MPLS شاخ روٹنگ: CE کیا سیکھتا ہے اور کس سے

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

راستے پر ایک پیکٹ کا پیچھا کرنا یہ دیکھنے کا تیز ترین طریقہ ہے کہ کون سا حصہ گاہک کی ذمہ داری ہے اور کون سا حصہ سروس کا ہے۔

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

ہر ہاپ کا کام کہاں ختم ہوتا ہے

CE-A کو دور کی LAN کے لیے ایسا راستہ درکار ہے جو اس کے مقامی فراہم کنندہ رابطے کی طرف اشارہ کرے، دور کی شاخ کے WAN پتے کی طرف نہیں۔ پھر فراہم کنندہ VPN روٹنگ حالت استعمال کرتے ہوئے پیکٹ کو اپنے کور سے گزارتا ہے، اور CE-B اسے منزل کی LAN پر پہنچاتا ہے۔ کسی بھی مرحلے پر میزبان کو لیبل، VRF یا دوسری طرف کے انٹرنیٹ سرکٹ کو سمجھنے کی ضرورت نہیں۔

ٹکٹوں میں بار بار آنے والی غلطی یہ ہے کہ شاخ A میں شاخ B کے WAN پتے کو اگلے ہاپ کے طور پر ترتیب دیا جائے۔ دونوں شاخوں نے ایک ہی سروس خریدی ہے، اس لیے لگتا ہے کہ وہ پڑوسی ہونی چاہئیں۔ لیکن نہیں ہیں: اگلا ہاپ اسی روٹنگ ڈیزائن سے قابل رسائی ہونا چاہیے جو واقعی آپ کے پاس ہے، اور دور کا CE عام طور پر ان آلات کے پیچھے کئی ہاپ دور ہوتا ہے جن کا انتظام آپ نہیں کرتے۔ اس مفروضے پر بنایا گیا جامد راستہ فعال دکھائی دیتا ہے اور کسی چیز میں حل نہیں ہوتا، جو غائب راستے سے بھی بدتر ہے کیونکہ جدول میں یہ درست لگتا ہے۔

RFC 4364 گاہک اور فراہم کنندہ کناروں کے درمیان تبادلے کو فراہم کنندہ کی VPN راستوں کی تقسیم سے الگ کرتا ہے، اور یہی وہ حد ہے جس پر یہ رہنما ہے۔ گاہک کا کام اپنے کنارے کو بتانا ہے کہ وہ کیا پہنچا سکتا ہے اور وہ رسائی قبول کرنا ہے جو سروس بدلے میں پیش کرتی ہے۔

حوالگی کو کس بات پر متفق ہونا چاہیے

طریقہ فراہم کنندہ کے ساتھ مل کر منتخب کریں، اس کے گرد نہیں۔ جامد راستے، BGP یا CE اور PE کے درمیان روٹنگ پروٹوکول معاہدہ سب جائز ہیں، اور OSPF کے پاس ایسی حوالگی کے لیے متعین MPLS VPN ماڈل ہے۔ ان میں سے کوئی بھی دو دور کے گاہک کناروں کے درمیان غیر متعین فراہم کنندہ کور کے ذریعے OSPF ہمسائیگی بنانے کی وجہ نہیں ہے، کیونکہ یہ ایسا ڈیزائن ہے جس پر فراہم کنندہ متفق نہیں ہوا اور اس کا ساتھ نہیں دے سکتا۔

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

پھر جواب کا پیچھا کریں۔ شاخ B کو ماخذ LAN کی طرف واپسی کے لیے راستہ درکار ہے، اور وصول کرنے والی طرف کے میزبان کو اپنا گیٹ وے اور اپنی سروس کی اجازتیں درکار ہیں۔ CE-A پر ظاہر ہونے والا راستہ آدھے سفر کو قائم کرتا ہے، اور یہی آدھا سفر وجہ ہے کہ ping ٹیسٹ کی ایک سمت صحت مند لگتی ہے جبکہ ایپلیکیشن اب بھی ناکام ہوتی ہے۔

قبولیت سے پہلے دونوں حوالگیاں جانچیں

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

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

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

جانیں کہ سروس کیا فراہم نہیں کرتی

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

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

آخر میں، سائٹ کی روٹنگ ترتیب کے ساتھ سروس ماڈل لکھا رکھیں۔ ذیلی نیٹ ورک شامل کرنے والے اگلے انجینئر کو پڑھ سکنا چاہیے کہ کون سے سابقے اعلان ہوتے ہیں، انہیں کون قبول کرتا ہے اور متوقع واپسی راستہ کیا ہے: BGP/MPLS IP VPN تصریح اس سب کے پیچھے موجود ماڈل کا حوالہ ہے۔