PIM-SM د VPN له لارې: BSR، د RP نقشه او د RPF لارې وګورئ

ټنل روان دی، یونیکاسټ پینګونه ترې تېریږي، او ترلاسه کوونکی بیا هم توره پرده ښیي۔ په 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ونه خپلې اعلانونه په unicast سره ټاکل شوي BSR ته لیږي، نو له RP څخه BSR ته برخه په کارکوونکي ټنل کې معمولاً پرته له بدلون پاتې کیږي۔ بلې خوا ته د Bootstrap پیغامونو سیلاب په دې تکیه دی چې هر منځګړی انټرفیس PIM فعال ولري او په پوله کې د پیغامونو د بندولو څه نه وي۔ RFC 5059 هغه وېش او د اداري ساحې هغه پولې تعریفوي چې اجازه لري یې لنډ کړي۔

ip pim bsr-border بیان، هغه ACL چې پروتوکول 103 فلټر کوي، یا پر پالیسي ولاړ IPsec ټنل چې multicast نه شي لېږدولی، هر یو به سیلاب پرې کړي او 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 نښان لرونکی شمېرونکی چې دوامداره لوړیږي، ټنل ته نه بلکې مخکیني برخې ته اشاره کوي۔

که پنځه واړه کمانډونه سم ښکاره شي او ترلاسه کوونکی بیا هم هېڅ نه ویني، پاتې شکمن د ټنل خپله پالیسي ده: کریپټو ACL یا د اور وژنې دیوال قاعده چې unicast روټینګ پروتوکول ته اجازه ورکوي خو PIM، IGMP یا د ډلې ترافیک ته نه۔ په پر پالیسي ولاړ IPsec ټنل کې multicast هېڅ نه لېږدول کیږي، نو ځواب د GRE یا VTI ډیزاین دی، نه بله فلټر استثنا۔ مخکې له دې چې څه بدل کړئ ولیکئ چې له پنځو کتنو کومه ناکامه شوه، بیا یوازې هغه طبقه بدله کړئ۔