ne-vlezay80 Опубликовано 10 марта, 2020 · Жалоба Интересно, есть ли провайдеры, которые отдают jumbo frame своим клиентам? Я спрашиваю потому, что собрался тянуть l2 поток от провайдера через gretap. На коммутаторе при этом будет размер пакета 9216 байт. Коммутатор под управлением linux. И модет быть размер пакета выше чем 9000 байт на стыке с клиентом? Например 16384 байт. Кстати, в ssh туннеле максимальный размер пакета ограничен 16370 байтами. В yggdrasil максимальный mtu не ограничен и равен 65535 байт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 10 марта, 2020 · Жалоба Считайте, что в Интернете MTU ВСЕГДА ограничен 1500. Если будете брать VPN - там можно договариваться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 10 марта, 2020 · Жалоба 11 минут назад, UglyAdmin сказал: Считайте, что в Интернете MTU ВСЕГДА ограничен 1500. Если будете брать VPN - там можно договариваться. Линк будет пробрасываться через gretap до роутера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 марта, 2020 · Жалоба 1 час назад, ne-vlezay80 сказал: И модет быть размер пакета выше чем 9000 байт на стыке с клиентом? Например 16384 байт. См спецификации на эзернет и коммутаторы. 1 час назад, ne-vlezay80 сказал: Кстати, в ssh туннеле максимальный размер пакета ограничен 16370 байтами. Это проблемы ссш, о которых даже ОС не очень в курсе. Даже если ссш клиент/сервер будет делать write()/send() на stream дескрипторе (файл, tcp/scp сокет) с ограниченным размером, скажем по 1 байту, это вовсе не означает что будут уходить пакеты с одним байтом, ОС может и будет такие данные склеивать внутри и агрегировать в пакеты большего размера. 1 час назад, ne-vlezay80 сказал: В yggdrasil максимальный mtu не ограничен и равен 65535 байт. Самопротиворечивое предложение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 10 марта, 2020 · Жалоба Фрагментируйте. Лично проверял WireGuard с большим MTU, и внутри него VXLAN. Фрагментация средствами WG, в результате внутри ходили полные джамбо-фреймы в 9000 байт. Но работало что-то не очень, при крупных трансферах происходили странные затыки. GRETAP внутри WG работал лучше. Идеально беспроблемной работы ожидать всё равно не стоит, но порой полезно передать полные 9000, прежде всего если на обеих концах требуется добавить это в бридж с JF-локалкой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 10 марта, 2020 · Жалоба 2 часа назад, rm_ сказал: Фрагментируйте. Лично проверял WireGuard с большим MTU, и внутри него VXLAN. Фрагментация средствами WG, в результате внутри ходили полные джамбо-фреймы в 9000 байт. Но работало что-то не очень, при крупных трансферах происходили странные затыки. GRETAP внутри WG работал лучше. Идеально беспроблемной работы ожидать всё равно не стоит, но порой полезно передать полные 9000, прежде всего если на обеих концах требуется добавить это в бридж с JF-локалкой. А если провайдер на все пакеты выстовляет DF бит? 2 часа назад, rm_ сказал: Фрагментируйте. Лично проверял WireGuard с большим MTU, и внутри него VXLAN. Фрагментация средствами WG, в результате внутри ходили полные джамбо-фреймы в 9000 байт. Но работало что-то не очень, при крупных трансферах происходили странные затыки. GRETAP внутри WG работал лучше. Идеально беспроблемной работы ожидать всё равно не стоит, но порой полезно передать полные 9000, прежде всего если на обеих концах требуется добавить это в бридж с JF-локалкой. WG просто убирает df бит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 10 марта, 2020 · Жалоба Только что попытался передать большой пакет через ip6gretap. Результат - если в бридж не объединять, то всё нормально. Но если объединить в бридж, пакеты начинают отбрасываться хостом. [root@archlinux user]# ip -s -h li show dev gt0 5: gt0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc fq_codel master bridge0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether ca:60:fa:36:41:b5 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 30.3G 667k 0 0 0 0 TX: bytes packets errors dropped carrier collsns 6.26M 119k 228 228 0 0 [root@archlinux user]# ip -s -h li show dev test0 6: test0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue master bridge0 state UP mode DEFAULT group default qlen 1000 link/ether 6a:d0:fd:02:bf:77 brd ff:ff:ff:ff:ff:ff link-netns test RX: bytes packets errors dropped overrun mcast 3.36M 322 0 0 0 0 TX: bytes packets errors dropped carrier collsns 61.6k 78 0 0 0 0 [root@archlinux user]# ip -s -h li show dev gt0 5: gt0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc fq_codel master bridge0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether ca:60:fa:36:41:b5 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 30.3G 667k 0 0 0 0 TX: bytes packets errors dropped carrier collsns 6.26M 119k 228 228 0 0 [root@archlinux user]# ip -s -h li show dev test0 6: test0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue master bridge0 state UP mode DEFAULT group default qlen 1000 link/ether 6a:d0:fd:02:bf:77 brd ff:ff:ff:ff:ff:ff link-netns test RX: bytes packets errors dropped overrun mcast 3.36M 322 0 0 0 0 TX: bytes packets errors dropped carrier collsns 61.6k 78 0 0 0 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sheft Опубликовано 10 марта, 2020 · Жалоба 10 часов назад, ne-vlezay80 сказал: Интересно, есть ли провайдеры, которые отдают jumbo frame своим клиентам? а зачем? с какой стороны интернета они могут придти? и по умолчанию джамбо у клиентов отключен. Я как то игрался с ним в пределах локалки, если включить на сервере, коммутаторе и клиенте, то всё нормально, как только появлялись клиенты с отключенным или неподдерживаемым джамбо (9к вместо 14к) начинался полтергейст. В итоге забил. Это должна быть очень маленькая локалка с полным контролем чтобы всё бегало как должно в теории. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 10 марта, 2020 · Жалоба 4 минуты назад, sheft сказал: а зачем? с какой стороны интернета они могут придти? и по умолчанию джамбо у клиентов отключен. Я как то игрался с ним в пределах локалки, если включить на сервере, коммутаторе и клиенте, то всё нормально, как только появлялись клиенты с отключенным или неподдерживаемым джамбо (9к вместо 14к) начинался полтергейст. В итоге забил. Это должна быть очень маленькая локалка с полным контролем чтобы всё бегало как должно в теории. а какой полтергейст и что за коммутаторы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sheft Опубликовано 11 марта, 2020 · Жалоба длинки des-3200, dgs-3000, dgs-3420, catalyst 2960 полтергейст во фризах и рваных графиках утилизации портов... на длинках даже монитор пакетов в консоли странный, несмотря на поддержку 13к пакетов и отображении этого в вэбке-настройке коммутатора, show packet ports показывает группы фреймов с максимум 4096-9216 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 марта, 2020 · Жалоба 13 часов назад, sheft сказал: а зачем? с какой стороны интернета они могут придти? и по умолчанию джамбо у клиентов отключен. Я как то игрался с ним в пределах локалки, если включить на сервере, коммутаторе и клиенте, то всё нормально, как только появлялись клиенты с отключенным или неподдерживаемым джамбо (9к вместо 14к) начинался полтергейст. В итоге забил. Это должна быть очень маленькая локалка с полным контролем чтобы всё бегало как должно в теории. Ваш негативный опыт не репрезентативен. Path MTU Discovery и другие механизмы должны работать в TCP, ICMP резать не надо, на шлюзе желательно делать MSS fix в 1472 (или сколько там, не помню), тогда всё работает вообще без проблем. Последний раз я сталкивался с проблемами из за джамбы года 4 назад, когда пришёл работать програмером в одного провайдера. У меня десктоп и внутриофисная локалка джамбу тянули, а вот ихний роутер в инет mss fix не делал и видимо что то ещё подрезалось, в итоге у меня домой TCP конектилось с MSS много больше 1500 и большие пакеты просто не проходили. Объяснение почему у них нет mss fix было весьма фееричным - роутер не тянет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sheft Опубликовано 11 марта, 2020 · Жалоба 2 часа назад, Ivan_83 сказал: Ваш негативный опыт не репрезентативен не буду спорить, опыты были лет 6 назад, тогда была ещё куча клиентов с XPюшами, в которой адаптивные механизмы TCP отсутствовали напрочь Но опять же, какие коммутаторы на доступе стоят? если с 100шными портами то всё это не имеет смысла.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 марта, 2020 · Жалоба Полагаю лет через 10 начнётся кипиш по поводу что надо бы джамбу везде в инете, тк оно снижает нагрузку на сеть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 11 марта, 2020 · Жалоба Заметная выгода от больших фреймов начинается от десятки. Пока абонентское оборудование 10G не станет относительно распространенным, изменений не будет, на гигабите смысла в jumbo немного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 11 марта, 2020 · Жалоба 56 минут назад, alibek сказал: Заметная выгода от больших фреймов начинается от десятки. Пока абонентское оборудование 10G не станет относительно распространенным, изменений не будет, на гигабите смысла в jumbo немного. Его сложно будет тянуть через gretap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 марта, 2020 · Жалоба 20 часов назад, alibek сказал: Заметная выгода от больших фреймов начинается от десятки. Пока абонентское оборудование 10G не станет относительно распространенным, изменений не будет, на гигабите смысла в jumbo немного. Нет и нет. Абонентское оборудование тут не при делах, зачем ты лезешь считать их деньги?) Я дома эффекта от джамбы уже практически не вижу, после того сменил совсем хилый E-350 на 5350 в домашнем сервере, но джамба она не для меня делана. С точки зрения и отдачи контента и транспорта (те хостенг и провайдинг) джамбо очень выгодна, ибо пакетрейт падает в разы - те почти в 6 раз. Те говоря очень утрированно, если у тебя какой то роутер на тазике роутил 10Г с загрузкой проца в 60% то 100Г с джамбой он пропустит с загрузкой 80%. (утрированно конечно) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 12 марта, 2020 · Жалоба 46 минут назад, Ivan_83 сказал: Абонентское оборудование тут не при делах Если оно не будет поддерживать jumbo-фреймы, то и смысла его делать мало. 47 минут назад, Ivan_83 сказал: пакетрейт падает в разы - те почти в 6 раз Это на стенде. А если сервер отдает пакетами по 1500 байт, то pps от этого не уменьшится. А сервер будет отдавать именно такими пакетами, пока основной потребитель (абонент) в массе своей не заменит свое оборудование на новое, с поддержкой jumbo. А у абонента причин этого делать нет, потому что на скоростях меньше 10G он ничего не ощутит от поддержки jumbo. У меня есть СХД с портами 1/10G и протоколом iSCSI. И даже сам производитель не рекомендует включать jumbo на гигабите, потому что эффект будет мизерным, смысл включать jumbo есть только на 10G. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 марта, 2020 · Жалоба 29 минут назад, alibek сказал: А если сервер отдает пакетами по 1500 байт, то pps от этого не уменьшится. А сервер будет отдавать именно такими пакетами, пока основной потребитель (абонент) в массе своей не заменит свое оборудование на новое, с поддержкой jumbo. Будет. Нетфликс или ютуб в этом заинтересованы очень. Что они скажут - то вы и будете делать, пинаемые абонентами. Контакт, яндекс и потом уже мыло - подхватят. Для контакта актуально точно. 29 минут назад, alibek сказал: А у абонента причин этого делать нет, потому что на скоростях меньше 10G он ничего не ощутит от поддержки jumbo. Абонента никто не спрашивает от слова совсем в данном случае. Ему сделают красивый лейбл на коробку: 1G Jambo9k Certified и он будет рад что на одну лычку у его устройства больше, всё просто и понятно: больше лычек - круче девайс. Для расширения кругозора можешь посмотреть как простые фичи подаются маркетологами тех же материнок или телеков. 29 минут назад, alibek сказал: У меня есть СХД с портами 1/10G и протоколом iSCSI. И даже сам производитель не рекомендует включать jumbo на гигабите, потому что эффект будет мизерным, смысл включать jumbo есть только на 10G. Опять ты со своим домом и гигабитом :) Да пофик что у тебя эффекта мало, а вот что у нетфликса и гугла упадут затраты на отдачу контента - это не пофик. Ты же в курсе как тот же гугль продавил и никому нинужный https везде, DoH, DoT а потом долбанутый http/2? И сейчас свой допиленный vp9 под видом AV1 везде заходить начинает. Нужно что то из этого потребителю в твоём лице или твоим знакомым? Кто то тебя спросил? Оно у тебя уже есть или коснётся в ближайшем будущем? То-то и оно. Впереди у этих гигантов 8к, и нового кодека типа AV2 который им компенсирует рост потока не предвидеться, ну и так по мелочи всякие долби атмос всё больше заходят, там тоже прибавка к потому идёт. Но при этом производители домашней техники всё ещё лепят 100м порты даже в топовые модели телеков, саундбаров и хз куда ещё. Забавно что уже даже фотики 2016 года дают 100м поток видео, которое по проводной сети не пролезает....а пролезает только по вифи в теже девайсы. Это ваще какое то извращение, на мой взгляд. Но таки джамбо к ним через вифи наверное может зайти уже сейчас, хотя бы в виде 2304 MTU. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 марта, 2020 · Жалоба 41 минуту назад, alibek сказал: У меня есть СХД с портами 1/10G и протоколом iSCSI. И даже сам производитель не рекомендует включать jumbo на гигабите, потому что эффект будет мизерным, смысл включать jumbo есть только на 10G. И кто вендор? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 12 марта, 2020 · Жалоба geneve может передавать jumbo, если снять df. Вот разница в скорости: MTU внешнего интерфейса - 9000 байт Размер пакета 8950 байт. (Нормальный MTU) [root@arch user (0)] #> ip netns exec test iperf3 -c 192.168.1.2 Connecting to host 192.168.1.2, port 5201 [ 5] local 192.168.1.1 port 54516 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 436 MBytes 3.66 Gbits/sec 89 2.22 MBytes [ 5] 1.00-2.00 sec 522 MBytes 4.38 Gbits/sec 49 2.90 MBytes [ 5] 2.00-3.00 sec 556 MBytes 4.67 Gbits/sec 31 3.01 MBytes [ 5] 3.00-4.00 sec 530 MBytes 4.44 Gbits/sec 26 3.02 MBytes [ 5] 4.00-5.00 sec 541 MBytes 4.55 Gbits/sec 40 3.02 MBytes [ 5] 5.00-6.00 sec 542 MBytes 4.55 Gbits/sec 5 3.02 MBytes [ 5] 6.00-7.00 sec 519 MBytes 4.35 Gbits/sec 5 2.47 MBytes [ 5] 7.00-8.00 sec 548 MBytes 4.60 Gbits/sec 0 3.01 MBytes [ 5] 8.00-9.00 sec 524 MBytes 4.39 Gbits/sec 0 3.02 MBytes [ 5] 9.00-10.00 sec 530 MBytes 4.45 Gbits/sec 0 3.02 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 5.13 GBytes 4.40 Gbits/sec 245 sender [ 5] 0.00-10.00 sec 5.13 GBytes 4.40 Gbits/sec receiver Размер пакета 32768 байт. (Повышенный MTU) [root@arch user (0)] #> ip netns exec test iperf3 -c 192.168.1.2 Connecting to host 192.168.1.2, port 5201 [ 5] local 192.168.1.1 port 54530 connected to 192.168.1.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 488 MBytes 4.09 Gbits/sec 29 3.00 MBytes [ 5] 1.00-2.00 sec 500 MBytes 4.19 Gbits/sec 7 3.06 MBytes [ 5] 2.00-3.00 sec 491 MBytes 4.11 Gbits/sec 4 3.06 MBytes [ 5] 3.00-4.00 sec 488 MBytes 4.10 Gbits/sec 1 3.06 MBytes [ 5] 4.00-5.00 sec 491 MBytes 4.11 Gbits/sec 4 2.46 MBytes [ 5] 5.00-6.00 sec 496 MBytes 4.18 Gbits/sec 9 2.59 MBytes [ 5] 6.00-7.00 sec 494 MBytes 4.14 Gbits/sec 1 3.03 MBytes [ 5] 7.00-8.00 sec 474 MBytes 3.98 Gbits/sec 0 3.09 MBytes [ 5] 8.00-9.00 sec 484 MBytes 4.05 Gbits/sec 0 3.09 MBytes [ 5] 9.00-10.00 sec 511 MBytes 4.29 Gbits/sec 0 3.09 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 4.80 GBytes 4.12 Gbits/sec 55 sender [ 5] 0.00-10.00 sec 4.80 GBytes 4.12 Gbits/sec receiver iperf Done. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 12 марта, 2020 · Жалоба NetApp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 марта, 2020 · Жалоба 2 часа назад, alibek сказал: NetApp Эти да, на своей волне. В IBM RedBook для ряда сценариев рекомендовалось и в гигабитные времена включать. На самом деле даже если вспомнить SAN/NAS, то: - Сраный Любимый уже нет FreeBDSM имел проблемы с выделением буферов при использовании Jumbo. Нужны были особые танцы с бубнами и подбор сетевых драйверов - жить все это должно было строго в выделенном сегменте, чтобы никакого другого трафика не ходило. Потому как даже базовые службы вроде NTP и DNS могли в сети с Jumbo работать очень странно, или не работать вообще. Что там, у меня Samba с Centos не работала - клиенты авторизоваться не могли при включенных Jumbo. - у каждого вендора своя интерпретация введенного размера jumbo. Советую повключать на разном железе и посмотреть в wireshark, что же реально вылетает из портов. Некоторые вендоры любят втихую округлять введенное до ближайшей степени двойки, другие напрямую берут, а вот Broadcom чипы какие-то вообще игнорили, пока не введешь одно из предзаданных "совместимых" значений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 марта, 2020 · Жалоба В 12.03.2020 в 22:43, ne-vlezay80 сказал: geneve может передавать jumbo, если снять df. Вот разница в скорости Нету разницы, потому что от снятия DF у тебя либо должно было сломаться либо оно и дальше юзает mtu в 9к. 23 часа назад, jffulcrum сказал: FreeBDSM имел проблемы с выделением буферов при использовании Jumbo. Нужны были особые танцы с бубнами и подбор сетевых драйверов Это если и было то очень давно, кажется уже в 9 или 10 ничего даже близко проблемного с буферами не наблюдалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 15 марта, 2020 · Жалоба В 14.03.2020 в 01:38, Ivan_83 сказал: Нету разницы, потому что от снятия DF у тебя либо должно было сломаться либо оно и дальше юзает mtu в 9к. А как сломаться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...