Hi All, We are doing traffic shaping with tc command of iproute2. With NATMAP our internal (Say)192.168.1.X class is mapped with routable 172.16.1.X class. We can successfully implement traffic shaping on either upload or download. We are using "red" scheduling and "fw" filter classifier for this. # /sbin/iptables -t nat -A PREROUTING -d 192.168.1.0/24 -j NETMAP \ --to 172.16.1.0/24 # /sbin/iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j NETMAP \ --to 192.168.1.0/24 To restrict Downloads: # /sbin/iptables t mangle I PREROUTING d 172.16.1.57 j MARK --set-mark 57 # /sbin/tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8 # /sbin/tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 cell 8 weight 10Mbit prio 8 maxburst 20 avpkt 1000 # /sbin/tc class add dev eth0 parent 10:1 classid 10:010 cbq bandwidth 100Mbit \ rate 120Kbit allot 1514 cell 8 weight 12Kbit prio 5 maxburst 20 avpkt 1000 bounded # /sbin/tc qdisc add dev eth0 parent 10:10 red max 12288 min 6100 limit 12288 \ avpkt 1000 burst 12 # /sbin/tc filter add dev eth0 parent 10:0 protocol ip prio 100 handle 57 fw classid 10:10 To restrict Uploads: # /sbin/iptables t mangle I PREROUTING s 192.168.1.57 j MARK --set-mark 57 # /sbin/tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8 # /sbin/tc class add dev eth1 parent 11:0 classid 11:1 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 cell 8 weight 10Mbit prio 8 maxburst 20 avpkt 1000 # /sbin/tc class add dev eth1 parent 11:1 classid 11:010 cbq bandwidth 100Mbit \ rate 120Kbit allot 1514 cell 8 weight 12Kbit prio 5 maxburst 20 avpkt 1000 bounded # /sbin/tc qdisc add dev eth1 parent 11:010 red max 12288 min 6100 limit 12288 \ avpkt 1000 burst 12 # /sbin/tc filter add dev eth1 parent 11:0 protocol ip prio 100 handle 57 fw classid 11:10 Though in Advance-Routing-HOWTO Section 9.1 its clearly stated that "With queueing we determine the way in which data is sent. It is important to realise that we can only shape data that we transmit". I wanted to work on setup someting describe below. Now instead of this 12Kbytes for individual upload and download; I want let user have total 12Kbytes; and sum of upload and download should not be more then this 12Kbytes. Is there any way to implementing traffic shaping over "from and to" an IP say 192.168.1.1? We did a little with "u32" classifier too. in that "match ip src" seems not work and/or work only while downloads and "match ip dst" works with uploads. Thanks for any support or hints. I''d like to even go for any beta-developmet going on this issue. Regards, -- Sumit
> Though in Advance-Routing-HOWTO Section 9.1 its clearly stated that "With > queueing we determine the way in which data is sent. It is important to > realise that we can only shape data that we transmit". I wanted to work on > setup someting describe below. > > Now instead of this 12Kbytes for individual upload and download; I want > let user have total 12Kbytes; and sum of upload and download should not be > more then this 12Kbytes. Is there any way to implementing traffic shaping > over "from and to" an IP say 192.168.1.1?Short answer : no The queues of device eth0 and eth1 have no idea of each other. This question is been asked before. Maybe you can dig in the archives to find more information about this toppic. Devik is developping something that can help you. It''s a virtual qdisc that holds all packets from all queues before they are queued in the real queue. From Devik : " It allows you to implement cross device bandwidth sharing.", just wat you need ;-) Stef> > We did a little with "u32" classifier too. in that "match ip src" seems > not work and/or work only while downloads and "match ip dst" works with > uploads. Thanks for any support or hints. I''d like to even go for any > beta-developmet going on this issue. > > Regards, > -- Sumit > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/-- stef.coene@docum.org More QOS info : http://docum.org/ Title : "Using Linux as bandwidth manager"
> Devik is developping something that can help you. It''s a virtual qdisc that > holds all packets from all queues before they are queued in the real queue. > From Devik : " It allows you to implement cross device bandwidth sharing.", > just wat you need ;-)precisely it is virtual network device. It can be used for two-way shaping and several people already uses it .. devik
On Wed, Dec 19, 2001 at 11:17:49AM +0100, Stef Coene wrote:> Devik is developping something that can help you. It''s a virtual qdisc that > holds all packets from all queues before they are queued in the real queue. > From Devik : " It allows you to implement cross device bandwidth sharing.", > just wat you need ;-)That''s good -- I''ve recently come across the need to do more than that though. In the situation where a proxy server is running on the Linux router which does the traffic controlling, I would like to be able to add the traffic going to the localhost for clients requesting web pages. I have no desire to shape traffic (severely) from the proxy servers to the clients (on eth1). But traffic from the Internet (eth0) to eth1 is usually shaped, except when they use the proxy server (which is encouraged). In that case, the proxy server requests traffic and sometimes overloads the incoming pipe. I know nothing can be done about this at this point (not in an intelligent way) but I was wondering if anyone is working on a user-space (or kernel-space for that matter) wholistic bandwidth manager (where interfaces are just a filtering option). -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/
>> Now instead of this 12Kbytes for individual upload and download; I want >> let user have total 12Kbytes; and sum of upload and download should not be >> more then this 12Kbytes. Is there any way to implementing traffic shaping >> over "from and to" an IP say 192.168.1.1?to shape traffic, you can also use an unofficial patch for netfilter (iptables), which does the same thing as the "limit" match, but allowing to specify rates in bytes/second instead of packets/second. you can get this patch from http://etudiant.univ-mlv.fr/~jpetazzo/bytelimit.tgz and you can then do something like : iptables -N lim1 iptables -A FORWARD -s 192.168.1.1 -j lim1 iptables -A FORWARD -d 192.168.1.1 -j lim1 iptables -A lim1 -m bytelimit --rate 12000 -j DROP (traffic "under" the 12000 bytes/second limit will go on thru the chain "lim1") Jerome Petazzoni <skaya at enix dot org>
Hi all, From: Stef Coene <stef.coene@docum.org>> Devik is developping something that can help you. It''s a virtual qdiscthat holds all packets from all queues before they are queued in the real queue. from Devik : " It allows you to implement cross device bandwidth sharing.",just wat you need ;-) May i know status of this devlopment? Can i''ve any version of this, i mean alpha/beta/devlopment/release? I also want basic as well as advance information about ingress and egress. I''m a frequent user of TC/CBQ/IPTABLES/IP but never knew about ingress/egress. Some links to the document where i can start all about. Thanks for taking time to write in. -- Sumit
> > Devik is developping something that can help you. It''s a virtual qdisc > > that holds all packets from all queues before they are queued in the real > queue. from Devik : " It allows you to implement cross device bandwidth > sharing.",just wat you need ;-) > > May i know status of this devlopment? Can i''ve any version of this, i mean > alpha/beta/devlopment/release?You can find more information on http://luxik.cdi.cz/~devik/qos/. There is only one relase, but it''s so simple, that are no bugs (according to Devik).> I also want basic as well as advance information about ingress and egress. > I''m a frequent user of TC/CBQ/IPTABLES/IP but never knew about > ingress/egress. Some links to the document where i can start all about.It''s simple. On the egress you can do everything you want. But on the ingress side, you are limit to the ingress qdisc. And that''s a qdisc that can do allmost nothing. But you can use the policy of filters to limit the bandwidth. I never tried it myself, but other people did. Stef -- stef.coene@docum.org More QOS info : http://docum.org/ Title : "Using Linux as bandwidth manager"
Hi Devik and All,>> You can find more information on http://luxik.cdi.cz/~devik/qos/. Thereis only one relase, but it''s so simple, that are no bugs (according to Devik). I want an architecturial/functional details of your "IMQ" development. The document on the link is insufficient to explain anything. If you can please get time to outline about every information about IMQ then I''m sure it will be going to useful to many peoples. It would be nice to go ahead with a case study also like HTB. Hey one more request for documentation. Its regarding HTB. Why its devloped and how its superb or advantagious against CBQ? Thanks. -- Sumit
On Tue, Dec 25, 2001 at 01:48:35PM +0530, Sumit Pandya wrote:> Hi Devik and All, > > >> You can find more information on http://luxik.cdi.cz/~devik/qos/. There > is only one relase, but it''s so simple, that are no bugs (according to > Devik). > I want an architecturial/functional details of your "IMQ" development.So you want that.> The document on the link is insufficient to explain anything. If you canYou may be insufficiently smart to grasp it. I seriously think you did not grap how open source works. This is *not* the way to participate! Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
Hey Bert, I''d like to go through detail of nice effort made by you peoples. As you answered, to use IMQ for my requirement, I placed this question. How did you answered is quite sarcastic to me. I feel that you forgot yourself as a good contributor of open-source. Otherwise there would be a warm support to test your development at one more place and feedback you. Oh yeah I confess that I''m a novice in open-source development but not newbie and very much experienced with Linux kernel network code. Which includes netfilter hack, some driver modification and detail understanding of Linux routing code... Anyway I''m not intended to describe my skills. I wont replace my request to you, infact this time loud against whatever I shown you for my contribution; ya simple but not trivial "a detail feedback". Thankx if you take some time off to write for me to go ahead task. -- Sumit -----Original Message----- From: bert hubert [mailto:ahu@ds9a.nl] Sent: Tuesday, December 25, 2001 5:51 PM To: Sumit Pandya Cc: lartc@mailman.ds9a.nl; devik@cdi.cz Subject: Re: Re: [LARTC] Re: Two-way Shared Traffic shaping and NAT On Tue, Dec 25, 2001 at 01:48:35PM +0530, Sumit Pandya wrote:> Hi Devik and All, > > >> You can find more information on http://luxik.cdi.cz/~devik/qos/.There> is only one relase, but it''s so simple, that are no bugs (according to > Devik). > I want an architecturial/functional details of your "IMQ"development. So you want that.> The document on the link is insufficient to explain anything. If you canYou may be insufficiently smart to grasp it. I seriously think you did not grap how open source works. This is *not* the way to participate! Regards, bert
On Tue, Dec 25, 2001 at 06:12:35PM +0530, Sumit Pandya wrote:> Hey Bert, > > I''d like to go through detail of nice effort made by you peoples. As you > answered, to use IMQ for my requirement, I placed this question. How did you > answered is quite sarcastic to me. I feel that you forgot yourself as a good > contributor of open-source. Otherwise there would be a warm support to test > your development at one more place and feedback you.It is a mistake that the open source world consists of saints. For it doesn''t. It''s like any other community in that it is a two way effort. You don''t go complaining to volunteers. If you find that something is lacking, your best action is to fix it. If unable to do so, the only thing left is to try to convince people who can rectify the problem to do so. Confronting them with your demands is not the way to do so - it is even insulting! Also, please not that I am not the HTB/IMQ developer. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
> > >> You can find more information on http://luxik.cdi.cz/~devik/qos/. There > > is only one relase, but it''s so simple, that are no bugs (according to > > Devik). > > I want an architecturial/functional details of your "IMQ" development. > > So you want that.Hehe .. yes. At least you (Sumit) should change "want" to "it could be nice" or similar :-)> > The document on the link is insufficient to explain anything. If you can > > You may be insufficiently smart to grasp it.Maybe I''d have to say something here. IIRC I''ve stated in the document that the IMQ is not documented well yet. There are two reasons for it. The first is that inner working of IMQ is so incredibly simple that one look at patch source code should be enough. The second one is that many developers do its open source work in their free time. When I write something I document it up to the level where smart techie can catch up. When some code/idea gets too popular then people often go and offers me help and ideas about documentation. Like Bert and Don in HTB case.> I seriously think you did not grap how open source works. This is *not* the > way to participate!And I have to agree here with Bert. If you want IMQ to be more documented then look at it try to write some decent help document and for such work I will answer all what you might need to do it. In fact when cooperating with Don I send him many kilobytes of answers :) Regards, devik
Michael T. Babcock
2001-Dec-25 14:39 UTC
Re: Re: Re: Two-way Shared Traffic shaping and NAT
On Tue, Dec 25, 2001 at 02:09:39PM +0100, bert hubert wrote:> On Tue, Dec 25, 2001 at 06:12:35PM +0530, Sumit Pandya wrote: > > I''d like to go through detail of nice effort made by you peoples. As you > > answered, to use IMQ for my requirement, I placed this question. How did youYou''ll probably find that many open source projects are documented in their source code. Did you download the IMQ source and read through it? If you''re not a programmer then a beta-quality project is not the place to hang out and you might want to wait until it is finished and fully documented for average-joe use. At that point, you will have your documentation. Of course, that point may never come, but feel free to pay a developer to do it for you.> > answered is quite sarcastic to me. I feel that you forgot yourself as a good > > contributor of open-source. Otherwise there would be a warm support to test > > your development at one more place and feedback you. > > It is a mistake that the open source world consists of saints.Mmm ... Linus Torvalds ... the least sarcastic person in the world ... :-P> Also, please not that I am not the HTB/IMQ developer.Bert''s just the guy who freely develops a fairly high quality FAQ and HOWTO w.r.t. the advanced routing & traffic control features of Linux. I''ve given him a hard time about that before, but I wouldn''t tell him to document something unless he wanted to (maybe as a suggestion ;-). -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/