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 मध्ये इन्स्टॉल आहे हे दाखवणारे तिकीट हा पुढच्या व्यक्तीला तुलना करता येणारा पुरावा आहे। पहिले दोनच बदलले असतील, तर तुम्ही बदल पूर्ण केलेला नाही।