[Sysadmins] tc + pppd

[Sysadmins] tc + pppd

[Александр Новосёлов]

впн сервер, поднятое соединение... 

клиент пингует мою сторону туннеля

как только выполняю команду :

tc qdisc add dev ppp0 root tbf rate 1024kbit latency 50ms burst 300k

не пингуется, хотя tcpdump показывает входящие icmp запросы

tc qdisc del dev ppp0 root решает проблему. 

тоже самое работает на M2.4

Re: [Sysadmins] tc + pppd

[Peter V. Saveliev]

В сообщении от Monday 04 February 2008 13:52:53 Александр Новосёлов 
написал(а):
> впн сервер, поднятое соединение...
>
> клиент пингует мою сторону туннеля
>
> как только выполняю команду :
>
> tc qdisc add dev ppp0 root tbf rate 1024kbit latency 50ms burst 300k
>
> не пингуется, хотя tcpdump показывает входящие icmp запросы
>
> tc qdisc del dev ppp0 root решает проблему.
>
> тоже самое работает на M2.4
<skip />

Версии ядра/iproute2 на работающем/не работающем решении?

-- 
Peter V. Saveliev

Re: [Sysadmins] tc + pppd

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

В сообщении от 4 февраля 2008 Peter V. Saveliev написал(a):
> В сообщении от Monday 04 February 2008 13:52:53 Александр Новосёлов
>
> написал(а):
> > впн сервер, поднятое соединение...
> >
> > клиент пингует мою сторону туннеля
> >
> > как только выполняю команду :
> >
> > tc qdisc add dev ppp0 root tbf rate 1024kbit latency 50ms burst 300k
> >
> > не пингуется, хотя tcpdump показывает входящие icmp запросы
> >
> > tc qdisc del dev ppp0 root решает проблему.
> >
> > тоже самое работает на M2.4
>
> <skip />
>
> Версии ядра/iproute2 на работающем/не работающем решении?


См. соседнее письмо с большими подробностями.

работает - Master 2.4 - 2.4.26-srv-up-alt13.1 (изменения в ядре только на 
число pty 256 -> 2048)

не работает на 2.6.18-std-smp-alt11 ALT Linux 4.0 Server (Walnut)

Re: [Sysadmins] tc + pppd

[Mike]

В сообщении от Monday 04 February 2008 17:45:26 Александр Новоселов 
написал(а):
> В сообщении от 4 февраля 2008 Peter V. Saveliev написал(a):
> > В сообщении от Monday 04 February 2008 13:52:53 Александр Новосёлов
> >
> > написал(а):
> > > впн сервер, поднятое соединение...
> > >
> > > клиент пингует мою сторону туннеля
> > >
> > > как только выполняю команду :
> > >
> > > tc qdisc add dev ppp0 root tbf rate 1024kbit latency 50ms burst 300k
> > >
> > > не пингуется, хотя tcpdump показывает входящие icmp запросы
> > >
> > > tc qdisc del dev ppp0 root решает проблему.
> > >
> > > тоже самое работает на M2.4
> >
> > <skip />
> >
> > Версии ядра/iproute2 на работающем/не работающем решении?
>
> См. соседнее письмо с большими подробностями.
>
> работает - Master 2.4 - 2.4.26-srv-up-alt13.1 (изменения в ядре только на
> число pty 256 -> 2048)
>
> не работает на 2.6.18-std-smp-alt11 ALT Linux 4.0 Server (Walnut)
Чем Вас не устраивает CBQ?
-- 
С уважением,

Михаил Александрович, Плужников
Системный администратор
ООО "РДМ-холдинг"
тел.: (495) 981-0322
e-mail: madm@rdm.ru
site: www.rdm.ru

Re: [Sysadmins] tc + pppd

[Александр Новосёлов]

В сообщении от 4 февраля 2008 Peter V. Saveliev написал(a):
> В сообщении от Monday 04 February 2008 13:52:53 Александр Новосёлов
>
> написал(а):
> > впн сервер, поднятое соединение...
> >
> > клиент пингует мою сторону туннеля
> >
> > как только выполняю команду :
> >
> > tc qdisc add dev ppp0 root tbf rate 1024kbit latency 50ms burst 300k
> >
> > не пингуется, хотя tcpdump показывает входящие icmp запросы
> >
> > tc qdisc del dev ppp0 root решает проблему.
> >
> > тоже самое работает на M2.4
>
> <skip />
>
> Версии ядра/iproute2 на работающем/не работающем решении?


См. соседнее письмо с большими подробностями.

работает - Master 2.4 - 2.4.26-srv-up-alt13.1 (изменения в ядре только на 
число pty 256 -> 2048)

не работает на 2.6.18-std-smp-alt11 ALT Linux 4.0 Server (Walnut)

Re: [Sysadmins] tc + pppd

[Peter V. Saveliev]

В сообщении от Monday 04 February 2008 17:45:53 Александр Новосёлов написал(а):
<skip />
> См. соседнее письмо с большими подробностями.
>
> работает - Master 2.4 - 2.4.26-srv-up-alt13.1 (изменения в ядре только на
> число pty 256 -> 2048)
>
<skip />

Обратите внимание на размеры буфера (запрашиваемые и фактические) в обоих
случаях.

# tc qdisc change dev ppp0 root tbf rate 1024kbit latency 50ms burst 268kb

# tc -s qdisc show dev ppp0
qdisc tbf 8001: rate 1024Kbit burst 268Kb lat 50.0ms
 Sent 2100 bytes 25 pkt (dropped 0, overlimits 142 requeues 0)
 rate 0bit 0pps backlog 0b 22p requeues 0

# tc qdisc change dev ppp0 root tbf rate 1024kbit latency 50ms burst 269kb

# tc -s qdisc show dev ppp0
qdisc tbf 8001: rate 1024Kbit burst 4294692419b lat 54.5ms
 Sent 2100 bytes 25 pkt (dropped 0, overlimits 142 requeues 0)
 rate 0bit 0pps backlog 0b 22p requeues 0

Багофича (при большей скорости больший размер буфера устанавливается).
Сейчас буду смотреть, чья именно.

-- 
Peter V. Saveliev

Re: [Sysadmins] tc + pppd

[Александр Новосёлов]

В сообщении от 4 февраля 2008 Peter V. Saveliev написал(a):

> Багофича (при большей скорости больший размер буфера устанавливается).
> Сейчас буду смотреть, чья именно.

Есть успехи? 

Может у кого есть опыт навешивания шейпа на ppp интерфейсы в впн соединении
Что нового можно сделать в новом ядре? может pppd научился сам шейпить?
Беда с Линуксом... Настроил после выхода Мастера-2.4 впн сервер. И он до 
сих пор работает... пора пыль стряхнуть - ну и заодно систему обновить...

на Мастере 2.4 в /etc/ppp/ip-up.d/vpnshaper 

#!/bin/bash

IFNAME=$1

tc qdisc add dev $IFNAME root tbf rate 800kbit latency 50ms burst 300k

tc qdisc add dev $IFNAME handle ffff: ingress
tc filter add dev $IFNAME parent ffff: protocol ip prio 50 u32 match ip src 
\
   0.0.0.0/0 police rate 512kbit burst 50k drop flowid :1

Re: [Sysadmins] tc + pppd

[Peter V. Saveliev]

В сообщении от Thursday 07 February 2008 10:22:21 Александр Новосёлов 
написал(а):
> В сообщении от 4 февраля 2008 Peter V. Saveliev написал(a):
> > Багофича (при большей скорости больший размер буфера устанавливается).
> > Сейчас буду смотреть, чья именно.
>
> Есть успехи?

нет пока. Это, как видно, фича не tc, значит, надо лезть в ядро; пока не было 
времени. Но как workaround могу предложить пока либо а) сначала проверить 
рабочие параметры tbf (в смысле, эмпирически "подогнать" буфер под скорость) 
либо б) использовать htb.

>
> Может у кого есть опыт навешивания шейпа на ppp интерфейсы в впн соединении
> Что нового можно сделать в новом ядре? может pppd научился сам шейпить?

Он всегда умел. Правда, из мана следует, что если хотите шейпить на любую 
скорость, а не только на "commonly-used baud rate", следует использовать 
*BSD. Насколько верно -- не проверял пока.

<skip />

ЗЫ: вместо полисера можно метить пакеты на прибытии в pppX и затем на внешнем 
интерфейсе раскидывать в классы htb (по классу на клиента, фильтр -- 
хэш-таблицей) -- тогда пакеты будут не дропаться, а буферизоваться.

-- 
Peter V. Saveliev

Re: [Sysadmins] tc + pppd

[Александр Новосёлов]

В сообщении от 7 февраля 2008 Peter V. Saveliev написал(a):

> ЗЫ: вместо полисера можно метить пакеты на прибытии в pppX и затем на
> внешнем интерфейсе раскидывать в классы htb (по классу на клиента,
> фильтр -- хэш-таблицей) -- тогда пакеты будут не дропаться, а
> буферизоваться.


Впн сервер - 1000 пользователей - шейпить надо входящий и исходящий. 

Есть ли примеры указанного с метками  - как будут вести себя классы htb с 
таким числом вариантов - еще на некоторые направдения желательно приоритет 
устроить - а на некоторые - ссделать вообще без шейпа

Re: [Sysadmins] tc + pppd

[Peter V. Saveliev]

В сообщении от Thursday 07 February 2008 11:25:39 Александр Новосёлов 
написал(а):
> В сообщении от 7 февраля 2008 Peter V. Saveliev написал(a):
> > ЗЫ: вместо полисера можно метить пакеты на прибытии в pppX и затем на
> > внешнем интерфейсе раскидывать в классы htb (по классу на клиента,
> > фильтр -- хэш-таблицей) -- тогда пакеты будут не дропаться, а
> > буферизоваться.
>
> Впн сервер - 1000 пользователей - шейпить надо входящий и исходящий.
>
> Есть ли примеры указанного с метками  - как будут вести себя классы htb с
> таким числом вариантов - еще на некоторые направдения желательно приоритет
> устроить - а на некоторые - ссделать вообще без шейпа
<skip />

tbf + полисер в ip-up по любому никаких приоритетов и классов обслуживания 
поддержать не смогут, как ни крути... Можно задавать скорость через атрибуты 
в радиусе, в принципе.

Про 1000 пользователей: я проверял только до 500 пользователей, дальше не было 
желания, так что гарантировать не могу, хотя попробовать можно. В принципе, 
хэш работает быстро, вот и повод проверить его в полевых условиях.

Про приоритеты и т.п. -- htb для этого и делался, чтобы классы обслуживания 
поддерживать. Уж на основе чего они будут, ip или меток и т.п. -- неважно.

Кстати, резалт Вашей работы надо будет запротоколировать как прецедент -- мне 
в одном знакомом месте до сих пор не верят в возможность 1К пользователей VPN 
на линухе, а доказать я им могу только "сферического коня в вакууме", бо 
тест-стенд одно, а реалити иногда другое даёт.

-- 
Peter V. Saveliev