PIM-SM oor ’n VPN: kontroleer BSR, RP-kartering en RPF-roetes

Die tonnel is op, unicast-pings steek dit oor, en die ontvanger wys steeds ’n swart skerm. In ’n PIM-SM-ontplooiing beteken daardie simptoom byna altyd dat een van vier kontrolepaaie stukkend is, en die datapad self was nooit die probleem nie. Werk die lys hieronder in volgorde deur en stop by die eerste stap wat misluk, want elke latere stap hang van die een voor dit af. Ek hou hierdie vyf ondersoeke in ’n konseplêer en plak dit in ’n terminaal wanneer ’n multicast-klag opduik, wat keer dat die diagnose in raaiwerk ontaard.

Begin by die ontvanger, nie by die tonnel nie

’n Ontvanger wat nooit om die groep gevra het nie, lewer geen toestand op enige router nie, so bevestig dat die aansluiting op die ontvangerkant-segment bestaan voordat jy enigiets anders ondersoek. Op Cisco-agtige platforms druk show ip igmp groups op die laaste-hop-router die aangeslote groepe langs die koppelvlak wat hulle gehoor het. Wanneer die groep uit daardie uitset ontbreek, is die tonnel ’n afleiding: die versoek het by die toegangskakelaar, by die gasheer-sok of in ’n VLAN sonder querier gesterf.

Twee alledaagse oorsake verklaar die meeste ontbrekende aansluitings wat ek gesien het: ’n IGMP-weergawe-verskil tussen gasheer en router, en ’n querier-verkiesing wat op ’n skakelaar beland het wat nie routeer nie. ’n Derde is subtieler, in dié sin dat die groep aangesluit is maar op die verkeerde VLAN, omdat die gasheer twee netwerkkaarte het en die toepassing aan die verkeerde een gebind het. IPv6-ontvangers het die ekwivalente probleem met MLD, waar show ipv6 mld groups dieselfde vraag beantwoord. Nie een van hierdie word reggemaak deur aan die tonnel te raak nie, en dit is juis waarom die volgorde saak maak.

Sodra die aansluiting sigbaar is, bevestig dat PIM op beide die ontvangerkoppelvlak en die koppelvlak wat na die rendezvous-punt lei, geaktiveer is. ’n Router met IGMP-lidmaatskap maar sonder PIM op sy opstroom-koppelvlak sal die groep in ’n plaaslike tabel hou en nêrens heen enigiets stuur nie.

Bereik die BSR-stel die oorkant?

Bootstrap Router-boodskappe beweeg hop vir hop binne ’n enkele PIM-domein, en dit is die rigting wat oor ’n tonnel breek. Kandidaat-RP’e stuur hul advertensies per unicast na die verkose BSR, so die RP-tot-BSR-been oorleef gewoonlik ’n werkende tonnel onveranderd. Die vloed van Bootstrap-boodskappe in die ander rigting hang daarvan af dat elke tussenliggende koppelvlak PIM geaktiveer het, en dat niks die boodskappe by ’n grens stop nie. RFC 5059 definieer daardie verspreiding en die administratiewe omvangsgrense wat dit mag kortknip.

’n ip pim bsr-border-stelling, ’n ACL wat protokol 103 filtreer, of ’n beleidsgebaseerde IPsec-tonnel wat nie multicast kan dra nie, sal elkeen die vloed knip terwyl unicast ongeskonde bly. Daardie kombinasie is wat die fout soos ’n RP-probleem laat lyk wanneer dit eintlik ’n bereikbaarheidsprobleem is, en dit is waarom ek die BSR-toestand lees voordat ek die RP-konfigurasie lees.

Op die oorkant-router noem show ip pim bsr-router die verkose BSR en die RP-stel wat hy geleer het; as die uitset leeg is, sit die oorkant in sy eie domein en geen hoeveelheid RP-konfigurasie sal die twee versoen nie. Vergelyk die groepsreekse en die RP-adresse in show ip pim rp mapping aan beide kante van die tonnel. ’n Kartering wat net plaaslik bestaan, produseer ’n gedeelde boom wat op die verkeerde plek eindig, en die ontvanger wag vir ewig.

Pas die RP-kartering aan beide kante van die tonnel

Statiese RP, BSR en anycast-RP is drie maniere om dieselfde vraag te antwoord, en om hulle oor ’n tonnel te meng is ’n betroubare manier om ’n domein te bou wat nooit konvergeer nie. As die hoofkant BSR gebruik en die tak ’n statiese ip pim rp-address na ’n ander adres gebruik, bou die tak sy gedeelde boom na ’n RP wat geen idee het die ontvanger bestaan nie. Die kartering moet oor die groepsreeks sowel as oor die adres ooreenkom, aangesien ’n meer spesifieke reeks oor ’n breër een wen.

Anycast-RP bestaan juis sodat twee terreine een RP-adres kan deel, en dit is die moeite werd om dit hier te noem omdat dit verander wat “dieselfde RP” beteken. Twee RP’e wat een adres adverteer, is ontwerpmatig konsekwent; twee RP’e wat verskillende adresse vir dieselfde reeks adverteer, is dit nie, maak nie saak hoe gesond elke terrein op sy eie lyk nie.

Vir bron-spesifieke multicast binne 232.0.0.0/8 word die RP nooit geraadpleeg nie, so ’n leë RP-kartering is nie outomaties ’n fout nie. Besluit watter diensmodel die toepassing gebruik voordat jy ’n RP jaag wat nooit nodig was nie.

Lees die RPF-soektog na die bron

PIM bou ’n boom deur die unicast-pad om te keer, so die kontrole wat saak maak is die roete terug na die bron, of terug na die RP vir ’n gedeelde boom. ’n Aansluiting wat op ’n koppelvlak aankom wat die router nie as opstroom beskou nie, word laat val, en die rede word as ’n RPF-mislukking eerder as ’n tonnelmislukking aangeteken. Op ’n takrouter met ’n verstekroete oor die tonnel en ’n meer spesifieke roete oor die WAN, kan die RPF-koppelvlak maklik die WAN wees selfs al is die bron net deur die tonnel bereikbaar. Dit is die enkele mees algemene rede waarom ’n aansluiting stilweg weggegooi word.

show ip rpf 192.0.2.10 druk die gekose koppelvlak, die volgende hop en die roete wat die besluit gelewer het, wat gewoonlik genoeg is om die wanverhouding te sien. ’n Statiese multicast-roete soos ip mroute 192.0.2.0 255.255.255.0 tunnel0 ignoreer die unicast-soektog vir daardie voorvoegsel, en dit is ’n geldige oplossing wanneer die multicast-topologie werklik van die unicast-topologie verskil. Behandel dit as konfigurasie wat gedokumenteer moet word, nie as ’n pleister wat tydens ’n voorval toegedien en dan vergeet word nie.

Bevestig die aansluiting met opdragte, nie met ’n ping nie

Ping bewys dat unicast werk, wat jy al geweet het. Die end-tot-end-bevestiging is ’n reeks wat die aansluiting, die kartering, die buur en die boom in daardie volgorde wys, en elke opdrag beantwoord ’n ander vraag.

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

’n Gevulde (S,G)-inskrywing met ’n werklike inkomende koppelvlak en ’n nie-lege uitgaande lys beteken die kontrolevlak het sy werk klaargemaak. ’n Inskrywing wie se inkomende koppelvlak Null lees, of ’n teller gemerk RPF failed wat aanhou klim, wys terug na die vorige afdeling eerder as na die tonnel.

As al vyf opdragte reg lyk en die ontvanger sien steeds niks, is die oorblywende verdagte die tonnel se eie beleid: ’n kripto-ACL of firewall-reël wat die unicast-roeteringprotokol toelaat maar nie PIM, IGMP of die groepverkeer self nie. Op ’n beleidsgebaseerde IPsec-tonnel word multicast glad nie gedra nie, so die antwoord is ’n GRE- of VTI-ontwerp eerder as nog ’n filter-uitsondering. Skryf neer watter van die vyf ondersoeke misluk het voordat jy enigiets verander, en verander dan net daardie laag.