Deutsche Übersetzung weiter unten.
New switches needs our LAN(d)
In 2021 we did not have a lot of "big" technical projects because of the covid pandemic. But right with the start of 2022 we started our process to chose new hardware for our network. The needed access hardware is used to connect our members in the dormitory to our network. In total we will need around 260 devices to cover everything.
Our current hardware is way over their expected lifetime but before there was no reason to change them from a technical perspective. We did not see any real innovations on the market until now. Also the first devices started to fail due to age related problems like failed fans, failed power supplies and failing storage chips. Also the vendors support will end in 2024 so we would not be able to fix any software issues or security vulnerabilities afterwards. Furthermore several new (larger) dormitories will be connected to our network which will need additional devices.
Therefore we are now at the perfect point of time to discuss a new access switch model. Of course we also want to integrate the new technologies of these platforms while we are at it. On the road map are features like being able to use multi-gigabit network devices or the Selfnet-PPSK-WLAN (currently in planning) which may allow to create a layer 2 network connection between the Selfnet WLAN and the network in the dormitory rooms. This would present the possibility to use in-room-streaming or using local wireless printers in your room.
Oh but all the choices to make...
In January we started to send our critera (which we created before) to different network vendors/suppliers. We expected to get back a suggested model and a short (at least by Selfnet standards) questionarie. We selected several vendors that were able to meet our criteria. This step is already completed and the vendors are currently providing us with demo equipment which we will test accordingly.
The vendors we selected are: Arista, Aruba/HP, Extreme Networks, Huawei und Juniper.
For each we selected models that provide all the features we asked for. That is mainly the multi-gigabit ports and VXLAN as an overlay feature. All features we currently use are set as basic requirements.
Current Demo Equipment (Top: Juniper EX4400, Middle: EX3300 (current model we use), Bottom: Arista 720XP)
This procedure is an interesting exercise in knowledge transfer as - even for us - it is not usual to have that many different models and vendors on our hands for experimenting.
It will still take several weeks until our tests are finished, propably until the end of May. Hopefully we can also integrate some devices into our active network to see how they behave in "real world" conditions. It is possible that we will replace access switches on a short notice (mainly the Vaihingen area).
But as we are volunteers working in our spare time we cannot provide any finished "timetable". But this also means: If you're interested in tech and/or networking you can just drop by and help out. We're always looking for interested people who want to join us, and shape our network.
We hope to have a decision within this year and maybe get the first new devices to install - but as soon as we know more about this, there will be another update.
Deutsche Übersetzung
Im Jahr 2021 haben Pandemiebedingt im Verein technisch wenig große Umsetzungen stattgefunden. Frisch zum Jahresbeginn 2022 haben wir mit der Auswahl neuer Hardware für Access-Switche begonnen. Dies sind die Geräte, mit denen wir die Anschlüsse unserer Mitglieder in den Wohnheimen bereitstellen. Insgesamt geht es dabei um eine Menge von circa 260 Geräten.
Die alten Geräte sind mittlerweile deutlich länger als die geplante Laufzeit in Betrieb. Bisher gab es jedoch keinen technischen Grund die Geräte zu tauschen. Deutliche Technologie-Neuerungen gab es auf dem Markt in den vergangenen Jahren nicht. Mittlerweile hat sich diese Situation geändert und es gibt vermehrt technische altersbedingt auftretende Probleme. Dazu gehören defekte Lüfter, Netzteile und ausfallende Speicherelemente.
Auẞerdem wird der Softwaresupport für die eingesetzten Geräte Mitte 2024 enden. Sicherheitsprobleme könnten danach nicht mehr auf unseren alten Geräten behoben werden. Zusätzlich werden in den nächsten Jahren auch mehrere größere Wohnheime mit einem Bedarf an weiteren Geräten angeschlossen.
Dementsprechend sehen wir nun genau den passenden Zeitpunkt um über ein neues Modell zu diskutieren. Soweit es uns möglich ist wollen wir gleichzeitig versuchen neue Technologien mit der neuen Plattform zu integrieren. So stehen auf dem weiteren Horizont beispielsweise die Nutzung von Multi-Gigabitanschlüssen oder die Verbindung zu einem in der Planung befindlichen Selfnet-PPSK-WLAN. Mit der richtigen Technologie auf den Switchen könnten dann Layer 2 Verbindungen zwischen Selfnet WLAN und Zimmernetzen hergestellt werden. Das ermöglicht das einfache Streamen oder drucken aus dem WLAN an Geräte, die im Zimmer angeschlossen sind.
Wer die Wahl hat....
Im Januar haben wir die von uns lange erarbeiteten Kriterien an die verschiedenen Gerätehersteller versendet. Als Antwort haben wir einen Modellvorschlag und einen ausgefüllten kurzen (für Selfnet verhältnisse :) Fragebogen erwartet. Aus diesen Antworten haben wir Hersteller ausgewählt, die unseren Anforderungen entsprechen. Inzwischen ist der Schritt abgeschlossen und die ausgewählten Hersteller stellen uns aktuell Testgeräte zur Verfügung. Die Geräte werden dann von uns auf verschiedene Aspekte getestet.
In die engere Auswahl geschafft haben es fünf Hersteller: Arista, Aruba/HP, Extreme Networks, Huawei und Juniper.
Jeweils haben wir uns für die Tests für Modelle der Hersteller entschieden, die alle unsere Wunschfunktionen an neuen Features unterstützen. Dabei geht es vor allem um Multigigabit auf allen Ports, sowie um die Funktion VXLAN. Die bereits eingesetzten Funktionen werden von uns natürlich als Grundlage erwartet.
Momentanes Testequipment (Oben: Juniper EX4400, Mitte: EX3300 (Momentanes Modell), Unten: Arista 720XP)
Der Gerätetest ist natürlich für uns ebenfalls eine Interessante Angelegenheit aus dem Bereich der Wissensvermittlung. Die Gelegenheit mit so vielen verschiedenen Switchmodellen und Herstellern zu experimentieren gibt es bei uns auch nur selten.
Bis die Tests abgeschlossen sind wird es noch vermutlich mehrere Wochen dauern. Die letzten Geräte werden vermutlich bis in den Mai bei uns sein. Optimalerweise werden wir die Geräte auch testweise ins aktive Netz integrieren um das Verhalten unter "realen Bedingungen" zu beobachten. Möglicherweise kann es daher bei einigen Wohnheimen (vor allem am Campus in Vaihingen) einige kurzfristige Gerätewechsel geben.
Da wir aber letztendlich alle ehrenamtlich und in unserer Freizeit diese Arbeit übernehmen, kann man hier leider keinen festen Zeitplan definieren. Das heißt aber auch, dass jeder der sich für das Thema interessiert gerne bei uns vorbei schauen und mit helfen kann. Wir suchen immer interessierte Leute, die das Netzwerk mitgestalten wollen.
Prinzipiell hoffen wir das noch dieses Jahr eine Entscheidung getroffen wird und vielleicht auch schon die ersten Geräte eingebaut werden können. Sobald wir so weit sind wird es noch eine genauere Ankündigung geben.
Deutsche Übersetzung weiter unten.
Our "new" network map is public now which shows the current situation in our (internal) network.
But we also want to describe the path how this project came into existence.
Some years ago several members visited the Gulasch-Programmier-Nacht in Karlsruhe. As a project there they used a Javascript-Library VivaGraphJS, which is a graph rendering engine also used to display molecules, to visualize networks.
Originally the just wanted to know how our network "looks". The point about the funny movable map that resulted from the rendering engine naturally increased the fun factor.
Some years later another member built a Perl script (because he wantet to learn Perl) to scan our internal network automatically and collect the neighor relations between the devices.
This script utilizes SNMP queries to our devices and asks for the LLDP Neighbors.
SNMP (Simple Network Management Protocol) is usually used by us to check for usage informations like temperature, cpu usage or network traffic. But it can (with sufficient privileges) also query a lot more information.
This information includes the LLDP (Link Layer Discovery Protocol) data of the device. LLDP is utilizing a lower network layer between configured devices (even before using IP addesses) to exchange basic information between devices. It includes the hostnames or the connected ports. So this can also used to find physical faults in connections.
An Example
Local Interface Parent Interface Chassis Id Port info System Name
ge-0/1/2.0 - xx:xx:xx:xx:xx:xx ge-0/1/0.0
These resulting script data was just used to find missing links or single points of failure (via a script).
The last years we connected those two projects in our network map. The first versions are from 2016 and were used for internal debugging and visualization. Since December 2017 the project is developed in our internal GitLab but only as a "tinkering project" and not as something productive. With the map you could (for example) after bigger network changes or new dormitories check for the network structure and if somewhere fibers are missing or connected in a wrong way.
Meanwhile the project has evolved and several people are using it for debugging or just to understand how our network works.
Thats the reason why we automated it now, "brighten it up" and added several features. Now you can also see the speed of links between devices in colorcode or differentiate hosts by type. The last was quite important as the map became crowded after we added our wireless access points to it.
Cutout of the network map
So for transparancy reasons (and so everybody can have a look how our network is connected) we now published the map on our Website. Direct Link
Of course there are still some small bugs we hope to eliminate as soon as possible.
Thanks to all of our members who helped in any way to realize this project.
Do you want to participate in taking care of such problems in the future? For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.
If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).
The Selfnet-Team
Deutsche Übersetzung
Die Selfnet Netzwerk-Karte
Mittlerweile ist unsere interaktive Netzwerkkarte öffentlich geworden, mit der man den momentanen Zustand unseres (internen) Netzes besser nachvollziehen kann.
Wir möchten euch aber auch den Weg aufzeigen, wie diese Entwicklung über die Jahre entstanden ist.
Vor einigen Jahren auf einer Gulasch-Programmier-Nacht in Karlsruhe eine Javascript-Library (VivaGraphJS zur Graphendarstellung, die unter anderem in der Moleküldarstellung genutzt wurde, anzupassen um Netzwerke zu visualisieren.
Ursprünglich war der Gedanke nur, dass man mal "sieht" wie unser Netzwerk eigentlich aussieht. Das die Karte lustig durch die gegend "gebobbelt" werden konnte hat den Spaßfaktor natürlich erhöht :)
Einige Jahre später hat ein anderes unserer Mitglieder ein Script in Perl gebaut (weil er Perl lernen wollte), dass unser Netzwerk automatisch untersucht und Nachbarbeziehungen erfasst.
Dies funktionierte über Anfragen an unsere Geräte per SNMP, welche die Nachbarbeziehungen per LLDP abgefragt haben.
SNMP (Simple Network Management Protocol) ist dabei ein einfaches Netzwerkverwaltungsprotokoll, dass wir eigentlich benutzten um zum Beispiel Auslastungsinformationen wie Temperatur, CPU-Last oder Traffic auszulesen. Dieses Protokoll kann aber (mit den richtigen Benutzerdaten) auch andere Informationen abrufen.
Diese Informationen umfassen die LLDP (Link Layer Discovery Protocol) Daten des Gerätes. LLDP funktioniert dabei zwischen konfigurierten Geräten auf einer der untersten Netzwerkebenen, noch bevor IP-Adressen benutzt werden und tauscht zwischen verbundenen Geräten Informationen aus. Diese Informationen beinhalten zum Beispiel den Hostnamen oder auch den angeschlossenen Port. Dies kann daher auch dafür genutzt werden, physikalische Fehler in Verbindungen zu finden.
Ein Beispiel
Local Interface Parent Interface Chassis Id Port info System Name
ge-0/1/2.0 - xx:xx:xx:xx:xx:xx ge-0/1/0.0
Diese Daten wurden ursprünglich dann nur genutzt um fehlende Verbindungen oder fehleranfällige Knotenpunkte zu finden (per Script).
Die letzten Jahre wurde dies dann "verheiratet". Die ersten Versionen sind von 2016 und wurden dann fürs interne Fehlersuchen und zum visualisieren genutzt. Seit Dezember 2017 ist dies Projekt bei uns im internen Gitlab verzeichnet, allerdings eher als "Bastelprojekt" und nicht als "produktives Projekt". Mithilfe der Karte konnte man beispielsweise nach großen umbauten oder neuen Wohnheimen feststellen, ob irgendwo Glasfasern falsch gesteckt sind oder Verbindungen noch fehlten.
Mittlerweile hat sich das Projekt aber soweit entwickelt, dass mehrere Personen das zum debugging oder zum verstehen des Netzwerkes genutzt haben.
Daher haben wir das Projekt jetzt automatisiert (das man es als Script ausführen kann) und auch etwas "aufgehübscht" und weitere Features eingebaut. So kann man jetzt auch per Farbe die Geschwindigkeit der Verbindungen erkennen, Hosts nach Typ erkennen oder einzelne Sachen nacheinander einblenden. Letzteres war ein wichtiger Punkt nachdem wir angefangen haben die WLAN-Accesspoints aufzunehmen, da die Karte einfach unglaublich komplex wurde.
Ausschnitt der Netzwerkkarte
Aus Gründen der Transparenz für unsere Mitglieder (und damit jeder mal sehen kann wie das alles aussieht) haben wir die Karte nun auf unserer Webseite eingebunden. Direkter Link
Natürlich gibt es noch einige kleinere Probleme, die wir hoffen bald beheben zu können.
Wir danken hiermit allen Mitgliedern, die bei der Realisierung des Projektes beteiligt waren.
Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.
Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).
Das Selfnet-Team
Deutsche Übersetzung weiter unten.
Maybe you have noticed it throughout last weekend - we had several issues with our network stability.
Friday we started upgrading software on several core routers. That's why we first thought the necessary reboots caused the problems. But the interruptions did not stop after the update was complete and even got worse.
A reason were several messages like this
vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC
or this
vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding
This caused lags, unresponsive and even unreachable devices. As we are using routing protocols to manage our traffic (OSPF and BGP) which require constant communication between the devices. As a result our devices can select the optimal path to send packets. So the unresponsive devices caused routing changes in the network protocols as the backups links took over.
As soon as the backup links took over the affected devices became reachable again and the routing changed back to the primary path. This repeated between 3 and 20 times and took between 30 seconds and 20 Minutes.
Finding the the Root Cause
The logs showed an activation of the devices DDoS-Protection measures, repeating messages like the ones above and dying OSPF- or BGP-connections.
The sporadic nature of this problem made it complicated to debug. You needed to be permanently present to notice the problem when it started and before it was over to run several commands to obtain log files and debug information.
First we thought there was a configuration difference between our two NAT servers, as the traffic was handled by one device when we started upgrading and by the other afterwards. But we could disregard this theory shortly after since the other device showed the same behaviour.
Another possible cause could have been the connection between the routers and the NAT servers but we were also able to verify that the setup was correct.
Directly after the incident started, it was more or less obvious for us the DDoS-Protection was just a symptom but not the cause. It was the same as with the Juriper-Bug. So we followed the same investigation pattern: Looking at the packets sent through the NAT when the lags started.
The result were a lot of packets to "event.selfnet.de", the public IPv4 NAT-Address for the wireless network we use at public events. Around 2.2% of the 3 seconds we took as a sample were directed to this IP. It was a mixture of UDP and a lot of NTP packets. This caused some concern. UDP could be explained with some former unknown - still active - access point. But there should be nobody using this IP for NTP updates.
So we looked at the source of the packets. Some were from a german vServer provider but the NTP-Packets originated mainly from China-Telecom... weird, why should they go around the globe to call us for a NTP update...
Solving the mystery
So now we wanted to verify it is legitimate traffic and found out: A simple ping to the public IPv4 Address returned with an error message "TTL expired" -- which should not happen in a local network...
Further lookups showed IP-Packets bouncing between our core routers (in the internal network) and the edge routers (in the external networks).
The edge routers sent the packets to our NAT (where they should go), but the NAT did not "translate" them. We expect those packets to be translated to the address of the host that opened the connection. Since there was no open connection, the packets should be dropped. But here, the NAT did forwrad the packets without translation. So an IPv4 packet arrived in our core network, that had a public IPv4 address as destination. Since we only use private address space inside the network, the routers have no route for this. So the packet gets forwarded in the direction of the default-route, which is: to the internet. So the packet gets sent back, though the NAT again. This time, the packet isn't expected to be translated, because it didn't originate inside our network and already has a public source address (from China Telecom). So our edge router receives the packet, and we start over. So these packets go back and forth, tens or maybe even hundrets of times, until their time-to-live expires.
To make matters worse all of that happened with 40 GBit/s between the devices while the packets still needed to be processed by the cores routing engine. So the "DDoS Violations" were correct, we DDoS'ed ourself with 40 GBit/s...
After this the pattern was clear to us: All IPs of our pool for internal SNAT (like the "Event" wireless network) were routed in a loop as the NAT did just forward them, even when there was no valid state from an internal IP.
So one packet from an external address was multiplied into (up to) 255 of them which were transmitted with 40 GBit/s between the devices. If you think about our observation before: We had 4000 Packets in 3 seconds. This times 255 translates to roughly a million packets in our internal network... Well, sounds reasonable the DDoS-Protection tried to protect the routing engine of the devices and it became unreachable.
But as the routing engine stopped responding, this caused the BGP- and OSPF-Sessions to die. This started a domino effect: Routing switched to the backup paths, other routers were impacted and when the first device became responsive again (since the load suddenly disappeared), the routing started to switch back to the primary connections - and caused the whole loop again.
The Fix
Finally we knew what we had to do: The packets that do not translate at the NAT should be dropped at the end of handling them.
The fix was applied yesterday around 9 p.m. and since then we haven't detect another larger disruption.
For the ultimate reason we can only speculate:
* Was it the new Software? Is there a command or anything which is interpreted in a different way?
* Did the reboot of our device change something?
* Did somebody try to scan our network for vulnerabilities?
* ...?
For now we can not say what is more likely. We can only say that our NAT was not configured in the correct way.
And the moral of the story? Do not trust your own NAT if you already have a history!
Thanks to all of our members who helped in any way to solve this problem. We also apologize to all users of our network, as it wasn't quite stable during the period of recognizing the bug and debugging it.
Do you want to participate in taking care of such problems in the future? For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.
If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).
The Selfnet-Team
Deutsche Übersetzung
Wie man sich selbst per DOS angreift
Eventuell hat es der ein oder andere am Wochenende mitbekommen: Wir hatten einige Probleme was die Stabilität der Verbindungen im Netzwerk anging.
Am Freitag hatten wir einige Software-Upgrades auf unseren Core-Routern durchgeführt, weshalb wir dies erst auf die neue Software und die Neustarts im Netz schoben. Doch die Ausfälle hörten auch nach dem Abschluss der Arbeiten nicht auf.
Der Grund waren einige Meldungen unserer Core-Geräte wie diese
vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC
oder auch diese
vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding
Bei dem Betrieb der Geräte äußerte es sich dabei so, dass diese stockten, nicht mehr reagierten und dann teilweise auch nicht mehr erreichbar waren. Das führte dann wiederum dazu, dass das Routing im Netzwerk auf die Backup-Wege umschwenkte.
Kurz danach war das Gerät dann wieder erreichbar und das Routing schwenkte wieder auf die Hauptleitungen. Das ganze wiederholte sich dann teilweise 3-20 mal über eine Zeitspanne von teilweise nur 30 Sekunden bis 20 Minuten.
Ursachenforschung
In den Logs sah man teilweise die DDOS-Protection anschlagen, wiederholende Meldungen wie die oben und sterbende OSPF-/BGP-Prozesse.
Problematisch war das sehr sporadisch Auftreten des Problems, was die Fehlersuche nicht so einfach machte, da man dauerhaft am Gerät sein musste um während einer Unterbrechung noch Befehle abzusetzen oder Log-Dateien auszulesen, bevor diese wieder vorbei war.
Anfangs war eine Vermutung, dass es eine Diskrepanz zwischen unseren beiden NAT-Servern gibt, da vor den Systemupgrades der Traffic über das eine Gerät ging, danach über das andere. Dies wurde kurz danach aber bereits widerlegt, da auch das andere Gerät die Probleme zeigte.
Da dies nicht die Ursache war ein weiteres mögliches Problem die Verbindung zwischen den Routern und dem NAT, aber auch das konnte ausgeschlossen werden.
Von Beginn an war relativ klar, dass die aktivierte DDOS-Protection nur ein Symptom und nicht die eigentliche Ursache war, da es bei dem Juriper-Bug ähnlich aussah. Also haben wir wie bei jenem Bug auf dem NAT die Pakete die weitergeleitet wurden mal angesehen als sich ein weiterer Ausfall ankündigte.
Das Ergebnis waren viele Pakete an event.selfnet.de, die öffentliche IPV4 NAT-Adresse für u.a. das Event-WLAN. Insgesamt 2,2% bei den knappen 3 Sekunden die wir uns ansahen. Die Pakete bestanden aus UDP Paketen mit kaum Inhalt und relativ viel NTP. Das machte uns schon etwas stutzig. UDP könnte man sich eventuell noch erklären wenn irgendwo das WLAN noch aktiv wäre, auch wenn kein Event ist, aber NTP-Anfragen sollten da nicht aktiv hin geleitet werden.
Also haben wir uns angesehen, wo die Pakete herkamen. Einige Pakete kamen von einem vServer-Anbieter in Deutschland und die NTP-Pakete hauptsächlich von der China-Telecom. Hmmm... komisch, wieso sollten die bei uns NTP machen wollen...
Des Rätsels Lösung
Daraufhin wollten wir verifizieren, ob der Traffic überhaupt legitim ist und stellten fest, dass ein Ping an die öffentliche IP mit der Meldung "TTL expired" zurück kam. Das sollte im lokalen Netzwerk eher nicht so sein...
Beim weiteren Betrachten fiel dann auf, dass die IP-Pakete zwischen unseren Core-Routern (dem internen Netz) und den Edge-Routern (dem externen Netz) Ping-Pong spielten.
Der Edge-Router schickte die IP-Pakete zum NAT (wo sie ja auch hin sollten), das NAT hat diese aber nicht "übersetzt" auf eine interne IP aber schickte es trotzdem weiter und der Core schickte das ganze wieder zurück zum NAT, da die IP ja durchs NAT musste.
Und das ganze mit 40 GBit/s wobei die IP-Pakete zum Routing an die Routing-Engine weitergeleitet werden mussten. Im Endeffekt war das mit dem "DDOS-Violations" also schon richtig, wir haben unsere Router selbst mit 40GBit/s gedost...
Daraufhin ist das Muster auch deutlich erkennbar geworden: Alle IPs aus dem Bereich für die internen SNAT-Dienste (wie eben das Event-WLAN) wurden im Kreis geschickt, da das NAT diese einfach weiterleitete, wenn es keinen passenden State von intern gab, zu den man die Anfrage zurück übersetzen könnte.
Damit wurde aus einem IP-Paket von extern eben bis zu 255 die mit 40 GBit/s zwischen den Geräten hin und her flogen. Wenn man nun noch bedenkt dass es in dem kurzen Zeitraum den wir uns ansahen knapp 4000 solcher IP-Pakete von extern waren kommt man auf etwa eine Million IP-Pakete intern... Irgendwo verständlich, dass dann der DDOS-Schutz anspringt und die Routing-Engine nicht mehr erreichbar ist.
Das die Routing-Engine der Geräte nicht mehr erreichbar war sorgte dann letztendlich dafür, dass die OSPF- und BGP-Sessions ausliefen. Das sorgte dann dominomäßig dafür dass dann im Routing viel umgestellt wurde und teilweise das Problem einfach den nächsten Router traf.
Wenn die Routing-Engine wieder erreichbar war, gings wieder zurück auf Ursprung und wenn dann immernoch so viele IP-Pakete da waren, waren wir wieder am Anfang des Kreises und alles begann von neuem.
Der Fix
Nachdem wir dies erkannt hatten konnten wir die Pakete die nicht zum NAT passen am Ende der NAT-Regeln einfach verwerfen.
Dieser Fix wurde gestern Abend ~21 Uhr eingespielt und seitdem konnte wir keine weiteren großen Ausfälle feststellen.
Über die Ursache kann man nun nur spekulieren:
* War die neue Software schuld? Wird irgendwas anders interpretiert?
* Hat der Neustart der Geräte etwas ausgelöst?
* Hat jemand versucht herauszufinden ob unser Netz verwundbar ist?
* ...?
Momentan kann man hier denke ich keine genauere Aussage treffen als die, dass letztendlich unser NAT falsch konfiguriert war.
Und die Moral von der Geschicht? Trau deinem eigenen NAT nicht!
Wir danken hiermit allen Mitgliedern, die bei der Fehlersuche und Problemlösung beteiligt waren. Auch wollen wir uns bei den Mitgliedern entschuldigen, die während dieser Zeit nicht auf die übliche Stabilität des Wohnheimnetzwerks zählen konnten.
Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.
Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).
Das Selfnet-Team