EoIP и MTU

Просто установи свойство mtu для туннеля IPIP на 1500... он сможет отлично справиться с необходимой фрагментацией и дефрагментацией (с тороны приёма).

Потому что с одной стороны это лучшее решение, а с другой — худшее. И нет универсального варианта для всех случаев из-за количества некомпетентных сетевых администраторов. TCP изначально создан для автоматической подстройки размера пакета под самый маленький MTU на пути между клиентом и сервером. Так он максимально эффективно использует пропускную способность и ресурсы маршрутизации, разбивая данные на оптимальные куски ещё у источника.

Если же принудительно задать MTU равным 1500, а реальный минимальный MTU на пути меньше этого значения, каждый пакет, превышающий минимальный MTU, придётся фрагментировать. Это влечёт за собой две неприятные проблемы:

1. Дальше по пути пакет уже считается как два отдельных, из-за чего нагрузка по количеству пакетов на маршрутизаторы удваивается, а соотношение полезной нагрузки к накладным расходам ухудшается, поскольку у каждого фрагмента свой IP-заголовок (а иногда и Ethernet-заголовок).
2. Если какой-то маршрутизатор на пути сбрасывает не первые фрагменты (что случается удивительно часто, частично из-за неправильной настройки правил файрвола), полный пакет не собирается на приёмной стороне и фактически теряется целиком.

Так что если вы выставляете MTU 1500 на туннельном интерфейсе, вы удваиваете количество пакетов и добавляете лишние накладные расходы уже у себя на маршрутизаторе (потому что пакет с полезной нагрузкой 1500 вместе с накладными туннеля превышает 1500 интерфейса отправки и его придётся там же фрагментировать), но при этом соединение всё равно работает, даже если на пути между клиентом и сервером сломан Path MTU Detection (чаще всего из-за непрофессиональных админов, полностью блокирующих ICMP ради «безопасности из-за секретности»).

Однако это работает, только если не сбрасываются не первые фрагменты. То есть, если вам «повезёт», вы почините соединение к тем серверам, где PMTUD не работает, но при этом сломаете связь с теми, у кого на пути сбрасывают не первые фрагменты.

Пока не было времени разобраться. @tdw Трёхочковый бросок. vlan-filtering с BCP работает отлично. Только что проверил на v718. Не понимаю, как я мог пропустить это в списке изменений.

Не знаю. Фрагментация и дефрагментация пакетов работают корректно. Если я выставляю MTU 1500 на vCenter и отправляю ping -s 1472 -4 -M на remote_esx_IP, приходит ответ. Правила фаервола очень простые: немного входящего трафика, немного форварда. Неправильное правило должно приводить к сбросу пакетов для всех видов связи, но всё работает.

ПРИМЕЧАНИЕ: Если я выставляю MTU 1500, всё работает, но, например, если включаю виртуальную машину, она запускается, а в vCenter вместо статуса «Завершено» отображается «Включение виртуальной машины» и 100%. Правильного отклика нет. Если бы у меня были неправильные правила фаервола, я бы вообще не смог ничего сделать с ESXi.

Если установить MTU 1300 на vCenter, всё работает без проблем. И это случилось после замены Mikrotiks.

ПРИМЕЧАНИЕ 2: Веб-консоль тоже не показывается. Это был хороший момент, чтобы подобрать максимально возможный MTU — и им оказался 1402. В любом случае я попытался залогировать ICMP-пакеты на Mikrotiks и ESXi (vCenter по неизвестной причине не показывает ICMP-пакеты в tcpdump), и ни одного упоминания о фрагментированных пакетах нигде не было.