AFI en SAFI: lees het paar vóór de dienstnaam

U kunt een sessie zien opkomen, een route zien verschijnen en toch de verkeerde dienst lezen. Het getallenpaar vooraan elke aankondiging, de adresfamilie-identificatie en de volgende adresfamilie-identificatie, bepaalt welke parser de payload leest en welke tabel het resultaat houdt. Vergist u zich in het paar, dan lopen het importbeleid, de routetarget-overeenkomst en het zoeken naar de volgende hop allemaal tegen een structuur die niemand heeft aangekondigd. De wandeling hieronder begint bij dat paar en eindigt bij het doorstuurresultaat.

Twee getallen bepalen in welke tabel de route hoort

Het paar verschijnt twee keer: binnen de multiprotocol-capaciteit, waar een spreker een familie aankondigt, en vóór elke NLRI die die familie draagt. Dat maakt het een eigenschap van de route in plaats van een instelling op de oorspronkelijke doos. Leveranciers drukken het af als een naam zoals Address family VPNv4 Unicast, en de formulering verschuift tussen releases terwijl de getallen blijven staan.

Vier coderingen dekken bijna elk bedrijfsgeval: 1 met 128 voor MPLS-gelabelde VPN-IPv4, 2 met 128 voor het IPv6-equivalent, 25 met 65 voor door BGP gesignaleerde VPLS en 25 met 70 voor EVPN. De eerste fout is aannemen dat elke Layer 2-dienst achter 25 met 65 zit, wat EVPN verbergt. De tweede is de twee IP-families behandelen als één familie met een langer adres, terwijl ze apart worden onderhandeld en op verschillende peers kunnen worden geaccepteerd. Een derde verschijnt wanneer een sjabloon wordt gekopieerd uit een release die er maar één kent. Een blik in het register beslecht alle drie sneller dan een gok die op de dienstnaam is gebouwd.

Behandel de vier rijen als voorbeelden uit het IANA-register, niet als het register zelf. Als een getal nergens bekends mee overeenkomt, zoek het dan op voordat u er beleid omheen bouwt.

AFI 25 draagt twee onverwante NLRI-formaten

Beide Layer 2-families zitten onder AFI 25, en de gelijkenis stopt daar. De VPLS-NLRI in RFC 4761 section 3.2.2 draagt een lengte, een route-differentiator, een VE ID, een VE-blokverschuiving, een VE-blokgrootte en een labelbasis, die samen een pseudowire-eindpunt en zijn label benoemen. EVPN houdt AFI 25 en gaat naar SAFI 70, waar de payload een routetype is: automatische Ethernet-ontdekking, MAC/IP-aankondiging, inclusieve multicast, Ethernet-segment, IP-prefix. Dezelfde byteverschuiving betekent dus verschillende dingen in de twee families. Een parser die voor de ene is geschreven leest de andere zonder klagen en produceert onzin. Het paar is de enige waarschuwing dat de interpretatie fout is.

Een veld dat in de ene familie VE-blokverschuiving betekent, heeft in de andere geen tegenhanger, en de MAC/IP-aankondigingsroute bestaat alleen in EVPN. Een attribuut citeren alsof het voor beide geldt, is hoe een capture-review misloopt.

Wanneer iemand u een capture of een leverancierstabel geeft, vraag dan bij welke familie het attribuut hoort. Bevestig daarna dat de ontvangende implementatie die familie ondersteunt, niet de dienstnaam op het datablad. Twee platforms kunnen beide VPLS-ondersteuning claimen terwijl ze verschillende signaleringsfamilies implementeren. Het paar scheidt ze; het productlabel niet.

De eigen adresfamilie van de sessie is een aparte vraag

VPN-IPv6 wordt routineus aangekondigd over een sessie waarvan de TCP-verbinding over IPv4 loopt, en dat is ondersteund ontwerp, geen storing. Alleen de sessiesamenvatting lezen zegt dus niets over welke VPN-families de peers uitwisselen.

NLRI-familie, transportfamilie en doorstuurfamilie zijn drie onafhankelijke beslissingen. Een router kan IPv4 spreken met zijn peer, bereikbaarheid van VPN-IPv6 accepteren en een route installeren waarvan de volgende hop een IPv6-adres is dat bereikbaar is via een pad dat u niet bedoelde. Elke laag heeft zijn eigen bevestiging nodig. Locaties die onbereikbare IPv6-bestemmingen melden terwijl de aankondigingen correct lijken, hebben meestal de resolutie van de volgende hop verloren, niet de familieonderhandeling.

Test de adresfamilie van de sessie apart, dan de families die zij draagt, dan wat de kern kan doorsturen. De drie gescheiden houden voorkomt de gangbare verkeerde diagnose waarbij een correcte aankondiging wordt gelezen als bewijs dat IPv6 van begin tot eind werkt. Het bewijst alleen dat de ene peer de andere iets over een prefix heeft verteld.

Onderhandeld, ontvangen, geïmporteerd, geïnstalleerd

Voor één verwachte route moeten vier toestanden in volgorde gelden, en elk is waarneembaar. De familie moet met die peer zijn onderhandeld, de route moet aankomen, een routetarget moet hem in de bedoelde context importeren en de volgende hop moet resolven zodat de route installeert. De eerste toestand overslaan maakt de andere drie onbeantwoordbaar, omdat een niet-onderhandelde familie geen routes oplevert om te inspecteren. Op platforms in Cisco-stijl zijn de familiesamenvattingen en de capaciteiten per peer aparte commando's.

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

De onderhandeling verschijnt in de capaciteitsuitwisseling die per peer wordt afgedrukt, en een gevestigde sessie zonder enige vermelde familie draagt niets van wat u vroeg. De import wordt bepaald door routetargets die als uitgebreide communities worden gedragen, dus een correct paar met een verkeerd getypt target laat de tabel leeg. De installatie hangt daarna af van het resolven van de volgende hop in de ontvangende context, wat kan mislukken terwijl elke aankondiging perfect lijkt.

Bevestig het dataplane als laatste, want een route in de tabel is een bewering, geen aflevering. Dezelfde vier toestanden gelden voor elke familie; alleen de commando's en tabelnamen veranderen.

Wat een familiepaar nooit bewijst

Het paar correct lezen vertelt u hoe u de routeringsinformatie die volgt moet interpreteren, en dat is de hele bewering. Het zegt niets over bereikbaarheid, niets over beleid en niets over de gezondheid van het dataplane. De twee verwarren levert zelfverzekerde uitspraken op over een netwerk dat niemand heeft geverifieerd. Een routetarget-misverhouding en een gebroken volgende hop zien er alleen op basis van het paar identiek uit. Het paar is een leesinstructie, nooit een vonnis.

Wanneer u escaleert, zet het paar, het routetarget en de geresolveerde volgende hop in dezelfde notitie. De volgende engineer heeft dan drie onafhankelijke dingen om te testen in plaats van een dienstnaam om te herinterpreteren. Ontbreekt de onderhandeling, dan zien ze dat meteen, een verkeerd target laat de import zichtbaar ontbreken, en een onopgeloste volgende hop laat de route aanwezig maar onbruikbaar.