[LARTC] Fwd: Traffic Shaping on a Transparent Bridge not working!

[Andy Furniss]

drew einhorn wrote:

> RTFM time.  The htb section of http://lartc.org/howto/index.html is easier
> reading than the cbq section.  And the howto claims htb is better anyway.
> Let's focus on the htb version of wondershaper.

Yes HTB/HFSC should br better for slow links, unfortunatly wondershaper 
is flawed as noted below. This may not be your problem here, though.


> Then we start downloading a file to generate some traffic that really
> needs to be shaped.

Shaping from the wrong end of the bottleneck is not nice and the slower 
the link the harder it is. It's better than not shaping (policing in 
this case).


> root at Devil:~ # sh -x wshaper.htb
> + DOWNLINK=100
> + UPLINK=100
> + DEV=eth0
> + NOPRIOHOSTSRC=
> + NOPRIOHOSTDST=
> + NOPRIOPORTSRC=
> + NOPRIOPORTDST=
> + '[' '' = status ']'
> + tc qdisc del dev eth0 root
> + tc qdisc del dev eth0 ingress
> + '[' '' = stop ']'
> + tc qdisc add dev eth0 root handle 1: htb default 20

It's not a good idea to use default on eth, unless you explicitly handle 
arp. IIRC WS was tested on ppp so I guess thats why. Not specifying 
default lets unclassified through unshaped and you can, and do make a 
catchall ip filter later for 20 anyway.

> + tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k
> + tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst 
> 6k prio 1
> + tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k 
> prio 2
> + tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k 
> prio 2

Rates can't add up to more than parent rate/ceil I guess the test case 
used didn't expose this when WS was published. I would use something like -
... 1:10 htb rate 80kbit ceil 100kbit ...
1:20 htb rate 15kbit ceil 100kbit
1:30 htb rate 5kbit ceil 100kbit


> + tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
> + tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
> + tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
> + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip
> tos 0x10 0xff flowid 1:10
> + tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip
> protocol 1 0xff flowid 1:10
> + tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip
> protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2
> match u8 0x10 0xff at 33 flowid 1:10
> + tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip
> dst 0.0.0.0/0 flowid 1:20

This filter should catch all IP so default not needed.

> + tc qdisc add dev eth0 handle ffff: ingress
> + tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip
> src 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1

I am suprised this did nothing - at low speeds you may need to back off 
a bit more. If I were shaping 128kbit link I would be tempted to mss 
clamp/set mtus lower as 1500byte packets have long bitrate latency - 
depends on your requirememts and I am not sure you can mss clamp with 
this bridge setup.



> + tc -s qdisc ls dev eth0
> qdisc htb 1: r2q 10 default 20 direct_packets_stat 0
> Sent 18649 bytes 191 pkts (dropped 0, overlimits 0)
> qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec
> Sent 10582 bytes 147 pkts (dropped 0, overlimits 0)
> qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec
> Sent 8067 bytes 44 pkts (dropped 0, overlimits 0)
> qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

Looks OK, we are testing ingress anyway. I would use limit XX on sfqs as 
128 default is a very long time @ low bitrates.


> qdisc ingress ffff: ----------------
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

0 bytes - something wrong here. Filter looks OK, but it's not seeing 
traffic. I haven't got a 2.4 box, I do have a br on a 2.6 box and just 
tested on eth0 - works OK with those rules.

Counters on eth0 egress look OK so I assume all traffic is IP  - tcpdump.

I wonder if it's something to do with bridging (I don't understand some 
behavior of mine), maybe ingress on eth0 has a different ethertype at 
that point.

Try this instead -

tc qdisc add dev eth0 handle ffff: ingress

tc filter add dev eth0 parent ffff: protocol arp prio 1 u32 match u32 0 
0 flowid :1

tc filter add dev eth0 parent ffff: protocol all prio 2 u32 match u32 0 
0 police rate 100kbit burst 10k drop flowid :2


Aggh just thought of something else - tempted to delete above, but will 
leave incase it works.

The thing is 2.4 and 2.6(default config) use different policers. On 2.4 
it hooks after PREROUTING and on 2.6 before. Maybe old policer + bridge 
isn't going to work for that reason.

Andy.