PIM-SM VPN-en át: BSR, RP-leképezés és RPF-útvonalak ellenőrzése

Az alagút él, az unicast pingek átjárnak rajta, a vevő mégis fekete képernyőt mutat. PIM-SM telepítésben ez a tünet szinte mindig azt jelenti, hogy a négy vezérlőút valamelyike eltört, és az adatút soha nem volt a probléma. Járja végig az alábbi listát sorrendben, és álljon meg az első sikertelen lépésnél, mert minden későbbi lépés az előzőtől függ. Ezt az öt vizsgálatot egy piszkozatfájlban tartom, és beillesztem egy terminálba, amikor multicast-panasz érkezik, ami megakadályozza, hogy a diagnózis találgatássá váljon.

A vevővel kezdje, ne az alagúttal

Egy vevő, amely soha nem kérte a csoportot, egyetlen routeren sem hoz létre állapotot, ezért minden más vizsgálata előtt erősítse meg, hogy a csatlakozás létezik a vevő felőli szegmensen. A Cisco-szerű platformokon a show ip igmp groups az utolsó ugrás routerén a csatlakozott csoportokat a fogadó interfész mellett írja ki. Ha a csoport hiányzik ebből a kimenetből, az alagút elterelés: a kérés a hozzáférési kapcsolón, a gazdagép socketjén vagy egy querier nélküli VLAN-ban halt meg.

Két hétköznapi ok magyarázza a legtöbb hiányzó csatlakozást, amit láttam: az IGMP verziójának eltérése a gazdagép és a router között, valamint egy querier-választás, amely olyan kapcsolóra esett, amely nem irányít. A harmadik finomabb: a csoport csatlakozva van, de a rossz VLAN-ban, mert a gazdagépnek két hálózati kártyája van, és az alkalmazás a rosszhoz kötődött. Az IPv6-os vevőknél ugyanez a probléma az MLD-vel, ahol a show ipv6 mld groups ugyanarra a kérdésre válaszol. Ezek egyike sem javul az alagút érintésétől, és éppen ezért számít a sorrend.

Amint a csatlakozás látható, erősítse meg, hogy a PIM engedélyezve van a vevő felőli interfészen és a találkozási pont felé vezető interfészen is. Egy router, amelynek van IGMP-tagsága, de a felső interfészén nincs PIM, a csoportot helyi táblában tartja, és sehova nem küld semmit.

Eljut a BSR-készlet a túloldalra?

A Bootstrap Router üzenetek ugrásról ugrásra haladnak egyetlen PIM-tartományon belül, és ez az az irány, amely alagúton át eltörik. A jelölt RP-k az értesítéseiket unicasttal küldik a megválasztott BSR-nek, ezért az RP-BSR szakasz általában változatlanul túléli a működő alagutat. A Bootstrap üzenetek áradata a másik irányban attól függ, hogy minden köztes interfészen engedélyezve van-e a PIM, és hogy semmi nem állítja meg az üzeneteket egy határon. RFC 5059 határozza meg ezt a terjesztést és azokat az adminisztratív hatókörhatárokat, amelyeknek joga van lerövidíteni.

Egy ip pim bsr-border utasítás, egy 103-as protokollt szűrő ACL vagy egy szabályalapú IPsec-alagút, amely nem képes multicastot szállítani, mindegyik elvágja az áradatot, miközben az unicast sértetlen marad. Pontosan ez a kombináció teszi a hibát RP-problémává látszóvá, holott valójában elérhetőségi probléma, és ezért olvasom a BSR állapotát az RP-konfiguráció előtt.

A túloldali routeren a show ip pim bsr-router megnevezi a megválasztott BSR-t és a megtanult RP-készletet; ha a kimenet üres, a túloldal a saját tartományában ül, és semekkora RP-konfiguráció nem békíti össze a kettőt. Hasonlítsa össze a csoporttartományokat és az RP-címeket a show ip pim rp mapping kimenetében az alagút két oldalán. Egy csak helyben létező leképezés olyan megosztott fát hoz létre, amely rossz helyen ér véget, és a vevő örökké vár.

Egyeztesse az RP-leképezést az alagút két oldalán

A statikus RP, a BSR és az anycast-RP háromféle válasz ugyanarra a kérdésre, és ezeket alagúton át keverni megbízható módja egy soha nem konvergáló tartomány építésének. Ha a fejoldal BSR-t használ, az ág pedig egy másik címre mutató statikus ip pim rp-address-öt, az ág a megosztott fáját egy olyan RP felé építi, amelynek fogalma sincs a vevő létezéséről. A leképezésnek a csoporttartományban és a címben is egyeznie kell, mivel a pontosabb tartomány legyőzi a szélesebbet.

Az anycast-RP éppen azért létezik, hogy két hely megoszthasson egy RP-címet, és érdemes itt megnevezni, mert megváltoztatja, mit jelent az „ugyanaz az RP”. Két RP, amely egy címet hirdet, tervezés szerint konzisztens; két RP, amely ugyanahhoz a tartományhoz különböző címeket hirdet, nem az, akármilyen egészségesnek látszik is mindegyik hely önmagában.

A forrás-specifikus multicast esetében a 232.0.0.0/8 tartományon belül az RP-t soha nem kérdezik meg, ezért az üres RP-leképezés nem automatikusan hiba. Döntse el, melyik szolgáltatásmodellt használja az alkalmazás, mielőtt olyan RP után kutat, amelyre soha nem volt szükség.

Olvassa el az RPF-keresést a forrás felé

A PIM az unicast útvonal megfordításával épít fát, ezért a fontos ellenőrzés a forrás felé visszavezető útvonal, vagy megosztott fa esetén az RP felé visszavezető útvonal. Az a csatlakozás, amely olyan interfészen érkezik, amelyet a router nem tekint felsőnek, eldobódik, és az okot RPF-hibaként, nem alagúthibaként naplózza a rendszer. Egy ágrouteren, amelynek az alagúton át van alapértelmezett útvonala és a WAN felé egy pontosabb útvonala, az RPF-interfész könnyen a WAN lehet, pedig a forrás csak az alagúton át érhető el. Ez a legelterjedtebb egyetlen ok arra, hogy egy csatlakozás csendben eldobódik.

A show ip rpf 192.0.2.10 kiírja a választott interfészt, a következő ugrást és a döntést létrehozó útvonalat, ami általában elég az eltérés meglátásához. Egy statikus multicast-útvonal, mint a ip mroute 192.0.2.0 255.255.255.0 tunnel0, felülírja az unicast keresést arra az előtagra, és ez jogos javítás, amikor a multicast-topológia valóban eltér az unicast-topológiától. Kezelje dokumentálandó konfigurációként, ne egy incidens közben felvitt, majd elfelejtett foltként.

Parancsokkal erősítse meg a csatlakozást, ne pinggel

A ping bizonyítja, hogy az unicast működik, amit már tudott. A végpontok közötti megerősítés egy sorrend, amely ebben a sorrendben mutatja a csatlakozást, a leképezést, a szomszédot és a fát, és minden parancs más kérdésre válaszol.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Egy feltöltött (S,G) bejegyzés valódi beérkező interfésszel és nem üres kimenő listával azt jelenti, hogy a vezérlősík elvégezte a dolgát. Az a bejegyzés, amelynek beérkező interfésze Null-ként olvasható, vagy a RPF failed címkével ellátott számláló, amely folyamatosan nő, visszafelé mutat, az előző szakaszra, nem az alagútra.

Ha mind az öt parancs helyesnek tűnik, és a vevő mégsem lát semmit, a fennmaradó gyanúsított magának az alagútnak a házirendje: egy kripto-ACL vagy tűzfalszabály, amely engedélyezi az unicast útválasztási protokollt, de a PIM-et, az IGMP-t vagy magát a csoportforgalmat nem. Szabályalapú IPsec-alagúton a multicast egyáltalán nem szállítódik, tehát a válasz egy GRE- vagy VTI-terv, nem egy újabb szűrő-kivétel. Jegyezze fel, melyik öt vizsgálat hibázott, mielőtt bármit módosítana, majd csak azt a réteget módosítsa.