[10Gb] Link crasht bij MTU 9000

[FireDrunk]

In mijn thuislab (2 servers) heb ik in beide servers een Intel AF DA 10Gb NIC zitten. Deze zitten met een TwinAx SFP+ 10Gb kabel op elkaar aangesloten.

Als ik deze verbinding met een MTU instel van 1500, gaat alles prima en haal ik > 600MB/s over NFS tussen de 2 servers.
Stel ik de link in met een MTU van 9000 (aan beide kanten), crashen de kaarten en krijg ik link up/down meldingen van de kernel.

De ene kant is CentOS 6 (NFS server), en de andere kant is ESXi (Netwerk client). NFS gaat op client niveau.
Drivers zijn aan beide kanten geupdate naar de laatste versie(s).

De meldingen:

ESXi

2012-04-18T15:28:59.231Z cpu0:2634)<6>ixgbe 0000:0a:00.1: vmnic5: NIC Link is Down
2012-04-18T15:29:02.734Z cpu3:2633)<6>ixgbe 0000:0a:00.1: vmnic5: NIC Link is Up 10 Gbps, Flow Control: RX/TX
2012-04-18T15:29:03.377Z cpu2:3456)NetPort: 1426: disabled port 0x4000003
2012-04-18T15:29:03.383Z cpu2:3456)NetPort: 1239: enabled port 0x4000003 with mac 00:0c:29:fb:6c:d6
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 1
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 2
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 3
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 4
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 5
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 6
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_free_tx_queue: freed tx queue 7
2012-04-18T15:29:07.579Z cpu1:2079)NetPort: 1426: disabled port 0x4000002
2012-04-18T15:29:07.579Z cpu1:2079)<3>ixgbe: vmnic5: ixgbe_get_supported_feature: netq features supported:  NONE
2012-04-18T15:29:07.579Z cpu1:2079)Uplink: 5244: enabled port 0x4000002 with mac 00:1b:21:5f:87:86

CentOS

ixgbe 0000:03:00.0: eth2: changing MTU from 1500 to 9000
ixgbe 0000:03:00.0: eth2: detected SFP+: 0
ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: None
ixgbe 0000:03:00.0: eth2: NIC Link is Down
ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: None
ixgbe 0000:03:00.0: eth2: changing MTU from 9000 to 1500
ixgbe 0000:03:00.0: eth2: detected SFP+: 0
ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: None

Zou het aan de SFP's kunnen liggen? Ik vraag me af of een andere MTU voor een SFP van toepassing is.

Iemand een idee?

[jvanhambelgium]

600Mbytes/sec tussen 2 servers over NFS ?
Dat lijkt me zéér straf, zeker tussen 1 server met slechts 1 NFS client.
Welke versie NFS ? Of gebruik je pNFS ?

Doe je copy naar /dev/null ofzo ? Heb je NFSCache actief staan ?

Ik wil de details van deze setup wel eens zien, deze performance-cijfers heb ik nog niet gezien...


Wat je vraag betreft : neen, andere SFP's voor specifieke MTU's bestaat niet dat ik weet. De SFP zit op een andere laag qua OSI model.
Het zal eerder met driver/kernel te maken hebben dat er bij deze MTU size toch iets mis gaat ;-)

[FireDrunk]

Nee, tussen 2 RAID array's (1 van 8*2TB, en 1 van 6*2TB).

Server A:
2 x Xeon E5520, 24GB RAM, 8 * F4EG aan een M1015 in RAID6 geformatteerd met Ext4.

Server B:
Xeon X3440, 12GB RAM, ESXi VM met een M1015 doorgegeven via VT-d met 2 * F4EG en 4 * Seagate 2TB in RAID6.

De server piekt op 600MB/s, dat is niet constant. Constant is ongeveer 350/400MB/s

[Kabouterplop01]

Misschien is de mss die onderhandeld wordt niet groot genoeg voor zo'n jumbo frame.
De vraag is natuurlijk waarom dat gebeurt (buiten het feit dat die throughput wel kinky veel is )
Ik meen ergens eens een site te hebben bezien waarmee je je max mtu kon uitrekenen a.d.h.v mss in een capture.
de mtu is over het algemeen 40 bytes groter dan de max mss (20 bytes ip header en 20 bytes tcp header overhead)
Volgens mij zou je eens moeten proberen om een kleinere Jumbo te configgen.
Ik kan me niet voorstellen dat er (x) of sfp's bestaan met regelbare mtu, dat is zoals gezegd in een andere OSI laag.

[FireDrunk]

Op de site van Intel:

If you have a 10GbE adapter installed in an Intel I/OAT capable system with direct cache access enabled, do not enable 9K jumbo frames on Windows Server 2008*. Doing so may cause the system to reboot under normal to heavy receive traffic.

En:

Jumbo frames on the network
All devices on the network must be configured to handle the maximum size frames sent and received or jumbo frames will be blocked. Enable jumbo frames only if devices across the network support them and are configured to use the same frame size.

When setting up jumbo frames on other network devices, note that different network devices calculate jumbo frame sizes differently. Some devices include the header information in the frame size while others do not. Intel adapters do not include header information in the frame size.

When configuring jumbo frames on a switch, set the frame size four bytes higher for CRC, plus four bytes if using VLANs or QoS packet tagging.

In Linux*, set the switch 22 bytes higher. The switch may be configured for a larger size as long as the setting is at least 22 bytes higher.

Nou gebruik ik geen 2k8, maar de omstandigheden zijn wel hetzelfde. Mijn bord ondersteund wel I/OAT, en volgens mij staat het in het BIOS ook aan voor zover ik weet.

Nu vraag ik me alleen af wat ESXi (staat op 9000) doet samen met de Ubuntu VM (die ook op 9000 staat).

Ik heb even gekeken naar het berekenen van die MTU, maar ik vind het allemaal niet duidelijk

[ Voor 56% gewijzigd door FireDrunk op 19-04-2012 08:43 ]

[Uberprutser]

FireDrunk schreef op woensdag 18 april 2012 @ 17:36:
Als ik deze verbinding met een MTU instel van 1500, gaat alles prima en haal ik > 600MB/s over NFS tussen de 2 servers.

Iemand een idee?

Lekker op 1500 laten staan, heb zelf een week lang zitten prutsen met een aantal NetApp's, een stapel ESXi servers en een paar Nexus switches.

Het is leuk dat je 10Gbit hebt maar die 600MB/s is niet mis, zeker niet zonder switch ertussen.

[FireDrunk]

Na *heel* veel tests (en een beetje geluk) heb ik het opgelost!

Tijdens het lezen van de README.txt die bij de ixgbe driver zit, kwam ik bij een stuk over Large Recieve Offloading. Daar werd heel duidelijk vermeld dat als je een bridge had je deze optie uit moest zetten omdat dat problemen kon geven.

Nadat ik in mijn CentOS bak rmmod en modprobe ixgbe LRO=0 heb gedaan, blijft de link netjes up