AFI og SAFI: les paret før tjenestenavnet

Du kan se en sesjon komme opp, se en rute dukke opp, og likevel lese feil tjeneste. Tallparet først i hver annonsering, adressefamilieidentifikatoren og den påfølgende adressefamilieidentifikatoren, avgjør hvilken parser som leser nyttelasten, og hvilken tabell som holder resultatet. Tar du feil av paret, kjører importpolicyen, rutemål-treffet og neste hopp-oppslaget alle mot en struktur ingen annonserte. Gjennomgangen nedenfor starter ved det paret og slutter ved videresendingsresultatet.

To tall avgjør hvilken tabell ruten hører til i

Paret opptrer to ganger: inne i multiprotokoll-kapabiliteten, der en speaker annonserer en familie, og foran hver NLRI som den familien bærer. Det gjør det til en egenskap ved ruten snarere enn en innstilling på opprinnelsesboksen. Leverandører trykker det som et navn som Address family VPNv4 Unicast, og formuleringen flytter seg mellom utgivelser mens tallene blir stående.

Fire kodinger dekker nesten alle virksomhetstilfeller: 1 med 128 for MPLS-merket VPN-IPv4, 2 med 128 for IPv6-ekvivalenten, 25 med 65 for BGP-signalisert VPLS og 25 med 70 for EVPN. Den første feilen er å anta at enhver Layer 2-tjeneste ligger bak 25 med 65, noe som skjuler EVPN. Den andre er å behandle de to IP-familiene som én familie med lengre adresse, når de forhandles separat og kan aksepteres på ulike peers. En tredje oppstår når en mal kopieres fra en utgivelse som bare kjenner én av dem. Et oppslag i registeret avgjør alle tre raskere enn en gjetning bygget på tjenestenavnet.

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

AFI 25 bærer to ubeslektede NLRI-formater

Begge Layer 2-familiene ligger under AFI 25, og likheten stopper der. VPLS-NLRI i RFC 4761 section 3.2.2 bærer en lengde, en rutedistinguisher, en VE ID, en VE-blokkforskyvning, en VE-blokkstørrelse og en etikettbase, som sammen navngir et pseudowire-endepunkt og etiketten. EVPN beholder AFI 25 og flytter til SAFI 70, der nyttelasten er en rutetype: Ethernet-autoopdagelse, MAC/IP-annonsering, inklusiv multicast, Ethernet-segment, IP-prefiks. Derfor betyr samme byteforskyvning forskjellige ting i de to familiene. En parser skrevet for den ene leser den andre uten klage og produserer vrøvl. Paret er den eneste advarselen om at tolkningen er feil.

Et felt som betyr VE-blokkforskyvning i den ene familien, har ingen motpart i den andre, og MAC/IP-annonseringsruten finnes bare i EVPN. Å sitere en attributt som om den gjaldt for begge, er hvordan en gjennomgang av en opptak går galt.

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

Sesjonens egen adressefamilie er et eget spørsmål

VPN-IPv6 annonseres rutinemessig over en sesjon der TCP-forbindelsen går over IPv4, og det er støttet design, ikke en feil. Å lese bare 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 sin, akseptere rekkevidde for VPN-IPv6 og installere en rute der neste hopp er en IPv6-adresse som nås via en vei du ikke hadde tenkt deg. Hvert lag trenger sin egen bekreftelse. Steder som melder om uoppnåelige IPv6-destinasjoner mens annonseringene ser riktige ut, har vanligvis mistet neste hopp-oppslaget, ikke familiforhandlingen.

Test sesjonens adressefamilie for seg, deretter familiene den bærer, deretter hva kjernen kan videresende. Å holde de tre fra hverandre hindrer den vanlige feildiagnosen der en korrekt annonsering leses som bevis på at IPv6 virker ende til ende. Det beviser bare at én peer fortalte en annen om et prefiks.

Forhandlet, mottatt, importert, installert

For én forventet rute må fire tilstander gjelde i rekkefølge, og hver er observerbar. Familien må være forhandlet med den peeren, ruten må ankomme, et rutemål må importere den til den tiltenkte konteksten, og neste hopp må løses opp slik at ruten installeres. Å hoppe over den første tilstanden gjør de tre andre ubesvarlige, fordi en uforhandlet familie ikke produserer ruter å inspisere. På Cisco-lignende plattformer er familiesammendragene og kapabilitetene per peer separate 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 deretter av at neste hopp løses opp i mottakerkonteksten, noe som kan feile mens hver annonsering ser perfekt ut.

Bekreft dataplanet sist, fordi en rute i tabellen er en påstand, ikke en levering. 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 selvsikre utsagn om et nettverk ingen har verifisert. Et rutemål-avvik og et brutt neste hopp ser identiske ut bare ut fra paret. Paret er en leseinstruksjon, aldri en dom.

Når du eskalerer, sett paret, rutemålet og det oppløste neste hoppet i samme notat. Den neste ingeniøren har da tre uavhengige ting å teste i stedet for et tjenestenavn å nytolke. Mangler forhandlingen ser de det med en gang, et feil mål lar importen mangle synlig, og et uoppløst neste hopp lar ruten stå der, men ubrukelig.