I use IMQ to incomming traffic shaping (using u32 to match the source/destination MACs)
With IMQ I use: iptables -t mangle -A PREROUTING -i $if_wan0 -j IMQ --to-dev 0 (for example) To enqueue packets into IMQ device and then shapping. With IMQ I can use modprobe to set the device count I need and so on. I really only want to replace IMQ scripts code with IFB, but, at least for now, I don't stand fine the packet flow using IFB. I stand now how to initialice ifbX with your example, good!! Now some aditional question about your example: With this line: tc qdisc add dev ifb19 root tbf limit 2k rate 20kbit buffer 2k You are initializing the qdisc for ibf in the same manner you could do with imq? With this lines: 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 Are those analogous as this (my imq0 device as your ifb19 device): iptables -t mangle -A PREROUTING -i $if_wan0 -j IMQ --to-dev 0 ? The last, Do I only need add clases and qdiscs to ifb19 as if it where my imq0 device? Thanks and sorry for my english. El Vie, 18 de Agosto de 2006, 11:41, Andy Furniss escribió: > Samuel Díaz García wrote: >> Hi, I'm looking for info about IFB devices and how I can use it to >> incomming traffic shapping. >> >> Has IFB any web about it? >> Do any body known where I can find more info about it? >> >> I found this: >> http://linux-net.osdl.org/index.php/IFB >> >> But I can't stand fine how to use it to allow many ifb's devices or how >> to use it with "tc actions". >> >> Any help? >> >> Thanks >> > > 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. > > Andy. > > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
