VPN દ્વારા PIM-SM: BSR, RP મેપિંગ અને RPF પથ ચકાસો

ટનલ ચાલુ છે, યુનિકાસ્ટ પિંગ તેમાંથી પસાર થાય છે, અને રિસીવર હજી કાળી સ્ક્રીન બતાવે છે. PIM-SM ડિપ્લોયમેન્ટમાં આ લક્ષણ લગભગ હંમેશા એમ કહે છે કે ચાર કંટ્રોલ પથમાંથી એક તૂટેલો છે, અને ડેટા પથ ક્યારેય સમસ્યા નહોતો. નીચેની સૂચિ ક્રમમાં પૂરી કરો અને જે પહેલું પગલું નિષ્ફળ જાય ત્યાં થોભો, કારણ કે દરેક પછીનું પગલું તેનાથી પહેલાના પર આધાર રાખે છે. હું આ પાંચ તપાસ ડ્રાફ્ટ ફાઇલમાં રાખું છું અને મલ્ટિકાસ્ટ ફરિયાદ આવે ત્યારે ટર્મિનલમાં પેસ્ટ કરું છું, જે નિદાનને અટકળોમાં ફેરવાતું અટકાવે છે.

ટનલથી નહીં, રિસીવરથી શરૂ કરો

જે રિસીવરે ક્યારેય જૂથ માટે વિનંતી કરી નથી તે કોઈપણ રાઉટર પર કોઈ સ્થિતિ ઊભી કરતું નથી, તેથી બીજું કંઈપણ તપાસતા પહેલા ખાતરી કરો કે રિસીવર તરફના સેગમેન્ટમાં જોડાણ અસ્તિત્વમાં છે. 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ને મોકલે છે, તેથી RP-થી-BSR ભાગ સામાન્ય રીતે કાર્યરત ટનલમાં અપરિવર્તિત રહે છે. બીજી દિશામાં Bootstrap સંદેશાઓનો પ્રવાહ દરેક મધ્યવર્તી ઇન્ટરફેસ પર PIM સક્રિય હોવા પર અને કોઈ સીમા પર સંદેશાઓને રોકતું ન હોવા પર આધાર રાખે છે. RFC 5059 તે વિતરણ અને વહીવટી વ્યાપની સીમાઓ વ્યાખ્યાયિત કરે છે જેને તેને ટૂંકાવવાની મંજૂરી છે.

ip pim bsr-border વિધાન, પ્રોટોકોલ 103 ફિલ્ટર કરતું ACL, અથવા મલ્ટિકાસ્ટ વહન કરી શકતું ન હોય તેવું નીતિ-આધારિત IPsec ટનલ, દરેક પ્રવાહને કાપી નાખશે જ્યારે યુનિકાસ્ટ અકબંધ રહેશે. આ જ સંયોજન નિષ્ફળતાને 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ની અંદર સ્રોત-વિશિષ્ટ મલ્ટિકાસ્ટ માટે RPને ક્યારેય પૂછવામાં આવતું નથી, તેથી ખાલી RP મેપિંગ આપોઆપ ખામી નથી. ક્યારેય જરૂરી ન હોય તેવા RPની પાછળ પડતાં પહેલાં એપ્લિકેશન કઈ સેવા મોડેલ વાપરે છે તે નક્કી કરો.

સ્રોત તરફ RPF શોધ વાંચો

PIM યુનિકાસ્ટ પથને ઉલટાવીને વૃક્ષ બનાવે છે, તેથી મહત્વની તપાસ સ્રોત તરફ પાછી જતી રૂટ છે, અથવા વહેંચાયેલા વૃક્ષ માટે RP તરફ પાછી જતી રૂટ. જે જોડાણ એવા ઇન્ટરફેસ પર આવે છે જેને રાઉટર અપસ્ટ્રીમ ગણતું નથી તે કાઢી નાખવામાં આવે છે, અને કારણ ટનલ નિષ્ફળતા તરીકે નહીં પણ RPF નિષ્ફળતા તરીકે નોંધાય છે. ટનલ પર ડિફોલ્ટ રૂટ અને WAN પર વધુ ચોક્કસ રૂટ ધરાવતા શાખા રાઉટર પર, સ્રોત ફક્ત ટનલ દ્વારા જ પહોંચી શકાય તેમ હોવા છતાં RPF ઇન્ટરફેસ સહેલાઈથી WAN હોઈ શકે. જોડાણ ચૂપચાપ કાઢી નાખવાનું આ એક જ સૌથી સામાન્ય કારણ છે.

show ip rpf 192.0.2.10 પસંદ કરેલા ઇન્ટરફેસ, આગલા હોપ અને નિર્ણય પેદા કરનારી રૂટ છાપે છે, જે સામાન્ય રીતે અસંગતિ જોવા માટે પૂરતું છે. ip mroute 192.0.2.0 255.255.255.0 tunnel0 જેવી સ્થિર મલ્ટિકાસ્ટ રૂટ તે પ્રિફિક્સ માટેની યુનિકાસ્ટ શોધને બાજુ પર રાખે છે, અને જ્યારે મલ્ટિકાસ્ટ ટોપોલોજી ખરેખર યુનિકાસ્ટ ટોપોલોજીથી અલગ હોય ત્યારે તે કાયદેસર સુધારો છે. તેને દસ્તાવેજીકરણ કરવા જેવી કન્ફિગરેશન તરીકે ગણો, ઘટના દરમિયાન લગાડીને ભૂલી જવાયેલા પૅચ તરીકે નહીં.

પિંગથી નહીં, આદેશોથી જોડાણની ખાતરી કરો

પિંગ સાબિત કરે છે કે યુનિકાસ્ટ કામ કરે છે, જે તમે પહેલેથી જાણતા હતા. શરૂઆતથી અંત સુધીની ખાતરી એ એવો ક્રમ છે જે જોડાણ, મેપિંગ, પડોશી અને વૃક્ષને તે જ ક્રમમાં દેખાડે છે, અને દરેક આદેશ અલગ પ્રશ્નનો જવાબ આપે છે.

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 અથવા ફાયરવોલ નિયમ જે યુનિકાસ્ટ રાઉટિંગ પ્રોટોકોલને મંજૂરી આપે પણ PIM, IGMP કે જૂથ ટ્રાફિકને નહીં. નીતિ-આધારિત IPsec ટનલ પર મલ્ટિકાસ્ટ બિલકુલ વહન થતું નથી, તેથી જવાબ GRE કે VTI ડિઝાઇન છે, બીજું ફિલ્ટર અપવાદ નહીં. કંઈપણ બદલતા પહેલાં પાંચમાંથી કઈ તપાસ નિષ્ફળ ગઈ તે લખો, પછી ફક્ત તે જ સ્તર બદલો.