Network stops working for no reason in Linux

[CougTek]

When I try large downloads on the damn Linux server, the transfers stops after a few tens of MB. First time I tried to download mysql 5.6 from Oracle's website, the forst 30MB went thru, but then all networking activity stopped. I could not even ping Google. After a few minutes, everything went back to normal. I retried the MySQL 5.6 download and this time, 46MB were saved before the same trouble happened.

I recently changed the name of the server by editing the hostname and hosts files, but I restarted the server since. I also set a fixed IP address that I verified to be free on the network. Bth should not cause this problem. Otherwise, I don't know what I could have done to cause this.

 

[CougTek]

I'll add that I have a lot of packet loss when pinging Google, but none when I ping a local IP (a 192.168.0.xxx).

There are two network card in the server. One is set with a fixed IP address and the other one is on the DHCP because I didn't bother to set it to a fixed IP. They don't have the same IP, of course.

 

[timwhit]

What kind of NICs are in use? I've had issues with cheap onboard NICs in Linux in the past. I use an Intel add-on one now.

 

[CougTek]

Whatever NIC comes on the motherboard of a Dell PowerEdge 2950 III. I doubt they are cheap. It's either Intel's or Broadcom's NIC.

 

[P5-133XL]

Does the same problem happen when DL'ing from the local network? I suspect that it is an ISP problem.

Tracert is probably a better tool for identifying the problem than ping.

 

[CougTek]

The problem was that I had two NIC on the same network and although they had different IP addresses, it somehow caused troubles. I disactivated the second network port and all was fine afterward.

 

[Handruin]

The problem was that I had two NIC on the same network and although they had different IP addresses, it somehow caused troubles. I disactivated the second network port and all was fine afterward.

If you want two NICs on the same network/subnet you'll need to team them otherwise you will end up with some traffic going out of one and receive on the other (in some cases) and hard to debug situations like you're seeing.

 

[CougTek]

Thanks for the link. I won't need it this time, but it will be useful for another project.

 

[blakerwry]

Teaming is only appropriate if the two NICs are connected to the same switch. Unfortunately, Linux exhibits this odd default behavior whether the NICs are connected to the same switch, different LAN segments, or even different ISPs.

It's ultimately caused by the fact that the Linux kernel sees IPs as belonging to the host and not to a specific NIC. So Linux will seemingly send traffic out of eth1 using the address assigned to eth0. This can happen at both layer 2 (mac addresses) and layer 3 (IP addresses). In practice, this used to work fine. But as more ISPs prevent IP spoofing it's generally "against the rules" to use your Comcast IP via your TimeWarner connection.

The solution in most cases is to apply the arp_filter command to one or more interfaces to ensure the Linux machine does not improperly respond to ARP requests. - http://robertlathanh.com/2009/08/two-subnetworks-on-one-lan-and-linux-arp_filter/
At L3, TCP based application generally get this right, but UDP applications (DNS, DHCP, NTP) often don't maintain the session information to respond using secondary IP addresses correctly (they often use the 1st or primary IP on an interface). If you run into problems here, it may be necessary to apply more advanced routing with static routes or iproute2 or even use iptables to re-write IP source addresses.

 

[Handruin]

Teaming is only appropriate if the two NICs are connected to the same switch. Unfortunately, Linux exhibits this odd default behavior whether the NICs are connected to the same switch, different LAN segments, or even different ISPs.

It's ultimately caused by the fact that the Linux kernel sees IPs as belonging to the host and not to a specific NIC. So Linux will seemingly send traffic out of eth1 using the address assigned to eth0. This can happen at both layer 2 (mac addresses) and layer 3 (IP addresses). In practice, this used to work fine. But as more ISPs prevent IP spoofing it's generally "against the rules" to use your Comcast IP via your TimeWarner connection.

The solution in most cases is to apply the arp_filter command to one or more interfaces to ensure the Linux machine does not improperly respond to ARP requests. - http://robertlathanh.com/2009/08/two-subnetworks-on-one-lan-and-linux-arp_filter/
At L3, TCP based application generally get this right, but UDP applications (DNS, DHCP, NTP) often don't maintain the session information to respond using secondary IP addresses correctly (they often use the 1st or primary IP on an interface). If you run into problems here, it may be necessary to apply more advanced routing with static routes or iproute2 or even use iptables to re-write IP source addresses.

My current implementation in my work environment uses teaming with NICs on separate switches in our Cisco UCS environment (Nexus 5K series layer 2). I do not believe we do any special arp_filter. Would this be due to the Cisco 5K series spanning tree updating each of the switches?