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 चलाउँदा, दिइएको व्यवहार सेवा सम्झौतामा पर्छ, र व्यवस्थापित उपकरणमा फरक प्रोटोकल वा फिर्ता लिने नीति राउटिङ समस्याअघि कागजातको समस्या हो।