Jump to content
Калькуляторы

Upload при Download,е tc шейпер

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

/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 не могут пробиться. Как порешать данный вопрос, чтобы при почти полной загрузке входящего исходящий был на уровне.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by SokolovS

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Эм.. А можно пример - если я обратный канал через 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";

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Эм.. А можно пример - если я обратный канал через 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-трафика

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Почему? Чем АСК проходящий через ingress отличается от egress??
В случае ingress трафик УЖЕ пришел — его можно либо отбросить, либо принять. А в egress вы сами определяете что пойдет первым и пойдет ли вообще.

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
а мне не надо ;) мои 8 впн серверов и так прекрасно работают.... Есть только одна проблема - максимальная скорость на ppp только 10 мбит... Но это я думаю все таки решу....
Решишь, если перейдешь на accel-pptp. Собирается без пересборки ядра, загружается модуль, а далее стандартно сервер pptp запускается.

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

Edited by SokolovS

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this