कोई आपसे spokes का सारांश बनाने को कहता है, और टिकट hub पर कम प्रीफ़िक्स के साथ बंद हो जाता है। एक हफ़्ते बाद वह शाखा-से-शाखा ट्रैफ़िक, जो पहले सीधा जाता था, फिर से hub से होकर जाता है, और कोई भी दोनों बदलावों को जोड़ता नहीं। spokes का सारांश बनाओ यह वाक्यांश दो अलग टेबल को छूने वाले दो अलग ऑपरेशनों को कवर करता है। किसी दूसरे DMVPN उदाहरण से कमांड उधार लेने से पहले बताइए कि आप कौन-सी स्थिति घटा रहे हैं।

लक्षण: सीधा spoke ट्रैफ़िक वापस hub पर चला गया

यह अंतर सबसे ज़्यादा तब मायने रखता है जब Phase 2 की चर्चा किसी Phase 3 डिज़ाइन पर लागू की जाती है। दोनों बातचीत में वही शब्द आते हैं, और फ़ॉरवर्डिंग पर असर एक जैसा नहीं होता।

इसीलिए समीक्षा के समय बदलाव सही लगा: समीक्षा ने रूटिंग टेबल देखी, जो शामिल तीन स्थितियों में से केवल एक है।

एक एकत्रीकरण, दो टेबल

दोनों ऑपरेशन ऐसे दिखते हैं:

OperationWhat it actually changes
Routing summaryAggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs
NHRP summary mapChanges the network returned in a resolution reply, so a requesting spoke resolves to a different address
Protection pathIPsec state for the peer you actually resolved; neither aggregation changes it

रूट सारांश इस बात का कथन है कि hub क्या विज्ञापित करता है और प्राप्त करने वाला spoke क्या रूट के रूप में इंस्टॉल करता है। NHRP सारांश मैप इस बात का कथन है कि जब कोई दूसरा spoke पूछता है कि किसी पते तक कैसे पहुँचें, तब spoke कौन-सा उत्तर भेजता है। ये अलग-अलग विफलता वाले अलग सवाल हैं, और कोई डिज़ाइन एक को बदलकर दूसरे को ठीक वैसा ही छोड़ सकता है। इन्हें एक ही लीवर मानना ही वह तरीका है जिससे एकत्रीकरण का बदलाव चुपचाप फ़ॉरवर्डिंग का बदलाव बन जाता है।

दोनों में से कोई ऑपरेशन सुरक्षा पथ के बारे में कथन नहीं है, क्योंकि उस पर उस पीयर के लिए बातचीत होती है जिसे आपने वास्तव में रिज़ॉल्व किया।

hub का सारांश वास्तव में क्या बदलता है

spoke-से-spoke NHRP सारांश मैप के लिए Cisco की मार्गदर्शिका ऐसी Phase 3 व्यवस्था का वर्णन करती है जिसमें hub एक सारांश विज्ञापित करता है और रूटिंग का अगला हॉप बना रहता है। फिर एक रीडायरेक्ट और उसके बाद का NHRP रिज़ॉल्यूशन अधिक सीधा फ़ॉरवर्डिंग पथ देते हैं। इसलिए केवल एकत्रित रूट पढ़ना पूरी फ़ॉरवर्डिंग स्थिति का वर्णन नहीं करता, और इसका अर्थ यह नहीं कि हर पैकेट को हमेशा hub से गुज़रना पड़े। सारांश पहुँच के बारे में है, पथ के बारे में नहीं।

इसीलिए रूटिंग टेबल पर रुकने वाली डिज़ाइन समीक्षा ऐसे बदलाव को मंज़ूरी दे सकती है जो रिज़ॉल्यूशन व्यवहार बदल देता है। चुने गए रूट, NHRP परिणाम और सुरक्षा पथ को तीन अलग अवलोकनों के रूप में देखें।

अगर आप यह नहीं बता सकते कि तीनों में से कौन बदला, तो आपने बदलाव पूरा नहीं किया।

NHRP सारांश मैप क्या बदलता है

ऐसा spoke लीजिए जो कई अधिक विशिष्ट LAN रूटों के ज़रिए 10.32.0.0/19 रखता है, जबकि hub बाकी spokes को बड़ा एकत्रीकरण विज्ञापित करता है। 10.32.12.10 के लिए अनुरोध को अन्यथा मेल खाते छोटे नेटवर्क की रिज़ॉल्यूशन जानकारी मिलती। प्रलेखित NHRP सारांश मैप सुविधा spoke को इसके बजाय अपना कॉन्फ़िगर किया गया कवरिंग प्रीफ़िक्स लौटाने देती है, जो उस spoke के नेटवर्क के लिए दोहराया जाने वाला रिज़ॉल्यूशन काम घटा सकता है। यह hub के रूट सारांश और spoke के रिज़ॉल्यूशन सारांश को एक ही वस्तु नहीं बनाता।

उस कवरिंग प्रीफ़िक्स को सोच-समझकर बनाया गया स्वामित्व मॉडल दें। कहीं और के पते शामिल करने वाला व्यापक उत्तर, या ऐसे अंतराल जहाँ पहुँच नहीं है, आगे का ट्रैफ़िक अनुपयुक्त पीयर की ओर भेज सकते हैं।

प्रीफ़िक्स बड़ा करने से पहले वास्तविक रूट और इच्छित अस्वीकृत मामले जाँचें, बाद में नहीं।

पहले गंतव्य और सारांश के भीतर एक गंतव्य की तुलना करें

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

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

टिकट में लिखा होना चाहिए कि आपने कौन-सी टेबल घटाई और किसे अछूता छोड़ा। इससे कम कुछ भी एक महीने बाद शुरू से फिर निदान किया जाएगा।

संबंधित लेख