ग्राहकले VPN बन्द भएको रिपोर्ट गर्दा र यातायात टोलीले सुरुङ ठीक छ भनी रिपोर्ट गर्दा दुवै टोली एकैसाथ सही हुन सक्छन्। ट्राफिक-इन्जिनियर गरिएको LSP र MPLS L3VPN फरक प्रश्नको जवाफ दिन्छन्: एउटाले कोरभरि लेबल भएका प्याकेट सार्छ, अर्कोले प्याकेट कुन राउटिङ सन्दर्भको हो भनी निर्धारण गर्छ। दुवैलाई मिसाइयो भने बहस गोलो घुम्छ, किनकि प्रत्येक पक्ष फरक वस्तु नाप्छ र दुवै नाप मान्य छन्।

यातायात चालु र सेवा बन्द हुनु सामान्य अवस्था हो

LSP स्थापित हुन सक्छ, ट्राफिक बोक्न सक्छ र हरेक निगरानी प्रणालीमा देखिन सक्छ, तर ग्राहक सेवा प्रयोगयोग्य रहँदैन। यो संयोजनमा केही पनि विरोधाभासी छैन, किनकि टाढाको प्रिफिक्स अवस्थित छ कि छैन, आयात नीतिले त्यसलाई स्वीकार्यो कि, वा जोडिएको सर्किटले फ्रेम पास गर्दैछ कि भन्नेबारे सुरुङको कुनै मत छैन।

अलमल खुलासा गर्ने लक्षण सामान्यतया असममित हुन्छ: PE लूपब्याकबाट पिङ सफल हुन्छ, तर ग्राहकको LAN मा रहेको होस्टले केही पाउँदैन, वा उल्टो। सिद्धान्त बनाउनु अघि कुन ठेगानाहरूले काम गरे लेख्नुहोस्। तपाईं दुई फरक वस्तु परीक्षण गर्दै हुनुहुन्छ भन्ने थाहा पाएपछि अर्को कदम कसको ग्राफ सही छ भनी बहस गर्नु होइन, लेबल स्ट्याक पढ्नु हो। दुई ठेगाना, दुई मालिक, र सामान्यतया अर्कोले केही भाँच्यो भनी प्रत्येकले विश्वास गर्ने दुई फरक व्यक्ति।

स्ट्याकलाई दुई जिम्मेवारीका रूपमा पढ्नुहोस्

तलको लेबल सेवाको हो र माथिको लेबल मार्गको हो। RFC 4364 ले क्रम सरल रूपमा वर्णन गर्छ: पहिले VPN मार्गको लेबल लगाइन्छ, त्यसपछि त्यो लेबल भएको प्याकेट BGP को अर्को हपतर्फ सुरुङमार्फत पठाइन्छ, र त्यहीँ ट्राफिक-इन्जिनियरिङ सुरुङले आफ्नो लेबल माथि राख्छ।

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

टाढाको PE मा सेवा लेबलले उपचार छान्छ, जो VRF खोजी वा जडान निर्णय हुन सक्छ। त्यो लेबललाई कोर मात्र पार गर्ने लेबलसँग बदल्न सकिँदैन, र दुवै एउटै इन्टरफेसमा एउटै स्ट्याकमा देखिए पनि ती परस्पर विनिमययोग्य छैनन्।

RSVP को सफलताले के प्रमाणित गर्छ र के गर्दैन

RSVP-TE ले स्रोत आरक्षणसहित वा बिना स्पष्ट रूपमा राउट गरिएका LSP स्थापना गर्छ, जो कोरभरि प्याकेट जाने मार्गबारे ठोस र उपयोगी ग्यारेन्टी हो। यो ग्राहक मार्गबारे कथन होइन, र कन्फिगर गरिएको सुरुङ नाम मार्ग नै होइन।

RSVP को उपस्थितिले पनि टुप्पोदेखि टुप्पोसम्मको कार्यक्षमताको वाचा दिँदैन। एउटा LSP मा ब्यान्डविथ आरक्षणले जोडिएको सर्किट, ग्राहकको आफ्नै पहुँच लाइन वा टाढाको किनारमा लाइनको व्यवहारबारे केही भन्दैन। यसलाई ग्यारेन्टीका रूपमा लिनाले कसैले नसोधेका प्रश्नको आत्मविश्वासपूर्ण जवाफ दिन्छ। यदि आवश्यकता साँच्चै ब्यान्डविथ प्रतिबद्धता हो भने, यसलाई वास्तवमै लागू गर्ने टुक्राहरूबाट जोड्नुपर्छ, र LSP त्यो शृंखलाको केवल मध्य हो।

क्रममा जाँच्नुहोस्, त्यसपछि रोक्नुहोस्

यातायातबाट बाहिरतिर काम गर्नुहोस् र असफल हुने पहिलो चरणमा रोक्नुहोस्, किनकि प्रत्येक पछिको चरणले अघिल्ला टिकेका छन् भनी मान्छ। पहिले LSP स्थापित छ र सेवा प्रिफिक्सको फर्वार्डिङ प्रविष्टि साँच्चै त्यसैतर्फ संकेत गर्छ भनी पुष्टि गर्नुहोस्। त्यसपछि VPN मार्ग सही तालिकामा छ, यसको लेबल बाइन्डिङ उपस्थित छ र आयात नीतिले यसलाई स्वीकार्यो भनी पुष्टि गर्नुहोस्। त्यसपछि जडान पुष्टि गर्नुहोस्: इन्टरफेस, इन्क्याप्सुलेसन र जहाँ लागू हुन्छ त्यो सम्झौताको VLAN पहिचानकर्ता।

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

कमाण्ड सिन्ट्याक्स प्लेटफर्मअनुसार फरक पर्छ, त्यसैले ती चार लाइनलाई स्क्रिप्ट होइन, चार प्रश्न मान्नुहोस्। महत्त्वपूर्ण कुरा प्रत्येकले फरक वस्तुसँग सोध्छ, र त्यसैले असफलता विशेष मालिकतर्फ संकेत गर्छ।

एउटा अनुमत अनुरोध पछ्याउनुहोस् र राम्रो प्रमाण राख्नुहोस्

नीतिले अनुमति दिएको एउटा वास्तविक ग्राहक अनुरोध र त्यसको जवाफसँग अन्त्य गर्नुहोस्। टुप्पोदेखि टुप्पोसम्म चल्ने एउटा प्रवाहले एक पृष्ठ काउन्टर पढाइभन्दा बढी टुङ्गो लगाउँछ, र यसले प्रत्येक भागलाई अलग होइन, संयोजनलाई परीक्षण गर्छ।

पछिको चरण असफल हुँदा यातायात पुनः निर्माण गर्नुको सट्टा सफल LSP अवलोकन सुरक्षित राख्नुहोस्। चलिरहेको सुरुङ पुनः निर्माण गर्दा अनुपस्थित टाढाको प्रिफिक्स, गलत VRF जडान वा गन्तव्य पहुँच नियम सुधारिँदैन, र यातायात स्वस्थ छ भनी सुरुमा भनेको प्रमाण नष्ट हुन्छ।

सम्बन्धित लेखहरू