a-zazell Posted November 4, 2011 Posted November 4, 2011 Здравствуйте, имеем Linux сервер с NAT, HTB shaping (упрощенная схема во вложении). До недавнего времени на lan интерфейсе все висели в /24 сети и задача динамического шейпинга была банально проста: ... dev="lan" CLIENTS=N MAX=10mbit AVERAGE=`expr ${MAX} / ${CLIENTS}` tc qdisc add dev ${dev} root handle 2 htb default 1 tc class add dev ${dev} parent 2: classid 2:5 htb rate ${MAX}kbit prio 3 #1 User 192.168.1.2 tc class add dev ${dev} parent 2:5 classid 2:50 htb rate ${AVERAGE}kbit ceil ${MAX}kbit tc qdisc add dev ${dev} parent 2:50 sfq tc filter add dev ${dev} parent 2: protocol ip pref 4 u32 match ip dst 192.168.1.2 classid 2:50 ... Но правильнее всех распихать по vlan-ам, и изолировать друг от друга - поставил L2 свитчи, на сервере поднял vlan's. Но дело в том, что tc вешает root на каждый интерфейс, и получается, чтобы разделить например 10Мбит/с на 10 vlan - то надо по 1Мбит/с вешать, иначе 1-ин занимает всю 10ку - остальные курят. А необходимо делить динамически поровну. Это понятно, что надо поставить просто L3 за сервером, терминировать vlan там, дефолт гнать на сервер, но реально пока нет возможности. Может есть у кого идеи или варианты как реализовать задачу динамического деления всей полосы между несколькими vlan в tc?? Спасибо за внимание! Вставить ник Quote
adron2 Posted November 4, 2011 Posted November 4, 2011 Здравствуйте, имеем Linux сервер с NAT, HTB shaping (упрощенная схема во вложении). До недавнего времени на lan интерфейсе все висели в /24 сети и задача динамического шейпинга была банально проста: ... dev="lan" CLIENTS=N MAX=10mbit AVERAGE=`expr ${MAX} / ${CLIENTS}` tc qdisc add dev ${dev} root handle 2 htb default 1 tc class add dev ${dev} parent 2: classid 2:5 htb rate ${MAX}kbit prio 3 #1 User 192.168.1.2 tc class add dev ${dev} parent 2:5 classid 2:50 htb rate ${AVERAGE}kbit ceil ${MAX}kbit tc qdisc add dev ${dev} parent 2:50 sfq tc filter add dev ${dev} parent 2: protocol ip pref 4 u32 match ip dst 192.168.1.2 classid 2:50 ... Но правильнее всех распихать по vlan-ам, и изолировать друг от друга - поставил L2 свитчи, на сервере поднял vlan's. Но дело в том, что tc вешает root на каждый интерфейс, и получается, чтобы разделить например 10Мбит/с на 10 vlan - то надо по 1Мбит/с вешать, иначе 1-ин занимает всю 10ку - остальные курят. А необходимо делить динамически поровну. Это понятно, что надо поставить просто L3 за сервером, терминировать vlan там, дефолт гнать на сервер, но реально пока нет возможности. Может есть у кого идеи или варианты как реализовать задачу динамического деления всей полосы между несколькими vlan в tc?? Спасибо за внимание! у линукса есть одна замечательная штука. А именно. Если все вланы подняты на одном интерфейсе. Скажем eth0. То достаточно повесить root htb и его потомков на eth0 и фильтрами или iptables-ом загонять траффик в нужные классы. и он будет туда попадать и нормально шейпиться ! Вставить ник Quote
a-zazell Posted November 4, 2011 Author Posted November 4, 2011 у линукса есть одна замечательная штука. А именно. Если все вланы подняты на одном интерфейсе. Скажем eth0. То достаточно повесить root htb и его потомков на eth0 и фильтрами или iptables-ом загонять траффик в нужные классы. и он будет туда попадать и нормально шейпиться ! Хм, дык пробовал, вешал на lan root и резал в 1Мбит, ничего не изменилось. Правда классы с других интерфейсов не снимал - ща попробуем, спасибо Вставить ник Quote
GFORGX Posted November 4, 2011 Posted November 4, 2011 Как вариант (плюс так изящнее), можете шейпить не на сервере, терминирующем 1Q, а на соседнем роутере, там у Вас будет один интерфейс, на который Вы сможете повешать htb. Вставить ник Quote
adron2 Posted November 4, 2011 Posted November 4, 2011 у линукса есть одна замечательная штука. А именно. Если все вланы подняты на одном интерфейсе. Скажем eth0. То достаточно повесить root htb и его потомков на eth0 и фильтрами или iptables-ом загонять траффик в нужные классы. и он будет туда попадать и нормально шейпиться ! Хм, дык пробовал, вешал на lan root и резал в 1Мбит, ничего не изменилось. Правда классы с других интерфейсов не снимал - ща попробуем, спасибо У меня так работает. Ядро 2.6.35.14. Трафик заворачивается в классы через iptables. Вставить ник Quote
a-zazell Posted November 4, 2011 Author Posted November 4, 2011 У меня так работает. Ядро 2.6.35.14. Трафик заворачивается в классы через iptables. Понял, я не заворачиваю, и смотрю что на lan все в default льется. Хотя, если даже все льется в дефаулт, то по идее, достаточно этот класс настроить на деление dst per /32 ?? Вставить ник Quote
adron2 Posted November 4, 2011 Posted November 4, 2011 У меня так работает. Ядро 2.6.35.14. Трафик заворачивается в классы через iptables. Понял, я не заворачиваю, и смотрю что на lan все в default льется. Хотя, если даже все льется в дефаулт, то по идее, достаточно этот класс настроить на деление dst per /32 ?? filter ставится на eth0 например так: tc filter add dev eth0 protocol ip parent 1: prio 6 u32 match ip dst 1.2.3.0/20 flowid 1:253 И тоже все попадает в нужный класс. Хотя 1.2.3.0/20 живет в eth0.1234 влане. Вставить ник Quote
a-zazell Posted November 4, 2011 Author Posted November 4, 2011 курите в сторону ifb или imq Что-то мне подсказывает, что действительно надо смотреть в эту сторону ... Пока вот почитываю Вставить ник Quote
Alex/AT Posted November 4, 2011 Posted November 4, 2011 Загоняйте нужный трафик на IFB и шейпьте. Наиболее дешевый по времязатратам вариант. По ресурсам CPU тоже крайне неплох. Вставить ник Quote
a-zazell Posted November 4, 2011 Author Posted November 4, 2011 Клева ... Добавил в /etc/modules ifb, сделал init 6 - и сервак больше не доступен. Впереди веселые выходные ... Вставить ник Quote
a-zazell Posted November 5, 2011 Author Posted November 5, 2011 Клева ... Добавил в /etc/modules ifb, сделал init 6 - и сервак больше не доступен. Впереди веселые выходные ... (up) Итак продолжим, чего-то там завис на loading kernel ... Вставить ник Quote
a-zazell Posted November 5, 2011 Author Posted November 5, 2011 Загоняйте нужный трафик на IFB и шейпьте. Наиболее дешевый по времязатратам вариант. По ресурсам CPU тоже крайне неплох. Вот нашел кучу примеров, по типу /sbin/tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 Как я понял - используется для шейпинга исходящего от абонентов траффа, и видимо надо так прописывать для каждого vlan'a в моем случае. Вот что-то не догоню, а как перенаправить трафф К абонентам на ifb?? Как я понял - используется для шейпинга исходящего от абонентов траффа, и видимо надо так прописывать для каждого vlan'a в моем случае. Вот что-то не догоню, а как перенаправить трафф К абонентам на ifb?? О, может что-то вроде повесить: #tc qdisc add dev wan ingress #tc filter add dev wan parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 О, может что-то вроде повесить: #tc qdisc add dev wan ingress #tc filter add dev wan parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 Не, не катит - по tcpdump внутренних адресов на ifb0 не бегает - nat... Вставить ник Quote
kayot Posted November 6, 2011 Posted November 6, 2011 IFB с натом и не не работает, если хочется курить - курите в сторону IMQ :) Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.