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 में इंस्टॉल है वह सबूत है जिससे अगला व्यक्ति तुलना कर सकता है। अगर सिर्फ़ पहले दो बदले, तो आपने बदलाव पूरा नहीं किया।