DMVPN WAN فیل اوور: روٹ پالیسی یا ٹنل بند کرنا؟

دو WAN والا DMVPN حب دو طریقوں میں سے ایک سے فیل اوور کرتا ہے، اور فرق دکھنے سے بڑا ہے۔ ایک بدلتا ہے کہ روٹ پالیسی کون سا اگلا ہاپ چنتی ہے، اس لیے پیکٹ بہتے رہتے ہیں اور صرف ان کا اخراج بدلتا ہے۔ دوسرا ٹنل کو انتظامی طور پر بند کر دیتا ہے، جو اس انٹرفیس کی ہر سروس کو ساتھ نیچے لے آتا ہے۔ دونوں درست ہو سکتے ہیں، کیونکہ وہ مختلف سوالات کا جواب دیتے ہیں۔

فیصلہ کنفیگ سے پہلے آتا ہے

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

اگر بند کرنا کام کرتی ہوئی سروسز کو نیچے لے آئے، تو روٹ پالیسی چھوٹا اقدام ہے۔ اگر تقاضا یہ ہو کہ بنیادی WAN کے نیچے رہنے تک ٹنل کا وجود ہی نہ ہو، تو کوئی پالیسی اندراج اس کا اظہار نہیں کر سکتا۔

جواب لکھ لیں، کیونکہ کنفیگ آسان حصہ ہے۔

روٹ پالیسی دراصل کیا بدلتی ہے

پالیسی پر مبنی روٹنگ میں، ٹریک شدہ آبجیکٹ اگلے ہاپ کو کنٹرول کر سکتا ہے۔ روٹ میپ اندراج ایک امیدوار اگلے ہاپ اور اس ٹریک شدہ آبجیکٹ کا نام دیتا ہے جو اسے استعمال کرنے کے لیے فعال ہونا چاہیے، اور وہ ٹریکنگ حالت IP SLA پروب سے آتی ہے۔ آبجیکٹ کے نیچے جانے پر اندراج مماثلت چھوڑ دیتا ہے اور پیکٹ کا جائزہ اگلا اندراج یا عام روٹنگ جدول لیتا ہے۔

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

نحو پلیٹ فارم اور ریلیز کے لحاظ سے مختلف ہے، اس لیے اس ورژن کی گائیڈ دیکھیں جو آپ واقعی چلاتے ہیں۔

ٹنل بند کرنا کیا بدلتا ہے

انٹرفیس بند کرنا انتظامی حالت بدلتا ہے۔ اس پر منحصر ہر ٹنل، روٹ اور سیشن ایک ساتھ نیچے جاتا ہے، جو تب بالکل وہی چاہیے جب ٹنل ہی وہ چیز ہو جسے غائب ہونا ہے۔ EEM ایپلٹ بھی اسی طرح WAN مسئلے کو ایسی بندش میں بدل دیتا ہے جس میں غیر متعلقہ سروسز بھی شامل ہوں۔

اگر یہ راستہ چنیں تو ایپلٹ کو ایک انٹرفیس اور ایک ٹرگر تک محدود رکھیں، پچھلی انتظامی حالت محفوظ کریں، بحالی کا عمل متعین کریں، اور یقینی بنائیں کہ بار بار ہونے والے فلپ اسے لوپ میں نہیں ڈال سکتے۔

ہارڈ کوڈ شدہ بحالی کمانڈ کسی اور کی کی گئی دیکھ بھال بندش کو بھی منسوخ کر سکتی ہے۔

پروب کو اسی راستے پر چلائیں جس کا آپ سوچتے ہیں

موجودہ بہترین روٹ کی پیروی کرنے والا پروب باقی سب کے ساتھ بیک اپ WAN پر چلا جاتا ہے، پھر بنیادی کو صحت مند بتاتا ہے کیونکہ اب وہ اسے استعمال نہیں کرتا۔

پروب کو اس راستے کے انٹرفیس یا ماخذ پتے پر پن کریں جس کی آپ جانچ کر رہے ہیں۔ یہ بھی دیکھیں کہ وہ کس کو نشانہ بناتا ہے، کیونکہ ISP کے اگلے ہاپ تک پہنچنا اس سروس تک پہنچنے سے کم ثابت کرتا ہے جس کے لیے ٹنل موجود ہے۔ اپ اور ڈاؤن تاخیر جان بوجھ کر مقرر کریں: مختصر ڈاؤن تاخیر تیزی سے ردعمل دیتی ہے اور فلپ کرتی ہے، جبکہ طویل تاخیر چھوٹے اتار چڑھاؤ برداشت کرتی ہے اور اصل ناکامیاں چھپا دیتی ہے۔ Cisco کی IOS XE میں ٹریکنگ اور پالیسی روٹنگ گائیڈ معاون امتزاجوں کی دستاویز کرتی ہے، اور آپ کے پلیٹ فارم کا فیچر سیٹ طے کرتا ہے کہ ان میں سے کون سے آپ استعمال کر سکتے ہیں۔

تاخیر کی دونوں قدریں ٹریک شدہ آبجیکٹ کے پاس لکھ لیں، ورنہ کسی کو پتہ نہیں چلے گا کہ اس نے ایسا رویہ کیوں اپنایا۔

بحالی کا فیصلہ کریں، پھر تصدیق کریں

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

اگر فیل اوور کام کرتا ہے مگر ایپلیکیشن پھر بھی ٹوٹتی ہے، تو مسئلہ روٹنگ تہہ کے اوپر ہے اور کوئی ٹریکنگ اسے ٹھیک نہیں کرے گی۔

اس ونڈو کے شواہد محفوظ رکھیں، کیونکہ اگلی تبدیلی کا موازنہ ان سے ہوگا۔