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 સેવાની સ્પેસિફિકેશન તરીકે નહીં.

જ્યારે ફ્રેમ બંધ બેસતી નથી

જો વધુ પડતી મોટી ફ્રેમ્સ વહન કરી શકાતી નથી અને કોઈ સમર્થિત ફ્રેગ્મેન્ટેશન કે પુનઃજોડાણ પદ્ધતિ નથી, તો તે ફેંકાઈ જાય છે, સામાન્ય રીતે બંને છેડે સ્પષ્ટ ભૂલ વિના. પછી એપ્લિકેશન્સ બલ્ક ટ્રાન્સફરમાં સમયસીમા દર્શાવે છે જ્યારે ઇન્ટરેક્ટિવ સેશન્સ સ્વસ્થ રહે છે, જે લોકોને બાઇટ ગણવાને બદલે ફાયરવોલ અને રૂટ તરફ ધકેલે છે.

પ્રદાતા સાથે વાસ્તવિક બજેટ સ્પષ્ટ કરો: સેવા મોડ, ટૅગ હેન્ડલિંગ, લેબલ ઊંડાઈ, કંટ્રોલ વર્ડ અને તમારું ઉપકરણ લાગુ કરે તે ચોક્કસ મર્યાદા. આંકડાની બાજુમાં ધારણાઓ લખો, નહીં તો આગલો એન્જિનિયર ત્રીસ બાઇટનો નિયમ અને એક રહસ્ય વારસામાં પામશે.