EVPN 2-es típus kontra 5-ös típus: miért jelent egy IP-cím két útvonalat

Két útvonal ugyanazon a dobozon mutathat a 198.51.100.77 címre, és mégis különböző kérdésekre válaszolhat. Az egyik azt írja le, hol érhető el egy MAC-cím, és opcionálisan, melyik IP van hozzá kötve. A másik egy előtagot ír le, amely a következő ugráson keresztül oldódik fel, még akkor is, ha ez az előtag egyetlen hoszt. Az összekeverésük olyan hibajegyet eredményez, amely útválasztási hibának tűnik, de valójában félreolvasott útvonaltípus.

A leggyorsabb megkülönböztetési mód az, hogy az NLRI köré épített kulcsot olvassuk, nem a végén lévő maszkot.

Az útvonal kulcsa megmondja, mit állít az útvonal

A 2-es típus az RFC 7432 MAC/IP hirdetési útvonala, kulcsa pedig az NLRI-n belüli 48 bites MAC-cím. A kulcs mögött egy IP-cím mező áll, amelynek hosszmezője 0, 32 vagy 128 bit lehet, így a csak MAC-et tartalmazó hirdetés teljes útvonal, nem hiányzó részekkel rendelkező hosztbejegyzés. A következő címkehalom arra a hídkontextusra mutat, ahol ez a MAC él.

Az, hogy az IP-mező ki van-e töltve, azt változtatja meg, amit az útvonal állít, nem az útvonal fajtáját. 32 vagy 128 bites hossz esetén a küldő azt is állítja, hogy ez az IP egy EVPN-példányon belül ahhoz a MAC-hez tartozik. Nulla hossz esetén a küldő egyáltalán nem tesz IP-állítást. Egyik változat sem mondja, hogy egy előtag egy routeren keresztül elérhető.

Az 5-ös típus az RFC 9136 IP-előtag útvonala, kulcsa pedig egy előtag, amelyet hosszként és annyi bitként írnak le. A hossz IPv4 esetén 0-tól 32-ig, IPv6 esetén 0-tól 128-ig terjed.

Ennek a tartománynak mindkét vége szabályos, és egyik sem feltételez MAC-et. A nulla hosszúságú előtag hoszt megnevezése nélkül állít elérhetőséget, míg a /32 pontosan egy címet nevez meg. Az NLRI egy átjáró IP-címet is hordoz, amelyet a kimenő oldal az overlay-index felépítéséhez használ, valamint egy címkét a továbbítási kontextushoz. Nincs MAC-mező, amelyre kapcsolni lehetne, ezért a fogadó az 5-ös típust irányított célként kezeli.

A /32-es előtagútvonal nem átnevezett 2-es típus

A hoszt méretű előtagok közönséges 5-ös típusú útvonalak. A /32-es előtagútvonal és ugyanahhoz a címhez tartozó 2-es típus egyaránt létezhet egy EVPN-példányban, és különböző továbbítási információt hordoznak.

Vegyük a 198.51.100.77 címet egy VNI 10100-at használó EVPN-példányban. A 2-es típus párosíthatja a MAC 02:00:00:00:00:77 címmel és egy címkével, amely azonosítja azt a hídtartományt, ahol ezt a MAC-et megtanulta. Az 5-ös típus hirdetheti a 198.51.100.0/24-et a teljes alhálózatra, vagy a 198.51.100.77/32-et csak arra a címre, egy átjárócímmel, amely a kimenő VTEP-re mutat. A címek szándékosan fedik egymást, mert az útvonalak különböző kérdésekre válaszolnak.

Az egyik útvonal azt mondja, hogy létezik egy végpont-kötés, és egy adott hídon keresztül elérhető. A másik azt mondja, hogy egy előtag egy adott routeren keresztül elérhető, függetlenül attól, hogy tanult-e valaha végpontot benne.

Ez a különbség dönti el, hova nézzünk először, amikor a forgalom meghibásodik. Ha egyetlen hoszt elérhetetlen, miközben az alhálózati útvonala rendben lévőnek tűnik, az 5-ös típus soha nem volt hivatott azt a hosztot szállítani; keressük a hiányzó 2-es típust. Ha a hosztútvonal létezik, de a teljes alhálózat elérhetetlen, ellenőrizzük, hogy az 5-ös típus egyáltalán létrejött-e. A mezők sorrendben történő olvasása jobb, mint a maszk hosszából következtetni.

Mindkét útvonal olvasása találgatás nélkül

NX-OS-en a show bgp l2vpn evpn route type 2 és show bgp l2vpn evpn route type 5 pontosan ezen a vonalon osztja fel a táblát, és a show l2route evpn mac ip a 2-es típusú útvonalak mögötti helyi MAC–IP kötéseket mutatja. Junoson a show evpn database a megtanult MAC- és IP-kötéseket listázza, míg a show route table bgp.evpn.0 azt mutatja, mit hirdettek és fogadtak.

A következtetések levonása előtt szűrjön route distinguisher és Ethernet-címke szerint. Ugyanaz a MAC vagy előtag több EVPN-példányban is megjelenhet, és egy útvonal, amely az egyik példányban hibásnak tűnik, a másikban helyes lehet.

Ezután olvassa az NLRI-t sorrendben: útvonaltípus, kulcs, átjáró- vagy címkemezők, majd az attribútumok route targetjei. A nem nulla ESI-t hordozó 2-es típus azt mondja, hogy a MAC multi-homed, és éppen ez az érték köti össze a különböző PE-routerek hirdetéseit. Az átjárócímet hordozó 5-ös típus azt mondja, melyik kimenő VTEP-nek kell fogadnia a forgalmat.

Ha hiányzik egy útvonal, a kódolás előtt ellenőrizze a létrejöttét. Erősítse meg, hogy a forrás helyben rendelkezik a kötéssel vagy az előtaggal, majd erősítse meg, hogy a hozzá csatolt route target importálva van ezen a dobozon. A hibás 5-ös típusról szóló jelentések többsége importszabályzatnál ér véget, nem az NLRI formátumánál.

A kontextust rögzítse, ne csak az útvonaltípust

Írja fel együtt az útvonaltípust, az EVPN-példányt, a route distinguishert, az importált és exportált route targeteket és a feloldott következő ugrást. A példánya nélküli 2-es típus kétértelmű, és az útvonalcsalád nélküli következő ugrás rossz következtetésre csábít.

Mindkettő EVPN-útvonal akkor is, ha a hasznos teher IPv4-cím. Az NLRI-n belüli címcsalád és magának az útvonalnak a címcsaládja külön tulajdonságok, és az 5-ös típus nem válik IPv4-unicast vagy VPN-IPv4 útvonallá csak azért, mert IPv4-előtagot hordoz.

Ez a megkülönböztetés az EVPN vezérlősík és az IP-VRF határán jelenik meg. A route target dönti el, melyik VRF importálja az előtagot, míg az átjárócím és a címke dönti el, hogyan csomagolódik a csomag a kimenet felé. Olvassa ezeket együtt, és a továbbítási döntés megszűnik önkényesnek tűnni.

Amikor legközelebb /32 jelenik meg az EVPN-táblában, a maszk előtt ellenőrizze a kulcsot. Az opcionális IP-vel rendelkező MAC-kulcs 2-es típusú kötés; az előtagkulcs 5-ös típusú útvonal, bármilyen hosszú is. Írja mellé a route targetet és a következő ugrást, és a következő mérnöknek nem kell újra levezetnie az egész történetet.