Jump to content

jumbo frame на стороне провайдера

ne-vlezay80

By ne-vlezay80
in У нага

 Share

Recommended Posts

ne-vlezay80

ne-vlezay80

Posted
Posted

Интересно, есть ли провайдеры, которые отдают jumbo frame своим клиентам? Я спрашиваю потому, что собрался тянуть l2 поток от провайдера через gretap. На коммутаторе при этом будет размер пакета 9216 байт. Коммутатор под управлением linux. И модет быть размер пакета выше чем 9000 байт на стыке с клиентом? Например 16384 байт. Кстати, в ssh туннеле максимальный размер пакета ограничен 16370 байтами. В yggdrasil максимальный mtu не ограничен и равен 65535 байт.

ne-vlezay80

ne-vlezay80

Posted
  • Author
Posted
11 минут назад, UglyAdmin сказал:

Считайте, что в Интернете MTU ВСЕГДА ограничен 1500.

Если будете брать VPN - там можно договариваться.

Линк будет пробрасываться через gretap до роутера.

Ivan_83

Ivan_83

Posted
Posted
1 час назад, ne-vlezay80 сказал:

И модет быть размер пакета выше чем 9000 байт на стыке с клиентом? Например 16384 байт.

См спецификации на эзернет и коммутаторы.

 

1 час назад, ne-vlezay80 сказал:

Кстати, в ssh туннеле максимальный размер пакета ограничен 16370 байтами.

Это проблемы ссш, о которых даже ОС не очень в курсе.

Даже если ссш клиент/сервер будет делать write()/send() на stream дескрипторе (файл, tcp/scp сокет) с ограниченным размером, скажем по 1 байту, это вовсе не означает что будут уходить пакеты с одним байтом, ОС может и будет такие данные склеивать внутри и агрегировать в пакеты большего размера.

 

1 час назад, ne-vlezay80 сказал:

В yggdrasil максимальный mtu не ограничен и равен 65535 байт.

Самопротиворечивое предложение.

rm_

rm_

Posted
Posted

Фрагментируйте. Лично проверял WireGuard с большим MTU, и внутри него VXLAN. Фрагментация средствами WG, в результате внутри ходили полные джамбо-фреймы в 9000 байт. Но работало что-то не очень, при крупных трансферах происходили странные затыки. GRETAP внутри WG работал лучше. Идеально беспроблемной работы ожидать всё равно не стоит, но порой полезно передать полные 9000, прежде всего если на обеих концах требуется добавить это в бридж с JF-локалкой.

ne-vlezay80

ne-vlezay80

Posted
  • Author
Posted
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 бит

ne-vlezay80

ne-vlezay80

Posted
  • Author
Posted

Только что попытался передать большой пакет через 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

 

sheft

sheft

Posted
Posted
10 часов назад, ne-vlezay80 сказал:

Интересно, есть ли провайдеры, которые отдают jumbo frame своим клиентам?

а зачем? с какой стороны интернета они могут придти? и по умолчанию джамбо у клиентов отключен. Я как то игрался с ним в пределах локалки, если включить на сервере, коммутаторе и клиенте, то всё нормально, как только появлялись клиенты с отключенным или неподдерживаемым джамбо (9к вместо 14к) начинался полтергейст. В итоге забил. Это должна быть очень маленькая локалка с полным контролем чтобы всё бегало как должно в теории.

ne-vlezay80

ne-vlezay80

Posted
  • Author
Posted
4 минуты назад, sheft сказал:

а зачем? с какой стороны интернета они могут придти? и по умолчанию джамбо у клиентов отключен. Я как то игрался с ним в пределах локалки, если включить на сервере, коммутаторе и клиенте, то всё нормально, как только появлялись клиенты с отключенным или неподдерживаемым джамбо (9к вместо 14к) начинался полтергейст. В итоге забил. Это должна быть очень маленькая локалка с полным контролем чтобы всё бегало как должно в теории.

а какой полтергейст и что за коммутаторы?

sheft

sheft

Posted
Posted

длинки des-3200, dgs-3000, dgs-3420, catalyst 2960

полтергейст во фризах и рваных графиках утилизации портов...

на длинках даже монитор пакетов в консоли странный, несмотря на поддержку 13к пакетов и отображении этого в вэбке-настройке коммутатора, show packet ports показывает группы фреймов с максимум 4096-9216

Ivan_83

Ivan_83

Posted
Posted
13 часов назад, sheft сказал:

а зачем? с какой стороны интернета они могут придти? и по умолчанию джамбо у клиентов отключен. Я как то игрался с ним в пределах локалки, если включить на сервере, коммутаторе и клиенте, то всё нормально, как только появлялись клиенты с отключенным или неподдерживаемым джамбо (9к вместо 14к) начинался полтергейст. В итоге забил. Это должна быть очень маленькая локалка с полным контролем чтобы всё бегало как должно в теории.

Ваш негативный опыт не репрезентативен.

Path MTU Discovery и другие механизмы должны работать в TCP, ICMP резать не надо, на шлюзе желательно делать MSS fix в 1472 (или сколько там, не помню), тогда всё работает вообще без проблем.

 

Последний раз я сталкивался с проблемами из за джамбы года 4 назад, когда пришёл работать програмером в одного провайдера.

У меня десктоп и внутриофисная локалка джамбу тянули, а вот ихний роутер в инет mss fix не делал и видимо что то ещё подрезалось, в итоге у меня домой TCP конектилось с MSS много больше 1500 и большие пакеты просто не проходили. Объяснение почему у них нет mss fix было весьма фееричным - роутер не тянет :)

sheft

sheft

Posted
Posted
2 часа назад, Ivan_83 сказал:

Ваш негативный опыт не репрезентативен

не буду спорить, опыты были лет 6 назад, тогда была ещё куча клиентов с XPюшами, в которой адаптивные механизмы TCP отсутствовали напрочь

Но опять же, какие коммутаторы на доступе стоят? если с 100шными портами то всё это не имеет смысла..

alibek

alibek

Posted
Posted

Заметная выгода от больших фреймов начинается от десятки.

Пока абонентское оборудование 10G не станет относительно распространенным, изменений не будет, на гигабите смысла в jumbo немного.

ne-vlezay80

ne-vlezay80

Posted
  • Author
Posted
56 минут назад, alibek сказал:

Заметная выгода от больших фреймов начинается от десятки.

Пока абонентское оборудование 10G не станет относительно распространенным, изменений не будет, на гигабите смысла в jumbo немного.

Его сложно будет тянуть через gretap

Ivan_83

Ivan_83

Posted
Posted
20 часов назад, alibek сказал:

Заметная выгода от больших фреймов начинается от десятки.

Пока абонентское оборудование 10G не станет относительно распространенным, изменений не будет, на гигабите смысла в jumbo немного.

Нет и нет.

 

Абонентское оборудование тут не при делах, зачем ты лезешь считать их деньги?)

Я дома эффекта от джамбы уже практически не вижу, после того сменил совсем хилый E-350 на 5350 в домашнем сервере, но джамба она не для меня делана.

 

С точки зрения и отдачи контента и транспорта (те хостенг и провайдинг) джамбо очень выгодна, ибо пакетрейт падает в разы - те почти в 6 раз. Те говоря очень утрированно, если у тебя какой то роутер на тазике роутил 10Г с загрузкой проца в 60% то 100Г с джамбой он пропустит с загрузкой 80%. (утрированно конечно)

 

alibek

alibek

Posted
Posted
46 минут назад, Ivan_83 сказал:

Абонентское оборудование тут не при делах

Если оно не будет поддерживать jumbo-фреймы, то и смысла его делать мало.

 

47 минут назад, Ivan_83 сказал:

пакетрейт падает в разы - те почти в 6 раз

Это на стенде.

А если сервер отдает пакетами по 1500 байт, то pps от этого не уменьшится.

А сервер будет отдавать именно такими пакетами, пока основной потребитель (абонент) в массе своей не заменит свое оборудование на новое, с поддержкой jumbo.

А у абонента причин этого делать нет, потому что на скоростях меньше 10G он ничего не ощутит от поддержки jumbo.

 

У меня есть СХД с портами 1/10G и протоколом iSCSI. И даже сам производитель не рекомендует включать jumbo на гигабите, потому что эффект будет мизерным, смысл включать jumbo есть только на 10G.

Ivan_83

Ivan_83

Posted
Posted

 

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.

jffulcrum

jffulcrum

Posted
Posted
41 минуту назад, alibek сказал:

У меня есть СХД с портами 1/10G и протоколом iSCSI. И даже сам производитель не рекомендует включать jumbo на гигабите, потому что эффект будет мизерным, смысл включать jumbo есть только на 10G.

И кто вендор?

ne-vlezay80

ne-vlezay80

Posted
  • Author
Posted

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.

 

jffulcrum

jffulcrum

Posted
Posted
2 часа назад, alibek сказал:

NetApp

Эти да, на своей волне. В IBM RedBook для ряда сценариев рекомендовалось и в гигабитные времена включать. 

 

На самом деле даже если вспомнить SAN/NAS, то:

 

- Сраный Любимый уже нет FreeBDSM имел проблемы с выделением буферов при использовании Jumbo. Нужны были особые танцы с бубнами и подбор сетевых драйверов

- жить все это должно было строго в выделенном сегменте, чтобы никакого другого трафика не ходило. Потому как даже базовые службы вроде NTP и DNS могли в сети с Jumbo работать очень странно, или не работать вообще. Что там, у меня Samba с Centos не работала - клиенты авторизоваться не могли при включенных Jumbo.

- у каждого вендора своя интерпретация введенного размера jumbo. Советую повключать на разном железе и посмотреть в wireshark, что же реально вылетает из портов. Некоторые вендоры любят втихую округлять введенное до ближайшей степени двойки, другие напрямую берут, а вот Broadcom чипы какие-то вообще игнорили, пока не введешь одно из предзаданных "совместимых" значений.

Ivan_83

Ivan_83

Posted
Posted
В 12.03.2020 в 22:43, ne-vlezay80 сказал:

geneve может передавать jumbo, если снять df. Вот разница в скорости

Нету разницы, потому что от снятия DF у тебя либо должно было сломаться либо оно и дальше юзает mtu в 9к.

 

23 часа назад, jffulcrum сказал:

FreeBDSM имел проблемы с выделением буферов при использовании Jumbo. Нужны были особые танцы с бубнами и подбор сетевых драйверов

Это если и было то очень давно, кажется уже в 9 или 10 ничего даже близко проблемного с буферами не наблюдалось.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.