должен же кто то спасать вымирающие виды :)

думаю что единственное к чему можно придраться, это то что у нас нет маршрута на 127.0.0.0/8

из-за этого мы получаем ошибку, т.к. неизвестный адрес уходит на маршрут по-умолчанию

а по RFC эти адрес не должны попадать в провод, от сюда и ошибка

если маршрут добавить, то пакет будет отправляться

но так как адрес не настроен, то он не ответит

А можно как-то просто убедиться, что IPSec использует AES-NI?

gif IPv4-in-IPv4 вдвое медленней на гигабитной сети с моей новой железкой, чем прямое соединение. Ой-ой. За что так? @bu7cher, ты говорил оно быстрее будет. Это вот быстрее, как же оно было медленное?!

Ща посмотрю что будет с OpenVPN, будет смешно, если будет быстрее

на падение скорости вдвое надо приложить серьёзные усилия. простыми проёбами этого не добиться

на падение скорости вдвое надо приложить серьёзные усилия. простыми проёбами этого не добиться

Ну, там желзка довольно медленная, но да, я впечатлён. Прямой iperf3 — 990 мегабит. Делаем туннель с gif — 420-450 мегабит. Без IPSec

ты бы попробовал бы поснифать. забавно же и интересно

ну... когда у тебя гигабит, а то и 10 то поди уже не так уж и сложно, вот выжать, это да

Ну, там желзка довольно медленная, но да, я впечатлён. Прямой iperf3 — 990 мегабит. Делаем туннель с gif — 420-450 мегабит. Без IPSec

а чем замеряется?

ты бы попробовал бы поснифать. забавно же и интересно

А что сниффать-то? IP-in-IP. Не в протоколе дело. Скорее попрофайлить dtrace'ом.

а чем замеряется?

iperf3 с дефолтовыми опциямИ, тупо один поток TCP. У меня идея, что может это потому что весь оффлоадинг в таком виде умирает? Надо попробовать отключить весь оффлоадинг и померять

попробуй)

А, на gif0 ещё же MTU 1280, а на физике 9000

Ща ещё джамбы выключим

Отключил все железные ускорялки и сделал MTU 1500 — на физике получаем 660 мегабит. Всё равно gif многовато жрёт

ты сделай на интерфейсе MTU не 1500, а то, которое у TCP внтури gif

и смотри есть ли фрагментация

ты сделай на интерфейсе MTU не 1500, а то, которое у TCP внтури gif

У gif 1280. И, скажем, 8000 он не даёт поставить

ты сделай на интерфейсе MTU не 1500, а то, которое у TCP внтури gif

А на физических интерфейсах 9000. Так что не должно быть никакой фрагментации жи. Или нет?

ты сделай на интерфейсе MTU не 1500, а то, которое у TCP внтури gif

Можем пойти в приват что бы флудить чат очень частным вопросом

А ещё на 12-ALPHA6 у igb (I210) не включается TSO6. На 11-STABLE включается. Ну девочка… (да, завёл баг)

А ещё на 12-ALPHA6 у igb (I210) не включается TSO6. На 11-STABLE включается. Ну девочка… (да, завёл баг)

о как с ipv6 стабильно?

о как с ipv6 стабильно?

В смысле стабильно? Стабильно ли не включается? Да. Стабильно ли работает? Ну, iperf вполне живёт.

ну у меня при загрузке с ipv6 енайблед, почти гарантированная маломотивированная паника с ребутом

ну у меня при загрузке с ipv6 енайблед, почти гарантированная маломотивированная паника с ребутом

Там уже review на этот баг сделали

Ну вот Физическое соеднинение, когда с двух сторон ВКЛЮЧЕНЫ все улучшалки и MTU=9000 [ 5] 0.00-10.00 sec 1.15 GBytes 991 Mbits/sec 0 sender [ 5] 0.00-10.29 sec 1.15 GBytes 962 Mbits/sec receiver Физическое соединение, когда с двух сторон ВЫКЛЮЧЕНЫ все улучшалки и MTU=1280 (как на gif по-умолчанию) [ 5] 0.00-10.00 sec 678 MBytes 569 Mbits/sec 0 sender [ 5] 0.00-10.28 sec 678 MBytes 553 Mbits/sec receiver А вот gif поверх этого соединения, все улучшалки на физике ВКЛЮЧЕНЫ, MTU на физике 9000, MTU на gif 1280 [ 5] 0.00-10.00 sec 525 MBytes 440 Mbits/sec 0 sender [ 5] 0.00-10.29 sec 524 MBytes 427 Mbits/sec receiver Продолбали примерно 22%.

Если к этому добавить IPSEC, то скорость упадёт ещё вдвое.

Интересно, спасибо.

Ну и вдогонку. IPSec, ESP/Transport, AES-256-GCM (aes-gcm-16), шифруется всё (any), физический интерфейсы (всё включено): [ 5] 0.00-10.01 sec 885 MBytes 742 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 885 MBytes 721 Mbits/sec receiver IPSec, ESP/Transport, AES-256-GCM (aes-gcm-16), шифруется туннель (ipencap), gif: [ 5] 0.00-10.01 sec 266 MBytes 223 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 266 MBytes 216 Mbits/sec receiver И вот это совсем удручает. Видно, что IPSec может быстрее, чем сам туннел, но всё равно скорость просаживается вдвое. Ну, на ту же абсолютную величину, что у физики. Это как-то противоестественно.

Ну вот Физическое соеднинение, когда с двух сторон ВКЛЮЧЕНЫ все улучшалки и MTU=9000 [ 5] 0.00-10.00 sec 1.15 GBytes 991 Mbits/sec 0 sender [ 5] 0.00-10.29 sec 1.15 GBytes 962 Mbits/sec receiver Физическое соединение, когда с двух сторон ВЫКЛЮЧЕНЫ все улучшалки и MTU=1280 (как на gif по-умолчанию) [ 5] 0.00-10.00 sec 678 MBytes 569 Mbits/sec 0 sender [ 5] 0.00-10.28 sec 678 MBytes 553 Mbits/sec receiver А вот gif поверх этого соединения, все улучшалки на физике ВКЛЮЧЕНЫ, MTU на физике 9000, MTU на gif 1280 [ 5] 0.00-10.00 sec 525 MBytes 440 Mbits/sec 0 sender [ 5] 0.00-10.29 sec 524 MBytes 427 Mbits/sec receiver Продолбали примерно 22%.

А попробуй вот этот модуль перед тестом загрузить: https://people.freebsd.org/~ae/linkhdr/

интересно, будет хоть пару % разницы?

А попробуй вот этот модуль перед тестом загрузить: https://people.freebsd.org/~ae/linkhdr/

Ща. Сробрать бы ешё, это система без компилятора вообще.

ну и причина падения производительности, скорее всего в том, что в случае использования gif происходит двойная IP обработка

ну и причина падения производительности, скорее всего в том, что в случае использования gif происходит двойная IP обработка

Обидно, что IPSec так просаживает сверху. Казалось бы сам по себе он может работать быстрее туннеля, «не должен» влиять :-)

сначал ты получаешь IP пакет одного address family, делаются все проверки, что он предназначен тебе и т.п., потом откидывыется IP хидер, и через netisr пакет заварачивается на вход ещё раз, где для inner IP заголовка выполняется всё то же самое

попробуй if_ipsec, там будет чуть меньше оверхеда

А попробуй вот этот модуль перед тестом загрузить: https://people.freebsd.org/~ae/linkhdr/

А надо mtu ставить потом вручную? Или просто загрузить? ifconfig gif0 показывает всё тот же MTU

попробуй if_ipsec, там будет чуть меньше оверхеда

Запутался я в этом IPSEC'е, если честно. Пять способов сделать одно и то же.

смысл модуля в том, что он изменять значение kern.ipc.max_linkhdr

TCP использует это значение для резервирования места в начала мбуфа

и т.к. там будет достаточно места, то gif не будет аллоцировать новый мбуф чтобы добавить туда новый IP хидер

и т.к. там будет достаточно места, то gif не будет аллоцировать новый мбуф чтобы добавить туда новый IP хидер

Вот, стало: [ 5] 0.00-10.00 sec 541 MBytes 453 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 540 MBytes 440 Mbits/sec receiver

Повторил 6 раз, числа стабильные с точность до 1 мегабита.

Т.е. от 452 до 454

Было 439-441

Т.е. почти 3% в плюс

А почему gif не позволяет толстый MTU поставить?

там с бородатых времён 8000 тысяч кажется GIF_MAX_MTU

там с бородатых времён 8000 тысяч кажется GIF_MAX_MTU

А, я пробовал 8500 ставить :-)

8192

#define GIF_MTU (1280) /* Default MTU */ #define GIF_MTU_MIN (1280) /* Minimum MTU */ #define GIF_MTU_MAX (8192) /* Maximum MTU */

не понятно почему ограничение, потом как-нибудь поковыряю это

А вот это (8192) нифига не помогает [ 5] 0.00-10.00 sec 538 MBytes 451 Mbits/sec 0 sender [ 5] 0.00-10.29 sec 537 MBytes 437 Mbits/sec receiver

а ipfw у тебя есть там?

если его выгрузить, то может чуток ещё поднимешь, за счёт того, что не будет в pfil лишний раз обращаться

а ipfw у тебя есть там?

На одном из концов есть (пустой), но тут дело такое, что это gateway, ему надо (а в будущем и не пустой).

Вот if_ipsec по man if_ipsec: [ 5] 0.00-10.02 sec 302 MBytes 253 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 301 MBytes 245 Mbits/sec receiver Не быстрее. Ну, на крошку быстрее, но не серьёзно.

там в примере cbc используется

там в примере cbc используется

Это я поправил всё же.

там в примере cbc используется

Т.е. я не копипастил совсем 1-в-1

ну +30Mb/s не совсем и крошечка

ERROR: S client not available

и mtu там 1400 по-умолчанию

ну +30Mb/s не совсем и крошечка

Ну, я сравниваю с IPSec по физике без туннелей :-)

и mtu там 1400 по-умолчанию

8192: [ 5] 0.00-10.04 sec 302 MBytes 252 Mbits/sec 0 sender [ 5] 0.00-10.33 sec 301 MBytes 245 Mbits/sec receiver Не влияет.

интересно а на 100Mb линке тоже на половину просядет?

не уверен, что простое увеличение MTU на интерфейсе повлияет на mtu на маршруте

попробуй ifconfig ipsec0 down up

попробуй ifconfig ipsec0 down up

Оооооо

[ 5] 0.00-10.01 sec 848 MBytes 711 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 848 MBytes 691 Mbits/sec receiver

Вот где MTU играет

Надо сейчас перетестить gif + IPSec с down-up

И тут понятно в чём дело. Очень выгодно шифровать БОЛЬШИЕ пакеты

пора автоматизировать тесты, запутался

gif + IPSec, MTU = 8192, гарантированно [ 5] 0.00-10.01 sec 830 MBytes 696 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 830 MBytes 676 Mbits/sec receiver Вот теперь офигенно

А вот теперь САМОЕ смешное. gif + IPSec, на физике mtu = 1500, на gif mtu = 8192. Т.е. гарантированная фрагментация в физике. [ 5] 0.00-10.01 sec 698 MBytes 585 Mbits/sec 0 sender [ 5] 0.00-10.30 sec 698 MBytes 569 Mbits/sec receiver Т.е. для IPSec так важны большие пакеты, что выгодно ФРАГМЕНТИРОВАТЬ

но если ты потеряешь фрагмент, то сразу станет невыгодно

но если ты потеряешь фрагмент, то сразу станет невыгодно

Да, это понятно. Но если я потеряю пакет то тоже не очень

ахаха, как раз твитером навеяло Department of Informatics Networks and Distributed Systems (ND) group TCP in painful detail (and some SCTP and QUIC as well) Michael Welzl Net Group, University of Rome Tor Vergata 22. 09. 2017 https://heim.ifi.uio.no/michawe/research/publications/tor-vergata_tcp-tutorial_2017.pdf

кстати, придумал как сделать автотюнинг max_linkhdr из коробки, приделаю потом, как разморозят head

кстати, придумал как сделать автотюнинг max_linkhdr из коробки, приделаю потом, как разморозят head

Здорово.

Так. А теперь надо попробовать поднять OpenVPN для полноты картины.

The 12.0-RELEASE schedule will slip while we wait for some last-minute work-in-progress to be completed before branching stable/12. The most notable work-in-progress is upgrading the in-tree OpenSSL to version 1.1.1, to avoid being stuck with an outdated OpenSSL when 1.0.x reaches end of life on January 1, 2020. There is a bit of non-trivial intrusiveness with this update, notably incompatibility with other in-tree utilities such as OpenSSH, Kerberos, and NTP.

ага в мордокниге ссылки на баги кидали, там вроде чтой то думали

ахаха, как раз твитером навеяло Department of Informatics Networks and Distributed Systems (ND) group TCP in painful detail (and some SCTP and QUIC as well) Michael Welzl Net Group, University of Rome Tor Vergata 22. 09. 2017 https://heim.ifi.uio.no/michawe/research/publications/tor-vergata_tcp-tutorial_2017.pdf

о, в кои-то веки кто-то и SCTP бенчит

% telegram-desktop /usr/local/lib/qt5/plugins/bearer/libqgenericbearer.so: Undefined symbol "_ZN17QNetworkInterfaceC1ERKS_@Qt_5" Это к чему бы? .so из состава qt5-network. Пересобирал -- не помогло. Персобирал qt5-* -- тоже.

Я бы посмотрел на вывод ldd /usr/local/lib/qt5/plugins/bearer/libqgenericbearer.so | grep Network и elfdump -s /usr/local/lib/qt5/libQt5Network.so.5 | grep ZN17QNetworkInterfaceC1ERKS

% strings /usr/local/lib/qt5/plugins/bearer/libqgenericbearer.so| grep _ZN17QNetworkInterfaceC1ERKS_ _ZN17QNetworkInterfaceC1ERKS_

% elfdump -s /usr/local/lib/qt5/libQt5Network.so.5 | grep _ZN17QNetworkInterfaceC1ERKS_ st_name: _ZN17QNetworkInterfaceC1ERKS_

Оба раза без @Qt5. Не знаю, критично это али нет

ldd /usr/local/bin/telegram-desktop | grep Network

Путь к libQt5Network.so.5 совпадает с тем который дампили выше?

ldd -- да, именно тот, на кого elfdump натравливал

дык вопрос может в том чтоб телеграм пересобрать?