MPLS L3VPN لیب پنگ نہیں کر رہی؟ یہ پانچ چھلانگیں جانچیں

گاہک کے دو راؤٹر، provider edge آلات کا ایک جوڑا اور ایک پنگ جو بغیر غلطی کے پیغام کے مر جاتا ہے۔ ایک چھوٹی MPLS L3VPN لیب میں خرابی تقریباً ہمیشہ پانچ کنٹرول پوائنٹس میں سے کسی ایک پر بیٹھتی ہے، اور ہر ایک کے پاس ایسا کمانڈ ہے جو دکھاتا ہے کہ انحصار کام کر رہا ہے یا غائب ہے۔ غلطی یہ ہے کہ ہر بار پنگ ناکام ہونے پر BGP دوبارہ شروع کیا جائے بجائے اس کے کہ انحصاروں کو ترتیب سے جانچا جائے۔ اگر آپ سیدھا VRF کنفیگریشن پر چھلانگ لگائیں تو دو آلات آگے کے حل نہ شدہ اگلی چھلانگ سے شروع ہونے والے مسئلے پر گھنٹہ ضائع کر سکتے ہیں۔

فہرست کو نیچے سے اوپر تک کام کریں۔ جو کنٹرول پوائنٹ پاس ہو جائے وہ پاس رہتا ہے، اور پہلی ناکامی وہ ہے جسے ڈیبگ کرنے کے قابل ہے۔

پہلا کنٹرول پوائنٹ: PE ایک دوسرے تک پہنچتے ہیں

ہر PE کو دوسرے PE کے loopback تک راستہ درکار ہے، اور یہ راستہ کسی حقیقی چیز کے ذریعے حل ہونا چاہیے۔ interior gateway protocol وہاں تک جانے کا معمول کا راستہ ہے، لیکن جامد راستہ بھی کام کرتا ہے جب تک کہ تکرار والی تلاش کسی زندہ adjacency پر اترے۔ IOS طرز کے آلات پر، show ip route 10.0.0.2 اور پھر show ip cef 10.0.0.2 دکھاتے ہیں کہ prefix موجود ہے یا نہیں اور اس کے پیچھے حل شدہ adjacency ہے یا نہیں۔ جدول میں موجود راستہ جس کے پیچھے adjacency نہ ہو، رسائی نہیں ہے۔

دونوں سمتوں کو جانچیں۔ غیر متناسب IGP لاگت، غلط طرف passive interface یا loopback کو فلٹر کرنے والا distribute list ہر ایک صرف ایک سمت توڑتا ہے، اور ایک سمت سیشن کو مارنے کے لیے کافی ہے۔ اگر loopback پنگ کرتے ہیں مگر BGP سیشن Active میں کھڑا ہے، تو کسی اور چیز کو چھونے سے پہلے update source دیکھیں۔

دوسرا کنٹرول پوائنٹ: لیبل کا راستہ موجود ہے

دور کے loopback تک IP راستہ ثابت نہیں کرتا کہ ٹرانسپورٹ لیبل لگائے گا۔ LDP ڈیزائن میں تصدیق کریں کہ دور کے loopback کا مقامی اور دور کا بائنڈنگ دونوں موجود ہیں اور باہر جانے والا لیبل forwarding جدول میں نظر آتا ہے۔ show mpls ldp bindings 10.0.0.2 32 لیبل کے جوڑے دکھاتا ہے، اور show mpls forwarding-table 10.0.0.2 دکھاتا ہے کہ line card واقعی کیا لگائے گا۔ جب دوسرا کمانڈ کوئی لیبل نہ دکھائے یا IP پر واپس گر جائے، تو ٹرانسپورٹ VPN ٹریفک کو ویسے نہیں لے جا رہا جیسے ڈیزائن فرض کرتا ہے۔

یہ فرق اس بات سے آتا ہے کہ MPLS کس طرح forwarding state کو منزل کے prefix سے الگ کرتا ہے، یہی وہ ماڈل ہے جو RFC 3031 میں بیان کیا گیا ہے۔ اگر آپ کی لیب LDP کی بجائے RSVP-TE یا BGP سے متصل لیبل استعمال کرتی ہے، تو اس میکانزم کی اپنی حالت جانچیں; یہ فرض کرنا کہ LDP ہر انڈرلیے لیبل تقسیم کرتا ہے، بھوت بگ کے پیچھے بھاگنے کا عام طریقہ ہے۔ ٹوٹا ہوا لیبل راستہ عموماً بعد میں ایسے VPN راستے کے طور پر ظاہر ہوتا ہے جو موجود ہے مگر ناقابل استعمال ہے۔

تیسرا کنٹرول پوائنٹ: VPN راستہ صحیح سلامت پہنچا

بالکل گاہک کے prefix کے VPNv4 یا VPNv6 راستے کو دیکھیں، سیشن کے خلاصے کو نہیں۔ show bgp vpnv4 unicast all 10.10.1.0/24 کو route distinguisher، دور کے PE کے loopback پر مقرر next hop اور ایک لیبل دکھانا چاہیے۔ اگر prefix غائب ہے تو پہلا شبہ ماخذ PE پر export پالیسی یا وصول کرنے والے PE پر import پالیسی ہے، اور route target ہی معمول کا مجرم ہیں۔

route target کی جانچ BGP وصولی سے الگ پڑھیں۔ راستہ درست next hop کے ساتھ آ سکتا ہے اور پھر بھی VRF میں نہ اترے کیونکہ importtarget مطابق نہیں۔ وصول کرنے والے PE پر show ip route vrf CUSTOMER 10.10.1.0 وہ امتحان ہے جس کا وزن ہے; BGP جدول صرف یہ ثابت کرتا ہے کہ راستہ کنٹرول پلین عبور کر گیا۔

چوتھا کنٹرول پوائنٹ: interface VRF میں ہے

route distinguisher اور route target کے ساتھ VRF تعریف کسی interface کو اس میں منتقل نہیں کرتی۔ CE کی طرف والے interface کو VRF مختص کرنے کی ضرورت ہے، اور show ip vrf interfaces یا show ip interface brief اسے درست مثال کے تحت فہرست کرنا چاہیے۔ یہی وہ کنٹرول پوائنٹ ہے جہاں کاپی شدہ کنفیگریشن سب سے زیادہ غلط ہوتی ہے، کیونکہ VRF بلاک مکمل نظر آتا ہے جبکہ interface اب بھی عالمی جدول میں بیٹھا ہے۔

پھر تصدیق کریں کہ PE نے مقامی گاہک کا prefix اس VRF میں سیکھا ہے اور CE کے پاس کنکشن کے ذریعے واپسی کا راستہ ہے۔ CE پر PE کی طرف اشارہ کرنے والا جامد default لیب کے لیے کافی ہے، بشرطیکہ PE کے VRF میں CE کے LAN تک راستہ ہو۔ اگر دونوں میں سے کوئی نصف غائب ہو تو پنگ کسی بھی لیبل کے لگنے سے پہلے ناکام ہو جاتا ہے۔

پانچواں کنٹرول پوائنٹ: جواب گھر کا راستہ ڈھونڈ لیتا ہے

آگے جانے والے پیکٹ اور پھر واپس آنے والے پیکٹ کا سراغ لگائیں، کیونکہ وہ مختلف جدولیں استعمال کرتے ہیں۔ داخل ہونے والے PE پر گاہک کا ماخذ VRF کے اندر دور کے prefix تک دور کے لیبل کے ساتھ حل ہونا چاہیے۔ خارج ہونے والے PE پر منزل اسی VRF کے اندر CE کی طرف والے interface تک حل ہونی چاہیے۔ خود PE سے بھیجا گیا پنگ ثبوت نہیں ہے: یہ عالمی جدول یا کسی دوسرے ماخذ پتے سے باہر جا سکتا ہے، اسی لیے ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 وہ امتحان ہے جو چلانا چاہیے۔

میزبانوں کے فائر وال، reverse-path filtering اور CE کی access فہرستیں پھر بھی لاگو ہیں۔ اگر آگے کا راستہ کام کرے اور جواب مر جائے تو مسئلہ واپسی کی طرف راستے یا فلٹر میں ہے، MPLS ٹرانسپورٹ میں نہیں۔

ہر کنٹرول پوائنٹ کے لیے ایک سطر رکھیں جو پہلا ناکام انحصار بتائے۔ وہ سطر گاہک کے پنگ نہ کر سکنے کی شکایت کو رسائی، لیبل کی حالت، راستہ درآمد، interface کی رکنیت یا واپسی کے راستے کے بارے میں ٹھوس سوال میں بدل دیتی ہے اور اگلی ڈیبگ نشست کو وہی پانچ کمانڈز اسی ترتیب سے دہرانے سے روکتی ہے۔