Mikrotik: почему огромный пинг через ip-туннель?

Question

[Максим Чорнопольский]

Имеются два микротика, один на нормальном проводном интернете, другой на спутнике (спутнику альтернативы нет). Между ними поднят туннель. Пинги до внешних интерфейсов (по внешке) в пределах нормы, 600-800мс. Пинги между подсетями от 800 до 3500мс. Почему такой пинг и как от него можно избавиться?

tracert -d 172.16.23.144
Трассировка маршрута к 172.16.23.144 с максимальным числом прыжков 30
  1    <1 мс    <1 мс    <1 мс  192.168.1.1
  2  1864 ms  1659 ms  1706 ms  192.168.49.2
  3   946 ms  1259 ms   809 ms  172.16.23.144
Трассировка завершена.

tracert -d 192.168.1.17
Трассировка маршрута к 192.168.1.17 с максимальным числом прыжков 30
  1    <1 мс    <1 мс    <1 мс  172.16.23.49
  2  1668 ms  1691 ms  2107 ms  192.168.49.1
  3   989 ms  1500 ms  1248 ms  192.168.1.17
Трассировка завершена.

172.16.23.0/24 -> спутник
192.168.1.0/24 -> нормальный интернет

Comments

[sonik_spb]

Можно про туннель подробнее?

[Максим Чорнопольский]

192.168.49.1 и 192.168.49.2 это адреса микротиков в туннеле.

Удаленный роутер

/ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          80.x.x.x             1
 1 ADC  80.79.178.0/24     80.79.178.186   ether1-gateway            0
 2 ADC  172.16.23.0/24     172.16.23.49    bridge-local              0
 3 A S  192.168.1.0/24     192.168.49.2    kirova                    1
 4 ADC  192.168.49.0/24    192.168.49.2    kirova                    0

Центральный роутер, с несколькими туннелями

/ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          94.x.x.x		             2
 1 ADC  94.73.215.144/29   94.73.215.145   ether1-gateway            0
 2 A S  172.16.23.0/24     192.168.49.1    andat                     1
 3 A S  172.30.99.0/24     192.168.50.1    tuhterek                  1
 4 A S  192.168.0.0/24     192.168.47.1    192.168.47.2              1
 5 ADC  192.168.1.0/24     192.168.1.1     bridge-local              0
 6 A S  192.168.20.0/24    192.168.48.1    1etag                     1
 7 ADC  192.168.47.0/24    192.168.47.1    bakinskih                 0
 8 ADC  192.168.48.0/24    192.168.48.1    1etag                     0
 9 ADC  192.168.49.0/24    192.168.49.1    andat                     0
10 ADC  192.168.50.0/24    192.168.50.1    tuhterek                  0
11 ADC  192.168.51.0/24    192.168.51.1    chemax                    0
12 A S  192.168.113.0/24                   chemax                    1

Что-то еще?

Answer 1

[Александр Карабанов]

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

Comments

[Максим Чорнопольский]

Но без тоннеля пинг вдвое ниже

[Александр Карабанов]

Хм... А если MTU покрутить в меньшую сторону?

[Максим Чорнопольский]

Подкрутил до 1000, сложно сказать, вроде бы ничего не изменилось.

[Александр Карабанов]

Если под Linux то попробуйте:
ping -M do -s 1000 <IP_из_сети_за_туннелем>

Если под Windows то попробуйте:
ping -f -l 1000 <IP_из_сети_за_туннелем>

И вывод покажите.

[Максим Чорнопольский]

ping -f -l 1000 172.16.23.144

Обмен пакетами с 172.16.23.144 по с 1000 байтами данных:
Ответ от 192.168.1.1: Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.

Статистика Ping для 172.16.23.144:
Пакетов: отправлено = 4, получено = 1, потеряно = 3
(75% потерь)

[Александр Карабанов]

Надо уменьшить MTU. Уменьшайте размер пакета до тех пор пока не начнет пинговаться, затем к полученному значению прибавьте 28 (размер заголовка IP пакета) это и будет MTU подходящий для вашего тунеля.

[Максим Чорнопольский]

Большое спасибо, удалось существенно снизить пинг. В районе 800-1500, что уже терпимо. MTU 400.

[kodi]

@Voiddancer mtu какого интерфейса вы уменьшили? и на какой железке?

[Максим Чорнопольский]

@kodi тоннеля. Обоих.

[kodi]

@Voiddancer проблема один в один как у вас, но внутри туннеля 1472 байта пролазят.
@karabanov не подскажите куда еще заглянуть?)

[Максим Чорнопольский]

@kodi на внешний интерфейс?

[Александр Карабанов]

@Voiddancer, а у вас что за туннель? Необходимо MTU именно туннеля уменьшать.

PS
И это, флаг запрещающий фрагментировать пакет ставили когда пинговали?

[kodi]

@karabanov
Вы наверное мне хотели написать обращение?) если формулировка "а у вас....."

конечно, без этого флага данная проверка не имеет смысла. у меня внутри туннеля пролазит 1472 байта + 28 заголовка получается 1500 байт интерфейса. опенвпн используется. Соответственно смысла меня мту наверное нет?

@Voiddancer
> "на внешний интерфейс?"
что на внешний интерфейс?

[Александр Карабанов]

@kodi, в туннеле MTU 1500 байт? Не может быть. Какой тип туннеля используете (PPTP, L2TP, IPIP, GRE, EoIP)?

[nimbo]

@karabanov "опенвпн используется. " OpenVPN

[kodi]

@nimbo верно, спасибо.
@karabanov да, подумал что фигню сморозил, 1500 байта это же в L3?
но тогда не понятно как у меня оно может пролазить?? Маршрутизатор делает фрагментацию несмотря на запрещающий флаг??

C:\Users\TEMP>ping 192.168.1.2 -f -l 1472
Обмен пакетами с 192.168.1.2 по с 1472 байтами данных:
Ответ от 192.168.1.2: число байт=1472 время=993мс TTL=126
Ответ от 192.168.1.2: число байт=1472 время=1018мс TTL=126
Ответ от 192.168.1.2: число байт=1472 время=1014мс TTL=126
Ответ от 192.168.1.2: число байт=1472 время=1599мс TTL=126

Статистика Ping для 192.168.1.2:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 993мсек, Максимальное = 1599 мсек, Среднее = 1156 мсек

В этих результатах не смотрите на пинг, на магистрали проблемы,поэтому так высоко.

как заметил выше @nimbo - OpenVPN
я нахожусь в сети 192.168.0.0/24, пингую машину из удаленной сети 192.168.1.0/24 через ВПН-сеть 192.168.7.0/24

C:\Users\TEMP>tracert -d 192.168.1.2
Трассировка маршрута к 192.168.1.2 с максимальным числом прыжков 30
1 <1 мс <1 мс <1 мс 192.168.0.97
2 41 ms 40 ms 53 ms 192.168.7.2
3 41 ms 62 ms 66 ms 192.168.1.2
Трассировка завершена.

Вот щас повезло и пинг хороший в канале. Специально не подбирал плохой момент, чтобы продемонстрировать, что бывает все хорошо.

C:\Users\TEMP>ping 192.168.1.2 -t
Обмен пакетами с 192.168.1.2 по с 32 байтами данных:
Ответ от 192.168.1.2: число байт=32 время=64мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=83мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=109мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=87мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=140мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=216мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=76мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=48мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=41мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=40мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=51мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=56мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=42мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=66мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=140мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=44мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=85мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=167мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=42мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=111мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=119мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=102мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=143мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=121мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=124мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=98мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=149мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=213мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=207мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=180мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=130мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=123мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=129мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=121мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=52мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=159мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=164мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=77мс TTL=126
Статистика Ping для 192.168.1.2:
Пакетов: отправлено = 38, получено = 38, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 40мсек, Максимальное = 216 мсек, Среднее = 108 мсек

Видно как в момент трейсроута и первую половину результатов пингов, пинг был норм, потом подскочил. При этом в впн-канале было около 40 пакетов в секунду. А пинг по внешним ip-адресам около 50 мс

[Александр Карабанов]

Ааа. OpenVPN. Хм...
А там в качестве транспортного протокола что, TCP или UDP?
Как далеко географически расположены точки меж которыми OpenVPN?

PS
Может канал чем-то забит торрентами например, не?

[Александр Карабанов]

Я тут вычитал, что OpenVPN средствами своего протокола может проводить фрагментацию и на IP пакете это не будет отражаться (ставь не ставь запрет на фрагментацию всё равно 1500 байт покажет) Пока проверить это не могу, но попробуйте уменьшить MTU и потестить.

PS
Лучше задайте отдельный вопрос. У вас все таки иная проблема.

[Александр Карабанов]

Почитал MAN про OpenVPN вычитал там опцию --mtu-test цитирую:

--mtu-test
Вычислить размер MTU при запуске подключения. OpenVPN будет слать ping пакеты различного размера и искать максимальный размер который успешно доходит. По умолчанию процесс --mtu-test занимает около 3х минут.

Перевод взял здесь: secretsline.biz

Так же можно попробовать включить Path MTU Descovery, это позволит OpenVPN автоматически вычислять оптимальный MTU (подробности в MAN или по вышеприведённой сылке на перевод MAN-a)

[kodi]

@karabanov используется TCP. географически разнесены 30 км. Канал не забит точно.
Вопрос мой существует, но безрезультатно(( - Высокий пинг в vpn канале, снаружи нормальный
MTU можно выставить в конфиге OpenVPN и тогда пролазит именно столько, сколько там указанно.
Попробовал выставить 1460.
При чем имеется несколько подключений и только на одном такой расколбас.

з.ы. используйте "упоминание" пользователя, а то Ваших сообщений не видно в трекере.
Спасибо.

[kodi]

@karabanov И опять же пинг то был по 32 байта, наверное в данном случаи мту не при чем?

C:\Windows\System32>ping xxx.ru
Обмен пакетами с xxx.ru [123.123123.123] с 32 байтами данных:
Ответ от 123.123123.123: число байт=32 время=58мс TTL=247
Ответ от 123.123123.123: число байт=32 время=40мс TTL=247
Ответ от 123.123123.123: число байт=32 время=39мс TTL=247
Ответ от 123.123123.123: число байт=32 время=53мс TTL=247

Статистика Ping для 123.123123.123:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 39мсек, Максимальное = 58 мсек, Среднее = 47 мсек

C:\Windows\System32>ping 192.168.1.2
Обмен пакетами с 192.168.1.2 по с 32 байтами данных:
Ответ от 192.168.1.2: число байт=32 время=143мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=100мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=89мс TTL=126
Ответ от 192.168.1.2: число байт=32 время=132мс TTL=126

Статистика Ping для 192.168.1.2:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 89мсек, Максимальное = 143 мсек, Среднее = 116 мсек

Два параллельных пинга - по внешке и по внутренней, по 32 байта. Сейчас. МТУ OpenVPN - 1460.

[Александр Карабанов]

@kodi, поробуйте сбросить настройки, обновить прошивку, и все настроить заново. Пока ничего иного в голову не приходит.

PS
Попробуйте mtr IP_на_другом_конце_туннеля может быть покажет что нибудь интересное. И да, все же сбросьте настройки и обновите прошивку.

[kodi]

@karabanov
тоже пришла мысль попробовать все вручную заново настроить на другой железяке и там же включится в "линию". Рабочую железяку трогать нельзя, она юзается постоянно.

mtr - это софт типа traceroute?

[Александр Карабанов]

@kodi, ога, типо трейсроут.

Answer 2

[Кирилл Васильев]

запутали вас с MTU по полной.
надо не уменьшать MTU, так как это приведёт к увлечению нагрузки на канал, вы должны выставить MTU тот которое вам отдаёт провайдер. а дальше вы должны просто установить окно передачи данных change-mss для туннеля.
а также уточнить какой туннель вы используете?

Comments

[Александр Карабанов]

@vasilevkirill, он же написал, что OpenVPN

[kodi]

@vasilevkirill можно про окно передачи данных поподробней, mss - так пониманию оно?
по мту понятное дело, что миллион мелких пакетов в канал - это ненужная работа, когда более крупные пакеты ходят нормально. это может помочь только в диагностике.

[Кирилл Васильев]

@kodi openvpn не самый лучший вариант, посмотрите в сторону ipip или gre если нужно шифрование то используйте ipsec.
минус в сторону опенвпн конкретно на микротике не рализована поддержка UDP, а с вашиv каналом, гнать по TCP туннель BAD Idea

[kodi]

@vasilevkirill вот интересная тема, можете дать наводку что почитать или кратко почему tcp хуже udp? большое количество "холостого" трафика при достаточно большом полезного?
и можно пояснить что Вы имели ввиду под "вашим каналом"?
у меня просто два доп.офиса. в одном все отлично, в другом проблемы. в них разные провайдеры.

[Кирилл Васильев]

@kodi Ваш канал это OpenVPN over TCP

При таком канале идёт вторичная проверка TCP и Имеет бесполезную суть.

так как TCP в туннеле и так будет проверятся доставлен он или нет.
А UDP в любом случае будет теряться!

[kodi]

@vasilevkirill Я Вас услышал)). Спасибо.
А по текущей схеме у Вас нет догадок из-за чего так может быть?

[kodi]

@vasilevkirill ipsec самодостаточен или его надо инкапсулировать в ipip?

[Кирилл Васильев]

всё зависит от вашей конфигурации, если у вас там одна под сеть, и не планируется других, то IPSec
но IPes очень плохо дружит с маршрутизацией, а точнее он работает как триггер. и поэтому у вас нету интерфейса который явным образом можно указывать в настройках фильтров.

Вообщем всё зависит от того что вы хотите получить от туннеля.

[Александр Карабанов]

@vasilevkirill, я, значит, запутал автора вопроса с MTU после коррекции которого все стало работать значительно лучше, а вы с IPsec ни разу не запутали автора второго вопроса? :-)

[kodi]

@vasilevkirill
где "там" одна подсеть? что значит IPSec плохо с маршрутизацией дружит? он же не занимается ей.
у нас есть основной роутер, за которым основная подсеть. и есть клиентские микротики, за которыми клиентские подсети.