Einige L2VPN-Routen verschwinden nach dem Hinzufügen von Route-Reflektoren

Sitzungen bleiben bestehen, das IGP ist stabil, und dennoch erscheinen einige L2VPN-Routen nie an zwei der vier Provider-Kanten. Dieses Muster gehört zu einem Reflexionsproblem und nicht zu einem Transportproblem, denn eine gebrochene Sitzung fällt vollständig aus, während eine wiederverwendete Reflexionsgrenze selektiv ausfällt. Der physische Ring hat damit nichts zu tun; der logische Verteilungsgraph ist der Ort, an dem diese Routen stehen geblieben sind. Diese Stelle zu finden erfordert keinen Neuaufbau der Steuerungsebene.

Der Verlust ist selektiv, was die Suche eingrenzt

Vier Provider-Kanten an einem physischen Ring benötigen sechs logische Sitzungen für ein vollständiges Mesh, da jeder Router mit den anderen drei gepaart wird. Diese Sitzungen laufen über den gerouteten Transport, sodass die Verkabelung nichts darüber aussagt, wie viele Nachbarschaften existieren oder welche von ihnen reflektiert. Wenn zwei Kanten einen bestimmten Präfixsatz verfehlen, während alles andere konvergiert, ist das Kabel nicht der Verdächtige.

Selektiver Verlust deutet auf Schleifenvermeidung, Policy oder Beziehungsrichtung hin, wo einige Routen eine Grenze überqueren und andere unterwegs verworfen werden. Totaler Verlust deutet auf die Sitzung oder die Adressfamilie hin. Zu entscheiden, welches der beiden man vor sich hat, ist der erste nützliche Schritt, und er kostet einen Befehl.

Was Reflexion tatsächlich ändert

Route-Reflection lockert die Regel, dass ein iBGP-Sprecher eine von einem anderen iBGP-Sprecher gelernte Route nicht erneut ankündigen darf. RFC 4456 drückt die Ausnahme über die Beziehung zwischen dem Sprecher und der Quelle der Route aus, und die Richtung dieser Beziehung ist wichtiger, als die meisten Zusammenfassungen nahelegen. Eine von einem Client gelernte Route darf an andere Clients und an Nicht-Clients reflektiert werden, während eine von einem Nicht-Client gelernte Route nur an Clients reflektiert werden darf. Lesen Sie die Asymmetrie zweimal, denn sie erklärt, wie das Hinzufügen einer Client-Beziehung einen Designfehler verbergen kann: Sie öffnet einen Pfad, den die Topologie nie vorgesehen hatte.

Das Attribut CLUSTER_LIST zeichnet die Reflexionshistorie auf, und ein Reflektor, der seine eigene Cluster-ID in dieser Liste findet, muss die Ankündigung ignorieren. Das ist Schleifenvermeidung, und es ist zugleich der Mechanismus, der Routen löscht, wenn Kennungen versehentlich wiederverwendet werden. ORIGINATOR_ID spielt eine verwandte Rolle, indem es den Router benennt, der die Route zuerst angekündigt hat.

Wiederverwendete Cluster-IDs sind der Weg, auf dem Routen verschwinden

Ein kleines Netzwerk lädt zu einer Abkürzung ein: Geben Sie jedem Router eine Cluster-ID gleich seinem Loopback, fügen Sie später einen weiteren Reflektor hinzu und verwenden Sie ein vorhandenes Loopback erneut, weil es bequem zur Hand ist. Erscheint diese Kennung nun an zwei unabhängigen Reflexionsstufen, sieht die zweite Stufe ihre eigene ID in CLUSTER_LIST und verwirft die Route. Nichts protokolliert einen Fehler, denn Verwerfen ist die richtige Antwort auf eine Schleife.

Redundante Reflektoren, die einen Cluster bedienen, sind die legitime Ausnahme: Sie teilen sich bewusst eine ID, damit jeder von ihnen dieselben Clients bedienen kann. Die Kennung muss zum Reflexionsdesign passen und nicht Gehäusenamen unterscheiden.

Zeichnen Sie den beabsichtigten Graphen, bevor Sie irgendeine Konfiguration anfassen: Wer erzeugt das Präfix, welche Client-Beziehung erlaubt die erste Reflexion, welcher Reflektor trägt es zur nächsten Stufe, und wo sitzt der letzte Client. Jeder Hop in diesem Graphen ist eine Stelle, an der eine wiederverwendete Kennung, eine fehlende Client-Beziehung oder ein Policy-Filter die Route stoppen kann. Mit gezeichnetem Graphen hat eine fehlende Route einen Ort statt eines Rätsels.

Widerstehen Sie dem Impuls, jeden Nachbarn zum Client zu machen

Die schnelle Reparatur für eine fehlende Route besteht darin, jeden Nachbarn zum Client jedes Reflektors zu machen. Die Verbreitung kehrt zurück, und das Design sagt Ihnen nichts mehr: Es vervielfacht die Routen, die jeder Sprecher trägt, und verbirgt zugleich, welche Beziehung die Arbeit hätte leisten sollen.

Ein kleines Netzwerk braucht normalerweise eine von zwei Formen. Ein vollständiges iBGP-Mesh sind sechs Sitzungen für vier Router ganz ohne Reflexion, und ein festgelegtes Reflektorpaar, das die übrigen Kanten bedient, ist die andere. Beide sind leichter zu durchdenken als ein Teil-Mesh, in dem jeder Router ein wenig reflektiert. Wählen Sie die Form nach Größe und Fehlerverhalten, nicht nach dem Verkabelungsdiagramm.

Prüfen Sie die Adressfamilie, bevor Sie die Reflexion beschuldigen

Eine TCP-Sitzung auf Port 179 beweist, dass die beiden Sprecher miteinander reden können, und nichts darüber, ob die VPN-Adressfamilie eine einzige Route ausgetauscht hat. Stellen Sie den Sitzungszustand fest, dann die Familie, dann das einzelne Präfix.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Diese drei Ausgaben trennen ein Nachbarschaftsproblem von einem Austauschproblem und von einem fehlenden Präfix. Wenn die Familie überhaupt keine Präfixe zeigt, prüfen Sie den Aktivierungszustand und die Export-Policy des Nachbarn, bevor Sie die Reflexion ansehen. Wenn Präfixe an einer Kante erscheinen, an einer anderen aber nicht, vergleichen Sie die Cluster-Liste und den Originator auf der Empfangsseite und gehen Sie dann den Graphen aus dem vorigen Abschnitt durch.

Halten Sie die Erreichbarkeit des nächsten Hops und den Weiterleitungszustand außerhalb dieser Prüfung. Eine reflektierte Route mit einem nicht erreichbaren nächsten Hop ist vorhanden und unbrauchbar, was wie ein Reflexionsfehler aussieht, bis man die Spalte für den nächsten Hop ansieht. Lösen Sie den nächsten Hop auf, bestätigen Sie den Weiterleitungseintrag, und erst dann entscheiden Sie, ob der Verteilungsgraph einen weiteren Reflektor braucht.