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 جیسا مستقل ملٹی کاسٹ راستہ اس پریفکس کے لیے یونیکاسٹ تلاش کو نظر انداز کرتا ہے، اور جب ملٹی کاسٹ ٹوپولوجی واقعی یونیکاسٹ ٹوپولوجی سے مختلف ہو تو یہ جائز اصلاح ہے۔ اسے دستاویز کرنے والی کنفیگریشن سمجھیں، واقعے کے دوران لگا کر بھول جانے والا پیچ نہیں۔

شمولیت کی تصدیق ping سے نہیں، کمانڈز سے کریں

ping ثابت کرتا ہے کہ یونیکاسٹ کام کرتا ہے، جو آپ پہلے ہی جانتے تھے۔ سرے سے سرے تک تصدیق ایک ایسی ترتیب ہے جو شمولیت، میپنگ، ہمسایہ اور درخت کو اسی ترتیب سے دکھاتی ہے، اور ہر کمانڈ الگ سوال کا جواب دیتی ہے۔

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 ڈیزائن ہے، فلٹر کی ایک اور استثنا نہیں۔ کچھ بھی بدلنے سے پہلے لکھیں کہ پانچ جانچوں میں سے کون ناکام ہوئی، پھر صرف وہی پرت بدلیں۔