DMVPN WAN फेलओव्हर: रूट धोरण की टनेल बंद करणे?

दोन WAN असलेला DMVPN हब दोनपैकी एका पद्धतीने फेलओव्हर होतो, आणि फरक दिसण्यापेक्षा मोठा आहे. एक रूट धोरण कोणता पुढील हॉप निवडते ते बदलते, त्यामुळे पॅकेट वाहत राहतात आणि फक्त त्यांचा निर्गम बदलतो. दुसरे टनेल प्रशासकीय पद्धतीने बंद करते, जे त्या इंटरफेसवरील प्रत्येक सेवा सोबत खाली आणते. दोन्ही बरोबर असू शकतात, कारण ते वेगळ्या प्रश्नांची उत्तरे देतात.

निर्णय कॉन्फिगपूर्वी येतो

तीन अटी हे तुमच्यासाठी ठरवतात. टनेल इंटरफेस सुरू असण्यावर दुसरे काही अवलंबून आहे का, जसे की दुसरे DMVPN प्रोफाइल किंवा त्याची स्थिती वाचणारा मॉनिटर? फेलओव्हर व्हायला हवा असलेला रहदारी स्वतःचे धोरण घेऊन येतो का, की जागतिक राउटिंग तक्त्यावर अवलंबून आहे? आणि ऑपरेटरला स्पष्ट स्थिती बदल हवा आहे का, की शांत मार्ग बदल स्वीकारार्ह आहे? या तिन्हींना उत्तर द्या आणि निवड बहुधा स्वतःच होते.

बंद केल्याने कार्यरत सेवा खाली आल्या तर रूट धोरण ही लहान कृती आहे. जर प्राथमिक WAN खाली असताना टनेल अस्तित्वातच नसावी अशी आवश्यकता असेल, तर कोणतीही धोरण नोंद ते व्यक्त करू शकत नाही.

उत्तर लिहून ठेवा, कारण कॉन्फिग हा सोपा भाग आहे.

रूट धोरण प्रत्यक्षात काय बदलते

धोरण-आधारित राउटिंगमध्ये, ट्रॅक केलेली वस्तू पुढील हॉप नियंत्रित करू शकते. रूट-मॅप नोंद उमेदवार पुढील हॉप आणि ते वापरण्यासाठी सुरू असणे आवश्यक असलेली ट्रॅक केलेली वस्तू नाव देते, आणि ती ट्रॅकिंग स्थिती IP SLA प्रोबमधून येते. वस्तू खाली गेल्यावर नोंद जुळणे थांबवते आणि पॅकेटचे मूल्यांकन पुढील नोंद किंवा सामान्य राउटिंग तक्त्याद्वारे होते.

हा शेवटचा तपशील लोकांना चकित करतो: पुढील हॉप निवडणे थांबवणारे धोरण सहसा रहदारी अडवण्याऐवजी सामान्य राउटिंगला परवानगी देते. तुम्हाला अपयशाच्या वेळी काळे छिद्र हवे असेल, तर तुम्हाला ते स्वतः लिहावे लागेल.

वाक्यरचना प्लॅटफॉर्म आणि आवृत्त्यांनुसार बदलते, त्यामुळे तुम्ही प्रत्यक्षात चालवत असलेल्या आवृत्तीचे मार्गदर्शक पहा.

टनेल बंद केल्याने काय बदलते

इंटरफेस बंद केल्याने प्रशासकीय स्थिती बदलते. त्यावर अवलंबून असलेली प्रत्येक टनेल, मार्ग आणि सत्र एकाच वेळी खाली जाते, टनेल हीच नाहीशी व्हायला हवी असेल तर तेच तुम्हाला हवे असते. EEM अॅप्लेटही याच पद्धतीने WAN समस्येचे असंबंधित सेवा असलेल्या खंडात रूपांतर करते.

हा मार्ग घेतल्यास, अॅप्लेट एका इंटरफेस आणि एका ट्रिगरपुरते मर्यादित करा, मागील प्रशासकीय स्थिती जतन करा, पुनर्प्राप्ती कृती परिभाषित करा आणि वारंवार होणारे फ्लॅप त्याला लूपमध्ये टाकू शकणार नाहीत याची खात्री करा.

हार्डकोड केलेला पुनर्प्राप्ती आदेश दुसऱ्याने केलेले देखभाल-बंदही रद्द करू शकतो.

प्रोबला तुम्ही विचार करता त्या मार्गाने जाऊ द्या

सध्याच्या सर्वोत्तम मार्गाचा अनुसरक करणारा प्रोब बाकी सर्वांसह बॅकअप WAN वर जातो, आणि नंतर प्राथमिकला निरोगी जाहीर करतो, कारण तो आता त्याचा वापर करत नाही.

प्रोबला तुम्ही चाचणी करत असलेल्या मार्गाच्या इंटरफेसवर किंवा स्रोत पत्त्यावर पिन करा. तो कशाला लक्ष्य करतो हेही तपासा, कारण ISP च्या पुढील हॉपपर्यंत पोहोचणे हे टनेल ज्या सेवेसाठी अस्तित्वात आहे तिथपर्यंत पोहोचण्यापेक्षा कमी सिद्ध करते. अप आणि डाउन विलंब जाणीवपूर्वक ठेवा: लहान डाउन विलंब वेगाने प्रतिक्रिया देतो आणि फ्लॅप करतो, तर मोठा लहान डगमगणे सहन करतो आणि खरे अपयश लपवतो. Cisco चे IOS XE मधील ट्रॅकिंग आणि धोरण-राउटिंग मार्गदर्शक समर्थित संयोजने नोंदवते, आणि तुमच्या प्लॅटफॉर्मवरील वैशिष्ट्य संच त्यापैकी कोणती तुम्ही वापरू शकता हे ठरवतो.

दोन्ही विलंब मूल्ये ट्रॅक केलेल्या वस्तूजवळ नोंदवा, नाहीतर तिने असे का वागले हे कोणालाही कळणार नाही.

पुनर्प्राप्ती ठरवा, मग पडताळा

पुनर्प्राप्ती स्वतःच्या निर्णयास पात्र आहे. उंबरठा सतत ओलांडणारा दुवा स्पष्टपणे अपयशी ठरलेल्या दुव्यापेक्षा जास्त वेळा सत्रे हलवू शकतो, आणि प्रत्येक हालचालीत की पुनर्वाटाघाटी आणि अॅप्लिकेशनच्या पुनःप्रयत्नांचा खर्च येतो. स्थिरतेची आवश्यकता निवडा आणि विलंबाने ती व्यक्त होऊ द्या. नंतर बदल खिडकीत प्रोबचा मार्ग दिसत असताना पडताळा: निवडलेला मार्ग, बाह्य पीअरचा मार्ग आणि अॅप्लिकेशनने प्रत्यक्षात काय केले.

फेलओव्हर काम करत असेल पण अॅप्लिकेशन तुटत असेल, तर समस्या राउटिंग थराच्या वर आहे आणि कोणतेही ट्रॅकिंग ती दुरुस्त करणार नाही.

त्या खिडकीतील पुरावे जतन करा, कारण पुढील बदल त्यांच्याशी तुलना केला जाईल.