NX-OS EVPN null रुट: खारेजी एकै टेनन्टभित्र राख्नुहोस्

अनुरोध एक हरफको परिवर्तनका रूपमा आउँछ: एउटा ठेगाना ब्ल्याकहोल गर्नु। तपाईं टेनन्ट सन्दर्भभित्र Null0 मा होस्ट रुट थप्नुहुन्छ, अपेक्षाअनुसार उपसर्ग स्थानीय तालिकाबाट हराउँछ, र त्यसपछि प्रश्नहरू सुरु हुन्छन्। रुट यन्त्रबाट बाहिर गयो? टाढाका VTEP ले खारेज गरे, वा तिनीहरूले पहुँच क्षमता मात्र गुमाए? अब दोस्रो टेनन्ट प्रभावित छ?

सही स्थानीय स्थिर रुटले तीमध्ये पहिलो प्रश्नको मात्र जवाफ दिन्छ, त्यसैले ब्ल्याकहोल परिवर्तन वास्तवमा एउटा आदेश नभई तीन समीक्षित नतिजा हुन्।

परिवर्तनले वास्तवमा के उत्पादन गर्नुपर्छ

तीन नतिजा लेखेर सुरु गर्नुहोस्। इच्छित टेनन्टले गन्तव्यलाई स्थानीय रूपमा खारेज गर्नुपर्छ। अधिकृत रुट मात्र निर्यात गर्न सकिन्छ, र त्यससँग अरू केही जानु हुँदैन। प्रत्येक प्राप्त गर्ने VTEP ले अर्को मार्ग नभई इच्छित खारेजी कार्य छान्नुपर्छ।

प्रत्येक नतिजासँग आफ्नै प्रमाण छ र कुनैले अरूलाई जनाउँदैन। स्थानीय Null0 रुटले स्थानीय खारेजी उत्पादन गर्छ र पुनर्वितरण बिना केही पनि निर्यात गर्दैन। सहमत community बिना पुनर्वितरित रुट साधारण उपसर्गका रूपमा आउँछ र अगाडि पठाइन्छ। प्राप्ति नीति बिना community पूर्ण रूपमा बेवास्ता गर्न सकिन्छ।

नतिजा पहिले लेख्नुले सामान्य असफलताबाट पनि बचाउँछ: गन्तव्य पहिले नै असम्बन्धित कारणले पहुँचयोग्य नभएको हुनाले काम गरेजस्तो देखिने परिवर्तन। दुईलाई कसरी छुट्याउने भनी वर्णन गर्न सक्नुहुन्न भने, स्वीकृति परीक्षण अझै डिजाइन गरिएको छैन।

स्थानीय वाक्यले पहिलो भाग मात्र गर्छ

10.4(x) शृंखलाको NX-OS मा, null रुट VRF को नाम लिने एउटै आदेशमा नभई टेनन्टको VRF सन्दर्भभित्र बस्छ। अंश छोटो छ, र यो पूर्ण EVPN कन्फिगरेसन होइन।

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

ठेगाना दस्तावेजीकरण उपसर्ग हो, लक्ष्य होइन। VRF को नाम रुट आदेशभित्रै देखिने IOS सँगको वाक्यरचना भिन्नता हेर्नुहोस्, र केही टाँस्नुअघि तपाईंले वास्तवमै चलाउनुहुने रिलिजका लागि समर्थित स्वरूप पुष्टि गर्नुहोस्।

एक्लै यो हरफले TENANT_A भित्रको त्यो होस्टको ट्राफिक खारेज गर्छ र अरू केही गर्दैन। यसले रुटलाई ट्याग गर्दैन, BGP का लागि छान्दैन र community सेट गर्दैन। यी छुट्टै कन्फिगरेसन निर्णय हुन्, र हरेक त्यस्तो ठाउँ हो जहाँ परिवर्तन काम गर्न धेरै साँघुरो वा सुरक्षित रहन धेरै फराकिलो हुन सक्छ।

स्थानीय खारेजीले उही गन्तव्यतर्फको वैध ट्राफिकलाई पनि असर गर्छ। यदि उद्देश्य वास्तविक प्रयोगकर्तालाई अझै ठेगाना चाहिएको बेला एउटा दुरुपयोग गर्ने स्रोत रोक्नु हो भने, null रुट गलत उपकरण हो र त्यो पहिलो सहयोग कलबाटै थाहा हुन्छ।

निर्यात र आयात छुट्टै सम्झौता हुन्

पुनर्वितरण भनेको दायरा तय हुने ठाउँ हो। योग्य उपसर्गहरूलाई स्वीकृत न्यूनीकरणमा सीमित गर्नुहोस्, यसलाई टेनन्टभित्र राख्नुहोस् र स्रोत पियरहरूलाई डिजाइनमा भएकाहरूमा सीमित गर्नुहोस्। एउटा ट्याग गरिएको होस्ट रुटले यात्रा गर्नुपर्ने भन्दै हरेक स्थिर रुट पुनर्वितरण गर्नु भनेको मर्मत परिवर्तनलाई राउटिङ घटनामा बदल्ने बाटो हो।

BLACKHOLE community ज्ञात मानको बारेमा सम्झौता हो, कुनै पनि छिमेकीलाई कुनै पनि ठेगाना खारेज गर्ने अधिकार होइन। RFC 7999 ले यसलाई ती शब्दहरूमै वर्णन गर्छ, र कसले यसको घोषणा गर्न सक्छ भन्ने विश्वासको सीमा डिजाइनको भाग हो, कार्यान्वयनको विवरण होइन।

प्राप्त गर्ने पक्षलाई आफ्नै कन्फिगरेसन चाहिन्छ। NX-OS मा, प्रकार 5 null रुटहरूलाई खारेजी व्यवहार छान्न VTEP मा route-map प्रशोधन चाहिन्छ, जो निर्यात चरणहरूसँगै अभिलेख गरिएको छ। सही रूपमा ट्याग गर्ने पठाउने यन्त्र र ट्यागलाई बेवास्ता गर्ने प्राप्तकर्ताले लागू भएजस्तो देखिने र तैपनि ट्राफिक अगाडि पठाउने परिवर्तन बनाउँछन्।

त्यहीँ हुँदा route-map का साइड इफेक्टहरू हेर्नुहोस्। नयाँ प्रतिबन्धात्मक नीतिले असम्बन्धित उपसर्गहरूको वैध पहुँच दबाउन सक्छ, र त्यो क्षति ब्ल्याकहोलपछि देखिन्छ र त्यससँग जोड्न गाह्रो हुन्छ।

सम्मिलन अघि फिर्ता लेख्नुहोस्

केही पनि कन्फिगर गर्नुअघि गन्तव्यको मालिक, कारण, स्वीकृत गर्ने र म्याद अभिलेख गर्नुहोस्। म्याद बिनाको खारेजी यस्तो स्थायी प्रविष्टि बन्छ जसको उत्पत्ति कसैलाई सम्झना हुँदैन, र ठेगाना डिबग गर्ने अर्को व्यक्तिले यसलाई सञ्जालको सामान्य भाग ठान्नेछ।

तपाईंले परिवर्तन गर्दै हुनुहुने रुटमा निर्भर नहुने स्वतन्त्र व्यवस्थापन मार्ग राख्नुहोस्। यदि न्यूनीकरणले यन्त्रसम्म पुग्न प्रयोग गर्ने ठेगाना ढाक्छ भने, तपाईंले थप चरणसहित लकआउट बनाउनुभएको छ।

न्यूनीकरण हटाउने ठ्याक्कै नियन्त्रणको नाम लिनुहोस्, र त्यो हटाइ प्रयोगशालामा वा तपाईंले सहन सक्ने विन्डोमा परीक्षण गर्नुहोस्। कसैले अभ्यास नगरेको फिर्ता प्रक्रिया होइन, योजना हो।

आदेशको आउटपुटले नभई प्रमाणले स्वीकार गर्नुहोस्

इच्छित VTEP हरूमा छानिएको राउटिङ स्थिति र अग्रगमन स्थिति जाँच्नुहोस्, र अछुत रहनुपर्ने छिमेकी गन्तव्य जाँच्नुहोस्। अरू कुनै टेनन्टले उपसर्ग आयात गरेको छैन भनी पुष्टि गर्नुहोस्, किनकि टेनन्टबीचको चुहावट नै त्यो असफलता ढाँचा हो जसले मर्मत कार्यलाई घटनामा बदल्छ।

त्यसपछि फिर्ता लिनुहोस् र सामान्य रुट र सेवा फर्किएको प्रमाणित गर्नुहोस्। NX-OS EVPN null रुट निर्देशिका 10.4(x) रिलिजका लागि यहाँ वर्णन गरिएको ट्यागिङ, पुनर्वितरण र प्राप्ति नीति अभिलेख गर्छ, र यो तपाईंको आफ्नै रिलिजसँग भिडाउने सन्दर्भ हो।