PIM-SM oer in VPN: kontrolearje BSR, RP-mapping en RPF-rûtes

De tunnel is omheech, unicast-pings geane der trochhinne, en de ûntfanger lit noch altyd in swart skerm sjen. Yn in PIM-SM-ymplemintaasje betsjut dat symptoom hast altyd dat ien fan fjouwer kontrôlepaden brutsen is, en dat it gegevenspaad nea it probleem wie. Wurkje de list hjirûnder yn folchoarder ôf en stop by de earste stap dy't mislearret, want elke lettere stap hinget fan 'e foarige ôf. Ik hâld dizze fiif ûndersiken yn in kladbestân en plak se yn in terminal as der in multicast-klacht binnenkomt, wat foarkomt dat de diagnose yn giswurk feroaret.

Begjin by de ûntfanger, net by de tunnel

In ûntfanger dy't nea om de groep frege hat, produsearret gjin steat op hokker router dan ek, dus befêstigje dat de oansluting op it segmint oan 'e ûntfangerkant bestiet foardat jo eat oars ûndersykje. Op Cisco-achtige platfoarms printsje show ip igmp groups op 'e router fan 'e lêste hop de oansletten groepen njonken de interface dy't se heard hat. As de groep yn dy útjefte ûntbrekt, is de tunnel in ôflieding: it fersyk stoar by de tagongsswitch, by de socket fan 'e host of yn in VLAN sûnder querier.

Twa gewoane oarsaken ferklearje de measte ûntbrekkende oanslutingen dy't ik sjoen haw: in ferskil yn IGMP-ferzje tusken host en router, en in querier-ferkiezing dy't op in switch telâne kaam dy't net rûtelet. In tredde is subtiler: de groep is oansletten, mar op 'e ferkearde VLAN, om't de host twa netwurkkaarten hat en de applikaasje him oan 'e ferkearde bûn hat. IPv6-ûntfangers hawwe itselde probleem mei MLD, wêrby't show ipv6 mld groups deselde fraach beantwurdet. Net ien fan dizze wurdt reparearre troch de tunnel oan te reitsjen, en dêrom is de folchoarder sa wichtich.

Sadree't de oansluting sichtber is, befêstigje dat PIM ynskeakele is op sawol de interface oan 'e ûntfangerkant as de interface dy't nei it moetingspunt liedt. In router mei IGMP-lidmaatskip mar sûnder PIM op syn upstream-interface sil de groep yn in lokale tabel hâlde en nearne eat hinne stjoere.

Berikt de BSR-set de oare kant?

Bootstrap Router-berjochten bewege hop foar hop binnen ien PIM-domein, en dat is de rjochting dy't oer in tunnel brekt. Kandidaat-RP's stjoere har oankundigings fia unicast nei de keazen BSR, sadat it stik RP-nei-BSR normaal in wurkjende tunnel ûnferoare oerlibbet. De floed fan Bootstrap-berjochten yn 'e oare rjochting hinget derfan ôf dat elke tuskenlizzende interface PIM ynskeakele hat, en dat neat de berjochten by in grins stoppet. RFC 5059 definiearret dy fersprieding en de grinzen fan it bestjoerlik berik dy't it koartsje meie.

In ip pim bsr-border-útspraak, in ACL dy't protokol 103 filteret, of in beliedsbasearre IPsec-tunnel dy't multicast net drage kin, snije elk de floed ôf wylst unicast yntakt bliuwt. Krekt dy kombinaasje makket dat de flater op in RP-probleem liket wylst it eins in berikberensprobleem is, en dêrom lês ik de BSR-steat foardat ik de RP-konfiguraasje lês.

Op 'e router oan 'e oare kant neamt show ip pim bsr-router de keazen BSR en de oanlearde RP-set; as de útjefte leech is, sit de oare kant yn syn eigen domein en gjin inkele hoemannichte RP-konfiguraasje sil de beide ferienje. Fergelykje de groepsberikken en de RP-adressen yn show ip pim rp mapping oan beide kanten fan 'e tunnel. In mapping dy't allinnich lokaal bestiet, produsearret in dielde beam dy't op 'e ferkearde plak einiget, en de ûntfanger wachtet ivich.

Meitsje de RP-mapping oan beide kanten fan 'e tunnel gelyk

Statyske RP, BSR en anycast-RP binne trije manieren om deselde fraach te beantwurdzjen, en om se oer in tunnel te mingjen is in betroubere manier om in domein te bouwen dat nea konvergearret. As de holle ein BSR brûkt en de filiaal in statyske ip pim rp-address nei in oar adres, bout de filiaal syn dielde beam nei in RP dy't gjin idee hat dat de ûntfanger bestiet. De mapping moat oerienkomme op sawol it groepsberik as it adres, om't in spesifiker berik in breder ien ferslacht.

Anycast-RP bestiet krekt sadat twa sites ien RP-adres diele kinne, en it is hjir it neamen wurdich om't it feroaret wat «deselde RP» betsjut. Twa RP's dy't ien adres oankundigje binne neffens it ûntwerp konsistint; twa RP's dy't ferskate adressen foar itselde berik oankundigje binne dat net, hoe sûn elk site ek op himsels liket.

Foar boarne-spesifike multicast binnen 232.0.0.0/8 wurdt de RP nea rieplachte, dus in lege RP-mapping is net automatysk in flater. Beslis hokker tsjinstmodel de applikaasje brûkt foardat jo in RP efternei geane dy't nea nedich wie.

Lês de RPF-opfreage nei de boarne

PIM bout in beam troch it unicast-paad om te kearen, dus de kontrôle dy't ta docht is de rûte werom nei de boarne, of werom nei de RP foar in dielde beam. In oansluting dy't oankomt op in interface dy't de router net as upstream beskôget, wurdt weilitten, en de reden wurdt as in RPF-flater yn it lochboek set ynstee fan as in tunnelflater. Op in filiaalrouter mei in standertrûte oer de tunnel en in spesifikere rûte oer de WAN kin de RPF-interface maklik de WAN wêze, ek al is de boarne allinnich troch de tunnel te berikken. Dat is de iennichste meast foarkommende reden dat in oansluting stilwei weilitten wurdt.

show ip rpf 192.0.2.10 printsje de keazen interface, de folgjende hop en de rûte dy't it beslút makke hat, wat meastentiids genôch is om de ôfwiking te sjen. In statyske multicast-rûte lykas ip mroute 192.0.2.0 255.255.255.0 tunnel0 giet foarby de unicast-opfreage foar dat foarheaksel, en it is in legitime ferbettering as de multicast-topology echt ferskilt fan 'e unicast-topology. Behannelje it as konfiguraasje dy't dokumintearre wurde moat, net as in pleister dy't by in ynsidint oanbrocht en dêrnei fergetten wurdt.

Befêstigje de oansluting mei opdrachten, net mei in ping

Ping bewiist dat unicast wurket, wat jo al wisten. De befêstiging fan ein oant ein is in sekwinsje dy't de oansluting, de mapping, de buorman en de beam yn dy folchoarder sjen lit, en elk opdracht beantwurdet in oare fraach.

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

In folle (S,G)-yngong mei in echte ynkommende interface en in net-lege útgeande list betsjut dat it kontrôleflak syn wurk dien hat. In yngong wêrfan't de ynkommende interface Null lêst, of in teller mei it label RPF failed dy't oanhâldend klimt, wiist werom nei de foarige paragraaf ynstee fan nei de tunnel.

As alle fiif opdrachten goed lykje en de ûntfanger sjocht noch altyd neat, is de oerbleaune fertochte it eigen belied fan 'e tunnel: in krypto-ACL of firewall-regel dy't it unicast-rûtearringsprotokol tastean, mar net PIM, IGMP of it groepsferkear sels. Op in beliedsbasearre IPsec-tunnel wurdt multicast hielendal net droegen, dus it antwurd is in GRE- of VTI-ûntwerp ynstee fan wer in filterútsûndering. Skriuw op hokker fan 'e fiif ûndersiken mislearre foardat jo eat feroarje, en feroarje dan allinnich dy laach.