nach 10GBE geht doch noch was… ODER???

Dieses mal gibt es etwas aus dem Bereich (Achtung Buzzword Bingo Bullshit!!!) „high“ Performance Networking.
Ich hatte im Rahmen einer Teststellung die Gelegenheit zwei Mellanox ConnectX-4LX 40GbE (CX4131A bzw. MCX4131A-BCAT) mit einem 3m QSFP+ (MC2210128-003) testen zu können.
Sofort Karten auspacken, in meine Testmaschine werfen und nix geht. ESXi 5.5 zeigt mir zwar die Karte an, aber nicht als Netzwerkkarte. Zweites Image mit ESXi 6.0 gestarten und… das gleiche Bild.
Ok dann halt im Passthrough Modus. Dabei zeigen sich folgende Verhaltensweisen:
Windows Server 2008 R2
Ähm… nöööö, da ging garnichts, zumindestens nicht automatisch. Nachdem ich den Treiber gefunden hatte, ging es gut. Doch wozu brauch ich 40G unter Windows in einer VM? ATTO Benchmarks auf SAN abfeuern, welches bereits wegen des Dell H310/M1015 bereits bei 600MBit/s aufgibt. Nee danke.
VMWare ESXi
Da ich kein VCenter habe und keine Lust darauf habe ein custom Image nur für diesen Test zu bauen, kann ich außer der Einleitung nichts dazu sagen.
*Ubuntu 16.04.2/Debian 8
gestartet, erkannt und funktionierte
Daher habe ich auch die weiteren Tests mit 16.04.2 gemacht.
Treiber
Lagen nicht bei, hab ich nach etwas suchen dann doch direkt beim Hersteller gefunden:
Link zum Mellanox Treiber
Benchmarks
Die waren mit einigen Hindernissen verbunden. Zuerst hatte ich als B-Ende einen Core2Quad Q8200 genutzt.
Der kam mit etwas Optimierung nur auf 17,9 GBit/s, zudem waren alle vier Kerne auf anschlag 100%.

Als nächstes habe ich dann den i3-2100 zum Testen herangezogen, welcher auch direkt ein besseres Bild zeigte (19,4GBit/s):

Diesmal war es aber iperf3, welches sich als Flaschenhals zeigte. iperf brachte da ein doch besseres Ergebnis (25,5-26,0GBit/s):

Ich merke jedoch, dass solche Hardware eindeutig für PCI Express 3.0 ausgelegt ist und ich einfach an die Limits von PCIe 2.0/2.1 stoße. Bei 10GBE ist das nämlich kein Problem.
Fazit
Mit einem „Marktpreis“ von ca. 500€ – nur Karte – ohne Kabel oder QSFP+ Modul – könnte 40GBE jetzt auch bei einem breiteren Publikum ankommen. Mir zeigte es vor allem, dass nach Dualport 10GBE nur 40GBE bzw. dual 40GBE kommen kann, PCIe 3.0 oder besser vorrausgesetzt.
Im Zusammenhang mit einem Mellanox 40GBE 12 Port Switch (MSX1012B-2BFS) geht da bereits einiges, vor allem wenn man nur noch zwei Ports braucht, um einen Nutanix/Supermicro Server mit vier Nodes á zweimal 10GBE SFP+ mit einem Kabel anzuschließen. Zudem können zwei dieser Switches auf einer Höheneinheit montiert werden.
Bei sowas kann ich mir gut vorstellen diese beiden untereinander zu verbinden und mit dem Management Switch anzubinden, dass ganze dann per 40GBE Redundant auf LWL (SMF) in Richtung Core Switch zu schicken. (Außer man macht es so wie ich aktuell und geht mit zwei QSFP+ auf SFP+ auf RJ-45 um den Management Switch anzubinden 😛 )
Schöne neue Welt 😀

ASG Uplinkausgleich & Multipathregeln

Damals als ich die Sophos SG430 eingerichtet hatte war eigentlich noch alles gut, bis ich auf die Idee gekommen bin mehrere Internetanschlüsse, damals 10MBit/s SDSL, 2MBIt/s SDSL, 6MBit/s ADSL (Annex B – Business) & 16MBit/s ADSL (Annex J), zu koppeln. Also alles über je eine Schnittstelle zur ASG geführt und die beiden SDSL und die langsame ADSL Leitung per Uplinkausgleich gekoppelt, welches zur Folge hatte, dass sich verschiedene Lastquellen, wie PACS (Radiologiebilderspeicher) und das Laborsystem, auf verschiedene Leitungen verteilt wurde. Jedoch war die Auswahl die von der Firewall getroffen wurde eher zufällig, wodurch die großen PACS Datenmengen (so ca. 18GB) über die 2er SDSL und die Labordaten (ca. 800MB) über die 10er SDSL geschubst wurden. Dieses Verhalten gefiel mir jedoch nicht so recht, weswegen ich zusätzlich zum Uplinkausgleich noch die Multipathregeln aktivierte. Diese ermöglichten mir gewisse Quellen und Dienste an gewisse Ziel-/Leitungsgruppen zu binden, welches auch bei direktem Test auch als funktional herausstellte.  Jedoch zeigte sich am selbigen Abend ein anderes Bild, denn auf einmal ging der PACS Traffic über die 600kbit/s Leitung per ADSL raus, der Labortraffic über die 2er SDSL, der Traffic zum Informationsportal über die andere ADSL (was nicht besonders war, da diese eine dynamische IP hatte und man auf IP Basis freigeschaltet wurde) und der Katzenvideotraffic* wurde über die 10er SDSL rausgeblasen. Als Ursache konnte ich den Uplinkausgleich festmachen, der auf vermutlich Layer 2 angriff und die Multipathregeln die auf Layer 3-7 ihr Unwesen trieben.

Die Lösung die ich ausarbeiten konnte, war durch das deaktivieren des Uplinkausgleich zu erreichen. Damit benötigte ich zwar mehr Multipathregeln, jedoch funktionierten diese dann wie erhofft.

*(bzw. sonstiger „Multimediatraffic“ der „Unterhaltungszwecken“ dient)

Endlich schnelleres Netzwerk 2

Nachdem ich mir im Juli 2014 den HP ProCurve 5308xl (siehe hier) geholt hatte, hatte ich bereits gesagt, dass der zu viel Strom benötigt. Demnach habe ich mir im Oktober 2014 den HP ProCurve 1810-24G v2 gegönnt. Von diesem habe ich selbst aktuell einen im Einsatz. Jedoch habe ich von diesem Modell, sowie vom HP ProCurve 1820-24G & HP ProCurve 1920-48G einige an der Arbeit in Umlauf gebracht. Gründe dafür waren hauptsächlich die HP ProCurve 4000M 100 MBit/s krücken.
Die von mir genutzten Features, neben den Switch sein, sind folgende:
– VLAN auf Port Basis
– Trunk/LACP – z.B. für die Anbindung einer NAS
– LWL Ports (jaja, alles Multimode…. Ich weiß)
Das größte Problem, welches ich jedoch mittlerweile mit meinem HP ProCurve 1810-24G v2 habe, ist, dass er nur 24 Ports hat. Daher hat sich dahinter schon wieder so eine TP-Link 5/8 Port Furunkel angesammelt. Wenn ich mit 24 Port auskommen würde, wäre das super, ebenso wie der geringe Stromverbrauch (ca. 18-28 Watt). Von der Performance her gibt es keine Probleme, die bricht auch nicht ein, wenn alle Geräte Daten haben wollen.

IPFire Raspberry Pi Benschmark

Ich wollte herausfinden, was für Hardware für einen 10MBit/s Internetuplink benötigt wird. Die Vorgabe war:
– Firewall Durchsatz ausreichend für die 10 MBit/s Leitung
– (Open-) VPN mit mindestens 1 MBit/s
– unter 100€
– muss auf die gleiche Höheneinheit passen, wie der Switch (dahinter)
Die erste Idee war, einfach einen alten Server zu nehmen, was aber durch die den Switch nicht möglich war. Also musste es kleiner werden. Nächste Idee war ein PC Engines APU.1D4 zu nehmen, ist aber zu teuer. Blieb nur ein Raspberry Pi 1 B zur Auswahl.
IPFire auf die SD-Karte, USB-LAN dran und losgetestet.
Das Ergebnis sah wie folgt aus:
– Firewall Durchsatz 27,8 MBit/s bei 10 Streams
– OpenVPN Durchsatz 2,9 MBit/s bei 1024 Bit Cert, SHA2 512 und 10 Streams
routing-durchsatz
openvpn-1k-key-sha2-512

Astaro AP 50 GW fail

Ich hab da mal wieder ein Problem oder besser „Captain Obvious, why so silent?!?“
Ist das ein Bug, ein Sicherheitsfeatcher oder kann das weg?
So ähnlich hab ich mich beim Konfigurieren von mehereren AP50 gefühlt.
Erst hatte ich sie in einem Versuchsaufbau direkt an die neue ASG SG430 angeschlossen. Dort liefen diese auch Problemlos.

ap50
Doch als ich die Dinger in das aktive Netz gehangen habe, ging nichts mehr. Die APs fanden einfach die ASG nicht. Über fast zwei Wochen habe ich dann ausprobiert woran es liegen könnte, Proxy, DNS, DHCP, VLAN, Switche. Waren es aber alle nicht.

Fehler:
Astaro AP50 wird im Management nicht gefunden.

Lösung:
Astaro zum Standardgateway für die APs machen, sonst finden sie den Server nicht.

Warscheinlich steht das auf Seite 3 im Manuel, aber nobody RTFM anyway. Ich übrigens in dem Fall bis heute auch nicht.

PS: bei mir heißen die Sophos Geräte immernoch Astaro