EVPN type 2 kontra type 5: kvifor éi IP-adresse tyder to ruter

To ruter på same boksen kan peike på 198.51.100.77 og likevel svare på ulike spørsmål. Den eine skildrar kvar ein MAC-adresse er nåbar og, valfritt, kva IP som er bunden til henne. Den andre skildrar eit prefiks som blir løyst opp gjennom eit neste hopp, sjølv når prefikset er ein einaste vert. Blandar ein dei, får ein ei sak som ser ut som ein rutefeil, men som eigentleg er ein feillesen rutetype.

Den raskaste måten å skilje dei på er å lese nøkkelen NLRI-en er bygd kring, ikkje maska på slutten.

Rutenøkkelen fortel kva ruta hevdar

Type 2 er MAC/IP-kunngjeringsruta frå RFC 7432, og nøkkelen er den 48-bits MAC-adressa inne i NLRI-en. Bak denne nøkkelen ligg eit IP-adressefelt der lengdefeltet kan vere 0, 32 eller 128 bit, så ei kunngjering med berre MAC er ei fullstendig rute og ikkje ei vertsoppføring med manglande delar. Etikettstabelen som følgjer, peikar på brukonteksten der MAC-en lever.

Om IP-feltet er fylt ut endrar kva ruta seier, ikkje kva slag rute det er. Med ei lengd på 32 eller 128 bit hevdar sendaren også at denne IP-en høyrer til den MAC-en innanfor éin EVPN-førekomst. Med null lengd kjem sendaren ikkje med noko IP-påstand i det heile. Ingen av versjonane seier at eit prefiks er nåbart gjennom ein ruter.

Type 5 er IP-prefiksruta frå RFC 9136, og nøkkelen er eit prefiks skrive som ei lengd pluss så mange bit. Lengda går frå 0 til 32 for IPv4 og frå 0 til 128 for IPv6.

Begge endane av dette området er lovlege, og ingen av dei inneber ein MAC. Eit prefiks med null lengd hevdar nåbarheit utan å namngje ein vert, medan eit /32 namngjev nøyaktig éi adresse. NLRI-en ber også ei gateway-IP-adresse som utgangssida brukar til å byggje overlay-indeksen, pluss ein etikett for vidaresendingskonteksten. Det finst ikkje noko MAC-felt å svitsje på, difor handsamar ein mottakar type 5 som ein ruta destinasjon.

Ei /32-prefiksrute er ikkje ein omdøypt type 2

Prefiks i vertsstorleik er vanlege type 5-ruter. Ei /32-prefiksrute og ein type 2 for same adresse kan båe finnast i éin EVPN-førekomst, og dei ber ulik vidaresendingsinformasjon.

Ta 198.51.100.77 i ein EVPN-førekomst som brukar VNI 10100. Ein type 2 kan pare henne med MAC 02:00:00:00:00:77 og ein etikett som identifiserer brudomenet der MAC-en vart lært. Ein type 5 kan kunngjere 198.51.100.0/24 for heile subnettet, eller 198.51.100.77/32 berre for den adressa, med ei gateway-adresse som peikar på utgangs-VTEP-en. Adressene overlappar med vilje fordi rutene svarar på ulike spørsmål.

Den eine ruta seier at ein endepunktbinding finst og er nåbar gjennom ei bestemd bru. Den andre seier at eit prefiks er nåbart gjennom ein bestemd ruter, uansett om noko endepunkt inni det nokon gong er lært.

Skilnaden avgjer kvar du ser først når trafikken sviktar. Viss éin einaste vert er unåbar medan subnett-ruta ser fin ut, var type 5 aldri meint å bere den verten; sjå etter den manglande type 2. Viss vertsruta finst, men heile subnettet er unåbart, sjekk om type 5 i det heile vart oppretta. Å lese felta i rekkjefølgje slår å gjette ut frå maskelengda.

Les båe rutene utan å gjette

På NX-OS deler show bgp l2vpn evpn route type 2 og show bgp l2vpn evpn route type 5 tabellen nøyaktig langs denne linja, og show l2route evpn mac ip viser dei lokale MAC-til-IP-bindingane bak type 2-rutene. På Junos viser show evpn database lærde MAC- og IP-bindingar, medan show route table bgp.evpn.0 viser kva som vart kunngjort og motteke.

Filtrer på route distinguisher og Ethernet-tagg før du dreg konklusjonar. Den same MAC-en eller prefikset kan dukke opp i fleire EVPN-førekomstar, og ei rute som ser feil ut i éin førekomst, kan vere riktig i ein annan.

Les deretter NLRI-en i rekkjefølgje: rutetype, nøkkel, gateway- eller etikettfelt, deretter route targets i attributta. Ein type 2 med ein ESI ulik null fortel at MAC-en er multi-homed, og nettopp den verdien bind kunngjeringane frå ulike PE-ruterar saman. Ein type 5 med ei gateway-adresse fortel kva utgangs-VTEP som skal ta imot trafikken.

Viss ei rute manglar, sjekk opprettinga før kodinga. Stadfest at kjelda har bindinga eller prefikset lokalt, og stadfest deretter at route target-en som er knytt til henne, blir importert på denne boksen. Dei fleste rapportane om ein øydelagd type 5 endar på ein importpolicy, ikkje på NLRI-formatet.

Noter konteksten, ikkje berre rutetypen

Skriv ned rutetypen, EVPN-førekomsten, route distinguisheren, dei importerte og eksporterte route target-ane og det oppløyste neste hoppet saman. Ein type 2 utan førekomsten sin er tvitydig, og eit neste hopp utan rutefamilien inviterer til feil konklusjon.

Båe er EVPN-ruter sjølv når nyttelasta er ei IPv4-adresse. Adressefamilien inne i NLRI-en og adressefamilien til sjølve ruta er separate eigenskapar, og ein type 5 blir ikkje ei IPv4-unicast- eller VPN-IPv4-rute berre fordi ho ber eit IPv4-prefiks.

Skilnaden viser seg ved grensa mellom eit EVPN-kontrollplan og ein IP-VRF. Route target-en avgjer kva VRF som importerer prefikset, medan gateway-adressa og etiketten avgjer korleis pakken blir kapsla inn mot utgangen. Les dei saman, og vidaresendingsavgjerda sluttar å verke vilkårleg.

Neste gong eit /32 dukkar opp i EVPN-tabellen, sjekk nøkkelen før maska. Ein MAC-nøkkel med ein valfri IP er ei type 2-binding; ein prefiksnøkkel er ei type 5-rute uansett lengd. Skriv route target-en og neste hopp ved sida av, og neste ingeniør slepp å utleia heile historia på nytt.