دو گاہکوں کے لیے ایک ہی /24؟ VPNv4 کو RD اور لیبل درکار ہیں
دو کرایہ دار ایک ہی /24 کا اعلان صرف اسی لیے کر سکتے ہیں کہ RD ہر راستے کو اپنی شناخت دیتا ہے۔ لیبل دوسرے سوال کا جواب دیتا ہے: آگے کیسے بھیجنا ہے۔
دو کرایہ دار اپنی شاخ کو ایک ہی 10.50.0.0/24 سے نمبر دیتے ہیں، اور تبدیلی کے بعد ایک کا راستہ فراہم کنندہ کے کنارے سے غائب ہو جاتا ہے جبکہ دوسرا کام کرتا رہتا ہے۔ اُس ٹکٹ کے پیچھے سادگی عام طور پر راستہ امتیاز کنندہ (RD) چھوڑ دینا ہوتی ہے، کیونکہ ”لیبل پہلے ہی گاہک کی شناخت کرتا ہے“۔ ایسا نہیں کرتا۔ RD اور لیبل دو مختلف سوالوں کے جواب دیتے ہیں، اور یہ خلا صرف اُس وقت نظر آتا ہے جب اوور لیپ ہوتے پتے اِسے مجبور کریں۔
جہاں دو ہونے چاہئیں وہاں ایک راستہ
عام IPv4 یونیکاسٹ ایک ہی سابقے کی طرف دو راستوں کا موازنہ کرتا ہے اور بہتر نصب کرتا ہے۔ کرایہ دار A سے 10.50.0.0/24 اور کرایہ دار B سے 10.50.0.0/24 ایک ہی کلید ہیں، اس لیے ایک جیتتا ہے اور دوسرا صرف بیک اپ راستے کے طور پر بچتا ہے۔ پروٹوکول نے وہی کیا جو اُسے کہا گیا؛ کنٹرول طیارے سے کہا گیا کہ دو مختلف راستے ایک ہی شناخت کنندہ کے تحت محفوظ کرے۔
نتیجہ غلطی کی طرح نہیں بلکہ گمشدہ راستے کی طرح دکھتا ہے: جو PE مقابلہ ہار گیا وہ اب بھی اپنے کرایہ دار کو مقامی طور پر آگے بھیجتا ہے، اس لیے سائٹ کے اندر جانچ کامیاب ہوتی ہے اور سائٹوں کے درمیان جانچ ناکام ہوتی ہے۔ کسی بھی پالیسی کو چھونے سے پہلے VPNv4 جدول میں اُس سابقے کے اندراج گن لیں۔
RD ایک کلید کو دو بنا دیتا ہے
آٹھ بائٹ کا راستہ امتیاز کنندہ IPv4 سابقے سے پہلے جوڑا جاتا ہے، اور BGP جو شے اٹھاتا ہے وہ IPv4 سابقے کی بجائے VPN-IPv4 پتہ بن جاتی ہے۔ دو کرایہ دار وہی 32 بٹ رکھ سکتے ہیں کیونکہ آگے کے 64 بٹ مختلف ہیں۔ AS پر مبنی RD اور پتے پر مبنی RD کے لیے فارمیٹ اقسام موجود ہیں، اور انتخاب اصل PE کا ہے۔ PE ایک ہی AS شیئر کریں تو AS پر مبنی RD عام ہے، اور نہ کریں تو پتے پر مبنی۔
RD کو رکنیت کے ٹیگ کے طور پر نہ پڑھیں. راستہ اہداف درآمد اور برآمد کو کنٹرول کرتے ہیں اور طے کرتے ہیں کہ کون سے VRF راستہ نصب کر سکتے ہیں؛ RD صرف یہ ضمانت دیتا ہے کہ راستے کی اپنی شناخت ہے۔ ہر VRF کو اپنا RD دینا عام رواج ہے، کیونکہ یہ اُس نقشہ کو راستہ ناظر میں پڑھنے کے قابل رکھتا ہے۔
لیبل مقامی آگے بھیجنے کی ہدایت ہے
ہر اعلان MPLS لیبل بھی اٹھاتا ہے، اور اُس کا مطلب اُس راؤٹر تک محدود ہے جس نے اُسے مختص کیا۔ دوسرا PE غیر متعلقہ منزل کے لیے وہی نمبر دے سکتا ہے۔ اسی لیے لیبل گاہک کی شناخت کی جگہ نہیں لے سکتا: نمبر صرف اگلے ہاپ اور اُسے نصب کرنے والی آگے بھیجنے کی حالت کے ساتھ ہی درست ہے۔
مختص کرنے کی باریک بینی عمل درآمد اور ڈیزائن کے مطابق بدلتی ہے: کچھ پلیٹ فارم ہر VRF کے لیے ایک لیبل مختص کرتے ہیں، دیگر ہر سابقے کے لیے، اور لیبل گاہک کے بجائے آگے بھیجنے کی کارروائی کی شناخت کر سکتا ہے۔ ایک ہی منزل تک پہنچنے والے دو مختلف لیبل تضاد نہیں ہیں، اور دو PE پر ایک ہی لیبل نمبر بھی نہیں۔
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
ایک دوسرے کی جگہ کیوں نہیں لے سکتا
اعلان پڑھنے کا مطلب چار چیزوں کو ایک ساتھ دیکھنا ہے: RD کے ساتھ اہل سابقہ، راستہ اہداف، اگلا ہاپ اور لیبل۔ صارف کے پیکٹ پڑھنے کا مطلب اُس معلومات سے نصب شدہ اسٹیک دیکھنا ہے۔ صحت مند ڈیزائن دونوں جانب کا میل دکھاتا ہے، اور خراب ڈیزائن میں عام طور پر ایک جانب درست اور دوسری پرانی ہوتی ہے۔ وہی موازنہ شناخت کے مسئلے کو آگے بھیجنے کے مسئلے سے الگ کرتا ہے۔
کنٹرول طیارے اور ڈیٹا طیارے کے درمیان صاف تضاد تدریسی ذریعہ ہے، انکوڈنگ کی وضاحت نہیں۔ RFC 8277 لیبل کو لیبل شدہ NLRI کے اندر رکھتا ہے، اس لیے اعلان بذات خود بندھن اٹھاتا ہے؛ اُسے آگے بھیجنے کے لیے استعمال کرنا بعد کا، الگ مرحلہ ہے۔
جب کرایہ دار کا راستہ گم ہو جائے تو اِس ترتیب سے جانچیں: سابقے کے لیے دو VPNv4 اندراج، ہر ایک پر درست راستہ ہدف، حل ہونے کے قابل اگلا ہاپ، اور ایسا لیبل جس کی حالت وصول کرنے والے PE کے پاس ہے۔ شناخت کو آگے بھیجنے کی قدر سے درست کرنا، یا اِس کے برعکس، ایک جانچ میں کامیاب ہوگا اور اگلی میں ناکام۔