AFI og SAFI: les paret før tenestenamnet

Du kan sjå ein sesjon kome opp, sjå ei rute dukke opp, og likevel lese feil teneste. Talparet fremst i kvar annonsering, adressefamilieidentifikatoren og den påfølgjande adressefamilieidentifikatoren, avgjer kva parser som les nyttelasta, og kva tabell som held resultatet. Tek du feil av paret, køyrer importpolicyen, rutemål-treffet og oppslaget etter neste hopp alle mot ein struktur ingen annonserte. Gjennomgangen nedanfor startar ved det paret og sluttar ved resultatet av videresendinga.

To tal avgjer kva tabell ruta høyrer til i

Paret opptrer to gonger: inne i multiprotokoll-kapabiliteten, der ein talar annonserer ein familie, og framom kvar NLRI som den familien ber. Det gjer det til ein eigenskap ved ruta snarare enn ei innstilling på opphavsboksen. Leverandørar trykkjer det som eit namn som Address family VPNv4 Unicast, og formuleringa flyttar seg mellom utgåver medan tala blir ståande.

Fire kodingar dekkjer nesten alle verksemds tilfelle: 1 med 128 for MPLS-merkt 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 å tru at kvar Layer 2-teneste ligg bak 25 med 65, noko som skjuler EVPN. Den andre er å handsame dei to IP-familiane som éin familie med lengre adresse, når dei blir forhandla kvar for seg og kan godtakast på ulike peer-ar. Ein tredje oppstår når ein mal blir kopiert frå ei utgåve som berre kjenner éin av dei. Eit oppslag i registeret avgjer alle tre raskare enn ein gissing bygd på tenestenamnet.

Handsam dei fire radene som døme frå IANA-registeret, ikkje som registeret sjølv. Når eit tal ikkje passar med noko du kjenner, slå det opp før du byggjer ein policy rundt det.

AFI 25 ber to ubeslekta NLRI-format

Begge Layer 2-familiane ligg under AFI 25, og likskapen stoppar der. VPLS-NLRI i RFC 4761 section 3.2.2 ber ei lengd, ein rutedistinguisher, ein VE ID, ei VE-blokkforskyving, ein VE-blokkstorleik og ein etikettbase, som saman namngjev eit pseudowire-endepunkt og etiketten. EVPN held på AFI 25 og flyttar til SAFI 70, der nyttelasta er ein rutetype: Ethernet-autooppdaging, MAC/IP-annonsering, inklusiv multicast, Ethernet-segment, IP-prefiks. Difor tyder same byteforskyving ulike ting i dei to familiane. Ein parser skriven for den eine les den andre utan klage og lagar vrøvl. Paret er den einaste åtvaringa om at tolkinga er feil.

Eit felt som tyder VE-blokkforskyving i den eine familien, har ingen motpart i den andre, og MAC/IP-annonseringsruta finst berre i EVPN. Å sitere ein attributt som om det gjaldt for begge, er korleis ein gjennomgang av eit opptak går gale.

Når nokon gir deg eit opptak eller ein leverandørtabell, spør kva familie attributten høyrer til. Stadfest deretter at mottakarimplementasjonen støttar den familien, ikkje tenestenamnet på databladet. To plattformer kan begge hevde VPLS-støtte medan dei implementerer ulike signaleringsfamiliar. Paret skil dei; produktetiketten gjer det ikkje.

Sesjonen sin eigen adressefamilie er eit eige spørsmål

VPN-IPv6 blir rutinemessig annonsert over ein sesjon der TCP-sambandet går over IPv4, og det er støtta design, ikkje ein feil. Å lese berre sesjonssammandraget seier difor ingenting om kva VPN-familiar peer-ane byter.

NLRI-familie, transportfamilie og videresendingsfamilie er tre sjølvstendige avgjerder. Ein ruter kan snakke IPv4 med peer-en sin, godta rekkevidd for VPN-IPv6 og installere ei rute der neste hopp er ei IPv6-adresse som ein når via ein veg du ikkje hadde tenkt deg. Kvart lag treng si eiga stadfesting. Stader som melder om uoppnåelege IPv6-destinasjonar medan annonseringane ser riktige ut, har vanlegvis mista oppslaget av neste hopp, ikkje familiforhandlinga.

Test adressefamilien til sesjonen for seg, deretter familiane han ber, deretter kva kjerna kan videresende. Å halde dei tre frå kvarandre hindrar den vanlege feildiagnosen der ei korrekt annonsering blir lese som prov på at IPv6 verkar ende til ende. Det provar berre at éin peer fortalde ein annan om eit prefiks.

Forhandla, motteke, importert, installert

For éi forventa rute må fire tilstandar gjelde i rekkjefølgje, og kvar er observerbar. Familien må vere forhandla med den peer-en, ruta må kome, eit rutemål må importere henne til den tiltenkte konteksten, og neste hopp må løysast opp slik at ruta blir installert. Å hoppe over den første tilstanden gjer dei tre andre ubesvarlege, fordi ein uforhandla familie ikkje lagar ruter å inspisere. På Cisco-liknande plattformer er familiesammandraga og kapabilitetane per peer eigne kommandoar.

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

Forhandlinga viser seg i kapabilitetsutvekslinga som blir skriven ut per peer, og ein etablert sesjon utan nokon oppført familie ber ingenting av det du bad om. Importen blir avgjort av rutemål som blir borne som utvida communities, så eit korrekt par med eit feilskrive mål lèt tabellen stå tom. Installasjonen avheng deretter av at neste hopp blir løyst opp i mottakarkonteksten, noko som kan feile medan kvar annonsering ser perfekt ut.

Stadfest dataplanet sist, fordi ei rute i tabellen er ein påstand, ikkje ei levering. Dei same fire tilstandane gjeld for kvar familie; berre kommandoane og tabellnamna blir endra.

Kva eit familiepar aldri provar

Å lese paret rett fortel deg korleis du skal tolke rutingsinformasjonen som følgjer, og det er heile påstanden. Det seier ingenting om rekkevidd, ingenting om policy og ingenting om helsa til dataplanet. Å blande dei to gir sjølvsikre utsegner om eit nettverk ingen har verifisert. Eit rutemål-avvik og eit brote neste hopp ser identiske ut berre ut frå paret. Paret er ei leseinstruksjon, aldri ein dom.

Når du eskalerer, set paret, rutemålet og det oppløyste neste hoppet i same notat. Den neste ingeniøren har då tre sjølvstendige ting å teste i staden for eit tenestenamn å nytolke. Manglar forhandlinga ser dei det med ein gong, eit feil mål lèt importen mangle synleg, og eit uoppløyst neste hopp lèt ruta stå der, men ubrukeleg.