[nuclearcat]

А я о чем? Технически ВОЗМОЖНО, но идеологически нельзя.

По поводу другой проблемы - лучше так не делать. Это просто игра в рулетку, если что-то делается "не по идеологии". Хотя можно попытаться обьяснить ситуацию в netdev@ или lartc - там может чего подскажут, или сделают

[Dark_Angel]

2nuclearcat: Все правильно Вы говорите, я же не спорю, просто Вы написали, что точно не знаете, т.к. не проверяли, я отписался, т.к. проверял. Делать так не надо, по одной причине: зачем?

 

Насчет другой проблемы: я прочел много статей и постов по этому вопросу + были проведены успешные эксперименты, поэтому до netdev и lartc дело не дошло. Тем более, по первокоренным докам было понятно, что промежуточные агрегативные классы могут быть без очереди, отдавая таким образом пакеты напрямую в рутовую очередь qdisc. Обрезка скорости пакетов будет происходить при этом в этом промежуточном классе, а пакеты не пролезшие в классе будут оставаться в очередях лиф классов. Так что они теряться не будут, скорость дергаться не будет. И это реально работает.

 

Хотя, я бы, конечно, все же сделал для промежуточного класса очередь, т.к. тогда было бы очевиднее, что происходит с пакетами которые не может пропустить класс. Сейчас тот факт, что они остаются в чужих очередях пришлось выискивать и это не является очевидным.

Изменено 27 февраля, 2009 пользователем Dark_Angel

[Nic]

Насчет фильтров - у меня в свое время была потребность в извращенном шейпере инет/анлим/пиринг. Так вот там мне была нужна иерархическая структура фильтров с переклассификацией отдельных видов трафика по мере движения по очередям. Пришлось делать через iptables mark..

[fedusia]

Nic, у меня сейчас аналогичная ситуация, необходимо разделить инет\пиринг\анлим. Аналогичным образом делаю.

[vadimus]

У меня тоже инет и огромный пиринг, так как я пиринговые маршруты получаю по BGP, я с помощью quagga помечаю их realm'ом и фильтрую уже по нему. Мне кажется, так проще.

[Dark_Angel]

Господа, уже давно есть таргет CLASSIFY у iptables, что упрощает построение фильтров и уменьшает количество объектов в системе.

 

А если вообщем по сути, то если у Вас на все виды трафика один исходящий интерфейс ( а обычно так и есть, не будете же Вы клиенту Вланами отдавать мир, пиринг ), то другого способа шейпить, я лично пока не знаю, только через iptables из-за гибкости правил.

[fedusia]

Есть идея поставить еще 1 сетевую карту отдельно под пиринг, тогда шейпер должен сильно разгрузиться.

eth0 - локальная сеть

eth1 - инет

eth2 - пиринг.

Кто что думает об этой идее? Имеет ли смысл?

[Nic]

У меня тоже инет и огромный пиринг, так как я пиринговые маршруты получаю по BGP, я с помощью quagga помечаю их realm'ом и фильтрую уже по нему. Мне кажется, так проще.

опа, а вот тут поподробнее можно? буду очень благодарен за ссылку на доку/пример

[yun]

Странно, у меня была схема когда к корневой дисциплине цеплялись классы а потом к этим промежуточным классам конечные классы.

Сначало фильтровлось фильтрами, прицепленными к корневой дисциплине а потом другими фильтрами раскидывалось по конечным классам.

Или я не так понял?

[nuclearcat]

yun - мы о другом кажется.

У тебя flowid в конце фильтра всегда смотрел на leaf класс? (конечный, с qdisc)

[yun]

Корневая дисциплина и промежуточные классы:

${ADD_QD} root handle 1:0 htb default 90
${ADD_CL} parent 1:0 classid 1:1 htb rate ${TOTAL_RATE}
${ADD_CL} parent 1:1 classid 1:10 htb rate ${VIDEO_RATE} ceil ${TOTAL_RATE} prio 0
${ADD_CL} parent 1:1 classid 1:60 htb rate ${INET_RATE} ceil ${TOTAL_RATE} prio 5

 

Фильтры к промежуточным классам

#filters
#multicast and video
${ADD_FT} parent 1:0 protocol ip prio 10 u32 match ip dst 234.0.0.0/8 flowid 1:10
#BIR
#ToS 0x0
${ADD_FT} parent 1:0 protocol ip prio 60 u32 flowid 1:60 \
    match ip tos 0x00 0x0f \
    match ip dst 192.168.0.0/16
#ToS 0x2
${ADD_FT} parent 1:0 protocol ip prio 61 u32 flowid 1:60 \
    match ip tos 0x02 0x0f \
    match ip dst 192.168.0.0/16.
.
.
.

 

Конечные классы:

${ADD_CL} parent 1:60 classid 1:${ID} htb rate ${RATE}bit ceil ${RATE}kbit
.
.
.

 

Фильтры:

${ADD_FT} parent 1:60 protocol ip prio 100 handle 2: u32 divisor 256
${ADD_FT} parent 1:60 protocol ip prio 100 u32 ht 2:${IP3}: match ip dst ${IP} flowid 1:${ID}
.
.
.
${ADD_FT} parent 1:60 protocol ip prio 100 u32 link 2: match ip dst ${NET}.0.0/16 hashkey mask 0x0000ff00 at 16

 

Так что получается что смотрит не только на конечные. Вобщем-то идеологически imho верно чтоб фильтры можно было делать не только плоской областью (все в одном горизонтальном уровне), но и разбивать на более крупные блоки.

[fedusia]

Vadimus, я бы тоже хотел примерчик реализации вашей схемы.

[vadimus]

Так указываем REALM для приходящих по BGP маршрутов

cat /etc/quagga/bgpd.conf

hostname bgpd
password *
router bgp *
bgp router-id *
network *
network *
!
neighbor * remote-as *
neighbor * route-map SETREALM in
neighbor * filter-list 1 out
!
no auto-summary
no synchronization
log file /var/log/quagga/bgpd.log
!
route-map SETREALM permit 10
set realm 10 (указываем REALM)
match ip address 2
!
ip as-path access-list 1 permit ^$
access-list 2 deny 192.168.0.0 0.0.255.255

 

Указываем REALM для пакета iproute2

cat /etc/iproute2/rt_realms

10    piring

 

А так ставим фильтр:

 

/sbin/tc filter add dev eth0 parent 1: protocol ip prio 1 route from 10 flowid 1:20;

Изменено 4 марта, 2009 пользователем vadimus

[Nic]

мда. аж прослезился. оказывается, все гениальное просто...

vadimus, огромное спасибо за пример. буду реализовывать в ближайшее время

[fedusia]

Да только тут есть некоторые вопросы, что делать если есть пиринговые сети не работающие по бгп?

[SSTS]

Да только тут есть некоторые вопросы, что делать если есть пиринговые сети не работающие по бгп?

для таких сетей realm можно указать ручками с помощью утилитки ip

[vadimus]

мда. аж прослезился. оказывается, все гениальное просто...

vadimus, огромное спасибо за пример. буду реализовывать в ближайшее время

Да не за что, рад поделиться опытом -:) А насчет указания realm - еще вроде можно прописать статические маршруты с указанием realm в /etc/quagga/zebra.conf

[Nic]

Мда, как выяснилось, реалмы quagga поддерживает только после наложения соответствующего патча...

[vadimus]

Да, точно, есть такое дело. Просто в gentoo он накладывается автоматически при указании соответсвующего USE-флага, я и забыл.

[Nic]

vadimus, а версия квагги какая у вас стоит? А то мне боязно на боевом сервере экспериментировать...

[vadimus]

У меня стоит 0.98.6