[Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Michael A. Kangin]

Добрый день.

Имеем некую удаленную сетку, к которой организовано vpn-подключение c помощью 
pptpd. Если мы пытаемся скачать из той сетки файлик по FTP напрямую, без VPN, 
то имеем скорость порядка 500-600 кбайт/сек. Если же тот же файлик с того же 
сервера, но через VPN - то скорость драматически падает до 100-50 кбайт/сек 
(постоянно меняется рывками) и в логи валятся сообщения вида:
-----------
Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
buffering packet 866 (expecting 863, lost or reordered)
Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
buffering packet 867 (expecting 863, lost or reordered)
-------------
в диких причем количествах. Попробовал гуглить - все свелось к советам 
отключить дебаг-логи или покрутить mtu/mru. Покрутил, не помогло. 


Что тут можно присоветовать, ну, кроме смены pptpd на openvpn?
pptpd версии 1.3.4-alt1, pppd - 2.4.4-alt7 на обеих сторонах.


-- 
wbr, Michael A. Kangin
OIOS, RSMU

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Евгений]

В сообщении от Sunday 09 December 2007 16:47:24 Michael A. Kangin написал(а):
> Добрый день.
>
> Имеем некую удаленную сетку, к которой организовано vpn-подключение c
> помощью pptpd. Если мы пытаемся скачать из той сетки файлик по FTP
> напрямую, без VPN, то имеем скорость порядка 500-600 кбайт/сек. Если же тот
> же файлик с того же сервера, но через VPN - то скорость драматически падает
> до 100-50 кбайт/сек (постоянно меняется рывками) и в логи валятся сообщения
> вида:
> -----------
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]:
> buffering packet 866 (expecting 863, lost or reordered)
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]:
> buffering packet 867 (expecting 863, lost or reordered)
> -------------
> в диких причем количествах. Попробовал гуглить - все свелось к советам
> отключить дебаг-логи или покрутить mtu/mru. Покрутил, не помогло.
>
>
> Что тут можно присоветовать, ну, кроме смены pptpd на openvpn?
> pptpd версии 1.3.4-alt1, pppd - 2.4.4-alt7 на обеих сторонах.

Ага. Имеется та же проблема. И тоже хотелось бы решить.

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Gennady Kovalev]

> > Что тут можно присоветовать, ну, кроме смены pptpd на openvpn?
> > pptpd версии 1.3.4-alt1, pppd - 2.4.4-alt7 на обеих сторонах.
>
> Ага. Имеется та же проблема. И тоже хотелось бы решить.

На нескольких сеоверах тоже есть. Долго мучался. Смирился. И с этим вроде 
работает.

-- 
Gennady Kovalev, 
BIGUR, ALT Linux Team.

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Gosha]

Hi!

Michael A. Kangin пишет:

> Имеем некую удаленную сетку, к которой организовано vpn-подключение c помощью 
> pptpd. Если мы пытаемся скачать из той сетки файлик по FTP напрямую, без VPN, 
> то имеем скорость порядка 500-600 кбайт/сек. Если же тот же файлик с того же 
> сервера, но через VPN - то скорость драматически падает до 100-50 кбайт/сек 
> (постоянно меняется рывками) и в логи валятся сообщения вида:
> -----------
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
> buffering packet 866 (expecting 863, lost or reordered)
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
> buffering packet 867 (expecting 863, lost or reordered)
> -------------
> в диких причем количествах. Попробовал гуглить - все свелось к советам 
> отключить дебаг-логи или покрутить mtu/mru. Покрутил, не помогло. 

IMHO все-таки "крутить" MTU в сторону уменьшения.

--
Best regards!
Igor Solovyov

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

On Sun, Dec 09, 2007 at 04:47:24PM +0300, Michael A. Kangin wrote:
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
> buffering packet 866 (expecting 863, lost or reordered)
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
> buffering packet 867 (expecting 863, lost or reordered)

1. Посмотреть, как ведёт себя ping -f -s1400 до другого конца туннеля;
   возможно, заняться поиском причин потерь пакетов (ещё более жёсткий
   тест: -s32000 или -s64000, но на такие запросы не всегда отвечают).
   В некоторых случаях ещё стоит посмотреть, как меняется картина при
   изменении содержимого пакетов (опция -p) - наблюдался случай, когда
   нормально проходили почти все пакеты, кроме заполненных 00 или ff.

2. У pptp есть опция --nobuffer, которая позволяет отключить проверку
   номеров пакетов; в этом случае убираются задержки, возникающие
   после потери пакета, и с этими потерями будет разбираться уже,
   например, TCP для соединения, проброшенного через VPN.  Есть также
   опция --timeout, позволяющая регулировать время ожидания при
   переупорядочении пакетов (хотя я подозреваю, что в реальности все
   эти меры бесполезны, поскольку обычно пакеты просто пропадают,
   поэтому ждать прихода старого пакета уже бессмысленно).

3. Ещё одна полезная опция для pptp - --sync (использовать совместно с
   опцией sync для pppd); в случае, если на другой стороне такой
   вариант поддерживается, можно уменьшить расход процессорного
   времени на обработку пакетов (что особенно заметно на слабом
   железе).  Хотя к потерям пакетов это уже не имеет отношения.

> в диких причем количествах. Попробовал гуглить - все свелось к советам 
> отключить дебаг-логи или покрутить mtu/mru. Покрутил, не помогло. 

Тем не менее указывать правильное значение MTU тоже нужно - обычно на
40 байт меньше, чем Path MTU между концами туннеля (если там 1500,
нужно писать mtu 1460).  В Windows XP по умолчанию используется 1400,
чтобы пакеты GRE передавались без фрагментации даже при наличии по
дороге ещё каких-то туннелей.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Michael A. Kangin]

On 9 декабря 2007 Gosha <gosha@anti.su> wrote:

> IMHO все-таки "крутить" MTU в сторону уменьшения.

Пробовал. Крутануть до 1200 - ничего не даёт, до 512 - становится резко хуже.


-- 
wbr, Michael A. Kangin
OIOS, RSMU

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Michael A. Kangin]

On 9 декабря 2007 Sergey Vlasov <vsu@altlinux.ru> wrote:

> On Sun, Dec 09, 2007 at 04:47:24PM +0300, Michael A. Kangin wrote:
> > Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]:
> > buffering packet 866 (expecting 863, lost or reordered)
> > Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]:
> > buffering packet 867 (expecting 863, lost or reordered)
>
> 1. Посмотреть, как ведёт себя ping -f -s1400 до другого конца туннеля;
>    возможно, заняться поиском причин потерь пакетов (ещё более жёсткий
>    тест: -s32000 или -s64000, но на такие запросы не всегда отвечают).

ну с ADSLных пользователей пакеты теряются при таком забивании канала, да. Но 
почему ж такая дикая потеря производительности-то получается?

>    В некоторых случаях ещё стоит посмотреть, как меняется картина при
>    изменении содержимого пакетов (опция -p) - наблюдался случай, когда
>    нормально проходили почти все пакеты, кроме заполненных 00 или ff.

не влияет вроде.


> 2. У pptp есть опция --nobuffer, которая позволяет отключить проверку
>    номеров пакетов; в этом случае убираются задержки, возникающие
>    после потери пакета, и с этими потерями будет разбираться уже,
>    например, TCP для соединения, проброшенного через VPN.  Есть также
>    опция --timeout, позволяющая регулировать время ожидания при
>    переупорядочении пакетов (хотя я подозреваю, что в реальности все
>    эти меры бесполезны, поскольку обычно пакеты просто пропадают,
>    поэтому ждать прихода старого пакета уже бессмысленно).

Ага, игрался уже, не помогает.

> 3. Ещё одна полезная опция для pptp - --sync (использовать совместно с
>    опцией sync для pppd); в случае, если на другой стороне такой
>    вариант поддерживается, можно уменьшить расход процессорного
>    времени на обработку пакетов (что особенно заметно на слабом
>    железе).  Хотя к потерям пакетов это уже не имеет отношения.
>
> > в диких причем количествах. Попробовал гуглить - все свелось к советам
> > отключить дебаг-логи или покрутить mtu/mru. Покрутил, не помогло.
>
> Тем не менее указывать правильное значение MTU тоже нужно - обычно на
> 40 байт меньше, чем Path MTU между концами туннеля (если там 1500,
> нужно писать mtu 1460).  В Windows XP по умолчанию используется 1400,
> чтобы пакеты GRE передавались без фрагментации даже при наличии по
> дороге ещё каких-то туннелей.

ну поставил, не помогло все равно.

А будет с openvpn проще, если так пакетики умеют теряются?


-- 
wbr, Michael A. Kangin
OIOS, RSMU

Re: [Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Nikolay A. Fetisov]

On Mon, 10 Dec 2007 00:04:53 +0300
Michael A. Kangin wrote:

> ...
> ну с ADSLных пользователей пакеты теряются при таком забивании канала, да. Но 
> почему ж такая дикая потеря производительности-то получается?

Вообще говоря, скорость передачи данных через VPN всегда будет меньше,
чем напрямую - из-за накладных расходов. В случае потерь пакетов
существенное влияние оказывает тип VPN. 
Общее описание причин того, что у Вас происходит, можно глянуть в
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html , хотя
непосредственно к PPTP эта заметка отношения не имеет.

> ...
> А будет с openvpn проще, если так пакетики умеют теряются?

Если нет необходимости использовать именно pptp - попробуйте. Хуже стать
не должно, лучше - может. Хотя бы потому, что из регулярных потерь
пакетов GRE отнюдь не следует аналогичная ситуация с пакетами UDP...

-- 
С уважением,
Николай Фетисов