Re: [LARTC] bridging shaper
Bart De Schuymer wrote: There are no real differences, except that arptables doesn't see bridged traffic, between the 2.4 bridge-nf/ebtables patch and the code in 2.6. So my guess is the problem isn't the bridge filtering code. I don't doubt that the bridging code, and iptables/ebtables is nearly the same, but _something_ is different. (Kernel .config options, QoS code, 2.4/2.6 interface, aliens abducting sk_buff->nfmark, I dunno...) The same system booted with a 2.4 kernel and a 2.6 kernel behave differently. 2.6 was configured with similar options to 2.4. (make oldconfig -> Maybe there's a new option somewhere that I'm missing?) As far as I can see, bridged traffic control on 2.4 works, 2.6 doesn't: "tc -s class show dev eth0" on a 2.4 kernel shows packets being classified properly, whereas on 2.6, they are not classified properly. I actually think iptables/ebtables is working properly; In 2.6, ebtables does indeed count the correct number of packets passing through each rule, and assuming that "-j mark" actually marks them, the only possibly answer would be that the tc stuff isn't catching those marks. I'd be really happy to hear any suggestions or ideas, 'cause I'd really love to get 2.6 working! If there's _anything_ I can do that might help debug this stuff, I'd be glad to try. Cheers, jon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] bridging shaper
Ryan Rothert wrote: I dont really need to run 2.6, 2.4 would be fine, what version are you using? Did you compile it yourself? Did you have to apply any extra patches if you compiled it yourself? 2.4.25+brnf-5 (Patch here: http://sourceforge.net/project/showfiles.php?group_id=39571 ) Yes, compiled myself - almost has to be. If you look through the archive for earlier this month, possibly last (look for "bridge") there's a little more detail about it. If you have any specific questions, I'd be glad to try and help if I can. jon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] bridging shaper
Ryan Rothert wrote: Any thoughts as to why this doesnt seem to work on a bridge? It does work if the box is setup to be a router. I have tried to do bridged traffic control with 2.6. It just doesn't seem to work. u32 matches won't work, marking packets with iptables/ebtables then trying to catch them with tc's fw match doesn't work. Filters just won't catch anything in 2.6, and all traffic just leaves through the default class. There are reports of people getting this working, but no real details have emerged. With 2.4, it works without problems. I have a few machines running bridging firewalls with traffic control using 2.4. Works without issues. Any developers want to shed some light on why 2.6 doesn't seem to go? (Config options?) jon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Bridge + TC
Roy Walker wrote: I posted out on this problem some time ago and could never get 2.4.25 or any 2.6 kernel to work with TC + Bridging. If anyone has this working and has actually tested it (I am actually just doing IP based iptables filtering from my bridge interface) please let us know what version of iproute you used and what patches you applied and with which version of the kernel. The older 2.4.2x kernel's seem to work fine for this (I am currently running 2.4.22). I just got this working under 2.4.25 on a different test rig (with only 2 interfaces) - installed Debian Testing, patched and compiled a kernel with relevant stuff, start the bridge, apply tc rules, and *poof* packets get filtered/classified properly. All within 1.5 hrs. `tc -s class show dev eth0` shows the right stuff going through the right filters at the right rate. Versions/patches: iproute-20010824-13, from Debian testing iptables-1.2.9, from Debian testing (Used: iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 0x4 --> no ebtables needed) ebtables-brnf-5-vs-2.4.25 patch from ebtables.sourceforge.net kernel-2.4.25, with above ebtables patch Hopefully it'll still work with 3 interfaces when I get 2.4.25 on the original test rig! Cheers, jon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Bridge + TC
Jeroen Vriesman wrote: So I would suggest testing: 1) no filter rule for 1:10 which is default This shouldn't affect things in the end though, correct? (I.e. it's overkill, but it won't hurt anything, right?) (I've also had it pass by default through the 1:1, in which case nothing passed through 1:10, nor 1:20 - everything went through 1:1.) 2) no filters with handle 1, (I start at 101 for the filters) tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10 "handle 1" - is that not how it picks up on nfmark? If nfmark is set to 1, is this not the part that picks up that nfmark? 3) marking with iptables in mangle PREROUTING I have also tried that. I'm using 2.6.3-mm3 -> packets don't seem to pass through iptables anymore unless they're specifically routed rather than bridged (can anyone confirm this?). I have another (2-if, no QoS) bridge running 2.4, and iptables commands filter fine. With this new bridge running 2.6, dropping everything with iptables doesn't work 'iptables -A FORWARD -j DROP' doesn't affect the bridge in the least - hosts continue to talk through the bridge. (Same in ebtables works as expected though.) should work, it's working fine here on 2.4.24+ebtables Perhaps the key here is 2.4. I might have to revert... Thanks for the input. Now I have something else to try! Cheers, jon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Bridge + TC
I'm hoping someone can provide a little input that might help me out a little... I've recently tried to setup a 3-interface transparent bridge, where 2 internal interfaces (eth1,eth2) funnel into 1 outgoing interface (eth0). The idea was to be that eth1 gets priority over eth2 in all cases. The bridge works flawlessly - it passes all layer2 traffic through properly. The traffic control however, does not work at all. (The LARTC Howto says bridging + tc should "work as advertised", but no examples or instructions are given...) The conclusion I came to was that bridging is done in layer2, and so traffic control code (typically layer3) never gets to touch it. Am I wrong? Setup was: mark packets with ebtables, then filter into 2 qdiscs based on those marks. Ebtables bit: ebtables -A FORWARD -i eth1 -j mark --set-mark 0x1 ebtables -A FORWARD -i eth2 -j mark --set-mark 0x2 - This works, as ebtables' counters do count matching packets correctly (connecting a machine to and interface, and starting . (I assume that they set sk_buff->nfmark properly.) . Classes: tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 500kbit ceil 500kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 450kbit ceil 500kbit prio 0 tc class add dev eth0 parent 1:1 classid 1:20 htb rate 50kbit ceil 500kbit prio 1 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10 tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:20 As I understand it, the second last line should put packets with nfmark 1 into class 1:10 (450-500 kbit), and the last line should put packets with nfmark 2 into class 1:20 (50-500kbit). With an active host plugged into eth2, all I get is traffic going through the default class (1:10) according to 'tc -s show class dev eth0' If anyone could offer any suggestions, I'd be glad to hear 'em. Cheers, jon anderson ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
