Считается что IFB идеологически более правильная реализация псевдо-устройства, чем IMQ.
IFB по умолчанию доступна в дистре Fedora Core 6.
IMQ требует патчить ядро, по умолчанию не доступна.Насколько я понял идеологически
IFB - это скорее для iproute2
IMQ - iptablesДокументация по IFB в исходниках iproute doc/actions/
или по адресу: http://linux-net.osdl.org/index.php?title=IFBОтличные картинки с местоположением IMQ:
http://www.abclinuxu.cz/clanky/site/traffic-shaping-2-imq-a-...
# СБРОС ПРАВИЛ -----------------------------
tc qdisc del dev eth0 root
tc qdisc del dev eth0 ingresstc qdisc del dev ifb0 root
tc qdisc del dev ifb0 ingressmodprobe ifb
ip link set dev ifb0 upservice iptables restart
# ------------------------------------------# IFB включение ----------------------------
modprobe ifb
ip link set dev ifb0 up
# ------------------------------------------## ПОЛЕЗНЫЕ КОМАНДЫ-------------------------
tc -s filter show parent ffff: dev eth0
tc -s qdisc
ifconfig ifb0
tc -s filter show dev ifb0 parent 1:
tc -s qdisc show dev ifb0
######################################################
# ПРИМЕР ограничения входящего трафика
# маркировка IPTABLES недоступна
######################################################### IFB --------------------------------------------------------------
tc qdisc add dev ifb0 root handle 1: priotc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 80kbit buffer 1600 limit 3000
tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 160kbit buffer 1600 limit 3000## выделили закачку исходников ядра
## wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz
tc filter add dev ifb0 parent 1: protocol ip prio 1 u32 match ip src 204.152.191.37/32 flowid 1:1## выделили закачку исходников fedora core 6
## wget ftp://ftp.muug.mb.ca/pub/fedora/linux/core/6/i386/iso/FC-6-i...
tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip src 130.179.31.46/32 flowid 1:2
### eth0 --------------------------------------------------------------
# перенаправлять входящие пакеты с eth0 в ifb0
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip \
u32 match u32 0 0 action mirred egress redirect dev ifb0## TESTING -------------------------------------------------------------
оцените скорость и т.д.
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.6.tar.gz######################################################
# ПРИМЕР ограничения исходящего трафика
# маркировка IPTABLES доступна но
# filter работает на уровне iproute2 match ip dst
######################################################Выполните СБРОС ПРАВИЛ и включите IFB (если выкл.)
### IFB --------------------------------------------------------------
tc qdisc add dev ifb0 root handle 1: prio
tc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 80kbit buffer 1600 limit 3000
tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 160kbit buffer 1600 limit 3000# закачка большого файла с хх.хх.хх.хх
tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip dst хх.хх.хх.хх/32 flowid 1:2### eth0 --------------------------------------------------------------
# перенаправлять выходящие пакеты с eth0 в ifb0
tc qdisc add dev eth0 root handle 2: prio
tc filter add dev eth0 parent 2: protocol ip \
u32 match u32 0 0 action mirred egress redirect dev ifb0## TESTING -------------------------------------------------------------
закачивайте большой файла на хх.хх.хх.хх оцените скорость и т.д.
tc -s filter show parent ffff: dev eth0
tc -s qdisc
ifconfig ifb0
tc -s filter show dev ifb0 parent 1:
tc -s qdisc show dev ifb0######################################################
# ПРИМЕР ограничения исходящего трафика
# маркировка IPTABLES доступна
# filter работает на уровне маркировке пакетов в IPTABLES
######################################################Выполните СБРОС ПРАВИЛ и включите IFB (если выкл.)
### IFB --------------------------------------------------------------
tc qdisc add dev ifb0 root handle 1: priotc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 80kbit buffer 1600 limit 3000
tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 160kbit buffer 1600 limit 3000tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:1
tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:2### eth0 --------------------------------------------------------------
# перенаправлять выходящие пакеты с eth0 в ifb0
tc qdisc add dev eth0 root handle 2: prio
tc filter add dev eth0 parent 2: protocol ip \
u32 match u32 0 0 action mirred egress redirect dev ifb0tc qdisc add dev eth0 root handle 2: prio
tc filter add dev eth0 parent 2: protocol ip \
u32 match u32 0 0 action mirred egress redirect dev ifb0# поставить в IPTABLES метку
iptables -t mangle -A OUTPUT -p tcp -d 85.254.228.6/32 -j MARK --set-mark 10## TESTING -------------------------------------------------------------
закачивайте большой файла на хх.хх.хх.хх оцените скорость и т.д.
URL:
Обсуждается: http://www.opennet.me/tips/info/1421.shtml
Все отлично, вот только баги в этом IFB еще ловить и ловить. Использовал раньше IMQ для объединения нескольких ppp-интерфейсов для наложения единого qdisc. И вот недавно решил (тоже по идеологическим соображениям) попробовать IFB. Использовал Debian Etch со стандартным ядром 2.6.18-4-686. На тестовой машине проблем не замечено, поэтому решил испытать в реальных условиях. Три дня все отлично работало, а потом все "упало" - kernel panic.
В итоге выпады в kernel panic появлялись регулярно раз в два-три дня. Возможно это баг, исправленный в 2.6.21 - [IFB]: Fix crash on input device removal, но точно не уверен.
А я как раз по тихоньку двигаюсь к тому чтобы не было подмены IP-MAC установить poptop, в этом случае возникает множество ppp+поэтому вначале думал использовать IMQ,
но когда прочел вот эту заметку
http://www.linux.org.ru/view-message.jsp?msgid=1415173подумал надо использовать IFB, ведь в новом ESFQ появились интересные возможности, связанные с равномерным распредлением выходящего трафика в интернет при использование gateway + NAT. Что по сути своей как мне кажется избавляет от необходимости imq.
hash ctorigdst, ctorigsrc, ctrepldst, ctreplsrc:
http://fatooh.org/esfq-2.6/current/READMEИнтересная получается ситуация....
У в вашем случае IMQ c ppp+ от poptop стабильно работает?
ядро 2.6.16 патченное esqf/imq прекрасно работает. Процитированный вами пост на linux.org.ru был мой. В той ситуации проблема была в этом http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/ImqFaq#How_stable_.... Другими словами - в IMQ устройство нельзя заворачивать локально (на vpn сервере) рожденный траффик. В скрипте заворачивающем траффик с ppp+ на imq это должно быть обязательно учтено. У меня это сделано прописыванием в ip-up.local
iptables -t mangle -A POSTROUTING -o $IFNAME -s ! 192.168.20.0/24 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -i $IFNAME -j IMQ --todev 1
где imq0 используется для исходящего траффика и imq1 для входящего и 192.168.20.0/24 это vpn сеть. Ну и билинг использую cake. Юзеров больше 100. Месячный об'ем траффика проходящего через vpn сервер >50Gb. Проблемы отсутствуют.
P.S. не забыть в ip-down.local прописать
iptables -t mangle -D POSTROUTING -o $IFNAME -s ! 192.168.20.0/24 -j IMQ --todev 0
iptables -t mangle -D PREROUTING -i $IFNAME -j IMQ --todev 1
Я пока остановился на IFB, сейчас в стадии тестирования и проблем пока нету.Попробовал и IMQ, но не учел описанную Вами особенность, спасибо за разъяснение проблемы,
поскольку наверняка бы наступил на описанные Вами грабли.
>Я пока остановился на IFB, сейчас в стадии тестирования и проблем пока
>нету.
>
>Попробовал и IMQ, но не учел описанную Вами особенность, спасибо за разъяснение
>проблемы,
>поскольку наверняка бы наступил на описанные Вами грабли.
А какие адреса вы раздаете клиентам с vpn сервера? "Левые" или реальные?
После VPN делаю НАТ
10.10.10.ХХ-->192.168.0.X-->NAT-->xx.xx.xx.GW
>После VPN делаю НАТ
>10.10.10.ХХ-->192.168.0.X-->NAT-->xx.xx.xx.GWа шейпер используете?
конечно использую!ifb0 -- для трафика идущего в локалку
eth0 -- для трафика идущего в интернетДумаю скоро выложить свой шейпер на www.dzti.edu.lv/isp-serv
пока там старый пример лежит, в нем есть большой недостаток
заключающийся в исопльзование geoip, Layer 7
с geoip насколько я понял проблемы с прикруткойLayer 7 тормозит при серфинге, время определения типа трафика для http у него от 3сек до 30сек.
На данный момент у меня тестируется следующая схема шейпера
http://www.tmf.rtu.lv/isp/tc-eth0.png
http://www.tmf.rtu.lv/isp/tc-ifb0.png
Простите что не в тему: каким пакетом генерируете .png схемы TC по указанным адресам? Спасибо!
Не могли бы вы описать, как завернуть трафик c ppp на ifb0? Никак не могу настроить так чтобы локальный трафик не ограничивался шейпером. Зарание спасибо.
ppp+ в ifb перенаправлял вот так:
tc filter add dev $DEV parent 1: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0вот часть трейса от kernel panic:
[<>] ri_tasklet+0xc1/0x19f [ifb]
[<>] tasklet_action+0x55/oxaf
[<>] __do_sofirq+0x5a/oxbb
[<>] do_softirq+0x36/0x3a
[<>] apic_timer_interrupt+0x1f/0x
[<>] mwait_idle+0x25/0x38
[<>] cpu_idle+0x9f/0xb9
[<>] start_kernel+0x379/0x380IMQ и 30-100 ppp соединений работает отлично
вот есть еще http://people.redhat.com/mingo/realtime-preempt/older/patch-... - набор патчей для realtime-preempt, среди которых есть патч для IFB:Index: linux/drivers/net/ifb.c
===================================================================
--- linux.orig/drivers/net/ifb.c
+++ linux/drivers/net/ifb.c
@@ -96,17 +96,24 @@ static void ri_tasklet(unsigned long dev
skb->tc_verd = SET_TC_NCLS(skb->tc_verd);
stats->tx_packets++;
stats->tx_bytes +=skb->len;
+
+ skb->dev = __dev_get_by_index(skb->iif);
+ if (!skb->dev) {
+ dev_kfree_skb(skb);
+ stats->tx_dropped++;
+ break;и тд
У меня линуксовое ядро (2.6.18) недавно тоже с той же периодичностью что и у вас падало, но первые где то 3 мес. стабильно работало.
Для сборки ядра использовал скрипт:
http://www.tmf.rtu.lv/isp/ISP-compile-2.6.18.1.sh
Конфиг ядра:
http://www.tmf.rtu.lv/isp/ISP.configКак ни странно у меня так, компилируешь новое ядро с патчами, потом от трех месяцев до полугода нормально работает а потом снова начинает падать.
При этом не использовал в скриптах IMQ, IFB.
Ставишь новое ядро, проблему уходят.А вот там где сервер НАТ (2.6.9-1.667) работает не под большой нагрузкой и без патчей типа ESFQ и т.п., так работает стабильно уже наверно года два.
Иногда мне кажется что падение старого ядра это результат атаки, использующей дырки в ядре.
В 2.6.20 пофикшено, сам принимал участие в отладке.
>В 2.6.20 пофикшено, сам принимал участие в отладке.а что имменно пофикшено? работа с ifb или imq?
Ничего там не профикшено ни ifb, ни imq. Виснет как и висло и в .20, и в .21, и в .22, и в .23 ядрах.
IMQ у меня работает на 22, 23. Около 300 одновременных сессий, smp система. Анатолий, почему у меня не глючит, а у Вас виснет? Вы пробовали написать в список рассылки IMQ о проблеме? Хм. Знаю, ибо я туда подписан, не пробовали. Куда проще здесь кричать, что ничего не работает...
Kernel-2.6.24, iptables-1.4.0, iproute2-ss071016. IFB работает, но конструкция с маркировкой при помощи iptables (последний пример) - НЕТ. То есть команды выполняются без ошибок, но трафик по классам в итоге не разбивается. А фильтры в iptables не в пример tc'шным удобнее. ОЧЕНЬ буду благодарен за помощь в решениии этой проблемы.
Кстати, в Shorewall-4.1.6 включена поддержка настройки IFB устройств. Очень рекоммендую.
В статье очень много ошибок и недочетов, по видимому коряво переведено. Статья не дает ответов, а только добавляет вопросов.
Подскажите пжста как перенаправить траффик с eth0 на ifb0. у меня TCPdump молчит при прослушке ifb0,
хотя дословно делаю как написано
У меня ядро 2.6.24-1-686-bigmem #1 SMP.
Debian unstable.
Работает такое:modprobe ifb
ifconfig ifb0 up
tc qdisc add dev eth0 root handle 2: prio
tc filter add dev eth0 parent 2: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0
>У меня ядро 2.6.24-1-686-bigmem #1 SMP.
>Debian unstable.
>Работает такое:
>
>modprobe ifb
>ifconfig ifb0 up
>tc qdisc add dev eth0 root handle 2: prio
>tc filter add dev eth0 parent 2: protocol ip u32 match u32
>0 0 action mirred egress redirect dev ifb0У меня начинается перенаправление трафика только после того, как в filter будет добавлено указание flowid:
# tc qdisc add dev ppp1 root handle 2: prio
# tc filter add dev ppp1 parent 2: protocol ip u32 match u32 0 0 flowid 1:10 action mirred egress redirect dev ifb0
Везде пишут что невозможно при помощи ifb огрганизовать шейпер входящего трафика для локальных приложение INPUT и транзитных FORWARD, так как в tc не возможно определить кому и идет пакет.
Решил эту проблему при помощи правил iptables
$IPTABLES -p TCP -s $LAN_IP_RANGE3 -t nat -A POSTROUTING -o $INET_IFACE2 -j SNAT --to-source $INET_IP2:65280-65535
Таким образом все исходящие соединения будут уходить в диапозне source ip port 65280-65535 и tc уже сможет определить на какй интерфейс уйдут дальше пакеты
TC filter add dev $DEV parent 1: protocol ip prio 1 u32 \
match ip protocol 6 0xff \
match ip dport 65280 0xff00 \
flowid 1:13
Только толком так и неразобрался как найти маски tc для портов
У кого нибудь работает маркировка через iptables и просовывание этих пакетов на ifb?
Не работает, и не должна, потому что IFB не является частью netfilter. Для маркировки через iptables используйте IMQ.
