DMVPN WAN फेलओवर: रूट नीति या टनल बंद करें?

दो WAN वाला DMVPN हब दो में से किसी एक तरीके से फेलओवर करता है, और अंतर दिखने से बड़ा है। एक बदलता है कि रूट नीति कौन सा अगला हॉप चुनती है, इसलिए पैकेट बहते रहते हैं और केवल उनका निकास बदलता है। दूसरा टनल को प्रशासनिक रूप से बंद कर देता है, जो उस इंटरफ़ेस की हर सेवा को साथ लेकर नीचे ले जाता है। दोनों सही हो सकते हैं, क्योंकि वे अलग-अलग प्रश्नों का उत्तर देते हैं।

निर्णय कॉन्फ़िग से पहले आता है

तीन शर्तें यह आपके लिए तय करती हैं। क्या टनल इंटरफ़ेस के चालू होने पर कुछ और निर्भर है, जैसे दूसरी DMVPN प्रोफ़ाइल या उसकी स्थिति पढ़ने वाला मॉनिटर? क्या जिस ट्रैफ़िक को फेलओवर करना है वह अपनी नीति लेकर चलता है, या वैश्विक रूटिंग तालिका पर निर्भर है? और क्या ऑपरेटर को स्पष्ट स्थिति परिवर्तन चाहिए, या शांत पथ परिवर्तन स्वीकार्य है? इन तीनों का उत्तर दें और चुनाव अक्सर स्वयं हो जाता है।

यदि बंद करने से ऐसी सेवाएँ नीचे आएँ जो काम कर रही थीं, तो रूट नीति छोटी कार्रवाई है। यदि आवश्यकता यह है कि प्राथमिक WAN के नीचे रहने तक टनल का अस्तित्व ही न हो, तो कोई नीति प्रविष्टि इसे व्यक्त नहीं कर सकती।

उत्तर लिख लें, क्योंकि कॉन्फ़िग आसान हिस्सा है।

रूट नीति वास्तव में क्या बदलती है

नीति-आधारित रूटिंग में, ट्रैक किया गया ऑब्जेक्ट अगले हॉप को नियंत्रित कर सकता है। रूट-मैप प्रविष्टि एक उम्मीदवार अगले हॉप और उस ट्रैक किए गए ऑब्जेक्ट का नाम देती है जो उसके उपयोग के लिए चालू होना चाहिए, और वह ट्रैकिंग स्थिति IP SLA प्रोब से आती है। जब ऑब्जेक्ट नीचे जाता है, प्रविष्टि मेल खाना बंद कर देती है और पैकेट का मूल्यांकन अगली प्रविष्टि या सामान्य रूटिंग तालिका द्वारा होता है।

यह अंतिम विवरण लोगों को चौंकाता है: जो नीति अगला हॉप चुनना बंद कर देती है, वह आमतौर पर ट्रैफ़िक रोकने के बजाय सामान्य रूटिंग की अनुमति देती है। यदि आपको विफलता पर ब्लैक होल चाहिए, तो आपको एक लिखना होगा।

सिंटैक्स प्लेटफ़ॉर्म और रिलीज़ के अनुसार अलग होता है, इसलिए उस संस्करण की मार्गदर्शिका देखें जिसे आप वास्तव में चलाते हैं।

टनल बंद करने से क्या बदलता है

इंटरफ़ेस बंद करना प्रशासनिक स्थिति बदलता है। उस पर निर्भर हर टनल, रूट और सत्र एक साथ नीचे चला जाता है, जो ठीक वही है जो आप चाहते हैं यदि टनल ही वह चीज़ है जिसे गायब होना है। EEM एप्लेट भी इसी तरह WAN समस्या को ऐसी बाधा में बदल देता है जिसमें असंबंधित सेवाएँ भी शामिल होती हैं।

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

हार्डकोडेड पुनर्प्राप्ति कमांड किसी और द्वारा किए गए रखरखाव-बंद को भी ओवरराइड कर सकता है।

प्रोब को उसी पथ पर चलाएँ जिसकी आप सोच रखते हैं

जो प्रोब वर्तमान सर्वोत्तम रूट का अनुसरण करता है, वह बाकी सब के साथ बैकअप WAN पर चला जाता है और फिर प्राथमिक को स्वस्थ बताता है, क्योंकि अब वह उसका उपयोग नहीं कर रहा।

प्रोब को उस पथ के इंटरफ़ेस या स्रोत पते पर पिन करें जिसका आप परीक्षण कर रहे हैं। यह भी जाँचें कि वह किसे लक्षित करता है, क्योंकि ISP के अगले हॉप तक पहुँचना उस सेवा तक पहुँचने से कम साबित करता है जिसके लिए टनल मौजूद है। अप और डाउन देरी जानबूझकर तय करें: छोटी डाउन देरी तेज़ी से प्रतिक्रिया देती है और फ़्लैप करती है, जबकि लंबी छोटे उतार-चढ़ाव सह लेती है और असली विफलताएँ छिपा देती है। Cisco की IOS XE में ट्रैकिंग और नीति-रूटिंग मार्गदर्शिका समर्थित संयोजनों का दस्तावेज़ीकरण करती है, और आपके प्लेटफ़ॉर्म का फ़ीचर सेट तय करता है कि आप उनमें से कौन से उपयोग कर सकते हैं।

दोनों देरी मान ट्रैक किए गए ऑब्जेक्ट के पास लिख लें, वरना किसी को पता नहीं चलेगा कि उसने ऐसा व्यवहार क्यों किया।

पुनर्स्थापन तय करें, फिर सत्यापित करें

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

यदि फेलओवर काम करता है पर एप्लिकेशन फिर भी टूटता है, तो समस्या रूटिंग परत के ऊपर है और कोई भी ट्रैकिंग उसे ठीक नहीं करेगी।

उस विंडो के साक्ष्य सहेजें, क्योंकि अगले परिवर्तन की तुलना उनसे की जाएगी।