AFI och SAFI: läs paret före tjänstenamnet

Du kan se en session komma upp, se en rutt dyka upp och ändå läsa fel tjänst. Talparet först i varje annonsering, adressfamiljens identifierare och nästa adressfamiljs identifierare, avgör vilken parser som läser nyttolasten och vilken tabell som håller resultatet. Tar du fel på paret kör importpolicyn, ruttmålsträffen och nästa hopps-uppslaget alla mot en struktur som ingen annonserat. Genomgången nedan börjar vid det paret och slutar vid vidarebefordringsresultatet.

Två tal avgör vilken tabell rutten hör hemma i

Paret förekommer två gånger: inne i multiprotokoll-kapabiliteten, där en talare annonserar en familj, och framför varje NLRI som familjen bär. Det gör det till en egenskap hos rutten snarare än en inställning på ursprungsboxen. Leverantörer trycker det som ett namn som Address family VPNv4 Unicast, och formuleringen flyttar sig mellan utgåvor medan talen står kvar.

Fyra kodningar täcker nästan alla företagsfall: 1 med 128 för MPLS-märkt VPN-IPv4, 2 med 128 för IPv6-motsvarigheten, 25 med 65 för BGP-signaliserad VPLS och 25 med 70 för EVPN. Första felet är att anta att varje Layer 2-tjänst ligger bakom 25 med 65, vilket döljer EVPN. Det andra är att behandla de två IP-familjerna som en familj med längre adress, när de förhandlas separat och kan accepteras på olika peers. Ett tredje uppstår när en mall kopieras från en utgåva som bara känner till en av dem. Ett uppslag i registret avgör alla tre snabbare än en gissning byggd på tjänstenamnet.

Behandla de fyra raderna som exempel från IANA-registret, inte som registret självt. När ett tal inte stämmer med något känt, slå upp det innan du bygger en policy runt det.

AFI 25 bär två orelaterade NLRI-format

Båda Layer 2-familjerna sitter under AFI 25, och likheten slutar där. VPLS-NLRI i RFC 4761 section 3.2.2 bär en längd, en ruttdistinguisher, ett VE ID, en VE-blokksförskjutning, en VE-blokksstorlek och en etikettbas, som tillsammans namnger en pseudowire-ändpunkt och dess etikett. EVPN behåller AFI 25 och flyttar till SAFI 70, där nyttolasten är en rutttyp: automatisk Ethernet-upptäckt, MAC/IP-annonsering, inkluderande multicast, Ethernet-segment, IP-prefix. Därför betyder samma byteförskjutning olika saker i de två familjerna. En parser skriven för den ena läser den andra utan klagomål och producerar nonsens. Paret är den enda varningen om att tolkningen är fel.

Ett fält som betyder VE-blokksförskjutning i den ena familjen har ingen motsvarighet i den andra, och MAC/IP-annonseringsrutten finns bara i EVPN. Att citera ett attribut som om det gällde båda är hur en genomgång av en inspelning går fel.

När någon ger dig en inspelning eller en leverantörstabell, fråga vilken familj attributet tillhör. Bekräfta sedan att mottagarimplementationen stöder den familjen, inte tjänstenamnet på databladet. Två plattformar kan båda hävda VPLS-stöd medan de implementerar olika signaleringsfamiljer. Paret skiljer dem; produktetiketten gör det inte.

Sessionens egen adressfamilj är en separat fråga

VPN-IPv6 annonseras rutinmässigt över en session vars TCP-anslutning går över IPv4, och det är stödd design, inte fel. Att bara läsa sessionssammanfattningen säger därför ingenting om vilka VPN-familjer peerarna utbyter.

NLRI-familj, transportfamilj och vidarebefordringsfamilj är tre oberoende beslut. En router kan tala IPv4 med sin peer, acceptera nåbarhet för VPN-IPv6 och installera en rutt vars nästa hopp är en IPv6-adress som nås via en väg du inte avsåg. Varje lager behöver sin egen bekräftelse. Platser som rapporterar onåbara IPv6-mål medan annonseringarna ser korrekta ut har oftast tappat uppslaget av nästa hopp, inte familjeförhandlingen.

Testa sessionens adressfamilj för sig, sedan familjerna den bär, sedan vad kärnan kan vidarebefordra. Att hålla de tre åtskilda förhindrar den vanliga felaktiga diagnosen där en korrekt annonsering läses som bevis på att IPv6 fungerar från ände till ände. Det bevisar bara att en peer berättade för en annan om ett prefix.

Förhandlat, mottaget, importerat, installerat

För en förväntad rutt måste fyra tillstånd gälla i ordning, och varje är observerbart. Familjen måste vara förhandlad med den peeren, rutten måste anlända, ett ruttmål måste importera den till den avsedda kontexten och nästa hopp måste lösas så att rutten installeras. Att hoppa över det första tillståndet gör de andra tre obesvarliga, eftersom en oförhandlad familj inte producerar några rutter att inspektera. På Cisco-liknande plattformar är familjesammanfattningarna och kapabiliteterna per peer separata kommandon.

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

Förhandlingen syns i kapabilitetsutbytet som skrivs ut per peer, och en etablerad session utan någon listad familj bär ingenting av det du bad om. Importen avgörs av ruttmål som bärs som utökade communities, så ett korrekt par med ett felstavat mål lämnar tabellen tom. Installationen beror sedan på att nästa hopp löses i mottagarkontexten, vilket kan misslyckas medan varje annonsering ser perfekt ut.

Bekräfta dataplanet sist, eftersom en rutt i tabellen är ett påstående, inte en leverans. Samma fyra tillstånd gäller för varje familj; bara kommandona och tabellnamnen ändras.

Vad ett familjepar aldrig bevisar

Att läsa paret rätt säger hur du ska tolka den routinginformation som följer, och det är hela påståendet. Det säger ingenting om nåbarhet, ingenting om policy och ingenting om dataplanets hälsa. Att blanda de två ger självsäkra uttalanden om ett nätverk som ingen verifierat. En ruttmålsavvikelse och ett trasigt nästa hopp ser identiska ut bara utifrån paret. Paret är en läsinstruktion, aldrig en dom.

När du eskalerar, sätt paret, ruttmålet och det lösta nästa hoppet i samma anteckning. Nästa ingenjör har då tre oberoende saker att testa i stället för ett tjänstenamn att nytolka. Saknas förhandlingen ser de det direkt, ett felaktigt mål lämnar importen synligt frånvarande, och ett olöst nästa hopp lämnar rutten närvarande men oanvändbar.