PIM-SM праз VPN: праверка BSR, суаднясення RP і шляхоў RPF

Тунэль працуе, unicast-пінгі праходзяць праз яго, але прыёмнік па-ранейшаму паказвае чорны экран. У разгортванні PIM-SM такі сімптом амаль заўсёды азначае, што адзін з чатырох шляхоў кіравання зламаны, а шлях даных ніколі не быў праблемай. Праходзьце спіс ніжэй па парадку і спыніцеся на першым кроку, які зрываецца, бо кожны наступны крок залежыць ад папярэдняга. Я трымаю гэтыя пяць праверак у чарнавым файле і ўстаўляю іх у тэрмінал, калі прыходзіць скарга на multicast, што не дае дыягназу ператварыцца ў здагадкі.

Пачніце з прыёмніка, а не з тунэля

Прыёмнік, які ніколі не запытваў групу, не стварае стану ні на адным маршрутызатары, таму пераканайцеся, што далучэнне існуе на сегменце, які глядзіць на прыёмнік, перш чым правяраць што-небудзь яшчэ. На платформах у стылі Cisco show ip igmp groups на маршрутызатары апошняга скачка друкуе далучаныя групы побач з інтэрфейсам, які іх пачуў. Калі групы няма ў гэтым вывадзе, тунэль — гэта адцягненне ўвагі: запыт загінуў на камутатары доступу, на сокеце хоста або ў VLAN без querier.

Дзве звычайныя прычыны тлумачаць большасць адсутных далучэнняў, якія я бачыў: неадпаведнасць версій IGMP паміж хостам і маршрутызатарам, і выбар querier, які прыпаў на камутатар, што не займаецца маршрутызацыяй. Трэцяя прычына танчэйшая: група далучана, але ў няправільным VLAN, бо ў хоста дзве сеткавыя карты і праграма прывязалася да няправільнай. У прыёмнікаў IPv6 тая ж праблема з MLD, дзе show ipv6 mld groups адказвае на тое ж пытанне. Ні адна з гэтых праблем не выпраўляецца дотыкам да тунэля, і менавіта таму парадак мае значэнне.

Як толькі далучэнне бачнае, пераканайцеся, што PIM уключаны і на інтэрфейсе, які глядзіць на прыёмнік, і на інтэрфейсе, які вядзе да пункта сустрэчы. Маршрутызатар з членствам IGMP, але без PIM на вышэйшым інтэрфейсе, будзе трымаць групу ў лакальнай табліцы і нікуды нічога не адправіць.

Ці дасягае набор BSR процілеглага боку?

Паведамленні Bootstrap Router рухаюцца скачок за скачком унутры аднаго дамена PIM, і менавіта гэты кірунак ламаецца праз тунэль. Кандыдаты RP адпраўляюць свае аб'явы абранаму BSR унікастам, таму ўчастак ад RP да BSR звычайна перажывае працоўны тунэль без зменаў. Плынь паведамленняў Bootstrap у адваротным кірунку залежыць ад таго, ці ўключаны PIM на кожным прамежкавым інтэрфейсе, і ад таго, ці нішто не спыняе паведамленні на мяжы. RFC 5059 вызначае гэтае распаўсюджанне і межы адміністрацыйнай зоны, якім дазволена яго абрываць.

Аператар ip pim bsr-border, ACL, які фільтруе пратакол 103, або тунель IPsec на аснове палітык, які не можа пераносіць multicast, кожны абрэжа плынь, пакідаючы unicast цэлым. Менавіта гэтая камбінацыя робіць збой падобным на праблему RP, калі насамрэч гэта праблема дасяжнасці, і таму я чытаю стан BSR перад чытаннем канфігурацыі RP.

На маршрутызатары процілеглага боку show ip pim bsr-router паказвае абраны BSR і набыты набор RP; калі вывад пусты, процілеглы бок знаходзіцца ў сваім дамене, і ніякая канфігурацыя RP не ўзгодніць абодва. Параўнайце дыяпазоны груп і адрасы RP у show ip pim rp mapping па абодвух баках тунэля. Суаднясенне, якое існуе толькі лакальна, стварае агульнае дрэва, што сканчаецца ў няправільным месцы, і прыёмнік чакае вечна.

Узгадніце суаднясенне RP па абодвух баках тунэля

Статычны RP, BSR і anycast-RP — тры спосабы адказаць на адно пытанне, і змешванне іх праз тунэль — надзейны спосаб пабудаваць дамен, які ніколі не збягаецца. Калі галаўны бок выкарыстоўвае BSR, а філіял — статычны ip pim rp-address, які паказвае на іншы адрас, філіял будуе сваё агульнае дрэва да RP, які не ведае пра існаванне прыёмніка. Суаднясенне павінна супадаць і па дыяпазоне груп, і па адрасе, бо больш канкрэтны дыяпазон перамагае шырэйшы.

Anycast-RP існуе менавіта для таго, каб два сайты маглі дзяліць адзін адрас RP, і варта назваць яго тут, бо ён змяняе сэнс «той самы RP». Два RP, якія абвяшчаюць адзін адрас, узгодненыя па задуме; два RP, якія абвяшчаюць розныя адрасы для таго ж дыяпазону, — не, як бы здарова кожны сайт ні выглядаў сам па сабе.

Для multicast, спецыфічнага для крыніцы, унутры 232.0.0.0/8 RP не запытваецца ніколі, таму пустое суаднясенне RP не з'яўляецца аўтаматычна збоем. Вызначце, якую мадэль паслугі выкарыстоўвае праграма, перш чым гнацца за RP, які ніколі не быў патрэбны.

Прачытайце пошук RPF у бок крыніцы

PIM будуе дрэва, разварочваючы шлях unicast, таму важная праверка — гэта маршрут назад да крыніцы або назад да RP для агульнага дрэва. Далучэнне, якое прыходзіць на інтэрфейс, што маршрутызатар не лічыць вышэйшым, адкідваецца, і прычына запісваецца як збой RPF, а не як збой тунэля. На маршрутызатары філіяла са стандартным маршрутам праз тунэль і больш канкрэтным маршрутам праз WAN інтэрфейс RPF можа лёгка аказацца WAN, хоць крыніца дасягальная толькі праз тунэль. Гэта самая распаўсюджаная прычына таго, што далучэнне ціха адкідваецца.

show ip rpf 192.0.2.10 друкуе выбраны інтэрфейс, наступны скачок і маршрут, які стварыў рашэнне, і гэтага звычайна дастаткова, каб убачыць неадпаведнасць. Статычны маршрут multicast, такі як ip mroute 192.0.2.0 255.255.255.0 tunnel0, перавышае пошук unicast для гэтага прэфікса, і гэта законнае выпраўленне, калі тапалогія multicast сапраўды адрозніваецца ад тапалогіі unicast. Стаўцеся да яго як да канфігурацыі, якую трэба дакументаваць, а не як да латкі, ужытай падчас інцыдэнту і забытай.

Пацвердзіце далучэнне камандамі, а не пінгам

Пінг даказвае, што 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, які ўвесь час расце, паказвае назад на папярэдні раздзел, а не на тунэль.

Калі ўсе пяць каманд выглядаюць правільна, а прыёмнік усё роўна нічога не бачыць, тое, што застаецца падазроным, — гэта ўласная палітыка тунэля: крыпта-ACL або правіла міжсеткавага экрана, якое дазваляе пратакол маршрутызацыі unicast, але не PIM, IGMP або сам трафік групы. У тунелі IPsec на аснове палітык multicast не пераносіцца зусім, таму адказ — праект GRE або VTI, а не чарговае выключэнне ў фільтры. Запішыце, якая з пяці праверак звалілася, перш чым нешта змяняць, і потым змяняйце толькі гэты пласт.