OSPF अधिकतम मेट्रिक: शाखा हटाउनुबिना नै त्यसको ट्रान्जिट निरुत्साहित गर्ने

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

तपाईंले चाहेको कुरा राउटिङ प्रोटोकलमा व्यक्त गरिएको प्राथमिकता हो, जसले शाखालाई पूर्ण रूपमा पुग्न सकिने राख्छ र यसबाट जाने जुनसुकै कुराका लागि यसलाई खराब विकल्प बनाउँछ। राउटरहरूले समस्या देख्ने क्रममै हिँड्नुहोस्।

बच्न चाहेको मार्गबाट सुरु गर्नुहोस्

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

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

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

यी तीन दृश्यहरू फरक प्रश्नको उत्तर दिन्छन्: को छिमेकी हो, कुन इन्टरफेसहरू कुन लागतमा सहभागी हुन्छन्, र यन्त्रले अहिले कुन मार्ग छान्छ। टनेल तैनाथीले चौथो थप्छ: रेखाचित्रमा एउटा रेखा त्यसबाट छिमेकीपन बनेको प्रमाण होइन, र बनेको छिमेकीपन फर्वार्डिङ त्यही मार्गमा जान्छ भन्ने प्रमाण होइन। टनेल डिजाइनमै यो खाडल सबैभन्दा धेरै देखिन्छ।

अधिकतम मेट्रिक के घोषणा गर्छ

RFC 6987 ले आफ्ना गैर-स्टब लिङ्कहरू अधिकतम लिङ्क मेट्रिकसँग घोषणा गर्ने राउटर वर्णन गर्छ, जुन 0xffff का रूपमा परिभाषित छ। राउटरले अझै आफूलाई र आफ्ना लिङ्कहरूलाई वर्णन गर्छ; यसले तिनीहरूलाई दायराको माथिल्लो भागमा मूल्य लगाउँछ, त्यसैले अरू हरेक राउटरले यसबाट जाने मार्गलाई महँगो मान्छ।

यो router-LSA परिवर्तन हो, टोपोलोजी हटाउनु होइन। भिन्नता महत्त्वपूर्ण छ: router-LSA फ्लस गर्दा टोपोलोजी जानकारी आफैँ फिर्ता लिइन्छ, जसले राउटर र त्यसपछाडिका प्रिफिक्ससम्म पुग्न आवश्यक सम्बन्धहरू पनि फिर्ता लिन सक्छ। घोषणा राख्ने र यसको मूल्य बढाउनेले ती सम्बन्ध जोगाउँछ। यो तकनिक र हटाउनेबीचको सम्पूर्ण भिन्नता यही हो।

RFC 6987 संयन्त्रको क्षेत्र प्रकार वा नामित-राउटर छनोटसँग पनि कुनै सम्बन्ध छैन। स्टब क्षेत्रले क्षेत्र सीमामा लिङ्क-स्टेट घोषणाको एउटा वर्ग अवरोध गर्छ, र स्टब राउटरले आफ्नै लिङ्कको मूल्य लगाउँछ। समान शब्द, असम्बन्धित यन्त्र।

किन पुग्न सकिने क्षमता टिक्छ र ट्रान्जिट टिक्दैन

अरू राउटरसँग अझै शाखाका जोडिएका प्रिफिक्ससम्मको रुट छ, किनकि शाखाले ती अझै घोषणा गर्छ र लिङ्कहरू अझै छन्। परिवर्तन हुने कुरा अन्यत्र जाँदा शाखाबाट जाने जुनसुकै मार्गको कुल लागत हो। प्रिफिक्सहरू सर्दैनन्; राउटर तर्ने मूल्य मात्र परिवर्तन हुन्छ।

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

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

अन्तिम मार्गको समस्या

त्यही RFC ले यो तकनिकले प्रयोग निषेध नगर्ने स्पष्ट पार्छ। वैकल्पिक मार्ग असफल हुँदा, राउटरहरू शाखाबाट जाने महँगो मार्गमा फर्किन्छन्, किनकि त्यो अझै वैध मार्ग हो र प्रोटोकलले रुट नहुनुभन्दा महँगो रुटलाई प्राथमिकता दिन्छ।

त्यो फर्किने कुरा स्वीकार्य छ कि छैन भन्ने तैनाथी अघि जवाफ दिनुपर्ने नीतिगत प्रश्न हो। सानो अपलिङ्कमा रहेको शाखाले अचानक कार्यालयबीचको ट्राफिक बोक्न थाल्यो भने त्यो अवरोधभन्दा पनि नराम्रो हुन सक्छ, र मर्मत विन्डोमा त्यो ठ्याक्कै तपाईंले चाहेको कुरा पनि हुन सक्छ। दुवै उत्तर वैध छन्; मौनता होइन।

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

OSPFv3 का लागि RFC ले R-बिटलाई ट्रान्जिट सहभागिता बाहिर राख्ने फरक तरिकाका रूपमा चर्चा गर्छ। यसले अधिकतम-मेट्रिक तकनिकजस्तै अन्तिम-मार्ग व्यवहार वंशानुगत पाउँछ भनी नमान्नुहोस्, र दुई ठेगाना परिवारबीच एउटै सुविधा भएझैँ सेटिङ प्रतिलिपि नगर्नुहोस्।

सामान्य र असफल अवस्थामा यो प्रमाणित गर्नुहोस्

दुई पटक परीक्षण गर्नुहोस्: एक पटक दुवै मार्ग उपलब्ध हुँदा, र एक पटक प्राथमिक मार्ग हटाइएको अवस्थामा। पहिलो परीक्षणले प्राथमिकता काम गरिरहेको देखाउँछ, र दोस्रोले प्राथमिकताको पालना गर्न नसकिँदा सञ्जालले के गर्छ भनी देखाउँछ। दोस्रो परीक्षण छोड्दा महत्त्वपूर्ण आधा भाग नजाँचिएको रहन्छ।

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

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

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