Zurück

Der perfekte Sturm (Warum ist er gescheitert?)

by Tod Bristol 2. Juni 2017

Willkommen bei The Perfect Storm!

In dieser Serie schauen wir uns die an Nicht so offensichtlich Szenarien, in denen die „richtige“ Kombination „falscher“ Dinge passiert ist und das Ergebnis zu einem Verlust an Erreichbarkeit, Konnektivität usw. führt. Nachdem wir den Fehler besprochen haben, gehen wir zurück und bestimmen, was passiert ist (Warum ist es fehlgeschlagen?). Wir werden auch untersuchen, wie der Fehler möglicherweise verhindert oder minimiert wurde NetBrain.

Lass uns anfangen!!

Netzwerkübersicht: Was ist das Szenario?

In diesem Szenario stellen wir fest, dass ein Abschnitt des Netzwerks während des Akzeptanztests nicht mit einer cloudbasierten Ressource kommunizieren kann.

Hier ist die Netzwerkumgebung, mit der wir arbeiten:

NetBrain Perfectstorm-Blog1

Abbildung 1: Konnektivität des Rechenzentrums mit der AWS Cloud

RT1 und RT2 sind jeweils über BGP in eine AWS-Umgebung eingebunden, und jeder hat einen anderen Physik Pfad in AWS. Diese beiden Router haben über das 172.16.110.0-Netzwerk eine iBGP-Beziehung miteinander. Darüber hinaus führen RT1 und RT2 OSPF in zwei separaten Netzwerken aus: dem 172.16.110.0-Netzwerk und dem 10.70.28.0-Netzwerk. Der Datenverkehr im 10.70.28.0-Netzwerk (von RT1 und RT2) wird durch eine Firewall geleitet, um zu einem dritten OSPF-Nachbarn, RT3, zu gelangen, der das Layer-3-Routing/den Datenverkehr für Rechenzentrums-Subnetze handhabt.

Fehlerübersicht: Die richtige Kombination der falschen Dinge

An den letzten beiden Abenden um 11:10.17.1.0 Uhr führte eine Netzwerkverwaltungsstation im 10.192.16.0-Netzwerk Leistungstests für einen AWS-Host im 10-Netzwerk durch. Die Tests dauern normalerweise 15-2 Minuten. In der dritten und letzten Testnacht werden die Tests auf @XNUMXam verschoben, mitten im Wartungsfenster des AWS Circuit-Anbieters (wo Wartungsarbeiten durchgeführt werden). Physikalischer Weg A). Obwohl von keinem der Hosts im Rechenzentrum verbindungsbezogene Probleme gemeldet wurden, schlugen die von der Netzwerkmanagementstation ausgeführten Leistungstests fehl. Warum ist es gescheitert?

METHODIK ZUR FEHLERBEHEBUNG

Sehen wir uns die Umgebung genauer an, sehen wir uns an, was sich geändert hat, und bestimmen wir, wie diese Änderungen die Umgebung beeinflusst haben. Also, was ist in der ersten und zweiten Testnacht passiert? Lass uns einen Blick darauf werfen:

  • Die Network Management Station hat versucht, einen Host im AWS hinter VPC F zu erreichen.
  • Verkehr von der Station wurde an das HSRP Primary Gateway gesendet, das RT1 war.
  • RT1 hatte eine BGP-installierte Route zu 192.16.0, die es vom AWS BGP-Peer (VGW) erlernte, der mit VPC F verbunden war.
  • Der Datenverkehr wurde an den Peer weitergeleitet.
  • Rückverkehr vom VPC-Host wurde aus dieser VPC an RT1 weitergeleitet, da RT1 das 10.17.1.0-Netzwerk an AWS angekündigt hatte (sowohl RT1 als auch RT2 haben diese Routen angekündigt, RT2 hatte jedoch den Pfad in seiner Ankündigung vorangestellt).
  • RT1 leitete den eingehenden Datenverkehr zu seiner direkt verbundenen Schnittstelle zu 17.1.0. wo sich die Station befindet.
  • Erfolg!!

Schauen Sie sich JETZT genau an, was in der dritten Nacht passiert ist!! Zunächst können wir damit beginnen, das zu identifizieren, was wir wissen: Die primäre ISP-Verbindung wurde unterbrochen.

AWS-Konnektivität zu Routern

Abbildung 2: Veranschaulichung des Problems, dh Abbau der primären ISP-Verbindung

Lassen Sie uns als Nächstes darüber sprechen, wie sich die Unterbrechung in der Schaltung auf die Routing-Tabellen ausgewirkt hat … insbesondere auf RT1. Vor dem ISP-Wartungsfenster hatte RT1 eine eBGP-Route in seiner Tabelle vom eBGP-Peer von VPC F.

RT1#Schiffsroute 10.192.16.0

Routing-Eintrag für 10.192.16.0/24

Bekannt über „bgp 65535“, Distanz 20, Metrik 0

Tag 7224, geben Sie extern ein

Neuverteilung über ospf 1

Beworben von ospf 1 subnets route-map DENY-SUMM

Letzte Aktualisierung von 192.168.8.6 vor 00:04:10

Routing-Deskriptor-Blöcke:

* 192.168.8.6, von 192.168.8.6, vor 00:04:10

Die Routenmetrik ist 0, die Anzahl der Verkehrsanteile ist 1

AS Hopfen 1

Streckenmarkierung 7224

MPLS-Etikett: keine

RT1#

Nach der Unterbrechung sieht die Routing-Tabelle von RT1 jedoch ganz anders aus. RT1s Tisch hat jetzt XNUMX Einträge für das 10.192.16.0-Netzwerk, einen in Richtung RT2 auf seiner GigabitEthernet 0/3-Schnittstelle und einen in Richtung RT2 auf seiner GigabitEthernet 0/1-Schnittstelle.

RT1#Schiffsroute 10.192.16.0

Routing-Eintrag für 10.192.16.0/24

Bekannt durch „ospf 1“, Distanz 110, metrisch 400

Tag 7224, extern 2 eingeben, Metrik 1 weiterleiten

Weiterverteilung über bgp 65535

Letztes Update von 10.170.28.12 auf GigabitEthernet0/1 vor 00:00:37

Routing-Deskriptor-Blöcke:

* 172.16.110.12, vom 10.70.28.12, vor 00:00:41, über GigabitEthernet0/3

Die Routenmetrik ist 400, die Anzahl der Verkehrsanteile ist 1

Streckenmarkierung 7224

10.70.28.12, von 10.70.28.12, vor 00:00:37, über GigabitEthernet0/1

Die Routenmetrik ist 400, die Anzahl der Verkehrsanteile ist 1

Streckenmarkierung 7224

VIRL-PHX-AWS-RT1#

Aber wie würde dies zu einem Ausfall führen? Wie würde ein zusätzliches gültig Route dazu führen, dass die Verbindung der Verwaltungsstation mit VPC F fehlschlägt? Um dies zu verstehen, sehen Sie sich an, wie der Datenverkehr zwischen VPC F und dem Management-Subnetz fließt. Eingehender Datenverkehr fließt von VPC F in R2 (der einzige verfügbare Pfad) und dann hinunter zum Verwaltungssubnetz.

NetBrain Perfectstorm-Blog4

Abbildung 3: Verstehen der eingehenden Verkehrsströme

Ausgehender Datenverkehr nimmt einen anderen Weg. Dieser ausgehende Pfad wird zunächst vom aktiven HSRP-Mitglied für das Subnetz 10.17.1.0 vorgegeben. Es ist immer noch auf RT1 eingestellt. Obwohl der Datenverkehr jetzt über RT2 nach außen fließt, bleibt RT1 der aktive Router (Standard-Gateway) für das Subnetz 10.17.1.0. Befolgen Sie in diesem Sinne den folgenden ausgehenden Ablauf:

NetBrain Perfectstorm-Blog5

Abbildung 4: Verstehen der ausgehenden Verkehrsströme

Wir können den ersten Pfad sehen, der zum Standard-Gateway führt (dargestellt durch RT1), aber es gibt ihn zwei gleiche Sprünge auf dem zweiten Weg vertreten! Eine an RT2 über das Netzwerk 172.16.110.0 und eine an RT2 über das Netzwerk 10.70.28.0. Mit zwei gleiche Layer3-Routen zu RT2 verfügbar ist, übernimmt RT1 den Lastausgleich und sendet einen Teil des Datenverkehrs über den Pfad der Firewall (2B). Die Firewall sieht eine unvollständige Konversation und ruft „Asymmetrisches Routing“ und bricht sie ab.

URSACHENANALYSE

Jetzt, wo wir besser verstehen, was passiert ist, ist es vielleicht ein guter Zeitpunkt, sich zu fragen: „Wie konnte ich das kommen sehen?” Welche Fragen sollte ich mir stellen, um mich besser auf Situationen wie diese vorzubereiten, und welche Tools bieten einen besseren Einblick in meine Netzwerkinfrastruktur Underlay/Overlay? Wie werde ich besser“Netzwerk-Fehlerbehebung“ und nicht nur ein „Shooter“?

WIE NETBRAIN HÄTTE HELFEN KÖNNEN

Im obigen Beispiel wurde das Problem identifiziert, als wir das abbildeten traffic path. Unten habe ich verwendet NetBrain grafisch darstellen a traffic path indem Sie die Router fragen, wie sie von der Quelle (in diesem Fall habe ich RT1 verwendet…) zum Ziel gelangen:

NetBrain Perfectstorm-Blog6

Abbildung 5: Erstellen Sie die traffic path Verwendung von NetBrain

Unten NetBrain präsentiert uns die tatsächlichen Daten vor/nach der Wartung aus den Routing-Tabellen von RT1, die die tatsächlichen „Entscheidungsfindungsdaten“ für die darstellen traffic paths haben wir uns oben angesehen.

NetBrain Perfectstorm-Blog7

Abbildung 6: Die Routing-Tabelle von Router 1 zur Ermittlung der traffic paths

Und schließlich sehen wir (indem wir NetBrain um die BGP-Nachbarzustände vor und nach der Wartung von RT1 zu vergleichen) BGP, ein Peer-Zustand, der die Wurzel aller Ereignisse in diesem Szenario ist … Leerlauf (oder andere nicht etablierte Zustände) vs. etablierte Zustände zwischen RT1s BGP-Nachbarn.

NetBrain Perfectstorm-Blog8

Abbildung 7: Vergleich der Konfigurationen „vorher“ und „nachher“.

Die richtigen NetBrain Zusammen mit VIRL auf Paket ist eine unschlagbare Kombination zum Simulieren und Überwachen/Aufzeichnen von Netzwerkleistung und -eigenschaften in Echtzeit unter Verwendung echter „produktionsähnlicher“ Buildouts, die einfach dokumentiert und (Konfigurationen, Überwachung usw.) in eine Produktionsumgebung übertragen werden können.

Um darüber zu erfahren, lesen Sie unbedingt unseren Leitfaden: NetBrain, besuchen Sie https://www.netbraintech.com/platform/

Verbunden