AFI og SAFI: les paret før du leser tjenestenavnet

Du kan se en sesjon komme opp, se en rute dukke opp og fortsatt lese feil tjeneste. Tallparet som står først i hver annonsering, adressefamilieidentifikatoren og den etterfølgende adressefamilieidentifikatoren, bestemmer hvilken parser som leser nyttelasten og hvilken tabell som holder resultatet. Tar du feil av paret, vil importpolitikken, treffet på rutemålet og oppslaget av neste hopp alle kjøre mot en struktur ingen har annonsert. Gjennomgangen nedenfor begynner ved det paret og ender ved resultatet av videresendingen.

To tall bestemmer hvilken tabell ruten hører hjemme i

Paret dukker opp to steder: inne i multiprotokoll-kapabiliteten, der en taler annonserer en familie, og foran hver NLRI som familien bærer. Dermed er det en egenskap ved ruten og ikke en innstilling på opphavsboksen. Leverandører skriver det ut som et navn som Address family VPNv4 Unicast, og ordlyden endrer seg mellom versjoner mens tallene står fast.

Fire kodinger dekker nesten alle bedriftscaser: 1 sammen med 128 for MPLS-merket VPN-IPv4, 2 sammen med 128 for IPv6-motstykket, 25 sammen med 65 for BGP-signalisert VPLS og 25 sammen med 70 for EVPN. Den første feilen er å tro at hver Layer 2-tjeneste ligger bak 25 sammen med 65, noe som skjuler EVPN. Den andre er å se de to IP-familiene som én familie med en lengre adresse, når de forhandles hver for seg og kan godtas på forskjellige peers. En tredje dukker opp når en mal kopieres fra en versjon som bare kjenner én av dem. Et oppslag i registeret avgjør alle tre raskere enn en gjetning som bygger på tjenestenavnet.

Se på de fire radene som eksempler fra IANA-registeret, ikke som registeret selv. Når et tall ikke stemmer med noe du kjenner, slå det opp før du bygger en policy rundt det.

AFI 25 bærer to urelaterte NLRI-formater

Begge Layer 2-familiene ligger under AFI 25, og likheten slutter der. VPLS-NLRI i RFC 4761 section 3.2.2 bærer en lengde, en rutedistinguisher, en VE ID, en forskyvning av VE-blokk, en størrelse på VE-blokk og en etikettbase, som til sammen navngir et pseudowire-endepunkt og etiketten. EVPN beholder AFI 25 og går til SAFI 70, der nyttelasten er en rutetype: automatisk Ethernet-oppdagelse, MAC/IP-annonsering, inkluderende multicast, Ethernet-segment, IP-prefiks. Derfor betyr samme byteforskyvning ulike ting i de to familiene. En parser skrevet for den ene leser den andre uten å klage og gir vrøvl. Paret er den eneste advarselen om at tolkningen er gal.

Et felt som betyr forskyvning av VE-blokk i den ene familien, har ingen motsvarighet i den andre, og MAC/IP-annonseringsruten finnes bare i EVPN. Å sitere et attributt som om det gjaldt begge, er måten en gjennomgang av et opptak går galt.

Når noen gir deg et opptak eller en leverandørtabell, spør hvilken familie attributtet tilhører. Bekreft så at mottakerimplementasjonen støtter den familien, ikke tjenestenavnet på databladet. To plattformer kan begge hevde VPLS-støtte mens de implementerer forskjellige signaleringsfamilier. Paret skiller dem; produktetiketten gjør det ikke.

Sesjonens egen adressefamilie er et separat spørsmål

VPN-IPv6 annonseres rutinemessig over en sesjon der TCP-forbindelsen går over IPv4, og det er støttet design, ikke feil. Bare å lese sesjonssammendraget sier derfor ingenting om hvilke VPN-familier peerne utveksler.

NLRI-familie, transportfamilie og videresendingsfamilie er tre uavhengige beslutninger. En ruter kan snakke IPv4 med peeren, godta at VPN-IPv6 er tilgjengelig og installere en rute der neste hopp er en IPv6-adresse som nås via en sti du ikke hadde tenkt deg. Hvert lag trenger sin egen bekreftelse. Steder som rapporterer at IPv6-mål ikke nås mens annonseringene ser riktige ut, har som regel mistet oppslaget av neste hopp, ikke familiforhandlingen.

Test adressefamilien til sesjonen for seg, så familiene den bærer, så det kjernen kan videresende. Å holde de tre atskilt hindrer den vanlige feildiagnosen der en korrekt annonsering leses som bevis på at IPv6 virker ende til ende. Det beviser bare at den ene peeren fortalte den andre om et prefiks.

Forhandlet, mottatt, importert, installert

For én forventet rute må fire tilstander holde i rekkefølge, og hver er observerbar. Familien må være forhandlet med den peeren, ruten må komme inn, et rutemål må importere den til den tiltenkte konteksten, og neste hopp må løses opp slik at ruten installeres. Hopper du over den første tilstanden, blir de tre andre ubesvarlige, fordi en uforhandlet familie ikke gir ruter å undersøke. På Cisco-lignende plattformer er familiesammendragene og kapabilitetene per peer egne kommandoer.

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

Forhandlingen vises i kapabilitetsutvekslingen som skrives ut per peer, og en etablert sesjon uten noen oppført familie bærer ingenting av det du ba om. Importen avgjøres av rutemål som bæres som utvidede communities, så et korrekt par med et feilskrevet mål lar tabellen stå tom. Installasjonen avhenger så av at neste hopp løses opp i mottakerkonteksten, noe som kan feile mens hver annonsering ser perfekt ut.

Bekreft dataplanet til slutt, fordi en rute i tabellen er en påstand, ikke en leveranse. De samme fire tilstandene gjelder for hver familie; bare kommandoene og tabellnavnene endres.

Hva et familiepar aldri beviser

Å lese paret riktig forteller deg hvordan du skal tolke rutingsinformasjonen som følger, og det er hele påstanden. Det sier ingenting om rekkevidde, ingenting om policy og ingenting om dataplanets helse. Å blande de to gir skråsikre utsagn om et nettverk ingen har verifisert. Et avvik på rutemålet og et brutt neste hopp ser like ut bare ut fra paret. Paret er en leseveiledning, aldri en dom.

Når du eskalerer, sett paret, rutemålet og det oppløste neste hoppet i samme notat. Neste ingeniør har da tre uavhengige ting å teste i stedet for et tjenestenavn å tolke på nytt. Mangler forhandlingen, ser de det straks, et galt mål lar importen mangle synlig, og et uoppløst neste hopp lar ruten være der, men ubrukelig.