کیوں QFX کا MAC EVPN میں نظر آتا ہے مگر فارورڈنگ ٹیبل میں نہیں

EVPN ڈیٹا بیس میں MAC ملنا ثابت کرتا ہے کہ اسے بطور روٹ اعلان یا وصول کیا گیا، اور اس سے زیادہ کچھ نہیں۔ فارورڈنگ ٹیبل ایک الگ ساخت ہے جو بعد میں پروگرام ہوتی ہے، اس لیے وہی MAC ایک میں نظر آ سکتا ہے اور دوسرے میں نہیں، جبکہ ہر پروٹوکول درست کام کر رہا ہوتا ہے۔ ان دونوں آؤٹ پٹس کو ایک دوسرے کی نقل ماننا انجینئروں کو BGP کی خرابی کے پیچھے بھیجتا ہے، جبکہ اصل خلا درآمد پالیسی یا حل نہ ہونے والا اگلا ہاپ ہے۔ پوچھنے کے قابل سوال یہ نہیں کہ fabric کو MAC معلوم ہے یا نہیں، بلکہ یہ ہے کہ کس مرحلے پر اس نے اسے آگے بھیجنا بند کیا۔

دو ٹیبل جو مختلف سوالات کے جواب دیتے ہیں

Junos EVPN میں ڈیٹا بیس ہر انسٹانس کے لیے MAC پتے درج کرتا ہے اور یہ بھی کہ ہر ایک کیسے آیا: ایکسیس پورٹ سے سیکھا گیا، Type 2 روٹ میں وصول، یا ملٹی ہومنگ گروپ کے حصے کے طور پر نشان زد۔ Juniper کا show evpn database حوالہ ہر MAC اور ہر انسٹانس کے فلٹرز کا احاطہ کرتا ہے جو دیکھنے کو پڑھنے کے قابل بناتے ہیں۔ یہ انسٹانس اور MAC کی کلید والا کنٹرول پلین خلاصہ ہے، وہ ٹیبل نہیں جس سے ہارڈ ویئر فریم سوئچ کرتا ہے۔

سوئچنگ ٹیبل وہی فارورڈنگ حالت ہے۔ دونوں آؤٹ پٹس MAC کو VLAN یا VNI سیاق کے ساتھ درج کرتے ہیں، اور یہی وجہ ہے کہ ان کا سطر بہ سطر موازنہ ہوتا ہے، اور یہی وجہ ہے کہ موازنہ گمراہ کرتا ہے۔ ڈیٹا بیس میں اندراج کہتا ہے کہ روٹ موجود ہے اور انسٹانس میں قبول ہوا؛ یہ نہیں بتاتا کہ پلیٹ فارم نے اسے فارورڈنگ کے لیے نصب کیا یا نہیں۔

Type 2 روٹ MAC، اختیاری IP، لیبل یا VNI، روٹ ممیز اور اگلا ہاپ جو دور کے VTEP کا نام لیتا ہے، لے کر جاتا ہے۔ تار اور اس روٹ کے درمیان چار چیزیں ٹوٹ سکتی ہیں: ہوسٹ کبھی نہیں سیکھا جاتا، روٹ کبھی اعلان نہیں ہوتا، درآمد پر مسترد ہو جاتا ہے، یا اس کا اگلا ہاپ حل نہیں ہوتا۔ ہر ناکامی مختلف ٹیبل مجموعہ بھرا چھوڑتی ہے، اور یہی وجہ ہے کہ اس ترتیب کی تشخیص ممکن ہے۔

مقامی سیکھنا اب بھی پہلے ہوتا ہے

عام مفروضہ یہ ہے کہ EVPN MAC سیکھنے کو سنبھال لیتا ہے، اس لیے خالی ڈیٹا بیس کا مطلب overlay مسئلہ ہونا چاہیے۔ مقامی سیکھنا اب بھی ایکسیس طرف چلتا ہے، بالکل ویسے ہی جیسے VXLAN سے پہلے: سوئچ اجازت شدہ فریم کا ماخذ MAC درست VLAN اور سروس میں سیکھتا ہے، اور اس کے بعد ہی اس کے لیے Type 2 بناتا ہے۔ جس ہوسٹ نے کوئی متعلقہ فریم نہیں بھیجا، اس کے پاس اعلان کرنے کو کچھ نہیں۔ جس ہوسٹ کے فریم VLAN رکنیت، فلٹر یا کسی مجموعے کے بند رکن کی وجہ سے ضائع ہوتے ہیں، وہ overlay کے نقطہ نظر سے یکساں دکھتا ہے۔

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

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

بنڈل کے اوپر ہونے سے زیادہ منتخب LACP ارکان اہم ہیں، کیونکہ مجموعہ ایک رکن پر اوپر ہو سکتا ہے جبکہ ہوسٹ کی ٹریفک ایسے لنک پر ہیش ہوتی ہے جو بند یا مسدود ہو۔ انٹرفیس کاؤنٹر خاموش ہوسٹ کو گرانے والے ہوسٹ سے الگ کرتے ہیں، کیونکہ جو ہوسٹ کبھی نہیں بھیجتا اور جس ہوسٹ کے فریم درجہ بندی سے ضائع ہوتے ہیں، دونوں وہی خالی ٹیبل چھوڑتے ہیں۔

دور کا MAC کہاں گم ہوتا ہے

دور کا MAC مخالف سمت میں ناکام ہوتا ہے، اور خاموشی سے۔ Type 2 روٹ آتا ہے، مگر یہ انسٹانس میں تب ہی داخل ہوتا ہے جب اس کا روٹ ہدف اور VNI مقامی ترتیب سے مطابقت رکھیں، اور تب ہی قابل استعمال ہوتا ہے جب اس کا اگلا ہاپ قابل رسائی VTEP میں حل ہو۔ روٹ ہدف کی عدم مطابقت BGP ٹیبل میں ایک درست روٹ چھوڑ دیتی ہے جس کی کوئی انسٹانس کبھی درخواست نہیں کرتی۔

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

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

وہ آؤٹ پٹس تین الگ سوالات کے جواب دیتے ہیں۔ bgp.evpn.0 میں روٹ ہو مگر ڈیٹا بیس اندراج نہ ہو تو یہ درآمد پالیسی، روٹ ہدف یا انسٹانس ترتیب کی طرف اشارہ کرتا ہے۔ ڈیٹا بیس اندراج ہو مگر فارورڈنگ اندراج نہ ہو تو یہ پلیٹ فارم پروگرامنگ کی طرف اشارہ کرتا ہے، جو دوسرے ایسکلیشن راستے کا ہے۔ جس فعال روٹ کا اگلا ہاپ حل نہ ہو وہ نقل و حمل یا لیبل کا مسئلہ ہے، اور MAC ڈی بگنگ کی کوئی مقدار اسے درست نہیں کرتی۔

جس ری بوٹ نے اسے درست کیا وہ بہت کم ثابت کرتا ہے

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

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

show evpn database instance blue
show route table bgp.evpn.0
show version

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

چار مشاہدے جو زیادہ تر معاملات طے کرتے ہیں

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

پھر جوابات کو ناکام مرحلے کی طرف اشارہ کرنے دیں۔ منسلکہ پر سیکھنے کا نہ ہونا ایکسیس طرف ہے؛ ڈیٹا بیس اندراج کے بغیر روٹ درآمد ہے؛ فارورڈنگ حالت کے بغیر ڈیٹا بیس اندراج پروگرامنگ ہے۔ جو بھی ہو، جمع شدہ آؤٹ پٹس ہوسٹ، انٹرفیس، سروس اور بلڈ کے ساتھ حوالے کریں، تاکہ اگلا انجینئر سوال دہرانے کے بجائے راستہ دوبارہ بنا سکے۔