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 सेवाको विशिष्टता होइन।

फ्रेम नअटाउँदा

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

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