R
какая скорость
Size: a a a
2018 April 30
LB
Смотри есть офис 1 и офис 2 в офисе 2 есть видеонаблюдение где иногда архив надо копировать в офис 1 по впн. В обоих офисах микротик стоит через 4g соединение
LB
Банд тест скорости обоих микротиков даёт 20 и по tcp и udp
LB
Но самба скачет
VO
Mssfix?
LB
Что это?
LB
Я только mtu настроил так глубоко не копал ))
VO
У l2tp хотя не помню, актуально ли, у openvpn и pptp 75% проблем из за него
VO
Там что то связанное с привычкой софта и осей выбирать окно для tcp меньшее
AC
Если с роутеров бандтест делать то между ними скорость норм
у микротика бандтест по умолчанию udp
AC
ты tcp делал?
AC
между серваками или на произвольный сервер?
VO
mssfix maxAnnounce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.
The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.
The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.
--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.
Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.
The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.
If --fragment and --mssfix are used together, --mssfixwill take its default max parameter from the --fragment max option.
Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:
--tun-mtu 1500 --fragment 1300 --mssfix
The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.
The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.
--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.
Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.
The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.
If --fragment and --mssfix are used together, --mssfixwill take its default max parameter from the --fragment max option.
Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:
--tun-mtu 1500 --fragment 1300 --mssfix
m
Mssfix?
Разве mss не влияет на http?
LB
ты tcp делал?
На обоих там менять можно одинаково 20
LB
между серваками или на произвольный сервер?
Между микротиками
VO
Разве mss не влияет на http?
По опыту оно может влиять и не влиять на что угодно, я вроде €везде всегда включал
LB
Там что то связанное с привычкой софта и осей выбирать окно для tcp меньшее
А что за окна?
m
По опыту оно может влиять и не влиять на что угодно, я вроде €везде всегда включал
Mssfix, это разве не Maximum segment size fixed? Фиксированный, тобишь
LB
В итоге что посоветуете парни?