VRF मा हराएको रुट: स्थानीय, VPNv4 कि फर्वार्डिङ तालिका?
VRF मा नभएको, VPNv4 मा नभएको र CEF मा स्थापना नभएको प्रिफिक्स तीन फरक खराबी हुन्। रुट-लक्ष्य सम्पादन गर्नुअघि तालिकाहरू क्रममा पढ्नुहोस्।
एक ग्राहक भन्छन् कि रुट-लक्ष्य परिवर्तनपछि प्रिफिक्स हरायो, र उनीहरूले पठाउने पहिलो स्क्रिनसट सामान्यतया गलत तालिका हुन्छ। तीन फरक तालिकाले तीन फरक प्रश्नको जवाफ दिन्छन्: प्रिफिक्स VRF भित्र छ कि छैन, त्यो VPNv4 रुटका रूपमा घोषित र आयात भयो कि भएन, र फर्वार्डिङ प्रविष्टि साँच्चै स्थापना भयो कि भएन। तिनीहरूलाई क्रमबाहिर पढ्दा विश्वासिलो तर गलत निष्कर्ष निस्कन्छ। यो पुस्तिकाले एक स्थानीय र एक टाढाको प्रिफिक्सलाई तीनै तालिकाबाट क्रममा लैजान्छ र यसलाई सुरु गर्ने RT परिवर्तनका लागि रोलब्याक योजनासँग टुंग्याउँछ।
प्रिफिक्स र त्यो पर्ने तालिकाको नाम भन्नुहोस्
केही टाइप गर्नुअघि दुई प्रिफिक्स लेख्नुहोस्। एउटा ग्राहक साइटमा स्थानीय हो, जोडिएको इन्टरफेस वा CE घोषणाबाट सिकिएको। अर्को टाढाको हो, र प्रदायकको ब्याकबोन हुँदै आउने अपेक्षा छ। तिनीहरू एउटै VRF मा फरक बाटोबाट पस्छन्, र एउटामा खराबीले अर्कोबारे केही भन्दैन।
| Table | Question it answers | Command |
|---|---|---|
show ip vrf CUST-A | Which RTs are attached for import and export | Read the RT lists before anything else |
show ip route vrf CUST-A | Is the prefix present in this VRF at all | Local and imported routes both appear |
show ip bgp vpnv4 all | Was the NLRI advertised and retained | Keyed by route distinguisher |
show ip cef vrf CUST-A | Was a forwarding entry installed | Proves a usable path, not just a BGP entry |
दुई पहिचानकर्ताबीचको भिन्नता स्पष्ट राख्नुहोस्, किनकि यी टिकटहरूमा धेरैजसो अलमल त्यहींबाट आउँछ। रुट विभाजक VPNv4 NLRI को भाग हो र अन्यथा समान ग्राहक प्रिफिक्सहरूलाई ब्याकबोनभरि अद्वितीय बनाउन अवस्थित छ। रुट-लक्ष्य गुणका रूपमा बोकिने विस्तारित समुदाय हो, र आयात-निर्यात नीति त्यसैसँग मिल्छ। त्यो विभाजकको दोस्रो नाम होइन र त्यो ग्राहकका प्याकेटमा बोकिँदैन।
चरण 1: प्रिफिक्स VRF मा छ भनी प्रमाणित गर्नुहोस्
स्थानीय दृश्यबाट सुरु गर्नुहोस्, त्यसपछि आयात नियन्त्रण गर्ने RT बाट। स्थानीय प्रिफिक्स यहाँ छैन भने माथिको केही पनि दोषी हुन सक्दैन:
show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-Aजोडिएको वा स्थिर देखिने प्रिफिक्स स्थानीय रूपमा सिकिएको हुन्छ, र त्यसको उपस्थितिले निर्यात भयो कि भएन भन्नेबारे केही भन्दैन। यो कामको प्रवाहमा सबैभन्दा सामान्य गलत पढाइ यही हो: स्वस्थ VRF तालिका केवल स्थानीय सिकाइको प्रमाण हो। निर्यातको पाटो छुट्टै प्रश्न हो, जसको जवाफ छिमेकीको दृश्य र जोडिएको निर्यात लक्ष्यले दिन्छ।
यहाँ हुँदै VRF मा रहेका RT सूचीहरू जाँच्नुहोस्। इच्छित आयात लक्ष्य सूचीमा छैन भने तलको सबै अप्रासंगिक हुन्छ। त्यो छ तर टाढाको PE ले निर्यात गर्नेभन्दा फरक छ भने, एउटै प्याकेट क्याप्चर नखोली खराबी भेट्टाउनुभयो।
चरण 2: VPNv4 तालिका र त्यसका लक्ष्यहरू पढ्नुहोस्
VPNv4 तालिकाले नियन्त्रण तहले वास्तवमा के साटासाट गर्यो देखाउँछ। सही विभाजकमुनि टाढाको प्रिफिक्स खोज्नुहोस्, त्यसपछि त्यसमा जोडिएका समुदाय हेर्नुहोस्:
show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routesसही रुट-लक्ष्य भएको तर स्थानीय स्थापना नभएको प्रविष्टि पहुँचतर्फ होइन, आयात नीति वा रुट छनोटतर्फ सङ्केत गर्छ। VPNv4 तालिकामा कहिल्यै नदेखिने प्रविष्टि माथितर्फ सङ्केत गर्छ: स्रोत PE ले निर्यात नगरेको हुन सक्छ, वा सत्रले ठेगाना परिवार बोक्दैन।
परिवर्तनका बेला मानिसहरूलाई अलमल्याउने तेस्रो अवस्था पनि छ। केही प्लेटफर्मले रुट-लक्ष्य सदस्यता जानकारी प्रयोग गरेर कुन VPN रुट माग्ने वा राख्ने भन्ने सीमित गर्छन्, त्यसैले एउटा फिल्टर गरिएको दृश्यमा टाढाको NLRI नदेखिनु भनेको घोषणा कतै छैन भन्ने प्रमाण होइन। रुट विश्वव्यापी रूपमा फिर्ता लिइयो भन्ने निष्कर्ष निकाल्नुअघि नफिल्टर गरिएको तालिका र छिमेकीका घोषित रुट जाँच्नुहोस्।
चरण 3: केही स्थापना र लेबल भयो भनी पुष्टि गर्नुहोस्
BGP प्रविष्टि निर्णय हो, बाटो होइन। फर्वार्डिङ तालिकाले प्याकेटलाई जाने ठाउँ छ कि छैन भन्छ:
show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-Aसमाधान भएको छिमेकीसम्बन्ध र बाहिर जाने लेबलसहितको CEF प्रविष्टि भनेको डेटा-तह ट्राफिक चल्नुपर्ने हो, र बाँकी कुनै पनि लक्षण अनुप्रयोग वा VRF भित्रको फिल्टरिङको हो। समाधान नभएको अर्को हप देखाउने CEF प्रविष्टि भनेको BGP स्वस्थ देखिए पनि लेबलको बाटो अपूर्ण छ, र BGP तालिकाको स्क्रिनसटले परिवर्तन समीक्षा भुलाएको ठ्याक्कै त्यही अवस्था हो।
स्थानीय PE ले लाद्ने लेबल लाई टाढाको PE ले पाउने अपेक्षा गर्ने लेबलसँग तुलना गर्नुहोस्। दुई दृश्यबीचको असङ्गति लेबल बाँडफाँड वा सत्रको समस्या हो, र तपाईंले जतिपटक रुट-लक्ष्य सम्पादन गरे पनि त्यो सुध्रने छैन।
घोषित व्याप्तिसहित RT परिवर्तन फिर्ता लिनुहोस्
खराबी रुट-लक्ष्य सम्पादनबाट सुरु भएको हो भने, त्यसलाई एउटै जानाजान गरिएको चरणका रूपमा रद्द गर्नुहोस् र कुन व्याप्ति बदल्दै हुनुहुन्छ भन्नुहोस्। आयात लक्ष्य हटाउँदा त्यो VRF भित्रको योग्यता फिर्ता हुन्छ। यसले ब्याकबोनबाट VPNv4 घोषणा मेटाउँदैन, र केही प्लेटफर्ममा रुट तालिकामा राखिएकै रहन्छ। यी फरक नतिजा हुन् र प्रयोगकर्तालाई देखिने प्रभाव तपाईंको मतलब कुन हो भन्नेमा निर्भर छ।
configure terminal
vrf definition CUST-A
address-family ipv4
no route-target import 65000:410
end
clear ip bgp vpnv4 vrf CUST-A soft inसत्रले पहिल्यै प्रिफिक्स राख्छ भने भित्री नरम पुनःकन्फिगरेसन पर्याप्त हुन्छ; कामको समयमा प्रदायकतर्फ फर्केको सत्रको कडा रिसेट अरू कसैले लिनुपर्ने निर्णय हो। Junos मा समतुल्य जाँचहरूले प्रत्येक VRF को तालिका र VPN तालिका सिधै पढ्छन्, र रोलब्याक प्रत्येक आदेशको रद्द होइन, commit को बेलाको फिर्ती हो, त्यसैले सुरु गर्नुअघि कन्फिगरेसनको फरक कैद गर्नुहोस्।
सुरु गरेका ती तीनै आदेशले त्यही क्रममा टुंग्याउनुहोस्, र तिनको आउटपुट समय-छापसहित लेख्नुहोस्। RT गलत थियो र अब सही छ भन्ने टिकट फेरि प्रयोग गर्न मिल्दैन; प्रिफिक्स VRF मा, VPNv4 मा र CEF मा स्थापित छ भनी देखाउने टिकट अर्को व्यक्तिले तुलना गर्न सक्ने प्रमाण हो। पहिला दुई मात्र बदलिए भने तपाईंले परिवर्तन पूरा गर्नुभएन।