Der Wirkungsradius
Jeder Link und jeder Router auf einmal geprüft, und warum Graphentheorie daraus 13 Millisekunden macht
Michel Wijnberg
“Was passiert, wenn ich das kaputt mache?” ist eine Frage nach einer Sache. Die Frage, auf die eine Architektin tatsächlich eine Antwort braucht, ist die Umkehrung, und sie ist viel schwerer:
Von allem in diesem Netzwerk: Welche Teile sind wichtig?
Dorthin kommen Sie nicht, indem Sie Links einzeln anklicken. AS 200 in meinem Labor hat 275 Links und 64 Router. Jeden einzelnen Ausfall von Hand zu prüfen sind 339 Experimente, und sie müssen bei jeder Topologieänderung wiederholt werden.
Also macht Osprey sie alle auf einmal. Was das einbringt, ist eine Auswahlliste: von 339 Dingen, die ausfallen können, die Handvoll, die Sie wirklich etwas kosten würde. Das ist der Unterschied zwischen einer Redundanzprüfung, die Sie fürs nächste Quartal einplanen, und einer, die Sie vor der Freigabe einer Änderung laufen lassen.
Jeder Link, jeder Router, dreizehn Millisekunden
Lesen Sie die Kopfzeile: “1 with impact in 13ms”, und darunter die Erklärung, was geprüft wurde: “Links whose failure causes device isolation. Redundant links omitted.”
Jeder Link des Mandanten wurde bewertet. Genau einer davon, mia1-cr1 ↔ mia1-gw1,
isoliert überhaupt etwas, und was er isoliert, ist ein Router: mia1-gw1. Stellen
Sie den Schalter auf Node Failures, und die Antwort ist das Spiegelbild: von
64 Routern strandet genau einer (mia1-cr1) genau einen anderen.
Das ist das Ergebnis, das eine Architektin will: keine Liste von 275 Zeilen zum Durchlesen, sondern die Aussage, dass 274 davon nachweislich uninteressant sind.
Dieselbe Schwachstelle, dreimal gefunden, durch drei Protokolle
Die strukturelle Sicht auf denselben Sachverhalt hat ihren eigenen Bericht:
64 Geräte, 275 Links analysiert, 1 Artikulationspunkt (mia1-cr1,
172.16.4.31) und 1 Brücken-Link. Ein Artikulationspunkt ist ein Knoten, dessen
Entfernung die Zahl der Zusammenhangskomponenten erhöht, der graphentheoretische
Name für “wenn dieser Router stirbt, zerfällt das Netz”.
Hier kommt der Teil, den ich nicht geplant habe und der mir am besten gefällt. Ich habe denselben Bericht für die beiden anderen Mandanten laufen lassen:
| Mandant | IGP | Artikulationspunkt | Brücken-Link |
|---|---|---|---|
| Harrier-Broadband | OSPFv2 | mia1-cr1 | mia1-cr1 ↔ mia1-gw1 |
| Kestrel-Dynamics | EIGRP | e-mia1-cr1 | e-mia1-cr1 ↔ e-mia1-gw1 |
| Merlin-Carrier | IS-IS | i-mia1-cr1 | i-mia1-cr1 ↔ i-mia1-gw1 |
Drei Carrier. Drei verschiedene IGPs. Drei völlig getrennte Erkennungswege:
OSPF-LSDB-Walks, Nachbartabellen aus der CISCO-EIGRP-MIB, IS-IS-LSPs. In jedem
dieselbe strukturelle Schwachstelle, an derselben Stelle.
Die ehrliche Erklärung ist, dass ich das Labor aus einer Vorlage gebaut und Miami
dreimal ein Gateway mit nur einer Anbindung gegeben habe. Aber genau das macht es
zu einer nützlichen Probe: Derselbe physische Fehler, Osprey über drei
unverwandte Protokollmodelle beschrieben, ergab dieselben drei Antworten. Hätte
die IS-IS-Topologieextraktion einen Fehler, wäre i-mia1-cr1 die Stelle, an der
die Abweichung aufgetaucht wäre.
Ich wusste nicht, dass das im Labor steckt, bis das Werkzeug es mir sagte. Es war wochenlang da, in einem Labor, das ich eigens gebaut habe, um Dinge zu finden.
Das ist der Teil, den man von der Graphentheorie trennen sollte, denn die Theorie ist die unspektakuläre Hälfte. Artikulationspunkte und Brücken stehen im Lehrbuch, und jedes Werkzeug kann sie über jede Zeichnung berechnen. Ob die Antwort etwas bedeutet, entscheidet sich daran, was die Knoten und Kanten sind. Ospreys Graph ist kein Diagramm, das jemand gepflegt hat: er wird aus dem rekonstruiert, was die Router selbst fluten, und deshalb ist eine Brücke darin eine Aussage über Forwarding und nicht über ein Bild. Lassen Sie denselben Algorithmus über eine veraltete Visio-Datei laufen, und Sie bekommen dieselben Formen und nichts von der Wahrheit.
Warum die Antwort da ist, bevor Sie die Maus loslassen
Dreizehn Millisekunden für 275 Ausfallszenarien sind nicht das Ergebnis raffinierter Parallelisierung. Sie sind das Ergebnis davon, die Arbeit nicht zu tun.
Ein Link, dessen Entfernung einen Graphen zerlegt, ist eine Brücke: eine Kante, die auf keinem Zyklus liegt. Tarjans Algorithmus zum Finden von Brücken identifiziert jede einzelne in einem einzigen Tiefendurchlauf, O(V+E), für den ganzen Graphen auf einmal. Und ein Link, der keine Brücke ist, kann unmöglich etwas isolieren: Er liegt per Definition auf einem Zyklus, es gibt also einen anderen Weg herum.
Die Bewertung findet also zuerst die Brücken und simuliert nur diese:
// Precompute bridges in O(V+E). These are the only links that can
// cause unreachable devices when removed.
bridgeLinks := spf.FindBridges(baselineMerged)Dann entfernt sie noch eine Klasse. Wenn zwei Router durch mehrere parallele Links verbunden sind, kann keiner davon eine Brücke im entscheidenden Sinne sein, denn lässt man einen ausfallen, bleiben die anderen:
// Parallel links: if a device pair has multiple links, failing any one
// cannot disconnect them. Remove such links from the bridge set.274 Links werden durch einen Satz aus der Mathematik ausgeschlossen und nicht durch eine Erreichbarkeitsprüfung. Ein Link wird simuliert. Das ist der ganze Trick, und deshalb ist die Antwort da, bevor Sie die Maus losgelassen haben. In einem hundertmal so großen Netz ist es immer noch ein Durchlauf plus eine Handvoll Prüfungen.
Graphentheorie ist hier keine Dekoration. Sie ist der Unterschied zwischen einem Bericht, den man startet, und einem Bericht, auf den man kurz schaut.
Was “kritisch” bedeutet, wenn nichts kritisch ist
Der Reiter Critical Pairs beantwortet eine Frage einen Schritt weiter draußen: welche zwei Links, von denen keiner ein Single Point of Failure ist, sind gemeinsam tödlich?
Das ist eine wirklich fiese Risikoklasse. Keiner der beiden Links taucht in irgendeinem SPOF-Bericht auf. Keiner allein bewirkt etwas. Nehmen Sie beide (derselbe Kabelkanal, dieselbe Karte, dasselbe Wartungsfenster), und das Netz zerfällt.
Sie zu finden heißt, für jede Nicht-Brücken-Kante diese zu entfernen und die Brückenerkennung auf dem Rest erneut laufen zu lassen. Das ist O(L·(V+E)) und das Teuerste im ganzen Bericht.
In allen drei Mandanten lautet die Antwort null, und das Panel sagt es in Worten:
No critical link pairs detected — your topology has good redundancy.
Eine Null, die echte Arbeit gekostet hat, ist mehr wert als eine lange Liste. Diese hier sagt: Es gibt in diesem Netz kein Linkpaar, dessen gleichzeitiger Verlust es aufteilt, und das wurde erschöpfend geprüft und nicht angenommen.
Wirkungsradius ist nicht nur Topologie
Struktur ist eine Art von Abhängigkeit. Die andere ist Erreichbarkeit, und die misst man in Adressraum:
| Peer-AS | Peers | Präfixe | IP-Raum | CIDR-Äquivalent |
|---|---|---|---|---|
| 100 | 2 | 3 | 131.328 | /15 |
| 300 | 2 | 3 | 131.074 | /15 |
Drei Präfixe klingen nach wenig, bis sie als 131.328 Adressen, also ein /15-Äquivalent dargestellt werden, die nur über AS 100 erreichbar sind. Zählungen von Präfixen sind ein schlechter Stellvertreter für Exposition (ein /15 und ein /32 zählen beide als “1”), also rechnet der Bericht in Adressraum um und wieder zurück in ein CIDR-Äquivalent, und das ist die Einheit, in der eine Architektin tatsächlich denkt.
Daneben schneidet der Bericht jedes kritische Linkpaar mit den SRLG-Gruppen seiner Mitglieder, sodass zwei Links, die auf der Karte unabhängig aussehen, sich aber einen Kabelkanal teilen, als korreliert und nicht als diversitär gemeldet werden.
Womit ich bei der Lücke bin, die ich lieber selbst benenne, als dass Sie sie finden.
Der Teil, der ehrlich und unfertig ist
Ospreys SRLG-Unterstützung ist in jede Richtung vollständig bis auf eine. Sie können Gruppen definieren, Links zuordnen, eine ganze Gruppe als eine einzige Simulationsveränderung ausfallen lassen und die Korrelation gemeinsamer Risiken im Abhängigkeitsbericht sehen. Was Sie nicht können, ist sie zu entdecken.
Nichts füllt die SRLG-Tabelle. Jede Gruppe wird von Hand eingetragen. Osprey speichert die Traffic-Engineering-Sub-TLVs nach RFC 5305, die es in IS-IS sieht, als rohe Bytes, dekodiert aber das SRLG-Sub-TLV noch nicht. Ein Netz, das seine Shared-Risk-Gruppen bereits im IGP ankündigt, hat davon also nichts.
Der Verbraucher wurde vor der Quelle gebaut. Das ist die falsche Reihenfolge, es steht auf der Roadmap, und bis es fertig ist, lautet die ehrliche Beschreibung der Funktion “SRLG-Simulation, aus Gruppen, die Sie ihr nennen”, und nicht “SRLG-Erkennung”.
Diesen Satz schreibe ich lieber selbst, als dass jemand ihn während einer Evaluierung entdeckt.
Warum das der Bericht ist, den ich als Erstes laufen ließe
Wenn ich morgen ein Netz erben würde, wäre das Erste, was ich wollte, keine Karte. Es wäre die Antwort auf drei Fragen:
- Welche Einzelausfälle isolieren tatsächlich etwas? (Ein Link. Ein Router.)
- Welche Ausfallpaare tun das, die kein Bericht über Einzelausfälle zeigen würde? (Keine: geprüft, nicht angenommen.)
- Wie viel Adressraum hängt hinter jeder externen Abhängigkeit? (Ein /15 je Peer-AS.)
Alle drei lassen sich aus einem Modell berechnen, das bereits korrekt ist, in deutlich unter einer Sekunde, ohne einen Router anzufassen. Das ist das ganze Argument dafür, vier Beiträge darauf zu verwenden, zuerst das Modell richtig zu bekommen: Ein genaues Modell ist nicht das Produkt, es ist der Untergrund, auf dem die nützlichen Fragen laufen.
Als Nächstes die Zahl, um die dieser Beitrag stillschweigend herumgekommen ist. Wie viel Verkehr sich tatsächlich bewegt, wenn dieser Link ausfällt, und warum mein Labor mir das nicht sagen kann. Schätzen, was man nicht messen kann.