Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #194340 > unrolled thread

All of my enoX interfaces are mapped to eth0

Back to article view | Back to linux.debian.user

Contents

  All of my enoX interfaces are mapped to eth0 David Parker <dparker@utica.edu> - 2018-03-30 22:30 +0200
    Re: All of my enoX interfaces are mapped to eth0 David Wright <deblis@lionunicorn.co.uk> - 2018-03-31 02:00 +0200
      Re: All of my enoX interfaces are mapped to eth0 David Parker <dparker@utica.edu> - 2018-03-31 04:10 +0200
        Re: All of my enoX interfaces are mapped to eth0 David Wright <deblis@lionunicorn.co.uk> - 2018-03-31 04:40 +0200
          Re: All of my enoX interfaces are mapped to eth0 David Parker <dparker@utica.edu> - 2018-03-31 05:20 +0200
            Re: All of my enoX interfaces are mapped to eth0 David Wright <deblis@lionunicorn.co.uk> - 2018-03-31 16:20 +0200
              Re: All of my enoX interfaces are mapped to eth0 David Parker <dparker@utica.edu> - 2018-04-02 17:40 +0200
                Re: All of my enoX interfaces are mapped to eth0 David Wright <deblis@lionunicorn.co.uk> - 2018-04-02 20:50 +0200

#194340 — All of my enoX interfaces are mapped to eth0

[Multipart message — attachments visible in raw view] — view raw

Hello,

I have two identical HP servers running Debian 9.  One of them is a clean
install of 9, whereas the other was upgraded from Debian 8.

The one that was upgraded has no networking issues (indeed, it still uses
the ethX interface names).  However, the one that was installed from
scratch is having an issue which I can't seem to figure out.  There are 4
network interfaces -- eno[1-4] -- but they are all getting mapped to eth0.
It looks like they were mapped correctly until I reloaded the network
driver a few days ago.  Any idea how I can get them back into a 1:1 mapping
with the actual physical interfaces, instead of all pointing to the same
one?

Some dmesg output for reference:

[Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014)
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001]
dma_mask[64-bit]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: dma_rwctrl[00000001]
dma_mask[64-bit]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: dma_rwctrl[00000001]
dma_mask[64-bit]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: dma_rwctrl[00000001]
dma_mask[64-bit]



*[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eno2: renamed from eth1[Wed
Mar 28 17:00:45 2018] tg3 0000:03:00.0 eno1: renamed from eth0[Wed Mar 28
17:00:45 2018] tg3 0000:03:00.3 eno4: renamed from eth3[Wed Mar 28 17:00:45
2018] tg3 0000:03:00.2 eno3: renamed from eth2*

Looks fine, but then...

[Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014)
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eno1: renamed from eth0*
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: dma_rwctrl[00000001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eno2: renamed from eth0*
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: dma_rwctrl[00000001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eno3: renamed from eth0*
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: dma_rwctrl[00000001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eno4: renamed from eth0*

I should note that this server is now in production, so it would be
fantastic if I can solve this without taking down eno1 as that is the
primary network link.  Any help is greatly appreciated.

Thanks!

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [next] | [standalone]

#194348

On Fri 30 Mar 2018 at 16:19:30 (-0400), David Parker wrote:
> Hello,
> 
> I have two identical HP servers running Debian 9.  One of them is a clean
> install of 9, whereas the other was upgraded from Debian 8.
> 
> The one that was upgraded has no networking issues (indeed, it still uses
> the ethX interface names).  However, the one that was installed from
> scratch is having an issue which I can't seem to figure out.  There are 4
> network interfaces -- eno[1-4] -- but they are all getting mapped to eth0.
> It looks like they were mapped correctly until I reloaded the network
> driver a few days ago.  Any idea how I can get them back into a 1:1 mapping
> with the actual physical interfaces, instead of all pointing to the same
> one?
> 
> Some dmesg output for reference:
> 
> [Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014)
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001]
> dma_mask[64-bit]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: dma_rwctrl[00000001]
> dma_mask[64-bit]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: dma_rwctrl[00000001]
> dma_mask[64-bit]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: dma_rwctrl[00000001]
> dma_mask[64-bit]
> 
> 
> 
> *[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eno2: renamed from eth1[Wed
> Mar 28 17:00:45 2018] tg3 0000:03:00.0 eno1: renamed from eth0[Wed Mar 28
> 17:00:45 2018] tg3 0000:03:00.3 eno4: renamed from eth3[Wed Mar 28 17:00:45
> 2018] tg3 0000:03:00.2 eno3: renamed from eth2*
> 
> Looks fine, but then...
> 
> [Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014)
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001]
> dma_mask[64-bit]
> *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eno1: renamed from eth0*
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: dma_rwctrl[00000001]
> dma_mask[64-bit]
> *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eno2: renamed from eth0*
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: dma_rwctrl[00000001]
> dma_mask[64-bit]
> *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eno3: renamed from eth0*
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: Tigon3
> [partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: attached PHY is 5719C
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[1] TSOcap[1]
> [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: dma_rwctrl[00000001]
> dma_mask[64-bit]
> *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eno4: renamed from eth0*
> 
> I should note that this server is now in production, so it would be
> fantastic if I can solve this without taking down eno1 as that is the
> primary network link.  Any help is greatly appreciated.

Colour me stupid but can you explain what the problem is. All I see is
two sets of logs, both of which result in this assignment:

 eno1: MAC address d8:9d:67:2c:ec:e0
 eno2: MAC address d8:9d:67:2c:ec:e1
 eno3: MAC address d8:9d:67:2c:ec:e2
 eno4: MAC address d8:9d:67:2c:ec:e3

Your system is using scheme 1 to arrive at this state:
"Names incorporating Firmware/BIOS provided index numbers
for on-board devices (example: eno1)".

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194350

[Multipart message — attachments visible in raw view] — view raw

That's what I thought, too.  As you pointed out, the logs show each eno
interface being assigned to a different MAC address.  However, I am able to
assign IP addresses to any (or all) of those interfaces and then ping them
from a different machine, even though the first interface is the only one
which is physically connected to the network.  The other three interfaces
are unplugged.  So that leads me to believe that all 4 eno interfaces are
actually mapping to the first physical interface (a.k.a. eth0).

That's why I'm really confused.

Thanks!

On Fri, Mar 30, 2018 at 7:50 PM, David Wright <deblis@lionunicorn.co.uk>
wrote:

> On Fri 30 Mar 2018 at 16:19:30 (-0400), David Parker wrote:
> > Hello,
> >
> > I have two identical HP servers running Debian 9.  One of them is a clean
> > install of 9, whereas the other was upgraded from Debian 8.
> >
> > The one that was upgraded has no networking issues (indeed, it still uses
> > the ethX interface names).  However, the one that was installed from
> > scratch is having an issue which I can't seem to figure out.  There are 4
> > network interfaces -- eno[1-4] -- but they are all getting mapped to
> eth0.
> > It looks like they were mapped correctly until I reloaded the network
> > driver a few days ago.  Any idea how I can get them back into a 1:1
> mapping
> > with the actual physical interfaces, instead of all pointing to the same
> > one?
> >
> > Some dmesg output for reference:
> >
> > [Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014)
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e0
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e1
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eth1: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e2
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.2 eth2: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e3
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 0000:03:00.3 eth3: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> >
> >
> >
> > *[Wed Mar 28 17:00:45 2018] tg3 0000:03:00.1 eno2: renamed from eth1[Wed
> > Mar 28 17:00:45 2018] tg3 0000:03:00.0 eno1: renamed from eth0[Wed Mar 28
> > 17:00:45 2018] tg3 0000:03:00.3 eno4: renamed from eth3[Wed Mar 28
> 17:00:45
> > 2018] tg3 0000:03:00.2 eno3: renamed from eth2*
> >
> > Looks fine, but then...
> >
> > [Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014)
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e0
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eth0: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.0 eno1: renamed from eth0*
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e1
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eth0: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.1 eno2: renamed from eth0*
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e2
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eth0: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.2 eno3: renamed from eth0*
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e3
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eth0: dma_rwctrl[00000001]
> > dma_mask[64-bit]
> > *[Wed Mar 28 17:12:33 2018] tg3 0000:03:00.3 eno4: renamed from eth0*
> >
> > I should note that this server is now in production, so it would be
> > fantastic if I can solve this without taking down eno1 as that is the
> > primary network link.  Any help is greatly appreciated.
>
> Colour me stupid but can you explain what the problem is. All I see is
> two sets of logs, both of which result in this assignment:
>
>  eno1: MAC address d8:9d:67:2c:ec:e0
>  eno2: MAC address d8:9d:67:2c:ec:e1
>  eno3: MAC address d8:9d:67:2c:ec:e2
>  eno4: MAC address d8:9d:67:2c:ec:e3
>
> Your system is using scheme 1 to arrive at this state:
> "Names incorporating Firmware/BIOS provided index numbers
> for on-board devices (example: eno1)".
>
> https://www.freedesktop.org/wiki/Software/systemd/
> PredictableNetworkInterfaceNames/
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [prev] | [next] | [standalone]

#194354

On Fri 30 Mar 2018 at 22:01:23 (-0400), David Parker wrote:
> That's what I thought, too.  As you pointed out, the logs show each eno
> interface being assigned to a different MAC address.  However, I am able to
> assign IP addresses to any (or all) of those interfaces and then ping them
> from a different machine, even though the first interface is the only one
> which is physically connected to the network.  The other three interfaces
> are unplugged.  So that leads me to believe that all 4 eno interfaces are
> actually mapping to the first physical interface (a.k.a. eth0).

Do you have the IP addresses for the different interfaces on the same subnet?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194356

[Multipart message — attachments visible in raw view] — view raw

They are all on the same subnet, yes.  But I haven't ever seen this
behavior before.  Normally, when I have an interface which is unplugged,
its IP is unreachable.

On Fri, Mar 30, 2018 at 10:30 PM, David Wright <deblis@lionunicorn.co.uk>
wrote:

> On Fri 30 Mar 2018 at 22:01:23 (-0400), David Parker wrote:
> > That's what I thought, too.  As you pointed out, the logs show each eno
> > interface being assigned to a different MAC address.  However, I am able
> to
> > assign IP addresses to any (or all) of those interfaces and then ping
> them
> > from a different machine, even though the first interface is the only one
> > which is physically connected to the network.  The other three interfaces
> > are unplugged.  So that leads me to believe that all 4 eno interfaces are
> > actually mapping to the first physical interface (a.k.a. eth0).
>
> Do you have the IP addresses for the different interfaces on the same
> subnet?
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [prev] | [next] | [standalone]

#194362

On Fri 30 Mar 2018 at 23:16:26 (-0400), David Parker wrote:
> They are all on the same subnet, yes.  But I haven't ever seen this
> behavior before.  Normally, when I have an interface which is unplugged,
> its IP is unreachable.

So we have two machines, one with eth0, eth1, eth2, eth3 and one
with eno1, eno2, eno3, eno4. The first one has no issues, and the
second reportedly does.

What differences are there in the symptoms presented by the two
machines? Are the former's interfaces on the same subnet too?

AIUI, which is not very much, your ping behaviour is not unexpected,
and running multiple interfaces on the same subnet takes some out
of the ordinary configuration. (Or are your interfaces eno2-4 just
treading water until you have something to connect them too?)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194401

[Multipart message — attachments visible in raw view] — view raw

I don't normally set IP addresses on interfaces which I know to be offline,
so perhaps my methodology here was flawed.  In this case, I set IP
addresses on eno2, eno3, and eno4 to test whether or not they were actually
discrete interfaces, or if they were all somehow mapped to the one
interface which was actually connected.

Normally, I only set IP addresses on interfaces which are already
connected, but in that case I will stop seeing a ping response from any IP
on an interface which is subsequently disconnected, regardless of whether
or not I have multiple interfaces on the same subnet.

The reason I was trying to figure out whether or not they were actually
mapped to the same physical interface was that I needed to setup a bonded
interface.  A quick unload/reload of the network driver resulted in a
correct mapping (eno1->eth0, eno2->eth1, etc.) and then I was able to set
up the bonded interface in active/passive failover mode just fine.  So it's
all set now.

Thanks!

On Sat, Mar 31, 2018 at 10:11 AM, David Wright <deblis@lionunicorn.co.uk>
wrote:

> On Fri 30 Mar 2018 at 23:16:26 (-0400), David Parker wrote:
> > They are all on the same subnet, yes.  But I haven't ever seen this
> > behavior before.  Normally, when I have an interface which is unplugged,
> > its IP is unreachable.
>
> So we have two machines, one with eth0, eth1, eth2, eth3 and one
> with eno1, eno2, eno3, eno4. The first one has no issues, and the
> second reportedly does.
>
> What differences are there in the symptoms presented by the two
> machines? Are the former's interfaces on the same subnet too?
>
> AIUI, which is not very much, your ping behaviour is not unexpected,
> and running multiple interfaces on the same subnet takes some out
> of the ordinary configuration. (Or are your interfaces eno2-4 just
> treading water until you have something to connect them too?)
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [prev] | [next] | [standalone]

#194416

On Mon 02 Apr 2018 at 11:34:40 (-0400), David Parker wrote:
> I don't normally set IP addresses on interfaces which I know to be offline,
> so perhaps my methodology here was flawed.  In this case, I set IP
> addresses on eno2, eno3, and eno4 to test whether or not they were actually
> discrete interfaces, or if they were all somehow mapped to the one
> interface which was actually connected.
> 
> Normally, I only set IP addresses on interfaces which are already
> connected, but in that case I will stop seeing a ping response from any IP
> on an interface which is subsequently disconnected, regardless of whether
> or not I have multiple interfaces on the same subnet.
> 
> The reason I was trying to figure out whether or not they were actually
> mapped to the same physical interface was that I needed to setup a bonded
> interface.  A quick unload/reload of the network driver resulted in a
> correct mapping (eno1->eth0, eno2->eth1, etc.) and then I was able to set
> up the bonded interface in active/passive failover mode just fine.  So it's
> all set now.

That seems an odd solution to me, which might work in your particular
case because of the hardware you're using (which has four sequential
MAC addresses) but would be unwise in the general case. The enoN names
are stable whereas the ethN names are assigned in a race.

Although the ethN race has been consistent for you, you can see the
race at work in their renaming. The second log showed the kernel kept
reusing eth0 because the renaming was winning against discovery,
whereas the first log showed discovery winning against renaming.

The gap between renaming the two interfaces on this laptop varies from
0.014 to 0.292 seconds as a lot is going on around the same time.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web