Ubuntu + Intel NIC geeft miljarden collisions

[Battle Bunny]

Ik heb hier een SuperMicro server met Ubuntu (kernel 2.6.32) en Intel NICs (82574L zegt lspci). Netwerk verkeer loopt prima, voor een half uurtje ongeveer. Vervolgens is de machine niet meer bereikbaar en verkeer van binnen naar buiten werkt ook niet meer. ifconfig toont vervolgens dit:

code:

eth0      Link encap:Ethernet  HWaddr 00:30:48:9f:09:be  
          inet addr:192.168.0.40  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::230:48ff:fe9f:9be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:105532 errors:24739011619200 dropped:4123168603200 overruns:0 frame:16492674412800
          TX packets:67612 errors:8246337206400 dropped:0 overruns:0 carrier:8246337206400
          collisions:4123168603200 txqueuelen:1000 
          RX bytes:13283864 (13.2 MB)  TX bytes:34871854 (34.8 MB)
          Memory:fb5e0000-fb600000

code:

cat /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.0.40
netmask 255.255.255.0

ifconfig eth0 down en vervolgens weer up fixen het niet, /etc/init.d/networking restart ook niet.

Vreemd genoeg treedt dit probleem ook op in een Ubuntu install in Hyper-V, nu dus op een fysieke machine.

Het natuurlijk wel zelf gezocht, maar snap niet waar dit probleem vandaan zou kunnen komen.


Enig idee?

[BHQ]

Hmm, wat voor NIC model heeft de virtuele machine? Dezelfde?

[ Voor 9% gewijzigd door BHQ op 20-09-2010 17:27 ]

[Exorcist]

Slechte kabel?

[FatalError]

Je hebt ook collisions.. dat komt meestal door een duplex mismatch. Hoe heb je de snelheid/duplex van de netwerkkaart (en van de switch indien het een manageable switch is) geconfigureerd?

[Kabouterplop01]

Yep, collissions heb je alleen bij half duplex. Jouw NIC staat dus op half duplex negotiated. (de andere kant wellicht fixed)

[Battle Bunny]

Excuses voor de late reactie, was even twee dagen "weg".

De VM had andere NICs maar wel dezelfde Ubuntu versie.

Kabels zijn vervangen en zitten in een andere poort in de switch. Beide NICs komen uit in een andere switch en beide hebben het probleem.

Zojuist ook even ethtool geinstalleerd:

code:

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        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
        Link partner advertised link modes:  Not reported
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: pumbag
        Wake-on: g
        Current message level: 0x00000001 (1)
        Link detected: yes

Volgens de switch staat de poort ook op "1000MbpsFullDuplexCopper"

(machine is wel net ge-reboot).

[Bloodshot]

Dus nu heb je zowel aan de switch-zijde als op de NIC 1000Mb/s, full duplex.
Het probleem moet nu eigenlijk opgelost zijn. Klopt dit?
Krijg je nu misschien andere errors?

[Battle Bunny]

Nope, nu is het weer kapot. Overigens lijkt de interne interface het eerder te begeven (eth0) dan de externe.

Sowieso lijkt me een getal van enkele honderden miljoenen niet echt een geloofwaardig aantal collisions...

[Battle Bunny]

Na lange tijd is het probleem ineens weer terug. Vreemd genoeg begon dit toevallig toen ik een nieuwe Ubuntu VM heb opgezet (from scratch, geen clone).




Volgens de switch heeft elke poort keurig 0 collisions.

Heeft iemand nog een idee waar ik het kan zoeken?

[FireDrunk]

VMWare tools geinstalleerd? Welke NIC wijs je toe aan de VM? Als jou switch geen collisions opgeeft, lijkt het een VMWare driver probleem... vmxnet schijnt betere performance te hebben, maar een e1000 werkt ook prima

[Battle Bunny]

De VMs draaien in Hyper-V, de screens zijn van een fysieke machine...

[Edit]
Dit is absurd. Na een reboot knalt 'ie binnen een paar minuten weer in de fout. Nu staan de VMs op pauze en nu lijkt het wel weer goed te werken. Kunnen meerdere Ubuntu installs elkaar bijten? Het zijn standaard installs waar ik Python, Mapnik en wat gerelateerde meuk op het staan.

Of staat default allerlei DHCP/Routing meuk aan?

[ Voor 71% gewijzigd door Battle Bunny op 09-12-2010 09:47 ]

[Gratzip]

Heb je al geprobeerd met Wireshark of een dergelijke tool, handmatig te kijken bij welke pakketjes het verkeerd gaat?

[Battle Bunny]

Neen, dit heb ik niet geprobeerd. De machine hangt in een rack bij XS4All samen met een flink aantal andere (drukke) servers welke ook onderling communiceren. Erg lastig om daar wijs uit te worden.

Daarbij geloof ik niet dat er écht data word verzonden, zoveel pakketjes is onmogelijk!

In ander nieuws: Ik heb nu de VMs geupdate naar Ubuntu 10.10 en dit lijkt het wat beter vol te houden (ondanks de hele lap met meldingen over "BUG: Scheduling while atomic" in de console). Toch bijten deze machines elkaar, blijkbaar...

[Battle Bunny]

Mocht iemand deze thread tegenkomen (ik had het probleem immers op VMs én op een fysieke machine): het is inmiddels opgelost door de update naar Ubuntu 10.10.

(Sorry voor de late bump, maar ik wilde de thread met een antwoord afsluiten).