a-zazell Опубликовано 17 декабря, 2013 · Жалоба Здравствуйте, есть схема (во вложении). К центральному узлу подключается офис через 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 декабря, 2013 · Жалоба TCP MSS не распространяется на icmp. Эти ваши l2tp и sstp подтверждения доставки поди шлют, потому и задержки дикие. И не в три а в два раза. Чтобы в три не было нужно быть проще в конфигах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 декабря, 2013 · Жалоба Ну так поставьте в SSTP размер MTU такой, какой проходит через билайновский туннель, тогда пакеты размером меньше этого мту пойдут без фрагментации. Попробуйте запустить пинг в туннеле SSTP с размером MTU, который через билайн проходит, увидите задержку еще меньше. А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 декабря, 2013 · Жалоба А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно. Без этого правила пакеты будет фрагментировать тик, и заполняемость последнего фрагмента будет скорее всего далека от полной. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 18 декабря, 2013 · Жалоба А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно. Без этого правила пакеты будет фрагментировать тик, и заполняемость последнего фрагмента будет скорее всего далека от полной. Они так и так будут фрагментироваться, ведь MTU первого туннеля 1460. Следовательно пакеты меньшего размера пройдут без проблем, а большего пойдут с довеском. Если поверх пустить еще туннель, то его MTU в канале нужно уменьшить, что бы фрагментацией не занимался первый туннель, а сам роутер, тогда уже он будет пакеты фрагментировать по MTU последнего туннеля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 декабря, 2013 · Жалоба Не будут они ферментироваться на хренотике для TCP если правильно заюзать MSS fix - сразу будут маленькими прилетать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 18 декабря, 2013 · Жалоба Не будут они ферментироваться на хренотике для TCP если правильно заюзать MSS fix - сразу будут маленькими прилетать. Попробуйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 декабря, 2013 · Жалоба Вы это кому то другому пишите :) Я во время реализации IP стёка + арп в нетграф ноде эту самую фрагментацию руками к себе перетягивал из исходников ос, а дефрагментацию уже не осилил и скопипастил почти без изменений. И как и куда mss выставляется я тоже прекрасно знаю, и как потом по быстрому контрольная сумма пересчитывается. Посему свои теории проверяйте сами, в нормальных лабах/стенда а не на тике, а я правильный ответ знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 19 декабря, 2013 · Жалоба Вы это кому то другому пишите :) Я во время реализации IP стёка + арп в нетграф ноде эту самую фрагментацию руками к себе перетягивал из исходников ос, а дефрагментацию уже не осилил и скопипастил почти без изменений. И как и куда mss выставляется я тоже прекрасно знаю, и как потом по быстрому контрольная сумма пересчитывается. Посему свои теории проверяйте сами, в нормальных лабах/стенда а не на тике, а я правильный ответ знаю. Зачем мне стенды и лабы, когда можно запустить тест с микротика на микротик, и получить через 2 туннеля полную утилизацию 100 мегабитного канала? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 декабря, 2013 · Жалоба И получить картину мира глазами мыкротика. И с tcpdump не сильно на тырке разойдёшься. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 19 декабря, 2013 · Жалоба И получить картину мира глазами мыкротика. И с tcpdump не сильно на тырке разойдёшься. Ну так если я беру IP и получаю 97/97, далее беру первый туннель, уменьшаю MTU так, что бы пакеты не фрагментировались, и получаю те же 97/97, потом создаю второй туннель и аналогично уменьшив MTU запускаю тест, получаю опять 97/97. Должно быть как-то иначе? Естественно если запускать тест пакетами 1500 байт, то каждый туннель уменьшит скорость примерно на 10 процентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 19 декабря, 2013 (изменено) · Жалоба Перевел на PPTP, проблема ушла. На SSTP менял MTU - толку нет. Изменено 19 декабря, 2013 пользователем a-zazell Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...