1.1, demyan (??), 14:31, 23/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Все отлично, вот только баги в этом 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, но точно не уверен. | |
|
2.2, andyS1976 (??), 14:44, 23/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
А я как раз по тихоньку двигаюсь к тому чтобы не было подмены 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 стабильно работает? | |
|
3.6, uu4jdf (??), 16:09, 30/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
ядро 2.6.16 патченное esqf/imq прекрасно работает. Процитированный вами пост на linux.org.ru был мой. В той ситуации проблема была в этом http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/ImqFaq#How_stable_is_IMQ. Другими словами - в 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
| |
|
4.7, andyS1976 (ok), 23:42, 08/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
Я пока остановился на IFB, сейчас в стадии тестирования и проблем пока нету.
Попробовал и IMQ, но не учел описанную Вами особенность, спасибо за разъяснение проблемы,
поскольку наверняка бы наступил на описанные Вами грабли. | |
|
5.8, uu4jdf (??), 16:32, 11/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Я пока остановился на IFB, сейчас в стадии тестирования и проблем пока
>нету.
>
>Попробовал и IMQ, но не учел описанную Вами особенность, спасибо за разъяснение
>проблемы,
>поскольку наверняка бы наступил на описанные Вами грабли.
А какие адреса вы раздаете клиентам с vpn сервера? "Левые" или реальные?
| |
|
|
7.11, uu4jdf (??), 15:05, 17/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>После VPN делаю НАТ
>10.10.10.ХХ-->192.168.0.X-->NAT-->xx.xx.xx.GW
а шейпер используете?
| |
|
|
9.20, storm (??), 19:04, 05/04/2008 [^] [^^] [^^^] [ответить] | +/– | Не могли бы вы описать, как завернуть трафик c ppp на ifb0 Никак не могу настро... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
1.3, demyan (??), 15:01, 23/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
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/0x380
IMQ и 30-100 ppp соединений работает отлично | |
|
2.4, demyan (??), 15:04, 23/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
вот есть еще http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.21-rc5-rt9 - набор патчей для 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;
и тд | |
|
1.5, andyS (?), 16:36, 23/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
У меня линуксовое ядро (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.13, unk (??), 20:28, 30/08/2007 [^] [^^] [^^^] [ответить]
| +/– |
>В 2.6.20 пофикшено, сам принимал участие в отладке.
а что имменно пофикшено? работа с ifb или imq?
| |
|
3.15, Anatoliy (??), 19:00, 21/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ничего там не профикшено ни ifb, ни imq. Виснет как и висло и в .20, и в .21, и в .22, и в .23 ядрах.
| |
|
|
1.16, Peter (??), 22:09, 16/01/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
IMQ у меня работает на 22, 23. Около 300 одновременных сессий, smp система. Анатолий, почему у меня не глючит, а у Вас виснет? Вы пробовали написать в список рассылки IMQ о проблеме? Хм. Знаю, ибо я туда подписан, не пробовали. Куда проще здесь кричать, что ничего не работает...
| |
1.17, Alex (??), 13:08, 19/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Kernel-2.6.24, iptables-1.4.0, iproute2-ss071016. IFB работает, но конструкция с маркировкой при помощи iptables (последний пример) - НЕТ. То есть команды выполняются без ошибок, но трафик по классам в итоге не разбивается. А фильтры в iptables не в пример tc'шным удобнее. ОЧЕНЬ буду благодарен за помощь в решениии этой проблемы.
Кстати, в Shorewall-4.1.6 включена поддержка настройки IFB устройств. Очень рекоммендую.
| |
1.18, rtty1 (?), 21:24, 22/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В статье очень много ошибок и недочетов, по видимому коряво переведено. Статья не дает ответов, а только добавляет вопросов.
| |
1.19, rtty1 (?), 22:30, 22/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Подскажите пжста как перенаправить траффик с eth0 на ifb0. у меня TCPdump молчит при прослушке ifb0,
хотя дословно делаю как написано
| |
|
2.21, vvvua (ok), 19:00, 24/04/2008 [^] [^^] [^^^] [ответить]
| +/– |
У меня ядро 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
| |
|
3.23, PavelR (??), 20:04, 14/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>У меня ядро 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
| |
|
|
1.22, Maxim (??), 19:49, 25/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Везде пишут что невозможно при помощи 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 для портов
| |
1.24, Аноним (-), 04:37, 13/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
У кого нибудь работает маркировка через iptables и просовывание этих пакетов на ifb?
| |
|
2.25, Аноним (-), 00:34, 22/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
Не работает, и не должна, потому что IFB не является частью netfilter. Для маркировки через iptables используйте IMQ.
| |
|
|