NX-OS EVPN نل روٹ: رد کرنا ایک ہی کرایہ دار کے اندر رکھیں

درخواست ایک سطر کی تبدیلی کے طور پر آتی ہے: ایک پتہ بلاک کریں۔ آپ کرایہ دار کے سیاق و سباق میں Null0 کی طرف ہوسٹ روٹ شامل کرتے ہیں، سابقہ توقع کے مطابق مقامی جدول سے غائب ہو جاتا ہے، اور پھر سوالات شروع ہوتے ہیں۔ کیا روٹ ڈیوائس سے باہر گیا؟ کیا دور کے VTEP نے رد کیا، یا انہوں نے صرف رسائی کھو دی؟ کیا اب دوسرا کرایہ دار متاثر ہے؟

درست مقامی جامد روٹ ان سوالات میں سے صرف پہلے کا جواب دیتا ہے، اسی لیے بلیک ہول تبدیلی درحقیقت ایک کمانڈ نہیں بلکہ تین جائزہ شدہ نتائج ہیں۔

تبدیلی کو واقعی کیا پیدا کرنا چاہیے

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

ہر نتیجے کے اپنے ثبوت ہیں اور کوئی بھی دوسرے کا تقاضا نہیں کرتا۔ مقامی Null0 روٹ مقامی رد کرنے کو جنم دیتا ہے اور دوبارہ تقسیم کے بغیر کچھ بھی برآمد نہیں کرتا۔ متفقہ community کے بغیر دوبارہ تقسیم شدہ روٹ عام سابقے کے طور پر آتا ہے اور آگے بھیجا جاتا ہے۔ وصولی پالیسی کے بغیر community کو مکمل طور پر نظر انداز کیا جا سکتا ہے۔

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

مقامی بیان صرف پہلا حصہ کرتا ہے

10.4(x) سلسلے کے NX-OS میں، نل روٹ VRF کا نام لینے والی ایک کمانڈ میں نہیں بلکہ کرایہ دار کے VRF سیاق و سباق کے اندر ہوتا ہے۔ ٹکڑا مختصر ہے، اور یہ بلاشبہ مکمل EVPN ترتیب نہیں ہے۔

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

پتہ دستاویزی سابقہ ہے، ہدف نہیں۔ IOS سے جملے کی ساخت کا فرق دیکھیں، جہاں VRF کا نام روٹ کمانڈ کے اندر ہی آتا ہے، اور کچھ بھی چسپاں کرنے سے پہلے اس ریلیز کے لیے معاون شکل کی تصدیق کریں جو آپ واقعی چلاتے ہیں۔

اکیلا یہ سطر TENANT_A کے اندر اس ہوسٹ کی ٹریفک رد کرتا ہے اور کچھ اور نہیں کرتا۔ یہ روٹ کو ٹیگ نہیں کرتا، BGP کے لیے منتخب نہیں کرتا اور community مقرر نہیں کرتا۔ یہ الگ ترتیبی فیصلے ہیں، اور ہر ایک ایسی جگہ ہے جہاں تبدیلی کام کرنے کے لیے بہت تنگ یا محفوظ رہنے کے لیے بہت وسیع ہو سکتی ہے۔

مقامی رد کرنا اسی منزل کی طرف قانونی ٹریفک کو بھی متاثر کرتا ہے۔ اگر مقصود یہ ہے کہ حقیقی صارفین کو ابھی بھی پتہ درکار ہو تو ایک غلط استعمال کرنے والے ماخذ کو روکا جائے، تو نل روٹ غلط ذریعہ ہے اور آپ یہ پہلی مدد کال سے سیکھیں گے۔

برآمد اور درآمد الگ معاہدے ہیں

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

BLACKHOLE community ایک معلوم قدر کے بارے میں معاہدہ ہے، کسی بھی پڑوسی کے لیے کسی بھی پتے کو رد کرنے کی اجازت نہیں۔ RFC 7999 اسے انہی اصطلاحات میں بیان کرتا ہے، اور یہ کہ کون اس کا اعلان کر سکتا ہے اس بارے میں اعتماد کی حد ڈیزائن کا حصہ ہے، عمل درآمد کی تفصیل نہیں۔

وصول کرنے والے فریق کو اپنی ترتیب درکار ہے۔ NX-OS میں، قسم 5 نل روٹ کو رد کرنے کا رویہ منتخب کرنے کے لیے VTEP پر route-map عمل درکار ہے، جو برآمدی مراحل کے ساتھ دستاویز کیا گیا ہے۔ درست طریقے سے ٹیگ کرنے والا بھیجنے والا آلہ اور ٹیگ کو نظر انداز کرنے والا وصول کنندہ ایسی تبدیلی بناتے ہیں جو نافذ شدہ دکھتی ہے اور پھر بھی ٹریفک آگے بھیجتی ہے۔

وہاں رہتے ہوئے route-map کے مضر اثرات دیکھیں۔ نئی پابند پالیسی غیر متعلق سابقوں کے لیے قانونی رسائی کو دبا سکتی ہے، اور وہ نقصان بلیک ہول کے بعد ظاہر ہوتا ہے اور اس سے منسوب کرنا مشکل ہے۔

داخل کرنے سے پہلے واپسی لکھیں

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

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

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

کمانڈ کے آؤٹ پٹ سے نہیں، ثبوت سے قبول کریں

مطلوبہ VTEP پر منتخب روٹنگ حالت اور آگے بھیجنے کی حالت جانچیں، اور ایک ہمسایہ منزل جانچیں جسے غیر متاثر رہنا چاہیے۔ تصدیق کریں کہ کسی دوسرے کرایہ دار نے سابقہ درآمد نہیں کیا، کیونکہ کرایہ داروں کے درمیان اخراج ہی وہ ناکامی کی صورت ہے جو دیکھ بھال کی کارروائی کو واقعہ بنا دیتی ہے۔

پھر واپس لیں اور تصدیق کریں کہ عام روٹ اور سروس لوٹ آتے ہیں۔ NX-OS EVPN نل روٹ رہنما 10.4(x) ریلیز کے لیے یہاں بیان کردہ ٹیگنگ، دوبارہ تقسیم اور وصولی پالیسی کی دستاویز کرتا ہے، اور یہ آپ کی اپنی ریلیز سے موازنہ کرنے کا حوالہ ہے۔