/ mrmcd

NOC Bericht von den MRMCD 2016

Nach den diesjährigen MRMCD wurde ich von Zaunei und Andi darauf angesprochen, wie das denn dieses Jahr mit dem Netzwerk auf den MRMCD war. Da ich versprochen hatte, dazu etwas zu schreiben, will ich dem auch nachkommen.

Kurz dazu wie ich überhaupt damit in Verbindung stehe: Seit aktuell 4 Jahren bin ich an der Orga der MRMCD, einer CCC IT-Security Konferenz, in Darmstadt beteiligt. Dieses Jahr kümmerte ich mich zum zweiten mal auch um das Netzwerk auf der Veranstaltung. Unterstützung hatte ich dabei durch Docsteel. Danke nochmal dafür!

Da wir letztes Jahr erst recht kurzfristig das Netzwerk übernommen hatten und es daher zu allerlei Problemen kam, wollten wir dieses Jahr rechtzeitig mit der Planung anfangen. Gesagt getan, etwa zwei Wochen vor Beginn stand der Plan, wie alles aussehen sollte. Es waren also, VLANs, Trunks, LACP Bündel und WLAN geplant. Auch die meiste Hardware stand bereit (viel aus dem Freifunk Rhein-Neckar Event Hardware Pool), sodass wir schon vorher mit dem Setup der Installation anfangen konnten.

Als Kernkomponenten hatten wir einen EdgeRouter Pro, einen 24 Port PoE EdgeSwitch und einen 24 Port TP-Link Switch (TL-SG3424). Das Setup hat auch so weit gut funktioniert, allerdings sind uns dabei bereits zwei Probleme aufgefallen. Eines der Probleme ist, dass der EdgeRouter Pro nicht in der Lage ist, Hardware Offloading für LACP zu machen. Dadurch sinkt die Bandbreite auf dem Bündel auf etwa 350Mbit/s bis 400Mbit/s. Das ist leider nicht so wirklich toll. Daher haben wir dieses Bündel recht schnell aufgelöst und nur noch einen Port zwischen EdgeRouter und EdgeSwitch gehabt. Damit waren dann auch die 1Gbit/s fast möglich, die wir als Uplink über MAN-DA zur Verfügung hatten.
Das zweite Problem war, dass der EdgeRouter (weiter ER) auf einem Bond Interface nur LACP spricht, der EdgeSwitch (weiter ES) aber im Default Port-Channel. Das funktioniert dann sogar, zumindest etwas. Leider führt es zu sehr sehr schwer zu debuggenden Problemen die mich im Vorlauf einige Zeit gekostet haben. Aber hey, man lernt etwas dabei!

Am Ende war der ER so konfiguriert, dass auf dem einen Interface die entsprechend benötigten VLANs auflagen und über den als Trunk eingerichteten Port auf den ES geleitet wurden. Außerdem war auf dem ER noch DHCP, radvd, NAT und Routing (nur eine Default Router für IPv6 und IPv4) eingerichtet. Zuletzt auch noch eine Firewall um die Netze voneinander zu trennen.

Nachdem das alles eingerichtet war, und die Probleme aus dem Weg geräumt waren, wurde das WLAN eingerichtet. Dabei haben wir 10 UAP-AC-Pro, 3 UAP-AC und 1 UAP-AC-Lite (fürs NOC) eingesetzt. Ausgestrahlt wurde darüber unser Patienten Netzwerk (SSID: "Radiologie") und das abgeschirmte Speaker Netzwerk (SSID: "Golfplatz"). Als Controller haben wir dabei einen Cloud-Key mit Unifi-Controller eingesetzt.

Zuletzt gab es noch den TP-Link Switch der die 3COM 48Port Gigabit Switche in den zwei Hackcentern versorgt hat.


Nachdem wir bereits am Donnerstagabend (Tag 0) ein lauffähiges Netzwerk mit WLAN hatten, mussten wir am Freitag und Samstag noch ein wenig nacharbeiten. Damit kommen wir auch schon zu dem Problemen, die uns während dem Betrieb aufgefallen sind.

Als Erstes hatten wir das Problem, das der DHCP Server auf dem ER nur sehr langsam IP Adressen ausgegeben hat. Das liegt daran, das dieser defaultmäßig nicht im autoritativen Modus läuft. Dieser lässt sich aber mit folgendem Befehl aktivieren:

set service dhcp-server shared-network-name DHCP-POOL-NAME authoritative enable

Als Nächstes haben wir gemerkt, dass, ebenfalls im Default, das Hardware-Offloading des ER deaktiviert ist und so sehr viele Netzwerk-Operationen auf der CPU durchgeführt wurden. Das wiederum hat den Durchsatz stark beeinflusst. Das ließ sich aber mit aktiveren des Hardware-Offloading beheben:

set system offload ipv4 forwarding enable
set system offload ipv4 vlan enable
set system offload ipv6 forwarding enable
set system offload ipv6 vlan enable

Weiter ging es damit, dass das Logging bestimmter Pakete standardmäßig aktiviert ist. Da dies die CPU unnötig belastet, musste auch hier eine ungünstige Default-Einstellung deaktiviert werden.

Dann hat sich gezeigt, dass das Connection Tracking ebenfalls im Default mit sehr niedrigen (Linux Standard) Werten belegt ist, zumindest für einen Router. Das haben wir auch wieder gefixt, in dem wir das Maximum dafür hochgesetzt haben, allerdings haben sich dadurch die Probleme nicht direkt gelöst. Das lag an einem Patienten der mit 1Gbit/s SYN Pakete über den Router geschickt hat, vermutlich ein Portscan. Nachdem wir das auch gelöst und den Nutzer gebeten hatten, das in Zukunft zu unterlassen, lief es wieder. An der Stelle hätten wir das Connection Tracking auch für die öffentlichen IP Bereiche deaktivieren können, das haben wir wegen der etwas zickigen Firewall auf dem ER dann aber nicht gemacht.

Als letztes Problem im Kernnetzwerk hatten wir noch, dass der ER trotz Änderungen am DHCP Server noch immer relativ langsam war. Daher ist geplant diesen in Zukunft vom ER auszulagern.

Das WLAN Netz hat weitestgehend zuverlässig funktioniert, jedoch gab es auch hier Probleme. Zeitweise hatten wir eine Störung auf dem Radius Server der die "Radiologie" bedient hat, wodurch eine Authentifizierung nicht mehr möglich war, das ließ sich jedoch recht schnell fixen.

Nerviger war da schon das Problem, dass uns DFS auf den Unifi APs beschert hat. Dieses, fast überall durch den Gesetzgeber vorausgesetzte Feature, ist bei diesen Geräten erst seit Kurzem in der Software verfügbar und daher scheinbar noch nicht ganz stabil. So sind einige APs immer im DFS Mode hängen geblieben, sodass sie kein 5GHz Netz ausgestrahlt haben. Hier mussten wir dann manuell nachsteuern in dem wir diese auf entsprechende, DFS freie, Indoor Kanäle gestellt haben.

Zuletzt hatten wir in einem Vortragsraum das Problem, dass die Clients dort nicht in der Lage waren, sauber die Übertragungsrate auszuhandeln. Daher hatten wir dort am Anfang immer wieder größere Störungen beim WLAN. Leider hat auch das Tauschen der Hardware nicht geholfen. Zuletzt haben wir den AP ganz deaktiviert und die anderen APs haben übernommen. Die Ursache ist hier noch nicht wirklich geklärt.

Das waren auch alle Probleme, die so aufgetreten sind. Zwischen drin haben wir nur noch Kleinigkeiten verändert. Seit Samstag Nachmittag lief das Netz dann stabil, sodass wir keine Änderungen mehr vornehmen mussten.


Letztlich haben die Patienten der Veranstaltung 5TB an Daten über den Uplink der Veranstaltung übertragen, davon 2TB über das WLAN Netz. Ausgelastet war unser Uplink dabei eigentlich fast nie. Für die internen Datenübertragungen haben wir keine genauen Zahlen.

Wir hatten etwas mehr als 250 Clients zu Spitzenzeiten in unserem WLAN Netz von denen etwa 1/3 im 5GHz Netz waren und der Rest im 2,4GHz Netz und das trotz 5GHz Bandsteering.

Die aktivsten APs standen wie zu erwarten in den Hackcentern und wurden da insbesondere nachts zu 100% ausgelastet. (Hint, Kabel wäre trotzdem schneller gewesen).

Alles in allem hat das Setup gut funktioniert und wir freuen uns schon auf das nächste Jahr mit neuen Bugs. Und bei der Gelegenheit: USE MORE BANDWIDTH!!!