Miért mutathat egy EVPN-bérlő több route distinguisher-t
Két RD egy bérlőn belül nem konfliktus. Haladjon a CLI-kimenettől a route-ot létrehozó MAC-VRF vagy IP-VRF felé, majd ellenőrizze az RT-importot és a VNI-t.
Egy bérlőre szűri az EVPN-táblát, és a route-ok két különböző route distinguisher-t hordoznak. Az első ösztön a konfigurációs konfliktus, és ez az ösztön általában téves. A bérlőnév üzleti címke, nem a vezérlősík egyetlen objektuma, ezért a benne lévő áthidaló kontextus és az útválasztási kontextus jogszerűen hirdethet külön azonosítók alatt. Haladjon egyszerre egy route-on a kimenettől visszafelé ahhoz a helyi szolgáltatási objektumhoz, amely létrehozta, és a második RD megszűnik hibának látszani.
Kezdje annál a kimenetnél, amely összezavarta
Válasszon egy route-ot a teljes tábla helyett. Jegyezze fel a route típusát, az RD-t, az exportált route targeteket és a következő ugrást. Ez a négy mező elég annak megállapításához, melyik helyi objektum hirdette, és melyik távoli házirendnek kell importálnia.
NX-OS stílusú eszközön a részletes nézet ezzel érhető el: show bgp l2vpn evpn route-type 2 detail vagy show bgp l2vpn evpn route-type 5 detail. Junoson ugyanez az információ ebben található: show route table bgp.evpn.0 detail. Más szintaxis, ugyanazok a mezők.
Ne azzal kezdje, hogy minden megjelenített számot egyenlővé tesz. Az RD-k egyenlővé tétele az a változtatás, amely működő fabric esetén megtöri az import házirendet.
Adja meg minden azonosítónak a maga feladatát
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
A MAC-VRF az áthidaló szolgáltatás MAC-továbbítási információit tartja. Az IP-VRF IP-útválasztási kontextust biztosít egy útválasztott szolgáltatáshoz. Egy bérlő mindkettőt tartalmazhatja, ezért egy bérlő több RD-t is létrehozhat bármilyen konfigurációs hiba nélkül.
Az RFC 7432 a hirdető MAC-VRF RD-jét az EVPN NLRI-hez rendeli, és különböző RD-ket ír elő az ugyanazon a PE-n lévő MAC-VRF-ek között. A route-target eljárások különállóak: egy vagy több RT-attribútumot engednek meg, és a tagsághoz az import házirendre támaszkodnak. Nem az RD-egyenlőség hozza létre a közös tagságot, és ennek ilyen kezelése a zavar gyökere.
Haladjon egy route-on a hirdetéstől az importig
Kövesse a route-ot egy irányban. Erősítse meg a route típusát, a létrehozó szolgáltatást, az RD-t, az exportált RT-ket, majd a fogadó PE import házirendjét. Minden lépés más kérdésre válaszol, és bármely lépés hibája ugyanolyan hiányzó prefixnek látszik a túloldalon.
Amikor a route jelen van, vizsgálja meg a telepített továbbítási kontextust és a VNI-leképezést. A VNI egyezése mindkét végén azt mutatja, hogy az adatsík egyetért; nem azt mutatja, hogy a vezérlősík a szándékolt házirenddel importálta a route-ot.
Ha a route megjelenik a távoli PE-n, de nem folyik forgalom, a probléma túljutott az EVPN-en. Ellenőrizze a VNI–VLAN vagy VNI–VRF kötést és az underlay útvonalat, mielőtt újra szerkesztené a route targeteket. Kezdje a leképezéssel, aztán az underlay-jel, és csak utána a vezérlősíkkal. A route-target változtatás visszavonása egy adatsíki hiba üldözésére megbízható módja egy működő import elrontásának.
A 3. réteg prefixei továbbra is EVPN route-ok
Az EVPN-táblában lévő IP-prefix nem közönséges IPv4-unicast BGP. Az EVPN IP Prefix route saját route-típus, a MAC/IP és IP-prefix hirdetések pedig az EVPN címcsaládban utaznak, amelyet az RFC 7432 AFI 25-ként és SAFI 70-ként azonosít.
Ez a különbség akkor számít, amikor az EVPN-tábla egy route-ját a unicast tábla egy route-jával hasonlítja össze. Ugyanazt a célt írhatják le, és mégis különböző házirend hozhatja létre, szűri és importálja őket. Az egyiket a másikra vonatkozó bizonyítékként olvasni az, amitől egy helyes fabric migráció közben töröttnek látszik.
A számok összehasonlítása előtt ellenőrizze a gyártó levezetését
Az RFC 9136 IP Prefix route-okkal bővíti az EVPN-t, és meghatározza, hogy az alkalmazandó RD a MAC-VRF vagy az IP-VRF kontextusából származik-e. Ezért az L2-szolgáltatáscímkét és az útválasztott szolgáltatás címkéjét ugyanabban a kimenetben ahhoz az objektumhoz viszonyítva kell olvasni, amelyhez tartoznak, nem pedig bérlőnként egy RD-re redukálni.
Az RD és RT automatikus levezetése gyártóspecifikus. Olvassa el a telepített gyártó referenciáját az alkalmazott képlethez; az egyik kapcsolón látott automatikusan generált érték nem univerzális kódolás, és két gyártó számainak összehasonlítása ritkán bizonyít bármit.
Fejezze be írásos nyomvonallal arra a route-ra, amellyel kezdte: típus, létrehozó objektum, RD, exportált RT, import házirend, telepített VNI. Hat mező magyarázza el a hirdetést annak, aki legközelebb olvassa a ticketet, és egyik sem igényli, hogy a bérlő számai megegyezzenek.