OpenVPN - очень низкая скорость загрузки, нормальная скорость выгрузки

[Dmitry Kolvakh]

Hello everybody!

Поставил openvpn-2.4.8_2 на 12.1-RELEASE в качестве сервера.
Протокол udp, интерфейс tun. Шлюз по умолчанию не отдается, только пушится
маршрутизация нужных сетей.
NAT не используется, только в rc.conf gateway_enable="YES"

Получился пренеприятный эффект. Скорость загрузки с маршрутизируемых сетей
просто никакая - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с
железной машине на Linux. Уже эта разница настораживает.
При этом скорость _выгрузки_ в маршрутизируемые сети - нормальная, 9MB/s.


Вот так:

keu@keu-home:~$ scp grey_server:/home/keu/Middle_ages.pdf .
Middle_ages.pdf 10% 1168KB 5.4KB/s 30:57 ETA^C

keu@keu-home:~$ scp Middle_ages.pdf grey_server:/home/keu/
Middle_ages.pdf 100% 11MB 9.3MB/s 00:01


Скорость в обе стороны со шлюзом openvpn - 9-11MB/s (т.е. с тем адресом,
который у него на tun0)

Скорость в обе стороны минуя openvpn - 11MB/s

Скорость плохая не только в scp, тот же эффект и при открытии веб-страниц.

Мой клиент: openvpn 2.4.4-2ubuntu1.3
Пробовал клиент под виндовс (скачанный с оф. сайта)
Пробовал увеличить буфера
Пробовал протокол tcp
Пробовал уменьшить/увеличить mtu
NAT и tap не пробовал.


Как лечить, куда смотреть?


Конфиг сервера:
=================
port 1194
proto udp
dev tun
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/openvpn-server.crt
key /usr/local/etc/openvpn/keys/openvpn-server.key # This file should be kept
secret
dh /usr/local/etc/openvpn/keys/dh.pem
topology subnet
server 10.100.22.0 255.255.255.0
ifconfig-pool-persist /var/openvpn/ipp.txt
push "route 10.0.0.0 255.0.0.0"
push "route 172.16.0.0 255.240.0.0"
keepalive 10 120
tls-auth /usr/local/etc/openvpn/keys/ta.key 0 # This file is secret
cipher AES-256-CBC
user nobody
group nobody
persist-key
persist-tun
status /var/openvpn/openvpn-status.log
verb 3
explicit-exit-notify 1
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
=================

Конфиг клиента
=================
client
dev tun
proto udp
remote хх.хх.хх.хх 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert keu.crt
key keu.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
=================


в rc.conf:

gateway_enable="YES"
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"


Dmitry

[Eugene Grosbein]

10 июля 2020, пятница, в 17:48 NOVT, Dmitry Kolvakh написал(а):

DK> Поставил openvpn-2.4.8_2 на 12.1-RELEASE в качестве сервера.
DK> Протокол udp, интерфейс tun. Шлюз по умолчанию не отдается, только пушится
DK> маршрутизация нужных сетей.
DK> NAT не используется, только в rc.conf gateway_enable="YES"
DK> Получился пренеприятный эффект. Скорость загрузки с маршрутизируемых сетей
DK> просто никакая - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с
DK> железной машине на Linux. Уже эта разница настораживает.
DK> При этом скорость _выгрузки_ в маршрутизируемые сети - нормальная, 9MB/s.

Опиши железо: точную модель сетевой карты и CPU.
Покажи вывод ifconfig для физической сетевой и для tun0.

DK> sndbuf 524288
DK> rcvbuf 524288
DK> push "sndbuf 524288"
DK> push "rcvbuf 524288"

Покажи выдачу sysctl net.inet | fgrep buf

Eugene

[Dmitry Kolvakh]

Hello Eugene!

11 Jul 20 06:59, you wrote to me:

EG> Subject: Re: OpenVPN - очень низкая скорость загрузки, нормальная
EG> скорость выгрузки

EG> 10 июля 2020, пятница, в 17:48 NOVT, Dmitry Kolvakh написал(а):

DK>> Поставил openvpn-2.4.8_2 на 12.1-RELEASE в качестве сервера.
DK>> Протокол udp, интерфейс tun. Шлюз по умолчанию не отдается,

DK>> только пушится маршрутизация нужных сетей. NAT не используется,
DK>> только в rc.conf gateway_enable="YES" Получился пренеприятный
DK>> эффект. Скорость загрузки с маршрутизируемых сетей просто никакая
DK>> - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с
DK>> железной машине на Linux. Уже эта разница настораживает. При
DK>> этом скорость _выгрузки_ в маршрутизируемые сети - нормальная,
DK>> 9MB/s.

EG> Опиши железо: точную модель сетевой карты и CPU.

Сервер на виртуалке под proxmox.

CPU: Common KVM processor (2600.01-MHz K8-class CPU)
Origin="GenuineIntel" Id=0xf61 Family=0xf Model=0x6 Stepping=1

Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
Features2=0x80202001<SSE3,CX16,x2APIC,HV>
AMD Features=0x20100800<SYSCALL,NX,LM>
AMD Features2=0x1<LAHF>
real memory = 2147483648 (2048 MB)
avail memory = 2043162624 (1948 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)

На физическом хосте 32 x Intel Xeon E5-2680 0 @ 2.70GHz (2 sockets)

Сетевая:
vtnet0: <VirtIO Networking Adapter> on virtio_pci3
vtnet0: Ethernet address: 26:da:78:ff:a9:fd
vtnet0: netmap queues/slots: TX 1/256, RX 1/128

Точную модель железа не знаю, если это важно - спрошу.

EG> Покажи вывод ifconfig для физической сетевой и для tun0.

vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,R
XCSUM_IPV6,TXCSUM_IPV6>
ether 26:da:78:ff:a9:fd
inet xx.xx.xx.xx netmask 0xfffffff0 broadcast xx.xx.xx.xx
media: Ethernet 10Gbase-T <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::5c2d:faf0:33a7:6ab0%tun0 prefixlen 64 scopeid 0x3
inet 10.100.22.1 --> 10.100.22.2 netmask 0xffffff00
groups: tun
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Opened by PID 2383

DK>> sndbuf 524288
DK>> rcvbuf 524288
DK>> push "sndbuf 524288"
DK>> push "rcvbuf 524288"

EG> Покажи выдачу sysctl net.inet | fgrep buf

net.inet.tcp.sendbuf_auto_lowat: 0
net.inet.tcp.sendbuf_max: 2097152
net.inet.tcp.sendbuf_inc: 8192
net.inet.tcp.sendbuf_auto: 1
net.inet.tcp.recvbuf_max: 2097152
net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.recvbuf_auto: 1
net.inet.sctp.buffer_splitting: 0
net.inet.sctp.max_chained_mbufs: 5

Dmitry

[Eugene Grosbein]

11 июля 2020, суббота, в 23:24 NOVT, Dmitry Kolvakh написал(а):

DK>>> Поставил openvpn-2.4.8_2 на 12.1-RELEASE в качестве сервера.
DK>>> Протокол udp, интерфейс tun. Шлюз по умолчанию не отдается,
DK>>> только пушится маршрутизация нужных сетей. NAT не используется,
DK>>> только в rc.conf gateway_enable="YES" Получился пренеприятный
DK>>> эффект. Скорость загрузки с маршрутизируемых сетей просто никакая
DK>>> - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с
DK>>> железной машине на Linux. Уже эта разница настораживает. При
DK>>> этом скорость _выгрузки_ в маршрутизируемые сети - нормальная,
DK>>> 9MB/s.
EG>> Опиши железо: точную модель сетевой карты и CPU.

DK> Сервер на виртуалке под proxmox.

EG>> Покажи вывод ifconfig для физической сетевой и для tun0.

DK> vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
DK> 1500
DK> options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,
DK> VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>

Первым делом отключи весь offload на vtnet0, какой сможешь:
rxcsum,txcsum и вообще всё что отключится, и перепроверь.

Eugene
--
Прекрасны тонко отшлифованная драгоценность; победитель, раненный в бою;
слон во время течки; река, высыхающая зимой; луна на исходе; юная женщина,
изнуренная наслаждением, и даятель, отдавший все нищим. (Дхарма)

[Dmitry Kolvakh]

Hello Eugene!

13 Jul 20 02:59, you wrote to me:

EG>>> Покажи вывод ifconfig для физической сетевой и для tun0.
DK>> vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric

DK>> 0 mtu 1500

DK>> options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,
DK>> VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM

DK>> _IPV6>

EG> Первым делом отключи весь offload на vtnet0, какой сможешь:
EG> rxcsum,txcsum и вообще всё что отключится, и перепроверь.

Удалось отключить до такого вида:

vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=800a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>

Это несколько помогло.
Скорость даунлоада стала 8 Мбайт/с, зато аплоад парадоксальным образом
уменьшился до 5.3 Мбайт/с (было 9)
Вернул LRO, аплоад тоже стал 8 Мбайт/с
Повозвращал по одному все прочие параметры, виновником оказался RXCSUM.

Что это было?


При этом на голой сети, мимо vpn, обмен с этим же сервером 70 Мбайт/с.
Как-то можно еще ускорить openvpn? Может, ослабить шифрование?
Кстати, что у него с многопоточностью, стоит ли добавить ядер cpu?
При копировании файла top показывает вот такую загрузку:
CPU: 38.2% user, 0.0% nice, 11.4% system, 3.9% interrupt, 46.5% idle


Dmitry

[Eugene Grosbein]

13 июля 2020, понедельник, в 23:37 NOVT, Dmitry Kolvakh написал(а):

DK> Повозвращал по одному все прочие параметры, виновником оказался RXCSUM.
DK> Что это было?

Случаем NAT не используется ли? libalias/ipfw nat/natd не совместимы
с checksum offload, но это больше касается txcsum. С другой стороны,
часто одно без другого (rxcsum/txcsum) отключить невозможно,
при отключении одного отключается и второе (и наоборот).

Если NAT нет, значит тупо баг в драйвере виртуализированной сетевой,
в 12.1-STABLE до сих пор чинят баги в iflib. Попробуй виртуалку
с 11.4-RELEASE, где ещё нет iflib и гораздо более оттестированный код.

DK> При этом на голой сети, мимо vpn, обмен с этим же сервером 70 Мбайт/с.
DK> Как-то можно еще ускорить openvpn? Может, ослабить шифрование?
DK> Кстати, что у него с многопоточностью, стоит ли добавить ядер cpu?
DK> При копировании файла top показывает вот такую загрузку:
DK> CPU: 38.2% user, 0.0% nice, 11.4% system, 3.9% interrupt, 46.5% idle

Я сам не использую openvpn, без понятия. Смотри top -SHPI.

Hо вообще openvpn известен как одно из самых тормознутых решений
по сравнению с альтернативами, работающими на уровне ядра,
например с IPSec.

Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.

[Dmitry Kolvakh]

Hello Eugene!

14 Jul 20 14:36, you wrote to me:


EG> Случаем NAT не используется ли? libalias/ipfw nat/natd не совместимы
EG> с checksum offload, но это больше касается txcsum.

Нет, не используется.

EG> С другой стороны,
EG> часто одно без другого (rxcsum/txcsum) отключить невозможно,
EG> при отключении одного отключается и второе (и наоборот).

Я пробовал отключать по одному, и по индикации от ifconfig и по актуальной
скорости передачи выходит, что таки
отключаются раздельно.

EG> Если NAT нет, значит тупо баг в драйвере виртуализированной сетевой,
EG> в 12.1-STABLE до сих пор чинят баги в iflib.

Обновил систему с RELEASE-p3 на RELEASE-p7, баг остался.

EG> Попробуй виртуалку
EG> с 11.4-RELEASE, где ещё нет iflib и гораздо более оттестированный код.

Тоже вариант. Лишь бы у нее поддержка не кончилась при еще непочиненном баге в
iflib ))

EG> Hо вообще openvpn известен как одно из самых тормознутых решений
EG> по сравнению с альтернативами, работающими на уровне ядра,
EG> например с IPSec.

А на чем сейчас лучше поднять l2tp+ipsec VPN-сервер под FreeBSD? Для доступа
внутрь сети организации.
Требуются подключения с клиентских компов (а хорошо б и телефонов), а не просто
туннель между двумя юниксами, как
описано в хендбуке.
Авторизация по АД необязательна (но не повредит), а вот управление
маршрутизацией со стороны сервера было бы
желательно.

Или какое-то другое решение, кроме l2tp+ipsec?


Dmitry

[Eugene Grosbein]

14 июля 2020, вторник, в 15:32 NOVT, Dmitry Kolvakh написал(а):

EG>> Если NAT нет, значит тупо баг в драйвере виртуализированной сетевой,
EG>> в 12.1-STABLE до сих пор чинят баги в iflib.

DK> Обновил систему с RELEASE-p3 на RELEASE-p7, баг остался.

Это не STABLE.

EG>> Попробуй виртуалку
EG>> с 11.4-RELEASE, где ещё нет iflib и гораздо более оттестированный код.

DK> Тоже вариант. Лишь бы у нее поддержка не кончилась при еще непочиненном
DK> баге в
DK> iflib ))

11.4-RELEASE вышла совсем недавно, поддерживаться будет ещё долго.

EG>> Hо вообще openvpn известен как одно из самых тормознутых решений
EG>> по сравнению с альтернативами, работающими на уровне ядра,
EG>> например с IPSec.

DK> А на чем сейчас лучше поднять l2tp+ipsec VPN-сервер под FreeBSD? Для
DK> доступа
DK> внутрь сети организации.
DK> Требуются подключения с клиентских компов (а хорошо б и телефонов), а не
DK> просто
DK> туннель между двумя юниксами, как
DK> описано в хендбуке.
DK> Авторизация по АД необязательна (но не повредит), а вот управление
DK> маршрутизацией со стороны сервера было бы
DK> желательно.

Я использую ipsec-tools (racoon) + mpd5, работает прекрасно и с виндовыми
компами, и с Android, и с iOS. Авторизация по AD тоже работает по протоколу
RADIUS, на контроллере домена надо просто включить эту роль.

Eugene
--
Чтобы всё как у всех, но чтоб при этом - не так, как они.

[Alex Korchmar]

Dmitry Kolvakh <Dmitry....@p2.f89.n5054.z2.fidonet.org> wrote:

DK> Получился пренеприятный эффект. Скорость загрузки с маршрутизируемых сетей
DK> просто никакая - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с
DK> железной машине на Linux. Уже эта разница настораживает.
я бы предположил простую и банальную проблему pmtud, а не мифические сложности
с сетевой картой на 20м году жизни технологии.

Понятия не имею, как в вашей фребеэсде ее решать - в когда-то существовавших
_нормальных_ системах можно было просто срезать флаг 'df' сразу по получении
такого пакета. Практика показала, к сожалению, что в современном интернете это
единственно-правильное решение, остальные годятся только в полностью
подконтрольных тебе сетях (включая конечных пользователей).

DK> При этом скорость _выгрузки_ в маршрутизируемые сети - нормальная, 9MB/s.
лишнее подтверждение что это именно mtu.

DK> Как лечить, куда смотреть?
кстати, для начала - не поебдил ли ты icmp на своем маршрутизаторе?

> Alex

[Eugene Grosbein]

16 июля 2020, четверг, в 11:15 NOVT, Alex Korchmar написал(а):

DK>> Получился пренеприятный эффект. Скорость загрузки с маршрутизируемых

DK>> сетей

DK>> просто никакая - 5KB/s с виртуальных машин на FreeBSD, порядка 700KB/s с
DK>> железной машине на Linux. Уже эта разница настораживает.

AK> я бы предположил простую и банальную проблему pmtud, а не мифические
AK> сложности
AK> с сетевой картой на 20м году жизни технологии.

При сломанном pmtud коннекты тупо застывают, потому что крупные пакеты
не пролазят, а TCP blackhole detection не включен или вообще не реализован.

AK> Понятия не имею, как в вашей фребеэсде ее решать - в когда-то
AK> существовавших
AK> _нормальных_ системах можно было просто срезать флаг 'df' сразу по
AK> получении
AK> такого пакета.

Hа оконечной системе если пакет уже пришел - сбрасывать флаг df смысла нет.

Eugene
--
Поэты - страшные люди. У них все святое.

[Alex Korchmar]

Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:

EG> При сломанном pmtud коннекты тупо застывают, потому что крупные пакеты
ты отстал от жизни. Поскольку он "сломан" практически повсеместно - со времен
windows XP, после поебды над icmp, ничего бы нигде и никогда не работало.

Поэтому у винды есть workaround - и оно начинает работать именно так как
описано, по пять килобайт в час.
При этом обратный канал работает на полной скорости, там icmp не заблокирован.

EG> Hа оконечной системе если пакет уже пришел - сбрасывать флаг df смысла нет.
на маршрутизаторе с openvpn.
(на самом деле - на любом маршрутизаторе)


> Alex

[Eugene Grosbein]

17 июля 2020, пятница, в 07:24 NOVT, Alex Korchmar написал(а):

EG>> При сломанном pmtud коннекты тупо застывают, потому что крупные пакеты

AK> ты отстал от жизни. Поскольку он "сломан" практически повсеместно - со
AK> времен
AK> windows XP, после поебды над icmp, ничего бы нигде и никогда не работало.

А оно и не работает. Работает только в двух случаях: mtu как минимум 1500
по всей трассе (чаще всего так и есть) или tcpmssfix - но только для TCP,
какой-нибудь GRE или ESP имеет все шансы не пролезть в случае чего
даже без NAT по трассе.

AK> Поэтому у винды есть workaround - и оно начинает работать именно так как
AK> описано, по пять килобайт в час.
AK> При этом обратный канал работает на полной скорости, там icmp не
AK> заблокирован.

Это как раз эффекты blackhole detection. Только в обсуждаемом случае
не винда.

EG>> Hа оконечной системе если пакет уже пришел - сбрасывать флаг df смысла

EG>> нет.
AK> на маршрутизаторе с openvpn.
AK> (на самом деле - на любом маршрутизаторе)

В обсуждаемом случае tcp с самой фряхи, контекст не теряй.

Eugene
--
И друзей успокоив и ближних любя,
Мы на роли героев вводили себя.

[Alex Korchmar]

Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:

AK>> windows XP, после поебды над icmp, ничего бы нигде и никогда не работало.

EG> А оно и не работает. Работает только в двух случаях: mtu как минимум 1500
работает, работает, я пять лет наслаждался этой "работой". И до
того еще четыре, с перерывом на XP sp3, где не было включено. Только
мээээдлэнно.

EG> Это как раз эффекты blackhole detection. Только в обсуждаемом случае
EG> не винда.
у винды это по другому называется и иначе устроено.
Кстати, да:
> 5KB/s с виртуальных машин на FreeBSD и 700 с линупсов
говорят нам о том что виртуальные машины настраивал поебдитель icmp,
а в линуксах его не так просто поебдить из-за stateful firewall, и у него не
совсем получилось.

AK>> на маршрутизаторе с openvpn.
AK>> (на самом деле - на любом маршрутизаторе)

EG> В обсуждаемом случае tcp с самой фряхи, контекст не теряй.
нет, это "виртуальные машины" - где-то за той фряхой.

> Alex

[Dmitry Kolvakh]

Hello Alex!

16 Jul 20 11:15, you wrote to me:

DK>> Получился пренеприятный эффект. Скорость загрузки с

DK>> маршрутизируемых сетей просто никакая - 5KB/s с виртуальных машин
DK>> на FreeBSD, порядка 700KB/s с железной машине на Linux. Уже эта
DK>> разница настораживает.
AK> я бы предположил простую и банальную проблему pmtud, а не мифические
AK> сложности с сетевой картой на 20м году жизни технологии.

Тем не менее, срезание rxcsum с сетевой карты проблему решило.
Ну как решило... теперь сабж тормозит на 9Мбайт/с, одинаково в обоих
направлениях.
Применять по назначению можно, но хочется бОльшего.

DK>> При этом скорость _выгрузки_ в маршрутизируемые сети - нормальная,

DK>> 9MB/s.
AK> лишнее подтверждение что это именно mtu.

Я тоже думал, что дело в mtu, т.к. инкапсуляция в vpn. Но вот оказалось не так
просто. Может быть, mtu влияет каким-то косвенным образом.

DK>> Как лечить, куда смотреть?

AK> кстати, для начала - не поебдил ли ты icmp на своем маршрутизаторе?

Ни на маршрутизаторе, ни на всех участвовавших в эксперименте виртуалках я icmp
не трогал.

Dmitry

[Dmitry Kolvakh]

Hello Eugene!

15 Jul 20 06:37, you wrote to me:

EG>>> Hо вообще openvpn известен как одно из самых тормознутых решений
EG>>> по сравнению с альтернативами, работающими на уровне ядра,
EG>>> например с IPSec.
DK>> А на чем сейчас лучше поднять l2tp+ipsec VPN-сервер под FreeBSD?

DK>> Для доступа внутрь сети организации. Требуются подключения с
DK>> клиентских компов (а хорошо б и телефонов), а не просто туннель
DK>> между двумя юниксами, как описано в хендбуке. Авторизация по АД
DK>> необязательна (но не повредит), а вот управление маршрутизацией
DK>> со стороны сервера было бы желательно.

EG> Я использую ipsec-tools (racoon) + mpd5, работает прекрасно и с
EG> виндовыми компами, и с Android, и с iOS. Авторизация по AD тоже
EG> работает по протоколу RADIUS, на контроллере домена надо просто
EG> включить эту роль.

Наверное, попробую это.

Dmitry

[Alex Korchmar]

Dmitry Kolvakh <Dmitry....@p2.f89.n5054.z2.fidonet.org> wrote:

DK> просто. Может быть, mtu влияет каким-то косвенным образом.
это легко проверить, зажав его на какие-нибудь произвольные 508 на конечных
получателях.

DK> Hи на маршрутизаторе, ни на всех участвовавших в эксперименте
DK> виртуалках я icmp не трогал.
а какой-нибудь дефолтный конфиг за тебя это не мог сделать?

> Alex

[Eugene Grosbein]

19 июля 2020, воскресенье, в 11:55 NOVT, Alex Korchmar написал(а):

DK>> просто. Может быть, mtu влияет каким-то косвенным образом.

AK> это легко проверить, зажав его на какие-нибудь произвольные 508 на
AK> конечных
AK> получателях.

Гораздо проще это сделать, запустив ping с флагом DF и нужным размером MTU.

Eugene
--
Choose no career

[Eugene Grosbein]

18 июля 2020, суббота, в 21:50 NOVT, Dmitry Kolvakh написал(а):

DK>>> Получился пренеприятный эффект. Скорость загрузки с
DK>>> маршрутизируемых сетей просто никакая - 5KB/s с виртуальных машин
DK>>> на FreeBSD, порядка 700KB/s с железной машине на Linux. Уже эта
DK>>> разница настораживает.
AK>> я бы предположил простую и банальную проблему pmtud, а не мифические
AK>> сложности с сетевой картой на 20м году жизни технологии.

DK> Тем не менее, срезание rxcsum с сетевой карты проблему решило.
DK> Hу как решило... теперь сабж тормозит на 9Мбайт/с, одинаково в обоих
DK> направлениях.
DK> Применять по назначению можно, но хочется бОльшего.

С учётом "Скорость в обе стороны минуя openvpn - 11MB/s"
можно пробовать выжимать из openvpn больше, пытаясь оптимизировать
чего-нибудь в нём или в сетевом стеке FreeBSD 12 -
не исключено, что в iflib ещё какие-то косяки с UDP и ты на них
напарываешься; но для этого надо всё-таки сравнить со скоростью
того же под FreeBSD 11.4, ты это уже делал?

Hо то, что openvpn тормоз это известный факт.

Eugene
--
- Локапалы непобедимы, - сказал Кубера, а девочка подняла кубик
и долго-долго разглядывала его, прежде чем назвать.

[Eugene Grosbein]

19 июля 2020, воскресенье, в 17:30 NOVT, Eugene Grosbein написал(а):

DK>> Тем не менее, срезание rxcsum с сетевой карты проблему решило.
DK>> Hу как решило... теперь сабж тормозит на 9Мбайт/с, одинаково в обоих
DK>> направлениях.
DK>> Применять по назначению можно, но хочется бОльшего.

EG> С учётом "Скорость в обе стороны минуя openvpn - 11MB/s"
EG> можно пробовать выжимать из openvpn больше, пытаясь оптимизировать
EG> чего-нибудь в нём или в сетевом стеке FreeBSD 12 -
EG> не исключено, что в iflib ещё какие-то косяки с UDP и ты на них
EG> напарываешься; но для этого надо всё-таки сравнить со скоростью
EG> того же под FreeBSD 11.4, ты это уже делал?

Подобная проблема c UDP уже была в старых релизах FreeBSD:
https://segfault.kiev.ua/pipermail/freebsd/2017-April/000199.html

Могли и снова сломать в 12.

[Dmitry Kolvakh]

Hello Alex!

19 Jul 20 11:55, you wrote to me:

DK>> Hи на маршрутизаторе, ни на всех участвовавших в эксперименте
DK>> виртуалках я icmp не трогал.

AK> а какой-нибудь дефолтный конфиг за тебя это не мог сделать?

Дефолтные конфиги в эхотаге могут молча поебдить icmp? Там нет активных
фаерволлов.

Dmitry

[Dmitry Kolvakh]

Hello Eugene!

19 Jul 20 17:30, you wrote to me:

DK>> Тем не менее, срезание rxcsum с сетевой карты проблему решило.
DK>> Hу как решило... теперь сабж тормозит на 9Мбайт/с, одинаково в

DK>> обоих направлениях. Применять по назначению можно, но хочется
DK>> бОльшего.

EG> С учётом "Скорость в обе стороны минуя openvpn - 11MB/s"

11МБ/с - это через мой домашний инет. А в пределах рабочей сети получалось
что-то порядка 70МБ/с.


EG> можно пробовать выжимать из openvpn больше, пытаясь оптимизировать
EG> чего-нибудь в нём или в сетевом стеке FreeBSD 12 -

Я думал было попробовать убавить мощи шифрования (т.к. вижу загрузку ЦПУ), но
что-то оно либо не убавлялось, либо не дало эффекта. Глубоко не смотрел, не
было пока времени.

EG> не исключено, что в iflib ещё какие-то косяки с UDP и ты на них
EG> напарываешься; но для этого надо всё-таки сравнить со скоростью
EG> того же под FreeBSD 11.4, ты это уже делал?

Нет еще.

EG> Hо то, что openvpn тормоз это известный факт.

Ну вот пока предпочтительнее видится вместо него попробовать l2tp+ipsec, но
пока даже не приступал.

Dmitry

[Dmitry Kolvakh]

Hello Eugene!

19 Jul 20 17:30, you wrote to me:

EG> С учётом "Скорость в обе стороны минуя openvpn - 11MB/s"
EG> можно пробовать выжимать из openvpn больше, пытаясь оптимизировать
EG> чего-нибудь в нём или в сетевом стеке FreeBSD 12 -
EG> не исключено, что в iflib ещё какие-то косяки с UDP и ты на них
EG> напарываешься; но для этого надо всё-таки сравнить со скоростью
EG> того же под FreeBSD 11.4, ты это уже делал?

Ты таки будешь смеяться, но под FreeBSD 11.4 та же фигня со скоростью.
5 КБайт/с входящий и 8МБайт/с исходящий.
И точно так же лечится отключением rxcsum.

Dmitry