[SokolovS]

Правила шейпинга на каждого юзера примерно такие:

/sbin/tc class replace dev eth0 parent 1:2 classid 1:911 htb rate 800kbit ceil 800kbit prio 2 
/sbin/tc class replace dev eth1 parent 1:2 classid 1:911 htb rate 800kbit ceil 800kbit prio 2 
/sbin/tc qdisc replace dev eth0 parent 1:911 handle 911 sfq                                   
/sbin/tc qdisc replace dev eth1 parent 1:911 handle 911 sfq                                   
/sbin/tc filter replace dev eth0 protocol ip parent 1:0 prio 100 u32 ht 14:b6: match ip dst <USER_IP> classid 1:911
/sbin/tc filter replace dev eth1 protocol ip parent 1:0 prio 100 u32 ht 14:b6: match ip src <USER_IP> classid 1:911

 

Т.е. вешается симметричный шейпер на оба интерфейса.

Вопрос такой. При полной загрузке входящего канала абонента, т.е. на 800 Кбит, исходящий резко падает. Если я правильно понимаю проблему, то входящие ACK не могут пробиться. Как порешать данный вопрос, чтобы при почти полной загрузке входящего исходящий был на уровне.

[Jugernault]

1:911 дробить на два класса с разными приоритетами.

в класс с высшим приоритетом пихать трафик по фильтру

u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33

все остальное прихать в класс с низшим приоритетом.

[SokolovS]

Если не дробить а выделить ACK вобще в отдельынй класс глобально дял всех юзеров с высоким приоритетом?

Изменено 16 марта, 2009 пользователем SokolovS

[Jugernault]

Если не дробить а выделить ACK вобще в отдельынй класс глобально дял всех юзеров с высоким приоритетом?

Нууу... По сути это дело вкуса - главное выделить и приоритета навалить, а куда - это уже опционально...

[martin74]

Эм.. А можно пример - если я обратный канал через ingress шейплю (ну или полисю, не суть важно) - в этом случае можно ACK выделить?

system "/sbin/tc qdisc add dev $interface handle ffff: ingress";
system "/sbin/tc filter add dev $interface parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate $speedout[$wday][$hour]kbit burst $burst";

 

[Max P]

+1, тоже интересен такой вопрос

[DemYaN]

Эм.. А можно пример - если я обратный канал через ingress шейплю (ну или полисю, не суть важно) - в этом случае можно ACK выделить?

system "/sbin/tc qdisc add dev $interface handle ffff: ingress";
system "/sbin/tc filter add dev $interface parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate $speedout[$wday][$hour]kbit burst $burst";

выделение приоритета для ack-ов актуально только для egress-трафика

[martin74]

Почему? Чем АСК проходящий через ingress отличается от egress??

[m_medved]

Почему? Чем АСК проходящий через ingress отличается от egress??

В случае ingress трафик УЖЕ пришел — его можно либо отбросить, либо принять. А в egress вы сами определяете что пойдет первым и пойдет ли вообще.

Как вариант — шейпите другую сторону канала на другом интерфейсе, куда он уходит

[martin74]

сейчас у меня на ВПН сервере грубо говоря 400-500 ppp интерфейсов, на каждом из которых свой шейпер. На два правила на egress (выделение ACK в отдельный приоритет) и ingress... И у меня нет проблемы с оптимизацией правил шейпера. Если же я буду вешать клиентский шейпер на сетевую... Мало того, что нат выполняется тут же, еще и оптимизировать правила шейпера на сетевой....

Лучше я оставлю так, как есть.

А есть сейчас так - трафик к абоненту шейпится с высокой точностью - на заявленном мегабите 1.1 максимум получается... А от абонента - пила. От 300 до 800 кбит... Собсно думаю, как эту пилу улучшить....

[m_medved]

оптимизировать правила шейпера на сетевой?

возьмите программиста, пиво и вечер, тщательно перемешайте :)

[martin74]

а мне не надо ;) мои 8 впн серверов и так прекрасно работают.... Есть только одна проблема - максимальная скорость на ppp только 10 мбит... Но это я думаю все таки решу....

[SokolovS]

а мне не надо ;) мои 8 впн серверов и так прекрасно работают.... Есть только одна проблема - максимальная скорость на ppp только 10 мбит... Но это я думаю все таки решу....

Решишь, если перейдешь на accel-pptp. Собирается без пересборки ядра, загружается модуль, а далее стандартно сервер pptp запускается.

А минус в твоем случае в том, что вешая шейпер на каждый юзерский интерфейс, ты лишаешься возможностей QoS, фактически просто шейпинг.

Изменено 17 марта, 2009 пользователем SokolovS

[martin74]

А нужен ли QoS ?

[SokolovS]

На брасах не нужен, если где то дальше есть возможность делать QoS. Что у вас будет если какой то юрик подключенный через VLAN и есно мимо браса, вдруг сильно загрузит канал?

[Jugernault]

а мне не надо ;) мои 8 впн серверов и так прекрасно работают.... Есть только одна проблема - максимальная скорость на ppp только 10 мбит... Но это я думаю все таки решу....

Именно ppp или все же pptp? А как дела с pppoe обстоят?

[martin74]

Ну так юрики - они как бы по другому пути ходят. И на бордере я QoS и делаю...

pptp родимый, pppoe не использую - локалка бесплатная, и des-3828 не умеет pppoe relay ;)

[SokolovS]

2Jugernault: ppp в обмене трафиком не участвует. Скорее всего имелся ввиду ppp интерфейс на pptp сервере.

 

Ну так юрики - они как бы по другому пути ходят. И на бордере я QoS и делаю...

pptp родимый, pppoe не использую - локалка бесплатная, и des-3828 не умеет pppoe relay ;)

Ну вот пример того где нужен QoS для абонентов. У меня например есть возможность выставлять приоритет трафика на тарифах :)

[martin74]

у меня тоже есть... маркирую необходимый трафик в dscp и на бордере уже по очередям....