PIM-SM over een VPN: controleer BSR, RP-mapping en RPF-paden

De tunnel staat, unicast-pings gaan erdoorheen, en de ontvanger toont nog steeds een zwart scherm. In een PIM-SM-implementatie betekent dat symptoom bijna altijd dat een van de vier controlepaden kapot is en dat het datapad nooit het probleem was. Werk de lijst hieronder op volgorde af en stop bij de eerste stap die mislukt, want elke latere stap hangt van de vorige af. Ik bewaar deze vijf controles in een kladbestand en plak ze in een terminal wanneer er een multicast-klacht binnenkomt, waardoor de diagnose geen giswerk wordt.

Begin bij de ontvanger, niet bij de tunnel

Een ontvanger die de groep nooit heeft aangevraagd, maakt op geen enkele router toestand aan, dus bevestig dat de join op het segment aan de ontvangerzijde bestaat voordat je iets anders onderzoekt. Op Cisco-achtige platforms drukt show ip igmp groups op de router van de laatste hop de toegetreden groepen af naast de interface die ze hoorde. Als de groep in die uitvoer ontbreekt, is de tunnel een afleiding: het verzoek stierf op de access-switch, in de socket van de host of in een VLAN zonder querier.

Twee alledaagse oorzaken verklaren de meeste ontbrekende joins die ik heb gezien: een IGMP-versieverschil tussen host en router, en een querier-verkiezing die op een switch belandde die niet routeert. Een derde is subtieler: de groep is toegetreden maar op de verkeerde VLAN, omdat de host twee netwerkkaarten heeft en de toepassing aan de verkeerde is gebonden. IPv6-ontvangers hebben hetzelfde probleem met MLD, waar show ipv6 mld groups dezelfde vraag beantwoordt. Niets hiervan wordt opgelost door de tunnel aan te raken, en daarom is de volgorde juist belangrijk.

Zodra de join zichtbaar is, bevestig dat PIM is ingeschakeld op zowel de interface aan de ontvangerzijde als de interface die naar het ontmoetingspunt leidt. Een router met IGMP-lidmaatschap maar zonder PIM op zijn upstream-interface houdt de groep in een lokale tabel en stuurt nergens iets heen.

Bereikt de BSR-set de overkant?

Bootstrap Router-berichten bewegen hop voor hop binnen één PIM-domein, en dat is de richting die over een tunnel breekt. Kandidaat-RP's sturen hun aankondigingen via unicast naar de gekozen BSR, dus het stuk RP-naar-BSR overleeft een werkende tunnel meestal onveranderd. De vloed van Bootstrap-berichten in de andere richting hangt ervan af dat elke tussenliggende interface PIM heeft ingeschakeld, en dat niets de berichten bij een grens stopt. RFC 5059 definieert die distributie en de administratieve bereikgrenzen die haar mogen inkorten.

Een ip pim bsr-border-verklaring, een ACL die protocol 103 filtert, of een op beleid gebaseerde IPsec-tunnel die multicast niet kan dragen, snijdt elk de vloed af terwijl unicast intact blijft. Juist die combinatie laat de storing op een RP-probleem lijken terwijl het in werkelijkheid een bereikbaarheidsprobleem is, en daarom lees ik de BSR-status voordat ik de RP-configuratie lees.

Op de router aan de andere kant noemt show ip pim bsr-router de gekozen BSR en de geleerde RP-set; als de uitvoer leeg is, zit de andere kant in zijn eigen domein en geen enkele hoeveelheid RP-configuratie verzoent de twee. Vergelijk de groepsbereiken en de RP-adressen in show ip pim rp mapping aan beide zijden van de tunnel. Een mapping die alleen lokaal bestaat, levert een gedeelde boom op die op de verkeerde plek eindigt, en de ontvanger wacht voor altijd.

Laat de RP-mapping aan beide zijden van de tunnel kloppen

Statische RP, BSR en anycast-RP zijn drie manieren om dezelfde vraag te beantwoorden, en ze over een tunnel mengen is een betrouwbare manier om een domein te bouwen dat nooit convergeert. Als de head-end BSR gebruikt en de vestiging een statische ip pim rp-address naar een ander adres, bouwt de vestiging haar gedeelde boom naar een RP die niet weet dat de ontvanger bestaat. De mapping moet zowel op het groepsbereik als op het adres overeenkomen, omdat een specifieker bereik een breder bereik verslaat.

Anycast-RP bestaat juist opdat twee locaties één RP-adres kunnen delen, en het is de moeite waard het hier te noemen omdat het verandert wat „dezelfde RP” betekent. Twee RP's die één adres aankondigen zijn per ontwerp consistent; twee RP's die verschillende adressen voor hetzelfde bereik aankondigen niet, hoe gezond elke locatie op zichzelf ook lijkt.

Voor bronspecifieke multicast binnen 232.0.0.0/8 wordt de RP nooit geraadpleegd, dus een lege RP-mapping is niet automatisch een storing. Beslis welk servicemodel de toepassing gebruikt voordat je een RP achterna gaat die nooit nodig was.

Lees de RPF-lookup richting de bron

PIM bouwt een boom door het unicast-pad om te keren, dus de controle die ertoe doet is de route terug naar de bron, of terug naar de RP voor een gedeelde boom. Een join die binnenkomt op een interface die de router niet als upstream beschouwt, wordt weggegooid, en de reden wordt gelogd als een RPF-fout in plaats van als een tunnelfout. Op een vestigingsrouter met een standaardroute over de tunnel en een specifiekere route over de WAN kan de RPF-interface gemakkelijk de WAN zijn, ook al is de bron alleen via de tunnel bereikbaar. Dat is de meest voorkomende reden dat een join stil wordt weggegooid.

show ip rpf 192.0.2.10 toont de gekozen interface, de volgende hop en de route die de beslissing heeft veroorzaakt, wat meestal genoeg is om de mismatch te zien. Een statische multicast-route zoals ip mroute 192.0.2.0 255.255.255.0 tunnel0 negeert de unicast-lookup voor dat prefix, en het is een legitieme correctie wanneer de multicast-topologie echt verschilt van de unicast-topologie. Behandel het als configuratie die gedocumenteerd moet worden, niet als een pleister die tijdens een incident wordt aangebracht en daarna vergeten.

Bevestig de join met commando's, niet met een ping

Ping bewijst dat unicast werkt, wat je al wist. De end-to-end bevestiging is een reeks die de join, de mapping, de buur en de boom in die volgorde laat zien, en elk commando beantwoordt een andere 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

Een gevulde (S,G)-entry met een echte inkomende interface en een niet-lege uitgaande lijst betekent dat het controlevlak zijn werk heeft gedaan. Een entry waarvan de inkomende interface als Null wordt gelezen, of een teller met het label RPF failed die blijft stijgen, wijst terug naar de vorige sectie en niet naar de tunnel.

Als alle vijf commando's er goed uitzien en de ontvanger nog steeds niets ziet, is de resterende verdachte het eigen beleid van de tunnel: een crypto-ACL of firewallregel die het unicast-routingprotocol toestaat maar niet PIM, IGMP of het groepsverkeer zelf. Op een op beleid gebaseerde IPsec-tunnel wordt multicast helemaal niet gedragen, dus het antwoord is een GRE- of VTI-ontwerp en niet nog een filteruitzondering. Schrijf op welke van de vijf controles faalde voordat je iets verandert, en verander dan alleen die laag.