[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