CE RIP मार्गापासून दूरच्या VRF पर्यंत: एक्सपोर्ट कुठे होतो

RIPv2 अपडेट प्रोव्हायडर एजवर येते, VRF राउटिंग टेबलमध्ये जाते आणि काहीतरी ते स्पष्टपणे एक्सपोर्ट करत नाही तोपर्यंत तिथेच थांबते. तीन निर्णय क्रमाने घडतात आणि प्रत्येकजण स्वतःच्या कारणाने प्रीफिक्स नाकारू शकतो. हे एकच घटना म्हणून वाचणे हेच कारण आहे की CE स्पष्टपणे जाहीर करत असलेल्या नेटवर्कपर्यंत दूरचे साइट पोहोचू शकत नाही तेव्हा लोक चुकीच्या उपकरणामागे धावतात. PE मधून मार्गाचा पाठपुरावा करा आणि क्रम स्पष्ट होतो.

PE RIP अपडेटसह काय करते

PE VRF इंटरफेसवर अपडेट घेते, स्रोत परवानगी असलेला शेजारी आहे याची तपासणी करते, आणि जाहिरातीतून मिळवलेल्या हॉप संख्येसह प्रीफिक्स VRF राउटिंग टेबलमध्ये टाकते. ते टेबल स्वतःच्या प्रशासकीय अंतरांसह आणि स्वतःच्या सर्वोत्तम-मार्ग निवडीसह सामान्य राउटिंग टेबल आहे. CE एकच प्रीफिक्स वेगवेगळ्या मेट्रिकसह दोनदा जाहीर करत असल्यास, टेबलमध्ये फक्त चांगलेच टिकते. या पायरीत प्रोव्हायडर बॅकबोनचा काहीही संबंध नाही.

प्रीफिक्स आता एका ग्राहकाच्या राउटिंग संदर्भात आहे, जे इतरत्र कुठेही पोहोचण्यायोग्य असण्यापासून खूप दूर आहे.

एक्सपोर्ट ही धोरणाची कृती आहे, प्रोटोकॉलचा परिणाम नाही

VRF सोडण्यासाठी, मार्ग VPN मार्ग वाहून नेणाऱ्या MP-BGP प्रक्रियेत पुनर्वितरित करावा लागतो, आणि कोणत्या दूरच्या VRF तो आयात करू शकतात हे ओळखणारा मार्ग लक्ष्य विस्तारित समुदाय आवश्यक असतो. RFC 4364 मधील आर्किटेक्चर हे देवाणघेवाण CE-ते-PE प्रोटोकॉलपासून वेगळ्या ठेवते ते नेमक्या याच कारणासाठी. एजवर RIP वापरणे प्रोव्हायडर नेटवर्क ओलांडायला काय हवे याबद्दल काहीही सांगत नाही.

काहीही कॉन्फिगर करण्यापूर्वी एक्सपोर्ट करार लिहून ठेवा: दूरून पोहोचण्यायोग्य असलेले ग्राहक प्रीफिक्स, स्थानिक राहणारे मार्ग, आणि कोणतेही डीफॉल्ट, अधिक-विशिष्ट किंवा सामायिक-सेवा अपवाद. तो करार प्रत्यक्ष VRFशी जुळवा, दुसऱ्या ग्राहकाच्या त्याच नावाच्या VRFशी नाही.

आयात बाजू स्वतःच्या मार्ग लक्ष्यांसह दुसरे धोरण आहे, आणि जुळणारा एक्सपोर्ट न जुळणाऱ्या आयातीसह बॅकबोनमध्ये असलेला पण कोणत्याही दूरच्या टेबलमध्ये न दिसणारा प्रीफिक्स तयार करतो.

पुनर्वितरण आणि स्पष्ट उगम वेगळ्या पद्धतीने वागतात

पुनर्वितरण VRF टेबलमध्ये आधीच असलेले मार्ग घेते आणि मार्ग नकाशाने गाळून ते BGP मध्ये कॉपी करते. नकाशा कोणते प्रीफिक्स पात्र आहेत आणि कोणती गुणवैशिष्ट्ये वाहतात हे ठरवतो, आणि RIP हॉप संख्येला BGP मेट्रिक म्हणून अर्थ नसल्याने मेट्रिक स्पष्टपणे सेट करावे लागते. तुम्ही न सेट करता सोडलेले सर्व सहा महिन्यांनंतर कॉन्फिग वाचणाऱ्याला सहसा चकित करणाऱ्या पद्धतीने वारसाहक्काने मिळते.

परस्पर पुनर्वितरण हेच शांत नुकसान होण्याचे ठिकाण आहे. BGP मध्ये एक्सपोर्ट केलेला प्रीफिक्स दुसऱ्या पुनर्वितरण बिंदूतून परत येऊ शकतो, आणि टॅग किंवा फिल्टर नसल्यास दोन्ही टेबल कोणत्याही क्षणी विश्वासार्ह दिसत असताना मार्ग डोलतो. परतीचा मार्ग रोखण्यासाठी टोपोलॉजीवर विश्वास ठेवण्याऐवजी एजवर लावलेल्या टॅगवर फिल्टर करा.

स्पष्ट उगम अधिक नीटनेटका दिसतो आणि तो बिनशर्त नाही. नेटवर्क विधानाला सहसा प्रीफिक्स तयार होण्यापूर्वी राउटिंग टेबलमध्ये जुळणारा मार्ग लागतो, त्यामुळे CE जाहिरात थांबवतो त्याच क्षणी जाहिरात नाहीशी होते. ते बऱ्याचदा तुम्हाला हवे असलेले वर्तन असते आणि ते कायम कॉन्फिगर राहणाऱ्या स्थिर मार्गासारखे नसते. दोनपैकी कोणतेही वर्तन गृहीत धरण्याऐवजी प्लॅटफॉर्मचा प्रत्यक्ष नियम तपासा.

कोणत्याही परिस्थितीत, प्रत्येक प्रीफिक्सबद्दल विचारायचा प्रश्न म्हणजे कोणता सक्रिय स्रोत त्याला पात्र बनवतो आणि तो स्रोत नाहीसा झाल्यावर काय होते.

चार ठिकाणी साखळी तपासा

CE जाहिरात, VRF राउटिंग टेबल, त्याच्या मार्ग लक्ष्यासह VPN मार्ग टेबल, आणि दूरच्या VRF मधील आयात, याच क्रमाने पहा. IOS वर याचा अर्थ CE शेजाऱ्याचे आउटपुट, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, आणि दूरच्या PE वर तोच आदेश. IOS-XR वर समतुल्य आउटपुट याच्या खाली आहे: show bgp vrf CUSTOMER ipv4 unicast. आदेशांची नावे वेगळी आहेत, चार तपासणी बिंदू नाहीत.

नाकारले जावे अशा प्रीफिक्सची तितक्याच काळजीपूर्वक तपासणी करा जितकी पास होणाऱ्याची, कारण सर्व काही परवानगी देणारे धोरण पहिला अपवाद येईपर्यंत योग्य धोरणासारखेच दिसते. नंतर मागे घेणे पहा: CE इंटरफेस बंद करा, आणि दूरची नोंद अपेक्षित टाइमरमध्ये नाहीशी होते, राहत नाही याची खात्री करा.

प्रत्येक धोरणाचा मालक कोण आहे ते नोंदवा. प्रोव्हायडर CE चालवत असताना, दिलेले वर्तन सेवा करारात येते, आणि व्यवस्थापित उपकरणावरील वेगळा प्रोटोकॉल किंवा मागे घेण्याचे धोरण राउटिंग समस्येपूर्वी कागदपत्रांची समस्या आहे.