ایک ہی سائٹ کے اندر وہی iESI، سائٹوں کے درمیان منفرد: Junos سلائی

گیٹ ویز کے دو جوڑے دو ڈیٹا سینٹرز کی خدمت کرتے ہیں، اور کسی کو فیصلہ کرنا ہے کہ ڈیزائن کو کتنے interconnect ESI اقدار درکار ہیں۔ جواب ہر گیٹ وے گروپ کے لیے ایک ہے، ہر fabric کے لیے ایک نہیں اور ہر گیٹ وے کے لیے ایک نہیں۔ ایسا غلط کرنے سے ایسا fabric بنتا ہے جو ترتیب شدہ دکھتا ہے اور غلط forwarder منتخب کرتا ہے، یا ایسی دو سائٹیں ضم ہو جاتی ہیں جنہیں الگ رہنا تھا۔ اصول اور اس کے استثنات گیٹ وے فہرست کے ساتھ لکھنے کے قابل ہیں۔

دو دائرے، دو اصول

سائٹ کے اندر، زائد interconnect گیٹ ویز ایک multihomed اختتامی نقطہ کے طور پر کام کرتے ہیں، اس لیے وہ ایک ہی interconnect ESI بانٹتے ہیں۔ ان کے peers کو دو آزاد کے بجائے ایک منطقی رکن دیکھنا چاہیے۔ مشترکہ قدر کا پورا مقصد یہی ہے۔

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

سائٹ کے اندر: گروپ کے لیے ایک شناخت

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

حمایت یافتہ ماڈل all-active ہے۔ وہی حوالہ اس سلائی شناخت کے لیے single-active آپریشن، خودکار طور پر ماخوذ LACP شناخت کنندگان اور source-bmac اختیارات کو خارج کرتا ہے، اس لیے ان میں سے کسی کو فرض کرنے والے ڈیزائن کا شناخت کنندہ منتخب کرنے سے پہلے ہی جائزہ لینا ضروری ہے۔ یہ پابندی ڈیزائن ان پٹ ہے، حاشیہ نہیں۔

سائٹوں کے درمیان: مختلف اقدار، یا جان بوجھ کر انضمام

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

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

peer بیان شناخت کا حصہ ہے

گروپ کا ہر گیٹ وے اپنے مقامی peers کو loopback پتے کے مطابق فہرست کرتا ہے، اور وہ تعلق انفرادی MAC-VRF کے اندر نہیں بلکہ عالمی EVPN سطح پر رہتا ہے۔ اسے غلط درجہ بندی میں رکھنا ایسی ترتیب بنانے کا عام طریقہ ہے جو commit ہوتی ہے مگر کبھی گروپ نہیں بناتی۔ حوالہ درجہ بندی ایک بار پڑھیں، پھر اس پر قائم رہیں۔

بیان کا نام بھی منتقل ہوا۔ Juniper نے 24.2R1 میں interconnect peer-gateways بیان کا نام بدلا اور 24.4R1 میں ڈیٹا سینٹر interconnect کے لیے interconnect مخصوص شکل بحال کی۔ اس لیے درمیانی ریلیز سے لیا گیا اسنیپٹ ایسا نام استعمال کر سکتا ہے جو تعینات شدہ ورژن قبول نہیں کرتا، یا اس کے برعکس۔ اسنیپٹ کس ریلیز سے آیا یہ اسنیپٹ کے ساتھ ہی درج کریں۔

iESI بانٹنا کیا نہیں کرتا

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

یہ peers کی رسائی یا designated forwarder کے انتخاب کو بھی ثابت نہیں کرتا۔ عام حالت میں unicast اور مطلوبہ broadcast اور multicast رویوں کی جانچ کریں، پھر ایک گیٹ وے ہٹا کر دہرائیں تاکہ بچا ہوا رکن گروپ اکیلا اٹھائے۔

وہی دوسرا رن ثابت کرتا ہے کہ گروپ حقیقی ہے۔

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