MPLS स्यूडोवायर पर MTU के लिए अतिरिक्त तीस बाइट का नियम टूट जाता है

किसी इंजीनियर से पूछें कि MPLS के लिए कितना जोड़ना है और आप एक संख्या सुनेंगे, आमतौर पर तीस, आत्मविश्वास से कही गई। संख्या उतनी गलत नहीं है जितनी जड़विहीन: यह पूरी तरह इस पर निर्भर है कि शुरुआती संख्या क्या गिनती है और प्रदाता का किनारा वास्तव में क्या भेजता है। Ethernet स्यूडोवायर पर मान्यताएँ दिखाई देती हैं, और जैसे ही आप उन्हें लिख लेते हैं, अंकगणित लोककथा की जगह ले लेता है।

एक ही नाम के नीचे तीन अलग चीज़ें मापी जाती हैं। ग्राहक का IP पैकेट है, स्यूडोवायर पर ले जाया जाने वाला Ethernet फ़्रेम है, और प्रदाता का अपना बाहरी लिंक फ़्रेमिंग है। इन्हें मिलाने वाला बजट ऐसा मान देता है जिसकी कोई डिवाइस फ़ील्ड अपेक्षा नहीं करती।

हर मान्यता स्पष्ट करते हुए एक गणना किया गया बजट

1500 बाइट का ग्राहक IP पैकेट, ग्राहक के FCS के बिना स्यूडोवायर पर ले जाया जाने वाला सामान्य Ethernet हेडर, कोई सुरक्षित VLAN टैग नहीं, दो प्रविष्टियों वाला लेबल स्टैक और चार बाइट का नियंत्रण शब्द लें। ले जाया गया Ethernet हेडर 14 जोड़ता है, सुरक्षित टैग कुछ नहीं जोड़ते, दो लेबल प्रविष्टियाँ 8 जोड़ती हैं क्योंकि प्रत्येक प्रविष्टि 4 बाइट है, और नियंत्रण शब्द 4 जोड़ता है। इससे 1526 बाइट का MPLS-एनकैप्सुलेटेड पैकेट बनता है।

परिणाम ध्यान से पढ़ें। यह प्रदाता लिंक के बाहरी Ethernet हेडर और उसके FCS को छोड़ देता है, और यह एक उदाहरण है, MTU नाम के किसी भी फ़ील्ड में लिखने के लिए स्थिरांक नहीं। दो लेबल भी एक मान्यता है: वास्तविक स्टैक एक ट्रांसपोर्ट लेबल, एक सेवा लेबल और कभी-कभी अधिक ले जा सकता है, और प्रत्येक प्रविष्टि की लागत वही 4 बाइट है।

स्यूडोवायर से वास्तव में क्या गुज़रता है

RFC 4448 परिभाषित करता है कि Ethernet फ़्रेम MPLS के भीतर कैसे यात्रा करते हैं, और इसके सामान्य मॉडल में ग्राहक की प्रस्तावना और FCS इनग्रेस पर हटा दिए जाते हैं और एग्रेस पर फिर से बनाए जाते हैं। इसीलिए FCS ऊपर के बजट में नहीं दिखता। VLAN का संचालन सेवा मोड पर निर्भर करता है: ग्राहक के टैग सुरक्षित रखने वाला मोड उनके बाइट वापस जोड़ता है, और उन्हें मैप करने वाला मोड ऐसा नहीं करता। अतिरिक्त संरक्षण या अतिरिक्त एनकैप्सुलेशन ऊपर से गिनना पड़ता है।

नियंत्रण शब्द जब भी उपयोग होता है, अंकगणित का हिस्सा होता है। RFC 8469 इसे Ethernet स्यूडोवायर के लिए अनुशंसित करता है, इसलिए इसे वैकल्पिक बताने वाला पुराना पाठ इस बात का प्रमाण नहीं है कि आपका पथ इसे छोड़ देता है। आरेख से अनुमान लगाने के बजाय प्रदाता से वास्तविक सेवा मोड की पुष्टि करें।

संख्या की तुलना सही फ़ील्ड से करें

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

इसीलिए असंबंधित प्लेटफ़ॉर्म के बीच मान कॉपी करना जोखिम भरा है। फ़ील्ड का नाम ही विनिर्देश है, दूसरे विक्रेता के कंसोल से याद रही दशमलव संख्या नहीं।

ping पेलोड MTU मान नहीं हैं

IPv4 ping का पेलोड IP MTU नहीं है। IP हेडर और ICMP हेडर भी बाइट खर्च करते हैं, इसलिए सफल होने वाला पेलोड आकार तार पर बड़े पैकेट के बराबर होता है। एक आकार में पास होने वाली जाँच किसी भिन्न VLAN मोड या गहरे लेबल स्टैक वाली सेवा के बारे में कुछ नहीं कहती। परीक्षण एक पथ, एक आकार और एक पेलोड आकार मापता है, और सेवा तीनों बदल सकती है।

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

जब फ़्रेम फिट नहीं होता

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

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