CE پر RIP روٹ سے دور دراز VRF تک: export کہاں ہوتا ہے

RIPv2 update provider edge پر پہنچتا ہے، VRF routing table میں داخل ہوتا ہے اور وہیں رک جاتا ہے جب تک کوئی اسے واضح طور پر export نہ کرے۔ تین فیصلے ترتیب سے ہوتے ہیں اور ہر ایک prefix کو اپنی وجہ سے مسترد کر سکتا ہے۔ انہیں ایک ہی واقعہ سمجھنا ہی وہ وجہ ہے کہ لوگ غلط ڈبہ ڈھونڈتے ہیں جب کوئی دور دراز سائٹ ایسے نیٹ ورک تک نہیں پہنچ پاتی جس کا CE واضح طور پر اعلان کر رہا ہوتا ہے۔ PE کے ذریعے روٹ کی پیروی کریں اور ترتیب واضح ہو جائے گی۔

PE RIP update کے ساتھ کیا کرتا ہے

PE VRF interface پر update وصول کرتا ہے، تصدیق کرتا ہے کہ ماخذ ایک اجازت یافتہ neighbour ہے، اور prefix کو VRF routing table میں اعلان سے ماخوذ hop count کے ساتھ نصب کرتا ہے۔ وہ table ایک عام routing table ہے جس کے اپنے administrative distance اور اپنا بہترین راستہ منتخب کرنے کا عمل ہے۔ اگر CE وہی prefix دو بار مختلف metric کے ساتھ اعلان کرے تو table میں صرف بہتر بچتا ہے۔ اس مرحلے میں کوئی چیز provider backbone سے متعلق نہیں۔

اب prefix ایک ہی گاہک کے routing context کے اندر موجود ہے، جو کہیں اور قابلِ رسائی ہونے سے بہت دور ہے۔

Export ایک پالیسی فعل ہے، پروٹوکول کا نتیجہ نہیں

VRF سے نکلنے کے لیے روٹ کو اس MP-BGP عمل میں دوبارہ تقسیم کرنا ہوتا ہے جو VPN روٹس لے کر چلتا ہے، اور اسے route target extended community درکار ہوتا ہے جو بتاتا ہے کہ کون سے دور دراز VRF اسے import کر سکتے ہیں۔ RFC 4364 میں موجود معماری بالکل اسی وجہ سے ان تبادلوں کو CE-PE پروٹوکول سے الگ رکھتی ہے۔ کنارے پر RIP استعمال کرنا اس بارے میں کچھ نہیں کہتا کہ provider نیٹ ورک سے کیا گزرنا چاہیے۔

کچھ بھی کنفیگر کرنے سے پہلے export معاہدہ لکھیں: وہ گاہک prefix جو دور سے قابلِ رسائی ہونے چاہئیں، وہ روٹس جو مقامی رہنی چاہئیں، اور کوئی بھی default، زیادہ مخصوص روٹس یا مشترکہ سروس کی استثنائیں۔ اس معاہدے کا موازنہ اصل VRF سے کریں، کسی دوسرے گاہک کے اسی نام والے VRF سے نہیں۔

Import کا پہلو اپنے route targets کے ساتھ دوسری پالیسی ہے، اور موزوں export کے ساتھ ناموزوں import ایسا prefix پیدا کرتا ہے جو backbone میں موجود ہوتا ہے اور کسی دور دراز table میں ظاہر نہیں ہوتا۔

Redistribution اور explicit origination مختلف طرح برتاؤ کرتے ہیں

Redistribution ان روٹس کو لیتا ہے جو پہلے سے VRF table میں موجود ہیں اور انہیں route map سے چھان کر BGP میں نقل کرتا ہے۔ Map فیصلہ کرتا ہے کہ کون سے prefix اہل ہیں اور وہ کون سی attributes لے کر چلتے ہیں، اور metric واضح طور پر مقرر کرنا ہوتا ہے کیونکہ RIP hop count کا BGP metric کے طور پر کوئی مطلب نہیں۔ جو کچھ آپ غیر مقرر چھوڑ دیتے ہیں وہ اس طرح وراثت میں آتا ہے جو عام طور پر چھ ماہ بعد config پڑھنے والے کو حیران کرتا ہے۔

Mutual redistribution وہ جگہ ہے جہاں خاموش نقصان ہوتا ہے۔ BGP میں export شدہ prefix دوسرے redistribution point سے واپس آ سکتا ہے، اور tag یا filter کے بغیر روٹ جھولتا رہتا ہے جبکہ دونوں tables ہر لمحہ معقول دکھائی دیتی ہیں۔ واپسی کے راستے کو روکنے کے لیے topology پر بھروسہ کرنے کے بجائے کنارے پر لگائے گئے tags پر فلٹر کریں۔

Explicit origination زیادہ صاف دکھتا ہے اور غیر مشروط نہیں۔ Network statement کو عام طور پر prefix originate ہونے سے پہلے routing table میں موزوں روٹ درکار ہوتی ہے، اس لیے اعلان اسی لمحے غائب ہو جاتا ہے جب CE اس کا اعلان کرنا بند کر دے۔ یہ اکثر وہی رویہ ہوتا ہے جو آپ چاہتے ہیں، اور یہ ایسے static route جیسا نہیں جو ہمیشہ کنفیگر رہے۔ دونوں رویوں میں سے کسی ایک کو فرض کرنے کے بجائے platform کا اصل قاعدہ دیکھیں۔

بہرحال، ہر prefix کے بارے میں سوال یہ ہے کہ کون سا فعال ماخذ اسے اہل بناتا ہے اور جب وہ ماخذ غائب ہو جائے تو کیا ہوتا ہے۔

زنجیر کو چار جگہوں پر جانچیں

CE کا اعلان، VRF routing table، اپنے route target کے ساتھ VPN route table، اور دور دراز VRF میں import، اسی ترتیب سے دیکھیں۔ IOS پر اس کا مطلب CE neighbour output ہے، show ip route vrf CUSTOMER، show ip bgp vpnv4 vrf CUSTOMER، اور دور دراز PE پر وہی کمانڈ۔ IOS-XR پر مساوی output show bgp vrf CUSTOMER ipv4 unicast کے تحت ہے۔ کمانڈ کے نام مختلف ہیں، چار جانچ کے مقامات نہیں۔

جس prefix کو مسترد ہونا چاہیے اسے اتنی ہی احتیاط سے دیکھیں جتنی اسے جو گزرنا چاہیے، کیونکہ ہر چیز کی اجازت دینے والی پالیسی پہلی استثنا آنے تک درست پالیسی جیسی ہی دکھتی ہے۔ پھر withdrawal دیکھیں: CE interface بند کریں اور تصدیق کریں کہ دور دراز اندراج متوقع timer کے اندر غائب ہو جاتا ہے، رہ نہیں جاتا۔

درج کریں کہ ہر پالیسی کس کی ملکیت ہے۔ جب provider CE چلاتا ہے تو فراہم کردہ رویہ سروس کنٹریکٹ کا حصہ ہوتا ہے، اور زیرِ انتظام ڈیوائس پر مختلف پروٹوکول یا withdrawal پالیسی پہلے دستاویزات کا مسئلہ ہے اور پھر routing کا۔