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 পরিষেবার স্পেসিফিকেশন হিসেবে নয়।

যখন ফ্রেম ফিট করে না

যদি অতিরিক্ত বড় ফ্রেম বহন করা না যায় এবং কোনো সমর্থিত ফ্র্যাগমেন্টেশন বা পুনঃসংযোজন ব্যবস্থা না থাকে, তবে সেগুলো বাদ পড়ে, সাধারণত উভয় প্রান্তে পরিষ্কার ত্রুটি ছাড়াই। তখন অ্যাপ্লিকেশনগুলো বাল্ক ট্রান্সফারে সময়সীমা দেখায়, যেখানে ইন্টারঅ্যাকটিভ সেশন সুস্থ থাকে, ফলে মানুষ বাইট গণনার বদলে ফায়ারওয়াল ও রুটের দিকে তাকায়।

প্রোভাইডারের সঙ্গে প্রকৃত বাজেট নির্ধারণ করুন: পরিষেবা মোড, ট্যাগ পরিচালনা, লেবেল গভীরতা, কন্ট্রোল ওয়ার্ড এবং আপনার ডিভাইস যে সঠিক সীমা প্রয়োগ করে। সংখ্যার পাশে অনুমানগুলো লিখে রাখুন, নইলে পরবর্তী ইঞ্জিনিয়ার ত্রিশ বাইটের নিয়ম ও একটি রহস্য উত্তরাধিকার পাবে।