nuclearcat Опубликовано 27 февраля, 2009 · Жалоба А я о чем? Технически ВОЗМОЖНО, но идеологически нельзя. По поводу другой проблемы - лучше так не делать. Это просто игра в рулетку, если что-то делается "не по идеологии". Хотя можно попытаться обьяснить ситуацию в netdev@ или lartc - там может чего подскажут, или сделают Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 февраля, 2009 (изменено) · Жалоба 2nuclearcat: Все правильно Вы говорите, я же не спорю, просто Вы написали, что точно не знаете, т.к. не проверяли, я отписался, т.к. проверял. Делать так не надо, по одной причине: зачем? Насчет другой проблемы: я прочел много статей и постов по этому вопросу + были проведены успешные эксперименты, поэтому до netdev и lartc дело не дошло. Тем более, по первокоренным докам было понятно, что промежуточные агрегативные классы могут быть без очереди, отдавая таким образом пакеты напрямую в рутовую очередь qdisc. Обрезка скорости пакетов будет происходить при этом в этом промежуточном классе, а пакеты не пролезшие в классе будут оставаться в очередях лиф классов. Так что они теряться не будут, скорость дергаться не будет. И это реально работает. Хотя, я бы, конечно, все же сделал для промежуточного класса очередь, т.к. тогда было бы очевиднее, что происходит с пакетами которые не может пропустить класс. Сейчас тот факт, что они остаются в чужих очередях пришлось выискивать и это не является очевидным. Изменено 27 февраля, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 1 марта, 2009 · Жалоба Насчет фильтров - у меня в свое время была потребность в извращенном шейпере инет/анлим/пиринг. Так вот там мне была нужна иерархическая структура фильтров с переклассификацией отдельных видов трафика по мере движения по очередям. Пришлось делать через iptables mark.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fedusia Опубликовано 3 марта, 2009 · Жалоба Nic, у меня сейчас аналогичная ситуация, необходимо разделить инет\пиринг\анлим. Аналогичным образом делаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadimus Опубликовано 3 марта, 2009 · Жалоба У меня тоже инет и огромный пиринг, так как я пиринговые маршруты получаю по BGP, я с помощью quagga помечаю их realm'ом и фильтрую уже по нему. Мне кажется, так проще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 3 марта, 2009 · Жалоба Господа, уже давно есть таргет CLASSIFY у iptables, что упрощает построение фильтров и уменьшает количество объектов в системе. А если вообщем по сути, то если у Вас на все виды трафика один исходящий интерфейс ( а обычно так и есть, не будете же Вы клиенту Вланами отдавать мир, пиринг ), то другого способа шейпить, я лично пока не знаю, только через iptables из-за гибкости правил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fedusia Опубликовано 3 марта, 2009 · Жалоба Есть идея поставить еще 1 сетевую карту отдельно под пиринг, тогда шейпер должен сильно разгрузиться. eth0 - локальная сеть eth1 - инет eth2 - пиринг. Кто что думает об этой идее? Имеет ли смысл? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 3 марта, 2009 · Жалоба У меня тоже инет и огромный пиринг, так как я пиринговые маршруты получаю по BGP, я с помощью quagga помечаю их realm'ом и фильтрую уже по нему. Мне кажется, так проще. опа, а вот тут поподробнее можно? буду очень благодарен за ссылку на доку/пример Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yun Опубликовано 3 марта, 2009 · Жалоба Странно, у меня была схема когда к корневой дисциплине цеплялись классы а потом к этим промежуточным классам конечные классы. Сначало фильтровлось фильтрами, прицепленными к корневой дисциплине а потом другими фильтрами раскидывалось по конечным классам. Или я не так понял? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 марта, 2009 · Жалоба yun - мы о другом кажется. У тебя flowid в конце фильтра всегда смотрел на leaf класс? (конечный, с qdisc) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yun Опубликовано 3 марта, 2009 · Жалоба Корневая дисциплина и промежуточные классы: ${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 верно чтоб фильтры можно было делать не только плоской областью (все в одном горизонтальном уровне), но и разбивать на более крупные блоки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fedusia Опубликовано 4 марта, 2009 · Жалоба Vadimus, я бы тоже хотел примерчик реализации вашей схемы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadimus Опубликовано 4 марта, 2009 (изменено) · Жалоба Так указываем 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 4 марта, 2009 · Жалоба мда. аж прослезился. оказывается, все гениальное просто... vadimus, огромное спасибо за пример. буду реализовывать в ближайшее время Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fedusia Опубликовано 5 марта, 2009 · Жалоба Да только тут есть некоторые вопросы, что делать если есть пиринговые сети не работающие по бгп? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SSTS Опубликовано 5 марта, 2009 · Жалоба Да только тут есть некоторые вопросы, что делать если есть пиринговые сети не работающие по бгп? для таких сетей realm можно указать ручками с помощью утилитки ip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadimus Опубликовано 8 марта, 2009 · Жалоба мда. аж прослезился. оказывается, все гениальное просто...vadimus, огромное спасибо за пример. буду реализовывать в ближайшее время Да не за что, рад поделиться опытом -:) А насчет указания realm - еще вроде можно прописать статические маршруты с указанием realm в /etc/quagga/zebra.conf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 14 марта, 2009 · Жалоба Мда, как выяснилось, реалмы quagga поддерживает только после наложения соответствующего патча... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadimus Опубликовано 15 марта, 2009 · Жалоба Да, точно, есть такое дело. Просто в gentoo он накладывается автоматически при указании соответсвующего USE-флага, я и забыл. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 15 марта, 2009 · Жалоба vadimus, а версия квагги какая у вас стоит? А то мне боязно на боевом сервере экспериментировать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vadimus Опубликовано 16 марта, 2009 · Жалоба У меня стоит 0.98.6 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...