PIM-SM VPN:n yli: tarkista BSR, RP-kartoitus ja RPF-reitit

Tunneli on pystyssä, unicast-pingit kulkevat sen läpi, ja vastaanotin näyttää silti mustaa ruutua. PIM-SM-käyttöönotossa tämä oire tarkoittaa lähes aina, että yksi neljästä ohjauspolusta on rikki ja että datapolku ei koskaan ollut ongelma. Käy alla oleva luettelo järjestyksessä läpi ja pysähdy ensimmäiseen epäonnistuvaan vaiheeseen, koska jokainen myöhempi vaihe riippuu edellisestä. Pidän nämä viisi tarkistusta luonnositedostossa ja liitän ne päätteeseen, kun multicast-valitus saapuu, mikä estää diagnoosin muuttumisen arvailuksi.

Aloita vastaanottimesta, ei tunnelista

Vastaanotin, joka ei koskaan pyytänyt ryhmää, ei luo tilaa yhdellekään reitittimelle, joten varmista ennen muuta tarkistamista, että liittyminen on olemassa vastaanottimen puoleisessa segmentissä. Cisco-tyylisillä alustoilla show ip igmp groups viimeisen hypyn reitittimellä tulostaa liittyneet ryhmät sen liitännän viereen, joka ne kuuli. Kun ryhmä puuttuu tästä tulosteesta, tunneli on harhautus: pyyntö kuoli access-kytkimessä, isännän pistokkeessa tai VLANissa, jossa ei ole querieria.

Kaksi tavallista syytä selittää useimmat näkemäni puuttuvat liittymiset: IGMP-version epäjohdonmukaisuus isännän ja reitittimen välillä sekä querier-vaali, joka päätyi kytkimeen, joka ei reititä. Kolmas on hienovaraisempi: ryhmään on liitytty, mutta väärässä VLANissa, koska isännällä on kaksi verkkokorttia ja sovellus sitoutui väärään. IPv6-vastaanottimilla on vastaava ongelma MLD:n kanssa, jossa show ipv6 mld groups vastaa samaan kysymykseen. Mikään näistä ei korjaannu tunnelia koskettamalla, ja juuri siksi järjestyksellä on väliä.

Kun liittyminen on näkyvissä, varmista, että PIM on käytössä sekä vastaanottimen puoleisella liitännällä että kohtaamispisteeseen johtavalla liitännällä. Reititin, jolla on IGMP-jäsenyys mutta ei PIM:iä ylävirran liitännällä, pitää ryhmän paikallisessa taulussa eikä lähetä mitään minnekään.

Saavuttaako BSR-joukko toiselle puolelle?

Bootstrap Router -viestit liikkuvat hyppy hypyltä yhden PIM-toimialueen sisällä, ja juuri se suunta katkeaa tunnelin yli. Ehdokas-RP:t lähettävät ilmoituksensa valitulle BSR:lle unicastina, joten RP:stä BSR:ään ulottuva osuus säilyy toimivassa tunnelissa yleensä muuttumattomana. Bootstrap-viestien tulva toiseen suuntaan riippuu siitä, että jokaisella väliliitännällä on PIM käytössä, ja siitä, ettei mikään pysäytä viestejä rajalla. RFC 5059 määrittelee tämän jakelun ja hallinnollisen laajuuden rajat, joilla se on sallittua katkaista.

ip pim bsr-border-lause, protokollan 103 suodattava ACL tai käytäntöpohjainen IPsec-tunneli, joka ei pysty kuljettamaan multicastia, katkaisevat kukin tulvan jättäen unicastin ehjäksi. Juuri tämä yhdistelmä saa vian näyttämään RP-ongelmalta, vaikka se on todellisuudessa tavoitettavuusongelma, ja siksi luen BSR-tilan ennen RP-konfiguraatiota.

Kauemman puolen reitittimellä show ip pim bsr-router nimeää valitun BSR:n ja opitun RP-joukon; jos tuloste on tyhjä, kauempi puoli istuu omalla toimialueellaan eikä mikään määrä RP-konfiguraatiota sovita niitä kahta. Vertaa ryhmäalueita ja RP-osoitteita show ip pim rp mapping-tulosteessa tunnelin molemmilla puolilla. Kartoitus, joka on olemassa vain paikallisesti, tuottaa jaetun puun, joka päättyy väärään paikkaan, ja vastaanotin odottaa ikuisesti.

Sovita RP-kartoitus tunnelin molemmilla puolilla

Staattinen RP, BSR ja anycast-RP ovat kolme tapaa vastata samaan kysymykseen, ja niiden sekoittaminen tunnelin yli on luotettava tapa rakentaa toimialue, joka ei koskaan konvergoidu. Jos päässä käytetään BSR:ää ja haarassa staattista ip pim rp-address-komentoa, joka osoittaa toiseen osoitteeseen, haara rakentaa jaetun puunsa RP:tä kohti, jolla ei ole aavistustakaan vastaanottimen olemassaolosta. Kartoituksen on täsmättävä sekä ryhmäalueen että osoitteen osalta, koska tarkempi alue voittaa laajemman.

Anycast-RP on olemassa juuri siksi, että kaksi toimipaikkaa voi jakaa yhden RP-osoitteen, ja se kannattaa mainita tässä, koska se muuttaa sitä, mitä „sama RP“ tarkoittaa. Kaksi RP:tä, jotka ilmoittavat yhden osoitteen, ovat johdonmukaisia suunnittelultaan; kaksi RP:tä, jotka ilmoittavat eri osoitteet samalle alueelle, eivät ole, vaikka kukin toimipaikka näyttäisi kuinka terveeltä tahansa yksinään.

Lähdekohtaiselle multicastille alueen 232.0.0.0/8 sisällä RP:ltä ei koskaan kysytä, joten tyhjä RP-kartoitus ei ole automaattisesti vika. Päätä, mitä palvelumallia sovellus käyttää, ennen kuin jahtaat RP:tä, jota ei koskaan tarvittu.

Lue RPF-haku kohti lähdettä

PIM rakentaa puun kääntämällä unicast-polkua, joten ratkaiseva tarkistus on reitti takaisin lähteelle tai jaetun puun tapauksessa takaisin RP:lle. Liittyminen, joka saapuu liitännälle, jota reititin ei pidä ylävirran liitäntänä, pudotetaan, ja syy kirjataan RPF-vian eikä tunnelivian merkiksi. Haarareitittimellä, jolla on oletusreitti tunnelin yli ja tarkempi reitti WANin yli, RPF-liitäntä voi helposti olla WAN, vaikka lähde on tavoitettavissa vain tunnelin kautta. Tämä on yleisin yksittäinen syy siihen, että liittyminen hylätään hiljaisesti.

show ip rpf 192.0.2.10 tulostaa valitun liitännän, seuraavan hypyn ja päätöksen tuottaneen reitin, ja se riittää yleensä eroavuuden näkemiseen. Staattinen multicast-reitti, kuten ip mroute 192.0.2.0 255.255.255.0 tunnel0, ohittaa kyseisen etuliitteen unicast-haun, ja se on laillinen korjaus, kun multicast-topologia todella eroaa unicast-topologiasta. Kohtele sitä dokumentoitavana konfiguraationa, älä häiriön aikana asennettuna ja sittemmin unohdettuna paikkana.

Vahvista liittyminen komennoilla, ei pingillä

Ping todistaa, että unicast toimii, minkä tiesit jo. Päästä päähän -vahvistus on sarja, joka näyttää liittymisen, kartoituksen, naapurin ja puun tässä järjestyksessä, ja jokainen komento vastaa eri kysymykseen.

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

Täytetty (S,G)-merkintä, jolla on todellinen saapuva liitäntä ja ei-tyhjä lähtevien luettelo, tarkoittaa, että ohjaustaso on hoitanut tehtävänsä. Merkintä, jonka saapuva liitäntä luetaan Null, tai laskuri, joka on merkitty RPF failed ja kasvaa edelleen, osoittaa takaisin edelliseen jaksoon eikä tunneliin.

Jos kaikki viisi komentoa näyttävät oikeilta eikä vastaanotin silti näe mitään, jäljellä oleva epäilty on tunnelin oma käytäntö: salaus-ACL tai palomuurisääntö, joka sallii unicast-reititysprotokollan mutta ei PIM:iä, IGMP:tä tai itse ryhmäliikennettä. Käytäntöpohjaisessa IPsec-tunnelissa multicastia ei kuljeteta lainkaan, joten vastaus on GRE- tai VTI-ratkaisu eikä jälleen yksi suodatinpoikkeus. Kirjoita muistiin, mikä viidestä tarkistuksesta epäonnistui, ennen kuin muutat mitään, ja muuta sitten vain se kerros.