AFI und SAFI: das Paar vor dem Dienstnamen lesen

Sie können sehen, wie eine Sitzung hochkommt, eine Route erscheinen sehen und trotzdem den falschen Dienst lesen. Das Zahlenpaar am Anfang jeder Ankündigung, der Adressfamilien-Identifikator und der nachfolgende Adressfamilien-Identifikator, entscheidet, welcher Parser die Nutzlast liest und welche Tabelle das Ergebnis hält. Liegt das Paar falsch, laufen Importrichtlinie, Routetarget-Abgleich und Next-Hop-Suche alle gegen eine Struktur, die niemand angekündigt hat. Der Gang unten beginnt bei diesem Paar und endet beim Weiterleitungsergebnis.

Zwei Zahlen entscheiden, in welche Tabelle die Route gehört

Das Paar erscheint zweimal: innerhalb der Multiprotocol-Fähigkeit, wo ein Sprecher eine Familie ankündigt, und vor jeder NLRI, die diese Familie trägt. Damit ist es eine Eigenschaft der Route und keine Einstellung auf der Ursprungsbox. Hersteller drucken es als Namen wie Address family VPNv4 Unicast, und die Formulierung wandert zwischen Releases, während die Zahlen stehen bleiben.

Vier Kodierungen decken fast jeden Unternehmensfall ab: 1 mit 128 für MPLS-gelabelte VPN-IPv4, 2 mit 128 für das IPv6-Äquivalent, 25 mit 65 für BGP-signalisiertes VPLS und 25 mit 70 für EVPN. Der erste Fehler ist anzunehmen, jeder Layer 2-Dienst liege hinter 25 mit 65, was EVPN verdeckt. Der zweite ist, die beiden IP-Familien als eine Familie mit längerer Adresse zu behandeln, obwohl sie getrennt ausgehandelt werden und auf verschiedenen Peers akzeptiert werden können. Ein dritter entsteht, wenn eine Vorlage aus einem Release kopiert wird, das nur eine davon kennt. Ein Blick ins Register klärt alle drei schneller als eine Vermutung, die auf dem Dienstnamen aufbaut.

Behandeln Sie die vier Zeilen als Beispiele aus dem IANA-Register, nicht als das Register selbst. Wenn eine Zahl zu nichts Bekanntem passt, schlagen Sie sie nach, bevor Sie eine Richtlinie darum bauen.

AFI 25 trägt zwei unverwandte NLRI-Formate

Beide Layer 2-Familien liegen unter AFI 25, und die Ähnlichkeit endet dort. Die VPLS-NLRI in RFC 4761 section 3.2.2 trägt eine Länge, einen Route Distinguisher, eine VE ID, einen VE-Block-Offset, eine VE-Block-Größe und eine Labelbasis, die zusammen einen Pseudowire-Endpunkt und sein Label benennen. EVPN behält AFI 25 und wechselt zu SAFI 70, wo die Nutzlast ein Routentyp ist: Ethernet-Autoerkennung, MAC/IP-Ankündigung, inklusives Multicast, Ethernet-Segment, IP-Präfix. Derselbe Byte-Offset bedeutet daher in den beiden Familien Verschiedenes. Ein für die eine geschriebener Parser liest die andere ohne Beschwerde und erzeugt Unsinn. Das Paar ist die einzige Warnung, dass die Auslegung falsch ist.

Ein Feld, das in einer Familie VE-Block-Offset bedeutet, hat in der anderen kein Gegenstück, und die MAC/IP-Ankündigungsroute gibt es nur in EVPN. Ein Attribut zu zitieren, als gelte es für beide, ist der Weg, auf dem eine Capture-Prüfung schiefgeht.

Wenn jemand Ihnen einen Mitschnitt oder eine Herstellertabelle gibt, fragen Sie, zu welcher Familie das Attribut gehört. Bestätigen Sie dann, dass die empfangende Implementierung diese Familie unterstützt, nicht den Dienstnamen im Datenblatt. Zwei Plattformen können beide VPLS-Unterstützung behaupten und dabei verschiedene Signalisierungsfamilien umsetzen. Das Paar trennt sie; das Produktetikett nicht.

Die eigene Adressfamilie der Sitzung ist eine separate Frage

VPN-IPv6 wird routinemäßig über eine Sitzung angekündigt, deren TCP-Verbindung über IPv4 läuft, und das ist unterstütztes Design, kein Fehler. Nur die Sitzungszusammenfassung zu lesen sagt daher nichts darüber, welche VPN-Familien die Peers austauschen.

NLRI-Familie, Transportfamilie und Weiterleitungsfamilie sind drei unabhängige Entscheidungen. Ein Router kann IPv4 mit seinem Peer sprechen, VPN-IPv6-Erreichbarkeit annehmen und eine Route installieren, deren nächster Hop eine IPv6-Adresse ist, die über einen Pfad erreichbar ist, den Sie nicht beabsichtigt haben. Jede Schicht braucht ihre eigene Bestätigung. Standorte, die unerreichbare IPv6-Ziele melden, während die Ankündigungen korrekt aussehen, haben meist die Next-Hop-Auflösung verloren, nicht die Familienaushandlung.

Prüfen Sie die Adressfamilie der Sitzung für sich, dann die Familien, die sie trägt, dann was der Kern weiterleiten kann. Die drei getrennt zu halten verhindert die verbreitete Fehldiagnose, bei der eine korrekte Ankündigung als Beweis gelesen wird, dass IPv6 durchgängig funktioniert. Sie beweist nur, dass ein Peer einem anderen von einem Präfix erzählt hat.

Aushandelt, empfangen, importiert, installiert

Für eine erwartete Route müssen vier Zustände der Reihe nach gelten, und jeder ist beobachtbar. Die Familie muss mit diesem Peer ausgehandelt sein, die Route muss ankommen, ein Routetarget muss sie in den vorgesehenen Kontext importieren, und der nächste Hop muss sich auflösen, damit die Route installiert wird. Den ersten Zustand zu überspringen macht die anderen drei unbeantwortbar, weil eine nicht ausgehandelte Familie keine Routen zur Prüfung erzeugt. Auf Plattformen im Cisco-Stil sind die Familienzusammenfassungen und die Fähigkeiten je Peer getrennte Befehle.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

Die Aushandlung erscheint im Fähigkeitsaustausch, der je Peer ausgegeben wird, und eine etablierte Sitzung ohne aufgeführte Familie trägt nichts von dem, was Sie angefragt haben. Der Import wird von Routetargets entschieden, die als erweiterte Communities getragen werden, sodass ein korrektes Paar mit falsch getipptem Target die Tabelle leer lässt. Die Installation hängt dann davon ab, dass der nächste Hop im empfangenden Kontext aufgelöst wird, was fehlschlagen kann, während jede Ankündigung perfekt aussieht.

Bestätigen Sie die Datenebene zuletzt, denn eine Route in der Tabelle ist eine Behauptung, keine Zustellung. Dieselben vier Zustände gelten für jede Familie; nur die Befehle und Tabellennamen ändern sich.

Was ein Familienpaar nie beweist

Das Paar richtig zu lesen sagt Ihnen, wie die folgende Routinginformation zu deuten ist, und das ist die ganze Behauptung. Es sagt nichts über Erreichbarkeit, nichts über Richtlinie und nichts über die Gesundheit der Datenebene. Beides zu verwechseln erzeugt sichere Aussagen über ein Netz, das niemand geprüft hat. Ein Routetarget-Fehler und ein kaputter nächster Hop sehen allein vom Paar her identisch aus. Das Paar ist eine Leseanweisung, nie ein Urteil.

Wenn Sie eskalieren, bringen Sie das Paar, das Routetarget und den aufgelösten nächsten Hop in derselben Notiz unter. Der nächste Ingenieur hat dann drei unabhängige Dinge zu prüfen statt einen Dienstnamen neu zu deuten. Fehlt die Aushandlung, sehen sie es sofort, ein falsches Target lässt den Import sichtbar ausbleiben, und ein unaufgelöster nächster Hop lässt die Route vorhanden, aber unbrauchbar.