خاموش EVPN ہوسٹ کبھی حل نہیں ہوتا: ARP کا پیچھا بائنڈنگ تک کریں

اینڈ پوائنٹ منسلک ہے، اس کا پورٹ فعال ہے، اور مانیٹرنگ ہوسٹ اب بھی اس تک نہیں پہنچ سکتا۔ کوئی دوسری طرف سے ping چلاتا ہے اور یہ کام کرنے لگتا ہے، جس سے مسئلہ وقفے وقفے کا لگتا ہے اور fabric بے قصور دکھائی دیتا ہے۔ یہی نمونہ خاموش ہوسٹ کی پہچان ہے: یہ شاذ و نادر ہی بھیجتا ہے، اس لیے fabric کا دریافت اور ریفریش کردار اس کے کنکشن کی حالت سے زیادہ اہم ہے۔ ایک مطلوبہ IP، MAC اور bridge domain سے شروع کریں اور اگلے ریزولوشن تبادلے کا پیچھا کریں۔

اگلے ARP یا ND تبادلے کا پیچھا کریں

IPv4 کے لیے، درخواست کرنے والے ہوسٹ کا ARP تبادلہ دیکھیں؛ IPv6 کے لیے، Neighbor Solicitation اور Advertisement کا پیچھا کریں۔ تصدیق کریں کہ درخواست مطلوبہ مقامی سیگمنٹ اور مطلوبہ VNI میں داخل ہوتی ہے، کیونکہ جو درخواست کبھی صحیح bridge domain تک نہیں پہنچتی اس کا کوئی پراکسی جواب نہیں دے سکتا۔

پھر دیکھیں کہ fabric ہدف کے بارے میں کیا جانتی ہے۔ صرف MAC والا راستہ Layer 2 منزل کی شناخت کر سکتا ہے جبکہ پراکسی کے پاس ابھی اس کے لیے کوئی IP-to-MAC بائنڈنگ نہیں ہے۔ یہ الگ ریکارڈ ہیں، اور ایک کی جانچ دوسرے کے بارے میں کچھ نہیں بتاتی۔

اگر کوئی درست بائنڈنگ موجود ہو، تو پراکسی اپنی پالیسی کے مطابق جواب دے سکتی ہے، لیکن اس بائنڈنگ میں موجود MAC کو اب بھی فعال فارورڈنگ راستہ درکار ہے۔ اگر بائنڈنگ نہ ہو، تو جواب سے کچھ سیکھنے سے پہلے درخواست کو flooding یا نقل کے راستے سے اینڈ پوائنٹ کے کنکشن تک پہنچنا ہوگا۔

دو ریکارڈ جنہیں ملنا چاہیے

MAC راستہ بتاتا ہے کہ Ethernet پتہ کہاں رہتا ہے۔ پراکسی جدول بتاتی ہے کہ کون سا IP کس MAC پر نقش ہوتا ہے۔ جس ہوسٹ نے حال ہی میں بات نہیں کی اس کے پاس مکمل طور پر اچھا MAC راستہ ہو سکتا ہے اور کوئی قابل استعمال پراکسی اندراج نہیں بھی ہو سکتا، اور یہی وہ حالت ہے جو صحت مند کنکشن پر ریزولوشن کی ناکامی پیدا کرتی ہے۔

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

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

معیار دراصل کیا فرض کرتا ہے

RFC 9161 متحرک پراکسی سیکھنے اور نامعلوم ARP اور ND درخواستوں کے طے شدہ flooding کی وضاحت کرتا ہے۔ اس flooding کو مکمل طور پر دبانا صرف ان تعیناتیوں تک محدود ہے جن کے سیکھنے یا فراہمی کے مفروضے اسے محفوظ بناتے ہیں، جو زیادہ تر کنفیگریشن گائیڈز کے اشارے سے زیادہ تنگ شرط ہے۔

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

دبانے کی ترتیب کو اس بیان کے طور پر پڑھیں کہ fabric کیا جاننے کا وعدہ کرتی ہے۔ اگر کوئی چیز بائنڈنگ فراہم نہیں کرتی، تو یہ وعدہ شاذ و نادر بھیجنے والوں کے لیے درست نہیں۔ ترتیب شدہ دبانے کا موازنہ اس فراہمی نظام سے کریں جسے اسے کھلانا چاہیے۔ جب یہ دونوں متفق نہ ہوں، تو fabric بالکل ویسا ہی برتاؤ کرتی ہے جیسا ترتیب دیا گیا ہے، اور درست کرنے کی چیز توقع ہے۔

ریفریش، بڑھاپا اور مستقل متبادل

معیار متحرک اندراجات کے پرانے ہونے سے پہلے معاون ریفریش پروب کی وضاحت کرتا ہے۔ جواب متعلقہ bridge اور پراکسی حالت کو تازہ کرتے ہیں؛ جواب نہ ملنے سے قانونی طور پر ہٹانا اور راستہ واپس لینا ہو سکتا ہے۔ یہ کوئی خرابی نہیں جسے ہر ٹائمر کھینچ کر دبانا چاہیے۔

بڑھاپے کے ٹائمرز کو غیر معینہ مدت تک بڑھانا نظر آنے والی ناکامی کو پرانی ناکامی سے بدل دیتا ہے: fabric اس مقام کا اعلان کرتی رہتی ہے جسے ہوسٹ چھوڑ چکا ہے۔ عمل درآمد کے دستاویزی کنٹرول استعمال کریں اور ایسی عمر منتخب کریں جو اینڈ پوائنٹ کے معقول طور پر بولنے کی متوقع تعدد سے میل کھائے۔

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

اگلے ٹکٹ سے پہلے کیا ریکارڈ کریں

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

پھر فیصلہ کریں کہ تینوں میں سے کون سا چلانے کے لیے آپ تیار ہیں۔ flooding کے ساتھ دریافت، حقیقت پسندانہ عمر کے ساتھ ریفریش، یا مالک کے ساتھ فراہمی — سب قابل دفاع ہیں۔ وہ fabric جو ایک کے لیے ترتیب دی گئی ہو اور دوسرے کی طرح برتاؤ کی توقع ہو، وہیں خاموش ہوسٹ غائب ہو جاتے ہیں۔