Andy Furniss wrote:
This won't work on ifb0. You could put it on eth1 and change the
"protocol ip" to "protocol all" and change the match to "match u32 0
0" . In theory that may catch a few arp so I suppose you could add
another rule to exempt them.
tc filter add dev eth1 parent ffff: protocol arp prio 1 u32 match u32
0 0 flowid :2
I would also make the burst bigger since you have quite high ingress
bandwidth.
Andy.
Thanks for the suggestions Andy, I've put them all into place, and
everything seems to be working nicely. I just had a question regarding
the rule to catch the ARP's - I get this message when I add the rule:
RTNETLINK answers: File exists
I guess this because the parent qdisc for that interface has already
been defined - does this mean that the rule won't work? Or is it just a
debugging notice that can be safely ignored?
I've also raised my burst to 50k. Implementing the downstream shaping
techniques you suggested, I am seeing good results.
I had a question regarding the ifb device - does it behave as a normal
interface when doing masquerading etc? It seems that if I place
destination IP's in the NOPRIOHOSTDST field, these get marked as low
priority, and the same when I put source ports in NOPRIOPORTSRC. When I
put source IP's in the NOPRIOHOSTSRC field, these do not seem to get
marked as low priority - I tried with 192.168.0.1 as an example (an FTP
server on the network). Could this be related to the fact that I'm using
the IFB device?
Thanks,
Terry.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc