all-active EVPN پر Linux کا فعال-بیک اپ بانڈ: کیا ٹوٹتا ہے

سرور پر فعال-بیک اپ بانڈ رکھیں، فیبرک پر all-active ایتھرنیٹ سیگمنٹ رکھیں، اور واپس آنے والی ٹریفک کا آدھا حصہ ایک بھی خرابی کاؤنٹر ہلے بغیر غائب ہو سکتا ہے۔ دونوں میں سے کوئی ترتیب بذات خود غلط نہیں۔ مسئلہ ان کے درمیان حوالگی میں ہے، جہاں ایک فریق ایک ہی پورٹ چنتا ہے اور دوسرا فرض کرتا ہے کہ جڑا ہوا ہر پتہ پہنچا سکتا ہے۔ ہر سمت میں ایک فریم کی پیروی کریں اور عدم مطابقت واضح ہو جاتی ہے۔

فعال-بیک اپ آنے والے فریم کے ساتھ کیا کرتا ہے

بانڈنگ موڈ 1 بھیجنے کے راستے میں بالکل ایک غلام رکھتا ہے اور موجودہ ناکام ہونے پر ہی اسے بدلتا ہے۔ وہ حصہ سب کو معلوم ہے۔ یہاں اہم بات وصولی کا پہلو ہے: کرنل فریم اسٹیک کو صرف اسی وقت دیتا ہے جب وہ فعال غلام پر آئے، اور کسی دوسرے غلام پر ظاہر ہونے والے فریم پھینک دیتا ہے۔ یہ all_slaves_active ترتیب اسی قاعدے کو نرم کرنے کے لیے ہے، اور بطور طے شدہ یہ بند ہے۔ ip -d link show bond0 موڈ کے ساتھ موجودہ قدر چھاپتا ہے۔

/proc/net/bonding/bond0 فعال غلام کا نام دیتا ہے اور ہر غلام کے لنک کی حالت بتاتا ہے۔ کون سی پورٹ اس وقت ٹریفک اٹھا رہی ہے، اس کے لیے وہی فائل واحد دیانتدار ذریعہ ہے۔

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

all-active ملٹی ہومنگ دور کے اگلے ہاپ کے ساتھ کیا کرتی ہے

EVPN ملٹی ہومنگ ایسے پتوں کے مجموعے کی وضاحت کرتی ہے جو ایک ایتھرنیٹ سیگمنٹ بانٹتے ہیں، جو ESI سے پہچانا جاتا ہے، اور وہ سیگمنٹ باقی فیبرک کو اعلان کرتی ہے۔ all-active ماڈل میں دور کے ساتھی سیگمنٹ کے پتوں کے لیے ایک سے زیادہ اگلے ہاپ نصب کرتے ہیں۔ سرور کی طرف یونیکاسٹ پھر کسی بھی پتے پر پہنچ سکتا ہے، اور فیبرک ہر بہاؤ کے لیے آزادانہ چن سکتا ہے۔ یہی ڈیزائن کا پورا مقصد ہے، اور یہی وہ مفروضہ بھی ہے جو سرور کے بانڈ کو پورا کرنا ہے۔

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

جہاں دونوں انتخاب متفق نہیں ہوتے

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

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

بیک اپ کیبل صحت مند کیوں دکھتی رہتی ہے

ٹریفک نہ اٹھانے والی کیبل بھی لنک اپ بتاتی ہے، اور بانڈ میں اسٹینڈ بائی غلام تیار دکھنے کے لیے ہی بنایا جاتا ہے۔ آپریٹر اسے فالتو پن سمجھتے ہیں اور سوال پوچھنا چھوڑ دیتے ہیں۔

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

دونوں سمتوں میں ترسیل جانچیں، لنک کی حالت نہیں

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

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

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