+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

проблема с размером пакета клиента pptp

проблема с размером пакета клиента pptp, RouterOS

guk

Guest

25.05.2009 13:03:00

Привет, у меня есть маршрутизатор Cisco 7204, к которому подключены два MikroTik через PPTP для VPN. Первый MikroTik работает на ROS 2.9.51, второй — на 3.23. Пинг с Cisco на первый проходит нормально, фрагментируется корректно для пакетов размером больше mtu/mru, но пинг с Cisco на второй показывает 90-100% потерь пакетов. Кроме того, у второго шлюза LAN MTU 1420, поэтому я хочу установить mru на MikroTik на 1380, но даже когда я устанавливаю это значение, в статусе отображается, что mru — 1400 (это значение тестировалось и является самым маленьким возможным). Что касается pingo tcp-mss, это не помогает, знаешь ли ты способ заставить «большие» пакеты работать? 3.23: /interface pptp-client
add add-default-route=no allow=pap,chap,mschap1,mschap2 connect-to=MYIP dial-on-demand=no disabled=no \
max-mru=1380 max-mtu=1344 mrru=1344 name=MYNAME password=MYPASS profile=default-encryption user=MYUSER

/interface pptp-client monitor MYNAME
status: "connected"
uptime: 12m44s
idle-time: 0s
encoding: "MPPE128 stateless"
mtu: 1344
mru: 1400 cisco#ping vrf MYVLAN FIRST size 1600 timeout 1 repeat 5 validate

Type escape sequence to abort.
Отправка 5 ICMP Echo размером 1600 байт на FIRST, таймаут 1 секунда:
Данные ответа будут проверены
!!!!!
Процент успешных ответов 100 процентов (5/5), минимальное/среднее/максимальное время кругового пути = 16/17/20 мс

cisco#ping vrf MYVLAN SECOND size 1600 timeout 1 repeat 5 validate

Type escape sequence to abort.
Отправка 5 ICMP Echo размером 1600 байт на SECOND, таймаут 1 секунда:
Данные ответа будут проверены
.....
Процент успешных ответов 0 процентов (0/5)

guk

Guest

25.06.2009 15:42:00

IP-aus-VPN:~ # ping -s 1317 -c 7 PPTP-Einwahl-IP-M want PING PPTP-Einwahl-IP(PPTP-Einwahl-IP) 1317(1345) байт данных. --- Статистика ping для PPTP-Einwahl-IP --- 7 пакетов передано, 0 получено, 100% потеря пакетов, время 6000мс. лог iptraf linux: Чт июн 25 16:48:02 2009; ******** Мониторинг IP-трафика запущен ******** Чт июн 25 16:48:18 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:18 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:48:19 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:19 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:48:20 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:20 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:48:21 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:21 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:48:22 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:22 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:48:23 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:23 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:48:24 2009; ICMP; eth0; 1340 байт; от IP-aus-VPN к PPTP-Einwahl-IP; echo req Чт июн 25 16:48:24 2009; ICMP; eth0; 25 байт; от IP-aus-VPN к PPTP-Einwahl-IP; фрагмент Чт июн 25 16:49:11 2009; ******** Мониторинг IP-трафика остановлен ******** и лог tik: есть у кого-то идея, почему оба пакета GRE принимаются, а отображается только меньший фрагмент ICMP?

guk Guest	#3 0 14.08.2009 08:38:00 никто не знает?

changeip Guest	#4 0 14.08.2009 15:04:00 какого типа эти ICMP? Это просто пакеты ответа с недоступными портами или что-то еще? Можешь выложить pcap?

guk

Guest

22.03.2010 14:05:00

Старая линия отключена, но теперь у меня возникла новая, похожая проблема на другой линии: у меня есть Cisco 7200, работающий в качестве PPTP-сервера. У меня есть две разные DSL-линии, на каждой из которых стоит Mikrotik rb450 с ROS 4.5. Оба имеют pptp-туннель (клиент) к Cisco. На одной линии пинг до внешнего IP и из VPN до внутреннего IP работает хорошо. На другой линии пинг до внешнего IP работает, но крупные пакеты в VPN теряются. Я запустил сниффер на неисправном Mikrotik. Похоже, что когда пакет слишком большой, он фрагментируется (это нормально), и чаще всего меньший пакет с «номером фрагмента 2» приходит раньше, чем «пакет с фрагментом 1», и Mikrotik не может с этим справиться. На сниффере видно, что оба GRE-пакета из pptp-туннеля получены, но в туннеле Mikrotik показывает только второй фрагмент: linux-in-vpn# ping -M want -c 9 -s 1840 -w 10 vpn.tik.xxx.211

changeip

Guest

22.03.2010 15:36:00

Я также наблюдал это на туннелях Lt2P... Поскольку это UDP, пакеты приходят не в том порядке, и тогда шифрование выходит из синхронизации. Мне все равно хотелось бы разобраться с этой проблемой. Вот мои теории: 1 - какой-то другой роутер по пути переупорядочивает пакеты, возможно, где-то в сети есть маршрутизация ECMP. Асинхронная маршрутизация. 2 - в середине находится QoS, который приоритизирует и отправляет сначала более мелкие пакеты. 3 - переработка фрагментации IP должна работать, даже если это происходит, я так думал. Главное, чтобы контроль соединения был включен. Может, кто-то подскажет, почему этот ядро не может обрабатывать пакеты не в порядке, как это происходит.

guk

Guest

23.03.2010 14:40:00

Хмм: http://support.microsoft.com/kb/292788 СИМПТОМЫ Протокол туннелирования точка-точка Microsoft (PPTP) отбрасывает все пакеты, которые принимаются вне последовательности. ПРИЧИНА PPTP полагается на протокол обобщенной маршрутизации в Интернете (GRE). Microsoft строго придерживается RFC 2890 "Расширения ключей и номеров последовательности для GRE", который в разделе 2.2 утверждает: Когда декапсулятор получает пакет вне последовательности, он ДОЛЖЕН быть молча отброшен. Так что похоже, что не только Mikrotik сталкивается с такими проблемами из-за идиотского DSL, который передает пакеты GRE вне порядка. Кто-нибудь знает обходной путь?

changeip

Guest

23.03.2010 15:58:00

Запустите это на ваш IP-адрес и посмотрите, сколько различных маршрутов рядом с вами — возможно, вы сможете найти место в вашем провайдере, чтобы попросить их помочь исправить проблему? http://www.changeip.com/tools/tr.php Указанный инструмент работает некоторое время, потому что он производит трассировку до вас из множества мест. Это дает вам хорошее представление о топологии маршрута, по которому идут ваши пакеты. Я предполагаю, что пакеты приходят не по порядку, потому что что-то на вышестоящем уровне делает ECMP или QoS, или, может быть, это ваш маршрутизатор? У вас есть какой-либо QoS на вашем маршрутизаторе? Сам.

changeip

Guest

23.03.2010 16:09:00

Мне интересно, не мог бы ты получить pcap-файл с некоторыми из пакетов, которые приходят не по порядку, на выходе из твоего роутера, и проверить последовательные номера, чтобы понять, действительно ли они в порядке - или проблема происходит где-то в сети? Также проверь TTL на полученных пакетах, чтобы выяснить, отличается ли количество переходов, когда они приходят?

guk

Guest

#10

23.03.2010 16:46:00

У Cisco есть ATM uplink, поэтому мне будет сложно фильтровать трафик между ними. Я постараюсь — спасибо за ожидание. LAN MTU = 1500, PPTP tunnel MTU установлен на 1400 → 3 фрагмента в GRE. Редактирование: PCAP на MikroTik → Wireshark: GRE (PPP compress): плохой пинг: Frame 44 TTL 247 Номер последовательности: 1159229 (182 байта в сети, 182 байта захвачено) Frame 46 TTL 247 Номер последовательности: 1159228 (1454 байта в сети, 1454 байта захвачено) Frame 47 TTL 247 Номер последовательности: 1159230 (446 байтов в сети, 446 байтов захвачено) Хороший пинг: Frame 52 TTL 247 Номер последовательности: 1159231 (1454 байта в сети, 1454 байта захвачено) Frame 53 TTL 247 Номер последовательности: 1159232 (182 байта в сети, 182 байта захвачено) Frame 56 TTL 247 Номер последовательности: 1159233 (446 байтов в сети, 446 байтов захвачено) IP (ICMP ping): плохой пинг: Frame 45 Общая длина: 124 Время жизни: 59 Сдвиг фрагмента: 1376 Frame 48 Общая длина: 388 Время жизни: 59 Сдвиг фрагмента: 1480 Хороший пинг: Frame 54 Общая длина: 1396 Время жизни: 59 Сдвиг фрагмента: 0 Frame 55 Общая длина: 124 Время жизни: 59 Сдвиг фрагмента: 1376 Frame 57 Общая длина: 388 Время жизни: 59 Сдвиг фрагмента: 1480 http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation#Packet_header Номер последовательности присутствует (большая буква S), 1 бит Если установлен, то поле номера последовательности присутствует и содержит действительную информацию. Номер последовательности, 32 бита Содержит число, которое вставляется инкапсулятором. Его может использовать получатель, чтобы установить порядок, в котором пакеты были переданы от инкапсулятора к получателю. PCAP dump говорит bit=1 и номер последовательности, как показано. Так что, на мой взгляд, MikroTik должен быть в состоянии правильно переставить пакеты.

guk Guest	#11 0 26.03.2010 11:43:00 RFC2637 - Протокол туннелирования точка-точка (PPTP) http://www.faqs.org/rfcs/rfc2637.html PPTP Сетевой Сервер (PNS) PPTP Концентратор доступа (PAC) 4.3. Пакеты вне последовательности Порой пакеты теряют свою последовательность в сложной межсетевой структуре. Допустим, PNS отправляет пакеты с номерами 0 по 5 в PAC. Из-за повторной маршрутизации в межсети, пакет 4 приходит в PAC до пакета 3. PAC подтверждает получение пакета 4 и может предположить, что пакет 3 потерян. Это подтверждение предоставляет кредит окна за пределами пакета 4. Когда PAC получает пакет 3, он НИКАК не должен пытаться передать его соответствующему клиенту PPP. Поступление пакета 3 нарушит корректную работу протокола PPP, так как он предполагает получение пакетов в последовательности. PPP корректно обрабатывает потерю пакетов, но не их переупорядочение, поэтому пакеты вне последовательности между PNS и PAC ДОЛЖНЫ быть бесшумно отброшены, иначе они могут быть переупорядочены приемником. Когда пакет 5 приходит, его подтверждает PAC, поскольку он имеет более высокий номер последовательности, чем 4, который был последним подтвержденным пакетом PAC. Пакеты с дублирующими номерами последовательности никогда не должны появляться, так как PAC и PNS никогда не повторно передают GRE-пакеты. Надежная реализация будет бесшумно отбрасывать дублирующие GRE-пакеты, если она их получит. Учитывая, что этот DSL отправляет 97% пакетов вне порядка (меньшие пакеты приходят раньше больших), мне хотелось бы узнать, возможно ли реализовать «переупорядочение приемником» вместо «отбрасывания»?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры