Border Gateway Protocol (BGP): erweitertes Troubleshooting

Haben wir das Präfix empfangen?

Das Troubleshooting von BGP-Problemen im Inbound-Bereich ist der schwierigste Teil beim BGP-Troubleshooting. Wenn ein IP-Präfix nicht, wie zu erwarten wäre, in Ihrer BGP-Tabelle enthalten ist, kommen die folgenden zwei Ursachen infrage:

• Der Nachbar sendet das Präfix nicht.
• Ihre Eingangsfilter blockieren das Präfix.

Das einzige Tool, das Ihnen helfen kann, das Problem zu identifizieren, ist die Debugging-Möglichkeit in Ihrem Edge Router (da Sie normalerweise keinen Zugriff auf den anderen BGP-Nachbarn haben). Achten Sie beim BGP-Debugging darauf, dass ein BGP-Nachbar Ihnen mehrere Hunderttausend Routen senden kann.

Sie müssen also sicherstellen, dass die von der Troubleshooting-Sitzung generierte Debugging-Ausgabe den Router nicht überlastet. Außerdem werden die BGP-Präfixe nur dann gesendet, wenn sie sich ändern, nicht in regelmäßigen Abständen (wie RIP-Updates oder OSPF LSA Floods). Ihr Debugging Tool wird Ihnen deshalb erst ein IP-Präfix anzeigen, wenn es sich geändert hat (oder wenn Sie die BGP-Sitzung mit Ihrem Nachbarn beendet haben).

Einige BGP-Router besitzen die Möglichkeit, eine separate Kopie aller Routen, die ein Nachbar gesendet hat, in einer parallelen BGP-Tabelle zu speichern. (Um diese Funktionalität unter Cisco IOS zu aktivieren, müssen Sie die Soft-Reconfiguration Inbound für einen BGP-Nachbarn konfigurieren.)

Mit der Paralleltabelle auf Nachbarbasis können Sie exakt feststellen, was der Nachbar Ihnen gesendet hat (den Inhalt der Paralleltabelle), sowie die Routen erkennen, die Ihre Eingangsfilter passiert haben (den Inhalt der BGP-Haupttabelle). Doch die Pro-Nachbar-Paralleltabelle benötigt natürlich sehr viel Speicher.

Wird das Präfix über unser Netzwerk propagiert?

Selbst wenn ein Edge Router per BGP ein IP-Präfix empfängt, wird es möglicherweise nicht bis zum anderen Ende Ihres Netzwerks propagiert. Zunächst einmal erfordert internes BGP (BGP innerhalb eines einzelnen autonomen Systems) eine vollständige Vermaschung von BGP-Sitzungen zwischen allen BGP-Routern.

Da jeder Router zwischen jedem Edge-Router-Paar BGP ausführen muss (ansonsten kann der Traffic innerhalb Ihres Netzwerks verworfen werden), könnte die Anzahl der BGP-Sitzungen übermäßig groß werden. (Abbildung 2 verdeutlicht die BGP-Sitzungen, die in einem kleinen Netzwerk mit vier Routern benötigt werden.)

Abbildung 2: Ein vermaschtes Netzwerk mit vier Routern.

Es gibt zwei Tools (BGP Route Reflectors und BGP Confederations), die Ihnen helfen können, die Zahl der BGP-Sitzungen auf einem vernünftigen Niveau zu halten. Dabei sind BGP Route Reflectors das gängigste Werkzeug.

Die Regeln für BGP Route Reflectors sind recht einfach:

• Alles, was von einem Route Reflector Client oder einem externen BGP-Peer empfangen wird, wird an jeden anderen BGP-Peer gesendet.
• Alles, was von einem Router empfangen wird, der kein Route Reflector Client ist, wird nur an Clients und externe BGP-Peers gesendet.

Anhand dieser Regeln müssen Sie Schritt für Schritt die BGP-Sitzungen in Ihrem Netzwerk durchgehen, dabei jeden BGP-Router auf dem Weg überprüfen und sicherstellen, dass die Route-Reflector-Regeln nicht verletzt werden (und, unter Anwendung dieser Regeln, dass die BGP-Präfixe von jedem Edge Router zu allen anderen Routern gelangen).

Es gibt einen anderen häufigen Grund, weshalb ein IP-Präfix nicht in Ihrem Netzwerk propagiert wird: die externen Subnetze an Ihrem Netzwerk-Edge werden Ihren Core Routern nicht bekannt gegeben.

Die IP-Adresse des Routers am nächsten Hop ändert sich nicht, wenn ein IP-Präfix an einen internen BGP-Nachbarn gesendet wird. Die IP am nächsten Hop einer externen Route entspricht somit immer der IP-Adresse eines Routers einen Hop außerhalb des Edge Ihres autonomen Systems. Die IP-Subnetze, die Ihre Edge Router mit ihren externen Nachbarn verbinden, müssen daher Ihrem internen Routing-Protokoll (zum Beispiel OSPF oder IS-IS) hinzugefügt werden. Ansonsten geht irgendein interner BGP-Router davon aus, dass BGP am nächsten Hop nicht erreichbar ist, und ignoriert das IP-Präfix. (Es wird zwar in der BGP-Tabelle erscheinen, aber nicht verwendet oder zu anderen BGP-Peers propagiert.)

Wird das Präfix an externe Nachbarn gesendet?

Im letzten Schritt beim Troubleshooting der BGP-Routenpropagierung müssen Sie kontrollieren, ob die IP-Präfixe, die über Ihr Netzwerk transportiert werden, den externen BGP-Peers bekannt gemacht werden. Die Techniken für das Troubleshooting der ausgehenden BGP-Routenpropagierung werden im ersten Artikel erläutert.

Durchquert der Traffic das Netzwerk?

Selbst wenn Ihre BGP-Routenpropagierung reibungslos funktioniert, kann es vorkommen, dass die IP-Pakete Ihr Netzwerk nicht durchqueren können. (Denken Sie daran, dass wir hier über reine IP-Netzwerke sprechen. Die Umstände ändern sich ein wenig, wenn auch MPLS beteiligt ist.) Häufigster Grund für ein sogenanntes Black Hole in Ihrem Netzwerk ist ein Router im Transitpfad, auf dem kein BGP läuft und der infolgedessen nicht weiß, wie er das empfangene IP-Paket in Richtung des Zielnetzwerks weiterleiten soll.

Das IP-Routing funktioniert auf Hop-Basis. Auch wenn der Ingress Edge Router genau weiß, welchen Egress Edge Router er nutzen soll und wie er ihn erreicht, kann er diese Informationen nicht an die Intermediate Router weitergeben. Daher müssen alle diese Geräte ebenfalls BGP ausführen.

Um ein Black Hole in Ihrem Netzwerk zu identifizieren, führen Sie vom Netzwerk Ihres Kunden aus einen Traceroute zu einem Ziel im Internet durch. Der letzte Router, der auf den Traceroute antwortet, befindet sich einen Hop weit vor dem Black Hole.

Obwohl alle Core Router in Ihrem Netzwerk BGP ausführen müssen, müssen die internen BGP-Sitzungen nicht der physischen Struktur des Netzwerks folgen. Sie können zum Beispiel einige zentrale Router einsetzen, die als BGP Route Reflectors für alle BGP-Router in Ihrem Netzwerk fungieren.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!