I''m trying to shape a connection behind a NAT. I have done it already using tc with htb. Now the problems is that I want to run Squid on the same machine, and also control de bandwidth but with htb so it can change the bandwidth in real time. For the non-squid version of this, I''m using iptables-mangle to mark packets and tc for the traffic control. As squid is only for HTTP transactions, I decided to send through it only the web traffic(excludind FTP and SSL), and limit the downstream with HTB as in the non-squid version. But the upstream is always uncontrolled since one only can control the packets going out of the server and the uploading proccess seem to come from the NAT-server since is there where squid is installed and squid doesn''t make any NAT at all. Is there a way to mark the packets squid sends out so tc can control them also? Exists there another solution? Is the web-cache server a bad solution into the QoS rage? If something sounds stupid I apologize, since I''m a newbie. Pity the meek, for they shall inherit the earth. -- Don Marquis _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
ToS marking of outgoing packets is included in Squid versions from 2.5STABLE1 onward. Just enable it when you run configure. Angelripper wrote:> I''m trying to shape a connection behind a NAT. I have done it already > using tc with htb. Now the problems is that I want to run Squid on the > same > machine, and also control de bandwidth but with htb so it can change > the bandwidth in real time. For the non-squid version of this, I''m using > iptables-mangle to mark packets and tc for the traffic control. > > As squid is only for HTTP transactions, I decided to send through it > only the web traffic(excludind FTP and SSL), and limit the downstream with > HTB as in the non-squid version. But the > upstream is always uncontrolled since one only can control the packets > going out of the server and the uploading proccess seem to come from the > NAT-server since is there where squid is installed and squid doesn''t make > any NAT at all. Is there a way to mark the packets squid sends > out so tc can control them also? Exists there another solution? Is the > web-cache server a bad solution into the QoS rage? > > If something sounds stupid I apologize, since I''m a newbie. > > > Pity the meek, for they shall inherit the earth. > -- Don Marquis > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/-- Joe Cooper <joe@swelltech.com> Web caching appliances and support. http://www.swelltech.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sunday 10 November 2002 01:22, Angelripper wrote:> I''m trying to shape a connection behind a NAT. I have done it already > using tc with htb. Now the problems is that I want to run Squid on the > same > machine, and also control de bandwidth but with htb so it can change > the bandwidth in real time. For the non-squid version of this, I''m using > iptables-mangle to mark packets and tc for the traffic control. > > As squid is only for HTTP transactions, I decided to send through it > only the web traffic(excludind FTP and SSL), and limit the downstream with > HTB as in the non-squid version. But the > upstream is always uncontrolled since one only can control the packets > going out of the server and the uploading proccess seem to come from the > NAT-server since is there where squid is installed and squid doesn''t make > any NAT at all. Is there a way to mark the packets squid sends > out so tc can control them also? Exists there another solution? Is the > web-cache server a bad solution into the QoS rage?If you want to control downloads with squid, you can use the delay pools. You can create different delay pools with different download speeds. And you can even filter on size of the downloaded file. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sun, 10 Nov 2002, Stef Coene wrote:> If you want to control downloads with squid, you can use the delay > pools. You can create different delay pools with different download > speeds. And you can even filter on size of the downloaded file....which is weak solution comparing what can be achieved using TC or best cooperative TC + Squid. Regards tw -- ---------------- ck.eter.tym.pl "Never let shooling disturb Your education" _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sunday 10 November 2002 16:55, Tomasz Wrona wrote:> On Sun, 10 Nov 2002, Stef Coene wrote: > > If you want to control downloads with squid, you can use the delay > > pools. You can create different delay pools with different download > > speeds. And you can even filter on size of the downloaded file. > > ...which is weak solution comparing what can be achieved using TC or best > cooperative TC + Squid.I never said that using the daly pools is the best solution. But delay pools can do some stuff that tc can''t. Squid knows the size of the downloaded object and use it to create different delay pools. It can also authenticate people so you can use different settings for different peoples. You can even install/enable inetd on all cliens so you can use local login names to put traffic in different daly pools. On the other hand, tc has some extra advantages, but I think we all know them. Sharing bandwidth, controlling delays, ... Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I don''t want to use delay pools, since I want squid as a web-cache and TC as a traffic shaper(the way it should be, I think :P). Now I have tried to use DSCP marks(using Squid5Stable1) on packets so TC can handle them, but the fact is they are leaving my machine without being even touched by TC. So now I have a netfilter problem (or I''m not sure if is it still a Lartc problem). I don''t know if this is the right place to ask for it, but if the packet is generated locally (as squid generates it) and it is DSCP marked will TC match it (is the TOS match DSCP compatible or are they different fields???). If I use iptables to mark with "fwmark"(based on the DSCP mark writted by SQUID something like "#iptables -t mangle -D POSTROUTING -m dscp --dscp 0x00 -j MARK --set-mark 5") the packet will TC see this fwmarked packet as with the nated packets? I guess not, because this packet will not fall in mangle, so this should be done in the OUTPUT chain, but iptables doesn''t support dscp on this chain. Which solution can I implement then? _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I apologize if I offended you, my intention was not to offend anyone,
sorry(I was just kidding, I already know of the great advantages on
Layer 3 squid offers, but is not the solution that I''m looking for).
What u say is what I''m actually doing, using acl in order to put a DSCP
mark on each packet leaving the maching according to the IP src, is
something like this
acl higgs src 192.168.1.2
tcp_outgoing_dscp 0x01 higgs
But tc seems to have no support on dscp or I haven''t found it yet; so I
must "remark" the packet with a fwmark that tc can handle. Thats where
the problem becomes a netfilter problem, but if you thinks it deeply is
a routering problem since the packets are being routered(anyway the
problem concercs with iptables or something so).
--
It will be advantageous to cross the great stream ... the Dragon is on
the wing in the Sky ... the Great Man rouses himself to his Work.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
That''s true rob, should be in the OUTPUT traffic. But rob, the problem is I''m trying to limit the upstream which in the case in which is squid is used, seems always to come from the local machine to the internet, so TC will not know to whom belongs that packet, it just belong to the local machine. There is where dscp is needed, in order to know (with squid''s help) to know to whom the "routered" packet belongs. I have already posted this question on the netfilter maillist, but I haven''t had an answer.>locally generated traffic should be in the OUTPUT chain, if you specify the >source port and the destination (device?) then i think you should not >need -m dscp anymore. > >-- >rob > > >-- Behold the warranty ... the bold print giveth and the fine print taketh away. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Yes Squid an TC are on the same machine. I know fwmarks exists only in kernel''s memory. ToS and DSCP goes in the TOS field in the IP packet. I need the packet inside my machine, I don''t care about it when it leaves it. > > > Are you running both Squid and tc on the same machine? Its worth > mentionning because the FW ''Marks'' don''t really ''exist'' as such within > the packets, but in the kernel''s memory. Once the packet''s sent, its > just a normal packet again. You can use diffserv marks though, which > survive routing ... > -- Logicians have but ill defined As rational the human kind. Logic, they say, belongs to man, But let them prove it if they can. -- Oliver Goldsmith _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/