آپ کا L2VPN ابھی بنایا ہوا RSVP-TE LSP کیوں نظر انداز کرتا ہے

دو انجینئر ایک ہی دیکھ بھال کی کھڑکی سے یہ یقین رکھتے ہوئے نکل سکتے ہیں کہ نیا راستہ سروس میں ہے، اور دونوں مختلف وجوہات سے غلط ہو سکتے ہیں۔ ایک نے LSP بنایا اور فرض کیا کہ سروس اس کے پیچھے چلے گی۔ دوسرے نے سروس کو اکیلا چھوڑ دیا اور فرض کیا کہ کچھ نہیں بدلا۔ pseudowire صرف اسی ٹرانسپورٹ کا استعمال کرتا ہے جس میں اس کے پیر کا پتہ اس لمحے حل ہوتا ہے، اس لیے اصل سوال یہ ہے کہ وہ حل ابھی کیا پیدا کرتا ہے، اور دونوں ڈیزائن اس کا مختلف جواب دیتے ہیں۔

ایک لیبل سروس کا نام دیتا ہے، دوسرا پیکٹ حرکت دیتا ہے

pseudowire لیبل، جو ہدف شدہ LDP کے ذریعے سگنل ہوتا ہے اور RFC 4447 میں بیان کیا گیا ہے، وصول کرنے والے فراہم کنندہ کنارے کو بتاتا ہے کہ کون سا اٹیچمنٹ سرکٹ فریم لینا چاہیے۔ فریم وہاں کیسے پہنچا اس بارے میں یہ کچھ نہیں کہتا۔ اس کے نیچے کا لیبل ٹرانسپورٹ کا ہے، اور وہ اسٹیک اسی نے بنایا ہے جس نے پیر لوپ بیک کے لیے رسائی کا اعلان کیا، چاہے وہ LDP ہو، RSVP-TE ہو یا قطعہ وار روٹ شدہ راستہ۔ چونکہ دو تہوں کو مختلف پروٹوکول سگنل کرتے ہیں، ایک صحت مند ہو سکتی ہے جبکہ دوسری پرانی ہو۔ یہی علیحدگی پوری الجھن کا سرچشمہ ہے۔

سیدھا کہنا مناسب ہے: pseudowire LSP نہیں چنتا۔ یہ فریم ٹرانسپورٹ کے حوالے کرتا ہے، اور ٹرانسپورٹ اسے دیے گئے منزل کے پتے سے فیصلہ کرتا ہے۔

اسی وجہ سے نئے LSP پر ایک صاف ping اتنا کم ثابت کرتا ہے۔ LSP چالو، لیبل والا اور دوسری سروسز اٹھائے ہو سکتا ہے جبکہ آپ کا pseudowire ابھی بھی کسی دوسرے اگلے ہاپ سے حل ہو رہا ہو۔ جب تک آپ بائنڈنگ نہیں پڑھتے، یہ دو حقائق متعلق نہیں۔

اختیار A: pseudowire کو منتخب ٹرانسپورٹ پر پن کریں

پن کرنے کا مطلب سروس کے ٹرانسپورٹ حل کو قطعی بنانا ہے۔ پلیٹ فارم کے مطابق یہ ٹنل کے انتخاب کی پالیسی، سروس پر واضح ٹرانسپورٹ اینڈ پوائنٹ، یا پیر کے پتے کے لیے اگلا ہاپ دوبارہ لکھنے والی روٹ پالیسی کی شکل اختیار کرتا ہے۔ تینوں اندر سے ایک ہی کام کرتے ہیں: ایک منزل کے حل کو مخصوص LSP پر مجبور کرتے ہیں۔ یہی نتیجے کو بعد میں قابلِ آڈٹ بناتا ہے۔

قیمت دائرہ ہے۔ پیر کے پتے پر منطبق پالیسی اس پیر کی طرف اشارہ کرنے والی ہر سروس کو متاثر کرتی ہے، صرف وہ pseudowire نہیں جو آپ کے ذہن میں تھا۔

متبادل راستہ تبدیلی کی کھڑکی سے پہلے فیصلہ مانگتا ہے، اس کے دوران نہیں۔ اگر پن شدہ LSP گر جائے تو آپ سروس کو کسی دوسرے منظور شدہ راستے پر جانے دیتے ہیں یا اسے رکنے دیتے ہیں۔ جو پالیسی خاموشی سے ایسے راستے پر لوٹتی ہے جو تاخیر یا علیحدگی کی شرط توڑتا ہے، اس نے صاف رکاوٹ کو ایسی چیز میں بدل دیا ہے جو کسی کو بھی سمجھانا کہیں زیادہ مشکل ہے۔

اختیار B: IGP کو چننے دیں اور دیکھیں کیا ہوتا ہے

سروس کو اکیلا چھوڑنا جائز ڈیزائن ہے، اور اکثر بہتر۔ pseudowire پیر لوپ بیک کی طرف جانے والی کسی بھی دوسری ٹریفک جیسا ہی حل اپناتا ہے، اس لیے یہ IGP کے اتحاد، سابقے کی دباؤ اور وہ زیادتی ورثے میں پاتا ہے جو کور پہلے ہی دیتا ہے۔ کم پالیسیاں یعنی پرانی مطابقت چھپنے کی کم جگہیں۔ بدلہ یہ ہے کہ سروس کون سا راستہ لیتی ہے اب آپ کنٹرول نہیں کرتے، صرف یہ کہ کوئی راستہ موجود ہے۔

برابر لاگت والے متعدد راستے اس بدلے کو پہلی نظر سے زیادہ تیز کرتے ہیں۔ ہیشنگ بہاؤ کے لحاظ سے ہوتی ہے، اس لیے ایک pseudowire میں دو گفتگو مختلف بیرونی لیبلوں پر نکل سکتی ہیں۔

کسی ایک پر بھروسہ کرنے سے پہلے نصب شدہ فارورڈنگ پڑھیں

سروس سے نہیں، پیر کے پتے سے شروع کریں۔ Junos پر show route 203.0.113.1 detail منتخب اگلا ہاپ اور لیبل کی کارروائی چھاپتا ہے، اور show route table mpls.0 آنے والے لیبل کو اسی کارروائی سے نقشہ کرتا ہے۔ IOS XR پر show mpls l2transport vc 100 detail مسلط شدہ اسٹیک کے ساتھ pseudowire کی حالت دیتا ہے۔

اس LSP کی تصدیق کریں جو ٹرانسپورٹ واقعی استعمال کرتا ہے، نہ کہ وہ جس کا نام آپ کا ڈیزائن دستاویز لیتا ہے۔ IOS XR پر traceroute mpls ipv4 203.0.113.1/32 لیبل سے سوئچ شدہ راستے پر چلتا ہے اور اس کے ساتھ لیبل اور باہر جانے والے انٹرفیس کی فہرست دیتا ہے، جو راستے کو خود دیکھنے کے سب سے قریب ہے۔ پھر دور کے فراہم کنندہ کنارے سے مشق دہرائیں، کیونکہ واپسی کی سمت خود مختار طور پر حل ہوتی ہے اور پالیسی کے جزوی نفاذ کے بعد عدم توازن عام ہے۔ ایک سمت میں درست اور دوسری میں غلط راستہ یکساں غلط راستے سے بدتر ہے، کیونکہ آپ کے آدھے ٹیسٹ پاس ہوں گے۔

شہادت سروس کے ریکارڈ کے ساتھ رکھیں: پیر کا پتہ، اگلا ہاپ، بیرونی لیبل اور وہ تاریخ جب آپ نے جانچا۔ روٹ پالیسیاں بری طرح پرانی ہوتی ہیں، اور کسی کو یاد نہیں کہ دو سہ ماہی پہلے کون سی نافذ تھی۔

پسند سے نہیں، ناکامی کے طریقے سے چنیں

پن کرنا ایسی سروسز کے لیے موزوں ہے جن میں ایسی شرط ہو جو IGP بیان نہیں کر سکتا، اور ان ٹیموں کے لیے جو ہر تبدیلی میں پالیسی برقرار رکھ سکیں۔ IGP پر چھوڑنا ایسی سروسز کے لیے موزوں ہے جنہیں لوپ میں انسان کے بغیر کسی بھی واحد ناکامی سے گزرنا ہو۔

فیصلہ کن سوال یہ ہے کہ غلط راستہ آپ کو کتنا مہنگا پڑتا ہے۔ اگر غلط LSP پر سروس صرف تھوڑی بری کارکردگی دیتی ہے تو IGP کو فیصلہ کرنے دیں اور محنت نگرانی پر خرچ کریں۔ اگر غلط راستہ معاہدہ، آڈٹ کی دریافت یا علیحدگی کی ضرورت توڑتا ہے تو اسے پن کریں اور متبادل راستہ لکھیں۔ پھر متبادل راستے کی جانچ کریں، کیونکہ غیر جانچا متبادل ایک مفروضہ ہے، منصوبہ نہیں۔ بہرحال، کور میں کسی بھی تبدیلی کے بعد نصب شدہ بائنڈنگ دوبارہ پڑھیں، اور اوپر آئے pseudowire کو صرف اس بات کا ثبوت سمجھیں کہ سگنلنگ کام کرتی ہے۔