قاعده سی بایت اضافی MTU روی شبه‌سیم‌های MPLS شکسته می‌شود

از یک مهندس بپرسید برای MPLS چقدر اضافه کنید و عددی می‌شنوید، معمولاً سی، که با اطمینان گفته می‌شود. عدد آن‌قدر غلط نیست که بی‌ریشه است: کاملاً بستگی دارد به اینکه عدد شروع چه چیزی را می‌شمارد و لبه ارائه‌دهنده واقعاً چه چیزی ارسال می‌کند. روی یک شبه‌سیم Ethernet فرض‌ها آشکارند، و به‌محض اینکه آن‌ها را بنویسید، حساب جای افسانه را می‌گیرد.

سه چیز متفاوت زیر یک نام اندازه‌گیری می‌شود. بسته IP مشتری هست، قاب Ethernet که از شبه‌سیم عبور می‌کند، و قاب‌بندی پیوند بیرونی خود ارائه‌دهنده. بودجه‌ای که آن‌ها را با هم مخلوط کند، مقداری می‌دهد که هیچ فیلد دستگاهی انتظارش را ندارد.

یک بودجه محاسبه‌شده با بیان همه فرض‌ها

بسته IP مشتری با 1500 بایت، سرآیند Ethernet معمولی که بدون FCS مشتری از شبه‌سیم عبور می‌کند، بدون برچسب 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 نیستند

بار ping در IPv4 یک MTU IP نیست. سرآیند IP و سرآیند ICMP هم بایت مصرف می‌کنند، بنابراین اندازه باری که موفق می‌شود با بسته بزرگ‌تری روی سیم مطابقت دارد. کاوشی که در یک اندازه عبور می‌کند هم درباره سرویسی با حالت VLAN متفاوت یا پشته برچسب عمیق‌تر چیزی نمی‌گوید. آزمون یک مسیر، یک اندازه و یک شکل بار را می‌سنجد، و سرویس می‌تواند هر سه را تغییر دهد.

بدتر اینکه ping می‌تواند موفق شود در حالی که قاب‌های بزرگ شکست می‌خورند، چون کاوش مسیر و اندازه‌ای را آزموده که ترافیک واقعی هرگز استفاده نمی‌کند. آن را یک نقطه داده درباره دسترسی‌پذیری بدانید، نه مشخصه سرویس لایه 2.

وقتی قاب جا نمی‌شود

اگر قاب‌های بیش‌ازحد بزرگ قابل حمل نباشند و هیچ سازوکار تکه‌تکه‌سازی یا بازمونتاژ پشتیبانی‌شده‌ای وجود نداشته باشد، کنار گذاشته می‌شوند، معمولاً بدون خطای روشن در هیچ‌یک از دو سر. سپس برنامه‌ها در انتقال‌های انبوه مهلت نشان می‌دهند در حالی که نشست‌های تعاملی سالم می‌مانند، و این مردم را به سمت دیوارهای آتش و مسیرها می‌فرستد نه شمردن بایت‌ها.

بودجه واقعی را با ارائه‌دهنده روشن کنید: حالت سرویس، مدیریت برچسب، عمق برچسب، واژه کنترل و حد دقیقی که دستگاه شما اعمال می‌کند. فرض‌ها را کنار عدد بنویسید، چون در غیر این صورت مهندس بعدی قاعده سی بایت و یک معما را به ارث می‌برد.