PIM-SM iwwer eng VPN: BSR, RP-Mapping an RPF-Weeër kontrolléieren
PIM-SM iwwer eng VPN feelt um Kontrollwee, dee feelt. Gitt d’IGMP-Memberschaft, de BSR-Beräich, d’RP-Mapping an d’RPF-Nopere an där Reihenfolg duerch.
Den Tunnel steet, Unicast-Pinge ginn duerch, an den Empfänger weist nach ëmmer e schwaarze Bildschierm. An enger PIM-SM-Installatioun heescht dat Symptom bal ëmmer, datt ee vun véier Kontrollweeër futti ass, an datt den Datenwee ni de Problem war. Gitt d’Lëscht hei drënner an der Rei duerch a stoppt beim éischte Schrëtt, dee feelt, well all weidere Schrëtt vum virege ofhänkt. Ech halen dës fënnef Kontrollen an enger Entwurfsdatei a pechen se an en Terminal, wann eng Multicast-Beschwäer kënnt, wat verhënnert, datt d’Diagnos zu Rotschléi gëtt.
Fänkt beim Empfänger un, net beim Tunnel
En Empfänger, deen d’Grupp ni gefrot huet, erzeegt op kengem Router en Zoustand, also bestätegt, datt de Bäitrëtt um Empfängersäit-Segment existéiert, ier Dir eppes anescht iwwerpréift. Op Cisco-änleche Plattforme dréckt show ip igmp groups um Router vum leschte Sprong déi bäigetruede Gruppe niewent deem Interface, dee se gehéiert huet. Wa d’Grupp an deem Output feelt, ass den Tunnel eng Ofleedung: d’Ufro ass um Access-Switch, um Socket vum Host oder an engem VLAN ouni Querier gestuerwen.
Zwee alldeeglech Ursaachen erklären déi meescht fehlend Bäitrëtt, déi ech gesinn hunn: eng Ongläichheet vun der IGMP-Versioun tëschent Host a Router, an eng Querier-Wiel, déi op engem Switch gelant ass, dee net routet. Déi drëtt ass méi subtil: d’Grupp ass bäigetrueden, awer am falsche VLAN, well den Host zwee Netzwierkkarten huet an d’Applikatioun sech un déi falsch gebonnen huet. IPv6-Empfänger hunn dat selwecht Problem mam MLD, wou show ipv6 mld groups déiselwecht Fro beäntwert. Keng dovun gëtt duerch Upacken vum Tunnel behuewen, an genau dofir ass d’Reihenfolg wichteg.
Soubal de Bäitrëtt sichtbar ass, bestätegt, datt PIM souwuel um Empfängersäit-Interface wéi och um Interface Richtung Treffpunkt aktivéiert ass. E Router mat IGMP-Memberschaft, awer ouni PIM op sengem Upstream-Interface, hält d’Grupp an enger lokaler Tabell a schéckt néierens eppes hin.
Erreecht de BSR-Saz déi aner Säit?
Bootstrap Router-Noriichte beweege sech Sprong fir Sprong bannent engem eenzegen PIM-Domän, an dat ass déi Richtung, déi iwwer en Tunnel bricht. Kandidat-RPe schécken hir Ukënnegungen iwwer Unicast un de gewielte BSR, dofir iwwersteet de RP-zu-BSR-Deel meeschtens en funktionéierenden Tunnel onverännert. D’Flut vu Bootstrap-Noriichten an déi aner Richtung hänkt dovun of, datt all Tëscheinterface PIM aktivéiert huet, an datt näischt d’Noriichten un enger Grenz stoppt. RFC 5059 definéiert déi Verdeelung an déi administrativ Beräichsgrenzen, déi se dierfen ofkierzen.
Eng ip pim bsr-border-Ausso, eng ACL déi Protokoll 103 filtert, oder en richtlinnbaséierten IPsec-Tunnel, deen Multicast net droe kann, schneiden all d’Flut of, wärend Unicast intakt bleift. Genee déi Kombinatioun mécht, datt de Feeler wéi en RP-Problem ausgesäit, wou et tatsächlech en Erreechbarkeetsproblem ass, an dofir liesen ech den BSR-Zoustand ier ech d’RP-Konfiguratioun liesen.
Um Router op der anerer Säit nennt show ip pim bsr-router de gewielte BSR an de geléierte RP-Saz; ass den Output eidel, sëtzt déi aner Säit an hirem eegenen Domän, an et wäert keng Quantitéit RP-Konfiguratioun déi zwee versöhnen. Vergläicht d’Gruppberäicher an d’RP-Adressen an show ip pim rp mapping op béide Säite vum Tunnel. Eng Mapping, déi nëmme lokal existéiert, produzéiert en gedeelte Bam, deen um falsche Punkt ophält, an den Empfänger waart fir ëmmer.
Passt d’RP-Mapping op béide Säite vum Tunnel un
Statische RP, BSR an anycast-RP sinn dräi Weeër, déiselwecht Fro ze beäntwerten, an se iwwer en Tunnel ze mëschen ass e séchere Wee, en Domän ze bauen, deen ni konvergéiert. Wann den Haaptende BSR benotzt an d’Filial e statischen ip pim rp-address deen op eng aner Adress weist, baut d’Filial hire gedeelte Bam zu engem RP, dee keng Ahnung huet, datt den Empfänger existéiert. D’Mapping muss souwuel am Gruppberäich wéi och an der Adress iwwerenee stëmmen, well e méi spezifesche Beräich e méi breede schléit.
Anycast-RP existéiert just dofir, datt zwee Site sech eng RP-Adress deele kënnen, an et ass wäert, en hei ze nennen, well en ännert, wat «dee selwechten RP» heescht. Zwee RPen, déi eng Adress ukënnegen, si vum Design hir konsequent; zwee RPen, déi verschidde Adressen fir dee selwechte Beräich ukënnegen, sinn et net, egal wéi gesond all Site fir sech ausgesäit.
Fir quellenspezifesche Multicast bannent 232.0.0.0/8 gëtt den RP ni gefrot, sou datt eng eidel RP-Mapping net automatesch e Feeler ass. Entscheet, wéi en Déngschtmodell d’Applikatioun benotzt, ier Dir engem RP nogeet, deen ni néideg war.
Liest de RPF-Lookup Richtung Quell
PIM baut e Bam andeems en den Unicast-Wee ëmdréit, dofir ass d’Kontroll déi zielt de Wee zréck zur Quell, oder zréck zum RP fir en gedeelte Bam. En Bäitrëtt, deen op engem Interface ukommt, deen de Router net als Upstream considéréiert, gëtt verworf, an de Grond gëtt als RPF-Feeler amplaz als Tunnel-Feeler protokolléiert. Op engem Filialrouter mat enger Standardroute iwwer den Tunnel an enger méi spezifescher Route iwwer d’WAN kann d’RPF-Interface liicht d’WAN sinn, obwuel d’Quell nëmmen duerch den Tunnel erreechbar ass. Dat ass deen eenzele meescht verbreete Grond, firwat en Bäitrëtt stëll verworfen gëtt.
show ip rpf 192.0.2.10 dréckt dat gewielten Interface, den nächste Sprong an de Wee, deen d’Entscheedung produzéiert huet, wat meeschtens duergeet, fir d’Ongläichheet ze gesinn. Eng statesch Multicast-Route wéi ip mroute 192.0.2.0 255.255.255.0 tunnel0 iwwerhëlt de Unicast-Lookup fir dee Prefix, an et ass eng legitim Korrektur, wann d’Multicast-Topologie wierklech vun der Unicast-Topologie ofwäicht. Behandelt se als Konfiguratioun déi dokumentéiert muss ginn, net als Flick deen während engem Tëschefall ugebruecht an duerno vergiess gëtt.
Bestätegt de Bäitrëtt mat Kommandoen, net mat engem Ping
Ping beweist, datt Unicast funktionéiert, wat Dir schonn wosst. D’Bestätegung vum Enn bis zum Enn ass eng Sequenz, déi de Bäitrëtt, d’Mapping, den Noper an de Bam an där Reihenfolg weist, an all Kommando beäntwert eng aner Fro.
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
En ausgefëllten (S,G)-Andro mat engem richtegen Ageschnidd an enger net eideler Ausgangslëscht heescht, datt d’Kontrollfläch hir Aarbecht fäerdeg huet. En Andro, deem säin Ageschnidd Null liest, oder en Zähler mat der Etikett RPF failed, deen weider klëmmt, weist zréck op de virege Sektioun an net op den Tunnel.
Wann all fënnef Kommandos richteg ausgesinn an den Empfänger nach ëmmer näischt gesäit, ass de verbleiwenen Verdächtegen d’Politik vum Tunnel selwer: eng Krypto-ACL oder eng Firewall-Reeg déi den Unicast-Routingprotokoll erlaabt, awer net PIM, IGMP oder de Grupptraffic selwer. Op engem richtlinnbaséierten IPsec-Tunnel gëtt Multicast guer net gedroen, dofir ass d’Äntwert en GRE- oder VTI-Design anstatt nach eng Filterausnam. Schreift op, wéi eng vun de fënnef Kontrollen gefeelt huet, ier Dir eppes ännert, an ännert dann nëmmen déi Schicht.