DMVPN WAN फेलओभर: रुट नीति कि टनेल बन्द गर्ने?

दुई WAN भएको DMVPN हब दुईमध्ये एक तरिकाले फेलओभर हुन्छ, र फरक देखिनेभन्दा ठूलो छ। एउटाले रुट नीतिले कुन अर्को हप छान्छ त्यो बदल्छ, त्यसैले प्याकेट बग्न छाड्दैनन् र तिनको निकास मात्र बदलिन्छ। अर्कोले टनेल प्रशासनिक रूपमा बन्द गर्छ, जसले त्यो इन्टरफेसका सबै सेवा सँगै तल ल्याउँछ। दुवै सही हुन सक्छन्, किनभने तिनीहरू फरक प्रश्नको जवाफ दिन्छन्।

निर्णय कन्फिगभन्दा अघि आउँछ

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

यदि बन्द गर्दा चलिरहेका सेवा तल आउने भए, रुट नीति सानो कदम हो। यदि प्राथमिक WAN तल हुँदा टनेल हुनै नहुने आवश्यकता हो भने, कुनै पनि नीति प्रविष्टिले त्यो व्यक्त गर्न सक्दैन।

जवाफ लेख्नुहोस्, किनभने कन्फिग सजिलो भाग हो।

रुट नीतिले वास्तवमा के बदल्छ

नीति-आधारित राउटिङमा, ट्र्याक गरिएको वस्तुले अर्को हप नियन्त्रण गर्न सक्छ। रुट-म्याप प्रविष्टिले उम्मेदवार अर्को हप र त्यो प्रयोग गर्न चालु हुनुपर्ने ट्र्याक गरिएको वस्तुको नाम दिन्छ, र त्यो ट्र्याकिङ अवस्था IP SLA प्रोबबाट आउँछ। वस्तु तल गएपछि प्रविष्टि मिल्न छाड्छ र प्याकेटको मूल्याङ्कन अर्को प्रविष्टि वा सामान्य राउटिङ तालिकाले गर्छ।

यो अन्तिम विवरणले मानिसहरूलाई छक्क पार्छ: अर्को हप छान्न छोड्ने नीतिले सामान्यतया ट्राफिक रोक्नुको सट्टा सामान्य राउटिङलाई अनुमति दिन्छ। यदि तपाईंलाई असफलतामा कालो प्वाल चाहिन्छ भने, आफैं लेख्नुपर्छ।

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

टनेल बन्द गर्दा के बदलिन्छ

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

यो बाटो लिनुभयो भने एप्लेटलाई एउटा इन्टरफेस र एउटा ट्रिगरमा सीमित गर्नुहोस्, अघिल्लो प्रशासनिक अवस्था सुरक्षित गर्नुहोस्, पुनःप्राप्ति कार्य परिभाषित गर्नुहोस् र बारम्बार फ्ल्यापले त्यसलाई लूपमा धकेल्न नसक्ने सुनिश्चित गर्नुहोस्।

हार्डकोड गरिएको पुनःप्राप्ति आदेशले अरू कसैले गरेको मर्मत-बन्द पनि रद्द गर्न सक्छ।

प्रोबलाई तपाईंले सोचेको बाटोमै हिँडाउनुहोस्

हालको उत्तम रुट पछ्याउने प्रोब अरू सबैसँगै ब्याकअप WAN मा सर्छ, अनि प्राथमिकलाई स्वस्थ भनी रिपोर्ट गर्छ, किनभने अब त्यसले त्यो प्रयोग गर्दैन।

प्रोबलाई तपाईंले परीक्षण गरिरहेको मार्गको इन्टरफेस वा स्रोत ठेगानामा पिन गर्नुहोस्। यसले के लक्ष्य गर्छ पनि जाँच्नुहोस्, किनभने ISP को अर्को हपमा पुग्नु टनेल जुन सेवाका लागि छ त्यहाँ पुग्नुभन्दा कम प्रमाणित गर्छ। अप र डाउन ढिलाइ जानाजान मिलाउनुहोस्: छोटो डाउन ढिलाइ छिटो प्रतिक्रिया दिन्छ र फ्ल्याप गर्छ, ठूलोले साना हल्लन सहन्छ र वास्तविक खराबी लुकाउँछ। Cisco को IOS XE मा ट्र्याकिङ र नीति-राउटिङ गाइड ले समर्थित संयोजनहरू अभिलेख गर्छ, र तपाईंको प्लेटफर्मको सुविधा समूहले तीमध्ये कुन प्रयोग गर्न सक्नुहुन्छ तय गर्छ।

दुवै ढिलाइ मान ट्र्याक गरिएको वस्तुको छेउमा लेख्नुहोस्, नत्र यसले किन यस्तो व्यवहार गर्‍यो कसैले थाहा पाउँदैन।

पुनःस्थापन तय गर्नुहोस्, अनि प्रमाणित गर्नुहोस्

पुनःस्थापन आफ्नै निर्णयको योग्य छ। सीमा निरन्तर नाघ्ने लिंकले स्पष्ट रूपमा असफल लिंकभन्दा बढी पटक सत्र सार्न सक्छ, र हरेक साराइमा कुञ्जी पुनर्वार्ता र एप्लिकेसन पुनःप्रयासको खर्च हुन्छ। स्थिरताको आवश्यकता छान्नुहोस् र ढिलाइले त्यो व्यक्त गरोस्। त्यसपछि परिवर्तन विन्डोमा प्रोबको मार्ग देखिने गरी प्रमाणित गर्नुहोस्: छानिएको रुट, बाह्य पियरको मार्ग र एप्लिकेसनले वास्तवमा के गर्‍यो।

फेलओभर काम गर्छ तर एप्लिकेसन अझै बिग्रन्छ भने, समस्या राउटिङ तहमाथि छ र कुनै पनि ट्र्याकिङले त्यसलाई सुधार्दैन।

त्यो विन्डोको प्रमाण राख्नुहोस्, किनभने अर्को परिवर्तन त्यससँग तुलना गरिनेछ।