I am attempting to build an IPv4/IPv6 router. I have put a 2nd ethernet card in a box.
I have one Ethernet card attached to my network and the other to a switch with nothing else there just so the link comes up for testing.
When I have the built-in Ethernet attached to my network, I get pings around 60ms. The other card, btw, does not have any IP addresses configed.
When I switch the cards around, the addon card attached to my network, I get pings that alternate with one being ~1488ms and the next 488ms! This is regular.
This is the 2nd card I have tried. The 1st one was getting ping times of 1900ms/900ms.
I have played around with the IRQ for the 2nd card. The 1st card I tried I was limited to 9,10, or 11. The card I am using now allows 3, 4, or 7 (btw, I have disabled serial and parallel ports).
Any Idea where I should look to fix this?
Robert Moskowitz wrote:
Any Idea where I should look to fix this?
- What version of CentOS? - What type of network card? - What driver is it using? - What type of device is on the other end of the network card?(Switch, hub, router etc) - Can you verify that the speed and duplex settings match on both ends of the connection? - I assume the ping you are running is only 1 or 2(if there's a hub/switch in between) hops away? - Any errors reported by ifconfig ? any collisions? - Try replacing the card itself? maybe it is bad.
nate
nate wrote:
Robert Moskowitz wrote:
Any Idea where I should look to fix this?
- What version of CentOS?
5.2
- What type of network card?
Intel the first time, DLink (Realtek) currently. Both 10/100Mb
- What driver is it using?
How do I tell?
- What type of device is on the other end of the network card?(Switch, hub, router etc)
The card is plugged into a switch. All boxes plugged into the switch get similar PING results. Good with the internal (also Intel) card, bad/very_bad with the PCI ethernet card.
- Can you verify that the speed and duplex settings match on both ends of the connection?
The switch has its 100Mb LED on. One of the switch ports has my Speedstream router which is only 10Mb, so we can believe the 100Mb LED. This is a dumb switch (my public network, so I am not going to plug into one of my Procurves).
- I assume the ping you are running is only 1 or 2(if there's a hub/switch in between) hops away?
I have done it 1 hop (directly attached boxes), 2 hops, and somewhere out there on the net (198.6.1.2, a great system to use as an emergency DNS server).
- Any errors reported by ifconfig ? any collisions?
No and no.
eth1 Link encap:Ethernet HWaddr 00:50:BA:42:82:49 inet addr:208.83.67.132 Bcast:208.83.67.135 Mask:255.255.255.248 inet6 addr: fe80::250:baff:fe42:8249/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1709 errors:0 dropped:0 overruns:0 frame:0 TX packets:1033 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:535351 (522.8 KiB) TX bytes:117321 (114.5 KiB) Interrupt:10 Base address:0xa000
ho, ho. MTU of 1500. Is this not doing MTU path discovery? But these are little PINGs so there should not be any frag problems (my WAN link is PPPoE, so you want pathMTU or have to hard config everything to 1415bytes per the pppoe man pages).
- Try replacing the card itself? maybe it is bad.
On my 2nd card already.
Robert Moskowitz wrote:
I get pings around 60ms.
Pings within the same LAN? If so, that's slow even for 100BaseT. It should be under 10 ms.
When I switch the cards around, the addon card attached to my network, I get pings that alternate with one being ~1488ms and the next 488ms! This is regular.
Have you removed the cabling from consideration? And, do you know you have good cabling, tested as following the wiring standards? Hand-made cables are particularly suspect, if made by someone who doesn't know what TIA/EIA 568 is, for example.
I have played around with the IRQ for the 2nd card. The 1st card I tried I was limited to 9,10, or 11. The card I am using now allows 3, 4, or 7 (btw, I have disabled serial and parallel ports).
None of this should matter in the PCI world, unless you're using really old hardware, which didn't properly support IRQ sharing.
- What driver is it using?
How do I tell?
grep eth0 /etc/modprobe.conf
or scan through the output of the dmesg command, looking for stuff that appears near "eth0".
- Can you verify that the speed and duplex settings match on both ends of the connection?
The switch has its 100Mb LED on. One of the switch ports has my Speedstream router which is only 10Mb, so we can believe the 100Mb LED. This is a dumb switch (my public network, so I am not going to plug into one of my Procurves).
That covers speed, but doesn't say anything about the duplex setting. You should see this mentioned near the Ethernet driver load lines in dmesg, too.
ho, ho. MTU of 1500. Is this not doing MTU path discovery?
PMTU-D is done per-connection at the TCP layer, not statically down at L2.
Warren Young wrote:
Robert Moskowitz wrote:
I get pings around 60ms.
Pings within the same LAN? If so, that's slow even for 100BaseT. It should be under 10 ms.
Well, perhaps I did not test everything out with the good card. MIght have been doing only 2 hop tests. But with the bad one, it is bad.
When I switch the cards around, the addon card attached to my network, I get pings that alternate with one being ~1488ms and the next 488ms! This is regular.
Have you removed the cabling from consideration? And, do you know you have good cabling, tested as following the wiring standards? Hand-made cables are particularly suspect, if made by someone who doesn't know what TIA/EIA 568 is, for example.
Some cables are hand made, some purchased. All tested with my cable tester. I know all too well the various cabling standards.
I have played around with the IRQ for the 2nd card. The 1st card I tried I was limited to 9,10, or 11. The card I am using now allows 3, 4, or 7 (btw, I have disabled serial and parallel ports).
None of this should matter in the PCI world, unless you're using really old hardware, which didn't properly support IRQ sharing.
It is old hardware. Compaq SFFs going back a number of years.
- What driver is it using?
How do I tell?
grep eth0 /etc/modprobe.conf
Good card: alias eth0 e100
Bad card: alias eth1 8139too
or scan through the output of the dmesg command, looking for stuff that appears near "eth0".
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 e100: eth0: e100_probe: addr 0x41200000, irq 10, MAC addr 00:50:8B:00:43:B3 8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004) 8139cp 0000:00:0e.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip 8139cp 0000:00:0e.0: Try the "8139too" driver instead. input: PC Speaker as /class/input/input2 8139too Fast Ethernet driver 0.9.27 ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10 eth1: RealTek RTL8139 at 0xd08fa000, 00:50:ba:42:82:49, IRQ 10 eth1: Identified 8139 chip type 'RTL-8139B'
The IRQs above are overrides on the BIOS settings of 11 and 3 respectively.
- Can you verify that the speed and duplex settings match on both
ends of the connection?
The switch has its 100Mb LED on. One of the switch ports has my Speedstream router which is only 10Mb, so we can believe the 100Mb LED. This is a dumb switch (my public network, so I am not going to plug into one of my Procurves).
That covers speed, but doesn't say anything about the duplex setting. You should see this mentioned near the Ethernet driver load lines in dmesg, too.
Do you see anything in the lines I pasted above? Those are the only ones from dmesg.
ho, ho. MTU of 1500. Is this not doing MTU path discovery?
PMTU-D is done per-connection at the TCP layer, not statically down at L2.
That I know, just thought there would be some indication in ifconfig. But thinking about it, I am not supprised there is not.
Robert Moskowitz wrote:
grep eth0 /etc/modprobe.conf
Good card: alias eth0 e100
Bad card: alias eth1 8139too
[..]
8139cp 0000:00:0e.0: Try the "8139too" driver instead. input: PC Speaker as /class/input/input2 8139too Fast Ethernet driver 0.9.27
There seems to be a conflict here, it seems as if a driver called '8139cp' is being loaded before '8139too'.
One thing to try, shut down the network interfaces (/etc/init.d/network stop), remove the 8139cp module and the 8139too modules: rmmod 8139cp rmmod 8139too
Re-insert the 8139too module: modprobe 8139too
Start networking again: /etc/init.d/networking start
Verify that the 8139cp driver is not loaded: lsmod | grep 8139cp
If 8139cp is loaded again try flat out moving the module out of the /lib/modules/`uname -r`/ directory tree to another location, and repeat the above.
and try your test again
nate
nate wrote:
One thing to try, shut down the network interfaces (/etc/init.d/network stop),
I noticed this which seems to be kinda-sorta-maybe related to what you are experiencing: https://bugs.launchpad.net/ubuntu/+source/gnome-network/+bug/35683
The suggestion is to boot with the option pci=noacpi
nate
nate wrote:
nate wrote:
One thing to try, shut down the network interfaces (/etc/init.d/network stop),
I noticed this which seems to be kinda-sorta-maybe related to what you are experiencing: https://bugs.launchpad.net/ubuntu/+source/gnome-network/+bug/35683
The suggestion is to boot with the option pci=noacpi
AH, that's the ticket.
ping times to 1 hop hoss >1ms
Thank you very much!
Robert Moskowitz wrote:
AH, that's the ticket.
ping times to 1 hop hoss >1ms
Thank you very much!
Sure thing, I guess that's just another data point that Realtek chipsets aren't the best thing to be using these days, seems flaky.
glad it was an easy fix(this time..).
nate
Robert Moskowitz wrote:
That covers speed, but doesn't say anything about the duplex setting. You should see this mentioned near the Ethernet driver load lines in dmesg, too.
Do you see anything in the lines I pasted above? Those are the only ones from dmesg.
try: ethtool eth0
this will tell you the duplex mode, speed etc...
Nicolas Thierry-Mieg wrote:
Robert Moskowitz wrote:
That covers speed, but doesn't say anything about the duplex setting. You should see this mentioned near the Ethernet driver load lines in dmesg, too.
Do you see anything in the lines I pasted above? Those are the only ones from dmesg.
try: ethtool eth0
thanks:
ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000007 (7) Link detected: yes
Robert Moskowitz wrote:
Intel the first time, DLink (Realtek) currently. Both 10/100Mb
There's a lot of different Realtek chips out there, can you send the output of lspci -v (and capture the network card only since it spits out a lot of output). I've heard lots of bad things over the years about Realtek cards though my personal experience with them has been fine(last one I used I bought probably 6 years ago).
- What driver is it using?
How do I tell?
Check in /etc/modprobe.conf, also you can include the output of 'lsmod'
- Can you verify that the speed and duplex settings match on both ends of the connection?
The switch has its 100Mb LED on. One of the switch ports has my Speedstream router which is only 10Mb, so we can believe the 100Mb LED. This is a dumb switch (my public network, so I am not going to plug into one of my Procurves).
Since it's a dumb switch there's probably no way to confirm duplex settings. One thing you could try is hard setting the NIC to the various different options and see if things improve. It could be that auto negotiation is failing so they are running at mismatched duplexes. Which depending on the quality of the switch will depend on the results. About 10 years ago I had a 3COM network card and a Linksys switch that just refused to co-operate. Of course 3COM blamed Linksys and Linksys blamed 3COM. Ended up going with a netgear switch and that 'fixed' it.
You should be able to use the 'ethtool' command to force duplex/speed changes.
No and no.
eth1 Link encap:Ethernet HWaddr 00:50:BA:42:82:49 inet addr:208.83.67.132 Bcast:208.83.67.135 Mask:255.255.255.248 inet6 addr: fe80::250:baff:fe42:8249/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1709 errors:0 dropped:0 overruns:0 frame:0 TX packets:1033 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:535351 (522.8 KiB) TX bytes:117321 (114.5 KiB) Interrupt:10 Base address:0xa000
Quite unusual..
ho, ho. MTU of 1500. Is this not doing MTU path discovery? But these are little PINGs so there should not be any frag problems (my WAN link is PPPoE, so you want pathMTU or have to hard config everything to 1415bytes per the pppoe man pages).
The only experience I have with MTU discovery is with jumbo frames, and as far as I know MTU discovery is only available for TCP, not UDP or ICMP. You could certainly manually set your MTU to 1415 with ifconfig eth1 mtu 1415, but as you say the packets your sending are tiny anyways so it probably won't have any impact.
- Try replacing the card itself? maybe it is bad.
On my 2nd card already.
Of the same type? Try another brand/model? Get another Intel card, or a broadcom-based card(3COM or something).
I wouldn't expect IRQ conflicts to be much of an issue with this type of problem, such tiny amounts of traffic on the card. I can't even remember the last time I had to deal with IRQs, 4-5-6 years? Things seem to work pretty well these days.
nate
nate wrote:
Robert Moskowitz wrote:
Intel the first time, DLink (Realtek) currently. Both 10/100Mb
There's a lot of different Realtek chips out there, can you send the output of lspci -v (and capture the network card only since it spits out a lot of output). I've heard lots of bad things over the years about Realtek cards though my personal experience with them has been fine(last one I used I bought probably 6 years ago).
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: D-Link System Inc Unknown device 1301 Flags: bus master, medium devsel, latency 66, IRQ 10 I/O ports at 1000 [size=256] Memory at 40000000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2
See my prior post for mseg info on this card.
- What driver is it using?
How do I tell?
Check in /etc/modprobe.conf, also you can include the output of 'lsmod'
- Can you verify that the speed and duplex settings match on both ends of the connection?
The switch has its 100Mb LED on. One of the switch ports has my Speedstream router which is only 10Mb, so we can believe the 100Mb LED. This is a dumb switch (my public network, so I am not going to plug into one of my Procurves).
Since it's a dumb switch there's probably no way to confirm duplex settings. One thing you could try is hard setting the NIC to the various different options and see if things improve. It could be that auto negotiation is failing so they are running at mismatched duplexes. Which depending on the quality of the switch will depend on the results. About 10 years ago I had a 3COM network card and a Linksys switch that just refused to co-operate. Of course 3COM blamed Linksys and Linksys blamed 3COM. Ended up going with a netgear switch and that 'fixed' it.
You should be able to use the 'ethtool' command to force duplex/speed changes.
I will change addresses on this card and plug it into one of my Procurve switches. That will tell me part of what is going on.
No and no.
eth1 Link encap:Ethernet HWaddr 00:50:BA:42:82:49 inet addr:208.83.67.132 Bcast:208.83.67.135 Mask:255.255.255.248 inet6 addr: fe80::250:baff:fe42:8249/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1709 errors:0 dropped:0 overruns:0 frame:0 TX packets:1033 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:535351 (522.8 KiB) TX bytes:117321 (114.5 KiB) Interrupt:10 Base address:0xa000
Quite unusual..
ho, ho. MTU of 1500. Is this not doing MTU path discovery? But these are little PINGs so there should not be any frag problems (my WAN link is PPPoE, so you want pathMTU or have to hard config everything to 1415bytes per the pppoe man pages).
The only experience I have with MTU discovery is with jumbo frames, and as far as I know MTU discovery is only available for TCP, not UDP or ICMP. You could certainly manually set your MTU to 1415 with ifconfig eth1 mtu 1415, but as you say the packets your sending are tiny anyways so it probably won't have any impact.
- Try replacing the card itself? maybe it is bad.
On my 2nd card already.
Of the same type? Try another brand/model? Get another Intel card, or a broadcom-based card(3COM or something).
Different types. I have to use what I have sitting around for right now.
I wouldn't expect IRQ conflicts to be much of an issue with this type of problem, such tiny amounts of traffic on the card. I can't even remember the last time I had to deal with IRQs, 4-5-6 years? Things seem to work pretty well these days.
Same here, but when you are groping for answers, you fall back on old experiences.
Good list: Also add multiple runs of "traceroute" and also try ping, ping -f , ping -A and ping -R. See also ping6 If routes are dynamic we have one answer to the problem, I would expect traceroute to have 'one' answer on a simple net. If packets are falling on the floor then we need to know why.
The different invocations of ping can tell you if packets drop at slow or fast transfer rates. ping -R is slightly different than traceroute but if the return routes flip one way then the other we should know why.
Watch out for /etc/sysconfig/network-scripts/ifcfg* where hardware addresses, subnet masks, device driver links/ names etc. no longer match the hardware when things move.
Consider snooping packets on the link to see if all is as you expect. I keep an old, slow network hub (not a switching hub) for the times when I want to see the bits on the wire and not the bits that the local driver is able to show me.
On Wed, Jul 2, 2008 at 8:55 AM, nate centos@linuxpowered.net wrote:
Robert Moskowitz wrote:
Any Idea where I should look to fix this?
- What version of CentOS?
- What type of network card?
- What driver is it using?
- What type of device is on the other end of the network card?(Switch, hub,
router etc)
- Can you verify that the speed and duplex settings match on both ends of
the connection?
- I assume the ping you are running is only 1 or 2(if there's a hub/switch
in between) hops away?
- Any errors reported by ifconfig ? any collisions?
- Try replacing the card itself? maybe it is bad.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- NiftyCluster T o m M i t c h e l l
NiftyClusters Mitch wrote:
Good list: Also add multiple runs of "traceroute" and also try ping, ping -f , ping -A and ping -R. See also ping6 If routes are dynamic we have one answer to the problem, I would expect traceroute to have 'one' answer on a simple net. If packets are falling on the floor then we need to know why.
The different invocations of ping can tell you if packets drop at slow or fast transfer rates. ping -R is slightly different than traceroute but if the return routes flip one way then the other we should know why.
Watch out for /etc/sysconfig/network-scripts/ifcfg* where hardware addresses, subnet masks, device driver links/ names etc. no longer match the hardware when things move.
More, watch out for /etc/sysconfig/networking/devices where configs that you thought you deleted live on to get you when your run system-config-network. I just could not figure out, for a while, why when I deleted /etc/sysconfig/network-scripts/ifcfg-eth1.bak it would be right back there!
Consider snooping packets on the link to see if all is as you expect. I keep an old, slow network hub (not a switching hub) for the times when I want to see the bits on the wire and not the bits that the local driver is able to show me.
I have one as well. It is so hard to find them anymore....
-
nate -
Nicolas Thierry-Mieg -
NiftyClusters Mitch -
Robert Moskowitz -
Warren Young