[anp/hsw] Опубликовано 6 марта, 2021 · Жалоба Здравствуйте! Столкнулся с удивительной проблемой: у исходящего TCP трафика не происходит window update, в результате чего скорость крайне маленькая (1-2мбит). Схема подключения такая: клиент -> свич -> PPP NAS -> свич -> NAT BOX -> внешка Все это добро подключено через гиговые порты, т.е. проблемы буферов нет (LACP на 2 порта у NAS и на 4 порта у NAT BOX, я пробовал их разваливать до одного порта - это не помогает). PPP NAS занимается терминацией, NAT BOX - BGP+шейпер+NAT. Все это добро на linux 3.2. До региональный и городских точек все нормально - и исходящий в иходящий в норме, но как только мы начинаем тест до москвы/забугра, так сразу исходящая резко падает с ростом RTT (>80мс). Проверяем через iperf3 и speedtest.net Клиент при подключении ppp (не важно - pptp, pppoe или l2tp) получает входящий поток в силу своих возможностей (в районе 300мбит), но исходящий от него колеблется от 1 до 3мбит. Если этого же клента подключить по подключению не используя PPP (gre/ipip-тунель, vlan, untagged ethernet), то исходящего он может нагенерить в районе 50 мегабит, и все это пролазит. UDP исходящий при этом всегда стабильно высокий и без потерь. Меняем клиента на чистую Win7 с тесового ноутбука - ситуация повторяется. Сняли дампы со всех интерфейсов по цепочке: В случае с ppp они оказались полностью идентичны за исключением переговоров по MSS при разном MTU. При одинаковом - как зеркало. С ответной стороны не приходит ни tcp window update (а если и приходит - то один-два а весь сеанс) ни tcp window full В случае с другим типом подключения - пакеты валят как бешенные, окно растет потоянно, есть незначительный reordering. Что делалось и не помогает: - смена MTU на всех интерфейсов до тунельного (на ethernet с пониженым MTU скорость также высокая) - подкинуть реальный IP и выключить conntrack на NAS и NAT BOX - полностью выключить шейперы (исходящий и входящий) - Полное отключение offload на сетевухах в цепочке Что помогает: - Задушить исходящую шейпером до ~20мегабит, тогда окно начинает увеличиваться. От 1 до 20 мегабит скорость растет, дальше начинает резко падать. Совсем без шейпера - также низкая. Вот пример iperf до амстердама: gre-тунель до NAS, MTU=1420 Цитата Connecting to host 163.172.208.7, port 5209 [ 4] local 192.168.5.34 port 47358 connected to 163.172.208.7 port 5209 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 3.96 MBytes 33.2 Mbits/sec 134 428 KBytes [ 4] 1.00-2.00 sec 4.83 MBytes 40.5 Mbits/sec 0 488 KBytes [ 4] 2.00-3.00 sec 5.63 MBytes 47.3 Mbits/sec 0 533 KBytes [ 4] 3.00-4.00 sec 5.63 MBytes 47.2 Mbits/sec 0 563 KBytes [ 4] 4.00-5.00 sec 4.83 MBytes 40.5 Mbits/sec 0 582 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-5.00 sec 24.9 MBytes 41.7 Mbits/sec 134 sender [ 4] 0.00-5.00 sec 23.8 MBytes 40.0 Mbits/sec receiver pppoe до NAS, MTU=1420 Цитата [ 4] local 192.168.5.34 port 55972 connected to 163.172.208.7 port 5209 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 38.7 KBytes 316 Kbits/sec 0 10.7 KBytes [ 4] 1.00-2.00 sec 25.8 KBytes 211 Kbits/sec 0 10.7 KBytes [ 4] 2.00-3.00 sec 40.8 KBytes 335 Kbits/sec 0 10.7 KBytes [ 4] 3.00-4.00 sec 25.8 KBytes 211 Kbits/sec 0 10.7 KBytes [ 4] 4.00-5.00 sec 25.8 KBytes 211 Kbits/sec 0 10.7 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-5.00 sec 157 KBytes 257 Kbits/sec 0 sender [ 4] 0.00-5.00 sec 144 KBytes 236 Kbits/sec receiver Т.к. tcp window update посылает удаленный хост, а не локальный, напрямую я повлиять на все хосты интернета я не могу, то определенно должно быть условие, при котором окно начнет увеличиваться. Но что это за условие? Проблема определенно в pppd. Но что в ним не так? Обновил до последнего git-среза, но проблему это не решило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
paradox_ Опубликовано 6 марта, 2021 · Жалоба ? https://www.opennet.ru/base/net/pppoe_mtu.txt.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 6 марта, 2021 · Жалоба 1 минуту назад, paradox_ сказал: https://www.opennet.ru/base/net/pppoe_mtu.txt.html С MTU проблем нет, discovery прекрасно отрабатывает. К тому же специально проводил тесты с занижением MTU на ethernet и gre-туннелях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 6 марта, 2021 · Жалоба Наконец-то, хоть кто-то нормально продебажил и озвучил одну из проблем, которой много лет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 6 марта, 2021 · Жалоба Суть бы проблемы еще понять. Я нашел очень много жалоб, где ломалось и чинилось pmtu, но тут оно как раз отрабатывает нормально. Большинство этих жалоб было на ядрах 3.2.60, 3.2.63-3.2.65, но тут стоит распоследнее 3.2.102. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 6 марта, 2021 · Жалоба 9 часов назад, [anp/hsw] сказал: linux 3.2. Ядрышко у Вас древнее кстати. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 6 марта, 2021 · Жалоба 3 минуты назад, sdy_moscow сказал: Ядрышко у Вас древнее кстати. Да уж какое есть. Но если обновляться на новое, там пол-системы сломается, вылезут новые грабли из разных мест, а это трудозатраты в разы большие, чем просто залатать дыру. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 7 марта, 2021 · Жалоба На микротике нет таких проблем, как описано в первом посте, хотя ядро линукса там не самое последнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 7 марта, 2021 · Жалоба 15 минут назад, Saab95 сказал: На микротике нет таких проблем, как описано в первом посте, хотя ядро линукса там не самое последнее. Как раз на форуме микротика подобные проблемы я и наблюдал, но они остались без ответа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 7 марта, 2021 · Жалоба В 06.03.2021 в 08:04, [anp/hsw] сказал: Меняем клиента на чистую Win7 с тесового ноутбука - ситуация повторяется. У венды тоже есть крутилки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 7 марта, 2021 · Жалоба 6 минут назад, Ivan_83 сказал: У венды тоже есть крутилки. Предлагаете крутить всем, кто заявит от проблеме? А если там телефон на андроиде без рута или какая-нибудь проприетарная железка? Что крутить будем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 7 марта, 2021 · Жалоба На это форуме была проблема с какой то кошкой используемой в качестве роутера, там тоже решилось крутилками в венде. Есть несколько вариантов: 1. Это венда тупит если она поднимает ппп подключение, тут или её лечить хотя бы настройками или ставить роутер, который поднимет ппп. 2. Это шейпер химичит с tcp служебкой. Поставьте перед вендой роутер, который подмет ппп и станет понятно кто виноват и что делать. 1 час назад, [anp/hsw] сказал: А если там телефон на андроиде без рута или какая-нибудь проприетарная железка? Что крутить будем? Я лично предлагаю провайдеру с PPP сгореть в аду, это самый простой и очевидный вариант. Мы в 2021 году, а PPP это наследие сраных телефонистов, которые привыкли тарифицировать звонки, и для них PPP был очередным звонком, а по другому они не умели. Нынче телефонисты уже скорее в виде зомби трупа, и даже они много где осилили уход от PPP на своём провайдинге. И как пользователь я голосую рублём и ухожу с корбины/билайна только из за ихнего дебильного PPP, просто 100м за 500 руб я бы ещё может стерпел, но когда рядом онлайм с 500 руб за 500 мегабит и без PPP - я не мазахист и не настолько ленив. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 7 марта, 2021 · Жалоба 44 минуты назад, Ivan_83 сказал: Поставьте перед вендой роутер, который подмет ппп и станет понятно кто виноват и что делать. Делали. И винду меняли на линкус. Проблема именно в прохождении ppp интерфейса, но не понятно, в чем конкретно (и когда она появилась, тоже никто не знает). 46 минут назад, Ivan_83 сказал: И как пользователь я голосую рублём и ухожу с корбины/билайна только из за ихнего дебильного PPP, просто 100м за 500 руб я бы ещё может стерпел, но когда рядом онлайм с 500 руб за 500 мегабит и без PPP - я не мазахист и не настолько ленив. Это уже попахивает фантомными болями, видимо протокол ppp доставляет вам мощные душевные страдания :) Есть еще такая штука как биллинг, и если она на pppoe затоечна, будет вдвойне сложнее с него слезть. Ну а уж про то, что 99% процентов людей знать не знают, pppoe там у них или что еще в роутере - свершившийся факт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 7 марта, 2021 · Жалоба 8 часов назад, [anp/hsw] сказал: Делали. И винду меняли на линкус. Проблема именно в прохождении ppp интерфейса, но не понятно, в чем конкретно (и когда она появилась, тоже никто не знает). Тогда остаётся либо реализация шейпера либо реализация NAT, отключайте по очереди и смотри как оно будет. Ещё может какие то оффлоадинги на сетевухах вашего сервера включены и они на что то влияют. 8 часов назад, [anp/hsw] сказал: Это уже попахивает фантомными болями, видимо протокол ppp доставляет вам мощные душевные страдания :) У меня действительно было много страданий с PPP на протяжении примерно двух лет, до тех пор пока я не начал использовать роутеры на базе BSD. Но в целом и на BSD мне не нравится что нужно держать отдельную службу и если она не стартанула - то из инета уже не попасть. Ну и применительно к роутеру в виде "железки" - оно там потребляет ресурсы и в пустую греет воздух. 8 часов назад, [anp/hsw] сказал: Есть еще такая штука как биллинг, и если она на pppoe затоечна, будет вдвойне сложнее с него слезть. Это ваш конкурентный недостаток. 8 часов назад, [anp/hsw] сказал: Ну а уж про то, что 99% процентов людей знать не знают, pppoe там у них или что еще в роутере - свершившийся факт. До тех пор, пока не нужно роутер поменять или не приспичит воткнуть провод напрямую в ноут/комп потому что роутер сдох а работать нада прямо щас а не за роутерами бегать или монтажопов ждать три дня. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 7 марта, 2021 · Жалоба 59 минут назад, Ivan_83 сказал: Тогда остаётся либо реализация шейпера либо реализация NAT, отключайте по очереди и смотри как оно будет. Ещё может какие то оффлоадинги на сетевухах вашего сервера включены и они на что то влияют. Что-то шепчет мне, что дело в ICMP... точнее в его отсутствии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 8 марта, 2021 · Жалоба 5 часов назад, Ivan_83 сказал: Тогда остаётся либо реализация шейпера либо реализация NAT, отключайте по очереди и смотри как оно будет. В первом посте же написано: отключалось полностью, вплоть до выпиливания conntrack на nat box и давания реальника, шейперы также все удалялись. A на NAS так вообще их нет, они только на NAT BOX, куда трафик приходит через один и тот же канал вне зависимости от типа клиентского подключения. 6 часов назад, Ivan_83 сказал: Ещё может какие то оффлоадинги на сетевухах вашего сервера включены и они на что то влияют. Пробовали отключать все, которые нашлись в ethtool - gro, gso, vlan, txcsum на обоих машинах... 6 часов назад, Ivan_83 сказал: Это ваш конкурентный недостаток. Что, это уже и в рекламке прописывается? "А вот у нас не pppoe", "mtu 9000 и jumbo frame первое в городе!", "dual stack ipv4/6 только сегодня!"? Вы как-то по-искаженному представляете конкурентое преимущество. 6 часов назад, Ivan_83 сказал: а работать нада прямо щас а не за роутерами бегать или монтажопов ждать три дня Пиццу и суши ждут час-два, а монтажника с преднастроеным роутером с какого-то перепуга три дня? 5 часов назад, sdy_moscow сказал: Что-то шепчет мне, что дело в ICMP... точнее в его отсутствии. Тогда бы не согласовался MSS. А с этим как раз все в порядке. После гадания на tcpdump имеется подозрение на лишнюю задержку, но пока без доказательств, что она может иметь значение. Ищу способ повысить ее на gre/vlan канале, чтобы проверить. Еще раз: такая байда начинается при росте RTT, т.е. до определенного момента и расстояния все OK.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 8 марта, 2021 · Жалоба 23 часа назад, [anp/hsw] сказал: Как раз на форуме микротика подобные проблемы я и наблюдал, но они остались без ответа. На микротике можно настраивать буфер пакетов в шейпере. Если поставить PFIFO с дефолтными 50 или 100 пакетами, то просто идут дропы и наблюдаются проблемы со скоростью одноканальной закачки. Стоит увеличить пакетный буфер до 2000-5000, как при нагрузке растет задержка и окно увеличивается, скорость одноканальной закачки так же увеличивается, но уже задержка начинает сдерживать максимальную пропускную способность. И только тип буфера PCQ решает все проблемы. В этом случае вносится некая задержка на прохождение всего трафика в потоке абонента, но скорость выравнивается по всем протоколам и увеличения задержки не происходит (пинг в норме). Это как у вас в случае с шейпером на 20М. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 8 марта, 2021 · Жалоба 42 минуты назад, Saab95 сказал: как при нагрузке растет задержка и окно увеличивается, скорость одноканальной закачки так же увеличивается Вы не читали исходный пост. В данном случае как раз наоборот происходит, а шейпер вообще выключен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 8 марта, 2021 · Жалоба 18 часов назад, [anp/hsw] сказал: В первом посте же написано: отключалось полностью, вплоть до выпиливания conntrack на nat box и давания реальника, шейперы также все удалялись. A на NAS так вообще их нет, они только на NAT BOX, куда трафик приходит через один и тот же канал вне зависимости от типа клиентского подключения. А точно ничего в фаере не забыли выключить, например mssfix какойнить или ещё чего то, что может лезть и менять содержимое TCP заголовков? 18 часов назад, [anp/hsw] сказал: Что, это уже и в рекламке прописывается? "А вот у нас не pppoe", "mtu 9000 и jumbo frame первое в городе!", "dual stack ipv4/6 только сегодня!"? Вы как-то по-искаженному представляете конкурентое преимущество. Всё же "включил и работает" лучше и для абонента и для вас мороки меньше. IPv6 уже заезжает и это вполне себе аргумент. И до mtu 9к доберутся, не переживайте, лет через 10 за него возьмутся. 13 часов назад, [anp/hsw] сказал: Вы не читали исходный пост. В данном случае как раз наоборот происходит, а шейпер вообще выключен. Тем не менее он может быть прав - где то в PPP хрени может не хватать буферов. Посмотрите на ретрансмиты в TCP соединении, может быть они как то неожиданно много прирастают? То что без PPP оно жмёт 50 мегабит а PPP только 3 конечно загадка :) Я бы попробовал снять полные tcpdump в pcap формате, а потом их бы разгребал разбирая отличия в TCP сигнализации, что вы видимо и сделали. У меня есть ещё гипотеза: микробёрсты. Без PPP у вас передающий хост пакеты может равномерно по времени размазывать, а в случае PPP они могу где то внутри агрегироваться и потом улетать большой пачкой, которая где то может не пролезать по пути, и клиент с той стороны будет запрашивать ретрансмиты. При этом при включённом шейпере у вас шейпер гарантирует что таких бёрстов не будет. Или всё таки где то у вас TCP может пересобираться и перефрагментироваться. Те попробуйте сравнить дампы трафика на клиентском PPP интерфейсе и на выходе уже на физическом и посмотрите на таймстемпы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 8 марта, 2021 · Жалоба 1 час назад, Ivan_83 сказал: IPv6 уже заезжает и это вполне себе аргумент Вот что я бы в сеть оператора ставить не стал.... дыра на дыре + куча лишней нагрузки на коммутаторы Л3. Тут как раз туннелирование будет спасением. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 9 марта, 2021 · Жалоба В 06.03.2021 в 08:04, [anp/hsw] сказал: - Задушить исходящую шейпером до ~20мегабит, тогда окно начинает увеличиваться. От 1 до 20 мегабит скорость растет, дальше начинает резко падать. Совсем без шейпера - также низкая. 2 часа назад, Ivan_83 сказал: У меня есть ещё гипотеза: микробёрсты. присоединяюсь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 9 марта, 2021 · Жалоба 8 часов назад, Ivan_83 сказал: А точно ничего в фаере не забыли выключить, например mssfix какойнить или ещё чего то, что может лезть и менять содержимое TCP заголовков? Точно. К тому же чем mssfix при работе с ppp отличается от mssfix при работе с vlan с точно таким же заниженым mtu? Ничем. ПО tcpdump все одинаково. 8 часов назад, Ivan_83 сказал: Посмотрите на ретрансмиты в TCP соединении, может быть они как то неожиданно много прирастают? В случае с медленным ppp ретрансмитов вообще нет. В случае с быстрыми vlan или gre, ретрансмитов куча (удаленный хост все же имеет лимит скорости), но и скорость высокая. 8 часов назад, Ivan_83 сказал: Без PPP у вас передающий хост пакеты может равномерно по времени размазывать, а в случае PPP они могу где то внутри агрегироваться и потом улетать большой пачкой, которая где то может не пролезать по пути, и клиент с той стороны будет запрашивать ретрансмиты. При этом при включённом шейпере у вас шейпер гарантирует что таких бёрстов не будет. Тоже на это грешу, но tcopdump показывает обратное: при ppp пакеты уходят в нужной очередности, просто медленно; при vlan/gre быстро, с берстами и реордеригном. Вот дамп начала соединений: *** gre 00:06:14.483075 IP 163.172.208.7.5209 > 192.168.5.34.36922: Flags [S.], seq 4084908873, ack 2960000570, win 43440, options [mss 1380,sackOK,TS val 3241808859 ecr 175168742,nop,wscale 13], length 0 00:06:14.483987 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], ack 1, win 432, options [nop,nop,TS val 175168765 ecr 3241808859], length 0 00:06:14.483992 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [P.], seq 1:38, ack 1, win 432, options [nop,nop,TS val 175168765 ecr 3241808859], length 37 00:06:14.574531 IP 163.172.208.7.5209 > 192.168.5.34.36922: Flags [.], ack 38, win 6, options [nop,nop,TS val 3241808881 ecr 175168765], length 0 00:06:14.577166 IP 163.172.208.7.5209 > 192.168.5.34.36920: Flags [P.], seq 3:4, ack 102, win 6, options [nop,nop,TS val 3241808882 ecr 175168753], length 1 00:06:14.578032 IP 192.168.5.34.36920 > 163.172.208.7.5209: Flags [.], ack 4, win 432, options [nop,nop,TS val 175168788 ecr 3241808882], length 0 00:06:14.662036 IP 163.172.208.7.5209 > 192.168.5.34.36920: Flags [P.], seq 4:5, ack 102, win 6, options [nop,nop,TS val 3241808903 ecr 175168788], length 1 00:06:14.662848 IP 192.168.5.34.36920 > 163.172.208.7.5209: Flags [.], ack 5, win 432, options [nop,nop,TS val 175168809 ecr 3241808903], length 0 00:06:14.663282 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 38:1406, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.663447 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 1406:2774, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.663455 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 2774:4142, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.663627 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 4142:5510, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.663700 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 5510:6878, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.663903 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 6878:8246, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.663909 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 8246:9614, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 00:06:14.664095 IP 192.168.5.34.36922 > 163.172.208.7.5209: Flags [.], seq 9614:10982, ack 1, win 432, options [nop,nop,TS val 175168809 ecr 3241808881], length 1368 *** pppoe 00:11:26.005393 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [S.], seq 3533636946, ack 1882388010, win 43440, options [mss 1380,sackOK,TS val 3241886739 ecr 175246624,nop,wscale 13], length 0 00:11:26.006324 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], ack 1, win 432, options [nop,nop,TS val 175246645 ecr 3241886739], length 0 00:11:26.006329 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [P.], seq 1:38, ack 1, win 432, options [nop,nop,TS val 175246645 ecr 3241886739], length 37 00:11:26.089993 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 38, win 6, options [nop,nop,TS val 3241886760 ecr 175246645], length 0 00:11:26.090532 IP 163.172.208.7.5209 > 192.168.5.34.45110: Flags [P.], seq 3:4, ack 102, win 6, options [nop,nop,TS val 3241886761 ecr 175246635], length 1 00:11:26.091445 IP 192.168.5.34.45110 > 163.172.208.7.5209: Flags [.], ack 4, win 432, options [nop,nop,TS val 175246667 ecr 3241886761], length 0 00:11:26.170553 IP 163.172.208.7.5209 > 192.168.5.34.45110: Flags [P.], seq 4:5, ack 102, win 6, options [nop,nop,TS val 3241886781 ecr 175246667], length 1 00:11:26.171418 IP 192.168.5.34.45110 > 163.172.208.7.5209: Flags [.], ack 5, win 432, options [nop,nop,TS val 175246687 ecr 3241886781], length 0 00:11:26.171745 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 38:1406, ack 1, win 432, options [nop,nop,TS val 175246687 ecr 3241886760], length 1368 00:11:26.171951 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 1406:2774, ack 1, win 432, options [nop,nop,TS val 175246687 ecr 3241886760], length 1368 00:11:26.255526 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 1406, win 6, options [nop,nop,TS val 3241886802 ecr 175246687], length 0 00:11:26.255538 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 2774, win 6, options [nop,nop,TS val 3241886802 ecr 175246687], length 0 00:11:26.256789 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 2774:4142, ack 1, win 432, options [nop,nop,TS val 175246708 ecr 3241886802], length 1368 00:11:26.257080 IP 192.168.5.34.45112 > 163.172.208.7.5209: Flags [.], seq 4142:5510, ack 1, win 432, options [nop,nop,TS val 175246708 ecr 3241886802], length 1368 00:11:26.340544 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 4142, win 7, options [nop,nop,TS val 3241886823 ecr 175246708], length 0 00:11:26.340858 IP 163.172.208.7.5209 > 192.168.5.34.45112: Flags [.], ack 5510, win 7, options [nop,nop,TS val 3241886823 ecr 175246708], length 0 Обратите внимание, что хоть и sack включен, в ppp на каждые 2 пакета хост ожидает ack, хотя в gre очередь намного длиннее. Использование accel-ppp несколько меняет картину относительно ванильного pppd: рост окна начинается примерно с 10-15 секунды соединения, но довольно вяло, совсем не как на ethernet. Первые два пакета в pppoe можете не принимать во внимание: это пакеты от служебной сессии iperf, где передается имя хоста и параметры потока. ps: Сообшение перечеркнуто хз, почему, тега такого в исходном посте нет, там spoiler и quote. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 9 марта, 2021 · Жалоба 1 час назад, [anp/hsw] сказал: Обратите внимание, что хоть и sack включен, в ppp на каждые 2 пакета хост ожидает ack, хотя в gre очередь намного длиннее. они случаем местами не перепутаны? в каком месте снят трафик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 9 марта, 2021 · Жалоба 2 часа назад, edo сказал: они случаем местами не перепутаны? Точно! Перепутаны. Исправил. Именно этот снят на стыке NAS-NATBOX, но у меня есть дампы на всех интерфейсах одновременно по цепочке этого же самого трафика, если надо. Не понятно, чем задается длина очереди при таком соединениии. Txqueuelen на интерфейсах крутить я пробовал, он не при делах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 9 марта, 2021 · Жалоба а ppp поднимается на windows? попробуйте поставить перед ней любой wifi-роутер (или не wifi) и поднять ppp на нём Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...