EVPN type 2 kontra type 5: hvorfor én IP-adresse betyr to ruter

To ruter på samme boks kan peke på 198.51.100.77 og likevel svare på forskjellige spørsmål. Den ene beskriver hvor en MAC-adresse er nåbar og, valgfritt, hvilken IP som er bundet til den. Den andre beskriver et prefiks som løses opp gjennom et neste hopp, selv når prefikset er en enkelt vert. Blander man dem, får man en sak som ser ut som en rutingsfeil, men som egentlig er en feillesen rutetype.

Den raskeste måten å skille dem er å lese nøkkelen NLRI-en er bygget rundt, ikke masken på slutten.

Rutenøkkelen forteller hva ruten hevder

Type 2 er MAC/IP-annonseringsruten fra RFC 7432, og nøkkelen er den 48-biters MAC-adressen inne i NLRI-en. Bak denne nøkkelen ligger et IP-adressefelt der lengdefeltet kan være 0, 32 eller 128 biter, så en annonsering med bare MAC er en fullstendig rute og ikke en vertsoppføring med manglende deler. Etikettstakken som følger, peker på brokonteksten der MAC-en lever.

Om IP-feltet er fylt ut endrer hva ruten sier, ikke hva slags rute det er. Med en lengde på 32 eller 128 biter hevder avsenderen også at denne IP-en tilhører den MAC-en innenfor én EVPN-forekomst. Med null lengde fremsetter avsenderen ingen IP-påstand i det hele tatt. Ingen av versjonene sier at et prefiks er nåbart gjennom en ruter.

Type 5 er IP-prefiksruten fra RFC 9136, og nøkkelen er et prefiks skrevet som en lengde pluss så mange biter. Lengden går fra 0 til 32 for IPv4 og fra 0 til 128 for IPv6.

Begge endene av dette området er lovlige, og ingen av dem innebærer en MAC. Et prefiks med null lengde hevder nåbarhet uten å navngi en vert, mens et /32 navngir nøyaktig én adresse. NLRI-en bærer også en gateway-IP-adresse som utgangssiden bruker til å bygge overlay-indeksen, pluss en etikett for videresendingskonteksten. Det finnes ikke noe MAC-felt å svitsje på, derfor behandler en mottaker type 5 som en rutet destinasjon.

En /32-prefiksrute er ikke en omdøpt type 2

Prefikser i vertsstørrelse er vanlige type 5-ruter. En /32-prefiksrute og en type 2 for samme adresse kan begge finnes i én EVPN-forekomst, og de bærer ulik videresendingsinformasjon.

Ta 198.51.100.77 i en EVPN-forekomst som bruker VNI 10100. En type 2 kan pare den med MAC 02:00:00:00:00:77 og en etikett som identifiserer brodomenet der MAC-en ble lært. En type 5 kan annonsere 198.51.100.0/24 for hele subnettet, eller 198.51.100.77/32 bare for den adressen, med en gateway-adresse som peker på utgangs-VTEP-en. Adressene overlapper med vilje fordi rutene svarer på forskjellige spørsmål.

Den ene ruten sier at en endepunktbinding finnes og er nåbar gjennom en bestemt bro. Den andre sier at et prefiks er nåbart gjennom en bestemt ruter, uansett om noe endepunkt inni det noen gang er lært.

Forskjellen avgjør hvor du ser først når trafikken svikter. Hvis én enkelt vert er unåbar mens subnett-ruten ser fin ut, var type 5 aldri ment å bære den verten; se etter den manglende type 2. Hvis vertsruten finnes, men hele subnettet er unåbart, sjekk om type 5 i det hele tatt ble opprettet. Å lese feltene i rekkefølge slår å gjette ut fra maskelengden.

Les begge rutene uten å 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 linjen, og show l2route evpn mac ip viser de lokale MAC-til-IP-bindingene bak type 2-rutene. På Junos viser show evpn database lærte MAC- og IP-bindinger, mens show route table bgp.evpn.0 viser hva som ble annonsert og mottatt.

Filtrer på route distinguisher og Ethernet-tagg før du trekker konklusjoner. Den samme MAC-en eller prefikset kan dukke opp i flere EVPN-forekomster, og en rute som ser feil ut i én forekomst, kan være riktig i en annen.

Les deretter NLRI-en i rekkefølge: rutetype, nøkkel, gateway- eller etikettfelter, deretter route targets i attributtene. En type 2 med en ESI ulik null forteller at MAC-en er multi-homed, og nettopp den verdien binder annonseringene fra ulike PE-rutere sammen. En type 5 med en gateway-adresse forteller hvilken utgangs-VTEP som skal motta trafikken.

Hvis en rute mangler, sjekk opprettelsen før kodingen. Bekreft at kilden har bindingen eller prefikset lokalt, og bekreft deretter at route target-en som er knyttet til den, importeres på denne boksen. De fleste rapportene om en ødelagt type 5 ender på en importpolicy, ikke på NLRI-formatet.

Noter konteksten, ikke bare rutetypen

Skriv ned rutetypen, EVPN-forekomsten, route distinguisheren, de importerte og eksporterte route target-ene og det oppløste neste hoppet sammen. En type 2 uten forekomsten sin er tvetydig, og et neste hopp uten rutefamilien inviterer til feil konklusjon.

Begge er EVPN-ruter selv når nyttelasten er en IPv4-adresse. Adressefamilien inne i NLRI-en og adressefamilien til selve ruten er separate egenskaper, og en type 5 blir ikke en IPv4-unicast- eller VPN-IPv4-rute bare fordi den bærer et IPv4-prefiks.

Den forskjellen vises ved grensen mellom et EVPN-kontrollplan og en IP-VRF. Route target-en avgjør hvilken VRF som importerer prefikset, mens gateway-adressen og etiketten avgjør hvordan pakken kapsles inn mot utgangen. Les dem sammen, og videresendingsbeslutningen slutter å virke vilkårlig.

Neste gang et /32 dukker opp i EVPN-tabellen, sjekk nøkkelen før masken. En MAC-nøkkel med en valgfri IP er en type 2-binding; en prefiksnøkkel er en type 5-rute uansett lengde. Skriv route target-en og neste hopp ved siden av, og neste ingeniør slipper å utlede hele historien på nytt.