BGP سیشن قائم، گاہک کا راستہ ٹوٹا: DMVPN پر MPLS
ایک BGP سیشن ایک پتے تک ایک TCP راستہ ثابت کرتا ہے۔ گاہک کی ٹریفک کو درست VRF، لیبل اور NHRP میپنگ بھی درکار ہے، اور دونوں خرابیاں ایک جیسی دکھتی ہیں۔
پیئرنگ ہفتوں سے قائم ہے، پریفکس کی تعداد درست دکھائی دیتی ہے، پھر بھی ایک گاہک کی ٹریفک اب بھی لمبا راستہ لیتی ہے یا پہنچتی ہی نہیں۔ ایک ہی اشارے سے دو مختلف چیزیں پرکھی جا رہی ہیں۔ BGP سیشن بتاتا ہے کہ دو پیر TCP کنکشن پر پیغامات کا تبادلہ کر سکتے ہیں؛ یہ اس بارے میں کچھ نہیں کہتا کہ اوورلے اس مخصوص گاہک کے لیے لیبل والا پیکٹ لے جا سکتا ہے یا نہیں۔
یہ خلا MPLS-over-DMVPN ڈیزائن میں سب سے آسانی سے نظر آتی ہے، جہاں ہب کا راستہ اور سیدھا اسپوک راستہ ایسی وجوہات سے مختلف برتاؤ کر سکتے ہیں جن کا پیئرنگ سے کوئی تعلق نہیں۔
سیشن واقعی کیا ثابت کرتا ہے
BGP TCP پر چلتا ہے، اس لیے کسی اور چیز سے پہلے ہر پیر کو دوسرے سرے کے پتے تک راستہ درکار ہوتا ہے۔ اگر اس سرے کے طور پر loopback چنیں تو آپ نے فارورڈنگ کی ضمانت نہیں بلکہ رسائی کی شرط بنائی ہے۔ اس کے بعد سیشن ایسی انٹرفیس سے بھی قائم رہ سکتا ہے جو گاہک کی ٹریفک کبھی استعمال نہیں کرے گی۔
نتیجہ اخذ کرنے سے پہلے دونوں سروں پر چار حقائق لکھیں: سیشن کا ماخذ پتہ، منزل کا پتہ، وہ روٹنگ سیاق جس میں یہ ہے، اور کرنل یا روٹر اس جوڑی کے لیے کون سی انٹرفیس چنے گا۔ یہ حقائق کنٹرول سطح بیان کرتے ہیں۔ گاہک کے پیکٹ ان پر VRF، لیبل اسٹیک اور اوورلے میپنگ کا اضافہ کرتے ہیں۔
چار طریقہ کار، ایک نہیں
MPLS-over-DMVPN کے بارے میں Cisco کی دستاویزات حصوں کو واضح طور پر الگ کرتی ہیں۔ MP-BGP فراہم کنندہ کے کنارے کے آلات کے درمیان گاہک کے اوورلے لیبل تقسیم کرتا ہے۔ MPLS ان لیبلوں کو پیکٹ کا فارورڈنگ سیاق چننے کے لیے استعمال کرتا ہے۔ NHRP اوورلے پتے کو اس ٹرانسپورٹ سرے سے میپ کرتا ہے جس کی متحرک ٹنل کو ضرورت ہوتی ہے۔ IPsec جہاں لاگو ہو وہاں پیر راستے کی حفاظت کرتا ہے۔
چاروں میں سے کوئی بھی درست ہو سکتا ہے جبکہ دوسرا غلط ہو، اور ٹریفک لے جانے والا یہی امتزاج ہے۔ راستوں کا تبادلہ مکمل ہو سکتا ہے جبکہ ایک VRF کے لیے لیبل بائنڈنگ غائب ہو، NHRP میپنگ پرانے ٹرانسپورٹ پتے کی طرف اشارہ کر رہی ہو، یا ٹنل موجود ہو مگر کوئی پالیسی اندرونی پیکٹ کی اجازت نہ دے۔ ان میں سے کوئی کیفیت سیشن کو نہیں گراتی۔
ہب راستے کا موازنہ شارٹ کٹ سے کریں، ایک وقت میں ایک متغیر
ماخذ ہوسٹ، منزل ہوسٹ اور VRF کو مستحکم کریں، پھر اسی بہاؤ کو دو بار ٹریس کریں۔ ہب راستے پر اگلا ہاپ، دور دراز گاہک کے سیاق کی شناخت کرنے والا سروس لیبل، اور زیرِ استعمال اوورلے سے ٹرانسپورٹ میپنگ لکھیں۔ مطلوبہ سیدھے راستے پر بھی وہی تین چیزیں لکھیں۔ دو فہرستوں کا فرق ہی خرابی ہے، یا خرابی کا نہ ہونا۔
موازنے کے دوران بہاؤ کو مستقل رکھیں۔ مشاہدوں کے درمیان ماخذ ہوسٹ، VRF یا منزل بدلنے سے دو غیر متعلق کہانیاں بنتی ہیں، اور یہی اس مشق کے بگڑنے کا عام ترین طریقہ ہے۔
loopback جانچ کو ان کے اپنے خانے میں رکھیں
روٹر کے loopback سے بھیجا گیا ping مفید جانچ ہے، اور یہ ہوسٹ کے بہاؤ سے مختلف صورت جانچتا ہے۔ ماخذ پتہ روٹر کا ہے، اس کا روٹنگ سیاق VRF کے بجائے عالمی ہو سکتا ہے، اور جواب کا راستہ گاہک کے پریفکس کے راستے سے مختلف ہو سکتا ہے۔ اس لیے loopback کا جواب دینا اور اس ایپلیکیشن کا شارٹ کٹ پر چلنا الگ نتائج ہیں، اور صرف دوسرا گاہک کی وضاحت کرتا ہے۔
دونوں جانچیں، پھر اپنے نوٹس میں انہیں الگ نشان زد کریں۔ جب وہ میل نہ کھائیں، آپ نے اس بارے میں کچھ ٹھوس سیکھا کہ ڈیزائن کہاں بھٹکتا ہے، اور یہ ایک سبز نشان کے کبھی بتا سکنے سے زیادہ ہے۔
ورژن اور خرابی کے دعووں کو اپنے ثبوت چاہیے
میدانی رپورٹیں کبھی کبھی ہوسٹ ماسک یا BGP ماخذ پتہ بدلنے کی تجویز دیتی ہیں، اور ایسی رپورٹیں صرف اسی خرابی اور ان ریلیز کے ساتھ پڑھنے کے قابل ہیں جن کے بارے میں وہ لکھی گئیں۔ ایک ریلیز کا حل یہ بیان نہیں کہ ساخت ہر /32 پریفکس کی حمایت نہیں کرتی۔
اپنے DMVPN مرحلے، پلیٹ فارم اور ریلیز سے میل کھاتی دستاویزات استعمال کریں، اور یاد رکھیں کہ ایک باب FlexVPN سمیت کئی ترتیبوں کو محیط ہو سکتا ہے۔ ایک ترتیب کی مثال دوسری میں خاموشی سے منتقل نہیں ہوتی۔ سیشن کے سرے اسی کنٹرول سطح ڈیزائن کے لیے چنیں جو آپ کو واقعی درکار ہے، پھر گاہک کے فارورڈنگ راستے کی الگ سے تصدیق کریں، کیونکہ ہر loopback ماسک دوبارہ لکھنا یہ جاننے کا متبادل نہیں کہ کون سا کام ناکام ہوا۔