| |
| 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, но точно не уверен. |  | | |
| 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 соединений работает отлично |  | | |
| 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 и т.п., так работает стабильно уже наверно года два.
Иногда мне кажется что падение старого ядра это результат атаки, использующей дырки в ядре.
|  | | |
| 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, 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 для портов
|  | | |
|
|