Комментарии 17
Вроде бы прямым текстом не сказано, но: «мы» здесь это Метротек?
Ну, интересно ещё посмотреть на метрики второго порядка — как меняются, например, потери пакетов с ростом фонового трафика. Или с ростом его burst-ности.
Не совсем понял о чем вы.
Фоновый трафик при эталонных измерениях никак не может присутствовать на сети, поскольку он вносит свою погрешность. Если же мы говорим о тесте канала для клиента (например L2 vlan) и по нашей сети его пропускная способность ограничена шейперами, qos-policy или еще как-то, то фоновый трафик будет оказывать влияние на потери пакетов в этом канале лишь в случае oversale'а, либо в случае паразитного роста.
С ростом берстности потери пакетов зависят лишь от вашего оборудования, т.е. если заявлено, что оборудование работает 100% на wirespeed без ограничений (скажем, современные коммутаторы), то потерь не будет, если же указывается, что буфер рассчитан на 0.5 сек, например, (аппаратно-программные сигнатурные фильтры) то потери начнутся спустя это время из-за переполнения буфера.
Может быть вы имеете ввиду применение Теории телетрафика к реальным сетям и оценку взаимовлияния потоков данных?
Фоновый трафик при эталонных измерениях никак не может присутствовать на сети, поскольку он вносит свою погрешность. Если же мы говорим о тесте канала для клиента (например L2 vlan) и по нашей сети его пропускная способность ограничена шейперами, qos-policy или еще как-то, то фоновый трафик будет оказывать влияние на потери пакетов в этом канале лишь в случае oversale'а, либо в случае паразитного роста.
С ростом берстности потери пакетов зависят лишь от вашего оборудования, т.е. если заявлено, что оборудование работает 100% на wirespeed без ограничений (скажем, современные коммутаторы), то потерь не будет, если же указывается, что буфер рассчитан на 0.5 сек, например, (аппаратно-программные сигнатурные фильтры) то потери начнутся спустя это время из-за переполнения буфера.
Может быть вы имеете ввиду применение Теории телетрафика к реальным сетям и оценку взаимовлияния потоков данных?
Спасибо большое за статью. Не смотря на то, что знал основы темы, статья помогла узнать о многих интересных нюансах.
Остался вопрос: как наиболее корректно определить и установить на всех устройствах правильный MTU?
Допустим у меня интернет от провайдера через PPPoE (+ роутер). Следовательно я так понимаю надо сначала определить MTU до поднятия PPPoE, а потом вычесть из него дополнительное кол-во байт, которые появляются после инкапсуляции пакета в PPPoE?
Возможно просто не заморачиваться и/или это не актуально для «домашних пользователей»?
Остался вопрос: как наиболее корректно определить и установить на всех устройствах правильный MTU?
Допустим у меня интернет от провайдера через PPPoE (+ роутер). Следовательно я так понимаю надо сначала определить MTU до поднятия PPPoE, а потом вычесть из него дополнительное кол-во байт, которые появляются после инкапсуляции пакета в PPPoE?
Возможно просто не заморачиваться и/или это не актуально для «домашних пользователей»?
По идее, все должно работать автоматом, но если есть проблемы поставьте на своем роутере MTU 1492 (или меньше).
В большинстве случаев для домашних пользователей это не очень актуально, поскольку есть механизмы, позволяющие оборудованию определить MTU, например Path MTU Discovery, если мы говорим о классическом Ethernet. Кроме того, интернет провайдеры берут не себя большую часть головной боли, связанной с согласованием MTU. Например, как в вашем случае с PPPoE, при проектировании и строительстве сети оператор, скорее всего, учитывает совместимость сети с оборудованием, т.е. в классическом представлении выглядит это так: на сети MTU 1500, соответственно для PPPoE MTU понижается до 1492 (PPP Protocol ID (2) + PPPoE header (6) = 8). В качестве проверки вы можете выполнить ping, как указано в статье, указав размер пакета 1492 и ping должен пройти. В GNU/Linux можно выполнить команду:
$ ping -s 1492 -Mdo 8.8.8.8
К счастью опция PMTU Discovery у меня в роутере есть (прошивка Wive-ng) и включена. А вот команда не работает…
Пытался погуглить, но пока не нашёл, что за цифра в скобках (1520). Я так понимаю 1492 байта это так называемая «полезная часть», а остальные 28 байт что добавились — итоговый размер пакета с учётом заголовка со служебной частью (1520).
Попробовал выполнив нехитрые арифметические действия 1492-28=1464, выполнить команду ping -s 1464 -Mdo 8.8.8.8 (чтоб итоговый «вес» пакета был равен 1492 байта) и тоже получил облом:
Опытным путём установил что MTU у меня получается равен 1480
$ ping -s 1492 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1492(1520) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
Пытался погуглить, но пока не нашёл, что за цифра в скобках (1520). Я так понимаю 1492 байта это так называемая «полезная часть», а остальные 28 байт что добавились — итоговый размер пакета с учётом заголовка со служебной частью (1520).
Попробовал выполнив нехитрые арифметические действия 1492-28=1464, выполнить команду ping -s 1464 -Mdo 8.8.8.8 (чтоб итоговый «вес» пакета был равен 1492 байта) и тоже получил облом:
$ ping -s 1464 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.
From 172.16.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1480)
ping: local error: Message too long, mtu=1480
Опытным путём установил что MTU у меня получается равен 1480
$ ping -s 1452 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1452(1480) bytes of data.
72 bytes from 8.8.8.8: icmp_seq=1 ttl=48 (truncated)
Так он вам сразу честно ответил:
То, что вы задаете в опции -s в man описывается как:
Т.е. опция задает размер пакета (на самом деле payload, полезной части) и трансформирует его в реальный ICMP пакет со всеми заголовками. Таким образом в скобках указывается реальный размер сформированного пакета. Именно он и должен «протиснуться» в минимально доступный MTU канала.
Как видим, в первом случае пакет вообще не прошел. Во втором, ICMP честно сказал, что нужна фрагментация (происходит это где-то на границе MTU).
Опытным путем — это путем постепенного уменьшения MTU? Можно откусывать по 1.
Что касается вашего случая, то вполне вероятно, что где-то съедено еще 12 байт. Можно предположить, что канал в vlan'е — это 4 байта, к которому добавлен mpls-vpn — еще 8 байт, итого 12. Т.е. получается VLAN+MPLS_VPN+PPPoE=4+8+8=20, соответственно при настройке хоть одного коммутатора на пцти пакета на максимальный MTU 1500 мы получаем 1500-20=1480. Вроде все сходится. Но это лишь предположение.
На самом деле не думаю, что провайдер будет делать секрет из значения MTU, если вы его спросите, разве что ребята в саппорте могут быть реально не в курсе дела и ваш вопрос им покажется из области секретных материалов.
From 172.16.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1480)
ping: local error: Message too long, mtu=1480
То, что вы задаете в опции -s в man описывается как:
-s packetsize
Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
Т.е. опция задает размер пакета (на самом деле payload, полезной части) и трансформирует его в реальный ICMP пакет со всеми заголовками. Таким образом в скобках указывается реальный размер сформированного пакета. Именно он и должен «протиснуться» в минимально доступный MTU канала.
Как видим, в первом случае пакет вообще не прошел. Во втором, ICMP честно сказал, что нужна фрагментация (происходит это где-то на границе MTU).
Опытным путем — это путем постепенного уменьшения MTU? Можно откусывать по 1.
Что касается вашего случая, то вполне вероятно, что где-то съедено еще 12 байт. Можно предположить, что канал в vlan'е — это 4 байта, к которому добавлен mpls-vpn — еще 8 байт, итого 12. Т.е. получается VLAN+MPLS_VPN+PPPoE=4+8+8=20, соответственно при настройке хоть одного коммутатора на пцти пакета на максимальный MTU 1500 мы получаем 1500-20=1480. Вроде все сходится. Но это лишь предположение.
На самом деле не думаю, что провайдер будет делать секрет из значения MTU, если вы его спросите, разве что ребята в саппорте могут быть реально не в курсе дела и ваш вопрос им покажется из области секретных материалов.
Опытным путем — это путем постепенного уменьшения MTU? Можно откусывать по 1.
Ну почти. Мне ж терминал намекнул MTU=1480. От этого отнял 28 и получил 1452. А, например, 1453 уже не проходит
ping -s 1453 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1453(1481) bytes of data.
ping: local error: Message too long, mtu=1452
Глянул кстати в ifconfig, у меня на интерфейсе wlan0 MTU был 1500. Получается все пакеты с роутера уходили фрагментированные?
del
Скажите, пожалуйста, для тестов 10G есть что-то в вашей линейке?
Например, metrotek.spb.ru/b3etx.html
Есть и 100G ;)
Есть и 100G ;)
Большое спасибо за статью. К ней можно отсылать вопрошающих про спидтест и иные яндекс.интернеты.
Если хотите, пришлю Вам в ПМ список опечаток. Например, «Пропускная способность в кадрах в секнду»
значения в районе 30-60 мс в прямом соединении (cross-connect), в то время как сертифицированный тест покажет 8-16 нс, т.е. разница на порядок«Порядок» это «10». Посчитаем? 30/8=5, 30/16=1.875, 60/8=7.5, 60/16=3.75. В общем, 10 никак не получается. Не поддавайтесь на маркетологические уловки, будьте правдивы.
Если хотите, пришлю Вам в ПМ список опечаток. Например, «Пропускная способность в кадрах в секнду»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Качество сетей передачи данных. Программные и аппаратные измерения