[a-zazell]

Здравствуйте, есть схема (во вложении). К центральному узлу подключается офис через Beeline (l2tp 1460MTU / 1464 MRU + IP FIREWALL MANGLE FWD change TCP MSS) с использованием SSTP VPN (1500 MTU/MRU).

 

На Core наблюдаю картину:

 

[admin@Core] > ping 10.254.248.15 size=1500
HOST                                     SIZE TTL TIME  STATUS                         
10.254.248.15                            1500  64 155ms
10.254.248.15                            1500  64 156ms
10.254.248.15                            1500  64 172ms
10.254.248.15                            1500  64 151ms
   sent=4 received=4 packet-loss=0% min-rtt=151ms avg-rtt=158ms max-rtt=172ms 

[admin@Core] > ping 10.254.248.15 size=1501
HOST                                     SIZE TTL TIME  STATUS                         
10.254.248.15                            1501  64 456ms
10.254.248.15                            1501  64 328ms
10.254.248.15                            1501  64 325ms
10.254.248.15                            1501  64 447ms
10.254.248.15                            1501  64 476ms
   sent=5 received=5 packet-loss=0% min-rtt=325ms avg-rtt=406ms max-rtt=476ms 

 

В три раза пинг вырастает, может быть кто сталкивался с подобной проблемой?

 

Делал с обеих сторон правила /ip firewall mangle action change TCP MSS до 1460 в диапазоне 1390-65534 - пакетов нет, пока "не въеду" чего им надо.

 

Конфиги Core Router:

 

 

 

[admin@Core] > interface sstp-server export 
/interface sstp-server server
set authentication=mschap1,mschap2 certificate=stb-bisv default-profile=default enabled=yes keepalive-timeout=60 max-mru=1500 max-mtu=1500 mrru=disabled port=443 \
   verify-client-certificate=no

[admin@Core] > ppp secret export 
/ppp secret
add caller-id="" comment=Office disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=\
   10.254.248.3 name=Office password=SuperPupperSecret profile=default-encryption remote-address=\
   10.254.248.15 routes="" service=any
[admin@Core] > ppp profile export 
/ppp profile
set 3 change-tcp-mss=yes name=default-encryption only-one=default use-compression=default \
   use-encryption=yes use-mpls=default use-vj-compression=default

 

 

 

Конфиги Office Router:

 

 

 

[admin@Office] > interface sstp-client export 
/interface sstp-client
add add-default-route=no authentication=pap,chap,mschap1,mschap2 certificate=cert1 connect-to=\
   <Core IP>:443 dial-on-demand=no disabled=no http-proxy=0.0.0.0:443 keepalive-timeout=60 \
   max-mru=1500 max-mtu=1500 mrru=disabled name=Core password=SuperPupperSecret profile=\
   default-encryption user=Office verify-server-address-from-certificate=yes \
   verify-server-certificate=no

[admin@Office] > interface l2tp-client export 
/interface l2tp-client
add add-default-route=no allow=pap,chap,mschap1,mschap2 connect-to=<Beeline VPN Server IP> dial-on-demand=\
   no disabled=no max-mru=1460 max-mtu=1460 mrru=disabled name=vpn-beeline password=\
   MegaSecret profile=default-encryption user=BeelineUsername

[admin@Office] > ip firewall mangle export 
/ip firewall mangle
add action=change-mss chain=forward disabled=no in-interface=vpn-beeline new-mss=1420 passthrough=\
   yes protocol=tcp tcp-flags=syn tcp-mss=1391-65535
add action=change-mss chain=forward disabled=no new-mss=1420 out-interface=vpn-beeline \
   passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1391-65535

 

[Ivan_83]

TCP MSS не распространяется на icmp.

Эти ваши l2tp и sstp подтверждения доставки поди шлют, потому и задержки дикие.

И не в три а в два раза. Чтобы в три не было нужно быть проще в конфигах.

[Saab95]

Ну так поставьте в SSTP размер MTU такой, какой проходит через билайновский туннель, тогда пакеты размером меньше этого мту пойдут без фрагментации.

 

Попробуйте запустить пинг в туннеле SSTP с размером MTU, который через билайн проходит, увидите задержку еще меньше. А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно.

[Ivan_83]

А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно.

Без этого правила пакеты будет фрагментировать тик, и заполняемость последнего фрагмента будет скорее всего далека от полной.

[Saab95]

А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно.

Без этого правила пакеты будет фрагментировать тик, и заполняемость последнего фрагмента будет скорее всего далека от полной.

 

Они так и так будут фрагментироваться, ведь MTU первого туннеля 1460. Следовательно пакеты меньшего размера пройдут без проблем, а большего пойдут с довеском. Если поверх пустить еще туннель, то его MTU в канале нужно уменьшить, что бы фрагментацией не занимался первый туннель, а сам роутер, тогда уже он будет пакеты фрагментировать по MTU последнего туннеля.

[Ivan_83]

Не будут они ферментироваться на хренотике для TCP если правильно заюзать MSS fix - сразу будут маленькими прилетать.

[Saab95]

Не будут они ферментироваться на хренотике для TCP если правильно заюзать MSS fix - сразу будут маленькими прилетать.

 

Попробуйте.

[Ivan_83]

Вы это кому то другому пишите :)

Я во время реализации IP стёка + арп в нетграф ноде эту самую фрагментацию руками к себе перетягивал из исходников ос, а дефрагментацию уже не осилил и скопипастил почти без изменений.

И как и куда mss выставляется я тоже прекрасно знаю, и как потом по быстрому контрольная сумма пересчитывается.

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

[Saab95]

Вы это кому то другому пишите :)

Я во время реализации IP стёка + арп в нетграф ноде эту самую фрагментацию руками к себе перетягивал из исходников ос, а дефрагментацию уже не осилил и скопипастил почти без изменений.

И как и куда mss выставляется я тоже прекрасно знаю, и как потом по быстрому контрольная сумма пересчитывается.

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

 

Зачем мне стенды и лабы, когда можно запустить тест с микротика на микротик, и получить через 2 туннеля полную утилизацию 100 мегабитного канала?

[Ivan_83]

И получить картину мира глазами мыкротика. И с tcpdump не сильно на тырке разойдёшься.

[Saab95]

И получить картину мира глазами мыкротика. И с tcpdump не сильно на тырке разойдёшься.

 

Ну так если я беру IP и получаю 97/97, далее беру первый туннель, уменьшаю MTU так, что бы пакеты не фрагментировались, и получаю те же 97/97, потом создаю второй туннель и аналогично уменьшив MTU запускаю тест, получаю опять 97/97. Должно быть как-то иначе? Естественно если запускать тест пакетами 1500 байт, то каждый туннель уменьшит скорость примерно на 10 процентов.

[a-zazell]

Перевел на PPTP, проблема ушла.

На SSTP менял MTU - толку нет.

Изменено 19 декабря, 2013 пользователем a-zazell