eth0 doesn't ping out, but eth1 with the same settings does.

abefroman · 01-14-2014, 10:05 PM

eth0 doesn't ping out, but when I move the cable over, eth1 with the same settings does.

iptables are flushed.

When the cable is in eth0 the green light is on on the nic port as well as the switch port.

Any ideas why eth0 won't ping out?

ericson007 · 01-14-2014, 10:30 PM

Because ping is routed through the default gateway which would be eth1. You need to change behavior using the ip tool stack so traffic comes in and out on the same interface it is generated on.

abefroman · 01-15-2014, 10:32 AM

Its coming in an out on eth1 when I have eth1 plugged in. (Note, only one of the nics is hooked up at a time).

Where is the IP Tool Stack set at?

ericson007 · 01-15-2014, 06:08 PM

If 1 nic is hooked up automatically it is the default device.

http://www.linuxquestions.org/questi...ks-4175487417/

Ser Olmy · 01-15-2014, 09:06 PM

Quote:

Originally Posted by abefroman

When the cable is in eth0 the green light is on on the nic port as well as the switch port.

Any ideas why eth0 won't ping out?

Because eth1 is set to retrieve an IP address using DHCP while eth0 has a statically assigned address in another network?

Because eth0 is set to retrieve an IP address using DHCP while eth1 has a statically assigned address, so the system keeps using the now-unreachable gateway?

Because autonegotiation is off on eth0?

Because the switchport is locked to a certain speed matching eth1, while eth0 tries in vain to autonegotiate?

Because eth1 is a 100 Mbps NIC while eth0 is a gigabit NIC and the cable is bad?

Because the driver for eth0 is broken?

We'll need some more information, like the output from ifconfig <device> or ip link show <device> when the cable is plugged into <device>. The output from ip route show and ethtool <device> could also be useful.

abefroman · 01-15-2014, 09:21 PM

It seems the box thinks eth0 is physical eth1 and it thinks eth1 is the physical eth0. ???

Because eth1 is set to retrieve an IP address using DHCP while eth0 has a statically assigned address in another network?
Because eth0 is set to retrieve an IP address using DHCP while eth1 has a statically assigned address, so the system keeps using the now-unreachable gateway?
>>Both have a static IP, no dhcp (the same IP for testing)

Because autonegotiation is off on eth0?
>>nope

Because the switchport is locked to a certain speed matching eth1, while eth0 tries in vain to autonegotiate?
>>I tried a couple different switch ports, they are auto/auto

Because eth1 is a 100 Mbps NIC while eth0 is a gigabit NIC and the cable is bad?
>>I used the same cable for both nics, and tried with 2 cables

Because the driver for eth0 is broken?
>>It should be using the same driver, its a fresh centos install.

Here is ifconfig (eth0 is unplugged)

Code:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:25:90:D6:1A:1D  
          inet addr:xx.xx.xx.145  Bcast:xx.xx.xx.255  Mask:255.255.255.0
          inet6 addr: fe80::225:90ff:fed6:1a1d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3952836 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1867151 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5205449134 (4.8 GiB)  TX bytes:120172152 (114.6 MiB)
          Interrupt:20 Memory:dfa00000-dfa20000 

eth1      Link encap:Ethernet  HWaddr 00:25:90:D6:1A:1C  
          inet addr:xx.xx.xx.145  Bcast:xx.xx.xx.255  Mask:255.255.255.0
          inet6 addr: fe80::225:90ff:fed6:1a1c/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:774 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:215668 (210.6 KiB)  TX bytes:746 (746.0 b)
          Interrupt:16 Memory:df900000-df920000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:15784 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15784 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2932877 (2.7 MiB)  TX bytes:2932877 (2.7 MiB)

This is weird, it seems like linux is using eth0 even though the cable is in eth1:

Code:

root [~]# ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 2
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes
root [~]# ethtool eth1
Settings for eth1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: no

How can Linux think eth0 is the physical eth1? Is there a way to switch that?

Here is my ip route:

Code:

# ip route show
xx.xx.xx.0/24 dev eth0  proto kernel  scope link  src xx.xx.xx.145 
xx.xx.xx.0/24 dev eth1  proto kernel  scope link  src xx.xx.xx.145 
169.254.0.0/16 dev eth0  scope link  metric 1002 
169.254.0.0/16 dev eth1  scope link  metric 1003 
default via xx.xx.xx.1 dev eth0

Thanks for the assistance!

Ser Olmy · 01-15-2014, 10:08 PM

According to ifconfig, you have the same IP address assigned to two different NICs simultanously. That's never going to work.

When you assign an IP address to a NIC, a network route is added to the routing table saying "all addresses in this network can be reached directly via <name of NIC>". A MAC-to-IP binding is created, causing the system to respond with the MAC address of the NIC when other hosts on the network wants to communicate with the IP address in question and sends an ARP request. So, when two NICs have the same IP address, which MAC address should the system respond with?

You need to delete the address from one NIC before assigning the same address to the other. ifconfig <device> 0.0.0.0 should do the trick.

As for ethtool, not all NICs are fully supported. If it consistently reports that one NIC has a link (or not) regardless of where the cable is actually plugged in, it's probably a driver/compatibility issue. However, if eth0 has suddenly become eth1 and vice versa, udev is probably to blame. Not sure where CentOS keeps the "persistent-net.rules" file, but you could check in /etc/udev for a directory called "rules.d".

abefroman · 01-15-2014, 10:50 PM

you have the same IP address assigned to two different NICs simultanously. That's never going to work.
>>It works as long as I only need 1 NIC

(but yes, I'm going to remove the ip from the other nic as it may cause probs later)

As for ethtool, not all NICs are fully supported. If it consistently reports that one NIC has a link (or not) regardless of where the cable is actually plugged in, it's probably a driver/compatibility issue. However, if eth0 has suddenly become eth1 and vice versa, udev is probably to blame. Not sure where CentOS keeps the "persistent-net.rules" file, but you could check in /etc/udev for a directory called "rules.d".

Looks like its in /lib/udev, what do I change in there, the mac addresses?

Code:

root [/lib/udev]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x1502 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:d6:1a:1d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:d6:1a:1c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

TY again for the assistance.

ericson007 · 01-15-2014, 10:57 PM

If your goal is to make it appear as if the machine has only 1 ip and use both nics on the same connection, you are trying to bond the connection, so if that's your main goal, lookup bonding.

abefroman · 01-15-2014, 11:03 PM

Quote:

Originally Posted by ericson007

If your goal is to make it appear as if the machine has only 1 ip and use both nics on the same connection, you are trying to bond the connection, so if that's your main goal, lookup bonding.

No, I only need 1 nic & 1 IP at this time.

The problem is the server thinks eth0 is the physical eth1, instead of the physical eth0

Ser Olmy · 01-15-2014, 11:29 PM

Quote:

Originally Posted by abefroman

>>It works as long as I only need 1 NIC

No, it doesn't, because the IP stack will most likely answer ARP requests with the wrong MAC address for one of the cards, which means only one card will work, which sounds suspiciously like what you're experiencing.

Could you try using standard quoting, by the way?

Quote:

Originally Posted by abefroman

Looks like its in /lib/udev, what do I change in there, the mac addresses?

Yep, or just swap the names around (the last attribute on the line). Make sure your editor doesn't leave a backup copy of the file in the same directory, otherwise things could get interesting.