کیا VPNv4 کو کور میں MPLS کی ضرورت ہے؟ ضروری نہیں
BGP VPNv4 روٹ تقسیم کے سیاق پر بات کرتا ہے، فارورڈنگ راستے پر نہیں۔ درآمد، اگلے ہاپ کا حل اور وہ encapsulation الگ کریں جو آپ چلا سکتے ہیں۔
دو راؤٹرز کے درمیان VPNv4 ایڈریس فیملی آن کرنا صرف روٹ تقسیم کا سیاق بناتا ہے، اس سے زیادہ کچھ نہیں۔ یہ فارورڈنگ راستہ نصب نہیں کرتا اور یہ نہیں بتاتا کہ کون سا encapsulation گاہک کے پیکٹ کو دور کے آخری نقطے تک لے جائے گا۔ جب یہ دو حقائق الگ ہو جائیں، تو سوال «کیا اسے کور میں MPLS کی ضرورت ہے» پلیٹ فارم کی معاونت کردہ ڈیٹا پلین کے بارے میں زیادہ تنگ اور جواب دے سکنے والا سوال بن جاتا ہے۔
ایڈریس فیملی اصل میں کس پر بات کرتی ہے
ملٹی پروٹوکول BGP AFI 1 اور SAFI 128 کے تحت VPNv4 نیٹ ورک لیئر کی رسائی کی معلومات اٹھاتا ہے، اور ہر اندراج روٹ امتیاز کنندہ کو سابقے اور لیبل کے ساتھ جوڑتا ہے۔ سیشن اس پر بات کرتا ہے کہ دونوں فریق وہ معلومات encode اور decode کر سکتے ہیں۔ جس پر یہ بات نہیں کرتا وہ ڈیٹا پلین ہے۔ اس پیراگراف کے بعد سب کچھ فارورڈنگ سے متعلق ہے، اور ان میں سے کچھ بھی سیشن کے اٹھنے سے طے نہیں ہوتا۔
لہٰذا کامیاب سیشن کنٹرول پلین کی صلاحیت کا ثبوت ہے، فارورڈنگ کا نہیں۔ راؤٹر ہزاروں VPNv4 اندراجات رکھ سکتا ہے اور پھر بھی ہر گاہک کا پیکٹ گرا سکتا ہے، اور اسی وجہ سے دو ناکامی کی اقسام شروع ہی سے گڈمڈ ہو جاتی ہیں۔
NLRI میں لیبل پر توجہ دیں۔ یہ سروس لیبل ہے، VRF کے اندر سابقے سے بندھا ہوا ہے، اور جب پیکٹ آؤٹ لیٹ آخری نقطے تک پہنچتا ہے تو اس کا فارورڈنگ کردار ہوتا ہے۔ کوئی بھی ٹرانزٹ ڈیوائس اسے پڑھتی ہے یا نہیں، یہ الگ ڈیزائن فیصلہ ہے۔
وصولی، درآمد اور فارورڈنگ تین مراحل ہیں
روٹ وصول کرنا، اسے استعمال کرنے کی اجازت ہونا اور اس کے ساتھ فارورڈ کر سکنا ڈیوائس کے مختلف حصے انجام دیتے ہیں۔ BGP جو سنتا ہے اسے محفوظ کرتا ہے؛ درآمد کی پالیسی اور روٹ ہدف کی مطابقت طے کرتی ہے کہ کون سا VRF اس پر غور کر سکتا ہے؛ پھر فارورڈنگ پلین کو اعلان کردہ اگلے ہاپ کو ایسی چیز میں حل کرنا ہوتا ہے جسے وہ واقعی تار پر دھکیل سکے۔
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
سب سے حیران کن ناکامیاں اسی درمیانی مرحلے میں رہتی ہیں۔ روٹ BGP جدول میں موجود، درست اور حتیٰ کہ بہترین بھی ہو سکتا ہے، جبکہ VRF روٹ جدول خالی رہتا ہے کیونکہ کوئی روٹ ہدف درآمد فہرست سے مطابقت نہیں رکھتا تھا۔ کچھ بھی پروٹوکول نقص درج نہیں کرتا، کیونکہ کوئی پروٹوکول نقص پیش نہیں آیا۔
آخری مرحلہ وہ ہے جہاں پلیٹ فارم کی معاونت ظاہر ہوتی ہے۔ انڈرلے میں قابل رسائی اگلا ہاپ خودکار طور پر VPN سروس ٹرانسپورٹ کے طور پر حل نہیں ہوتا، اور ڈیوائس مخصوص ٹنل قسم، مخصوص لیبل آپریشن یا دونوں کا مطالبہ کر سکتی ہے۔ حل کی حالت پڑھنا روٹ تعداد پڑھنے سے زیادہ معلوماتی ہے۔
ایک IP کور ایسا اسٹیک اٹھا سکتا ہے جسے وہ کبھی سوئچ نہیں کرتا
محفوظ رکھنے کے قابل فرق «کور MPLS نہیں چلاتا» اور «سروس میں کہیں لیبل نہیں» کے درمیان ہے۔ یہ الگ دعوے ہیں، اور صرف پہلا ٹرانزٹ ڈیوائسز کے بارے میں ہے۔ RFC 4023 IP یا GRE ٹنلوں کے ذریعے MPLS اٹھانے کی تعریف کرتا ہے، اور یہی طریقہ کار دوسرے دعوے کو مکمل IP کور پر ممکن بناتا ہے۔
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulٹرانزٹ راؤٹرز بیرونی IP منزل کی بنیاد پر فارورڈ کرتے ہیں اور انہیں نہ گاہک سابقوں کی ضرورت ہے نہ مقامی لیبل سوئچنگ کی۔ دور کے سرے پر بیرونی ٹنل ہٹا دی جاتی ہے اور سروس لیبل اپنا کام دوبارہ شروع کرتا ہے۔ کور نے ایک غیر شفاف پے لوڈ منتقل کیا، اور IP نیٹ ورک اسی میں اچھا ہے۔
یہ ڈیزائن آپ کو جو نہیں دیتا وہ عالمگیر ضمانت ہے۔ یہ ثبوت نہیں کہ ہر راؤٹر ہر VPNv4 اگلے ہاپ کو کسی بھی GRE انٹرفیس سے حل کرتا ہے، اور نہ یہ کام کرتی مقامی MPLS ترتیب حذف کرنے کی وجہ ہے۔ یہ عالمگیر دعوے کے خلاف مثال ہے، اور عملی سوال پلیٹ فارم تک مقامی رہتا ہے۔ اس سوال کو پروٹوکول قاعدے کے بجائے پلیٹ فارم حد کے طور پر درج کریں۔
بکس پر زنجیر ٹوٹنے تک چلیں
موصول شدہ روٹ سے شروع کریں اور پہلے اس مرحلے پر رکیں جو ناکام ہو، کیونکہ پچھلا مرحلہ ٹوٹا ہونے پر اگلے مراحل کی تشخیص نہیں ہو سکتی۔ عام عمل میں چار کمانڈز اس کا بیشتر حصہ ڈھانپ لیتے ہیں۔
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aانہیں چار آزاد جانچ کے بجائے ترتیب کے طور پر پڑھیں۔ پہلا تصدیق کرتا ہے کہ فیملی فعال ہے اور ساتھی روٹس کا تبادلہ کر رہا ہے؛ دوسرا دکھاتا ہے کہ سابقہ قابل استعمال اگلے ہاپ کے ساتھ آیا یا نہیں؛ تیسرا درآمد کی اہلیت ثابت کرتا ہے؛ چوتھا دکھاتا ہے کہ فارورڈنگ پلین نے اس کے ساتھ لیبل یا ٹنل باندھا یا نہیں۔
پھر کام کے بوجھ کا راستہ دونوں سمتوں میں جانچیں، ایسے MTU کے ساتھ جو encapsulation برداشت کرے۔ GRE ہیڈر بائٹس شامل کرتا ہے، اور چھوٹے probe سے گزرنے والا راستہ پورے سائز کے پیکٹوں پر صرف ایک سمت میں ناکام ہو سکتا ہے، جو ٹرانسپورٹ نقص کے بجائے ایپلیکیشن نقص جیسا لگتا ہے۔
دو آپریشنل نوٹس چکر بند کرتے ہیں۔ GRE encapsulation ہے، رازداری نہیں، اس لیے غیر قابل اعتماد ٹرانزٹ نیٹ ورک کو مفروضے کے بجائے اوپر معاون سیکیورٹی انتظام چاہیے۔ اور ڈیزائن جائزے سے پہلے درج کریں کہ پلیٹ فارم واقعی کون سا encapsulation معاونت کرتا ہے، کیونکہ وہی ایک جواب طے کرتا ہے کہ صرف-IP کور درست انتخاب ہے یا ایسی منصوبہ بندی جو فارورڈ نہیں کر سکتی۔