Server 2012, Jumbo Frames - стоит ли ожидать проблем?

Хорошо, этот звук может быть глупым - но есть ли какой-то недостаток в том, чтобы просто включить на практике большие кадры?

Из того, что я понимаю:

• Любой коммутатор или сетевой адаптер, который видит гигантский фрейм, который он не может обработать, просто уронит его.
• TCP не является проблемой, так как максимальный размер кадра определяется на этапе setinuo.
• UCP является теоретической проблемой, поскольку сервер может просто отправить БОЛЬШОЙ UDP-пакет, который сбрасывается по пути.

Хотя на практике UDP основывается на пакетах, я не думаю, что какое-либо программное обеспечение отправило бы пакет UDP размером более 1500 байт без изменений конфигурации на уровне приложения - по крайней мере, так я делаю свое программирование, так как довольно сложно получить Приличный размер MTU для этого без тестирования, так что вы прибегаете к программированию до 1500 пакетов.

Рассматриваемая сеть является стандартной сетью для малого бизнеса - теперь мы перешли с неуправляемого 24-портового коммутатора на 52-портовый коммутатор с 4 портами 10g (netgear - довольно дешевый) и переместим файловый сервер на 10g для обслуживания ISCSI. Все мое оборудование на уровне Ethernet может обрабатывать минимум 9000 байт, и из-за локальных брандмауэров я действительно хочу получать пакеты большего размера (меньше обработки брандмауэром), но сеть также подключена к Интернету через NAT. Кроме того, различные машины часто перемещаются (загружают) большие файлы (размером в несколько гигабайт) для обработки.

Вопрос в том, можно ли ожидать проблем, когда я просто включаю большие кадры?

Опять же, это не совсем невежество - я просто не вижу программ, отправляющих более 1500 байтовых UDP-пакетов (если это практическая проблема, пожалуйста, сообщите мне), и для TCP MTU все равно согласовывается.

если есть проблема, я могу перейти к выделенной VLAN, но у нее есть свои проблемы, поскольку в основном большинство рабочих станций должны быть в обеих VLAN.