तपाईंको VPN ब्याकअप EIGRP को सम्भाव्य उत्तराधिकारी किन होइन

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

सर्त, ठ्याक्कै भनिएको

RFC 7868 छिमेकीको लूप-मुक्त बाटोका लागि पर्याप्त जाँचको रूपमा सम्भाव्यता सर्त परिभाषित गर्छ: गन्तव्यका लागि छिमेकीको रिपोर्ट गरिएको दूरी स्थानीय सम्भाव्य दूरीभन्दा कडाइका साथ कम हुनुपर्छ। कडाइका साथ। कम वा बराबर होइन।

त्यही एउटा असमानताले विकल्पलाई सम्भाव्य उत्तराधिकारी बनाउँछ। यहाँ बाँकी सबै त्यसको वरिपरिको हिसाब हो।

फरक काम भएका दुई दूरी

रिपोर्ट गरिएको दूरी भनेको छिमेकीले गन्तव्यका लागि घोषणा गर्ने हो। सम्भाव्य दूरी अन्तिम ACTIVE–PASSIVE संक्रमणदेखि ज्ञात सबैभन्दा सानो कुल मेट्रिकको रेकर्ड हो, त्यसैले यो हालको उत्तम बाटोको मेट्रिकभन्दा फरक हुन सक्छ। यी दुईलाई मिसाउँदा आत्मविश्वासी गलत निष्कर्ष निस्कन्छ।

सञ्चालन प्रदर्शनमा दूरीजस्ता देखिने धेरै स्तम्भहरू सँगसँगै हुन्छन्। तपाईंले प्रयोग गरिरहेको स्तम्भको शीर्षक पढ्नुहोस्, र छिमेकीको पूरा गणना गरिएको बाटो-मेट्रिक उसले तपाईंलाई रिपोर्ट गरेको दूरीजत्तिकै परिमाण होइन भन्ने सम्झनुहोस्।

एउटा गरिएको तुलना

1000 सम्भाव्य दूरी भएको घोषित उदाहरण लिनुहोस्। 900 रिपोर्ट गर्ने छिमेकी परीक्षण पास गर्छ र सम्भाव्य उत्तराधिकारी बन्न सक्छ। 1000 रिपोर्ट गर्ने छिमेकी असफल हुन्छ, किनकि सर्त कडा असमानता हो र समानता पर्याप्त छैन।

ती संख्याहरू अंकगणित हुन्, लिङ्कको गति होइन। तिनलाई कुनै विशेष राउटरबारे भविष्यवाणी वा सिफारिस गरिएको मेट्रिकका रूपमा नपढ्नुहोस्।

पहिचान योग्यता होइन

एउटा संयन्त्रले मृत साथीलाई छिटो याद गर्न सक्छ जबकि EIGRP सँग अझै कुनै योग्य प्रतिस्थापन हुँदैन। याद गर्नु एउटा चरण हो; समन्वित बाटो गणना अर्को हो, र यो तब मात्र सुरु हुन्छ जब कुनै सम्भाव्य उत्तराधिकारी हुँदैन। सर्तमा असफल हुनुले विकल्पमा भौतिक लूप छ भनी प्रमाणित गर्दैन। यसको अर्थ स्थानीय सर्टकट परीक्षणले ग्यारेन्टी स्थापित गरेन, त्यसैले गणनाले नतिजा सम्हाल्नुपर्छ।

जीवन्तता टाइमर छोट्याउँदा कहिल्यै नभएको पहुँच सिर्जना गर्न सकिँदैन, र कन्फिगर गरिएको ब्यान्डविथ वा ढिलाइ मान बदल्नु क्षमताको मापन होइन।

फिल्ड पढ्नुहोस्, त्यसपछि अनुप्रयोग जाँच्नुहोस्

गन्तव्य, हालको उत्तराधिकारी, उम्मेदवार छिमेकी, उसको रिपोर्ट गरिएको दूरी, सम्भाव्य दूरी र परिणामस्वरूप बाटो स्थिति रेकर्ड गर्नुहोस्। show ip eigrp topology 10.10.10.0/24 ले एउटा प्रिफिक्सका लागि त्यसको धेरैजसो दिन्छ। त्यसपछि निर्णयलाई अर्को हप वास्तवमा बोक्ने टनेल बाटोसँग बाँध्नुहोस्, किनकि राउटिङ तालिका र टनेल तालिका कुन इन्टरफेस प्रयोग भइरहेको छ भन्नेमा असहमत हुन सक्छन्।

स्वीकृत अवलोकनअन्तर्गत तीनवटा कुरा छुट्टाछुट्टै पछ्याउनुहोस्: पहिचान, बाटो छनोट र अनुप्रयोगको आफ्नै पुनःप्राप्ति। त्यो क्रमले तपाईंलाई बताउँछ कि छुटेको भाग योग्य ब्याकअप हो, तलको VPN बाटो हो, वा कामको भार पुनः जोडिँदै छ — हरेक ढिलो पुनःप्राप्तिलाई अर्को टाइमर चाहिन्छ भनी मान्नुको सट्टा।

उपयोगी बानी भनेको अरू केही छुनु अघि असमानता जाँच्नु हो। यसका लागि एउटा आदेश चाहिन्छ र यसले बहस टुंग्याउँछ।