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 की सदस्यता या वापसी के रास्ते के बारे में ठोस सवाल में बदल देती है और अगले डीबग सत्र को वही पाँच कमांड उसी क्रम में दोहराने से रोकती है।