PIM-SM VPN-ի միջով՝ 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-ը կամ քաղաքականության վրա հիմնված 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, որոնք նույն միջակայքի համար հայտարարում են տարբեր հասցեներ, այդպիսին չեն, ինչքան էլ յուրաքանչյուր տեղամաս առանձին առողջ տեսք ունենա։

232.0.0.0/8-ի ներսում աղբյուր-հատուկ multicast-ի համար 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 տոպոլոգիայից։ Վերաբերվեք դրան որպես փաստաթղթավորվող կարգաբերման, ոչ թե միջադեպի ընթացքում կիրառված և հետո մոռացված կարկատանի։

Հաստատեք միացումը հրամաններով, ոչ 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 պիտակով հաշվիչը, որը շարունակ բարձրանում է, մատնանշում է նախորդ բաժինը, ոչ թե թունելը։

Եթե բոլոր հինգ հրամանները ճիշտ են թվում, և ստացողը դեռ ոչինչ չի տեսնում, մնացած կասկածյալը թունելի սեփական քաղաքականությունն է. կրիպտո ACL կամ firewall կանոն, որը թույլ է տալիս unicast երթուղավորման արձանագրությունը, բայց ոչ PIM-ը, IGMP-ն կամ խմբի երթևեկությունն ինքը։ Քաղաքականության վրա հիմնված IPsec թունելում multicast-ը բոլորովին չի տեղափոխվում, ուստի պատասխանը GRE կամ VTI նախագծումն է, ոչ թե ֆիլտրի ևս մեկ բացառություն։ Գրի առեք, թե հինգ ստուգումներից որն է ձախողվել, նախքան որևէ բան փոխելը, ապա փոխեք միայն այդ շերտը։