Ein immer wieder geäußerter Verdacht besagt, dass man umso mehr positive Fälle bekommt, je mehr man mehr testet. Das klingt zunächst einleuchtend, ist aber nicht korrekt.

Modellierung

Zur Modellierung beziehe ich mich auf ein paar wohl fundierte Voraussetzungen:

• Es gibt eine reale Inzidenz, d.h. ein bestimmter Prozentsatz der Bevölkerung ist aktuell infiziert.
• Betrachtet wird ein Schnappschuss des Infektionsgeschehens, weitere Ansteckungen während dieser Zeit bleiben außen vor.
• 20% der Infizierten hat Symptome.
• Jeder Infizierte hat 3,2 weitere Menschen angesteckt.
• 40% der Menschen, die Symptome haben, sind tatsächlich infiziert.
• 5% der nachverfolgten Kontakte sind infiziert.
• Der Test wirkt zu 100%, er erkennt eine Infektion zweifelsfrei.

Dies bedeutet, dass es einen unentdeckten Rest an Infektionen gibt, der nicht zu den 20% Symptomatischen oder den 64% angesteckten Kontakten gehört. 16% sind also ohne erkennbaren Bezug infiziert. In diesem Modell nehme ich eine Stadt mit 100000 Einwohnern, so dass die Anzahl der positiven Tests und die Inzidenzzahlen identisch sind. So setzen sich 1% Infizierte somit aus 200 Symptomatischen, 640 infizierten Kontakten und 160 unentdeckten Fällen zusammen. Insgesamt ist das eine reale Inzidenz von 1000.

Das Testregime geht strikt vor:

• Zuerst werden symptomatische Personen getestet.
• Sind noch Kapazitäten frei, so werden Kontaktpersonen getestet.
• Sind dann noch Kapazitäten frei, so werden weitere Personen getestet.

Beginnt man mit wenigen Tests, so reicht die Testkapazität nicht aus, alle symptomatischen Personen zu testen.  Aber nicht alle Tests sind auch positiv.

Die Anzahl der entdeckten Fälle steigt also linear mit der Anzahl der Tests an, wobei die Positivquote sich bei 40% einpegelt. Das ist genau der Wert, der für den Anteil der Infizierten unter den Symptomatischen vorgegeben war.

Erst, wenn alle 500 symptomatischen Personen auch getestet wurden, um die 200 (40%) Infizierten zu finden, kommen die Kontaktpersonen an die Reihe und die Positivquote sinkt. Man erreicht einen Inzidenzwert von 200,  der um den Faktor 5 zu niedrig ist. Ja, das ist genau die gern bemühte Dunkelziffer vom Frühjahr 2020.

Auch jetzt muss wieder viel getestet werden, um alle Kontaktpersonen zu überprüfen. Wiederum steigt die Inzidenz mit den Tests linear an, diesmal aber langsamer, denn man liegt oft (zu 95%) falsch. Dabei werden aber schon die ersten Fälle entdeckt, die nichts mit den ursprünglichen Ansteckungsverhältnissen zu tun haben.

Hat man alle Kontaktpersonen durch stabilisiert sich die Inzidenz bei 840 (von real 1000). Die Positivquote ist inzwischen auf ca 7% gefallen. Die Dunkelziffer beträgt nach der Ausleuchtung der Kontakte nur noch bei 1,2. Man ist also schon ziemlich nahe dran.

Weitere Tests hellen das Dunkelfeld immer weiter auf, die Positivqoute sinkt weiter, bis sie die realen 1% der Infektionsrate erreicht hat.

Fazit

Die Erhöhung der Tests führt zu erhöhten Inzidenzzahlen, indem die noch unentdeckten Fälle aufgedeckt werden. Die Anzahl der positiven Tests überschreitet dabei niemals die realen Fälle, es wird nur das Maß der Unbestimmtheit verringert.

Das geschieht in drei Stufen: Nach der Aufdeckung der symptomatischen Fälle kommt es zur ersten Stagnation, eine Erhöhung der Tests führt nicht mehr im gleichen Maße zu einer Erhöhung der positiven Fälle. Die Positivquote sinkt.

Nach der Aufdeckung der Kontakte kommt es zu einer weiteren Stagnation, eine Erhöhung der Tests führt nicht mehr im gleichen Maße zu einer Erhöhung der positiven Fälle. Die Positivquote sinkt weiter. Dabei ist schon fast das ganze Infektionsgeschehen sichtbar. Es sind dafür fast 10% der Bevölkerung zu testen.

Die restlichen 90% der Bevölkerung zu testen, führt zur Aufdeckung der restlichen 16% der Fälle und damit zum Erliegen der Ausbreitung. Bis zur nächsten Einschleppung.

Es ist nicht möglich, durch mehr Tests beliebig hohe Inzidenzen zu erreichen. Man kann eine Pandemie nicht herbei testen!

Ein realistischeres Beispiel

Ganz offensichtlich sind 1% Infektion in der Bevölkerung extrem viel. Dies würde bedeuten, dass in Folge dieses Geschehens ca. 20 Personen versterben (2% Tödlichkeit). Eine Inzidenz von 1000 ist weit mehr, als wir hier real erleben und hoffentlich auch nicht erleben müssen.

In Jena (ca. 100000 Einwohner) werden ca. 70 Leute in einer Woche positiv getestet. Dies entspricht in dem Modell einem Schnappschuss, weil es etwa der Zeit der Kontaktnachverfolgung entspricht. Die Positivquote ist ca, 5% (Durchschnitt in Deutschland). Damit wurden 1400 Tests durchgeführt.

Durch Ausprobieren komme ich damit auf eine realen Infektionsrate von 0,085%, d.h. 85 Infizierte (17 mit Symptomen, 54 in den Kontakten und 14 sonstige). Davon werden bei 1400 Tests alle Symptomatische und alle Kontakte gefunden, jedoch kein weiterer Fall. Die beobachtete Inzidenz liegt somit bei 71. Real wären es 85.

Steigert man die Zahl der Tests, so findet man erst bei ca. 4000 Tests den nächsten, bis dahin völlig unbekannten Fall. Man kann auch bis 1200 Tests zurück gehen, ohne einen Fall zu übersehen. Die Anzahl der Tests spielt also keine Rolle mehr für die ermittelte Inzidenz. Nur die Positivquote wandert von 2% zu 6%. Dazu sind nur etwas mehr als 1% der Bevölkerung zu testen.

Mit den 1400 Tests bei einer Inzidenz von 70 liegt Jena also nur knapp über der Schwelle, die notwendig ist, um das Kontaktumfeld auszuleuchten.

Zum Abschluss nochmal das volle Bild für diesen Fall: Jena, gemessene Inzidenz 70 bei 5% Positivquote, reale Inzidenz 85 (= 0,085% Infizierte)

Eine Inzidenz von 70 bedeutet aber auch, dass es in den nächsten drei bis sechs Wochen ein bis zwei weitere Todesfälle geben wird, die auf genau diese Woche zurück gehen. Noch mehr Personen werden nach schwerem Verlauf lange Schäden davon tragen. Und dann kommt schon wieder die nächste Woche.

Zu kompliziert? Dann vielleicht mal die andere Erklärung lesen.

Wir müssen die Dimension Infektionsschutz und die Dimension Auswirkungen desselben in ein Konzept zu kriegen. Ob es uns gefällt oder nicht, wir brauchen einen härteren Lockdown. Damit das funktioniert, brauchen wir Konzepte, wie dieser Lockdown erträglich wird. … so schreibt Josef Dietel. Aber wie geht das?

Josef schlägt Gruppenbildung und die Umsetzung des ZeroCovid-Konzeptes vor.

Der Kerngedanke ist folgender:

• SARS-CoV2 hat eine Inkubationszeit von ein bis zwei Wochen. Die Ansteckungszeit liegt bei ein bis zwei Wochen. In Summe ist man i.d.R. nach der dritten Woche nach einem Risikokontakt nicht mehr ansteckend oder deutlich krank.
• SARS-CoV2 verbreitet sich über engen Kontakt mit Austausch von Aerosolen aus den oberen Atemwegen. I.d.R. ist also eine Ansteckung nur möglich, wenn sich Leute treffen und einige Zeit zusammen verbringen.
• Isoliert man also eine kleine Gruppe von Menschen über vier bis acht Wochen, so ist hinterher keiner mehr ansteckend, wenn es keine Krankheitsfälle gibt. Je größer die Gruppe umso länger dauert es, weil es interne Infektionswege geben kann.

ZeroCovid macht nun aus diesem Fakten ein Konzept:

• Jede beliebige kleine Gruppe von (möglicherweise infizierten) Menschen kann durch eine kurze, harte Quarantäne frei von SARS-CoV2-Viren werden.
• Größere Gruppen kann man durch mehrfache Tests aller Mitglieder als virenfrei überprüfen. Da die Krankheit einen zeitlichen Verlauf hat, genügt nicht ein einziger Test, sondern man muss alle Stadien der Virenentwicklung abdecken.
• Hat man einen virenfreie Gruppe, so kann diese sich ohne ernsthafte Schutzmaßnahmen frei bewegen.
• Tritt wieder ein Fall auf, so muss das Infektionsgeschehen vollständig nachvollzogen werden. Alle möglicherweise in Frage kommenden Kontakte müssen in Quarantäne und kommen nur durch mehrfache Tests wieder raus.
• Gibt es auch nur den leisesten Zweifel an der Nachvollziehbarkeit der Infektion, so wird im Sinne der frühzeitigen Brandbekämpfung die gesamte mögliche Umgebung komplett getestet und geht solange in Quarantäne.
• Gibt es keinen positiven Test im gesamten Gebiet, ist die Quarantäne aufgehoben.
• Gibt es einen positiven Test, wird das Gebiet zurück gestuft und bleibt in Quarantäne und es gibt neue Massentests.

Quarantäne heißt dabei: Kein Verlassen der Wohnung, auch keine Einkäufe. Nur Homeoffice und Homeschooling. Arzt und Essen kommen bei Bedarf ins Haus.

Auf diese Weise bekommt man Städte und Dörfer virenfrei. Sie bekommen eine grünen Kennung und können zum normalen Leben zurück. Aus Vorsicht sind Kontakte in nicht-grünen Bereichen zu vermeiden und wenn überhaupt dann mit Rückkehrquarantäne versehen. Das setzt auch eine hohe Motivation für die Bewohner grüner Bereiche: Wer die Vorsichtsmaßnahmen verletzt, riskiert eine regionale Quarantäne und sogar eine Rückstufung des Gebiets, was mit Verlust der offenen Läden, Clubs, Sportstätten und Restaurants einher geht.

Das klingt hart? Ist es auch.

Das klingt unmöglich? Richtig, weil man nicht weiß, wo man anfangen soll.  Man kann ja nicht wie in China einfach virenfreie Menschen aus anderen Regionen ankarren, damit die das öffentliche Leben aufrecht erhalten.

Was also tun? Josef hat da eine Idee. Er schlägt vor, die Einheiten kleiner zu fassen.

Man kann sich freiwillig zu Gruppen zusammen finden, innerhalb derer man sich frei bewegen kann. Man darf keinen Kontakt zu anderen Menschen außerhalb seiner Gruppe haben. Alle Mitglieder einer Gruppe werden einheitlich behandelt und bekommen eine Einstufung von grün, gelb oder rot.

• grün: Die Gruppe ist nachweislich virenfrei. Sie unterliegt keinen Einschränkungen.
• gelb: Die Gruppe ist wahrscheinlich virenfrei. Infizierte Einzelfälle haben lückenlos aufgeklärte Infektionsketten, die sich in Quarantäne befinden. Mögliche Spreaderevents sind unzulässig.
• rot: Die Gruppe ist teilweise durchseucht. Es ist unklar, welche Personen aktuell infiziert und infektiös sind. Die Gruppe ist auf das nötigste beschränkt.

Gruppen gleicher Einstufung können sich zusammen schließen oder trennen. Jede Person ist genau einer Gruppe zugeordnet. Die Zuordnung ist behördlich und im Umfeld der Gruppe bekannt. Dies ermöglicht eine Kontrolle der Gruppenzuordnung. Damit ist es möglich, zumindest innerhalb einer Gruppe, sich sinnvoll zu betätigen und Kontakte zu pflegen. Das macht es leichter.

Die Idee ist nun:

• Das Gesundheitsamt nimmt die Umstufung einer Gruppe mit Hilfe von Tests und Gruppen-Quarantäne vor.
• Einzelfallquarantäne wird nur in gelben Gruppen angeordnet. Nur hier erfolgte eine Kontaktnachverfolgung, diese dafür intensiv.
• Bei Auftreten von neuen Fällen geht die gesamte betroffene Gruppe in die Stufe rot, bis das Gesundheitsamt die gesamte Gruppe komplett getestet hat.
• Bereits nach wenigen Tagen das Gesundheitsamt die Gruppe aufteilen in eine gelbe (negative Tests) und eine rote Gruppe (positive Tests plus alle möglichen Kontaktpersonen)
• Die gelbe Gruppe kann nach einem zweiten Massentest nach einer Woche in die Stufe grün zurück fallen.
• Die rote Gruppe wird schrittweise verkleinert, wobei neue gelbe Kleingruppen entstehen.

Da sich grüne Gruppen zu immer größeren Einheiten zusammen schließen können, kann der Bewegungsfreiraum deutlich erweitert werden. Auch Reisen zwischen diesen Gruppen ist möglich (u.a. auch weltweit zu anderen Ländern mit ZeroCovid-Strategie), solange vor und nach der Reise ein Schnelltest vorgenommen wird.

Die Gruppen entscheiden selbst über ihr Verhalten. Es gibt also einen sozialen Druck, nicht negativ auszuscheren. Es gibt einen sichtbaren Ansporn, sich um eine bessere Gruppeneinstufung zu bemühen. Es gibt klare und überschaubare Intervalle in denen eine Statusänderung möglich ist.

Betriebe - die momentan am meisten unterschätzten Treiber der Pandemie - können Mitarbeiter verschiedener Gruppen im Schichtsystem ins Haus holen, oder selbst durch eigene betriebliche Maßnahmen für eine niedrigere Einstufung ihrer Mitarbeiter beitragen. Es gibt somit eine Motivation der Unternehmen, sich aktiv um besseren Arbeitnehmerschutz vor Ansteckungen zu kümmern.

Wie man erkennen kann, ist die Zeitschiene dieses Verfahrens ziemlich kurz, weil man auch initial kleine Gruppen binnen Monatsfrist auf einen grünen Status bekommt. Dies wäre auf größeren Einheiten, wie Landkreise, nicht möglich.

Menschen, die sich nicht an die Regeln halten wollen, landen in Gruppen mit Gleichgesinnten. Sie gefährden damit nicht länger die Entwicklung der anderen Gruppen mit denen sie aktuell noch zusammen erfasst werden.

Die aufzuwendenden Ressoucen wie Tests und Kontaktnachverfolgung werden wesentlich effektiver eingesetzt.

Und was ist mit Impfungen?

Auch heute wieder hört man in den Nachrichten von der Herdenimmunität durch Impfung. Das hat leider nur einen Haken, es grenzt aktuell an vorsätzliche Volksverdummung. Diese Unehrlichkeit können wir uns aber nicht leisten. Ich vermisse da auch eine klare Aussage von Politikern wie Karl Lauterbach.

Herdenimmunität entsteht, wenn so viele Leute gegen eine Krankheit immun sind, dass die Weiterverbreitung des Erregers zum erliegen kommt.

Das kann man ausrechnen, so braucht man im Mittel bei einer Reproduktionszahl von 3 (eine infizierte Person steckt drei andere an) einen Anteil von ca. 66% (1 -1/3) für eine Herdenimmunität. Sinkt die effektive Reproduktionszahl z.B. durch Vorsichtsmaßnahmen und Verhaltensänderungen auf beispielsweise 1,2 , so sinkt auch der benötigte Anteil der Immunen auf ca. 16% (1 - 1/1.2). Bekommt man durch eine Mutation eine höhere Ansteckungsrate (+0.6), so steigt der Anteil für die Herdenimmunität wieder auf 44% (1 - 1/1.8).

All das setzt voraus, dass eine durchgemachte Erkrankung oder eine Infektion, tatsächlich zu einer Reduktion der Weiterverbreitung führt. Und da liegt der Hase im Pfeffer.

Corona  hat die Hauptinfektionsphase während der Vermehrung im Nasen- und Rachenraum, wo  das Immunsystem nur schwer hin kommt. Zusätzlich tarnt sich das Virus in dieser Phase mit Zucker um die Spikeproteine, wird also von den Antikörpern nicht  erkannt.

Erst nach der Hochinfektionsphase geht es in den Körper so das  Immunsystem angreifen kann und die Impfung ihr Potential ausspielt. Nun kann das Immunsystem richtig (nicht überschießen und wild Zellen abtöten) und gezielt reagieren. Damit ist die Wahrscheinlichkeit für den schweren Verlauf deutlich gesenkt.

Diese "Infektion vor Symptomen" ist also bei Corona anders als bei anderen Krankheiten. Vermeintlich gesunde (und geimpfte) können die Krankheit weiterhin übertragen! Sie können die Ansteckung weiter verbreiten. Sie tragen also nicht zur Herdenimmunität bei.

Inwieweit eine Impfung zur Senkung der Virenlast und damit zur Verringerung der Infektionszahlen beitragen kann, ist die  offene Frage der aktuellen Forschung. Ich würde mich sehr freuen, wenn heraus kommt, dass es eine Schutzwirkung gibt, dass das trainierte Immunsystem in der Lage ist, die Vermehrung im Rachenraum zu unterbinden.

Leider fehlen dazu bislang die Studien. Und solange wir die nicht haben, müssen wir davon aus gehen, dass wir keine Herdenimmunität bekommen werden.

Noch ein Nachtrag zu wir können doch aufmachen, wenn die Risikogruppen durch Impfung geschützt sind. Nein, können wir nicht! Angenommen die Impfung senkt die schweren Verläufe um den Faktor 20 (was viel ist). Mit einer Reproduktionszahl von 3 nach Abschaffung der Maßnahmen, bekommen wir also jede Woche drei mal mehr Infzierte. Wie lange dauert es, bis wir trotz Impfung die alten Toteszahlen wieder haben? Genau: Wenn wir nach knapp drei Wochen die 27-fache Anzahl an Infzierten haben. Nur wächst es dann immer weiter ...

Update vom März 2021

Inzwischen gibt es Nachweise, dass die Impfstoffe auch die Virenlast senken und so die Infektiösität. Damit ist diese Befürchtung zu großen Teilen ausgeräumt.

Da immer wieder die Frage aufkommt, wie die Regeln denn nun im Detail zu interpretieren seien, was also gerade noch erlaubt ist...

Wer die Inzidenz hoch halten und den Lockdown verlängern will, macht folgendes:

Man trifft sich jede Stunde mit einer anderen Person eines anderen Haushalts, aber nie mit zweien gleichzeitig.

Man kann z.B. bei gemeinsamen Spaziergängen mit 3m Abstand gehen und sich höchstens Zweiergruppen bildend abwechselnd durch die Menge schlendern und so mit vielen ins Gespräch kommen.

Man kann sich zufällig beim Rodeln treffen. Man kann dazu auch in die schneesicheren Lagen fahren, am besten irgendwo hin, wo keine Skipisten ausgeschildert sind. Passende Plätze kann man in der Telegramm-Gruppe austauschen, damit man nicht allein ist.

Man kann im Freien den Mundschutz abnehmen, auch wenn es kalt ist, weil man ja auch dort, wo es vorgeschrieben ist, nicht kontrolliert wird.

Man kann sich zum gemeinsamen Grillen auf der Terrasse oder im Hof treffen und dort zusammen rauchen und grillen. Eine gemeinsame Bierflasche, die im Kreis geht, friert nicht so schnell zu. Bratwurst draußen - wer braucht da schon Mundschutz? Ist ja wie die Gastronomie im Sommer, völlig ungefährlich!
Apropos Mundschutz, genau, immer das Wort Mundschutz benutzen, denn dann braucht man es nicht über die Nase ziehen. Denn nur, wer einen Mund-Nasen-Schutz hat, muss den hochziehen, das sagt doch schon der Name!

Also raus an die frische Luft! Bewegung hat noch niemanden geschadet und auf Arbeit sitzt man eh zu fünft im Büro, zu zehnt im Meeting. Ungelüftet natürlich, die Haustechnik hat vernoten die Fenster aufzumachen, wenn die Heizung an ist. Wegen Klimawandel und so!

Und dann kann der Lockdown endlich bis Juli verlängert werden. Hauptsache er endet kurz vor der Mallorca Reise!

Auf geht's!

Pack mas!

Da die Frage nach einer Zukunft immer wieder gestellt wird, mal etwas Klartext zur Idee die Beschränkungen einfach fallen zu lassen, um die Wirtschaft zu retten.

Nein. Erstens, man kann ZeroCovid machen. Dazu müssen zuerst mal die Behörden und Betriebe zum Homeoffice gezwungen werden. Schulen und Co bleiben zu. Ende der Diskussionen. Ja, das ist politisch schwierig, vermutlich sogar politischer Selbstmord, aber es wäre es wert.

Zweitens, die aktuellen Maßnahmen zu lockern oder aufzugeben, bedeutet binnen Monatsfrist die Toten nicht mehr wegtragen zu können. Kann man machen.

Es bedeutet auch, zur Brutstätte vieler neuer Mutationen zu werden, insbesondere wenn parallel weiter halbherzig geimpft wird. Diese Mutationen werden gegen die Impfung immun sein. Neue Wirkstoffe dann vermutlich im Frühjahr 2022.

Es bedeutet auch, dass niemand mehr mit Deutschland handeln oder Tourismus erlauben wird. Wir würden weltweit isoliert da sich niemand diesem Seuchenherd mehr nähern will. In globaler Isolation mit einer verängstigter Bevölkerung zerstört sich die Wirtschaft selbst. Wir bekommen MadMax Verhältnisse.

Achja, diese Impfung bringt vermutlich gar keinen Beitrag zur Herdenimmunität, den Begriff sollten wir aus der politischen Debatte streichen. Sie taugt nach aktuellem Stand der Forschung nicht zur Einschränkung der Infektiösität. Sie taugt zur Verringerung der Sterblichkeit. Aber diese Verringerung ist linear mit der Impfquote, wird also vom exponentiellen Wachstum aufgefressen. Damit ist der Schutz der Risikogruppen eine Chimäre, es funktioniert nur zusätzlich, nicht stattdessen.

Weil es wieder Verwirrungen um WhatsApp und Messenger im Allgemeinen gibt. Es besteht die Angst, dass Fremde mitlesen könnten.

Generell hat die jeweilige App immer Zugriff auf die Keys. Ansonsten könnte man die Nachrichten weder lesen noch schreiben. Man muss dem App-Hersteller vertrauen, dass er die ausgelieferte Version ohne Hintertüren und ohne Übertragung an Dritte programmiert hat. Auch wenn man den Source Code einsehen kann, nützt das nichts, solange man nicht prüfen kann, ob die App auch daraus erzeugt wurde.

Bietet die App Komfortfunktionen, wie Webinterface, Backup, etc. so ist dort ebenfalls Schlüsselmanagement angesagt. I.d.R. kann dabei ein Dritter nicht mitlesen. Das gilt für alle Messenger, ob WhatsApp, Threema, Signal oder Telegram. Die Messenger unterscheiden sich im Komfort, so hat Signal mal auf direktem Kontakt (QR Scan, Codetausch) zwischen Teilnehmern bestanden, bevor man kommunizieren konnte.

Übrigens hat das Betriebssystem auch Zugriff auf die Keys, die Datenablage, die Kommunikationskanäle etc. pp

Mit der Änderung der Nutzungsbedingungen passieren zwei Dinge:

a) Facebook genehmigt sich Zugriff auf die Metadaten (Wer redet wann mit wem? Wo befindet sich der Nutzer derzeit? Welche Inhalte veröffentlicht er im Status?)

Das bedeutet, dass WhatsApp die Bewegungs- und Kontaktdaten, die sie bisher schon den Strafverfolgungsbehörden und den Gesundheitsämtern (in Taiwan, Südkorea, ...) zur Verfügung gestellt hat, nun auch an Facebook weiter geben kann. Im Gegenzug bekommt WhatsApp eine Facebook-Integration (die nur funktioniert, wenn man die eingerichtete Facebook App auf dem Handy hat)

b) ist der Satz "WhatApp Server haben keinen Zugriff auf die privaten Schlüssel" weggefallen.

Das bedeutet, dass ... ohja ... wir betreten das Reich der Spekulation ... der Satz wird als Canary interpretiert ... also es bedeutet, dass WhatApp gezwungen sein kann, die App dahingehend verändern zu müssen, dass Strafverfolgungsbehörden mitlesen können. Hier geht es hauptsächlich um die Bemühungen der EU Kommission.

Und natürlich betrifft das beides (Metadaten, Lawful Interception) auch alle anderen Messenger.

Das Modul ng_bridge erlaubt es, verschiedene Datenkanäle über die MAC Adressen zu separieren. Dies funktioniert nicht besonders gut, wenn an einer Stelle sehr große Netze mit sehr vielen Teilnehmern angeschlossen sind. Dort möchte man die MAC Adressen nicht lernen. Mit interessanten Konsequenzen.

Problem

Das netgraph Modul ng_bridge verbindet verschiedene Teile des Netgraph-Netzwerkes wie ein Switch in einem Serverraum. Die einzelnen Teile sollen dabei nur die Daten bekommen, die auch für sie gedacht sich. Leider hat das Modul ein paar Schwächen in der Praxis.

• Zunächst mal konnte das Modul nur mit einer Handvoll Anschlüssen umgehen. Die Limitierung habe ich aufgehoben.
• Dann lernt das Modul sämtliche MAC Adressen an allen Anschlüssen, was hier ein Problem ist. Auch dafür gibt es eine Lösung.
• Das Modul behandelt sämtliche Multicast- und Broadcast-Frames gleich: Sie gehen an jeden Anschluss raus. Das ist ein Problem.
• Aufgrund der inneren Architektur ist das Modul nur single-threaded, was einen begrenzten Datendurchsatz mit sich bringt. Das ist ein weiteres Problem.

Sobald man an einigen Anschlüssen schwachbrüstige Leitungen hängt, treten Überlastungsprobleme auf. Traffic, der dort hin geschickt wird, sollte weitestgehends auch dort hingehen sollen. Traffic, der dort nichts zu suchen hat, sollte gar nicht erst in diese Richtung geschoben werden.

Mit der Einführung von uplink-Ports verringert sich massiv der interne Verwaltungsaufwand. Die MAC-Adressen in Richtung des Uplinks müssen nicht mehr gelernt werden. Und das hat Konsequenzen: Was passiert mit Frames, die an den Uplink geschickt werden müssen?

Eigentlich ist das ganz einfach, denn das Modul kennt die Ziel-MAC ja nicht, schickt es also an alle Links raus, auch an den Uplink. Damit ist der Frame dort, wo er hin soll. Allerdings landet er auch dort, wo er nicht hin soll: Alle anderen Teilnehmer an der Bridge bekommen den kompletten Uplink-Traffic aller ihrer Nachbar zu sehen.

Test

Also teste ich das mal aus. Zunächst wird eine bridge eingerichtet, die drei Downlinks (link1, link2, link3) und zwei Uplinks (uplink1 und uplink2) hat, die alle an virtuellen Ethernet-Interfaces hängen.

ngctl -f- <<END
mkpeer bridge x link10
mkpeer x eiface uplink1 ether
mkpeer x eiface link1 ether
mkpeer x eiface link2 ether
mkpeer x eiface link3 ether
mkpeer x eiface uplink2 ether
END

link10 ist nur temporär zur Erzeugung des gesamten Konstrukts vorhanden, er geht automatisch weg, wenn das Tool ngctl sich beendet

Alle Interfaces werden mit unterschiedlichen MAC Adressen bestückt.

ifconfig ngeth0 ether 00:00:00:00:00:01
ifconfig ngeth1 ether 00:00:00:00:01:01
ifconfig ngeth3 ether 00:00:00:00:02:01
ifconfig ngeth2 ether 00:00:00:00:02:01
ifconfig ngeth3 ether 00:00:00:00:03:01
ifconfig ngeth4 ether 00:00:00:00:04:01

Und dann wird der komplette Datenverkehr mit geschnitten.

tcpdump -eni ngeth0 > bridge.e0 &
tcpdump -eni ngeth1 > bridge.e1 &
tcpdump -eni ngeth2 > bridge.e2 &
tcpdump -eni ngeth3 > bridge.e3 &
tcpdump -eni ngeth4 > bridge.e4 & 

Um nicht jedes Interface in separate Routing-Umgebungen werfen zu müssen, nehme ich einfach für alle Interfaces unterschiedliche IP-Netze. Damit weiß der Kernel, welches Interface ich benutzen möchte.

ifconfig ngeth0 inet 192.168.0.10/24
ifconfig ngeth1 inet 192.168.1.11/24
ifconfig ngeth2 inet 192.168.2.12/24
ifconfig ngeth3 inet 192.168.3.13/24
ifconfig ngeth4 inet 192.168.4.14/24

Und dann muss der Kernel noch wissen, welche MAC Adresse er von welchem Interface aus ansprechen soll. Das erfolgt mit Hilfe von statischen ARP-Einträgen.

arp -s 192.168.0.11 00:00:00:00:01:01
arp -s 192.168.0.12 00:00:00:00:02:01
arp -s 192.168.0.13 00:00:00:00:03:01
arp -s 192.168.0.14 00:00:00:00:04:01
arp -s 192.168.0.20 00:00:00:00:20:00
arp -s 192.168.1.10 00:00:00:00:00:01
arp -s 192.168.1.12 00:00:00:00:02:01
arp -s 192.168.1.13 00:00:00:00:03:01
arp -s 192.168.1.14 00:00:00:00:04:01
arp -s 192.168.1.20 00:00:00:00:20:01
arp -s 192.168.2.10 00:00:00:00:00:01
arp -s 192.168.2.11 00:00:00:00:01:01
arp -s 192.168.2.13 00:00:00:00:03:01
arp -s 192.168.2.14 00:00:00:00:04:01
arp -s 192.168.2.20 00:00:00:00:20:02
arp -s 192.168.3.10 00:00:00:00:00:01
arp -s 192.168.3.11 00:00:00:00:01:01
arp -s 192.168.3.12 00:00:00:00:02:01
arp -s 192.168.3.14 00:00:00:00:04:01
arp -s 192.168.3.20 00:00:00:00:20:03
arp -s 192.168.4.10 00:00:00:00:00:01
arp -s 192.168.4.11 00:00:00:00:01:01
arp -s 192.168.4.12 00:00:00:00:02:01
arp -s 192.168.4.13 00:00:00:00:03:01
arp -s 192.168.4.20 00:00:00:00:20:03

Wie man erkennen kann sind hier mit den 20-er Adressen auch Einträge dabei, deren MACs dem System unbekannt sind. Spreche ich dagegen eine IP an, für die kein statischer ARP Eintrag vor liegt, wird es einen ARP-Broadcast geben. Damit sind alle Fälle abgedeckt.

Und dann kommen die Tests pro Interface:

ping -c 3 -W 1 192.168.0.10
ping -c 3 -W 1 192.168.0.11
ping -c 3 -W 1 192.168.0.12
ping -c 3 -W 1 192.168.0.13
ping -c 3 -W 1 192.168.0.14
ping -c 3 -W 1 192.168.0.20
ping -c 3 -W 1 192.168.0.21

ping -c 3 -W 1 192.168.1.10
ping -c 3 -W 1 192.168.1.11
ping -c 3 -W 1 192.168.1.12
ping -c 3 -W 1 192.168.1.13
ping -c 3 -W 1 192.168.1.14
ping -c 3 -W 1 192.168.1.20
ping -c 3 -W 1 192.168.1.21

ping -c 3 -W 1 192.168.2.10
ping -c 3 -W 1 192.168.2.11
ping -c 3 -W 1 192.168.2.12
ping -c 3 -W 1 192.168.2.13
ping -c 3 -W 1 192.168.2.14
ping -c 3 -W 1 192.168.2.20
ping -c 3 -W 1 192.168.2.21

ping -c 3 -W 1 192.168.3.10
ping -c 3 -W 1 192.168.3.11
ping -c 3 -W 1 192.168.3.12
ping -c 3 -W 1 192.168.3.13
ping -c 3 -W 1 192.168.3.14
ping -c 3 -W 1 192.168.3.20
ping -c 3 -W 1 192.168.3.21

ping -c 3 -W 1 192.168.4.10
ping -c 3 -W 1 192.168.4.11
ping -c 3 -W 1 192.168.4.12
ping -c 3 -W 1 192.168.4.13
ping -c 3 -W 1 192.168.4.14
ping -c 3 -W 1 192.168.4.20
ping -c 3 -W 1 192.168.4.21

Nachdem die Tests durch sind, kann das Testbed weg geworfen werden. Dazu genügt es, die virtuellen Ethernet-Interfaces abzuschalten. Ohne Verbindungen nach außen löscht sich die Bridge von allein.

ngctl shutdown ngeth0:
ngctl shutdown ngeth1:
ngctl shutdown ngeth2:
ngctl shutdown ngeth3:
ngctl shutdown ngeth4:

Mit dem Verschwinden der Interfaces beenden sich auch die Sniffer und schreiben die letzten empfangen Daten noch ins Logfile.

Was kommt dabei raus? Hier ein kleiner Blick in das Logfile von ngeth0:

12:35:07.109300 00:00:00:00:00:01 > 00:00:00:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.0.10 > 192.168.0.11: ICMP echo request, id 7173, seq 0, length 64
12:35:08.176378 00:00:00:00:00:01 > 00:00:00:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.0.10 > 192.168.0.11: ICMP echo request, id 7173, seq 1, length 64
12:35:09.197277 00:00:00:00:00:01 > 00:00:00:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.0.10 > 192.168.0.11: ICMP echo request, id 7173, seq 2, length 64 

Zu sehen sind die ersten drei Pings von 192.168.0.10 an 192.168.0.11. Man erkennt die MAC Adressen aus den statischen ARP Einträgen und natürlich kommt keine Antwort zurück, weil die IP ja absichtlich auf dem Zielinterface nicht konfiguriert wurde.

Im Logfile von ngeth1 finden sich die Gegenstücke:

12:35:07.109336 00:00:00:00:00:01 > 00:00:00:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.0.10 > 192.168.0.11: ICMP echo request, id 7173, seq 0, length 64
12:35:08.176528 00:00:00:00:00:01 > 00:00:00:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.0.10 > 192.168.0.11: ICMP echo request, id 7173, seq 1, length 64
12:35:09.197342 00:00:00:00:00:01 > 00:00:00:00:01:01, ethertype IPv4 (0x0800), length 98: 192.168.0.10 > 192.168.0.11: ICMP echo request, id 7173, seq 2, length 64

aber auch die Broadcasts kommen hier an

12:35:23.132078 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.0.21 tell 192.168.0.10, length 28
12:35:24.196809 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.0.21 tell 192.168.0.10, length 28
12:35:25.268910 00:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.0.21 tell 192.168.0.10, length 28

Auswertung

Alle Logfiles einzeln durch zu gehen, ist viel zu anstrengend, deswegen gibt es eine Kreuztabelle für jeden Test.

Die Tabelle enthält oben links die Quell-IP, in den Spalten die Ziel-IPs und in den Zeilen die Messtelle am jeweiligen Interface. Blau hinterlegt sind die Felder, die in jedem Fall erwartungskonform sind. Entweder wurden die Pakete dort versendet oder sollen dort ankommen.

Es zeigt in der ersten Zeile, dass von Interface mit der IP ...10 (ngeth0) Pakete an 11, 12, 13, 14 sowie an unbekannt (20) und broadcast (21) geschickt und gesehen werden. Pakete an sich selbst sieht das Interface nicht, denn das handelt der Kernel intern ab.

In der zweiten Zeile finden sich Pakete, die von der IP ...10 ausgehen und am Interface ngeth1 (also mit der IP ...11) gesehen werden. Das sind zunächst mal das Paket an das Interface selbst (korrekterweise), die Pakete an die anderen Ziele (12 und 13) sind nicht zu sehen, weil die Bridge die Ziel-MACs kennt. Das Paket an die 14 (einem weiteren Uplink) kennt Bridge ebensowenig wie die unbekannte MAC (20). Bei der 21 gibt es einen Broadcast, der ebenso zu sehen ist.

Bei den Paketen von den normalen Links wird es nun bunt.

Gelb hinterlegt sind hier diskussionswürdige Felder, beispielsweise die vom Downlink in Richtung Uplink gehen sollten. Da kein MAC Learning am Uplink stattfindet kann die Bridge nicht wissen, welche Pakete an welchen Uplink raus gehen sollen. Das gilt insbesondere für komplett unbekannte MACs, die ja auch in Richtung des Downlinks liegen könnten, aber noch nicht gelernt wurden.

Rot hinterlegt sind Fälle, die man eigentlich gar nicht haben möchte. Pakete, die vom Downlink in Richtung Uplink gehen, sollen nicht zu anderen Downlinks wieder raus gehen.

In gleicher Weise findet sich das Spiel auch für die anderen Quell-IPs darstellen:

Offenbar ist die Behandlung der unbekannten MACs ein ernsthaftes Problem.

Änderungen

Dank OpenSource ist eine Änderung möglich: Wenn das erste Interface, das an die Bridge gebunden wird, ein uplink-Interface ist, schaltet die Bridge in einen Restrictive Mode. Hier werden die unbekannten MACs nicht mehr an die Downlinks weiter gegeben.

Das Verhalten ist nicht unproblematisch, denn nun können Geräte am Downlink nicht mehr erreicht werden, wenn deren MAC längere Zeit nicht zu sehen war. Das kann besonders bei pausierenden Geräten zu einem Problem werden. Die MAC-Haltezeit sollte also in jedem Fall größer sein als die ARP-Timeouts. So sollten die die MAC-Tabellen ausreichend oft aktualisiert werden.

Alles was sich am Testbed nun ändert, ist der Anfang:

ngctl -f- <<END
mkpeer bridge x uplink10
mkpeer x eiface uplink1 ether
mkpeer x eiface link1 ether
mkpeer x eiface link2 ether
mkpeer x eiface link3 ether
mkpeer x eiface uplink2 ether
END 

Aus link10 wird uplink10. Das ist alles. Aber die Wirkung ist verblüffend:

Alle gelben und roten Felder für die Quelle 11 sind weg. Es werden in Richtung des Downlinks nur noch entweder die bekannten MACs oder die Broadcasts geschickt. Das reduziert den Traffic erheblich.

Hier die Zusammenstellung aller Ergebnisse im restrictive Mode:

Bis auf die Uplinks bekommt kein Link mehr Frames mit unbekannter Ziel-MAC.

Ein weiteres Teilziel geschafft.

Weil immer wieder die Frage aufkommt, was den die Impfung eigentlich ist und wie sie wirkt. Und warum man nach der Impfung nicht komplett immun ist, warum es Fälle von positiven Tests von Geimpften gibt.

Der Impfstoff ist ohne ausreichende Kühlung transportierbar. Er ist dann binnen weniger Tage aufzubrauchen. Man kann ihn auch gar nicht beim -80°C verimpfen. Andere Impfstoffe sind nicht ganz so empfindlich, brauchen dafür aber mehr mRNA um wirksam zu sein.

Der Impfstoff ist ein mRNA Molekül, dass von die körpereigenen Zellen zur Produktion des Spike-Protein auffordert. Diese mRNA ist im Körper nur sehr kurze Zeit haltbar, sie dient eigentlich dazu, Informationen aus dem Zellkern zu den Ribosomen in der Zelle zu transportieren (ein Bote, ein Messenger). Sie wird vom Körper dann direkt wieder zerlegt. Deswegen hält die Produktion des Spikeprotein auch nicht lange an. Es kommt ja keine neue mRNA nach. Über Langzeitschäden oder ähnlichen Unsinn zu spekulieren verbietet sich damit unmittelbar.

Das Spikeprotein allein kann keinen Schaden anrichten. Aber das Immunsystem erlernt es als körperfremd zu erkennen, Das dauert einige Tage. Nun haben sich Antikörper gebildet, die das Spikeprotin erkennen. Aber die sind kurzzeitig, halten sich also nur einige Monate.

Mit der zweiten Impfung trifft das Protein auf einen vorbereiteten Körper, der nun - als wiederkehrendes Ereignis - langfristige Maßnahmen ergreift (T-Zellen etc,) Was passiert aber nun bei einer Infektion? Nun ja, die Viren gelangen in den Nasen und Rachenraum, der für das Immunsystem nur schwer zugänglich ist. Darüber hinaus tarnen die Viren ihre Spikeproteine mit Zucker. Erst, wenn im Rachenraum die Virenproduktion los geht, kann das Immunsystem reagieren. Das ist übrigends der Grund dafür, dass Erkältungskrankheiten so schwer in Griff zu bekommen sind, auch wenn man nicht schwer daran erkrankt.

Bei SARS-CoV2 ist diese Vermehrungsphase aber gleichzeitig die infektiöse Phase. Ein Geimpfter ist also erst mal weiterhin infizierbar, dann ansteckend und natürlich auch positiv testbar, denn da sind ja Viren! Aber er erkrankt nicht mehr schwer, weil das Immunsystem nun rechtzeitig und korrekt reagieren kann.

Das bedeutet aber insbesondere, dass man den medialen Hype um das rettende Vaccin sich besser stecken lassen sollte. Begriffe wie "Herdenimmunität" setzen voraus, dass die Infektionsphase eingedämmt wird. Dazu liegen aber gar keine Informationen vor. Es kann sein, dass das Immunsystem schon so früh reagiert, dass die infektiöse Phase sehr kurz wird, aber das ist nicht sicher. Also sollte man aktuell nicht darauf bauen.

Wie angekündigt, wurde in einem Kundennetz das OSPF komplett umgekrempelt. Dabei gab es mehrere Überraschungen, die mit zwei ernsthaften Zwischenfällen einher gingen. Ein Rückblick.

Vorgehensweise

Der geplante Ansatz war, das Routing der BGP-Außenrouter untereinander in eine extra OSPF Instanz zu verschieben und die Default-Route in die jeweilige Standort-Area einzuspeisen, sowie die notwendigen Routen aus der Standort-Area zu lernen.

Dieser Teil des Konzeptes wurde wie folgt geändert:

• Die BGP-Außenrouter kommen in die Area 0 statt in die Standortareas. Hintergrund ist, dass das Erlernen der (meist statischen) Routen aus einer normalen Area heraus nicht möglich ist, da redistributierte Routen im OSPF area-übergreifend sind.
• Anstatt die Loopback-IPs der BGP-Außenrouter zwischen zwei OSPF-Instanzen zu redistributieren, wurde die Verbindung der BGP-Außenrouter untereinander in eine extra Area verschoben, deren Intra-Area-Routen gegenüber den anderen OSPF-Routen stets bevorzugt wird. Damit ist die Routing-Trennung erfolgreich durchgeführt.
• Um die Standorte zu trennen wird auf den Leitungen zwischen den Standorten eine OSPF-Cost von 1000 eingetragen. Lokale verfügbare Routen haben damit eine Metrik von kleiner 1000 und können per "match metric 450 +- 500" in route-maps leicht erkannt werden.

Die Umstellung erfolgt schrittweise:

1. Die aktuelle Redistribution von OSPF nach BGP wird von Standortinformationen befreit. Alle Routen werden an allen Standorten weiter injeziert. Damit kann man umbauen, ohne die Außenverbindung zu verlieren.
2. Die Standort-Router wandern zusätzlich in die Area 0, ohne die Standorte direkt miteinander zu verbinden. Auf diese Weise bleibt das Routing über die BGP-Außenrouter bestehen.
3. Aggregierung verschiebt sich von den BGP-Außenroutern zu den Standort-Routern.
4. Die BGP-Außenrouter verlieren ihre Verbindung in die jeweilige Standortarea. Sie kommunizieren nun nur noch über die Area 0.
5. Die für das BGP benötigten Interfaces (Loopback) wandern in eine neue Area,  die aktuell fragmentiert ist. Da über die Area 0 aber nur Interarea-Routen ohne Angabe der originalen Area-Nummer verteilt werden, bekommen die Router weiterhin ihre BGP-Nachbarn erlernt.
6. Die BGP-Außenrouter werden nach und nach mit extra VLANs zu einer eigenen OSPF-Wolke verbunden. Sie erreichen nun ihre BGP-Nachbarn direkt über diese neue OSPF-Area, nicht mehr über die Area 0.
7. Die Area 0 kann zwischen den Standorten direkt verbunden werden. BGP-Quertraffic geht ja nun nicht mehr über diese Area.
8. Die Area 0 zwischen den BGP-Außenroutern wird entfernt. Sie reden nun in der Area 0 nur noch mit den jeweiligen Standort-Routern.
9. Die Kosten auf der Querverbindung der Standorte werden angehoben. Man kann nun anhand der Metrik die Lokalität der Routen erkennen.
10. Routen aus dem OSPF werden nun anhand der Metrik gefiltert, so dass der alte Zustand (lokale Routen am Standort announcen) wieder hergestellt ist.

Soweit der Plan. Aber in der Praxis sieht das alles noch etwas anders aus.

Überraschungen

Zunächst einmal ist fest zu stellen, dass der oben stehende Plan sich erst während der Umstellung heraus bildete. Jeder einzelne Schritt wurde in der Praxis so ausgeführt, dass das Monitoring des gesamten Netzes auf sehr feine Details achten konnte. So wurde binnen einer Minute erkannt, wenn mehr als 10 von 70000 versorgten Endgeräten unzureichende Kommunikation hatten.

Um sich nicht selbst abzuschießen, erfolgte der Management-Zugriff bei IPv4 Änderungen über IPv6 und umgekehrt. (Vorzugsweise gibt es Management nur über IPv6.)

Der Ablauf des Umbaus war also folgendermaßen:

• Vornehmen einer einzelnen Änderung an einem einzelnen Gerät.
• Beobachten des Monitorings für ca. 10 min.
• Gibt es einen Abfall, wird die Änderung zurück genommen. Kehrt das Monitoring zu normalen Werten zurück, muss man nachdenken, was man gerade falsch gemacht hat.
• Bleibt der Abfall bestehen, wird rumtelefoniert, ob jemand anders am Netz ebenfalls Änderungen vornimmt oder ungeplanten Ausfälle erkennbar sind. Ist das der Fall, wird Stabilität im Netz abgewartet und die Änderung nochmal versucht.

Auf diese Weise hat sich der Umbau über fast zwei Wochen hin gezogen. Dabei durften Zwischenstände mit massiv eingeschränkter Performance (wenn der gesamte Traffic nur über eine statt vier Leitungen läuft) nicht über die Hochlastzeiten bestehen bleiben.

Einer der Fälle, die auf diese Weise aufgefallen ist, war: Man trenne die Area0 zwischen den BGP-Routern nicht, bevor es eine direkte Area0 Kopplung der Standorte gibt!

Aber es gab auch schwerere Fälle, die besonders lehrreich sind.

Zum einen hatten wir einen Standort-Router mit einer kaputten OSPF-Datenbank.

Das ist im Normalbetrieb nicht aufgefallen, als aber größere Umstellungen passierten, routete er nicht so, wie man es erwarten sollte. Es gab Kreisrouting und Paketverlust. Nach einem ganzen Tag ständiger Versuche, konnte der Übeltäter eingekreist werden. Ein beherztes "clear ip ospf process" am kommenden Morgen brachte spontane Besserung. Alle bis dahin unerklärlichen Vorfälle waren verschwunden und die Konfigurationsänderungen zeigten die erwünschte Wirkung.

Da nicht alle Geräte zur gleichen Zeit einer Änderung folgen konnten, wurde die Umstellung durch Aufbau von parallelen Verbindungen nach einem neuen VLAN-Konzept durch geführt. Dabei wechseln die beteiligten Geräte einzeln in ein neues VLAN mit neuen IP Adressen. Viele Point-to-Point Verbindungen sind jedoch als "unnumbered" Interface ausgeführt um Adressen zu sparen.

Der interessante Effekt tritt auf, wenn das referenzierte Interface seine iP-Adresse verliert (durch den Umzug auf ein anderes VLAN). In dem Fall bleibt das unnumbered Interface im OSPF aktiv in der Area. Es verbreitet weiter Routing-Informationen und spricht mit den OSPF Nachbarn. Sollen dann aber Datenpakete über dieses Interface geschickt werden, so verwirft der Cisco-L3-Switch diese Pakete kommentarlos. Das unnumbered Interface wird zum aktiven Blackhole. Erst, als das Interface auf shutdown gesetzt wurde, war der Spuk vorbei.

Weil's so wichtig ist, hier nochmal das Rezept:

• Man erzeuge ein VLAN zwischen zwei Geräten, dass "ip unnumbered xxx" als Point-2-Point Interface  auf beiden Seiten eingerichtet wird.
• Man nehme das Interface XXX und damit das Vlan-Interface per "network"-statement ins OSPF auf.
• Man etabliere eine OSPF Kopplung über das VLAN-Interface zum Nachbarn.
• Nun lösche man die IP Adresse vom Interface XXX mit "no ip address".
• Das Vlan-Interface verbleibt voll funktional im OSPF: Es hält Nachbarschaftsbeziehungen und Routing-Updates aufrecht.
• Ein- und ausgehende Datenpakete über das Interface werden verworfen: Black Hole.

Die von dem Verhalten ausgehenden Störungen waren sporadisch, aber merkbar. Es hat ziemlich lange gedauert, das Phänomen zu verstehen und gezielt in Angriff zu nehmen. Auslöser der Erkenntnis war dann eine Fehlereingrenzung auf einen deutlich merkbaren, stabilen Stör-Pfad, bei dem Interfaces stückweise shutdown genommen wurden.

Und dann war da noch der wirklich heftige Ausfall, der einen Standort komplett erdete. An diesem Standort gab es noch Überreste einer älteren NSSA, die nun wirklich weg geräumt werden sollte. Aber wie wechselt man bei einem Gerät, das unter Last steht, die OSPF Area? In dem Fall handelt es sich um die Anycast-DNS Server, die mit vier externen Beinen sowohl ihre DNS Anfragen machen, als auch ihre OSPF-Uplinks bedienen. Die Interfaces auszuschalten, kam wegen der DNS-Nutzung nicht in Frage.  So kam die Idee auf, diese Maschinen in zwei regionale Areas gleichzeitig zu stellen.

Grundsätzlich ist es möglich, einen Router in zwei Areas zu haben, auch wenn keine davon die Area 0 ist. Dies wird ausführlich in verschiedenen Design Dokumenten von OSPF diskutiert, und zwar wird dabei betont, dass dieser Router keine Routen von der einen in die andere Area weiter leiten wird. Das wäre ja sogar ein gewünschtes Verhalten. Die Software bird auf FreeBSD fand die Idee auch erstmal ganz gut und importierte aus beiden Areas die Routen.

Allerdings injezierte sie die nun widersprüchlichen Ziele für die exteren Routen nicht in die Kernel-Routing-Tabelle. Auf diese Weise verloren die DNS-Server ihre Default Route und konnten keine neuen DNS Namen mehr auflösen. Das fiel auf die Schnelle natürlich nicht auf, dann aber um so heftiger. Ohne DNS brach die Internet-Versorgung des Standorts zusammen.

Der Fehler war nach einer guten Viertelstunde behoben und der alte Zustand wieder her gestellt. Bis sich der Rest beruhigte, dauerte es noch ein wenig länger. Die eigentliche Lösung bestand dann darin, mit einem Schlag die Area zu wechseln. Das klappte dann problemlos.

Ein Kundennetz ist im Laufe der Zeit organisch gewachsen. Irgendwann kommt dann der Augenblick, wo man es in verschiedene Standorte trennen muss. Denn es gibt ungeplante Überlastungssituationen.

Ausgangslage

Das Netz besteht aus einigen Au0enroutern an den Rändern und innen aus einer Reihe von Layer3-Switchen. L3-Switche sind Geräte, die genauso schnell routen wie switchen können, allerdings nur mit einer beschränkten Anzahl von Routen, weil sonst die Hardwarekosten explodieren.

Seit einiger Zeit sind einige der Geräte an einen anderen Standort umgezogen. Nun kann man nicht mehr bei Bedarf einfach wild Querverbindungen zwischen den Geräten patchen. Es gibt drei Leitungen zwischen den Standorten sowie separate Uplinks und das war es.

Geroutet wird per OSPF. Streng nach Design Guide gibt es zwei lokale Areas, in denen Ziele bevorzugt direkt erreichen werden können. Und dazwischen gibt es eine Area 0, den Backbone, der alles aufnimmt, was in den einzelen Areas nicht zu finden ist.

Konsequenterweise ist die Area 0, also die Resterampe des Routings, die Quelle der Default Route, auch das Heim der BGP Router mit Außenanbindung. Diese kennen so viele Routen, dass man diese den Switchen keinesfalls  erzählen darf, sollen die nicht spontan an Herzdrücken versterben. So gesehen, sind die Außenrouter eigentlich in der Mitte des OSPF Protokolls.

Die Area 0, der Backbone, darf nicht mit seinen externem Routen die L3-Switche berühren. Denn diese würden die Pakete per Default Route einfach nur wieder zurück zum lokalen BGP Router schicken, und der wieder ... ein Routing-Loop. Deswegen besteht die Area 0 eigentlich aus switchübergreifenden VLANs, in denen die BGP-Router je ein Bein stehen haben.

Für das OSPF sieht es also so aus, als gäbe es drei LAN-Segmente, die die Router direkt miteinander verbinden.

In der Realität ist dem allerdings nicht so, denn die OSPF-Idee eines LAN-Segmentes kommt noch aus der Zeit des echten Ethernets, wo alle Geräte im wahrsten Sinne an einem gemeinsam genutzten Strang hängen. Dabei ist es komplett egal, wer mit wem redet, das Medium ist für alle gleich teuer in der Benutzung.

In der Realität der heutigen, strukturierten Ethernet-Verkablung sieht es allerdings ganz anders aus. Hier wandert ein Datenpaket zwischen zwei Routern in Form eines Ethernet-Frames mehrfach über verschiedene Leitungen, oft sogar mehrfach über die gleiche physikalische Strippe.

Eine solche Mehrfachbenutzung ist bei begrenzten Ressourcen ein Problem. Konkret aufgefallen ist es als sieben Gbps über mehrere Stunden transportiert werden mussten. Dann blieb auf den 10G-Leitungen der Router kaum noch was für anderen Traffic frei.

Lösungen

Die einfachste Lösung ist, neue Technik zu kaufen, die um den Faktor 4 oder 10 höhere Leitungskapazitäten anbietet. Leider versackte die Bestellung und wird auch so schnell nicht realisiert werden.

Eine zweite Lösung wäre, die Standorte als eigenständige BGP Inseln zu betreiben.

Das hält den Traffic lokal und der Datenverkehr zwischen den Bereichen lässt sich feingranular steuern. Selbst Loadbalancing über mehrere Wege ist kein Problem. Zusätzlich reizt an dem Ansatz, dass die extern sichtbaren Routen schon an der Stelle fertig im BGP erzeugt werden können, an den sie entstehen.

Leider fehlt für die Benutzung von BGP die Lizenz auf den L3-Switchen. Deren Beschaffung ist auch nicht so einfach, denn auch hier hängen Bestellprozesse dran.

Bleibt also nur der Versuch, die Datenflüsse innerhalb des OSPF selbst neu zu sortieren. Dabei gibt es einige grundlegende Konzepte:

• Die Area0 dient als Bindeglied zwischen den anderen Area.
• Traffic, der in einer Area zugestellt werden kann, verlässt diese Area nicht (intra-Area first).
• Traffic, den sich die BGP-Router gegenseitig zustellen, darf mit keinen anderen Routern in Berührung kommen.
• Traffic, der nicht extern zugestellt werden soll, soll schnellstmöglich an die L3-Switche übergeben werden.

Damit ergibt sich, dass das gesamte Netz auf den Kopf zu stellen ist:

• Die Area 0 kommt ganz nach innen, sie bildet die Standortkopplung.
• Pro Standort gibt es ein eigne Area, die den Traffic am Standort fest hält.
• Die BGP-Außenrouter gehören zwar zum Standort, den sie bedienen, kommunizieren aber untereinander über eine komplett eigene Struktur.

Die Interaktion zwischen den Außenroutern und der jeweiligen Area besteht grundsätzlich darin, dass die BGP-Router eine Default-Route in die lokale Area injizieren und aus der Area lernen, welche Netze in beiden Standorten bedient werden können.

Das Injizieren der Default-Route durch die BGP-Router in die jeweilge lokale Area ist kein Problem. Die BGP-Router werden somit zu ASBRs. Im Gegenzug werden alle Geräte am Standort zu einem lokal nahe gelegenen BGP-Router routen. Traffic, der das Netz verlässt, tut es am gleichen Standort.

Umgekehrt lernen die BGP-Router die internen Routen aus dem OSPF und können sie ins BGP redistributieren. Dabei setzen sie Communities etc. pp. Dies sind vor allem die extern sichtbaren Aggregates des Autonomen Systems. Erzeugt man die Aggragate (per Null-Route) lokale auf dem BGP-Router, besteht die Gefahr des Blackholings, insbesondere wenn der BGP-Router keine funktionierende Verbindung nach innen hat.

In der rot gepunkteten Area tauschen die BGP-Router untereinander ihre für die BGP relevanten Loopback-Adressen aus. Über diese sprechen sie internal BGP miteinander. Es sind die Next-Hop Adressen der externen Ziele, die ein BGP-Router anderswo los werden muss. Dabei gibt es einiges zu beachten:

• Die vom internen BGP erzeugten Routen haben als Next-Hop eine (Loopback-)IP die im rot gepunkteten Bereich auftaucht. Diese IPs dürfen keinesfalls durch das interne OSPF hindurch erreichbar sein, weil das zu Routing-Loops für externe Ziele führt.
• Die Loopback-IPs der BGP-Router sollen aus dem internen Bereich erreichbar sein,  auch wenn sie von einer internen Sammel-(Aggregate)-Route überdeckt werden.
• Bestimmte externe (Eyeball-)Ziele sollen auch standortübergreifend auf dem jeweils besten Weg erreicht werden. Diese Ziele sollen direkt zum zuständigen BGP-Router gelangen, nicht erst eine extra Runde im rot gepunkteten Bereich laufen müssen.

Um diese Anforderungen zu erreichen, muss man zwischen verschiedenen Routing-Protokollen redistributieren. Gleichzeitig, darf die rot gepunktete Area nicht einfach Bestandteil der gleichen OSPF Instanz sein, die auch die internen Areas bedient. Zwischen zwei nicht-backbone Areas, die am gleichen Router anliegen erfolgt kein Austausch von Routen, deswegen würden die Loopback-IPs nie in den internen Bereich gelangen. Mit zwei OSPF Instanzen geht das aber problemlos.

Die BGP-Router haben nur vier verschiedene Quellen für Routing-Informationen:

• externes BGP
• OSPF zwischen den BGP-Routern
• OSPF im internen Netz
• internes BGP

Externes BGP kann aufgrund der Eingangsfilter keine netzinternen Routen enthalten. Dieser Teil ist für (interne) Routingprobleme also irrelevant.

OSPF zwischen den BGP-Routern muss immer zuerst berücksichtigt werden. Egal welche Metriken eine Route hier hat, es ist ein BGP-Peer und damit auf diesem Weg zu erreichen. Anderenfalls gibt es Routingloops für externe Ziele.

Wenn ein anderes internes Ziel erreicht werden soll, dann ist das immer unmittelbar an die inneren Router abzugeben. Anderenfalls gibt es das eingangs skizzierte Problem der Überlastung von Leitungen.

Interne Ziele, die über iBGP (von anderen BGP-Routern gelernt und redistributiert) erreichbar sind, müssen zwar an externe Partner übermittelt werden, damit das Netz extern erreichbar bleibt. Traffic an interne Ziele sollten aber nur dann an andere BGP-Nachbarn geroutet werden, wenn man diese Ziele nicht über interne Wege erreichen konnte.

Es beitet sich also an, für das OSPF zwischen den BGP-Routern eine eigene Instanz zu betreiben. Aus dieser Instanz kann in die andere OSPF-Instranz redistributiert werden. Und diese wird mit einer niedrigeren administrativen Distanz versehen:

Und nun bleibt die Aufgabe, dieses Umstellung im laufenden Betrieb vor zu nehmen.