PIM-SM über ein VPN: BSR, RP-Mapping und RPF-Pfade prüfen

Der Tunnel steht, Unicast-Pings laufen hindurch, und der Empfänger zeigt trotzdem einen schwarzen Bildschirm. In einem PIM-SM-Deployment bedeutet dieses Symptom fast immer, dass einer von vier Kontrollpfaden gebrochen ist und der Datenpfad nie das Problem war. Arbeiten Sie die folgende Liste der Reihe nach ab und halten Sie beim ersten Schritt an, der fehlschlägt, weil jeder spätere Schritt vom vorherigen abhängt. Ich halte diese fünf Prüfungen in einer Notizdatei und füge sie in ein Terminal ein, wenn eine Multicast-Beschwerde eingeht, was verhindert, dass die Diagnose zum Raten wird.

Beim Empfänger anfangen, nicht beim Tunnel

Ein Empfänger, der die Gruppe nie angefordert hat, erzeugt auf keinem Router Zustand; bestätigen Sie also, dass der Join im empfängerseitigen Segment existiert, bevor Sie irgendetwas anderes prüfen. Auf Cisco-artigen Plattformen gibt show ip igmp groups auf dem Router des letzten Hops die beigetretenen Gruppen neben dem Interface aus, das sie gehört hat. Fehlt die Gruppe in dieser Ausgabe, ist der Tunnel eine Ablenkung: Die Anfrage ist am Access-Switch, am Socket des Hosts oder in einem VLAN ohne Querier gestorben.

Zwei banale Ursachen erklären die meisten fehlenden Joins, die ich gesehen habe: eine IGMP-Versionsabweichung zwischen Host und Router und eine Querier-Wahl, die auf einem Switch landete, der nicht routet. Eine dritte ist subtiler: Die Gruppe ist beigetreten, aber im falschen VLAN, weil der Host zwei Netzwerkkarten hat und die Anwendung sich an die falsche gebunden hat. IPv6-Empfänger haben mit MLD das gleiche Problem, wobei show ipv6 mld groups dieselbe Frage beantwortet. Nichts davon wird durch Anfassen des Tunnels behoben, und genau deshalb ist die Reihenfolge wichtig.

Sobald der Join sichtbar ist, bestätigen Sie, dass PIM sowohl auf dem empfängerseitigen Interface als auch auf dem Interface in Richtung Rendezvous-Punkt aktiviert ist. Ein Router mit IGMP-Mitgliedschaft, aber ohne PIM auf seinem Upstream-Interface, hält die Gruppe in einer lokalen Tabelle und sendet nirgendwohin etwas.

Erreicht der BSR-Satz die Gegenseite?

Bootstrap-Router-Nachrichten wandern Hop für Hop innerhalb einer PIM-Domäne, und das ist die Richtung, die über einen Tunnel bricht. Kandidaten-RPs senden ihre Ankündigungen per Unicast an den gewählten BSR, sodass der RP-zu-BSR-Abschnitt einen funktionierenden Tunnel meist unverändert übersteht. Die Flut von Bootstrap-Nachrichten in die andere Richtung hängt davon ab, dass jedes Zwischeninterface PIM aktiviert hat und dass nichts die Nachrichten an einer Grenze stoppt. RFC 5059 definiert diese Verteilung und die administrativen Bereichsgrenzen, die sie verkürzen dürfen.

Eine ip pim bsr-border-Anweisung, eine ACL, die Protokoll 103 filtert, oder ein richtlinienbasierter IPsec-Tunnel, der Multicast nicht tragen kann, kappen jeweils die Flut, während Unicast intakt bleibt. Genau diese Kombination lässt den Fehler wie ein RP-Problem aussehen, obwohl er in Wahrheit ein Erreichbarkeitsproblem ist, und deshalb lese ich den BSR-Zustand, bevor ich die RP-Konfiguration lese.

Auf dem Router der Gegenseite nennt show ip pim bsr-router den gewählten BSR und den gelernten RP-Satz; ist die Ausgabe leer, sitzt die Gegenseite in ihrer eigenen Domäne, und keine Menge an RP-Konfiguration wird die beiden zusammenbringen. Vergleichen Sie die Gruppenbereiche und die RP-Adressen in show ip pim rp mapping auf beiden Seiten des Tunnels. Ein Mapping, das nur lokal existiert, erzeugt einen gemeinsamen Baum, der an der falschen Stelle endet, und der Empfänger wartet ewig.

RP-Mapping auf beiden Seiten des Tunnels angleichen

Statisches RP, BSR und Anycast-RP sind drei Arten, dieselbe Frage zu beantworten, und sie über einen Tunnel zu mischen ist ein zuverlässiger Weg, eine Domäne zu bauen, die nie konvergiert. Verwendet das Head-End BSR und die Filiale ein statisches ip pim rp-address, das auf eine andere Adresse zeigt, baut die Filiale ihren gemeinsamen Baum zu einem RP auf, der nicht weiß, dass der Empfänger existiert. Das Mapping muss sowohl beim Gruppenbereich als auch bei der Adresse übereinstimmen, da ein spezifischerer Bereich einen breiteren schlägt.

Anycast-RP existiert genau dafür, dass zwei Standorte eine RP-Adresse teilen können, und es lohnt sich, es hier zu nennen, weil es verändert, was „derselbe RP“ bedeutet. Zwei RPs, die eine Adresse ankündigen, sind konstruktionsbedingt konsistent; zwei RPs, die unterschiedliche Adressen für denselben Bereich ankündigen, sind es nicht, egal wie gesund jeder Standort für sich aussieht.

Für quellenspezifisches Multicast innerhalb von 232.0.0.0/8 wird der RP nie befragt, ein leeres RP-Mapping ist also nicht automatisch ein Fehler. Entscheiden Sie, welches Dienstmodell die Anwendung nutzt, bevor Sie einem RP nachjagen, der nie nötig war.

Den RPF-Lookup in Richtung Quelle lesen

PIM baut einen Baum, indem es den Unicast-Pfad umkehrt; die entscheidende Prüfung ist also die Route zurück zur Quelle oder zurück zum RP bei einem gemeinsamen Baum. Ein Join, der auf einem Interface ankommt, das der Router nicht als Upstream betrachtet, wird verworfen, und der Grund wird als RPF-Fehler statt als Tunnel-Fehler protokolliert. Auf einem Filialrouter mit einer Default-Route über den Tunnel und einer spezifischeren Route über das WAN kann das RPF-Interface leicht das WAN sein, obwohl die Quelle nur über den Tunnel erreichbar ist. Das ist der mit Abstand häufigste Grund, warum ein Join stillschweigend verworfen wird.

show ip rpf 192.0.2.10 gibt das gewählte Interface, den nächsten Hop und die Route aus, die die Entscheidung herbeigeführt hat, was meist genügt, um die Abweichung zu sehen. Eine statische Multicast-Route wie ip mroute 192.0.2.0 255.255.255.0 tunnel0 überschreibt den Unicast-Lookup für dieses Präfix, und sie ist eine legitime Korrektur, wenn die Multicast-Topologie tatsächlich von der Unicast-Topologie abweicht. Behandeln Sie sie als zu dokumentierende Konfiguration, nicht als einen während eines Vorfalls angewandten und dann vergessenen Patch.

Den Join mit Befehlen bestätigen, nicht mit einem Ping

Ping beweist, dass Unicast funktioniert, was Sie bereits wussten. Die End-to-End-Bestätigung ist eine Folge, die Join, Mapping, Nachbar und Baum in dieser Reihenfolge zeigt, und jeder Befehl beantwortet eine andere Frage.

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

Ein gefüllter (S,G)-Eintrag mit echtem eingehendem Interface und nicht leerer ausgehender Liste bedeutet, dass die Steuerungsebene ihre Arbeit erledigt hat. Ein Eintrag, dessen eingehendes Interface Null lautet, oder ein Zähler mit der Bezeichnung RPF failed, der weiter steigt, weist zurück auf den vorigen Abschnitt statt auf den Tunnel.

Wenn alle fünf Befehle richtig aussehen und der Empfänger trotzdem nichts sieht, ist der verbleibende Verdächtige die eigene Richtlinie des Tunnels: eine Krypto-ACL oder Firewall-Regel, die das Unicast-Routingprotokoll erlaubt, aber nicht PIM, IGMP oder den Gruppentraffic selbst. Auf einem richtlinienbasierten IPsec-Tunnel wird Multicast überhaupt nicht übertragen, die Antwort ist also ein GRE- oder VTI-Design statt einer weiteren Filterausnahme. Notieren Sie, welche der fünf Prüfungen fehlgeschlagen ist, bevor Sie etwas ändern, und ändern Sie dann nur diese Schicht.