PIM-SM caur VPN: pārbaudīt BSR, RP kartējumu un RPF ceļus

Tunelis darbojas, unicast pingi tam iet cauri, un uztvērējs joprojām rāda melnu ekrānu. PIM-SM izvietojumā šis simptoms gandrīz vienmēr nozīmē, ka ir salauzts viens no četriem vadības ceļiem un ka datu ceļš nekad nav bijis problēma. Izstaigājiet zemāk esošo sarakstu pēc kārtas un apstājieties pie pirmā soļa, kas neizdodas, jo katrs nākamais solis ir atkarīgs no iepriekšējā. Es turu šīs piecas pārbaudes melnraksta failā un ielīmēju tās terminālī, kad pienāk multicast sūdzība, un tas neļauj diagnozei pārvērsties minējumos.

Sāciet ar uztvērēju, nevis tuneli

Uztvērējs, kas nekad nav pieprasījis grupu, nerada stāvokli nevienā maršrutētājā, tāpēc pirms jebko cita pārbaudes pārliecinieties, ka pievienošanās pastāv uztvērēja puses segmentā. Cisco tipa platformās pēdējā lēciena maršrutētājā show ip igmp groups izdrukā pievienotās grupas blakus saskarnei, kas tās dzirdēja. Ja grupā šajā izvadē nav, tunelis ir uzmanības novēršana: pieprasījums nomira piekļuves komutatorā, saimniekdatora ligzdā vai VLAN bez querier.

Divus ikdienišķus iemeslus izskaidro lielāko daļu manis redzēto trūkstošo pievienošanos: IGMP versijas neatbilstība starp saimniekdatoru un maršrutētāju, un querier vēlēšanas, kas nonākušas uz komutatora, kurš neveic maršrutēšanu. Trešais ir smalkāks: grupa ir pievienota, bet nepareizajā VLAN, jo saimniekdatoram ir divas tīkla kartes un lietojumprogramma piesaistījās nepareizajai. IPv6 uztvērējiem ir tā pati problēma ar MLD, kur show ipv6 mld groups atbild uz to pašu jautājumu. Nevienu no tiem neizlabo, pieskaroties tunelim, un tieši tāpēc secība ir svarīga.

Kad pievienošanās ir redzama, pārliecinieties, ka PIM ir iespējots gan uztvērēja puses saskarnē, gan saskarnē, kas ved uz satikšanās punktu. Maršrutētājs ar IGMP dalību, bet bez PIM savā augšupējā saskarnē, turēs grupu vietējā tabulā un nekur neko nesūtīs.

Vai BSR kopa sasniedz otru pusi?

Bootstrap Router ziņojumi pārvietojas lēciens pa lēcienam viena PIM domēna ietvaros, un tieši šis virziens lūzt caur tuneli. Kandidātu RP sūta savus paziņojumus ievēlētajam BSR ar unicast starpniecību, tāpēc RP–BSR posms parasti saglabājas nemainīgs strādājošā tunelī. Bootstrap ziņojumu plūsma pretējā virzienā ir atkarīga no tā, vai katrai starpsaskarņu iekārtai ir iespējots PIM, un no tā, vai nekas neaptur ziņojumus pie robežas. RFC 5059 definē šo izplatīšanu un administratīvās jomas robežas, kurām to ir atļauts saīsināt.

ip pim bsr-border paziņojums, ACL, kurš filtrē protokolu 103, vai uz politiku balstīts IPsec tunelis, kas nespēj pārnest multicast, katrs pārtrauks plūsmu, kamēr unicast paliks neskarts. Tieši šī kombinācija liek atteicei izskatīties kā RP problēmai, lai gan patiesībā tā ir sasniedzamības problēma, un tāpēc es lasu BSR stāvokli pirms RP konfigurācijas.

Tālās puses maršrutētājā show ip pim bsr-router nosauc ievēlēto BSR un apgūto RP kopu; ja izvade ir tukša, tālā puse atrodas savā domēnā un neviena RP konfigurācija abas nesamierinās. Salīdziniet grupu diapazonus un RP adreses show ip pim rp mapping izvadē abās tuneļa pusēs. Kartējums, kas pastāv tikai lokāli, rada kopīgu koku, kas beidzas nepareizajā vietā, un uztvērējs gaida mūžīgi.

Saskaņojiet RP kartējumu abās tuneļa pusēs

Statiskais RP, BSR un anycast-RP ir trīs veidi, kā atbildēt uz to pašu jautājumu, un to sajaukšana caur tuneli ir uzticams veids, kā izveidot domēnu, kas nekad nesaplūst. Ja galvenais gals izmanto BSR, bet filiāle izmanto statisku ip pim rp-address, kas norāda uz citu adresi, filiāle būvē savu kopīgo koku pret RP, kuram nav ne jausmas, ka uztvērējs eksistē. Kartējumam jāsakrīt gan grupu diapazonā, gan adresē, jo konkrētāks diapazons uzvar plašāku.

Anycast-RP pastāv tieši tāpēc, lai divas vietas varētu dalīt vienu RP adresi, un to ir vērts šeit nosaukt, jo tas maina to, ko nozīmē „tas pats RP”. Divi RP, kas paziņo vienu adresi, pēc konstrukcijas ir konsekventi; divi RP, kas paziņo dažādas adreses vienam un tam pašam diapazonam, nav, lai cik veselīga izskatītos katra vieta atsevišķi.

Avotam specifiskajam multicast diapazonā 232.0.0.0/8 RP nekad neprasa, tāpēc tukšs RP kartējums nav automātiski atteice. Izlemiet, kuru pakalpojuma modeli lietojumprogramma izmanto, pirms dzenāties pēc RP, kas nekad nebija vajadzīgs.

Izlasiet RPF meklējumu avota virzienā

PIM būvē koku, apgriežot unicast ceļu, tāpēc svarīgā pārbaude ir maršruts atpakaļ uz avotu vai atpakaļ uz RP kopīga koka gadījumā. Pievienošanās, kas pienāk saskarnē, kuru maršrutētājs neuzskata par augšupēju, tiek izmesta, un iemesls tiek reģistrēts kā RPF atteice, nevis kā tuneļa atteice. Filiāles maršrutētājā ar noklusējuma maršrutu pāri tunelim un konkrētāku maršrutu pāri WAN RPF saskarne var viegli būt WAN, lai gan avots ir sasniedzams tikai caur tuneli. Tas ir vienīgais visbiežāk sastopamais iemesls, kāpēc pievienošanās tiek klusi izmesta.

show ip rpf 192.0.2.10 izdrukā izvēlēto saskarni, nākamo lēcienu un maršrutu, kas radīja lēmumu, un ar to parasti pietiek, lai saskatītu neatbilstību. Statisks multicast maršruts, piemēram, ip mroute 192.0.2.0 255.255.255.0 tunnel0, ignorē unicast meklējumu šim prefiksam, un tā ir likumīga labojuma darbība, kad multicast topoloģija patiešām atšķiras no unicast topoloģijas. Uztveriet to kā konfigurāciju, kas jādokumentē, nevis kā plāksteri, kas uzlikts incidenta laikā un pēc tam aizmirsts.

Apstipriniet pievienošanos ar komandām, nevis ar ping

Ping pierāda, ka unicast darbojas, ko jūs jau zinājāt. Apstiprinājums no gala līdz galam ir secība, kas parāda pievienošanos, kartējumu, kaimiņu un koku tieši šādā secībā, un katra komanda atbild uz citu jautājumu.

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

Aizpildīts (S,G) ieraksts ar reālu ienākošo saskarni un ne tukšu izejošo sarakstu nozīmē, ka vadības plakne ir pabeigusi savu darbu. Ieraksts, kura ienākošā saskarne tiek lasīta kā Null, vai skaitītājs ar apzīmējumu RPF failed, kas turpina kāpt, norāda atpakaļ uz iepriekšējo sadaļu, nevis uz tuneli.

Ja visas piecas komandas izskatās pareizi un uztvērējs joprojām neko neredz, atlikušais aizdomās turamais ir paša tuneļa politika: kripto ACL vai ugunsmūra noteikums, kas atļauj unicast maršrutēšanas protokolu, bet ne PIM, IGMP vai pašu grupas datu plūsmu. Uz politiku balstītā IPsec tunelī multicast netiek pārnests vispār, tāpēc atbilde ir GRE vai VTI projekts, nevis vēl viens filtru izņēmums. Pierakstiet, kura no piecām pārbaudēm neizdevās, pirms kaut ko maināt, un pēc tam mainiet tikai to slāni.