[LARTC] WonderShaper and NNTP traffic.
Hi! I'm testing out the wshaper script using both CBQ and HTB, with: DOWNLINK=1152 UPLINK=312 DEV=eth3 It works great for simultaneous uploads/downloads, and FTP traffic, but when I enable wshaper and am doing an NNTP download, it slows NNTP downloads to 50kB/s. When I do a 'wshaper stop', NNTP downloads creep back up to about 150kB/s. FTP downloads, as mentioned go full speed at around ~130-140kB/s as well. Any ideas on why this might be happening, or what I can try to tweak? -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian/ GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [rogue.genosha.enfusion-group.com] 5:10pm up 18 days, 1:17, 5 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] (no subject)
On Fri, May 03, 2002 at 12:21:13PM +0200, Stef Coene wrote: [...] > you can't match them. But there is a iptables-hack that can mark all > ftp-packets and after that you can use that mark with the fw filter to put > all packets in a class. I searched for this a while back, and didn't see it in the standard patch-o-matic stuff... Do you know where it can be found (the patch for marking ftp-packets)? -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 40 days, 20:27, 20 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Fwmark problem - policy routing does not work.
On Sat, Apr 27, 2002 at 10:25:24AM +0200, Arthur van Leeuwen wrote: > On Fri, 26 Apr 2002, Adrian Chung wrote: > > > When you add a route that sets a src like: > > > > ip route add table 192.168.1.0/24 src 192.168.1.11 dev eth0 > > > > The "src" doesn't specify the source IP to put in the packet (it's not > > network address translation, like SNAT in iptables), it just specifies > > which local source IP the routing mechanisms should use to determine > > where to route the packet. > > Actually, it is more subtle than that. The 'src' *does* specify the source > IP to put in the packet *if* the packet doesn't have a source IP yet. This > only holds true for packets generated locally. Ah okay, that makes sense... But I think in both our cases the packets were generated locally, so the 'src' flag should have set the source IP. Is it possible for the application (telnet in my case) to explicitly bind to a socket and set it's source IP? That could explain why the rule has no effect since by the time the packet reaches the routing system, it already has a source IP set. -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 34 days, 17:14, 17 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Fwmark problem - policy routing does not work.
On Fri, Apr 26, 2002 at 10:01:48PM +0200, Thilo Schulz wrote: [...] > > The "src" doesn't specify the source IP to put in the packet (it's not > > network address translation, like SNAT in iptables), it just specifies > > which local source IP the routing mechanisms should use to determine > > where to route the packet. > > However, somewhere inthe iproute tools this HAS to be possible ... I read in the documentation for iproute2 somewhere, sometime that there was a 'nat' directive, but I thought I'd also read that it wasn't very well supported, probably didn't work, and probably wouldn't be rewritten to work because netfilter/SNAT already do a much better job of NAT in general. [..] > Also i'm going to contact one of the Policy Routing developers. Hope you get it working! -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 34 days, 1:40, 17 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Fwmark problem - policy routing does not work.
On Tue, Apr 23, 2002 at 07:23:58PM +0200, Thilo Schulz wrote: [...] > I have a computer in my LAN with 2 ips (192.168.1.10 and 192.168.1.11), the > latter one created by "ip addr add" and users on that computer, and depending > on the uid of the created packets i want those to take another source address. > Of course, it should start with marking the packets with a simple iptables > rule: > > iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 1 [...] > The table as well as the route entry are correct, i am sure of this, for i > have tested removing the fwmark rule and instead added: > ip rule add to 192.168.1.4 table thilo > everything worked then as i have intended, and it showed me logged in from > 192.168.1.11 then. Are you sure it showed you as logged in from 192.168.1.11? I just tried the same setup here, and with either setup you describe, it always shows me as having logged in from the primary IP. In my case, I setup 192.168.1.1 and 192.168.1.2 and tried to connect to 192.168.1.5. In both cases above, it showed me as having logged in from 192.168.1.1. The counters are incrementing though, so marking is working. > Another problems checked too: I have enabled MARK based routing in the kernel > (policy routing, everything switched on ..) > > So I only can ask you on this mailing list - anyone got an idea of what > is/what i did wrong? Depending on what the results of your second setup above were (ip rule add to 192.168.1.4 table thilo), I have a theory... When you add a route that sets a src like: ip route add table 192.168.1.0/24 src 192.168.1.11 dev eth0 The "src" doesn't specify the source IP to put in the packet (it's not network address translation, like SNAT in iptables), it just specifies which local source IP the routing mechanisms should use to determine where to route the packet. For example, I've got policy routing setup with FreeS/WAN on a gateway with an internal and external interface, where I do: # ip rule add table 1 prio 100 # ip route add table 1 dev ipsec0 src This forces the box to route all packets to the remote LAN via the internal interface, rather than the external interface. However, the packets that show up at the other end don't contain a source IP of from the table 1 route, rather they contain the source IP of the client machine that sent them. This led me to believe that the "src" option only adjusts the way the routing machinery in the kernel decides where and how to route the packet, but doesn't change/rewrite the source address in the packets themselves. This makes sense to me as well, because if setup routes for 192.168.1.4 through 192.168.1.11, and send packets from 192.168.1.10, they'll have a source address of 192.168.1.10, but get routed through the 192.168.1.11 interface (which is transparent at 192.168.1.4's end). If you really want the packets to look like they're coming from 192.168.1.11, why don't you just use iptables and SNAT them? -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 34 days, 1:10, 17 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Routing based on source port - Solution ?
On Fri, Apr 19, 2002 at 03:18:01PM +0200, Tobias wrote: [...] > Unfortinuatly netfilter can only set MARKs in the moment the > packets travers the INPUT Queue (of corresponding interface). > > --> > netfilter is not able to set mark for _local_ created packets, > because the INPUT Queue of netfilter is not passed. > > => In fact the MARK mechanism can only be used for incoming packets. Prior to 2.4.18, the 'mangle' table had PREROUTING (for incoming packets prior to routing) and OUTPUT (for locally generated packets) chains. After 2.4.18, there are INPUT, FORWARD, and POSTROUTING chains as well. I'm using the OUTPUT chain of the 'mangle' table to set-tos values, but I'm pretty sure I can --set-mark instead. I'm unable to test it at the moment though. -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 26 days, 21:07, 16 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] device independent qdisc?
On Wed, Mar 20, 2002 at 02:10:49PM +0100, Martin Devera wrote: > http://luxik.cdi.cz/~devik/qos/ > look at IMQ > > On Wed, 20 Mar 2002 [EMAIL PROTECTED] wrote: > > > Hello ALL, > > is there a way to have a device independent qdisc, or a qdisc on some kind > > of virtuall interface? Could one use IMQ and a route filter to have 75% of the total bandwidth of two devices go via one interface and 25% go via the other? There aren't many examples of IMQ in action, but I was wondering if something like the following would be possible (bearing in mind I'm new to this, and this might make no sense): - Set up IMQ - Attach HTB with two classes - Use route filter to put traffic going out each WAN interface into each class - One class (first interface) has a higher priority and is isolated, but can borrow from the other class (second interface). I want to primarily use one interface, but when it gets full, also use the other one. -- Adrian Chung (adrian at enfusion-group dot com) http://www.enfusion-group.com/~adrian GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17 [toad.enfusion-group.com] up 1 day, 8:20, 4 users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
