port aggregation und so (SPAM aus dem BUMP-Thread :))

[Protoberance]

Alter, ich soll hier mit einem Plastik Klickbunti Alice Home Router einen sicheren !!!!! VNC und SSH Zugang auf ein Demo System realisieren,

ich kann nichtmal ne static Route eintragen und von VLAN oder subnetting ist nur zu träumen. FUFFUFUFUFUFFUFUFU

Notlösung, Solaris Server hoffentlich ist der Kunde zu blöd das zu bedienen.

Bearbeitet 10. Dezember 2012 von mad.gobbo

[mad.gobbo]

Alice ist aber auch wirklich der ideale Provider für möglicherweise kritische Anwendungen .... eindeutig das falsche Werkzeug

[Kneipi]

klingt nach spaß proto....

alice home managed services

[mad.gobbo]

Klickibunti ist für Consumer. Als ich früher noch DSL-Zeitanschlüsse für Tagungen brauchte, hatte ich immer einen eigenen Satz Router im Einsatz und habe den Consumer-Schmutz ungeöffnet nach den Events zurück gegeben.

[Protoberance]

Deswegen setze ich nun auch MTU bei der 10GBase Karte auf OVER 9000 !!!!

[Kneipi]

ich setz mtu imm auf 576 um isdn werte zu simulieren, bin halt nostalgisch xD

[Protoberance]

aggr510:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 6000 index 12

inet 192.168.2.6 netmask ffffff00 broadcast 192.168.2.255

so schauts auf beiden Seiten aus, aber es gehen nur 9.13 Gbit/s durch, hmpf. Dabei sollten brutto 20 Gbit/s gehen.

[mad.gobbo]

netter overhead Oder die 20 sind Marketingaussage

[Nuwien]

linux? bsd? tcp? udp? puffergrößen? was für ne anwendung ? multiqueue treiber? wenn ja die queues auch auf unterschiedliche cpu gebindet?

edit: brutto 20G, ist das nen port channel/LACP/Link aggregation?

Bearbeitet 10. Dezember 2012 von Nuwien

[Protoberance]

OpenIndiana, also luminos Kernel. TCP, 64k socketbuffer, iperf als Test. Bei den Treibern muss ich passen und erstmal nachforschen. Es werden zwar beides CPU zu 80 % belastet ( Xeon E5 2620 ), aber auch da muss ich genauer nachsehen.

edit :

Die NIC ist ein mezzanine board, was nur auf den PCIe Bus der 2. CPU geht, zumindest elektrisch.

Bearbeitet 10. Dezember 2012 von Protoberance

[Raven]

bahnhof...

[Nuwien]

OpenIndiana, also luminos Kernel. TCP, 64k socketbuffer, iperf als Test. Bei den Treibern muss ich passen und erstmal nachforschen. Es werden zwar beides CPU zu 80 % belastet ( Xeon E5 2620 ), aber auch da muss ich genauer nachsehen.

edit :

Die NIC ist ein mezzanine board, was nur auf den PCIe Bus der 2. CPU geht, zumindest elektrisch.

isses nun ne port aggregation oder ne exotische nic die wirklich 20G pro port kann? wenn es port aggregation ist und keine 10G+ durchgehen würde ich tippen das es nen balancing problem ist (dstmac -> srcmac gleich -> gleicher hash -> gleiches if)

wie sieht denn die interrupt last der zweiten cpu aus? bei jumbo frames sollte die ja nicht so hoch sein. hat der PCIe genügend lanes für die 20G ?

[Protoberance]

Das Problem könnte wirklich der PCIe Bus sein. Das Mezzanine Board funktioniert z.B. nur, wenn man eine 2. CPU im System hat. Aber die CPU kontrolliert

schon einen HostBusAdapter für externes SAS. Auf der Platine sind 2 10Gbase Anschlüsse. Die habe ich mit Port Aggregation verbunden. Oder liegt es daran, dass die NIC ohne Switch quasi im "Crossover" verbunden sind ? Ich habe auf der NIC die Ports gegeneinander auf 16 Gbit/s gemessen, also mehr oder weniger die Backplane gemessen

[Nuwien]

Das Problem könnte wirklich der PCIe Bus sein. Das Mezzanine Board funktioniert z.B. nur, wenn man eine 2. CPU im System hat. Aber die CPU kontrolliert

schon einen HostBusAdapter für externes SAS.

gibts sowas wie "/proc/interrupts" ? wenn ja wie schaut denn da die verteilung aus (hab nur wenig plan von solaris, linux-kenntnisse lassen sich nicht immer übertragen).

Auf der Platine sind 2 10Gbase Anschlüsse. Die habe ich mit Port Aggregation verbunden.

ok wie ist die port aggregation geconft? wenn ich das richtig lese ist die einstellung bei illumos "link aggregation policy". wenn die auf l2 oder l3 steht solltest du bei host-to-host immer nur auf <10G kommen, srcmac/dstmac srcip/dstip ist immer gleich, also wird nur ein physical link genutzt.

zum test -> stell mal L4 ein und starte mindestens 2 mal iperf mit unterschiedlichem source/destination port.

zum test2 -> brich den port channel auf, jedes interface ne eigene ip im eigenen subnetz. zwei mal iperf auf jeweils ein interface. damit solltest du zumindest rausbekommen ob du jedes interface einzeln halbwegs auslasten kannst (und somit combined auf 10G+ kommst)

[Protoberance]

zum test -> stell mal L4 ein und starte mindestens 2 mal iperf mit unterschiedlichem source/destination port.

zum test2 -> brich den port channel auf, jedes interface ne eigene ip im eigenen subnetz. zwei mal iperf auf jeweils ein interface. damit solltest du zumindest rausbekommen ob du jedes interface einzeln halbwegs auslasten kannst (und somit combined auf 10G+ kommst)

Ist auf L2 eingestellt, morgen auf der Arbeit teste ich das mal, danke dir erstmal.

[Protoberance]

Habe es nun auf L4 gestellt, hat aber gefühlt nichts gebracht. Vielleicht 50 mbit/s.

Mir ist aber aufgefallen, dass ich 2 verschiedene Maschinen habe beim Test. Ein System arbeitet noch mit PCIe 2.0 und die NIC hat nur 4 lanes.

Das setup kriegt also maximal 2000 MB/s hin... brutto.

[Kneipi]

die 2000 MB/s hätte ich gerne zu Hause

[Protoberance]

2 NIC + 1 Kabel, da bist du derzeit mit ca. 800 Euro dabei.

[Protoberance]

Bei Jumboframes MTU 9000 mit L4 Policy komme ich auf 12,1 Gbit/s.-> 1512.5 MB / s

[Nuwien]

Das ist doch mal nen Fortschritt und klarer Sprung über die 10G Marke. Bei dem 4Lane-System wärst immerhin schon bei 75% PCIe-Auslastung, die Timing-Probleme werden somit nur noch größer werden was sich wiederum nicht gerade Positiv auf TCP auswirkt. Wenn du auf 80-85% kommen würdest, wäre das finde ich schon ein recht guter Wert.

Nun wirds schwer.

1) Schau dir die Socketbuffer an. Hat der illumos kernel TCP-Autotuning? Wenn ja wie sehen die max-werte für die Socketbuffer aus? 64k als initial ist okay, aber nur wenn die Max-Werte gross genug sind.

(vgl Linux

$ cat /proc/sys/net/core/rmem_default

$ cat /proc/sys/net/core/rmem_max

).

Mal das Bandwith-Delay-Product ausgerechnet? Die RTT bei direktverkabelung dürfte zwar weit unter 1msec liegen aber bei 20G Bandbreite kommt da dennoch was zusammen so daß die TCP-Defaults wohl nicht mehr ganz passen werden.

2) Was sagt denn "ifconfig <ethX>" ? Hast du Drops? Overruns? Wie sind die RX-Ring-Parameter der NIC ? (vgl. Linux -> ethtool -g|--show-ring ethX ). Ggf die Ring-Parameter anpassen.

3) Zu guter letzt, wasn das fürn NIC-Chipsatz? Intel? Broadcom oder was interessantes wie Myricom? Nach http://hub.opensolaris.org/bin/view/Project+crossbow/nic sollte der ixgb Treiber für Intel alle interessanten sachen unterstützen -> Stichwort MSI-X, RSS, multiple Hardware RX-Rings.

[Protoberance]

Ich habe heute leider keine Zeit mehr darauf einzugehen, weil das System morgen verschifft wird und eigentlich nur die Funktionalität der NIC getestet werden sollte.

Die Config wird der Kunde hinterher wohl selber anpassen müssen, weil seine Umgebung eine andere ist. Aber ich habe noch weitere Maschinen mit PCIe 3.0 fähigen Boards und Prozessoren in der Warteschleife, bei denen man sicherlich den PCIe Bus als Bottleneck ausschließen kann.

Die NIC hat einen Intel 82599 Chip, damit könnte ich den Treiber auch ausschließen. TCP Autotuning sollte eigentlich vorhanden sein.

Die übrigen Punkte gehe ich morgen mal durch, wenn nichts dazwischen kommt Vielen Dank erstmal für die Hilfe, so langsam taste ich mich heran.

[Protoberance]

Nächste Woche bekomme ich einen weiteren Server zum Testen + Switch mit 4 SFP+ Ports.

Dann haben beide Server PCIe 3.0 und die komplette Infrastruktur unterstützt LACP.

Ist es eigentlich wichtig ob das Aggregat auf node #1 auf active und node #2 auf passive steht ?

[Nuwien]

Ist es eigentlich wichtig ob das Aggregat auf node #1 auf active und node #2 auf passive steht ?

Kannst du das Umformulieren? Irgendwie raff ich deine Frage nicht.

[Protoberance]

Ich benutze einfach das Zitat hier zur Erklärung, bin zu müde um selber nachzudenken

LACP works by sending frames (LACPDUs) down all links that have the protocol enabled. If it finds a device on the other end of the link that also has LACP enabled, it will also independently send frames along the same links enabling the two units to detect multiple links between themselves and then combine them into a single logical link. LACP can be configured in one of two modes: active or passive. In active mode it will always send frames along the configured links. In passive mode however, it acts as "speak when spoken to", and therefore can be used as a way of controlling accidental loops (as long as the other device is in active mode)

Sollte ich beide "units" auf Active schalten ?

[Nuwien]

ach soo, ja logisch. passive/passive funzt logischerweise nicht. active/active sollte okay sein, allerdings habe ich dazu auch keine best practices gefunden bzw gründe wieso man nicht active/active machen sollte. den switch auf passive und den client auf active dürfte aber aufs gleiche raus kommen. (in der doku zum linux bonding treiber finde ich z.B. gar keine Info bezüglich passive lacp, denkemal das is dort eh dauer active sofern man den 802.3ad mode nutzt, einzig die rate lässt sich via 'lacp_rate' beeinflussen und das auch nur sehr rudimentär.)

Bearbeitet 24. Januar 2013 von Nuwien