AFI og SAFI: læs parret før servicenavnet

Du kan se en session komme op, se en rute dukke frem og alligevel læse den forkerte service. Parret af tal foran hver annoncering, adressefamilieidentifikatoren og den efterfølgende adressefamilieidentifikator, afgør hvilken parser der læser nyttelasten, og hvilken tabel der holder resultatet. Tager du fejl af parret, kører importpolitikken, routetarget-matchningen og næste-hop-opslaget alle mod en struktur, ingen annoncerede. Gennemgangen nedenfor starter ved det par og slutter ved videresendelsesresultatet.

To tal afgør, hvilken tabel ruten hører til i

Parret optræder to gange: inde i multiprotokol-kapabiliteten, hvor en speaker annoncerer en familie, og foran hver NLRI, som den familie bærer. Det gør det til en egenskab ved ruten snarere end en indstilling på den oprindelige boks. Leverandører trykker det som et navn som Address family VPNv4 Unicast, og formuleringen flytter sig mellem udgivelser, mens tallene bliver på plads.

Fire kodninger dækker næsten alle virksomhedstilfælde: 1 med 128 til MPLS-mærket VPN-IPv4, 2 med 128 til IPv6-ækvivalenten, 25 med 65 til BGP-signaliseret VPLS og 25 med 70 til EVPN. Den første fejl er at antage, at enhver Layer 2-service ligger bag 25 med 65, hvilket skjuler EVPN. Den anden er at behandle de to IP-familier som én familie med en længere adresse, når de forhandles separat og kan accepteres på forskellige peers. En tredje opstår, når en skabelon kopieres fra en udgivelse, der kun kender én af dem. Et opslag i registret afgør alle tre hurtigere end et gæt bygget på servicenavnet.

Behandl de fire rækker som eksempler fra IANA-registret, ikke registret selv. Når et tal ikke matcher noget, du genkender, så slå det op, før du bygger en politik omkring det.

AFI 25 bærer to uafhængige NLRI-formater

Begge Layer 2-familier ligger under AFI 25, og ligheden stopper der. VPLS-NLRI'et i RFC 4761 section 3.2.2 bærer en længde, en routedistinguisher, et VE ID, en VE-blokforskydning, en VE-blokstørrelse og en labelbase, som tilsammen navngiver et pseudowire-endepunkt og dets label. EVPN beholder AFI 25 og flytter til SAFI 70, hvor nyttelasten er en rutetype: Ethernet-autoopdagelse, MAC/IP-annoncering, inklusiv multicast, Ethernet-segment, IP-præfiks. Derfor betyder den samme byteforskydning forskellige ting i de to familier. En parser skrevet til den ene læser den anden uden klage og producerer vrøvl. Parret er den eneste advarsel om, at fortolkningen er forkert.

Et felt, der betyder VE-blokforskydning i den ene familie, har ingen modpart i den anden, og MAC/IP-annonceringsruten findes kun i EVPN. At citere en attribut, som om den gjaldt for begge, er hvordan en gennemgang af en optagelse går galt.

Når nogen giver dig en optagelse eller en leverandørtabel, så spørg, hvilken familie attributten hører til. Bekræft derefter, at den modtagende implementering understøtter den familie, ikke servicenavnet på databladet. To platforme kan begge hævde VPLS-understøttelse, mens de implementerer forskellige signaleringsfamilier. Parret skiller dem; produktmærket gør ikke.

Sessionens egen adressefamilie er et separat spørgsmål

VPN-IPv6 annonceres rutinemæssigt over en session, hvis TCP-forbindelse kører over IPv4, og det er understøttet design, ikke en fejl. At læse kun sessionsoversigten siger derfor intet om, hvilke VPN-familier peerne udveksler.

NLRI-familie, transportfamilie og videresendelsesfamilie er tre uafhængige beslutninger. En router kan tale IPv4 med sin peer, acceptere VPN-IPv6-rækkevidde og installere en rute, hvis næste hop er en IPv6-adresse, der kan nås ad en vej, du ikke havde tænkt på. Hvert lag kræver sin egen bekræftelse. Steder, der rapporterer uopnåelige IPv6-destinationer, mens annonceringerne ser korrekte ud, har som regel mistet næste-hop-opløsningen, ikke familienegocieringen.

Test sessionens adressefamilie for sig, derefter de familier, den bærer, derefter hvad kernen kan videresende. At holde de tre adskilt forhindrer den almindelige fejldiagnose, hvor en korrekt annoncering læses som bevis på, at IPv6 virker ende til ende. Det beviser kun, at den ene peer har fortalt den anden om et præfiks.

Forhandlet, modtaget, importeret, installeret

For én forventet rute skal fire tilstande gælde i rækkefølge, og hver er observerbar. Familien skal være forhandlet med den peer, ruten skal ankomme, et routetarget skal importere den i den tilsigtede kontekst, og næste hop skal opløses, så ruten installeres. Springes den første tilstand over, bliver de tre andre ubesvarlige, fordi en uforhandlet familie ikke producerer ruter at inspicere. På Cisco-lignende platforme er familiesummeringerne og kapabiliteterne pr. 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 ses i kapabilitetsudvekslingen, der printes pr. peer, og en etableret session uden nogen angivet familie bærer intet af det, du bad om. Import afgøres af routetargets, der bæres som udvidede communities, så et korrekt par med et fejlskrevet target efterlader tabellen tom. Installationen afhænger derefter af, at næste hop opløses i den modtagende kontekst, hvilket kan fejle, mens hver annoncering ser perfekt ud.

Bekræft dataplanet sidst, fordi en rute i tabellen er en påstand, ikke en levering. De samme fire tilstande gælder for hver familie; kun kommandoerne og tabelnavnene ændrer sig.

Hvad et familiepar aldrig beviser

At læse parret korrekt fortæller dig, hvordan du skal fortolke den rutningsinformation, der følger, og det er hele påstanden. Det siger intet om rækkevidde, intet om politik og intet om dataplanets sundhed. At forveksle de to producerer selvsikre udsagn om et netværk, ingen har verificeret. Uoverensstemmelse i routetarget og et brudt næste hop ser identiske ud alene ud fra parret. Parret er en læseinstruktion, aldrig en dom.

Når du eskalerer, så sæt parret, routetargetet og det opløste næste hop i samme note. Den næste ingeniør har så tre uafhængige ting at teste i stedet for et servicenavn at genfortolke. Mangler forhandlingen, ser de det med det samme, et forkert target efterlader importen synligt fraværende, og et uopløst næste hop efterlader ruten til stede, men ubrugelig.