> My first guess would be vlans being a problem. I know at least for > class based queuing disciplines on vlans, you have to take care to > define filters that funnel traffic through a class by selecting > 802.1q traffic on the real interface, not the vlan interface. Wow, why would that be though? If the VLAN is simply presented as an interface, and the queuing disciplines work on an interface basis, what is it that breaks it? > I know traffic shaping does work on vlans with the class based queues > because I use it every day. But all my tc statements are applied on a > real physical interface and not the vlan interface; I could never get > tc to work on vlan interfaces directly. For what's it worth, I've been applying netem queuing disciplines to many different VLAN interfaces and have been getting exactly the expected results (the packet loss % is right on, etc). Could you think of anything different with a tbf that fails? > Just a guess, but I bet you'd get the rate limiting you expect on > your vlan by applying the tbf rate limit on interface eth1 instead of > the vlan interface. If so, and if your goal is to rate limit by vlan, > then you will likely need to go with a class based queueing > discipline like htb and then define traffic filters to limit each > vlan to the rate you wish. Yes the goal is to limit by VLAN. I will try what you suggested, i.e. limit the traffic on the physical interface instead and I'll report back. But I hope that won't be the solution! :) > > > > > > > > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Aug 2007 23:32:18 -0700 >> From: sting <sting@xxxxxxxxxxxxx> >> Subject: simple tbf rate clamping issues >> To: LARTC@xxxxxxxxxxxxxxx >> Message-ID: <46CBD872.6060307@xxxxxxxxxxxxx> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hello, >> >> I was attempting to throttle egress traffic to a specific rate using a >> tbf. As a starting point I used an example from the LARTC howto, >> which >> goes: >> >> tc qdisc add dev eth1 root tbf rate 220kbit latency 50ms burst 1540 >> >> I then attempt a large fetch from another machine via wget (~40 megs) >> and the rate was clamped down to about 12Kbytes/s. As this seemed too >> much, I gradually increased the latency up to 200ms which then gave me >> the expected results (~34Kbytes/s). >> >> I then applied this queuing discipline on a machine acting as a >> gateway/router for a few VLANed subnets. The tbf was applied on >> interface eth1.615. From another workstation I attempted a wget, >> and so >> the traffic had to go through the gateway/router. The download rate >> went from 16 Mbytes/s down to about 1.6 Mbytes/s, but was much much >> higher than what I'm trying to clamp it down to. >> >> Two questions: >> 1/ My main question. AFAIK, queuing disciplines affect egress traffic >> whether that traffic originates from the host or is being forwarded. >> Assuming that the fact the tbf is mostly meant to be applied to >> forwarded traffic is not an issue, *is there anything else that could >> cause the transfer rate not to be correctly clamped down?* What >> parameters should I be playing with? >> >> 2/ I'm assuming the first example I quoted must have worked as >> described >> when the HOWTO was initially written a few years ago. In any case, >> i am >> assuming with 50ms max latency outgoing packets could not be held long >> enough in the tbf and had to be droppd, correct? >> >> Thank you, >> sting >> > > _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
