Здравствуйте!

Есть влан (eth2.111), трафик из которого направляется на ifb. Входящий (из инета к абоненту) - направляется в ifb0, исходящий (от абонента в инет) - в ifb1. В дальнейшем и из других vlan'ов трафик будет собираться в ifb, чтобы потом там его шейпить.
С шейпингом входящего трафика на ifb0 проблем нет, все ок, а вот на ifb1 не получается пользоваться фильтрами, т.к. по-видимому туда заварачиваются пакеты "как есть", со служебными транспортными заголовками, и класиффикатор u32 не может определить src/dst IP...
Если заворачивать не с vlan'а, а с eth2 - то пакеты нормальные приходят на ifb1, а вот если с eth2.111, то tcpdump на ifb1 показывает кашу:
# tcpdump -i ifb1
tcpdump: WARNING: ifb1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ifb1, link-type EN10MB (Ethernet), capture size 96 bytes
14:47:21.771685 8f:ec:30:52:00:1c (oui Unknown) > 00:13:8f:ec:00:13 (oui Unknown), ethertype Unknown (0xc02e), length 102:
        0x0000:  e1e7 0800 4500 0054 0000 4000 4001 4424  ....E..T..@.@.D$
        0x0010:  0a0a 6f02 4d78 3001 0800 fb80 084b 0006  ..o.Mx0......K..
        0x0020:  05c6 5d4a 9a1a 0c00 0809 0a0b 0c0d 0e0f  ..]J............
        0x0030:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f  ................
        0x0040:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f  .!"#$%&'()*+,-./
        0x0050:  3031                                     01

Заворачиваю трафик с eth2.111 на ifb1 так:
$TC qdisc add dev eth2.111 ingress
$TC filter add dev eth2.111 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb1

• Исходящий трафик с vlan, переброшенный на ifb,PavelR, 18:31 , 15-Июл-09
  • Исходящий трафик с vlan, переброшенный на ifb,PavelR, 18:42 , 15-Июл-09
    • Исходящий трафик с vlan, переброшенный на ifb,PavelR, 09:56 , 16-Июл-09
• Исходящий трафик с vlan, переброшенный на ifb,mew, 15:07 , 16-Июл-09

>[оверквотинг удален]
>определить src/dst IP...
>Если заворачивать не с vlan'а, а с eth2 - то пакеты нормальные
>приходят на ifb1, а вот если с eth2.111, то tcpdump на
>ifb1 показывает кашу:
># tcpdump -i ifb1
>tcpdump: WARNING: ifb1: no IPv4 address assigned
>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>
>listening on ifb1, link-type EN10MB (Ethernet), capture size 96 bytes
>14:47:21.771685 8f:ec:30:52:00:1c (oui Unknown) > 00:13:8f:ec:00:13 (oui Unknown),

Вроде как это нормальное поведение, так задумано разработчиками ifb, если я правильно понял чтение всякой инфы из интернета. Там описывается, что некто изменил некий флаг в описании устройства, после чего тцпдамп начал показывать всё красиво, особых акцентов на применение u32 там вроде не делалось. Маны типа http://www.linuxfoundation.org/en/Net:IFB#IFB_Example_2 также используют u32.

>
>Заворачиваю трафик с eth2.111 на ifb1 так:
>$TC qdisc add dev eth2.111 ingress
>$TC filter add dev eth2.111 parent ffff: protocol ip prio 10 u32
>match u32 0 0 flowid 1:0 action mirred egress redirect dev
>ifb1

Лично мне не понятно, что определит указание flowid 1:0 в описании фильтра.
Если описывать исходящий фильтр, то этот флоу укажет, в какой класс закинуть трафик по возвращению из ifb-девайса. Но тут  же трафик входящий, как это сработает ??

какие правила фильтрации на ifb1 ? трафик по дисциплине ходит ?

Немного из избранного:

>[оверквотинг удален]
> tc -s qdisc ls dev ifb19
> tc -s filter ls dev eth0 parent ffff:
>
> If you want to do the same sort of thing on egress you need to put
> something classfull on the interface rather than the default pfifo_fast
>   prio will do.
>
> Some examples show using marks aswell, it's not needed as such and
> doesn't always work as the netfilter bits keep getting out of sync with
>   ifb.

А теперь без цитирования... :

To use many you'll need to specify the number with modprobe -

modprobe ifb numifbs=20

ip link ls should show them all - you need to ip link set up dev ifbXX
aswell.

to send arp coming in on eth0 to ifb19 which has a tbf on it (just to
see counters - would be silly to really limit arp)

ip link set up ifb19
tc qdisc add dev ifb19 root tbf limit 2k rate 20kbit buffer 2k

tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol arp prio 1 u32 match u32 0
0 flowid 1:1 action mirred egress redirect dev ifb19

The flowid 1:1 is what the classification will be when the packet
returns from the ifb - unless you are shaping again (on a real dev - you
can't chain ifbs) it doesn't really matter what you put, but you do need
one as wothout it the rule will be accepted, but won't work (apart from
as a counter)

look at counters with -

tc -s qdisc ls dev ifb19
tc -s filter ls dev eth0 parent ffff:

If you want to do the same sort of thing on egress you need to put
something classfull on the interface rather than the default pfifo_fast
   prio will do.

Some examples show using marks aswell, it's not needed as such and
doesn't always work as the netfilter bits keep getting out of sync with
  ifb.

Все разобрался... Просто что-то напутал с фильтрами сначала. u32 работает нормально. Можно закрывать :)