Jumbo frame. Рекомендованный размер

[fox_m]

Всем привет!

 

Назрела необходимость в настройке Jumbo frame на каналах связи. Есть какой-то рекомендованный размер или все сугубо индивидуально?

 

 

 

Edited March 14, 2024 by fox_m

[sol]

Хм. А вы ТОЧНО понимаете что, и главное, для чего собираетесь делать?

[sheft]

25 минут назад, fox_m сказал:

Назрела необходимость в настройке Jumbo frame на каналах связи. Есть какой-то рекомендованный размер или все сугубо индивидуально?

если назрела необходимость... то чем больше - тем лучше... но встаёт вопрос а какого размера фреймы умеют пропускать  коммутаторы на пути следования трафика, и упирается всё в железку у которой размер джамбы самый маленький -на неё и ровняйтесь

и не забудьте про тюнинг операционок на узлах между которыми собираетесь гонять трафик

[fox_m]

Понимаю) У нас есть стык с партнерами, у которых jumbo. У нас mtu 1548 (увеличен для работы с MPLS). И из за разного размера есть проблемы с работой протокола PIM. Вот и нужно согласовать размер jumbo

[Умник]

Возможно оффтоп, но можете в двух словах рассказать, что за проблемы возникают в работе PIM из-за того, что на соседних железках отличается максимальный размер кадра? Интересно. Похоже на проблему, которую пытались решить в этом предложении-черновике?

https://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/00/

[fox_m]

Была такая проблема:  мы отдавали партнеру мультикаст (через MSDP, но не принципиально наверно). И когда у них количество принимаемых групп достигло определенного числа, остальные стали тупо падать (не могли их принять). Как выяснилось, из за разных MTU (у нас было 1500 у них 9170), PIM на их стороне запихивал в одно сообщение групп больше, чем мы могли принять (или что-то в этом роде). Но проблема решилась установкой одинакового ipv4 mtu на интерфейсах.

 

"The Sending MTU state should be checked before sending a multicast PIM message, to ensure the length of the message does not exceed the MTU limit of both the sending and receiving links" - вроде что-то похоже.

Edited March 14, 2024 by fox_m

[rover-lt]

В 14.03.2024 в 10:03, fox_m сказал:

Всем привет!

 

Назрела необходимость в настройке Jumbo frame на каналах связи. Есть какой-то рекомендованный размер или все сугубо индивидуально?

 

 

 

Jumbo макс. размер у разных производителей разный. У кого 8000, у кого 9000, у кого 5000, у кого 4000. Это чисто L2 фишка. 
PIM - это L3+. L3 интерфейсы могут наследовать, а могут и не наследовать L2 MTU. 
IP пейлоад и все заголовки посчитайте - это будет необходимым минимумом. Больше все равно возьмется. 

[jffulcrum]

Jumbo frames - это штука исключительно для контролируемого окружения, где все участники имеют возможность и желание разбираться с его работой и возникающими проблемами. Проблемы могут возникать разнообразнейшие. К примеру, сервер под виндой успешно работает с Jumbo Frames 8К, а после перехода на Linux внезапно умеет уже только 4К. Или при включении какого-то протокола на роутере максимальный размер Jumbo меняется, причем без предупреждения. Дополнительно, даже сетевое железо, особенно недорогое, не всегда тщательно тестируется производителем для всех сценариев с Jumbo, и после включения начинают лезть глюки. С дешевым железом все еще и ухудшается проблемой нехватки буферов при переливе между разноскоростными подключениями - там и так обычно буфера кот нассал, а с Jumbo становится еще жестче. QoS с Jumbo я не припоминаю за 25 лет ни одного случая, когда оно работало как написано в мануале "искаропки", всегда приходилось открывать тикеты у вендора. Да даже сама настройка не всегда очевидна, например на одной стороне написано в интерфейсе: 9К, и на другой - 9К, вот только у первой это на самом деле 9000, а у второй 9216. Так что вы должны быть на 100% уверены в соседе, что у того еть время и способности на достижение работоспособной конфигурации. Хотя это и не исключает ситуаций "прокатило".

[rm_]

Quote

сервер под виндой успешно работает с Jumbo Frames 8К, а после перехода на Linux внезапно умеет уже только 4К

Как вариант, заменить древние карты реалтек с рукожоп-дровами на что-то нормальное.

 

Quote

у первой это на самом деле 9000, а у второй 9216. Так что вы должны быть на 100% уверены в соседе

По TCP будет работать с наименьшим из двух размером пакетов. А разрабы протоколов поверх UDP обычно и не закладываются, что там джамбо-фреймы могут быть вообще.

[jffulcrum]

49 минут назад, rm_ сказал:

Как вариант, заменить древние карты реалтек с рукожоп-дровами на что-то нормальное.

Забавно, я как раз с Intel сталкивался. Даже с X520 было поначалу. А Emulex один раз вообще на все деньги порадовал, в сеть отдавал пакеты на 512 байт меньше, чем в настройках, и выяснилось это только с помощью Wireshark. Разумеется, потом уже нашлась технота, где было сказано "это не баг, это фича, читайте мелким шрифтом".

 

1 час назад, rm_ сказал:

По TCP будет работать с наименьшим из двух размером пакетов. А разрабы протоколов поверх UDP обычно и не закладываются, что там джамбо-фреймы могут быть вообще.

Это еще пока у нас два участника. Там еще коммутаторы и роутеры есть, а если еще и инкапсуляция какая, в GRE/MPLS/VxLAN, то вообще веселье. Но больше всего радовали коробки безопасников. Одна, вроде Watchguard, вообще тупо резала все фреймы выше 1532, ибо "в интернете таких пакетов не бывает, это всё хакеры, крекеры, куки, спамы"

[ne-vlezay80]

Цитата

Это еще пока у нас два участника. Там еще коммутаторы и роутеры есть, а если еще и инкапсуляция какая, в GRE/MPLS/VxLAN, то вообще веселье. Но больше всего радовали коробки безопасников. Одна, вроде Watchguard, вообще тупо резала все фреймы выше 1532, ибо "в интернете таких пакетов не бывает, это всё хакеры, крекеры, куки, спамы"

Ну, можно через gre jumbo пустить (если указать nopmtudisc ignore-df) в linux (нужны будут ipv4 адреса на wg туннелях)

[myst]

джамбо надо выбрать по минимальному для всех участников. 

[shurdre]

размер кадра надо выбирать такой, какой прописан в БЗ (бланк заказа).

Edited April 7, 2024 by shurdre