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 सदस्यता वा फर्कने बाटोबारे ठोस प्रश्नमा बदल्छ र अर्को डिबग सत्रलाई त्यही पाँच आदेश त्यही क्रममा दोहोर्‍याउनबाट रोक्छ।