MTU को EIGRP और OSPF जैसे आंतरिक लिंक स्टेट रूटिंग प्रोटोकॉल पर मिलान करने की आवश्यकता क्यों है?

Question

यदि कोई MTU से मेल किए बिना पड़ोसी आसन्न को कॉन्फ़िगर करने का प्रयास करता है, तो राउटर पड़ोसी बनने में विफल हो जाते हैं। मुझे लगता है कि यह रूटिंग प्रोटोकॉल को स्वयं से बचाने के लिए है, लेकिन मुझे समझ में नहीं आता कि यह खुद से क्या बचा रहा है? एमटीयू के मिलान के बिना क्या (परिणाम) हो सकता है?

Comments

क्या आप स्पष्ट कर सकते हैं कि आप जिस सटीक स्थिति के बारे में चिंतित हैं, वह आपको OSPF या EIGRP MTUs के बेमेल होने का कारण देगी?

— माइक पेनिंगटन

मैं ऐसी स्थिति के बारे में नहीं सोच सकता जहाँ आपको इसकी आवश्यकता होगी। मैं सिर्फ यह जानना चाहता था कि तर्क क्या था जो इन रूटिंग प्रोटोकॉल में एक स्पष्ट जाँच करता है।

— पीट

Answer 1

पीट ने कहा :

मैं ऐसी स्थिति के बारे में नहीं सोच सकता जहाँ आपको इसकी आवश्यकता होगी। मैं सिर्फ यह जानना चाहता था कि तर्क क्या था जो इन रूटिंग प्रोटोकॉल में एक स्पष्ट जाँच करता है।

संक्षिप्त जवाब

रूटिंग प्रोटोकॉल इंटरनेट पर सबसे मौलिक बिल्डिंग ब्लॉक में से कुछ हैं; हमें उन्हें हर संभव मामले में बहुत विश्वसनीय होने की आवश्यकता है। बेमेल MTU पर OSPF या EIGRP सन्निकट लाना अच्छा नहीं है।

राउटिंग प्रोटोकॉल को राउटर के फॉरवर्डिंग पथ से किसी भी संभावित बेमेल MTU को हटाना होगा।

लंबा जवाब

मैं तीन संभावित स्थितियों के बारे में सोच सकता हूँ जहाँ आपको आईजीपी एमटीयू बेमेल मिलेंगे ...

1. Layer2 पर अनजाने MTU बेमेल (उदाहरण के लिए, अगर किसी ने गलती से सीरियल लाइन पर MTUs को बेमेल कर दिया, या अलग-अलग विक्रेताओं के एक ही मीडिया पर अलग-अलग डिफ़ॉल्ट MTU थे )
2. Layer2 MTU का मिलान, लेकिन एक राउटर कार्यान्वयन में बग है जो आवश्यक इंटरफ़ेस IP MTU को गलत करता है
3. जानबूझकर एमटीयू बेमेल

IP MTUs सीधे Layer2 MTUs (कम से कम केस 1, ऊपर) के लिए सहसंबद्ध हैं। कोई फर्क नहीं पड़ता कि हम क्या करते हैं, हम हमेशा अनजाने Layer2 MTU बेमेल से समस्याओं को कम करने की दया पर हैं, क्योंकि Layer2 MTU खोज तंत्र (IP के विपरीत, जिसमें ICMP त्रुटि संदेश नहीं है) है।

इसका मतलब यह है कि Layer2 MTU बेमेल से बचने के लिए हमें हर संभव प्रयास करना होगा, भले ही मामले 2 और 3 से ऊपर के केस नंबर 1 के साथ समस्याओं को कम करने के हताहत हैं। केस 1 के बड़े पैमाने पर निहितार्थ हैं जब तक कि हम इसे हल नहीं करते; यानी सभी ट्रैफिक को ब्लैक-होल करना क्योंकि हमने एमटीयू की बेमेल अनुमति दी है।

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

नतीजतन, EIGRP और OSPF को मान्य Layer2 आसन्न ^{नोट 1} (MTUs सहित) की आवश्यकता होती है ।

एमटीयू के मिलान के बिना क्या (परिणाम) हो सकता है?

RFC 2329 पेज 4 में जॉन मोय (OSPF के लेखक) का हवाला देते हुए :

• सभी आईपी अग्रेषण के साथ समस्या
• OSPF समस्याएं

ओएसपीएफ मेलिंग सूची से उसे उद्धृत करना :

---

^{नोट 1} कुछ लोग आसन्न के अर्थ को गलत तरीके से समझते हैं जैसे कि एक आईपी मार्ग प्रोटोकॉल अवधारणा। यह दावा वास्तविकता को याद करता है कि सब कुछ (आईपी सहित) को लेयर 2 डोमेन को ठीक से काम करने के लिए मैचिंग लेयर 2 एमटीयू की आवश्यकता होती है।

रूटिंग प्रोटोकॉल के सबसे महत्वपूर्ण कार्यों में से एक एक वैध FIB / CEF / अग्रेषण तालिका का निर्माण करना है। वह तालिका जानकारी को राउटिंग प्रोटोकॉल के माध्यम से लेयर 2 में फिर से लिखने की जानकारी के लिए मैप करती है । एक ही भौतिक लिंक पर Layer2 संबंध वे हैं जिन्हें सिस्को भी आसन्नता कहता है।

Comments

धन्यवाद, माइक! मुझे लगता है कि मुझे जो हिस्सा याद आ रहा था, वह यह था कि एमटीयू के ऊपर एक पैकेट भेजने वाले राउटर पर खंडित है लेकिन प्राप्त राउटर पर छोड़ दिया गया है।

— पीट

काफी नहीं, बेमेल L2 MTUs एक गलत धारणा है, जो पूरी तरह से लागू करने के साथ मज़बूती से काम नहीं किया जा सकता है। सभी OSPF जानते हैं कि मौजूदा IP MTU सममित नहीं है, लेकिन इसे कैसे ठीक किया जाए, इसकी कोई जानकारी नहीं है। OSPF में विखंडन का समर्थन नहीं किया जाता है क्योंकि यह अभी भी केस 1 में एक टूटे हुए L2 डेटा प्लेन को छोड़ता है और OSPF को वास्तव में यह भी नहीं पता है कि बेमेल क्यों है

— माइक पेनिंगटन

Answer 2

के अनुसार ओएसपीएफ 2328 RFC (10.6):

यदि डेटाबेस विवरण पैकेट में इंटरफ़ेस MTU फ़ील्ड एक IP डेटाग्राम आकार इंगित करता है जो राउटर से बड़ा है जो विखंडन के बिना प्राप्त इंटरफ़ेस पर स्वीकार कर सकता है, तो डेटाबेस विवरण पैकेट अस्वीकार कर दिया जाता है।

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

OSPF RFC से अधिक:

4.3.  Routing protocol packets

    The OSPF protocol runs directly over IP, using IP protocol 89.
    OSPF does not provide any explicit fragmentation/reassembly
    support.  When fragmentation is necessary, IP
    fragmentation/reassembly is used.  OSPF protocol packets have
    been designed so that large protocol packets can generally be
    split into several smaller protocol packets.  This practice is
    recommended; IP fragmentation should be avoided whenever
    possible.

Comments

EIGRP और OSPF लेयर 2 आसन्न बनाते हैं और किसी भी लेयर 2 पर IP / डेटाग्राम विखंडन नहीं होता है। तो, बेमेल MTU का उपयोग करना असंभव है, भले ही मानक ने इसकी अनुमति दी हो।

— माइक पेनिंगटन

नकारात्मक। वे परत 3 आसन्न बनाते हैं, प्रोटोकॉल संचार आईपी मल्टीकास्ट (परत 3) का उपयोग करते हैं। यदि उन्होंने तकनीकी रूप से परत 2 समीपताएं बनाई हैं, तो आपको इंटरफ़ेस पर आईपी पते की आवश्यकता नहीं होगी।

— राबर्ट

RFC से ही: OSPF प्रोटोकॉल IP पर सीधे चलता है, IP प्रोटोकॉल 89 का उपयोग करके।

— रॉबर्ट

रॉबर्ट, आप आसन्न की परिभाषा को याद कर रहे हैं जो सिस्को का उपयोग करता है। कृपया किसी भी सिस्को राउटर पर "sh adjacency internal" देखें। CEF आसन्न तालिका के हिस्से के रूप में सभी Layer2 जानकारी का इलाज करता है; प्रत्येक प्रविष्टि पर दूसरी और तीसरी पंक्ति हेक्स लेयर 2 हैडर जानकारी है। IP को एक सुसंगत लेयर 2 की आवश्यकता होती है, तब भी जब यह सीधे जुड़ा होता है।

— माइक पेनिंगटन

तो आप L2 विखंडन के बिना बेमेल OSPF MTUs का समर्थन कैसे करते हैं? सभी RFC को एक तरफ फेंकते हुए, उत्तर सरल है ... बेमेल MTUs लेयर 2 पर टूट जाते हैं

— माइक पेनिंगटन