Hello, I have some htb rules set up to govern download speeds through a linux box, depending on the IP address of the destination machine. My problem is that when the end users choose to use my squid cache, which sits before the htb machine (and has to be there), the htb machine thinks the traffic is going to/from the squid box, so nullifying all my bandwidth rules. Has anyone come accross this before? Gavin ************************************************************** Scanned by MailScan Content-Security and Anti-Virus Software. Visit http://www.mwti.net for more info on eScan and MailScan. **************************************************************
On Wednesday 22 May 2002 09:00, Gavin White wrote:> Hello, > > I have some htb rules set up to govern download speeds through a linux box, > depending on the IP address of the destination machine. > > My problem is that when the end users choose to use my squid cache, which > sits before the htb machine (and has to be there), the htb machine thinks > the traffic is going to/from the squid box, so nullifying all my bandwidth > rules.All squid traffic will have as source address the squid box, so you can''t know who is doing what. But squid can also do bandwidth management. Take a look at delay pools, Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
oh well, just wondered if there was a way to get squid to keep the original IP. I''m currently working on a fully automated mac address authentication, bandwidth control thing for WISPS - it takes a csv from rodopi and modifies it''s iptables and htb rules according to the latest client data. In fact, we''re starting to migrate today. If anyone wants to take a look at the script, mail me and I''d be glad to send it. Gavin ----- Original Message ----- From: "Stef Coene" <stef.coene@docum.org> To: "Gavin White" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> Sent: Wednesday, May 22, 2002 10:27 AM Subject: Re: [LARTC] squid + tc On Wednesday 22 May 2002 09:00, Gavin White wrote:> Hello, > > I have some htb rules set up to govern download speeds through a linuxbox,> depending on the IP address of the destination machine. > > My problem is that when the end users choose to use my squid cache, which > sits before the htb machine (and has to be there), the htb machine thinks > the traffic is going to/from the squid box, so nullifying all mybandwidth> rules.All squid traffic will have as source address the squid box, so you can''t know who is doing what. But squid can also do bandwidth management. Take a look at delay pools, Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net ************************************************************** Scanned by MailScan Content-Security and Anti-Virus Software. Visit http://www.mwti.net for more info on eScan and MailScan. ************************************************************** ************************************************************** Scanned by MailScan Content-Security and Anti-Virus Software. Visit http://www.mwti.net for more info on eScan and MailScan. **************************************************************
I''ve seen patch to squid somewhere. The trick is to encode original requester information into new request packets. It can go into "priority" field - it is 32bit and is userspace-settable. I''m currently thinking about doing something like it but have no time ... On Wed, 22 May 2002, Gavin White wrote:> oh well, just wondered if there was a way to get squid to keep the original > IP. > > I''m currently working on a fully automated mac address authentication, > bandwidth control thing for WISPS - it takes a csv from rodopi and modifies > it''s iptables and htb rules according to the latest client data. In fact, > we''re starting to migrate today. If anyone wants to take a look at the > script, mail me and I''d be glad to send it. > > Gavin > > > ----- Original Message ----- > From: "Stef Coene" <stef.coene@docum.org> > To: "Gavin White" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> > Sent: Wednesday, May 22, 2002 10:27 AM > Subject: Re: [LARTC] squid + tc > > > On Wednesday 22 May 2002 09:00, Gavin White wrote: > > Hello, > > > > I have some htb rules set up to govern download speeds through a linux > box, > > depending on the IP address of the destination machine. > > > > My problem is that when the end users choose to use my squid cache, which > > sits before the htb machine (and has to be there), the htb machine thinks > > the traffic is going to/from the squid box, so nullifying all my > bandwidth > > rules. > All squid traffic will have as source address the squid box, so you can''t > know who is doing what. But squid can also do bandwidth management. Take a > look at delay pools, > > Stef > > -- > > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net > > ************************************************************** > Scanned by MailScan Content-Security and Anti-Virus Software. > Visit http://www.mwti.net for more info on eScan and MailScan. > ************************************************************** > > > > ************************************************************** > Scanned by MailScan Content-Security and Anti-Virus Software. > Visit http://www.mwti.net for more info on eScan and MailScan. > ************************************************************** > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
I ''m working in project that consists in implementation of a multimedia extension over IP. I set up informations about MPEG Video on the IP option fields. I want to use this information , in the router side, to implemente a EPD (early packet discart) approche. The EPD approche consists in the following : -it is based on the data unit information, a data unit may be fragmentated into many IP packet (number of packet per data unit is varaible) - when we reatch a limit in the queue,we will reject a packet that belongs to a new unit and we accept only a packet that belong to an old unit (with is already enqueued) this approche, is taked from ATM world, : ip packet is fragmentated into many cell, then if we have to reject one cell we must do this for all cells that belong to the same packet (a unit here is a packet) my question is how can i used the traffic control implemented on linux to do that, i''m working with red hat 7.2 . if you have any idea, or you dindn''t understand me please send me a mail thanks in advance ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
I ''m working in project that consists in> implementation of a multimedia extension over IP. > I set up informations about MPEG Video on the IP > option fields. > I want to use this information , in the router side, > to implemente a EPD (early packet discart) approche. > The EPD approche consists in the following : > > -it is based on the data unit information, a data > unit > may be fragmentated into many IP packet (number of > packet per data unit is varaible) > - when we reatch a limit in the queue,we will reject > a > packet that belongs to a new unit and we accept only > a > packet that belong to an old unit (with is already > enqueued) > > this approche, is taked from ATM world, : ip packet > is > fragmentated into many cell, then if we have to > reject > one cell we must do this for all cells that belong > to > the same packet (a unit here is a packet) > > my question is how can i used the traffic control > implemented on linux to do that, i''m working with > red > hat 7.2 . > if you have any idea, or you dindn''t understand me > please send me a mail > > thanks in advance___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Wednesday 22 May 2002 10:43, you wrote:> I''ve seen patch to squid somewhere. The trick is to encode original > requester information into new request packets. It can go into > "priority" field - it is 32bit and is userspace-settable.That sounds exactly like the solution I''ve been looking for for about 3 months! Devik, could you possibly find out or give me a hint, where you''ve seen this patch? I am really interested in such a thing and I would be very grateful for everything someone knows about it.> I''m currently thinking about doing something like it but have no > time ...Unfortunataly I currently do not have the time to build it for myself as well. (I''m also sure that Devik would be way faster ;) Thanks, Andreas Lehrbaum
Andreas Lehrbaum wrote:> On Wednesday 22 May 2002 10:43, you wrote: > >>I''ve seen patch to squid somewhere. The trick is to encode original >>requester information into new request packets. It can go into >>"priority" field - it is 32bit and is userspace-settable. > > > That sounds exactly like the solution I''ve been looking for for about 3 > months! > > Devik, could you possibly find out or give me a hint, where you''ve seen this > patch? I am really interested in such a thing and I would be very grateful > for everything someone knows about it.i would be interested too, i thought about writing the same thing for myself as kind of acls, but if it already exists, even better ... bye, patrick
> On Wednesday 22 May 2002 10:43, you wrote: > > I''ve seen patch to squid somewhere. The trick is to encode original > > requester information into new request packets. It can go into > > "priority" field - it is 32bit and is userspace-settable. > > That sounds exactly like the solution I''ve been looking for for about 3 > months! > > Devik, could you possibly find out or give me a hint, where you''ve seen this > patch? I am really interested in such a thing and I would be very grateful > for everything someone knows about it.I think you should start search at squid page .. but I really can''t remember :(> > I''m currently thinking about doing something like it but have no > > time ... > > Unfortunataly I currently do not have the time to build it for myself as > well. (I''m also sure that Devik would be way faster ;)If someone is willing to spend $1000 I''ll write it ;-) devik
look at one simple qdisc (tbf, red) copy and extend to your algorithm ... On Wed, 22 May 2002, [iso-8859-1] alouini khalif wrote:> I ''m working in project that consists in > > implementation of a multimedia extension over IP. > > I set up informations about MPEG Video on the IP > > option fields. > > I want to use this information , in the router side, > > to implemente a EPD (early packet discart) approche. > > The EPD approche consists in the following : > > > > -it is based on the data unit information, a data > > unit > > may be fragmentated into many IP packet (number of > > packet per data unit is varaible) > > - when we reatch a limit in the queue,we will reject > > a > > packet that belongs to a new unit and we accept only > > a > > packet that belong to an old unit (with is already > > enqueued) > > > > this approche, is taked from ATM world, : ip packet > > is > > fragmentated into many cell, then if we have to > > reject > > one cell we must do this for all cells that belong > > to > > the same packet (a unit here is a packet) > > > > my question is how can i used the traffic control > > implemented on linux to do that, i''m working with > > red > > hat 7.2 . > > if you have any idea, or you dindn''t understand me > > please send me a mail > > > > thanks in advance > > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
Martin Devera wrote:>>On Wednesday 22 May 2002 10:43, you wrote: >> >>>I''ve seen patch to squid somewhere. The trick is to encode original >>>requester information into new request packets. It can go into >>>"priority" field - it is 32bit and is userspace-settable.In Squid 2.5 you have the possibility to set TOS field with acls. This also works by calling setsockopt on the socket, changing it to SO_PRIORITY should take very little time ..>> >>That sounds exactly like the solution I''ve been looking for for about 3 >>months! >> >>Devik, could you possibly find out or give me a hint, where you''ve seen this >>patch? I am really interested in such a thing and I would be very grateful >>for everything someone knows about it. > > > I think you should start search at squid page .. but I really > can''t remember :(>>>>I''m currently thinking about doing something like it but have no >>>time ... >> >>Unfortunataly I currently do not have the time to build it for myself as >>well. (I''m also sure that Devik would be way faster ;) > > If someone is willing to spend $1000 I''ll write it ;-)I''ll do it for a couple sixpacks of Ganther Bier (which releases enormous coding powers) ;) If no one volunteers, maybe i''ll also do it for free ... Bye Patrick
> Martin Devera wrote: > >>On Wednesday 22 May 2002 10:43, you wrote: > >> > >>>I''ve seen patch to squid somewhere. The trick is to encode original > >>>requester information into new request packets. It can go into > >>>"priority" field - it is 32bit and is userspace-settable. > > In Squid 2.5 you have the possibility to set TOS field with acls. > This also works by calling setsockopt on the socket, changing it to > SO_PRIORITY should take very little timethe only problem is that you will have to keep acls in sync with your tc setup. But it could be done. Also you can could read fw_mark (probably it can''t be done from userspace => patch needed) on incoming connection packets and set it on outgoing. If you then set nf_mark in ipchains/tables and use cls_fw then all should work transparently ..> > If someone is willing to spend $1000 I''ll write it ;-) > > I''ll do it for a couple sixpacks of Ganther Bier (which releases > enormous coding powers) ;) > If no one volunteers, maybe i''ll also do it for free ...some day someone will write it. I need it too so that probably I''ll spend some evening on it .. devik
Martin Devera wrote:>>Martin Devera wrote: >> >>>>On Wednesday 22 May 2002 10:43, you wrote: >>>> >>>> >>>>>I''ve seen patch to squid somewhere. The trick is to encode original >>>>>requester information into new request packets. It can go into >>>>>"priority" field - it is 32bit and is userspace-settable. >>>> >>In Squid 2.5 you have the possibility to set TOS field with acls. >>This also works by calling setsockopt on the socket, changing it to >>SO_PRIORITY should take very little time > > > the only problem is that you will have to keep acls in sync > with your tc setup. But it could be done. Also you can could read > fw_mark (probably it can''t be done from userspace => patch needed) > on incoming connection packets and set it on outgoing. > If you then set nf_mark in ipchains/tables and use cls_fw then > all should work transparently ..Although i like the idea and it would be more administrative overhead i would prefer the acl solution because probably more people would use it if you don''t need to patch the kernel .. also there would be better chances of getting included into the main squid tree.> some day someone will write it. I need it too so that probably > I''ll spend some evening on it ..Please tell me if you start on it so we don''t end up doing the same work twice .. Bye, Patrick