VPN аркылуу PIM-SM: BSR, RP картасы жана RPF жолдорун текшерүү

Туннель иштеп жатат, unicast ping-дер андан өтөт, бирок кабыл алуучу дагы эле кара экранды көрсөтүп турат. PIM-SM жайгаштыруусунда бул белги дээрлик ар дайым төрт башкаруу жолунун бири бузулганын жана маалымат жолу эч качан маселе болбогонун билдирет. Төмөнкү тизмени тартиби менен карап чыгып, ишке ашпаган биринчи кадамда токтогула, анткени ар бир кийинки кадам мурункусуна көз каранды. Мен бул беш текшерүүнү долбоор файлында сактап, multicast тууралуу даттануу келгенде терминалга чаптаймын, бул диагностиканын божомолго айланышына жол бербейт.

Туннелден эмес, кабыл алуучудан баштаңыз

Топту эч качан сурабаган кабыл алуучу эч бир маршрутизатордо абал түзбөйт, ошондуктан башка нерсени текшерүүдөн мурун кошулуу кабыл алуучуга караган сегментте бар экенин тастыктаңыз. Cisco сыяктуу платформаларда акыркы секирүү маршрутизаторунда show ip igmp groups кошулган топторду аларды уккан интерфейстин жанында басып чыгарат. Ошол чыгарылышта топ жок болсо, туннель көңүлдү бурмалайт: суроо кирүү коммутаторунда, хосттун сокетинде же querier жок VLAN ичинде өлдү.

Мен көргөн жоголгон кошулуулардын көбүн эки жөнөкөй себеп түшүндүрөт: хост менен маршрутизатордун ортосундагы IGMP версиясынын дал келбестиги жана маршруттоо кылбаган коммутаторго түшкөн querier тандоосу. Үчүнчүсү назикрээк: топко кошулган, бирок туура эмес VLAN-да, анткени хостто эки тармак картасы бар жана колдонмо туура эмес картага байланган. IPv6 кабыл алуучуларында MLD менен ушундай эле маселе бар, ал жерде show ipv6 mld groups ошол эле суроого жооп берет. Булардын эч бири туннелге тийүү менен оңдолбойт жана дал ошондуктан тартип маанилүү.

Кошулуу көрүнгөндөн кийин, PIM кабыл алуучуга караган интерфейсте да, жолугушуу чекитине бараткан интерфейсте да күйгүзүлгөнүн тастыктаңыз. IGMP мүчөлүгү бар, бирок жогорку интерфейсинде PIM жок маршрутизатор топту жергиликтүү таблицада кармап, эч жакка эч нерсе жибербейт.

BSR топтому ары жакка жетеби?

Bootstrap Router билдирүүлөрү бир PIM доменинин ичинде секирүүдөн секирүүгө жылат жана туннелден өткөндө сынган багыт дал ошол. Кандидат RP-лар өз жарнамаларын шайланган BSR-га unicast аркылуу жиберишет, ошондуктан RPден BSRга чейинки бөлүк иштеп жаткан туннелде адатта өзгөрүүсүз калат. Каршы багыттагы Bootstrap билдирүүлөрүнүн агымы ар бир аралык интерфейсте PIM күйгүзүлгөнүнө жана эч нерсе билдирүүлөрдү чек арада токтотпошуна көз каранды. RFC 5059 ушул бөлүштүрүүнү жана аны кыскартууга уруксат берилген административдик аймактын чектерин аныктайт.

ip pim bsr-border билдирүүсү, 103 протоколун фильтрлеген ACL же multicast ташый албаган саясатка негизделген IPsec туннели — ар бири агымды кесип, unicast бүтүн бойдон калат. Дал ушул айкалыш бузулушту RP маселесине окшоштурат, чындыгында бул жеткиликтүүлүк маселеси, ошондуктан мен RP конфигурациясын окуудан мурун BSR абалын окуйм.

Ары жактагы маршрутизатордо show ip pim bsr-router шайланган BSRды жана үйрөнгөн RP топтомун атайт; чыгарылыш бош болсо, ары жак өз доменинде отурат жана эч бир RP конфигурациясы экөөнү келиштире албайт. Туннелдин эки жагында show ip pim rp mapping чыгарылышындагы топ диапазондорун жана RP даректерин салыштырыңыз. Тек жергиликтүү жерде бар карталоо туура эмес жерде бүткөн жалпы даракты жаратат, ал эми кабыл алуучу түбөлүк күтөт.

RP картасын туннелдин эки жагында дал келтириңиз

Статикалык RP, BSR жана anycast-RP — бир суроого үч жооп, аларды туннел аркылуу аралаштыруу эч качан жакындашпаган домен куруунун ишенимдүү жолу. Эгер баш жагы BSR колдонсо, ал эми тармак башка дарекке көрсөткөн статикалык ip pim rp-address колдонсо, тармак өзүнүн жалпы дарагын кабыл алуучунун бар экенин билбеген RP тарапка курат. Карталоо топ диапазонунда да, даректе да дал келиши керек, анткени так диапазон кененирээктен жеңет.

Anycast-RP эки сайт бир RP дарегин бөлүшү үчүн так бар жана аны бул жерде атоо жарайт, анткени ал «ошол эле RP» дегендин маанисин өзгөртөт. Бир даректи жарыялаган эки RP дизайн боюнча ырааттуу; бир диапазон үчүн ар башка даректерди жарыялаган эки RP андай эмес, ар бир сайт өзүнчө канчалык соо көрүнсө да.

232.0.0.0/8 ичиндеги булакка таандык multicast үчүн RPга эч качан кайрылышпайт, ошондуктан бош RP картасы автоматтык түрдө бузулуш эмес. Эч качан керек болбогон RPнын артынан түшүүдөн мурун колдонмо кайсы кызмат моделин колдонорун чечиңиз.

RPF издөөсүн булакка карай окуңуз

PIM даракты unicast жолун тескери буруу менен курат, ошондуктан маанилүү текшерүү — булакка кайра кетүүчү маршрут, же жалпы дарак үчүн RPга кайра кетүүчү жол. Маршрутизатор жогорку деп эсептебеген интерфейске келген кошулуу ташталат жана себеби туннелдин бузулушу катары эмес, RPFдин ишке ашпастыгы катары жазылат. Туннел аркылуу демейки маршруту жана WAN аркылуу такыраак маршруту бар тармак маршрутизаторунда RPF интерфейси оңой эле WAN болушу мүмкүн, булакка туннель аркылуу гана жетүү мүмкүн болсо да. Бул кошулуунун унчукпай ташталышынын эң кеңири тараган жалгыз себеби.

show ip rpf 192.0.2.10 тандалган интерфейсти, кийинки секирүүнү жана чечимди жараткан маршрутту басып чыгарат, бул адатта дал келбестикти көрүүгө жетет. ip mroute 192.0.2.0 255.255.255.0 tunnel0 сыяктуу статикалык multicast маршруту ошол префикс үчүн unicast издөөсүн айланып өтөт жана multicast топологиясы unicast топологиясынан чындап айырмаланганда бул мыйзамдуу оңдоо. Аны документтештирилиши керек конфигурация катары караңыз, окуя учурунда колдонулган жана кийин унутулган жамаачы катары эмес.

Кошулууну ping менен эмес, буйруктар менен тастыктаңыз

Ping unicast иштешин далилдейт, муну сиз мурун эле билчүсүз. Учтан учка чейинки тастыктоо — кошулууну, карталоону, кошунаны жана даракты ушундай тартипте көрсөткөн ырааттуулук, ал эми ар бир буйрук башка суроого жооп берет.

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

Чыныгы кирүүчү интерфейси жана бош эмес чыгуучу тизмеси бар толтурулган (S,G) жазуусу башкаруу тегиздиги ишин бүткөргөнүн билдирет. Кирүүчү интерфейси Null деп окулган жазуу же RPF failed белгиси бар, тынымсыз өсүп жаткан эсептегич — туннелге эмес, мурунку бөлүмгө шилтейт.

Эгер беш буйруктун баары туура көрүнүп, кабыл алуучу дагы эле эч нерсе көрбөсө, калган шектүү — туннелдин өз саясаты: unicast маршруттоо протоколуна уруксат берип, PIM, IGMP же топ трафигинин өзүнө уруксат бербеген крипто ACL же firewall эрежеси. Саясатка негизделген IPsec туннелинде multicast такыр ташылбайт, ошондуктан жооп — фильтрдин дагы бир өзгөчөлүгү эмес, GRE же VTI дизайны. Бир нерсени өзгөртүүдөн мурун беш текшерүүнүн кайсынысы ишке ашпаганын жазыңыз, анан ошол катмарды гана өзгөртүңүз.