नावाचा वि. क्रमांकाचा DMVPN हब: FQDN काय बदलते

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

दोन पत्ते, दोन कामे

एका घोषित उदाहरणात, hub.example.net स्पोकला ट्रान्सपोर्ट रहदारी कुठे पाठवायची ते सांगतो, आणि 10.90.0.1 टनेलमधील NHS ओळखतो. डिस्कव्हरी पहिल्यावर काम करते; नोंदणी आणि राउटिंग दुसऱ्यावर काम करतात. नावातील बदल एंडपॉइंटपर्यंतच्या मार्गावर परिणाम करतो, तर प्रोटोकॉल पत्त्यातील बदल ओव्हरले संबंधावरच परिणाम करतो.

भूमिका वेगळ्या ठेवणे हेच नावाच्या स्वरूपाला डीबग करण्यायोग्य बनवते. स्पोक नोंदणी करू शकत नसल्यास, तुम्ही दोन वेगळे प्रश्न विचारू शकता: नाव मी अपेक्षित असलेल्या पत्त्यावर सोडवले गेले का, आणि तो पत्ता कॉन्फिगरेशन ज्या प्रोटोकॉल पत्त्याचा दावा करते त्याला जुळला का? कोणतेही उत्तर दुसऱ्याला सूचित करत नाही.

दोन्ही कॉन्फिगरेशन स्वरूपांची तुलना करा

एक स्वरूप नावासोबत NHS प्रोटोकॉल पत्ता स्पष्टपणे कॉन्फिगर करते. दुसरे स्पोकला नोंदणी उत्तरातून तो प्रोटोकॉल पत्ता शिकू देते. दोन्ही दस्तऐवजीकृत आहेत, आणि यशस्वी झाल्यास दोन्ही एकाच प्रकारच्या NHS संबंधात संपतात.

स्पष्ट स्वरूपात एक मर्यादा आहे जी लक्षात ठेवण्यासारखी आहे: कॉन्फिगर केलेल्या प्रोटोकॉल पत्त्यावर मॅप न होणारा सोडवलेला ट्रान्सपोर्ट पत्ता नोंदणी रोखतो. हे DNS बिघाड नाही, तरी लक्षण DNS बदलानंतर लगेच दिसते. नाव योग्यरित्या सोडवले गेले आणि निकाल दुसऱ्या कारणाने नाकारला गेला. सोडवलेला पत्ता आणि कॉन्फिगर केलेला प्रोटोकॉल पत्ता शेजारी शेजारी वाचा.

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

स्थिर हबसोबत DNS कॅशची तुलना करा

कोणी कॉन्फिगरेशन संपादित केल्यावर स्थिर हब पत्ता बदलतो. नावाचा हब DNS बदलल्यावर बदलतो, आणि DNS उत्तरे त्यांच्या आयुष्यभर कॅशमध्ये ठेवली जातात. कॅश केलेली माहिती कालबाह्य होईपर्यंत वापरण्यायोग्य राहते, आणि नंतरची क्वेरी नवीन पत्ता परत करू शकते असे दस्तऐवज नमूद करते.

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

स्थिर स्वरूपाला अर्थातच स्वतःचा विलंब आहे: प्रत्येक स्पोक संपादित होईपर्यंत काहीही बदलत नाही. तुलना समन्वित कॉन्फिगरेशन ढकलणे आणि कॅश केलेले डिस्कव्हरी रिफ्रेश यामधील आहे, हळू आणि तात्काळ यामधील नाही.

काय समान राहते याची तुलना करा

पीअर प्रमाणीकरण हलत नाही. ट्रान्सपोर्ट एंडपॉइंट शोधणारे होस्टनाव कॉन्फिगर केलेली IKE ओळख किंवा पीअरची पडताळणी करणाऱ्या प्रमाणीकरण धोरणाची जागा घेत नाही. ओळख चुकीची असल्यास, यशस्वी DNS निराकरण तुम्हाला नाकारलेल्या टनेलपर्यंत लवकर पोहोचवते.

संरक्षित रहदारीही अपरिवर्तित आहे. प्रतिसाद देणारा NHS ग्राहक मार्ग अस्तित्वात आहे किंवा अनुप्रयोग प्रवाहास परवानगी आहे हे सिद्ध करत नाही. नोंदणी, राउटिंग आणि धोरण या तीन तपासण्या आहेत, आणि नाव त्यांना पोषण देणाऱ्या पहिल्या टप्प्यावरच परिणाम करते.

तुम्ही पडताळू शकता अशी तुलना

Cisco सत्र आणि NHS संबंधासाठी स्वतंत्र निरीक्षणे दस्तऐवजीकृत करते. पीअर आणि सत्र स्थिती वाचण्यासाठी show dmvpn वापरा, आणि NHS नोंदणी दृश्य वाचण्यासाठी show ip nhrp nhs वापरा. सोडवलेला ट्रान्सपोर्ट पत्ता, ओव्हरले पीअर आणि नोंदणी स्थिती या क्रमाने तुलना करा.

IOS XE FQDN-DMVPN प्रकरण या तुलनेमागील डिस्कव्हरी, कॅशिंग आणि मर्यादा वर्तन दस्तऐवजीकृत करते. नाव बदललेल्या हबला क्रमांकाच्या हबचा थेट पर्याय मानण्यापूर्वी ते तुमच्या स्थापित आवृत्तीशी तुलना करून वाचा.