PIM-SM gegnum VPN: athuga BSR, RP-kortlagningu og RPF-slóðir
PIM-SM gegnum VPN bregst á þeirri stjórnleið sem vantar. Farðu í gegnum IGMP-aðild, BSR-umfang, RP-kortlagningu og RPF-nágranna í þeirri röð.
Göngin eru uppi, unicast-ping fara í gegnum þau, og móttakarinn sýnir samt svartan skjá. Í PIM-SM uppsetningu þýðir þetta einkenni næstum alltaf að ein af fjórum stjórnleiðum sé brotin, og gagnaleiðin hafi aldrei verið vandamálið. Farðu í gegnum listann hér fyrir neðan í röð og stöðvaðu við fyrsta skrefið sem bregst, því hvert síðara skref veltur á því fyrra. Ég geymi þessi fimm próf í drögskrá og lím þau inn í skjáhermi þegar kvörtun um multicast berst, sem kemur í veg fyrir að greiningin verði að getgátum.
Byrjaðu á móttakaranum, ekki göngunum
Móttakari sem bað aldrei um hópinn myndar ekkert ástand á neinum beini, svo staðfestu að liðtakan sé til staðar á þeim hluta sem snýr að móttakaranum áður en þú skoðar nokkuð annað. Á Cisco-líkum kerfum prentar show ip igmp groups á beini síðasta hoppsins hópana sem liðið er í við hlið þess viðmóts sem heyrði þá. Þegar hópurinn vantar í þessa útkomu er göngin truflun: beiðnin dó í aðgangsskiptinum, í sokk hýsilsins eða í VLAN án querier.
Tvær hversdagslegar orsakir útskýra flestar þær liðtökur sem vantaði og ég hef séð: misræmi í IGMP-útgáfu milli hýsils og beinis, og querier-kjör sem lentu á skipti sem beinir ekki. Sú þriðja er fíngerðari: hópurinn er liðinn en í röngu VLAN, því hýsillinn er með tvö netkort og forritið tengdist því ranga. IPv6-móttakarar hafa sömu vandamálin með MLD, þar sem show ipv6 mld groups svarar sömu spurningu. Ekkert þessara lagast við að snerta göngin, og þess vegna skiptir röðin máli.
Um leið og liðtakan er sýnileg skaltu staðfesta að PIM sé virkt bæði á viðmótinu sem snýr að móttakaranum og á viðmótinu sem liggur að fundarstaðnum. Beinir sem hefur IGMP-aðild en ekki PIM á uppstreymisviðmóti sínu heldur hópnum í staðbundinni töflu og sendir ekkert hvert sem er.
Nær BSR-settið yfir á hina hliðina?
Bootstrap Router-skilerð flytjast hopp fyrir hopp innan eins PIM-léns, og það er stefnan sem brotnar í gegnum göng. Frambjóðandi RP senda tilkynningar sínar til kjörins BSR með unicast, svo RP-til-BSR hlutinn stendur venjulega af sér vinnandi göng óbreyttur. Flóð Bootstrap-skila í hina stefnuna veltur á því að hvert milliviðmót hafi PIM virkt, og að ekkert stöðvi skilin við landamæri. RFC 5059 skilgreinir þá dreifingu og þau stjórnsýslumörk sem má stytta hana.
ip pim bsr-border fullyrðing, ACL sem síar prótókol 103, eða stefnumiðuð IPsec-göng sem geta ekki borið multicast, mun hvert um sig klippa flóðið á meðan unicast helst óskaddað. Einmitt sú samsetning gerir bilunina að RP-vandamáli í útliti þótt hún sé í raun aðgengisvandamál, og þess vegna les ég BSR-ástandið áður en ég les RP-stillinguna.
Á beini hinum megin við nefnir show ip pim bsr-router kjörinn BSR og lærða RP-mengið; ef útkoman er tóm situr hin hliðin í eigin léni og engin RP-stilling sameinar þau tvö. Berðu saman hópsviðin og RP-vistföngin í show ip pim rp mapping á báðum hliðum ganganna. Kortlagning sem er aðeins til staðbundin framleiðir sameiginlegt tré sem endar á röngu stað, og móttakarinn bíður að eilífu.
Láttu RP-kortlagninguna stemma á báðum hliðum ganganna
Staðbundið RP, BSR og anycast-RP eru þrjár leiðir til að svara sömu spurningu, og að blanda þeim í gegnum göng er áreiðanleg leið til að byggja lén sem nær aldrei samkvæmni. Ef höfuðendinn notar BSR og útibúið nota staðbundið ip pim rp-address sem bendir á annað vistfang, byggir útibúið sameiginlegt tré sitt að RP sem hefur ekki hugmynd um að móttakarinn sé til. Kortlagningin verður að stemma bæði á hópsviðinu og vistfanginu, þar sem nákvæmara svið vinnur á víðara.
Anycast-RP er til einmitt svo að tveir staðir geti deilt einu RP-vistfangi, og þess virði að nefna hér því það breytir því hvað „sama RP“ þýðir. Tveir RP sem tilkynna eitt vistfang eru samkvæmir að hönnun; tveir RP sem tilkynna mismunandi vistföng fyrir sama svið eru það ekki, sama hversu heilbrigður hver staður lítur út einn og sér.
Fyrir upptökusértækt multicast innan 232.0.0.0/8 er RP aldrei spurður, svo tóm RP-kortlagning er ekki sjálfkrafa bilun. Ákveddu hvaða þjónustulíkan forritið notar áður en þú eltir RP sem var aldrei þörf.
Lestu RPF-uppflettinguna í átt að upptökunni
PIM byggir tré með því að snúa unicast-leiðinni við, svo prófið sem skiptir máli er leiðin til baka að upptökunni, eða til baka að RP fyrir sameiginlegt tré. Liðtaka sem kemur á viðmót sem beinirinn telur ekki uppstreymis er hent, og ástæðan er skráð sem RPF-bilun frekar en göngabilun. Á útibúsbeinir með sjálfgefna leið gegnum göngin og nákvæmari leið gegnum WAN getur RPF-viðmótið auðveldlega verið WAN þótt upptökin séu aðeins aðgengileg gegnum göngin. Það er algengasta einstaka ástæðan fyrir því að liðtöku er hljóðlaust hent.
show ip rpf 192.0.2.10 prentar valið viðmót, næsta hopp og leiðina sem framleiddi ákvörðunina, sem venjulega nægir til að sjá misræmið. Staðbundin multicast-leið eins og ip mroute 192.0.2.0 255.255.255.0 tunnel0 gengur fram úr unicast-uppflettingunni fyrir það forskeyti, og það er lögmæt lagfæring þegar multicast-topologían er í raun frábrugðin unicast-topologíunni. Líttu á hana sem stillingu sem þarf að skjalfesta, ekki sem plástur sem settur er á meðan atburður stendur yfir og svo gleymdur.
Staðfestu liðtökuna með skipunum, ekki með pingi
Ping sannar að unicast virkar, sem þú vissir nú þegar. Staðfestingin frá enda til enda er runa sem sýnir liðtökuna, kortlagninguna, nágrannann og tréð í þeirri röð, og hver skipun svarar annarri spurningu.
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
Fyllt (S,G) færsla með raunverulegu inngangsviðmóti og ekki tómum útgangslista þýðir að stjórnplaninu er lokið. Færsla þar sem inngangsviðmótið er lesið sem Null, eða teljari merktur RPF failed sem heldur áfram að hækka, vísar til baka á fyrri hlutann en ekki á göngin.
Ef allar fimm skipanirnar líta rétt út og móttakarinn sér samt ekkert, er eftirlifandi grunsemdin stefna ganganna sjálfra: dulritunar-ACL eða eldveggjarregla sem leyfir unicast-beiningarprótókolið en ekki PIM, IGMP eða hópumferðina sjálfa. Á stefnumiðuðum IPsec-göngum er multicast alls ekki flutt, svo svarið er GRE- eða VTI-hönnun frekar en önnur síunarundantekning. Skrifaðu niður hvert fimm prófanna brást áður en þú breytir nokkru, og breyttu þá aðeins því lagi.