Twee routes op dezelfde box kunnen naar 198.51.100.77 wijzen en toch verschillende vragen beantwoorden. De ene beschrijft waar een MAC-adres bereikbaar is en, optioneel, welke IP eraan gebonden is. De andere beschrijft een prefix dat via een volgende hop wordt opgelost, zelfs wanneer dat prefix een enkele host is. Ze door elkaar halen levert een ticket op dat op een routingfout lijkt, maar in werkelijkheid een verkeerd gelezen routetype is.

De snelste manier om ze te onderscheiden is de sleutel lezen waar de NLRI omheen is gebouwd, niet het masker aan het einde.

De routesleutel vertelt wat de route beweert

Type 2 is de MAC/IP-aankondigingsroute uit RFC 7432, en de sleutel is het 48-bits MAC-adres binnen de NLRI. Achter die sleutel zit een IP-adresveld waarvan het lengteveld 0, 32 of 128 bits kan zijn, dus een aankondiging met alleen MAC is een volledige route en geen hostvermelding met ontbrekende delen. De labelstack die volgt wijst naar de bridgecontext waarin die MAC leeft.

Of het IP-veld is ingevuld verandert wat de route stelt, niet wat voor route het is. Met een lengte van 32 of 128 bits beweert de afzender ook dat deze IP binnen één EVPN-instantie bij die MAC hoort. Met een lengte van nul doet de afzender helemaal geen IP-bewering. Geen van beide versies zegt dat een prefix via een router bereikbaar is.

Type 5 is de IP-prefixroute uit RFC 9136, en de sleutel is een prefix geschreven als een lengte plus zoveel bits. De lengte loopt van 0 tot 32 voor IPv4 en van 0 tot 128 voor IPv6.

Beide uiteinden van dat bereik zijn toegestaan, en geen van beide impliceert een MAC. Een prefix van lengte nul beweert bereikbaarheid zonder een host te noemen, terwijl een /32 precies één adres noemt. De NLRI draagt ook een gateway-IP-adres dat de uitgaande kant gebruikt om de overlay-index op te bouwen, plus een label voor de doorstuurcontext. Er is geen MAC-veld om op te schakelen, daarom behandelt een ontvanger type 5 als een gerouteerde bestemming.

Een /32-prefixroute is geen omgedoopt type 2

Prefixen van hostgrootte zijn gewone type 5-routes. Een /32-prefixroute en een type 2 voor hetzelfde adres kunnen beide in één EVPN-instantie bestaan, en ze dragen verschillende doorstuurinformatie.

Neem 198.51.100.77 in een EVPN-instantie met VNI 10100. Een type 2 kan die koppelen aan MAC 02:00:00:00:00:77 en een label dat het bridgedomein identificeert waar die MAC is geleerd. Een type 5 kan 198.51.100.0/24 voor het hele subnet aankondigen, of 198.51.100.77/32 alleen voor dat adres, met een gateway-adres dat naar de uitgaande VTEP wijst. De adressen overlappen opzettelijk omdat de routes verschillende vragen beantwoorden.

De ene route zegt dat er een endpointbinding bestaat en dat die via een bepaalde bridge bereikbaar is. De andere zegt dat een prefix via een bepaalde router bereikbaar is, of er ooit een endpoint in is geleerd of niet.

Dat verschil bepaalt waar je eerst kijkt als verkeer faalt. Als één host onbereikbaar is terwijl zijn subnetroute er goed uitziet, was type 5 nooit bedoeld om die host te dragen; zoek de ontbrekende type 2. Als de hostroute bestaat maar het hele subnet onbereikbaar is, controleer of type 5 überhaupt is aangemaakt. De velden op volgorde lezen is beter dan gokken op basis van de maskerlengte.

Beide routes lezen zonder te gokken

Op NX-OS verdelen show bgp l2vpn evpn route type 2 en show bgp l2vpn evpn route type 5 de tabel precies langs deze lijn, en show l2route evpn mac ip toont de lokale MAC-naar-IP-bindingen achter de type 2-routes. Op Junos somt show evpn database geleerde MAC- en IP-bindingen op, terwijl show route table bgp.evpn.0 toont wat is aangekondigd en ontvangen.

Filter op route distinguisher en Ethernet-tag voordat je conclusies trekt. Dezelfde MAC of prefix kan in meerdere EVPN-instanties voorkomen, en een route die in de ene instantie fout lijkt, kan in een andere juist zijn.

Lees daarna de NLRI op volgorde: routetype, sleutel, gateway- of labelvelden, dan de route targets in de attributen. Een type 2 met een ESI die niet nul is, zegt dat de MAC multi-homed is, en juist die waarde verbindt de aankondigingen van verschillende PE-routers. Een type 5 met een gateway-adres zegt welke uitgaande VTEP het verkeer moet ontvangen.

Als een route ontbreekt, controleer dan de totstandkoming vóór de codering. Bevestig dat de bron de binding of het prefix lokaal heeft, en bevestig dan dat de route target die eraan hangt op deze box wordt geïmporteerd. De meeste meldingen van een kapotte type 5 eindigen bij een importbeleid, niet bij het NLRI-formaat.

Leg de context vast, niet alleen het routetype

Schrijf het routetype, de EVPN-instantie, de route distinguisher, de geïmporteerde en geëxporteerde route targets en de opgeloste volgende hop bij elkaar op. Een type 2 zonder zijn instantie is dubbelzinnig, en een volgende hop zonder de routefamilie nodigt uit tot een verkeerde conclusie.

Beide zijn EVPN-routes, ook wanneer de payload een IPv4-adres is. De adresfamilie binnen de NLRI en de adresfamilie van de route zelf zijn aparte eigenschappen, en een type 5 wordt niet vanzelf een IPv4-unicast- of VPN-IPv4-route doordat hij een IPv4-prefix draagt.

Dat onderscheid is zichtbaar op de grens tussen een EVPN-controlelaag en een IP-VRF. De route target bepaalt welke VRF het prefix importeert, terwijl het gateway-adres en het label bepalen hoe het pakket richting de uitgang wordt ingekapseld. Lees die samen, en de doorsturbeslissing ziet er niet langer willekeurig uit.

De volgende keer dat er een /32 in de EVPN-tabel verschijnt, controleer de sleutel vóór het masker. Een MAC-sleutel met een optionele IP is een type 2-binding; een prefixsleutel is een type 5-route, hoe lang die ook is. Schrijf de route target en de volgende hop ernaast, en de volgende ingenieur hoeft het hele verhaal niet opnieuw af te leiden.

Gerelateerde artikelen