[LARTC] Re: IFB setup was no subject

[Andy Furniss <lists@andyfurniss.entadsl.com>]

Leigh Sharpe wrote:
> Hi all,
>  I'm having a hell of a time getting my IFB to work. I know I've done
> this before, so I'm missing something stupid. Can anybody tell me what
> it might be?
> Configs as follows:
>  
> --------
> #!/bin/sh
> modprobe ifb numifbs=1000
> modprobe act_mirred
> modprobe 8021q
>  
> brctl addbr br0
> brctl setfd br0 0
> brctl stp br0 off
> brctl addif br0 eth1
> brctl addif br0 eth2
> ifconfig eth1 up
> ifconfig eth2 up
> ifconfig br0 up
>  
> tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000
> cell 8
> tc qdisc add dev eth2 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000
> cell 8
>  
> ifconfig ifb0 up
>  
> tc qdisc add dev ifb0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000
> cell 8
>  
> tc class add dev ifb0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate
> 100Kbit weight 10Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
> bounded isolated
>  
> tc qdisc add dev eth1 ingress
> tc qdisc add dev eth2 ingress
> tc filter add dev eth1 parent ffff: protocol ip prio 10 u32 match u32 0
> 0 action mirred egress redirect dev ifb0
> tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0
> 0 action mirred egress redirect dev ifb0
>  
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match u32 0 0
> flowid 1:1
> --------------
>  
> By my reckoning, this should redirect all packets passing through eth2
> and eth1 through the IFB, and put a rate limit on the IFB of
> 100Kbits/sec.
> What have I missed?
Subject changed as the no subject thread I see is quite long and diverse :-)

It will only get ingress ethertype ip traffic on eth 1/2 (I don't know 
whether bridging complicates it - still havent fixed my own bridge yet)
You need two more ... action mirred egress redirect ... to get egress 
eth1/2 traffic aswell. You need something classfull on the roots for it 
to work - you have CBQ already if you didn't prio would have done.
If you have a qdisc on the real interface and redirect egress traffic to 
ifb then you can't classify again, though classification done before the 
 redirect will be reinstated after the packets come back from ifb.
Generally - I never used CBQ so don't know it's limitations/behavior. 
Accepting this may just be a test, but if you did it like this for real 
ie. sending in/out traffic to one slow buffer it will make for a truly 
horrible user experience - you should at least seperate the directions 
into seperate classes and make the classes share the bandwidth.
I wonder if using policers and shared meters would be a nicer 
alternative - not that I have any examples to hand.
If the nics are gig/ you use xen turn off * segmentation offload with 
ethtool -k
Andy.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc