Правило зайвих тридцяти байтів для 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 — це не IP MTU. Заголовок IP і заголовок ICMP теж споживають байти, тож розмір навантаження, що проходить, відповідає більшому пакету на лінії. Перевірка, що проходить за одного розміру, також нічого не каже про послугу з іншим режимом VLAN або глибшим стеком міток. Тест вимірює один шлях, один розмір і одну форму навантаження, а послуга може змінювати всі три.

Гірше того, ping може проходити, поки великі кадри не проходять, бо перевірка задіяла шлях і розмір, які реальний трафік ніколи не використовує. Розглядайте це як одну точку даних про доступність, а не як специфікацію послуги рівня 2.

Коли кадр не вміщається

Якщо завеликі кадри неможливо передати і немає підтримуваного механізму фрагментації чи збирання, вони відкидаються, зазвичай без чіткої помилки на обох кінцях. Тоді застосунки показують тайм-аути під час масових передач, а інтерактивні сеанси залишаються здоровими, що змушує людей дивитися на міжмережеві екрани й маршрути замість підрахунку байтів.

З'ясуйте фактичний бюджет із провайдером: режим послуги, обробка тегів, глибина міток, керівне слово і точна межа, яку застосовує ваш пристрій. Запишіть припущення поруч із числом, бо інакше наступний інженер успадкує правило тридцяти байтів і загадку.