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 सेवेचे विनिर्देश म्हणून नाही.

फ्रेम बसत नाही तेव्हा

जर जास्त मोठ्या फ्रेम वाहून नेता येत नाहीत आणि समर्थित विभाजन किंवा पुनर्संयोजन यंत्रणा नाही, तर त्या टाकून दिल्या जातात, सहसा दोन्ही टोकांना स्पष्ट त्रुटीशिवाय. मग अनुप्रयोग मोठ्या हस्तांतरणांमध्ये वेळमर्यादा दाखवतात तर परस्परसंवादी सत्रे निरोगी राहतात, ज्यामुळे लोक बाइट मोजण्याऐवजी फायरवॉल आणि मार्ग पाहू लागतात.

प्रदात्यासोबत खरे बजेट स्पष्ट करा: सेवा मोड, टॅग हाताळणी, लेबल खोली, नियंत्रण शब्द आणि तुमचे उपकरण लागू करणारी नेमकी मर्यादा. संख्येच्या शेजारी गृहीतके लिहा, अन्यथा पुढच्या अभियंत्याला तीस-बाइट नियम आणि एक कोडे वारसात मिळेल.