fox_m Опубликовано 14 марта (изменено) · Жалоба Всем привет! Назрела необходимость в настройке Jumbo frame на каналах связи. Есть какой-то рекомендованный размер или все сугубо индивидуально? Изменено 14 марта пользователем fox_m Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 14 марта · Жалоба Хм. А вы ТОЧНО понимаете что, и главное, для чего собираетесь делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sheft Опубликовано 14 марта · Жалоба 25 минут назад, fox_m сказал: Назрела необходимость в настройке Jumbo frame на каналах связи. Есть какой-то рекомендованный размер или все сугубо индивидуально? если назрела необходимость... то чем больше - тем лучше... но встаёт вопрос а какого размера фреймы умеют пропускать коммутаторы на пути следования трафика, и упирается всё в железку у которой размер джамбы самый маленький -на неё и ровняйтесь и не забудьте про тюнинг операционок на узлах между которыми собираетесь гонять трафик Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 14 марта · Жалоба Понимаю) У нас есть стык с партнерами, у которых jumbo. У нас mtu 1548 (увеличен для работы с MPLS). И из за разного размера есть проблемы с работой протокола PIM. Вот и нужно согласовать размер jumbo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 14 марта · Жалоба Возможно оффтоп, но можете в двух словах рассказать, что за проблемы возникают в работе PIM из-за того, что на соседних железках отличается максимальный размер кадра? Интересно. Похоже на проблему, которую пытались решить в этом предложении-черновике? https://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/00/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 14 марта (изменено) · Жалоба Была такая проблема: мы отдавали партнеру мультикаст (через 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" - вроде что-то похоже. Изменено 14 марта пользователем fox_m Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rover-lt Опубликовано 26 марта · Жалоба В 14.03.2024 в 10:03, fox_m сказал: Всем привет! Назрела необходимость в настройке Jumbo frame на каналах связи. Есть какой-то рекомендованный размер или все сугубо индивидуально? Jumbo макс. размер у разных производителей разный. У кого 8000, у кого 9000, у кого 5000, у кого 4000. Это чисто L2 фишка. PIM - это L3+. L3 интерфейсы могут наследовать, а могут и не наследовать L2 MTU. IP пейлоад и все заголовки посчитайте - это будет необходимым минимумом. Больше все равно возьмется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 26 марта · Жалоба Jumbo frames - это штука исключительно для контролируемого окружения, где все участники имеют возможность и желание разбираться с его работой и возникающими проблемами. Проблемы могут возникать разнообразнейшие. К примеру, сервер под виндой успешно работает с Jumbo Frames 8К, а после перехода на Linux внезапно умеет уже только 4К. Или при включении какого-то протокола на роутере максимальный размер Jumbo меняется, причем без предупреждения. Дополнительно, даже сетевое железо, особенно недорогое, не всегда тщательно тестируется производителем для всех сценариев с Jumbo, и после включения начинают лезть глюки. С дешевым железом все еще и ухудшается проблемой нехватки буферов при переливе между разноскоростными подключениями - там и так обычно буфера кот нассал, а с Jumbo становится еще жестче. QoS с Jumbo я не припоминаю за 25 лет ни одного случая, когда оно работало как написано в мануале "искаропки", всегда приходилось открывать тикеты у вендора. Да даже сама настройка не всегда очевидна, например на одной стороне написано в интерфейсе: 9К, и на другой - 9К, вот только у первой это на самом деле 9000, а у второй 9216. Так что вы должны быть на 100% уверены в соседе, что у того еть время и способности на достижение работоспособной конфигурации. Хотя это и не исключает ситуаций "прокатило". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 26 марта · Жалоба Quote сервер под виндой успешно работает с Jumbo Frames 8К, а после перехода на Linux внезапно умеет уже только 4К Как вариант, заменить древние карты реалтек с рукожоп-дровами на что-то нормальное. Quote у первой это на самом деле 9000, а у второй 9216. Так что вы должны быть на 100% уверены в соседе По TCP будет работать с наименьшим из двух размером пакетов. А разрабы протоколов поверх UDP обычно и не закладываются, что там джамбо-фреймы могут быть вообще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 26 марта · Жалоба 49 минут назад, rm_ сказал: Как вариант, заменить древние карты реалтек с рукожоп-дровами на что-то нормальное. Забавно, я как раз с Intel сталкивался. Даже с X520 было поначалу. А Emulex один раз вообще на все деньги порадовал, в сеть отдавал пакеты на 512 байт меньше, чем в настройках, и выяснилось это только с помощью Wireshark. Разумеется, потом уже нашлась технота, где было сказано "это не баг, это фича, читайте мелким шрифтом". 1 час назад, rm_ сказал: По TCP будет работать с наименьшим из двух размером пакетов. А разрабы протоколов поверх UDP обычно и не закладываются, что там джамбо-фреймы могут быть вообще. Это еще пока у нас два участника. Там еще коммутаторы и роутеры есть, а если еще и инкапсуляция какая, в GRE/MPLS/VxLAN, то вообще веселье. Но больше всего радовали коробки безопасников. Одна, вроде Watchguard, вообще тупо резала все фреймы выше 1532, ибо "в интернете таких пакетов не бывает, это всё хакеры, крекеры, куки, спамы" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 27 марта · Жалоба Цитата Это еще пока у нас два участника. Там еще коммутаторы и роутеры есть, а если еще и инкапсуляция какая, в GRE/MPLS/VxLAN, то вообще веселье. Но больше всего радовали коробки безопасников. Одна, вроде Watchguard, вообще тупо резала все фреймы выше 1532, ибо "в интернете таких пакетов не бывает, это всё хакеры, крекеры, куки, спамы" Ну, можно через gre jumbo пустить (если указать nopmtudisc ignore-df) в linux (нужны будут ipv4 адреса на wg туннелях) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 28 марта · Жалоба джамбо надо выбрать по минимальному для всех участников. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shurdre Опубликовано 7 апреля (изменено) · Жалоба размер кадра надо выбирать такой, какой прописан в БЗ (бланк заказа). Изменено 7 апреля пользователем shurdre Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
