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

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

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