NX-OS EVPN नल रूट: छँटाई को एक ही टेनेंट के भीतर रखें

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

सही स्थानीय स्टैटिक रूट इनमें से केवल पहले प्रश्न का उत्तर देता है, इसलिए ब्लैकहोल बदलाव वास्तव में एक आदेश नहीं बल्कि तीन समीक्षित परिणाम हैं।

बदलाव को वास्तव में क्या उत्पन्न करना चाहिए

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

प्रत्येक परिणाम के अपने प्रमाण हैं और कोई भी दूसरे को निहित नहीं करता। स्थानीय Null0 रूट स्थानीय छँटाई उत्पन्न करता है और पुनर्वितरण के बिना कुछ भी निर्यात नहीं करता। सहमत community के बिना पुनर्वितरित रूट सामान्य उपसर्ग के रूप में आता है और अग्रेषित हो जाता है। प्राप्ति नीति के बिना community को पूरी तरह अनदेखा किया जा सकता है।

पहले परिणाम लिखना आपको एक सामान्य विफलता से भी बचाता है: ऐसा बदलाव जो काम करता दिखता है क्योंकि गंतव्य पहले से ही किसी असंबंधित कारण से अगम्य था। यदि आप बता नहीं सकते कि अंतर कैसे करेंगे, तो स्वीकृति परीक्षण अभी तैयार नहीं है।

स्थानीय कथन केवल पहला भाग करता है

10.4(x) श्रेणी के NX-OS में, नल रूट VRF का नाम लेने वाले एक आदेश में नहीं, बल्कि टेनेंट के VRF संदर्भ के भीतर बैठता है। अंश छोटा है, और यह निश्चित रूप से पूर्ण EVPN कॉन्फ़िगरेशन नहीं है।

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

पता एक प्रलेखन उपसर्ग है, लक्ष्य नहीं। IOS से वाक्य-रचना का अंतर देखें, जहाँ VRF का नाम रूट आदेश के भीतर ही आता है, और कुछ भी चिपकाने से पहले उस रिलीज़ के लिए समर्थित रूप की पुष्टि करें जिसे आप वास्तव में चलाते हैं।

अकेली यह पंक्ति TENANT_A के भीतर उस होस्ट के लिए ट्रैफ़िक छाँट देती है और कुछ और नहीं करती। यह रूट को टैग नहीं करती, इसे BGP के लिए नहीं चुनती और community सेट नहीं करती। ये अलग कॉन्फ़िगरेशन निर्णय हैं, और हर एक ऐसी जगह है जहाँ बदलाव या तो काम करने के लिए बहुत संकीर्ण या सुरक्षित रहने के लिए बहुत व्यापक हो सकता है।

स्थानीय छँटाई उसी गंतव्य के वैध ट्रैफ़िक को भी प्रभावित करती है। यदि उद्देश्य एक दुरुपयोग करने वाले स्रोत को रोकना है जबकि वास्तविक उपयोगकर्ताओं को अभी भी पता चाहिए, तो नल रूट गलत उपकरण है और आप यह पहली सहायता कॉल से सीखेंगे।

निर्यात और आयात अलग समझौते हैं

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

BLACKHOLE community एक ज्ञात मान के बारे में समझौता है, किसी भी पड़ोसी को कोई भी पता छाँटने का प्राधिकार नहीं। RFC 7999 इसे उन्हीं शब्दों में वर्णित करता है, और कौन इसकी घोषणा कर सकता है इस पर विश्वास की सीमा डिज़ाइन का हिस्सा है, कार्यान्वयन का विवरण नहीं।

प्राप्त करने वाले पक्ष को अपना कॉन्फ़िगरेशन चाहिए। NX-OS में, टाइप 5 नल रूट को छँटाई व्यवहार चुनने के लिए VTEP पर route-map प्रसंस्करण चाहिए, जो निर्यात चरणों के साथ प्रलेखित है। सही ढंग से टैग करने वाला प्रेषक उपकरण और टैग को अनदेखा करने वाला प्राप्तकर्ता ऐसा बदलाव बनाते हैं जो लागू दिखता है और फिर भी ट्रैफ़िक अग्रेषित करता है।

वहाँ रहते हुए route-map को दुष्प्रभावों के लिए देखें। नई प्रतिबंधक नीति असंबंधित उपसर्गों के लिए वैध पहुँच दबा सकती है, और वह क्षति ब्लैकहोल के बाद दिखती है और उससे जोड़ना कठिन है।

प्रवेश से पहले वापसी लिखें

कुछ भी कॉन्फ़िगर करने से पहले गंतव्य का स्वामी, कारण, अनुमोदक और समाप्ति तिथि दर्ज करें। बिना समाप्ति की छँटाई ऐसी स्थायी प्रविष्टि बन जाती है जिसका मूल किसी को याद नहीं रहता, और पता डीबग करने वाला अगला व्यक्ति इसे नेटवर्क का सामान्य हिस्सा मानेगा।

एक स्वतंत्र प्रबंधन पथ रखें जो उस रूट पर निर्भर न हो जिसे आप बदल रहे हैं। यदि शमन उस पते को कवर करता है जिसका उपयोग आप उपकरण तक पहुँचने के लिए करते हैं, तो आपने अतिरिक्त चरणों के साथ लॉकआउट बना दिया है।

उस सटीक नियंत्रण का नाम लें जो शमन हटाता है, और उस हटाने का परीक्षण प्रयोगशाला में या ऐसी विंडो में करें जिसे आप सह सकें। जिस वापसी का किसी ने अभ्यास नहीं किया वह प्रक्रिया नहीं, योजना है।

आदेश के आउटपुट से नहीं, प्रमाण से स्वीकारें

इच्छित VTEP पर चयनित रूटिंग स्थिति और अग्रेषण स्थिति जाँचें, और एक पड़ोसी गंतव्य जाँचें जो अछूता रहना चाहिए। पुष्टि करें कि किसी अन्य टेनेंट ने उपसर्ग आयात नहीं किया, क्योंकि टेनेंट-से-टेनेंट रिसाव वही विफलता विधा है जो रखरखाव कार्रवाई को घटना में बदल देती है।

फिर वापस लें और सत्यापित करें कि सामान्य रूट और सेवा लौट आए हैं। NX-OS EVPN नल रूट मार्गदर्शिका 10.4(x) रिलीज़ के लिए यहाँ वर्णित टैगिंग, पुनर्वितरण और प्राप्ति नीति का प्रलेखन करती है, और यह आपकी अपनी रिलीज़ से मिलाने का संदर्भ है।