From filip.sneppe@chello.be Mon Jul 1 01:14:22 2002 From: filip.sneppe@chello.be (Filip Sneppe) Date: 01 Jul 2002 02:14:22 +0200 Subject: [LARTC] advanced routing for traffic generator-like setup Message-ID: <1025482462.638.9.camel@exile> Hi, Given the following two variations of the same setup: HostA ------------------ HostB eth0: eth0: 1.1.1.1/24 1.1.1.2/24 2.2.2.1/24 2.2.2.2/24 and: HostA HostB eth0:1.1.1.1/24 ------------ eth0:1.1.1.2/24 eth1:2.2.2.1/24 ------------ eth1:2.2.2.2/24 (basically same setup but with two NICs on each host) How does one set up advanced routing so that when HostA sends a packet from 1.1.1.1 to 2.2.2.1, it goes via HostB, and vice versa: a packet from 2.2.2.1 to 1.1.1.1 also goes via HostB. This setup would allow me to do traffic-generator/ troughput-like tests when HostB is a low-end machine. I have been fiddling around with ip route/ip rule, but the biggest problem I seem te be having is that when I change/delete an entry from the local table, HostA no longer replies to ARP queries on the wire. Thanks in advance, Filip From fineberg@aviating.com Mon Jul 1 04:05:43 2002 From: fineberg@aviating.com (Adam B. Fineberg) Date: Sun, 30 Jun 2002 20:05:43 -0700 Subject: [LARTC] how to filter based upon MAC Message-ID: <3D1FC707.5040102@aviating.com> It isn't obvious to me from the lartc howto or frmo the tc source how to set a filter to send all traffic destined for a specified MAC to a particular class. Any suggestions would be appreciated. Best regards, Adam Fineberg fineberg@aviating.com From arc_of_descent@gmx.net Mon Jul 1 07:45:46 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Mon, 1 Jul 2002 12:15:46 +0530 Subject: [LARTC] how to filter based upon MAC In-Reply-To: <3D1FC707.5040102@aviating.com> References: <3D1FC707.5040102@aviating.com> Message-ID: <02070112154600.01252@sanitarium> Adam B. Fineberg wrote: > It isn't obvious to me from the lartc howto or frmo the tc source how to > set a filter to send all traffic destined for a specified MAC to a > particular class. Any suggestions would be appreciated. Hi, I hardly think it is possible to send traffic for MAC address to a particular class. I had tried it myself and failed miserably. It all started when i wanted to control the "upload" traffic on my LAN. I found out (from the lartc HOWTO) ,that you could mark packets using iptables based on the MAC source for incoming packets, on an incoming interface. Then we send these marked packets to a destined class on the outgoing interface. The basic problem is that you can only mark packets based on MAC for packets coming from an ethernet device. -- arc_of_descent From devik@cdi.cz Mon Jul 1 08:12:22 2002 From: devik@cdi.cz (Martin Devera) Date: Mon, 1 Jul 2002 09:12:22 +0200 (CEST) Subject: [LARTC] HTB stats In-Reply-To: <20020630113108.12544DC349@tartarus.telenet-ops.be> References: <3D1A3570.7080108@dg.net.ua> <20020627182446.17781DCC91@tartarus.telenet-ops.be> <3D1EC160.9080803@dg.net.ua> <20020630113108.12544DC349@tartarus.telenet-ops.be> Message-ID: > > >>1. why do I have "lended" for children classes almost the same as > > >>"sent", who do they lend to? the neighboring classes? > > >Yes, to other classes. > > >"lended is # of packets donated by this class (from its rate)" > > I did some experimenting, and had a root class and just 1 child class, > > and this child class still had lended pkts to smbody. Who did it lend it > > to? > Can you send me your script so I know the settings of rate and ceil ? Or > maybe Devik knows the answer. leaf class also "lends" to itself ... > > >overlimits : Packet is not sended due to ceil or rate restrictions So > > > there was to much data in the class. But don't believe this too much. > > > It depends on how often the qdisc looked for packet. > > > > What does "looked" mean? could you pleases explain it a bit more? How > > does it look for a pkt? I`m very interested in finding out what that > > value means. > I quoted it from Devik, he his also reading this list, so Devik, can clear > this out. It is incremented per unsucessfull DRR loop. > > >Between what? > > Between "overlimits" and "dropped" > If the packet is overlimit, it can also be delayed to be send later. overlimits >> dropped. It is because for each drop there is overlimit but there is more overlimits (see prev. paragraph). devik From ganesh kumar godavari" hello group, i just want to know, if i can do some priority based routing for voice packets, send from my machine? can any one tell me how can that be done? thanks ganesh _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.com/rediffin/ From arthurvl@sci.kun.nl Mon Jul 1 09:05:40 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Mon, 1 Jul 2002 10:05:40 +0200 (MEST) Subject: [LARTC] [OT]: rtt measurement using tcp timestamps from a MITM position In-Reply-To: <3D1C6B1B.5000700@trash.net> Message-ID: On Fri, 28 Jun 2002, Patrick McHardy wrote: > Arthur van Leeuwen wrote: > > > > >On Fri, 28 Jun 2002, Patrick McHardy wrote: > > > >>Hi Arthur, [snip, RTT estimation from router] > >>I hope i got you right, you mean i should calculate the difference > >>between my clock and the first timestamp of a session, then > >>send my own and on reply substract the clock-skew again ? > >> > > > >No, that is active intervention again. I meant to *remember* the value of > >your clock and the last seen RTTM field for a session, and then when > >the corresponding ack returns use that remembered value as opposed to the > >the value in the RTTM field for your round-trip time calculation. > > > >>>per TCP stream, and tracking of all active TCP streams running through your > >>>machine. However, the latter is probably necessary *anyway* if you are > >>>going to do rate control, as you're bound to want to store the windowsizes > >>>and stuff related to each TCP stream separately. > >>> > > > >>Yes connection tracking is necessary (and already working fine :) > >> > > > >Well, what you do then is (in pseudocode): > > > > if packet contains RTTM field: > > if packet is SYN: > > remember local time (RTTM value, TCP stream) > > send packet on > > else: > > lookup local time for (TCP stream, RTTM value) > > calculate round-trip with local time > > else: > > do whatever you like > > > >Thereby you merely use the value in the RTTM field as a key to a set of > >stored local clockvalues. Yes, this will break if the value in the RTTM does > >not monotonically increase, but... that increase *is* guaranteed by the RFC. > hmm i suppose with "if packet is SYN" you mean "if packet contains new > data", right ? Well, I mean `if packet contains new RTTM timestamp'. However, I didn't think this through all that well: you want to store the last seen RTTM field in each direction of a TCP stream. > the reason i came up with this is i want to avoid storing lots of > timestamps/myclock pairs, You'll have to store 2 per TCP stream, one for each direction. > the number i would need to store depends on how many packets fit in the > current window, No. You only need to store the one for each window. Thus, upon store, have a counter count acks, and remember the new RTTM field only when the counter drops below the number of packets that fit in the window. Although round-trip-time may vary per packet, the approximation is probably still good enough. > so for bigger windows i would have to remember lots of values. > Remebering only the first one wouldn't work because i had to rely on the > remote clock to increase excactly as fast as mine. Why? The remote clock doesn't do *anything* to the RTTM field. As I read the RFC a host has to copy the RTTM field back verbatim into the ACK to the packet that contained it... as such, you *only* rely on your own clock to measure roundtrip time. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From raheesom@awr.org Mon Jul 1 09:29:30 2002 From: raheesom@awr.org (Rupert Heesom) Date: Mon, 1 Jul 2002 09:29:30 +0100 Subject: [LARTC] Is it possible to measure / graph the bandwidth used for individual IP sessions to an FTP server? Message-ID: <000201c220d9$6cafae40$0a00a8c0@MATRIX> This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C220E1.CE759CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My office has an FTP server which is used by various "satellite sites" = to upload files to us. As part of the management of my local network & auditing network = resources, I want to try & measure (and hopefully) graph [like MRTG] the bandwidth = used by individual FTP upload connections (assuming each file being uploaded = only uses one connection). I am wondering whether it's possible to do this using Linux?? Regs Rupert Heesom Asst Distribution Engineer Adventist World Radio ------=_NextPart_000_0003_01C220E1.CE759CE0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IiAIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHBgAeABEAKwAAAAAAOQEB A5AGAKAGAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAYgAAAElzIGl0IHBvc3NpYmxlIHRvIG1lYXN1cmUgLyBncmFwaCB0aGUgYmFuZHdpZHRoIHVz ZWQgZm9yIGluZGl2aWR1YWwgSVAgc2Vzc2lvbnMgdG8gYW4gRlRQIHNlcnZlcj8AAAACAXEAAQAA ABYAAAABwiBVP1ZQMUgr1StA1ZAlIoNcDi+JAAACAR0MAQAAABYAAABTTVRQOlJBSEVFU09NQEFX Ui5PUkcAAAALAAEOAAAAAEAABg4AwtIxVSDCAQIBCg4BAAAAGAAAAAAAAACePoZDSZm7SqR2pI3Z lXVFwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAAEMCAAA/AgAAuQIAAExaRnXe0GRsAwAKAHJj cGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgJ0AACoJsAnwBJBhdAWx GlIN4GgJgAHQIDUuADQwLjExLjIykw9AAoBcdgiQd2sLgPRkNAxgYwBQCwMLtQXQmHkgbwEgDeBl IBDwQwQgA5FGVFAgESByonYEkCB3aBMBIAQARCB1ESBkIGIWMHZNCsBpCGAEICJzEqBlOGxsaRmg F2AZ4XMiziASsBhgC1BvYRigFnDmbAeRGpJzLgqiCoQKgH5BBCAKsQVAFlAagBMgIL0DgWESUAeA AjAdIm0WMJUJAGMHQCAScHR3BbDIayAmFvB1ZBngC4A2Zx8HCXBzCGEWkHMsPCBJF9AAcAVAGpF0 cr8WMB+QB4AW0AhwFqAoAHBRGKBob3ABEHUZwHmkKSAJwGFwGCBbGdCCaxagTVJUR10dU3ZiIwED 8GQdYBhnFMFpeRRwZHUe4RcyGsUFoG59EnBjH/ACIAQgIvAEEHW+bSACIoAYERsyGLBlIAL/GsQY kQIgI7AYYgQgAiAWoM0n2Ckb6yFwYW0X0AIgfwSBIAIX4BEwEyAFwBngJ3UcwW8EEGkCYBagGpFk LyHxF/AYUiACTAuAdXicPz8b+grzB/BlZxCw3RwDUhrABJAFQEgJ4CDg6m0cVnMFQEQEACIQLyBy dSgyIEUPIAuACeBynRxVZBegAjA0QSBXBbB+bDHxGwAZIDFZG/QR4QABOIAAAwDeP59OAAADAAlZ AwAAAAMAQGUAAAAACwATgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADACeACCAGAAAAAADA AAAAAAAARgAAAAABhQAAAAAAAAMANIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwBXgAgg BgAAAAAAwAAAAAAAAEYAAAAAUoUAAOOQAQAeAGqACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAA AAUAAAAxMC4wAAAAAAsAa4AIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwBvgAggBgAAAAAA wAAAAAAAAEYAAAAADoUAAAAAAAADAHKACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAiYAI IAYAAAAAAMAAAAAAAABGAAAAAIKFAAAAAAAAAgH4DwEAAAAQAAAAnj6GQ0mZu0qkdqSN2ZV1RQIB +g8BAAAAEAAAAJ4+hkNJmbtKpHakjdmVdUUCAfsPAQAAAJwAAAAAAAAAOKG7EAXlEBqhuwgAKypW wgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGlu Z3NcUnVwZXJ0IEhlZXNvbVxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29m dFxPdXRsb29rXE91dGxvb2sxLnBzdAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAATklUQfm/ uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwOUUzRTg2NDM0OTk5QkI0QUE0NzZBNDhERDk5 NTc1NDVDNDdBMjgwMAAAAAADAAYQa8JXcwMABxCIAQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAA ZQAAAE1ZT0ZGSUNFSEFTQU5GVFBTRVJWRVJXSElDSElTVVNFREJZVkFSSU9VUyJTQVRFTExJVEVT SVRFUyJUT1VQTE9BREZJTEVTVE9VU0FTUEFSVE9GVEhFTUFOQUdFTUVOVE9GTVkAAAAAFow= ------=_NextPart_000_0003_01C220E1.CE759CE0-- From tobias.geiger@web.de Mon Jul 1 10:10:30 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Mon, 1 Jul 2002 11:10:30 +0200 (CEST) Subject: [LARTC] Is it possible to measure / graph the bandwidth used for individual IP sessions to an FTP server? In-Reply-To: <000201c220d9$6cafae40$0a00a8c0@MATRIX> References: <000201c220d9$6cafae40$0a00a8c0@MATRIX> Message-ID: <55867.212.2.37.233.1025514630.squirrel@kaeptnb.d2g.com> Hi. Hm. accounting each ftp-session separately sounds impossible (for me :), but with ipac (-ng) @sourceforge.net it's possible to feed mrtg.So you can at least measure and graph the TOTAL ammount of (ftp-)traffic to/from your ftp-server. to measure and graph each ftp-session seperately u can try to find a tool which evaluates /var/log/xferlog, assuming your ftp-server writes such a log-file (e.g. with modlogan) Greetings Tobias > My office has an FTP server which is used by various "satellite sites" > to upload files to us. > > As part of the management of my local network & auditing network > resources, I want to try & measure (and hopefully) graph [like MRTG] > the bandwidth used by individual FTP upload connections (assuming each > file being uploaded only uses one connection). > > I am wondering whether it's possible to do this using Linux?? > > Regs > Rupert Heesom > Asst Distribution Engineer > Adventist World Radio From hxgang@csnet4.cs.tsinghua.edu.cn Mon Jul 1 10:54:11 2002 From: hxgang@csnet4.cs.tsinghua.edu.cn (Huang Xin Gang) Date: Mon, 1 Jul 2002 17:54:11 +0800 Subject: [LARTC] what's the meaning of macro "TC_U32_NODE()" Message-ID: <200207010849.QAA01721@csnet4.cs.tsinghua.edu.cn> TEFSVEOjrGhlbGxvo6ENCg0KSSBhbSByZWFkaW5nIHRoZSBVMzIgZmlsdGVyJ3MgY29kZSAsYnV0 IEkgY2FuJ3QgdW5kZXJzdGFuZCB0aGlzIG1hY3JvLiB3aG8gY2FuIGhlbHAgbWU/DQoNClRoZSBt YWNybyBpcyBkZWZpbmVkIGluIGluY2x1ZGUvbGludXgvcGt0X2Nscy5oLg0KDQpUaGFua3MNCg0K oaGhoaGhYmVzdCByZWdhcmRzIQ0KDQogCQkJCQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh oUh1YW5nIFhpbiBHYW5nDQqhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhaHhnYW5nQGNzbmV0 NC5jcy50c2luZ2h1YS5lZHUuY24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaEy MDAyLTA3LTAxDQo= From stef.coene@docum.org Mon Jul 1 11:13:47 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 1 Jul 2002 12:13:47 +0200 Subject: [LARTC] how to filter based upon MAC In-Reply-To: <3D1FC707.5040102@aviating.com> References: <3D1FC707.5040102@aviating.com> Message-ID: On Monday 01 July 2002 05:05, Adam B. Fineberg wrote: > It isn't obvious to me from the lartc howto or frmo the tc source how t= o > set a filter to send all traffic destined for a specified MAC to a > particular class. Any suggestions would be appreciated. I'm not sure, but can iptables mark packets based on Max address? If yes= ,=20 you can use the fw filter to put the marked packets in a class. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Mon Jul 1 11:16:58 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 1 Jul 2002 12:16:58 +0200 Subject: [LARTC] priority for voip In-Reply-To: <20020701075750.20880.qmail@webmail7.rediffmail.com> References: <20020701075750.20880.qmail@webmail7.rediffmail.com> Message-ID: On Monday 01 July 2002 09:57, ganesh kumar godavari wrote: > hello group, > i just want to know, if i can do some priority based routing for > voice packets, send from my machine? Yes you can. > can any one tell me how can that be done? www.lartc.org www.docum.org The archive of this list. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From jwickman@tawi.fi Mon Jul 1 13:40:23 2002 From: jwickman@tawi.fi (Joachim Wickman) Date: Mon, 1 Jul 2002 15:40:23 +0300 Subject: [LARTC] Hammer protection References: Message-ID: <006801c220fc$79605900$0c01a8c0@jokke> Hi, Is it possible to use iptables as hammeprotection ? I want to deny a user who has just logged off .. for about 10seconds. I tried with this, but that didn't work. Maybe my mind is going = completely in the wrong direction today? =3D) iptables -I INPUT -i eth0 -p tcp -s 0/0 -d $my_ip --dport 21 -m limit = --limit 10/second --limit-burst 1 --tcp-flags ALL SYN -j ACCEPT Greetings, Joachim From tobias.geiger@web.de Mon Jul 1 14:00:16 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Mon, 1 Jul 2002 15:00:16 +0200 (CEST) Subject: [LARTC] Hammer protection In-Reply-To: <006801c220fc$79605900$0c01a8c0@jokke> References: <006801c220fc$79605900$0c01a8c0@jokke> Message-ID: <40620.212.2.37.233.1025528416.squirrel@kaeptnb.d2g.com> > Hi, > > Is it possible to use iptables as hammeprotection ? > > I want to deny a user who has just logged off .. for about 10seconds. > i think this is a application-logic-thing which can't be implemented that easy only by one iptables-line > I tried with this, but that didn't work. Maybe my mind is going > completely in the wrong direction today? =) > > iptables -I INPUT -i eth0 -p tcp -s 0/0 -d $my_ip --dport 21 -m limit > --limit 10/second --limit-burst 1 --tcp-flags ALL SYN -j ACCEPT > this rule blocks (afaik) every request after the 10th/second, no matter s.o logged off or on ... i think what u want must be done on application-level or with an "magic) (and dirty) script which watches the ftp-log if s.o loggs off, grep's it's ip and then blocks it for 10 seconds but that not only sounds ugly :) > Greetings, > > Joachim > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From pape@rbg.informatik.tu-darmstadt.de Mon Jul 1 18:51:06 2002 From: pape@rbg.informatik.tu-darmstadt.de (Sebastian 'spax' Pape) Date: Mon, 1 Jul 2002 19:51:06 +0200 (MET DST) Subject: [LARTC] Hammer protection In-Reply-To: <006801c220fc$79605900$0c01a8c0@jokke> Message-ID: hi Joachim, > I want to deny a user who has just logged off .. for about > 10seconds. I think you can only limit the number of syn-pakets like you already proposed. > I tried with this, but that didn't work. Maybe my mind is going > completely in the wrong direction today? =) > > iptables -I INPUT -i eth0 -p tcp -s 0/0 -d $my_ip --dport 21 -m > limit --limit 10/second --limit-burst 1 --tcp-flags ALL SYN -j > ACCEPT I'm not sure, but I think you just mixed the parameters up. --limit 10/second allows 10 SYN pakets per second so if you only want one paket per 10 seconds you should perhaps try 6/minute or maybe say 1/minute and set the limit-bust to 3 or so. best regards Sebastian -- Sebastian 'spax' Pape | I'm like time ... u can't stop me! mailto: sebastian@p-a-p-e.de | gpg: http://p-a-p-e.de/gpg.asc | --- Do you want to know more? http://www.p-a-p-e.de/ --- From ganesh kumar godavari" hai stef, i looked into your docum.org and lartc.org. for information on giving high priority for voice packets. i did check with the netfilter group for information on identifying if a packet is a voice/data packet. i received no response from them. so can u please tell me how i can identify if a packet is a voice/data packet so that i can mangle it and send to high priority queue. thanks ganesh On Mon, 01 Jul 2002 Stef Coene wrote : >On Monday 01 July 2002 09:57, ganesh kumar godavari wrote: > > hello group, > > i just want to know, if i can do some priority based routing >for > > voice packets, send from my machine? >Yes you can. > > > can any one tell me how can that be done? >www.lartc.org >www.docum.org >The archive of this list. > >Stef > >-- > >stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: >http://lartc.org/ _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.com/rediffin/ From stef.coene@docum.org Mon Jul 1 20:34:02 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 1 Jul 2002 21:34:02 +0200 Subject: [LARTC] priority for voip In-Reply-To: <20020701191256.12066.qmail@webmail6.rediffmail.com> References: <20020701191256.12066.qmail@webmail6.rediffmail.com> Message-ID: <20020701193402.F1D18DC9D2@tartarus.telenet-ops.be> On Monday 01 July 2002 21:12, ganesh kumar godavari wrote: > hai stef, > i looked into your docum.org and lartc.org. for information on > giving high priority for voice packets. > i did check with the netfilter group for information on > identifying if a packet is a voice/data packet. > > i received no response from them. so can u please tell me how i > can identify if a packet is a voice/data packet so that i can > mangle it and send to high priority queue. I have no idea how you can identify voip packets. Is it using a fixed ds= t=20 port of maybe host so you can use that in the filter? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From jwickman@tawi.fi Mon Jul 1 21:12:03 2002 From: jwickman@tawi.fi (Joachim Wickman) Date: Mon, 1 Jul 2002 23:12:03 +0300 Subject: [LARTC] Hammer protection References: Message-ID: <001301c2213b$917646f0$01000001@floppe> Hi > I think you can only limit the number of syn-pakets like you already > proposed. I tried to switch the params as you said, but no success. It took maybe a minute before I did get in to the site, but after that I could logout and in as fast as I wanted. (hammering) Mabye the only way is the dirty scriptin to fetch the IP from the log then :/ // Joachim From Gareth.Segree@gleanerjm.com Mon Jul 1 21:14:38 2002 From: Gareth.Segree@gleanerjm.com (Segree, Gareth) Date: Mon, 1 Jul 2002 15:14:38 -0500 Subject: [LARTC] seeming simple routing problem Message-ID: <706F7FF7ADC24C4E9299261CA739A51F066C5F@COMMSRV04.gleanerjm.com> I have a server 128.187.2.0/16 and 128.187.1.0/16 that was setup by a vendor. I have a host on 128.187.2.1 and 128.187.1.1 side with the following eth1: 128.187.3.1/24 and eth2: 128.187.4.1/24 each side to talk to the other in the event that one of the network card goes down. I have a firewall setup like the following. eth1: 128.187.3.1/24 and eth2: 128.187.4.1/24 - with clients on each side of the lan with default gateway being the interface that it is connected to. The 128.187.2.1 is on the hub that eth2 is connected to and 128.187.1.1 is on the hub that eth1 is connected to. I have done the following: echo 1 > /proc/sys/net/ipv4/ip_forward ip route replace 128.187.1.1 dev eth1 ip route replace 128.187.2.1 dev eth2 >From the firewall I can ping 128.187.1.1 & 128.187.2.1. clients from the 128.187.3.0 side can't ping 128.187.2.1 and clients from the 128.187.4.0 side can't ping 128.187.1.1. How can I allow hosts on the eth1: 128.187.3.1/24 to ping 128.187.2.1 and hosts on eth2: 128.187.4.1/24 to ping 128.187.1.1. Thanks in Advance. From ganesh kumar godavari" hello stef, this is the information i got from microsoft website (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q158623) *************************** NetMeeting uses the following Internet Protocol (IP) ports: Port Purpose ------------------------------------- 389 Internet Locator Server [Transmission Control Protocol (TCP)] 522 User Location Server (TCP) 1503 T.120 (TCP) 1720 H.323 call setup (TCP) 1731 Audio call control (TCP) Dynamic H.323 call control (TCP) Dynamic H.323 streaming [Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP)] To establish outbound NetMeeting connections through a firewall, the firewall must be configured to do the following: Pass through primary TCP connections on ports 522, 389, 1503, 1720 and 1731. Pass through secondary UDP connections on dynamically assigned ports (1024-65535). ******************************* so as u can see there is no way of determining the port if it were dynamic any pointers in this regard would be helpful thanks ganesh On Tue, 02 Jul 2002 Stef Coene wrote : >On Monday 01 July 2002 21:12, ganesh kumar godavari wrote: > > hai stef, > > i looked into your docum.org and lartc.org. for information >on > > giving high priority for voice packets. > > i did check with the netfilter group for information on > > identifying if a packet is a voice/data packet. > > > > i received no response from them. so can u please tell me how >i > > can identify if a packet is a voice/data packet so that i >can > > mangle it and send to high priority queue. >I have no idea how you can identify voip packets. Is it using a >fixed dst >port of maybe host so you can use that in the filter? > >Stef > >-- > >stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.com/rediffin/ From ganesh kumar godavari" hello stef, this is the information i got from microsoft website (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q158623) *************************** NetMeeting uses the following Internet Protocol (IP) ports: Port Purpose ------------------------------------- 389 Internet Locator Server [Transmission Control Protocol (TCP)] 522 User Location Server (TCP) 1503 T.120 (TCP) 1720 H.323 call setup (TCP) 1731 Audio call control (TCP) Dynamic H.323 call control (TCP) Dynamic H.323 streaming [Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP)] To establish outbound NetMeeting connections through a firewall, the firewall must be configured to do the following: Pass through primary TCP connections on ports 522, 389, 1503, 1720 and 1731. Pass through secondary UDP connections on dynamically assigned ports (1024-65535). ******************************* so as u can see there is no way of determining the port if it were dynamic any pointers in this regard would be helpful thanks ganesh On Tue, 02 Jul 2002 Stef Coene wrote : >On Monday 01 July 2002 21:12, ganesh kumar godavari wrote: > > hai stef, > > i looked into your docum.org and lartc.org. for information >on > > giving high priority for voice packets. > > i did check with the netfilter group for information on > > identifying if a packet is a voice/data packet. > > > > i received no response from them. so can u please tell me how >i > > can identify if a packet is a voice/data packet so that i >can > > mangle it and send to high priority queue. >I have no idea how you can identify voip packets. Is it using a >fixed dst >port of maybe host so you can use that in the filter? > >Stef > >-- > >stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.com/rediffin/ From ganesh kumar godavari" hello group, i want to know if there is any way i can determine using iptables if the ip packet contains voice? i want to know this as i want to do some queuing for output packets and the voice packets are given high preference next ftp,telnet,ssh..... i want to know if this is possible using iptables and tc. if so how. if i can identify the packet to be voice then i can do the rest using tc. thanks ganesh _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.com/rediffin/ From n5jxs@tamu.edu Tue Jul 2 04:31:44 2002 From: n5jxs@tamu.edu (Gerry Creager N5JXS) Date: Mon, 01 Jul 2002 22:31:44 -0500 Subject: [LARTC] voice based queuing References: <20020702030957.9597.qmail@webmail30.rediffmail.com> Message-ID: <3D211EA0.2070408@tamu.edu> ganesh kumar godavari wrote: > hello group, > > i want to know if there is any way i can determine using iptables if > the ip packet contains voice? > > i want to know this as i want to do some queuing for output packets and > the voice packets are given high preference next ftp,telnet,ssh..... > > > i want to know if this is possible using iptables and tc. if so how. if > i can identify the packet to be voice then i can do the rest using tc. I've followed (from afar, things are busy) your quest. The issues are several. 1. The ports used, except for setup, are dynamic, as the Microsoft page told you (although NetMeeting is hardly a good example of a compliant H.323 app). 2. You can do stateful inspection of headers and have a good shot at finding RTP and RTCP packets, and then mark those. Where you probably need to go is toward marking all from the H.323 hosts. You will need to spend some time with TOS/DiffServ, and 802.1p. Also, be aware that if you do not have priority queuing from endpoint to endpoint (also known as E2E) you will not see an appreciable improvement in handling. We are engaged in a couple of efforts to identify Voice and Video Over IP, and mark it for priority queuing on our campus. Cisco has a nice simple strategy they're apparently trying to make a "standard" but it's at odds with diffserv marking. If you go with the Cisco markings, and you enable your queue disciplines based on the markings, _throughout_the_entire_network_ then you may see some improvement. Can you di this with LARTC, yes, I believe so. Sorry I cannot be more certain, but while it's on my list to test, I'm still a bit busy... The trick is getting the appropriate packets marked properly at the edge, rather than trying to mark them at the core. And why, one might ask, is this so? Well, we see a lot of congestion at the edge in wiring closet aggregation switches. If these switches cannot handle priority queuing AND they experience periods (even short ones) of congestion, then most of the effort you're going to is for naught. Gerry Creager network Engineering AATLT, Texas A&M University College Station, Texas From jeremy@thepulsegroup.net Tue Jul 2 04:30:45 2002 From: jeremy@thepulsegroup.net (Jeremy Nelson) Date: Tue, 2 Jul 2002 13:30:45 +1000 Subject: [LARTC] tc filter protocol 47 issues Message-ID: <21CFAEE4AD228C41B78FDEBA4C82B774227B@luci.thepulsegroup.net> Hi Group.... Im trying to use tc to filter GRE (protocol 47) traffic. I have all my = classes under one parent. I have all my qdiscs and classes setup. When I use tc to filter GRE traffic it seems to work ok but as soon as I = then try to filter IP traffic I get "Invalid argument" See below [root@scabeek rc.d]# tc filter add dev eth0 protocol 47 parent 1:0 prio = 1 u32 match ip src 192.168.97.245 flowid 1:30 [root@scabeek rc.d]# tc filter add dev eth0 protocol ip parent 1:0 prio = 1 u32 match ip sport 80 0xffff flowid 1:10 RTNETLINK answers: Invalid argument If I then delete all tc filters and then I add the IP tc filter first = and it is ok. I then try to add the GRE filter and again I get the = "Invalid argument"=20 See below [root@scabeek rc.d]# tc filter add dev eth0 protocol ip parent 1:0 prio = 1 u32 match ip sport 80 0xffff flowid 1:10 [root@scabeek rc.d]# tc filter add dev eth0 protocol 47 parent 1:0 prio = 1 u32 match ip src 192.168.97.245 flowid 1:30 RTNETLINK answers: Invalid argument Can I filter both IP and GRE traffic or are they incompatible within tc = ?? Cheers Jeremy From alexey_talikov@texlab.com.uz Tue Jul 2 06:06:48 2002 From: alexey_talikov@texlab.com.uz (Alexey Talikov) Date: Tue, 02 Jul 2002 10:06:48 +0500 Subject: [LARTC] tc filter protocol 47 issues In-Reply-To: <21CFAEE4AD228C41B78FDEBA4C82B774227B@luci.thepulsegroup.net> Message-ID: <2Y0476PKOKEDDQN6YT86GEHC62XHE.3d2134e8@ALEXEY> tc filter add dev eth0 parent 1:0 prio 1 u32 match protocol ip 0x2f 0xff flowid 1:30 0x2f=47 (gre) ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From jeremy@thepulsegroup.net Tue Jul 2 07:33:42 2002 From: jeremy@thepulsegroup.net (Jeremy Nelson) Date: Tue, 2 Jul 2002 16:33:42 +1000 Subject: [LARTC] tc filter protocol 47 issues Message-ID: <21CFAEE4AD228C41B78FDEBA4C82B774227D@luci.thepulsegroup.net> I gave that a go but come up with Illegal "match" and unfortunatly the tc-filter man pages are still forthcoming > -----Original Message----- > From: Alexey Talikov [mailto:alexey_talikov@texlab.com.uz] > Sent: Tuesday, 2 July 2002 3:07 PM > To: LARTC mailing list (E-mail); Jeremy Nelson > Subject: Re: [LARTC] tc filter protocol 47 issues >=20 >=20 > tc filter add dev eth0 parent 1:0 prio 1 u32 match protocol=20 > ip 0x2f 0xff flowid 1:30 >=20 > 0x2f=3D47 (gre) > ----------------------------------- > mailto:alexey_talikov@texlab.com.uz > BR > Alexey Talikov > FORTEK > ----------------------------------- >=20 >=20 >=20 From alexey_talikov@texlab.com.uz Tue Jul 2 08:41:21 2002 From: alexey_talikov@texlab.com.uz (Alexey Talikov) Date: Tue, 02 Jul 2002 12:41:21 +0500 Subject: [LARTC] tc filter protocol 47 issues In-Reply-To: <21CFAEE4AD228C41B78FDEBA4C82B774227D@luci.thepulsegroup.net> Message-ID: Sorry my error, change words "ip" and "protocol" after match tc filter add dev eth0 parent 1:0 prio 1 u32 match ip protocol 0x2f 0xff flowid 1:30 02.07.2002 11:33:42, "Jeremy Nelson" wrote: >I gave that a go but come up with Illegal "match" >and unfortunatly the tc-filter man pages are still forthcoming > > >> -----Original Message----- >> From: Alexey Talikov [mailto:alexey_talikov@texlab.com.uz] >> Sent: Tuesday, 2 July 2002 3:07 PM >> To: LARTC mailing list (E-mail); Jeremy Nelson >> Subject: Re: [LARTC] tc filter protocol 47 issues >> >> >> tc filter add dev eth0 parent 1:0 prio 1 u32 match protocol >> ip 0x2f 0xff flowid 1:30 >> >> 0x2f=47 (gre) >> ----------------------------------- >> mailto:alexey_talikov@texlab.com.uz >> BR >> Alexey Talikov >> FORTEK >> ----------------------------------- >> >> >> > ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From arc_of_descent@gmx.net Tue Jul 2 10:09:01 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Tue, 2 Jul 2002 14:39:01 +0530 Subject: [LARTC] burstable with tc Message-ID: <02070214390101.01380@sanitarium> Hi, Is it possible to avail of burstable option while controlling bandwidth using tc? Let me explain.. :-) I could successfully allocate an ip(or class) a certain bandwdith limit, and without giving a bounded parameter, it borrowed bandwidth when available. But i also want an upper limit. Cause, the lower limit works fine. ie. when there are other ips online, this particular ip does not go above the lower limit. Once the other ips go offlline, this particular ip starts borrowing all the "available" bandwdith. "available" is the key word here, After it starts borrowing bandwdith I also want it to have an upper limit. Something like, giving a user a bandwidth restriction of 64Kbps to 256Kbps on a 2Mbps network. Thanx -- arc_of_descent From ciprian@promo.ro Mon Jul 1 23:30:21 2002 From: ciprian@promo.ro (Ciprian Niculescu) Date: Tue, 02 Jul 2002 01:30:21 +0300 Subject: [LARTC] priority for voip References: <20020701211942.22559.qmail@webmail7.rediffmail.com> Message-ID: <3D20D7FD.1040908@promo.ro> priorize udp trafic, or based on tos, if previously marked by the system C ganesh kumar godavari wrote: > > hello stef, > this is the information i got from microsoft website > (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q158623) > > > *************************** > NetMeeting uses the following Internet Protocol (IP) ports: > Port Purpose > ------------------------------------- > 389 Internet Locator Server [Transmission Control Protocol (TCP)] > 522 User Location Server (TCP) > 1503 T.120 (TCP) > 1720 H.323 call setup (TCP) > 1731 Audio call control (TCP) > Dynamic H.323 call control (TCP) > Dynamic H.323 streaming [Realtime Transport Protocol (RTP) over > User Datagram Protocol (UDP)] > To establish outbound NetMeeting connections through a firewall, the > firewall must be configured to do the following: > Pass through primary TCP connections on ports 522, 389, 1503, 1720 and > 1731. > > Pass through secondary UDP connections on dynamically assigned ports > (1024-65535). > ******************************* > > so as u can see there is no way of determining the port if it were dynamic > > any pointers in this regard would be helpful > > thanks > ganesh > > > On Tue, 02 Jul 2002 Stef Coene wrote : > >> On Monday 01 July 2002 21:12, ganesh kumar godavari wrote: >> > hai stef, >> > i looked into your docum.org and lartc.org. for information on >> > giving high priority for voice packets. >> > i did check with the netfilter group for information on >> > identifying if a packet is a voice/data packet. >> > >> > i received no response from them. so can u please tell me how i >> > can identify if a packet is a voice/data packet so that i can >> > mangle it and send to high priority queue. >> I have no idea how you can identify voip packets. Is it using a fixed >> dst >> port of maybe host so you can use that in the filter? >> >> Stef >> >> -- >> >> stef.coene@docum.org >> "Using Linux as bandwidth manager" >> http://www.docum.org/ >> #lartc @ irc.openprojects.net > > > _________________________________________________________ > There is always a better job for you at Monsterindia.com. > Go now http://monsterindia.com/rediffin/ > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From stef.coene@docum.org Tue Jul 2 10:37:05 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 2 Jul 2002 11:37:05 +0200 Subject: [LARTC] burstable with tc In-Reply-To: <02070214390101.01380@sanitarium> References: <02070214390101.01380@sanitarium> Message-ID: Hi, I suppose you are using CBQ ? You can create more classes to achieve it.= =20 > Something like, giving a user a bandwidth restriction of > 64Kbps to 256Kbps on a 2Mbps network Gives : cbq qdisc \ bounded class rate =3D 2Mbps \ bounded class rate =3D 256 Kbps | \ class rate =3D 64Kbps \ other class rate =3D 512 Kbps \ other class rate =3D 512 Kbps \ other class rate =3D 512 Kbps \ ... But I think it will not the give the results where you are looking for. Or use htb :) Htb has a ceil parameter to ceil a class so it does exactly what you want= =2E =20 With rate you can specify the minimum rate and with ceil the maximum rate= =2E Stef On Tuesday 02 July 2002 11:09, Rohan Almeida wrote: > Hi, > Is it possible to avail of burstable option while > controlling bandwidth using tc? > Let me explain.. :-) > I could successfully allocate an ip(or class) a certain bandwdith > limit, and without giving a bounded parameter, it borrowed > bandwidth when available. > But i also want an upper limit. > Cause, the lower limit works fine. > ie. when there are other ips online, this particular ip > does not go above the lower limit. > Once the other ips go offlline, this particular ip > starts borrowing all the "available" bandwdith. > "available" is the key word here, > After it starts borrowing bandwdith I also want it > to have an upper limit. > Something like, giving a user a bandwidth restriction of > 64Kbps to 256Kbps on a 2Mbps network. > > Thanx --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From alexey_talikov@texlab.com.uz Tue Jul 2 11:35:01 2002 From: alexey_talikov@texlab.com.uz (Alexey Talikov) Date: Tue, 02 Jul 2002 15:35:01 +0500 Subject: [LARTC] IMQ and GRE Message-ID: This question mainly for Patrick McHardy As I understand problem about IMQ and GRE all been working fine, if I send packets from tunnel to another IMQ. I'm right ? My configuration eth2 - main link ppp0 - PPTP (tcp control connection on port 1723-over eth2 and GRE tunnel ppp0 ) I'm not sure that only GRE packets flowing through ppp0, can somebody corect me if not so ? modprobe imq numdevs=2 ..... ( queue config for imq0 and imq1 ) iptables -t mangle -A PREROUTING -i eth2 -j IMQ --todev 0 iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 1 ip link set imq0 up ip link set imq1 up Thank for any answer !! ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From arc_of_descent@gmx.net Tue Jul 2 11:41:11 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Tue, 2 Jul 2002 16:11:11 +0530 Subject: [LARTC] burstable with tc In-Reply-To: References: <02070214390101.01380@sanitarium> Message-ID: <02070216111100.02409@sanitarium> Stef Coene wrote: > I suppose you are using CBQ ? You can create more classes to achieve it. Yes i am using cbq > Gives : > cbq qdisc > \ bounded class rate = 2Mbps > \ bounded class rate = 256 Kbps > > | \ class rate = 64Kbps > > \ other class rate = 512 Kbps > \ other class rate = 512 Kbps > \ other class rate = 512 Kbps I'm sorry. I dont understand Maybe i'll switch to htb Thanx From lartc@itsmee.worldonline.co.uk Tue Jul 2 12:06:10 2002 From: lartc@itsmee.worldonline.co.uk (A. Peter Mee) Date: Tue, 2 Jul 2002 12:06:10 +0100 Subject: [LARTC] Lack of filtering? Message-ID: <00ec01c221b8$bc0a83e0$7f0101ac@engineering> Hi all, I have been attempting to get to know the basics of CBQ. Having followed the example at http://lartc.org/HOWTO//cvs/2.4routing/lartc.html in Section 9.5.4.4, I find myself somewhat baffled. I have checked & double-checked the commands entered and they conform to the above (though my bandwidth limits are different). What I fail to see, using `tc -s class show dev eth0 && tc -s qdisc show`, is any filtering being performed: [root@gw rc.d]# tc -s class show dev eth0 && tc -s qdisc show class cbq 1: root rate 10Mbit (bounded,isolated) prio no-transmit Sent 253851 bytes 3784 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 624 undertime 0 class cbq 1:1 parent 1: rate 40Kbit (bounded) prio no-transmit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 4.52356e+06 undertime 0 class cbq 1:3 parent 1:1 leaf 30: rate 30Kbit prio 5 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 6.03733e+06 undertime 0 class cbq 1:4 parent 1:1 leaf 40: rate 3Kbit prio 5 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 6.0533e+07 undertime 0 qdisc sfq 40: dev eth0 quantum 1514b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 30: dev eth0 quantum 1514b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc cbq 1: dev eth0 rate 10Mbit (bounded,isolated) prio no-transmit Sent 253851 bytes 3784 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 624 undertime 0 Using `tc filter show dev eth0`, I get the following: filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:3 match 00500000/ffff0000 at 20 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:2 match 0a000003/ffffffff at 12 There is one change to the filter rule given in the example: the second filter matches against the ip address 10.0.0.3 (my box). I did this to ensure all my traffic would get matched. Should I be expecting to see something from the stats (it makes sense to me that I should!)? If so, could someone point me in the direction of where I may be going wrong? If not, where should I be looking? To be clear, here are the commands I used: [root@gw rc.d]# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 10Mbit avpkt 1000 cell 8 [root@gw rc.d]# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 10Mbit rate 40kbit weight 0.4kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded [root@gw rc.d]# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 10Mbit rate 30kbit weight 0.3kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 [root@gw rc.d]# tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 10Mbit rate 3kbit weight 0.03kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 [root@gw rc.d]# tc qdisc add dev eth0 parent 1:3 handle 30: sfq [root@gw rc.d]# tc qdisc add dev eth0 parent 1:4 handle 40: sfq [root@gw rc.d]# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 80 0xffff flowid 1:3 [root@gw rc.d]# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 10.0.0.3 flowid 1:2 Kernel is v2.4.18. Cheers, Pete Mee From stef.coene@docum.org Tue Jul 2 12:54:48 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 2 Jul 2002 13:54:48 +0200 Subject: [LARTC] burstable with tc In-Reply-To: <02070216111100.02409@sanitarium> References: <02070214390101.01380@sanitarium> <02070216111100.02409@sanitarium> Message-ID: On Tuesday 02 July 2002 12:41, Rohan Almeida wrote: > Stef Coene wrote: > > I suppose you are using CBQ ? You can create more classes to achieve= it. > > Yes i am using cbq > > > Gives : > > cbq qdisc > > \ bounded class rate =3D 2Mbps > > \ bounded class rate =3D 256 Kbps > > > > | \ class rate =3D 64Kbps > > > > \ other class rate =3D 512 Kbps > > \ other class rate =3D 512 Kbps > > \ other class rate =3D 512 Kbps > > I'm sorry. I dont understand > Maybe i'll switch to htb That was the purpose :) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From kaber@trash.net Tue Jul 2 17:37:44 2002 From: kaber@trash.net (Patrick McHardy) Date: Tue, 02 Jul 2002 18:37:44 +0200 Subject: [LARTC] IMQ and GRE References: Message-ID: <3D21D6D8.8070105@trash.net> hi. Alexey Talikov wrote: >This question mainly for Patrick McHardy >As I understand problem about IMQ and GRE all been working fine, if I send packets from tunnel >to another IMQ. I'm right ? > right. the problem is when sending packets to a device which encapsulates them and both the non-encapsulated and the encapsulated go to the same imq device. > > >My configuration >eth2 - main link >ppp0 - PPTP (tcp control connection on port 1723-over eth2 and GRE tunnel ppp0 ) >I'm not sure that only GRE packets flowing through ppp0, can somebody corect me if not so ? > >modprobe imq numdevs=2 >..... ( queue config for imq0 and imq1 ) >iptables -t mangle -A PREROUTING -i eth2 -j IMQ --todev 0 >iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 1 >ip link set imq0 up >ip link set imq1 up > >Thank for any answer !! >----------------------------------- >mailto:alexey_talikov@texlab.com.uz >BR >Alexey Talikov >FORTEK >----------------------------------- > hmm sorry i don't really get your configuration. gre tunnel is going through ppp0 which is pptp over eth2 ? you can just try out if it works, your computer won't crash if it doesn't. you'll see some messages about imq beeing deadlooped in the ringbuffer if it doesn't ... Bye Patrick From gabriel@sics.se Tue Jul 2 18:57:59 2002 From: gabriel@sics.se (Gabriel Paues) Date: Tue, 02 Jul 2002 19:57:59 +0200 Subject: [LARTC] Compiling HTB References: <3D21D6D8.8070105@trash.net> Message-ID: <3D21E9A7.9E2CFCD6@sics.se> Hello! I try to make HTB work with kernel 2.4.18. The patch goes through, and compilation as well but when I do make modules_install the sch_htb.o wont get copied to /lib/modules/2.4.18/kernel/net/sched - directory. When I try to insmod it (sch_htb.o) it tells me that this module is for another version of the kernel. This usally happens when that is the case, but ever since the versioning system CONFIG_MODVERSIONS got into the kernel (God bless it) I haven't had those problems... How do I load the HTB functionality? Is it incorporated in another module which I must load instead? I cannot se anywhere on the files changed by the htb-patch anything about a specific kernel-version. Or, am I just stupid... :-) Regards, Gabriel Paues From alexey_talikov@texlab.com.uz Wed Jul 3 09:51:22 2002 From: alexey_talikov@texlab.com.uz (Alexey Talikov) Date: Wed, 03 Jul 2002 13:51:22 +0500 Subject: [LARTC] IMQ and GRE In-Reply-To: <3D21D6D8.8070105@trash.net> Message-ID: <8641972UEDUP4ZVQ62QMDBRMYURQ2ZQK.3d22bb0a@ALEXEY> Thanks Patrick !! I also found answer on my last question. It's may be interesting for you http://pptpclient.sourceforge.net/diagrams.phtml ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From gabriel@sics.se Wed Jul 3 15:35:06 2002 From: gabriel@sics.se (Gabriel Paues) Date: Wed, 03 Jul 2002 16:35:06 +0200 Subject: [LARTC] I can not set up filters References: <200206171816.08176.Adi@iNterNUX.co.id> Message-ID: <3D230B9A.F90A4A21@sics.se> Hello! I have set up a htb qdisc: # tc qdisc show dev eth1 qdisc htb 1: r2q 10 default 12 direct_packets_stat 0 with the following classes attached to it #tc class show dev eth1 class htb 1:11 parent 1:1 prio 0 rate 80Kbit ceil 800Kbit burst 1575b cburst 1969b class htb 1:1 root rate 800Kbit ceil 800Kbit burst 1969b cburst 1969b class htb 1:10 parent 1:1 prio 0 rate 240Kbit ceil 800Kbit burst 1772b cburst 1969b class htb 1:12 parent 1:1 prio 0 rate 480Kbit ceil 800Kbit burst 1181b cburst 1969b When I try to attach filters to it i get the following answer: # tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dport 80 0xffff flowid 1:10 RTNETLINK answers: Invalid argument What am I doing wrong? I Would really appreciate your help. Regards, Gabriel Paues From devik@cdi.cz Wed Jul 3 15:42:33 2002 From: devik@cdi.cz (Martin Devera) Date: Wed, 3 Jul 2002 16:42:33 +0200 (CEST) Subject: [LARTC] I can not set up filters In-Reply-To: <3D230B9A.F90A4A21@sics.se> References: <200206171816.08176.Adi@iNterNUX.co.id> <3D230B9A.F90A4A21@sics.se> Message-ID: > When I try to attach filters to it i get the following answer: > # tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip > dport 80 0xffff flowid 1:10 > RTNETLINK answers: Invalid argument > > What am I doing wrong? did you load/compile U32 classifier ? From gabriel@sics.se Wed Jul 3 15:44:39 2002 From: gabriel@sics.se (Gabriel Paues) Date: Wed, 03 Jul 2002 16:44:39 +0200 Subject: [LARTC] I can not set up filters References: <200206171816.08176.Adi@iNterNUX.co.id> <3D230B9A.F90A4A21@sics.se> Message-ID: <3D230DD7.7425D651@sics.se> Wohhaaa... Thank you so much for pointing out the obvious... Now it works.. Thanks! Gabriel Paues Martin Devera wrote: > > > When I try to attach filters to it i get the following answer: > > # tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip > > dport 80 0xffff flowid 1:10 > > RTNETLINK answers: Invalid argument > > > > What am I doing wrong? > > did you load/compile U32 classifier ? From bm@turtle-entertainment.de Wed Jul 3 15:46:10 2002 From: bm@turtle-entertainment.de (Bjoern Metzdorf) Date: Wed, 3 Jul 2002 16:46:10 +0200 Subject: [LARTC] I can not set up filters References: <200206171816.08176.Adi@iNterNUX.co.id> <3D230B9A.F90A4A21@sics.se> Message-ID: <05ae01c222a0$5f0e9c60$81c206d4@office.turtleentertainment.de> Hi, > qdisc htb 1: r2q 10 default 12 direct_packets_stat 0 > > with the following classes attached to it > > #tc class show dev eth1 > class htb 1:11 parent 1:1 prio 0 rate 80Kbit ceil 800Kbit burst 1575b > cburst 1969b > class htb 1:1 root rate 800Kbit ceil 800Kbit burst 1969b cburst 1969b > class htb 1:10 parent 1:1 prio 0 rate 240Kbit ceil 800Kbit burst 1772b > cburst 1969b > class htb 1:12 parent 1:1 prio 0 rate 480Kbit ceil 800Kbit burst 1181b > cburst 1969b > > When I try to attach filters to it i get the following answer: > # tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip > dport 80 0xffff flowid 1:10 > RTNETLINK answers: Invalid argument > > What am I doing wrong? My guess: You try to attach the filter to the class 1:0. Try attaching it to the defined root class 1:1, or even better to the subclasses 1:10, 1:11 or 1:12 (think this is what you want). Greetings, Bjoern From bm@turtle-entertainment.de Wed Jul 3 15:54:38 2002 From: bm@turtle-entertainment.de (Bjoern Metzdorf) Date: Wed, 3 Jul 2002 16:54:38 +0200 Subject: [LARTC] I can not set up filters References: <200206171816.08176.Adi@iNterNUX.co.id> <3D230B9A.F90A4A21@sics.se> <05ae01c222a0$5f0e9c60$81c206d4@office.turtleentertainment.de> Message-ID: <060c01c222a1$8e1dec80$81c206d4@office.turtleentertainment.de> > > What am I doing wrong? > > My guess: (Foolish crap removed) I mixed up flowid and parent, your syntax was correct, and I was wrong. Greetings, Bjoern From dzila@tassadar.physics.auth.gr Wed Jul 3 17:33:25 2002 From: dzila@tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Wed, 3 Jul 2002 19:33:25 +0300 (EEST) Subject: [LARTC] tc reliably hangs my system Message-ID: kernel 2.4.18-ac3 smp , iproute2-2.4.7-now-ss020116-try.tar.gz I am using the following scripts to adjust my traffic during certain periods of time , running them cron and sometimes by hand . They can reliably freeze the system if they are run certain number of times . No oops/panic/errors of whatsoever , just a frozen system . the following "fast" script freezes the system after it is executed 7-8 times tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 weight 10Mbit prio 8 maxburst 20 avpkt 1000 tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 weight 10Mbit prio 5 maxburst 20 avpkt 1000 tc class add dev eth0 parent 10:1 classid 10:200 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 weight 10Mbit prio 5 maxburst 20 avpkt 1000 tc qdisc add dev eth0 parent 10:100 sfq quantum 1514b perturb 10 tc qdisc add dev eth0 parent 10:200 tbf rate 6Mbit latency 50ms burst \ 50000 tc qdisc del dev eth0 ingress tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 2 u32 match ip \ protocol 1 0xFF police rate 1kbit burst 10000 mtu 1k drop flowid :1 tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip dst \ 1.2.3.0/16 flowid 10:100 tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match tcp src \ 22 0xffff match ip protocol 0x6 0xff flowid 10:100 tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip src \ 1.2.3.25/32 flowid 10:200 The following "slow" script freezes the system after being executed around 11-18 times tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 weight 10Mbit prio 8 maxburst 20 avpkt 1000 tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 weight 10Mbit prio 5 maxburst 20 avpkt 1000 tc class add dev eth0 parent 10:1 classid 10:200 cbq bandwidth 100Mbit \ rate 100Mbit allot 1514 weight 10Mbit prio 5 maxburst 20 avpkt 1000 tc qdisc add dev eth0 parent 10:100 sfq quantum 1514b perturb 10 tc qdisc add dev eth0 parent 10:200 tbf rate 3Mbit latency 50ms burst \ 50000 tc qdisc del dev eth0 ingress tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 2 u32 match ip \ protocol 1 0xFF police rate 1kbit burst 10000 mtu 1k drop flowid :1 tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip dst \ 1.2.3.0/16 flowid 10:100 tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match tcp src \ 22 0xffff match ip protocol 0x6 0xff flowid 10:100 tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip src \ 1.2.3.25/32 flowid 10:200 The ingress related parts are the prime suspects for me , i added them recently . Before that no freezing has ever ocurred . I couldn't perform more tests because the box is a rather busy server and the lockups cause painfull reboots . Any advice is welcomed . Kind regards , -- ============================================================================= Dimitris Zilaskos Department of Physics @ Aristotle Univercity of Thessaloniki , Greece ============================================================================= From stef.coene@docum.org Wed Jul 3 17:47:42 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 3 Jul 2002 18:47:42 +0200 Subject: [LARTC] tc reliably hangs my system In-Reply-To: References: Message-ID: <20020703164743.12828DCB1F@tartarus.telenet-ops.be> On Wednesday 03 July 2002 18:33, Dimitris Zilaskos wrote: > kernel 2.4.18-ac3 smp , iproute2-2.4.7-now-ss020116-try.tar.gz > > I am using the following scripts to adjust my traffic during certain > periods of time , running them cron and sometimes by hand . They can > reliably freeze the system if they are run certain number of times . > No oops/panic/errors of whatsoever , just a frozen system . > > The ingress related parts are the prime suspects for me , i added them > recently . Before that no freezing has ever ocurred . I couldn't perfor= m > more tests because the box is a rather busy server and the lockups caus= e > painfull reboots . > > Any advice is welcomed . I ran both scripts for 10 minutes (while true; do ./test.sh; sleep 5; don= e)=20 and no freeze for me. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From jeroen.dille@st.cs.kuleuven.ac.be Wed Jul 3 20:24:44 2002 From: jeroen.dille@st.cs.kuleuven.ac.be (Jeroen Dille) Date: Wed, 3 Jul 2002 21:24:44 +0200 Subject: [LARTC] policy based routing Message-ID: <016d01c222c7$4f7243c0$0200a8c0@gaiothpc> Hello, I'm running a home-made Debian 2.4.18 kernel with iproute2-ss010824. I have 2 cable-modems to 2 different providers. One with a transparant proxy and one with a regular. I would like to load-balance all traffic over the 2 modems and to do this with http traffic I have to run 2 squid processes: squid1 to act as a proxy for the provider with the transparant proxy and squid2 that does the load-balancing between the squid1 and the regular proxy of the other provider. The main difficulty is to route all packets coming from the squid1 to the right interface (eth0 in my case). I want to do this based on the user that's running the squid process. I think this should work, but it doesn't... What I've done: To mark all packets coming from the squid process: iptables -t mangle -A OUTPUT -m owner --uid-owner 23 -j MARK --set-mark 1 To send all marked packets to routing table T4: ip rule add fwmark 1 table T4 This is my main routing table: 127.0.0.1 dev lo scope link src 127.0.0.1 192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.15 195.130.138.0/23 dev eth1 proto kernel scope link src 195.x.x.x 10.4.0.0/16 dev eth0 proto kernel scope link src 10.4.29.11 default nexthop via 10.4.0.1 dev eth0 weight 1 nexthop via 195.130.138.1 dev eth1 weight 1 This is table T4: 10.4.0.0/16 dev eth0 proto kernel scope link src 10.4.29.11 default via 10.4.0.1 dev eth0 The packets get marked correctly but the routing is wrong. If I put "ip rule add fwmark 1 table default" instead of "ip rule add fwmark 1 table T4" it works like a charm... (well, if I leave the load-balancing, only 1 in 2 pages work, if I put default via 10.4.0.1 dev eth0 in the main table it always works) I've tried to recreate the main table in T4 but that didn't work either... 127.0.0.1 dev lo scope link src 127.0.0.1 192.168.0.0/24 dev eth2 scope link src 192.168.0.15 10.4.0.0/16 dev eth0 scope link src 10.4.29.11 default via 10.4.0.1 dev eth0 Does anybody knows what's going wrong? What routes should be in table T4? tia Jeroen From ganesh kumar godavari" This is a multipart mime message --Next_1025748106---0-202.54.124.151-697 Content-type: text/plain; format=flowed Content-Disposition: inline hello group, i need some help in debugging my cbq work, i have the following setup at my dorms, i have 2 computers and a 10 mbit hub, i use the schools connection. we have a T1 connection( i think so...). one of the machine is configured to be the firewall(p.q.r.s) and the other machine has a private address of (a.b.c.d) i am running the following services on a.b.c.d real server using 8080, 7070, 554, 26887 apache webserver 80,443 i want to allocate 70% for realserver and apache server, ssh,telnet,ftp,nntp 20%, smtp and pop 5% and ICMP and TCP-SYN traffic the remaining 5% i want to limit some of friends from accessing and attacking my computer. for better service, more over its a good learning experience i have written a firewall script and want to do some qos can anyone tell me how if my script is right or wrong, i want to measure if the queuing is working fine or not. i downloaded monitor.pl from docum.org and put it on cgi-bin of my firewall(p.q.r.s) where i am currently running apache. i am getting a internal error, i am not good at perl, so can anyone tell me how i can monitor the bandwidth and see if monitor.pl is working or not. i am attaching my code to this mail, i will grateful to you if u can help me identify the problem in my shell script( it doesn't give me any error -- but i donot know what the errors are hidden :-)) thanks gamesh _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.com/rediffin/ --Next_1025748106---0-202.54.124.151-697 Content-type: application/x-sh Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tfinal.sh" IyEvYmluL3NoCgojIFRoaXMgaXMgdGhlIGxvY2F0aW9uIG9mIHRoZSBpcHRhYmxlcyBjb21t YW5kCklQVEFCTEVTPSIvc2Jpbi9pcHRhYmxlcyIKVEM9Ii9zYmluL3RjIgoKRVhUSUY9ImV0 aDAiCklOVElGPSJldGgxIgoKCmNhc2UgIiQxIiBpbgogICBzdG9wKQogICAgICBlY2hvICJT aHV0dGluZyBkb3duIGZpcmV3YWxsLi4uIgogICAgICAkSVBUQUJMRVMgLUYKICAgICAgJElQ VEFCTEVTIC1GIC10IG1hbmdsZQogICAgICAkSVBUQUJMRVMgLUYgLXQgbmF0CiAgICAgICRJ UFRBQkxFUyAtWAogICAgICAkSVBUQUJMRVMgLVggLXQgbWFuZ2xlCiAgICAgICRJUFRBQkxF UyAtWCAtdCBuYXQKCiAgICAgICRJUFRBQkxFUyAtUCBJTlBVVCBBQ0NFUFQKICAgICAgJElQ VEFCTEVTIC1QIE9VVFBVVCBBQ0NFUFQKICAgICAgJElQVEFCTEVTIC1QIEZPUldBUkQgQUND RVBUCgogICAgICRUQyBxZGlzYyBkZWwgZGV2ICRJTlRJRiByb290IGhhbmRsZSAxMDowIGNi cSBiYW5kd2lkdGggMTBNYml0IGF2cGt0IDEwMDAgCgogICAgICBlY2hvICIuLi5kb25lIgog ICAgICA7OwogICBzdGF0dXMpCiAgICAgIGVjaG8gJCJUYWJsZTogZmlsdGVyIgogICAgICBp cHRhYmxlcyAtLWxpc3QKICAgICAgZWNobyAkIlRhYmxlOiBuYXQiCiAgICAgIGlwdGFibGVz IC10IG5hdCAtLWxpc3QKICAgICAgZWNobyAkIlRhYmxlOiBtYW5nbGUiCiAgICAgIGlwdGFi bGVzIC10IG1hbmdsZSAtLWxpc3QKICAgICAgOzsKICAgcW9zKQogICAgICBlY2hvICJTdGFy dGluZyB0aGUgcW9zIC4uLiIKCiAgICAgIGFkZF9jbGFzcygpIHsKICAgICAgICMgJDE9cGFy ZW50IGNsYXNzICQyPWNsYXNzaWQgJDM9aGliYW5kICQ0PWxvd2JhbmQgJDU9aGFuZGxlICQ2 PXN0eWxlCiAgICAgICAkVEMgY2xhc3MgYWRkIGRldiAkSU5USUYgIHBhcmVudCAkMSBjbGFz c2lkICQyIGNicSBiYW5kd2lkdGggMTBNYml0IHJhdGUgJDMgYWxsb3QgMTUxNCB3ZWlnaHQg JDQgcHJpbyA1ICBtYXhidXJzdCAyMCBhdnBrdCAxMDAwICQ2CiAgICAgICAkVEMgcWRpc2Mg YWRkIGRldiAkSU5USUYgcGFyZW50ICQyIHNmcSBxdWFudHVtIDE1MTRiIHBlcnR1cmIgMTUK ICAgICAgICRUQyBmaWx0ZXIgYWRkIGRldiAkSU5USUYgcHJvdG9jb2wgaXAgcHJpbyAzIGhh bmRsZSAkNSBmdyBjbGFzc2lkICQyCiAgICAgIH0KCiAgICAgICAkVEMgcWRpc2MgYWRkIGRl diAkSU5USUYgcm9vdCBoYW5kbGUgMTA6IGNicSBiYW5kd2lkdGggMTBNYml0IGF2cGt0IDEw MDAKICAgICAgICRUQyBjbGFzcyBhZGQgZGV2ICRJTlRJRiBwYXJlbnQgMTA6MCBjbGFzc2lk IDEwOjEgY2JxIGJhbmR3aWR0aCAxME1iaXQgcmF0ZSA2NGtiaXQgYWxsb3QgMTUxNCB3ZWln aHQgNi40a2JpdCBwcmlvIDggbWF4YnVyc3QgMjAgYXZwa3QgMTAwMCBib3VuZGVkCgogICAg ICAjZmlyc3QgdHlwZSBvZiB0cmFmZmljIElDTVAsIFRDUC1TWU4sIEROUyB3aWxsIGJlIG1h cmtlZCAnMScgYnkgdGhlIGZpcmV3YWxsIGNvZGUKICAgICAgI3dlIHdpbGwgZ2l2ZSBpdCBh IGJvdW5kZWQgYmFuZHdpZHRoIG9mIDUlIG9mIG91ciB0b3RhbCBpbmNvbWluZyBiYW5kd2lk dGggKDY0KjAuMDU9My4yKQogICAgICAgYWRkX2NsYXNzIDEwOjEgMTA6MTAwIDMuMmtiaXQg MC4zMmtiaXQgMSBib3VuZGVkCiAKICAgICAgI3NlY29uZCB0eXBlIG9mIHRyYWZmaWMgU01U UCxQT1AzIHdpbGwgYmUgbWFya2VkICcyJyBieSB0aGUgZmlyZXdhbGxpbmcgY29kZQogICAg ICAjd2Ugd2lsbCBnaXZlIGl0IGEgYm91bmRlZCBiYW5kd2lkdGggb2YgNSUgb2Ygb3VyIHRv dGFsIGluY29taW5nIGJhbmR3aWR0aCAoNjQqMC4wNT0zLjIpCiAgICAgIGFkZF9jbGFzcyAx MDoxIDEwOjMwMCAzLjJrYml0IDAuMzJrYml0IDIgCgogICAgICAjdGhpcmQgdHlwZSBvZiB0 cmFmZmljIG5udHAsc3NoLGZ0cCB3aWxsIGJlIG1hcmtlZCAnMycgYnkgdGhlIGZpcmV3YWxs aW5nIGNvZGUKICAgICAgI3dlIHdpbGwgZ2l2ZSBpdCBhIGJvdW5kZWQgYmFuZHdpZHRoIG9m IDIwJSBvZiBvdXIgdG90YWwgaW5jb21pbmcgYmFuZHdpZHRoICg2NCowLjIwPTEyLjgpCiAg ICAgIGFkZF9jbGFzcyAxMDoxIDEwOjIwMCAxMi44a2JpdCAxLjI4a2JpdCAzIAoKICAgICAg I2xhc3QgdHlwZSBvZiB0cmFmZmljIGlzIGludGVyYWN0aXZlIHRyYWZmaWMuIEl0IHdpbGwg YmUgbWFya2VkICc0JyBieSB0aGUgZmlyZXdhbGxpbmcgY29kZQogICAgICAjd2Ugd2lsbCBn aXZlIGl0IGEgYm91bmRlZCBiYW5kd2lkdGggb2YgNzAlIG9mIG91ciB0b3RhbCBpbmNvbWlu ZyBiYW5kd2lkdGggKDY0KjAuNzA9NDQuOCkKICAgICAgYWRkX2NsYXNzIDEwOjEgMTA6NDAw IDQ0LjhrYml0IDQuNDhrYml0IDQgCiAgICAgIDs7CgogICAgcmVzdGFydHxyZWxvYWQpCiAg ICAgIHNoICQwIHN0b3AKICAgICAgc2ggJDAgc3RhcnQKICAgICAgc2ggJDAgcW9zCiAgICAg IDs7CgogICBzdGFydCkKICAgIGVjaG8gIlN0YXJ0aW5nIEZpcmV3YWxsLi4uIgogICAKICAg IGVjaG8gIiIKCgojIy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tQmVnaW4gRmlyZXdhbGwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0jIwoKCiMtLS0tRmxvb2QgVmFyaWFi bGVzLS0tLS0jCiMgT3ZlcmFsbCBMaW1pdCBmb3IgVENQLVNZTi1GbG9vZCBkZXRlY3Rpb24K VENQU1lOTElNSVQ9IjEvcyIKIyBCdXJzdCBMaW1pdCBmb3IgVENQLVNZTi1GbG9vZCBkZXRl Y3Rpb24KVENQU1lOTElNSVRCVVJTVD0iNSIKCiMgT3ZlcmFsbCBMaW1pdCBmb3IgUGluZy1G bG9vZC1EZXRlY3Rpb24KUElOR0xJTUlUPSIxL3MiCiMgQnVyc3QgTGltaXQgZm9yIFBpbmct Rmxvb2QtRGV0ZWN0aW9uClBJTkdMSU1JVEJVUlNUPSI1IgoKIy0tLS1DbGVhci9SZXNldCBh bGwgY2hhaW5zLS0tLS0jCgojQ2xlYXIgYWxsIElQVEFCTEVTLWNoYWlucwojRmx1c2ggZXZl cnl0aGluZywgc3RhcnQgZnJvbSBzY3JhdGNoCiRJUFRBQkxFUyAtRgokSVBUQUJMRVMgLUYg LXQgbWFuZ2xlCiRJUFRBQkxFUyAtRiAtdCBuYXQKJElQVEFCTEVTIC1YCiRJUFRBQkxFUyAt WCAtdCBtYW5nbGUKJElQVEFCTEVTIC1YIC10IG5hdAoKI1NldCBkZWZhdWx0IHBvbGljaWVz IHRvIERST1AKJElQVEFCTEVTIC1QIElOUFVUIERST1AKJElQVEFCTEVTIC1QIE9VVFBVVCBE Uk9QCiRJUFRBQkxFUyAtUCBGT1JXQVJEIERST1AKCgojUmVkdWNlIERvUydpbmcgYWJpbGl0 eSBieSByZWR1Y2luZyB0aW1lb3V0cwplY2hvIDMwID4gL3Byb2Mvc3lzL25ldC9pcHY0L3Rj cF9maW5fdGltZW91dAplY2hvIDI0MDAgPiAvcHJvYy9zeXMvbmV0L2lwdjQvdGNwX2tlZXBh bGl2ZV90aW1lCmVjaG8gMCA+IC9wcm9jL3N5cy9uZXQvaXB2NC90Y3Bfd2luZG93X3NjYWxp bmcKZWNobyAwID4gL3Byb2Mvc3lzL25ldC9pcHY0L3RjcF9zYWNrCgojIEFsbG93IHRoZSBr ZXJuZWwgdG8gZm9yd2FyZCBwYWNrZXRzIGFuZCBwcmV2ZW50IGlwc3Bvb2YKZWNobyAxID4g L3Byb2Mvc3lzL25ldC9pcHY0L2lwX2ZvcndhcmQKZWNobyAxID4gL3Byb2Mvc3lzL25ldC9p cHY0L2lwX2R5bmFkZHIKZm9yIGYgaW4gL3Byb2Mvc3lzL25ldC9pcHY0L2NvbmYvKi9ycF9m aWx0ZXI7IGRvIGVjaG8gMSA+ICRmOyBkb25lCgojIENyZWF0ZSBjaGFpbnMgdG8gcHJvdGVj dCBmcm9tIHBpbmdvZmRlYXRoLFN5bi1mbG9vZCxGdXJ0aXZlLXBvcnQKJElQVEFCTEVTIC1O IG15bGltaXQKJElQVEFCTEVTIC1BIG15bGltaXQgLW0gbGltaXQgLS1saW1pdCAxL3MgLS1s aW1pdC1idXJzdCA1IC1qIEFDQ0VQVAokSVBUQUJMRVMgLUEgbXlsaW1pdCAtaiBEUk9QCgoj IHNldCB1cCBhIG5ldyBjaGFpbiB0byBhY2NlcHQgdGhlIGdvb2QgY29ubmVjdGlvbnMKIyBi bG9jayBpbmNvbWluZyBjb25uZWN0aW9zIGZyb20gZXRoMCAgb24gcG9ydHMgb3RoZXIgdGhh biBkZXNpcmVkCgojIENyZWF0ZSB1c2VyIGNoYWluCmVjaG8gIkNyZWF0aW5nIHVzZXItY2hh aW5zIgokSVBUQUJMRVMgLU4gbXlhY2NlcHQKIyBQaW5nIGZsb29kIC8gU3luLWZsb29kIHBy b3RlY3Rpb24gLyBGdXJ0aXZlIHBvcnQgc2Nhbm5lcgokSVBUQUJMRVMgLUEgbXlhY2NlcHQg LXAgaWNtcCAtLWljbXAtdHlwZSBlY2hvLXJlcXVlc3QgLWogbXlsaW1pdAokSVBUQUJMRVMg LUEgbXlhY2NlcHQgLXAgdGNwIC0tc3luIC1qIG15bGltaXQKJElQVEFCTEVTIC1BIG15YWNj ZXB0IC1wIHRjcCAtLXRjcC1mbGFncyBTWU4sQUNLLEZJTixSU1QgUlNUIC1qIG15bGltaXQK IyRJUFRBQkxFUyAtQSBteWFjY2VwdCAtcCB0Y3AgLS10Y3AtZmxhZ3MgU1lOIFNZTiAtaiBt eWxpbWl0CgojIGVzdGFibGlzaGVkIGFuZCByZWxhdGVkIGNvbm5ldGN0aW9ucyBhcmUgYWNj ZXB0YWJsZQokSVBUQUJMRVMgLUEgbXlhY2NlcHQgLW0gc3RhdGUgLS1zdGF0ZSBFU1RBQkxJ U0hFRCxSRUxBVEVEIC1qIEFDQ0VQVAojIG5ldyBjb25uZWN0aW9ucyBub3QgZnJvbSB0aGUg b3V0c2lkZSBhcmUgYWNjZXB0YWJsZQokSVBUQUJMRVMgLUEgbXlhY2NlcHQgLWkgISBldGgw IC1tIHN0YXRlIC0tc3RhdGUgTkVXIC1qIEFDQ0VQVAoKIyBpY21wIGNvbm5lY3Rpb25zIHRo YXQgcGFzc2VkIHRoZSBwaW5nZmxvb2QgdGVzdCBhcmUgYWNjZXB0ZWQKIyRJUFRBQkxFUyAt QSBteWFjY2VwdCAtaSBldGgwIC1wIGljbXAgLW0gc3RhdGUgLS1zdGF0ZSBORVcgLWogQUND RVBUCgojIHRoZSBnb29kIHBvcnRzIHd3dyBhbmQgc3NoIGFyZSBhY2NlcHRlZAojJElQVEFC TEVTIC1BIG15YWNjZXB0IC1pIGV0aDAgLXAgdGNwIC1tIG11bHRpcG9ydCAtLWRwb3J0IHd3 dyxzc2ggLW0gc3RhdGUgLS1zdGF0ZSBORVcgLWogQUNDRVBUCgojIEknbSBub3Qgc3VyZSBp ZiB0aGlzIGlzIGEgZ29vZCBJZGVhLCBidXQgSSBsaWtlIHRoZSBpZGVhIG9mIHJlamVjdGlu ZyBldmFuIGlmIGl0IGdpdmVzIHRoZSBhdHRhY2tlciB0aGUgaW5mbwojIHRoZXJlIGlzIGEg aG9zdCB0aGVyZS4gIFBlcnNvbmFsIHByZWZlcmVuY2UgSSBndWVzcy4gIEknZCBsaWtlIHRv IGhhdmUgYSByZWplY3Qgd2l0aCBpY21wLXBvcnQtbmFuYW5hbmEtYm9vby1ib29vLgojL3Ni aW4vaXB0YWJsZXMgLUEgbXlhY2NlcHQgLWkgZXRoMCAtbSBzdGF0ZSAtLXN0YXRlIE5FVyAt aiBSRUpFQ1QgLS1yZWplY3Qtd2l0aCBpY21wLXBvcnQtdW5yZWFjaGFibGUKCiMgQSBwcm9i bGVtIHdhcyBvY2N1cmluZyB3aGVyZSBjZXJ0YWluIHNpdGVzIHdlcmUgdW5hY2Nlc3NpYmxl LCB0aGlzIG5leHQgbGluZSBmaXhlcyBpdAokSVBUQUJMRVMgLUEgRk9SV0FSRCAtcCB0Y3Ag LS10Y3AtZmxhZ3MgU1lOLFJTVCBTWU4gLWogVENQTVNTIC0tY2xhbXAtbXNzLXRvLXBtdHUK JElQVEFCTEVTIC1BIE9VVFBVVCAtcCB0Y3AgLS10Y3AtZmxhZ3MgU1lOLFJTVCBTWU4gLWog VENQTVNTIC0tY2xhbXAtbXNzLXRvLXBtdHUKCiMjIyMjIFJBVEUgTElNSVRJTkcgR09FUyBI RVJFICMjIyMjIyMjIyMjCiMgQXBwZW5kIFVzZXIgY2hhaW5zCiRJUFRBQkxFUyAtQSBJTlBV VCAtcyAxMjguMTk4LjYwLjE5NSAtcCB0Y3AgLWogbXlhY2NlcHQKJElQVEFCTEVTIC1BIElO UFVUIC1zIDEyOC4xOTguNjAuMTk1IC1wIGljbXAgLWogbXlhY2NlcHQKJElQVEFCTEVTIC1B IElOUFVUIC1zIDEyOC4xOTguNjAuMTk1IC1wIHVkcCAtaiBteWFjY2VwdAoKCiMjIyMjIyMj IEVORCBPRiBSQVRFIExJTUlUSU5HICMjIyMjIyMjIyMjIwoKIyMjIyMjIyMjIyMgUU9TIEdP RVMgSEVSRSAjIyMjIyMjIyMjIyMjIyMjIwoKIyBhbGxvdyBzaW1wbGUgZG5zIHRyYWZmaWMK JElQVEFCTEVTIC1BIElOUFVUIC1wIHVkcCAtcyAwLzAgLS1kcG9ydCAgNTMgLWogQUNDRVBU IAokSVBUQUJMRVMgLUEgT1VUUFVUIC1wIHVkcCAtZCAwLzAgLS1kcG9ydCA1MyAtaiBBQ0NF UFQKCiMgYWxsb3cgaWNtcCB0cmFmZmljIG1hcmsgaXQgd2l0aCB2YWx1ZSAxCiRJUFRBQkxF UyAtQSBJTlBVVCAtcCBpY21wIC1pICRFWFRJRiAtaiBBQ0NFUFQgLW0gbWFyayAtLW1hcmsg MQokSVBUQUJMRVMgLUEgSU5QVVQgLXAgdGNwIC0tc3luIC1pICRFWFRJRiAtaiBBQ0NFUFQg LW0gbWFyayAtLW1hcmsgMSAKCiNtYXJrIGluY29taW5nIG1haWwgdHJhZmZpYyB3aXRoIG1h cmsgdmFsdWUgMgokSVBUQUJMRVMgLUEgSU5QVVQgLXAgdGNwICEgLS1zeW4gLWkgJEVYVElG IC1zIDAvMCAtLWRwb3J0IHNtdHAgLWQgMC8wIC1qIEFDQ0VQVCAtbSBtYXJrIC0tbWFyayAy CiRJUFRBQkxFUyAtQSBJTlBVVCAtcCB0Y3AgISAtLXN5biAtaSAkRVhUSUYgLXMgMC8wIC0t ZHBvcnQgcG9wMyAtZCAwLzAgLWogQUNDRVBUIC1tIG1hcmsgLS1tYXJrIDIKCiNtYXJrIGlu Y29taW5nICBhbmQgTmV3cyB0cmFmZmljIHdpdGggbWFyayB2YWx1ZSAzCiRJUFRBQkxFUyAt QSBJTlBVVCAtcCB0Y3AgISAtLXN5biAtaSAkRVhUSUYgLXMgMC8wIC0tZHBvcnQgMjEgLWQg MC8wIC1qIEFDQ0VQVCAtbSBtYXJrIC0tbWFyayAzCiRJUFRBQkxFUyAtQSBJTlBVVCAtcCB0 Y3AgISAtLXN5biAtaSAkRVhUSUYgLXMgMC8wIC0tZHBvcnQgMjIgLWQgMC8wIC1qIEFDQ0VQ VCAtbSBtYXJrIC0tbWFyayAzCiRJUFRBQkxFUyAtQSBJTlBVVCAtcCB0Y3AgISAtLXN5biAt aSAkRVhUSUYgLXMgMC8wIC0tZHBvcnQgMjMgLWQgMC8wIC1qIEFDQ0VQVCAtbSBtYXJrIC0t bWFyayAzCiRJUFRBQkxFUyAtQSBJTlBVVCAtcCB0Y3AgISAtLXN5biAtaSAkRVhUSUYgLXMg MC8wIC0tZHBvcnQgbm50cCAtZCAwLzAgLWogQUNDRVBUIC1tIG1hcmsgLS1tYXJrIDMKCiNt YXJrIGluY29taW5nIHd3dyBhbmQgUmVhbCBTZXJ2ZXIgdHJhZmZpYyB3aXRoIG1hcmsgdmFs dWUgNAokSVBUQUJMRVMgLUEgSU5QVVQgLXAgdGNwIC1pICRFWFRJRiAtcyAwLzAgLS1kcG9y dCA4MCAtZCAwLzAgLWogQUNDRVBUIC1tIG1hcmsgLS1tYXJrIDQKJElQVEFCTEVTIC1BIElO UFVUIC1wIHRjcCAtaSAkRVhUSUYgLXMgMC8wIC0tZHBvcnQgNDQzIC1kIDAvMCAtaiBBQ0NF UFQgLW0gbWFyayAtLW1hcmsgNAokSVBUQUJMRVMgLUEgSU5QVVQgLXAgdGNwIC1pICRFWFRJ RiAtcyAwLzAgLS1kcG9ydCA3MDcwIC1kIDAvMCAtaiBBQ0NFUFQgLW0gbWFyayAtLW1hcmsg NAokSVBUQUJMRVMgLUEgSU5QVVQgLXAgdGNwIC1pICRFWFRJRiAtcyAwLzAgLS1kcG9ydCA1 NTQgLWQgMC8wIC1qIEFDQ0VQVCAtbSBtYXJrIC0tbWFyayA0CiRJUFRBQkxFUyAtQSBJTlBV VCAtcCB0Y3AgLWkgJEVYVElGIC1zIDAvMCAtLWRwb3J0IDgwODAgLWQgMC8wIC1qIEFDQ0VQ VCAtbSBtYXJrIC0tbWFyayA0CiRJUFRBQkxFUyAtQSBJTlBVVCAtcCB0Y3AgLWkgJEVYVElG IC1zIDAvMCAtLWRwb3J0IDI2ODcgLWQgMC8wIC1qIEFDQ0VQVCAtbSBtYXJrIC0tbWFyayA0 CgojJElQVEFCTEVTIC1BIE9VVFBVVCAtaSAkRVhUSUYgLWogQUNDRVBUCiMkSVBUQUJMRVMg LUEgSU5QVVQgIC1pICRFWFRJRiAtaiBBQ0NFUFQKCiMgRE5BVAojIHRyYW5zbGF0ZSBpbmNv bWluZyBzc2ggYW5kIHd3dyB0cmFmZmljIHRvIG15IGludGVybmFsIGhvc3RzCiNpcHRhYmxl cyAtdCBuYXQgLUEgUFJFUk9VVElORyAtcCB0Y3AgLS1kcG9ydCAyMiAtaSBwcHAwIC1qIERO QVQgLS10byAxOTIuMTY4LjAuMzoyMgojaXB0YWJsZXMgLXQgbmF0IC1BIFBSRVJPVVRJTkcg LXAgdGNwIC0tZHBvcnQgODAgLWkgcHBwMCAtaiBETkFUIC0tdG8gMTkyLjE2OC4wLjE6ODAK CiRJUFRBQkxFUyAtQSBJTlBVVCAtaiBBQ0NFUFQKJElQVEFCTEVTIC1BIEZPUldBUkQgLWog QUNDRVBUCiRJUFRBQkxFUyAtQSBPVVRQVVQgLWogQUNDRVBUCgojLS0tLS0tRW5kIFJ1bGVz ZXQtLS0tLS0jCgplY2hvICIuLi5kb25lIgplY2hvICIiCgplY2hvICItLT4gSVBUQUJMRVMg ZmlyZXdhbGwgbG9hZGVkL2FjdGl2YXRlZCA8LS0iCgoKIyMtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLUVuZCBGaXJld2FsbC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSMjCgogIHNoICQwICBxb3MKICAgOzsKICAgKikKICAgICAgZWNobyAiVXNhZ2U6IGZp cmV3YWxsIChzdGFydHxzdG9wfHJlc3RhcnR8c3RhdHVzKSBFWFRJRiBJTlRJRiIKICAgICAg ZXhpdCAxCmVzYWMKCmV4aXQgMAoK --Next_1025748106---0-202.54.124.151-697-- From stef.coene@docum.org Thu Jul 4 07:34:58 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 4 Jul 2002 08:34:58 +0200 Subject: [LARTC] testing the cbq how to In-Reply-To: <20020704020146.700.qmail@webmail6.rediffmail.com> References: <20020704020146.700.qmail@webmail6.rediffmail.com> Message-ID: > i am getting a internal error, i am not good at perl, so can > anyone tell me how i can monitor the bandwidth and see if > monitor.pl is working or not. I have 2 versions of monitor.pl. One character based and one for in the=20 cgi-bin. Did you download the good one? Can you paste me the output of monitor.pl when you run it on the command=20 line? You can also take a look in the error.log (for me that's=20 /var/log/appache/error.log). If the monitor.pl generates errors, it will= be=20 logged in the logfile. > i am attaching my code to this mail, i will grateful to you if u > can help me identify the problem in my shell script( it doesn't > give me any error -- but i donot know what the errors are hidden You never told us if it's working or not :) The script looks ok. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From hanhbnetfilter@yahoo.com.cn Thu Jul 4 09:00:22 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Thu, 4 Jul 2002 16:00:22 +0800 (CST) Subject: [LARTC] how to control bridge traffic using imq Message-ID: <20020704080022.92316.qmail@web15003.mail.bjs.yahoo.com> bridge was configured with "brctl" three NIC was bind to br0 imq and htb was used to control traffic. #modprobe imq numdevs=3 "htb scripts" #iptables -t mangle -A PREROUTING -i br0 -j IMQ --todev 1 #ip link set imq1 up but this can not do the traffic controling. please tell me how can i do _________________________________________________________ Do You Yahoo!? ÒĝŜÍ·ÛğáÖÔ­ ´óÀËÌÔĦ½ĦŻË­½ĞĤ°Á http://sweepstakes.yahoo.com/bank_surveywave2/ From dzila@tassadar.physics.auth.gr Thu Jul 4 09:07:57 2002 From: dzila@tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Thu, 4 Jul 2002 11:07:57 +0300 (EEST) Subject: [LARTC] tc reliably hangs my system In-Reply-To: <20020703164743.12828DCB1F@tartarus.telenet-ops.be> Message-ID: On Wed, 3 Jul 2002, Stef Coene wrote: > I ran both scripts for 10 minutes (while true; do ./test.sh; sleep 5; done) > and no freeze for me. > > Stef I woke up early today to do some more tests . The hang occurs if there is substantial traffic to the box running the scripts , ie around 300 kb/sec sustained outgoing traffic . The box serves as ftp server . I could not freeze it while the ftp daemon was not running (pureftpd) . When I started the ftp daemon and traffic began to flow , again running the scripts 7-8 times resulted in a frozen system . I am trying to find out the specific command that causes the problem.... Regards , -- ============================================================================= Dimitris Zilaskos Department of Physics @ Aristotle Univercity of Thessaloniki , Greece ============================================================================= From hanhbnetfilter@yahoo.com.cn Thu Jul 4 09:22:08 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Thu, 4 Jul 2002 16:22:08 +0800 (CST) Subject: [LARTC] filter add to which of class Message-ID: <20020704082208.92384.qmail@web15004.mail.bjs.yahoo.com> htb was used to control traffic stuctrul is like that(default is 1:20): |----1:100 |------1:10| 1:1| |____1:110 | |------1:20 #AC="tc filter add dev eth0 protocol ip parent 1:0 prio 1" #$AC u32 match u32 0xac100b00 ffffff00 at 16 flowid 1:10 #$AC u32 match u32 0xac100b01 ffffffff at 16 flowid 1:100 I copy a file to 172.16.11.1 class 1:100 go into effect. I copy a file to 172.16.11.2 class 1:10 did not go into effect but class 1:20 take effect. if a class has sub class, can the filter be added to this class? _________________________________________________________ Do You Yahoo!? ÒĝŜÍ·ÛğáÖÔ­ ´óÀËÌÔĦ½ĦŻË­½ĞĤ°Á http://sweepstakes.yahoo.com/bank_surveywave2/ From dzila@tassadar.physics.auth.gr Thu Jul 4 11:07:08 2002 From: dzila@tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Thu, 4 Jul 2002 13:07:08 +0300 (EEST) Subject: [LARTC] tc reliably hangs my system In-Reply-To: Message-ID: ok , this 2 lines repated anything from 5 to 20 times cause the hang : tc qdisc del dev eth0 ingress tc qdisc add dev eth0 handle ffff: ingress again , the presence of sustained outgoing traffic catalyses the effect . It takes at least 150-200 kbytes/sec to easily cause the hang . Regards , -- ============================================================================= Dimitris Zilaskos Department of Physics @ Aristotle Univercity of Thessaloniki , Greece ============================================================================= From lartc@itsmee.worldonline.co.uk Thu Jul 4 12:40:31 2002 From: lartc@itsmee.worldonline.co.uk (A. Peter Mee) Date: Thu, 4 Jul 2002 12:40:31 +0100 Subject: [LARTC] Allowing CVS, RCP & SCP Message-ID: <017601c2234f$a0c44100$7f00000a@engineering> Hi all, Could someone give me some pointers to achieving stable cvs and rcp access through a fairly restrictive firewall. I'm using a 2.4.18 kernel which defaults to dropping everthing, then punching holes where needed and SNATting the internal network. Single-socket protocols (http, smtp, pop3) do currently function correctly through the firewall so I'm assuming the cvs and rcp/scp protocols are not single-socket. The ftp and irc protocols also function correctly through the firewall. If something more specific about my configuration is needed, I'll be happy to oblige. ;-) TIA Cheers, Pete Mee From alex@bennee.com Thu Jul 4 14:01:07 2002 From: alex@bennee.com (Alex Bennee) Date: Thu, 4 Jul 2002 14:01:07 +0100 (BST) Subject: [LARTC] Allowing CVS, RCP & SCP In-Reply-To: <017601c2234f$a0c44100$7f00000a@engineering> References: <017601c2234f$a0c44100$7f00000a@engineering> Message-ID: <19889.195.99.244.5.1025787667.squirrel@www.bennee.com> A. Peter Mee said: > Hi all, > > Could someone give me some pointers to achieving stable cvs and rcp > access through a fairly restrictive firewall. I'm using a 2.4.18 > kernel which defaults to dropping everthing, then punching holes where > needed and SNATting the internal network. Single-socket protocols > (http, smtp, pop3) do currently function correctly through the firewall > so I'm assuming the cvs and rcp/scp protocols are not single-socket. > The ftp and irc protocols also function correctly through the firewall. ssh is a single socket protocol. If you can ssh through your firewall then you can use scp. You can even tunnel other ports over the single ssh connection (e.g. X). CVS isn't a network protocol. You generally run it using remote shell tools, in the CVS manual it allows you to specifify how with the CVS_RSH evrionment variable. r* tools are bad. Do you need them? > If something more specific about my configuration is needed, I'll be > happy to oblige. ;-) > > TIA > > Cheers, > > Pete Mee > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ Alex www.bennee.com/~alex/ From ahu@ds9a.nl Thu Jul 4 15:34:20 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 16:34:20 +0200 Subject: [LARTC] Allowing CVS, RCP & SCP In-Reply-To: <19889.195.99.244.5.1025787667.squirrel@www.bennee.com> References: <017601c2234f$a0c44100$7f00000a@engineering> <19889.195.99.244.5.1025787667.squirrel@www.bennee.com> Message-ID: <20020704143420.GA12749@outpost.ds9a.nl> On Thu, Jul 04, 2002 at 02:01:07PM +0100, Alex Bennee wrote: > A. Peter Mee said: > > Hi all, > > > > Could someone give me some pointers to achieving stable cvs and rcp > > access through a fairly restrictive firewall. I'm using a 2.4.18 > > kernel which defaults to dropping everthing, then punching holes where > > needed and SNATting the internal network. Single-socket protocols > > (http, smtp, pop3) do currently function correctly through the firewall > > so I'm assuming the cvs and rcp/scp protocols are not single-socket. > > The ftp and irc protocols also function correctly through the firewall. > > ssh is a single socket protocol. If you can ssh through your firewall then > you can use scp. You can even tunnel other ports over the single ssh > connection (e.g. X). > > CVS isn't a network protocol. You generally run it using remote shell tools, > in the CVS manual it allows you to specifify how with the CVS_RSH evrionment > variable. CVS 'pserver' lives on port 2401. Use netstat -an to see which ports have LISTENing sockets, and open up those ports. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Thu Jul 4 15:35:11 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 16:35:11 +0200 Subject: [LARTC] how to control bridge traffic using imq In-Reply-To: <20020704080022.92316.qmail@web15003.mail.bjs.yahoo.com> References: <20020704080022.92316.qmail@web15003.mail.bjs.yahoo.com> Message-ID: <20020704143511.GB12749@outpost.ds9a.nl> On Thu, Jul 04, 2002 at 04:00:22PM +0800, hanhbnetfilter wrote: > bridge was configured with "brctl" > three NIC was bind to br0 > imq and htb was used to control traffic. > #modprobe imq numdevs=3 > "htb scripts" > #iptables -t mangle -A PREROUTING -i br0 -j IMQ > --todev 1 > #ip link set imq1 up > but this can not do the traffic controling. > please tell me how can i do iptables does not function on bridge devices - there are reasons for this, I'm seeing if I can push the right people into submitting a patch though. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Thu Jul 4 15:42:19 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 16:42:19 +0200 Subject: [LARTC] tc reliably hangs my system In-Reply-To: References: Message-ID: <20020704144219.GD12749@outpost.ds9a.nl> On Thu, Jul 04, 2002 at 01:07:08PM +0300, Dimitris Zilaskos wrote: > > ok , this 2 lines repated anything from 5 to 20 times cause the hang : > > tc qdisc del dev eth0 ingress > tc qdisc add dev eth0 handle ffff: ingress > > again , the presence of sustained outgoing traffic catalyses the effect . > It takes at least 150-200 kbytes/sec to easily cause the hang . I've forwarded this to the right kernel people - your description is specific enough, so I have good hope that this bug will be spotted soon! Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Thu Jul 4 15:49:33 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 16:49:33 +0200 Subject: [LARTC] advanced routing for traffic generator-like setup In-Reply-To: <1025482462.638.9.camel@exile> References: <1025482462.638.9.camel@exile> Message-ID: <20020704144933.GF12749@outpost.ds9a.nl> On Mon, Jul 01, 2002 at 02:14:22AM +0200, Filip Sneppe wrote: > How does one set up advanced routing so that when > HostA sends a packet from 1.1.1.1 to 2.2.2.1, it > goes via HostB, and vice versa: a packet from > 2.2.2.1 to 1.1.1.1 also goes via HostB. Only by doing NAT at HostB. Linux is way to smart for this to work otherwise :-) Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Thu Jul 4 15:52:38 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 16:52:38 +0200 Subject: [LARTC] Load balancing In-Reply-To: <365871C49598504A9481DDBEC3EB4955537D@MAIL.InfraSupportEtc.com> References: <365871C49598504A9481DDBEC3EB4955537D@MAIL.InfraSupportEtc.com> Message-ID: <20020704145238.GG12749@outpost.ds9a.nl> On Wed, Jun 26, 2002 at 05:06:36PM -0500, Greg Scott wrote: > I am trying to figure out how to do this: I've tried the howto but just become > hopelessly confused. (I don' think this is a problem in the howto, it's a problem > with my comprehension.) What you want is hard in general. > And I need the ability to change this policy at will, so I can let other departments > use the combined T1s as needed. Incoming or outgoing? Outgoing is pretty easy - just make policy rules to route traffic from different department differently, and use TEQL to distribute outgoing traffic. > I think I can figure out how to route based on the source network, that all makes > sense in the how-to. I can set up different routing tables based on the source IP > address/network. It's the load balancing that is making me crazy - how do I put > together a load-balancing mechanism for those combined T1s that makes sense? TEQL is probably your best bet. There is also the nano-howto by Julian Anastasov. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Thu Jul 4 15:54:11 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 16:54:11 +0200 Subject: [LARTC] filter add to which of class In-Reply-To: <20020704082208.92384.qmail@web15004.mail.bjs.yahoo.com> References: <20020704082208.92384.qmail@web15004.mail.bjs.yahoo.com> Message-ID: <20020704145411.GH12749@outpost.ds9a.nl> On Thu, Jul 04, 2002 at 04:22:08PM +0800, hanhbnetfilter wrote: > htb was used to control traffic > stuctrul is like that(default is 1:20): > > |----1:100 > |------1:10| > 1:1| |____1:110 > | > |------1:20 > > #AC="tc filter add dev eth0 protocol ip parent 1:0 > prio 1" > #$AC u32 match u32 0xac100b00 ffffff00 at 16 flowid > 1:10 > #$AC u32 match u32 0xac100b01 ffffffff at 16 flowid > 1:100 > I copy a file to 172.16.11.1 > class 1:100 go into effect. > I copy a file to 172.16.11.2 > class 1:10 did not go into effect > but class 1:20 take effect. > if a class has sub class, can the filter be added to > this class? With recent versions of htb, yes. -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From devik@cdi.cz Thu Jul 4 15:37:38 2002 From: devik@cdi.cz (devik) Date: Thu, 4 Jul 2002 16:37:38 +0200 (CEST) Subject: [LARTC] Re: Is my comprehend right? In-Reply-To: <200207041230.UAA02224@csnet4.cs.tsinghua.edu.cn> Message-ID: Ok, I cc it to lartc as it can be of general interest. ffz is Find First Zero. So that it is index of first LSB zero. In ffs indexes starts with 1 in ffz with 0. It can be used to do some action for each zero (or one) bit in integer. The simplest code do do f() for each zero bit in x is: unsigned int x,m=3D1,i=3D0; for(;m < 0x80000000; m <<=3D 1,i++) =09if ((m & x) =3D=3D 0) f(i) The code above will take about 32*4 x86 instructions (and,jz,shl,jnc). There is possibility to write this in paralel fashion but GCC will not do it. In direct implementation of code there is little ILP (only jz+shl) so that is will take at least 128 CPU cycles (not counting f). When there is not many zeros in x the code above will be ineffecient. Let's rewrite it: while (x !=3D 0xffffffff) { =09int i =3D ffz(x); =09f(i); =09x |=3D (1< devik,hello! > > I read the man page of ffs() and looked ffz() in Linux kernel code, and t= hen I queried the assembly code > > "asm ("cntlzw %0,%1" : "=3Dr" (lz) : "r" (x));" > > in the __ilog2() in Linux kernel codethrough google.com. > > I think that ffz(int value) return the number of consecutive zero bit in = the value from leftmost. > > Is my comprehend right? > > But could you explain why ffz() is used in htb_dequeue()? > > I think I can understand the same usage in CBQ code with your help. > > Thanks. > > =3D=3D=3D=3D=3D=3D=3D 2002-07-04 10:52:00 you wrote:=3D=3D=3D=3D=3D=3D=3D > > >find first zero. See man ffs - ffz is negated one with > >a bit different return value. > >I remember I was thinking about it when I first read CBQ > >source. I remember I've figured its function in hour or > >so by reading headers ... > >devik > > > >On Thu, 4 Jul 2002, Huang Xin Gang wrote: > > > >> devik,hello! > >> > >> Thanks for your reply before. > >> Now I have another question for you: > >> I found a function ffz() used in your code of HTB. > >> I want to know why you use this function. > >> > >> I will be appreciate if you reply me. > >> > >> Thanks. > >> > >> =3D=3D=3D=3D=3D=3D=3D 2002-07-02 12:00:00 you wrote:=3D=3D=3D=3D=3D=3D= =3D > >> > >> >you probably should grep in linux/include. Sorry > >> >but finding definition of function is not so hard > >> >task, is it ? > >> >They translate to GCC3 branching hints. > >> >devik > >> > > >> >On Tue, 15 Feb 2000, Huang Xin Gang wrote: > >> > > >> >> Martin=A3=AChello=A3=A1 > >> >> > >> >> Could you tell me the meaning of these two function? > >> >> and what form can I change these functions into C langague? > >> >> > >> >> Thanks a lot! > >> >> > >> >> =A1=A1=A1=A1=A1=A1best regards! > >> >> > >> >> > >> >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1Huang Xin Gang > >> >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1hxgang@csnet4.cs.tsinghua.edu.cn > >> >> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12000-02-15 > >> >> > >> > >> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D > >> > >> > >> best regards! > >> > >> Huang Xin Gang > >> hxgang@csnet4.cs.tsinghua.edu.cn > >> =09=09=09=09=092002-07-04 > >> > > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D > > > best regards! > > Huang Xin Gang > hxgang@csnet4.cs.tsinghua.edu.cn > =09=09=09=09=092000-02-15 > From alex@bennee.com Thu Jul 4 16:04:09 2002 From: alex@bennee.com (Alex Bennee) Date: Thu, 4 Jul 2002 16:04:09 +0100 (BST) Subject: [LARTC] Allowing CVS, RCP & SCP In-Reply-To: <20020704143420.GA12749@outpost.ds9a.nl> References: <20020704143420.GA12749@outpost.ds9a.nl> Message-ID: <8810.195.99.244.5.1025795049.squirrel@www.bennee.com> bert hubert said: > On Thu, Jul 04, 2002 at 02:01:07PM +0100, Alex Bennee wrote: >> A. Peter Mee said: >> > >> > Could someone give me some pointers to achieving stable cvs and rcp >> > access through a fairly restrictive firewall. >> > >> >> CVS isn't a network protocol. You generally run it using remote shell >> tools, in the CVS manual it allows you to specifify how with the >> CVS_RSH evrionment variable. > > CVS 'pserver' lives on port 2401. Use netstat -an to see which ports > have LISTENing sockets, and open up those ports. Quite correct of course. There are numerous ways of accessing remote CVS repositries (see http://www.cvshome.org/docs/manual/cvs_2.html#SEC26). CVS over ssh seems to be the preffered method of large development communities (sourceforge and savanah at least). Once you've got ssh working you don't need to do any additional (network level) work to get CVS running. I would generally be wary of just opening up ports that are listening without being aware of the security implications of using that protocol. The CVS documentation suggests Kerboros over pserver for security. ssh works just as well (the documention only refers to rsh which isecure but replaceable by ssh). Alex www.bennee.com/~alex/ From devik@cdi.cz Thu Jul 4 16:17:04 2002 From: devik@cdi.cz (devik) Date: Thu, 4 Jul 2002 17:17:04 +0200 (CEST) Subject: [LARTC] Re: htb In-Reply-To: <20020701150947.GA5630@ugly.homeip.net> Message-ID: Ok here is solution. 1) the filter is not swallowed. For inner filters you have to use "tc filter show dev lo parent 1:1". If you miss parent keyword nothing will be shown. 2) the code you attached can't work. You wanted to use "default" keyword to direct packets into 1:1 and then use filter attached to 1:1. It can't be done. default is resolved as last instance and MUST point to a LEAF. No other resolution is done then. To solve your prob use catchall u32 filter (src 0.0.0.0 0 f.e.). on 1: and flowid 1:1. devik On Mon, 1 Jul 2002, Oswald Buddenhagen wrote: > On Mon, Jul 01, 2002 at 04:46:12PM +0200, Martin Devera wrote: > > probably I can. but you have to create test case as simple as > > possible. > > > it can't get simpler than the attached, i guess ... :) > as opposed to my previous observations, filters attached to classes of > of the root qdisc are "swallowed" as well (that means, they don't even > show up in "tc filter show dev eth0"). > > > I can't dig thru long codes .. no time. you know .. > > > yeah, i know this pain. > > greetings > > -- > Hi! I'm a .signature virus! Copy me into your ~/.signature, please! > -- > Chaos, panic, and disorder - my work here is done. > From ahu@ds9a.nl Thu Jul 4 16:50:47 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 17:50:47 +0200 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this Message-ID: <20020704155047.GA17160@outpost.ds9a.nl> >From lwn.net: The current development kernel remains 2.5.24. Linus has not released any kernels - or surfaced on the linux-kernel mailing list - since before OLS and the Kernel Summit. Some patches are beginning to show up in his BitKeeper tree, however; they include some SCSI updates, an NTFS update, and, interestingly, a change of the internal x86 clock frequency to 1000 Hz. 1000Hz would mean great things for us shaping people! Also, on a related note, see this on 'firm timers': http://www.cse.ogi.edu/~luca/firm.html More on http://www.cse.ogi.edu/~ashvin/ Thanks for Erik Walthinsen for pointing this out . Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From bm@turtle-entertainment.de Thu Jul 4 17:57:34 2002 From: bm@turtle-entertainment.de (Bjoern Metzdorf) Date: Thu, 4 Jul 2002 18:57:34 +0200 Subject: [LARTC] quake3 issues Message-ID: <002b01c2237b$e4f7f480$81c206d4@office.turtleentertainment.de> Hi, I am using wshaper.htb from wondershaper 1.1a on 2.4.18 with htb2. I have an adsl (german telekom) 128/768 line. I want to be able to play quake3 all the time without lag, even when there are heavy uploads going on. I decided to use the fwmark method, then my line is not influenced at all by other minimize-delay TOS programs. So I put marked all quake packets (-p udp --dport 20000:35000 -J MARK --set-mark 1). Here you go: ----------------------------------------------------------- DOWNLINK=2300 UPLINK=2300 DEV=eth0 # install root HTB, point default traffic to 1:20: tc qdisc add dev $DEV root handle 1: htb default 20 # shape everything at $UPLINK speed - this prevents huge queues in your # DSL modem which destroy latency: tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit \ burst 6k # high prio class 1:10: tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \ burst 6k prio 1 # bulk & default class 1:20 - gets slightly less traffic, # and a lower priority: tc class add dev $DEV parent 1:1 classid 1:20 htb \ rate $[9*$UPLINK/10]kbit burst 6k prio 2 # all get Stochastic Fairness: tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10 # filters: quake and ping tc filter add dev $DEV parent 1:0 protocol ip prio 1 handle 1 fw \ flowid 1:10 tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ match ip protocol 1 0xff flowid 1:10 ----------------------------------------------------------- So far, so good. The only problem I have is that, if I dont play quake, all the normal traffic gets only 90% of my line speed ($[9*$UPLINK/10] kbit). But I want that traffic to get 100%, but only if I dont play). Ok, then i modified the 1:20 class to have a ceil statement: ----------------------------------------------------------- tc class add dev $DEV parent 1:1 classid 1:20 htb \ rate $[9*$UPLINK/10]kbit ceil ${UPLINK}kbit \ burst 6k prio 2 ----------------------------------------------------------- In theorie everything should be fine now, 1:20 gets the whole line as long as 1:10 doesn't need any bandwidth. Problem: I have lag in quake! So what do you guys think? Is there any way to limit 1:20 to exactly 90% uplink, as soon as 1:10 has activity < 10% uplink? Then quake should have enough spare bandwidth. I tried lower burst settings without luck. Thanks for your help. Greetings, Bjoern From bm@turtle-entertainment.de Thu Jul 4 18:04:02 2002 From: bm@turtle-entertainment.de (Bjoern Metzdorf) Date: Thu, 4 Jul 2002 19:04:02 +0200 Subject: [LARTC] quake3 issues References: <002b01c2237b$e4f7f480$81c206d4@office.turtleentertainment.de> Message-ID: <006601c2237c$cc4b50c0$81c206d4@office.turtleentertainment.de> Oops, > Here you go: > ----------------------------------------------------------- > DOWNLINK=2300 > UPLINK=2300 > DEV=eth0 This should read: DOWNLINK=768 UPLINK=128 DEV=eth0 pasted the wrong file, sorry. Greetings, Bjoern From stef.coene@docum.org Thu Jul 4 18:28:07 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 4 Jul 2002 19:28:07 +0200 Subject: [LARTC] quake3 issues In-Reply-To: <002b01c2237b$e4f7f480$81c206d4@office.turtleentertainment.de> References: <002b01c2237b$e4f7f480$81c206d4@office.turtleentertainment.de> Message-ID: <20020704172808.2455DDB96C@tartarus.telenet-ops.be> > # install root HTB, point default traffic to 1:20: > tc qdisc add dev $DEV root handle 1: htb default 20 > tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit \ > burst 6k > tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \ > burst 6k prio 1 > tc class add dev $DEV parent 1:1 classid 1:20 htb \ > rate $[9*$UPLINK/10]kbit burst 6k prio 2 > So far, so good. > > The only problem I have is that, if I dont play quake, all the normal > traffic gets only 90% of my line speed ($[9*$UPLINK/10] kbit). But I wa= nt > that traffic to get 100%, but only if I dont play). > > Ok, then i modified the 1:20 class to have a ceil statement: > > ----------------------------------------------------------- > tc class add dev $DEV parent 1:1 classid 1:20 htb \ > rate $[9*$UPLINK/10]kbit ceil ${UPLINK}kbit \ > burst 6k prio 2 > ----------------------------------------------------------- > > In theorie everything should be fine now, 1:20 gets the whole line as l= ong > as 1:10 doesn't need any bandwidth. > > Problem: I have lag in quake! If you read the htb pages, you can find some more info about delays. You= can=20 try to give the quake class a lower prio. > So what do you guys think? > > Is there any way to limit 1:20 to exactly 90% uplink, as soon as 1:10 h= as > activity < 10% uplink? Then quake should have enough spare bandwidth. I > tried lower burst settings without luck. I don't think it's possible without external scripting. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From LIEVEN@terra.es Thu Jul 4 18:48:31 2002 From: LIEVEN@terra.es (LIEVEN) Date: Thu, 04 Jul 2002 19:48:31 +0200 Subject: [LARTC] advanced routing for traffic generator-like setup Message-ID: <109cc210d612.10d612109cc2@teleline.es> This is a multi-part message in MIME format. ----3df7366759f5994 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit You can enable Zebra routing because both host are in different networks maybe ripd a possible solution this issue http://www.guadawireless.net -.-.LievenX..--. ----- Mensaje Original ----- De: bert hubert Fecha: Jueves, Julio 4, 2002 4:49 pm Asunto: Re: [LARTC] advanced routing for traffic generator-like setup > On Mon, Jul 01, 2002 at 02:14:22AM +0200, Filip Sneppe wrote: > > > How does one set up advanced routing so that when > > HostA sends a packet from 1.1.1.1 to 2.2.2.1, it > > goes via HostB, and vice versa: a packet from > > 2.2.2.1 to 1.1.1.1 also goes via HostB. > > Only by doing NAT at HostB. Linux is way to smart for this to work > otherwise:-) > > Regards, > > bert > > -- > http://www.PowerDNS.com Versatile DNS Software & Services > http://www.tk the dot in .tk > http://lartc.org Linux Advanced Routing & Traffic > Control HOWTO > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ----3df7366759f5994 Content-Type: text/x-vcard; name="LIEVEN.terra.es.vcf"; charset="iso-8859-1" Content-Disposition: attachment; filename="LIEVEN.terra.es.vcf" Content-Description: Card for LIEVEN Content-Transfer-Encoding: quoted-printable begin=3Avcard n=3A=3BLievenX version=3A2=2E1 end=3Avcard ----3df7366759f5994-- From ahu@ds9a.nl Thu Jul 4 19:24:44 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 20:24:44 +0200 Subject: [LARTC] tc reliably hangs my system In-Reply-To: <20020704144219.GD12749@outpost.ds9a.nl> References: <20020704144219.GD12749@outpost.ds9a.nl> Message-ID: <20020704182444.GA20870@outpost.ds9a.nl> On Thu, Jul 04, 2002 at 04:42:19PM +0200, bert hubert wrote: > I've forwarded this to the right kernel people - your description is > specific enough, so I have good hope that this bug will be spotted soon! Ok, I've been told that this might or might not help: http://www.cyberus.ca/~hadi/patches/ing-stats.patch This fixes a known issue that looks like this - can you try if this resolves your problem? This patch will be in in 2.4.19 probably. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ja@ssi.bg Thu Jul 4 22:45:31 2002 From: ja@ssi.bg (Julian Anastasov) Date: Thu, 4 Jul 2002 21:45:31 +0000 (GMT) Subject: [LARTC] how to control bridge traffic using imq In-Reply-To: <20020704143511.GB12749@outpost.ds9a.nl> Message-ID: Hello, On Thu, 4 Jul 2002, bert hubert wrote: > iptables does not function on bridge devices - there are reasons for this, > I'm seeing if I can push the right people into submitting a patch though. Some days ago I uploaded some patches related to bridging. Of course, they are one big ugly hack but allow the bridging to be used in special "IP" mode (wrong word, of course) where the incoming traffic can be received on the slave ports, the output traffic can be sent via the master or the slave interfaces (according to the admin's needs) and ARP is received on both the master and the slave interface to help the neighbouring code to play with such asymmetric routing. The result: full inspection of the traffic forwarded between the slave ports, broadcast forwarding, etc. http://www.linuxvirtualserver.org/~julian/#bridging > Regards, > > bert Regards -- Julian Anastasov From mbabcock@fibrespeed.net Thu Jul 4 20:36:28 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Thu, 04 Jul 2002 15:36:28 -0400 Subject: [LARTC] Per-destination MTUs? Message-ID: <3D24A3BC.8090102@fibrespeed.net> I have some Path-MTU discovery problems it seems; a few sites I deal with can only communicate with us if we use an MTU of 1492 (they're on ADSL of course ...) and another (in Japan) only works for file transfers if we use an MTU of around 1425. Is there any way to tell Linux what the MTU should be on a per-destination basis? -- Michael T. Babcock CTO. FibreSpeed Ltd. From ahu@ds9a.nl Thu Jul 4 20:48:55 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 4 Jul 2002 21:48:55 +0200 Subject: [LARTC] Per-destination MTUs? In-Reply-To: <3D24A3BC.8090102@fibrespeed.net> References: <3D24A3BC.8090102@fibrespeed.net> Message-ID: <20020704194855.GA23137@outpost.ds9a.nl> On Thu, Jul 04, 2002 at 03:36:28PM -0400, Michael T. Babcock wrote: > I have some Path-MTU discovery problems it seems; a few sites I deal > with can only communicate with us if we use an MTU of 1492 (they're on > ADSL of course ...) and another (in Japan) only works for file transfers > if we use an MTU of around 1425. http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.cookbook.mtu-discovery.html -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From mbabcock@fibrespeed.net Thu Jul 4 20:54:06 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Thu, 04 Jul 2002 15:54:06 -0400 Subject: [LARTC] Per-destination MTUs? References: <3D24A3BC.8090102@fibrespeed.net> <20020704194855.GA23137@outpost.ds9a.nl> Message-ID: <3D24A7DE.8010204@fibrespeed.net> bert hubert wrote: >http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.cookbook.mtu-discovery.html > > (Ignoring the fact that I should've looked there in the first place ...) thanks, it works exactly as desired (even on kernel 2.2.19, fwiw). -- Michael T. Babcock CTO, FibreSpeed Ltd. From hanhbnetfilter@yahoo.com.cn Fri Jul 5 02:54:34 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Fri, 5 Jul 2002 09:54:34 +0800 (CST) Subject: [LARTC] HTB and bridge rules Message-ID: <20020705015434.36395.qmail@web15001.mail.bjs.yahoo.com> bridge was configured with "brctl" three NIC was bind to br0 |----| |------| |-----| | B |------|___A__|------| D | |____| | |_____| __|__ | C | |____| A:three NIC was bind to br0:172.16.6.235/24 B:172.16.6.3/24 D:172.16.6.4/24 C:172.16.6.2/24 htb was used to control traffic on A stuctrul is like that(default is 1:20): |----1:100 |------1:10| 1:1| |____1:110 | |------1:20 #AC="tc filter add dev br0 protocol ip parent 1:0 prio 1" #$AC u32 match u32 0xac100600 ffffff00 at 16 flowid 1:100 I copy a file from A to B(or D), class 1:100 go into effect. but when I copy a file from C to B(or D) class 1:100 did not go into effect class 1:20 also do not take effect. please tell me how can i do? _________________________________________________________ Do You Yahoo!? ÒĝŜÍ·ÛğáÖÔ­ ´óÀËÌÔĦ½ĦŻË­½ĞĤ°Á http://sweepstakes.yahoo.com/bank_surveywave2/ From ahu@ds9a.nl Fri Jul 5 12:01:40 2002 From: ahu@ds9a.nl (bert hubert) Date: Fri, 5 Jul 2002 13:01:40 +0200 Subject: [LARTC] HTB and bridge rules In-Reply-To: <20020705015434.36395.qmail@web15001.mail.bjs.yahoo.com> References: <20020705015434.36395.qmail@web15001.mail.bjs.yahoo.com> Message-ID: <20020705110140.GA2067@outpost.ds9a.nl> On Fri, Jul 05, 2002 at 09:54:34AM +0800, hanhbnetfilter wrote: > bridge was configured with "brctl" > three NIC was bind to br0 > > |----| |------| |-----| > | B |------|___A__|------| D | > |____| | |_____| > __|__ > | C | > |____| > > A:three NIC was bind to br0:172.16.6.235/24 > B:172.16.6.3/24 > D:172.16.6.4/24 > C:172.16.6.2/24 > > htb was used to control traffic on A > stuctrul is like that(default is 1:20): Try attaching your qdiscs and filters to actual devices. -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From michelpereira@netsite.com.br Fri Jul 5 14:14:07 2002 From: michelpereira@netsite.com.br (Michel Angelo da Silva Pereira) Date: Fri, 05 Jul 2002 10:14:07 -0300 Subject: [LARTC] Diferences between HTB and CBQ Message-ID: <3D259B9F.50005@netsite.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, what's the diferences between HTB and CBQ? Bye - -- ======================================== Netsite S/A - Security Officer Profissional Certificado Conectiva Linux www.kidmumu.com.br - UIN 4553082 ======================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9JZueKFcUl0ru4isRAkowAKDcCNO2he7sZ8tHxZBhoEA/nP8KrQCgiG8a nV1Cl3GpWLpSAd1Ss4pj8dA= =VQ5i -----END PGP SIGNATURE----- From dzila@tassadar.physics.auth.gr Fri Jul 5 14:35:33 2002 From: dzila@tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Fri, 5 Jul 2002 16:35:33 +0300 (EEST) Subject: [LARTC] tc reliably hangs my system In-Reply-To: <20020704182444.GA20870@outpost.ds9a.nl> Message-ID: > > > http://www.cyberus.ca/~hadi/patches/ing-stats.patch > > This fixes a known issue that looks like this - can you try if this resolves > your problem? This patch will be in in 2.4.19 probably. Thnx . I am using the patch now with success . I can no longer reproduce the hang . Regards , -- ============================================================================= Dimitris Zilaskos Department of Physics @ Aristotle Univercity of Thessaloniki , Greece ============================================================================= From ahu@ds9a.nl Fri Jul 5 15:59:15 2002 From: ahu@ds9a.nl (bert hubert) Date: Fri, 5 Jul 2002 16:59:15 +0200 Subject: [LARTC] tc reliably hangs my system In-Reply-To: References: <20020704182444.GA20870@outpost.ds9a.nl> Message-ID: <20020705145915.GC5919@outpost.ds9a.nl> On Fri, Jul 05, 2002 at 04:35:33PM +0300, Dimitris Zilaskos wrote: > > > > > > http://www.cyberus.ca/~hadi/patches/ing-stats.patch > > > > This fixes a known issue that looks like this - can you try if this resolves > > your problem? This patch will be in in 2.4.19 probably. > > Thnx . I am using the patch now with success . I can no longer reproduce > the hang . Good to hear - I reported the success to the author, Jamal Hadi Salim - thanks for verifying that it helps! Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From stef.coene@docum.org Fri Jul 5 16:19:27 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 5 Jul 2002 17:19:27 +0200 Subject: [LARTC] Diferences between HTB and CBQ In-Reply-To: <3D259B9F.50005@netsite.com.br> References: <3D259B9F.50005@netsite.com.br> Message-ID: <20020705151928.7762EDBA11@tartarus.telenet-ops.be> On Friday 05 July 2002 15:14, Michel Angelo da Silva Pereira wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > =09Hi, what's the diferences between HTB and CBQ? HTB is better :) Use htb if you can. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From mbabcock@fibrespeed.net Fri Jul 5 18:00:27 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Fri, 05 Jul 2002 13:00:27 -0400 Subject: [LARTC] Diferences between HTB and CBQ References: <3D259B9F.50005@netsite.com.br> <20020705151928.7762EDBA11@tartarus.telenet-ops.be> Message-ID: <3D25D0AB.7050104@fibrespeed.net> Stef Coene wrote: >On Friday 05 July 2002 15:14, Michel Angelo da Silva Pereira wrote: > > >> Hi, what's the diferences between HTB and CBQ? >> >> >HTB is better :) > >Use htb if you can. > I have a feeling they may have been looking for a more theoretical angle or discussion on design perspectives ... :) A lot of that is in the HTB3 documentation though, I've found. -- Michael T. Babcock CTO, FibreSpeed Ltd. From tcl@bunzy.net Fri Jul 5 18:26:08 2002 From: tcl@bunzy.net (tc lewis) Date: Fri, 5 Jul 2002 13:26:08 -0400 (EDT) Subject: [LARTC] Diferences between HTB and CBQ In-Reply-To: <3D259B9F.50005@netsite.com.br> Message-ID: On Fri, 5 Jul 2002, Michel Angelo da Silva Pereira wrote: > > Hi, what's the diferences between HTB and CBQ? > the advanced routing & traffic control howto, as well as the htb site, explain the answer to your query a few times over. check out: cbq in the howto: http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.qdisc.classful.html#AEN735 htb in the howto: http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.qdisc.classful.html#AEN867 htb's home site with lots of docs: http://luxik.cdi.cz/~devik/qos/htb/ i learned (what i think is) everything i need to know about htb from those pages, and they even convinced me to build htb into the kernels of a few machines of mine where i may need bandwidth management options sooner or later. good luck. -tcl. From ard@telegraafnet.nl Fri Jul 5 18:31:51 2002 From: ard@telegraafnet.nl (Ard van Breemen) Date: Fri, 5 Jul 2002 19:31:51 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice Message-ID: <20020705173151.GD32493@telegraafnet.nl> Hi, http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html I am not sure who wrote this part or what it was based upon, but since I am working a lot longer now with ip rules, I think I want to add some stuff: The example 4.2.1 refers to the picture above, and does a plain ip rule add from .... table .... The problem with the exampe is that if you connect from the inside (local network) to your if1 ip or if2 ip, that in this example the replies to the local-network are going out if1 or if2... That is not what you want. If we carefully study the ip rule set, we see the first number. This number is the priority, and if you use this priority number in your rule command, it will insert it in the rule list after the rule with the same or lower priority. I am using this to differentiate between known routing, and default routing. So first we set up the link local routing (the things you can reach directly). Actually you don't have to do a thing for that, except setting up the interface. List your local routing to understand: ip route show table main Then we put the default routing into table default. And between the main and the default rule we put rules that differentiate the default routing per provider. example: ############################################################ # set up table main by upping the interfaces ifup eth0 # local net ifup eth1 # provider 1 ifup eth2 # provider 2 # Now set up the default routes in a failover fashion, with the # most important route first(f.i. gw-provider1): ip route add default via gw-provider1 table default # Secondary route when the first gw fails: ip route append default via gw-provider2 table default # (The append is needed because else the routes will clash) # So we have a table with two default routes wich will failover # for eachother (takes about 10 minutes in default config) # We now have a simple failover, which for most of us will not # work, since most providers will have src-ip filtering. # We are going to fix that now: ip route add default via gw-provider1 table rt-provider1 ip route add default via gw-provider2 table rt-provider2 # We now have 2 tables each with a single different default gw. # They are not used, that is what we are going to solve now: ip rule add from ip-eth1 table rt-provider1 prio 32766 ip rule add from ip-eth2 table rt-provider2 prio 32766 # That's it. ############################################################ So let's think about it, and look at it: ard@erwin(slave):~$ /sbin/ip rule list 0: from all lookup local 32766: from all lookup main 32766: from lookup 32767: from all lookup default This is not what we did above, but it is a rule list from a working environment (does www.telegraaf.nl ring a bell?). What we should have seen was this: /sbin/ip rule list 0: from all lookup local 32766: from all lookup main 32766: from lookup rt-provider1 32766: from lookup rt-provider2 32767: from all lookup default The main difference with the example in the document is: - We do *not* have a default route in main - We *have* default routes in the default table - We have rules *after* main, not before main So what is the catch: The only catch is that if you do not have point-to-point connections with your provider, but a /24 for example, then requests coming in from provider2 for the ip-eth1, will go out from your eth2 and not from your eth1. This might be a problem if your /24 is filtered by your ISP. The solution to that is the essence of this story: move the calling of your default route tables from the rules to the last possible moment. So to fix the catch you get two more routing tables: (With a provider3 added for clarity) ############################################################ ip route add net-provider2/24 via gw-provider1 table use-gw-provider1 ip route add net-provider3/24 via gw-provider1 table use-gw-provider1 ip rule add from ip-eth1 table use-gw-provider1 prio 32765 ip route add net-provider1/24 via gw-provider2 table use-gw-provider2 ip route add net-provider3/24 via gw-provider2 table use-gw-provider2 ip rule add from ip-eth2 table use-gw-provider2 prio 32765 ip route add net-provider1/24 via gw-provider3 table use-gw-provider3 ip route add net-provider2/24 via gw-provider3 table use-gw-provider3 ip rule add from ip-eth3 table use-gw-provider3 prio 32765 ############################################################ I hope this makes some sense, and I hope it also is clear that this is only needed for the link-local network of your provider only if it is filtered! Next thing: I was talking about failover earlier: If a gateway is not available (ie, it does not reply to arps), linux will think it is dead within a few minutes, and use the other gateway. But only if it reaches the default table. It reaches that, when it does not have a clue of the outgoing src-ip yet. So if an application makes a connection to a website, and the first gateway is considered dead, it will connect to the website using the second gateway, and therefore bind to ip-eth2. Last thing: this failover thingie can also be a "loadbalanced" thingie as explained in "4.2.2 Load balancing". However: due to bugs in the equalizeing code, I recommend against it. Somewhere inside the kernel it cannot clearly come up with a route, which results in a lot of "cannot happen 777". Next to that: the usage counts of the devices are not correctly incremented and decremented. You have to be very careful and craft an extra non-multipath route before, then remove the existing multi-path route, before bringing down a network device. Else it ends up in an endless "device still in use, waiting". And you will not be able to use the device anymore until you reset some sense into the machine... -- begin ILOVEYOU.VBS 666 Telegraaf Elektronische Media Real geeks don't get viruses end From arthurvl@sci.kun.nl Fri Jul 5 19:13:53 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Fri, 5 Jul 2002 20:13:53 +0200 (MEST) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020705173151.GD32493@telegraafnet.nl> Message-ID: On Fri, 5 Jul 2002, Ard van Breemen wrote: > Hi, > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html > I am not sure who wrote this part or what it was based upon, but > since I am working a lot longer now with ip rules, I think I want > to add some stuff: The stuff that is in the HOWTO was designed and tested back in 1999. Oh, and I am the author. :) > The example 4.2.1 refers to the picture above, and does a plain > ip rule add from .... table .... > The problem with the exampe is that if you connect from the > inside (local network) to your if1 ip or if2 ip, that in this > example the replies to the local-network are going out if1 or > if2... That is not what you want. True. That is indeed a bug. Never saw it in actual practice though: you *should*not* connect to the external IP addresses of your router from the internal network... for various security reasons and such. But you are right. [snip] Whoa, that was large. I'm not sure I entirely follow you though. The *point* of the extra routing tables is that they take precedence over the default routing tables... Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From laurens.van.alphen@keenondots.com Fri Jul 5 19:25:49 2002 From: laurens.van.alphen@keenondots.com (Laurens van Alphen) Date: Fri, 5 Jul 2002 20:25:49 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice Message-ID: <68B054706B911B4189020B333B10A2DA8C84@filmore.corp.keenondots.com> Hi, What is still unclear to me is when the http://www.linuxvirtualserver.org/~julian/#routes patches are needed. What do they do exactly? Thanks in advance, -- Laurens van Alphen -----Original Message----- From: Ard van Breemen [mailto:ard@telegraafnet.nl]=20 Sent: vrijdag 5 juli 2002 19:32 To: lartc@mailman.ds9a.nl Cc: HOWTO@ds9a.nl Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice Hi, http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.ht ml I am not sure who wrote this part or what it was based upon, but since I am working a lot longer now with ip rules, I think I want to add some stuff: The example 4.2.1 refers to the picture above, and does a plain ip rule add from .... table .... The problem with the exampe is that if you connect from the inside (local network) to your if1 ip or if2 ip, that in this example the replies to the local-network are going out if1 or if2... That is not what you want. If we carefully study the ip rule set, we see the first number. This number is the priority, and if you use this priority number in your rule command, it will insert it in the rule list after the=20 rule with the same or lower priority. I am using this to differentiate between known routing, and default routing. So first we set up the link local routing (the things you can reach directly). Actually you don't have to do a thing for that, except setting up the interface. List your local routing to understand: ip route show table main Then we put the default routing into table default. And between the main and the default rule we put rules that differentiate the default routing per provider. example: ############################################################ # set up table main by upping the interfaces ifup eth0 # local net ifup eth1 # provider 1 ifup eth2 # provider 2 # Now set up the default routes in a failover fashion, with the # most important route first(f.i. gw-provider1): ip route add default via gw-provider1 table default # Secondary route when the first gw fails: ip route append default via gw-provider2 table default # (The append is needed because else the routes will clash) # So we have a table with two default routes wich will failover # for eachother (takes about 10 minutes in default config) # We now have a simple failover, which for most of us will not # work, since most providers will have src-ip filtering. # We are going to fix that now: ip route add default via gw-provider1 table rt-provider1 ip route add default via gw-provider2 table rt-provider2 # We now have 2 tables each with a single different default gw. # They are not used, that is what we are going to solve now: ip rule add from ip-eth1 table rt-provider1 prio 32766 ip rule add from ip-eth2 table rt-provider2 prio 32766 # That's it. ############################################################ So let's think about it, and look at it: ard@erwin(slave):~$ /sbin/ip rule list 0: from all lookup local=20 32766: from all lookup main=20 32766: from lookup 32767: from all lookup default=20 This is not what we did above, but it is a rule list from a working environment (does www.telegraaf.nl ring a bell?). What we should have seen was this: /sbin/ip rule list 0: from all lookup local 32766: from all lookup main 32766: from lookup rt-provider1 32766: from lookup rt-provider2 32767: from all lookup default The main difference with the example in the document is: - We do *not* have a default route in main - We *have* default routes in the default table - We have rules *after* main, not before main So what is the catch: The only catch is that if you do not have point-to-point connections with your provider, but a /24 for example, then requests coming in from provider2 for the ip-eth1, will go out from your eth2 and not from your eth1. This might be a problem if your /24 is filtered by your ISP. The solution to that is the essence of this story: move the calling of your default route tables from the rules to the last possible moment. So to fix the catch you get two more routing tables: (With a provider3 added for clarity) ############################################################ ip route add net-provider2/24 via gw-provider1 table use-gw-provider1 ip route add net-provider3/24 via gw-provider1 table use-gw-provider1 ip rule add from ip-eth1 table use-gw-provider1 prio 32765 ip route add net-provider1/24 via gw-provider2 table use-gw-provider2 ip route add net-provider3/24 via gw-provider2 table use-gw-provider2 ip rule add from ip-eth2 table use-gw-provider2 prio 32765 ip route add net-provider1/24 via gw-provider3 table use-gw-provider3 ip route add net-provider2/24 via gw-provider3 table use-gw-provider3 ip rule add from ip-eth3 table use-gw-provider3 prio 32765 ############################################################ I hope this makes some sense, and I hope it also is clear that this is only needed for the link-local network of your provider only if it is filtered! Next thing: I was talking about failover earlier: If a gateway is not available (ie, it does not reply to arps), linux will think it is dead within a few minutes, and use the other gateway. But only if it reaches the default table. It reaches that, when it does not have a clue of the outgoing src-ip yet. So if an application makes a connection to a website, and the first gateway is considered dead, it will connect to the website using the second gateway, and therefore bind to ip-eth2. Last thing: this failover thingie can also be a "loadbalanced" thingie as explained in "4.2.2 Load balancing". However: due to bugs in the equalizeing code, I recommend against it. Somewhere inside the kernel it cannot clearly come up with a route, which results in a lot of "cannot happen 777". Next to that: the usage counts of the devices are not correctly incremented and decremented. You have to be very careful and craft an extra non-multipath route before, then remove the existing multi-path route, before bringing down a network device. Else it ends up in an endless "device still in use, waiting". And you will not be able to use the device anymore until you reset some sense into the machine... --=20 From stef.coene@docum.org Fri Jul 5 19:39:13 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 5 Jul 2002 20:39:13 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020705173151.GD32493@telegraafnet.nl> References: <20020705173151.GD32493@telegraafnet.nl> Message-ID: <20020705183914.EA150DB961@tartarus.telenet-ops.be> Hi, I was rereading the pages in the howto about multiple ISP's and I also fo= und=20 some strange stuff in it. Maybe you can create a patch for Bert to updat= e=20 the howto ? Stef PS. Het wordt hier echt wel een lage-landen onderonsje :) English : lot of low-country (Belgium, The Netherlands) people on the lis= t. On Friday 05 July 2002 19:31, Ard van Breemen wrote: > Hi, > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.h= tml > I am not sure who wrote this part or what it was based upon, but > since I am working a lot longer now with ip rules, I think I want > to add some stuff: > The example 4.2.1 refers to the picture above, and does a plain > ip rule add from .... table .... > The problem with the exampe is that if you connect from the > inside (local network) to your if1 ip or if2 ip, that in this > example the replies to the local-network are going out if1 or > if2... That is not what you want. > > If we carefully study the ip rule set, we see the first number. > This number is the priority, and if you use this priority number > in your rule command, it will insert it in the rule list after the > rule with the same or lower priority. > > I am using this to differentiate between known routing, and > default routing. > > So first we set up the link local routing (the things you can > reach directly). Actually you don't have to do a thing for that, > except setting up the interface. > List your local routing to understand: > ip route show table main > > Then we put the default routing into table default. > And between the main and the default rule we put rules that > differentiate the default routing per provider. > > example: > ############################################################ > # set up table main by upping the interfaces > ifup eth0 # local net > ifup eth1 # provider 1 > ifup eth2 # provider 2 > > # Now set up the default routes in a failover fashion, with the > # most important route first(f.i. gw-provider1): > ip route add default via gw-provider1 table default > # Secondary route when the first gw fails: > ip route append default via gw-provider2 table default > # (The append is needed because else the routes will clash) > # So we have a table with two default routes wich will failover > # for eachother (takes about 10 minutes in default config) > > # We now have a simple failover, which for most of us will not > # work, since most providers will have src-ip filtering. > # We are going to fix that now: > ip route add default via gw-provider1 table rt-provider1 > ip route add default via gw-provider2 table rt-provider2 > # We now have 2 tables each with a single different default gw. > # They are not used, that is what we are going to solve now: > > ip rule add from ip-eth1 table rt-provider1 prio 32766 > ip rule add from ip-eth2 table rt-provider2 prio 32766 > > > # That's it. > ############################################################ > > So let's think about it, and look at it: > ard@erwin(slave):~$ /sbin/ip rule list > 0: from all lookup local > 32766: from all lookup main > 32766: from lookup > 32767: from all lookup default > > This is not what we did above, but it is a rule list from a > working environment (does www.telegraaf.nl ring a bell?). > > What we should have seen was this: > /sbin/ip rule list > 0: from all lookup local > 32766: from all lookup main > 32766: from lookup rt-provider1 > 32766: from lookup rt-provider2 > 32767: from all lookup default > > The main difference with the example in the document is: > - We do *not* have a default route in main > - We *have* default routes in the default table > - We have rules *after* main, not before main > > So what is the catch: > The only catch is that if you do not have point-to-point > connections with your provider, but a /24 for example, then > requests coming in from provider2 for the ip-eth1, will go out > from your eth2 and not from your eth1. This might be a problem if > your /24 is filtered by your ISP. > The solution to that is the essence of this story: move the > calling of your default route tables from the rules to the last > possible moment. > So to fix the catch you get two more routing tables: > (With a provider3 added for clarity) > ############################################################ > ip route add net-provider2/24 via gw-provider1 table use-gw-provider1 > ip route add net-provider3/24 via gw-provider1 table use-gw-provider1 > ip rule add from ip-eth1 table use-gw-provider1 prio 32765 > > ip route add net-provider1/24 via gw-provider2 table use-gw-provider2 > ip route add net-provider3/24 via gw-provider2 table use-gw-provider2 > ip rule add from ip-eth2 table use-gw-provider2 prio 32765 > > ip route add net-provider1/24 via gw-provider3 table use-gw-provider3 > ip route add net-provider2/24 via gw-provider3 table use-gw-provider3 > ip rule add from ip-eth3 table use-gw-provider3 prio 32765 > ############################################################ > > I hope this makes some sense, and I hope it also is clear that > this is only needed for the link-local network of your provider > only if it is filtered! > > > Next thing: I was talking about failover earlier: > If a gateway is not available (ie, it does not reply to arps), > linux will think it is dead within a few minutes, and use the > other gateway. But only if it reaches the default table. > It reaches that, when it does not have a clue of the outgoing > src-ip yet. So if an application makes a connection to a website, > and the first gateway is considered dead, it will connect to the > website using the second gateway, and therefore bind to ip-eth2. > > > Last thing: this failover thingie can also be a "loadbalanced" > thingie as explained in "4.2.2 Load balancing". > However: due to bugs in the equalizeing code, I recommend against > it. Somewhere inside the kernel it cannot clearly come up with a > route, which results in a lot of "cannot happen 777". > Next to that: the usage counts of the devices are not correctly > incremented and decremented. You have to be very careful and craft > an extra non-multipath route before, then remove the existing > multi-path route, before bringing down a network device. Else it > ends up in an endless "device still in use, waiting". And you > will not be able to use the device anymore until you reset some > sense into the machine... --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From arthurvl@sci.kun.nl Fri Jul 5 19:45:12 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Fri, 5 Jul 2002 20:45:12 +0200 (MEST) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <68B054706B911B4189020B333B10A2DA8C84@filmore.corp.keenondots.com> Message-ID: On Fri, 5 Jul 2002, Laurens van Alphen wrote: > What is still unclear to me is when the > http://www.linuxvirtualserver.org/~julian/#routes patches are needed. > What do they do exactly? They add actual dead gateway detection (so that failover in fact does fail over... ;)), alternative routes (so that if multiple routes are defined only the active ones will actually be used), static routes (so that routes don't get deleted by the kernel if the correspondign interface goes down... thus automatically reusing it when it comes back up), and MASQUERADING support for multiple gateways. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From arthurvl@sci.kun.nl Fri Jul 5 19:47:27 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Fri, 5 Jul 2002 20:47:27 +0200 (MEST) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020705183914.EA150DB961@tartarus.telenet-ops.be> Message-ID: On Fri, 5 Jul 2002, Stef Coene wrote: > Hi, > > I was rereading the pages in the howto about multiple ISP's and I also found > some strange stuff in it. Maybe you can create a patch for Bert to update > the howto ? Could you be more precies? :) Doei, Arthur. (Yeah, the type is intentional :)) -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From stef.coene@docum.org Fri Jul 5 19:58:35 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 5 Jul 2002 20:58:35 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: References: Message-ID: <20020705185836.E6C28DB9B4@tartarus.telenet-ops.be> On Friday 05 July 2002 20:47, Arthur van Leeuwen wrote: > On Fri, 5 Jul 2002, Stef Coene wrote: > > Hi, > > > > I was rereading the pages in the howto about multiple ISP's and I als= o > > found some strange stuff in it. Maybe you can create a patch for Ber= t to > > update the howto ? > > Could you be more precies? :) export CVSROOT=3D:pserver:anon@outpost.ds9a.nl:/var/cvsroot cvs login CVS password: [enter 'cvs' (without 's)] cvs co 2.4routing password =3D cvs vi 2.4routing/2.4routing.sgml :wq cvs diff -u > patch uuencode patch patch | mail -s "HOWTO update" HOWTO@ds9a.nl :) Stef From arthurvl@sci.kun.nl Fri Jul 5 20:05:47 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Fri, 5 Jul 2002 21:05:47 +0200 (MEST) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020705185836.E6C28DB9B4@tartarus.telenet-ops.be> Message-ID: On Fri, 5 Jul 2002, Stef Coene wrote: > On Friday 05 July 2002 20:47, Arthur van Leeuwen wrote: > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > Hi, > > > > > > I was rereading the pages in the howto about multiple ISP's and I also > > > found some strange stuff in it. Maybe you can create a patch for Bert to > > > update the howto ? > > > > Could you be more precies? :) > export CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot > cvs login > CVS password: [enter 'cvs' (without 's)] > cvs co 2.4routing > password = cvs > vi 2.4routing/2.4routing.sgml > :wq > cvs diff -u > patch > uuencode patch patch | mail -s "HOWTO update" HOWTO@ds9a.nl On what stuff you found strange, I meant... not on the process of sending in a patch for the HOWTO... Doei, Arthur. (Jeez, nerds... :)) -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From stef.coene@docum.org Fri Jul 5 20:27:52 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 5 Jul 2002 21:27:52 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: References: Message-ID: <20020705192753.92433DC19E@tartarus.telenet-ops.be> On Friday 05 July 2002 21:05, Arthur van Leeuwen wrote: > On Fri, 5 Jul 2002, Stef Coene wrote: > > On Friday 05 July 2002 20:47, Arthur van Leeuwen wrote: > > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > > Hi, > > > > > > > > I was rereading the pages in the howto about multiple ISP's and I > > > > also found some strange stuff in it. Maybe you can create a patc= h > > > > for Bert to update the howto ? > > > > > > Could you be more precies? :) > > > > export CVSROOT=3D:pserver:anon@outpost.ds9a.nl:/var/cvsroot > > cvs login > > CVS password: [enter 'cvs' (without 's)] > > cvs co 2.4routing > > password =3D cvs > > vi 2.4routing/2.4routing.sgml > > > > :wq > > > > cvs diff -u > patch > > uuencode patch patch | mail -s "HOWTO update" HOWTO@ds9a.nl > > On what stuff you found strange, I meant... not on the process of sendi= ng > in a patch for the HOWTO... quoted from my post above : > > > > I was rereading the pages in the howto about multiple ISP's and I quoted from the subject Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice So I was talking about chapter 4.2 : http://www.lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links= =2Ehtml > Doei, Arthur. (Jeez, nerds... :)) A real nerd takes a plane to Canada to talk about traffic shaping :) Yesterday a colleague had a problem. He had a redhat based firewall and=20 installed NT4 on it. After first reboot, lilo was still booting a linux=20 kernel even after fdisk'ing the disk. He couldn't remove the tux-virus := ) Stef --=20 From arthurvl@sci.kun.nl Fri Jul 5 20:39:28 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Fri, 5 Jul 2002 21:39:28 +0200 (MEST) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020705192753.92433DC19E@tartarus.telenet-ops.be> Message-ID: On Fri, 5 Jul 2002, Stef Coene wrote: > On Friday 05 July 2002 21:05, Arthur van Leeuwen wrote: > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > On Friday 05 July 2002 20:47, Arthur van Leeuwen wrote: > > > > On Fri, 5 Jul 2002, Stef Coene wrote: > > > > > Hi, > > > > > > > > > > I was rereading the pages in the howto about multiple ISP's and I > > > > > also found some strange stuff in it. Maybe you can create a patch > > > > > for Bert to update the howto ? > > > > > > > > Could you be more precies? :) > > > > > > export CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot > > > cvs login > > > CVS password: [enter 'cvs' (without 's)] > > > cvs co 2.4routing > > > password = cvs > > > vi 2.4routing/2.4routing.sgml > > > > > > :wq > > > > > > cvs diff -u > patch > > > uuencode patch patch | mail -s "HOWTO update" HOWTO@ds9a.nl > > On what stuff you found strange, I meant... not on the process of sending > > in a patch for the HOWTO... > quoted from my post above : > > > > > I was rereading the pages in the howto about multiple ISP's and I > quoted from the subject > Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice > So I was talking about chapter 4.2 : > http://www.lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html Yeah, that was quite clear. But what did you find particularly strange, other than the style of writing (for which I'm *not* going to apologize :))? > > Doei, Arthur. (Jeez, nerds... :)) > A real nerd takes a plane to Canada to talk about traffic shaping :) No, a real nerd takes a plane to Canada to listen to others talk about traffic shaping. >:) > Yesterday a colleague had a problem. He had a redhat based firewall and > installed NT4 on it. After first reboot, lilo was still booting a linux > kernel even after fdisk'ing the disk. He couldn't remove the tux-virus :) Yes? The disk probably wasn't fully wiped by the NT install, nor was the bootblock cleared. The first will have happened if the kernel was nowhere near the low end of the disk, the second is one of the lesser known issues with Microsoft's fdisk: it will only reset the MBR if you use fdisk /mbr . Doei, Arthur. (Not surprised in the least) -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From ja@ssi.bg Sat Jul 6 00:31:53 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 5 Jul 2002 23:31:53 +0000 (GMT) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020705173151.GD32493@telegraafnet.nl> Message-ID: Hello, On Fri, 5 Jul 2002, Ard van Breemen wrote: > I am using this to differentiate between known routing, and > default routing. Or more correctly, to specify the path between each two subnets, the more specific rules and routes before the others. > # (The append is needed because else the routes will clash) > # So we have a table with two default routes wich will failover > # for eachother (takes about 10 minutes in default config) You can add note about tuning this timeout with gc_interval, gc_timeout and friends. > So what is the catch: > The only catch is that if you do not have point-to-point > connections with your provider, but a /24 for example, then > requests coming in from provider2 for the ip-eth1, will go out > from your eth2 and not from your eth1. This might be a problem if > your /24 is filtered by your ISP. This should be covered from sharing /24 subnet with the provider - the link-local networks. The most usual setups are: 1. shared /30 => routes via peer gateway 2. shared pubnet, ISP/we have one IP from pubnet => link-local routes, gateway is onlink The 2nd case can be split again in 2 cases according to the pubnet owner (ISP has the pubnet or the pubnet is yours). I.e. this explains where is the subnet, on internal or on external interface. Other alternatives? > Last thing: this failover thingie can also be a "loadbalanced" > thingie as explained in "4.2.2 Load balancing". > However: due to bugs in the equalizeing code, I recommend against Yes, equalize does not work if the ISPs filter by src. This flag is simply not in the kernel, only in user space. > it. Somewhere inside the kernel it cannot clearly come up with a > route, which results in a lot of "cannot happen 777". Fixed in 2.4.19pre8, SMP race. > Next to that: the usage counts of the devices are not correctly > incremented and decremented. You have to be very careful and craft > an extra non-multipath route before, then remove the existing > multi-path route, before bringing down a network device. Else it > ends up in an endless "device still in use, waiting". And you > will not be able to use the device anymore until you reset some > sense into the machine... This snafu is also fixed in 2.4.19pre8, it is even killed: the multipath route is deleted due to SMP locking problems. Regards -- Julian Anastasov From stef.coene@docum.org Fri Jul 5 22:43:21 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 5 Jul 2002 23:43:21 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: References: Message-ID: <20020705214322.91A7EDC420@tartarus.telenet-ops.be> > Yeah, that was quite clear. But what did you find particularly strange, > other than the style of writing (for which I'm *not* going to apologize > :))? - All the variables are fine to read, but it's nicer to have an example w= ith=20 real numbers. - "One creates two additional routing tables, say T1 and T2. These are ad= ded=20 in /etc/iproute2/rt_tables" How do you do this ? - "ip route add $P1_NET dev $IF1 src $IP1 table T1" blablabla "ip route add $P1_NET dev $IF1 src $IP1" Why adding allmost the same route ???? - what's the right syntax for $P1_NET ???? I'm not a newbie (anymore, at least that's my opinion), I know what I can= do=20 with the tc command, but ip is sometimes a mistery to me. If I have some= =20 time, I will reread the chapter with the mind of a ip-newbie (no brain=20 adaption needed) to try to update the chapter. =20 But my mind is already on holiday, my body follows sunday :) At least fo= r=20 the next 2 weeks. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From Gareth.Segree@gleanerjm.com Sat Jul 6 02:12:50 2002 From: Gareth.Segree@gleanerjm.com (Segree, Gareth) Date: Fri, 5 Jul 2002 20:12:50 -0500 Subject: [LARTC] Serious Routing problem Message-ID: <706F7FF7ADC24C4E9299261CA739A51F066C73@COMMSRV04.gleanerjm.com> It might seem like I'm asking this question in vain but let me post it for the last time. I have a server with two interfaces 128.187.2.0/16 and 128.187.1.0/16 that was setup by a vendor (I dont think there is any ip routing enabled). I have a hosts on two hubs (server card 1 is on hub 1 128.187.2.1 and server card 2 is on hub 2 128.187.1.1) I have a firewall with two interface cards with the following eth1: 128.187.3.1/24 [hub 1] and eth2: 128.187.4.1/24 [hub 2]. I want each side to talk to the other in the event that one of the network card goes down. I have a firewall setup like the following. eth1: 128.187.3.1/24 and eth2: 128.187.4.1/24 - with clients on each side of the lan with default gateway being the interface that it is connected to. I have done the following: echo 1 > /proc/sys/net/ipv4/ip_forward ip route replace 128.187.1.1 dev eth1 ip route replace 128.187.2.1 dev eth2 >From the firewall I can ping 128.187.1.1 & 128.187.2.1. clients from the 128.187.3.0 side can't ping 128.187.2.1 and clients from the 128.187.4.0 side can't ping 128.187.1.1. How can I allow hosts on the eth1: 128.187.3.1/24 to ping 128.187.2.1 and hosts on eth2: 128.187.4.1/24 to ping 128.187.1.1. Thanks in Advance. From patrick_chan@mtelnet.com Sat Jul 6 03:45:12 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Sat, 6 Jul 2002 10:45:12 +0800 Subject: [LARTC] tc hard problem Message-ID: <80313B62CF86B749B7C416579F394498029874@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22497.26C4F9A0 Content-Type: text/plain; charset="big5" Hi, I have a Linux router which has to do QoS Voice and Data traffic will pass through this router Of cuz, voice traffic is put in first priority than data traffic Can you tell me how can I configure tc in order to meet the following requirements? 1. There are two types of traffic: voice and data 2. The bandwidth to the Internet is just 64K 3. Each voice call occupies 16K bandwidth, so the whole bandwidth can only allows 4 concurrent voice calls 4. The most important and most hard to do: If no voice call, data can use up to 64K bandwidth If there are three voice calls, voice can use up to 16K x 3 = 48K bandwidth, data only can use 16K bandwidth If there are four voice calls, voice can use up to 64K bandwidth, data cannot use any bandwidth Voice always come first, data can only use the bandwidth left. Thanks very much. Patrick ------_=_NextPart_001_01C22497.26C4F9A0 Content-Type: text/html; charset="big5" tc hard problem

Hi,

I have a Linux router which has to do QoS
Voice and Data traffic will pass through this router
Of cuz, voice traffic is put in first priority than data traffic
Can you tell me how can I configure tc in order to meet
the following requirements?

1. There are two types of traffic: voice and data

2. The bandwidth to the Internet is just 64K

3. Each voice call occupies 16K bandwidth, so
the whole bandwidth can only allows 4 concurrent voice calls

4. The most important and most hard to do:
If no voice call, data can use up to 64K bandwidth

If there are three voice calls, voice can use up to 16K x 3 = 48K bandwidth,
data only can use 16K bandwidth

If there are four voice calls, voice can use up to 64K bandwidth,
data cannot use any bandwidth

Voice always come first, data can only use the bandwidth left.


Thanks very much.

Patrick

------_=_NextPart_001_01C22497.26C4F9A0-- From tcl@bunzy.net Sat Jul 6 04:46:11 2002 From: tcl@bunzy.net (tc lewis) Date: Fri, 5 Jul 2002 23:46:11 -0400 (EDT) Subject: [LARTC] Serious Routing problem In-Reply-To: <706F7FF7ADC24C4E9299261CA739A51F066C73@COMMSRV04.gleanerjm.com> Message-ID: er, i didn't really read this whole thing, so this reply is probably worthless, but... > I have a server with two interfaces 128.187.2.0/16 and 128.187.1.0/16 that > was setup by a vendor (I dont think there is any ip routing enabled). doesn't 128.187.1.0/16 bleed into 128.187.2.0/16? i would think there would be problems with that right there. y/n? -tcl. On Fri, 5 Jul 2002, Segree, Gareth wrote: > It might seem like I'm asking this question in vain but let me post it for > the last time. > > I have a server with two interfaces 128.187.2.0/16 and 128.187.1.0/16 that > was setup by a vendor (I dont think there is any ip routing enabled). > > I have a hosts on two hubs (server card 1 is on hub 1 128.187.2.1 and server > card 2 is on hub 2 128.187.1.1) > > I have a firewall with two interface cards with the following eth1: > 128.187.3.1/24 [hub 1] and eth2: 128.187.4.1/24 [hub 2]. > > I want each side to talk to the other in the event that one of the network > card goes down. > > I have a firewall setup like the following. > > eth1: 128.187.3.1/24 and eth2: 128.187.4.1/24 - with clients on each side of > the lan with default gateway being the interface that it is connected to. > > I have done the following: > echo 1 > /proc/sys/net/ipv4/ip_forward > ip route replace 128.187.1.1 dev eth1 > ip route replace 128.187.2.1 dev eth2 > > From the firewall I can ping 128.187.1.1 & 128.187.2.1. > > clients from the 128.187.3.0 side can't ping 128.187.2.1 and clients from > the 128.187.4.0 side can't ping 128.187.1.1. > > How can I allow hosts on the eth1: 128.187.3.1/24 to ping 128.187.2.1 and > hosts on eth2: 128.187.4.1/24 to ping 128.187.1.1. > > Thanks in Advance. > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From ja@ssi.bg Sat Jul 6 10:13:00 2002 From: ja@ssi.bg (Julian Anastasov) Date: Sat, 6 Jul 2002 09:13:00 +0000 (GMT) Subject: [LARTC] Serious Routing problem In-Reply-To: <706F7FF7ADC24C4E9299261CA739A51F066C73@COMMSRV04.gleanerjm.com> Message-ID: Hello, On Fri, 5 Jul 2002, Segree, Gareth wrote: > It might seem like I'm asking this question in vain but let me post it for > the last time. Well, do you have picture of this setup: wires, hosts, hubs, IPs, subnets. It will help for selecting the right solution. Is the problem that rp_filter drops the packets? > Thanks in Advance. Regards -- Julian Anastasov From vanitha@hotpop.com Sat Jul 6 17:07:03 2002 From: vanitha@hotpop.com (Vanitha) Date: Sat, 6 Jul 2002 17:07:03 +0100 Subject: [LARTC] PROMISC mode Message-ID: <006101c22507$329ffde0$260110ac@KOVAITEAM> This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C2250F.8CFF1660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, While implementing CBQ for my network card , i found it has PROMISC mode enabled by default while installing = RedHat-7.3 . What is it ? Is any way related to security. Regards Vanitha ------=_NextPart_000_005E_01C2250F.8CFF1660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
While implementing CBQ for my network = card=20 ,
i found it has PROMISC  mode = enabled by=20 default while installing RedHat-7.3 .
What is it ? Is any way related to=20 security.
 
Regards
Vanitha
------=_NextPart_000_005E_01C2250F.8CFF1660-- From stef.coene@docum.org Sat Jul 6 12:43:37 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 6 Jul 2002 13:43:37 +0200 Subject: [LARTC] PROMISC mode In-Reply-To: <006101c22507$329ffde0$260110ac@KOVAITEAM> References: <006101c22507$329ffde0$260110ac@KOVAITEAM> Message-ID: <20020706114338.DF447DC3E6@tartarus.telenet-ops.be> On Saturday 06 July 2002 18:07, Vanitha wrote: > Hello All, > > While implementing CBQ for my network card , > i found it has PROMISC mode enabled by default while installing RedHat= -7.3 > . What is it ? Is any way related to security. No. It means the network card is capturing all packets that pass the wir= e. =20 If you run tcpdump or other sniffing software (ntop), the network card go= es=20 in promiscuous mode. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From ahu@ds9a.nl Sat Jul 6 13:10:31 2002 From: ahu@ds9a.nl (bert hubert) Date: Sat, 6 Jul 2002 14:10:31 +0200 Subject: [LARTC] tc hard problem In-Reply-To: <80313B62CF86B749B7C416579F394498029874@mail.mtel> References: <80313B62CF86B749B7C416579F394498029874@mail.mtel> Message-ID: <20020706121031.GA28710@outpost.ds9a.nl> On Sat, Jul 06, 2002 at 10:45:12AM +0800, Patrick Chan wrote: > Hi, > > I have a Linux router which has to do QoS > Voice and Data traffic will pass through this router > Of cuz, voice traffic is put in first priority than data traffic > Can you tell me how can I configure tc in order to meet > the following requirements? > > 1. There are two types of traffic: voice and data > > 2. The bandwidth to the Internet is just 64K > > 3. Each voice call occupies 16K bandwidth, so > the whole bandwidth can only allows 4 concurrent voice calls > > 4. The most important and most hard to do: > If no voice call, data can use up to 64K bandwidth > > If there are three voice calls, voice can use up to 16K x 3 = 48K bandwidth, > data only can use 16K bandwidth > > If there are four voice calls, voice can use up to 64K bandwidth, > data cannot use any bandwidth > > Voice always come first, data can only use the bandwidth left. I've tried this and you can't get it perfect. The big thing with voice is that it really hates delays. I think you'll be able to do 3 calls and have data active at the same time. You can easily do this with the PRIO qdisc. Just make sure that all call data, which you can recognize because they are small UDP packets most of the time, and put them in the highest priority band, band 0 or 1 I think. Put the rest in the lowest band. I very much advise the use of 'tcng' http://tcng.sourceforge.net/dist/tcng-8s.tar.gz Configure with ./configure -n and read the example file. It should be pretty easy to write something that does what you want. Also see http://ds9a.nl/ols-presentation/800x600 , near the end. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From sahil@sahil.net.nz Sat Jul 6 13:11:58 2002 From: sahil@sahil.net.nz (Sahil Gupta - Net4U Limited) Date: Sun, 7 Jul 2002 00:11:58 +1200 (NZST) Subject: [LARTC] Graphing In-Reply-To: <20020706121031.GA28710@outpost.ds9a.nl> Message-ID: Hi there, We currently use CBQ to traffic-shape our boxes. Just wondering, does anybody know of a way to graph the traffic flowing to netblocks / ip addresses? Cheers, Sahil From stef.coene@docum.org Sat Jul 6 14:29:34 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 6 Jul 2002 15:29:34 +0200 Subject: [LARTC] Graphing In-Reply-To: References: Message-ID: <20020706132936.28AC9DBA1F@tartarus.telenet-ops.be> On Saturday 06 July 2002 14:11, Sahil Gupta - Net4U Limited wrote: > Hi there, > We currently use CBQ to traffic-shape our boxes. Just wondering, does > anybody know of a way to graph the traffic flowing to netblocks / ip > addresses? I create graphs based on the tc-counters. =20 http://home.docum.org/stef.coene/qos/gui/rrd.html I also monitored what-ever-I-wanted with the counters of iptables/ipchain= s. =20 But I have no graphing script for this. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From ahu@ds9a.nl Sat Jul 6 15:08:59 2002 From: ahu@ds9a.nl (bert hubert) Date: Sat, 6 Jul 2002 16:08:59 +0200 Subject: [LARTC] tc hard problem In-Reply-To: <20020706121031.GA28710@outpost.ds9a.nl> References: <80313B62CF86B749B7C416579F394498029874@mail.mtel> <20020706121031.GA28710@outpost.ds9a.nl> Message-ID: <20020706140858.GA31156@outpost.ds9a.nl> On Sat, Jul 06, 2002 at 02:10:31PM +0200, bert hubert wrote: > > Voice always come first, data can only use the bandwidth left. > > I've tried this and you can't get it perfect. The big thing with voice is > that it really hates delays. I think you'll be able to do 3 calls and have > data active at the same time. Oh, by the way, you need to install rules at *both* ends! Otherwise you have little control over downstream, except for dropping it and hoping tcp slows down enough. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From sahil@sahil.net.nz Sat Jul 6 15:18:33 2002 From: sahil@sahil.net.nz (Sahil Gupta - Net4U Limited) Date: Sun, 7 Jul 2002 02:18:33 +1200 (NZST) Subject: [LARTC] Graphing In-Reply-To: <20020706132936.28AC9DBA1F@tartarus.telenet-ops.be> Message-ID: Stef, Are you using SNMP? We currently have a great model working using SNMP/MRTG but, we want to get away from SNMP as it isn't as accurate as we would like it to be. We are really looking for information off the router itself.... are you able to shed any light to it? Cheers, Sahil --------------------------------------------------------------------- Net4U Limited - New Zealands Premier Internet Service Provider -- Home of the new $24.95 Global Dialup / JetStart Service -- Visit http://www.net4u.co.nz for further information --------------------------------------------------------------------- On Sat, 6 Jul 2002, Stef Coene wrote: > On Saturday 06 July 2002 14:11, Sahil Gupta - Net4U Limited wrote: > > Hi there, > > We currently use CBQ to traffic-shape our boxes. Just wondering, does > > anybody know of a way to graph the traffic flowing to netblocks / ip > > addresses? > I create graphs based on the tc-counters. > http://home.docum.org/stef.coene/qos/gui/rrd.html > I also monitored what-ever-I-wanted with the counters of iptables/ipchains. > But I have no graphing script for this. > > Stef > > -- > > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net > > From stef.coene@docum.org Sat Jul 6 16:00:25 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 6 Jul 2002 17:00:25 +0200 Subject: [LARTC] Graphing In-Reply-To: References: Message-ID: <20020706150026.7785BDC11C@tartarus.telenet-ops.be> On Saturday 06 July 2002 16:18, Sahil Gupta - Net4U Limited wrote: > Stef, > Are you using SNMP? We currently have a great model working using > SNMP/MRTG but, we want to get away from SNMP as it isn't as accurate as= we > would like it to be. We are really looking for information off the rou= ter > itself.... are you able to shed any light to it? I use SNMP so I can monitor the box remotely. But what do you mean with = "it=20 isn't as accurate as we would like it to be. We are really looking for=20 information off the router itzelf" ?? MRTG is great to monitor devices, but for custom made monitor, you better= =20 create your own scripts. I'm leaving for holiday tomorrow morning, so it's possible that you will = have=20 to wait 2 weeks for an answer on you mails. =20 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From hadi@cyberus.ca Sat Jul 6 15:55:17 2002 From: hadi@cyberus.ca (jamal) Date: Sat, 6 Jul 2002 10:55:17 -0400 (EDT) Subject: [LARTC] ANNOUNCE: tc based firewalling Message-ID: Apologies for the mass listing (probably shouldnt have sent to netfilter users, but theres a relation) As an alternative to iptables. It's still in the "use at your own risk" category. http://www.cyberus.ca/~hadi/patches/action.DESCRIPTION for description. Pick the right patch by reading http://www.cyberus.ca/~hadi/patches/action.REVISION cheers, jamal From Gareth.Segree@gleanerjm.com Sat Jul 6 16:39:38 2002 From: Gareth.Segree@gleanerjm.com (Segree, Gareth) Date: Sat, 6 Jul 2002 10:39:38 -0500 Subject: [LARTC] Serious Routing problem Message-ID: <706F7FF7ADC24C4E9299261CA739A51F066C76@COMMSRV04.gleanerjm.com> > Well, do you have picture of this setup: wires, hosts, hubs, IPs, > Subnets. It will help for selecting the right solution. Is the problem > that rp_filter drops the packets? No I can ping both hosts and server from the firewall . I thought that if you created host routes on the firewall and enable ip_forwarding thats all that would be needed. From ja@ssi.bg Sat Jul 6 20:04:42 2002 From: ja@ssi.bg (Julian Anastasov) Date: Sat, 6 Jul 2002 19:04:42 +0000 (GMT) Subject: [LARTC] Serious Routing problem In-Reply-To: <706F7FF7ADC24C4E9299261CA739A51F066C76@COMMSRV04.gleanerjm.com> Message-ID: Hello, On Sat, 6 Jul 2002, Segree, Gareth wrote: > > Well, do you have picture of this setup: wires, hosts, hubs, IPs, > > Subnets. It will help for selecting the right solution. Is the problem > > that rp_filter drops the packets? > No I can ping both hosts and server from the firewall . > > I thought that if you created host routes on the firewall and enable > ip_forwarding thats all that would be needed. Not so easy if you connect one Linux box to another host by using 2 or more devices.... ping can work because by default selects as src IP the preferred source address to the targat host. But from the information provided I assume you have a problem with talks between different subnets. No? At least, I don't have a clear picture of your setup which is essential step before continuing further. Regards -- Julian Anastasov From Gareth.Segree@gleanerjm.com Sat Jul 6 17:57:54 2002 From: Gareth.Segree@gleanerjm.com (Segree, Gareth) Date: Sat, 6 Jul 2002 11:57:54 -0500 Subject: [LARTC] Serious Routing problem Message-ID: <706F7FF7ADC24C4E9299261CA739A51F066C77@COMMSRV04.gleanerjm.com> [128.187.1.1] gw none [128.187.2.1] gw none __________________[eth1-- Server -- eth2]__________________ / \ 24-port Hub 1 24 port Hub 2 +-----------+ +-----------+ +-----------+ +-----------+ /\______________[eth1-- Linux Firewall --eth2]__________________/\ / [128.187.3.1] [128.187.4.1] \ [clients1] [clients2] 128.187.3.0/24 gw eth1 128.187.4.0/24 gw eth2 I want clients1 to be able to reach eth2 on server [128.187.2.1] if eth1 on Server goes down and visa versa. Does this explain better. -----Original Message----- From: Julian Anastasov [mailto:ja@ssi.bg] Sent: Saturday, July 06, 2002 2:05 PM To: Segree, Gareth Cc: 'lartc@mailman.ds9a.nl' Subject: RE: [LARTC] Serious Routing problem Hello, On Sat, 6 Jul 2002, Segree, Gareth wrote: > > Well, do you have picture of this setup: wires, hosts, hubs, IPs, > > Subnets. It will help for selecting the right solution. Is the problem > > that rp_filter drops the packets? > No I can ping both hosts and server from the firewall . > > I thought that if you created host routes on the firewall and enable > ip_forwarding thats all that would be needed. Not so easy if you connect one Linux box to another host by using 2 or more devices.... ping can work because by default selects as src IP the preferred source address to the targat host. But from the information provided I assume you have a problem with talks between different subnets. No? At least, I don't have a clear picture of your setup which is essential step before continuing further. Regards -- Julian Anastasov From ja@ssi.bg Sat Jul 6 21:45:44 2002 From: ja@ssi.bg (Julian Anastasov) Date: Sat, 6 Jul 2002 20:45:44 +0000 (GMT) Subject: [LARTC] Serious Routing problem In-Reply-To: <706F7FF7ADC24C4E9299261CA739A51F066C77@COMMSRV04.gleanerjm.com> Message-ID: Hello, On Sat, 6 Jul 2002, Segree, Gareth wrote: > [128.187.1.1] gw none [128.187.2.1] gw none > __________________[eth1-- Server -- eth2]__________________ > / \ > 24-port Hub 1 24 port Hub 2 > +-----------+ +-----------+ > +-----------+ +-----------+ > /\______________[eth1-- Linux Firewall --eth2]__________________/\ > / [128.187.3.1] [128.187.4.1] \ > [clients1] [clients2] > 128.187.3.0/24 gw eth1 128.187.4.0/24 gw eth2 Hey, your setup is rather complex. OK, where do you think is the problem? Did you really tried to set /proc/sys/net/ipv4/conf/*/rp_filter to 0, both on Server and Firewall? Tests with tcpdump can show what does not work. If rp_filter=1 is the problem and you still require rp_filter=1 then you need some patching: http://www.linuxvirtualserver.org/~julian/#rp_filter_mask http://www.linuxvirtualserver.org/~julian/#medium_id In short, Server and Firewall should allow traffic from the clients to come via the both interfaces. rp_filter=1 allows the traffic to come only from one interface. rp_filter_mask extends the allowed devices according to the medium_id values and routes. Note that rp_filter constrols both ARP and IP. If you decide using the above features then you have to mark each hub with specific medium_id value and then to set medium_id value and rp_filter_mask for each interface to allow traffic from the both mediums. > I want clients1 to be able to reach eth2 on server [128.187.2.1] if eth1 on > Server goes down and visa versa. If you need failover then we come to other features: http://www.linuxvirtualserver.org/~julian/#routes You need to use alternative routes for the local networks, IMO both on Server and Firewall. In short, these 2 boxes will have two routes for the remote subnet, one for each devices. The patches will do passive failover by inspecting the ARP state for all neighbours. If one NIC fails it will be noticed and the alternative route will be used. There are so many variations for the settings so I only can recommend you to read the docs provided on the above URLs. You are just starting ... :) > Does this explain better. Better - yes, enough - no :) Welcome to the world of advanced routing :) There are no many ways to build working setup but there are huge number of settings that can break it :) Regards -- Julian Anastasov From blanda@mnsi.net Sat Jul 6 23:36:10 2002 From: blanda@mnsi.net (Brian) Date: Sat, 6 Jul 2002 18:36:10 -0400 Subject: [LARTC] Redhat 7.3 / SuSE 8.0 Message-ID: I have a question here? why in SuSE 8.0 pro I can slect all the networking options and none of them are gray out? while under Redhat 7.3 most of them are? I can't modify the IP:Netfilter Config under Redhat 7.3? ANY IDEA's why I can't? I am using make xconfig... From GregScott@InfraSupportEtc.com Sun Jul 7 01:17:48 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Sat, 6 Jul 2002 19:17:48 -0500 Subject: [LARTC] RE: Redhat 7.3 / SuSE 8.0 Message-ID: <365871C49598504A9481DDBEC3EB49554756@MAIL.InfraSupportEtc.com> I'll bet something is messed up in your source tree. All the distros = use=20 the same base kernel after all (don't they?) As I recall, the .config from Red Hat sets up the netfilter stuff as = modules. I'll work on cleaning up my compile notes. - Greg -----Original Message----- From: Brian [mailto:blanda@mnsi.net] Sent: Saturday, July 06, 2002 5:36 PM To: lartc@mailman.ds9a.nl; users@lists.freeswan.org; Greg Scott Cc: redhat-list@redhat.com; tonyz@ctitek.com; ken@networkoverlord.com Subject: Redhat 7.3 / SuSE 8.0 I have a question here? why in SuSE 8.0 pro I can slect all the = networking options and none of them are gray out? while under Redhat 7.3 most of = them are? I can't modify the IP:Netfilter Config under Redhat 7.3? ANY IDEA's = why I can't? I am using make xconfig... From blanda@mnsi.net Sun Jul 7 01:37:07 2002 From: blanda@mnsi.net (Brian) Date: Sat, 6 Jul 2002 20:37:07 -0400 Subject: [LARTC] RE: Redhat 7.3 / SuSE 8.0 In-Reply-To: <365871C49598504A9481DDBEC3EB49554756@MAIL.InfraSupportEtc.com> Message-ID: You would think?, but you never know. I am loading SuSE 8.0 on the same box as my Redhat 7.3 box having the problem...hummmmmmmm -----Original Message----- From: Greg Scott [mailto:GregScott@InfraSupportEtc.com] Sent: Saturday, July 06, 2002 8:18 PM To: Brian; lartc@mailman.ds9a.nl; users@lists.freeswan.org Cc: redhat-list@redhat.com; tonyz@ctitek.com; ken@networkoverlord.com Subject: RE: Redhat 7.3 / SuSE 8.0 I'll bet something is messed up in your source tree. All the distros use the same base kernel after all (don't they?) As I recall, the .config from Red Hat sets up the netfilter stuff as modules. I'll work on cleaning up my compile notes. - Greg -----Original Message----- From: Brian [mailto:blanda@mnsi.net] Sent: Saturday, July 06, 2002 5:36 PM To: lartc@mailman.ds9a.nl; users@lists.freeswan.org; Greg Scott Cc: redhat-list@redhat.com; tonyz@ctitek.com; ken@networkoverlord.com Subject: Redhat 7.3 / SuSE 8.0 I have a question here? why in SuSE 8.0 pro I can slect all the networking options and none of them are gray out? while under Redhat 7.3 most of them are? I can't modify the IP:Netfilter Config under Redhat 7.3? ANY IDEA's why I can't? I am using make xconfig... From GregScott@InfraSupportEtc.com Sun Jul 7 04:59:40 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Sat, 6 Jul 2002 22:59:40 -0500 Subject: [LARTC] RE: [Users] FreeS/Wan on Redhat 7.3 Message-ID: <365871C49598504A9481DDBEC3EB49555387@MAIL.InfraSupportEtc.com> Here are my notes for building a FreeS/WAN 2.4.18-3 kernel starting with = the stock kernel and sources from Red Hat 7.3. A few clarifications -=20 The PPTP patch below is referenced in the VPN Masquerade howto - this = patch=20 supports connection tracking with GRE and I enthusiastically thank the folks who put all this together. So I install Linux and the sources, then apply the PPTP patch and build a new kernel. After building this = kernel, I put in the IPSEC stuff and do make xgo and build an IPSEC-enabled = kernel. When I'm done, I have a system with 3 kernels - the original Red Hat = kernel, the PPTP kernel, and the IPSEC kernel that supports both IPSEC tunneling = and=20 has the ability to pass PPTP stuff along to an authentication server = inside the network. If you're building 1.98, you shouldn't need the fixed-up errcheck = program. =20 I haven't yet tried building 1.98 myself. =20 A couple other caveats - These notes are cryptic and made only for my = use. It never occurred to me they would do anyone else any good and I have = references to directories local to my own setup. =20 I figured out my X Windows problem - if you do "shutdown -r now" from = inside a terminal emulator window, that messes up X windows next time. So it's = best to logout first and then reboot I've done this with a couple different clones and Compaq deskpro PCs. I = have=20 never tried any of this with a system with SCSI disks. Geez, the caveats and clarifications are as long as the notes! Here are the notes - I hope they do some good! ********************************************************************** See these URLs: http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-c= ustom-kernel.html http://tldp.org/HOWTO/Kernel-HOWTO-6.html#ss6.3 Put the PPTP patch file in /home/gregs/pptp and do this command: gunzip netfilter-pptp-2.4.17-rev2.patch.gz This creates the file, netfilter-pptp-2.4.17-rev2.patch. Next, copy this file to /usr/src: cp netfilter-pptp-2.4.17-rev2.patch /usr/src cd /usr/src Be sure to make a symbolic link, linux, that points to the real source = tree, like this: ln --symbolic linux-2.4.18-3 linux patch -p0 < netfilter-pptp-2.4.17-rev2.patch cd linux make mrproper cp configs/kernel-2.4.18-i386.config .config cp Makefile Makefile.original pico Makefile Look for a line that looks like this: EXTRAVERSION =3D -3custom Edit this line to say something like: EXTRAVERSION =3D -3PPTP make xconfig Networking options IP: Netfilter Configuration m - PPTP protocol support m - AH/ESP match support This creates a new .config file with the PPTP stuff make dep make clean make bzImage make modules make modules_install /sbin/mkinitrd /boot/initrd-PPTP.img 2.4.18-3PPTP This makes the RAMdisk for loading the EXT3 file system and SCSI = devices. usage: mkinitrd {ImageName} {Subfolder to use from /lib/modules = directory} make install This copies all the files to their various locations. (Do this instead of cp /usr/src/linux/arch/i386/boot/bzImage = /boot/vmlinux-PPTP) ++++++++++++++++++++++++++++++++++++++++++++++++++++ Now for IPSEC (See = http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/install.html) Free S/WAN depends on the gmp developer package. This isn't documented = in the Free S/WAN installation procedures. Be sure to install this package before = building Free S/WAN. For Red Hat Linux 7.3, it is on the 2nd CD. rpm --install /mnt/cdrom/RedHat/gmp-devel-4.0.1-3.i386.rpm=20 ftp the latest Free S/WAN from ftp://ftp.xs4all.nl/pub/crypto/freeswan/ Put the .tar.gz file (freeswan-1.97.tar.gz) into /usr/src on the target = system. cd /usr/src tar -xzf freeswan*.gz=20 This will give you a directory /usr/src/freeswan. Assuming that we already have a customized kernel configured with the = PPTP patches above: Don't forget to edit Makefile again: cd /usr/src/linux Pico Makefile change: EXTRAVERSION =3D -3PPTP to: EXTRAVERSION =3D -3IPSEC197 Now let's build a kernel. (First, don't forget to put in the fixed up utils/errcheck program. See = the email from Sam S.) cd freeswan-1.97 make xgo (See the Free S/WAN documentation) This configures a kernel, (same as make xconfig, make dep, make clean, = make bzImage) After exiting, this should generate lots and lots of output as it does = all those stock kernel make commands and builds a new kernel. Note this error during the build: 53c700.h:40:2: #error "Config.in must define either = CONFIG_53C700_IO_MAPPED or CONFIG_53C700_MEM_MAPPED to use this scsi = core." 53c700.c:155:22: 53c700_d.h: No such file or directory This and other bugs are fixed in release 1.98. In the mean time, see = the email message from Sam S for a workaround. Next do: make kinstall (The same as make modules, make modules_install, make = install.) This should install the new kernel and put all the pieces where they = belong. Don't forget to build another copy of initrd (see above PPTP stuff) to support the ext3 file = system at boot time. Take a look at /etc/grub.conf to make sure the right edits are in place. May need to run Xconfigurator to make X windows work again. May need to set /proc/sys/net/ipv4/conf/eth0/rp_filter =3D '0' for KLIPS = to work. Can also do this with /etc/sysctl.conf *************************************************************************= ************** -----Original Message----- From: Brian [mailto:blanda@mnsi.net] Sent: Saturday, July 06, 2002 2:35 PM To: Greg Scott Subject: RE: [Users] FreeS/Wan on Redhat 7.3 I had no problems installing FreeS/Wan with SuSE 8.0 Pro, it has = FreeS/Wan 1.96 using kernel 2.4.18??? hummmmmmm. Can you please clean-up your = notes and send it to me.. Thank you for doing that. It's work great under SuSE = 8.0 , I even posted a step by step installing and compiling IPSec under SuSE 8.0. I got FreeS/Wan working with SSH Sent and it work GREAT. -----Original Message----- From: Greg Scott [mailto:GregScott@InfraSupportEtc.com] Sent: Saturday, July 06, 2002 3:37 PM To: Brian; redhat-list@redhat.com Cc: users@lists.freeswan.org Subject: RE: [Users] FreeS/Wan on Redhat 7.3 Brian, did you have the same problem with FreeS/WAN 1.97? I was able to get 1.97 to work after some struggles but have not yet tried 1.98. I am using the kernel configuration answers from configs/kernel-2.4.18-i386.config. Here is an extract from my notes on how to set it all up. cd /usr/src Be sure to make a symbolic link, linux, that points to the real source tree, like this: ln --symbolic linux-2.4.18-3 linux cd linux make mrproper I use the Red Hat configuration answers to initially start out, like this: cp configs/kernel-2.4.18-i386.config .config Next, I build a kernel without FreeS/WAN, then do make xgo and and build a kernel with FreeS/WAN support. There was a 1.97 bug and I had to pull out an error checking tool from the 1.98 candidate release. I can clean up my detailed notes and post here if you want - but I have not yet tried a 1.98 build. - Greg -----Original Message----- From: Brian [mailto:blanda@mnsi.net] Sent: Saturday, July 06, 2002 1:14 PM To: redhat-list@redhat.com Cc: users@lists.freeswan.org Subject: [Users] FreeS/Wan on Redhat 7.3 I have been trying to install FreeS/Wan 1.98b for about one week now = and have gotten NO Where. My advice to anyone that wants to run FreeS/Wan buy SuSE 8.0 Pro with FreeS/Wan already included , it will save you from pulling all your hair out, unless you have no hair to begin with. It seems like redhat does = not like FreeS/Wan for some reason, everytime I get FreeS/Wan to work I need = add another fuction to the kernel then after I think I have it, when I = re-start and get to the part starting IPSEc, IT BOMBS out!!!!, telling KLIPS is = now not part of the kernel...LOL I have tryed to re-compile the kernel and de-slect the options that I think caused the problem but with no luck... when I slect the netfilter option, which I need to setup routing , It = bombs out when I restart redhat... _______________________________________________ Users mailing list Users@lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users From ahu@ds9a.nl Sun Jul 7 12:04:44 2002 From: ahu@ds9a.nl (bert hubert) Date: Sun, 7 Jul 2002 13:04:44 +0200 Subject: [LARTC] RE: Redhat 7.3 / SuSE 8.0 In-Reply-To: References: <365871C49598504A9481DDBEC3EB49554756@MAIL.InfraSupportEtc.com> Message-ID: <20020707110444.GA17031@outpost.ds9a.nl> On Sat, Jul 06, 2002 at 08:37:07PM -0400, Brian wrote: > You would think?, but you never know. I am loading SuSE 8.0 on the same box > as my Redhat 7.3 box having the problem...hummmmmmmm Turn on 'experimental features' and turn on 'advanced router' and they will be un-greyed. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From jmunoz@telefonica.net Sun Jul 7 15:51:53 2002 From: jmunoz@telefonica.net (=?ISO-8859-1?Q?Juli=E1n_Mu=F1oz?=) Date: Sun, 7 Jul 2002 14:51:53 +0000 (GMT) Subject: [LARTC] ip aliasing and tc ? Message-ID: How does traffic control behaves with respect of ip aliasing ? I am using IMQ for ingress shapping. How behaves IMQ with an interface eth0:0 ?? (linux ip aliasing, kernel 2.4) iptables -A PREROUTING -t mangel -i eth0:0 -j IMQ doesn't work, so I think it is useless ?? (The queue is before the interface "demultiplexing" ??) On the egress side, idem. --=20 __o _ \<_ (_)/(_) Saludos de Juli=E1n EA4ACL -.- Foro Wireless Madrid http://opennetworks.rg3.net From ahu@ds9a.nl Sun Jul 7 19:26:58 2002 From: ahu@ds9a.nl (bert hubert) Date: Sun, 7 Jul 2002 20:26:58 +0200 Subject: [LARTC] ip aliasing and tc ? In-Reply-To: References: Message-ID: <20020707182658.GA23037@outpost.ds9a.nl> On Sun, Jul 07, 2002 at 02:51:53PM +0000, Juli?n Mu?oz wrote: > How does traffic control behaves with respect of ip aliasing ? > > > I am using IMQ for ingress shapping. > > How behaves IMQ with an interface eth0:0 ?? (linux ip aliasing, kernel > 2.4) > iptables -A PREROUTING -t mangel -i eth0:0 -j IMQ doesn't work, so I think > it is useless ?? (The queue is before the interface "demultiplexing" ??) There is no eth0:0 - it is a fiction created by ifconfig. Just do everything on eth0 and use other filters to separate traffic, perhaps based on source or destination address. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From xerox@foonet.net Sun Jul 7 20:05:38 2002 From: xerox@foonet.net (Creative Internet Techniques) Date: Sun, 7 Jul 2002 15:05:38 -0400 Subject: [LARTC] CBQ/SFQ Setup example please? Message-ID: <000101c225e9$48868ba0$2d00000a@foolaptop> This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C225C7.C174EBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am trying to set up something similar to the following.. #1. I want to use either iptables or tc filter to assign subnets/protocols/etc to a class and have it traffic shape it using sfq. This is really just generic traffic shaping like using CBWFQ on cisco. When I shape something to say 2000kbit I want it at 2000kbit, period. I'm having problems getting it to stay at what I shape it at without borrowing from other classes. All I'm trying to do is just basic traffic shaping on what I select with tc filter or iptables. #2. I want to have say 5 subnets, each subnet I want to guarantee a CIR of 512kbps. All the subnets combined will have 5mbps available to share between them but still Get minimum CIR of 512kbps no matter what. They can borrow the bandwidth >From other classes to use for burst but still needs to maintain the CIR. If possible I would also like to add something like 512kbps cir with burst 1mbit and then share the rest. That way if no one is using the 5 mbit in the class one subnet could use the full 5mbit until Someone else tries to use it then it would give them each 2.5 and so on.. This should use SFQ to give more fairness and improve latency.. I don't want 4000ms latency when the 5mbit is in use.. Also some way in here to deprioritize certain types of packets like icmp and other non essential packets, while prioritizing smaller packets to improve latency in telnet/ssh and other real time applications. If I can figure out how to do that and make it work I will have a lot more questions :> :> I know what I need and I know how to do it with a cisco but I want to use linux because it's much More configurable and scalable, especially without spending a fortune. P.S. If anyone needs help on cisco stuff or network design let me know :> (as long as I can figure out How to replicate it in linux) hehehe THANKS! Paul ------=_NextPart_000_0002_01C225C7.C174EBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am trying to set up something similar to the = following..

 

#1. I want to use either iptables or tc filter to assign subnets/protocols/etc to = a

class and have it traffic shape it using sfq.  This is really just generic = traffic shaping like

using CBWFQ on cisco.  When I shape something to say 2000kbit I want it at 2000kbit, = period.

I’m having problems getting it to stay at what = I shape it at without borrowing from other classes.

All I’m trying to do is just basic traffic = shaping on what I select with tc filter or iptables.

 

#2.  I want to have say 5 subnets, each subnet I want to guarantee a CIR of 512kbps. 

All the subnets combined will have 5mbps available to = share between them but still

Get minimum CIR of 512kbps no matter what.  They can borrow the = bandwidth

From other classes to use for burst but still needs = to maintain the CIR.  If = possible

I would also like to add something like 512kbps cir = with burst 1mbit and then share the rest.

That way if no one is using the 5 mbit in the class one subnet could use the full 5mbit = until

Someone else tries to use it then it would give them = each 2.5 and so on.. This should = use

SFQ to give more fairness and improve latency.. I don’t want 4000ms latency when = the

5mbit is in use.. Also = some way in here to deprioritize certain types of = packets like icmp

and other non essential packets, while prioritizing smaller packets to improve latency = in telnet/ssh

and other real time applications.

 

If I can figure out how to do that and make it work I = will have a lot more questions :> :>

I know what I need and I know how to do it with a = cisco but I want to use linux because it’s much

More configurable and = scalable, especially without spending a fortune.

 

P.S. If anyone needs help on cisco stuff or network design let me know :> (as = long as I can figure out

How to replicate it in linux) hehehe

 

THANKS!

Paul

------=_NextPart_000_0002_01C225C7.C174EBA0-- From ahu@ds9a.nl Sun Jul 7 22:06:45 2002 From: ahu@ds9a.nl (bert hubert) Date: Sun, 7 Jul 2002 23:06:45 +0200 Subject: [LARTC] #lartc IRC channel Message-ID: <20020707210645.GA26341@outpost.ds9a.nl> Hi everybody, Due to the current situation with openprojects.org (operators begging for monetary support), we've moved to irc.oftc.net, which is a very fine IRC network which is managed by rightminded people. If you are new to IRC - a small introduction. To access IRC you need a client, I highly recommend irssi (http://www.irssi.org) for Unix users and mirc for those with Win32. IRC is a very direct medium. It is well suited for chatting. It is however no substitute for email. We currently see people joining the channel and attempting to describe complex problems. While IRC is very good at 'try this? does it work?' kind of conversations, it is not good for passing around large amounts of information. So, the drill is as follows: 0) Search the HOWTO if your question is answered there 1) Post your problem to the mailinglist 2) Mention the problem on #lartc and see if people can/want to help you 3) If a solution was found on IRC, post it to the list so everybody can see it. Do not skip 0 and 1 or risk being ridiculed! Simple small questions are possible exceptions to these rules. Very small irc tutorial: * install irssi * Start irssi * type /server irc.oftc.net * wait a while * type /join #lartc * say 'hi' If you are running an accessfilter (firewall) that drops packets instead of denying connections, the /server bit may take up to a minute! Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From patrick_chan@mtelnet.com Mon Jul 8 04:17:03 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Mon, 8 Jul 2002 11:17:03 +0800 Subject: [LARTC] tc hard problem Message-ID: <80313B62CF86B749B7C416579F394498029896@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2262D.EE71E2A0 Content-Type: text/plain; charset="iso-8859-1" Hello, Thanks for your help first. Basically I am not familar with tc very much. I just copied a config for ethernet from google.com iptables -t mangle -A FORWARD -p tcp --dport 1720 -j TOS --set-tos Maximize-Throughput tc qdisc add dev ppp0 root handle 10: cbq bandwidth 128Kbit avpkt 1000 tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 64Kbit rate 32Kbit allot 1514 weight 3Kbit prio 1 maxburst 20 avpkt 1000 tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 64Kbit rate 32Kbi t allot 1514 weight 3Kbit prio 5 maxburst 20 avpkt 1000 tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15 tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15 tc filter add dev ppp0 parent 10:0 protocol ip prio 1 u32 match ip tos 0x08 0xff flowid 10:100 tc filter add dev ppp0 parent 10:0 protocol ip prio 5 u32 match ip tos 0x00 0xff flowid 10:200 1) Because my requirement does not limit bandwidth, I just wanna set the priority of different types of data? How can I modify the config? 2) How can I change quantum and other parameters to be suitable for ppp, instead of ethernet? Thx very much!!! -----Original Message----- From: bert hubert [mailto:ahu@ds9a.nl] Sent: Saturday, July 06, 2002 8:11 PM To: Patrick Chan Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] tc hard problem On Sat, Jul 06, 2002 at 10:45:12AM +0800, Patrick Chan wrote: > Hi, > > I have a Linux router which has to do QoS > Voice and Data traffic will pass through this router > Of cuz, voice traffic is put in first priority than data traffic > Can you tell me how can I configure tc in order to meet > the following requirements? > > 1. There are two types of traffic: voice and data > > 2. The bandwidth to the Internet is just 64K > > 3. Each voice call occupies 16K bandwidth, so > the whole bandwidth can only allows 4 concurrent voice calls > > 4. The most important and most hard to do: > If no voice call, data can use up to 64K bandwidth > > If there are three voice calls, voice can use up to 16K x 3 = 48K bandwidth, > data only can use 16K bandwidth > > If there are four voice calls, voice can use up to 64K bandwidth, > data cannot use any bandwidth > > Voice always come first, data can only use the bandwidth left. I've tried this and you can't get it perfect. The big thing with voice is that it really hates delays. I think you'll be able to do 3 calls and have data active at the same time. You can easily do this with the PRIO qdisc. Just make sure that all call data, which you can recognize because they are small UDP packets most of the time, and put them in the highest priority band, band 0 or 1 I think. Put the rest in the lowest band. I very much advise the use of 'tcng' http://tcng.sourceforge.net/dist/tcng-8s.tar.gz Configure with ./configure -n and read the example file. It should be pretty easy to write something that does what you want. Also see http://ds9a.nl/ols-presentation/800x600 , near the end. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO ------_=_NextPart_001_01C2262D.EE71E2A0 Content-Type: text/html; charset="iso-8859-1" RE: [LARTC] tc hard problem

Hello,

Thanks for your help first.

Basically I am not familar with tc very much.
I just copied a config for ethernet from google.com

iptables -t mangle -A FORWARD -p tcp --dport 1720 -j TOS --set-tos Maximize-Throughput
tc qdisc add dev ppp0 root handle 10: cbq bandwidth 128Kbit avpkt 1000
tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 64Kbit rate 32Kbit
 allot 1514 weight 3Kbit prio 1 maxburst 20 avpkt 1000
tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 64Kbit rate 32Kbi
t allot 1514 weight 3Kbit prio 5 maxburst 20 avpkt 1000
tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15
tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15
tc filter add dev ppp0 parent 10:0 protocol ip prio 1 u32 match ip tos 0x08 0xff
 flowid 10:100
tc filter add dev ppp0 parent 10:0 protocol ip prio 5 u32 match ip tos 0x00 0xff
 flowid 10:200

1) Because my requirement does not limit bandwidth, I just wanna set the priority
of different types of data? How can I modify the config?
2) How can I change quantum and other parameters to be suitable for ppp, instead of ethernet?

Thx very much!!!



-----Original Message-----
From: bert hubert [mailto:ahu@ds9a.nl]
Sent: Saturday, July 06, 2002 8:11 PM
To: Patrick Chan
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] tc hard problem


On Sat, Jul 06, 2002 at 10:45:12AM +0800, Patrick Chan wrote:
> Hi,
>
> I have a Linux router which has to do QoS
> Voice and Data traffic will pass through this router
> Of cuz, voice traffic is put in first priority than data traffic
> Can you tell me how can I configure tc in order to meet
> the following requirements?
>
> 1. There are two types of traffic: voice and data
>
> 2. The bandwidth to the Internet is just 64K
>
> 3. Each voice call occupies 16K bandwidth, so
> the whole bandwidth can only allows 4 concurrent voice calls
>
> 4. The most important and most hard to do:
> If no voice call, data can use up to 64K bandwidth
>
> If there are three voice calls, voice can use up to 16K x 3 = 48K bandwidth,
> data only can use 16K bandwidth
>
> If there are four voice calls, voice can use up to 64K bandwidth,
> data cannot use any bandwidth
>
> Voice always come first, data can only use the bandwidth left.

I've tried this and you can't get it perfect. The big thing with voice is
that it really hates delays. I think you'll be able to do 3 calls and have
data active at the same time.

You can easily do this with the PRIO qdisc. Just make sure that all call
data, which you can recognize because they are small UDP packets most of the
time, and put them in the highest priority band, band 0 or 1 I think. Put
the rest in the lowest band.

I very much advise the use of 'tcng'
http://tcng.sourceforge.net/dist/tcng-8s.tar.gz

Configure with ./configure -n and read the example file. It should be pretty
easy to write something that does what you want. Also see
http://ds9a.nl/ols-presentation/800x600 , near the end.

Regards,

bert

--
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

------_=_NextPart_001_01C2262D.EE71E2A0-- From fozzie@muppet.mine.nu Mon Jul 8 07:21:00 2002 From: fozzie@muppet.mine.nu (Fozzie) Date: Mon, 8 Jul 2002 02:21:00 -0400 (EDT) Subject: [LARTC] NAT and CBQ Message-ID: I've got a linux box setup as a dedicated router, with CBQ and NAT. I've got the NAT all setup and that part is working ok. I tried HTB first, and then CBQ and both gave me this trouble. Traffic doesn't seem to be hitting my filter rules on outgoing traffic(sending from eth0 out to internet land). Incoming traffic is being bounded perfectly. I was wondering if there's any "issues" that have to be worked out when you have CBQ and NAT on the same box. Thanks in advanced for any help ------------------------------------------------------------------ - cbq.init list ### eth0: queueing disciplines qdisc sfq 103: quantum 1514b qdisc sfq 102: quantum 1514b qdisc sfq 101: quantum 1514b qdisc cbq 1: rate 100Mbit (bounded,isolated) prio no-transmit ### eth0: traffic classes class cbq 1:101 parent 1: leaf 101: rate 102Kbit prio 5 class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit class cbq 1:103 parent 1: leaf 103: rate 204Kbit prio 5 class cbq 1:102 parent 1: leaf 102: rate 204Kbit prio 5 ### eth0: filtering rules filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:101 match 0a000001/ffffffff at 12 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:102 match 0a000002/ffffffff at 12 filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:102 match 0a000004/ffffffff at 12 filter parent 1: protocol ip pref 100 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:102 match 0a000005/ffffffff at 12 filter parent 1: protocol ip pref 100 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:103 match 0a000003/ffffffff at 12 filter parent 1: protocol ip pref 100 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:103 match 0a000006/ffffffff at 12 ### eth1: queueing disciplines qdisc sfq 203: quantum 1514b qdisc sfq 202: quantum 1514b qdisc sfq 201: quantum 1514b qdisc cbq 1: rate 100Mbit (bounded,isolated) prio no-transmit ### eth1: traffic classes class cbq 1:202 parent 1: leaf 202: rate 819Kbit prio 5 class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit class cbq 1:203 parent 1: leaf 203: rate 819Kbit prio 5 class cbq 1:201 parent 1: leaf 201: rate 409Kbit prio 5 ### eth1: filtering rules filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:201 match 0a000001/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:202 match 0a000002/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:202 match 0a000004/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:202 match 0a000005/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:203 match 0a000003/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:203 match 0a000006/ffffffff at 16 ----------------------------------------------------------------------------------------------------- --- iptables -t nat -L -n Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:21 to:10.0.0.1:21 DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:22 to:10.0.0.1:22 DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:25 to:10.0.0.1:25 DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:53 to:10.0.0.1:53 DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:80 to:10.0.0.1:80 DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:110 to:10.0.0.1:110 DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:113 to:10.0.0.1:113 Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.0.0.0/24 0.0.0.0/0 to:24.156.64.5 Chain OUTPUT (policy ACCEPT) target prot opt source destination --- Am Foz, Need Sig. From sdan@terranet.ro Mon Jul 8 07:45:38 2002 From: sdan@terranet.ro (Daniel Sercaianu) Date: Mon, 8 Jul 2002 09:45:38 +0300 (EEST) Subject: [LARTC] NAT and CBQ In-Reply-To: Message-ID: The same problem I encountered myself when I try to SNAT some ip's going through my router. The incoming is shaped ok but the outgoing doesn't seem to hit my rules. I think when the traffic leaves the outgoing interface isn't caught in the filter rules because the source address of the packets is already changed with the address specified in the SNAT rules or with the address of the outgoing interface if you do masquerade. To make some shapers, I think you have to shape the ip of the outgoing interface, but this only works if you want to shape globally only one filter rules because there is only one ip of the outgoing interface you can catch it in the filter rules. If someone can give any clues how we can solve this problem please help us. Thanx, Daniel Sercaianu Terranet Virtual Media sdan@terranet.ro GSM +40 788 837723 On Mon, 8 Jul 2002, Fozzie wrote: > > I've got a linux box setup as a dedicated router, with CBQ and NAT. I've > got the NAT all setup and that part is working ok. I tried HTB first, > and then CBQ and both gave me this trouble. Traffic doesn't seem to be > hitting my filter rules on outgoing traffic(sending from eth0 out to > internet land). Incoming traffic is being bounded perfectly. I was > wondering if there's any "issues" that have to be worked out when you have > CBQ and NAT on the same box. Thanks in advanced for any help > > > ------------------------------------------------------------------ > - cbq.init list > > ### eth0: queueing disciplines > > qdisc sfq 103: quantum 1514b > qdisc sfq 102: quantum 1514b > qdisc sfq 101: quantum 1514b > qdisc cbq 1: rate 100Mbit (bounded,isolated) prio no-transmit > > ### eth0: traffic classes > > class cbq 1:101 parent 1: leaf 101: rate 102Kbit prio 5 > class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit > class cbq 1:103 parent 1: leaf 103: rate 204Kbit prio 5 > class cbq 1:102 parent 1: leaf 102: rate 204Kbit prio 5 > > ### eth0: filtering rules > > filter parent 1: protocol ip pref 100 u32 > filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 > filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:101 > match 0a000001/ffffffff at 12 > filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:102 > match 0a000002/ffffffff at 12 > filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:102 > match 0a000004/ffffffff at 12 > filter parent 1: protocol ip pref 100 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:102 > match 0a000005/ffffffff at 12 > filter parent 1: protocol ip pref 100 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:103 > match 0a000003/ffffffff at 12 > filter parent 1: protocol ip pref 100 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:103 > match 0a000006/ffffffff at 12 > > ### eth1: queueing disciplines > > qdisc sfq 203: quantum 1514b > qdisc sfq 202: quantum 1514b > qdisc sfq 201: quantum 1514b > qdisc cbq 1: rate 100Mbit (bounded,isolated) prio no-transmit > > ### eth1: traffic classes > > class cbq 1:202 parent 1: leaf 202: rate 819Kbit prio 5 > class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit > class cbq 1:203 parent 1: leaf 203: rate 819Kbit prio 5 > class cbq 1:201 parent 1: leaf 201: rate 409Kbit prio 5 > > ### eth1: filtering rules > > filter parent 1: protocol ip pref 100 u32 > filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 > filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:201 > match 0a000001/ffffffff at 16 > filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:202 > match 0a000002/ffffffff at 16 > filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:202 > match 0a000004/ffffffff at 16 > filter parent 1: protocol ip pref 100 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:202 > match 0a000005/ffffffff at 16 > filter parent 1: protocol ip pref 100 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:203 > match 0a000003/ffffffff at 16 > filter parent 1: protocol ip pref 100 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:203 > match 0a000006/ffffffff at 16 > > > ----------------------------------------------------------------------------------------------------- > --- iptables -t nat -L -n > > Chain PREROUTING (policy ACCEPT) > target prot opt source destination > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:21 to:10.0.0.1:21 > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:22 to:10.0.0.1:22 > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:25 to:10.0.0.1:25 > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:53 to:10.0.0.1:53 > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:80 to:10.0.0.1:80 > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:110 to:10.0.0.1:110 > DNAT tcp -- 0.0.0.0/0 24.156.64.5 tcp dpt:113 to:10.0.0.1:113 > > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > SNAT all -- 10.0.0.0/24 0.0.0.0/0 to:24.156.64.5 > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > --- > Am Foz, Need Sig. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From trinity@mailru.com Mon Jul 8 09:58:24 2002 From: trinity@mailru.com (Dmitriy) Date: Mon, 8 Jul 2002 12:58:24 +0400 Subject: [LARTC] fixed RTT Message-ID: <20020708085824.GA24177@mitch.demos.su> Can anybody tell me: is there any way(module, qdisc) which is possible to make a packet wait for a fixed time then dequeue? It is needed for me to get a fixed RTT. Using htb,tbf... I can get only total speed limitations but then a queue is empty rtt of small ICMP packets is smth like 200-300 usec. Will be thankful for any info.(Note: I`d like to make this thing using only Linux tc). Example: (speed is limited to 33.6 Kbit/sec using tbf as leaf node of one CBQ class) [root@rack1 root]# time scp root@10.10.10.65:/boot/vmlinuz-netli /tmp root@10.10.10.65's password: vmlinuz 100% |*************************************************| 907 KB 03:09 real 4m1.375s user 0m0.003s sys 0m0.012s [root@rack1 root]# ping 10.10.10.65 PING 10.10.10.65 (10.10.10.65) from 10.10.10.64 : 56(84) bytes of data. 64 bytes from 10.10.10.65: icmp_seq=0 ttl=254 time=354 usec 64 bytes from 10.10.10.65: icmp_seq=1 ttl=254 time=229 usec --- 10.10.10.65 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.229/0.291/0.354/0.064 ms [root@rack1 root]# -- With Respect Dmitriy Kuznetsov From ahu@ds9a.nl Mon Jul 8 10:39:11 2002 From: ahu@ds9a.nl (bert hubert) Date: Mon, 8 Jul 2002 11:39:11 +0200 Subject: [LARTC] NAT and CBQ In-Reply-To: References: Message-ID: <20020708093911.GA4909@outpost.ds9a.nl> On Mon, Jul 08, 2002 at 09:45:38AM +0300, Daniel Sercaianu wrote: > > The same problem I encountered myself when I try to SNAT some ip's > going through my router. The incoming is shaped ok but the outgoing > doesn't seem to hit my rules. I think when the traffic leaves the outgoing > interface isn't caught in the filter rules because the source address of > the packets is already changed with the address specified in the SNAT > rules or with the address of the outgoing interface if you do masquerade. > To make some shapers, I think you have to shape the ip of the outgoing Exactly - once tc 'sees' your packets they have everything done to them already. Every translation by then will have finished. > interface, but this only works if you want to shape globally only one > filter rules because there is only one ip of the outgoing interface you can catch it in > the filter rules. If someone can give any clues how we can solve this > problem please help us. Add fwmarks - they survive the NAT process and tell you where packets came from. The HOWTO details this. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ard@telegraafnet.nl Mon Jul 8 12:22:00 2002 From: ard@telegraafnet.nl (Ard van Breemen) Date: Mon, 8 Jul 2002 13:22:00 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: References: <20020705173151.GD32493@telegraafnet.nl> Message-ID: <20020708112200.GB987@telegraafnet.nl> On Fri, Jul 05, 2002 at 08:13:53PM +0200, Arthur van Leeuwen wrote: > On Fri, 5 Jul 2002, Ard van Breemen wrote: > > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html > > I am not sure who wrote this part or what it was based upon, but > > since I am working a lot longer now with ip rules, I think I want > > to add some stuff: > The stuff that is in the HOWTO was designed and tested back in 1999. > Oh, and I am the author. :) Ok... I would have written the same example, so I was not sure on who's experience it was based upon. It was not meant as a "the author is stupid", but more like "do I know the author...". I've told this example also to many people (before I even heard about the lartc. I usually do not read HOWTO's or stuff like that), because it was the same setup I was using at home. But as experience evolves, I now know it is not ok. > > The example 4.2.1 refers to the picture above, and does a plain > > ip rule add from .... table .... > > The problem with the exampe is that if you connect from the > > inside (local network) to your if1 ip or if2 ip, that in this > > example the replies to the local-network are going out if1 or > > if2... That is not what you want. > > True. That is indeed a bug. Never saw it in actual practice though: you > *should*not* connect to the external IP addresses of your router from > the internal network... for various security reasons and such. But you are > right. Hmmmm, to the linux kernel, an IP address is not really interface bound, so everybody should be able to connect to any ip address on the router. My filters are usually only based on interface instead of ip addresses. Usually rp_filter will do the remaining work. So I see no harm in connecting to the "external" ip addressess. (Quoted, since they are not really external or completely bound to an interface, you can always arp for them on another interface..., eh..., if rp_filter allows that of-course.) > > [snip] > > Whoa, that was large. I'm not sure I entirely follow you though. > The *point* of the extra routing tables is that they take precedence > over the default routing tables... -----------^^^^^^^ That's exactly my point: default routes make the kernel go "hey I found the route, so I do not have to search anymore", so they should be *after* the normal routing, but *before* the big catchall default route. Anything else not being a default route, should of course go before the normal routing. I like the way Julian describes it: " Or more correctly, to specify the path between each two subnets, the more specific rules and routes before the others." So, eventually we will get a good description and a good practices guide. -- begin ILOVEYOU.VBS 666 Telegraaf Elektronische Media Real geeks don't get viruses end From ard@telegraafnet.nl Mon Jul 8 12:54:40 2002 From: ard@telegraafnet.nl (Ard van Breemen) Date: Mon, 8 Jul 2002 13:54:40 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: References: <20020705173151.GD32493@telegraafnet.nl> Message-ID: <20020708115440.GC987@telegraafnet.nl> On Fri, Jul 05, 2002 at 11:31:53PM +0000, Julian Anastasov wrote: > On Fri, 5 Jul 2002, Ard van Breemen wrote: > > I am using this to differentiate between known routing, and > > default routing. > Or more correctly, to specify the path between > each two subnets, the more specific rules and routes before the > others. Yes... I like. Although too complex for the users that do not know what we are talking about. > > # (The append is needed because else the routes will clash) > > # So we have a table with two default routes wich will failover > > # for eachother (takes about 10 minutes in default config) > You can add note about tuning this timeout with > gc_interval, gc_timeout and friends. Or refer to the page, ehhhh, oops... I remember Bert asking me to write one up :(... > > So what is the catch: > > The only catch is that if you do not have point-to-point > > connections with your provider, but a /24 for example, then > > requests coming in from provider2 for the ip-eth1, will go out > > from your eth2 and not from your eth1. This might be a problem if > > your /24 is filtered by your ISP. > This should be covered from sharing /24 subnet with > the provider - the link-local networks. > > The most usual setups are: > > 1. shared /30 => routes via peer gateway > > 2. shared pubnet, ISP/we have one IP from pubnet => link-local > routes, gateway is onlink > > The 2nd case can be split again in 2 cases according to the pubnet > owner (ISP has the pubnet or the pubnet is yours). I.e. this > explains where is the subnet, on internal or on external > interface. Once again, I like it. This time it is also not complex. > Other alternatives? I think that covers everything: peer-to-peer, and subnets... Is there something else I did not know about? > > Last thing: this failover thingie can also be a "loadbalanced" > > thingie as explained in "4.2.2 Load balancing". > > However: due to bugs in the equalizeing code, I recommend against > Yes, equalize does not work if the ISPs filter by src. > This flag is simply not in the kernel, only in user space. Well, it *does* work in this framework: we only need the multipath code to select a route, and therefore a source ip. Once we got the source ip, we will not hit the multipath route anymore due to the rules... And even if we did, there is a good chance it is still cached :). > > it. Somewhere inside the kernel it cannot clearly come up with a > > route, which results in a lot of "cannot happen 777". > Fixed in 2.4.19pre8, SMP race. Cool! > > Next to that: the usage counts of the devices are not correctly > > incremented and decremented. You have to be very careful and craft > > an extra non-multipath route before, then remove the existing > > multi-path route, before bringing down a network device. Else it > > ends up in an endless "device still in use, waiting". And you > > will not be able to use the device anymore until you reset some > > sense into the machine... > This snafu is also fixed in 2.4.19pre8, it is even killed: > the multipath route is deleted due to SMP locking problems. Do you mean we cannot have multipaths anymore? Or that the fix was to remove the multipath route? -- begin ILOVEYOU.VBS 666 Telegraaf Elektronische Media Real geeks don't get viruses end From ja@ssi.bg Mon Jul 8 13:15:38 2002 From: ja@ssi.bg (Julian Anastasov) Date: Mon, 8 Jul 2002 15:15:38 +0300 (EEST) Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020708115440.GC987@telegraafnet.nl> Message-ID: Hello, On Mon, 8 Jul 2002, Ard van Breemen wrote: > > Or more correctly, to specify the path between > > each two subnets, the more specific rules and routes before the > > others. > Yes... I like. Although too complex for the users that do not > know what we are talking about. Yes, I usually can't write good docs for the user's eyes :) > > Yes, equalize does not work if the ISPs filter by src. > > This flag is simply not in the kernel, only in user space. > Well, it *does* work in this framework: we only need the > multipath code to select a route, and therefore a source ip. Once > we got the source ip, we will not hit the multipath route > anymore due to the rules... And even if we did, there is a good > chance it is still cached :). Yes, the route cache is the only place that remembers these associations. But it is dangerous for the NAT conns, one IP added and some of the connections can die selecting wrong src IP after the cache is autoflushed. > > This snafu is also fixed in 2.4.19pre8, it is even killed: > > the multipath route is deleted due to SMP locking problems. > Do you mean we cannot have multipaths anymore? Or that the fix > was to remove the multipath route? Yes, the kernel removes the whole multipath route if one device from a path is unregistered. Even without such action from the kernel, the user is obligated to delete this multipath route because if we register the same device name, the nexthop will not switch from dead to alive. So, for 2.4 (I'm not sure how the behaviour will change in 2.5 later) the kernel removes the multipaths but note that we (the users) always have to recreate the multipath routes with unregistered devices. Regards -- Julian Anastasov From smohan@vsnl.com Mon Jul 8 13:16:02 2002 From: smohan@vsnl.com (S Mohan) Date: Mon, 8 Jul 2002 17:46:02 +0530 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <20020708112200.GB987@telegraafnet.nl> Message-ID: <00e001c22679$3ef83f30$6300a8c0@smohan> Dear Ard: All your mails seem to come with an attachment I LOVE YOU.VBS 666.dat. Can you check this out lest you end up spreading virus all over? If I'm wrong, forgive me. Mohan -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Ard van Breemen Sent: 08 July, 2002 4:52 PM To: Arthur van Leeuwen Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice On Fri, Jul 05, 2002 at 08:13:53PM +0200, Arthur van Leeuwen wrote: > On Fri, 5 Jul 2002, Ard van Breemen wrote: > > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-link > > s.html > > I am not sure who wrote this part or what it was based upon, but > > since I am working a lot longer now with ip rules, I think I want > > to add some stuff: > The stuff that is in the HOWTO was designed and tested back in 1999. > Oh, and I am the author. :) Ok... I would have written the same example, so I was not sure on who's experience it was based upon. It was not meant as a "the author is stupid", but more like "do I know the author...". I've told this example also to many people (before I even heard about the lartc. I usually do not read HOWTO's or stuff like that), because it was the same setup I was using at home. But as experience evolves, I now know it is not ok. > > The example 4.2.1 refers to the picture above, and does a plain ip > > rule add from .... table .... The problem with the exampe is that if > > you connect from the inside (local network) to your if1 ip or if2 > > ip, that in this example the replies to the local-network are going > > out if1 or if2... That is not what you want. > > True. That is indeed a bug. Never saw it in actual practice though: > you > *should*not* connect to the external IP addresses of your router from > the internal network... for various security reasons and such. But you are > right. Hmmmm, to the linux kernel, an IP address is not really interface bound, so everybody should be able to connect to any ip address on the router. My filters are usually only based on interface instead of ip addresses. Usually rp_filter will do the remaining work. So I see no harm in connecting to the "external" ip addressess. (Quoted, since they are not really external or completely bound to an interface, you can always arp for them on another interface..., eh..., if rp_filter allows that of-course.) > > [snip] > > Whoa, that was large. I'm not sure I entirely follow you though. The > *point* of the extra routing tables is that they take precedence over > the default routing tables... -----------^^^^^^^ That's exactly my point: default routes make the kernel go "hey I found the route, so I do not have to search anymore", so they should be *after* the normal routing, but *before* the big catchall default route. Anything else not being a default route, should of course go before the normal routing. I like the way Julian describes it: " Or more correctly, to specify the path between each two subnets, the more specific rules and routes before the others." So, eventually we will get a good description and a good practices guide. -- From ard@telegraafnet.nl Mon Jul 8 14:50:26 2002 From: ard@telegraafnet.nl ('Ard van Breemen') Date: Mon, 8 Jul 2002 15:50:26 +0200 Subject: [LARTC] "Bug" in howto 4.2.1 Split access and other advice In-Reply-To: <00e001c22679$3ef83f30$6300a8c0@smohan> References: <20020708112200.GB987@telegraafnet.nl> <00e001c22679$3ef83f30$6300a8c0@smohan> Message-ID: <20020708135026.GE987@telegraafnet.nl> On Mon, Jul 08, 2002 at 05:46:02PM +0530, S Mohan wrote: > All your mails seem to come with an attachment I LOVE YOU.VBS 666.dat. > Can you check this out lest you end up spreading virus all over? If I'm > wrong, forgive me. You are not the first one accusing me of that. This is my .signature indented with a # because some mailers (If I am correct only outlook has this wrong behaviour) have problems with plaintext remarks, and show them as attachments, although they really are not. .signature altered for outlook users: -- # begin ILOVEYOU.VBS 666 # Telegraaf Elektronische Media # Real geeks don't get viruses # end From mbabcock@fibrespeed.net Mon Jul 8 15:05:08 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Mon, 08 Jul 2002 10:05:08 -0400 Subject: [LARTC] Re: [OT] non-Virus attachments References: <20020708112200.GB987@telegraafnet.nl> <00e001c22679$3ef83f30$6300a8c0@smohan> <20020708135026.GE987@telegraafnet.nl> Message-ID: <3D299C14.9000309@fibrespeed.net> 'Ard van Breemen' wrote: >You are not the first one accusing me of that. >This is my .signature indented with a # because some mailers (If >I am correct only outlook has this wrong behaviour) have problems >with plaintext remarks, and show them as attachments, although >they really are not. > > It is a great bug for most of my clients; sometimes they even get attachments in their Inbox which they cannot open / double-click :-). Ah well, I'm glad to see that my (Linux-based) spam/virus filter didn't pick it up incorrectly either. -- Michael T. Babcock CTO, FibreSpeed Ltd. From muthu5@sbcglobal.net Mon Jul 8 20:13:01 2002 From: muthu5@sbcglobal.net (Muthukumar Ratty) Date: Mon, 8 Jul 2002 12:13:01 -0700 (PDT) Subject: [LARTC] fixed RTT In-Reply-To: <20020708085824.GA24177@mitch.demos.su> Message-ID: On Mon, 8 Jul 2002, Dmitriy wrote: > Can anybody tell me: is there any way(module, qdisc) which is possible to > make a packet wait for a fixed time then dequeue? It is needed for me to > get a fixed RTT. Using htb,tbf... I can get only total speed limitations > but then a queue is empty rtt of small ICMP packets is smth like 200-300 > usec. Will be thankful for any info.(Note: I`d like to make this thing > using only Linux tc). Just a random thought but dont know if this is doable. If it is possible to do a range check on the length field of a packet using some filters (u32 filter??) then you could Q them in different Qs and then control when they can be sent (>= SOME FIXED TIME) say using tbf. but I am not sure if u32 can do these kinda range check. Any comments? > > > Example: > (speed is limited to 33.6 Kbit/sec using tbf as leaf node of one CBQ class) > > [root@rack1 root]# time scp root@10.10.10.65:/boot/vmlinuz-netli /tmp > root@10.10.10.65's password: > vmlinuz 100% |*************************************************| 907 KB 03:09 > > real 4m1.375s > user 0m0.003s > sys 0m0.012s > > > [root@rack1 root]# ping 10.10.10.65 > PING 10.10.10.65 (10.10.10.65) from 10.10.10.64 : 56(84) bytes of data. > 64 bytes from 10.10.10.65: icmp_seq=0 ttl=254 time=354 usec > 64 bytes from 10.10.10.65: icmp_seq=1 ttl=254 time=229 usec > > --- 10.10.10.65 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/mdev = 0.229/0.291/0.354/0.064 ms > [root@rack1 root]# > > From josh@imagestream.com Mon Jul 8 22:56:15 2002 From: josh@imagestream.com (Joshua Snyder) Date: Mon, 8 Jul 2002 16:56:15 -0500 (EST) Subject: [LARTC] Questions about HTB classes with an SFQ Message-ID: I have read most of the documents regarding both Htb and Sfq and I still am not sure if it is best to put the Sfq on the leaf Htb or to put it closer to the root class. All of the docs for Htb say to put it on the leaf classes but the Sfq stuff says to put it closer to the root(but not on the root). If my case every leaf class is only going to be one machine/user. I want to have fairness between machines(I don't want one person to get all of the bandwidth). I don't think putting Sfq on the leaf classes will get me this, but I haven't been able to find a place that says this for sure... josh From patrick_chan@mtelnet.com Tue Jul 9 05:02:40 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Tue, 9 Jul 2002 12:02:40 +0800 Subject: [LARTC] Priority Queueing on Linux Message-ID: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226FD.780AA4A0 Content-Type: text/plain; charset="iso-8859-1" There is priority queueing in Cisco router. Is there any equivalent implementation for TC on Linux? If yes, how can I configure and can you give me example? Thx. ------_=_NextPart_001_01C226FD.780AA4A0 Content-Type: text/html; charset="iso-8859-1" Priority Queueing on Linux

There is priority queueing in Cisco router.

Is there any equivalent implementation for TC on Linux?

If yes, how can I configure and can you give me example?
Thx.

------_=_NextPart_001_01C226FD.780AA4A0-- From ganesh kumar godavari" Hey guys I've 2 questions: Question 1 ################ I want to see if the bandwidth allocation using cbq is working properly or not I looked into stef coene's beautiful document(http://docum.org) for the monitor.pl. I am not good at perl so can anyone help me to understand if there is anyway I can check if the cbq is working. Question 2 ################## I also want to know if anyone has worked on realserver, the real server client can use either the tcp or udp packets for voice/video transfer. I checked with ethereal. It looks like that the packets are successfully forwarded by my firewall to my server in the private subnet. However, the server seems to be able to finish the tcp handshake with the real player. The last successful connection is the sever sending the client [FIN, ACK]. After that, nothing happens. Why can't the realserver serves the video/voice packets? Thanks Ganesh ########################################################################################### ____________ 10 mbps |---------------| eth0 | | eth 1 |-----| | | internet ------|firewall |----------------| hub |-------------------| 192.168.0.1 | | | |-----| | | |____________| |---------------| 192.168.0.1 is running the following services http, https, pop3, smtp, realserver goal i want to allocate my internal bandwidth the following way - 70% for http/https, realserver - 20% for smtp, pop3 - 5% for tcp packets - 5% for icmp packets ############################################################### #The firewall Scripts ############################################################### #inorder to make the 192.168.0.1 talk to the outside world i run the following script # Set up IP FORWARDing and Masquerading iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE iptables --append FORWARD --in-interface eth1 -j ACCEPT echo 1 > /proc/sys/net/ipv4/ip_forward # Enables packet forwarding by kernel #inorder to redirect requests from firewall to the services we can use the following script iptables -t nat -A PREROUTING -p tcp --dport 21 -i eth0 -j DNAT --to 192.168.0.2:21 iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to 192.168.0.2:22 iptables -t nat -A PREROUTING -p tcp --dport 23 -i eth0 -j DNAT --to 192.168.0.2:23 iptables -t nat -A PREROUTING -p tcp --dport nntp -i eth0 -j DNAT --to 192.168.0.2:22 iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to 192.168.0.2:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -i eth0 -j DNAT --to 192.168.0.2:443 iptables -t nat -A PREROUTING -p tcp --dport 8080 -i eth0 -j DNAT --to 192.168.0.2:8080 iptables -t nat -A PREROUTING -p tcp --dport 7070 -i eth0 -j DNAT --to 192.168.0.2:7070 iptables -t nat -A PREROUTING -p tcp --dport 554 -i eth0 -j DNAT --to 192.168.0.2:554 iptables -t nat -A PREROUTING -p tcp --dport 2687 -i eth0 -j DNAT --to 192.168.0.2:2687 #class based queuing is done this way $INTIF = eth1 $EXTIF = eth0 add_class() { # $1=parent class $2=classid $3=hiband $4=lowband $5=handle $6=style $TC class add dev $INTIF parent $1 classid $2 cbq bandwidth 10Mbit rate $3 allot 1514 weight $4 prio 5 maxburst 20 avpkt 1000 $6 $TC qdisc add dev $INTIF parent $2 sfq quantum 1514b perturb 15 $TC filter add dev $INTIF protocol ip prio 3 handle $5 fw classid $2 } $TC qdisc add dev $INTIF root handle 10: cbq bandwidth 10Mbit avpkt 1000 $TC class add dev $INTIF parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate 64kbit allot 1514 weight 6.4kbit prio 8 maxburst 20 avpkt 1000 bounded #first type of traffic ICMP, TCP-SYN, DNS will be marked '1' by the firewall code #we will give it a bounded bandwidth of 5% of our total incoming bandwidth (64*0.05=3.2) add_class 10:1 10:100 3.2kbit 0.32kbit 1 bounded #second type of traffic SMTP,POP3 will be marked '2' by the firewalling code #we will give it a bounded bandwidth of 5% of our total incoming bandwidth (64*0.05=3.2) add_class 10:1 10:300 3.2kbit 0.32kbit 2 #third type of traffic ssh,ftp,telnet will be marked '3' by the firewalling code #we will give it a bounded bandwidth of 20% of our total incoming bandwidth (64*0.20=12.8) add_class 10:1 10:200 12.8kbit 1.28kbit 3 #last type of traffic is interactive traffic. It will be marked '4' by the firewalling code #we will give it a bounded bandwidth of 70% of our total incoming bandwidth (64*0.70=44.8) add_class 10:1 10:400 44.8kbit 4.48kbit 4 # this is where the marking of packets is done IPTABLES=/sbin/iptables #mark incoming and News traffic with mark value 3 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 21 -d 0/0 -t mangle -j MARK --set-mark 3 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 22 -d 0/0 -t mangle -j MARK --set-mark 3 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 23 -d 0/0 -t mangle -j MARK --set-mark 3 #mark incoming www and Real Server traffic with mark value 4 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 80 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 443 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 7070 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 554 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 8080 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport 2687 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p udp -o $INTIF -s 0/0 --dport 7070 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p udp -o $INTIF -s 0/0 --dport 554 -d 0/0 -t mangle -j MARK --set-mark 4 $IPTABLES -A FORWARD -p udp -o $INTIF -s 0/0 --dport 8080 -d 0/0 -t mangle -j MARK --set-mark 4 #mark incoming mail traffic with mark value 2 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport smtp -d 0/0 -t mangle -j MARK --set-mark 2 $IPTABLES -A FORWARD -p tcp ! --syn -o $INTIF -s 0/0 --dport pop3 -d 0/0 -t mangle -j MARK --set-mark 2 # allow icmp traffic mark it with value 1 $IPTABLES -A FORWARD -p icmp -o $INTIF -t mangle -j MARK --set-mark 1 $IPTABLES -A FORWARD -p tcp --syn -o $INTIF -t mangle -j MARK --set-mark 1 $IPTABLES -A FORWARD -p udp -s 0/0 --dport 53 -o $INTIF -t mangle -j MARK --set-mark 1 $IPTABLES -A INPUT -j ACCEPT $IPTABLES -A FORWARD -j ACCEPT $IPTABLES -A OUTPUT -j ACCEPT the whole shell script can be downloaded from http://cs.uccs.edu/~gkgodava/tfinal.sh i can see that the packets are marked # iptables -L -v -t mangle Chain FORWARD (policy ACCEPT 6404 packets, 1766K bytes) pkts bytes target prot opt in out source destination 0 0 MARK tcp -- any eth1 anywhere anywhere tcp dpt:ftp flags:!SYN,RST,ACK/SYN MARK set 0x3 257 19602 MARK tcp -- any eth1 anywhere anywhere tcp dpt:ssh flags:!SYN,RST,ACK/SYN MARK set 0x3 : : : _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.rediff.com/jobs From vanitha@hotpop.com Tue Jul 9 12:15:25 2002 From: vanitha@hotpop.com (Vanitha) Date: Tue, 9 Jul 2002 12:15:25 +0100 Subject: [LARTC] cbq & iptables nat problems References: <20020709041739.31197.qmail@webmail10.rediffmail.com> Message-ID: <009001c22739$fa5d68c0$260110ac@KOVAITEAM> ----- Original Message ----- From: "ganesh kumar godavari" To: ; Cc: Sent: Tuesday, July 09, 2002 5:17 AM Subject: [LARTC] cbq & iptables nat problems Hello, To find out wether CBQ is SET on the device or not , use the command #ip link show This would show the queue attached to the device To find out the exact flow transmission in bits/bytes use iptraf. Regards Vanitha > Hey guys > > I've 2 questions: > > Question 1 > ################ > I want to see if the bandwidth allocation using cbq is working > properly or not > I looked into stef coene's beautiful document(http://docum.org) > for the monitor.pl. > I am not good at perl so can anyone help me to understand if there > is anyway I can check if the cbq is working. > From lartc@itsmee.worldonline.co.uk Tue Jul 9 08:53:38 2002 From: lartc@itsmee.worldonline.co.uk (A. Peter Mee) Date: Tue, 9 Jul 2002 08:53:38 +0100 Subject: [LARTC] Ingress - No such file or directory Message-ID: <022901c2271d$bd93a560$7f00000a@engineering> Hi all, (My apologies if this appears to be a repost - my mail yesterday does not appear to have got to the list.) I am attempting to implement the SYN flood protection scheme as presented in LARTC. Unfortunately, when I attempt `tc qdisc add dev eth0 handle ffff: ingress` I get the error: RTNETLINK answers: No such file or directory I have seen this referenced several times on this mailing list, but I appear to have a seperate set of circumstances. I am using a kernal 2.4.18 with Ingress as a module (sch_ingress.o exists in the location /lib/modules/2.4.18/kernel/net/sched), and am able to load it with insmod and remove it with rmmod. Regardless of the state of the sch_ingress.o module, I get the same error. Perhaps someone can point me in the correct direction? TIA Best regards, A. Peter Mee From ahu@ds9a.nl Tue Jul 9 10:42:45 2002 From: ahu@ds9a.nl (bert hubert) Date: Tue, 9 Jul 2002 11:42:45 +0200 Subject: [LARTC] Ingress - No such file or directory In-Reply-To: <022901c2271d$bd93a560$7f00000a@engineering> References: <022901c2271d$bd93a560$7f00000a@engineering> Message-ID: <20020709094245.GA26593@outpost.ds9a.nl> On Tue, Jul 09, 2002 at 08:53:38AM +0100, A. Peter Mee wrote: > I am attempting to implement the SYN flood protection scheme as presented in > LARTC. Unfortunately, when I attempt `tc qdisc add dev eth0 handle ffff: > ingress` I get the error: > > RTNETLINK answers: No such file or directory If you get an error in the last two lines of the script, try this version of iproute instead: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss010824.tar.gz. (local mirror) Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Tue Jul 9 10:46:58 2002 From: ahu@ds9a.nl (bert hubert) Date: Tue, 9 Jul 2002 11:46:58 +0200 Subject: [LARTC] Priority Queueing on Linux In-Reply-To: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> References: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> Message-ID: <20020709094658.GB26593@outpost.ds9a.nl> On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: > There is priority queueing in Cisco router. > > Is there any equivalent implementation for TC on Linux? > > If yes, how can I configure and can you give me example? Please dig up a link so we can see what 'priority queueing' actually *is*. But I bet that tc has it. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Tue Jul 9 10:55:41 2002 From: ahu@ds9a.nl (bert hubert) Date: Tue, 9 Jul 2002 11:55:41 +0200 Subject: [LARTC] cbq & iptables nat problems In-Reply-To: <20020709041739.31197.qmail@webmail10.rediffmail.com> References: <20020709041739.31197.qmail@webmail10.rediffmail.com> Message-ID: <20020709095541.GC26593@outpost.ds9a.nl> On Tue, Jul 09, 2002 at 04:17:39AM -0000, ganesh kumar godavari wrote: > server in the private subnet. However, the server seems to be able > to finish the tcp handshake with the real player. The last > > successful connection is the sever sending the client [FIN, ACK]. > After that, nothing happens. Why can't the realserver FIN,ACK means that the connection was closed by an application. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From arc_of_descent@gmx.net Tue Jul 9 12:13:37 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Tue, 9 Jul 2002 16:43:37 +0530 Subject: [LARTC] cbq or htb Message-ID: <02070916433700.02383@sanitarium> Hi List, Sorry if my question sounds naive and/or repeated. But, is it safe to use htb in a real environment, with about 150 customers sharing a 2 Mbps link, and with bandwidth restriction applied to each ip? I'm currently using cbq, and its not giving ne problems so far (except a slight headache due to the amount of numbers and options) :-) I tried htb on a small setup of about 5 machines on my local LAN and it works like a charm, especially the burstable (ceil) option, and the fact that root classes don't share bandwidth, which makes it a good candidate for bandwidth guarantee. I don't have the resources (m/c) to test htb on my LAN. So i was wondering if it is safe to apply htb to my client environment (150 ips , 2 Mbps link) thanx, -- arc_of_descent From smohan@vsnl.com Tue Jul 9 13:25:46 2002 From: smohan@vsnl.com (S Mohan) Date: Tue, 9 Jul 2002 17:55:46 +0530 Subject: [LARTC] cbq & iptables nat problems In-Reply-To: <009001c22739$fa5d68c0$260110ac@KOVAITEAM> Message-ID: <007601c22743$c2090ba0$6300a8c0@smohan> Iptraf shows by interface. However, we cannot see traffic per flowid which is what I guess is needed. I've been hunting for one myself. Staf has promised a good working version using rrd on a stable basis shortly. Right Staf? Mohan -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Vanitha Sent: 09 July, 2002 4:45 PM To: lartc@mailman.ds9a.nl Cc: ganesh kumar godavari Subject: Re: [LARTC] cbq & iptables nat problems ----- Original Message ----- From: "ganesh kumar godavari" To: ; Cc: Sent: Tuesday, July 09, 2002 5:17 AM Subject: [LARTC] cbq & iptables nat problems Hello, To find out wether CBQ is SET on the device or not , use the command #ip link show This would show the queue attached to the device To find out the exact flow transmission in bits/bytes use iptraf. Regards Vanitha > Hey guys > > I've 2 questions: > > Question 1 > ################ > I want to see if the bandwidth allocation using cbq is working > properly or not > I looked into stef coene's beautiful document(http://docum.org) > for the monitor.pl. > I am not good at perl so can anyone help me to understand if there > is anyway I can check if the cbq is working. > _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From mbabcock@fibrespeed.net Tue Jul 9 14:19:11 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Tue, 09 Jul 2002 09:19:11 -0400 Subject: [LARTC] Priority Queueing on Linux References: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> <20020709094658.GB26593@outpost.ds9a.nl> Message-ID: <3D2AE2CF.8080504@fibrespeed.net> bert hubert wrote: >On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: > > >>There is priority queueing in Cisco router. >> >> >Please dig up a link so we can see what 'priority queueing' actually *is*. >But I bet that tc has it. > > I can almost guarantee Patrick is asking about diffserv support. -- Michael T. Babcock CTO, FibreSpeed Ltd. From nitin_rpr@yahoo.com Tue Jul 9 19:44:32 2002 From: nitin_rpr@yahoo.com (nitin panjwani) Date: Tue, 9 Jul 2002 11:44:32 -0700 (PDT) Subject: [LARTC] Ethernet interface shuts down In-Reply-To: <20020709042626.22254.99950.Mailman@outpost> Message-ID: <20020709184432.21559.qmail@web20307.mail.yahoo.com> Hi All, I have three Linux boxes running RH7.2 and each one of these has two 3com Ethernet NICs. I am trying to do some routing stuff with these. Ethernet interfaces on these boxes shut down by its own if I do not pass the packet through them for a while. I am not able to understand why is it happening. One more thing when I use “ip addr show” it shows that interface is there , but ifconfig doesn’t. I guess that is because ifconfig shows only the interfaces that are up. Any help on this will be really appreciable . Thanks in advance, Nitin __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From ahu@ds9a.nl Tue Jul 9 20:08:56 2002 From: ahu@ds9a.nl (bert hubert) Date: Tue, 9 Jul 2002 21:08:56 +0200 Subject: [LARTC] Ethernet interface shuts down In-Reply-To: <20020709184432.21559.qmail@web20307.mail.yahoo.com> References: <20020709042626.22254.99950.Mailman@outpost> <20020709184432.21559.qmail@web20307.mail.yahoo.com> Message-ID: <20020709190856.GA11222@outpost.ds9a.nl> On Tue, Jul 09, 2002 at 11:44:32AM -0700, nitin panjwani wrote: > Hi All, > > I have three Linux boxes running RH7.2 and each one of > these has two 3com Ethernet NICs. I am trying to do > some routing stuff with these. > > Ethernet interfaces on these boxes shut down by its > own if I do not pass the packet through them for a > while. I am not able to understand why is it > happening. I think you are running some kind of router daemon like routed, gated or Zebra. Just turn it off. > One more thing when I use ?ip addr show? it shows that > interface is there , but ifconfig doesn?t. I guess > that is because ifconfig shows only the interfaces > that are up. ifconfig -a will show it. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From John@JohnTelford.com Tue Jul 9 22:14:05 2002 From: John@JohnTelford.com (John Telford) Date: Tue, 9 Jul 2002 14:14:05 -0700 Subject: [LARTC] which NIC is which Message-ID: <20020709211405.GA28929@lnx2.labnet> I'm building routers. It's difficult to tell in advance which NIC will be assigned eth0 and which will assigned eth1 when using two NICs. Ping testing usually clears up this simple problem. The identification problem gets worse when adding a third NIC, after sorting out the first two NICs. Frequently the eth0 or eth1 assignments for the first two NICs change. Of course adding a fourth and fifth NIC multiplies the identification problem. Yes, some of my routers are supporting five network segments. My question is, what's the algorithm for assigning Ethernet designations? I know it not placement order in the PCI bus, and I know its not the NIC data-link address. So what is it? Thanks ...John -- John Telford - Owner JohnTelford.com LLC 503-292-6865 - fax:503-292-3094 john@johntelford.com - www.johntelford.com From arthurvl@sci.kun.nl Tue Jul 9 22:56:52 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Tue, 9 Jul 2002 23:56:52 +0200 (MEST) Subject: [LARTC] which NIC is which In-Reply-To: <20020709211405.GA28929@lnx2.labnet> Message-ID: On Tue, 9 Jul 2002, John Telford wrote: > I'm building routers. It's difficult to tell in advance which NIC will > be assigned eth0 and which will assigned eth1 when using two NICs. Ping > testing usually clears up this simple problem. > > The identification problem gets worse when adding a third NIC, after > sorting out the first two NICs. Frequently the eth0 or eth1 assignments > for the first two NICs change. > > Of course adding a fourth and fifth NIC multiplies the identification > problem. Yes, some of my routers are supporting five network segments. > > My question is, what's the algorithm for assigning Ethernet > designations? I know it not placement order in the PCI bus, and I know > its not the NIC data-link address. > > So what is it? Almost random. However, there's some evidence to suggest: order of probing of device drivers order of I/O addresses Unfortunately, in systems with identical cards that are configured using plug-and-play methods such as those used by PCI random is the best shot you have... Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From mbabcock@fibrespeed.net Tue Jul 9 23:06:34 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Tue, 09 Jul 2002 18:06:34 -0400 Subject: [LARTC] which NIC is which References: Message-ID: <3D2B5E6A.3010808@fibrespeed.net> Arthur van Leeuwen wrote: >Unfortunately, in systems with identical cards that are configured using >plug-and-play methods such as those used by PCI random is the best shot you >have... > > 'Deterministic' is more accurate. It seems to be random, on first boot. But it will almost never change after that unless you make hardware changes, in my experience. -- Michael T. Babcock CTO, FibreSpeed Ltd. From poltorak@df.ru Wed Jul 10 01:35:16 2002 From: poltorak@df.ru (Poltorak Serguei) Date: Wed, 10 Jul 2002 04:35:16 +0400 (MSD) Subject: [LARTC] routing broadcast messages Message-ID: Hello. I would like to route broadcast messages. For now, if I ping a.b.c.255 from m.n.o.w the packet is passing through each router, except the last, a.b.c.1 (m.n.o.p, other "external" address) and only he replys to that packet, but not from a.b.c.1, he does it from m.n.o.p address (logic, it's the address of the output interface). simple pic. a.b.c.0/24--[ a.b.c.1, m.n.o.p ]---m.n.o.w How can i fix this problem?? It could be very cool tool to know, how many hosts are up in your netS. Combined with VPN from FreeS/WAN (he transports brdcast as other ip trafic) makes administration easier. thanks for help. PoltoS/ From sandos@home.se Wed Jul 10 02:00:14 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 10 Jul 2002 03:00:14 +0200 Subject: [LARTC] "automatic" classes Message-ID: <001101c227ad$26f633d0$0219450a@sandos> Ive read up a bit on traffic shaping the last days, but not only on linux TC, but also on dummynet and altq for freebsd. My seemingly biggest problem is that I dont want to specify manually every "class", but I want the filtering to automatically regard each IP as a different class. I might have misunderstood classes though. Instead, Ill explain what I want to achieve: 1) I want to deploy a box in bridge mode first of all. 2) I would _want_ to traffic shape based on mac, not IP, but this doesnt seem possible. It isnt vital for me though, ip will work. 3) I want each ip (well, preferrably MAC, but...) to have 3 mbit of bandwidth. Is this possible with linux TC ? My problem is I dont know each and every IP-address that will be used. With dummynet in freebsd, you can specify "filters" on ip-dest/src and so on, and whats left after the filter is used as a ID, where each ID get a identical "pipe", effectively a bandwidth-cap. Thats suiting me perfectly, though I would want a bit more functionality. Basically, dummynet wouldnt let the individual streams to go above their 3mbit even when our connection isnt being fully utilized. I hope I made some sense. --- John Bäckstrand From fineberg@aviating.com Wed Jul 10 02:17:10 2002 From: fineberg@aviating.com (Adam B. Fineberg) Date: Tue, 09 Jul 2002 18:17:10 -0700 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this References: <20020704155047.GA17160@outpost.ds9a.nl> Message-ID: <3D2B8B16.1040107@aviating.com> bert hubert wrote: >>From lwn.net: > >The current development kernel remains 2.5.24. Linus has not released any >kernels - or surfaced on the linux-kernel mailing list - since before OLS >and the Kernel Summit. Some patches are beginning to show up in his >BitKeeper tree, however; they include some SCSI updates, an NTFS update, >and, interestingly, a change of the internal x86 clock frequency to 1000 Hz. > >1000Hz would mean great things for us shaping people! > > Can this be done in 2.4.18 by changing HZ in include/asm-i386/param.h to 1000? Would anything else need to be changed, like CLOCKS_PER_SEC (also in param.h)? Best regards, Adam Fineberg fineberg@aviating.com From trinity@mailru.com Wed Jul 10 06:30:19 2002 From: trinity@mailru.com (Dmitriy) Date: Wed, 10 Jul 2002 09:30:19 +0400 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this In-Reply-To: <3D2B8B16.1040107@aviating.com> References: <20020704155047.GA17160@outpost.ds9a.nl> <3D2B8B16.1040107@aviating.com> Message-ID: <20020710053019.GB17744@mitch.demos.su> On Tue, Jul 09, 2002 at 06:17:10PM -0700, Adam B. Fineberg wrote: > bert hubert wrote: > > >>From lwn.net: > > > >The current development kernel remains 2.5.24. Linus has not released any > >kernels - or surfaced on the linux-kernel mailing list - since before OLS > >and the Kernel Summit. Some patches are beginning to show up in his > >BitKeeper tree, however; they include some SCSI updates, an NTFS update, > >and, interestingly, a change of the internal x86 clock frequency to 1000 > >Hz. > > > >1000Hz would mean great things for us shaping people! > > > > > > Can this be done in 2.4.18 by changing HZ in include/asm-i386/param.h to > 1000? Would anything else need to be changed, like CLOCKS_PER_SEC (also > in param.h)? Try to download this url: http://www.ibiblio.org/gentoo/distfiles/linux-gentoo-2.4.19-crypto-r7.patch.bz2 This is gentoo Linux patch to 2.4.18, which adds Low Latency Scheduling, Preemptible Kernel, rmap, Ingo Molnar o(1) scheduler and by default it has HZ equal to 1000. Also there is XFS, Grsec and lots of other usefull staff. Patch is about 6.4Mbyte. Luck. > > Best regards, > Adam Fineberg > fineberg@aviating.com > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- With Respect Dmitriy Kuznetsov From arthurvl@sci.kun.nl Wed Jul 10 07:37:39 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Wed, 10 Jul 2002 08:37:39 +0200 (MEST) Subject: [LARTC] which NIC is which In-Reply-To: <3D2B5E6A.3010808@fibrespeed.net> Message-ID: On Tue, 9 Jul 2002, Michael T. Babcock wrote: > Arthur van Leeuwen wrote: > > >Unfortunately, in systems with identical cards that are configured using > >plug-and-play methods such as those used by PCI random is the best shot you > >have... > > > > > 'Deterministic' is more accurate. It seems to be random, on first boot. > But it will almost never change after that unless you make hardware > changes, in my experience. Not in mine. Every time the PCI bus settings (can't recall the name right now, have been playing with a fixed hardware platform for quite a while) get reset there will probably be a different assignation. Yeah, it'll probably be deterministic *somehow*, but you'll be hard pressed to come up with any rules. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From arthurvl@sci.kun.nl Wed Jul 10 07:41:35 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Wed, 10 Jul 2002 08:41:35 +0200 (MEST) Subject: [LARTC] "automatic" classes In-Reply-To: <001101c227ad$26f633d0$0219450a@sandos> Message-ID: On Wed, 10 Jul 2002, [iso-8859-1] John B=E4ckstrand wrote: [snip] > 2) I would _want_ to traffic shape based on mac, not > IP, but this doesnt seem possible. It isnt vital for me > though, ip will work. Actually, it is possible, using netfilter and fwmarks. Netfilter can actually match based on MAC address. Problem is that you can't have it without specifying shit yourself. You could conceivably write a script to take a list of MAC addresses to shape and generate the corresponding tc calls... and then seed that from your ARP table. That would be the closest to automatic you can get. Doei, Arthur. --=20 /\ / | arthurvl@sci.kun.nl | Work like you don't need the mo= ney /__\ / | A friend is someone with whom | Love like you have never been h= urt / \/__ | you can dare to be yourself | Dance like there's nobody watch= ing From andrei@srr.ro Wed Jul 10 07:57:48 2002 From: andrei@srr.ro (Andrei Boros) Date: Wed, 10 Jul 2002 09:57:48 +0300 Subject: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch Message-ID: <3D2BDAEC.C8C4B872@srr.ro> Since some other constraints require me to still run 2.2 kernel. (drivers for some hardware not working under 2.4) I tried to control the ingress traffic with the ingress qdisc with no success whatsoever. I got 2.2.21 kernel and installed the ds8 patch to have the ingress qdisc too. Recompiled, installed kernel and modules. Recompiled tc with diffserv=y. I tried a setup very similar to the example Edge2: ipchains -A input -p tcp -d 0/0 20 --mark 20 ipchains -A input -p tcp -d 0/0 21 --mark 20 tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 20 fw police rate 256kbit burst 25k mtu 1.5k drop flowid :1 I tried uploading with a ftp client and there was no traffic limit imposed on what my box received. tc -s qdisc ls shows all counters as 0 (zero). I looked around for this issue and managed to find exactly my problem described in a forum at http://www.geocrawler.com/archives/3/11111/2001/5/0/5806401/ but the message was unaswered there. If anyone has any suggestions, they are most welcome. -- ing. Andrei Boros mailto:andrei@srr.ro / +40-1-303-1870 Centrul pt. Tehnologia Informatiei Societatea Romana de Radiodifuziune From patrick_chan@mtelnet.com Wed Jul 10 08:47:44 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Wed, 10 Jul 2002 15:47:44 +0800 Subject: [LARTC] What does overlimits mean? Message-ID: <80313B62CF86B749B7C416579F394498029945@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C227E6.1398AF50 Content-Type: text/plain; charset="iso-8859-1" Hi all, After configurating tc, there is a overlimits: [root@mailredhat root]# tc -s qdisc qdisc sfq 8030: dev ppp0 quantum 1514b perturb 15sec Sent 9505059 bytes 6445 pkts (dropped 0, overlimits 0) qdisc sfq 802f: dev ppp0 quantum 1514b perturb 15sec Sent 154284 bytes 897 pkts (dropped 0, overlimits 0) qdisc cbq 10: dev ppp0 rate 112Kbit (bounded,isolated) prio no-transmit Sent 9662343 bytes 7344 pkts (dropped 0, overlimits 1710) borrowed 0 overactions 0 avgidle 57142 undertime 0 in the root qdisc, the overlimits is 1710. 1) What does "overlimits" mean? 2) How to avoid overlimits? 3) Below is the tc config, why only root qdisc has overlimits? the child qdisc does not have? tc qdisc add dev ppp0 root handle 10: cbq bandwidth 112Kbit avpkt 1000 tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 112Kbit rate 57Kb it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt 1000 isolated tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 112Kbit rate 55Kb it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt 1000 bounded tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15 tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15 tc filter add dev ppp0 parent 10:0 protocol ip prio 2 u32 match ip tos 0x8 0xff flowid 10:100 tc filter add dev ppp0 parent 10:0 protocol ip prio 8 u32 match ip tos 0x00 0xff flowid 10:200 ------_=_NextPart_001_01C227E6.1398AF50 Content-Type: text/html; charset="iso-8859-1" What does overlimits mean?

Hi all,

After configurating tc, there is a overlimits:

 [root@mailredhat root]# tc -s qdisc
qdisc sfq 8030: dev ppp0 quantum 1514b perturb 15sec
 Sent 9505059 bytes 6445 pkts (dropped 0, overlimits 0)

 qdisc sfq 802f: dev ppp0 quantum 1514b perturb 15sec
 Sent 154284 bytes 897 pkts (dropped 0, overlimits 0)

 qdisc cbq 10: dev ppp0 rate 112Kbit (bounded,isolated) prio no-transmit
 Sent 9662343 bytes 7344 pkts (dropped 0, overlimits 1710)
  borrowed 0 overactions 0 avgidle 57142 undertime 0

in the root qdisc, the overlimits is 1710.
1) What does "overlimits" mean?
2) How to avoid overlimits?
3) Below is the tc config, why only root qdisc has overlimits?
the child qdisc does not have?

tc qdisc add dev ppp0 root handle 10: cbq bandwidth 112Kbit avpkt 1000
tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 112Kbit rate 57Kb
it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt 1000 isolated
tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 112Kbit rate 55Kb
it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt 1000 bounded
tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15
tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15
tc filter add dev ppp0 parent 10:0 protocol ip prio 2 u32 match ip tos 0x8 0xff
flowid 10:100
tc filter add dev ppp0 parent 10:0 protocol ip prio 8 u32 match ip tos 0x00 0xff
 flowid 10:200

------_=_NextPart_001_01C227E6.1398AF50-- From phila@dg.net.ua Wed Jul 10 08:54:25 2002 From: phila@dg.net.ua (Anton Yurchenko) Date: Wed, 10 Jul 2002 10:54:25 +0300 Subject: [LARTC] Priority Queueing on Linux References: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> <20020709094658.GB26593@outpost.ds9a.nl> <3D2AE2CF.8080504@fibrespeed.net> Message-ID: <3D2BE831.5060304@dg.net.ua> Michael T. Babcock wrote: > bert hubert wrote: > >> On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: >> >> >>> There is priority queueing in Cisco router. >>> >> >> Please dig up a link so we can see what 'priority queueing' actually >> *is*. >> But I bet that tc has it. >> > I can almost guarantee Patrick is asking about diffserv support. nope, here it is. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt2/qcdconmg.htm#23965 -- Anton Yurchenko Digital Generation From wa@almesberger.net Wed Jul 10 09:06:15 2002 From: wa@almesberger.net (Werner Almesberger) Date: Wed, 10 Jul 2002 05:06:15 -0300 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this In-Reply-To: <3D2B8B16.1040107@aviating.com>; from fineberg@aviating.com on Tue, Jul 09, 2002 at 06:17:10PM -0700 References: <20020704155047.GA17160@outpost.ds9a.nl> <3D2B8B16.1040107@aviating.com> Message-ID: <20020710050615.U1424@almesberger.net> Adam B. Fineberg wrote: > Can this be done in 2.4.18 by changing HZ in include/asm-i386/param.h to > 1000? Yes. > Would anything else need to be changed, like CLOCKS_PER_SEC (also > in param.h)? Hmm, CLOCKS_PER_SEC doesn't look right, particularly if you look at include/asm-ia64/ia32.h:IA32_CLOCKS_PER_SEC. It's only used for some obscure parameter-passing mechanism in ELF, so the damage should be quite limited. (I.e. I've never noticed anything going wrong when changing HZ, and I didn't realize the CLOCKS_PER_SEC dependency until now.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From mage@adamant.net Wed Jul 10 09:04:35 2002 From: mage@adamant.net (Alexander Trotsai) Date: Wed, 10 Jul 2002 11:04:35 +0300 Subject: [LARTC] HTB does not work Message-ID: <20020710080435.GV4851@blackhole.adamant.ua> Hi Could someone help me. I'm successfully install htb patches and new tc binary, but htb won't work [root@watcher root]# uname -a Linux watcher.adamant.ua 2.4.19-pre8-ac5 #2 Wed Jul 10 10:08:55 EEST 2002 i686 unknown [root@watcher root]# lsmod Module Size Used by Not tainted sch_htb 13888 0 (autoclean) (unused) ... [root@watcher root]# tc qdisc change dev eth0.2 root handle 2: htb RTNETLINK answers: No such file or directory [root@watcher root]# tc qdisc change dev eth0 root handle 2: htb RTNETLINK answers: No such file or directory [root@watcher root]# tc qdisc change dev lo root handle 2: htb RTNETLINK answers: No such file or directory [root@watcher root]# why? -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] Big trouble - Decreasing electron flux From mage@adamant.net Wed Jul 10 09:07:20 2002 From: mage@adamant.net (Alexander Trotsai) Date: Wed, 10 Jul 2002 11:07:20 +0300 Subject: [LARTC] HTB does not work In-Reply-To: <20020710080435.GV4851@blackhole.adamant.ua> References: <20020710080435.GV4851@blackhole.adamant.ua> Message-ID: <20020710080720.GA27253@blackhole.adamant.ua> And some other tries [root@watcher root]# tc qdisc del dev eth0 root RTNETLINK answers: No such file or directory [root@watcher root]# tc qdisc del dev eth0.2 root RTNETLINK answers: No such file or directory [root@watcher root]# tc qdisc add dev eth0 root handle 1: htb default 20 RTNETLINK answers: Invalid argument [root@watcher root]# tc qdisc add dev eth0 root handle 1: htb RTNETLINK answers: Invalid argument [root@watcher root]# tc qdisc add dev eth0.2 root handle 1: htb default 20 RTNETLINK answers: Invalid argument ps. Could I use htb queuening on dotQ subinterfaces? On Wed, Jul 10, 2002 at 11:04:35AM +0300, Alexander Trotsai wrote: AT>Hi AT>Could someone help me. I'm successfully install htb patches AT>and new tc binary, but htb won't work AT>[root@watcher root]# uname -a AT>Linux watcher.adamant.ua 2.4.19-pre8-ac5 #2 Wed Jul 10 AT>10:08:55 EEST 2002 i686 unknown AT>[root@watcher root]# lsmod AT>Module Size Used by Not tainted AT>sch_htb 13888 0 (autoclean) (unused) AT>... AT>[root@watcher root]# tc qdisc change dev eth0.2 root handle AT>2: htb AT>RTNETLINK answers: No such file or directory AT>[root@watcher root]# tc qdisc change dev eth0 root handle 2: AT>htb AT>RTNETLINK answers: No such file or directory AT>[root@watcher root]# tc qdisc change dev lo root handle 2: AT>htb AT>RTNETLINK answers: No such file or directory AT>[root@watcher root]# AT>why? AT>-- AT>Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC AT>My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] AT>Big trouble - Decreasing electron flux AT>_______________________________________________ AT>LARTC mailing list / LARTC@mailman.ds9a.nl AT>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] Big trouble - Cache miss - please take better aim next time From devik@cdi.cz Wed Jul 10 09:21:04 2002 From: devik@cdi.cz (Martin Devera) Date: Wed, 10 Jul 2002 10:21:04 +0200 (CEST) Subject: [LARTC] Priority Queueing on Linux In-Reply-To: <20020709094658.GB26593@outpost.ds9a.nl> References: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> <20020709094658.GB26593@outpost.ds9a.nl> Message-ID: it is the same as PRIO queue in linux tc. devik On Tue, 9 Jul 2002, bert hubert wrote: > On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: > > There is priority queueing in Cisco router. > > > > Is there any equivalent implementation for TC on Linux? > > > > If yes, how can I configure and can you give me example? > > Please dig up a link so we can see what 'priority queueing' actually *is*. > But I bet that tc has it. > > Regards, > > bert > > -- > http://www.PowerDNS.com Versatile DNS Software & Services > http://www.tk the dot in .tk > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From devik@cdi.cz Wed Jul 10 09:24:07 2002 From: devik@cdi.cz (Martin Devera) Date: Wed, 10 Jul 2002 10:24:07 +0200 (CEST) Subject: [LARTC] Questions about HTB classes with an SFQ In-Reply-To: References: Message-ID: sfq MUST be leaf because it is classless. devik On Mon, 8 Jul 2002, Joshua Snyder wrote: > I have read most of the documents regarding both Htb and Sfq and I > still am not sure if it is best to put the Sfq on the leaf Htb or to put > it closer to the root class. All of the docs for Htb say to put it on the > leaf classes but the Sfq stuff says to put it closer to the root(but not > on the root). If my case every leaf class is only going to be one > machine/user. I want to have fairness between machines(I don't want one > person to get all of the bandwidth). I don't think putting Sfq on the > leaf classes will get me this, but I haven't been able to find a place > that says this for sure... > > josh > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From ahu@ds9a.nl Wed Jul 10 09:29:43 2002 From: ahu@ds9a.nl (bert hubert) Date: Wed, 10 Jul 2002 10:29:43 +0200 Subject: [LARTC] HTB does not work In-Reply-To: <20020710080720.GA27253@blackhole.adamant.ua> References: <20020710080435.GV4851@blackhole.adamant.ua> <20020710080720.GA27253@blackhole.adamant.ua> Message-ID: <20020710082943.GA26989@outpost.ds9a.nl> On Wed, Jul 10, 2002 at 11:07:20AM +0300, Alexander Trotsai wrote: > [root@watcher root]# tc qdisc add dev eth0 root handle 1: > htb default 20 Make doubly sure that you are running a patched tc. Verify which tc you are running - perhaps an old one is lying around. > ps. Could I use htb queuening on dotQ subinterfaces? I think you can, but don't trust me on that. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Wed Jul 10 09:30:36 2002 From: ahu@ds9a.nl (bert hubert) Date: Wed, 10 Jul 2002 10:30:36 +0200 Subject: [LARTC] routing broadcast messages In-Reply-To: References: Message-ID: <20020710083034.GB26989@outpost.ds9a.nl> On Wed, Jul 10, 2002 at 04:35:16AM +0400, Poltorak Serguei wrote: > Hello. > > I would like to route broadcast messages. > For now, if I ping a.b.c.255 from m.n.o.w the packet is passing through > each router, except the last, a.b.c.1 (m.n.o.p, other "external" address) > and only he replys to that packet, but not from a.b.c.1, he does it from > m.n.o.p address (logic, it's the address of the output interface). Broadcast messages don't leave their subnet. If you want that, you don't need a router but a bridge! Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Wed Jul 10 09:32:16 2002 From: ahu@ds9a.nl (bert hubert) Date: Wed, 10 Jul 2002 10:32:16 +0200 Subject: [LARTC] What does overlimits mean? In-Reply-To: <80313B62CF86B749B7C416579F394498029945@mail.mtel> References: <80313B62CF86B749B7C416579F394498029945@mail.mtel> Message-ID: <20020710083216.GC26989@outpost.ds9a.nl> On Wed, Jul 10, 2002 at 03:47:44PM +0800, Patrick Chan wrote: > in the root qdisc, the overlimits is 1710. > 1) What does "overlimits" mean? Times that CBQ decided to shutdown for a while. See the HOWTO. > 2) How to avoid overlimits? Not shaping - sorry, this is vital to how CBQ works, and how most other qdiscs that slow down traffic work. > 3) Below is the tc config, why only root qdisc has overlimits? > the child qdisc does not have? Try looking at the classes, tc -s class ls dev ppp0 - the rest will also have overlimits, if they are slowing traffic down. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Wed Jul 10 09:34:35 2002 From: ahu@ds9a.nl (bert hubert) Date: Wed, 10 Jul 2002 10:34:35 +0200 Subject: [LARTC] which NIC is which In-Reply-To: <20020709211405.GA28929@lnx2.labnet> References: <20020709211405.GA28929@lnx2.labnet> Message-ID: <20020710083435.GD26989@outpost.ds9a.nl> On Tue, Jul 09, 2002 at 02:14:05PM -0700, John Telford wrote: > I'm building routers. It's difficult to tell in advance which NIC will > be assigned eth0 and which will assigned eth1 when using two NICs. Ping > testing usually clears up this simple problem. > > The identification problem gets worse when adding a third NIC, after > sorting out the first two NICs. Frequently the eth0 or eth1 assignments > for the first two NICs change. There are tricks to configure based on the MAC address of your interface instead of on its place in the probe. Perhaps googling on that will help. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From mage@adamant.net Wed Jul 10 09:44:51 2002 From: mage@adamant.net (Alexander Trotsai) Date: Wed, 10 Jul 2002 11:44:51 +0300 Subject: [LARTC] HTB does not work In-Reply-To: <20020710082943.GA26989@outpost.ds9a.nl> References: <20020710080435.GV4851@blackhole.adamant.ua> <20020710080720.GA27253@blackhole.adamant.ua> <20020710082943.GA26989@outpost.ds9a.nl> Message-ID: <20020710084451.GC27253@blackhole.adamant.ua> On Wed, Jul 10, 2002 at 10:29:43AM +0200, bert hubert wrote: bh>On Wed, Jul 10, 2002 at 11:07:20AM +0300, Alexander Trotsai wrote: bh>> [root@watcher root]# tc qdisc add dev eth0 root handle 1: bh>> htb default 20 bh>Make doubly sure that you are running a patched tc. Verify which tc you are bh>running - perhaps an old one is lying around. Thanks Seems to be that binary tc from site won't work with my kernel So I get patch, rehdat iproute src.rpm, apply patch and can setup htb policy bh>> ps. Could I use htb queuening on dotQ subinterfaces? bh>I think you can, but don't trust me on that. bh>Regards, -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] Big trouble - old inkjet cartridges emanate barium-based fumes From patrick_chan@mtelnet.com Wed Jul 10 10:02:28 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Wed, 10 Jul 2002 17:02:28 +0800 Subject: [LARTC] Priority Queueing on Linux Message-ID: <80313B62CF86B749B7C416579F39449802994C@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C227F0.84791FC0 Content-Type: text/plain; charset="iso-8859-1" Hi, Below is the explanation of priority queueing http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm#xtocid22 I am developing a linux router. There is both data and voice traffic passed thru it. When I use priority queueing on Cisco router, the voice quality is good, evening downloading a large file. But I use the following tc config, the voice quality is not smooth when downloading a large file: tc qdisc add dev ppp0 root handle 10: cbq bandwidth 112Kbit avpkt 1000 tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 112Kbit rate 57Kb it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt 1000 isolated tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 112Kbit rate 55Kb it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt 1000 bounded tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15 tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15 tc filter add dev ppp0 parent 10:0 protocol ip prio 2 u32 match ip tos 0x8 0xff flowid 10:100 tc filter add dev ppp0 parent 10:0 protocol ip prio 8 u32 match ip tos 0x00 0xff flowid 10:200 voice packet is tagged with 0x8 in TOS field. Voice traffic only uses 34K bandwidth. So the bandwidth allocated to voice is enough. Is there any better tc config? ---------------------------------------------------------------------------- ---------------------- Date: Tue, 9 Jul 2002 11:46:58 +0200 From: bert hubert To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] Priority Queueing on Linux On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: > There is priority queueing in Cisco router. > > Is there any equivalent implementation for TC on Linux? > > If yes, how can I configure and can you give me example? Please dig up a link so we can see what 'priority queueing' actually *is*. But I bet that tc has it. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO Date: Tue, 09 Jul 2002 09:19:11 -0400 From: "Michael T. Babcock" Organization: FibreSpeed Ltd. To: lartc Subject: Re: [LARTC] Priority Queueing on Linux bert hubert wrote: >On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: > > >>There is priority queueing in Cisco router. >> >> >Please dig up a link so we can see what 'priority queueing' actually *is*. >But I bet that tc has it. > > I can almost guarantee Patrick is asking about diffserv support. -- Michael T. Babcock CTO, FibreSpeed Ltd. ------_=_NextPart_001_01C227F0.84791FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [LARTC] Priority Queueing on Linux

Hi,

Below is the explanation of priority queueing
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_d= oc/qos.htm#xtocid22

I am developing a linux router.
There is both data and voice traffic passed thru = it.

When I use priority queueing on Cisco router,
the voice quality is good, evening downloading a = large file.

But I use the following tc config, the voice quality = is not smooth
when downloading a large file:

tc qdisc add dev ppp0 root handle 10: cbq bandwidth = 112Kbit avpkt 1000
tc class add dev ppp0 parent 10:0 classid 10:100 cbq = bandwidth 112Kbit rate 57Kb
it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt = 1000 isolated
tc class add dev ppp0 parent 10:0 classid 10:200 cbq = bandwidth 112Kbit rate 55Kb
it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt = 1000 bounded
tc qdisc add dev ppp0 parent 10:100 sfq quantum = 1514b perturb 15
tc qdisc add dev ppp0 parent 10:200 sfq quantum = 1514b perturb 15
tc filter add dev ppp0 parent 10:0 protocol ip prio = 2 u32 match ip tos 0x8 0xff
flowid 10:100
tc filter add dev ppp0 parent 10:0 protocol ip prio = 8 u32 match ip tos 0x00 0xff
 flowid 10:200

voice packet is tagged with 0x8 in TOS field.
Voice traffic only uses 34K bandwidth. So the = bandwidth allocated
to voice is enough.
Is there any better tc config?









---------------------------------------------------------------= -----------------------------------
Date: Tue, 9 Jul 2002 11:46:58 +0200
From: bert hubert <ahu@ds9a.nl>
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Priority Queueing on = Linux

On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick = Chan wrote:
> There is priority queueing in Cisco = router.
>
> Is there any equivalent implementation for TC = on Linux?
>
> If yes, how can I configure and can you give me = example?

Please dig up a link so we can see what 'priority = queueing' actually *is*.
But I bet that tc has it.

Regards,

bert

--
http://www.PowerDNS.com    &nb= sp;     Versatile DNS Software & = Services
http://www.tk      &= nbsp;           &= nbsp;           the = dot in .tk
http://lartc.org     &nbs= p;     Linux Advanced Routing & Traffic Control = HOWTO

Date: Tue, 09 Jul 2002 09:19:11 -0400
From: "Michael T. Babcock" = <mbabcock@fibrespeed.net>
Organization: FibreSpeed Ltd.
To: lartc <lartc@mailman.ds9a.nl>
Subject: Re: [LARTC] Priority Queueing on = Linux

bert hubert wrote:

>On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick = Chan wrote:
> 
>
>>There is priority queueing in Cisco = router.
>>   
>>
>Please dig up a link so we can see what = 'priority queueing' actually *is*.
>But I bet that tc has it.
> 
>
I can almost guarantee Patrick is asking about = diffserv support.
--
Michael T. Babcock
CTO, FibreSpeed Ltd.


------_=_NextPart_001_01C227F0.84791FC0-- From patrick_chan@mtelnet.com Wed Jul 10 10:14:13 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Wed, 10 Jul 2002 17:14:13 +0800 Subject: [LARTC] QoS on data and voice traffic Message-ID: <80313B62CF86B749B7C416579F39449802994F@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C227F2.28362080 Content-Type: text/plain; charset="iso-8859-1" Hi, Sorry for asking so much questions in this mailing list. Because I have to develop a Linux router, there are both data and voice packets passed thru it. The voice packets are already tagged with 0x8 in TOS field. The bandwidth of the serial link is 115200bps. A voice call takes up 34Kbytes bandwidth. Now, I use the following tc config: tc qdisc add dev ppp0 root handle 10: cbq bandwidth 112Kbit avpkt 1000 tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 112Kbit rate 57Kb it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt 1000 isolated tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 112Kbit rate 55Kb it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt 1000 bounded tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15 tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15 tc filter add dev ppp0 parent 10:0 protocol ip prio 2 u32 match ip tos 0x8 0xff flowid 10:100 tc filter add dev ppp0 parent 10:0 protocol ip prio 8 u32 match ip tos 0x00 0xff flowid 10:200 10:100 is isolated and the bandwidth allocated to this class is 57Kb, the voice packets are successfully put to class 10:100 because I know it by tc -s qdisc theoretically, the voice quality should be very smooth. But the voice is not smooth, when I start to download a file. If I turn off tc, the quality is even terrible, when download a file. Sorry, I just learn tc for 1 month. Hope someone can help me..... ------_=_NextPart_001_01C227F2.28362080 Content-Type: text/html; charset="iso-8859-1" QoS on data and voice traffic

Hi,

Sorry for asking so much questions in this mailing list.

Because I have to develop a Linux router,
there are both data and voice packets passed thru it.
The voice packets are already tagged with 0x8 in TOS field.
The bandwidth of the serial link is 115200bps.
A voice call takes up 34Kbytes bandwidth.

Now, I use the following tc config:
tc qdisc add dev ppp0 root handle 10: cbq bandwidth 112Kbit avpkt 1000
tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 112Kbit rate 57Kb
it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt 1000 isolated
tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 112Kbit rate 55Kb
it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt 1000 bounded
tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15
tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15
tc filter add dev ppp0 parent 10:0 protocol ip prio 2 u32 match ip tos 0x8 0xff
flowid 10:100
tc filter add dev ppp0 parent 10:0 protocol ip prio 8 u32 match ip tos 0x00 0xff
 flowid 10:200


10:100 is isolated and the bandwidth allocated to this class is 57Kb,
the voice packets are successfully put to class 10:100 because
I know it by tc -s qdisc
theoretically, the voice quality should be very smooth.
But the voice is not smooth, when I start to download a file.

If I turn off tc, the quality is even terrible, when download a file.



Sorry, I just learn tc for 1 month. Hope someone can help me.....

------_=_NextPart_001_01C227F2.28362080-- From poltorak@df.ru Wed Jul 10 11:03:37 2002 From: poltorak@df.ru (Poltorak Serguei) Date: Wed, 10 Jul 2002 14:03:37 +0400 (MSD) Subject: [LARTC] routing broadcast messages In-Reply-To: <20020710083034.GB26989@outpost.ds9a.nl> Message-ID: Hello but packets are going To their subnetwork. then m.n.o.w sends packet to a.b.c.255 gateways other than a.b.c.1 doesn't know that a.b.c.255 is a broadcast. it's only a.b.c.1 (m.n.o.p) who discards the packet may be I should redraw my pic. a.b.c.0/24,brd+ -----[ a.b.c.1, m.n.o.p ]-----m.n.o.w <-------pings are going in that direction So, packets are going TO their subnet. Any idea??? thanks, PoltoS/ On Wed, 10 Jul 2002, bert hubert wrote: ;On Wed, Jul 10, 2002 at 04:35:16AM +0400, Poltorak Serguei wrote: ;> Hello. ;> ;> I would like to route broadcast messages. ;> For now, if I ping a.b.c.255 from m.n.o.w the packet is passing through ;> each router, except the last, a.b.c.1 (m.n.o.p, other "external" address) ;> and only he replys to that packet, but not from a.b.c.1, he does it from ;> m.n.o.p address (logic, it's the address of the output interface). ; ;Broadcast messages don't leave their subnet. If you want that, you don't ;need a router but a bridge! ; ;Regards, ; ;bert ; ;-- ;http://www.PowerDNS.com Versatile DNS Software & Services ;http://www.tk the dot in .tk ;http://lartc.org Linux Advanced Routing & Traffic Control HOWTO ; From serban_rares@yahoo.com Wed Jul 10 11:26:51 2002 From: serban_rares@yahoo.com (Mr SERBAN Rares) Date: Wed, 10 Jul 2002 03:26:51 -0700 (PDT) Subject: [LARTC] QoS on data and voice traffic In-Reply-To: <80313B62CF86B749B7C416579F39449802994F@mail.mtel> Message-ID: <20020710102651.75568.qmail@web13902.mail.yahoo.com> Hi, You are wrong! The packets must spend less time in your box for 0x08 class. So, if you are using cbq and sfq I don't belive that you will have good results. First you need a scheduler between 0x08 class and 0x00 like PRIO. You can use sfq for 0x00 class or tbf to limit the bandwidth. For 0x08 try to use pfifo. Also you can do the same configuration using htb. Please, for 0x08, use pfifo and for 0x00 sfq! A +, R. --- Patrick Chan wrote: > Hi, > > Sorry for asking so much questions in this mailing > list. > > Because I have to develop a Linux router, > there are both data and voice packets passed thru > it. > The voice packets are already tagged with 0x8 in TOS > field. > The bandwidth of the serial link is 115200bps. > A voice call takes up 34Kbytes bandwidth. > > Now, I use the following tc config: > tc qdisc add dev ppp0 root handle 10: cbq bandwidth > 112Kbit avpkt 1000 > tc class add dev ppp0 parent 10:0 classid 10:100 cbq > bandwidth 112Kbit rate > 57Kb > it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt > 1000 isolated > tc class add dev ppp0 parent 10:0 classid 10:200 cbq > bandwidth 112Kbit rate > 55Kb > it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt > 1000 bounded > tc qdisc add dev ppp0 parent 10:100 sfq quantum > 1514b perturb 15 > tc qdisc add dev ppp0 parent 10:200 sfq quantum > 1514b perturb 15 > tc filter add dev ppp0 parent 10:0 protocol ip prio > 2 u32 match ip tos 0x8 > 0xff > flowid 10:100 > tc filter add dev ppp0 parent 10:0 protocol ip prio > 8 u32 match ip tos 0x00 > 0xff > flowid 10:200 > > > 10:100 is isolated and the bandwidth allocated to > this class is 57Kb, > the voice packets are successfully put to class > 10:100 because > I know it by tc -s qdisc > theoretically, the voice quality should be very > smooth. > But the voice is not smooth, when I start to > download a file. > > If I turn off tc, the quality is even terrible, when > download a file. > > > > Sorry, I just learn tc for 1 month. Hope someone can > help me..... > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From patrick_chan@mtelnet.com Wed Jul 10 11:42:17 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Wed, 10 Jul 2002 18:42:17 +0800 Subject: [LARTC] QoS on data and voice traffic Message-ID: <80313B62CF86B749B7C416579F394498029954@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C227FE.75D05840 Content-Type: text/plain; charset="iso-8859-1" Hi, Thx for your reply. Can you give me an example configuration? -----Original Message----- From: Mr SERBAN Rares [mailto:serban_rares@yahoo.com] Sent: Wednesday, July 10, 2002 6:27 PM To: Patrick Chan; lartc@mailman.ds9a.nl Subject: Re: [LARTC] QoS on data and voice traffic Hi, You are wrong! The packets must spend less time in your box for 0x08 class. So, if you are using cbq and sfq I don't belive that you will have good results. First you need a scheduler between 0x08 class and 0x00 like PRIO. You can use sfq for 0x00 class or tbf to limit the bandwidth. For 0x08 try to use pfifo. Also you can do the same configuration using htb. Please, for 0x08, use pfifo and for 0x00 sfq! A +, R. --- Patrick Chan wrote: > Hi, > > Sorry for asking so much questions in this mailing > list. > > Because I have to develop a Linux router, > there are both data and voice packets passed thru > it. > The voice packets are already tagged with 0x8 in TOS > field. > The bandwidth of the serial link is 115200bps. > A voice call takes up 34Kbytes bandwidth. > > Now, I use the following tc config: > tc qdisc add dev ppp0 root handle 10: cbq bandwidth > 112Kbit avpkt 1000 > tc class add dev ppp0 parent 10:0 classid 10:100 cbq > bandwidth 112Kbit rate > 57Kb > it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt > 1000 isolated > tc class add dev ppp0 parent 10:0 classid 10:200 cbq > bandwidth 112Kbit rate > 55Kb > it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt > 1000 bounded > tc qdisc add dev ppp0 parent 10:100 sfq quantum > 1514b perturb 15 > tc qdisc add dev ppp0 parent 10:200 sfq quantum > 1514b perturb 15 > tc filter add dev ppp0 parent 10:0 protocol ip prio > 2 u32 match ip tos 0x8 > 0xff > flowid 10:100 > tc filter add dev ppp0 parent 10:0 protocol ip prio > 8 u32 match ip tos 0x00 > 0xff > flowid 10:200 > > > 10:100 is isolated and the bandwidth allocated to > this class is 57Kb, > the voice packets are successfully put to class > 10:100 because > I know it by tc -s qdisc > theoretically, the voice quality should be very > smooth. > But the voice is not smooth, when I start to > download a file. > > If I turn off tc, the quality is even terrible, when > download a file. > > > > Sorry, I just learn tc for 1 month. Hope someone can > help me..... > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ------_=_NextPart_001_01C227FE.75D05840 Content-Type: text/html; charset="iso-8859-1" RE: [LARTC] QoS on data and voice traffic

Hi,

Thx for your reply.

Can you give me an example configuration?



-----Original Message-----
From: Mr SERBAN Rares [mailto:serban_rares@yahoo.com]
Sent: Wednesday, July 10, 2002 6:27 PM
To: Patrick Chan; lartc@mailman.ds9a.nl
Subject: Re: [LARTC] QoS on data and voice traffic


Hi,

You are wrong! The packets must spend less time in
your box for 0x08 class. So, if you are using cbq and
sfq I don't belive that you will have good results.
First you need a scheduler between 0x08 class and 0x00
like PRIO. You can use sfq for 0x00 class or tbf to
limit the bandwidth. For 0x08 try to use pfifo.

Also you can do the same configuration using htb.
Please, for 0x08, use pfifo and for 0x00 sfq!

A +,

R.

--- Patrick Chan <patrick_chan@mtelnet.com> wrote:
> Hi,
>
> Sorry for asking so much questions in this mailing
> list.
>
> Because I have to develop a Linux router,
> there are both data and voice packets passed thru
> it.
> The voice packets are already tagged with 0x8 in TOS
> field.
> The bandwidth of the serial link is 115200bps.
> A voice call takes up 34Kbytes bandwidth.
>
> Now, I use the following tc config:
> tc qdisc add dev ppp0 root handle 10: cbq bandwidth
> 112Kbit avpkt 1000
> tc class add dev ppp0 parent 10:0 classid 10:100 cbq
> bandwidth 112Kbit rate
> 57Kb
> it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt
> 1000 isolated
> tc class add dev ppp0 parent 10:0 classid 10:200 cbq
> bandwidth 112Kbit rate
> 55Kb
> it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt
> 1000 bounded
> tc qdisc add dev ppp0 parent 10:100 sfq quantum
> 1514b perturb 15
> tc qdisc add dev ppp0 parent 10:200 sfq quantum
> 1514b perturb 15
> tc filter add dev ppp0 parent 10:0 protocol ip prio
> 2 u32 match ip tos 0x8
> 0xff
> flowid 10:100
> tc filter add dev ppp0 parent 10:0 protocol ip prio
> 8 u32 match ip tos 0x00
> 0xff
>  flowid 10:200
>
>
> 10:100 is isolated and the bandwidth allocated to
> this class is 57Kb,
> the voice packets are successfully put to class
> 10:100 because
> I know it by tc -s qdisc
> theoretically, the voice quality should be very
> smooth.
> But the voice is not smooth, when I start to
> download a file.
>
> If I turn off tc, the quality is even terrible, when
> download a file.
>
>
>
> Sorry, I just learn tc for 1 month. Hope someone can
> help me.....
>


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

------_=_NextPart_001_01C227FE.75D05840-- From foxes@fiberlogic.com Wed Jul 10 12:33:41 2002 From: foxes@fiberlogic.com (Foxes C.H. Hung) Date: Wed, 10 Jul 2002 19:33:41 +0800 Subject: [LARTC] CBQ+TBF on Linux router help!! Message-ID: <3D2C1B95.1000300@fiberlogic.com> Dear all, I am a beginner on tc class. Now,I have some problems. In my Linux router,I had two interface(eth0,wan0), eth0 interface is an ethernet, wan0 interface used ppp protocol on E1 Line. Below were my setting: Linux Router PC1 <---->eth0 wan0<----->wan1 eth1<----->PC2 PC1 = 192.168.0.1 eth0 = 192.168.0.2 PC2 = 10.1.1.1 #tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell 8 #tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 100Mbit weight 10Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 #tc class add dev eth0 parent 1:1 classid 1:100 cbq bandwidth 100Mbit rate 128Kbit weight 10Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded #tc qdisc add dev eth0 parent 1:100 tbf rate 128Kbit buffer 10Kb/8 limit 15Kb mtu 1500 #tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.0.1 flowid 1:100 #tc qdisc add dev wan0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell 8 #tc class add dev wan0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 100Mbit weight 10Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 #tc class add dev wan0 parent 1:1 classid 1:100 cbq bandwidth 100Mbit rate 128Kbit weight 10Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded #tc qdisc add dev wan0 parent 1:100 tbf rate 128Kbit buffer 10Kb/8 limit 15Kb mtu 1500 #tc filter add dev wan0 parent 1:0 protocol ip prio 100 u32 match ip dst 10.1.1.1 flowid 1:100 Then,I had ftp server on PC1 and PC2. I used ftp to get some files each other. But only eth0 got traffic shaping.. #tc -s class show dev eth0 class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit Sent 140656 bytes 5813 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 3225 undertime 0 class cbq 1:10 parent 1:1 leaf 8001: rate 128Kbit (bounded) prio 7 Sent 68252 bytes 476 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 1.63339e+08 undertime 0 class cbq 1:1 parent 1: rate 100MKbit prio no-transmit Sent 68252 bytes 476 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 3028 undertime 0 #tc -s class show dev wan0 class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit Sent 281212 bytes 9812 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 3225 undertime 0 class cbq 1:10 parent 1:1 leaf 8001: rate 128Kbit (bounded) prio 7 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 1.63339e+08 undertime 0 class cbq 1:1 parent 1: rate 100MKbit prio no-transmit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 3028 undertime 0 But when I ping or telnet from Linux router to PC2, TC can got my traffic?! #tc -s class show dev wan0 class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit Sent 2812 bytes 12 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 3225 undertime 0 class cbq 1:10 parent 1:1 leaf 8001: rate 128Kbit (bounded) prio 7 Sent 1388 bytes 10 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 1.63339e+08 undertime 0 class cbq 1:1 parent 1: rate 100MKbit prio no-transmit Sent 1388 bytes 10 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 3028 undertime 0 But Why???? PS: Linux kernel is 2.4.3 BEST REGARDS foxes Jul 10 2002 From mbabcock@fibrespeed.net Wed Jul 10 13:09:02 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Wed, 10 Jul 2002 08:09:02 -0400 Subject: [LARTC] Priority Queueing on Linux References: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> <20020709094658.GB26593@outpost.ds9a.nl> <3D2AE2CF.8080504@fibrespeed.net> <3D2BE831.5060304@dg.net.ua> Message-ID: <3D2C23DE.6040508@fibrespeed.net> Anton Yurchenko wrote: > nope, here it is. > http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt2/qcdconmg.htm#23965 From the page (for those who don't follow links, or for the archives of this list): PQ [Priority Queuing] allows you to define how traffic is prioritized in the network. You configure four traffic priorities. You can define a series of filters based on packet characteristics to cause the router to place traffic into these four queues; the queue with the highest priority is serviced first until it is empty, then the lower queues are serviced in sequence. -- Michael T. Babcock CTO, FibreSpeed Ltd. From sandos@home.se Wed Jul 10 13:22:50 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 10 Jul 2002 14:22:50 +0200 Subject: [LARTC] Re: "automatic" classes Message-ID: <007601c2280c$82130b80$0219450a@sandos> > Is this possible with linux TC ? My problem is I dont > know each and every IP-address that will be used. Just wanted to let everyone know that I think I found my solution: http://wipl-wrr.sourceforge.net It automatically creates a classes based on either IP or MAC. --- John Bäckstrand From eran@nbase.co.il Wed Jul 10 13:42:23 2002 From: eran@nbase.co.il (Eran Man) Date: Wed, 10 Jul 2002 15:42:23 +0300 Subject: [LARTC] routing broadcast messages References: Message-ID: <3D2C2BAF.6020106@nbase.co.il> Hello All, What your are trying to do is called "directed broadcast", and the linux networking gods believe it is evil (i.e. a security hole) and should not be implemented by routers. See http://www.uwsg.iu.edu/hypermail/linux/net/9707.3/0030.html for example. Eran. Poltorak Serguei wrote: > Hello > > but packets are going To their subnetwork. then m.n.o.w sends packet to > a.b.c.255 gateways other than a.b.c.1 doesn't know that a.b.c.255 is a > broadcast. it's only a.b.c.1 (m.n.o.p) who discards the packet > > may be I should redraw my pic. > a.b.c.0/24,brd+ -----[ a.b.c.1, m.n.o.p ]-----m.n.o.w > <-------pings are going in that direction > > So, packets are going TO their subnet. > > Any idea??? > > thanks, > PoltoS/ > > On Wed, 10 Jul 2002, bert hubert wrote: > > ;On Wed, Jul 10, 2002 at 04:35:16AM +0400, Poltorak Serguei wrote: > ;> Hello. > ;> > ;> I would like to route broadcast messages. > ;> For now, if I ping a.b.c.255 from m.n.o.w the packet is passing through > ;> each router, except the last, a.b.c.1 (m.n.o.p, other "external" address) > ;> and only he replys to that packet, but not from a.b.c.1, he does it from > ;> m.n.o.p address (logic, it's the address of the output interface). > ; > ;Broadcast messages don't leave their subnet. If you want that, you don't > ;need a router but a bridge! > ; > ;Regards, > ; > ;bert > ; > ;-- > ;http://www.PowerDNS.com Versatile DNS Software & Services > ;http://www.tk the dot in .tk > ;http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > ; > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Eran Mann Direct : 972-4-9936297 Senior Software Engineer Fax : 972-4-9890430 Optical Access Email : emann@opticalaccess.com From Vladimir B. Savkin" ; from ahu@ds9a.nl on Wed, Jul 10, 2002 at 10:34:35AM +0200 References: <20020709211405.GA28929@lnx2.labnet> <20020710083435.GD26989@outpost.ds9a.nl> Message-ID: <20020710163855.A4221@shade.msu.ru> Thus spake bert hubert: > On Tue, Jul 09, 2002 at 02:14:05PM -0700, John Telford wrote: > > I'm building routers. It's difficult to tell in advance which NIC will > > be assigned eth0 and which will assigned eth1 when using two NICs. Ping > > testing usually clears up this simple problem. > > > > The identification problem gets worse when adding a third NIC, after > > sorting out the first two NICs. Frequently the eth0 or eth1 assignments > > for the first two NICs change. > > There are tricks to configure based on the MAC address of your interface > instead of on its place in the probe. Perhaps googling on that will help. A script to rename interfaces with "ip link ... set name ..." after modprobe according to their hw addresses should suffice. I never tried this because in my experience order of detection was always consistant between reboots assuming there are no hardware chasnges. From ahu@ds9a.nl Wed Jul 10 13:42:06 2002 From: ahu@ds9a.nl (bert hubert) Date: Wed, 10 Jul 2002 14:42:06 +0200 Subject: [LARTC] which NIC is which In-Reply-To: <20020710163855.A4221@shade.msu.ru> References: <20020709211405.GA28929@lnx2.labnet> <20020710083435.GD26989@outpost.ds9a.nl> <20020710163855.A4221@shade.msu.ru> Message-ID: <20020710124206.GC1399@outpost.ds9a.nl> On Wed, Jul 10, 2002 at 04:38:55PM +0400, Vladimir B. Savkin wrote: > A script to rename interfaces with "ip link ... set name ..." after > modprobe according to their hw addresses should suffice. > > I never tried this because in my experience order of detection was always > consistant between reboots assuming there are no hardware chasnges. If you turn on APIC you are in for a surprise I gather :-) Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From don-lartc@isis.cs3-inc.com Wed Jul 10 16:29:47 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Wed, 10 Jul 2002 08:29:47 -0700 Subject: [LARTC] "automatic" classes In-Reply-To: <20020710042620.20014.53903.Mailman@outpost> References: <20020710042620.20014.53903.Mailman@outpost> Message-ID: <15660.21227.725741.553634@isis.cs3-inc.com> > From: =?iso-8859-1?Q?John_B=E4ckstrand?= > 1) I want to deploy a box in bridge mode first of all. > 2) I would _want_ to traffic shape based on mac, not > IP, but this doesnt seem possible. It isnt vital for me > though, ip will work. > 3) I want each ip (well, preferrably MAC, but...) to > have 3 mbit of bandwidth. On one level this makes no sense. What if you have more clients than bandwidth? Clearly you want to lower the 3MB to bandwidth/#clients. What if you have extra bandwidth? You probably want to share the excess rather than waste the bandwidth. In fact you probably want to share the bandwidth dynamically among the active clients. All of this is just what's done by SFQ, except that you want to alter it to use source MAC, which is easy enough. I think there's already a version out there that uses only source IP if you want to try that first. In order to use source MAC you probably do have to change the kernel to store the source MAC when the packet arrives. Otherwise it's gone by the time you forward. From sandos@home.se Wed Jul 10 16:46:25 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 10 Jul 2002 17:46:25 +0200 Subject: [LARTC] "automatic" classes References: <20020710042620.20014.53903.Mailman@outpost> <15660.21227.725741.553634@isis.cs3-inc.com> Message-ID: <00e601c22828$f2ea4f00$0219450a@sandos> > > 1) I want to deploy a box in bridge mode first of all. > > 2) I would _want_ to traffic shape based on mac, not > > IP, but this doesnt seem possible. It isnt vital for me > > though, ip will work. > > 3) I want each ip (well, preferrably MAC, but...) to > > have 3 mbit of bandwidth. > On one level this makes no sense. Well, I was a bit unclear, or rather unsure of what I really wanted. I actually want clients that use more bandwidth to have less priority, which is what wrr can do. >What if you have more clients than > bandwidth? Clearly you want to lower the 3MB to bandwidth/#clients. > What if you have extra bandwidth? You probably want to share the > excess rather than waste the bandwidth. In fact you probably want to > share the bandwidth dynamically among the active clients. > All of this is just what's done by SFQ Interesting. But would SFQ for example, result in low latency on a heavily used connection for clients that doesnt use much bandwidth? --- John Bäckstrand From don-lartc@isis.cs3-inc.com Wed Jul 10 16:51:12 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Wed, 10 Jul 2002 08:51:12 -0700 Subject: [LARTC] "automatic" classes In-Reply-To: <00e601c22828$f2ea4f00$0219450a@sandos> References: <20020710042620.20014.53903.Mailman@outpost> <15660.21227.725741.553634@isis.cs3-inc.com> <00e601c22828$f2ea4f00$0219450a@sandos> Message-ID: <15660.22512.282268.736570@isis.cs3-inc.com> =?iso-8859-1?Q?John_B=E4ckstrand?= writes: > Interesting. But would SFQ for example, result in low > latency on a heavily used connection for clients that > doesnt use much bandwidth? Yes. SFQ is basically round robin among connections, which you'll change to round robin among clients. In general the latency for the first packet sent by a new client is proportional to the number of clients in the queue regardless of the amount of data the other clients have in the queue. From xerox@foonet.net Wed Jul 10 16:57:59 2002 From: xerox@foonet.net (CIT/Paul) Date: Wed, 10 Jul 2002 11:57:59 -0400 Subject: [LARTC] Anything out there that is similar to Cisco's WFQ? In-Reply-To: <3D2C1B95.1000300@fiberlogic.com> Message-ID: <001201c2282a$90233880$2d00000a@foolaptop> I've looked all over the place and I can't find Any queuing mechanism that is similar to the "fair-queue" on Cisco. It seems to work better than anything else that I have ever seen to create Lower latency for connections. This is what it does in brief (flow based WFQ) http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/q os_c/qcpart2/qcwfq.htm Any help would be greatly appreciated :) This is much better than SFQ :> Paul From fineberg@aviating.com Wed Jul 10 17:37:05 2002 From: fineberg@aviating.com (Adam B. Fineberg) Date: Wed, 10 Jul 2002 09:37:05 -0700 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this References: <20020704155047.GA17160@outpost.ds9a.nl> <3D2B8B16.1040107@aviating.com> <20020710053019.GB17744@mitch.demos.su> Message-ID: <3D2C62B1.2000909@aviating.com> Dmitriy, I tried applying the patch you suggested (http://www.ibiblio.org/gentoo/distfiles/linux-gentoo-2.4.19-crypto-r7.patch.bz2) and after I sorted through a few things with the patching (since I already had a HTB) I tried a make xconfig and got the following: rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts kconfig.tk make[1]: Entering directory `/usr/src/linux-2.4.18-WMUX-low-latency/scripts' cat header.tk >> ./kconfig.tk ./tkparse < ../arch/i386/config.in >> kconfig.tk -: 309: can't handle dep_bool/dep_mbool/dep_tristate condition make[1]: *** [kconfig.tk] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.18-WMUX-low-latency/scripts' make: *** [xconfig] Error 2 Any ideas how to proceed or who/where else I can ask? Best regards, Adam Fineberg From xerox@foonet.net Wed Jul 10 17:49:54 2002 From: xerox@foonet.net (CIT/Paul) Date: Wed, 10 Jul 2002 12:49:54 -0400 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this In-Reply-To: <20020710053019.GB17744@mitch.demos.su> Message-ID: <001301c22831$d1852e30$2d00000a@foolaptop> HZ is set to 100 in that patch.. :> -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Dmitriy Sent: Wednesday, July 10, 2002 1:30 AM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HZ to be 1000 - 2.5.25 may have this On Tue, Jul 09, 2002 at 06:17:10PM -0700, Adam B. Fineberg wrote: > bert hubert wrote: > > >>From lwn.net: > > > >The current development kernel remains 2.5.24. Linus has not released any > >kernels - or surfaced on the linux-kernel mailing list - since before OLS > >and the Kernel Summit. Some patches are beginning to show up in his > >BitKeeper tree, however; they include some SCSI updates, an NTFS update, > >and, interestingly, a change of the internal x86 clock frequency to 1000 > >Hz. > > > >1000Hz would mean great things for us shaping people! > > > > > > Can this be done in 2.4.18 by changing HZ in include/asm-i386/param.h to > 1000? Would anything else need to be changed, like CLOCKS_PER_SEC (also > in param.h)? Try to download this url: http://www.ibiblio.org/gentoo/distfiles/linux-gentoo-2.4.19-crypto-r7.pa tch.bz2 This is gentoo Linux patch to 2.4.18, which adds Low Latency Scheduling, Preemptible Kernel, rmap, Ingo Molnar o(1) scheduler and by default it has HZ equal to 1000. Also there is XFS, Grsec and lots of other usefull staff. Patch is about 6.4Mbyte. Luck. > > Best regards, > Adam Fineberg > fineberg@aviating.com > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- With Respect Dmitriy Kuznetsov _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From larryf@sdintegrators.com Wed Jul 10 18:55:29 2002 From: larryf@sdintegrators.com (Larry Flathmann) Date: Wed, 10 Jul 2002 12:55:29 -0500 Subject: [LARTC] Subnet/routing question Message-ID: Forgive me if this is something so simple that i should already know it, but i need to understand if i can accomplish this with Linux routing. We have a /26 subnet from our ISP, and we have been using a Linux box as a firewall to put all our workstations behind NAT, with port forwarding for any box that's providing a service to the whole world. We now need to implement a system which will not support any kind of NAT - it requires having an external IP. Is it possible to use Linux routing to break up the /26 subnet into two /27 subnets, and to do NAT on addresses in one of the /27 subnets and to route addresses on the other /27 subnet straight through to that internal network? This is what i've tried, which i haven't gotten to work: ISP [x.y.z.193/26] | | [x.y.z.194/27 eth0] [x.y.z.225/27 eth0:0] Linux Firewall [192.168.0.0/24 eth1] (for NAT connections through the x.y.z.192/27 subnet) [x.y.z.226/27 eth1:0] (for straight through routing of IP addresses in the x.y.z.224/27 subnet) I've added rules to the routing table to create the connection, but i cannot get a packet with an address in the x.y.z.224/27 range to cross over between eth0 and eth1 in either direction. (Connections using NAT work fine) And the firewall is not stopping them, because the packets still don't go through even when i turn the firewall off. I'm definitely a newbie to the routing area, so maybe my routing table is wrong. What would i need in it? BTW, i'm running Mandrake Linux 8.2 right out of the box. Do i have to recompile the kernel to get some of these options? Thanks! I can't tell you how much i'd appreciate some light on this problem! Larry From fineberg@aviating.com Wed Jul 10 20:46:54 2002 From: fineberg@aviating.com (Adam B. Fineberg) Date: Wed, 10 Jul 2002 12:46:54 -0700 Subject: [LARTC] HZ to be 1000 - 2.5.25 may have this References: <001301c22831$d1852e30$2d00000a@foolaptop> Message-ID: <3D2C8F2E.30803@aviating.com> --------------070202000402070802060101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit CIT/Paul wrote: >HZ is set to 100 in that patch.. :> > > > >> >> >Try to download this url: >http://www.ibiblio.org/gentoo/distfiles/linux-gentoo-2.4.19-crypto-r7.pa >tch.bz2 > > Acutally in this patch the clock rate becomes configurable. HZ is set to CONFIG_JIFFIES which defaults to 1000. Best regards, Adam Fineberg fineberg@aviating.com --------------070202000402070802060101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit CIT/Paul wrote:
HZ is set to 100 in that patch.. :>

  
    
Try to download this url:
http://www.ibiblio.org/gentoo/distfiles/linux-gentoo-2.4.19-crypto-r7.pa
tch.bz2

Acutally in this patch the clock rate becomes configurable.  HZ is set to CONFIG_JIFFIES which defaults to 1000.

Best regards,
Adam Fineberg
fineberg@aviating.com
--------------070202000402070802060101-- From don-lartc@isis.cs3-inc.com Wed Jul 10 20:55:16 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Wed, 10 Jul 2002 12:55:16 -0700 Subject: [LARTC] Anything out there that is similar to Cisco's WFQ? In-Reply-To: <20020710194701.11721.17231.Mailman@outpost> References: <20020710194701.11721.17231.Mailman@outpost> Message-ID: <15660.37156.753518.403894@isis.cs3-inc.com> > From: "CIT/Paul" > Any help would be greatly appreciated :) This is much better than SFQ :> Sounds like SFQ to me. Can you tell us what the differences are? From mbabcock@fibrespeed.net Wed Jul 10 21:20:27 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Wed, 10 Jul 2002 16:20:27 -0400 Subject: [LARTC] Subnet/routing question References: Message-ID: <3D2C970B.2050301@fibrespeed.net> Try: eth0 (external) - > x.y.z.193/27 eth1 (internal) -> x.y.z.225/27 (non-nat) eth2 (internal) -> 192.168.0.0/24 (nat) eth0 -> turn on proxy_arp eth1 -> turn on proxy_arp eth2 -> leave proxy_arp off. This should work just fine. Connections for the eth1-connected addresses will 'forward' through the box (set up your firewall rules appropriately) from eth0 (and vice-versa). To explain what I mean: ipchains -A forward -s x.y.z.255/27 --jump ACCEPT ipchains -A forward -s 192.168.0.0/24 --jump MASQ ... have fun. -- Michael T. Babcock CTO, FibreSpeed Ltd. From xerox@foonet.net Wed Jul 10 21:16:32 2002 From: xerox@foonet.net (Paul) Date: Wed, 10 Jul 2002 16:16:32 -0400 Subject: [LARTC] RE: Anything out there that is similar to Cisco's WFQ? In-Reply-To: <15660.37156.753518.403894@isis.cs3-inc.com> Message-ID: Nooooo SFQ is not like WFQ... WRR is the closest thing to cisco's fair-queue.. WRR keeps track of the connections using the ip_conntrack .. that's sort of what cisco's fair-queue does and it checks the bandwidth streams and gives lower priority to the higher streams and larger packets.. it's meant to reduce latency for traffic shaping and it does :) I haven't tried WRR but it looks like the closest thing to it although it doesn't take everything in to account as cisco's flow based WFQ does.. Paul -----Original Message----- From: Don Cohen [mailto:don-lartc@isis.cs3-inc.com] Sent: Wednesday, July 10, 2002 3:55 PM To: xerox@foonet.net; lartc@mailman.ds9a.nl Subject: Anything out there that is similar to Cisco's WFQ? > From: "CIT/Paul" > Any help would be greatly appreciated :) This is much better than SFQ :> Sounds like SFQ to me. Can you tell us what the differences are? From mbabcock@fibrespeed.net Wed Jul 10 21:31:02 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Wed, 10 Jul 2002 16:31:02 -0400 Subject: [LARTC] Anything out there that is similar to Cisco's WFQ? References: <20020710194701.11721.17231.Mailman@outpost> <15660.37156.753518.403894@isis.cs3-inc.com> Message-ID: <3D2C9986.4050407@fibrespeed.net> Don Cohen wrote: > > From: "CIT/Paul" > > Any help would be greatly appreciated :) This is much better than SFQ :> > >Sounds like SFQ to me. Can you tell us what the differences are? > > PRIO'd SFQ. If you had classful PRIO with SFQ on each band, you'd probably have a similar effect to what's been described; just a guess though. It seems the desire is to 'ignore' low-priority bands if high-priority bands have traffic, and to balance between those sessions. -- Michael T. Babcock CTO, FibreSpeed Ltd. From don-lartc@isis.cs3-inc.com Wed Jul 10 21:27:21 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Wed, 10 Jul 2002 13:27:21 -0700 Subject: [LARTC] RE: Anything out there that is similar to Cisco's WFQ? In-Reply-To: References: <15660.37156.753518.403894@isis.cs3-inc.com> Message-ID: <15660.39081.965522.673251@isis.cs3-inc.com> Paul writes: > Nooooo SFQ is not like WFQ... WRR is the closest thing to cisco's > fair-queue.. > WRR keeps track of the connections using the ip_conntrack .. that's sort of > what > cisco's fair-queue does and it checks the bandwidth streams and gives lower > priority > to the higher streams and larger packets.. it's meant to reduce latency for > traffic > shaping and it does :) > I haven't tried WRR but it looks like the closest thing to it although it > doesn't > take everything in to account as cisco's flow based WFQ does.. This is not very convincing. Do you actually know how WFQ works? If so, please tell us. The doc you sent did not describe how it works but what the effects are, and those are entirely consistent with what SFQ does. High bandwidth flows are limited, low bandwidth flows get lower latency. Can you describe some effect that's different? From sandos@home.se Wed Jul 10 21:55:38 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 10 Jul 2002 22:55:38 +0200 Subject: [LARTC] RE: Anything out there that is similar to Cisco's WFQ? References: <15660.37156.753518.403894@isis.cs3-inc.com> <15660.39081.965522.673251@isis.cs3-inc.com> Message-ID: <014f01c22854$25e53f20$0219450a@sandos> > This is not very convincing. Do you actually know how WFQ > works? If so, please tell us. The doc you sent did not describe how > it works but what the effects are, and those are entirely consistent > with what SFQ does. > High bandwidth flows are limited, low bandwidth flows get lower > latency. Can you describe some effect that's different? I read a bit on WFQ earlier, Im not grasping it totally and I dont know every implementation detail, but I think its basically WRR but taking actual bandwidth usage into account, and not just packet-counts. Well, try this: http://www.sics.se/~ianm/WFQ/wfq_descrip/node21.html Im sure you all can get more out of it than me, a total newbie to queueing theory and QoS. --- John Bäckstrand From don-lartc@isis.cs3-inc.com Wed Jul 10 21:54:30 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Wed, 10 Jul 2002 13:54:30 -0700 Subject: [LARTC] RE: Anything out there that is similar to Cisco's WFQ? In-Reply-To: <014f01c22854$25e53f20$0219450a@sandos> References: <15660.37156.753518.403894@isis.cs3-inc.com> <15660.39081.965522.673251@isis.cs3-inc.com> <014f01c22854$25e53f20$0219450a@sandos> Message-ID: <15660.40710.643116.240722@isis.cs3-inc.com> =?iso-8859-1?Q?John_B=E4ckstrand?= writes: > > This is not very convincing. Do you actually know > how WFQ > > works? If so, please tell us. The doc you sent did > not describe how > > it works but what the effects are, and those are > entirely consistent > > with what SFQ does. > > High bandwidth flows are limited, low bandwidth flows > get lower > > latency. Can you describe some effect that's > different? > > I read a bit on WFQ earlier, Im not grasping it totally > and I dont know every implementation detail, but I > think its basically WRR but taking actual bandwidth > usage into account, and not just packet-counts. Well, > try this: > > http://www.sics.se/~ianm/WFQ/wfq_descrip/node21.html This sounds just like SFQ except for the weights. I have a variant of SFQ that does support weights if that's important. It's easy to add. (The hard part is the code that allows you to configure the weights.) From sandos@home.se Wed Jul 10 22:09:56 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 10 Jul 2002 23:09:56 +0200 Subject: [LARTC] RE: Anything out there that is similar to Cisco's WFQ? References: <15660.37156.753518.403894@isis.cs3-inc.com><15660.39081.965522.673251@isis.cs3-inc.com><014f01c22854$25e53f20$0219450a@sandos> <15660.40710.643116.240722@isis.cs3-inc.com> Message-ID: <018701c22856$2499e880$0219450a@sandos> > =?iso-8859-1?Q?John_B=E4ckstrand?= writes: > > > This is not very convincing. Do you actually know > > how WFQ > > > works? If so, please tell us. The doc you sent did > > not describe how > > > it works but what the effects are, and those are > > entirely consistent > > > with what SFQ does. > > > High bandwidth flows are limited, low bandwidth flows > > get lower > > > latency. Can you describe some effect that's > > different? > > > > I read a bit on WFQ earlier, Im not grasping it totally > > and I dont know every implementation detail, but I > > think its basically WRR but taking actual bandwidth > > usage into account, and not just packet-counts. Well, > > try this: > > > > http://www.sics.se/~ianm/WFQ/wfq_descrip/node21.html > > This sounds just like SFQ except for the weights. > I have a variant of SFQ that does support weights if that's important. > It's easy to add. (The hard part is the code that allows you to > configure the weights.) I was under the impression that the weights of WFQ isnt actually supposed to be set manually, but rather automatically. This page has a nice picture of WFQ (I think) http://www.cisco.com/warp/public/732/Tech/wfq/ It says: "Weight determined by: *Required QoS (IP Procedure, RSVP) *Flow throughput inversely proportional *Frame relay FECN, BECN, DE (for FR Traffic)" Only think I actually understood was "Flow throughput inversely proportional" which is a property I am looking for when trying to find a traffic control implementation. --- John Bäckstrand From sandos@home.se Wed Jul 10 22:14:45 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 10 Jul 2002 23:14:45 +0200 Subject: [LARTC] RE: Anything out there that is similar to Cisco's WFQ? References: <15660.37156.753518.403894@isis.cs3-inc.com><15660.39081.965522.673251@isis.cs3-inc.com><014f01c22854$25e53f20$0219450a@sandos> <15660.40710.643116.240722@isis.cs3-inc.com> Message-ID: <019d01c22856$d0ced6b0$0219450a@sandos> Btw, about the original question (havent got the original email left), there is a WFQ implementation for ALTQ and FreeBSD, but it seems to not work too well: http://www.criticalsoftware.com/research/pdf/Paper-PS.p df http://corn.eos.nasa.gov/qos/qos_results_summary_july98 .html --- John Bäckstrand From rodb@tce.com.au Thu Jul 11 01:36:55 2002 From: rodb@tce.com.au (Rod Blennerhassett) Date: Thu, 11 Jul 2002 08:36:55 +0800 Subject: [LARTC] RE: Priority Queueing on Linux Message-ID: <000401c22873$0f060cc0$2a42a8c0@servicemgr.perth.tce.com.au> Hi Patrick I have implement voice and data on a linux machine with the assistance of tc. I have found limited success with tc to this end. I am using an ADSL link of 1.5Mb/256Kb. I previously had a 64Kb ISDN link which I could not really get top quality out of with data and voice. (So I just throw lots of bandwidth at the problem!!) I experimented with cbq and sfq but did not go with this solution as they try to be fair about the data it is handling. Voice does not want fairness as voice is a beast that demands attention and it wants it now!! Instead I have implemented PRIO with tbf on the upstream and have tinkered with tbf on an ingress filter on the downstream. I have no direct experience with imq or htb but I have a feeling they may not assist with the immediacy voice requires. If someone can help us with that point it would be most appreciated. The biggest difference I found was changing the mtu to 300. I have assigned voice to TOS 0x10 and used iptables to mark the traffic appropriately. heres is my tc script: tc qdisc del dev eth0 root > /dev/null 2>&1 tc qdisc del dev eth0 ingress > /dev/null 2>&1 tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 1 3 2 3 3 3 0 3 3 3 3 3 3 3 3 3 tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 208kbit buffer 4kb limit 12kb mpu 50 tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 208kbit buffer 4kb limit 12kb mpu 50 tc qdisc add dev eth0 parent 1:4 handle 40: tbf rate 208kbit buffer 4kb limit 12kb mpu 50 tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 2 u32 match ip protocol 17 0xff match ip dport 1101 0xffff police rate 1536kbit burst 10k drop flowid :1 tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 match ip src 0.0.0.0/0 police rate 1312kbit burst 10k drop flowid :1 I have also played with the priomap, this modification is not necessary. All voice (tos 0x10) goes through the highest priority which I am not rate limiting. The rest of the bands I am rate limiting to 208Kb. On the ingress side I have identified my voice packets and let them have full bandwidth, the rest of the traffic I am rate limiting to 1312Kb. I don't know whether this helps the voice. If someone can comment on this it would be helpful. With this implementation I can have good quality voice conversations whilst downloading (or loading) My assumptions I have made about tc and voice and data are by no means authoritive, so any input on this subject from the group are welcome. Regards Rod Blennerhassett >Hi, > >Below is the explanation of priority queueing >http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm#xtocid22 > >I am developing a linux router. >There is both data and voice traffic passed thru it. > >When I use priority queueing on Cisco router, >the voice quality is good, evening downloading a large file. > >But I use the following tc config, the voice quality is not smooth >when downloading a large file: > >tc qdisc add dev ppp0 root handle 10: cbq bandwidth 112Kbit avpkt 1000 >tc class add dev ppp0 parent 10:0 classid 10:100 cbq bandwidth 112Kbit rate >57Kb >it allot 1514 weight 5Kbit prio 2 maxburst 20 avpkt 1000 isolated >tc class add dev ppp0 parent 10:0 classid 10:200 cbq bandwidth 112Kbit rate >55Kb >it allot 1514 weight 5Kbit prio 8 maxburst 20 avpkt 1000 bounded >tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15 >tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15 >tc filter add dev ppp0 parent 10:0 protocol ip prio 2 u32 match ip tos 0x8 >0xff >flowid 10:100 >tc filter add dev ppp0 parent 10:0 protocol ip prio 8 u32 match ip tos 0x00 >0xff > flowid 10:200 >voice packet is tagged with 0x8 in TOS field. >Voice traffic only uses 34K bandwidth. So the bandwidth allocated >to voice is enough. >Is there any better tc config? From smohan@vsnl.com Thu Jul 11 02:54:40 2002 From: smohan@vsnl.com (S Mohan) Date: Thu, 11 Jul 2002 07:24:40 +0530 Subject: [LARTC] Priority Queueing on Linux In-Reply-To: <80313B62CF86B749B7C416579F3944980298F7@mail.mtel> Message-ID: <000401c2287d$eceaa960$01000001@mohans> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C228AC.06A55660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You can use the prio options in qdisc and channel traffic thro' different qdiscs. Another option is to set TOS marks and route to qdiscs using the mark filters in u32 classifier. Why don't you look up http://www.docum.net . Staf has a good site going. I've benefitted from it. Mohan -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Patrick Chan Sent: Tuesday, July 09, 2002 9:33 AM To: lartc@mailman.ds9a.nl Subject: [LARTC] Priority Queueing on Linux There is priority queueing in Cisco router. Is there any equivalent implementation for TC on Linux? If yes, how can I configure and can you give me example? Thx. ------=_NextPart_000_0005_01C228AC.06A55660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
You=20 can use the prio options in qdisc and channel traffic thro' different = qdiscs.=20 Another option is to set TOS marks and route to qdiscs using the mark = filters in=20 u32 classifier.
 
Why=20 don't you look up http://www.docum.net . Staf=20 has a good site going. I've benefitted from it.
 
Mohan
-----Original Message-----
From:=20 lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On = Behalf=20 Of Patrick Chan
Sent: Tuesday, July 09, 2002 9:33=20 AM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] = Priority=20 Queueing on Linux

There is priority queueing in Cisco router. =

Is there any equivalent implementation for TC on = Linux?=20

If yes, how can I configure and can you give me=20 example?
Thx. =

------=_NextPart_000_0005_01C228AC.06A55660-- From smohan@vsnl.com Thu Jul 11 03:03:58 2002 From: smohan@vsnl.com (S Mohan) Date: Thu, 11 Jul 2002 07:33:58 +0530 Subject: [LARTC] Anything out there that is similar to Cisco's WFQ? In-Reply-To: <001201c2282a$90233880$2d00000a@foolaptop> Message-ID: <001101c2287f$393b2410$01000001@mohans> Try sfq qdisc as a leaf within a class. Mohan -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of CIT/Paul Sent: Wednesday, July 10, 2002 9:28 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] Anything out there that is similar to Cisco's WFQ? I've looked all over the place and I can't find Any queuing mechanism that is similar to the "fair-queue" on Cisco. It seems to work better than anything else that I have ever seen to create Lower latency for connections. This is what it does in brief (flow based WFQ) http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/q os_c/qcpart2/qcwfq.htm Any help would be greatly appreciated :) This is much better than SFQ :> Paul _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From alexey_talikov@texlab.com.uz Thu Jul 11 04:48:45 2002 From: alexey_talikov@texlab.com.uz (Alexey Talikov) Date: Thu, 11 Jul 2002 08:48:45 +0500 Subject: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: <3D2BDAEC.C8C4B872@srr.ro> Message-ID: May be you use ftp in passive mode, where port 20 not used 10.07.2002 11:57:48, Andrei Boros wrote: > > Since some other constraints require me to still run 2.2 kernel. >(drivers for some hardware not working under 2.4) > > I tried to control the ingress traffic with the ingress qdisc with no >success whatsoever. > I got 2.2.21 kernel and installed the ds8 patch to have the ingress >qdisc too. > Recompiled, installed kernel and modules. > Recompiled tc with diffserv=y. > > I tried a setup very similar to the example Edge2: > >ipchains -A input -p tcp -d 0/0 20 --mark 20 >ipchains -A input -p tcp -d 0/0 21 --mark 20 > >tc qdisc add dev eth0 handle ffff: ingress > >tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 20 fw >police rate 256kbit burst 25k mtu 1.5k drop flowid :1 > >I tried uploading with a ftp client and there was no traffic limit >imposed on what my box received. > >tc -s qdisc ls shows all counters as 0 (zero). > >I looked around for this issue and managed to find exactly my problem >described in a forum at >http://www.geocrawler.com/archives/3/11111/2001/5/0/5806401/ but the >message was unaswered there. > > If anyone has any suggestions, they are most welcome. > >-- >ing. Andrei Boros >mailto:andrei@srr.ro / +40-1-303-1870 >Centrul pt. Tehnologia Informatiei >Societatea Romana de Radiodifuziune >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From nitin_rpr@yahoo.com Thu Jul 11 06:05:58 2002 From: nitin_rpr@yahoo.com (nitin panjwani) Date: Wed, 10 Jul 2002 22:05:58 -0700 (PDT) Subject: [LARTC] Re: Ethernet interface shuts down In-Reply-To: <20020710042620.20014.53903.Mailman@outpost> Message-ID: <20020711050558.54129.qmail@web20302.mail.yahoo.com> Bert thanks for your reply It seems routing daemons are not creating problem. with: "ifconfig eth1 up " I find that I am able to make interface up again, but it disappears after a while if I do not do anything on this machine for a while and comes back again with "ifconfig eth1 up " I have another similar kind of problem. I will describe it: (R1)eth0-------eth1(R2) If for certain time I do not work on the machine then I am not able to ping the remote interface .eg eth0 from R2 and eth1 from R1.While local interfaces are pingable and ifconfig/ip addr shows that that interfaces are up on both sides. Initailly when I rebooted both machines these two boxes were mutually pingable.ip route also recognizes the availability of the networks. In this case also I am not running Any routing daemon. Any help on this will be very appreciable. Thanks in advance, Nitin __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From andrei@srr.ro Thu Jul 11 06:43:17 2002 From: andrei@srr.ro (Andrei Boros) Date: Thu, 11 Jul 2002 08:43:17 +0300 Subject: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch Message-ID: <3D2D1AF5.3CA48A3F@srr.ro> Alexey Talikov wrote: > > May be you use ftp in passive mode, where port 20 not used > No, I set the client not to use passive mode, and confirmed it with tcpdump. If it were a protocol/port specific thing I'd dig more in that direction. And the statistic counters are on zero at all times. If it were passive mode, why didn't the ingress capture the ftp session packets on port 21??? I even set firewall to mark everything and the filter directs it to ingress. Nothing happened. > > Since some other constraints require me to still run 2.2 kernel. > >(drivers for some hardware not working under 2.4) > > > > I tried to control the ingress traffic with the ingress qdisc with no > >success whatsoever. > > I got 2.2.21 kernel and installed the ds8 patch to have the ingress > >qdisc too. > > Recompiled, installed kernel and modules. > > Recompiled tc with diffserv=y. > > > > I tried a setup very similar to the example Edge2: > > > >ipchains -A input -p tcp -d 0/0 20 --mark 20 > >ipchains -A input -p tcp -d 0/0 21 --mark 20 > > > >tc qdisc add dev eth0 handle ffff: ingress > > > >tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 20 fw > >police rate 256kbit burst 25k mtu 1.5k drop flowid :1 > > > >I tried uploading with a ftp client and there was no traffic limit > >imposed on what my box received. > > > >tc -s qdisc ls shows all counters as 0 (zero). > > > >I looked around for this issue and managed to find exactly my problem > >described in a forum at > >http://www.geocrawler.com/archives/3/11111/2001/5/0/5806401/ but the > >message was unaswered there. > > > > If anyone has any suggestions, they are most welcome. > > > >-- > >ing. Andrei Boros > >mailto:andrei@srr.ro / +40-1-303-1870 > >Centrul pt. Tehnologia Informatiei > >Societatea Romana de Radiodifuziune > >_______________________________________________ > >LARTC mailing list / LARTC@mailman.ds9a.nl > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > ----------------------------------- > mailto:alexey_talikov@texlab.com.uz > BR > Alexey Talikov > FORTEK > ----------------------------------- > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- ing. Andrei Boros mailto:andrei@srr.ro / +40-1-303-1870 Centrul pt. Tehnologia Informatiei Societatea Romana de Radiodifuziune From carles@descom.es Thu Jul 11 10:31:16 2002 From: carles@descom.es (Carles Xavier Munyoz =?iso-8859-1?q?Bald=F3?=) Date: Thu, 11 Jul 2002 11:31:16 +0200 Subject: [LARTC] Where is the howto ? Message-ID: <200207111131.20800.carles@descom.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Where is the file pinted by the link "a good section on how to combine=20 multiple internet links succesfully" (http://lartc.org/howto/x247.html) May anyone recomend me another links for combine multiple internet links=20 succesfully ? Greetings. - --- Carles Xavier Munyoz Bald=F3 carles@descom.es Descom Consulting Telf: +34 965861024 Fax: +34 965861024 http://www.descom.es/ - --- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPS1QZTvYAf7VZNaaEQKHjgCg8HEbpXQ+lxjtyFfv5Rr8ZvHRihIAniqX WhsV4YQE+IjmOVOFHF0yJVjK =3DXliH -----END PGP SIGNATURE----- From Jerome.Kerdreux@finix.eu.org Thu Jul 11 11:18:09 2002 From: Jerome.Kerdreux@finix.eu.org (Jerome Kerdreux) Date: Thu, 11 Jul 2002 12:18:09 +0200 (CEST) Subject: [LARTC] Multiple ADSL link Message-ID: Hi all, It's my first post on this list, i'm not a ip route / qdisc guru, and have a awfull english. So if i may say something stupid ... In fact i got a problem with my ISP(s) . I have 2 ISP / 2 DSL Modem / 3 nic / on my firewall and something like 20 computers behing it. 20 machines with 192.168.0.xxx/16 private IPs | | |eth2 (192.168.0.1) ====================== | Linux 2.4.18 | ====================== |eth0 |eth1 | | | | | | ppp0 ppp1 (IP1) (IP2) Notation : provider 1 : IF1="ppp0" # interface IP1="xxx.xxx.xxx.xxx" # ip of if1 P1="xxx.xxx.xxx.1" # gateway ip P1_NET="xxx.xxx.xxx.0" # network provider 2 : IF2="ppp1" IP2= ... P2= ... P2_NET= ... eth0 and eth1 have no ip there are only used for the ppp Now I can only use 1 provider at the same time cause I can't route them. As said before I want to use the provider at the same time without distinction.(Perhaps I will look at a way to have stmp / dns / ssh on one ppp and ftp / http on the other but i gonna try w/ a simple thing before ) I tried several things like the teql module. http://lartc.org/howto/lartc.loadshare.html but I still have the same pb. the teql module is loaded but outgoing packet don't know the way to go out (I think) So yesterday i try w/ load balancing way http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN284 (multipath in fact) I figured out how to have ppp0 and ppp1 used at the same time the ppp0 doesn't transmit anything. only some udp 6 (really strange) Another thing I don't really understand if I need to use the Split Access (previous in the howto). This section isn't really clear for my awfull english and isn't transalted in the french howto. Does I need to add something else than ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1 And the next question is how can I NAT this traffic cause I don't have only one IF but 2 ? (with teql I is easy .. but don't work for me) .. Thanks for any help. ------------------------ Jerome Kerdreux aka SoaF From carles@descom.es Thu Jul 11 11:41:37 2002 From: carles@descom.es (Carles Xavier Munyoz =?iso-8859-1?q?Bald=F3?=) Date: Thu, 11 Jul 2002 12:41:37 +0200 Subject: [LARTC] Multilink. Message-ID: <200207111241.41424.carles@descom.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have one computer with 3 ISDN internet links and other one with 1 DSL=20 internet link. I want communicate this two computers but I need that computer one uses t= he 3=20 ISDN links combined to obtain a greater bandwith. How may I do this ? Is multilink my best solution ? May someone give me advises about howto do it in Linux ? Greetings. - --- Carles Xavier Munyoz Bald=F3 carles@descom.es Descom Consulting Telf: +34 965861024 Fax: +34 965861024 http://www.descom.es/ - --- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPS1g4jvYAf7VZNaaEQIg4wCfdcPJiaxmCAMB9w/uq4pbL78Dc4YAoKNO DGzBebR0VPUGMA3sZI4Y4oLv =3DuwmP -----END PGP SIGNATURE----- From hadi@cyberus.ca Thu Jul 11 13:06:38 2002 From: hadi@cyberus.ca (jamal) Date: Thu, 11 Jul 2002 08:06:38 -0400 (EDT) Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: <3D2D1AF5.3CA48A3F@srr.ro> Message-ID: I havent run any 2.2 code in years (and dont have a machine with such code;->) Can you turn on debugging in the ingress code? Does the same syntax work in 2.4? cheers, jamal On Thu, 11 Jul 2002, Andrei Boros wrote: > > Alexey Talikov wrote: > > > > May be you use ftp in passive mode, where port 20 not used > > > No, I set the client not to use passive mode, and confirmed it with > tcpdump. If it were a protocol/port specific thing I'd dig more in that > direction. > And the statistic counters are on zero at all times. > If it were passive mode, why didn't the ingress capture the ftp session > packets on port 21??? > > I even set firewall to mark everything and the filter directs it to > ingress. Nothing happened. > > > > > Since some other constraints require me to still run 2.2 kernel. > > >(drivers for some hardware not working under 2.4) > > > > > > I tried to control the ingress traffic with the ingress qdisc with no > > >success whatsoever. > > > I got 2.2.21 kernel and installed the ds8 patch to have the ingress > > >qdisc too. > > > Recompiled, installed kernel and modules. > > > Recompiled tc with diffserv=y. > > > > > > I tried a setup very similar to the example Edge2: > > > > > >ipchains -A input -p tcp -d 0/0 20 --mark 20 > > >ipchains -A input -p tcp -d 0/0 21 --mark 20 > > > > > >tc qdisc add dev eth0 handle ffff: ingress > > > > > >tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 20 fw > > >police rate 256kbit burst 25k mtu 1.5k drop flowid :1 > > > > > >I tried uploading with a ftp client and there was no traffic limit > > >imposed on what my box received. > > > > > >tc -s qdisc ls shows all counters as 0 (zero). > > > > > >I looked around for this issue and managed to find exactly my problem > > >described in a forum at > > >http://www.geocrawler.com/archives/3/11111/2001/5/0/5806401/ but the > > >message was unaswered there. > > > > > > If anyone has any suggestions, they are most welcome. > > > > > >-- > > >ing. Andrei Boros > > >mailto:andrei@srr.ro / +40-1-303-1870 > > >Centrul pt. Tehnologia Informatiei > > >Societatea Romana de Radiodifuziune > > >_______________________________________________ > > >LARTC mailing list / LARTC@mailman.ds9a.nl > > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > > > ----------------------------------- > > mailto:alexey_talikov@texlab.com.uz > > BR > > Alexey Talikov > > FORTEK > > ----------------------------------- > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- > ing. Andrei Boros > mailto:andrei@srr.ro / +40-1-303-1870 > Centrul pt. Tehnologia Informatiei > Societatea Romana de Radiodifuziune > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > PC Mods, Computing goodies, cases & more > http://thinkgeek.com/sf > _______________________________________________ > Diffserv-general mailing list > Diffserv-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/diffserv-general > From ahu@ds9a.nl Thu Jul 11 14:10:47 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 11 Jul 2002 15:10:47 +0200 Subject: [LARTC] Where is the howto ? In-Reply-To: <200207111131.20800.carles@descom.es> References: <200207111131.20800.carles@descom.es> Message-ID: <20020711131047.GA31410@outpost.ds9a.nl> On Thu, Jul 11, 2002 at 11:31:16AM +0200, Carles Xavier Munyoz Bald? wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > Where is the file pinted by the link "a good section on how to combine > multiple internet links succesfully" (http://lartc.org/howto/x247.html) http://lartc.org/howto/lartc.rpdb.multiple-links.html Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From Jerome.Kerdreux@finix.eu.org Thu Jul 11 15:12:07 2002 From: Jerome.Kerdreux@finix.eu.org (Jerome Kerdreux) Date: Thu, 11 Jul 2002 16:12:07 +0200 (CEST) Subject: [LARTC] Multiple ADSL link In-Reply-To: References: Message-ID: Today, mahhy a =E9crit: m>On Thu, 11 Jul 2002, Jerome Kerdreux wrote: m>> ip route add default scope global nexthop via $P1 dev $IF1 weight 1 m>> nexthop via $P2 dev $IF2 weight 1 m>I havent looked at the LARTC HOWTO in depth yet, but I believe you are m>wanting to implement Equal Cost Multipath Routing. ECM allows for m>*outgoing* traffic to be load-balanced across multiple ISP connections. m> m>There is some good information in the Advanced Routing HOWTO on m>http://www.linuxdoc.org, I suggest you read that as well. m> m>Here is the general script I use to implement ECM, you will have to edit m>it for your own values (different interface names, IP addresses, gateway m>addresses, etc): m> m> /sbin/ip rule add from table 124 m> /sbin/ip rule add from table 120 m> /sbin/ip route add default via dev eth0 table 124 m> /sbin/ip route add default via dev ppp0 table 120 m> /sbin/ip route delete default m> /sbin/ip route add default scope global nexthop via dev m>eth0 nexthop via dev ppp0 m> /sbin/ip route flush cache m> m> is the first IP address on my Linux Router m> is the second IP address on my Linux Router m> is the first IP address's default Gateway m> is the second IP address's default Gateway m> m>replace them with appropriate values for your system. Oh thanks Mahhy I test that :) Here is what I test : /sbin/ip rule add from table T1 /sbin/ip rule add from table T2 /sbin/ip route add default via dev ppp0 table T1 /sbin/ip route add default via dev ppp1 table T2 /sbin/ip route delete default /sbin/ip route add default scope global nexthop via dev ppp0 = nexthop via dev ppp1 /sbin/ip route flush cache but I still have the same pb =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ip route: 194.206.78.3 dev ppp1 proto kernel scope link src 62.212.102.172 80.15.151.1 dev ppp0 proto kernel scope link src 80.15.151.117 192.168.0.0/16 dev eth2 proto kernel scope link src 192.168.0.1 default nexthop via 80.15.151.117 dev ppp0 weight 1 dead nexthop via 62.212.102.172 dev ppp1 weight 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ppp0 seems to be detected as dead. So all the trafic go throught ppp1 and only get this on ppp0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D tcpdump -i ppp0: 15:50:22.786991 80.24.174.28.1073 > 80.15.151.117.4665: udp 6 15:50:22.787074 80.15.151.117 > 80.24.174.28: icmp: 80.15.151.117 udp port 4665 unreachable [tos 0xc0] 15:50:36.917769 62.178.40.99.1275 > 80.15.151.117.4665: udp 6 15:50:36.917855 80.15.151.117 > 62.178.40.99: icmp: 80.15.151.117 udp port 4665 unreachable [tos 0xc0] 15:50:37.446685 217.235.251.61.2588 > 80.15.151.117.4665: udp 6 15:50:37.446767 80.15.151.117 > 217.235.251.61: icmp: 80.15.151.117 udp port 4665 unreachable [tos 0xc0] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D all the trafic i get it that :( Another thing is that when I drop all the route and just put ppp0 as default route. this interface works well . this sound really strange. Any body have a idea ? I put the list in Cc: too :) /Thanks From ganesh kumar godavari" hello group, eth0 eth1 eth0 internet-----firewall--------10mbps hub------server i have the following configuration of machines all the packets pass through the firewall (port forwarding) to the server, this works fine, but some times the firewall gets congested in case of an DOS attack so i want the output not to go through the firewall. i want the output to go via another connection? ps: connection for me is the not based on the ISP, but the connection provided to me at school. is this possible? if so how can one do it. eth0 eth1 eth0 eth1 internet-----firewall--------10mbps hub------server----- internet thanks ganesh _________________________________________________________ There is always a better job for you at Monsterindia.com. Go now http://monsterindia.rediff.com/jobs From ja@ssi.bg Fri Jul 12 00:40:44 2002 From: ja@ssi.bg (Julian Anastasov) Date: Thu, 11 Jul 2002 23:40:44 +0000 (GMT) Subject: [LARTC] Multiple ADSL link In-Reply-To: Message-ID: Hello, On Thu, 11 Jul 2002, Jerome Kerdreux wrote: > default > nexthop via 80.15.151.117 dev ppp0 weight 1 dead > nexthop via 62.212.102.172 dev ppp1 weight 1 > =================================================================== > > ppp0 seems to be detected as dead. This bug is fixed in iproute2 package from this year. Fetch the latest archive. Regards -- Julian Anastasov From Jerome.Kerdreux@finix.eu.org Thu Jul 11 23:04:46 2002 From: Jerome.Kerdreux@finix.eu.org (Jkx) Date: Fri, 12 Jul 2002 00:04:46 +0200 (CEST) Subject: [LARTC] Multiple ADSL link In-Reply-To: Message-ID: On Thu, 11 Jul 2002, Julian Anastasov wrote: > > Hello, > > On Thu, 11 Jul 2002, Jerome Kerdreux wrote: > > > default > > nexthop via 80.15.151.117 dev ppp0 weight 1 dead > > nexthop via 62.212.102.172 dev ppp1 weight 1 > > =================================================================== > > > > ppp0 seems to be detected as dead. > > This bug is fixed in iproute2 package from this year. > Fetch the latest archive. (Please add this in the Howto . I spent a couple of hours to find that) Ok thanks .. I miss this bug fix . and gonna try this tomorrow. so the nex question is : How could i NAT my local traffic throught this 2 ppp I usually do that w / $IPTABLES -t nat -A POSTROUTING -o ppp0 -j MASQUERADE but this assume you have only one not two :)) Thanks again all for the help. :) From ja@ssi.bg Fri Jul 12 02:08:38 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 12 Jul 2002 01:08:38 +0000 (GMT) Subject: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: <3D2BDAEC.C8C4B872@srr.ro> Message-ID: Hello, On Wed, 10 Jul 2002, Andrei Boros wrote: > I tried to control the ingress traffic with the ingress qdisc with no > success whatsoever. > I got 2.2.21 kernel and installed the ds8 patch to have the ingress > qdisc too. You probably have to apply more fixes to be sure something will not break. I just uploaded some fixes for the 2.2 code as it appears nobody have the time to deal with it: http://www.linuxvirtualserver.org/~julian/#qos-2.2 To all: if there is a good place for such fixes please let me know. > Recompiled, installed kernel and modules. > Recompiled tc with diffserv=y. > > I tried a setup very similar to the example Edge2: Not "very similar" :) The bug is exactly in the differences :) mark here is in decimal (may be can be hex with 0x20): > ipchains -A input -p tcp -d 0/0 20 --mark 20 > ipchains -A input -p tcp -d 0/0 21 --mark 20 > > tc qdisc add dev eth0 handle ffff: ingress "handle 20" here is in hex: > tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 20 fw > police rate 256kbit burst 25k mtu 1.5k drop flowid :1 if you somewhere use fwmark in ip rules, the fwmark there is again in hex. Make sure all values match according to their representation, i.e. 20 in dec is different from 20 in hex. > If anyone has any suggestions, they are most welcome. Regards -- Julian Anastasov From ja@ssi.bg Fri Jul 12 02:17:03 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 12 Jul 2002 01:17:03 +0000 (GMT) Subject: [LARTC] Multiple ADSL link In-Reply-To: Message-ID: Hello, On Fri, 12 Jul 2002, Jkx wrote: > > This bug is fixed in iproute2 package from this year. > > Fetch the latest archive. > > (Please add this in the Howto . I spent a couple of > hours to find that) Always use the latest software in such situations, the HowTo is not a changelog :) > so the nex question is : > How could i NAT my local traffic throught this 2 ppp > I usually do that w / Check this URL: http://www.linuxvirtualserver.org/~julian/#routes and read some docs and the included examples. Then you will be able to build correct routing rules for your setup. Regards -- Julian Anastasov From stew@michaelishof.de Fri Jul 12 00:15:49 2002 From: stew@michaelishof.de (Arvid =?iso-8859-1?Q?St=FCwe?=) Date: Fri, 12 Jul 2002 01:15:49 +0200 Subject: [LARTC] Shaping per type/size of connection Message-ID: <20020711231549.GA2962@aurora.michaelishof.etc.tu-bs.de> Hi! Currently I'm controlling 4 Mbit Connection based on the source and destination ports, so that ftp traffic doesn't clog the line and udp packets and other time critical things (ssh, irc, etc...) get priority. Normally that works just fine, but two problems remain: - How do I recognize traffic from non-standard ports? (like a ftp-server on port 1337) - Big http-transfers still clog the line I want my users to be able to surf fast. But when they download big files from a webserver this transfer should be slowed down. Perhaps a way to slow down any connection that exceeds a certain size would solve both problems. Any suggestions, pointers or ideas for a better policy are welcome! Arvid -- in bunten Bildern wenig Klarheit, viel Irrtum und ein Fünkchen Wahrheit (Johann Wolfgang v. Goethe) From andrei@srr.ro Fri Jul 12 06:50:26 2002 From: andrei@srr.ro (Andrei Boros) Date: Fri, 12 Jul 2002 08:50:26 +0300 Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 withds8 patch References: Message-ID: <3D2E6E22.3CB7EC6B@srr.ro> jamal wrote: > > I havent run any 2.2 code in years (and dont have a machine with such > code;->) > Can you turn on debugging in the ingress code? > Does the same syntax work in 2.4? > Couldn't try the same thing under 2.4 because I have no machine with 2.4 at my disposal. How do I turn on debugging in the ingress code? -- ing. Andrei Boros mailto:andrei@srr.ro / +40-1-303-1870 Centrul pt. Tehnologia Informatiei Societatea Romana de Radiodifuziune From andrei@srr.ro Fri Jul 12 06:56:52 2002 From: andrei@srr.ro (Andrei Boros) Date: Fri, 12 Jul 2002 08:56:52 +0300 Subject: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch References: Message-ID: <3D2E6FA4.62C96AF5@srr.ro> Julian Anastasov wrote: > > You probably have to apply more fixes to be sure something > will not break. I just uploaded some fixes for the 2.2 code as > it appears nobody have the time to deal with it: > > http://www.linuxvirtualserver.org/~julian/#qos-2.2 I'll try them asap. > > To all: if there is a good place for such fixes please let > me know. > > > Recompiled, installed kernel and modules. > > Recompiled tc with diffserv=y. > > > > I tried a setup very similar to the example Edge2: > > Not "very similar" :) The bug is exactly in the > differences :) I also tried filtering using the u32 match ip dport ... same result. I even tried u32 match ip (anything ip), same result. > mark here is in decimal (may be can be hex with 0x20): > > > ipchains -A input -p tcp -d 0/0 20 --mark 20 > > ipchains -A input -p tcp -d 0/0 21 --mark 20 > > > > tc qdisc add dev eth0 handle ffff: ingress > > "handle 20" here is in hex: > > > tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 20 fw > > police rate 256kbit burst 25k mtu 1.5k drop flowid :1 > > if you somewhere use fwmark in ip rules, the fwmark > there is again in hex. Make sure all values match according > to their representation, i.e. 20 in dec is different from > 20 in hex. Sorry. However, I don't know of any place where these differences are explained clearly. -- ing. Andrei Boros mailto:andrei@srr.ro / +40-1-303-1870 Centrul pt. Tehnologia Informatiei Societatea Romana de Radiodifuziune From ja@ssi.bg Fri Jul 12 10:46:41 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 12 Jul 2002 09:46:41 +0000 (GMT) Subject: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: <3D2E6FA4.62C96AF5@srr.ro> Message-ID: Hello, On Fri, 12 Jul 2002, Andrei Boros wrote: > I also tried filtering using the u32 match ip dport ... same result. > I even tried u32 match ip (anything ip), same result. This is another issue, may be for howto:12.1.2. Bert promised to clarify them in the Howto: http://mailman.ds9a.nl/pipermail/lartc/2001q4/thread.html Search for "tc: u32 match in nexthdr not working?" In short, dport and sport do not always match, eg. for packets with IP Options. Try different examples. May be your settings are incorrect. > Sorry. However, I don't know of any place where these differences are > explained clearly. Huh. I don't want to start new howto :) Regards -- Julian Anastasov From hanhbnetfilter@yahoo.com.cn Fri Jul 12 08:44:01 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Fri, 12 Jul 2002 15:44:01 +0800 (CST) Subject: [LARTC] HTB filter rules Message-ID: <20020712074401.98359.qmail@web15004.mail.bjs.yahoo.com> HTB and imq was used to control traffic. |----| eth0|------|eth2 |-----| | B |------|___A__|------| D | |____| |eth1 |_____| __|__ | C | |____| A:three NIC was bind to br0:172.16.6.235/24 B:172.16.6.3/24 D:172.16.6.4/24 C:172.16.6.2/24 htb was used to control traffic on A stuctrul is like that(default is 1:20): |----1:100 |------1:10| 1:1| |____1:110 | |------1:20 #AC="tc filter add dev eth1 protocol ip parent 1:0 prio 1" #$AC u32 match u32 0xac100600 0xffffff00 at 16 flowid 1:10 #$AC u32 match u32 0xac100603 0xffffffff at 16 flowid 1:100 I copy a file from C to B, class 1:100 go into effect. but when I copy a file from C to D class 1:10 did not go into effect class 1:20 take effect. please tell me if filter can not be appended to parent class, it can only be appended to leaf(end of class). my htb version is htb3.6-020525 _________________________________________________________ Do You Yahoo!? ÒĝŜÍ·ÛğáÖÔ­ ´óÀËÌÔĦ½ĦŻË­½ĞĤ°Á http://sweepstakes.yahoo.com/bank_surveywave2/ From hadi@cyberus.ca Fri Jul 12 10:57:13 2002 From: hadi@cyberus.ca (jamal) Date: Fri, 12 Jul 2002 05:57:13 -0400 (EDT) Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 withds8 patch In-Reply-To: <3D2E6E22.3CB7EC6B@srr.ro> Message-ID: On Fri, 12 Jul 2002, Andrei Boros wrote: > > Couldn't try the same thing under 2.4 because I have no machine with 2.4 > at my disposal. > fair enough. BTW, now that i am actually thinking, another very stupid question -- if you are trying to ingress police, do you have policing compiled in under QoS? double check this. Infact the more i think about the more i believe this may be your problem. > How do I turn on debugging in the ingress code? > If you edit net/sched/sch_ingress.c at the very top you should see: ---------- #undef DEBUG_INGRESS #ifdef DEBUG_INGRESS /* control */ #define DPRINTK(format,args...) printk(KERN_DEBUG format,##args) #else #define DPRINTK(format,args...) #endif #if 0 /* data */ #define D2PRINTK(format,args...) printk(KERN_DEBUG format,##args) #else #define D2PRINTK(format,args...) #endif ----------- convert to: --- #if 1 #define DPRINTK(format,args...) printk(KERN_DEBUG format,##args) #else #define DPRINTK(format,args...) #endif #if 1 /* data */ #define D2PRINTK(format,args...) printk(KERN_DEBUG format,##args) #else #define D2PRINTK(format,args...) #endif ----------- run your tests and look at dmesg. cheers, jamal From hadi@cyberus.ca Fri Jul 12 11:11:43 2002 From: hadi@cyberus.ca (jamal) Date: Fri, 12 Jul 2002 06:11:43 -0400 (EDT) Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: Message-ID: On Fri, 12 Jul 2002, Julian Anastasov wrote: > > Hello, > > On Wed, 10 Jul 2002, Andrei Boros wrote: > > > I tried to control the ingress traffic with the ingress qdisc with no > > success whatsoever. > > I got 2.2.21 kernel and installed the ds8 patch to have the ingress > > qdisc too. > > You probably have to apply more fixes to be sure something > will not break. I just uploaded some fixes for the 2.2 code as > it appears nobody have the time to deal with it: Werner and I did announce (about 2 years ago if i am not mistaken) that we will not be backporting features fixes etc to 2.2 and were hoping to encourage people to upgrade this way. > > http://www.linuxvirtualserver.org/~julian/#qos-2.2 > > To all: if there is a good place for such fixes please let > me know. > Honestly dont remember these patches -- maybe the time lag. BTW, what is the motivatein behind: http://www.linuxvirtualserver.org/~julian/01_ingress-breaks-fw-1.diff > > Recompiled, installed kernel and modules. > > Recompiled tc with diffserv=y. > > tc qdisc add dev eth0 handle ffff: ingress > > "handle 20" here is in hex: > Is this true with the mark target in iptables? Bert should probably document this in his HOWTO. cheers, jamal From ja@ssi.bg Fri Jul 12 11:49:29 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 12 Jul 2002 13:49:29 +0300 (EEST) Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: Message-ID: Hello, On Fri, 12 Jul 2002, jamal wrote: > Werner and I did announce (about 2 years ago if i am not mistaken) that > we will not be backporting features fixes etc to 2.2 and were hoping to > encourage people to upgrade this way. There are still 2.2 users :) > > http://www.linuxvirtualserver.org/~julian/#qos-2.2 > > > > To all: if there is a good place for such fixes please let > > me know. > > > > Honestly dont remember these patches -- maybe the time lag. > BTW, what is the motivatein behind: > http://www.linuxvirtualserver.org/~julian/01_ingress-breaks-fw-1.diff At least, FW_REDIRECT, not sure for any others > cheers, > jamal Regards -- Julian Anastasov From sandos@home.se Fri Jul 12 12:42:39 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Fri, 12 Jul 2002 13:42:39 +0200 Subject: [LARTC] Shaping per type/size of connection References: <20020711231549.GA2962@aurora.michaelishof.etc.tu-bs.de> Message-ID: <001701c22999$3990c800$0219450a@sandos> > Hi! > Currently I'm controlling 4 Mbit Connection based on the source and > destination ports, so that ftp traffic doesn't clog the line and udp packets > and other time critical things (ssh, irc, etc...) get priority. > > Normally that works just fine, but two problems remain: > > - How do I recognize traffic from non-standard ports? > (like a ftp-server on port 1337) > > - Big http-transfers still clog the line > I want my users to be able to surf fast. But when they download > big files from a webserver this transfer should be slowed down. > > Perhaps a way to slow down any connection that exceeds a certain size would > solve both problems. Any suggestions, pointers or ideas for a better policy > are welcome! WFQ seems to do just this, but in lack of any real implementation there is wrr: http://wipl-wrr.sourceforge.net/ It has the ability to automatically lower the weights of streams with high bandwidth-usage. --- John Bäckstrand From hadi@cyberus.ca Fri Jul 12 12:37:51 2002 From: hadi@cyberus.ca (jamal) Date: Fri, 12 Jul 2002 07:37:51 -0400 (EDT) Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: Message-ID: On Fri, 12 Jul 2002, Julian Anastasov wrote: > > Hello, > > On Fri, 12 Jul 2002, jamal wrote: > > > Werner and I did announce (about 2 years ago if i am not mistaken) that > > we will not be backporting features fixes etc to 2.2 and were hoping to > > encourage people to upgrade this way. > > There are still 2.2 users :) > If you look at the old postings on the diffserv mailing list youll see about 70% of the questions were related to "my patch failed" etc (people patching in the wrong directory etc). Believe it or not a _lot_ of Linux users still hate patching (I have matured to accept it) or are not very skilled or bothered to learn; they just install connectiva 8 and are off to cook: i.e they just want things to work. Now unlike MS, we have the code! infact Werner has clearly documented what the changes from 2.2->2.4 are in his doc. I know the only time i have lately is for breathing (hopefully fresh air at work) and this backporting requires abuse of the brain cells more than thinking i.e its mechanical and therefore requires concentration/focus; so if someone could submit a backport patch i think we would put it up the website. I believe we could even push it into the 2.2 next release since this stuff is pretty much stable right now. > > BTW, what is the motivatein behind: > > http://www.linuxvirtualserver.org/~julian/01_ingress-breaks-fw-1.diff > > At least, FW_REDIRECT, not sure for any others > I am trying to think of some way to probably do this from ingress instead since some people actually want that overwrite. cheers, jamal From mage@adamant.net Fri Jul 12 13:23:24 2002 From: mage@adamant.net (Alexander Trotsai) Date: Fri, 12 Jul 2002 15:23:24 +0300 Subject: [LARTC] IMQ crash dump Message-ID: <20020712122324.GT27253@blackhole.adamant.ua> Hi I try setup imq pseudo device for shaping I'm work such script #!/bin/sh TC=/sbin/tc /sbin/modprobe imq numdevs=1 /sbin/ip link set imq0 up $TC qdisc add dev imq0 handle 1: root htb default 1 $TC class add dev imq0 parent 1: classid 1:1 htb rate 10mbit # client1 tunnel tunnel $TC class add dev imq0 parent 1: classid 1:2 htb rate 256kbit $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src 10.255.255.40/30 flowid 1:2 $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src 10.255.255.52/30 flowid 1:2 # client2 $TC class add dev imq0 parent 1: classid 1:3 htb rate 128kbit $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src x.x.x.x/30 flowid 1:3 # client3 $TC class add dev imq0 parent 1: classid 1:4 htb rate 64kbit $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src x.x.x.x/30 flowid 1:4 # client4 $TC class add dev imq0 parent 1: classid 1:5 htb rate 64kbit ceil 768kbit $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src x.x.x.x/30 flowid 1:5 # send to intarface all from eth0.9 (clients) /sbin/iptables -t mangle -A PREROUTING -i eth0.9 -j IMQ All patches I get from http://luxik.cdi.cz/~patrick/imq/ iptables and kernel modules compiled and loaded successfully But after run last line /sbin/iptables -t mangle -A PREROUTING -i eth0.9 -j IMQ I got kernel crush and register stack I can't save it because kernel frezze O, my kernel is Linux watcher 2.4.19-pre8-ac5 #2 Wed Jul 10 10:08:55 EEST 2002 i686 unknown May be I do something wrong or any other ideas? -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] Big trouble - The Borg tried to assimilate your system. Resistance is futile. From ja@ssi.bg Fri Jul 12 13:26:32 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 12 Jul 2002 15:26:32 +0300 (EEST) Subject: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch In-Reply-To: Message-ID: Hello, On Fri, 12 Jul 2002, jamal wrote: > If you look at the old postings on the diffserv mailing list youll see > about 70% of the questions were related to "my patch failed" etc (people > patching in the wrong directory etc). Believe it or not a _lot_ of Linux > users still hate patching (I have matured to accept it) or are not > very skilled or bothered to learn; they just install connectiva 8 and are > off to cook: i.e they just want things to work. > Now unlike MS, we have the code! infact Werner has clearly documented what > the changes from 2.2->2.4 are in his doc. I know the only time i have > lately is for breathing (hopefully fresh air at work) and this backporting > requires abuse of the brain cells more than thinking i.e its mechanical > and therefore requires concentration/focus; > > so if someone could submit a backport patch i think we would > put it up the website. I believe we could even push it into the 2.2 next > release since this stuff is pretty much stable right now. At least, we need valid patch with the most needed fixes. I think, I can walk the both trees and to fix the obvious bugs that are fixed in 2.4. At first look, the changes are not too much, so we will be back soon with the most needed fixes. I can report that the small part of the code I'm using looks stable enough. > > > BTW, what is the motivatein behind: > > > http://www.linuxvirtualserver.org/~julian/01_ingress-breaks-fw-1.diff > > > > At least, FW_REDIRECT, not sure for any others > > > > I am trying to think of some way to probably do this from ingress instead > since some people actually want that overwrite. ok :) But then you have to add ipchains support for tc in addition to the iptables' one. My wish was to have only the needed bugfixes :) > cheers, > jamal Regards -- Julian Anastasov From shadur@systemec.nl Fri Jul 12 13:56:23 2002 From: shadur@systemec.nl (Rens Houben) Date: 12 Jul 2002 14:56:23 +0200 Subject: [LARTC] [slightly offtopic] synchronizing servers Message-ID: <1026478583.13930.4.camel@hiryuu> --=-qPfrL1GUrb59iuluidF3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I know this question is probably partly outside the scope of this mailing list, but when you're using a backup server with automatic failover, what is the recommended method to ensure that its configuration is periodically (or automatically) synchronized to the master server it has to be the backup for?=20 Are there any tools that help automate this, or am I best off bashing up a set of shell scripts? --=20 Rens Houben | opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP public key at http://suzaku.systemec.nl/shadur.key.asc -- new Dec 12 2001 --=-qPfrL1GUrb59iuluidF3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9LtH3R5T92/AjF/gRAqm5AJwKd+ErKC3ImkVYHrShuEYVRYb/PwCfQbkB YPAnarO/+wjH4q/64GtX5f8= =Lpwy -----END PGP SIGNATURE----- --=-qPfrL1GUrb59iuluidF3-- From kaber@trash.net Fri Jul 12 17:41:04 2002 From: kaber@trash.net (Patrick McHardy) Date: Fri, 12 Jul 2002 18:41:04 +0200 Subject: [LARTC] IMQ crash dump References: <20020712122324.GT27253@blackhole.adamant.ua> Message-ID: <3D2F06A0.6070001@trash.net> Hi Alexander, Alexander Trotsai wrote: >Hi > >I try setup imq pseudo device for shaping >I'm work such script >#!/bin/sh > >TC=/sbin/tc > >/sbin/modprobe imq numdevs=1 >/sbin/ip link set imq0 up >$TC qdisc add dev imq0 handle 1: root htb default 1 >$TC class add dev imq0 parent 1: classid 1:1 htb rate 10mbit ># client1 tunnel tunnel >$TC class add dev imq0 parent 1: classid 1:2 htb rate 256kbit >$TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src 10.255.255.40/30 flowid 1:2 >$TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src 10.255.255.52/30 flowid 1:2 ># client2 >$TC class add dev imq0 parent 1: classid 1:3 htb rate 128kbit >$TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src x.x.x.x/30 flowid 1:3 ># client3 >$TC class add dev imq0 parent 1: classid 1:4 htb rate 64kbit >$TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src x.x.x.x/30 flowid 1:4 ># client4 >$TC class add dev imq0 parent 1: classid 1:5 htb rate 64kbit ceil 768kbit >$TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 match ip src x.x.x.x/30 flowid 1:5 > ># send to intarface all from eth0.9 (clients) >/sbin/iptables -t mangle -A PREROUTING -i eth0.9 -j IMQ > >All patches I get from http://luxik.cdi.cz/~patrick/imq/ >iptables and kernel modules compiled and loaded successfully >But after run last line >/sbin/iptables -t mangle -A PREROUTING -i eth0.9 -j IMQ >I got kernel crush and register stack >I can't save it because kernel frezze > Thats bad, i can't really help you without at least the registers and the corresponding symbols ... You could try two things: use serial console to capture the output or use kdb to obtain a backtrace and the registers after it crashed. kdb requires recompiling the kernel, but if you are used to using debuggers it can give you alot more information. > > >O, my kernel is >Linux watcher 2.4.19-pre8-ac5 #2 Wed Jul 10 10:08:55 EEST 2002 i686 unknown > >May be I do something wrong or any other ideas? > Hmm there's not much to do wrong, everything seems to be ok .... seems to be imq's fault. If you send me your config (off-list please) i can compile a kernel with it and try it myself .. Bye, Patrick From szabszi@goodwill.hu Fri Jul 12 21:45:58 2002 From: szabszi@goodwill.hu (=?iso-8859-2?Q?G=E9czi?= Szabolcs) Date: Fri, 12 Jul 2002 22:45:58 +0200 Subject: [LARTC] 3 interfaces in one linux box Message-ID: <20020712224558.B11384@goodwill.hu> Hello, first of all apologize for my bad english. the facts : +-------+ leased line--------- eth0| Linux | | box |-eth1------subnet/switch ---clients, servers cablenetwork ------- eth2+-------+ The eth0 interface has 5 aliased ip addresses which portforwarded to servers into subnet. The eth2 interface has 1 ip address. The eth1 interface used for subnet. The linux box masquerades with ipchains (2.2.19 kernel). My goal: I would like to route the outgoing packets (www, mail from clients) on my cablenetwork line, and the incoming packets for servers (dns etc in subnet) should come on the leased line. On the leased line should work the ip aliasing and the portforwarding. Any idea ? -- Géczi Szabolcs GPG: http://www.goodwill.hu/~szabszi/szabszi.asc Fingerprint: B36C 150C C316 5A15 DB5F 183A 303B 5AEB 36C2 3162 From ahu@ds9a.nl Fri Jul 12 21:55:25 2002 From: ahu@ds9a.nl (bert hubert) Date: Fri, 12 Jul 2002 22:55:25 +0200 Subject: [LARTC] Re: 3 interfaces in one linux box In-Reply-To: <20020712224558.B11384@goodwill.hu> References: <20020712224558.B11384@goodwill.hu> Message-ID: <20020712205525.GA28862@outpost.ds9a.nl> On Fri, Jul 12, 2002 at 10:45:58PM +0200, G?czi Szabolcs wrote: > Hello, > > first of all apologize for my bad english. No problem. > the facts : > +-------+ > leased line------- eth0| Linux | > | box |-eth1------subnet/switch ---clients, servers > cablenetwork ----- eth2+-------+ > > > The eth0 interface has 5 aliased ip addresses which portforwarded to > servers into subnet. Ok. How is this forwarding performed? ipchains? rinetd? > The eth2 interface has 1 ip address. > The eth1 interface used for subnet. > The linux box masquerades with ipchains (2.2.19 kernel). The problems are: * Making sure that the default gateway is the cablenet * Except for sessions that went to the 5 aliased ip addresses on eth0, which should have eth0 as their default gateway I think this will be pretty easy with policy routing. echo 200 leased >> /etc/iproute2/rt_tables ip rule add from alias.1.ip.address table leased ip rule add from alias.2.ip.address table leased ip rule add from alias.3.ip.address table leased ip rule add from alias.4.ip.address table leased ip rule add from alias.5.ip.address table leased ip route add default via leased.router.ip dev eth0 table leased However, it *is* possible that this interferes with the aliases. Try this and let us know! See also http://lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From cheako911@yahoo.com Sat Jul 13 00:38:46 2002 From: cheako911@yahoo.com (Mike Mestnik) Date: Fri, 12 Jul 2002 16:38:46 -0700 (PDT) Subject: [LARTC] htb+sfq not being fair, while other methods have better results. Message-ID: <20020712233846.52253.qmail@web11907.mail.yahoo.com> --0-1696835571-1026517126=:51213 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm running at 290Kbps and I have a cable modem(i'v gotten almost (1.54 * 3)Mbps down). When I use htb3.6-020525 I get vary sparatic changes(in speed) on my 3 to 7 uploads. With 7 uploads I should get about 4.5KBits/s, instead I get some much grater and some much less. I'm using sfq perterb 10. I'v got a complex setup (View Attachment). The traffic going to handel 43 is what is not shapping correctly, with no other traffic. When I tell the app (gtk-gnutella 3.x+my TOS patch) to shape the traffic it dose a better job(self reporting). Thats where I got the 4.5KBits/s mentioned above, all 7 uploads just solid at 4.xKBits/s Also there is other data going through that qdisc, I don't see this being a problem thought. See I continually get SIN packets(all connections accepted but the app) then there is a read, if it reads an HTTP header OR a gnutella header, it drops saying no open connection(In both cases the connection get's dropped). This data should be quite small and NEEDS to be ignored(as background noise), it should be tolerable! My first thought is that the drops on the backbone causes there to be A need for a burst of bandwidth(for the retransmit), is this what the burst setting is for? I get this idea from MRTG reporting a SOLID line at the htb shaped max. While using the app I get a wave form. Please cc me in any reply. Working Hard on this Mike __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --0-1696835571-1026517126=:51213 Content-Type: application/x-sh; name="qdisc.sh" Content-Transfer-Encoding: base64 Content-Description: qdisc.sh Content-Disposition: attachment; filename="qdisc.sh" IyEvYmluL3NoCgp0YyBxZGlzYyBkZWwgZGV2IGV0aDAgcm9vdCA+IC9kZXYv bnVsbCAyPiYxCgojIFRvdGFsIEJhbmR3aWR0aCBMaW1pdGVyLiAoMTApCnRj IHFkaXNjIGFkZCBkZXYgZXRoMCByb290IGhhbmRsZSAxMDogaHRiIGRlZmF1 bHQgMQp0YyBjbGFzcyBhZGQgZGV2IGV0aDAgcGFyZW50IDEwOiBjbGFzc2lk IDEwOjEgaHRiIHJhdGUgMjgwS2JpdCBcCglidXJzdCAxSwp7ICMgVGhpcyBp cyBtdXRjaCBsaWtlIHRoZSBkZWZhdWx0IHFkaXNjLCBleGVwdCAyIG1vcmUg YmFuZHMgdGhlIGZpcnN0Jmxhc3QKICAgdGMgcWRpc2MgYWRkIGRldiBldGgw IHBhcmVudCAxMDoxIGhhbmRsZSAyMTogcHJpbyBiYW5kcyA1IFwKCXByaW9t YXAgMiAzIDMgMyAyIDMgMSAxIDIgMiAyIDIgMiAyIDIgMgogICB7ICMgU21h bGwgcGFja2V0cywgbm90IG9uIHBvcnQgODA4MC4gKDMxKQogICAgICB0YyBm aWx0ZXIgYWRkIGRldiBldGgwIHBhcmVudCAyMTogcHJpbyAxNSBwcm90b2Nv bCBpcCB1MzIgXAogICAJCW1hdGNoIGlwIHByb3RvY29sIDYgMHhmZiBcCiAg IAkJbWF0Y2ggdTggMHgwNSAweDBmIGF0IDAgXAogICAJCW1hdGNoIHUxNiAw eDAwMDAgMHhmZmMwIGF0IDIgXAogICAJCW1hdGNoIHU4IDB4MTAgMHhmZiBh dCAzMyBcCiAgIAkJZmxvd2lkIDoxCiAgICAgIHRjIHFkaXNjIGFkZCBkZXYg ZXRoMCBwYXJlbnQgMjE6MSBoYW5kbGUgMzE6IHBmaWZvIGxpbWl0IDUwMAog ICB9CiAgIHsgIyBUSEUgMyBERUZBVUxUIExJTlVYIEJBTkRTLiAoMzIsMzMs MzQpCiAgICAgIHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBwYXJlbnQgMjE6MiBo YW5kbGUgMzI6IHNmcSBwZXJ0dXJiIDYwCiAgICAgIHRjIHFkaXNjIGFkZCBk ZXYgZXRoMCBwYXJlbnQgMjE6MyBoYW5kbGUgMzM6IHNmcSBwZXJ0dXJiIDYw CiAgICAgIHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBwYXJlbnQgMjE6NCBoYW5k bGUgMzQ6IHNmcSBwZXJ0dXJiIDYwCiAgIH0KICAgeyAjIDR0aCBiYW5kIGZv ciBwb3J0cyA4MDgwLDYzNDYuICgzNSkKICAgICAgdGMgZmlsdGVyIGFkZCBk ZXYgZXRoMCBwYXJlbnQgMjE6IHByaW8gMTAgcHJvdG9jb2wgaXAgdTMyIFwK CQltYXRjaCBpcCBzcG9ydCA4MDgwIDB4ZmZmZiBcCgkJZmxvd2lkIDo1CiAg ICAgIHRjIGZpbHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IDIxOiBwcmlvIDEw IHByb3RvY29sIGlwIHUzMiBcCgkJbWF0Y2ggaXAgc3BvcnQgNjM0NiAweGZm ZmYgXAoJCWZsb3dpZCA6NQogICAgICB0YyBxZGlzYyBhZGQgZGV2IGV0aDAg cGFyZW50IDIxOjUgaGFuZGxlIDM1OiBwcmlvIGJhbmRzIDMgXAoJCXByaW9t YXAgMSAyIDIgMiAxIDIgMSAxIDEgMSAxIDEgMSAxIDEgMQogICAgICB7ICMg U21hbGwgcGFja2V0cy4gKDQxKQoJIHRjIGZpbHRlciBhZGQgZGV2IGV0aDAg cGFyZW50IDM1OiBwcmlvIDIwIHByb3RvY29sIGlwIHUzMiBcCgkJbWF0Y2gg aXAgcHJvdG9jb2wgNiAweGZmIFwKCQltYXRjaCB1OCAweDA1IDB4MGYgYXQg MCBcCgkJbWF0Y2ggdTE2IDB4MDAwMCAweGZmYzAgYXQgMiBcCgkJbWF0Y2gg dTggMHgxMCAweGZmIGF0IDMzIFwKCQlmbG93aWQgOjEKCSB0YyBxZGlzYyBh ZGQgZGV2IGV0aDAgcGFyZW50IDM1OjEgaGFuZGxlIDQxOiBwZmlmbyBsaW1p dCA1MDAKICAgICAgfQogICAgICB7ICMgR251dGVsbGEgRGF0YS4gKDQyKQoJ IHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBwYXJlbnQgMzU6MiBoYW5kbGUgNDI6 IGh0YiByMnEgMSBkZWZhdWx0IDEKCSB0YyBjbGFzcyBhZGQgZGV2IGV0aDAg cGFyZW50IDQyOiBjbGFzc2lkIDQyOjEgaHRiIHJhdGUgNTBLYml0IFwKCQli dXJzdCAxSwoJIHRjIGNsYXNzIGFkZCBkZXYgZXRoMCBwYXJlbnQgNDI6IGNs YXNzaWQgNDI6MiBodGIgcmF0ZSA1MEtiaXQgXAoJCWJ1cnN0IDFLCgkgeyAj IEdudXRlbGxhIERhdGEgb24gT3ZlcnJ1bi4gKDUxKQoJICAgIHRjIGZpbHRl ciBhZGQgZGV2IGV0aDAgcGFyZW50IDQyOiBwcmlvIDEwIHByb3RvY29sIGlw IHUzMiBcCgkJbWF0Y2ggaXAgc3BvcnQgODA4MCAweGZmZmYgXAoJCWZsb3dp ZCA6MQoJICAgIHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBwYXJlbnQgNDI6MSBo YW5kbGUgNTE6IHNmcSBwZXJ0dXJiIDMwCgkgfQoJIHsgIyBHbnV0ZWxsYSBE YXRhIG9uIEZpbGJlcnQuICg1MikKCSAgICB0YyBmaWx0ZXIgYWRkIGRldiBl dGgwIHBhcmVudCA0MjogcHJpbyAxMCBwcm90b2NvbCBpcCB1MzIgXAoJCW1h dGNoIGlwIHNwb3J0IDYzNDYgMHhmZmZmIFwKCQlmbG93aWQgOjIKCSAgICB0 YyBxZGlzYyBhZGQgZGV2IGV0aDAgcGFyZW50IDQyOjIgaGFuZGxlIDUyOiBz ZnEgcGVydHVyYiAzMAoJIH0KICAgICAgfQogICAgICB7ICMgSFRUUCBEYXRh LiAoNDMpCiAgICAgICAgIHRjIHFkaXNjIGFkZCBkZXYgZXRoMCBwYXJlbnQg MzU6MyBoYW5kbGUgNDM6IHNmcSBwZXJ0dXJiIDEwCiAgICAgIH0KICAgfQp9 CgojIDIwOS45OC45OC45OCBNQVg6MTQyCiMgMTI4LjEwMS4xMDEuMTAxIE1B WDo1NwojMjg0LzYgOikKCiMgMjA5Ljk4Ljk4Ljk4IDI0NSEhIQojIDEyOC4x MDEuMTAxLjEwMSAyMTUhISEKIzI4NS82IDooCgp7ICMgSW5ncmVzcyBHYXJi YWdlLgojdGMgcWRpc2MgZGVsIGRldiBldGgwIGluZ3Jlc3MgcGZpZm8KI3Rj IHFkaXNjIGFkZCBkZXYgZXRoMCBoYW5kbGUgZmZmZjogaW5ncmVzcyBwZmlm byBsaW1pdCA1MDAKI3RjIGZpbHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IGZm ZmY6IHByb3RvY29sIGlwIHByaW8gMTAgdTMyIG1hdGNoIGlwIHNyYyBcCiMg ICAwLjAuMC4wLzAgcG9saWNlIHJhdGUgODIwS2JpdCBidXJzdCA4MGtiaXQg ZHJvcAp0cnVlCn0KCmV4aXQgMAoKI3RjIGZpbHRlciBhZGQgZGV2IGV0aDAg cGFyZW50IDE6IHByZWYgMTAgcHJvdG9jb2wgaXAgdTMyIFwKIwltYXRjaCBp cCBwcm90b2NvbCA2IDB4ZmYgXAojCW1hdGNoIHU4IDB4MDUgMHgwZiBhdCAw IFwKIwltYXRjaCB1MTYgMHgwMDAwIDB4ZmZjMCBhdCAyIFwKIwltYXRjaCB1 OCAweDEwIDB4ZmYgYXQgMzMgXAojCXBvbGljZSByYXRlIDEwS2JpdCBidXJz dCA2S2JpdCBtdHUgOUsgcmVjbGFzc2lmeSBmbG93aWQgMToxCgoKI3RjIGZp bHRlciBhZGQgZGV2IGV0aDAgcGFyZW50IDE6IHByZWYgMzAgcHJvdG9jb2wg aXAgdTMyIFwKIwltYXRjaCBpcCBwcm90b2NvbCA2IDB4ZmYgXAojCW1hdGNo IHU4IDB4MDUgMHgwZiBhdCAwIFwKIwltYXRjaCB1MTYgMHgwMDAwIDB4ZmZj MCBhdCAyIFwKIwltYXRjaCB1OCAweDEwIDB4ZmYgYXQgMzMgXAojCW1hdGNo IGlwIHNwb3J0IDgwODAgMHhmZmZmIFwKIwlwb2xpY2UgcmF0ZSAxMGtiaXQg YnVyc3QgNktiaXQgbXR1IDlLIGNvbnRpbnVlIGZsb3dpZCAxOjQK --0-1696835571-1026517126=:51213-- From chevalier00@hotmail.com Sat Jul 13 16:17:46 2002 From: chevalier00@hotmail.com (Zein Wali) Date: Sat, 13 Jul 2002 18:17:46 +0300 Subject: [LARTC] Advanced routing (Tc filter) Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C22A99.96CBD9A0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Greetings, =20 I am working in a project , and we are concerned about usin Traffic = Conrol tool in iproute2 package, but unfortunately we are facing some = problems using u32 filters to match the ip protocol. Frankly we used: # tc filter add dev eth0 parent 1:0 protocol ip pref 2 u32 match ip = protocol 1 0xff classid 1:4 ( to match icmp protocol ) and then we tried to use # tc filter add dev eth0 parent 1:0 protocol ip pref 2 u32 match u32 00010000 00ff0000 at 8 flowid 1:4 (to match icmp too) and it also failed so we need your help URGENTLY PLEASE !! Thanks a lot and best regards ------=_NextPart_000_0073_01C22A99.96CBD9A0 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Greetings,
 
I am working in a project , and we are = concerned=20 about usin Traffic Conrol tool in iproute2 package, but = unfortunately we=20 are facing some problems using u32 filters to match the ip=20 protocol.
 Frankly we used:

 # tc filter add dev eth0 parent 1:0 protocol ip pref 2 = u32 match=20 ip protocol
 1 0xff classid 1:4 ( to match icmp protocol = )
 and then we tried to use
 # tc filter add dev eth0 = parent 1:0=20 protocol ip pref 2 u32 match u32
 00010000 00ff0000 at 8 flowid = 1:4 (to=20 match icmp too)
 and it also failed
 so we need your help URGENTLY PLEASE !!
 Thanks a lot = and=20 best regards
------=_NextPart_000_0073_01C22A99.96CBD9A0-- From raptor@unacs.bg Sat Jul 13 20:05:25 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Sat, 13 Jul 2002 22:05:25 +0300 Subject: [LARTC] tcng questions ? Message-ID: <20020713220525.74c5fbfd.raptor@unacs.bg> - Does tcng support HTB ? syntax ? - what is the difference between "if" and "on" ? I'm reading the docs but can get it right ! "if" uses bool expressions and "on" is using only "u32", correct ?! what more? - how can I tell tcng to use iptables for classifying and what is the syntax for it ? if I want all packets that are not classified to be dropped what i have to do, is this correct : dev eth0 { class (1) if ....; class (2) if ....; class (3) drop if 1; } thanx alot ===== iVAN raptor@unacs.bg From raptor@unacs.bg Sat Jul 13 20:22:04 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Sat, 13 Jul 2002 22:22:04 +0300 Subject: [LARTC] more tcng questions ? Message-ID: <20020713222204.0ded71b7.raptor@unacs.bg> hi me again I have also these questions : - What are meters used for ? I see they are implemeted using policers ( i cant understand them too, as read in the lartc howto they are used on ingress to block exeeding traffic for example.) ? - How ppl are counting traffic and later drawing it with mrtg or rdd or "?" ... In the past I was parsing the output of "tc class show" with perl script but it seem a liitle clumsy doing it this way, isnt there more direct/better way ? thanx ===== iVAN raptor@unacs.bg From wa@almesberger.net Sun Jul 14 01:39:23 2002 From: wa@almesberger.net (Werner Almesberger) Date: Sat, 13 Jul 2002 21:39:23 -0300 Subject: [LARTC] tcng questions ? In-Reply-To: <20020713220525.74c5fbfd.raptor@unacs.bg>; from raptor@unacs.bg on Sat, Jul 13, 2002 at 10:05:25PM +0300 References: <20020713220525.74c5fbfd.raptor@unacs.bg> Message-ID: <20020713213922.W1424@almesberger.net> raptor@unacs.bg wrote: > - Does tcng support HTB ? syntax ? Not yet. Someone's working on implementing support for it, so I hope to have it in the not too distant future. > - what is the difference between "if" and "on" ? "on" gives direct access to the filters of Linux traffic control, while "if" provides a more abstract language. I'm reading the docs but can get it right ! > "if" uses bool expressions and "on" is using only "u32", correct ?! Half of it ;-) "on" supports all filters except u32. "if" uses u32 to do its work. > what more? Eventually, I plan to phase out "on". If you look at the documentation, the elements in "The tcng language" are here to stay, while the ones in "Under the hood" may change, and the ones in "Historical constructs" should eventually disappear. > - how can I tell tcng to use iptables for classifying and what is the > syntax for it ? You'll have to use the "fw" classifier. tcng doesn't touch iptables directly, so you'd have to set up that classification separately. For static classification, "if" is probably more convenient to use than a mixture of iptables and tcng. > if I want all packets that are not classified to be dropped what i have to do, is this correct : > > dev eth0 { > class (1) if ....; > class (2) if ....; > class (3) drop if 1; > } It's either dev eth0 { name_of_qdisc { /* except if that qdisc is prio and your kernel isn't very very recent */ class (1) if ...; class (2) if ...; drop if 1; } } Or, better dev eth0 { egress { class (<$c1>) if ...; class (<$c2>) if ...; drop if 1; name_of_qdisc { $c1 = class (1); $c2 = class (1); } } } The second form gives you a better separation of classification and queuing, and you also don't have to worry about drop not working (in the case of "prio"). As a disadvantage, the second form adds an indirection through "dsmark" and "tcindex". - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From poltorak@df.ru Sun Jul 14 01:40:01 2002 From: poltorak@df.ru (Poltorak Serguei) Date: Sun, 14 Jul 2002 04:40:01 +0400 (MSD) Subject: [LARTC] routing broadcast messages In-Reply-To: <3D2C2BAF.6020106@nbase.co.il> Message-ID: Hello. this is Kuznetsov's point of view of 1997 :) I think it might change. Why not to implement this feature as optional thing, like syn cookies, that you are to enable. Sometimes this is a security hole, but sometimes - not. I need this to do a tunnel between two networks with windoze inside. I don't want to set up a wins or something else, it's easyer to let broadcast packets traverse through my tunnel, that need directed broadcast routing. I know, it's a little bit stupid to support buggy software like netbios, but sometimes it's worth... PoltoS/ ;Hello All, ;What your are trying to do is called "directed broadcast", and the linux ;networking gods believe it is evil (i.e. a security hole) and should not ;be implemented by routers. See ;http://www.uwsg.iu.edu/hypermail/linux/net/9707.3/0030.html for example. ; Eran. ;Poltorak Serguei wrote: ;> Hello ;> ;> but packets are going To their subnetwork. then m.n.o.w sends packet to ;> a.b.c.255 gateways other than a.b.c.1 doesn't know that a.b.c.255 is a ;> broadcast. it's only a.b.c.1 (m.n.o.p) who discards the packet ;> ;> may be I should redraw my pic. ;> a.b.c.0/24,brd+ -----[ a.b.c.1, m.n.o.p ]-----m.n.o.w ;> <-------pings are going in that direction ;> ;> So, packets are going TO their subnet. ;> ;> Any idea??? ;> ;> thanks, ;> PoltoS/ ;> ;> On Wed, 10 Jul 2002, bert hubert wrote: ;> ;> ;On Wed, Jul 10, 2002 at 04:35:16AM +0400, Poltorak Serguei wrote: ;> ;> Hello. ;> ;> ;> ;> I would like to route broadcast messages. ;> ;> For now, if I ping a.b.c.255 from m.n.o.w the packet is passing through ;> ;> each router, except the last, a.b.c.1 (m.n.o.p, other "external" address) ;> ;> and only he replys to that packet, but not from a.b.c.1, he does it from ;> ;> m.n.o.p address (logic, it's the address of the output interface). ;> ; ;> ;Broadcast messages don't leave their subnet. If you want that, you don't ;> ;need a router but a bridge! ;> ; ;> ;Regards, ;> ; ;> ;bert ;> ; ;> ;-- ;> ;http://www.PowerDNS.com Versatile DNS Software & Services ;> ;http://www.tk the dot in .tk ;> ;http://lartc.org Linux Advanced Routing & Traffic Control HOWTO ;> ; ;> ;> _______________________________________________ ;> LARTC mailing list / LARTC@mailman.ds9a.nl ;> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ;> ; ; ; ;-- ;Eran Mann Direct : 972-4-9936297 ;Senior Software Engineer Fax : 972-4-9890430 ;Optical Access Email : emann@opticalaccess.com ; ; ; ; From stew@michaelishof.de Sun Jul 14 03:01:42 2002 From: stew@michaelishof.de (Arvid =?iso-8859-1?Q?St=FCwe?=) Date: Sun, 14 Jul 2002 04:01:42 +0200 Subject: [LARTC] Shaping per type/size of connection In-Reply-To: <001701c22999$3990c800$0219450a@sandos> References: <20020711231549.GA2962@aurora.michaelishof.etc.tu-bs.de> <001701c22999$3990c800$0219450a@sandos> Message-ID: <20020714020142.GA2390@aurora.michaelishof.etc.tu-bs.de> On Fre, 12 Jul 2002, John Bäckstrand wrote: >> Perhaps a way to slow down any connection that exceeds a certain size >> would solve both problems. Any suggestions, pointers or ideas for a >> better policy are welcome! > >WFQ seems to do just this, but in lack of any real >implementation there is wrr: I just tried it, but it didn't seem to work. At least I could not make out any difference between with or without shaping (same lousy behaviour when one host started too much traffic). The clases DID receive traffic, as far as I can tell from a 'tc -s qdisc'. Perhaps I missed something with the parameters and misconfigured it. :-( But I managed to crash my router several times (kernel panik) when using the wrr-module. cu Arvid -- in bunten Bildern wenig Klarheit, viel Irrtum und ein Fünkchen Wahrheit (Johann Wolfgang v. Goethe) From sandos@home.se Sun Jul 14 11:18:56 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Sun, 14 Jul 2002 12:18:56 +0200 Subject: [LARTC] Shaping per type/size of connection References: <20020711231549.GA2962@aurora.michaelishof.etc.tu-bs.de> <001701c22999$3990c800$0219450a@sandos> <20020714020142.GA2390@aurora.michaelishof.etc.tu-bs.de> Message-ID: <001301c22b1f$dd063fb0$0219450a@sandos> > On Fre, 12 Jul 2002, John Bäckstrand wrote: > >> Perhaps a way to slow down any connection that exceeds a certain size > >> would solve both problems. Any suggestions, pointers or ideas for a > >> better policy are welcome! > > > >WFQ seems to do just this, but in lack of any real > >implementation there is wrr: > > I just tried it, but it didn't seem to work. At least I could not make out > any difference between with or without shaping (same lousy behaviour when > one host started too much traffic). The clases DID receive traffic, as far > as I can tell from a 'tc -s qdisc'. Perhaps I missed something with the > parameters and misconfigured it. :-( > > But I managed to crash my router several times (kernel panik) when using the > wrr-module. Hmm, Ive been using it a day or so with 2 boxes, no problems at all, though I havent been able to test with different amount of traffic if the weighing really works. Which kernel are you using? Did you ask about your problems on the wrr mailinglist? --- John Bäckstrand From devik@cdi.cz Sun Jul 14 12:10:09 2002 From: devik@cdi.cz (Martin Devera) Date: Sun, 14 Jul 2002 13:10:09 +0200 (CEST) Subject: [LARTC] tcng questions ? In-Reply-To: <20020713213922.W1424@almesberger.net> References: <20020713220525.74c5fbfd.raptor@unacs.bg> <20020713213922.W1424@almesberger.net> Message-ID: > raptor@unacs.bg wrote: > > - Does tcng support HTB ? syntax ? > > Not yet. Someone's working on implementing support for it, so I > hope to have it in the not too distant future. Jacob have it done. He sent me some results for checking and althought I have no time to test the latest one it seems to work. devik From piotr@omega.resa.es Sun Jul 14 15:10:25 2002 From: piotr@omega.resa.es (Pedro Larroy) Date: Sun, 14 Jul 2002 16:10:25 +0200 Subject: [LARTC] priomap table In-Reply-To: References: Message-ID: <20020714141024.GA32647@omega> On Sat, Jun 29, 2002 at 01:20:41PM +0200, Vik Heyndrickx wrote: > Hi guys, > > In the current LARTC Howto, at 9.2.1.1. "Parameters & usage", there is the > following table > > > TOS Bits Means Linux Priority Band > ------------------------------------------------------------ > 0x0 0 Normal Service 0 Best Effort 1 > 0x2 1 Minimize Monetary Cost 1 Filler 2 > 0x4 2 Maximize Reliability 0 Best Effort 1 > 0x6 3 mmc+mr 0 Best Effort 1 > 0x8 4 Maximize Throughput 2 Bulk 2 > 0xa 5 mmc+mt 2 Bulk 2 > 0xc 6 mr+mt 2 Bulk 2 > 0xe 7 mmc+mr+mt 2 Bulk 2 > 0x10 8 Minimize Delay 6 Interactive 0 > 0x12 9 mmc+md 6 Interactive 0 > 0x14 10 mr+md 6 Interactive 0 > 0x16 11 mmc+mr+md 6 Interactive 0 > 0x18 12 mt+md 4 Int. Bulk 1 > 0x1a 13 mmc+mt+md 4 Int. Bulk 1 > 0x1c 14 mr+mt+md 4 Int. Bulk 1 > 0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1 > > > And then > > The last column shows the result of the default priomap. > On the commandline, the default priomap looks like this: > 1, 2, 2, 2, 1, 2, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1 > > > Now, why are this "band column" and priomap list different? Is there a > relationship between them, or is it just a mistake, or did I miss something > (also a good possibility)? > > Thanks, Hi, Where do I find the updated doc? The one in www.ldp.org doesn't seem to be. Regards. > > -- > Vik > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| From raptor@unacs.bg Sun Jul 14 20:01:57 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Sun, 14 Jul 2002 22:01:57 +0300 Subject: [LARTC] tcng questions ? In-Reply-To: References: <20020713220525.74c5fbfd.raptor@unacs.bg> <20020713213922.W1424@almesberger.net> Message-ID: <20020714220157.6840b8a1.raptor@unacs.bg> |> raptor@unacs.bg wrote: |> > - Does tcng support HTB ? syntax ? |> |> Not yet. Someone's working on implementing support for it, so I |> hope to have it in the not too distant future. | |Jacob have it done. He sent me some results for checking |and althought I have no time to test the latest one it |seems to work. ]- will u post a note on the list when it is integrated ? and if not soon, a patch to current tcng will be good if possible ? I'm going to build a qos server after 1-2 weeks and want not to use CBQ :") ---- dev eth0 { egress { class (<$c1>) if ...; class (<$c2>) if ...; drop if 1; name_of_qdisc { $c1 = class (1); $c2 = class (1); } } } ]- yep I forgot about the "egress" :"), still learning ..... my last time working with QoS was before a year or so and i was using flat-structure generated by a perl script I've done, but now tcng seems much more powerfull, easy and extendible.. and as I see the lartc-howto is very good (finally good and comprehensive documentation), thank you for the good work.. thanx alot raptor@unacs.bg From raptor@unacs.bg Sun Jul 14 20:07:44 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Sun, 14 Jul 2002 22:07:44 +0300 Subject: [LARTC] drawing qdisc/classes/filter trees ? Message-ID: <20020714220744.639dbb30.raptor@unacs.bg> is there a tool which from the tc and/or tcng file can generate a picture with the tree-like structure ... or posibly a XML file or so ? thanx raptor@unacs.bg From t_bonnedahl@hotmail.com Mon Jul 15 08:44:07 2002 From: t_bonnedahl@hotmail.com (tomas bonnedahl) Date: Mon, 15 Jul 2002 07:44:07 +0000 Subject: [LARTC] filter problem with htb + sfq Message-ID:
hello.
our setup looks like this:
we want to shape the egress traffic with htb and in the leaf, sfq. the problem is that all traffic goes to the default class/qdisc. i removed the default parameter in the root qdisc and instead addad another class that becomes the default class, but still all traffic goes to that class.
 
i have tried to filter root qdisc, "root" class, everything. i have tried filtering the dst ip and also the dport, nothing matches..
 
what could cause this? i will attach my rc.qos script for anyone to see, it's nothing complicated, just a few classes.
 
thank you.
 
- tomas bonnedahl

MSN Hotmail är världens populäraste e-posttjänst. Skaffa dig ett eget konto du ocksċ: Klicka här
From mnh3000@yahoo.com Mon Jul 15 09:03:29 2002 From: mnh3000@yahoo.com (Najibul Huq) Date: Mon, 15 Jul 2002 01:03:29 -0700 (PDT) Subject: [LARTC] Bandwidth limiting on specific IP addresses Message-ID: <20020715080329.89358.qmail@web10704.mail.yahoo.com> Hi, I am just another newcomer to LARTC, and not much experience on linux either. I need to limit usable bandwidth on a per-ip basis, so that my internet bandwith isnt hogged by the network users. I would like to assign a specific bandwith to an IP address, so people doing useless downloads all day dont affect the other users. I really need help on this one (bcos my boss is involved). And when you reply please put my email address (mnh3000@yahoo.com) in your CC field so that I dont have to hunt through the digest to find your helpful suggestions. Thanks a lot, | - - M. N. H ------- --------- __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From devik@cdi.cz Mon Jul 15 09:22:25 2002 From: devik@cdi.cz (devik) Date: Mon, 15 Jul 2002 08:22:25 +0000 (Local time zone must be set--see zic manual page) Subject: [LARTC] tcng questions ? In-Reply-To: <20020714220157.6840b8a1.raptor@unacs.bg> Message-ID: Hi Jacob, please can you post the htb tcng patch to LARTC list ? raptor@unacs.bg would test it in real environment ... thanks, devik On Sun, 14 Jul 2002 raptor@unacs.bg wrote: > > > > > |> raptor@unacs.bg wrote: > |> > - Does tcng support HTB ? syntax ? > |> > |> Not yet. Someone's working on implementing support for it, so I > |> hope to have it in the not too distant future. > | > |Jacob have it done. He sent me some results for checking > |and althought I have no time to test the latest one it > |seems to work. > > ]- will u post a note on the list when it is integrated ? and if not soon, a patch to current tcng will be good if possible ? > I'm going to build a qos server after 1-2 weeks and want not to use CBQ :") > > > ---- > dev eth0 { > egress { > class (<$c1>) if ...; > class (<$c2>) if ...; > drop if 1; > > name_of_qdisc { > $c1 = class (1); > $c2 = class (1); > } > } > } > > > ]- yep I forgot about the "egress" :"), still learning ..... my last time working with QoS was before a year or so and i was using flat-structure generated by a perl script I've done, but now tcng seems much more powerfull, easy and extendible.. and as I see the lartc-howto is very good (finally good and comprehensive documentation), thank you for the good work.. > > > thanx alot > > raptor@unacs.bg > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From t_bonnedahl@hotmail.com Mon Jul 15 10:00:45 2002 From: t_bonnedahl@hotmail.com (tomas bonnedahl) Date: Mon, 15 Jul 2002 09:00:45 +0000 Subject: [LARTC] filter problems with htb + sfq, with script Message-ID:
i forgot to attach the script to my previous message, im sorry for the inconvenience.
 
- tomas bonnedahl

Med MSN Foto kan du enkelt dela med dig av dina fotografier och beställa kopior: Klicka här
From t_bonnedahl@hotmail.com Mon Jul 15 10:01:25 2002 From: t_bonnedahl@hotmail.com (tomas bonnedahl) Date: Mon, 15 Jul 2002 09:01:25 +0000 Subject: [LARTC] filter problems with htb + sfq, with script Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_239b_64d4_51e7 Content-Type: text/html; charset=iso-8859-1
i forgot to attach the script to my previous message, im sorry for the inconvenience.
 
- tomas bonnedahl

Skicka snabbmeddelanden till dina vänner online med MSN Messenger: Klicka här
------=_NextPart_000_239b_64d4_51e7 Content-Type: text/plain; name="rc.qos.txt"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="rc.qos.txt" tc qdisc del root dev eth1 tc qdisc add dev eth1 root handle 1:0 htb default 222 tc class add dev eth1 parent 1:0 classid 1:1 htb rate 4Mbit ceil 4Mbit tc class add dev eth1 parent 1:1 classid 1:10 htb rate 2Mbit ceil 2Mbit tc class add dev eth1 parent 1:1 classid 1:20 htb rate 2Mbit ceil 2Mbit tc class add dev eth1 parent 1:20 classid 1:210 htb rate 512kbit ceil 2Mbit tc class add dev eth1 parent 1:20 classid 1:220 htb rate 1536kbit ceil 1536kbit tc class add dev eth1 parent 1:220 classid 1:221 htb rate 307kbit ceil 1536kbit tc class add dev eth1 parent 1:220 classid 1:222 htb rate 1229kbit ceil 1536kbit tc qdisc add dev eth1 parent 1:210 sfq perturb 10 tc qdisc add dev eth1 parent 1:221 sfq perturb 10 tc qdisc add dev eth1 parent 1:222 sfq perturb 10 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 172.16.1.0/24 flowid 1:10 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 10.47.17.23/32 flowid 1:210 tc filter add dev eth1 protocol ip parent 1:1 prio 1 u32 match ip dst 10.46.23.0/24 flowid 1:221 tc filter add dev eth1 protocol ip parent 1:1 prio 2 u32 match ip dport 0x19 0xffff flowid 1:221 tc filter add dev eth1 protocol ip parent 1:1 prio 2 u32 match ip dport 0x6e 0xffff flowid 1:221 ------=_NextPart_000_239b_64d4_51e7-- From tobias.geiger@web.de Mon Jul 15 14:57:59 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Mon, 15 Jul 2002 15:57:59 +0200 (CEST) Subject: [LARTC] tcng questions ? In-Reply-To: References: <20020714220157.6840b8a1.raptor@unacs.bg> Message-ID: <4791.213.164.67.210.1026741479.squirrel@kaeptnb.d2g.com> > Hi Jacob, > > please can you post the htb tcng patch to LARTC list ? > raptor@unacs.bg would test it in real environment ... I'd like to test tcng with htb, to :) Greetings Tobias From mage@adamant.net Mon Jul 15 15:09:44 2002 From: mage@adamant.net (Alexander Trotsai) Date: Mon, 15 Jul 2002 17:09:44 +0300 Subject: [LARTC] [Q] htb Message-ID: <20020715140944.GE23845@blackhole.adamant.ua> Hi Can I make htb node (class) without rate limit For example limit ip1/len1 to xx kb limit ip2/len2 to yy kb any other traffic - without limit? -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] Big trouble - Your modem doesn't speak English. From devik@cdi.cz Mon Jul 15 18:13:39 2002 From: devik@cdi.cz (Martin Devera) Date: Mon, 15 Jul 2002 19:13:39 +0200 (CEST) Subject: [LARTC] [Q] htb In-Reply-To: <20020715140944.GE23845@blackhole.adamant.ua> References: <20020715140944.GE23845@blackhole.adamant.ua> Message-ID: there is build-in passthru class named X:0 where X is your handle. Simply set "default 0" when creating htb and all unclassified packets will go directly thru. devik On Mon, 15 Jul 2002, Alexander Trotsai wrote: > Hi > > Can I make htb node (class) without rate limit > For example > > limit ip1/len1 to xx kb > limit ip2/len2 to yy kb > any other traffic - without limit? > > -- > Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC > My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] > Big trouble - Your modem doesn't speak English. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From lucky@knup.de Mon Jul 15 20:32:05 2002 From: lucky@knup.de (Lucky) Date: Mon, 15 Jul 2002 21:32:05 +0200 Subject: [LARTC] Routing private and non-private ips Message-ID: <20020715213205.A7872@knup.knup.de> Hi folks! I have a little problem here, probably not related to LAR and surely not to TC, but I don't know somebody else to ask. The scenario is as follows: Router R has two connections to the internet (ippp3, static IP-Address with and a /29er network N1 routed to, and ppp0, dynamic IP-Address), one to the local network N2 (eth0). Currently, R does the following: - masqerades all connections from N2 to the Internet - policy-routes packets originating from connections from ippp3 back to ippp3 - firewalls Now I'd like to give a Host H1 in N2 a local, private IP-Address _and_ a public, non-private IP-Address from our /29-net. How would I do the routing? I tried routing the /29-net through eth0, which lets me ping R to H1, but not vice-versa. The routing from the internet to H1 and vice-versa also didn't work. I allowed nearly everything to and from the /29-net in all of the input, forward and output-chains (I'm currently using Linux 2.2.20). Any help would be really appreciated. Please Cc' me on answers, cause I'm getting the list only in digest-mode. -- Lukas From smohan@vsnl.com Tue Jul 16 08:28:13 2002 From: smohan@vsnl.com (S Mohan) Date: Tue, 16 Jul 2002 12:58:13 +0530 Subject: [LARTC] Tcng error Message-ID: <003301c22c9a$591e7830$6300a8c0@smohan> I downloaded tcng and tried to run ./configure. I got the following error. ---------screen output/ transcript----------- bash-2.05a# ./configure building tcsim: yes /usr/src/linux: no kernel directory bash-2.05a# ---------end transcript---------------------- Does tcng require recompilation of kernel? I'm using RH7.3. Is there an rpm for RH? How do I get this going. All help welcome. TIA Mohan From wa@almesberger.net Tue Jul 16 08:52:00 2002 From: wa@almesberger.net (Werner Almesberger) Date: Tue, 16 Jul 2002 04:52:00 -0300 Subject: [LARTC] Tcng error In-Reply-To: <003301c22c9a$591e7830$6300a8c0@smohan>; from smohan@vsnl.com on Tue, Jul 16, 2002 at 12:58:13PM +0530 References: <003301c22c9a$591e7830$6300a8c0@smohan> Message-ID: <20020716045159.Z1424@almesberger.net> S Mohan wrote: > Does tcng require recompilation of kernel? No, but it needs the kernel and iproute2 source if you want to build tcsim too. If you don't want tcsim, just run ./configure -n If you want tcsim, look at the README for instructions. > I'm using RH7.3. Is there an rpm for RH? I don't know of any, but it would be good if someone who regularly builds RPMs for a reasonably large set of distributions/releases could include tcng (and, of course, let people know). tcng already supports building RPMs: make rpm and make tcsim-rpms - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From grzegorz.skrzypczak@interia.pl Tue Jul 16 10:05:25 2002 From: grzegorz.skrzypczak@interia.pl (Grzegorz Skrzypczak) Date: Tue, 16 Jul 2002 11:05:25 +0200 Subject: [LARTC] Installation of HTB on Slack v8.0 Message-ID: <002f01c22ca7$f26ebf60$1001a8c0@test.pl> This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C22CB8.B0BA5000 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi All, I'm looking for something to give me possibilty to manage the bandwidth = inside my FastEthernet LAN. I found HTB code but I don't know how to = install it on my Slack v.8.0 with kernel version 2.4.18 (without any QoS = functionality compiled in to kernel). Right now my network is running = without any bandwidth limitations. Could any one help me to understand = the idea of HTB's class hierarchy? What external pckeges should I = download and install? Do I really need "iproute2"? How to compile HTB = code (where is the source code to compile?)? Hope for helping me Best regads, Grzegorz "Greg" Skrzypczak ------=_NextPart_000_002C_01C22CB8.B0BA5000 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Hi All,
I'm looking for something to give me possibilty to manage the = bandwidth=20 inside my FastEthernet LAN. I found HTB code but I don't know how = to=20 install it on my Slack v.8.0 with kernel version 2.4.18 (without any QoS = functionality compiled in to kernel). Right now my network is running = without=20 any bandwidth limitations. Could any one help me to understand the idea = of HTB's=20 class hierarchy? What external pckeges should I download and install? Do = I=20 really need "iproute2"? How to compile HTB code (where is the = source code=20 to compile?)?
Hope for helping me
Best regads,
Grzegorz "Greg" Skrzypczak
---------------------------R-E-K-L-A-M-A-------------------------------
Bezplatne czlonkostwo w Klubie Wakacyjnym
Pierwszy wyjazd za cene serwisowo-rezerwacyjna
http://www.klubwakacyjny.pl/klub_rejestracja.html
------=_NextPart_000_002C_01C22CB8.B0BA5000-- From carles@descom.es Tue Jul 16 11:59:40 2002 From: carles@descom.es (Carles Xavier Munyoz =?iso-8859-1?q?Bald=F3?=) Date: Tue, 16 Jul 2002 12:59:40 +0200 Subject: [LARTC] RedHat 7.2/7.3 Message-ID: <200207161259.43378.carles@descom.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, My question is some offtopic. May someone tell me where may I found the kernel patches list for the Red= Hat=20 7.2/7.3 kernel ? Greetings. - --- Carles Xavier Munyoz Bald=F3 carles@descom.es Descom Consulting Telf: +34 965861024 Fax: +34 965861024 http://www.descom.es/ - --- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPTP8nDvYAf7VZNaaEQKtXgCfQ1FElK2sNl58ey7ZZlaQRFThAWIAn1qD xUOeNT1QbRGgZ8Sb5YXWA2vC =3D3kyV -----END PGP SIGNATURE----- From patrizio.nini@grupposistematica.it Tue Jul 16 15:40:39 2002 From: patrizio.nini@grupposistematica.it (Patrizio Nini) Date: Tue, 16 Jul 2002 16:40:39 +0200 Subject: [LARTC] static routes number Message-ID: <01a101c22cd6$c3280ac0$1103a8c0@SISTEMATICA> I'm dealing with loadsharing over multiple interfaces. My goal is setting-up a a load balanced Linux routing over 16 ppp links, splitting the traffic toward one destination over multiple "parallel" ppp connections and using TEQL. I'm going to tune kernel parameters to minimize the problems with packet reordering, but before setting up the expensive testing environment (32 cable modems and the switchboard), I'd like to know which is the max number of configurable static routes (all ones toward the same destination in my case), if an upper bound exists 'cause I didn't find anything about. Thanks in advance Pat From tech@playawireless.com Tue Jul 16 17:18:10 2002 From: tech@playawireless.com (Alfredo Giordano) Date: Tue, 16 Jul 2002 11:18:10 -0500 Subject: [LARTC] Installation of HTB on Slack v8.0 References: <002f01c22ca7$f26ebf60$1001a8c0@test.pl> Message-ID: <007401c22ce4$60ad4910$130ce994@playawireless.com> This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C22CBA.77BEB000 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Try following the following step: 1 Install the kernel source package 2 Read all the Doc about how compile the kernel 3 download the HTB patch code and apply it to your kernel source tree 4 download the patched tc binary and replace your original tc 5 compile the kernel with the QoS and HTB options compiled in the kernel = (not as module) 6 read all the lartc howto you should get trough cheers=20 alfredo ----- Original Message -----=20 From: Grzegorz Skrzypczak=20 To: lartc@mailman.ds9a.nl=20 Sent: Tuesday, July 16, 2002 4:05 AM Subject: [LARTC] Installation of HTB on Slack v8.0 Hi All, I'm looking for something to give me possibilty to manage the = bandwidth inside my FastEthernet LAN. I found HTB code but I don't know = how to install it on my Slack v.8.0 with kernel version 2.4.18 (without = any QoS functionality compiled in to kernel). Right now my network is = running without any bandwidth limitations. Could any one help me to = understand the idea of HTB's class hierarchy? What external pckeges = should I download and install? Do I really need "iproute2"? How to = compile HTB code (where is the source code to compile?)? Hope for helping me Best regads, Grzegorz "Greg" Skrzypczak = ---------------------------R-E-K-L-A-M-A-------------------------------=20 Bezplatne czlonkostwo w Klubie Wakacyjnym=20 Pierwszy wyjazd za cene serwisowo-rezerwacyjna=20 http://www.klubwakacyjny.pl/klub_rejestracja.html=20 =20 ------=_NextPart_000_0071_01C22CBA.77BEB000 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Try following the following = step:
1 Install the kernel source=20 package
2 Read all the Doc about how = compile the=20 kernel
3 download the HTB patch code and = apply it to=20 your kernel source tree
4 download the patched tc binary = and replace=20 your original tc
5 compile the kernel with the QoS = and HTB=20 options compiled in the kernel (not as module)
6 read all the lartc = howto
you should get trough
 
cheers
alfredo
 
----- Original Message -----
From:=20 Grzegorz Skrzypczak
To: lartc@mailman.ds9a.nl
Sent: Tuesday, July 16, 2002 = 4:05=20 AM
Subject: [LARTC] Installation = of HTB on=20 Slack v8.0

Hi All,
I'm looking for something to give me possibilty to manage the = bandwidth=20 inside my FastEthernet LAN. I found HTB code but I don't know how = to=20 install it on my Slack v.8.0 with kernel version 2.4.18 (without any = QoS=20 functionality compiled in to kernel). Right now my network is running = without=20 any bandwidth limitations. Could any one help me to understand the = idea of=20 HTB's class hierarchy? What external pckeges should I download and = install? Do=20 I really need "iproute2"? How to compile HTB code (where is the = source=20 code to compile?)?
Hope for helping me
Best regads,
Grzegorz "Greg" Skrzypczak
---------------------------R-E-K-L-A-M-A----------------------------= ---=20
Bezplatne czlonkostwo w Klubie Wakacyjnym
Pierwszy = wyjazd za=20 cene serwisowo-rezerwacyjna
http://www.klu= bwakacyjny.pl/klub_rejestracja.html=20
------=_NextPart_000_0071_01C22CBA.77BEB000-- From tech@playawireless.com Tue Jul 16 17:20:22 2002 From: tech@playawireless.com (Alfredo Giordano) Date: Tue, 16 Jul 2002 11:20:22 -0500 Subject: [LARTC] Tcng error References: <003301c22c9a$591e7830$6300a8c0@smohan> Message-ID: <007c01c22ce4$af486c80$130ce994@playawireless.com> try installing the kernel-source and the kernel-headers packages ;) Alf ----- Original Message ----- From: "S Mohan" To: Sent: Tuesday, July 16, 2002 2:28 AM Subject: [LARTC] Tcng error > I downloaded tcng and tried to run ./configure. I got the following > error. > ---------screen output/ transcript----------- > bash-2.05a# ./configure > building tcsim: yes > /usr/src/linux: no kernel directory > bash-2.05a# > ---------end transcript---------------------- > > Does tcng require recompilation of kernel? I'm using RH7.3. Is there an > rpm for RH? How do I get this going. All help welcome. TIA > > Mohan > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From mabrown-lartc@securepipe.com Tue Jul 16 19:19:19 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Tue, 16 Jul 2002 13:19:19 -0500 (CDT) Subject: [LARTC] Routing private and non-private ips In-Reply-To: <20020715213205.A7872@knup.knup.de> Message-ID: Lucky, If I understand correctly what you are trying to do, it is simple static network address translation. The following commands should give you static NAT. Choose an IP in your /29 and make it the public IP. Choose an IP in the internal rfc 1918 network and make it the private IP. Now try the following: ip route add nat pu.bl.ic.ip via pr.iv.at.ip ip rule add nat pu.bl.ic.ip from pr.iv.at.ip prio $PRIO ip route flush cache As for the packet filtering, you'll have to make a second set of rules. You'll need to allow the packet from outside to the public IP and you'll need to add a second set of rules to allow the packet from outside to the private IP. Good luck, -Martin On Mon, 15 Jul 2002, Lucky wrote: : Hi folks! : : I have a little problem here, probably not related to LAR and surely not to : TC, but I don't know somebody else to ask. : : The scenario is as follows: : : Router R has two connections to the internet (ippp3, static IP-Address with : and a /29er network N1 routed to, and ppp0, dynamic IP-Address), one to the : local network N2 (eth0). : Currently, R does the following: : : - masqerades all connections from N2 to the Internet : - policy-routes packets originating from connections from ippp3 back to ippp3 : - firewalls : : Now I'd like to give a Host H1 in N2 a local, private IP-Address _and_ a : public, non-private IP-Address from our /29-net. : : How would I do the routing? : I tried routing the /29-net through eth0, which lets me ping R to H1, but not : vice-versa. The routing from the internet to H1 and vice-versa also didn't : work. : I allowed nearly everything to and from the /29-net in all of the input, : forward and output-chains (I'm currently using Linux 2.2.20). : : Any help would be really appreciated. : : Please Cc' me on answers, cause I'm getting the list only in digest-mode. : : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From jacobt@bivio.net Tue Jul 16 23:36:02 2002 From: jacobt@bivio.net (Jacob Teplitsky) Date: Tue, 16 Jul 2002 15:36:02 -0700 Subject: [LARTC] tcng questions ? In-Reply-To: ; from devik@cdi.cz on Mon, Jul 15, 2002 at 08:22:25AM +0000 References: <20020714220157.6840b8a1.raptor@unacs.bg> Message-ID: <20020716153602.A30555@stimpy.networkrobots.com> --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here it is. - Jacob On Mon, Jul 15, 2002 at 08:22:25AM +0000, devik wrote: > Hi Jacob, > > please can you post the htb tcng patch to LARTC list ? > raptor@unacs.bg would test it in real environment ... > > thanks, devik > --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcng_htb.patch" Index: Makefile =================================================================== RCS file: /export/cvsroot/tcng/Makefile,v retrieving revision 1.124 diff -u -r1.124 Makefile --- Makefile 26 May 2002 06:27:52 -0000 1.124 +++ Makefile 6 Jun 2002 01:46:47 -0000 @@ -50,6 +50,7 @@ tcc/sprintf.h tcc/sprintf.c \ tcc/device.h tcc/device.c \ tcc/qdisc.h tcc/qdisc.c tcc/qdisc_common.h tcc/q_ingress.c tcc/q_cbq.c \ + tcc/q_htb.c \ tcc/q_dsmark.c tcc/q_fifo.c tcc/q_gred.c tcc/q_prio.c tcc/q_red.c \ tcc/q_sfq.c tcc/q_tbf.c tcc/csp.c \ tcc/filter.h tcc/filter.c tcc/filter_common.h tcc/f_if.c tcc/f_fw.c \ Index: VERSION =================================================================== RCS file: /export/cvsroot/tcng/VERSION,v retrieving revision 1.127 diff -u -r1.127 VERSION --- VERSION 31 May 2002 12:26:35 -0000 1.127 +++ VERSION 6 Jun 2002 23:15:54 -0000 @@ -1 +1 @@ -8r +8s Index: tcc/Makefile =================================================================== RCS file: /export/cvsroot/tcng/tcc/Makefile,v retrieving revision 1.22 diff -u -r1.22 Makefile --- tcc/Makefile 17 May 2002 04:42:25 -0000 1.22 +++ tcc/Makefile 6 Jun 2002 01:43:29 -0000 @@ -13,6 +13,7 @@ OBJS=lex.yy.o y.tab.o tcc.o util.o error.o var.o data.o param.o device.o \ registry.o u128.o sprintf.o \ qdisc.o q_ingress.o q_cbq.o q_dsmark.o q_fifo.o q_gred.o q_prio.o \ + q_htb.o \ q_red.o q_sfq.o q_tbf.o csp.o \ filter.o f_if.o f_fw.o f_route.o f_rsvp.o f_tcindex.o \ police.o tc.o op.o field.o named.o \ Index: tcc/Parameters =================================================================== RCS file: /export/cvsroot/tcng/tcc/Parameters,v retrieving revision 1.3 diff -u -r1.3 Parameters --- tcc/Parameters 26 Jan 2002 19:31:40 -0000 1.3 +++ tcc/Parameters 27 Jun 2002 19:11:19 -0000 @@ -7,6 +7,8 @@ bandwidth rate bounded flag burst size +cburst size +ceil rate default flag default_index unum dport unum @@ -42,6 +44,7 @@ protocol unum quantum size rate rate +r2q unum set_tc_index flag shift unum skip size Index: tcc/if_u32.c =================================================================== RCS file: /export/cvsroot/tcng/tcc/if_u32.c,v retrieving revision 1.11 diff -u -r1.11 if_u32.c --- tcc/if_u32.c 21 May 2002 06:44:39 -0000 1.11 +++ tcc/if_u32.c 8 Jun 2002 00:17:25 -0000 @@ -941,7 +941,9 @@ tc_pragma(filter->params); for (i = 0; i < 2; i++) { +// to uncover everything if (!i) { + // first time d = data_clone(qdisc->if_expr); d = op_binary(&op_logical_or,d,data_decision(dr_continue,NULL)); } Index: tcc/q_htb.c =================================================================== RCS file: tcc/q_htb.c diff -N tcc/q_htb.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ tcc/q_htb.c 27 Jun 2002 19:42:35 -0000 @@ -0,0 +1,314 @@ +/* + * q_htb.c - Hierachical Token Bucket Queuing qdisc + + * + * Written 2002 by Jacob Teplitsky + * Copyright 2002 Bivio Networks. + */ + + +#include + +#include "tcdefs.h" +#include "util.h" +#include "error.h" +#include "data.h" +#include "param.h" +#include "tree.h" +#include "field.h" +#include "op.h" +#include "tc.h" +#include "ext.h" +#include "filter.h" +#include "qdisc_common.h" +#include "qdisc.h" + + +/* ------------------------------- Checking -------------------------------- */ + + +#define __DEFAULT_PRM(f) f(burst) f(ceil) f(cburst) f(prio) f(quantum) f(rate) +#define __DEFAULT_PRM_REQ(f) f(rate) + +static void htb_check_classes(CLASS **classes,DEFAULT_ARGS,int depth, int *got_default) +{ + CLASS *class; + + if (!*classes) return; + sort_classes(classes); + if (depth == TC_HTB_MAXLEVEL) + lerrorf((*classes)->location, + "can't nest HTB classes deeper than %d levels",TC_HTB_MAXLEVEL); + for (class = *classes; class; class = class->next) { + DEFAULT_DECL_SAVED; + + param_get(class->params,class->location); + DEFAULT_GET; + if (class->number != 0) { + DEFAULT_CHECK(class->location); + } + DEFAULT_SAVE; + if (class->number != 0) { + if (!prm_rate.v) lerror(class->location,"rate must be non-zero"); + } + if (prm_ceil.present && prm_ceil.v < prm_rate.v) + lerrorf(class->location,"\"ceil\" (%lu) > \"rate\" (%lu)", + (unsigned long) prm_ceil.v,(unsigned long) prm_rate.v); + if (prm_prio.present && prm_prio.v > TC_HTB_MAXPRIO) + lerrorf(class->location,"\"prio\" (%lu) > %d", + (unsigned long) prm_prio.v,TC_HTB_MAXPRIO); + if (prm_default.present) { + if (*got_default) { + lerror(class->location, + "more than one class marked as \"default\""); + } + *got_default = 1; + } + + htb_check_classes(&class->child,DEFAULT_PASS_SAVED,depth+1, got_default); + check_qdisc(class->qdisc); + check_filters(class->filters); + } +} + +static void create_root_class(QDISC *qdisc) +{ + CLASS *classes,*root,*class; + int zero = 0; + + if (recurse_class(qdisc->classes,count_class_ids,&zero)) return; + classes = qdisc->classes; + qdisc->classes = NULL; + root = require_class(qdisc,0); + root->child = classes; + for (class = classes; class; class = class->next) + class->parent.class = root; + /* + * Root class inherits all parameters from qdisc, and gets prm_rate from + * prm_bandwidth. + */ +} + +static void check_root_class(QDISC *qdisc) +{ + if (!qdisc->classes || qdisc->classes->next) + lerror(qdisc->classes ? qdisc->classes->location : + qdisc->classes->next->location, + "HTB must have exactly one root class"); + if (qdisc->classes->number) /* hard to trigger :-) */ + lerrorf(qdisc->classes->location, + "HTB root class must have number 0, not %lu\n", + (unsigned long) qdisc->classes->number); + if (qdisc->filters && qdisc->classes->filters) + lerror(qdisc->filters->location,"please specify filters either at HTB " + "qdisc or at root class"); + if (qdisc->classes->filters) { + qdisc->filters = qdisc->classes->filters; + qdisc->classes->filters = NULL; + } +} + + +static void htb_check(QDISC *qdisc) +{ + int got_default = 0; + + curr_id = 1; + (void) recurse_class(qdisc->classes,assign_class_id,qdisc->classes); + create_root_class(qdisc); + param_get(qdisc->params,qdisc->location); + check_root_class(qdisc); /* must be after param_get */ + htb_check_classes(&qdisc->classes,DEFAULT_PASS,0, &got_default); + if (!got_default) { + lerror(qdisc->location, + "htb requires one class to be marked as \"default\""); + } + check_filters(qdisc->filters); +} + + +/* ------------------------ Default classification ------------------------- */ +static CLASS *htb_get_default_class(CLASS *classes) +{ + CLASS *class, *rt; + + if (!classes) return (NULL); + for (class = classes; class; class = class->next) { + param_get(class->params,class->location); + if (prm_default.present) { + return (class); + } + rt = htb_get_default_class(class->child); + if (rt) { + return rt; + } + } + return NULL; +} + +static void htb_use_default(DATA *d,DATA dfl,const CLASS *class) +{ + if (!d->op) { + if (d->type == dt_decision && d->u.decision.result == dr_class && + d->u.decision.class == class) + *d = data_clone(dfl); + return; + } + htb_use_default(&d->op->a,dfl,class); + htb_use_default(&d->op->b,dfl,class); + htb_use_default(&d->op->c,dfl,class); +} + +static void htb_push_defaults(DATA *d,PARAM *params,QDISC *qdisc, + CLASS *classes,CLASS *this_class) +{ + CLASS *class; + + for (class = classes; class; class = class->next) + htb_push_defaults(d,class->params,qdisc,class->child,class); +} + +static void htb_default_class(DATA *d,QDISC *qdisc) +{ + /* + * This is the only place where the root class becomes visible. + * This may confuse external programs quite badly. + */ + CLASS *class; + + class = htb_get_default_class(qdisc->classes); + append_default(d,data_decision(dr_class, class)); +} + + +/* -------------------------------- Dump tc -------------------------------- */ + + + +static void htb_dump_classes_tc(CLASS *classes,DEFAULT_ARGS) +{ + CLASS *class; + + if (!classes) return; + for (class = classes; class; class = class->next) { + DEFAULT_DECL_SAVED; + + param_get(class->params,class->location); + DEFAULT_GET; + DEFAULT_CHECK(class->location); + DEFAULT_SAVE; + tc_pragma(class->params); + tc_class_add(class); + tc_add_rate("rate",prm_rate.v); + if (prm_ceil.present) tc_add_rate("ceil",prm_ceil.v); + if (prm_burst.present) tc_add_size("burst",prm_burst.v); + if (prm_cburst.present) tc_add_size("cburst",prm_cburst.v); + if (prm_prio.present) tc_add_unum("prio",prm_prio.v); + tc_nl(); + dump_qdisc(class->qdisc); + htb_dump_classes_tc(class->child,DEFAULT_PASS_SAVED); + dump_filters(class->filters); + } +} + + +static void htb_dump_tc(QDISC *qdisc) +{ + DEFAULT_DECL; + CLASS *class; + + tc_pragma(qdisc->params); + tc_qdisc_add(qdisc); + class = htb_get_default_class(qdisc->classes); + param_get(qdisc->params,qdisc->location); + tc_add_unum("default", class->number); + if (prm_r2q.present) tc_add_unum("r2q",prm_r2q.v); + DEFAULT_SET; + + param_get(qdisc->classes->params,qdisc->classes->location); + DEFAULT_GET; + tc_nl(); + htb_dump_classes_tc(qdisc->classes->child,DEFAULT_PASS); + dump_qdisc(qdisc->classes->qdisc); + dump_filters(qdisc->filters); +} + + +/* ----------------------------- Dump external ----------------------------- */ + + +static void htb_dump_classes_ext(FILE *file,CLASS *classes) +{ + const PARAM_DSC *hide[] = { + NULL + }; + const CLASS *class; + + for (class = classes; class; class = class->next) { + param_push(); + class_param_load(class); + ext_dump_class(file,class,hide,NULL); + htb_dump_classes_ext(file,class->child); + param_pop(); + } +} + + +static void htb_dump_ext(FILE *file,QDISC *qdisc) +{ + const PARAM_DSC *hide[] = { + NULL + }; + + qdisc_param_load(qdisc); + ext_dump_qdisc(file,qdisc,hide,NULL); + htb_dump_classes_ext(file,qdisc->classes); +} + + +/* ------------------------------ Descriptors ------------------------------ */ + + +static const PARAM_DSC *htb_qdisc_req[] = { + NULL +}; + +static const PARAM_DSC *htb_qdisc_opt[] = { + &prm_pragma, /* list */ + &prm_r2q, + DEFAULT_LIST /* NB: no trailing comma */ + NULL +}; + +static const PARAM_DSC *htb_class_req[] = { + NULL +}; + +static const PARAM_DSC *htb_class_opt[] = { + &prm_default, /* flag */ + &prm_pragma, /* list */ + DEFAULT_LIST /* NB: no trailing comma */ + NULL +}; + +static PARAM_DEF htb_qdisc = { + .required = htb_qdisc_req, + .optional = htb_qdisc_opt, +}; + +static PARAM_DEF htb_class = { + .required = htb_class_req, + .optional = htb_class_opt, +}; + +QDISC_DSC htb_dsc = { + .name = "htb", + .flags = QDISC_HAS_CLASSES | QDISC_HAS_FILTERS | QDISC_HAS_DEFAULT | + QDISC_CHILD_QDISCS, + .qdisc_param = &htb_qdisc, + .class_param = &htb_class, + .check = &htb_check, + .default_class = &htb_default_class, + .dump_tc = &htb_dump_tc, + .dump_ext = &htb_dump_ext, +}; Index: tcc/qdisc.h =================================================================== RCS file: /export/cvsroot/tcng/tcc/qdisc.h,v retrieving revision 1.4 diff -u -r1.4 qdisc.h --- tcc/qdisc.h 12 Mar 2002 13:46:41 -0000 1.4 +++ tcc/qdisc.h 6 Jun 2002 01:42:25 -0000 @@ -23,6 +23,7 @@ extern QDISC_DSC red_dsc; extern QDISC_DSC sfq_dsc; extern QDISC_DSC tbf_dsc; +extern QDISC_DSC htb_dsc; void assign_qdisc_ids(QDISC *root); Index: tcc/tcdefs.h =================================================================== RCS file: /export/cvsroot/tcng/tcc/tcdefs.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 tcdefs.h --- tcc/tcdefs.h 16 Jul 2001 09:26:06 -0000 1.1.1.1 +++ tcc/tcdefs.h 6 Jun 2002 03:46:09 -0000 @@ -15,6 +15,8 @@ #ifndef TCDEFS_H #define TCDEFS_H +#define TC_HTB_MAXLEVEL 8 +#define TC_HTB_MAXPRIO 8 /* From linux/include/linux/pkt_sched.h */ #define TC_CBQ_MAXLEVEL 8 Index: tcc/tcng.l =================================================================== RCS file: /export/cvsroot/tcng/tcc/tcng.l,v retrieving revision 1.24 diff -u -r1.24 tcng.l --- tcc/tcng.l 17 May 2002 04:42:25 -0000 1.24 +++ tcc/tcng.l 27 Jun 2002 19:15:57 -0000 @@ -92,6 +92,8 @@ bands return TOK_BANDS; bounded return TOK_BOUNDED; burst return TOK_BURST; +cburst return TOK_CBURST; +ceil return TOK_CEIL; default return TOK_DEFAULT; default_index return TOK_DEFAULT_INDEX; dport return TOK_DPORT; @@ -104,6 +106,7 @@ fromif return TOK_FROMIF; grio return TOK_GRIO; hash return TOK_HASH; +htb return TOK_HTB; isolated return TOK_ISOLATED; indices return TOK_INDICES; ipproto return TOK_IPPROTO; @@ -125,6 +128,7 @@ protocol return TOK_PROTOCOL; quantum return TOK_QUANTUM; rate return TOK_RATE; +r2q return TOK_R2Q; set_tc_index return TOK_SET_TC_INDEX; shift return TOK_SHIFT; skip return TOK_SKIP; Index: tcc/tcng.y =================================================================== RCS file: /export/cvsroot/tcng/tcc/tcng.y,v retrieving revision 1.52 diff -u -r1.52 tcng.y --- tcc/tcng.y 17 May 2002 04:42:25 -0000 1.52 +++ tcc/tcng.y 27 Jun 2002 19:44:14 -0000 @@ -265,11 +265,11 @@ %token TOK_PASS TOK_RECLASSIFY TOK_CONTINUE TOK_FIELD TOK_TAG %token TOK_FIELD_ROOT %token TOK_CONFORM TOK_COUNT TOK_PRECOND TOK_DROP TOK_IF_ANCHOR -%token TOK_CBQ TOK_DSMARK TOK_FIFO TOK_GRED TOK_PRIO TOK_RED TOK_SFQ +%token TOK_CBQ TOK_DSMARK TOK_FIFO TOK_GRED TOK_PRIO TOK_RED TOK_SFQ TOK_HTB %token TOK_TBF TOK_INGRESS TOK_EGRESS %token TOK_FW TOK_ROUTE TOK_RSVP TOK_TCINDEX %token TOK_AH TOK_ALLOT TOK_AVPKT TOK_BANDS TOK_BANDWIDTH TOK_BOUNDED -%token TOK_BURST +%token TOK_BURST TOK_CBURST TOK_CEIL %token TOK_DEFAULT TOK_DEFAULT_INDEX TOK_DPORT TOK_DST %token TOK_ECN TOK_ESP TOK_EWMA TOK_FALL_THROUGH %token TOK_FROM TOK_FROMIF TOK_GRIO TOK_HASH @@ -1366,6 +1366,10 @@ { $$ = &tbf_dsc; } + | TOK_HTB + { + $$ = &htb_dsc; + } ; opt_qdisc_or_class_body: @@ -1564,6 +1568,14 @@ $$ = param_make(&prm_burst,$2); /* check against expected psched_mtu */ } + | TOK_CBURST constant_expression + { + $$ = param_make(&prm_cburst,$2); + } + | TOK_CEIL constant_expression + { + $$ = param_make(&prm_ceil,$2); + } | TOK_DEFAULT { $$ = param_make(&prm_default,data_unum(1)); @@ -1700,7 +1712,7 @@ | TOK_PRIO constant_expression { $$ = param_make(&prm_prio,$2); - NONZERO($$); + // NONZERO($$); jacobt add check in prio and cbq } | TOK_PRIOMAP forward_class_list { @@ -1724,6 +1736,10 @@ { $$ = param_make(&prm_rate,$2); /* NONZERO($$); @@@ policer may have zero rate */ + } + | TOK_R2Q constant_expression + { + $$ = param_make(&prm_r2q,$2); } | TOK_SET_TC_INDEX { --OgqxwSJOaUobr8KG-- From wa@almesberger.net Wed Jul 17 04:03:09 2002 From: wa@almesberger.net (Werner Almesberger) Date: Wed, 17 Jul 2002 00:03:09 -0300 Subject: [LARTC] tcng version 8t Message-ID: <20020717000309.A12583@almesberger.net> ... is on SourceForge, http://tcng.sourceforge.net/#src The main features are that it fixes the CBQ busy loop problem and RPM builds (broken in 8s), and time specifications in tcsim are now more flexible. The full change log is below. The CBQ busy loop fix is admittedly ugly: there's only one way to explicitly make CBQ select a non-leaf class, and that's by using an invalid class number. Of course, filters detect this and complain ... with one exception: u32. That was close ;-) tcsim now supports the usual SI prefixes for seconds and jiffies. Also, "time" and "until" can use relative time now. Examples: time 1500mj /* at time 1500 millijiffies */ time +500us /* relative time */ every ... until +100s ... - Werner ---------------------------------- cut here ----------------------------------- Version 8t (16-JUL-2002) ------------------------ - tcc: changed some "error"s to "lerrors"s (by Jacob Teplitsky) - updated tests/tcng-4i accordingly - tcc selected CBQ class 0 when using negation, causing the kernel to busy loop (tests/cbqzero; reported by Bert Hubert) - updated tests/cbqroot accordingly - tcsim/cfg.[ly] claimed their names were tcsim.[ly] - tcsim allowed second and jiffie values to begin with opening square bracket (tests/tcng-8t) - tcsim now supports SI prefixes "M", "k", "m", and "u" for second and jiffie values (tests/tcssi) - tcsim now supports relative time for "time" and "until" (tests/tcsrelt) - updated documentation according to above two changes - copied acknowledgements from README to documentation preamble - began adding support for FSM-based classification to external interface (untested and undocumented) - changed "-C" to "nounspec" in all test titles of tests/defdsm - RPM build didn't build "shared" directory introduced in tcng 8s From szabszi@goodwill.hu Wed Jul 17 07:11:50 2002 From: szabszi@goodwill.hu (=?iso-8859-2?Q?G=E9czi?= Szabolcs) Date: Wed, 17 Jul 2002 08:11:50 +0200 Subject: [LARTC] Re: 3 interfaces in one linux box In-Reply-To: <20020713105402.GA6262@outpost.ds9a.nl> References: <20020712224558.B11384@goodwill.hu> <20020712205525.GA28862@outpost.ds9a.nl> <20020713110129.A19562@goodwill.hu> <20020713105402.GA6262@outpost.ds9a.nl> Message-ID: <20020717081150.A5434@goodwill.hu> On Sat, Jul 13, 2002 at 12:54:02PM +0200, bert hubert wrote: > > Great, a little corrections needed, the solution provided by ahu. > > I did what bert wrote, but ahu adviced that I should write ip rule add from > > internal.ip.address table leased, after that the servers in subnet can > > answer. Thanks to Bert and ahu. > > Bert and are one guy :-) This means that ipchains acts AFTER the > policy table has been selected. iptables may well go BEFORE - be aware of > that before upgrading. [...] > > Try 'tcpdump -n -i interface' to see where packets go. They probably go out > the wrong interface. there are some additional problems with routing :). So after I set up my iproute2 (ip rule add, ip route) my servers answer from subnet, BUT the client from subnet can't reach the linuxbox's public interface (217.65.110.146) and about this problem, they can't see the webpage on the linux box. The internal ip address is available from subnet, but the leased line's public interface cannot be reached. any idea ? -- Géczi Szabolcs GPG: http://www.goodwill.hu/~szabszi/szabszi.asc Fingerprint: B36C 150C C316 5A15 DB5F 183A 303B 5AEB 36C2 3162 From Jan Coppens" <20020710083216.GC26989@outpost.ds9a.nl> Message-ID: <002f01c22d70$da2610b0$877ac19d@reve> Hi all, A short question. If you specify a protocol with a filter e.g. #tc filter add dev eth1 parent 1:0 protocol ip tc ... will this filter match every packet that has the specified protocol (IP) in one of its headers or only in the outer most header? If I encapsulate the IP packet with f.e. a TCP or ICMP header, will this filter still match? thanks, Jan From Pascal.Schnurbus@prodv.de Wed Jul 17 10:53:55 2002 From: Pascal.Schnurbus@prodv.de (Schnurbus, Pascal) Date: Wed, 17 Jul 2002 11:53:55 +0200 Subject: [LARTC] Source adress error??? Message-ID: <0CC1A27363E3D1498DAC0F28897ACD1E035644@x101.p01.prodv.loc> Hi, Network: LAN 1 Con 1 LAN 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Router 1 -------------------- Router 2 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Computer 3 | | ------------------------------------ Con 2 LAN 1: 192.168.1.0/24 LAN 2: 192.168.2.0/24 CON 1: 192.168.11.0/24 CON 2: 192.168.12.0/24 Router 1 (Lan1): 192.168.1.1 Router 1 (Con1): 192.168.11.1 Router 1 (Con2): 192.168.12.1 Router 2 (Lan2): 192.168.2.1 Router 2 (Con1): 192.168.11.2 Router 2 (Con2): 192.168.12.2 Computer 3: 192.168.2.100 Routes (Router1): 192.168.2.0/24 -> 192.168.12.2 Routes (Router2): 192.168.1.0/24 -> 192.168.12.1 IP Rule (both Router) FW-Mark 1 -> table "con1" Table "con1" (Router1): 192.168.2.0/24 -> 192.168.11.2 Table "con1" (Router2): 192.168.1.0/24 -> 192.168.11.1 iptables -t mangle PREROUTING (both Router) Port 22, 3389 -> mark 1 iptables -t mangle OUTPUT (both Router) all -> mark 1 Explanation: I have 2 routers with 2 connections between them (a fast and a slow = line). I want, that all traffic but interactive traffic go over the slow = line. Problem If i try to use snmp from Computer 3 to Router 1 (192.168.11.1) the = reply packets will have the source adress 192.168.12.1 and the firewall = on Router 2 will not accept them. Want do i wrong? Thanks for any help! Mit freundlichen Gr=FC=DFen P. Schnurbus Pascal Schnurbus=20 IT-Services Phone: +49-231-9792-138 PRO DV Software AG FAX: +49-231-9792-200 Hauert 6 mailto:pascal.schnurbus@prodv.de 44227 Dortmund http://www.prodv.de From ahu@ds9a.nl Wed Jul 17 12:25:58 2002 From: ahu@ds9a.nl (bert hubert) Date: Wed, 17 Jul 2002 13:25:58 +0200 Subject: [LARTC] Re: 3 interfaces in one linux box In-Reply-To: <20020717081150.A5434@goodwill.hu> References: <20020712224558.B11384@goodwill.hu> <20020712205525.GA28862@outpost.ds9a.nl> <20020713110129.A19562@goodwill.hu> <20020713105402.GA6262@outpost.ds9a.nl> <20020717081150.A5434@goodwill.hu> Message-ID: <20020717112558.GA17986@outpost.ds9a.nl> On Wed, Jul 17, 2002 at 08:11:50AM +0200, G?czi Szabolcs wrote: > So after I set up my iproute2 (ip rule add, ip route) my servers answer from > subnet, BUT the client from subnet can't reach the linuxbox's public > interface (217.65.110.146) and about this problem, they can't see the > webpage on the linux box. The internal ip address is available from subnet, > but the leased line's public interface cannot be reached. I'm very busy with powerdns now, but on a guess, turn off the reverse path filter and see if that helps. Otherwise, tcpdump on ALL interfaces individually and see what happens. Go beyond "can't reach". Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From lucky@knup.de Wed Jul 17 16:15:13 2002 From: lucky@knup.de (Lukas Kolbe) Date: 17 Jul 2002 17:15:13 +0200 Subject: [LARTC] Routing private and non-private ips In-Reply-To: <20020716223701.7137.49134.Mailman@outpost> References: <20020716223701.7137.49134.Mailman@outpost> Message-ID: <1026918913.504.109.camel@rechenknecht> Am Mit, 2002-07-17 um 00.37 schrieb lartc-request@mailman.ds9a.nl: > From: Martin A. Brown > To: Lucky > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Routing private and non-private ips > Date: 16 Jul 2002 13:19:19 -0500 > > Lucky, > > If I understand correctly what you are trying to do, it is simple static > network address translation. The following commands should give you > static NAT. Well, that sounds quite good :) I first got an "RTNETLINK answers: Invalid argument", but D'oh, it was the wrong shell ;) > Choose an IP in your /29 and make it the public IP. Choose an IP in the > internal rfc 1918 network and make it the private IP. Now try the > following: > > ip route add nat pu.bl.ic.ip via pr.iv.at.ip > ip rule add nat pu.bl.ic.ip from pr.iv.at.ip prio $PRIO > ip route flush cache A big thant you, this works so far. I thought that I could give a public IP to one of the NICs in the Server here, an it would be routed directly to, but this is also very nice. I think it works partially now. If I do a traceroute from a pc on the internet, it goes on up to the router and stops there. If I ping the NATed IP from the router, I get: moria2:~# ping x.x.x.42 ping: sendto: Invalid argument ping: wrote x.x.x.42 64 chars, ret=-1 Ping to the private one just works fine: moria2:~# ping 192.168.2.206 PING 192.168.2.206 (192.168.2.206): 56 data bytes 64 bytes from 192.168.2.206: icmp_seq=0 ttl=64 time=0.5 ms Well, there comes something to my mind: All of the 192.168.2.0/24 gets masq'ed to the internet on the router. I think I somehow have to exclude 192.168.2.206 (the pr.iv.at.ip) from the masq'ing, right? Or is the best solution to put the to-be-NATed server in another subnet (192.168.4.0/24) for example? > As for the packet filtering, you'll have to make a second set of rules. > > You'll need to allow the packet from outside to the public IP and you'll > need to add a second set of rules to allow the packet from outside to the > private IP. > > Good luck, > > -Martin > -- Lucky From kmallants@hotmail.com Wed Jul 17 17:18:09 2002 From: kmallants@hotmail.com (Kenny Mallants) Date: Wed, 17 Jul 2002 16:18:09 +0000 Subject: [LARTC] Routing internet to private network Message-ID: Hi, How can I share my internet connection (eth0 using dhcp) with my private network (eth1 192.168.0.*)?? Greets, Kenny _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From DiG@bvc.com.au Wed Jul 17 17:31:34 2002 From: DiG@bvc.com.au (Don Gould) Date: Thu, 18 Jul 2002 00:31:34 +0800 Subject: [LARTC] Thank You From Perth, AUSTRALIA Message-ID: <416540820D20D511AC7F00805F5DC4280AE996@NTSERVER> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C22DAF.6A1C6E10 Content-Type: text/plain; charset="iso-8859-1" Hi All, I have a bunch of Linux QoS, VPN, Bandwidth Management, Squid Proxy (and the list goes on...) questions. As an utter newbi to Linux I find many of the terms (CBQ, HTB, ippp3, qdisc, dport, tcng, wrr, tc, WFQ, ...) leave me wondering how a simple packet ever makes it from one side of my computer to the other let alone around the world! This is just a quick note to say THANKS to all those who provide THIS fantastic resource. I've seen most of the questions I have answered already. I'm sure that are others like me who don't even feel the need to ask questions. The answers to many of the challenges that face us as we take on the challenge of user to user QoS in an environment where to many are fighting for every 'bit' of capacity in our often fragile broadband internet seem to thrive here! Thank you for the gold mine :) Cheers DiG Ask not what your broadband Telcos can do for you... ...but what you can do for your broadband community! ============================================================ Don Gould Unit 4 / 3 Conroy Street CBP Team Leader Maylands , Perth Bowenvale Communications WA 6051 www.bvc.com.au Australia Phone + 61 8 9371 7289 CBP Discussion can be found on Whirlpool here... http://forums.whirlpool.net.au/forum-threads.cfm?f=51 ------_=_NextPart_000_01C22DAF.6A1C6E10 Content-Type: application/octet-stream; name="Don Gould.vcf" Content-Disposition: attachment; filename="Don Gould.vcf" BEGIN:VCARD VERSION:2.1 N:Gould;Don FN:Don Gould ORG:Bowenvale Communications TEL;WORK;VOICE:08 9371 7289 TEL;CELL;VOICE:0412 922 425 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Unit 4=0D=0A3 Conroy Street=0D=0AMaylands;Perth;WA;6051;Australia LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Unit 4=0D=0A3 Conroy Street=0D=0AMaylands=0D=0APerth, WA 6051=0D=0AAustralia EMAIL;PREF;INTERNET:DiG@bvc.com.au REV:20011130T101019Z END:VCARD ------_=_NextPart_000_01C22DAF.6A1C6E10-- From tech@playawireless.com Wed Jul 17 17:44:20 2002 From: tech@playawireless.com (Alfredo Giordano) Date: Wed, 17 Jul 2002 11:44:20 -0500 Subject: [LARTC] Routing internet to private network References: Message-ID: <002701c22db1$33756c70$130ce994@playawireless.com> Try: ----------------- modprobe iptable_nat iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward ----------------- let me know ;-) Alfredo ----- Original Message ----- From: "Kenny Mallants" To: Sent: Wednesday, July 17, 2002 11:18 AM Subject: [LARTC] Routing internet to private network > Hi, > > How can I share my internet connection (eth0 using dhcp) with my private > network (eth1 192.168.0.*)?? > > Greets, > Kenny > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From roman@complex.lviv.ua Wed Jul 17 17:44:20 2002 From: roman@complex.lviv.ua (Vasilenko Roman) Date: Wed, 17 Jul 2002 19:44:20 +0300 Subject: [LARTC] bug: source address don't changing when fwmark rerouting Message-ID: <200207171644.g6HGiLm12672@compas.complex.lviv.ua> hello ALL The source address remains the same after fwmark rerouting (route_me_harder) as it was before netfilter local_out hooks because in route_me_harder() function source address was taken from ip-header (iph->saddr) -- not from bind() address or via IP_PKTINFO this address must be saved in sock sk (like rcv_saddr) or something else in kernel. I should white patch but I not shure that my decision is right. ========= Vasilenko Roman aka Firewalker ============ From mabrown-lartc@securepipe.com Wed Jul 17 18:18:17 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Wed, 17 Jul 2002 12:18:17 -0500 (CDT) Subject: [LARTC] Routing private and non-private ips In-Reply-To: <1026918913.504.109.camel@rechenknecht> Message-ID: Lucky, : Well, there comes something to my mind: All of the 192.168.2.0/24 gets : masq'ed to the internet on the router. I think I somehow have to exclude : 192.168.2.206 (the pr.iv.at.ip) from the masq'ing, right? : Or is the best solution to put the to-be-NATed server in another subnet : (192.168.4.0/24) for example? Perhaps you could insert a new rule with ipchains or iptables. So, you have something in your chains rules that looks like this: ipchains -A forward -s 192.168.2.0/24 -d 0/0 -j MASQ Simply insert a special case: ipchains -I forward 1 -s 192.168.2.206 -d 0/0 -j ACCEPT Then the packet will not be masqueraded and will be handled by whatever other packet mangling rules you have (in particular, it will be NAT'd by the rule policy database). To verify that the RPDB has the rules you inserted, try this (your output should look similar to this; filled in with the correct pu.bl.ic.ip, of course): # ip rule show 0: from all lookup local 32765: from 192.168.2.206 lookup main map-to pu.bl.ic.ip 32766: from all lookup main 32767: from all lookup 253 # ip route show table all | grep nat nat pu.bl.ic.ip via 192.168.2.206 table local scope host Rules in both iptables and ipchains are handled sequentially, so you want to create the more specific chains rules first and then the more general. This prevents the general rule from matching before the specific rule is used. Freundliche grüsse, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From raptor@unacs.bg Wed Jul 17 20:20:38 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Wed, 17 Jul 2002 22:20:38 +0300 Subject: [LARTC] [tcng] filtering based on MAC address Message-ID: <20020717222038.75646063.raptor@unacs.bg> hi there, Is there a way to classify packets based on the MAC address ... I will have a cable plant and want to give IP addresses via DHCP (i.e dynamic), so the IP addresses will not be constant... if not is there other solution to the problem ? thanx alot raptor@unacs.bg From stef.coene@docum.org Wed Jul 17 21:41:47 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 17 Jul 2002 22:41:47 +0200 Subject: [LARTC] drawing qdisc/classes/filter trees ? In-Reply-To: <20020714220744.639dbb30.raptor@unacs.bg> References: <20020714220744.639dbb30.raptor@unacs.bg> Message-ID: <20020717204148.5A326DC640@tartarus.telenet-ops.be> On Sunday 14 July 2002 21:07, raptor@unacs.bg wrote: > is there a tool which from the tc and/or tcng file can generate a pictu= re > with the tree-like structure ... or posibly a XML file or so ? It works for me, but no promise it works for you :) http://www.docum.org/stef.coene/qos/show_qos/index.html Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From john_zhou@hotmail.com Thu Jul 18 22:27:36 2002 From: john_zhou@hotmail.com (john zhou) Date: Thu, 18 Jul 2002 21:27:36 +0000 Subject: [LARTC] tc pfifo queue length Message-ID: hi, when I read following part in sch_fifo.c, in pfifo_enqueue: static int 105 pfifo_enqueue(struct sk_buff *skb, struct Qdisc* sch) 106 { 107 struct fifo_sched_data *q = (struct fifo_sched_data *)sch->data; 108 109 if (sch->q.qlen <= q->limit) { 110 __skb_queue_tail(&sch->q, skb); 111 sch->stats.bytes += skb->len; 112 sch->stats.packets++; 113 return 0; 114 } 115 sch->stats.drops++; 116 #ifdef CONFIG_NET_CLS_POLICE 117 if (sch->reshape_fail==NULL || sch->reshape_fail(skb, sch)) 118 #endif 119 kfree_skb(skb); 120 return NET_XMIT_DROP; After enqueue, sch->q.qlen++ should be there, why in above part no this kind of sentence, sch->q.qlen updated in other place??? in bfifo, sch->stats.backlog += skb->len exists. please give some suggestion, thanks. John Zhou _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From muthu5@sbcglobal.net Fri Jul 19 02:46:00 2002 From: muthu5@sbcglobal.net (Muthukumar Ratty) Date: Thu, 18 Jul 2002 18:46:00 -0700 (PDT) Subject: [LARTC] tc pfifo queue length In-Reply-To: Message-ID: > 110 __skb_queue_tail(&sch->q, skb); > Its updated there. grep is your friend :) > > After enqueue, sch->q.qlen++ should be there, why in above part no this > kind of sentence, sch->q.qlen updated in other place??? > > in bfifo, sch->stats.backlog += skb->len exists. > > please give some suggestion, thanks. > > John Zhou > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From raptor@unacs.bg Fri Jul 19 18:48:59 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Fri, 19 Jul 2002 20:48:59 +0300 Subject: [LARTC] [tcng] drawing with gnuplot Message-ID: <20020719204859.31be4c56.raptor@unacs.bg> hi, Is there a way with tcsim to see how different channels got used i.e. say I have three channels egress { class(<$a>) if ip_src == 192.168.0.1; class(<$b>) if ip_src == 192.168.0.2; class(<$c>) if ip_src == 192.168.0.3; htb(...) { $a = class { htb(rate X1, ceil Y1 ...) }; $b = class { htb(rate X2, ceil Y2 ...) }; $c = class { htb(rate X3, ceil Y3 ...) }; } } now I want to "send" alot of packets in different speeds from these three addreses and see how channels got used when borrowing happens and in what proportions .... as I saw in the examples of the tcsim i see only E,D stuff... in fact the examples are very hard to undersand... I read the whole tcng there is no one full example of say cbq and/or tbf usage (for beginners :") ). :"( thanx alot PS. I got errors on "make test", tommorow will save it on fdd and will post them on the list .... There is one good news HTB is included in Mandrake 8.2 :"), so i dont need to patch. From raptor@unacs.bg Fri Jul 19 18:58:26 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Fri, 19 Jul 2002 20:58:26 +0300 Subject: [LARTC] tcng questions ? In-Reply-To: <20020716153602.A30555@stimpy.networkrobots.com> References: <20020714220157.6840b8a1.raptor@unacs.bg> <20020716153602.A30555@stimpy.networkrobots.com> Message-ID: <20020719205826.73b3a1c2.raptor@unacs.bg> in the tcng directory i'm doing this : patch -b /path/tcng_htb.patch it cant find which files to patch, i tried also "-p1" to "-p5" ... what I'm doing wrong thanx alot raptor@unacs.bg PS. one of the errors : it tries to patch tcc/Parameters but there is no such file, there is tcc/PARAMETERS .... (tcng-8s) From lucky@knup.de Fri Jul 19 19:29:17 2002 From: lucky@knup.de (Lukas Kolbe) Date: 19 Jul 2002 20:29:17 +0200 Subject: [LARTC] Routing private and non-private ips In-Reply-To: References: Message-ID: <1027103357.510.58.camel@rechenknecht> Am Mit, 2002-07-17 um 19.18 schrieb Martin A. Brown: > Lucky, > So, you have something in your chains rules that looks like this: > ipchains -A forward -s 192.168.2.0/24 -d 0/0 -j MASQ > Simply insert a special case: > ipchains -I forward 1 -s 192.168.2.206 -d 0/0 -j ACCEPT OK, now I have in the firewall: Chain input (policy DENY): target prot opt source destination ports [ipac and lo rules] ACCEPT all ------ 0.0.0.0/0 pu.bl.ic.ip n/a [rest] Chain forward (policy DENY): target prot opt source destination ports ACCEPT all ------ 0.0.0.0/0 192.168.2.206 n/a ACCEPT all ------ 192.168.2.206 0.0.0.0/0 n/a [masq`ing stuff] Chain output (policy DENY): target prot opt source destination ports [ipac] ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a ACCEPT all ------ 192.168.2.206 0.0.0.0/0 n/a [rest] and the routing is as follows: moria2:/etc/ipmasq/rules# ip rule ls 0: from all lookup local 320: from 192.168.2.206 lookup public.ip 32763: from is.dn.if.ip lookup isdn 32766: from all lookup main 32767: from all lookup default moria2:/etc/ipmasq/rules# ip route show table public.ip nat pu.bl.ic.ip via 192.168.2.206 scope host default dev ippp3 scope link moria2:/etc/ipmasq/rules# ip route show table isdn default via is.dn.peer.ip dev ippp3 I have a problem with the public.ip-table: normally, like in the lartc-howto, one does ip route add default via is.dn.peer.ip dev ippp3 table public.ip this actually works for table isdn (right after dial-up), but when I do this for table public.ip I get: RTNETLINK answers: Network is unreachable The ISDN-Peer is in another subnet (x.x.32.121) than our address-space (x.x.35.40/29), maybe that does matter. I hope somebody can help me there. If not, I'm just going on and try things out :) Maybe it is a Kernel-Problem, or such. I'm using 2.2.20, perhaps I have to use the lates 2.4? -- Lucky From wa@almesberger.net Fri Jul 19 23:01:17 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 19 Jul 2002 19:01:17 -0300 Subject: [LARTC] [tcng] drawing with gnuplot In-Reply-To: <20020719204859.31be4c56.raptor@unacs.bg>; from raptor@unacs.bg on Fri, Jul 19, 2002 at 08:48:59PM +0300 References: <20020719204859.31be4c56.raptor@unacs.bg> Message-ID: <20020719190117.G1424@almesberger.net> raptor@unacs.bg wrote: > Is there a way with tcsim to see how different channels got used i.e. say > I have three channels There's no general way to distinguish classes (*). However, since you select by source IP address, you can let tcsim_filter split flows by that: tcsim ... | tcsim_filter ... src | tcsim_plot (*) In principle, I could export skb->tc_index, which is always set when using the egress or ingress qdiscs, but since skb->tc_index gets assigned some more-or-less arbitrary values, additional information would be needed to make this data useful. Perhaps something to consider after switching from tcsim to umlsim. > I read the whole tcng there is no one full example of say cbq and/or > tbf usage (for beginners :") ). :"( Not sure if this helps, but there is examples-ng/tbf In general, the tcng documentation doesn't try to explain how to use the qdiscs (semantics, parameters, etc.), since all that is basically the same as with "tc". > PS. I got errors on "make test", tommorow will save it on fdd and will > post them on the list .... "make test" errors are always interesting :-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From tarekamr@haridy.com Sat Jul 20 16:21:06 2002 From: tarekamr@haridy.com (Tarek Amr) Date: Sat, 20 Jul 2002 18:21:06 +0300 Subject: [LARTC] DSMARK and Filters Message-ID: <002401c23001$139bbfb0$fa7c0c3e@s9z7y6> This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C2301A.36F230C0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I have a root qdisc "DSMARK" with a CBQ qdisc attached in it so I wanted to re classify the packets within the CBQ according to the = mark they have acquired at the DSMARK. But when I used a u32 filter = "matching on the ToS field" it failed, then I read that I have to use = some kind of filter called tcindex, but I really don't know it's syntax = well, and what's the handles parameter in it .. etc. ------=_NextPart_000_0021_01C2301A.36F230C0 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I have a root qdisc "DSMARK" with a CBQ = qdisc=20 attached in it
so I wanted to re classify the packets = within=20 the CBQ according to the mark they have acquired at the DSMARK. But = when I used a u32 filter "matching on the ToS field" it = failed, then I=20 read that I have to use some kind of filter called tcindex, but I really = don't=20 know it's syntax well, and what's the handles parameter in it ..=20 etc.
 
------=_NextPart_000_0021_01C2301A.36F230C0-- From wa@almesberger.net Sun Jul 21 00:16:20 2002 From: wa@almesberger.net (Werner Almesberger) Date: Sat, 20 Jul 2002 20:16:20 -0300 Subject: [LARTC] DSMARK and Filters In-Reply-To: <002401c23001$139bbfb0$fa7c0c3e@s9z7y6>; from tarekamr@haridy.com on Sat, Jul 20, 2002 at 06:21:06PM +0300 References: <002401c23001$139bbfb0$fa7c0c3e@s9z7y6> Message-ID: <20020720201620.H1424@almesberger.net> Tarek Amr wrote: > I have a root qdisc "DSMARK" with a CBQ qdisc attached in it > so I wanted to re classify the packets within the CBQ according to the mark > they have acquired at the DSMARK. But when I used a u32 filter "matching > on the ToS field" it failed, Yes, dsmark only changes the DS/ToS field (if at all) when the packet leaves dsmark, i.e. right before it hits the wire. > then I read that I have to use some kind of filter called tcindex, > but I really don't know it's syntax well, and what's the handles > parameter in it .. etc. Please read ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From tarekamr@haridy.com Sun Jul 21 07:01:39 2002 From: tarekamr@haridy.com (Tarek Amr) Date: Sun, 21 Jul 2002 09:01:39 +0300 Subject: [LARTC] Thanks Warner but .... Message-ID: <000a01c2307c$164eb4d0$737c0c3e@s9z7y6> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C23095.39775F20 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thanks Warner for your help, but the code there didn't work I think there is something with tcindex handle=20 ------=_NextPart_000_0007_01C23095.39775F20 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks Warner for your help, but the = code there=20 didn't work
 
I think there is something with =  tcindex=20 handle 
------=_NextPart_000_0007_01C23095.39775F20-- From albertogli@telpin.com.ar Mon Jul 22 04:49:19 2002 From: albertogli@telpin.com.ar (Alberto Bertogli) Date: Mon, 22 Jul 2002 00:49:19 -0300 Subject: [LARTC] Frozen machine with adding a tc filter Message-ID: <20020722034919.GH685@telpin.com.ar> Hi! This is a (really early) bug report on one i just caught when setting a filter for traffic control. It makes the machine to frozen solid, without even an oops. Keyboard is not responsive (neither sysrq nor the num/caps/screen lock leds), everything seems quite dead. It's fully reproducible, i tried both 2.4.13 and 2.4.19-rc3 (the last one with htb patches, but i don't think it's related). The machine is an iPII with 256Mb RAM, it has been working well for about a year and a half. Basically a main cbq class with two (also cbq) leaves: tc qdisc add dev eth1 root handle 20:0 cbq bandwidth 100Mbit avpkt 1000 tc class add dev eth1 parent 20:0 classid 20:1 $EST cbq bandwidth 100Mbit \ rate 2800Kbit bounded isolated $CBQ_PARAMS ($EST is empty and $CBQ_PARAMS is "allot 1514 avpkt 1000") Both leaves are basically the same, just a cbq class with parent 20:1 and then sfq attached as qdisc; really simple. I have another set pretty much like this one, only with one leave, on eth0. The command which frozes the machine is tc filter add dev eth1 parent 20:0 protocol ip handle 5 fw classid 20:0 I know it's weird, but anyway i don't think that a lockup is the error the user deserves =) Setting classid 20:X (X != 0) works as expected. As this is quite early (just hit it) i don't know if i can reproduce it using another scenario. Tomorrow i'll try to dig into it on a testing machine and i'll post the results. Thanks, Alberto From lumir.unzeitig@gatc.com Mon Jul 22 09:44:56 2002 From: lumir.unzeitig@gatc.com (Lumir Unzeitig) Date: Mon, 22 Jul 2002 10:44:56 +0200 Subject: [LARTC] htb2 with link sharing - the bandwidth dividing question Message-ID: <009201c2315c$0f306fa0$6403a8c0@unzeitig> Hi I have flat structure of traffic control - 8 children can borrow from a parent. Problem: The rest bandwidth is not divided to children how I expect. The ISP line is 64kbit/s,therefore, I'm working with 56kbit/s. (the config is in the end of the mail) I set up a test environment - 1\ 3 PCs, each of them in different subclass 2\ minimal bandwidth (RATE) PC1 - 4kbit/s class 1:10 PC2 - 4kbit/s class 1:40 PC3 - 15kbit/s class 1:80 maximal bandwith (CEIL) 56kbit/s 3\ all of the PCs download the same big file from ISP ftp server by Windows Commander. I supposed "the rest of bandwidth is divided to the PCs in ratio of their RATE values". But it isn't. Calculation ======== the rest: 56 - 4 - 4 - 15 = 33 kbit/s desired PC1 bw: 4 + 33/(4+4+15) * 4 = 9,74 kbit/s < real PC1 bw: 12 kbit/s desired PC2 bw: 4 + 33/(4+4+15) * 4 = 9,74 kbit/s < real PC2 bw: 12 kbit/s desired PC3 bw: 15 + 33/(4+4+15) * 15 = 36,52 kbit/s > real PC3 bw: 29.6 kbit/s Please,can anybody tell me what's wrong in the calculation or setting? Thanks Lumir Unzeitig ---[ eth0: configured classes ]--------------------------- class htb 1:1 root prio 0 rate 56Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 1912117995 bytes 2263853 pkts (dropped 0, overlimits 0) rate 292bps 1pps lended: 1072525 borrowed: 0 giants: 0 injects: 0 tokens: 227657 ctokens: 184572 class htb 1:10 parent 1:1 leaf 100: prio 0 rate 4Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 26382511 bytes 303604 pkts (dropped 0, overlimits 364) rate 107bps lended: 300541 borrowed: 3063 giants: 0 injects: 0 tokens: 3161600 ctokens: 182743 class htb 1:20 parent 1:1 leaf 200: prio 0 rate 9Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 394142012 bytes 400328 pkts (dropped 0, overlimits 10743) lended: 138359 borrowed: 261969 giants: 0 injects: 0 tokens: 1236764 ctokens: 184572 class htb 1:40 parent 1:1 leaf 400: prio 0 rate 4Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 5245504 bytes 4490 pkts (dropped 0, overlimits 67) lended: 1627 borrowed: 2863 giants: 0 injects: 0 tokens: 3174400 ctokens: 183658 class htb 1:50 parent 1:1 leaf 500: prio 0 rate 6Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 186581247 bytes 273327 pkts (dropped 0, overlimits 3118) lended: 144824 borrowed: 128503 giants: 0 injects: 0 tokens: 2116266 ctokens: 183658 class htb 1:60 parent 1:1 leaf 600: prio 0 rate 9Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 71911357 bytes 143754 pkts (dropped 0, overlimits 2096) rate 3bps lended: 104774 borrowed: 38980 giants: 0 injects: 0 tokens: 1190802 ctokens: 184572 class htb 1:70 parent 1:1 leaf 700: prio 0 rate 4Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 18277641 bytes 22099 pkts (dropped 0, overlimits 537) lended: 5879 borrowed: 16220 giants: 0 injects: 0 tokens: 2436096 ctokens: 184572 class htb 1:80 parent 1:1 leaf 800: prio 0 rate 15Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 1176861863 bytes 1057644 pkts (dropped 0, overlimits 19241) rate 285bps 1pps lended: 471653 borrowed: 585991 giants: 0 injects: 0 tokens: 849920 ctokens: 184572 class htb 1:90 parent 1:1 leaf 900: prio 0 rate 6Kbit ceil 56Kbit burst 2Kb cburst 1670b Sent 32715860 bytes 58607 pkts (dropped 0, overlimits 2741) lended: 23671 borrowed: 34936 giants: 0 injects: 0 tokens: 2116266 ctokens: 183658 From radoslav_kolev@smartcom.bg Mon Jul 22 12:08:12 2002 From: radoslav_kolev@smartcom.bg (Radoslav Kolev) Date: Mon, 22 Jul 2002 14:08:12 +0300 Subject: [LARTC] squid marking packets Message-ID: <3D3BE79C.4@smartcom.bg> Hi all! Does anyone know about some patch for squid allowing it to mark IP packets based on if the request being served is a cache HIT or a MISS. thanx RAdo From Jan Coppens" This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C23177.32F4ABC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I've create a cbq qdisc on an 100Mbit link and I attached a cbq class to = it with a rate of 15Mbit (borrow). Now I would like to attach a RED = qdisc to that class, but I'm a little confused by the REDs parameters. = What should I choose for the bandwidth (100Mbit or 15Mbit) and what are = some good values for min, max, limit and burst in my case? All help is appreciated thanks, Jan ------=_NextPart_000_0029_01C23177.32F4ABC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I've create a cbq qdisc on an 100Mbit = link and I=20 attached a cbq class to it with a rate of 15Mbit (borrow). Now I would = like to=20 attach a RED qdisc to that class, but I'm a little confused by the = REDs=20 parameters. What should I choose for the bandwidth (100Mbit or 15Mbit) = and what=20 are some good values for min, max, limit and burst in my = case?
 
All help is appreciated
thanks,
 
Jan
------=_NextPart_000_0029_01C23177.32F4ABC0-- From stef.coene@docum.org Mon Jul 22 15:38:43 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 22 Jul 2002 16:38:43 +0200 Subject: [LARTC] htb2 with link sharing - the bandwidth dividing question In-Reply-To: <009201c2315c$0f306fa0$6403a8c0@unzeitig> References: <009201c2315c$0f306fa0$6403a8c0@unzeitig> Message-ID: <20020722163038.7057BDC015@tartarus.telenet-ops.be> On Monday 22 July 2002 10:44, Lumir Unzeitig wrote: > Hi > I have flat structure of traffic control - 8 children can borrow from a > parent. > Problem: The rest bandwidth is not divided to children how I expect. > I supposed "the rest of bandwidth is divided to the PCs in ratio of th= eir > RATE values". But it isn't. But how is the bandwidth divided in your test ? Can be handy to know to = find=20 a solution/answer ... And can you post the used htb script? Stef From raptor@unacs.bg Mon Jul 22 18:59:17 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Mon, 22 Jul 2002 20:59:17 +0300 Subject: [LARTC] [tcng] make test errors Message-ID: <20020722205917.294daa93.raptor@unacs.bg> tcng-8t on Mandrake 8.2 Below are the errors I got.. errors-------------------------------------------- --> in $a = { $x = 13; 7; }; field foo = raw if $a == $a; --> out :17: warning: unused variable x --> ref :1: warning: unused variable x make test --------------------------------- .............. bare words for strings are forbidden: PASSED quoted strings for strings are okay: PASSED bare words for warning labels are forbidden: PASSED (warning: output differs) Standard output: | :17: syntax error near "nounused" Reference output: | :1: syntax error near "nounused" quoted strings for warning labels are okay: PASSED ............ ....... bucket: can define variables: PASSED bucket: can use with conform, count: PASSED bucket: policer parameters are refused: PASSED (warning: output differs) Standard output: | :17: unrecognized parameter "mtu" Reference output: | :1: unrecognized parameter "mtu" bucket: "bucket" is no synonym for "police" after filters: PASSED bucket: tc does not dump buckets: PASSED bucket: tc does not dump buckets (sneaky): PASSED ........... compound construct with multiple assignments: PASSED compound construct must end with semicolon: PASSED (warning: output differs) Standard output: | :17: syntax error near "}" Reference output: | :1: syntax error near "}" compound construct may end with multiple semicolons: PASSED compound construct requires semicolon after assignment: PASSED (warning: output differs) Standard output: | :17: syntax error near "$x" Reference output: | :1: syntax error near "$x" compound construct allows multiple semicolons after assignment: PASSED compound construct warns about unused variables: FAILED File: tests/compound Command: tcc -c 2>&1 Input: _in.26670 Output: _out.26670 Reference: _ref.26670 From raptor@unacs.bg Mon Jul 22 19:05:47 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Mon, 22 Jul 2002 21:05:47 +0300 Subject: [LARTC] [tcng] correct config? Message-ID: <20020722210547.6dfe1e49.raptor@unacs.bg> Below is my tests and I have some questions regarding them : first it seems that classification doesnt happen at all ?! and it is clear from the u32 filters 'cause they point to classes 1:1 and 1:2 which doesnt exist at all ? Also I can't figure out which filter got used u32 or tc_index but 'cause tcism_plot generates only enqueed packed and no dequee-packets. They have same priority but u32 is attached at root so they should be used, right ? Ok I will describe the scenario I want to achieve if u can give me simple exmples : On the root I want to create one 256KB/s channel then in this channel I want to create two channels which will be separated on two one 60% the other 40% (both can borrow bandwith from each other but the 60%-channel has to be more privileged, higher priority) Then in those two channels I want have more small channels say 30 in each of them... (cbq and htb if posiible :") 'm I nasty !) Next question : Say I have to handle other traffic not only Internet, then I should make sibling channels to my Internet one to handle this, right ? One final question : If u have say 1Mbps Internet connection to the outside world what channel u create below-the-root (which is 100Mbps -ethernet) for handling your internet traffic -- exact 1Mbps OR something like 1.2Mbps so that u can be sure that if link is used to 100% u dont end up using something like 98% of the link OR some other way ? xxx.tcng================================================== dev eth0 { egress { class(<$t1>) if ip_src == 192.168.0.1; class(<$t2>) if ip_src == 192.168.0.2; //drop if tcp_sport != PORT_HTTP; //drop if 1; cbq(bandwidth 256*8 kbps, maxburst 200p, avpkt 1024B, allot 1514B) { $t1 = class(5,rate 19200 bps) { tbf(rate 19200 bps, burst 3000B, limit 280B, mtu 1510B) {}; } $t2 = class(6, rate 33600 bps) {}; } } } ----------------------- I start tcism this way : tcism xxx.tcng | tcsim_filter src | tcism_plot #include "packet.def" #include "ports.tc" dev eth0 10Mbps { #include "xxx.tcng" } every 0.1s send TCP_PCK($ip_src = 192.168.0.1 $tcp_sport = PORT_HTTP); time 2s end ----------------------- the result of tcc compilation---------------------------------------- # ================================ Device eth0 ================================ tc qdisc add dev eth0 handle 1:0 root dsmark indices 4 default_index 0 tc qdisc add dev eth0 handle 2:0 parent 1:0 cbq bandwidth 256000bps avpkt 1024 tc class add dev eth0 parent 2:0 classid 2:5 cbq bandwidth 256000bps rate 2400bps allot 1514 avpkt 1024 maxburst 200 tc qdisc add dev eth0 handle 3:0 parent 2:5 tbf burst 3000 limit 280 mtu 1510 rate 2400bps tc class add dev eth0 parent 2:0 classid 2:6 cbq bandwidth 256000bps rate 4200bps allot 1514 avpkt 1024 maxburst 200 tc filter add dev eth0 parent 2:0 protocol ip prio 1 tcindex mask 0x3 shift 0 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 2 tcindex classid 2:6 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 1 tcindex classid 2:5 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1:0:0 u32 divisor 1 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u32 0xc0a80001 0xffffffff at 12 classid 1:1 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u32 0xc0a80002 0xffffffff at 12 classid 1:2 Thanx alot raptor@unacs.bg From raptor@unacs.bg Mon Jul 22 19:13:56 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Mon, 22 Jul 2002 21:13:56 +0300 Subject: [LARTC] [tcng] htb example and default class Message-ID: <20020722211356.598cf694.raptor@unacs.bg> hi I patched tcng to support htb (it seems to work :") ), now when I try to use it i got this error : htb requires one class to be marked as "default" If I try to use somewhere "class(default, .....) {}" i get : unrecognized parameter "default" I tried also "def", "dfl" nope :"[ How do u mark some class to be "default" !?! can u give me some example ? (htb preffered). Thanx alot in advance raptor@unacs.bg PS. In fact only gred qdisc has a "default" parameter as I read the docs?!? From stef.coene@docum.org Mon Jul 22 19:40:06 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 22 Jul 2002 20:40:06 +0200 Subject: [LARTC] [tcng] correct config? In-Reply-To: <20020722210547.6dfe1e49.raptor@unacs.bg> References: <20020722210547.6dfe1e49.raptor@unacs.bg> Message-ID: <20020722184007.0C2AADC419@tartarus.telenet-ops.be> On Monday 22 July 2002 20:05, raptor@unacs.bg wrote: > Below is my tests and I have some questions regarding them : > first it seems that classification doesnt happen at all ?! and it is cl= ear > from the u32 filters 'cause they point to classes 1:1 and 1:2 which doe= snt > exist at all ? Also I can't figure out which filter got used u32 or > tc_index but 'cause tcism_plot generates only enqueed packed and no > dequee-packets. They have same priority but u32 is attached at root so = they > should be used, right ? > > Ok I will describe the scenario I want to achieve if u can give me simp= le > exmples : > > On the root I want to create one 256KB/s channel then in this channel I > want to create two channels which will be separated on two one 60% the > other 40% (both can borrow bandwith from each other but the 60%-channel= has > to be more privileged, higher priority) What do you exacly mean with "more privileged, higher priority" ?? > Then in those two channels I want have more small channels say 30 in ea= ch > of them... (cbq and htb if posiible :") 'm I nasty !) No problem with cbq nor with htb. > Next question : Say I have to handle other traffic not only Internet, t= hen > I should make sibling channels to my Internet one to handle this, right= ? Mhh. I don't understand your point. > One final question : If u have say 1Mbps Internet connection to the out= side > world what channel u create below-the-root (which is 100Mbps -ethernet)= =20 > for handling your internet traffic -- exact 1Mbps OR something like 1.2= Mbps > so that u can be sure that if link is used to 100% u dont end up using > something like 98% of the link OR some other way ? Other way. If you create a 1.2 Mbps class, you will send more data then = the=20 internet connecion can handle. So the buffers in the internet modem (mos= t=20 high-bandwidth modems has big buffers to get a higher throuput) will get=20 filled. Solution: make sure the buffers are never filled so send less bandwidth t= hen=20 you actualy have. You loose some bandwidth, but you win the ability to=20 control that bandwidth. There is also something wrong with the output generated by tcng. But I d= ived=20 not deep enough in the tcng docs to know what's going wrong. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Mon Jul 22 19:42:01 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 22 Jul 2002 20:42:01 +0200 Subject: [LARTC] [tcng] htb example and default class In-Reply-To: <20020722211356.598cf694.raptor@unacs.bg> References: <20020722211356.598cf694.raptor@unacs.bg> Message-ID: <20020722184202.89BA4DD189@tartarus.telenet-ops.be> On Monday 22 July 2002 20:13, raptor@unacs.bg wrote: > hi > I patched tcng to support htb (it seems to work :") ), now when I try t= o > use it i got this error : > > htb requires one class to be marked as "default" It's not required if you use the tc command to create a htb qdisc. So I= =20 guess it's a small bug in the patch for tcng. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From raptor@unacs.bg Mon Jul 22 20:29:15 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Mon, 22 Jul 2002 22:29:15 +0300 Subject: [LARTC] [tcng] correct config? In-Reply-To: <20020722184007.0C2AADC419@tartarus.telenet-ops.be> References: <20020722210547.6dfe1e49.raptor@unacs.bg> <20020722184007.0C2AADC419@tartarus.telenet-ops.be> Message-ID: <20020722222915.1eb7103e.raptor@unacs.bg> |> On the root I want to create one 256KB/s channel then in this channel I |> want to create two channels which will be separated on two one 60% the |> other 40% (both can borrow bandwith from each other but the 60%-channel has |> to be more privileged, higher priority) |What do you exacly mean with "more privileged, higher priority" ?? ]- Opps i've made a mistake... both have to be able to use bantwidth from each other (if the "other" is not used at its full capacity).. then it is ok.. in HTB it should be : 40% -> rate 40% ceil 100% 60% -> rate 60% ceil 100% |> Then in those two channels I want have more small channels say 30 in each |> of them... (cbq and htb if posiible :") 'm I nasty !) |No problem with cbq nor with htb. ]- i meaned if possible u to provide examples in both qdisc :") |> Next question : Say I have to handle other traffic not only Internet, then |> I should make sibling channels to my Internet one to handle this, right ? |Mhh. I don't understand your point. egress { //100Mbps //internet traffic htb (rate 256Kbps) { .... }; // other traffic : say intranet traffic htb (rate XXX) { .... } } |Solution: make sure the buffers are never filled so send less bandwidth then |you actualy have. You loose some bandwidth, but you win the ability to |control that bandwidth. ]- understand |There is also something wrong with the output generated by tcng. But I dived |not deep enough in the tcng docs to know what's going wrong. ]- i cant figure out yet too... (i'm doing those test on the computer at work, but still have no Internet there.. ) |Stef From stef.coene@docum.org Mon Jul 22 20:35:19 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 22 Jul 2002 21:35:19 +0200 Subject: [LARTC] [tcng] correct config? In-Reply-To: <20020722222915.1eb7103e.raptor@unacs.bg> References: <20020722210547.6dfe1e49.raptor@unacs.bg> <20020722184007.0C2AADC419@tartarus.telenet-ops.be> <20020722222915.1eb7103e.raptor@unacs.bg> Message-ID: <20020722193520.7A558DD189@tartarus.telenet-ops.be> > ]- Opps i've made a mistake... both have to be able to use bantwidth fr= om > each other (if the "other" is not used at its full capacity).. then it = is > ok.. in HTB it should be : > 40% -> rate 40% ceil 100% > 60% -> rate 60% ceil 100% AND both connected to a 1 class with 100% rate, 100 ceil. > |> Then in those two channels I want have more small channels say 30 in > |> each of them... (cbq and htb if posiible :") 'm I nasty !) > | > |No problem with cbq nor with htb. > > ]- i meaned if possible u to provide examples in both qdisc :") I have no examples for that with tcng. But I have "some" docs on=20 www.docum.org if you are interested. > |> Next question : Say I have to handle other traffic not only Internet= , > |> then I should make sibling channels to my Internet one to handle thi= s, > |> right ? > | > |Mhh. I don't understand your point. > > egress { //100Mbps > //internet traffic > htb (rate 256Kbps) { .... }; > // other traffic : say intranet traffic > htb (rate XXX) { .... } That's indeed the way to handle this. > |There is also something wrong with the output generated by tcng. But = I > | dived not deep enough in the tcng docs to know what's going wrong. > > ]- i cant figure out yet too... (i'm doing those test on the computer = at > work, but still have no Internet there.. ) Reading tc docs is number one on my to do list :) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From raptor@unacs.bg Mon Jul 22 20:41:57 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Mon, 22 Jul 2002 22:41:57 +0300 Subject: [LARTC] linux NETWORKING diagram ? Message-ID: <20020722224157.257560e0.raptor@unacs.bg> Hi, is there a full diagram of the whole path of the PACKET trought the linux-kernel i.e something like this : http://netfilter.samba.org/unreliable-guides/packet-filtering-HOWTO/packet-filtering-HOWTO.linuxdoc-6.html but including the all the stuff that got touched from "ip(route)", "iptables", "tc" and the desicion making for choosing the correct path .... If there is someone to explain it I will draw it if nececary :") raptor@unacs.bg From stef.coene@docum.org Mon Jul 22 21:03:23 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 22 Jul 2002 22:03:23 +0200 Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <20020722224157.257560e0.raptor@unacs.bg> References: <20020722224157.257560e0.raptor@unacs.bg> Message-ID: <20020722200325.07AF0DC4DD@tartarus.telenet-ops.be> On Monday 22 July 2002 21:41, raptor@unacs.bg wrote: > Hi, > > is there a full diagram of the whole path of the PACKET trought the > linux-kernel i.e something like this : > http://netfilter.samba.org/unreliable-guides/packet-filtering-HOWTO/pac= ket- >filtering-HOWTO.linuxdoc-6.html > > but including the all the stuff that got touched from "ip(route)",=20 > "iptables", "tc" and the desicion making for choosing the correct path = =2E... > If there is someone to explain it I will draw it if nececary :") I have a drawing that was posted once on this list. You can find it on=20 www.docum.org under KPTD. Plz feel free to send me updates. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From jacobt@bivio.net Mon Jul 22 21:54:19 2002 From: jacobt@bivio.net (Jacob Teplitsky) Date: Mon, 22 Jul 2002 13:54:19 -0700 (PDT) Subject: [LARTC] LARTC digest, Vol 1 #689 - 13 msgs (fwd) Message-ID: <200207222054.g6MKsJK15974@stimpy.networkrobots.com> > Message: 7 > Date: Mon, 22 Jul 2002 21:13:56 +0300 > From: raptor@unacs.bg > To: lartc@mailman.ds9a.nl > Subject: [LARTC] [tcng] htb example and default class > > hi > I patched tcng to support htb (it seems to work :") ), now when I try to use it i got this error : > > htb requires one class to be marked as "default" > > If I try to use somewhere "class(default, .....) {}" i get : > > unrecognized parameter "default" > > I tried also "def", "dfl" nope :"[ > How do u mark some class to be "default" !?! can u give me some example ? (htb preffered). > > > Thanx alot in advance > raptor@unacs.bg > > PS. In fact only gred qdisc has a "default" parameter as I read the docs?!? > > --__--__-- > > Message: 9 > From: Stef Coene > To: raptor@unacs.bg, lartc@mailman.ds9a.nl > Subject: Re: [LARTC] [tcng] htb example and default class > Date: Mon, 22 Jul 2002 20:42:01 +0200 > > On Monday 22 July 2002 20:13, raptor@unacs.bg wrote: > > hi > > I patched tcng to support htb (it seems to work :") ), now when I try t= > o > > use it i got this error : > > > > htb requires one class to be marked as "default" > It's not required if you use the tc command to create a htb qdisc. So I= > =20 > guess it's a small bug in the patch for tcng. > > > Stef > > ======================================= Here is a sample of htb tcng script and the output: > guess it's a small bug in the patch for tcng. I thought that it is required: tc qdisc add dev eth0 handle 2:0 parent 1:0 htb default 5 r2q 100 ~~~~~~~ - Jacob dev "eth0" { egress { $base = 100 * 1kBps; class (<$cl1_2>) if ((raw[6] & 0xfe) == 0); class (<$cl1_12>) if (raw[6] == 2); class (<$cl1_10>) if (raw[6] == 0); class (<$cl1_11>) if (raw[6] == 1); htb (r2q 100) { class(rate 10 * $base) { $cl1_2 = class (rate 4 * $base, ceil 8 * $base,) { $cl1_10 = class (rate 3 * $base, ceil 10 * $base, prio 1) { fifo(limit 8p); } $cl1_11 = class (rate 1 * $base, ceil 10 * $base, prio 0) { fifo(limit 8p); } } } $cl1_12 = class (rate 6 * $base, ceil 10 * $base, prio 1, default) { fifo(limit 8p); } } } } # ================================ Device eth0 ================================ tc qdisc add dev eth0 handle 1:0 root dsmark indices 8 default_index 0 tc qdisc add dev eth0 handle 2:0 parent 1:0 htb default 5 r2q 100 tc class add dev eth0 parent 2:0 classid 2:1 htb rate 1000000bps tc class add dev eth0 parent 2:1 classid 2:2 htb rate 400000bps ceil 800000bps tc class add dev eth0 parent 2:2 classid 2:3 htb rate 300000bps ceil 1000000bps prio 1 tc qdisc add dev eth0 handle 3:0 parent 2:3 pfifo limit 8 tc class add dev eth0 parent 2:2 classid 2:4 htb rate 100000bps ceil 1000000bps prio 0 tc qdisc add dev eth0 handle 4:0 parent 2:4 pfifo limit 8 tc class add dev eth0 parent 2:0 classid 2:5 htb rate 600000bps ceil 1000000bps prio 1 tc qdisc add dev eth0 handle 5:0 parent 2:5 pfifo limit 8 tc filter add dev eth0 parent 2:0 protocol ip prio 1 tcindex mask 0x7 shift 0 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 4 tcindex classid 2:4 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 3 tcindex classid 2:3 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 2 tcindex classid 2:5 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 1 tcindex classid 2:2 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1:0:0 u32 divisor 1 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u8 0x0 0xfe at 6 classid 1:1 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u8 0x2 0xff at 6 classid 1:2 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u8 0x0 0xff at 6 classid 1:3 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u8 0x1 0xff at 6 classid 1:4 From paul.damink@philips.com Mon Jul 22 23:46:30 2002 From: paul.damink@philips.com (paul.damink@philips.com) Date: Tue, 23 Jul 2002 00:46:30 +0200 Subject: [LARTC] Paul Damink/EHV/RESEARCH/PHILIPS is out of the office. Message-ID: I will be out of the office starting 12-07-2002 and will not return until 12-08-2002. I will respond to your message when I return. From leoball@opalsoft.net Tue Jul 23 00:22:26 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Mon, 22 Jul 2002 19:22:26 -0400 Subject: [LARTC] Attacing a RED to a CBQ Message-ID: <5.1.0.14.1.20020722191202.00a10de0@opalsoft.net> Hi Jan: Perhaps this could help you. Best regards, Leonardo Balliache Pd: haven't never implemented one of this monsters. NAME red - Random Early Detection SYNOPSIS tc qdisc ... red limit bytes min bytes max bytes avpkt bytes burst packets [ ecn ] [ bandwidth rate ] probability chance DESCRIPTION Random Early Detection is a classless qdisc which limits its queue size smartly. Regular queues simply drop packets from the tail when they are full, which may not be the optimal behaviour. RED also performs tail drop, but does so in a more gradual way. Once the queue hits a certain average length, packets enqueued have a configurable chance of being marked (which may mean dropped). This chance increases linearly up to a point called the max average queue length, although the queue might get bigger. This has a host of benefits over simple taildrop, while not being processor intensive. It prevents synchronous retransmits after a burst in traffic, which cause further retransmits, etc. The goal is the have a small queue size, which is good for interactivity while not disturbing TCP/IP traffic with too many sudden drops after a burst of traffic. Depending on wether ECN is configured, marking either means dropping or purely marking a packet as overlimit. ALGORITHM The average queue size is used for determining the marking probability. This is calculated using an Exponential Weighted Moving Average, which can be more or less sensi- tive to bursts. When the average queue size is below min bytes, no packet will ever be marked. When it exceeds min, the probability of doing so climbs linearly up to probability, until the average queue size hits max bytes. Because probability is normally not set to 100%, the queue size might conceivably rise above max bytes, so the limit parameter is provided to set a hard maximum for the size of the queue. PARAMETERS min Average queue size at which marking becomes a pos- sibility. max At this average queue size, the marking probability is maximal. Should be at least twice min to prevent synchronous retransmits, higher for low min. probability Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%, respectively). limit Hard limit on the real (not average) queue size in bytes. Further packets are dropped. Should be set higher than max+burst. It is advised to set this a few times higher than max. burst Used for determining how fast the average queue size is influenced by the real queue size. Larger values make the calculation more sluggish, allowing longer bursts of traffic before marking starts. Real life experiments support the following guide- line: (min+min+max)/(3*avpkt). avpkt Specified in bytes. Used with burst to determine the time constant for average queue size calcula- tions. 1000 is a good value. bandwidth This rate is used for calculating the average queue size after some idle time. Should be set to the bandwidth of your interface. Does not mean that RED will shape for you! Optional. ecn As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion Notification allows RED to notify remote hosts that their rate exceeds the amount of bandwidth available. Non-ECN capable hosts can only be notified by dropping a packet. If this parameter is specified, packets which indi- cate that their hosts honor ECN will only be marked and not dropped, unless the queue size hits limit bytes. Needs a tc binary with RED support compiled in. Recommended. SOURCES o Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html o Some changes to the algorithm by Alexey N. Kuznetsov. SEE ALSO tc-cbq(8), tc-htb(8), tc-red(8), tc-tbf(8), tc-pfifo(8), tc-bfifo(8), tc-pfifo_fast(8), tc-filters(8) From packetmagician@ii.net Tue Jul 23 02:07:48 2002 From: packetmagician@ii.net (Chris Harrison) Date: Tue, 23 Jul 2002 09:07:48 +0800 Subject: [LARTC] squid marking packets In-Reply-To: <3D3C05BC.9040709@smartcom.bg> Message-ID: <004b01c231e5$5f9a1340$0d00a8c0@blackwin> -----Original Message----- From: Radoslav Kolev [mailto:radoslav_kolev@smartcom.bg] Sent: Monday, 22 July 2002 9:17 PM To: Chris Harrison Subject: Re: [LARTC] squid marking packets Chris Harrison wrote: >No, but how would it help anyway? > >The packets are on different OSI levels to begin with. >You could probably filter squid accessing the internet checking whether >it's trying for a If-Modified-Since request or a Get Request... > >What exactly are you trying to do anyway? > >__________________________________________________________________ >Mr Chris Harrison > >ICQ#: 354303 >EMAIL: theguru@ii.net >__________________________________________________________________ > > >-----Original Message----- >From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] >On Behalf Of Radoslav Kolev >Sent: Monday, 22 July 2002 7:08 PM >To: lartc@mailman.ds9a.nl >Subject: [LARTC] squid marking packets > >Hi all! >Does anyone know about some patch for squid allowing it to mark IP >packets based >on if the request being served is a cache HIT or a MISS. >thanx >RAdo > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > Hi! I want squid to put different marks on IP packets belonging to a connection between a client (web browser) and squid, depending on if the file requested is served from the cache or fetched from the web server. By doing this I can send objects from the cache at full speed to the clients (because these requests don't consume bandwidth to my ISP). If the object is not found in the cache i wan't to limit the bandwidth consumed for fetching the object. I think that if I use squid delay pools they will not affect traffic serverd from the cache, and this is what I want. The problem is that not all the traffic is passing through squid. I hope this makes it a bit more clear. RAdo ---- After quite a bit of a search I found this which maybe of interest to you. http://www.squid-cache.org/mail-archive/squid-users/200005/0470.html I think it basically states that delay pools only affect incoming data, and therefore do not affect the rate of data retrieved that's already cached. HTH. Chris From gabriel@sics.se Tue Jul 23 08:15:20 2002 From: gabriel@sics.se (Gabriel Paues) Date: Tue, 23 Jul 2002 09:15:20 +0200 (CEST) Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <20020722224157.257560e0.raptor@unacs.bg> Message-ID: Hello! I have made one diagram for the IPv6 stack if that interests anybody, for download at: www.sics.se/~gabriel/funccalls.pdf The Netfilter hooks are marked out as well, on this diagram. Cheers! /gabriel On Mon, 22 Jul 2002 raptor@unacs.bg wrote: > > > > Hi, > > is there a full diagram of the whole path of the PACKET trought the linux-kernel i.e something like this : > http://netfilter.samba.org/unreliable-guides/packet-filtering-HOWTO/packet-filtering-HOWTO.linuxdoc-6.html > > but including the all the stuff that got touched from "ip(route)", "iptables", "tc" and the desicion making for choosing the correct path .... If there is someone to explain it I will draw it if nececary :") > > raptor@unacs.bg > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From tarekamr@haridy.com Tue Jul 23 09:14:19 2002 From: tarekamr@haridy.com (Tarek Amr) Date: Tue, 23 Jul 2002 11:14:19 +0300 Subject: [LARTC] The re-classifying Message-ID: <002001c23221$15b50690$037c0c3e@s9z7y6> This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C2323A.16E3E040 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Referring to Differentiated Services on Linux = I read the examples there; they seem to be very helpful. Especially the = last two ones of thee EF But in my case I am working on an exterior node (packets are not marked = yet) Here is a brief description of my problem. =20 =20 1. tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 = set_tc_index 2. tc class change dev eth0 parent 1:0 classid 1:1 dsmark mask 0x3 = value 0xb8 3. tc class change dev eth0 parent 1:0 classid 1:2 dsmark mask 0x3 = value 0x28 4. tc class change dev eth0 parent 1:0 classid 1:3 dsmark mask 0x3 = value 0x30 5. tc class change dev eth0 parent 1:0 classid 1:4 dsmark mask 0x3 = value 0x38 6. tc class change dev eth0 parent 1:0 classid 1:5 dsmark mask 0x3 = value 0x48 7. tc class change dev eth0 parent 1:0 classid 1:6 dsmark mask 0x3 = value 0x50 8. tc class change dev eth0 parent 1:0 classid 1:7 dsmark mask 0x3 = value 0x58 9. tc class change dev eth0 parent 1:0 classid 1:8 dsmark mask 0x3 = value 0x60 10. tc class change dev eth0 parent 1:0 classid 1:9 dsmark mask 0x3 = value 0x70 11. tc class change dev eth0 parent 1:0 classid 1:a dsmark mask 0x3 = value 0x78 12. tc class change dev eth0 parent 1:0 classid 1:b dsmark mask 0x3 = value 0x88 13. tc class change dev eth0 parent 1:0 classid 1:c dsmark mask 0x3 = value 0x90 14. tc class change dev eth0 parent 1:0 classid 1:d dsmark mask 0x3 = value 0x98 15. tc qdisc add dev eth0 handle 2:0 parent 1:0 cbq bandwidth = 10Mbit cell 8 avpkt 1000 mpu 64 16. tc class add dev eth0 classid 2:1 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 1 bounded allot 1514 weight 1 = maxburst 21 17. tc class add dev eth0 classid 2:2 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 2 bounded allot 1514 weight 1 = maxburst 21 18. tc class add dev eth0 classid 2:3 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 3 bounded allot 1514 weight 1 = maxburst 21 19. tc class add dev eth0 classid 2:4 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 4 bounded allot 1514 weight 1 = maxburst 21 20. tc class add dev eth0 classid 2:5 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 5 bounded allot 1514 weight 1 = maxburst 21 21. tc class add dev eth0 classid 2:6 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 6 bounded allot 1514 weight 1 = maxburst 21 22. tc class add dev eth0 classid 2:7 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 7 bounded allot 1514 weight 1 = maxburst 21 23. tc class add dev eth0 classid 2:8 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 8 bounded allot 1514 weight 1 = maxburst 21 24. tc class add dev eth0 classid 2:9 parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 9 bounded allot 1514 weight 1 = maxburst 21 25. tc class add dev eth0 classid 2:a parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 10 bounded allot 1514 weight 1 = maxburst 21 26. tc class add dev eth0 classid 2:b parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 11 bounded allot 1514 weight 1 = maxburst 21 27. tc class add dev eth0 classid 2:c parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 12 bounded allot 1514 weight 1 = maxburst 21 28. tc class add dev eth0 classid 2:d parent 2:0 cbq bandwidth = 10Mbit rate 50Kbit avpkt 1000 prio 13 bounded allot 1514 weight 1 = maxburst 21 29. etc. =20 =20 =20 So here in lines 1, 2, till 14 I made a rood qdisc =93DSMARK=94 and put = in it two =93DSMARK=94 classes for marking 0xb8, and 0x28, etc In lines 15, 16, till 28 I added a =93CBQ=94 =20 Now I have no problem in making filters to classify the incoming traffic = according to their IP header (u32, etc) and to point them to the = =93DSMARK=94 classes 1:1, and 1:2. =20 But I need to reclassify the packets within the =93CBQ=94 again, = according to the mark they had had. The problem here that I tried to use a =93TCINDEX=94 filter =20 E.g. tc filter add dev eth0 parent 2:0 protocol ip prio 1 tcindex handle = 1 tcindex classid 2:1 =20 This filter is supposed to point the traffic with the mark 0xb8 to = classid 2:1 =20 But when I added the rest of the filters to point to the classes 2:2, = 2:3, 2:d .. only some of the filters worked well and the rest didn=92t =20 Also in that =93TCINDEX=94 filter, what value does that handle take? Is = it in hex or decimal or is it just the marking classid or what? =20 =20 BEST REGARDS=20 =20 ------=_NextPart_000_000E_01C2323A.16E3E040 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable 
Referring to =
Differentiated Services on Linux =
<draft-almesberger-wajhak-diffserv-linux-01.txt>

I = read the=20 examples there; they seem to be very helpful. Especially the last two = ones of=20 thee EF

But = in my case=20 I am working on an exterior node (packets are not marked=20 yet)

Here = is a=20 brief description of my problem.

 

 

1.   =20 tc = qdisc add=20 dev eth0 handle 1:0 root dsmark indices 64=20 set_tc_index

2.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:1 dsmark mask 0x3 value=20 0xb8

3.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:2 dsmark mask 0x3 value=20 0x28

4.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:3 dsmark mask 0x3 value=20 0x30

5.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:4 dsmark mask 0x3 value=20 0x38

6.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:5 dsmark mask 0x3 value=20 0x48

7.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:6 dsmark mask 0x3 value=20 0x50

8.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:7 dsmark mask 0x3 value=20 0x58

9.   =20 tc = class=20 change dev eth0 parent 1:0 classid 1:8 dsmark mask 0x3 value=20 0x60

10.     =20 tc = class=20 change dev eth0 parent 1:0 classid 1:9 dsmark mask 0x3 value=20 0x70

11.     =20 tc = class=20 change dev eth0 parent 1:0 classid 1:a dsmark mask 0x3 value=20 0x78

12.     =20 tc = class=20 change dev eth0 parent 1:0 classid 1:b dsmark mask 0x3 value=20 0x88

13.     =20 tc = class=20 change dev eth0 parent 1:0 classid 1:c dsmark mask 0x3 value=20 0x90

14.     =20 tc = class=20 change dev eth0 parent 1:0 classid 1:d dsmark mask 0x3 value=20 0x98

15.     =20 tc = qdisc add=20 dev eth0 handle 2:0 parent 1:0 cbq bandwidth 10Mbit cell 8 avpkt 1000 = mpu=20 64

16.     =20 tc = class add=20 dev eth0 classid 2:1 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 1 bounded allot 1514 weight 1 maxburst 21

17.     =20 tc = class add=20 dev eth0 classid 2:2 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 2 bounded allot 1514 weight 1 maxburst 21

18.     =20 tc = class add=20 dev eth0 classid 2:3 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 3 bounded allot 1514 weight 1 maxburst 21

19.     =20 tc = class add=20 dev eth0 classid 2:4 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 4 bounded allot 1514 weight 1 maxburst 21

20.     =20 tc = class add=20 dev eth0 classid 2:5 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 5 bounded allot 1514 weight 1 maxburst 21

21.     =20 tc = class add=20 dev eth0 classid 2:6 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 6 bounded allot 1514 weight 1 maxburst 21

22.     =20 tc = class add=20 dev eth0 classid 2:7 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 7 bounded allot 1514 weight 1 maxburst 21

23.     =20 tc = class add=20 dev eth0 classid 2:8 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 8 bounded allot 1514 weight 1 maxburst 21

24.     =20 tc = class add=20 dev eth0 classid 2:9 parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 9 bounded allot 1514 weight 1 maxburst 21

25.     =20 tc = class add=20 dev eth0 classid 2:a parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 10 bounded allot 1514 weight 1 maxburst 21

26.     =20 tc = class add=20 dev eth0 classid 2:b parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 11 bounded allot 1514 weight 1 maxburst 21

27.     =20 tc = class add=20 dev eth0 classid 2:c parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 12 bounded allot 1514 weight 1 maxburst 21

28.     =20 tc = class add=20 dev eth0 classid 2:d parent 2:0 cbq bandwidth 10Mbit rate 50Kbit avpkt = 1000 prio=20 13 bounded allot 1514 weight 1 maxburst 21

29.     =20 etc.

 

 

 

So = here in=20 lines 1, 2, till 14 I made a rood qdisc =93DSMARK=94 and put in it two = =93DSMARK=94=20 classes for marking 0xb8, and 0x28, etc

In = lines 15,=20 16, till 28 I added a =93CBQ=94

 

Now = I have no=20 problem in making filters to classify the incoming traffic according to = their IP=20 header (u32, etc) and to point them to the =93DSMARK=94 classes 1:1, and = 1:2.

 

But = I need to=20 reclassify the packets within the =93CBQ=94 again, according to the mark = they had=20 had.

The = problem=20 here that I tried to use a =93TCINDEX=94 filter

 

E.g. = tc filter=20 add dev eth0 parent 2:0 protocol ip prio 1 tcindex handle 1 tcindex = classid=20 2:1

 

This = filter is=20 supposed to point the traffic with the mark 0xb8 to classid=20 2:1

 

But = when I=20 added the rest of the filters to point to the classes 2:2, 2:3, 2:d .. = only some=20 of the filters worked well and the rest didn=92t

 

Also = in that=20 =93TCINDEX=94 filter, what value does that handle take? Is it in hex or = decimal or=20 is it just the marking classid or what?

 

 

BEST = REGARDS=20

 

------=_NextPart_000_000E_01C2323A.16E3E040-- From lumir.unzeitig@gatc.com Tue Jul 23 10:26:18 2002 From: lumir.unzeitig@gatc.com (Lumir Unzeitig) Date: Tue, 23 Jul 2002 11:26:18 +0200 Subject: [LARTC] htb2 with link sharing - the bandwidth dividing question Message-ID: <00b601c2322b$00c331d0$6403a8c0@unzeitig> On Monday 22 July 2002 10:44, Lumir Unzeitig wrote: >> Hi >> I have flat structure of traffic control - 8 children can borrow from a >> parent. >> Problem: The rest bandwidth is not divided to children how I expect. >>I supposed "the rest of bandwidth is divided to the PCs in ratio of their >>RATE values". But it isn't. >But how is the bandwidth divided in your test ? Can be handy to know to >find >a solution/answer ... >And can you post the used htb script? >Stef ====================== 1. Real measurement of bw (also in Calculation in previous mail) In my test the downstream bw was divided: class real bw ---------------------------------------- class 1:10-RATE=4kbit....... 12 kbit/s class 1:40-RATE=4kbit....... 12 kbit/s class 1:80-RATE=15kbit...... 29.6 kbit/s ---------------------------------------- Used bw .................... 53.6 kbit/s 2. HTB script ---------------------- #!/bin/bash # chkconfig: 2345 14 89 # description: sets up HTB traffic control and filters #VLAN ########## BAND=56 #kbit/s BURST=2 VBAND1=4 VBAND2=9 VBAND4=4 VBAND5=6 VBAND6=9 VBAND7=4 VBAND8=15 VBAND9=6 ######### case "$1" in ### START ### start) #Delete a root qdisc #******************** tc qdisc del dev eth0 2>/dev/null #Root handle #************ tc qdisc add dev eth0 root handle 1: htb default 100 tc qdisc add dev eth1 root handle 1: htb default 100 #Class for 56kbps channel #************************ tc class add dev eth0 parent 1: classid 1:1 htb \ rate ${BAND}kbit ceil ${BAND}kbit burst 2k #VLAN #1 - subclass 1:10 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:10 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.1.0/24 flowid 1:10 #qdisc - SFQ tc qdisc add dev eth0 parent 1:10 handle 100: sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:10 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 1 \ fw classid 1:10 #qdisc - SFQ tc qdisc add dev eth1 parent 1:10 handle 100: sfq #VLAN #2 - subclass 1:20 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:20 htb \ rate ${VBAND2}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.2.0/24 flowid 1:20 #qdisc - SFQ tc qdisc add dev eth0 parent 1:20 handle 200 sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:20 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 2 \ fw classid 1:20 #qdisc - SFQ tc qdisc add dev eth1 parent 1:20 handle 200: sfq #VLAN #4 - subclass 1:40 #------------------------- #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:40 htb \ rate ${VBAND4}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.4.0/24 flowid 1:40 #qdisc - SFQ tc qdisc add dev eth0 parent 1:40 handle 400: sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:40 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 4 \ fw classid 1:40 #qdisc - SFQ tc qdisc add dev eth1 parent 1:40 handle 400: sfq #VLAN #5 - subclass 1:50 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:50 htb \ rate ${VBAND5}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.5.0/24 flowid 1:50 #qdisc - SFQ tc qdisc add dev eth0 parent 1:50 handle 500: sfq #Upstrean #Subclass definition tc class add dev eth1 parent 1:1 classid 1:50 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 5 \ fw classid 1:50 #qdisc - SFQ tc qdisc add dev eth1 parent 1:50 handle 500: sfq #VLAN #6 - subclass 1:60 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:60 htb \ rate ${VBAND6}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.6.0/24 flowid 1:60 #qdisc - SFQ tc qdisc add dev eth0 parent 1:60 handle 600: sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:60 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 6 \ fw classid 1:60 #qdisc - SFQ tc qdisc add dev eth1 parent 1:60 handle 600: sfq #VLAN #7 - subclass 1:70 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:70 htb \ rate ${VBAND7}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.7.0/24 flowid 1:70 #qdisc - SFQ tc qdisc add dev eth0 parent 1:70 handle 700: sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:70 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 7 \ fw classid 1:70 #qdisc - SFQ tc qdisc add dev eth1 parent 1:70 handle 700: sfq #VLAN #8 - subclass 1:80 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:80 htb \ rate ${VBAND8}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.8.0/24 flowid 1:80 #qdisc - SFQ tc qdisc add dev eth0 parent 1:80 handle 800: sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:80 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 8 \ fw classid 1:80 #qdisc - SFQ tc qdisc add dev eth1 parent 1:80 handle 800: sfq #VLAN #9 - subclass 1:90 #------------------------------ #Downstream #Subclass definition tc class add dev eth0 parent 1:1 classid 1:90 htb \ rate ${VBAND9}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \ match ip dst 192.168.9.0/24 flowid 1:90 #qdisc - SFQ tc qdisc add dev eth0 parent 1:90 handle 900: sfq #Upstream #Subclass definition tc class add dev eth1 parent 1:1 classid 1:90 htb \ rate ${VBAND1}kbit ceil ${BAND}kbit burst ${BURST}k #Filter tc filter add dev eth1 parent 1: protocol ip prio 1 handle 9 \ fw classid 1:90 #qdisc - SFQ tc qdisc add dev eth1 parent 1:90 handle 900: sfq ;; stop) for dev in `ip link| sed -n '/^[0-9]/ { s/^[0-9]\+: \([a-z0-9]\+\):.*/\1/; p; }'`; do tc qdisc del dev $dev root &>/dev/null done ;; restart) $0 stop $0 start ;; stats) echo ---[ eth0: queueing disciplines ]------------------------- echo; tc -s qdisc show dev eth0; echo echo ---[ eth0: configured classes ]--------------------------- echo; tc -s class show dev eth0; echo echo ========================================================================== echo ---[ eth1: queueing disciplines ]------------------------- echo; tc -s qdisc show dev eth1; echo echo ---[ eth1: configured classes ]--------------------------- echo; tc -s class show dev eth1; echo ;; *) echo "HTB start|stop|restart|stats" ;; esac -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On Behalf Of Stef Coene Sent: Monday, July 22, 2002 4:39 PM To: lumir.unzeitig@gatc.com; lartc@mailman.ds9a.nl Subject: Re: [LARTC] htb2 with link sharing - the bandwidth dividing question _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From radoslav_kolev@smartcom.bg Tue Jul 23 12:21:22 2002 From: radoslav_kolev@smartcom.bg (Radoslav Kolev) Date: Tue, 23 Jul 2002 14:21:22 +0300 Subject: [LARTC] squid marking packets References: <002d01c23220$42b22a70$0d00a8c0@blackwin> Message-ID: <3D3D3C32.2040606@smartcom.bg> > > >--- >Ok, I wasn't entirely sure what you meant - let me summarize and correct >any mistakes I have made? > >1) You use Squid for web traffic. (Is that all web traffic via >transparent proxy, or do some clients not use the Squid cache for web?) >2) You have other traffic as well such as p2p, ftp, cs etc. >3) You wish to rate-limit any web traffic traffic that isn't >already in squid's cache. >4) You wish to rate-limit all other traffic that's not web also. > >If that is the case, then I would make your traffic classifiers handle >all traffic, except for web traffic, and then use squid's delay pools to >accommodate and differentiate between cached and non-cached content. > > >Chris > > > Hi, Chris! You are perfectly right! I use transperant proxy f?r the web traffic. The above lines describe it really well. The problem with your suggestion is that there's no connection between squid and the for example HTB shaper for the other traffic. I want Client X to have 64kbit guranteed bandwidth, and to be able to borrow up to 128kbit if available. My idea was to make the HTB shaper not account packets belonging to connections of squid serving cached pages. I'm not sure, but it seems to me that the easiest way to accomplish this is to make squid mark these packets and let them through at full speed (HTB 1:0 class). All other traffic is classifies and shaped. Thats how i understand your suggestion: make a class for Client X rate 64kbit ceil 128kbit. Then I don't shape packets coming from the proxy machine. But to what values should I limit the bandwidth at squid delay pools? How would squid know that the user is already using his bandwidth playing CS, or doing someting else squid isn't aware of. And vice versa HTB won't know how much bandwidth the user is consuming through squid browsing the web. These problems would be solved if bandwidth is controlled using only one mechanism HTB or delay pools. Since delay pools are limited to only http and possibli ftp, i think using HTB for both is a better choice. Thus I need a way to tell which packets belong to connections served from the cache. Rado From omersuat2002@yahoo.com Tue Jul 23 18:47:39 2002 From: omersuat2002@yahoo.com (Omer suat) Date: Tue, 23 Jul 2002 10:47:39 -0700 (PDT) Subject: [LARTC] A filtering problem In-Reply-To: <20020706121031.GA28710@outpost.ds9a.nl> Message-ID: <20020723174739.1312.qmail@web14804.mail.yahoo.com> --0-851835079-1027446459=:97158 Content-Type: text/plain; charset=us-ascii Hi, I have the following problem. I have followed iproute2 manual, and try to fillter incoming traffic by using u32. But it seems the filtering is not working properly, all the packets are still going default class. # tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell 8 # tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 5Mbit prio 3 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded # tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 100Mbit rate 3Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded # tc qdisc add dev eth0 parent 1:1 tbf rate 1Mbit buffer 10Kb/8 limit 15Kb mtu 1500 # tc qdisc add dev eth0 parent 1:1 tbf rate 1Mbit buffer 10Kb/8 limit 15Kb mtu 1500 # tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.20.21.14/32 flowid 1:1 # tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.20.21.13/32 flowid 1:2 Both class 1 & 2 (1:1, 1:2) are not getting any traffic Is there any thing am I missing. Thanks in advance --------------------------------- Do You Yahoo!? Yahoo! Health - Feel better, live better --0-851835079-1027446459=:97158 Content-Type: text/html; charset=us-ascii

Hi,

I have the following problem.

I have followed iproute2 manual, and try to fillter incoming traffic by using u32. But it seems the filtering is not working properly, all the packets are still going default class.

# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell 8

# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit  rate 5Mbit prio 3 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded

# tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 100Mbit  rate 3Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded

# tc qdisc add dev eth0 parent 1:1 tbf rate 1Mbit buffer 10Kb/8 limit 15Kb mtu 1500

# tc qdisc add dev eth0 parent 1:1 tbf rate 1Mbit buffer 10Kb/8 limit 15Kb mtu 1500

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.20.21.14/32 flowid 1:1

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.20.21.13/32 flowid 1:2

Both class 1 & 2 (1:1, 1:2) are not getting any traffic

Is there any thing am I missing.

Thanks in advance

 

 

 


Do You Yahoo!?
Yahoo! Health - Feel better, live better --0-851835079-1027446459=:97158-- From raptor@unacs.bg Tue Jul 23 19:27:15 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Tue, 23 Jul 2002 21:27:15 +0300 Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <20020722200325.07AF0DC4DD@tartarus.telenet-ops.be> References: <20020722224157.257560e0.raptor@unacs.bg> <20020722200325.07AF0DC4DD@tartarus.telenet-ops.be> Message-ID: <20020723212715.28524b8d.raptor@unacs.bg> This is a multi-part message in MIME format. --Multipart_Tue__23_Jul_2002_21:27:15_+0300_08294fd0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit | |I have a drawing that was posted once on this list. You can find it on |www.docum.org under KPTD. Plz feel free to send me updates. OK. I've made the diagram in Dia (attached). U can easly export it in any format (any linux distro have Dia, i think)... I made some changes may be they are wrong, pls correct me... I thought that all "mangle" and "nat" stuff should be "IPTABLES", and all "ipchains" suff should go away !! ? - What is "mark-rewrite" ?! - there is something which have to be added somewhere around "forwarding", can't figure out what/where ?! Pls do it, or tell me i wil do it? - in my opinion (6a.3) output-routing should go at the place of (7) !!! 'm I right ? raptor@unacs.bg --Multipart_Tue__23_Jul_2002_21:27:15_+0300_08294fd0 Content-Type: application/octet-stream; name="24net.dia" Content-Disposition: attachment; filename="24net.dia" Content-Transfer-Encoding: base64 H4sIAAAAAAAAA+2dW2/buBKA3/MrvNmXBmgY8U5utl3spV0ssNj2pCkOsC+BYiuxTh3LkJWmOQ/n t5+hpCS+SbFNUt4kLJC2lhmNRhrymyE5ox9/+nY16n1N8mmajd/sYxTt//R278dBGv8AP5d5fNWD BuOp+fRmf1gUkx+Ojm5ubtDodhoXWY5G6TWaJkf/i0ej+AgaHe2/3ev1Zk8wiIvYHKuPxkWRp+fX RdIbx1fJm/3zuP/lMs+ux4P9qlXdrp+Nsrz3NR692f/+ovyzf1Sf5mjuPC3nnsSTJF887dUkm6bQ pLidLDVpOI/5e6ZN3WoKjcaXb7//mX1fXVJ94OFcqy60UUhxFeeX6XhZTp7Eo+pGEKQIIXf3YXMR 5/5FjPyLyP2LSKdnkywv8jgtlsWcZ9koiceVpCK/TraXM+3HIzCZNlXw9me/SIsie+T6L+LRdB0F qsP3vWfTnniZp4P2jjjXouEsN+mgGJ5983S7qrPfejr713Sano+SVVefjgtnp7+1PL3tc75OB8n0 kSc936bhTMO62dFjii+2W1eD6tACpEoRo/g2yevT//KAp159j+tOP3MXsvP/JP2iVu/9KLvpD+O8 6B32fsm+7T/QNdrvpYM3+x+i+fuzqBGcDUafpRs0ye4f5CHGEeIKvz6UCjG+qPvyQ20Sc36+KCUH ReLx5SiZkSRoJYkfH2qGFNbwiSO8pdxklFyd9bN8vMxd1yqWospuvazmfZfmSGJicf5hkl4Oi2YB FJEtL386zG7OVvhHj3NoEymTeDCYZ9CCAvActjtzkXxbui+Lg8FCm6Y7UXpWc+0WnLBX+ODjybuT D59P//jr9710UsTQUw+vSlN+BQ7Dl16e3OQg96DBWWsZcJvwmo2LVZdkjtdNfs2u8xTs/MhGzpKB rXxGyk7I/ICzukdGBEnCoUcKpGlE7QSW/v0qkbOOf1T+sRMEHtbl+CpZ/ayS8fXVCji20XcVXpoQ efRAh+1xge1xEWlwiM2TYwgrLr0Cw8iSlSxCuQRmcMTLA2Ckkmm/1HCi6VrcAPX8UkNEMoDDPzjI KnCM4+IVeJVFoIY7ahAkRCQCNbqhBnFADYEiBk9OaKSJ3yjDiNK1KGniDI0oN58FEp6B4UDJdXgB ijC/vAi06IAW9OD9H3+evjsBUkD/S8fT774LaLBFg1CIaqICGrpBA3USUHBJ4clx4+z7jicEqUTB AF2GE4pI+EwQ596DCWst14olKBJaBDo8eTqwAwgiTt59+rT3r+zTqz6M2zncnkHv/LZ3+muIIexB wRBlARRdgYI5AQUlGJ5cZJ6gb1BQWYsqYwjw7KV+fcglYt45Ya3kmpzAmgROPHlOcODEx8+ne6/g XhXJgfkbvugNkn5qemAAhS0ouDY9JYCiI1BwByvaAqmIwJMTiEeE+F3TBlm8lsUJOa6CjEjBERhh pSSeV7ZdqLoOLyTCLEw6PX1ciBjhmhj1AkUgxLaEAB/KzCZwhrQMeOgGD8IhHgiilIpu8ACyFBUz eGAaRZESHeHBRtWAhxeFB3IwyvrxaG+SZ/1kOg14sMUDCIswC4DoBhDSASAkijiDIVohLLbdZbQu IGDkjCpZBDNdAYJyAUcYUlR73uPkRNX1ACGYCoB4DoCgBx8+n5oAop5rCoSwJAQTSFASQoiOCKGc EIJz48RTpLWgvglRBQwMRUxQQwhVBRUsQkJi6p0Q9qquQwiFBA8L18+CEOyOEPPJEwEUtqAgiAmG Ayi6AYV2F0pQk0sgRSehhJElpZgJJWi5OiC6CSWsVA2hxIsCBV8ExTguAiUsKUEVIpqHCaeucuoi h5jg4ASrbmacQJaM1OyMEy1XCTqacbJSNWDiRWFCLGAiIMIWEQxhIsKMU1eIsM+71qZKBozRHCPi mRAgikSVKFoCQgmky0UCibRvPjjRc73pJszD/tdngIdzhA/efzj5988nvwU+WPJBY1TvTZEBD93h wUWCNUOSYyB7hLBkfve8giwVVbIIYeT4UJs1Avn6kAikmPa85dWJpmFP08shhFzOsw6J1tunRWDo dhr6uoL4mgREdIQIF4nWCkUm25mY7GffiABZspYlS0QwREwJPkIQ194R4ULTkG39ghihDj5++HS6 qnTTNO+Hyk3uqMFMeY5AjY6owdxUbsJm4MZICs9LE0aWqGQpbGaetEBEw0COFWLM98qEE03XoYZG IhRwegbQ0AfvHip0hKIcLvAQIULDxJMbPnyCwXUQ5wPAw5/pOFnFBwfJ1vc1GTnyHFLMCDp2Ibef jcdnyXhQqrONkn5uB9hNf7J4NasK77ed1OgGNxCe9nRpNLz7pjcE+zA16MEciqwsJt97+NYEN0uq rvhl/Pgv3xn2wiU5smHxxGxY1oJ4ZcSiLnCM6bYlhv3asU3x4ydqynj+l0lXliwdWnJkZj50N8Yc mTkePWPOQm9f5G4ba15UtrXul0Vx1t3ZM7axZ7Ije1bu7NkU7+WdWDNIkrOmbEpEdmfKC3q2NrWo JLk7QyY2hkx3ZMjaoSETJLqxYxA062IIkyzWoSHP6dna0qLS3e7smNrYMfNsx3+nl3/Hlw3WTCJ3 pRi5RpHvor1my6KqyrAxTqvtysQUZ7Qr75UXw7N17LlJ08caa07bG9+Vh9ikrbXGWZ7Oz1e0zVUs fBe1fOezqy30FrlJT+M77WkOtn0KhInupKMZUVLPdDSzGYza7jhdr5s1qvlI28c6Tr2fbZOm1to+ gy6mNoqWdxQuEwe75u7GVfiHSNIJxszijDQTmKYCrypLcxG1bWmuDRyzJlXb2tpUDduda8ZtXDPh 2ZhPzeLTCmN2sL8Hg0MtKocac+29rh1ntC6QrXVVlEIrWY61VG5btqjL5btJ3P+SFL102tu7yPJe MYT/xYNB/nxrnskO8ouabDAs5DlZyGsaPuw3emiCIsyrLk08Dx/gwjHOVClLlcOHkubFjpWrxp7i 8BGPs2KY5GEEsc1AaTTDMIL43ApAuDNv2lS25Up04U2DKHA8xIM3beoY4m3XvTb3ppdUbWtrU2Jx d960sPGm5Y5CQ+HOmBlSSutOjJkhTUtf+s6YKdJs25JrWxjzoqptbW2qwe3OmKWNMasdGbN0Z8xm qQXTTozZBIaYPhgz1XBAdjbPsaRqWzUEm4pVuzNmZWPMekfGrJwZMy3fuNKJmwGiRERm3AxTvCZS nbkZS6q2tbWpq7M7Y9ZWG7ainS7zaHc2Xb4mohNvoxZ1XCVUm3RuYpNkse56apOiLW3NdenH2t5l hW/amM9tN38Riz3YbnMkaVyO7aCvUfvNC3c1LiTSnrualjAUy3tR9yuq9ma3xopqg5bNTU1Cd0Rk e1NTi1pu3PYldjLsspOpjtwzih3sDbrL5RFIbZ3pve5mN4wIqWRppsu0EFztDiBmdyTrIDOkSdvW xjZ56TvchGy1eRPvaPcmJQ5tmiDBurJpkKXnbRojiTuIOhq1bW1skzW7Q5u22siJvezknE3s/i3r X5frCisM20VNEIq4APhjgRjW1HfZqEiTUpZm1GwwU4hAFA1HKBga9/1mbReqrpPebd7bxDH2mOBN EGFa/6NTvC9G6eRsCJ7bf7NxEY9apVzEo6mNGOgZRdr3J2SNdHXKKef0n79q/VdS3GT5l5CpbpOp zmEQ4Wand3gTh/NCJm28c1HNhJvCx68PFUFYc8+8MzOxpSgJvAHcafCQBOBOasQI9o07F5oG3AXc Bdy9ZNwR85IIGEUw+O4y8K6j3VjUUWGW8tFFiAihOkk6BVkUC1WnnZr9nFIh1knS6UpVW6sGwJU9 vbTThQmH+fdKb1ijpbMZOOFuBg4vru95nIEDWZxVS6QgvZw5oELTzubf8FprmXVAYjOrscPpN2ZV D4D6nn77mCeD5ALMegD/zfrJdLrKvl0UbpGIUVLmH3IceS4RIJEu37FBUESZKCfitGSs3M9K5bae 9tqRiQtV1yvgrilVPt8Bhc0S57axT4hMXnBkcj1N8t50EvfDy0q2D04oYmaGhUfAPhJeeNhVcKKc FBApwwN4dEIL7Bd3uooOQJbkEh+XBKKKVNLZttI3ceiatG3FI1xuJPETzxfZqJQAXdifLzb256rP o/g2yd/uVR/g5zKPr97u/R87Jux2obgAAA== --Multipart_Tue__23_Jul_2002_21:27:15_+0300_08294fd0-- From stef.coene@docum.org Tue Jul 23 19:49:00 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 23 Jul 2002 20:49:00 +0200 Subject: [LARTC] htb2 with link sharing - the bandwidth dividing question In-Reply-To: <00b601c2322b$00c331d0$6403a8c0@unzeitig> References: <00b601c2322b$00c331d0$6403a8c0@unzeitig> Message-ID: <20020723184901.029AEDB9AC@tartarus.telenet-ops.be> > 1. Real measurement of bw (also in Calculation in previous mail) (Sorry, missed that in the prevois mail) > In my test the downstream bw was divided: > class real bw > ---------------------------------------- > class 1:10-RATE=3D4kbit....... 12 kbit/s > class 1:40-RATE=3D4kbit....... 12 kbit/s > class 1:80-RATE=3D15kbit...... 29.6 kbit/s > ---------------------------------------- > Used bw .................... 53.6 kbit/s So class 1:10 and 1:40 get's more bandwidth then they should. =20 Actually, the remaining bandwidth is not divided proportional to the rate= ,=20 but to quantum. Quantum is calculated as rate / r2q with 2rq =3D 10. Bu= t you=20 can overrule r2q when you add the htb qdisc and you can overrule quantum = per=20 class. I have more info on www.docum.org, under FAQ, HTB, quantum. If rate =3D 4kbit/s and r2q =3D 10, then quantum =3D 4kbit/10 =3D 400 byt= e If rate =3D 15kbit/s and r2q =3D 10, then quantum =3D 15kbit/10 =3D 1500 = byte Each class can send an amount of bytes equal to it's quantum. But a pack= et=20 is most of time bigger then 400 byte so for the 4kbit class, more bytes a= re=20 sended then allowed and there is no payback Solution : decrease quantum so the smallest quantum is big enough to send= the=20 bigest packet. So setting r2q =3D 2 will give better results. tc qdisc add dev eth0 root handle 1: htb default 100 r2q 2 You will also find some errors in the log file about htb that's complaini= ng=20 that the quantum is too small. This is triggered because you want to sen= d a=20 packet that's bigger then the quantum. After decreasing the r2q parameter, these errors should disappear. The default r2q parameter is OK for classes with rates > 15kbit/s. (thx to Devik to explain me this some time ago) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Tue Jul 23 20:06:00 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 23 Jul 2002 21:06:00 +0200 Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <20020723212715.28524b8d.raptor@unacs.bg> References: <20020722224157.257560e0.raptor@unacs.bg> <20020722200325.07AF0DC4DD@tartarus.telenet-ops.be> <20020723212715.28524b8d.raptor@unacs.bg> Message-ID: <20020723190601.40C21DC763@tartarus.telenet-ops.be> On Tuesday 23 July 2002 20:27, raptor@unacs.bg wrote: > |I have a drawing that was posted once on this list. You can find it o= n > |www.docum.org under KPTD. Plz feel free to send me updates. > > OK. I've made the diagram in Dia (attached). U can easly export it in a= ny > format (any linux distro have Dia, i think)... > > I made some changes may be they are wrong, pls correct me... I thought = that > all "mangle" and "nat" stuff should be "IPTABLES", and all "ipchains" s= uff > should go away !! ? Ipchains is still available in the 2.4 kernel. > - What is "mark-rewrite" ?! Don't know. > - there is something which have to be added somewhere around "forwardin= g", > can't figure out what/where ?! Pls do it, or tell me i wil do it? - in = my > opinion (6a.3) output-routing should go at the place of (7) !!! 'm I ri= ght > ? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From raptor@unacs.bg Tue Jul 23 20:29:08 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Tue, 23 Jul 2002 22:29:08 +0300 Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <20020723190601.40C21DC763@tartarus.telenet-ops.be> References: <20020722224157.257560e0.raptor@unacs.bg> <20020722200325.07AF0DC4DD@tartarus.telenet-ops.be> <20020723212715.28524b8d.raptor@unacs.bg> <20020723190601.40C21DC763@tartarus.telenet-ops.be> Message-ID: <20020723222908.4ccd6981.raptor@unacs.bg> |> I made some changes may be they are wrong, pls correct me... I thought that |> all "mangle" and "nat" stuff should be "IPTABLES", and all "ipchains" suff |> should go away !! ? |Ipchains is still available in the 2.4 kernel. ]- Yes but it is just module that runs on top of iptables, afaik ? i.e. it uses iptables infrastructure raptor@unacs.bg From stef.coene@docum.org Tue Jul 23 21:35:14 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 23 Jul 2002 22:35:14 +0200 Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <20020723222908.4ccd6981.raptor@unacs.bg> References: <20020722224157.257560e0.raptor@unacs.bg> <20020723190601.40C21DC763@tartarus.telenet-ops.be> <20020723222908.4ccd6981.raptor@unacs.bg> Message-ID: <20020723203515.EC461DC763@tartarus.telenet-ops.be> On Tuesday 23 July 2002 21:29, raptor@unacs.bg wrote: > |> I made some changes may be they are wrong, pls correct me... I thoug= ht > |> that all "mangle" and "nat" stuff should be "IPTABLES", and all > |> "ipchains" suff should go away !! ? > | > |Ipchains is still available in the 2.4 kernel. > > ]- Yes but it is just module that runs on top of iptables, afaik ? i.e.= it > uses iptables infrastructure Mhh. I'm not a kernel specialist, but I thought there was still some=20 ipchains code in the 2.4 kernel. Staf =20 --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From tobias.geiger@web.de Tue Jul 23 21:35:20 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Tue, 23 Jul 2002 22:35:20 +0200 (CEST) Subject: [LARTC] failover problems Message-ID: <24863.213.164.67.210.1027456520.squirrel@kaeptnb.d2g.com> Hello LARTC, I'm testing Failover and i'm getting this problem: In the moment the device gets deleted (dissapears from /proc/net/dev) e.g. pppd crashes all RULES regarding this device are flushed. Is this a known bug/problem (i think so :) is there a workaround/solution (except adding the rules again in ip-up.d) ? Thanks in advance Tobias From tobias.geiger@web.de Tue Jul 23 21:55:54 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Tue, 23 Jul 2002 22:55:54 +0200 (CEST) Subject: [LARTC] failover problems In-Reply-To: <24863.213.164.67.210.1027456520.squirrel@kaeptnb.d2g.com> References: <24863.213.164.67.210.1027456520.squirrel@kaeptnb.d2g.com> Message-ID: <24896.213.164.67.210.1027457754.squirrel@kaeptnb.d2g.com> addition: to be precisly: the problem is i have several nexthops (e.g. ppp0 +eth1 +eth2) for the same route and this WHOLE Route is deleted, although only the ppp0-device dissapears... and i cannot add several entries in different tables, cause this seems not to do failover > Hello LARTC, > > I'm testing Failover and i'm getting this problem: > > In the moment the device gets deleted (dissapears from /proc/net/dev) > e.g. pppd crashes all RULES regarding this device are flushed. > Is this a known bug/problem (i think so :) > is there a workaround/solution (except adding the rules again in > ip-up.d) ? > > Thanks in advance > > Tobias > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From ja@ssi.bg Wed Jul 24 01:13:59 2002 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 24 Jul 2002 00:13:59 +0000 (GMT) Subject: [LARTC] failover problems In-Reply-To: <24896.213.164.67.210.1027457754.squirrel@kaeptnb.d2g.com> Message-ID: Hello, On Tue, 23 Jul 2002, Tobias Geiger wrote: > to be precisly: the problem is i have several nexthops (e.g. ppp0 +eth1 > +eth2) for the same route and this WHOLE Route is deleted, although only > the ppp0-device dissapears... > and i cannot add several entries in different tables, cause this seems not > to do failover Yes, similar behavior appeared in latest 2.4.19pre kernels, it looks like a recommendation the users to recreate their routes because a device in nexthop was unregistsred. Is this true for your setup? Regards -- Julian Anastasov From mahhy@undertow.ca Wed Jul 24 13:11:09 2002 From: mahhy@undertow.ca (mahhy) Date: Wed, 24 Jul 2002 08:11:09 -0400 (EDT) Subject: [LARTC] TC bug? Mixing u32 and FW filters. In-Reply-To: Message-ID: I've noticed some strange behaivour in tc and can't seem to find a definate "this is a bug" or "this is not a bug". Figured I'd ask the list. I'm using HTB2 and HTB3, on different machines. This happened on both of them. I've created a few different classes and quite a few filters. All of my filters were previously u32 filters. (wont bother posting the exact script, its fairly long, works on 3 separate interfaces, etc) I started to mark FTP packets using iptables (trying for both active and passive ftp), which seems to work fine. When I added a FW filter: /sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 handle 5 fw classid 1:24 I got the infamous: RTNETLINK answers: Invalid argument After a few hours of experimentation, I realized that if I changed the filters PRIO to something not used by one of the u32 filters, all went well. i.e.: /sbin/tc filter add dev eth1 protocol ip parent 1: prio 5 handle 5 fw classid 1:24 Has anyone seen this before? Anyone know if it is definately a bug or not? Or is it something very strange specific to my setup? -- Rob Rankin mahhy@undertow.ca http://undertow.ca From mehak mehak" hi, > > i am working on the diffserv implementation in linux. > i am new to this work and first time i am working on red hat along > with diffserv tech. > > i have compiled my kernel with the proper compilation of the > iproute2 utility. > > now i want to set the diffserv enviorment with the help of tc.i > have studied the method of described in > > http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/bmeter.html > > will u please tell me how to do.whether i am going fine. > > which steps i should take care of so that minimum problems will > come.OR TELL ME WHICH IS THE BETERR WAY TO CHECK THAT DIFFSERV IS WORKING PROPERLY IN UR LINUX SYSTEM WITH TC AND IP OR I NEED SOMETHING ELSE > > please ans this as soon as possible. > > regards > mehak > From tobias.geiger@web.de Wed Jul 24 17:46:37 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Wed, 24 Jul 2002 18:46:37 +0200 (CEST) Subject: [LARTC] failover problems In-Reply-To: References: <24896.213.164.67.210.1027457754.squirrel@kaeptnb.d2g.com> Message-ID: <26031.213.164.67.210.1027529197.squirrel@kaeptnb.d2g.com> > > Hello, > > On Tue, 23 Jul 2002, Tobias Geiger wrote: > >> to be precisly: the problem is i have several nexthops (e.g. ppp0 >> +eth1 +eth2) for the same route and this WHOLE Route is deleted, >> although only the ppp0-device dissapears... >> and i cannot add several entries in different tables, cause this seems >> not to do failover > > Yes, similar behavior appeared in latest 2.4.19pre kernels, > it looks like a recommendation the users to recreate their routes > because a device in nexthop was unregistsred. Is this true for > your setup? > Yes. i used 2.4.19pre-10 kernel. This behaviour affects only ppp-devices (never tried ippp but i guess it's the same) i also wondered, why failover doesn't work when using different route-entries for each nexthop... another confusing thing: using "nexthop via dev ppp0" in a table made me think that i don't need a gateway address at all... but unfortunatly that's no the case :(seems that ip searches the gateway address itself so that after appp-reconnect (where i get another gateway address) the table-entries aren't valid anymore. Thanks Tobias From stef.coene@docum.org Wed Jul 24 15:07:52 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 24 Jul 2002 16:07:52 +0200 Subject: [LARTC] LARTC digest, Vol 1 #689 - 13 msgs (fwd) In-Reply-To: <200207222054.g6MKsJK15974@stimpy.networkrobots.com> References: <200207222054.g6MKsJK15974@stimpy.networkrobots.com> Message-ID: <20020724173500.70C4CDBF7C@tartarus.telenet-ops.be> > > guess it's a small bug in the patch for tcng. > > I thought that it is required: > tc qdisc add dev eth0 handle 2:0 parent 1:0 htb default 5 r2q 100 > =09=09=09=09=09 ~~~~~~~ The default parameter is not required for htb. I have only experience in= =20 creating htb scripts and I don't know if the tcng generated syntax is bug= =20 free. The tcng config you include seems OK to me. But don't trust me on that := ) Stef > > dev "eth0" { > egress { > $base =3D 100 * 1kBps; > > class (<$cl1_2>) if ((raw[6] & 0xfe) =3D=3D 0); > class (<$cl1_12>) if (raw[6] =3D=3D 2); > class (<$cl1_10>) if (raw[6] =3D=3D 0); > class (<$cl1_11>) if (raw[6] =3D=3D 1); > > > htb (r2q 100) { > =09class(rate 10 * $base) { > =09$cl1_2 =3D class (rate 4 * $base, ceil 8 * $base,) { > =09=09$cl1_10 =3D class (rate 3 * $base, ceil 10 * $base, prio 1) { f= ifo(limit > 8p); } $cl1_11 =3D class (rate 1 * $base, ceil 10 * $base, prio 0) { > fifo(limit 8p); } } > =09} > =09$cl1_12 =3D class (rate 6 * $base, ceil 10 * $base, prio 1, default= ) { > fifo(limit 8p); } } > } > } > > # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Device eth0 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > tc qdisc add dev eth0 handle 1:0 root dsmark indices 8 default_index 0 > tc qdisc add dev eth0 handle 2:0 parent 1:0 htb default 5 r2q 100 > tc class add dev eth0 parent 2:0 classid 2:1 htb rate 1000000bps > tc class add dev eth0 parent 2:1 classid 2:2 htb rate 400000bps ceil > 800000bps tc class add dev eth0 parent 2:2 classid 2:3 htb rate 300000b= ps > ceil 1000000bps prio 1 tc qdisc add dev eth0 handle 3:0 parent 2:3 pfif= o > limit 8 > tc class add dev eth0 parent 2:2 classid 2:4 htb rate 100000bps ceil > 1000000bps prio 0=20 tc qdisc add dev eth0 handle 4:0 parent 2:4 pfifo limit 8 > tc class add dev eth0 parent 2:0 classid 2:5 htb rate 600000bps ceil > 1000000bps prio 1=20 tc qdisc add dev eth0 handle 5:0 parent 2:5 pfifo limit 8 > tc filter add dev eth0 parent 2:0 protocol ip prio 1 tcindex mask 0x7 s= hift > 0=20 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 4 tcindex > classid 2:4 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle= 3 > tcindex classid 2:3 tc filter add dev eth0 parent 2:0 protocol ip prio = 1 > handle 2 tcindex classid 2:5 tc filter add dev eth0 parent 2:0 protocol= ip > prio 1 handle 1 tcindex classid 2:2 tc filter add dev eth0 parent 1:0 > protocol ip prio 1 handle 1:0:0 u32 divisor 1 tc filter add dev eth0 pa= rent > 1:0 protocol ip prio 1 u32 match u8 0x0 0xfe at 6 classid 1:1 tc filter= add > dev eth0 parent 1:0 protocol ip prio 1 u32 match u8 0x2 0xff at 6 class= id > 1:2 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u8 0= x0 > 0xff at 6 classid 1:3 tc filter add dev eth0 parent 1:0 protocol ip pri= o 1 > u32 match u8 0x1 0xff at 6 classid 1:4 > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From ja@ssi.bg Wed Jul 24 22:44:54 2002 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 24 Jul 2002 21:44:54 +0000 (GMT) Subject: [LARTC] failover problems In-Reply-To: <26031.213.164.67.210.1027529197.squirrel@kaeptnb.d2g.com> Message-ID: Hello, On Wed, 24 Jul 2002, Tobias Geiger wrote: > Yes. i used 2.4.19pre-10 kernel. > This behaviour affects only ppp-devices (never tried ippp but i guess it's > the same) > > i also wondered, why failover doesn't work when using different > route-entries for each nexthop... Hm, the kernel can not perform failover for NOARP devices that are always in UP state. It is possible only for ARP devices and for default routes with same metric. But if the first route is automatically deleted from kernel the 2nd one will be used. No? > another confusing thing: using "nexthop via dev ppp0" in a table made me > think that i don't need a gateway address at all... but unfortunatly > that's no the case :(seems that ip searches the gateway address itself so > that after appp-reconnect (where i get another gateway address) the table-entries > aren't valid anymore. The "via GW" syntax is not mandatory for ppp devices, you can use only "nexthop dev ppp0", just remove this "via", you have syntax error. As for ppp devices, it is recommended your scripts to recreate the multipath routes to contain nexthops only for valid ppp devices (for which you have established link). As you see, the new kernels delete the multipath route for you, so you can't rely on permanent multipath route (I assume the ppp devices really pass unregistration). Even in the old kernels you have to recreate the route because when one ppp devices is registered again its nexthop status does not change, it remains dead. > Thanks > > Tobias Regards -- Julian Anastasov From he@fli4l.de Wed Jul 24 21:08:37 2002 From: he@fli4l.de (Hannes Ebner) Date: Wed, 24 Jul 2002 22:08:37 +0200 Subject: [LARTC] Matching packet size Message-ID: <3D3F0945.1050405@fli4l.de> Hi, In the ACK-matching example in the LARTC-HOWTO there is a line to match all packets smaller than 64 bytes ("match u16 0x0000 0xffc0 at 2"). This sounds logical for Ethernet-devices, but what if I use a PPP-device (as it is shown in the example)? The Frame-Header of PPP is significant smaller than the header of Ethernet, does this affect the matching of the relevant packets with the ACK-bit set? Additional question: If I want to match packets smaller than 128 bytes, would "match u16 0x0000 0xff80 at 2" do the thing? Regards, Hannes -- GnuPG Key-ID: 0x49360B78 From kphanse@vt.edu Wed Jul 24 22:09:11 2002 From: kphanse@vt.edu (Kaustubh S. Phanse) Date: Wed, 24 Jul 2002 17:09:11 -0400 Subject: [LARTC] Changing the QoS for a given flow Message-ID: <002301c23356$5be280d0$87c211d0@ari.vt.edu> This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C23334.D4D0E0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, I am trying to set-up a scenario wherein a given traffic flow gets certain QoS to begin with, and then is moved to another QoS class. Using Linux RH7.0 kernel 2.2.16. I tried doing this using the "tc filter change" and "tc filter replace" commands, but both don't seem to work. An example scenario is as follows: ***** Initial set-up **** tc qdisc add dev eth0 handle 1:0 root htb default 1 r2q 1 tc class add dev eth0 parent 1:0 classid 1:1 htb rate \ 64kbit ceil 64kbit burst 2k tc qdisc add dev eth0 parent 1:1 handle 2:0 dsmark indices 64 tc class change dev eth0 classid 2:1 dsmark mask 0x3 value 0x68 tc class change dev eth0 classid 2:2 dsmark mask 0x3 value 0x48 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 1: \ u32 divisor 1 tc filter add dev eth0 parent 2:0 prio 1 u32 \ match ip src 10.0.41.2 match ip protocol 17 0xff match ip dport 5000 0xffff flowid 2:1 As shown above, initially the flow is marked with DSCP value 0x68 (confirmed using ethereal). Later, I need to move this flow to class 2:2, so that it gets marked with value 0x48. Using, "tc filter replace" to now classify the flow as 2:2 doesn't work, as the packets are still marked as 0x68. Doing "tc filter show dev eth0" returns nothing! I am not sure what I am doing wrong. Any help in this matter is appreciated. Thanking in advance. regards Kaustubh ------=_NextPart_000_0024_01C23334.D4D0E0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 everyone,
 
    I am trying to set-up a scenario wherein a given traffic flow = gets=20 certain QoS to begin with, and then is moved to another QoS class. Using = Linux=20 RH7.0 kernel 2.2.16. I tried doing this using the "tc filter change" and = "tc=20 filter replace" commands, but both don't seem to work. An example = scenario=20 is as follows:
 
***** = Initial set-up=20 ****
 
tc = qdisc add dev=20 eth0 handle 1:0 root htb default 1 r2q 1
tc class add dev eth0 parent = 1:0=20 classid 1:1 htb rate \
 64kbit ceil 64kbit burst 2k
tc qdisc = add dev=20 eth0 parent 1:1 handle 2:0 dsmark indices 64
tc class change dev eth0 = classid=20 2:1 dsmark mask 0x3 value 0x68
 
tc = class change dev=20 eth0 classid 2:2 dsmark mask 0x3 value 0x48
 
tc = filter add dev=20 eth0 parent 2:0 protocol ip prio 1 handle 1: \
 u32 divisor=20 1
 
tc = filter add dev=20 eth0 parent 2:0 prio 1 u32 \
 match ip src = 10.0.41.2
 match ip=20 protocol 17 0xff
 match ip dport 5000 = 0xffff
 flowid=20 2:1
 
As = shown above,=20 initially the flow is marked with DSCP value 0x68 (confirmed using = ethereal).=20 Later, I need to move this flow to class 2:2, so that it gets marked = with value=20 0x48. Using, "tc filter replace" to now classify the flow as 2:2 doesn't = work,=20 as the packets are still marked as 0x68. Doing "tc filter show dev eth0" = returns=20 nothing! I am not sure what I am doing wrong. Any help in this matter is = appreciated.
 
Thanking in=20 advance.
regards
Kaustubh
------=_NextPart_000_0024_01C23334.D4D0E0D0-- From eng01050@hotmail.com Thu Jul 25 03:31:12 2002 From: eng01050@hotmail.com (Alfred Quah) Date: Thu, 25 Jul 2002 02:31:12 +0000 Subject: [LARTC] (no subject) Message-ID: Hi, I'm currently doing some test on HTB and realised that cburst is a very important parameter that will shapes the throughput of the traffic. Also I realise that if all the traffic are given the same priority in HTB, there is a lot of pertubations in the bandwidth consumed by each traffic. As a result, the rate and ceil are not well-managed. Why is this so. I'm useing HTB2 code that i have downloaded from the home page. Is it because of the bug that is in HTB2?. Please Help! Confused Alfred _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From leoball@opalsoft.net Thu Jul 25 03:54:10 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Wed, 24 Jul 2002 22:54:10 -0400 Subject: [LARTC] linux NETWORKING diagram ? Message-ID: <5.1.0.14.1.20020724214151.00a16e10@opalsoft.net> Hi. You wrote: > OK. I've made the diagram in Dia (attached). U can easly export it in any format > (any linux distro have Dia, i think)... Could you post your diagram in ascii? > I made some changes may be they are wrong, pls correct me... I thought that all > "mangle" and "nat" stuff should be "IPTABLES", and all "ipchains" suff should go > away !! ? As I understand there is some ipchains original code running on iptables; but not iptables code to emulate ipchains behavior, just ipchains filter code. Have a look to LARTC digest, Vol 1 #641, #642, #651, #652 and #655. > - What is "mark-rewrite" ?! It would be better "mark-write". It's mark packet writing in mangle table (fwmark). This mark survive just inside host or router that makes the mark (the packet is not really marked when it leaves the router). > - there is something which have to be added somewhere around "forwarding", can't > figure out what/where ?! Pls do it, or tell me i wil do it? > - in my opinion (6a.3) output-routing should go at the place of (7) !!! > 'm I right ? I haven't your diagram. BTW, diagram misses some hooks (must be added): conntrack PREROUTING just before mangle PREROUTING. conntrack INPUT after filter INPUT but before LOCAL PROCESS. mangle INPUT after conntrack INPUT also before LOCAL PROCESS. mangle FORWARD before filter FORWARD. conntrack OUTPUT before mangle OUTPUT but after OUTPUT ROUTING. mangle POSTROUTING before nat POSTROUTING. conntrack POSTROUTING after nat POSTROUTING but before QOS EGRESS. when discussion matures I will post this changes to Stef. Best regards, Leonardo Balliache From stef.coene@docum.org Thu Jul 25 06:52:32 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 25 Jul 2002 07:52:32 +0200 Subject: [LARTC] (no subject) In-Reply-To: References: Message-ID: <20020725055233.8B20FDB966@tartarus.telenet-ops.be> On Thursday 25 July 2002 04:31, Alfred Quah wrote: > Hi, > I'm currently doing some test on HTB and realised that cburst is a very > important parameter that will shapes the throughput of the traffic. Als= o I > realise that if all the traffic are given the same priority in HTB, the= re > is a lot of pertubations in the bandwidth consumed by each traffic. As = a > result, the rate and ceil are not well-managed. Why is this so.=20 Can you post the script you use to test this? There are other parameters= who=20 are also important and that can explain the behaviour you get. And also = the=20 results why you think there is a problem. cburst is indeed an important paramater. Ideal, cburst =3D packet size. = So=20 there is no burst on the ceil and you _never_ exceed the burst. But you = can=20 make surfing more attractive by allowing a cburst so small pages/images a= re=20 loaded very quickly. > I'm useing > HTB2 code that i have downloaded from the home page. Is it because of t= he > bug that is in HTB2?. Please Help! I don't think so. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From raptor@unacs.bg Thu Jul 25 20:01:20 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Thu, 25 Jul 2002 22:01:20 +0300 Subject: [LARTC] [tcng] make test errors Message-ID: <20020725220120.58c7c154.raptor@unacs.bg> tcng8t, Mandrake 8.2(upgraded from 8.1), patched with htb_patch _out ============== OK UNSPEC UNSPEC _ref================ OK UNSPEC UNSPEC _in is empty ================ ((X.nl & 0xf0) >> 2) & 0xf0 works: PASSED ((X.nl & 0xf0) >> 2) & 0xf0 works: PASSED ((X.nl << 2) & 0xf0) >> 3 works: PASSED Additive headers at external interface (C): FAILED Standard error: | input in flex scanner failed File: tests/additive Command: LD_LIBRARY_PATH=. tcsim -v -Xc,-tif:c tests/lib/additive.tcsim | sed '/.* c .*returns /{s///;s/ (.*//;p;};d' Input: _in.11911 Output: _out.11911 Reference: _ref.11911 scripts/runtests.sh: line 2: 11935 Broken pipe cat scripts/run-all-tests: line 14: 13671 Broken pipe cat $n make: *** [test] Error 1 Meanwhile on two Mandrake's 8.2 when I try "make rpm" it don't work ..... if I try "checkinstall make install" i also can't make .rpm... .............OOOPS the kernel is 2.4.8 may be this is why this happen (will updated /usr/src to the 2.4.18 to see if it works)....................... raptor From raptor@unacs.bg Thu Jul 25 20:07:46 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Thu, 25 Jul 2002 22:07:46 +0300 Subject: [LARTC] linux NETWORKING diagram ? In-Reply-To: <5.1.0.14.1.20020724214151.00a16e10@opalsoft.net> References: <5.1.0.14.1.20020724214151.00a16e10@opalsoft.net> Message-ID: <20020725220746.744fa435.raptor@unacs.bg> This is a multi-part message in MIME format. --Multipart_Thu__25_Jul_2002_22:07:46_+0300_08305648 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dia has no ASCII export so I'm posting compressed .png |Hi. | |You wrote: | | > OK. I've made the diagram in Dia (attached). U can easly export it in |any format > (any linux distro have Dia, i think)... | |Could you post your diagram in ascii? | --Multipart_Thu__25_Jul_2002_22:07:46_+0300_08305648 Content-Type: application/octet-stream; name="24net.png.gz" Content-Disposition: attachment; filename="24net.png.gz" Content-Transfer-Encoding: base64 H4sICAFMQD0AAzI0bmV0LnBuZwCtfAk8m9u6d+hgo629tehIW0VbQ1QNNXekxLBLzRLUVEOoWRDR UVVbVEnNVUWJeYghIW1V0ZiDIIZSREwxxBiJ7033Pvee7957zrfv+Y5fF5V3rfdd71rP+j///1rP I+p3I939fEf5QCDQfr2b101AIG5nEGiP8y/cwCdd+jJs4Mcuv6t6t3/55RfKmPF3EOgkSO/6ldvB qXPDqEVZZ6TYop+cyG4uoclI7c67pPMip9/m5VzJefObovJ7/+n3pFKj7t+bnHLScmhvXopX7hwu jL9qmGpEqjj3RLmUJd44dFLc/c7juOjrPLdei0nue/n0QSzl2CZrNp3tw3AaFutw7Ugvpw5oUle3 Hm6GdyxoMVWpoQPriHRkYJBaSpsk6HJ3+tAe0MdfmiGgpy3/oMy3QUGen0UIG40xyDnHGszh+xk7 mxmoXgwsAcd3+DSixah6MtFGa/G+wETRnd3hy1IoE9hVWUTLgU0Kium98xC1KGBdpJFmFCrrcpdN 3dnOCBry0V04b189IaE+MVfeUc/ohvhZXPhdZSQ4C/9o9woSdFISzPX/KA4Qg1wSFBcp5vkK/+go Sewm/tUIvqr7aJtLeRv9UGAk8GH5gKeodvSEDZ57TnLdJvL1gKdympFHfFl/lEyRPKrucEWljZmK Ff6NF+KW2bxaVB0IE4vuvHHuejRB8jS21p/tt9ToT4z/jPjmL6yvbwn+Ufrr2YApyYSbGGjuixlJ WRsjgQNS3UenDXYEaw/PGfR8Et7rKAU+ZX7iDjR7lwUc/kLz8+AVqH3AV0cHt0rH90QY21LDL+lu jc1ywDGxvYIMcObX057CPkJ7bfLWk9IJ1lBCG7YxXxACKZ6++9m6GfLhN0lbktqJRHOyQWshnKB7 gXfWWUMYdGdZ8P9dFiJ5fsintC3UzhZRvAmsdnW6hv905zpfevB41EGjS2Oq2vc+80rhtyfBo1Xe o7TcjPqg4p0mB81twu5dqwyS8WjwjxcZbEYuvfrHS/WF6h9YilfoVJJroruDWhr7BWFJxUh9vuJi +6UfQ34dmjvbKzGqU2/S8x8XSoEdLosiGV3HvPFLW7PFBKADXrW0nCYxVFjpXbW0+jlnMNCQ1K6x 0krVWq+JHpnwy2AOuWrOWvEIiNr6qwicUPOnpgWN+DSdsNvZItOB/uOAeyR7FG2+GN14oRm6loqY SkKt8xip0d4/px/S0YVdDR/dbA8qqt+aYTHXUVMXM6ycJvzVNFdaL3ao0/EXOzRWlIoRbUmu6YiJ OF253rmxhkjqJwTwkPDxgxnVS1+PedcA1utVM9kgxl5M1wyFrdeSof5dN1A79B0W8IpZkeu7KTqw q8pVw4EUNou5sxGzs9HBnus4IKalgVri3NyY1WMMdBqBWqezh6madASmggAsPCRzbZ5S5a2QhGcO 08PHo6S0djY77FCsVTLw7f4uHs7IpADfgAYd0TDGu6q6efgoe62KvJhoH9oCCWx21WYOjLLnR9m6 O9Nidd/3gJvNGoAX8vv+8T7wrjtdYqwuaNCwEmrpjePLmu8P+OVqp9/xg/GLE/HGC27kjpC+cmDi 8Svt6kAfNLams1DA0ixD7bBjUNs/OIMmR9heTg/ks3GcySybe6C9laVduzEeTd0ZzCXRgJeMsQOG QQQYC4wda6bt0OJ0Vkz4jGnGIAG1o0S2Xfm4S6DVbqjctQO8/Rlsy6lqe+9TeQZrru22yTIw+kOA DaG2m1B44InFKNashR1y9bEI7E224OFLiJai4MVPPMU1U8mcWQPuGgLMzhS4HrBIFCllxH8EmCEU exMc0hXdh2vKTQ+Z4bfb+BxAhq4ndYQBk7zZeufLqjerkLDaV1W/ypm6pSaxnTo60rtOHdo4XzUa PuTTVMfIBrdBf9kXh3eiaqz1O6K2clG1QG8wxfVbbCbdDs8W114W59hbyggjh2SszQLQaCFwclxz fWglG4ykceyCY8LVY0+k0oPvsLc49gHYZYd6JTC36sCS4pVKXcQDU77DIuxUpQftYRjAykhe9ZtT HeFr5WRgdjiTPd2Z2ThLojF6TI01AesHrGI9CxjtbBwXp1eNlD3HNYIXpe02v50AkHG2sEqO23ek GViUWhk1K19V6pdemxpZyagFL37nhy0+oGrvbKI20aiaLpV9/hJgB4UkA5fyAYv65QRgvbEBg9r6 ZlHfPTYF8stN9f2m4Ty6PaWSAQwlZw3OuwtoLH5skcoI69aTQq7jRqGF9+yvTUj0XArbWBwOGkUy gZED1t76kJ8xzQukK4Zk+PEBcPGIMzYVJCN15ly5jRGlZofNBGZDJN3327n14SC7UfoeS34E75Ew qvooYinabvudSF2zWYy8cLox95FWntCYS+NPhx6D4C2QZvtweEu6JpvnUdciQdrpLYo3Sxx8ahcL cvjEDu7q3mVBnaadotj7S5aHTwD3m7b7PL0xKqTwZh08KfH86Q701EPETnewzPOn+Ef7njf9cVF+ lIeDAnu30PJq7KDH+yYknr8Eau76USqvtiyo0El41LUEPOr71p/PKAI+iEP/8QzO71PMj9PNkObL O38+e1Prj/u0rt//39ZLq6vhP3mvTYkcNucoRoTu8VijotjU+JaJlYydbfWRpZdDlSUurqk+X4vZ M8VTRQ9WU9pdyoeUYpfvC4R974YAtrqns89mZDnRo7hOOUioIIM9eWm7tWO7tVHELhXHd3KSsxAj tRiZQ2adIgjVA65pAX0SaNtXnEvxGdvv8UN3co6BLhvAuP8NRcGLRFOsq3B7zHgCkgj1EwEhk4xy ywcKzolQo13KrUjY3lV1sGxR/Ah28KopMbtPkF7h5gYnRoscLFZM2E8xhCncifqYUhB4uTjHbYns jDY6/6mvAr5FnsFmWzwbMP9Wc6O+L1wmOjtaSB9hW5g/+Iunyo/SuSL/DM+EBHVMW7nhE9N5igEK fP/EKbCD2Zhqj56fq0rrZ4e9vfKYB7AjMY/Nu68VVM7m2kA8KYampsSF00gXkcBE/CMdwxWvZ8Xv XdcVC2NHApu7M3g9L/wo7bxrHmspdSI06q6nn5EiJCeHKpSr/Wu/+bJgn33CbenV/meEvnTmUNgD L5eig/tSlyyx5kvWTzcFer/rGTfoeVoOhYlKRdtBKMqVtrj594JG2VBwn7d1JqMI0/C50js/ZPhm 5T6yXdmPCQnxxPSksvFVNERWFnpwAEHxkq2wGnTAuN+Wso4odNVIPOHMd7bkEKKlOqBdw4FX5sZ/ jLiXtgV3ieF2qKQIomVLIl2txrLWULdOaPRWYswdInu39PKtzif4ofA0Kay/1tNHaDnPAduUC/VZ XUL42A9hCajS0/Gx+Eeptn3cjmPheygFDbsU9ase6lV0TtVT0uhtw/CGQWaXouZk9Rr2UmO4zrgs Wbn+NnwYO7P4UjKh3XQLKWtm9m5yEXD/uR42Xiv0GhZhc/CY1ObC1Qf4IRe46NtbdR7WS4F3aczn 4HAjjcnqQd8PFS7M/dFKFqibZNs6MPTd8wMOSZMnDPmo5yxqXH+f/xaVeJBexaC7s/1WGwcTG1Ad NAHsih3X1ITEZGhNpcbLCtVRUubkjFp26wfsEMzS712WLRI8HzRoZ+EyQLgK55+to15jrqecDZ/X 65u141gC7d1gUEERqUkjy+ylF9x9Qc+Yac06sWrd37mv/LzOdVj3rcj08VrrBRkL1zsl9A9qH3HC Y/3eiZm3oHrmTuEy2ow6XEMcZpK8lihLPhBQxLrzydlG2qyyZ6ohTPcGZD84yKNwKzzaVY5cOduL ebCbRYRjLwk/ymW5W9xsDU9lLWp0d+9+0dhRmRJpZiYAn5fiM5yZarwt0GaohDZ6bS6V32N+aSKo 57YZPLhCxlOWXqWmlIdsk13H3TZrdxZ8haYUTO7sRPVay+WnNfVXIIgwl2oj4qvkGc981VuXTc0w +CxGQbxSfZa/JgT5HbOzx6b+MWydn6ggyg8hiQwosN9WZKJqcPpZNi9FMoWKXdzG4zvaMyKUJyYX fJ9bJhrvC0xasvzHRP4fFYRWyyVbvzYlDpYDvBwjI9qJlRvd6qvqo5x8eBrcNEa0Yy+jCduTQ2ag OTmEqr/2ykXtlc8i9fIASA3sVxm61yhkgR/b71098QriS/6cXDchAW6BctfFoq8F9VlxYMqqBmPf tjY34MepuZxQ/BotLzzF/GdYdXVv+YBMEO9H3wkJ0Jd/VjTAIUML9cyFFO96xC51XyQrBAn4oFQD ydGNryrsRYEd+SBZmXlncOjALMAph8xK3EybPt1iFu+sEtjdYJYJ8MZV2/GoZePwnXWUdpCQZzJ7 Ujm4URq2NEiuB2C4hLVQQ03XZpZrA5COaCbC733aI7LdTt82AloyWZ/Etj9RANo2ZBYbuakF+jUe /e8ozyn+avst3tgEXot4B3iVCFHDXNKApzkLoZDU6lLeLZ29H1J8iGwb6OaTxsD2Cidby1UqowBW Are2pvgu/XAPyc7z7PdafvUbZDfMTO1kQ0I0QQ7nb8KLzYGTCOZVsnUmzEn7+lkOBnP/Fwz2LPdX y2E6YQqGrODpcIVU99Epk1GIvQ3ASG+g8uK9avrrbAIpX54g9pefn05Ysgy8qlZhjY09fAc+6Fib LgQ57+buPgCVUbq3H3cNVsZSi3Qm4VPGpWkDmobS76tOlDFcuW0AljRpTjtfOSA/90JCcrCC1uLc 0nPdgUbnKmlMJTilwD3Nqedl0SGejXYeoV9TBPLbWgMe3CcRnDzaBJaidiGDWc4kq6+N3Y3ZIo3S F7qZht7qeY9M3cjRqynmZ2FcCnmzB/rq82YCxHsVbFEtL4HxtAzR8EvYFRJ8Sn88wQw733c1JfsE Nl8n4N2e/pCvjgO3ciK4IXHo5zbFfgiQ8H+Y12SRXxro2o/RMw1nwAMVg7m3EhO9ptqnjqnLVY12 SWIGz2mZmUuBg6BUN3CawOWxx/tTkqLKR+oKZu9ptOYryyydKlgu9nqfsbfhFDjTTs72/vz38D04 TMMPJX2VaA4yFw2l0YfqvskSSFVz59auCgZletQOG1e9+gwn0auq4asXuobzz1da4dYBWE77hQPL qv7sAo2gx0ItxOHeqaWjvaH5Qt6JwiNO+AqzW6bEzBlZB4oYF8bHRKba367WhBiVVhR80ui22bDF OHkwqKcwv9GOsLYXS1PIL9UUcwTXWVJ8N7wVWC/NN6u4TiH03trIV6ha9HAwuXF/Q7puQEzUq/yU XI9ZSajZFiuREbcfrtVy3SwKgL5euVWrKzzLr1Y9aklBt8RWnm+pK2ARunULtXp38BUWDanqF1vz +48uv4L5T58rwkym77tHiM5s75ZGYJJ7AuaUTd8UnalT0E68HBJ8L6+NhKl0qwn8tXJSKbo3s135 sVlh1cH4ovNhBKuQ27I7fI0X0Q15fGokwhC019HrUpyST06hW9cd0bY7aX8D4+h5cTy25I6ZISFn 9NYWyTI7f5GVs06pya/cFnJ3hWTbwAIJELNJW0npV2gcZrJUvNSaeKPS72SKsvcAcR/ZCluSc5pS kFqU31YQ7/8D8FwQEiWnkG1xd1N1vdaOI/8/rpFqnAK20D3SL56r9hV8zkWnaXNh4tE9fmFcZwGI Bl1A8P6zUnK8Q2PA8L9K9XTjsv2i4RtjoQs1UhywOSCq8Qa3uywOTfmeJcaa1tXe6gJg1/MiQtWr CdAHELutbgDDKnRFERPfPz1sEg2d47BLgFkqoiqHFVct7fvxMWET4mhb3xZtVu4OQ1xs8+aCdYR5 6zpXxBv87j/LI8+hJ4cAf/lX2eDVvQuPeACuznUSqxLEVZJKD1/HGWssXV84bx6w+P1Ti9Nys3gM ZzOgxsPqIbqekV0DiRgxdC23Wjhqz0tND10AvEQsji+8GVASyC+/6U4UcW9lo1rOpoUtt3CEqq/F Jyf1rSaA4Di91lorjUnza1cFXEZZEH0EUO6SwMDw/nN38b8tZbgcklv156GyY9wUV+8Fbvu3OSSa pzKGrcHRU1a0hO4nlcUd5GI5WayprTVcO4608kqNLvILgIK3Ty9OqTXpwZPlxt3jYJXzufHVlmbn 2ilzVRWK27sjTgNk88Y7bR5PCQTvuZUVNIbRIJxGWBWqfMLiC7VMXLK8qSeQIcn47aahkmIaV+H5 /fy75ml2VwsapmfneMxHmSY4I3oQVOLTgVfozmLbzR5F2cDxCWn/0+BT2ARaWYI339aPbYkefvBj A+Nst2Sv8rvYtdt3fCglJd1y3RS5xHZyRtAFqAn3PKenTOkT6hVDpG6GGhErc87hHGcvqta55OGE RFZFYvVMHg8vp5d/GmiL15GpG4caCvjOKmgLm09K+pXwM8ADssjrgzMqSbNZ+YkiPtyyHL5wJMbZ 4r2uYcpCebKl1LAR6eK17o64InhhMI78Zf/Dz+rynJ20uWdfWE0QSHTQGwyrJi8tZxVyTBi1H3N+ uLLIWocWHnzZeEJiO9bkTduuPGdCYW7kxao5hRmrq8UTEv5dWqnu9Gf1XxW61x/z9N2AXaWHPCtF FFe5BQeuHsPtujHV9FngXCBZ35hwvrAvM7d6zfR51F6SUCBGLDCJLYE7zfreMqiEoSpEE8xVrCY8 lsjdc303fk9w2XovFmkFxxqafTwKDE7jTLnLIFh/OxlWfq18NuS4ZKwLZ3sN0JFJt7/eCCBECCJ4 46Midp/+6vj/2oz872Vq88zzbh7tjU+mRqoS5BHNVqexxbEGYFHsB5xMd5M2e2lIAoS7AVNQ4Kwk AnOYPlV0xwxgUg1CFrZLT1TwY68gci1Q4tG5gR+tByjGQEURWLDDAqBWOtI1LWx9Gjn7BfPNkP49 9UJ/3e5bWY5VA44xmmvfHwoAAvQoj4AoQJQEtLcXNdeH4nHC7seDhnykUu9dXTh/ODFPahNeiimq nRFjN6De4PgOZ9htJthtto1utw2ZyctsoSn0N44vVZe+HPSz4Pqx2HmNs3t3NkhoXxygUryRszY7 HTub2jWYCJ+NwtGtQtRqMdsMuO/pv7bB+1fLwCkSrYLiLquyG9s/MrTnY0mPzg9P5ZSfWnVSslFJ BCICloTpEUZ6fElqhm1YK77XzQCTOb1oruiNzWMBHIIv2sKdX/qrpVJuNKEvJzjFpSH7MsBrNjyi DNIiSedfkLGdds92zUqAx5h7BaFRR7vva9olNzO91PdMPW/6PPW+46FyXjq9AGqNKx4vnkdzmy0L SsY7+MulcBf415e/Z028dXeSTOSW+Oo4xszRLtmoiak70/6wPdx+YL+ItEF4cL3xHeeDYfZWHMub mPWUVb+KEf+lphmy4ZHdbkX8tTCQ5g7uPQszNqm7+77f3u1pZcXYOLmxe3HeYKb9dzUUL8Bb5p4p a9Z4lXZltn3J+8KY7V1J9ijgu3mPLXhH50rQixXcbcDeb1JbDyZG/IcH4BQnJ6znaZ0lSV4Pt/yY BBWXCIlPD2b1piFUIvPJpu3X9JzmHHpAlScgxK1YPtKGgm19I7XFwWnGVczZzy7NkJC4YPcfZcck ExUMGm0LXN7reiuYAIQAY1jJMI0j49bHiw1jTNN7hh/n9s/my8FDjG4urfozAXdtPZKTS2mypARX tgmtmwxBN94fGn12WBLRIvn6ZdR8aMaJd9nI9YoND5q5XyWEdEOu/RfsZlHn5pPSKDt1/x79PVJf b4S+uEBrPvuG3pCTHXo4emhG/pQE8rJAqHJ8gsBQpbGIW/moJA2OiesrnBr8SrLzsVbunwo4zM+C 7HV9EcM38MDRvzh3Hft95f6LOLTnZxOy6qWnIqtbbu+15xsPz4XsnGV/ef56ybKvWO21yrnj65is uFm1iD7skOLH6q+swA/5rH6XVYzO0nW3VT9Y4/lrTbK99T6mTkf2sIAxeXPuqBzU+bwblSXn8lEY /LTAaFPP02bbYYCFHcVWXJ3PG1UWs4aPFy31ONKQSr22cDt6/KdXaIbHwLV7W5YDLp4llG53/YCR wARWoGUu5XXG+HpEYoqMcwLht33x+Pci2S8HU7Mmpj2rq3L9WmJbICFdduuNS/67aqF6ZWoo2yfA Onf25c9vjdnzdzP9l8pZvyZEvkaGE3M4bKWNHtyk7stZ15XFSNkg3n2vgUX9U1ExUTv0GgzosAqi pg3GHCTrf3OoHXtyrKh6/BkAW/sB4qG3YP3B5+sR1wm5+58AHjM3CUbVNCzJAxJGGqiVUByWrf3r 88f/PrH0rxdKCg6kTF1qEkN9v8/D4SAKScc1gu8pJGkAfIazC7pg/cZAMp6qQVXtQC74+Vl8evsH qemP9SiuWyv0RnoAIvDpyEr6On6HRe+A7nmYg6rxe6m1NR1vpHYuSEj+0ChzZJ09U8w+HyQkfjFt 4Y4dBLaQqlK/9CJj44sUMMDXlv5j969RDRiiFqeyh4g+lRVkiOKOBX+JHlHSOVK81+vJ0sIaGLln 1xNHn+vW78nj07eR2YyQ+e7B/Skwt8EbtT05w5Werv6BVSia9GH54ysNjdv47+PUxnc147fu/mYN CKNkWR1H+A/4YF6iddldfA9b+YjVTreFvH207Evexixb07VDAicrI5PHoxvtIF04uWio52wc3Amh unMRzD7fmAEZzRTWNp55UDI4N07N+YpOEzBngstuU7zaL+waxIh2WueLVm4trCQcCKEE3TtmBWvf 5Nvrmd0+mkkxaJ5mviGpDjbdeY2wmpQ+XLKnWypFUnv7MY52s9s/uZw20WPCk20ikt1zymrmfe/0 cwXOi2LNaL++TifGhyNXcxKHaeZfJz6fXeH0F7rX183Kx8Rh7c4HpW/41A3gMSKRj8eODayio4vt dRS4+t/HrXLucDIa+Mn1x3dlT/xBxhP50LPI3HIf5Hv1YYK/4KGb0sPCASXuMS7XPqim+qiePjZv 58X2GPy1/rMniSzdfy7qmC4ZBk2s/hQQIlL5AjzoVjP6xYjk7TC/CmaGhBDmtXe+zHqU1uDnmLA8 gAbS3aqSCtzzM3OZ81yzJnU7ZFvSi7eu2mEPZxNxH7CqmKGzOMa1+fCUQOvB/MGpwVnvWmkIaTaK 1dc3wFBVrKuXO/aNWE/ICdgISVhYqxxwMyWegIkRydJvz/jExyuroTK9dx6rp62zekd7wpksyRkZ l7B5SeRxlvJrNBJlOLu4mr9W3D8222KErOPu+0CLKEmCFmfH1c96uwf23WuozCGT71xecbTYTgY0 POsbMVxzIK/YgiLLWj291LRc96hroJ/QnyPuRG1furOSvXXG48Jb/PGn2fXpc4NkzAkyw+FJw7Go wOT2QwZH692ym0ZIlCfej17lHNQ03EE/lnqSHFi6UbMRVHDASoJNL4Ledpda6siqYD9bRRvJyn6t TYZ5b6qqyLpvHe9j021hiYWa3FW02V7h2eIYyxPni6HWRw+/ETZyU1l1xkAgxY+kfrkJ2Y6/ua1k 4U1ghNCMh+ornSlWFqwoZC97aN7PK4TAQp5o1Rh1fWFHStwKMdtySCiWUl9dfSZJk5s6amOJ1L2s kpJCL+955xX5cM2uuNtudpCOJNfD5i/ZXbdHc7aP9R++ixc1KTccLUVSyyYtxTpf4R9lmzW1hDpz i+y7j3/ElTd/59vNww/S6kfV/C9+OKIyhfvsMm13VZp2pUuZbNdnJHJertCo6IDUM7CLlUpv4hu+ AzI3YEZa6zUd0ND5ypq1+pYfnBMgpSSDhbr1kRfzPtc/1yin7ZjQ9pNWGl7f1+//WyyADUyvF3Eu vmViAUdPN5DkNMpGw5JxiV2XdrZXUDO54QB4pEiCpVSG/UnM0R32kJlne7yxVhLuEfzihzGrxNUv B40BmNrFc+D4pXsng2SzfBhdukTicMBCDZXNMN7xXzi/tco5i7CAISalYUvPhh7vu22seXPvQgXJ KMVA8ucR2Oj21FClf0UL6j7nnGyLc/453L+w9wYsfNR4+4uxJ+tuayUZFjqZYDFVxP1kOtWvHdER OhKPe/Zb8HiUVKAyuO2nx3m0D0s/HWs20rWGPAqICz2bLPUPL4q+G56HPuZ+NCFxjbxZUj+G6xN6 zGzTuvEhJmXUZUBYWQfW/QwiGXHCNVzGo5MxtDZ4bKCnHhZymWZifNVwaFjSR+SBrVIVAkyLfGMu 7b1jlrMipZrnnwyhq0B18qa8KEZH2Xzp5V8BTtJnH3fcMJJuclcIVShK129q8icrdy3LexQV2VnX Bj8LttSJLCnYazbfrUzAhunSWHKV8+8XimM3CuzrnjeVGQGksa3OjBzg4iMr6109lSjRWw/Ld8/z vOmdEk7waM0cNMbppRAeRDg5MsBHVOI1yM55xr55r/WfBzc8bYZ8bfsUBA3ZOkNFfvFynJI/+9WR Bg3YV9hGKq6t1LAiJTxm9eKfmZhhwsx7b7V9kbJiulWMMo8W//Kq0uk9quXoIWP/NtTNjEA+Y30l wyK3cjixyKAomcSEthbKGj3SM1CaOZ7U26JAMy5bUZ8JpXxx3QOQUrfsttSOkscyEIuB/Jj8xMH8 wEmz5ZOa0A+EoJ4mQqpyhlBB3JIltq8vSAnL3v/57bRdd9/0gbYs6ersnEzIW4tlQR0dg6vC/6LI UadyzqS0ma47MhxnB2gSC1/0x0vNxLQVwDnOPpMuaobu+djcTDyx7Ki95khg4ggpuGfzVcHpF8V9 p5Jcp+TuZ8aj1Sd6TI2VBPk7X/z/kAKbhU30zrjddjSPWFhJrolvzUq7ulR8C0dscdRIjYdVeV3o OptN3wlfOA/CfvJFIFZ7LVArKaNzea/xC/iVdsQ9r3jxGA0TGHdBoy9CdT2DTUKpAfqGDOPzYDBI xgTWvDfg4z+uTb9CczaEmWXoOs/57BIdY83V1/jdluL/LmmDrcGnGuWO8fHPDnubPpwd/g1k4+m9 wF3vLQotH/Ccb2t3Kc+xTQW7D7oFYMaTo7OjRaKLK4YCl0JCKIM6oP73+yedTydK1j2efAaXe1WA jeOonMYJjKTPEnmmu1u6cV/R1AVQisrrFTTNftbtQ6DgKrWv//OMOvfJLIcXTUZHH5TnZe0FpVx4 jU8906TNM3IRksGT5iG2YogJ2EiUX+zYb3/9ySt0lF9odnmK+LeIGbwoSMf9LCJJebsEQM0DBE+Q 9dFvYRk3LGSGkQVy846CnS7PKzwjhhWfsifxfn2Kk7mXyiuqXVJGbJSeQGwqa9hlgZTx7sbVM9mG gvFv9L1rsCXjArX5IAT8LLjhyAWaxllofj+8wTngbk0I12QIheckOvN5k8tY9yGQ9aAt7IB80l5L QVBDBYkFAd3VA4SupyKCNsMPUjj6ZfVMw+v6WHFkgw0I23p3C53mmOfXpIgfuWbCPfeya0IC5KT4 YKmf0ewKXy/191u7zg/3ihrZxNIWqg6UKOnEoqOpYY8h0Res8LpQIpNPQlTCHK56G/ntWfPuw8Xz R2Jkhy8WT7oR3T4dtSlCmkedqwf9UHrAdkYNalj5raw8Bx1+m9ZO1Iu+NKfx0p0hZJ/i2RHsWapN PjUxGDOKDVtrVtbMPxjxGwPc4GppTjZI9fG0vo0smxqnDrY15OfH5TXxysPEm4mJF0jzY8nw9IKk 8B7nqlegw2jg0Xsi2M/fopLMj4r0Zu96K5DVAeHi/bj38D/l/UMuckZ7LEX+hw3KUrkOqc1owka0 rhjS/0+bvr0gCMLqo/FhpJSRijU1kH1zIpEoxuoSQ66VZwybnqvhBC7gRlkLnC1IwCGpBsl6BHIC OeS47CEyaHTGZqtrSL54FhFM2IbSQ8hg9jgYFjjgXOPBZf/2/96Q/Oul37djZWvOVZvZ7xizeltf LmjIp8lJoYa5gNNeijKeKHJuyyHRjHcYxtQibvtjQC8Ii/yExTbv8PJck+XamXzOjkb+kFnBQJyu 6OZEvPHUn9X8vMN+HOMEMlWiP3PCyP44hAdRsiAwwGsmgEMHiH0cHACaaM1adXzj4ID8KM9fC8j6 +wJNN+aWZXEC4XaIqE3wrDtcOaUQc65vcgZTHL5JtEvH8fXvRujFLBB22DbedUpBQozmXS0DJ5Zf jbBWUOyOn9EfbcmcjSNOAM3PQKXHIrD+ILPX28vgneX9KkOLFAKLQk0P9UpZRa25otaOjW7odNz4 FAFo9qDlFqmd/hiWZYpSxjqeaigZb2qsWTm5VdAFyCDtJIPwCd3w95ORqJ5buqu2v+2L5iAyxXbH Vy0th+phkEtq7JhNGyi9W9PjWfs+p3Ar0YPw0SQ9fIvm164qBbCUQHrdupFk/Ohm2mjN1gzGj1zm du1ITFrkdTHeW/saTS4DyHXdqd0OnLPhMjEILnk94Ln2GBx2KkgIMRRKr1v5PnQOYMHKmjX7/XO7 uXhLCgDEFuVwGiHG7GoxiuV0iUVkP3EnzRa/eUv7rI/8Ms7H2q9FXjg63eKvhhyehaFxfMoOABJp uVnoJ1d+oczoJzwiCFdByerc9hcBzIr/jMCVZPW1hegiMQHCuHyIoRe3/QZwIdo/70Bsom+RTbfn 3CG3+EqCOEjZDbgR9k77/nsf/e6ugmKVXzOFZLYsae3mATR/tf0qeqm6c54jAl6DtwAdBp215X7+ +eQWesXfLXnZtDV9PBlee3dF6WDS6+kQc3GNW/0mEBL97BBdeGWe63ABgNDBAzrBvbqk5HkVW/MU uDrw9gD+Rl9hgP2OfEe0rYYA7jF8nhwOX9sVKSC2sOZH3U+vZy7ARu3hBDxDRTZgMiUxUVkGboYz ShnMZxbOX1NJU/gwDB0ffK+csmvYUw7Ms0FYAEGsixsiBew4qw4zfcvNKdSk5ZX/7xJySdCKPrhL wB1Co1r07OtAqI0DvE129LeSd2kLdl514i8vjT8U2/6+/ZYTyUYTKGBRc4SK8MvfpIvxCutNi0ja 9yRF/8sWHSk5wvm5FR7ihLNpKKB55wsAYkLX5hBk3EhCaQQnCurIulaUjikzBVYxftYrZBFbkTUz dVlsQsLGY6RS/7nxWs8S33oKVt+s9lVnRqYtiheD0bw2ULFc4Pti7n3jJD5NWq/Y9NiHXp18JRH+ hdUTXFvo5zbwR4eo7We+3sBQzHmu5mprZHywMTOkmB8DPM6xoHDdj88mJLLQ6b/HH3iuHO9T23sQ 2+kr2llWyXtzuuWX5bJAxbxBgZthdCMUyRgl5l0D3xrUIh3i+uq1G5FUD5PFG3kl408XbnlUwT06 jlVmTDYvnH3B2BLe43jhAd72bi2ssNb/FPLG4NFil4vXdSDsCx9vvjgHVrHPwwwkJiPGzg6kLwQL a60Z8hl3vu+QC9BKP6Mc1H72DNj084jrneDABOnFCGjizcpBzJNBlZR+Dc2206Wc+NMVW0OIh2u2 Yl3ZbWIlRP0waRU9tupuBoF6ylstu2MZBOvRvvvWY0lv9bTFTTySVqG3bR269N5gXFyrK9qkK0kX cfNVDwGte3BUPbk+okDBfZBBtapzjpCEHxBBHod1Q1v9L/QWqin2rl+ypapcUsnBex5Nm8aOPYNg RiMGwRJt1K8v+emvuvzrPn69bayacEbNb6zZtn+u7OHXWYUcvNN79voOe7RqyBeSokTYaARzVvlW 4SgHUUPknpVxjt8Vkra3ine2OFG/hW1bnFjG0KK7uW3vVLd7S4v2X586f79n3twqGt7w25yXLNh5 N4IWUlmKY61xYlTX1mZRnHN7HqmUoO8f7w9J/F7Pclh9i56Vt9T8DTuHjdpPIsUJHnsiW0z8Zdnk 8kuyNrtpZ2OuvKMdukczhNMS9wj6GlmPrF73Kr8nFbCrprLKCMM60LXepPAA74T/GYs5Wj9k9rH5 ED2v24HVput2DvNZYYsf60y/Wn4IwSt/svyzn5vkfovjgSnhYjDDX42y3VAOd33SGrGNxKv56DUz 8Mk8L5sQiWHf0qnBdZwMgrfkFvzrmYYbJ4pELCVkzWsEM9s2yYMltu5tyhALxRymEKgzfo56PdIY xu05CIp3i5DY/+I/PVn/edG1zoMrjlyWelsPiC+Gi4u8t9Agm2w/mYCFN0/Ipc81z1E5p9DPm7g9 o/4gKCGjqTnCg0Nnc1fa/HWWKuyBHkh0B6UV1jV50lx8ZelqPYyI6cHEa9lKPKHU3T9KQbjsrblW ZRtD/r5+X6UTFHSFA3QLzYnpvKV7onL8ZeSmj+cLAB6oclz9or31jgFpbR0XB0vkEAiibFVB3QHQ k4K2i2DcjSl5XTsM4PtZzHVtgA9rJrwicg4mBVAbDd6hFAp7krCNrpR+Pokz7g2W5tkyDdHoK/Op nDNVJbl3pEyFxLoOAmR7bcB1/bauTgZziCoZ38KJeM3YiMpohvJfDho7KIfxkGy/pCx7XiuzXDHy Q+BKSf4MLzFTYjJ1sxRk8865tWBjum3GHaORUM5SG0gS4wddYEEi0n4/KnLiBtrr9wmJj0a/xkr/ hVPYP8jO902n3IzwrU8PeVTMDYVjtLamrwloMjisYuNHzOhikQoqNB/wR0F0mMqVR0rBM3m5L9Vm PgDaAPCeGa1QflbyqI/KJX+txY+7BLQ2vuvMtMx1ccIlu3T9LLrUVWJ3T+eYWfwMm/7ED+sMOseY kQAjWkjG2mk4vohS9wS0VJp/d5RUej9wKZ+x4Wsve0BMK6xNiexP6dtJ+DF+W/hyUIfGSisnYBbw aFdg3P6lABAT1tfZsIXzyvOcUBa77UY7TizNdgpqxXuqyJk0IXFZRPe4z3VqXP/SVtDOwmgdHUkP ZVJG2SPr9SpBsilTW//LyKC/L6sb20TA7aW0dUvLhBsVDziQK9ueSHBdLvTsiE7XtRajmf3p39vP wZB1b741ZktUQsi9vuMvQCU6yElntcQtfqJQimwCdLsyuTLbwv1ayJJRqPuRiLbmQLbC3IRsAZJg CO9zCTMufb1wiVteManJUWr/p4EeIRssSwhXYrI/osYToXouFTObZYG+ixcwDHULqUM6ELH7LouV TTqPz0HzPKr1A7FJ38svsNp49r71VmWieXdFxa8e+HpgwpCr8wp2Uyv6rL6rSQDNJD4ikQ/fPfBt 8OJbVlq7/7tD9s3LDDC1pQfQJm9sGpVs1jq6G9JpYwMmTn3CiZaZDIm3iu9T34z31DiDlLOK8fuM j+fEbGRH/0bx7nd5bKZMx1YY6mHmRCLq5/tYjpEX13kifGgXwDxvDHbJ8Ebc6i9kS4D8xX/Ku11y KyD702Cuty+gHcQS5t1nv4IOAjYJ38dgl97IDmXJwIpH3tXRVhvL9fWl33vj4sPHLZeudBpizKTJ NnsO5/02MXl6Pvl07lZwfHeDsf78IRujoU9va8PdaPj3d7aUE07JAK7M4EcpZy+DZa+yGUtNjKl6 /RrkCED+7ghbDqToZKB7u8hfzrUYviSZi2Xzfgx+YV9vvNrSTTuYOEZrzeG9Ev9Etaryj50Hfn0D JcEkUJbyA/wccyxuWNR6YCovNWcT5PmiK6bp5QOqF/fz4V+20D8S6n9wgcRPg0PPSHJhn/wrkWiV IVotulrLcT9eqhfRTaZ7xxoi/dAg+TuFy8ujgJmTgk6A5J2uwAAZwR5vENDGJ5n4bi6jCWGAwyhv V5tN9WtvgULoa3MXuAU6b8SiCUvHCKVJagq128tEgeOX7rE3qXZ/kx8M5X9NqmPJ5W8Ji4/BBpLx s8WEEd0lYG2tA6DB2Rf4dZ4lsDOmPVHk8Gs9UKX1oR+aNVPMzsfv/rDKot6gf/bL1AvmHAh0XhOY BGRHdX0GmrDmQUisOrC81RmpdQbMJfivyqL/WixjEKppRg1Cwsqml40B8js731b5A+EPCBsYBZzU 5sKJ7iWNP2lUwhSDYUkqlB77+e6AytRgcVDBLTtE0svs+oaycpOBRjuMlU2I89K1pcZG9fk8wPjF KZvEkviqb7/DTxce1MQOFoY8y/Zv+i0is0VDVN3tl/acIktiIrnXL8Ed1OpMJOqN2Q5/DQlg6fm7 eth5i8383XKlzU2ZDNR8bZ8cVGo7A7Bw3zXwQfOo+DsyhZdK79YN2x4BxO/AFFPm3dk0vUry7zng UkvL7cGy95xlWzDv/TbY/1onSF3CeMc33cDQNPxZjZltOXI54XM1ay7zz2XrRlixO2iaqla176ML IwE9lsbVrbvd3fh0XsWT0D7zuNKuNqSNW/Bk8XAtai7WdReXvJPm1ORPT80lz4frJeyO8OKsF/M2 iMUVUAn/3hDCg0eMPUI0SvfLrrU68YgL1pWomk0b6iMy1NOqyHNUnfuwOBWwkj6khrKmkSUF6Yki pChXSdLDmMtexxKx+XV+v5uWN+bqqMxX+UOyzNw9aoRA8wEdxEZS9efsxje2Q32VrGGUoMB2PvZ4 vhZ/NsuvUliaE2CLrx6Gmn7KvhEv0eCb0PSYu1OHvoLML+2aujsyNecSmYiZfW1SMugb6tAmm/FY 1WbqVC8taPfH2n0+4Z4pVLu1Cx13VyOfBoS6UJ/Zdu8q4brWStSLnp4ZejxT/CMBA8mV5i3hquuI kdW85TvwMJTYbkpM9IhUIwn0zNkP9Lln4AbglBv8ammg2conm6VjboRBIUHjZAPtnTI1sr+Jyq+D U2PJtDKP0Ruk1xnKnFjYxCk+M2rTGusl6K5372YppqDP9xZpBeyhQqfT3lRKKPUO3PZ7F5GTvxWq C6qghu956Bgo/RG0qjSaq/jsLOjqwkF+eSfkZPZDdlnYHdA1l7+a+PT3ZRSl1ZIVo5UMLK5l/0MR FXTqZGmTaErVAdDhsjqOMvEjxw5wMhs4+TLDuPUPWS+/QSEu0a7mu34vW4/TFW2BXnNB24Vv4kZW izihDzVzZURfMvfHy0n0XX+JZvw32lFHawwaQVAvdmiUA9DFyaOQim+xY0/ajQRS4DUeVikDnubM LVpuxsIpNOjEbgRioYYK0IuHKeckikeZdX/8GzJjLAAshHNE6WfBJa91BdZeN2NWrDb+VHxL7jFs OJw5b5hmBLoKgCYnu+pPljEDvF4IwGN8gSbm/65YKk9vlKExJzI1Eeaw5BfS5rxus13Z72spCOqZ uQAmTeX1mYYoKamntKnlBq+uNkqvuBxsvI0uwkx+OcZl/2LrG9FfZvVoIubs3ziBsPYhO1s8Kd16 r/3FsjTCPnUEv8eot2lK5ZFRU5ls9ZegfYZTS/161+4VBXdfGA4O/U9OYONdXBTifm/XLkLUxZzK 4qodwRJPIohxygYm2T6ScNWrce64EU9p7uZHkOfldrbz58vjTnVW6rEqey7z/A1ierMhhtzWM0Ou eRet1RMpdt4Bl1j2oPw/aYH0H7RA0i6k/2La2+zmAlmZ0qs0yGW3m6oX+PP8iCBPHTvEkZEjJ5Ff wNDn/eENytIFZYiqbLi+tTMBxIBXLYjNhgeD/EmOf9uuzCqxYUFA0zqcccxC0F7xgnTc365LW6IZ vSKztW0yIBvvLBaxvbSnxvEo7P2F1vc9v/EcPspBF2zmHzuWQfmsNp/BoSb8Sl07Dm4ZZuA/jx0r DHsutGvftyfLvkvTRffcLkhStcEBmLdfSJ/yZSPzBYzcdn4t2mTNJwcm31UOI4A8R0qmmP7RL5Rd mWoVttDcaocUtt2duIuvQT8UCvBzb9saFJhvXCv0d7xfCGzstr8IUId44a5eRHA54cqthkJOrc3S 7CZjuWPnZdXdZW3kNCkepfMhuIdqaOANaX8Di5hsA22ZcjXjgJ9goZf6EyxoTq5ue01N22jr/JeF j6WJ4b65y4ooacqUB670ikEGfDGDPNdzg06Jc+11tgTEjLzBwzd006MivZXc9nf3xqG5BSPuX/yL jP+/LUXzjpWQJvURH84+F5SvjrPb4vsH1fDdYbOQZC7QNeGJSTp7ga61OREPLEA0J21u5wdqO4aT Y8c5TfMjd+PEX146HcQLyjo0MXlDBFoBkI2tKRWCapIBbDXfgjXUwbJdsAYdPvuvHgwIa3TMtnmH r2Rei1Q21ZdbHw4adVLYfKi98RAgH1pBsnXq975/HKkrFBU8cPnWventbnQ94/tDAa+c1/gFHL0e cc+rClicuN0Rt9x7ezd6crVW8VTNYg61UqWmrjBIPzdJC6wnJz1gK8kHjTVKOZf81dqg3B+f/qso 999Rj6WkmWbkWm4V8rixg6akPleLnSw5A/rQ6wjLaRMvjGHoV2j8HUSkHC2A1hYlHvTeHaE0Iw0m lb6WkLHxGukRK3SB0xIaBRpFRFYZPQqglLj5bef+FhtLb2KUqA386/ohCO2lOOhaPEIjsFvjnrWt Xx77Tu1k9k0l0FTZ5OT7e0Ve83W114maboO3SLPzHjZYZ9BWrCz4oCtdn3oS3dZ+nYhYVRE7HFE/ OWcnue+MUZ/64f+KEGNn3ibKWiS0m/cZVc7T/XMOZoOuJeaiVI1zcqJUG4fOFw3koBK9EIJpl2Ru uMAdooT0b0GPmhjd7v2bbOg48cQCqVh4RKfxmVV3fckaxEYSSc3+Ax/UP9C0Qc9vAsTto9NRez3Q 889eq4BMOMYZw66JbKIsqPkuABCHHzASjnngIbKgBpVk9uT5mOkZx5jyAYP/4UCD9SJgcGhX3Qqy e9j+hL3H85NgEQEqH1rY0Ze9YlJ1RF/DqmDQ98NWp1AcQLUoF0Vtah/DiKRE0gMlrK2hbkz63sOV vzHATNLUlZSUDNfdH0Hz/jAj6y8OVJ/bWcUgilPoV0dITJGtchHnNANVYBlgk2YUEXf0yk7Z1jY1 e+FUbPB7560rKdEZHioCmHydHFEpQGmcBNt8NahyhWMRnS7zUxjtbsGI3wbSAbkw3QGoCLdsn1tQ NdCW/Bb+UCzIM+JflRG52iwaJ24HiS5DRLven3/wxzaH/RfA2Ckja9j6WVDEKf7l5Qf8chsYwham 7fUr4p8pkIRxoeL+Km87qs7XbrPh8qZfNC6LXIGFM7LEhg1OHIGGb07SQ8g4ufqNcaIcTiZIFrTv 9cjef56k8k/LXqy0NAh0KJsTC/Cv3uN/Udam5EC+tQD3EBDTSsXxDSYb5YLDxvj9LD69fIWeqxDb WRIjrI+E+llcseFsaTjGaCbi+AJf4x+1cDJHfwZvP3g94Bk4ilyfLHqQJgl28F1pUyH8zPnZcy5G m71xoel4PNAk+d8Z4sUJ1eo3ItH8lVOUZPPrqy1VS0/FxuEf7dOPsjToHPDEevbJHS3ghGsPQoiJ IhIBI2BPHgTvbNVtMZ+8BA+S/28W0Yx8uHzal/gnWgv4pXuE7OyQFk8xKtiB9PmkHoPKUcbP+9+t qHxg8YViXy1ZNudRqp3F7vfc1iEd6czvLpH3PILg/WGqVlP9zLkjXXKNorjOg30I1HNZvdvSGw+5 nhVf7CmN4FWFz3ZmNzsxD8c8/sRbTPBM9iq/mTdoGtUIP4iTY/9+NAI+GFjqX8/GR9eMQPTTw5Zb WpyWe0yNOd5iqHbQ9pk3yM+OOUj2Rce+wD9a5S/2ty3oy5xMT8whW2EnK9dTgHnTSDJIR0wlaW83 aNt6Eztf4bfrO1DsFXroKNPX4lOOJqPzWnzLxFKTWAe02c4vG1UI+Kk77FFOzpPFgnWIynb93BHX 1Djco30Tk+vD9xo4SVzXFs43/+jMvObhXe43xUu05qQYbBNqvjpegRlx/qrDMie9mlNHBbWiIhYy nQmodLmgUx87j2w65KYB3BIwGnpV/WohGj8hUeNxapJzoDT1xpETDdckGgoslLmz5PjLQQ0aHYqt +fZzz5s+l1Rjju+LZ0v4k3XfA8pUKGU+Kz/RAh5oyed4CvB+AO2vvRmTLOmlO1JhVJuWE/novdhx KMV6iV0Upb67Ej/JPXcAwQt9n9F4y9Yan20732E4r1hoN1iy4WFpRlMO6FXo25g42K+wLBhym68c cbJyrmqVoTiVCNXRhJyNQ8faMe/l1+3fOkq8uW/t88t4tLyCZmM/nkxR1KCsI0ccNlpjHosK4Tyy m6AJ5rOdprbMc1+vP6TxWVjxOWaiOM9VtMK5rNq6LJFnJKPDZNnWycO1T991G2QwVsCYNmweX2Aq /pGceYYSKfzWOJmRfCIZSl4BU8CPS+VFf25gWhK6qz8cEPbkAgxV6qQD858f3v6DQo3/ODFMD1/n iBsc38/DuCGJktkcUY0vcuqrPab0uvWRIbPOvi5dMVa/YwywZk9ko1qMmN95tDeaxWMO2VlpzCDw WpstxrCAXjNvBNGGA21DlQUDv+kej8PtDkTjnXLrfoY+fN46oeY/nY8pUpstKB/ZbA+aKtqD/f9K e1vZhgxycv/r1+voQM/6rwloKiYZcBJi6GFUdcCKAod8mk6gtpdqMCeV09pcajzsj2sxMgVYsyhW MSB/KFPdEDBr1W5ndcjsVxLBSZWTEeOXvpI6ZPZROXhjLJL6kOv5A7yTKud2P9lbDSYCvsheJ+yM sikoYMAGFf7Xh7ivsBpb+/ud/8tnOSS3BUFQWdx/vN0iuduxnSRmGXjNnn+uDQp63uCvBrW9r2bc NL4nr3ygoPpqAKVbulcpevZ1YqIyWM5wgoF/384srK8PzsZOrjFlsQfru28re6bjH9Ehu2F6avLJ fWBnHaIdJjr/BdmrcjwcQ0mE6dGrBoPzviOMkWy/czENVfusAOBZtTx/PVqaPPVt79XT5HARd+3S tVFr+4YJiYoEo2olfcX6b+ENMsddft9ffj4wdsnyrvPIEWuLdcxKv7cbJkenm8pvQXYhyFK6Mp1k gDavtFbIZQB3g8Bx4+EQVx7d9ytSe5Gx6JJT8zEbjamWQEtDYzlIjiSfR7Icv9UlFG9Sgo4tRgRT cCuvSXghaOVK5dyQY/9hFuSuBFLU59XcL+0qBqm6BiqiByDCUqcNzw+XjTsfa8Rc+swyNx5QFjLH jeZU2aYpm8k2rKL3xQKvz68roy5WSfGs/rYveY2CRTivZp/AuqvG8CooiPJ72L+S8tRE8KIKyaJn 5N3/c0rafNJAKVS7E7OnwQMuNPV+iXRXVZjNWuCTlkh8yoRECglhYkBtMA12aDhMpV2yBEssScEm RxMInw+8Qpdo2vZxs3wI3MqnWE+fDxbP9Kb0KFb+XcpetJKKZmsNdnIxUQ2j4XsG2vu+G6GvUVsz OYKGq4ZV66+KGcCJcHZv5Q7aKnRFfNQo8Bne6WB3TPNZOVnR+mgViAeCkvblYixGNtIcIakHPyTL JzeMLurxvZMrLZpDMjPkcw1rOMauFIud6/SlvURmC+Rv3YETxwi1DKmab3YZhWfAR2K9PnVOfRz+ I18PPTNWWbPL1o3skIKxmfEK9NCLTpRVYd0XFCMOxhcgzQCsbKlWGqbhPsQgdBxSokqblNUNCVnt ahZmlB6188kGT9Qeur0xi4vDOzHUGIfIvb4hMWm6KyEzXwoszVCf3VqtnuhELrbIn51qUjjZ6M04 8TJKVn23rE1Rnctb1mqyBy2toC66/Kv02b4AmjuxoyZ4ync1rQhzPvAZWyKl5NK3P9Kon59OdElK zAmXCS8a1ijID+m0zY95k75ipSZknTzaw3jZLVsM632/mls694sfM9HjWHGaQIIXojHodZH7Saif sh6sjFc2RuaPHOpTAxUIap6abJW7amaOs3JF3nlNKee8fLViki7RUOwms9B8FAxAquXL9kmvbsIZ AGyTxLvOh4Uc+35txHD51fZxZMTYvyQgO6QcVDl/TWUZQmBAfgJKNhh5LohX5gqsLNXGu261z8a7 DbrnYw5C/xJ8OGS2UGUk2HHh/FPkcnwGfiYfM7KcWGUbttRY45GpQ/sA+Pr6tYDiUGjRnbvGO6+w MNaMBWGrt7gduqf0WuQBKIDKnBxq9dHN9qHKfzHo5GeqIaqleQi1wwKHL0X7WVy4Wz7gqZximAtw qmRc4hUm8NDanyek8keBmhvHtcIuBfGKyxu3DZntS+6IzG6G6NBemxptrlUR0nB8X2d6i8NX4VXD ADnU0YEpmIeuXWIe8HwpfuDfxVQZd9TSnki3yuJOxTZyMnvkkjlJPZ4m6JfA99KKwIZBcvQsus9K Jn/YgpmYkgwvP4SNAAgTAJVubmonMO5ksIuZm5vPrQBKyavGqSiXhuySEwDp+N6ahWl4ArkBLjmE 4D1SgOFR9paKi6N5eVETSXky5QP6Xx0dSMntttiqRLiHqayPcLliBSX8HIdNIs7kjBU4U3JAkNwA ZsuV3mYDmcey9hrCvtY+9sq/hZeL3R2Ur5s1IcL3ejvgWiDNni+gpc5SfC2qdzuCZTytg/PBeLZC nF9vs8z+UrmjGcVWtYIVDSBvosoeRymwA6vbwqxIUAqOhRNGZxBtXkyh2DnuH6XyMpLEj/ItkOkb nAweeYP/e1qx+sbo27UmB22NuRH+9falK/GSJAt4n7lZrSXJ9kxgEsCQBTsybQMbvnTn35Ezv9jt KHPqE6cz8HyzeO9TFma0yNiPRV2ER9v6t3rq1wfWQXlclpaxaHmZSha+G/Fl/N2aLJUP2n9gWVDn a7zkKX4q+BRhjbonVPPhNOPMmWZIf8XMwDe9TLJlmnl5kpETKb5xawT8/DHAi08ijyrU+TdKGQoX iybdFqUlVFeT+sHqRrCrRsT2T7zgYk8Ur0tkdglxQsKp5GalkHr0sSw/3mVBhbPphXN5k7cU+cXv 1Av8a+aj0RF9i8MrOKczAK8oDeEkeKA/bgTvlRH322Gtc45wWqF7KN89AKpNy81IB6z42s6rONW1 fkfOCc1U0Z1Ozt9rQm2RMtjqKCrd9t6nPTUemx4kmmIQr7NUmr/JguDhgyzIxs78cIcHyev4x6XA lAQz9LN3Kd+Ov/ue6tcshytoc/tFWPrZL+msXYcYUwT5K5+iUfc/nM0Zd4gUTTZ8clDjdXtA8G/g QDVqX5eDA7w+0n66anh5Tjc9J3Qr/MQTl02zwOAVvXhzJeN0jZog+sgwLkhMO3xuvQY08z1c7LLS iRMn7l+2RyKH6Qe5Xl8Fc/VWVFXxcN/3rZlbjwLpZ6Ij3N+AuY5MS7w9OgW5vDeE98OTTcHY+zDu fIf63U5v/+5yCG/zZaD5PU3h//HyP2g9t/kKxj3y7o//zZZGVHHqFjVxK3RCLisN0Xf9vKe83R+/ t6Ij9jEEf9+/InFyV93u2w0rZ/74vSMe9PO6bcyenzetHuX53/Thz8vJ9vL9IyNeVsItuzWug7n2 +OgJLx6v233oi4TVRz/gMb+uSHxXDeE9+3RT8I/Pw3iDX8K4+cal60AdXRD7qpycnAeGU00xYvcv f99Y+hGe0bzzPCaGyariDgTqgU7qgLm8n798ad3/hcVcZ7GZINwNMNdNkX17WVp77IEXB4HuMARB oAshvKCIw3W7QZef/9kK9GsWGgR62gUBgb78WS3iDes+LTxjz3epEF7F5BXkCTnIkAo60D2lTAaz xLMnma9u99E29i/Ll802UyVAyeaRo1KgCjli2YNP359kF4iexliUoC0iAxsKZ1R8hGvpA6qY/WQf Vb63GsDt0pKfmu+QJUpXCZU70LpOZMf9/PVzwzY3z3U9qBbl38hzecPfIwFvCMC+C4+XXRhgjZdA CqGdFmcjNgXvqhmGSrmT0g93ghiCi1Ysib5hA8fVUMrA9eqB9rrhUyWRgH3clTsGEx9e+BHTS7et nUM0iVgcUex68AZ8X8fvzo8J/cPYZBqJxe7dWq0qg69a1WxjXXgfSlrzAG9kaFnd1jfwyXuW7F9T FTireyb+7hVg0n+OVGzRlKNwRN3TfzxmP4f27ZWN17vm3MLqBSKsG++ULnYMDg5mXotUNCQpzi+O NWhci0q8Ab7f52zVt04f9asZGhpKZfmFh4c7OHxyPmhIMkq91DU6imJvI6iuFhYWDe1HFvnrdltD amzbnRRo/oOKbS0tLY2NjVsBB45fess6eCASjUZbmJvzPf6coY2ay7yIJtYhmX2wmsJC+L178sLR tFrRFzo4HO4Y80HE3kz0ZYiltXXI2txApICYSV7PKAGVNjk8PLxr167295fk5e8tT+ihWYf4HgNO dmDlw8VXLgpJBpIrDBrp8snO0VGxmCZdXd0fSxv1SOZcYTBVkA+w7zIZYnJSkp5k/BOH1vZ2NWJH qurB6Ma5qEWgFWUwN8ft2s+v9lcmeYoXLzomu6ilpaenY9W3pruy2tvbS0tLr5/2WZ0x64AJfhcL 4Q12hMML9epv1tjKEcI2FdKMCMFLdxCIAdjhA5HFdoSi2a15SpWAqMb02NgafVTshU5W13RDpIB0 wrdc4wxJKSk7Qjhr6UeTE6fjDz99L3Vs0tA4/Z0fuPGPFWqHbozoi6YfUdfHlyeJI8pu0omJiSME VIaBpJSkpLmFxfxjJBJJLoJCzgiWWrbWqJ03trGhNP/8esgjsLy5jQui72u4mW2ysP4rV+jV2HWh CKi1re1xMTGVfeJo4gDkamZnf39/oU3Vu67pQHCwFxmY4J6eHuDJhiQZNHHt89jYWLBG+I+vLyBo OT3NLfND0Y1RUbwN8ndK+9PUg7a1TthHTkt8T9rcRDTIv2qZYDD8s01KRdbW1mZqvQh2wQtDNcNi 2SZ5TuVWzL0WJEXAUtzAAo+v1hZRSE7e3vQFgd1vj9btxlucPQSrC0nQzx7BI0zPJ6ROampqNjQ0 tMdHP3z4MO7m9eqqMC26xumkNhdDkq2dXVA4ZWAAsTLVJm1RdEYw6t4lmclVEDC3txOd24A5LbfX AohAZm5uLgZDRPQvNceJZ5u4BQT0bganAeNdWFDQ49lLJrt2FNQWZWiGYm8V773rxhC8m+qpzFyd tXC13F6ehJRaHvISirouZ1v93SBbBAzTCJi5vatd+LJSCO+GG2D+7OnjFPoo4VpmbI5b3M0vR9QQ h3fd3ftzWdV38P9F3AKBSndABucsQw7r2eqCgC+9G0bXi67aP/g/iZ1AugVVAAA= --Multipart_Thu__25_Jul_2002_22:07:46_+0300_08305648-- From wa@almesberger.net Thu Jul 25 23:17:26 2002 From: wa@almesberger.net (Werner Almesberger) Date: Thu, 25 Jul 2002 19:17:26 -0300 Subject: [LARTC] [tcng] make test errors In-Reply-To: <20020725220120.58c7c154.raptor@unacs.bg>; from raptor@unacs.bg on Thu, Jul 25, 2002 at 10:01:20PM +0300 References: <20020725220120.58c7c154.raptor@unacs.bg> Message-ID: <20020725191726.P1424@almesberger.net> raptor@unacs.bg wrote: > Additive headers at external interface (C): FAILED > Standard error: > | input in flex scanner failed Does changing the line tcsim -v -Xc,-tif:c tests/lib/additive.tcsim | \ to tcsim -v -Xc,-tif:c tests/lib/additive.tcsim -I tests/lib | \ help ? > Meanwhile on two Mandrake's 8.2 when I try "make rpm" it don't work ..... Hmm, how does it fail ? > if I try "checkinstall make install" i also can't make .rpm... What is "checkinstall" ? > .............OOOPS the kernel is 2.4.8 may be this is why this happen tcng should work with kernels as far back as 2.4.3. But the RPM build process looks for 2.4.18, yes. (It will happily take any other compatible kernel source tree if you change the name, though.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From wa@almesberger.net Thu Jul 25 23:54:31 2002 From: wa@almesberger.net (Werner Almesberger) Date: Thu, 25 Jul 2002 19:54:31 -0300 Subject: [LARTC] [tcng] make test errors In-Reply-To: <20020722205917.294daa93.raptor@unacs.bg>; from raptor@unacs.bg on Mon, Jul 22, 2002 at 08:59:17PM +0300 References: <20020722205917.294daa93.raptor@unacs.bg> Message-ID: <20020725195431.R1424@almesberger.net> raptor@unacs.bg wrote: > --> out > :17: warning: unused variable x > --> ref > :1: warning: unused variable x Your cpp seems to count the lines of a file included with -include as lines of the main source file. Which version of cpp does this ? (cpp --version and/or cpp -v &1 | grep CPP ) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From wa@almesberger.net Fri Jul 26 00:01:01 2002 From: wa@almesberger.net (Werner Almesberger) Date: Thu, 25 Jul 2002 20:01:01 -0300 Subject: [LARTC] [tcng] correct config? In-Reply-To: <20020722210547.6dfe1e49.raptor@unacs.bg>; from raptor@unacs.bg on Mon, Jul 22, 2002 at 09:05:47PM +0300 References: <20020722210547.6dfe1e49.raptor@unacs.bg> Message-ID: <20020725200101.S1424@almesberger.net> raptor@unacs.bg wrote: > Below is my tests and I have some questions regarding them : > first it seems that classification doesnt happen at all ?! and it is > clear from the u32 filters 'cause they point to classes 1:1 and 1:2 which > doesnt exist at all ? They're dsmark classes and don't need explicit creation. They simply set skb->tc_index to 1 and 2, respectively. > Also I can't figure out which filter got used u32 or tc_index but > 'cause tcism_plot generates only enqueed packed and no dequee-packets. BTW, if you want to see what exactly is going on, you may want to use tcsim -v -v -v ... | tcsim_pretty > They have same priority but u32 is attached at root so they should be > used, right ? Yes. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From David.Watson@team17.com Fri Jul 26 17:24:25 2002 From: David.Watson@team17.com (David Watson) Date: Fri, 26 Jul 2002 17:24:25 +0100 Subject: [LARTC] RTNETLINK answers: Invalid argument, fwmark Message-ID: <5.1.0.14.0.20020726171433.0301b1c8@mailgate.team17.com> I'm using htb classes on my firewall to queue traffic and implement different restrictions on different protocols. tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 190 tc class add dev eth0 parent 1: classid 1:3 htb rate 2mbit burst 30k tc class add dev eth0 parent 1:1 classid 1:90 htb rate 50kbit ceil 384kbit burst 5k tc qdisc add dev eth0 parent 1:90 handle 190: sfq perturb 10 tc qdisc add dev eth0 parent 1:3 handle 310: sfq perturb 10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw flowid 1:3 This last line gets a "RTNETLINK answers: Invalid argument" I'm using kernel 2.4.18 with the htb and wrr patches on both the kernel and on tc in the kernel .config I have: CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y I'm not really sure where else I could be going wrong, any advice would be greatly appreciated. _____________________________________________________________ David Watson, Network Manager, Team17 Software Ltd. Phone: +44-1924-267776 Fax: +44-1924-267658 _____________________________________________________________ From stef.coene@docum.org Fri Jul 26 18:39:57 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 26 Jul 2002 19:39:57 +0200 Subject: [LARTC] RTNETLINK answers: Invalid argument, fwmark In-Reply-To: <5.1.0.14.0.20020726171433.0301b1c8@mailgate.team17.com> References: <5.1.0.14.0.20020726171433.0301b1c8@mailgate.team17.com> Message-ID: <20020726173958.2C740DB99F@tartarus.telenet-ops.be> On Friday 26 July 2002 18:24, David Watson wrote: > I'm using htb classes on my firewall to queue traffic and implement > different restrictions on different protocols. > > tc qdisc del dev eth0 root > tc qdisc add dev eth0 root handle 1: htb default 190 > tc class add dev eth0 parent 1: classid 1:3 htb rate 2mbit burst 30k > tc class add dev eth0 parent 1:1 classid 1:90 htb rate 50kbit ceil 384k= bit > burst 5k > tc qdisc add dev eth0 parent 1:90 handle 190: sfq perturb 10 > tc qdisc add dev eth0 parent 1:3 handle 310: sfq perturb 10 > > > tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw flowid= 1:3 > > This last line gets a "RTNETLINK answers: Invalid argument" > > I'm using kernel 2.4.18 with the htb and wrr patches on both the kernel= and > on tc > in the kernel .config I have: > > CONFIG_IP_ADVANCED_ROUTER=3Dy > CONFIG_IP_MULTIPLE_TABLES=3Dy > CONFIG_IP_ROUTE_FWMARK=3Dy > > > =09I'm not really sure where else I could be going wrong, any advice wo= uld be > greatly appreciated. You attach class 1:90 to class 1:1, but you didn't create class 1:1 ?? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From raptor@unacs.bg Fri Jul 26 19:42:53 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Fri, 26 Jul 2002 21:42:53 +0300 Subject: [LARTC] [tcng] make test errors In-Reply-To: <20020725191726.P1424@almesberger.net> References: <20020725220120.58c7c154.raptor@unacs.bg> <20020725191726.P1424@almesberger.net> Message-ID: <20020726214253.47c9ab22.raptor@unacs.bg> |> Additive headers at external interface (C): FAILED |> Standard error: |> | input in flex scanner failed | |Does changing the line | tcsim -v -Xc,-tif:c tests/lib/additive.tcsim | \ |to | tcsim -v -Xc,-tif:c tests/lib/additive.tcsim -I tests/lib | \ |help ? ]- doesn't help :"[, will make the whole procedure again.. and some research so I can give more meaningful results |> Meanwhile on two Mandrake's 8.2 when I try "make rpm" it don't work ..... | |Hmm, how does it fail ? ]- This is on MDK8.1 -upgraded-> MDK8.2 ... the pure MDK 8.2 results I will post when I go to work .. I see now the problem may be 'cause I patch them with htb_patch :") make rpm=============== ............. cc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -I../shared -DVERSION=\"`cat ../VERSION`\" -DTOPDIR=\"/arh/compile/tcng/rpm/BUILD/tcng\" -c -o ext_io.o ext_io.c cc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -I../shared -DVERSION=\"`cat ../VERSION`\" -DTOPDIR=\"/arh/compile/tcng/rpm/BUILD/tcng\" -c -o ext_dump.o ext_dump.c cc -g -o tcc lex.yy.o y.tab.o tcc.o util.o error.o var.o data.o param.o device.o registry.o sprintf.o qdisc.o q_ingress.o q_cbq.o q_dsmark.o q_fifo.o q_gred.o q_prio.o q_htb.o q_red.o q_sfq.o q_tbf.o csp.o filter.o f_if.o f_fw.o f_route.o f_rsvp.o f_tcindex.o police.o tc.o op.o field.o named.o if_u32.o if_c.o if_ext.o iflib_actdb.o target.o location.o iflib_comb.o iflib_off.o iflib_misc.o iflib_red.o iflib_act.o iflib_arith.o iflib_not.o iflib_bit.o iflib_cheap.o iflib_newbit.o ext_all.o ext.o ext_io.o ext_dump.o -lfl -lm -L../shared -ltcngmisc cc: q_htb.o: No such file or directory make[2]: *** [tcc] Error 1 make[2]: Leaving directory `/arh/compile/tcng/rpm/BUILD/tcng/tcc' make[1]: *** [tcc] Error 2 make[1]: Leaving directory `/arh/compile/tcng/rpm/BUILD/tcng' error: Bad exit status from /var/tmp/rpm-tmp.2941 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.2941 (%build) make: *** [tcc-rpms] Error 1 |> if I try "checkinstall make install" i also can't make .rpm... | |What is "checkinstall" ? ]- It seems that I cant open their site(it seems to be down!!) at the moment here is it : http://asic-linux.com.mx/~izto/checkinstall/ In short the idea is instead of doing "make install" to invoke "checkinstall make install" and then checkinstall-program captures/intercepts which file operations and other stuff .... so that in u can create .rpm, .deb or slack-tgz packges.... All this happen in interactive mode.. I have used it many times for building .rpm's |> .............OOOPS the kernel is 2.4.8 may be this is why this happen | |tcng should work with kernels as far back as 2.4.3. But the RPM |build process looks for 2.4.18, yes. (It will happily take any |other compatible kernel source tree if you change the name, |though.) | |- Werner ]- raptor :") From raptor@unacs.bg Fri Jul 26 20:22:41 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Fri, 26 Jul 2002 22:22:41 +0300 Subject: [LARTC] [tcng] weird request Message-ID: <20020726222241.46f7903e.raptor@unacs.bg> Is there a way to count the childrens of a class i.e. I want to do something like this.. Explantion : $count = class(5).childrensCount; $rate = (0.7/$count); htb(rate 1Mbps, ceil 1Mbps) { class(5, rate 0.7Mbps, ceil 1Mbps) { class(rate $rate Mbps, ceil 0.6Mbps) {}; class(rate $rate Mbps, ceil 0.6Mbps) {}; class(rate $rate Mbps, ceil 0.5Mbps) {}; .............................. } class(rate 0.3Mbps, ceil 1Mbps) { ...similar thing } } So that rates scalles according to the count of the children... raptor@unacs.bg From robert@support4linux.com Sat Jul 27 00:23:46 2002 From: robert@support4linux.com (Robert Cole) Date: Fri, 26 Jul 2002 16:23:46 -0700 Subject: [LARTC] simple nat firewall Message-ID: <200207261623.46813.robert@support4linux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Before I even worry about a firewall I'm trying to get routing to happen=20 between the 2 nics in the machine I'm going to use for this. My table looks like this: fw1 root # ip route show 127.0.0.1 dev lo scope link 64.xx.xx.48/29 dev eth0 proto kernel scope link src 64.xx.xx.54 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1 default via 64.xx.xx.49 dev eth0 fw1 root # The main table looks like this: fw1 root # ip route list table main 127.0.0.1 dev lo scope link 64.xx.xx.48/29 dev eth0 proto kernel scope link src 64.xx.xx.54 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1 default via 64.xx.xx.49 dev eth0 fw1 root # I have to admit that I'm WAY out of practice in routing but I know I'm mi= ssing=20 something real simple here. As you can see I have a block of 5 IP's that = are=20 statically assigned to me and I'm trying to use just 1 .54 that I'll NAT = the=20 internal network to. Both interfaces on the router machine are working as= I=20 can SSH into both IP's (using 2 other systems each on the same network as= =20 each of the routers interfaces). When I try to ping thru the private interface to the outside world I get = no=20 responding and on the 3rd ping I get a report on the screen from 192.168.= 0.1=20 that the destination address is unreachable. I've looked at and studied the webpage=20 http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html but I'= m=20 not that familier with iptables. I was using ipchains a few years back to= =20 build a router before and I got it working. It's been over a year since I= =20 touched any routing anything so I was hoping someone might help me out he= re=20 and tell me where I'm going wrong. Its odd but I can look at those tables and see something wrong but I can'= t=20 quite put my finger on it. :( Please help. Thanks. Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9QdoCOWbzte5wVEURApnmAJ4/yUR5mGWrqBwqPt59MIiIjd3+mgCeLy7D RpMKjAiyLnNUYOkjSL+W+Qk=3D =3Dbxee -----END PGP SIGNATURE----- From amery@ing.puc.cl Sat Jul 27 04:20:10 2002 From: amery@ing.puc.cl (Alejandro Mery Pellegrini) Date: Fri, 26 Jul 2002 23:20:10 -0400 Subject: [LARTC] dhclient Message-ID: <006401c2351c$840bd6c0$0201a8c0@victoria> does anyone have dhclient-script (isc's dhcpc v3) for iproute2? i have ported most of it, but how do i remove aliases with the ip command? Best regards, Alejandro Mery From robert@support4linux.com Sat Jul 27 06:09:31 2002 From: robert@support4linux.com (Robert Cole) Date: Fri, 26 Jul 2002 22:09:31 -0700 Subject: [LARTC] basic NAT setup Message-ID: <200207262209.31839.robert@support4linux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a howto out there that I'm missing that show setting up NAT thru= 2=20 network cards and not ppp or pppoe? I'm using iproute2 and iptables to set all this up and I'm looking for a=20 little better example than I've been finding so far. Anyone? Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9QisLOWbzte5wVEURAhlQAJ9cJuaxQ0VZblaQR7Y9y+4qxma5AACfWniW mm1oCjDcVRuoV0SFmpLYsaY=3D =3Dlaxp -----END PGP SIGNATURE----- From robert@support4linux.com Sat Jul 27 07:00:41 2002 From: robert@support4linux.com (Robert Cole) Date: Fri, 26 Jul 2002 23:00:41 -0700 Subject: [LARTC] the answer Message-ID: <200207262300.41415.robert@support4linux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well the answer to my question about getting basic nat running was this: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE and of course the ol' echo 1 to ip_forward. I'm just real new to iptables and I hope this list turns out to be a good= =20 resource. Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9QjcJOWbzte5wVEURAs97AKCPw+Sq91BQIuMSQR4v9aonFjafwQCfX9av pIsCQd7RZcuWf3jCC19EAmE=3D =3DGAbx -----END PGP SIGNATURE----- From roche@upfrontsystems.co.za Sat Jul 27 18:56:05 2002 From: roche@upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan) Date: 27 Jul 2002 19:56:05 +0200 Subject: [LARTC] Bridge with Traffic shaping Message-ID: <1027792567.1954.32.camel@localhost.localdomain> Hi, I am fairly new to routing and traffic control but I with the help of the lartc howto I managed to setup a bridge with htb traffic control. The traffic shapping does not seem to work as I expected and I would really appreciate if somebody can tell my why this is the case. My setup: I have a DSL router connecting a /28 network to the internet. I put a linux box with 2 ethernet cards between my router and the rest of the subnet. I set up the linux box as an ethernet bridge where the 2 ethernet cards has no ip address and the bridge has an ip address. I patched the kernel with the IMQ patch so that I can shape incoming traffic. eth0 is connected to the router and eth1 is connect to the rest of the public subnet. I have an iptables rule that routes all traffic on eth1 to the imq device. I started with a very simple htb setup to make testing easier: #!/bin/bash tc qdisc del dev imq0 root ip link set imq0 down tc qdisc add dev imq0 root handle 1: htb default 12 tc class add dev imq0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit tc class add dev imq0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit tc class add dev imq0 parent 1:1 classid 1:11 htb rate 32kbit ceil 128kbit tc class add dev imq0 parent 1:1 classid 1:12 htb rate 32kbit ceil 128kbit tc filter add dev imq0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 196.44.35.53 flowid 1:10 tc filter add dev imq0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 196.44.35.54 flowid 1:10 tc filter add dev imq0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 196.44.35.55 flowid 1:10 tc filter add dev imq0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 196.44.35.51 flowid 1:11 tc filter add dev imq0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 196.44.35.52 flowid 1:11 iptables -F iptables -X iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0 ip link set imq0 up My problem is that all traffic seems to go through the default htb class although there are lots of traffic matching the other 2 classes. root@griet root # tc -d -s class show dev imq0 class htb 1:1 root prio 0 rate 128Kbit ceil 128Kbit burst 1753b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 1638 level 3=20 Sent 13194 bytes 147 pkts (dropped 0, overlimits 0)=20 rate 7bps=20 lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 101 ctokens: 101 class htb 1:10 parent 1:1 prio 0 rate 64Kbit ceil 128Kbit burst 1679b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 819 level 0=20 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)=20 lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 205 ctokens: 107 class htb 1:11 parent 1:1 prio 0 rate 32Kbit ceil 128Kbit burst 1638b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 409 level 0=20 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)=20 lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 400 ctokens: 107 class htb 1:12 parent 1:1 prio 0 rate 32Kbit ceil 128Kbit burst 1638b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 409 level 0=20 Sent 13194 bytes 147 pkts (dropped 0, overlimits 0)=20 rate 7bps=20 lended: 147 borrowed: 0 giants: 0 injects: 0 tokens: 373 ctokens: 101 Any help would be greatly appreciated. --=20 Roch=E9 Compaan Upfront Systems http://www.upfrontsystems.co.za From ch@westend.com Sat Jul 27 23:58:31 2002 From: ch@westend.com (Christian Hammers) Date: Sun, 28 Jul 2002 00:58:31 +0200 Subject: [LARTC] Change of option names should be documented. Message-ID: <20020727225831.GA25059@westend.com> Hi In "tc add filter .. fw ..": "prio" was apparently renamed to "preference" and "flowid" to "classid". The manual examples still often uses this term, it should be annotated or replace because it confuses. bye, -christian- -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 ch@westend.com Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller From ch@westend.com Sun Jul 28 03:46:25 2002 From: ch@westend.com (Christian Hammers) Date: Sun, 28 Jul 2002 04:46:25 +0200 Subject: [LARTC] ingress policier only "overlimit" but not "drop" In-Reply-To: <20020727225831.GA25059@westend.com> References: <20020727225831.GA25059@westend.com> Message-ID: <20020728024625.GC25059@westend.com> Hi My ingress policies _seems_ to work but the statistics are somwhat strange: When sending only 4 SYN packets, they are passed and counted in neither "dropped" nor "overlimit". When sending 40 SYN packets they are also only show up in "overlimits" and not "dropped" although they should be above the (testing) values I've choosen! Why? I also wonder why the counters at the ingress qdisc never increase? I'm using linux kernel 2.4.18 with IMQ patch (IMQ not enabled). thanks, -christian- --- qdisc --- qdisc ingress ffff: dev eth0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) --- filter --- filter protocol ip pref 49152 fw filter protocol ip pref 49152 fw handle 0x14 classid :1 police 28 action drop rate 200bps burst 159b mtu 320b peakrate 400bps Sent 1920 bytes 48 pkts (dropped 0, overlimits 33) ---------------------------------------------------------------------------- $TC qdisc add \ dev eth0 \ handle ffff: \ ingress # testing with 40byte tcp syn packets # rate: 5 SYN packets = 200 bytes/s = 1600 bit/s # peak: 10 SYN packets = 400 bytes/s = 3200 bit/s $TC filter add \ dev eth0 \ protocol ip \ parent ffff: \ handle 20 \ fw \ police \ rate 1600 burst 160 \ peakrate 3200 mtu 320 \ drop \ classid :1 # tag all incoming SYN packets through eth0 as mark value 20. # (20 is an arbitrary number) $IPT -A PREROUTING -t mangle -i eth0 -p tcp --syn -j MARK --set-mark 20 -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 ch@westend.com Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller From amery@ing.puc.cl Sun Jul 28 08:07:48 2002 From: amery@ing.puc.cl (Alejandro Mery Pellegrini) Date: Sun, 28 Jul 2002 03:07:48 -0400 Subject: [LARTC] dhclient References: <006401c2351c$840bd6c0$0201a8c0@victoria> Message-ID: <001301c23605$83a01cc0$0201a8c0@victoria> hi :< how do i write 'ifconfig eth1:0- init 0' in iproute2 sintaxis? and.... how does a route add -host looks like? Please..... i really need your help. Best Regards, Alejandro Mery ----- Original Message ----- From: "Alejandro Mery Pellegrini" To: "NG LARTC" Sent: Friday, July 26, 2002 11:20 PM Subject: [LARTC] dhclient > does anyone have dhclient-script (isc's dhcpc v3) for iproute2? > > i have ported most of it, but how do i remove aliases with the ip command? > > Best regards, > Alejandro Mery > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From ch@westend.com Sun Jul 28 12:02:24 2002 From: ch@westend.com (Christian Hammers) Date: Sun, 28 Jul 2002 13:02:24 +0200 Subject: [LARTC] "For ethernet, no packet uses less than 64 bytes" - why? Message-ID: <20020728110224.GA7262@westend.com> Hi Well, subject says all. In Chapter 9.2.2.1, TBF, the parameter mpu or "minimum packet size" is explained as: > A zero-sized packet does not use zero bandwidth. For ethernet, no packet > uses less than 64 bytes. The Minimum Packet Unit determines the minimal > token usage for a packet. In my understanding an ethernet packet needs at least 14 (2*6+2) bytes or 54 bytes if there's an ip header present. If this is a kernel issue it should be noted. To which layer does the term "zero-sized" apply anyway? I mean, how can I tell C to send "nothing"? bye, -christian- -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 ch@westend.com Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller From ch@westend.com Sun Jul 28 12:30:01 2002 From: ch@westend.com (Christian Hammers) Date: Sun, 28 Jul 2002 13:30:01 +0200 Subject: [LARTC] [patch] Improvements for the TBF chapter In-Reply-To: <20020728110224.GA7262@westend.com> References: <20020728110224.GA7262@westend.com> Message-ID: <20020728113001.GA14592@westend.com> Hi Please consider applying this patch: - Clearifies the relation between 'rate' and 'burst' - Corrects statement about non-existing input qdisc (-> IMQ) bye, -christian- Index: lartc.db =================================================================== RCS file: /var/cvsroot/2.4routing/lartc.db,v retrieving revision 1.12 diff -u -B -b -r1.12 lartc.db --- lartc.db 20 Jul 2002 14:44:26 -0000 1.12 +++ lartc.db 28 Jul 2002 11:25:06 -0000 @@ -2102,18 +2102,27 @@ -burst/buffer/maxburst +rate and burst/buffer/maxburst -Size of the bucket, in bytes. This is the maximum amount of bytes that -tokens can be available for instantaneously. In general, larger shaping -rates require a larger buffer. For 10mbit/s on Intel, you need at least -10kbyte buffer if you want to reach your configured rate! +Rate is the amount of tokens that are tried to put into the bucket every +second specified in mbit/s. + + +Burst is the size of the bucket, in bytes. This is the maximum amount of bytes +that tokens can be available for instantaneously. - -If your buffer is too small, packets may be dropped because more tokens -arrive per timer tick than fit in your bucket. +In general, larger shaping rates require a larger buffer. Remember that if +your buffer is too small, packets may be dropped because regardless how +much tokens the 'rate' parameter tries to put in the bucket, the ones that +actually fit into it are not sufficient for all waiting data. + +To archive a throughput of 10mbit/s on Intel you have to set the buffer +to 12.8kbyte. Calculation: On Intel the kernel HZ variable is 100, which means +that the token filler function is called 100 times per second. 100 times +12.8kbyte are 1310720byte or 10485760bit that are pushed into the bucket - +assuming a high enough value for the rate variable. @@ -2125,13 +2134,6 @@ token usage for a packet. - -rate - - -The speedknob. See remarks above about limits! - - @@ -2502,8 +2504,10 @@ Delaying or dropping packets in order to make traffic stay below a -configured bandwidth. In Linux, policing can only drop a packet and not -delay it - there is no 'ingress queue'. +configured bandwidth. In Linux, policing used to be only able to drop a packet +and not delay it - there was no 'ingress queue'. A currently developed solution +is the 'intermediate queueing device' (IMQ). It is discussed in a seperate +chapter. -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 ch@westend.com Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller From stef.coene@docum.org Sun Jul 28 16:16:37 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 28 Jul 2002 17:16:37 +0200 Subject: [LARTC] dhclient In-Reply-To: <001301c23605$83a01cc0$0201a8c0@victoria> References: <006401c2351c$840bd6c0$0201a8c0@victoria> <001301c23605$83a01cc0$0201a8c0@victoria> Message-ID: <20020728151638.A0E9CDBEEF@tartarus.telenet-ops.be> On Sunday 28 July 2002 09:07, Alejandro Mery Pellegrini wrote: > hi :< > > how do i write 'ifconfig eth1:0- init 0' in iproute2 sintaxis? > and.... how does a route add -host looks like? > > Please..... i really need your help. You don't have alias in iproute like you have with the old util ipconfig. ip link show : shows the devices ip add show : shows the addresses A NIC has multiple addresses. So you can have more then 1 address / NIC=20 without having 1 primary and mutiple addresses. All addresses are equal. Stef From stef.coene@docum.org Sun Jul 28 16:21:19 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 28 Jul 2002 17:21:19 +0200 Subject: [LARTC] Bridge with Traffic shaping In-Reply-To: <1027792567.1954.32.camel@localhost.localdomain> References: <1027792567.1954.32.camel@localhost.localdomain> Message-ID: <20020728152120.6F855DC212@tartarus.telenet-ops.be> On Saturday 27 July 2002 19:56, Roch=E9 Compaan wrote: > Hi, > > I am fairly new to routing and traffic control but I with the > help of the lartc howto I managed to setup a bridge with htb > traffic control. The traffic shapping does not seem to work > as I expected and I would really appreciate if somebody > can tell my why this is the case. > > My setup: > I have a DSL router connecting a /28 network to the internet. > I put a linux box with 2 ethernet cards between my router and > the rest of the subnet. I set up the linux box as an ethernet > bridge where the 2 ethernet cards has no ip address and the > bridge has an ip address. I patched the kernel with the IMQ > patch so that I can shape incoming traffic. eth0 is connected > to the router and eth1 is connect to the rest of the public > subnet. I have an iptables rule that routes all traffic on eth1 > to the imq device. If you put all incoming traffic on eth1 in the imq device, why don't you = use=20 the outgoing traffic on eth0 do the same shaping? All traffic entering t= he=20 box on eth1 leaves the box on eth0. That way you don't need the imq devi= ce. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From roche@upfrontsystems.co.za Mon Jul 29 06:27:49 2002 From: roche@upfrontsystems.co.za (=?iso-8859-1?Q?Roch=E9_Compaan?=) Date: Mon, 29 Jul 2002 07:27:49 +0200 Subject: [LARTC] Bridge with Traffic shaping In-Reply-To: <20020728152120.6F855DC212@tartarus.telenet-ops.be> Message-ID: > On Saturday 27 July 2002 19:56, Roch=E9 Compaan wrote: > > Hi, > > > > I am fairly new to routing and traffic control but I with the > > help of the lartc howto I managed to setup a bridge with htb > > traffic control. The traffic shapping does not seem to work > > as I expected and I would really appreciate if somebody > > can tell my why this is the case. > > > > My setup: > > I have a DSL router connecting a /28 network to the internet. > > I put a linux box with 2 ethernet cards between my router and > > the rest of the subnet. I set up the linux box as an ethernet > > bridge where the 2 ethernet cards has no ip address and the > > bridge has an ip address. I patched the kernel with the IMQ > > patch so that I can shape incoming traffic. eth0 is connected > > to the router and eth1 is connect to the rest of the public > > subnet. I have an iptables rule that routes all traffic on eth1 > > to the imq device. > If you put all incoming traffic on eth1 in the imq device, why=20 > don't you use=20 > the outgoing traffic on eth0 do the same shaping? All traffic=20 > entering the=20 > box on eth1 leaves the box on eth0. That way you don't need the=20 > imq device. If I understand correctly I can shape incoming traffic by setting up a qdisc on eth0 and filters that match any of the ip addresses in my public subnet sitting behind the linux box that currently does the traffic shaping. Ok, I tried this but all traffic still seems to match only the default htb class. Here's my tc script: #!/bin/bash tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 htb rate 128kbit ceil = 128kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil = 128kbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate 32kbit ceil = 128kbit tc class add dev eth0 parent 1:1 classid 1:12 htb rate 32kbit ceil = 128kbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.53 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.54 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.55 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.51 flowid 1:11 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.52 flowid 1:11 And this is the ouput of "tc -s -d class show dev eth0": class htb 1:1 root prio 0 rate 128Kbit ceil 128Kbit burst 1753b/8 mpu 0b = cburst 1753b/8 mpu 0b quantum 1638 level 3=20 Sent 83954 bytes 576 pkts (dropped 0, overlimits 0)=20 rate 30bps=20 lended: 114 borrowed: 0 giants: 0 injects: 0 tokens: 101 ctokens: 101 class htb 1:10 parent 1:1 prio 0 rate 64Kbit ceil 128Kbit burst 1679b/8 = mpu 0b cburst 1753b/8 mpu 0b quantum 819 level 0=20 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)=20 lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 205 ctokens: 107 class htb 1:12 parent 1:1 prio 0 rate 32Kbit ceil 128Kbit burst 1638b/8 = mpu 0b cburst 1753b/8 mpu 0b quantum 409 level 0=20 Sent 12864 bytes 215 pkts (dropped 0, overlimits 0)=20 rate 30bps=20 lended: 215 borrowed: 0 giants: 0 injects: 0 tokens: 387 ctokens: 104 class htb 1:11 parent 1:1 prio 0 rate 32Kbit ceil 128Kbit burst 1638b/8 = mpu 0b cburst 1753b/8 mpu 0b quantum 409 level 0=20 Sent 71090 bytes 361 pkts (dropped 0, overlimits 97)=20 lended: 247 borrowed: 114 giants: 0 injects: 0 tokens: 373 ctokens: 101 No packets seem to match any of the other classes although tcpdump confirms that there are definitely traffic destined for the ip addresses mentioned in my filters. --=20 Roch=E9 Compaan Upfront Systems http://www.upfrontsystems.co.za=20 From cke@highlandshighspeed.net Mon Jul 29 07:05:15 2002 From: cke@highlandshighspeed.net (Chris K Ellsworth) Date: Sun, 28 Jul 2002 23:05:15 -0700 Subject: [LARTC] Bridge with Traffic shaping References: Message-ID: <000901c236c5$e8ce0bf0$f9c9d8c0@highlandshighspeed.net> what kinda bridge are you using? bridge-nf? if you are it says it only supports iptables, you would have to mark the packets then use filter to put the marked packets into teh correct queue for managing ----- Original Message ----- From: "Roché Compaan" To: "Stef Coene" ; Sent: Sunday, July 28, 2002 10:27 PM Subject: RE: [LARTC] Bridge with Traffic shaping > On Saturday 27 July 2002 19:56, Roché Compaan wrote: > > Hi, > > > > I am fairly new to routing and traffic control but I with the > > help of the lartc howto I managed to setup a bridge with htb > > traffic control. The traffic shapping does not seem to work > > as I expected and I would really appreciate if somebody > > can tell my why this is the case. > > > > My setup: > > I have a DSL router connecting a /28 network to the internet. > > I put a linux box with 2 ethernet cards between my router and > > the rest of the subnet. I set up the linux box as an ethernet > > bridge where the 2 ethernet cards has no ip address and the > > bridge has an ip address. I patched the kernel with the IMQ > > patch so that I can shape incoming traffic. eth0 is connected > > to the router and eth1 is connect to the rest of the public > > subnet. I have an iptables rule that routes all traffic on eth1 > > to the imq device. > If you put all incoming traffic on eth1 in the imq device, why > don't you use > the outgoing traffic on eth0 do the same shaping? All traffic > entering the > box on eth1 leaves the box on eth0. That way you don't need the > imq device. If I understand correctly I can shape incoming traffic by setting up a qdisc on eth0 and filters that match any of the ip addresses in my public subnet sitting behind the linux box that currently does the traffic shaping. Ok, I tried this but all traffic still seems to match only the default htb class. Here's my tc script: #!/bin/bash tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate 32kbit ceil 128kbit tc class add dev eth0 parent 1:1 classid 1:12 htb rate 32kbit ceil 128kbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.53 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.54 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.55 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.51 flowid 1:11 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip dst 196.xx.yy.52 flowid 1:11 And this is the ouput of "tc -s -d class show dev eth0": class htb 1:1 root prio 0 rate 128Kbit ceil 128Kbit burst 1753b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 1638 level 3 Sent 83954 bytes 576 pkts (dropped 0, overlimits 0) rate 30bps lended: 114 borrowed: 0 giants: 0 injects: 0 tokens: 101 ctokens: 101 class htb 1:10 parent 1:1 prio 0 rate 64Kbit ceil 128Kbit burst 1679b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 819 level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 205 ctokens: 107 class htb 1:12 parent 1:1 prio 0 rate 32Kbit ceil 128Kbit burst 1638b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 409 level 0 Sent 12864 bytes 215 pkts (dropped 0, overlimits 0) rate 30bps lended: 215 borrowed: 0 giants: 0 injects: 0 tokens: 387 ctokens: 104 class htb 1:11 parent 1:1 prio 0 rate 32Kbit ceil 128Kbit burst 1638b/8 mpu 0b cburst 1753b/8 mpu 0b quantum 409 level 0 Sent 71090 bytes 361 pkts (dropped 0, overlimits 97) lended: 247 borrowed: 114 giants: 0 injects: 0 tokens: 373 ctokens: 101 No packets seem to match any of the other classes although tcpdump confirms that there are definitely traffic destined for the ip addresses mentioned in my filters. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From roche@upfrontsystems.co.za Mon Jul 29 07:22:24 2002 From: roche@upfrontsystems.co.za (=?iso-8859-1?Q?Roch=E9_Compaan?=) Date: Mon, 29 Jul 2002 08:22:24 +0200 Subject: [LARTC] Bridge with Traffic shaping In-Reply-To: <000901c236c5$e8ce0bf0$f9c9d8c0@highlandshighspeed.net> Message-ID: > what kinda bridge are you using? > bridge-nf? if you are it says it only supports iptables, you would = have to > mark the packets then use filter to put the marked packets into=20 > teh correct > queue for managing Yes I'm using bridge-nf, but as far as I understand bridge-nf doesn't require iptables for shaping - you only need to patch your kernel if you _want_ to use iptables. I am in any case not using "fw" but using "u32" which should match anything in a packet header. --=20 Roch=E9 Compaan Upfront Systems http://www.upfrontsystems.co.za=20 From stef.coene@docum.org Mon Jul 29 13:54:59 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 29 Jul 2002 14:54:59 +0200 Subject: [LARTC] Bridge with Traffic shaping In-Reply-To: References: Message-ID: <20020729125352.6F09E3FC3@outpost.ds9a.nl> > If I understand correctly I can shape incoming traffic by setting > up a qdisc on eth0 and filters that match any of the ip addresses > in my public subnet sitting behind the linux box that currently does > the traffic shaping. But all traffic coming on eth0 is leaving eht1 and vice versa. So shapin= g=20 incoming traffic on eth0 is the same as shaping outgoing traffic on eth1. > No packets seem to match any of the other classes although tcpdump > confirms that there are definitely traffic destined for the ip addresse= s > mentioned in my filters. Mhh. It should work. I will think about it tonight. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From sumit@elitecore.com Mon Jul 29 14:14:52 2002 From: sumit@elitecore.com (Sumit Pandya) Date: Mon, 29 Jul 2002 18:44:52 +0530 Subject: [LARTC] Oops with IMQ Ingress In-Reply-To: <20020502100104.7CF17C6516@outpost.powerdns.com> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C23730.067BCDD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, Is there any bug in Ingress for IMQ? I get Oops with following setup /sbin/modprobe imq iptables -I POSTROUTING -t mangle -j IMQ iptables -I PREROUTING -t mangle -j IMQ #Making imq0 enable /sbin/ip link set imq0 up #Adding root /sbin/tc qdisc del dev imq0 root #Diverting unclassified traffic to default class. /sbin/tc qdisc add dev imq0 root handle 1: htb default 1 #Default traffic class /sbin/tc class add dev imq0 parent 1:0 classid 1:1 htb rate 100mbps tc class add dev imq0 parent 1:2 classid 1:10 htb rate 50kbps ceil 50kbps tc class add dev imq0 parent 1:2 classid 1:11 htb rate 50kbps ceil 50kbps tc filter add dev imq0 protocol ip parent 1:0 prio 1 handle 800::1 u32 match ip dst 192.9.203.70 match ip sport 80 0xffff flowid 1:10 tc filter add dev imq0 protocol ip parent 1:0 prio 1 handle 800::3 u32 match ip src 192.9.203.139 match ip dport 80 0xffff flowid 1:10 Now when I do http download my system crashes when download reaches somewhere between 100K and 200K. Most surprising observation in this is system crash happens only when I do download from simultanious connection tool DAP (Download Accelarator Plus). I know in above setup one problem is there that a packet will get pass 2 from IMQ. I'm useing kernel-2.4.18 from redhat rpm and patched with imq-2.4.18.diff-10.txt, and htb3.6_2.4.17.diff Now let me clear my question why I asked Ingress... In above setup if i remove "iptables -I PREROUTING -t mangle -j IMQ" then no kernel oops. Attechment is Oops on serial-console. -- Sumit ------=_NextPart_000_0002_01C23730.067BCDD0 Content-Type: application/octet-stream; name="2.4bug.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="2.4bug.log" Unable to handle kernel NULL pointer dereference at virtual address = 00000020=0A= =0D*pde =3D 00000000=0A= =0DOops: 0002=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DCPU: 0=0A= =0DEIP: 0010:[] Not tainted=0A= =0DEFLAGS: 00010002=0A= =0DEIP is at do_page_fault [kernel] 0x77 (2.4.18-3elite)=0A= =0Deax: 00000020 ebx: c02e6000 ecx: 00000018 edx: c02e6000=0A= =0Desi: 00000004 edi: 00000020 ebp: 00000000 esp: c02e6004=0A= =0Dds: 0018 es: 0018 ss: 0018=0A= =0DProcess 4=C0=01 (pid: 365, stackpage=3Dc02e5000)=0A= =0DStack: c02e6000 c57b48c0 c02e6000 00000004 c8802400 00030001 c7fa1160 = c0195a3a =0A= =0D c7fa1000 c7fa1160 c8802400 00000000 00000013 c7bc8940 0000a33a = 0000000a =0A= =0D c02e608c c0109c7a 0000000a c7fa1000 00000004 c8802400 c7fa1000 = c7fa1160 =0A= =0DCall Trace: [] rtl8139_interrupt [kernel] 0xba =0A= =0D[] handle_IRQ_event [kernel] 0x3a =0A= =0D[] rtl8139_interrupt [kernel] 0xba =0A= =0D[] handle_IRQ_event [kernel] 0x3a =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] nf_hook_slow [kernel] 0xe7 =0A= =0D[] ip_forward [kernel] 0x1ed =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] sockfs_delete_dentry [kernel] 0x8 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] fifo_dump [kernel] 0x18 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] nf_hook_slow [kernel] 0xe7 =0A= =0D[] ip_forward [kernel] 0x1ed =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] fifo_dump [kernel] 0x18 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] sockfs_delete_dentry [kernel] 0x8 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] nf_hook_slow [kernel] 0xe7 =0A= =0D[] ip_forward [kernel] 0x1ed =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] nf_hook_slow [kernel] 0xe7 =0A= =0D[] ip_forward [kernel] 0x1ed =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] fifo_dump [kernel] 0x18 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] nf_hook_slow [kernel] 0xe7 =0A= =0D[] ip_forward [kernel] 0x1ed =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] sockfs_delete_dentry [kernel] 0x8 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_forward_finish [kernel] 0x36 =0A= =0D[] nf_hook_slow [kernel] 0xe7 =0A= =0D[] ip_forward [kernel] 0x1ed =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] ip_finish_output [kernel] 0xff =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_iterate [kernel] 0x37 =0A= =0D[] ip_forward_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_rcv_finish [kernel] 0x1a9 =0A= =0D[] nf_reinject [kernel] 0xa2 =0A= =0D[] nf_reinject [kernel] 0x165 =0A= =0D[] htb_delay_by [sch_htb] 0x66 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] sockfs_delete_dentry [kernel] 0x8 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_refrag [ip_conntrack] 0x26 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] nf_hook_slow [kernel] 0xd6 =0A= =0D[] imq_egress_ipv4 [imq] 0x0 =0A= =0D[] ip_finish_output2 [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] qdisc_restart [kernel] 0x14 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] nulldevname.0 [ip_tables] 0x0 =0A= =0D[] imq_skb_destructor [imq] 0x0 =0A= =0D[] imq_nf_queue [imq] 0x13e =0A= =0D[] ip_rcv_finish [kernel] 0x0 =0A= =0D[] ipt_route_hook [iptable_mangle] 0x20 =0A= =0D[] nf_queue [kernel] 0xe1 =0A= =0D[] ip_rcv_finish [kernel] 0x0 =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0D[] ip_rcv_finish [kernel] 0x0 =0A= =0D[] htb_dequeue [sch_htb] 0x1d1 =0A= =0D[] net_rx_action [kernel] 0x1aa =0A= =0D[] net_tx_action [kernel] 0x9e =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] default_idle [kernel] 0x0 =0A= =0D[] schedule [kernel] 0x66 =0A= =0D[] default_idle [kernel] 0x0 =0A= =0D[] stext [kernel] 0x0 =0A= =0D[] cpu_idle [kernel] 0x29 =0A= =0DCode: ff 00 0f 88 dc 03 00 00 57 56 e8 3a 33 01 00 59 89 c5 85 ed =0A= =0D <1>Unable to handle kernel NULL pointer dereference at virtual = address 00000000=0A= =0D printing eip:=0A= =0Dc011d0a6=0A= =0D*pde =3D 00000000=0A= =0DOops: 0002=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DCPU: 0=0A= =0DEIP: 0010:[] Not tainted=0A= =0DEFLAGS: 00010082=0A= =0DEIP is at del_timer [kernel] 0x16 (2.4.18-3elite)=0A= =0Deax: 00000000 ebx: 00000202 ecx: c02e40dc edx: c11c9720=0A= =0Desi: 00000000 edi: c02e4000 ebp: 0000000b esp: c02e5ecc=0A= =0Dds: 0018 es: 0018 ss: 0018=0A= =0DProcess 4=C0=01 (pid: 365, stackpage=3Dc02e5000)=0A= =0DStack: 00000000 c0118ad0 c02e40dc 00000002 c7b6602c c8802400 c022b62e = c02e5fd0 =0A= =0D 00000002 c024765a 00000018 c0230018 ffffff00 c0108e74 00000010 = 00000000 =0A= =0D 00000000 c02e5fd0 00000002 c0112637 0000000b c02e5fd0 00000002 = c02e4000 =0A= =0DCall Trace: [] do_exit [kernel] 0x60 =0A= =0D[] die [kernel] 0x54 =0A= =0D[] do_page_fault [kernel] 0x327 =0A= =0D[] handle_IRQ_event [kernel] 0x3a =0A= =0D[] do_IRQ [kernel] 0x9c =0A= =0D[] rtl8139_interrupt [kernel] 0xba =0A= =0D[] handle_IRQ_event [kernel] 0x3a =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] rwsem_wake [kernel] 0xde8 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0DCode: 89 10 b8 01 00 00 00 c7 41 04 00 00 00 00 c7 01 00 00 00 00 =0A= =0D <1>Unable to handle kernel NULL pointer dereference at virtual = address 00000000=0A= =0D printing eip:=0A= =0Dc011d0a6=0A= =0D*pde =3D 00000000=0A= =0DOops: 0002=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DCPU: 0=0A= =0DEIP: 0010:[] Not tainted=0A= =0DEFLAGS: 00010082=0A= =0DEIP is at del_timer [kernel] 0x16 (2.4.18-3elite)=0A= =0Deax: 00000000 ebx: 00000202 ecx: c02e40dc edx: c11c9720=0A= =0Desi: 00000000 edi: c02e4000 ebp: 0000000b esp: c02e5d94=0A= =0Dds: 0018 es: 0018 ss: 0018=0A= =0DProcess 4=C0=01 (pid: 365, stackpage=3Dc02e5000)=0A= =0DStack: 00000000 c0118ad0 c02e40dc 00000002 00000001 c7cc4000 c022b62e = c02e5e98 =0A= =0D 00000002 c024765a 00000018 c0230018 ffffff00 c0108e74 00000010 = 00000000 =0A= =0D 00000000 c02e5e98 00000002 c0112637 0000000b c02e5e98 00000002 = c02e4000 =0A= =0DCall Trace: [] do_exit [kernel] 0x60 =0A= =0D[] die [kernel] 0x54 =0A= =0D[] do_page_fault [kernel] 0x327 =0A= =0D[] imq_ingress_ipv4 [imq] 0x0 =0A= =0D[] ip_rcv [kernel] 0x36b =0A= =0D[] ip_rcv_finish [kernel] 0x0 =0A= =0D[] net_rx_action [kernel] 0x1aa =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] del_timer [kernel] 0x16 =0A= =0D[] do_exit [kernel] 0x60 =0A= =0D[] die [kernel] 0x54 =0A= =0D[] do_page_fault [kernel] 0x327 =0A= =0D[] handle_IRQ_event [kernel] 0x3a =0A= =0D[] do_IRQ [kernel] 0x9c =0A= =0D[] rtl8139_interrupt [kernel] 0xba =0A= =0D[] handle_IRQ_event [kernel] 0x3a =0A= =0D[] do_page_fault [kernel] 0x0 =0A= =0D[] error_code [kernel] 0x34 =0A= =0D[] rwsem_wake [kernel] 0xde8 =0A= =0D[] do_page_fault [kernel] 0x77 =0A= =0DCode: 89 10 b8 01 00 00 00 c7 41 04 00 00 00 00 c7 01 00 00 00 00 =0A= =0D <1>Unable to handle kernel NULL pointer dereference at virtual = address %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle = ipt_multiport ipt_REJECT ipt=0A= =0DCPU: %EIP: %:[<%8lx>] =0A= =0DEFLAGS: %8lx=0A= =0DEIP is at del_timer [kernel] 0x% (2.4.18-3elite)=0A= =0Deax: %8lx ebx: %8lx ecx: %8lx edx: %8lx=0A= =0Desi: %8lx edi: %8lx ebp: %8lx esp: %8lx=0A= =0Dds: % es: % ss: %Process 4=C0=01 (pid: %, stackpage=3D%8lx)=0A= =0DStack: %8lx %8lx %8lx %8lx %8lx %8lx %8lx %8lx =0A= =0D %8lx %8lx %8lx %8lx %8lx %8lx %8lx %8lx =0A= =0D %8lx %8lx %8lx %8lx %8lx %8lx %8lx %8lx =0A= =0DCall Trace: [<%8lx>] ^U=E8=C97 =0A= =0D[<%8lx>] [^_=E9=F4=FB =0A= =0D[<%8lx>] j =0A= =0D[<%8lx>] =E0f=88=C8=9C=F7=87=C8 =0A= =0D[<%8lx>] =83=C4=1C=EB"=FF=05=04=E44=C0=8BGxHt=0A= =0D=FFOx=0F=94=C0=84=C0t=07W=E8D=BC=FE=FFZ=B8=01 =0A= =0D[<%8lx>] = UWVS=83=EC=10=8B|$$=8BG0=8Bo=18=8B=8Bw(=85=C0u"U=0F=B6F=01P=8BV=0CR=8BF=10= PW=E8=B4=D7=FF=FF=83=C4=14=85=C0=0F=85=7F=01 =0A= =0D[<%8lx>] =83=C4=0C=EB=18=90=90=8BFxHt=0A= =0D=FFOx=0F=94=C0=84=C0t=07V=E8=BA=BD=FF=FFX=8BT$=04=FF=8A=DC =0A= =0D[<%8lx>] UW=0F =D7VS=81=EC=8C =0A= =0D[<%8lx>] =83=C4=08=EB=9A=8Dv =0A= =0D[<%8lx>] =89=10=B8=01 =0A= =0D[<%8lx>] ^U=E8=C97 =0A= =0D[<%8lx>] [^_=E9=F4=FB =0A= =0D[<%8lx>] j =0A= =0D[<%8lx>] =E0f=88=C8=9C=F7=87=C8 =0A= =0D[<%8lx>] =83=C4=1C=EB"=FF=05=04=E44=C0=8BGxHt=0A= =0D=FFOx=0F=94=C0=84=C0t=07W=E8D=BC=FE=FFZ=B8=01 =0A= =0D[<%8lx>] = UWVS=83=EC=10=8B|$$=8BG0=8Bo=18=8B=8Bw(=85=C0u"U=0F=B6F=01P=8BV=0CR=8BF=10= PW=E8=B4=D7=FF=FF=83=C4=14=85=C0=0F=85=7F=01 =0A= =0D[<%8lx>] =83=C4=0C=EB=18=90=90=8BFxHt=0A= =0D=FFOx=0F=94=C0=84=C0t=07V=E8=BA=BD=FF=FFX=8BT$=04=FF=8A=DC =0A= =0D[<%8lx>] UW=0F =D7VS=81=EC=8C =0A= =0D[<%8lx>] =83=C4=08=EB=9A=8Dv =0A= =0D[<%8lx>] =89=10=B8=01 =0A= =0D[<%8lx>] ^U=E8=C97 =0A= =0D[<%8lx>] [^_=E9=F4=FB =0A= =0D[<%8lx>] j =0A= =0D[<%8lx>] =8B[=14=83=C4=0C=85=DBu=E2=F7=C6 =0A= =0D[<%8lx>] [=B8=01 =0A= =0D[<%8lx>] =83=C4=0C=F7=C3=08 =0A= =0D[<%8lx>] =8B[=14=83=C4=0C=85=DBu=E2=F7=C6 =0A= =0D[<%8lx>] UW=0F =D7VS=81=EC=8C =0A= =0D[<%8lx>] =83=C4=08=EB=9A=8Dv =0A= =0D[<%8lx>] = =E9Uh=F2=FFQP1=C0=F3=ABXY=C1=E1=02=E9C=ED=F2=FF=C1=E1=02=E9=D7=EF=F2=FF=C1= =E1=02=E9X=F0=F2=FF=C1=E1=02=E9=04=F1=F2=FFQP1=C0=F3=ABXY=C1=E1=02=E9=94=F1= =F2=FF=8DL=8A =0A= =0D[<%8lx>] =FF =0A= =0DCode: %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x %2x = %2x %2x %2x %2x =0A= =0D <1>Unable to handle kernel NULL pointer dereference at virtual = address %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DCPU: 0=0A= =0DEIP: 0010:[<%8lx>] =89=10=B8=01=0A= =0DEFLAGS: %8lx=0A= =0DEIP is at del_timer [kernel] 0x16 (2.4.18-3elite)=0A= =0Deax: %8lx ebx: %8lx ecx: %8lx edx: %8lx=0A= =0Desi: %8lx edi: %8lx ebp: %8lx esp: %8lx=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel paging request at virtual address %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= =0D printing eip:=0A= =0D%8lx=0A= =0D*pde =3D %8lx=0A= =0DOops: %4lx=0A= =0Dcls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt=0A= =0DUnable to handle kernel NULL pointer dereference at virtual address = %8lx=0A= ... ... ... ... ------=_NextPart_000_0002_01C23730.067BCDD0-- From sumit@elitecore.com Mon Jul 29 15:49:41 2002 From: sumit@elitecore.com (Sumit Pandya) Date: Mon, 29 Jul 2002 20:19:41 +0530 Subject: [LARTC] RE: Oops with IMQ Ingress In-Reply-To: <20020729130502.1739.72009.Mailman@outpost> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2373D.453B1D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, One more result with my setup. Here is my all command lines with more details my client IP is 192.9.203.70 IP on linux router 192.9.203.139 and xxx.xxx.xxx.xxx # iptables -n -t nat -L -v Chain PREROUTING (policy ACCEPT 245 packets, 42668 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 14 packets, 1279 bytes) pkts bytes target prot opt in out source destination 10 488 MASQUERADE all -- * eth1 192.9.203.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 19 packets, 1963 bytes) pkts bytes target prot opt in out source destination # iptables -n -t mangle -L -v Chain PREROUTING (policy ACCEPT 6917 packets, 4711K bytes) pkts bytes target prot opt in out source destination 12 569 IMQ all -- * * 0.0.0.0/0 0.0.0.0/0 IMQ: todev 0 Chain INPUT (policy ACCEPT 1419 packets, 118K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 5356 packets, 4575K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 824 packets, 67098 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 6191 packets, 4644K bytes) pkts bytes target prot opt in out source destination 5779 4600K IMQ all -- * * 0.0.0.0/0 0.0.0.0/0 IMQ: todev 0 # sh /root/show_tc.sh ############################################################################ ######################## Qdisciplines ############################################################################ ######################## qdisc htb 1: r2q 10 default 1 direct_packets_stat 0 Sent 2185158 bytes 2835 pkts (dropped 1, overlimits 3168) ############################################################################ ######################## Classes ############################################################################ ######################## class htb 1:11 root prio 0 quantum 5120 rate 400Kbit ceil 400Kbit burst 2111b/8 mpu 0b cburst 2111b/8 mpu 0b level 0 buffer [000119fb] cbuffer [000119fb] Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 72187 ctokens: 72187 class htb 1:1 root prio 0 quantum 200000 rate 800Mbit ceil 800Mbit burst 1050044b/8 mpu 0b cburst 1050044b/8 mpu 0b level 0 buffer [00004476] cbuffer [00004476] Sent 40014 bytes 482 pkts (dropped 0, overlimits 0) rate 100bps 1pps lended: 482 borrowed: 0 giants: 0 tokens: 17526 ctokens: 17526 class htb 1:10 root prio 0 quantum 5120 rate 400Kbit ceil 400Kbit burst 2111b/8 mpu 0b cburst 2111b/8 mpu 0b level 0 buffer [000119fb] cbuffer [000119fb] Sent 2145144 bytes 2353 pkts (dropped 1, overlimits 0) lended: 2353 borrowed: 0 giants: 0 tokens: 70548 ctokens: 70548 ############################################################################ ######################## Filters ############################################################################ ######################## filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800:[80000000] ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::1[80000001] order 1 key ht 800 bkt 0 flowid 1:10 match c009cb46/ffffffff at 16 match 00500000/ffff0000 at 20 filter parent 1: protocol ip pref 1 u32 fh 800::3[80000003] order 3 key ht 800 bkt 0 flowid 1:10 match c009cb46/ffffffff at 12 match 00000050/0000ffff at 20 This time Oops trace is different then previous. But similarity is that it can be simulated by placing simply one entry into iptables i.e iptables -t mangle -I PREROUTING -j IMQ and avoided by not having above entry. I know again filter 800::3 is not proper and it does not satisfy my purpose. Insteed of specifying Public-IP, I made mistake of placing client-ip and found some bug. -- Sumit ------=_NextPart_000_0000_01C2373D.453B1D70 Content-Type: application/octet-stream; name="2.4bug.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="2.4bug.log" Red Hat Linux release 7.2 (Enigma) Kernel 2.4.18-3elite on an i686 kernel2_4 login: Unable to handle kernel paging request at virtual = address 036a0472 *pde =3D 00000000 Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010006 EIP is at find_vma [kernel] 0x17 (2.4.18-3elite) eax: c01e89a9 ebx: 036a0472 ecx: 036a046a edx: c02e6000 esi: c01e898d edi: 036a0472 ebp: 00000000 esp: c02e5ff0 ds: 0018 es: 0018 ss: 0018 Process 4=C0=01 (pid: 365, stackpage=3Dc02e5000) Stack: c02e6000 c01e898d c0112396 c01e898d=20 Call Trace: [] ip_forward [kernel] 0x1ed=20 [] do_page_fault [kernel] 0x86=20 [] ip_forward [kernel] 0x1ed=20 Code: 39 59 08 76 05 39 59 04 76 2c 8b 56 04 31 c9 eb 0b 8b 52 0c=20 <1>Unable to handle kernel NULL pointer dereference at virtual address = 00000000 printing eip: c011d0a6 *pde =3D 00000000 Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010082 EIP is at del_timer [kernel] 0x16 (2.4.18-3elite) eax: 00000000 ebx: 00000202 ecx: c02e40dc edx: c11c9720 esi: c022b4a0 edi: c02e4000 ebp: 0000000b esp: c02e5eb8 ds: 0018 es: 0018 ss: 0018 Process 4=C0=01 (pid: 365, stackpage=3Dc02e5000) Stack: 00000000 c0118ad0 c02e40dc 00000000 c7c5002c 00000002 c022b62e = c02e5fbc=20 00000000 c024765a 00000018 c0230018 ffffff00 c0108e74 00000010 = 00000000=20 c022b4a0 c02e5fbc 00000000 c0112637 0000000b c02e5fbc 00000000 = c02e4000=20 Call Trace: [] do_exit [kernel] 0x60=20 [] die [kernel] 0x54=20 [] do_page_fault [kernel] 0x327=20 [] imq_nf_queue [imq] 0x13e=20 [] nf_queue [kernel] 0xe1=20 [] ip_finish_output2 [kernel] 0x0=20 [] ip_finish_output2 [kernel] 0x0=20 [] nf_hook_slow [kernel] 0xd6=20 [] imq_egress_ipv4 [imq] 0x0=20 [] ip_finish_output2 [kernel] 0x0=20 [] imq_egress_ipv4 [imq] 0x0=20 [] do_page_fault [kernel] 0x0=20 [] error_code [kernel] 0x34=20 [] ip_forward [kernel] 0x1ed=20 [] ip_forward [kernel] 0x209=20 [] fifo_dump [kernel] 0x18=20 [] find_vma [kernel] 0x17=20 [] ip_forward [kernel] 0x1ed=20 [] do_page_fault [kernel] 0x86=20 [] ip_forward [kernel] 0x1ed=20 Code: 89 10 b8 01 00 00 00 c7 41 04 00 00 00 00 c7 01 00 00 00 00=20 <1>Unable to handle kernel NULL pointer dereference at virtual address = %8lx printing eip: %8lx *pde =3D %8lx Oops: %4lx cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: %4lx cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: c021e45b *pde =3D %8lx Oops: % cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel paging request at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0002 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx Oops: 0000 cls_u32 ipt_IMQ imq ipt_MASQUERADE iptable_mangle ipt_multiport = ipt_REJECT ipt Unable to handle kernel NULL pointer dereference at virtual address %8lx printing eip: %8lx *pde =3D %8lx LILO=20 Red Hat Linux release 7.2 (Enigma) ------=_NextPart_000_0000_01C2373D.453B1D70-- From cke@highlandshighspeed.net Mon Jul 29 17:36:07 2002 From: cke@highlandshighspeed.net (Chris K Ellsworth) Date: Mon, 29 Jul 2002 09:36:07 -0700 Subject: [LARTC] Bridge with Traffic shaping References: <20020729125352.6F09E3FC3@outpost.ds9a.nl> Message-ID: <002901c2371e$09c70660$f9c9d8c0@highlandshighspeed.net> does not HTB only shape on outgoing traffic? unless you start doing some ingress queues? ----- Original Message ----- From: "Stef Coene" To: "Roché Compaan" ; Sent: Monday, July 29, 2002 5:54 AM Subject: Re: [LARTC] Bridge with Traffic shaping > If I understand correctly I can shape incoming traffic by setting > up a qdisc on eth0 and filters that match any of the ip addresses > in my public subnet sitting behind the linux box that currently does > the traffic shaping. But all traffic coming on eth0 is leaving eht1 and vice versa. So shaping incoming traffic on eth0 is the same as shaping outgoing traffic on eth1. > No packets seem to match any of the other classes although tcpdump > confirms that there are definitely traffic destined for the ip addresses > mentioned in my filters. Mhh. It should work. I will think about it tonight. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From roche@upfrontsystems.co.za Mon Jul 29 22:44:51 2002 From: roche@upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan) Date: 29 Jul 2002 23:44:51 +0200 Subject: [LARTC] Bridge with Traffic shaping References: Message-ID: <1027979097.1599.6.camel@localhost.localdomain> Hi Stef I think I caused unnecessary alarm. There was actually a network cable connecting my router and hub behind the linux box that does the shaping, duh :-) I forgot to pull it out once I move some servers around causing very little traffic to go through=20 the box doing the shaping. On Mon, 2002-07-29 at 14:54, Stef Coene wrote: > > If I understand correctly I can shape incoming traffic by setting > > up a qdisc on eth0 and filters that match any of the ip addresses > > in my public subnet sitting behind the linux box that currently does > > the traffic shaping. > But all traffic coming on eth0 is leaving eht1 and vice versa. So shapin= g=20 > incoming traffic on eth0 is the same as shaping outgoing traffic on eth1. This seems to be working now. Are there tools that I can test this with. Traffic seems to go through all classes now and there is good amount of borrowed and lended packets on all classes. --=20 Roch=E9 Compaan Upfront Systems http://www.upfrontsystems.co.za From David.Watson@team17.com Tue Jul 30 11:19:29 2002 From: David.Watson@team17.com (David Watson) Date: Tue, 30 Jul 2002 11:19:29 +0100 Subject: [LARTC] RTNETLINK answers: Invalid argument, fwmark In-Reply-To: <20020726173958.2C740DB99F@tartarus.telenet-ops.be> References: <5.1.0.14.0.20020726171433.0301b1c8@mailgate.team17.com> <5.1.0.14.0.20020726171433.0301b1c8@mailgate.team17.com> Message-ID: <5.1.0.14.0.20020730111551.023dfb60@mailgate.team17.com> I missed a line in my report and I do in fact create a 1:1 class before attaching to it. I have found that if I change the prio value on the filter lines to unique numbers that I no longer get the error. I am however confused as to the meaning of the prio parameter, and I'm not sure why these filter lines need unique values or exactly what impact these values have. At 19:39 26/07/2002 +0200, Stef Coene wrote: >On Friday 26 July 2002 18:24, David Watson wrote: > > I'm using htb classes on my firewall to queue traffic and implement > > different restrictions on different protocols. > > > > tc qdisc del dev eth0 root > > tc qdisc add dev eth0 root handle 1: htb default 190 > > tc class add dev eth0 parent 1: classid 1:3 htb rate 2mbit burst 30k > > tc class add dev eth0 parent 1:1 classid 1:90 htb rate 50kbit ceil 384kbit > > burst 5k > > tc qdisc add dev eth0 parent 1:90 handle 190: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:3 handle 310: sfq perturb 10 > > > > > > tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw flowid 1:3 > > > > This last line gets a "RTNETLINK answers: Invalid argument" > > > > I'm using kernel 2.4.18 with the htb and wrr patches on both the kernel and > > on tc > > in the kernel .config I have: > > > > CONFIG_IP_ADVANCED_ROUTER=y > > CONFIG_IP_MULTIPLE_TABLES=y > > CONFIG_IP_ROUTE_FWMARK=y > > > > > > I'm not really sure where else I could be going wrong, any advice > would be > > greatly appreciated. >You attach class 1:90 to class 1:1, but you didn't create class 1:1 ?? > >Stef > >-- > >stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From phila@dg.net.ua Tue Jul 30 11:28:56 2002 From: phila@dg.net.ua (Anton Yurchenko) Date: Tue, 30 Jul 2002 13:28:56 +0300 Subject: [LARTC] definition of burst Message-ID: <3D466A68.7000007@dg.net.ua> Hello, How does HTB define burst. What does it consider a burst, I mean how does it destinguish when to allow traffic above rate(ceil), within burst(cburst) values? -- Anton Yurchenko Digital Generation From ch@westend.com Tue Jul 30 11:37:57 2002 From: ch@westend.com (Christian Hammers) Date: Tue, 30 Jul 2002 12:37:57 +0200 Subject: [LARTC] definition of burst In-Reply-To: <3D466A68.7000007@dg.net.ua> References: <3D466A68.7000007@dg.net.ua> Message-ID: <20020730103757.GL14692@westend.com> Hi On Tue, Jul 30, 2002 at 01:28:56PM +0300, Anton Yurchenko wrote: > How does HTB define burst. What does it consider a burst, I mean how > does it destinguish when to allow traffic above rate(ceil), within > burst(cburst) values? >From just reading the docs (not the actual source) I would say that "rate" is only the rate in which the bucket is filled with tokens. "burst" defines the size of the bucket. I.e. when the bucket is filled up after a pause, you can send out as much packets as the bucket is large as fast as you want. The burst therefore starts at a sometimes undefined point in time but definetly ends when the bucket is simple empty. Because then, the packets have to wait for new tokens which only arrives at the "rate" frequency. So "burst" defines the endurance of the burst. (if you want those small-burst-until-the-bucket-is-empty to be not as fast as possible but shaped as well then you have to use the maxpeak parameter. HTH, -christian- -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 ch@westend.com Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller From phila@dg.net.ua Tue Jul 30 12:00:40 2002 From: phila@dg.net.ua (Anton Yurchenko) Date: Tue, 30 Jul 2002 14:00:40 +0300 Subject: [LARTC] definition of burst References: <3D466A68.7000007@dg.net.ua> <20020730103757.GL14692@westend.com> Message-ID: <3D4671D8.4030800@dg.net.ua> Christian Hammers wrote: >Hi > >On Tue, Jul 30, 2002 at 01:28:56PM +0300, Anton Yurchenko wrote: > > >>How does HTB define burst. What does it consider a burst, I mean how >>does it destinguish when to allow traffic above rate(ceil), within >>burst(cburst) values? >> >> > >>From just reading the docs (not the actual source) I would say that >"rate" is only the rate in which the bucket is filled with tokens. >"burst" defines the size of the bucket. I.e. when the bucket is filled up >after a pause, you can send out as much packets as the bucket is large as >fast as you want. The burst therefore starts at a sometimes undefined point >in time but definetly ends when the bucket is simple empty. Because then, >the packets have to wait for new tokens which only arrives at the "rate" >frequency. > >So "burst" defines the endurance of the burst. > >(if you want those small-burst-until-the-bucket-is-empty to be not as fast >as possible but shaped as well then you have to use the maxpeak parameter. > > maxpeak? is that an undocumented HTB param? >HTH, > >-christian- > > > -- Anton Yurchenko Digital Generation From ch@westend.com Tue Jul 30 12:31:37 2002 From: ch@westend.com (Christian Hammers) Date: Tue, 30 Jul 2002 13:31:37 +0200 Subject: [LARTC] definition of burst In-Reply-To: <3D4671D8.4030800@dg.net.ua> References: <3D466A68.7000007@dg.net.ua> <20020730103757.GL14692@westend.com> <3D4671D8.4030800@dg.net.ua> Message-ID: <20020730113137.GO14692@westend.com> On Tue, Jul 30, 2002 at 02:00:40PM +0300, Anton Yurchenko wrote: > maxpeak? is that an undocumented HTB param? Oh.. I mixed something up, it was "peakrate", not "maxpeak", and moreover I was referring to the "Token Bucket Filter", TBF, not the "Hierarchy Token Bucket ", HTB, although it should work quite similar. BTW: There's an excelent user guide at http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm bye, -christian- -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 ch@westend.com Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller From catab@deuroconsult.ro Tue Jul 30 13:35:13 2002 From: catab@deuroconsult.ro (Catalin BOIE) Date: Tue, 30 Jul 2002 15:35:13 +0300 (EEST) Subject: [LARTC] qdisc_sleeping Message-ID: Hi! Can somebody explain to me why there are qdisc_sleeping and qdisc_list beside qdisc in net_device structure and what are these useful for? Thank you very much! --- Catalin(ux) BOIE catab@deuroconsult.ro H323: dino.rdsbv.ro From stef.coene@docum.org Tue Jul 30 18:37:58 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 30 Jul 2002 19:37:58 +0200 Subject: [LARTC] Bridge with Traffic shaping In-Reply-To: <1027979097.1599.6.camel@localhost.localdomain> References: <1027979097.1599.6.camel@localhost.localdomain> Message-ID: <20020730173759.5D004DC8D2@tartarus.telenet-ops.be> > I think I caused unnecessary alarm. There was actually > a network cable connecting my router and hub behind the linux > box that does the shaping, duh :-) I forgot to pull it out once I > move some servers around causing very little traffic to go through > the box doing the shaping. :) > This seems to be working now. Are there tools that I can test this > with. Traffic seems to go through all classes now and there is good > amount of borrowed and lended packets on all classes. I have some scripts that generate graphs based on the output of tc. See=20 www.docum.org under "gui". There is a link to an example setup that moni= tors=20 my internet connection at home. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From DiG@bvc.com.au Tue Jul 30 19:07:00 2002 From: DiG@bvc.com.au (Don Gould) Date: Wed, 31 Jul 2002 02:07:00 +0800 Subject: [LARTC] RADIUS? Traffic Accounting and VPN (PPTP) Message-ID: <416540820D20D511AC7F00805F5DC4280AE9CB@NTSERVER> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C237F3.E64FB840 Content-Type: text/plain; charset="iso-8859-1" Hi All, I'm trying to find the right tools to be able to track the amount of data that my users and pulling accross our VPN links. I've already done a google and hunted thru the Redhat web site but I'm really just not sure what I'm looking for. Could someone give me some links or even the correct terms would be a start. Cheers DiG Ask not what your broadband Telcos can do for you... ...but what you can do for your broadband community! ============================================================ Don Gould Unit 4 / 3 Conroy Street CBP Team Leader Maylands , Perth Bowenvale Communications WA 6051 www.bvc.com.au Australia Phone + 61 8 9371 7289 ------_=_NextPart_000_01C237F3.E64FB840 Content-Type: application/octet-stream; name="Don Gould.vcf" Content-Disposition: attachment; filename="Don Gould.vcf" BEGIN:VCARD VERSION:2.1 N:Gould;Don FN:Don Gould ORG:Bowenvale Communications TEL;WORK;VOICE:08 9371 7289 TEL;CELL;VOICE:0412 922 425 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Unit 4=0D=0A3 Conroy Street=0D=0AMaylands;Perth;WA;6051;Australia LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Unit 4=0D=0A3 Conroy Street=0D=0AMaylands=0D=0APerth, WA 6051=0D=0AAustralia EMAIL;PREF;INTERNET:DiG@bvc.com.au REV:20011130T101019Z END:VCARD ------_=_NextPart_000_01C237F3.E64FB840-- From raptor@unacs.bg Tue Jul 30 19:22:21 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Tue, 30 Jul 2002 21:22:21 +0300 Subject: [LARTC] shaping redirected traffic Message-ID: <20020730212221.4ccd890a.raptor@unacs.bg> Hi I have the following situation : CableTV-NET (128-254) | |(c0) Cisco7233 -(s0)-----> Internet |(e0) | QoS Server Now I will route all traffic coming from Cable-net to Internet trought the QoS server AND then back from internet trought the QoS-Server again to the Cable-net, how I will do is another matter, i have some ideas.. ( if u have ideas too mail directly to me, i will be very glad if u can help me on this too .... i'm still one week cisco user :") ) but the main question is not this..... I'm wondering will I be able to SHAPE the traffic in both directions .... My worries are that I'm using only one Ethernet interface on the QoS-Server ? Do U have any ideas will I be able to do this ? Or I have to put 2 Ethernet cards on the QoS-Server, one for incoming and one for outgoing traffic ? I don't want to do this :"[, it becomes too weird ..... One more thing I will use tcng (preffer it instead tc, 'cause i will have a very complex setup and i worry if i use directly tc that i will mess everything) (I will probably get a separate serial-card (Frame realay), but it is not an option at the moment and wont be soon) Thanx alot in advance raptor@unacs.bg PS. These days I'm very busy... but when i have free time i will redo the 2.4-NETWORK-DIAGRAM with some updates that Leonardo was so generous to send me... From stef.coene@docum.org Tue Jul 30 19:37:31 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 30 Jul 2002 20:37:31 +0200 Subject: [LARTC] RADIUS? Traffic Accounting and VPN (PPTP) In-Reply-To: <416540820D20D511AC7F00805F5DC4280AE9CB@NTSERVER> References: <416540820D20D511AC7F00805F5DC4280AE9CB@NTSERVER> Message-ID: <20020730183732.27E77DBD56@tartarus.telenet-ops.be> On Tuesday 30 July 2002 20:07, Don Gould wrote: > Hi All, > > I'm trying to find the right tools to be able to track the amount of da= ta > that my users and pulling accross our VPN links. > > I've already done a google and hunted thru the Redhat web site but I'm > really just not sure what I'm looking for. > > Could someone give me some links or even the correct terms would be a So you want to know it from each user seperated? And do they have static ip-addresses? You can create a iptable rule that match each user and use the iptables b= yte=20 counters. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From f2zubac@chiquita.www.yu Wed Jul 31 10:01:57 2002 From: f2zubac@chiquita.www.yu (Dragan Zubac) Date: Wed, 31 Jul 2002 11:01:57 +0200 (CEST) Subject: [LARTC] RADIUS? Traffic Accounting and VPN (PPTP) In-Reply-To: <416540820D20D511AC7F00805F5DC4280AE9CB@NTSERVER> Message-ID: Hi, You can always use pppd (which VPN uses),and radiusclient to do IP accounting via internal or external radius server.Radius protocol can account time as well as byte octets,it depends only on You what things You'd like to account :) Dragan Zubac On Wed, 31 Jul 2002, Don Gould wrote: > Hi All, > > I'm trying to find the right tools to be able to track the amount of data > that my users and pulling accross our VPN links. > > I've already done a google and hunted thru the Redhat web site but I'm > really just not sure what I'm looking for. > > Could someone give me some links or even the correct terms would be a start. > > Cheers DiG > > Ask not what your broadband Telcos can do for you... > ...but what you can do for your broadband community! > ============================================================ > Don Gould Unit 4 / 3 Conroy Street > CBP Team Leader Maylands , Perth > Bowenvale Communications WA 6051 > www.bvc.com.au Australia > Phone + 61 8 9371 7289 > > From niels@wxn.nl Wed Jul 31 14:42:02 2002 From: niels@wxn.nl (niels@wxn.nl) Date: Wed, 31 Jul 2002 15:42:02 +0200 Subject: [LARTC] Multipath route problem Message-ID: <4FACD13E65E34440B01491D90EDE966A26C217@hq-exchange.hq.nl> Hi ... I have 2 DSL lines all up and running on one RedHat box... I want to balance traffic going out over the two providers The 2 DSL routers Have IP's 10.10.10.1 / 10.10.10.2 ... my linux box (eth0) has IP 10.10.10.10 connected on a separate ethernet SO I read the http://lartc.org/howto/lartc.rpdb.multiple-links.html guide (chapter 4.2.2) In my case I have to make these routes # ip route add default nexthop via 10.10.10.1 dev eth0 nexthop via 10.10.10.2 dev eth0 Works Fine!! every connection request going is perfectly balanced sent out via both gateways But works only on the linux box itself! from the (masqueraded) clients it doesn't: Every first request which is masqueraded -> gateway 10.10.10.1 (works fine) Every second request which is masqueraded -> gateway 10.10.10.2 (don't get reply back) When I change the multipath route so that 10.10.10.2 is the first hop # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via 10.10.10.1 dev eth0 Gw 10.10.10.2 (fine) Gw 10.10.10.1 (doesn't work ... Only from the linux box itself) So it every time seems to be the second "hop" in the multipath route which isn't beeing masqueraded properly! Can anyone help? Thanks in advance! Niels! From GregScott@InfraSupportEtc.com Wed Jul 31 16:14:58 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Wed, 31 Jul 2002 10:14:58 -0500 Subject: [LARTC] Multipath route problem Message-ID: <365871C49598504A9481DDBEC3EB495553D1@MAIL.InfraSupportEtc.com> > # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via > 10.10.10.1 dev eth0 I wonder if this is a problem going out over the same NIC to the two=20 providers? All the docs I can find show each provider on its own NIC. =20 I am setting up something similar and was just about to ask if I can=20 do it with one NIC connecting all the providers. That would save me=20 a bunch of precious PCI slots! In my case there are 4 - count 'em - 4 external routers to the=20 Internet! 3 of them are supposed to load-balance for user traffic=20 and the fourth is for a bunch of internal servers with known IP=20 Addresses. So there will be a fwmark policy that puts the routes=20 for those servers into its own table. =20 Life would be great if I could do all this on a single NIC connecting=20 all of those routers. Or do Neils and I both need a separate NIC for=20 each router? thanks - Greg -----Original Message----- From: niels@wxn.nl [mailto:niels@wxn.nl] Sent: Wednesday, July 31, 2002 8:42 AM To: lartc@mailman.ds9a.nl Subject: [LARTC] Multipath route problem Hi ... I have 2 DSL lines all up and running on one RedHat box...=20 I want to balance traffic going out over the two providers The 2 DSL routers Have IP's 10.10.10.1 / 10.10.10.2 ... my linux box = (eth0) has IP 10.10.10.10 connected on a separate ethernet=20 SO I read the http://lartc.org/howto/lartc.rpdb.multiple-links.html = guide (chapter 4.2.2) In my case I have to make these routes # ip route add default nexthop via 10.10.10.1 dev eth0 nexthop via 10.10.10.2 dev eth0 Works Fine!! every connection request going is perfectly balanced sent = out via both gateways But works only on the linux box itself! from the (masqueraded) clients = it doesn't: Every first request which is masqueraded -> gateway 10.10.10.1 (works = fine) Every second request which is masqueraded -> gateway 10.10.10.2 (don't = get reply back) When I change the multipath route so that 10.10.10.2 is the first hop # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via 10.10.10.1 dev eth0 Gw 10.10.10.2 (fine)=20 Gw 10.10.10.1 (doesn't work ... Only from the linux box itself) So it every time seems to be the second "hop" in the multipath route = which isn't beeing masqueraded properly! Can anyone help? Thanks in advance!=20 Niels! _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From niels@wxn.nl Wed Jul 31 16:07:55 2002 From: niels@wxn.nl (niels@wxn.nl) Date: Wed, 31 Jul 2002 17:07:55 +0200 Subject: [LARTC] Multipath route problem Message-ID: <4FACD13E65E34440B01491D90EDE966A26C21C@hq-exchange.hq.nl> I'm almost sure I don't need more NIC's... (only if you want to separate the nets physically you do neet more NIC's) With simple policy routing I already have a succesfull masquerading network with Source Subnet X going through gateway 1 and Source subnet Y going through gateway 2 (balancing the load based on subnet) It even works if those 2 gateways are on totally different subnets! just add an extra IP adress to your interface like this: #Ip addr add 10.50.50.10/24 dev eth0 brd 10.50.50.255 then add a second default route (for example to gateway 10.50.50.254) in table (for example testtable) like this: #Ip route add default dev eth0 via 10.50.50.254 table test Then add a rule to use the table from (for example) a specific subnet #Ip rule add pref 1000 table test from 192.168.0.0/16 And it's up and running! SO, I'm sure load balancing (multi path routes) must also be possible from the local machine I have it already working... so why not via masquerading? PS.. I read something about the "src" option in the route add command .. But it didn't seem to help me out. -----Original Message----- From: Greg Scott [mailto:GregScott@InfraSupportEtc.com] Sent: 31 July 2002 17:15 To: niels@wxn.nl; lartc@mailman.ds9a.nl Subject: RE: [LARTC] Multipath route problem > # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via > 10.10.10.1 dev eth0 I wonder if this is a problem going out over the same NIC to the two providers? All the docs I can find show each provider on its own NIC. I am setting up something similar and was just about to ask if I can do it with one NIC connecting all the providers. That would save me a bunch of precious PCI slots! From mabrown-lartc@securepipe.com Wed Jul 31 18:46:04 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Wed, 31 Jul 2002 12:46:04 -0500 (CDT) Subject: [LARTC] Multipath route problem In-Reply-To: <365871C49598504A9481DDBEC3EB495553D1@MAIL.InfraSupportEtc.com> Message-ID: Greg, : I wonder if this is a problem going out over the same NIC to the two : providers? All the docs I can find show each provider on its own NIC. : : I am setting up something similar and was just about to ask if I can : do it with one NIC connecting all the providers. That would save me : a bunch of precious PCI slots! You could always try the multi-port ethernet cards. They are usually a bit more expensive, but they give you up to four ports on a single PCI card. Occasionally, you may run into IRQ problems, depending on the card and your motherboard, but this solves your PCI slot availablity problem. The DLink DFE 570TX is the one I use (with the tulip driver), and it works well and reliably. http://www.dlink.com/products/adapters/dfe570tx/ There are, I'm sure many others which people on this list can recommend. : Life would be great if I could do all this on a single NIC connecting : all of those routers. Or do Neils and I both need a separate NIC for : each router? I don't think you *need* to have a separate NIC for each router, but if I were doing it, I'd want each router on a separate network. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From support@obsidian-studios.com Wed Jul 31 18:50:47 2002 From: support@obsidian-studios.com (William L. Thomson Jr.) Date: 31 Jul 2002 10:50:47 -0700 Subject: [LARTC] Multipath route problem In-Reply-To: <4FACD13E65E34440B01491D90EDE966A26C217@hq-exchange.hq.nl> References: <4FACD13E65E34440B01491D90EDE966A26C217@hq-exchange.hq.nl> Message-ID: <1028137847.8259.14.camel@wlt.obsidian-studios.com> Niels, I do not think the two nics are your problem. First off you will need two things. The first is patches made by Julian Anastasov, I had a link but it does not seem to work. Julian subscribes to this list so maybe he will post an updated link to where they can be found. After you apply the patches the Linux machine will need to be running NAT in some manor. Because I have routers on each of my DSL lines I perform two rounds of NAT or PAT. One in each router, and then again in the Linux router. Without those two things, I was not able to get things to work by using only the example on lartc.org that you posted below. You will also want to dial in your DNS to servers for each IP block, and load balance that as well. In doing the NAT/PAT you will need to give the outgoing interface each of the IP's that your routers will be translating to. Example. Public IP - Router Nat to say 10.1.0.3 On the Linux router your interface may have 10.1.0.1 as the ip, so you will need to add the other ip as well. ip addr add 10.1.0.1/16 brd 10.1.255.255 dev eth1 ip addr add 10.1.0.3/16 brd 10.1.255.255 dev eth1 You will need to do that for each IP that the routers will NAT/PAT the public ips to. Then in the Linux box, you can map those IP to what ever internal ones you want from there via NAT or PAT. Hope that makes sense and helps. On Wed, 2002-07-31 at 06:42, niels@wxn.nl wrote: > Hi ... I have 2 DSL lines all up and running on one RedHat box... > > I want to balance traffic going out over the two providers > > The 2 DSL routers Have IP's 10.10.10.1 / 10.10.10.2 ... my linux box (eth0) > has IP 10.10.10.10 connected on a separate ethernet > > SO I read the http://lartc.org/howto/lartc.rpdb.multiple-links.html guide > (chapter 4.2.2) > > In my case I have to make these routes > > # ip route add default nexthop via 10.10.10.1 dev eth0 nexthop via > 10.10.10.2 dev eth0 > > Works Fine!! every connection request going is perfectly balanced sent out > via both gateways > But works only on the linux box itself! from the (masqueraded) clients it > doesn't: > > Every first request which is masqueraded -> gateway 10.10.10.1 (works fine) > Every second request which is masqueraded -> gateway 10.10.10.2 (don't get > reply back) > > When I change the multipath route so that 10.10.10.2 is the first hop > > # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via > 10.10.10.1 dev eth0 > > Gw 10.10.10.2 (fine) > Gw 10.10.10.1 (doesn't work ... Only from the linux box itself) > > So it every time seems to be the second "hop" in the multipath route which > isn't beeing masqueraded properly! > > Can anyone help? > > Thanks in advance! > Niels! > > > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com From ja@ssi.bg Wed Jul 31 23:55:06 2002 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 31 Jul 2002 22:55:06 +0000 (GMT) Subject: [LARTC] Multipath route problem In-Reply-To: <1028137847.8259.14.camel@wlt.obsidian-studios.com> Message-ID: Hello, On 31 Jul 2002, William L. Thomson Jr. wrote: > two things. The first is patches made by Julian Anastasov, > I had a link but it does not seem to work. Julian subscribes to this > list so maybe he will post an updated link to where they can be found. The box that hosts the patches is down. I can't provide another link, I don't know whether it is mirrored with wget somewhere by someone. When the site is ok I'll upload the files. Until then, I still can use email, just let me know what files you like to see. I simply didn't started to think for another place for this page, I hope the issue will be resolved in days. Regards -- Julian Anastasov From anish_46628" Hi *, I have the enabled my kernel with the QoS options and to support diffserv. I want to test whether it is working fine or not. Please suggest me how can i check that my kernel is supporting diffserv or not. Waiting for reply. Regards, Anish Mehta. From niels@wxn.nl Thu Aug 1 09:14:45 2002 From: niels@wxn.nl (niels@wxn.nl) Date: Thu, 1 Aug 2002 10:14:45 +0200 Subject: [LARTC] Multipath route problem Message-ID: <4FACD13E65E34440B01491D90EDE966A26C226@hq-exchange.hq.nl> > After you apply the patches the Linux machine will need to be running NAT in some manor. > Because I have routers on each of my DSL lines I perform two > rounds of NAT or PAT. One in each router, and then again in the Linux router. > In doing the NAT/PAT you will need to give the outgoing interface each of the > IP's that your routers will be translating to. Have that up and running alrady ... :-) > You will also want to dial in your DNS to servers for each IP block, > and load balance that as well. What do you mean by that? Hope that the patches work when I get my hands on them :-) Regards, Niels From Nils.Lichtenfeld@gmx.net Thu Aug 1 09:54:09 2002 From: Nils.Lichtenfeld@gmx.net (Nils Lichtenfeld) Date: Thu, 1 Aug 2002 10:54:09 +0200 Subject: [LARTC] HTB parent rates and ceils Message-ID: <002001c23939$0101a7c0$9605a8c0@Gundy> Hello @all, hello Devik! Whe have got a little confusion here. What of the following statements is true? - The ceil of a class should always be at least as high as the sum of the rates of its children. - The rate of a class should always be at least as high as the sum of the rates of its children. Thank you! Greetings, Nils From support@obsidian-studios.com Thu Aug 1 10:13:14 2002 From: support@obsidian-studios.com (William L. Thomson Jr.) Date: 01 Aug 2002 02:13:14 -0700 Subject: [LARTC] Multipath route problem In-Reply-To: <4FACD13E65E34440B01491D90EDE966A26C226@hq-exchange.hq.nl> References: <4FACD13E65E34440B01491D90EDE966A26C226@hq-exchange.hq.nl> Message-ID: <1028193195.1733.7.camel@wlt.obsidian-studios.com> Niels, On Thu, 2002-08-01 at 01:14, niels@wxn.nl wrote: > > After you apply the patches the Linux machine will need to be running NAT > in some manor. > > Because I have routers on each of my DSL lines I perform two > > rounds of NAT or PAT. One in each router, and then again in the Linux > router. > > In doing the NAT/PAT you will need to give the outgoing interface each of > the > > IP's that your routers will be translating to. > > Have that up and running alrady ... :-) Your routers translation? Good, then you will need to do second round of translation in the Linux box as well. Also helps to act as a second in line firewall that is transparent from the outside world. The Linux box must perform translation at some point or no go. The patches only work when translating. > > You will also want to dial in your DNS to servers for each IP block, > > and load balance that as well. > > What do you mean by that? The docs from isc.org, the pdf will help. You may have to use a later version of bind, 9.x not 8.x, but it may work in older ones as well. Normally an A record looks like domain.com. IN A ip So all you will need is domain.com. IN A ip1 IN A ip2 Which will use ip1 half the time, and ip2 the other half. In theory. There are other params like the time for each one to last and etc. Download this pdf doc on admin Bind and it should tell you what you will need from there http://www.nominum.com/resources/documentation/Bv9ARM.pdf > Hope that the patches work when I get my hands on them :-) They do, have you emailed Julian? He will send you the ones you will need. Without the patches things will not work correctly or at all. They are a must not an option. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com From phila@dg.net.ua Thu Aug 1 10:51:14 2002 From: phila@dg.net.ua (Anton Yurchenko) Date: Thu, 01 Aug 2002 12:51:14 +0300 Subject: [LARTC] shaping redirected traffic References: <20020730212221.4ccd890a.raptor@unacs.bg> Message-ID: <3D490492.5000203@dg.net.ua> raptor@unacs.bg wrote: > >Hi I have the following situation : > >CableTV-NET (128-254) > | > |(c0) >Cisco7233 -(s0)-----> Internet > |(e0) > | >QoS Server > >Now I will route all traffic coming from Cable-net to Internet trought the QoS server AND then back from internet trought the QoS-Server again to the Cable-net, how I will do is another matter, i have some ideas.. ( if u have ideas too mail directly to me, i will be very glad if u can help me on this too .... i'm still one week cisco user :") ) but the main question is not this..... I'm wondering will I be able to SHAPE the traffic in both directions .... My worries are that I'm using only one Ethernet interface on the QoS-Server ? Do U have any ideas will I be able to do this ? > >Or I have to put 2 Ethernet cards on the QoS-Server, one for incoming and one for outgoing traffic ? I don't want to do this :"[, it becomes too weird ..... >One more thing I will use tcng (preffer it instead tc, 'cause i will have a very complex setup and i worry if i use directly tc that i will mess everything) > >(I will probably get a separate serial-card (Frame realay), but it is not an option at the moment and wont be soon) > > You can shape on one interface with no problems at all, just create for example one parent class for outbound and one for inbound packets, and use iptables with marks to place packets on respactive classes under those parent classes. Its just you have to set up the routes right. And that depends on you physical setup. If the interfaces of Cisco and QoS are connected directly, you could create two VLAN interfaces on linux and route traffic as if QoS box had 2 interfaces. Or if you have some switch that connects Cisco Cable-Net and QoS, than you just make Qos default gateway for Cable-Net and QoS default gateway is Cisco, and from Cisco route the Cable-Net networks to the QoS box. Bottom line is that how the routing goes is dependent on your physical connections setup, but shaping on one interface is definitely possible :) >Thanx alot in advance > >raptor@unacs.bg >PS. These days I'm very busy... but when i have free time i will redo the 2.4-NETWORK-DIAGRAM with some updates that Leonardo was so generous to send me... >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > -- Anton Yurchenko Digital Generation From jshen@cad.zju.edu.cn Thu Aug 1 11:15:22 2002 From: jshen@cad.zju.edu.cn (shen jing) Date: Thu, 01 Aug 2002 18:15:22 +0800 Subject: [LARTC] Two adapter, One IP address Message-ID: <3D490A3A.58C8565@cad.zju.edu.cn> Hi, I have a question, is it possible to assign one IP address to two ntework adapter installed on the same Linux box? Must we use NAT at gateway to enable such a reduant configuation? Thanks a lot. Jing From wing328@yahoo.com Thu Aug 1 11:39:52 2002 From: wing328@yahoo.com (Cheng Kwok Wing, William) Date: Thu, 1 Aug 2002 03:39:52 -0700 (PDT) Subject: [LARTC] Best relation (value) of rate and burst in TBF and HTB Message-ID: <20020801103952.84279.qmail@web14803.mail.yahoo.com> Hi, I'm going to setup a linux traffic control box and has decided to adapt HTB. What should be the best relation(value) of rate and burst? I mean the formula used to calculate burst give rate or vice verse. I think the bandwidth of NIC and CPU processing speed are also important in the calculation above. What else are important?? Thanks a lot, Willim __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From dizzy@roedu.net Thu Aug 1 16:27:24 2002 From: dizzy@roedu.net (Mihai RUSU) Date: Thu, 1 Aug 2002 18:27:24 +0300 (EEST) Subject: [LARTC] htb qdisc on top of htb Message-ID: Hi I tryed to use a htb qdisc/class on top of another htb qdisc/class as you can see bellow: #!/bin/bash tc="/sbin/tc" $tc qdisc del dev eth0 root $tc qdisc add dev eth0 root handle 1: htb default 40 $tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit burst 15k $tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50Mbit burst 15k $tc class add dev eth0 parent 1:1 classid 1:20 htb rate 256Kbit burst 15k $tc class add dev eth0 parent 1:1 classid 1:30 htb rate 50Mbit ceil 100Mbit burst 15k $tc qdisc add dev eth0 parent 1:10 handle 10: htb default 20 $tc class add dev eth0 parent 10: classid 10:1 htb rate 50Mbit burst 15k $tc class add dev eth0 parent 10:1 classid 10:10 htb rate 256Kbit $tc class add dev eth0 parent 10:1 classid 10:20 htb rate 1Mbit ceil 50Mbit $tc filter add dev eth0 parent 1: protocol ip u32 match ip dst 1.2.3.4/32 flowid 10:10 The problem is I dont limited with 256 Kbit downloading from 1.2.3.4. If I change flowid from 10:10 to 1:20 I do get shaped so its not from a filter problem. Is it possible to use htb qdisc on top of htb qdisc ? Thanks PS: I am using last htb2 ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From dizzy@roedu.net Thu Aug 1 16:33:35 2002 From: dizzy@roedu.net (Mihai RUSU) Date: Thu, 1 Aug 2002 18:33:35 +0300 (EEST) Subject: [LARTC] htb qdisc on top of htb In-Reply-To: Message-ID: Heh I solved the "problem" with a litle filters modification, see below: On Thu, 1 Aug 2002, Mihai RUSU wrote: > Hi > > I tryed to use a htb qdisc/class on top of another htb qdisc/class as you > can see bellow: > #!/bin/bash > > tc="/sbin/tc" > > $tc qdisc del dev eth0 root > $tc qdisc add dev eth0 root handle 1: htb default 40 > $tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit burst 15k > > $tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50Mbit burst 15k > $tc class add dev eth0 parent 1:1 classid 1:20 htb rate 256Kbit burst 15k > $tc class add dev eth0 parent 1:1 classid 1:30 htb rate 50Mbit ceil 100Mbit burst 15k > > $tc qdisc add dev eth0 parent 1:10 handle 10: htb default 20 > $tc class add dev eth0 parent 10: classid 10:1 htb rate 50Mbit burst 15k > > $tc class add dev eth0 parent 10:1 classid 10:10 htb rate 256Kbit > $tc class add dev eth0 parent 10:1 classid 10:20 htb rate 1Mbit ceil 50Mbit > > $tc filter add dev eth0 parent 1: protocol ip u32 match ip dst 1.2.3.4/32 flowid 10:10 > replaced the line above with: $tc filter add dev eth0 parent 1: protocol ip u32 match ip dst 0.0.0.0/0 flowid 1:10 $tc filter add dev eth0 parent 10: protocol ip u32 match ip dst 1.2.3.4/32 flowid 10:10 ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From ch@westend.com Thu Aug 1 17:40:11 2002 From: ch@westend.com (Christian Hammers) Date: Thu, 1 Aug 2002 18:40:11 +0200 Subject: [LARTC] Two adapter, One IP address In-Reply-To: <3D490A3A.58C8565@cad.zju.edu.cn> References: <3D490A3A.58C8565@cad.zju.edu.cn> Message-ID: <20020801164011.GB22449@westend.com> On Thu, Aug 01, 2002 at 06:15:22PM +0800, shen jing wrote: > I have a question, is it possible to assign one IP address to two > ntework adapter installed on the same Linux box? Would the bonding driver support (kernel/network options) be an option for you? bye, -christian- From stimits@idcomm.com Thu Aug 1 17:51:31 2002 From: stimits@idcomm.com (D. Stimits) Date: Thu, 01 Aug 2002 10:51:31 -0600 Subject: [LARTC] bridge advice Message-ID: <3D496713.4020604@idcomm.com> I'm about to set up a Linux bridge (kernel 2.4.18.x from Redhat 7.3) between a (future) cable modem and several machines in the house. Some of those machines are windows, mine is Linux (but dual boots to windows). Basically: CABLE_MODEM (DHCP issues to each machine) | |(eth0 -- outer) LINUX_BRIDGE (not proxy, but is firewall on some ports) |(eth1 -- inner) | 8_PORT_SWITCH | |-Machine1 |-Machine2 ... |-MachineN Except for my machine, the other machines will email and web browsing machines (I do cvs, ssh, remote web site editing, and write network game software in Linux, as well as play games under windows). My goal is similar to the cable modem "wonder shaper", but I'm not positive if maybe I need to expand on that, and am currently not familiar with the more advanced QoS and shaping abilities (I know they are there, I now have some docs, and a machine I will be able to test on soon), especially with respect to bridges. I want my machine to have low latency, but the other machines do not care about latency; all machines care about having a fair bandwidth. A problem I am thinking about (until I get my bridge done I can only think about it, can't test anything) is that each machine is assigned address via DHCP, so perhaps the Linux bridge will have to find a way to know which DHCP address is assigned to which physical machine. If I were to simply assign qualities to the inside interface (eth1), then the same QoS and general characteristics would apply to all machines...which I do not want, so it seems I must deal on a per-IP-address basis, or a per-port basis. For port 80 web traffic, this seems just fine. I could even assign a quality for telnet and ssh ports. However, if I suddenly decide that one machine wants different characteristics for a port, or if it is an unknown port (such as some games work with...they may not always use the same port, or they can use more than one port at once), this breaks. So I am wanting to deal with latency on a per-machine basis, and simply assign low latency to my machine in general, and fair bandwidth for all machines; perhaps after that, I could override for particular ports, and for example, make all machines use port 80 web traffic with higher latency, even on my machine (which is otherwise low latency). Is this reasonable with current 2.4.x kernels? Are there particular things to watch out for or look for, especially for a bridge? Also, I have used ipchains in the past, but it seems iptables will be the future. What parts of this depend on iptables versus ipchains (if any)? The iproute2 package seems to provide most of the features I'm looking at, but it is conceivable that the use of ipchains or iptables will interact. D. Stimits, stimits AT idcomm.com From get@andrew.cmu.edu Thu Aug 1 18:18:56 2002 From: get@andrew.cmu.edu (Gil Tolle) Date: Thu, 1 Aug 2002 13:18:56 -0400 (EDT) Subject: [LARTC] Many:Many NAT with DHCP external addresses Message-ID: I'm interested in setting up a NAT machine between a local network and a DSL-connected ISP. In order to avoid some of the problems with Many:1 NAT, I would like to take advantage of the fact that my ISP is willing to issue as many DHCP dynamic addresses as I ask for, possibly enabling me to set up Many:Many NAT for my local machines. Currently, the machines are all on the same switch as the bridging DSL modem and are acquiring DHCP addresses on their own. Is there a way to configure iproute2 under Linux to acquire external IP addresses from a DHCP server as needed, instead of selecting its own external IP addresses from a given subnet? Thanks, Gil From stef.coene@docum.org Thu Aug 1 18:32:55 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 19:32:55 +0200 Subject: [LARTC] Many:Many NAT with DHCP external addresses In-Reply-To: References: Message-ID: <20020801173256.027A5DC226@tartarus.telenet-ops.be> On Thursday 01 August 2002 19:18, Gil Tolle wrote: > I'm interested in setting up a NAT machine between a local network and = a > DSL-connected ISP. In order to avoid some of the problems with Many:1 N= AT, > I would like to take advantage of the fact that my ISP is willing to is= sue > as many DHCP dynamic addresses as I ask for, possibly enabling me to se= t > up Many:Many NAT for my local machines. Currently, the machines are all= on > the same switch as the bridging DSL modem and are acquiring DHCP addres= ses > on their own. > > Is there a way to configure iproute2 under Linux to acquire external IP > addresses from a DHCP server as needed, instead of selecting its own > external IP addresses from a given subnet? That's called a dhcp relay Or you can configure the linux box as a bridge. But this is not the right place for this issue. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Aug 1 18:37:11 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 19:37:11 +0200 Subject: [LARTC] bridge advice In-Reply-To: <3D496713.4020604@idcomm.com> References: <3D496713.4020604@idcomm.com> Message-ID: <20020801173712.0FDE0DC307@tartarus.telenet-ops.be> I have some remakst to make. You can't use iptables on a linux bridge. (I think there is a patch that= you=20 can, but I'm not sure). And try to patch the kernel for htb (it's a=20 replacement for cbq). And maybe you can try to filter on mac-address so = you=20 don't need to know the ip-addresses. Stef On Thursday 01 August 2002 18:51, D. Stimits wrote: > I'm about to set up a Linux bridge (kernel 2.4.18.x from Redhat 7.3) > between a (future) cable modem and several machines in the house. Some > of those machines are windows, mine is Linux (but dual boots to > windows). Basically: > > CABLE_MODEM (DHCP issues to each machine) > > |(eth0 -- outer) > > LINUX_BRIDGE (not proxy, but is firewall on some ports) > > |(eth1 -- inner) > > 8_PORT_SWITCH > > |-Machine1 > |-Machine2 > > ... > > |-MachineN > > Except for my machine, the other machines will email and web browsing > machines (I do cvs, ssh, remote web site editing, and write network gam= e > software in Linux, as well as play games under windows). My goal is > similar to the cable modem "wonder shaper", but I'm not positive if > maybe I need to expand on that, and am currently not familiar with the > more advanced QoS and shaping abilities (I know they are there, I now > have some docs, and a machine I will be able to test on soon), > especially with respect to bridges. I want my machine to have low > latency, but the other machines do not care about latency; all machines > care about having a fair bandwidth. > > A problem I am thinking about (until I get my bridge done I can only > think about it, can't test anything) is that each machine is assigned > address via DHCP, so perhaps the Linux bridge will have to find a way t= o > know which DHCP address is assigned to which physical machine. If I wer= e > to simply assign qualities to the inside interface (eth1), then the sam= e > QoS and general characteristics would apply to all machines...which I d= o > not want, so it seems I must deal on a per-IP-address basis, or a > per-port basis. For port 80 web traffic, this seems just fine. I could > even assign a quality for telnet and ssh ports. However, if I suddenly > decide that one machine wants different characteristics for a port, or > if it is an unknown port (such as some games work with...they may not > always use the same port, or they can use more than one port at once), > this breaks. So I am wanting to deal with latency on a per-machine > basis, and simply assign low latency to my machine in general, and fair > bandwidth for all machines; perhaps after that, I could override for > particular ports, and for example, make all machines use port 80 web > traffic with higher latency, even on my machine (which is otherwise low > latency). > > Is this reasonable with current 2.4.x kernels? Are there particular > things to watch out for or look for, especially for a bridge? > > Also, I have used ipchains in the past, but it seems iptables will be > the future. What parts of this depend on iptables versus ipchains (if > any)? The iproute2 package seems to provide most of the features I'm > looking at, but it is conceivable that the use of ipchains or iptables > will interact. > > D. Stimits, stimits AT idcomm.com > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Aug 1 18:43:49 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 19:43:49 +0200 Subject: [LARTC] Best relation (value) of rate and burst in TBF and HTB In-Reply-To: <20020801103952.84279.qmail@web14803.mail.yahoo.com> References: <20020801103952.84279.qmail@web14803.mail.yahoo.com> Message-ID: <20020801174349.B5691DC4DA@tartarus.telenet-ops.be> On Thursday 01 August 2002 12:39, Cheng Kwok Wing, William wrote: > Hi, > > I'm going to setup a linux traffic control box and has > decided to adapt HTB. > > What should be the best relation(value) of rate and > burst? I mean the formula used to calculate burst give > rate or vice verse. > > I think the bandwidth of NIC and CPU processing speed > are also important in the calculation above. What else > are important?? Rate and burst do not really influence the CPU. The more classes you hav= e,=20 the more load it will give. But I once shaped 5.000 parallel streams on = a=20 10mbit connection with 486, 25hz, 8MB ram. I used htb and the box surviv= ed=20 the test without the load becoming bigger then 1.00. If you use latest htb, you only need a rate parameter. The burst will be= =20 callulated for you. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Aug 1 18:50:01 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 19:50:01 +0200 Subject: [LARTC] Two adapter, One IP address In-Reply-To: <3D490A3A.58C8565@cad.zju.edu.cn> References: <3D490A3A.58C8565@cad.zju.edu.cn> Message-ID: <20020801175002.BADC7DC4DA@tartarus.telenet-ops.be> On Thursday 01 August 2002 12:15, shen jing wrote: > Hi, > > I have a question, is it possible to assign one IP address to two > ntework adapter installed on the same Linux box? It's possible. > Must we use NAT at gateway to enable such a reduant configuation? If you want to read some about it, you can read the paper called "Some ev= il ideas about decentralised loadbalancing/clustering, with no=20 single point of failure " on www.ds9a.nl. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From get@andrew.cmu.edu Thu Aug 1 18:52:06 2002 From: get@andrew.cmu.edu (Gil Tolle) Date: Thu, 1 Aug 2002 13:52:06 -0400 (EDT) Subject: [LARTC] Many:Many NAT with DHCP external addresses In-Reply-To: <20020801173256.027A5DC226@tartarus.telenet-ops.be> Message-ID: The thing is, I'm trying to work around an address assignment decision made by my ISP. I'm running a local server on my side of the DSL line, with an address statically assigned to be .9.220. Every other machine on my side of the DSL is acquiring dynamic IP addresses in the .57.255 subnet with a default gateway of .57.1, on the other side of the DSL link. This causes the unfortunate side effect of forcing all traffic between the dynamically assigned machines and the statically assigned machine to travel across the DSL, even though both machines are on the same ethernet. In addition, if the DSL link goes down, as it tends to on occasion, the dynamic machines cannot acquire addresses, and therefore cannot communicate with the local server. My idea is to use a NAT machine to manage the routing myself. I would like to ensure that no traffic between local machines and the local server will go over the DSL, without having to add special routes to each dynamic client machine. I would also like to ensure that dynamic local machines can contact the static local server, even when the DSL is down and they cannot get DHCP addresses from the ISP's server. I would also like to keep the statically assigned server accessible from the public Internet. DHCP relay does not seem to solve the routing issue, and neither does the bridging. And if I am resigned to using NAT, I'd like to make it Many:Many NAT to avoid the occasional problems seen when using things like active FTP and online games behind Many:1 NAT. Thus the rationale behind my question. Have I missed something obvious that might satisfy the constraints above? Thanks, Gil On Thu, 1 Aug 2002, Stef Coene wrote: > On Thursday 01 August 2002 19:18, Gil Tolle wrote: > > I'm interested in setting up a NAT machine between a local network and a > > DSL-connected ISP. In order to avoid some of the problems with Many:1 NAT, > > I would like to take advantage of the fact that my ISP is willing to issue > > as many DHCP dynamic addresses as I ask for, possibly enabling me to set > > up Many:Many NAT for my local machines. Currently, the machines are all on > > the same switch as the bridging DSL modem and are acquiring DHCP addresses > > on their own. > > > > Is there a way to configure iproute2 under Linux to acquire external IP > > addresses from a DHCP server as needed, instead of selecting its own > > external IP addresses from a given subnet? > That's called a dhcp relay > Or you can configure the linux box as a bridge. > > But this is not the right place for this issue. > > Stef > > -- > > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net > > From stef.coene@docum.org Thu Aug 1 18:59:01 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 19:59:01 +0200 Subject: [LARTC] HTB parent rates and ceils In-Reply-To: <002001c23939$0101a7c0$9605a8c0@Gundy> References: <002001c23939$0101a7c0$9605a8c0@Gundy> Message-ID: <20020801175902.70C66DBD0B@tartarus.telenet-ops.be> On Thursday 01 August 2002 10:54, Nils Lichtenfeld wrote: > Hello @all, hello Devik! > > Whe have got a little confusion here. What of the following statements = is > true? > > - The ceil of a class should always be at least as high as the sum of t= he > rates of its children. False - The ceil of a class should always be at least as high as the maximum of= the=20 rates of its children : True If you have a class with ceil 100 kbps and a child-class with a ceil 150k= bps,=20 the never be reached due to the ceil of the parent. > - The rate of a class should always be at least as high as the sum of t= he > rates of its children. True If you don't respect this rule, the setup may work. I have to check this= =20 with Devik to be sure. But respecting this rule makes it easier to figur= e=20 out how the bandwidth will be distributed. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Thu Aug 1 19:00:15 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 20:00:15 +0200 Subject: [LARTC] Request In-Reply-To: <20020801074336.21187.qmail@webmail5.rediffmail.com> References: <20020801074336.21187.qmail@webmail5.rediffmail.com> Message-ID: <20020801180016.14BA7DBB85@tartarus.telenet-ops.be> On Thursday 01 August 2002 09:43, anish_46628 wrote: > Hi *, > > I have the enabled my kernel with the QoS options and to support > diffserv. I want to test whether it is working fine or not. Please > suggest me how can i check that my kernel is supporting diffserv > or not. Just try to execute some tc commands like=20 tc qdisc show And I hope you don't get any errors. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mabrown-lartc@securepipe.com Thu Aug 1 19:21:59 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Thu, 1 Aug 2002 13:21:59 -0500 (CDT) Subject: [LARTC] Many:Many NAT with DHCP external addresses In-Reply-To: Message-ID: Gil, I understand your problem, and why you'd choose to do it this way. Perhaps you (c|sh)ould look at udhcp....it's a small lightweight dhcp server which is ultimately scriptable and flexible. http://udhcp.busybox.net/ You can interface with it via a set of scripts. Instead of using the scripts that come with the distribution, you could write your own to grab public IPs from your ISPs dhcp server and then set up NAT to the internal IPs. If I were in your position, I'd: - run udhpcd on the inside interface - give IPs upon request to inside hosts (inside-0) - fork a process to request an IP from ISP - upon receiving IP (outside-0) from provider - setup NAT for outside-0 <--> inside-0 Good luck, -Martin : : The thing is, I'm trying to work around an address assignment decision : made by my ISP. I'm running a local server on my side of the DSL line, : with an address statically assigned to be .9.220. Every other machine on : my side of the DSL is acquiring dynamic IP addresses in the .57.255 subnet : with a default gateway of .57.1, on the other side of the DSL link. This : causes the unfortunate side effect of forcing all traffic between the : dynamically assigned machines and the statically assigned machine to : travel across the DSL, even though both machines are on the same ethernet. : In addition, if the DSL link goes down, as it tends to on occasion, the : dynamic machines cannot acquire addresses, and therefore cannot : communicate with the local server. : : My idea is to use a NAT machine to manage the routing myself. I would like : to ensure that no traffic between local machines and the local server will : go over the DSL, without having to add special routes to each dynamic : client machine. I would also like to ensure that dynamic local machines : can contact the static local server, even when the DSL is down and they : cannot get DHCP addresses from the ISP's server. I would also like to keep : the statically assigned server accessible from the public Internet. : : DHCP relay does not seem to solve the routing issue, and neither does the : bridging. And if I am resigned to using NAT, I'd like to make it Many:Many : NAT to avoid the occasional problems seen when using things like active : FTP and online games behind Many:1 NAT. Thus the rationale behind my : question. : : Have I missed something obvious that might satisfy the constraints above? : : Thanks, : Gil : : : On Thu, 1 Aug 2002, Stef Coene wrote: : : > On Thursday 01 August 2002 19:18, Gil Tolle wrote: : > > I'm interested in setting up a NAT machine between a local network and a : > > DSL-connected ISP. In order to avoid some of the problems with Many:1 NAT, : > > I would like to take advantage of the fact that my ISP is willing to issue : > > as many DHCP dynamic addresses as I ask for, possibly enabling me to set : > > up Many:Many NAT for my local machines. Currently, the machines are all on : > > the same switch as the bridging DSL modem and are acquiring DHCP addresses : > > on their own. : > > : > > Is there a way to configure iproute2 under Linux to acquire external IP : > > addresses from a DHCP server as needed, instead of selecting its own : > > external IP addresses from a given subnet? : > That's called a dhcp relay : > Or you can configure the linux box as a bridge. : > : > But this is not the right place for this issue. : > : > Stef : > : > -- : > : > stef.coene@docum.org : > "Using Linux as bandwidth manager" : > http://www.docum.org/ : > #lartc @ irc.openprojects.net : > : > : : _______________________________________________ : LARTC mailing list / LARTC@mailman.ds9a.nl : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From marcio@waw.com.br Thu Aug 1 20:01:24 2002 From: marcio@waw.com.br (Marcio Fraisleben Dias) Date: Thu, 1 Aug 2002 16:01:24 -0300 Subject: [LARTC] Filtering with MAC Address Message-ID: <01dc01c2398d$d550f5e0$0ddacbc8@MARCIO> Can someone help me to do 'tc filter' by MAC Address? I use HTB in my setup and it works wonderfully for IP, but I need to shape NAT connections, and I can't do it using IP addresses. Any suggestions welcome! Marcio Fraisleben Dias NetUnio Ltda. Internet Banda Larga - Soluçġes em Networking (55) 42 523 4100 From fineberg@aviating.com Thu Aug 1 20:07:59 2002 From: fineberg@aviating.com (Adam B. Fineberg) Date: Thu, 01 Aug 2002 12:07:59 -0700 Subject: [LARTC] Filtering with MAC Address References: <01dc01c2398d$d550f5e0$0ddacbc8@MARCIO> Message-ID: <3D49870F.9020700@aviating.com> Marcio Fraisleben Dias wrote: >Can someone help me to do 'tc filter' by MAC Address? I use HTB in my setup >and it works wonderfully for IP, but I need to shape NAT connections, and I >can't do it using IP addresses. Any suggestions welcome! > I was never able to figure it out either so if someone can help with this I'd appreciate it. Best regards, Adam Fineberg From stef.coene@docum.org Thu Aug 1 20:38:25 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 1 Aug 2002 21:38:25 +0200 Subject: [LARTC] Filtering with MAC Address In-Reply-To: <3D49870F.9020700@aviating.com> References: <01dc01c2398d$d550f5e0$0ddacbc8@MARCIO> <3D49870F.9020700@aviating.com> Message-ID: <20020801193826.A751BDC340@tartarus.telenet-ops.be> On Thursday 01 August 2002 21:07, Adam B. Fineberg wrote: > Marcio Fraisleben Dias wrote: > >Can someone help me to do 'tc filter' by MAC Address? I use HTB in my > > setup and it works wonderfully for IP, but I need to shape NAT > > connections, and I can't do it using IP addresses. Any suggestions > > welcome! > > I was never able to figure it out either so if someone can help with > this I'd appreciate it. You can filtering on source mac address with iptables : -m mac --mac-sour= ce=20 xx:xx:xx:xx:xx:xx. That you wat you can mark the packets with -j MARK=20 --set-mark 123 and use the fw filter. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From fineberg@aviating.com Thu Aug 1 22:15:39 2002 From: fineberg@aviating.com (Adam B. Fineberg) Date: Thu, 1 Aug 2002 14:15:39 -0700 Subject: [LARTC] Filtering with MAC Address References: <01dc01c2398d$d550f5e0$0ddacbc8@MARCIO> <3D49870F.9020700@aviating.com> <20020801193826.A751BDC340@tartarus.telenet-ops.be> Message-ID: <001301c239a0$9a629de0$0101a8c0@whizbang> > You can filtering on source mac address with iptables : -m mac --mac-source > xx:xx:xx:xx:xx:xx. That you wat you can mark the packets with -j MARK > --set-mark 123 and use the fw filter. My problem was I need to filter on the destination mac address and I couldn't figure a way to do that. Is there a --mac-destination? Adam From GregScott@InfraSupportEtc.com Fri Aug 2 08:46:17 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Fri, 2 Aug 2002 02:46:17 -0500 Subject: [LARTC] Why multiple NICs in a multiple route situation? Message-ID: <365871C49598504A9481DDBEC3EB495553D6@MAIL.InfraSupportEtc.com> In a situation with multiple routers to the Internet and a Linux firewall/router that either makes a choice about which route to use or load balances among the routes: > I don't think you *need* to have a separate NIC for each=20 > router, but if I were doing it, I'd want each router on a=20 > separate network. This has been bugging me - if a single NIC will work then what=20 value does another NIC add? Let's say the circuits are both T1. With two possible circuits, that's just a little more than 3mb per second. At 100 mbit per NIC, it would take more than 50 T1s to swamp it.=20 So why a NIC per T1? Why not just give a single NIC an=20 IP address in all the networks for each T1? Or am I missing something important? thanks - Greg Scott From support@obsidian-studios.com Fri Aug 2 08:57:26 2002 From: support@obsidian-studios.com (William L. Thomson Jr.) Date: 02 Aug 2002 00:57:26 -0700 Subject: [LARTC] Why multiple NICs in a multiple route situation? In-Reply-To: <365871C49598504A9481DDBEC3EB495553D6@MAIL.InfraSupportEtc.com> References: <365871C49598504A9481DDBEC3EB495553D6@MAIL.InfraSupportEtc.com> Message-ID: <1028275047.8022.16.camel@wlt.obsidian-studios.com> Greg, On Fri, 2002-08-02 at 00:46, Greg Scott wrote: > In a situation with multiple routers to the Internet and a > Linux firewall/router that either makes a choice about which > route to use or load balances among the routes:. > > This has been bugging me - if a single NIC will work then what > value does another NIC add? Let's say the circuits are both T1. > With two possible circuits, that's just a little more than 3mb > per second. At 100 mbit per NIC, it would take more than 50 > T1s to swamp it. > > So why a NIC per T1? Why not just give a single NIC an > IP address in all the networks for each T1? Or am I missing > something important? Please someone correct me if I am wrong. To my knowledge ethernet does mostly broadcasting. So the traffic from one router will be bounced off both. If one says hello I am this ip, the other will say it's ip, until the proper path is determined. It's kind of like the difference between a switch and a hub, sort of. I would recommend trying to isolate the traffic from each to the Linux router if possible, using a nic per connection/router. With dual or multiple port nic cards it's not so much of an issue. Even though the nic is on the Linux side will be 100mbit, most routers are only 10mbit, so the broadcast flooding could become an issue. Also in order to use a single nic with multiple connections another device like a switch or a hub will have to be inline. Which will create another hop. So for that reason alone it's worth having two nics, or at least a port per connection/router. So for example in my case I do Router1 --| | |-- Server | Linux Router |-- Switch --|-- Server Router2 --| | |-- Server Otherwise you will have to have two switches or hubs. I mean how can you connect two devices to one ethernet port? So two reasons I can think of are: 1. To isolate broadcasts from each router 2. To reduce hops to the Linux Router I really can't think of any other reason. Maybe someone else can? -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com From psi@platon.atlantis.sk Fri Aug 2 09:07:32 2002 From: psi@platon.atlantis.sk (M.F. PSIkappa) Date: Fri, 2 Aug 2002 10:07:32 +0200 (CEST) Subject: [LARTC] Filtering with MAC Address In-Reply-To: <001301c239a0$9a629de0$0101a8c0@whizbang> Message-ID: Maybe you can use ebtables http://users.pandora.be/bart.de.schuymer/ebtables/ ebtables are iptables which understand ethernet protocol. On Thu, 1 Aug 2002, Adam B. Fineberg wrote: > > You can filtering on source mac address with iptables : -m > mac --mac-source > > xx:xx:xx:xx:xx:xx. That you wat you can mark the packets with -j MARK > > --set-mark 123 and use the fw filter. > > My problem was I need to filter on the destination mac address and I > couldn't figure a way to do that. Is there a --mac-destination? > > Adam -- `)_|_(' PSIkappa I k psi _at_ atlantis.sk From zipzeroo@hotmail.com Sat Aug 3 08:21:16 2002 From: zipzeroo@hotmail.com (d d) Date: Sat, 03 Aug 2002 07:21:16 +0000 Subject: [LARTC] limiting outgoing bandwidth Message-ID:
i have a linux server/firewall running for my network 192.168.1.10/255. my set up is as follows...i have a adsl modem ppp0 interface that uses an ethernet card eth1, connected to server.my network is on eth0. i am currently running cbq.init-v0.7 script for limiting incoming bandwidth on a per ip basis.this works well.there are 14 clients on the network and they all use peer to peer programs like kazaa,etc. the connection is 1300k down and only 256k up , and at times the outgoing bandwidth is used up. i would really like to limit the outgoing bandwidth on a per ip basis, since i have a ftp server running on my pc, a client on the network and would prefer to allow it half the available outgoing bandwidth while limiting the other clients to very small outgoing bandwidth.
need help!!!!... any suggestions please...anything thing that works to limit outgoing bandwidth 
thanx for the help in advance

Chat with friends online, try MSN Messenger: Click Here
From gbiondi@tech2.it Sat Aug 3 10:34:19 2002 From: gbiondi@tech2.it (Giorgio Biondi) Date: Sat, 3 Aug 2002 11:34:19 +0200 Subject: [LARTC] Iproute + masquerade on 2 ISP with traffic blancing... Message-ID: <20020803113419.01c3d5d1.gbiondi@tech2.it> Hi, I have a linux-box with 3 eth, 2 of us go into 2 ISP. My localnet is masquerade with this rule: Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.0.0.0/16 anywhere to:211.56.233.186 SNAT all -- 10.0.0.0/16 anywhere to:211.13.8.50 Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@fw /root]# ip route show 211.56.233.184/29 dev eth1 proto kernel scope link src 211.56.233.186 211.13.8.48/28 dev eth2 proto kernel scope link src 211.13.8.50 211.13.13.0/24 via 212.13.8.49 dev eth2 10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.1.2 127.0.0.0/8 dev lo scope link default nexthop via 211.56.233.185 dev eth1 weight 10 nexthop via 211.13.8.49 dev eth2 weight 1 ...and all work well (seems...) My traffic in reality go to in the first masquerade interface (in this case go to all in the eth1) indipendly from value 'weight'.... Where are wrong??? From stef.coene@docum.org Sat Aug 3 11:16:32 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 3 Aug 2002 12:16:32 +0200 Subject: [LARTC] limiting outgoing bandwidth In-Reply-To: References: Message-ID: <20020803101633.65E59DC570@tartarus.telenet-ops.be> Hi, More info can be found on www.lartc.org and I have some examples and extr= a=20 info about shaping on www.docum.org. Stef PS. It seems to me that your shift and enter key is broken. =20 On Saturday 03 August 2002 09:21, d d wrote: > i have a linux server/firewall running for my network 192.168.1.10/255.= my > set up is as follows...i have a adsl modem ppp0 interface that uses an > ethernet card eth1, connected to server.my network is on eth0. i am > currently running cbq.init-v0.7 script for limiting incoming bandwidth = on a > per ip basis.this works well.there are 14 clients on the network and th= ey > all use peer to peer programs like kazaa,etc. the connection is 1300k d= own > and only 256k up , and at times the outgoing bandwidth is used up. i wo= uld > really like to limit the outgoing bandwidth on a per ip basis, since i = have > a ftp server running on my pc, a client on the network and would prefer= to > allow it half the available outgoing bandwidth while limiting the other > clients to very small outgoing bandwidth. need help!!!!... any suggesti= ons > please...anything thing that works to limit outgoing bandwidth=A0 thanx= for > the help in advance > > Chat with friends online, try MSN Messenger: Click Here > _______________________________________________ LARTC mailing list / > LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOW= TO: > http://lartc.org/ --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From jwickman@tawi.fi Sun Aug 4 02:07:11 2002 From: jwickman@tawi.fi (Joachim Wickman) Date: Sun, 4 Aug 2002 04:07:11 +0300 Subject: [LARTC] Computer Message-ID: <001801c23b53$43f7c1b0$010aa8c0@floppe> Hello, How powerful computer do I need when I want to trafic shape & firewall a 2Mbit Internet line? // Joachim From stef.coene@docum.org Sun Aug 4 09:42:22 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 4 Aug 2002 10:42:22 +0200 Subject: [LARTC] Computer In-Reply-To: <001801c23b53$43f7c1b0$010aa8c0@floppe> References: <001801c23b53$43f7c1b0$010aa8c0@floppe> Message-ID: <20020804084223.883ECDC1F5@tartarus.telenet-ops.be> 486 is enough as long as the setup is not too complicated. Stef On Sunday 04 August 2002 03:07, Joachim Wickman wrote: > Hello, > > > How powerful computer do I need when I want to trafic shape & firewall = a > 2Mbit Internet line? > > > // Joachim > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From robert.penz@outertech.com Mon Aug 5 01:00:35 2002 From: robert.penz@outertech.com (Robert Penz) Date: Mon, 5 Aug 2002 02:00:35 +0200 Subject: [LARTC] iptables post/pre rountig problem Message-ID: <200208050200.36062.robert.penz@outertech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm trying to exclude some ip ranges from my traffic filter, for that I m= ark=20 the packets in PRE-/POST-ROUTING. If I mark them straight ahead it works, but if I want to do that in a use= r=20 chain I get the message that userchain.so can't beloaded. iptables -N capped_in iptables -N capped_out # put all incoming traffic to IMQ iptables -t mangle -A PREROUTING -i eth0 -j IMQ # mark all packets which need to be capped iptables -t mangle -A PREROUTING -i eth0 -d xxx.xxx.xxx.141 -s !=20 xxx.xxx.xxx.0/24 -j capped_in iptables -A capped_in -s yyy.yyy.yyy.0/27 -j RETURN iptables -A capped_in -j MARK --set-mark 2 # now the outgoing traffic iptables -t mangle -A POSTROUTING -o eth0 -s xxx.xxx.xxx.141 -d !=20 xxx.xxx.xxx.0/24 -j capped_out iptables -A capped_out -s yyy.yyy.yyy.0/27 -j RETURN iptables -A capped_out -j MARK --set-mark 1 Can anyone tell me how I can achieve? thx - --=20 Regards, Robert - ---------------- Robert Penz robert.penz@outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9TcAj8tTsQqJDUBMRAoSfAKCDG3rDZsegmeR9HlvsnNptPIyiMwCdH/An af69+Ymez7VxWqBtX8I40Yg=3D =3Dk0pV -----END PGP SIGNATURE----- From wing328@yahoo.com Mon Aug 5 04:28:18 2002 From: wing328@yahoo.com (Cheng Kwok Wing, William) Date: Sun, 4 Aug 2002 20:28:18 -0700 (PDT) Subject: [LARTC] Question on FW and htb Message-ID: <20020805032818.43267.qmail@web14801.mail.yahoo.com> Hi, I've try to use htb to limit outgoing traffic but it seems that it doesn't work. I guess the probem is the filter. Here is my script. #!/bin/sh echo "Add root qdisc, default traffic go to 1:30" tc qdisc add dev eth1 root handle 1: htb default 30 tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit burst 15k tc class add dev eth1 parent 1:1 classid 1:10 htb rate 2mbit ceil 2.5mbit burst 1m tc class add dev eth1 parent 1:1 classid 1:20 htb rate 1mbit ceil 1.5mbit burst 1m echo "SFQ for leaf" tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 echo "Add the filters which direct traffic to the right classes:" tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 1 fw classid 1:10 tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 2 fw classid 1:20 tc filter add dev eth1 parent 1:1 protocol ip prio 3 handle 1 fw classid 1:10 tc filter add dev eth1 parent 1:1 protocol ip prio 3 handle 2 fw classid 1:20 When I use the command "tc -s -d qdisc" to show all qdisc, it seems that nothing pass through SFQ. [root@localhost tc]# tc -s -d qdisc qdisc sfq 20: dev eth1 quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 10: dev eth1 quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 1: dev eth1 r2q 10 default 30 dcache 0 deq_util 1/1000000 deq_rate 77 trials_per_deq 0 dcache_hits 0 direct_packets 12786 Sent 18636370 bytes 12786 pkts (dropped 0, overlimits 0) What's the problem?? I'm pretty sure I've mark the packet correctly as shown below: [root@localhost tc]# iptables -L -n -v -t mangle Chain PREROUTING (policy ACCEPT 489K packets, 285M bytes) pkts bytes target prot opt in out source destination 3799 454K MARK all -- * * 0.0.0.0/0 10.0.0.0/8 MARK set 0x1 190K 12M MARK all -- * * 10.0.0.0/8 0.0.0.0/0 MARK set 0x1 0 0 MARK all -- * * 0.0.0.0/0 192.168.1.224/29 MARK set 0x2 0 0 MARK all -- * * 192.168.1.224/29 0.0.0.0/0 MARK set 0x2 Please help. Thanks, William __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From angel@khaosse.net Mon Aug 5 07:59:53 2002 From: angel@khaosse.net (Simon Bland) Date: Mon, 5 Aug 2002 16:59:53 +1000 (EST) Subject: [LARTC] Ip accounting, masq'ing and bandwidth sharing Message-ID: I'll cut to the chase of what I'm trying to do.. I've set up my system with a 56k dial-up connection on the gateway, and 3 machines on the LAN. I'm using a set of iptables to handle the firewall and Masq'ing, and ipac-ng to do the accounting on a per ip basis for each machine on the LAN's usage. All that's pretty trivial.. What I want to do next is be able to guarentee bandwidth to each machine on the LAN, so that 1 person trying to pull large amounts of data doesn't totally lock the others off being able to do whatever they want to use it for.. >From what I've read this can be done by applying a set of queues on the eth0 side of the gateway machine, but that doesn't seem to make sense (how do the queues there prevent the modem from being choked by the incoming data? What I'd like is either an explanation of how queueing on eth0 works for what I'm doing, or a set of rules/explanations of how to set up an appropriate set of queues on the ppp interface that handle the masq'ing settings.. Hope that makes sense.. Thanks. :) -- Freedom is just chaos with better lighting. From stef.coene@docum.org Mon Aug 5 18:59:25 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 5 Aug 2002 19:59:25 +0200 Subject: [LARTC] Ip accounting, masq'ing and bandwidth sharing In-Reply-To: References: Message-ID: <20020805175926.2F3CCDC812@tartarus.telenet-ops.be> > What I'd like is either an explanation of how queueing on eth0 works fo= r > what I'm doing, or a set of rules/explanations of how to set up an > appropriate set of queues on the ppp interface that handle the masq'ing > settings.. You can't control how much data you receive. But you can try to do it. = If=20 you give one connection 1kbyte/s, tcp will control his behaviour untill t= he=20 1kilobyte/s is reached. But you can't prevent that they send more. =20 All data that you receive on ppp0 is also transmitted on eth0. So=20 controlling the outgoing bandwidth on eth0 is the same as controlling the= =20 incoming traffic on ppp0 (if you don't run any special services on the bo= x). =20 You can't control incoming traffic (there some work arounds), so you have= to=20 use eth0 to control the incoming traffic on ppp0 If you make sure you never receive that so many data that the modem can't= =20 handle it, you will never have big queueus in the modem. So limiting the= =20 total incoming traffic on ppp0 to 99% of the link, is a good idea. Big=20 queues means a long time for a packet to travel thru the queue, so this=20 create big latency. By creating a queue for each ip in the LAN, you can make sure that each I= P=20 has the same chance to send/receive something. So launching 10 parallel=20 downloads is useless. Stef=20 --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Mon Aug 5 19:03:06 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 5 Aug 2002 20:03:06 +0200 Subject: [LARTC] Question on FW and htb In-Reply-To: <20020805032818.43267.qmail@web14801.mail.yahoo.com> References: <20020805032818.43267.qmail@web14801.mail.yahoo.com> Message-ID: <20020805180307.6A4C1DC243@tartarus.telenet-ops.be> On Monday 05 August 2002 05:28, Cheng Kwok Wing, William wrote: What shows=20 tc -s -d class show dev eth > echo "Add the filters which direct traffic to the > right classes:" > tc filter add dev eth1 parent 1:0 protocol ip prio 3 > handle 1 fw classid 1:10 > tc filter add dev eth1 parent 1:0 protocol ip prio 3 > handle 2 fw classid 1:20 > > tc filter add dev eth1 parent 1:1 protocol ip prio 3 > handle 1 fw classid 1:10 > tc filter add dev eth1 parent 1:1 protocol ip prio 3 > handle 2 fw classid 1:20 Why do you attach these filters to 1:1 ?? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From tech@playawireless.com Tue Aug 6 01:39:52 2002 From: tech@playawireless.com (Alfredo Giordano) Date: Mon, 5 Aug 2002 19:39:52 -0500 Subject: [LARTC] Routing internet to private network References: Message-ID: <000801c23ce1$c77c8590$130ce994@playawireless.com> Ok, first of all what kernel version do you have? To find out do uname -r you probably have a 2.2.x that doesn't have iptable bye Alfredo ----- Original Message ----- From: "Kenny Mallants" To: Sent: Sunday, August 04, 2002 11:18 AM Subject: Re: [LARTC] Routing internet to private network > Hi Alfredo, > > first of all thxs for your reply and sorry for my late reaction! > I can't load the iptable_nat. Get some errors so couldn't try it. > Is there no other possibillity? > > Thx, > Kenny > > >Try: > >----------------- > >modprobe iptable_nat > >iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > >echo 1 > /proc/sys/net/ipv4/ip_forward > >----------------- > > > >let me know ;-) > > > >Alfredo > > > > > > > > > >----- Original Message ----- > >From: "Kenny Mallants" > >To: > >Sent: Wednesday, July 17, 2002 11:18 AM > >Subject: [LARTC] Routing internet to private network > > > > > > > Hi, > > > > > > How can I share my internet connection (eth0 using dhcp) with my private > > > network (eth1 192.168.0.*)?? > > > > > > Greets, > > > Kenny > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > > --- > (o_ > (o_ (o_ //\ > (/)_ (\)_ V_/_ > |~~~~~~~~~~~~~~~~~~~~~~| > | Beware of the Penguin| > |~~~~~~~~~~~~~~~~~~~~~~| > > ############################# > ##ccc r rr A zzzz y y#- > ##c rr A A z yy #- > ##c r AAA z y #- > ##ccc r A A zzzz y #- > #############################- > ---------------------------- > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > From mmrmedia@yahoo.com Tue Aug 6 10:38:21 2002 From: mmrmedia@yahoo.com (maart b) Date: Tue, 6 Aug 2002 02:38:21 -0700 (PDT) Subject: [LARTC] IMQ device or resource busy Message-ID: <20020806093821.51197.qmail@web14907.mail.yahoo.com> Hi When i try to load the imq module like insmod imq numdevs=1 i get he following error message init_module: Device or resource busy kernel 2.4.18 imq-2.4.18.diff-10 iptables-1.2.6a-img-diff3 sch_generic.diff all patched and compiled cleanly the modules are in place so what could keep the device busy? thanks in advance maart __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From landreani@seltatel.it Tue Aug 6 11:12:19 2002 From: landreani@seltatel.it (Andreani Luca) Date: Tue, 6 Aug 2002 12:12:19 +0200 Subject: [LARTC] max acceptaple values Message-ID: <6812F61B83A6D411BF250060B01B7BAC4A6F4A@SELTATOR> Dear All, I'm building a graphical interface for the configuration of QoS under Linux. The program translates the configuration and issues the appropriate tc commands. I have to establish the max values for all configurable parameter to avoid errors running tc. In fact, due to the needs of the linux-based router I'm developing, I can't have any feedback from the system. The question is: Can anybody tell me the max values for the following parameters? - Major and minor numbers in qdisc-id class-id - Filter priority - flow-id - Number of classes in PRIO qdisc - Rate and avpkt in CBQ qdisc - Rate bucket dimension and max-wait in TBF Thanks in advance, Luca From marcus@ingate.com Tue Aug 6 14:29:51 2002 From: marcus@ingate.com (Marcus Sundberg) Date: 06 Aug 2002 15:29:51 +0200 Subject: [LARTC] PSCHED_CLOCK_SOURCE Message-ID: Hi, just wondering whether my assumption that, assuming an IA32 machine with working TSC, using PSCHED_CLOCK_SOURCE == PSCHED_CPU will give significantly better accuracy and at least as good performance as using PSCHED_CLOCK_SOURCE == PSCHED_JIFFIES? //Marcus -- ---------------------------------------+-------------------------- Marcus Sundberg | Firewalls with SIP & NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/ From kaber@trash.net Tue Aug 6 15:47:27 2002 From: kaber@trash.net (Patrick McHardy) Date: Tue, 06 Aug 2002 16:47:27 +0200 Subject: [LARTC] IMQ device or resource busy References: <20020806093821.51197.qmail@web14907.mail.yahoo.com> Message-ID: <3D4FE17F.6080304@trash.net> you probably got netfilter ip_queue compiled in, disable it and see if it helps. bye, patrick maart b wrote: > Hi > > When i try to load the imq module like > insmod imq numdevs=1 i get he following error message > init_module: Device or resource busy > > kernel 2.4.18 > imq-2.4.18.diff-10 > iptables-1.2.6a-img-diff3 > sch_generic.diff > > all patched and compiled cleanly > the modules are in place > > so what could keep the device busy? > > thanks in advance > > maart > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From kaber@trash.net Tue Aug 6 16:42:10 2002 From: kaber@trash.net (Patrick McHardy) Date: Tue, 06 Aug 2002 17:42:10 +0200 Subject: [LARTC] iptables post/pre rountig problem References: <200208050200.36062.robert.penz@outertech.com> Message-ID: <3D4FEE52.2010709@trash.net> Hi Robert, Robert Penz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I'm trying to exclude some ip ranges from my traffic filter, for that I mark > the packets in PRE-/POST-ROUTING. > > If I mark them straight ahead it works, but if I want to do that in a user > chain I get the message that userchain.so can't beloaded. > > iptables -N capped_in > iptables -N capped_out > > # put all incoming traffic to IMQ > iptables -t mangle -A PREROUTING -i eth0 -j IMQ > # mark all packets which need to be capped > iptables -t mangle -A PREROUTING -i eth0 -d xxx.xxx.xxx.141 -s ! > xxx.xxx.xxx.0/24 -j capped_in > iptables -A capped_in -s yyy.yyy.yyy.0/27 -j RETURN > iptables -A capped_in -j MARK --set-mark 2 > > # now the outgoing traffic > iptables -t mangle -A POSTROUTING -o eth0 -s xxx.xxx.xxx.141 -d ! > xxx.xxx.xxx.0/24 -j capped_out > iptables -A capped_out -s yyy.yyy.yyy.0/27 -j RETURN > iptables -A capped_out -j MARK --set-mark 1 > > Can anyone tell me how I can achieve? thx Did you try -t mangle -A capped_in/out ? Your chains were created in the mangle table, so they can only be called from within mangle. Bye, Patrick From kaber@trash.net Tue Aug 6 16:46:44 2002 From: kaber@trash.net (Patrick McHardy) Date: Tue, 06 Aug 2002 17:46:44 +0200 Subject: [LARTC] problem dumping statistics from queueing discipline Message-ID: <3D4FEF64.6010300@trash.net> Hi. I already wrote to linux-net but noone responded there and i don't want to go on peoples nerves in netdev with this, maybe someone here can help me .. I want to supply extra data to print_copt and print_xstats so i tried this code: ... rta = (struct rtattr *)b; RTA_PUT(skb, TCA_OPTIONS, 0, NULL); RTA_PUT(skb, TCA_XSTATS, 0, NULL); if (trc_dump_attr(skb, cl) < 0) goto rtattr_failure; rta->rta_len = skb->tail - b; if (qdisc_copy_stats(skb, &cl->stats)) goto rtattr_failure; ... The extra data gets added in trc_dump_attr. The problem is, depending on wether i add empty TCA_OPTIONS before TCA_XSTATS or the other way around, only one of them seems to make it to userspace, so only print_copt or print_xstats is called, but not both. I don't understand why this doesn't works, please someone explain it to me ;) Thanks & Bye, Patrick From mbabcock@fibrespeed.net Tue Aug 6 17:30:47 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Tue, 06 Aug 2002 12:30:47 -0400 Subject: [LARTC] Why multiple NICs in a multiple route situation? References: <365871C49598504A9481DDBEC3EB495553D6@MAIL.InfraSupportEtc.com> Message-ID: <3D4FF9B7.60505@fibrespeed.net> Greg Scott wrote: >So why a NIC per T1? Why not just give a single NIC an >IP address in all the networks for each T1? Or am I missing >something important? > > I don't like the fact that one ISP can 'see' the other ISP if they decide to actually 'look'. -- Michael T. Babcock From mmrmedia@yahoo.com Tue Aug 6 18:31:41 2002 From: mmrmedia@yahoo.com (maart b) Date: Tue, 6 Aug 2002 10:31:41 -0700 (PDT) Subject: [LARTC] IMQ device or resource busy In-Reply-To: <3D4FE17F.6080304@trash.net> Message-ID: <20020806173141.15332.qmail@web14904.mail.yahoo.com> --- Patrick McHardy wrote: > you probably got netfilter ip_queue compiled in, > disable it and see if > it helps. > bye, > patrick > Hallo Patrick your right i did load the module ip_queue when i remove it works thanks again maart __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From raptor@unacs.bg Tue Aug 6 19:22:15 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Tue, 6 Aug 2002 21:22:15 +0300 Subject: [LARTC] Ip accounting, masq'ing and bandwidth sharing In-Reply-To: References: Message-ID: <20020806212215.1babf13f.raptor@unacs.bg> from what i've read on the lartc-faq best suited for this sort of things is SFQ ... read the explanation and u will understand.. HtH raptor@unacs.bg From lartc@medz.org Tue Aug 6 20:21:27 2002 From: lartc@medz.org (Stephan Jager) Date: Tue, 06 Aug 2002 21:21:27 +0200 Subject: [LARTC] multiple inet and local connectivity Message-ID: <200208061921.g76JLR0X001066@alpha.medz.org> Hi, I have 1 local network (eth0) and 2 internet connections. I used the technique described at 4.2 in the LARTC to make a propper connection to/from the both internet connections. This works fine. I also use SNAT to provide an internet connection from my local net (eth0). I use this iptables line: iptables -A POSTROUTING -t nat -o eth1 -j SNAT --to-source 123.123.123.123 (123.123.123.123 is the IP address of the eth1 interface). This workes fine. The problem is that I can't connect from my local network the the IP address of eth1 and eth2! For example: 10.0.0.2 -> 123.123.123.123 doesn't work, but 10.0.0.2 -> 10.0.0.1 does work (eth0 address) Also 10.0.0.2 -> 234.234.234.234 ain't working (eth2 address) I can't seem to fix it. I think I need some additional routing rules, but which ones I can't seem to find out. Anybody got any tips? Stephan From arthurvl@sci.kun.nl Tue Aug 6 21:17:17 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Tue, 6 Aug 2002 22:17:17 +0200 (MEST) Subject: [LARTC] multiple inet and local connectivity In-Reply-To: <200208061921.g76JLR0X001066@alpha.medz.org> Message-ID: On Tue, 6 Aug 2002, Stephan Jager wrote: > Anybody got any tips? Yes. Read the mailinglist. This has been explained about 6 weeks ago. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From rust Wed Aug 7 09:01:27 2002 From: rust (rust) Date: Wed, 7 Aug 2002 12:01:27 +0400 Subject: [LARTC] 3 providers route - help me Message-ID: <19492403469.20020807120127@vinet.ru> Hello lartc, Sorry for my english. My conf: Linux kernel 2.4.18 + ipchains I have: 1) eth1 - via SATelite only send data - with 195.x.x.2 and ISP1 ip 195.x.x.1 2) eth1:1 - via SATelite only recieve data - with 212.x.x.218 and ISP2 ip 212.x.x.217 3) eth0 - local network with 192.168.0.x 4) eth0:1 - local network with 192.168.1.x Default gateway 212.x.x.217 eth1:1 Script for ipchains /sbin/ipchains -F /sbin/ipchains -A forward -s 192.168.0.1/24 -j MASQ /sbin/ipchains -A forward -s 192.168.1.1/24 -j MASQ |---------------| | | ISP2 | |212.x.x.218 212.x.x.217 192.168.0.x 192.168.0.1| eth1:1|<<<----------------------- -------------------------|eth0 | | | ISP1 192.168.1.x 192.168.1.1| |195.x.x.2 195.x.x.1 -------------------------|eth0:1 eth1|----------------------->>> | | |---------------| All work fine. Now we added new ISP3 1) eth3 - with ip 217.x.x.170 and ISP1 ip 217.x.x.169 Now new default gateway 217.x.x.169 with gatewaydev eth3 isp1 |217.x.x.169 | | |217.x.x.170 |---------------| | eth3 | ISP2 | |212.x.x.218 212.x.x.217 192.168.0.x 192.168.0.1| |<<<----------------------- -------------------------|eth0 | | | ISP1 192.168.1.x 192.168.1.1| |195.x.x.2 195.x.x.1 -------------------------|eth0:1 |----------------------->>> | | |---------------| Now I want to net 192.168.0.x use new ISP3, net 192.168.1.x use old ISP1 and ISP2 # Net 192.168.0.x default into main table ip ru add pref 10 to 192.168.0.1/24 tab main # Now incoming traffic from ISP2 - (ip 212.x.x.218) send to ISP1 # ip - 195.x.x.2 ip ru add pref 20 from 212.x.x.218 tab 201 ip route add default via 195.x.x.2 dev eth1 table 201 # And now for net 192.168.0.x ip rule add from 192.168.1.0/24 table 200 ip ro add default via 218.x.x.217 dev eth1 table 200 But now i see with tcpdump -i eth1 when ping www.list.ru from 192.168.1.x 11:53:25.367532 > my_linux_box > host1.list.ru: icmp: echo request 11:53:26.363947 > my_linux_box > host1.list.ru: icmp: echo request 11:53:27.375236 > my_linux_box > host1.list.ru: icmp: echo request 11:53:28.376499 > my_linux_box > host1.list.ru: icmp: echo request And tcpdump -i eth3 11:53:25.796200 < host1.list.ru > my_linux_box: icmp: echo reply 11:53:26.832670 < host1.list.ru > my_linux_box: icmp: echo reply 11:53:27.815478 < host1.list.ru > my_linux_box: icmp: echo reply 11:53:28.752727 < host1.list.ru > my_linux_box: icmp: echo reply Packets go to ISP1 and return over ISP3, but need go ISP1 and return over ISP2 Can you help me?? How configure routing in this conf?? -- Best regards, rust mailto:rust@vinet.ru From arindamhaldar@inbox.lv Wed Aug 7 09:41:38 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Wed, 07 Aug 2002 14:11:38 +0530 Subject: [LARTC] Error ! Message-ID: <3D50DD42.8040004@inbox.lv> hi all, i got the following error while compiling lartc with patched htb3.6_tc.diff.. In file included from arpd.c:19: ../include-glibc/db.h:10:20: db_185.h: No such file or directory make[1]: *** [arpd.o] Error 1 make[1]: Leaving directory `/usr/local/src/iproute2/misc' make: *** [all] Error 2 [root@Lr1 iproute2]# kernel version is 2.4.19 & lartc version is iproute2-2.4.7-now-ss020116-try.tar.gz iproute2-2.4.7-now-ss010824.tar.gz didnt gaveany errors though !! anyone found similar error ??.. i checked include-glibc directory & didnt find the file mentioned in error-->db_185.h any views/guidance is welcome.. awaing a reply.. A.H From glouis@dynamicro.on.ca Wed Aug 7 13:20:27 2002 From: glouis@dynamicro.on.ca (Greg Louis) Date: Wed, 7 Aug 2002 08:20:27 -0400 Subject: [LARTC] htb in the 2.4 tree, woo woo Message-ID: <20020807082027.7f0dd77b.glouis@dynamicro.on.ca> Just discovered the hard way (trying to patch) that Marcelo's got htb in the 2.4.20-pre1 tree. Way to go! (I'm surprised it hasn't been announced on this list before -- did I miss something?) -- | G r e g L o u i s | gpg public key: | | http://www.bgl.nu/~glouis | finger greg@bgl.nu | From caznar@stechcomm.com Wed Aug 7 14:00:22 2002 From: caznar@stechcomm.com (Claudio Aznar) Date: Wed, 7 Aug 2002 10:00:22 -0300 Subject: [LARTC] Ingress polices Message-ID: <20020807100022.0b2075ed.caznar@stechcomm.com> Hi list, I'm making BW control using filter police rate with ingress qdisc, it work fine but i have few question: 1. How to set different priorities for this filter, (I can dom it?), because if I set different priority, the filters are multiplied. 2. How I can combine different condition in only one filter, sharing the same BW of course. For example: port 80 and port 3128 with the same police rate of 128 Kbit. (Again, I can do it?). The possible way is using classes and two interfaces, but the limitation is that I control port (protocols) in one interface (eth0) and clients (BW max for each) in other (eth1). Thank in advance Claudio Aznar From stefan@ms-kaiser.de Wed Aug 7 14:16:38 2002 From: stefan@ms-kaiser.de (Stefan Kaiser) Date: Wed, 7 Aug 2002 15:16:38 +0200 Subject: [LARTC] policy routing Message-ID: Hello, i am using suse-linux 8.0 and i am trying to get this to work: eth0 =3D local network ppp0 =3D dsl modem ippp0=3D isdn-card network traffic coming from eth0 and going to ppp0 by default network traffic to dport25 is routed to ippp0 (dynamic-ip) the traffic from eth0 to ppp0 is working but the configuration for ippp0 is killing me :-( marking the pakets: # iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 25 \ -j MARK --set-mark 1 configuring the policy routing database: # echo 201 mail.out >> /etc/iproute2/rt_tables # ip rule add fwmark 1 table mail.out # ip rule ls 0: from all lookup local 32764: from all fwmark 1 lookup mail.out 32766: from all lookup main 32767: from all lookup default and at last the mail.out table with the route to ippp0, but that=B4s my problem: (i think) # ip route add default dev ippp0 table mail.out when i am now sending a mail (port25) ippp0 is dialing, but then the route is deleted, so i set the route again manual with the above command, but the mail is not delivered i have tryed to route the pakets back to my local net to the external isdn-router: # ip route add default via 192.168.21.10 dev eth0 table mail.out this is working!!! where do i fail? when i try to set "default route" in the isdn configuration my default route to the dsl connection is deleted I hope somebody can help me regards, stefan From thomas.speck@wanadoo.fr Wed Aug 7 15:43:29 2002 From: thomas.speck@wanadoo.fr (Thomas SPECK) Date: Wed, 07 Aug 2002 16:43:29 +0200 (MET DST) Subject: [LARTC] pb with ingress policy Message-ID: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) Hi ! I have a single host which is connected via an 512kbit ADSL link to the n= et. I quite often use some realaudio application that uses some bandwidth = and I want to avoid other traffic to scale that bandwidth down. So I used = some classes (with htb) on imq0 device and applied some filters and it see= ms to work in most cases. However, there are some sites with which downloa= d is interrupted if bandwidth is limited. I tried to trace it down and did= some simple test: modprobe imq numdevs=3D1 tc qdisc add dev imq0 root handle 1: htb default 10 tc class add dev imq0 parent 1: classid 1:10 htb rate 60kbit ceil 512kbit= burst 15k tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0 ip li set imq0 up So now all traffic is limited to 60kbit. If I use some particular site fo= r downloading (with wget) I observe the following with tcpdump: At the beginning there is a huge burst (wget indicating something like 45= kbps) than speed decreases dramatically and achieves some equilibrium aro= und 60kbit. Then for some reason after about 15 seconds my host sends FIN = to the other site. Why =3F ;-) Is that a problem with some queue being too full after the burst at the b= eginning =3F I tried to play with the burst option and I also used the pmtu stuff (ipt= ables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-= pmtu) without success. Anyone having an idea =3F Kernel 2.4.19, iptables 1.2.6a. Thank you -- Thomas From b@aufbix.org Wed Aug 7 15:32:18 2002 From: b@aufbix.org (Borut Mrak) Date: Wed, 7 Aug 2002 16:32:18 +0200 Subject: [LARTC] problems with vlans Message-ID: <20020807143224.9E71636E4B9@hydra.aufbix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. My setup: P3 box, a few ethernet interfaces (eepro100) shaping traffic to some of my customers. It's been working fine for more than a year. Each interface has a root cbq qdisc with n (=num of customers) classes, u32 filters are used to classify the packets according to src/dst addresses. These are the commands used (taken from a perl script which parses a simple config file, therefore the $ variables): /sbin/tc qdisc add dev $device root handle $handle cbq bandwidth $bandwidth avpkt 1000 /sbin/tc class add dev $device parent $rh{$device}0 classid $handle cbq bandwidth 100mbit rate $bandwidth allot 1514 weight 100kbit prio 1 maxburst 1 avpkt 1000 bounded /sbin/tc filter add dev $device parent $rh{$device}0 protocol ip prio 100 u32 match ip $direction $netblock flowid $handle I tried moving this to a new machine using only 2 eepro100 interfaces and using vlans (one port per customer is really quite expensive on an Extreme switch :-), but suddenly the shaping stopped working as supposed. For instance, I have a customers shaped to 512 kbps, but instead of that they only get ~250 kbps. Changing the rate of the class does not make much difference. Pushing it up to 2048kbps only changes the clients real bandwidth to ~340 kbps. The kernel is stock 2.4.18, eepro100 driver is patched (one line) to support VLANs and that's the only change from the old machine. Any ideas? Shaping on a "normal" (non-vlan) interface seems to work OK. BTW (offtopic), anyone knows of a more compact changelog for kernel 2.4.19? I don't have time to read all the bk mumbo-jumbo, I only want to know the major differences. 25MB diff scared me a little when it came out :-) regards, - -- Borut Mrak, b@aufbix.org PGP: finger:b@aufbix.org - ------------------------ "Great minds discuss ideas; Average minds discuss events; Small minds discuss people." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1RL3IACgkQRUVvbWYRhIJtGACgn146nxtpyLgCtGMel53sMABs ipMAoLuCGikOJqGsdBW8jyzoFzXpyMXN =4TQa -----END PGP SIGNATURE----- From kaber@trash.net Wed Aug 7 15:42:05 2002 From: kaber@trash.net (Patrick McHardy) Date: Wed, 07 Aug 2002 16:42:05 +0200 Subject: [LARTC] pb with ingress policy References: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) Message-ID: <3D5131BD.8080700@trash.net> Hi. Thomas SPECK wrote: > Hi ! > > I have a single host which is connected via an 512kbit ADSL link to the net. I quite often use some realaudio application that uses some bandwidth and I want to avoid other traffic to scale that bandwidth down. So I used some classes (with htb) on imq0 device and applied some filters and it seems to work in most cases. However, there are some sites with which download is interrupted if bandwidth is limited. I tried to trace it down and did some simple test: > > modprobe imq numdevs=1 > tc qdisc add dev imq0 root handle 1: htb default 10 > tc class add dev imq0 parent 1: classid 1:10 htb rate 60kbit ceil 512kbit burst 15k > tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 > iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0 > ip li set imq0 up > > So now all traffic is limited to 60kbit. If I use some particular site for downloading (with wget) I observe the following with tcpdump: > At the beginning there is a huge burst (wget indicating something like 45 kbps) than speed decreases dramatically and achieves some equilibrium around 60kbit. Then for some reason after about 15 seconds my host sends FIN to the other site. Why ? ;-) Hard to tell without seeing any data. Can you capture the session with tcpdump and put it online somewhere (or send it via email off-list) ? Bye Patrick From stef.coene@docum.org Wed Aug 7 20:09:34 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 7 Aug 2002 21:09:34 +0200 Subject: [LARTC] pb with ingress policy In-Reply-To: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> References: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) Message-ID: <20020807190934.D780FDB9B2@tartarus.telenet-ops.be> On Wednesday 07 August 2002 16:43, Thomas SPECK wrote: > Hi ! > > I have a single host which is connected via an 512kbit ADSL link to the > net. I quite often use some realaudio application that uses some bandwi= dth > and I want to avoid other traffic to scale that bandwidth down. So I us= ed > some classes (with htb) on imq0 device and applied some filters and it > seems to work in most cases. However, there are some sites with which > download is interrupted if bandwidth is limited. I tried to trace it do= wn > and did some simple test: > > modprobe imq numdevs=3D1 > tc qdisc add dev imq0 root handle 1: htb default 10 > tc class add dev imq0 parent 1: classid 1:10 htb rate 60kbit ceil 512kb= it > burst 15k tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 > iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0 > ip li set imq0 up > > So now all traffic is limited to 60kbit.=20 You limit all traffic to 512 kbit with the ceil parameter, not 60 kbit. = The=20 rate is used when you have 2 or more child classes with the same parent. > If I use some particular site for > downloading (with wget) I observe the following with tcpdump: At the > beginning there is a huge burst (wget indicating something like 45 kbps= ) > than speed decreases dramatically and achieves some equilibrium around > 60kbit. Then for some reason after about 15 seconds my host sends FIN t= o > the other site. Why ? ;-) Is that a problem with some queue being too f= ull > after the burst at the beginning ? I tried to play with the burst optio= n > and I also used the pmtu stuff (iptables -A FORWARD -p tcp --tcp-flags > SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) without success. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Aug 7 20:18:02 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 7 Aug 2002 21:18:02 +0200 Subject: [LARTC] Error ! In-Reply-To: <3D50DD42.8040004@inbox.lv> References: <3D50DD42.8040004@inbox.lv> Message-ID: <20020807191802.95F9EDC581@tartarus.telenet-ops.be> On Wednesday 07 August 2002 10:41, Arindam Haldar wrote: > hi all, > i got the following error while compiling lartc with patched > htb3.6_tc.diff.. > In file included from arpd.c:19: > ../include-glibc/db.h:10:20: db_185.h: No such file or directory > make[1]: *** [arpd.o] Error 1 > make[1]: Leaving directory `/usr/local/src/iproute2/misc' > make: *** [all] Error 2 > [root@Lr1 iproute2]# > > kernel version is 2.4.19 & lartc version is > iproute2-2.4.7-now-ss020116-try.tar.gz > > iproute2-2.4.7-now-ss010824.tar.gz didnt gaveany errors though !! > > anyone found similar error ??.. i checked include-glibc directory & > didnt find the file mentioned in error-->db_185.h > > any views/guidance is welcome.. > awaing a reply.. apt-get install libdb2-dev Or find the needed rpm or tgz somewhere on the internet :) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Aug 7 20:19:50 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 7 Aug 2002 21:19:50 +0200 Subject: [LARTC] Ingress polices In-Reply-To: <20020807100022.0b2075ed.caznar@stechcomm.com> References: <20020807100022.0b2075ed.caznar@stechcomm.com> Message-ID: <20020807191951.35AA4DBC46@tartarus.telenet-ops.be> On Wednesday 07 August 2002 15:00, Claudio Aznar wrote: > Hi list, > =09I'm making BW control using filter police rate with ingress qdisc, i= t work > fine but i have few question: > > =091. How to set different priorities for this filter, (I can dom it?), > because if I set different priority, the filters are multiplied.=20 There is only 1 filter, but there is a bug in the output of tc so the fil= ter=20 is printed more the once. > 2. How I > can combine different condition in only one filter, sharing the same BW= of > course. For example: port 80 and port 3128 with the same police rate of= 128 > Kbit. (Again, I can do it?). You can't do it. To do so, you will have to create a IMQ device, redirec= t=20 all incoming traffic to it and use htb or cbq to create a hierarchical se= tup. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stimits@idcomm.com Wed Aug 7 21:01:51 2002 From: stimits@idcomm.com (D. Stimits) Date: Wed, 07 Aug 2002 14:01:51 -0600 Subject: [LARTC] htb in the 2.4 tree, woo woo References: <20020807082027.7f0dd77b.glouis@dynamicro.on.ca> Message-ID: <3D517CAF.1050303@idcomm.com> Greg Louis wrote: > Just discovered the hard way (trying to patch) that Marcelo's got htb in > the 2.4.20-pre1 tree. Way to go! (I'm surprised it hasn't been > announced on this list before -- did I miss something?) > Is this the prepatch version you are talking about: http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.20-pre1.gz ? There are actually several patches, such as the ac series, and rc series. I just want to know I am getting the right one. D. Stimits, stimits AT idcomm.com From thomas.speck@wanadoo.fr Thu Aug 8 13:02:14 2002 From: thomas.speck@wanadoo.fr (Thomas SPECK) Date: Thu, 08 Aug 2002 14:02:14 +0200 (MET DST) Subject: [LARTC] pb with ingress policy References: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) <3D5131BD.8080700@trash.net> Message-ID: <3D49FFB700281E6B@mel-rta9.wanadoo.fr> (added by postmaster@wanadoo.fr) >Messsage du 07/08/2002 16:42 >De : Patrick McHardy >A : Thomas SPECK >Copie =E0 : >Objet : Re: [LARTC] pb with ingress policy > > Hi. > > Thomas SPECK wrote: > > > Hi ! > > > > I have a single host which is connected via an 512kbit ADSL link to t= he net. I quite often use some realaudio application that uses some bandwi= dth and I want to avoid other traffic to scale that bandwidth down. So I u= sed some classes (with htb) on imq0 device and applied some filters and it= seems to work in most cases. However, there are some sites with which dow= nload is interrupted if bandwidth is limited. I tried to trace it down and= did some simple test: > > > > modprobe imq numdevs=3D1 > > tc qdisc add dev imq0 root handle 1: htb default 10 > > tc class add dev imq0 parent 1: classid 1:10 htb rate 60kbit ceil 512= kbit burst 15k > > tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 > > iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0 > > ip li set imq0 up > > > > So now all traffic is limited to 60kbit. If I use some particular sit= e for downloading (with wget) I observe the following with tcpdump: > > At the beginning there is a huge burst (wget indicating something lik= e 45 kbps) than speed decreases dramatically and achieves some equilibrium= around 60kbit. Then for some reason after about 15 seconds my host sends = FIN to the other site. Why =3F ;-) > > > Hard to tell without seeing any data. Can you capture the session with = > tcpdump and put it online somewhere (or send it via email off-list) =3F= Unfortunately the site is down now, so I can't do any tests anymore. I tr= ied to find some other site but without succces :( I could reproduce it with realplayer but I am not sure if it is not realp= layer shutting down and causing the FIN or the FIN causing realplayer to s= hut down ... (BTW I am not sure with wget as well, so could that all be an= application problem =3F) If you would like to see the dump anyway, please let me know. -- Thomas From thomas.speck@wanadoo.fr Thu Aug 8 13:09:27 2002 From: thomas.speck@wanadoo.fr (Thomas SPECK) Date: Thu, 08 Aug 2002 14:09:27 +0200 (MET DST) Subject: [LARTC] pb with ingress policy References: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> (added by postmaster@wanadoo.fr) <20020807190934.D780FDB9B2@tartarus.telenet-ops.be> Message-ID: <3D49FF1400266776@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) >Messsage du 07/08/2002 21:09 >De : Stef Coene >A : Thomas SPECK , >Copie =E0 : >Objet : Re: [LARTC] pb with ingress policy > > On Wednesday 07 August 2002 16:43, Thomas SPECK wrote: > > Hi ! > > > > I have a single host which is connected via an 512kbit ADSL link to t= he > > net. I quite often use some realaudio application that uses some band= width > > and I want to avoid other traffic to scale that bandwidth down. So I = used > > some classes (with htb) on imq0 device and applied some filters and i= t > > seems to work in most cases. However, there are some sites with which= > > download is interrupted if bandwidth is limited. I tried to trace it = down > > and did some simple test: > > > > modprobe imq numdevs=3D1 > > tc qdisc add dev imq0 root handle 1: htb default 10 > > tc class add dev imq0 parent 1: classid 1:10 htb rate 60kbit ceil 512= kbit > > burst 15k tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10= > > iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0 > > ip li set imq0 up > > > > So now all traffic is limited to 60kbit. > You limit all traffic to 512 kbit with the ceil parameter, not 60 kbit.= The > rate is used when you have 2 or more child classes with the same parent= . I would like to believe you but I observe even with one class, that traff= ic is decreasing to something around 60kbit. Is there something I am doing= wrong =3F BTW looking into the howto I wonder if it is a good idea to set ceil for = ingress to the maximum rate I get. -- Thomas From stef.coene@docum.org Thu Aug 8 12:56:48 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 8 Aug 2002 13:56:48 +0200 Subject: [LARTC] pb with ingress policy In-Reply-To: <3D49FF1400266776@mel-rta7.wanadoo.fr> References: <3D49FFDD002281D5@mel-rta10.wanadoo.fr> <20020807190934.D780FDB9B2@tartarus.telenet-ops.be> <3D49FF1400266776@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Message-ID: <20020808163418.39860DC446@tartarus.telenet-ops.be> > > You limit all traffic to 512 kbit with the ceil parameter, not 60 kbi= t.=20 > > The rate is used when you have 2 or more child classes with the same > > parent. > > I would like to believe you but I observe even with one class, that tra= ffic > is decreasing to something around 60kbit. Is there something I am doing > wrong ? BTW looking into the howto I wonder if it is a good idea to set > ceil for ingress to the maximum rate I get. You have to put the ceil to 99% of the link in both directions so the hug= h=20 filters in the modem are not used. But the 512 kbit ceil works. I did s= ome=20 htb tests (http://www.docum.org/stef.coene/qos/tests/htb/index.html) and = the=20 results are very accurate. What if you remove the sfq qdisc and/or take=20 other values for rate/ceil? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Thu Aug 8 21:26:04 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 8 Aug 2002 22:26:04 +0200 Subject: [LARTC] Unable To Telnet In-Reply-To: <200208082005.g78K5R113022@cdm01.deedsmiscentral.net> References: <200208082005.g78K5R113022@cdm01.deedsmiscentral.net> Message-ID: <20020808202605.F0D9FDBFFE@tartarus.telenet-ops.be> On Thursday 08 August 2002 22:05, SoloCDM wrote: > I know about ssh, but I still want to telnet to my server within > our network and I am unable. > > I have /etc/xinetd.d/telnet and /proc/sys/net/ipv4/ip_forward > enabled. I don't have any firewall blocking for inside telneting. > I can ping the server. I have removed or added lines in both > /etc/hosts.allow and /etc/hosts.deny to enable telnet with no > success. > > The following is the message when I try to telnet: > > Trying ... > telnet: Unable to connect to remote host: Connection refused > > What is missing? I don't know. Can you log on to the server and do telnet localhost? Can you take a look at /var/log/* to make sure there are no errors? But this list is more for people who want to shape the telnet session :) = So=20 don't expect much answers on your question. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From arindamhaldar@inbox.lv Fri Aug 9 05:04:39 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Fri, 09 Aug 2002 09:34:39 +0530 Subject: [LARTC] Error ! References: <3D50DD42.8040004@inbox.lv> <20020807191802.95F9EDC581@tartarus.telenet-ops.be> Message-ID: <3D533F57.1000604@inbox.lv> THANX :) .. it works !!.. :) Stef Coene wrote: > On Wednesday 07 August 2002 10:41, Arindam Haldar wrote: > >>hi all, >>i got the following error while compiling lartc with patched >>htb3.6_tc.diff.. >>In file included from arpd.c:19: >>../include-glibc/db.h:10:20: db_185.h: No such file or directory >>make[1]: *** [arpd.o] Error 1 >>make[1]: Leaving directory `/usr/local/src/iproute2/misc' >>make: *** [all] Error 2 >>[root@Lr1 iproute2]# >> >>kernel version is 2.4.19 & lartc version is >>iproute2-2.4.7-now-ss020116-try.tar.gz >> >>iproute2-2.4.7-now-ss010824.tar.gz didnt gaveany errors though !! >> >>anyone found similar error ??.. i checked include-glibc directory & >>didnt find the file mentioned in error-->db_185.h >> >>any views/guidance is welcome.. >>awaing a reply.. > > apt-get install libdb2-dev > Or find the needed rpm or tgz somewhere on the internet :) > > Stef > From gbiondi@tech2.it Fri Aug 9 06:48:39 2002 From: gbiondi@tech2.it (Giorgio Biondi) Date: Fri, 9 Aug 2002 07:48:39 +0200 Subject: [LARTC] Dead Gateway Detection Message-ID: <001b01c23f68$699de7a0$2c01000a@texte.com> This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C23F79.2CB13980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a linux box loaded with RH7.1, 3 ethernet with load balance on 2 = ISP. In theory, if one router stop to work (I have turn off for this try), = the Dead Gateway Detection, would re-instradate alla traffic on other link. This not work...someone = have more experience on this? Giorgio Biondi ------=_NextPart_000_0018_01C23F79.2CB13980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a linux box loaded with RH7.1, 3 = ethernet=20 with load balance on 2 ISP.
In theory, if one router stop to work = (I have turn=20 off for this try), the Dead Gateway Detection,
would re-instradate alla traffic on = other link.=20 This not work...someone have more experience on this?
 
Giorgio Biondi
 
------=_NextPart_000_0018_01C23F79.2CB13980-- From stef.coene@docum.org Fri Aug 9 07:21:33 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 9 Aug 2002 08:21:33 +0200 Subject: [LARTC] Dead Gateway Detection In-Reply-To: <001b01c23f68$699de7a0$2c01000a@texte.com> References: <001b01c23f68$699de7a0$2c01000a@texte.com> Message-ID: <200208090621.IAA30582@TIV-AIX1.seabrex.nl> On Friday 09 August 2002 07:48, Giorgio Biondi wrote: > Hi, > > I have a linux box loaded with RH7.1, 3 ethernet with load balance on 2 > ISP. In theory, if one router stop to work (I have turn off for this tr= y), > the Dead Gateway Detection, would re-instradate alla traffic on other l= ink. > This not work...someone have more experience on this? Have you followed the lartc howto chapter 10? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From deedsmis@aculink.net, lartc@mailman.ds9a.nl Fri Aug 9 07:56:05 2002 From: deedsmis@aculink.net, lartc@mailman.ds9a.nl (SoloCDM) Date: Fri, 09 Aug 2002 00:56:05 -0600 Subject: [LARTC] Re: Unable To Telnet References: <200208082005.g78K5R113022@cdm01.deedsmiscentral.net> <20020808202605.F0D9FDBFFE@tartarus.telenet-ops.be> Message-ID: <3D536784.B7A28E9D@cdm01.deedsmiscentral.net> Stef Coene stated the following: > > On Thursday 08 August 2002 22:05, SoloCDM wrote: > > > I know about ssh, but I still want to telnet to my server within > > our network and I am unable. > > > > I have /etc/xinetd.d/telnet and /proc/sys/net/ipv4/ip_forward > > enabled. I don't have any firewall blocking for inside telneting. > > I can ping the server. I have removed or added lines in both > > /etc/hosts.allow and /etc/hosts.deny to enable telnet with no > > success. > > > > The following is the message when I try to telnet: > > > > Trying ... > > telnet: Unable to connect to remote host: Connection refused > > > > What is missing? > > Can you log on to the server and do telnet localhost? > Can you take a look at /var/log/* to make sure there are no errors? No -- none of the above. No messages are listed in /var/log/*. -- Note: When you reply to this message, please include the mailing list and/or newsgroup address and my email address in To: ********************************************************************* Signed, SoloCDM From lartc@mailman.ds9a.nl, deedsmis@aculink.net Fri Aug 9 08:03:04 2002 From: lartc@mailman.ds9a.nl, deedsmis@aculink.net (SoloCDM) Date: Fri, 09 Aug 2002 01:03:04 -0600 Subject: [LARTC] Re: Unable To Telnet References: <200208082005.g78K5R113022@cdm01.deedsmiscentral.net> <20020808202605.F0D9FDBFFE@tartarus.telenet-ops.be> <3D536784.B7A28E9D@cdm01.deedsmiscentral.net> Message-ID: <3D536928.680BFFAE@cdm01.deedsmiscentral.net> SoloCDM stated the following: > > Stef Coene stated the following: > > > > On Thursday 08 August 2002 22:05, SoloCDM wrote: > > > > > I know about ssh, but I still want to telnet to my server within > > > our network and I am unable. > > > > > > I have /etc/xinetd.d/telnet and /proc/sys/net/ipv4/ip_forward > > > enabled. I don't have any firewall blocking for inside telneting. > > > I can ping the server. I have removed or added lines in both > > > /etc/hosts.allow and /etc/hosts.deny to enable telnet with no > > > success. > > > > > > The following is the message when I try to telnet: > > > > > > Trying ... > > > telnet: Unable to connect to remote host: Connection refused > > > > > > What is missing? > > > > Can you log on to the server and do telnet localhost? > > Can you take a look at /var/log/* to make sure there are no errors? > > No -- none of the above. No messages are listed in /var/log/*. Correction -- I am able to login to the server. -- Note: When you reply to this message, please include the mailing list and/or newsgroup address and my email address in To: ********************************************************************* Signed, SoloCDM From laurens.van.alphen@keenondots.com Fri Aug 9 13:32:14 2002 From: laurens.van.alphen@keenondots.com (Laurens van Alphen) Date: Fri, 9 Aug 2002 14:32:14 +0200 Subject: [LARTC] Dead gateway detection Message-ID: <68B054706B911B4189020B333B10A2DA01B700@filmore.corp.keenondots.com> Hi, I installed the routing patches at http://www.linuxvirtualserver.org/~julian/#routes for Linux 2.4.19 and have a few questions: Q1: In the Nano-HOWTO on your site, it says to include these statements: "ip route append prohibit default table metric 1 proto static" Why? What does it do? If I use these I can't connect to the Internet, without them I can. Q2: I have the following multipath route to the Internet: "default proto static nexthop via GW1 dev eth1 weight 1 nexthop via GW2 dev eth2 weight 1" If I unplug eth2 the second route is never marked as 'dead', why? Only if I 'ifconfig eth2 down' the second route is marked dead. I thought the patches would detect this? Thanks, -- Laurens van Alphen Keen on dots From ja@ssi.bg Fri Aug 9 13:48:19 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 9 Aug 2002 15:48:19 +0300 (EEST) Subject: [LARTC] Re: Dead gateway detection In-Reply-To: <68B054706B911B4189020B333B10A2DA01B700@filmore.corp.keenondots.com> Message-ID: Hello, On Fri, 9 Aug 2002, Laurens van Alphen wrote: > Q1: In the Nano-HOWTO on your site, it says to include these statements: > "ip route append prohibit default table metric 1 proto > static" > Why? What does it do? If I use these I can't connect to the Internet, > without them I can. The reason can be that you have other rule/route settings. The purpose is: traffic using source addresses from failed links should not try to use another alive link (some ISPs do not allow spoofing from our side). Such prohibit rules avoid using less-specific routes from other tables if the previous route is deleted (metric 0). > Q2: I have the following multipath route to the Internet: > "default proto static > nexthop via GW1 dev eth1 weight 1 > nexthop via GW2 dev eth2 weight 1" > If I unplug eth2 the second route is never marked as 'dead', why? > Only if I 'ifconfig eth2 down' the second route is marked dead. I > thought the patches would detect this? Linux detects failed gateways and does not use them but the nexthops remain alive. Dead are only the routes administratively marked as such. This is the current way. > Thanks, > > -- > Laurens van Alphen > Keen on dots Regards -- Julian Anastasov From raptor@unacs.bg Fri Aug 9 20:35:34 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Fri, 9 Aug 2002 22:35:34 +0300 Subject: [LARTC] non-ethernet devices and QoS ? Message-ID: <20020809223534.3a20ae0a.raptor@unacs.bg> hi, I'm just evaluating to use Cyclades PC300 card instead of a Cisco router... and 'cause I have never used such boards so I wanted to know will I be able to do egress shaping on this board ? (It should be connected to the ISP with FrameRelay protocol (V35)) ... and as far as I can understand it will be seen in linux as hdslN device !! (not sure). So will I be able to work with it as a normal ethernet device ?! Sorry for the stupid question, but I have to be sure it will work thanx alot raptor From arindamhaldar@inbox.lv Fri Aug 9 20:51:09 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Sat, 10 Aug 2002 01:21:09 +0530 Subject: [LARTC] htb3 & imq Message-ID: <3D541D2D.9080008@inbox.lv> hi all, am testing htb3 with imq. i have read the mannuals & have the follwoing script for a test bed. $htb qdisc add dev imq0 root handle 2: htb $htb class add dev imq0 parent 2: classid 2:1 htb rate 10mbit $htb class add dev imq0 parent 2:1 classid 2:10 htb rate 64kbit ceil 72kbit $htb class add dev imq0 parent 2:1 classid 2:20 htb rate 64kbit ceil 70kbit ##### -- define for groupA $htb class add dev imq0 parent 2:10 classid 2:1010 htb quantum 40960 rate 36kbit ceil 44kbit $htb class add dev imq0 parent 2:10 classid 2:1011 htb quantum 4096 rate 36kbit ceil 46kbit ##### -- define for groupB $htb class add dev imq0 parent 2:20 classid 2:2020 htb quantum 1096 rate 36kbit ceil 42kbit $htb class add dev imq0 parent 2:20 classid 2:2021 htb quantum 1096 rate 36kbit ceil 46kbit $htb qdisc add dev imq0 parent 2:1010 handle 20 sfq perturb 5 $htb qdisc add dev imq0 parent 2:1011 handle 21 sfq perturb 5 $htb qdisc add dev imq0 parent 2:2020 handle 22 pfifo limit 2 $htb qdisc add dev imq0 parent 2:2021 handle 23 pfifo limit 2 the quantum were added as the default taken reported error to be *TOO* small... am getting this errors in log file... Aug 10 01:05:32 Lr1 kernel: HTB init, kernel part version 3.6 Aug 10 01:05:32 Lr1 kernel: HTB: quantum of class 20010 is small. Consider r2q change.<4>HTB: quantum of class 20020 is small. Consider r2q change.nf_hook: Verdict = QUEUE. Aug 10 01:05:32 Lr1 kernel: nf_hook: Verdict = QUEUE. Aug 10 01:06:03 Lr1 last message repeated 2297 times the mannual says >>> "..Normaly you don't need to specify quantums manualy as HTB chooses precomputed values. It computes classe's quantum (when you add or change it) as its rate divided by r2q global parameter... " why in thiscase the default quabum reported error/taken too small ? can u please elaborate on r2q... how is it calculated, as the mannual says default value 10 ! what does these error signifies?.. thanking in advance A.H From stef.coene@docum.org Fri Aug 9 22:20:42 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 9 Aug 2002 23:20:42 +0200 Subject: [LARTC] htb3 & imq In-Reply-To: <3D541D2D.9080008@inbox.lv> References: <3D541D2D.9080008@inbox.lv> Message-ID: <20020809212043.46CABDC32F@tartarus.telenet-ops.be> > $htb class add dev imq0 parent 2:20 classid 2:2020 htb quantum 1096 rat= e > 36kbit ceil 42kbit > $htb class add dev imq0 parent 2:20 classid 2:2021 htb quantum 1096 rat= e > 36kbit ceil 46kbit > the mannual says >>> "..Normaly you don't need to specify quantums > manualy as HTB chooses precomputed values. It computes classe's quantum > (when you add or change it) as its rate divided by r2q global parameter= =2E.. > " why in thiscase the default quabum reported error/taken too small ? c= an u > please elaborate on r2q... how is it calculated, as the mannual says=20 > default value 10 ! > what does these error signifies?.. Each class can send quantum bytes at a time. You specified quantum =3D 1= 096=20 wich is bigger then the MTU (mostly 1500). If you have a big packet of 1= 500=20 byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. = But=20 the packet is sended anyway and a warning message is logged. Quantum is calculated as rate / r2q. r2q iq by default 10 and can be=20 overruled if you create the heb qdisc. Quantum can be overruled when you= add=20 a class. You should choose r2q so that the class with the smallest rate has a quan= tum=20 equal to MTU. Because quantum is used by each class to send quantum byte= s at=20 a time, you should take quantum proportional to the rate so each class is= =20 getting the bandwidth you want to get it. So leaving quantum untouched, = but=20 changing r2q is a good choice. Taking too big quantums can cause delays. All classes can send it's quan= tum=20 bytes before the first class may send again. So how bigger the quantum, = the=20 longer it takes before a class can send again. I have some more info about it on www.docum.org on the faq page. But not so much as I typed now :) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From wdenobre@techconcepts.co.za Fri Aug 9 23:10:50 2002 From: wdenobre@techconcepts.co.za (Wayne de Nobrega) Date: Sat, 10 Aug 2002 00:10:50 +0200 Subject: [LARTC] Managing Inbound Traffic Message-ID: <70D669BA9BE5CD42B147B00D2D01903806ED8F@tc-pdc.jhbA.techconcepts.co.za> This is a multi-part message in MIME format. ------_=_NextPart_001_01C23FF1.9EF6516A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been playing around with traffic shaping using htb and imq but am battling to get any control over the inbound traffic. Managing the outgoing is working perfectly. To manage the inbound internet traffic which is running on a 64kbit line, I have tried the following including various permutations of priorities, bursts, and ceilings with no affect. (Does the ceil option work becuase when I did have it set higher than the rate, the traffic did not increase even with no other traffic on the line. I noticed the same thing with the burst option. I cannot place the shaper at the ISP in this case. =20 modprobe imq numdevs=3D1 =20 tc qdisc add dev imq0 handle 1: root htb default 1 tc class add dev imq0 parent 1: classid 1:1 htb rate 64kbit =20 tc qdisc add dev imq0 parent 1:1 handle 10: htb default 5 tc class add dev imq0 parent 10: classid 10:1 htb rate 12kbit burst 16kbit prio 3 tc class add dev imq0 parent 10: classid 10:2 htb rate 28kbit burst 16kbit prio 2 tc class add dev imq0 parent 10: classid 10:3 htb rate 16kbit burst 16kbit prio 1 tc class add dev imq0 parent 10: classid 10:5 htb rate 8kbit prio 4 =20 tc qdisc add dev imq0 parent 10:1 handle 21:0 sfq tc qdisc add dev imq0 parent 10:2 handle 22:0 sfq tc qdisc add dev imq0 parent 10:3 handle 23:0 sfq tc qdisc add dev imq0 parent 10:5 handle 24:0 sfq =20 tc filter add dev imq0 protocol ip pref 1 parent 10: handle 1 fw classid 10:1 tc filter add dev imq0 protocol ip pref 2 parent 10: handle 2 fw classid 10:2 tc filter add dev imq0 protocol ip pref 3 parent 10: handle 3 fw classid 10:3 =20 iptables -t mangle -A PREROUTING -i eth0 -j IMQ iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 20 --dport 1024: -m state --state ESTABLISHED -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 80 --dport 1024: -m state --state ESTABLISHED -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 22 --dport 1024: -m state --state ESTABLISHED -j MARK --set-mark 3 =20 ip link set imq0 up What I want to have is that they all have a minimum rate set which can grow to fill the line if it is available. =20 =20 Any help or ideas if this is possible??? =20 Thanks Wayne =20 ------_=_NextPart_001_01C23FF1.9EF6516A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Managing Inbound Traffic

I have been playing around with traffic shaping using = htb and imq but am battling to get any control over the inbound = traffic.  Managing the outgoing is working perfectly.  To = manage the inbound internet traffic which is running on a 64kbit line, I = have tried the following including various permutations of priorities, = bursts, and ceilings with no affect.  (Does the ceil option work = becuase when I did have it set higher than the rate, the traffic did not = increase even with no other traffic on the line. I noticed the same = thing with the burst option.  I cannot place the shaper at the ISP = in this case.

 
modprobe imq numdevs=3D1
 
tc qdisc add dev imq0 handle 1: root htb default = 1
tc class add dev imq0 parent 1: classid 1:1 htb rate = 64kbit
 
tc qdisc add dev imq0 parent 1:1 handle 10: htb = default 5
tc class add dev imq0 parent 10: classid 10:1 htb = rate 12kbit burst 16kbit prio 3
tc class add dev imq0 parent 10: classid 10:2 htb = rate 28kbit burst 16kbit prio 2
tc class add dev imq0 parent 10: classid 10:3 htb = rate 16kbit burst 16kbit prio 1
tc class add dev imq0 parent 10: classid 10:5 htb = rate 8kbit prio 4
 
tc qdisc add dev imq0 parent 10:1 handle 21:0 = sfq
tc qdisc add dev imq0 parent 10:2 handle 22:0 = sfq
tc qdisc add dev imq0 parent 10:3 handle 23:0 = sfq
tc qdisc add dev imq0 parent 10:5 handle 24:0 = sfq
 
tc filter add dev imq0 protocol ip pref 1 parent 10: = handle 1 fw classid 10:1
tc filter add dev imq0 protocol ip pref 2 parent 10: = handle 2 fw classid 10:2
tc filter add dev imq0 protocol ip pref 3 parent 10: = handle 3 fw classid 10:3
 
iptables -t mangle -A PREROUTING -i eth0 -j = IMQ
iptables -t mangle -A PREROUTING -i eth0 -p tcp = --sport 20 --dport 1024: -m state --state ESTABLISHED -j MARK --set-mark = 1

iptables -t mangle -A PREROUTING -i eth0 -p tcp = --sport 80 --dport 1024: -m state --state ESTABLISHED -j MARK --set-mark = 2

iptables -t mangle -A PREROUTING -i eth0 -p tcp = --sport 22 --dport 1024: -m state --state ESTABLISHED -j MARK --set-mark = 3

 
ip link set imq0 up

What I want to have is that they all have a minimum = rate set which can grow to fill the line if it is available.  =
 
Any help or ideas if this is possible???
 
Thanks

Wayne
 

------_=_NextPart_001_01C23FF1.9EF6516A-- From arindamhaldar@inbox.lv Sat Aug 10 05:46:00 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Sat, 10 Aug 2002 10:16:00 +0530 Subject: [LARTC] htb3 & imq References: <3D541D2D.9080008@inbox.lv> <20020809212043.46CABDC32F@tartarus.telenet-ops.be> Message-ID: <3D549A88.8040601@inbox.lv> > Each class can send quantum bytes at a time. You specified quantum = 1096 > wich is bigger then the MTU (mostly 1500). If you have a big packet of 1500 > byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. But > the packet is sended anyway and a warning message is logged. > > Quantum is calculated as rate / r2q. r2q iq by default 10 and can be > overruled if you create the heb qdisc. Quantum can be overruled when you add > a class. Stef thanx to you so much.. whats an "heb qdisc". am sorry but i really dont know anything about it. if u can give a little more detail pls. :) log message generated now is--> Aug 10 04:12:05 Lr1 kernel: nf_hook: Verdict = QUEUE. Aug 10 04:12:36 Lr1 last message repeated 5614 times Aug 10 04:13:37 Lr1 last message repeated 12355 times Aug 10 04:14:38 Lr1 last message repeated 12845 times why this log message appears every minute ??.. is it due to packets are being send to the imq QUEUE ie its queueing ?? thanking in advance A.H From stef.coene@docum.org Sat Aug 10 09:20:23 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 10 Aug 2002 10:20:23 +0200 Subject: [LARTC] htb3 & imq In-Reply-To: <3D549A88.8040601@inbox.lv> References: <3D541D2D.9080008@inbox.lv> <20020809212043.46CABDC32F@tartarus.telenet-ops.be> <3D549A88.8040601@inbox.lv> Message-ID: <20020810082024.ED6C1DBFE5@tartarus.telenet-ops.be> On Saturday 10 August 2002 06:46, Arindam Haldar wrote: > > Each class can send quantum bytes at a time. You specified quantum =3D > > 1096 wich is bigger then the MTU (mostly 1500). If you have a big pa= cket > > of 1500 byte and a quantum of 1096 byte, you are only allowed to send > > 1096 byte. But the packet is sended anyway and a warning message is > > logged. > > > > Quantum is calculated as rate / r2q. r2q iq by default 10 and can be > > overruled if you create the heb qdisc. Quantum can be overruled when= you > > add a class. > > Stef thanx to you so much.. > whats an "heb qdisc". am sorry but i really dont know anything about it= =2E > if u can give a little more detail pls. :) It's a typo :) I meant the disc. > > log message generated now is--> > Aug 10 04:12:05 Lr1 kernel: nf_hook: Verdict =3D QUEUE. > Aug 10 04:12:36 Lr1 last message repeated 5614 times > Aug 10 04:13:37 Lr1 last message repeated 12355 times > Aug 10 04:14:38 Lr1 last message repeated 12845 times > > why this log message appears every minute ??.. is it due to packets are > being send to the imq QUEUE ie its queueing ?? I think so. I'm not sure. Maybe you can search the imq page for a way t= o=20 disabling this message or for an explanation of the message. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Sat Aug 10 10:10:03 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 10 Aug 2002 11:10:03 +0200 Subject: [LARTC] Managing Inbound Traffic In-Reply-To: <70D669BA9BE5CD42B147B00D2D01903806ED8F@tc-pdc.jhbA.techconcepts.co.za> References: <70D669BA9BE5CD42B147B00D2D01903806ED8F@tc-pdc.jhbA.techconcepts.co.za> Message-ID: <20020810091004.9960BDBBB4@tartarus.telenet-ops.be> > tc class add dev imq0 parent 10: classid 10:1 htb rate 12kbit burst > 16kbit prio 3 > tc class add dev imq0 parent 10: classid 10:2 htb rate 28kbit burst > 16kbit prio 2 > tc class add dev imq0 parent 10: classid 10:3 htb rate 16kbit burst > 16kbit prio 1 > tc class add dev imq0 parent 10: classid 10:5 htb rate 8kbit prio 4 > > tc qdisc add dev imq0 parent 10:1 handle 21:0 sfq > tc qdisc add dev imq0 parent 10:2 handle 22:0 sfq > tc qdisc add dev imq0 parent 10:3 handle 23:0 sfq > tc qdisc add dev imq0 parent 10:5 handle 24:0 sfq > > tc filter add dev imq0 protocol ip pref 1 parent 10: handle 1 fw classi= d > 10:1 > tc filter add dev imq0 protocol ip pref 2 parent 10: handle 2 fw classi= d > 10:2 > tc filter add dev imq0 protocol ip pref 3 parent 10: handle 3 fw classi= d > 10:3 > > iptables -t mangle -A PREROUTING -i eth0 -j IMQ > iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 20 --dport 1024= : > -m state --state ESTABLISHED -j MARK --set-mark 1 > iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 80 --dport 1024= : > -m state --state ESTABLISHED -j MARK --set-mark 2 > iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 22 --dport 1024= : > -m state --state ESTABLISHED -j MARK --set-mark 3 > > ip link set imq0 up > > What I want to have is that they all have a minimum rate set which can > grow to fill the line if it is available. > > Any help or ideas if this is possible??? You have to give each class a ceil of 64 kbit. So the classes can borrow= =20 bandwidth from the parent up to 64 kbit. On the other hand, 64kbit is to= o=20 high. You have to make sure you never receive more packets then the mode= m=20 can handle. So ceiling at 62kbit will give better results (at least that= 's=20 what I hope :). Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From arindamhaldar@inbox.lv Sat Aug 10 10:46:29 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Sat, 10 Aug 2002 15:16:29 +0530 Subject: [LARTC] Managing Inbound Traffic Message-ID: <3D54E0F5.101@inbox.lv> hi, i have added just these iptables command to handle in & out traffice thru the same imq0 markOut="$ipt -A FORWARD -t mangle -o eth0 -j MARK -s " markIn="$ipt -A FORWARD -t mangle -o eth1 -j MARK -d " $markOut 192.168.1.20 --set-mark 1 $markIn 192.168.1.20 --set-mark 1 $ipt -A POSTROUTING -t mangle -j IMQ rest of the htb & imq rules are same like you :) A.H From psi@platon.atlantis.sk Sat Aug 10 13:45:29 2002 From: psi@platon.atlantis.sk (M.F. PSIkappa) Date: Sat, 10 Aug 2002 14:45:29 +0200 (CEST) Subject: [LARTC] non-ethernet devices and QoS ? In-Reply-To: <20020809223534.3a20ae0a.raptor@unacs.bg> Message-ID: Hi, if I known there is no problem with QoS on Synchronnous card. The devices are hdlc0, hdlc1... BUT frame-relay use own tools for QoS on provider side, it's known as signaling. You will have problem e.g. with latency because frame-relay have own strategy with prioritization of traffic. For more read www.frforum.com On Fri, 9 Aug 2002 raptor@unacs.bg wrote: > hi, > > I'm just evaluating to use Cyclades PC300 card instead of a Cisco router... > and 'cause I have never used such boards so I wanted to know will I be > able to do egress shaping on this board ? > (It should be connected to the ISP with FrameRelay protocol (V35)) ... > and as far as I can understand it will be seen in linux as hdslN device > !! (not sure). > > So will I be able to work with it as a normal ethernet device ?! > > Sorry for the stupid question, but I have to be sure it will work > > thanx alot > raptor -- `)_|_(' PSIkappa I k psi _at_ atlantis.sk From Alexey Talikov Sat Aug 10 14:37:43 2002 From: Alexey Talikov (Alexey Talikov) Date: Sat, 10 Aug 2002 18:37:43 +0500 Subject: Re[2]: [LARTC] htb3 & imq In-Reply-To: <3D549A88.8040601@inbox.lv> References: <3D541D2D.9080008@inbox.lv> <20020809212043.46CABDC32F@tartarus.telenet-ops.be> <3D549A88.8040601@inbox.lv> Message-ID: <18436171231.20020810183743@texlab.com.uz> Hello Arindam, See imq faq http://luxik.cdi.cz/~patrick/imq/faq.html Saturday, August 10, 2002, 9:46:00 AM, you wrote: >> Each class can send quantum bytes at a time. You specified quantum = 1096 >> wich is bigger then the MTU (mostly 1500). If you have a big packet of 1500 >> byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. But >> the packet is sended anyway and a warning message is logged. >> >> Quantum is calculated as rate / r2q. r2q iq by default 10 and can be >> overruled if you create the heb qdisc. Quantum can be overruled when you add >> a class. AH> Stef thanx to you so much.. AH> whats an "heb qdisc". am sorry but i really dont know anything about it. AH> if u can give a little more detail pls. :) AH> log message generated now is--> AH> Aug 10 04:12:05 Lr1 kernel: nf_hook: Verdict = QUEUE. AH> Aug 10 04:12:36 Lr1 last message repeated 5614 times AH> Aug 10 04:13:37 Lr1 last message repeated 12355 times AH> Aug 10 04:14:38 Lr1 last message repeated 12845 times AH> why this log message appears every minute ??.. is it due to packets are AH> being send to the imq QUEUE ie its queueing ?? AH> thanking in advance AH> A.H AH> _______________________________________________ AH> LARTC mailing list / LARTC@mailman.ds9a.nl AH> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From sdan@terranet.ro Sat Aug 10 18:11:32 2002 From: sdan@terranet.ro (Daniel Sercaianu) Date: Sat, 10 Aug 2002 20:11:32 +0300 (EEST) Subject: [LARTC] NAT & IMQ Message-ID: I have the following problems: I cannot shape the ip xxx.xxx.xxx.xxx when I do SNAT or MASQUERADE with them. Otherwise when I remove these two iptables lines the shaping works perfectly. It is very important for me to shape the xxx.xxx.xxx.xxx ip and not the yyy.yyy.yyy.yyy. When I tried to shape yyy.yyy.yyy.yyy, it worked. What rules should be added to make this possible? My iptables rules are: iptables -A PREROUTING -t mangle -s xxx.xxx.xxx.xxx -j MARK --set-mark 1 iptables -A POSTROUTING -t nat -s xxx.xxx.xxx.xxx -j SNAT --to zzz.zzz.zzz.zzz -o eth4 iptables -t mangle -I PREROUTING -j IMQ ip link set imq0 up ip rule shows the following output: 32764: from zzz.zzz.zzz.0/24 lookup ew 32765: from all fwmark 1 lookup ew 32766: from all lookup main 32767: from all lookup default My tc + htb rule look like this: /sbin/tc qdisc add dev imq0 root handle 1: htb default 200 r2q 3 /sbin/tc class add dev imq0 parent 1:0 classid 1:1 htb rate 100Mbit ceil 100Mbit burst 2k prio 5 /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 256 /sbin/tc class add dev imq0 parent 1:1 classid 1:2 htb rate 512kbit ceil 512kbit burst 2k prio 5 /sbin/tc qdisc add dev imq0 parent 1:2 handle 10: sfq quantum 1514b perturb 10 /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 u32 match ip dst xxx.xxx.xxx.xxx flowid 1:2 /sbin/tc filter add dev imq0 parent 1:0 prio 5 handle ::1 u32 ht 800:: \ match ip nofrag \ offset mask 0x0F00 shift 6 \ hashkey mask 0x00ff0000 at 8 link 1: Daniel Sercaianu Terranet Virtual Media sdan@terranet.ro GSM +40 788 837723 From misiek@pld.ORG.PL Sat Aug 10 23:06:22 2002 From: misiek@pld.ORG.PL (Arkadiusz Miskiewicz) Date: 11 Aug 2002 00:06:22 +0200 Subject: [LARTC] bnig number of interfaces and upstream limit Message-ID: <87u1m29xnl.fsf@arm.t19.ds.pwr.wroc.pl> Hi, The problem is: I have PPPoE (ppp over eth) server and 100 clients. For each client new pppX interface is created. Now I want to limit max speed on each interface to different values. For example ppp0 - downstream 256kbit, upstream 128kbit ppp1 - downstream 512kbit, upstream 512kbit ... Downstream is easy - I just add htb rule on user pppX interface and that's all. 100 rules for 100 clients. Upstream seems be big problem because AFAIK htb (cbq, too) must be attached to outgoing interface which means that in my case for each client there is 99 potential outgoing interfaces. This means that I need to setup 10k rules for only 100 clients (100 rules for each pppX interface) ! I'm not sure but 10k rules (u32 filter) is rather big number for typical PC (or maybe I'm wrong and 10k rules is small thing to process for ie. single duron 800MHz, 256MB RAM?). Any ideas how to do such limiting in better way? --=20 Arkadiusz Mi=B6kiewicz IPv6 ready PLD Linux at http://www.pld.org.pl misiek(at)pld.org.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr From arindamhaldar@inbox.lv Sun Aug 11 08:17:59 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Sun, 11 Aug 2002 12:47:59 +0530 Subject: [LARTC] htb3 & imq References: <3D541D2D.9080008@inbox.lv> <20020809212043.46CABDC32F@tartarus.telenet-ops.be> <3D549A88.8040601@inbox.lv> <18436171231.20020810183743@texlab.com.uz> Message-ID: <3D560FA7.2090902@inbox.lv> hi Alex, thanx so much.. :) .. thanx to all my IMQ & htb3 test rules are working ok.. the best part--> imq handling both in & out traffic now.. :) Alexey Talikov wrote: > Hello Arindam, > See imq faq http://luxik.cdi.cz/~patrick/imq/faq.html > Saturday, August 10, 2002, 9:46:00 AM, you wrote: > From kaber@trash.net Sun Aug 11 14:39:17 2002 From: kaber@trash.net (Patrick McHardy) Date: Sun, 11 Aug 2002 15:39:17 +0200 Subject: [LARTC] NAT & IMQ References: Message-ID: <3D566905.9060406@trash.net> This is a multi-part message in MIME format. --------------020208080004090901020901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, Daniel Sercaianu wrote: > I have the following problems: > I cannot shape the ip xxx.xxx.xxx.xxx when I do SNAT or MASQUERADE with > them. Otherwise when I remove these two iptables lines the shaping works > perfectly. > > It is very important for me to shape the xxx.xxx.xxx.xxx ip and not the > yyy.yyy.yyy.yyy. When I tried to shape yyy.yyy.yyy.yyy, it worked. > > What rules should be added to make this possible? > > > My iptables rules are: > > iptables -A PREROUTING -t mangle -s xxx.xxx.xxx.xxx -j MARK --set-mark 1 > iptables -A POSTROUTING -t nat -s xxx.xxx.xxx.xxx -j SNAT --to zzz.zzz.zzz.zzz -o eth4 > > > > iptables -t mangle -I PREROUTING -j IMQ > ip link set imq0 up > > > ip rule shows the following output: > > 32764: from zzz.zzz.zzz.0/24 lookup ew > 32765: from all fwmark 1 lookup ew > 32766: from all lookup main > 32767: from all lookup default > > > > > My tc + htb rule look like this: > > /sbin/tc qdisc add dev imq0 root handle 1: htb default 200 r2q 3 > /sbin/tc class add dev imq0 parent 1:0 classid 1:1 htb rate 100Mbit ceil 100Mbit burst 2k prio 5 > > /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 256 > > /sbin/tc class add dev imq0 parent 1:1 classid 1:2 htb rate 512kbit ceil 512kbit burst 2k prio 5 > /sbin/tc qdisc add dev imq0 parent 1:2 handle 10: sfq quantum 1514b perturb 10 > /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 u32 match ip dst xxx.xxx.xxx.xxx flowid 1:2 If i understood you right this is probably not working because imq sees packets before zzz.zzz.zzz.zzz is dnated back to xxx.xxx.xxx.xxx. please try the attached patch. bye patrick --------------020208080004090901020901 Content-Type: text/plain; name="imqnat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="imqnat.diff" --- imq.c.orig Sun Aug 11 15:30:24 2002 +++ imq.c Sun Aug 11 15:31:17 2002 @@ -37,7 +37,7 @@ imq_nf_hook, PF_INET, NF_IP_PRE_ROUTING, - NF_IP_PRI_MANGLE + 1 + NF_IP_PRI_NAT_DST + 1 }; static struct nf_hook_ops imq_egress_ipv4 = { @@ -54,7 +54,7 @@ imq_nf_hook, PF_INET6, NF_IP6_PRE_ROUTING, - NF_IP6_PRI_MANGLE + 1 + NF_IP6_PRI_NAT_SRC + 1 }; static struct nf_hook_ops imq_egress_ipv6 = { --------------020208080004090901020901-- From kaber@trash.net Sun Aug 11 14:44:22 2002 From: kaber@trash.net (Patrick McHardy) Date: Sun, 11 Aug 2002 15:44:22 +0200 Subject: [LARTC] NAT & IMQ References: <3D566905.9060406@trash.net> Message-ID: <3D566A36.6050804@trash.net> This is a multi-part message in MIME format. --------------020001010800070707090803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit sorry last patch was broken, this one is ok. patrick Patrick McHardy wrote: > Hi Daniel, > > Daniel Sercaianu wrote: > >> I have the following problems: >> I cannot shape the ip xxx.xxx.xxx.xxx when I do SNAT or MASQUERADE with >> them. Otherwise when I remove these two iptables lines the shaping works >> perfectly. >> >> It is very important for me to shape the xxx.xxx.xxx.xxx ip and not the >> yyy.yyy.yyy.yyy. When I tried to shape yyy.yyy.yyy.yyy, it worked. >> >> What rules should be added to make this possible? >> >> >> My iptables rules are: >> >> iptables -A PREROUTING -t mangle -s xxx.xxx.xxx.xxx -j MARK --set-mark 1 >> iptables -A POSTROUTING -t nat -s xxx.xxx.xxx.xxx -j SNAT --to >> zzz.zzz.zzz.zzz -o eth4 >> >> >> >> iptables -t mangle -I PREROUTING -j IMQ >> ip link set imq0 up >> >> >> ip rule shows the following output: >> >> 32764: from zzz.zzz.zzz.0/24 lookup ew >> 32765: from all fwmark 1 lookup ew >> 32766: from all lookup main >> 32767: from all lookup default >> >> >> >> >> My tc + htb rule look like this: >> >> /sbin/tc qdisc add dev imq0 root handle 1: htb default 200 r2q 3 >> /sbin/tc class add dev imq0 parent 1:0 classid 1:1 htb rate 100Mbit >> ceil 100Mbit burst 2k prio 5 >> >> /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 handle 1: >> u32 divisor 256 >> >> /sbin/tc class add dev imq0 parent 1:1 classid 1:2 htb rate 512kbit >> ceil 512kbit burst 2k prio 5 >> /sbin/tc qdisc add dev imq0 parent 1:2 handle 10: sfq quantum 1514b >> perturb 10 >> /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 u32 match >> ip dst xxx.xxx.xxx.xxx flowid 1:2 > > > > If i understood you right this is probably not working because imq sees > packets before zzz.zzz.zzz.zzz is dnated back to xxx.xxx.xxx.xxx. please > try the attached patch. > > > bye > > patrick > > > ------------------------------------------------------------------------ > > --- imq.c.orig Sun Aug 11 15:30:24 2002 > +++ imq.c Sun Aug 11 15:31:17 2002 > @@ -37,7 +37,7 @@ > imq_nf_hook, > PF_INET, > NF_IP_PRE_ROUTING, > - NF_IP_PRI_MANGLE + 1 > + NF_IP_PRI_NAT_DST + 1 > }; > > static struct nf_hook_ops imq_egress_ipv4 = { > @@ -54,7 +54,7 @@ > imq_nf_hook, > PF_INET6, > NF_IP6_PRE_ROUTING, > - NF_IP6_PRI_MANGLE + 1 > + NF_IP6_PRI_NAT_SRC + 1 > }; > > static struct nf_hook_ops imq_egress_ipv6 = { > --------------020001010800070707090803 Content-Type: text/plain; name="imqnat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="imqnat.diff" --- imq.c.orig Sun Aug 11 15:30:24 2002 +++ imq.c Sun Aug 11 15:31:17 2002 @@ -37,7 +37,7 @@ imq_nf_hook, PF_INET, NF_IP_PRE_ROUTING, - NF_IP_PRI_MANGLE + 1 + NF_IP_PRI_NAT_DST + 1 }; static struct nf_hook_ops imq_egress_ipv4 = { @@ -54,7 +54,7 @@ imq_nf_hook, PF_INET6, NF_IP6_PRE_ROUTING, - NF_IP6_PRI_MANGLE + 1 + NF_IP6_PRI_NAT_DST + 1 }; static struct nf_hook_ops imq_egress_ipv6 = { --------------020001010800070707090803-- From sdan@terranet.ro Sun Aug 11 15:53:03 2002 From: sdan@terranet.ro (Daniel Sercaianu) Date: Sun, 11 Aug 2002 17:53:03 +0300 (EEST) Subject: [LARTC] NAT & IMQ In-Reply-To: <3D566A36.6050804@trash.net> Message-ID: Yes, I think you are wright. I will it try as soon I get the chance, because these are on a working server (router) which cannot be rebooted. Temporarilly I solved the problem by applying the download shapers to the wright eth. Thanx, Daniel Sercaianu Terranet Virtual Media sdan@terranet.ro GSM +40 788 837723 On Sun, 11 Aug 2002, Patrick McHardy wrote: > sorry last patch was broken, this one is ok. > patrick > > Patrick McHardy wrote: > > > Hi Daniel, > > > > Daniel Sercaianu wrote: > > > >> I have the following problems: > >> I cannot shape the ip xxx.xxx.xxx.xxx when I do SNAT or MASQUERADE with > >> them. Otherwise when I remove these two iptables lines the shaping works > >> perfectly. > >> > >> It is very important for me to shape the xxx.xxx.xxx.xxx ip and not the > >> yyy.yyy.yyy.yyy. When I tried to shape yyy.yyy.yyy.yyy, it worked. > >> > >> What rules should be added to make this possible? > >> > >> > >> My iptables rules are: > >> > >> iptables -A PREROUTING -t mangle -s xxx.xxx.xxx.xxx -j MARK --set-mark 1 > >> iptables -A POSTROUTING -t nat -s xxx.xxx.xxx.xxx -j SNAT --to > >> zzz.zzz.zzz.zzz -o eth4 > >> > >> > >> > >> iptables -t mangle -I PREROUTING -j IMQ > >> ip link set imq0 up > >> > >> > >> ip rule shows the following output: > >> > >> 32764: from zzz.zzz.zzz.0/24 lookup ew > >> 32765: from all fwmark 1 lookup ew > >> 32766: from all lookup main > >> 32767: from all lookup default > >> > >> > >> > >> > >> My tc + htb rule look like this: > >> > >> /sbin/tc qdisc add dev imq0 root handle 1: htb default 200 r2q 3 > >> /sbin/tc class add dev imq0 parent 1:0 classid 1:1 htb rate 100Mbit > >> ceil 100Mbit burst 2k prio 5 > >> > >> /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 handle 1: > >> u32 divisor 256 > >> > >> /sbin/tc class add dev imq0 parent 1:1 classid 1:2 htb rate 512kbit > >> ceil 512kbit burst 2k prio 5 > >> /sbin/tc qdisc add dev imq0 parent 1:2 handle 10: sfq quantum 1514b > >> perturb 10 > >> /sbin/tc filter add dev imq0 parent 1:0 protocol ip prio 5 u32 match > >> ip dst xxx.xxx.xxx.xxx flowid 1:2 > > > > > > > > If i understood you right this is probably not working because imq sees > > packets before zzz.zzz.zzz.zzz is dnated back to xxx.xxx.xxx.xxx. please > > try the attached patch. > > > > > > bye > > > > patrick > > > > > > ------------------------------------------------------------------------ > > > > --- imq.c.orig Sun Aug 11 15:30:24 2002 > > +++ imq.c Sun Aug 11 15:31:17 2002 > > @@ -37,7 +37,7 @@ > > imq_nf_hook, > > PF_INET, > > NF_IP_PRE_ROUTING, > > - NF_IP_PRI_MANGLE + 1 > > + NF_IP_PRI_NAT_DST + 1 > > }; > > > > static struct nf_hook_ops imq_egress_ipv4 = { > > @@ -54,7 +54,7 @@ > > imq_nf_hook, > > PF_INET6, > > NF_IP6_PRE_ROUTING, > > - NF_IP6_PRI_MANGLE + 1 > > + NF_IP6_PRI_NAT_SRC + 1 > > }; > > > > static struct nf_hook_ops imq_egress_ipv6 = { > > > > From stef.coene@docum.org Sun Aug 11 19:02:24 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 11 Aug 2002 20:02:24 +0200 Subject: [LARTC] bnig number of interfaces and upstream limit In-Reply-To: <87u1m29xnl.fsf@arm.t19.ds.pwr.wroc.pl> References: <87u1m29xnl.fsf@arm.t19.ds.pwr.wroc.pl> Message-ID: <20020811180224.CDB82DCB17@tartarus.telenet-ops.be> > Downstream is easy - I just add htb rule on user pppX interface > and that's all. 100 rules for 100 clients. > > Upstream seems be big problem because AFAIK htb (cbq, too) must > be attached to outgoing interface which means that in my > case for each client there is 99 potential outgoing interfaces. > > This means that I need to setup 10k rules for only 100 clients > (100 rules for each pppX interface) ! > > I'm not sure but 10k rules (u32 filter) is rather big number > for typical PC (or maybe I'm wrong and 10k rules is small > thing to process for ie. single duron 800MHz, 256MB RAM?). > > Any ideas how to do such limiting in better way? You can use the imq device to catch all incoming traffic. You can create= 10=20 subclasses and put each client data in 1 subclass. Or you can use the=20 ingress qdisc and use the policers in the filters to throttle incoming=20 traffic per interface. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From wing328@yahoo.com Mon Aug 12 09:31:46 2002 From: wing328@yahoo.com (Cheng Kwok Wing, William) Date: Mon, 12 Aug 2002 01:31:46 -0700 (PDT) Subject: [LARTC] Question on hashkey Message-ID: <20020812083146.80686.qmail@web14808.mail.yahoo.com> Hi, I've been working on hashing in tc for a month. Since there are only a limited number of avaialbe example on hashing, I'll be appreciate if someone can my questions as follows: 1. tc filter add dev eth1 protocol ip perent 1:0 \ prio 5 u32 ht 800:: \ match ip src 1.2.0.0/16 \ hashkey mask 0x000000ff at 12 \ link 2: It seems that the hashkey make can only applied to ip header. How can I use the marked number in a packet (using iptables) as the hashkey??? 2.By looking ad "tc filter add fw help", it seems that hashing is not supported in "fw", is it? so how can I speed up the search time if I've 1000 fitler rules using fw??? Thanks, William __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From stef.coene@docum.org Mon Aug 12 12:19:35 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 12 Aug 2002 13:19:35 +0200 Subject: [LARTC] Question on hashkey In-Reply-To: <20020812083146.80686.qmail@web14808.mail.yahoo.com> References: <20020812083146.80686.qmail@web14808.mail.yahoo.com> Message-ID: <200208121119.NAA25416@TIV-AIX1.seabrex.nl> > 1. > tc filter add dev eth1 protocol ip perent 1:0 \ > prio 5 u32 ht 800:: \ > match ip src 1.2.0.0/16 \ > hashkey mask 0x000000ff at 12 \ > link 2: > > It seems that the hashkey make can only applied to ip > header. How can I use the marked number in a packet > (using iptables) as the hashkey??? > > 2.By looking ad "tc filter add fw help", it seems that > hashing is not supported in "fw", is it? so how can I > speed up the search time if I've 1000 fitler rules > using fw??? If you add a fw filter with no options : tc filter add dev eth0 parent 1: protocol ip prio 3 handle 1 fw Then the mark will be used as the classid. So if you marked a packet wit= h 5,=20 the packet will be placed in class1:5. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From lars@segv.dk Mon Aug 12 14:10:23 2002 From: lars@segv.dk (Lars Munch) Date: Mon, 12 Aug 2002 15:10:23 +0200 Subject: [LARTC] Downloadable mail archive missing june 2002 Message-ID: <20020812131022.GB10833@tuxedo.skovlyporten.dk> Hi The downloadable mail archive is missing everything from 10/5 to 30/6: http://mailman.ds9a.nl/pipermail/lartc/2002q2.txt.gz Could someone fix this? Thanks Lars Munch From misiek@pld.ORG.PL Sun Aug 11 11:41:35 2002 From: misiek@pld.ORG.PL (Arkadiusz Miskiewicz) Date: 11 Aug 2002 12:41:35 +0200 Subject: [LARTC] bnig number of interfaces and upstream limit In-Reply-To: <87u1m29xnl.fsf@arm.t19.ds.pwr.wroc.pl> References: <87u1m29xnl.fsf@arm.t19.ds.pwr.wroc.pl> Message-ID: <87eld5pti8.fsf@arm.t19.ds.pwr.wroc.pl> Arkadiusz Miskiewicz writes: > Hi, >=20 > The problem is: I have PPPoE (ppp over eth) server and 100 clients. > For each client new pppX interface is created. >=20 > Now I want to limit max speed on each interface to different > values. For example > ppp0 - downstream 256kbit, upstream 128kbit > ppp1 - downstream 512kbit, upstream 512kbit > ... >=20 > Downstream is easy - I just add htb rule on user pppX interface > and that's all. 100 rules for 100 clients. >=20 > Upstream seems be big problem because AFAIK htb (cbq, too) must > be attached to outgoing interface which means that in my > case for each client there is 99 potential outgoing interfaces. Uhm, it was so easy ;) part of my python script now os.system("tc qdisc del root dev %s 2> /dev/null" % ppp_iface) os.system("tc qdisc del dev %s ingress 2> /dev/null" % ppp_iface) =20=20=20=20 # downstream os.system("tc qdisc add dev %s root tbf rate %skbit latency 50ms burst = 1540" % (ppp_iface, speed_down)) =20=20=20=20 # upstream os.system("tc qdisc add dev %s handle ffff: ingress" % ppp_iface) os.system("tc filter add dev %s parent ffff: protocol ip prio 50 u32 ma= tch ip src 0.0.0.0/0 police rate %skbit burst 10k drop flowid :1" % (ppp_if= ace, speed_up)) --=20 Arkadiusz Mi=B6kiewicz IPv6 ready PLD Linux at http://www.pld.org.pl misiek(at)pld.org.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr From wa@almesberger.net Mon Aug 12 20:27:14 2002 From: wa@almesberger.net (Werner Almesberger) Date: Mon, 12 Aug 2002 16:27:14 -0300 Subject: [LARTC] tcng version 8u Message-ID: <20020812162714.A10318@almesberger.net> ... is on SourceForge, http://tcng.sourceforge.net/#src This is a maintenance release. Highlights: - value << 0 was broken, oops - build process is compatible with the final release of 2.4.19 - make tcsim-rpms is now much better at finding sources. In particular, it will happily accept any source that configure recognizes as compatible, and no longer insist on exactly the recommended (i.e. latest) version And no, HTB support isn't in yet. But I've seen that 2.5.31 has it now. And UML (*). We're getting there ... (*) UML is the future of tcsim, see also http://www.almesberger.net/umlsim/ The full change log is below. - Werner ---------------------------------- cut here ----------------------------------- Version 8u (12-AUG-2002) ------------------------ - updated kernel version example in tcng/README from 2.4.18 to 2.4.19 - configure is now compatible with 2.4.19 (final release) - tcc refused to left-shift 32 bit values by 0 bits (tests/tcng-8u) - configure now checks for defective cpp (reported by "raptor") - added undocumented options --kversions and --iversions to configure - added script build/findsrc to locate source files - "make tcsim-rpms" now uses any supported version of kernel and iproute2, not only the suggested one - added more experimental code for FSM-based classification (not yet useful) - documentation: tcsim figure still called tcsim_filter and tcsim_plot "filter.pl" and "plot.pl" -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From caznar@stechcomm.com Mon Aug 12 20:48:55 2002 From: caznar@stechcomm.com (Claudio Aznar) Date: Mon, 12 Aug 2002 16:48:55 -0300 Subject: [LARTC] Problem with Kernel compilation Message-ID: <20020812164855.23c9f073.caznar@stechcomm.com> Hello list, I'm try to compile the new versión of Kernel (2.4.18) for IMQ support, and I don't find this option: Networking options ---> IP: Netfilter Configuration --->IMQ target support Networking options ---> IPv6: Netfilter Configuration --->IMQ target support Any idea? Thank in advance Claudio Aznar STech SA From thomas.speck@wanadoo.fr Mon Aug 12 21:57:56 2002 From: thomas.speck@wanadoo.fr (Thomas SPECK) Date: Mon, 12 Aug 2002 22:57:56 +0200 (MET DST) Subject: [LARTC] Managing Inbound Traffic References: <70D669BA9BE5CD42B147B00D2D01903806ED8F@tc-pdc.jhbA.techconcepts.co.za> Message-ID: <3D49FFB7004008C4@mel-rta9.wanadoo.fr> (added by postmaster@wanadoo.fr) >Messsage du 10/08/2002 00:10 >De : Wayne de Nobrega >A : >Copie =E0 : >Objet : [LARTC] Managing Inbound Traffic > > I have been playing around with traffic shaping using htb and imq but a= m > battling to get any control over the inbound traffic. Managing the > outgoing is working perfectly. To manage the inbound internet traffic > which is running on a 64kbit line, I have tried the following including= > various permutations of priorities, bursts, and ceilings with no affect= . > (Does the ceil option work becuase when I did have it set higher than > the rate, the traffic did not increase even with no other traffic on th= e > line. I noticed the same thing with the burst option. I cannot place > the shaper at the ISP in this case. > > modprobe imq numdevs=3D1 > > tc qdisc add dev imq0 handle 1: root htb default 1 > tc class add dev imq0 parent 1: classid 1:1 htb rate 64kbit > > tc qdisc add dev imq0 parent 1:1 handle 10: htb default 5 > tc class add dev imq0 parent 10: classid 10:1 htb rate 12kbit burst > 16kbit prio 3 > tc class add dev imq0 parent 10: classid 10:2 htb rate 28kbit burst > 16kbit prio 2 > tc class add dev imq0 parent 10: classid 10:3 htb rate 16kbit burst > 16kbit prio 1 > tc class add dev imq0 parent 10: classid 10:5 htb rate 8kbit prio 4 > > tc qdisc add dev imq0 parent 10:1 handle 21:0 sfq > tc qdisc add dev imq0 parent 10:2 handle 22:0 sfq > tc qdisc add dev imq0 parent 10:3 handle 23:0 sfq > tc qdisc add dev imq0 parent 10:5 handle 24:0 sfq > > tc filter add dev imq0 protocol ip pref 1 parent 10: handle 1 fw classi= d > 10:1 > tc filter add dev imq0 protocol ip pref 2 parent 10: handle 2 fw classi= d > 10:2 > tc filter add dev imq0 protocol ip pref 3 parent 10: handle 3 fw classi= d > 10:3 > > iptables -t mangle -A PREROUTING -i eth0 -j IMQ > iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 20 --dport 1024= : > -m state --state ESTABLISHED -j MARK --set-mark 1 > iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 80 --dport 1024= : > -m state --state ESTABLISHED -j MARK --set-mark 2 > iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 22 --dport 1024= : > -m state --state ESTABLISHED -j MARK --set-mark 3 I wonder if this is true. Shouldn't one rather use iptables -t mangle -A = PREROUTING -i eth0 -j IMQ at the end (after the other rules) =3F Otherwise= everyting from eth0 will go right to target IMQ and the other rules are n= ever executed, i.e. the desired packets are never marked and all the filte= rs are never true ... -- Thomas From stef.coene@docum.org Mon Aug 12 20:59:17 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 12 Aug 2002 21:59:17 +0200 Subject: [LARTC] Problem with Kernel compilation In-Reply-To: <20020812164855.23c9f073.caznar@stechcomm.com> References: <20020812164855.23c9f073.caznar@stechcomm.com> Message-ID: <20020812195918.0609BDBF35@tartarus.telenet-ops.be> On Monday 12 August 2002 21:48, Claudio Aznar wrote: > Hello list, > =09I'm try to compile the new versi=F3n of Kernel (2.4.18) for IMQ supp= ort, and > I don't find this option:=20 > Networking options ---> IP: Netfilter Configuration --->IMQ target su= pport > Networking options ---> IPv6: Netfilter Configuration --->IMQ target=20 support Make sure you patched the kernel. You can find the IMQ device under Netw= ork=20 device support. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Mon Aug 12 21:04:16 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 12 Aug 2002 22:04:16 +0200 Subject: [LARTC] Managing Inbound Traffic In-Reply-To: <3D49FFB7004008C4@mel-rta9.wanadoo.fr> References: <70D669BA9BE5CD42B147B00D2D01903806ED8F@tc-pdc.jhbA.techconcepts.co.za> <3D49FFB7004008C4@mel-rta9.wanadoo.fr> (added by postmaster@wanadoo.fr) Message-ID: <20020812200417.5F7CBDC0D2@tartarus.telenet-ops.be> > I wonder if this is true. Shouldn't one rather use iptables -t mangle -= A > PREROUTING -i eth0 -j IMQ at the end (after the other rules) ? Otherwis= e > everyting from eth0 will go right to target IMQ and the other rules are > never executed, i.e. the desired packets are never marked and all the > filters are never true ... The script is ok. The iptables command registers netfilter hooks. The order you enter the=20 commands is not important. For ingress, the imq rules are processed just after the mangle rules. So= you=20 can use the iptable mark when filtering on the imq device. For egress, t= he=20 imq rules are matched after all iptables rules. The packet is only queued in the imq device if it passes all previous rul= es. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From caznar@stechcomm.com Mon Aug 12 21:19:49 2002 From: caznar@stechcomm.com (Claudio Aznar) Date: Mon, 12 Aug 2002 17:19:49 -0300 Subject: [LARTC] Problem with Kernel compilation In-Reply-To: <20020812195918.0609BDBF35@tartarus.telenet-ops.be> References: <20020812164855.23c9f073.caznar@stechcomm.com> <20020812195918.0609BDBF35@tartarus.telenet-ops.be> Message-ID: <20020812171949.0a4a663b.caznar@stechcomm.com> I have in the kernel configuration the option Network device support --->IMQ (intermediate queueing device) support But not the other options... To activate this option is sufficient ? CA On Mon, 12 Aug 2002 21:59:17 +0200 Stef Coene wrote: > On Monday 12 August 2002 21:48, Claudio Aznar wrote: > > Hello list, > > I'm try to compile the new versión of Kernel (2.4.18) for IMQ support, and > > I don't find this option: > > Networking options ---> IP: Netfilter Configuration --->IMQ target support > > Networking options ---> IPv6: Netfilter Configuration --->IMQ target > support > > Make sure you patched the kernel. You can find the IMQ device under Network > device support. > > Stef > > -- > > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > From stef.coene@docum.org Mon Aug 12 21:49:49 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 12 Aug 2002 22:49:49 +0200 Subject: [LARTC] Problem with Kernel compilation In-Reply-To: <20020812171949.0a4a663b.caznar@stechcomm.com> References: <20020812164855.23c9f073.caznar@stechcomm.com> <20020812195918.0609BDBF35@tartarus.telenet-ops.be> <20020812171949.0a4a663b.caznar@stechcomm.com> Message-ID: <20020812204950.A9A6ADBD78@tartarus.telenet-ops.be> On Monday 12 August 2002 22:19, Claudio Aznar wrote: > I have in the kernel configuration the option > =09Network device support --->IMQ (intermediate queueing device) suppo= rt > But not the other options... To activate this option is sufficient ? If you only want to enable the imq device, that's the only option there i= s. =20 Of course there are other options under Networking option ---> QoS and/o= r=20 fair queueing ---> Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From pulsar@bofh.homeunix.org Mon Aug 12 22:40:53 2002 From: pulsar@bofh.homeunix.org (Alexey Sheshka) Date: Tue, 13 Aug 2002 00:40:53 +0300 Subject: [LARTC] HTTP traffic limiting Message-ID: <20020813004053.30387988.pulsar@bofh.homeunix.org> Hello! Sorry for ugly english. I was sĠtup rules to limit outgoing HTTP traffic : $TC qdisc add dev $DEVA root handle 1: htb default 30 $TC class add dev $DEVA parent 1: classid 1:1 htb rate 100mbit ceil 100mbit burst 15k #HTTP 49Mbit $TC class add dev $DEVA parent 1:1 classid 1:10 htb rate 49mbit ceil 100mbit burst 15k #Other 51Mbit $TC class add dev $DEVA parent 1:1 classid 1:30 htb rate 51mbit ceil 100mbit burst 15k $TC class add dev $DEVA parent 1:10 classid 1:199 htb rate 49Mbit ceil 49mbit burst 15k $TC qdisc add dev $DEVA parent 1:199 sfq perturb 10 /sbin/iptables -A OUTPUT -t mangle -s x.x.x.x --sport 80 -j MARK --set-mark 199 But it doesn't work ! Users download files via HTTP at full 100Mb, but if replase last line with /sbin/iptables -A OUTPUT -t mangle -s x.x.x.x -j MARK --set-mark 199 they got 51Mbit. From tobias.geiger@web.de Tue Aug 13 00:07:33 2002 From: tobias.geiger@web.de (Tobias Geiger) Date: Tue, 13 Aug 2002 01:07:33 +0200 Subject: [LARTC] htb3 & imq References: <3D541D2D.9080008@inbox.lv> <20020809212043.46CABDC32F@tartarus.telenet-ops.be> <3D549A88.8040601@inbox.lv> <18436171231.20020810183743@texlab.com.uz> <3D560FA7.2090902@inbox.lv> Message-ID: <3D583FB5.7020009@web.de> Arindam Haldar wrote: > hi Alex, > thanx so much.. :) .. thanx to all > my IMQ & htb3 test rules are working ok.. the best part--> imq handling > both in & out traffic now.. :) I also had this setup, and i also thought of it as a "cool thing" :) but then Patrick told me, that it's not so clever: the incoming traffic must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not good because 1) cpu - overhead (but this could be negleted) AND 2) these 2 qdiscs COULD drop packets and no one would know of the other having dropped s.th. -> retransmit ok. case 2 is not so realistic, as the qdisc on the interface normaly is the qfifo but nevertheless point 1) and the possibility of 2) made me think that queing double unnecessary. > > Alexey Talikov wrote: > >> Hello Arindam, >> See imq faq http://luxik.cdi.cz/~patrick/imq/faq.html >> Saturday, August 10, 2002, 9:46:00 AM, you wrote: >> > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From wing328@yahoo.com Tue Aug 13 03:27:45 2002 From: wing328@yahoo.com (Cheng Kwok Wing, William) Date: Mon, 12 Aug 2002 19:27:45 -0700 (PDT) Subject: [LARTC] Question on hashkey In-Reply-To: <200208121119.NAA25416@TIV-AIX1.seabrex.nl> Message-ID: <20020813022745.9883.qmail@web14804.mail.yahoo.com> Hi, Thanks for your reply. Does it mean that "fw" has implemented hashing implicitly?? Suppose I've the following fitler rules: tc filter add dev eth0 parent 1: protocol ip prio 3 handle 1 fw tc filter add dev eth0 parent 1: protocol ip prio 3 handle 2 fw tc filter add dev eth0 parent 1: protocol ip prio 3 handle 3 fw tc filter add dev eth0 parent 1: protocol ip prio 3 handle 4 fw ........ and more How does the hashing work here?? What is the hash key? Thanks, William --- Stef Coene wrote: > > 1. > > tc filter add dev eth1 protocol ip perent 1:0 \ > > prio 5 u32 ht 800:: \ > > match ip src 1.2.0.0/16 \ > > hashkey mask 0x000000ff at 12 \ > > link 2: > > > > It seems that the hashkey make can only applied to > ip > > header. How can I use the marked number in a > packet > > (using iptables) as the hashkey??? > > > > 2.By looking ad "tc filter add fw help", it seems > that > > hashing is not supported in "fw", is it? so how > can I > > speed up the search time if I've 1000 fitler rules > > using fw??? > If you add a fw filter with no options : > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 1 fw > Then the mark will be used as the classid. So if > you marked a packet with 5, > the packet will be placed in class1:5. > > Stef > > -- > > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From admin@banpol.com.pl Tue Aug 13 07:18:35 2002 From: admin@banpol.com.pl (Jaroslaw Szpinak) Date: Tue, 13 Aug 2002 08:18:35 +0200 Subject: [LARTC] unsubscribe Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C242A2.054B6EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PLEASE DO NOT SEND ME ANY NEW E-MAIL with (LARTC) in the subject body. Regards! Admin@banpol.com.pl ------=_NextPart_000_000B_01C242A2.054B6EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
PLEASE DO NOT SEND ME ANY NEW E-MAIL with (LARTC) in the = subject=20 body.
 
Regards!
 
Admin@banpol.com.pl
------=_NextPart_000_000B_01C242A2.054B6EC0-- From stef.coene@docum.org Tue Aug 13 08:54:18 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Aug 2002 09:54:18 +0200 Subject: [LARTC] htb3 & imq In-Reply-To: <3D583FB5.7020009@web.de> References: <3D541D2D.9080008@inbox.lv> <3D560FA7.2090902@inbox.lv> <3D583FB5.7020009@web.de> Message-ID: <20020813075329.6281645A9@outpost.ds9a.nl> On Tuesday 13 August 2002 01:07, Tobias Geiger wrote: > Arindam Haldar wrote: > > hi Alex, > > thanx so much.. :) .. thanx to all > > my IMQ & htb3 test rules are working ok.. the best part--> imq handl= ing > > both in & out traffic now.. :) > > I also had this setup, and i also thought of it as a "cool thing" :) > but then Patrick told me, that it's not so clever: the incoming traffic > must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not > good because > 1) cpu - overhead (but this could be negleted) AND > 2) these 2 qdiscs COULD drop packets and no one would know of the other > having dropped s.th. -> retransmit > ok. case 2 is not so realistic, as the qdisc on the interface normaly > is the qfifo but nevertheless point 1) and the possibility of 2) made m= e > think that queing double unnecessary. Basic incoming shaping can be done with the ingress qdisc and the policer= s. =20 This is not a real qdisc with a queue, but it can throttle down incoming=20 packets without creating extra delays. It just droppes incoming packets=20 untill the wanted rate is reached. =20 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Aug 13 08:54:24 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Aug 2002 09:54:24 +0200 Subject: [LARTC] Question on hashkey In-Reply-To: <20020813022745.9883.qmail@web14804.mail.yahoo.com> References: <20020813022745.9883.qmail@web14804.mail.yahoo.com> Message-ID: <20020813075334.078C045A9@outpost.ds9a.nl> On Tuesday 13 August 2002 04:27, Cheng Kwok Wing, William wrote: > Hi, > > Thanks for your reply. > > Does it mean that "fw" has implemented hashing > implicitly?? > > Suppose I've the following fitler rules: > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 1 fw > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 2 fw > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 3 fw > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 4 fw > ........ and more > How does the hashing work here?? What is the hash key? There is no real hash key. If you add the filter : tc filter add dev eth0 parent 1: protocol ip prio 3 fw then the mark is used as the classid. So packets marked with 3 will end = in=20 class 1:3, etc. So you only need 1 fulter. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From arindamhaldar@inbox.lv Tue Aug 13 12:48:49 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Tue, 13 Aug 2002 17:18:49 +0530 Subject: [LARTC] htb3 & imq References: <3D541D2D.9080008@inbox.lv> <3D560FA7.2090902@inbox.lv> <3D583FB5.7020009@web.de> Message-ID: <3D58F221.1090908@inbox.lv> Stef Coene wrote: > On Tuesday 13 August 2002 01:07, Tobias Geiger wrote: > >>Arindam Haldar wrote: >> >>>hi Alex, >>>thanx so much.. :) .. thanx to all >>>my IMQ & htb3 test rules are working ok.. the best part--> imq handling >>>both in & out traffic now.. :) >> >>I also had this setup, and i also thought of it as a "cool thing" :) >>but then Patrick told me, that it's not so clever: the incoming traffic >>must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not >>good because >>1) cpu - overhead (but this could be negleted) AND >>2) these 2 qdiscs COULD drop packets and no one would know of the other >>having dropped s.th. -> retransmit >>ok. case 2 is not so realistic, as the qdisc on the interface normaly >>is the qfifo but nevertheless point 1) and the possibility of 2) made me >>think that queing double unnecessary. > > Basic incoming shaping can be done with the ingress qdisc and the policers. > This is not a real qdisc with a queue, but it can throttle down incoming > packets without creating extra delays. It just droppes incoming packets > untill the wanted rate is reached. > > Stefi have acheived restrictinng both in&out trafic using imq0.. i have marked the packets on different ineterface, hence sending them to the rules i want & then used **FORWARD** to imq .!.. it works pretty good, though done in a test bed of 4 ip.. i want to scale it to our running linux box handling about 250 ip's with 1.5mbps link.. the question now i have start thinking, after Tobias Geiger'smail is --> what will be the cpu overhead when the linix box also runs squid in it.. withh htb3 & imq show the same result as shown in the test ? i hope & feel it will .. :) A.H From g38@rdsbv.ro Tue Aug 13 16:41:50 2002 From: g38@rdsbv.ro (Petre Bandac) Date: Tue, 13 Aug 2002 18:41:50 +0300 Subject: [LARTC] double rule Message-ID: <200208131541.g7DFff111091@g38.rdsbv.ro> I want to shape the traffic on the http port and further on shape it if the destination ip is on some network I specify however, only the first rule is applied ... why ? #http $filtru prio 1 u32 match ip sport 80 0xffff flowid 1:11 #droop :-) $filtru prio 1 u32 match ip src x.x.x.x \ match ip dst x.x.x.0/24 flowid 1:13 where classes are defined earlier as $tc class add dev eth0 parent 1:1 classid 1:10 \ htb rate 32kbit ceil 32kbit $tc class add dev eth0 parent 1:1 classid 1:11 \ htb rate 64kbit ceil 64kbit $tc class add dev eth0 parent 1:1 classid 1:12 \ htb rate 128kbit ceil 160kbit $tc class add dev eth0 parent 1:1 classid 1:13 \ htb rate 100kbit ceil 100kbit and filtru="$tc filter add dev eth0 protocol ip \ parent 1:0" thanks in advance, petre -- 6:39pm up 6:21, 1 user, load average: 0.06, 0.10, 0.06 From stef.coene@docum.org Tue Aug 13 17:56:56 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Aug 2002 18:56:56 +0200 Subject: [LARTC] double rule In-Reply-To: <200208131541.g7DFff111091@g38.rdsbv.ro> References: <200208131541.g7DFff111091@g38.rdsbv.ro> Message-ID: <20020813165657.A6219DC9A5@tartarus.telenet-ops.be> On Tuesday 13 August 2002 17:41, Petre Bandac wrote: > I want to shape the traffic on the http port and further on shape it if= the > destination ip is on some network I specify > > however, only the first rule is applied ... why ? Because you add both rules to the same parent. When one rule is matched,= the=20 packet is put in the destination class and the other rule is never matche= d. =20 Atach the second rule to class 1:11 with option "parent 1:11" and it shou= ld=20 work. Stef > #http > $filtru prio 1 u32 match ip sport 80 0xffff flowid 1:11 > #droop :-) > $filtru prio 1 u32 match ip src x.x.x.x \ > match ip dst x.x.x.0/24 flowid 1:13 > > where classes are defined earlier as > > $tc class add dev eth0 parent 1:1 classid 1:10 \ > htb rate 32kbit ceil 32kbit > > $tc class add dev eth0 parent 1:1 classid 1:11 \ > htb rate 64kbit ceil 64kbit > > $tc class add dev eth0 parent 1:1 classid 1:12 \ > htb rate 128kbit ceil 160kbit > > $tc class add dev eth0 parent 1:1 classid 1:13 \ > htb rate 100kbit ceil 100kbit > > and > > filtru=3D"$tc filter add dev eth0 protocol ip \ > parent 1:0" > > > thanks in advance, > > petre --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Aug 13 18:44:51 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Aug 2002 19:44:51 +0200 Subject: [LARTC] htb3 & imq In-Reply-To: <3D58F221.1090908@inbox.lv> References: <3D541D2D.9080008@inbox.lv> <3D583FB5.7020009@web.de> <3D58F221.1090908@inbox.lv> Message-ID: <20020813174451.C18E9DBA81@tartarus.telenet-ops.be> > i have acheived restrictinng both in&out trafic using imq0.. i have > marked the packets on different ineterface, hence sending them to the > rules i want & then used **FORWARD** to imq .!.. it works pretty good, > though done in a test bed of 4 ip.. i want to scale it to our running > linux box handling about 250 ip's with 1.5mbps link.. > the question now i have start thinking, after Tobias Geiger'smail is --= > > what will be the cpu overhead when the linix box also runs squid in it.= =2E > withh htb3 & imq show the same result as shown in the test ? > i hope & feel it will .. :) I think the CPU is not so important. I think there are other problems wi= th=20 shaping incoming bandwidth with imq. First of all, you can create an ext= ra=20 queue and so extra delays. But using a "shared" structure to manage inco= ming=20 problems can also be a problem. Imagine a setup where 100 kbps is split = in 2=20 parts of 50 and they can borrow from each other. One class is empty and = one=20 class is filled. When there is suddenly a burst in the empty class of 50= =20 kbps, it will take some time before the traffic in the full class will=20 throttle down to 50kbps. And don't forget the extra delay introduced by = the=20 imq device, so the response will even be slower. It's better to be sure = the=20 50kbps is available for the bursty traffic. Of cours, you waste some=20 bandwidth, but a few kbps is enough to make telnet more responsive. So you can do some shaping on incoming traffic, but bursty traffic is not= so=20 easy to mange. To be honest, I just start reading and thinking about shaping incoming=20 traffic, so any suggestions are welcome. Stef =20 --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From valen@ihanaa.org Tue Aug 13 20:58:33 2002 From: valen@ihanaa.org (=?ISO-8859-1?Q?Jussi_M=E4ki?=) Date: Tue, 13 Aug 2002 22:58:33 +0300 (EEST) Subject: [LARTC] really weird problem with 2.2.20 kernel Message-ID: I'm trying to limit the available bandwidth for an single ip address, i've got 3 different scripts which all work with kernel 2.2.17 and all the 2.4.x kernel's i've tested.. The problem is that when for example i limit the traffic to 512kbit/s i'm only getting about 300kbit/s and this is only with 2.2.20 kernel.. I've tried htb and cbq with different schudulers like sfq and pfifo and all of them have the exact same problem. I'm not very keen on upgrading to kernel 2.4.x as i have to upgrade quite a few machine's at once and none of them have compilation tools. Any ideas? From stef.coene@docum.org Tue Aug 13 21:12:37 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Aug 2002 22:12:37 +0200 Subject: [LARTC] really weird problem with 2.2.20 kernel In-Reply-To: References: Message-ID: <20020813201238.D5E5FDCA64@tartarus.telenet-ops.be> On Tuesday 13 August 2002 21:58, Jussi M=E4ki wrote: > I'm trying to limit the available bandwidth for an single ip address, i= 've > got 3 different scripts which all work with kernel 2.2.17 and all the > 2.4.x kernel's i've tested.. > > The problem is that when for example i limit the traffic to 512kbit/s i= 'm > only getting about 300kbit/s and this is only with 2.2.20 kernel.. > > I've tried htb and cbq with different schudulers like sfq and pfifo and > all of them have the exact same problem. > > I'm not very keen on upgrading to kernel 2.4.x as i have to upgrade qui= te > a few machine's at once and none of them have compilation tools. > > Any ideas? What if you have no qos enabled? Maybe it's a driver or hardware problem. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From valen@ihanaa.org Wed Aug 14 06:32:35 2002 From: valen@ihanaa.org (=?ISO-8859-1?Q?Jussi_M=E4ki?=) Date: Wed, 14 Aug 2002 08:32:35 +0300 (EEST) Subject: [LARTC] really weird problem with 2.2.20 kernel In-Reply-To: <20020813201238.D5E5FDCA64@tartarus.telenet-ops.be> Message-ID: > On Tuesday 13 August 2002 21:58, Jussi M=E4ki wrote: > > I'm trying to limit the available bandwidth for an single ip address, i= 've > > got 3 different scripts which all work with kernel 2.2.17 and all the > > 2.4.x kernel's i've tested.. > > > > The problem is that when for example i limit the traffic to 512kbit/s i= 'm > > only getting about 300kbit/s and this is only with 2.2.20 kernel.. > > > > I've tried htb and cbq with different schudulers like sfq and pfifo and > > all of them have the exact same problem. > > > > I'm not very keen on upgrading to kernel 2.4.x as i have to upgrade qui= te > > a few machine's at once and none of them have compilation tools. > > > > Any ideas? > What if you have no qos enabled? Maybe it's a driver or hardware problem. Then it isnt limited in any way. And i've tried with different hardware, with different ethernet cards. From sdan@terranet.ro Wed Aug 14 11:56:29 2002 From: sdan@terranet.ro (Daniel Sercaianu) Date: Wed, 14 Aug 2002 13:56:29 +0300 (EEST) Subject: [LARTC] HTB3 big problem Message-ID: With the following setup I can get maxim of 4Mbit bandwidth when downloading to ip dst 10.0.0.1. When I remove the shapers it works at full 100Mbit. What could be the problem? tc -s -d class ls dev eth0 class htb 1:1 root rate 100Mbit ceil 100Mbit burst 2031b/8 mpu 0b cburst 132644b/8 mpu 0b level 7 Sent 30473118 bytes 20564 pkts (dropped 0, overlimits 0) rate 394194bps 261pps lended: 0 borrowed: 0 giants: 0 tokens: -155 ctokens: 8009 class htb 1:2 parent 1:1 leaf 10: prio 5 quantum 200000 rate 50Mbit ceil 50Mbit burst 2Kb/8 mpu 0b cburst 67121b/8 mpu 0b level 0 Sent 30524594 bytes 20598 pkts (dropped 0, overlimits 0) rate 395529bps 262pps backlog 34p lended: 20564 borrowed: 0 giants: 0 tokens: -309 ctokens: 7827 class htb 1:3 parent 1:1 leaf 20: prio 5 quantum 1638 rate 128Kbit ceil 128Kbit burst 2Kb/8 mpu 0b cburst 1762b/8 mpu 0b level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 102400 ctokens: 88149 To kernel-2.4.18 I applied the following patches: htb3.6_2.4.17.diff imq-2.4.18.diff-10 iptables-1.2.6a-imq /sbin/tc qdisc del dev eth0 root /sbin/tc qdisc add dev eth0 root handle 1: htb default 200 /sbin/tc class add dev eth0 parent 1:0 classid 1:1 htb\ rate 100Mbit ceil 100Mbit burst 2k prio 5 /sbin/tc filter add dev eth0 parent 1:0 protocol ip\ prio 5 handle 1: u32 divisor 256 /sbin/tc class add dev eth0 parent 1:1 classid 1:2 htb\ rate 50Mbit ceil 50Mbit burst 2k prio 5 /sbin/tc qdisc add dev eth0 parent 1:2 handle 10: sfq quantum 1514 perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 5 u32 \ match ip dst 10.0.0.1 flowid 1:2 /sbin/tc filter add dev eth0 parent 1:0 prio 5\ handle ::1 u32 ht 800:: match ip nofrag\ offset mask 0x0F00 shift 6\ hashkey mask 0x00ff0000 at 8 link 1: Daniel Sercaianu Terranet Virtual Media sdan@terranet.ro GSM +40 788 837723 From Alexey Talikov Wed Aug 14 13:41:38 2002 From: Alexey Talikov (Alexey Talikov) Date: Wed, 14 Aug 2002 17:41:38 +0500 Subject: [LARTC] HTB3 big problem In-Reply-To: References: Message-ID: <1114348733.20020814174138@texlab.com.uz> Hello Daniel, Increase burst value or simple don't set it, htb calculate it for you. Wednesday, August 14, 2002, 3:56:29 PM, you wrote: DS> With the following setup I can get maxim of 4Mbit bandwidth when DS> downloading to ip dst 10.0.0.1. When I remove the shapers it works at DS> full 100Mbit. DS> What could be the problem? DS> tc -s -d class ls dev eth0 DS> class htb 1:1 root rate 100Mbit ceil 100Mbit burst 2031b/8 mpu 0b cburst DS> 132644b/8 mpu 0b level 7 DS> Sent 30473118 bytes 20564 pkts (dropped 0, overlimits 0) DS> rate 394194bps 261pps DS> lended: 0 borrowed: 0 giants: 0 DS> tokens: -155 ctokens: 8009 DS> class htb 1:2 parent 1:1 leaf 10: prio 5 quantum 200000 rate 50Mbit ceil DS> 50Mbit burst 2Kb/8 mpu 0b cburst 67121b/8 mpu 0b level 0 DS> Sent 30524594 bytes 20598 pkts (dropped 0, overlimits 0) DS> rate 395529bps 262pps backlog 34p DS> lended: 20564 borrowed: 0 giants: 0 DS> tokens: -309 ctokens: 7827 DS> class htb 1:3 parent 1:1 leaf 20: prio 5 quantum 1638 rate 128Kbit ceil DS> 128Kbit burst 2Kb/8 mpu 0b cburst 1762b/8 mpu 0b level 0 DS> Sent 0 bytes 0 pkts (dropped 0, overlimits 0) DS> lended: 0 borrowed: 0 giants: 0 DS> tokens: 102400 ctokens: 88149 DS> To kernel-2.4.18 I applied the following patches: DS> htb3.6_2.4.17.diff DS> imq-2.4.18.diff-10 DS> iptables-1.2.6a-imq DS> /sbin/tc qdisc del dev eth0 root DS> /sbin/tc qdisc add dev eth0 root handle 1: htb default 200 DS> /sbin/tc class add dev eth0 parent 1:0 classid 1:1 htb\ DS> rate 100Mbit ceil 100Mbit burst 2k prio 5 DS> /sbin/tc filter add dev eth0 parent 1:0 protocol ip\ DS> prio 5 handle 1: u32 divisor 256 DS> /sbin/tc class add dev eth0 parent 1:1 classid 1:2 htb\ DS> rate 50Mbit ceil 50Mbit burst 2k prio 5 DS> /sbin/tc qdisc add dev eth0 parent 1:2 handle 10: sfq quantum 1514 perturb 10 DS> /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 5 u32 \ DS> match ip dst 10.0.0.1 flowid 1:2 DS> /sbin/tc filter add dev eth0 parent 1:0 prio 5\ DS> handle ::1 u32 ht 800:: match ip nofrag\ DS> offset mask 0x0F00 shift 6\ DS> hashkey mask 0x00ff0000 at 8 link 1: DS> Daniel Sercaianu DS> Terranet Virtual Media DS> sdan@terranet.ro DS> GSM +40 788 837723 DS> _______________________________________________ DS> LARTC mailing list / LARTC@mailman.ds9a.nl DS> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From devik@cdi.cz Wed Aug 14 22:32:05 2002 From: devik@cdi.cz (devik) Date: Wed, 14 Aug 2002 23:32:05 +0200 (CEST) Subject: [LARTC] HTB is in 2.4.20pre1,2 Message-ID: Hi, for those who haven't realized it yet. It is in 2.4.20pre2, 2.5.xx, should go into new iproute2 package and I have informations about possibility to have it in 2.2 soon. devik From Alexey Talikov Thu Aug 15 06:46:07 2002 From: Alexey Talikov (Alexey Talikov) Date: Thu, 15 Aug 2002 10:46:07 +0500 Subject: [LARTC] HTB is in 2.4.20pre1,2 In-Reply-To: References: Message-ID: <1662289151.20020815104607@texlab.com.uz> Hello devik, Thanks for your great work I think in many cases HTB is more simple, power and beautiful than CBQ. Thursday, August 15, 2002, 2:32:05 AM, you wrote: d> Hi, d> for those who haven't realized it yet. It is in 2.4.20pre2, d> 2.5.xx, should go into new iproute2 package and I have informations d> about possibility to have it in 2.2 soon. d> devik d> _______________________________________________ d> LARTC mailing list / LARTC@mailman.ds9a.nl d> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From arindamhaldar@inbox.lv Thu Aug 15 08:33:22 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Thu, 15 Aug 2002 13:03:22 +0530 Subject: [LARTC] Advance Routing Guidance Message-ID: <3D5B5942.6050503@inbox.lv> hi all, i want guidance in advance routing--to be specific load balance between two links.. i have gone thru the LARTC docs and docs for julians patches too.. am yet to implement it but have a few queries/doubts.. our setup--> we have two providers. the present one is thru a wan link using cisco router & the 2nd is a wireless link terminated in another router. these two routers will be connected to linux box(its a compulsion to have 2 routers).. the linx box has 3 interface, 2 of wich are connected to the router via a switch.. we already have valid/real ip with us after going thru the docs i find that with julians patch one needs to **MASQUERADE** to the links... we dont want that !.. we want our real ip to flow in these 2 links(real ip already being broadcasted on provider's network).. so my Question is-->possible without **MASQUERADE** ??.. will the setup(as shown in docs) loadbalance for our real ip's ?? .. what other things i have to consider ?.. Awaiting a reply very very anxiously.. A.H From arindamhaldar@inbox.lv Thu Aug 15 09:09:22 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Thu, 15 Aug 2002 13:39:22 +0530 Subject: [LARTC] Route Patch from julian Message-ID: <3D5B61B2.4020002@inbox.lv> hi, im sorry if this mail doesnt apply to this mailing list but i really need help... while applying patches to kernel-2.4.19, i got these errors... i did this first [root@Lr1 linux-2.4.19-r]# patch -p1 < ../routes-2.4.19-8.diff patching file include/net/ip_fib.h patch: **** malformed patch at line 6: fib_result *res) After which i applied... [root@Lr1 linux-2.4.19-r]# patch -p1 < ../00_static_routes-2.4.19-8.diff patching file include/net/ip_fib.h patching file net/ipv4/fib_semantics.c patching file net/ipv4/fib_frontend.c [root@Lr1 linux-2.4.19-r]# patch -p1 < ../01_alt_routes-2.4.19-8.diff patching file include/net/ip_fib.h patch: **** malformed patch at line 6: fib_result *res) [root@Lr1 linux-2.4.19-r]# patch -p1 < ../01_arp_prefsrc-2.4.12-5.diff patching file net/ipv4/arp.c [root@Lr1 linux-2.4.19-r]# patch -p1 < ../05_nf_reroute-2.4.19-8.diff patching file include/net/route.h patch: **** malformed patch at line 16: net_device *devin); i need help is solving this.. plss help ! awaiting a reply A.H From support@obsidian-studios.com Thu Aug 15 09:42:52 2002 From: support@obsidian-studios.com (William L. Thomson Jr.) Date: 15 Aug 2002 01:42:52 -0700 Subject: [LARTC] Advance Routing Guidance In-Reply-To: <3D5B5942.6050503@inbox.lv> References: <3D5B5942.6050503@inbox.lv> Message-ID: <1029400972.1711.15.camel@wlt.obsidian-studios.com> On Thu, 2002-08-15 at 00:33, Arindam Haldar wrote: > so my Question is-->possible without **MASQUERADE** ??.. No > will the > setup(as shown in docs) loadbalance for our real ip's ?? .. Not without the Linux router performing NAT. > what other things i have to consider ?.. I would consider doing some NAT in one way or another. In my case I perform two consecutive rounds of NAT, one in each router, and again in the Linux router. In short, in order for Julian's patches to work and to load balance the connections, the Linux router must be doing NAT. So I would look into a topology in your network that would allow for the Linux router to perform NAT. Otherwise I do not believe you will be able to load balance your connections. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com From support@obsidian-studios.com Thu Aug 15 09:43:04 2002 From: support@obsidian-studios.com (William L. Thomson Jr.) Date: 15 Aug 2002 01:43:04 -0700 Subject: [LARTC] Route Patch from julian In-Reply-To: <3D5B61B2.4020002@inbox.lv> References: <3D5B61B2.4020002@inbox.lv> Message-ID: <1029400984.1716.18.camel@wlt.obsidian-studios.com> I would contact Julian directly on this matter. He usually will have some other patches or be able to tweak an existing patch so you can apply it without problems. On Thu, 2002-08-15 at 01:09, Arindam Haldar wrote: > hi, > > im sorry if this mail doesnt apply to this mailing list but i really > need help... > while applying patches to kernel-2.4.19, i got these errors... > i did this first > [root@Lr1 linux-2.4.19-r]# patch -p1 < ../routes-2.4.19-8.diff > patching file include/net/ip_fib.h > patch: **** malformed patch at line 6: fib_result *res) > > After which i applied... > > [root@Lr1 linux-2.4.19-r]# patch -p1 < ../00_static_routes-2.4.19-8.diff > patching file include/net/ip_fib.h > patching file net/ipv4/fib_semantics.c > patching file net/ipv4/fib_frontend.c > > [root@Lr1 linux-2.4.19-r]# patch -p1 < ../01_alt_routes-2.4.19-8.diff > patching file include/net/ip_fib.h > patch: **** malformed patch at line 6: fib_result *res) > > [root@Lr1 linux-2.4.19-r]# patch -p1 < ../01_arp_prefsrc-2.4.12-5.diff > patching file net/ipv4/arp.c > > [root@Lr1 linux-2.4.19-r]# patch -p1 < ../05_nf_reroute-2.4.19-8.diff > patching file include/net/route.h > patch: **** malformed patch at line 16: net_device *devin); > > i need help is solving this.. plss help ! > awaiting a reply > A.H > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com From patrick_chan@mtelnet.com Thu Aug 15 10:16:57 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Thu, 15 Aug 2002 17:16:57 +0800 Subject: [LARTC] How to read the statistics Message-ID: <80313B62CF86B749B7C416579F3944980FD7A8@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2443C.81621310 Content-Type: text/plain; charset="iso-8859-1" Hi all, How can I know how many packets are dropped? I have used: tc qdisc It just show me which qdisc I have set. Thanks. ------_=_NextPart_001_01C2443C.81621310 Content-Type: text/html; charset="iso-8859-1" How to read the statistics

Hi all,

How can I know how many packets are dropped?

I have used:
tc qdisc
It just show me which qdisc I have set.

Thanks.

------_=_NextPart_001_01C2443C.81621310-- From Alberto.Baragatti@nokia.com Thu Aug 15 10:25:41 2002 From: Alberto.Baragatti@nokia.com (Alberto.Baragatti@nokia.com) Date: Thu, 15 Aug 2002 11:25:41 +0200 Subject: [LARTC] How to read the statistics Message-ID: <9DF9EDD872380D4B802D1E341ABF6471F7AB15@duebe003.NOE.Nokia.com> try to use "tc -s -d qdisc" =20 ciao, - Alb =20 -----Original Message----- From: ext Patrick Chan [mailto:patrick_chan@mtelnet.com] Sent: Donnerstag, 15. August 2002 11:17 To: lartc@mailman.ds9a.nl Subject: [LARTC] How to read the statistics Hi all,=20 How can I know how many packets are dropped?=20 I have used:=20 tc qdisc=20 It just show me which qdisc I have set.=20 Thanks.=20 From laurens.van.alphen@keenondots.com Thu Aug 15 16:34:23 2002 From: laurens.van.alphen@keenondots.com (Laurens van Alphen) Date: Thu, 15 Aug 2002 17:34:23 +0200 Subject: [LARTC] Advance Routing Guidance Message-ID: <68B054706B911B4189020B333B10A2DA01B724@filmore.corp.keenondots.com> > so my Question is-->possible without **MASQUERADE** ??.. will the=20 > setup(as shown in docs) loadbalance for our real ip's ?? Short answer: No. Long answer: You should first answer the question: what kind of LB do you want? = Incoming, outgoing or both? If you want incoming only, you don't need = Julian's patches, nor NAT per s=E9. You can use DNS to balance your = incoming connections and assing every backend server two IP addresses: = one from both IP ranges. If you want outgoing LB, or both: Julian's patches work when you have more than one IP range, but each IP = range is going only through one provider, that is: you do not have PI = address space and do not use BGP4 to announce your routes through = multiple providers. If you do have PI address space and speak BGP4, you = don't need Julian's patches nor do you need NAT. This is probably not your case, and the IP ranges you received from your = providers are PA, that is they are part of the larger address space of = your provider. This means that IP range 1 will only come through = provider 1 and IP range 2 will only flow through provider 2. Because of this: if you don't use NAT and assign an IP from IP range 1 = to some machine, the server will never be able to use the link through = provider 2, because his address is from IP range 1 and will only flow = through provider 1 (read above). For this to work, you THUS need NAT. Why don't you want to use NAT? NAT is not dirty. NAT is stable, fast, = secure and saves you from renumbering your network when you switch = providers. Hope this is clear and helps, if not, ask. Cheers, Laurens van Alphen Keen on dots From arthurvl@sci.kun.nl Thu Aug 15 20:35:16 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Thu, 15 Aug 2002 21:35:16 +0200 (MEST) Subject: [LARTC] Advance Routing Guidance In-Reply-To: <68B054706B911B4189020B333B10A2DA01B724@filmore.corp.keenondots.com> Message-ID: On Thu, 15 Aug 2002, Laurens van Alphen wrote: > Why don't you want to use NAT? NAT is not dirty. NAT is stable, fast, > secure and saves you from renumbering your network when you switch > providers. On the other hand, NAT breaks useful stuff such as IPSec. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From ja@ssi.bg Fri Aug 16 01:06:43 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 16 Aug 2002 00:06:43 +0000 (GMT) Subject: [LARTC] Advance Routing Guidance In-Reply-To: <3D5B5942.6050503@inbox.lv> Message-ID: Hello, On Thu, 15 Aug 2002, Arindam Haldar wrote: > after going thru the docs i find that with julians patch one needs to > **MASQUERADE** to the links... we dont want that !.. we want our real ip > to flow in these 2 links(real ip already being broadcasted on provider's > network).. > so my Question is-->possible without **MASQUERADE** ??.. will the > setup(as shown in docs) loadbalance for our real ip's ?? .. Of course, it is possible ... and depends on how restrictive are your providers. But if one link fails you can have the problem of using sources for the failed link, then the replies from world will hit the failed provider and will not reach you. As result, your internal servers should know which source addresses to use according to the link state. The masquerade simply guarantees that one link is used only from addresses that are reachable from this link. > what other things i have to consider ?.. As for applying the patches you need to download them correctly. More likely you have white space problem (try with patch -l). > Awaiting a reply very very anxiously.. > A.H Regards -- Julian Anastasov From mabrown-lartc@securepipe.com Thu Aug 15 22:18:28 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Thu, 15 Aug 2002 16:18:28 -0500 (CDT) Subject: [LARTC] conditional routing based on tos/fwmark not working with ipsec Message-ID: Hello all, I am working with kernel 2.2.20 with the necessary options configured into the kernel to support all of the wonderfully fancy routing features: - routing based on ToS - routing based on fwmark - multiple routing tables This same kernel is in use elsewhere, and is routing based on fwmark with success. This leads me to believe that my kernel is OK and that I have another problem. problem description - - - - - - - - - - I have marked packets using ipchains, created another routing table, and populated that routing table with a single route. # ipchains -I output 1 -p tcp -s $OUTIF $PORT -d $CLIENT -m 8 -j ACCEPT # ip rule add from $OUTIF fwmark 8 lookup 8 # ip route add $CLIENT via $GW dev eth0 table 8 # ip route flush cache When I inspect the counters on the chains, I notice that the chain I insert is actually in use (the counter does increment). The problem is that the packet is still routed out the ipsec0 interface. Operating on the false assumption that I was misunderstanding something, I tried a similar technique with ToS. This failed as well. # ipchains -I output 1 -p tcp -s $OUTIF $PORT -d $CLIENT -t 0x01 0x04 -j ACCEPT # ip route add from $OUTIF tos 0x04 dev eth0 # ip route flush cache In each case, I am able to see the packets leaving the ipsec0 interface. In the former case, I see the counters on the chain incrementing. In the latter case, I see the tos bits set in the packet outbound on ipsec0. summary of questions - - - - - - - - - - 1. Does anybody have any idea why packets which have been marked (fwmark) would not be routed according to the RPDB? 2. Am I marking packets on the wrong chain? 2.a Don't locally generated packets only traverse the output chain? 3. Any suggestions for how to separate the IPSec packets from "plaintext" packets and route them according to these rules: - IPSec packet bound for internal network; via ipsec0 - any other IP packet (ping, tcp, udp); via eth0 -Martin relevant kernel options settings - - - - - - - - - - - - - - - - CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_LARGE_TABLES=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_NETLINK=y CONFIG_NETLINK_DEV=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_DIVERT=y CONFIG_DIV_PT=y -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From arindamhaldar@inbox.lv Fri Aug 16 15:56:24 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Fri, 16 Aug 2002 20:26:24 +0530 Subject: [LARTC] Advance Routing Guidance References: Message-ID: <3D5D1298.6040100@inbox.lv> hi julian hi all thanx to you all.. many doubts are now cleared.. the **NATing** soulution is ofcource a very steady one but am not able to convince my management for it !.. hopefully they will... ys julian you r right :).. there were white spaces--it's patched perfectly now .. :) .. to you all---> have a :) sunday.. :) A.H Julian Anastasov wrote: > Hello, > > On Thu, 15 Aug 2002, Arindam Haldar wrote: > > >>after going thru the docs i find that with julians patch one needs to >>**MASQUERADE** to the links... we dont want that !.. we want our real ip >>to flow in these 2 links(real ip already being broadcasted on provider's >>network).. >>so my Question is-->possible without **MASQUERADE** ??.. will the >>setup(as shown in docs) loadbalance for our real ip's ?? .. > > > Of course, it is possible ... and depends on how restrictive > are your providers. But if one link fails you can have the problem > of using sources for the failed link, then the replies from world > will hit the failed provider and will not reach you. As result, > your internal servers should know which source addresses to use > according to the link state. The masquerade simply guarantees that > one link is used only from addresses that are reachable from this > link. > > >>what other things i have to consider ?.. > > > As for applying the patches you need to download them > correctly. More likely you have white space problem (try with > patch -l). > > >>Awaiting a reply very very anxiously.. >>A.H > > > Regards > > -- > Julian Anastasov > > > From tack@auc.ca Fri Aug 16 19:43:54 2002 From: tack@auc.ca (Jason Tackaberry) Date: 16 Aug 2002 14:43:54 -0400 Subject: [LARTC] HTB is in 2.4.20pre1,2 In-Reply-To: <1662289151.20020815104607@texlab.com.uz> References: <1662289151.20020815104607@texlab.com.uz> Message-ID: <1029523435.10208.22.camel@somewhere.auc.ca> On Thu, 2002-08-15 at 01:46, Alexey Talikov wrote: > I think in many cases HTB is more simple, power and beautiful > than CBQ. Not only that, but it _works_, which is pretty important for me. :) I'm very happy to see it included into the main kernel. Best, Jason. -- Academic Computing Support Specialist Algoma University College Sault Ste. Marie, Ontario 705-949-2301 x330 Personal Home Page http://www.auc.ca http://sault.org From amitk@ittc.ku.edu Fri Aug 16 21:54:10 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Fri, 16 Aug 2002 15:54:10 -0500 (CDT) Subject: [LARTC] HTB3 port for 2.2.18? In-Reply-To: <1029523435.10208.22.camel@somewhere.auc.ca> Message-ID: Hi all, Is there an HTB3 port for 2.2.18? Is HTB2 patch on devik's site accurate enough in 2.2.18? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From amitk@ittc.ku.edu Fri Aug 16 22:09:15 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Fri, 16 Aug 2002 16:09:15 -0500 (CDT) Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ Message-ID: Hi all, Sally Floyd's Link sharing paper defines the following: 1. Bounded class: class that is not allowed to borrow from ancestor classes, regardless of the limit status of those classes. 2. Isolated class: class that does not allow non-descendant classes to borrow its unused bandwidth and that does not borrow bandwidth from other classes in turn How does HTB implement a 'bounded class'? I seem to see no constructs to be able to do this. The 'ceil' parameter allows us to implement a part of the 'isolated' definition above. By setting it equal to 'rate', the class does not borrow bandwidth, but what will stop other classes from borrowing its unused bandwidth? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From piotr@omega.resa.es Fri Aug 16 23:38:50 2002 From: piotr@omega.resa.es (Pedro Larroy) Date: Sat, 17 Aug 2002 00:38:50 +0200 Subject: [LARTC] Implementation details of sch Message-ID: <20020816223850.GA4245@omega> Hi I'm trying to understand the sch implementation in the linux kernel. Is there some documentation out there that may be helpful to me? Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| From wa@almesberger.net Sat Aug 17 01:59:14 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 16 Aug 2002 21:59:14 -0300 Subject: [LARTC] Implementation details of sch In-Reply-To: <20020816223850.GA4245@omega>; from piotr@omega.resa.es on Sat, Aug 17, 2002 at 12:38:50AM +0200 References: <20020816223850.GA4245@omega> Message-ID: <20020816215914.C2239@almesberger.net> Pedro Larroy wrote: > I'm trying to understand the sch implementation in the linux kernel. Is > there some documentation out there that may be helpful to me? ftp://icaftp.epfl.ch/pub/people/almesber/pub/tcio-current.ps.gz and, more recent, but not quite finished: ftp://icaftp.epfl.ch/pub/people/almesber/junk/tc-04FEB2001-0.tar.gz - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From mikep02@softerware.com Sat Aug 17 05:32:12 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Sat, 17 Aug 2002 00:32:12 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #721 - 6 msgs Message-ID: <211962148@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #721 - 6 msgs From: lartc@mailman.ds9a.nl Date: 08/17/02 01:27:51 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: Advance Routing Guidance (Arindam Haldar) 2. Re: HTB is in 2.4.20pre1,2 (Jason Tackaberry) 3. HTB3 port for 2.2.18? (Amit Kucheria) 4. HTB equivalent for 'bounded' and 'isolated' in CBQ (Amit Kucheria) 5. Implementation details of sch (Pedro Larroy) 6. Re: Implementation details of sch (Werner Almesberger) --__--__-- Message: 1 Date: Fri, 16 Aug 2002 20:26:24 +0530 From: Arindam Haldar To: Julian Anastasov Cc: LARTC Subject: Re: [LARTC] Advance Routing Guidance hi julian hi all thanx to you all.. many doubts are now cleared.. the **NATing** soulution is ofcource a very steady one but am not able to convince my management for it !.. hopefully they will... ys julian you r right :).. there were white spaces--it's patched perfectly now .. :) .. to you all---> have a :) sunday.. :) A.H Julian Anastasov wrote: > Hello, > > On Thu, 15 Aug 2002, Arindam Haldar wrote: > > >>after going thru the docs i find that with julians patch one needs to >>**MASQUERADE** to the links... we dont want that !.. we want our real ip >>to flow in these 2 links(real ip already being broadcasted on provider's >>network).. >>so my Question is-->possible without **MASQUERADE** ??.. will the >>setup(as shown in docs) loadbalance for our real ip's ?? .. > > > Of course, it is possible ... and depends on how restrictive > are your providers. But if one link fails you can have the problem > of using sources for the failed link, then the replies from world > will hit the failed provider and will not reach you. As result, > your internal servers should know which source addresses to use > according to the link state. The masquerade simply guarantees that > one link is used only from addresses that are reachable from this > link. > > >>what other things i have to consider ?.. > > > As for applying the patches you need to download them > correctly. More likely you have white space problem (try with > patch -l). > > >>Awaiting a reply very very anxiously.. >>A.H > > > Regards > > -- > Julian Anastasov > > > --__--__-- Message: 2 Subject: Re: [LARTC] HTB is in 2.4.20pre1,2 From: Jason Tackaberry To: Alexey Talikov Cc: devik , lartc@mailman.ds9a.nl Date: 16 Aug 2002 14:43:54 -0400 On Thu, 2002-08-15 at 01:46, Alexey Talikov wrote: > I think in many cases HTB is more simple, power and beautiful > than CBQ. Not only that, but it _works_, which is pretty important for me. :) I'm very happy to see it included into the main kernel. Best, Jason. -- Academic Computing Support Specialist Algoma University College Sault Ste. Marie, Ontario 705-949-2301 x330 Personal Home Page http://www.auc.ca http://sault.org --__--__-- Message: 3 Date: Fri, 16 Aug 2002 15:54:10 -0500 (CDT) From: Amit Kucheria To: lartc@mailman.ds9a.nl Subject: [LARTC] HTB3 port for 2.2.18? Hi all, Is there an HTB3 port for 2.2.18? Is HTB2 patch on devik's site accurate enough in 2.2.18? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ --__--__-- Message: 4 Date: Fri, 16 Aug 2002 16:09:15 -0500 (CDT) From: Amit Kucheria To: lartc@mailman.ds9a.nl Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ Hi all, Sally Floyd's Link sharing paper defines the following: 1. Bounded class: class that is not allowed to borrow from ancestor classes, regardless of the limit status of those classes. 2. Isolated class: class that does not allow non-descendant classes to borrow its unused bandwidth and that does not borrow bandwidth from other classes in turn How does HTB implement a 'bounded class'? I seem to see no constructs to be able to do this. The 'ceil' parameter allows us to implement a part of the 'isolated' definition above. By setting it equal to 'rate', the class does not borrow bandwidth, but what will stop other classes from borrowing its unused bandwidth? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ --__--__-- Message: 5 Date: Sat, 17 Aug 2002 00:38:50 +0200 To: lartc@mailman.ds9a.nl From: Pedro Larroy Subject: [LARTC] Implementation details of sch Hi I'm trying to understand the sch implementation in the linux kernel. Is there some documentation out there that may be helpful to me? Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| --__--__-- Message: 6 Date: Fri, 16 Aug 2002 21:59:14 -0300 From: Werner Almesberger To: piotr@outpost.ds9a.nl, lartc@mailman.ds9a.nl Subject: Re: [LARTC] Implementation details of sch Pedro Larroy wrote: > I'm trying to understand the sch implementation in the linux kernel. Is > there some documentation out there that may be helpful to me? ftp://icaftp.epfl.ch/pub/people/almesber/pub/tcio-current.ps.gz and, more recent, but not quite finished: ftp://icaftp.epfl.ch/pub/people/almesber/junk/tc-04FEB2001-0.tar.gz - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ --__--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest From ja@ssi.bg Sat Aug 17 13:25:30 2002 From: ja@ssi.bg (Julian Anastasov) Date: Sat, 17 Aug 2002 12:25:30 +0000 (GMT) Subject: [LARTC] HTB3 port for 2.2.18? In-Reply-To: Message-ID: Hello, On Fri, 16 Aug 2002, Amit Kucheria wrote: > Is there an HTB3 port for 2.2.18? Yes, I have backported the net/sched from 2.4.20pre1 to 2.2.21, including HTB3. The simple tests look good, the problem is that I still have problems updating/accessing my site. I can provide my "DS-9" tree to anyone interested in testing and hosting the files. > Regards, > Amit Regards -- Julian Anastasov From raptor@unacs.bg Sat Aug 17 14:14:11 2002 From: raptor@unacs.bg (raptor@unacs.bg) Date: Sat, 17 Aug 2002 16:14:11 +0300 Subject: [LARTC] Another sharing tehnique, is this possible ? Message-ID: <20020817161411.32ed78fb.raptor@unacs.bg> hi, (assume HTB) I was thinking will it be possible to do some sort of UNFAIR-SHARING :"), what I have in mind : Say I have a internet link with 100kbits bandwith, then I want to share it between many clients (which will increase over time). Let's i start with 5 clients with rate = 30kbits... See the total bandwith of users is 120kbits but I have only 100kbits.... So where is the problem I want to describe their bandwith like total 100kbits |__ user1 => rate 30kbits, ceil 30kbits |__ user2 => rate 30kbits, ceil 30kbits |__ user3 => rate 30kbits, ceil 30kbits |__ ..................... |__ userX => rate 30kbits, ceil 30kbits U can say why I just don't calculate 100/5 = 20 and set for all users "rate 20kbits, ceil 30kbits", 'cause i will add more users in the future and will need to calculate again and again this value... also some of them may want 30kbits other 10kbits etc.... (it is ok for them to get lower rates 'cause the speed is ungaranteed the user are not online 24hours a day and of course when bandwith got used to the max it will upgraded to better speed).. In fact what I want to say is : the max rate should be X but if the link is overused u will get lower speed ...?? One way this to be done is if I use something like this : rate 0 ceil desired-speed but is this possible, or if not what is the lowest possible value.... - Will proirity have be taken into account so that i can say some should be served better than other ? - the lower possible bandwith i will lend is 9600bps .. yes we have such speeds the price here is big :"( Thanx alot raptor From mikep02@softerware.com Sun Aug 18 05:34:26 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Sun, 18 Aug 2002 00:34:26 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #722 - 3 msgs Message-ID: <1023655209@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #722 - 3 msgs From: lartc@mailman.ds9a.nl Date: 08/18/02 01:27:42 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: LARTC digest, Vol 1 #721 - 6 msgs (mikep02@softerware.com) 2. Re: HTB3 port for 2.2.18? (Julian Anastasov) 3. Another sharing tehnique, is this possible ? (raptor@unacs.bg) --__--__-- Message: 1 Date: Sat, 17 Aug 2002 00:32:12 -0400 To: lartc@mailman.ds9a.nl From: mikep02@softerware.com Reply-To: mikep02@softerware.com Subject: [LARTC] Re: LARTC digest, Vol 1 #721 - 6 msgs I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #721 - 6 msgs From: lartc@mailman.ds9a.nl Date: 08/17/02 01:27:51 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: Advance Routing Guidance (Arindam Haldar) 2. Re: HTB is in 2.4.20pre1,2 (Jason Tackaberry) 3. HTB3 port for 2.2.18? (Amit Kucheria) 4. HTB equivalent for 'bounded' and 'isolated' in CBQ (Amit Kucheria) 5. Implementation details of sch (Pedro Larroy) 6. Re: Implementation details of sch (Werner Almesberger) -- __--__-- Message: 1 Date: Fri, 16 Aug 2002 20:26:24 +0530 From: Arindam Haldar To: Julian Anastasov Cc: LARTC Subject: Re: [LARTC] Advance Routing Guidance hi julian hi all thanx to you all.. many doubts are now cleared.. the **NATing** soulution is ofcource a very steady one but am not able to convince my management for it !.. hopefully they will... ys julian you r right :).. there were white spaces--it's patched perfectly now .. :) .. to you all---> have a :) sunday.. :) A.H Julian Anastasov wrote: > Hello, > > On Thu, 15 Aug 2002, Arindam Haldar wrote: > > >>after going thru the docs i find that with julians patch one needs to >>**MASQUERADE** to the links... we dont want that !.. we want our real ip >>to flow in these 2 links(real ip already being broadcasted on provider's >>network).. >>so my Question is-->possible without **MASQUERADE** ??.. will the >>setup(as shown in docs) loadbalance for our real ip's ?? .. > > > Of course, it is possible ... and depends on how restrictive > are your providers. But if one link fails you can have the problem > of using sources for the failed link, then the replies from world > will hit the failed provider and will not reach you. As result, > your internal servers should know which source addresses to use > according to the link state. The masquerade simply guarantees that > one link is used only from addresses that are reachable from this > link. > > >>what other things i have to consider ?.. > > > As for applying the patches you need to download them > correctly. More likely you have white space problem (try with > patch -l). > > >>Awaiting a reply very very anxiously.. >>A.H > > > Regards > > -- > Julian Anastasov > > > -- __--__-- Message: 2 Subject: Re: [LARTC] HTB is in 2.4.20pre1,2 From: Jason Tackaberry To: Alexey Talikov Cc: devik , lartc@mailman.ds9a.nl Date: 16 Aug 2002 14:43:54 -0400 On Thu, 2002-08-15 at 01:46, Alexey Talikov wrote: > I think in many cases HTB is more simple, power and beautiful > than CBQ. Not only that, but it _works_, which is pretty important for me. :) I'm very happy to see it included into the main kernel. Best, Jason. -- Academic Computing Support Specialist Algoma University College Sault Ste. Marie, Ontario 705-949-2301 x330 Personal Home Page http://www.auc.ca http://sault.org -- __--__-- Message: 3 Date: Fri, 16 Aug 2002 15:54:10 -0500 (CDT) From: Amit Kucheria To: lartc@mailman.ds9a.nl Subject: [LARTC] HTB3 port for 2.2.18? Hi all, Is there an HTB3 port for 2.2.18? Is HTB2 patch on devik's site accurate enough in 2.2.18? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ -- __--__-- Message: 4 Date: Fri, 16 Aug 2002 16:09:15 -0500 (CDT) From: Amit Kucheria To: lartc@mailman.ds9a.nl Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ Hi all, Sally Floyd's Link sharing paper defines the following: 1. Bounded class: class that is not allowed to borrow from ancestor classes, regardless of the limit status of those classes. 2. Isolated class: class that does not allow non-descendant classes to borrow its unused bandwidth and that does not borrow bandwidth from other classes in turn How does HTB implement a 'bounded class'? I seem to see no constructs to be able to do this. The 'ceil' parameter allows us to implement a part of the 'isolated' definition above. By setting it equal to 'rate', the class does not borrow bandwidth, but what will stop other classes from borrowing its unused bandwidth? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ -- __--__-- Message: 5 Date: Sat, 17 Aug 2002 00:38:50 +0200 To: lartc@mailman.ds9a.nl From: Pedro Larroy Subject: [LARTC] Implementation details of sch Hi I'm trying to understand the sch implementation in the linux kernel. Is there some documentation out there that may be helpful to me? Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| -- __--__-- Message: 6 Date: Fri, 16 Aug 2002 21:59:14 -0300 From: Werner Almesberger To: piotr@outpost.ds9a.nl, lartc@mailman.ds9a.nl Subject: Re: [LARTC] Implementation details of sch Pedro Larroy wrote: > I'm trying to understand the sch implementation in the linux kernel. Is > there some documentation out there that may be helpful to me? ftp://icaftp.epfl.ch/pub/people/almesber/pub/tcio-current.ps.gz and, more recent, but not quite finished: ftp://icaftp.epfl.ch/pub/people/almesber/junk/tc-04FEB2001-0.tar.gz - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ -- __--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest --__--__-- Message: 2 Date: Sat, 17 Aug 2002 12:25:30 +0000 (GMT) From: Julian Anastasov To: Amit Kucheria Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB3 port for 2.2.18? Hello, On Fri, 16 Aug 2002, Amit Kucheria wrote: > Is there an HTB3 port for 2.2.18? Yes, I have backported the net/sched from 2.4.20pre1 to 2.2.21, including HTB3. The simple tests look good, the problem is that I still have problems updating/accessing my site. I can provide my "DS-9" tree to anyone interested in testing and hosting the files. > Regards, > Amit Regards -- Julian Anastasov --__--__-- Message: 3 Date: Sat, 17 Aug 2002 16:14:11 +0300 From: raptor@unacs.bg To: lartc@mailman.ds9a.nl Subject: [LARTC] Another sharing tehnique, is this possible ? hi, (assume HTB) I was thinking will it be possible to do some sort of UNFAIR-SHARING :"), what I have in mind : Say I have a internet link with 100kbits bandwith, then I want to share it between many clients (which will increase over time). Let's i start with 5 clients with rate = 30kbits... See the total bandwith of users is 120kbits but I have only 100kbits.... So where is the problem I want to describe their bandwith like total 100kbits |__ user1 => rate 30kbits, ceil 30kbits |__ user2 => rate 30kbits, ceil 30kbits |__ user3 => rate 30kbits, ceil 30kbits |__ ..................... |__ userX => rate 30kbits, ceil 30kbits U can say why I just don't calculate 100/5 = 20 and set for all users "rate 20kbits, ceil 30kbits", 'cause i will add more users in the future and will need to calculate again and again this value... also some of them may want 30kbits other 10kbits etc.... (it is ok for them to get lower rates 'cause the speed is ungaranteed the user are not online 24hours a day and of course when bandwith got used to the max it will upgraded to better speed).. In fact what I want to say is : the max rate should be X but if the link is overused u will get lower speed ...?? One way this to be done is if I use something like this : rate 0 ceil desired-speed but is this possible, or if not what is the lowest possible value.... - Will proirity have be taken into account so that i can say some should be served better than other ? - the lower possible bandwith i will lend is 9600bps .. yes we have such speeds the price here is big :"( Thanx alot raptor --__--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest From noroozi@mehr.sharif.edu Sun Aug 18 12:28:16 2002 From: noroozi@mehr.sharif.edu (noroozi@mehr.sharif.edu) Date: Sun, 18 Aug 2002 11:28:16 GMT Subject: [LARTC] (no subject) Message-ID: <200208181128.g7IBSFh26221@mehr.sharif.edu> Hello every body, I install Traffic control on the my system(Kernel 2.4.7),when I adjust rule on that,my network rate decrease,I don't know why, In the normal operation I get 98Mbps ,but when I use cbq class ,and set the bandwith 50Mbit I get 15Mbps, :( what is the TC buttleneck ? I am really wait for you help, Thanks Noroozi --------------------------------------------- This message was sent using sharif web-based mail. http://mehr.sharif.edu From eric@regit.org Sun Aug 18 14:40:27 2002 From: eric@regit.org (Eric Leblond) Date: 18 Aug 2002 15:40:27 +0200 Subject: [LARTC] (no subject) In-Reply-To: <200208181128.g7IBSFh26221@mehr.sharif.edu> References: <200208181128.g7IBSFh26221@mehr.sharif.edu> Message-ID: <1029678027.21484.11.camel@porky> Le dim 18/08/2002 =E0 13:28, noroozi@mehr.sharif.edu a =E9crit : > In the normal operation I get 98Mbps ,but when I use cbq class ,and set t= he bandwith=20 > 50Mbit I get 15Mbps, :( > what is the TC buttleneck ? The bandwith parameter has to be set to the physical bandwith (use in internal computation), not to the deisirated one, use rate to specify the bandwith of the class. --=20 Eric Leblond Mail: regit@regit.org Tips and Linux: http://www.regit.org *--------------------------------------------------------------------------= -* Computers are like air conditioners. They don't work when Windows are open. *--------------------------------------------------------------------------= -* From ja@ssi.bg Sun Aug 18 19:58:40 2002 From: ja@ssi.bg (Julian Anastasov) Date: Sun, 18 Aug 2002 18:58:40 +0000 (GMT) Subject: [LARTC] Announce: Backport QoS from 2.4 to 2.2 Message-ID: Hello, I'm happy to announce a QoS Backport from 2.4 to 2.2. This is unofficial DiffServ v9 release (a.k.a DS-9). This beta release includes some bugfixes after the last 2.2 release, known as DS-8, many files copied from 2.4.19, some definitions and functions useful for keeping the interface for schedulers and classifiers similar to the 2.4 one. I'm planning to apply all 2.4/2.5 QoS fixes to this DS-9 tree, so the result should be fully functional net schedulers for 2.2. As there are still some 2.2 specific parts, any kind of reports are useful (even the good ones :)). Any bugfixes and comments can be posted directly to me or to the LARTC and/or DiffServ mailing lists. Have fun! DS-9 - QoS Backport from 2.4.19 to 2.2.21: http://www.ssi.bg/~ja/ds9/ Changes between DS-8 and DS-9: http://www.ssi.bg/~ja/ds9/Changelog.ds9 Regards -- Julian Anastasov From p0wer@tl.krakow.pl Sun Aug 18 19:13:42 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Sun, 18 Aug 2002 20:13:42 +0200 (CEST) Subject: [LARTC] HTTP traffic limiting In-Reply-To: <20020813004053.30387988.pulsar@bofh.homeunix.org> Message-ID: On Tue, 13 Aug 2002, Alexey Sheshka wrote: > Hello! > Sorry for ugly english. > /sbin/iptables -A OUTPUT -t mangle -s x.x.x.x --sport 80 -j MARK --set-mark 199 And where is your tc filter statement? You must set some filters to catch the traffic into corresponding class. > But it doesn't work ! Users download files via HTTP at full 100Mb, but if replase > last line with > /sbin/iptables -A OUTPUT -t mangle -s x.x.x.x -j MARK --set-mark 199 > they got 51Mbit. Consider setting some TOS values, it could speed up some traffic if the routers on the route are configured correctly. You could then attach the traffic with each TOS to any of your HTB classes with tc filter statement. -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From p0wer@tl.krakow.pl Sun Aug 18 19:32:59 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Sun, 18 Aug 2002 20:32:59 +0200 (CEST) Subject: [LARTC] Long delays Message-ID: Hi. I'm using HTB to divide my 115kbit (95kbit of actual speed - HDSL) link for 10 people. IT seems to work fine for me. I have created such tree: ISP --, 1:1 - rate 95kbit, ceil 95kbit, burst 10k +-->1:10 - rate 95kbit, ceil 95kbit, burst 10k, prio 0 | +-->1:20 - rate 30kbit, ceil 40kbit, burst 2k, prio 1 | +-->1:30 - rate 30kbit, ceil 40kbit, prio 3 | `-->1:99 - rate 40kbit, ceil 50kbit, burst 5k, prio 2 Filters based on TOS (packets are mangled by firewall): - 1:10 - interactive class, low delays: SSH, telnet and some network games (like MoH,Q3,Battle.NET) - 1:20 - high reliability: WWW, mail, news... - 1:30 - high throughput: KaZaA, FTP... - 1:99 - default class All classes get also the SFQ. The problem is that when classes other than 1:10 are loaded, even slightly, the delays on 1:10 grow too large, thus distorting heavily the network games. When that classes are very heavily loaded, no reasonable playing is possible. I want to reduce the delays in 1:10 to the absolute minimum, especially when the other classes aren't heavily loaded. What should I do? Too slow CPU (P166MMX) ? Greetz. PS. What is the unit for burst: bit/s, byte/s, packet/s or something else? -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From stef.coene@docum.org Sun Aug 18 20:48:09 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 18 Aug 2002 21:48:09 +0200 Subject: [LARTC] Another sharing tehnique, is this possible ? In-Reply-To: <20020817161411.32ed78fb.raptor@unacs.bg> References: <20020817161411.32ed78fb.raptor@unacs.bg> Message-ID: <20020818194810.7259ADC9C6@tartarus.telenet-ops.be> > Say I have a internet link with 100kbits bandwith, then I want to share= it > between many clients (which will increase over time). Let's i start wit= h 5 > clients with rate =3D 30kbits... See the total bandwith of users is 120= kbits > but I have only 100kbits.... So where is the problem I want to describe > their bandwith like > > total 100kbits > > |__ user1 =3D> rate 30kbits, ceil 30kbits > |__ user2 =3D> rate 30kbits, ceil 30kbits > |__ user3 =3D> rate 30kbits, ceil 30kbits > |__ ..................... > |__ userX =3D> rate 30kbits, ceil 30kbits > > U can say why I just don't calculate 100/5 =3D 20 and set for all users= "rate > 20kbits, ceil 30kbits", 'cause i will add more users in the future and = will > need to calculate again and again this value... also some of them may w= ant > 30kbits other 10kbits etc.... (it is ok for them to get lower rates 'ca= use > the speed is ungaranteed the user are not online 24hours a day and of > course when bandwith got used to the max it will upgraded to better > speed).. > > In fact what I want to say is : the max rate should be X but if the lin= k is > overused u will get lower speed ...?? One way this to be done is if I u= se > something like this : > > rate 0 ceil desired-speed > > but is this possible, or if not what is the lowest possible value.... > - Will proirity have be taken into account so that i can say some shoul= d be > served better than other ? - the lower possible bandwith i will lend is > 9600bps .. yes we have such speeds the price here is big :"( Normally, each class gets the rate as a minimum. After that, the remanin= g=20 bandwidth is divided according to the proportions of the rate (more accur= ate,=20 the quantums) but the classes with the lowest prio will be serverd first.= So=20 only remaining bandwidth will be influenced with the prio parameter. And giving a class rate 0 is a strange idea :)=20 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Sun Aug 18 21:01:31 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 18 Aug 2002 22:01:31 +0200 Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ In-Reply-To: References: Message-ID: <20020818200131.DDB73DC9E9@tartarus.telenet-ops.be> On Friday 16 August 2002 23:09, Amit Kucheria wrote: > Hi all, > > Sally Floyd's Link sharing paper defines the following: > > 1. Bounded class: class that is not allowed to borrow from ancestor > classes, regardless of the limit status of those classes. > > 2. Isolated class: class that does not allow non-descendant classes to > borrow its unused bandwidth and that does not borrow bandwidth from > other classes in turn > How does HTB implement a 'bounded class'? I seem to see no constructs t= o > be able to do this. You can use the ceil parameter to bound a class to a certain rate. With = rate=20 =3D ceil, you will get the same result as the bounded option in cbq. > The 'ceil' parameter allows us to implement a part of the 'isolated' > definition above. By setting it equal to 'rate', the class does not > borrow bandwidth, but what will stop other classes from borrowing its > unused bandwidth? Providing no ceil parameter means rate =3D ceil. But this can not be use= d to=20 implement isolated like in cbq. Rate =3D ceil means the class can not us= e more=20 bandwidth then it's rate. Isolated in cbq means other classes can not bo= rrow=20 bandwidth from the class and that's not the same. There is no way you ca= n=20 implement isolated with htb. =20 But with htb you can do something like this : Total : 100 class1 rate 20 ceil 20 class2 rate 40 ceil 80 class3 rate 40 ceil 80 class 1 is isolated like in cbq. It can not use more then it's rate/ceil= and=20 class2 and class3 will never use bandwidth from class1, only from each ot= her.=20 Just like the definition of isolated :) Stef Btw, I never could get isolated working with cbq. --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Sun Aug 18 21:03:40 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 18 Aug 2002 22:03:40 +0200 Subject: [LARTC] Another sharing tehnique, is this possible ? In-Reply-To: <20020818215645.B8297@student.rug.ac.be> References: <20020817161411.32ed78fb.raptor@unacs.bg> <20020818194810.7259ADC9C6@tartarus.telenet-ops.be> <20020818215645.B8297@student.rug.ac.be> Message-ID: <20020818200341.021C6DC9C8@tartarus.telenet-ops.be> On Sunday 18 August 2002 21:56, Ivo De Decker wrote: > On Sun, Aug 18, 2002 at 09:48:09PM +0200, Stef Coene wrote: > > Normally, each class gets the rate as a minimum. After that, the > > remaning bandwidth is divided according to the proportions of the rat= e > > (more accurate, the quantums) but the classes with the lowest prio wi= ll > > be serverd first. So only remaining bandwidth will be influenced wit= h > > the prio parameter. > > > > And giving a class rate 0 is a strange idea :) > > Well, not really: > > There might be some sorts of traffic (eg backups) that aren't really > prioritary. The classes of this traffic could use borrowed bandwith > exclusively: if there is no other traffic (or not enough to fill the to= tal > available bandwith), the backups can happen, but if there is other (hig= her > priority) traffic, the backups can wait till that traffic lessens (assu= ming > this eventually happens, off course). > > > The question is: is this possible? If you have a total of 100, give backup 1 and the rest 99. As long as th= ere=20 is no other traffic, backup can get the full bandwidth. But if there is=20 other traffic, it can use up to 99.=20 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Fabian Gervan Mon Aug 19 03:31:05 2002 From: Fabian Gervan (Fabian Gervan) Date: Sun, 18 Aug 2002 21:31:05 -0500 Subject: [LARTC] filter in-cache traffic with tc Message-ID: <596087767.20020818213105@inter-k.com.ar> Hello lartc, I am using squid in transparent mode, and bandwith control with tc (htb). (redhat 7.3). Currently I mark packets comming from 3128 (squid port) to users, there are any way to filter the trafic if the object that user request alreay is in the squid cache (hit)? sorry for my english. -- Best regards, Fabian mailto:fabian1@inter-k.com.ar From mikep02@softerware.com Mon Aug 19 01:30:34 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Sun, 18 Aug 2002 20:30:34 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #723 - 10 msgs Message-ID: <1594292732@softerware.com> --MIME MULTIPART BOUNDARY=.1029717066:+'1 Content-Type: application/octet-stream Content-Id: <1594292732-2@softerware.com> Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Text Item" U2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCglsYXJ0Y0BtYWlsbWFuLmRz OWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBX ZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRj DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVs cCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5ubA0KDQpZb3UgY2FuIHJlYWNoIHRo ZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0Yy1hZG1pbkBtYWlsbWFuLmRzOWEu bmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQg aXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIExBUlRDIGRpZ2VzdC4uLiIN Cg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IExBUlRDIGRpZ2VzdCwgVm9sIDEgIzcy MiAtIDMgbXNncyAobWlrZXAwMkBzb2Z0ZXJ3YXJlLmNvbSkNCiAgIDIuIChubyBzdWJqZWN0KSAo bm9yb296aUBtZWhyLnNoYXJpZi5lZHUpDQogICAzLiBSZTogKG5vIHN1YmplY3QpIChFcmljIExl YmxvbmQpDQogICA0LiBBbm5vdW5jZTogQmFja3BvcnQgUW9TIGZyb20gMi40IHRvIDIuMiAoSnVs aWFuIEFuYXN0YXNvdikNCiAgIDUuIFJlOiBIVFRQIHRyYWZmaWMgbGltaXRpbmcgKD0/aXNvLTg4 NTktMj9RP1JhZG9zPUIzYXdfPUEzb2JvZGE/PSkNCiAgIDYuIExvbmcgZGVsYXlzICg9P2lzby04 ODU5LTI/UT9SYWRvcz1CM2F3Xz1BM29ib2RhPz0pDQogICA3LiBSZTogQW5vdGhlciBzaGFyaW5n IHRlaG5pcXVlLCBpcyB0aGlzIHBvc3NpYmxlID8gKFN0ZWYgQ29lbmUpDQogICA4LiBSZTogSFRC IGVxdWl2YWxlbnQgZm9yICdib3VuZGVkJyBhbmQgJ2lzb2xhdGVkJyBpbiBDQlEgKFN0ZWYgQ29l bmUpDQogICA5LiBSZTogQW5vdGhlciBzaGFyaW5nIHRlaG5pcXVlLCBpcyB0aGlzIHBvc3NpYmxl ID8gKFN0ZWYgQ29lbmUpDQogIDEwLiBmaWx0ZXIgaW4tY2FjaGUgdHJhZmZpYyAgd2l0aCB0YyAo RmFiaWFuIEdlcnZhbikNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBTdW4sIDE4 IEF1ZyAyMDAyIDAwOjM0OjI2IC0wNDAwDQpUbzogbGFydGNAbWFpbG1hbi5kczlhLm5sDQpGcm9t OiBtaWtlcDAyQHNvZnRlcndhcmUuY29tDQpSZXBseS1UbzogbWlrZXAwMkBzb2Z0ZXJ3YXJlLmNv bQ0KU3ViamVjdDogW0xBUlRDXSBSZTogTEFSVEMgZGlnZXN0LCBWb2wgMSAjNzIyIC0gMyBtc2dz DQoNCkkgd2lsbCBiZSBvdXQgb2YgdGhlIG9mZmljZSBmcm9tIDgvMTkgdW50aWwgOC8yMy4gIEkg d2lsbCBiZSByZXR1cm5pbmcgb24gTW9uZGF5DQphZnRlcm5vb24sIDgvMjYsIGFuZCB3aWxsIHJl cGx5IHRoZW4uDQoNClRoYW5rIHlvdSwNCg0KTWljaGFlbCBQZWxsZWdyaW5vDQpTb2Z0ZXJ3YXJl LCBJbmMuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3ViamVjdDogTEFSVEMgZGlnZXN0LCBWb2wg MSAjNzIyIC0gMyBtc2dzDQpGcm9tOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNCkRhdGU6IDA4LzE4 LzAyIDAxOjI3OjQyDQoNClNlbmQgTEFSVEMgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQoJ bGFydGNAbWFpbG1hbi5kczlhLm5sDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEg dGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KCWh0dHA6Ly9tYWlsbWFuLmRzOWEubmwvbWFpbG1h bi9saXN0aW5mby9sYXJ0Yw0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJq ZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQoJbGFydGMtcmVxdWVzdEBtYWlsbWFuLmRzOWEubmwNCg0K WW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQoJbGFydGMtYWRt aW5AbWFpbG1hbi5kczlhLm5sDQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3Vi amVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiBM QVJUQyBkaWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIFJlOiBMQVJUQyBk aWdlc3QsIFZvbCAxICM3MjEgLSA2IG1zZ3MgKG1pa2VwMDJAc29mdGVyd2FyZS5jb20pDQogICAy LiBSZTogSFRCMyBwb3J0IGZvciAyLjIuMTg/IChKdWxpYW4gQW5hc3Rhc292KQ0KICAgMy4gQW5v dGhlciBzaGFyaW5nIHRlaG5pcXVlLCBpcyB0aGlzIHBvc3NpYmxlID8gKHJhcHRvckB1bmFjcy5i ZykNCg0KLS0gX18tLV9fLS0gDQoNCk1lc3NhZ2U6IDENCkRhdGU6IFNhdCwgMTcgQXVnIDIwMDIg MDA6MzI6MTIgLTA0MDANClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNCkZyb206IG1pa2VwMDJA c29mdGVyd2FyZS5jb20NClJlcGx5LVRvOiBtaWtlcDAyQHNvZnRlcndhcmUuY29tDQpTdWJqZWN0 OiBbTEFSVENdIFJlOiBMQVJUQyBkaWdlc3QsIFZvbCAxICM3MjEgLSA2IG1zZ3MNCg0KSSB3aWxs IGJlIG91dCBvZiB0aGUgb2ZmaWNlIGZyb20gOC8xOSB1bnRpbCA4LzIzLiAgSSB3aWxsIGJlIHJl dHVybmluZyBvbiBNb25kYXkNCmFmdGVybm9vbiwgOC8yNiwgYW5kIHdpbGwgcmVwbHkgdGhlbi4N Cg0KVGhhbmsgeW91LA0KDQpNaWNoYWVsIFBlbGxlZ3Jpbm8NClNvZnRlcndhcmUsIEluYy4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpTdWJqZWN0OiBMQVJUQyBkaWdlc3QsIFZvbCAxICM3MjEgLSA2 IG1zZ3MNCkZyb206IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KRGF0ZTogMDgvMTcvMDIgMDE6Mjc6 NTENCg0KU2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCglsYXJ0Y0BtYWls bWFuLmRzOWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQg V2lkZSBXZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZv L2xhcnRjDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9k eSAnaGVscCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5ubA0KDQpZb3UgY2FuIHJl YWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0Yy1hZG1pbkBtYWlsbWFu LmRzOWEubmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUg c28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIExBUlRDIGRpZ2Vz dC4uLiINCg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IEFkdmFuY2UgUm91dGluZyBH dWlkYW5jZSAoQXJpbmRhbSBIYWxkYXIpDQogICAyLiBSZTogSFRCIGlzIGluIDIuNC4yMHByZTEs MiAoSmFzb24gVGFja2FiZXJyeSkNCiAgIDMuIEhUQjMgcG9ydCBmb3IgMi4yLjE4PyAoQW1pdCBL dWNoZXJpYSkNCiAgIDQuIEhUQiBlcXVpdmFsZW50IGZvciAnYm91bmRlZCcgYW5kICdpc29sYXRl ZCcgaW4gQ0JRIChBbWl0IEt1Y2hlcmlhKQ0KICAgNS4gSW1wbGVtZW50YXRpb24gZGV0YWlscyBv ZiBzY2ggKFBlZHJvIExhcnJveSkNCiAgIDYuIFJlOiBJbXBsZW1lbnRhdGlvbiBkZXRhaWxzIG9m IHNjaCAoV2VybmVyIEFsbWVzYmVyZ2VyKQ0KDQotLSAgX18tLV9fLS0gIA0KDQpNZXNzYWdlOiAx DQpEYXRlOiBGcmksIDE2IEF1ZyAyMDAyIDIwOjI2OjI0ICswNTMwDQpGcm9tOiBBcmluZGFtIEhh bGRhciA8YXJpbmRhbWhhbGRhckBpbmJveC5sdj4NClRvOiBKdWxpYW4gQW5hc3Rhc292IDxqYUBz c2kuYmc+DQpDYzogTEFSVEMgPGxhcnRjQG1haWxtYW4uZHM5YS5ubD4NClN1YmplY3Q6IFJlOiBb TEFSVENdIEFkdmFuY2UgUm91dGluZyBHdWlkYW5jZQ0KDQpoaSBqdWxpYW4NCmhpIGFsbA0KdGhh bnggdG8geW91IGFsbC4uIG1hbnkgZG91YnRzIGFyZSBub3cgY2xlYXJlZC4uIHRoZSAqKk5BVGlu ZyoqIA0Kc291bHV0aW9uIGlzIG9mY291cmNlIGEgdmVyeSBzdGVhZHkgb25lIGJ1dCBhbSBub3Qg YWJsZSB0byBjb252aW5jZSBteSANCm1hbmFnZW1lbnQgZm9yIGl0ICEuLiBob3BlZnVsbHkgdGhl eSB3aWxsLi4uDQp5cyBqdWxpYW4geW91IHIgcmlnaHQgOikuLiB0aGVyZSB3ZXJlIHdoaXRlIHNw YWNlcy0taXQncyBwYXRjaGVkIA0KcGVyZmVjdGx5IG5vdyAuLiA6KSAuLg0KdG8geW91IGFsbC0t LT4gaGF2ZSBhIDopIHN1bmRheS4uDQo6KQ0KQS5IDQoNCkp1bGlhbiBBbmFzdGFzb3Ygd3JvdGU6 DQo+IAlIZWxsbywNCj4gDQo+IE9uIFRodSwgMTUgQXVnIDIwMDIsIEFyaW5kYW0gSGFsZGFyIHdy b3RlOg0KPiANCj4gDQo+PmFmdGVyIGdvaW5nIHRocnUgdGhlIGRvY3MgaSBmaW5kIHRoYXQgd2l0 aCBqdWxpYW5zIHBhdGNoIG9uZSBuZWVkcyB0bw0KPj4qKk1BU1FVRVJBREUqKiB0byB0aGUgbGlu a3MuLi4gd2UgZG9udCB3YW50IHRoYXQgIS4uIHdlIHdhbnQgb3VyIHJlYWwgaXANCj4+dG8gZmxv dyBpbiB0aGVzZSAyIGxpbmtzKHJlYWwgaXAgYWxyZWFkeSBiZWluZyBicm9hZGNhc3RlZCBvbiBw cm92aWRlcidzDQo+Pm5ldHdvcmspLi4NCj4+c28gbXkgUXVlc3Rpb24gaXMtLT5wb3NzaWJsZSB3 aXRob3V0ICoqTUFTUVVFUkFERSoqID8/Li4gd2lsbCB0aGUNCj4+c2V0dXAoYXMgc2hvd24gaW4g ZG9jcykgbG9hZGJhbGFuY2UgZm9yIG91ciByZWFsIGlwJ3MgPz8gLi4NCj4gDQo+IA0KPiAJT2Yg Y291cnNlLCBpdCBpcyBwb3NzaWJsZSAuLi4gYW5kIGRlcGVuZHMgb24gaG93IHJlc3RyaWN0aXZl DQo+IGFyZSB5b3VyIHByb3ZpZGVycy4gQnV0IGlmIG9uZSBsaW5rIGZhaWxzIHlvdSBjYW4gaGF2 ZSB0aGUgcHJvYmxlbQ0KPiBvZiB1c2luZyBzb3VyY2VzIGZvciB0aGUgZmFpbGVkIGxpbmssIHRo ZW4gdGhlIHJlcGxpZXMgZnJvbSB3b3JsZA0KPiB3aWxsIGhpdCB0aGUgZmFpbGVkIHByb3ZpZGVy IGFuZCB3aWxsIG5vdCByZWFjaCB5b3UuIEFzIHJlc3VsdCwNCj4geW91ciBpbnRlcm5hbCBzZXJ2 ZXJzIHNob3VsZCBrbm93IHdoaWNoIHNvdXJjZSBhZGRyZXNzZXMgdG8gdXNlDQo+IGFjY29yZGlu ZyB0byB0aGUgbGluayBzdGF0ZS4gVGhlIG1hc3F1ZXJhZGUgc2ltcGx5IGd1YXJhbnRlZXMgdGhh dA0KPiBvbmUgbGluayBpcyB1c2VkIG9ubHkgZnJvbSBhZGRyZXNzZXMgdGhhdCBhcmUgcmVhY2hh YmxlIGZyb20gdGhpcw0KPiBsaW5rLg0KPiANCj4gDQo+PndoYXQgb3RoZXIgdGhpbmdzIGkgaGF2 ZSB0byBjb25zaWRlciA/Li4NCj4gDQo+IA0KPiAJQXMgZm9yIGFwcGx5aW5nIHRoZSBwYXRjaGVz IHlvdSBuZWVkIHRvIGRvd25sb2FkIHRoZW0NCj4gY29ycmVjdGx5LiBNb3JlIGxpa2VseSB5b3Ug aGF2ZSB3aGl0ZSBzcGFjZSBwcm9ibGVtICh0cnkgd2l0aA0KPiBwYXRjaCAtbCkuDQo+IA0KPiAN Cj4+QXdhaXRpbmcgYSByZXBseSB2ZXJ5IHZlcnkgYW54aW91c2x5Li4NCj4+QS5IDQo+IA0KPiAN Cj4gUmVnYXJkcw0KPiANCj4gLS0NCj4gSnVsaWFuIEFuYXN0YXNvdiA8amFAc3NpLmJnPg0KPiAN Cj4gDQo+IA0KDQoNCg0KLS0gIF9fLS1fXy0tICANCg0KTWVzc2FnZTogMg0KU3ViamVjdDogUmU6 IFtMQVJUQ10gSFRCIGlzIGluIDIuNC4yMHByZTEsMg0KRnJvbTogSmFzb24gVGFja2FiZXJyeSA8 dGFja0BhdWMuY2E+DQpUbzogQWxleGV5IFRhbGlrb3YgPGFsZXhleV90YWxpa292QHRleGxhYi5j b20udXo+DQpDYzogZGV2aWsgPGRldmlrQGNkaS5jej4sIGxhcnRjQG1haWxtYW4uZHM5YS5ubA0K RGF0ZTogMTYgQXVnIDIwMDIgMTQ6NDM6NTQgLTA0MDANCg0KT24gVGh1LCAyMDAyLTA4LTE1IGF0 IDAxOjQ2LCBBbGV4ZXkgVGFsaWtvdiB3cm90ZToNCj4gSSB0aGluayBpbiBtYW55IGNhc2VzIEhU QiBpcyBtb3JlIHNpbXBsZSwgcG93ZXIgYW5kIGJlYXV0aWZ1bA0KPiB0aGFuIENCUS4NCg0KTm90 IG9ubHkgdGhhdCwgYnV0IGl0IF93b3Jrc18sIHdoaWNoIGlzIHByZXR0eSBpbXBvcnRhbnQgZm9y IG1lLiA6KQ0KDQpJJ20gdmVyeSBoYXBweSB0byBzZWUgaXQgaW5jbHVkZWQgaW50byB0aGUgbWFp biBrZXJuZWwuDQoNCkJlc3QsDQpKYXNvbi4NCg0KLS0gDQpBY2FkZW1pYyBDb21wdXRpbmcgU3Vw cG9ydCBTcGVjaWFsaXN0DQpBbGdvbWEgVW5pdmVyc2l0eSBDb2xsZWdlDQpTYXVsdCBTdGUuIE1h cmllLCBPbnRhcmlvDQo3MDUtOTQ5LTIzMDEgeDMzMCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUGVyc29uYWwgSG9tZSBQYWdlDQpodHRwOi8vd3d3LmF1Yy5jYSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vc2F1bHQub3JnDQoNCg0KLS0gIF9fLS1f Xy0tICANCg0KTWVzc2FnZTogMw0KRGF0ZTogRnJpLCAxNiBBdWcgMjAwMiAxNTo1NDoxMCAtMDUw MCAoQ0RUKQ0KRnJvbTogQW1pdCBLdWNoZXJpYSA8YW1pdGtAaXR0Yy5rdS5lZHU+DQpUbzogbGFy dGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0OiBbTEFSVENdIEhUQjMgcG9ydCBmb3IgMi4yLjE4 Pw0KDQpIaSBhbGwsDQoNCklzIHRoZXJlIGFuIEhUQjMgcG9ydCBmb3IgMi4yLjE4Pw0KDQpJcyBI VEIyIHBhdGNoIG9uIGRldmlrJ3Mgc2l0ZSBhY2N1cmF0ZSBlbm91Z2ggaW4gMi4yLjE4Pw0KDQpS ZWdhcmRzLA0KQW1pdA0KLS0gDQpJJ20gYW4gYW5nZWwhISEgSG9uZXN0IQ0KVGhlIGhvcm5zIGFy ZSBqdXN0IHRoZXJlIHRvIGhvbGQgdGhlIGhhbG8gdXAgc3RyYWlnaHQuDQpeLV4tXi1eLV4tXi1e LV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXg0KICAgICAgICAgICAgICAg ICAgQW1pdCBLdWNoZXJpYQ0KICAgICAgICAgIEVFQ1MgR3JhZC4gUmVzZWFyY2ggQXNzaXN0YW50 DQogICAgICAgICBVbml2ZXJzaXR5IG9mIEthbnNhcyBAIExhd3JlbmNlDQogICAoUik6ICsxLTc4 NS04MzAtODUyMSB8fHwgKEMpOiArMS03ODUtNzYwLTI4NzENCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQotLSAgX18tLV9fLS0gIA0KDQpN ZXNzYWdlOiA0DQpEYXRlOiBGcmksIDE2IEF1ZyAyMDAyIDE2OjA5OjE1IC0wNTAwIChDRFQpDQpG cm9tOiBBbWl0IEt1Y2hlcmlhIDxhbWl0a0BpdHRjLmt1LmVkdT4NClRvOiBsYXJ0Y0BtYWlsbWFu LmRzOWEubmwNClN1YmplY3Q6IFtMQVJUQ10gSFRCIGVxdWl2YWxlbnQgZm9yICdib3VuZGVkJyBh bmQgJ2lzb2xhdGVkJyBpbiBDQlENCg0KSGkgYWxsLA0KDQpTYWxseSBGbG95ZCdzIExpbmsgc2hh cmluZyBwYXBlciBkZWZpbmVzIHRoZSBmb2xsb3dpbmc6DQoNCjEuIEJvdW5kZWQgY2xhc3M6IGNs YXNzIHRoYXQgaXMgbm90IGFsbG93ZWQgdG8gYm9ycm93IGZyb20gYW5jZXN0b3IgDQpjbGFzc2Vz LCByZWdhcmRsZXNzIG9mIHRoZSBsaW1pdCBzdGF0dXMgb2YgdGhvc2UgY2xhc3Nlcy4NCg0KMi4g SXNvbGF0ZWQgY2xhc3M6IGNsYXNzIHRoYXQgZG9lcyBub3QgYWxsb3cgbm9uLWRlc2NlbmRhbnQg Y2xhc3NlcyB0byANCmJvcnJvdyBpdHMgdW51c2VkIGJhbmR3aWR0aCBhbmQgdGhhdCBkb2VzIG5v dCBib3Jyb3cgYmFuZHdpZHRoIGZyb20gDQpvdGhlciBjbGFzc2VzIGluIHR1cm4NCg0KSG93IGRv ZXMgSFRCIGltcGxlbWVudCBhICdib3VuZGVkIGNsYXNzJz8gSSBzZWVtIHRvIHNlZSBubyBjb25z dHJ1Y3RzIHRvIA0KYmUgYWJsZSB0byBkbyB0aGlzLg0KDQpUaGUgJ2NlaWwnIHBhcmFtZXRlciBh bGxvd3MgdXMgdG8gaW1wbGVtZW50IGEgcGFydCBvZiB0aGUgJ2lzb2xhdGVkJw0KZGVmaW5pdGlv biBhYm92ZS4gQnkgc2V0dGluZyBpdCBlcXVhbCB0byAncmF0ZScsIHRoZSBjbGFzcyBkb2VzIG5v dA0KYm9ycm93IGJhbmR3aWR0aCwgYnV0IHdoYXQgd2lsbCBzdG9wIG90aGVyIGNsYXNzZXMgZnJv bSBib3Jyb3dpbmcgaXRzDQp1bnVzZWQgYmFuZHdpZHRoPw0KDQpSZWdhcmRzLA0KQW1pdA0KDQot LQ0KSSdtIGFuIGFuZ2VsISEhIEhvbmVzdCENClRoZSBob3JucyBhcmUganVzdCB0aGVyZSB0byBo b2xkIHRoZSBoYWxvIHVwIHN0cmFpZ2h0Lg0KXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4t Xi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4NCiAgICAgICAgICAgICAgICAgIEFtaXQgS3VjaGVyaWEN CiAgICAgICAgICBFRUNTIEdyYWQuIFJlc2VhcmNoIEFzc2lzdGFudA0KICAgICAgICAgVW5pdmVy c2l0eSBvZiBLYW5zYXMgQCBMYXdyZW5jZQ0KICAgKFIpOiArMS03ODUtODMwLTg1MjEgfHx8IChD KTogKzEtNzg1LTc2MC0yODcxDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCg0KLS0gIF9fLS1fXy0tICANCg0KTWVzc2FnZTogNQ0KRGF0ZTog U2F0LCAxNyBBdWcgMjAwMiAwMDozODo1MCArMDIwMA0KVG86IGxhcnRjQG1haWxtYW4uZHM5YS5u bA0KRnJvbTogUGVkcm8gTGFycm95IDxwaW90ckBvbWVnYS5yZXNhLmVzPg0KU3ViamVjdDogW0xB UlRDXSBJbXBsZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHNjaA0KDQpIaQ0KSSdtIHRyeWluZyB0byB1 bmRlcnN0YW5kIHRoZSBzY2ggaW1wbGVtZW50YXRpb24gaW4gdGhlIGxpbnV4IGtlcm5lbC4gSXMN CnRoZXJlIHNvbWUgZG9jdW1lbnRhdGlvbiBvdXQgdGhlcmUgdGhhdCBtYXkgYmUgaGVscGZ1bCB0 byBtZT8NCg0KUmVnYXJkcy4NCi0tIA0KIC4uLiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAuLi4NCnwgICAvfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxcICAgfCANCnwgIC8t fCBQZWRybyBMYXJyb3kgVG92YXIuIFBpb3RSIHwgaHR0cDovL29tZWdhLnJlc2EuZXMvcGlvdHIg IHwtXCAgfA0KfCAvLS18ICAgICAgICAgICAgTm8gTVMtT2ZmaWNlIGF0dGFjaG1lbnRzIHBsZWFz ZS4gICAgICAgICAgICAgfC0tXCB8DQpvLXwtLXwgICAgICAgICAgICAgIGUtbWFpbDogcGlvdHJA b21lZ2EucmVzYS5lcyAgICAgICAgICAgICAgICB8LS18LW8gDQp8ICBcLXwgICAgZmluZ2VyIHBp b3RyQG9tZWdhLnJlc2EuZXMgZm9yIHB1YmxpYyBrZXkgYW5kIGluZm8gICB8LS8gIHwgDQp8Li4u XHxfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X198Ly4uLnwgDQoNCi0tICBfXy0tX18tLSAgDQoNCk1lc3NhZ2U6IDYNCkRhdGU6IEZyaSwgMTYg QXVnIDIwMDIgMjE6NTk6MTQgLTAzMDANCkZyb206IFdlcm5lciBBbG1lc2JlcmdlciA8d2FAYWxt ZXNiZXJnZXIubmV0Pg0KVG86IHBpb3RyQG91dHBvc3QuZHM5YS5ubCwgbGFydGNAbWFpbG1hbi5k czlhLm5sDQpTdWJqZWN0OiBSZTogW0xBUlRDXSBJbXBsZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHNj aA0KDQpQZWRybyBMYXJyb3kgd3JvdGU6DQo+IEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUg c2NoIGltcGxlbWVudGF0aW9uIGluIHRoZSBsaW51eCBrZXJuZWwuIElzDQo+IHRoZXJlIHNvbWUg ZG9jdW1lbnRhdGlvbiBvdXQgdGhlcmUgdGhhdCBtYXkgYmUgaGVscGZ1bCB0byBtZT8NCg0KZnRw Oi8vaWNhZnRwLmVwZmwuY2gvcHViL3Blb3BsZS9hbG1lc2Jlci9wdWIvdGNpby1jdXJyZW50LnBz Lmd6DQphbmQsIG1vcmUgcmVjZW50LCBidXQgbm90IHF1aXRlIGZpbmlzaGVkOg0KZnRwOi8vaWNh ZnRwLmVwZmwuY2gvcHViL3Blb3BsZS9hbG1lc2Jlci9qdW5rL3RjLTA0RkVCMjAwMS0wLnRhci5n eg0KDQotIFdlcm5lcg0KDQotLSANCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KIC8gV2VybmVyIEFsbWVz YmVyZ2VyLCBCdWVub3MgQWlyZXMsIEFyZ2VudGluYSAgICAgICAgIHdhQGFsbWVzYmVyZ2VyLm5l dCAvDQovX2h0dHA6Ly9pY2FwZW9wbGUuZXBmbC5jaC9hbG1lc2Jlci9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fLw0KDQoNCi0tICBfXy0tX18tLSAgDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMQVJUQyBtYWlsaW5nIGxpc3QN CkxBUlRDQG1haWxtYW4uZHM5YS5ubA0KaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xp c3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9mIExBUlRDIERpZ2VzdA0KDQoNCg0KLS0gX18tLV9fLS0g DQoNCk1lc3NhZ2U6IDINCkRhdGU6IFNhdCwgMTcgQXVnIDIwMDIgMTI6MjU6MzAgKzAwMDAgKEdN VCkNCkZyb206IEp1bGlhbiBBbmFzdGFzb3YgPGphQHNzaS5iZz4NClRvOiBBbWl0IEt1Y2hlcmlh IDxhbWl0a0BpdHRjLmt1LmVkdT4NCkNjOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6 IFJlOiBbTEFSVENdIEhUQjMgcG9ydCBmb3IgMi4yLjE4Pw0KDQoNCglIZWxsbywNCg0KT24gRnJp LCAxNiBBdWcgMjAwMiwgQW1pdCBLdWNoZXJpYSB3cm90ZToNCg0KPiBJcyB0aGVyZSBhbiBIVEIz IHBvcnQgZm9yIDIuMi4xOD8NCg0KCVllcywgSSBoYXZlIGJhY2twb3J0ZWQgdGhlIG5ldC9zY2hl ZCBmcm9tIDIuNC4yMHByZTENCnRvIDIuMi4yMSwgaW5jbHVkaW5nIEhUQjMuIFRoZSBzaW1wbGUg dGVzdHMgbG9vayBnb29kLCB0aGUNCnByb2JsZW0gaXMgdGhhdCBJIHN0aWxsIGhhdmUgcHJvYmxl bXMgdXBkYXRpbmcvYWNjZXNzaW5nIG15DQpzaXRlLiBJIGNhbiBwcm92aWRlIG15ICJEUy05IiB0 cmVlIHRvIGFueW9uZSBpbnRlcmVzdGVkIGluDQp0ZXN0aW5nIGFuZCBob3N0aW5nIHRoZSBmaWxl cy4NCg0KPiBSZWdhcmRzLA0KPiBBbWl0DQoNClJlZ2FyZHMNCg0KLS0NCkp1bGlhbiBBbmFzdGFz b3YgPGphQHNzaS5iZz4NCg0KDQotLSBfXy0tX18tLSANCg0KTWVzc2FnZTogMw0KRGF0ZTogU2F0 LCAxNyBBdWcgMjAwMiAxNjoxNDoxMSArMDMwMA0KRnJvbTogcmFwdG9yQHVuYWNzLmJnDQpUbzog bGFydGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0OiBbTEFSVENdIEFub3RoZXIgc2hhcmluZyB0 ZWhuaXF1ZSwgaXMgdGhpcyBwb3NzaWJsZSA/DQoNCg0KDQoNCmhpLA0KKGFzc3VtZSBIVEIpDQpJ IHdhcyB0aGlua2luZyB3aWxsIGl0IGJlIHBvc3NpYmxlIHRvIGRvIHNvbWUgc29ydCBvZiBVTkZB SVItU0hBUklORyA6IiksIHdoYXQgSSBoYXZlIGluIG1pbmQgOg0KDQpTYXkgSSBoYXZlIGEgaW50 ZXJuZXQgbGluayB3aXRoIDEwMGtiaXRzIGJhbmR3aXRoLCB0aGVuIEkgd2FudCB0byBzaGFyZSBp dCBiZXR3ZWVuIG1hbnkgY2xpZW50cyAod2hpY2ggd2lsbCBpbmNyZWFzZSBvdmVyIHRpbWUpLiBM ZXQncyBpIHN0YXJ0IHdpdGggNSBjbGllbnRzIHdpdGggcmF0ZSA9IDMwa2JpdHMuLi4NClNlZSB0 aGUgdG90YWwgYmFuZHdpdGggb2YgdXNlcnMgaXMgMTIwa2JpdHMgYnV0IEkgaGF2ZSBvbmx5IDEw MGtiaXRzLi4uLiBTbyB3aGVyZSBpcyB0aGUgcHJvYmxlbSBJIHdhbnQgdG8gZGVzY3JpYmUgdGhl aXIgYmFuZHdpdGggbGlrZQ0KDQp0b3RhbCAxMDBrYml0cw0KIHxfXyB1c2VyMSA9PiByYXRlIDMw a2JpdHMsIGNlaWwgMzBrYml0cw0KIHxfXyB1c2VyMiA9PiByYXRlIDMwa2JpdHMsIGNlaWwgMzBr Yml0cw0KIHxfXyB1c2VyMyA9PiByYXRlIDMwa2JpdHMsIGNlaWwgMzBrYml0cw0KIHxfXyAgLi4u Li4uLi4uLi4uLi4uLi4uLi4uDQogfF9fIHVzZXJYID0+IHJhdGUgMzBrYml0cywgY2VpbCAzMGti aXRzDQoNClUgY2FuIHNheSB3aHkgSSBqdXN0IGRvbid0IGNhbGN1bGF0ZSAxMDAvNSA9IDIwIGFu ZCBzZXQgZm9yIGFsbCB1c2VycyAicmF0ZSAyMGtiaXRzLCBjZWlsIDMwa2JpdHMiLCAnY2F1c2Ug aSB3aWxsIGFkZCBtb3JlIHVzZXJzIGluIHRoZSBmdXR1cmUgYW5kIHdpbGwgbmVlZCB0byBjYWxj dWxhdGUgYWdhaW4gYW5kIGFnYWluIHRoaXMgdmFsdWUuLi4gYWxzbyBzb21lIG9mIHRoZW0gbWF5 IHdhbnQgMzBrYml0cyBvdGhlciAxMGtiaXRzIGV0Yy4uLi4NCihpdCBpcyBvayBmb3IgdGhlbSB0 byBnZXQgbG93ZXIgcmF0ZXMgJ2NhdXNlIHRoZSBzcGVlZCBpcyB1bmdhcmFudGVlZCB0aGUgdXNl ciBhcmUgbm90IG9ubGluZSAyNGhvdXJzIGEgZGF5IGFuZCBvZiBjb3Vyc2Ugd2hlbiBiYW5kd2l0 aCBnb3QgdXNlZCB0byB0aGUgbWF4IGl0IHdpbGwgdXBncmFkZWQgdG8gYmV0dGVyIHNwZWVkKS4u DQoNCkluIGZhY3Qgd2hhdCBJIHdhbnQgdG8gc2F5IGlzIDogdGhlIG1heCByYXRlIHNob3VsZCBi ZSBYIGJ1dCBpZiB0aGUgbGluayBpcyBvdmVydXNlZCB1IHdpbGwgZ2V0IGxvd2VyIHNwZWVkIC4u Lj8/DQpPbmUgd2F5IHRoaXMgdG8gYmUgZG9uZSBpcyBpZiBJIHVzZSBzb21ldGhpbmcgbGlrZSB0 aGlzIDoNCg0KIHJhdGUgMCBjZWlsIGRlc2lyZWQtc3BlZWQNCg0KYnV0IGlzIHRoaXMgcG9zc2li bGUsIG9yIGlmIG5vdCB3aGF0IGlzIHRoZSBsb3dlc3QgcG9zc2libGUgdmFsdWUuLi4uIA0KLSBX aWxsIHByb2lyaXR5IGhhdmUgYmUgdGFrZW4gaW50byBhY2NvdW50IHNvIHRoYXQgaSBjYW4gc2F5 IHNvbWUgc2hvdWxkIGJlIHNlcnZlZCBiZXR0ZXIgdGhhbiBvdGhlciA/DQotIHRoZSBsb3dlciBw b3NzaWJsZSBiYW5kd2l0aCBpIHdpbGwgbGVuZCBpcyA5NjAwYnBzIC4uIHllcyB3ZSBoYXZlIHN1 Y2ggc3BlZWRzIHRoZSBwcmljZSBoZXJlIGlzIGJpZyA6IigNCg0KVGhhbnggYWxvdA0KcmFwdG9y DQoNCg0KLS0gX18tLV9fLS0gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpMQVJUQyBtYWlsaW5nIGxpc3QNCkxBUlRDQG1haWxtYW4uZHM5YS5ubA0K aHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9m IExBUlRDIERpZ2VzdA0KDQoNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiAyDQpUbzogbGFydGNA bWFpbG1hbi5kczlhLm5sDQpGcm9tOiBub3Jvb3ppQG1laHIuc2hhcmlmLmVkdQ0KRGF0ZTogU3Vu LCAxOCBBdWcgMjAwMiAxMToyODoxNiBHTVQNClN1YmplY3Q6IFtMQVJUQ10gKG5vIHN1YmplY3Qp DQoNCkhlbGxvIGV2ZXJ5IGJvZHksDQpJIGluc3RhbGwgVHJhZmZpYyBjb250cm9sIG9uIHRoZSBt eSBzeXN0ZW0oS2VybmVsIDIuNC43KSx3aGVuIEkgYWRqdXN0IHJ1bGUgb24gdGhhdCxteSANCm5l dHdvcmsgcmF0ZSBkZWNyZWFzZSxJIGRvbid0IGtub3cgd2h5LA0KSW4gdGhlIG5vcm1hbCBvcGVy YXRpb24gSSBnZXQgOThNYnBzICxidXQgd2hlbiBJIHVzZSBjYnEgY2xhc3MgLGFuZCBzZXQgdGhl IGJhbmR3aXRoIA0KNTBNYml0IEkgZ2V0IDE1TWJwcywgOigNCndoYXQgaXMgdGhlIFRDIGJ1dHRs ZW5lY2sgPw0KSSBhbSByZWFsbHkgd2FpdCBmb3IgeW91IGhlbHAsDQpUaGFua3MNCk5vcm9vemkN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1l c3NhZ2Ugd2FzIHNlbnQgdXNpbmcgc2hhcmlmIHdlYi1iYXNlZCBtYWlsLg0KaHR0cDovL21laHIu c2hhcmlmLmVkdQ0KDQoNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiAzDQpTdWJqZWN0OiBSZTog W0xBUlRDXSAobm8gc3ViamVjdCkNCkZyb206IEVyaWMgTGVibG9uZCA8ZXJpY0ByZWdpdC5vcmc+ DQpUbzogbGFydGNAbWFpbG1hbi5kczlhLm5sDQpEYXRlOiAxOCBBdWcgMjAwMiAxNTo0MDoyNyAr MDIwMA0KDQpMZSBkaW0gMTgvMDgvMjAwMiA9RTAgMTM6MjgsIG5vcm9vemlAbWVoci5zaGFyaWYu ZWR1IGEgPUU5Y3JpdCA6DQoNCj4gSW4gdGhlIG5vcm1hbCBvcGVyYXRpb24gSSBnZXQgOThNYnBz ICxidXQgd2hlbiBJIHVzZSBjYnEgY2xhc3MgLGFuZCBzZXQgdD0NCmhlIGJhbmR3aXRoPTIwDQo+ IDUwTWJpdCBJIGdldCAxNU1icHMsIDooDQo+IHdoYXQgaXMgdGhlIFRDIGJ1dHRsZW5lY2sgPw0K DQpUaGUgYmFuZHdpdGggcGFyYW1ldGVyIGhhcyB0byBiZSBzZXQgdG8gdGhlIHBoeXNpY2FsIGJh bmR3aXRoICh1c2UgaW4NCmludGVybmFsIGNvbXB1dGF0aW9uKSwgbm90IHRvIHRoZSBkZWlzaXJh dGVkIG9uZSwgdXNlIHJhdGUgdG8gc3BlY2lmeQ0KdGhlIGJhbmR3aXRoIG9mIHRoZSBjbGFzcy4N Cg0KLS09MjANCkVyaWMgTGVibG9uZA0KTWFpbDogcmVnaXRAcmVnaXQub3JnDQpUaXBzIGFuZCBM aW51eDogaHR0cDovL3d3dy5yZWdpdC5vcmcNCiotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT0NCi0qDQogQ29t cHV0ZXJzIGFyZSBsaWtlIGFpciBjb25kaXRpb25lcnMuIFRoZXkgZG9uJ3Qgd29yayB3aGVuIFdp bmRvd3MgYXJlDQpvcGVuLg0KKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPQ0KLSoNCg0KDQotLV9fLS1fXy0t DQoNCk1lc3NhZ2U6IDQNCkRhdGU6IFN1biwgMTggQXVnIDIwMDIgMTg6NTg6NDAgKzAwMDAgKEdN VCkNCkZyb206IEp1bGlhbiBBbmFzdGFzb3YgPGphQHNzaS5iZz4NClRvOiBsYXJ0YyA8bGFydGNA bWFpbG1hbi5kczlhLm5sPg0KQ2M6IGRpZmZzZXJ2LWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2Uu bmV0LCBqYW1hbCA8aGFkaUBjeWJlcnVzLmNhPg0KU3ViamVjdDogW0xBUlRDXSBBbm5vdW5jZTog QmFja3BvcnQgUW9TIGZyb20gMi40IHRvIDIuMg0KDQoNDQoJSGVsbG8sDQoNCglJJ20gaGFwcHkg dG8gYW5ub3VuY2UgYSBRb1MgQmFja3BvcnQgZnJvbSAyLjQgdG8gMi4yLg0KVGhpcyBpcyB1bm9m ZmljaWFsIERpZmZTZXJ2IHY5IHJlbGVhc2UgKGEuay5hIERTLTkpLg0KDQoJVGhpcyBiZXRhIHJl bGVhc2UgaW5jbHVkZXMgc29tZSBidWdmaXhlcyBhZnRlciB0aGUgbGFzdCAyLjINCnJlbGVhc2Us IGtub3duIGFzIERTLTgsIG1hbnkgZmlsZXMgY29waWVkIGZyb20gMi40LjE5LCBzb21lIGRlZmlu aXRpb25zDQphbmQgZnVuY3Rpb25zIHVzZWZ1bCBmb3Iga2VlcGluZyB0aGUgaW50ZXJmYWNlIGZv ciBzY2hlZHVsZXJzIGFuZA0KY2xhc3NpZmllcnMgc2ltaWxhciB0byB0aGUgMi40IG9uZS4NCg0K CUknbSBwbGFubmluZyB0byBhcHBseSBhbGwgMi40LzIuNSBRb1MgZml4ZXMgdG8gdGhpcyBEUy05 DQp0cmVlLCBzbyB0aGUgcmVzdWx0IHNob3VsZCBiZSBmdWxseSBmdW5jdGlvbmFsIG5ldCBzY2hl ZHVsZXJzDQpmb3IgMi4yLiBBcyB0aGVyZSBhcmUgc3RpbGwgc29tZSAyLjIgc3BlY2lmaWMgcGFy dHMsIGFueSBraW5kIG9mDQpyZXBvcnRzIGFyZSB1c2VmdWwgKGV2ZW4gdGhlIGdvb2Qgb25lcyA6 KSkuDQoNCglBbnkgYnVnZml4ZXMgYW5kIGNvbW1lbnRzIGNhbiBiZSBwb3N0ZWQgZGlyZWN0bHkg dG8gbWUgb3INCnRvIHRoZSBMQVJUQyBhbmQvb3IgRGlmZlNlcnYgbWFpbGluZyBsaXN0cy4NCg0K SGF2ZSBmdW4hDQoNCkRTLTkgLSBRb1MgQmFja3BvcnQgZnJvbSAyLjQuMTkgdG8gMi4yLjIxOg0K aHR0cDovL3d3dy5zc2kuYmcvfmphL2RzOS8NCg0KQ2hhbmdlcyBiZXR3ZWVuIERTLTggYW5kIERT LTk6DQpodHRwOi8vd3d3LnNzaS5iZy9+amEvZHM5L0NoYW5nZWxvZy5kczkNCg0KUmVnYXJkcw0K DQotLQ0KSnVsaWFuIEFuYXN0YXNvdiA8amFAc3NpLmJnPg0KDQoNCi0tX18tLV9fLS0NCg0KTWVz c2FnZTogNQ0KRGF0ZTogU3VuLCAxOCBBdWcgMjAwMiAyMDoxMzo0MiArMDIwMCAoQ0VTVCkNCkZy b206ID0/aXNvLTg4NTktMj9RP1JhZG9zPUIzYXdfPUEzb2JvZGE/PSA8cDB3ZXJAdGwua3Jha293 LnBsPg0KVG86IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogUmU6IFtMQVJUQ10gSFRU UCB0cmFmZmljIGxpbWl0aW5nDQoNCk9uIFR1ZSwgMTMgQXVnIDIwMDIsIEFsZXhleSBTaGVzaGth IHdyb3RlOg0KPiBIZWxsbyENCj4gU29ycnkgZm9yIHVnbHkgZW5nbGlzaC4NCj4gL3NiaW4vaXB0 YWJsZXMgLUEgT1VUUFVUIC10IG1hbmdsZSAgLXMgeC54LngueCAtLXNwb3J0IDgwIC1qIE1BUksg LS1zZXQtbWFyayAxOTkNCg0KQW5kIHdoZXJlIGlzIHlvdXIgdGMgZmlsdGVyIHN0YXRlbWVudD8g WW91IG11c3Qgc2V0IHNvbWUgZmlsdGVycyB0byBjYXRjaA0KdGhlIHRyYWZmaWMgaW50byBjb3Jy ZXNwb25kaW5nIGNsYXNzLg0KDQo+IEJ1dCBpdCBkb2Vzbid0IHdvcmsgISBVc2VycyBkb3dubG9h ZCBmaWxlcyB2aWEgSFRUUCBhdCBmdWxsIDEwME1iLCBidXQgaWYgcmVwbGFzZQ0KPiAgbGFzdCBs aW5lIHdpdGggDQo+IC9zYmluL2lwdGFibGVzIC1BIE9VVFBVVCAtdCBtYW5nbGUgIC1zIHgueC54 LnggIC1qIE1BUksgLS1zZXQtbWFyayAxOTkNCj4gdGhleSBnb3QgNTFNYml0Lg0KDQpDb25zaWRl ciBzZXR0aW5nIHNvbWUgVE9TIHZhbHVlcywgaXQgY291bGQgc3BlZWQgdXAgc29tZSB0cmFmZmlj IGlmIHRoZQ0Kcm91dGVycyBvbiB0aGUgcm91dGUgYXJlIGNvbmZpZ3VyZWQgY29ycmVjdGx5LiBZ b3UgY291bGQgdGhlbiBhdHRhY2ggdGhlDQp0cmFmZmljIHdpdGggZWFjaCBUT1MgdG8gYW55IG9m IHlvdXIgSFRCIGNsYXNzZXMgd2l0aCB0YyBmaWx0ZXIgc3RhdGVtZW50Lg0KDQotLSANCg0KIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojICAgICAgICAgICB8ICAg ICAgIHAwd2VyICAgICAgICB8ICAgICAgICMNCiMgICBfXyAgICAgIHwgICAgR0cjMTg3NzI0OCAg ICAgIHwgICAgICAgIw0KIyAgKG9vKSAgICAgfCBwMHdlckBib2prby5ldS5vcmcgfCAgICAgICAj DQojIC8gXC8gXCBHbyBhd2F5IG9yIEkgd2lsbCByZXBsYWNlIHlvdSAgICMNCiMgYFZfX1YnIHdp dGggYSB2ZXJ5IHNtYWxsIHNoZWxsIHNjcmlwdC4gIw0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjDQoNCg0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogNg0KRGF0 ZTogU3VuLCAxOCBBdWcgMjAwMiAyMDozMjo1OSArMDIwMCAoQ0VTVCkNCkZyb206ID0/aXNvLTg4 NTktMj9RP1JhZG9zPUIzYXdfPUEzb2JvZGE/PSA8cDB3ZXJAdGwua3Jha293LnBsPg0KVG86IGxh cnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogW0xBUlRDXSBMb25nIGRlbGF5cw0KDQoNCkhp Lg0KSSdtIHVzaW5nIEhUQiB0byBkaXZpZGUgbXkgMTE1a2JpdCAoOTVrYml0IG9mIGFjdHVhbCBz cGVlZCAtIEhEU0wpIGxpbmsNCmZvciAxMCBwZW9wbGUuIElUIHNlZW1zIHRvIHdvcmsgZmluZSBm b3IgbWUuIEkgaGF2ZSBjcmVhdGVkIHN1Y2ggdHJlZToNCg0KSVNQIC0tLCAgIDE6MSAgLSByYXRl IDk1a2JpdCwgY2VpbCA5NWtiaXQsIGJ1cnN0IDEwaw0KICAgICAgKy0tPjE6MTAgLSByYXRlIDk1 a2JpdCwgY2VpbCA5NWtiaXQsIGJ1cnN0IDEwaywgcHJpbyAwDQogICAgICB8DQogICAgICArLS0+ MToyMCAtIHJhdGUgMzBrYml0LCBjZWlsIDQwa2JpdCwgYnVyc3QgMmssIHByaW8gMQ0KICAgICAg fA0KICAgICAgKy0tPjE6MzAgLSByYXRlIDMwa2JpdCwgY2VpbCA0MGtiaXQsIHByaW8gMw0KICAg ICAgfA0KICAgICAgYC0tPjE6OTkgLSByYXRlIDQwa2JpdCwgY2VpbCA1MGtiaXQsIGJ1cnN0IDVr LCBwcmlvIDINCg0KRmlsdGVycyBiYXNlZCBvbiBUT1MgKHBhY2tldHMgYXJlIG1hbmdsZWQgYnkg ZmlyZXdhbGwpOg0KLSAxOjEwIC0gaW50ZXJhY3RpdmUgY2xhc3MsIGxvdyBkZWxheXM6IFNTSCwg dGVsbmV0IGFuZCBzb21lIG5ldHdvcmsgZ2FtZXMNCihsaWtlIE1vSCxRMyxCYXR0bGUuTkVUKQ0K LSAxOjIwIC0gaGlnaCByZWxpYWJpbGl0eTogV1dXLCBtYWlsLCBuZXdzLi4uDQotIDE6MzAgLSBo aWdoIHRocm91Z2hwdXQ6IEthWmFBLCBGVFAuLi4NCi0gMTo5OSAtIGRlZmF1bHQgY2xhc3MNCg0K QWxsIGNsYXNzZXMgZ2V0IGFsc28gdGhlIFNGUS4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB3aGVu IGNsYXNzZXMgb3RoZXIgdGhhbiAxOjEwIGFyZSBsb2FkZWQsIGV2ZW4NCnNsaWdodGx5LCB0aGUg ZGVsYXlzIG9uIDE6MTAgZ3JvdyB0b28gbGFyZ2UsIHRodXMgZGlzdG9ydGluZyBoZWF2aWx5IHRo ZQ0KbmV0d29yayBnYW1lcy4gV2hlbiB0aGF0IGNsYXNzZXMgYXJlIHZlcnkgaGVhdmlseSBsb2Fk ZWQsIG5vIHJlYXNvbmFibGUNCnBsYXlpbmcgaXMgcG9zc2libGUuDQoNCkkgd2FudCB0byByZWR1 Y2UgdGhlIGRlbGF5cyBpbiAxOjEwIHRvIHRoZSBhYnNvbHV0ZSBtaW5pbXVtLCBlc3BlY2lhbGx5 DQp3aGVuIHRoZSBvdGhlciBjbGFzc2VzIGFyZW4ndCBoZWF2aWx5IGxvYWRlZC4gV2hhdCBzaG91 bGQgSSBkbz8gVG9vIHNsb3cNCkNQVSAoUDE2Nk1NWCkgPw0KDQpHcmVldHouDQoNClBTLiBXaGF0 IGlzIHRoZSB1bml0IGZvciBidXJzdDogYml0L3MsIGJ5dGUvcywgcGFja2V0L3Mgb3Igc29tZXRo aW5nDQplbHNlPw0KDQotLSANCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjDQojICAgICAgICAgICB8ICAgICAgIHAwd2VyICAgICAgICB8ICAgICAgICMNCiMgICBf XyAgICAgIHwgICAgR0cjMTg3NzI0OCAgICAgIHwgICAgICAgIw0KIyAgKG9vKSAgICAgfCBwMHdl ckBib2prby5ldS5vcmcgfCAgICAgICAjDQojIC8gXC8gXCBHbyBhd2F5IG9yIEkgd2lsbCByZXBs YWNlIHlvdSAgICMNCiMgYFZfX1YnIHdpdGggYSB2ZXJ5IHNtYWxsIHNoZWxsIHNjcmlwdC4gIw0K IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoNCg0KLS1fXy0tX18t LQ0KDQpNZXNzYWdlOiA3DQpGcm9tOiBTdGVmIENvZW5lIDxzdGVmLmNvZW5lQGRvY3VtLm9yZz4N Ck9yZ2FuaXphdGlvbjogTm9uZQ0KVG86IHJhcHRvckB1bmFjcy5iZywgbGFydGNAbWFpbG1hbi5k czlhLm5sDQpTdWJqZWN0OiBSZTogW0xBUlRDXSBBbm90aGVyIHNoYXJpbmcgdGVobmlxdWUsIGlz IHRoaXMgcG9zc2libGUgPw0KRGF0ZTogU3VuLCAxOCBBdWcgMjAwMiAyMTo0ODowOSArMDIwMA0K DQo+IFNheSBJIGhhdmUgYSBpbnRlcm5ldCBsaW5rIHdpdGggMTAwa2JpdHMgYmFuZHdpdGgsIHRo ZW4gSSB3YW50IHRvIHNoYXJlPQ0KIGl0DQo+IGJldHdlZW4gbWFueSBjbGllbnRzICh3aGljaCB3 aWxsIGluY3JlYXNlIG92ZXIgdGltZSkuIExldCdzIGkgc3RhcnQgd2l0PQ0KaCA1DQo+IGNsaWVu dHMgd2l0aCByYXRlID0zRCAzMGtiaXRzLi4uIFNlZSB0aGUgdG90YWwgYmFuZHdpdGggb2YgdXNl cnMgaXMgMTIwPQ0Ka2JpdHMNCj4gYnV0IEkgaGF2ZSBvbmx5IDEwMGtiaXRzLi4uLiBTbyB3aGVy ZSBpcyB0aGUgcHJvYmxlbSBJIHdhbnQgdG8gZGVzY3JpYmUNCj4gdGhlaXIgYmFuZHdpdGggbGlr ZQ0KPg0KPiB0b3RhbCAxMDBrYml0cw0KPg0KPiAgfF9fIHVzZXIxID0zRD4gcmF0ZSAzMGtiaXRz LCBjZWlsIDMwa2JpdHMNCj4gIHxfXyB1c2VyMiA9M0Q+IHJhdGUgMzBrYml0cywgY2VpbCAzMGti aXRzDQo+ICB8X18gdXNlcjMgPTNEPiByYXRlIDMwa2JpdHMsIGNlaWwgMzBrYml0cw0KPiAgfF9f ICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4NCj4gIHxfXyB1c2VyWCA9M0Q+IHJhdGUgMzBrYml0cywg Y2VpbCAzMGtiaXRzDQo+DQo+IFUgY2FuIHNheSB3aHkgSSBqdXN0IGRvbid0IGNhbGN1bGF0ZSAx MDAvNSA9M0QgMjAgYW5kIHNldCBmb3IgYWxsIHVzZXJzPQ0KICJyYXRlDQo+IDIwa2JpdHMsIGNl aWwgMzBrYml0cyIsICdjYXVzZSBpIHdpbGwgYWRkIG1vcmUgdXNlcnMgaW4gdGhlIGZ1dHVyZSBh bmQgPQ0Kd2lsbA0KPiBuZWVkIHRvIGNhbGN1bGF0ZSBhZ2FpbiBhbmQgYWdhaW4gdGhpcyB2YWx1 ZS4uLiBhbHNvIHNvbWUgb2YgdGhlbSBtYXkgdz0NCmFudA0KPiAzMGtiaXRzIG90aGVyIDEwa2Jp dHMgZXRjLi4uLiAoaXQgaXMgb2sgZm9yIHRoZW0gdG8gZ2V0IGxvd2VyIHJhdGVzICdjYT0NCnVz ZQ0KPiB0aGUgc3BlZWQgaXMgdW5nYXJhbnRlZWQgdGhlIHVzZXIgYXJlIG5vdCBvbmxpbmUgMjRo b3VycyBhIGRheSBhbmQgb2YNCj4gY291cnNlIHdoZW4gYmFuZHdpdGggZ290IHVzZWQgdG8gdGhl IG1heCBpdCB3aWxsIHVwZ3JhZGVkIHRvIGJldHRlcg0KPiBzcGVlZCkuLg0KPg0KPiBJbiBmYWN0 IHdoYXQgSSB3YW50IHRvIHNheSBpcyA6IHRoZSBtYXggcmF0ZSBzaG91bGQgYmUgWCBidXQgaWYg dGhlIGxpbj0NCmsgaXMNCj4gb3ZlcnVzZWQgdSB3aWxsIGdldCBsb3dlciBzcGVlZCAuLi4/PyBP bmUgd2F5IHRoaXMgdG8gYmUgZG9uZSBpcyBpZiBJIHU9DQpzZQ0KPiBzb21ldGhpbmcgbGlrZSB0 aGlzIDoNCj4NCj4gIHJhdGUgMCBjZWlsIGRlc2lyZWQtc3BlZWQNCj4NCj4gYnV0IGlzIHRoaXMg cG9zc2libGUsIG9yIGlmIG5vdCB3aGF0IGlzIHRoZSBsb3dlc3QgcG9zc2libGUgdmFsdWUuLi4u DQo+IC0gV2lsbCBwcm9pcml0eSBoYXZlIGJlIHRha2VuIGludG8gYWNjb3VudCBzbyB0aGF0IGkg Y2FuIHNheSBzb21lIHNob3VsPQ0KZCBiZQ0KPiBzZXJ2ZWQgYmV0dGVyIHRoYW4gb3RoZXIgPyAt IHRoZSBsb3dlciBwb3NzaWJsZSBiYW5kd2l0aCBpIHdpbGwgbGVuZCBpcw0KPiA5NjAwYnBzIC4u IHllcyB3ZSBoYXZlIHN1Y2ggc3BlZWRzIHRoZSBwcmljZSBoZXJlIGlzIGJpZyA6IigNCk5vcm1h bGx5LCBlYWNoIGNsYXNzIGdldHMgdGhlIHJhdGUgYXMgYSBtaW5pbXVtLiAgQWZ0ZXIgdGhhdCwg dGhlIHJlbWFuaW49DQpnPTIwDQpiYW5kd2lkdGggaXMgZGl2aWRlZCBhY2NvcmRpbmcgdG8gdGhl IHByb3BvcnRpb25zIG9mIHRoZSByYXRlIChtb3JlIGFjY3VyPQ0KYXRlLD0yMA0KdGhlIHF1YW50 dW1zKSBidXQgdGhlIGNsYXNzZXMgd2l0aCB0aGUgbG93ZXN0IHByaW8gd2lsbCBiZSBzZXJ2ZXJk IGZpcnN0Lj0NCiAgU289MjANCm9ubHkgcmVtYWluaW5nIGJhbmR3aWR0aCB3aWxsIGJlIGluZmx1 ZW5jZWQgd2l0aCB0aGUgcHJpbyBwYXJhbWV0ZXIuDQoNCkFuZCBnaXZpbmcgYSBjbGFzcyByYXRl IDAgaXMgYSBzdHJhbmdlIGlkZWEgOik9MjANCg0KU3RlZg0KDQotLT0yMA0KDQpzdGVmLmNvZW5l QGRvY3VtLm9yZw0KICJVc2luZyBMaW51eCBhcyBiYW5kd2lkdGggbWFuYWdlciINCiAgICAgaHR0 cDovL3d3dy5kb2N1bS5vcmcvDQogICAgICNsYXJ0YyBAIGlyYy5vZnRjLm5ldA0KDQoNCi0tX18t LV9fLS0NCg0KTWVzc2FnZTogOA0KRnJvbTogU3RlZiBDb2VuZSA8c3RlZi5jb2VuZUBkb2N1bS5v cmc+DQpPcmdhbml6YXRpb246IE5vbmUNClRvOiBBbWl0IEt1Y2hlcmlhIDxhbWl0a0BpdHRjLmt1 LmVkdT4sIGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogUmU6IFtMQVJUQ10gSFRCIGVx dWl2YWxlbnQgZm9yICdib3VuZGVkJyBhbmQgJ2lzb2xhdGVkJyBpbiBDQlENCkRhdGU6IFN1biwg MTggQXVnIDIwMDIgMjI6MDE6MzEgKzAyMDANCg0KT24gRnJpZGF5IDE2IEF1Z3VzdCAyMDAyIDIz OjA5LCBBbWl0IEt1Y2hlcmlhIHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IFNhbGx5IEZsb3lkJ3Mg TGluayBzaGFyaW5nIHBhcGVyIGRlZmluZXMgdGhlIGZvbGxvd2luZzoNCj4NCj4gMS4gQm91bmRl ZCBjbGFzczogY2xhc3MgdGhhdCBpcyBub3QgYWxsb3dlZCB0byBib3Jyb3cgZnJvbSBhbmNlc3Rv cg0KPiBjbGFzc2VzLCByZWdhcmRsZXNzIG9mIHRoZSBsaW1pdCBzdGF0dXMgb2YgdGhvc2UgY2xh c3Nlcy4NCj4NCj4gMi4gSXNvbGF0ZWQgY2xhc3M6IGNsYXNzIHRoYXQgZG9lcyBub3QgYWxsb3cg bm9uLWRlc2NlbmRhbnQgY2xhc3NlcyB0bw0KPiBib3Jyb3cgaXRzIHVudXNlZCBiYW5kd2lkdGgg YW5kIHRoYXQgZG9lcyBub3QgYm9ycm93IGJhbmR3aWR0aCBmcm9tDQo+IG90aGVyIGNsYXNzZXMg aW4gdHVybg0KPiBIb3cgZG9lcyBIVEIgaW1wbGVtZW50IGEgJ2JvdW5kZWQgY2xhc3MnPyBJIHNl ZW0gdG8gc2VlIG5vIGNvbnN0cnVjdHMgdD0NCm8NCj4gYmUgYWJsZSB0byBkbyB0aGlzLg0KWW91 IGNhbiB1c2UgdGhlIGNlaWwgcGFyYW1ldGVyIHRvIGJvdW5kIGEgY2xhc3MgdG8gYSBjZXJ0YWlu IHJhdGUuICBXaXRoID0NCnJhdGU9MjANCiA9M0QgY2VpbCwgeW91IHdpbGwgZ2V0IHRoZSBzYW1l IHJlc3VsdCBhcyB0aGUgYm91bmRlZCBvcHRpb24gaW4gY2JxLg0KDQo+IFRoZSAnY2VpbCcgcGFy YW1ldGVyIGFsbG93cyB1cyB0byBpbXBsZW1lbnQgYSBwYXJ0IG9mIHRoZSAnaXNvbGF0ZWQnDQo+ IGRlZmluaXRpb24gYWJvdmUuIEJ5IHNldHRpbmcgaXQgZXF1YWwgdG8gJ3JhdGUnLCB0aGUgY2xh c3MgZG9lcyBub3QNCj4gYm9ycm93IGJhbmR3aWR0aCwgYnV0IHdoYXQgd2lsbCBzdG9wIG90aGVy IGNsYXNzZXMgZnJvbSBib3Jyb3dpbmcgaXRzDQo+IHVudXNlZCBiYW5kd2lkdGg/DQpQcm92aWRp bmcgbm8gY2VpbCBwYXJhbWV0ZXIgbWVhbnMgcmF0ZSA9M0QgY2VpbC4gIEJ1dCB0aGlzIGNhbiBu b3QgYmUgdXNlPQ0KZCB0bz0yMA0KaW1wbGVtZW50IGlzb2xhdGVkIGxpa2UgaW4gY2JxLiAgUmF0 ZSA9M0QgY2VpbCBtZWFucyB0aGUgY2xhc3MgY2FuIG5vdCB1cz0NCmUgbW9yZT0yMA0KYmFuZHdp ZHRoIHRoZW4gaXQncyByYXRlLiAgSXNvbGF0ZWQgaW4gY2JxIG1lYW5zIG90aGVyIGNsYXNzZXMg Y2FuIG5vdCBibz0NCnJyb3c9MjANCmJhbmR3aWR0aCBmcm9tIHRoZSBjbGFzcyBhbmQgdGhhdCdz IG5vdCB0aGUgc2FtZS4gIFRoZXJlIGlzIG5vIHdheSB5b3UgY2E9DQpuPTIwDQppbXBsZW1lbnQg aXNvbGF0ZWQgd2l0aCBodGIuID0yMA0KDQpCdXQgd2l0aCBodGIgeW91IGNhbiBkbyBzb21ldGhp bmcgbGlrZSB0aGlzIDoNCg0KVG90YWwgOiAxMDANCmNsYXNzMSAgIHJhdGUgMjAgICBjZWlsIDIw DQpjbGFzczIgICByYXRlIDQwICAgY2VpbCA4MA0KY2xhc3MzICAgcmF0ZSA0MCAgIGNlaWwgODAN Cg0KY2xhc3MgMSBpcyBpc29sYXRlZCBsaWtlIGluIGNicS4gIEl0IGNhbiBub3QgdXNlIG1vcmUg dGhlbiBpdCdzIHJhdGUvY2VpbD0NCiBhbmQ9MjANCmNsYXNzMiBhbmQgY2xhc3MzIHdpbGwgbmV2 ZXIgdXNlIGJhbmR3aWR0aCBmcm9tIGNsYXNzMSwgb25seSBmcm9tIGVhY2ggb3Q9DQpoZXIuPTIw DQogSnVzdCBsaWtlIHRoZSBkZWZpbml0aW9uIG9mIGlzb2xhdGVkIDopDQoNClN0ZWYNCg0KQnR3 LCBJIG5ldmVyIGNvdWxkIGdldCBpc29sYXRlZCB3b3JraW5nIHdpdGggY2JxLg0KDQotLT0yMA0K DQpzdGVmLmNvZW5lQGRvY3VtLm9yZw0KICJVc2luZyBMaW51eCBhcyBiYW5kd2lkdGggbWFuYWdl ciINCiAgICAgaHR0cDovL3d3dy5kb2N1bS5vcmcvDQogICAgICNsYXJ0YyBAIGlyYy5vZnRjLm5l dA0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDkNCkZyb206IFN0ZWYgQ29lbmUgPHN0ZWYuY29l bmVAZG9jdW0ub3JnPg0KT3JnYW5pemF0aW9uOiBOb25lDQpUbzogSXZvIERlIERlY2tlciA8aXZv QHpldXMucnVnLmFjLmJlPg0KU3ViamVjdDogUmU6IFtMQVJUQ10gQW5vdGhlciBzaGFyaW5nIHRl aG5pcXVlLCBpcyB0aGlzIHBvc3NpYmxlID8NCkRhdGU6IFN1biwgMTggQXVnIDIwMDIgMjI6MDM6 NDAgKzAyMDANCkNjOiByYXB0b3JAdW5hY3MuYmcsIGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KDQpP biBTdW5kYXkgMTggQXVndXN0IDIwMDIgMjE6NTYsIEl2byBEZSBEZWNrZXIgd3JvdGU6DQo+IE9u IFN1biwgQXVnIDE4LCAyMDAyIGF0IDA5OjQ4OjA5UE0gKzAyMDAsIFN0ZWYgQ29lbmUgd3JvdGU6 DQo+ID4gTm9ybWFsbHksIGVhY2ggY2xhc3MgZ2V0cyB0aGUgcmF0ZSBhcyBhIG1pbmltdW0uICBB ZnRlciB0aGF0LCB0aGUNCj4gPiByZW1hbmluZyBiYW5kd2lkdGggaXMgZGl2aWRlZCBhY2NvcmRp bmcgdG8gdGhlIHByb3BvcnRpb25zIG9mIHRoZSByYXQ9DQplDQo+ID4gKG1vcmUgYWNjdXJhdGUs IHRoZSBxdWFudHVtcykgYnV0IHRoZSBjbGFzc2VzIHdpdGggdGhlIGxvd2VzdCBwcmlvIHdpPQ0K bGwNCj4gPiBiZSBzZXJ2ZXJkIGZpcnN0LiAgU28gb25seSByZW1haW5pbmcgYmFuZHdpZHRoIHdp bGwgYmUgaW5mbHVlbmNlZCB3aXQ9DQpoDQo+ID4gdGhlIHByaW8gcGFyYW1ldGVyLg0KPiA+DQo+ ID4gQW5kIGdpdmluZyBhIGNsYXNzIHJhdGUgMCBpcyBhIHN0cmFuZ2UgaWRlYSA6KQ0KPg0KPiBX ZWxsLCBub3QgcmVhbGx5Og0KPg0KPiBUaGVyZSBtaWdodCBiZSBzb21lIHNvcnRzIG9mIHRyYWZm aWMgKGVnIGJhY2t1cHMpIHRoYXQgYXJlbid0IHJlYWxseQ0KPiBwcmlvcml0YXJ5LiBUaGUgY2xh c3NlcyBvZiB0aGlzIHRyYWZmaWMgY291bGQgdXNlIGJvcnJvd2VkIGJhbmR3aXRoDQo+IGV4Y2x1 c2l2ZWx5OiBpZiB0aGVyZSBpcyBubyBvdGhlciB0cmFmZmljIChvciBub3QgZW5vdWdoIHRvIGZp bGwgdGhlIHRvPQ0KdGFsDQo+IGF2YWlsYWJsZSBiYW5kd2l0aCksIHRoZSBiYWNrdXBzIGNhbiBo YXBwZW4sIGJ1dCBpZiB0aGVyZSBpcyBvdGhlciAoaGlnPQ0KaGVyDQo+IHByaW9yaXR5KSB0cmFm ZmljLCB0aGUgYmFja3VwcyBjYW4gd2FpdCB0aWxsIHRoYXQgdHJhZmZpYyBsZXNzZW5zIChhc3N1 PQ0KbWluZw0KPiB0aGlzIGV2ZW50dWFsbHkgaGFwcGVucywgb2ZmIGNvdXJzZSkuDQo+DQo+DQo+ IFRoZSBxdWVzdGlvbiBpczogaXMgdGhpcyBwb3NzaWJsZT8NCklmIHlvdSBoYXZlIGEgdG90YWwg b2YgMTAwLCBnaXZlIGJhY2t1cCAxIGFuZCB0aGUgcmVzdCA5OS4gIEFzIGxvbmcgYXMgdGg9DQpl cmU9MjANCmlzIG5vIG90aGVyIHRyYWZmaWMsIGJhY2t1cCBjYW4gZ2V0IHRoZSBmdWxsIGJhbmR3 aWR0aC4gIEJ1dCBpZiB0aGVyZSBpcz0yMA0Kb3RoZXIgdHJhZmZpYywgaXQgY2FuIHVzZSB1cCB0 byA5OS49MjANCg0KU3RlZg0KDQotLT0yMA0KDQpzdGVmLmNvZW5lQGRvY3VtLm9yZw0KICJVc2lu ZyBMaW51eCBhcyBiYW5kd2lkdGggbWFuYWdlciINCiAgICAgaHR0cDovL3d3dy5kb2N1bS5vcmcv DQogICAgICNsYXJ0YyBAIGlyYy5vZnRjLm5ldA0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDEw DQpEYXRlOiBTdW4sIDE4IEF1ZyAyMDAyIDIxOjMxOjA1IC0wNTAwDQpGcm9tOiBGYWJpYW4gR2Vy dmFuIDxmYWJpYW4xQGludGVyLWsuY29tLmFyPg0KUmVwbHktVG86IEZhYmlhbiBHZXJ2YW4gPGZh YmlhbjFAaW50ZXItay5jb20uYXI+DQpUbzogbGFydGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0 OiBbTEFSVENdIGZpbHRlciBpbi1jYWNoZSB0cmFmZmljICB3aXRoIHRjDQoNCkhlbGxvIGxhcnRj LCBJIGFtIHVzaW5nIHNxdWlkIGluIHRyYW5zcGFyZW50IG1vZGUsIGFuZCBiYW5kd2l0aCBjb250 cm9sDQp3aXRoIHRjIChodGIpLiAocmVkaGF0IDcuMykuDQpDdXJyZW50bHkgSSBtYXJrIHBhY2tl dHMgY29tbWluZyBmcm9tIDMxMjggKHNxdWlkDQpwb3J0KSB0byB1c2VycywgdGhlcmUgYXJlIGFu eSB3YXkgdG8gZmlsdGVyIHRoZSB0cmFmaWMgaWYgdGhlIG9iamVjdA0KdGhhdCB1c2VyIHJlcXVl c3QgYWxyZWF5IGlzIGluIHRoZSBzcXVpZCBjYWNoZSAoaGl0KT8NCnNvcnJ5IGZvciBteSBlbmds aXNoLg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQogRmFiaWFuICAgICAgICAgICAgICAgICAgICAgICAg ICBtYWlsdG86ZmFiaWFuMUBpbnRlci1rLmNvbS5hcg0KDQoNCg0KDQotLV9fLS1fXy0tDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMQVJUQyBtYWls aW5nIGxpc3QNCkxBUlRDQG1haWxtYW4uZHM5YS5ubA0KaHR0cDovL21haWxtYW4uZHM5YS5ubC9t YWlsbWFuL2xpc3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9mIExBUlRDIERpZ2VzdA0KDQo= --MIME MULTIPART BOUNDARY=.1029717066:+'1 Content-Type: text/plain; charset=US-ASCII Content-Id: <1594292732-3@softerware.com> Content-Transfer-Encoding: 7bit I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #723 - 10 msgs From: lartc@mailman.ds9a.nl Date: 08/18/02 21:26:02 This item was automatically created and contains MIME Information. --MIME MULTIPART BOUNDARY=.1029717066:+'1-- From patrick_chan@mtelnet.com Mon Aug 19 03:01:18 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Mon, 19 Aug 2002 10:01:18 +0800 Subject: [LARTC] VoIP and QoS Message-ID: <80313B62CF86B749B7C416579F3944980FD815@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24724.4EFA3390 Content-Type: text/plain; charset="iso-8859-1" There are two Linux routers, a 64K leased line is used to connect these two machines. Now, we would like to run Voice over IP between two machines. We have to run QoS and tag voice packet's TOS field, otherwise, the voice quality is terrible if we transfer file and make voice call at the same time. I am not familiar with tc in Linux. But I have copied a script from LARTC archives. If the following config is used, the situation is better than nothing used. The voice packets can be tagged as TOS=0x21: tc qdisc add dev hdlc0 parent 1:1 handle 2: pfifo limit 512 tc qdisc add dev hdlc0 parent 1:2 handle 3: pfifo limit 512 tc qdisc add dev hdlc0 parent 1:3 handle 4: pfifo limit 512 tc filter add dev hdlc0 parent 1:0 protocol ip prio 1 u32 divisor 1 tc filter add dev hdlc0 parent 1:0 prio 1 u32 match ip tos 0x21 0xff flowid 1:1 I don't know what it means exactly. But this is used, the voice quality is bad at the beginning when file is transferred. The voice quality will "converge" to be good after about 30 seconds. However, this is not acceptable. Can anyone tell me what is the best tc config for running VoIP? Thanks very much. ------_=_NextPart_001_01C24724.4EFA3390 Content-Type: text/html; charset="iso-8859-1" VoIP and QoS

There are two Linux routers, a 64K leased line is used
to connect these two machines. Now, we would like to run
Voice over IP between two machines. We have to run QoS and
tag voice packet's TOS field,
otherwise, the voice quality is terrible if we transfer file
and make voice call at the same time.

I am not familiar with tc in Linux. But I have copied a script
from LARTC archives. If the following config is used, the situation
is better than nothing used. The voice packets can be tagged as
TOS=0x21:

tc qdisc add dev hdlc0 parent 1:1 handle 2: pfifo limit 512
tc qdisc add dev hdlc0 parent 1:2 handle 3: pfifo limit 512
tc qdisc add dev hdlc0 parent 1:3 handle 4: pfifo limit 512
tc filter add dev hdlc0 parent 1:0 protocol ip prio 1 u32 divisor 1
tc filter add dev hdlc0 parent 1:0 prio 1 u32 match ip tos 0x21 0xff flowid 1:1

I don't know what it means exactly. But this is used, the voice quality
is bad at the beginning when file is transferred. The voice quality will
"converge" to be good after about 30 seconds.

However, this is not acceptable. Can anyone tell me what is the best
tc config for running VoIP? Thanks very much.

------_=_NextPart_001_01C24724.4EFA3390-- From Alexey Talikov Mon Aug 19 05:05:12 2002 From: Alexey Talikov (Alexey Talikov) Date: Mon, 19 Aug 2002 09:05:12 +0500 Subject: [LARTC] filter in-cache traffic with tc In-Reply-To: <596087767.20020818213105@inter-k.com.ar> References: <596087767.20020818213105@inter-k.com.ar> Message-ID: <1801614201.20020819090512@texlab.com.uz> Hello Fabian, I recomend you use squid delay pools or WRR qdisc with patch for squid. see this links http://wipl-wrr.sourceforge.net/ http://squid-docs.sourceforge.net/latest/html/x2116.html Monday, August 19, 2002, 7:31:05 AM, you wrote: FG> Hello lartc, I am using squid in transparent mode, and bandwith control FG> with tc (htb). (redhat 7.3). FG> Currently I mark packets comming from 3128 (squid FG> port) to users, there are any way to filter the trafic if the object FG> that user request alreay is in the squid cache (hit)? FG> sorry for my english. ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From mikep02@softerware.com Mon Aug 19 05:29:26 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Mon, 19 Aug 2002 00:29:26 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #725 - 2 msgs Message-ID: <370864772@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #725 - 2 msgs From: lartc@mailman.ds9a.nl Date: 08/19/02 01:27:39 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. VoIP and QoS (Patrick Chan) 2. Re: filter in-cache traffic with tc (Alexey Talikov) --__--__-- Message: 1 From: Patrick Chan To: lartc@mailman.ds9a.nl Date: Mon, 19 Aug 2002 10:01:18 +0800 Subject: [LARTC] VoIP and QoS This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24724.4EFA3390 Content-Type: text/plain; charset="iso-8859-1" There are two Linux routers, a 64K leased line is used to connect these two machines. Now, we would like to run Voice over IP between two machines. We have to run QoS and tag voice packet's TOS field, otherwise, the voice quality is terrible if we transfer file and make voice call at the same time. I am not familiar with tc in Linux. But I have copied a script from LARTC archives. If the following config is used, the situation is better than nothing used. The voice packets can be tagged as TOS=0x21: tc qdisc add dev hdlc0 parent 1:1 handle 2: pfifo limit 512 tc qdisc add dev hdlc0 parent 1:2 handle 3: pfifo limit 512 tc qdisc add dev hdlc0 parent 1:3 handle 4: pfifo limit 512 tc filter add dev hdlc0 parent 1:0 protocol ip prio 1 u32 divisor 1 tc filter add dev hdlc0 parent 1:0 prio 1 u32 match ip tos 0x21 0xff flowid 1:1 I don't know what it means exactly. But this is used, the voice quality is bad at the beginning when file is transferred. The voice quality will "converge" to be good after about 30 seconds. However, this is not acceptable. Can anyone tell me what is the best tc config for running VoIP? Thanks very much. ------_=_NextPart_001_01C24724.4EFA3390 Content-Type: text/html; charset="iso-8859-1" VoIP and QoS

There are two Linux routers, a 64K leased line is used
to connect these two machines. Now, we would like to run
Voice over IP between two machines. We have to run QoS and
tag voice packet's TOS field,
otherwise, the voice quality is terrible if we transfer file
and make voice call at the same time.

I am not familiar with tc in Linux. But I have copied a script
from LARTC archives. If the following config is used, the situation
is better than nothing used. The voice packets can be tagged as
TOS=0x21:

tc qdisc add dev hdlc0 parent 1:1 handle 2: pfifo limit 512
tc qdisc add dev hdlc0 parent 1:2 handle 3: pfifo limit 512
tc qdisc add dev hdlc0 parent 1:3 handle 4: pfifo limit 512
tc filter add dev hdlc0 parent 1:0 protocol ip prio 1 u32 divisor 1
tc filter add dev hdlc0 parent 1:0 prio 1 u32 match ip tos 0x21 0xff flowid 1:1

I don't know what it means exactly. But this is used, the voice quality
is bad at the beginning when file is transferred. The voice quality will
"converge" to be good after about 30 seconds.

However, this is not acceptable. Can anyone tell me what is the best
tc config for running VoIP? Thanks very much.

------_=_NextPart_001_01C24724.4EFA3390-- --__--__-- Message: 2 Date: Mon, 19 Aug 2002 09:05:12 +0500 From: Alexey Talikov Reply-To: Alexey Talikov Organization: Fortek To: Fabian Gervan Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] filter in-cache traffic with tc Hello Fabian, I recomend you use squid delay pools or WRR qdisc with patch for squid. see this links http://wipl-wrr.sourceforge.net/ http://squid-docs.sourceforge.net/latest/html/x2116.html Monday, August 19, 2002, 7:31:05 AM, you wrote: FG> Hello lartc, I am using squid in transparent mode, and bandwith control FG> with tc (htb). (redhat 7.3). FG> Currently I mark packets comming from 3128 (squid FG> port) to users, there are any way to filter the trafic if the object FG> that user request alreay is in the squid cache (hit)? FG> sorry for my english. ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- --__--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest From blackoutz@yahoo.com Mon Aug 19 11:01:03 2002 From: blackoutz@yahoo.com (zain arrifa'i) Date: Mon, 19 Aug 2002 03:01:03 -0700 (PDT) Subject: [LARTC] TC start/stop Problem Message-ID: <20020819100103.45899.qmail@web40201.mail.yahoo.com> I have internet connection with 1,7 mbit down and 512 kbit up currently serving several corporate/college labs, which is fully loaded most of the time. in my shaper box located in remote site, I have my HTB tcscript that simply creates the qdiscs, classes and filters upon execution. I also have a script (tcstop) containing: rmmod sch_htb rmmod sch_sfq rmmod cls_u32 tc qdisc del root dev eth0 tc qdisc del root dev eth1 for releasing the traffic control. problem is : I need to make changes to my start script, so I execute the tcstop script, edit the tcstart script a little, execute it, and boom. My shaperbox disconnected from the rest of the net. since my shaperbox is placed right before the gateway/WAN router, we all got disconnected. when I came to the shaperbox, it didn't crash or hang, it is just disconnected. and I couldn't find any suspicious log related to that. It didn't happen all the times (about 1 out of 5) but quite annoying. anyone have any idea about that? because I still can't figured out why. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From blackoutz@yahoo.com Mon Aug 19 11:17:35 2002 From: blackoutz@yahoo.com (zain arrifa'i) Date: Mon, 19 Aug 2002 03:17:35 -0700 (PDT) Subject: [LARTC] HTB 3.6-020525-error still Message-ID: <20020819101735.49293.qmail@web40205.mail.yahoo.com> I always got messages like this when I start my tc script: Aug 19 11:10:03 yggdrasil kernel: htb: assertion (cl && cl->un.leaf.q->q.qlen) failed at sch_htb.c(94 9) Aug 19 11:10:03 yggdrasil kernel: htb: class 10014 isn't work conserving ?! Aug 19 11:10:03 yggdrasil kernel: KERNEL: assertion (cl && cl->un.leaf.q->q.qlen ) failed at sch_htb.c(949) Aug 19 11:10:04 yggdrasil last message repeated 487 times weird is, the tc rules themselves still running. I patched and recompiled my kernel (2.4.18) and ip route2-2.4.7-now-ss010824 using htb 3.6-020525 package, and everything seemed fine. did I miss something? __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From blackoutz@yahoo.com Mon Aug 19 12:33:37 2002 From: blackoutz@yahoo.com (zain arrifa'i) Date: Mon, 19 Aug 2002 04:33:37 -0700 (PDT) Subject: [LARTC] Strange Class-Filter behavior.. Message-ID: <20020819113337.32379.qmail@web40209.mail.yahoo.com> I read on the HTB homepage that tc filter has a bug when which causes duplicate entries to be listed by "tc filter show" when we use U32 classifiers with different prio values. OK. But then my case was more than that. First, I have 1280kbit link split into 3 classes serving 3 subnet. I put SSH traffic into default class with different prio, because those 3 classes are would be heavily loaded, and I think the default class would be sufficient for the ssh traffic to and from all directions.(see script below). everything worked fine. and then I got 4th customer/subnet. I increased my link to 1792kbit and assign 512kbit to it. the script is the same script I used before. Just add an additional class (1:13) , along with corresponding filter and leaf needed. here, I found that traffic for the 4th subnet didn't get into the slot where it should be. I did download tests with big ftp/scp, but from the "tc -s class show dev eth1" command, I see class 1:13 didn't send packets. the scp/ftp stalled then. the "tc filter show" command resulted duplicate entries for each pref. I then tried to not putting the SSH filter, and all four classes worked fine, delivering packets correctly as the filters said. I've tried to put prio value into the filter rules (instead the class) and vice versa, I've tried to assign all classes the same prio, I've tried other match methods for SSH filter, I've tried to put "ip address match" in addition to the "ip tos match" (thus 4 filter for SSH), only to no avail. unless the SSH filter removed, The class 1:13 didn't send packets in amount it should be. (just sent few pakets, fewer than the default). weird is the first three classes seemed fine from what listed in "tc -s class show" result. so is the actual traffic. I got my scp/ftp test for these three classes was OK. why? did I make any mistakes? any suggestions would be much appreciated. here is the currently "strange" script: --------------------------------------------------- tc qdisc add dev eth1 root handle 1: htb default 90 tc class add dev eth1 parent 1: classid 1:1 htb rate 1792kbit ceil 1792kbit tc class add dev eth1 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbit prio 2 tc class add dev eth1 parent 1:1 classid 1:11 htb rate 384kbit ceil 384kbit prio 2 tc class add dev eth1 parent 1:1 classid 1:12 htb rate 384kbit ceil 384kbit prio 2 tc class add dev eth1 parent 1:1 classid 1:13 htb rate 512kbit ceil 512kbit prio 2 tc class add dev eth1 parent 1:1 classid 1:90 htb rate 48kbit ceil 48kbit prio 1 tc filter add dev eth1 protocol ip parent 1:0 u32 \ match ip dst 202.59.196.192/28 flowid 1:10 tc filter add dev eth1 protocol ip parent 1:0 u32 \ match ip dst 202.59.196.208/28 flowid 1:11 tc filter add dev eth1 protocol ip parent 1:0 u32 \ match ip dst 202.59.206.0/27 flowid 1:12 tc filter add dev eth1 protocol ip parent 1:0 u32 \ match ip dst 202.59.196.224/28 flowid 1:13 tc filter add dev eth1 protocol ip parent 1:0 u32 \ match ip tos 0x10 0xff flowid 1:90 tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 1:11 handle 11: sfq perturb 10 tc qdisc add dev eth1 parent 1:12 handle 12: sfq perturb 10 tc qdisc add dev eth1 parent 1:13 handle 13: sfq perturb 10 tc qdisc add dev eth1 parent 1:90 handle 90: sfq perturb 10 ------------------------------------------------- I patched and recompiled the RedHat 7.3 kernel sources (2.4.18) and iproute2-2.4.7-now-ss010824 and found no errors. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From elacour@easter-eggs.com Mon Aug 19 17:29:29 2002 From: elacour@easter-eggs.com (Emmanuel Lacour) Date: Mon, 19 Aug 2002 18:29:29 +0200 Subject: [LARTC] Limit bandwidth for ipsec vpns Message-ID: <20020819162929.GO19138@easter-eggs.com> Hi everybody, Is there anyone having an idea on how to limit bandwidth on a linux gw doing vpns with freeswan, I.E. for a 1Mbit line with 1 ipsec tunnel on interface ppp0, limiting vpn traffic (esp) to 512kbit and internet traffic (non vpn) to 512kbit. Thanks in advance! Manu. -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 mailto:elacour@easter-eggs.com - http://www.easter-eggs.com From mgraupe@web.de Mon Aug 19 17:39:44 2002 From: mgraupe@web.de (Michael Graupner) Date: Mon, 19 Aug 2002 18:39:44 +0200 Subject: [LARTC] gateway problems Message-ID: <3D611F50.8020007@web.de> Hello! I am trying to set up a local network consisting out of two laptops under SuSE 8.0 (kernel 2.4.18). The modem on my laptop is not working unde r linux, so I want to use the other computer as a gateway. After dialing in via modem on the other laptop, the routing tables are looking like the following: - computer 1 (141.30.17.252): Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 141.30.17.252 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 141.30.17.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 141.30.17.253 0.0.0.0 UG 0 0 0 eth0 - computer 2 gateway (141.30.17.253): Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.104.204.34 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 141.30.17.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 62.104.204.34 0.0.0.0 UG 0 0 0 ppp0 From 141.30.17.252 I am able to connect to 141.30.17.253 in our local network, but I do not have access to the outer space. I even cannot ping to 62.104.204.34. On 141.30.17.252 I have a pcmcia network card and the other computer has a internal network card. I am running out of idea s how to get the network working and would appreciate all suggestions. Michael. From stef.coene@docum.org Mon Aug 19 18:01:32 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 19 Aug 2002 19:01:32 +0200 Subject: [LARTC] Limit bandwidth for ipsec vpns In-Reply-To: <20020819162929.GO19138@easter-eggs.com> References: <20020819162929.GO19138@easter-eggs.com> Message-ID: <20020819170133.33E9BDBB44@tartarus.telenet-ops.be> On Monday 19 August 2002 18:29, Emmanuel Lacour wrote: > Hi everybody, > > > Is there anyone having an idea on how to limit bandwidth on a linux gw > doing vpns with freeswan, I.E. for a 1Mbit line with 1 ipsec tunnel on > interface ppp0, limiting vpn traffic (esp) to 512kbit and internet > traffic (non vpn) to 512kbit. > > > Thanks in advance! More info about shaping can be found on www.lartc.org. And I have some e= xtra=20 information on www.docum.org. You have to add a cbq or htb qdisc to your interfaces and create 2 classe= s. =20 One for vpn traffic and one for non vpn traffic. I hope that you use fix= ed=20 ports for the vpn traffic so you can use the dst/src port as a filter key= =2E =20 You can share the same 1mbit or you can limit each class to 512kbit. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From amitk@ittc.ku.edu Mon Aug 19 18:47:35 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Mon, 19 Aug 2002 12:47:35 -0500 (CDT) Subject: [LARTC] HTB3 port for 2.2.18? In-Reply-To: Message-ID: I would be interested in getting the patches for 2.2.21. Thanks. - Amit On Fri, 17 Aug 2002, Julian Anastasov wrote: >> Is there an HTB3 port for 2.2.18? >> > Yes, I have backported the net/sched from 2.4.20pre1 to 2.2.21, > including HTB3. The simple tests look good, the problem is that I > still have problems updating/accessing my site. I can provide my > "DS-9" tree to anyone interested in testing and hosting the files. -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From mbabcock@fibrespeed.net Mon Aug 19 19:28:34 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Mon, 19 Aug 2002 14:28:34 -0400 Subject: [LARTC] Limit bandwidth for ipsec vpns In-Reply-To: <20020819170133.33E9BDBB44@tartarus.telenet-ops.be> References: <20020819162929.GO19138@easter-eggs.com> <20020819170133.33E9BDBB44@tartarus.telenet-ops.be> Message-ID: <20020819182834.GD9987@godzilla.fibrespeed.net> On Mon, Aug 19, 2002 at 07:01:32PM +0200, Stef Coene wrote: > > Is there anyone having an idea on how to limit bandwidth on a linux gw > > doing vpns with freeswan, I.E. for a 1Mbit line with 1 ipsec tunnel on > > interface ppp0, limiting vpn traffic (esp) to 512kbit and internet > > traffic (non vpn) to 512kbit. > More info about shaping can be found on www.lartc.org. And I have some extra > information on www.docum.org. > > You have to add a cbq or htb qdisc to your interfaces and create 2 classes. > One for vpn traffic and one for non vpn traffic. I hope that you use fixed > ports for the vpn traffic so you can use the dst/src port as a filter key. > You can share the same 1mbit or you can limit each class to 512kbit. If FreeS/WAN is used, adding a pair of classes to the external interface for 'normal' and 'VPN' traffic should suffice. VPN traffic is identifiable as traffic over UDP port 500 and protocols 50 or 51, although you may wish to give them their own class with high priority as they do key exchanges. If you gave each 512kbps, then add a root class to ipsec0 of 512kbps and work from there on it. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ From stef.coene@docum.org Mon Aug 19 19:42:16 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 19 Aug 2002 20:42:16 +0200 Subject: [LARTC] gateway problems In-Reply-To: <3D611F50.8020007@web.de> References: <3D611F50.8020007@web.de> Message-ID: <20020819184217.5605EDB9DB@tartarus.telenet-ops.be> > I am trying to set up a local network consisting out of two laptops > under SuSE 8.0 (kernel 2.4.18). The modem on my laptop is not working u= nde > r linux, so I want to use the other computer as a gateway. After dialin= g > in via modem on the other laptop, the routing > tables are looking like the following: > > - computer 1 (141.30.17.252): > Kernel IP Routentabelle > Ziel Router Genmask Flags Metric Ref Use > Iface > 141.30.17.252 0.0.0.0 255.255.255.255 UH 0 0 0 > eth0 141.30.17.0 0.0.0.0 255.255.255.0 U 0 0 = =20 > 0 eth0 0.0.0.0 141.30.17.253 0.0.0.0 UG 0 0 = =20 > 0 eth0 > > - computer 2 gateway (141.30.17.253): > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 62.104.204.34 0.0.0.0 255.255.255.255 UH 0 0 0 > ppp0 141.30.17.0 0.0.0.0 255.255.255.0 U 0 0 = =20 > 0 eth0 0.0.0.0 62.104.204.34 0.0.0.0 UG 0 0 = =20 > 0 ppp0 > > From 141.30.17.252 I am able to connect to 141.30.17.253 in our local > network, but I do not have access to the outer space. I even cannot pin= g > to 62.104.204.34. On 141.30.17.252 I have a pcmcia network card and th= e > other computer has a internal network card. I am running out of idea > s how to get the network working and would appreciate all suggestions. > Michael. Have you a kernel with ip forwarding and have you enabled it ? echo "1" > /proc/sys/net/ipv4/ip_forward And have you same basic masquing rules ? iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From patrick_chan@mtelnet.com Tue Aug 20 03:02:34 2002 From: patrick_chan@mtelnet.com (Patrick Chan) Date: Tue, 20 Aug 2002 10:02:34 +0800 Subject: [LARTC] Priority Queueing Message-ID: <80313B62CF86B749B7C416579F3944980FD854@mail.mtel> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C247ED.A6B58390 Content-Type: text/plain; charset="iso-8859-1" Dear all, How can I do priority queueing in Linux? Should I use PRIO qdisc? Can anyone give me an example on priority queueing? P.S. Priority Queueing is to classify packets into high and low queue, high queue packets always dequeue first before low queue. Patrick ------_=_NextPart_001_01C247ED.A6B58390 Content-Type: text/html; charset="iso-8859-1" Priority Queueing

Dear all,

How can I do priority queueing in Linux?
Should I use PRIO qdisc?
Can anyone give me an example on priority queueing?

P.S. Priority Queueing is to classify packets into high and low queue,
high queue packets always dequeue first before low queue.

Patrick

------_=_NextPart_001_01C247ED.A6B58390-- From mikep02@softerware.com Tue Aug 20 05:34:41 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Tue, 20 Aug 2002 00:34:41 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #726 - 11 msgs Message-ID: <1551405451@softerware.com> --MIME MULTIPART BOUNDARY=.1029818107:+'1 Content-Type: application/octet-stream Content-Id: <1551405451-2@softerware.com> Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Text Item" U2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCglsYXJ0Y0BtYWlsbWFuLmRz OWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBX ZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRj DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVs cCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5ubA0KDQpZb3UgY2FuIHJlYWNoIHRo ZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0Yy1hZG1pbkBtYWlsbWFuLmRzOWEu bmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQg aXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIExBUlRDIGRpZ2VzdC4uLiIN Cg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IExBUlRDIGRpZ2VzdCwgVm9sIDEgIzcy NSAtIDIgbXNncyAobWlrZXAwMkBzb2Z0ZXJ3YXJlLmNvbSkNCiAgIDIuIFRDIHN0YXJ0L3N0b3Ag UHJvYmxlbSAoemFpbiBhcnJpZmEnaSkNCiAgIDMuIEhUQiAzLjYtMDIwNTI1LWVycm9yIHN0aWxs ICh6YWluIGFycmlmYSdpKQ0KICAgNC4gU3RyYW5nZSBDbGFzcy1GaWx0ZXIgYmVoYXZpb3IuLiAo emFpbiBhcnJpZmEnaSkNCiAgIDUuIExpbWl0IGJhbmR3aWR0aCBmb3IgaXBzZWMgdnBucyAoRW1t YW51ZWwgTGFjb3VyKQ0KICAgNi4gZ2F0ZXdheSBwcm9ibGVtcyAoTWljaGFlbCBHcmF1cG5lcikN CiAgIDcuIFJlOiBMaW1pdCBiYW5kd2lkdGggZm9yIGlwc2VjIHZwbnMgKFN0ZWYgQ29lbmUpDQog ICA4LiBSZTogSFRCMyBwb3J0IGZvciAyLjIuMTg/IChBbWl0IEt1Y2hlcmlhKQ0KICAgOS4gUmU6 IExpbWl0IGJhbmR3aWR0aCBmb3IgaXBzZWMgdnBucyAoTWljaGFlbCBULiBCYWJjb2NrKQ0KICAx MC4gUmU6IGdhdGV3YXkgcHJvYmxlbXMgKFN0ZWYgQ29lbmUpDQogIDExLiBQcmlvcml0eSBRdWV1 ZWluZyAoUGF0cmljayBDaGFuKQ0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDENCkRhdGU6IE1v biwgMTkgQXVnIDIwMDIgMDA6Mjk6MjYgLTA0MDANClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwN CkZyb206IG1pa2VwMDJAc29mdGVyd2FyZS5jb20NClJlcGx5LVRvOiBtaWtlcDAyQHNvZnRlcndh cmUuY29tDQpTdWJqZWN0OiBbTEFSVENdIFJlOiBMQVJUQyBkaWdlc3QsIFZvbCAxICM3MjUgLSAy IG1zZ3MNCg0KSSB3aWxsIGJlIG91dCBvZiB0aGUgb2ZmaWNlIGZyb20gOC8xOSB1bnRpbCA4LzIz LiAgSSB3aWxsIGJlIHJldHVybmluZyBvbiBNb25kYXkNCmFmdGVybm9vbiwgOC8yNiwgYW5kIHdp bGwgcmVwbHkgdGhlbi4NCg0KVGhhbmsgeW91LA0KDQpNaWNoYWVsIFBlbGxlZ3Jpbm8NClNvZnRl cndhcmUsIEluYy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdWJqZWN0OiBMQVJUQyBkaWdlc3Qs IFZvbCAxICM3MjUgLSAyIG1zZ3MNCkZyb206IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KRGF0ZTog MDgvMTkvMDIgMDE6Mjc6MzkNCg0KU2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMg dG8NCglsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJl IHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9t YWlsbWFuL2xpc3RpbmZvL2xhcnRjDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRo IHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5u bA0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0 Yy1hZG1pbkBtYWlsbWFuLmRzOWEubmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91 ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRz IG9mIExBUlRDIGRpZ2VzdC4uLiINCg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gVm9JUCBh bmQgUW9TIChQYXRyaWNrIENoYW4pDQogICAyLiBSZTogZmlsdGVyIGluLWNhY2hlIHRyYWZmaWMg IHdpdGggdGMgKEFsZXhleSBUYWxpa292KQ0KDQotLSBfXy0tX18tLSANCg0KTWVzc2FnZTogMQ0K RnJvbTogUGF0cmljayBDaGFuIDxwYXRyaWNrX2NoYW5AbXRlbG5ldC5jb20+DQpUbzogbGFydGNA bWFpbG1hbi5kczlhLm5sDQpEYXRlOiBNb24sIDE5IEF1ZyAyMDAyIDEwOjAxOjE4ICswODAwDQpT dWJqZWN0OiBbTEFSVENdIFZvSVAgYW5kIFFvUw0KDQpUaGlzIG1lc3NhZ2UgaXMgaW4gTUlNRSBm b3JtYXQuIFNpbmNlIHlvdXIgbWFpbCByZWFkZXIgZG9lcyBub3QgdW5kZXJzdGFuZA0KdGhpcyBm b3JtYXQsIHNvbWUgb3IgYWxsIG9mIHRoaXMgbWVzc2FnZSBtYXkgbm90IGJlIGxlZ2libGUuDQoN Ci0tLS0tLV89X05leHRQYXJ0XzAwMV8wMUMyNDcyNC40RUZBMzM5MA0KQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQoNClRoZXJlIGFyZSB0d28gTGludXgg cm91dGVycywgYSA2NEsgbGVhc2VkIGxpbmUgaXMgdXNlZA0KdG8gY29ubmVjdCB0aGVzZSB0d28g bWFjaGluZXMuIE5vdywgd2Ugd291bGQgbGlrZSB0byBydW4NClZvaWNlIG92ZXIgSVAgYmV0d2Vl biB0d28gbWFjaGluZXMuIFdlIGhhdmUgdG8gcnVuIFFvUyBhbmQgDQp0YWcgdm9pY2UgcGFja2V0 J3MgVE9TIGZpZWxkLA0Kb3RoZXJ3aXNlLCB0aGUgdm9pY2UgcXVhbGl0eSBpcyB0ZXJyaWJsZSBp ZiB3ZSB0cmFuc2ZlciBmaWxlDQphbmQgbWFrZSB2b2ljZSBjYWxsIGF0IHRoZSBzYW1lIHRpbWUu DQoNCkkgYW0gbm90IGZhbWlsaWFyIHdpdGggdGMgaW4gTGludXguIEJ1dCBJIGhhdmUgY29waWVk IGEgc2NyaXB0DQpmcm9tIExBUlRDIGFyY2hpdmVzLiBJZiB0aGUgZm9sbG93aW5nIGNvbmZpZyBp cyB1c2VkLCB0aGUgc2l0dWF0aW9uDQppcyBiZXR0ZXIgdGhhbiBub3RoaW5nIHVzZWQuIFRoZSB2 b2ljZSBwYWNrZXRzIGNhbiBiZSB0YWdnZWQgYXMgDQpUT1M9MHgyMToNCg0KdGMgcWRpc2MgYWRk IGRldiBoZGxjMCBwYXJlbnQgMToxIGhhbmRsZSAyOiBwZmlmbyBsaW1pdCA1MTINCnRjIHFkaXNj IGFkZCBkZXYgaGRsYzAgcGFyZW50IDE6MiBoYW5kbGUgMzogcGZpZm8gbGltaXQgNTEyDQp0YyBx ZGlzYyBhZGQgZGV2IGhkbGMwIHBhcmVudCAxOjMgaGFuZGxlIDQ6IHBmaWZvIGxpbWl0IDUxMg0K dGMgZmlsdGVyIGFkZCBkZXYgaGRsYzAgcGFyZW50IDE6MCBwcm90b2NvbCBpcCBwcmlvIDEgdTMy IGRpdmlzb3IgMQ0KdGMgZmlsdGVyIGFkZCBkZXYgaGRsYzAgcGFyZW50IDE6MCBwcmlvIDEgdTMy IG1hdGNoIGlwIHRvcyAweDIxIDB4ZmYgZmxvd2lkDQoxOjENCg0KSSBkb24ndCBrbm93IHdoYXQg aXQgbWVhbnMgZXhhY3RseS4gQnV0IHRoaXMgaXMgdXNlZCwgdGhlIHZvaWNlIHF1YWxpdHkNCmlz IGJhZCBhdCB0aGUgYmVnaW5uaW5nIHdoZW4gZmlsZSBpcyB0cmFuc2ZlcnJlZC4gVGhlIHZvaWNl IHF1YWxpdHkgd2lsbA0KImNvbnZlcmdlIiB0byBiZSBnb29kIGFmdGVyIGFib3V0IDMwIHNlY29u ZHMuDQoNCkhvd2V2ZXIsIHRoaXMgaXMgbm90IGFjY2VwdGFibGUuIENhbiBhbnlvbmUgdGVsbCBt ZSB3aGF0IGlzIHRoZSBiZXN0DQp0YyBjb25maWcgZm9yIHJ1bm5pbmcgVm9JUD8gVGhhbmtzIHZl cnkgbXVjaC4NCg0KLS0tLS0tXz1fTmV4dFBhcnRfMDAxXzAxQzI0NzI0LjRFRkEzMzkwDQpDb250 ZW50LVR5cGU6IHRleHQvaHRtbDsNCgljaGFyc2V0PSJpc28tODg1OS0xIg0KDQo8IURPQ1RZUEUg SFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9FTiI+DQo8SFRNTD4NCjxIRUFEPg0K PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9aXNvLTg4NTktMSI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENPTlRFTlQ9Ik1TIEV4Y2hh bmdlIFNlcnZlciB2ZXJzaW9uIDUuNS4yNjUzLjEyIj4NCjxUSVRMRT5Wb0lQIGFuZCBRb1M8L1RJ VExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGVyZSBhcmUgdHdvIExp bnV4IHJvdXRlcnMsIGEgNjRLIGxlYXNlZCBsaW5lIGlzIHVzZWQ8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPnRvIGNvbm5lY3QgdGhlc2UgdHdvIG1hY2hpbmVzLiBOb3csIHdlIHdvdWxkIGxpa2Ug dG8gcnVuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Wb2ljZSBvdmVyIElQIGJldHdlZW4gdHdv IG1hY2hpbmVzLiBXZSBoYXZlIHRvIHJ1biBRb1MgYW5kIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+dGFnIHZvaWNlIHBhY2tldCdzIFRPUyBmaWVsZCw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y Pm90aGVyd2lzZSwgdGhlIHZvaWNlIHF1YWxpdHkgaXMgdGVycmlibGUgaWYgd2UgdHJhbnNmZXIg ZmlsZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YW5kIG1ha2Ugdm9pY2UgY2FsbCBhdCB0aGUg c2FtZSB0aW1lLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgYW0gbm90IGZhbWls aWFyIHdpdGggdGMgaW4gTGludXguIEJ1dCBJIGhhdmUgY29waWVkIGEgc2NyaXB0PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5mcm9tIExBUlRDIGFyY2hpdmVzLiBJZiB0aGUgZm9sbG93aW5nIGNv bmZpZyBpcyB1c2VkLCB0aGUgc2l0dWF0aW9uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5pcyBi ZXR0ZXIgdGhhbiBub3RoaW5nIHVzZWQuIFRoZSB2b2ljZSBwYWNrZXRzIGNhbiBiZSB0YWdnZWQg YXMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UT1M9MHgyMTo8L0ZPTlQ+DQo8L1A+DQoNCjxQ PjxGT05UIFNJWkU9Mj50YyBxZGlzYyBhZGQgZGV2IGhkbGMwIHBhcmVudCAxOjEgaGFuZGxlIDI6 IHBmaWZvIGxpbWl0IDUxMjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGMgcWRpc2MgYWRkIGRl diBoZGxjMCBwYXJlbnQgMToyIGhhbmRsZSAzOiBwZmlmbyBsaW1pdCA1MTI8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPnRjIHFkaXNjIGFkZCBkZXYgaGRsYzAgcGFyZW50IDE6MyBoYW5kbGUgNDog cGZpZm8gbGltaXQgNTEyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50YyBmaWx0ZXIgYWRkIGRl diBoZGxjMCBwYXJlbnQgMTowIHByb3RvY29sIGlwIHByaW8gMSB1MzIgZGl2aXNvciAxPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50YyBmaWx0ZXIgYWRkIGRldiBoZGxjMCBwYXJlbnQgMTowIHBy aW8gMSB1MzIgbWF0Y2ggaXAgdG9zIDB4MjEgMHhmZiBmbG93aWQgMToxPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SSBkb24ndCBrbm93IHdoYXQgaXQgbWVhbnMgZXhhY3RseS4gQnV0 IHRoaXMgaXMgdXNlZCwgdGhlIHZvaWNlIHF1YWxpdHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PmlzIGJhZCBhdCB0aGUgYmVnaW5uaW5nIHdoZW4gZmlsZSBpcyB0cmFuc2ZlcnJlZC4gVGhlIHZv aWNlIHF1YWxpdHkgd2lsbDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+JnF1b3Q7Y29udmVyZ2Um cXVvdDsgdG8gYmUgZ29vZCBhZnRlciBhYm91dCAzMCBzZWNvbmRzLi48L0ZPTlQ+DQo8L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj5Ib3dldmVyLCB0aGlzIGlzIG5vdCBhY2NlcHRhYmxlLiBDYW4gYW55 b25lIHRlbGwgbWUgd2hhdCBpcyB0aGUgYmVzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGMg Y29uZmlnIGZvciBydW5uaW5nIFZvSVA/IFRoYW5rcyB2ZXJ5IG11Y2guPC9GT05UPg0KPC9QPg0K DQo8L0JPRFk+DQo8L0hUTUw+DQotLS0tLS1fPV9OZXh0UGFydF8wMDFfMDFDMjQ3MjQuNEVGQTMz OTAtLQ0KDQotLSBfXy0tX18tLSANCg0KTWVzc2FnZTogMg0KRGF0ZTogTW9uLCAxOSBBdWcgMjAw MiAwOTowNToxMiArMDUwMA0KRnJvbTogQWxleGV5IFRhbGlrb3YgPGFsZXhleV90YWxpa292QHRl eGxhYi5jb20udXo+DQpSZXBseS1UbzogQWxleGV5IFRhbGlrb3YgPGFsZXhleV90YWxpa292QHRl eGxhYi5jb20udXo+DQpPcmdhbml6YXRpb246IEZvcnRlaw0KVG86IEZhYmlhbiBHZXJ2YW4gPGZh YmlhbjFAaW50ZXItay5jb20uYXI+DQpDYzogbGFydGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0 OiBSZTogW0xBUlRDXSBmaWx0ZXIgaW4tY2FjaGUgdHJhZmZpYyAgd2l0aCB0Yw0KDQpIZWxsbyBG YWJpYW4sDQpJIHJlY29tZW5kIHlvdSB1c2Ugc3F1aWQgZGVsYXkgcG9vbHMgb3IgV1JSIHFkaXNj IHdpdGggcGF0Y2ggZm9yDQpzcXVpZC4NCnNlZSB0aGlzIGxpbmtzDQpodHRwOi8vd2lwbC13cnIu c291cmNlZm9yZ2UubmV0Lw0KaHR0cDovL3NxdWlkLWRvY3Muc291cmNlZm9yZ2UubmV0L2xhdGVz dC9odG1sL3gyMTE2Lmh0bWwNCg0KDQpNb25kYXksIEF1Z3VzdCAxOSwgMjAwMiwgNzozMTowNSBB TSwgeW91IHdyb3RlOg0KDQpGRz4gSGVsbG8gbGFydGMsIEkgYW0gdXNpbmcgc3F1aWQgaW4gdHJh bnNwYXJlbnQgbW9kZSwgYW5kIGJhbmR3aXRoIGNvbnRyb2wNCkZHPiB3aXRoIHRjIChodGIpLiAo cmVkaGF0IDcuMykuDQpGRz4gQ3VycmVudGx5IEkgbWFyayBwYWNrZXRzIGNvbW1pbmcgZnJvbSAz MTI4IChzcXVpZA0KRkc+IHBvcnQpIHRvIHVzZXJzLCB0aGVyZSBhcmUgYW55IHdheSB0byBmaWx0 ZXIgdGhlIHRyYWZpYyBpZiB0aGUgb2JqZWN0DQpGRz4gdGhhdCB1c2VyIHJlcXVlc3QgYWxyZWF5 IGlzIGluIHRoZSBzcXVpZCBjYWNoZSAoaGl0KT8NCkZHPiBzb3JyeSBmb3IgbXkgZW5nbGlzaC4N Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KbWFpbHRvOmFsZXhleV90 YWxpa292QHRleGxhYi5jb20udXoNCkJSDQpBbGV4ZXkgVGFsaWtvdg0KRk9SVEVLDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0gX18tLV9fLS0gDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMQVJUQyBtYWlsaW5n IGxpc3QNCkxBUlRDQG1haWxtYW4uZHM5YS5ubA0KaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWls bWFuL2xpc3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9mIExBUlRDIERpZ2VzdA0KDQoNCg0KLS1fXy0t X18tLQ0KDQpNZXNzYWdlOiAyDQpEYXRlOiBNb24sIDE5IEF1ZyAyMDAyIDAzOjAxOjAzIC0wNzAw IChQRFQpDQpGcm9tOiB6YWluIGFycmlmYSdpIDxibGFja291dHpAeWFob28uY29tPg0KVG86IGxh cnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogW0xBUlRDXSBUQyBzdGFydC9zdG9wIFByb2Js ZW0NCg0KSSBoYXZlIGludGVybmV0IGNvbm5lY3Rpb24gd2l0aCAxLDcgbWJpdCBkb3duIGFuZCA1 MTINCmtiaXQgdXAgY3VycmVudGx5IHNlcnZpbmcgc2V2ZXJhbCBjb3Jwb3JhdGUvY29sbGVnZQ0K bGFicywgd2hpY2ggaXMgZnVsbHkgbG9hZGVkIG1vc3Qgb2YgdGhlIHRpbWUuDQoNCmluIG15IHNo YXBlciBib3ggbG9jYXRlZCBpbiByZW1vdGUgc2l0ZSwgSSBoYXZlIG15IEhUQg0KdGNzY3JpcHQg dGhhdCBzaW1wbHkgY3JlYXRlcyB0aGUgcWRpc2NzLCBjbGFzc2VzIGFuZA0KZmlsdGVycyB1cG9u IGV4ZWN1dGlvbi4NCkkgYWxzbyBoYXZlIGEgc2NyaXB0ICh0Y3N0b3ApIGNvbnRhaW5pbmc6DQoN CnJtbW9kIHNjaF9odGINCnJtbW9kIHNjaF9zZnENCnJtbW9kIGNsc191MzINCnRjIHFkaXNjIGRl bCByb290IGRldiBldGgwDQp0YyBxZGlzYyBkZWwgcm9vdCBkZXYgZXRoMQ0KDQpmb3IgcmVsZWFz aW5nIHRoZSB0cmFmZmljIGNvbnRyb2wuDQoNCnByb2JsZW0gaXMgOiBJIG5lZWQgdG8gbWFrZSBj aGFuZ2VzIHRvIG15IHN0YXJ0DQpzY3JpcHQsIHNvIEkgZXhlY3V0ZSB0aGUgdGNzdG9wIHNjcmlw dCwgZWRpdCB0aGUNCnRjc3RhcnQgc2NyaXB0IGEgbGl0dGxlLCBleGVjdXRlIGl0LCBhbmQgYm9v bS4gTXkNCnNoYXBlcmJveCBkaXNjb25uZWN0ZWQgZnJvbSB0aGUgcmVzdCBvZiB0aGUgbmV0Lg0K c2luY2UgbXkgc2hhcGVyYm94IGlzIHBsYWNlZCByaWdodCBiZWZvcmUgdGhlDQpnYXRld2F5L1dB TiByb3V0ZXIsIHdlIGFsbCBnb3QgZGlzY29ubmVjdGVkLg0KDQp3aGVuIEkgY2FtZSB0byB0aGUg c2hhcGVyYm94LCBpdCBkaWRuJ3QgY3Jhc2ggb3IgaGFuZywNCml0IGlzIGp1c3QgZGlzY29ubmVj dGVkLiBhbmQgSSBjb3VsZG4ndCBmaW5kIGFueQ0Kc3VzcGljaW91cyBsb2cgcmVsYXRlZCB0byB0 aGF0Lg0KDQpJdCBkaWRuJ3QgaGFwcGVuIGFsbCB0aGUgdGltZXMgKGFib3V0IDEgb3V0IG9mIDUp IGJ1dA0KcXVpdGUgYW5ub3lpbmcuDQphbnlvbmUgaGF2ZSBhbnkgaWRlYSBhYm91dCB0aGF0PyBi ZWNhdXNlIEkgc3RpbGwgY2FuJ3QNCmZpZ3VyZWQgb3V0IHdoeS4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRvIFlvdSBZYWhvbyE/DQpIb3RK b2JzIC0gU2VhcmNoIFRob3VzYW5kcyBvZiBOZXcgSm9icw0KaHR0cDovL3d3dy5ob3Rqb2JzLmNv bQ0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDMNCkRhdGU6IE1vbiwgMTkgQXVnIDIwMDIgMDM6 MTc6MzUgLTA3MDAgKFBEVCkNCkZyb206IHphaW4gYXJyaWZhJ2kgPGJsYWNrb3V0ekB5YWhvby5j b20+DQpUbzogbGFydGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0OiBbTEFSVENdIEhUQiAzLjYt MDIwNTI1LWVycm9yIHN0aWxsDQoNCkkgYWx3YXlzIGdvdCBtZXNzYWdlcyBsaWtlIHRoaXMgd2hl biBJIHN0YXJ0IG15IHRjDQpzY3JpcHQ6DQoNCkF1ZyAxOSAxMToxMDowMyB5Z2dkcmFzaWwga2Vy bmVsOiBodGI6IGFzc2VydGlvbiAoY2wNCiYmIGNsLT51bi5sZWFmLnEtPnEucWxlbikgZmFpbGVk IGF0IHNjaF9odGIuYyg5NCAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICA5KQ0KQXVnIDE5 IDExOjEwOjAzIHlnZ2RyYXNpbCBrZXJuZWw6IGh0YjogY2xhc3MgMTAwMTQNCmlzbid0IHdvcmsg Y29uc2VydmluZyA/IQ0KQXVnIDE5IDExOjEwOjAzIHlnZ2RyYXNpbCBrZXJuZWw6IEtFUk5FTDog YXNzZXJ0aW9uDQooY2wgJiYgY2wtPnVuLmxlYWYucS0+cS5xbGVuICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICkgZmFpbGVkIGF0IHNjaF9odGIuYyg5NDkpDQpBdWcgMTkgMTE6MTA6MDQg eWdnZHJhc2lsIGxhc3QgbWVzc2FnZSByZXBlYXRlZCA0ODcNCnRpbWVzDQoNCndlaXJkIGlzLCB0 aGUgdGMgcnVsZXMgdGhlbXNlbHZlcyBzdGlsbCBydW5uaW5nLg0KIA0KSSBwYXRjaGVkIGFuZCBy ZWNvbXBpbGVkIG15IGtlcm5lbCAoMi40LjE4KSBhbmQgaXANCnJvdXRlMi0yLjQuNy1ub3ctc3Mw MTA4MjQgdXNpbmcgaHRiIDMuNi0wMjA1MjUNCnBhY2thZ2UsIGFuZCBldmVyeXRoaW5nIHNlZW1l ZCBmaW5lLg0KDQpkaWQgSSBtaXNzIHNvbWV0aGluZz8NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG8gWW91IFlhaG9vIT8NCkhvdEpvYnMg LSBTZWFyY2ggVGhvdXNhbmRzIG9mIE5ldyBKb2JzDQpodHRwOi8vd3d3LmhvdGpvYnMuY29tDQoN Ci0tX18tLV9fLS0NCg0KTWVzc2FnZTogNA0KRGF0ZTogTW9uLCAxOSBBdWcgMjAwMiAwNDozMzoz NyAtMDcwMCAoUERUKQ0KRnJvbTogemFpbiBhcnJpZmEnaSA8YmxhY2tvdXR6QHlhaG9vLmNvbT4N ClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFtMQVJUQ10gU3RyYW5nZSBDbGFz cy1GaWx0ZXIgYmVoYXZpb3IuLg0KDQpJIHJlYWQgb24gdGhlIEhUQiBob21lcGFnZSB0aGF0IHRj IGZpbHRlciBoYXMgYSBidWcNCndoZW4gd2hpY2ggY2F1c2VzIGR1cGxpY2F0ZSBlbnRyaWVzIHRv IGJlIGxpc3RlZCBieQ0KInRjIGZpbHRlciBzaG93IiB3aGVuIHdlIHVzZSBVMzIgY2xhc3NpZmll cnMgd2l0aA0KZGlmZmVyZW50IHByaW8gdmFsdWVzLiBPSy4NCkJ1dCB0aGVuIG15IGNhc2Ugd2Fz IG1vcmUgdGhhbiB0aGF0Lg0KDQpGaXJzdCwgSSBoYXZlIDEyODBrYml0IGxpbmsgc3BsaXQgaW50 byAzIGNsYXNzZXMNCnNlcnZpbmcgMyBzdWJuZXQuIEkgcHV0IFNTSCB0cmFmZmljIGludG8gZGVm YXVsdCBjbGFzcw0Kd2l0aCBkaWZmZXJlbnQgcHJpbywgYmVjYXVzZSB0aG9zZSAzIGNsYXNzZXMg YXJlIHdvdWxkDQpiZSBoZWF2aWx5IGxvYWRlZCwgYW5kIEkgdGhpbmsgdGhlIGRlZmF1bHQgY2xh c3Mgd291bGQNCmJlIHN1ZmZpY2llbnQgZm9yIHRoZSBzc2ggdHJhZmZpYyB0byBhbmQgZnJvbSBh bGwNCmRpcmVjdGlvbnMuKHNlZSBzY3JpcHQgYmVsb3cpLg0KZXZlcnl0aGluZyB3b3JrZWQgZmlu ZS4NCmFuZCB0aGVuIEkgZ290IDR0aCBjdXN0b21lci9zdWJuZXQuIEkgaW5jcmVhc2VkIG15DQps aW5rIHRvIDE3OTJrYml0IGFuZCBhc3NpZ24gNTEya2JpdCB0byBpdC4NCnRoZSBzY3JpcHQgaXMg dGhlIHNhbWUgc2NyaXB0IEkgdXNlZCBiZWZvcmUuIEp1c3QgYWRkDQphbiBhZGRpdGlvbmFsIGNs YXNzICgxOjEzKSAsIGFsb25nIHdpdGggY29ycmVzcG9uZGluZw0KZmlsdGVyIGFuZCBsZWFmIG5l ZWRlZC4NCg0KaGVyZSwgSSBmb3VuZCB0aGF0IHRyYWZmaWMgZm9yIHRoZSA0dGggc3VibmV0IGRp ZG4ndA0KZ2V0IGludG8gdGhlIHNsb3Qgd2hlcmUgaXQgc2hvdWxkIGJlLiBJIGRpZCBkb3dubG9h ZA0KdGVzdHMgd2l0aCBiaWcgZnRwL3NjcCwgYnV0IGZyb20gdGhlICJ0YyAtcyBjbGFzcyBzaG93 DQpkZXYgZXRoMSIgY29tbWFuZCwgSSBzZWUgY2xhc3MgMToxMyBkaWRuJ3Qgc2VuZA0KcGFja2V0 cy4gdGhlIHNjcC9mdHAgc3RhbGxlZCB0aGVuLg0KdGhlICJ0YyBmaWx0ZXIgc2hvdyIgY29tbWFu ZCByZXN1bHRlZCBkdXBsaWNhdGUNCmVudHJpZXMgZm9yIGVhY2ggcHJlZi4NCg0KSSB0aGVuIHRy aWVkIHRvIG5vdCBwdXR0aW5nIHRoZSBTU0ggZmlsdGVyLCBhbmQgYWxsDQpmb3VyIGNsYXNzZXMg d29ya2VkIGZpbmUsIGRlbGl2ZXJpbmcgcGFja2V0cyBjb3JyZWN0bHkNCmFzIHRoZSBmaWx0ZXJz IHNhaWQuDQpJJ3ZlIHRyaWVkIHRvIHB1dCBwcmlvIHZhbHVlIGludG8gdGhlIGZpbHRlciBydWxl cw0KKGluc3RlYWQgdGhlIGNsYXNzKSBhbmQgdmljZSB2ZXJzYSwgSSd2ZSB0cmllZCB0bw0KYXNz aWduIGFsbCBjbGFzc2VzIHRoZSBzYW1lIHByaW8sIEkndmUgdHJpZWQgb3RoZXINCm1hdGNoIG1l dGhvZHMgZm9yIFNTSCBmaWx0ZXIsIEkndmUgdHJpZWQgdG8gcHV0ICJpcA0KYWRkcmVzcyBtYXRj aCIgaW4gYWRkaXRpb24gdG8gdGhlICJpcCB0b3MgbWF0Y2giDQoodGh1cyA0IGZpbHRlciBmb3Ig U1NIKSwgb25seSB0byBubyBhdmFpbC4NCnVubGVzcyB0aGUgU1NIIGZpbHRlciByZW1vdmVkLCBU aGUgY2xhc3MgMToxMyBkaWRuJ3QNCnNlbmQgcGFja2V0cyBpbiBhbW91bnQgaXQgc2hvdWxkIGJl LiAoanVzdCBzZW50IGZldw0KcGFrZXRzLCBmZXdlciB0aGFuIHRoZSBkZWZhdWx0KS4NCndlaXJk IGlzIHRoZSBmaXJzdCB0aHJlZSBjbGFzc2VzIHNlZW1lZCBmaW5lIGZyb20gd2hhdA0KbGlzdGVk IGluICJ0YyAtcyBjbGFzcyBzaG93IiByZXN1bHQuIHNvIGlzIHRoZSBhY3R1YWwNCnRyYWZmaWMu IEkgZ290IG15IHNjcC9mdHAgdGVzdCBmb3IgdGhlc2UgdGhyZWUgY2xhc3Nlcw0Kd2FzIE9LLg0K d2h5PyBkaWQgSSBtYWtlIGFueSBtaXN0YWtlcz8NCmFueSBzdWdnZXN0aW9ucyB3b3VsZCBiZSBt dWNoIGFwcHJlY2lhdGVkLiANCmhlcmUgaXMgdGhlIGN1cnJlbnRseSAic3RyYW5nZSIgc2NyaXB0 Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp0 YyBxZGlzYyBhZGQgZGV2IGV0aDEgcm9vdCBoYW5kbGUgMTogaHRiIGRlZmF1bHQgOTAgDQoNCnRj IGNsYXNzIGFkZCBkZXYgZXRoMSBwYXJlbnQgMTogY2xhc3NpZCAxOjEgaHRiIHJhdGUNCjE3OTJr Yml0IGNlaWwgMTc5MmtiaXQNCnRjIGNsYXNzIGFkZCBkZXYgZXRoMSBwYXJlbnQgMToxIGNsYXNz aWQgMToxMCBodGIgcmF0ZQ0KNTEya2JpdCBjZWlsIDUxMmtiaXQgcHJpbyAyDQp0YyBjbGFzcyBh ZGQgZGV2IGV0aDEgcGFyZW50IDE6MSBjbGFzc2lkIDE6MTEgaHRiIHJhdGUNCjM4NGtiaXQgY2Vp bCAzODRrYml0IHByaW8gMg0KdGMgY2xhc3MgYWRkIGRldiBldGgxIHBhcmVudCAxOjEgY2xhc3Np ZCAxOjEyIGh0YiByYXRlDQozODRrYml0IGNlaWwgMzg0a2JpdCBwcmlvIDINCnRjIGNsYXNzIGFk ZCBkZXYgZXRoMSBwYXJlbnQgMToxIGNsYXNzaWQgMToxMyBodGIgcmF0ZQ0KNTEya2JpdCBjZWls IDUxMmtiaXQgcHJpbyAyDQp0YyBjbGFzcyBhZGQgZGV2IGV0aDEgcGFyZW50IDE6MSBjbGFzc2lk IDE6OTAgaHRiIHJhdGUNCjQ4a2JpdCBjZWlsIDQ4a2JpdCBwcmlvIDENCg0KdGMgZmlsdGVyIGFk ZCBkZXYgZXRoMSBwcm90b2NvbCBpcCBwYXJlbnQgMTowIHUzMiBcDQptYXRjaCBpcCBkc3QgMjAy LjU5LjE5Ni4xOTIvMjggZmxvd2lkIDE6MTANCnRjIGZpbHRlciBhZGQgZGV2IGV0aDEgcHJvdG9j b2wgaXAgcGFyZW50IDE6MCB1MzIgXA0KbWF0Y2ggaXAgZHN0IDIwMi41OS4xOTYuMjA4LzI4IGZs b3dpZCAxOjExDQp0YyBmaWx0ZXIgYWRkIGRldiBldGgxIHByb3RvY29sIGlwIHBhcmVudCAxOjAg dTMyIFwNCm1hdGNoIGlwIGRzdCAyMDIuNTkuMjA2LjAvMjcgZmxvd2lkIDE6MTINCnRjIGZpbHRl ciBhZGQgZGV2IGV0aDEgcHJvdG9jb2wgaXAgcGFyZW50IDE6MCB1MzIgXA0KbWF0Y2ggaXAgZHN0 IDIwMi41OS4xOTYuMjI0LzI4IGZsb3dpZCAxOjEzDQoNCnRjIGZpbHRlciBhZGQgZGV2IGV0aDEg cHJvdG9jb2wgaXAgcGFyZW50IDE6MCB1MzIgXA0KbWF0Y2ggaXAgdG9zIDB4MTAgMHhmZiBmbG93 aWQgMTo5MA0KDQp0YyBxZGlzYyBhZGQgZGV2IGV0aDEgcGFyZW50IDE6MTAgaGFuZGxlIDEwOiBz ZnENCnBlcnR1cmIgMTANCnRjIHFkaXNjIGFkZCBkZXYgZXRoMSBwYXJlbnQgMToxMSBoYW5kbGUg MTE6IHNmcQ0KcGVydHVyYiAxMA0KdGMgcWRpc2MgYWRkIGRldiBldGgxIHBhcmVudCAxOjEyIGhh bmRsZSAxMjogc2ZxDQpwZXJ0dXJiIDEwDQp0YyBxZGlzYyBhZGQgZGV2IGV0aDEgcGFyZW50IDE6 MTMgaGFuZGxlIDEzOiBzZnENCnBlcnR1cmIgMTANCnRjIHFkaXNjIGFkZCBkZXYgZXRoMSBwYXJl bnQgMTo5MCBoYW5kbGUgOTA6IHNmcQ0KcGVydHVyYiAxMA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSSBwYXRjaGVkIGFuZCByZWNvbXBpbGVkIHRo ZSBSZWRIYXQgNy4zIGtlcm5lbCBzb3VyY2VzDQooMi40LjE4KSBhbmQgaXByb3V0ZTItMi40Ljct bm93LXNzMDEwODI0DQphbmQgZm91bmQgbm8gZXJyb3JzLg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG8gWW91IFlhaG9vIT8NCkhvdEpvYnMg LSBTZWFyY2ggVGhvdXNhbmRzIG9mIE5ldyBKb2JzDQpodHRwOi8vd3d3LmhvdGpvYnMuY29tDQoN Ci0tX18tLV9fLS0NCg0KTWVzc2FnZTogNQ0KRGF0ZTogTW9uLCAxOSBBdWcgMjAwMiAxODoyOToy OSArMDIwMA0KRnJvbTogRW1tYW51ZWwgTGFjb3VyIDxlbGFjb3VyQGVhc3Rlci1lZ2dzLmNvbT4N ClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFtMQVJUQ10gTGltaXQgYmFuZHdp ZHRoIGZvciBpcHNlYyB2cG5zDQoNCkhpIGV2ZXJ5Ym9keSwNCg0KDQpJcyB0aGVyZSBhbnlvbmUg aGF2aW5nIGFuIGlkZWEgb24gaG93IHRvIGxpbWl0IGJhbmR3aWR0aCBvbiBhIGxpbnV4IGd3DQpk b2luZyB2cG5zIHdpdGggZnJlZXN3YW4sIEkuRS4gZm9yIGEgMU1iaXQgbGluZSB3aXRoIDEgaXBz ZWMgdHVubmVsIG9uDQppbnRlcmZhY2UgcHBwMCwgbGltaXRpbmcgdnBuIHRyYWZmaWMgKGVzcCkg dG8gNTEya2JpdCBhbmQgaW50ZXJuZXQNCnRyYWZmaWMgKG5vbiB2cG4pIHRvIDUxMmtiaXQuDQoN Cg0KVGhhbmtzIGluIGFkdmFuY2UhDQoNCk1hbnUuDQoNCg0KLS0gDQpFYXN0ZXItZWdncyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3DpY2lhbGlzdGUgR05VL0xpbnV4DQo0NC00NiBy dWUgZGUgbCdPdWVzdCAgLSAgNzUwMTQgUGFyaXMgICAtICAgRnJhbmNlIC0gIE3pdHJvIEdhaXTp DQpQaG9uZTogKzMzICgwKSAxIDQzIDM1IDAwIDM3ICAgIC0gICAgIEZheDogKzMzICgwKSAxIDQx IDM1IDAwIDc2DQptYWlsdG86ZWxhY291ckBlYXN0ZXItZWdncy5jb20gICAtICAgIGh0dHA6Ly93 d3cuZWFzdGVyLWVnZ3MuY29tDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogNg0KRGF0ZTogTW9u LCAxOSBBdWcgMjAwMiAxODozOTo0NCArMDIwMA0KRnJvbTogTWljaGFlbCBHcmF1cG5lciA8bWdy YXVwZUB3ZWIuZGU+DQpUbzogbGFydGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0OiBbTEFSVENd IGdhdGV3YXkgcHJvYmxlbXMNCg0KSGVsbG8hDQoNCkkgYW0gdHJ5aW5nIHRvIHNldCB1cCBhIGxv Y2FsIG5ldHdvcmsgY29uc2lzdGluZyBvdXQgb2YgdHdvIGxhcHRvcHMgDQp1bmRlciBTdVNFIDgu MCAoa2VybmVsIDIuNC4xOCkuIFRoZSBtb2RlbSBvbiBteSBsYXB0b3AgaXMgbm90IHdvcmtpbmcg dW5kZQ0KciBsaW51eCwgc28gSSB3YW50IHRvIHVzZSB0aGUgb3RoZXIgY29tcHV0ZXIgYXMgYSBn YXRld2F5LiBBZnRlciBkaWFsaW5nIA0KaW4gdmlhIG1vZGVtIG9uIHRoZSBvdGhlciBsYXB0b3As IHRoZSByb3V0aW5nDQp0YWJsZXMgYXJlIGxvb2tpbmcgbGlrZSB0aGUgZm9sbG93aW5nOg0KDQot IGNvbXB1dGVyIDEgKDE0MS4zMC4xNy4yNTIpOg0KS2VybmVsIElQIFJvdXRlbnRhYmVsbGUNClpp ZWwgICAgICAgICAgICBSb3V0ZXIgICAgICAgICAgR2VubWFzayAgICAgICAgIEZsYWdzIE1ldHJp YyBSZWYgICAgVXNlIA0KSWZhY2UNCjE0MS4zMC4xNy4yNTIgICAwLjAuMC4wICAgICAgICAgMjU1 LjI1NS4yNTUuMjU1IFVIICAgIDAgICAgICAwICAgICAgICAwIGV0aDANCjE0MS4zMC4xNy4wICAg ICAwLjAuMC4wICAgICAgICAgMjU1LjI1NS4yNTUuMCAgIFUgICAgIDAgICAgICAwICAgICAgICAw IGV0aDANCjAuMC4wLjAgICAgICAgICAxNDEuMzAuMTcuMjUzICAgMC4wLjAuMCAgICAgICAgIFVH ICAgIDAgICAgICAwICAgICAgICAwIGV0aDANCg0KLSBjb21wdXRlciAyIGdhdGV3YXkgKDE0MS4z MC4xNy4yNTMpOg0KS2VybmVsIElQIHJvdXRpbmcgdGFibGUNCkRlc3RpbmF0aW9uICAgICBHYXRl d2F5ICAgICAgICAgR2VubWFzayAgICAgICAgIEZsYWdzIE1ldHJpYyBSZWYgICAgVXNlIA0KSWZh Y2UNCjYyLjEwNC4yMDQuMzQgICAwLjAuMC4wICAgICAgICAgMjU1LjI1NS4yNTUuMjU1IFVIICAg IDAgICAgICAwICAgICAgICAwIHBwcDANCjE0MS4zMC4xNy4wICAgICAwLjAuMC4wICAgICAgICAg MjU1LjI1NS4yNTUuMCAgIFUgICAgIDAgICAgICAwICAgICAgICAwIGV0aDANCjAuMC4wLjAgICAg ICAgICA2Mi4xMDQuMjA0LjM0ICAgMC4wLjAuMCAgICAgICAgIFVHICAgIDAgICAgICAwICAgICAg ICAwIHBwcDANCg0KIEZyb20gMTQxLjMwLjE3LjI1MiBJIGFtIGFibGUgdG8gY29ubmVjdCB0byAx NDEuMzAuMTcuMjUzIGluIG91ciBsb2NhbCANCm5ldHdvcmssIGJ1dCBJIGRvIG5vdCBoYXZlIGFj Y2VzcyB0byB0aGUgb3V0ZXIgc3BhY2UuIEkgZXZlbiBjYW5ub3QgcGluZw0KIHRvIDYyLjEwNC4y MDQuMzQuIE9uIDE0MS4zMC4xNy4yNTIgSSBoYXZlIGEgcGNtY2lhIG5ldHdvcmsgY2FyZCBhbmQg dGhlIA0Kb3RoZXIgY29tcHV0ZXIgaGFzIGEgaW50ZXJuYWwgbmV0d29yayBjYXJkLiAgSSBhbSBy dW5uaW5nIG91dCBvZiBpZGVhDQpzIGhvdyB0byBnZXQgdGhlIG5ldHdvcmsgd29ya2luZyBhbmQg d291bGQgYXBwcmVjaWF0ZSBhbGwgc3VnZ2VzdGlvbnMuDQpNaWNoYWVsLg0KDQoNCg0KLS1fXy0t X18tLQ0KDQpNZXNzYWdlOiA3DQpGcm9tOiBTdGVmIENvZW5lIDxzdGVmLmNvZW5lQGRvY3VtLm9y Zz4NCk9yZ2FuaXphdGlvbjogTm9uZQ0KVG86IEVtbWFudWVsIExhY291ciA8ZWxhY291ckBlYXN0 ZXItZWdncy5jb20+LCBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFJlOiBbTEFSVENd IExpbWl0IGJhbmR3aWR0aCBmb3IgaXBzZWMgdnBucw0KRGF0ZTogTW9uLCAxOSBBdWcgMjAwMiAx OTowMTozMiArMDIwMA0KDQpPbiBNb25kYXkgMTkgQXVndXN0IDIwMDIgMTg6MjksIEVtbWFudWVs IExhY291ciB3cm90ZToNCj4gSGkgZXZlcnlib2R5LA0KPg0KPg0KPiBJcyB0aGVyZSBhbnlvbmUg aGF2aW5nIGFuIGlkZWEgb24gaG93IHRvIGxpbWl0IGJhbmR3aWR0aCBvbiBhIGxpbnV4IGd3DQo+ IGRvaW5nIHZwbnMgd2l0aCBmcmVlc3dhbiwgSS5FLiBmb3IgYSAxTWJpdCBsaW5lIHdpdGggMSBp cHNlYyB0dW5uZWwgb24NCj4gaW50ZXJmYWNlIHBwcDAsIGxpbWl0aW5nIHZwbiB0cmFmZmljIChl c3ApIHRvIDUxMmtiaXQgYW5kIGludGVybmV0DQo+IHRyYWZmaWMgKG5vbiB2cG4pIHRvIDUxMmti aXQuDQo+DQo+DQo+IFRoYW5rcyBpbiBhZHZhbmNlIQ0KTW9yZSBpbmZvIGFib3V0IHNoYXBpbmcg Y2FuIGJlIGZvdW5kIG9uIHd3dy5sYXJ0Yy5vcmcuICBBbmQgSSBoYXZlIHNvbWUgZT0NCnh0cmE9 MjANCmluZm9ybWF0aW9uIG9uIHd3dy5kb2N1bS5vcmcuDQoNCllvdSBoYXZlIHRvIGFkZCBhIGNi cSBvciBodGIgcWRpc2MgdG8geW91ciBpbnRlcmZhY2VzIGFuZCBjcmVhdGUgMiBjbGFzc2U9DQpz LiA9MjANCk9uZSBmb3IgdnBuIHRyYWZmaWMgYW5kIG9uZSBmb3Igbm9uIHZwbiB0cmFmZmljLiAg SSBob3BlIHRoYXQgeW91IHVzZSBmaXg9DQplZD0yMA0KcG9ydHMgZm9yIHRoZSB2cG4gdHJhZmZp YyBzbyB5b3UgY2FuIHVzZSB0aGUgZHN0L3NyYyBwb3J0IGFzIGEgZmlsdGVyIGtleT0NCj0yRSA9 MjANCllvdSBjYW4gc2hhcmUgdGhlIHNhbWUgMW1iaXQgb3IgeW91IGNhbiBsaW1pdCBlYWNoIGNs YXNzIHRvIDUxMmtiaXQuDQoNClN0ZWYNCg0KLS09MjANCg0Kc3RlZi5jb2VuZUBkb2N1bS5vcmcN CiAiVXNpbmcgTGludXggYXMgYmFuZHdpZHRoIG1hbmFnZXIiDQogICAgIGh0dHA6Ly93d3cuZG9j dW0ub3JnLw0KICAgICAjbGFydGMgQCBpcmMub2Z0Yy5uZXQNCg0KLS1fXy0tX18tLQ0KDQpNZXNz YWdlOiA4DQpEYXRlOiBNb24sIDE5IEF1ZyAyMDAyIDEyOjQ3OjM1IC0wNTAwIChDRFQpDQpGcm9t OiBBbWl0IEt1Y2hlcmlhIDxhbWl0a0BpdHRjLmt1LmVkdT4NClRvOiBsYXJ0Y0BtYWlsbWFuLmRz OWEubmwNCkNjOiBqYUBzc2kuYmcNClN1YmplY3Q6IFJlOiBbTEFSVENdIEhUQjMgcG9ydCBmb3Ig Mi4yLjE4Pw0KDQpJIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gZ2V0dGluZyB0aGUgcGF0Y2hlcyBm b3IgMi4yLjIxLg0KDQpUaGFua3MuDQotIEFtaXQNCg0KT24gRnJpLCAxNyBBdWcgMjAwMiwgSnVs aWFuIEFuYXN0YXNvdiB3cm90ZToNCg0KPj4gSXMgdGhlcmUgYW4gSFRCMyBwb3J0IGZvciAyLjIu MTg/DQo+Pg0KPglZZXMsIEkgaGF2ZSBiYWNrcG9ydGVkIHRoZSBuZXQvc2NoZWQgZnJvbSAyLjQu MjBwcmUxIHRvIDIuMi4yMSwNCj4gaW5jbHVkaW5nIEhUQjMuIFRoZSBzaW1wbGUgdGVzdHMgbG9v ayBnb29kLCB0aGUgcHJvYmxlbSBpcyB0aGF0IEkgDQo+IHN0aWxsIGhhdmUgcHJvYmxlbXMgdXBk YXRpbmcvYWNjZXNzaW5nIG15IHNpdGUuIEkgY2FuIHByb3ZpZGUgbXkgDQo+ICJEUy05IiB0cmVl IHRvIGFueW9uZSBpbnRlcmVzdGVkIGluIHRlc3RpbmcgYW5kIGhvc3RpbmcgdGhlIGZpbGVzLg0K DQotLSANCkknbSBhbiBhbmdlbCEhISBIb25lc3QhDQpUaGUgaG9ybnMgYXJlIGp1c3QgdGhlcmUg dG8gaG9sZCB0aGUgaGFsbyB1cCBzdHJhaWdodC4NCl4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4t Xi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eDQogICAgICAgICAgICAgICAgICBBbWl0IEt1Y2hl cmlhDQogICAgICAgICAgRUVDUyBHcmFkLiBSZXNlYXJjaCBBc3Npc3RhbnQNCiAgICAgICAgIFVu aXZlcnNpdHkgb2YgS2Fuc2FzIEAgTGF3cmVuY2UNCiAgIChSKTogKzEtNzg1LTgzMC04NTIxIHx8 fCAoQyk6ICsxLTc4NS03NjAtMjg3MQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogOQ0KRGF0ZTog TW9uLCAxOSBBdWcgMjAwMiAxNDoyODozNCAtMDQwMA0KRnJvbTogIk1pY2hhZWwgVC4gQmFiY29j ayIgPG1iYWJjb2NrQGZpYnJlc3BlZWQubmV0Pg0KVG86IExBUlRDIExpc3QgPGxhcnRjQG1haWxt YW4uZHM5YS5ubD4NClN1YmplY3Q6IFJlOiBbTEFSVENdIExpbWl0IGJhbmR3aWR0aCBmb3IgaXBz ZWMgdnBucw0KDQpPbiBNb24sIEF1ZyAxOSwgMjAwMiBhdCAwNzowMTozMlBNICswMjAwLCBTdGVm IENvZW5lIHdyb3RlOg0KPiA+IElzIHRoZXJlIGFueW9uZSBoYXZpbmcgYW4gaWRlYSBvbiBob3cg dG8gbGltaXQgYmFuZHdpZHRoIG9uIGEgbGludXggZ3cNCj4gPiBkb2luZyB2cG5zIHdpdGggZnJl ZXN3YW4sIEkuRS4gZm9yIGEgMU1iaXQgbGluZSB3aXRoIDEgaXBzZWMgdHVubmVsIG9uDQo+ID4g aW50ZXJmYWNlIHBwcDAsIGxpbWl0aW5nIHZwbiB0cmFmZmljIChlc3ApIHRvIDUxMmtiaXQgYW5k IGludGVybmV0DQo+ID4gdHJhZmZpYyAobm9uIHZwbikgdG8gNTEya2JpdC4NCj4gTW9yZSBpbmZv IGFib3V0IHNoYXBpbmcgY2FuIGJlIGZvdW5kIG9uIHd3dy5sYXJ0Yy5vcmcuICBBbmQgSSBoYXZl IHNvbWUgZXh0cmEgDQo+IGluZm9ybWF0aW9uIG9uIHd3dy5kb2N1bS5vcmcuDQo+IA0KPiBZb3Ug aGF2ZSB0byBhZGQgYSBjYnEgb3IgaHRiIHFkaXNjIHRvIHlvdXIgaW50ZXJmYWNlcyBhbmQgY3Jl YXRlIDIgY2xhc3Nlcy4gIA0KPiBPbmUgZm9yIHZwbiB0cmFmZmljIGFuZCBvbmUgZm9yIG5vbiB2 cG4gdHJhZmZpYy4gIEkgaG9wZSB0aGF0IHlvdSB1c2UgZml4ZWQgDQo+IHBvcnRzIGZvciB0aGUg dnBuIHRyYWZmaWMgc28geW91IGNhbiB1c2UgdGhlIGRzdC9zcmMgcG9ydCBhcyBhIGZpbHRlciBr ZXkuICANCj4gWW91IGNhbiBzaGFyZSB0aGUgc2FtZSAxbWJpdCBvciB5b3UgY2FuIGxpbWl0IGVh Y2ggY2xhc3MgdG8gNTEya2JpdC4NCg0KSWYgRnJlZVMvV0FOIGlzIHVzZWQsIGFkZGluZyBhIHBh aXIgb2YgY2xhc3NlcyB0byB0aGUgZXh0ZXJuYWwgaW50ZXJmYWNlDQpmb3IgJ25vcm1hbCcgYW5k ICdWUE4nIHRyYWZmaWMgc2hvdWxkIHN1ZmZpY2UuICBWUE4gdHJhZmZpYyBpcyBpZGVudGlmaWFi bGUNCmFzIHRyYWZmaWMgb3ZlciBVRFAgcG9ydCA1MDAgYW5kIHByb3RvY29scyA1MCBvciA1MSwg YWx0aG91Z2ggeW91IG1heSB3aXNoDQp0byBnaXZlIHRoZW0gdGhlaXIgb3duIGNsYXNzIHdpdGgg aGlnaCBwcmlvcml0eSBhcyB0aGV5IGRvIGtleSBleGNoYW5nZXMuDQoNCklmIHlvdSBnYXZlIGVh Y2ggNTEya2JwcywgdGhlbiBhZGQgYSByb290IGNsYXNzIHRvIGlwc2VjMCBvZiA1MTJrYnBzIGFu ZA0Kd29yayBmcm9tIHRoZXJlIG9uIGl0Lg0KLS0gDQpNaWNoYWVsIFQuIEJhYmNvY2sNCkNUTywg RmlicmVTcGVlZCBMdGQuICAgICAoSG9zdGluZywgU2VjdXJpdHksIENvbnN1bHRhdGlvbiwgRGF0 YWJhc2UsIGV0YykNCmh0dHA6Ly93d3cuZmlicmVzcGVlZC5uZXQvfm1iYWJjb2NrLw0KDQotLV9f LS1fXy0tDQoNCk1lc3NhZ2U6IDEwDQpGcm9tOiBTdGVmIENvZW5lIDxzdGVmLmNvZW5lQGRvY3Vt Lm9yZz4NCk9yZ2FuaXphdGlvbjogTm9uZQ0KVG86IE1pY2hhZWwgR3JhdXBuZXIgPG1ncmF1cGVA d2ViLmRlPiwgbGFydGNAbWFpbG1hbi5kczlhLm5sDQpTdWJqZWN0OiBSZTogW0xBUlRDXSBnYXRl d2F5IHByb2JsZW1zDQpEYXRlOiBNb24sIDE5IEF1ZyAyMDAyIDIwOjQyOjE2ICswMjAwDQoNCj4g SSBhbSB0cnlpbmcgdG8gc2V0IHVwIGEgbG9jYWwgbmV0d29yayBjb25zaXN0aW5nIG91dCBvZiB0 d28gbGFwdG9wcw0KPiB1bmRlciBTdVNFIDguMCAoa2VybmVsIDIuNC4xOCkuIFRoZSBtb2RlbSBv biBteSBsYXB0b3AgaXMgbm90IHdvcmtpbmcgdT0NCm5kZQ0KPiByIGxpbnV4LCBzbyBJIHdhbnQg dG8gdXNlIHRoZSBvdGhlciBjb21wdXRlciBhcyBhIGdhdGV3YXkuIEFmdGVyIGRpYWxpbj0NCmcN Cj4gaW4gdmlhIG1vZGVtIG9uIHRoZSBvdGhlciBsYXB0b3AsIHRoZSByb3V0aW5nDQo+IHRhYmxl cyBhcmUgbG9va2luZyBsaWtlIHRoZSBmb2xsb3dpbmc6DQo+DQo+IC0gY29tcHV0ZXIgMSAoMTQx LjMwLjE3LjI1Mik6DQo+IEtlcm5lbCBJUCBSb3V0ZW50YWJlbGxlDQo+IFppZWwgICAgICAgICAg ICBSb3V0ZXIgICAgICAgICAgR2VubWFzayAgICAgICAgIEZsYWdzIE1ldHJpYyBSZWYgICAgVXNl DQo+IElmYWNlDQo+IDE0MS4zMC4xNy4yNTIgICAwLjAuMC4wICAgICAgICAgMjU1LjI1NS4yNTUu MjU1IFVIICAgIDAgICAgICAwICAgICAgICAwDQo+IGV0aDAgMTQxLjMwLjE3LjAgICAgIDAuMC4w LjAgICAgICAgICAyNTUuMjU1LjI1NS4wICAgVSAgICAgMCAgICAgIDAgICAgPQ0KICA9MjANCj4g MCBldGgwIDAuMC4wLjAgICAgICAgICAxNDEuMzAuMTcuMjUzICAgMC4wLjAuMCAgICAgICAgIFVH ICAgIDAgICAgICAwICA9DQogICA9MjANCj4gIDAgZXRoMA0KPg0KPiAtIGNvbXB1dGVyIDIgZ2F0 ZXdheSAoMTQxLjMwLjE3LjI1Myk6DQo+IEtlcm5lbCBJUCByb3V0aW5nIHRhYmxlDQo+IERlc3Rp bmF0aW9uICAgICBHYXRld2F5ICAgICAgICAgR2VubWFzayAgICAgICAgIEZsYWdzIE1ldHJpYyBS ZWYgICAgVXNlDQo+IElmYWNlDQo+IDYyLjEwNC4yMDQuMzQgICAwLjAuMC4wICAgICAgICAgMjU1 LjI1NS4yNTUuMjU1IFVIICAgIDAgICAgICAwICAgICAgICAwDQo+IHBwcDAgMTQxLjMwLjE3LjAg ICAgIDAuMC4wLjAgICAgICAgICAyNTUuMjU1LjI1NS4wICAgVSAgICAgMCAgICAgIDAgICAgPQ0K ICA9MjANCj4gMCBldGgwIDAuMC4wLjAgICAgICAgICA2Mi4xMDQuMjA0LjM0ICAgMC4wLjAuMCAg ICAgICAgIFVHICAgIDAgICAgICAwICA9DQogICA9MjANCj4gIDAgcHBwMA0KPg0KPiAgRnJvbSAx NDEuMzAuMTcuMjUyIEkgYW0gYWJsZSB0byBjb25uZWN0IHRvIDE0MS4zMC4xNy4yNTMgaW4gb3Vy IGxvY2FsDQo+IG5ldHdvcmssIGJ1dCBJIGRvIG5vdCBoYXZlIGFjY2VzcyB0byB0aGUgb3V0ZXIg c3BhY2UuIEkgZXZlbiBjYW5ub3QgcGluPQ0KZw0KPiAgdG8gNjIuMTA0LjIwNC4zNC4gT24gMTQx LjMwLjE3LjI1MiBJIGhhdmUgYSBwY21jaWEgbmV0d29yayBjYXJkIGFuZCB0aD0NCmUNCj4gb3Ro ZXIgY29tcHV0ZXIgaGFzIGEgaW50ZXJuYWwgbmV0d29yayBjYXJkLiAgSSBhbSBydW5uaW5nIG91 dCBvZiBpZGVhDQo+IHMgaG93IHRvIGdldCB0aGUgbmV0d29yayB3b3JraW5nIGFuZCB3b3VsZCBh cHByZWNpYXRlIGFsbCBzdWdnZXN0aW9ucy4NCj4gTWljaGFlbC4NCkhhdmUgeW91IGEga2VybmVs IHdpdGggaXAgZm9yd2FyZGluZyBhbmQgaGF2ZSB5b3UgZW5hYmxlZCBpdCA/DQplY2hvICIxIiA+ IC9wcm9jL3N5cy9uZXQvaXB2NC9pcF9mb3J3YXJkDQoNCkFuZCBoYXZlIHlvdSBzYW1lIGJhc2lj IG1hc3F1aW5nIHJ1bGVzID8NCmlwdGFibGVzIC10IG5hdCAtQSBQT1NUUk9VVElORyAtbyBwcHAw IC1qIE1BU1FVRVJBREUNCg0KU3RlZg0KDQotLT0yMA0KDQpzdGVmLmNvZW5lQGRvY3VtLm9yZw0K ICJVc2luZyBMaW51eCBhcyBiYW5kd2lkdGggbWFuYWdlciINCiAgICAgaHR0cDovL3d3dy5kb2N1 bS5vcmcvDQogICAgICNsYXJ0YyBAIGlyYy5vZnRjLm5ldA0KDQotLV9fLS1fXy0tDQoNCk1lc3Nh Z2U6IDExDQpGcm9tOiBQYXRyaWNrIENoYW4gPHBhdHJpY2tfY2hhbkBtdGVsbmV0LmNvbT4NClRv OiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNCkRhdGU6IFR1ZSwgMjAgQXVnIDIwMDIgMTA6MDI6MzQg KzA4MDANClN1YmplY3Q6IFtMQVJUQ10gUHJpb3JpdHkgUXVldWVpbmcNCg0KVGhpcyBtZXNzYWdl IGlzIGluIE1JTUUgZm9ybWF0LiBTaW5jZSB5b3VyIG1haWwgcmVhZGVyIGRvZXMgbm90IHVuZGVy c3RhbmQNCnRoaXMgZm9ybWF0LCBzb21lIG9yIGFsbCBvZiB0aGlzIG1lc3NhZ2UgbWF5IG5vdCBi ZSBsZWdpYmxlLg0KDQotLS0tLS1fPV9OZXh0UGFydF8wMDFfMDFDMjQ3RUQuQTZCNTgzOTANCkNv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJpc28tODg1OS0xIg0KDQpEZWFyIGFs bCwNCg0KSG93IGNhbiBJIGRvIHByaW9yaXR5IHF1ZXVlaW5nIGluIExpbnV4Pw0KU2hvdWxkIEkg dXNlIFBSSU8gcWRpc2M/DQpDYW4gYW55b25lIGdpdmUgbWUgYW4gZXhhbXBsZSBvbiBwcmlvcml0 eSBxdWV1ZWluZz8NCg0KUC5TLiBQcmlvcml0eSBRdWV1ZWluZyBpcyB0byBjbGFzc2lmeSBwYWNr ZXRzIGludG8gaGlnaCBhbmQgbG93IHF1ZXVlLCANCmhpZ2ggcXVldWUgcGFja2V0cyBhbHdheXMg ZGVxdWV1ZSBmaXJzdCBiZWZvcmUgbG93IHF1ZXVlLg0KDQpQYXRyaWNrDQoNCi0tLS0tLV89X05l eHRQYXJ0XzAwMV8wMUMyNDdFRC5BNkI1ODM5MA0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7DQoJ Y2hhcnNldD0iaXNvLTg4NTktMSINCg0KPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RU RCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRl bnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEg TkFNRT0iR2VuZXJhdG9yIiBDT05URU5UPSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUu MjY1My4xMiI+DQo8VElUTEU+UHJpb3JpdHkgUXVldWVpbmc8L1RJVExFPg0KPC9IRUFEPg0KPEJP RFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5EZWFyIGFsbCw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj5Ib3cgY2FuIEkgZG8gcHJpb3JpdHkgcXVldWVpbmcgaW4gTGludXg/PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5TaG91bGQgSSB1c2UgUFJJTyBxZGlzYz88L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPkNhbiBhbnlvbmUgZ2l2ZSBtZSBhbiBleGFtcGxlIG9uIHByaW9yaXR5IHF1ZXVl aW5nPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlAuUy4gUHJpb3JpdHkgUXVldWVp bmcgaXMgdG8gY2xhc3NpZnkgcGFja2V0cyBpbnRvIGhpZ2ggYW5kIGxvdyBxdWV1ZSwgPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5oaWdoIHF1ZXVlIHBhY2tldHMgYWx3YXlzIGRlcXVldWUgZmly c3QgYmVmb3JlIGxvdyBxdWV1ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5QYXRy aWNrPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+DQotLS0tLS1fPV9OZXh0UGFydF8w MDFfMDFDMjQ3RUQuQTZCNTgzOTAtLQ0KDQoNCi0tX18tLV9fLS0NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkxBUlRDIG1haWxpbmcgbGlzdA0KTEFS VENAbWFpbG1hbi5kczlhLm5sDQpodHRwOi8vbWFpbG1hbi5kczlhLm5sL21haWxtYW4vbGlzdGlu Zm8vbGFydGMNCg0KDQpFbmQgb2YgTEFSVEMgRGlnZXN0DQoNCg== --MIME MULTIPART BOUNDARY=.1029818107:+'1 Content-Type: text/plain; charset=US-ASCII Content-Id: <1551405451-3@softerware.com> Content-Transfer-Encoding: 7bit I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #726 - 11 msgs From: lartc@mailman.ds9a.nl Date: 08/20/02 01:27:40 This item was automatically created and contains MIME Information. --MIME MULTIPART BOUNDARY=.1029818107:+'1-- From arindamhaldar@inbox.lv Mon Aug 19 09:19:52 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Mon, 19 Aug 2002 13:49:52 +0530 Subject: [LARTC] Multi Routing Problem. Message-ID: <3D60AA28.4050906@inbox.lv> hi all, i am trying to do some advance routing for our clients on a multi route platform !.. at present am trying on a test bed.. i followed the example & applied julian's patch to kernel 2.4.19 & have gone thru the docs at the site... i have defined basically 3 groups for clients--> cache, cisco, balance.. the name specifies the importance.. this is the details of what i did--> [root@Lr1 root]# ip rule ls 0: from all lookup local 10: from EXTnA.124/25 lookup ONE 20: from EXTnB.106/26 lookup TWO 100: from 192.168.1.10 lookup CACHE 101: from 192.168.1.20 lookup CISCO 150: from 192.168.1.30 lookup BALANCE 200: from all lookup ME 32766: from all lookup main 32767: from all lookup 253 [root@Lr1 root]# ip route ls ta ONE default via EXtnA.1 dev eth1 src EXTnA.124 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta TWO default via EXTnB.70 dev eth0 src EXTnB.106 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta CACHE default via EXTnA.1 dev eth1 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta CISCO default via EXTnB.70 dev eth0 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta BALANCE default nexthop via EXTnB.70 dev eth0 weight 1 nexthop via EXTnA.1 dev eth1 weight 1 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta ME default nexthop via EXTnA.1 dev eth1 weight 1 nexthop via EXTnB.70 dev eth0 weight 1 prohibit default proto static metric 1 [root@Lr1 root]# ip addr ls 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:50:bf:4b:f7:84 brd ff:ff:ff:ff:ff:ff inet EXTnB.106/26 brd EXTnB.127 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:b9:69:99 brd ff:ff:ff:ff:ff:ff inet EXTnA.124/25 brd EXTnA.127 scope global eth1 4: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:b9:69:9a brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/16 brd 192.168.255.255 scope global eth2 [root@Lr1 root]# ip route ls 203.163.146.64/26 dev eth0 scope link 203.163.149.0/25 dev eth1 scope link 192.168.0.0/16 dev eth2 proto kernel scope link src 192.168.0.1 127.0.0.0/8 dev lo scope link here ONE & TWO are the two external links.. ME is used for local server DNS deamon.. the other three viz CACHE CISCO BALANCE are the routes the clients ip's must follow.. i have enabled ip_forward .. & iptables rules are also specified correct .. i.e according to the ip.. BUT am **NOT** able to surf at all from internal network... not even able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while FORWARD is DROP.. whats missing there ?.. after trying all day i want guidance now... awaiting a reply very anxiously.... A.H From bergal@gmx.net Tue Aug 20 14:09:35 2002 From: bergal@gmx.net (Alexander Bergal) Date: Tue, 20 Aug 2002 15:09:35 +0200 (MEST) Subject: [LARTC] unsubscribe Message-ID: <29526.1029848975@www27.gmx.net> -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From caldodge@fpcc.net Tue Aug 20 14:21:37 2002 From: caldodge@fpcc.net (Calvin Dodge) Date: Tue, 20 Aug 2002 07:21:37 -0600 Subject: [LARTC] uplink with multiple lines Message-ID: <20020820072137.A3180@aberdeen.fpcc.net> I've been trying - without success - to aggregate the bandwidth of 3 DSL modems using the instructions in the HowTo (sections 4.2.1 and 4.2.2). I _believe_ I'm following the instructions to the letter, but when I add the last command (the "ip route" with "nexthop") then nothing goes out through the modems. Each modem works when I add a single default gateway pointing to it, so I don't believe the modems are the problem. Two of the modems _do_ have private IP addresses (192.168.x.1) - could that be confusing the kernel? If so, do I need to get public IP addresses for those modems? Do I HAVE to create a patched kernel (ala Anastasov)? May I post the script I used to try this out? Thanks, folks! Calvin Dodge Certified Linux Bigot (tm) http://www.caldodge.fpcc.net From arindamhaldar@inbox.lv Sun Aug 18 17:14:40 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Sun, 18 Aug 2002 21:44:40 +0530 Subject: [LARTC] Multi Routing Problem Message-ID: <3D5FC7F0.30101@inbox.lv> hi all, i am trying to do some advance routing for our clients on a multi route platform !.. at present am trying on a test bed.. i followed the example & applied julian's patch to kernel 2.4.19 & have gone thru the docs at the site... i have defined basically 3 groups for clients--> cache, cisco, balance.. the name specifies the importance.. this is the details of what i did--> [root@Lr1 root]# ip rule ls 0: from all lookup local 10: from EXTnA.124/25 lookup ONE 20: from EXTnB.106/26 lookup TWO 100: from 192.168.1.10 lookup CACHE 101: from 192.168.1.20 lookup CISCO 150: from 192.168.1.30 lookup BALANCE 200: from all lookup ME 32766: from all lookup main 32767: from all lookup 253 [root@Lr1 root]# ip route ls ta ONE default via EXtnA.1 dev eth1 src EXTnA.124 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta TWO default via EXTnB.70 dev eth0 src EXTnB.106 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta CACHE default via EXTnA.1 dev eth1 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta CISCO default via EXTnB.70 dev eth0 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta BALANCE default nexthop via EXTnB.70 dev eth0 weight 1 nexthop via EXTnA.1 dev eth1 weight 1 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta ME default nexthop via EXTnA.1 dev eth1 weight 1 nexthop via EXTnB.70 dev eth0 weight 1 prohibit default proto static metric 1 [root@Lr1 root]# ip addr ls 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:50:bf:4b:f7:84 brd ff:ff:ff:ff:ff:ff inet EXTnB.106/26 brd EXTnB.127 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:b9:69:99 brd ff:ff:ff:ff:ff:ff inet EXTnA.124/25 brd EXTnA.127 scope global eth1 4: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:b9:69:9a brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/16 brd 192.168.255.255 scope global eth2 [root@Lr1 root]# ip route ls 203.163.146.64/26 dev eth0 scope link 203.163.149.0/25 dev eth1 scope link 192.168.0.0/16 dev eth2 proto kernel scope link src 192.168.0.1 127.0.0.0/8 dev lo scope link here ONE & TWO are the two external links.. ME is used for local server DNS deamon.. the other three viz CACHE CISCO BALANCE are the routes the clients ip's must follow.. i have enabled ip_forward .. & iptables rules are also specified correct .. i.e according to the ip.. BUT am **NOT** able to surf at all from internal network... not even able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while FORWARD is DROP.. whats missing there ?.. after trying all day i want guidance now... awaiting a reply very anxiously.... A.H From bergal@gmx.net Tue Aug 20 15:13:03 2002 From: bergal@gmx.net (Alexander Bergal) Date: Tue, 20 Aug 2002 16:13:03 +0200 (MEST) Subject: [LARTC] unsubscribe Message-ID: <8787.1029852783@www45.gmx.net> -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From arindamhaldar@inbox.lv Sun Aug 18 21:51:33 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Mon, 19 Aug 2002 02:21:33 +0530 Subject: [LARTC] Multi Routing Problem Message-ID: <3D6008D5.1010704@inbox.lv> hi all, i am trying to do some advance routing for our clients on a multi route platform !.. at present am trying on a test bed.. i followed the example & applied julian's patch to kernel 2.4.19 & have gone thru the docs at the site... i have defined basically 3 groups for clients--> cache, cisco, balance.. the name specifies the importance.. this is the details of what i did--> [root@Lr1 root]# ip rule ls 0: from all lookup local 10: from EXTnA.124/25 lookup ONE 20: from EXTnB.106/26 lookup TWO 100: from 192.168.1.10 lookup CACHE 101: from 192.168.1.20 lookup CISCO 150: from 192.168.1.30 lookup BALANCE 200: from all lookup ME 32766: from all lookup main 32767: from all lookup 253 [root@Lr1 root]# ip route ls ta ONE default via EXtnA.1 dev eth1 src EXTnA.124 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta TWO default via EXTnB.70 dev eth0 src EXTnB.106 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta CACHE default via EXTnA.1 dev eth1 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta CISCO default via EXTnB.70 dev eth0 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta BALANCE default nexthop via EXTnB.70 dev eth0 weight 1 nexthop via EXTnA.1 dev eth1 weight 1 prohibit default proto static metric 1 [root@Lr1 root]# ip route ls ta ME default nexthop via EXTnA.1 dev eth1 weight 1 nexthop via EXTnB.70 dev eth0 weight 1 prohibit default proto static metric 1 [root@Lr1 root]# ip addr ls 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:50:bf:4b:f7:84 brd ff:ff:ff:ff:ff:ff inet EXTnB.106/26 brd EXTnB.127 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:b9:69:99 brd ff:ff:ff:ff:ff:ff inet EXTnA.124/25 brd EXTnA.127 scope global eth1 4: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:b9:69:9a brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/16 brd 192.168.255.255 scope global eth2 [root@Lr1 root]# ip route ls 203.163.146.64/26 dev eth0 scope link 203.163.149.0/25 dev eth1 scope link 192.168.0.0/16 dev eth2 proto kernel scope link src 192.168.0.1 127.0.0.0/8 dev lo scope link here ONE & TWO are the two external links.. ME is used for local server DNS deamon.. the other three viz CACHE CISCO BALANCE are the routes the clients ip's must follow.. i have enabled ip_forward .. & iptables rules are also specified correct .. i.e according to the ip.. BUT am **NOT** able to surf at all from internal network... not even able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while FORWARD is DROP.. whats missing there ?.. after trying all day i want guidance now... awaiting a reply very anxiously.... A.H From elacour@easter-eggs.com Tue Aug 20 16:56:02 2002 From: elacour@easter-eggs.com (Emmanuel Lacour) Date: Tue, 20 Aug 2002 17:56:02 +0200 Subject: [LARTC] Limit bandwidth for ipsec vpns In-Reply-To: <20020819182834.GD9987@godzilla.fibrespeed.net> References: <20020819162929.GO19138@easter-eggs.com> <20020819170133.33E9BDBB44@tartarus.telenet-ops.be> <20020819182834.GD9987@godzilla.fibrespeed.net> Message-ID: <20020820155602.GB26441@easter-eggs.com> On Mon, Aug 19, 2002 at 02:28:34PM -0400, Michael T. Babcock wrote: > On Mon, Aug 19, 2002 at 07:01:32PM +0200, Stef Coene wrote: > > > Is there anyone having an idea on how to limit bandwidth on a linux gw > > > doing vpns with freeswan, I.E. for a 1Mbit line with 1 ipsec tunnel on > > > interface ppp0, limiting vpn traffic (esp) to 512kbit and internet > > > traffic (non vpn) to 512kbit. > > More info about shaping can be found on www.lartc.org. And I have some extra > > information on www.docum.org. > > > > You have to add a cbq or htb qdisc to your interfaces and create 2 classes. > > One for vpn traffic and one for non vpn traffic. I hope that you use fixed > > ports for the vpn traffic so you can use the dst/src port as a filter key. > > You can share the same 1mbit or you can limit each class to 512kbit. > > If FreeS/WAN is used, adding a pair of classes to the external interface > for 'normal' and 'VPN' traffic should suffice. VPN traffic is identifiable > as traffic over UDP port 500 and protocols 50 or 51, although you may wish > to give them their own class with high priority as they do key exchanges. Thanks, I tried with marking packet with netfilter, but here is one of my pbms, I can mark esp proto but not non-esp proto: # This works # Marking outgoing vpn packets iptables -t mangle -A OUTPUT -o $IFEXT -p esp -j MARK --set-mark 29 iptables -t mangle -A OUTPUT -o $IFEXT -p udp --dport 500 -j MARK --set-mark 29 # This doesn't works!! # Marking outgoing non-vpn packets iptables -t mangle -A OUTPUT -o $IFEXT -p ! esp -j MARK --set-mark 39 Any Idea?? > > If you gave each 512kbps, then add a root class to ipsec0 of 512kbps and > work from there on it. > -- > Michael T. Babcock > CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) > http://www.fibrespeed.net/~mbabcock/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 mailto:elacour@easter-eggs.com - http://www.easter-eggs.com From egal@ipanematech.com Tue Aug 20 17:17:23 2002 From: egal@ipanematech.com (EGAL Vincent) Date: Tue, 20 Aug 2002 18:17:23 +0200 Subject: [LARTC] bug in sfq fairness Message-ID: <3D626B93.4D2E1FC8@ipanematech.com> --------------17452DEC6F0C72576E7E5126 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, I found a strange behavior with SFQ qdisc when several TCP flows start at the same time: despite having different hash values , they have a good chances to fall in the same slot which implies no more fairness than a simple FIFO. This is due to the fact that the hash table for a flow is not cleared after dequeuing a slot whith a single packet in queue and so the same slot might be shared without hash colisions. proposed patch : --- kernel/linux-2.4.18/net/sched/sch_sfq.c Tue May 7 16:22:23 2002 +++ sch_sfq.c Tue Aug 20 18:07:03 2002 @@ -343,6 +343,7 @@ if (q->qs[a].qlen == 0) { a = q->next[a]; if (a == old_a) { + q->ht[q->hash[a]] = SFQ_DEPTH; q->tail = SFQ_DEPTH; return skb; } any comments ? -- Vincent EGAL Email : egal@ipanematech.com --------------17452DEC6F0C72576E7E5126 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi,
I found a strange behavior with SFQ qdisc when several TCP flows start at the same time:  despite having different hash values , they have a good chances to fall in the same slot which implies no more fairness than a simple FIFO.
This is due to the fact that the hash table for a flow is not cleared after dequeuing a slot whith a single packet in queue and so the same slot might be shared without hash colisions.
proposed patch :

--- kernel/linux-2.4.18/net/sched/sch_sfq.c     Tue May  7 16:22:23 2002
+++ sch_sfq.c   Tue Aug 20 18:07:03 2002
@@ -343,6 +343,7 @@
        if (q->qs[a].qlen == 0) {
                a = q->next[a];
                if (a == old_a) {
+                       q->ht[q->hash[a]] = SFQ_DEPTH;
                        q->tail = SFQ_DEPTH;
                        return skb;
                }

any comments ? 

-- 
Vincent EGAL
Email : egal@ipanematech.com
  --------------17452DEC6F0C72576E7E5126-- From isamp@terra.com.br Tue Aug 20 20:14:33 2002 From: isamp@terra.com.br (Isamp) Date: Tue, 20 Aug 2002 16:14:33 -0300 Subject: [LARTC] FreeSWAN and IPROUTE2 Message-ID: <200208201614.34339.isamp@terra.com.br> Hi People !!! I'm a newbie in this list and in this concepts. Please, I need help to learn more about routing tools on Linux and its in= teraction with FreeSWAN and IPTables. I just read the "Fun with iproute2 and FreeS/WAN" (www.quintilion.com/moa= t/ipsec+routing/iproute2.html,=20 very, very, very good text) document but, I need more !!! On my project, I'm tinking in a lot of linux boxes with 2 or more uplinks= , like this: Frame Relay uplink /------------------------------\ / \ | +---------+/ \+---------+ | +----+Linux Box|---=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D---|Linux Box|----+ | +---------+\ IPSEC with /+---------+ | \ FreeS/WAN / \ / \ / \----------+POTS+----------/ Dial on Demand On my tests, when the tunnel is downed, the routing table is updated but,= if the tunnel broke,=20 the kernel routing table persists with routes added by freeSWAN. I'm thinking to use OSPF (Zebra or BIRD): on this protocol we have the 'h= elo' packets to determine the current state of links but, ipsec interface is not a multicast interf= ace ! Reading "Linux Advanced Routing & Traffic Control HOWTO" (http://lartc.or= g/howto/, very good document too), in chapter 5.3 we can read=20 "GRE is a tunneling protocol that was originally developed by Cisco, and = it can do=20 a few more things than IP-in-IP tunneling. For example, you can also tran= sport=20 multicast traffic and IPv6 through a GRE tunnel.". So, What I use ? Ipsec tunnels from FreeS/WAN or GRE Tunnels ? Both ? How= ? The traffic over GRE Tunnel are encripted ? How ? I'm tinking to use the OSPF protocol (Zebra) do make a load balance betwe= en FrameRelay and ipsec interfaces but, in same HOWTO ("Fun...") I see the new possibilitie= with iproute2. What is better ? Someone have interest in this solution ? Someone can help me ? Tanks in Advance . Isamp ps.: sorry for my poor english !!! From ja@ssi.bg Wed Aug 21 01:10:22 2002 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 21 Aug 2002 00:10:22 +0000 (GMT) Subject: [LARTC] Multi Routing Problem. In-Reply-To: <3D60AA28.4050906@inbox.lv> Message-ID: Hello, On Mon, 19 Aug 2002, Arindam Haldar wrote: > & applied julian's patch to kernel 2.4.19 & have gone thru the docs at > the site... i have defined basically 3 groups for clients--> cache, > cisco, balance.. the name specifies the importance.. this is the details > of what i did--> Carefully analyze the docs... > [root@Lr1 root]# ip rule ls > 0: from all lookup local # direct communications are first priority ip rule add prio 5 table main > 10: from EXTnA.124/25 lookup ONE > 20: from EXTnB.106/26 lookup TWO > 100: from 192.168.1.10 lookup CACHE > 101: from 192.168.1.20 lookup CISCO > 150: from 192.168.1.30 lookup BALANCE > 200: from all lookup ME > 32766: from all lookup main > 32767: from all lookup 253 > BUT am **NOT** able to surf at all from internal network... not even > able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while > FORWARD is DROP.. First try with all ACCEPT. > whats missing there ?.. after trying all day i want guidance now... > awaiting a reply very anxiously.... Your setup is a bit strange: internal hosts use some gateways, the external addresses use different gateways. The problem is that if you are using NAT and for example 192.168.1.10 is SNAT-ed the packet will leave with new saddr (the masquerade address). Looking in your rules there is different gateway for the masquerade address. This can't work. The current framework requires that: - if one internal IP is masqueraded to a specific address, you need the 2 routes to be similar, i.e.: from INT_IP to TARGET and from MASQ_IP to TARGET to use same gateway and device. This is even mandatory for the patches. Currently, the first packet for one connection is routed via the route "from INT_IP to TARGET", the SNAT rules assign masquerade address at postrouting and then all next packets are routed via the 2nd route - 1 route per forwarded packet. It is a bit strange these two routes to use different gateways. Do you have a good reason for this? Also note that rules in the form "from 0/0 to ANY_TARGET" where ANY_TARGET can be any subnet including 0/0 are used for source address autoselection - the resulting preferred source IP is used as saddr. It is not used only as "default" rule. So, playing tricks with different gateways is not possible. The setup is ambiguous if NAT is involved. > A.H Regards -- Julian Anastasov From ja@ssi.bg Wed Aug 21 01:25:40 2002 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 21 Aug 2002 00:25:40 +0000 (GMT) Subject: [LARTC] uplink with multiple lines In-Reply-To: <20020820072137.A3180@aberdeen.fpcc.net> Message-ID: Hello, On Tue, 20 Aug 2002, Calvin Dodge wrote: > Two of the modems _do_ have private IP addresses (192.168.x.1) - could > that be confusing the kernel? If so, do I need to get public IP > addresses for those modems? AFAIK, there is not flag "public" for the IP addresses in Linux, at least, not in IPv4. The kernel does not know anything about private/reserved IP ranges. > Do I HAVE to create a patched kernel (ala Anastasov)? May be not. But you can try to understand the settings provided in the docs. The essential thing to understand is how the ip rules and routes are ordered, how the NAT uses the routing, why the NAT in plain kernels sometimes breaks with multipath routes, what kind of nexthops the kernel can live with, can you live without dead gateway detection, if not, how it works (in kernel? help from user space?), etc. > May I post the script I used to try this out? Or if possible to provide reference to it after the 5th reading of all docs :) > Thanks, folks! > > Calvin Dodge > Certified Linux Bigot (tm) > http://www.caldodge.fpcc.net Regards -- Julian Anastasov From mikep02@softerware.com Tue Aug 20 22:28:52 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Tue, 20 Aug 2002 17:28:52 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #728 - 11 msgs Message-ID: <723468053@softerware.com> --MIME MULTIPART BOUNDARY=.1029878952:+'1 Content-Type: application/octet-stream Content-Id: <723468053-2@softerware.com> Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Text Item" U2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCglsYXJ0Y0BtYWlsbWFuLmRz OWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBX ZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRj DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVs cCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5ubA0KDQpZb3UgY2FuIHJlYWNoIHRo ZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0Yy1hZG1pbkBtYWlsbWFuLmRzOWEu bmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQg aXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIExBUlRDIGRpZ2VzdC4uLiIN Cg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gTXVsdGkgUm91dGluZyBQcm9ibGVtLiAoQXJp bmRhbSBIYWxkYXIpDQogICAyLiB1bnN1YnNjcmliZSAoQWxleGFuZGVyIEJlcmdhbCkNCiAgIDMu IHVwbGluayB3aXRoIG11bHRpcGxlIGxpbmVzIChDYWx2aW4gRG9kZ2UpDQogICA0LiBNdWx0aSBS b3V0aW5nIFByb2JsZW0gKEFyaW5kYW0gSGFsZGFyKQ0KICAgNS4gdW5zdWJzY3JpYmUgKEFsZXhh bmRlciBCZXJnYWwpDQogICA2LiBNdWx0aSBSb3V0aW5nIFByb2JsZW0gKEFyaW5kYW0gSGFsZGFy KQ0KICAgNy4gUmU6IExpbWl0IGJhbmR3aWR0aCBmb3IgaXBzZWMgdnBucyAoRW1tYW51ZWwgTGFj b3VyKQ0KICAgOC4gYnVnIGluIHNmcSBmYWlybmVzcyAoRUdBTCBWaW5jZW50KQ0KICAgOS4gRnJl ZVNXQU4gYW5kIElQUk9VVEUyIChJc2FtcCkNCiAgMTAuIFJlOiBNdWx0aSBSb3V0aW5nIFByb2Js ZW0uIChKdWxpYW4gQW5hc3Rhc292KQ0KICAxMS4gUmU6IHVwbGluayB3aXRoIG11bHRpcGxlIGxp bmVzIChKdWxpYW4gQW5hc3Rhc292KQ0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDENCkRhdGU6 IE1vbiwgMTkgQXVnIDIwMDIgMTM6NDk6NTIgKzA1MzANCkZyb206IEFyaW5kYW0gSGFsZGFyIDxh cmluZGFtaGFsZGFyQGluYm94Lmx2Pg0KVG86IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVj dDogW0xBUlRDXSBNdWx0aSBSb3V0aW5nIFByb2JsZW0uDQoNCmhpIGFsbCwNCmkgYW0gdHJ5aW5n IHRvIGRvIHNvbWUgYWR2YW5jZSByb3V0aW5nIGZvciBvdXIgY2xpZW50cyBvbiBhIG11bHRpIHJv dXRlIA0KcGxhdGZvcm0gIS4uIGF0IHByZXNlbnQgYW0gdHJ5aW5nIG9uIGEgdGVzdCBiZWQuLiBp IGZvbGxvd2VkIHRoZSBleGFtcGxlIA0KJiBhcHBsaWVkIGp1bGlhbidzIHBhdGNoIHRvIGtlcm5l bCAyLjQuMTkgJiBoYXZlIGdvbmUgdGhydSB0aGUgZG9jcyBhdCANCnRoZSBzaXRlLi4uIGkgaGF2 ZSBkZWZpbmVkIGJhc2ljYWxseSAzIGdyb3VwcyBmb3IgY2xpZW50cy0tPiBjYWNoZSwgDQpjaXNj bywgYmFsYW5jZS4uIHRoZSBuYW1lIHNwZWNpZmllcyB0aGUgaW1wb3J0YW5jZS4uIHRoaXMgaXMg dGhlIGRldGFpbHMgDQpvZiB3aGF0IGkgZGlkLS0+DQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJ1bGUg bHMNCjA6ICAgICAgZnJvbSBhbGwgbG9va3VwIGxvY2FsDQoxMDogICAgIGZyb20gRVhUbkEuMTI0 LzI1IGxvb2t1cCBPTkUNCjIwOiAgICAgZnJvbSBFWFRuQi4xMDYvMjYgbG9va3VwIFRXTw0KMTAw OiAgICBmcm9tIDE5Mi4xNjguMS4xMCBsb29rdXAgQ0FDSEUNCjEwMTogICAgZnJvbSAxOTIuMTY4 LjEuMjAgbG9va3VwIENJU0NPDQoxNTA6ICAgIGZyb20gMTkyLjE2OC4xLjMwIGxvb2t1cCBCQUxB TkNFDQoyMDA6ICAgIGZyb20gYWxsIGxvb2t1cCBNRQ0KMzI3NjY6ICBmcm9tIGFsbCBsb29rdXAg bWFpbg0KMzI3Njc6ICBmcm9tIGFsbCBsb29rdXAgMjUzDQoNCltyb290QExyMSByb290XSMgaXAg cm91dGUgbHMgdGEgT05FDQpkZWZhdWx0IHZpYSBFWHRuQS4xIGRldiBldGgxICBzcmMgRVhUbkEu MTI0DQpwcm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAxDQoNCltyb290QExy MSByb290XSMgaXAgcm91dGUgbHMgdGEgVFdPDQpkZWZhdWx0IHZpYSBFWFRuQi43MCBkZXYgZXRo MCAgc3JjIEVYVG5CLjEwNg0KcHJvaGliaXQgZGVmYXVsdCAgcHJvdG8gc3RhdGljICBtZXRyaWMg MQ0KDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxzIHRhIENBQ0hFDQpkZWZhdWx0IHZpYSBF WFRuQS4xIGRldiBldGgxDQpwcm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAx DQoNCltyb290QExyMSByb290XSMgaXAgcm91dGUgbHMgdGEgQ0lTQ08NCmRlZmF1bHQgdmlhIEVY VG5CLjcwIGRldiBldGgwDQpwcm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAx DQoNCltyb290QExyMSByb290XSMgaXAgcm91dGUgbHMgdGEgQkFMQU5DRQ0KZGVmYXVsdA0KICAg ICAgICAgbmV4dGhvcCB2aWEgRVhUbkIuNzAgIGRldiBldGgwIHdlaWdodCAxDQogICAgICAgICBu ZXh0aG9wIHZpYSBFWFRuQS4xICBkZXYgZXRoMSB3ZWlnaHQgMQ0KcHJvaGliaXQgZGVmYXVsdCAg cHJvdG8gc3RhdGljICBtZXRyaWMgMQ0KDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxzIHRh IE1FDQpkZWZhdWx0DQogICAgICAgICBuZXh0aG9wIHZpYSBFWFRuQS4xICBkZXYgZXRoMSB3ZWln aHQgMQ0KICAgICAgICAgbmV4dGhvcCB2aWEgRVhUbkIuNzAgIGRldiBldGgwIHdlaWdodCAxDQpw cm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAxDQpbcm9vdEBMcjEgcm9vdF0j IGlwIGFkZHIgbHMNCjE6IGxvOiA8TE9PUEJBQ0ssVVA+IG10dSAxNjQzNiBxZGlzYyBub3F1ZXVl DQogICAgIGxpbmsvbG9vcGJhY2sgMDA6MDA6MDA6MDA6MDA6MDAgYnJkIDAwOjAwOjAwOjAwOjAw OjAwDQogICAgIGluZXQgMTI3LjAuMC4xLzggYnJkIDEyNy4yNTUuMjU1LjI1NSBzY29wZSBob3N0 IGxvDQoyOiBldGgwOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxVUD4gbXR1IDE1MDAgcWRpc2MgcGZp Zm9fZmFzdCBxbGVuIDEwMA0KICAgICBsaW5rL2V0aGVyIDAwOjUwOmJmOjRiOmY3Ojg0IGJyZCBm ZjpmZjpmZjpmZjpmZjpmZg0KICAgICBpbmV0IEVYVG5CLjEwNi8yNiBicmQgRVhUbkIuMTI3IHNj b3BlIGdsb2JhbCBldGgwDQozOiBldGgxOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxVUD4gbXR1IDE1 MDAgcWRpc2MgcGZpZm9fZmFzdCBxbGVuIDEwMA0KICAgICBsaW5rL2V0aGVyIDAwOjgwOmM4OmI5 OjY5Ojk5IGJyZCBmZjpmZjpmZjpmZjpmZjpmZg0KICAgICBpbmV0IEVYVG5BLjEyNC8yNSBicmQg RVhUbkEuMTI3IHNjb3BlIGdsb2JhbCBldGgxDQo0OiBldGgyOiA8QlJPQURDQVNULE1VTFRJQ0FT VCxVUD4gbXR1IDE1MDAgcWRpc2MgcGZpZm9fZmFzdCBxbGVuIDEwMA0KICAgICBsaW5rL2V0aGVy IDAwOjgwOmM4OmI5OjY5OjlhIGJyZCBmZjpmZjpmZjpmZjpmZjpmZg0KICAgICBpbmV0IDE5Mi4x NjguMC4xLzE2IGJyZCAxOTIuMTY4LjI1NS4yNTUgc2NvcGUgZ2xvYmFsIGV0aDINCltyb290QExy MSByb290XSMgaXAgcm91dGUgbHMNCjIwMy4xNjMuMTQ2LjY0LzI2IGRldiBldGgwICBzY29wZSBs aW5rDQoyMDMuMTYzLjE0OS4wLzI1IGRldiBldGgxICBzY29wZSBsaW5rDQoxOTIuMTY4LjAuMC8x NiBkZXYgZXRoMiAgcHJvdG8ga2VybmVsICBzY29wZSBsaW5rICBzcmMgMTkyLjE2OC4wLjENCjEy Ny4wLjAuMC84IGRldiBsbyAgc2NvcGUgbGluaw0KDQpoZXJlIE9ORSAmIFRXTyBhcmUgdGhlIHR3 byBleHRlcm5hbCBsaW5rcy4uIE1FIGlzIHVzZWQgZm9yIGxvY2FsIHNlcnZlciANCkROUyBkZWFt b24uLiB0aGUgb3RoZXIgdGhyZWUgdml6IENBQ0hFIENJU0NPIEJBTEFOQ0UgYXJlIHRoZSByb3V0 ZXMgdGhlIA0KY2xpZW50cyBpcCdzIG11c3QgZm9sbG93Li4gaSBoYXZlIGVuYWJsZWQgaXBfZm9y d2FyZCAuLiAmIGlwdGFibGVzIHJ1bGVzIA0KYXJlIGFsc28gc3BlY2lmaWVkIGNvcnJlY3QgLi4g aS5lIGFjY29yZGluZyB0byB0aGUgaXAuLg0KQlVUIGFtICoqTk9UKiogYWJsZSB0byBzdXJmIGF0 IGFsbCBmcm9tIGludGVybmFsIG5ldHdvcmsuLi4gbm90IGV2ZW4gDQphYmxlIHRvIHBpbmcgZXRo MiAhISEuLiBkZWZhdWx0IElOUFVUICYgT1VUUFVUIGFyZSBzZXQgdG8gQUNDRVBUIHdoaWxlIA0K Rk9SV0FSRCBpcyBEUk9QLi4NCndoYXRzIG1pc3NpbmcgdGhlcmUgPy4uIGFmdGVyIHRyeWluZyBh bGwgZGF5IGkgd2FudCBndWlkYW5jZSBub3cuLi4NCmF3YWl0aW5nIGEgcmVwbHkgdmVyeSBhbnhp b3VzbHkuLi4uDQpBLkgNCg0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDINCkRhdGU6IFR1ZSwg MjAgQXVnIDIwMDIgMTU6MDk6MzUgKzAyMDAgKE1FU1QpDQpGcm9tOiBBbGV4YW5kZXIgQmVyZ2Fs IDxiZXJnYWxAZ214Lm5ldD4NClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFtM QVJUQ10gdW5zdWJzY3JpYmUNCg0KDQoNCi0tIA0KR01YIC0gRGllIEtvbW11bmlrYXRpb25zcGxh dHRmb3JtIGltIEludGVybmV0Lg0KaHR0cDovL3d3dy5nbXgubmV0DQoNCg0KLS1fXy0tX18tLQ0K DQpNZXNzYWdlOiAzDQpEYXRlOiBUdWUsIDIwIEF1ZyAyMDAyIDA3OjIxOjM3IC0wNjAwDQpGcm9t OiBDYWx2aW4gRG9kZ2UgPGNhbGRvZGdlQGZwY2MubmV0Pg0KVG86IGxhcnRjQG1haWxtYW4uZHM5 YS5ubA0KU3ViamVjdDogW0xBUlRDXSB1cGxpbmsgd2l0aCBtdWx0aXBsZSBsaW5lcw0KDQpJJ3Zl IGJlZW4gdHJ5aW5nIC0gd2l0aG91dCBzdWNjZXNzIC0gdG8gYWdncmVnYXRlIHRoZSBiYW5kd2lk dGggb2YgMyBEU0wgbW9kZW1zDQp1c2luZyB0aGUgaW5zdHJ1Y3Rpb25zIGluIHRoZSBIb3dUbyAo c2VjdGlvbnMgNC4yLjEgYW5kIDQuMi4yKS4NCg0KSSBfYmVsaWV2ZV8gSSdtIGZvbGxvd2luZyB0 aGUgaW5zdHJ1Y3Rpb25zIHRvIHRoZSBsZXR0ZXIsIGJ1dCB3aGVuIEkgYWRkIHRoZSBsYXN0IGNv bW1hbmQgKHRoZSAiaXAgcm91dGUiIHdpdGggIm5leHRob3AiKSB0aGVuIG5vdGhpbmcgZ29lcyBv dXQgdGhyb3VnaCB0aGUgbW9kZW1zLg0KDQpFYWNoIG1vZGVtIHdvcmtzIHdoZW4gSSBhZGQgYSBz aW5nbGUgZGVmYXVsdCBnYXRld2F5IHBvaW50aW5nIHRvIGl0LCBzbyBJIGRvbid0IGJlbGlldmUg dGhlIG1vZGVtcyBhcmUgdGhlIHByb2JsZW0uICAgDQoNClR3byBvZiB0aGUgbW9kZW1zIF9kb18g aGF2ZSBwcml2YXRlIElQIGFkZHJlc3NlcyAoMTkyLjE2OC54LjEpIC0gY291bGQgdGhhdCBiZSBj b25mdXNpbmcgdGhlIGtlcm5lbD8gSWYgc28sIGRvIEkgbmVlZCB0byBnZXQgcHVibGljIElQIGFk ZHJlc3NlcyBmb3IgdGhvc2UgbW9kZW1zPw0KDQpEbyBJIEhBVkUgdG8gY3JlYXRlIGEgcGF0Y2hl ZCBrZXJuZWwgKGFsYSBBbmFzdGFzb3YpPw0KDQpNYXkgSSBwb3N0IHRoZSBzY3JpcHQgSSB1c2Vk IHRvIHRyeSB0aGlzIG91dD8NCg0KVGhhbmtzLCBmb2xrcyENCg0KQ2FsdmluIERvZGdlDQpDZXJ0 aWZpZWQgTGludXggQmlnb3QgKHRtKQ0KaHR0cDovL3d3dy5jYWxkb2RnZS5mcGNjLm5ldA0KDQot LV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDQNCkRhdGU6IFN1biwgMTggQXVnIDIwMDIgMjE6NDQ6NDAg KzA1MzANCkZyb206IEFyaW5kYW0gSGFsZGFyIDxhcmluZGFtaGFsZGFyQGluYm94Lmx2Pg0KVG86 IExBUlRDIDxsYXJ0Y0BtYWlsbWFuLmRzOWEubmw+DQpTdWJqZWN0OiBbTEFSVENdIE11bHRpIFJv dXRpbmcgUHJvYmxlbQ0KDQpoaSBhbGwsDQppIGFtIHRyeWluZyB0byBkbyBzb21lIGFkdmFuY2Ug cm91dGluZyBmb3Igb3VyIGNsaWVudHMgb24gYSBtdWx0aSByb3V0ZSANCnBsYXRmb3JtICEuLiBh dCBwcmVzZW50IGFtIHRyeWluZyBvbiBhIHRlc3QgYmVkLi4gaSBmb2xsb3dlZCB0aGUgZXhhbXBs ZSANCiYgYXBwbGllZCBqdWxpYW4ncyBwYXRjaCB0byBrZXJuZWwgMi40LjE5ICYgaGF2ZSBnb25l IHRocnUgdGhlIGRvY3MgYXQgDQp0aGUgc2l0ZS4uLiBpIGhhdmUgZGVmaW5lZCBiYXNpY2FsbHkg MyBncm91cHMgZm9yIGNsaWVudHMtLT4gY2FjaGUsIA0KY2lzY28sIGJhbGFuY2UuLiB0aGUgbmFt ZSBzcGVjaWZpZXMgdGhlIGltcG9ydGFuY2UuLiB0aGlzIGlzIHRoZSBkZXRhaWxzIA0Kb2Ygd2hh dCBpIGRpZC0tPg0KW3Jvb3RATHIxIHJvb3RdIyBpcCBydWxlIGxzDQowOiAgICAgIGZyb20gYWxs IGxvb2t1cCBsb2NhbA0KMTA6ICAgICBmcm9tIEVYVG5BLjEyNC8yNSBsb29rdXAgT05FDQoyMDog ICAgIGZyb20gRVhUbkIuMTA2LzI2IGxvb2t1cCBUV08NCjEwMDogICAgZnJvbSAxOTIuMTY4LjEu MTAgbG9va3VwIENBQ0hFDQoxMDE6ICAgIGZyb20gMTkyLjE2OC4xLjIwIGxvb2t1cCBDSVNDTw0K MTUwOiAgICBmcm9tIDE5Mi4xNjguMS4zMCBsb29rdXAgQkFMQU5DRQ0KMjAwOiAgICBmcm9tIGFs bCBsb29rdXAgTUUNCjMyNzY2OiAgZnJvbSBhbGwgbG9va3VwIG1haW4NCjMyNzY3OiAgZnJvbSBh bGwgbG9va3VwIDI1Mw0KDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxzIHRhIE9ORQ0KZGVm YXVsdCB2aWEgRVh0bkEuMSBkZXYgZXRoMSAgc3JjIEVYVG5BLjEyNA0KcHJvaGliaXQgZGVmYXVs dCAgcHJvdG8gc3RhdGljICBtZXRyaWMgMQ0KDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxz IHRhIFRXTw0KZGVmYXVsdCB2aWEgRVhUbkIuNzAgZGV2IGV0aDAgIHNyYyBFWFRuQi4xMDYNCnBy b2hpYml0IGRlZmF1bHQgIHByb3RvIHN0YXRpYyAgbWV0cmljIDENCg0KW3Jvb3RATHIxIHJvb3Rd IyBpcCByb3V0ZSBscyB0YSBDQUNIRQ0KZGVmYXVsdCB2aWEgRVhUbkEuMSBkZXYgZXRoMQ0KcHJv aGliaXQgZGVmYXVsdCAgcHJvdG8gc3RhdGljICBtZXRyaWMgMQ0KDQpbcm9vdEBMcjEgcm9vdF0j IGlwIHJvdXRlIGxzIHRhIENJU0NPDQpkZWZhdWx0IHZpYSBFWFRuQi43MCBkZXYgZXRoMA0KcHJv aGliaXQgZGVmYXVsdCAgcHJvdG8gc3RhdGljICBtZXRyaWMgMQ0KDQpbcm9vdEBMcjEgcm9vdF0j IGlwIHJvdXRlIGxzIHRhIEJBTEFOQ0UNCmRlZmF1bHQNCiAgICAgICAgIG5leHRob3AgdmlhIEVY VG5CLjcwICBkZXYgZXRoMCB3ZWlnaHQgMQ0KICAgICAgICAgbmV4dGhvcCB2aWEgRVhUbkEuMSAg ZGV2IGV0aDEgd2VpZ2h0IDENCnByb2hpYml0IGRlZmF1bHQgIHByb3RvIHN0YXRpYyAgbWV0cmlj IDENCg0KW3Jvb3RATHIxIHJvb3RdIyBpcCByb3V0ZSBscyB0YSBNRQ0KZGVmYXVsdA0KICAgICAg ICAgbmV4dGhvcCB2aWEgRVhUbkEuMSAgZGV2IGV0aDEgd2VpZ2h0IDENCiAgICAgICAgIG5leHRo b3AgdmlhIEVYVG5CLjcwICBkZXYgZXRoMCB3ZWlnaHQgMQ0KcHJvaGliaXQgZGVmYXVsdCAgcHJv dG8gc3RhdGljICBtZXRyaWMgMQ0KW3Jvb3RATHIxIHJvb3RdIyBpcCBhZGRyIGxzDQoxOiBsbzog PExPT1BCQUNLLFVQPiBtdHUgMTY0MzYgcWRpc2Mgbm9xdWV1ZQ0KICAgICBsaW5rL2xvb3BiYWNr IDAwOjAwOjAwOjAwOjAwOjAwIGJyZCAwMDowMDowMDowMDowMDowMA0KICAgICBpbmV0IDEyNy4w LjAuMS84IGJyZCAxMjcuMjU1LjI1NS4yNTUgc2NvcGUgaG9zdCBsbw0KMjogZXRoMDogPEJST0FE Q0FTVCxNVUxUSUNBU1QsVVA+IG10dSAxNTAwIHFkaXNjIHBmaWZvX2Zhc3QgcWxlbiAxMDANCiAg ICAgbGluay9ldGhlciAwMDo1MDpiZjo0YjpmNzo4NCBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCiAg ICAgaW5ldCBFWFRuQi4xMDYvMjYgYnJkIEVYVG5CLjEyNyBzY29wZSBnbG9iYWwgZXRoMA0KMzog ZXRoMTogPEJST0FEQ0FTVCxNVUxUSUNBU1QsVVA+IG10dSAxNTAwIHFkaXNjIHBmaWZvX2Zhc3Qg cWxlbiAxMDANCiAgICAgbGluay9ldGhlciAwMDo4MDpjODpiOTo2OTo5OSBicmQgZmY6ZmY6ZmY6 ZmY6ZmY6ZmYNCiAgICAgaW5ldCBFWFRuQS4xMjQvMjUgYnJkIEVYVG5BLjEyNyBzY29wZSBnbG9i YWwgZXRoMQ0KNDogZXRoMjogPEJST0FEQ0FTVCxNVUxUSUNBU1QsVVA+IG10dSAxNTAwIHFkaXNj IHBmaWZvX2Zhc3QgcWxlbiAxMDANCiAgICAgbGluay9ldGhlciAwMDo4MDpjODpiOTo2OTo5YSBi cmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCiAgICAgaW5ldCAxOTIuMTY4LjAuMS8xNiBicmQgMTkyLjE2 OC4yNTUuMjU1IHNjb3BlIGdsb2JhbCBldGgyDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxz DQoyMDMuMTYzLjE0Ni42NC8yNiBkZXYgZXRoMCAgc2NvcGUgbGluaw0KMjAzLjE2My4xNDkuMC8y NSBkZXYgZXRoMSAgc2NvcGUgbGluaw0KMTkyLjE2OC4wLjAvMTYgZGV2IGV0aDIgIHByb3RvIGtl cm5lbCAgc2NvcGUgbGluayAgc3JjIDE5Mi4xNjguMC4xDQoxMjcuMC4wLjAvOCBkZXYgbG8gIHNj b3BlIGxpbmsNCg0KaGVyZSBPTkUgJiBUV08gYXJlIHRoZSB0d28gZXh0ZXJuYWwgbGlua3MuLiBN RSBpcyB1c2VkIGZvciBsb2NhbCBzZXJ2ZXIgDQpETlMgZGVhbW9uLi4gdGhlIG90aGVyIHRocmVl IHZpeiBDQUNIRSBDSVNDTyBCQUxBTkNFIGFyZSB0aGUgcm91dGVzIHRoZSANCmNsaWVudHMgaXAn cyBtdXN0IGZvbGxvdy4uIGkgaGF2ZSBlbmFibGVkIGlwX2ZvcndhcmQgLi4gJiBpcHRhYmxlcyBy dWxlcyANCmFyZSBhbHNvIHNwZWNpZmllZCBjb3JyZWN0IC4uIGkuZSBhY2NvcmRpbmcgdG8gdGhl IGlwLi4NCkJVVCBhbSAqKk5PVCoqIGFibGUgdG8gc3VyZiBhdCBhbGwgZnJvbSBpbnRlcm5hbCBu ZXR3b3JrLi4uIG5vdCBldmVuIA0KYWJsZSB0byBwaW5nIGV0aDIgISEhLi4gZGVmYXVsdCBJTlBV VCAmIE9VVFBVVCBhcmUgc2V0IHRvIEFDQ0VQVCB3aGlsZSANCkZPUldBUkQgaXMgRFJPUC4uDQp3 aGF0cyBtaXNzaW5nIHRoZXJlID8uLiBhZnRlciB0cnlpbmcgYWxsIGRheSBpIHdhbnQgZ3VpZGFu Y2Ugbm93Li4uDQphd2FpdGluZyBhIHJlcGx5IHZlcnkgYW54aW91c2x5Li4uLg0KQS5IDQoNCg0K DQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDUNCkRhdGU6IFR1ZSwgMjAgQXVnIDIwMDIgMTY6MTM6 MDMgKzAyMDAgKE1FU1QpDQpGcm9tOiBBbGV4YW5kZXIgQmVyZ2FsIDxiZXJnYWxAZ214Lm5ldD4N ClRvOiBMQVJUQ0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFtMQVJUQ10gdW5zdWJzY3JpYmUN Cg0KDQoNCi0tIA0KR01YIC0gRGllIEtvbW11bmlrYXRpb25zcGxhdHRmb3JtIGltIEludGVybmV0 Lg0KaHR0cDovL3d3dy5nbXgubmV0DQoNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiA2DQpEYXRl OiBNb24sIDE5IEF1ZyAyMDAyIDAyOjIxOjMzICswNTMwDQpGcm9tOiBBcmluZGFtIEhhbGRhciA8 YXJpbmRhbWhhbGRhckBpbmJveC5sdj4NClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1Ympl Y3Q6IFtMQVJUQ10gTXVsdGkgUm91dGluZyBQcm9ibGVtDQoNCmhpIGFsbCwNCmkgYW0gdHJ5aW5n IHRvIGRvIHNvbWUgYWR2YW5jZSByb3V0aW5nIGZvciBvdXIgY2xpZW50cyBvbiBhIG11bHRpIHJv dXRlIA0KcGxhdGZvcm0gIS4uIGF0IHByZXNlbnQgYW0gdHJ5aW5nIG9uIGEgdGVzdCBiZWQuLiBp IGZvbGxvd2VkIHRoZSBleGFtcGxlIA0KJiBhcHBsaWVkIGp1bGlhbidzIHBhdGNoIHRvIGtlcm5l bCAyLjQuMTkgJiBoYXZlIGdvbmUgdGhydSB0aGUgZG9jcyBhdCANCnRoZSBzaXRlLi4uIGkgaGF2 ZSBkZWZpbmVkIGJhc2ljYWxseSAzIGdyb3VwcyBmb3IgY2xpZW50cy0tPiBjYWNoZSwgDQpjaXNj bywgYmFsYW5jZS4uIHRoZSBuYW1lIHNwZWNpZmllcyB0aGUgaW1wb3J0YW5jZS4uIHRoaXMgaXMg dGhlIGRldGFpbHMgDQpvZiB3aGF0IGkgZGlkLS0+DQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJ1bGUg bHMNCjA6ICAgICAgZnJvbSBhbGwgbG9va3VwIGxvY2FsDQoxMDogICAgIGZyb20gRVhUbkEuMTI0 LzI1IGxvb2t1cCBPTkUNCjIwOiAgICAgZnJvbSBFWFRuQi4xMDYvMjYgbG9va3VwIFRXTw0KMTAw OiAgICBmcm9tIDE5Mi4xNjguMS4xMCBsb29rdXAgQ0FDSEUNCjEwMTogICAgZnJvbSAxOTIuMTY4 LjEuMjAgbG9va3VwIENJU0NPDQoxNTA6ICAgIGZyb20gMTkyLjE2OC4xLjMwIGxvb2t1cCBCQUxB TkNFDQoyMDA6ICAgIGZyb20gYWxsIGxvb2t1cCBNRQ0KMzI3NjY6ICBmcm9tIGFsbCBsb29rdXAg bWFpbg0KMzI3Njc6ICBmcm9tIGFsbCBsb29rdXAgMjUzDQoNCltyb290QExyMSByb290XSMgaXAg cm91dGUgbHMgdGEgT05FDQpkZWZhdWx0IHZpYSBFWHRuQS4xIGRldiBldGgxICBzcmMgRVhUbkEu MTI0DQpwcm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAxDQoNCltyb290QExy MSByb290XSMgaXAgcm91dGUgbHMgdGEgVFdPDQpkZWZhdWx0IHZpYSBFWFRuQi43MCBkZXYgZXRo MCAgc3JjIEVYVG5CLjEwNg0KcHJvaGliaXQgZGVmYXVsdCAgcHJvdG8gc3RhdGljICBtZXRyaWMg MQ0KDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxzIHRhIENBQ0hFDQpkZWZhdWx0IHZpYSBF WFRuQS4xIGRldiBldGgxDQpwcm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAx DQoNCltyb290QExyMSByb290XSMgaXAgcm91dGUgbHMgdGEgQ0lTQ08NCmRlZmF1bHQgdmlhIEVY VG5CLjcwIGRldiBldGgwDQpwcm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAx DQoNCltyb290QExyMSByb290XSMgaXAgcm91dGUgbHMgdGEgQkFMQU5DRQ0KZGVmYXVsdA0KICAg ICAgICAgbmV4dGhvcCB2aWEgRVhUbkIuNzAgIGRldiBldGgwIHdlaWdodCAxDQogICAgICAgICBu ZXh0aG9wIHZpYSBFWFRuQS4xICBkZXYgZXRoMSB3ZWlnaHQgMQ0KcHJvaGliaXQgZGVmYXVsdCAg cHJvdG8gc3RhdGljICBtZXRyaWMgMQ0KDQpbcm9vdEBMcjEgcm9vdF0jIGlwIHJvdXRlIGxzIHRh IE1FDQpkZWZhdWx0DQogICAgICAgICBuZXh0aG9wIHZpYSBFWFRuQS4xICBkZXYgZXRoMSB3ZWln aHQgMQ0KICAgICAgICAgbmV4dGhvcCB2aWEgRVhUbkIuNzAgIGRldiBldGgwIHdlaWdodCAxDQpw cm9oaWJpdCBkZWZhdWx0ICBwcm90byBzdGF0aWMgIG1ldHJpYyAxDQpbcm9vdEBMcjEgcm9vdF0j IGlwIGFkZHIgbHMNCjE6IGxvOiA8TE9PUEJBQ0ssVVA+IG10dSAxNjQzNiBxZGlzYyBub3F1ZXVl DQogICAgIGxpbmsvbG9vcGJhY2sgMDA6MDA6MDA6MDA6MDA6MDAgYnJkIDAwOjAwOjAwOjAwOjAw OjAwDQogICAgIGluZXQgMTI3LjAuMC4xLzggYnJkIDEyNy4yNTUuMjU1LjI1NSBzY29wZSBob3N0 IGxvDQoyOiBldGgwOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxVUD4gbXR1IDE1MDAgcWRpc2MgcGZp Zm9fZmFzdCBxbGVuIDEwMA0KICAgICBsaW5rL2V0aGVyIDAwOjUwOmJmOjRiOmY3Ojg0IGJyZCBm ZjpmZjpmZjpmZjpmZjpmZg0KICAgICBpbmV0IEVYVG5CLjEwNi8yNiBicmQgRVhUbkIuMTI3IHNj b3BlIGdsb2JhbCBldGgwDQozOiBldGgxOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxVUD4gbXR1IDE1 MDAgcWRpc2MgcGZpZm9fZmFzdCBxbGVuIDEwMA0KICAgICBsaW5rL2V0aGVyIDAwOjgwOmM4OmI5 OjY5Ojk5IGJyZCBmZjpmZjpmZjpmZjpmZjpmZg0KICAgICBpbmV0IEVYVG5BLjEyNC8yNSBicmQg RVhUbkEuMTI3IHNjb3BlIGdsb2JhbCBldGgxDQo0OiBldGgyOiA8QlJPQURDQVNULE1VTFRJQ0FT VCxVUD4gbXR1IDE1MDAgcWRpc2MgcGZpZm9fZmFzdCBxbGVuIDEwMA0KICAgICBsaW5rL2V0aGVy IDAwOjgwOmM4OmI5OjY5OjlhIGJyZCBmZjpmZjpmZjpmZjpmZjpmZg0KICAgICBpbmV0IDE5Mi4x NjguMC4xLzE2IGJyZCAxOTIuMTY4LjI1NS4yNTUgc2NvcGUgZ2xvYmFsIGV0aDINCltyb290QExy MSByb290XSMgaXAgcm91dGUgbHMNCjIwMy4xNjMuMTQ2LjY0LzI2IGRldiBldGgwICBzY29wZSBs aW5rDQoyMDMuMTYzLjE0OS4wLzI1IGRldiBldGgxICBzY29wZSBsaW5rDQoxOTIuMTY4LjAuMC8x NiBkZXYgZXRoMiAgcHJvdG8ga2VybmVsICBzY29wZSBsaW5rICBzcmMgMTkyLjE2OC4wLjENCjEy Ny4wLjAuMC84IGRldiBsbyAgc2NvcGUgbGluaw0KDQpoZXJlIE9ORSAmIFRXTyBhcmUgdGhlIHR3 byBleHRlcm5hbCBsaW5rcy4uIE1FIGlzIHVzZWQgZm9yIGxvY2FsIHNlcnZlciANCkROUyBkZWFt b24uLiB0aGUgb3RoZXIgdGhyZWUgdml6IENBQ0hFIENJU0NPIEJBTEFOQ0UgYXJlIHRoZSByb3V0 ZXMgdGhlIA0KY2xpZW50cyBpcCdzIG11c3QgZm9sbG93Li4gaSBoYXZlIGVuYWJsZWQgaXBfZm9y d2FyZCAuLiAmIGlwdGFibGVzIHJ1bGVzIA0KYXJlIGFsc28gc3BlY2lmaWVkIGNvcnJlY3QgLi4g aS5lIGFjY29yZGluZyB0byB0aGUgaXAuLg0KQlVUIGFtICoqTk9UKiogYWJsZSB0byBzdXJmIGF0 IGFsbCBmcm9tIGludGVybmFsIG5ldHdvcmsuLi4gbm90IGV2ZW4gDQphYmxlIHRvIHBpbmcgZXRo MiAhISEuLiBkZWZhdWx0IElOUFVUICYgT1VUUFVUIGFyZSBzZXQgdG8gQUNDRVBUIHdoaWxlIA0K Rk9SV0FSRCBpcyBEUk9QLi4NCndoYXRzIG1pc3NpbmcgdGhlcmUgPy4uIGFmdGVyIHRyeWluZyBh bGwgZGF5IGkgd2FudCBndWlkYW5jZSBub3cuLi4NCmF3YWl0aW5nIGEgcmVwbHkgdmVyeSBhbnhp b3VzbHkuLi4uDQpBLkgNCg0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogNw0KRGF0ZTogVHVl LCAyMCBBdWcgMjAwMiAxNzo1NjowMiArMDIwMA0KRnJvbTogRW1tYW51ZWwgTGFjb3VyIDxlbGFj b3VyQGVhc3Rlci1lZ2dzLmNvbT4NClRvOiAiTWljaGFlbCBULiBCYWJjb2NrIiA8bWJhYmNvY2tA ZmlicmVzcGVlZC5uZXQ+DQpDYzogTEFSVEMgTGlzdCA8bGFydGNAbWFpbG1hbi5kczlhLm5sPg0K U3ViamVjdDogUmU6IFtMQVJUQ10gTGltaXQgYmFuZHdpZHRoIGZvciBpcHNlYyB2cG5zDQoNCk9u IE1vbiwgQXVnIDE5LCAyMDAyIGF0IDAyOjI4OjM0UE0gLTA0MDAsIE1pY2hhZWwgVC4gQmFiY29j ayB3cm90ZToNCj4gT24gTW9uLCBBdWcgMTksIDIwMDIgYXQgMDc6MDE6MzJQTSArMDIwMCwgU3Rl ZiBDb2VuZSB3cm90ZToNCj4gPiA+IElzIHRoZXJlIGFueW9uZSBoYXZpbmcgYW4gaWRlYSBvbiBo b3cgdG8gbGltaXQgYmFuZHdpZHRoIG9uIGEgbGludXggZ3cNCj4gPiA+IGRvaW5nIHZwbnMgd2l0 aCBmcmVlc3dhbiwgSS5FLiBmb3IgYSAxTWJpdCBsaW5lIHdpdGggMSBpcHNlYyB0dW5uZWwgb24N Cj4gPiA+IGludGVyZmFjZSBwcHAwLCBsaW1pdGluZyB2cG4gdHJhZmZpYyAoZXNwKSB0byA1MTJr Yml0IGFuZCBpbnRlcm5ldA0KPiA+ID4gdHJhZmZpYyAobm9uIHZwbikgdG8gNTEya2JpdC4NCj4g PiBNb3JlIGluZm8gYWJvdXQgc2hhcGluZyBjYW4gYmUgZm91bmQgb24gd3d3LmxhcnRjLm9yZy4g IEFuZCBJIGhhdmUgc29tZSBleHRyYSANCj4gPiBpbmZvcm1hdGlvbiBvbiB3d3cuZG9jdW0ub3Jn Lg0KPiA+IA0KPiA+IFlvdSBoYXZlIHRvIGFkZCBhIGNicSBvciBodGIgcWRpc2MgdG8geW91ciBp bnRlcmZhY2VzIGFuZCBjcmVhdGUgMiBjbGFzc2VzLiAgDQo+ID4gT25lIGZvciB2cG4gdHJhZmZp YyBhbmQgb25lIGZvciBub24gdnBuIHRyYWZmaWMuICBJIGhvcGUgdGhhdCB5b3UgdXNlIGZpeGVk IA0KPiA+IHBvcnRzIGZvciB0aGUgdnBuIHRyYWZmaWMgc28geW91IGNhbiB1c2UgdGhlIGRzdC9z cmMgcG9ydCBhcyBhIGZpbHRlciBrZXkuICANCj4gPiBZb3UgY2FuIHNoYXJlIHRoZSBzYW1lIDFt Yml0IG9yIHlvdSBjYW4gbGltaXQgZWFjaCBjbGFzcyB0byA1MTJrYml0Lg0KPiANCj4gSWYgRnJl ZVMvV0FOIGlzIHVzZWQsIGFkZGluZyBhIHBhaXIgb2YgY2xhc3NlcyB0byB0aGUgZXh0ZXJuYWwg aW50ZXJmYWNlDQo+IGZvciAnbm9ybWFsJyBhbmQgJ1ZQTicgdHJhZmZpYyBzaG91bGQgc3VmZmlj ZS4gIFZQTiB0cmFmZmljIGlzIGlkZW50aWZpYWJsZQ0KPiBhcyB0cmFmZmljIG92ZXIgVURQIHBv cnQgNTAwIGFuZCBwcm90b2NvbHMgNTAgb3IgNTEsIGFsdGhvdWdoIHlvdSBtYXkgd2lzaA0KPiB0 byBnaXZlIHRoZW0gdGhlaXIgb3duIGNsYXNzIHdpdGggaGlnaCBwcmlvcml0eSBhcyB0aGV5IGRv IGtleSBleGNoYW5nZXMuDQoNCg0KVGhhbmtzLCBJIHRyaWVkIHdpdGggbWFya2luZyBwYWNrZXQg d2l0aCBuZXRmaWx0ZXIsIGJ1dCBoZXJlIGlzIG9uZSBvZg0KbXkgcGJtcywgSSBjYW4gbWFyayBl c3AgcHJvdG8gYnV0IG5vdCBub24tZXNwIHByb3RvOg0KDQojIFRoaXMgd29ya3MNCiMgTWFya2lu ZyBvdXRnb2luZyB2cG4gcGFja2V0cw0KaXB0YWJsZXMgLXQgbWFuZ2xlIC1BIE9VVFBVVCAtbyAk SUZFWFQgLXAgZXNwIC1qIE1BUksgLS1zZXQtbWFyayAyOQ0KaXB0YWJsZXMgLXQgbWFuZ2xlIC1B IE9VVFBVVCAtbyAkSUZFWFQgLXAgdWRwIC0tZHBvcnQgNTAwIC1qIE1BUksNCi0tc2V0LW1hcmsg MjkNCg0KIyBUaGlzIGRvZXNuJ3Qgd29ya3MhIQ0KIyBNYXJraW5nIG91dGdvaW5nIG5vbi12cG4g cGFja2V0cyANCmlwdGFibGVzIC10IG1hbmdsZSAtQSBPVVRQVVQgLW8gJElGRVhUIC1wICEgZXNw IC1qIE1BUksgLS1zZXQtbWFyayAzOQ0KDQpBbnkgSWRlYT8/DQoNCj4gDQo+IElmIHlvdSBnYXZl IGVhY2ggNTEya2JwcywgdGhlbiBhZGQgYSByb290IGNsYXNzIHRvIGlwc2VjMCBvZiA1MTJrYnBz IGFuZA0KPiB3b3JrIGZyb20gdGhlcmUgb24gaXQuDQo+IC0tIA0KPiBNaWNoYWVsIFQuIEJhYmNv Y2sNCj4gQ1RPLCBGaWJyZVNwZWVkIEx0ZC4gICAgIChIb3N0aW5nLCBTZWN1cml0eSwgQ29uc3Vs dGF0aW9uLCBEYXRhYmFzZSwgZXRjKQ0KPiBodHRwOi8vd3d3LmZpYnJlc3BlZWQubmV0L35tYmFi Y29jay8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gTEFSVEMgbWFpbGluZyBsaXN0IC8gTEFSVENAbWFpbG1hbi5kczlhLm5sDQo+IGh0dHA6Ly9t YWlsbWFuLmRzOWEubmwvbWFpbG1hbi9saXN0aW5mby9sYXJ0YyBIT1dUTzogaHR0cDovL2xhcnRj Lm9yZy8NCg0KLS0gDQpFYXN0ZXItZWdncyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U3DpY2lhbGlzdGUgR05VL0xpbnV4DQo0NC00NiBydWUgZGUgbCdPdWVzdCAgLSAgNzUwMTQgUGFy aXMgICAtICAgRnJhbmNlIC0gIE3pdHJvIEdhaXTpDQpQaG9uZTogKzMzICgwKSAxIDQzIDM1IDAw IDM3ICAgIC0gICAgIEZheDogKzMzICgwKSAxIDQxIDM1IDAwIDc2DQptYWlsdG86ZWxhY291ckBl YXN0ZXItZWdncy5jb20gICAtICAgIGh0dHA6Ly93d3cuZWFzdGVyLWVnZ3MuY29tDQoNCi0tX18t LV9fLS0NCg0KTWVzc2FnZTogOA0KRGF0ZTogVHVlLCAyMCBBdWcgMjAwMiAxODoxNzoyMyArMDIw MA0KRnJvbTogRUdBTCBWaW5jZW50IDxlZ2FsQGlwYW5lbWF0ZWNoLmNvbT4NClRvOiAibGFydGNA bWFpbG1hbi5kczlhLm5sIiA8bGFydGNAbWFpbG1hbi5kczlhLm5sPg0KU3ViamVjdDogW0xBUlRD XSBidWcgaW4gc2ZxIGZhaXJuZXNzDQoNCg0KLS0tLS0tLS0tLS0tLS0xNzQ1MkRFQzZGMEM3MjU3 NkU3RTUxMjYNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11cy1hc2NpaQ0KQ29u dGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdA0KDQpoaSwNCkkgZm91bmQgYSBzdHJhbmdlIGJl aGF2aW9yIHdpdGggU0ZRIHFkaXNjIHdoZW4gc2V2ZXJhbCBUQ1AgZmxvd3Mgc3RhcnQNCmF0IHRo ZSBzYW1lIHRpbWU6ICBkZXNwaXRlIGhhdmluZyBkaWZmZXJlbnQgaGFzaCB2YWx1ZXMgLCB0aGV5 IGhhdmUgYQ0KZ29vZCBjaGFuY2VzIHRvIGZhbGwgaW4gdGhlIHNhbWUgc2xvdCB3aGljaCBpbXBs aWVzIG5vIG1vcmUgZmFpcm5lc3MNCnRoYW4gYSBzaW1wbGUgRklGTy4NClRoaXMgaXMgZHVlIHRv IHRoZSBmYWN0IHRoYXQgdGhlIGhhc2ggdGFibGUgZm9yIGEgZmxvdyBpcyBub3QgY2xlYXJlZA0K YWZ0ZXIgZGVxdWV1aW5nIGEgc2xvdCB3aGl0aCBhIHNpbmdsZSBwYWNrZXQgaW4gcXVldWUgYW5k IHNvIHRoZSBzYW1lDQpzbG90IG1pZ2h0IGJlIHNoYXJlZCB3aXRob3V0IGhhc2ggY29saXNpb25z Lg0KcHJvcG9zZWQgcGF0Y2ggOg0KDQotLS0ga2VybmVsL2xpbnV4LTIuNC4xOC9uZXQvc2NoZWQv c2NoX3NmcS5jICAgICBUdWUgTWF5ICA3IDE2OjIyOjIzIDIwMDINCg0KKysrIHNjaF9zZnEuYyAg IFR1ZSBBdWcgMjAgMTg6MDc6MDMgMjAwMg0KQEAgLTM0Myw2ICszNDMsNyBAQA0KICAgICAgICBp ZiAocS0+cXNbYV0ucWxlbiA9PSAwKSB7DQogICAgICAgICAgICAgICAgYSA9IHEtPm5leHRbYV07 DQogICAgICAgICAgICAgICAgaWYgKGEgPT0gb2xkX2EpIHsNCisgICAgICAgICAgICAgICAgICAg ICAgIHEtPmh0W3EtPmhhc2hbYV1dID0gU0ZRX0RFUFRIOw0KICAgICAgICAgICAgICAgICAgICAg ICAgcS0+dGFpbCA9IFNGUV9ERVBUSDsNCiAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiBz a2I7DQogICAgICAgICAgICAgICAgfQ0KDQphbnkgY29tbWVudHMgPw0KDQotLQ0KVmluY2VudCBF R0FMDQpFbWFpbCA6IGVnYWxAaXBhbmVtYXRlY2guY29tDQoNCg0KDQotLS0tLS0tLS0tLS0tLTE3 NDUyREVDNkYwQzcyNTc2RTdFNTEyNg0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9 dXMtYXNjaWkNCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQNCg0KPCFkb2N0eXBlIGh0 bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwvL2VuIj4NCjxodG1s Pg0KaGksDQo8YnI+SSBmb3VuZCBhIHN0cmFuZ2UgYmVoYXZpb3Igd2l0aCBTRlEgcWRpc2Mgd2hl biBzZXZlcmFsIFRDUCBmbG93cyBzdGFydA0KYXQgdGhlIHNhbWUgdGltZTombmJzcDsgZGVzcGl0 ZSBoYXZpbmcgZGlmZmVyZW50IGhhc2ggdmFsdWVzICwgdGhleSBoYXZlDQphIGdvb2QgY2hhbmNl cyB0byBmYWxsIGluIHRoZSBzYW1lIHNsb3Qgd2hpY2ggaW1wbGllcyBubyBtb3JlIGZhaXJuZXNz DQp0aGFuIGEgc2ltcGxlIEZJRk8uDQo8YnI+VGhpcyBpcyBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0 aGUgaGFzaCB0YWJsZSBmb3IgYSBmbG93IGlzIG5vdCBjbGVhcmVkDQphZnRlciBkZXF1ZXVpbmcg YSBzbG90IHdoaXRoIGEgc2luZ2xlIHBhY2tldCBpbiBxdWV1ZSBhbmQgc28gdGhlIHNhbWUgc2xv dA0KbWlnaHQgYmUgc2hhcmVkIHdpdGhvdXQgaGFzaCBjb2xpc2lvbnMuDQo8YnI+cHJvcG9zZWQg cGF0Y2ggOg0KPHA+LS0tIGtlcm5lbC9saW51eC0yLjQuMTgvbmV0L3NjaGVkL3NjaF9zZnEuYyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVHVlIE1heSZuYnNwOyA3IDE2OjIyOjIzIDIwMDINCjxi cj4rKysgc2NoX3NmcS5jJm5ic3A7Jm5ic3A7IFR1ZSBBdWcgMjAgMTg6MDc6MDMgMjAwMg0KPGJy PkBAIC0zNDMsNiArMzQzLDcgQEANCjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaWYgKHEtPnFzW2FdLnFsZW4gPT0gMCkNCnsNCjxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCmEgPSBxLT5uZXh0W2FdOw0KPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KaWYgKGEgPT0gb2xkX2EpIHsNCjxicj4rJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQpxLT5odFtxLT5oYXNoW2FdXSA9IFNGUV9ERVBUSDsNCjxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCnEtPnRhaWwgPSBTRlFfREVQVEg7DQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQpyZXR1cm4gc2tiOw0KPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KfQ0KPHA+YW55IGNvbW1lbnRzID8NCjxwcmU+LS0mbmJzcDsNClZpbmNlbnQgRUdBTA0KRW1h aWwgOiBlZ2FsQGlwYW5lbWF0ZWNoLmNvbQ0KPC9wcmU+DQombmJzcDs8L2h0bWw+DQoNCi0tLS0t LS0tLS0tLS0tMTc0NTJERUM2RjBDNzI1NzZFN0U1MTI2LS0NCg0KDQotLV9fLS1fXy0tDQoNCk1l c3NhZ2U6IDkNCkZyb206IElzYW1wIDxpc2FtcEB0ZXJyYS5jb20uYnI+DQpUbzogbGFydGNAbWFp bG1hbi5kczlhLm5sDQpEYXRlOiBUdWUsIDIwIEF1ZyAyMDAyIDE2OjE0OjMzIC0wMzAwDQpTdWJq ZWN0OiBbTEFSVENdIEZyZWVTV0FOIGFuZCBJUFJPVVRFMg0KDQpIaSBQZW9wbGUgISEhDQoNCkkn bSBhIG5ld2JpZSBpbiB0aGlzIGxpc3QgYW5kIGluIHRoaXMgY29uY2VwdHMuDQpQbGVhc2UsIEkg bmVlZCBoZWxwIHRvIGxlYXJuIG1vcmUgYWJvdXQgcm91dGluZyB0b29scyBvbiBMaW51eCBhbmQg aXRzIGluPQ0KdGVyYWN0aW9uIHdpdGggRnJlZVNXQU4gYW5kIElQVGFibGVzLg0KDQpJIGp1c3Qg cmVhZCB0aGUgIkZ1biB3aXRoIGlwcm91dGUyIGFuZCBGcmVlUy9XQU4iICh3d3cucXVpbnRpbGlv bi5jb20vbW9hPQ0KdC9pcHNlYytyb3V0aW5nL2lwcm91dGUyLmh0bWwsPTIwDQp2ZXJ5LCB2ZXJ5 LCB2ZXJ5IGdvb2QgdGV4dCkgZG9jdW1lbnQgYnV0LCBJIG5lZWQgbW9yZSAhISENCg0KT24gbXkg cHJvamVjdCwgSSdtIHRpbmtpbmcgaW4gYSBsb3Qgb2YgbGludXggYm94ZXMgd2l0aCAyIG9yIG1v cmUgdXBsaW5rcz0NCiwgbGlrZSB0aGlzOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgRnJh bWUgUmVsYXkgdXBsaW5rDQogICAgICAgICAgICAgICAgICAvLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tXA0KICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBcDQp8ICAgICstLS0tLS0tLS0rLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBcKy0tLS0tLS0tLSsgICAgfA0KKy0tLS0rTGludXggQm94fC0tLT0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj0zRD0zRD0zRD0zRD0zRD0z RD0zRD0zRD0zRD0zRD0zRD0zRC0tLXxMaW51eCBCb3h8LS0tLSsNCnwgICAgKy0tLS0tLS0tLStc ICAgICAgICAgICBJUFNFQyB3aXRoICAgICAgICAgICAgIC8rLS0tLS0tLS0tKyAgICB8DQogICAg ICAgICAgICAgICAgIFwgICAgICAgICAgRnJlZVMvV0FOICAgICAgICAgICAgIC8NCiAgICAgICAg ICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQogICAgICAgICAgICAg ICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQogICAgICAgICAgICAgICAgICAg IFwtLS0tLS0tLS0tK1BPVFMrLS0tLS0tLS0tLS8NCiAgICAgICAgICAgICAgICAgICAgICAgICAg IERpYWwgb24gRGVtYW5kDQoNCk9uIG15IHRlc3RzLCB3aGVuIHRoZSB0dW5uZWwgaXMgZG93bmVk LCB0aGUgcm91dGluZyB0YWJsZSBpcyB1cGRhdGVkIGJ1dCw9DQogaWYgdGhlIHR1bm5lbCBicm9r ZSw9MjANCnRoZSBrZXJuZWwgcm91dGluZyB0YWJsZSBwZXJzaXN0cyB3aXRoIHJvdXRlcyBhZGRl ZCBieSBmcmVlU1dBTi4NCg0KSSdtIHRoaW5raW5nIHRvIHVzZSBPU1BGIChaZWJyYSBvciBCSVJE KTogb24gdGhpcyBwcm90b2NvbCB3ZSBoYXZlIHRoZSAnaD0NCmVsbycgcGFja2V0cyB0byBkZXRl cm1pbmUNCnRoZSBjdXJyZW50IHN0YXRlIG9mIGxpbmtzIGJ1dCwgaXBzZWMgaW50ZXJmYWNlIGlz IG5vdCBhIG11bHRpY2FzdCBpbnRlcmY9DQphY2UgIQ0KUmVhZGluZyAiTGludXggQWR2YW5jZWQg Um91dGluZyAmIFRyYWZmaWMgQ29udHJvbCBIT1dUTyIgKGh0dHA6Ly9sYXJ0Yy5vcj0NCmcvaG93 dG8vLA0KdmVyeSBnb29kIGRvY3VtZW50IHRvbyksIGluIGNoYXB0ZXIgNS4zIHdlIGNhbiByZWFk PTIwDQoNCiJHUkUgaXMgYSB0dW5uZWxpbmcgcHJvdG9jb2wgdGhhdCB3YXMgb3JpZ2luYWxseSBk ZXZlbG9wZWQgYnkgQ2lzY28sIGFuZCA9DQppdCBjYW4gZG89MjANCmEgZmV3IG1vcmUgdGhpbmdz IHRoYW4gSVAtaW4tSVAgdHVubmVsaW5nLiBGb3IgZXhhbXBsZSwgeW91IGNhbiBhbHNvIHRyYW49 DQpzcG9ydD0yMA0KbXVsdGljYXN0IHRyYWZmaWMgYW5kIElQdjYgdGhyb3VnaCBhIEdSRSB0dW5u ZWwuIi4NCg0KU28sIFdoYXQgSSB1c2UgPyBJcHNlYyB0dW5uZWxzIGZyb20gRnJlZVMvV0FOIG9y IEdSRSBUdW5uZWxzID8gQm90aCA/IEhvdz0NCiA/DQpUaGUgdHJhZmZpYyBvdmVyIEdSRSBUdW5u ZWwgYXJlIGVuY3JpcHRlZCA/IEhvdyA/DQoNCkknbSB0aW5raW5nIHRvIHVzZSB0aGUgT1NQRiBw cm90b2NvbCAoWmVicmEpIGRvIG1ha2UgYSBsb2FkIGJhbGFuY2UgYmV0d2U9DQplbiBGcmFtZVJl bGF5IGFuZA0KaXBzZWMgaW50ZXJmYWNlcyBidXQsIGluIHNhbWUgSE9XVE8gKCJGdW4uLi4iKSBJ IHNlZSB0aGUgbmV3IHBvc3NpYmlsaXRpZT0NCiB3aXRoIGlwcm91dGUyLg0KV2hhdCBpcyBiZXR0 ZXIgPw0KDQpTb21lb25lIGhhdmUgaW50ZXJlc3QgaW4gdGhpcyBzb2x1dGlvbiA/IFNvbWVvbmUg Y2FuIGhlbHAgbWUgPw0KDQpUYW5rcyBpbiBBZHZhbmNlIC4NCg0KDQoNCklzYW1wDQoNCg0KcHMu OiBzb3JyeSBmb3IgbXkgcG9vciBlbmdsaXNoICEhIQ0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2Fn ZTogMTANCkRhdGU6IFdlZCwgMjEgQXVnIDIwMDIgMDA6MTA6MjIgKzAwMDAgKEdNVCkNCkZyb206 IEp1bGlhbiBBbmFzdGFzb3YgPGphQHNzaS5iZz4NClRvOiBBcmluZGFtIEhhbGRhciA8YXJpbmRh bWhhbGRhckBpbmJveC5sdj4NCkNjOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFJl OiBbTEFSVENdIE11bHRpIFJvdXRpbmcgUHJvYmxlbS4NCg0KDQoJSGVsbG8sDQoNCk9uIE1vbiwg MTkgQXVnIDIwMDIsIEFyaW5kYW0gSGFsZGFyIHdyb3RlOg0KDQo+ICYgYXBwbGllZCBqdWxpYW4n cyBwYXRjaCB0byBrZXJuZWwgMi40LjE5ICYgaGF2ZSBnb25lIHRocnUgdGhlIGRvY3MgYXQNCj4g dGhlIHNpdGUuLi4gaSBoYXZlIGRlZmluZWQgYmFzaWNhbGx5IDMgZ3JvdXBzIGZvciBjbGllbnRz LS0+IGNhY2hlLA0KPiBjaXNjbywgYmFsYW5jZS4uIHRoZSBuYW1lIHNwZWNpZmllcyB0aGUgaW1w b3J0YW5jZS4uIHRoaXMgaXMgdGhlIGRldGFpbHMNCj4gb2Ygd2hhdCBpIGRpZC0tPg0KDQoJQ2Fy ZWZ1bGx5IGFuYWx5emUgdGhlIGRvY3MuLi4NCg0KPiBbcm9vdEBMcjEgcm9vdF0jIGlwIHJ1bGUg bHMNCj4gMDogICAgICBmcm9tIGFsbCBsb29rdXAgbG9jYWwNCg0KCSMgZGlyZWN0IGNvbW11bmlj YXRpb25zIGFyZSBmaXJzdCBwcmlvcml0eQ0KCWlwIHJ1bGUgYWRkIHByaW8gNSB0YWJsZSBtYWlu DQoNCj4gMTA6ICAgICBmcm9tIEVYVG5BLjEyNC8yNSBsb29rdXAgT05FDQo+IDIwOiAgICAgZnJv bSBFWFRuQi4xMDYvMjYgbG9va3VwIFRXTw0KPiAxMDA6ICAgIGZyb20gMTkyLjE2OC4xLjEwIGxv b2t1cCBDQUNIRQ0KPiAxMDE6ICAgIGZyb20gMTkyLjE2OC4xLjIwIGxvb2t1cCBDSVNDTw0KPiAx NTA6ICAgIGZyb20gMTkyLjE2OC4xLjMwIGxvb2t1cCBCQUxBTkNFDQo+IDIwMDogICAgZnJvbSBh bGwgbG9va3VwIE1FDQo+IDMyNzY2OiAgZnJvbSBhbGwgbG9va3VwIG1haW4NCj4gMzI3Njc6ICBm cm9tIGFsbCBsb29rdXAgMjUzDQoNCj4gQlVUIGFtICoqTk9UKiogYWJsZSB0byBzdXJmIGF0IGFs bCBmcm9tIGludGVybmFsIG5ldHdvcmsuLi4gbm90IGV2ZW4NCj4gYWJsZSB0byBwaW5nIGV0aDIg ISEhLi4gZGVmYXVsdCBJTlBVVCAmIE9VVFBVVCBhcmUgc2V0IHRvIEFDQ0VQVCB3aGlsZQ0KPiBG T1JXQVJEIGlzIERST1AuLg0KDQoJRmlyc3QgdHJ5IHdpdGggYWxsIEFDQ0VQVC4NCg0KPiB3aGF0 cyBtaXNzaW5nIHRoZXJlID8uLiBhZnRlciB0cnlpbmcgYWxsIGRheSBpIHdhbnQgZ3VpZGFuY2Ug bm93Li4uDQo+IGF3YWl0aW5nIGEgcmVwbHkgdmVyeSBhbnhpb3VzbHkuLi4uDQoNCglZb3VyIHNl dHVwIGlzIGEgYml0IHN0cmFuZ2U6IGludGVybmFsIGhvc3RzIHVzZSBzb21lIGdhdGV3YXlzLA0K dGhlIGV4dGVybmFsIGFkZHJlc3NlcyB1c2UgZGlmZmVyZW50IGdhdGV3YXlzLiBUaGUgcHJvYmxl bSBpcyB0aGF0DQppZiB5b3UgYXJlIHVzaW5nIE5BVCBhbmQgZm9yIGV4YW1wbGUgMTkyLjE2OC4x LjEwIGlzIFNOQVQtZWQgdGhlDQpwYWNrZXQgd2lsbCBsZWF2ZSB3aXRoIG5ldyBzYWRkciAodGhl IG1hc3F1ZXJhZGUgYWRkcmVzcykuIExvb2tpbmcNCmluIHlvdXIgcnVsZXMgdGhlcmUgaXMgZGlm ZmVyZW50IGdhdGV3YXkgZm9yIHRoZSBtYXNxdWVyYWRlDQphZGRyZXNzLiBUaGlzIGNhbid0IHdv cmsuIFRoZSBjdXJyZW50IGZyYW1ld29yayByZXF1aXJlcyB0aGF0Og0KDQotIGlmIG9uZSBpbnRl cm5hbCBJUCBpcyBtYXNxdWVyYWRlZCB0byBhIHNwZWNpZmljIGFkZHJlc3MsIHlvdQ0KbmVlZCB0 aGUgMiByb3V0ZXMgdG8gYmUgc2ltaWxhciwgaS5lLjoNCg0KCWZyb20gSU5UX0lQIHRvIFRBUkdF VA0KCWFuZA0KCWZyb20gTUFTUV9JUCB0byBUQVJHRVQNCg0KdG8gdXNlIHNhbWUgZ2F0ZXdheSBh bmQgZGV2aWNlLiBUaGlzIGlzIGV2ZW4gbWFuZGF0b3J5IGZvciB0aGUNCnBhdGNoZXMuIEN1cnJl bnRseSwgdGhlIGZpcnN0IHBhY2tldCBmb3Igb25lIGNvbm5lY3Rpb24gaXMgcm91dGVkDQp2aWEg dGhlIHJvdXRlICJmcm9tIElOVF9JUCB0byBUQVJHRVQiLCB0aGUgU05BVCBydWxlcyBhc3NpZ24N Cm1hc3F1ZXJhZGUgYWRkcmVzcyBhdCBwb3N0cm91dGluZyBhbmQgdGhlbiBhbGwgbmV4dCBwYWNr ZXRzIGFyZQ0Kcm91dGVkIHZpYSB0aGUgMm5kIHJvdXRlIC0gMSByb3V0ZSBwZXIgZm9yd2FyZGVk IHBhY2tldC4gSXQgaXMgYQ0KYml0IHN0cmFuZ2UgdGhlc2UgdHdvIHJvdXRlcyB0byB1c2UgZGlm ZmVyZW50IGdhdGV3YXlzLiBEbyB5b3UNCmhhdmUgYSBnb29kIHJlYXNvbiBmb3IgdGhpcz8NCg0K CUFsc28gbm90ZSB0aGF0IHJ1bGVzIGluIHRoZSBmb3JtICJmcm9tIDAvMCB0byBBTllfVEFSR0VU Ig0Kd2hlcmUgQU5ZX1RBUkdFVCBjYW4gYmUgYW55IHN1Ym5ldCBpbmNsdWRpbmcgMC8wIGFyZSB1 c2VkIGZvcg0Kc291cmNlIGFkZHJlc3MgYXV0b3NlbGVjdGlvbiAtIHRoZSByZXN1bHRpbmcgcHJl ZmVycmVkIHNvdXJjZSBJUA0KaXMgdXNlZCBhcyBzYWRkci4gSXQgaXMgbm90IHVzZWQgb25seSBh cyAiZGVmYXVsdCIgcnVsZS4gU28sDQpwbGF5aW5nIHRyaWNrcyB3aXRoIGRpZmZlcmVudCBnYXRl d2F5cyBpcyBub3QgcG9zc2libGUuIFRoZQ0Kc2V0dXAgaXMgYW1iaWd1b3VzIGlmIE5BVCBpcyBp bnZvbHZlZC4NCg0KPiBBLkgNCg0KUmVnYXJkcw0KDQotLQ0KSnVsaWFuIEFuYXN0YXNvdiA8amFA c3NpLmJnPg0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogMTENCkRhdGU6IFdlZCwgMjEgQXVn IDIwMDIgMDA6MjU6NDAgKzAwMDAgKEdNVCkNCkZyb206IEp1bGlhbiBBbmFzdGFzb3YgPGphQHNz aS5iZz4NClRvOiBDYWx2aW4gRG9kZ2UgPGNhbGRvZGdlQGZwY2MubmV0Pg0KQ2M6IGxhcnRjQG1h aWxtYW4uZHM5YS5ubA0KU3ViamVjdDogUmU6IFtMQVJUQ10gdXBsaW5rIHdpdGggbXVsdGlwbGUg bGluZXMNCg0KDQoJSGVsbG8sDQoNCk9uIFR1ZSwgMjAgQXVnIDIwMDIsIENhbHZpbiBEb2RnZSB3 cm90ZToNCg0KPiBUd28gb2YgdGhlIG1vZGVtcyBfZG9fIGhhdmUgcHJpdmF0ZSBJUCBhZGRyZXNz ZXMgKDE5Mi4xNjgueC4xKSAtIGNvdWxkDQo+IHRoYXQgYmUgY29uZnVzaW5nIHRoZSBrZXJuZWw/ IElmIHNvLCBkbyBJIG5lZWQgdG8gZ2V0IHB1YmxpYyBJUA0KPiBhZGRyZXNzZXMgZm9yIHRob3Nl IG1vZGVtcz8NCg0KCUFGQUlLLCB0aGVyZSBpcyBub3QgZmxhZyAicHVibGljIiBmb3IgdGhlIElQ IGFkZHJlc3NlcyBpbg0KTGludXgsIGF0IGxlYXN0LCBub3QgaW4gSVB2NC4gVGhlIGtlcm5lbCBk b2VzIG5vdCBrbm93IGFueXRoaW5nDQphYm91dCBwcml2YXRlL3Jlc2VydmVkIElQIHJhbmdlcy4N Cg0KPiBEbyBJIEhBVkUgdG8gY3JlYXRlIGEgcGF0Y2hlZCBrZXJuZWwgKGFsYSBBbmFzdGFzb3Yp Pw0KDQoJTWF5IGJlIG5vdC4gQnV0IHlvdSBjYW4gdHJ5IHRvIHVuZGVyc3RhbmQgdGhlIHNldHRp bmdzDQpwcm92aWRlZCBpbiB0aGUgZG9jcy4gVGhlIGVzc2VudGlhbCB0aGluZyB0byB1bmRlcnN0 YW5kIGlzIGhvdw0KdGhlIGlwIHJ1bGVzIGFuZCByb3V0ZXMgYXJlIG9yZGVyZWQsIGhvdyB0aGUg TkFUIHVzZXMgdGhlDQpyb3V0aW5nLCB3aHkgdGhlIE5BVCBpbiBwbGFpbiBrZXJuZWxzIHNvbWV0 aW1lcyBicmVha3Mgd2l0aA0KbXVsdGlwYXRoIHJvdXRlcywgd2hhdCBraW5kIG9mIG5leHRob3Bz IHRoZSBrZXJuZWwgY2FuIGxpdmUNCndpdGgsIGNhbiB5b3UgbGl2ZSB3aXRob3V0IGRlYWQgZ2F0 ZXdheSBkZXRlY3Rpb24sIGlmIG5vdCwgaG93DQppdCB3b3JrcyAoaW4ga2VybmVsPyBoZWxwIGZy b20gdXNlciBzcGFjZT8pLCBldGMuDQoNCj4gTWF5IEkgcG9zdCB0aGUgc2NyaXB0IEkgdXNlZCB0 byB0cnkgdGhpcyBvdXQ/DQoNCglPciBpZiBwb3NzaWJsZSB0byBwcm92aWRlIHJlZmVyZW5jZSB0 byBpdCBhZnRlciB0aGUgNXRoDQpyZWFkaW5nIG9mIGFsbCBkb2NzIDopDQoNCj4gVGhhbmtzLCBm b2xrcyENCj4NCj4gQ2FsdmluIERvZGdlDQo+IENlcnRpZmllZCBMaW51eCBCaWdvdCAodG0pDQo+ IGh0dHA6Ly93d3cuY2FsZG9kZ2UuZnBjYy5uZXQNCg0KUmVnYXJkcw0KDQotLQ0KSnVsaWFuIEFu YXN0YXNvdiA8amFAc3NpLmJnPg0KDQoNCg0KLS1fXy0tX18tLQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTEFSVEMgbWFpbGluZyBsaXN0DQpMQVJU Q0BtYWlsbWFuLmRzOWEubmwNCmh0dHA6Ly9tYWlsbWFuLmRzOWEubmwvbWFpbG1hbi9saXN0aW5m by9sYXJ0Yw0KDQoNCkVuZCBvZiBMQVJUQyBEaWdlc3QNCg0K --MIME MULTIPART BOUNDARY=.1029878952:+'1 Content-Type: text/plain; charset=US-ASCII Content-Id: <723468053-3@softerware.com> Content-Transfer-Encoding: 7bit I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #728 - 11 msgs From: lartc@mailman.ds9a.nl Date: 08/20/02 18:25:03 This item was automatically created and contains MIME Information. --MIME MULTIPART BOUNDARY=.1029878952:+'1-- From jma@nsicomm.com Tue Aug 20 23:21:52 2002 From: jma@nsicomm.com (James Ma) Date: Tue, 20 Aug 2002 18:21:52 -0400 Subject: [LARTC] iproute and iptables Message-ID: <009c01c24897$fc9ffc40$7c010a0a@nsicomm.com> This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C24876.7518DE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I am newbie. However, I tried iptables recently and succeeded. I don't = understand the relationship between iptables and iproute2, is iproute = used to replace iptables? Thanks, James ------=_NextPart_000_0099_01C24876.7518DE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I am newbie. However, I tried iptables = recently and=20 succeeded. I don't understand the relationship between iptables and = iproute2, is=20 iproute used to replace iptables?
 
Thanks,
 
James
------=_NextPart_000_0099_01C24876.7518DE20-- From arny@ats.s.bawue.de Tue Aug 20 23:26:43 2002 From: arny@ats.s.bawue.de (Thilo Schulz) Date: Wed, 21 Aug 2002 00:26:43 +0200 Subject: [LARTC] iproute and iptables In-Reply-To: <009c01c24897$fc9ffc40$7c010a0a@nsicomm.com> References: <009c01c24897$fc9ffc40$7c010a0a@nsicomm.com> Message-ID: <200208210026.43170.arny@ats.s.bawue.de> Am Mittwoch, 21. August 2002 00:21 schrieb James Ma: > Dear all, > > I am newbie. However, I tried iptables recently and succeeded. I don't > understand the relationship between iptables and iproute2, is iproute u= sed > to replace iptables? No. The iproute2 utilities allow to set various things, such as ip addres= ses,=20 routing entries or the traffic shaper. The iptables tool is responsible for the firewall and the rules in there = - as=20 well as some packet mangling and network address translation. You can com= bine=20 both tools with the -j MARK directive .. rtfm ;-) - Thilo Schulz From amitk@ittc.ku.edu Wed Aug 21 04:32:13 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Tue, 20 Aug 2002 22:32:13 -0500 (CDT) Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ In-Reply-To: Message-ID: On Fri, 16 Aug 2002, Stef Coene wrote: >> The 'ceil' parameter allows us to implement a part of the 'isolated' >> definition above. By setting it equal to 'rate', the class does not >> borrow bandwidth, but what will stop other classes from borrowing its >> unused bandwidth? > > Providing no ceil parameter means rate = ceil. But this can not be > used to implement isolated like in cbq. Rate = ceil means the class > can not use more bandwidth then it's rate. Isolated in cbq means other > classes can not borrow bandwidth from the class and that's not the > same. There is no way you can implement isolated with htb. > > But with htb you can do something like this : > > Total : 100 > class1 rate 20 ceil 20 > class2 rate 40 ceil 80 > class3 rate 40 ceil 80 > > class 1 is isolated like in cbq. It can not use more then it's > rate/ceil and class2 and class3 will never use bandwidth from class1, > only from each other. Just like the definition of isolated :) What happens when there is no traffic in class 1? Will class 2 and 3 share class 1's bandwidth then? The reason I am asking these questions is because I am trying to see if HTB can be used in place of CBQ in Diffserv. Has anybody tried something like this? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From mikep02@softerware.com Wed Aug 21 05:30:22 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Wed, 21 Aug 2002 00:30:22 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #730 - 3 msgs Message-ID: <651191453@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #730 - 3 msgs From: lartc@mailman.ds9a.nl Date: 08/21/02 01:27:45 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. iproute and iptables (James Ma) 2. Re: iproute and iptables (Thilo Schulz) 3. Re: HTB equivalent for 'bounded' and 'isolated' in CBQ (Amit Kucheria) --__--__-- Message: 1 From: "James Ma" To: Date: Tue, 20 Aug 2002 18:21:52 -0400 Subject: [LARTC] iproute and iptables This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C24876.7518DE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I am newbie. However, I tried iptables recently and succeeded. I don't = understand the relationship between iptables and iproute2, is iproute = used to replace iptables? Thanks, James ------=_NextPart_000_0099_01C24876.7518DE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I am newbie. However, I tried iptables = recently and=20 succeeded. I don't understand the relationship between iptables and = iproute2, is=20 iproute used to replace iptables?
 
Thanks,
 
James
------=_NextPart_000_0099_01C24876.7518DE20-- --__--__-- Message: 2 From: Thilo Schulz To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] iproute and iptables Date: Wed, 21 Aug 2002 00:26:43 +0200 Am Mittwoch, 21. August 2002 00:21 schrieb James Ma: > Dear all, > > I am newbie. However, I tried iptables recently and succeeded. I don't > understand the relationship between iptables and iproute2, is iproute u= sed > to replace iptables? No. The iproute2 utilities allow to set various things, such as ip addres= ses,=20 routing entries or the traffic shaper. The iptables tool is responsible for the firewall and the rules in there = - as=20 well as some packet mangling and network address translation. You can com= bine=20 both tools with the -j MARK directive .. rtfm ;-) - Thilo Schulz --__--__-- Message: 3 Date: Tue, 20 Aug 2002 22:32:13 -0500 (CDT) From: Amit Kucheria To: lartc@mailman.ds9a.nl Cc: stef.coene@docum.org Subject: Re: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ On Fri, 16 Aug 2002, Stef Coene wrote: >> The 'ceil' parameter allows us to implement a part of the 'isolated' >> definition above. By setting it equal to 'rate', the class does not >> borrow bandwidth, but what will stop other classes from borrowing its >> unused bandwidth? > > Providing no ceil parameter means rate = ceil. But this can not be > used to implement isolated like in cbq. Rate = ceil means the class > can not use more bandwidth then it's rate. Isolated in cbq means other > classes can not borrow bandwidth from the class and that's not the > same. There is no way you can implement isolated with htb. > > But with htb you can do something like this : > > Total : 100 > class1 rate 20 ceil 20 > class2 rate 40 ceil 80 > class3 rate 40 ceil 80 > > class 1 is isolated like in cbq. It can not use more then it's > rate/ceil and class2 and class3 will never use bandwidth from class1, > only from each other. Just like the definition of isolated :) What happens when there is no traffic in class 1? Will class 2 and 3 share class 1's bandwidth then? The reason I am asking these questions is because I am trying to see if HTB can be used in place of CBQ in Diffserv. Has anybody tried something like this? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ --__--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest From blackoutz@yahoo.com Wed Aug 21 05:47:07 2002 From: blackoutz@yahoo.com (zain arrifa'i) Date: Tue, 20 Aug 2002 21:47:07 -0700 (PDT) Subject: [LARTC] HTB and bridge... In-Reply-To: Message-ID: <20020821044707.75403.qmail@web40206.mail.yahoo.com> does anyone know about HTB shaping in a bridging machine? I currently run my shaper box as bridge and something is going strange, such as a class cannot send at rate it supposed to. I mean if anyone know something about bridging and its htb shaping behavior. thanks in advance. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From arindamhaldar@inbox.lv Wed Aug 21 11:58:31 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Wed, 21 Aug 2002 16:28:31 +0530 Subject: [LARTC] Multi Routing Problem. References: Message-ID: <3D637257.3010202@inbox.lv> hi again, :) i tried again & now am succesfull.. :) this is my script #!/bin/sh ipr="/sbin/ip" NetExtA="...6.64/26" IPExtA="....6.106" GtExtA="....6.70" NetExtB="...9.0/25" IPExtB="....9.124" GtExtB="....9.1" Netlcl="172.31.13.0/24" IPlcl="172.31.13.1" NetgrpA="172.31.13.10/31" NetgrpB="172.31.13.20/31" NetgrpC="172.31.13.30/31" $ipr rule del prio 99 from $NetExtA $ipr rule del prio 98 from $NetgrpA $ipr rule del prio 74 from $NetExtB $ipr rule del prio 73 from $NetgrpB $ipr rule del prio 49 from $NetgrpC # $ipr rule del prio 48 echo 100 EXTnA >> /etc/iproute2/rt_tables echo 75 EXTnB >> /etc/iproute2/rt_tables echo 50 BALANCE >> /etc/iproute2/rt_tables $ipr rule add prio 99 from $NetExtA table EXTnA $ipr rule add prio 98 from $NetgrpA table EXTnA $ipr rule add prio 74 from $NetExtB table EXTnB $ipr rule add prio 73 from $NetgrpB table EXTnB $ipr rule add prio 49 from $NetgrpC table BALANCE # $ipr rule add prio 48 table BALANCE $ipr route add default table EXTnB via $GtExtB dev eth1 src $IPExtB $ipr route add $NetgrpB via $IPlcl dev eth2 table EXTnB $ipr route add default table EXTnA via $GtExtA dev eth0 src $IPExtA $ipr route add $NetgrpA via $IPlcl dev eth2 table EXTnB $ipr route add default table BALANCE nexthop via $GtExtB dev eth1 nexthop via $GtExtA dev eth0 $ipr route add $NetgrpC via $IPlcl dev eth2 table EXTnB things work fine from the client's end, and follows the routing/balancing as defined.. but when i use **2 append ** ip route commands to table BALANCE--viz ip route append default via $GtExtB dev eth1 ta BALANCE ip route append default via $GtExtA dev eth0 ta BALANCE then everything **STOPS**... WHY ???? julian u wrote in ur mail about adding >>>ip rule add prio 5 ta main & i also saw it in the docs too but i couldnt understand the importance.. more so coz there was no routing attached to this prio.. will the default route of ta main(32766) be carried to table main (prio 5) ??.. can u please tell me more about it ?... awaitng a reply thanking u in advance A.H Julian Anastasov wrote: > Hello, > > On Mon, 19 Aug 2002, Arindam Haldar wrote: > > >>& applied julian's patch to kernel 2.4.19 & have gone thru the docs at >>the site... i have defined basically 3 groups for clients--> cache, >>cisco, balance.. the name specifies the importance.. this is the details >>of what i did--> > > > Carefully analyze the docs... > > >>[root@Lr1 root]# ip rule ls >>0: from all lookup local > > > # direct communications are first priority > ip rule add prio 5 table main > From osraza@yahoo.com Wed Aug 21 14:22:59 2002 From: osraza@yahoo.com (AOUN RAZA) Date: Wed, 21 Aug 2002 06:22:59 -0700 (PDT) Subject: [LARTC] QOs with ipv6 Message-ID: <20020821132259.18923.qmail@web20609.mail.yahoo.com> Hallo , i want to create qdisc with u32 by using tc. my question is how to compare ipv6 header Class field with cbq or tbf.. can some body give me some little example with ipv6 ..header checking queue. Aoun raza. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From p0wer@tl.krakow.pl Wed Aug 21 16:03:05 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Wed, 21 Aug 2002 17:03:05 +0200 (CEST) Subject: [LARTC] HTB and bridge... In-Reply-To: <20020821044707.75403.qmail@web40206.mail.yahoo.com> Message-ID: On Tue, 20 Aug 2002, zain arrifa'i wrote: > does anyone know about HTB shaping in a bridging > machine? > I currently run my shaper box as bridge and something > is going strange, such as a class cannot send at rate > it supposed to. > I mean if anyone know something about bridging and its > htb shaping behavior. > thanks in advance. I don't know about HTB but I had such configuration: ,------------------------------. | ,-- eth0 -+--> Seg1 INET ----+-> ppp0 -- ROUTER --+ (bridge)| | (fwall) `-- eth1 -+--> Seg2 `------------------------------' and I succeded in firewalling and shaping one of the segments with CBQ (just limiting to some rate, in this example INET=192kbit, seg1=64kbit). It just worked, of course after applying the correct patches fr bridge firewalling into the kernel... -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From yans@endeavour.eu.org Wed Aug 21 16:52:08 2002 From: yans@endeavour.eu.org (Yans van Horn) Date: Wed, 21 Aug 2002 17:52:08 +0200 Subject: [LARTC] HTB problem (yet another one?) Message-ID: <003b01c2492a$b4b7e580$8002a8c0@typhoon> Hello I have a small (maybe typical?) problem with HTB. Present configuration is: Kernel: 2.4.20-pre4 (with HTB, IMQ) endeavour:/var/log# tc -V tc utility, iproute2-ss010824 Which should support HTB because writes help for it ;-) endeavour:~# tc qdisc add dev imq0 root handle 1 htb ttt What is "ttt"? Usage: ... qdisc add ... htb [default N] [r2q N] default number of class to which unclassified packets are sent {1} endeavour:~# ip link show 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:50:ba:d4:9d:50 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:48:54:55:54:d1 brd ff:ff:ff:ff:ff:ff 4: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:24:d5:ae:33 brd ff:ff:ff:ff:ff:ff 5: ppp0: mtu 1656 qdisc pfifo_fast qlen 3 link/ppp 6: ppp1: mtu 1656 qdisc pfifo_fast qlen 3 link/ppp 7: imq0: mtu 1500 qdisc pfifo_fast qlen 30 link/void I should have all the needed modules also: endeavour:~# lsmod Module Size Used by Not tainted ipt_IMQ 760 1 (autoclean) sch_htb 18048 0 (autoclean) (unused) imq 1864 1 cls_route 4088 0 (unused) cls_u32 4540 0 cls_fw 2360 0 (unused) sch_prio 2368 0 (unused) sch_sfq 3520 0 (unused) sch_tbf 2432 0 sch_cbq 11744 0 ipt_MARK 792 73 (autoclean) iptable_mangle 2196 1 (autoclean) ipt_REDIRECT 824 3 (autoclean) ipt_nth 1280 2 (autoclean) ipt_REJECT 2840 2 (autoclean) iptable_filter 1672 1 (autoclean) ppp_deflate 2904 2 (autoclean) zlib_inflate 18436 0 (autoclean) [ppp_deflate] zlib_deflate 17720 0 (autoclean) [ppp_deflate] bsd_comp 3992 0 (autoclean) 3c59x 24560 1 ip_nat_ftp 2864 0 (unused) iptable_nat 14040 2 [ipt_REDIRECT ip_nat_ftp] ip_conntrack_ftp 3760 1 ip_conntrack 16448 2 [ipt_REDIRECT ip_nat_ftp iptable_nat ip_conntrack_ftp] ip_tables 10552 10 [ipt_IMQ ipt_MARK iptable_mangle ipt_REDIRECT ipt_nth ipt_REJECT iptable_filter iptable_nat] ------------------------------------------------------------------------- And the PROBLEM: When i try to add qdisc to the imq device.. a get: endeavour:~# tc qdisc add dev imq0 root handle 1 htb default 20 r2q 10 RTNETLINK answers: Invalid argument ------------------------------------------------------------------------- BTW: Adding CBQ qdisc to imq0 works fine... Any suggestions ? -- regards, Marcin 'Yans' Bazarnik yans@endeavour.eu.org From stef.coene@docum.org Wed Aug 21 18:40:22 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 21 Aug 2002 19:40:22 +0200 Subject: [LARTC] HTB problem (yet another one?) In-Reply-To: <003b01c2492a$b4b7e580$8002a8c0@typhoon> References: <003b01c2492a$b4b7e580$8002a8c0@typhoon> Message-ID: <20020821174023.5C7C5DBBA8@tartarus.telenet-ops.be> > endeavour:~# tc qdisc add dev imq0 root handle 1 htb ttt > What is "ttt"? > Usage: ... qdisc add ... htb [default N] [r2q N] > default number of class to which unclassified packets are sent {1} > Why do you have that "ttt" option? If you remove ttt from the command, d= oes=20 it work? > -----------------------------------------------------------------------= -- > And the PROBLEM: > > When i try to add qdisc to the imq device.. a get: > > endeavour:~# tc qdisc add dev imq0 root handle 1 htb default 20 r2q 10 > RTNETLINK answers: Invalid argument > -----------------------------------------------------------------------= -- > > BTW: Adding CBQ qdisc to imq0 works fine... Any suggestions ? What if you add a htb qdisc with no options ? tc qdisc add dev imq0 root handle 1 htb Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Aug 21 18:43:24 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 21 Aug 2002 19:43:24 +0200 Subject: [LARTC] iproute and iptables In-Reply-To: <009c01c24897$fc9ffc40$7c010a0a@nsicomm.com> References: <009c01c24897$fc9ffc40$7c010a0a@nsicomm.com> Message-ID: <20020821174324.C2E66DC622@tartarus.telenet-ops.be> On Wednesday 21 August 2002 00:21, James Ma wrote: > Dear all, > > I am newbie. However, I tried iptables recently and succeeded. I don't > understand the relationship between iptables and iproute2, is iproute u= sed > to replace iptables? iptables is to create firewall chains iproute2 contains 2 programs : ip : For setting/changing all the ip configuration and routing tc : For manipulating the bandwidth managing part of the kernel But iptables and iproute can work together. You can mark packets with=20 iptables and use that mark to route packets or use that mark in the filte= rs=20 you can add with tc. More info about the iproute2 utility can be found on www.lartc.org. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Aug 21 18:48:04 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 21 Aug 2002 19:48:04 +0200 Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ In-Reply-To: References: Message-ID: <20020821174805.936E6DBE27@tartarus.telenet-ops.be> > > Total : 100 > > class1 rate 20 ceil 20 > > class2 rate 40 ceil 80 > > class3 rate 40 ceil 80 > > > > class 1 is isolated like in cbq. It can not use more then it's > > rate/ceil and class2 and class3 will never use bandwidth from class1, > > only from each other. Just like the definition of isolated :) > > What happens when there is no traffic in class 1? Will class 2 and 3 > share class 1's bandwidth then? No traffic in class 1 means that class2 and class3 will share the same=20 bandwidth, but only 80 as maximum. So the bandwidth of class1 (20) is=20 isolated like you can set with cbq. Htb is straight forward. Each class will get's his rate as a minimum. T= he=20 remaining bandwidth is devided according to the rate (and lowest priority= =20 gets first choice) and this with a maximum of the ceil. > The reason I am asking these questions is because I am trying to see if > HTB can be used in place of CBQ in Diffserv. Has anybody tried somethin= g > like this? I didn't tried, but I think htb will do fine (or even better). Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From amitk@ittc.ku.edu Wed Aug 21 23:29:54 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Wed, 21 Aug 2002 17:29:54 -0500 (CDT) Subject: [LARTC] CBQ bounded & isolated In-Reply-To: <20020821174805.936E6DBE27@tartarus.telenet-ops.be> Message-ID: I am trying to reproduce Stef's CBQ tests from www.docum.org My setup is very simple : testbed43 --------> testbed44 -------> testbed45 (src) (CBQ) (sink) 192.168.10.2 in: 192.168.10.254 192.168.100.2 out: 192.168.100.254 I have 2 isolated classes (2:2 and 2:3) which need to share the bandwidth. I have only one traffic source at the moment whose traffic is sent into 2:2, but *doesnot* get limited to the rate specified in 2:2. Any clues would be welcome. TIA. ciao, Amit p.s. Stef - You 'tests' page is down. The script follows: ----------------------------------------------------------------- #!/bin/sh -x # Script to see the working of bounded and isolated TC="/usr/bin/tc" DEV="dev eth1" AVPKT="avpkt 1514" BW="bandwidth 10Mbit" MAXBURST="maxburst 200" MPU="mpu 64" CELL="cell 8" ALLOT="allot 1514" #RATE1="rate 6Mbit weight 600Kbit" #RATE2="rate 4Mbit weight 400Kbit" RATE1="rate 150Kbit weight 150Kbit" RATE2="rate 200Kbit weight 200Kbit" # Root qdisc (10 Mbit) $TC qdisc add $DEV root handle 1:0 cbq $BW $AVPKT $CELL # Root class (10Mbit) $TC class add $DEV parent 1:0 classid 1:1 cbq $BW $CELL \ prio 3 rate 10Mbit $ALLOT $MAXBURST $AVPKT \ bounded # Enclosing qdisc (10 Mbit) $TC qdisc add $DEV parent 1:1 handle 2:0 cbq $BW $AVPKT $CELL # Enclosing class (10 Mbit) $TC class add $DEV parent 2:0 classid 2:1 cbq $BW $CELL \ prio 3 rate 10Mbit $ALLOT $MAXBURST $AVPKT # Real-time class (6Mbit) $TC class add $DEV parent 2:1 classid 2:2 cbq $BW $CELL \ prio 3 $RATE1 $ALLOT $MAXBURST $AVPKT \ isolated # Best-effort class (4Mbit) $TC class add $DEV parent 2:1 classid 2:3 cbq $BW $CELL \ prio 3 $RATE2 $ALLOT $MAXBURST $AVPKT \ isolated # Dummy filter (qdisc 1:0 to class 1:1) $TC filter add $DEV parent 1:0 protocol ip prio 2 u32 match ip tos 0x00 0x00 flowid 1:1 # RSVP filter to send RT traffic from 2:0 to 2:2 $TC filter add $DEV parent 2:0 protocol ip prio 2 rsvp \ ipproto udp session 192.168.100.2/9001 flowid 2:2 ----------------------------------------------------------------- -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From okidz@pindad.com Thu Aug 22 02:47:41 2002 From: okidz@pindad.com (Oki DZ) Date: Thu, 22 Aug 2002 08:47:41 +0700 (WIT) Subject: [LARTC] Usermode Linux & bandwidth limit Message-ID: Hi, Would the bandwith limiter work between the virtual machine and the host machine? [Internet]---[host's eth0]---[virt. machine]---[host's eth1]---[internal] I'd like to limit the bandwidth for the traffic going from the virtual machine to a daemon running on the host (a Squid that serves an internal network). Thanks in advance, Oki From mikep02@softerware.com Thu Aug 22 05:29:54 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Thu, 22 Aug 2002 00:29:54 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #731 - 11 msgs Message-ID: <3014839620@softerware.com> --MIME MULTIPART BOUNDARY=.1029990611:+'1 Content-Type: application/octet-stream Content-Id: <3014839620-2@softerware.com> Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Text Item" U2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCglsYXJ0Y0BtYWlsbWFuLmRz OWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBX ZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRj DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVs cCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5ubA0KDQpZb3UgY2FuIHJlYWNoIHRo ZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0Yy1hZG1pbkBtYWlsbWFuLmRzOWEu bmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQg aXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIExBUlRDIGRpZ2VzdC4uLiIN Cg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IExBUlRDIGRpZ2VzdCwgVm9sIDEgIzcz MCAtIDMgbXNncyAobWlrZXAwMkBzb2Z0ZXJ3YXJlLmNvbSkNCiAgIDIuIEhUQiBhbmQgYnJpZGdl Li4uICh6YWluIGFycmlmYSdpKQ0KICAgMy4gUmU6IE11bHRpIFJvdXRpbmcgUHJvYmxlbS4gKEFy aW5kYW0gSGFsZGFyKQ0KICAgNC4gUU9zIHdpdGggaXB2NiAoQU9VTiBSQVpBKQ0KICAgNS4gUmU6 IEhUQiBhbmQgYnJpZGdlLi4uICg9P2lzby04ODU5LTI/UT9SYWRvcz1CM2F3Xz1BM29ib2RhPz0p DQogICA2LiBIVEIgcHJvYmxlbSAoeWV0IGFub3RoZXIgb25lPykgKFlhbnMgdmFuIEhvcm4pDQog ICA3LiBSZTogSFRCIHByb2JsZW0gKHlldCBhbm90aGVyIG9uZT8pIChTdGVmIENvZW5lKQ0KICAg OC4gUmU6IGlwcm91dGUgYW5kIGlwdGFibGVzIChTdGVmIENvZW5lKQ0KICAgOS4gUmU6IEhUQiBl cXVpdmFsZW50IGZvciAnYm91bmRlZCcgYW5kICdpc29sYXRlZCcgaW4gQ0JRIChTdGVmIENvZW5l KQ0KICAxMC4gQ0JRIGJvdW5kZWQgJiBpc29sYXRlZCAoQW1pdCBLdWNoZXJpYSkNCiAgMTEuIFVz ZXJtb2RlIExpbnV4ICYgYmFuZHdpZHRoIGxpbWl0IChPa2kgRFopDQoNCi0tX18tLV9fLS0NCg0K TWVzc2FnZTogMQ0KRGF0ZTogV2VkLCAyMSBBdWcgMjAwMiAwMDozMDoyMiAtMDQwMA0KVG86IGxh cnRjQG1haWxtYW4uZHM5YS5ubA0KRnJvbTogbWlrZXAwMkBzb2Z0ZXJ3YXJlLmNvbQ0KUmVwbHkt VG86IG1pa2VwMDJAc29mdGVyd2FyZS5jb20NClN1YmplY3Q6IFtMQVJUQ10gUmU6IExBUlRDIGRp Z2VzdCwgVm9sIDEgIzczMCAtIDMgbXNncw0KDQpJIHdpbGwgYmUgb3V0IG9mIHRoZSBvZmZpY2Ug ZnJvbSA4LzE5IHVudGlsIDgvMjMuICBJIHdpbGwgYmUgcmV0dXJuaW5nIG9uIE1vbmRheQ0KYWZ0 ZXJub29uLCA4LzI2LCBhbmQgd2lsbCByZXBseSB0aGVuLg0KDQpUaGFuayB5b3UsDQoNCk1pY2hh ZWwgUGVsbGVncmlubw0KU29mdGVyd2FyZSwgSW5jLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClN1 YmplY3Q6IExBUlRDIGRpZ2VzdCwgVm9sIDEgIzczMCAtIDMgbXNncw0KRnJvbTogbGFydGNAbWFp bG1hbi5kczlhLm5sDQpEYXRlOiAwOC8yMS8wMiAwMToyNzo0NQ0KDQpTZW5kIExBUlRDIG1haWxp bmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KCWxhcnRjQG1haWxtYW4uZHM5YS5ubA0KDQpUbyBzdWJz Y3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCglodHRw Oi8vbWFpbG1hbi5kczlhLm5sL21haWxtYW4vbGlzdGluZm8vbGFydGMNCm9yLCB2aWEgZW1haWws IHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KCWxhcnRjLXJl cXVlc3RAbWFpbG1hbi5kczlhLm5sDQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2lu ZyB0aGUgbGlzdCBhdA0KCWxhcnRjLWFkbWluQG1haWxtYW4uZHM5YS5ubA0KDQpXaGVuIHJlcGx5 aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmlj DQp0aGFuICJSZTogQ29udGVudHMgb2YgTEFSVEMgZGlnZXN0Li4uIg0KDQoNClRvZGF5J3MgVG9w aWNzOg0KDQogICAxLiBpcHJvdXRlIGFuZCBpcHRhYmxlcyAoSmFtZXMgTWEpDQogICAyLiBSZTog aXByb3V0ZSBhbmQgaXB0YWJsZXMgKFRoaWxvIFNjaHVseikNCiAgIDMuIFJlOiBIVEIgZXF1aXZh bGVudCBmb3IgJ2JvdW5kZWQnIGFuZCAnaXNvbGF0ZWQnIGluIENCUSAoQW1pdCBLdWNoZXJpYSkN Cg0KLS0gX18tLV9fLS0gDQoNCk1lc3NhZ2U6IDENCkZyb206ICJKYW1lcyBNYSIgPGptYUBuc2lj b21tLmNvbT4NClRvOiA8bGFydGNAbWFpbG1hbi5kczlhLm5sPg0KRGF0ZTogVHVlLCAyMCBBdWcg MjAwMiAxODoyMTo1MiAtMDQwMA0KU3ViamVjdDogW0xBUlRDXSBpcHJvdXRlIGFuZCBpcHRhYmxl cw0KDQpUaGlzIGlzIGEgbXVsdGktcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0Lg0KDQotLS0t LS09X05leHRQYXJ0XzAwMF8wMDk5XzAxQzI0ODc2Ljc1MThERTIwDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47DQoJY2hhcnNldD0iaXNvLTg4NTktMSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rp bmc6IHF1b3RlZC1wcmludGFibGUNCg0KRGVhciBhbGwsDQoNCkkgYW0gbmV3YmllLiBIb3dldmVy LCBJIHRyaWVkIGlwdGFibGVzIHJlY2VudGx5IGFuZCBzdWNjZWVkZWQuIEkgZG9uJ3QgPQ0KdW5k ZXJzdGFuZCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gaXB0YWJsZXMgYW5kIGlwcm91dGUyLCBp cyBpcHJvdXRlID0NCnVzZWQgdG8gcmVwbGFjZSBpcHRhYmxlcz8NCg0KVGhhbmtzLA0KDQpKYW1l cw0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDk5XzAxQzI0ODc2Ljc1MThERTIwDQpDb250ZW50 LVR5cGU6IHRleHQvaHRtbDsNCgljaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFuc2Zl ci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KDQo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0v L1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPEhUTUw+PEhFQUQ+DQo8TUVU QSBodHRwLWVxdWl2PTNEQ29udGVudC1UeXBlIGNvbnRlbnQ9M0QidGV4dC9odG1sOyA9DQpjaGFy c2V0PTNEaXNvLTg4NTktMSI+DQo8TUVUQSBjb250ZW50PTNEIk1TSFRNTCA1LjUwLjQzMDguMjkw MCIgbmFtZT0zREdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgYmdD b2xvcj0zRCNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9M0RBcmlhbCBzaXplPTNEMj5EZWFyIGFs bCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9M0RBcmlhbCBzaXplPTNEMj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9M0RBcmlhbCBzaXplPTNEMj5JIGFtIG5ld2Jp ZS4gSG93ZXZlciwgSSB0cmllZCBpcHRhYmxlcyA9DQpyZWNlbnRseSBhbmQ9MjANCnN1Y2NlZWRl ZC4gSSBkb24ndCB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBpcHRhYmxlcyBh bmQgPQ0KaXByb3V0ZTIsIGlzPTIwDQppcHJvdXRlIHVzZWQgdG8gcmVwbGFjZSBpcHRhYmxlcz88 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9M0RBcmlhbCBzaXplPTNEMj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9M0RBcmlhbCBzaXplPTNEMj5UaGFua3MsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPTNEQXJpYWwgc2l6ZT0zRDI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPTNEQXJpYWwgc2l6ZT0zRDI+SmFtZXM8L0ZPTlQ+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg0KLS0tLS0tPV9OZXh0UGFydF8wMDBfMDA5OV8wMUMyNDg3Ni43NTE4 REUyMC0tDQoNCg0KLS0gX18tLV9fLS0gDQoNCk1lc3NhZ2U6IDINCkZyb206IFRoaWxvIFNjaHVs eiA8YXJueUBhdHMucy5iYXd1ZS5kZT4NClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1Ympl Y3Q6IFJlOiBbTEFSVENdIGlwcm91dGUgYW5kIGlwdGFibGVzDQpEYXRlOiBXZWQsIDIxIEF1ZyAy MDAyIDAwOjI2OjQzICswMjAwDQoNCkFtIE1pdHR3b2NoLCAyMS4gQXVndXN0IDIwMDIgMDA6MjEg c2NocmllYiBKYW1lcyBNYToNCj4gRGVhciBhbGwsDQo+DQo+IEkgYW0gbmV3YmllLiBIb3dldmVy LCBJIHRyaWVkIGlwdGFibGVzIHJlY2VudGx5IGFuZCBzdWNjZWVkZWQuIEkgZG9uJ3QNCj4gdW5k ZXJzdGFuZCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gaXB0YWJsZXMgYW5kIGlwcm91dGUyLCBp cyBpcHJvdXRlIHU9DQpzZWQNCj4gdG8gcmVwbGFjZSBpcHRhYmxlcz8NCg0KTm8uIFRoZSBpcHJv dXRlMiB1dGlsaXRpZXMgYWxsb3cgdG8gc2V0IHZhcmlvdXMgdGhpbmdzLCBzdWNoIGFzIGlwIGFk ZHJlcz0NCnNlcyw9MjANCnJvdXRpbmcgZW50cmllcyBvciB0aGUgdHJhZmZpYyBzaGFwZXIuDQpU aGUgaXB0YWJsZXMgdG9vbCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGZpcmV3YWxsIGFuZCB0aGUg cnVsZXMgaW4gdGhlcmUgPQ0KLSBhcz0yMA0Kd2VsbCBhcyBzb21lIHBhY2tldCBtYW5nbGluZyBh bmQgbmV0d29yayBhZGRyZXNzIHRyYW5zbGF0aW9uLiBZb3UgY2FuIGNvbT0NCmJpbmU9MjANCmJv dGggdG9vbHMgd2l0aCB0aGUgLWogTUFSSyBkaXJlY3RpdmUgLi4gcnRmbSA7LSkNCg0KIC0gVGhp bG8gU2NodWx6DQoNCi0tIF9fLS1fXy0tIA0KDQpNZXNzYWdlOiAzDQpEYXRlOiBUdWUsIDIwIEF1 ZyAyMDAyIDIyOjMyOjEzIC0wNTAwIChDRFQpDQpGcm9tOiBBbWl0IEt1Y2hlcmlhIDxhbWl0a0Bp dHRjLmt1LmVkdT4NClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNCkNjOiBzdGVmLmNvZW5lQGRv Y3VtLm9yZw0KU3ViamVjdDogUmU6IFtMQVJUQ10gSFRCIGVxdWl2YWxlbnQgZm9yICdib3VuZGVk JyBhbmQgJ2lzb2xhdGVkJyBpbiBDQlENCg0KT24gRnJpLCAxNiBBdWcgMjAwMiwgU3RlZiBDb2Vu ZSB3cm90ZToNCg0KPj4gVGhlICdjZWlsJyBwYXJhbWV0ZXIgYWxsb3dzIHVzIHRvIGltcGxlbWVu dCBhIHBhcnQgb2YgdGhlICdpc29sYXRlZCcNCj4+IGRlZmluaXRpb24gYWJvdmUuIEJ5IHNldHRp bmcgaXQgZXF1YWwgdG8gJ3JhdGUnLCB0aGUgY2xhc3MgZG9lcyBub3QNCj4+IGJvcnJvdyBiYW5k d2lkdGgsIGJ1dCB3aGF0IHdpbGwgc3RvcCBvdGhlciBjbGFzc2VzIGZyb20gYm9ycm93aW5nIGl0 cw0KPj4gdW51c2VkIGJhbmR3aWR0aD8NCj4NCj4gUHJvdmlkaW5nIG5vIGNlaWwgcGFyYW1ldGVy IG1lYW5zIHJhdGUgPSBjZWlsLiAgQnV0IHRoaXMgY2FuIG5vdCBiZQ0KPiB1c2VkIHRvIGltcGxl bWVudCBpc29sYXRlZCBsaWtlIGluIGNicS4gUmF0ZSA9IGNlaWwgbWVhbnMgdGhlIGNsYXNzDQo+ IGNhbiBub3QgdXNlIG1vcmUgYmFuZHdpZHRoIHRoZW4gaXQncyByYXRlLiBJc29sYXRlZCBpbiBj YnEgbWVhbnMgb3RoZXINCj4gY2xhc3NlcyBjYW4gbm90IGJvcnJvdyBiYW5kd2lkdGggZnJvbSB0 aGUgY2xhc3MgYW5kIHRoYXQncyBub3QgdGhlDQo+IHNhbWUuICBUaGVyZSBpcyBubyB3YXkgeW91 IGNhbiBpbXBsZW1lbnQgaXNvbGF0ZWQgd2l0aCBodGIuDQo+DQo+IEJ1dCB3aXRoIGh0YiB5b3Ug Y2FuIGRvIHNvbWV0aGluZyBsaWtlIHRoaXMgOg0KPg0KPiBUb3RhbCA6IDEwMA0KPiBjbGFzczEg ICByYXRlIDIwICAgY2VpbCAyMA0KPiBjbGFzczIgICByYXRlIDQwICAgY2VpbCA4MA0KPiBjbGFz czMgICByYXRlIDQwICAgY2VpbCA4MA0KPg0KPiBjbGFzcyAxIGlzIGlzb2xhdGVkIGxpa2UgaW4g Y2JxLiBJdCBjYW4gbm90IHVzZSBtb3JlIHRoZW4gaXQncw0KPiByYXRlL2NlaWwgYW5kIGNsYXNz MiBhbmQgY2xhc3MzIHdpbGwgbmV2ZXIgdXNlIGJhbmR3aWR0aCBmcm9tIGNsYXNzMSwNCj4gb25s eSBmcm9tIGVhY2ggb3RoZXIuIEp1c3QgbGlrZSB0aGUgZGVmaW5pdGlvbiBvZiBpc29sYXRlZCA6 KQ0KDQpXaGF0IGhhcHBlbnMgd2hlbiB0aGVyZSBpcyBubyB0cmFmZmljIGluIGNsYXNzIDE/IFdp bGwgY2xhc3MgMiBhbmQgMyANCnNoYXJlIGNsYXNzIDEncyBiYW5kd2lkdGggdGhlbj8NCg0KVGhl IHJlYXNvbiBJIGFtIGFza2luZyB0aGVzZSBxdWVzdGlvbnMgaXMgYmVjYXVzZSBJIGFtIHRyeWlu ZyB0byBzZWUgaWYgDQpIVEIgY2FuIGJlIHVzZWQgaW4gcGxhY2Ugb2YgQ0JRIGluIERpZmZzZXJ2 LiBIYXMgYW55Ym9keSB0cmllZCBzb21ldGhpbmcgDQpsaWtlIHRoaXM/DQoNClJlZ2FyZHMsDQpB bWl0DQoNCi0tIA0KSSdtIGFuIGFuZ2VsISEhIEhvbmVzdCENClRoZSBob3JucyBhcmUganVzdCB0 aGVyZSB0byBob2xkIHRoZSBoYWxvIHVwIHN0cmFpZ2h0Lg0KXi1eLV4tXi1eLV4tXi1eLV4tXi1e LV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4NCiAgICAgICAgICAgICAgICAgIEFtaXQg S3VjaGVyaWENCiAgICAgICAgICBFRUNTIEdyYWQuIFJlc2VhcmNoIEFzc2lzdGFudA0NCiAgICAg ICAgIFVuaXZlcnNpdHkgb2YgS2Fuc2FzIEAgTGF3cmVuY2UNCiAgIChSKTogKzEtNzg1LTgzMC04 NTIxIHx8fCAoQyk6ICsxLTc4NS03NjAtMjg3MQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KLS0gX18tLV9fLS0gDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMQVJUQyBtYWlsaW5nIGxp c3QNCkxBUlRDQG1haWxtYW4uZHM5YS5ubA0KaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFu L2xpc3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9mIExBUlRDIERpZ2VzdA0KDQoNCg0KLS1fXy0tX18t LQ0KDQpNZXNzYWdlOiAyDQpEYXRlOiBUdWUsIDIwIEF1ZyAyMDAyIDIxOjQ3OjA3IC0wNzAwIChQ RFQpDQpGcm9tOiB6YWluIGFycmlmYSdpIDxibGFja291dHpAeWFob28uY29tPg0KVG86IGxhcnRj QG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogW0xBUlRDXSBIVEIgYW5kIGJyaWRnZS4uLg0KDQpk b2VzIGFueW9uZSBrbm93IGFib3V0IEhUQiBzaGFwaW5nIGluIGEgYnJpZGdpbmcNCm1hY2hpbmU/ DQpJIGN1cnJlbnRseSBydW4gbXkgc2hhcGVyIGJveCBhcyBicmlkZ2UgYW5kIHNvbWV0aGluZw0K aXMgZ29pbmcgc3RyYW5nZSwgc3VjaCBhcyBhIGNsYXNzIGNhbm5vdCBzZW5kIGF0IHJhdGUNCml0 IHN1cHBvc2VkIHRvLg0KSSBtZWFuIGlmIGFueW9uZSBrbm93IHNvbWV0aGluZyBhYm91dCBicmlk Z2luZyBhbmQgaXRzDQpodGIgc2hhcGluZyBiZWhhdmlvci4NCnRoYW5rcyBpbiBhZHZhbmNlLg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG8g WW91IFlhaG9vIT8NCkhvdEpvYnMgLSBTZWFyY2ggVGhvdXNhbmRzIG9mIE5ldyBKb2JzDQpodHRw Oi8vd3d3LmhvdGpvYnMuY29tDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogMw0KRGF0ZTogV2Vk LCAyMSBBdWcgMjAwMiAxNjoyODozMSArMDUzMA0KRnJvbTogQXJpbmRhbSBIYWxkYXIgPGFyaW5k YW1oYWxkYXJAaW5ib3gubHY+DQpUbzogSnVsaWFuIEFuYXN0YXNvdiA8amFAc3NpLmJnPg0KQ2M6 IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogUmU6IFtMQVJUQ10gTXVsdGkgUm91dGlu ZyBQcm9ibGVtLg0KDQpoaSBhZ2FpbiwgOikNCg0KaSB0cmllZCBhZ2FpbiAmIG5vdyBhbSBzdWNj ZXNmdWxsLi4gOikgdGhpcyBpcyBteSBzY3JpcHQNCg0KIyEvYmluL3NoDQppcHI9Ii9zYmluL2lw Ig0KDQoNCk5ldEV4dEE9Ii4uLjYuNjQvMjYiDQpJUEV4dEE9Ii4uLi42LjEwNiINCkd0RXh0QT0i Li4uLjYuNzAiDQpOZXRFeHRCPSIuLi45LjAvMjUiDQpJUEV4dEI9Ii4uLi45LjEyNCINCkd0RXh0 Qj0iLi4uLjkuMSINCk5ldGxjbD0iMTcyLjMxLjEzLjAvMjQiDQpJUGxjbD0iMTcyLjMxLjEzLjEi DQoNCk5ldGdycEE9IjE3Mi4zMS4xMy4xMC8zMSINCk5ldGdycEI9IjE3Mi4zMS4xMy4yMC8zMSIN Ck5ldGdycEM9IjE3Mi4zMS4xMy4zMC8zMSINCg0KICAkaXByIHJ1bGUgZGVsIHByaW8gOTkgZnJv bSAkTmV0RXh0QQ0KICAkaXByIHJ1bGUgZGVsIHByaW8gOTggZnJvbSAkTmV0Z3JwQQ0KICAkaXBy IHJ1bGUgZGVsIHByaW8gNzQgZnJvbSAkTmV0RXh0Qg0KICAkaXByIHJ1bGUgZGVsIHByaW8gNzMg ZnJvbSAkTmV0Z3JwQg0KICAkaXByIHJ1bGUgZGVsIHByaW8gNDkgZnJvbSAkTmV0Z3JwQw0KIyAk aXByIHJ1bGUgZGVsIHByaW8gNDgNCg0KZWNobyAxMDAgRVhUbkEgPj4gL2V0Yy9pcHJvdXRlMi9y dF90YWJsZXMNCmVjaG8gNzUgRVhUbkIgPj4gL2V0Yy9pcHJvdXRlMi9ydF90YWJsZXMNCmVjaG8g NTAgQkFMQU5DRSA+PiAvZXRjL2lwcm91dGUyL3J0X3RhYmxlcw0KDQogICRpcHIgcnVsZSBhZGQg cHJpbyA5OSBmcm9tICROZXRFeHRBIHRhYmxlIEVYVG5BDQogICRpcHIgcnVsZSBhZGQgcHJpbyA5 OCBmcm9tICROZXRncnBBIHRhYmxlIEVYVG5BDQogICRpcHIgcnVsZSBhZGQgcHJpbyA3NCBmcm9t ICROZXRFeHRCIHRhYmxlIEVYVG5CDQogICRpcHIgcnVsZSBhZGQgcHJpbyA3MyBmcm9tICROZXRn cnBCIHRhYmxlIEVYVG5CDQogICRpcHIgcnVsZSBhZGQgcHJpbyA0OSBmcm9tICROZXRncnBDIHRh YmxlIEJBTEFOQ0UNCiMgJGlwciBydWxlIGFkZCBwcmlvIDQ4IHRhYmxlIEJBTEFOQ0UNCg0KICAk aXByIHJvdXRlIGFkZCBkZWZhdWx0IHRhYmxlIEVYVG5CIHZpYSAkR3RFeHRCIGRldiBldGgxIHNy YyAkSVBFeHRCDQogICRpcHIgcm91dGUgYWRkICROZXRncnBCIHZpYSAkSVBsY2wgZGV2IGV0aDIg dGFibGUgRVhUbkINCg0KICAkaXByIHJvdXRlIGFkZCBkZWZhdWx0IHRhYmxlIEVYVG5BIHZpYSAk R3RFeHRBIGRldiBldGgwIHNyYyAkSVBFeHRBDQogICRpcHIgcm91dGUgYWRkICROZXRncnBBIHZp YSAkSVBsY2wgZGV2IGV0aDIgdGFibGUgRVhUbkINCg0KICAkaXByIHJvdXRlIGFkZCBkZWZhdWx0 IHRhYmxlIEJBTEFOQ0UgbmV4dGhvcCB2aWEgJEd0RXh0QiBkZXYgZXRoMSANCm5leHRob3Agdmlh ICRHdEV4dEEgZGV2IGV0aDANCiAgJGlwciByb3V0ZSBhZGQgJE5ldGdycEMgdmlhICRJUGxjbCBk ZXYgZXRoMiB0YWJsZSBFWFRuQg0KDQp0aGluZ3Mgd29yayBmaW5lIGZyb20gdGhlIGNsaWVudCdz IGVuZCwgYW5kIGZvbGxvd3MgdGhlIA0Kcm91dGluZy9iYWxhbmNpbmcgYXMgZGVmaW5lZC4uIGJ1 dCB3aGVuIGkgdXNlICoqMiBhcHBlbmQgKiogaXAgcm91dGUgDQpjb21tYW5kcyB0byB0YWJsZSBC QUxBTkNFLS12aXoNCmlwIHJvdXRlIGFwcGVuZCBkZWZhdWx0IHZpYSAkR3RFeHRCIGRldiBldGgx IHRhIEJBTEFOQ0UNCmlwIHJvdXRlIGFwcGVuZCBkZWZhdWx0IHZpYSAkR3RFeHRBIGRldiBldGgw IHRhIEJBTEFOQ0UNCnRoZW4gZXZlcnl0aGluZyAqKlNUT1BTKiouLi4gV0hZID8/Pz8NCg0KanVs aWFuIHUgd3JvdGUgaW4gdXIgbWFpbCBhYm91dCBhZGRpbmcgPj4+aXAgcnVsZSBhZGQgcHJpbyA1 IHRhIG1haW4NCiYgaSBhbHNvIHNhdyBpdCBpbiB0aGUgZG9jcyB0b28gYnV0IGkgY291bGRudCB1 bmRlcnN0YW5kIHRoZSANCmltcG9ydGFuY2UuLiBtb3JlIHNvIGNveiB0aGVyZSB3YXMgbm8gcm91 dGluZyBhdHRhY2hlZCB0byB0aGlzIHByaW8uLiANCndpbGwgdGhlIGRlZmF1bHQgcm91dGUgb2Yg dGEgbWFpbigzMjc2NikgYmUgY2FycmllZCB0byB0YWJsZSBtYWluIChwcmlvIA0KNSkgPz8uLiBj YW4gdSBwbGVhc2UgdGVsbCBtZSBtb3JlIGFib3V0IGl0ID8uLi4NCg0KYXdhaXRuZyBhIHJlcGx5 DQp0aGFua2luZyB1IGluIGFkdmFuY2UNCkEuSA0KDQpKdWxpYW4gQW5hc3Rhc292IHdyb3RlOg0K PiAJSGVsbG8sDQo+IA0KPiBPbiBNb24sIDE5IEF1ZyAyMDAyLCBBcmluZGFtIEhhbGRhciB3cm90 ZToNCj4gDQo+IA0KPj4mIGFwcGxpZWQganVsaWFuJ3MgcGF0Y2ggdG8ga2VybmVsIDIuNC4xOSAm IGhhdmUgZ29uZSB0aHJ1IHRoZSBkb2NzIGF0DQo+PnRoZSBzaXRlLi4uIGkgaGF2ZSBkZWZpbmVk IGJhc2ljYWxseSAzIGdyb3VwcyBmb3IgY2xpZW50cy0tPiBjYWNoZSwNCj4+Y2lzY28sIGJhbGFu Y2UuLiB0aGUgbmFtZSBzcGVjaWZpZXMgdGhlIGltcG9ydGFuY2UuLiB0aGlzIGlzIHRoZSBkZXRh aWxzDQo+Pm9mIHdoYXQgaSBkaWQtLT4NCj4gDQo+IA0KPiAJQ2FyZWZ1bGx5IGFuYWx5emUgdGhl IGRvY3MuLi4NCj4gDQo+IA0KPj5bcm9vdEBMcjEgcm9vdF0jIGlwIHJ1bGUgbHMNCj4+MDogICAg ICBmcm9tIGFsbCBsb29rdXAgbG9jYWwNCj4gDQo+IA0KPiAJIyBkaXJlY3QgY29tbXVuaWNhdGlv bnMgYXJlIGZpcnN0IHByaW9yaXR5DQo+IAlpcCBydWxlIGFkZCBwcmlvIDUgdGFibGUgbWFpbg0K PiANCg0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDQNCkRhdGU6IFdlZCwgMjEgQXVnIDIwMDIg MDY6MjI6NTkgLTA3MDAgKFBEVCkNCkZyb206IEFPVU4gUkFaQSA8b3NyYXphQHlhaG9vLmNvbT4N ClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFtMQVJUQ10gUU9zIHdpdGggaXB2 Ng0KDQpIYWxsbyAsDQoNCmkgd2FudCB0byBjcmVhdGUgcWRpc2Mgd2l0aCB1MzIgIGJ5IHVzaW5n IHRjLg0KbXkgcXVlc3Rpb24gaXMgaG93IHRvIGNvbXBhcmUgaXB2NiBoZWFkZXIgQ2xhc3MgZmll bGQNCndpdGggY2JxIG9yIHRiZi4uIA0KDQpjYW4gc29tZSBib2R5IGdpdmUgbWUgc29tZSBsaXR0 bGUgZXhhbXBsZSB3aXRoIGlwdjYNCi4uaGVhZGVyIGNoZWNraW5nIHF1ZXVlLg0KDQoNCkFvdW4g cmF6YS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRG8gWW91IFlhaG9vIT8NCkhvdEpvYnMgLSBTZWFyY2ggVGhvdXNhbmRzIG9mIE5ldyBK b2JzDQpodHRwOi8vd3d3LmhvdGpvYnMuY29tDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogNQ0K RGF0ZTogV2VkLCAyMSBBdWcgMjAwMiAxNzowMzowNSArMDIwMCAoQ0VTVCkNCkZyb206ID0/aXNv LTg4NTktMj9RP1JhZG9zPUIzYXdfPUEzb2JvZGE/PSA8cDB3ZXJAdGwua3Jha293LnBsPg0KVG86 IHphaW4gYXJyaWZhJ2kgPGJsYWNrb3V0ekB5YWhvby5jb20+DQpDYzogbGFydGNAbWFpbG1hbi5k czlhLm5sDQpTdWJqZWN0OiBSZTogW0xBUlRDXSBIVEIgYW5kIGJyaWRnZS4uLg0KDQpPbiBUdWUs IDIwIEF1ZyAyMDAyLCB6YWluIGFycmlmYSdpIHdyb3RlOg0KPiBkb2VzIGFueW9uZSBrbm93IGFi b3V0IEhUQiBzaGFwaW5nIGluIGEgYnJpZGdpbmcNCj4gbWFjaGluZT8NCj4gSSBjdXJyZW50bHkg cnVuIG15IHNoYXBlciBib3ggYXMgYnJpZGdlIGFuZCBzb21ldGhpbmcNCj4gaXMgZ29pbmcgc3Ry YW5nZSwgc3VjaCBhcyBhIGNsYXNzIGNhbm5vdCBzZW5kIGF0IHJhdGUNCj4gaXQgc3VwcG9zZWQg dG8uDQo+IEkgbWVhbiBpZiBhbnlvbmUga25vdyBzb21ldGhpbmcgYWJvdXQgYnJpZGdpbmcgYW5k IGl0cw0KPiBodGIgc2hhcGluZyBiZWhhdmlvci4NCj4gdGhhbmtzIGluIGFkdmFuY2UuDQoNCkkg ZG9uJ3Qga25vdyBhYm91dCBIVEIgYnV0IEkgaGFkIHN1Y2ggY29uZmlndXJhdGlvbjoNCg0KICAg ICAgICAgLC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS4NCiAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICwtLSBldGgwIC0rLS0+IFNlZzENCklORVQgLS0tLSstPiBwcHAwIC0tIFJP VVRFUiAtLSsgKGJyaWRnZSl8DQogICAgICAgICB8ICAgICAgICAgICAoZndhbGwpICBgLS0gZXRo MSAtKy0tPiBTZWcyDQogICAgICAgICBgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJw0K DQphbmQgSSBzdWNjZWRlZCBpbiBmaXJld2FsbGluZyBhbmQgc2hhcGluZyBvbmUgb2YgdGhlIHNl Z21lbnRzIHdpdGggQ0JRDQooanVzdCBsaW1pdGluZyB0byBzb21lIHJhdGUsIGluIHRoaXMgZXhh bXBsZSBJTkVUPTE5MmtiaXQsIHNlZzE9NjRrYml0KS4NCg0KSXQganVzdCB3b3JrZWQsIG9mIGNv dXJzZSBhZnRlciBhcHBseWluZyB0aGUgY29ycmVjdCBwYXRjaGVzIGZyIGJyaWRnZQ0KZmlyZXdh bGxpbmcgaW50byB0aGUga2VybmVsLi4uDQoNCi0tIA0KDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMgICAgICAgICAgIHwgICAgICAgcDB3ZXIgICAgICAgIHwg ICAgICAgIw0KIyAgIF9fICAgICAgfCAgICBHRyMxODc3MjQ4ICAgICAgfCAgICAgICAjDQojICAo b28pICAgICB8IHAwd2VyQGJvamtvLmV1Lm9yZyB8ICAgICAgICMNCiMgLyBcLyBcIEdvIGF3YXkg b3IgSSB3aWxsIHJlcGxhY2UgeW91ICAgIw0KIyBgVl9fVicgd2l0aCBhIHZlcnkgc21hbGwgc2hl bGwgc2NyaXB0LiAjDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN Cg0KDQoNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiA2DQpGcm9tOiAiWWFucyB2YW4gSG9ybiIg PHlhbnNAZW5kZWF2b3VyLmV1Lm9yZz4NClRvOiAiTEFSVEMiIDxsYXJ0Y0BtYWlsbWFuLmRzOWEu bmw+DQpEYXRlOiBXZWQsIDIxIEF1ZyAyMDAyIDE3OjUyOjA4ICswMjAwDQpTdWJqZWN0OiBbTEFS VENdIEhUQiBwcm9ibGVtICh5ZXQgYW5vdGhlciBvbmU/KQ0KDQpIZWxsbw0KDQpJIGhhdmUgYSBz bWFsbCAobWF5YmUgdHlwaWNhbD8pIHByb2JsZW0gd2l0aCBIVEIuIFByZXNlbnQgY29uZmlndXJh dGlvbiBpczoNCg0KS2VybmVsOiAyLjQuMjAtcHJlNCAod2l0aCBIVEIsIElNUSkNCg0KZW5kZWF2 b3VyOi92YXIvbG9nIyB0YyAtVg0KdGMgdXRpbGl0eSwgaXByb3V0ZTItc3MwMTA4MjQNCg0KV2hp Y2ggc2hvdWxkIHN1cHBvcnQgSFRCIGJlY2F1c2Ugd3JpdGVzIGhlbHAgZm9yIGl0IDstKQ0KDQpl bmRlYXZvdXI6fiMgdGMgcWRpc2MgYWRkIGRldiBpbXEwIHJvb3QgaGFuZGxlIDEgaHRiIHR0dA0K V2hhdCBpcyAidHR0Ij8NClVzYWdlOiAuLi4gcWRpc2MgYWRkIC4uLiBodGIgW2RlZmF1bHQgTl0g W3IycSBOXQ0KIGRlZmF1bHQgIG51bWJlciBvZiBjbGFzcyB0byB3aGljaCB1bmNsYXNzaWZpZWQg cGFja2V0cyBhcmUgc2VudCB7MX0NCjxhbmQgc28gb24+DQoNCmVuZGVhdm91cjp+IyBpcCBsaW5r IHNob3cNCjE6IGxvOiA8TE9PUEJBQ0ssVVA+IG10dSAxNjQzNiBxZGlzYyBub3F1ZXVlDQogICAg bGluay9sb29wYmFjayAwMDowMDowMDowMDowMDowMCBicmQgMDA6MDA6MDA6MDA6MDA6MDANCjI6 IGV0aDA6IDxCUk9BRENBU1QsTVVMVElDQVNULEFMTE1VTFRJLFVQPiBtdHUgMTUwMCBxZGlzYyBw Zmlmb19mYXN0IHFsZW4gMTAwDQogICAgbGluay9ldGhlciAwMDo1MDpiYTpkNDo5ZDo1MCBicmQg ZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCjM6IGV0aDE6IDxCUk9BRENBU1QsTVVMVElDQVNULFVQPiBtdHUg MTUwMCBxZGlzYyBwZmlmb19mYXN0IHFsZW4gMTAwDQogICAgbGluay9ldGhlciAwMDo0ODo1NDo1 NTo1NDpkMSBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCjQ6IGV0aDI6IDxCUk9BRENBU1QsTVVMVElD QVNULEFMTE1VTFRJLFVQPiBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IHFsZW4gMTAwDQogICAg bGluay9ldGhlciAwMDphMDoyNDpkNTphZTozMyBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCjU6IHBw cDA6IDxQT0lOVE9QT0lOVCxNVUxUSUNBU1QsTk9BUlAsVVA+IG10dSAxNjU2IHFkaXNjIHBmaWZv X2Zhc3QgcWxlbiAzDQogICAgbGluay9wcHANCjY6IHBwcDE6IDxQT0lOVE9QT0lOVCxNVUxUSUNB U1QsTk9BUlAsVVA+IG10dSAxNjU2IHFkaXNjIHBmaWZvX2Zhc3QgcWxlbiAzDQogICAgbGluay9w cHANCjc6IGltcTA6IDxOT0FSUCxVUD4gbXR1IDE1MDAgcWRpc2MgcGZpZm9fZmFzdCBxbGVuIDMw DQogICAgbGluay92b2lkDQoNCkkgc2hvdWxkIGhhdmUgYWxsIHRoZSBuZWVkZWQgbW9kdWxlcyBh bHNvOg0KDQplbmRlYXZvdXI6fiMgbHNtb2QNCk1vZHVsZSAgICAgICAgICAgICAgICAgIFNpemUg IFVzZWQgYnkgICAgTm90IHRhaW50ZWQNCmlwdF9JTVEgICAgICAgICAgICAgICAgICA3NjAgICAx ICAoYXV0b2NsZWFuKQ0Kc2NoX2h0YiAgICAgICAgICAgICAgICAxODA0OCAgIDAgIChhdXRvY2xl YW4pICh1bnVzZWQpDQppbXEgICAgICAgICAgICAgICAgICAgICAxODY0ICAgMQ0KY2xzX3JvdXRl ICAgICAgICAgICAgICAgNDA4OCAgIDAgICh1bnVzZWQpDQpjbHNfdTMyICAgICAgICAgICAgICAg ICA0NTQwICAgMA0KY2xzX2Z3ICAgICAgICAgICAgICAgICAgMjM2MCAgIDAgICh1bnVzZWQpDQpz Y2hfcHJpbyAgICAgICAgICAgICAgICAyMzY4ICAgMCAgKHVudXNlZCkNCnNjaF9zZnEgICAgICAg ICAgICAgICAgIDM1MjAgICAwICAodW51c2VkKQ0Kc2NoX3RiZiAgICAgICAgICAgICAgICAgMjQz MiAgIDANCnNjaF9jYnEgICAgICAgICAgICAgICAgMTE3NDQgICAwDQppcHRfTUFSSyAgICAgICAg ICAgICAgICAgNzkyICA3MyAgKGF1dG9jbGVhbikNCmlwdGFibGVfbWFuZ2xlICAgICAgICAgIDIx OTYgICAxICAoYXV0b2NsZWFuKQ0KaXB0X1JFRElSRUNUICAgICAgICAgICAgIDgyNCAgIDMgIChh dXRvY2xlYW4pDQppcHRfbnRoICAgICAgICAgICAgICAgICAxMjgwICAgMiAgKGF1dG9jbGVhbikN CmlwdF9SRUpFQ1QgICAgICAgICAgICAgIDI4NDAgICAyICAoYXV0b2NsZWFuKQ0KaXB0YWJsZV9m aWx0ZXIgICAgICAgICAgMTY3MiAgIDEgIChhdXRvY2xlYW4pDQpwcHBfZGVmbGF0ZSAgICAgICAg ICAgICAyOTA0ICAgMiAgKGF1dG9jbGVhbikNCnpsaWJfaW5mbGF0ZSAgICAgICAgICAgMTg0MzYg ICAwICAoYXV0b2NsZWFuKSBbcHBwX2RlZmxhdGVdDQp6bGliX2RlZmxhdGUgICAgICAgICAgIDE3 NzIwICAgMCAgKGF1dG9jbGVhbikgW3BwcF9kZWZsYXRlXQ0KYnNkX2NvbXAgICAgICAgICAgICAg ICAgMzk5MiAgIDAgIChhdXRvY2xlYW4pDQozYzU5eCAgICAgICAgICAgICAgICAgIDI0NTYwICAg MQ0KaXBfbmF0X2Z0cCAgICAgICAgICAgICAgMjg2NCAgIDAgICh1bnVzZWQpDQppcHRhYmxlX25h dCAgICAgICAgICAgIDE0MDQwICAgMiAgW2lwdF9SRURJUkVDVCBpcF9uYXRfZnRwXQ0KaXBfY29u bnRyYWNrX2Z0cCAgICAgICAgMzc2MCAgIDENCmlwX2Nvbm50cmFjayAgICAgICAgICAgMTY0NDgg ICAyICBbaXB0X1JFRElSRUNUIGlwX25hdF9mdHAgaXB0YWJsZV9uYXQNCmlwX2Nvbm50cmFja19m dHBdDQppcF90YWJsZXMgICAgICAgICAgICAgIDEwNTUyICAxMCAgW2lwdF9JTVEgaXB0X01BUksg aXB0YWJsZV9tYW5nbGUgaXB0X1JFRElSRUNUDQppcHRfbnRoIGlwdF9SRUpFQ1QgaXB0YWJsZV9m aWx0ZXIgaXB0YWJsZV9uYXRdDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFuZCB0aGUgUFJPQkxFTToN Cg0KV2hlbiBpIHRyeSB0byBhZGQgcWRpc2MgdG8gdGhlIGltcSBkZXZpY2UuLiBhIGdldDoNCg0K ZW5kZWF2b3VyOn4jIHRjIHFkaXNjIGFkZCBkZXYgaW1xMCByb290IGhhbmRsZSAxIGh0YiBkZWZh dWx0IDIwIHIycSAxMA0KUlRORVRMSU5LIGFuc3dlcnM6IEludmFsaWQgYXJndW1lbnQNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KQlRXOiBBZGRpbmcgQ0JRIHFkaXNjIHRvIGltcTAgd29ya3MgZmluZS4u LiBBbnkgc3VnZ2VzdGlvbnMgPw0KDQotLQ0KcmVnYXJkcywNCg0KTWFyY2luICdZYW5zJyBCYXph cm5paw0KeWFuc0BlbmRlYXZvdXIuZXUub3JnDQoNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiA3 DQpGcm9tOiBTdGVmIENvZW5lIDxzdGVmLmNvZW5lQGRvY3VtLm9yZz4NCk9yZ2FuaXphdGlvbjog Tm9uZQ0KVG86ICJZYW5zIHZhbiBIb3JuIiA8eWFuc0BlbmRlYXZvdXIuZXUub3JnPiwNCgkiTEFS VEMiIDxsYXJ0Y0BtYWlsbWFuLmRzOWEubmw+DQpTdWJqZWN0OiBSZTogW0xBUlRDXSBIVEIgcHJv YmxlbSAoeWV0IGFub3RoZXIgb25lPykNCkRhdGU6IFdlZCwgMjEgQXVnIDIwMDIgMTk6NDA6MjIg KzAyMDANCg0KPiBlbmRlYXZvdXI6fiMgdGMgcWRpc2MgYWRkIGRldiBpbXEwIHJvb3QgaGFuZGxl IDEgaHRiIHR0dA0KPiBXaGF0IGlzICJ0dHQiPw0KPiBVc2FnZTogLi4uIHFkaXNjIGFkZCAuLi4g aHRiIFtkZWZhdWx0IE5dIFtyMnEgTl0NCj4gIGRlZmF1bHQgIG51bWJlciBvZiBjbGFzcyB0byB3 aGljaCB1bmNsYXNzaWZpZWQgcGFja2V0cyBhcmUgc2VudCB7MX0NCj4gPGFuZCBzbyBvbj4NCldo eSBkbyB5b3UgaGF2ZSB0aGF0ICJ0dHQiIG9wdGlvbj8gIElmIHlvdSByZW1vdmUgdHR0IGZyb20g dGhlIGNvbW1hbmQsIGQ9DQpvZXM9MjANCml0IHdvcms/DQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS09DQot LQ0KPiBBbmQgdGhlIFBST0JMRU06DQo+DQo+IFdoZW4gaSB0cnkgdG8gYWRkIHFkaXNjIHRvIHRo ZSBpbXEgZGV2aWNlLi4gYSBnZXQ6DQo+DQo+IGVuZGVhdm91cjp+IyB0YyBxZGlzYyBhZGQgZGV2 IGltcTAgcm9vdCBoYW5kbGUgMSBodGIgZGVmYXVsdCAyMCByMnEgMTANCj4gUlRORVRMSU5LIGFu c3dlcnM6IEludmFsaWQgYXJndW1lbnQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS09DQotLQ0KPg0KPiBCVFc6 IEFkZGluZyBDQlEgcWRpc2MgdG8gaW1xMCB3b3JrcyBmaW5lLi4uIEFueSBzdWdnZXN0aW9ucyA/ DQpXaGF0IGlmIHlvdSBhZGQgYSBodGIgcWRpc2Mgd2l0aCBubyBvcHRpb25zID8NCnRjIHFkaXNj IGFkZCBkZXYgaW1xMCByb290IGhhbmRsZSAxIGh0Yg0KDQpTdGVmDQoNCi0tPTIwDQoNCnN0ZWYu Y29lbmVAZG9jdW0ub3JnDQogIlVzaW5nIExpbnV4IGFzIGJhbmR3aWR0aCBtYW5hZ2VyIg0KICAg ICBodHRwOi8vd3d3LmRvY3VtLm9yZy8NCiAgICAgI2xhcnRjIEAgaXJjLm9mdGMubmV0DQoNCi0t X18tLV9fLS0NCg0KTWVzc2FnZTogOA0KRnJvbTogU3RlZiBDb2VuZSA8c3RlZi5jb2VuZUBkb2N1 bS5vcmc+DQpPcmdhbml6YXRpb246IE5vbmUNClRvOiAiSmFtZXMgTWEiIDxqbWFAbnNpY29tbS5j b20+LCA8bGFydGNAbWFpbG1hbi5kczlhLm5sPg0KU3ViamVjdDogUmU6IFtMQVJUQ10gaXByb3V0 ZSBhbmQgaXB0YWJsZXMNCkRhdGU6IFdlZCwgMjEgQXVnIDIwMDIgMTk6NDM6MjQgKzAyMDANCg0K T24gV2VkbmVzZGF5IDIxIEF1Z3VzdCAyMDAyIDAwOjIxLCBKYW1lcyBNYSB3cm90ZToNCj4gRGVh ciBhbGwsDQo+DQo+IEkgYW0gbmV3YmllLiBIb3dldmVyLCBJIHRyaWVkIGlwdGFibGVzIHJlY2Vu dGx5IGFuZCBzdWNjZWVkZWQuIEkgZG9uJ3QNCj4gdW5kZXJzdGFuZCB0aGUgcmVsYXRpb25zaGlw IGJldHdlZW4gaXB0YWJsZXMgYW5kIGlwcm91dGUyLCBpcyBpcHJvdXRlIHU9DQpzZWQNCj4gdG8g cmVwbGFjZSBpcHRhYmxlcz8NCmlwdGFibGVzIGlzIHRvIGNyZWF0ZSBmaXJld2FsbCBjaGFpbnMN Cmlwcm91dGUyIGNvbnRhaW5zIDIgcHJvZ3JhbXMgOg0KICAgaXAgOiBGb3Igc2V0dGluZy9jaGFu Z2luZyBhbGwgdGhlIGlwIGNvbmZpZ3VyYXRpb24gYW5kIHJvdXRpbmcNCiAgIHRjIDogRm9yIG1h bmlwdWxhdGluZyB0aGUgYmFuZHdpZHRoIG1hbmFnaW5nIHBhcnQgb2YgdGhlIGtlcm5lbA0KDQpC dXQgaXB0YWJsZXMgYW5kIGlwcm91dGUgY2FuIHdvcmsgdG9nZXRoZXIuICBZb3UgY2FuIG1hcmsg cGFja2V0cyB3aXRoPTIwDQppcHRhYmxlcyBhbmQgdXNlIHRoYXQgbWFyayB0byByb3V0ZSBwYWNr ZXRzIG9yIHVzZSB0aGF0IG1hcmsgaW4gdGhlIGZpbHRlPQ0KcnM9MjANCnlvdSBjYW4gYWRkIHdp dGggdGMuDQoNCk1vcmUgaW5mbyBhYm91dCB0aGUgaXByb3V0ZTIgdXRpbGl0eSBjYW4gYmUgZm91 bmQgb24gd3d3LmxhcnRjLm9yZy4NCg0KU3RlZg0KDQotLT0yMA0KDQpzdGVmLmNvZW5lQGRvY3Vt Lm9yZw0KICJVc2luZyBMaW51eCBhcyBiYW5kd2lkdGggbWFuYWdlciINCiAgICAgaHR0cDovL3d3 dy5kb2N1bS5vcmcvDQogICAgICNsYXJ0YyBAIGlyYy5vZnRjLm5ldA0KDQotLV9fLS1fXy0tDQoN Ck1lc3NhZ2U6IDkNCkZyb206IFN0ZWYgQ29lbmUgPHN0ZWYuY29lbmVAZG9jdW0ub3JnPg0KT3Jn YW5pemF0aW9uOiBOb25lDQpUbzogQW1pdCBLdWNoZXJpYSA8YW1pdGtAaXR0Yy5rdS5lZHU+LCBs YXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFJlOiBbTEFSVENdIEhUQiBlcXVpdmFsZW50 IGZvciAnYm91bmRlZCcgYW5kICdpc29sYXRlZCcgaW4gQ0JRDQpEYXRlOiBXZWQsIDIxIEF1ZyAy MDAyIDE5OjQ4OjA0ICswMjAwDQoNCj4gPiBUb3RhbCA6IDEwMA0KPiA+IGNsYXNzMSAgIHJhdGUg MjAgICBjZWlsIDIwDQo+ID4gY2xhc3MyICAgcmF0ZSA0MCAgIGNlaWwgODANCj4gPiBjbGFzczMg ICByYXRlIDQwICAgY2VpbCA4MA0KPiA+DQo+ID4gY2xhc3MgMSBpcyBpc29sYXRlZCBsaWtlIGlu IGNicS4gSXQgY2FuIG5vdCB1c2UgbW9yZSB0aGVuIGl0J3MNCj4gPiByYXRlL2NlaWwgYW5kIGNs YXNzMiBhbmQgY2xhc3MzIHdpbGwgbmV2ZXIgdXNlIGJhbmR3aWR0aCBmcm9tIGNsYXNzMSwNCj4g PiBvbmx5IGZyb20gZWFjaCBvdGhlci4gSnVzdCBsaWtlIHRoZSBkZWZpbml0aW9uIG9mIGlzb2xh dGVkIDopDQo+DQo+IFdoYXQgaGFwcGVucyB3aGVuIHRoZXJlIGlzIG5vIHRyYWZmaWMgaW4gY2xh c3MgMT8gV2lsbCBjbGFzcyAyIGFuZCAzDQo+IHNoYXJlIGNsYXNzIDEncyBiYW5kd2lkdGggdGhl bj8NCk5vIHRyYWZmaWMgaW4gY2xhc3MgMSBtZWFucyB0aGF0IGNsYXNzMiBhbmQgY2xhc3MzIHdp bGwgc2hhcmUgdGhlIHNhbWU9MjANCmJhbmR3aWR0aCwgYnV0IG9ubHkgODAgYXMgbWF4aW11bS4g IFNvIHRoZSBiYW5kd2lkdGggb2YgY2xhc3MxICgyMCkgaXM9MjANCmlzb2xhdGVkIGxpa2UgeW91 IGNhbiBzZXQgd2l0aCBjYnEuDQpIdGIgaXMgc3RyYWlnaHQgZm9yd2FyZC4gIEVhY2ggY2xhc3Mg d2lsbCBnZXQncyBoaXMgcmF0ZSBhcyBhIG1pbmltdW0uICBUPQ0KaGU9MjANCnJlbWFpbmluZyBi YW5kd2lkdGggaXMgZGV2aWRlZCBhY2NvcmRpbmcgdG8gdGhlIHJhdGUgKGFuZCBsb3dlc3QgcHJp b3JpdHk9DQo9MjANCmdldHMgZmlyc3QgY2hvaWNlKSBhbmQgdGhpcyB3aXRoIGEgbWF4aW11bSBv ZiB0aGUgY2VpbC4NCg0KPiBUaGUgcmVhc29uIEkgYW0gYXNraW5nIHRoZXNlIHF1ZXN0aW9ucyBp cyBiZWNhdXNlIEkgYW0gdHJ5aW5nIHRvIHNlZSBpZg0KPiBIVEIgY2FuIGJlIHVzZWQgaW4gcGxh Y2Ugb2YgQ0JRIGluIERpZmZzZXJ2LiBIYXMgYW55Ym9keSB0cmllZCBzb21ldGhpbj0NCmcNCj4g bGlrZSB0aGlzPw0KSSBkaWRuJ3QgdHJpZWQsIGJ1dCBJIHRoaW5rIGh0YiB3aWxsIGRvIGZpbmUg KG9yIGV2ZW4gYmV0dGVyKS4NCg0KU3RlZg0KDQotLT0yMA0KDQpzdGVmLmNvZW5lQGRvY3VtLm9y Zw0KICJVc2luZyBMaW51eCBhcyBiYW5kd2lkdGggbWFuYWdlciINCiAgICAgaHR0cDovL3d3dy5k b2N1bS5vcmcvDQogICAgICNsYXJ0YyBAIGlyYy5vZnRjLm5ldA0KDQotLV9fLS1fXy0tDQoNCk1l c3NhZ2U6IDEwDQpEYXRlOiBXZWQsIDIxIEF1ZyAyMDAyIDE3OjI5OjU0IC0wNTAwIChDRFQpDQpG cm9tOiBBbWl0IEt1Y2hlcmlhIDxhbWl0a0BpdHRjLmt1LmVkdT4NClRvOiBTdGVmIENvZW5lIDxz dGVmLmNvZW5lQGRvY3VtLm9yZz4NCkNjOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6 IFtMQVJUQ10gQ0JRIGJvdW5kZWQgJiBpc29sYXRlZA0KDQpJIGFtIHRyeWluZyB0byByZXByb2R1 Y2UgU3RlZidzIENCUSB0ZXN0cyBmcm9tIHd3dy5kb2N1bS5vcmcNCg0KTXkgc2V0dXAgaXMgdmVy eSBzaW1wbGUgOg0KDQogIHRlc3RiZWQ0MyAtLS0tLS0tLT4gdGVzdGJlZDQ0IC0tLS0tLS0+IHRl c3RiZWQ0NQ0KICAgKHNyYykgICAgICAgICAgICAgICAoQ0JRKSAgICAgICAgICAgICAgKHNpbmsp DQogMTkyLjE2OC4xMC4yICAgIGluOiAgMTkyLjE2OC4xMC4yNTQgICAgIDE5Mi4xNjguMTAwLjIN CiAgICAgICAgICAgICAgICAgb3V0OiAxOTIuMTY4LjEwMC4yNTQgICANCg0KSSBoYXZlIDIgaXNv bGF0ZWQgY2xhc3NlcyAoMjoyIGFuZCAyOjMpIHdoaWNoIG5lZWQgdG8gc2hhcmUgdGhlIA0KYmFu ZHdpZHRoLiBJIGhhdmUgb25seSBvbmUgdHJhZmZpYyBzb3VyY2UgYXQgdGhlIG1vbWVudCB3aG9z ZSB0cmFmZmljIGlzIA0Kc2VudCBpbnRvIDI6MiwgYnV0ICpkb2Vzbm90KiBnZXQgbGltaXRlZCB0 byB0aGUgcmF0ZSBzcGVjaWZpZWQgaW4gMjoyLg0KDQpBbnkgY2x1ZXMgd291bGQgYmUgd2VsY29t ZS4NCg0KVElBLg0KDQpjaWFvLA0KQW1pdA0KcC5zLiBTdGVmIC0gWW91ICd0ZXN0cycgcGFnZSBp cyBkb3duLg0KDQpUaGUgc2NyaXB0IGZvbGxvd3M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIyEvYmluL3NoIC14DQoj IFNjcmlwdCB0byBzZWUgdGhlIHdvcmtpbmcgb2YgYm91bmRlZCBhbmQgaXNvbGF0ZWQNCg0KVEM9 Ii91c3IvYmluL3RjIg0KREVWPSJkZXYgZXRoMSINCkFWUEtUPSJhdnBrdCAxNTE0Ig0KQlc9ImJh bmR3aWR0aCAxME1iaXQiDQpNQVhCVVJTVD0ibWF4YnVyc3QgMjAwIg0KTVBVPSJtcHUgNjQiDQpD RUxMPSJjZWxsIDgiDQpBTExPVD0iYWxsb3QgMTUxNCINCiNSQVRFMT0icmF0ZSA2TWJpdCB3ZWln aHQgNjAwS2JpdCINCiNSQVRFMj0icmF0ZSA0TWJpdCB3ZWlnaHQgNDAwS2JpdCINClJBVEUxPSJy YXRlIDE1MEtiaXQgd2VpZ2h0IDE1MEtiaXQiDQpSQVRFMj0icmF0ZSAyMDBLYml0IHdlaWdodCAy MDBLYml0Ig0KDQojIFJvb3QgcWRpc2MgKDEwIE1iaXQpDQokVEMgcWRpc2MgYWRkICRERVYgcm9v dCBoYW5kbGUgMTowIGNicSAkQlcgJEFWUEtUICRDRUxMDQogDQojIFJvb3QgY2xhc3MgKDEwTWJp dCkNCiRUQyBjbGFzcyBhZGQgJERFViBwYXJlbnQgMTowIGNsYXNzaWQgMToxIGNicSAkQlcgJENF TEwgXA0KICAgIHByaW8gMyByYXRlIDEwTWJpdCAkQUxMT1QgJE1BWEJVUlNUICRBVlBLVCBcDQog ICAgYm91bmRlZA0KIA0KIyBFbmNsb3NpbmcgcWRpc2MgKDEwIE1iaXQpDQokVEMgcWRpc2MgYWRk ICRERVYgcGFyZW50IDE6MSBoYW5kbGUgMjowIGNicSAkQlcgJEFWUEtUICRDRUxMDQogDQojIEVu Y2xvc2luZyBjbGFzcyAoMTAgTWJpdCkNCiRUQyBjbGFzcyBhZGQgJERFViBwYXJlbnQgMjowIGNs YXNzaWQgMjoxIGNicSAkQlcgJENFTEwgXA0KICAgIHByaW8gMyByYXRlIDEwTWJpdCAkQUxMT1Qg JE1BWEJVUlNUICRBVlBLVA0KIA0KIyBSZWFsLXRpbWUgY2xhc3MgKDZNYml0KQ0KJFRDIGNsYXNz IGFkZCAkREVWIHBhcmVudCAyOjEgY2xhc3NpZCAyOjIgY2JxICRCVyAkQ0VMTCBcDQogICAgcHJp byAzICRSQVRFMSAkQUxMT1QgJE1BWEJVUlNUICRBVlBLVCBcDQogICAgaXNvbGF0ZWQNCiANCiMg QmVzdC1lZmZvcnQgY2xhc3MgKDRNYml0KQ0KJFRDIGNsYXNzIGFkZCAkREVWIHBhcmVudCAyOjEg Y2xhc3NpZCAyOjMgY2JxICRCVyAkQ0VMTCBcDQogICAgcHJpbyAzICRSQVRFMiAkQUxMT1QgJE1B WEJVUlNUICRBVlBLVCBcDQogICAgaXNvbGF0ZWQNCiANCiMgRHVtbXkgZmlsdGVyIChxZGlzYyAx OjAgdG8gY2xhc3MgMToxKQ0KJFRDIGZpbHRlciBhZGQgJERFViBwYXJlbnQgMTowIHByb3RvY29s IGlwIHByaW8gMiB1MzIgbWF0Y2ggaXAgdG9zIDB4MDAgDQoweDAwIGZsb3dpZCAxOjENCiANCiMg UlNWUCBmaWx0ZXIgdG8gc2VuZCBSVCB0cmFmZmljIGZyb20gMjowIHRvIDI6Mg0KJFRDIGZpbHRl ciBhZGQgJERFViBwYXJlbnQgMjowIHByb3RvY29sIGlwIHByaW8gMiByc3ZwIFwNCiAgICBpcHBy b3RvIHVkcCBzZXNzaW9uIDE5Mi4xNjguMTAwLjIvOTAwMSBmbG93aWQgMjoyDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQotLSANCkknbSBhbiBhbmdlbCEhISBIb25lc3QhDQpUaGUgaG9ybnMgYXJlIGp1c3QgdGhlcmUg dG8gaG9sZCB0aGUgaGFsbyB1cCBzdHJhaWdodC4NCl4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4t Xi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eDQogICAgICAgICAgICAgICAgICBBbWl0IEt1Y2hl cmlhDQogICAgICAgICAgRUVDUyBHcmFkLiBSZXNlYXJjaCBBc3Npc3RhbnQNCiAgICAgICAgIFVu aXZlcnNpdHkgb2YgS2Fuc2FzIEAgTGF3cmVuY2UNCiAgIChSKTogKzEtNzg1LTgzMC04NTIxIHx8 fCAoQyk6ICsxLTc4NS03NjAtMjg3MQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogMTENCkRhdGU6 IFRodSwgMjIgQXVnIDIwMDIgMDg6NDc6NDEgKzA3MDAgKFdJVCkNCkZyb206IE9raSBEWiA8b2tp ZHpAcGluZGFkLmNvbT4NClRvOiBsYXJ0Y0BtYWlsbWFuLmRzOWEubmwNClN1YmplY3Q6IFtMQVJU Q10gVXNlcm1vZGUgTGludXggJiBiYW5kd2lkdGggbGltaXQNCg0KSGksDQoNCldvdWxkIHRoZSBi YW5kd2l0aCBsaW1pdGVyIHdvcmsgYmV0d2VlbiB0aGUgdmlydHVhbCBtYWNoaW5lIGFuZCB0aGUg aG9zdA0KbWFjaGluZT8NCg0KW0ludGVybmV0XS0tLVtob3N0J3MgZXRoMF0tLS1bdmlydC4gbWFj aGluZV0tLS1baG9zdCdzIGV0aDFdLS0tW2ludGVybmFsXQ0KDQpJJ2QgbGlrZSB0byBsaW1pdCB0 aGUgYmFuZHdpZHRoIGZvciB0aGUgdHJhZmZpYyBnb2luZyBmcm9tIHRoZSB2aXJ0dWFsDQptYWNo aW5lIHRvIGEgZGFlbW9uIHJ1bm5pbmcgb24gdGhlIGhvc3QgKGEgU3F1aWQgdGhhdCBzZXJ2ZXMg YW4gaW50ZXJuYWwNCm5ldHdvcmspLg0KDQpUaGFua3MgaW4gYWR2YW5jZSwNCk9raQ0KDQoNCg0K DQotLV9fLS1fXy0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpMQVJUQyBtYWlsaW5nIGxpc3QNCkxBUlRDQG1haWxtYW4uZHM5YS5ubA0KaHR0cDov L21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9mIExBUlRD IERpZ2VzdA0KDQo= --MIME MULTIPART BOUNDARY=.1029990611:+'1 Content-Type: text/plain; charset=US-ASCII Content-Id: <3014839620-3@softerware.com> Content-Transfer-Encoding: 7bit I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #731 - 11 msgs From: lartc@mailman.ds9a.nl Date: 08/22/02 01:27:51 This item was automatically created and contains MIME Information. --MIME MULTIPART BOUNDARY=.1029990611:+'1-- From wepprop@sbcglobal.net Thu Aug 22 06:21:33 2002 From: wepprop@sbcglobal.net (William Powers) Date: Thu, 22 Aug 2002 00:21:33 -0500 Subject: [LARTC] Traffic Shaping Script to Optimize FPS Game Performance Message-ID: <000a01c2499b$c76d9000$0264a8c0@mars.sol> I have several kids and, to keep them happy and myself busy, I run 6 Windows boxes behind a Linux box that firewalls and SNAT's. Our internet connection is ADSL with nominal line speeds of 128 kbit up and 1400 kbit down. Everything has worked well except when one person is playing a first person shooter like Q3, CS, RTCW, etc. and someone else is downloading, uploading, sending mail with large attachments, etc. Whenever this occurs, shouting and disharmony usually results. To fix this, I recently dug through the Linux Advanced Routing & Traffic Control HOWTO, along with several other references, and I have been able to address all of the issues: Typical game pings now do not change at all during heavy downloads, and increase only slightly (~10 - 20 msec) during heavy uploads. The cost of this is about an 15% decrease in download bandwidth, and about a 30% decrease in upload bandwidth, which I have found to be more than acceptable. I started with the HTB version of the "Ultimate Traffic Conditioner" script in the HOWTO and then tweaked it a bit to reduce game traffic latency even further, including the addition of a trivial bit of policy routing to send all non-game packets through a default route with a very small per-route MTU. I have attached a script of my implementation below. I've done this a) for the benefit of anyone searching the mailing list archive, and b) on the chance that someone might know of a way to improve upon my results! :) Questions, comments, and suggestions are all welcome. My thanks to the authors of this excellent HOWTO! Bill Powers wepprop@sbcglobal.net #!/bin/sh # # GameScript This script establishes policy routing and traffic # control rules to minimize latency for game packets # in the presence of other traffic. # # Besides this script, there is one other thing that must be done. # Assuming that iproute2 is already installed, edit the file # /etc/iproute2/rt_tables and add the following line at the bottom: # "100 Small_MTU" # *********************************************************************** # DEFINES * # *********************************************************************** # Change these values as required to reflect your setup # Addresses and Interfaces LAN_IP_RANGE="192.168.1.0/24" LAN_IP="192.168.0.1" LAN_INTERFACE="eth0" LOCALHOST_IP="127.0.0.1/32" INTERNET_IP_RANGE="123.123.123.0/24" INTERNET_IP="123.123.123.123" INTERNET_GATEWAY="123.123.123.1" INTERNET_INTERFACE="eth1" # Executables IPTABLES="/sbin/iptables" TC="/sbin/tc" IP="/sbin/ip" # Information used to identify game traffic. # add more as required HOST1="192.168.0.2" HOST1_GAME_PORT="27661" # Packet marks (arbitrary) GAME_PACKET="1" # For traffic shaping: # # The numbers below were arrived at by test on a DSL # line with nominal line speeds of 128 kbit up and # 1400 kbit down. Actual measured throughput was # about 90 kbit up and 1150 kbit down. # # A note regarding MTU: Standard ethernet MTU is 1500 # bytes, which which resulted in unacceptable single # packet xmit waits of 1500 x 8 / 90,000 = 133 msec. # Lowering the interface MTU changes the MTU in both # directions, which helped uplink latency but hurt # downlink throughput. Lowering the interface MTU to # 256 bytes resulted in a downlink throughput of less # than 500kbit. An interface MTU in the 400 - 500 byte # range provided an acceptable compromise, with single # packet xmit times of about 40 msec and downlink speeds # of about 700kbit. However, leaving the interface MTU # at 1500 bytes and setting a lower per-route MTU that # only affected non-game uplink traffic was the best # solution. An uplink MTU smaller than 256 bytes would # help latency even more, but tc and/or htb don't seem # to like mtu's below 256 and, besides, 256 results in a max # single packet xmit wait of around 25 msec, with # even better average behavior. STD_MTU="1500" TC_MTU="256" TC_MSS=$(( $STD_MTU - 40 )) TC_UPLINK_RATE="90" TC_DOWNLINK_RATE="1000" TC_GAME_RATE="30" TC_GAME_CEIL=$TC_UPLINK_RATE TC_OTHER_RATE=$(( $TC_UPLINK_RATE - $TC_GAME_RATE )) TC_OTHER_CEIL=$(( $TC_UPLINK_RATE - $TC_GAME_RATE )) # ********************************************************************* # RULES * # ********************************************************************* case "$1" in start) # *************************************************************** # MANGLE Table PREROUTING Chain * # *************************************************************** # Firewall packet marking TCP game traffic from Host1 $IPTABLES --table mangle \ --append PREROUTING \ --protocol TCP \ --in-interface $LAN_INTERFACE \ --source $HOST1 \ --source-port $HOST1_GAME_PORT \ --jump MARK \ --set-mark $GAME_PACKET # Firewall packet marking UDP game traffic from Host1 $IPTABLES --table mangle \ --append PREROUTING \ --protocol UDP \ --in-interface $LAN_INTERFACE \ --source $HOST1 \ --source-port $HOST1_GAME_PORT \ --jump MARK \ --set-mark $GAME_PACKET # Firewall packet marking TCP game traffic to Host1 $IPTABLES --table mangle \ --append PREROUTING \ --protocol TCP \ --in-interface $INTERNET_INTERFACE \ --destination $HOST1 \ --destination-port $HOST1_GAME_PORT \ --jump MARK \ --set-mark $GAME_PACKET # Firewall packet marking UDP game traffic to Host1 $IPTABLES --table mangle \ --append PREROUTING \ --protocol UDP \ --in-interface $INTERNET_INTERFACE \ --destination $HOST1 \ --destination-port $HOST1_GAME_PORT \ --jump MARK \ --set-mark $GAME_PACKET # *************************************************************** # Policy Routing * # *************************************************************** # Delete any existing / old rules. $IP rule del priority 4000 2> /dev/null $IP rule del priority 5000 2> /dev/null # Flush the alternate routing table and routing cache $IP route flush table Small_MTU 2> /dev/null $IP route flush cache # Duplicate the normal routing table except lower the MTU of the # default route. $IP route add $LOCALHOST_IP dev lo table Small_MTU $IP route add $LAN_IP_RANGE dev $LAN_INTERFACE src $LAN_IP \ table Small_MTU proto static $IP route add $INTERNET_IP_RANGE dev $INTERNET_INTERFACE \ src $INTERNET_IP table Small_MTU proto static $IP route add default via $INTERNET_GATEWAY mtu $TC_MTU \ advmss $TC_MSS table Small_MTU proto static # Game traffic continues to go to the main routing table with # so that it can take advantage of larger uplink packet sizes. $IP rule add fwmark $GAME_PACKET priority 4000 table main # Now start referring non-game traffic to the new routing table $IP rule add from 0/0 priority 5000 table Small_MTU $IP route flush cache # *************************************************************** # Uplink Traffic Control * # *************************************************************** # Egress bandwidth shaping and scheduling are performed to ensure # that packets are never queued in the ADSL modem, and that game # packets, if present, take priority over all other traffic. # First delete any previous traffic control rules $TC qdisc del dev $INET_IFACE root 2> /dev/null $TC qdisc del dev $INET_IFACE ingress 2> /dev/null # Now establish the HTB root discipline $TC qdisc add dev $INTERNET_INTERFACE root handle 1:0 \ htb default 11 r2q 1 # Now establish the root class $TC class add dev $INTERNET_INTERFACE parent 1:0 classid 1:1 \ htb rate $TC_UPLINK_RATE"kbit" ceil $TC_UPLINK_RATE"kbit" \ burst 6k cburst 6k # Add leaf class for game traffic $TC class add dev $INTERNET_INTERFACE parent 1:1 classid 1:10 \ htb rate $TC_GAME_RATE"kbit" ceil $TC_GAME_CEIL"kbit" \ prio 1 burst 6k cburst 6k # Add leaf class for non-game traffic. Note that non-game # traffic is capped at about 67% of the available uplink # bandwidth, both for rate and ceiling. This was done # to ensure that sufficient bandwidth (tokens) is always # available for game packets when they arrive. $TC class add dev $INTERNET_INTERFACE parent 1:1 classid 1:11 \ htb rate $TC_OTHER_RATE"kbit" ceil $TC_OTHER_CEIL"kbit" \ prio 2 mtu $TC_MTU # Add fifo queueing discipline for game traffic $TC qdisc add dev $INTERNET_INTERFACE parent 1:10 handle 10: \ pfifo limit 25 # Add prio queueing discipline for non-game traffic to provide # standard TOS priority queueing. $TC qdisc add dev $INTERNET_INTERFACE parent 1:11 handle 11: \ prio # Add sfq queueing discipline for minimize-delay traffic $TC qdisc add dev $INTERNET_INTERFACE parent 11:1 handle 111: \ sfq perturb 5 # Add sfq queueing discipline for best-effort traffic $TC qdisc add dev $INTERNET_INTERFACE parent 11:2 handle 112: \ sfq perturb 5 # Add sfq queueing discipline for maximize-throughput traffic $TC qdisc add dev $INTERNET_INTERFACE parent 11:3 handle 113: \ sfq perturb 5 # Now filter game traffic to leaf 1:10 as first priority $TC filter add dev $INTERNET_INTERFACE parent 1:0 \ protocol ip prio 1 handle $GAME_PACKET fw flowid 1:10 # Empty ack packets are assigned directly to the minimize- # delay queue. $TC filter add dev $INTERNET_INTERFACE parent 11:0 protocol ip \ prio 3 u32 match ip protocol 6 0xff \ match u8 0x05 0x0f at 0 \ match u16 0x0000 0xffc0 at 2 \ match u8 0x10 0xff at 33 \ flowid 11:1 # The remaining traffic defaults to htb leaf 1:11 # ************************************************************** # Downlink Traffic Control (Ingress Policing) * # ************************************************************** # Downlink traffic is limited to about 85% of actual downlink # capability to prevent upstream queueing. # First establish an ingress qdisc $TC qdisc add dev $INTERNET_INTERFACE handle ffff: ingress # Incoming game traffic is not policed $TC filter add dev $INTERNET_INTERFACE parent ffff: \ protocol ip prio 1 handle $GAME_PACKET fw flowid :1 # Filter everything else to that qdisc and drop packets # that exceed the bandwidth limit $TC filter add dev $INTERNET_INTERFACE parent ffff: \ protocol ip prio 3 u32 match ip src 0.0.0.0/0 \ police rate $TC_DOWNLINK_RATE"kbit" burst 3k drop \ flowid :1 ;; stop) # Remove any uplink throttling $TC qdisc del dev $INTERNET_INTERFACE root 2> /dev/null $TC qdisc del dev $INTERNET_INTERFACE ingress 2> /dev/null # Remove policy routing $IP rule del priority 5000 2> /dev/null $IP rule del priority 4000 2> /dev/null $IP route flush table Small_MTU 2> /dev/null $IP route flush cache ;; restart) $0 stop sleep 3 $0 start ;; *) echo "Usage: ./$0 start|stop|restart}" exit 1 esac exit 0 From LARTC@Tech.InteractiveNetworks.net Thu Aug 22 08:00:54 2002 From: LARTC@Tech.InteractiveNetworks.net (George J. Jahchan) Date: Thu, 22 Aug 2002 10:00:54 +0300 Subject: [LARTC] Is TC flow-aware? Message-ID: <012f01c249a9$b2a56680$0a0fa8c0@diabelec.com> Is TC flow-aware for individual flows (sessions) within a given class of traffic? For example, assuming 100Kbps allocated to a class and 100 simultaneous active flows within that class. Will each flow get approx. 1K, or will the greedier flows capture the lion's share of the 100K, leaving the others struggling to go through? Conversely, when a queue fills up and packets from that queue must be drop- ped, will TC drop packets from the greedier flows (that are most likely causing the congestion) or does it not distinguish between flows? In the latter case, which rules determine the packets that get dropped? From amitk@ittc.ku.edu Thu Aug 22 08:06:02 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Thu, 22 Aug 2002 02:06:02 -0500 (CDT) Subject: [LARTC] Is TC flow-aware? In-Reply-To: <012f01c249a9$b2a56680$0a0fa8c0@diabelec.com> Message-ID: On Thu, 22 Aug 2002, George J. Jahchan wrote: > Is TC flow-aware for individual flows (sessions) within a given class of > traffic? No, TC isnt flow-aware. If all the flows fall into the same class, packets will be dropped on a "need-to-drop" basis. Also the greedy flow will be able to hog bandwidth unless it is policed at the edge of the traffic control network. But you could use something like Diffserv which has various drop probabilities and thus control which flows have more drop probability. -Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From amitk@ittc.ku.edu Thu Aug 22 08:07:55 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Thu, 22 Aug 2002 02:07:55 -0500 (CDT) Subject: [LARTC] HTB & GRED Message-ID: With reference to the following post: http://mailman.ds9a.nl/pipermail/lartc/2002q1/002410.html Was anybody able to create GRED virtual queues inside HTB? Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From karl.gaissmaier@rz.uni-ulm.de Thu Aug 22 08:38:58 2002 From: karl.gaissmaier@rz.uni-ulm.de (Karl Gaissmaier) Date: Thu, 22 Aug 2002 09:38:58 +0200 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregistered hosts Message-ID: <3D649512.976BA7DF@rz.uni-ulm.de> Hi perhaps someone else already had the same problem. Problem description: I'm running a class B University network with approx 10k hosts attached. I would now like to stop traffic from and to hosts in my network not already registered in my DNS server. This means I've to handle with approx 50k rules|routes. Sure I can summarize the unalloctaed address space a little bit with masks to approx 30k rules, anyway this seems to be a problem. Question: What will be the best solution between the different choices netfilter/iptables, ip route(s) ... type prohibit and tc filter ... u32 ... police 0kbps netfilter/iptables doesn't seem to scale well and the only match module "pool" which is able to deal with pools of addresses seemes to stay in alpha state. With ip route I think I have to describe all unregistered hosts to stop traffic and not the smaller amount of registered hosts. Does the FIB and route cache scale well to approx 30k routes? Is it possible and more performant to use tc to throttle down traffic to unregistered hosts already in the ingress lane without hitting the routing and netfilter engine with this traffic? Does tc scale well with this huge amount addresses/masks? How could this be handled with tc? Regards and thanks in advance for any hint Charly P.S. Speed is important, this linux router/firewall connects Gigabit Ethernet networks -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:karl.gaissmaier@rz.uni-ulm.de Network Administration Tel.: ++49 731 50-22499 From kustosz@veb.pl Thu Aug 22 15:29:01 2002 From: kustosz@veb.pl (Michal Kustosik) Date: Thu, 22 Aug 2002 16:29:01 +0200 Subject: [LARTC] htb and priority of borrowing bandwidth... Message-ID: <20020822162901.A2360@veb.pl> Hello... I have a question about htb... Is it possible to share bandwidth with some proportion? For example, I have: tc qdisc add dev $INT root handle 1: htb default 12 tc class add dev $INT parent 1: classid 1:1 htb rate 300kbit ceil 300kbit tc class add dev $INT parent 1:1 classid 1:10 htb rate 50kbit ceil 300kbit tc class add dev $INT parent 1:1 classid 1:11 htb rate 50kbit ceil 300kbit but I wanted class 1:10 to borrow five times bigger bandwidth than 1:11. Is it possible with htb ??? Greetings... /kustosz From karl.gaissmaier@rz.uni-ulm.de Thu Aug 22 21:44:07 2002 From: karl.gaissmaier@rz.uni-ulm.de (Karl Gaissmaier) Date: Thu, 22 Aug 2002 22:44:07 +0200 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregistered hosts References: <3D649512.976BA7DF@rz.uni-ulm.de> <20020822140528.379dc63a.marian.jancar@nmskb.cz> Message-ID: <3D654D17.6402BCDE@rz.uni-ulm.de> Marian Jancar schrieb: > > On Thu, 22 Aug 2002 09:38:58 +0200 > "Karl Gaissmaier" wrote: > > > I'm running a class B University network with approx 10k hosts > > attached. I would now like to stop traffic from and to hosts > > in my network not already registered in my DNS server. > > > > This means I've to handle with approx 50k rules|routes. Sure > > I can summarize the unalloctaed address space a little bit > > with masks to approx 30k rules, anyway this seems to be a problem. > > Create tree with decreasing netmask, you will have more rules in total > but packets will have to travel through only few of them. Yep, I thought already about this. If I set decreasing netmasks from /17 to /32 I would end up with 2^16 chains but after 16 comparisons I would have a match. This would be the extreme! If I create 256 different chains based on a /24 netmask then I would have a match at least after 256 + 256 = 512 comparisons. The first max 256 comparisons select the next chain and the last max 256 comparisons select the /32 address in this special chain. Anyway I find this ugly with iptables that we have no MADDR match (in analogy to MPORT). If you build a firewall you try always to build groups of services (mport) and groups of servers/clients (maddr). With iptables you have to reply the same rule n times for n similar servers/clients. This is ugly and a performance bottleneck because these similar rules are cheched sequentially. Best regards and thanks for your tip. Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:karl.gaissmaier@rz.uni-ulm.de Network Administration From karl.gaissmaier@rz.uni-ulm.de Thu Aug 22 21:55:57 2002 From: karl.gaissmaier@rz.uni-ulm.de (Karl Gaissmaier) Date: Thu, 22 Aug 2002 22:55:57 +0200 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregistered hosts References: <3D649512.976BA7DF@rz.uni-ulm.de> <20020822160205.GA32725@ossifrage.net> Message-ID: <3D654FDD.15C9D9FC@rz.uni-ulm.de> Robert Collier schrieb: > > Hi Karl, > > I don't have any suggestions for an easy way to solve your problem - > but: > > On Thu, Aug 22, 2002 at 09:38:58AM +0200, Karl Gaissmaier wrote: > > With ip route I think I have to describe all unregistered hosts > > to stop traffic and not the smaller amount of registered hosts. > > Does the FIB and route cache scale well to approx 30k routes? > > With 'large routing tables' enabled the kernel works just fine with a > full internet routing table of 115,000 routes so a mere 30,000 should > be a doddle. > > Your main problem will be getting the routes into the kernel. Yes this is a problem. I tried for fun to build a 64k routing table with: ip route add type prohibit 10.0.i.j (i=0..255; j=0..255) and this took more than one hour on my home desktop (old pentium 90) to fill the routing table. Even if I know that this is pretty old stuff I was astonished over this slow progress. The question that arises is now for me, how long does it take for a full internet routing table to get synchronized after a route flush with a linux router? Anyway, you told me that the kernel works fine with 115k routes but be aware I will use this with Gigabit Interfaces. What is the average forwarding time in ms for a packet with 115k routes? Best regards and thanks for your answer Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:karl.gaissmaier@rz.uni-ulm.de Network Administration From karl.gaissmaier@rz.uni-ulm.de Thu Aug 22 22:04:47 2002 From: karl.gaissmaier@rz.uni-ulm.de (Karl Gaissmaier) Date: Thu, 22 Aug 2002 23:04:47 +0200 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts References: <3D649512.976BA7DF@rz.uni-ulm.de> <3D64DCA8.7020805@tamu.edu> Message-ID: <3D6551EF.49730B2E@rz.uni-ulm.de> Gerry Creager N5JXS schrieb: > > The answers are not necessarily pretty. > > I've done a similar task with a Juniper M5 router. It will handle up to > about 180,000 rules at wire speed. But it is expensive. > > If your switches were a little newer, we could use 802.1x to enable the > switch-use capability flag (:-) and solve the problem. you know, 10k hosts are never attached to a network with homogenous new network devices :-( > > Instead of policing at a single edge point, you might consider policing > at dormatory and building edges, where the load is smaller and you can > use masking and diminsh the ruleset some more. but the management is very difficult, see above > > With a sufficiently fast box, or series of boxes, doing specific tasks, > you should be able to do this. Folks like Juniper achieve it by being > able to classify and mark in ASIC without having to go to the processor. Netfilter and iproute2/tc is very good but I miss just a fast matching module for a "pool" of ip addresses and the missing tc-cref or better documented tc examples, especially dealing with general ingress policing. Best regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:karl.gaissmaier@rz.uni-ulm.de Network Administration From mikep02@softerware.com Thu Aug 22 22:17:35 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Thu, 22 Aug 2002 17:17:35 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #733 - 12 msgs Message-ID: <2340648442@softerware.com> --MIME MULTIPART BOUNDARY=.1030051089:+'1 Content-Type: application/octet-stream Content-Id: <2340648442-2@softerware.com> Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Text Item" U2VuZCBMQVJUQyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCglsYXJ0Y0BtYWlsbWFuLmRz OWEubmwNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBX ZWIsIHZpc2l0DQoJaHR0cDovL21haWxtYW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRj DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVs cCcgdG8NCglsYXJ0Yy1yZXF1ZXN0QG1haWxtYW4uZHM5YS5ubA0KDQpZb3UgY2FuIHJlYWNoIHRo ZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCglsYXJ0Yy1hZG1pbkBtYWlsbWFuLmRzOWEu bmwNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQg aXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIExBUlRDIGRpZ2VzdC4uLiIN Cg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gVHJhZmZpYyBTaGFwaW5nIFNjcmlwdCB0byBP cHRpbWl6ZSBGUFMgR2FtZSBQZXJmb3JtYW5jZSAoV2lsbGlhbSBQb3dlcnMpDQogICAyLiBJcyBU QyBmbG93LWF3YXJlPyAoR2VvcmdlIEouIEphaGNoYW4pDQogICAzLiBSZTogSXMgVEMgZmxvdy1h d2FyZT8gKEFtaXQgS3VjaGVyaWEpDQogICA0LiBIVEIgJiBHUkVEIChBbWl0IEt1Y2hlcmlhKQ0K ICAgNS4gUTogYmVzdCBzb2x1dGlvbiB0byBzdG9wIHRyYWZmaWMgdG8gaHVnZSBhbW91bnQgb2Yg dW5yZWdpc3RlcmVkIGhvc3RzIChLYXJsIEdhaXNzbWFpZXIpDQogICA2LiBodGIgYW5kIHByaW9y aXR5IG9mIGJvcnJvd2luZyBiYW5kd2lkdGguLi4gKE1pY2hhbCBLdXN0b3NpaykNCiAgIDcuIFJl OiBROiBiZXN0IHNvbHV0aW9uIHRvIHN0b3AgdHJhZmZpYyB0byBodWdlIGFtb3VudCBvZg0KICAg ICAgIHVucmVnaXN0ZXJlZCBob3N0cyAoS2FybCBHYWlzc21haWVyKQ0KICAgOC4gUmU6IFE6IGJl c3Qgc29sdXRpb24gdG8gc3RvcCB0cmFmZmljIHRvIGh1Z2UgYW1vdW50IG9mDQogICAgICAgdW5y ZWdpc3RlcmVkIGhvc3RzIChLYXJsIEdhaXNzbWFpZXIpDQogICA5LiBSZTogUTogYmVzdCBzb2x1 dGlvbiB0byBzdG9wIHRyYWZmaWMgdG8gaHVnZSBhbW91bnQgb2YNCiAgICAgICB1bnJlZ2lzdGVy ZWRob3N0cyAoS2FybCBHYWlzc21haWVyKQ0KDQotLV9fLS1fXy0tDQoNCk1lc3NhZ2U6IDENCkZy b206ICJXaWxsaWFtIFBvd2VycyIgPHdlcHByb3BAc2JjZ2xvYmFsLm5ldD4NClRvOiA8bGFydGNA bWFpbG1hbi5kczlhLm5sPg0KRGF0ZTogVGh1LCAyMiBBdWcgMjAwMiAwMDoyMTozMyAtMDUwMA0K U3ViamVjdDogW0xBUlRDXSBUcmFmZmljIFNoYXBpbmcgU2NyaXB0IHRvIE9wdGltaXplIEZQUyBH YW1lIFBlcmZvcm1hbmNlDQoNCkkgaGF2ZSBzZXZlcmFsIGtpZHMgYW5kLCB0byBrZWVwIHRoZW0g aGFwcHkgYW5kIG15c2VsZiBidXN5LCBJIHJ1biA2IFdpbmRvd3MNCmJveGVzIGJlaGluZCBhIExp bnV4IGJveCB0aGF0IGZpcmV3YWxscyBhbmQgU05BVCdzLiAgT3VyIGludGVybmV0IGNvbm5lY3Rp b24NCmlzIEFEU0wgd2l0aCBub21pbmFsIGxpbmUgc3BlZWRzIG9mIDEyOCBrYml0IHVwIGFuZCAx NDAwIGtiaXQgZG93bi4NCkV2ZXJ5dGhpbmcgaGFzIHdvcmtlZCB3ZWxsIGV4Y2VwdCB3aGVuIG9u ZSBwZXJzb24gaXMgcGxheWluZyBhIGZpcnN0IHBlcnNvbg0Kc2hvb3RlciBsaWtlIFEzLCBDUywg UlRDVywgZXRjLiBhbmQgc29tZW9uZSBlbHNlIGlzIGRvd25sb2FkaW5nLCB1cGxvYWRpbmcsDQpz ZW5kaW5nIG1haWwgd2l0aCBsYXJnZSBhdHRhY2htZW50cywgZXRjLiAgV2hlbmV2ZXIgdGhpcyBv Y2N1cnMsIHNob3V0aW5nDQphbmQgZGlzaGFybW9ueSB1c3VhbGx5IHJlc3VsdHMuDQoNClRvIGZp eCB0aGlzLCBJIHJlY2VudGx5IGR1ZyB0aHJvdWdoIHRoZSBMaW51eCBBZHZhbmNlZCBSb3V0aW5n ICYgVHJhZmZpYw0KQ29udHJvbCBIT1dUTywgYWxvbmcgd2l0aCBzZXZlcmFsIG90aGVyIHJlZmVy ZW5jZXMsIGFuZCBJIGhhdmUgYmVlbiBhYmxlIHRvDQphZGRyZXNzIGFsbCBvZiB0aGUgaXNzdWVz OiAgVHlwaWNhbCBnYW1lIHBpbmdzIG5vdyBkbyBub3QgY2hhbmdlIGF0IGFsbA0KZHVyaW5nIGhl YXZ5IGRvd25sb2FkcywgYW5kIGluY3JlYXNlIG9ubHkgc2xpZ2h0bHkgKH4xMCAtIDIwIG1zZWMp IGR1cmluZw0KaGVhdnkgdXBsb2Fkcy4gIFRoZSBjb3N0IG9mIHRoaXMgaXMgYWJvdXQgYW4gMTUl IGRlY3JlYXNlIGluIGRvd25sb2FkDQpiYW5kd2lkdGgsIGFuZCBhYm91dCBhIDMwJSBkZWNyZWFz ZSBpbiB1cGxvYWQgYmFuZHdpZHRoLCB3aGljaCBJIGhhdmUgZm91bmQNCnRvIGJlIG1vcmUgdGhh biBhY2NlcHRhYmxlLg0KDQpJIHN0YXJ0ZWQgd2l0aCB0aGUgSFRCIHZlcnNpb24gb2YgdGhlICJV bHRpbWF0ZSBUcmFmZmljIENvbmRpdGlvbmVyIiBzY3JpcHQNCmluIHRoZSBIT1dUTyBhbmQgdGhl biB0d2Vha2VkIGl0IGEgYml0IHRvIHJlZHVjZSBnYW1lIHRyYWZmaWMgbGF0ZW5jeSBldmVuDQpm dXJ0aGVyLCBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uIG9mIGEgdHJpdmlhbCBiaXQgb2YgcG9saWN5 IHJvdXRpbmcgdG8gc2VuZA0KYWxsIG5vbi1nYW1lIHBhY2tldHMgdGhyb3VnaCBhIGRlZmF1bHQg cm91dGUgd2l0aCBhIHZlcnkgc21hbGwgcGVyLXJvdXRlDQpNVFUuDQoNCkkgaGF2ZSBhdHRhY2hl ZCBhIHNjcmlwdCBvZiBteSBpbXBsZW1lbnRhdGlvbiBiZWxvdy4gIEkndmUgZG9uZSB0aGlzIGEp IGZvcg0KdGhlIGJlbmVmaXQgb2YgYW55b25lIHNlYXJjaGluZyB0aGUgbWFpbGluZyBsaXN0IGFy Y2hpdmUsIGFuZCBiKSBvbiB0aGUNCmNoYW5jZSB0aGF0IHNvbWVvbmUgbWlnaHQga25vdyBvZiBh IHdheSB0byBpbXByb3ZlIHVwb24gbXkgcmVzdWx0cyEgIDopDQoNClF1ZXN0aW9ucywgY29tbWVu dHMsIGFuZCBzdWdnZXN0aW9ucyBhcmUgYWxsIHdlbGNvbWUuDQoNCk15IHRoYW5rcyB0byB0aGUg YXV0aG9ycyBvZiB0aGlzIGV4Y2VsbGVudCBIT1dUTyENCg0KQmlsbCBQb3dlcnMNCndlcHByb3BA c2JjZ2xvYmFsLm5ldA0KDQoNCiMhL2Jpbi9zaA0KIw0KIyBHYW1lU2NyaXB0ICAgICBUaGlzIHNj cmlwdCBlc3RhYmxpc2hlcyBwb2xpY3kgcm91dGluZyBhbmQgdHJhZmZpYw0KIyAgICAgICAgICAg ICAgICBjb250cm9sIHJ1bGVzIHRvIG1pbmltaXplIGxhdGVuY3kgZm9yIGdhbWUgcGFja2V0cw0K IyAgICAgICAgICAgICAgICBpbiB0aGUgcHJlc2VuY2Ugb2Ygb3RoZXIgdHJhZmZpYy4NCiMNCg0K IyBCZXNpZGVzIHRoaXMgc2NyaXB0LCB0aGVyZSBpcyBvbmUgb3RoZXIgdGhpbmcgdGhhdCBtdXN0 IGJlIGRvbmUuDQojIEFzc3VtaW5nIHRoYXQgaXByb3V0ZTIgaXMgYWxyZWFkeSBpbnN0YWxsZWQs IGVkaXQgdGhlIGZpbGUNCiMgL2V0Yy9pcHJvdXRlMi9ydF90YWJsZXMgYW5kIGFkZCB0aGUgZm9s bG93aW5nIGxpbmUgYXQgdGhlIGJvdHRvbToNCiMgIjEwMCAgU21hbGxfTVRVIg0KDQojICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQojIERFRklORVMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAqDQojICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCiMgQ2hhbmdl IHRoZXNlIHZhbHVlcyBhcyByZXF1aXJlZCB0byByZWZsZWN0IHlvdXIgc2V0dXANCg0KIyBBZGRy ZXNzZXMgYW5kIEludGVyZmFjZXMNCkxBTl9JUF9SQU5HRT0iMTkyLjE2OC4xLjAvMjQiDQpMQU5f SVA9IjE5Mi4xNjguMC4xIg0KTEFOX0lOVEVSRkFDRT0iZXRoMCINCkxPQ0FMSE9TVF9JUD0iMTI3 LjAuMC4xLzMyIg0KSU5URVJORVRfSVBfUkFOR0U9IjEyMy4xMjMuMTIzLjAvMjQiDQpJTlRFUk5F VF9JUD0iMTIzLjEyMy4xMjMuMTIzIg0KSU5URVJORVRfR0FURVdBWT0iMTIzLjEyMy4xMjMuMSIN CklOVEVSTkVUX0lOVEVSRkFDRT0iZXRoMSINCg0KIyBFeGVjdXRhYmxlcw0KDQpJUFRBQkxFUz0i L3NiaW4vaXB0YWJsZXMiDQpUQz0iL3NiaW4vdGMiDQpJUD0iL3NiaW4vaXAiDQoNCiMgSW5mb3Jt YXRpb24gdXNlZCB0byBpZGVudGlmeSBnYW1lIHRyYWZmaWMuDQojIGFkZCBtb3JlIGFzIHJlcXVp cmVkDQoNCkhPU1QxPSIxOTIuMTY4LjAuMiINCkhPU1QxX0dBTUVfUE9SVD0iMjc2NjEiDQoNCiMg UGFja2V0IG1hcmtzIChhcmJpdHJhcnkpDQoNCkdBTUVfUEFDS0VUPSIxIg0KDQojIEZvciB0cmFm ZmljIHNoYXBpbmc6DQojDQojIFRoZSBudW1iZXJzIGJlbG93IHdlcmUgYXJyaXZlZCBhdCBieSB0 ZXN0IG9uIGEgRFNMDQojIGxpbmUgd2l0aCBub21pbmFsIGxpbmUgc3BlZWRzIG9mIDEyOCBrYml0 IHVwIGFuZA0KIyAxNDAwIGtiaXQgZG93bi4gIEFjdHVhbCBtZWFzdXJlZCB0aHJvdWdocHV0IHdh cw0KIyBhYm91dCA5MCBrYml0IHVwIGFuZCAxMTUwIGtiaXQgZG93bi4NCiMNCiMgQSBub3RlIHJl Z2FyZGluZyBNVFU6ICBTdGFuZGFyZCBldGhlcm5ldCBNVFUgaXMgMTUwMA0KIyBieXRlcywgd2hp Y2ggd2hpY2ggcmVzdWx0ZWQgaW4gdW5hY2NlcHRhYmxlIHNpbmdsZQ0KIyBwYWNrZXQgeG1pdCB3 YWl0cyBvZiAxNTAwIHggOCAvIDkwLDAwMCA9IDEzMyBtc2VjLg0KIyBMb3dlcmluZyB0aGUgaW50 ZXJmYWNlIE1UVSBjaGFuZ2VzIHRoZSBNVFUgaW4gYm90aA0KIyBkaXJlY3Rpb25zLCB3aGljaCBo ZWxwZWQgdXBsaW5rIGxhdGVuY3kgYnV0IGh1cnQNCiMgZG93bmxpbmsgdGhyb3VnaHB1dC4gIExv d2VyaW5nIHRoZSBpbnRlcmZhY2UgTVRVIHRvDQojIDI1NiBieXRlcyByZXN1bHRlZCBpbiBhIGRv d25saW5rIHRocm91Z2hwdXQgb2YgbGVzcw0KIyB0aGFuIDUwMGtiaXQuIEFuIGludGVyZmFjZSBN VFUgaW4gdGhlIDQwMCAtIDUwMCBieXRlDQojIHJhbmdlIHByb3ZpZGVkIGFuIGFjY2VwdGFibGUg Y29tcHJvbWlzZSwgd2l0aCBzaW5nbGUNCiMgcGFja2V0IHhtaXQgdGltZXMgb2YgYWJvdXQgNDAg bXNlYyBhbmQgZG93bmxpbmsgc3BlZWRzDQojIG9mIGFib3V0IDcwMGtiaXQuIEhvd2V2ZXIsIGxl YXZpbmcgdGhlIGludGVyZmFjZSBNVFUNCiMgYXQgMTUwMCBieXRlcyBhbmQgc2V0dGluZyBhIGxv d2VyIHBlci1yb3V0ZSBNVFUgdGhhdA0KIyBvbmx5IGFmZmVjdGVkIG5vbi1nYW1lIHVwbGluayB0 cmFmZmljIHdhcyB0aGUgYmVzdA0KIyBzb2x1dGlvbi4gIEFuIHVwbGluayBNVFUgc21hbGxlciB0 aGFuIDI1NiBieXRlcyB3b3VsZA0KIyBoZWxwIGxhdGVuY3kgZXZlbiBtb3JlLCBidXQgdGMgYW5k L29yIGh0YiBkb24ndCBzZWVtDQojIHRvIGxpa2UgbXR1J3MgYmVsb3cgMjU2IGFuZCwgYmVzaWRl cywgMjU2IHJlc3VsdHMgaW4gYSBtYXgNCiMgc2luZ2xlIHBhY2tldCB4bWl0IHdhaXQgb2YgYXJv dW5kIDI1IG1zZWMsIHdpdGgNCiMgZXZlbiBiZXR0ZXIgYXZlcmFnZSBiZWhhdmlvci4NCg0KU1RE X01UVT0iMTUwMCINClRDX01UVT0iMjU2Ig0KDQpUQ19NU1M9JCgoICRTVERfTVRVIC0gNDAgKSkN Cg0KVENfVVBMSU5LX1JBVEU9IjkwIg0KVENfRE9XTkxJTktfUkFURT0iMTAwMCINClRDX0dBTUVf UkFURT0iMzAiDQpUQ19HQU1FX0NFSUw9JFRDX1VQTElOS19SQVRFDQpUQ19PVEhFUl9SQVRFPSQo KCAkVENfVVBMSU5LX1JBVEUgLSAkVENfR0FNRV9SQVRFICkpDQpUQ19PVEhFUl9DRUlMPSQoKCAk VENfVVBMSU5LX1JBVEUgLSAkVENfR0FNRV9SQVRFICkpDQoNCiMgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQojIFJV TEVTICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKg0KIyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KY2FzZSAiJDEiIGluDQogIHN0YXJ0KQ0KDQog ICAgICAjICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KICAgICAgIyBNQU5HTEUgVGFibGUgUFJFUk9VVElORyBDaGFpbiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiAgICAgICMgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCiAgICAgICMg RmlyZXdhbGwgcGFja2V0IG1hcmtpbmcgVENQIGdhbWUgdHJhZmZpYyBmcm9tIEhvc3QxDQoNCiAg ICAgICRJUFRBQkxFUyAgIC0tdGFibGUgICAgICAgICAgICAgICAgIG1hbmdsZSAgICAgICAgICAg ICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAtLWFwcGVuZCAgICAgICAgICAgICAgICBQ UkVST1VUSU5HICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAgLS1wcm90b2Nv bCAgICAgICAgICAgICAgVENQICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAg ICAgICAgIC0taW4taW50ZXJmYWNlICAgICAgICAgICRMQU5fSU5URVJGQUNFICAgICAgICAgICAg ICBcDQogICAgICAgICAgICAgICAgICAtLXNvdXJjZSAgICAgICAgICAgICAgICAkSE9TVDEgICAg ICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAgLS1zb3VyY2UtcG9ydCAgICAg ICAgICAgJEhPU1QxX0dBTUVfUE9SVCAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0t anVtcCAgICAgICAgICAgICAgICAgIE1BUksgICAgICAgICAgICAgICAgICAgICAgICBcDQogICAg ICAgICAgICAgICAgICAtLXNldC1tYXJrICAgICAgICAgICAgICAkR0FNRV9QQUNLRVQNCg0KICAg ICAgIyBGaXJld2FsbCBwYWNrZXQgbWFya2luZyBVRFAgZ2FtZSB0cmFmZmljIGZyb20gSG9zdDEN Cg0KICAgICAgJElQVEFCTEVTICAgLS10YWJsZSAgICAgICAgICAgICAgICAgbWFuZ2xlICAgICAg ICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tYXBwZW5kICAgICAgICAgICAg ICAgIFBSRVJPVVRJTkcgICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAtLXBy b3RvY29sICAgICAgICAgICAgICBVRFAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KICAgICAg ICAgICAgICAgICAgLS1pbi1pbnRlcmZhY2UgICAgICAgICAgJExBTl9JTlRFUkZBQ0UgICAgICAg ICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tc291cmNlICAgICAgICAgICAgICAgICRIT1NU MSAgICAgICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAtLXNvdXJjZS1wb3J0 ICAgICAgICAgICAkSE9TVDFfR0FNRV9QT1JUICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAg ICAgLS1qdW1wICAgICAgICAgICAgICAgICAgTUFSSyAgICAgICAgICAgICAgICAgICAgICAgIFwN CiAgICAgICAgICAgICAgICAgIC0tc2V0LW1hcmsgICAgICAgICAgICAgICRHQU1FX1BBQ0tFVA0K DQogICAgICAjIEZpcmV3YWxsIHBhY2tldCBtYXJraW5nIFRDUCBnYW1lIHRyYWZmaWMgdG8gSG9z dDENCg0KICAgICAgJElQVEFCTEVTICAgLS10YWJsZSAgICAgICAgICAgICAgICAgbWFuZ2xlICAg ICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tYXBwZW5kICAgICAgICAg ICAgICAgIFBSRVJPVVRJTkcgICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAt LXByb3RvY29sICAgICAgICAgICAgICBUQ1AgICAgICAgICAgICAgICAgICAgICAgICAgXA0KICAg ICAgICAgICAgICAgICAgLS1pbi1pbnRlcmZhY2UgICAgICAgICAgJElOVEVSTkVUX0lOVEVSRkFD RSAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tZGVzdGluYXRpb24gICAgICAgICAgICRI T1NUMSAgICAgICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAtLWRlc3RpbmF0 aW9uLXBvcnQgICAgICAkSE9TVDFfR0FNRV9QT1JUICAgICAgICAgICAgXA0KICAgICAgICAgICAg ICAgICAgLS1qdW1wICAgICAgICAgICAgICAgICAgTUFSSyAgICAgICAgICAgICAgICAgICAgICAg IFwNCiAgICAgICAgICAgICAgICAgIC0tc2V0LW1hcmsgICAgICAgICAgICAgICRHQU1FX1BBQ0tF VA0KDQogICAgICAjIEZpcmV3YWxsIHBhY2tldCBtYXJraW5nIFVEUCBnYW1lIHRyYWZmaWMgdG8g SG9zdDENCg0KICAgICAgJElQVEFCTEVTICAgLS10YWJsZSAgICAgICAgICAgICAgICAgbWFuZ2xl ICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tYXBwZW5kICAgICAg ICAgICAgICAgIFBSRVJPVVRJTkcgICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAg ICAtLXByb3RvY29sICAgICAgICAgICAgICBVRFAgICAgICAgICAgICAgICAgICAgICAgICAgXA0K ICAgICAgICAgICAgICAgICAgLS1pbi1pbnRlcmZhY2UgICAgICAgICAgJElOVEVSTkVUX0lOVEVS RkFDRSAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tZGVzdGluYXRpb24gICAgICAgICAg ICRIT1NUMSAgICAgICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAtLWRlc3Rp bmF0aW9uLXBvcnQgICAgICAkSE9TVDFfR0FNRV9QT1JUICAgICAgICAgICAgXA0KICAgICAgICAg ICAgICAgICAgLS1qdW1wICAgICAgICAgICAgICAgICAgTUFSSyAgICAgICAgICAgICAgICAgICAg ICAgIFwNCiAgICAgICAgICAgICAgICAgIC0tc2V0LW1hcmsgICAgICAgICAgICAgICRHQU1FX1BB Q0tFVA0KDQogICAgICAjICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KICAgICAgIyBQb2xpY3kgUm91dGluZyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiAgICAgICMgKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoN CiAgICAgICMgRGVsZXRlIGFueSBleGlzdGluZyAvIG9sZCBydWxlcy4NCg0KICAgICAgJElQIHJ1 bGUgZGVsIHByaW9yaXR5IDQwMDAgMj4gL2Rldi9udWxsDQoNCiAgICAgICRJUCBydWxlIGRlbCBw cmlvcml0eSA1MDAwIDI+IC9kZXYvbnVsbA0KDQogICAgICAjIEZsdXNoIHRoZSBhbHRlcm5hdGUg cm91dGluZyB0YWJsZSBhbmQgcm91dGluZyBjYWNoZQ0KDQogICAgICAkSVAgcm91dGUgZmx1c2gg dGFibGUgU21hbGxfTVRVIDI+IC9kZXYvbnVsbA0KDQogICAgICAkSVAgcm91dGUgZmx1c2ggY2Fj aGUNCg0KICAgICAgIyBEdXBsaWNhdGUgdGhlIG5vcm1hbCByb3V0aW5nIHRhYmxlIGV4Y2VwdCBs b3dlciB0aGUgTVRVIG9mIHRoZQ0KICAgICAgIyBkZWZhdWx0IHJvdXRlLg0KDQogICAgICAkSVAg cm91dGUgYWRkICRMT0NBTEhPU1RfSVAgZGV2IGxvIHRhYmxlIFNtYWxsX01UVQ0KDQogICAgICAk SVAgcm91dGUgYWRkICRMQU5fSVBfUkFOR0UgZGV2ICRMQU5fSU5URVJGQUNFIHNyYyAkTEFOX0lQ ICAgICAgXA0KICAgICAgICAgICB0YWJsZSBTbWFsbF9NVFUgcHJvdG8gc3RhdGljDQoNCiAgICAg ICRJUCByb3V0ZSBhZGQgJElOVEVSTkVUX0lQX1JBTkdFIGRldiAkSU5URVJORVRfSU5URVJGQUNF ICAgICAgICBcDQogICAgICAgICAgIHNyYyAkSU5URVJORVRfSVAgdGFibGUgU21hbGxfTVRVIHBy b3RvIHN0YXRpYw0KDQogICAgICAkSVAgcm91dGUgYWRkIGRlZmF1bHQgdmlhICRJTlRFUk5FVF9H QVRFV0FZIG10dSAkVENfTVRVICAgICAgICAgXA0KICAgICAgICAgICBhZHZtc3MgJFRDX01TUyB0 YWJsZSBTbWFsbF9NVFUgcHJvdG8gc3RhdGljDQoNCiAgICAgICMgR2FtZSB0cmFmZmljIGNvbnRp bnVlcyB0byBnbyB0byB0aGUgbWFpbiByb3V0aW5nIHRhYmxlIHdpdGgNCiAgICAgICMgc28gdGhh dCBpdCBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2YgbGFyZ2VyIHVwbGluayBwYWNrZXQgc2l6ZXMuDQoN CiAgICAgICRJUCBydWxlIGFkZCBmd21hcmsgJEdBTUVfUEFDS0VUIHByaW9yaXR5IDQwMDAgdGFi bGUgbWFpbg0KDQogICAgICAjIE5vdyBzdGFydCByZWZlcnJpbmcgbm9uLWdhbWUgdHJhZmZpYyB0 byB0aGUgbmV3IHJvdXRpbmcgdGFibGUNCg0KICAgICAgJElQIHJ1bGUgYWRkIGZyb20gMC8wIHBy aW9yaXR5IDUwMDAgdGFibGUgU21hbGxfTVRVDQoNCiAgICAgICRJUCByb3V0ZSBmbHVzaCBjYWNo ZQ0KDQogICAgICAjICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KICAgICAgIyBVcGxpbmsgVHJhZmZpYyBDb250cm9sICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoNCiAgICAgICMgKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCiAg ICAgICMgRWdyZXNzIGJhbmR3aWR0aCBzaGFwaW5nIGFuZCBzY2hlZHVsaW5nIGFyZSBwZXJmb3Jt ZWQgdG8gZW5zdXJlDQogICAgICAjIHRoYXQgcGFja2V0cyBhcmUgbmV2ZXIgcXVldWVkIGluIHRo ZSBBRFNMIG1vZGVtLCBhbmQgdGhhdCBnYW1lDQogICAgICAjIHBhY2tldHMsIGlmIHByZXNlbnQs IHRha2UgcHJpb3JpdHkgb3ZlciBhbGwgb3RoZXIgdHJhZmZpYy4NCg0KICAgICAgIyBGaXJzdCBk ZWxldGUgYW55IHByZXZpb3VzIHRyYWZmaWMgY29udHJvbCBydWxlcw0KDQogICAgICAkVEMgcWRp c2MgZGVsIGRldiAkSU5FVF9JRkFDRSByb290IDI+IC9kZXYvbnVsbA0KICAgICAgJFRDIHFkaXNj IGRlbCBkZXYgJElORVRfSUZBQ0UgaW5ncmVzcyAyPiAvZGV2L251bGwNCg0KICAgICAgIyBOb3cg ZXN0YWJsaXNoIHRoZSBIVEIgcm9vdCBkaXNjaXBsaW5lDQoNCiAgICAgICRUQyBxZGlzYyBhZGQg ZGV2ICRJTlRFUk5FVF9JTlRFUkZBQ0Ugcm9vdCBoYW5kbGUgMTowICAgICAgICAgICBcDQogICAg ICAgICAgIGh0YiBkZWZhdWx0IDExIHIycSAxDQoNCiAgICAgICMgTm93IGVzdGFibGlzaCB0aGUg cm9vdCBjbGFzcw0KDQogICAgICAkVEMgY2xhc3MgYWRkIGRldiAkSU5URVJORVRfSU5URVJGQUNF IHBhcmVudCAxOjAgY2xhc3NpZCAxOjEgICAgXA0KICAgICAgICAgICBodGIgcmF0ZSAkVENfVVBM SU5LX1JBVEUia2JpdCIgY2VpbCAkVENfVVBMSU5LX1JBVEUia2JpdCIgIFwNCiAgICAgICAgICAg YnVyc3QgNmsgY2J1cnN0IDZrDQoNCiAgICAgICMgQWRkIGxlYWYgY2xhc3MgZm9yIGdhbWUgdHJh ZmZpYw0KDQogICAgICAkVEMgY2xhc3MgYWRkIGRldiAkSU5URVJORVRfSU5URVJGQUNFIHBhcmVu dCAxOjEgY2xhc3NpZCAxOjEwICAgXA0KICAgICAgICAgICBodGIgcmF0ZSAkVENfR0FNRV9SQVRF ImtiaXQiIGNlaWwgJFRDX0dBTUVfQ0VJTCJrYml0IiAgICAgIFwNCiAgICAgICAgICAgcHJpbyAx IGJ1cnN0IDZrIGNidXJzdCA2aw0KDQogICAgICAjIEFkZCBsZWFmIGNsYXNzIGZvciBub24tZ2Ft ZSB0cmFmZmljLiAgTm90ZSB0aGF0IG5vbi1nYW1lDQogICAgICAjIHRyYWZmaWMgaXMgY2FwcGVk IGF0IGFib3V0IDY3JSBvZiB0aGUgYXZhaWxhYmxlIHVwbGluaw0KICAgICAgIyBiYW5kd2lkdGgs IGJvdGggZm9yIHJhdGUgYW5kIGNlaWxpbmcuICBUaGlzIHdhcyBkb25lDQogICAgICAjIHRvIGVu c3VyZSB0aGF0IHN1ZmZpY2llbnQgYmFuZHdpZHRoICh0b2tlbnMpIGlzIGFsd2F5cw0KICAgICAg IyBhdmFpbGFibGUgZm9yIGdhbWUgcGFja2V0cyB3aGVuIHRoZXkgYXJyaXZlLg0KDQogICAgICAk VEMgY2xhc3MgYWRkIGRldiAkSU5URVJORVRfSU5URVJGQUNFIHBhcmVudCAxOjEgY2xhc3NpZCAx OjExICAgXA0KICAgICAgICAgICBodGIgcmF0ZSAkVENfT1RIRVJfUkFURSJrYml0IiBjZWlsICRU Q19PVEhFUl9DRUlMImtiaXQiICAgIFwNCiAgICAgICAgICAgcHJpbyAyIG10dSAkVENfTVRVDQoN CiAgICAgICMgQWRkIGZpZm8gcXVldWVpbmcgZGlzY2lwbGluZSBmb3IgZ2FtZSB0cmFmZmljDQoN CiAgICAgICRUQyBxZGlzYyBhZGQgZGV2ICRJTlRFUk5FVF9JTlRFUkZBQ0UgcGFyZW50IDE6MTAg aGFuZGxlIDEwOiAgICBcDQogICAgICAgICAgIHBmaWZvIGxpbWl0IDI1DQoNCiAgICAgICMgQWRk IHByaW8gcXVldWVpbmcgZGlzY2lwbGluZSBmb3Igbm9uLWdhbWUgdHJhZmZpYyB0byBwcm92aWRl DQogICAgICAjIHN0YW5kYXJkIFRPUyBwcmlvcml0eSBxdWV1ZWluZy4NCg0KICAgICAgJFRDIHFk aXNjIGFkZCBkZXYgJElOVEVSTkVUX0lOVEVSRkFDRSBwYXJlbnQgMToxMSBoYW5kbGUgMTE6ICAg IFwNCiAgICAgICAgICAgcHJpbw0KDQogICAgICAjIEFkZCBzZnEgcXVldWVpbmcgZGlzY2lwbGlu ZSBmb3IgbWluaW1pemUtZGVsYXkgdHJhZmZpYw0KDQogICAgICAkVEMgcWRpc2MgYWRkIGRldiAk SU5URVJORVRfSU5URVJGQUNFIHBhcmVudCAxMToxIGhhbmRsZSAxMTE6ICAgXA0KICAgICAgICAg ICBzZnEgcGVydHVyYiA1DQoNCiAgICAgICMgQWRkIHNmcSBxdWV1ZWluZyBkaXNjaXBsaW5lIGZv ciBiZXN0LWVmZm9ydCB0cmFmZmljDQoNCiAgICAgICRUQyBxZGlzYyBhZGQgZGV2ICRJTlRFUk5F VF9JTlRFUkZBQ0UgcGFyZW50IDExOjIgaGFuZGxlIDExMjogICBcDQogICAgICAgICAgIHNmcSBw ZXJ0dXJiIDUNCg0KICAgICAgIyBBZGQgc2ZxIHF1ZXVlaW5nIGRpc2NpcGxpbmUgZm9yIG1heGlt aXplLXRocm91Z2hwdXQgdHJhZmZpYw0KDQogICAgICAkVEMgcWRpc2MgYWRkIGRldiAkSU5URVJO RVRfSU5URVJGQUNFIHBhcmVudCAxMTozIGhhbmRsZSAxMTM6ICAgXA0KICAgICAgICAgICBzZnEg cGVydHVyYiA1DQoNCiAgICAgICMgTm93IGZpbHRlciBnYW1lIHRyYWZmaWMgdG8gbGVhZiAxOjEw IGFzIGZpcnN0IHByaW9yaXR5DQoNCiAgICAgICRUQyBmaWx0ZXIgYWRkIGRldiAkSU5URVJORVRf SU5URVJGQUNFIHBhcmVudCAxOjAgICAgICAgICAgICAgICBcDQogICAgICAgICAgIHByb3RvY29s IGlwIHByaW8gMSBoYW5kbGUgJEdBTUVfUEFDS0VUIGZ3IGZsb3dpZCAxOjEwDQoNCiAgICAgICMg RW1wdHkgYWNrIHBhY2tldHMgYXJlIGFzc2lnbmVkIGRpcmVjdGx5IHRvIHRoZSBtaW5pbWl6ZS0N CiAgICAgICMgZGVsYXkgcXVldWUuDQoNCiAgICAgICRUQyBmaWx0ZXIgYWRkIGRldiAkSU5URVJO RVRfSU5URVJGQUNFIHBhcmVudCAxMTowIHByb3RvY29sIGlwIFwNCiAgICAgICAgICAgcHJpbyAz IHUzMiBtYXRjaCBpcCBwcm90b2NvbCA2IDB4ZmYgICAgICAgICAgICAgICAgICAgICAgIFwNCiAg ICAgICAgICAgbWF0Y2ggdTggMHgwNSAweDBmIGF0IDAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFwNCiAgICAgICAgICAgbWF0Y2ggdTE2IDB4MDAwMCAweGZmYzAgYXQgMiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgbWF0Y2ggdTggMHgxMCAweGZm IGF0IDMzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgZmxv d2lkIDExOjENCg0KICAgICAgIyBUaGUgcmVtYWluaW5nIHRyYWZmaWMgZGVmYXVsdHMgdG8gaHRi IGxlYWYgMToxMQ0KDQogICAgICAjICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgICAjIERvd25saW5rIFRyYWZmaWMgQ29u dHJvbCAoSW5ncmVzcyBQb2xpY2luZykgICAgICAgICAgICAgICAgICAqDQogICAgICAjICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQoNCiAgICAgICMgRG93bmxpbmsgdHJhZmZpYyBpcyBsaW1pdGVkIHRvIGFib3V0IDg1JSBvZiBh Y3R1YWwgZG93bmxpbmsNCiAgICAgICMgY2FwYWJpbGl0eSB0byBwcmV2ZW50IHVwc3RyZWFtIHF1 ZXVlaW5nLg0KDQogICAgICAjIEZpcnN0IGVzdGFibGlzaCBhbiBpbmdyZXNzIHFkaXNjDQoNCiAg ICAgICRUQyBxZGlzYyBhZGQgZGV2ICRJTlRFUk5FVF9JTlRFUkZBQ0UgaGFuZGxlIGZmZmY6IGlu Z3Jlc3MNCg0KICAgICAgIyBJbmNvbWluZyBnYW1lIHRyYWZmaWMgaXMgbm90IHBvbGljZWQNCg0K ICAgICAgJFRDIGZpbHRlciBhZGQgZGV2ICRJTlRFUk5FVF9JTlRFUkZBQ0UgcGFyZW50IGZmZmY6 ICAgICAgICAgICAgXA0KICAgICAgICAgICBwcm90b2NvbCBpcCBwcmlvIDEgaGFuZGxlICRHQU1F X1BBQ0tFVCBmdyBmbG93aWQgOjENCg0KICAgICAgIyBGaWx0ZXIgZXZlcnl0aGluZyBlbHNlIHRv IHRoYXQgcWRpc2MgYW5kIGRyb3AgcGFja2V0cw0KICAgICAgIyB0aGF0IGV4Y2VlZCB0aGUgYmFu ZHdpZHRoIGxpbWl0DQoNCiAgICAgICRUQyBmaWx0ZXIgYWRkIGRldiAkSU5URVJORVRfSU5URVJG QUNFIHBhcmVudCBmZmZmOiAgICAgICAgICAgIFwNCiAgICAgICAgICAgcHJvdG9jb2wgaXAgcHJp byAzIHUzMiBtYXRjaCBpcCBzcmMgMC4wLjAuMC8wICAgICAgICAgICAgIFwNCiAgICAgICAgICAg cG9saWNlIHJhdGUgJFRDX0RPV05MSU5LX1JBVEUia2JpdCIgYnVyc3QgM2sgZHJvcCAgICAgICAg IFwNCiAgICAgICAgICAgZmxvd2lkIDoxDQogICAgICA7Ow0KICBzdG9wKQ0KICAgICAgIyBSZW1v dmUgYW55IHVwbGluayB0aHJvdHRsaW5nDQoNCiAgICAgICRUQyBxZGlzYyBkZWwgZGV2ICRJTlRF Uk5FVF9JTlRFUkZBQ0Ugcm9vdCAyPiAvZGV2L251bGwNCiAgICAgICRUQyBxZGlzYyBkZWwgZGV2 ICRJTlRFUk5FVF9JTlRFUkZBQ0UgaW5ncmVzcyAyPiAvZGV2L251bGwNCg0KICAgICAgIyBSZW1v dmUgcG9saWN5IHJvdXRpbmcNCg0KICAgICAgJElQIHJ1bGUgZGVsIHByaW9yaXR5IDUwMDAgMj4g L2Rldi9udWxsDQogICAgICAkSVAgcnVsZSBkZWwgcHJpb3JpdHkgNDAwMCAyPiAvZGV2L251bGwN CiAgICAgICRJUCByb3V0ZSBmbHVzaCB0YWJsZSBTbWFsbF9NVFUgMj4gL2Rldi9udWxsDQogICAg ICAkSVAgcm91dGUgZmx1c2ggY2FjaGUNCiAgICAgIDs7DQogIHJlc3RhcnQpDQogICAgICAkMCBz dG9wDQogICAgICBzbGVlcCAzDQogICAgICAkMCBzdGFydA0KICAgICAgOzsNCiAgKikNCiAgICAg IGVjaG8gIlVzYWdlOiAuLyQwIHN0YXJ0fHN0b3B8cmVzdGFydH0iDQogICAgICBleGl0IDENCmVz YWMNCg0KZXhpdCAwDQoNCg0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogMg0KRnJvbTogIkdl b3JnZSBKLiBKYWhjaGFuIiA8TEFSVENAVGVjaC5JbnRlcmFjdGl2ZU5ldHdvcmtzLm5ldD4NClRv OiAiTGludXggQWR2YW5jZWQgUm91dGluZyAmIFRyYWZmaWMgQ29udHJvbCIgPGxhcnRjQG1haWxt YW4uZHM5YS5ubD4NCkRhdGU6IFRodSwgMjIgQXVnIDIwMDIgMTA6MDA6NTQgKzAzMDANClN1Ympl Y3Q6IFtMQVJUQ10gSXMgVEMgZmxvdy1hd2FyZT8NCg0KSXMgVEMgZmxvdy1hd2FyZSBmb3IgaW5k aXZpZHVhbCBmbG93cyAoc2Vzc2lvbnMpIHdpdGhpbiBhIGdpdmVuIGNsYXNzIG9mDQp0cmFmZmlj Pw0KDQpGb3IgZXhhbXBsZSwgYXNzdW1pbmcgMTAwS2JwcyBhbGxvY2F0ZWQgdG8gYSBjbGFzcyBh bmQgMTAwIHNpbXVsdGFuZW91cw0KYWN0aXZlIGZsb3dzIHdpdGhpbiB0aGF0IGNsYXNzLiBXaWxs IGVhY2ggZmxvdyBnZXQgYXBwcm94LiAxSywgb3IgIHdpbGwgdGhlDQpncmVlZGllcg0KZmxvd3Mg Y2FwdHVyZSB0aGUgbGlvbidzIHNoYXJlIG9mIHRoZSAxMDBLLCBsZWF2aW5nIHRoZSBvdGhlcnMg c3RydWdnbGluZyB0bw0KZ28NCnRocm91Z2g/DQoNCkNvbnZlcnNlbHksIHdoZW4gYSBxdWV1ZSBm aWxscyB1cCBhbmQgcGFja2V0cyBmcm9tIHRoYXQgcXVldWUgbXVzdCBiZSBkcm9wLQ0KcGVkLCB3 aWxsIFRDIGRyb3AgcGFja2V0cyBmcm9tIHRoZSBncmVlZGllciBmbG93cyAodGhhdCBhcmUgbW9z dCBsaWtlbHkNCmNhdXNpbmcNCnRoZSBjb25nZXN0aW9uKSBvciBkb2VzIGl0IG5vdCBkaXN0aW5n dWlzaCBiZXR3ZWVuIGZsb3dzPyBJbiB0aGUgbGF0dGVyDQpjYXNlLA0Kd2hpY2ggcnVsZXMgZGV0 ZXJtaW5lIHRoZSBwYWNrZXRzIHRoYXQgZ2V0IGRyb3BwZWQ/DQoNCg0KLS1fXy0tX18tLQ0KDQpN ZXNzYWdlOiAzDQpEYXRlOiBUaHUsIDIyIEF1ZyAyMDAyIDAyOjA2OjAyIC0wNTAwIChDRFQpDQpG cm9tOiBBbWl0IEt1Y2hlcmlhIDxhbWl0a0BpdHRjLmt1LmVkdT4NClRvOiAiR2VvcmdlIEouIEph aGNoYW4iIDxMQVJUQ0BUZWNoLkludGVyYWN0aXZlTmV0d29ya3MubmV0Pg0KQ2M6IExpbnV4IEFk dmFuY2VkIFJvdXRpbmcgJiBUcmFmZmljIENvbnRyb2wgPGxhcnRjQG1haWxtYW4uZHM5YS5ubD4N ClN1YmplY3Q6IFJlOiBbTEFSVENdIElzIFRDIGZsb3ctYXdhcmU/DQoNCk9uIFRodSwgMjIgQXVn IDIwMDIsIEdlb3JnZSBKLiBKYWhjaGFuIHdyb3RlOg0KDQo+IElzIFRDIGZsb3ctYXdhcmUgZm9y IGluZGl2aWR1YWwgZmxvd3MgKHNlc3Npb25zKSB3aXRoaW4gYSBnaXZlbiBjbGFzcyBvZg0KPiB0 cmFmZmljPw0KDQpObywgVEMgaXNudCBmbG93LWF3YXJlLiBJZiBhbGwgdGhlIGZsb3dzIGZhbGwg aW50byB0aGUgc2FtZSBjbGFzcywNCnBhY2tldHMgd2lsbCBiZSBkcm9wcGVkIG9uIGEgIm5lZWQt dG8tZHJvcCIgYmFzaXMuIEFsc28gdGhlIGdyZWVkeSBmbG93IA0Kd2lsbCBiZSBhYmxlIHRvIGhv ZyBiYW5kd2lkdGggdW5sZXNzIGl0IGlzIHBvbGljZWQgYXQgdGhlIGVkZ2Ugb2YgdGhlIA0KdHJh ZmZpYyBjb250cm9sIG5ldHdvcmsuDQoNCkJ1dCB5b3UgY291bGQgdXNlIHNvbWV0aGluZyBsaWtl IERpZmZzZXJ2IHdoaWNoIGhhcyB2YXJpb3VzIGRyb3AgDQpwcm9iYWJpbGl0aWVzIGFuZCB0aHVz IGNvbnRyb2wgd2hpY2ggZmxvd3MgaGF2ZSBtb3JlIGRyb3AgcHJvYmFiaWxpdHkuDQoNCi1BbWl0 DQotLSANCkknbSBhbiBhbmdlbCEhISBIb25lc3QhDQpUaGUgaG9ybnMgYXJlIGp1c3QgdGhlcmUg dG8gaG9sZCB0aGUgaGFsbyB1cCBzdHJhaWdodC4NCl4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4t Xi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eDQogICAgICAgICAgICAgICAgICBBbWl0IEt1Y2hl cmlhDQogICAgICAgICAgRUVDUyBHcmFkLiBSZXNlYXJjaCBBc3Npc3RhbnQNCiAgICAgICAgIFVu aXZlcnNpdHkgb2YgS2Fuc2FzIEAgTGF3cmVuY2UNCiAgIChSKTogKzEtNzg1LTgzMC04NTIxIHx8 fCAoQyk6ICsxLTc4NS03NjAtMjg3MQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogNA0KRGF0ZTog VGh1LCAyMiBBdWcgMjAwMiAwMjowNzo1NSAtMDUwMCAoQ0RUKQ0KRnJvbTogQW1pdCBLdWNoZXJp YSA8YW1pdGtAaXR0Yy5rdS5lZHU+DQpUbzogb3lzdGVsb2tAdW5pay5ubw0KQ2M6IGRldmlrQGNk aS5jeiwgPGxhcnRjQG1haWxtYW4uZHM5YS5ubD4NClN1YmplY3Q6IFtMQVJUQ10gSFRCICYgR1JF RA0KDQpXaXRoIHJlZmVyZW5jZSB0byB0aGUgZm9sbG93aW5nIHBvc3Q6DQoNCmh0dHA6Ly9tYWls bWFuLmRzOWEubmwvcGlwZXJtYWlsL2xhcnRjLzIwMDJxMS8wMDI0MTAuaHRtbA0KDQpXYXMgYW55 Ym9keSBhYmxlIHRvIGNyZWF0ZSBHUkVEIHZpcnR1YWwgcXVldWVzIGluc2lkZSBIVEI/DQoNClJl Z2FyZHMsDQpBbWl0DQotLSANCkknbSBhbiBhbmdlbCEhISBIb25lc3QhDQpUaGUgaG9ybnMgYXJl IGp1c3QgdGhlcmUgdG8gaG9sZCB0aGUgaGFsbyB1cCBzdHJhaWdodC4NCl4tXi1eLV4tXi1eLV4t Xi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eLV4tXi1eDQogICAgICAgICAgICAgICAg ICBBbWl0IEt1Y2hlcmlhDQogICAgICAgICAgRUVDUyBHcmFkLiBSZXNlYXJjaCBBc3Npc3RhbnQN CiAgICAgICAgIFVuaXZlcnNpdHkgb2YgS2Fuc2FzIEAgTGF3cmVuY2UNCiAgIChSKTogKzEtNzg1 LTgzMC04NTIxIHx8fCAoQyk6ICsxLTc4NS03NjAtMjg3MQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCi0tX18tLV9fLS0NCg0KTWVzc2Fn ZTogNQ0KRGF0ZTogVGh1LCAyMiBBdWcgMjAwMiAwOTozODo1OCArMDIwMA0KRnJvbTogS2FybCBH YWlzc21haWVyIDxrYXJsLmdhaXNzbWFpZXJAcnoudW5pLXVsbS5kZT4NCk9yZ2FuaXphdGlvbjog PT9pc28tODg1OS0xP1E/VW5pdmVyc2l0PUU0dD89IFVsbQ0KVG86IExpbnV4IEFkdmFuY2VkIFJv dXRpbmcgJiBUcmFmZmljIENvbnRyb2wgPGxhcnRjQG1haWxtYW4uZHM5YS5ubD4NClN1YmplY3Q6 IFtMQVJUQ10gUTogYmVzdCBzb2x1dGlvbiB0byBzdG9wIHRyYWZmaWMgdG8gaHVnZSBhbW91bnQg b2YgdW5yZWdpc3RlcmVkIGhvc3RzDQoNCkhpDQoNCnBlcmhhcHMgc29tZW9uZSBlbHNlIGFscmVh ZHkgaGFkIHRoZSBzYW1lIHByb2JsZW0uDQoNClByb2JsZW0gZGVzY3JpcHRpb246DQoNCkknbSBy dW5uaW5nIGEgY2xhc3MgQiBVbml2ZXJzaXR5IG5ldHdvcmsgd2l0aCBhcHByb3ggMTBrIGhvc3Rz DQphdHRhY2hlZC4gSSB3b3VsZCBub3cgbGlrZSB0byBzdG9wIHRyYWZmaWMgZnJvbSBhbmQgdG8g aG9zdHMNCmluIG15IG5ldHdvcmsgbm90IGFscmVhZHkgcmVnaXN0ZXJlZCBpbiBteSBETlMgc2Vy dmVyLg0KDQpUaGlzIG1lYW5zIEkndmUgdG8gaGFuZGxlIHdpdGggYXBwcm94IDUwayBydWxlc3xy b3V0ZXMuIFN1cmUNCkkgY2FuIHN1bW1hcml6ZSB0aGUgdW5hbGxvY3RhZWQgYWRkcmVzcyBzcGFj ZSBhIGxpdHRsZSBiaXQNCndpdGggbWFza3MgdG8gYXBwcm94IDMwayBydWxlcywgYW55d2F5IHRo aXMgc2VlbXMgdG8gYmUgYSBwcm9ibGVtLg0KDQpRdWVzdGlvbjoNCg0KV2hhdCB3aWxsIGJlIHRo ZSBiZXN0IHNvbHV0aW9uIGJldHdlZW4gdGhlIGRpZmZlcmVudCBjaG9pY2VzDQpuZXRmaWx0ZXIv aXB0YWJsZXMsIGlwIHJvdXRlKHMpIC4uLiB0eXBlIHByb2hpYml0IGFuZA0KdGMgZmlsdGVyIC4u LiB1MzIgLi4uIHBvbGljZSAwa2Jwcw0KDQpuZXRmaWx0ZXIvaXB0YWJsZXMgZG9lc24ndCBzZWVt IHRvIHNjYWxlIHdlbGwgYW5kIHRoZSBvbmx5DQptYXRjaCBtb2R1bGUgInBvb2wiIHdoaWNoIGlz IGFibGUgdG8gZGVhbCB3aXRoIHBvb2xzIG9mIGFkZHJlc3Nlcw0Kc2VlbWVzIHRvIHN0YXkgaW4g YWxwaGEgc3RhdGUuDQoNCg0KV2l0aCBpcCByb3V0ZSBJIHRoaW5rIEkgaGF2ZSB0byBkZXNjcmli ZSBhbGwgdW5yZWdpc3RlcmVkIGhvc3RzDQp0byBzdG9wIHRyYWZmaWMgYW5kIG5vdCB0aGUgc21h bGxlciBhbW91bnQgb2YgcmVnaXN0ZXJlZCBob3N0cy4NCkRvZXMgdGhlIEZJQiBhbmQgcm91dGUg Y2FjaGUgc2NhbGUgd2VsbCB0byBhcHByb3ggMzBrIHJvdXRlcz8NCg0KSXMgaXQgcG9zc2libGUg YW5kIG1vcmUgcGVyZm9ybWFudCB0byB1c2UgdGMgdG8gdGhyb3R0bGUgZG93bg0KdHJhZmZpYyB0 byB1bnJlZ2lzdGVyZWQgaG9zdHMgYWxyZWFkeSBpbiB0aGUgaW5ncmVzcyBsYW5lDQp3aXRob3V0 IGhpdHRpbmcgdGhlIHJvdXRpbmcgYW5kIG5ldGZpbHRlciBlbmdpbmUgd2l0aCB0aGlzDQp0cmFm ZmljPyBEb2VzIHRjIHNjYWxlIHdlbGwgd2l0aCB0aGlzIGh1Z2UgYW1vdW50IGFkZHJlc3Nlcy9t YXNrcz8NCg0KSG93IGNvdWxkIHRoaXMgYmUgaGFuZGxlZCB3aXRoIHRjPw0KDQpSZWdhcmRzIGFu ZCB0aGFua3MgaW4gYWR2YW5jZSBmb3IgYW55IGhpbnQNCglDaGFybHkNCg0KUC5TLiBTcGVlZCBp cyBpbXBvcnRhbnQsIHRoaXMgbGludXggcm91dGVyL2ZpcmV3YWxsIGNvbm5lY3RzDQpHaWdhYml0 IEV0aGVybmV0IG5ldHdvcmtzDQoNCi0tIA0KS2FybCBHYWlzc21haWVyICAgICAgICAgIENvbXB1 dGluZyBDZW50ZXIsVW5pdmVyc2l0eSBvZiBVbG0sR2VybWFueQ0KRW1haWw6a2FybC5nYWlzc21h aWVyQHJ6LnVuaS11bG0uZGUgICAgICAgICAgTmV0d29yayBBZG1pbmlzdHJhdGlvbg0KVGVsLjog Kys0OSA3MzEgNTAtMjI0OTkNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiA2DQpEYXRlOiBUaHUs IDIyIEF1ZyAyMDAyIDE2OjI5OjAxICswMjAwDQpGcm9tOiBNaWNoYWwgS3VzdG9zaWsgPGt1c3Rv c3pAdmViLnBsPg0KVG86IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KU3ViamVjdDogW0xBUlRDXSBo dGIgYW5kIHByaW9yaXR5IG9mIGJvcnJvd2luZyBiYW5kd2lkdGguLi4NCg0KSGVsbG8uLi4NCg0K SSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgaHRiLi4uDQpJcyBpdCBwb3NzaWJsZSB0byBzaGFyZSBi YW5kd2lkdGggd2l0aCBzb21lIHByb3BvcnRpb24/DQoNCkZvciBleGFtcGxlLCBJIGhhdmU6DQoN CnRjIHFkaXNjIGFkZCBkZXYgJElOVCByb290IGhhbmRsZSAxOiBodGIgZGVmYXVsdCAxMiAgDQp0 YyBjbGFzcyBhZGQgZGV2ICRJTlQgcGFyZW50IDE6IGNsYXNzaWQgMToxIGh0YiByYXRlIDMwMGti aXQgY2VpbCAzMDBrYml0DQp0YyBjbGFzcyBhZGQgZGV2ICRJTlQgcGFyZW50IDE6MSBjbGFzc2lk IDE6MTAgaHRiIHJhdGUgNTBrYml0IGNlaWwgMzAwa2JpdA0KdGMgY2xhc3MgYWRkIGRldiAkSU5U IHBhcmVudCAxOjEgY2xhc3NpZCAxOjExIGh0YiByYXRlIDUwa2JpdCBjZWlsIDMwMGtiaXQNCg0K YnV0IEkgd2FudGVkIGNsYXNzIDE6MTAgdG8gYm9ycm93IGZpdmUgdGltZXMgYmlnZ2VyIGJhbmR3 aWR0aCB0aGFuIDE6MTEuDQpJcyBpdCBwb3NzaWJsZSB3aXRoIGh0YiA/Pz8NCg0KDQpHcmVldGlu Z3MuLi4NCi9rdXN0b3N6DQoNCg0KLS1fXy0tX18tLQ0KDQpNZXNzYWdlOiA3DQpEYXRlOiBUaHUs IDIyIEF1ZyAyMDAyIDIyOjQ0OjA3ICswMjAwDQpGcm9tOiBLYXJsIEdhaXNzbWFpZXIgPGthcmwu Z2Fpc3NtYWllckByei51bmktdWxtLmRlPg0KVG86IGxhcnRjQG1haWxtYW4uZHM5YS5ubA0KU3Vi amVjdDogUmU6IFtMQVJUQ10gUTogYmVzdCBzb2x1dGlvbiB0byBzdG9wIHRyYWZmaWMgdG8gaHVn ZSBhbW91bnQgb2YgDQogdW5yZWdpc3RlcmVkIGhvc3RzDQoNCk1hcmlhbiBKYW5jYXIgc2Nocmll YjoNCj4gDQo+IE9uIFRodSwgMjIgQXVnIDIwMDIgMDk6Mzg6NTggKzAyMDANCj4gIkthcmwgR2Fp c3NtYWllciIgPGthcmwuZ2Fpc3NtYWllckByei51bmktdWxtLmRlPiB3cm90ZToNCj4gDQo+ID4g SSdtIHJ1bm5pbmcgYSBjbGFzcyBCIFVuaXZlcnNpdHkgbmV0d29yayB3aXRoIGFwcHJveCAxMGsg aG9zdHMNCj4gPiBhdHRhY2hlZC4gSSB3b3VsZCBub3cgbGlrZSB0byBzdG9wIHRyYWZmaWMgZnJv bSBhbmQgdG8gaG9zdHMNCj4gPiBpbiBteSBuZXR3b3JrIG5vdCBhbHJlYWR5IHJlZ2lzdGVyZWQg aW4gbXkgRE5TIHNlcnZlci4NCj4gPg0KPiA+IFRoaXMgbWVhbnMgSSd2ZSB0byBoYW5kbGUgd2l0 aCBhcHByb3ggNTBrIHJ1bGVzfHJvdXRlcy4gU3VyZQ0KPiA+IEkgY2FuIHN1bW1hcml6ZSB0aGUg dW5hbGxvY3RhZWQgYWRkcmVzcyBzcGFjZSBhIGxpdHRsZSBiaXQNCj4gPiB3aXRoIG1hc2tzIHRv IGFwcHJveCAzMGsgcnVsZXMsIGFueXdheSB0aGlzIHNlZW1zIHRvIGJlIGEgcHJvYmxlbS4NCj4g DQo+IENyZWF0ZSB0cmVlIHdpdGggZGVjcmVhc2luZyBuZXRtYXNrLCB5b3Ugd2lsbCBoYXZlIG1v cmUgcnVsZXMgaW4gdG90YWwNCj4gYnV0IHBhY2tldHMgd2lsbCBoYXZlIHRvIHRyYXZlbCB0aHJv dWdoIG9ubHkgZmV3IG9mIHRoZW0uDQoNClllcCwgSSB0aG91Z2h0IGFscmVhZHkgYWJvdXQgdGhp cy4gSWYgSSBzZXQgZGVjcmVhc2luZyBuZXRtYXNrcyBmcm9tIC8xNw0KdG8gLzMyIAlJIHdvdWxk IGVuZCB1cCB3aXRoIDJeMTYgY2hhaW5zIGJ1dCBhZnRlciAxNiBjb21wYXJpc29ucw0KSSB3b3Vs ZCBoYXZlIGEgbWF0Y2guIFRoaXMgd291bGQgYmUgdGhlIGV4dHJlbWUhDQoNCklmIEkgY3JlYXRl IDI1NiBkaWZmZXJlbnQgY2hhaW5zIGJhc2VkIG9uIGEgLzI0IG5ldG1hc2sNCnRoZW4gSSB3b3Vs ZCBoYXZlIGEgbWF0Y2ggYXQgbGVhc3QgYWZ0ZXIgMjU2ICsgMjU2ID0gNTEyDQpjb21wYXJpc29u cy4gVGhlIGZpcnN0IG1heCAyNTYgY29tcGFyaXNvbnMgc2VsZWN0IHRoZQ0KbmV4dCBjaGFpbiBh bmQgdGhlIGxhc3QgbWF4IDI1NiBjb21wYXJpc29ucyBzZWxlY3QgdGhlDQovMzIgYWRkcmVzcyBp biB0aGlzIHNwZWNpYWwgY2hhaW4uDQoNCkFueXdheSBJIGZpbmQgdGhpcyB1Z2x5IHdpdGggaXB0 YWJsZXMgdGhhdCB3ZSBoYXZlIG5vDQpNQUREUiBtYXRjaCAoaW4gYW5hbG9neSB0byBNUE9SVCku IElmIHlvdSBidWlsZCBhIGZpcmV3YWxsDQp5b3UgdHJ5IGFsd2F5cyB0byBidWlsZCBncm91cHMg b2Ygc2VydmljZXMgKG1wb3J0KSBhbmQNCmdyb3VwcyBvZiBzZXJ2ZXJzL2NsaWVudHMgKG1hZGRy KS4gV2l0aCBpcHRhYmxlcyB5b3UgaGF2ZQ0KdG8gcmVwbHkgdGhlIHNhbWUgcnVsZSBuIHRpbWVz IGZvciBuIHNpbWlsYXIgc2VydmVycy9jbGllbnRzLg0KDQpUaGlzIGlzIHVnbHkgYW5kIGEgcGVy Zm9ybWFuY2UgYm90dGxlbmVjayBiZWNhdXNlIHRoZXNlDQpzaW1pbGFyIHJ1bGVzIGFyZSBjaGVj aGVkIHNlcXVlbnRpYWxseS4NCg0KQmVzdCByZWdhcmRzIGFuZCB0aGFua3MgZm9yIHlvdXIgdGlw Lg0KDQoJQ2hhcmx5DQoNCi0tIA0KS2FybCBHYWlzc21haWVyICAgICAgICAgIENvbXB1dGluZyBD ZW50ZXIsVW5pdmVyc2l0eSBvZiBVbG0sR2VybWFueQ0KRW1haWw6a2FybC5nYWlzc21haWVyQHJ6 LnVuaS11bG0uZGUgICAgICAgICAgTmV0d29yayBBZG1pbmlzdHJhdGlvbg0KDQotLV9fLS1fXy0t DQoNCk1lc3NhZ2U6IDgNCkRhdGU6IFRodSwgMjIgQXVnIDIwMDIgMjI6NTU6NTcgKzAyMDANCkZy b206IEthcmwgR2Fpc3NtYWllciA8a2FybC5nYWlzc21haWVyQHJ6LnVuaS11bG0uZGU+DQpUbzog TGludXggQWR2YW5jZWQgUm91dGluZyAmIFRyYWZmaWMgQ29udHJvbCA8bGFydGNAbWFpbG1hbi5k czlhLm5sPg0KU3ViamVjdDogUmU6IFtMQVJUQ10gUTogYmVzdCBzb2x1dGlvbiB0byBzdG9wIHRy YWZmaWMgdG8gaHVnZSBhbW91bnQgb2YgDQogdW5yZWdpc3RlcmVkIGhvc3RzDQoNClJvYmVydCBD b2xsaWVyIHNjaHJpZWI6DQo+IA0KPiBIaSBLYXJsLA0KPiANCj4gSSBkb24ndCBoYXZlIGFueSBz dWdnZXN0aW9ucyBmb3IgYW4gZWFzeSB3YXkgdG8gc29sdmUgeW91ciBwcm9ibGVtIC0NCj4gYnV0 Og0KPiANCj4gT24gVGh1LCBBdWcgMjIsIDIwMDIgYXQgMDk6Mzg6NThBTSArMDIwMCwgS2FybCBH YWlzc21haWVyIHdyb3RlOg0KPiA+IFdpdGggaXAgcm91dGUgSSB0aGluayBJIGhhdmUgdG8gZGVz Y3JpYmUgYWxsIHVucmVnaXN0ZXJlZCBob3N0cw0KPiA+IHRvIHN0b3AgdHJhZmZpYyBhbmQgbm90 IHRoZSBzbWFsbGVyIGFtb3VudCBvZiByZWdpc3RlcmVkIGhvc3RzLg0KPiA+IERvZXMgdGhlIEZJ QiBhbmQgcm91dGUgY2FjaGUgc2NhbGUgd2VsbCB0byBhcHByb3ggMzBrIHJvdXRlcz8NCj4gDQo+ IFdpdGggJ2xhcmdlIHJvdXRpbmcgdGFibGVzJyBlbmFibGVkIHRoZSBrZXJuZWwgd29ya3MganVz dCBmaW5lIHdpdGggYQ0KPiBmdWxsIGludGVybmV0IHJvdXRpbmcgdGFibGUgb2YgMTE1LDAwMCBy b3V0ZXMgc28gYSBtZXJlIDMwLDAwMCBzaG91bGQNCj4gYmUgYSBkb2RkbGUuDQo+IA0KPiBZb3Vy IG1haW4gcHJvYmxlbSB3aWxsIGJlIGdldHRpbmcgdGhlIHJvdXRlcyBpbnRvIHRoZSBrZXJuZWwu DQoNClllcyB0aGlzIGlzIGEgcHJvYmxlbS4gSSB0cmllZCBmb3IgZnVuIHRvIGJ1aWxkIGEgNjRr IHJvdXRpbmcgdGFibGUNCndpdGg6DQppcCByb3V0ZSBhZGQgdHlwZSBwcm9oaWJpdCAxMC4wLmku ag0KKGk9MC4uMjU1OyBqPTAuLjI1NSkNCmFuZCB0aGlzIHRvb2sgbW9yZSB0aGFuIG9uZSBob3Vy IG9uIG15IGhvbWUgZGVza3RvcCAob2xkIHBlbnRpdW0gOTApDQp0byBmaWxsIHRoZSByb3V0aW5n IHRhYmxlLg0KRXZlbiBpZiBJIGtub3cgdGhhdCB0aGlzIGlzIHByZXR0eSBvbGQgc3R1ZmYgSSB3 YXMgYXN0b25pc2hlZCBvdmVyIHRoaXMNCnNsb3cgcHJvZ3Jlc3MuDQoNClRoZSBxdWVzdGlvbiB0 aGF0IGFyaXNlcyBpcyBub3cgZm9yIG1lLCBob3cgbG9uZyBkb2VzIGl0IHRha2UNCmZvciBhIGZ1 bGwgaW50ZXJuZXQgcm91dGluZyB0YWJsZSB0byBnZXQgc3luY2hyb25pemVkIGFmdGVyDQphIHJv dXRlIGZsdXNoIHdpdGggYSBsaW51eCByb3V0ZXI/DQoNCkFueXdheSwgeW91IHRvbGQgbWUgdGhh dCB0aGUga2VybmVsIHdvcmtzIGZpbmUgd2l0aCAxMTVrIHJvdXRlcw0KYnV0IGJlIGF3YXJlIEkg d2lsbCB1c2UgdGhpcyB3aXRoIEdpZ2FiaXQgSW50ZXJmYWNlcy4NCg0KV2hhdCBpcyB0aGUgYXZl cmFnZSBmb3J3YXJkaW5nIHRpbWUgaW4gbXMgZm9yIGEgcGFja2V0IHdpdGgNCjExNWsgcm91dGVz Pw0KDQpCZXN0IHJlZ2FyZHMgYW5kIHRoYW5rcyBmb3IgeW91ciBhbnN3ZXINCglDaGFybHkNCg0K LS0gDQpLYXJsIEdhaXNzbWFpZXIgICAgICAgICAgQ29tcHV0aW5nIENlbnRlcixVbml2ZXJzaXR5 IG9mIFVsbSxHZXJtYW55DQpFbWFpbDprYXJsLmdhaXNzbWFpZXJAcnoudW5pLXVsbS5kZSAgICAg ICAgICBOZXR3b3JrIEFkbWluaXN0cmF0aW9uDQoNCi0tX18tLV9fLS0NCg0KTWVzc2FnZTogOQ0K RGF0ZTogVGh1LCAyMiBBdWcgMjAwMiAyMzowNDo0NyArMDIwMA0KRnJvbTogS2FybCBHYWlzc21h aWVyIDxrYXJsLmdhaXNzbWFpZXJAcnoudW5pLXVsbS5kZT4NClRvOiBMaW51eCBBZHZhbmNlZCBS b3V0aW5nICYgVHJhZmZpYyBDb250cm9sIDxsYXJ0Y0BtYWlsbWFuLmRzOWEubmw+DQpTdWJqZWN0 OiBSZTogW0xBUlRDXSBROiBiZXN0IHNvbHV0aW9uIHRvIHN0b3AgdHJhZmZpYyB0byBodWdlIGFt b3VudCBvZiANCiB1bnJlZ2lzdGVyZWRob3N0cw0KDQpHZXJyeSBDcmVhZ2VyIE41SlhTIHNjaHJp ZWI6DQo+IA0KPiBUaGUgYW5zd2VycyBhcmUgbm90IG5lY2Vzc2FyaWx5IHByZXR0eS4NCj4gDQo+ IEkndmUgZG9uZSBhIHNpbWlsYXIgdGFzayB3aXRoIGEgSnVuaXBlciBNNSByb3V0ZXIuICBJdCB3 aWxsIGhhbmRsZSB1cCB0bw0KPiBhYm91dCAxODAsMDAwIHJ1bGVzIGF0IHdpcmUgc3BlZWQuICBC dXQgaXQgaXMgZXhwZW5zaXZlLg0KPiANCj4gSWYgeW91ciBzd2l0Y2hlcyB3ZXJlIGEgbGl0dGxl IG5ld2VyLCB3ZSBjb3VsZCB1c2UgODAyLjF4IHRvIGVuYWJsZSB0aGUNCj4gc3dpdGNoLXVzZSBj YXBhYmlsaXR5IGZsYWcgKDotKSBhbmQgc29sdmUgdGhlIHByb2JsZW0uDQoNCnlvdSBrbm93LCAx MGsgaG9zdHMgYXJlIG5ldmVyIGF0dGFjaGVkIHRvIGEgbmV0d29yayB3aXRoIGhvbW9nZW5vdXMN Cm5ldyBuZXR3b3JrIGRldmljZXMgOi0oDQoNCj4gDQo+IEluc3RlYWQgb2YgcG9saWNpbmcgYXQg YSBzaW5nbGUgZWRnZSBwb2ludCwgeW91IG1pZ2h0IGNvbnNpZGVyIHBvbGljaW5nDQo+IGF0IGRv cm1hdG9yeSBhbmQgYnVpbGRpbmcgZWRnZXMsIHdoZXJlIHRoZSBsb2FkIGlzIHNtYWxsZXIgYW5k IHlvdSBjYW4NCj4gdXNlIG1hc2tpbmcgYW5kIGRpbWluc2ggdGhlIHJ1bGVzZXQgc29tZSBtb3Jl Lg0KDQpidXQgdGhlIG1hbmFnZW1lbnQgaXMgdmVyeSBkaWZmaWN1bHQsIHNlZSBhYm92ZQ0KDQo+ IA0KPiBXaXRoIGEgc3VmZmljaWVudGx5IGZhc3QgYm94LCBvciBzZXJpZXMgb2YgYm94ZXMsIGRv aW5nIHNwZWNpZmljIHRhc2tzLA0KPiB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gZG8gdGhpcy4gIEZv bGtzIGxpa2UgSnVuaXBlciBhY2hpZXZlIGl0IGJ5IGJlaW5nDQo+IGFibGUgdG8gY2xhc3NpZnkg YW5kIG1hcmsgaW4gQVNJQyB3aXRob3V0IGhhdmluZyB0byBnbyB0byB0aGUgcHJvY2Vzc29yLg0K DQpOZXRmaWx0ZXIgYW5kIGlwcm91dGUyL3RjIGlzIHZlcnkgZ29vZCBidXQgSSBtaXNzIGp1c3Qg YSBmYXN0DQptYXRjaGluZyBtb2R1bGUgZm9yIGEgInBvb2wiIG9mIGlwIGFkZHJlc3NlcyBhbmQg dGhlIG1pc3NpbmcgdGMtY3JlZg0Kb3IgYmV0dGVyIGRvY3VtZW50ZWQgdGMgZXhhbXBsZXMsIGVz cGVjaWFsbHkgZGVhbGluZyB3aXRoIGdlbmVyYWwNCmluZ3Jlc3MgcG9saWNpbmcuDQoNCkJlc3Qg cmVnYXJkcw0KCUNoYXJseQ0KDQotLSANCkthcmwgR2Fpc3NtYWllciAgICAgICAgICBDb21wdXRp bmcgQ2VudGVyLFVuaXZlcnNpdHkgb2YgVWxtLEdlcm1hbnkNCkVtYWlsOmthcmwuZ2Fpc3NtYWll ckByei51bmktdWxtLmRlICAgICAgICAgIE5ldHdvcmsgQWRtaW5pc3RyYXRpb24NCg0KDQotLV9f LS1fXy0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpMQVJUQyBtYWlsaW5nIGxpc3QNCkxBUlRDQG1haWxtYW4uZHM5YS5ubA0KaHR0cDovL21haWxt YW4uZHM5YS5ubC9tYWlsbWFuL2xpc3RpbmZvL2xhcnRjDQoNCg0KRW5kIG9mIExBUlRDIERpZ2Vz dA0KDQo= --MIME MULTIPART BOUNDARY=.1030051089:+'1 Content-Type: text/plain; charset=US-ASCII Content-Id: <2340648442-3@softerware.com> Content-Transfer-Encoding: 7bit I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #733 - 12 msgs From: lartc@mailman.ds9a.nl Date: 08/22/02 18:06:01 This item was automatically created and contains MIME Information. --MIME MULTIPART BOUNDARY=.1030051089:+'1-- From n5jxs@tamu.edu Fri Aug 23 01:02:26 2002 From: n5jxs@tamu.edu (Gerry Creager N5JXS) Date: Thu, 22 Aug 2002 19:02:26 -0500 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts References: <3D649512.976BA7DF@rz.uni-ulm.de> <3D64DCA8.7020805@tamu.edu> <3D6551EF.49730B2E@rz.uni-ulm.de> Message-ID: <3D657B92.6040103@tamu.edu> Karl Gaissmaier wrote: > Gerry Creager N5JXS schrieb: > >>The answers are not necessarily pretty. >> >>I've done a similar task with a Juniper M5 router. It will handle up to >>about 180,000 rules at wire speed. But it is expensive. >> >>If your switches were a little newer, we could use 802.1x to enable the >>switch-use capability flag (:-) and solve the problem. > > > you know, 10k hosts are never attached to a network with homogenous > new network devices :-( Unfortunately, I do. We have 50k hosts, more or less, on 2 class B address spaces. We have about 200 buildings, and I'm not sure how many wiring closet switches. And worse, yet, how many wiring closet hubs! Our (switched) dorm hosts are about 10k. So, I understand the issues. The comment about newer gear, and 802.1x, however, stands. This will provide some capability to handle registered hosts in the future, perhaps... but I remain skeptical. >>Instead of policing at a single edge point, you might consider policing >>at dormatory and building edges, where the load is smaller and you can >>use masking and diminsh the ruleset some more. > > > but the management is very difficult, see above Correct, but you have several management issues. One is unnecessary delays while filtering, marking and queuing. Another is device configuration. I've found little existing useful software for real-life multiple device (and heterogeneous device) management. And none I'm willing to pay for. I _do_ have a team of graduate students who are working on a heterogeneous-environment configuration tool, but it's not nearly ready for prime time. >>With a sufficiently fast box, or series of boxes, doing specific tasks, >>you should be able to do this. Folks like Juniper achieve it by being >>able to classify and mark in ASIC without having to go to the processor. > > > Netfilter and iproute2/tc is very good but I miss just a fast > matching module for a "pool" of ip addresses and the missing tc-cref > or better documented tc examples, especially dealing with general > ingress policing. We have experimented with A Juniper M5, as a shaping and filtering box for specific applications. It worked well in the tests, but is an expensive toy for this. You might consider a Sitara box for some off your work. I prefer the Linux approach, too, but there are times where scalability, due to the state of the art (and certainly not for want of advancement in the state of the art!) means a commercial solution. What HAS happened, though, is that my expectations for the commercial products are now higher than they were... and the salesmen are somewhat worried. Regards, Gerry From piotr@omega.resa.es Fri Aug 23 03:33:31 2002 From: piotr@omega.resa.es (Pedro Larroy) Date: Fri, 23 Aug 2002 04:33:31 +0200 Subject: [LARTC] psched_tod_diff function Message-ID: <20020823023331.GA12105@omega> Hi I don't understand what psched_tod_diff function in net/sched/sch_api.c does, so I don't know what PSCHED_TDIFF_SAFE does in sch_tbf.c Any help will be apreciated. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| From piotr@omega.resa.es Fri Aug 23 03:36:12 2002 From: piotr@omega.resa.es (Pedro Larroy) Date: Fri, 23 Aug 2002 04:36:12 +0200 Subject: [LARTC] HTB is in 2.4.20pre1,2 In-Reply-To: References: Message-ID: <20020823023612.GB12105@omega> On Wed, Aug 14, 2002 at 11:32:05PM +0200, devik wrote: > Hi, > for those who haven't realized it yet. It is in 2.4.20pre2, > 2.5.xx, should go into new iproute2 package and I have informations > about possibility to have it in 2.2 soon. > > devik Congratulations devik :) Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| From mikep02@softerware.com Fri Aug 23 05:33:28 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Fri, 23 Aug 2002 00:33:28 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #735 - 3 msgs Message-ID: <748912733@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #735 - 3 msgs From: lartc@mailman.ds9a.nl Date: 08/23/02 01:27:45 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: Q: best solution to stop traffic to huge amount of unregisteredhosts (Gerry Creager N5JXS) 2. psched_tod_diff function (Pedro Larroy) 3. Re: HTB is in 2.4.20pre1,2 (Pedro Larroy) --__--__-- Message: 1 Date: Thu, 22 Aug 2002 19:02:26 -0500 From: Gerry Creager N5JXS Reply-To: n5jxs@tamu.edu Organization: Da House To: Karl Gaissmaier Cc: Linux Advanced Routing & Traffic Control Subject: Re: [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts Karl Gaissmaier wrote: > Gerry Creager N5JXS schrieb: > >>The answers are not necessarily pretty. >> >>I've done a similar task with a Juniper M5 router. It will handle up to >>about 180,000 rules at wire speed. But it is expensive. >> >>If your switches were a little newer, we could use 802.1x to enable the >>switch-use capability flag (:-) and solve the problem. > > > you know, 10k hosts are never attached to a network with homogenous > new network devices :-( Unfortunately, I do. We have 50k hosts, more or less, on 2 class B address spaces. We have about 200 buildings, and I'm not sure how many wiring closet switches. And worse, yet, how many wiring closet hubs! Our (switched) dorm hosts are about 10k. So, I understand the issues. The comment about newer gear, and 802.1x, however, stands. This will provide some capability to handle registered hosts in the future, perhaps... but I remain skeptical. >>Instead of policing at a single edge point, you might consider policing >>at dormatory and building edges, where the load is smaller and you can >>use masking and diminsh the ruleset some more. > > > but the management is very difficult, see above Correct, but you have several management issues. One is unnecessary delays while filtering, marking and queuing. Another is device configuration. I've found little existing useful software for real-life multiple device (and heterogeneous device) management. And none I'm willing to pay for. I _do_ have a team of graduate students who are working on a heterogeneous-environment configuration tool, but it's not nearly ready for prime time. >>With a sufficiently fast box, or series of boxes, doing specific tasks, >>you should be able to do this. Folks like Juniper achieve it by being >>able to classify and mark in ASIC without having to go to the processor. > > > Netfilter and iproute2/tc is very good but I miss just a fast > matching module for a "pool" of ip addresses and the missing tc-cref > or better documented tc examples, especially dealing with general > ingress policing. We have experimented with A Juniper M5, as a shaping and filtering box for specific applications. It worked well in the tests, but is an expensive toy for this. You might consider a Sitara box for some off your work. I prefer the Linux approach, too, but there are times where scalability, due to the state of the art (and certainly not for want of advancement in the state of the art!) means a commercial solution. What HAS happened, though, is that my expectations for the commercial products are now higher than they were... and the salesmen are somewhat worried. Regards, Gerry --__--__-- Message: 2 Date: Fri, 23 Aug 2002 04:33:31 +0200 To: lartc@mailman.ds9a.nl From: Pedro Larroy Subject: [LARTC] psched_tod_diff function Hi I don't understand what psched_tod_diff function in net/sched/sch_api.c does, so I don't know what PSCHED_TDIFF_SAFE does in sch_tbf.c Any help will be apreciated. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| --__--__-- Message: 3 Date: Fri, 23 Aug 2002 04:36:12 +0200 To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB is in 2.4.20pre1,2 From: Pedro Larroy On Wed, Aug 14, 2002 at 11:32:05PM +0200, devik wrote: > Hi, > for those who haven't realized it yet. It is in 2.4.20pre2, > 2.5.xx, should go into new iproute2 package and I have informations > about possibility to have it in 2.2 soon. > > devik Congratulations devik :) Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| --__--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest From phila@dg.net.ua Fri Aug 23 09:31:27 2002 From: phila@dg.net.ua (Anton Yurchenko) Date: Fri, 23 Aug 2002 11:31:27 +0300 Subject: [LARTC] Is TC flow-aware? References: <012f01c249a9$b2a56680$0a0fa8c0@diabelec.com> Message-ID: <3D65F2DF.901@dg.net.ua> George J. Jahchan wrote: >Is TC flow-aware for individual flows (sessions) within a given class of >traffic? > >For example, assuming 100Kbps allocated to a class and 100 simultaneous >active flows within that class. Will each flow get approx. 1K, or will the >greedier >flows capture the lion's share of the 100K, leaving the others struggling to >go >through? > if you set up an sfq qdisc attached to the class then the bandwidth will be devided between flows. in a prety fair manner I`m not shure though what happens with your second question. > > -- Anton Yurchenko Digital Generation From arindamhaldar@inbox.lv Fri Aug 23 13:38:05 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Fri, 23 Aug 2002 18:08:05 +0530 Subject: [LARTC] htb doubts Message-ID: <3D662CAD.4030403@inbox.lv> hi all, i want to clear a doubt i have for some time.. if my htb rules(part of) looks like this---> ... ... tc class add dev eth0 parent 1:10 classid 1:1005 htb rate ${Netwk-64}kbit ceil ${Netwk}kbit tc qdisc add dev eth0 parent 1:1005 handle 1005 pfifo limit 2 ... tc class add dev eth0 parent 1:20 classid 1:2000 htb rate ${Caf}kbit ceil ${All}kbit tc qdisc add dev eth0 parent 1:2000 handle 2000 pfifo limit 2 ... tc class add dev eth0 parent 1:20 classid 1:2001 htb rate ${Ofice}kbit ceil $[All-64]kbit tc qdisc add dev eth0 parent 1:2001 handle 2001 pfifo limit 2 ... what numeric should be used in for handle.. can i use the same numeric value as of **classid** for handle ?.. or should they be unique ? for eg above i used classid 1:2001 and used handle 2001--will it work ? awaiting your help in this.... A.H From stef.coene@docum.org Fri Aug 23 18:11:35 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 23 Aug 2002 19:11:35 +0200 Subject: [LARTC] htb doubts In-Reply-To: <3D662CAD.4030403@inbox.lv> References: <3D662CAD.4030403@inbox.lv> Message-ID: <200208231911.35224.stef.coene@docum.org> > tc class add dev eth0 parent 1:20 classid 1:2001 htb rate ${Ofice}kbit > ceil $[All-64]kbit > tc qdisc add dev eth0 parent 1:2001 handle 2001 pfifo limit 2 > ... > > what numeric should be used in for handle.. can i use the same numeric > value as of **classid** for handle ?.. or should they be unique ? > for eg above i used classid 1:2001 and used handle 2001--will it work ? > > awaiting your help in this.... Yes. Actually it's handle 2001:0 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mikep02@softerware.com Sat Aug 24 05:29:23 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Sat, 24 Aug 2002 00:29:23 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #736 - 4 msgs Message-ID: <784273141@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #736 - 4 msgs From: lartc@mailman.ds9a.nl Date: 08/24/02 01:27:48 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: LARTC digest, Vol 1 #735 - 3 msgs (mikep02@softerware.com) 2. Re: Is TC flow-aware? (Anton Yurchenko) 3. htb doubts (Arindam Haldar) 4. Re: htb doubts (Stef Coene) --__--__-- Message: 1 Date: Fri, 23 Aug 2002 00:33:28 -0400 To: lartc@mailman.ds9a.nl From: mikep02@softerware.com Reply-To: mikep02@softerware.com Subject: [LARTC] Re: LARTC digest, Vol 1 #735 - 3 msgs I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #735 - 3 msgs From: lartc@mailman.ds9a.nl Date: 08/23/02 01:27:45 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: Q: best solution to stop traffic to huge amount of unregisteredhosts (Gerry Creager N5JXS) 2. psched_tod_diff function (Pedro Larroy) 3. Re: HTB is in 2.4.20pre1,2 (Pedro Larroy) -- __--__-- Message: 1 Date: Thu, 22 Aug 2002 19:02:26 -0500 From: Gerry Creager N5JXS Reply-To: n5jxs@tamu.edu Organization: Da House To: Karl Gaissmaier Cc: Linux Advanced Routing & Traffic Control Subject: Re: [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts Karl Gaissmaier wrote: > Gerry Creager N5JXS schrieb: > >>The answers are not necessarily pretty. >> >>I've done a similar task with a Juniper M5 router. It will handle up to >>about 180,000 rules at wire speed. But it is expensive. >> >>If your switches were a little newer, we could use 802.1x to enable the >>switch-use capability flag (:-) and solve the problem. > > > you know, 10k hosts are never attached to a network with homogenous > new network devices :-( Unfortunately, I do. We have 50k hosts, more or less, on 2 class B address spaces. We have about 200 buildings, and I'm not sure how many wiring closet switches. And worse, yet, how many wiring closet hubs! Our (switched) dorm hosts are about 10k. So, I understand the issues. The comment about newer gear, and 802.1x, however, stands. This will provide some capability to handle registered hosts in the future, perhaps... but I remain skeptical. >>Instead of policing at a single edge point, you might consider policing >>at dormatory and building edges, where the load is smaller and you can >>use masking and diminsh the ruleset some more. > > > but the management is very difficult, see above Correct, but you have several management issues. One is unnecessary delays while filtering, marking and queuing. Another is device configuration. I've found little existing useful software for real-life multiple device (and heterogeneous device) management. And none I'm willing to pay for. I _do_ have a team of graduate students who are working on a heterogeneous-environment configuration tool, but it's not nearly ready for prime time. >>With a sufficiently fast box, or series of boxes, doing specific tasks, >>you should be able to do this. Folks like Juniper achieve it by being >>able to classify and mark in ASIC without having to go to the processor. > > > Netfilter and iproute2/tc is very good but I miss just a fast > matching module for a "pool" of ip addresses and the missing tc-cref > or better documented tc examples, especially dealing with general > ingress policing. We have experimented with A Juniper M5, as a shaping and filtering box for specific applications. It worked well in the tests, but is an expensive toy for this. You might consider a Sitara box for some off your work. I prefer the Linux approach, too, but there are times where scalability, due to the state of the art (and certainly not for want of advancement in the state of the art!) means a commercial solution. What HAS happened, though, is that my expectations for the commercial products are now higher than they were... and the salesmen are somewhat worried. Regards, Gerry -- __--__-- Message: 2 Date: Fri, 23 Aug 2002 04:33:31 +0200 To: lartc@mailman.ds9a.nl From: Pedro Larroy Subject: [LARTC] psched_tod_diff function Hi I don't understand what psched_tod_diff function in net/sched/sch_api.c does, so I don't know what PSCHED_TDIFF_SAFE does in sch_tbf.c Any help will be apreciated. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| -- __--__-- Message: 3 Date: Fri, 23 Aug 2002 04:36:12 +0200 To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB is in 2.4.20pre1,2 From: Pedro Larroy On Wed, Aug 14, 2002 at 11:32:05PM +0200, devik wrote: > Hi, > for those who haven't realized it yet. It is in 2.4.20pre2, > 2.5.xx, should go into new iproute2 package and I have informations > about possibility to have it in 2.2 soon. > > devik Congratulations devik :) Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| -- __--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest --__--__-- Message: 2 Date: Fri, 23 Aug 2002 11:31:27 +0300 From: Anton Yurchenko To: "George J. Jahchan" Cc: Linux Advanced Routing & Traffic Control Subject: Re: [LARTC] Is TC flow-aware? George J. Jahchan wrote: >Is TC flow-aware for individual flows (sessions) within a given class of >traffic? > >For example, assuming 100Kbps allocated to a class and 100 simultaneous >active flows within that class. Will each flow get approx. 1K, or will the >greedier >flows capture the lion's share of the 100K, leaving the others struggling to >go >through? > if you set up an sfq qdisc attached to the class then the bandwidth will be devided between flows. in a prety fair manner I`m not shure though what happens with your second question. > > -- Anton Yurchenko Digital Generation --__--__-- Message: 3 Date: Fri, 23 Aug 2002 18:08:05 +0530 From: Arindam Haldar To: LARTC Subject: [LARTC] htb doubts hi all, i want to clear a doubt i have for some time.. if my htb rules(part of) looks like this---> ... ... tc class add dev eth0 parent 1:10 classid 1:1005 htb rate ${Netwk-64}kbit ceil ${Netwk}kbit tc qdisc add dev eth0 parent 1:1005 handle 1005 pfifo limit 2 ... tc class add dev eth0 parent 1:20 classid 1:2000 htb rate ${Caf}kbit ceil ${All}kbit tc qdisc add dev eth0 parent 1:2000 handle 2000 pfifo limit 2 ... tc class add dev eth0 parent 1:20 classid 1:2001 htb rate ${Ofice}kbit ceil $[All-64]kbit tc qdisc add dev eth0 parent 1:2001 handle 2001 pfifo limit 2 ... what numeric should be used in for handle.. can i use the same numeric value as of **classid** for handle ?.. or should they be unique ? for eg above i used classid 1:2001 and used handle 2001--will it work ? awaiting your help in this.... A.H --__--__-- Message: 4 From: Stef Coene Organization: None To: Arindam Haldar , LARTC Subject: Re: [LARTC] htb doubts Date: Fri, 23 Aug 2002 19:11:35 +0200 > tc class add dev eth0 parent 1:20 classid 1:2001 htb rate ${Ofice}kbit > ceil $[All-64]kbit > tc qdisc add dev eth0 parent 1:2001 handle 2001 pfifo limit 2 > ... > > what numeric should be used in for handle.. can i use the same numeric > value as of **classid** for handle ?.. or should they be unique ? > for eg above i used classid 1:2001 and used handle 2001--will it work ? > > awaiting your help in this.... Yes. Actually it's handle 2001:0 Stef --=20 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 End of LARTC Digest From nji-lartc@njivy.org Sat Aug 24 14:45:42 2002 From: nji-lartc@njivy.org (Nic Ivy) Date: Sat, 24 Aug 2002 23:45:42 +1000 (ChST) Subject: [LARTC] traffic id by iproute2 for iptables Message-ID: <10043.202.22.178.58.1030196742.squirrel@mail.njivy.org> I have several parallel public networks attached to a single network interface. Each public network requires iptables to do a different SNAT in the POSTROUTING table. I think iproute2 can do multipath routing over a single device, but can iptables recognize which network a packet is destined for? I have explored using the 'realm' match in iptables 1.2.8 (cvs), but iproute2 apparently doesn't support realms in multipath routing statements. Can iproute2 mark packets another way such that iptables can recognize it? Nic Ivy From nji-lartc@njivy.org Sun Aug 25 05:23:50 2002 From: nji-lartc@njivy.org (Nic Ivy) Date: Sun, 25 Aug 2002 14:23:50 +1000 (ChST) Subject: [LARTC] could iproute2 set fwmark? Message-ID: <10593.202.22.178.58.1030249430.squirrel@mail.njivy.org> How feasible would it be to have iproute2 set fwmark, the mark normally set by ipchains/iptables? This would help iptables (postrouting) identify the intended route for a packet. Nic Ivy From mikep02@softerware.com Sun Aug 25 05:33:49 2002 From: mikep02@softerware.com (mikep02@softerware.com) Date: Sun, 25 Aug 2002 00:33:49 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #737 - 2 msgs Message-ID: <1967466258@softerware.com> I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #737 - 2 msgs From: lartc@mailman.ds9a.nl Date: 08/25/02 01:27:57 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: LARTC digest, Vol 1 #736 - 4 msgs (mikep02@softerware.com) 2. traffic id by iproute2 for iptables (Nic Ivy) --__--__-- Message: 1 Date: Sat, 24 Aug 2002 00:29:23 -0400 To: lartc@mailman.ds9a.nl From: mikep02@softerware.com Reply-To: mikep02@softerware.com Subject: [LARTC] Re: LARTC digest, Vol 1 #736 - 4 msgs I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #736 - 4 msgs From: lartc@mailman.ds9a.nl Date: 08/24/02 01:27:48 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: LARTC digest, Vol 1 #735 - 3 msgs (mikep02@softerware.com) 2. Re: Is TC flow-aware? (Anton Yurchenko) 3. htb doubts (Arindam Haldar) 4. Re: htb doubts (Stef Coene) -- __--__-- Message: 1 Date: Fri, 23 Aug 2002 00:33:28 -0400 To: lartc@mailman.ds9a.nl From: mikep02@softerware.com Reply-To: mikep02@softerware.com Subject: [LARTC] Re: LARTC digest, Vol 1 #735 - 3 msgs I will be out of the office from 8/19 until 8/23. I will be returning on Monday afternoon, 8/26, and will reply then. Thank you, Michael Pellegrino Softerware, Inc. ___________________________________________________________________________ Subject: LARTC digest, Vol 1 #735 - 3 msgs From: lartc@mailman.ds9a.nl Date: 08/23/02 01:27:45 Send LARTC mailing list submissions to lartc@mailman.ds9a.nl To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@mailman.ds9a.nl You can reach the person managing the list at lartc-admin@mailman.ds9a.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. Re: Q: best solution to stop traffic to huge amount of unregisteredhosts (Gerry Creager N5JXS) 2. psched_tod_diff function (Pedro Larroy) 3. Re: HTB is in 2.4.20pre1,2 (Pedro Larroy) -- __--__-- Message: 1 Date: Thu, 22 Aug 2002 19:02:26 -0500 From: Gerry Creager N5JXS Reply-To: n5jxs@tamu.edu Organization: Da House To: Karl Gaissmaier Cc: Linux Advanced Routing & Traffic Control Subject: Re: [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts Karl Gaissmaier wrote: > Gerry Creager N5JXS schrieb: > >>The answers are not necessarily pretty. >> >>I've done a similar task with a Juniper M5 router. It will handle up to >>about 180,000 rules at wire speed. But it is expensive. >> >>If your switches were a little newer, we could use 802.1x to enable the >>switch-use capability flag (:-) and solve the problem. > > > you know, 10k hosts are never attached to a network with homogenous > new network devices :-( Unfortunately, I do. We have 50k hosts, more or less, on 2 class B address spaces. We have about 200 buildings, and I'm not sure how many wiring closet switches. And worse, yet, how many wiring closet hubs! Our (switched) dorm hosts are about 10k. So, I understand the issues. The comment about newer gear, and 802.1x, however, stands. This will provide some capability to handle registered hosts in the future, perhaps... but I remain skeptical. >>Instead of policing at a single edge point, you might consider policing >>at dormatory and building edges, where the load is smaller and you can >>use masking and diminsh the ruleset some more. > > > but the management is very difficult, see above Correct, but you have several management issues. One is unnecessary delays while filtering, marking and queuing. Another is device configuration. I've found little existing useful software for real-life multiple device (and heterogeneous device) management. And none I'm willing to pay for. I _do_ have a team of graduate students who are working on a heterogeneous-environment configuration tool, but it's not nearly ready for prime time. >>With a sufficiently fast box, or series of boxes, doing specific tasks, >>you should be able to do this. Folks like Juniper achieve it by being >>able to classify and mark in ASIC without having to go to the processor. > > > Netfilter and iproute2/tc is very good but I miss just a fast > matching module for a "pool" of ip addresses and the missing tc-cref > or better documented tc examples, especially dealing with general > ingress policing. We have experimented with A Juniper M5, as a shaping and filtering box for specific applications. It worked well in the tests, but is an expensive toy for this. You might consider a Sitara box for some off your work. I prefer the Linux approach, too, but there are times where scalability, due to the state of the art (and certainly not for want of advancement in the state of the art!) means a commercial solution. What HAS happened, though, is that my expectations for the commercial products are now higher than they were... and the salesmen are somewhat worried. Regards, Gerry -- __--__-- Message: 2 Date: Fri, 23 Aug 2002 04:33:31 +0200 To: lartc@mailman.ds9a.nl From: Pedro Larroy Subject: [LARTC] psched_tod_diff function Hi I don't understand what psched_tod_diff function in net/sched/sch_api.c does, so I don't know what PSCHED_TDIFF_SAFE does in sch_tbf.c Any help will be apreciated. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| -- __--__-- Message: 3 Date: Fri, 23 Aug 2002 04:36:12 +0200 To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] HTB is in 2.4.20pre1,2 From: Pedro Larroy On Wed, Aug 14, 2002 at 11:32:05PM +0200, devik wrote: > Hi, > for those who haven't realized it yet. It is in 2.4.20pre2, > 2.5.xx, should go into new iproute2 package and I have informations > about possibility to have it in 2.2 soon. > > devik Congratulations devik :) Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| -- __--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest -- __--__-- Message: 2 Date: Fri, 23 Aug 2002 11:31:27 +0300 From: Anton Yurchenko To: "George J. Jahchan" Cc: Linux Advanced Routing & Traffic Control Subject: Re: [LARTC] Is TC flow-aware? George J. Jahchan wrote: >Is TC flow-aware for individual flows (sessions) within a given class of >traffic? > >For example, assuming 100Kbps allocated to a class and 100 simultaneous >active flows within that class. Will each flow get approx. 1K, or will the >greedier >flows capture the lion's share of the 100K, leaving the others struggling to >go >through? > if you set up an sfq qdisc attached to the class then the bandwidth will be devided between flows. in a prety fair manner I`m not shure though what happens with your second question. > > -- Anton Yurchenko Digital Generation -- __--__-- Message: 3 Date: Fri, 23 Aug 2002 18:08:05 +0530 From: Arindam Haldar To: LARTC Subject: [LARTC] htb doubts hi all, i want to clear a doubt i have for some time.. if my htb rules(part of) looks like this---> ... ... tc class add dev eth0 parent 1:10 classid 1:1005 htb rate ${Netwk-64}kbit ceil ${Netwk}kbit tc qdisc add dev eth0 parent 1:1005 handle 1005 pfifo limit 2 ... tc class add dev eth0 parent 1:20 classid 1:2000 htb rate ${Caf}kbit ceil ${All}kbit tc qdisc add dev eth0 parent 1:2000 handle 2000 pfifo limit 2 ... tc class add dev eth0 parent 1:20 classid 1:2001 htb rate ${Ofice}kbit ceil $[All-64]kbit tc qdisc add dev eth0 parent 1:2001 handle 2001 pfifo limit 2 ... what numeric should be used in for handle.. can i use the same numeric value as of **classid** for handle ?.. or should they be unique ? for eg above i used classid 1:2001 and used handle 2001--will it work ? awaiting your help in this.... A.H -- __--__-- Message: 4 From: Stef Coene Organization: None To: Arindam Haldar , LARTC Subject: Re: [LARTC] htb doubts Date: Fri, 23 Aug 2002 19:11:35 +0200 > tc class add dev eth0 parent 1:20 classid 1:2001 htb rate ${Ofice}kbit > ceil $[All-64]kbit > tc qdisc add dev eth0 parent 1:2001 handle 2001 pfifo limit 2 > ... > > what numeric should be used in for handle.. can i use the same numeric > value as of **classid** for handle ?.. or should they be unique ? > for eg above i used classid 1:2001 and used handle 2001--will it work ? > > awaiting your help in this.... Yes. Actually it's handle 2001:0 Stef --=20 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 End of LARTC Digest --__--__-- Message: 2 Date: Sat, 24 Aug 2002 23:45:42 +1000 (ChST) From: "Nic Ivy" To: Subject: [LARTC] traffic id by iproute2 for iptables I have several parallel public networks attached to a single network interface. Each public network requires iptables to do a different SNAT in the POSTROUTING table. I think iproute2 can do multipath routing over a single device, but can iptables recognize which network a packet is destined for? I have explored using the 'realm' match in iptables 1.2.8 (cvs), but iproute2 apparently doesn't support realms in multipath routing statements. Can iproute2 mark packets another way such that iptables can recognize it? Nic Ivy --__--__-- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest From miernik@debina.ctnet.pl Sun Aug 25 14:04:16 2002 From: miernik@debina.ctnet.pl (Jan Macek) Date: Sun, 25 Aug 2002 15:04:16 +0200 (CEST) Subject: [LARTC] how to log pacets which hit routing rules? Message-ID: Hi, Is there some way to make iproute2 log to syslog or to a file selected packets? I have a problem, that my packets dissapear somewhere, and I want to be sure if they get to the routing stage or not, and where do they get routed. -- Miernik _____________________________________ / / tel.: +48603070983 / / mailto:miernik@ctnet.pl __________________/___/ ICQ UIN: 4004001 From miernik@debina.ctnet.pl Sun Aug 25 14:11:13 2002 From: miernik@debina.ctnet.pl (Jan Macek) Date: Sun, 25 Aug 2002 15:11:13 +0200 (CEST) Subject: [LARTC] how to force iproute2 to FORWARD to another interface packets with a destinatioin IP on this machine? Message-ID: I have this situation: My machine debina, has three interfaces: eth1 212.126.24.129 ppp0 10.2.0.1 (Point-to-Point: 212.31.242.98) nsc5 10.2.0.250 (Point-to-Point: 172.23.140.32) I want packets which come in through the nsc5 interface, to be FORWARDED to the ppp0 interface to 212.31.242.98, even when their destination address is 212.126.24.129 (even so this is the IP of eth1 on this machine). How to achieve that? -- Miernik _____________________________________ / / tel.: +48603070983 / / mailto:miernik@ctnet.pl __________________/___/ ICQ UIN: 4004001 From piotr@omega.resa.es Sun Aug 25 19:44:45 2002 From: piotr@omega.resa.es (Pedro Larroy) Date: Sun, 25 Aug 2002 20:44:45 +0200 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts In-Reply-To: <3D657B92.6040103@tamu.edu> References: <3D649512.976BA7DF@rz.uni-ulm.de> <3D64DCA8.7020805@tamu.edu> <3D6551EF.49730B2E@rz.uni-ulm.de> <3D657B92.6040103@tamu.edu> Message-ID: <20020825184445.GA13527@omega> On Thu, Aug 22, 2002 at 07:02:26PM -0500, Gerry Creager N5JXS wrote: > > Our (switched) dorm hosts are about 10k. How do you deal with ip theft? > > Regards, > Gerry > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| From amitk@ittc.ku.edu Sun Aug 25 22:01:38 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Sun, 25 Aug 2002 16:01:38 -0500 (CDT) Subject: [LARTC] HTB3 port for 2.2.18? In-Reply-To: Message-ID: On Sun, 25 Aug 2002, Julian Anastasov wrote: > # 3 GRED qdiscs for the 3 drop priorities of real time packets > -$TC qdisc add $DEV parent 2:1 gred limit 12KB min 3KB max 9KB \ > +$TC qdisc change $DEV parent 2:1 gred limit 12KB min 3KB max 9KB \ > burst 20 $AVPKT $BW DP 1 probability 0.02 prio 2 > -$TC qdisc add $DEV parent 2:1 gred limit 12KB min 3KB max 9KB \ > +$TC qdisc change $DEV parent 2:1 gred limit 12KB min 3KB max 9KB \ > burst 20 $AVPKT $BW DP 2 probability 0.04 prio 3 > -$TC qdisc add $DEV parent 2:1 gred limit 12KB min 3KB max 9KB \ > +$TC qdisc change $DEV parent 2:1 gred limit 12KB min 3KB max 9KB \ > burst 20 $AVPKT $BW DP 3 probability 0.06 prio 4 > i.e. first time it is "qdisc add", later the qdisc is changed > with "qdisc change". > > Let me know if this is the only problem and whether > GRED is working properly. Thanks. Hi, It works now! It seems to me that the semantics of the GRED qdisc with respect to 'tc' have changed. The script I had provided worked with CBQ i.e. 'qdisc add' was used 3 times to add the GRED qdiscs with different drop probabilities. Thanks a lot. Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From lromano@its.na.it Tue Aug 27 09:22:09 2002 From: lromano@its.na.it (Luigi Romano) Date: Tue, 27 Aug 2002 10:22:09 +0200 Subject: [LARTC] Buffering traffic flow with HTB Message-ID: <001101c24da2$eda4dac0$e0640a0a@lromano> This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C24DB3.99A00100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, can I buffer traffic flow with HTB (like with TBF)? HTB hasn't the "limit" parameter that represent the buffer size in tbf. there is another manner to buffering traffic with HTB? Thank in advance, Luigi Romano ------=_NextPart_000_000C_01C24DB3.99A00100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
can I buffer traffic flow with HTB (like with=20 TBF)?
HTB hasn't the "limit" parameter that represent the = buffer=20 size in tbf.
there is another manner to buffering traffic with=20 HTB?
 
Thank in advance,
        Luigi=20 Romano
 
 
 
 
 
 
 
 
------=_NextPart_000_000C_01C24DB3.99A00100-- From devik@cdi.cz Tue Aug 27 10:09:54 2002 From: devik@cdi.cz (Martin Devera) Date: Tue, 27 Aug 2002 11:09:54 +0200 (CEST) Subject: [LARTC] Buffering traffic flow with HTB In-Reply-To: <001101c24da2$eda4dac0$e0640a0a@lromano> References: <001101c24da2$eda4dac0$e0640a0a@lromano> Message-ID: include pfifo or bfifo as leaf and set limit on it. devik On Tue, 27 Aug 2002, Luigi Romano wrote: > Hi all, > can I buffer traffic flow with HTB (like with TBF)? > HTB hasn't the "limit" parameter that represent the buffer size in tbf. > there is another manner to buffering traffic with HTB? > > Thank in advance, > Luigi Romano > > > > > > > > From jaag@dte.uma.es Tue Aug 27 12:49:58 2002 From: jaag@dte.uma.es (=?iso-8859-1?Q?Jos=E9?= Alberto Aguilar =?iso-8859-1?Q?Gonz=E1lez?=) Date: Tue, 27 Aug 2002 13:49:58 +0200 Subject: [LARTC] dsmark_dequeue: unsupported protocol 2054 In-Reply-To: References: <001101c24da2$eda4dac0$e0640a0a@lromano> <001101c24da2$eda4dac0$e0640a0a@lromano> Message-ID: <5.1.0.14.0.20020827132818.00bc70e0@150.214.59.79> Hi all, I am using dsmark in a DS Edge router and I got those "dsmark_dequeue: unsupported protocol 2054" messages. I know it is ARP traffic (2054=0x806) and I wonder how can I avoid that kind traffic entering in the dsmark. Thanx in advance From wa@almesberger.net Wed Aug 28 01:10:35 2002 From: wa@almesberger.net (Werner Almesberger) Date: Tue, 27 Aug 2002 21:10:35 -0300 Subject: [LARTC] dsmark_dequeue: unsupported protocol 2054 In-Reply-To: <5.1.0.14.0.20020827132818.00bc70e0@150.214.59.79>; from jaag@dte.uma.es on Tue, Aug 27, 2002 at 01:49:58PM +0200 References: <001101c24da2$eda4dac0$e0640a0a@lromano> <001101c24da2$eda4dac0$e0640a0a@lromano> <5.1.0.14.0.20020827132818.00bc70e0@150.214.59.79> Message-ID: <20020827211035.E2239@almesberger.net> José Alberto Aguilar González wrote: > I am using dsmark in a DS Edge router and I got those "dsmark_dequeue: > unsupported protocol 2054" messages. > I know it is ARP traffic (2054=0x806) and I wonder how can I avoid that > kind traffic entering in the dsmark. Entering dsmark per se isn't a problem. dsmark will happily ignore your ARP traffic as long as you don't ask dsmark to actually (re)mark it. dsmark will notice that you're not trying to (re)mark the packets, if the dsmark class you're sending it to uses value 0 and mask 0xff. In case you really want to divert non-IP traffic, you need another qdisc around dsmark, and send only IPv4 and IPv6 traffic to the class to which dsmark is attached. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ From htb@nimaci.pcnet.ro Wed Aug 28 14:15:02 2002 From: htb@nimaci.pcnet.ro (Ciprian Nica) Date: Wed, 28 Aug 2002 16:15:02 +0300 (EEST) Subject: [LARTC] HTB - problem with one thread Message-ID: Hello, Besides a very good functionality, I have a small, yet stressing, problem. Let's say I have a bandwidth of N bits. I have X clients, everyone with his fixed bandwidth. I create htb qdsics for each client. Each leaf has sfq queueing discipline. A sample config would be like this : tc class add dev eth0 parent 1:2 classid 1:346 htb rate 32Kbit ceil 32Kbit burst 4k cburst 2k prio 4 tc qdisc add dev eth0 parent 1:346 handle 346 sfq perturb 10 AND tc class add dev eth0 parent 1:2 classid 1:161 htb rate 256Kbit ceil 256Kbit burst 32k cburst 2k prio 4 tc qdisc add dev eth0 parent 1:161 handle 161 sfq perturb 10 The filters are like : tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 1.2.3.128/25 classid 1:346 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 1.2.3.4/30 classid 1:161 The problem is that clients can have their bandwidths at maximum only if they use a download accelerating software like DAP with multiple symultanous threads. Using only one thread, a single download can reach about 60% of the allocated bandwidth. I have tested a download without any limits and it was working well, so there's no problem with the remote site. I have searched thorugh messages posted on this mailing list but I didn't find a similar problem. Maybe I need to set quantum manually. I have tested with r2q default value (10) and also with 2 (raising quantum). Another question would be: if quantum is bigger, the client can exceed his limit by that value ? Is that possible all the time or at bursty intervals ? Thank you very much, Ciprian Nica From robert.penz@outertech.com Wed Aug 28 14:21:32 2002 From: robert.penz@outertech.com (Robert Penz) Date: Wed, 28 Aug 2002 15:21:32 +0200 Subject: [LARTC] patch HTB to 2.4.19 problem Message-ID: <200208281521.33111.robert.penz@outertech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I keep getting following whitestar:/usr/src/linux-2.4.19# patch -p1 < ../htb3.6_2.4.17.diff patching file net/sched/Config.in patching file net/sched/Makefile patching file net/sched/sch_htb.c patching file include/linux/pkt_sched.h patching file net/sched/sch_api.c Hunk #1 FAILED at 1117. 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.rej patching file lib/Makefile Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 8. 1 out of 1 hunk FAILED -- saving rejects to file lib/Makefile.rej patching file lib/rbtree.c Reversed (or previously applied) patch detected! Assume -R? [n] - --=20 Regards, Robert - ---------------- Robert Penz robert.penz@outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9bM5d8tTsQqJDUBMRAuInAKCB3a9J+DMuJERG6Ug0D/j+G/maRACgoeHf JPaHJBfzUxIy25s58dfc7B0=3D =3D1OYV -----END PGP SIGNATURE----- From mello@lcs.poli.usp.br Wed Aug 28 17:21:33 2002 From: mello@lcs.poli.usp.br (Fernando Lemos de Mello) Date: Wed, 28 Aug 2002 13:21:33 -0300 Subject: [LARTC] Help with tc TBF filter References: <20020828042624.22689.85453.Mailman@outpost> Message-ID: <001b01c24eae$fac53760$6564a8c0@mello> Dear Friends, I have tryed to follow the Traffic Control HOWTO to setup a bandwidth limit of 500kbps in a Ethernet 10Mbps LAN. What I did: tc qdisc add dev eth0 root tbf rate 500kbit limit 50kb burst 10kb peakrate 501kbit mtu 6000b Happens that in average I get the correct rate: 500kbps, but unfortunatly, what the token bucket filter does is that some times it sends burts of packets, and other times it waits for a relative long time before sending packets. I believe this is a problem for what I would like to have: I need a token bucket or leaky bucket algorithm that counts packet by packet, how many bytes it is putting on the link. In a really small window, like 10 ms for example. Then: 10ms * 500k = 5000 bits each 10ms or 625 bytes each 10ms This is what would be perfect for me: the algorithm sends at most 625 bytes each 10ms. No burts!!! Reading the HOWTO I had the impression that it is not possible using tc - TBF. Is it right? Does anyone know if this is possible to be achieved? Thanks for your patience and atttention. Fernando. From stef.coene@docum.org Wed Aug 28 18:45:53 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 28 Aug 2002 19:45:53 +0200 Subject: [LARTC] HTB - problem with one thread In-Reply-To: References: Message-ID: <200208281945.54073.stef.coene@docum.org> On Wednesday 28 August 2002 15:15, Ciprian Nica wrote: > Hello, > > Besides a very good functionality, I have a small, yet stressing, probl= em. > > Let's say I have a bandwidth of N bits. > > I have X clients, everyone with his fixed bandwidth. > > I create htb qdsics for each client. Each leaf has sfq queueing > discipline. > > A sample config would be like this : > > tc class add dev eth0 parent 1:2 classid 1:346 htb rate 32Kbit ceil 32K= bit > burst 4k cburst 2k prio 4 > tc qdisc add dev eth0 parent 1:346 handle 346 sfq perturb 10 > > AND > > tc class add dev eth0 parent 1:2 classid 1:161 htb rate 256Kbit ceil > 256Kbit burst 32k cburst 2k prio 4 > tc qdisc add dev eth0 parent 1:161 handle 161 sfq perturb 10 > > > The filters are like : > tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst > 1.2.3.128/25 classid 1:346 tc filter add dev eth0 parent 1:0 protocol i= p > prio 100 u32 match ip dst 1.2.3.4/30 classid 1:161 > > The problem is that clients can have their bandwidths at maximum only i= f > they use a download accelerating software like DAP with multiple > symultanous threads. Using only one thread, a single download can reach > about 60% of the allocated bandwidth. > > I have tested a download without any limits and it was working well, so > there's no problem with the remote site. > > I have searched thorugh messages posted on this mailing list but I didn= 't > find a similar problem. > > > Maybe I need to set quantum manually. I have tested with r2q default va= lue > (10) and also with 2 (raising quantum). > > Another question would be: if quantum is bigger, the client can exceed = his > limit by that value ? Is that possible all the time or at bursty interv= als > ? Quantum is used if 2 or more classes with the same parent are fighting fo= r=20 bandwidth. First, they are allowed to get the rate you gave them. For t= he=20 remaining bandwidth, quantum is used. Each class may send quantum bytes.= =20 You have to make sure quantum > MTU (typical 1500 bytes for ethernet). What if you use no sfq qdiscs? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Aug 28 18:48:54 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 28 Aug 2002 19:48:54 +0200 Subject: [LARTC] patch HTB to 2.4.19 problem In-Reply-To: <200208281521.33111.robert.penz@outertech.com> References: <200208281521.33111.robert.penz@outertech.com> Message-ID: <200208281948.54897.stef.coene@docum.org> On Wednesday 28 August 2002 15:21, Robert Penz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I keep getting following > > whitestar:/usr/src/linux-2.4.19# patch -p1 < ../htb3.6_2.4.17.diff > patching file net/sched/Config.in > patching file net/sched/Makefile > patching file net/sched/sch_htb.c > patching file include/linux/pkt_sched.h > patching file net/sched/sch_api.c > Hunk #1 FAILED at 1117. > 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.r= ej > patching file lib/Makefile > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] y > Hunk #1 FAILED at 8. > 1 out of 1 hunk FAILED -- saving rejects to file lib/Makefile.rej > patching file lib/rbtree.c > Reversed (or previously applied) patch detected! Assume -R? [n] You can safely ignore these errors. Just press enter on all questions. If you check out the *.rej files, you will see that some of the htb patch= es=20 are already applied to the default linux kernel. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From p0wer@tl.krakow.pl Thu Aug 29 07:26:28 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Thu, 29 Aug 2002 08:26:28 +0200 (CEST) Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ In-Reply-To: Message-ID: On Tue, 20 Aug 2002, Amit Kucheria wrote: > On Fri, 16 Aug 2002, Stef Coene wrote: > > >> The 'ceil' parameter allows us to implement a part of the 'isolated' > >> definition above. By setting it equal to 'rate', the class does not > >> borrow bandwidth, but what will stop other classes from borrowing its > >> unused bandwidth? > > > > Providing no ceil parameter means rate = ceil. But this can not be > > used to implement isolated like in cbq. Rate = ceil means the class > > can not use more bandwidth then it's rate. Isolated in cbq means other > > classes can not borrow bandwidth from the class and that's not the > > same. There is no way you can implement isolated with htb. > > > > But with htb you can do something like this : > > > > Total : 100 > > class1 rate 20 ceil 20 > > class2 rate 40 ceil 80 > > class3 rate 40 ceil 80 > > > > class 1 is isolated like in cbq. It can not use more then it's > > rate/ceil and class2 and class3 will never use bandwidth from class1, > > only from each other. Just like the definition of isolated :) > > What happens when there is no traffic in class 1? Will class 2 and 3 > share class 1's bandwidth then? > > The reason I am asking these questions is because I am trying to see if > HTB can be used in place of CBQ in Diffserv. Has anybody tried something > like this? It works fine for me, although I haven't used CBQ previously so I can't comapre them. It just works for me, except the delays in interactive class are too long, even when the prio is 0 (highest) and the rate and ceil are maximum. Maybe CBQ is better in reducing the delays... Anybody solved this problem? -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From arc_of_descent@gmx.net Thu Aug 29 08:19:53 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Thu, 29 Aug 2002 12:49:53 +0530 Subject: [LARTC] htb guarantee bandwidth Message-ID: <02082912495300.01420@sanitarium> Hi People, I am really losing sleep over concept of bandwidth guarantee using htb. Let me say that i have tried cbq and was quite satisfied. A simple example. I have a link of 128 Kbps, and 3 clients. Now i give each of them a bandwidth restriction of 64 Kbps, and one out of them i want guaranteed bandwidth. Now with cbq, i create an isolated class for the guaranteed guy, and i observerd that regardless of the other 2 machines being online, He always gets his allocated 64 Kbps. For htb, since there is no keyword "isolated", i created 3 root classes. Also in htb, its documented that root classes do not share from each other. In other words, can i assume that they are isolated? I tried the same scenario as above using htb, but unfortunately the guaranteed machine was not receiving the allocated bandwidth. Has neone doen nething like this? Thanx -- arc_of_descent From htb@nimaci.pcnet.ro Thu Aug 29 09:19:08 2002 From: htb@nimaci.pcnet.ro (Ciprian Nica) Date: Thu, 29 Aug 2002 11:19:08 +0300 Subject: [LARTC] HTB - problem with one thread In-Reply-To: <200208281945.54073.stef.coene@docum.org> References: <200208281945.54073.stef.coene@docum.org> Message-ID: <200208291119.08869.htb@nimaci.pcnet.ro> On Wednesday 28 August 2002 20:45, Stef Coene wrote: > > The problem is that clients can have their bandwidths at maximum only if > > they use a download accelerating software like DAP with multiple > > symultanous threads. Using only one thread, a single download can reach > > about 60% of the allocated bandwidth. > > Quantum is used if 2 or more classes with the same parent are fighting for > bandwidth. First, they are allowed to get the rate you gave them. For the > remaining bandwidth, quantum is used. Each class may send quantum bytes. > You have to make sure quantum > MTU (typical 1500 bytes for ethernet). > > What if you use no sfq qdiscs? > > Stef I have tried with pfifo queues and it's the same. I made many tests changing quantum, queueing for leaf but in no case I could reach the allocated bandwidth with a single download thread. The same limit set on cisco router with traffic-shape, worked fine. Could there be a problem when there are many qdiscs ? Are there many calculations to be done, so the packets get delayed and the TCP transfer rate is lowered. Ciprian From ciprian@promo.ro Thu Aug 29 09:53:58 2002 From: ciprian@promo.ro (Ciprian Niculescu) Date: Thu, 29 Aug 2002 11:53:58 +0300 Subject: [LARTC] htb guarantee bandwidth References: <02082912495300.01420@sanitarium> Message-ID: <3D6DE126.6020704@promo.ro> hi, you give to all the clients all the bandwith or limited at 64k, but with different priorities. class parent 1: classid 1:5 htb rate 128kbit class parent 1:5 classid 1:1 htb rate 64kbit ceil 128kbit prio 1 class parent 1:5 classid 1:2 htb rate 64kbit ceil 128kbit prio 2 you put the client that you want to have guaranted 64kbps in 1:1, and the other two in 1:2. it's the clasic example from the devik page. C Rohan Almeida wrote: > Hi People, > I am really losing sleep over concept of bandwidth guarantee > using htb. > Let me say that i have tried cbq and was quite satisfied. > > A simple example. > I have a link of 128 Kbps, and 3 clients. > Now i give each of them a bandwidth restriction of 64 Kbps, > and one out of them i want guaranteed bandwidth. > > Now with cbq, i create an isolated class for the guaranteed guy, > and i observerd that regardless of the other 2 machines being online, > He always gets his allocated 64 Kbps. > > For htb, since there is no keyword "isolated", i created 3 root classes. > Also in htb, its documented that root classes do not share from each > other. In other words, can i assume that they are isolated? > > I tried the same scenario as above using htb, but unfortunately > the guaranteed machine was not receiving the allocated > bandwidth. > > Has neone doen nething like this? > Thanx > > -- > arc_of_descent > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ------------------------------------------------------- Xnet scaneaza automat toate mesajele impotriva virusilor folosind RAV AntiVirus. Xnet automatically scans all messages for viruses using RAV AntiVirus. Nota: RAV AntiVirus poate sa nu detecteze toti virusii noi sau toate variantele lor. Va rugam sa luati in considerare ca exista un risc de fiecare data cand deschideti fisiere atasate si ca MobiFon nu este responsabila pentru nici un prejudiciu cauzat de virusi. Disclaimer: RAV AntiVirus may not be able to detect all new viruses and variants. Please be aware that there is a risk involved whenever opening e-mail attachments to your computer and that MobiFon is not responsible for any damages caused by viruses. From roberto@meuprovedor.com.br Thu Aug 29 12:03:22 2002 From: roberto@meuprovedor.com.br (Roberto Campos) Date: Thu, 29 Aug 2002 08:03:22 -0300 Subject: RES: [LARTC] Help with tc TBF filter In-Reply-To: <001b01c24eae$fac53760$6564a8c0@mello> Message-ID: <00c401c24f4b$b4c66e80$0500a8c0@escritoriomundial.com.br> Hi, I just want to know if HTB is alredy in stock kernel or if I have do recompile the kernel for it to work. Thanks. Roberto Campos _______________________________________________________________ Meu Provedor Tecnologias e Informatica ltda. Rua Camerino, 128 Gr. 302 - Centro Rio de Janeiro - RJ - CEP 20080-010 Tel.: 21 - 25181011 Fax: 21 - 25181911 From voyo@punkt.pl Thu Aug 29 13:07:08 2002 From: voyo@punkt.pl (Wojtek) Date: Thu, 29 Aug 2002 14:07:08 +0200 Subject: [LARTC] how to force iproute2 to FORWARD to another interface packets with a destinatioin IP on this machine? References: Message-ID: <3D6E0E6C.6070908@punkt.pl> Jan Macek wrote: > I have this situation: > > My machine debina, has three interfaces: > > eth1 212.126.24.129 > ppp0 10.2.0.1 (Point-to-Point: 212.31.242.98) > nsc5 10.2.0.250 (Point-to-Point: 172.23.140.32) > > > I want packets which come in through the nsc5 interface, to be FORWARDED > to the ppp0 interface to 212.31.242.98, even when their destination > address is 212.126.24.129 (even so this is the IP of eth1 on this > machine). > > How to achieve that? > you can use set of 'ip rule' and other routing table From stef.coene@docum.org Thu Aug 29 13:53:44 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 14:53:44 +0200 Subject: [LARTC] htb guarantee bandwidth In-Reply-To: <3D6DE126.6020704@promo.ro> References: <02082912495300.01420@sanitarium> <3D6DE126.6020704@promo.ro> Message-ID: <200208291453.44399.stef.coene@docum.org> On Thursday 29 August 2002 10:53, Ciprian Niculescu wrote: > hi, > > you give to all the clients all the bandwith or limited at 64k, but wit= h > different priorities. > > class parent 1: classid 1:5 htb rate 128kbit > class parent 1:5 classid 1:1 htb rate 64kbit ceil 128kbit prio 1 > class parent 1:5 classid 1:2 htb rate 64kbit ceil 128kbit prio 2 > > you put the client that you want to have guaranted 64kbps in 1:1, and > the other two in 1:2. The prio is only used to split the traffic that's available after the rat= es=20 are satisfied. In this case, the prio will change nothing. But if you h= ave=20 3 classes like : class parent 1: classid 1:5 htb rate 128kbit class parent 1:5 classid 1:1 htb rate 32kbit ceil 128kbit prio 1 class parent 1:5 classid 1:2 htb rate 32kbit ceil 128kbit prio 1 class parent 1:5 classid 1:3 htb rate 64kbit ceil 128kbit prio 2 and class 1:1 uses no bandwidth. Class 1:2 will get 32kbit, class 1:3 64= kbit,=20 so 32 kbit left. Class 1:2 has the lowest prio, so it will get the remai= ning=20 32kbit. So each class gets 64 kbit. The rate for a class is always guaranteed. So you don't need an isolated= =20 option like in cbq. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Thu Aug 29 13:54:12 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 14:54:12 +0200 Subject: RES: [LARTC] Help with tc TBF filter In-Reply-To: <00c401c24f4b$b4c66e80$0500a8c0@escritoriomundial.com.br> References: <00c401c24f4b$b4c66e80$0500a8c0@escritoriomundial.com.br> Message-ID: <200208291454.12591.stef.coene@docum.org> On Thursday 29 August 2002 13:03, Roberto Campos wrote: > Hi, > > I just want to know if HTB is alredy in stock kernel or if I have do > recompile the kernel for it to work. It will be in kernel 2.4.20. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mage@adamant.net Thu Aug 29 14:15:04 2002 From: mage@adamant.net (Alexander Trotsai) Date: Thu, 29 Aug 2002 16:15:04 +0300 Subject: [LARTC] masq vs snat Message-ID: <20020829131503.GD1710@blackhole.adamant.ua> Hi all Is snat /x -> 1IP equal to masquerade? If I want specify address for masquerade, could I use snat for this? -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] From voyo@punkt.pl Thu Aug 29 14:17:55 2002 From: voyo@punkt.pl (Wojtek) Date: Thu, 29 Aug 2002 15:17:55 +0200 Subject: [LARTC] how to log pacets which hit routing rules? References: Message-ID: <3D6E1F03.9020305@punkt.pl> Jan Macek wrote: > Hi, > > Is there some way to make iproute2 log to syslog or to a file selected > packets? > > I have a problem, that my packets dissapear somewhere, and I want to be > sure if they get to the routing stage or not, and where do they get > routed. > > use the iptables or ipchains with --log switch From stef.coene@docum.org Thu Aug 29 14:08:10 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 15:08:10 +0200 Subject: [LARTC] HTB equivalent for 'bounded' and 'isolated' in CBQ In-Reply-To: References: Message-ID: <200208291508.10250.stef.coene@docum.org> > It works fine for me, although I haven't used CBQ previously so I can't > comapre them. It just works for me, except the delays in interactive cl= ass > are too long, even when the prio is 0 (highest) and the rate and ceil a= re > maximum. Maybe CBQ is better in reducing the delays... Anybody solved t= his > problem? There is a way with htb to get really low delays. It can be found on the= htb=20 homepage (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio, last=20 paragraph). =20 Basically, you have 2 classes : on rated to xx% of the link and an other = rated=20 to 100-X%. If you make sure you NEVER send more data to the 100-xx% clas= s so=20 it never has to ask for more bandwidth, it will have very low delays. If= you=20 send more data, the situation is reversed and that class will get very hi= gh=20 delays. I still have to test it, but you can use the policer in the filt= ers=20 to make sure you never send more data then the rate of the class. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From robert.penz@outertech.com Thu Aug 29 14:37:59 2002 From: robert.penz@outertech.com (Robert Penz) Date: Thu, 29 Aug 2002 15:37:59 +0200 Subject: [LARTC] HTB: messages in my log Message-ID: <200208291538.00177.robert.penz@outertech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm getting following messages in my log, don't know what I'm doing wrong= =2E I have that messages on 2.419 and 20pre1 first call of my TC script, after the boot Aug 29 14:30:06 whitestar kernel: HTB init, kernel part version 3.6 Aug 29 14:30:06 whitestar kernel: HTB: quantum of class 10001 is big. Con= sider=20 r2q change.<4>HTB: quantum of class 10010 is big. Consider r2q change.<6>= HTB=20 init, kernel part version 3.6 second call Aug 29 15:35:25 whitestar kernel: HTB: quantum of class 10001 is big. Con= sider=20 r2q change.<4>HTB: quantum of class 10010 is big. Consider r2q=20 change.<7>htb*g j=3D1476817 Aug 29 15:35:25 whitestar kernel: HTB init, kernel part version 3.6 Aug 29 15:35:25 whitestar kernel: HTB: quantum of class 10001 is big. Con= sider=20 r2q change.<4>HTB: quantum of class 10010 is big. Consider r2q change.<6>= HTB=20 init, kernel part version 3.6 here is my script #!/bin/bash # Written by Robert Penz (robert.penz@outertech.com) # Script is under GPL # Thx for the help goes to the Linux Advanced Routing & Traffic Control H= OWTO # at http://lartc.org/HOWTO//cvs/2.4routing/lartc.html # and http://www.docum.org/ and http://luxik.cdi.cz/~patrick/imq/index.ht= ml #=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # # all in Mbit # $1 =3D max bandwidth down # $2 =3D max bandwidth up # first check the parameter [ -z "$1" ] && echo "parameter 1 missing" && exit 1 [ -z "$2" ] && echo "parameter 2 missing" && exit 1 if [ -n "`tc -s qdisc ls dev imq0 | grep "htb"`" ] ; then tc qdisc del dev imq0 root handle 1:0 tc qdisc del dev eth0 root handle 1:0 echo old stuff killed fi # start with the download stuff # we use htb tc qdisc add dev eth0 root handle 1: htb default 10 # 100mbit nic tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit # 80mbit is just a fake value, the ceil value is more important tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80mbit ceil 100mbi= t # traffic shaping to $1 mbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate $1mbit # we use sfq for all tc qdisc add dev eth0 parent 1:10 handle 30:0 sfq tc qdisc add dev eth0 parent 1:11 handle 40:0 sfq ## now call the filters # put the capped marked stuff into that chain, uncapped is default so we = don't # need to do anythink # mark with -j MARK --set-mark 1 tc filter add dev eth0 protocol ip pref 1 parent 1: handle 1 fw classid 1= :11 ## continue with the upload stuff # we use HTB # all traffic to this device is to the ip 141 .. put it by default into t= he TC tc qdisc add dev imq0 handle 1: root htb default 10 # 100mbit virtual nic tc class add dev imq0 parent 1: classid 1:1 htb rate 100mbit # 80mbit is just a fake value, the ceil value is more important tc class add dev imq0 parent 1:1 classid 1:10 htb rate 80mbit ceil 100mbi= t # traffic shaping to $2 tc class add dev imq0 parent 1:1 classid 1:11 htb rate $2Mbit # we use sfq for both tc qdisc add dev imq0 parent 1:10 handle 30:0 sfq tc qdisc add dev imq0 parent 1:11 handle 40:0 sfq ## now call the filters # put the capped marked stuff into that chain, uncapped is default so we = don't # need to do anythink # mark with -j MARK --set-mark 2 tc filter add dev imq0 protocol ip pref 2 parent 1: handle 2 fw classid 1= :11 ## bring up the imq virtual nic ip link set imq0 up - --=20 Regards, Robert - ---------------- Robert Penz robert.penz@outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9biO48tTsQqJDUBMRAgxKAJwKbnPrqDbfl4Il6OGXyQc0CGkGHgCgl16J FxcZjs4+Rovn92EWiR8c2tA=3D =3Dr2/R -----END PGP SIGNATURE----- From stef.coene@docum.org Thu Aug 29 14:48:33 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 15:48:33 +0200 Subject: [LARTC] HTB: messages in my log In-Reply-To: <200208291538.00177.robert.penz@outertech.com> References: <200208291538.00177.robert.penz@outertech.com> Message-ID: <200208291548.33402.stef.coene@docum.org> On Thursday 29 August 2002 15:37, Robert Penz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I'm getting following messages in my log, don't know what I'm doing wro= ng. > I have that messages on 2.419 and 20pre1 > > first call of my TC script, after the boot > > Aug 29 14:30:06 whitestar kernel: HTB init, kernel part version 3.6 > Aug 29 14:30:06 whitestar kernel: HTB: quantum of class 10001 is big. > Consider r2q change.<4>HTB: quantum of class 10010 is big. Consider r2q > change.<6>HTB init, kernel part version 3.6 > > second call > > Aug 29 15:35:25 whitestar kernel: HTB: quantum of class 10001 is big. > Consider r2q change.<4>HTB: quantum of class 10010 is big. Consider r2q > change.<7>htb*g j=3D1476817 > Aug 29 15:35:25 whitestar kernel: HTB init, kernel part version 3.6 > Aug 29 15:35:25 whitestar kernel: HTB: quantum of class 10001 is big. > Consider r2q change.<4>HTB: quantum of class 10010 is big. Consider r2q > change.<6>HTB init, kernel part version 3.6 All you have to do is chaning r2q so quantum is smaller :) Quantum is the amount of bytes a class may send when 2 classes are fighti= ng=20 for excess bandwidth. When quantum is too big, it can create extra burst= s. =20 When quantum is too small (smaller then 1 packet) it can will disturb the= htb=20 calculations. quantum =3D rate / r2q with r2q =3D 10 (can be overruled when you add a qdisc) Solution :=20 r2q =3D smallest_rate_you_have / 1500 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From robert.penz@outertech.com Thu Aug 29 15:00:18 2002 From: robert.penz@outertech.com (Robert Penz) Date: Thu, 29 Aug 2002 16:00:18 +0200 Subject: [LARTC] HTB: messages in my log In-Reply-To: <200208291548.33402.stef.coene@docum.org> References: <200208291538.00177.robert.penz@outertech.com> <200208291548.33402.stef.coene@docum.org> Message-ID: <200208291559.53664.robert.penz@outertech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > All you have to do is chaning r2q so quantum is smaller :) ok, I've done that, set r2q to 60, but still the same message, my problem= is also that I don't know a class 10010 now my qdisc line looks that way tc qdisc add dev eth0 root handle 1: htb default 10 r2q 60 - -- Regards, Robert - ---------------- Robert Penz robert.penz@outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9bijy8tTsQqJDUBMRAq7OAKCCmYs9GrDntAXBFIq8ncdAJMjSFQCdEX1V tUq54Ojsmd4K+fdIe61nEBY=3D =3DEOE7 -----END PGP SIGNATURE----- From stef.coene@docum.org Thu Aug 29 15:17:28 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 16:17:28 +0200 Subject: [LARTC] HTB: messages in my log In-Reply-To: <200208291559.53664.robert.penz@outertech.com> References: <200208291538.00177.robert.penz@outertech.com> <200208291548.33402.stef.coene@docum.org> <200208291559.53664.robert.penz@outertech.com> Message-ID: <200208291617.28331.stef.coene@docum.org> On Thursday 29 August 2002 16:00, Robert Penz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > All you have to do is chaning r2q so quantum is smaller :) > > ok, I've done that, set r2q to 60, but still the same message, my probl= em > is also that I don't know a class 10010 That's an internal number. > now my qdisc line looks that way > > tc qdisc add dev eth0 root handle 1: htb default 10 r2q 60 The biggest quantum allowed is 60000 (I think). So if you calculate all=20 quantums, make sure none of them is bigger then 60000. or smaller then 15= 00 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From lartc@24x7linux.com Thu Aug 29 16:07:27 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Thu, 29 Aug 2002 17:07:27 +0200 Subject: [LARTC] masq vs snat In-Reply-To: <20020829131503.GD1710@blackhole.adamant.ua> References: <20020829131503.GD1710@blackhole.adamant.ua> Message-ID: <20020829150727.GA4752@localhost> On Thursday, 29 August 2002, at 16:15:04 +0300, Alexander Trotsai wrote: > Is snat /x -> 1IP equal to masquerade? If I want specify > address for masquerade, could I use snat for this? > As far as I know (and from what iptables manpage says) MASQ is similar to SNAT with just a single source IP address to choose from, with the addition that all connections MASQed through this interface are lost (forgotten to be precise) when the interface goes down. This should happen when you redial your ISP and get a new IP or when DHCP leases you a different IP address. In any case, your IP changes and there is no point keeping state for connections that will never succeed any more. My firts post to the list, hopefully not the last :-) -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From Nils.Lichtenfeld@gmx.net Thu Aug 29 16:40:27 2002 From: Nils.Lichtenfeld@gmx.net (Nils Lichtenfeld) Date: Thu, 29 Aug 2002 17:40:27 +0200 Subject: [LARTC] Confusion about kernelconfig QoS-options Message-ID: <01bb01c24f72$685d5b90$9605a8c0@Gundy> Hello there! Using Kernel 2.4.19. The modules I intend to use are SFQ queue, HTB packet scheduler, Firewall based classifier and the U32 classifier. Witch of the following options _NEED_ to be enabled? I ask, because the goal is to have the kernel as small as possible. < QOS and/or fair queueing > [*] QoS support [*] Rate estimator [*] Traffic policing Thank you! Greetings, Nils From stef.coene@docum.org Thu Aug 29 17:04:30 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 18:04:30 +0200 Subject: [LARTC] Confusion about kernelconfig QoS-options In-Reply-To: <01bb01c24f72$685d5b90$9605a8c0@Gundy> References: <01bb01c24f72$685d5b90$9605a8c0@Gundy> Message-ID: <200208291804.30819.stef.coene@docum.org> On Thursday 29 August 2002 17:40, Nils Lichtenfeld wrote: > Hello there! > > Using Kernel 2.4.19. > > The modules I intend to use are SFQ queue, HTB packet scheduler, > Firewall based classifier and the U32 classifier. > > Witch of the following options _NEED_ to be enabled? I ask, because the > goal is to have the kernel as small as possible. Then use modules and load only the modules you need. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Nils.Lichtenfeld@gmx.net Thu Aug 29 17:25:13 2002 From: Nils.Lichtenfeld@gmx.net (Nils Lichtenfeld) Date: Thu, 29 Aug 2002 18:25:13 +0200 Subject: [LARTC] Confusion about kernelconfig QoS-options References: <01bb01c24f72$685d5b90$9605a8c0@Gundy> <200208291804.30819.stef.coene@docum.org> Message-ID: <01d401c24f78$ad525880$9605a8c0@Gundy> Hi Stef! Stef Coene schrieb: >> Witch of the following options _NEED_ to be enabled? I ask, because >> the goal is to have the kernel as small as possible. > Then use modules and load only the modules you need. That was not my question. The listed items are not selectable as modules. They can only be compiled into the kernel or turned off. I list them again, they reside in the < QOS and/or fair queueing > section: [*] QoS support [*] Rate estimator [*] Traffic policing "*" is the default selection. Thank you! Greetings, Nils From stef.coene@docum.org Thu Aug 29 17:50:32 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Aug 2002 18:50:32 +0200 Subject: [LARTC] Confusion about kernelconfig QoS-options In-Reply-To: <01d401c24f78$ad525880$9605a8c0@Gundy> References: <01bb01c24f72$685d5b90$9605a8c0@Gundy> <200208291804.30819.stef.coene@docum.org> <01d401c24f78$ad525880$9605a8c0@Gundy> Message-ID: <200208291850.32778.stef.coene@docum.org> On Thursday 29 August 2002 18:25, Nils Lichtenfeld wrote: > Hi Stef! > > Stef Coene schrieb: > >> Witch of the following options _NEED_ to be enabled? I ask, because > >> the goal is to have the kernel as small as possible. > > > > Then use modules and load only the modules you need. > > That was not my question. The listed items are not selectable as > modules. They can only be compiled into the kernel or turned off. I lis= t > them again, they reside in the < QOS and/or fair queueing > section: > > [*] QoS support Only needed if you want to implement QOS support so other devices on the=20 network can send requestst for bandwidth. > [*] Rate estimator This can be used for the "Traffic policing" to calculate the rate of the=20 packets. > [*] Traffic policing This is sort of tbf-in-filter. You can configure a filter to only match=20 packets at a certain rate. You don't need these options to use SFQ, HTB, fw and/or u32. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Nils.Lichtenfeld@gmx.net Thu Aug 29 18:12:49 2002 From: Nils.Lichtenfeld@gmx.net (Nils Lichtenfeld) Date: Thu, 29 Aug 2002 19:12:49 +0200 Subject: [LARTC] Confusion about kernelconfig QoS-options References: <200208291850.32778.stef.coene@docum.org> Message-ID: <01db01c24f7f$4e018ac0$9605a8c0@Gundy> Hello Stef! Stef Coene schrieb: > On Thursday 29 August 2002 18:25, Nils Lichtenfeld wrote: >> That was not my question. The listed items are not selectable as >> modules. They can only be compiled into the kernel or turned off. I >> list them again, they reside in the < QOS and/or fair queueing > >> section: >> >> [*] QoS support > Only needed if you want to implement QOS support so other devices on > the network can send requestst for bandwidth. > >> [*] Rate estimator > This can be used for the "Traffic policing" to calculate the rate of > the packets. > >> [*] Traffic policing > This is sort of tbf-in-filter. You can configure a filter to only > match packets at a certain rate. > > You don't need these options to use SFQ, HTB, fw and/or u32. Thank you very, very mutch! This is exactly the information I was hoping for. Greetings, Gundy From esteban.maringolo@secont.com.ar Fri Aug 30 18:59:54 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 30 Aug 2002 14:59:54 -0300 Subject: [LARTC] Old linuxbox as BwM Message-ID: <1030730395.759.48.camel@sico> --=-Z7plGNizlpwk9urljaWt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I'm playing with tc, htb, and other QoS features on an old pc I have. The PC runs, by now, a shrinked version of Debian Woody, with patched versions of kernel 2.4.18 and iproute in order to support HTB. What i'm wondering is if with a AMD 100Mhz (stealed from a museum ;-), 16Mbps RAM i can do bandwidth management to 20 network hosts, which connect wirelessly (not all, but mostly of these) sharing a wireless link of 800 kbps (kbit in tc grammar) and i'm simulating an external interfase of 256 kbps.=20 The ASCII art is as follows: ____________ e0| |e1 ____ _________ to client --------| Linuxbox |----|HUB |----|Wireless | 800kbps devices | 100MHz16MB | |____| |AP | ) ) ) ) (PC,Hheld) |____________| | |_________| | `------ Wired Network Where e0 and e1 means eth0 and eth1. eth0 works at 256kbps, and eth1 might receive traffic at 800kbps as much (from Wireless Access Point) or at 10mbps from the wired network. ------- is wire cable ) ) ) ) is air link (aka wireless) All this stuff is just for asking if i could use the "old museum" AMD 100MHz for BwM of 800 kbps average traffic. This old PC also works as testbed for mi diskless linux test (ramdisks, initrd setups, etc) so, it is possible that it will work with only 8MB of RAM if I use 8MB for the ramdisk. So, consider both cases (8 and 16 of RAM). Thanks. =09 --=20 Esteban A. Maringolo Buenos Aires, Argentina --=-Z7plGNizlpwk9urljaWt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9b7KaDY8wt+MWh9ARAq2uAJwPtzbDpuXCdVNQpvxczknMyMYiXQCfeNnZ x9rKSvvkOx+ZyooE9s1OoTI= =uli8 -----END PGP SIGNATURE----- --=-Z7plGNizlpwk9urljaWt-- From james+lartc@vincentsystems.com Thu Aug 29 21:39:23 2002 From: james+lartc@vincentsystems.com (James Sneeringer) Date: Thu, 29 Aug 2002 15:39:23 -0500 Subject: [LARTC] how to log pacets which hit routing rules? In-Reply-To: <3D6E1F03.9020305@punkt.pl> References: <3D6E1F03.9020305@punkt.pl> Message-ID: <20020829203923.GB27986@valjean.si.ocslink.com> On Thu, Aug 29, 2002 at 03:17:55PM +0200, Wojtek wrote: | Jan Macek wrote: | >Is there some way to make iproute2 log to syslog or to a file selected | >packets? | | use the iptables or ipchains with --log switch iptables does not have a --log switch. You must use the '-j LOG' target instead. -James From marcus@ingate.com Thu Aug 29 21:40:01 2002 From: marcus@ingate.com (Marcus Sundberg) Date: 29 Aug 2002 22:40:01 +0200 Subject: [LARTC] Weird(?) HTB3 setup Message-ID: Hi, I want to be able to specify actions for different classes of traffic in any of these four ways, and I'd like to use only HTB if possible: 1. No guranteed rate, No ceil 2. Guaranteed rate, No ceil 3. No guranteed rate, Ceil specified 4. Guaranteed rate, Ceil specified For types 2, 3 and 4 there can be several classes of each, with different rates and ceilings. 4 is ofcourse easy. 2 is also easy - just set ceil to the ceil of the parent class. But I'm not sure whether 1 can be accomplished with this: > there is build-in passthru class named X:0 where X is your > handle. Simply set "default 0" when creating htb and all > unclassified packets will go directly thru. > devik Does "go directly thru" mean that unclassified packets are sent *before* packets belonging to a class with a guarateed rate? Or does it mean that unclassified packets get sent when there is bandwidth to spare (which is what I want) ? And what about lending? In what proportion does this "passthru class" lend bandwidth compared to other classes? And for 3 I have no idea if it's possible using only HTB? Setting rate to 0 doesn't work. //Marcus -- ---------------------------------------+-------------------------- Marcus Sundberg | Firewalls with SIP & NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/ From ahu@ds9a.nl Thu Aug 29 22:19:49 2002 From: ahu@ds9a.nl (bert hubert) Date: Thu, 29 Aug 2002 23:19:49 +0200 Subject: [LARTC] Old linuxbox as BwM In-Reply-To: <1030730395.759.48.camel@sico> References: <1030730395.759.48.camel@sico> Message-ID: <20020829211949.GA1134@outpost.ds9a.nl> On Fri, Aug 30, 2002 at 02:59:54PM -0300, Esteban Maringolo wrote: > Hello, > > I'm playing with tc, htb, and other QoS features on an old pc I have. > The PC runs, by now, a shrinked version of Debian Woody, with patched > versions of kernel 2.4.18 and iproute in order to support HTB. > > What i'm wondering is if with a AMD 100Mhz (stealed from a museum ;-), > 16Mbps RAM i can do bandwidth management to 20 network hosts, which > connect wirelessly (not all, but mostly of these) sharing a wireless > link of 800 kbps (kbit in tc grammar) and i'm simulating an external > interfase of 256 kbps. No problem. -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From stef.coene@docum.org Fri Aug 30 07:04:02 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 30 Aug 2002 08:04:02 +0200 Subject: [LARTC] Weird(?) HTB3 setup In-Reply-To: References: Message-ID: <200208300804.02773.stef.coene@docum.org> > I want to be able to specify actions for different classes of > traffic in any of these four ways, and I'd like to use only > HTB if possible: > > 1. No guranteed rate, No ceil > 2. Guaranteed rate, No ceil > 3. No guranteed rate, Ceil specified > 4. Guaranteed rate, Ceil specified What do you mean with no ceil? Do you mean that the classes can send at = full=20 device speed? Then the ceil =3D device speed. For htb, no ceil means ce= il =3D=20 rate. No guaranteed rate can be simulated by creating 2 classes : root class rate =3D cail =3D 100 % class 1 =3D rate 1%, ceil 100% class 2 =3D rate 99%, ceil 100% Class 1 will have (allmost) no guaranteed bandwidth. In worst case senar= io,=20 it get's only 1 % of the bandwidth. But if class 2 uses only 20%, class = 1=20 can get's the remaining 80%. Of course you can change the ceil to match = case=20 3. > For types 2, 3 and 4 there can be several classes of each, with > different rates and ceilings. > > 4 is ofcourse easy. 2 is also easy - just set ceil to the ceil of > the parent class. But I'm not sure whether 1 can be accomplished > with this: > > there is build-in passthru class named X:0 where X is your > > handle. Simply set "default 0" when creating htb and all > > unclassified packets will go directly thru. > > devik > > Does "go directly thru" mean that unclassified packets are sent > *before* packets belonging to a class with a guarateed rate? Or > does it mean that unclassified packets get sent when there is > bandwidth to spare (which is what I want) ? And what about lending? > In what proportion does this "passthru class" lend bandwidth compared > to other classes? It means that all the packets will get sended as fast as the hardware can= =2E =20 The packets will end up in the queue just before the device so they can e= at=20 bandwidth from other classes (and that's not what you want). =20 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From nberg@gandalf.xs4all.nl Fri Aug 30 09:32:32 2002 From: nberg@gandalf.xs4all.nl (Nico Berg) Date: Fri, 30 Aug 2002 10:32:32 +0200 Subject: [LARTC] 4 ipadresses only one working In-Reply-To: <200208300804.02773.stef.coene@docum.org> Message-ID: Dear listreaders, This is about my last hope! I'm new to this list. Running Suse Linux 8 (for shortly installed over 7.2) I have an adsl connection and can loggin 4 times. Every time I loggin at my ISP I get an ipadres. So I own 4 ipadresses. Only this first adress is working. The other 3 are connected, can do a tcpdump and see reaction's only the one who is pinging doesn't get an reaction. So, apperently the machine doesn't react to this ipadresses because they are not in the system or so???? I put in a piece tcpdump. tcpdump: listening on ppp1 14:37:42.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:43.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:44.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:45.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:46.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:47.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:48.123230 194.109.6.44 > 213.84.46.145: icmp: echo request Reaction from the ping adres PING 213.84.46.145 (213.84.46.145): 56 data bytes ^C --- 213.84.46.145 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss I can ping from my intern network then it works normal with a normal reaction. I have a server (the machine discused above) and 4 machine getting there internetaccess from the server with iptables. #!/bin/sh # Masquerading firewall (simpel) # 13 augustus 2001 # Bart Geverts (bart@hakkefest.linux-site.net) # Een hele eenvoudige masquerading firewall waarmee het mogelijk om met het # hele achterliggende LAN het internet op te kunnen. Het 'firewall' gedeelte # bestaat uit het afsluiten van een aantal poorten waarop relatief riskante # servers draaien. Alleen de variabelen moeten aan de omgeving worden aangepast. ############################################################################ #### # variabelen # waar iptables staat IPTABLES="/usr/sbin/iptables" # interfaces INTERNAL_INTERFACE="eth1" # interface waarmee gateway aan lokale netwerk zit EXTERNAL_INTERFACE="ppp+" # interface waarmee gateway aan het internet zit #EXTERNAL_INTERFACE2="ppp1" # tweede ipnr #EXTERNAL_INTERFACE3="ppp2" # derde #EXTERNAL_INTERFACE4="ppp3" # vierde # ipadressen / netwerken LAN="196.168.0.1/24" # lokale netwerk # ip nummers #IP_nr_1="213.84.46.144" #IP_nr_2="213.84.46.145" #IP_nr_3="213.84.46.146" #IP_nr_4="213.84.46.147" ############################################################################ #### # clean-up + init # flush en clear alle rules en zet de tellers op 0 $IPTABLES -F $IPTABLES -X $IPTABLES -Z $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t nat -Z # set de default policies $IPTABLES -P INPUT ACCEPT $IPTABLES -P FORWARD ACCEPT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -t nat -P PREROUTING ACCEPT $IPTABLES -t nat -P POSTROUTING ACCEPT $IPTABLES -t nat -P OUTPUT ACCEPT ############################################################################ #### # initialiseren van de kernel ## Enable IP forwarding echo 1 > /proc/sys/net/ipv4/ip_forward ############################################################################ #### # masquerade ## Alles met afkomst van of bestemming lokale netwerk heeft forwarden $IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_INTERFACE -j MASQUERADE $IPTABLES -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LAN -d ! $LAN -j ACCEPT $IPTABLES -A FORWARD -o $INTERNAL_INTERFACE -i $EXTERNAL_INTERFACE -d $LAN -s ! $LAN -j ACCEPT ############################################################################ ##### Tweede IPnr #$IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_INTERFACE_2 - MASQUERADE #$IPTABLES -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE2 -s $LAN -d ! $LAN -j ACCEPT #$IPTABLES -A FORWARD -o $INTERNAL_INTERFACE -i $EXTERNAL_INTERFACE2 -d $LAN -s ! $LAN -j ACCEPT #$IPTABLES -A INPUT -i $EXTERNAL_INTERFACE_2 -j ACCEPT #$IPTABLES -A OUTPUT -o $EXTERNAL_INTERFACE_2 -j ACCEPT ############################################################################ #### # riskante servers afsluiten ## telnet afsluiten voor de buitenwereld $IPTABLES -A INPUT -p tcp --destination-port 23 -i $EXTERNAL_INTERFACE -j DROP # #$IPTABLES -L If my ipadresses working properly then I want to extend the firewallscript to a normal working firewall (in the mean time I have updated my swiss cheese to a normal functional firewall). I hope somebody can help me out here and tell me how to (I think Postrouting or so) my 3 adresses. If there is somebody interested I have put a lot of information on a webpages and publised it on the first ipadres: http://gandalf.xs4all.nl/Suse.html So please help! Greetings, Nico Berg From niels@wxn.nl Fri Aug 30 10:22:58 2002 From: niels@wxn.nl (niels@wxn.nl) Date: Fri, 30 Aug 2002 11:22:58 +0200 Subject: [LARTC] 4 ipadresses only one working Message-ID: <4FACD13E65E34440B01491D90EDE966A26C5E8@hq-exchange.hq.nl> Try to run /sbin/ifconfig... It show's the IP adresses your interfaces have... has your interface all those 4 adresses? I think not... If not you should "add" those IP adresses to the interface Try something like this: #ip addr add 213.84.46.145/24 dev ppp+ broadcast 213.84.46.255 After that you should proxy-ARP or SNAT them to another machine on the internal network (or better DMZ) because I don't see the advantage of running more than one IP adress on the linux box itself -----Original Message----- From: Nico Berg [mailto:nberg@gandalf.xs4all.nl] Sent: 30 August 2002 10:33 To: lartc@mailman.ds9a.nl Subject: [LARTC] 4 ipadresses only one working Dear listreaders, This is about my last hope! I'm new to this list. Running Suse Linux 8 (for shortly installed over 7.2) I have an adsl connection and can loggin 4 times. Every time I loggin at my ISP I get an ipadres. So I own 4 ipadresses. Only this first adress is working. The other 3 are connected, can do a tcpdump and see reaction's only the one who is pinging doesn't get an reaction. So, apperently the machine doesn't react to this ipadresses because they are not in the system or so???? I put in a piece tcpdump. tcpdump: listening on ppp1 14:37:42.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:43.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:44.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:45.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:46.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:47.123230 194.109.6.44 > 213.84.46.145: icmp: echo request 14:37:48.123230 194.109.6.44 > 213.84.46.145: icmp: echo request Reaction from the ping adres PING 213.84.46.145 (213.84.46.145): 56 data bytes ^C --- 213.84.46.145 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss I can ping from my intern network then it works normal with a normal reaction. I have a server (the machine discused above) and 4 machine getting there internetaccess from the server with iptables. #!/bin/sh # Masquerading firewall (simpel) # 13 augustus 2001 # Bart Geverts (bart@hakkefest.linux-site.net) # Een hele eenvoudige masquerading firewall waarmee het mogelijk om met het # hele achterliggende LAN het internet op te kunnen. Het 'firewall' gedeelte # bestaat uit het afsluiten van een aantal poorten waarop relatief riskante # servers draaien. Alleen de variabelen moeten aan de omgeving worden aangepast. ############################################################################ #### # variabelen # waar iptables staat IPTABLES="/usr/sbin/iptables" # interfaces INTERNAL_INTERFACE="eth1" # interface waarmee gateway aan lokale netwerk zit EXTERNAL_INTERFACE="ppp+" # interface waarmee gateway aan het internet zit #EXTERNAL_INTERFACE2="ppp1" # tweede ipnr #EXTERNAL_INTERFACE3="ppp2" # derde #EXTERNAL_INTERFACE4="ppp3" # vierde # ipadressen / netwerken LAN="196.168.0.1/24" # lokale netwerk # ip nummers #IP_nr_1="213.84.46.144" #IP_nr_2="213.84.46.145" #IP_nr_3="213.84.46.146" #IP_nr_4="213.84.46.147" ############################################################################ #### # clean-up + init # flush en clear alle rules en zet de tellers op 0 $IPTABLES -F $IPTABLES -X $IPTABLES -Z $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t nat -Z # set de default policies $IPTABLES -P INPUT ACCEPT $IPTABLES -P FORWARD ACCEPT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -t nat -P PREROUTING ACCEPT $IPTABLES -t nat -P POSTROUTING ACCEPT $IPTABLES -t nat -P OUTPUT ACCEPT ############################################################################ #### # initialiseren van de kernel ## Enable IP forwarding echo 1 > /proc/sys/net/ipv4/ip_forward ############################################################################ #### # masquerade ## Alles met afkomst van of bestemming lokale netwerk heeft forwarden $IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_INTERFACE -j MASQUERADE $IPTABLES -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LAN -d ! $LAN -j ACCEPT $IPTABLES -A FORWARD -o $INTERNAL_INTERFACE -i $EXTERNAL_INTERFACE -d $LAN -s ! $LAN -j ACCEPT ############################################################################ ##### Tweede IPnr #$IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_INTERFACE_2 - MASQUERADE #$IPTABLES -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE2 -s $LAN -d ! $LAN -j ACCEPT #$IPTABLES -A FORWARD -o $INTERNAL_INTERFACE -i $EXTERNAL_INTERFACE2 -d $LAN -s ! $LAN -j ACCEPT #$IPTABLES -A INPUT -i $EXTERNAL_INTERFACE_2 -j ACCEPT #$IPTABLES -A OUTPUT -o $EXTERNAL_INTERFACE_2 -j ACCEPT ############################################################################ #### # riskante servers afsluiten ## telnet afsluiten voor de buitenwereld $IPTABLES -A INPUT -p tcp --destination-port 23 -i $EXTERNAL_INTERFACE -j DROP # #$IPTABLES -L If my ipadresses working properly then I want to extend the firewallscript to a normal working firewall (in the mean time I have updated my swiss cheese to a normal functional firewall). I hope somebody can help me out here and tell me how to (I think Postrouting or so) my 3 adresses. If there is somebody interested I have put a lot of information on a webpages and publised it on the first ipadres: http://gandalf.xs4all.nl/Suse.html So please help! Greetings, Nico Berg _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From AClara@strategyconsultors.com Fri Aug 30 11:30:27 2002 From: AClara@strategyconsultors.com (AClara@strategyconsultors.com) Date: Fri, 30 Aug 2002 12:30:27 +0200 Subject: [LARTC] Problem with nexthop and gets dead Message-ID: SGVsbG8sDQoNCldlIGhhdmUgZGViaWFuIHdpdGggMi40LjE5LXByZTgga2VybmVsDQpXZSBhY3Rp dmUgdGhlIGxvYWQgYmFsYW5jaW5nIHdpdGggdHdvIGV0aGVybmV0cyB0byBpbnRlcm5ldCwgd2lo IHRoZQ0KY29tbWFuZDoNCg0KICAgICAgICBpcCBydWxlIGFkZCBmcm9tIDEyOC4xLjMuMS8zMiBs b29rdXAgaG9zdF9wcm94eSBwcmVmZXJlbmNlIDIwNjANCiAgICAgICAgaXAgcm91dGUgYWRkIGRl ZmF1bHQgdGFibGUgaG9zdF9wcm94eSBwcm90byBzdGF0aWMgbmV4dGhvcCB2aWENCjgwLjI1LjE3 NS4xIGRldiBldGgwIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBuZXh0aG9wIHZpYQ0KMjEyLjE3MC4xNC4xIGRldiBldGgxDQoNCndoZW4gc2Vl IHRoZSByb3V0ZSB3aXRoIGlwIHJvdXRlIGxpc3QgdGFibGUgaG9zdF9wcm94eSwgZ2V0cyA6DQoN CmRlZmF1bHQgIHByb3RvIHN0YXRpYw0KICAgICAgICBuZXh0aG9wIHZpYSA4MC4yNS4xNzUuMSAg ZGV2IGV0aDAgd2VpZ2h0IDEgZGVhZA0KICAgICAgICBuZXh0aG9wIHZpYSAyMTIuMTcwLjE0LjEg IGRldiBldGgxIHdlaWdodCAxDQoNCmF0IHRoZSBlbmQgdGhlIGxvYWQgYmFsYW5jaW5nIGRvZXNu dCB3b3JrLCB0aGUgcGluZyB0byA4MC4yNS4xNzUuMSBhbmQNCjIxMi4xNzAuMTQuMSB3b3JrcyAh ISEhDQoNCkhhdmUgYW55IGlkZWE/IFdoeSBzYWlkIGRlYWQgaWYgdGhlIGlwJ3MgcmVzcG9uZHMg dG8gdGhlIHBpbmcgISEhIQ0KDQpUaGFua3MgaW4gYWR2YW5jZQ== From ja@ssi.bg Fri Aug 30 12:15:58 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 30 Aug 2002 14:15:58 +0300 (EEST) Subject: [LARTC] Problem with nexthop and gets dead In-Reply-To: Message-ID: Hello, On Fri, 30 Aug 2002 AClara@strategyconsultors.com wrote: > default proto static > nexthop via 80.25.175.1 dev eth0 weight 1 dead > nexthop via 212.170.14.1 dev eth1 weight 1 > Have any idea? Why said dead if the ip's responds to the ping !!!! You have to upgrade to iproute2 package released this year. Regards -- Julian Anastasov From miernik@ctnet.pl Thu Aug 29 23:04:14 2002 From: miernik@ctnet.pl (Miernik) Date: Fri, 30 Aug 2002 00:04:14 +0200 (CEST) Subject: [LARTC] how to log pacets which hit routing rules? In-Reply-To: <3D6E1F03.9020305@punkt.pl> Message-ID: On Thu, 29 Aug 2002, Wojtek wrote: > > Is there some way to make iproute2 log to syslog or to a file selected > > packets? > > > > I have a problem, that my packets dissapear somewhere, and I want to be > > sure if they get to the routing stage or not, and where do they get > > routed. > > use the iptables or ipchains with --log switch I know that, but I did not mean that. I want to log packets _at_the_roting_stage_, not at the filtering or NAT stage. -- Miernik _____________________________________ / / tel.: +48603070983 / / mailto:miernik@ctnet.pl __________________/___/ ICQ UIN: 4004001 From badrul@mail.kktaz.um.edu.my Fri Aug 30 21:08:47 2002 From: badrul@mail.kktaz.um.edu.my (Badrul Anuar) Date: Sat, 31 Aug 2002 04:08:47 +0800 (MYT) Subject: [LARTC] Multicast Routing Message-ID: <63462.202.185.68.221.1030738127.squirrel@mail.kktaz.um.edu.my> Anybody can answer my question regarding multicast routing. i have read Linux 2.4 Advanced Routing HOWTO and i have some question about multicast routing. I have two network to route between. Can you give me some tips to configure the routing table. I have two LAN connecting each other through Linux Box. Box A eth0 : internet Add eth1 : local subnet (192.168.0.0) Box B eth0 : 192.168.0.15 eth1 : 10.100.0.1 Client C (windows 98) connect to Box B is 10.100.0.10 How can my Client C can send multicast packet to LAN connected to BOX A and B in the same time (sending from client C 10.100.0.10)?I use IP Masquerade to make sure my "Client C" can connected directly to internet. same as i use it at BOX A and B. I can send multicast packet from Client C to Box B, and Box B to Box A. But can't send from Client C to Box A. Box A can send multicast packet to Box B but can't send to Client C. I think may be i have to configure the multicast routing at BOX B. But I have tried many ways but failed. Thank you. ps: sorry for the bad english language. From tack@auc.ca Fri Aug 30 21:35:44 2002 From: tack@auc.ca (Jason Tackaberry) Date: 30 Aug 2002 16:35:44 -0400 Subject: [LARTC] htb guarantee bandwidth In-Reply-To: <200208291453.44399.stef.coene@docum.org> References: <02082912495300.01420@sanitarium> <3D6DE126.6020704@promo.ro> <200208291453.44399.stef.coene@docum.org> Message-ID: <1030739745.7463.72.camel@somewhere.auc.ca> On Thu, 2002-08-29 at 08:53, Stef Coene wrote: > The prio is only used to split the traffic that's available after the rates > are satisfied. In this case, the prio will change nothing. But if you have > 3 classes like : Yes, the prio will change nothing, so it might as well look like this: class parent 1: classid 1:5 htb rate 128kbit class parent 1:5 classid 1:1 htb rate 64kbit ceil 128kbit prio 1 class parent 1:5 classid 1:2 htb rate 64kbit ceil 128kbit prio 1 If we put the client with the guaranteed rate (call him A) into 1:1, and the other two clients (B and C) into 1:2, it should work out the same way. If A uses 64kbit, the remaining 64kbit is split between B and C, and assuming there is a fair qdisc attached to 1:2, they should each get 32kbit. If B is inactive, both A and C will get 64kbit: their classes' guaranteed rates. If A is inactive, 1:2 will hit the ceil and B and C will share 128kbit, so each gets 64kbit. Doesn't that work out? Of course it's entirely academic, since it's not as if adding one extra rule makes it more complicated or less efficient in practice. Jason. -- Academic Computing Support Specialist Algoma University College Sault Ste. Marie, Ontario 705-949-2301 x330 Personal Home Page http://www.auc.ca http://sault.org From stef.coene@docum.org Fri Aug 30 21:44:17 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 30 Aug 2002 22:44:17 +0200 Subject: [LARTC] htb guarantee bandwidth In-Reply-To: <1030739745.7463.72.camel@somewhere.auc.ca> References: <02082912495300.01420@sanitarium> <200208291453.44399.stef.coene@docum.org> <1030739745.7463.72.camel@somewhere.auc.ca> Message-ID: <200208302244.17268.stef.coene@docum.org> On Friday 30 August 2002 22:35, Jason Tackaberry wrote: > On Thu, 2002-08-29 at 08:53, Stef Coene wrote: > > The prio is only used to split the traffic that's available after the > > rates are satisfied. In this case, the prio will change nothing. Bu= t if > > you have 3 classes like : > > Yes, the prio will change nothing, so it might as well look like this: > > class parent 1: classid 1:5 htb rate 128kbit > class parent 1:5 classid 1:1 htb rate 64kbit ceil 128kbit prio 1 > class parent 1:5 classid 1:2 htb rate 64kbit ceil 128kbit prio 1 > > If we put the client with the guaranteed rate (call him A) into 1:1, an= d > the other two clients (B and C) into 1:2, it should work out the same > way. If A uses 64kbit, the remaining 64kbit is split between B and C, > and assuming there is a fair qdisc attached to 1:2, they should each ge= t > 32kbit. If B is inactive, both A and C will get 64kbit: their classes' > guaranteed rates. If A is inactive, 1:2 will hit the ceil and B and C > will share 128kbit, so each gets 64kbit. Better, attach 2 new classes to 1:2 : class parent 1:2 classid 1:10 htb rate 16kbit ceil 128kbit prio 1 class parent 1:2 classid 1:20 htb rate 48kbit ceil 128kbit prio 1 Class 10 will get 25% of the available bandwidth of class 1:2 and class 2= 0=20 75%. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mello@lcs.poli.usp.br Fri Aug 30 22:00:37 2002 From: mello@lcs.poli.usp.br (Fernando Lemos de Mello) Date: Fri, 30 Aug 2002 18:00:37 -0300 Subject: [LARTC] TBF to limit bandwidth, Should I change #define HZ? References: <20020825042757.28961.97733.Mailman@outpost> Message-ID: <001f01c25068$4b2a9d20$0605a8c0@fernando> Dear friends, thanks for the last advices about TBF. After reading the tbf.pdf document I got a better insight of the problems I had trying to limit the bandwith on my testbed with a high resolution. The question I have now is: Would I get an immediatly better resolution result if I change the #define HZ to 1000 for my Linux box? I have a Pentium Celeron 700 MHz, and I would like to see the tbf working like: send a 1000 bytes packet -> wait 10ms -> send a 1000 bytes packet -> wait 10ms .... So if I change the file /usr/src/linux/include/asm-i386/param.h: #define HZ 100 to #define HZ 1000 and simply recompile the kernel, would tc work with better resolution? Thanks again, Fernando. From phil21@five-elements.com Sat Aug 31 04:11:46 2002 From: phil21@five-elements.com (Phil Doroff) Date: Fri, 30 Aug 2002 22:11:46 -0500 Subject: [LARTC] SMP in regards to routing/filtering Message-ID: Hey, quick (stupid) question.. Is the routing/filtering code in the linux kernel able to take much advantage of SMP? I'm building a router that I'd like to be able to handle at least 450mbit/sec (64bit 66mhtz PCI slots of course) and be able to apply QoS (basic prio queues) and htb/etc. traffic shaping to. Just wondering if it's worth grabbing an extra processor for the box, or if it will largely go unused. Thanks! Phil Doroff Five Elements, Inc. phil21@five-elements.com Phone:(763)595-9479 ICQ: 25285313 From ahu@ds9a.nl Sat Aug 31 12:28:27 2002 From: ahu@ds9a.nl (bert hubert) Date: Sat, 31 Aug 2002 13:28:27 +0200 Subject: [LARTC] TBF to limit bandwidth, Should I change #define HZ? In-Reply-To: <001f01c25068$4b2a9d20$0605a8c0@fernando> References: <20020825042757.28961.97733.Mailman@outpost> <001f01c25068$4b2a9d20$0605a8c0@fernando> Message-ID: <20020831112827.GA3411@outpost.ds9a.nl> On Fri, Aug 30, 2002 at 06:00:37PM -0300, Fernando Lemos de Mello wrote: > Dear friends, > > thanks for the last advices about TBF. > > After reading the tbf.pdf document I got a better insight of the problems I > had trying to limit the bandwith on my testbed with a high resolution. > > The question I have now is: > Would I get an immediatly better resolution result if I change the #define > HZ to 1000 for my Linux box? I have a Pentium Celeron 700 MHz, and I would > like to see the tbf working like: You don't need to change HZ, for most purposes, it suffices to just raise the burst size, which means 'send some packets' 'wait 10 ms' 'send some more packets'. This will even out just fine. > So if I change the file /usr/src/linux/include/asm-i386/param.h: #define HZ > 100 to #define HZ 1000 and simply recompile the kernel, would tc work with > better resolution? Yes. Kind regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ahu@ds9a.nl Sat Aug 31 12:55:18 2002 From: ahu@ds9a.nl (bert hubert) Date: Sat, 31 Aug 2002 13:55:18 +0200 Subject: [LARTC] SMP in regards to routing/filtering In-Reply-To: References: Message-ID: <20020831115517.GA4069@outpost.ds9a.nl> On Fri, Aug 30, 2002 at 10:11:46PM -0500, Phil Doroff wrote: > Hey, quick (stupid) question.. > > Is the routing/filtering code in the linux kernel able to take much > advantage of SMP? I'm building a router that I'd like to be able to handle > at least 450mbit/sec (64bit 66mhtz PCI slots of course) and be able to apply > QoS (basic prio queues) and htb/etc. traffic shaping to. Under some circumstances, a second CPU can be very useful. It depends on what you are doing, but the Linux networking core is completely able to paralelly use processors. You may need to do some work to give each network adaptor a dedicated CPU and you will also want to have multiple PCI busses. > Just wondering if it's worth grabbing an extra processor for the box, or if > it will largely go unused. It will see use but if you mess things up, it will not help. So make sure that you search on 'irq affinity' and the utility of multiple PCI busses. Perhaps a 64-bit 66MHz bus is fast enough to get by with one. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From arthur@reseau.nl Sat Aug 31 20:03:48 2002 From: arthur@reseau.nl (Arthur Donkers) Date: Sat, 31 Aug 2002 21:03:48 +0200 (MEST) Subject: [LARTC] Splitting locally generated traffic based on destination port Message-ID: Hi All, I have a Linux box (2.4.19, iptables 1.2.6a) that has two Ethernet interfaces. Eth0 is connected to a cisco which is connected to the Internet via a leasedline. Eth1 is connected to an ADSL connection. Both interfaces have a fixed IP address, and the default route points over the ADSL connection (because this is used for browsing, ftp and such). However, the Eth0 has the 'official' IP address and should be used for send e-mail and some ssh traffic. I already defined a policy to return incoming traffic over the interface it was received, so both interface can be contacted via the Internet. My question now is how to define a policy so specific traffic, generated locally by sendmail and ssh, uses eth0 as its interface in stead of eth1 which is used for the default route ? I already mark outgoing traffic in the mangle table thus iptables -A OUTPUT -t mangle -p tcp --dport 25 -j MARK --set-mark 1 I have to SNAT outgoing traffic as well: iptables -A POSTROUTING -t nat -m mark --mark 1 -j SNAT --to-source I have added a table mail.out to /etc/iproute2/rt_tables and defined rules like this: ip rule add fwmark 1 table mail.out ip route add default via dev eth0 src And when I do this: telnet 25 I indeed see a SYN packet coming out of eth0 to , and a SYN/ACK packet comes back. The problem is that it appears that the Linux box does not see this SYN/ACK packet and resends the SYN packet after a few seconds, which again is answered by a SYN/ACK and this goes on a few times. No other packet filters are active on the Linux box (yet). So how do I get this setup to work ? Am I heading for the wrong direction with the policy or is there something else missing ? thnx in advance, Arthur Donkers -- /* Disclaimer : you hire my skills, not my opinions, those are mine ! */ /* email : arthur@reseau.nl Security 'Me ? I'm not me ! I'm just a */ /* phone : (+31) 50 549 2701 is not a computer simulation of me' */ /* URL http://www.reseau.nl dirty word Red Dwarf, First Episode */ From piotr@omega.resa.es Sat Aug 31 20:36:48 2002 From: piotr@omega.resa.es (Pedro Larroy) Date: Sat, 31 Aug 2002 21:36:48 +0200 Subject: [LARTC] proc statistics and perl/tk frontend for QoS Message-ID: <20020831193648.GA19477@omega> Hi all. I have begun implementing /proc statistics for Linux queueing disciplines. I am also working in a perl fronted for simplifying the whole process. I cannot promise anything yet, but I wanted to let you know, just in case anybody is working on the same. Regards. -- ... ___________________________________________________________ ... | /| |\ | | /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr |-\ | | /--| No MS-Office attachments please. |--\ | o-|--| e-mail: piotr@omega.resa.es |--|-o | \-| finger piotr@omega.resa.es for public key and info |-/ | |...\|_________________________________________________________|/...| From miernik@ctnet.pl Sat Aug 31 20:46:31 2002 From: miernik@ctnet.pl (Miernik) Date: Sat, 31 Aug 2002 21:46:31 +0200 (CEST) Subject: [LARTC] Splitting locally generated traffic based on destination port In-Reply-To: Message-ID: On Sat, 31 Aug 2002, Arthur Donkers wrote: > I have added a table mail.out to /etc/iproute2/rt_tables and defined rules > like this: > > ip rule add fwmark 1 table mail.out > ip route add default via dev eth0 src > > And when I do this: > > telnet 25 > > I indeed see a SYN packet coming out of eth0 to , and a SYN/ACK > packet comes back. The problem is that it appears that the Linux box does > not see this SYN/ACK packet and resends the SYN packet after a few > seconds, which again is answered by a SYN/ACK and this goes on a few > times. No other packet filters are active on the Linux box (yet). Try: echo "0" > /proc/sys/net/ipv4/conf/eth0/rp_filter If it works, to make it permanent, include this line in your /etc/sysctl.conf file: net/ipv4/conf/eth0/rp_filter = 0 -- Miernik _____________________________________ / / tel.: +48603070983 / / mailto:miernik@ctnet.pl __________________/___/ ICQ UIN: 4004001 From Sebastian.Bleikamp@web.de Sat Aug 31 20:47:57 2002 From: Sebastian.Bleikamp@web.de (Sebastian Bleikamp) Date: Sat, 31 Aug 2002 21:47:57 +0200 Subject: [LARTC] Splitting locally generated traffic based on destination port References: Message-ID: <3D711D6D.7060700@web.de> Arthur Donkers wrote: > My question now is how to define a policy so specific traffic, generated > locally by sendmail and ssh, uses eth0 as its interface in stead of eth1 > which is used for the default route ? > > I already mark outgoing traffic in the mangle table thus > iptables -A OUTPUT -t mangle -p tcp --dport 25 -j MARK --set-mark 1 > I have to SNAT outgoing traffic as well: > iptables -A POSTROUTING -t nat -m mark --mark 1 -j SNAT --to-source > I have added a table mail.out to /etc/iproute2/rt_tables and defined rules > like this: > ip rule add fwmark 1 table mail.out > ip route add default via dev eth0 src > > And when I do this: > telnet 25 > > I indeed see a SYN packet coming out of eth0 to , and a SYN/ACK > packet comes back. The problem is that it appears that the Linux box does > not see this SYN/ACK packet and resends the SYN packet after a few > seconds, which again is answered by a SYN/ACK and this goes on a few > times. No other packet filters are active on the Linux box (yet). Hello Arthur, I´m not a professional in routing, but I think I´ve read something about the routing mechanism: Packet ---> Table PREROUTING -+-> Table FORWARD -+-> Table POSTROUTING | | (and then out) +-> Table INCOMING | | Table OUTGOING -+ The problem is, that the routing decision is done AFTER processing the forward table, but BEFORE the postrouting table (NAT). So it is possible to modify the packets in POSTROUTING that way, that they will go out via device A, but have the ip of the other device B. If the "answer" packet comes in at A (but are addressed to B), the address will be checked and device A drops (/does not listen to) them. ("Hey, that packet is not for me !"). Possible unclean variant to fix that would be to put device A in the so called "promisc" (promiscueing ?) mode, where all packets are processed. Clean variant is _not_ to do NAT by the filter. Make the _routing_ decision depending on the filter. And NAT is done afterwards based on the routing. Hope I told not too much wrong, Sebastian -=> Sebastian Bleikamp -=> EMail: -=> Phone: +49-172-6545394 From arthur@reseau.nl Sat Aug 31 21:41:08 2002 From: arthur@reseau.nl (Arthur Donkers) Date: Sat, 31 Aug 2002 22:41:08 +0200 Subject: [LARTC] Splitting locally generated traffic based on destination port In-Reply-To: References: Message-ID: <20020831204108.GB3142@netfinity.reseau.nl> On Sat, Aug 31, 2002 at 09:46:31PM +0200, Miernik wrote: > On Sat, 31 Aug 2002, Arthur Donkers wrote: > > > I have added a table mail.out to /etc/iproute2/rt_tables and defined rules > > like this: > > > > ip rule add fwmark 1 table mail.out > > ip route add default via dev eth0 src > > > > And when I do this: > > > > telnet 25 > > > > I indeed see a SYN packet coming out of eth0 to , and a SYN/ACK > > packet comes back. The problem is that it appears that the Linux box does > > not see this SYN/ACK packet and resends the SYN packet after a few > > seconds, which again is answered by a SYN/ACK and this goes on a few > > times. No other packet filters are active on the Linux box (yet). > > Try: > > echo "0" > /proc/sys/net/ipv4/conf/eth0/rp_filter > > If it works, to make it permanent, include this line in your > /etc/sysctl.conf file: > > net/ipv4/conf/eth0/rp_filter = 0 thanks ! this works ! grtz, Arthur > > -- > Miernik _____________________________________ > / / > tel.: +48603070983 / / mailto:miernik@ctnet.pl > __________________/___/ ICQ UIN: 4004001 -- /* Disclaimer : you hire my skills, not my opinions, those are mine ! */ /* email : arthur@reseau.nl Security 'Me ? I'm not me ! I'm just a */ /* phone : (+31) 50 549 2701 is not a computer simulation of me' */ /* URL http://www.reseau.nl dirty word Red Dwarf, First Episode */ From deim@inf.elte.hu Sun Sep 1 00:04:40 2002 From: deim@inf.elte.hu (=?ISO-8859-2?Q?Tak=E1cs=20B=E1lint?=) Date: Sun, 01 Sep 2002 01:04:40 +0200 Subject: [LARTC] HTB shares equally when borrowing enabled :( Message-ID: <3D714B88.7000903@inf.elte.hu> Hi, I'm fighting seriously with a most simple HTB setup. I'd like to share the incoming 64kbps into 5 and 59 for two different machines under NAT. HTB seems to hold the required limits when ceil is not set (no borrowing), but when borrowing enabled it seems to share equally rather then keeping the specified ratio. My setup is below. A typical output of "tc -s -d qdisc show dev eth1" and "tc -s -d class show dev eth1" is given. HTB seems to disobey the specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is measured, while rate 472Kbit is set for 1:11 and rate 20755bps is measured). Setting the explicit bandwith (ceil=64kbps everywhere) does not work. Playing with burst and cburst did not any change. I've tried CBQ but it seems to do the same... :( Please help. Thank you, Bálint #################################### # add root HTB disc run_tc qdisc add dev eth1 root handle 1: htb default 11 r2q 1 # be optimistic about input rates :) run_tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit # setup classes for the local nodes run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil 10mbit prio 2 run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil 10mbit prio 1 # create leaves run_tc qdisc add dev eth1 parent 1:10 sfq perturb 10 run_tc qdisc add dev eth1 parent 1:11 sfq perturb 10 # setup filtering rules : packets going to 192.168.1.2 will go into class 1:10 run_tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.2 flowid 1:10 ################################ # tc -s -d qdisc show dev eth1 qdisc sfq 8002: quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 3401706 bytes 2650 pkts (dropped 0, overlimits 0) qdisc sfq 8001: quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 2039284 bytes 1363 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 1 default 11 dcache 0 deq_util 1/1000000 deq_rate 5 trials_per_deq 0 dcache_hits 0 direct_packets 0 Sent 5440990 bytes 4013 pkts (dropped 0, overlimits 0) ################################ # tc -s -d class show dev eth1 class htb 1:11 parent 1:1 leaf 8002: prio 1 rate 472Kbit ceil 10Mbit burst 2203b/8 mpu 0b cburst 14704b/8 mpu 0b quantum 60000 level 0 Sent 3284592 bytes 2545 pkts (dropped 0, overlimits 0) rate 20755bps 15pps lended: 2545 borrowed: 0 giants: 0 injects: 0 tokens: 28909 ctokens: 9147 class htb 1:1 root prio 0 rate 10Mbit ceil 10Mbit burst 14704b/8 mpu 0b cburst 14704b/8 mpu 0b quantum 60000 level 3 Sent 5140628 bytes 3786 pkts (dropped 0, overlimits 0) rate 37374bps 26pps lended: 888 borrowed: 0 giants: 0 injects: 0 tokens: 9147 ctokens: 9147 class htb 1:10 parent 1:1 leaf 8001: prio 2 rate 40Kbit ceil 10Mbit burst 1650b/8 mpu 0b cburst 14704b/8 mpu 0b quantum 5120 level 0 Sent 1856036 bytes 1241 pkts (dropped 0, overlimits 0) rate 16466bps 10pps lended: 353 borrowed: 888 giants: 0 injects: 0 tokens: -71171 ctokens: 8247 From arindamhaldar@inbox.lv Sun Sep 1 08:59:18 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Sun, 01 Sep 2002 13:29:18 +0530 Subject: [LARTC] htb ,essage in messages file ! Message-ID: <3D71C8D6.3030205@inbox.lv> hi all, i saw this message today & am reporting it(as it says) [root@cab1 surfNet]# tail -f /var/log/messages Sep 1 04:02:03 cab1 syslogd 1.4.1: restart. Sep 1 09:35:27 cab1 kernel: HTB: mindelay=500, report it please ! [root@cab1 root]# iptables -V iptables v1.2.6a [root@cab1 root]# tc -V tc utility, iproute2-ss020116 [root@cab1 root]# uname -a Linux cab1 2.4.19-r #2 Sun Aug 25 01:49:24 IST 2002 i686 unknown [root@cab1 root]# additional patches are imq-2.4.18.diff-5 & iptables-1.2.6a-imq.diff-2 and patches for load balance routing, but am not using imq at all ! htb was started on Aug 30 10:24:54 cab1 kernel: HTB init, kernel part version 3.6 why it appeared ? awaiting a reply A.H From stef.coene@docum.org Sun Sep 1 09:44:39 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 1 Sep 2002 10:44:39 +0200 Subject: [LARTC] HTB shares equally when borrowing enabled :( In-Reply-To: <3D714B88.7000903@inf.elte.hu> References: <3D714B88.7000903@inf.elte.hu> Message-ID: <200209011044.39145.stef.coene@docum.org> On Sunday 01 September 2002 01:04, Tak=E1cs B=E1lint wrote: > Hi, > > I'm fighting seriously with a most simple HTB setup. I'd like to share > the incoming 64kbps into 5 and 59 for two different machines under NAT. > HTB seems to hold the required limits when ceil is not set (no > borrowing), but when borrowing enabled it seems to share equally rather > then keeping the specified ratio. > My setup is below. A typical output of "tc -s -d qdisc show dev eth1" > and "tc -s -d class show dev eth1" is given. HTB seems to disobey the > specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is > measured, while rate 472Kbit is set for 1:11 and rate 20755bps is > measured). > Setting the explicit bandwith (ceil=3D64kbps everywhere) does not work. > Playing with burst and cburst did not any change. You have to put a ceil of 64kbps everywhere so class 1:10 and 1:11 share = the=20 same 64 kbps : run_tc class add dev eth1 parent 1: classid 1:1 htb rate ceil 64kbps run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil 64= kbps=20 prio 2 run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil 6= 4kbps=20 prio 1 And if that's not working, try ceil=3D62kbps. You have to do this so YOU= are=20 controlling the link and not the modem. And take sum of class =3D 62kbps= =2E Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From ahu@ds9a.nl Sun Sep 1 13:13:41 2002 From: ahu@ds9a.nl (bert hubert) Date: Sun, 1 Sep 2002 14:13:41 +0200 Subject: [LARTC] htb ,essage in messages file ! In-Reply-To: <3D71C8D6.3030205@inbox.lv> References: <3D71C8D6.3030205@inbox.lv> Message-ID: <20020901121341.GA25577@outpost.ds9a.nl> On Sun, Sep 01, 2002 at 01:29:18PM +0530, Arindam Haldar wrote: > hi all, > i saw this message today & am reporting it(as it says) > > [root@cab1 surfNet]# tail -f /var/log/messages > Sep 1 04:02:03 cab1 syslogd 1.4.1: restart. > Sep 1 09:35:27 cab1 kernel: HTB: mindelay=500, report it please ! Can you also report your HTB configuration, the tc commands you used? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From nberg@gandalf.xs4all.nl Mon Sep 2 00:00:37 2002 From: nberg@gandalf.xs4all.nl (Nico Berg) Date: Mon, 2 Sep 2002 01:00:37 +0200 Subject: [LARTC] 4 ipadresses only one working In-Reply-To: <4FACD13E65E34440B01491D90EDE966A26C5E8@hq-exchange.hq.nl> Message-ID: > -----Oorspronkelijk bericht----- > Van: lartc-admin@mailman.ds9a.nl > [mailto:lartc-admin@mailman.ds9a.nl]Namens niels@wxn.nl > Verzonden: vrijdag 30 augustus 2002 11:23 > Aan: nberg@gandalf.xs4all.nl; lartc@mailman.ds9a.nl > Onderwerp: RE: [LARTC] 4 ipadresses only one working > > > Try to run /sbin/ifconfig... It show's the IP adresses your interfaces > have... has your interface all those 4 adresses? I think not... Yes I do have all the 4 adresses!!!!! > > If not you should "add" those IP adresses to the interface > > Try something like this: > > #ip addr add 213.84.46.145/24 dev ppp+ broadcast 213.84.46.255 This doesn't work, I still can not ping to this adress from another server! I am new to this kind of stuff and I don't know shit about it, so excuse me if I do not understand why it doesn't work this way, it looked good. Greetings, Nico Berg > > After that you should proxy-ARP or SNAT them to another machine on the > internal network (or better DMZ) because I don't see the advantage of > running more than one IP adress on the linux box itself > > > -----Original Message----- > From: Nico Berg [mailto:nberg@gandalf.xs4all.nl] > Sent: 30 August 2002 10:33 > To: lartc@mailman.ds9a.nl > Subject: [LARTC] 4 ipadresses only one working > > > Dear listreaders, > This is about my last hope! I'm new to this list. > Running Suse Linux 8 (for shortly installed over 7.2) I have an adsl > connection and can loggin 4 times. Every time I loggin at my ISP I get an > ipadres. So I own 4 ipadresses. Only this first adress is working. > > The other 3 are connected, can do a tcpdump and see reaction's > only the one > who is pinging doesn't get an reaction. So, apperently the machine doesn't > react to this ipadresses because they are not in the system or > so???? I put > in a piece tcpdump. > > tcpdump: listening on ppp1 > 14:37:42.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > 14:37:43.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > 14:37:44.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > 14:37:45.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > 14:37:46.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > 14:37:47.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > 14:37:48.123230 194.109.6.44 > 213.84.46.145: icmp: echo request > > Reaction from the ping adres > PING 213.84.46.145 (213.84.46.145): 56 data bytes > ^C > --- 213.84.46.145 ping statistics --- > 7 packets transmitted, 0 packets received, 100% packet loss > > I can ping from my intern network then it works normal with a normal > reaction. I have a server (the machine discused above) and 4 > machine getting > there internetaccess from the server with iptables. > > #!/bin/sh > > # Masquerading firewall (simpel) > # 13 augustus 2001 > # Bart Geverts (bart@hakkefest.linux-site.net) > > # Een hele eenvoudige masquerading firewall waarmee het mogelijk > om met het > # hele achterliggende LAN het internet op te kunnen. Het > 'firewall' gedeelte > # bestaat uit het afsluiten van een aantal poorten waarop > relatief riskante > # servers draaien. Alleen de variabelen moeten aan de omgeving worden > aangepast. > > > ################################################################## > ########## > #### > # variabelen > > # waar iptables staat > IPTABLES="/usr/sbin/iptables" > > # interfaces > INTERNAL_INTERFACE="eth1" # interface waarmee gateway aan lokale netwerk > zit > EXTERNAL_INTERFACE="ppp+" # interface waarmee gateway aan het > internet zit > #EXTERNAL_INTERFACE2="ppp1" # tweede ipnr #EXTERNAL_INTERFACE3="ppp2" # > derde #EXTERNAL_INTERFACE4="ppp3" # vierde > > # ipadressen / netwerken > LAN="196.168.0.1/24" # lokale netwerk > > # ip nummers > #IP_nr_1="213.84.46.144" > #IP_nr_2="213.84.46.145" > #IP_nr_3="213.84.46.146" > #IP_nr_4="213.84.46.147" > > > ################################################################## > ########## > #### > # clean-up + init > > # flush en clear alle rules en zet de tellers op 0 > $IPTABLES -F > $IPTABLES -X > $IPTABLES -Z > $IPTABLES -t nat -F > $IPTABLES -t nat -X > $IPTABLES -t nat -Z > > # set de default policies > $IPTABLES -P INPUT ACCEPT > $IPTABLES -P FORWARD ACCEPT > $IPTABLES -P OUTPUT ACCEPT > $IPTABLES -t nat -P PREROUTING ACCEPT > $IPTABLES -t nat -P POSTROUTING ACCEPT > $IPTABLES -t nat -P OUTPUT ACCEPT > > > ################################################################## > ########## > #### > # initialiseren van de kernel > > ## Enable IP forwarding > echo 1 > /proc/sys/net/ipv4/ip_forward > > > ################################################################## > ########## > #### > # masquerade > > ## Alles met afkomst van of bestemming lokale netwerk heeft forwarden > $IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_INTERFACE -j MASQUERADE > $IPTABLES -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE -s $LAN > -d ! $LAN -j ACCEPT $IPTABLES -A FORWARD -o $INTERNAL_INTERFACE -i > $EXTERNAL_INTERFACE -d $LAN -s ! $LAN -j ACCEPT > > ################################################################## > ########## > ##### Tweede IPnr > #$IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_INTERFACE_2 - MASQUERADE > #$IPTABLES -A FORWARD -i $INTERNAL_INTERFACE -o > $EXTERNAL_INTERFACE2 -s $LAN > -d ! $LAN -j ACCEPT #$IPTABLES -A FORWARD -o $INTERNAL_INTERFACE -i > $EXTERNAL_INTERFACE2 -d $LAN -s ! $LAN -j ACCEPT #$IPTABLES -A INPUT -i > $EXTERNAL_INTERFACE_2 -j ACCEPT #$IPTABLES -A OUTPUT -o > $EXTERNAL_INTERFACE_2 -j ACCEPT > > ################################################################## > ########## > #### > # riskante servers afsluiten > > ## telnet afsluiten voor de buitenwereld > $IPTABLES -A INPUT -p tcp --destination-port 23 -i $EXTERNAL_INTERFACE -j > DROP # #$IPTABLES -L > > If my ipadresses working properly then I want to extend the firewallscript > to a normal working firewall (in the mean time I have updated my swiss > cheese to a normal functional firewall). > > I hope somebody can help me out here and tell me how to (I think > Postrouting > or so) my 3 adresses. If there is somebody interested I have put a lot of > information on a webpages and publised it on the first ipadres: > http://gandalf.xs4all.nl/Suse.html > > So please help! Greetings, Nico Berg > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From gsteer@lidcam.com.au Mon Sep 2 03:34:30 2002 From: gsteer@lidcam.com.au (Geoff Steer) Date: Mon, 02 Sep 2002 12:34:30 +1000 Subject: [LARTC] arp control in a multihomes host Message-ID: <3D72CE36.60705@lidcam.com.au> I have a problem involing arp table entries that I'm hoping someone can help with. I'm working on a mail system that utilises multiple Linux servers in a redundant configuration. The configuration has pairs of Linux servers running as MTAs. Each pair of real servers hides behind a virtual server name. The virtual server name and load balancing of real servers is handled by an Alteon AD3 switch. Each of the Linux servers has two ethernet interfaces with the second interface also connected to a (second) Alteon. The two Alteons are configured in an active-standby arrangement using VRRP. The IP addresses of each linux servers' ethernet interfaces are on the same subnet (172.16.180.0/128), The configuration of the Alteon causes each of the Alteon IP addresses to appear on each interface of the Linux box, with the same MAC address i.e. alteon1 (172.16.180.2) at 00:00:E8:D7:4F:5D [ether] on eth0 alteon2 (172.16.180.3) at 00:50:BA:CB:DD:D8 [ether] on eth0 alteon1 (172.16.180.2) at 00:00:E8:D7:4F:5D [ether] on eth1 alteon2 (172.16.180.3) at 00:50:BA:CB:DD:D8 [ether] on eth1 What I'm looking to do is to not have the second entry for any host appear in the arp table if it's already there for another interface. i.e. if alteon1 has an arp entry pointing to eth0, don't add one for eth1 - which I guess means, don't issue arp requests/responses on the other interface for an Alteon if we have an arp table entry. The solution doesn't need to be tailored to the Alteon IP addresses, just a general rule of not issuing arp requests/responses on a second interface if we already have a similiar entry pointing to the first interface. Regards Geoff Steer From mabrown-lartc@securepipe.com Mon Sep 2 03:50:05 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Sun, 1 Sep 2002 21:50:05 -0500 (CDT) Subject: [LARTC] arp control in a multihomes host In-Reply-To: <3D72CE36.60705@lidcam.com.au> Message-ID: Geoff, Frankly, I'm not sure if this is the answer to your question, but Julian Anastasov has written a very handy utility called "ip arp". You may find that this is just the trick. Check out Julian's work here: http://www.linuxvirtualserver.org/~julian/ http://www.linuxvirtualserver.org/~julian/iparp.txt Hopefully, there is somebody else on this list who has specific experience with the problem you are trying to solve. Anyway, best of luck, -Martin On Mon, 2 Sep 2002, Geoff Steer wrote: : I have a problem involing arp table entries that I'm hoping someone can : help with. : : I'm working on a mail system that utilises multiple Linux servers in a : redundant configuration. : The configuration has pairs of Linux servers running as MTAs. Each pair : of real servers hides behind a virtual server name. The virtual server : name and load balancing of real servers is handled by an Alteon AD3 switch. : Each of the Linux servers has two ethernet interfaces with the second : interface also connected to a (second) Alteon. The two Alteons are : configured in an active-standby arrangement using VRRP. : The IP addresses of each linux servers' ethernet interfaces are on the : same subnet (172.16.180.0/128), : : The configuration of the Alteon causes each of the Alteon IP : addresses to appear on each interface of the Linux box, with the same : MAC address i.e. : : alteon1 (172.16.180.2) at 00:00:E8:D7:4F:5D [ether] on eth0 : alteon2 (172.16.180.3) at 00:50:BA:CB:DD:D8 [ether] on eth0 : alteon1 (172.16.180.2) at 00:00:E8:D7:4F:5D [ether] on eth1 : alteon2 (172.16.180.3) at 00:50:BA:CB:DD:D8 [ether] on eth1 : : What I'm looking to do is to not have the second entry for any host : appear in the arp table if it's already there for another interface. : i.e. if alteon1 has an arp entry pointing to eth0, don't add one for : eth1 - which I guess means, don't issue arp requests/responses on the : other interface for an Alteon if we have an arp table entry. : The solution doesn't need to be tailored to the Alteon IP : addresses, just a general rule of not issuing arp requests/responses : on a second interface if we already have a similiar entry pointing to : the first interface. : : Regards : Geoff Steer : : : : : _______________________________________________ : LARTC mailing list / LARTC@mailman.ds9a.nl : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From bergal@gmx.net Mon Sep 2 06:40:29 2002 From: bergal@gmx.net (Alexander Bergal) Date: Mon, 2 Sep 2002 07:40:29 +0200 (MEST) Subject: [LARTC] howto unsubscribe Message-ID: <12769.1030945229@www1.gmx.net> Hello! Please help to unsubscribe -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From psi@platon.atlantis.sk Mon Sep 2 08:04:48 2002 From: psi@platon.atlantis.sk (M.F. PSIkappa) Date: Mon, 2 Sep 2002 09:04:48 +0200 (CEST) Subject: [LARTC] arp control in a multihomes host In-Reply-To: <3D72CE36.60705@lidcam.com.au> Message-ID: Hello, you can use ebtables (http://users.pandora.be/bart.de.schuymer/ebtables/). On Mon, 2 Sep 2002, Geoff Steer wrote: > I have a problem involing arp table entries that I'm hoping someone can > help with. > > I'm working on a mail system that utilises multiple Linux servers in a > redundant configuration. > The configuration has pairs of Linux servers running as MTAs. Each pair > of real servers hides behind a virtual server name. The virtual server > name and load balancing of real servers is handled by an Alteon AD3 switch. > Each of the Linux servers has two ethernet interfaces with the second > interface also connected to a (second) Alteon. The two Alteons are > configured in an active-standby arrangement using VRRP. > The IP addresses of each linux servers' ethernet interfaces are on the > same subnet (172.16.180.0/128), > > The configuration of the Alteon causes each of the Alteon IP > addresses to appear on each interface of the Linux box, with the same > MAC address i.e. > > alteon1 (172.16.180.2) at 00:00:E8:D7:4F:5D [ether] on eth0 > alteon2 (172.16.180.3) at 00:50:BA:CB:DD:D8 [ether] on eth0 > alteon1 (172.16.180.2) at 00:00:E8:D7:4F:5D [ether] on eth1 > alteon2 (172.16.180.3) at 00:50:BA:CB:DD:D8 [ether] on eth1 > > What I'm looking to do is to not have the second entry for any host > appear in the arp table if it's already there for another interface. > i.e. if alteon1 has an arp entry pointing to eth0, don't add one for > eth1 - which I guess means, don't issue arp requests/responses on the > other interface for an Alteon if we have an arp table entry. > The solution doesn't need to be tailored to the Alteon IP > addresses, just a general rule of not issuing arp requests/responses > on a second interface if we already have a similiar entry pointing to > the first interface. > > Regards > Geoff Steer -- `)_|_(' PSIkappa I k psi _at_ atlantis.sk From deim@inf.elte.hu Mon Sep 2 12:24:59 2002 From: deim@inf.elte.hu (=?ISO-8859-2?Q?Tak=E1cs=20B=E1lint?=) Date: Mon, 02 Sep 2002 13:24:59 +0200 Subject: [LARTC] HTB shares equally when borrowing enabled :( References: <3D714B88.7000903@inf.elte.hu> <200209011044.39145.stef.coene@docum.org> Message-ID: <3D734A8B.7030704@inf.elte.hu> Thanks Stef! The trick with setting lower maximum bandwidth works. I convinced me that I understand now what happens :) The ISP starts to build queues when maximal input rate is reached and releases packets from these queues equally. Thus the prioritized connections had to wait sometimes and it lends its guaranteed bw instead of waiting. I had to set the ceil to as low as 50 kbps (!). My usual maximal throughput rate is about 55 kb/sec, while my ISP says the maximal input rate is 512 kbit/sec. I always assigned the difference to IP administration. Now, the maximal throughput seems to not drop until ceil is lowered below 55 kbps. Thus I assume the rates calculated by HTB measure the REAL throughput without IP administration. Is it true? Sometimes the maximal input rate drops (damn ISP) and it seems to enable small "bursts" with high throughputs. Does it mean that I should to decrease/increase the ceil when it happens? I think it depends on the ISP queues: if they start to build, then I must. It can mean that I can't use traffic shaping, or at least not HTB qdisc - maybe some prio setup will do the job. What if I try to shape the outgoing traffic? Maybe it has an effect on incoming, too. I mean if "acknowledged" information goes back slow, I can manipulate the ISP queues, hm? Bálint Stef Coene wrote: >On Sunday 01 September 2002 01:04, Takács Bálint wrote: > >>Hi, >> >>I'm fighting seriously with a most simple HTB setup. I'd like to share >>the incoming 64kbps into 5 and 59 for two different machines under NAT. >>HTB seems to hold the required limits when ceil is not set (no >>borrowing), but when borrowing enabled it seems to share equally rather >>then keeping the specified ratio. >>My setup is below. A typical output of "tc -s -d qdisc show dev eth1" >>and "tc -s -d class show dev eth1" is given. HTB seems to disobey the >>specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is >>measured, while rate 472Kbit is set for 1:11 and rate 20755bps is >>measured). >>Setting the explicit bandwith (ceil=64kbps everywhere) does not work. >>Playing with burst and cburst did not any change. >> >You have to put a ceil of 64kbps everywhere so class 1:10 and 1:11 share the >same 64 kbps : > >run_tc class add dev eth1 parent 1: classid 1:1 htb rate ceil 64kbps > >run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil 64kbps >prio 2 >run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil 64kbps >prio 1 > >And if that's not working, try ceil=62kbps. You have to do this so YOU are >controlling the link and not the modem. And take sum of class = 62kbps. > >Stef > From noroozi@mehr.sharif.edu Mon Sep 2 13:13:03 2002 From: noroozi@mehr.sharif.edu (noroozi@mehr.sharif.edu) Date: Mon, 2 Sep 2002 12:13:03 GMT Subject: [LARTC] is CBQ wrong !!! Message-ID: <200209021213.g82CD2G15305@mehr.sharif.edu> Hello every body , I am really mixed up ,I set the TC linke below,I take the rate around 3-4 Mbit/Sec, I forward 530 Mbit file over the line bye network card 100 Mbit, If you know why I am really wait to help me, Is my code wrong,or not ???? Is the number of rule effect on the speed ??? I examine bye 2 rules and 90 rules but the rate that I establish is fix 3-4 Mbit/sec !!!!!! ################################################################## tc qdisc add dev eth0 root handle 1: cbq bandwidth 100Mbit avpkt 1000 rate 100Mbit ################################################################## tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 100Mbit rate 100Mbit mpu 1500 allot 1500 prio 5 bounded isolated tc class add dev eth0 parent 1:1 classid 1:20 cbq rate 40Mbit bandwidth 40Mbit mpu 1500 avpkt 1000 allot 1600 minburst 100 maxburst 100 prio 1 isolated bounded tc class add dev eth0 parent 1:1 classid 1:10 cbq rate 60Mbit bandwidth 60Mbit mpu 1500 avpkt 1000 allot 1600 minburst 200 maxburst 10000 prio 2 isolated bounded tc qdisc add dev eth0 parent 1:10 handle 10: pfifo limit 10 tc qdisc add dev eth0 parent 1:20 handle 20: pfifo limit 10 ################################################################## ################################################################## tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 194.225.42.37/32 flowid 1:20 tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 194.225.42.36/32 flowid 1:10 194.225.42.35/32 flowid 1:20 tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip src 194.225.42.34/32 flowid 1:20 --------------------------------------------- This message was sent using sharif web-based mail. http://mehr.sharif.edu From miernik@ctnet.pl Mon Sep 2 13:58:38 2002 From: miernik@ctnet.pl (Miernik) Date: Mon, 2 Sep 2002 14:58:38 +0200 (CEST) Subject: [LARTC] how to force iproute2 to FORWARD to another interface packets with a destinatioin IP on this machine? In-Reply-To: <3D6E0E6C.6070908@punkt.pl> Message-ID: On Thu, 29 Aug 2002, Wojtek wrote: > > My machine debina, has three interfaces: > > > > eth1 212.126.24.129 > > ppp0 10.2.0.1 (Point-to-Point: 212.31.242.98) > > nsc5 10.2.0.250 (Point-to-Point: 172.23.140.32) > > > > I want packets which come in through the nsc5 interface, to be FORWARDED > > to the ppp0 interface to 212.31.242.98, even when their destination > > address is 212.126.24.129 (even so this is the IP of eth1 on this > > machine). > > you can use set of 'ip rule' and other routing table I tried to, but it is not that simple: The routing table 'local' is bound to the first rule (rule 0), and I cannot put any other rule before it. I cannot delete the rule 0. I tried deleting rules from from the local table, and putting them into table local2, and assinging rule 2 to table local2, but it didn't work too: I lost connectivity to my local host. -- Miernik _____________________________________ / / tel.: +48603070983 / / mailto:miernik@ctnet.pl __________________/___/ ICQ UIN: 4004001 From esteban.maringolo@secont.com.ar Mon Sep 2 16:08:59 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 02 Sep 2002 12:08:59 -0300 Subject: [LARTC] "Transparent" shapping Message-ID: <1030979340.445.40.camel@sico> --=-6K17sYyhFHCCa4IfFYBv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I want to do some traffic shapping with a PC in the same IP subnet that the "shaped" PC's. Graphically: ________ __________ | | | | Internet-eth0| NAT/GW |eth1----eth0| TC BOX |eth1 --- SUBNET PC's... |________| |__________| NAT GW (Nat Gateway) Specs: eth0 IP: AAA.BBB.CCC.DDD Public Address eth1 IP: 192.168.0.1/24 TC BOX (Traffic Shaper): eth0 IP: 192.168.0.2/24 eth1 IP: 192.168.0.3/24 SUBNET PCs: Netblock: 192.168.0.10/24 - 192.168.0.254/24 Default GW IP: 192.168.0.1 Is possible to make that my TC BOX acts transparently for the subnet PCs without redefine the default GW to 192.168.0.3 (the TC inner interface). The intention is not add another Hop to the network, and lower the CPU usage of the TC BOX (i don't want to do NAT on it). Thanks. --=20 Esteban A. Maringolo --=-6K17sYyhFHCCa4IfFYBv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9c38KDY8wt+MWh9ARAmnFAKDKutsQoNrJ4mEsXbwx6YbEzQP5bgCgi1iB YK6htM78f02EbjDmJi96YWQ= =Axmn -----END PGP SIGNATURE----- --=-6K17sYyhFHCCa4IfFYBv-- From David.Lamparter@t-online.de Mon Sep 2 16:17:54 2002 From: David.Lamparter@t-online.de (David Lamparter) Date: Mon, 02 Sep 2002 17:17:54 +0200 Subject: [LARTC] how to force iproute2 to FORWARD to another interface packets with a destinatioin IP on this machine? References: Message-ID: <3D738122.60307@t-online.de> You may want to try the (unoffical) 'ROUTE' netfilter patch (see patch-o-matic at www.netfilter.org) after applying and re-compiling kernel + iptables use: iptables -t mangle -A PREROUTING -i nsc5 -d 212.31.242.98 -j ROUTE --iface ppp0 (maybe there is another possibility without recompiling kernel ... but I didn't find anything...) Miernik schrieb: > On Thu, 29 Aug 2002, Wojtek wrote: > > >>>My machine debina, has three interfaces: >>> >>>eth1 212.126.24.129 >>>ppp0 10.2.0.1 (Point-to-Point: 212.31.242.98) >>>nsc5 10.2.0.250 (Point-to-Point: 172.23.140.32) >>> >>>I want packets which come in through the nsc5 interface, to be FORWARDED >>>to the ppp0 interface to 212.31.242.98, even when their destination >>>address is 212.126.24.129 (even so this is the IP of eth1 on this >>>machine). >> >>you can use set of 'ip rule' and other routing table > > > I tried to, but it is not that simple: > > The routing table 'local' is bound to the first rule (rule 0), and I > cannot put any other rule before it. > > I cannot delete the rule 0. > > I tried deleting rules from from the local table, and putting them into > table local2, and assinging rule 2 to table local2, but it didn't work > too: I lost connectivity to my local host. > David Lamparter, david.lamparter@t-online.de From arindamhaldar@inbox.lv Mon Sep 2 16:34:41 2002 From: arindamhaldar@inbox.lv (Arindam Haldar) Date: Mon, 02 Sep 2002 21:04:41 +0530 Subject: [LARTC] htb message in messages file ! References: <3D71C8D6.3030205@inbox.lv> <20020901121341.GA25577@outpost.ds9a.nl> Message-ID: <3D738511.1030005@inbox.lv> bert hubert wrote: > On Sun, Sep 01, 2002 at 01:29:18PM +0530, Arindam Haldar wrote: > >>hi all, >>i saw this message today & am reporting it(as it says) >> >>[root@cab1 surfNet]# tail -f /var/log/messages >>Sep 1 04:02:03 cab1 syslogd 1.4.1: restart. >>Sep 1 09:35:27 cab1 kernel: HTB: mindelay=500, report it please ! > > Can you also report your HTB configuration, the tc commands you used? > > Regards, > > bert $TC qdisc del dev eth4 root $TC qdisc add dev eth4 root handle 5: htb $TC class add dev eth4 parent 5: classid 5:1 htb rate 10mbit $TC class add dev eth4 parent 5:1 classid 5:10 htb rate ${d2vNtwk}kbit quantum 3000 $TC class add dev eth4 parent 5:1 classid 5:20 htb rate ${d2vCable}kbit quantum 4500 ###################---------from NtWk Servers $TC class add dev eth4 parent 5:10 classid 5:1005 htb rate ${d2vNtwk}kbit $TC qdisc add dev eth4 parent 5:1005 sfq quantum 1514b perturb 10 $TC filter add dev eth4 protocol ip parent 5:0 prio 1 handle 4001 fw classid 5:1005 $TC filter add dev eth4 protocol ip parent 5:0 prio 2 u32 match ip dst 10.0.0.0/8 match ip protocol 1 0xff flowid 5:105 ####################----------CABLE $TC class add dev eth4 parent 5:20 classid 5:201 htb rate ${groupA}kbit ceil $[groupA+(d2vCable-groupA)/4]kbit $TC class add dev eth4 parent 5:20 classid 5:202 htb rate ${groupB}kbit ceil $[groupB+(d2vCable-groupB)/4]kbit #################-----groupA ####------JComB $TC class add dev eth4 parent 5:201 classid 5:2001 htb rate ${jcomB}kbit ceil $[jcomB+(groupA-jcomB)/10]kbit quantum 3000 $TC qdisc add dev eth4 parent 5:2001 handle 2001 pfifo limit 2 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst abc.234/31 flowid 5:2001 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst abc.236/30 flowid 5:2001 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst 10.255.2.16/30 flowid 5:2001 #### ---- collector $TC class add dev eth4 parent 5:201 classid 5:2002 htb rate ${collector}kbit ceil $[collector+(groupA-collector)/10]kbit quantum 3000 $TC qdisc add dev eth4 parent 5:2002 handle 2002 pfifo limit 2 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst 10.2.1.40 flowid 5:2002 ####----- lakhanpal $TC class add dev eth4 parent 5:201 classid 5:2003 htb rate ${lakhanpal}kbit ceil $[lakhanpal+(groupA-lakhanpal)/10]kbit quantum 4500 $TC qdisc add dev eth4 parent 5:2003 handle 2003 pfifo limit 2 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst 10.255.0.17 flowid 5:2003 ####----- htl $TC class add dev eth4 parent 5:201 classid 5:2004 htb rate ${htl}kbit ceil $[htl+(groupA-htl)/10]kbit quantum 4500 $TC qdisc add dev eth4 parent 5:2004 handle 2004 pfifo limit 2 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst 10.0.3.8/31 flowid 5:2004 ################--------GroupB cnt=1 for users in ` cat /var/surfNet/access/users-cable.[1.2] ` ; do $TC class add dev eth4 parent 5:202 classid 5:$[5200+cnt] htb rate ${cmnGp}kbit ceil $[cmnGp+(groupB)/12]kbit quantum 3000 $TC qdisc add dev eth4 parent 5:$[5200+cnt] handle $[5200+cnt] pfifo limit 2 $TC filter add dev eth4 protocol ip parent 5:0 prio 100 u32 match ip dst $users flowid 5:$[5200+cnt] cnt=$[cnt+1] done From arc_of_descent@gmx.net Mon Sep 2 16:38:50 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Mon, 2 Sep 2002 21:08:50 +0530 Subject: [LARTC] "Transparent" shapping In-Reply-To: <1030979340.445.40.camel@sico> References: <1030979340.445.40.camel@sico> Message-ID: <02090221085005.03104@sanitarium> Esteban Maringolo thus wrote: > I want to do some traffic shapping with a PC in the same IP subnet that > the "shaped" PC's. > The intention is not add another Hop to the network, and lower the CPU > usage of the TC BOX (i don't want to do NAT on it). Sorry i haven't read u're full mail yet, as i'm in a hurry to go home :-) But plz check out the proxy-arp option I have deployed this successfully using proxy-arp on a linux box with same network and tc -- arc_of_descent From stef.coene@docum.org Mon Sep 2 19:41:15 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 2 Sep 2002 20:41:15 +0200 Subject: [LARTC] "Transparent" shapping In-Reply-To: <1030979340.445.40.camel@sico> References: <1030979340.445.40.camel@sico> Message-ID: <200209022041.15560.stef.coene@docum.org> On Monday 02 September 2002 17:08, Esteban Maringolo wrote: > Hello, > > =09I want to do some traffic shapping with a PC in the same IP subnet t= hat > the "shaped" PC's. > =09Graphically: > > ________ __________ > > Internet-eth0| NAT/GW |eth1----eth0| TC BOX |eth1 --- SUBNET PC's... > > |________| |__________| > > NAT GW (Nat Gateway) Specs: > eth0 IP: AAA.BBB.CCC.DDD Public Address > eth1 IP: 192.168.0.1/24 > > TC BOX (Traffic Shaper): > eth0 IP: 192.168.0.2/24 > eth1 IP: 192.168.0.3/24 > > SUBNET PCs: > Netblock: 192.168.0.10/24 - 192.168.0.254/24 > Default GW IP: 192.168.0.1 > > Is possible to make that my TC BOX acts transparently for the subnet PC= s > without redefine the default GW to 192.168.0.3 (the TC inner interface)= =2E > > The intention is not add another Hop to the network, and lower the CPU > usage of the TC BOX (i don't want to do NAT on it). You can put the box in bridge mode and use the u23 filter. There is a pa= tch=20 floating around to enable iptables on the bridged box. You can asign the= box=20 an ip-address so you can reach it, but all traffic passes thru and is sha= ped. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Mon Sep 2 19:46:08 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 2 Sep 2002 20:46:08 +0200 Subject: [LARTC] htb message in messages file ! In-Reply-To: <3D738511.1030005@inbox.lv> References: <3D71C8D6.3030205@inbox.lv> <20020901121341.GA25577@outpost.ds9a.nl> <3D738511.1030005@inbox.lv> Message-ID: <200209022046.08851.stef.coene@docum.org> > >>Sep 1 09:35:27 cab1 kernel: HTB: mindelay=3D500, report it please ! > > > > Can you also report your HTB configuration, the tc commands you used? Can you post *all* the commands so we know the value of all the variables= ? > $TC filter add dev eth4 protocol ip parent 5:0 prio 2 u32 match ip ds= t > 10.0.0.0/8 match ip protocol 1 0xff flowid 5:105 Where is class 5:105 difined ? Stef ---- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Mon Sep 2 19:50:56 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 2 Sep 2002 20:50:56 +0200 Subject: [LARTC] HTB shares equally when borrowing enabled :( In-Reply-To: <3D734A8B.7030704@inf.elte.hu> References: <3D714B88.7000903@inf.elte.hu> <200209011044.39145.stef.coene@docum.org> <3D734A8B.7030704@inf.elte.hu> Message-ID: <200209022050.56380.stef.coene@docum.org> On Monday 02 September 2002 13:24, Tak=E1cs B=E1lint wrote: > Thanks Stef! The trick with setting lower maximum bandwidth works. I > convinced me that I understand now what happens :) The ISP starts to > build queues when maximal input rate is reached and releases packets > from these queues equally. Thus the prioritized connections had to wait > sometimes and it lends its guaranteed bw instead of waiting. > > I had to set the ceil to as low as 50 kbps (!). My usual maximal > throughput rate is about 55 kb/sec, while my ISP says the maximal input > rate is 512 kbit/sec. I always assigned the difference to IP > administration. Now, the maximal throughput seems to not drop until > ceil is lowered below 55 kbps. Thus I assume the rates calculated by HT= B > measure the REAL throughput without IP administration. Is it true? HTB measures each bit that's sended. So all ip-overhead included. > Sometimes the maximal input rate drops (damn ISP) and it seems to enabl= e > small "bursts" with high throughputs. Does it mean that I should to > decrease/increase the ceil when it happens? I think it depends on the > ISP queues: if they start to build, then I must. It can mean that I > can't use traffic shaping, or at least not HTB qdisc - maybe some prio > setup will do the job. You can use traffic shaping for the moments the traffic is not dropped. = If=20 you know exactly how the bursts are, you can try to enable the same burst= s=20 with htb. > What if I try to shape the outgoing traffic? Maybe it has an effect on > incoming, too. I mean if "acknowledged" information goes back slow, I > can manipulate the ISP queues, hm? It can affect incoming traffic, but I think the effect will be allmost=20 neglectable. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Krzysztof Wittek Tue Sep 3 00:14:02 2002 From: Krzysztof Wittek (Krzysztof Wittek) Date: Tue, 3 Sep 2002 01:14:02 +0200 Subject: [LARTC] can I replace sfq with wrr Message-ID: <20020902231402.GA30328@home.krzychu.net> Hello, Currently I use htb with sfq, /sbin/tc class add dev $IFACE classid 1:0 parent 1: htb rate ${RATE0}kbit \ ceil ${CEIL0}kbit burst 6k prio 0 /sbin/tc qdisc add dev $IFACE parent 1:0 sfq but it has one big "hole" - person which uses 10 tcp connections ( with download accelerator ) gets 10 times more bandwidth than normal user with one tcp session . I want bandwidth share based on IP adresses ( MAC adresses ) not tcp sessions . I've noticed that wrr could fix this problem. I wonder if new kernel and iproute2 and : /sbin/tc qdisc add dev $IFACE parent 1:0 wrr instead of /sbin/tc qdisc add dev $IFACE parent 1:0 sfq is enough to do what I need ? or I need some more complex qdisc ? Another question is if it's possible to limit bandwith like squid with delay pools ( so files smaller than eg: 2 MB are transmitted at full speed and larger files are transmitted : 0 - 2 MB full speed and anything more over 2MB is dropper do low priority class ) ? How can I do this with ipchains ( kernel 2.2 ) + htb and iptables (kernel 2.4 ) + htb ? Greets, K. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - { Krzysztof Wittek - Gliwice Poland - ICQ: 6667414 - IRCNet: Krzychu } { krzychu@gliwice.eu.org ftp://ftp.krzychu.net http://www.krzychu.net } { ==========> IPv4://3646973238 IPv6://3ffe:8010:28:2::1 <========== } - - KW6109-RIPE * + P-o-w-e-r-e-d b-y P-L-D L-i-n-u-x + * KW1-6BONE - - From tw@eter.tym.pl Tue Sep 3 12:09:05 2002 From: tw@eter.tym.pl (Tomasz Wrona) Date: Tue, 3 Sep 2002 13:09:05 +0200 (CEST) Subject: [LARTC] can I replace sfq with wrr In-Reply-To: <20020902231402.GA30328@home.krzychu.net> Message-ID: On Tue, 3 Sep 2002, Krzysztof Wittek wrote: > > /sbin/tc qdisc add dev $IFACE parent 1:0 wrr > > instead of > > /sbin/tc qdisc add dev $IFACE parent 1:0 sfq > > is enough to do what I need ? or I need some more complex qdisc ? In base it's almost enough, look at wrr doc for details. You can try esfq also [less powerfull than wrr but works simmilar] tw -- ---------------- ck.eter.tym.pl "Never let shooling disturb Your education" From karl.gaissmaier@rz.uni-ulm.de Tue Sep 3 12:13:41 2002 From: karl.gaissmaier@rz.uni-ulm.de (Karl Gaissmaier) Date: Tue, 03 Sep 2002 13:13:41 +0200 Subject: [LARTC] Q: best solution to stop traffic to huge amount of unregistered hosts References: <200209021627.g82GRsN02517@isis.cs3-inc.com> Message-ID: <3D749965.7C3B1CB2@rz.uni-ulm.de> Hi Don, Don Cohen schrieb: > > Just reading mail that arrived while I was on vacation ... > > Several points. > - In order to use the current tc you don't have to match all of the > illegal addresses (64K - 10K) - it would be easier to default to > disallow packets and match the smaller 10K that are allowed. > actually I can do this with three independent ore loosely coupled systems: iproute2 netfilter tc netfilter is to slow for 10k rules and if I use hierarchical prefixes I have a lot of chains and still ca. 500 rules in worst case. With iproute2 I could do this with a prohibit rule, but then I have the bigger amount of disallowd addresses. I think in the moment tc is the best solution, but how could this be handled on ingress shaping to a 0 kbps queue? > - What you really want, of course, is a new module that does a simple > table lookup to decide whether to classify a packet. This should be > easy to write. The hard part is filling the table - I don't even know > where your data comes from. the comes programmatically from the DNS system by a walk throug. I check once a day all Class B addresses whether they are registered. > > - I'd expect your addresses to not be uniformly distributed. A right! > reasonable routing scheme would assign different class-c's to > different departments/dorms; many class c's don't exist and you > can eliminate those immediately; those that do probably go to other > routers and those can do further filtering. > An additional benefit of this more distributed solution is that, this must be done a the central FW, because the other routers are from different vendors with even different capabilities. This would not be manageable. > at least for traffic originating inside your network, earlier > filtering prevents one class c from denying (outbound) service to > others. I'd guess that you're less concerned with outside attackers > sending to these bogus addresses without provocation from inside. Regards Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:karl.gaissmaier@rz.uni-ulm.de Network Administration Tel.: ++49 731 50-22499 From esteban.maringolo@secont.com.ar Tue Sep 3 13:46:29 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 03 Sep 2002 09:46:29 -0300 Subject: [LARTC] "Transparent" shapping In-Reply-To: <200209022041.15560.stef.coene@docum.org> References: <1030979340.445.40.camel@sico> <200209022041.15560.stef.coene@docum.org> Message-ID: <1031057190.452.45.camel@sico> --=-Kchh95oe9N4+1hF2Cy+x Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello Stef, On Mon, 2002-09-02 at 15:41, Stef Coene wrote: > On Monday 02 September 2002 17:08, Esteban Maringolo wrote: > > Hello, > > > > I want to do some traffic shapping with a PC in the same IP subnet tha= t > > the "shaped" PC's. > > Graphically: > > > > ________ __________ > > > > Internet-eth0| NAT/GW |eth1----eth0| TC BOX |eth1 --- SUBNET PC's... > > > > |________| |__________| > > > > Is possible to make that my TC BOX acts transparently for the subnet PC= s > > without redefine the default GW to 192.168.0.3 (the TC inner interface)= . > You can put the box in bridge mode and use the u23 filter. There is a pa= tch=20 > floating around to enable iptables on the bridged box. You can asign the= box=20 > an ip-address so you can reach it, but all traffic passes thru and is sha= ped. I've worked a little with bridging on linux, but you're trying to say "u32" filter, right? Because i've never heard about u23 filter (google doesn't say anything). I'll keep trying. Thanks. --=20 Esteban A. Maringolo Buenos Aires, Argentina --=-Kchh95oe9N4+1hF2Cy+x Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9dK8lDY8wt+MWh9ARAstyAKCCkM5i7/8ouOgg4FHfwvPjKhD5bACfZdtv yzBTAJaef3Ajd3M0HUvURFM= =oD6C -----END PGP SIGNATURE----- --=-Kchh95oe9N4+1hF2Cy+x-- From stef.coene@docum.org Tue Sep 3 14:53:15 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 3 Sep 2002 15:53:15 +0200 Subject: [LARTC] can I replace sfq with wrr In-Reply-To: <20020902231402.GA30328@home.krzychu.net> References: <20020902231402.GA30328@home.krzychu.net> Message-ID: <200209031553.15620.stef.coene@docum.org> On Tuesday 03 September 2002 01:14, Krzysztof Wittek wrote: > Hello, > > > Currently I use htb with sfq, > > /sbin/tc class add dev $IFACE classid 1:0 parent 1: htb rate ${RATE0}kb= it \ > ceil ${CEIL0}kbit burst 6k prio 0 > /sbin/tc qdisc add dev $IFACE parent 1:0 sfq Class 1:0 is a special class in htb. All packets queued in this class wi= ll=20 get pas thru as fast as possible. Try class 1:1 and it will work like yo= u=20 want :) > > but it has one big "hole" - person which uses 10 tcp connections ( wit= h > download accelerator ) gets 10 times more bandwidth than normal user > with one tcp session . > > I want bandwidth share based on IP adresses ( MAC adresses ) > not tcp sessions . There is hacked sfq qdisc : EFSQ. You can configure it so it uses only t= he=20 src and/or dst address to classify the packets and not the ports. I have= a=20 local copy on www.docum.org under FAQ. > Another question is if it's possible to limit bandwith like squid with > delay pools ( so files smaller than eg: 2 MB are transmitted at full sp= eed > and larger files are transmitted : 0 - 2 MB full speed and anything mor= e > over 2MB is dropper do low priority class ) ? > How can I do this with ipchains ( kernel 2.2 ) + htb and > iptables (kernel 2.4 ) + htb ? I think there is a patch for iptables so you can mark packets based on th= e=20 size of the file where they belong to. But I'm not sure. If it exist, y= ou=20 can redirect big files to a queue with lower bandwidth. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Sep 3 14:54:06 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 3 Sep 2002 15:54:06 +0200 Subject: [LARTC] "Transparent" shapping In-Reply-To: <1031057190.452.45.camel@sico> References: <1030979340.445.40.camel@sico> <200209022041.15560.stef.coene@docum.org> <1031057190.452.45.camel@sico> Message-ID: <200209031554.06395.stef.coene@docum.org> > I've worked a little with bridging on linux, but you're trying to say > "u32" filter, right? Because i've never heard about u23 filter (google > doesn't say anything). Indeed u32 :) > I'll keep trying. Good luck :) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From david_list@boreham.org Tue Sep 3 15:11:29 2002 From: david_list@boreham.org (David Boreham) Date: Tue, 3 Sep 2002 07:11:29 -0700 Subject: [LARTC] SMP in regards to routing/filtering References: <20020831115517.GA4069@outpost.ds9a.nl> Message-ID: <004801c25353$cc2cbc30$220aa8c0@mtbrook.boreham.org> > > Just wondering if it's worth grabbing an extra processor for the box, or if > > it will largely go unused. It is also possible that two processors will be _slower_ than one, due to contention. So it will be worthwhile to test with one CPU disabled (UP kernel) just to see what happens. From mabrown-lartc@securepipe.com Wed Sep 4 06:25:16 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Wed, 4 Sep 2002 00:25:16 -0500 (CDT) Subject: [LARTC] RPDB && routing locally generated (and marked) traffic Message-ID: Hello all, I'm using iproute2 + ipchains and have a question about locally generated packets. I have noticed that I have no problem marking packets in the input chain from sources other than my router. These packets are marked and routed exactly as I expect. Now supposing I want to mark particular outbound packets which are locally generated. The only solution I have found so far (http://www.quintillion.com/moat/ipsec+routing/iproute2.html) suggests # ip rule add iif lo lookup $other But the side effects are tremendous. All of the processes on this box suddenly start using the $other routing table (exactly as I told them to!), which is not what I desire. If I try marking the special locally generated packets with # ipchains -I input -p tcp -s $OUTIF $PORT -d $ALL -m $other -j ACCEPT nothing changes. The return traffic ends up flowing out my main link according to my main routing table. When I look at the ipchains HOWTO on how packets traverse filters, http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html#ss4.1 I fear that the routing decision has already been made by the time the local process is generating a packet. Is there any way around this problem? -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From mabrown-lartc@securepipe.com Wed Sep 4 06:29:27 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Wed, 4 Sep 2002 00:29:27 -0500 (CDT) Subject: [LARTC] iproute2; NAT routes in tables other than local Message-ID: Hello again (sorry to be so chatty tonight), I wanted to confirm that NAT routes must be in table local in order to function properly. I have tried adding nat routes to tables other than the local table without any success. Even if I proxy-arp for the IP I'm trying to NAT, my router never receives packets bound for the NAT IP. I have worked around the problem another way, but am curious if I am misunderstanding. I have re-read the ip-cref document seeking the answer to this question, but find no answer. Thanks all, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From marcus@ingate.com Wed Sep 4 08:27:30 2002 From: marcus@ingate.com (Marcus Sundberg) Date: 04 Sep 2002 09:27:30 +0200 Subject: [LARTC] How to match all packets with a tc filter Message-ID: Hi, I have several specific filters classifying packets into different classes, and in addition to those I would like to have a filter with low priority (filters are matched in priority order, right?) which matches everything, in order to explicitly put such traffic where it belongs. Is there a cleaner way to do this than using the u32 filter and matching a random field with a zero mask? //Marcus -- ---------------------------------------+-------------------------- Marcus Sundberg | Firewalls with SIP & NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/ From devik@cdi.cz Wed Sep 4 08:20:51 2002 From: devik@cdi.cz (devik) Date: Wed, 4 Sep 2002 09:20:51 +0200 (CEST) Subject: [LARTC] Re: HTB source code - kernel and tc In-Reply-To: <3FFBC907DD03A34CA4410C5C745DEB12D555E2@wnimail.woodsidenet.com> Message-ID: Ehh it is the same for 2 years. luxik.cdi.cz/~devik/qos/htb/ .. On Tue, 3 Sep 2002, Jingsong Fu wrote: > Hi Devik, > Where can I find the HTB source code for kernel and tc? > Thanks, > Jingsong > From luciano@elo.com.br Wed Sep 4 12:46:53 2002 From: luciano@elo.com.br (Luciano Lima) Date: Wed, 04 Sep 2002 08:46:53 -0300 Subject: [LARTC] Limit FTP traffic References: <20020904042620.17171.92196.Mailman@outpost> Message-ID: <3D75F2AD.5000804@elo.com.br> Hi all, I'm trying to shape ftp traffic. I saw in netstat that when a ftp get is started, a session is established using high ports (above 1024) randomic. So I can't guess what port will be used. What could be the tc filter parameters for this ? I think marking packet is a way, but I'm using ipchains in the router, wich does not have established parameter. Any sugestion ? Thanks, Luciano Lima ========== ELO Internet So Luis - MA - Brazil From stef.coene@docum.org Wed Sep 4 19:03:00 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 4 Sep 2002 20:03:00 +0200 Subject: [LARTC] Limit FTP traffic In-Reply-To: <3D75F2AD.5000804@elo.com.br> References: <20020904042620.17171.92196.Mailman@outpost> <3D75F2AD.5000804@elo.com.br> Message-ID: <200209042003.00591.stef.coene@docum.org> On Wednesday 04 September 2002 13:46, Luciano Lima wrote: > Hi all, > > I'm trying to shape ftp traffic. I saw in netstat that when a ftp get i= s > started, a session is established using high ports (above 1024) > randomic. So I can't guess what port will be used. > What could be the tc filter parameters for this ? > > I think marking packet is a way, but I'm using ipchains in the router, > wich does not have established parameter. The establish parameter will help you neither. But there is a patch for=20 iptables (sorry) so you can mark ftp-data packets. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Sep 4 19:04:21 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 4 Sep 2002 20:04:21 +0200 Subject: [LARTC] How to match all packets with a tc filter In-Reply-To: References: Message-ID: <200209042004.21050.stef.coene@docum.org> On Wednesday 04 September 2002 09:27, Marcus Sundberg wrote: > Hi, > > I have several specific filters classifying packets into different > classes, and in addition to those I would like to have a filter > with low priority (filters are matched in priority order, right?) > which matches everything, in order to explicitly put such traffic > where it belongs. Is there a cleaner way to do this than using > the u32 filter and matching a random field with a zero mask? If you use htb you can use the default option. This determines the class= =20 where all non-classified packets will be put. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From marcus@ingate.com Wed Sep 4 19:17:20 2002 From: marcus@ingate.com (Marcus Sundberg) Date: 04 Sep 2002 20:17:20 +0200 Subject: [LARTC] How to match all packets with a tc filter In-Reply-To: <200209042004.21050.stef.coene@docum.org> References: <200209042004.21050.stef.coene@docum.org> Message-ID: Stef Coene writes: > If you use htb you can use the default option. This determines the class > where all non-classified packets will be put. Yeah I know, but I use several different qdiscs and would prefer to have a general way to do it with filters. //Marcus -- ---------------------------------------+-------------------------- Marcus Sundberg | Firewalls with SIP & NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/ From stef.coene@docum.org Wed Sep 4 19:27:27 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 4 Sep 2002 20:27:27 +0200 Subject: [LARTC] How to match all packets with a tc filter In-Reply-To: References: <200209042004.21050.stef.coene@docum.org> Message-ID: <200209042027.27215.stef.coene@docum.org> On Wednesday 04 September 2002 20:17, Marcus Sundberg wrote: > Stef Coene writes: > > If you use htb you can use the default option. This determines the c= lass > > where all non-classified packets will be put. > > Yeah I know, but I use several different qdiscs and would prefer to > have a general way to do it with filters. The I think the u32 trick is the best you can do. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From lartc@24x7linux.com Wed Sep 4 22:27:41 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Wed, 4 Sep 2002 23:27:41 +0200 Subject: [LARTC] How to match all packets with a tc filter In-Reply-To: <200209042027.27215.stef.coene@docum.org> References: <200209042004.21050.stef.coene@docum.org> <200209042027.27215.stef.coene@docum.org> Message-ID: <20020904212741.GB5139@localhost> On Wednesday, 04 September 2002, at 20:27:27 +0200, Stef Coene wrote: > > Yeah I know, but I use several different qdiscs and would prefer to > > have a general way to do it with filters. > The I think the u32 trick is the best you can do. > Or tag all traffic with ipchains/iptables and add a tc filter of type fwmark matching this tag. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From Alexey Talikov Thu Sep 5 08:06:45 2002 From: Alexey Talikov (Alexey Talikov) Date: Thu, 5 Sep 2002 12:06:45 +0500 Subject: [LARTC] Limit FTP traffic In-Reply-To: <3D75F2AD.5000804@elo.com.br> References: <20020904042620.17171.92196.Mailman@outpost> <3D75F2AD.5000804@elo.com.br> Message-ID: <6612430083.20020905120645@texlab.com.uz> Hello Luciano, Try helper patch from patch-o-matic or use last kernel. I see it in 2.4.20pre4 If you want to match all packets belonging to ftp-sessions: (both ftp-command and ftp-data connections) iptables -t nat -A PREROUTING -m helper --helper ftp -j MARK --set-mark 1 use irc for irc-sessions. You'll also need the bidirectional irc match for irc matching to work properly. ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From mdew@mdew.dyndns.org Thu Sep 5 11:09:38 2002 From: mdew@mdew.dyndns.org (mdew) Date: 05 Sep 2002 22:09:38 +1200 Subject: [LARTC] matching classid with iptables and stuff Message-ID: <1031220579.14431.12.camel@mdew> --=-SbMXKKPCBj1lQjZ5x0tc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable # 40.10 Paul 40.11 Mark tc class add dev imq0 parent 40:1 classid 40:10 htb rate 5Kbps ceil 7Kbps burst 2k tc class add dev imq0 parent 40:1 classid 40:11 htb rate 5Kbps ceil 6Kbps burst 3k # 40:12 Mike 40:13 Brian tc class add dev imq0 parent 40:1 classid 40:12 htb rate 200Kbps ceil 220Kbps burst 4k tc class add dev imq0 parent 40:1 classid 40:13 htb rate 200Kbps ceil 240Kbps burst 4k how do i show 40:1x is the ip w.x.y.z (and for the other ip's) ? Working off the prensentation..=20 Basically we have a 256Kb connection (yes small fry) ## We Start at the root of the device, eth0 # Install HTB as the root qdisc, names it 1:0. tc qdisc add dev eth0 root handle 1: htb # This attaches a shaping HTB to the HTB root, 256kps with a 2k bucket tc gdisc add dev eth0 parent 1: classid 1:1 htb rate 256Kbps burst 20k #The first class is guaranteed 5Kbps of the 256Kbps, but can grow to 7 if available #The second class however can take up to 240kbits (changed) # 1.10 Paul 1.11 Mark tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5Kbps ceil 7Kbps burst 2k tc class add dev eth0 parent 1:1 classid 1:11 htb rate 5Kbps ceil 6Kbps burst 3k # 1:12 Mike 1:13 Brian tc class add dev eth0 parent 1:1 classid 1:12 htb rate 200Kbps ceil 220Kbs burst 4k tc class add dev eth0 parent 1:1 classid 1:13 htb rate 200Kbps ceil 240Kbs burst 4k ## Filtering to Classify traffic # When a packet enters the qdisc it needs to be classified. This is done with 'tc filters': U32=3D"tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" $U32 match ip dport 25 0xffff flowid 1:10 $U32 match ip sport 80 0xffff flowid 1:11 ## Shape incoming Traffic (IMQ) modprobe imq numdevs=3D1 tc qdisc add dec imq0 root handle 40: htb default 22 tc class add dev imq0 parent 40: classid 40:1 htb rate 256Kbps burst 20k # 40.10 Paul 40.11 Mark tc class add dev imq0 parent 40:1 classid 40:10 htb rate 5Kbps ceil 7Kbps burst 2k tc class add dev imq0 parent 40:1 classid 40:11 htb rate 5Kbps ceil 6Kbps burst 3k # 40:12 Mike 40:13 Brian tc class add dev imq0 parent 40:1 classid 40:12 htb rate 200Kbps ceil 220Kbps burst 4k tc class add dev imq0 parent 40:1 classid 40:13 htb rate 200Kbps ceil 240Kbps burst 4k tc class add dev imq0 parent 40:10 classid 40:11 htb rate 240Kbps burst 4k iptables -t mangle -A PREROUTING -i eth0 -j IMQ # Push all Pauls traffic through IMQ iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 10.0.0.9 -j IMQ --todev 0 ip link setup imq0 up am i close? :) --=-SbMXKKPCBj1lQjZ5x0tc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9dy1iH5J/xul0J+4RAnn3AJ9dvQHayeI5zio3CsPufDPlX1kNSwCbBpUp ytoGYHxkhFVfcBvD4gYbtIQ= =pKSC -----END PGP SIGNATURE----- --=-SbMXKKPCBj1lQjZ5x0tc-- From mdew@mdew.dyndns.org Thu Sep 5 11:23:30 2002 From: mdew@mdew.dyndns.org (mdew) Date: 05 Sep 2002 22:23:30 +1200 Subject: [LARTC] matching classid with iptables and stuff In-Reply-To: <1031220579.14431.12.camel@mdew> References: <1031220579.14431.12.camel@mdew> Message-ID: <1031221410.13583.18.camel@mdew> --=-PASFK36Iq0A/IFezP8wA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable http://mdew.dyndns.org/network.jpg for a pic :) --=-PASFK36Iq0A/IFezP8wA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9dzChH5J/xul0J+4RAhNNAJ9MYQEZu2YIWiwiHm6ZwKMlquy14wCcDKv7 1IpKwc+gIaotLIiZUdsTNfc= =Dpyk -----END PGP SIGNATURE----- --=-PASFK36Iq0A/IFezP8wA-- From esteban.maringolo@secont.com.ar Thu Sep 5 17:41:08 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 05 Sep 2002 13:41:08 -0300 Subject: [LARTC] "Transparent" shapping In-Reply-To: <02090221085005.03104@sanitarium> References: <1030979340.445.40.camel@sico> <02090221085005.03104@sanitarium> Message-ID: <1031244069.590.13.camel@inercia> --=-X+Z8gvSrMvF9CXR1vk8J Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-09-02 at 12:38, Rohan Almeida wrote: > Esteban Maringolo thus wrote: > > I want to do some traffic shapping with a PC in the same IP subnet tha= t > > the "shaped" PC's. > > The intention is not add another Hop to the network, and lower the CPU > > usage of the TC BOX (i don't want to do NAT on it). >=20 > Sorry i haven't read u're full mail yet, > as i'm in a hurry to go home :-) > But plz check out the proxy-arp option > I have deployed this successfully using > proxy-arp on a linux box with same network > and tc I dosn't see it as a solution, perhaps i misunderstand the concept. The search keeps going... Does anybody knows where to find the "Bridger Filter" patch for kernel 2.4.18? I want to be able to use bridging and netfilter (with iptables) capabilities simultaneously in my linuxbox. Thanks. --=20 Esteban A. Maringolo Buenos Aires, Argentina --=-X+Z8gvSrMvF9CXR1vk8J Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9d4kjDY8wt+MWh9ARAs4FAJ9wlYaPIQexTDp/tMe4weFo6XJemgCdFkBQ x9hcqaRbwbO5dDZx0WwXDAE= =22/V -----END PGP SIGNATURE----- --=-X+Z8gvSrMvF9CXR1vk8J-- From marcus@ingate.com Thu Sep 5 17:49:06 2002 From: marcus@ingate.com (Marcus Sundberg) Date: 05 Sep 2002 18:49:06 +0200 Subject: [LARTC] How to match all packets with a tc filter In-Reply-To: <20020904212741.GB5139@localhost> References: <200209042004.21050.stef.coene@docum.org> <200209042027.27215.stef.coene@docum.org> <20020904212741.GB5139@localhost> Message-ID: Jose Luis Domingo Lopez writes: > On Wednesday, 04 September 2002, at 20:27:27 +0200, > Stef Coene wrote: > > > > Yeah I know, but I use several different qdiscs and would prefer to > > > have a general way to do it with filters. > > The I think the u32 trick is the best you can do. > > > Or tag all traffic with ipchains/iptables and add a tc filter of type > fwmark matching this tag. I'm already using fwmark matching for everything except the default filter. Because fwmark doesn't have a mask but only does exact matches I can't use that for the default filter without generating lots of extra iptables rules. //Marcus -- ---------------------------------------+-------------------------- Marcus Sundberg | Firewalls with SIP & NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/ From mabrown-lartc@securepipe.com Thu Sep 5 17:52:43 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Thu, 5 Sep 2002 11:52:43 -0500 (CDT) Subject: [LARTC] "Transparent" shapping In-Reply-To: <1031244069.590.13.camel@inercia> Message-ID: Esteban, I think this is the stuff you need (but I'm not positive!): http://bridge.sourceforge.net/ http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff -Martin : > > I want to do some traffic shapping with a PC in the same IP subnet that : > > the "shaped" PC's. : > > The intention is not add another Hop to the network, and lower the CPU : > > usage of the TC BOX (i don't want to do NAT on it). : > : > Sorry i haven't read u're full mail yet, : > as i'm in a hurry to go home :-) : > But plz check out the proxy-arp option : > I have deployed this successfully using : > proxy-arp on a linux box with same network : > and tc : : I dosn't see it as a solution, perhaps i misunderstand the concept. : : The search keeps going... : : Does anybody knows where to find the "Bridger Filter" patch for kernel : 2.4.18? : : I want to be able to use bridging and netfilter (with iptables) : capabilities simultaneously in my linuxbox. : : Thanks. : : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From anish_46628" Hello Sir, I want some help from you. I have my configuration like this. I have three machines. PC1,PC2,PC3. hub hub PC1--------------------PC2-----------------------PC3 eth0 eth0,eth1 eth0 I want to work my configuration like diffserv. I am generating traffic from PC3 and sending it to PC1 via PC2(as a router)and from PC2 to PC1 also. So i have two kinds of traffic. I want to do these things: 1. Mark the packets going out from PC3 towards PC1 via PC2. 2. I have my rules and filters with tc in PC2. Means i want to contol the traffic from PC2. Based on the mark which i put on the traffic going out from PC3 i want to put the traffic in different-differnt classes. Means i want to filter the traffic based on the mark on traffic. It would be helpful if i am able to mark the TOS bits so that i can see it in tcdump or ethereal. 3. Traffic going out from PC2 and generated by PC2 itself should have different differnt mark so that the traffic can be filtered based on the mark. Please suggest sthing related to this. Waiting for your reply. Anish Mehta. ENST-Bretagne. From stef.coene@docum.org Fri Sep 6 06:52:02 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 6 Sep 2002 07:52:02 +0200 Subject: [LARTC] How to match all packets with a tc filter In-Reply-To: References: <20020904212741.GB5139@localhost> Message-ID: <200209060751.51508.stef.coene@docum.org> On Thursday 05 September 2002 18:49, Marcus Sundberg wrote: > Jose Luis Domingo Lopez writes: > > On Wednesday, 04 September 2002, at 20:27:27 +0200, > > > > Stef Coene wrote: > > > > Yeah I know, but I use several different qdiscs and would prefer = to > > > > have a general way to do it with filters. > > > > > > The I think the u32 trick is the best you can do. > > > > Or tag all traffic with ipchains/iptables and add a tc filter of type > > fwmark matching this tag. > > I'm already using fwmark matching for everything except the default > filter. Because fwmark doesn't have a mask but only does exact > matches I can't use that for the default filter without generating > lots of extra iptables rules. Only one iptables rule is needed. As first rule in the iptables list, ma= tch=20 all packets with 1. Then process the rules in the iptables list and mark= the=20 packets with an other mark if you want. All packets not matched again, w= ill=20 keep the mark 1. This is your "default" mark. =20 You only need a filter to put the packets marked with 1 in a default clas= s and=20 you have your default filter. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Fri Sep 6 06:55:09 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 6 Sep 2002 07:55:09 +0200 Subject: [LARTC] matching classid with iptables and stuff In-Reply-To: <1031220579.14431.12.camel@mdew> References: <1031220579.14431.12.camel@mdew> Message-ID: <200209060748.18022.stef.coene@docum.org> On Thursday 05 September 2002 12:09, mdew wrote: > # 40.10 Paul 40.11 Mark > tc class add dev imq0 parent 40:1 classid 40:10 htb rate 5Kbps ceil > 7Kbps burst 2k > tc class add dev imq0 parent 40:1 classid 40:11 htb rate 5Kbps ceil > 6Kbps burst 3k > # 40:12 Mike 40:13 Brian > tc class add dev imq0 parent 40:1 classid 40:12 htb rate 200Kbps ceil > 220Kbps burst 4k > tc class add dev imq0 parent 40:1 classid 40:13 htb rate 200Kbps ceil > 240Kbps burst 4k > how do i show 40:1x is the ip w.x.y.z (and for the other ip's) ? What do you mean with "show"? Do you want to put the traffic from/to the= =20 different ip's in the different class? If yes, you need some filters (li= ke=20 u32 or fw). > Working off the prensentation.. > Basically we have a 256Kb connection (yes small fry) > > ## We Start at the root of the device, eth0 > # Install HTB as the root qdisc, names it 1:0. > tc qdisc add dev eth0 root handle 1: htb > # This attaches a shaping HTB to the HTB root, 256kps with a 2k bucket > tc gdisc add dev eth0 parent 1: classid 1:1 htb rate 256Kbps burst 20k > > #The first class is guaranteed 5Kbps of the 256Kbps, but can grow to 7 > if available > #The second class however can take up to 240kbits (changed) > # 1.10 Paul 1.11 Mark > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5Kbps ceil 7Kbps > burst 2k > tc class add dev eth0 parent 1:1 classid 1:11 htb rate 5Kbps ceil 6Kbps > burst 3k > # 1:12 Mike 1:13 Brian > tc class add dev eth0 parent 1:1 classid 1:12 htb rate 200Kbps ceil > 220Kbs burst 4k > tc class add dev eth0 parent 1:1 classid 1:13 htb rate 200Kbps ceil > 240Kbs burst 4k > > ## Filtering to Classify traffic > # When a packet enters the qdisc it needs to be classified. This is don= e > with 'tc filters': > U32=3D"tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" > $U32 match ip dport 25 0xffff flowid 1:10 > $U32 match ip sport 80 0xffff flowid 1:11 > > ## Shape incoming Traffic (IMQ) > modprobe imq numdevs=3D1 > tc qdisc add dec imq0 root handle 40: htb default 22 > tc class add dev imq0 parent 40: classid 40:1 htb rate 256Kbps burs= t > 20k > # 40.10 Paul 40.11 Mark > tc class add dev imq0 parent 40:1 classid 40:10 htb rate 5Kbps ceil > 7Kbps burst 2k > tc class add dev imq0 parent 40:1 classid 40:11 htb rate 5Kbps ceil > 6Kbps burst 3k > # 40:12 Mike 40:13 Brian > tc class add dev imq0 parent 40:1 classid 40:12 htb rate 200Kbps ceil > 220Kbps burst 4k > tc class add dev imq0 parent 40:1 classid 40:13 htb rate 200Kbps ceil > 240Kbps burst 4k > > tc class add dev imq0 parent 40:10 classid 40:11 htb rate 240Kbps burs= t > 4k ??? Why are you doing this? The parent has a ceil of 7Kbps, so this cla= ss=20 will get never more then 7Kbps. > iptables -t mangle -A PREROUTING -i eth0 -j IMQ > # Push all Pauls traffic through IMQ > iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 10.0.0.9 -j IMQ > --todev 0 > ip link setup imq0 up > > am i close? :) Don't you have to put also the other traffic (Mark, Mike, Brian) traffic = in=20 the imq0 device ? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Sebastian.Bleikamp@web.de Fri Sep 6 09:52:29 2002 From: Sebastian.Bleikamp@web.de (Sebastian Bleikamp) Date: Fri, 06 Sep 2002 10:52:29 +0200 Subject: [LARTC] Wondershaper Message-ID: <3D786CCD.6050809@web.de> Hi ! I´ve been using the wonderful wondershaper from chapter 15.8 of the LARTC Howto for some time. It´s really wonderful. Actually, I use the version from http://freshmeat.net/projects/wshaper/?topic_id=87 Now I tried to put some hosts to low priority, and it doesn´t work. The traffic is splitted equally between the noprio and the other hosts. Is this because I use ip masquerading, and all the traffic seems (for the shaper) to come from one host ? The U32 filter and the other setup works correctly, because e.g. ssh traffic on port 23 always has highest priority. Has anybody an idea how to fix it ? I think a nice sketch about the order of routing/postrouting and traffic shaping would help me. Sebastian -=> Sebastian Bleikamp -=> EMail: -=> Phone: +49-172-6545394 From stef.coene@docum.org Fri Sep 6 10:27:40 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 6 Sep 2002 11:27:40 +0200 Subject: [LARTC] Wondershaper In-Reply-To: <3D786CCD.6050809@web.de> References: <3D786CCD.6050809@web.de> Message-ID: <200209061123.15759.stef.coene@docum.org> On Friday 06 September 2002 10:52, Sebastian Bleikamp wrote: > Hi ! > > I=B4ve been using the wonderful wondershaper from chapter 15.8 of the > LARTC Howto for some time. It=B4s really wonderful. That's exactly why it's called the wondershaper :) > Actually, I use the version from > http://freshmeat.net/projects/wshaper/?topic_id=3D87 > > Now I tried to put some hosts to low priority, and it doesn=B4t work. T= he > traffic is splitted equally between the noprio and the other hosts. > Is this because I use ip masquerading, and all the traffic seems (for > the shaper) to come from one host ? The U32 filter and the other setup > works correctly, because e.g. ssh traffic on port 23 always has highest > priority. > > Has anybody an idea how to fix it ? You can use an other filter : fw. This filter can use the iptables/ipcha= ins=20 mark. And you can put this mark when the packets enters the LAN NIC so y= ou=20 can use the ip-address of the incoming packets from your lan, mark this=20 packets and use the mark on the internet NIC. > I think a nice sketch about the order of routing/postrouting and traffi= c > shaping would help me. I have one on docum.org, but it needs some updates. It's the one posted = some=20 months ago on this list. You can find it under KPTD. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Sebastian.Bleikamp@web.de Fri Sep 6 12:47:09 2002 From: Sebastian.Bleikamp@web.de (Sebastian Bleikamp) Date: Fri, 06 Sep 2002 13:47:09 +0200 Subject: [LARTC] Wondershaper References: <3D786CCD.6050809@web.de> <200209061123.15759.stef.coene@docum.org> <3D787C47.2040605@web.de> <200209061234.03303.stef.coene@docum.org> Message-ID: <3D7895BD.80807@web.de> Stef Coene schrieb: > Try efsq. It's SFQ (so each "flow" gets an equal chance to send something). > But efsq uses only dst/src addres and not dst/src address/port like sfq. > Ideal to kill download managers because all traffic form/to the same hosts is > considered as one stream. > I have a link on docum.org under FAQ. I will test it, thnx. But another question: I tried your solution via fwmark, and it works. At least when the router is forwarding. I can slow down hosts on my LAN this way. If i try to slow the gateway/router down, it fails. I have added a mark to all outgoing traffic on ppp0, which comes from the router, to the OUTGOING/mangle table. But it doesn´t work this way. But from the sketch on your homepage this should work. I already checked the IPs and devices and they are correct. Any suggestions ? ;-) Seb. -=> Sebastian Bleikamp -=> EMail: -=> Phone: +49-172-6545394 From eth@finsiel.ro Fri Sep 6 13:39:16 2002 From: eth@finsiel.ro (eth) Date: Fri, 06 Sep 2002 15:39:16 +0300 Subject: [LARTC] Examples from HTB home page... Message-ID: <3D78A1F4.2080200@finsiel.ro> ... do not work anymore. Anybody with a hint? I've got a fully functional HTB setup and just wanted to replace the kernel from 2.4.17 to 2.4.19. In the end the modified tc binary doesn't recognize "tc filter add" (yet it does accept qdisc show and recognizes htb...) I've downloaded the 2.4.19 from kernel.org, iproute2 (2.4.7), installed the patches (to kern and iproute) and ended with a kernel / tc combo that at the following example (taken from from HTB page): tc qdisc add dev eth0 root handle 1:0 htb default 12 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 flowid 1:11 ... chokes at the "tc filter add " with: RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument As far as I can tell this *should* work, it did 6 months ago on a 2.4.17. From p0wer@tl.krakow.pl Fri Sep 6 14:53:10 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Fri, 6 Sep 2002 15:53:10 +0200 (CEST) Subject: [LARTC] Compile problems... Message-ID: Hi. I have some problems while applying WRR, ESFQ and HTB3 patches and then compiling kernel. The HTB patch rejects some lines. I haven't tried to change the order of the patches but I suppose it won't work anyway. On 2.4.18 i tried HTB3 and ESFQ and it compiled fine... The other thing is that after compiling the 2.4.18 with ESFQ I need to recompile the iproute package. There are also some problems with it. Even without patches, it wont compile. Here are the errors: ll_proto.c:36: `ETH_P_ECHO' undeclared here (not in a function) ll_proto.c:36: Initializer element is not constant ll_proto.c:36: (near initialization for `llproto_names[1].id') There are probably some inckudes missing, but i don;t know which ones ! I searches thorugh package database and installed almost all net-related -dev libraries. Please help me and tell me which libraries are needed. I use Debian Woody. -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From lhyuan@bumper.sytes.net Fri Sep 6 15:46:21 2002 From: lhyuan@bumper.sytes.net (lhyuan@bumper.sytes.net) Date: Fri, 6 Sep 2002 22:46:21 +0800 Subject: [LARTC] Compile problems... In-Reply-To: (message from =?iso-8859-2?Q?Rados=B3aw_=A3oboda?= on Fri, 6 Sep 2002 15:53:10 +0200 (CEST)) References: Message-ID: <200209061446.g86EkLi02839@bumper.sytes.net> >> The other thing is that after compiling the 2.4.18 with ESFQ I need to >> recompile the iproute package. There are also some problems with it. Even >> without patches, it wont compile. Here are the errors: >> ll_proto.c:36: `ETH_P_ECHO' undeclared here (not in a function) >> ll_proto.c:36: Initializer element is not constant >> ll_proto.c:36: (near initialization for `llproto_names[1].id') just goto the ./lib/ll_proto.c file and comment out that line, then everything will compile. I remember someone mentions this long ago, and it works fine for me. cheers yuan -- The man who finds his homeland sweet is still a tender beginner; he to whom every soil is as his native one is already strong; but he is perfect to whom the entire world is as a foreign land. From yxjia@site.uottawa.ca Fri Sep 6 21:45:15 2002 From: yxjia@site.uottawa.ca (yuxiao) Date: Fri, 6 Sep 2002 13:45:15 -0700 Subject: [LARTC] questiona about CBQ algorithm in Linux Message-ID: <004701c255e6$4df731c0$775b7a89@BWWIL23> This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C255AB.A1307030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stef and Alexey I have read some documents about CBQ algorithm from = http://www.icir.org/floyd/cbq.html but still have some question about CBQ in Linux . 1. First estimator can estimate how much bandwidth already USED per = class. one estimating algorithm is EWMA (exponential weighted moving = average), how about Linux implemenatation about estimator?=20 also do you have link for this algorithm? I canot find it. 2. If I want to see how CBQ work in Linux, any suggestion how I start = read these code? there are a lot of files under tc folder, q_cbq.c tc_cbq.c... 3. In linux how CBQ measure used bandwidth per class? does it measure bandwith bits/sec? If it measue bandwidth every seconds, is there any = way to collect these data (grap these data)?=20 4. I read stef's monitor.pl, it is based on firwall code. why didn't use = CBQ's measurement result if it can do (I am not sure..)? 5. In stef's bandwidth monitor, I am not sure whether it is per-flow = based or per-class based. if it is per-flowed based, how can I modify to = per-class? I belivee CBQ can estimate used bandwidth PER CLASS. For example you have two flow belong to one class. 6. In Linux how CBQ distribute the excess bandwidth between sibling = class when "borrow" enabled. what algorithm it used? which code? 7. Can HTB do the same job as CBQ right now, can HTB do borrow ?=20 Thanks in advance best regards yuxiao Jia ------=_NextPart_000_0044_01C255AB.A1307030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Stef and Alexey
 
 
I have read some documents about CBQ = algorithm from=20 http://www.icir.org/floyd/cbq= .html
but still have some question about CBQ = in=20 Linux
.
1. First estimator can = estimate how much=20 bandwidth already USED per class. one estimating algorithm is EWMA=20 (exponential weighted moving average), how about  Linux = implemenatation=20 about estimator? 
also do you have link for this algorithm? I = canot find=20 it.

2. If I want to see how CBQ work in Linux,  any = suggestion how I=20 start read these code?
there are a lot of files under tc folder, = q_cbq.c=20 tc_cbq.c...

3. In linux how CBQ measure = used bandwidth=20 per class? does it measure
bandwith bits/sec? If it measue bandwidth = every=20 seconds, is there any way to
collect these data (grap these data)?=20
 
4. I read stef's monitor.pl, it is = based on firwall=20 code. why didn't use CBQ's measurement result if it can do (I am not=20 sure..)?
 
5. In stef's bandwidth monitor, = I am not sure=20 whether it is per-flow based or per-class based. if it is per-flowed = based, how=20 can I modify to per-class? I belivee CBQ can estimate used bandwidth PER = CLASS.
For example  you have two flow = belong to one=20 class.
 
6. In Linux how CBQ distribute the = excess bandwidth=20 between sibling class
when "borrow" enabled.  what algorithm it = used?=20 which code?
 
7. Can HTB do the same job as CBQ = right now,=20 can HTB do borrow ?
 
Thanks in advance
 
 
best regards
 
 
yuxiao = Jia

------=_NextPart_000_0044_01C255AB.A1307030-- From kuznet@ms2.inr.ac.ru Fri Sep 6 19:31:18 2002 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Fri, 6 Sep 2002 22:31:18 +0400 (MSD) Subject: [LARTC] Re: questiona about CBQ algorithm in Linux In-Reply-To: <004701c255e6$4df731c0$775b7a89@BWWIL23> from "yuxiao" at Sep 6, 2 01:45:15 pm Message-ID: <200209061831.WAA07683@sex.inr.ac.ru> Hello! > average), how about Linux implemenatation about estimator?=20 > also do you have link for this algorithm? I canot find it. The questions are answered in papers, references are in comments in sch_cbq.c, look at http://www.icir.org/floyd/cbq.html > 3. In linux how CBQ measure used bandwidth per class? does it measure > bandwith bits/sec? No, it does not measure bandwdith at all. Read papers, please. > 7. Can HTB do the same job as CBQ right now, can HTB do borrow ?=20 Yes, it does. And does it better than CBQ. Alexey From stef.coene@docum.org Fri Sep 6 19:56:48 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 6 Sep 2002 20:56:48 +0200 Subject: [LARTC] questiona about CBQ algorithm in Linux In-Reply-To: <004701c255e6$4df731c0$775b7a89@BWWIL23> References: <004701c255e6$4df731c0$775b7a89@BWWIL23> Message-ID: <200209062056.34848.stef.coene@docum.org> > 4. I read stef's monitor.pl, it is based on firwall code. why didn't us= e > CBQ's measurement result if it can do (I am not sure..)? With iptables you can monitor everything you want. It can also be used t= o=20 determine who is using the most bandwidth. Actually it's a bandwidth mon= itor=20 and not a tc monitor. But I use it to monitor tc :). I have some other scripts that uses the counters in cbq if you are inters= ted=20 (see the page under the gui link). They create nice looking graphs. So = ne=20 real-time measurement like monitor.pl. > 5. In stef's bandwidth monitor, I am not sure whether it is per-flow b= ased > or per-class based. if it is per-flowed based, how can I modify to > per-class? I belivee CBQ can estimate used bandwidth PER CLASS. For exa= mple > you have two flow belong to one class. Again, you can montir whatever you want with monitor.pl as long as you ca= n=20 match the packets with iptables. There are other monitors (I just don't=20 remember them right now), who can identify flows and monitor them. =20 > 6. In Linux how CBQ distribute the excess bandwidth between sibling cla= ss > when "borrow" enabled. what algorithm it used? which code? > > 7. Can HTB do the same job as CBQ right now, can HTB do borrow ? Yes : class 1 with rate =3D 100, ceil =3D 100 class 11 with rate =3D 25, ceil =3D 100 class 12 with rate =3D 75, ceil =3D 100 Class 11 and 12 borrow the same 100. Class 12 will get 75% of the link, = class=20 11 15%. Stef From lartc@24x7linux.com Fri Sep 6 21:31:29 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Fri, 6 Sep 2002 22:31:29 +0200 Subject: [LARTC] Requset regarding packet marking. In-Reply-To: <20020905165753.16892.qmail@webmail7.rediffmail.com> References: <20020905165753.16892.qmail@webmail7.rediffmail.com> Message-ID: <20020906203129.GC5094@localhost> On Thursday, 05 September 2002, at 16:57:53 -0000, anish_46628 wrote: > 3. Traffic going out from PC2 and generated by PC2 itself should > have different differnt mark so that the traffic can be filtered > based on the mark. > With linux kernel 2.4.x, packets go through different sets of rules when "traversing" the box. A packet in transit will enter PREROUTING, pass on to FORWARD and finally to POSTROUTING just before being queued to be sent out on the physical interface. On the other hand, locally generated packets go first to OUTPUT and afterwards to POSTROUTING. Compare this to kernels 2.2.x when an in-transit packet would be seen at input, forward and output. There is an _excelent_ reference on iptables you should check to get the details of what you can do and how: http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From lartc@24x7linux.com Fri Sep 6 21:47:22 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Fri, 6 Sep 2002 22:47:22 +0200 Subject: [LARTC] Examples from HTB home page... In-Reply-To: <3D78A1F4.2080200@finsiel.ro> References: <3D78A1F4.2080200@finsiel.ro> Message-ID: <20020906204722.GD5094@localhost> On Friday, 06 September 2002, at 15:39:16 +0300, eth wrote: > tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src > 1.2.3.4 match ip dport 80 0xffff flowid 1:10 > tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src > 1.2.3.4 flowid 1:11 > ... chokes at the "tc filter add " with: > RTNETLINK answers: Invalid argument > RTNETLINK answers: Invalid argument > As far as I can tell this *should* work, it did 6 months ago on a 2.4.17. > Maybe your kernel configuration changed in the meantime, and with the new version you didn't compile some necessary features. Have just tried your exact configuration with a 2.4.20-pre1 kernel and it works OK. It seems you missed "U32 classifier" support either compiled in or as a module. My box show the following modules loaded after trying your config: Module Size Used by Not tainted cls_u32 4484 1 (autoclean) sch_htb 18016 1 (autoclean) pcnet32 13120 1 (autoclean) mii 1104 0 (autoclean) [pcnet32] -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From lartc@24x7linux.com Fri Sep 6 21:56:58 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Fri, 6 Sep 2002 22:56:58 +0200 Subject: [LARTC] Compile problems... In-Reply-To: References: Message-ID: <20020906205658.GE5094@localhost> On Friday, 06 September 2002, at 15:53:10 +0200, Rados?aw ?oboda wrote: > I have some problems while applying WRR, ESFQ and HTB3 patches and then > compiling kernel. The HTB patch rejects some lines. I haven't tried to > change the order of the patches but I suppose it won't work anyway. On > 2.4.18 i tried HTB3 and ESFQ and it compiled fine... > Linux kernel 2.4.20-pre1 and higher include support for HTB3 by default, so maybe it could be easier to apply just two patches :-) > The other thing is that after compiling the 2.4.18 with ESFQ I need to > recompile the iproute package. There are also some problems with it. Even > without patches, it wont compile. Here are the errors: > I have "adapted" Debian Woody iproute package to include support for HTB3 (instead of HTB2 in the standard package). Download it from: ftp://ftp.24x7linux.com/iproute/ A quote from a message I sent to Debian bug #147550 (with respect to patching "iproute" package to add support for HTB3): "With respect to userspace, at least building is plain simple. Delete tc/q_thb.c, put q_htb.c from htb3.6_tc.diff (as downloaded from http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz). Then copy /usr/src/linux-2.4.20-pre1/include/linux/pkt_sched.h to include/linux/pkt_sched.h and rebuild." Hope this helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From cparpart@surakware.net Sat Sep 7 03:25:42 2002 From: cparpart@surakware.net (Christian Parpart) Date: Sat, 7 Sep 2002 04:25:42 +0200 Subject: [LARTC] htb/iptables: incoming vs. outgoing shaping? Message-ID: <200209070425.51264.cparpart@surakware.net> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, there's something I really don't understand. What I wanna=20 do is to shape my incoming _and_ my outgoing traffic in speperate=20 queues. I have a 256kbit up and 256kbit down link on eth1. I want to use iptables to set the marks. wan=3Deth1 lowin=3D1 # ; highin=3D2 lowout=3D5 # ; highout=3D6 # mark incoming traffic iptables -t mangle -A PREROUTING -i $wan -p tcp --sport 80 \ -j MARK --set-mark $lowin # mark outgoing traffic iptables -t mangle -A OUTPUT -o $wan -p tcp --dport 80 \ -j MARK --set-mark $lowout tc qdisc handle add dev $wan root handle 1:0 htb tc class add dev $wan parent 1:0 classid 1:1 htb rate 256kbit # input shapi= ng tc class add dev $wan parent 1:0 classid 1:2 htb rate 256kbit # output shap= ing tc class add dev $wan parent 1:1 classid 1:11 htb rate 64kbit # low in tc class add dev $wan parent 1:1 classid 1:12 htb rate 192kbit # high in tc class add dev $wan parent 1:2 classid 1:21 htb rate 64kbit # low out tc class add dev $wan parent 1:2 classid 1:22 htb rate 192kbit # high out tc filter add dev $wan parent 1:1 protocol ip prio 1 \ fw handle $lowin flowid 1:11 tc filter add dev $wan parent 1:2 protocol ip prio 1 \ fw handle $lowout flowid 1:21 What I think I have done is that I've created to main queues (1:1 and 1:2)= =20 each one rating up to 256kbit. Each main queue got devided into a queue for= =20 low traffic (non priorized) and one high traffic (priorized). Then, I attatched the filter that anchors the iptables marked ip packets to= =20 their corresponding queue. But does this really work? I also notices somewhere that you just can shape= =20 input traffic, and for output you need a special IMQ target for iptables,=20 why? And why doesn't it work in that way?=20 =46urthermore, is this right how I mark the outgoing traffic? should this b= e=20 done in POSTROUTING, or even somewhere else? It's that we've=20 PREROUTING,INPUT, FORWARD,OUTPUT and POSTROUTING have in table mangle. Please, would you help me solving my problem? Thanks in advance, Christian Parpart. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9eWOpPpa2GmDVhK0RAgYtAJ9EgbgblPUgeB+1C0rbBMGE2u6MCACdFpOh ZIoj8dQQ3GYpWjxHrgTT/5Y=3D =3Dhq5D =2D----END PGP SIGNATURE----- From stef.coene@docum.org Sat Sep 7 10:32:02 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 7 Sep 2002 11:32:02 +0200 Subject: [LARTC] htb/iptables: incoming vs. outgoing shaping? In-Reply-To: <200209070425.51264.cparpart@surakware.net> References: <200209070425.51264.cparpart@surakware.net> Message-ID: <200209071131.51304.stef.coene@docum.org> > But does this really work? I also notices somewhere that you just can s= hape > input traffic, and for output you need a special IMQ target for iptable= s, > why? And why doesn't it work in that way? it' the other way around. You can only shape outgoing traffic. You shap= e=20 traffic by influencing the queue where the packets wait to be sended. Fo= r=20 incoming packets, there is no queue, so you can't shape incoming traffic. But, there is a IMQ device. You can put all incoming packets in this vir= tual=20 device and this device has a queue. So you can shape incoming traffic. B= ut=20 this can/will introduce extra delays. There is also a ingress qdisc. Th= is=20 qdisc contains no queue, but you can attach filter to it. And you can us= e=20 policers on this filter. A policer is sort of shaper on a filter : it wi= ll=20 only match the packets at a certain rate. So you can match packets at a=20 certain rate and throttle incoming traffic. Howerver, this is a one-leve= l=20 setup so you can't create a hierarchical setup like you can with htb/cbq. You never provided a ceil parameter when you created the classes. So the= =20 class will never borrow unused bandwidth from each other. And to be able to shape the traffic, you have to shape at 250 kbit or so.= So=20 YOU are the bottleneck and not your router/modem. You will loose some=20 bandwidth, but you will be able the shape it. So if shaping is not worki= ng,=20 try to lower the total bandwidth you send/receive. I suggest reading some docs : lartc.org in general and I have some more i= nfo=20 about shaping on docum.org. > Furthermore, is this right how I mark the outgoing traffic? should this= be > done in POSTROUTING, or even somewhere else? It's that we've > PREROUTING,INPUT, FORWARD,OUTPUT and POSTROUTING have in table mangle. It depends if the traffic is generated locally or forwarded. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From blueflux@koffein.net Sat Sep 7 12:19:25 2002 From: blueflux@koffein.net (Oskar Andreasson) Date: Sat, 7 Sep 2002 13:19:25 +0200 (CEST) Subject: iptables tutorial moved (was Re: [LARTC] Requset regarding packet marking.) In-Reply-To: <20020906203129.GC5094@localhost> Message-ID: Sorry to nitpick, but the tutorial actually moved some time ago. There was simply too much troubles with hosting, so I finally got a domain of my own (frozentux.net), and the tutorial is available at http://iptables-tutorial.frozentux.net, hosted by haringstad.com which looks really really good so far. Of course, if they would go down, i will always be able to move the DNS to somewhere else in the future instead... Anyways, just to let everyone know. I got some other things under development as well right now, hence the iptables stuff is pretty much at a "featurefreeze". Have a nice day! ---- Oskar Andreasson http://iptables-tutorial.haringstad.com http://people.unix-fu.org/andreasson/ mailto:blueflux@koffein.net On Fri, 6 Sep 2002, Jose Luis Domingo Lopez wrote: > On Thursday, 05 September 2002, at 16:57:53 -0000, > anish_46628 wrote: > > > 3. Traffic going out from PC2 and generated by PC2 itself should > > have different differnt mark so that the traffic can be filtered > > based on the mark. > > > With linux kernel 2.4.x, packets go through different sets of rules when > "traversing" the box. A packet in transit will enter PREROUTING, pass on > to FORWARD and finally to POSTROUTING just before being queued to be > sent out on the physical interface. On the other hand, locally generated > packets go first to OUTPUT and afterwards to POSTROUTING. Compare this > to kernels 2.2.x when an in-transit packet would be seen at input, forward > and output. > > There is an _excelent_ reference on iptables you should check to get the > details of what you can do and how: > http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html > > From mdew@mdew.dyndns.org Sat Sep 7 14:53:41 2002 From: mdew@mdew.dyndns.org (mdew) Date: 08 Sep 2002 01:53:41 +1200 Subject: [LARTC] imq0 not being detected Message-ID: <1031406822.988.6.camel@mdew> --=-v77a7p/jO4+6IOTC1sEg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable mdew:~# tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1=20 Cannot find device "imq0" mdew:~# lsmod Module Size Used by Not tainted ipt_REDIRECT 728 0 (autoclean) ipt_MARK 728 2 (autoclean) iptable_mangle 2100 1 (autoclean) ipt_REJECT 2712 4 (autoclean) iptable_filter 1672 1 (autoclean) ip_nat_ftp 3760 0 (unused) ip_conntrack_ftp 3616 0 [ip_nat_ftp] ip_nat_irc 3024 0 (unused) iptable_nat 19608 3 [ipt_REDIRECT ip_nat_ftp ip_nat_irc] ip_conntrack_irc 2720 0 [ip_nat_irc] ip_conntrack 21372 3 [ipt_REDIRECT ip_nat_ftp ip_conntrack_ftp ip_nat rc iptable_nat ip_conntrack_irc] keybdev 1632 0 (unused) 8139too 12904 2=20 mdew:~# modprobe ipt_IMQ mdew:~# tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1 Cannot find device "imq0" mdew:~# lsmod Module Size Used by Not tainted ipt_IMQ 760 0 (unused) ipt_REDIRECT 728 0 (autoclean) ipt_MARK 728 2 (autoclean) iptable_mangle 2100 1 (autoclean) ipt_REJECT 2712 4 (autoclean) iptable_filter 1672 1 (autoclean) ip_nat_ftp 3760 0 (unused) ip_conntrack_ftp 3616 0 [ip_nat_ftp] ip_nat_irc 3024 0 (unused) iptable_nat 19608 3 [ipt_REDIRECT ip_nat_ftp ip_nat_irc] ip_conntrack_irc 2720 0 [ip_nat_irc] ip_conntrack 21372 3 [ipt_REDIRECT ip_nat_ftp ip_conntrack_ftp ip_nat rc iptable_nat ip_conntrack_irc] keybdev 1632 0 (unused) 8139too 12904 2=20 mdew:~# modprobe imq mdew:~# tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1 RTNETLINK answers: Invalid argument (imq/htb kernel and iptables patch applied) --=-v77a7p/jO4+6IOTC1sEg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9egTlH5J/xul0J+4RAnxrAJ9bsT0RAHXTdL/QaCtvLrQjaybKBQCfS9BN dnClch6SI7p7Lb4SZkm59I4= =XXuK -----END PGP SIGNATURE----- --=-v77a7p/jO4+6IOTC1sEg-- From mdew@mdew.dyndns.org Sat Sep 7 22:37:18 2002 From: mdew@mdew.dyndns.org (mdew) Date: 08 Sep 2002 09:37:18 +1200 Subject: [LARTC] imq0 not being detected In-Reply-To: <1031406822.988.6.camel@mdew> References: <1031406822.988.6.camel@mdew> Message-ID: <1031434639.987.9.camel@mdew> --=-SyPNgG4FbaAaKfXURryH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ip_conntrack (992 buckets, 7936 max) imq driver loaded. HTB init, kernel part version 3.6 HTB: need tc/htb version 3 (minor is 6), you have 1 HTB init, kernel part version 3.6 HTB: need tc/htb version 3 (minor is 6), you have 1 HTB init, kernel part version 3.6 HTB: need tc/htb version 3 (minor is 6), you have 1 HTB init, kernel part version 3.6 HTB: need tc/htb version 3 (minor is 6), you have 10 from dmesg.. what version of htb is needed? Im using 3.6 (well i think) On Sun, 2002-09-08 at 01:53, mdew wrote: > mdew:~# tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1=20 > Cannot find device "imq0" > mdew:~# lsmod > Module Size Used by Not tainted > ipt_REDIRECT 728 0 (autoclean) > ipt_MARK 728 2 (autoclean) > iptable_mangle 2100 1 (autoclean) > ipt_REJECT 2712 4 (autoclean) > iptable_filter 1672 1 (autoclean) > ip_nat_ftp 3760 0 (unused) > ip_conntrack_ftp 3616 0 [ip_nat_ftp] > ip_nat_irc 3024 0 (unused) > iptable_nat 19608 3 [ipt_REDIRECT ip_nat_ftp ip_nat_irc] > ip_conntrack_irc 2720 0 [ip_nat_irc] > ip_conntrack 21372 3 [ipt_REDIRECT ip_nat_ftp > ip_conntrack_ftp ip_nat rc iptable_nat ip_conntrack_irc] > keybdev 1632 0 (unused) > 8139too 12904 2=20 > mdew:~# modprobe ipt_IMQ > mdew:~# tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1 > Cannot find device "imq0" > mdew:~# lsmod > Module Size Used by Not tainted > ipt_IMQ 760 0 (unused) > ipt_REDIRECT 728 0 (autoclean) > ipt_MARK 728 2 (autoclean) > iptable_mangle 2100 1 (autoclean) > ipt_REJECT 2712 4 (autoclean) > iptable_filter 1672 1 (autoclean) > ip_nat_ftp 3760 0 (unused) > ip_conntrack_ftp 3616 0 [ip_nat_ftp] > ip_nat_irc 3024 0 (unused) > iptable_nat 19608 3 [ipt_REDIRECT ip_nat_ftp ip_nat_irc] > ip_conntrack_irc 2720 0 [ip_nat_irc] > ip_conntrack 21372 3 [ipt_REDIRECT ip_nat_ftp > ip_conntrack_ftp ip_nat rc iptable_nat ip_conntrack_irc] > keybdev 1632 0 (unused) > 8139too 12904 2=20 > mdew:~# modprobe imq > mdew:~# tc qdisc add dev imq0 handle 1: root htb default 12 r2q 1 > RTNETLINK answers: Invalid argument >=20 > (imq/htb kernel and iptables patch applied) >=20 >=20 >=20 >=20 --=-SyPNgG4FbaAaKfXURryH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9enGOH5J/xul0J+4RAp/OAKCCkiNOfc5jiSXVoyxs1fWswR/XBQCfe8vI 34AWea+mLKdmRS5amPBgWKc= =S8cT -----END PGP SIGNATURE----- --=-SyPNgG4FbaAaKfXURryH-- From lartc@24x7linux.com Sun Sep 8 00:30:32 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Sun, 8 Sep 2002 01:30:32 +0200 Subject: [LARTC] imq0 not being detected In-Reply-To: <1031434639.987.9.camel@mdew> References: <1031406822.988.6.camel@mdew> <1031434639.987.9.camel@mdew> Message-ID: <20020907233032.GA14652@localhost> On Sunday, 08 September 2002, at 09:37:18 +1200, mdew wrote: > HTB init, kernel part version 3.6 > HTB: need tc/htb version 3 (minor is 6), you have 10 > As the messages say, it seems like a version mismatch between the kernel an userspace (tc) side of HTB. Get HTB3 from: http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz The tarball includes two patches, one for the kernel and the other for tc (as well as a precompiled "tc" binary"): -rw-rw-r-- devik/devik 53438 2002-05-25 11:15:45 htb3.6_2.4.17.diff -rw-rw-r-- devik/devik 9302 2002-05-25 11:11:58 htb3.6_tc.diff -rwxrwxr-x devik/devik 101992 2002-05-12 22:26:53 tc Kernel versions 2.4.20-pre1 and up include HTB3 by default. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From Igor Suvorov Sun Sep 8 05:43:47 2002 From: Igor Suvorov (Igor Suvorov) Date: Sun, 8 Sep 2002 08:43:47 +0400 Subject: [LARTC] overlimits value in statistics Message-ID: <5472371064.20020908084347@khrunichev.com> Good Day! I was interested with a question what exactly is considered in overlimits parameter to count of statistics. I thought, that this parameter should specify number of the packages which have exceeded valid boundary. But, for example statistics on one of queues: class cbq 20:12 parent 20:10 leaf 8015: rate 128Kbit (bounded) prio 5 Sent 23171746615 bytes 43153460 pkts (dropped 81179, overlimits 641814686) backlog 1p Queue has passed 43153460 packets, but has exceeded a valid level of 641814686 packets. What it? Errors? -- Igor From stef.coene@docum.org Sun Sep 8 10:57:43 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 8 Sep 2002 11:57:43 +0200 Subject: [LARTC] overlimits value in statistics In-Reply-To: <5472371064.20020908084347@khrunichev.com> References: <5472371064.20020908084347@khrunichev.com> Message-ID: <200209081157.15189.stef.coene@docum.org> On Sunday 08 September 2002 06:43, Igor Suvorov wrote: > Good Day! > > I was interested with a question what exactly > is considered in overlimits parameter to count > of statistics. I thought, that this parameter > should specify number of the packages which > have exceeded valid boundary. But, for example > statistics on one of queues: I have some more info on www.docum.org (FAQ page) : overlimits : Packet is not sended due to ceil or rate restrictions=20 So there was to much data in the class. But don't believe this too much. = It=20 depends on how often the qdisc looked for packet. This counter is increme= nted=20 per unsucessfull DRR loop and it's possible that this happens more then o= nce=20 per packet.=20 Each dropped packet is overlimited.=20 > class cbq 20:12 parent 20:10 leaf 8015: rate 128Kbit (bounded) prio 5 > Sent 23171746615 bytes 43153460 pkts (dropped 81179, overlimits 641814= 686) > backlog 1p > > Queue has passed 43153460 packets, but has > exceeded a valid level of 641814686 packets. > What it? Errors? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Igor Suvorov Sun Sep 8 13:07:23 2002 From: Igor Suvorov (Igor Suvorov) Date: Sun, 8 Sep 2002 16:07:23 +0400 Subject: [LARTC] overlimits value in statistics In-Reply-To: <200209081157.15189.stef.coene@docum.org> References: <5472371064.20020908084347@khrunichev.com> <200209081157.15189.stef.coene@docum.org> Message-ID: <12498987426.20020908160723@khrunichev.com> Good Day, Stef! Sunday, September 8, 2002, 1:57:43 PM, you wrote: >> I was interested with a question what exactly >> is considered in overlimits parameter to count >> of statistics. I thought, that this parameter >> should specify number of the packages which >> have exceeded valid boundary. But, for example >> statistics on one of queues: SC> I have some more info on www.docum.org (FAQ page) : SC> overlimits : Packet is not sended due to ceil or rate restrictions SC> So there was to much data in the class. But don't believe this too much. It SC> depends on how often the qdisc looked for packet. This counter is incremented SC> per unsucessfull DRR loop and it's possible that this happens more then once SC> per packet. SC> Each dropped packet is overlimited. Thus this parameter is really useless? I have paid attention, that at speed of passinge of packages approximately 40 pps growth rate of this parameter about (near) 150000 pps. -- Igor From mdew@mdew.dyndns.org Sun Sep 8 15:45:23 2002 From: mdew@mdew.dyndns.org (mdew) Date: 09 Sep 2002 02:45:23 +1200 Subject: [LARTC] imq0 not being detected In-Reply-To: <20020907233032.GA14652@localhost> References: <1031406822.988.6.camel@mdew> <1031434639.987.9.camel@mdew> <20020907233032.GA14652@localhost> Message-ID: <1031496324.1338.47.camel@mdew> --=-p+sOBI5xwyvLwrlD/QxH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2002-09-08 at 11:30, Jose Luis Domingo Lopez wrote: > On Sunday, 08 September 2002, at 09:37:18 +1200, > mdew wrote: >=20 > > HTB init, kernel part version 3.6 > > HTB: need tc/htb version 3 (minor is 6), you have 10 > >=20 > As the messages say, it seems like a version mismatch between the kernel > an userspace (tc) side of HTB. Get HTB3 from: > http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz >=20 > The tarball includes two patches, one for the kernel and the other for=20 > tc (as well as a precompiled "tc" binary"): > -rw-rw-r-- devik/devik 53438 2002-05-25 11:15:45 htb3.6_2.4.17.diff > -rw-rw-r-- devik/devik 9302 2002-05-25 11:11:58 htb3.6_tc.diff > -rwxrwxr-x devik/devik 101992 2002-05-12 22:26:53 tc >=20 > Kernel versions 2.4.20-pre1 and up include HTB3 by default. >=20 > --=20 > Jose Luis Domingo Lopez > Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa= 1) > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ Im still having the same problems with HTB, I've upgraded to 2.4.20pre6+IMQ..(loaded not as module, but directly into the kernel) HTB init, kernel part version 3.6 HTB: need tc/htb version 3 (minor is 6), you have 10 mdew:/sbin# ls -al tc* -rwxr-xr-x 1 root root 94368 Sep 8 13:15 tc -rwxr-xr-x 1 root root 153792 Apr 3 06:46 tc-2 tc-2 is the debian package(htb compt), tc is the package from http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz mdew:/sbin# tc-2 qdisc add dev imq0 handle 1: root htb default 1 RTNETLINK answers: Invalid argument mdew:~# modprobe imq numdevs=3D1 mdew:~# tc qdisc add dev imq0 handle 1: root htb default 1 RTNETLINK answers: Invalid argument mdew:~# lsmod Module Size Used by Not tainted ipt_IMQ 760 0 (unused) ipt_MARK 792 2 (autoclean) ipt_REJECT 2840 4 (autoclean) ipt_REDIRECT 792 0 (autoclean) ip_conntrack_ftp 3760 1 (autoclean) ip_nat_ftp 2896 0 (unused) ip_conntrack_irc 2992 1 (autoclean) ip_nat_irc 2288 0 (unused) iptable_nat 14328 3 (autoclean) [ipt_REDIRECT ip_nat_ftp ip_nat_irc] ip_conntrack 16448 3 (autoclean) [ipt_REDIRECT ip_conntrack_ftp ip_nat_ftp ip_conntrack_irc ip_nat_irc iptable_nat] iptable_mangle 2160 1 (autoclean) iptable_filter 1668 1 (autoclean) keybdev 1664 0 (unused) 8139too 13704 2 mdew:/sbin# uname -a Linux mdew 2.4.20-pre5-xfs #1 Sun Sep 8 14:04:31 NZST 2002 i686 unknown unknown GNU/Linux http://mdew.dyndns.org/config-2.4 suggestions guys? mdew:/harddisk/apache# cat /proc/cpuinfo=20 processor : 0 vendor_id : CyrixInstead cpu family : 6 model : 2 model name : M II 3.5x Core/Bus Clock stepping : 8 cpu MHz : 233.865 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr bogomips : 466.94 --=-p+sOBI5xwyvLwrlD/QxH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9e2KDH5J/xul0J+4RAisBAJ9/ngZGHeKxBZLTdHGfnTDcuymc2QCfSFLO 1AQRSyvGBAsfgk/XtyL43A8= =TruM -----END PGP SIGNATURE----- --=-p+sOBI5xwyvLwrlD/QxH-- From mdew@mdew.dyndns.org Sun Sep 8 16:10:17 2002 From: mdew@mdew.dyndns.org (mdew) Date: 09 Sep 2002 03:10:17 +1200 Subject: [LARTC] imq0 not being detected In-Reply-To: <1031496324.1338.47.camel@mdew> References: <1031406822.988.6.camel@mdew> <1031434639.987.9.camel@mdew> <20020907233032.GA14652@localhost> <1031496324.1338.47.camel@mdew> Message-ID: <1031497818.1338.49.camel@mdew> --=-Hzjnz7/5gbMoaIxoAIme Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-09-09 at 02:45, mdew wrote: ah dont worry bout it...my fuckup :) > On Sun, 2002-09-08 at 11:30, Jose Luis Domingo Lopez wrote: > > On Sunday, 08 September 2002, at 09:37:18 +1200, > > mdew wrote: > >=20 > > > HTB init, kernel part version 3.6 > > > HTB: need tc/htb version 3 (minor is 6), you have 10 > > >=20 > > As the messages say, it seems like a version mismatch between the kerne= l > > an userspace (tc) side of HTB. Get HTB3 from: > > http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz > >=20 > > The tarball includes two patches, one for the kernel and the other for=20 > > tc (as well as a precompiled "tc" binary"): > > -rw-rw-r-- devik/devik 53438 2002-05-25 11:15:45 htb3.6_2.4.17.diff > > -rw-rw-r-- devik/devik 9302 2002-05-25 11:11:58 htb3.6_tc.diff > > -rwxrwxr-x devik/devik 101992 2002-05-12 22:26:53 tc > >=20 > > Kernel versions 2.4.20-pre1 and up include HTB3 by default. > >=20 > > --=20 > > Jose Luis Domingo Lopez > > Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6= aa1) > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >=20 >=20 > Im still having the same problems with HTB, I've upgraded to > 2.4.20pre6+IMQ..(loaded not as module, but directly into the kernel) >=20 > HTB init, kernel part version 3.6 > HTB: need tc/htb version 3 (minor is 6), you have 10 >=20 > mdew:/sbin# ls -al tc* > -rwxr-xr-x 1 root root 94368 Sep 8 13:15 tc > -rwxr-xr-x 1 root root 153792 Apr 3 06:46 tc-2 >=20 > tc-2 is the debian package(htb compt), tc is the package from > http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz >=20 > mdew:/sbin# tc-2 qdisc add dev imq0 handle 1: root htb default 1 > RTNETLINK answers: Invalid argument > mdew:~# modprobe imq numdevs=3D1 > mdew:~# tc qdisc add dev imq0 handle 1: root htb default 1 > RTNETLINK answers: Invalid argument >=20 > mdew:~# lsmod > Module Size Used by Not tainted > ipt_IMQ 760 0 (unused) > ipt_MARK 792 2 (autoclean) > ipt_REJECT 2840 4 (autoclean) > ipt_REDIRECT 792 0 (autoclean) > ip_conntrack_ftp 3760 1 (autoclean) > ip_nat_ftp 2896 0 (unused) > ip_conntrack_irc 2992 1 (autoclean) > ip_nat_irc 2288 0 (unused) > iptable_nat 14328 3 (autoclean) [ipt_REDIRECT ip_nat_ftp > ip_nat_irc] > ip_conntrack 16448 3 (autoclean) [ipt_REDIRECT > ip_conntrack_ftp ip_nat_ftp ip_conntrack_irc ip_nat_irc iptable_nat] > iptable_mangle 2160 1 (autoclean) > iptable_filter 1668 1 (autoclean) > keybdev 1664 0 (unused) > 8139too 13704 2 >=20 > mdew:/sbin# uname -a > Linux mdew 2.4.20-pre5-xfs #1 Sun Sep 8 14:04:31 NZST 2002 i686 unknown > unknown GNU/Linux >=20 > http://mdew.dyndns.org/config-2.4 >=20 > suggestions guys? >=20 > mdew:/harddisk/apache# cat /proc/cpuinfo=20 > processor : 0 > vendor_id : CyrixInstead > cpu family : 6 > model : 2 > model name : M II 3.5x Core/Bus Clock > stepping : 8 > cpu MHz : 233.865 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr > bogomips : 466.94 >=20 >=20 --=-Hzjnz7/5gbMoaIxoAIme Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9e2hZH5J/xul0J+4RAugmAJ9c/038XXE1F4G38WbWLGV4Uk12/ACdGqBA 45Q3a3IkzL9NhFX+dJrl6cY= =CJKd -----END PGP SIGNATURE----- --=-Hzjnz7/5gbMoaIxoAIme-- From p0wer@tl.krakow.pl Sun Sep 8 20:22:11 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Sun, 8 Sep 2002 21:22:11 +0200 (CEST) Subject: [LARTC] Compile problems... In-Reply-To: <200209061446.g86EkLi02839@bumper.sytes.net> Message-ID: On Fri, 6 Sep 2002 lhyuan@bumper.sytes.net wrote: > just goto the ./lib/ll_proto.c file and comment out that line, > then everything will compile. I remember someone mentions this > long ago, and it works fine for me. Thanks. It helped. I found this clue in ESFQ docs after your post :) It worked out the right way. -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From Xorader Babka Mon Sep 9 06:17:46 2002 From: Xorader Babka (Xor) Date: Mon, 9 Sep 2002 09:17:46 +0400 Subject: [LARTC] Counters of CLASSes HTB Message-ID: <75848246964.20020909091746@uic.nnov.ru> Hello, lartc. # tc -s -d class show dev imq0 class htb 1:1 root leaf 10: prio 7 quantum 200000 rate 40Mbit ceil 90Mbit burst 256Kb/8 mpu 0b cburst 119545b/8 mpu 0b level 0 Sent 4599841 bytes 18384 pkts (dropped 0, overlimits 0) rate 6bps lended: 18386 borrowed: 0 giants: 0 tokens: 40950 ctokens: 8298 class htb 1:2 root "and so on...." Can I reset "Sent bytes and pkts" into zero(0) without recreate class ? I want to collect traffic statistic from classes (very comfortable...) by method "every night get this values for traffic logs and resets its". If not, may by somebody known better method without recreate class ? And this post is IDEA to do new feature in HTB ;) Example: tc class reset dev imq0 classid 1:1 -- Xor mailto:xor@uic.nnov.ru aka Molchanov Alexander mailto:a.molchanov@transtelecom-nn.ru From nick@fluffyspider.com.au Mon Sep 9 06:22:10 2002 From: nick@fluffyspider.com.au (Nick) Date: Mon, 9 Sep 2002 15:22:10 +1000 (EST) Subject: [LARTC] Counters of CLASSes HTB In-Reply-To: <75848246964.20020909091746@uic.nnov.ru> Message-ID: Hi, Isn't the usual way of collecting stats of this kind, you get the value when you start monitoring and then the value when you want to stop and take the difference. This way if you want measurements of different periods its only the programs doing the measureing that change not the device producing the readings, and you can have multiple readers of different periods. Just my 2c Nick On Mon, 9 Sep 2002, Xor wrote: > Hello, lartc. > > # tc -s -d class show dev imq0 > > class htb 1:1 root leaf 10: prio 7 quantum 200000 rate 40Mbit ceil 90Mbit burst > 256Kb/8 mpu 0b cburst 119545b/8 mpu 0b level 0 > Sent 4599841 bytes 18384 pkts (dropped 0, overlimits 0) > rate 6bps > lended: 18386 borrowed: 0 giants: 0 > tokens: 40950 ctokens: 8298 > > class htb 1:2 root > "and so on...." > > > Can I reset "Sent bytes and pkts" into zero(0) without recreate class > ? I want to collect traffic statistic from classes (very comfortable...) > by method "every night get this values for traffic logs and resets > its". > If not, may by somebody known better method without recreate class ? > And this post is IDEA to do new feature in HTB ;) > Example: > tc class reset dev imq0 classid 1:1 > > From Xorader Babka Mon Sep 9 07:02:21 2002 From: Xorader Babka (Xor) Date: Mon, 9 Sep 2002 10:02:21 +0400 Subject: Re[2]: [LARTC] Counters of CLASSes HTB In-Reply-To: References: Message-ID: <35850921810.20020909100221@uic.nnov.ru> Hello, Nick. You wrote Monday, September 09, 2002, 9:22:10 AM: N> Hi, N> Isn't the usual way of collecting stats of this kind, you get the N> value when you start monitoring and then the value when you want to stop N> and take the difference. This way if you want measurements of different N> periods its only the programs doing the measureing that change not the N> device producing the readings, and you can have multiple readers of N> different periods. ... and what about overlimit counters ? Example: counters was max values two (or more) time every some times ? I will not argue... I understand that can to do read different more often, but reset counters is more suitable %) PS. thanks! N> On Mon, 9 Sep 2002, Xor wrote: >> Can I reset "Sent bytes and pkts" into zero(0) without recreate class >> ? I want to collect traffic statistic from classes (very comfortable...) >> by method "every night get this values for traffic logs and resets >> its". >> If not, may by somebody known better method without recreate class ? >> And this post is IDEA to do new feature in HTB ;) >> Example: >> tc class reset dev imq0 classid 1:1 >> >> -- Xor mailto:xor@uic.nnov.ru From raptor@tvskat.net Mon Sep 9 18:59:54 2002 From: raptor@tvskat.net (raptor) Date: Mon, 9 Sep 2002 13:59:54 -0400 Subject: [LARTC] /proc interface OR graphing again ? Message-ID: <20020909135954.7e3864f0.raptor@tvskat.net> hi, I was searching in the arhives(for tcng-htb patch, still searching !!) and found a discussion about /proc interface for the ip-statistics/qos ..... is there any advance on this ? Current practice is to install ipchains/iptables for counting the traffic and then graph the results with ip"something!" (computionaly intensive).... i probably will take the approach a separate station in promicious mode.. but availability of the counters in the /proc can streamline the things alot and give a quick way with simple scripts to handle those things... And the idea to polling this statistics later with mrtg via net-snmp is good :") thanx alot raptor@tvskat.net PS. If anyone has the tcng-htb patch nearby, send it to me please :") thanx From michael.oshea@commtech.ie Mon Sep 9 15:20:51 2002 From: michael.oshea@commtech.ie (Michael O'Shea) Date: Mon, 9 Sep 2002 15:20:51 +0100 Subject: [LARTC] HTB and per-connection bandwidth allocation Message-ID: <46D691ED7233D511AF0B0090277A532D1CD942@mail.commtech.ie> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2580C.19D2EA60 Content-Type: text/plain; charset="iso-8859-1" Hi, How do I allocate a guaranteed rate to each individual connection. For example I can allocate, say 1Mb, to all HTTP traffic by defining the appropriate class & filter. In this case, if I have one connection it will get all 1M; if I have 100 then each connection will get ~ 10k. But supposing I want to allocate 10k per individual connection regardless of the number of connections - so if I have only one connection it gets 10k...20 get 20*10k and if I go above 100 any extra connections are dropped. This allows a guaranteed level of service per connection. I cannot see how to achieve this in HTB. Thanks Michael ------_=_NextPart_001_01C2580C.19D2EA60 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
How do I allocate a guaranteed rate to each individual connection.
For example I can allocate, say 1Mb, to all HTTP traffic by defining the appropriate class & filter. In this case, if I have one connection it will get all 1M; if I have 100 then each connection will get ~ 10k. But supposing I want to allocate 10k per individual connection regardless of the number of connections - so if I have only one connection it gets 10k...20 get 20*10k and if I go above 100 any extra connections are dropped. This allows a guaranteed level of service per connection.
I cannot see how to achieve this in HTB.
 
Thanks
Michael
------_=_NextPart_001_01C2580C.19D2EA60-- From pape@rbg.informatik.tu-darmstadt.de Mon Sep 9 15:43:47 2002 From: pape@rbg.informatik.tu-darmstadt.de (Sebastian 'spax' Pape) Date: Mon, 9 Sep 2002 16:43:47 +0200 (MEST) Subject: [LARTC] HTB and per-connection bandwidth allocation In-Reply-To: <46D691ED7233D511AF0B0090277A532D1CD942@mail.commtech.ie> References: <46D691ED7233D511AF0B0090277A532D1CD942@mail.commtech.ie> Message-ID: hi! imho there's an iplimit-patch (at patchomatic) - you should be able to limit the numer of connections to 100 with this... just a guess Sebastian -- Sebastian 'spax' Pape | Better to remain silent and be thought a fool mailto: sebastian@p-a-p-e.de | than to speak and remove all doubt. gpg: http://p-a-p-e.de/gpg.asc | --- Do you want to know more? http://www.p-a-p-e.de/ --- From rmocius@auste.elnet.lt Mon Sep 9 16:19:21 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Mon, 9 Sep 2002 16:19:21 +0100 Subject: [LARTC] routing to 2 different Internet connections Message-ID: <015d01c25814$478f5080$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_015A_01C2581C.A7DFDD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, I have iptables rules: iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE iptables -A POSTROUTING -t nat -o eth2 -j MASQUERADE That will masquerade all packets going out of the two external = interfaces. How to make a routing with iproute2 to direct packets from=20 10.105.105.100-105 via eth0 and to direct packets from the rest of and 10.105.105.0/24 via eth2 ? Thanks in advance Rimas ------=_NextPart_000_015A_01C2581C.A7DFDD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
I have iptables rules:
iptables -A=20 POSTROUTING -t nat -o eth0 -j MASQUERADE
iptables -A POSTROUTING -t = nat -o=20 eth2 -j MASQUERADE
That will masquerade all packets going out of the = two=20 external interfaces.

How to make a routing with iproute2 to = direct=20 packets from
10.105.105.100-105 via eth0 and to direct packets from = the rest=20 of and
10.105.105.0/24 via eth2 ?
Thanks in advance
 
Rimas
 
------=_NextPart_000_015A_01C2581C.A7DFDD30-- From mabrown-lartc@securepipe.com Mon Sep 9 16:31:01 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Mon, 9 Sep 2002 10:31:01 -0500 (CDT) Subject: [LARTC] routing to 2 different Internet connections In-Reply-To: <015d01c25814$478f5080$6e69690a@rimas> Message-ID: Rimas, This pseudo-code may not be the correct solution for you, but it should help you get on the right track...there is documentation out there to help you figure out what you need to do--good luck! # -- are you following the LARTC two-link howto? # http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN261 # make sure you set up default routes in two separate routing tables ip route add default via $ETH0_GW table eth0.link ip route add default via $ETH2_GW table eth2.link # -- add rules to the RPDB in order from most general to most specific # ip rule add from 10.105.105.0/24 table eth2.link ip rule add from 10.105.105.100 table eth0.link ip rule add from 10.105.105.101 table eth0.link ip rule add from 10.105.105.102 table eth0.link ip rule add from 10.105.105.103 table eth0.link ip rule add from 10.105.105.104 table eth0.link ip rule add from 10.105.105.105 table eth0.link As I mentioned above, Rimas, you'll want to look at the split access howto of the LARTC HOWTO. If that's not enough to make sense of it, you'll need to refer to the iproute2 manual, which is available as HTML here: http://defiant.coinet.com/iproute2/ip-cref/ Post to the list with more specific questions if you have them....and hopefully somebody else with a more elegant solution will post in the interim. Ciao for now, -Martin : Hi folks, : : I have iptables rules: : iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE : iptables -A POSTROUTING -t nat -o eth2 -j MASQUERADE : That will masquerade all packets going out of the two external interfaces. : : How to make a routing with iproute2 to direct packets from : 10.105.105.100-105 via eth0 and to direct packets from the rest of and : 10.105.105.0/24 via eth2 ? : : Thanks in advance : : Rimas : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From devik@cdi.cz Mon Sep 9 17:52:10 2002 From: devik@cdi.cz (Martin Devera) Date: Mon, 9 Sep 2002 18:52:10 +0200 (CEST) Subject: [LARTC] HTB and per-connection bandwidth allocation In-Reply-To: <46D691ED7233D511AF0B0090277A532D1CD942@mail.commtech.ie> References: <46D691ED7233D511AF0B0090277A532D1CD942@mail.commtech.ie> Message-ID: try SFQ. devik On Mon, 9 Sep 2002, Michael O'Shea wrote: > Hi, > > How do I allocate a guaranteed rate to each individual connection. > For example I can allocate, say 1Mb, to all HTTP traffic by defining the > appropriate class & filter. In this case, if I have one connection it will > get all 1M; if I have 100 then each connection will get ~ 10k. But supposing > I want to allocate 10k per individual connection regardless of the number of > connections - so if I have only one connection it gets 10k...20 get 20*10k > and if I go above 100 any extra connections are dropped. This allows a > guaranteed level of service per connection. > I cannot see how to achieve this in HTB. > > Thanks > Michael > From stef.coene@docum.org Mon Sep 9 18:13:41 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 9 Sep 2002 19:13:41 +0200 Subject: [LARTC] /proc interface OR graphing again ? In-Reply-To: <20020909135954.7e3864f0.raptor@tvskat.net> References: <20020909135954.7e3864f0.raptor@tvskat.net> Message-ID: <200209091913.41184.stef.coene@docum.org> On Monday 09 September 2002 19:59, raptor wrote: > hi, > > I was searching in the arhives(for tcng-htb patch, still searching !!) = and > found a discussion about /proc interface for the ip-statistics/qos ....= =2E is > there any advance on this ? Not that I know .... > Current practice is to install ipchains/iptables for counting the traff= ic > and then graph the results with ip"something!" (computionaly intensive)= =2E... > i probably will take the approach a separate station in promicious mode= =2E. > but availability of the counters in the /proc can streamline the things > alot and give a quick way with simple scripts to handle those things... > And the idea to polling this statistics later with mrtg via net-snmp is > good :") I have some scripts that uses the rrdtool (that's the graping part of mrt= g) to=20 create graphs based on the counters in tc. It also uses snmp to get the=20 information so you can monitor on an other box. The scripts are ugly and= I=20 have some snmp-related problems, but it works for me. (see docum.org on t= he=20 gui page for an exampe). Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Mon Sep 9 18:15:46 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 9 Sep 2002 19:15:46 +0200 Subject: Re[2]: [LARTC] Counters of CLASSes HTB In-Reply-To: <35850921810.20020909100221@uic.nnov.ru> References: <35850921810.20020909100221@uic.nnov.ru> Message-ID: <200209091915.46616.stef.coene@docum.org> On Monday 09 September 2002 08:02, Xor wrote: > Hello, Nick. > > You wrote Monday, September 09, 2002, 9:22:10 AM: > > N> Hi, > N> Isn't the usual way of collecting stats of this kind, you ge= t > the N> value when you start monitoring and then the value when you want= to > stop N> and take the difference. This way if you want measurements of > different N> periods its only the programs doing the measureing that ch= ange > not the N> device producing the readings, and you can have multiple rea= ders > of N> different periods. > > ... and what about overlimit counters ? Example: counters was max > values two (or more) time every some times ? I will not argue... I > understand that can to do read different more often, but reset > counters is more suitable %) That's not such an issue if you read the counters fast enough. If you re= ad=20 the counters each 5 minutes, you know quite accurate when they are resett= ed=20 and you will not loose that much data. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From yxjia@site.uottawa.ca Mon Sep 9 22:08:34 2002 From: yxjia@site.uottawa.ca (yuxiao) Date: Mon, 9 Sep 2002 14:08:34 -0700 Subject: [LARTC] Re: questiona about CBQ algorithm in Linux References: <200209061831.WAA07683@sex.inr.ac.ru> Message-ID: <000c01c25845$0f7fd9e0$775b7a89@BWWIL23> Hello Alex Sorry for my stubborn question. I read the S.Floyd paer "Link-sharing and resource mamagement...." On page 5, they said" The estimator estimates the bandwidth used byeach class over the appropriate time interval, to determine whether or not each class has been receiveing its link -sharing bandwidth..." Also as I know CBQ building block, they have general scheduler, link-sharing scheduler, estimater, classifier etc. complonents. This is why I ask you how about its implementation in linux. I read the sch_cbq.c comments, not quite sure one line" Linux has no EOI event, so that we ca not estimater true idle class idle time..." what's EOI event, This is why in Linux, CBQ canot measure bandwidth? regards yuxiao ----- Original Message ----- From: To: "yuxiao" Cc: ; Sent: Friday, September 06, 2002 11:31 AM Subject: Re: questiona about CBQ algorithm in Linux > Hello! > > > average), how about Linux implemenatation about estimator?=20 > > also do you have link for this algorithm? I canot find it. > > The questions are answered in papers, references are in comments > in sch_cbq.c, look at http://www.icir.org/floyd/cbq.html > > > > 3. In linux how CBQ measure used bandwidth per class? does it measure > > bandwith bits/sec? > > No, it does not measure bandwdith at all. Read papers, please. > > > > 7. Can HTB do the same job as CBQ right now, can HTB do borrow ?=20 > > Yes, it does. And does it better than CBQ. > > Alexey From kuznet@ms2.inr.ac.ru Mon Sep 9 19:28:52 2002 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Mon, 9 Sep 2002 22:28:52 +0400 (MSD) Subject: [LARTC] Re: questiona about CBQ algorithm in Linux In-Reply-To: <000c01c25845$0f7fd9e0$775b7a89@BWWIL23> from "yuxiao" at Sep 9, 2 02:08:34 pm Message-ID: <200209091828.WAA22320@sex.inr.ac.ru> Hello! > Sorry for my stubborn question. I read the S.Floyd paer "Link-sharing and > resource mamagement...." On page 5, they said" The estimator estimates the > bandwidth used byeach class over the appropriate time interval, to determine > whether or not each class has been receiveing its link -sharing > bandwidth..." Appendix A. > sch_cbq.c comments, not quite sure one line" Linux has no EOI event, so that > we ca not estimater true idle class idle time..." > what's EOI event, This is why in Linux, CBQ canot measure bandwidth? No. No OSes have "EOI event". :-) CBQ does not measure bandwidth because it does not need it. Period. Listen, please, do not waste your time for useless phylosophical meditations, read the paper instead. Alexey From stef.coene@docum.org Mon Sep 9 20:22:03 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 9 Sep 2002 21:22:03 +0200 Subject: [LARTC] Wondershaper In-Reply-To: <3D7895BD.80807@web.de> References: <3D786CCD.6050809@web.de> <200209061234.03303.stef.coene@docum.org> <3D7895BD.80807@web.de> Message-ID: <200209092122.03442.stef.coene@docum.org> On Friday 06 September 2002 13:47, Sebastian Bleikamp wrote: > Stef Coene schrieb: > > Try efsq. It's SFQ (so each "flow" gets an equal chance to send > > something). But efsq uses only dst/src addres and not dst/src > > address/port like sfq. Ideal to kill download managers because all > > traffic form/to the same hosts is considered as one stream. > > I have a link on docum.org under FAQ. > > I will test it, thnx. > > > But another question: > I tried your solution via fwmark, and it works. At least when the route= r > is forwarding. I can slow down hosts on my LAN this way. If i try to > slow the gateway/router down, it fails. > > I have added a mark to all outgoing traffic on ppp0, which comes from > the router, to the OUTGOING/mangle table. But it doesn=B4t work this wa= y. > But from the sketch on your homepage this should work. I already checke= d > the IPs and devices and they are correct. If you list the iptables/ipchains rules, you can check the counters to se= e if=20 they are incrementing. And the sketch at my homepage is for from complete. I have to check it o= ut=20 for errors. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From amitk@ittc.ku.edu Mon Sep 9 21:59:15 2002 From: amitk@ittc.ku.edu (Amit Kucheria) Date: Mon, 9 Sep 2002 15:59:15 -0500 (CDT) Subject: [LARTC] Netspec Traffic generator and experiment control tool In-Reply-To: <3B2535B7.C3951B63@comm.utoronto.ca> Message-ID: Hi Everybody, I am sending out this email to everybody who has contacted me regarding Netspec over the last few months along with the other Linux lists where this might be of use. At the time, I was 'sort of' maintaining Netspec, but not quite. And I had my hands full with other stuff, making enhancements difficult. My friend Karthik here has been able to coordinate a newer version 5.0 finally. What is Netspec? ---------------- We think of it as a distributed, automated testing framework. We have used it to perform a variety of tasks required to setup and run network-based experiments. Some of the tasks we have accomplished are: - Setting up a network (configuring routers, sources, sinks, setting up traffic control - RSVP, Diffserv) - Executing repetitive commands on many machines (copying data files, copying reports, processing reports, etc.) - Log kernel instrumentation points using DSKI (www.ittc.ku.edu/datastream/) - Split up our experiments into phases, such that Phase X always precedes Phase Y or Phase A and Phase B happen in parallel. - Generating various kinds of traffic (TCP, UDP, with TOS bits, emulated traffic such as FTP, Telnet, etc.) - And all this can be done by typing a single command at ONE machine such as: netspec my-script where 'my-script' contains information to instructions to send to the various machines. Enhancements ------------ The following are some of the enhancements in Netspec 5.0: - Netspec is now not limited only to traffic generation. We are using it for 'Total experiment control' TM :). This facility was present before but sort of 'hidden' by its traffic generation capabilities. - Clean up of Netspec source with new features. - Improved documentation; new document which builds up on existing one and describes newer features in detail. - Removed problems with ATM dependencies. - Compilation on a newer glibc (RH7.1). - New variable-phase execution with multiple combinations of serial and parallel phases possible. - New simple 'system command' daemon which can act as a template for creating your own daemons and which also works if you need to execute some existing commands on multiple machines. It is the simplest daemon possible. So I thought you people might want to retry it if you were unsuccessful at first. Give it a try if you want and see if it works for you now. Grab it at: http://www.ittc.ku.edu/~ntkarthik/Netspec-5.0.tar.gz Official Website: http://www.ittc.ku.edu/netspec/ For more help, you can contact ntkarthik@ittc.ku.edu and if he is not available, then I should be able to answer your queries. If both of us disappear by virtue of graduation, then our advisor Dr. Niehaus (niehaus@ittc.ku.edu) should be able to help. We welcome new additions, corrections or short HOWTOs to add to our documentation as well as patches to the code. Regards, Amit -- I'm an angel!!! Honest! The horns are just there to hold the halo up straight. ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ Amit Kucheria EECS Grad. Research Assistant University of Kansas @ Lawrence (R): +1-785-830-8521 ||| (C): +1-785-760-2871 ____________________________________________________ From devik@cdi.cz Mon Sep 9 22:52:06 2002 From: devik@cdi.cz (Martin Devera) Date: Mon, 9 Sep 2002 23:52:06 +0200 (CEST) Subject: [LARTC] Re: questiona about CBQ algorithm in Linux In-Reply-To: <000c01c25845$0f7fd9e0$775b7a89@BWWIL23> References: <200209061831.WAA07683@sex.inr.ac.ru> <000c01c25845$0f7fd9e0$775b7a89@BWWIL23> Message-ID: Hi yuxiao, On Mon, 9 Sep 2002, yuxiao wrote: > Hello Alex > > Sorry for my stubborn question. I read the S.Floyd paer "Link-sharing and > resource mamagement...." On page 5, they said" The estimator estimates the > bandwidth used byeach class over the appropriate time interval, to determine > whether or not each class has been receiveing its link -sharing > bandwidth..." > > Also as I know CBQ building block, they have general scheduler, link-sharing > scheduler, estimater, classifier etc. complonents. > > This is why I ask you how about its implementation in linux. I read the > sch_cbq.c comments, not quite sure one line" Linux has no EOI event, so that > we ca not estimater true idle class idle time..." > what's EOI event, This is why in Linux, CBQ canot measure bandwidth? Alexey meant EndOfInterrupt probably - the timepoint when a packet finally leaved NIC. It is needed to compute and measure inderpacket times - these are used as guide whether are we over/underlimit. When I started to write first HTB version I spent one YEAR of thinking - so that don't expect to understand all nuances so fast :) The main problems when implementing CBQ as described in Floyd paper (Appendix A - interpacked delay measure) is that you don;t have precise time reference. Alexey used trick in sch_cbq - used NIC as time source ;) HTB is direct implementation of Floyd's formal sharing and uses leaky buckets as estimators - they are not so sensitive to less precise timing. Also you should note that original CBQ really didn't measure bw, it rather tries to correct deviations from expected interpacket delay. regards, devik > regards > > yuxiao > ----- Original Message ----- > From: > To: "yuxiao" > Cc: ; > Sent: Friday, September 06, 2002 11:31 AM > Subject: Re: questiona about CBQ algorithm in Linux > > > > Hello! > > > > > average), how about Linux implemenatation about estimator?=20 > > > also do you have link for this algorithm? I canot find it. > > > > The questions are answered in papers, references are in comments > > in sch_cbq.c, look at http://www.icir.org/floyd/cbq.html > > > > > > > 3. In linux how CBQ measure used bandwidth per class? does it measure > > > bandwith bits/sec? > > > > No, it does not measure bandwdith at all. Read papers, please. > > > > > > > 7. Can HTB do the same job as CBQ right now, can HTB do borrow ?=20 > > > > Yes, it does. And does it better than CBQ. > > > > Alexey > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From devik@cdi.cz Mon Sep 9 22:53:14 2002 From: devik@cdi.cz (Martin Devera) Date: Mon, 9 Sep 2002 23:53:14 +0200 (CEST) Subject: [LARTC] Re: questiona about CBQ algorithm in Linux In-Reply-To: <200209091828.WAA22320@sex.inr.ac.ru> References: <200209091828.WAA22320@sex.inr.ac.ru> Message-ID: heh you was a bit faster Alexey ;-) On Mon, 9 Sep 2002 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Sorry for my stubborn question. I read the S.Floyd paer "Link-sharing and > > resource mamagement...." On page 5, they said" The estimator estimates the > > bandwidth used byeach class over the appropriate time interval, to determine > > whether or not each class has been receiveing its link -sharing > > bandwidth..." > > Appendix A. > > > > sch_cbq.c comments, not quite sure one line" Linux has no EOI event, so that > > we ca not estimater true idle class idle time..." > > what's EOI event, This is why in Linux, CBQ canot measure bandwidth? > > No. No OSes have "EOI event". :-) > > CBQ does not measure bandwidth because it does not need it. Period. > Listen, please, do not waste your time for useless phylosophical meditations, > read the paper instead. > > Alexey > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From rmocius@auste.elnet.lt Tue Sep 10 11:39:48 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 10 Sep 2002 11:39:48 +0100 Subject: [LARTC] routing to 2 different Internet connections Message-ID: <008901c258b6$645e77c0$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C258BE.C4AA2270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, I have iptables rules: iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE iptables -A POSTROUTING -t nat -o eth2 -j MASQUERADE That will masquerade all packets going out of the two external = interfaces. How to make a routing with iproute2 to direct packets from=20 10.105.105.100-105 via eth0 and to direct packets from the rest of and 10.105.105.0/24 via eth2 ? Thanks in advance Rimas ------=_NextPart_000_0086_01C258BE.C4AA2270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
I have iptables rules:
iptables -A=20 POSTROUTING -t nat -o eth0 -j MASQUERADE
iptables -A POSTROUTING -t = nat -o=20 eth2 -j MASQUERADE
That will masquerade all packets going out of the = two=20 external interfaces.

How to make a routing with iproute2 to = direct=20 packets from
10.105.105.100-105 via eth0 and to direct packets from = the rest=20 of and
10.105.105.0/24 via eth2 ?
Thanks in advance
 
Rimas
 
------=_NextPart_000_0086_01C258BE.C4AA2270-- From devik@cdi.cz Tue Sep 10 10:24:58 2002 From: devik@cdi.cz (devik) Date: Tue, 10 Sep 2002 11:24:58 +0200 (CEST) Subject: [LARTC] HTB and per-connection bandwidth allocation In-Reply-To: <46D691ED7233D511AF0B0090277A532D1CD947@mail.commtech.ie> Message-ID: Ahh yes .. so that maximum N is fixed in this way ? Hmmm and you then need way to map active connection to free class in HTB for example. It will not be simple because you can't say when conversation ends (safely). So that you will end with all classes busy. You would have to write it yourself probably - extend iptables connection tracking to maintain table of classids and select classid for new connection and return it when conn is deleted. Then simply copy this number to fwmark ... If you really need this and can't write it you could ask in lartc list whether someone is willing to write it (for fun or for money). devik On Tue, 10 Sep 2002, Michael O'Shea wrote: > devik, > But this is my problem - I don't want bw per connection = total/n ... I want > bw per connection = x, where x is a constant fraction of total. So for n > connections total bw utilised = n*x <= total. > rgds, Michael > > -----Original Message----- > From: devik [mailto:devik@cdi.cz] > Sent: 09 September 2002 19:53 > To: Michael O'Shea > Subject: RE: [LARTC] HTB and per-connection bandwidth allocation > > > for n active (backlogged) connection sfq gives > total/n fraction. existence of backlog is > essential ! chech with tc class show whether > htb leaf is backloged during periods you > are interested in. > devik > > On Mon, 9 Sep 2002, Michael O'Shea wrote: > > > devik, > > > > I've tried adding sfq qdiscs to the class that governs HTTP but I still > > don't get the result I want. If I open a single connection, it still gets > > all the bandwidth available for the class. My understanding is that the > > addition of sfq to a class will allow fairness between the individual > > connections (giving each a 'turn') .. but this does not help with defining > a > > specific rate per connection? > > > > > > Michael > > > > -----Original Message----- > > From: Martin Devera [mailto:devik@cdi.cz] > > Sent: 09 September 2002 17:52 > > To: Michael O'Shea > > Cc: 'lartc@mailman.ds9a.nl' > > Subject: Re: [LARTC] HTB and per-connection bandwidth allocation > > > > > > try SFQ. > > devik > > > > On Mon, 9 Sep 2002, Michael O'Shea wrote: > > > > > Hi, > > > > > > How do I allocate a guaranteed rate to each individual connection. > > > For example I can allocate, say 1Mb, to all HTTP traffic by defining the > > > appropriate class & filter. In this case, if I have one connection it > will > > > get all 1M; if I have 100 then each connection will get ~ 10k. But > > supposing > > > I want to allocate 10k per individual connection regardless of the > number > > of > > > connections - so if I have only one connection it gets 10k...20 get > 20*10k > > > and if I go above 100 any extra connections are dropped. This allows a > > > guaranteed level of service per connection. > > > I cannot see how to achieve this in HTB. > > > > > > Thanks > > > Michael > > > > > > > > > From michael.oshea@commtech.ie Tue Sep 10 12:22:44 2002 From: michael.oshea@commtech.ie (Michael O'Shea) Date: Tue, 10 Sep 2002 12:22:44 +0100 Subject: [LARTC] HTB and per-connection bandwidth allocation Message-ID: <46D691ED7233D511AF0B0090277A532D1CD94E@mail.commtech.ie> Devik, Thanks for that...now I have to do some thinking.. Rgds Michael -----Original Message----- From: devik [mailto:devik@cdi.cz] Sent: 10 September 2002 10:25 To: Michael O'Shea Cc: lartc@mailman.ds9a.nl Subject: RE: [LARTC] HTB and per-connection bandwidth allocation Ahh yes .. so that maximum N is fixed in this way ? Hmmm and you then need way to map active connection to free class in HTB for example. It will not be simple because you can't say when conversation ends (safely). So that you will end with all classes busy. You would have to write it yourself probably - extend iptables connection tracking to maintain table of classids and select classid for new connection and return it when conn is deleted. Then simply copy this number to fwmark ... If you really need this and can't write it you could ask in lartc list whether someone is willing to write it (for fun or for money). devik On Tue, 10 Sep 2002, Michael O'Shea wrote: > devik, > But this is my problem - I don't want bw per connection = total/n ... I want > bw per connection = x, where x is a constant fraction of total. So for n > connections total bw utilised = n*x <= total. > rgds, Michael > > -----Original Message----- > From: devik [mailto:devik@cdi.cz] > Sent: 09 September 2002 19:53 > To: Michael O'Shea > Subject: RE: [LARTC] HTB and per-connection bandwidth allocation > > > for n active (backlogged) connection sfq gives > total/n fraction. existence of backlog is > essential ! chech with tc class show whether > htb leaf is backloged during periods you > are interested in. > devik > > On Mon, 9 Sep 2002, Michael O'Shea wrote: > > > devik, > > > > I've tried adding sfq qdiscs to the class that governs HTTP but I still > > don't get the result I want. If I open a single connection, it still gets > > all the bandwidth available for the class. My understanding is that the > > addition of sfq to a class will allow fairness between the individual > > connections (giving each a 'turn') .. but this does not help with defining > a > > specific rate per connection? > > > > > > Michael > > > > -----Original Message----- > > From: Martin Devera [mailto:devik@cdi.cz] > > Sent: 09 September 2002 17:52 > > To: Michael O'Shea > > Cc: 'lartc@mailman.ds9a.nl' > > Subject: Re: [LARTC] HTB and per-connection bandwidth allocation > > > > > > try SFQ. > > devik > > > > On Mon, 9 Sep 2002, Michael O'Shea wrote: > > > > > Hi, > > > > > > How do I allocate a guaranteed rate to each individual connection. > > > For example I can allocate, say 1Mb, to all HTTP traffic by defining the > > > appropriate class & filter. In this case, if I have one connection it > will > > > get all 1M; if I have 100 then each connection will get ~ 10k. But > > supposing > > > I want to allocate 10k per individual connection regardless of the > number > > of > > > connections - so if I have only one connection it gets 10k...20 get > 20*10k > > > and if I go above 100 any extra connections are dropped. This allows a > > > guaranteed level of service per connection. > > > I cannot see how to achieve this in HTB. > > > > > > Thanks > > > Michael > > > > > > > > > From domingos@microlink.com.br Tue Sep 10 16:00:42 2002 From: domingos@microlink.com.br (Domingos Reis da Costa) Date: Tue, 10 Sep 2002 12:00:42 -0300 Subject: [LARTC] TC filter:Marking packets X IP/PORT filter Message-ID: <3D7E091A.F4FEE9F7@microlink.com.br> Hello, Is there any advantages on fwmark filtering rather than ip/port filtering? Is load average the only advantage? If load average is low on both cases, will fwmark reduce the RTT of the packet in comparison with ip/port filtering? Domingos Costa From thad@marshtek.com Tue Sep 10 17:02:44 2002 From: thad@marshtek.com (Thad Marsh) Date: Tue, 10 Sep 2002 12:02:44 -0400 Subject: [LARTC] 4 nic advanced routing question Message-ID: <19ED2BC99F18344B8B571CD827577675109829@genisis.Marshtek.loc> This is a multi-part message in MIME format. ------_=_NextPart_001_01C258E3.801CD380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have scoured the net, gotten a few pointers from several people and = looked at several books and still have not come up with a satisfactory = solution. =20 =20 I know someone has done it! =20 =20 Can some one point me to a reference for how to route two wan nics and = two internal nics on the same box. =20 =20 I have tried using ip add to setup two separate lookup tables and route = tables but to know avail. Any help greatly appreciated! =20 This is what I have=20 =20 66.92.114.46 66.92.114.46 = 209.141.2.194 | | xxxxxxxxxxxxxxxx RedHat 7.3 will run ShoreWall xxxxxxxxxxxxxxxx 192.168.119.101 192.168.120.101 | | = each network will have servers running here 192.168.119.100 192.168.119.100 = 192.168.120.100 xxxxxxxxxxxxxxxxx failover box xxxxxxxxxxxxxxxxx 192.168.121.101 internal mail server =20 ip ru 0: from all lookup local 32766: from all lookup main 32767: from all lookup 253 =20 =20 ip ro 66.92.114.32/28 dev eth0 scope link 209.141.2.192/27 dev eth1 scope link 192.168.119.0/24 dev eth2 scope link 192.168.120.0/24 dev eth3 scope link 127.0.0.0/8 dev lo scope link default via 66.92.114.33 dev eth0 =20 ------_=_NextPart_001_01C258E3.801CD380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I = have scoured the net, gotten a few pointers from several people and looked at several books and still have not come up with a satisfactory = solution.  <= /p>

 <= /p>

I = know someone has done it!  = <= /p>

 <= /p>

Can some one point me to a reference for how to route two wan nics and two internal = nics on the same box.  = <= /p>

 <= /p>

I = have tried using ip add to setup two separate lookup tables and route tables but to = know avail. Any help greatly appreciated!<= /p>

 <= /p>

This is what I have

 <= /p>

66.92.114.46           = ;            =        66.92.114.46      = ;            =             209.141.2.194<= /p>

|        = ;            =    |<= /p>

xxxxxxxxxxxxxxxx<= /p>

RedHat 7.3 will run ShoreWall

xxxxxxxxxxxxxxxx<= /p>

192.168.119.101        = ; 192.168.120.101<= /p>

        = ;    |        = ;            =             &= nbsp;  |        = ;            =             &= nbsp;  each network will have servers running here<= /p>

192.168.119.100           = ;       192.168.119.100      = ;            192.168.120.100<= /p>

xxxxxxxxxxxxxxxxx<= /p>

failover box<= /p>

xxxxxxxxxxxxxxxxx<= /p>

192.168.121.101<= /p>

internal mail server

 

ip = ru

0:      from = all lookup local

32766:  from all lookup = main

32767:  from all lookup = 253

 

 

ip = ro<= /p>

66.92.114.32/28 dev eth0  scope = link<= /p>

209.141.2.192/27 dev eth1  scope = link<= /p>

192.168.119.0/24 dev eth2  scope = link<= /p>

192.168.120.0/24 dev eth3  scope = link<= /p>

127.0.0.0/8 dev lo  scope = link<= /p>

default via 66.92.114.33 dev eth0

 <= /p>

------_=_NextPart_001_01C258E3.801CD380-- From jmorilla@creaciondeweb.com Tue Sep 10 17:29:17 2002 From: jmorilla@creaciondeweb.com (Juan Antonio Morillas Cerezo) Date: Tue, 10 Sep 2002 18:29:17 +0200 Subject: [LARTC] 4 nic advanced routing question In-Reply-To: <19ED2BC99F18344B8B571CD827577675109829@genisis.Marshtek.loc> References: <19ED2BC99F18344B8B571CD827577675109829@genisis.Marshtek.loc> Message-ID: <20020910162917.GD2397@creaciondeweb.com> A fecha Tue, Sep 10, 2002 at 12:02:44PM -0400, Thad Marsh dijo: > > I have scoured the net, gotten a few pointers from several people and looked at > several books and still have not come up with a satisfactory solution. > Perhaps it's because of my mail reader not properly opening html documents, but I'd ask you to make a diagram or even a drawing, with arrows included, that would help a lot. Please take into account possible NATings between networks too. From mbabcock@fibrespeed.net Tue Sep 10 17:34:10 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Tue, 10 Sep 2002 12:34:10 -0400 Subject: [LARTC] 4 nic advanced routing question References: <19ED2BC99F18344B8B571CD827577675109829@genisis.Marshtek.loc> <20020910162917.GD2397@creaciondeweb.com> Message-ID: <3D7E1F02.4020301@fibrespeed.net> Juan Antonio Morillas Cerezo wrote: >Perhaps it's because of my mail reader not properly >opening html documents, but I'd ask you to make a diagram or >even a drawing, with arrows included, that would help a lot. >Please take into account possible NATings between networks too. > I'm not sure why you're having a problem: ------_=_NextPart_001_01C258E3.801CD380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable His document was encoded properly ... -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock From thad@marshtek.com Tue Sep 10 17:39:57 2002 From: thad@marshtek.com (Thad Marsh) Date: Tue, 10 Sep 2002 12:39:57 -0400 Subject: [LARTC] 4 nic advanced routing question repost txt Message-ID: <19ED2BC99F18344B8B571CD82757767510982B@genisis.Marshtek.loc> This is a multi-part message in MIME format. ------_=_NextPart_001_01C258E8.B2CAD8E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHNjb3VyZWQgdGhlIG5ldCwgZ290dGVuIGEgZmV3IHBvaW50ZXJzIGZyb20gc2V2ZXJh bCBwZW9wbGUgYW5kIGxvb2tlZCBhdCBzZXZlcmFsIGJvb2tzIGFuZCBzdGlsbCBoYXZlIG5vdCBj b21lIHVwIHdpdGggYSBzYXRpc2ZhY3Rvcnkgc29sdXRpb24uICANCg0KIA0KDQpJIGtub3cgc29t ZW9uZSBoYXMgZG9uZSBpdCEgIA0KDQogDQoNCkNhbiBzb21lIG9uZSBwb2ludCBtZSB0byBhIHJl ZmVyZW5jZSBmb3IgaG93IHRvIHJvdXRlIHR3byB3YW4gbmljcyBhbmQgdHdvIGludGVybmFsIG5p Y3Mgb24gdGhlIHNhbWUgYm94LiAgDQoNCiANCg0KSSBoYXZlIHRyaWVkIHVzaW5nIGlwIGFkZCB0 byBzZXR1cCB0d28gc2VwYXJhdGUgbG9va3VwIHRhYmxlcyBhbmQgcm91dGUgdGFibGVzIGJ1dCB0 byBrbm93IGF2YWlsLiBBbnkgaGVscCBncmVhdGx5IGFwcHJlY2lhdGVkIQ0KDQogDQoNClRoaXMg aXMgd2hhdCBJIGhhdmUgDQoNCiANCg0KNjYuOTIuMTE0LjQ2ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMjA5LjE0MS4yLjE5NA0KDQp8ICAgICAgICAgICAgICAgICAgICAgICB8DQoNCnh4 eHh4eHh4eHh4eHh4eHgNCg0KTmF0ZWQgUmVkSGF0IDcuMyB3aWxsIHJ1biBTaG9yZVdhbGwNCg0K eHh4eHh4eHh4eHh4eHh4eA0KDQoxOTIuMTY4LjExOS4xMDEgICAgICAgICAxOTIuMTY4LjEyMC4x MDENCg0KICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWFjaCBuZXR3b3JrIHdpbGwgaGF2ZSBz ZXJ2ZXJzIHJ1bm5pbmcgaGVyZQ0KDQoxOTIuMTY4LjExOS4xMDAgICAgICAgICAgICAgICAgICAx OTIuMTY4LjEyMC4xMDANCg0KeHh4eHh4eHh4eHh4eHh4eHgNCg0KTmF0ZWQgZmFpbG92ZXIgYm94 DQoNCnh4eHh4eHh4eHh4eHh4eHh4DQoNCjE5Mi4xNjguMTIxLjEwMQ0KDQppbnRlcm5hbCBtYWls IHNlcnZlcg0KDQogDQoNCmlwIHJ1DQoNCjA6ICAgICAgZnJvbSBhbGwgbG9va3VwIGxvY2FsDQoN CjMyNzY2OiAgZnJvbSBhbGwgbG9va3VwIG1haW4NCg0KMzI3Njc6ICBmcm9tIGFsbCBsb29rdXAg MjUzDQoNCiANCg0KIA0KDQppcCBybw0KDQo2Ni45Mi4xMTQuMzIvMjggZGV2IGV0aDAgIHNjb3Bl IGxpbmsNCg0KMjA5LjE0MS4yLjE5Mi8yNyBkZXYgZXRoMSAgc2NvcGUgbGluaw0KDQoxOTIuMTY4 LjExOS4wLzI0IGRldiBldGgyICBzY29wZSBsaW5rDQoNCjE5Mi4xNjguMTIwLjAvMjQgZGV2IGV0 aDMgIHNjb3BlIGxpbmsNCg0KMTI3LjAuMC4wLzggZGV2IGxvICBzY29wZSBsaW5rDQoNCmRlZmF1 bHQgdmlhIDY2LjkyLjExNC4zMyBkZXYgZXRoMA0KDQogDQoNCiANCg0KIA0KDQo= ------_=_NextPart_001_01C258E8.B2CAD8E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj48SFRNTD48SEVBRD48TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PC9IRUFEPjxCT0RZPjxESVY+CjxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW4iPjxTUEFOIHN0eWxlPSJDT0xP UjogYmxhY2siPkkgCmhhdmUgc2NvdXJlZCB0aGUgbmV0LCBnb3R0ZW4gYSBmZXcgcG9pbnRlcnMg ZnJvbSBzZXZlcmFsIHBlb3BsZSBhbmQgbG9va2VkIGF0IApzZXZlcmFsIGJvb2tzIGFuZCBzdGls bCBoYXZlIG5vdCBjb21lIHVwIHdpdGggYSBzYXRpc2ZhY3Rvcnkgc29sdXRpb24uPFNQQU4gCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj48L1NQQU4+PFNQQU4gCnN0eWxl PSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjw/eG1sOm5hbWVzcGFj ZSBwcmVmaXggPSBvIG5zID0gCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZp Y2UiIC8+PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQgMWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjayI+Jm5ic3A7 PC9TUEFOPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0 ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOOiAwaW4gMGluIDBwdCAxaW4iPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPkkgCmtub3cg c29tZW9uZSBoYXMgZG9uZSBpdCE8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyAKPC9TUEFOPjwvU1BBTj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFs dDogd2luZG93dGV4dCI+PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFj ayI+Jm5ic3A7PC9TUEFOPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrOyBtc28tY29sb3ItYWx0 OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNr Ij5DYW4gc29tZSBvbmUgcG9pbnQgbWUgdG8gYSByZWZlcmVuY2UgZm9yIGhvdyB0byByb3V0ZSB0 d28gCndhbiBuaWNzIGFuZCB0d28gaW50ZXJuYWwgbmljcyBvbiB0aGUgc2FtZSBib3guPFNQQU4g CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj48L1NQQU4+PFNQQU4gCnN0 eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 IDFpbiI+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPiZuYnNwOzwvU1BBTj48U1BBTiAKc3R5 bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFsdDogd2luZG93dGV4dCI+PG86cD48L286cD48 L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQg MWluIj48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrIj5JIApoYXZlIHRyaWVkIHVzaW5nIGlwIGFk ZCB0byBzZXR1cCB0d28gc2VwYXJhdGUgbG9va3VwIHRhYmxlcyBhbmQgcm91dGUgdGFibGVzIGJ1 dCAKdG8ga25vdyBhdmFpbC4gQW55IGhlbHAgZ3JlYXRseSBhcHByZWNpYXRlZCE8L1NQQU4+PFNQ QU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0IDFpbiI+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPiZuYnNwOzwvU1BBTj48U1BB TiAKc3R5bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFsdDogd2luZG93dGV4dCI+PG86cD48 L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQgMWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjayI+VGhpcyBpcyB3aGF0IEkgaGF2 ZSA8L1NQQU4+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRv d3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gMHB0IDFpbiI+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPiZuYnNw OzwvU1BBTj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFsdDogd2luZG93 dGV4dCI+PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgCnN0eWxlPSJN QVJHSU46IDBpbiAwaW4gMHB0IDIuNWluOyBURVhULUlOREVOVDogLTEuNWluOyBtc28tbGlzdDog bDAgbGV2ZWw0IGxmbzE7IHRhYi1zdG9wczogbGlzdCAyLjVpbiI+PFNQQU4gCnN0eWxlPSJDT0xP UjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjY2LjkyLjExNC40NjxTUEFOIApz dHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+PC9TUEFOPjxTUEFOIApzdHlsZT0iRk9OVC1TSVpF OiA3cHQ7IENPTE9SOiBibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiAKc3R5 bGU9IkNPTE9SOiBibGFjayI+MjA5LjE0MS4yLjE5NDwvU1BBTj48U1BBTiAKc3R5bGU9IkNPTE9S OiBibGFjazsgbXNvLWNvbG9yLWFsdDogd2luZG93dGV4dCI+PG86cD48L286cD48L1NQQU4+PC9Q Pgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMS41aW4iPjxT UEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj58PFNQQU4gCnN0eWxlPSJtc28tdGFiLWNvdW50OiAy Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgCjwvU1BBTj58PC9TUEFOPjxTUEFOIApzdHlsZT0iQ09MT1I6 IGJsYWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+ CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbiI+PFNQ QU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPnh4eHh4eHh4eHh4eHh4eHg8L1NQQU4+PC9QPgo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMS41aW4iPjxTUEFOIApz dHlsZT0iQ09MT1I6IGJsYWNrIj5OYXRlZCA8L1NQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFj ayI+UmVkSGF0IDcuMyB3aWxsIHJ1biAKU2hvcmVXYWxsPC9TUEFOPjxTUEFOIApzdHlsZT0iQ09M T1I6IGJsYWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48 L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbiI+ PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPnh4eHh4eHh4eHh4eHh4eHg8L1NQQU4+PFNQQU4g CnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4g MHB0IDFpbiI+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPjE5Mi4xNjguMTE5LjEwMTxTUEFO IApzdHlsZT0ibXNvLXRhYi1jb3VudDogMSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IAo8L1NQQU4+MTkyLjE2OC4xMjAuMTAxPC9TUEFOPjxTUEFOIApz dHlsZT0iQ09MT1I6IGJsYWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpw PjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBw dCAxaW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj48U1BBTiAKc3R5bGU9Im1zby10YWIt Y291bnQ6IDEiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAKPC9TUEFOPnw8U1BBTiAKc3R5bGU9Im1zby10YWItY291bnQ6 IDMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKPC9TUEFOPnw8U1BBTiAKc3R5 bGU9Im1zby10YWItY291bnQ6IDMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAK PC9TUEFOPmVhY2ggbmV0d29yayB3aWxsIGhhdmUgc2VydmVycyBydW5uaW5nIGhlcmU8L1NQQU4+ PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxv OnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIApzdHlsZT0iTUFSR0lOOiAw aW4gMGluIDBwdCAyLjVpbjsgVEVYVC1JTkRFTlQ6IC0xLjVpbjsgbXNvLWxpc3Q6IGwxIGxldmVs NCBsZm8yOyB0YWItc3RvcHM6IGxpc3QgMi41aW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNr OyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij4xOTIuMTY4LjExOS4xMDA8U1BBTiAKc3R5bGU9 IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IAo8L1NQQU4+PC9TUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxh Y2siPjE5Mi4xNjguMTIwLjEwMDwvU1BBTj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjazsgbXNv LWNvbG9yLWFsdDogd2luZG93dGV4dCI+PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1N c29Ob3JtYWwgCnN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluOyB0YWItc3RvcHM6IGxp c3QgMi41aW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj54eHh4eHh4eHh4eHh4eHh4eDwv U1BBTj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFsdDogd2luZG93dGV4 dCI+PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiAwcHQgMS41aW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj5OYXRlZCBm YWlsb3ZlciBib3g8L1NQQU4+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1h bHQ6IHdpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBi bGFjayI+eHh4eHh4eHh4eHh4eHh4eHg8L1NQQU4+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7 IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluIj48U1BBTiAKc3R5 bGU9IkNPTE9SOiBibGFjayI+MTkyLjE2OC4xMjEuMTAxPC9TUEFOPjxTUEFOIApzdHlsZT0iQ09M T1I6IGJsYWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48 L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbiI+ PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPmludGVybmFsIG1haWwgc2VydmVyPG86cD48L286 cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw cHQgMS41aW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv U1BBTj48L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAx LjVpbiI+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPmlwIHJ1PG86cD48L286cD48L1NQQU4+ PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMS41aW4i PjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj4wOjxTUEFOIApzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+ZnJvbSBhbGwgbG9v a3VwIApsb2NhbDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjayI+ MzI3NjY6PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPmZyb20g CmFsbCBsb29rdXAgbWFpbjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBi bGFjayI+MzI3Njc6PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFO PmZyb20gCmFsbCBsb29rdXAgMjUzPG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMS41aW4iPjxTUEFOIApzdHlsZT0iQ09M T1I6IGJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbiI+PFNQQU4gCnN0eWxlPSJDT0xPUjog YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFj ayI+aXAgcm88L1NQQU4+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6 IHdpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFj ayI+NjYuOTIuMTE0LjMyLzI4IGRldiBldGgwPFNQQU4gCnN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7IDwvU1BBTj5zY29wZSBsaW5rPC9TUEFOPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJs YWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+CjxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbiI+PFNQQU4g CnN0eWxlPSJDT0xPUjogYmxhY2siPjIwOS4xNDEuMi4xOTIvMjcgZGV2IGV0aDE8U1BBTiAKc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPnNjb3BlIGxpbms8L1NQQU4+PFNQ QU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0IDEuNWluIj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjayI+MTkyLjE2OC4xMTkuMC8y NCBkZXYgZXRoMjxTUEFOIApzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+ c2NvcGUgbGluazwvU1BBTj48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFs dDogd2luZG93dGV4dCI+PG86cD48L286cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMS41aW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJs YWNrIj4xOTIuMTY4LjEyMC4wLzI0IGRldiBldGgzPFNQQU4gCnN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7IDwvU1BBTj5zY29wZSBsaW5rPC9TUEFOPjxTUEFOIApzdHlsZT0iQ09MT1I6 IGJsYWNrOyBtc28tY29sb3ItYWx0OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+ CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbiI+PFNQ QU4gCnN0eWxlPSJDT0xPUjogYmxhY2siPjEyNy4wLjAuMC84IGRldiBsbzxTUEFOIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7IAo8L1NQQU4+c2NvcGUgbGluazwvU1BBTj48U1BBTiAK c3R5bGU9IkNPTE9SOiBibGFjazsgbXNvLWNvbG9yLWFsdDogd2luZG93dGV4dCI+PG86cD48L286 cD48L1NQQU4+PC9QPgo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw cHQgMS41aW4iPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrIj5kZWZhdWx0IHZpYSA2Ni45Mi4x MTQuMzMgZGV2IGV0aDA8L1NQQU4+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1zby1jb2xv ci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4KPFAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiAKc3R5bGU9IkNPTE9SOiBibGFj ayI+Jm5ic3A7PC9TUEFOPjxTUEFOIApzdHlsZT0iQ09MT1I6IGJsYWNrOyBtc28tY29sb3ItYWx0 OiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gY2xhc3M9RW1haWxTdHlsZTE1PjxTUEFO IApzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZv bnQtc2l6ZTogMTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1NQQU4+PC9QPgo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIApzdHlsZT0i Q09MT1I6IGJsYWNrIj4mbmJzcDs8L1NQQU4+PFNQQU4gCnN0eWxlPSJDT0xPUjogYmxhY2s7IG1z by1jb2xvci1hbHQ6IHdpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0JP RFk+PC9IVE1MPg== ------_=_NextPart_001_01C258E8.B2CAD8E0-- From lartc@24x7linux.com Tue Sep 10 19:39:41 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Tue, 10 Sep 2002 20:39:41 +0200 Subject: [LARTC] 4 nic advanced routing question In-Reply-To: <3D7E1F02.4020301@fibrespeed.net> References: <19ED2BC99F18344B8B571CD827577675109829@genisis.Marshtek.loc> <20020910162917.GD2397@creaciondeweb.com> <3D7E1F02.4020301@fibrespeed.net> Message-ID: <20020910183941.GA2960@localhost> On Tuesday, 10 September 2002, at 12:34:10 -0400, Michael T. Babcock wrote: > I'm not sure why you're having a problem: > His document was encoded properly ... > Yes, multipart/alternative, but I think what the reader was trying to say us that the ASCII version of the email seems to include some kind of ASCII-art that depicts the sender's network. But at least in my email client the drawing seems broken and gives no clues about topology. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From ciprian@promo.ro Tue Sep 10 21:16:20 2002 From: ciprian@promo.ro (Ciprian Niculescu) Date: Tue, 10 Sep 2002 23:16:20 +0300 Subject: [LARTC] HTB syslog message Message-ID: <3D7E5314.202@promo.ro> Sep 10 04:08:12 www kernel: HTB: bad diff in charge, diff=9DC000 now=3375104 then=4288004096 j=471 i get mesages like this one, what is it? Suse 7.2 - kernel 2.4.18 + htb 3.3 + imq C From stef.coene@docum.org Tue Sep 10 21:34:27 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 10 Sep 2002 22:34:27 +0200 Subject: [LARTC] HTB syslog message In-Reply-To: <3D7E5314.202@promo.ro> References: <3D7E5314.202@promo.ro> Message-ID: <200209102234.27227.stef.coene@docum.org> On Tuesday 10 September 2002 22:16, Ciprian Niculescu wrote: > Sep 10 04:08:12 www kernel: HTB: bad diff in charge, diff=3D9DC000 > now=3D3375104 then=3D4288004096 j=3D471 > > i get mesages like this one, what is it? > > Suse 7.2 - kernel 2.4.18 + htb 3.3 + imq It's a bug in the kernel. But htb3.6 fixes this and I think kernel 2.4.1= 9 is=20 also fixed. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From thad@marshtek.com Tue Sep 10 22:17:52 2002 From: thad@marshtek.com (Thad Marsh) Date: Tue, 10 Sep 2002 17:17:52 -0400 Subject: [LARTC] 4 nic advanced routing question update Message-ID: <19ED2BC99F18344B8B571CD82757767510982C@genisis.Marshtek.loc> This is a multi-part message in MIME format. ------_=_NextPart_001_01C2590F.85AB1C50 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ok i will do it in text: 66.92.114.46 eth0 209.141.2.194 eth1 192.168.119.101 eth2 192.168.120.101 eth3=20 What i have is a linux box RH7.3 which will eventually run Shorewall = Firewall. On this box there is eth0 66.92.114.46 conneted to isp1 and = eth1 209.141.2.194 connected to isp2 It also has eth2 192.168.119.101 and eth3 192.168.120.101 which will = connect to a failover appliance which has 2 wan interface and one lan = interface. What i need is to have traffic going to eth0 be routed to eth2 and = traffic going to eth1 routed to eth3, and vice versa. Right now i can ping eth0, eth1, eth2, eth3 on the box. I also can ping = beyond eth0 and eth1. what i can not do is ping beyond eth2 and eth3. I have tried several table statements and played with pref to no avail. = any insight would be helpful! -----Original Message----- From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com] Sent: Tue 9/10/2002 2:39 PM To: lartc@mailman.ds9a.nl Cc:=20 Subject: Re: [LARTC] 4 nic advanced routing question On Tuesday, 10 September 2002, at 12:34:10 -0400, Michael T. Babcock wrote: > I'm not sure why you're having a problem: > His document was encoded properly ... >=20 Yes, multipart/alternative, but I think what the reader was trying to say us that the ASCII version of the email seems to include some kind of ASCII-art that depicts the sender's network. But at least in my email client the drawing seems broken and gives no clues about topology. --=20 Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux = 2.4.19-pre6aa1) _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ------_=_NextPart_001_01C2590F.85AB1C50 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [LARTC] 4 nic advanced routing question update

ok i will do it in text:

66.92.114.46 eth0
209.141.2.194 eth1
192.168.119.101 eth2
192.168.120.101 eth3

What i have is a linux box RH7.3 which will eventually run Shorewall = Firewall. On this box there is eth0 66.92.114.46 conneted to isp1 and = eth1 209.141.2.194 connected to isp2
It also has eth2 192.168.119.101 and eth3 192.168.120.101 which will = connect to a failover appliance which has 2 wan interface and one lan = interface.


What i need is to have traffic going to eth0 be routed to eth2 and = traffic going to eth1 routed to eth3, and vice versa.

Right now i can ping eth0, eth1, eth2, eth3 on the box.  I also can = ping beyond eth0 and eth1.  what i can not do is ping beyond eth2 = and eth3.

I have tried several table statements and played with pref to no = avail. 

any insight would be helpful!



-----Original Message-----
From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com]
Sent: Tue 9/10/2002 2:39 PM
To: lartc@mailman.ds9a.nl
Cc:
Subject: Re: [LARTC] 4 nic advanced routing question

On Tuesday, 10 September 2002, at 12:34:10 -0400,
Michael T. Babcock wrote:

> I'm not sure why you're having a problem:
> His document was encoded properly ...
>
Yes, multipart/alternative, but I think what the reader was trying = to
say us that the ASCII version of the email seems to include some kind = of
ASCII-art that depicts the sender's network. But at least in my = email
client the drawing seems broken and gives no clues about topology.

--
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Woody = (Linux 2.4.19-pre6aa1)
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9= a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

------_=_NextPart_001_01C2590F.85AB1C50-- From ja@ssi.bg Wed Sep 11 01:35:31 2002 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 11 Sep 2002 00:35:31 +0000 (GMT) Subject: [LARTC] 4 nic advanced routing question In-Reply-To: <19ED2BC99F18344B8B571CD827577675109829@genisis.Marshtek.loc> Message-ID: Hello, On Tue, 10 Sep 2002, Thad Marsh wrote: > Can some one point me to a reference for how to route two wan nics and > two internal nics on the same box. Here you can find some documents and patches on this issue: http://www.ssi.bg/~ja/#routes Regards -- Julian Anastasov From mabrown-lartc@securepipe.com Tue Sep 10 22:49:52 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Tue, 10 Sep 2002 16:49:52 -0500 (CDT) Subject: [LARTC] 4 nic advanced routing question update In-Reply-To: <19ED2BC99F18344B8B571CD82757767510982C@genisis.Marshtek.loc> Message-ID: Thad, Preface: - - - - - - I'm not certain that I understand your ultimate goal, though I'm sure I do not understand what you mean by a failover appliance.... (I know what such devices do, but I don't see how you are integrating it into this solution, but that's your problem.) : ok i will do it in text: : : 66.92.114.46 eth0 : 209.141.2.194 eth1 : 192.168.119.101 eth2 : 192.168.120.101 eth3 : : What i have is a linux box RH7.3 which will eventually run Shorewall : Firewall. On this box there is eth0 66.92.114.46 conneted to isp1 and : eth1 209.141.2.194 connected to isp2 It also has eth2 192.168.119.101 : and eth3 192.168.120.101 which will connect to a failover appliance : which has 2 wan interface and one lan interface. : : What i need is to have traffic going to eth0 be routed to eth2 and : traffic going to eth1 routed to eth3, and vice versa. This appears to be the rub! I assume for the purposes of my answer that you don't want either of these pairs of networks knowing about the others. This is essentially turning your linux box into two separate routers....if this is not what you intend, at least it might get you started. You'll need to take the following steps: - create routing tables for each of the sets of networks between which you want to pass traffic - modify the RPDB to select traffic based on the interface on which a packet arrives # -- numbers chosen here are arbitrary, but between 1 and 253 # labels are also completely arbitary # echo 4 public-link-0 >> /etc/iproute2/rt_tables # -- table identifiers below are looked up in the above file # (/etc/iproute2/rt_tables) # ip route add table public-link-0 192.168.119.0/24 dev eth2 ip route add table public-link-0 66.92.114.32/28 dev eth0 ip route add table public-link-0 default via 66.92.114.33 dev eth0 # -- numbers here are equally as arbitrary--use alabel # that makes sense to you # echo 5 public-link-1 >> /etc/iproute2/rt_tables ip route add table public-link-1 192.168.120.0/24 dev eth3 ip route add table public-link-1 209.141.2.192/27 dev eth1 ip route add table public-link-1 default via $GW_ON_ETH1 dev eth1 # Notice that this simply sets up the routing tables. # Now you need to use the RPDB to ask for lookups to the routing table you # wish to use. # -- here we'll configure the policy routing to force packets # coming to and from the separate networks through the right interfaces # ip rule add iif eth2 table public-link-0 ip rule add iif eth0 table public-link-0 ip rule add iif eth1 table public-link-1 ip rule add iif eth3 table public-link-1 # -- now flush the routing cache # ip route flush cache Notes: - - - - - - - I can't simulate your setup....this may not work, and may not do what you want - locally generated traffic is a problem I don't deal with - this will only allow packets to and from eth0 <--> eth2 and eth1 <--> eth3 - you'll need to do masquerading with your packet filtering engine if you want any of the rfc1918 networks to reach the internet Oh, yes....by the way, Julian just responded to this. Read his documentation and the iproute2 manual thoroughly and carefully. There is more than enough to get you to where you want to go. If you need an online iproute2 manual there are a few--try this one: http://defiant.coinet.com/iproute2/ip-cref/node1.html Good luck and bon voyage! -Martin : Right now i can ping eth0, eth1, eth2, eth3 on the box. I also can : ping beyond eth0 and eth1. what i can not do is ping beyond eth2 and : eth3. : : I have tried several table statements and played with pref to no avail. : : any insight would be helpful! : : : : -----Original Message----- : From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com] : Sent: Tue 9/10/2002 2:39 PM : To: lartc@mailman.ds9a.nl : Cc: : Subject: Re: [LARTC] 4 nic advanced routing question : : On Tuesday, 10 September 2002, at 12:34:10 -0400, : Michael T. Babcock wrote: : : > I'm not sure why you're having a problem: : > His document was encoded properly ... : > : Yes, multipart/alternative, but I think what the reader was trying to : say us that the ASCII version of the email seems to include some kind of : ASCII-art that depicts the sender's network. But at least in my email : client the drawing seems broken and gives no clues about topology. : : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From ciprian@promo.ro Tue Sep 10 23:35:09 2002 From: ciprian@promo.ro (Ciprian Niculescu) Date: Wed, 11 Sep 2002 01:35:09 +0300 Subject: [LARTC] Kernel Packet Traveling Diagram Message-ID: <3D7E739D.8080903@promo.ro> Hy, I did some tests and i have some modifications and questions on the Kernel Packet Traveling Diagram found at http://www.docum.org/stef.coene/qos/kptd/ Test where made on a Suse 7.2 - kernel 2.4.18 + htb 3.3 + imq, iptables 1.2.6-imq and tc_htb. Where is on the diagram the mangle INPUT,FORWARD,POSTROUTING??? i tested only the POSTROUTING, and found that is before "nat POSTROUTING", beacouse i put: iptables -t mangle -A POSTROUTING -o eth0 -j LOG --log-prefix LOG_FILTER_EXT-DEF- and get in the logs this: Sep 11 00:18:22 www kernel: LOG_FILTER_EXT-DEF-IN= OUT=eth0 SRC=10.0.0.100 DST=80.128.37.129 LEN=1 and i have: Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.0.0.0/24 0.0.0.0/0 to:x.x.x.x so it's right??? if yes Stef please modify the diagram, if no, why? and probably the "mangle INPUT" is after "filter INPUT" and "mangle FORWARD" is after "filter FORWARD" C From thad@marshtek.com Wed Sep 11 01:03:14 2002 From: thad@marshtek.com (Thad Marsh) Date: Tue, 10 Sep 2002 20:03:14 -0400 Subject: [LARTC] 4 nic advanced routing question update Message-ID: <19ED2BC99F18344B8B571CD82757767510982D@genisis.Marshtek.loc> I just wanted to clarify the failover appliance piece. =20 The failover appliance was purchased to allow incoming and outgoing = traffic when one of the two isps went down quite a while ago.=20 The host piece was handled by a variety of commercial firewalls which = have since failed, leaving us searching for an alternative. The firewall appliance is just nat and only had the ability to deal with = one ip per interface, limiting our ability to host multiple servers = without changing a lot of ports to non-standard ones. That is why we are = putting the Linux box in front of the appliance to provide security and = handle multiple ips (phase two after we get the basics down). This way = the area between the Linux/firewall and the failover appliance creates a = dmz for external servers accessible while the internal clients have the = benefit of outgoing failover. =20 Not sure if this is the best way but it seemed to make sense, thoughts? Martin in answer to this below, I guess since the two internal eth2 and = eth3 are really a dmz I suppose it wouldn't matter if they know just so = long as when a request comes from the outside they know how to route it = back out properly even when one isp is down. This appears to be the rub! I assume for the purposes of my answer that = you don't want either of these pairs of networks knowing about the others. This is essentially turning your linux box into two separate routers....if this is not what you intend, at least it might get you started. Again thanks to all and look forward to your input. -----Original Message----- From: Martin A. Brown [mailto:mabrown-lartc@securepipe.com] Sent: Tuesday, September 10, 2002 5:50 PM To: Thad Marsh Cc: lartc@mailman.ds9a.nl Subject: RE: [LARTC] 4 nic advanced routing question update Thad, Preface: - - - - - - I'm not certain that I understand your ultimate goal, though I'm sure I do not understand what you mean by a failover appliance.... (I = know what such devices do, but I don't see how you are integrating it into = this solution, but that's your problem.) : ok i will do it in text: : : 66.92.114.46 eth0 : 209.141.2.194 eth1 : 192.168.119.101 eth2 : 192.168.120.101 eth3 : : What i have is a linux box RH7.3 which will eventually run Shorewall : Firewall. On this box there is eth0 66.92.114.46 conneted to isp1 and : eth1 209.141.2.194 connected to isp2 It also has eth2 192.168.119.101 : and eth3 192.168.120.101 which will connect to a failover appliance : which has 2 wan interface and one lan interface. : : What i need is to have traffic going to eth0 be routed to eth2 and : traffic going to eth1 routed to eth3, and vice versa. This appears to be the rub! I assume for the purposes of my answer that = you don't want either of these pairs of networks knowing about the others. This is essentially turning your linux box into two separate routers....if this is not what you intend, at least it might get you started. You'll need to take the following steps: - create routing tables for each of the sets of networks between which you want to pass traffic - modify the RPDB to select traffic based on the interface on which a packet arrives # -- numbers chosen here are arbitrary, but between 1 and 253 # labels are also completely arbitary # echo 4 public-link-0 >> /etc/iproute2/rt_tables # -- table identifiers below are looked up in the above file # (/etc/iproute2/rt_tables) # ip route add table public-link-0 192.168.119.0/24 dev eth2 ip route add table public-link-0 66.92.114.32/28 dev eth0 ip route add table public-link-0 default via 66.92.114.33 dev eth0 # -- numbers here are equally as arbitrary--use alabel # that makes sense to you # echo 5 public-link-1 >> /etc/iproute2/rt_tables ip route add table public-link-1 192.168.120.0/24 dev eth3 ip route add table public-link-1 209.141.2.192/27 dev eth1 ip route add table public-link-1 default via $GW_ON_ETH1 dev eth1 # Notice that this simply sets up the routing tables. # Now you need to use the RPDB to ask for lookups to the routing table = you # wish to use. # -- here we'll configure the policy routing to force packets # coming to and from the separate networks through the right = interfaces # ip rule add iif eth2 table public-link-0 ip rule add iif eth0 table public-link-0 ip rule add iif eth1 table public-link-1 ip rule add iif eth3 table public-link-1 # -- now flush the routing cache # ip route flush cache Notes: - - - - - - - I can't simulate your setup....this may not work, and may not do what you want - locally generated traffic is a problem I don't deal with - this will only allow packets to and from eth0 <--> eth2 and eth1 <--> eth3 - you'll need to do masquerading with your packet filtering engine if you want any of the rfc1918 networks to reach the internet Oh, yes....by the way, Julian just responded to this. Read his documentation and the iproute2 manual thoroughly and carefully. There = is more than enough to get you to where you want to go. If you need an online iproute2 manual there are a few--try this one: http://defiant.coinet.com/iproute2/ip-cref/node1.html Good luck and bon voyage! -Martin : Right now i can ping eth0, eth1, eth2, eth3 on the box. I also can : ping beyond eth0 and eth1. what i can not do is ping beyond eth2 and : eth3. : : I have tried several table statements and played with pref to no = avail.=20 : : any insight would be helpful! : : : : -----Original Message----- : From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com] : Sent: Tue 9/10/2002 2:39 PM : To: lartc@mailman.ds9a.nl : Cc: : Subject: Re: [LARTC] 4 nic advanced routing question : : On Tuesday, 10 September 2002, at 12:34:10 -0400, : Michael T. Babcock wrote: : : > I'm not sure why you're having a problem: : > His document was encoded properly ... : > : Yes, multipart/alternative, but I think what the reader was trying to : say us that the ASCII version of the email seems to include some kind = of : ASCII-art that depicts the sender's network. But at least in my email : client the drawing seems broken and gives no clues about topology. : : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From thad@marshtek.com Wed Sep 11 01:28:15 2002 From: thad@marshtek.com (Thad Marsh) Date: Tue, 10 Sep 2002 20:28:15 -0400 Subject: [LARTC] 4 nic advanced routing question update Message-ID: <19ED2BC99F18344B8B571CD82757767510982E@genisis.Marshtek.loc> This line gave me an errors I substituted $GW_ON_ETH1 for the ip of the = interface gateway 209.141.2.195: ip route add table public-link-1 default via $GW_ON_ETH1 dev eth1 I am still unable to ping beyond the internal interface hon the = firewall. Ie from the firewall I can ping 209.141.2.192, 66.92.114.33 = but not the next hop from 192.168.119.101 which is 192.168.119.100. = here are the rules and routes: ip ru 0: from all lookup local 32762: from all iif eth3 lookup public-link-1 32763: from all iif eth1 lookup public-link-1 32764: from all iif eth0 lookup public-link-0 32765: from all iif eth2 lookup public-link-0 32766: from all lookup main 32767: from all lookup 253 ip ro 66.92.114.32/28 dev eth0 scope link 209.141.2.192/27 dev eth1 scope link 192.168.119.0/24 dev eth2 scope link 192.168.120.0/24 dev eth3 scope link 127.0.0.0/8 dev lo scope link default via 66.92.114.33 dev eth0 ip ad 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:75:9f:07:79 brd ff:ff:ff:ff:ff:ff inet 66.92.114.46/28 brd 66.92.114.47 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:10:5a:a2:75:0d brd ff:ff:ff:ff:ff:ff inet 209.141.2.194/27 brd 209.141.2.223 scope global eth1 4: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:10:5a:a2:74:2f brd ff:ff:ff:ff:ff:ff inet 192.168.119.101/24 brd 192.168.119.255 scope global eth2 5: eth3: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:60:08:bf:1c:c2 brd ff:ff:ff:ff:ff:ff inet 192.168.120.101/24 brd 192.168.120.255 scope global eth3 Thanks again for the help! -----Original Message----- From: Martin A. Brown [mailto:mabrown-lartc@securepipe.com] Sent: Tuesday, September 10, 2002 5:50 PM To: Thad Marsh Cc: lartc@mailman.ds9a.nl Subject: RE: [LARTC] 4 nic advanced routing question update Thad, Preface: - - - - - - I'm not certain that I understand your ultimate goal, though I'm sure I do not understand what you mean by a failover appliance.... (I = know what such devices do, but I don't see how you are integrating it into = this solution, but that's your problem.) : ok i will do it in text: : : 66.92.114.46 eth0 : 209.141.2.194 eth1 : 192.168.119.101 eth2 : 192.168.120.101 eth3 : : What i have is a linux box RH7.3 which will eventually run Shorewall : Firewall. On this box there is eth0 66.92.114.46 conneted to isp1 and : eth1 209.141.2.194 connected to isp2 It also has eth2 192.168.119.101 : and eth3 192.168.120.101 which will connect to a failover appliance : which has 2 wan interface and one lan interface. : : What i need is to have traffic going to eth0 be routed to eth2 and : traffic going to eth1 routed to eth3, and vice versa. This appears to be the rub! I assume for the purposes of my answer that = you don't want either of these pairs of networks knowing about the others. This is essentially turning your linux box into two separate routers....if this is not what you intend, at least it might get you started. You'll need to take the following steps: - create routing tables for each of the sets of networks between which you want to pass traffic - modify the RPDB to select traffic based on the interface on which a packet arrives # -- numbers chosen here are arbitrary, but between 1 and 253 # labels are also completely arbitary # echo 4 public-link-0 >> /etc/iproute2/rt_tables # -- table identifiers below are looked up in the above file # (/etc/iproute2/rt_tables) # ip route add table public-link-0 192.168.119.0/24 dev eth2 ip route add table public-link-0 66.92.114.32/28 dev eth0 ip route add table public-link-0 default via 66.92.114.33 dev eth0 # -- numbers here are equally as arbitrary--use alabel # that makes sense to you # echo 5 public-link-1 >> /etc/iproute2/rt_tables ip route add table public-link-1 192.168.120.0/24 dev eth3 ip route add table public-link-1 209.141.2.192/27 dev eth1 ip route add table public-link-1 default via $GW_ON_ETH1 dev eth1 # Notice that this simply sets up the routing tables. # Now you need to use the RPDB to ask for lookups to the routing table = you # wish to use. # -- here we'll configure the policy routing to force packets # coming to and from the separate networks through the right = interfaces # ip rule add iif eth2 table public-link-0 ip rule add iif eth0 table public-link-0 ip rule add iif eth1 table public-link-1 ip rule add iif eth3 table public-link-1 # -- now flush the routing cache # ip route flush cache Notes: - - - - - - - I can't simulate your setup....this may not work, and may not do what you want - locally generated traffic is a problem I don't deal with - this will only allow packets to and from eth0 <--> eth2 and eth1 <--> eth3 - you'll need to do masquerading with your packet filtering engine if you want any of the rfc1918 networks to reach the internet Oh, yes....by the way, Julian just responded to this. Read his documentation and the iproute2 manual thoroughly and carefully. There = is more than enough to get you to where you want to go. If you need an online iproute2 manual there are a few--try this one: http://defiant.coinet.com/iproute2/ip-cref/node1.html Good luck and bon voyage! -Martin : Right now i can ping eth0, eth1, eth2, eth3 on the box. I also can : ping beyond eth0 and eth1. what i can not do is ping beyond eth2 and : eth3. : : I have tried several table statements and played with pref to no = avail.=20 : : any insight would be helpful! : : : : -----Original Message----- : From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com] : Sent: Tue 9/10/2002 2:39 PM : To: lartc@mailman.ds9a.nl : Cc: : Subject: Re: [LARTC] 4 nic advanced routing question : : On Tuesday, 10 September 2002, at 12:34:10 -0400, : Michael T. Babcock wrote: : : > I'm not sure why you're having a problem: : > His document was encoded properly ... : > : Yes, multipart/alternative, but I think what the reader was trying to : say us that the ASCII version of the email seems to include some kind = of : ASCII-art that depicts the sender's network. But at least in my email : client the drawing seems broken and gives no clues about topology. : : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From SKUDA@telefonica.net Wed Sep 11 11:18:22 2002 From: SKUDA@telefonica.net (skuda) Date: 11 Sep 2002 10:18:22 +0000 Subject: [LARTC] [Fwd: streaming problem] Message-ID: <1031739503.5461.5.camel@skuda.betanetgeb.com> --=-PVq1Jp2uyT6U0kjOjzRM Content-Type: text/plain Content-Transfer-Encoding: 7bit --=-PVq1Jp2uyT6U0kjOjzRM Content-Disposition: inline Content-Description: Reenviado mensaje - streaming problem Content-Type: message/rfc822 Subject: streaming problem From: skuda To: lartc@mailman.ds9a.nl Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 22:21:55 +0000 Message-Id: <1031698628.5611.5.camel@skuda.betanetgeb.com> Mime-Version: 1.0 hi all :), i have a problem, i have 2 servers, with linux and apache 1.3.26 in it, one (A) have a slow connection 64kbit isdn, and the other (B) have a fast connection 100mbit, in A i have motion (http://motion.technolust.cx/) sharing a webcam in port 8001 and a java applet (cambozola) to show in the index of the webserver the camera in real time, i would like connect the fast (B) to the slow connection (A) and share with many people this camera without open more than one connection from (B) to (A), because bandwith is too little to open many connections with B. Do you know any solution to this problem? thanks in advance --=-PVq1Jp2uyT6U0kjOjzRM-- From leoball@opalsoft.net Wed Sep 11 12:15:27 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Wed, 11 Sep 2002 07:15:27 -0400 Subject: [LARTC] Kernel Packet Traveling Diagram Message-ID: <5.1.0.14.1.20020911070825.00a31ae0@opalsoft.net> Hi, The diagram is not completed. If you check previous messages in this list you will see that mangle INPUT, FORWARD and POSTROUTING are not included yet. It's my responsability to update the diagram. I'm going to do it as soon as possible. Mangle is always before nat, have a look to http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO.txt Best regards, Leonardo Balliache. From stef.coene@docum.org Wed Sep 11 19:11:13 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 11 Sep 2002 20:11:13 +0200 Subject: [LARTC] Kernel Packet Traveling Diagram In-Reply-To: <3D7E739D.8080903@promo.ro> References: <3D7E739D.8080903@promo.ro> Message-ID: <200209112011.13766.stef.coene@docum.org> > i tested only the POSTROUTING, and found that is before "nat > POSTROUTING", beacouse i put: > > iptables -t mangle -A POSTROUTING -o eth0 -j LOG --log-prefix > LOG_FILTER_EXT-DEF- > > and get in the logs this: > Sep 11 00:18:22 www kernel: LOG_FILTER_EXT-DEF-IN=3D OUT=3Deth0 > SRC=3D10.0.0.100 DST=3D80.128.37.129 LEN=3D1 > > and i have: > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > SNAT all -- 10.0.0.0/24 0.0.0.0/0 to:x.x.x.x > > > so it's right??? if yes Stef please modify the diagram, if no, why? > > and probably the "mangle INPUT" is after "filter INPUT" > > and "mangle FORWARD" is after "filter FORWARD" I updated the diagram. Like Leonardo said, I putted mangle before nat. = Any=20 updates/remarks are welcome. I also added the imq device (right after ma= ngle=20 for incoming packets and after all tables for outgoing packets). Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From nick@fluffyspider.com.au Thu Sep 12 02:18:22 2002 From: nick@fluffyspider.com.au (Nick) Date: Thu, 12 Sep 2002 11:18:22 +1000 (EST) Subject: [LARTC] [Fwd: streaming problem] In-Reply-To: <1031739503.5461.5.camel@skuda.betanetgeb.com> Message-ID: Hi, This may or may not be what your looking for. Rather than finding some complex routing solution, you just need a proxy sitting on the machine what sits between the fast and slow connection. It makes a single connection to the camera and serves multiple connection to anyone else on the 100mb connection. I've used a camera server called 'camserv' and it comes with a utility proxy for just this type of thing. Give it a go. The only other thing I can think you might want to do is route connections going the cameras source to the proxy so users don't need to know its not a dedicated connection. Nick On 11 Sep 2002, skuda wrote: hi all :), i have a problem, i have 2 servers, with linux and apache 1.3.26 in it, one (A) have a slow connection 64kbit isdn, and the other (B) have a fast connection 100mbit, in A i have motion (http://motion.technolust.cx/) sharing a webcam in port 8001 and a java applet (cambozola) to show in the index of the webserver the camera in real time, i would like connect the fast (B) to the slow connection (A) and share with many people this camera without open more than one connection from (B) to (A), because bandwith is too little to open many connections with B. Do you know any solution to this problem? thanks in advance From tdiehl@rogueind.com Thu Sep 12 04:44:17 2002 From: tdiehl@rogueind.com (Tom Diehl) Date: Wed, 11 Sep 2002 23:44:17 -0400 (EDT) Subject: [LARTC] Routing/NAT question Message-ID: Hi all, I have a strange setup I am trying to get working. Initally I thought I could set it up by just setting up the correct routes. However after thinking about it I have convinced myself (maybe incorrectly) that I most likely need some sort of advanced NAT/routing setup. Below is a description of the networks involved: Local net (192.168.101.0/24) | | Linux machine eth1 (192.168.101.5)---- eth1:0 (10.140.227.245) | Iptables NAT/firewall | Linux machine wan0 (This is a sangoma wanpipe with a routable ip address) | ISP The 10.140.227.224/27 network is a private network that knows nothing about the 192.168.101.0/24 network and is not controlled by us. Previously they were run as 2 seperate networks. What we are trying to do is to be able to install some custom software on the local net machines (the 192.168.101.0 net) and have 5 specific subnets send the traffic down the 10.140... net and the rest of the non 192.168.... traffic out the wan0 interface. Currently the 192.168... net and the 10.140..... net are on the same wire. I could split them and put another interface in the linux box if necessary. Is this possible? If so can someone point me in the right direction on how? Does this even make sense? If not please let me know and I will try to explain further. FWIW the linux box is a Red Hat 7.3 box with all of the latest updates. Regards, -- .............Tom "Nothing would please me more than being able to tdiehl@rogueind.com hire ten programmers and deluge the hobby market with good software." -- Bill Gates 1976 We are still waiting .... From arc_of_descent@gmx.net Thu Sep 12 12:42:40 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Thu, 12 Sep 2002 17:12:40 +0530 Subject: [LARTC] reset /proc/net/dev Message-ID: <02091217115600.02481@sanitarium> HI List, How do i reset the values in /proc/net/dev ? This file holds values for count of each (packet && byte), (sent && received) through all interfaces. I'm using a monitor which reads values from this file and prints out some nicely formatted output. But i need to reset the values. ie. set then to zero. Restarting the network does not do what i want. I guess a reboot should do it. Any other way? -- arc_of_descent From tobias.geiger@web.de Thu Sep 12 13:20:05 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Thu, 12 Sep 2002 14:20:05 +0200 (CEST) Subject: [LARTC] reset /proc/net/dev Message-ID: <46884.212.2.37.233.1031833205.squirrel@kaeptnb.d2g.com> Hi, perhaps the only way (although untested) may be to "ip link set down" and to "rmmod " which is in my opinion impractible :) much nicer and easier: create a simple rule matching everything incoming/outgoing your desired device and insert it in the PREROUTING/POSTROUTING chain. (or a custom rule to which is jumped in INPUT and FORWARD / OUTPUT and FORWARD) e.g. iptables -t nat -I PREROUTING -i eth0 # for incoming iptables -t nat -I POSTROUTING -o eth0 # for outgoing or if u prefer not to use the nat table e.g. iptables -N eth0_out iptables -N eth0_in iptables -I INPUT -i eth0 -j eth0_in iptables -I FORWARD -i eth0 -j eth0_in iptables -I FORWARD -o eth0 -j eth0_out iptables -I INPUT -o eth0 -j eth0_out with "iptables -t nat -L -vx" / "iptables -L -vx" u can read bytes/packets and process this output in your script hope that helps.... tobias > > HI List, > How do i reset the values in /proc/net/dev ? > This file holds values for count of each (packet && byte), > (sent && received) through all interfaces. > > I'm using a monitor which reads values from this > file and prints out some nicely formatted output. > > But i need to reset the values. ie. set then to zero. > Restarting the network does not do what i want. > I guess a reboot should do it. > > Any other way? > > -- > arc_of_descent > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From arc_of_descent@gmx.net Thu Sep 12 13:36:13 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Thu, 12 Sep 2002 18:06:13 +0530 Subject: [LARTC] reset /proc/net/dev In-Reply-To: <46884.212.2.37.233.1031833205.squirrel@kaeptnb.d2g.com> References: <46884.212.2.37.233.1031833205.squirrel@kaeptnb.d2g.com> Message-ID: <02091218061302.03272@sanitarium> Tobias Geiger thus wrote: > with "iptables -t nat -L -vx" / "iptables -L -vx" u can read > bytes/packets and process this output in your script Yes thanx I've already used iptables for interesting graphical output of traffic and bandwidth usage But i just wanted to know how to reset /proc/net/dev/ cause its been bugging me for a long time :-) -- arc_of_descent From jma@nsicomm.com Thu Sep 12 14:35:51 2002 From: jma@nsicomm.com (James Ma) Date: Thu, 12 Sep 2002 09:35:51 -0400 Subject: [LARTC] iptable for multiple ip address Message-ID: <001701c25a61$5053ec40$7c010a0a@nsicomm.com> This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C25A3F.C889AAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, All, So far, all the applications I have seen for Iptables are focusing on = connecting a WAN with one IP address to a LAN and using NAT. My question = is if the iptables support multiple IP address on WAN side? If so, how = it works (you only have one NIC on WAN side)? Is static NAT (it might = not be the right term, I mean a static and permanent connection between = WAN IP address and LAN IP address) supported? Thanks in advance, James ------=_NextPart_000_0014_01C25A3F.C889AAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, All,
 
So far, all the applications I have = seen for=20 Iptables are focusing on connecting a WAN with one IP address to a = LAN and=20 using NAT. My question is if the iptables support multiple IP address on = WAN=20 side? If so, how it works (you only have one NIC on WAN side)? Is static = NAT (it=20 might not be the right term, I mean a static and permanent connection = between=20 WAN IP address and LAN IP address) supported?
 
 
Thanks in advance,
 
James
 
------=_NextPart_000_0014_01C25A3F.C889AAA0-- From mabrown-lartc@securepipe.com Thu Sep 12 15:32:15 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Thu, 12 Sep 2002 09:32:15 -0500 (CDT) Subject: [LARTC] Routing/NAT question In-Reply-To: Message-ID: Tom, I presume the iptables firewall will SNAT any connection from any of these internal networks to the world. Correct? In answer to your question, I assume that your 192.168.101.0/24 network and your 10.140.x.x networks are connected to the firewall on the same ethernet medium. If this is so, then you and there is no missing detail, your first impression was correct: You simply need to # ip addr add 10.140.227.245/$CIDR_MASK dev eth1 label eth1:0 (or use the traditional redhat ifcfg-eth1:0 technique) and tell the internal machines that the default gateway is 10.140.227.245. What you are doing here is using the same ethernet for two separate IP networks. If I were in your position I would absolutely add another interface for security and network segregation purposes, but, strictly speaking, you do not need to do so. -Martin : Hi all, : I have a strange setup I am trying to get working. Initally I thought : I could set it up by just setting up the correct routes. However after : thinking about it I have convinced myself (maybe incorrectly) that I : most likely need some sort of advanced NAT/routing setup. : : Below is a description of the networks involved: : : Local net (192.168.101.0/24) : | : | : Linux machine eth1 (192.168.101.5)---- eth1:0 (10.140.227.245) : | : Iptables NAT/firewall : | : Linux machine wan0 (This is a sangoma wanpipe with a routable ip address) : | : ISP : : The 10.140.227.224/27 network is a private network that knows nothing : about the 192.168.101.0/24 network and is not controlled by us. : Previously they were run as 2 seperate networks. What we are trying to : do is to be able to install some custom software on the local net : machines (the 192.168.101.0 net) and have 5 specific subnets send the : traffic down the 10.140... net and the rest of the non 192.168.... : traffic out the wan0 interface. Currently the 192.168... net and the : 10.140..... net are on the same wire. I could split them and put : another interface in the linux box if necessary. : : Is this possible? If so can someone point me in the right direction on how? : Does this even make sense? If not please let me know and I will try to : explain further. FWIW the linux box is a Red Hat 7.3 box with all of the latest : updates. : : Regards, : : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From jmorilla@creaciondeweb.com Thu Sep 12 15:54:03 2002 From: jmorilla@creaciondeweb.com (Juan Antonio Morillas Cerezo) Date: Thu, 12 Sep 2002 16:54:03 +0200 Subject: [LARTC] iptable for multiple ip address In-Reply-To: <001701c25a61$5053ec40$7c010a0a@nsicomm.com> References: <001701c25a61$5053ec40$7c010a0a@nsicomm.com> Message-ID: <20020912145403.GA5690@creaciondeweb.com> A fecha Thu, Sep 12, 2002 at 09:35:51AM -0400, James Ma dijo: > > So far, all the applications I have seen for Iptables are focusing on > connecting a WAN with one IP address to a LAN and using NAT. My question is if > the iptables support multiple IP address on WAN side? If so, how it works (you > only have one NIC on WAN side)? Is static NAT (it might not be the right term, > I mean a static and permanent connection between WAN IP address and LAN IP > address) supported? > Yes, with iptables you can have more than one IP address for each physical interface, both in "local" and "external" places, then you have to add them as aliases with ip, and do some NAT to connect each side, if there are private IPs involved. From andrew@mailerdirect.net Thu Sep 12 16:07:46 2002 From: andrew@mailerdirect.net (Andrew J. Barbara) Date: Thu, 12 Sep 2002 23:07:46 +0800 Subject: [LARTC] Content based Routing Message-ID: Just a quick question... Is there a way to do content based routing (i.e. routing based on a TCP or UDP port) without using iptables, i.e. using the ip command? Thanks Andrew From mabrown-lartc@securepipe.com Thu Sep 12 16:11:58 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Thu, 12 Sep 2002 10:11:58 -0500 (CDT) Subject: [LARTC] Content based Routing In-Reply-To: Message-ID: Nope. You can use ipchains/iptables to fwmark a packet and then route based on fwmark (which needs to be supported by your kernel). -Martin : Just a quick question... : Is there a way to do content based routing (i.e. routing based on a TCP : or UDP port) without using iptables, i.e. using the ip command? : : Thanks : Andrew : _______________________________________________ : LARTC mailing list / LARTC@mailman.ds9a.nl : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From markprezswa@hotmail.com Thu Sep 12 17:47:29 2002 From: markprezswa@hotmail.com (Mark Donaldson) Date: Thu, 12 Sep 2002 16:47:29 +0000 Subject: [LARTC] delete files Message-ID: Does anyone know any software that runs under Linux that does a military wipe, making file unreadable by deleting file then writing all ones and zeros, when deleting files. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From tobias.geiger@web.de Thu Sep 12 19:20:56 2002 From: tobias.geiger@web.de (Tobias Geiger) Date: Thu, 12 Sep 2002 20:20:56 +0200 Subject: [LARTC] delete files References: Message-ID: <3D80DB08.7050705@web.de> Hi, this is a little bit OT, so please ask such questions in irc-channels or other forums please. a quick "apt-cache show wipe" (on woody) brings up this: Package: wipe Priority: extra Section: utils Installed-Size: 124 Maintainer: Thomas Schoepf Architecture: i386 Version: 0.16-8 Depends: libc6 (>= 2.2.4-4) Filename: pool/main/w/wipe/wipe_0.16-8_i386.deb Size: 30586 MD5sum: c294c13d07feeaee895539499af787fa Description: Secure file deletion Recovery of supposedly erased data from magnetic media is easier than what many people would like to believe. A technique called Magnetic Force Microscopy (MFM) allows any moderately funded opponent to recover the last two or three layers of data written to disk. Wipe repeatedly writes special patterns to the files to be destroyed, using the fsync() call and/or the O_SYNC bit to force disk access. . Homepage: http://gsu.linux.org.tr/wipe/ p.s.: thats the biggest reason why i just love debian :) Mark Donaldson wrote: > Does anyone know any software that runs under Linux that does a > military wipe, making file unreadable by deleting file then writing all > ones and zeros, when deleting files. > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From lartc@24x7linux.com Thu Sep 12 20:49:14 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Thu, 12 Sep 2002 21:49:14 +0200 Subject: [LARTC] iptable for multiple ip address In-Reply-To: <20020912145403.GA5690@creaciondeweb.com> References: <001701c25a61$5053ec40$7c010a0a@nsicomm.com> <20020912145403.GA5690@creaciondeweb.com> Message-ID: <20020912194914.GA3566@localhost> On Thursday, 12 September 2002, at 16:54:03 +0200, Juan Antonio Morillas Cerezo wrote: > Yes, with iptables you can have more than one IP > address for each physical interface, both in "local" and > "external" places, then you have to add them as aliases with > ip, and do some NAT to connect each side, if there are private > IPs involved. > I would add the following. If what the original poster wants is to somehow give a LAN with private IP addressing access to the Internet using not a simple public IP address, but a pool of them, you easily can. Just create an iptables rule with a SNAT target like this: iptables -t nat -A POSTROUTING --out-interface $WAN_IF \ --jump SNAT --to-source $START_PUB_IP-$END_PUB_IP The only limitation I see with this approach is that IP addresses must be contiguous, but I think this is a typical scenario, because our ISP tend to give addresses in blocks :) Hope this helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From wa@almesberger.net Thu Sep 12 20:51:51 2002 From: wa@almesberger.net (Werner Almesberger) Date: Thu, 12 Sep 2002 16:51:51 -0300 Subject: [LARTC] tcng version 8v Message-ID: <20020912165151.A21389@almesberger.net> ... is on SourceForge, http://tcng.sourceforge.net/#src This is yet another maintenance release. The main feature is that tcsim now supports HTB (well, it can configure it. I haven't tried yet to actually run any traffic through it.). I've also advanced all the surrounding infrastructure (regression tests, etc.) to make this useful. tcng needs a very recent 2.4.20 kernel pre-release and a patched iproute2 source tree for HTB. tcng/README describes how the latter is created. The full change log is below. - Werner ---------------------------------- cut here ----------------------------------- Version 8v (12-SEP-2002) ------------------------ - configure is now compatible with 2.4.20 (pre-release, tested with pre6), - tcsim/setup.klib: added struct notifier_block declaration for 2.4.20-pre6 compatibility - tcsim/setup.klib: disables psched_tick (added in 2.4.20) when terminating - added HTB and its various dependencies to the tcsim kernel build process - runtests.sh now only counts tests instead of running them if environment variable TCNG_TESTS_COUNT is set - runtests.sh: added conditional test execution (tests/tstcond) - runtests.sh: added command runtests for regression testing the regression test script - README: described how to build tcsim with HTB support (tests/htb) - tcsim now sets printk log level to KERN_WARNING (4) - tcsim: added option -k to set kernel logging threshold - updated documentation accordingly - added "help" target to top-level Makefile -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From lartc@24x7linux.com Thu Sep 12 20:52:14 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Thu, 12 Sep 2002 21:52:14 +0200 Subject: [LARTC] Content based Routing In-Reply-To: References: Message-ID: <20020912195214.GB3566@localhost> On Thursday, 12 September 2002, at 23:07:46 +0800, Andrew J. Barbara wrote: > Just a quick question... > Is there a way to do content based routing (i.e. routing based on a TCP > or UDP port) without using iptables, i.e. using the ip command? > It doesn't seem to be possible with just "ip", as neither "ip rule" nor "ip route" have "selectors" for transport-level port. But you have ipchains/iptables to mark packets and "ip" to route them based on the mark put on them. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From LARTC@Tech.InteractiveNetworks.net Wed Sep 11 14:43:07 2002 From: LARTC@Tech.InteractiveNetworks.net (George J. Jahchan) Date: Wed, 11 Sep 2002 16:43:07 +0300 Subject: [LARTC] Traffic classification. Message-ID: <00d101c25999$c0f5d580$0a0fa8c0@diabelec.com> Are there any Linux tools to identify and report network traffic at the application layer (sort of an application-layer protocol sniffer)? Layer 2-to-4 sniffers are next to useless at identifying apps that do not use fixed and documented ports. Examples: Peer-to-peer apps or apps utilizing well known ports defined for other apps like non-http traffic to tcp/80, or non-ftp traffic to tcp/21, etc... From LARTC@Tech.InteractiveNetworks.net Wed Sep 11 14:43:20 2002 From: LARTC@Tech.InteractiveNetworks.net (George J. Jahchan) Date: Wed, 11 Sep 2002 16:43:20 +0300 Subject: [LARTC] htb/iptables: incoming vs. outgoing shaping? References: <200209070425.51264.cparpart@surakware.net> <200209071131.51304.stef.coene@docum.org> Message-ID: <00d201c25999$c0ff2450$0a0fa8c0@diabelec.com> Outgoing shaping (LAN --> WAN) makes sense as your input rate to the router is at LAN speeds while its output rate is at (relatively low-bandwidth) WAN speeds. A good set of rules will provide significant performance benefits for critical apps, while relegating non-critical ones to a "best effort" basis. Shaping incoming traffic with queueing technology (WAN --> LAN) does not make much sense as queues would occur after packets have crossed a (presumably congested) WAN link, to be forwarded by the routing engine to a 10, 100 or 1,000 Mbps infrastructure. Queues in such a case add unnecessary latency and provide no real benefit. From wa@almesberger.net Fri Sep 13 08:46:10 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 13 Sep 2002 04:46:10 -0300 Subject: [LARTC] tcng version 8w Message-ID: <20020913044610.A21918@almesberger.net> ... is on SourceForge, http://tcng.sourceforge.net/#src This one has the first steps towards getting non-IPv4 classification right: - I've added fields for skb meta-data (meta_protocol, etc.) - if USE_META_PROTOCOL is #defined (tcc -D... or tcsim -Xc,-D...), ip_hdr and ip6_hdr check the protocol number - if_u32 generates distinct classifier branches for each protocol - f_fw, f_tcindex, and f_u32 now default to ETH_P_ALL instead of ETH_P_IP The latter change affects how u32 classification works ! tests/protu32 illustrates how protocol-aware classification is used. What's missing: - C and tcc-ext-match need to support meta_protocol too - if_u32 does a few ugly things, and can also generate redundant filter stubs - remove USE_META_PROTOCOL :-) The next version will make meta data classification visible at the external interface, so if you're using this interface, this change will probably break your program. If you don't want to add support for meta fields to your program right now, you can simply work around the problem by redefinition ip_hdr and ip6_hdr to their old values (i.e. remove the if ... clause). The full change log is below. - Werner ---------------------------------- cut here ----------------------------------- Version 8w (13-SEP-2002) ------------------------ - added root of meta fields (__meta) and definitions for meta-fields in meta.tc (included via fields.tc) - added some layer > 2 protocol numbers to values.tc - tcsim's send command now has a "protocol" attribute (default: ETH_P_IP) - updated documentation according to above changes - ip_hdr and ip6_hdr now check meta_protocol if USE_META_PROTOCOL is #defined - added protocol selection support to if_u32.c (tests/protu32) - filters fw, tcindex, and u32, now default to ETH_P_ALL instad of ETH_P_IP - updated tests/cbqroot, tests/egress, tests/named, tests/selpath, tests/selpathcbq, tests/selpathdup, and tests/setpathgred accordingly - configure now detects and prints kernel extra version (e.g. pre7) -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From ludovic.drolez@freealter.com Fri Sep 13 11:05:51 2002 From: ludovic.drolez@freealter.com (Ludovic Drolez) Date: Fri, 13 Sep 2002 10:05:51 +0000 Subject: [LARTC] This simple ingress script blocks my traffic Message-ID: <3D81B87F.3060809@freealter.com> Hi ! I have a 56k modem internet connection and I want to control the BW of ftp downloads. But when I run the following script, my downloads are simply stopped (and they resume if I clear the rules): ----------------- #!/bin/sh DEV=ppp0 DOWNLINK=14kbit /sbin/ipchains -A input -i $DEV -p tcp -s 0/0 ftp-data -m 1 tc qdisc del dev $DEV root 2> /dev/null > /dev/null tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null tc qdisc add dev $DEV handle ffff: ingress tc filter add dev $DEV parent ffff: protocol ip prio 50 handle \ 1 fw police rate $DOWNLINK burst 3000 mtu 1500 drop flowid :1 ------------------ I have a Debian woody with the 2.4.18-k6 kernel. All modules are loaded (cls_u32, cls_fw, sch_ingress, ...) I get the same result If I try an "u32" match instead of a firewall mark match. When I tcpdump, it seems that the application does not receive incoming packets. When I ask for qdisc stats, it answers me "Sent 0 bytes 0 pkts (dropped 0, overlimits 0)" Any clue ? TIA, Ludovic. From raptor@tvskat.net Fri Sep 13 16:38:36 2002 From: raptor@tvskat.net (raptor) Date: Fri, 13 Sep 2002 11:38:36 -0400 Subject: [LARTC] tcng version 8v In-Reply-To: <20020912165151.A21389@almesberger.net> References: <20020912165151.A21389@almesberger.net> Message-ID: <20020913113836.2ebc7269.raptor@tvskat.net> any chances to run under 2.4.19 :") !! (I'm using mandrake kernel). From p.thompson@ncl.cjp.co.uk Fri Sep 13 09:53:00 2002 From: p.thompson@ncl.cjp.co.uk (Thompson,Peter) Date: Fri, 13 Sep 2002 09:53:00 +0100 Subject: [LARTC] iproute and marking packets. Message-ID: <8B6215367908D311A346009027719CE5016C7E7A@CJP_NCLE_NT01> I have browsed the archives and not found anything to answer my problem so here goes :-) my internal network is on the 10.0.0.0/16 my eth0 has 10.1.0.13 this address is NAT'ed at a cisco router which is 10.1.0.21 my eth1 has 217.41.191.35 and this is connected straight into the back of an ADSL modem the ip address of this is 217.41.191.38 the default gateway of this machine is the ADSL router. i have recompiled the kernel with routing/packet marking options needed. I have the machine talking to the net and replying via both interfaces. this is my script so far... echo 1 > /proc/sys/net/ipv4/ip_forward echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter ip route add default via 217.41.191.38 table T1 ip route add default via 10.1.0.21 table T2 # adds rules from the tables i guess. ip rule add from 217.41.191.35 table T1 ip rule add from 10.1.0.13 table T2 #need this to see other internal machines... route add -net 10.0.0.0/8 gw 10.1.0.21 dev eth0 this bit works fine.. What i want to do is mark smtp packets and send them via my 10.1.0.21 gateway. #iptables -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark 1 #iptables -t mangle -A PREROUTING -p tcp --dport 25 -j MARK --set-mark 1 #tried both methods here.. both result in failure... #ip ro add default dev eth0 table 10 #ip route add default via 10.1.0.21 dev eth0 table 10 #ip ru add fwmark 1 table 10 ive checked to see if the counters increment and they do.. so the marking is working fine.. just not the routing.. when i try to telnet to port 25 of anything i get a "no route to host" and nothing appears in TCPDUMP if i remove the ip ru add fwmark 1 i can then telnet to port 25 of anything again but via the adsl link... i am using iptables 1.2.7a and kernel 2.4.18 on a suse 8 box. anyone any ideas ? Thanks in advance. Pete Thompson From raptor@tvskat.net Fri Sep 13 16:54:24 2002 From: raptor@tvskat.net (raptor) Date: Fri, 13 Sep 2002 11:54:24 -0400 Subject: [LARTC] tcng version 8v In-Reply-To: <20020913113836.2ebc7269.raptor@tvskat.net> References: <20020912165151.A21389@almesberger.net> <20020913113836.2ebc7269.raptor@tvskat.net> Message-ID: <20020913115424.1ae6eeb2.raptor@tvskat.net> In fact from where to get the full-source of the latest&greatest 2.40.20 if i want ?! From blueflux@koffein.net Fri Sep 13 08:37:11 2002 From: blueflux@koffein.net (Oskar Andreasson) Date: Fri, 13 Sep 2002 09:37:11 +0200 (CEST) Subject: [LARTC] tcng version 8v In-Reply-To: <20020913115424.1ae6eeb2.raptor@tvskat.net> Message-ID: On Fri, 13 Sep 2002, raptor wrote: > In fact from where to get the full-source of the latest&greatest 2.40.20 > if i want ?! Have you tried ftp.kernel.org? _______________________________________________ LARTC > mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net From smohan@vsnl.com Fri Sep 13 10:33:55 2002 From: smohan@vsnl.com (S Mohan) Date: Fri, 13 Sep 2002 15:03:55 +0530 Subject: [LARTC] iproute and marking packets. In-Reply-To: <8B6215367908D311A346009027719CE5016C7E7A@CJP_NCLE_NT01> Message-ID: You would probably need to check the precedence of the rules. Routing based on fwmark may need to come ahead of the one that routes the packet to T2. Have not used it myself. This is logic and not experience. If this is wrong, forgive me for I know not. Mohan -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On Behalf Of Thompson,Peter Sent: 13 September 2002 14:23 To: 'lartc@mailman.ds9a.nl' Subject: [LARTC] iproute and marking packets. I have browsed the archives and not found anything to answer my problem so here goes :-) my internal network is on the 10.0.0.0/16 my eth0 has 10.1.0.13 this address is NAT'ed at a cisco router which is 10.1.0.21 my eth1 has 217.41.191.35 and this is connected straight into the back of an ADSL modem the ip address of this is 217.41.191.38 the default gateway of this machine is the ADSL router. i have recompiled the kernel with routing/packet marking options needed. I have the machine talking to the net and replying via both interfaces. this is my script so far... echo 1 > /proc/sys/net/ipv4/ip_forward echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter ip route add default via 217.41.191.38 table T1 ip route add default via 10.1.0.21 table T2 # adds rules from the tables i guess. ip rule add from 217.41.191.35 table T1 ip rule add from 10.1.0.13 table T2 #need this to see other internal machines... route add -net 10.0.0.0/8 gw 10.1.0.21 dev eth0 this bit works fine.. What i want to do is mark smtp packets and send them via my 10.1.0.21 gateway. #iptables -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark 1 #iptables -t mangle -A PREROUTING -p tcp --dport 25 -j MARK --set-mark 1 #tried both methods here.. both result in failure... #ip ro add default dev eth0 table 10 #ip route add default via 10.1.0.21 dev eth0 table 10 #ip ru add fwmark 1 table 10 ive checked to see if the counters increment and they do.. so the marking is working fine.. just not the routing.. when i try to telnet to port 25 of anything i get a "no route to host" and nothing appears in TCPDUMP if i remove the ip ru add fwmark 1 i can then telnet to port 25 of anything again but via the adsl link... i am using iptables 1.2.7a and kernel 2.4.18 on a suse 8 box. anyone any ideas ? Thanks in advance. Pete Thompson _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From herrold@owlriver.com Fri Sep 13 14:02:18 2002 From: herrold@owlriver.com (R P Herrold) Date: Fri, 13 Sep 2002 09:02:18 -0400 (EDT) Subject: [LARTC] Traffic classification. In-Reply-To: <00d101c25999$c0f5d580$0a0fa8c0@diabelec.com> Message-ID: On Wed, 11 Sep 2002, George J. Jahchan wrote: > Are there any Linux tools to identify and report network traffic at the > application layer (sort of an application-layer protocol sniffer)? Layer > 2-to-4 sniffers are next to useless at identifying apps that do not use > fixed and documented ports. Examples: Peer-to-peer apps or apps > utilizing well known ports defined for other apps like non-http traffic > to tcp/80, or non-ftp traffic to tcp/21, etc... tcpflow -- packaged in RPMs, with underlying SRPM at: ftp.owlriver.com in /pub/local/ORC/tcpflow/ comes to mind -- it allows line by line post-reconstruction and reverse engineering of an arbitrary IP protocol. I forget the reference site, but Google shjould reveal it. -- Russ Herrold From wa@almesberger.net Fri Sep 13 17:15:33 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 13 Sep 2002 13:15:33 -0300 Subject: [LARTC] tcng version 8v In-Reply-To: <20020913113836.2ebc7269.raptor@tvskat.net>; from raptor@tvskat.net on Fri, Sep 13, 2002 at 11:38:36AM -0400 References: <20020912165151.A21389@almesberger.net> <20020913113836.2ebc7269.raptor@tvskat.net> Message-ID: <20020913131533.D1781@almesberger.net> raptor wrote: > any chances to run under 2.4.19 :") !! (I'm using mandrake kernel). Sure. From tcng/README: | - obtain the Linux kernel source, version 2.4.3 or any later 2.4 kernel | or any 2.5 kernel from 2.5.0 to 2.5.4 (2.5.5 and above will be supported | at a later time) [...] | - obtain iproute2, version 991023, 001007, 010803, 010824, or 020116-try So unless Mandrake mangled their source tree quite badly, this should work just fine. Note that you need kernel and iproute2 sources only for tcsim, but not if tcc is all you want. If what you're interested in is HTB: You may even be able to get tcsim to pick up HTB from an older kernel source tree if the HTB patch was added manually. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From david_list@boreham.org Fri Sep 13 17:31:12 2002 From: david_list@boreham.org (David Boreham) Date: Fri, 13 Sep 2002 09:31:12 -0700 Subject: [LARTC] tcng version 8v References: <20020912165151.A21389@almesberger.net> <20020913113836.2ebc7269.raptor@tvskat.net> <20020913131533.D1781@almesberger.net> Message-ID: <051901c25b42$f93fc3b0$160aa8c0@mtbrook.boreham.org> > So unless Mandrake mangled their source tree quite badly, this should Mandrake ships an older version of HTB. I make a new kernel RPM (slower than building from kernel source, but I find more satisfying in the long run), replacing the old HTB patches with the new ones. Building from the rpm source allows you to see what patches are in there, often invaluable in diagnosing why off the shelf patches aren't taking in a distro's kernel tree. From tdiehl@rogueind.com Fri Sep 13 17:57:32 2002 From: tdiehl@rogueind.com (Tom Diehl) Date: Fri, 13 Sep 2002 12:57:32 -0400 (EDT) Subject: [LARTC] Re: Routing/NAT question In-Reply-To: Message-ID: On Thu, 12 Sep 2002, Martin A. Brown wrote: Hi Martin, Thanks for responding. > I presume the iptables firewall will SNAT any connection from any of these > internal networks to the world. Correct? I think so, but please see below. > In answer to your question, I assume that your 192.168.101.0/24 network > and your 10.140.x.x networks are connected to the firewall on the same > ethernet medium. If this is so, then you and there is no missing detail, > your first impression was correct: > > You simply need to > > # ip addr add 10.140.227.245/$CIDR_MASK dev eth1 label eth1:0 FYI $CIDR_MASK=27 > > (or use the traditional redhat ifcfg-eth1:0 technique) > > and tell the internal machines that the default gateway is 10.140.227.245. > > What you are doing here is using the same ethernet for two separate IP > networks. Ok, but as I said in the diagram below my connection to the internet is on wan0 via iptables and NAT. Will not 2 default routes confuse things? In addition I only want traffic for 8 the following specific subnets routed down the 10.140.x.x pipe. They are 10.140.0.0/16, 10.141.0.0/16, 10.142.0.0/16, 151.193.141.0/24, 162.92.160.0/24. All other traffic should go out to the internet via wan0. Does this make sense? > > If I were in your position I would absolutely add another interface for > security and network segregation purposes, but, strictly speaking, you do > not need to do so. Network security issues are minimal because the 10.140.x.x is another private network not connected to the internet. I tend to agree with you though that it is most likely worth doing just to keep the traffic segerated. IMO it is a cleaner solution and since I already have a 3rd unused nic in the machine I will most likely configure it as you suggest. I am sorry for not describing this better to start with. I wish I was better at this kind of thing. > : Hi all, > : I have a strange setup I am trying to get working. Initally I thought > : I could set it up by just setting up the correct routes. However after > : thinking about it I have convinced myself (maybe incorrectly) that I > : most likely need some sort of advanced NAT/routing setup. > : > : Below is a description of the networks involved: > : > : Local net (192.168.101.0/24) > : | > : | > : Linux machine eth1 (192.168.101.5)---- eth1:0 (10.140.227.245) > : | > : Iptables NAT/firewall > : | > : Linux machine wan0 (This is a sangoma wanpipe with a routable ip address) > : | > : ISP > : > : The 10.140.227.224/27 network is a private network that knows nothing > : about the 192.168.101.0/24 network and is not controlled by us. > : Previously they were run as 2 seperate networks. What we are trying to > : do is to be able to install some custom software on the local net > : machines (the 192.168.101.0 net) and have 5 specific subnets send the > : traffic down the 10.140... net and the rest of the non 192.168.... > : traffic out the wan0 interface. Currently the 192.168... net and the > : 10.140..... net are on the same wire. I could split them and put > : another interface in the linux box if necessary. > : > : Is this possible? If so can someone point me in the right direction on how? > : Does this even make sense? If not please let me know and I will try to > : explain further. FWIW the linux box is a Red Hat 7.3 box with all of the latest > : updates. > : > : Regards, > : > : > > -- .............Tom "Nothing would please me more than being able to tdiehl@rogueind.com hire ten programmers and deluge the hobby market with good software." -- Bill Gates 1976 We are still waiting .... From GregScott@InfraSupportEtc.com Fri Sep 13 19:33:46 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Fri, 13 Sep 2002 13:33:46 -0500 Subject: [LARTC] Re: Routing/NAT question Message-ID: <365871C49598504A9481DDBEC3EB49555434@MAIL.InfraSupportEtc.com> Hi Tom - I just set up a similar situation - for traffic coming from one or more = subnets, route thru one path. For everyone else, route through a = different path. You need to choose a different default route, based on = the where packets come from, right? You will want to grab a copy of Alexy K's writeup on the new ip command = set. In the Red Hat distro, there's a postscript file in one of the = subdirectories someplace. I don't remember the exact path, but do a = find for all *.ps files and you'll see it. Print that .ps file on a = postscript printer and you'll see tons of details on syntax. Also take = a close look at the advanced routing howto. Here's how it works: There are a bunch of routing tables, including the main and default = tables. Unless a packet is somehow flagged, it will route according to = what these tables say. So your question - wouldn't things get really = confusing if you have more than one default route? - is absolutely = valid. =20 But - this is the cool part - you also have more than one table, (I = think up to 255 of them), and each table can have its own default route = and other routing info. So now the challenge is - how do you decide which table to use? That's = where fwmark comes in. You can set up iptables rules to match pretty = much anything relevant in a packet and apply a fwmark to it. This is = just some number that you make up. Later on, you put in a rule (the ip = rule command) that tells the kernel which table to use for each packet, = based on the contents of the fwmark. So if the fwmark is, say, 13, then = you would route according to the rules of, say, table number 13. = Otherwise, just use the default tables. (You can also edit a file to = give a name to table number 13 if you want.) And you can set up much = more complex scenarios using source address, TCP/UDP port, IP protocol = number, you name it. =20 It's always 3 steps - first an iptables rule in the mangle table that = associates some number with packets you care about, then an "ip rule" = command that associates packets with the fwmark numbers you assigned = earlier to the routing table you want. And, of course, make sure each = routing table is populated with the correct routes. (ip route add . . = .) Note that there is nothing special about the number 13, and the table = number doesn't have anything to do with value of the fwmark. I picked = 13 and used that number in both places only because today is Friday, = Sept. 13. =20 - Greg Scott -----Original Message----- From: Tom Diehl [mailto:tdiehl@rogueind.com] Sent: Friday, September 13, 2002 11:58 AM To: Martin A. Brown Cc: lartc@mailman.ds9a.nl Subject: [LARTC] Re: Routing/NAT question On Thu, 12 Sep 2002, Martin A. Brown wrote: Hi Martin, Thanks for responding. > I presume the iptables firewall will SNAT any connection from any of = these > internal networks to the world. Correct? I think so, but please see below. > In answer to your question, I assume that your 192.168.101.0/24 = network > and your 10.140.x.x networks are connected to the firewall on the same > ethernet medium. If this is so, then you and there is no missing = detail, > your first impression was correct: >=20 > You simply need to >=20 > # ip addr add 10.140.227.245/$CIDR_MASK dev eth1 label eth1:0 FYI $CIDR_MASK=3D27 >=20 > (or use the traditional redhat ifcfg-eth1:0 technique) >=20 > and tell the internal machines that the default gateway is = 10.140.227.245. >=20 > What you are doing here is using the same ethernet for two separate IP = > networks. Ok, but as I said in the diagram below my connection to the internet is = on wan0 via iptables and NAT. Will not 2 default routes confuse things? In = addition I only want traffic for 8 the following specific subnets routed down the = 10.140.x.x pipe. They are 10.140.0.0/16, 10.141.0.0/16, 10.142.0.0/16,=20 151.193.141.0/24, 162.92.160.0/24. All other traffic should go out to = the=20 internet via wan0.=20 Does this make sense? >=20 > If I were in your position I would absolutely add another interface = for=20 > security and network segregation purposes, but, strictly speaking, you = do=20 > not need to do so. Network security issues are minimal because the 10.140.x.x is another = private network not connected to the internet. I tend to agree with you though = that=20 it is most likely worth doing just to keep the traffic segerated. IMO it = is=20 a cleaner solution and since I already have a 3rd unused nic in the = machine I will most likely configure it as you suggest. I am sorry for not describing this better to start with. I wish I was = better at this kind of thing. > : Hi all, > : I have a strange setup I am trying to get working. Initally I = thought=20 > : I could set it up by just setting up the correct routes. However = after=20 > : thinking about it I have convinced myself (maybe incorrectly) that = I=20 > : most likely need some sort of advanced NAT/routing setup.=20 > :=20 > : Below is a description of the networks involved: > :=20 > : Local net (192.168.101.0/24) > : | > : | > : Linux machine eth1 (192.168.101.5)---- eth1:0 (10.140.227.245) > : | > : Iptables NAT/firewall > : | > : Linux machine wan0 (This is a sangoma wanpipe with a routable ip = address) > : | > : ISP > :=20 > : The 10.140.227.224/27 network is a private network that knows = nothing > : about the 192.168.101.0/24 network and is not controlled by us. > : Previously they were run as 2 seperate networks. What we are trying = to > : do is to be able to install some custom software on the local net > : machines (the 192.168.101.0 net) and have 5 specific subnets send = the > : traffic down the 10.140... net and the rest of the non 192.168.... > : traffic out the wan0 interface. Currently the 192.168... net and = the > : 10.140..... net are on the same wire. I could split them and put > : another interface in the linux box if necessary. > :=20 > : Is this possible? If so can someone point me in the right direction = on how? > : Does this even make sense? If not please let me know and I will try = to > : explain further. FWIW the linux box is a Red Hat 7.3 box with all = of the latest > : updates. > :=20 > : Regards, > :=20 > :=20 >=20 >=20 --=20 .............Tom "Nothing would please me more than being able to=20 tdiehl@rogueind.com hire ten programmers and deluge the hobby market=20 with good software." -- Bill Gates 1976 We are still waiting .... _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From lartc@24x7linux.com Fri Sep 13 21:14:36 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Fri, 13 Sep 2002 22:14:36 +0200 Subject: [LARTC] Re: Routing/NAT question In-Reply-To: <365871C49598504A9481DDBEC3EB49555434@MAIL.InfraSupportEtc.com> References: <365871C49598504A9481DDBEC3EB49555434@MAIL.InfraSupportEtc.com> Message-ID: <20020913201436.GB6599@localhost> On Friday, 13 September 2002, at 13:33:46 -0500, Greg Scott wrote: > Note that there is nothing special about the number 13, and the table number doesn't have anything to do with value of the fwmark. I picked 13 and used that number in both places only because today is Friday, Sept. 13. > You must be _very_ careful when dealing with "iptables" and "ip" for marking packets and routing them based on those marks. The numeric argument to: iptables -t mangle -A PREROUTING --jump MARK --set-mark 13 is a decimal number, BUT the argument to "ip" is an hexadecimal number, so to insert a matching "ip rule" you should do: ip rule add fwmark D pref 10000 table whatever NOT ip rule add fwmark 13 pref 10000 table whatever Hope it helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From osraza@yahoo.com Fri Sep 13 22:09:16 2002 From: osraza@yahoo.com (AOUN RAZA) Date: Fri, 13 Sep 2002 14:09:16 -0700 (PDT) Subject: [LARTC] Mgen6 Message-ID: <20020913210916.50156.qmail@web20605.mail.yahoo.com> Hello , i have prepared a mgen6 script and i want to check it with my local network .. but on receiver side it needs drec6 to run.. i tryed to make the command without script file ,, and log file.. which is not working error is : log file not found , even if i give the any file namr for log file... My question is how can i run drec6.. and where i will find log file .. and what is the function of log and script file for drec... plz some body reply soon... Regrds... Aoun Raza. ===== Syed Aoun Raza. Student MS(IT). Ph: +49-179-1833720 Stuttgart, Germany. __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From stef.coene@docum.org Fri Sep 13 22:16:50 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 13 Sep 2002 23:16:50 +0200 Subject: [LARTC] Mgen6 In-Reply-To: <20020913210916.50156.qmail@web20605.mail.yahoo.com> References: <20020913210916.50156.qmail@web20605.mail.yahoo.com> Message-ID: <200209132316.50860.stef.coene@docum.org> On Friday 13 September 2002 23:09, AOUN RAZA wrote: > Hello , > i have prepared a mgen6 script and i want to check it > with my local network .. but on receiver side it needs > drec6 to run.. i tryed to make the command without > script file ,, and log file.. > > which is not working error is : log file not found , > even if i give the any file namr for log file... > > My question is how can i run drec6.. and where i will > find log file .. and what is the function of log and > script file for drec... > > plz some body reply soon... What's mgen6 & drec6 ????? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mabrown-lartc@securepipe.com Fri Sep 13 23:04:28 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Fri, 13 Sep 2002 17:04:28 -0500 (CDT) Subject: [LARTC] Re: Routing/NAT question In-Reply-To: Message-ID: Tom, : FYI $CIDR_MASK=27 Right--got it. : > (or use the traditional redhat ifcfg-eth1:0 technique) : > : > and tell the internal machines that the default gateway is 10.140.227.245. : : Ok, but as I said in the diagram below my connection to the internet is : on wan0 via iptables and NAT. Will not 2 default routes confuse things? default gateway on the linux box - - - - - - - - - - - - - - - - - - I think you missed my drift--your linux box will have one default route to the T1 (wan0) peer endpoint or ISP access router. (Yes, Greg Scott is right when he mentions that linux supports multiple routing tables, but you do not need them for this scenario.) default gateway on internal machines - - - - - - - - - - - - - - - - - - Each of your internal machines which is locally connected to the same ethernet/IP network as the linux box will use the linux box as its default gateway. Machines in the 10.140.227.224/27 network will use 10.140.227.245 as a default gateway. Machines in 192.168.101.0/24 will use 192.168.101.5 as a default gateway. : In addition I only want traffic for 8 the following specific subnets : routed down the 10.140.x.x pipe. They are 10.140.0.0/16, 10.141.0.0/16, : 10.142.0.0/16, 151.193.141.0/24, 162.92.160.0/24. All other traffic : should go out to the internet via wan0. : Does this make sense? Sure....seems clear to me. You have a couple of internal networks behind a router on the locally connected 10.140.227.245/27 network. So, assuming that 10.140.227.254 is the gateway to your remote networks*: # route add -net 10.140.0.0 netmask 255.255.0.0 gw 10.140.227.254 # route add -net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 # route add -net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 # route add -net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 # route add -net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 And repeat as necessary up to your eight subnets. Really though, there's nothing LARTC about this setup--sure you are using Sangoma's (wonderful) T1 card, but you don't need any of the fancy routing tricks and tips usually discussed in this forum. -Martin * If I recall correctly, you are using RedHat...you can append the following lines to your /etc/sysconfig/static-routes file to have these routes added at network restart (boot): eth0 net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 eth0 net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 eth0 net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 eth0 net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 Of course, you should use the correct ethernet interface..... -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From GregScott@InfraSupportEtc.com Sat Sep 14 05:21:33 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Fri, 13 Sep 2002 23:21:33 -0500 Subject: [LARTC] Re: Routing/NAT question Message-ID: <365871C49598504A9481DDBEC3EB49555436@MAIL.InfraSupportEtc.com> woops (twice!) First, Jose, thank you for correcting my error with the fwmark stuff! > You must be _very_ careful when dealing with "iptables" and "ip" for > marking packets and routing them based on those marks. The numeric > argument to: > iptables -t mangle -A PREROUTING --jump MARK --set-mark 13 > > is a decimal number, BUT the argument to "ip" is an hexadecimal = number, > so to insert a matching "ip rule" you should do: > ip rule add fwmark D pref 10000 table whatever > > NOT > > ip rule add fwmark 13 pref 10000 table whatever Second, I went back and more carefully read Tom's question and Martin is right, I messed up again. In Tom's case, the Linux FW does not=20 need to make any special routing decisions - just assign the IP = Addresses to the Ethernet interface on the FW and have the systems in the various LANs behind the FW point to the appropriate gateway, as Martin = explained. - Greg -----Original Message----- From: Martin A. Brown [mailto:mabrown-lartc@securepipe.com] Sent: Friday, September 13, 2002 5:04 PM To: Tom Diehl Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] Re: Routing/NAT question Tom, : FYI $CIDR_MASK=3D27 Right--got it. : > (or use the traditional redhat ifcfg-eth1:0 technique) : >=20 : > and tell the internal machines that the default gateway is = 10.140.227.245. :=20 : Ok, but as I said in the diagram below my connection to the internet = is : on wan0 via iptables and NAT. Will not 2 default routes confuse = things? default gateway on the linux box - - - - - - - - - - - - - - - - - - I think you missed my drift--your linux box will have one default route = to=20 the T1 (wan0) peer endpoint or ISP access router. (Yes, Greg Scott is=20 right when he mentions that linux supports multiple routing tables, but=20 you do not need them for this scenario.) default gateway on internal machines - - - - - - - - - - - - - - - - - - Each of your internal machines which is locally connected to the same ethernet/IP network as the linux box will use the linux box as its = default gateway. Machines in the 10.140.227.224/27 network will use 10.140.227.245 as a default gateway. Machines in 192.168.101.0/24 will use 192.168.101.5 as a default gateway. : In addition I only want traffic for 8 the following specific subnets : routed down the 10.140.x.x pipe. They are 10.140.0.0/16, = 10.141.0.0/16, : 10.142.0.0/16, 151.193.141.0/24, 162.92.160.0/24. All other traffic : should go out to the internet via wan0. : Does this make sense? Sure....seems clear to me. You have a couple of internal networks=20 behind a router on the locally connected 10.140.227.245/27 network. =20 So, assuming that 10.140.227.254 is the gateway to your remote=20 networks*: # route add -net 10.140.0.0 netmask 255.255.0.0 gw 10.140.227.254 # route add -net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 # route add -net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 # route add -net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 # route add -net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 And repeat as necessary up to your eight subnets. Really though, there's nothing LARTC about this setup--sure you are = using Sangoma's (wonderful) T1 card, but you don't need any of the fancy = routing tricks and tips usually discussed in this forum. -Martin * If I recall correctly, you are using RedHat...you can append the following lines to your /etc/sysconfig/static-routes file to have = these routes added at network restart (boot): eth0 net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 eth0 net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 eth0 net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 =20 eth0 net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 Of course, you should use the correct ethernet interface..... --=20 Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From dealy@deatech.com Sat Sep 14 07:14:58 2002 From: dealy@deatech.com (Shannon C. Dealy) Date: Fri, 13 Sep 2002 23:14:58 -0700 (PDT) Subject: [LARTC] police/ingress limiting problem Message-ID: I setup the "Ultimate Traffic Conditioner" script on one of my 56k modem lines, and every time it effectively kills the link. The specific problem is the ingress filter/rate limiter lines (which was what I really wanted) tc qdisc add dev $DEV handle ffff: ingress tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \ 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1 After quite a bit of searching, I finally found another person posted this exact problem to the list a few months ago, but the answer they got was to try another approach. Before I spend time trying to figure out how to use that approach, I thought I would check if anything more has been discovered about this. Like the person who originally reported this, I am also running a 2.4.18 kernel, and as soon as I activate the filter (regardless of settings), the link is effectively dead until I remove the filter, presumably all incoming packets are being blocked. I have tried many variations, including setting the rate much higher than the link can provide (so presumably the limit will never be reached), and even switching from "drop" to "continue" or "pass", and even in these cases, all the data gets blocked. Unless I am misunderstanding something here, there would appear to be a serious bug somewhere in the kernel or tc command. Anyone know anything more about this? Has anyone gotten this to work with a 2.4.18 kernel? If not, what is the most recent kernel and tc command combination that does work? Thanks for any enlightenment you can provide. Shannon C. Dealy | DeaTech Research Inc. dealy@deatech.com | - Custom Software Development - | Embedded Systems, Real-time, Device Drivers Phone: (800) 467-5820 | Networking, Scientific & Engineering Applications or: (541) 451-5177 | www.deatech.com From curt@acm.org Sat Sep 14 07:56:07 2002 From: curt@acm.org (curt brune) Date: Fri, 13 Sep 2002 23:56:07 -0700 Subject: [LARTC] HTB questions Message-ID: <20020913235607.E3077@curtisb.com> Hello, I have a number of questions re: HTB * Traffic Simulator I saw the traffic simulator, ethloop -- very clever. I was wondering, however, how to simulate traffic destined for specific ports ? In the HBT HOWTO there are gnuplots of traffic destined for different ports. * Low rate shaping My maximum uplink is 384kbits/sec . I plan to shape HTTP,SMTP and other protos to some fraction of the maximum. Are there any special steps when shaping to these low rates ? I saw most of the examples are in the 5 to 10 mbit/sec range, roughly 30 times higher than what I plan to do. Cheers, Curt From stef.coene@docum.org Sat Sep 14 09:49:12 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 14 Sep 2002 10:49:12 +0200 Subject: [LARTC] HTB questions In-Reply-To: <20020913235607.E3077@curtisb.com> References: <20020913235607.E3077@curtisb.com> Message-ID: <200209141049.12494.stef.coene@docum.org> On Saturday 14 September 2002 08:56, curt brune wrote: > Hello, > > I have a number of questions re: HTB > > * Traffic Simulator > > I saw the traffic simulator, ethloop -- very clever. I was wondering, > however, how to simulate traffic destined for specific ports ? In the = HBT > HOWTO there are gnuplots of traffic destined for different ports. I never used ethloop myself, but I think it uses flowid's. So if you cre= ate a=20 htb setup with classes and filters, you can use the u32 filter to match=20 packets with different ports. Ethloop will generate the traffic in the=20 flowid's you configured it for. Or take a look at the P option : P Number. Priocode set by setsockopt(sock,SOL_SOCKET,SO_PRIORITY,...). It= is=20 very convenient way to test qdisc because majority of classfull qdisc wil= l=20 use classid stored in priority field. To say that this flow should go to=20 class 3:4f use P 0x3004f. This way you need no filters. > * Low rate shaping > > My maximum uplink is 384kbits/sec . I plan to shape HTTP,SMTP and othe= r > protos to some fraction of the maximum. Are there any special steps wh= en > shaping to these low rates ? I saw most of the examples are in the 5 t= o 10 > mbit/sec range, roughly 30 times higher than what I plan to do. If you have class with very different rates, it's possible you can get=20 warnings about quantum. You can ignore them, but it's better fix it. To= be=20 short, quantum =3D rate / r2q with r2q =3D 10 by default. =20 And MTU (1500) < quantum < 60.000. Quantum is the number of bytes a class my send IF 2 or more classes are=20 fighting for bandwidth from the same parent. You can overrule r2q when y= ou=20 add the htb qdisc and/or you can overrule quantum when you add a htb clas= s. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From eric@regit.org Sat Sep 14 13:14:18 2002 From: eric@regit.org (Eric Leblond) Date: 14 Sep 2002 14:14:18 +0200 Subject: [LARTC] iptable for multiple ip address In-Reply-To: <20020912194914.GA3566@localhost> References: <001701c25a61$5053ec40$7c010a0a@nsicomm.com> <20020912145403.GA5690@creaciondeweb.com> <20020912194914.GA3566@localhost> Message-ID: <1032005658.14050.1.camel@porky> Le jeu 12/09/2002 =E0 21:49, Jose Luis Domingo Lopez a =E9crit : =20 > iptables -t nat -A POSTROUTING --out-interface $WAN_IF \ > --jump SNAT --to-source $START_PUB_IP-$END_PUB_IP >=20 > The only limitation I see with this approach is that IP addresses must > be contiguous, but I think this is a typical scenario, because our ISP > tend to give addresses in blocks :) But you can put multiple --to-source so there's no limitation. -- Eric Leblond eric@regit.org From devik@cdi.cz Sun Sep 15 09:37:19 2002 From: devik@cdi.cz (devik) Date: Sun, 15 Sep 2002 10:37:19 +0200 (CEST) Subject: [LARTC] Re: HTB questions In-Reply-To: <20020913235607.E3077@curtisb.com> Message-ID: > * Traffic Simulator > > I saw the traffic simulator, ethloop -- very clever. I was wondering, > however, how to simulate traffic destined for specific ports ? In the > HBT HOWTO there are gnuplots of traffic destined for different ports. The simulator is used to test queuing part of qdisc. The ports in plot was added by myself to make more complete picture. ethloop didn't create "regular" ip packets co that you can't use it to test filters. > * Low rate shaping > > My maximum uplink is 384kbits/sec . I plan to shape HTTP,SMTP and > other protos to some fraction of the maximum. Are there any special > steps when shaping to these low rates ? I saw most of the examples > are in the 5 to 10 mbit/sec range, roughly 30 times higher than what I > plan to do. no problem. I use it for rates of 1kbps. The fast rates used in examples was to demonstrate ability to operate on high speeds. devik From curt@acm.org Sun Sep 15 19:03:11 2002 From: curt@acm.org (curt brune) Date: Sun, 15 Sep 2002 11:03:11 -0700 Subject: [LARTC] marking packets vs. tc filter Message-ID: <20020915110311.A1413@curtisb.com> Using tc filter is there a way to direct a range of ports (say ports 5000 to 5100) to a particular flowid ? I am aware I can use iptables to mark packets and that iptables has a syntax for port ranges -- so I could us this method. Theoretical question: Has anyone done an experiment to test wether filtering with "tc" or "iptables" is more performant? I.e. given two ways to solve the problem which way is better, tc filter or iptables w/ marking? Cheers, Curt From wa@almesberger.net Sun Sep 15 19:50:11 2002 From: wa@almesberger.net (Werner Almesberger) Date: Sun, 15 Sep 2002 15:50:11 -0300 Subject: [LARTC] marking packets vs. tc filter In-Reply-To: <20020915110311.A1413@curtisb.com>; from curt@acm.org on Sun, Sep 15, 2002 at 11:03:11AM -0700 References: <20020915110311.A1413@curtisb.com> Message-ID: <20020915155011.K1781@almesberger.net> curt brune wrote: > Using tc filter is there a way to direct a range of ports (say ports 5000 > to 5100) to a particular flowid ? You can translate relational operators (<, >=, etc.) into individual tests of bits or prefixes, which can then be used by u32. For the algorithms, see tcng's tcng/tcc/iflib_arith.c:rel_general and the functions it calls. If using tcc to generate such classifiers, you can speed up configuration-time processing considerably with -Oprefix -Onocse > Theoretical question: Has anyone done an experiment to test wether > filtering with "tc" or "iptables" is more performant? In this case, iptables should win hands down, because it uses CPU instructions that accomplish the task much more directly. I don't know how iptables and tc compare in cases where the actual classifications have similar cost. If somebody's going to run some comparisons, the results may be interesting, though. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From mage@adamant.net Mon Sep 16 10:06:17 2002 From: mage@adamant.net (Alexander Trotsai) Date: Mon, 16 Sep 2002 12:06:17 +0300 Subject: [LARTC] error in htb or I don't understand something Message-ID: <20020916090617.GP1710@blackhole.adamant.ua> Hi I'm use htb and as I think if I don't setup default class, all other (not classified) traffic must going throw 0 class without any shaping But when I try to make such config all other traffic doesn't transmiting. I have some clients on vlan connected with modem (routing, not bridging) So modem has own addresses I try shape clients not modems If no default - no ping to modems And when I setup default class I got pings htb I use from kernel tree (I'm use 2.4.20-pre5) -- Best regard, Alexander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP at ftp://blackhole.adamant.net/pgp/trotsai.key[.asc] Big trouble - the butane lighter causes the pincushioning From landreani@seltatel.it Mon Sep 16 10:49:28 2002 From: landreani@seltatel.it (Andreani Luca) Date: Mon, 16 Sep 2002 11:49:28 +0200 Subject: [LARTC] Voip and Qos tests Message-ID: <6812F61B83A6D411BF250060B01B7BAC4A6F67@SELTATOR> Hello list, I'm performing some tests in order to evaluate the possibility to make Voip calls on a busy network. I use some cisco routers with wfq enabled. I want to introduce some linux boxes acting as routers. I am especially interested in low-speed (64-128 kbps) links with PPP and frame-relay. Haw you some reference about similar tests? Whath qdisc (from tc) has best performance in these situations? Thank's Luca From Eicher Rene" Hi I wanna run a web-service and tried to connect from the internet. One connection works. (default gateway). The other connections does not find the way back to his incomming device. Does somebody now wrere I can get information for the solution? Thank you for any links and hints... Rene isp1 isp2 eth0 eth1 | | Router Router | | --------------------------- | RH7.2/iptables | --------------------------- | eth2 | Hub/Switch | ---------------------------------------- | | | | www backup dns usw Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.0.0.0 * 255.255.255.0 U 2 0 0 eth0 80.0.0.0 * 255.255.255.0 U 1 0 0 eth1 192.168.1.0 * 255.255.255.0 U 0 0 0 eth2 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 62.0.0.1 0.0.0.0 UG 1 0 0 eth1 default 80.0.0.1 0.0.0.0 UG 2 0 0 eth0 From tdiehl@rogueind.com Mon Sep 16 17:35:19 2002 From: tdiehl@rogueind.com (Tom Diehl) Date: Mon, 16 Sep 2002 12:35:19 -0400 (EDT) Subject: [LARTC] Re: Routing/NAT question In-Reply-To: Message-ID: On Fri, 13 Sep 2002, Martin A. Brown wrote: Hi Martin, First I want to apologize for my inability to explain this correctly. I feel pretty stupid right now. I will try again. > : > (or use the traditional redhat ifcfg-eth1:0 technique) > : > > : > and tell the internal machines that the default gateway is 10.140.227.245. > : > : OK, but as I said in the diagram below my connection to the internet is > : on wan0 via iptables and NAT. Will not 2 default routes confuse things? > > default gateway on the linux box > - - - - - - - - - - - - - - - - - - > I think you missed my drift--your linux box will have one default route to > the T1 (wan0) peer endpoint or ISP access router. (Yes, Greg Scott is > right when he mentions that linux supports multiple routing tables, but > you do not need them for this scenario.) > > default gateway on internal machines > - - - - - - - - - - - - - - - - - - > Each of your internal machines which is locally connected to the same > ethernet/IP network as the linux box will use the linux box as its default > gateway. Machines in the 10.140.227.224/27 network will use > 10.140.227.245 as a default gateway. Machines in 192.168.101.0/24 will > use 192.168.101.5 as a default gateway. OK, I understand this but I want the 192.168.101.0/24 machines to be able to talk to the 10.140.227.224/27 network also but only for the subnets listed below. All other traffic goes out the default route to the internet (wan0). I am trying to eliminate the 2nd pc on some desks and to do that the machines on the 192.168.* net must be able to talk to the 10.* net. > > : In addition I only want traffic for 8 the following specific subnets > : routed down the 10.140.x.x pipe. They are 10.140.0.0/16, 10.141.0.0/16, > : 10.142.0.0/16, 151.193.141.0/24, 162.92.160.0/24. All other traffic > : should go out to the internet via wan0. > : Does this make sense? > > Sure....seems clear to me. You have a couple of internal networks > behind a router on the locally connected 10.140.227.245/27 network. > So, assuming that 10.140.227.254 is the gateway to your remote > networks*: > > # route add -net 10.140.0.0 netmask 255.255.0.0 gw 10.140.227.254 > # route add -net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 > # route add -net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 > # route add -net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 > # route add -net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 > > And repeat as necessary up to your eight subnets. > > Really though, there's nothing LARTC about this setup--sure you are using > Sangoma's (wonderful) T1 card, but you don't need any of the fancy routing > tricks and tips usually discussed in this forum. I really love the wanpipe cards. We bought and deployed almost a dozen of them. As far as the fancy tricks discussed here I think I really do need them but I am just not good at explaining what I am trying to do. Sorry. :-( > > * If I recall correctly, you are using RedHat...you can append the > following lines to your /etc/sysconfig/static-routes file to have these > routes added at network restart (boot): > > eth0 net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 > eth0 net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 > eth0 net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 > eth0 net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 > > Of course, you should use the correct ethernet interface..... Understood. Thanks for the help everyone. I am not ready to give up yet. Your patience is appreciated. -- .............Tom "Nothing would please me more than being able to tdiehl@rogueind.com hire ten programmers and deluge the hobby market with good software." -- Bill Gates 1976 We are still waiting .... From anirban_tech@yahoo.com Mon Sep 16 18:00:15 2002 From: anirban_tech@yahoo.com (Anirban Chakraborti) Date: Mon, 16 Sep 2002 10:00:15 -0700 (PDT) Subject: [LARTC] Multicasting routing in SUSE Message-ID: <20020916170015.87479.qmail@web12801.mail.yahoo.com> --0-383557225-1032195615=:86442 Content-Type: text/plain; charset=us-ascii hi all, This is my first message to the group.My name is Anirban Chakraborti and I am with new mexico state university. I have recently built a router using suse linux.I need to turn on IGMP and PIM to allow it do multicasting.How to do that? Secondly I also want to control the rate of the datatransfer from the router's ethernet interface to the ppp interface. Thanks for the help, Anirban --------------------------------- Do you Yahoo!? Yahoo! News - Today's headlines --0-383557225-1032195615=:86442 Content-Type: text/html; charset=us-ascii

hi all,

        This is my first message to the group.My name is Anirban Chakraborti and I am with new mexico state university.

I have recently built a  router using suse linux.I need to turn on IGMP and PIM to allow it do multicasting.How to do that? Secondly I also want to control the rate of the datatransfer from the router's ethernet interface to the ppp interface.

Thanks for the help,

Anirban


Do you Yahoo!?
Yahoo! News - Today's headlines --0-383557225-1032195615=:86442-- From lartc@24x7linux.com Mon Sep 16 18:49:32 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Mon, 16 Sep 2002 19:49:32 +0200 Subject: [LARTC] Multicasting routing in SUSE In-Reply-To: <20020916170015.87479.qmail@web12801.mail.yahoo.com> References: <20020916170015.87479.qmail@web12801.mail.yahoo.com> Message-ID: <20020916174932.GA3133@localhost> On Monday, 16 September 2002, at 10:00:15 -0700, Anirban Chakraborti wrote: > I have recently built a router using suse linux.I need to turn on IGMP and PIM to allow it do multicasting.How to do that? Secondly I also want to control the rate of the datatransfer from the router's ethernet interface to the ppp interface. > To enable multicast support and multicast routing, you _maybe_ will need to recompile your kernel, but I would say that any recent SuSE distribution probably have the already compiled on. Just check boot messages (execute dmesg o see /var/log/*). If you need to recompile the kernel, go to and select: Networking options ---> [*] TCP/IP networking ---> [*] IP: multicasting ---> [*] IP: multicast routing [*] IP: PIM-SM version 1 support (NEW) [*] IP: PIM-SM version 2 support (NEW) And the recompile as usual. To limit traffic, even if it is multicast, check the HOWTO, list archives and scripts at lartc.org. Hope this helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From GregScott@InfraSupportEtc.com Tue Sep 17 00:48:10 2002 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Mon, 16 Sep 2002 18:48:10 -0500 Subject: [LARTC] Re: Routing/NAT question Message-ID: <365871C49598504A9481DDBEC3EB4955543F@MAIL.InfraSupportEtc.com> > but I want the 192.168.101.0/24 machines to be able to=20 > talk to the 10.140.227.224/27 network also but only for the subnets = listed=20 > below.=20 OK...here I go again, I'll give this another shot. =20 So you want your 10.xxx networks to communicate with your 192.168.xxx=20 networks, right? Both are behind a Linux FW. The 10.xx network uses a gateway IP also of 10.xx. The 192.168.xxx network uses a gateway IP in the 192.168.xxx range. Both of these gateway IP address could be=20 NICs inside the same firewall - they might even be aliases of the same NIC but they really should be different NICs. If this is true, then . . . You still don't have a problem. Remember that a firewall is really a router with a bunch of rules to=20 decide whether or not to forward packets. The classic firewall=20 installation routes between a single internal network and the Internet so the routing part is pretty simple. But this is really no different=20 than routing among two or several internal networks and the Internet. =20 Simply assign the appropriate gateway IP address to each system in the=20 various networks, put in a bunch of packet filtering rules in your=20 firewall, and turn on IP forwarding. It will "know" to send traffic between the 10.xx guys and the 192.168.xxx guys because it will be a=20 member of both networks. fwiw, I have a customer right now with 4 NICs and 4 separate internal=20 networks. We can argue about whether or not this is a good idea, but all 4 internal networks can see all the other internal networks just fine. No special routes, no LARTC stuff, nothing fancy. Now, let's say you want to restrict one of those networks from getting out to the Internet - no problem, you can do that with just a couple of rules. Put in rules in your FORWARD table that ACCEPT packets from the networks you want, then put in a DROP rule after that. (Or just make=20 DROP your policy and then you don't need a DROP rule.) Did I get it right this time? - Greg Scott -----Original Message----- From: Tom Diehl [mailto:tdiehl@rogueind.com] Sent: Monday, September 16, 2002 11:35 AM To: Martin A. Brown Cc: lartc@mailman.ds9a.nl Subject: [LARTC] Re: Routing/NAT question On Fri, 13 Sep 2002, Martin A. Brown wrote: Hi Martin, First I want to apologize for my inability to explain this correctly. I = feel=20 pretty stupid right now. I will try again. > : > (or use the traditional redhat ifcfg-eth1:0 technique) > : >=20 > : > and tell the internal machines that the default gateway is = 10.140.227.245. > :=20 > : OK, but as I said in the diagram below my connection to the = internet is > : on wan0 via iptables and NAT. Will not 2 default routes confuse = things? >=20 > default gateway on the linux box > - - - - - - - - - - - - - - - - - - > I think you missed my drift--your linux box will have one default = route to=20 > the T1 (wan0) peer endpoint or ISP access router. (Yes, Greg Scott is = > right when he mentions that linux supports multiple routing tables, = but=20 > you do not need them for this scenario.) >=20 > default gateway on internal machines > - - - - - - - - - - - - - - - - - - > Each of your internal machines which is locally connected to the same > ethernet/IP network as the linux box will use the linux box as its = default > gateway. Machines in the 10.140.227.224/27 network will use > 10.140.227.245 as a default gateway. Machines in 192.168.101.0/24 = will > use 192.168.101.5 as a default gateway. OK, I understand this but I want the 192.168.101.0/24 machines to be = able to=20 talk to the 10.140.227.224/27 network also but only for the subnets = listed=20 below. All other traffic goes out the default route to the internet = (wan0). I am trying to eliminate the 2nd pc on some desks and to do that=20 the machines on the 192.168.* net must be able to talk to the 10.* net. >=20 > : In addition I only want traffic for 8 the following specific = subnets > : routed down the 10.140.x.x pipe. They are 10.140.0.0/16, = 10.141.0.0/16, > : 10.142.0.0/16, 151.193.141.0/24, 162.92.160.0/24. All other traffic > : should go out to the internet via wan0. > : Does this make sense? >=20 > Sure....seems clear to me. You have a couple of internal networks=20 > behind a router on the locally connected 10.140.227.245/27 network. =20 > So, assuming that 10.140.227.254 is the gateway to your remote=20 > networks*: >=20 > # route add -net 10.140.0.0 netmask 255.255.0.0 gw 10.140.227.254 > # route add -net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 > # route add -net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 > # route add -net 151.193.141.0 netmask 255.255.255.0 gw = 10.140.227.254 > # route add -net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 >=20 > And repeat as necessary up to your eight subnets. >=20 > Really though, there's nothing LARTC about this setup--sure you are = using > Sangoma's (wonderful) T1 card, but you don't need any of the fancy = routing > tricks and tips usually discussed in this forum. I really love the wanpipe cards. We bought and deployed almost a dozen = of them. As far as the fancy tricks discussed here I think I really do need them = but I am just not good at explaining what I am trying to do. Sorry. :-( >=20 > * If I recall correctly, you are using RedHat...you can append the > following lines to your /etc/sysconfig/static-routes file to have = these > routes added at network restart (boot): >=20 > eth0 net 10.141.0.0 netmask 255.255.0.0 gw 10.140.227.254 > eth0 net 10.142.0.0 netmask 255.255.0.0 gw 10.140.227.254 > eth0 net 151.193.141.0 netmask 255.255.255.0 gw 10.140.227.254 =20 > eth0 net 162.92.160.0 netmask 255.255.255.0 gw 10.140.227.254 >=20 > Of course, you should use the correct ethernet interface..... Understood. Thanks for the help everyone. I am not ready to give up yet. Your = patience is appreciated. --=20 .............Tom "Nothing would please me more than being able to=20 tdiehl@rogueind.com hire ten programmers and deluge the hobby market=20 with good software." -- Bill Gates 1976 We are still waiting .... _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From leoball@opalsoft.net Tue Sep 17 01:56:12 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Mon, 16 Sep 2002 20:56:12 -0400 Subject: [LARTC] DS examples misunderstood Message-ID: <5.1.0.14.1.20020916205228.00a3ac90@opalsoft.net> Hi everyone: Could anyone help me to clear some misunderstood with DS examples in iproute2 distribution? In Edge31-ca-u32 we have these sentences --------------------------: tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 4 handle 1: u32 \ divisor 1 tc filter add dev eth0 parent ffff: protocol ip prio 4 u32 \ match ip tos 0x88 0xfc \ police index 1 rate 1500kbit burst 90k \ continue flowid :1 In Edge32-ca-u32 also we have --------------------------------------: tc qdisc add dev eth2 handle ffff: ingress tc filter add dev eth2 parent ffff: protocol ip prio 1 u32 \ match ip tos 0x88 0xfc \ police index 1 rate 1000kbit burst 90k \ continue flowid :1 tc filter add dev eth2 parent ffff: protocol ip prio 2 u32 \ match ip tos 0x88 0xfc \ police index 2 rate 1000kbit burst 30k \ continue flowid :1 ------------------------------------------------------------------------- I have 2 questions: 1. Why next sentence (below) is only present in Edge31-ca-u32 and not in Edge32-ca-u32? What's the meaning or reason of this command and what in fact it does? tc filter add dev eth0 parent ffff: protocol ip prio 4 handle 1: u32 \ divisor 1 2. I don't understand the expresion "police index 1" or "police index 2" above. Are those just simple way of numbering polices? Also this command: tc filter add dev eth2 parent ffff: protocol ip prio 2 u32 \ match ip tos 0x88 0xfc \ police index 2 rate 1000kbit burst 30k continue flowid :1 Combines "police index 2" with "flowid :1" and I thought (perhaps erroneusly) that "flowid :1" corresponded to "tcindex 1" but now I'm really confused. Are "police index n" and "tc index n" different things? What are the different meaning of those expressions in the examples? What the relationship is between "flowid :1 or :2", "tc index 1 or 2" and "police index 1 or 2"? Hoping any help. Best regards. Leonardo Balliache From snuffy2@yahoo.com Tue Sep 17 04:31:26 2002 From: snuffy2@yahoo.com (Justin Morea) Date: Mon, 16 Sep 2002 20:31:26 -0700 (PDT) Subject: [LARTC] Bridging & Shaping (Wondershaper) Message-ID: <20020917033126.88117.qmail@web9503.mail.yahoo.com> I am rather new to all of this and I've got a few questions. I have an ADSL connection with 5 static IPs. Currently the DSL modem is connected directly to a switch, and all the computers to this switch. I would like to place a Linux box inbetween the modem & the switch in order to do some traffic shaping. If I understand what I've read so far, I need to place the 2 newtork cards in a bridged mode correct? This should be transparent to the users correct? In bridged mode, what are my options for shaping? Can I just use the normal shaping tools/commands described in LARTC.org? Can I user WonderShaper? Thanx Snuffy2 __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From stef.coene@docum.org Tue Sep 17 08:13:59 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 09:13:59 +0200 Subject: [LARTC] Bridging & Shaping (Wondershaper) In-Reply-To: <20020917033126.88117.qmail@web9503.mail.yahoo.com> References: <20020917033126.88117.qmail@web9503.mail.yahoo.com> Message-ID: <200209170913.59339.stef.coene@docum.org> On Tuesday 17 September 2002 05:31, Justin Morea wrote: > I am rather new to all of this and I've got a few > questions. > > I have an ADSL connection with 5 static IPs. > > Currently the DSL modem is connected directly to a > switch, and all the computers to this switch. > > I would like to place a Linux box inbetween the modem > & the switch in order to do some traffic shaping. > > If I understand what I've read so far, I need to place > the 2 newtork cards in a bridged mode correct? This > should be transparent to the users correct? > > In bridged mode, what are my options for shaping? Can > I just use the normal shaping tools/commands described > in LARTC.org? Can I user WonderShaper? Yes you can. However, iptables will not work on a bridge. So you have t= o use=20 the u32 filter (there is a patch to get iptables working on a bridge). If you shape on a bridge, you can shape on both interfaces, so you don't = need=20 the ingress capabilities of the wondershaper. However, you introduce an=20 extra NIC in the data path, so you also introduce extra (small) delays. = One=20 of the benefits of ingress shaping, is that it does not introduce extra=20 delays, but it's not so powerfull as egress shaping. Or you can replace the switch with a linux box with some quad-NIC's. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From hanhbnetfilter@yahoo.com.cn Tue Sep 17 08:53:09 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Tue, 17 Sep 2002 15:53:09 +0800 (CST) Subject: [LARTC] the range of HTB's prio Message-ID: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> HTB and imq was used to control traffic. AC="tc class add dev eth0 parent" $AC 1: classid 1:1 htb rate 100kbps burst 2k $AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps burst 2k prio 1 $AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps burst 2k prio 1 please tell me the range of "prio" _________________________________________________________ Do You Yahoo!? ÂÏʵ½µ×,ÓéÀÖµ½ĵÒ - ÑĊğ˘ÍĈ³öâ·ÑÓéÀÖµç×ÓÖÜħ¨! http://cn.ent.yahoo.com/newsletter/index.html From ciprian@promo.ro Tue Sep 17 09:29:58 2002 From: ciprian@promo.ro (Ciprian Niculescu) Date: Tue, 17 Sep 2002 11:29:58 +0300 Subject: [LARTC] iptables -m limit Message-ID: <3D86E806.2000005@promo.ro> hy, i want a iptables rule to match if a designated trafic is above x bps or pps, i try iptm="/usr/local/sbin/iptables -t mangle" $iptm -A PREROUTING -i eth0 -m limit --limit 10000/sec $iptm -A PREROUTING -i eth0 -m limit ! --limit 10000/sec the results are: 62992 16M all -- eth0 * 0.0.0.0/0 0.0.0.0/0 limit: avg 10000/sec burst 5 62993 16M all -- eth0 * 0.0.0.0/0 0.0.0.0/0 limit: avg 10000/sec burst 5 why the ! argument dont work???? and is accepted C From eric@regit.org Tue Sep 17 10:27:57 2002 From: eric@regit.org (Eric Leblond) Date: 17 Sep 2002 11:27:57 +0200 Subject: [LARTC] iptables -m limit In-Reply-To: <3D86E806.2000005@promo.ro> References: <3D86E806.2000005@promo.ro> Message-ID: <1032254877.11270.50.camel@tech004> --=-6seZvTekXltvit1j8EE0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 2002-09-17 at 10:29, Ciprian Niculescu wrote: > hy, >=20 > i want a iptables rule to match if a designated trafic is above x bps or=20 > pps, i try >=20 > iptm=3D"/usr/local/sbin/iptables -t mangle" > $iptm -A PREROUTING -i eth0 -m limit --limit 10000/sec > $iptm -A PREROUTING -i eth0 -m limit ! --limit 10000/sec you don't have to use the ! if you go to the second rules, this is because you don't have match the first one, so you are over the limit. So you can do : $iptm -A PREROUTING -i eth0 -m limit --limit 10000/sec -j MYTARGET iptm -A PREROUTING -i eth0 -j MYTARGET --=20 =C9ric Leblond courriel : eric@regit.org --=-6seZvTekXltvit1j8EE0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9hvWdnxA7CdMWjzIRAsh0AJ4yjskTnDrmvR2+HLCEHD7MNwmVQgCeMuqD uAvP3fMr5+nVkHt8PHQMFtI= =pQQ/ -----END PGP SIGNATURE----- --=-6seZvTekXltvit1j8EE0-- From nikky@mnet.bg Tue Sep 17 10:50:13 2002 From: nikky@mnet.bg (Nickola Kolev) Date: Tue, 17 Sep 2002 12:50:13 +0300 Subject: [LARTC] the range of HTB's prio In-Reply-To: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> References: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> Message-ID: <20020917125013.5baa3d3f.nikky@mnet.bg> > HTB and imq was used to control traffic. > AC="tc class add dev eth0 parent" > $AC 1: classid 1:1 htb rate 100kbps burst 2k > $AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps > burst 2k prio 1 > $AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps > burst 2k prio 1 > > please tell me the range of "prio" 1 to 8, 1 being the highest, 8 - the lowest. From robert.penz@outertech.com Tue Sep 17 11:00:17 2002 From: robert.penz@outertech.com (Robert Penz) Date: Tue, 17 Sep 2002 12:00:17 +0200 Subject: [LARTC] the range of HTB's prio In-Reply-To: <20020917125013.5baa3d3f.nikky@mnet.bg> References: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> <20020917125013.5baa3d3f.nikky@mnet.bg> Message-ID: <200209171200.20249.robert.penz@outertech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 17 September 2002 11:50, Nickola Kolev wrote: > > please tell me the range of "prio" > 1 to 8, 1 being the highest, 8 - the lowest. 0 is highest as I know ...=20 but I've also an question: is there if difference if I have 2 chains and use prio 0 and 7 or prio 0 = and 1=20 ? - --=20 Regards, Robert - ---------------- Robert Penz robert.penz@outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9hv008tTsQqJDUBMRAuJIAJ90P6MUqvNw2V1sm9qLtPtncGXBnQCeNVFT 9DbmTUzKwv0/eMwgdg2n/lo=3D =3DKhJa -----END PGP SIGNATURE----- From raptor@tvskat.net Tue Sep 17 20:52:27 2002 From: raptor@tvskat.net (raptor) Date: Tue, 17 Sep 2002 15:52:27 -0400 Subject: [LARTC] [htb3] patch errors on 2.4.19mdk Message-ID: <20020917155227.0d132c37.raptor@tvskat.net> When I apply HTB3 paches to 2.4.19 (mandrake kernel) I get this : (NO to all questions) ---------------------------------------------------------------------------- [root@qos test]# patch -p1 -b References: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> Message-ID: <36510.212.2.37.233.1032267475.squirrel@kaeptnb.d2g.com> HTB Prios are 0-6 by default (htb 3.6), but afaik u can increase this number at compile-time. btw: is it true that you're a "Spamware site or vendor"? at least my Spam-Assasin (which consults 2 rbl-hosts...) declares you as such... > SPAM: -------------------- Start SpamAssassin results > ---------------------- SPAM: This mail is probably spam. The original > message has been altered SPAM: so you can recognise or block similar > unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more > details. > SPAM: > SPAM: Content analysis details: (9.5 hits, 5 required) > SPAM: Hit! (2.0 points) Forged yahoo.com 'Received:' header found SPAM: > Hit! (2.0 points) Received via a relay in relays.osirusoft.com SPAM: > [RBL check: found 202.41.99.202.relays.osirusoft.com., > type: 127.0.0.6] SPAM: Hit! (0.5 points) Received via a relay in > ipwhois.rfc-ignorant.org SPAM: [RBL check: found > 141.128.135.61.ipwhois.rfc-ignorant.org., type: 127.0.0.6] SPAM: Hit! > (5.0 points) DNSBL: sender is a Spamware site or vendor SPAM: > SPAM: -------------------- End of SpamAssassin results > --------------------- > > HTB and imq was used to control traffic. > AC="tc class add dev eth0 parent" > $AC 1: classid 1:1 htb rate 100kbps burst 2k > $AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps > burst 2k prio 1 > $AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps > burst 2k prio 1 > > please tell me the range of "prio" > > > > > _________________________________________________________ > Do You Yahoo!? > ÂÏʵ½µ×,ÓéÀÖµ½ĵÒ - ÑĊğ˘ÍĈ³öâ·ÑÓéÀÖµç×ÓÖÜħ¨! > http://cn.ent.yahoo.com/newsletter/index.html > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From m.c.p@gmx.net Tue Sep 17 14:02:58 2002 From: m.c.p@gmx.net (Marc-Christian Petersen) Date: Tue, 17 Sep 2002 15:02:58 +0200 Subject: [LARTC] [htb3] patch errors on 2.4.19mdk In-Reply-To: <20020917155227.0d132c37.raptor@tvskat.net> References: <20020917155227.0d132c37.raptor@tvskat.net> Message-ID: <200209171502.58689.m.c.p@gmx.net> On Tuesday 17 September 2002 21:52, raptor wrote: Hi Raptor, > When I apply HTB3 paches to 2.4.19 (mandrake kernel) I get this : > (NO to all questions) > -----------------------------------------------------------------------= ---- >- [root@qos test]# patch -p1 -b patching file net/sched/Config.in > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file net/sched/Config.in.r= ej > patching file net/sched/Makefile > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file net/sched/Makefile.re= j > patching file net/sched/sch_htb.c > patching file include/linux/pkt_sched.h > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file > include/linux/pkt_sched.h.rej patching file net/sched/sch_api.c > Hunk #1 FAILED at 1117. > Hunk #2 succeeded at 1205 with fuzz 2. > 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.r= ej > patching file lib/Makefile > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file lib/Makefile.rej > patching file lib/rbtree.c > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 3 out of 3 hunks ignored -- saving rejects to file lib/rbtree.c.rej > patching file include/net/pkt_sched.h > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file > include/net/pkt_sched.h.rej > -----------------------------------------------------------------------= ---- hmm, maybe htb is already in the mdk kernel? anyway, you should patch with "patch -p1 --dry-run < patchname" FIRST, be= fore=20 applying and see if it succeed. --=20 Kind regards Marc-Christian Petersen http://sourceforge.net/projects/wolk PGP/GnuPG Key: 1024D/569DE2E3DB441A16 Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16 Key available at www.keyserver.net. Encrypted e-mail preferred. From raptor@tvskat.net Tue Sep 17 21:54:43 2002 From: raptor@tvskat.net (raptor) Date: Tue, 17 Sep 2002 16:54:43 -0400 Subject: [LARTC] [htb3] patch errors on 2.4.19mdk In-Reply-To: <200209171502.58689.m.c.p@gmx.net> References: <20020917155227.0d132c37.raptor@tvskat.net> <200209171502.58689.m.c.p@gmx.net> Message-ID: <20020917165443.21fa6d09.raptor@tvskat.net> |hmm, maybe htb is already in the mdk kernel? | |anyway, you should patch with "patch -p1 --dry-run < patchname" FIRST, before |applying and see if it succeed. ]- yep it is in, but i'm not sure is it the latest ?? is there a way I can check this ... "Dry run", hu :") didn't knew it From raptor@tvskat.net Tue Sep 17 22:06:26 2002 From: raptor@tvskat.net (raptor) Date: Tue, 17 Sep 2002 17:06:26 -0400 Subject: [LARTC] Cont'd [htb3] patch errors on 2.4.19mdk In-Reply-To: <20020917155227.0d132c37.raptor@tvskat.net> References: <20020917155227.0d132c37.raptor@tvskat.net> Message-ID: <20020917170626.6591e559.raptor@tvskat.net> Now i applied it again this time answering yes, the only .rej file I got is this : is it fatal !? ------------------------------------ [root@qos sched]# cat *rej *************** *** 1117,1123 **** psched_timer.expires = jiffies + 1*HZ; #else unsigned long now = jiffies; - psched_time_base = ((u64)now)< Hi, how could I achieve a simulation of Bandwidth _and_ Latency? In detail, I need to simulate the characteristics of ISDN and DSL on a simple Ethernet-Connection: ISDN 64 Kbit/s und 10 ms latency DSL 128 Kbit/s und 50 ms latency I would use HTB for the limitation of the Bandwidth, but how am I able to increase the latency? Thank you in advance, Hannes From Nils.Lichtenfeld@gmx.net Tue Sep 17 15:40:32 2002 From: Nils.Lichtenfeld@gmx.net (Nils Lichtenfeld) Date: Tue, 17 Sep 2002 16:40:32 +0200 Subject: [LARTC] Wondershaper ACK-Filtering Message-ID: <014101c25e58$2d986410$9605a8c0@Gundy> Hi there! It just occured to me that there is a difference between wshaper and wshaper.htb. In wshaper there is no check on the ACK-bit, all small packages are priorized. Is that the new way to go, or is it a "bug"? Greetings, Nils From noroozi@mehr.sharif.edu Tue Sep 17 16:18:19 2002 From: noroozi@mehr.sharif.edu (noroozi@mehr.sharif.edu) Date: Tue, 17 Sep 2002 15:18:19 GMT Subject: [LARTC] How to install HTB in kernel 2.4.7-10 ?? Message-ID: <200209171518.g8HFIIT10054@mehr.sharif.edu> Hi all, How can I add htb to the linux kernel? I download htb from www.docum.org , but I can't use that , I use patch to change Kernel, after change adjust when I use tc add qdisc dev eth0 htb ... RTNETLINK :answerd errore I use kernel 2.4.7-10 ,If you have any idea I am waiting to listen, --------------------------------------------- This message was sent using sharif web-based mail. http://mehr.sharif.edu From esteban.maringolo@secont.com.ar Tue Sep 17 17:43:23 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 17 Sep 2002 13:43:23 -0300 Subject: [LARTC] Problems compiling patched bridge-utils Message-ID: <1032281004.4300.18.camel@inercia> --=-7j1ebKNIrSJd9bYalbFW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I've applied ``bridge-utils-0.9.5-ipmode-1.diff'' to be able to use my shaper as bridge and don't lose the netfilter capabilities, the patch applies with no error messages, which makes me supose everything is working fine. But when i try to recompile the bridge-utils utilities i get the message transcript below: esteban@inercia:~/devel/nexusbm/bridge-utils-0.9.5$ make make -C libbridge make[1]: Entering directory `/home/esteban/devel/bridge-shaper/bridge-utils-0.9.5/libbridge' gcc -Wall -g -c libbridge_devif.c libbridge_devif.c: In function `br_set_bridge_ip_mode': libbridge_devif.c:151: `BRCTL_SET_BRIDGE_IP_MODE' undeclared (first use in this function) libbridge_devif.c:151: (Each undeclared identifier is reported only once libbridge_devif.c:151: for each function it appears in.) make[1]: *** [libbridge_devif.o] Error 1 make[1]: Leaving directory `/home/esteban/devel/bridge-shaper/bridge-utils-0.9.5/libbridge' make: *** [libbridge/libbridge.a] Error 2 If I compile the bridge-utils with no patch applied (or with the lower version diff applied) it compiles seamsly, and I can build a .deb with it too :-) Any Clue? --=20 Esteban A. Maringolo Buenos Aires, Argentina --=-7j1ebKNIrSJd9bYalbFW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9h1urDY8wt+MWh9ARAmiVAJ9BuhbVBduq5y/Q5CHlYP/kRvVg3QCeIkUG 41EAS7GhrxchhRh4GV7Irbg= =TKvv -----END PGP SIGNATURE----- --=-7j1ebKNIrSJd9bYalbFW-- From stef.coene@docum.org Tue Sep 17 18:07:09 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 19:07:09 +0200 Subject: [LARTC] How to install HTB in kernel 2.4.7-10 ?? In-Reply-To: <200209171518.g8HFIIT10054@mehr.sharif.edu> References: <200209171518.g8HFIIT10054@mehr.sharif.edu> Message-ID: <200209171907.09974.stef.coene@docum.org> On Tuesday 17 September 2002 17:18, noroozi@mehr.sharif.edu wrote: > Hi all, > How can I add htb to the linux kernel? > I download htb from www.docum.org , but I can't use that , I use patch = to > change Kernel, after change adjust when I use > tc add qdisc dev eth0 htb ... > RTNETLINK :answerd errore > > I use kernel 2.4.7-10 ,If you have any idea I am waiting to listen, I think you mean you followed the link on www.docum.org to the htb home-p= age. =20 On the same page is a patch for iproute2. You have to applied this patch= to=20 the iproute2 source and use the patched version of the tc command. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Sep 17 18:10:35 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 19:10:35 +0200 Subject: [LARTC] latency simulation In-Reply-To: <3D8739E0.5030305@fli4l.de> References: <3D8739E0.5030305@fli4l.de> Message-ID: <200209171910.35162.stef.coene@docum.org> On Tuesday 17 September 2002 16:19, Hannes Ebner wrote: > Hi, > > how could I achieve a simulation of Bandwidth _and_ Latency? > > In detail, I need to simulate the characteristics of ISDN and DSL on a > simple Ethernet-Connection: > > ISDN 64 Kbit/s und 10 ms latency > DSL 128 Kbit/s und 50 ms latency > > I would use HTB for the limitation of the Bandwidth, but how am I able > to increase the latency? Take a look at nist : http://snad.ncsl.nist.gov/itg/nistnet/ I once tried it and it works. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From ja@ssi.bg Tue Sep 17 18:10:46 2002 From: ja@ssi.bg (Julian Anastasov) Date: Tue, 17 Sep 2002 20:10:46 +0300 (EEST) Subject: [LARTC] Problems compiling patched bridge-utils In-Reply-To: <1032281004.4300.18.camel@inercia> Message-ID: Hello, On 17 Sep 2002, Esteban Maringolo wrote: > I've applied ``bridge-utils-0.9.5-ipmode-1.diff'' to be able to use my > shaper as bridge and don't lose the netfilter capabilities, the patch > applies with no error messages, which makes me supose everything is > working fine. > > But when i try to recompile the bridge-utils utilities i get the > message transcript below: > > esteban@inercia:~/devel/nexusbm/bridge-utils-0.9.5$ make > make -C libbridge > make[1]: Entering directory > `/home/esteban/devel/bridge-shaper/bridge-utils-0.9.5/libbridge' > gcc -Wall -g -c libbridge_devif.c > libbridge_devif.c: In function `br_set_bridge_ip_mode': > libbridge_devif.c:151: `BRCTL_SET_BRIDGE_IP_MODE' undeclared (first use > in this function) May be you need 2.4.19 kernel in /usr/src/linux patched with bridge-ipmode-2.4.19-2.diff, the user-space stuff is not enough. > Any Clue? Regards -- Julian Anastasov From stef.coene@docum.org Tue Sep 17 18:14:00 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 19:14:00 +0200 Subject: [LARTC] [htb3] patch errors on 2.4.19mdk In-Reply-To: <20020917155227.0d132c37.raptor@tvskat.net> References: <20020917155227.0d132c37.raptor@tvskat.net> Message-ID: <200209171914.00492.stef.coene@docum.org> On Tuesday 17 September 2002 21:52, raptor wrote: > When I apply HTB3 paches to 2.4.19 (mandrake kernel) I get this : > (NO to all questions) Some parts of the htb patch fixes other, small network problems. But the= se=20 changes are already applied to the 2.4.19 kernel. So just press enter an= d it=20 will work. At least on the 2.4.19 kernel from kernel.org. If you check out the *.rej files and the original files, you will see tha= t the=20 changes in the *.rej files are allready applied. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Sep 17 18:15:48 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 19:15:48 +0200 Subject: [LARTC] the range of HTB's prio In-Reply-To: <200209171200.20249.robert.penz@outertech.com> References: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> <20020917125013.5baa3d3f.nikky@mnet.bg> <200209171200.20249.robert.penz@outertech.com> Message-ID: <200209171915.48409.stef.coene@docum.org> On Tuesday 17 September 2002 12:00, Robert Penz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 17 September 2002 11:50, Nickola Kolev wrote: > > > please tell me the range of "prio" > > > > 1 to 8, 1 being the highest, 8 - the lowest. > > 0 is highest as I know ... > > but I've also an question: > > is there if difference if I have 2 chains and use prio 0 and 7 or prio = 0 > and 1 ? No Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Sep 17 18:15:20 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 19:15:20 +0200 Subject: [LARTC] the range of HTB's prio In-Reply-To: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> References: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> Message-ID: <200209171915.20548.stef.coene@docum.org> On Tuesday 17 September 2002 09:53, hanhbnetfilter wrote: > HTB and imq was used to control traffic. > AC=3D"tc class add dev eth0 parent" > $AC 1: classid 1:1 htb rate 100kbps burst 2k > $AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps > burst 2k prio 1 > $AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps > burst 2k prio 1 > > please tell me the range of "prio" htb2 : 0-3 htb3 : 0-7 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From josh@chamas.com Tue Sep 17 19:02:40 2002 From: josh@chamas.com (Josh Chamas) Date: Tue, 17 Sep 2002 11:02:40 -0700 Subject: [LARTC] Throttling or policing incoming bandwidth to my linux server Message-ID: <3D876E40.505@chamas.com> Hey, Does anyone have an idea on how to police incoming bandwidth to my server/workstation, in addition to outgoing. I have a rule set like this so far that does well to limit my outbound traffic, but what could I add to this that would limit my inbound traffic to $LIMIT as well, ideally both inbound & outbound sharing the same $LIMIT say 200kbit. LIMIT=200kbit HOSTIP=NNN.NNN.NNN.NNN start () { tc qdisc add dev eth1 root handle 1: cbq avpkt 1000 bandwidth 10mbit tc class add dev eth1 parent 1: classid 1:1 cbq rate $LIMIT allot 1500 prio 5 bounded isolated tc filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src $HOSTIP flowid 1:1 tc qdisc add dev eth1 parent 1:1 sfq perturb 10 } The reason I want this is to be able to limit my bandwidth to what I pay for at my colocation facility, & I only have one server/host machine there, no router. I have read the docs about policing bandwidth with little help, and it seems that when I try to reference the ingress rules, I get a kernel error, maybe its not compiled into my stock 7.2 redhat by default? It sounded like ingress rules might be related to policing, if so I am out of luck. The FreeBSD dummynet/ipfw implementation seem to handle this just fine out of the box, so I suspect this functionality is lurking in the tc rules, but have not found any online docs that seem to know how to clearly do it. Thanks for any clarification you might have on this. Regards, Josh ________________________________________________________________ Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc. http://www.chamas.com NodeWorks Link Checking http://www.nodeworks.com From stef.coene@docum.org Tue Sep 17 19:53:05 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 20:53:05 +0200 Subject: [LARTC] Throttling or policing incoming bandwidth to my linux server In-Reply-To: <3D876E40.505@chamas.com> References: <3D876E40.505@chamas.com> Message-ID: <200209172053.05495.stef.coene@docum.org> On Tuesday 17 September 2002 20:02, Josh Chamas wrote: > Does anyone have an idea on how to police incoming bandwidth > to my server/workstation, in addition to outgoing. I have > a rule set like this so far that does well to limit my > outbound traffic, but what could I add to this that would > limit my inbound traffic to $LIMIT as well, ideally both > inbound & outbound sharing the same $LIMIT say 200kbit. If you create a imq devce (you need to patch kernel + iptables for this),= you=20 can redirect incomint and outgoing to this device so you can make sure IN= +=20 OUT < 200kbit. > LIMIT=3D200kbit > HOSTIP=3DNNN.NNN.NNN.NNN > > start () { > tc qdisc add dev eth1 root handle 1: cbq avpkt 1000 bandwidth 10mb= it > tc class add dev eth1 parent 1: classid 1:1 cbq rate $LIMIT allot = 1500 > prio 5 bounded isolated tc filter add dev eth1 parent 1: protocol ip pr= io > 16 u32 match ip src $HOSTIP flowid 1:1 tc qdisc add dev eth1 parent 1:1= sfq > perturb 10 > } > > The reason I want this is to be able to limit my bandwidth > to what I pay for at my colocation facility, & I only have > one server/host machine there, no router. > > I have read the docs about policing bandwidth with little > help, and it seems that when I try to reference the ingress > rules, I get a kernel error, maybe its not compiled into my > stock 7.2 redhat by default? It sounded like ingress rules > might be related to policing, if so I am out of luck. You also need tc with ingress support. Why not compile your own kernel ?= And=20 I don't use RH, so I don't know if there kernels support ingress. > The FreeBSD dummynet/ipfw implementation seem to handle this > just fine out of the box, so I suspect this functionality > is lurking in the tc rules, but have not found any online > docs that seem to know how to clearly do it. It is, ingress + policer is the answer. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Tue Sep 17 20:15:18 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 17 Sep 2002 21:15:18 +0200 Subject: [LARTC] the range of HTB's prio In-Reply-To: <20020917212832.3a12a061.nikky@mnet.bg> References: <20020917075309.4116.qmail@web15211.mail.bjs.yahoo.com> <200209171915.20548.stef.coene@docum.org> <20020917212832.3a12a061.nikky@mnet.bg> Message-ID: <200209172115.19001.stef.coene@docum.org> > Aren't you talking about the depth of the classes? Euh stupid me. Indeed. > Btw, several months ago I tried to hack my kernel (2.4.17 at that time) > and changed the maxdepth to 7... Guess what happenned? > It went OOOPS'ing... Anyway. That was HTB2. In htb3 you can change it if you want : htb3.6_2.4.17.diff:+#define TC_HTB_MAXDEPTH 8 > So, now with htb3 I can use maximum depth of classes =3D 7, right? Yep. Or change it in the source to an other value. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From leoball@opalsoft.net Wed Sep 18 00:51:20 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Tue, 17 Sep 2002 19:51:20 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #766 - 9 msgs In-Reply-To: <20020917042837.14823.15971.Mailman@outpost> Message-ID: <5.1.0.14.1.20020917192220.00a181d0@opalsoft.net> Hi, In a busy network you need to use prio. Check how many channels of voice=20 you do need and bandwidth required by each channel (16-32 kbits?). Put=20 voice (udp packets) in the higher priority prio queue and use tbf behind it= =20 to limit traffic via prio to the maximum required for your channels. Or use= =20 htp putting your udp traffic in the higher priority class. Be careful that higher prio traffic can't be more than 20-30% of the link=20 capacity to avoid starvation of lower prio traffic. Don=B4t expect good quality in a busy network. When congestion appears your= =20 udp packets will be dropped with no mercy (udp is an unresponssive=20 protocol) hurting quality. Best regards, Leonardo Balliache Ps: Cisco has (check your IOS version) RTP header compression that can help= =20 a lot to lowering bandwidth requirements. You have to enable it at both=20 sides of the link. Also, why don't try directly with Cisco PQ? At 06:28 a.m. 17/09/02 +0200, you wrote: >From: Andreani Luca >To: "LARTC mailing list (E-mail)" >Date: Mon, 16 Sep 2002 11:49:28 +0200 >Subject: [LARTC] Voip and Qos tests > >Hello list, > >I'm performing some tests in order to evaluate the possibility to make Voip >calls on a busy network. >I use some cisco routers with wfq enabled. I want to introduce some linux >boxes acting as routers. >I am especially interested in low-speed (64-128 kbps) links with PPP and >frame-relay. > >Haw you some reference about similar tests? > >Whath qdisc (from tc) has best performance in these situations? > >Thank's > >Luca From leoball@opalsoft.net Wed Sep 18 01:51:41 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Tue, 17 Sep 2002 20:51:41 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #767 - 15 msgs In-Reply-To: <20020917164504.30340.29731.Mailman@outpost> Message-ID: <5.1.0.14.1.20020917203510.00a3e190@opalsoft.net> Hi, Have a look to tbf. It has a selectable latency parameter that adjust the queue length. http://lartc.org/lartc.txt paragraph 9.2.2. Token Bucket Filter can give you more information. Best regards, Leonardo Balliache At 06:45 p.m. 17/09/02 +0200, you wrote: >Message: 12 >Date: Tue, 17 Sep 2002 16:19:12 +0200 >From: Hannes Ebner >To: lartc@mailman.ds9a.nl >Subject: [LARTC] latency simulation > >Hi, > >how could I achieve a simulation of Bandwidth _and_ Latency? > >In detail, I need to simulate the characteristics of ISDN and DSL on a >simple Ethernet-Connection: > > ISDN 64 Kbit/s und 10 ms latency > DSL 128 Kbit/s und 50 ms latency > >I would use HTB for the limitation of the Bandwidth, but how am I able >to increase the latency? > >Thank you in advance, >Hannes From snuffy2@yahoo.com Wed Sep 18 05:42:13 2002 From: snuffy2@yahoo.com (Justin Morea) Date: Tue, 17 Sep 2002 21:42:13 -0700 (PDT) Subject: [LARTC] Wondershaper Message-ID: <20020918044213.28723.qmail@web9501.mail.yahoo.com> I think I've gotten everything up and running but I'm not sure. How can I tell if wondershaper is running correctly (I just put the command /wondershaper/wshaper in my /etc/rc.local)? Can anyone recommend a good program to log bandwidth usage? Thanx Snuffy2 __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From stef.coene@docum.org Wed Sep 18 06:50:52 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 18 Sep 2002 07:50:52 +0200 Subject: [LARTC] Wondershaper In-Reply-To: <20020918044213.28723.qmail@web9501.mail.yahoo.com> References: <20020918044213.28723.qmail@web9501.mail.yahoo.com> Message-ID: <200209180750.52426.stef.coene@docum.org> On Wednesday 18 September 2002 06:42, Justin Morea wrote: > I think I've gotten everything up and running but I'm > not sure. > > How can I tell if wondershaper is running correctly (I > just put the command /wondershaper/wshaper in my > /etc/rc.local)? > > Can anyone recommend a good program to log bandwidth > usage? iptraf, ethereal, ntop, a quick google search will show some more. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From smohan@vsnl.com Wed Sep 18 07:23:44 2002 From: smohan@vsnl.com (S Mohan) Date: Wed, 18 Sep 2002 11:53:44 +0530 Subject: [LARTC] the range of HTB's prio In-Reply-To: <200209171915.48409.stef.coene@docum.org> Message-ID: Earlier Freeswan also required patching of kernel. Recently, however, an rpm was released which makes it easy to install. many users may not have installed development libraries to do a recompile. Can someone who is good at it create and publish the rpms of kernel, iproute2 and tc patched for htb please? Mohan -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On Behalf Of Stef Coene Sent: 17 September 2002 22:46 To: Robert Penz; lartc@mailman.ds9a.nl Subject: Re: [LARTC] the range of HTB's prio On Tuesday 17 September 2002 12:00, Robert Penz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 17 September 2002 11:50, Nickola Kolev wrote: > > > please tell me the range of "prio" > > > > 1 to 8, 1 being the highest, 8 - the lowest. > > 0 is highest as I know ... > > but I've also an question: > > is there if difference if I have 2 chains and use prio 0 and 7 or prio 0 > and 1 ? No 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/ From mr_alavi@yahoo.com Wed Sep 18 07:39:35 2002 From: mr_alavi@yahoo.com (Reza Alavi) Date: Tue, 17 Sep 2002 23:39:35 -0700 (PDT) Subject: [LARTC] Simple (y/n) HTB question Message-ID: <20020918063935.38849.qmail@web13302.mail.yahoo.com> Assume the following condition: I have a Network with this topology INTERNET | | [Router A] | | /|\ / | \ Clients If I install a Linux box between Router A and Internet ,could I shape the bandwidth of every client with HTB ? What If router A is simply a NAT and clients IPs are not valid? What about this diagram? INTERNET ---------------------- | | [Linux Box] /|\ / | \ / | \ / | \ A B C A,C are both NATs. B is a router. Can I limit the bandwidth of every client simply with their IP addresses?(no matther if they are valid or NAT addresses?) __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From he@fli4l.de Wed Sep 18 09:04:36 2002 From: he@fli4l.de (Hannes Ebner) Date: Wed, 18 Sep 2002 10:04:36 +0200 Subject: [LARTC] latency simulation References: <3D8739E0.5030305@fli4l.de> Message-ID: <3D883394.9060408@fli4l.de> Hi Leonardo, > Have a look to tbf. It has a selectable latency parameter that adjust > the queue length. http://lartc.org/lartc.txt paragraph 9.2.2. Token > Bucket Filter can give you more information. from the HOWTO: "...the latency parameter, which specifies the maximum amount of time a packet can sit in the TBF...". _Can_ sit in the TBF, not _will_ sit. Therefore it is also possible to get the packet forwarded with a latency smaller than the one I have given to the TBF - but I need a method to decrease it to a fixed amount. Regards, Hannes From he@fli4l.de Wed Sep 18 09:06:10 2002 From: he@fli4l.de (Hannes Ebner) Date: Wed, 18 Sep 2002 10:06:10 +0200 Subject: [LARTC] latency simulation References: <3D8739E0.5030305@fli4l.de> <200209171910.35162.stef.coene@docum.org> Message-ID: <3D8833F2.4000208@fli4l.de> Hi Stef, Stef Coene schrieb: >>I would use HTB for the limitation of the Bandwidth, but how am I able >>to increase the latency? > > Take a look at nist : > http://snad.ncsl.nist.gov/itg/nistnet/ > I once tried it and it works. thank you, a very powerful tool! Regards, Hannes From druid@mail.cz Wed Sep 18 09:57:56 2002 From: druid@mail.cz (=?iso-8859-2?B?VmxhZGlt7XIgVPhlYmlja/0=?=) Date: Wed, 18 Sep 2002 10:57:56 +0200 Subject: [LARTC] Where to get working esfq hash src ip? Message-ID: <003901c25ef1$7af0b5c0$4500a8c0@cybernet.cz> Hi, It is exactly what I need except one thing. I don't know exactly if my router is the right place to apply QoS policy. It has two network interfaces and both are 10Mbit/s. The slow part of the network is little bit more far. On their QoS we have 2Mbit and I want all our users to divide this bandwidth equally but also don't want to unnecessarily restrain their bandwith and to have free bandwith elsewhere at the same time. In my opinion esfq is right choice but I don't if it has any effect on router that has two 10Mbit/s interfaces that cannot be fully used because of that restriction on ISP's side. Anyway, should I use esfq dst on LAN interface and esfq src on Internet interface? Where can I get the latest version of esfq? Thanks, Vladimir Trebicky -- Vladimir Trebicky druid@mail.cz From alex@ssi.bg Wed Sep 18 10:31:40 2002 From: alex@ssi.bg (Alexander Atanasov) Date: Wed, 18 Sep 2002 12:31:40 +0300 Subject: [LARTC] Where to get working esfq hash src ip? In-Reply-To: <003901c25ef1$7af0b5c0$4500a8c0@cybernet.cz> References: <003901c25ef1$7af0b5c0$4500a8c0@cybernet.cz> Message-ID: <20020918123140.5d700f5e.alex@ssi.bg> Hello, On Wed, 18 Sep 2002 10:57:56 +0200 "Vladimír Tĝebickŭ" wrote: > Hi, > It is exactly what I need except one thing. I don't know exactly if my > router is the right place to apply QoS policy. It has two network > interfaces and both are 10Mbit/s. The slow part of the network is > little bit more far. On their QoS we have 2Mbit and I want all our > users to divide this bandwidth equally but also don't want to > unnecessarily restrain their bandwith and to have free bandwith > elsewhere at the same time. In my opinion esfq is right choice but I > don't if it has any effect on router that has two 10Mbit/s interfaces > that cannot be fully used because of that restriction on ISP's side. You'll need to put something over it CBQ/HTB to limit it little below 2MBit. > Anyway, should I use esfq dst on LAN interface and esfq src on > Internet Yes. > interface? Where can I get the latest version of esfq? You can get it from: http://www.ssi.bg/~alex/esfq/index.html Not updated soon but should work with recent 2.4 kernels. If you have troubles with it ,please, let me know. > -- > Vladimir Trebicky > druid@mail.cz -- Best Regards, Alexander Atanasov From raptor@tvskat.net Wed Sep 18 21:21:49 2002 From: raptor@tvskat.net (raptor) Date: Wed, 18 Sep 2002 16:21:49 -0400 Subject: [LARTC] [tcng] PSCHED_CPU ? Message-ID: <20020918162149.0efbd869.raptor@tvskat.net> hi, Will it be a problem if my kernel is compiled with PSCHED_CPU, but for the success of the compilation of tcism I use PSCHED_JIFFES ? ----------------------------------------------------------------- In file included from klink.c:19: klib/include/net/pkt_sched.h:285:2: #error PSCHED_CLOCK_SOURCE=PSCHED_CPU is not supported on this arch. In file included from trace.c:20: klib/include/net/pkt_sched.h:285:2: #error PSCHED_CLOCK_SOURCE=PSCHED_CPU is not supported on this arch. make[1]: *** [.depend] Error 1 make[1]: Leaving directory `/arh/compile/tcng/tcsim' make: *** [all] Error 1 Thanx raptor From wa@almesberger.net Wed Sep 18 14:38:18 2002 From: wa@almesberger.net (Werner Almesberger) Date: Wed, 18 Sep 2002 10:38:18 -0300 Subject: [LARTC] [tcng] PSCHED_CPU ? In-Reply-To: <20020918162149.0efbd869.raptor@tvskat.net>; from raptor@tvskat.net on Wed, Sep 18, 2002 at 04:21:49PM -0400 References: <20020918162149.0efbd869.raptor@tvskat.net> Message-ID: <20020918103818.M1781@almesberger.net> raptor wrote: > Will it be a problem if my kernel is compiled with PSCHED_CPU, but for > the success of the compilation of tcism I use PSCHED_JIFFES ? tcsim should just use PSCHED_JIFFIES, no matter what your kernel is configured to do. Quite obviously, this doesn't seem to be the case on your system. Is this a i386 platform ? And which kernel and which version of tcng are you using ? - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From Adi@iNterNUX.co.id Wed Sep 18 10:50:59 2002 From: Adi@iNterNUX.co.id (Adi Nugroho) Date: Wed, 18 Sep 2002 17:50:59 +0800 Subject: [LARTC] Simple (y/n) HTB question In-Reply-To: <20020918063935.38849.qmail@web13302.mail.yahoo.com> References: <20020918063935.38849.qmail@web13302.mail.yahoo.com> Message-ID: <200209181750.59276.Adi@iNterNUX.co.id> On Wednesday 18 September 2002 14:39, Reza Alavi wrote: > [Linux Box] > /|\ > / | \ > / | \ > / | \ > A B C > A,C are both NATs. > B is a router. > Can I limit the bandwidth of every client simply with > their IP addresses?(no matther if they are valid or > NAT addresses?) Yes, you are right. (assuming that NAT are done by the linux box). -- Salam, Adi Nugroho From raptor@tvskat.net Wed Sep 18 21:57:33 2002 From: raptor@tvskat.net (raptor) Date: Wed, 18 Sep 2002 16:57:33 -0400 Subject: [LARTC] [tcng] PSCHED_CPU ? In-Reply-To: <20020918103818.M1781@almesberger.net> References: <20020918162149.0efbd869.raptor@tvskat.net> <20020918103818.M1781@almesberger.net> Message-ID: <20020918165733.78907577.raptor@tvskat.net> |Quite obviously, this doesn't seem to be the case on your system. |Is this a i386 platform ? And which kernel and which version of |tcng are you using ? ]- i386, tcng-8u, Mandrake 2.4.19mdk-9 From wa@almesberger.net Wed Sep 18 15:25:05 2002 From: wa@almesberger.net (Werner Almesberger) Date: Wed, 18 Sep 2002 11:25:05 -0300 Subject: [LARTC] [tcng] PSCHED_CPU ? In-Reply-To: <20020918165733.78907577.raptor@tvskat.net>; from raptor@tvskat.net on Wed, Sep 18, 2002 at 04:57:33PM -0400 References: <20020918162149.0efbd869.raptor@tvskat.net> <20020918103818.M1781@almesberger.net> <20020918165733.78907577.raptor@tvskat.net> Message-ID: <20020918112505.N1781@almesberger.net> --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline raptor wrote: > ]- i386, tcng-8u, Mandrake 2.4.19mdk-9 Does the attached patch help ? With it, setup.klib simply reverts include/net/pkt_sched.h back to using PSCHED_JIFFIES. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch --- setup.klib.old Wed Sep 18 11:14:27 2002 +++ setup.klib Wed Sep 18 11:24:23 2002 @@ -100,7 +100,14 @@ u16 mask); \ trace_u32_offset(skb,n->handle,ptr-skb->nh.raw+n->sel.offoff,n->sel.offmask);\ & }/'>cls_u32.c - + +# +# De-Mandrakize net/pkt_sched.h +# + +sed 's/\(#define PSCHED_CLOCK_SOURCE[^ -~]*PSCHED_\)CPU/\1JIFFIES/' \ + <$KSRC/include/net/pkt_sched.h >include/net/pkt_sched.h + ln -s $KSRC kernel # --TB36FDmn/VVEgNH/-- From david_list@boreham.org Wed Sep 18 15:31:20 2002 From: david_list@boreham.org (David Boreham) Date: Wed, 18 Sep 2002 07:31:20 -0700 Subject: [LARTC] the range of HTB's prio References: Message-ID: <044b01c25f20$0e7906c0$220aa8c0@mtbrook.boreham.org> > Earlier Freeswan also required patching of kernel. Recently, however, an rpm > was released which makes it easy to install. many users may not have > installed development libraries to do a recompile. Can someone who is good > at it create and publish the rpms of kernel, iproute2 and tc patched for htb > please? For which distribution ? From g38@rdsbv.ro Wed Sep 18 15:51:24 2002 From: g38@rdsbv.ro (Petre Bandac) Date: Wed, 18 Sep 2002 17:51:24 +0300 Subject: [LARTC] cbq & htb Message-ID: <200209181451.g8IEpqF12283@g38.rdsbv.ro> is it ok if on a router with several NICs I use htb for one/more interfaces and cbq for only one ? (don't ask me why I need this solution :-)) thanks, petre -- 5:49pm up 9:49, 1 user, load average: 0.10, 0.13, 0.13 From Adi@iNterNUX.co.id Wed Sep 18 16:01:23 2002 From: Adi@iNterNUX.co.id (Adi Nugroho) Date: Wed, 18 Sep 2002 23:01:23 +0800 Subject: [LARTC] Wondershaper In-Reply-To: <20020918044213.28723.qmail@web9501.mail.yahoo.com> References: <20020918044213.28723.qmail@web9501.mail.yahoo.com> Message-ID: <200209182301.23597.Adi@iNterNUX.co.id> On Wednesday 18 September 2002 12:42, Justin Morea wrote: > How can I tell if wondershaper is running correctly tc qdisc sh dev $dev tc class sh dev $dev tc -s -d qdisc show dev $dev tc -s -d class show dev $dev > Can anyone recommend a good program to log bandwidth > usage? I would recommend mrtg. -- Salam, Adi Nugroho From druid@mail.cz Wed Sep 18 17:07:36 2002 From: druid@mail.cz (=?iso-8859-1?Q?Vladim=EDr_Trebick=FD?=) Date: Wed, 18 Sep 2002 18:07:36 +0200 Subject: [LARTC] [tcng] PSCHED_CPU ? References: <20020918162149.0efbd869.raptor@tvskat.net> Message-ID: <001801c25f2d$8d5b8eb0$4500a8c0@cybernet.cz> The problem with PSCHED_CPU is that the time is derived by reading of TSC registry which is measure counter of the processor. TSC exists on Intel platform from the times of Pentium but sometimes cannot be used as a counter, for example with APM (advanced power management) turned on. ----- Original Message ----- From: "raptor" To: Sent: Wednesday, September 18, 2002 10:21 PM Subject: [LARTC] [tcng] PSCHED_CPU ? > hi, > > Will it be a problem if my kernel is compiled with PSCHED_CPU, but for the success of the compilation of tcism I use PSCHED_JIFFES ? > ----------------------------------------------------------------- > In file included from klink.c:19: > klib/include/net/pkt_sched.h:285:2: #error PSCHED_CLOCK_SOURCE=PSCHED_CPU is not supported on this arch. > In file included from trace.c:20: > klib/include/net/pkt_sched.h:285:2: #error PSCHED_CLOCK_SOURCE=PSCHED_CPU is not supported on this arch. > make[1]: *** [.depend] Error 1 > make[1]: Leaving directory `/arh/compile/tcng/tcsim' > make: *** [all] Error 1 > > Thanx > > raptor > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From stef.coene@docum.org Wed Sep 18 17:32:13 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 18 Sep 2002 18:32:13 +0200 Subject: [LARTC] cbq & htb In-Reply-To: <200209181451.g8IEpqF12283@g38.rdsbv.ro> References: <200209181451.g8IEpqF12283@g38.rdsbv.ro> Message-ID: <200209181832.13477.stef.coene@docum.org> On Wednesday 18 September 2002 16:51, Petre Bandac wrote: > is it ok if on a router with several NICs I use htb for one/more interf= aces > and cbq for only one ? (don't ask me why I need this solution :-)) It's ok. At least, I don't know one reason why it shouldn't. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Sep 18 17:33:59 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 18 Sep 2002 18:33:59 +0200 Subject: [LARTC] latency simulation In-Reply-To: <3D8833F2.4000208@fli4l.de> References: <3D8739E0.5030305@fli4l.de> <200209171910.35162.stef.coene@docum.org> <3D8833F2.4000208@fli4l.de> Message-ID: <200209181833.59428.stef.coene@docum.org> On Wednesday 18 September 2002 10:06, Hannes Ebner wrote: > Hi Stef, > > Stef Coene schrieb: > >>I would use HTB for the limitation of the Bandwidth, but how am I abl= e > >>to increase the latency? > > > > Take a look at nist : > > http://snad.ncsl.nist.gov/itg/nistnet/ > > I once tried it and it works. > > thank you, a very powerful tool! Let me know if it works for you. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mr_alavi@yahoo.com Wed Sep 18 17:58:34 2002 From: mr_alavi@yahoo.com (Reza Alavi) Date: Wed, 18 Sep 2002 09:58:34 -0700 (PDT) Subject: [LARTC] Re: Simple (y/n) HTB question (Adi Nugroho) In-Reply-To: <20020918163502.29393.97233.Mailman@outpost> Message-ID: <20020918165834.24927.qmail@web13307.mail.yahoo.com> On Wednesday 18 September 2002 14:39, Reza Alavi wrote: >> [Linux Box] >> /|\ >> / | \ >> / | \ >> / | \ >> A B C >> A,C are both NATs. >> B is a router. >> Can I limit the bandwidth of every client simply with >> their IP addresses?(no matther if they are valid or >> NAT addresses?) >Yes, you are right. >(assuming that NAT are done by the linux box). What I ment was if A and C are both Networks Which use NAT By themselfs and I want tp use Linux Box as only a traffic shaper for them (B is a network behind a router.) Is it possible?? __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From tw@eter.tym.pl Wed Sep 18 23:52:18 2002 From: tw@eter.tym.pl (Tomasz Wrona) Date: Thu, 19 Sep 2002 00:52:18 +0200 (CEST) Subject: [LARTC] tc/htb still hangs system. Message-ID: Hello, I would like ask for help in despair... I am running complex htb setup to manage two leased lines [1+2MBit] for 500 users. Setup works from few months but in this time I have still awfully problems with stable work. Nowadays there is no week when system hangs two or three times. I tried dozens of setups, patches, recompilations of kernel, iproute and iptables, tricks and still almost without improvement. I tried to find reason but without success. Bellow I mention some observed facts. Maybe someboty could advise or solve problem... When I started with HTB [2.0] [about 200 users on 1Mbit link; Previous it worked on CBQ setup] there wasn't propably [AFAIK] problems with stable work [many days between manual reboot]. From time to time I had some sudden hangs, which become more often later. I changed kernel to 2.4.18 but the reason what I found [or one of the reasons...] whas hardware related [damaged cpu and/or mboard]. I changed completly all hardware and changed kernel to 2.4.18 patched with htb v2. but problem didn't dissapear - frozen system during several days. Most ofen hangs was after 1 or 2 days of stable work but some cases it was 4 or even 7 days. . Then I tried 2.4.18 patched with htb v.3. but situation become hopeless. I found that each changing of htb class parameters [tc class change...] lead to freezing system. Sometimes one sometimes more changing params caused crash. Htb 3 was useless for me and htb 2 was/is also unstable. I also tried htb2 on completly other machine [but with the same Linux distro - PLD], but system crashed almost immediately. Now I am testing 2.4.20-pre7 [with included htb3], system didn't hang immediatelly after changing htb class params but now it works from several hours to one day. Unfortunatelly I didn't have any error messages in logs and on console. ERRATA: Today I have first time to see some logs on console [kernel 2.4.20-pre7], there is something about Oops "Process swapper (pid: 0, stackpage=c0211000)" and a lot of digits. I put screen on location: http://eter.tym.pl/bug2.gif Diging in LARTC archive I found maybe something simmilar problem in post of "Dimitris Zilaskos: [LARTC] tc reliably hangs my system " [http://mailman.ds9a.nl/pipermail/lartc/2002q3/004316.html] but there is not solution for me and despaired I dont know the reason and what to do with it. BTW. If this bug report [http://eter.tym.pl/bug2.gif file] is related more to kernel than to tc/htb please tell me where to send it. Regards tw -- ---------------- ck.eter.tym.pl "Never let shooling disturb Your education" From wa@almesberger.net Thu Sep 19 01:35:39 2002 From: wa@almesberger.net (Werner Almesberger) Date: Wed, 18 Sep 2002 21:35:39 -0300 Subject: [LARTC] tc/htb still hangs system. In-Reply-To: ; from tw@eter.tym.pl on Thu, Sep 19, 2002 at 12:52:18AM +0200 References: Message-ID: <20020918213539.P1781@almesberger.net> Tomasz Wrona wrote: > I tried to find reason but without success. Bellow I mention some > observed facts. Maybe someboty could advise or solve problem... In case you want to try systematic debugging of HTB, you may find tcsim useful. tcsim can be run under Electric Fence and under Valgrind (http://developer.kde.org/~sewardj/). It won't help you find race conditions and such, but spotting odd side-effects of parameter changes may be well within its capabilities. Of course, a decent set of regression tests should also be useful for future HTB development ... Concerning the Oops you got: you should run it through ksymoops (see Documentation/oops-tracing.txt in your kernel source tree). If you don't want to type in the whole Oops text, you can also get the location of individual symbols with gdb your/kernel/dir/vmlinux (gdb) info line *0xd093caa4 etc. The most useful data is in the EIP and the call trace. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From Adi@iNterNUX.co.id Thu Sep 19 04:57:02 2002 From: Adi@iNterNUX.co.id (Adi Nugroho) Date: Thu, 19 Sep 2002 11:57:02 +0800 Subject: [LARTC] Re: Simple (y/n) HTB question (Adi Nugroho) In-Reply-To: <20020918165834.24927.qmail@web13307.mail.yahoo.com> References: <20020918165834.24927.qmail@web13307.mail.yahoo.com> Message-ID: <200209191157.02799.Adi@iNterNUX.co.id> On Thursday 19 September 2002 00:58, Reza Alavi wrote: > What I ment was if A and C are both Networks Which use > NAT By themselfs and I want tp use Linux Box as only a > traffic shaper for them (B is a network behind a > router.) > Is it possible?? A and C are networks which are NAT-ed by router A and router B. Then if you shape for A and C, it will shape every box which is NAT-ed. If B are router, and NOT doing NAT, then if you shape B, it is only match the router, and NOT imply boxes behind B. You have to shape them one-by-one. -- Salam, Adi Nugroho From raptor@tvskat.net Thu Sep 19 14:20:24 2002 From: raptor@tvskat.net (raptor) Date: Thu, 19 Sep 2002 09:20:24 -0400 Subject: [LARTC] [tcng] PSCHED_CPU ? In-Reply-To: <001801c25f2d$8d5b8eb0$4500a8c0@cybernet.cz> References: <20020918162149.0efbd869.raptor@tvskat.net> <001801c25f2d$8d5b8eb0$4500a8c0@cybernet.cz> Message-ID: <20020919092024.00c6a7a7.raptor@tvskat.net> Vladimír Trebickŭ wrote: |The problem with PSCHED_CPU is that the time is derived by reading of TSC |registry which is measure counter of the processor. TSC exists on Intel |platform from the times of Pentium but sometimes cannot be used as a |counter, for example with APM (advanced power management) turned on. ]- that's good then 'cause I didn't compiled power-management into the kernel :") Do u know any other reason not to use PSCHED_CPU ? In the past I have setup "HZ = 1000" when building QoS is it wise to do it if the only purpose of this computer is QoS+Firewall and of course it is powerfull enought 1.8GHz. And I don't expect it to exceed 1000 slow-qos-channels and handle not more than 1Mb/s most of the time. raptor PS.Sorry for the ignorance what is TSC-regitry and its use ? thanx.. From druid@mail.cz Thu Sep 19 07:33:14 2002 From: druid@mail.cz (=?iso-8859-1?Q?Vladim=EDr_Trebick=FD?=) Date: Thu, 19 Sep 2002 08:33:14 +0200 Subject: [LARTC] [tcng] PSCHED_CPU ? References: <20020918162149.0efbd869.raptor@tvskat.net><001801c25f2d$8d5b8eb0$4500a8c0@cybernet.cz> <20020919092024.00c6a7a7.raptor@tvskat.net> Message-ID: <000b01c25fa6$6e6e56d0$4500a8c0@cybernet.cz> In my opinion there is no reason not to use PSCHED_CPU except those around APM and architecture. If you don't want to use APM and do have Athlon use PSCHED_CPU. ----- Original Message ----- From: "raptor" To: "Vladimír Trebickŭ" Cc: Sent: Thursday, September 19, 2002 3:20 PM Subject: Re: [LARTC] [tcng] PSCHED_CPU ? > Vladimír Trebickŭ wrote: > |The problem with PSCHED_CPU is that the time is derived by reading of TSC > |registry which is measure counter of the processor. TSC exists on Intel > |platform from the times of Pentium but sometimes cannot be used as a > |counter, for example with APM (advanced power management) turned on. > > ]- that's good then 'cause I didn't compiled power-management into the kernel :") > Do u know any other reason not to use PSCHED_CPU ? > > In the past I have setup "HZ = 1000" when building QoS is it wise to do it if the only purpose of this computer is QoS+Firewall and of course it is powerfull enought 1.8GHz. > And I don't expect it to exceed 1000 slow-qos-channels and handle not more than 1Mb/s most of the time. > > raptor > PS.Sorry for the ignorance what is TSC-regitry and its use ? thanx.. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From raptor@tvskat.net Thu Sep 19 15:48:40 2002 From: raptor@tvskat.net (raptor) Date: Thu, 19 Sep 2002 10:48:40 -0400 Subject: [LARTC] [tcng8u] make test errors Message-ID: <20020919104840.127a6fb4.raptor@tvskat.net> here are the errors I'm getting -------------------------------------------- [root@qos tcng]# cat _ref.4609 :1: warning: unused variable x [root@qos tcng]# cat _out.4609 :17: warning: unused variable x [root@qos tcng]# cat _in.4609 $a = { $x = 13; 7; }; field foo = raw if $a == $a; ------------------------------------------------- bare words for strings are forbidden: PASSED quoted strings for strings are okay: PASSED bare words for warning labels are forbidden: PASSED (warning: output differs) Standard output: | :17: syntax error near "nounused" Reference output: | :1: syntax error near "nounused" quoted strings for warning labels are okay: PASSED bare words are still okay for device names: PASSED quoted strings are also okay for device names: PASSED typos don't turn into strings (1): PASSED ........................................ qdisc collision from distinct blocks is detected (1): PASSED qdisc collision from distinct blocks is detected (2): PASSED "inner" blocks are shown correctly in variable use output: PASSED bucket: can define variables: PASSED bucket: can use with conform, count: PASSED bucket: policer parameters are refused: PASSED (warning: output differs) Standard output: | :17: unrecognized parameter "mtu" Reference output: | :1: unrecognized parameter "mtu" ........................ compound construct with multiple assignments: PASSED compound construct must end with semicolon: PASSED (warning: output differs) Standard output: | :17: syntax error near "}" Reference output: | :1: syntax error near "}" compound construct may end with multiple semicolons: PASSED compound construct requires semicolon after assignment: PASSED (warning: output differs) Standard output: | :17: syntax error near "$x" Reference output: | :1: syntax error near "$x" compound construct allows multiple semicolons after assignment: PASSED compound construct warns about unused variables: FAILED File: tests/compound Command: tcc -c 2>&1 Input: _in.4609 Output: _out.4609 Reference: _ref.4609 scripts/runtests.sh: line 2: 4633 Broken pipe cat scripts/run-all-tests: line 14: 15771 Broken pipe cat $n make: *** [test] Error From raptor@tvskat.net Thu Sep 19 16:25:53 2002 From: raptor@tvskat.net (raptor) Date: Thu, 19 Sep 2002 11:25:53 -0400 Subject: [LARTC] [tcng8u] make test errors In-Reply-To: <20020919104840.127a6fb4.raptor@tvskat.net> References: <20020919104840.127a6fb4.raptor@tvskat.net> Message-ID: <20020919112553.4a3e2ac1.raptor@tvskat.net> Hmm it seems like one my old problem... seems i had the same error with older tcng.. have to look in the arhives.. From raptor@tvskat.net Thu Sep 19 16:38:04 2002 From: raptor@tvskat.net (raptor) Date: Thu, 19 Sep 2002 11:38:04 -0400 Subject: [LARTC] Don't-bother [tcng8u] make test errors In-Reply-To: <20020919104840.127a6fb4.raptor@tvskat.net> References: <20020919104840.127a6fb4.raptor@tvskat.net> Message-ID: <20020919113804.7ece2863.raptor@tvskat.net> sorry for the wasted bandwith, all the time I was thinking I'm with the latest TCNG, but the last one is 8w.... dloading...:") sorry again .... From tw@eter.tym.pl Thu Sep 19 10:52:48 2002 From: tw@eter.tym.pl (Tomasz Wrona) Date: Thu, 19 Sep 2002 11:52:48 +0200 (CEST) Subject: [LARTC] tc/htb still hangs system - ksymoops traced. In-Reply-To: <20020918213539.P1781@almesberger.net> Message-ID: Werner thanks for usefull info ! On Wed, 18 Sep 2002, Werner Almesberger wrote: > Concerning the Oops you got: you should run it through ksymoops > (see Documentation/oops-tracing.txt in your kernel source tree). OK, I retyped screenshot and put it to ksymoops and it said: [Will it be enough info to debug, what can I do also ?] ### BEGIN ### ksymoops 2.4.6 on i686 2.4.20-pre7. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-pre7/ (default) -m /boot/System.map-2.4.20-pre7 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Oops: 0000 CPU: 0 EIP: 0010:[] Not tained Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00005198 ebx: 00000030 ecx: cd227400 edx: cf6ecc84 esi: cf6ecc84 edi: 00000030 ebp: 00000000 esp: c0211e3c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0211000) Stack: 00000000 cf6ecc00 00000000 cd227400 d093caa4 cd363c5c cf6ecc84 cd227400 00000003 cd227400 00000001 cd363c5c cd363c5c d093ce55 cd363c5c cd227400 03938700 00000000 cd227400 d093d71f cd363c5c cd227400 c0211eb4 cd363924 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 81 38 f1 fe fa fe 74 12 68 84 01 00 00 68 00 f3 93 d0 c8 82 >>EIP; d093c56f <[sch_htb]htb_add_to_id_tree+93/130> <===== >>ecx; cd227400 <_end+cfb8e4c/10596a4c> >>edx; cf6ecc84 <_end+f47e6d0/10596a4c> >>esi; cf6ecc84 <_end+f47e6d0/10596a4c> >>esp; c0211e3c Trace; d093caa4 <[sch_htb]htb_activate_prios+a4/13c> Trace; d093ce55 <[sch_htb]htb_change_class_mode+89/a0> Trace; d093d71f <[sch_htb]htb_do_events+1bb/210> Trace; d093dc1b <[sch_htb]htb_dequeue+10b/21c> Trace; d093d913 <[sch_htb]htb_dequeue_tree+a7/218> Trace; d093dc8c <[sch_htb]htb_dequeue+17c/21c> Trace; c0199843 Trace; c019384d Trace; c01168aa Trace; c0109962 Trace; c0106ba0 Trace; c0106ba0 Trace; c010bb18 Trace; c0106ba0 Trace; c0106ba0 Trace; c0106bc3 Trace; c0106c29 Trace; c0105000 <_stext+0/0> Trace; c0105027 Code; d093c56f <[sch_htb]htb_add_to_id_tree+93/130> 00000000 <_EIP>: Code; d093c56f <[sch_htb]htb_add_to_id_tree+93/130> <===== 0: 81 38 f1 fe fa fe cmpl $0xfefafef1,(%eax) <===== Code; d093c575 <[sch_htb]htb_add_to_id_tree+99/130> 6: 74 12 je 1a <_EIP+0x1a> d093c589 <[sch_htb]htb_add_to_id_tree+ad/130> Code; d093c577 <[sch_htb]htb_add_to_id_tree+9b/130> 8: 68 84 01 00 00 push $0x184 Code; d093c57c <[sch_htb]htb_add_to_id_tree+a0/130> d: 68 00 f3 93 d0 push $0xd093f300 Code; d093c581 <[sch_htb]htb_add_to_id_tree+a5/130> 12: c8 82 00 00 enter $0x82,$0x0 <0>Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. ### END ### Regards tw -- ---------------- ck.eter.tym.pl From leoball@opalsoft.net Thu Sep 19 13:48:12 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Thu, 19 Sep 2002 08:48:12 -0400 Subject: [LARTC] latency simulation In-Reply-To: <20020918163502.29393.97233.Mailman@outpost> Message-ID: <5.1.0.14.1.20020919084615.00a3a300@opalsoft.net> Hi Hannes, You are right. Thank to Stef for the information. I=B4ll take a copy too. Best regards, Leonardo Balliache At 06:35 p.m. 18/09/02 +0200, you wrote: >Message: 5 >Date: Wed, 18 Sep 2002 10:04:36 +0200 >From: Hannes Ebner >To: lartc@mailman.ds9a.nl >Subject: Re: [LARTC] latency simulation > >Hi Leonardo, > > > Have a look to tbf. It has a selectable latency parameter that adjust > > the queue length. http://lartc.org/lartc.txt paragraph 9.2.2. Token > > Bucket Filter can give you more information. > >from the HOWTO: "...the latency parameter, which specifies the maximum >amount of time a packet can sit in the TBF...". > >_Can_ sit in the TBF, not _will_ sit. Therefore it is also possible to >get the packet forwarded with a latency smaller than the one I have >given to the TBF - but I need a method to decrease it to a fixed amount. > >Regards, >Hannes From Xor Thu Sep 19 14:05:26 2002 From: Xor (Xorader Babka) Date: Thu, 19 Sep 2002 17:05:26 +0400 Subject: [LARTC] Collect iproute2 traffic stat Message-ID: <4492918750.20020919170526@transtelecom-nn.ru> Hello lartc-boys, I planed to write script, which collects traffic statistics from 'tc classes' (different server services) and transform this by MRTG (or other...) for web view... And logs, archived in txt files or in DB (MySQL ? ) But i think, that someone made this job,.... May somebody share one's experience or finished scripts for examples ? anyone any ideas ? -- Xor mailto:xor@uic.nnov.ru From lumir.unzeitig@gatc.com Thu Sep 19 14:15:06 2002 From: lumir.unzeitig@gatc.com (Lumir Unzeitig) Date: Thu, 19 Sep 2002 15:15:06 +0200 Subject: [LARTC] "rate" is not in class statistics for htb with imq0 Message-ID: <003801c25fde$92cb2340$6403a8c0@unzeitig> Hi, please, may anybody explain me why real class rate is not appeared in statistics? When I used HTB without imq the "rate" appeared on the line after Sent .. >tc -s class show dev imq0 class htb 1:1 root rate 240Kbit ceil 240Kbit burst 4Kb cburst 1906b Sent 629827678 bytes 1352516 pkts (dropped 0, overlimits 0) lended: 300670 borrowed: 0 giants: 0 tokens: 106880 ctokens: 48506 class htb 1:100 parent 1:1 leaf 1000: prio 0 rate 120Kbit ceil 240Kbit burst 2Kb cburst 1906b Sent 50222321 bytes 195041 pkts (dropped 0, overlimits 0) lended: 195000 borrowed: 41 giants: 0 tokens: 103681 ctokens: 48080 class htb 1:200 parent 1:1 leaf 2000: prio 7 rate 120Kbit ceil 240Kbit burst 2Kb cburst 1906b Sent 579605357 bytes 1157475 pkts (dropped 0, overlimits 0) lended: 856846 borrowed: 300629 giants: 0 tokens: 104533 ctokens: 48506 Thanks Lumir Unzeitig From raptor@tvskat.net Thu Sep 19 21:48:37 2002 From: raptor@tvskat.net (raptor) Date: Thu, 19 Sep 2002 16:48:37 -0400 Subject: [LARTC] [tcng8w] make test errors (mandrake 2.4.19-9mdk) Message-ID: <20020919164837.74f930f7.raptor@tvskat.net> This time errors are real :") tc-htb patch applied... (as specified in the README) tcng-htb patch applied ..... For thouse that don't know... i have made manual review of the mandrake kernel and the latest htb-kernel-patches... and it seems they are in... SO ANYONE USING MANDRAKE SHOULD NOT NEED TO APPLY HTB-KERNEL-PATCHES FOR 2.4.19-9mdk. FYI : after maximum a week Mandrake9.0 will be out (it is with this kernel). ============================================================================== compound construct with assignment: PASSED compound construct with multiple assignments: PASSED compound construct must end with semicolon: PASSED (warning: output differs) Standard output: | :17: syntax error near "}" Reference output: | :1: syntax error near "}" compound construct may end with multiple semicolons: PASSED compound construct requires semicolon after assignment: PASSED (warning: output differs) Standard output: | :17: syntax error near "$x" Reference output: | :1: syntax error near "$x" compound construct allows multiple semicolons after assignment: PASSED compound construct warns about unused variables: FAILED File: tests/compound Command: tcc -c 2>&1 Input: _in.17273 Output: _out.17273 Reference: _ref.17273 scripts/runtests.sh: line 2: 17297 Broken pipe cat scripts/run-all-tests: line 14: 28441 Broken pipe cat $n make: *** [test] Error 1 [root@qos tcng]# cat _in.17273 $a = { $x = 13; 7; }; field foo = raw if $a == $a; [root@qos tcng]# cat _ref.17273 :1: warning: unused variable x [root@qos tcng]# cat _out.17273 :17: warning: unused variable x [root@qos tcng]# From stef.coene@docum.org Thu Sep 19 17:14:32 2002 From: stef.coene@docum.org (Stef Coene) Date: Thu, 19 Sep 2002 18:14:32 +0200 Subject: [LARTC] Collect iproute2 traffic stat In-Reply-To: <4492918750.20020919170526@transtelecom-nn.ru> References: <4492918750.20020919170526@transtelecom-nn.ru> Message-ID: <200209191814.32290.stef.coene@docum.org> On Thursday 19 September 2002 15:05, Xorader Babka wrote: > Hello lartc-boys, > > I planed to write script, which collects traffic statistics from 'tc > classes' (different server services) and transform this by MRTG (or > other...) for web view... And logs, archived in txt files or in DB > (MySQL ? ) > But i think, that someone made this job,.... May somebody share one's > experience or finished scripts for examples ? :) http://home.docum.org/stef.coene/qos/gui/rrd.html But hey, any updates/suggestions are welcome. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From arny@ats.s.bawue.de Thu Sep 19 18:00:48 2002 From: arny@ats.s.bawue.de (Thilo Schulz) Date: Thu, 19 Sep 2002 19:00:48 +0200 Subject: [LARTC] Collect iproute2 traffic stat In-Reply-To: <200209191814.32290.stef.coene@docum.org> References: <4492918750.20020919170526@transtelecom-nn.ru> <200209191814.32290.stef.coene@docum.org> Message-ID: <200209191900.48616.arny@ats.s.bawue.de> I have written a very small and simple C program parsing traffic byte val= ues=20 out of the iptables output, and then storing the values into a MySQL=20 Database. Combined with a PHP webinterface for example you can also generate statis= tics=20 like these ... If anyone wants the source of the small C program, just ask me for it. - Thilo Schulz From wa@almesberger.net Thu Sep 19 19:11:58 2002 From: wa@almesberger.net (Werner Almesberger) Date: Thu, 19 Sep 2002 15:11:58 -0300 Subject: [LARTC] [tcng8w] make test errors (mandrake 2.4.19-9mdk) In-Reply-To: <20020919164837.74f930f7.raptor@tvskat.net>; from raptor@tvskat.net on Thu, Sep 19, 2002 at 04:48:37PM -0400 References: <20020919164837.74f930f7.raptor@tvskat.net> Message-ID: <20020919151158.R1781@almesberger.net> raptor wrote: > This time errors are real :") That weird cpp strikes again. Which CPP version is this anyway ? Does putting #line 0 or #line 1 at the end of tcng/tcc/default.tc help or at least change the output in any way ? (According to the CPP 2.95.3, 3.1.1 and 3.2 docs, #line N should set the line number of the _next_ line to N, but CPP "2.96" (RH) and 3.1 set the line number of the current line, so the next line becomes N+1.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From hanhbnetfilter@yahoo.com.cn Fri Sep 20 03:56:22 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Fri, 20 Sep 2002 10:56:22 +0800 (CST) Subject: [LARTC] the quantity of imq device Message-ID: <20020920025622.46494.qmail@web15201.mail.bjs.yahoo.com> HTB and imq was used to control traffic. modprobe imq numdevs=3 but only imq0 and imq1 can be used; if there are five NICs, please tell me how can I can use imq2 , imq3 and so on. _________________________________________________________ Do You Yahoo!? ÂÏʵ½µ×,ÓéÀÖµ½ĵÒ - ÑĊğ˘ÍĈ³öâ·ÑÓéÀÖµç×ÓÖÜħ¨! http://cn.ent.yahoo.com/newsletter/index.html From wa@almesberger.net Fri Sep 20 04:56:20 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 20 Sep 2002 00:56:20 -0300 Subject: [LARTC] tcng version 8x Message-ID: <20020920005620.A6740@almesberger.net> ... is on SourceForge, http://tcng.sourceforge.net/#src There's a lot of stuff in this one, and there's even more to come. In fact, the change log just got so long that I need to make this release now :-) Highlight: - added Jacob Teplitsky's HTB for tcng - tcsim's attribute handling got a little smarter again - build/cleanup process housekeeping - lots of minor bug fixes The full change log is below. The probably most interesting feature is Jacob's HTB interface for tcng. Thanks, Jacob ! There are still a few things in parameter handling that may change in the next version of tcng, mainly concerning quanta, but besides that, this looks good. See tests/htbng for an example and its translation. The tcsim attribute handling changes are mainly an extension to allow macros like IP_PCK and IP6_PCK to change the protocol, but in such that this doesn't get in the way with explicitly setting the protocol attribute. The gory details are explained in the tcsim documentation (the "send" command), and in tests/tcsattset and tests/tcsattpro There's also one more user-visible change: the "protocol" attribute is now preserved across links in tcsim, because this is also what's likely to happen in real life. Note that I didn't have time yet to resolve the pending issues in protocol-aware classification. - Werner ---------------------------------- cut here ----------------------------------- Version 8x (20-SEP-2002) ------------------------ - tcc: added HTB queuing discipline (tests/htbng, by Jacob Teplitsky) - tcsim no longer resets the "protocol" attribute when traversing a link (tests/tcsattpsv) - tcsim attributes now have two priorities (normal and default, indicated with the keyword "default"), and the global attributes can be set with the command "attributes" (tests/tcsattset) - tcsim: IP_PCK and IP6_PCK now set the "protocol" attribute with "default" priority (tests/tcsattpro) - updated kernel version example in tcng/README from 2.4.18 to 2.4.19 (change log incorrectly stated this had been done already in 8u) - added warning when taking prefix of IPv4 or IPv6 constant instead of field (tests/constpfx, suggested by Jacob Teplitsky) - added warning switch "constpfx" to control above warning (tests/constpfx) - added new make target "immaculate" which also removes pre-built files - tcc/ports.tc is now removed by "immaculate", not "clean" - doc/Makefile can now re-generate EPS files (from FIG) - .depend is now always removed on "spotless", never on "clean" - various other minor "make clean" and "make spotless" corrections (most of them reported by Jacob Teplitsky) - added dummy targets "depend" and "dep" to doc/Makefile - documentation: added section describing parameter propagation rules - tcng/README now lists packages required for building and using tcng (suggested by "raptor") - setup.klib now reverts PSCHED_CLOCK_SOURCE to PSCHED_JIFFIES in case it was changed in the source tree (reported by "raptor") - runtests.sh got confused by END CONDITIONAL followed by BEGIN CONDITIONAL (tests/tstcond) - tcc let various types of "drop on" slip through, crashing it later (tests/dropon) - moved "drop on" test from tests/misfeatures to tests/dropon - tcsim_filter failed to select by device name (tests/tcng-8x) - documentation: -c was missing in "tcsim_filter tos=0xb8" example - tcsim_filter included packet ID in output, although documentation claims it doesn't, which makes more sense (tests/tcng-8x) - tcc failed to refuse element ID zero in "fw" filter (tests/tcng-8x) - updated tests/blocks, tests/cbqzero, tests/extndm, tests/location, tests/misfeatures, tests/newsynmsc, tests/semicolon, tests/tag, tests/tcng-5g, and tests/tcng-6w accordingly - tcsim/packet6.def:IP6_HDR did not initialize $ip6_plen - added pending issues related to protocol selection support to tcng/TODO -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From raptor@tvskat.net Fri Sep 20 16:04:52 2002 From: raptor@tvskat.net (raptor) Date: Fri, 20 Sep 2002 11:04:52 -0400 Subject: [LARTC] [tcng8w] make test errors (mandrake 2.4.19-9mdk) In-Reply-To: <20020919151158.R1781@almesberger.net> References: <20020919164837.74f930f7.raptor@tvskat.net> <20020919151158.R1781@almesberger.net> Message-ID: <20020920110452.3dd7c9f7.raptor@tvskat.net> Werner Almesberger wrote: |raptor wrote: |> This time errors are real :") | |That weird cpp strikes again. Which CPP version is this anyway ? | |Does putting |#line 0 ]- nope.. it seems worst wit it |or |#line 1 ]- definetly helps,.. 'man u have put hell-of-a-tests, no bug can escape :") This time i got up to here... Now I'm going to get 8x :") (i was just going to ask when htb-tcng patch will be in :") ) check syntax of examples-ng/dsmark+policing: PASSED check syntax of examples-ng/ef-prio: PASSED Standard error: | warning: real MTU (guessed 1510) may be larger than 1500 check syntax of examples-ng/gred: PASSED check syntax of examples-ng/ingress: PASSED check syntax of examples-ng/pfifo_fast: PASSED check syntax of examples-ng/prio+fw: PASSED ...................... SLB without MPU (ext) : PASSED SLB with MPU (ext): FAILED File: tests/mpu Command: tcsim | tcsim_filter -c Input: _in.30580 Output: _out.30580 Reference: _ref.30580 scripts/runtests.sh: line 2: 30604 Broken pipe cat scripts/run-all-tests: line 14: 11902 Broken pipe cat $n make: *** [test] Error 1 [root@qos tcng]# [root@qos tcng]# cat _in.30580 dev eth0 10Gbps { egress { /* Note: cbs must be >= mpu */ $p = SLB(cir 500kbps,cbs 3kB,mpu 2500B); class (<>) if SLB_else_drop($p); } } every 0.01s send 0 x 1250 /* 1 Mbps */ time 1s end [root@qos tcng]# cat _out.30580 D 13 E 102 [root@qos tcng]# cat _ref.30580 D 26 E 102 [root@qos tcng]# |at the end of tcng/tcc/default.tc help or at least change the |output in any way ? (According to the CPP 2.95.3, 3.1.1 and |3.2 docs, #line N should set the line number of the _next_ line |to N, but CPP "2.96" (RH) and 3.1 set the line number of the |current line, so the next line becomes N+1.) ]- [root@qos tcng]# cpp -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk) /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/cpp0 -lang-c -v -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__NO_INLINE__ -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ - GNU CPP version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk) (cpplib) (i386 Linux/ELF) ... From sumit@elitecore.com Fri Sep 20 10:18:36 2002 From: sumit@elitecore.com (Sumit Pandya) Date: Fri, 20 Sep 2002 14:48:36 +0530 Subject: [LARTC] Avoid adding fw filter using mark In-Reply-To: <20020917042837.14823.15971.Mailman@outpost> Message-ID: Hi Devik, > I'm happy that HTB gained so much popularity ;) Only > one hint for you - you can completely avoid all these > tc filter add .... fw ... > You can use only one > tc filter add dev ppp0 parent 1: protocol ip prio 1 handle 1 fw When I add above rule I get an error message "RTNETLINK answers: Invalid argument" but I can see above filter inserted with command: # /sbin/tc -s -d -r filter show dev ppp0 output: filter parent 1: protocol ip pref 1 fw Even if that message comming My all rules and policy works fine :-) Can I neglect error message occurs at time of adding filter? > and set classid directly in iptables like: > iptables -t mangle -A to-dsl -p tcp --dport 80 -j MARK --set-mark 0x10010 > iptables -t mangle -A to-dsl -p tcp --sport 24 -j MARK --set-mark 0x10020 > > and so on .. > devik > > > On 17 Apr 2002, alex wrote: > > > /sbin/iptables -t mangle -A to-dsl -p tcp --dport 22 -j MARK > > --set-mark 1 > > > > > And handle 11:111 ? > would become --set-mark 0x00110111... > or 0x110111 Last 4 digits (16bits) is class, firct 16bit is qdisc. -- Sumit From sumit@elitecore.com Fri Sep 20 10:37:21 2002 From: sumit@elitecore.com (Sumit Pandya) Date: Fri, 20 Sep 2002 15:07:21 +0530 Subject: [LARTC] Shaping known application traffic In-Reply-To: <20020917042837.14823.15971.Mailman@outpost> Message-ID: Hi, Many of traffic shaper products provide shaping based on certain application type. How can we implement shaping of recognized application types? Like FTP can take only 64Kbps irrelevant of weather FTP Server is running on port 21 or 4096. Thanks for your suggestions. -- Sumit From druid@mail.cz Fri Sep 20 10:22:37 2002 From: druid@mail.cz (=?iso-8859-2?B?VmxhZGlt7XIgVPhlYmlja/0=?=) Date: Fri, 20 Sep 2002 11:22:37 +0200 Subject: [LARTC] ESFQ debugging Message-ID: <002001c26087$42facf60$4500a8c0@cybernet.cz> Is there any way to see the whole hash table of esfq to debug wheter the chosen hash table type is working correctly? This is my situation: ### ROOT tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell 8 ### CLASS PARENT tc class add dev eth1 parent 1: classid 1:1 cbq bandwidth 10Mbit \ rate 2Mbit weight 200Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 \ isolated ### CLASS PRIORITIES tc class add dev eth1 parent 1:1 classid 1:10 cbq bandwidth 10Mbit \ rate 200Kbit weigth 20Kbit prio 1 allot 1514 cell 8 maxburst 10 avpkt 100 \ isolated tc class add dev eth1 parent 1:1 classid 1:20 cbq bandwidth 10Mbit \ rate 1800Kbit weigth 180Kbit prio 2 allot 1514 cell 8 maxburst 10 avpkt 1500 \ bounded ### SFQ tc qdisc add dev eth1 parent 1:10 handle 10: esfq perturb 10 hash dst tc qdisc add dev eth1 parent 1:20 handle 20: esfq perturb 10 hash dst Plus some iptables -t mangle -A OUTPUT filters that divide traffic to 0:500 (marking as 3 and flowing to 1:10) and 500:1500 (marking as 4 and flowing to 1:20) I have another 2 linux stations. On the first (A) a ran 2 scp's and on the second (B) only 1 scp. The result isn't so definite. The scp on B ended first but in that time the first scp on A had 80% and the second somthing about 70%. In my opinion it should be something like A-100%, B1-50%, B2-50%. Any ideas? ;-) Thank you for any hint :-) -- Vladimir Trebicky From hanhbnetfilter@yahoo.com.cn Fri Sep 20 10:49:22 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Fri, 20 Sep 2002 17:49:22 +0800 (CST) Subject: [LARTC] the quantem of class 10001 is big Message-ID: <20020920094922.26416.qmail@web15202.mail.bjs.yahoo.com> imq and htb are used to control traffic. #tc qdisc add dev imq0 root handle 1: htb default 0 #tc class add dev $IMQDEV parent 1: classid 1:1 htb \ rate 10000kbps ceil 10000kbps burst 15k I get the following messages: HTB quantum of class 1001 is big.consider r2q change <7>htb*g j=4129006 what is the reasonable range of rate ,or I have to set which parameter to set rate up to 10M(even 100M) _________________________________________________________ Do You Yahoo!? ÂÏʵ½µ×,ÓéÀÖµ½ĵÒ - ÑĊğ˘ÍĈ³öâ·ÑÓéÀÖµç×ÓÖÜħ¨! http://cn.ent.yahoo.com/newsletter/index.html From wa@almesberger.net Fri Sep 20 16:04:38 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 20 Sep 2002 12:04:38 -0300 Subject: [LARTC] [tcng8w] make test errors (mandrake 2.4.19-9mdk) In-Reply-To: <20020920110452.3dd7c9f7.raptor@tvskat.net>; from raptor@tvskat.net on Fri, Sep 20, 2002 at 11:04:52AM -0400 References: <20020919164837.74f930f7.raptor@tvskat.net> <20020919151158.R1781@almesberger.net> <20020920110452.3dd7c9f7.raptor@tvskat.net> Message-ID: <20020920120437.Z1781@almesberger.net> raptor wrote: > |#line 1 > ]- definetly helps,.. Finally !! The workaround will be in 8y. > 'man u have put hell-of-a-tests, no bug can escape :") And then, they mutate ... :) > check syntax of examples-ng/ef-prio: PASSED > Standard error: > | warning: real MTU (guessed 1510) may be larger than 1500 Those MTU warnings are normal, although I should probably get rid of them eventually. > SLB without MPU (ext) : PASSED > SLB with MPU (ext): FAILED Hmm, that one is a bit surprising ... can you please try the test with the following changes: | $p = SLB(cir 500kbps,cbs 3kB); ---------- (mpu removed) | every 0.01s send 0 x 2500 /* 1 Mbps */ ---- (2500 instead of 1250) > GNU CPP version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk) Looks like the same version of cpp as used by Red Hat. Odd ... - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From Allang@equation.co.za Fri Sep 20 16:47:08 2002 From: Allang@equation.co.za (Allan Gee) Date: Fri, 20 Sep 2002 17:47:08 +0200 Subject: [LARTC] u32 filter question Message-ID: <000201c260bc$fb2acec0$0eb2a8c0@equation.co.za> SGkgZ3V5cyBJIGhhdmUgYSBjb25maWcgYXMgZm9sbG93cyBmb3Igb25lIG9mIG15IG5ldHdvcmtz LiBJIHdhbnQgdG8gZ2l2ZSB0aGUgeHh4Lnh4eC54eHgueHh4L3h4IG5ldHdvcmsgNjRrYml0IGZv ciBldmVyeXRoaW5nIGZyb20gdGhlIGludGVybmV0IGJ1dCA4MDAwa2JpdCBmcm9tIG91ciBpbnRl cm5hbCBzZXJ2ZXJzIG9uIHl5eS55eXkueXl5Lnl5eS95eSBuZXR3b3JrLiBJdCBkb2VzIG5vdCB3 b3JrLiBJIG9ubHkgd2FudCB0byB1c2UgdTMyIGZpbHRlcnMuIEkgdGhpbmsgd2hhdCdzIGhhcHBl bmluZyBpcyB0aGUgZmlyc3QgZmxvd2lkIG9mIDE6MjEgaXMgY2F0Y2hpbmcgdGhlbSBhbmQgbm90 IGdldHRpbmcgdG8gdGhlIDE6NDAgZmxvd2lkLiBJcyB0aGlzIHJpZ2h0PyBUaGUgYm94IGhhcyB0 byBiZSBiZXR3ZWVuIHRoZSB4IG5ldHdvcmsgYW5kIHRoZSB5IG5ldHdvcmsuDQoNCg0KdGMgcWRp c2MgZGVsIGRldiBldGgxIHJvb3QgaGFuZGxlIDE6IGh0YiBkZWZhdWx0IDk5OSANCnRjIHFkaXNj IGFkZCBkZXYgZXRoMSByb290IGhhbmRsZSAxOiBodGIgZGVmYXVsdCA5OTkgDQp0YyBjbGFzcyBh ZGQgZGV2IGV0aDEgcGFyZW50IDE6IGNsYXNzaWQgMToxIGh0YiByYXRlIDEwMDAwa2JpdCANCnRj IGNsYXNzIGFkZCBkZXYgZXRoMSBwYXJlbnQgMToxIGNsYXNzaWQgMTo5OTkgaHRiIHJhdGUgMTAw MGtiaXQgY2VpbCAxMDAwMGtiaXQgDQp0YyBxZGlzYyBhZGQgZGV2IGV0aDEgcGFyZW50IDE6OTk5 IGhhbmRsZSAxOTk5OiBzZnEgcGVydHVyYiAxMCANCnRjIGNsYXNzIGFkZCBkZXYgZXRoMSBwYXJl bnQgMToxIGNsYXNzaWQgMToyIGh0YiByYXRlIDEwMDAwa2JpdCBxdWFudHVtIDE1MTQgDQp0YyBj bGFzcyBhZGQgZGV2IGV0aDEgcGFyZW50IDE6MiBjbGFzc2lkIDE6MjEgaHRiIHJhdGUgNjRrYml0 IGNlaWwgNjRrYml0IHF1YW50dW0gMTUxNCANCnRjIGNsYXNzIGFkZCBkZXYgZXRoMSBwYXJlbnQg MToyIGNsYXNzaWQgMTo0MCBodGIgcmF0ZSA4MDAwa2JpdCBjZWlsIDgwMDBrYml0IHF1YW50dW0g NzU3MDAwIA0KdGMgcWRpc2MgYWRkIGRldiBldGgxIHBhcmVudCAxOjIxIGhhbmRsZSAyMTAwOiBz ZnEgcGVydHVyYiAxMCANCnRjIHFkaXNjIGFkZCBkZXYgZXRoMSBwYXJlbnQgMTo0MCBoYW5kbGUg NDAwMDogc2ZxIHBlcnR1cmIgMTAgDQp0YyBmaWx0ZXIgYWRkIGRldiBldGgxIHByb3RvY29sIGlw IHBhcmVudCAxOjAgcHJpbyAxIHUzMiBtYXRjaCBpcCBkc3QgeHh4Lnh4eC54eHgueHh4Lnh4IGZs b3dpZCAxOjIxIA0KdGMgZmlsdGVyIGFkZCBkZXYgZXRoMSBwcm90b2NvbCBpcCBwYXJlbnQgMTow IHByaW8gMSB1MzIgbWF0Y2ggaXAgc3JjIHl5eS55eXkueXl5Lnl5eS95eSBtYXRjaCBpcCBkc3Qg eHh4Lnh4eC54eHgueHh4L3h4IGZsb3dpZCAxOjQwIA0KDQoNClJlZ2FyZHMgQWxsYW4gR2VlDQpF cXVhdGlvbg0KMDIxIDQxODE3NzcNCnd3dy5lcXVhdGlvbi5jby56YQ0K From tobias.geiger@web.de Fri Sep 20 18:23:50 2002 From: tobias.geiger@web.de ( Tobias Geiger) Date: Fri, 20 Sep 2002 19:23:50 +0200 (CEST) Subject: [LARTC] u32 filter question In-Reply-To: <000201c260bc$fb2acec0$0eb2a8c0@equation.co.za> References: <000201c260bc$fb2acec0$0eb2a8c0@equation.co.za> Message-ID: <50820.212.2.37.233.1032542630.squirrel@kaeptnb.d2g.com> Hi, try to give the more specific filter a higher prio. if i understood "tc filter" right, the filters with higher prio are checked first. in you're setup giving the last filter line "prio 0" should do the job. > Hi guys I have a config as follows for one of my networks. I want to > give the xxx.xxx.xxx.xxx/xx network 64kbit for everything from the > internet but 8000kbit from our internal servers on yyy.yyy.yyy.yyy/yy > network. It does not work. I only want to use u32 filters. I think > what's happening is the first flowid of 1:21 is catching them and not > getting to the 1:40 flowid. Is this right? The box has to be between the > x network and the y network. > > tc qdisc del dev eth1 root handle 1: htb default 999 > tc qdisc add dev eth1 root handle 1: htb default 999 > tc class add dev eth1 parent 1: classid 1:1 htb rate 10000kbit > tc class add dev eth1 parent 1:1 classid 1:999 htb rate 1000kbit ceil > 10000kbit tc qdisc add dev eth1 parent 1:999 handle 1999: sfq perturb > 10 > tc class add dev eth1 parent 1:1 classid 1:2 htb rate 10000kbit quantum > 1514 tc class add dev eth1 parent 1:2 classid 1:21 htb rate 64kbit > ceil 64kbit quantum 1514 tc class add dev eth1 parent 1:2 classid 1:40 > htb rate 8000kbit ceil 8000kbit quantum 757000 tc qdisc add dev eth1 > parent 1:21 handle 2100: sfq perturb 10 > tc qdisc add dev eth1 parent 1:40 handle 4000: sfq perturb 10 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst > xxx.xxx.xxx.xxx.xx flowid 1:21 tc filter add dev eth1 protocol ip > parent 1:0 prio 1 u32 match ip src yyy.yyy.yyy.yyy/yy match ip dst > xxx.xxx.xxx.xxx/xx flowid 1:40 > > Regards Allan Gee > Equation > 021 4181777 > www.equation.co.za > ,S 隊X§ƒéb²ßżĝ°L)šŠYšÛ=jyaĥÚŝf˘–f§vÏZž_ĉj)fjċŠËbú?•ŞísáÎY3†Ûi˙ùZ×( From stef.coene@docum.org Fri Sep 20 18:34:02 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 20 Sep 2002 19:34:02 +0200 Subject: [LARTC] u32 filter question In-Reply-To: <50820.212.2.37.233.1032542630.squirrel@kaeptnb.d2g.com> References: <000201c260bc$fb2acec0$0eb2a8c0@equation.co.za> <50820.212.2.37.233.1032542630.squirrel@kaeptnb.d2g.com> Message-ID: <200209201934.02348.stef.coene@docum.org> On Friday 20 September 2002 19:23, Tobias Geiger wrote: > Hi, > > try to give the more specific filter a higher prio. if i understood "tc > filter" right, the filters with higher prio are checked first. But that's only for filters with the same parent. So it will work in thi= s=20 case. Or you enter the filters in the order they have to be checked : tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src=20 yyy.yyy.yyy.yyy/yy match ip dst xxx.xxx.xxx.xxx/xx flowid 1:40=20 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst=20 xxx.xxx.xxx.xxx.xx flowid 1:21=20 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Fri Sep 20 18:36:18 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 20 Sep 2002 19:36:18 +0200 Subject: [LARTC] the quantem of class 10001 is big In-Reply-To: <20020920094922.26416.qmail@web15202.mail.bjs.yahoo.com> References: <20020920094922.26416.qmail@web15202.mail.bjs.yahoo.com> Message-ID: <200209201936.18959.stef.coene@docum.org> On Friday 20 September 2002 11:49, hanhbnetfilter wrote: > imq and htb are used to control traffic. > #tc qdisc add dev imq0 root handle 1: htb default 0 > #tc class add dev $IMQDEV parent 1: classid 1:1 htb \ > rate 10000kbps ceil 10000kbps burst 15k > > I get the following messages: > HTB quantum of class 1001 is big.consider r2q change > <7>htb*g j=3D4129006 > what is the reasonable range of rate ,or I have to set > which parameter to set rate up to 10M(even 100M) If you want more info about quantum, checkout the faq page on www.docum.o= rg. =20 1500 < quantum =3D rate / r2q (=3D10) < 60.000 - r2q can be overruled when you add the cbq qdisc - quantum can be overruled when you add the cvq class Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Fri Sep 20 18:39:04 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 20 Sep 2002 19:39:04 +0200 Subject: [LARTC] Shaping known application traffic In-Reply-To: References: Message-ID: <200209201939.04144.stef.coene@docum.org> On Friday 20 September 2002 11:37, Sumit Pandya wrote: > Hi, > =09Many of traffic shaper products provide shaping based on certain > application type. How can we implement shaping of recognized applicatio= n > types? Like FTP can take only 64Kbps irrelevant of weather FTP Server i= s > running on port 21 or 4096. > =09Thanks for your suggestions. Maybe you can try to mark the ftp packets with iptables and use the mark = to=20 shape. There is already a iptables option that matches ftp-data packets.= I=20 think it's easier to change iptables so you can mark certain data types. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Fri Sep 20 18:39:46 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 20 Sep 2002 19:39:46 +0200 Subject: [LARTC] Avoid adding fw filter using mark In-Reply-To: References: Message-ID: <200209201939.46045.stef.coene@docum.org> On Friday 20 September 2002 11:18, Sumit Pandya wrote: > Hi Devik, > > > I'm happy that HTB gained so much popularity ;) Only > > one hint for you - you can completely avoid all these > > tc filter add .... fw ... > > You can use only one > > tc filter add dev ppp0 parent 1: protocol ip prio 1 handle 1 fw > > =09When I add above rule I get an error message "RTNETLINK answers: Inv= alid > argument" > but I can see above filter inserted with command: > =09# /sbin/tc -s -d -r filter show dev ppp0 > =09output: filter parent 1: protocol ip pref 1 fw > =09Even if that message comming My all rules and policy works fine :-) = Can I > neglect error message occurs at time of adding filter? If it works, yes ;) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Fri Sep 20 18:40:44 2002 From: stef.coene@docum.org (Stef Coene) Date: Fri, 20 Sep 2002 19:40:44 +0200 Subject: [LARTC] the quantity of imq device In-Reply-To: <20020920025622.46494.qmail@web15201.mail.bjs.yahoo.com> References: <20020920025622.46494.qmail@web15201.mail.bjs.yahoo.com> Message-ID: <200209201940.44875.stef.coene@docum.org> On Friday 20 September 2002 04:56, hanhbnetfilter wrote: > HTB and imq was used to control traffic. > modprobe imq numdevs=3D3 > but only imq0 and imq1 can be used; > if there are five NICs, please tell me how can I can > use imq2 , imq3 > and so on. You did the modprobe the way you have to. I never tried it myself, maybe= you=20 can mail the author and post a bug-report. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From p0wer@tl.krakow.pl Fri Sep 20 20:03:10 2002 From: p0wer@tl.krakow.pl (=?iso-8859-2?Q?Rados=B3aw_=A3oboda?=) Date: Fri, 20 Sep 2002 21:03:10 +0200 (CEST) Subject: [LARTC] possible performance issues Message-ID: Hi. I'm wondering how much CPU power does a 500-entries FORWARD table with different filters and some qdiscs take. What CPU is required for 10Mbit shaping? Thanks. -- ########################################## # | p0wer | # # __ | GG#1877248 | # # (oo) | p0wer@bojko.eu.org | # # / \/ \ Go away or I will replace you # # `V__V' with a very small shell script. # ########################################## From tw@eter.tym.pl Fri Sep 20 20:19:38 2002 From: tw@eter.tym.pl (Tomasz Wrona) Date: Fri, 20 Sep 2002 21:19:38 +0200 (CEST) Subject: [LARTC] possible performance issues In-Reply-To: Message-ID: Cze=B6=E6, On Fri, 20 Sep 2002, Rados=B3aw =A3oboda wrote: > I'm wondering how much CPU power does a 500-entries FORWARD table with > different filters and some qdiscs take. What CPU is required for 10Mbit > shaping? iptables with over 1300 rules [up to 8000 conntrack entries] divided into different chains + extensive traffic shaping done for three independant lines take 5-6% [up to 10] of Celeron 1GHz CPU power. Earlier on Cel 300MHz up to 20% Pozdro tw --=20 ---------------- ck.eter.tym.pl "Never let shooling disturb Your education" From mr_alavi@yahoo.com Fri Sep 20 21:53:11 2002 From: mr_alavi@yahoo.com (Reza Alavi) Date: Fri, 20 Sep 2002 13:53:11 -0700 (PDT) Subject: [LARTC] Netfilter API -Kylix In-Reply-To: <20020920192202.18527.25009.Mailman@outpost> Message-ID: <20020920205311.19997.qmail@web13303.mail.yahoo.com> Dear Friends, Does anyone know any kylix source which use netfilter API? what about some "simple" C examples? (I have seen libiptq man page ;) ) I want to write a program (with kylix if it is possible)to monitor the traffic of an IP address and whenever its credit is over (which will be calculated againts the traffic) simply reject any traffic to/from that IP, any idea or clue ? Thanks in advance. __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From mabrown-lartc@securepipe.com Sat Sep 21 00:36:36 2002 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Fri, 20 Sep 2002 18:36:36 -0500 (CDT) Subject: [LARTC] ANNOUNCE: guide to linux IP; basics through iproute2/LARTC topics Message-ID: Hello all, I have been working on a guide to IP networking with linux for some time now, and have been putting off announcing this project for no good reason. A colleague has suggested that I might benefit from following the open source credo, (release early, release often). In this spirit, let me state that the document is still only draft quality, and I would welcome contributions, suggestions and feedback. I am announcing my: Guide to IP Layer Network Administration with Linux http://plorf.net/linux-ip/ This is intended to be a companion guide and HOWTO for simple host networking configuration to complex multi-link routers. I have spent my recent efforts providing examples and English descriptions of many of the iproute2 tools and other common command line utilities used in IP networking. This is meant to be an adjunct and companion to the existing documentation such as ip-cref.ps and man pages for the other command line tools. Currently the majority of the content is in the appendices covering the most common types of operations performed with command line tools and utilities. I look forward to any criticism, feedback or suggestions from anybody. Thanks in advance for any time you may spend looking at this work. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From wa@almesberger.net Sat Sep 21 04:35:06 2002 From: wa@almesberger.net (Werner Almesberger) Date: Sat, 21 Sep 2002 00:35:06 -0300 Subject: [LARTC] tc/htb still hangs system - ksymoops traced. In-Reply-To: ; from tw@eter.tym.pl on Thu, Sep 19, 2002 at 11:52:48AM +0200 References: <20020918213539.P1781@almesberger.net> Message-ID: <20020921003506.E1781@almesberger.net> Tomasz Wrona wrote: > OK, I retyped screenshot and put it to ksymoops and it said: > [Will it be enough info to debug, what can I do also ?] I guess Martin could figure it out from this. I'm too lazy ;-) But it would be interesting to see whether this problem also shows up in tcsim (then, it should be easy to diagnose it completely). You seem to have a sequence of configuration commands that reliably cause this crash, right ? If yes, it would be good if you could send them. Also, do you know what happens at the time of the crash ? Is this simply the first packet that hits HTB after some change, or is this a packet with special characteristics ? (Specific flow, etc.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From wa@almesberger.net Sat Sep 21 04:39:59 2002 From: wa@almesberger.net (Werner Almesberger) Date: Sat, 21 Sep 2002 00:39:59 -0300 Subject: [LARTC] tcng version 8y Message-ID: <20020921003959.A822@almesberger.net> ... is on SourceForge, http://tcng.sourceforge.net/#src The main changes are that tcng's HTB is now better at quantum handling, and that tcsim now includes packet.def and ports.tc automatically (via the new default.tcsim), like tcc uses default.tc. The full change log is below, as usual. The HTB change adds a very natural way for expressing a quantum: instead of the somewhat obscure r2q, the quantum can be specified as the time during which the class may monopolize the link. The following two examples are equivalent: htb { class (rate 1Mbps,quantum 1250B); } htb { class (rate 1Mbps,quantum 10ms); } A larger example for HTB with tcng is at the end of tests/htbng I still owe you the completion of protocol-aware classification. Well, next week :-) - Werner ---------------------------------- cut here ----------------------------------- Version 8y (21-SEP-2002) ------------------------ - HTB quantum can now be specified in bytes or seconds (tests/htbquant) - documented various parameter handling differences between tcng and tc - added first example from HTB documentation to tests/htbng - tcsim now uses default.tcsim to automatically include packet.def and ports.tc, similar to how tcc uses default.tc (tests/tcsdefinc) - tcsim: added option -n to disable inclusion of default.tcsim (tests/tcsdefinc) - updated tests/cbqroot, tests/cpp31, tests/defcbq, tests/defdsm, tests/ext, tests/idiomatic, tests/tcng-2j, tests/tcng-3i, tests/tcng-3t, tests/tcng-4n, and tests/trace to either invoke tcsim with -n, or to avoid using ip.def - removed use of ip.def from all examples (examples/*, examples-ng/*) - tcc/defaults.tc now resets the line number in order to work around strange cpps that embed -included file instead of including it, causing line numbers to be off by the length of the -included file (reported by "raptor") - tcsim now stops SFQ and HTB timers at end (tests/tcstimstp) - updated examples/sfq and examples-ng/sfq accordingly - moved helper functions alloc, alloc_t, stralloc, and alloc_sprintf to tcng/shared/memutil.* - added %c format to alloc_sprintf - removed potential buffer overruns in tcsim/module.c and tcsim/cfg.l by using alloc_sprintf - tcc did not complain when specifying "limit" in bytes and in packets for FIFO qdisc (tests/tcng-8y) - added awk to build prerequisites -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From jacobt@bivio.net Sat Sep 21 19:03:31 2002 From: jacobt@bivio.net (Jacob Teplitsky) Date: Sat, 21 Sep 2002 11:03:31 -0700 (PDT) Subject: [LARTC] tcng version 8y Message-ID: <200209211803.g8LI3VX32172@stimpy.bivio.net> > > Message: 4 > Date: Sat, 21 Sep 2002 00:39:59 -0300 > From: Werner Almesberger > To: lartc@mailman.ds9a.nl > Subject: [LARTC] tcng version 8y > > ... is on SourceForge, http://tcng.sourceforge.net/#src > > The main changes are that tcng's HTB is now better at quantum > handling, and that tcsim now includes packet.def and ports.tc > automatically (via the new default.tcsim), like tcc uses > default.tc. The full change log is below, as usual. > > The HTB change adds a very natural way for expressing a quantum: > instead of the somewhat obscure r2q, I think this statement requires a little more explanation. > the quantum can be specified > as the time during which the class may monopolize the link. > > The following two examples are equivalent: > > htb { > class (rate 1Mbps,quantum 1250B); > } > > htb { > class (rate 1Mbps,quantum 10ms); > } > According to http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm ====================== It might be good time to touch concept of quantums now. In fact when more classes want to borrow bandwidth they are each given some number of bytes before serving other competing class. This number is called quantum. You should see that if several classes are competing for parent's bandwidth then they get it in proportion of their quantums. It is important to know that for precise operation quantums need to be as small as possible and larger than MTU. Normaly you don't need to specify quantums manualy as HTB chooses precomputed values. It computes classe's quantum (when you add or change it) as its rate divided by r2q global parameter. Its default value is 10 and because typical MTU is 1500 the default is good for rates from 15 kBps (120 kbit). For smaller minimal rates specify r2q 1 when creating qdisc - it is good from 12 kbit which should be enough. If you will need you can specify quantum manualy when adding or changing the class. You can avoid warnings in log if precomputed value would be bad. When you specify quantum on command line the r2q is ignored for that class. ====================== This is how tcng replaces a global parameter r2q with quantums : Tcc allows inheritance of paramers so the following htb (quantum 1250B) { class (rate 1Mbps); class (rate 2Mbps); } will have the same effect as: htb () { class (rate 1Mbps, quantum 1250B); class (rate 2Mbps, quantum 1250B); } So, in a way every parameter is "global". If time is specified instead of bytes: htb (quantum 10ms) { class (rate 1Mbps); class (rate 2Mbps); } tcc will calculate the quantum for each class based it's rate and it's time quantum inherited from the "global" time quantum. - Jacob From 69link@telia.com Sun Sep 22 09:16:24 2002 From: 69link@telia.com (Jonas Lindqvist) Date: Sun, 22 Sep 2002 10:16:24 +0200 Subject: [LARTC] txqueuelen in ifconfig and tc Message-ID: <014b01c26210$57cd8240$0b00a8c0@mindblower> This is a multi-part message in MIME format. ------=_NextPart_000_0148_01C26221.1B20EA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, when reading "man ifconfig" it says the following: " txqueuelen length Set the length of the transmit queue of the device. It is useful to set = this to small values for slower devices with a high latency (modem = links, ISDN) to prevent fast bulk transfers from dis=ADturbing = interactive traffic like telnet too much." This seems to normally be 100 (packets i guess?) Is this queue affected by tc or is it after all shaping? I wonder this because im doing the Wondershaper ACK-priority thing, but = people with a small windowsize is still affected very much by not = recieving their ACK fast enough on my system. Any ideas anyone? Regards Jonas ------=_NextPart_000_0148_01C26221.1B20EA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there,
 
when reading "man ifconfig" it says the = following:
" txqueuelen length
Set the length = of the=20 transmit queue of the device. It is useful to set this to small = values  for=20 slower  devices  with a high latency (modem links, ISDN) to = prevent=20 fast bulk transfers from dis­turbing interactive traffic like telnet = too=20 much."
 
This seems to normally be 100 (packets = i=20 guess?)
 
Is this queue affected by tc or is it = after all=20 shaping?
 
I wonder this because im doing the = Wondershaper=20 ACK-priority thing, but people with a small windowsize is still affected = very=20 much by not recieving their ACK fast enough on my system.
 
Any ideas anyone?
 
Regards
Jonas
------=_NextPart_000_0148_01C26221.1B20EA60-- From wa@almesberger.net Sun Sep 22 16:49:22 2002 From: wa@almesberger.net (Werner Almesberger) Date: Sun, 22 Sep 2002 12:49:22 -0300 Subject: [LARTC] txqueuelen in ifconfig and tc In-Reply-To: <014b01c26210$57cd8240$0b00a8c0@mindblower>; from 69link@telia.com on Sun, Sep 22, 2002 at 10:16:24AM +0200 References: <014b01c26210$57cd8240$0b00a8c0@mindblower> Message-ID: <20020922124922.H1781@almesberger.net> Jonas Lindqvist wrote: > Is this queue affected by tc or is it after all shaping? tx_queue_len provides default values for the queue size in all FIFO qdiscs, and an in unconfigured GRED (which acts just as a pfifo)), In HTB, it sets the limit of the queue of class qdisc:0, so it affects traffic that doesn't get shaped. In any case, any additional queuing after traffic control is at the discretion of the network interface driver, and not affected by tx_queue_len. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From snowie@klippanlan.net Mon Sep 23 00:16:07 2002 From: snowie@klippanlan.net (Kristoffer Ottosson) Date: Mon, 23 Sep 2002 01:16:07 +0200 Subject: [LARTC] wondershaper problem Message-ID: <002b01c2628e$07c4a0c0$640aa8c0@merkurius> This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C2629E.CB4162D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have two lucent wlancards and one 3com ethernet card running on my = box. I'm running routing tables with iproute2 in order to route all the = packets correctly ... Now I wonder, I should be able to use wondershaper = on top of this, right? When I try to run wondershaper, it does nothing, and gives me lots of = error messages ...=20 The beginning of them are quoted here (output with -x activated in the = beginning of the script): + DOWNLINK=3D1024 + UPLINK=3D1024 + DEV=3Deth1 + NOPRIOHOSTSRC=3D80 + NOPRIOHOSTDST=3D + NOPRIOPORTSRC=3D + NOPRIOPORTDST=3D + '[' '' =3D status ']' + tc qdisc del dev eth1 root + tc qdisc del dev eth1 ingress + '[' '' =3D stop ']' + tc qdisc add dev eth1 root handle 1: cbq avpkt 1000 bandwidth 10mbit RTNETLINK answers: Invalid argument + tc class add dev eth1 parent 1: classid 1:1 cbq rate 1024kbit allot = 1500 prio 5 bounded isolated RTNETLINK answers: Invalid argument + tc class add dev eth1 parent 1:1 classid 1:10 cbq rate 1024kbit allot = 1600 prio 1 avpkt 1000 RTNETLINK answers: Invalid argument + tc class add dev eth1 parent 1:1 classid 1:20 cbq rate 921kbit allot = 1600 prio 2 avpkt 1000 RTNETLINK answers: Invalid argument + tc class add dev eth1 parent 1:1 classid 1:30 cbq rate 819kbit allot = 1600 prio 2 avpkt 1000 RTNETLINK answers: Invalid argument and so it continues on every single command-line wondershaper tried to = type in. anybody have a clue, I would be grateful /Snowi3 ------=_NextPart_000_0028_01C2629E.CB4162D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I have two lucent wlancards and one = 3com ethernet=20 card running on my box.
I'm running routing tables with = iproute2 in order=20 to route all the packets correctly ... Now I wonder, I should be able to = use=20 wondershaper on top of this, right?
 
When I try to run wondershaper, it does = nothing,=20 and gives me lots of error messages ...
The beginning of them are quoted here = (output with=20 -x activated in the beginning of the script):
+ DOWNLINK=3D1024
+ = UPLINK=3D1024
+ DEV=3Deth1
+=20 NOPRIOHOSTSRC=3D80
+ NOPRIOHOSTDST=3D
+ NOPRIOPORTSRC=3D
+=20 NOPRIOPORTDST=3D
+ '[' '' =3D status ']'
+ tc qdisc del dev eth1 = root
+ tc=20 qdisc del dev eth1 ingress
+ '[' '' =3D stop ']'
+ tc qdisc add = dev eth1=20 root handle 1: cbq avpkt 1000 bandwidth 10mbit
RTNETLINK answers: = Invalid=20 argument
+ tc class add dev eth1 parent 1: classid 1:1 cbq rate = 1024kbit=20 allot 1500 prio 5 bounded isolated
RTNETLINK answers: Invalid = argument
+=20 tc class add dev eth1 parent 1:1 classid 1:10 cbq rate 1024kbit allot = 1600 prio=20 1 avpkt 1000
RTNETLINK answers: Invalid argument
+ tc class add = dev eth1=20 parent 1:1 classid 1:20 cbq rate 921kbit allot 1600 prio 2 avpkt=20 1000
RTNETLINK answers: Invalid argument
+ tc class add dev eth1 = parent=20 1:1 classid 1:30 cbq rate 819kbit allot 1600 prio 2 avpkt = 1000
RTNETLINK=20 answers: Invalid argument
and so it continues on every single = command-line=20 wondershaper tried to type in.
anybody have a clue, I would be=20 grateful
 
/Snowi3
------=_NextPart_000_0028_01C2629E.CB4162D0-- From leoball@opalsoft.net Mon Sep 23 01:44:32 2002 From: leoball@opalsoft.net (Leonardo Balliache) Date: Sun, 22 Sep 2002 20:44:32 -0400 Subject: [LARTC] Netfilter API -Kylix In-Reply-To: <20020921042900.27516.73231.Mailman@outpost> Message-ID: <5.1.0.14.1.20020922204027.00a42ec0@opalsoft.net> Hi, I wrote http://tldp.org/HOWTO/Querying-libiptc-HOWTO/ published by The=20 Linux Document Project. It=B4s very simple C program. Hoping this can help you. Best regards, Leonardo Balliache At 06:29 a.m. 21/09/02 +0200, you wrote: >Message: 1 >Date: Fri, 20 Sep 2002 13:53:11 -0700 (PDT) >From: Reza Alavi >To: lartc@mailman.ds9a.nl >Subject: [LARTC] Netfilter API -Kylix > >Dear Friends, >Does anyone know any kylix source which use netfilter >API? >what about some "simple" C examples? >(I have seen libiptq man page ;) ) > >I want to write a program (with kylix if it is >possible)to monitor the traffic of an IP address and >whenever its credit is over (which will be calculated >againts the traffic) simply reject any traffic to/from >that IP, any idea or clue ? > >Thanks in advance. From Allang@equation.co.za Mon Sep 23 09:41:49 2002 From: Allang@equation.co.za (Allan Gee) Date: Mon, 23 Sep 2002 10:41:49 +0200 Subject: [LARTC] RE:u32 filters and compression Message-ID: <000901c262dd$0fcd4340$0eb2a8c0@equation.co.za> VGhhbmtzOg0KVG8gU3RlZiBhbmQgVG9iaWFzIEdlaWdlciBmb3IgZ2l2aW5nIG1lIHRoZSBhbnN3 ZXIuIEkgdXNlZCB0aGUgcHJpbyB0byBnZXQgdGhlIG9yZGVyIHJpZ2h0LiBEb24ndCBrbm93IHdo eSBJIGRpZCdudCB0aGluayBvZiBpdCBteXNlbGYuDQpDb21wcmVzc2lvbjoNCkFub3RoZXIgdGhp bmcgdGhhdCBtaWdodCBiZSB1c2VmdWwgdG8gdGhlIGxpc3QgaXMgdGhlIHVzZSBvZiBjb21wcmVz c2lvbiAoRGVmbGF0ZSBldGMuKSB0byBnZXQgYmV0dGVyIGJhbmR3aWR0aCBhY3Jvc3MgbGlua3Mu IFRoaXMgcmVxdWlyZXMgYSBMaW51eCByb3V0ZXIgYXQgYm90aCBlbmRzIG9mIHRoZSBsaW5rLiBJ IGdvdCB0aGUgaWRlYSBmcm9tIGEgcHJvZHVjdCBjYWxsZWQgUGVyaWJpdCBzZWUgd3d3LnBlcmli aXQuY29tICggYW5kIG1haW5seSBmcm9tIE1hcnRpbiBEZXZlcmEgd2hvIHBvaW50ZWQgb3V0IHRv IG1lIHRoYXQgTGludXggZG9lcyBjb21wcmVzc2lvbiBhbHJlYWR5IHdpdGggcHBwLiApIEkgaGF2 ZSBub3cgc3RhcnRlZCB0byB3b3JrIG9uIGdldHRpbmcgY29tcHJlc3Npb24gYnVpbHQgaW50byBt eSB0cmFmZmljIHNoYXBpbmcvcm91dGVyIHByb2R1Y3RzIHRoYXQgYXJlIExpbnV4IGJhc2VkLiBQ dXR0aW5nIHRoYXQgaW4gcGxhY2Ugb2YgQ2lzY28gc2hvdWxkIGJlIGEgbXVjaCBiZXR0ZXIvY2hl YXBlciBzb2x1dGlvbiBkbyB5b3Ugbm90IHRoaW5rPyBPbmUgY291bGQgZXZlbiBzaGFwZSB0aGUg cG9ydCB0aGF0IHRoZSBwcHBvZSBydW5zIG9uLiBJIGhhdmUgbG9va2VkIGF0IFplYmVkZWUgd2hp Y2ggYWxzbyBoYXMgYSBzb2x1dGlvbiBmb3IgIldpbmRvd3MiIGJveGVzLiBBbnl3YXkgSSd2ZSBq dXN0IHN0YXJ0ZWQgdG8gZG8gdGhpcyBhbmQgSWYgYW55b25lIGlzIGludGVyZXN0ZWQgSSB3aWxs IGxldCB5b3Uga25vdyB0aGUgb3V0Y29tZS4NCg0KUmVnYXJkcyBBbGxhbiBHZWUNCkVxdWF0aW9u DQowMjEgNDE4MTc3Nw0Kd3d3LmVxdWF0aW9uLmNvLnphDQo= From stef.coene@docum.org Tue Sep 24 14:05:40 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 24 Sep 2002 15:05:40 +0200 Subject: [LARTC] wondershaper problem In-Reply-To: <002b01c2628e$07c4a0c0$640aa8c0@merkurius> References: <002b01c2628e$07c4a0c0$640aa8c0@merkurius> Message-ID: <200209241505.40595.stef.coene@docum.org> On Monday 23 September 2002 01:16, Kristoffer Ottosson wrote: > Hi > > I have two lucent wlancards and one 3com ethernet card running on my bo= x. > I'm running routing tables with iproute2 in order to route all the pack= ets > correctly ... Now I wonder, I should be able to use wondershaper on top= of > this, right? Are you sure you have all the needed options in the kernel? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From rmocius@auste.elnet.lt Tue Sep 24 15:12:30 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 24 Sep 2002 15:12:30 +0100 Subject: [LARTC] HTB Message-ID: <00f101c263d4$6cc806a0$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C263DC.CD186C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, How to put HTB in to 2.4 kernel? Thanks in advance Rimas ------=_NextPart_000_00EE_01C263DC.CD186C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi guys,
 
How to put HTB in to 2.4 = kernel?
 
 
Thanks in advance
 
Rimas
 
------=_NextPart_000_00EE_01C263DC.CD186C40-- From rmocius@auste.elnet.lt Tue Sep 24 15:12:30 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 24 Sep 2002 15:12:30 +0100 Subject: [LARTC] HTB Message-ID: <00f101c263d4$6cc806a0$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C263DC.CD186C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, How to put HTB in to 2.4 kernel? Thanks in advance Rimas ------=_NextPart_000_00EE_01C263DC.CD186C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi guys,
 
How to put HTB in to 2.4 = kernel?
 
 
Thanks in advance
 
Rimas
 
------=_NextPart_000_00EE_01C263DC.CD186C40-- From m.c.p@gmx.net Tue Sep 24 15:17:33 2002 From: m.c.p@gmx.net (Marc-Christian Petersen) Date: Tue, 24 Sep 2002 16:17:33 +0200 Subject: [LARTC] HTB In-Reply-To: <00f101c263d4$6cc806a0$6e69690a@rimas> References: <00f101c263d4$6cc806a0$6e69690a@rimas> Message-ID: <200209241615.03204.m.c.p@gmx.net> On Tuesday 24 September 2002 16:12, Rimas wrote: Hi Rimas, > How to put HTB in to 2.4 kernel? patching? :) If you wanna try 3.6 code, download the tgz, untargzip it (tar xzpf) and=20 you'll see a diff/patch. Just "patch -p1 --dry-run < patchname" and see i= f it=20 succeed, if, leave out --dry-run, if not, fix the errors. If you have=20 questions when errors occur, don't hesitate to ask. for HTB2 code, just download the patch and follow the same as above (patc= h -p1=20 =2E..) http://luxik.cdi.cz/~devik/qos/htb/ --=20 Kind regards Marc-Christian Petersen http://sourceforge.net/projects/wolk PGP/GnuPG Key: 1024D/569DE2E3DB441A16 Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16 Key available at www.keyserver.net. Encrypted e-mail preferred. From esteban.maringolo@secont.com.ar Tue Sep 24 15:23:19 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 24 Sep 2002 11:23:19 -0300 Subject: [LARTC] HTB In-Reply-To: <00f101c263d4$6cc806a0$6e69690a@rimas> References: <00f101c263d4$6cc806a0$6e69690a@rimas> Message-ID: <1032877400.761.29.camel@inercia> --=-WTbbx5n0zfyTRN5gGP8b Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-09-24 at 11:12, Rimas wrote: > Hi guys, > =20 > How to put HTB in to 2.4 kernel? Compile kernel 2.4.20 with HTB support. Or else get kernel patches for 2.4.x (or 2.2.x) from devik's homepage. --=20 Esteban A. Maringolo Secont, Comunicaciones Digitales Buenos Aires, Argentina Tel: +54 (11) 4551-2455 http://www.secont.com.ar/ --=-WTbbx5n0zfyTRN5gGP8b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9kHVXDY8wt+MWh9ARAnOTAKDZXCUjiKuXS97Th8gRWYPwEBfTqQCgzvh0 iOA3hNhk2OZAisXJLv2Ys0E= =9zuY -----END PGP SIGNATURE----- --=-WTbbx5n0zfyTRN5gGP8b-- From rmocius@auste.elnet.lt Tue Sep 24 15:30:11 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 24 Sep 2002 15:30:11 +0100 Subject: [LARTC] HTB References: <00f101c263d4$6cc806a0$6e69690a@rimas> Message-ID: <011901c263d6$e579a160$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_0114_01C263DF.45CEE900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you guys Rimas ----- Original Message -----=20 From: Rimas=20 To: lartc@mailman.ds9a.nl=20 Sent: Tuesday, September 24, 2002 3:12 PM Subject: [LARTC] HTB Hi guys, How to put HTB in to 2.4 kernel? Thanks in advance Rimas ------=_NextPart_000_0114_01C263DF.45CEE900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you guys
 
Rimas
 
----- Original Message -----
From:=20 Rimas=20
Sent: Tuesday, September 24, = 2002 3:12=20 PM
Subject: [LARTC] HTB

Hi guys,
 
How to put HTB in to 2.4 = kernel?
 
 
Thanks in advance
 
Rimas
 
------=_NextPart_000_0114_01C263DF.45CEE900-- From rmocius@auste.elnet.lt Tue Sep 24 15:55:04 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 24 Sep 2002 15:55:04 +0100 Subject: [LARTC] HTB References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241615.03204.m.c.p@gmx.net> Message-ID: <012201c263da$5f7e5390$6e69690a@rimas> I tried the "patch -p1 --dry-run ./htb3.6_2.4.17.diff" but nothing happened, no error message, nothing. Rimas ----- Original Message ----- From: "Marc-Christian Petersen" To: Cc: "Rimas" Sent: Tuesday, September 24, 2002 3:17 PM Subject: Re: [LARTC] HTB > On Tuesday 24 September 2002 16:12, Rimas wrote: > > Hi Rimas, > > > How to put HTB in to 2.4 kernel? > patching? :) > > If you wanna try 3.6 code, download the tgz, untargzip it (tar xzpf) and > you'll see a diff/patch. Just "patch -p1 --dry-run < patchname" and see if it > succeed, if, leave out --dry-run, if not, fix the errors. If you have > questions when errors occur, don't hesitate to ask. > > for HTB2 code, just download the patch and follow the same as above (patch -p1 > ...) > > http://luxik.cdi.cz/~devik/qos/htb/ > > -- > Kind regards > Marc-Christian Petersen > > http://sourceforge.net/projects/wolk > > PGP/GnuPG Key: 1024D/569DE2E3DB441A16 > Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16 > Key available at www.keyserver.net. Encrypted e-mail preferred. > > From m.c.p@gmx.net Tue Sep 24 16:00:32 2002 From: m.c.p@gmx.net (Marc-Christian Petersen) Date: Tue, 24 Sep 2002 17:00:32 +0200 Subject: [LARTC] HTB In-Reply-To: <012201c263da$5f7e5390$6e69690a@rimas> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241615.03204.m.c.p@gmx.net> <012201c263da$5f7e5390$6e69690a@rimas> Message-ID: <200209241659.51730.m.c.p@gmx.net> On Tuesday 24 September 2002 16:55, Rimas wrote: Hi Rimas, > I tried the "patch -p1 --dry-run ./htb3.6_2.4.17.diff" but nothing > happened, no error message, nothing. err, you forget < ! Look carefully to what I've posted :) root@codeman:[/usr/src/linux-2.4.18-vanilla] # patch -p1 --dry-run <=20 htb2_2.4.17.diff=20 patching file net/sched/Config.in patching file net/sched/Makefile patching file net/sched/sch_htb.c patching file include/linux/pkt_sched.h patching file net/sched/sch_api.c --=20 Kind regards Marc-Christian Petersen http://sourceforge.net/projects/wolk PGP/GnuPG Key: 1024D/569DE2E3DB441A16 Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16 Key available at www.keyserver.net. Encrypted e-mail preferred. From rmocius@auste.elnet.lt Tue Sep 24 16:14:52 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 24 Sep 2002 16:14:52 +0100 Subject: [LARTC] HTB References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241615.03204.m.c.p@gmx.net> <012201c263da$5f7e5390$6e69690a@rimas> <200209241659.51730.m.c.p@gmx.net> Message-ID: <015201c263dd$23371590$6e69690a@rimas> Hi again, Sorry it was my mistake, I have mised <. And I got a few error messages : patching file net/sched/Config.in patching file net/sched/Makefile patching file net/sched/sch_htb.c patching file include/linux/pkt_sched.h patching file net/sched/sch_api.c Hunk #1 FAILED at 1117. 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.rej patching file lib/Makefile Reversed (or previously applied) patch detected! Assume -R? [n] y patching file lib/rbtree.c Reversed (or previously applied) patch detected! Assume -R? [n] y patching file include/net/pkt_sched.h Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #1 succeeded at 222 (offset 1 line). Is it OK or no? I use RedHat 7.3 and kernel 2.4.19 and do I have to update iproute2 too ? Thank you Rimas ----- Original Message ----- From: "Marc-Christian Petersen" To: Cc: "Rimas" Sent: Tuesday, September 24, 2002 4:00 PM Subject: Re: [LARTC] HTB > On Tuesday 24 September 2002 16:55, Rimas wrote: > > Hi Rimas, > > > I tried the "patch -p1 --dry-run ./htb3.6_2.4.17.diff" but nothing > > happened, no error message, nothing. > err, you forget < ! > > Look carefully to what I've posted :) > > root@codeman:[/usr/src/linux-2.4.18-vanilla] # patch -p1 --dry-run < > htb2_2.4.17.diff > patching file net/sched/Config.in > patching file net/sched/Makefile > patching file net/sched/sch_htb.c > patching file include/linux/pkt_sched.h > patching file net/sched/sch_api.c > > -- > Kind regards > Marc-Christian Petersen > > http://sourceforge.net/projects/wolk > > PGP/GnuPG Key: 1024D/569DE2E3DB441A16 > Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16 > Key available at www.keyserver.net. Encrypted e-mail preferred. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From rmocius@auste.elnet.lt Tue Sep 24 16:14:52 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Tue, 24 Sep 2002 16:14:52 +0100 Subject: [LARTC] HTB References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241615.03204.m.c.p@gmx.net> <012201c263da$5f7e5390$6e69690a@rimas> <200209241659.51730.m.c.p@gmx.net> Message-ID: <015201c263dd$23371590$6e69690a@rimas> Hi again, Sorry it was my mistake, I have mised <. And I got a few error messages : patching file net/sched/Config.in patching file net/sched/Makefile patching file net/sched/sch_htb.c patching file include/linux/pkt_sched.h patching file net/sched/sch_api.c Hunk #1 FAILED at 1117. 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.rej patching file lib/Makefile Reversed (or previously applied) patch detected! Assume -R? [n] y patching file lib/rbtree.c Reversed (or previously applied) patch detected! Assume -R? [n] y patching file include/net/pkt_sched.h Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #1 succeeded at 222 (offset 1 line). Is it OK or no? I use RedHat 7.3 and kernel 2.4.19 and do I have to update iproute2 too ? Thank you Rimas ----- Original Message ----- From: "Marc-Christian Petersen" To: Cc: "Rimas" Sent: Tuesday, September 24, 2002 4:00 PM Subject: Re: [LARTC] HTB > On Tuesday 24 September 2002 16:55, Rimas wrote: > > Hi Rimas, > > > I tried the "patch -p1 --dry-run ./htb3.6_2.4.17.diff" but nothing > > happened, no error message, nothing. > err, you forget < ! > > Look carefully to what I've posted :) > > root@codeman:[/usr/src/linux-2.4.18-vanilla] # patch -p1 --dry-run < > htb2_2.4.17.diff > patching file net/sched/Config.in > patching file net/sched/Makefile > patching file net/sched/sch_htb.c > patching file include/linux/pkt_sched.h > patching file net/sched/sch_api.c > > -- > Kind regards > Marc-Christian Petersen > > http://sourceforge.net/projects/wolk > > PGP/GnuPG Key: 1024D/569DE2E3DB441A16 > Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16 > Key available at www.keyserver.net. Encrypted e-mail preferred. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From stef.coene@docum.org Tue Sep 24 16:38:05 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 24 Sep 2002 17:38:05 +0200 Subject: [LARTC] HTB In-Reply-To: <1032877400.761.29.camel@inercia> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <1032877400.761.29.camel@inercia> Message-ID: <200209241738.05747.stef.coene@docum.org> On Tuesday 24 September 2002 16:23, Esteban Maringolo wrote: > On Tue, 2002-09-24 at 11:12, Rimas wrote: > > Hi guys, > > > > How to put HTB in to 2.4 kernel? > > Compile kernel 2.4.20 with HTB support. Kernel 2.4.20 has htb builtin. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From elacour@easter-eggs.com Tue Sep 24 16:50:28 2002 From: elacour@easter-eggs.com (Emmanuel Lacour) Date: Tue, 24 Sep 2002 17:50:28 +0200 Subject: [LARTC] An example of prio qdisc please... Message-ID: <20020924155028.GE4582@easter-eggs.com> I simply wan't to give higher priority for esp protocol. Could someone give me an example (I think using prio qdisc and u32 filter???) -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 mailto:elacour@easter-eggs.com - http://www.easter-eggs.com From esteban.maringolo@secont.com.ar Tue Sep 24 16:51:44 2002 From: esteban.maringolo@secont.com.ar (Esteban Maringolo) Date: 24 Sep 2002 12:51:44 -0300 Subject: [LARTC] HTB In-Reply-To: <200209241738.05747.stef.coene@docum.org> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <1032877400.761.29.camel@inercia> <200209241738.05747.stef.coene@docum.org> Message-ID: <1032882705.627.37.camel@inercia> --=-Mt4b4EEW4clvA3xzWZyo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-09-24 at 12:38, Stef Coene wrote: > On Tuesday 24 September 2002 16:23, Esteban Maringolo wrote: > > On Tue, 2002-09-24 at 11:12, Rimas wrote: > > > How to put HTB in to 2.4 kernel? > > Compile kernel 2.4.20 with HTB support. > Kernel 2.4.20 has htb builtin. That's why I've said "compile" and not "patch". :-) --=20 Esteban A. Maringolo Secont, Comunicaciones Digitales Buenos Aires, Argentina Tel: +54 (11) 4551-2455 http://www.secont.com.ar/ --=-Mt4b4EEW4clvA3xzWZyo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9kIoPDY8wt+MWh9ARAipoAKCdKMHY5Gt/neh1Z0VWhjBDUjjxBQCdHoNt fDu5awc7FJeqVX7+xeMUvTg= =elvt -----END PGP SIGNATURE----- --=-Mt4b4EEW4clvA3xzWZyo-- From stef.coene@docum.org Tue Sep 24 17:16:01 2002 From: stef.coene@docum.org (Stef Coene) Date: Tue, 24 Sep 2002 18:16:01 +0200 Subject: [LARTC] HTB In-Reply-To: <1032882705.627.37.camel@inercia> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241738.05747.stef.coene@docum.org> <1032882705.627.37.camel@inercia> Message-ID: <200209241816.01320.stef.coene@docum.org> On Tuesday 24 September 2002 17:51, Esteban Maringolo wrote: > On Tue, 2002-09-24 at 12:38, Stef Coene wrote: > > On Tuesday 24 September 2002 16:23, Esteban Maringolo wrote: > > > On Tue, 2002-09-24 at 11:12, Rimas wrote: > > > > How to put HTB in to 2.4 kernel? > > > > > > Compile kernel 2.4.20 with HTB support. > > > > Kernel 2.4.20 has htb builtin. > > That's why I've said "compile" and not "patch". :-) :) Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From smb23@csufresno.edu Tue Sep 24 23:22:47 2002 From: smb23@csufresno.edu (Steve M Bibayoff) Date: Tue, 24 Sep 2002 15:22:47 -0700 Subject: [LARTC] GRE tunnel wierdness Message-ID: <15f92a164a89.164a8915f92a@scccd.org> I haveing something wierd going on, can't seem to figure why. I have two private networks (neta & netb), being masq'ed behind RH 7.3 machines(east & west). I also have iptables running on both machines. I could ping from west to east anytime with no problem, but when I try to ping from east to west, it doesn't go through unless I first ping from west to east (hoepfully this is understandable the way I'm descibing it). Here is my setup: ------ ------------ ------------ ------ neta---|east|---|dsl router|--internet---|dsl router|--|west|--netb ------ ------------ ------------ ------ internal infaces on linux boxes eth0 on x.x.x.1neta=192.168.0.0/24 netb=192.168.1.0/24ip rules on east: # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255 # ip link set netb up arp on # ip addr add 192.168.0.254/24 dev netb # ip route add 192.168.1.0/24 dev netb ip rules on west: # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255 # ip link set neta up arp on # ip addr add 192.168.1.254/24 dev neta # ip route add 192.168.0.0/24 dev neta [east]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface a.b.c.w 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 netb 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 netb 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 a.b.c.x 0.0.0.0 UG 0 0 0 eth0 [west]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface f.g.h.y 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 neta 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 neta 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 f.g.h.z 0.0.0.0 UG 0 0 0 eth0 Iptables are the same on both boxes except on east I open allow ports 25 80 443 and specifically block port 1003. If I'm listening on west at neta when I first try to ping anyone on netb, nothing is coming though unless I have just pinged from netb to neta first. Hopefully this isn't too confusing or long winded. TIA Steve From david.lamparter@t-online.de Tue Sep 24 23:42:25 2002 From: david.lamparter@t-online.de (David Lamparter) Date: Wed, 25 Sep 2002 00:42:25 +0200 Subject: [LARTC] GRE tunnel wierdness References: <15f92a164a89.164a8915f92a@scccd.org> Message-ID: <3D90EA51.1000500@t-online.de> Hi, Steve M Bibayoff schrieb: > internal infaces on linux boxes eth0 on x.x.x.1neta=192.168.0.0/24 > netb=192.168.1.0/24ip rules on east: > # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255 > # ip link set netb up arp on > # ip addr add 192.168.0.254/24 dev netb -^^ > # ip route add 192.168.1.0/24 dev netb > ip rules on west: > # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255 > # ip link set neta up arp on > # ip addr add 192.168.1.254/24 dev neta -^^ > # ip route add 192.168.0.0/24 dev neta > [east]# route -n [...] > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 netb [...] > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 neta [...] > If I'm listening on west at neta when I first try to ping anyone on > netb, nothing is coming though unless I have just pinged from netb to > neta first. > I don't know where this ping effect comes from, but your setup is somewhat ... confusing. First, you use /24 subnet masks on the tunnel interfaces ... why? This results in having 2 routes for your local subnet, one over eth1, and one over the tunnel ... - A possible setup would be: east: # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255 # ip link set netb up # ip addr add 192.168.0.254/32 peer 192.168.1.0/24 dev netb west: # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255 # ip link set neta up # ip addr add 192.168.1.254/32 peer 192.168.0.0/24 dev neta - *Or* another possibility: east: # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255 # ip link set netb up # ip addr add 192.168.2.1/30 dev netb # ip route add 192.168.1.0/24 via 192.168.2.2 dev netb west: # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255 # ip link set neta up # ip addr add 192.168.2.2/30 dev neta # ip route add 192.168.0.0/24 via 192.168.2.1 dev neta The second possibility will work better when using some "sensible" software like zebra, mrouted or pimd. Note that tunnels usually are used as point-to-point interfaces. David Lamparter From mdew@mdew.dyndns.org Wed Sep 25 05:27:10 2002 From: mdew@mdew.dyndns.org (mdew) Date: 25 Sep 2002 16:27:10 +1200 Subject: [LARTC] HTB In-Reply-To: <015201c263dd$23371590$6e69690a@rimas> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241615.03204.m.c.p@gmx.net> <012201c263da$5f7e5390$6e69690a@rimas> <200209241659.51730.m.c.p@gmx.net> <015201c263dd$23371590$6e69690a@rimas> Message-ID: <1032928030.1110.1.camel@mdew> --=-M7RoaowJf5uw6HeGqVbi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-09-25 at 03:14, Rimas wrote: > Hi again, >=20 > Sorry it was my mistake, I have mised <. > And I got a few error messages : >=20 > patching file net/sched/Config.in > patching file net/sched/Makefile > patching file net/sched/sch_htb.c > patching file include/linux/pkt_sched.h > patching file net/sched/sch_api.c > Hunk #1 FAILED at 1117. > 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.rej > patching file lib/Makefile > Reversed (or previously applied) patch detected! Assume -R? [n] y ^^^^ > patching file lib/rbtree.c > Reversed (or previously applied) patch detected! Assume -R? [n] y ^^^^ > patching file include/net/pkt_sched.h > Reversed (or previously applied) patch detected! Assume -R? [n] y ^^^^ > Hunk #1 succeeded at 222 (offset 1 line). why did you reverse the patch? --=-M7RoaowJf5uw6HeGqVbi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9kTseH5J/xul0J+4RAppeAKCHk/aN0majIdjtd511S3FOqR5bewCfU2Rc gxzSvuODXo9+ba2qNY6G8E0= =JvAW -----END PGP SIGNATURE----- --=-M7RoaowJf5uw6HeGqVbi-- From arc_of_descent@gmx.net Wed Sep 25 06:59:12 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Wed, 25 Sep 2002 11:29:12 +0530 Subject: [LARTC] bridging and shaping Message-ID: <20020925112912.348818f4.arc_of_descent@gmx.net> Hi List, I've truly sorry if this question has been tried on this LIST, but i'm quite desperate now! I'm currently using a linux box doing proxy-arp, with same IP on both interfaces. kernel 2.4.18 with htb and iproute2 patch iptables and tc works perfectly as expected Now, I want to convert the linux box to a bridge, using (http://bridge.sourceforge.net) I noticed that you have to patch the kernel as well as iptables. Does tc need to be patched? Does this even work? I mean is it possible to operate linux in bridge mode and have bandwidth control also? Thanx -- arc_of_descent From zob_soulfly@hotmail.com Wed Sep 25 08:28:28 2002 From: zob_soulfly@hotmail.com (Soulfly) Date: Wed, 25 Sep 2002 09:28:28 +0200 Subject: [LARTC] An example of prio qdisc please... References: <20020924155028.GE4582@easter-eggs.com> Message-ID: tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3 3 3 1 1 1 1 2 2 2 2 tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip protocol 0xXX 0xff flowid 1:1 have you read the docs? If not, do so to understand how it works and what the quirks are. http://www.lartc.org/ ----- Original Message ----- From: "Emmanuel Lacour" To: Sent: Tuesday, September 24, 2002 5:50 PM Subject: [LARTC] An example of prio qdisc please... > I simply wan't to give higher priority for esp protocol. > > Could someone give me an example (I think using prio qdisc and u32 > filter???) > > > > -- > Easter-eggs Spécialiste GNU/Linux > 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité > Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 > mailto:elacour@easter-eggs.com - http://www.easter-eggs.com > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From stef.coene@docum.org Wed Sep 25 08:56:58 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 25 Sep 2002 09:56:58 +0200 Subject: [LARTC] bridging and shaping In-Reply-To: <20020925112912.348818f4.arc_of_descent@gmx.net> References: <20020925112912.348818f4.arc_of_descent@gmx.net> Message-ID: <200209250956.59013.stef.coene@docum.org> On Wednesday 25 September 2002 07:59, Rohan Almeida wrote: > Hi List, > > I've truly sorry if this question has been tried > on this LIST, but i'm quite desperate now! > > I'm currently using a linux box doing proxy-arp, > with same IP on both interfaces. > kernel 2.4.18 with htb and iproute2 patch > iptables and tc works perfectly as expected > > Now, I want to convert the linux box to a > bridge, using (http://bridge.sourceforge.net) This code is already available in kernel 2.4.x, so no patches needed if y= ou=20 use a 2.4.x kernel. > I noticed that you have to patch the kernel > as well as iptables. It's only needed to patch the kernel if you want to use iptables on the=20 bridge. > Does tc need to be patched? No > Does this even work? Yes > I mean is it possible to operate linux > in bridge mode and have bandwidth control also? Yes. You can use the u32 filter. If you want to use the iptables+fw-fil= ter,=20 you will need extra patches. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Sep 25 08:59:34 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 25 Sep 2002 09:59:34 +0200 Subject: [LARTC] HTB In-Reply-To: <015201c263dd$23371590$6e69690a@rimas> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241659.51730.m.c.p@gmx.net> <015201c263dd$23371590$6e69690a@rimas> Message-ID: <200209250959.34967.stef.coene@docum.org> On Tuesday 24 September 2002 17:14, Rimas wrote: > Hi again, > > Sorry it was my mistake, I have mised <. > And I got a few error messages : > > patching file net/sched/Config.in > patching file net/sched/Makefile > patching file net/sched/sch_htb.c > patching file include/linux/pkt_sched.h > patching file net/sched/sch_api.c > Hunk #1 FAILED at 1117. > 1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.r= ej > patching file lib/Makefile > Reversed (or previously applied) patch detected! Assume -R? [n] y > patching file lib/rbtree.c > Reversed (or previously applied) patch detected! Assume -R? [n] y > patching file include/net/pkt_sched.h > Reversed (or previously applied) patch detected! Assume -R? [n] y > Hunk #1 succeeded at 222 (offset 1 line). > > Is it OK or no? Nop. You have to choose "n". Some general clean-up patches that are in = the=20 htb patch are already applied to the defaul tkernel. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From elacour@easter-eggs.com Wed Sep 25 10:18:20 2002 From: elacour@easter-eggs.com (Emmanuel Lacour) Date: Wed, 25 Sep 2002 11:18:20 +0200 Subject: [LARTC] An example of prio qdisc please... In-Reply-To: References: <20020924155028.GE4582@easter-eggs.com> Message-ID: <20020925091820.GA9153@easter-eggs.com> On Wed, Sep 25, 2002 at 09:28:28AM +0200, Soulfly wrote: > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3 3 3 1 > 1 1 1 2 2 2 2 > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip protocol > 0xXX 0xff flowid 1:1 > > have you read the docs? If not, do so to understand how it works and what > the quirks are. http://www.lartc.org/ > > Of course, I did it already, the lartc howto is a really good doc, but all of this is not really easy so by giving me this example I will be able to understand more and do what I wan't. Thanks! -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 mailto:elacour@easter-eggs.com - http://www.easter-eggs.com From arc_of_descent@gmx.net Wed Sep 25 10:39:13 2002 From: arc_of_descent@gmx.net (Rohan Almeida) Date: Wed, 25 Sep 2002 15:09:13 +0530 Subject: [LARTC] An example of prio qdisc please... In-Reply-To: References: <20020924155028.GE4582@easter-eggs.com> Message-ID: <20020925150913.53942bb1.arc_of_descent@gmx.net> "Soulfly" thus wrote: > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3 3 3 1 > 1 1 1 2 2 2 2 > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip protocol > 0xXX 0xff flowid 1:1 Hi there This is ver infornmative I've long wanted priority of some protocol over the other. Now my question is: Can i use this with htb? I want: o ip 172.16.0.5 bandwidth restriction of 32 kbps (htb ceil) o ip 172.16.0.49 bandwidth restriction of 64 kbps (htb ceil) o protocol 23 priority over protocol 80 U see, I don't want to limit "protocol 80" to some bandwidth restriction so that "protocol 23" gets the rest available bandwidth I just want "proto 23" packets priority over "proto 80" In the above example u used the "prio" qdisc Can i use this with my htb as the roo qdisc and prio lower down in the class? Thanx -- arc_of_descent From zob_soulfly@hotmail.com Wed Sep 25 11:45:55 2002 From: zob_soulfly@hotmail.com (Soulfly) Date: Wed, 25 Sep 2002 12:45:55 +0200 Subject: [LARTC] An example of prio qdisc please... References: <20020924155028.GE4582@easter-eggs.com> <20020925091820.GA9153@easter-eggs.com> Message-ID: I'm happy to help! I just want to make sure you've know the basics so you don't fall into pitholes. Examples is one of the best sources of information. Oh I didn't look up the number for your protocol, so exchange the 'XX' with this. ----- Original Message ----- From: "Emmanuel Lacour" To: "Soulfly" Cc: Sent: Wednesday, September 25, 2002 11:18 AM Subject: Re: [LARTC] An example of prio qdisc please... > On Wed, Sep 25, 2002 at 09:28:28AM +0200, Soulfly wrote: > > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3 3 3 1 > > 1 1 1 2 2 2 2 > > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 > > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip protocol > > 0xXX 0xff flowid 1:1 > > > > have you read the docs? If not, do so to understand how it works and what > > the quirks are. http://www.lartc.org/ > > > > > > Of course, I did it already, the lartc howto is a really good doc, but > all of this is not really easy so by giving me this example I will be > able to understand more and do what I wan't. > > Thanks! > > -- > Easter-eggs Spécialiste GNU/Linux > 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité > Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 > mailto:elacour@easter-eggs.com - http://www.easter-eggs.com > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From zob_soulfly@hotmail.com Wed Sep 25 12:02:03 2002 From: zob_soulfly@hotmail.com (Soulfly) Date: Wed, 25 Sep 2002 13:02:03 +0200 Subject: [LARTC] An example of prio qdisc please... References: <20020924155028.GE4582@easter-eggs.com> <20020925150913.53942bb1.arc_of_descent@gmx.net> Message-ID: > "Soulfly" thus wrote: > > > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3 3 3 1 > > 1 1 1 2 2 2 2 > > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 > > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip protocol > > 0xXX 0xff flowid 1:1 > I have a configuration which use 5 prio levels (2 above the standard priolevels). I conerted it to 4 and forgot to alter the band parameter.. so the correct line is.. tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 2 3 2 2 3 3 3 3 1 1 1 1 2 2 2 2 > Hi there > This is ver infornmative > I've long wanted priority of some protocol over the other. > Now my question is: > Can i use this with htb? > > I want: > o ip 172.16.0.5 bandwidth restriction of 32 kbps (htb ceil) > o ip 172.16.0.49 bandwidth restriction of 64 kbps (htb ceil) > o protocol 23 priority over protocol 80 > > U see, I don't want to limit "protocol 80" to some bandwidth > restriction so that "protocol 23" gets the rest available bandwidth > I just want "proto 23" packets priority over "proto 80" > > In the above example u used the "prio" qdisc > Can i use this with my htb as the roo qdisc and prio > lower down in the class? > Yes, this should work out well. I suggest you add prio qdisc to the leafs in your htb class-tree. > Thanx > no problem From stef.coene@docum.org Wed Sep 25 12:44:11 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 25 Sep 2002 13:44:11 +0200 Subject: [LARTC] An example of prio qdisc please... In-Reply-To: <20020925150913.53942bb1.arc_of_descent@gmx.net> References: <20020924155028.GE4582@easter-eggs.com> <20020925150913.53942bb1.arc_of_descent@gmx.net> Message-ID: <200209251344.12014.stef.coene@docum.org> On Wednesday 25 September 2002 11:39, Rohan Almeida wrote: > "Soulfly" thus wrote: > > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3= 3 3 > > 1 1 1 1 2 2 2 2 > > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 > > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 > > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip > > protocol 0xXX 0xff flowid 1:1 > > Hi there > This is ver infornmative > I've long wanted priority of some protocol over the other. > Now my question is: > =09Can i use this with htb? > > I want: > =09o ip 172.16.0.5 bandwidth restriction of 32 kbps (htb ceil) > =09o ip 172.16.0.49 bandwidth restriction of 64 kbps (htb ceil) > =09o protocol 23 priority over protocol 80 > > U see, I don't want to limit "protocol 80" to some bandwidth > restriction so that "protocol 23" gets the rest available bandwidth > I just want "proto 23" packets priority over "proto 80" > > In the above example u used the "prio" qdisc > Can i use this with my htb as the roo qdisc and prio > lower down in the class? Yes, you can add the prio qdisc on a htb class. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From jegp@netvision.com.py Wed Sep 25 13:50:09 2002 From: jegp@netvision.com.py (Julio E. Gonzalez P.) Date: Wed, 25 Sep 2002 09:50:09 -0300 Subject: [LARTC] bridging and shaping References: <20020925112912.348818f4.arc_of_descent@gmx.net> <200209250956.59013.stef.coene@docum.org> Message-ID: <3D91B101.2030901@netvision.com.py> Stef Coene wrote: >On Wednesday 25 September 2002 07:59, Rohan Almeida wrote: > > >>Hi List, >> >>I've truly sorry if this question has been tried >>on this LIST, but i'm quite desperate now! >> >>I'm currently using a linux box doing proxy-arp, >>with same IP on both interfaces. >>kernel 2.4.18 with htb and iproute2 patch >>iptables and tc works perfectly as expected >> >>Now, I want to convert the linux box to a >>bridge, using (http://bridge.sourceforge.net) >> >> >This code is already available in kernel 2.4.x, so no patches needed if you >use a 2.4.x kernel. > > > >>I noticed that you have to patch the kernel >>as well as iptables. >> >> >It's only needed to patch the kernel if you want to use iptables on the >bridge. > > > >>Does tc need to be patched? >> >> >No > > > >>Does this even work? >> >> >Yes > > > >>I mean is it possible to operate linux >>in bridge mode and have bandwidth control also? >> >> >Yes. You can use the u32 filter. If you want to use the iptables+fw-filter, >you will need extra patches. > >Stef > > > I want to put very clear this idea, because I am interested in this too! If I want to put a Linux machine with bridge and HTB shaping, and only that (NO firewall, no iptables, no nothing, only bridge and HTB for shaping). Do I need to patch the kernel with anything other that the HTB patch (if my linux kernel < 2.4.20 ) Thanks! Julio. From raptor@tvskat.net Wed Sep 25 21:28:03 2002 From: raptor@tvskat.net (raptor) Date: Wed, 25 Sep 2002 16:28:03 -0400 Subject: [LARTC] [tcng8y] make test errors again :") Message-ID: <20020925162803.51a62220.raptor@tvskat.net> mandrake2.4.19mdk - sorry that i'm not able to be more helpfull :") And just sending make test reports ================================================================== TCNG host syntax: bare name with host prefix: PASSED TCNG host syntax: bare name with host prefix (obsolete): PASSED TCNG host syntax: name in double quotes, with host prefix: PASSED First example of HTB user guide: PASSED HTB in tcng: PASSED HTB example 1, in tcng: PASSED HTB using r2q default (10): FAILED File: tests/htbquant Command: tcsim -k 3 | tcsim_filter -d tos | awk '{ if ($2 == last) c++; else { print c+0; last = $2; c = 1; } }' | sort -rn | sed 1q Input: _in.4819 Output: _out.4819 Reference: _ref.4819 scripts/runtests.sh: line 2: 4843 Broken pipe cat scripts/run-all-tests: line 14: 1295 Broken pipe cat $n make: *** [test] Error 1 [root@qos tcng]# cat _in.4819 dev eth0 1Mbps { htb { /* quantum 12'500 bytes */ class (rate 1Mbps) if ip_tos == 0; class (rate 1Mbps) if ip_tos == 1; class (rate 1Mbps) if ip_tos == 2; } } every 1ms send IP_PCK($ip_tos=0) 0 x 80 /* 800 kbps */ every 1ms send IP_PCK($ip_tos=1) 0 x 80 every 1ms send IP_PCK($ip_tos=2) 0 x 80 time 0.5s end [root@qos tcng]# cat _out.4819 113 [root@qos tcng]# cat _ref.4819 125 [root@qos tcng]# From tobias.geiger@web.de Wed Sep 25 15:13:39 2002 From: tobias.geiger@web.de (Tobias Geiger) Date: Wed, 25 Sep 2002 16:13:39 +0200 (CEST) Subject: [LARTC] An example of prio qdisc please... In-Reply-To: <200209251344.12014.stef.coene@docum.org> References: <20020924155028.GE4582@easter-eggs.com> <20020925150913.53942bb1.arc_of_descent@gmx.net> <200209251344.12014.stef.coene@docum.org> Message-ID: <34194.213.164.67.210.1032963219.squirrel@kaeptnb.d2g.com> correct me if im wrong, but couldn't u achieve the same goal only with htb? i mean by creating a leave-level with classes rate=1bps, ceil=maxbw, prio 0-6 and attaching sfq/pfifo as leave-qdiscs to these classes? s.th. like: tc qdisc root handle 1:0 htb tc class parent 1:0 handle 1:1 rate tc class parent 1:1 handle 1:10 rate 1bps ceil prio 0 tc class parent 1:1 handle 1:11 rate .... ... .. prio 1 and so on tc qdisc parent 1:10 handle 10:0 pfifo/sfq tc qdisc parent 1:11 handle 11:0 .... and so on tc filter 1:0 protocol ip prio 0 handle 9999 fw classid 1:10 (syntax is not correct :) and/or other filters doesn't do this setup the same as the priomap (in general)? Greetings Tobias > On Wednesday 25 September 2002 11:39, Rohan Almeida wrote: >> "Soulfly" thus wrote: >> > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 >> 3 3 3 1 1 1 1 2 2 2 2 >> > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 >> > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 >> > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 >> > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 >> > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip >> protocol 0xXX 0xff flowid 1:1 >> >> Hi there >> This is ver infornmative >> I've long wanted priority of some protocol over the other. >> Now my question is: >> Can i use this with htb? >> >> I want: >> o ip 172.16.0.5 bandwidth restriction of 32 kbps (htb ceil) >> o ip 172.16.0.49 bandwidth restriction of 64 kbps (htb ceil) >> o protocol 23 priority over protocol 80 >> >> U see, I don't want to limit "protocol 80" to some bandwidth >> restriction so that "protocol 23" gets the rest available bandwidth I >> just want "proto 23" packets priority over "proto 80" >> >> In the above example u used the "prio" qdisc >> Can i use this with my htb as the roo qdisc and prio >> lower down in the class? > Yes, you can add the prio qdisc on a htb class. > > 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/ From thomas@arkena.com Wed Sep 25 16:12:15 2002 From: thomas@arkena.com (Thomas Kirk) Date: Wed, 25 Sep 2002 17:12:15 +0200 Subject: [LARTC] pfifo_fast dosnt work? Message-ID: <20020925151214.GA7331@thomas.arkena.com> Hep Trying to get pfifo to work. Setup : |------|<--->eth1 (192.168.10.0/24) eth0---| GW |<--->eth2 (192.168.11.0/24) |------|<--->eth3 (192.168.12.0/24) read all documentation : http://lartc.org/howto/lartc.cookbook.interactive-prio.html here is my TOS mangling rulse in iptables : $IPTABLES -A PREROUTING -i eth1 -t mangle -s 192.168.10.0/24 -p tcp --dport ftp-data -m state --state NEW,ESTABLISHED -j TOS --set-tos Maximize-Throughput $IPTABLES -A PREROUTING -i eth1 -t mangle -s 192.168.10.0/24 -p tcp --sport 44100:44200 -m state --state NEW,ESTABLISHED -j TOS --set-tos Maximize-Throughput $IPTABLES -A PREROUTING -i eth1 -t mangle -s 192.168.10.0/24 -p tcp --dport ftp -m state --state NEW,ESTABLISHED -j TOS --set-tos Minimize-Delay Im trying to limited the ftp-data throughoutput by putting all ftp-data in band 2. Ive checked with tcpdump -v -v |grep tos and yes ftp-data get [tos 0x8] which destination is band 2 if i read the documentation right? Allthough everything is set ok all my interactiv traffic ssh/telnet etc is very slow and sloppy when someone uploads to our ftpserver. Im running kernel 2.4.19 with latest patch-o-matic Please write to me for further information! You will find that im more than willing to get this problem solved :) -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas(at)arkena(dot)com Http://www.arkena.com BOFH excuse #212: Of course it doesn't work. We've performed a software upgrade. From landreani@seltatel.it Wed Sep 25 16:15:59 2002 From: landreani@seltatel.it (Andreani Luca) Date: Wed, 25 Sep 2002 17:15:59 +0200 Subject: [LARTC] get a route from within c code Message-ID: <6812F61B83A6D411BF250060B01B7BAC4A6F75@SELTATOR> I woluld like to know if there is a way to know the route to a destination without asking it via console (ip route get) but from within c code. One possible way is to make system("ip route gat xxx.xxx.xxx.xxx"), redirect to a file and then read the file. Is there a simpler and more efficient way? Thanks, Luca Andreani From david_list@boreham.org Wed Sep 25 16:30:45 2002 From: david_list@boreham.org (David Boreham) Date: Wed, 25 Sep 2002 08:30:45 -0700 Subject: [LARTC] get a route from within c code References: <6812F61B83A6D411BF250060B01B7BAC4A6F75@SELTATOR> Message-ID: <02a101c264a8$8425d370$160aa8c0@mtbrook.boreham.org> > I woluld like to know if there is a way to know the route to a destination > without asking it via console (ip route get) but from within c code. > One possible way is to make system("ip route gat xxx.xxx.xxx.xxx"), redirect > to a file and then read the file. > Is there a simpler and more efficient way? So...the 'ip' command is C code, right ? And you can download the source... From stef.coene@docum.org Wed Sep 25 16:39:13 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 25 Sep 2002 17:39:13 +0200 Subject: [LARTC] bridging and shaping In-Reply-To: <3D91B101.2030901@netvision.com.py> References: <20020925112912.348818f4.arc_of_descent@gmx.net> <200209250956.59013.stef.coene@docum.org> <3D91B101.2030901@netvision.com.py> Message-ID: <200209251739.13664.stef.coene@docum.org> > I want to put very clear this idea, because I am interested in this too= ! > If I want to put a Linux machine with bridge and HTB shaping, and only > that (NO firewall, no iptables, no nothing, only bridge and HTB for > shaping). > Do I need to patch the kernel with anything other that the HTB patch (i= f > my linux kernel < 2.4.20 ) No Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Wed Sep 25 16:42:21 2002 From: stef.coene@docum.org (Stef Coene) Date: Wed, 25 Sep 2002 17:42:21 +0200 Subject: [LARTC] An example of prio qdisc please... In-Reply-To: <34194.213.164.67.210.1032963219.squirrel@kaeptnb.d2g.com> References: <20020924155028.GE4582@easter-eggs.com> <200209251344.12014.stef.coene@docum.org> <34194.213.164.67.210.1032963219.squirrel@kaeptnb.d2g.com> Message-ID: <200209251742.21270.stef.coene@docum.org> On Wednesday 25 September 2002 16:13, Tobias Geiger wrote: > correct me if im wrong, but couldn't u achieve the same goal only with = htb? > > i mean by creating a leave-level with classes rate=3D1bps, ceil=3Dmaxbw= , prio > 0-6 > > and attaching sfq/pfifo as leave-qdiscs to these classes? Yes and it's even better. With cbq you can give the all classes a minimu= m=20 bandwidth so one class can not kill an other by using all bandwidth. Wit= h=20 prio, you can generate a lot of traffic in the highest band so the other=20 bands have no bandwidth left. > s.th. like: > tc qdisc root handle 1:0 htb > tc class parent 1:0 handle 1:1 rate > tc class parent 1:1 handle 1:10 rate 1bps ceil prio 0 > tc class parent 1:1 handle 1:11 rate .... ... .. prio 1 > and so on > tc qdisc parent 1:10 handle 10:0 pfifo/sfq > tc qdisc parent 1:11 handle 11:0 .... > and so on > tc filter 1:0 protocol ip prio 0 handle 9999 fw classid 1:10 > (syntax is not correct :) > and/or other filters > > doesn't do this setup the same as the priomap (in general)? It's not the same, but you can get the same result. Remember, prio is only for excess bandidth. So each class will get's at = least=20 his rate and the class with the lowest prio will get the remaining bandwi= dth. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From john@dallambarn.freeserve.co.uk Wed Sep 25 17:12:39 2002 From: john@dallambarn.freeserve.co.uk (John Cushnie) Date: Wed, 25 Sep 2002 17:12:39 +0100 Subject: [LARTC] Routing and Shaping using RedHat7.3 Message-ID: <000a01c264ae$63bcf450$016aa8c0@dmrg.local> Hi all, I'm running RH7.3 plus errata. I've read through the HowTo and I had something like this configuration working on RH7.1, but it looks like the interface to IP and ROUTE has changed considerably since then..... I'm trying to set up a simple router configuration to route between subnets, as shown in the diagram. My aim is to provide traffic shaping between the 194.80.34.0 hosts and the 148.88.0.0 and 192.168.106.0 networks. 148.88.0.0 network --------+-------------------------------+----- __ | | ___/ \_ +------+-----------------+ +-------+-----------+ _/ \__ | eth2 148.88.155.253| |eth1 148.88.154.150| / \ | | | | | network -----+ eth0 194.80.34.202 | | WinXP | | 194.80.34.0 | | Linux router | | | \_ __/ | | | 192.168.106.1 | \__ __/ | eth1 192.168.106.2 | | eth0 | \___/ +------+-----------------+ +---------+---------+ | | | 192.168.106.0 network | ----+---------------------------------+-------- The routes and addresses for the Linux box are as listed below. I have enabled ip-forwarding: # cat /proc/sys/net/ipv4/ip_forward 1 # cat /proc/sys/net/ipv4/conf/eth2/forwarding 1 # cat /proc/sys/net/ipv4/conf/eth0/forwarding 1 # cat /proc/sys/net/ipv4/conf/eth1/forwarding 1 >From the Linux host I can ping all the subnets I have defined and have connections to. Ie: Ping 192.168.106.1 Ping 148.88.154.150 Ping 194.80.34.35 (Remote Host) When I try to ping from the WinXP machine I get mixed results. Ie: Ping 192.168.106.2 -- works fine Ping 194.80.34.202 -- works fine Ping 194.80.34.35 (Remote Host) -- doesn't work -- Using Ethereal I see the ARP request at eth2 rom the WinXP on the Linux router but no response, and then time out at the WinXP box. Not quite sure the pings don't work in the configuration I have, unless I have missed something in the routing tables or a basic configuration parameter. Any suggestions ? Do I need further routes defining ? Do I need to enable something to allow ARP requests to be responded to ? Is there any way to check if the required routing is enabled in the kernel ? Thanks in advance for any suggestions. John Cushnie. Email: cushnie@csi.com =========================================================== Routes: ======== # /sbin/ip route list 192.168.106.0/24 via 192.168.106.2 dev eth1 scope link 194.80.34.0/24 via 194.80.34.202 dev eth0 scope link 192.168.0.0/16 dev eth1 scope link 148.88.0.0/16 via 148.88.155.253 dev eth2 scope link 148.88.0.0/16 dev eth2 scope link 127.0.0.0/8 dev lo scope link default via 194.80.34.99 dev eth0 Addresses: =========== # /sbin/ip address list 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:76:f3:b4:56 brd ff:ff:ff:ff:ff:ff inet 194.80.34.202/24 brd 194.80.34.255 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:76:f3:b2:65 brd ff:ff:ff:ff:ff:ff inet 192.168.106.2/16 brd 192.168.106.255 scope global eth1 4: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:01:02:df:c2:38 brd ff:ff:ff:ff:ff:ff inet 148.88.155.253/16 brd 148.88.155.255 scope global eth2 ==================================================================== From tobias.geiger@web.de Wed Sep 25 17:18:44 2002 From: tobias.geiger@web.de (Tobias Geiger) Date: Wed, 25 Sep 2002 18:18:44 +0200 (CEST) Subject: [LARTC] pfifo_fast dosnt work? In-Reply-To: <20020925151214.GA7331@thomas.arkena.com> References: <20020925151214.GA7331@thomas.arkena.com> Message-ID: <39680.212.2.37.233.1032970724.squirrel@kaeptnb.d2g.com> hi, just like Steve said in the previous mail, prioband is ok but it doesn't make sure that your bandwith is consumed by one service (even if it's in a lower class than interactive stuff) because it doesn't reserve bandwidth for its priomaps. to achieve what u want i suggest using htb (see previous mail). > Hep > > Trying to get pfifo to work. Setup : > > |------|<--->eth1 (192.168.10.0/24) > eth0---| GW |<--->eth2 (192.168.11.0/24) > |------|<--->eth3 (192.168.12.0/24) > > read all documentation : > > http://lartc.org/howto/lartc.cookbook.interactive-prio.html > > here is my TOS mangling rulse in iptables : > > $IPTABLES -A PREROUTING -i eth1 -t mangle -s 192.168.10.0/24 -p tcp > --dport ftp-data -m state --state NEW,ESTABLISHED -j TOS --set-tos > Maximize-Throughput $IPTABLES -A PREROUTING -i eth1 -t mangle -s > 192.168.10.0/24 -p tcp --sport 44100:44200 -m state --state > NEW,ESTABLISHED -j TOS --set-tos Maximize-Throughput $IPTABLES -A > PREROUTING -i eth1 -t mangle -s 192.168.10.0/24 -p tcp --dport ftp -m > state --state NEW,ESTABLISHED -j TOS --set-tos Minimize-Delay > > Im trying to limited the ftp-data throughoutput by putting all > ftp-data in band 2. Ive checked with tcpdump -v -v |grep tos and yes > ftp-data get [tos 0x8] which destination is band 2 if i read the > documentation right? > > Allthough everything is set ok all my interactiv traffic ssh/telnet etc > is very slow and sloppy when someone uploads to our ftpserver. > > Im running kernel 2.4.19 with latest patch-o-matic > > Please write to me for further information! You will find that im more > than willing to get this problem solved :) > > -- > Venlig hilsen/Kind regards > Thomas Kirk > ARKENA > thomas(at)arkena(dot)com > Http://www.arkena.com > > > BOFH excuse #212: > > Of course it doesn't work. We've performed a software upgrade. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From smb23@csufresno.edu Wed Sep 25 17:32:12 2002 From: smb23@csufresno.edu (Steve M Bibayoff) Date: Wed, 25 Sep 2002 09:32:12 -0700 Subject: [LARTC] GRE tunnel wierdness Message-ID: <1b52791b8517.1b85171b5279@scccd.org> David Lamparter wrote: > I don't know where this ping effect comes from, > > east: > # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255 > # ip link set netb up > # ip addr add 192.168.0.254/32 peer 192.168.1.0/24 dev netb > > west: > # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255 > # ip link set neta up > # ip addr add 192.168.1.254/32 peer 192.168.0.0/24 dev neta > > - *Or* another possibility: > east: > # ip tunnel add netb mode gre remote a.b.c.e local f.g.h.i ttl 255 > # ip link set netb up > # ip addr add 192.168.2.1/30 dev netb > # ip route add 192.168.1.0/24 via 192.168.2.2 dev netb > > west: > # ip tunnel add neta mode gre remote f.g.h.i local a.b.c.e ttl 255 > # ip link set neta up > # ip addr add 192.168.2.2/30 dev neta > # ip route add 192.168.0.0/24 via 192.168.2.1 dev neta Tried both of these, am still seeing this weird ping affect. If no traffic travels over the tunnel for a while (>5 minutes) I can't get from .0/24 neta(east) to .1/24 netb(west) till after I send some traffic from west to east first. Once I do that, everything else works fine. Is there soemthing, that someone could think of, that I should check? TIA Steve From david.lamparter@t-online.de Wed Sep 25 17:59:57 2002 From: david.lamparter@t-online.de (David Lamparter) Date: Wed, 25 Sep 2002 18:59:57 +0200 Subject: [LARTC] GRE tunnel wierdness References: <1b52791b8517.1b85171b5279@scccd.org> Message-ID: <3D91EB8D.5050005@t-online.de> Steve M Bibayoff schrieb: > Tried both of these, am still seeing this weird ping affect. If no > traffic travels over the tunnel for a while (>5 minutes) I can't get > from .0/24 neta(east) to .1/24 netb(west) till after I send some traffic > from west to east first. Once I do that, everything else works fine. > > Is there soemthing, that someone could think of, that I should check? > Do you have NAT / mangling / etc. running somewhere? The connection tracking timeout is 500 s afaik, maybe GRE is NATed on one of your gateways? A possible explanation would be that east does SNAT on GRE packets or west does DNAT on GRE ... so when east tries to reach west, the packet is SNAT'ed or DNAT'ed and therefore doesn't reach west, but when west tries to reach east, connection tracking information is set up on both routers so it works ... until the timeout expires. David Lamparter From smb23@csufresno.edu Wed Sep 25 19:01:44 2002 From: smb23@csufresno.edu (Steve M Bibayoff) Date: Wed, 25 Sep 2002 11:01:44 -0700 Subject: [LARTC] GRE tunnel wierdness Message-ID: <1c24201c29c2.1c29c21c2420@scccd.org> David Lamparter wrote: > Do you have NAT / mangling / etc. running somewhere? The connection > tracking timeout is 500 s afaik, maybe GRE is NATed on one of your > gateways? > A possible explanation would be that east does SNAT on GRE packets > or > west does DNAT on GRE ... so when east tries to reach west, the > packet > is SNAT'ed or DNAT'ed and therefore doesn't reach west, but when > west > tries to reach east, connection tracking information is set up on > both > routers so it works ... until the timeout expires. That's is it. It actually happens when going from west to east, I just never noticed it before. Thanks for the clue. Steve ps. I know this isn't the appropiate list, but could someone see what iptable rule needs to be changed to make this not happen(rules generated from script found at: http://www.asgardsrealm.net/linux/firewall ). [root@east root]# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT ipv6-auth-- anywhere anywhere ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- east.somenet.com east.somenet.com ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT udp -- anywhere anywhere udp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:re-mail-ck ACCEPT udp -- anywhere anywhere udp dpt:re-mail-ck ACCEPT tcp -- anywhere anywhere tcp dpt:51 ACCEPT udp -- anywhere anywhere udp dpt:51 ACCEPT tcp -- anywhere anywhere tcp dpt:47 ACCEPT udp -- anywhere anywhere udp dpt:47 ACCEPT udp -- anywhere anywhere udp dpt:isakmp ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT all -- anywhere anywhere LOG all -- anywhere anywhere LOG level info prefix `FIREWALL: Filter-INPUT ' Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 192.168.1.0/24 192.168.0.0/24 ACCEPT all -- 192.168.0.0/24 192.168.1.0/24 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- 192.168.2.0/24 anywhere ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT all -- 192.168.0.0/24 anywhere LOG all -- anywhere anywhere LOG level info prefix `FIREWALL: Filter-FORWARD ' Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- 192.168.0.0/24 anywhere ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT all -- 192.168.2.0/24 anywhere ACCEPT all -- east.somenet.com east.somenet.com ACCEPT all -- anywhere anywhere ACCEPT all -- somenet.com somenet.com LOG all -- anywhere anywhere LOG level info prefix `FIREWALL: Filter-OUTPUT ' From thomas@arkena.com Wed Sep 25 19:04:22 2002 From: thomas@arkena.com (Thomas Kirk) Date: Wed, 25 Sep 2002 20:04:22 +0200 Subject: [LARTC] pfifo_fast dosnt work? In-Reply-To: <39680.212.2.37.233.1032970724.squirrel@kaeptnb.d2g.com> References: <20020925151214.GA7331@thomas.arkena.com> <39680.212.2.37.233.1032970724.squirrel@kaeptnb.d2g.com> Message-ID: <20020925180422.GB7816@thomas.arkena.com> On Wed, Sep 25, 2002 at 06:18:44PM +0200, Tobias Geiger wrote: > hi, > > just like Steve said in the previous mail, prioband is ok but it doesn't > make sure that your bandwith is consumed by one service (even if it's in a > lower class than interactive stuff) because it doesn't reserve bandwidth > for its priomaps. If it dosnt use the TOS fileds to take prioity for delivering packets in a certain way what exactly is pfifo good for? > > to achieve what u want i suggest using htb (see previous mail). ok i will look into that then. -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas(at)arkena(dot)com Http://www.arkena.com BOFH excuse #398: Data for intranet got routed through the extranet and landed on the internet. From dhlii@1dla.com Wed Sep 25 23:27:25 2002 From: dhlii@1dla.com (David H. Lynch Jr.) Date: Wed, 25 Sep 2002 18:27:25 -0400 Subject: [LARTC] Help: Multiple internet connections Message-ID: <001001c264e2$baef0bd0$64a9a6cd@1dla.com> I have been trying to get a router/firewall with a DSL and 6 fixed IP's and a Faster Cable modem with a semi-fixed IP up and running for a long, long time. Mostly things work, and I have read the http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN261 pages and implemented them. I appear to have full access to the extent that my iptables rules allow to any services running on the router/firewall. I appear to have outgoing internet access NATed correctly and running the way I want. However I have problems with the servers/services that are being DNATed to behind the firewall. I do not believe my problems are with IPTABLES - at least I have forced IPTABLES to log every packet it drops and it is not dropping anything related to the areas I am having problems. There are a number of odd things that appear to be going on, but for the most part the failure cases appear to occur when a client on the internet who is using an ISP closely related to one of my connections, tries to connect through an address on the interface farthest away from them. I.E. when a client also using a local cable connection tries to connect to a DNATed server/service using a DSL IP. My DSL is 209.223.245.120-128 my cable is 68.84.207,53 A client whose IP is 68.84.207.97 tries to connect to 209.223.245.125:143 and is unable to connect. IPTABLES logs no dropped packets. iproute is configured as per the multiple links pages above. It is my guess that the inbound packet manages its way to my server just fine, but on the return trip it decides to head back out the cable modem as that is the best route back to the client, and since the client sees a response coming from the wrong source it discards it, but I could easily be wrong. I believe I am only having problems with DNATed services behind the firewall, and I believe it is only when the client is local to the external interface opposite the one they are coming in on. But I could easily be wrong. regardless the problem is most ly reproducible - though it has been know to go away for days at a time on its own, and mostly limited to a small subset of all clients. I am busily perusing the lartc archives but have not found anything directly on point yet. From jleach@ocis.net Thu Sep 26 03:47:46 2002 From: jleach@ocis.net (Jason C. Leach) Date: Wed, 25 Sep 2002 19:47:46 -0700 Subject: [LARTC] simple question Message-ID: <20020925194746.D25895@ocis.net> hi, So I have the following: ROUTER 10.0.0.254 | 10.0.0.3(eth0) MY_DEBIAN_RTR 209.52.x.126(eth1) | LAN (the 209.52.x.64/26 subnet) I need to route the 209.52.x.64 subnet through MY_DEBIAN_RTR and on to the telephone company router. I'd probably like 209.52.x to have it's own table (if that is a good idea). The debian box will eventually do some firewalling, and some traffic monitoring. But first I have to get the traffic flowing. I have read some docs, and the HOTO, but they were not too much help. Thanks, j. -- ...................... ..... Jason C. Leach .. Current PGP/GPG Key ID: 43AD2024 From LIEVEN@terra.es Thu Sep 26 05:01:23 2002 From: LIEVEN@terra.es (LIEVEN) Date: Thu, 26 Sep 2002 06:01:23 +0200 Subject: [LARTC] simple question Message-ID: As you can confirm in your own draw that you shown us, you have different nets . You need : 1.- A static route to ROUTER 10.0.0.254 from de LAN 209 or 2.- Configure some routing protocols like RIP with Zebra suite. These configurations tipe are the same as Cisco routers, for any configurations problem you can look at www.cisco.com and search "configuring RIP" for example Best Regards!!!! LievenX -.-.LievenX..--. ----- Mensaje Original ----- De: "Jason C. Leach" Fecha: Jueves, Septiembre 26, 2002 4:47 am Asunto: [LARTC] simple question > hi, > > So I have the following: > > ROUTER 10.0.0.254 > | > 10.0.0.3(eth0) > MY_DEBIAN_RTR > 209.52.x.126(eth1) > | > LAN (the 209.52.x.64/26 subnet) > > > I need to route the 209.52.x.64 subnet through MY_DEBIAN_RTR > and on to the telephone company router. I'd probably like > 209.52.x to have it's own table (if that is a good idea). > The debian box will eventually do some firewalling, and some > traffic monitoring. But first I have to get the traffic flowing. > > I have read some docs, and the HOTO, but they were not too > much help. > > Thanks, > j. > > > > -- > ...................... > ..... Jason C. Leach > .. > > Current PGP/GPG Key ID: 43AD2024 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From arthurvl@sci.kun.nl Thu Sep 26 10:27:59 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Thu, 26 Sep 2002 11:27:59 +0200 (MEST) Subject: [LARTC] Help: Multiple internet connections In-Reply-To: <001001c264e2$baef0bd0$64a9a6cd@1dla.com> Message-ID: On Wed, 25 Sep 2002, David H. Lynch Jr. wrote: > Mostly things work, and I have read the > http://lartc.org/howto/lartc.rpdb.multiple-links.html#AEN261 pages and > implemented them. *blink*, nice to hear that. :) > I appear to have full access to the extent that my iptables rules > allow to any services running on the router/firewall. Good. > I appear to have outgoing internet access NATed correctly and > running the way I want. Good. > However I have problems with the servers/services that are being > DNATed to behind the firewall. Not so good. [snip] > It is my guess that the inbound packet manages its way to my > server just fine, but on the return trip it decides to head back out the > cable modem as that is the best route back to the client, and since the > client sees a response coming from the wrong source it discards it, but > I could easily be wrong. No, you are most probably right. Unfortunately, there is no real solution to your problem, for as soon as the packet has ben DNATed to the service behind the firewall you lose all information as to which route the packet took to get to your firewall. This means that any return packet can only take the `obvious' short route directly to the remote machine, and not the less-obvious route the long way round but with the correct source address. > I believe I am only having problems with DNATed services behind > the firewall, and I believe it is only when the client is local to the > external interface opposite the one they are coming in on. But I could > easily be wrong. regardless the problem is most ly reproducible - though > it has been know to go away for days at a time on its own, and mostly > limited to a small subset of all clients. Sounds as if there's routes flapping for a subset of your clients. I can see only one real solution: have some sort of application-level proxies run on your firewall host to plug the connections through to the services behind it. One way to do so would be to use socks in listening mode. Another would be to use netcat... Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From elacour@easter-eggs.com Thu Sep 26 10:52:48 2002 From: elacour@easter-eggs.com (Emmanuel Lacour) Date: Thu, 26 Sep 2002 11:52:48 +0200 Subject: [LARTC] An example of prio qdisc please... In-Reply-To: References: <20020925150913.53942bb1.arc_of_descent@gmx.net> Message-ID: <20020926095248.GB12891@easter-eggs.com> On Wed, Sep 25, 2002 at 01:02:03PM +0200, Soulfly wrote: > > "Soulfly" thus wrote: > > > > > tc qdisc add dev eth0 root handle 1: prio bands 5 priomap 2 3 2 2 3 3 3 > 3 1 > > > 1 1 1 2 2 2 2 > > > tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 10 > > > tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 10 > > > tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10 > > > tc qdisc add dev eth0 parent 1:4 handle 40: sfq perturb 10 > > > tc filter add dev eth0 protocol ip parent 1: prio 10 u32 match ip > protocol > > > 0xXX 0xff flowid 1:1 > > > > I have a configuration which use 5 prio levels (2 above the standard > priolevels). I conerted it to 4 and forgot to alter the band parameter.. so > the correct line is.. > > tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 2 3 2 2 3 3 3 3 1 > 1 1 1 2 2 2 2 > Here is my net config: LAN1->(eth1)ipsec_gw1(ppp0)---------------(ppp0)ipsec_gw2(eth1)<-LAN2 ^ | server Ok, so I tried this: tc qdisc del dev ppp0 root tc qdisc add dev ppp0 root handle 1: prio tc qdisc add dev ppp0 parent 1:1 handle 10: sfq perturb 10 tc qdisc add dev ppp0 parent 1:2 handle 20: sfq perturb 10 tc qdisc add dev ppp0 parent 1:3 handle 30: sfq perturb 10 tc filter add dev ppp0 protocol ip parent 1: prio 10 u32 match ip protocol 0x50 0xff flowid 1:1 I did it on my too ipsec-end gateway so if from I connect from LAN1 to LAN2 via ssh, all traffic go in 10:, and when I ftp from LAN1 to the server directly through internet (no tunnel), traffic go in 30: But this doesn't change anything, ssh is as slow as without prio when I do ftp???? Where is my probably qos conception error?? Thanks for any help. -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76 mailto:elacour@easter-eggs.com - http://www.easter-eggs.com From noroozi@mehr.sharif.edu Thu Sep 26 12:45:50 2002 From: noroozi@mehr.sharif.edu (noroozi@mehr.sharif.edu) Date: Thu, 26 Sep 2002 11:45:50 GMT Subject: [LARTC] dual processor Message-ID: <200209261145.g8QBjn014726@mehr.sharif.edu> Hello every body, do you have any expriment on dual processor in linux kernel ? if you have please send me acknowledge, thanx, Noroozi --------------------------------------------- This message was sent using sharif web-based mail. http://mehr.sharif.edu From raptor@tvskat.net Thu Sep 26 22:21:36 2002 From: raptor@tvskat.net (raptor) Date: Thu, 26 Sep 2002 17:21:36 -0400 Subject: [LARTC] [tcng] tcc->tc comments Message-ID: <20020926172136.01e9caab.raptor@tvskat.net> hi, is there a way so that I can write something like that : htb { class ( rate 10kbps, ceil 20kbps, comment "this is a comment") { } } and later in the tcc-output I get something like this : #this is a comment tc ...blah.. classid X:Y .... And similar thing for filters/classifiers ?! The idea is to be able read easly if I have alot of classes and classifiers. thanx alot in advance From john@dallambarn.freeserve.co.uk Thu Sep 26 15:29:01 2002 From: john@dallambarn.freeserve.co.uk (John Cushnie) Date: Thu, 26 Sep 2002 15:29:01 +0100 Subject: [LARTC] Routing and Shaping using RedHat7.3 In-Reply-To: <200209251941.28233.z@adsl-213-190-47-193.takas.lt> Message-ID: <001001c26569$123cc860$016aa8c0@dmrg.local> Hi, Thanks for the pointer. It was in fact the gateways to/from the Linux box not being defined correctly that caused the confusion and no-function of the routing. All no in place and working. Many thanks. John. >>> -----Original Message----- >>> From: Zubio Ancartone [mailto:z@adsl-213-190-47-193.takas.lt] >>> Sent: 25 September 2002 20:41 >>> To: john@dallambarn.freeserve.co.uk >>> Subject: Re: [LARTC] Routing and Shaping using RedHat7.3 >>> >>> >>> On Wednesday 25 September 2002 16:12, John Cushnie wrote: >>> >>> What is your "remote host" default gateway? Do tcpdump on eth0. >>> >>> > Hi all, >>> > >>> > I'm running RH7.3 plus errata. >>> > I've read through the HowTo and I had something like this >>> > configuration working on RH7.1, but it looks like the >>> interface to IP >>> > and ROUTE has changed considerably since then..... >>> > >>> > I'm trying to set up a simple router configuration to >>> route between >>> > subnets, as shown in the diagram. My aim is to provide >>> traffic shaping >>> > between the 194.80.34.0 hosts and the 148.88.0.0 and >>> 192.168.106.0 >>> > networks. >>> > From raptor@tvskat.net Thu Sep 26 22:31:39 2002 From: raptor@tvskat.net (raptor) Date: Thu, 26 Sep 2002 17:31:39 -0400 Subject: [LARTC] HTB In-Reply-To: <015201c263dd$23371590$6e69690a@rimas> References: <00f101c263d4$6cc806a0$6e69690a@rimas> <200209241615.03204.m.c.p@gmx.net> <012201c263da$5f7e5390$6e69690a@rimas> <200209241659.51730.m.c.p@gmx.net> <015201c263dd$23371590$6e69690a@rimas> Message-ID: <20020926173139.23fcca1e.raptor@tvskat.net> Mandrake 2.4.19mdk has HTB in, probably RedHat have done the same ... "Rimas" wrote: |Hi again, | |Sorry it was my mistake, I have mised <. |And I got a few error messages : | |patching file net/sched/Config.in |patching file net/sched/Makefile |patching file net/sched/sch_htb.c |patching file include/linux/pkt_sched.h |patching file net/sched/sch_api.c |Hunk #1 FAILED at 1117. |1 out of 2 hunks FAILED -- saving rejects to file net/sched/sch_api.c.rej |patching file lib/Makefile |Reversed (or previously applied) patch detected! Assume -R? [n] y |patching file lib/rbtree.c |Reversed (or previously applied) patch detected! Assume -R? [n] y |patching file include/net/pkt_sched.h |Reversed (or previously applied) patch detected! Assume -R? [n] y |Hunk #1 succeeded at 222 (offset 1 line). | |Is it OK or no? | |I use RedHat 7.3 and kernel 2.4.19 and do I have to update iproute2 too ? | |Thank you | |Rimas | | |----- Original Message ----- |From: "Marc-Christian Petersen" |To: |Cc: "Rimas" |Sent: Tuesday, September 24, 2002 4:00 PM |Subject: Re: [LARTC] HTB | | |> On Tuesday 24 September 2002 16:55, Rimas wrote: |> |> Hi Rimas, |> |> > I tried the "patch -p1 --dry-run ./htb3.6_2.4.17.diff" but nothing |> > happened, no error message, nothing. |> err, you forget < ! |> |> Look carefully to what I've posted :) |> |> root@codeman:[/usr/src/linux-2.4.18-vanilla] # patch -p1 --dry-run < |> htb2_2.4.17.diff |> patching file net/sched/Config.in |> patching file net/sched/Makefile |> patching file net/sched/sch_htb.c |> patching file include/linux/pkt_sched.h |> patching file net/sched/sch_api.c |> |> -- From raptor@tvskat.net Thu Sep 26 22:47:31 2002 From: raptor@tvskat.net (raptor) Date: Thu, 26 Sep 2002 17:47:31 -0400 Subject: [LARTC] [tcng] and iptables Message-ID: <20020926174731.79623190.raptor@tvskat.net> As we discused earlier in the list tcng still doesn't support ipchains/iptable/ip route marking and classifing based on this. So my question is how can I do this manualy i.e. find the desired class-ID ... and add additional tc-commands so that marked packets goes to the desired class. I need this for this :") eth0 ----> class X:Y eht1 ----> class Z:W f.e. everything coming from eth0 goes to 100kbps class and everything from eth1 to 50kbps. In fact it a litle bit harder : 3 frame realy channels (1 upstream/pvc0 and 2 downstream/pvc1,pvc2) and 2 eth. Example : if from pvc1 --> eth0 and ip_dst = 192.168.0.55 then 10kbps if from pvc2 --> eth0 and ip_dst = 192.168.0.55 then 15kbps if ip_src = 192.168.0.55 then 10kbps (dest is always pvc0 until i setup proxy) thanx raptor From wa@almesberger.net Thu Sep 26 22:58:21 2002 From: wa@almesberger.net (Werner Almesberger) Date: Thu, 26 Sep 2002 18:58:21 -0300 Subject: [LARTC] [tcng] tcc->tc comments In-Reply-To: <20020926172136.01e9caab.raptor@tvskat.net>; from raptor@tvskat.net on Thu, Sep 26, 2002 at 05:21:36PM -0400 References: <20020926172136.01e9caab.raptor@tvskat.net> Message-ID: <20020926185821.B29542@almesberger.net> --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline raptor wrote: > is there a way so that I can write something like that : Hmm, looks like a good use for pragmas with tc output ;-) After applying the attached quick and dirty patch, this htb (pragma "#the_outer_qdisc") { class (rate 10kbps,ceil 20kbps,pragma "#the_first_class") { fifo(pragma "#the_inner_qdisc"); } } yields this: # the_outer_qdisc tc qdisc add dev eth0 handle 1:0 root htb # the_first_class tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1250bps ceil 2500bps # the_inner_qdisc tc qdisc add dev eth0 handle 2:0 parent 1:1 pfifo Note that you can't include spaces in pragams, but all other non-blank characters are fine. > And similar thing for filters/classifiers ?! Works there too, but only if using "on". When using "if", tcc may transform the expression quite heavily, and there's no way for associating output items with input items (in the general case). But a better way to do all this is to use tcc's location map to extract the comments directly from the source, as demonstrated by the Perl script in the second attachment. Input example: /* this is the comment for HTB */ htb { // another comment, this // time for a class class (rate 10kbps,ceil 20kbps) { // last but not least, a comment for the FIFO fifo; } } Not that, when invoking com.pl, the name of the input file must be the last command-line argument. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch --- tc.c.orig Thu Sep 26 17:32:47 2002 +++ tc.c Thu Sep 26 17:37:52 2002 @@ -237,6 +237,18 @@ void tc_pragma(const PARAM *params) { - if (prm_present(params,&prm_pragma)) - yywarn("\"pragma\" parameter ignored by \"tc\" target"); + const DATA_LIST *pragma; + + if (!prm_present(params,&prm_pragma)) return; + for (pragma = prm_data(params,&prm_pragma).u.list; pragma; + pragma = pragma->next) { + const char *s; + + s = pragma->ref->u.string; + if (*s != '#') { + yywarn("\"pragma\" parameter ignored by \"tc\" target"); + return; + } + printf("# %s\n",s+1); + } } --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="com.pl" #!/usr/bin/perl sub emit { return unless $in =~ /\n$_[0] /s; ($s = "\n$`") =~ s/\n\d+ /\n/gs; return unless $s =~ m#/\*\s*(([^*]|\*[^/])*)\*/[^\n]*$|//\s*(([^\n]*\n\s*//)*[^\n]*)$#s; ($s = defined $1 ? $1 : $3) =~ s/\n\s*/\n# /sg; $s =~ s#\s*//\s*# #; print "# $s\n" || die "stdout: $!"; } open(FILE,$ARGV[$#ARGV]) || die "$ARGV[$#ARGV]: $!"; while () { $in .= "$. $_"; } close FILE; print "out: $in\n"; open(PIPE,"tcc -l $$.out ".join(" ",@ARGV)."|") || die "tcc: $!"; @out = ; close PIPE; exit $? if $?; open(FILE,"$$.out") || die "$$.out: $!"; for () { $q{$1} = $2 if /^qdisc [^:]+:(\S+) .* (\d+)$/; $c{$1} = $2 if /^class [^:]+:(\S+) .* (\d+)$/; } close FILE; unlink "$$.out" || warn "unlink $$.out: $!"; for (@out) { &emit($q{$1}) if /^tc qdisc .* handle (\d+):0/; &emit($c{$1}) if /^tc class .* classid (\d+:\d+)/; print $_ || die "stdout: $!"; } --9jxsPFA5p3P2qPhR-- From johannes@erdfelt.com Fri Sep 27 01:52:19 2002 From: johannes@erdfelt.com (Johannes Erdfelt) Date: Thu, 26 Sep 2002 20:52:19 -0400 Subject: [LARTC] htb random weirdness Message-ID: <20020926205219.A9523@sventech.com> Today I setup htb on a system of mine that I needed to control bandwidth for. I read the documentation and setup a config that seems to be working fine. Unfortunately, there's a problem where randomly for between 1 and a couple of seconds, almost no packets are sent out, or are delayed significantly. This is the output from a script I got from a friend. It does some simple difference averaging with a 10 second period. Notice the period of 0.13 Mb/s. That's not supposed to happen. eth0: 0.04 Mb/s In 1.68 Mb/s Out - 116.3 p/s In 180.7 p/s Out eth0: 0.04 Mb/s In 1.59 Mb/s Out - 82.1 p/s In 130.4 p/s Out eth0: 0.04 Mb/s In 1.60 Mb/s Out - 123.1 p/s In 184.8 p/s Out eth0: 0.01 Mb/s In 0.13 Mb/s Out - 33.3 p/s In 53.9 p/s Out eth0: 0.05 Mb/s In 1.53 Mb/s Out - 63.2 p/s In 89.6 p/s Out eth0: 0.05 Mb/s In 1.76 Mb/s Out - 119.4 p/s In 180.9 p/s Out At the same time I ran a ping to the host as well: 64 bytes from xxx.xxx.xxx.20: icmp_seq=488 ttl=58 time=75.8 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=489 ttl=58 time=75.6 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=490 ttl=58 time=75.6 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=491 ttl=58 time=80.4 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=492 ttl=58 time=75.7 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=493 ttl=58 time=111 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=495 ttl=58 time=1370 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=497 ttl=58 time=2695 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=499 ttl=58 time=700 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=504 ttl=58 time=135 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=506 ttl=58 time=81.8 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=507 ttl=58 time=75.4 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=508 ttl=58 time=75.6 ms 64 bytes from xxx.xxx.xxx.20: icmp_seq=509 ttl=58 time=75.7 ms I also ran a ping to a host sitting right next to it on the same switch. It did not see the same increase in latency. Load on the system was negligble at the time of the "blip". Also, in my logs was this message: HTB: mindelay=500, report it please ! Here's the jist of my config: tc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 htb \ rate 2016kbit ceil 2016kbit tc class add dev eth0 parent 1:1 classid 1:10 htb \ rate 768kbit ceil 2016kbit prio 0 tc class add dev eth0 parent 1:1 classid 1:11 htb \ rate 256kbit ceil 1920kbit prio 2 tc class add dev eth0 parent 1:1 classid 1:12 htb \ rate 1024kbit ceil 2016kbit prio 1 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip tos 0x10 0xff flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip protocol 1 0xff flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip src xxx.xxx.xxx.119 flowid 1:11 tc qdisc add dev eth0 parent 1:10 handle 20: sfq perturb 10 tc qdisc add dev eth0 parent 1:11 handle 21: sfq perturb 10 tc qdisc add dev eth0 parent 1:12 handle 22: sfq perturb 10 Anyone have any idea what be causing the "blip"? It's noticable because for that period of time, all of my ssh sessions become very slow and laggy, and then everything speeds up again. In fact, it happened as I was writing this email too. JE From hanhbnetfilter@yahoo.com.cn Fri Sep 27 03:28:44 2002 From: hanhbnetfilter@yahoo.com.cn (=?gb2312?q?hanhbnetfilter?=) Date: Fri, 27 Sep 2002 10:28:44 +0800 (CST) Subject: [LARTC] ipmode compile error Message-ID: <20020927022844.58266.qmail@web15202.mail.bjs.yahoo.com> imq and htb are used to control traffic. When I create a bridge with the bridge-utils, I get a new device : br0. I can shape traffic on this device, but I can not use iptables to mark packets. I used ipmode http://www.linuxvirtualserver.org/~julian/#bridging my kernel is 2.4.19 when i compile kernel I get the following error: br_forward.o error 1 first_rule error 2 if I used ipmode, then I can set imq as this: /usr/local/sbin/iptables -t mangle -A PREROUTING -i br0 -j IMQ --todev 0 is this right ? _________________________________________________________ Do You Yahoo!? "·˘ĥÌĊÓÊÖğú,żìÀ´²ÎĵÓÑĊğ˘ŜÇ!" http://cn.ent.yahoo.com/star/midautumn/index.html From wa@almesberger.net Fri Sep 27 06:52:33 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 27 Sep 2002 02:52:33 -0300 Subject: [LARTC] [tcng] and iptables In-Reply-To: <20020926174731.79623190.raptor@tvskat.net>; from raptor@tvskat.net on Thu, Sep 26, 2002 at 05:47:31PM -0400 References: <20020926174731.79623190.raptor@tvskat.net> Message-ID: <20020927025233.C29542@almesberger.net> raptor wrote: > As we discused earlier in the list tcng still doesn't support > ipchains/iptable/ip route marking and classifing based on this. Well, you can just use the MARK target to set skb->nfmark with iptables, and you can then use this for classification with the "fw" classifier, e.g. prio { fw { class (1) on (13); class (2) on (42); } } 13 and 42 are the MARK values. > In fact it a litle bit harder : > 3 frame realy channels (1 upstream/pvc0 and 2 downstream/pvc1,pvc2) and 2 > eth. Combining classifiers is rather tricky, and it's also quite limited by the way how classifiers are chained. You can build interesting things with that, as shown e.g. in the section "Dump actions" of tcc/if_u32.c, but it's quite messy. tcc doesn't support any combined classifiers (when using tc), because the limitations imposed by the kernel traffic control are just too narrow. Example: let's assume, you could select "nfmark == X" in an "if" construct, and tcc would build a classifier combining "fw" and "u32". Then, the following expressions could be converted: class (<$class_1>) if nfmark == VALUE_1 && $condition_1; class (<$class_2>) if nfmark == VALUE_1 && $condition_2; class (<$class_3>) if 1; and class (<$class_1>) if nfmark == VALUE_1 && $condition_1; class (<$class_2>) if nfmark == VALUE_2 && $condition_1; class (<$class_3>) if 1; but not class (<$class_1>) if nfmark == VALUE_1 && $condition_1; class (<$class_2>) if nfmark == VALUE_2 && $condition_2; class (<$class_3>) if 1; I don't even want to think about how to combine this with policing :-) So in your case, the correct solution is to do the whole classification process in iptables, and only use "fw" in the tcng part. In a future version of tcc, you'll also be able to usw "if" instead of "fw". - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From dhlii@1dla.com Fri Sep 27 07:54:24 2002 From: dhlii@1dla.com (David H. Lynch Jr.) Date: Fri, 27 Sep 2002 02:54:24 -0400 Subject: [LARTC] Help: Multiple internet connections In-Reply-To: Message-ID: <000d01c265f2$b763d7a0$fc14dfce@1dla.com> >-----Original Message----- >From: Arthur van Leeuwen [mailto:arthurvl@sci.kun.nl] >Sent: Thursday, September 26, 2002 5:28 AM >To: David H. Lynch Jr. >Cc: 'lartc Mailing List' >Subject: Re: [LARTC] Help: Multiple internet connections >> However I have problems with the servers/services that are being >> DNATed to behind the firewall. >Not so good. >[snip] >> It is my guess that the inbound packet manages its way to my server >> just fine, but on the return trip it decides to head back out the >> cable modem as that is the best route back to the client, and since >> the client sees a response coming from the wrong source it discards >> it, but I could easily be wrong. >No, you are most probably right. Unfortunately, there is no real solution to your problem, for as soon as the packet has >ben DNATed to the service behind the firewall you lose all information as to which route the packet took to get to >your firewall. This means that any return packet can only take the `obvious' short route directly to the remote machine, >and not the less-obvious route the long way round but with the correct source address. >> I believe I am only having problems with DNATed services behind the >> firewall, and I believe it is only when the client is local to the >> external interface opposite the one they are coming in on. But I could >> easily be wrong. regardless the problem is most ly reproducible - >> though it has been know to go away for days at a time on its own, and >> mostly limited to a small subset of all clients. >Sounds as if there's routes flapping for a subset of your clients. >I can see only one real solution: have some sort of application-level proxies run on your firewall host to plug the >connections through to the services behind it. One way to do so would be to use socks in listening mode. >Another would be to use netcat... >Doei, Arthur. Trying to grok the interrelations between IPTABLES and routing has given me a headache. I guess I am not as sharp as I used to be. I am also having a hard time getting a complete handle on what "stateful" really means. But I am gathering that this is a routing problem caused as a side effect of DNATing a connection. If IPTABLES is "stateful" does that mean that if I MARK a packet that the return packet is also marked ? If that were the case I could mark the Inbound packets from one interface and use iproute to select the right routing table for the return packets. Alternatively, if I set the servers behind the firewall up with two IP's and DNATed to a different one depending on the incoming interface shouldn't I be able to chose an outgoing routing table based on the source IP of the return packet ? Finally what is a flapping route ? This problem would make allot more sense to me if it were consistent. Thank you. Just having a second opinion that I am on the right track helps allot. From arthurvl@sci.kun.nl Fri Sep 27 08:29:49 2002 From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Date: Fri, 27 Sep 2002 09:29:49 +0200 (MEST) Subject: [LARTC] Help: Multiple internet connections In-Reply-To: <000d01c265f2$b763d7a0$fc14dfce@1dla.com> Message-ID: On Fri, 27 Sep 2002, David H. Lynch Jr. wrote: [snip, trying to do multipath routing through a NAT box] > Trying to grok the interrelations between IPTABLES and routing has given > me a headache. I guess I am not as sharp as I used to be. I am also > having a hard time getting a complete handle on what "stateful" really > means. But I am gathering that this is a routing problem caused as a > side effect of DNATing a connection. If IPTABLES is "stateful" does that > mean that if I MARK a packet that the return packet is also marked ? No. It means that the firewall maintains internal state as to what packets it has seen. This allows it to determine that packets from a TCP connection are allowed, due to the fact that it has indeed been setup from this side. The problem you're seeing is that you let the packets travel out of your firewall again to the server behind it. As soon as the packets are on the wire, there is *no* way to do any tracking of the any more, as you can with fwmarks as long as they stay on the host. The problem is that you lose the information on what interface the packet has originally come in, due to DNAT. > Alternatively, if I set the servers behind the firewall up with > two IP's and DNATed to a different one depending on the incoming > interface shouldn't I be able to chose an outgoing routing table based > on the source IP of the return packet ? That is exactly the right solution to this problem, if you don't intend to do it at the application level. :) > Finally what is a flapping route ? This problem would make allot more > sense to me if it were consistent. Owh, the internet provider of the clients that you see `disappearing' from the server at times re-routes the traffic from time to time. It probably has redundant links to the internet, and using some of these links the problem does occur whereas using others it doesn't. However, due to reconfigurations, hardware failure, all kinds of reasons really, the routes may not be very stable and `flap' between the different links. That is what I meant. > Thank you. Just having a second opinion that I am on the right > track helps allot. Well, you are. :) Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From thomas@arkena.com Fri Sep 27 09:18:22 2002 From: thomas@arkena.com (Thomas Kirk) Date: Fri, 27 Sep 2002 10:18:22 +0200 Subject: [LARTC] htb + iproute2/tc Message-ID: <20020927081822.GD12646@thomas.arkena.com> Having trouble with htb. Using example from documents so there should not be any problems with the configuration : http://lartc.org/howto/lartc.cookbook.ultimate-tc.html 15.8.3. The actual script (HTB) Im trying to get this to work on Debian woody which run a patched linux kernel 2.4.18. Ive patched it with the following files : http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff applied cleanly http://www.netfilter.org/files/patch-o-matic-20020825.tar.bz2 applied cleanly Whenever i try to use tc to configure tc i get the following errors on commandline : RTNETLINK answers: Invalid argument RTNETLINK answers: No such file or directory And from syslog i get : Sep 27 10:15:03 staalanden kernel: HTB init, kernel part version 3.6 Sep 27 10:15:03 staalanden kernel: HTB: need tc/htb version 3 (minor is 6), you have 1 I dont really know whats going one here? Maybe my version of HTB is to new for the version of tc on this debian woody system? According to the packagesmaintainer of iproute2 for debian system this is not the case : http://www.geocrawler.com/mail/msg.php3?msg_id=8273731&list=216 As you can see ive done alot of googling but havnt really found any real answers. Hope the listmembers here can help me :) Thanks in advance -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas(at)arkena(dot)com Http://www.arkena.com BOFH excuse #86: Runt packets From ja@ssi.bg Fri Sep 27 09:54:05 2002 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 27 Sep 2002 11:54:05 +0300 (EEST) Subject: [LARTC] ipmode compile error In-Reply-To: <20020927022844.58266.qmail@web15202.mail.bjs.yahoo.com> Message-ID: Hello, On Fri, 27 Sep 2002, [gb2312] hanhbnetfilter wrote: > imq and htb are used to control traffic. > When I create a bridge with the bridge-utils, I get a > new device : br0. I can shape traffic on this > device, but I can not use iptables to mark packets. > I used ipmode > http://www.linuxvirtualserver.org/~julian/#bridging > my kernel is 2.4.19 > when i compile kernel I get the following error: > br_forward.o error 1 > first_rule error 2 What errors? Do you have plain kernel patched with the ipmode kernel patch? > if I used ipmode, then I can set imq as this: > /usr/local/sbin/iptables -t mangle -A PREROUTING -i > br0 -j IMQ --todev 0 > is this right ? Bridge in IP MODE enabled receives IP traffic on the slave eth* ports, not on the br0 interface. Only ARP can be received on br0 if you are using routes through br0. The goal is to receive IP on the slave ports, though. The asymmetry in the route settings is not a problem if you handle it correctly as mentioned in the docs, then you can use routes on slave or on bridge interface according to your needs. Else, there is no reason to use ipmode, you can play with br0 if ipmode is off. Regards -- Julian Anastasov From Alberto.Baragatti@nokia.com Fri Sep 27 09:52:34 2002 From: Alberto.Baragatti@nokia.com (Alberto.Baragatti@nokia.com) Date: Fri, 27 Sep 2002 10:52:34 +0200 Subject: [LARTC] htb + iproute2/tc Message-ID: <9DF9EDD872380D4B802D1E341ABF6471B5FF4C@duebe003.europe.nokia.com> Hi, note that the htb patch comes with a modified "tc" binary as well. So make sure you are using the tc executable that comes with the htp3 = bundle: http://luxik.cdi.cz/~devik/qos/htb/ the patch for tc is also there, but is specific for iproute2 rel 991023, so I recommend to use as far as possible the provided tc binary. I hope this helps, - Alberto BOFH excuse:=20 "parallel processors running perpendicular today" -----Original Message----- From: ext Thomas Kirk [mailto:thomas@arkena.com] Sent: Freitag, 27. September 2002 10:18 To: lartc@mailman.ds9a.nl Subject: [LARTC] htb + iproute2/tc Having trouble with htb. Using example from documents so there should not be any problems with the configuration : http://lartc.org/howto/lartc.cookbook.ultimate-tc.html 15.8.3. The actual script (HTB) Im trying to get this to work on Debian woody which run a patched linux kernel 2.4.18. Ive patched it with the following files : http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff applied cleanly http://www.netfilter.org/files/patch-o-matic-20020825.tar.bz2 applied cleanly Whenever i try to use tc to configure tc i get the following errors on commandline : RTNETLINK answers: Invalid argument RTNETLINK answers: No such file or directory And from syslog i get : Sep 27 10:15:03 staalanden kernel: HTB init, kernel part version 3.6 Sep 27 10:15:03 staalanden kernel: HTB: need tc/htb version 3 (minor is 6), you have 1 I dont really know whats going one here? Maybe my version of HTB is to new for the version of tc on this debian woody system? According to the packagesmaintainer of iproute2 for debian system this is not the case : http://www.geocrawler.com/mail/msg.php3?msg_id=3D8273731&list=3D216 As you can see ive done alot of googling but havnt really found any real answers. Hope the listmembers here can help me :) Thanks in advance --=20 Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas(at)arkena(dot)com Http://www.arkena.com BOFH excuse #86: Runt packets _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From thomas@arkena.com Fri Sep 27 11:36:13 2002 From: thomas@arkena.com (Thomas Kirk) Date: Fri, 27 Sep 2002 12:36:13 +0200 Subject: [LARTC] htb + iproute2/tc In-Reply-To: <9DF9EDD872380D4B802D1E341ABF6471B5FF4C@duebe003.europe.nokia.com> References: <9DF9EDD872380D4B802D1E341ABF6471B5FF4C@duebe003.europe.nokia.com> Message-ID: <20020927103613.GA19849@thomas.arkena.com> Hey There Alberto! On Fri, Sep 27, 2002 at 10:52:34AM +0200, Alberto.Baragatti@nokia.com wrote: > note that the htb patch comes with a modified "tc" binary as well. > So make sure you are using the tc executable that comes with the htp3 bundle: > http://luxik.cdi.cz/~devik/qos/htb/ yes i noticed that and tried it but that gives me the same errors as described in previous mail. I found another tc binary though that works. One can get it here : http://mdew.dyndns.org/tc.tar.gz I dont know whats the diffrence between the one you pointed me towards and this one? -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas(at)arkena(dot)com Http://www.arkena.com BOFH excuse #160: non-redundant fan failure From raptor@tvskat.net Fri Sep 27 18:43:58 2002 From: raptor@tvskat.net (raptor) Date: Fri, 27 Sep 2002 13:43:58 -0400 Subject: [LARTC] tctree Message-ID: <20020927134358.39838ec2.raptor@tvskat.net> Hi, below u will find a simple perl script to draw a TC CLASS tree. At the moment only 3 formatings are available, but u can easly add more(look cformat) The formating option can be chained with '-'. Example usage : tc class show dev eth1 | ./tctree.pl tc class show dev eth1 | ./tctree.pl -f pure tc class show dev eth1 | ./tctree.pl -f bitps tc class show dev eth1 | ./tctree.pl -f rate tc class show dev eth1 | ./tctree.pl -f rate-bitps Good for diplayng ppl scenarios. ==========================OUTPUT===================================================== [root@qos tcng]# tc class show dev eth1 | ./tctree.pl class htb 2:1 root rate 125000bps ceil 125000bps burst 2849b cburst 2849b |_class htb 2:2 parent 2:1 rate 12500bps ceil 12500bps burst 1724b cburst 1724b |_class htb 2:3 parent 2:2 rate 8750bps ceil 12500bps burst 1686b cburst 1724b |_class htb 2:4 parent 2:3 prio 0 rate 125bps ceil 9625bps burst 1600b cburst 1695b |_class htb 2:5 parent 2:3 prio 0 rate 2400bps ceil 2400bps burst 1623b cburst 1623b |_class htb 2:6 parent 2:2 prio 0 rate 3750bps ceil 12500bps burst 1636b cburst 1724b |_class htb 2:7 parent 2:1 rate 6250bps ceil 6250bps burst 1661b cburst 1661b |_class htb 2:8 parent 2:7 prio 0 rate 125bps ceil 9625bps burst 1600b cburst 1695b |_class htb 2:9 parent 2:7 prio 0 rate 2400bps ceil 2400bps burst 1623b cburst 1623b [root@qos tcng]# tc class show dev eth1 | ./tctree.pl -f rate-bitps rate 1000000bs |_rate 100000bs |_rate 70000bs |_rate 1000bs |_rate 19200bs |_rate 30000bs |_rate 50000bs |_rate 1000bs |_rate 19200bs [root@qos tcng]# tc class show dev eth1 | ./tctree.pl -f pure htb 2:1 |_htb 2:2 |_htb 2:3 |_htb 2:4 |_htb 2:5 |_htb 2:6 |_htb 2:7 |_htb 2:8 |_htb 2:9 [root@qos tcng]# ======================================SCRIPT================================================================ #!/usr/bin/perl use strict; use vars qw(%o); use Getopt::Std; getopts('f:',\%o); open FILE, '-' or die 'hmmm... : $!'; my @in = ; close FILE; #formats - pure sub cformat { my ($line, $formats) = @_; my $res; for my $f (split /-/, $formats) { $line =~ s/class (\w+? \d+:\d+).+$/$1/ if $f eq 'pure'; $line =~ s/^.+(rate \d+\w+).+$/$1/ if $f eq 'rate'; $line =~ s!(\d+)bps!($1*8).'bs'!eg if $f eq 'bitps'; }; return $line } my $tab = '|_'; my $prev = shift @in; my ($prevParent) = $prev =~ /(\d+:\d+)/; for my $i ( 0 .. $#in ) { my ($classID, $parent) = $in[$i] =~ /class\D+(\d+:\d+)\D+parent\D+(\d+:\d+)/; $tab =~ s/^(.+)$/(' ' x length($1)).'|_'/e unless $parent eq $prevParent; $in[$i] = "$tab" . cformat($in[$i], $o{f}); $prevParent = $parent; }; print cformat($prev,$o{f}),@in; From raptor@tvskat.net Fri Sep 27 19:00:57 2002 From: raptor@tvskat.net (raptor) Date: Fri, 27 Sep 2002 14:00:57 -0400 Subject: [LARTC] tctree In-Reply-To: <20020927134358.39838ec2.raptor@tvskat.net> References: <20020927134358.39838ec2.raptor@tvskat.net> Message-ID: <20020927140057.6adceab1.raptor@tvskat.net> oops i forgot to go backward :")) From raptor@tvskat.net Fri Sep 27 21:43:53 2002 From: raptor@tvskat.net (raptor) Date: Fri, 27 Sep 2002 16:43:53 -0400 Subject: [LARTC] [tctree] now seems to work ok :") Message-ID: <20020927164353.6a461577.raptor@tvskat.net> Here is another try .... i havent tried on deeper trees, but it should work.... enjoy ============OUTPUT================================================================== [root@qos tcng]# tc class show dev eth1 | ./tctree.pl -f idparent +-class htb 2:1 root rate 125000bps ceil 125000bps burst 2849b cburst 2849b +-htb 2:2 parent 2:1 | +-htb 2:3 parent 2:2 | | +-htb 2:4 parent 2:3 | | +-htb 2:4 parent 2:3 | +-htb 2:3 parent 2:2 +-htb 2:2 parent 2:1 +-htb 2:3 parent 2:2 +-htb 2:3 parent 2:2 [root@qos tcng]# tc class show dev eth1 | ./tctree.pl -f pure +-htb 2:1 +-htb 2:2 | +-htb 2:3 | | +-htb 2:4 | | +-htb 2:4 | +-htb 2:3 +-htb 2:2 +-htb 2:3 +-htb 2:3 ============================SCRIPT====================================================== #!/usr/bin/perl use strict; use vars qw(%o); use Getopt::Std; use Data::Dumper; getopts('f:',\%o); my %pos;#for storing class positions #used to cut unnececary vertical bars #too much effort for being beautiful :") my %child; open FILE, '-' or die 'hmmm... : $!'; my @in = ; close FILE; #formats - pure, bitps, rate, idparent sub cformat { my ($line, $formats) = @_; my $res; for my $f (split /-/, $formats) { $line =~ s/class (\w+? \d+:\d+).+$/$1/ if $f eq 'pure'; $line =~ s/^.+(rate \d+\w+).+$/$1/ if $f eq 'rate'; $line =~ s!(\d+)bps!($1*8).'bs'!eg if $f eq 'bitps'; $line =~ s/class (.+parent \d+:\d+).+$/$1/ if $f eq 'idparent'; }; return $line } #which is the nearest parent in this column in the rows before me sub nearestInCol { my ($row, $col) = shift; #if u think u can make it harder do it :") my ($v) = sort { $pos{$_}{$b} <=> $pos{$_}{$b} } grep { $pos{$_}{row} < $row && $pos{$_}{col} == $col } keys %pos; return $v } #ascii-art sub art { my ($cls,$row) = @_; my $tab; for my $c (0 .. $pos{$cls}{col}) { my $nearest = &nearestInCol($row,$c); SWITCH: { if ($c > ($pos{$cls}{col})-1) { $tab .= '+-'; last SWITCH}; #dont even ask me what this is doing ... !!! if (#ok if nearest parent on this column doesnt have more childs below us cut it $c == $pos{$nearest}{col} || $row > $child{$nearest} ) { $tab .= ' '; last SWITCH}; $tab .= '| ' } } return $tab } #build class position table my ($prevParent, $prevClassID); my $c = 0;#column for my $r ( 1 .. $#in ) { my ($classID, $parent) = $in[$r] =~ /class\D+(\d+:\d+)\D+parent\D+(\d+:\d+)/; unless ($parent eq $prevParent) { unless ($parent ne $prevClassID) { $c++ } else {$c = $pos{$parent}{col}+1} }; $pos{$classID}{col} = $c; $pos{$classID}{row} = $r; $prevParent = $parent; $prevClassID = $classID; $child{$parent} = $r; }; #print the tree my $row = 0; for my $cls (sort {$pos{$a}{row} <=> $pos{$b}{row}} keys %pos) { my $tab = art($cls,$row); print $tab.(cformat($in[$pos{$cls}{col}],$o{f})); $row++ }; From jacobt@bivio.net Fri Sep 27 15:23:40 2002 From: jacobt@bivio.net (Jacob Teplitsky) Date: Fri, 27 Sep 2002 07:23:40 -0700 (PDT) Subject: [LARTC] Is there a way to set fwmark without iptables ? Message-ID: <200209271423.g8RENek17691@stimpy.bivio.net> I'm looking for something like this: ping --fwmark 1234 ... bind (fwmark, .....) Thanks - Jacob From raptor@tvskat.net Fri Sep 27 23:23:24 2002 From: raptor@tvskat.net (raptor) Date: Fri, 27 Sep 2002 18:23:24 -0400 Subject: [LARTC] tctree + tcng Message-ID: <20020927182324.5303d56c.raptor@tvskat.net> OK, now it should support the output of the tcng too.... And one new option if u have a comments before the class declaration u can print them like this : [root@qos tcng]# cat xxx.tc | ./tctree.pl -f comment +- total +- internet channel | +- guaranteed 70% | | +- g19.2 | | +- g19.2 | +- unguaranteed +- BG channel +- u77kbps +- u19.2kbps [root@qos tcng]# cat xxx.tc | ./tctree.pl -f idparent +-parent 2:0 classid 2:1 +-parent 2:1 classid 2:2 | +-parent 2:2 classid 2:3 | | +-parent 2:3 classid 2:4 | | +-parent 2:3 classid 2:4 | +-parent 2:2 classid 2:3 +-parent 2:1 classid 2:2 +-parent 2:2 classid 2:3 +-parent 2:2 classid 2:3 =========================xxx.tc================== which is generated using prevoisly sent on the list com.pl script from Warner .... i.e. "com.pl xxx.tcng > xxx.tc" # ================================ Device eth1 ================================ tc qdisc add dev eth1 handle 1:0 root dsmark indices 4 default_index 0 # root tc qdisc add dev eth1 handle 2:0 parent 1:0 htb default 5 # total tc class add dev eth1 parent 2:0 classid 2:1 htb rate 125000bps # internet channel tc class add dev eth1 parent 2:1 classid 2:2 htb rate 12500bps # guaranteed 70% tc class add dev eth1 parent 2:2 classid 2:3 htb rate 8750bps ceil 12500bps # g19.2 tc class add dev eth1 parent 2:3 classid 2:4 htb rate 125bps ceil 9625bps tc class add dev eth1 parent 2:3 classid 2:5 htb rate 2400bps ceil 2400bps # unguaranteed tc class add dev eth1 parent 2:2 classid 2:6 htb rate 3750bps ceil 12500bps # BG channel tc class add dev eth1 parent 2:1 classid 2:7 htb rate 6250bps # u77kbps tc class add dev eth1 parent 2:7 classid 2:8 htb rate 125bps ceil 9625bps # u19.2kbps tc class add dev eth1 parent 2:7 classid 2:9 htb rate 2400bps ceil 2400bps tc filter add dev eth1 parent 2:0 protocol all prio 1 tcindex mask 0x3 shift 0 tc filter add dev eth1 parent 2:0 protocol all prio 1 handle 2 tcindex classid 2:5 tc filter add dev eth1 parent 2:0 protocol all prio 1 handle 1 tcindex classid 2:4 tc filter add dev eth1 parent 1:0 protocol all prio 1 handle 1:0:0 u32 divisor 1 tc filter add dev eth1 parent 1:0 protocol all prio 1 u32 match u32 0xc0a80001 0xffffffff at 12 classid 1:1 tc filter add dev eth1 parent 1:0 protocol all prio 1 u32 match u32 0xc0a80002 0xffffffff at 12 classid 1:2 tc filter add dev eth1 parent 1:0 protocol all prio 1 u32 match u32 0 0 at 0 classid 1:0 police index 1 rate 1bps burst 1 action drop/drop =====================THE SCRIPT=================== #!/usr/bin/perl use strict; use vars qw(%o @in); use Getopt::Std; use Data::Dumper; getopts('f:',\%o); my %pos;#for storing class positions #used to cut unnececary vertical bars #too much effort for being beautiful :") my %child; #formats - pure, bitps, rate, idparent ...etc sub cformat { my ($line, $formats, $cls) = @_; my $res; for my $f (split /-/, $formats) { $line =~ s/class (\w+? \d+:\d+).+$/$1/ if $f eq 'pure'; $line =~ s/^.+(rate \d+\w+).+$/$1/ if $f eq 'rate'; $line =~ s!(\d+)bps!($1*8).'bs'!eg if $f eq 'bitps'; if ($f eq 'idparent') { if ($line =~ /classid/) { $line =~ s/^.+(parent.+classid \d+:\d+).+$/$1/} else { $line =~ s/class (.+parent \d+:\d+).+$/$1/ } }; $line = $pos{$cls}{comment}."\n" if $f eq 'comment'; }; return $line } #which is the nearest parent in this column in rows before me sub nearestInCol { my ($row, $col) = shift; #if u think u can make it harder do it :") my ($v) = sort { $pos{$_}{$b} <=> $pos{$_}{$b} } grep { $pos{$_}{row} < $row && $pos{$_}{col} == $col } keys %pos; return $v } #ascii-art sub art { my ($cls,$row) = @_; my $tab; for my $c (0 .. $pos{$cls}{col}) { my $nearest = &nearestInCol($row,$c); SWITCH: { if ($c > ($pos{$cls}{col})-1) { $tab .= '+-'; last SWITCH}; #dont even ask me what this is doing ... !!! if (#ok if nearest parent on this column doesnt have more childs below us cut it $c == $pos{$nearest}{col} || $row > $child{$nearest} ) { $tab .= ' '; last SWITCH}; $tab .= '| ' } } return $tab } #=======================MAIN===================== #leave only classes and comments and place comments in %pos open FILE, '-' or die 'hmmm... : $!'; my $comment; while () { if ($_ =~ /^\s*#/) {#this is comment just before class declaration ($comment) = $_ =~ /^\s*#(.+)$/; }; next unless $_ =~ /^(tc )?class/; $_ =~ s/^.*?(class.+)$/$1/; push @in, $_; if ($comment) { my ($classID) = $_ =~ /class(?:id)?\D+(\d+:\d+)/; $pos{$classID}{comment} = $comment } } close FILE; #build class position table my ($prevParent, $prevClassID, $myComment); my $c = 0;#column for my $r ( 1 .. $#in ) { my ($classID) = $in[$r] =~ /class(?:id)?\D+(\d+:\d+)/; my ($parent) = $in[$r] =~ /parent\D+(\d+:\d+)/; # print "$classID -- $parent\n"; unless ($parent eq $prevParent) { unless ($parent ne $prevClassID) { $c++ } else {$c = $pos{$parent}{col}+1} }; $pos{$classID}{col} = $c; $pos{$classID}{row} = $r; $prevParent = $parent; $prevClassID = $classID; $child{$parent} = $r; }; #print the tree my $row = 0; for my $cls (sort {$pos{$a}{row} <=> $pos{$b}{row}} keys %pos) { my $tab = art($cls,$row); print $tab.(cformat($in[$pos{$cls}{col}],$o{f},$cls)); $row++ }; From don-lartc@isis.cs3-inc.com Fri Sep 27 17:22:02 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Fri, 27 Sep 2002 09:22:02 -0700 Subject: [LARTC] RE: Help: Multiple internet connections (David H. Lynch Jr.) Message-ID: <15764.34218.431669.976310@isis.cs3-inc.com> > >> However I have problems with the servers/services that are being > >> DNATed to behind the firewall. > > >> It is my guess that the inbound packet manages its way to my > server > >> just fine, but on the return trip it decides to head back out the > >> cable modem as that is the best route back to the client, and since > >> the client sees a response coming from the wrong source it discards > >> it, but I could easily be wrong. > > >No, you are most probably right... I don't see it. The way to find out what's really going on is to record the relevant packets on both sides of the firewall. Here's my understanding of what should be happening: Your firewall has two public IP addresses, say 9.9.9.9 and 8.8.8.8. client 1.2.3.4 (say, port 1234) on internet sends request to your IP address, say 8.8.8.8 port 80. This arrives at your firewall where your dnat rule (= port forwarding) translates 1.2.3.4:1234->8.8.8.8:80 to 1.2.3.4:1234->10.0.1.2:80, then forwards the request to your internal server 10.0.1.2. This creates an entry in the firewall NAT table which will cause replies 10.0.1.2:80->1.2.3.4:1234 to translate back to 8.8.8.8:80->1.2.3.4:1234, which is what you want. Your server now sees a packet 1.2.3.4:1234->10.0.1.2:80, replies with a packet 10.0.1.2:80->1.2.3.4:1234, which your firewall translates to 8.8.8.8:80->1.2.3.4:1234 and sends out to 1.2.3.4. It doesn't even matter which interface this goes out, *unless* one of your providers is doing the ingress filtering that he really ought to. As far as I know, nobody actually does this, but if they do they should be willing to make an exception for you. So, above is at least one (unlikely) possible cause. In that case you could solve the problem by making sure packets with source address 8.8.8.8 route out the 8.8.8.8 interface. From wa@almesberger.net Sat Sep 28 02:05:45 2002 From: wa@almesberger.net (Werner Almesberger) Date: Fri, 27 Sep 2002 22:05:45 -0300 Subject: [LARTC] tctree + tcng In-Reply-To: <20020927182324.5303d56c.raptor@tvskat.net>; from raptor@tvskat.net on Fri, Sep 27, 2002 at 06:23:24PM -0400 References: <20020927182324.5303d56c.raptor@tvskat.net> Message-ID: <20020927220545.E29542@almesberger.net> raptor wrote: > OK, now it should support the output of the tcng too.... Cool. I like -f comment. Of course, people really ought to format their tcng source such that it's actually readable ;-)) BTW, I'll drop the pragma variant (too awkward), but include an improved version of com.pl in the next version of tcng, along with preprocessing support in tcc. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From druid@mail.cz Sat Sep 28 11:01:33 2002 From: druid@mail.cz (=?iso-8859-2?B?VmxhZGlt7XIgVPhlYmlja/0=?=) Date: Sat, 28 Sep 2002 12:01:33 +0200 Subject: [LARTC] ESFQ Message-ID: <001401c266d6$18462580$4500a8c0@cybernet.cz> Hi, I have little problem with ESFQ. I set root qdisc cbq on eth1 (which is on LAN side of network), then 1:1 cbq class with exact bandwidth and its two child - cbq 1:10 and cbq 1:20 with 1:1's bandwidth divided. I also set two ESFQ perturb 10 hash dst on those two classes. But when someone starts to download with 100 threads, he has much more bandwith than someone with only one. I understand that this is exactly what esfq should solve, so I think that somewhere on my side is mistake :-( This is my configuration: tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell 8 tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 10Mbit rate 256 Kbit weight 2.56 Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 isolated tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 10Mbit rate 32 Kbit weight 3.2 Kbit prio 1 allot 1514 cell 8 maxburst 18 avpkt 100 isolated tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 10Mbit rate 224 Kbit weight 2.24 Kbit prio 2 allot 1514 cell 8 maxburst 2 avpkt 1500 bounded tc qdisc add dev eth0 parent 1:10 handle 10: esfq perturb 10 hash dst tc qdisc add dev eth0 parent 1:20 handle 20: esfq perturb 10 hash dst iptables -t mangle -A PREROUTING -m length --length 0:500 -j MARK --set-mark 3 iptables -t mangle -A PREROUTING -m length --length ! 0:500 -j MARK --set-mark 4 tc filter add dev eth0 parent 1: protocol ip handle 3 fw flowid 1:10 tc filter add dev eth0 parent 1: protocol ip handle 4 fw flowid 1:20 Thank you very much for answer, Vladimir Trebicky From stef.coene@docum.org Sat Sep 28 11:06:11 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 28 Sep 2002 12:06:11 +0200 Subject: [LARTC] Transparent bridging / smart rate limiting In-Reply-To: <000001c1925a$d9907700$9604a8c0@twistpoint> References: <000001c1925a$d9907700$9604a8c0@twistpoint> Message-ID: <200209281206.11255.stef.coene@docum.org> On Tuesday 01 January 2002 01:25, Tor Inge Kloumann wrote: > I've decided to try to make a transparent bridge, that should drop > packet's based on some weird rules. > I have googled around a bit and couldn't find any information about wha= t > I would like to do. > And therefore I now send a mail to this mailinglist in hope that someon= e > can either help me, or point me in the right direction. > > What I want to do is the following: > Make a transparent bridge that starts dropping ICMP packets that are > oversized(malicious icmp), drop all syn packets that comes from spoofed > hosts(non existent ip's), drop other obvious malicious traffic. > My problem is not dropping packets(hehe), the problem is dropping > packets based on these rules, so that legit icmp/syn traffic etc will > not be affected by the rules. > I've done some testing with hogwash as transparent bridge to intercept > and block malicious packets. I was however not able to use hogwash to > drop icmp/syn based on above clearified rules. > > > If someone could point me in the right direction/maybe someone has some > examples(?) I would be very greatfull. Have you read the docs about iptables? It can match allmost everything. = =20 Search for the -m so you can call extra "helpers". You can use iptables on a linux bridge, but it requires some extra patche= s. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Sat Sep 28 12:20:14 2002 From: stef.coene@docum.org (Stef Coene) Date: Sat, 28 Sep 2002 13:20:14 +0200 Subject: [LARTC] ESFQ In-Reply-To: <001401c266d6$18462580$4500a8c0@cybernet.cz> References: <001401c266d6$18462580$4500a8c0@cybernet.cz> Message-ID: <200209281320.14465.stef.coene@docum.org> On Saturday 28 September 2002 12:01, Vladim=EDr T=F8ebick=FD wrote: > Hi, > > I have little problem with ESFQ. I set root qdisc cbq on eth1 (which is= on > LAN side of network), then 1:1 cbq class with exact bandwidth and its t= wo > child - cbq 1:10 and cbq 1:20 with 1:1's bandwidth divided. I also set = two > ESFQ perturb 10 hash dst on those two classes. But when someone starts = to > download with 100 threads, he has much more bandwith than someone with = only > one. I understand that this is exactly what esfq should solve, so I thi= nk > that somewhere on my side is mistake :-( This is my configuration: > > tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit avpkt 1000 ce= ll 8 > > tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 10Mbit rate 2= 56 > Kbit weight 2.56 Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 > isolated > > tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 10Mbit rate= 32 > Kbit weight 3.2 Kbit prio 1 allot 1514 cell 8 maxburst 18 avpkt 100 > isolated tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 10= Mbit > rate 224 Kbit weight 2.24 Kbit prio 2 allot 1514 cell 8 maxburst 2 avpk= t > 1500 bounded > > tc qdisc add dev eth0 parent 1:10 handle 10: esfq perturb 10 hash dst > tc qdisc add dev eth0 parent 1:20 handle 20: esfq perturb 10 hash dst > > iptables -t mangle -A PREROUTING -m length --length 0:500 -j MARK > --set-mark 3 > iptables -t mangle -A PREROUTING -m length --length ! 0:500 -j > MARK --set-mark 4 > > tc filter add dev eth0 parent 1: protocol ip handle 3 fw flowid 1:10 > tc filter add dev eth0 parent 1: protocol ip handle 4 fw flowid 1:20 > > Thank you very much for answer, You have to make class 1:1 bounded so it can not get more bandwidth than = it's=20 rate. And remove all isolated parameters. They are not working. In fact, if y= ou=20 add a isolated parameter to class 1:10 and 1:20 then these class will get= =20 more bandwidth then the parent allows even if the parent is bounded. I t= hink=20 it's a bug in cbq (more info on=20 http://www.docum.org/stef.coene/qos/tests/cbq/classes.html). tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit avpkt 1000 cell= 8 tc class add dev eth0 parent 1: classid 1:1 cbq bandwidth 10Mbit rate 256 Kbit weight 2.56 Kbit prio 1 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 10Mbit rate 3= 2 Kbit weight 3.2 Kbit prio 1 allot 1514 cell 8 maxburst 18 avpkt 100 tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 10Mbit rate 2= 24 Kbit weight 2.24 Kbit prio 2 allot 1514 cell 8 maxburst 2 avpkt 1500 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From root@dworf.com Sat Sep 28 12:36:27 2002 From: root@dworf.com (Dworf) Date: Sat, 28 Sep 2002 13:36:27 +0200 Subject: [LARTC] two internet connections + filter? Message-ID: <200209281336.27747.root@dworf.com> Hello, I hope i wont make it too complicated and sorry for my englihs... The company has multiple connections to the internet ADSL + CABLE + XDSL.= =2E.=20 and i only want to use two for load balancing for now. I have read the HO= WTO=20 and i got it up and working it works great but i still have a few questio= ns=20 if anyone could help! the setup is: ADSL on ETH0 and CABLE on ETH1 When i load balance on ADSL + CABLE i want to load balance only lets say = FTP,=20 WEB, SMTP and some other ports BUT NOT ssh, telnet and such applications.= I=20 want to have ssh and telnet outgoing connections only on my ADSL route. h= ow=20 can i do that? any ideas? and another thing... i was wondering if there is a patch or command or=20 somthing that could check if lets say CABLE line is used more then 80% an= d=20 ADSL is used less then 10% that the next connection would be made on ADSL= ? And the last one... about the route cache can i reduce the timeout in cha= che=20 from default 60s i think to lets say 1 and that when new connections are = made=20 they are more frequently reorganized over the load balance? thank you David From lists@quux.de Sat Sep 28 14:04:27 2002 From: lists@quux.de (Jens Link) Date: 28 Sep 2002 15:04:27 +0200 Subject: [LARTC] bridging and shaping In-Reply-To: <20020925112912.348818f4.arc_of_descent@gmx.net> References: <20020925112912.348818f4.arc_of_descent@gmx.net> Message-ID: <873cruw9ic.fsf@laptop.quux.de> Rohan Almeida writes: > Now, I want to convert the linux box to a > bridge, using (http://bridge.sourceforge.net) You should also take a look a ebtables: http://users.pandora.be/bart.de.schuymer/ebtables > I noticed that you have to patch the kernel Yes. > as well as iptables. No. > Does tc need to be patched? > Does this even work? > I mean is it possible to operate linux > in bridge mode and have bandwidth control also? I'm not sure. I think somebody asked the same question on the bridge or ebtables Mailinglist but I can't find it. Check the archives. Jens -- I just found out that the brain is like a computer. If that's true, then there really aren't any stupid people. Just people running Windows. From lists@quux.de Sat Sep 28 14:50:05 2002 From: lists@quux.de (Jens Link) Date: 28 Sep 2002 15:50:05 +0200 Subject: [LARTC] bridging and shaping In-Reply-To: <200209250956.59013.stef.coene@docum.org> References: <20020925112912.348818f4.arc_of_descent@gmx.net> <200209250956.59013.stef.coene@docum.org> Message-ID: <87n0q2rzoy.fsf@laptop.quux.de> Stef Coene writes: > > Now, I want to convert the linux box to a > > bridge, using (http://bridge.sourceforge.net) > This code is already available in kernel 2.4.x, so no patches > needed if you use a 2.4.x kernel. You still need the patch to make iptables work on the bridge interface. Jens -- I just found out that the brain is like a computer. If that's true, then there really aren't any stupid people. Just people running Windows. From devik@cdi.cz Sat Sep 28 15:17:08 2002 From: devik@cdi.cz (devik) Date: Sat, 28 Sep 2002 16:17:08 +0200 (CEST) Subject: [LARTC] HTB bug fix Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-2145597208-1033222628=:583 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Thomasz (and LARTC), regarding the crash-suite you send me. I located the bug and attached patch should fix it. Everyone who experienced crashes after "tc class change" ahould apply and let me know. If it will fix the issue I'll push it into 2.4.20 before stable one. Detail: "tc class change" applied to inner class overwrites internal union members because of missing test for leaf node. best regards, devik PS: thanks, Thomasz --8323328-2145597208-1033222628=:583 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="thomas_htb_fix.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="thomas_htb_fix.diff" LS0tIG5ldC9zY2hlZC9zY2hfaHRiLmMJVGh1IFNlcCAyNiAxMTo0MTowOCAy MDAyDQorKysgbmV0L3NjaGVkL3NjaF9odGIuYwlTYXQgU2VwIDI4IDE1OjUz OjU5IDIwMDINCkBAIC0xNSw5ICsxNSwxMSBAQA0KICAqCQkJaGVscGVkIGEg bG90IHRvIGxvY2F0ZSBuYXN0eSBjbGFzcyBzdGFsbCBidWcNCiAgKgkJQW5k aSBLbGVlbiwgSmFtYWwgSGFkaSwgQmVydCBIdWJlcnQNCiAgKgkJCWNvZGUg cmV2aWV3IGFuZCBoZWxwZnVsIGNvbW1lbnRzIG9uIHNoYXBpbmcNCisgKgkJ VG9tYXN6IFdyb25hLCA8dHdAZXRlci50eW0ucGw+DQorICoJCQljcmVhdGVk IHRlc3QgY2FzZSBzbyB0aGF0IEkgd2FzIGFibGUgdG8gZml4IG5hc3R5IGJ1 Zw0KICAqCQlhbmQgbWFueSBvdGhlcnMuIHRoYW5rcy4NCiAgKg0KLSAqICRJ ZDogc2NoX2h0Yi5jLHYgMS4xMyAyMDAyLzA1LzI1IDA5OjA0OjUwIGRldmlr IEV4cCAkDQorICogJElkOiBzY2hfaHRiLmMsdiAxLjE0IDIwMDIvMDkvMjgg MTI6NTU6MjIgZGV2aWsgRXhwIGRldmlrICQNCiAgKi8NCiAjaW5jbHVkZSA8 bGludXgvY29uZmlnLmg+DQogI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0K QEAgLTY5LDcgKzcxLDcgQEANCiAjZGVmaW5lIEhUQl9IWVNURVJFU0lTIDEv KiB3aGV0aGVyIHRvIHVzZSBtb2RlIGh5c3RlcmVzaXMgZm9yIHNwZWVkdXAg Ki8NCiAjZGVmaW5lIEhUQl9RTE9DSyhTKSBzcGluX2xvY2tfYmgoJihTKS0+ ZGV2LT5xdWV1ZV9sb2NrKQ0KICNkZWZpbmUgSFRCX1FVTkxPQ0soUykgc3Bp bl91bmxvY2tfYmgoJihTKS0+ZGV2LT5xdWV1ZV9sb2NrKQ0KLSNkZWZpbmUg SFRCX1ZFUiAweDMwMDA2CS8qIG1ham9yIG11c3QgYmUgbWF0Y2hlZCB3aXRo IG51bWJlciBzdXBsaWVkIGJ5IFRDIGFzIHZlcnNpb24gKi8NCisjZGVmaW5l IEhUQl9WRVIgMHgzMDAwNwkvKiBtYWpvciBtdXN0IGJlIG1hdGNoZWQgd2l0 aCBudW1iZXIgc3VwbGllZCBieSBUQyBhcyB2ZXJzaW9uICovDQogDQogI2lm IEhUQl9WRVIgPj4gMTYgIT0gVENfSFRCX1BST1RPVkVSDQogI2Vycm9yICJN aXNtYXRjaGVkIHNjaF9odGIuYyBhbmQgcGt0X3NjaC5oIg0KQEAgLTExNzQs NiArMTE3Niw4IEBADQogCXNrYl9xdWV1ZV9oZWFkX2luaXQoJnEtPmRpcmVj dF9xdWV1ZSk7DQogDQogCXEtPmRpcmVjdF9xbGVuID0gc2NoLT5kZXYtPnR4 X3F1ZXVlX2xlbjsNCisJaWYgKHEtPmRpcmVjdF9xbGVuIDwgMikgLyogc29t ZSBkZXZpY2VzIGhhdmUgemVybyB0eF9xdWV1ZV9sZW4gKi8NCisJCXEtPmRp cmVjdF9xbGVuID0gMjsNCiAJcS0+dGltZXIuZnVuY3Rpb24gPSBodGJfdGlt ZXI7DQogCXEtPnRpbWVyLmRhdGEgPSAodW5zaWduZWQgbG9uZylzY2g7DQog DQpAQCAtMTQzNCwxMiArMTQzOCwxNiBAQA0KIAlwYXJlbnQgPSBwYXJlbnRp ZCA9PSBUQ19IX1JPT1QgPyBOVUxMIDogaHRiX2ZpbmQgKHBhcmVudGlkLHNj aCk7DQogDQogCWhvcHQgPSBSVEFfREFUQSh0YltUQ0FfSFRCX1BBUk1TLTFd KTsNCi0JSFRCX0RCRygwLDEsImh0Yl9jaGcgY2w9JXAsIGNsaWQ9JVgsIG9w dC9wcmlvPSVkLCByYXRlPSV1LCBidWZmPSVkLCBxdWFudD0lZFxuIiwgY2ws Y2w/Y2wtPmNsYXNzaWQ6MCwoaW50KWhvcHQtPnByaW8saG9wdC0+cmF0ZS5y YXRlLGhvcHQtPmJ1ZmZlcixob3B0LT5xdWFudHVtKTsNCisJSFRCX0RCRygw LDEsImh0Yl9jaGcgY2w9JXAoJVgpLCBjbGlkPSVYLCBwYXJpZD0lWCwgb3B0 L3ByaW89JWQsIHJhdGU9JXUsIGJ1ZmY9JWQsIHF1YW50PSVkXG4iLCBjbCxj bD9jbC0+Y2xhc3NpZDowLGNsYXNzaWQscGFyZW50aWQsKGludClob3B0LT5w cmlvLGhvcHQtPnJhdGUucmF0ZSxob3B0LT5idWZmZXIsaG9wdC0+cXVhbnR1 bSk7DQogCXJ0YWIgPSBxZGlzY19nZXRfcnRhYigmaG9wdC0+cmF0ZSwgdGJb VENBX0hUQl9SVEFCLTFdKTsNCiAJY3RhYiA9IHFkaXNjX2dldF9ydGFiKCZo b3B0LT5jZWlsLCB0YltUQ0FfSFRCX0NUQUItMV0pOw0KIAlpZiAoIXJ0YWIg fHwgIWN0YWIpIGdvdG8gZmFpbHVyZTsNCiANCiAJaWYgKCFjbCkgeyAvKiBu ZXcgY2xhc3MgKi8NCisJCS8qIGNoZWNrIGZvciB2YWxpZCBjbGFzc2lkICov DQorCQlpZiAoIWNsYXNzaWQgfHwgVENfSF9NQUooY2xhc3NpZF5zY2gtPmhh bmRsZSkgfHwgaHRiX2ZpbmQoY2xhc3NpZCxzY2gpKQ0KKwkJCWdvdG8gZmFp bHVyZTsNCisNCiAJCS8qIGNoZWNrIG1heGltYWwgZGVwdGggKi8NCiAJCWlm IChwYXJlbnQgJiYgcGFyZW50LT5wYXJlbnQgJiYgcGFyZW50LT5wYXJlbnQt PmxldmVsIDwgMikgew0KIAkJCXByaW50ayhLRVJOX0VSUiAiaHRiOiB0cmVl IGlzIHRvbyBkZWVwXG4iKTsNCkBAIC0xNTAxLDE5ICsxNTA5LDIzIEBADQog I2VuZGlmDQogCX0gZWxzZSBzY2hfdHJlZV9sb2NrKHNjaCk7DQogDQotCWNs LT51bi5sZWFmLnF1YW50dW0gPSBydGFiLT5yYXRlLnJhdGUgLyBxLT5yYXRl MnF1YW50dW07DQotCWlmICghaG9wdC0+cXVhbnR1bSAmJiBjbC0+dW4ubGVh Zi5xdWFudHVtIDwgMTAwMCkgew0KLQkJcHJpbnRrKEtFUk5fV0FSTklORyAi SFRCOiBxdWFudHVtIG9mIGNsYXNzICVYIGlzIHNtYWxsLiBDb25zaWRlciBy MnEgY2hhbmdlLiIsIGNsLT5jbGFzc2lkKTsNCi0JCWNsLT51bi5sZWFmLnF1 YW50dW0gPSAxMDAwOw0KLQl9DQotCWlmICghaG9wdC0+cXVhbnR1bSAmJiBj bC0+dW4ubGVhZi5xdWFudHVtID4gMjAwMDAwKSB7DQotCQlwcmludGsoS0VS Tl9XQVJOSU5HICJIVEI6IHF1YW50dW0gb2YgY2xhc3MgJVggaXMgYmlnLiBD b25zaWRlciByMnEgY2hhbmdlLiIsIGNsLT5jbGFzc2lkKTsNCi0JCWNsLT51 bi5sZWFmLnF1YW50dW0gPSAyMDAwMDA7DQotCX0NCi0JaWYgKGhvcHQtPnF1 YW50dW0pDQotCQljbC0+dW4ubGVhZi5xdWFudHVtID0gaG9wdC0+cXVhbnR1 bTsNCi0JaWYgKChjbC0+dW4ubGVhZi5wcmlvID0gaG9wdC0+cHJpbykgPj0g VENfSFRCX05VTVBSSU8pDQotCQljbC0+dW4ubGVhZi5wcmlvID0gVENfSFRC X05VTVBSSU8gLSAxOw0KKwkvKiBpdCB1c2VkIHRvIGJlIGEgbmFzdHkgYnVn IGhlcmUsIHdlIGhhdmUgdG8gY2hlY2sgdGhhdCBub2RlDQorICAgICAgICAg ICBpcyByZWFsbHkgbGVhZiBiZWZvcmUgY2hhbmdpbmcgY2wtPnVuLmxlYWYg ISAqLw0KKwlpZiAoIWNsLT5sZXZlbCkgew0KKwkJY2wtPnVuLmxlYWYucXVh bnR1bSA9IHJ0YWItPnJhdGUucmF0ZSAvIHEtPnJhdGUycXVhbnR1bTsNCisJ CWlmICghaG9wdC0+cXVhbnR1bSAmJiBjbC0+dW4ubGVhZi5xdWFudHVtIDwg MTAwMCkgew0KKwkJCXByaW50ayhLRVJOX1dBUk5JTkcgIkhUQjogcXVhbnR1 bSBvZiBjbGFzcyAlWCBpcyBzbWFsbC4gQ29uc2lkZXIgcjJxIGNoYW5nZS4i LCBjbC0+Y2xhc3NpZCk7DQorCQkJY2wtPnVuLmxlYWYucXVhbnR1bSA9IDEw MDA7DQorCQl9DQorCQlpZiAoIWhvcHQtPnF1YW50dW0gJiYgY2wtPnVuLmxl YWYucXVhbnR1bSA+IDIwMDAwMCkgew0KKwkJCXByaW50ayhLRVJOX1dBUk5J TkcgIkhUQjogcXVhbnR1bSBvZiBjbGFzcyAlWCBpcyBiaWcuIENvbnNpZGVy IHIycSBjaGFuZ2UuIiwgY2wtPmNsYXNzaWQpOw0KKwkJCWNsLT51bi5sZWFm LnF1YW50dW0gPSAyMDAwMDA7DQorCQl9DQorCQlpZiAoaG9wdC0+cXVhbnR1 bSkNCisJCQljbC0+dW4ubGVhZi5xdWFudHVtID0gaG9wdC0+cXVhbnR1bTsN CisJCWlmICgoY2wtPnVuLmxlYWYucHJpbyA9IGhvcHQtPnByaW8pID49IFRD X0hUQl9OVU1QUklPKQ0KKwkJCWNsLT51bi5sZWFmLnByaW8gPSBUQ19IVEJf TlVNUFJJTyAtIDE7DQorCX0NCiANCiAJY2wtPmJ1ZmZlciA9IGhvcHQtPmJ1 ZmZlcjsNCiAJY2wtPmNidWZmZXIgPSBob3B0LT5jYnVmZmVyOw0K --8323328-2145597208-1033222628=:583-- From druid@mail.cz Sat Sep 28 15:21:00 2002 From: druid@mail.cz (=?iso-8859-2?B?VmxhZGlt7XIgVPhlYmlja/0=?=) Date: Sat, 28 Sep 2002 16:21:00 +0200 Subject: [LARTC] ESFQ note Message-ID: <000701c266fa$56e599a0$4500a8c0@cybernet.cz> I finally got the problem solved. Only I want is to notice: Beware of setting perturb too small, otherwise you'll got sinusoidal result of two traffics generated by two ip's but one ip downloading with many more threads. Until esfq builds the right hash table, the ip with more threads will get more bandwidth. Esfq will have practically no time to make that streams equivalent because in 10 seconds it must create a new table and everything repeats. I've got LAN with no more than 64 ip's so I could possibly set hash table not to rebuild at all so I set perturb to 10 minutes (600) and I'm perfectly satisfied ;-) Thank's to Stef Coene for his tests with CBQ !!! Vladimir Trebicky P.S.: The only remaining problem is that I have 486 with psched JIFFIES so the QoS doesn't shape much high bandwidth... :-( From lartc@24x7linux.com Sat Sep 28 15:41:54 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Sat, 28 Sep 2002 16:41:54 +0200 Subject: [LARTC] two internet connections + filter? In-Reply-To: <200209281336.27747.root@dworf.com> References: <200209281336.27747.root@dworf.com> Message-ID: <20020928144154.GA16942@localhost> On Saturday, 28 September 2002, at 13:36:27 +0200, Dworf wrote: > When i load balance on ADSL + CABLE i want to load balance only lets say FTP, > WEB, SMTP and some other ports BUT NOT ssh, telnet and such applications. I > want to have ssh and telnet outgoing connections only on my ADSL route. how > can i do that? any ideas? > It is easy. Just mark the traffic coming into the Linux router and then route depending on the marks set. For example: echo "100 ADSL" >> /etc/iproute2/rt_tables ip rule add fwmark 1 table ADSL ip route add table ADSL default via $ADSL_GW_IP iptables -t mangle -A PREROUTING --protocol tcp --destination-port 22 \ --jump MARK --set-mark 1 The above does the following: it creates a new routing table called ADSL, that is populated with just one route, a default one, through your ADSL router to the Internet. It additionally uses "iptables" to mark incoming packets going to the SSH well-known port. This traffic gets marked as "1", the mark matches the added "ip rule", so the packet is routed checking the table "ADSL". We configured a very similar setup here some time ago, and is working fine. Specifically, all traffic is routed along a FR line (costly and low bandwidth) but HTTP and FTP, that is routed through ADSL (cheap, high bandwidth). To load balance certain traffic among the two lines we should need to use something like: ip route add default nexthop via $ADSL_GW_IP dev $ETH_ADSL weigth 4 \ nexthop via $FR_GW_IP dev $ETH_FR weight 1 This should direct 80% of connections through ADSL and the remaining 20% through FR. As route selection is cached, all traffic for a certain TCP session will go to the same line. UDP traffic will be balanced per-packet. > and another thing... i was wondering if there is a patch or command or > somthing that could check if lets say CABLE line is used more then 80% and > ADSL is used less then 10% that the next connection would be made on ADSL? > I don't know if such a command exists (I don't think so). But you could get something similar with some monitoring and scripting. Hope this helps, in any case, check the Linux Advanced Routing and Traffic Shaping HOWTO at lartc.org, becasuse it contains much information related to what you try to implement. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From jtwatson@datakota.com Sat Sep 28 18:46:37 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Sat, 28 Sep 2002 13:46:37 -0400 Subject: [LARTC] Rip problems Message-ID: <200209281347.03095.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, =09I am running a portmaster for dialup customers. This portmaster has a= T1=20 connected to it, and is the gateway to the internet. Behind it I have a=20 class C network divided up into 4 subnets, netmask 255.255.255.192 or /26= =2E =20 One of the subnets is behind my linuxbox (the 192 network). The portmast= er=20 is running rip(1), so I installed routed on the linux box, and configured= it=20 to share its information. ie. EXPORT_GATEWAY=3D"no" SILENT=3D"no" When I start routed, the appropriate routes show up in the portmaster a= fter=20 about a 30 seconds, and all works good for about 2 1/2 minutes. Then the= =20 portmaster sets the Metric to 16 for the route to my subnet behind the=20 firewall, and routing quits working. If I restart routed, we will repeat= the=20 process. If I stop routed during the 2 1/2 mins, it will immediately set= the=20 Met to 16. This tells me that they are communicating because when I shut= =20 routed down the metric is set to 16. But why does this happen exactly at= 2=20 1/2 min?? I am quite confused? Any suggestions would be great. - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lesTABydhMNsDgMRAuZzAKCDKkKGviW6PYX4YxDyTfyzikNhHQCeLiSz +cONh6fjWlgOY4eirljT0CI=3D =3DvgXh -----END PGP SIGNATURE----- From jtwatson@datakota.com Sat Sep 28 20:10:12 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Sat, 28 Sep 2002 15:10:12 -0400 Subject: [LARTC] Rip problems In-Reply-To: <200209281347.03095.jtwatson@datakota.com> References: <200209281347.03095.jtwatson@datakota.com> Message-ID: <200209281510.15727.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have identified the source of the problem, but not the cause of it. Her= e is a output from tcpdump that shows the rip traffic from the routed process on the linuxbo= x. Again I have configured routed as follows: EXPORT_GATEWAY=3D"no" SILENT=3D"no" and it gets its information from the network setup on the localmachine. in the following output, all xx.xx.xx. represent the same class C address= =2E [root@dwwireless httpd]# tcpdump -ni eth0 udp port 520 and src host xx.xx= =2Exx.52 tcpdump: listening on eth0 12:33:16.427345 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:33:21.658707 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(16) {xx.xx.xx.0}(16) (DF) <----- restarted routed ------ 12:33:22.359761 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-req 24 (DF) 12:33:52.358588 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:34:22.359529 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:34:52.360541 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:35:22.361625 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:35:52.362543 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:36:22.365285 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF) 12:36:52.364554 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF) 12:37:22.365592 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:37:52.366556 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:38:22.367531 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:38:52.368547 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:39:22.369516 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:39:52.370524 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:40:22.371571 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:40:52.372525 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:41:22.373521 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:41:52.374513 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:42:22.375511 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:42:28.221015 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(16) {xx.xx.xx.0}(16) (DF) <---- restarted routed ------- 12:42:28.937439 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-req 24 (DF) 12:42:59.066864 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:43:29.067806 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:43:59.068802 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:44:29.069811 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:44:59.070798 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF) 12:45:29.073590 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF) 12:45:59.072795 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:= {xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF) 12:46:29.073861 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:46:59.074794 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:47:28.741356 xx.xx.xx.52.520 > xx.xx.xx.62.520: RIPv1-resp [items 13]= : {xx.xx.xx.65}(2) {xx.xx.xx.67}(2)[|rip] (DF) 12:47:29.075708 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) 12:47:59.076795 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:= {192.168.1.0}(1) {xx.xx.xx.0}(1) (DF) As you can see, routed is expiring the route xx.xx.xx.192 network, and ad= ding one to the hole class C block. This is obviously wrong, and I don't know why it is changing its routing = information in mid swing??? Any Ideas? - -- Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lf6UABydhMNsDgMRAlT4AKDaZwYQHEzVA/VQGuadgeUlwcptsQCgxOyU LWz1POL9TDTO+LELeMkFS3s=3D =3DyRZe -----END PGP SIGNATURE----- From jtwatson@datakota.com Sat Sep 28 20:46:37 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Sat, 28 Sep 2002 15:46:37 -0400 Subject: [LARTC] Rip problems In-Reply-To: <04a701c26726$b6ef00d0$160aa8c0@mtbrook.boreham.org> References: <200209281347.03095.jtwatson@datakota.com> <200209281510.15727.jtwatson@datakota.com> <04a701c26726$b6ef00d0$160aa8c0@mtbrook.boreham.org> Message-ID: <200209281546.38623.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 28 September 2002 03:39 pm, you wrote: > >Any Ideas? > > I've not been following closely, but could this be a RIPv1 vs RIPv2 thi= ng ? > > (As I understand things, RIPv1 did not support CIDR, but RIPv2 does). Im not sure, but it worked for the first few minutes and then routed star= ted=20 changing the routing tables, and I don't know where this info was coming from??? I think I am going to try gated. - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lgcdABydhMNsDgMRAkvBAJ9YOpwPcYrY8rIYzXbcDEyYK/PVkgCg2xiG bnfpmXr42tUrqFNr8WAMdSI=3D =3D+cEd -----END PGP SIGNATURE----- From ury@bofh.homeunix.org Sun Sep 29 00:02:18 2002 From: ury@bofh.homeunix.org (Ury) Date: Sun, 29 Sep 2002 02:02:18 +0300 Subject: [LARTC] qos setting up Message-ID: <20020929020218.4f95c4b1.ury@bofh.homeunix.org> This is a multi-part message in MIME format. --Multipart_Sun__29_Sep_2002_02:02:18_+0300_082226b0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit what about this script fot HTB setup, as filter can use u32 and fw filters. __Ury --Multipart_Sun__29_Sep_2002_02:02:18_+0300_082226b0 Content-Type: application/x-bzip2; name="qos.tar.bz2" Content-Disposition: attachment; filename="qos.tar.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWe6bEMsADIH/hfywAEB//////+////////8AAIAQAAhgC1fAvZLXVjUcq3bZ3F3A OAGig0BoBhJISYI1NME8lG0ajEYmmR6TRkyZGmI0GmINANNBoDEQmiYmUZFPR5NU/JlGpkzRoaAT TIYQYTAmADQmOGI000GgDQAAAA0GQaaBoANGgDENAM0klPKanqeoAA09QANAAGQDQAAGgADQDhiN NNBoA0AAAANBkGmgaADRoAxDQCRICTQ0CaaaBGSZMU9Mk0yaMQ9TINNGgaemppk0aNpNKPWfB6// yZRokYCaE2BIFxDI7aIJc59FMCARXhEycB3pdm288EsBCBoGK+LIYmANicIEfz9W+S8TGxNis0EN ILMm1Ngk2CGRAmIdXBzxAmDIo4EORCTCkQCtY+1rwKC7Mc4Swryoqi6XbMliTqyY34fi88tNFGTC xgPKfLrryVhyoRtc25M14ePK1CwNrOOHDgWppSsODNKkp0gnTTImUikE2WzS24z3Tqx4brzUxb/1 ckK1KSYCGs0FuMYoTui6E0S4diQ9meh4e2+WHCDlrSnfaVUStSyUhGTeSGGDiMp2NbmZhfTP5p43 t7+NLjfGKVUUbGw+nNEhlnhLvvW20UpLIjS262WIkJFnai4y9FCAAD60xAsXVppNq2KyGDSUIkgQ m0JDBITD+lCVNA0JMQ2oJQaESJEBNYx0mANMXmMCkJe6jlSXroNNTwQvonqzxe7/yNDYMMcU6kBe V0/iJ8O+GrGNfBNqoEoXwvmoWSdS1zUckZ6mlozHRVBtQT0oNOeRnLkGD1PjgUtOrD7M8jfAoHue p6+CvXs9vOMhhzYmAh9uSzJbt2s0vgoHXMu9l5938xkqF2LBQmwgOblgMbXk4rLZE9XcMwumVX8f /bFaTi5PZhUwUkbx+YhiEtU46xQ56x7nAx3PJTm4KIGtG7BqutohpG3HOAqDuXqjUzVY0C8BKjLt Rip2UYAuINFH4bE/LS1/8McAwXCsXYGJ2RdCTWkn1JITYabt5ciwC2YzjYdk77BaykPrf3IjRhNr BzWnpvex/sN3DoHzw7fDE7WGsV2dfTXfCVz2k7c6wUo7i3i5J85HHmz5+g6eCwi9U9BbntoSuS7E Yi2TFpGy8YsWC2FWhIYtcZsiKIQVf+5KQDcNayjVUzFwNpJpL2oQU0IN8LLOFlSie2xkxpk70YdW HilzxKVGBuw8M0szTe8g0qIybTYSYQAQzUwMOXHq7Cpx5eunuB5g6IhibCRPGKmSMiqnBURKn0a6 lvpVJlzH49mtHN2CQ7jKX4FYrCaqLQAQACvGw0GCQmCXKOTKNHdZUeAy/yuJY2iIJJMTSI5kFIws 6qJIk24r74sQreJysJYEKCWFoGNq5RZUpOp9GJNIsqpjTDaNDM5mQC6eVdPvnpZxyoZswzZoPI0K dPplOcKgjSVF2DOc4JGC4sQEw62S1tokiEvQyj7rhwwMsG5sm1At6Jnzkm4wtsYxrlbBQM8roX6w g/rolKvNYDWI0fABUJwVxfk94lfz3a+MPjEhF962wbSAS7CH6CeBKtzkud6j3O6GDcA7QcJwJxgj ilOnQ1tTeq468gmqc7VcPsDqmzmjwOdlOdp2TY0JZjhoBZRQ2lVsBYrRKJxIVEA0LT4idgU7CVaN ZWluF9Sy4gmd66wr1d6BRnklnST3Q6+zSEtRLbHv+Vwa2hjqMVZEpJFxuMWT1165Fiw8Ud8M2EHo UUHJ4V5PBssFKnxi2ksKyUWrqJ6p2nGEp0ZW1K5EpT96cXNWbNauFqMJk5kVlYkqAe20ZN7Hxae5 7kpglanUvkLEdlG8Fx83Uy0XQ1QnOn+ROVG7gnv0RCQ58R8pNHlrTUyiGiA00wXUrdyRVWfrtZax a0pZ2mS0WCplr1I8tQshkdphX7jkAVkF9F5gNYxS3mgrGO96YYhdkmClXp39/KtW4DNurmGXOGJJ kAGzA5C5GEpu/T8EJmrjncLb8vrbn39kr6EXu6cZKeeCUxNIlUVt/jI4rrHPSc90YoYqKHJpDc41 xQxspX0PLExGEEAGAmLPwmKaE7edeZK/cPkZEZEgAv2nwhSRc2LofT0M97zImzca2PVKpVBbS5bt JAcVBshpOHDN+sIe3U1S7mdSHFhK+niQRePvUZYbRwOcwzM0D830tfbFYXzVSdyrxNjjNhQNJvMH IRemSOJBvDCv/Cf4QvPfWjBaMQF8TS+FcclXQzdKiDogCiWAwxsvnWwKlEUCgx3ofCwI5vTlcFTx dAYlrRERkL9FjauOk4gxjDOxQ9OwVgsrICF2ZEavwUMJDSmbJQBZ9OCBFrhPwDRozlUzWZyLyBMG JnuS4INETBsBjBlEiHWJKSDx0QeTQHdwehSQwDODHk0tRsPzlF2pXOSXIi1jWhVQmPgeh7yfJmHu 1+q0ws4iCJNLn7mNSlKtsdsEmUEY886Wo5kpkHQL7hzvizzkhqAO8GcV/YmQpchyXAJ+s2xBNCM0 1hSJCV5Qw8urLHQYxtO3RwuVRnAGwRM9D+0f1LrzGJx4+Hcku6+UEhyESdyGoyGSDajaTYiFkWIu 2PORpMKSLAsjlWo2JpgxtMaKkdTM9e6FEyC2rrSClS7bpp0iNsmm6IXeOf6Ta0boTGLE4hP5lRqh GAduMC8mtsbDkmuO6OHk7TVY6oKgClABGGwmqaMwkdkWBc2Z5WkWjLZwbpo/E59ydrgoAWhoFxRS JDF5X7KzoKme20dmmpU2waDEPYqk9EDds1uQjNK6qpBg2BISupxCg0yopqodvabZdLHOZI9O+pkg RcpjBz56UznWkDqFq8rIU5fUAqSksDUTSUyo1wG0ZjCSbTENhSARQiUSBdLSP35pB8gdxGHtagqn pmYSRMR2YKmviENPTFWFsSwZLJFoTmCcHmWr1mi0WFKpcdDDJVmUOxlpZ0uSFvgCXTMPXuU6GHiW BuQN90OhHTX11m4sRBAuxzCENZGSCEcAWzbC2pBzpkKiWxPSttGwbYN7Ilviakkp0NCNGg38doZg V8Mx0GPq+v79Ofv4AHH2OC5scqhqUtwXAFlRVqidDlwX3LAKBey4tbZPNEQEdXmV5/IVwFLUzs4a vbO/WUzTvcUnBcrTwnrZz7DQNhxNSvfclLdlgMaRomJgyfkg+Z3ZlQbS7nS0wGtVV2d+/3viq8AB 4KBvnzwYbZGMoIDLXiBmBW3BjyqCCLxCYm+xopZgQR3+C3nGlCyxTMMYgeZcrCGii0CWagE00J4d hABnC4I4ArDt1GO7SGAoAuRoMCWcIRgollYVvJ5YFVHeEXWjxmgrINaaPGJrb4/vWm4W1iXMxk2O cpGdgtkkZNCmmTFlVQixAc7N6F7N7i+WUpI2oDFj5ibA1lDcAcUfOjqQzJg2jM/UzU0KdPdQoH/A baAXD3CGqpFPb57/aA8YxTCpNEiXrSaUgY5d5BGmEWlALZshIhgNOKyQQ0uGN/7SstEzxgTIP+Lu SKcKEh3TYhlg --Multipart_Sun__29_Sep_2002_02:02:18_+0300_082226b0-- From mattt@above.nq4u.net Sun Sep 29 04:27:53 2002 From: mattt@above.nq4u.net (Mattt) Date: 29 Sep 2002 13:27:53 +1000 Subject: [LARTC] Some QoS and PPPoE q's... Message-ID: <1033270073.604.51.camel@hellbringer> Greetings List'ers :-) Have been playing around with QoS, and have a problem, and some questions... Oh yeah, Debian Woody, 2.4.19, 512/128(pppoe). Problem : kernel oops's (sadly, unlogged - though I have a display on the router, so could transpose the oops if need be...). Using either version of WonderShaper (CBQ), I get a kernel oops - it seems to take a little longer with the older version, but mebbe that's co-inkydink... I manually entered the script from the lartc howto, and that seemed to be okay (tested for about five mins so far, then tried WS1.0, which oops'ed in less than 3...). I haven't gotten as far as any link testing yet, but things 'feel' different when the shapers are up... I'm using the Debian PPPoE package at present, but have built support into the new (QoS-enabled) kernel, and will no doubt switch to that (does anyone have any comments about the value of such a move?). Question : I have a Billion aDSL modem/router/etc. It has a web interface and all manner of other features. This stuff (particualrly the interface) are normally sucked through the ethernet (or usb, but we don't touch that...) connection to the host. However, I put the modem into bridged mode so I could use PPPoE/shaping/netfilter, etc on the Linux router, which entails *not* assigning an address to the NIC. Of course, this stops me from being able to access the modem's web interface. I guess it's hardly that important, given the setup, but it would still be nice to be able to at least get to it in case it's ever necessary (for a quick test-bench reconfig and back, perhaps...). Everything still seems to work when the interface *does* have an IP, though - is it okay to have an address on this NIC? Could that be what's choking tc (probably not, as it still oops'es the kernel with no address on it...). The router in question has three legs - one going to the 'secure' local network, one going to the DSL 'modem', and one (two transparently bridged NICS) going to the DMZ, in case any of that matters. -- Cheers, Mattt icq : 117539757 Network and Tech Dood, www : above.nq4u.net aboveNetworks. mattt@above.nq4u.net jabber: mattt@jabber.expressnet.net.au What's got four legs and an arm? A happy Pit Bull... From ramin@cannon.eng.us.uu.net Sun Sep 29 04:43:57 2002 From: ramin@cannon.eng.us.uu.net (Ramin Alidousti) Date: Sat, 28 Sep 2002 23:43:57 -0400 Subject: [LARTC] Rip problems In-Reply-To: <200209281546.38623.jtwatson@datakota.com> References: <200209281347.03095.jtwatson@datakota.com> <200209281510.15727.jtwatson@datakota.com> <04a701c26726$b6ef00d0$160aa8c0@mtbrook.boreham.org> <200209281546.38623.jtwatson@datakota.com> Message-ID: <20020929034357.GA21653@cannon.eng.us.uu.net> On Sat, Sep 28, 2002 at 03:46:37PM -0400, Joseph Watson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 28 September 2002 03:39 pm, you wrote: > > >Any Ideas? > > > > I've not been following closely, but could this be a RIPv1 vs RIPv2 thing ? > > > > (As I understand things, RIPv1 did not support CIDR, but RIPv2 does). Yes, it's correct, RIPv1 is classful. > Im not sure, but it worked for the first few minutes and then routed started > changing the routing tables, and I don't know where this info was coming > from??? Can you explain what exactly was working in the first few minutes? Did you actually see a /26 route on the portmaster? There are a few timers in RIP. The 30 sec you mentioned reminds me of the the update advertisement timer and the 3 min interval is the holddown timer. What is the topology and where does the remaining block (C - /26) reside? You said that you have a class C. Is it a class C or a /24? iaw what is the natural class of your netblock? Do you also run RIP between the portmaster and that other part? This is important because if you do you'll end up having two different routes to the same natural class of your netblock which is not what you want. > I think I am going to try gated. A better choice is zebra if you're already familiar with cisco syntax. Does your portmaster support OSPF? Ramin > > - -- > Regards > > Joseph Watson > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9lgcdABydhMNsDgMRAkvBAJ9YOpwPcYrY8rIYzXbcDEyYK/PVkgCg2xiG > bnfpmXr42tUrqFNr8WAMdSI= > =+cEd > -----END PGP SIGNATURE----- > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From jtwatson@datakota.com Sun Sep 29 06:16:43 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Sun, 29 Sep 2002 01:16:43 -0400 Subject: [LARTC] Rip problems In-Reply-To: <20020929034357.GA21653@cannon.eng.us.uu.net> References: <200209281347.03095.jtwatson@datakota.com> <200209281546.38623.jtwatson@datakota.com> <20020929034357.GA21653@cannon.eng.us.uu.net> Message-ID: <200209290118.07853.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 28 September 2002 11:43 pm, Ramin Alidousti wrote: > Can you explain what exactly was working in the first few minutes? Did = you > actually see a /26 route on the portmaster? There are a few timers in R= IP. > The 30 sec you mentioned reminds me of the the update advertisement tim= er > and the 3 min interval is the holddown timer. What is the topology and > where does the remaining block (C - /26) reside? You said that you have= a > class C. Is it a class C or a /24? iaw what is the natural class of you= r > netblock? Do you also run RIP between the portmaster and that other par= t? > This is important because if you do you'll end up having two different > routes to the same natural class of your netblock which is not what you > want. > > > I think I am going to try gated. > > A better choice is zebra if you're already familiar with cisco syntax. > Does your portmaster support OSPF? > > Ramin I will try to be as complete as possible :) I have a /24, ie xx.xx.xx.0 - xx.xx.xx.255 This is split into 4 subnets ie /26 The xx.xx.xx.0/26 subnet is used on the network that the portmaster is pl= ugged into. I also have a second Portmaster on this network, and xx.xx.xx.63/26 is as= igned=20 to the modem pool split between the portmasters. The routing is taken ca= re of=20 by rip on the two portmasters. Now on the same xx.xx.xx.0/26 network, I have a linux box. Behind this=20 Linux Box is where I have the xx.xx.xx.128/26 network. xx.xx.xx.192/26 is not being used now. ,---modems in the xx.xx.xx.64/26 ---, ,-----'------. ,-----'-------. - ---T1--CSU/DSU--| portmaster |---xx.xx.xx.0/26-------| portmaster2 | `------------` | `-------------` =20 ,--------------. | Linux Box | `--------------` | xx.xx.xx.128/26 Now, I am monitoring the routing tables in the portmaster connected to th= e=20 T1. Since it is the gateway this is what matters for incoming traffic. = When I start routed on the linuxbox, after 30 seconds it broadcasts its info, = and the portmaster updated its routes with a xx.xx.xx.128/26: I can then acce= ss=20 clients on the xx.xx.xx.128/26 network behind the linux box. But after=20 3min's, routed start brodcasting the route to the 128/26 network with a=20 metric of 16. And as expected, I can't access the 128/26 network anymore= =2E Then it started broadcasting a route to the xx.xx.xx.0/24 network???? Wh= ere=20 does it get this from?? What I can't figure out is why routed changes wh= at=20 it is broadcasting?? =20 So it is something to do with routed on the linux box! I monitored all r= ip=20 traffic with tcpdump (a previous post has this info) and nothing else is=20 telling it to change the routing. The only other rip divices on the netw= ork=20 are the portmasters, and they are taking care of the xx.xx.xx.64/26 netwo= rk=20 that the modems are on. Gated talks about routes from the local interface config timing out, and=20 there is config options to prevent this. Maybe this is what I am seeing with routed?? I have added a static route to the portmaster until I can figure this out= =2E Thanks for the help - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lozxABydhMNsDgMRAmJ7AKC2cS/bNkAbaJIQBojSTpnU1yRqsgCffk+D yCXIDHSYEUNPVm1qrkek4mg=3D =3DmzJ/ -----END PGP SIGNATURE----- From brt_informatics@wlink.com.np Sun Sep 29 06:40:26 2002 From: brt_informatics@wlink.com.np (brt_informatics@wlink.com.np) Date: 29 Sep 2002 05:40:26 -0000 Subject: [LARTC] HTB or CBQ ? Message-ID: <20020929054026.15262.qmail@mail2.wlink.com.np> Hi.. I've tried both (HTB & CBQ) the queuing descpliens and I think HTB is more efficient than CBQ. But i think HTB is still in beta. I just want to know if I can go for HTB right away. I mean, is it stable? I'm trying to implement it in my company and thus stability and performance is big issue in this case. Please correct me if i'm wrong. Thank you very much, Bikrant From mattt@above.nq4u.net Sun Sep 29 09:05:42 2002 From: mattt@above.nq4u.net (Mattt) Date: 29 Sep 2002 18:05:42 +1000 Subject: [LARTC] UPDATE: Re: [LARTC]Some QoS and PPPoE q's... In-Reply-To: <1033270073.604.51.camel@hellbringer> References: <1033270073.604.51.camel@hellbringer> Message-ID: <1033286742.790.61.camel@hellbringer> Small update - I just transposed the Wondershaper from the howto (that I thought was okay before) into a script - it lasted about 1min :-/ Unfortunately, I forgot to take down the oops message before rebooting the box... On Sun, 2002-09-29 at 13:27, Mattt wrote: > Greetings List'ers :-) > > Have been playing around with QoS, and have a problem, and some > questions... Oh yeah, Debian Woody, 2.4.19, 512/128(pppoe). > > Problem : kernel oops's (sadly, unlogged - though I have a display on > the router, so could transpose the oops if need be...). Using either > version of WonderShaper (CBQ), I get a kernel oops - it seems to take a > little longer with the older version, but mebbe that's co-inkydink... I > manually entered the script from the lartc howto, and that seemed to be > okay (tested for about five mins so far, then tried WS1.0, which oops'ed > in less than 3...). I haven't gotten as far as any link testing yet, but > things 'feel' different when the shapers are up... I'm using the Debian > PPPoE package at present, but have built support into the new > (QoS-enabled) kernel, and will no doubt switch to that (does anyone have > any comments about the value of such a move?). > > Question : I have a Billion aDSL modem/router/etc. It has a web > interface and all manner of other features. This stuff (particualrly the > interface) are normally sucked through the ethernet (or usb, but we > don't touch that...) connection to the host. However, I put the modem > into bridged mode so I could use PPPoE/shaping/netfilter, etc on the > Linux router, which entails *not* assigning an address to the NIC. Of > course, this stops me from being able to access the modem's web > interface. I guess it's hardly that important, given the setup, but it > would still be nice to be able to at least get to it in case it's ever > necessary (for a quick test-bench reconfig and back, perhaps...). > Everything still seems to work when the interface *does* have an IP, > though - is it okay to have an address on this NIC? Could that be what's > choking tc (probably not, as it still oops'es the kernel with no address > on it...). The router in question has three legs - one going to the > 'secure' local network, one going to the DSL 'modem', and one (two > transparently bridged NICS) going to the DMZ, in case any of that > matters. > > -- > Cheers, > Mattt icq : 117539757 > Network and Tech Dood, www : above.nq4u.net > aboveNetworks. > mattt@above.nq4u.net jabber: mattt@jabber.expressnet.net.au > > What's got four legs and an arm? A happy Pit Bull... > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Cheers, Mattt. icq : 117539757 aboveNetworks www : www.above.nq4u.net mattt@above.nq4u.net jabber: mattt@jabber.above.nq4u.net What's got four legs and an arm? A happy Pit Bull... From mattt@above.nq4u.net Sun Sep 29 09:54:47 2002 From: mattt@above.nq4u.net (Mattt) Date: 29 Sep 2002 18:54:47 +1000 Subject: [LARTC] UPDATE: Re: [LARTC]Some QoS and PPPoE q's... In-Reply-To: <1033286742.790.61.camel@hellbringer> References: <1033270073.604.51.camel@hellbringer> <1033286742.790.61.camel@hellbringer> Message-ID: <1033289687.790.72.camel@hellbringer> Alrighty... I seem to have gotten to the bottom of the oops dilemnas... I was attaching the qdiscs to ppp0 - I've now (for the last 15-odd minutes) got them attached to eth3 (the interface the DSL device is attached to) and all seems well (although there's not enough traffic right now to see how it's working...). So that just leaves my other question... To re-iterate, I have a Billion modem - these little guys are rather feature-rich, and said features are configured via a web interface. I've disabled all the routing, etc in the device, and set it to bridge mode, so I can use PPPoE on the Linux router to which it's attached (for shaping and fw'ing). Owing to this, I am bringing up the interface without an IP. This means I now, for instance, can't easily connect to it from a workstation and, say, upload a new firmware... There are other ways to go about it anyways (like attaching an IP to eth3 on the router before I need to do such stuff to the Billion), but it would be a lot handier to be able to connect anytime (there are also some good line, etc, diags in the interface) without having to play around. So, my question - it all seems to work (the DSL connection, routing, etc) when the interface *has* an IP, so it it important to *not* have one? Will this react badly with QoS, etc (having said it worked, there was no shaping running at the time)? On Sun, 2002-09-29 at 18:05, Mattt wrote: > Small update - I just transposed the Wondershaper from the howto (that I > thought was okay before) into a script - it lasted about 1min :-/ > > Unfortunately, I forgot to take down the oops message before rebooting > the box... > > On Sun, 2002-09-29 at 13:27, Mattt wrote: > > Greetings List'ers :-) > > > > Have been playing around with QoS, and have a problem, and some > > questions... Oh yeah, Debian Woody, 2.4.19, 512/128(pppoe). > > > > Problem : kernel oops's (sadly, unlogged - though I have a display on > > the router, so could transpose the oops if need be...). Using either > > version of WonderShaper (CBQ), I get a kernel oops - it seems to take a > > little longer with the older version, but mebbe that's co-inkydink... I > > manually entered the script from the lartc howto, and that seemed to be > > okay (tested for about five mins so far, then tried WS1.0, which oops'ed > > in less than 3...). I haven't gotten as far as any link testing yet, but > > things 'feel' different when the shapers are up... I'm using the Debian > > PPPoE package at present, but have built support into the new > > (QoS-enabled) kernel, and will no doubt switch to that (does anyone have > > any comments about the value of such a move?). > > > > Question : I have a Billion aDSL modem/router/etc. It has a web > > interface and all manner of other features. This stuff (particualrly the > > interface) are normally sucked through the ethernet (or usb, but we > > don't touch that...) connection to the host. However, I put the modem > > into bridged mode so I could use PPPoE/shaping/netfilter, etc on the > > Linux router, which entails *not* assigning an address to the NIC. Of > > course, this stops me from being able to access the modem's web > > interface. I guess it's hardly that important, given the setup, but it > > would still be nice to be able to at least get to it in case it's ever > > necessary (for a quick test-bench reconfig and back, perhaps...). > > Everything still seems to work when the interface *does* have an IP, > > though - is it okay to have an address on this NIC? Could that be what's > > choking tc (probably not, as it still oops'es the kernel with no address > > on it...). The router in question has three legs - one going to the > > 'secure' local network, one going to the DSL 'modem', and one (two > > transparently bridged NICS) going to the DMZ, in case any of that > > matters. > > > > -- > > Cheers, > > Mattt icq : 117539757 > > Network and Tech Dood, www : above.nq4u.net > > aboveNetworks. > > mattt@above.nq4u.net jabber: mattt@jabber.expressnet.net.au > > > > What's got four legs and an arm? A happy Pit Bull... > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > -- > Cheers, > Mattt. icq : 117539757 > aboveNetworks www : www.above.nq4u.net > mattt@above.nq4u.net jabber: mattt@jabber.above.nq4u.net > > What's got four legs and an arm? A happy Pit Bull... > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Cheers, Mattt. icq : 117539757 aboveNetworks www : www.above.nq4u.net mattt@above.nq4u.net jabber: mattt@jabber.above.nq4u.net What's got four legs and an arm? A happy Pit Bull... From stef.coene@docum.org Sun Sep 29 10:18:09 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 29 Sep 2002 11:18:09 +0200 Subject: [LARTC] HTB or CBQ ? In-Reply-To: <20020929054026.15262.qmail@mail2.wlink.com.np> References: <20020929054026.15262.qmail@mail2.wlink.com.np> Message-ID: <200209291118.09534.stef.coene@docum.org> On Sunday 29 September 2002 07:40, brt_informatics@wlink.com.np wrote: > Hi.. > I've tried both (HTB & CBQ) the queuing descpliens and I think HTB is > more efficient than CBQ. But i think HTB is still in beta. I just want > to know if I can go for HTB right away. I mean, is it stable? I'm > trying to implement it in my company and thus stability and performance > is big issue in this case. > Please correct me if i'm wrong. It's not because cbq is in the kernel for a long time that it is stable. = I=20 know more bugs/problems with cbq then with htb. I think htb is better because : - design - less obscure options - actively maintained - faster - included in kernel 2.4.20 :) Just my 2=A2 Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From Adi@iNterNUX.co.id Mon Sep 23 04:29:26 2002 From: Adi@iNterNUX.co.id (Adi Nugroho) Date: Mon, 23 Sep 2002 11:29:26 +0800 Subject: [LARTC] htb2 with link sharing - the bandwidth dividing question In-Reply-To: <20020723184901.029AEDB9AC@tartarus.telenet-ops.be> References: <00b601c2322b$00c331d0$6403a8c0@unzeitig> <20020723184901.029AEDB9AC@tartarus.telenet-ops.be> Message-ID: <200209231129.26673.Adi@iNterNUX.co.id> On Wednesday 24 July 2002 02:49, Stef Coene wrote: > Actually, the remaining bandwidth is not divided proportional to the rate, > but to quantum. Helo.... I would like to ask about r2q and quantum. I'm using sfq, which has also something named quantum. the question is.... I I want that the remaining bandwidth to be devided proportional to the rate, which one shuld I set... * sfq quantum? * or htb quantum? * or both? Second question, how can we set r2q lower than 1? I would like to set my r2q to 0.1. Thank you in advance, Adi Nugroho From gypsy@iswest.com Sun Sep 29 19:05:11 2002 From: gypsy@iswest.com (gypsy) Date: Sun, 29 Sep 2002 10:05:11 -0800 Subject: [LARTC] Tune and tweak WonderShaper - How?? Message-ID: <3D9740D7.699C4B11@iswest.com> First, it is impossible for there to be LENDED without BORROWED. (And proper English would be LOANED not LENDED.) Second, where is a (console, not X; we do not run X on our servers!!) utility to determine what is happening so that one can set WonderShaper's UPLINK and DOWNLINK and see immediately the effects? In other words, "how can I impress my friends if I can't even show them that this works?" -- if it really does. Third and last, where is 'man tc'? (Aside: It looks like this is not wrapping correctly even though I'm set up to wrap at 72. If so, I'll find a way to fix it. Meanwhile, please accept my apology.) gypsy From simon@paxonet.com Sun Sep 29 19:24:03 2002 From: simon@paxonet.com (Simon Matthews) Date: Sun, 29 Sep 2002 11:24:03 -0700 (PDT) Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways Message-ID: I have a dual-homed firewall. It has 2 Internet connections, provided by different ISPs (each with an associated IP address). The 2 Internet connections are connected to the same physical interface. The 2 Internet connections do NOT have equal bandwidth How do I configure the SNAT/MASQ and ensure sharing of the gateways with the correct ratio of usage and with the correct source IP address? I know how to use the 'ip' commands to configure gateway sharing according to my defined ratios and ensure that packets go out of the correct gateway according to their source address. However, I need to configure SNAT-ed or MASQ-ed in such a way that it shares the gateways according to my defined ration and so that it sets the source address correctly for the gateway. How do I do this? Can someone please point me in the correct direction for the SNAT/MASQ setup with iptables/iproute2? Thanks! Simon From ramin@cannon.eng.us.uu.net Sun Sep 29 19:50:30 2002 From: ramin@cannon.eng.us.uu.net (Ramin Alidousti) Date: Sun, 29 Sep 2002 14:50:30 -0400 Subject: [LARTC] Rip problems In-Reply-To: <200209290118.07853.jtwatson@datakota.com> References: <200209281347.03095.jtwatson@datakota.com> <200209281546.38623.jtwatson@datakota.com> <20020929034357.GA21653@cannon.eng.us.uu.net> <200209290118.07853.jtwatson@datakota.com> Message-ID: <20020929185030.GA29637@cannon.eng.us.uu.net> > I will try to be as complete as possible :) > > I have a /24, ie xx.xx.xx.0 - xx.xx.xx.255 > This is split into 4 subnets ie /26 > The xx.xx.xx.0/26 subnet is used on the network that the portmaster > is plugged into. I also have a second Portmaster on this network, and > xx.xx.xx.63/26 is asigned to the modem pool split between the portmasters. > The routing is taken care of by rip on the two portmasters. *) Are we talking RIPv1 or v2? > Now on the same xx.xx.xx.0/26 network, I have a linux box. Behind this > Linux Box is where I have the xx.xx.xx.128/26 network. > > xx.xx.xx.192/26 is not being used now. > > ,---modems in the xx.xx.xx.64/26 ---, > ,-----'------. ,-----'-------. > - ---T1--CSU/DSU--| portmaster |---xx.xx.xx.0/26-------| portmaster2 | > `------------` | `-------------` > ,--------------. > | Linux Box | > `--------------` > | > xx.xx.xx.128/26 > > Now, I am monitoring the routing tables in the portmaster connected to the > T1. Since it is the gateway this is what matters for incoming traffic. When > I start routed on the linuxbox, after 30 seconds it broadcasts its info, and > the portmaster updated its routes with a xx.xx.xx.128/26: I can then access *) So you actually see xx.xx.xx.128/26 with the next hop the linux box's interface on xx.xx.xx.0/26? This means that you're not running RIPv1. > clients on the xx.xx.xx.128/26 network behind the linux box. But after > 3min's, routed start brodcasting the route to the 128/26 network with a > metric of 16. This is the mechanism to announce the unreachability of the route. *) Are you running RIP among the two portmasters and the linux box? > And as expected, I can't access the 128/26 network anymore. > Then it started broadcasting a route to the xx.xx.xx.0/24 network???? Where > does it get this from?? What I can't figure out is why routed changes what > it is broadcasting?? Somehow, the linux box receives the route for the whole /24. At this point it poisons the previous /26 and starts announcing the /24. > > So it is something to do with routed on the linux box! I monitored all rip > traffic with tcpdump (a previous post has this info) and nothing else is > telling it to change the routing. Your previous posting only showed the RIP packets from the linux box. Can you capture all the RIP packets? > The only other rip divices on the network are the portmasters, and they are > taking care of the xx.xx.xx.64/26 network that the modems are on. Exactly. I didn't see any routing information exchange between the linux box and the second portmaster, though. > > Gated talks about routes from the local interface config timing out, and I don't understand what you mean here. > there is config options to prevent this. Maybe this is what I am seeing > with routed?? > > I have added a static route to the portmaster until I can figure this out. Yes. For your setup static route is good enough and possibly the easiest. But just as an exercise, I'd like to know what the problem is. Ramin > > Thanks for the help > - -- > Regards > > Joseph Watson > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9lozxABydhMNsDgMRAmJ7AKC2cS/bNkAbaJIQBojSTpnU1yRqsgCffk+D > yCXIDHSYEUNPVm1qrkek4mg= > =mzJ/ > -----END PGP SIGNATURE----- From robert.penz@outertech.com Sun Sep 29 20:36:31 2002 From: robert.penz@outertech.com (Robert Penz) Date: Sun, 29 Sep 2002 21:36:31 +0200 Subject: [LARTC] vtun - mtu problem Message-ID: <200209292136.34954.robert.penz@outertech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I want to to that local network ---eth0--- tunnel entry point ---- tunnel exit point. (windows and linux pcs)=20 I'm using vtun and I'm masquerating on both tunnel machines, my problem i= s now=20 that a ping works also small packets but if the packet gets bigger I get = that=20 with tcpdump on my tunnel exit point. tcpdump -n -i eth0 host heise.de 21:03:32.595835 194.242.45.xxx > 193.99.144.71: icmp: 10.3.0.2 unreachabl= e -=20 need to frag (mtu 1450) [tos 0xc0] 21:03:38.794269 193.99.144.71.80 > 194.242.45.xxx.32819: R=20 1387534372:1387534372(0) ack 3349554176 win 0 here the setup of my tunnel entry point: eth0 Link encap:Ethernet HWaddr 00:00:CB:59:EE:85 inet addr:10.149.xx.xx Bcast:10.149.xx.255 Mask:255.255.240.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 tun0 Link encap:Point-to-Point Protocol inet addr:10.3.0.2 P-t-P:10.3.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1450 Metric:1 I did a little searching on the internet, and the only stuff I found was = from=20 2000, where something simlular happend, and the answer was to set the cli= ents=20 to mtu 1450, is that the still the only way. (didn't try it sofar)=20 but what I don't understand, that the mtu is always 1450 .... so why is t= hat=20 only a problem with my setup? - --=20 Regards, Robert - ---------------- Robert Penz robert.penz AT outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9l1ZC8tTsQqJDUBMRAiLMAJ4mhO4FGkjXbYioRDyerl1nHboLcgCeNi+W YLVA3MaoyN/bELX7g1OPw6k=3D =3DUPRC -----END PGP SIGNATURE----- From stef.coene@docum.org Sun Sep 29 21:21:38 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 29 Sep 2002 22:21:38 +0200 Subject: [LARTC] Tune and tweak WonderShaper - How?? In-Reply-To: <3D9740D7.699C4B11@iswest.com> References: <3D9740D7.699C4B11@iswest.com> Message-ID: <200209292221.38934.stef.coene@docum.org> On Sunday 29 September 2002 20:05, gypsy wrote: > First, it is impossible for there to be LENDED without BORROWED. (And > proper English would be LOANED not LENDED.) > > Second, where is a (console, not X; we do not run X on our servers!!) > utility to determine what is happening so that one can set > WonderShaper's UPLINK and DOWNLINK and see immediately the effects? In > other words, "how can I impress my friends if I can't even show them > that this works?" -- if it really does. There is no such script. I have a script that reads the iptables counter= s to=20 calculate the bandwidth each second if you are intersted. And yes, it ru= ns=20 in a console. You can monitor what ever you can match with iptables. > Third and last, where is 'man tc'? www.lartc.org > (Aside: It looks like this is not wrapping correctly even though I'm > set up to wrap at 72. If so, I'll find a way to fix it. Meanwhile, > please accept my apology.) It's fine for me. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From stef.coene@docum.org Sun Sep 29 21:33:44 2002 From: stef.coene@docum.org (Stef Coene) Date: Sun, 29 Sep 2002 22:33:44 +0200 Subject: [LARTC] htb2 with link sharing - the bandwidth dividing question In-Reply-To: <200209231129.26673.Adi@iNterNUX.co.id> References: <00b601c2322b$00c331d0$6403a8c0@unzeitig> <20020723184901.029AEDB9AC@tartarus.telenet-ops.be> <200209231129.26673.Adi@iNterNUX.co.id> Message-ID: <200209292233.44461.stef.coene@docum.org> On Monday 23 September 2002 05:29, Adi Nugroho wrote: > On Wednesday 24 July 2002 02:49, Stef Coene wrote: > > Actually, the remaining bandwidth is not divided proportional to the > > rate, but to quantum. > > Helo.... > I would like to ask about r2q and quantum. > I'm using sfq, which has also something named quantum. > the question is.... > I I want that the remaining bandwidth to be devided proportional to the > rate, which one shuld I set... > * sfq quantum? > * or htb quantum? > * or both? Htb quantum is used to between different classes and only for bandwidth t= hat=20 remains after each class get's it's rate. Sfq quantum is used within one class where the sfq qdisc is attached to a= nd=20 determines how many bytes each flow can send when they may send. Setting on quantum is the best. > Second question, how can we set r2q lower than 1? I would like to set m= y > r2q to 0.1. Just try it out. I don't know if it will work. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From lartc@24x7linux.com Sun Sep 29 23:45:33 2002 From: lartc@24x7linux.com (=?iso-8859-1?Q?Jos=E9_Luis_Domingo_L=F3pez?=) Date: Mon, 30 Sep 2002 00:45:33 +0200 Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways In-Reply-To: References: Message-ID: <20020929224533.GB18178@localhost> On Sunday, 29 September 2002, at 11:24:03 -0700, Simon Matthews wrote: > I have a dual-homed firewall. It has 2 Internet connections, provided by > different ISPs (each with an associated IP address). The 2 Internet > connections are connected to the same physical interface. The 2 Internet > connections do NOT have equal bandwidth > > How do I configure the SNAT/MASQ and ensure sharing of the gateways with > the correct ratio of usage and with the correct source IP address? > ip route add default nexthop via $CONN1_IP dev $ETHX weight $X \ nexthop via $CONN2_IP dev $ETHX weight $Y weight(s) are the relative bandwidths of the connections. If the first is a 2 Mbps line and the second a 512 Kbps one, $=4 and $Y=1, for example. What matters is the ratio, not the actual bandwidth. > I know how to use the 'ip' commands to configure gateway sharing according > to my defined ratios and ensure that packets go out of the correct gateway > according to their source address. > The above defines routing. And SNAT/MASQ is something done afterwards, so you could SNAT/MASQ traffic going to each connection differently. What I don't know right now is how to determine to which Internet connection are packets going in your setup with only an ethernet card for both. With a card for each Internet connection it is simple. Hope this helps. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From jtwatson@datakota.com Mon Sep 30 05:39:15 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Mon, 30 Sep 2002 00:39:15 -0400 Subject: [LARTC] Rip problems In-Reply-To: <20020929185030.GA29637@cannon.eng.us.uu.net> References: <200209281347.03095.jtwatson@datakota.com> <200209290118.07853.jtwatson@datakota.com> <20020929185030.GA29637@cannon.eng.us.uu.net> Message-ID: <200209300039.17904.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 29 September 2002 02:50 pm, Ramin Alidousti wrote: > > I have added a static route to the portmaster until I can figure this > > out. > > Yes. For your setup static route is good enough and possibly the easies= t. > But just as an exercise, I'd like to know what the problem is. > > Ramin Well, doesn't this just figure. I tried to recreate the problem .... and= it=20 no longer exists?? =20 I removed the static routes from the portmaster and rebooted it. I then=20 started routed on the linux box and it is 2 hours now and working perfect= ly! I have a hunch that I know what the problem was though. There was a prob= lem=20 with the pool on one portmaster, and it was spilling over into the 128/26= =20 network. I corrected the problem and reset all ports so that everyone ha= d to=20 log back on, and nobody was assigned an address from the 128/26 network, = but=20 I did not reboot it. It must have been trying to keep possesion of the=20 128/26 network for its own use??? Thanks much. - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l9VzABydhMNsDgMRAik5AJ9kfUIQCZslxZ0BqyVQvoDJ8iKruACgrQ9B mBbmniv0KBPZR2csFkxEGqo=3D =3DfNmW -----END PGP SIGNATURE----- From jtwatson@datakota.com Mon Sep 30 05:54:51 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Mon, 30 Sep 2002 00:54:51 -0400 Subject: [LARTC] Mailing list problems Message-ID: <200209300054.53041.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Every time I post to this list, I recieve non-deliverable responces such = as=20 the follow: =09nonexist mail account : dominic@192.168.16.254 =09dominic@ap.hgiga.com in Mon, 30 Sep 2002 12:46:12 +0800 =09Subject: Re: [LARTC] Rip problems =09user can't receive this mail now due to non exist mail account I did not send it to this account, I posted to the list. It seems that there is a bad subscriber on the list, but why do I get the= se=20 notices. I was just wondering if this is normal for this list setup, or if it is=20 something that could be fixed. - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l9kbABydhMNsDgMRAq+PAKDoj5wtStO4m0dMpXdg2DMyPMma6ACgrGnQ iyBmwt046LLr+yW93LUiiX4=3D =3D8f5a -----END PGP SIGNATURE----- From jtwatson@datakota.com Mon Sep 30 06:07:05 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Mon, 30 Sep 2002 01:07:05 -0400 Subject: [LARTC] Simple question Message-ID: <200209300107.09759.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have a linuxbox running shorewall, and on the lan side nic I have multi= ple=20 networks, and ip's from both assigned to the nic. One network is private= ,=20 and the other is public ip's. I have a web server running on the firewal= l=20 with multiple virtual hosts configured. I have the private ip on the lan= =20 tied to the default apache config, and the public ip on the lan tied to a= =20 vurtual configuration. Also the public ip on the wan is tied to another=20 virtual host. I want all web traffic on the private network that is trying to go throug= h the=20 firewall to get forwarded to the firewall and be answered by the apache=20 default config. All this config will do is redirects the request to my=20 domain. So no matter where they try to go, they will end up at my page. = The=20 following will do the trick. ACCEPT lan:192.168.1.0/24 fw:192.168.1.1:80 tcp http - all I think it is required to specify the 192.168.1.1 on the firewall so it i= s=20 answered by the proper apache config. Am I right? The 192.168.1.1 is th= e=20 main ip on the nic, and the public ip is a alias. Then came the question, will the following rule do the same thing? ACCEPT lan:192.168.1.0/24 lan:192.168.1.1:80 tcp http - all Would this act any different? - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l9v5ABydhMNsDgMRAqX/AJ49x9j4fK4eVuwfQJMxA15YWKdHoACgzhKv mGExxcT5A/DK6prz2L1yBog=3D =3Dz1pS -----END PGP SIGNATURE----- From jtwatson@datakota.com Mon Sep 30 06:14:38 2002 From: jtwatson@datakota.com (Joseph Watson) Date: Mon, 30 Sep 2002 01:14:38 -0400 Subject: [LARTC] Simple question In-Reply-To: <200209300107.09759.jtwatson@datakota.com> References: <200209300107.09759.jtwatson@datakota.com> Message-ID: <200209300114.39766.jtwatson@datakota.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 30 September 2002 01:07 am, Joseph Watson wrote: > Hello, > Sorry I have the wrong list here :) - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l92+ABydhMNsDgMRAp1vAJ9wUqtPWCqXGOqVN2hu+dJtX+oKFQCgkBub 7DK5G7KEIqa3EwkbZUeiIXc=3D =3DHiAH -----END PGP SIGNATURE----- From simon@paxonet.com Mon Sep 30 06:15:23 2002 From: simon@paxonet.com (Simon Matthews) Date: Sun, 29 Sep 2002 22:15:23 -0700 (PDT) Subject: [LARTC] Mailing list problems In-Reply-To: <200209300054.53041.jtwatson@datakota.com> Message-ID: On Mon, 30 Sep 2002, Joseph Watson wrote: > Hello, > > Every time I post to this list, I recieve non-deliverable responces such as > the follow: > > nonexist mail account : dominic@192.168.16.254 > dominic@ap.hgiga.com in Mon, 30 Sep 2002 12:46:12 +0800 > Subject: Re: [LARTC] Rip problems He's also on the netfilter list. From don-lartc@isis.cs3-inc.com Mon Sep 30 06:18:30 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Sun, 29 Sep 2002 22:18:30 -0700 Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways In-Reply-To: <20020930042919.14457.91574.Mailman@outpost> References: <20020930042919.14457.91574.Mailman@outpost> Message-ID: <15767.56998.786090.377704@isis.cs3-inc.com> > > I have a dual-homed firewall. It has 2 Internet connections, provided by > > different ISPs (each with an associated IP address). The 2 Internet > > connections are connected to the same physical interface. The 2 Internet > > connections do NOT have equal bandwidth > > How do I configure the SNAT/MASQ and ensure sharing of the gateways with > > the correct ratio of usage and with the correct source IP address? > > > ip route add default nexthop via $CONN1_IP dev $ETHX weight $X \ > nexthop via $CONN2_IP dev $ETHX weight $Y Note that this only shapes outgoing traffic and also relies on your ISPs to NOT do the ingress filtering that they're really supposed to do. If most of the traffic at your site is going out this might be reasonable. For most people, most of the traffic is coming in, e.g., behind your firewall are clients who want to download data. The bandwidth going out is mostly acks, which is very small compared to that coming in. Which interface traffic comes in on depends on which IP address it's sent to, which depends on which address the original request came from. That's related to the nat decision but there's no way to make the "right" decision. You can divide the original requests in some given proportion, but you don't know when you do that how much traffic each one will generate. So, for instance, the clients behind your firewall make 10 http requests. You nat 8 to the fast interface and 2 to the slow one. But then it turns out that the 8 you send to the fast one all result in small amounts of data while one of the two sent to the slow interface results in a large amount. You might be better off just using the fast one, or perhaps using the slow one only for stuff that you can be sure will fit comfortably in its bandwidth. From simon@paxonet.com Mon Sep 30 08:06:15 2002 From: simon@paxonet.com (Simon Matthews) Date: Mon, 30 Sep 2002 00:06:15 -0700 (PDT) Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways In-Reply-To: <15767.56998.786090.377704@isis.cs3-inc.com> Message-ID: On Sun, 29 Sep 2002, Don Cohen wrote: > > > I have a dual-homed firewall. It has 2 Internet connections, provided by > > > > > ip route add default nexthop via $CONN1_IP dev $ETHX weight $X \ > > nexthop via $CONN2_IP dev $ETHX weight $Y > > Note that this only shapes outgoing traffic and also relies on your > ISPs to NOT do the ingress filtering that they're really supposed to do. > > If most of the traffic at your site is going out this might be > reasonable. For most people, most of the traffic is coming in, e.g., > behind your firewall are clients who want to download data. The > bandwidth going out is mostly acks, which is very small compared to > that coming in. > > off just using the fast one, or perhaps using the slow one only for > stuff that you can be sure will fit comfortably in its bandwidth. OK, this may be a reasonable approach, but how do I force it initiate connections from the "fast" interface, yet allow it to fail over to the slow interface if the sytem removes the route to the fast gateway because it has detected that it is not responding? Simon From Allang@equation.co.za Mon Sep 30 08:42:07 2002 From: Allang@equation.co.za (Allan Gee) Date: Mon, 30 Sep 2002 09:42:07 +0200 Subject: [LARTC] RE:u32 filters and compression Message-ID: <000201c26854$e1a4a300$0eb2a8c0@equation.co.za> Thanks: To Stef and Tobias Geiger for giving me the answer. I used the prio to = get the order right. Don't know why I did'nt think of it myself. Compression: Another thing that might be useful to the list is the use of compression = (Deflate etc.) to get better bandwidth across links. This requires a = Linux router at both ends of the link. I got the idea from a product = called Peribit see www.peribit.com ( and mainly from Martin Devera who = pointed out to me that Linux does compression already with ppp. ) I have = now started to work on getting compression built into my traffic = shaping/router products that are Linux based. Putting that in place of = Cisco should be a much better/cheaper solution do you not think? One = could even shape the port that the pppoe runs on. I have looked at = Zebedee which also has a solution for "Windows" boxes. Anyway I've just = started to do this and If anyone is interested I will let you know the = outcome. Regards Allan Gee Equation 021 4181777 www.equation.co.za From fredthep@yahoo.fr Mon Sep 30 09:31:30 2002 From: fredthep@yahoo.fr (=?iso-8859-1?q?Fred=20Thep?=) Date: Mon, 30 Sep 2002 10:31:30 +0200 (CEST) Subject: [LARTC] (no subject) Message-ID: <20020930083130.85683.qmail@web20422.mail.yahoo.com> --0-379481560-1033374690=:85017 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I want to know how I can put two statics default routes on a linux machine: one route with a preference inferior at the other in order to switch via the other when the first gateway fall, and if it's not possible -what I think- I want know how I can implement this with gateD. --------------------------------- Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français ! --0-379481560-1033374690=:85017 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

I want to know how I can put two statics default routes on a linux machine: one route with a preference inferior at the other in order to switch via the other when the first gateway fall, and if it's not possible -what I think- I want know how I can implement this with gateD.

 

 


Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !
--0-379481560-1033374690=:85017-- From jvds@netgroup.co.za Mon Sep 30 10:07:46 2002 From: jvds@netgroup.co.za (Jaco van der Schyff) Date: Mon, 30 Sep 2002 11:07:46 +0200 Subject: [LARTC] OT: Latency issues with Satellite connections Message-ID: <3D981462.E05D1289@netgroup.co.za> Hi Everyone, Sorry for this OT post, but I wonder if there is someone out there who can answer this question for me. We are currently investigating the option of using VSAT Satellite connections for some of our sites in remote areas of Africa. VSAT has been critisized with regards to latency, and according to the supplier, its about 560ms per satellite hop. My question is the following: Would this be 560ms both ways, for each packet sent/received? Would it be 560ms for a packet to be received, then 560ms AGAIN for the corresponding ACK to be sent? If this is the case, even a fast 2Mb line would seem really slow. Or am a reasoning at the wrong end? Any ideas/input would be appreciated. - Jaco From Alexey Talikov Mon Sep 30 10:15:59 2002 From: Alexey Talikov (Alexey Talikov) Date: Mon, 30 Sep 2002 14:15:59 +0500 Subject: [LARTC] OT: Latency issues with Satellite connections In-Reply-To: <3D981462.E05D1289@netgroup.co.za> References: <3D981462.E05D1289@netgroup.co.za> Message-ID: <16719908817.20020930141559@texlab.com.uz> Hello Jaco, Monday, September 30, 2002, 2:07:46 PM, you wrote: JvdS> Would this be 560ms both ways, for each packet sent/received? JvdS> Would it be 560ms for a packet to be received, then 560ms AGAIN JvdS> for the corresponding ACK to be sent? If this is the case, JvdS> even a fast 2Mb line would seem really slow. Not so good for interactive connection such as telnet ssh and for interactive browsing. But 2mbit always 2mbit. ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- From sandos@home.se Mon Sep 30 10:23:09 2002 From: sandos@home.se (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Mon, 30 Sep 2002 11:23:09 +0200 Subject: [LARTC] OT: Latency issues with Satellite connections References: <3D981462.E05D1289@netgroup.co.za> Message-ID: <009501c26862$fe517470$0219450a@sandos> > Any ideas/input would be appreciated. Tcp transfers should work out ok of you compensate by setting large/huge windows, though interactive work will probably not be that fun. Slashdot had a story about a satellite connection, and the page regarding that says their "ping-time" was around 650ms, I guess thats round-trip then? --- John Bäckstrand From serban_rares@yahoo.com Mon Sep 30 11:52:47 2002 From: serban_rares@yahoo.com (SERBAN Rares) Date: Mon, 30 Sep 2002 03:52:47 -0700 (PDT) Subject: [LARTC] HTB or CBQ ? In-Reply-To: <200209291118.09534.stef.coene@docum.org> Message-ID: <20020930105247.99309.qmail@web13907.mail.yahoo.com> Hi Stef, Please can you detail the arguments to use CBQ and HTB? Why HTB is better than CBQ? Which are the weakness of CBQ implementation which solved by HTB? Thank you, R. --- Stef Coene wrote: > On Sunday 29 September 2002 07:40, > brt_informatics@wlink.com.np wrote: > > Hi.. > > I've tried both (HTB & CBQ) the queuing descpliens > and I think HTB is > > more efficient than CBQ. But i think HTB is still > in beta. I just want > > to know if I can go for HTB right away. I mean, is > it stable? I'm > > trying to implement it in my company and thus > stability and performance > > is big issue in this case. > > Please correct me if i'm wrong. > It's not because cbq is in the kernel for a long > time that it is stable. I > know more bugs/problems with cbq then with htb. > > I think htb is better because : > - design > - less obscure options > - actively maintained > - faster > - included in kernel 2.4.20 :) > > Just my 2˘ > > 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/ __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From folke@sohu.com Mon Sep 30 15:03:22 2002 From: folke@sohu.com (folke@sohu.com) Date: Mon, 30 Sep 2002 22:03:22 +0800 Subject: [LARTC] will anyone here help me to write a script to implement AF service class? Message-ID: <00c801c2688a$2360d7c0$1200000b@rascal> aGkgLGFsbCANCiANCiAgaSBhbSBhIG5ldyBjb21tZXIgb2YgdGhpcyBjb21tdW5pdHkuIDopDQoN CiAgaSB3YW50IHRvIHVzZSBxZGlzYyBHUkVEIHRvIGltcGxlbW5ldCB0aGUgQUYNCnNlcnZpY2Ug LiB0aGF0IGlzIHRvIGRpdmlkZSB0cmFmZmljIGludG8gQUYxIA0KQUYyIGFuZCBBRjMgYW5kIGJv dGggaGF2ZSB0d28gZHJvcCBwcmVjZWRlbmNpZXMuDQp0aHVzIGkgY3JlYXQgdGhyZWUgY2xhc3Nl cyAsZWFjaCBoYXZlIG9uZSBHUkVEIA0KcWRpc2MgLCBidXQgaSBkb247dCBrbm93IGhvdyB0byBk aXZpZGUgdGhlIA0KdHJhZmZpYyB3aXRoaW4gb25lIGNsYXNzIGludG8gdHdvIGRyb3AgcHJlY2Vk ZW5jaWVzLg0KZS5nLiBpIGNhbiBtYXAgYm90aCBBRjExIGFuZCBBRjEyIG9udG8gY2xhc3MgMjox IA0Kd2hpY2ggY29udGFpbnMgYSBHUkVEIHFkaXNjICwgYnV0IGhvdyBjYW4gaSANCnN1Yi1kaXZp ZGUgdGhlIHR3byBkcm9wIHByZWNlZGVuY3kgd2l0aGluIA0KdGhpcyBxZGlzYyA/DQoNCg0KYW55 IGhlbHAgaXMgYXBwcmVjaWF0ZWQgDQoNCkZvbGtlDQoNCg0K From stef.coene@docum.org Mon Sep 30 16:15:22 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 30 Sep 2002 17:15:22 +0200 Subject: [LARTC] HTB or CBQ ? In-Reply-To: <20020930105247.99309.qmail@web13907.mail.yahoo.com> References: <20020930105247.99309.qmail@web13907.mail.yahoo.com> Message-ID: <200209301715.22200.stef.coene@docum.org> On Monday 30 September 2002 12:52, SERBAN Rares wrote: > Hi Stef, > > Please can you detail the arguments to use CBQ and > HTB? Why HTB is better than CBQ? Which are the > weakness of CBQ implementation which solved by HTB? For the performance difference, take a look at the htb homepage. Devik d= id=20 some tests with both htb2, htb3 and cbq. Cbq has a weak theory background. It works by calculating the idle time = of=20 the link. But the only input we have to calculate this is the number of=20 packets the NIC send. So you have to know your NIC bandwidth, the averag= e=20 packet size, and some other obscure options (allot). If you have differe= nt=20 packet size or a changing NIC bandwidth (pppoe, pptp), you can get strang= e=20 results with cbq. Htb on the other hand is based on tbf. It does not need to know NIC=20 bandwidth, nor average packet size. It has a total different approach to= do=20 traffic shaping. I refer to the htb homepage for more info about the the= ory=20 background of htb. And one of the mose convincing arguments to me : htb is actively maintain= ed. =20 If there is a bug or performance problem, it will get fixed. Stef=20 --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From mbabcock@fibrespeed.net Mon Sep 30 16:26:24 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Mon, 30 Sep 2002 11:26:24 -0400 Subject: [LARTC] HTB or CBQ ? References: <20020930105247.99309.qmail@web13907.mail.yahoo.com> <200209301715.22200.stef.coene@docum.org> Message-ID: <3D986D20.5000703@fibrespeed.net> Stef Coene wrote: >And one of the mose convincing arguments to me : htb is actively maintained. >If there is a bug or performance problem, it will get fixed. > > And, being newer code that many of us have looked at, patches / fixes will probably flow to the maintainer faster than CBQ ones. BTW, how many people are using the patched SFQ (ESFQ?) these days, and how stable is it? -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock From stef.coene@docum.org Mon Sep 30 16:37:03 2002 From: stef.coene@docum.org (Stef Coene) Date: Mon, 30 Sep 2002 17:37:03 +0200 Subject: [LARTC] HTB or CBQ ? In-Reply-To: <3D986D20.5000703@fibrespeed.net> References: <20020930105247.99309.qmail@web13907.mail.yahoo.com> <200209301715.22200.stef.coene@docum.org> <3D986D20.5000703@fibrespeed.net> Message-ID: <200209301737.03927.stef.coene@docum.org> On Monday 30 September 2002 17:26, Michael T. Babcock wrote: > Stef Coene wrote: > >And one of the mose convincing arguments to me : htb is actively > > maintained. If there is a bug or performance problem, it will get fix= ed. > > And, being newer code that many of us have looked at, patches / fixes > will probably flow to the maintainer faster than CBQ ones. > > BTW, how many people are using the patched SFQ (ESFQ?) these days, and > how stable is it? I used it and it was stable. I'm going to switch over to kernel 2.5. Wi= ll=20 the efsq patch apply? Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net From don-lartc@isis.cs3-inc.com Mon Sep 30 16:55:27 2002 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Mon, 30 Sep 2002 08:55:27 -0700 Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways In-Reply-To: References: <15767.56998.786090.377704@isis.cs3-inc.com> Message-ID: <15768.29679.531429.988158@isis.cs3-inc.com> Simon Matthews writes: > OK, this may be a reasonable approach, but how do I force it initiate > connections from the "fast" interface, yet allow it to fail over to the > slow interface if the sytem removes the route to the fast gateway because > it has detected that it is not responding? Off hand I don't know anything built in for this (I look forward to hearing an answer from someone who does), but I don't think this is really what you want anyway. It's not as if your link is the only one that could fail! If ISP1's upstream link fails then you want to use ISP2 for all traffic other than that intended for ISP1 itself. And of course, problems further upstream prevent you from reaching certain addresses but not others, and you don't really know which without a global view of the routing. I think the "right" solution involves monitoring the traffic. There's a wide range of things you could do, the simplest being simply detecting that the link is not responding. You could also try to detect tcp retransmits, measure RTT, aggregate data to measure how well individual connections are working, further aggregate data to determine which addresses blocks are working well and which poorly, etc. Then use that data to decide which of your links to use for a given destination. I actually sent a proposal to this list that I think provides a good solution to the general problem: an extension to TCP (possibly even IP) that supports multiple addresses/ports. This would even allow you to switch addresses in the middle of a connection. I think what I described before applies more to the machine on the other side of your connection, which now would know both of your addresses. Whenever it does a tcp retransmit it switches the address. It therefore tends to stay on the one that works most reliably. (Perhaps this algorithm could be improved to take speed into account too.) This discussion points out that something similar should be done on your end: you should switch the output interface you use when you retransmit. Of course this is not yet implemented. It's on my queue, but not close to the beginning. I'd be glad if someone out there could beat me to it. From tobias.geiger@web.de Mon Sep 30 17:04:17 2002 From: tobias.geiger@web.de (Tobias Geiger) Date: Mon, 30 Sep 2002 18:04:17 +0200 Subject: [LARTC] RE:u32 filters and compression References: <000901c262dd$0fcd4340$0eb2a8c0@equation.co.za> Message-ID: <3D987601.6020404@web.de> Hi, thanks for the thanks :) i looked at the whitepaper on www.peribit.com and it seems that they do much more than the standard (lzw-) compression: they use kind of proxy for cachable protocols, and their MSR ("Molecular Sequence Reduction", sounds great ! :) Algorithm to find repeating patterns even across multiple packets. although i can't really believe that this doesn't effect latency the technical approach sounds amazing. The great "disadvantage" is that u need such a box at both ends (obviously) unlike compressed pppd (at least i think windows understands compressed-pppd, or?) which is more platform independent. But i admit this is like comparing apples with pears... Allan Gee wrote: > Thanks: To Stef and Tobias Geiger for giving me the answer. I used > the prio to get the order right. Don't know why I did'nt think of it > myself. Compression: Another thing that might be useful to the list > is the use of compression (Deflate etc.) to get better bandwidth > across links. This requires a Linux router at both ends of the link. > I got the idea from a product called Peribit see www.peribit.com ( > and mainly from Martin Devera who pointed out to me that Linux does > compression already with ppp. ) I have now started to work on getting > compression built into my traffic shaping/router products that are > Linux based. Putting that in place of Cisco should be a much > better/cheaper solution do you not think? One could even shape the > port that the pppoe runs on. I have looked at Zebedee which also has > a solution for "Windows" boxes. Anyway I've just started to do this > and If anyone is interested I will let you know the outcome. > > Regards Allan Gee Equation 021 4181777 www.equation.co.za ,S > f??)?+-?L)??Y???=jya???f??f?v?Z?_?j)fj??b??????ps?L?m??????r??/=== From rmocius@auste.elnet.lt Mon Sep 30 17:11:22 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Mon, 30 Sep 2002 17:11:22 +0100 Subject: [LARTC] ip route Message-ID: <025b01c2689c$068fa7e0$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_0258_01C268A4.66DDC390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, How with ip route permanently delete default route and add a new one? I use RedHat 7.3. Thank you in advance Rimas ------=_NextPart_000_0258_01C268A4.66DDC390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
How with ip route permanently = delete default=20 route and add a new one?
I use RedHat 7.3.
 
Thank you in advance
 
Rimas
------=_NextPart_000_0258_01C268A4.66DDC390-- From james+lartc@vincentsystems.com Mon Sep 30 17:42:40 2002 From: james+lartc@vincentsystems.com (James Sneeringer) Date: Mon, 30 Sep 2002 11:42:40 -0500 Subject: [LARTC] Rip problems In-Reply-To: <200209281347.03095.jtwatson@datakota.com> References: <200209281347.03095.jtwatson@datakota.com> Message-ID: <20020930164240.GA5543@valjean.si.ocslink.com> On Sat, Sep 28, 2002 at 01:46:37PM -0400, Joseph Watson wrote: | EXPORT_GATEWAY="no" | SILENT="no" This should cause the equivalent of "routed -s" to be run. The "-s" tells routed to send routing updates. Check with "ps ax". You can get further debugging out of it with "-d" and "-t". | When I start routed, the appropriate routes show up in the portmaster after | about a 30 seconds, and all works good for about 2 1/2 minutes. Then the | portmaster sets the Metric to 16 for the route to my subnet behind the | firewall, and routing quits working. PortMasters do this when they think they need to remove the route from the routing table. They set the "O" flag (for obsolete, I guess) and set the metric to 16 (because 16 is the largest metric permitted by RIPv1). The route will eventually disappear from the table unless another update is received. | If I restart routed, we will repeat the | process. If I stop routed during the 2 1/2 mins, it will immediately set the | Met to 16. This tells me that they are communicating because when I shut | routed down the metric is set to 16. But why does this happen exactly at 2 | 1/2 min?? I am quite confused? It sounds like routed isn't sending routing updates. RIPv1 sends the whole routing table every 30 seconds to the broadcast address (which is why it takes about 30 seconds for the PortMaster to see the routes). My guess is it's only sending out the initial announcement, and when the PM doesn't see subsequent announcements for a couple minutes, it drops the routes. If possible, consider using OSPF instead. RIPv1 is quite obsolete and generally useless on subnetted networks like yours. PortMasters have done OSPF since ComOS 3.5, and you can implement it on Linux with zebra or gated. For further PortMaster-specific help, consider subscribing to the portmaster-users@portmasters.com list. See http://www.portmasters.com/ for more info. -James From mbabcock@fibrespeed.net Mon Sep 30 18:05:54 2002 From: mbabcock@fibrespeed.net (Michael T. Babcock) Date: Mon, 30 Sep 2002 13:05:54 -0400 Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways References: <15767.56998.786090.377704@isis.cs3-inc.com> <15768.29679.531429.988158@isis.cs3-inc.com> Message-ID: <3D988472.6040907@fibrespeed.net> Don Cohen wrote: >I actually sent a proposal to this list that I think provides a good >solution to the general problem: an extension to TCP (possibly even >IP) that supports multiple addresses/ports. This would even allow you >to switch addresses in the middle of a connection. I think what I > > SCTP actually supports this already; look it up -- its quite a bit different from TCP but allows you to do all the same types of things, with more options. That said, a Zebra (routing software) plugin that would run iptables scripts would be all you'd need in many cases. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock From lartc@24x7linux.com Mon Sep 30 19:11:58 2002 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Mon, 30 Sep 2002 20:11:58 +0200 Subject: [LARTC] Iptables, SNAT/MASQ, Multiple gateways In-Reply-To: <15767.56998.786090.377704@isis.cs3-inc.com> References: <20020930042919.14457.91574.Mailman@outpost> <15767.56998.786090.377704@isis.cs3-inc.com> Message-ID: <20020930181158.GA4038@localhost> On Sunday, 29 September 2002, at 22:18:30 -0700, Don Cohen wrote: > > ip route add default nexthop via $CONN1_IP dev $ETHX weight $X \ > > nexthop via $CONN2_IP dev $ETHX weight $Y > > Note that this only shapes outgoing traffic and also relies on your > ISPs to NOT do the ingress filtering that they're really supposed to do. > Just a note. The above routing doesn't prevent you from applying SNAT/MASQ to the outgoing traffic, at least not when you have an ethernet card for each connection (not the case) and you can know through each one the traffic will go out. So adding another ethernet card and a couple of "iptables" rules can avoid problems with ISPs filtering "alien" incoming traffic :) -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1) From rmocius@auste.elnet.lt Mon Sep 30 19:28:36 2002 From: rmocius@auste.elnet.lt (Rimas) Date: Mon, 30 Sep 2002 19:28:36 +0100 Subject: [LARTC] Two ISP and NAT Message-ID: <007d01c268af$32a64c40$6e69690a@rimas> This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C268B7.92A0F0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, I have 2 ISP Inet connections. 1 Inet I (eth0) use have used for everything (SMTP server, MASQ for = local network) I got the 2 INET (eth1) and made some changes: They both have MASQ: iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE_2 -j = MASQUERADE (2 Inet) iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE_1 -j = MASQUERADE (1 Inet) I changed default route to eth1 and put some additional route:=20 ip route rep default via ext_ip2 dev eth1 ip route add 1.2.3.4 via ext_ip1 (eth0) And now I'm having a problem with my email server (Lotus Notes on = Linux). It can send emails via SMTP but cannot use encrypted Lotus connection = and receive emails as well. iptables -t nat -A PREROUTING -i $EXTERNAL_INTERFACE_1 -p tcp -d = $EXTERNALIP_1 --dport 25 \ -j DNAT --to-destination 1.2.3.196:25 # Lotus Notes Encrypted connection (tcp 1352) port forward from eth0 to = internal ip 10.105.105.196 =20 iptables -t nat -A PREROUTING -i $EXTERNAL_INTERFACE_1 -p tcp -d = $EXTERNALIP_1 --dport 1352 \ -j DNAT --to-destination = 1.2.3.196:1352 And how to route with ip route command that email server have to use not = the default route (eth1) but eth0. What I need to configure more to get working back my email server? Thank you in advance Rimas ------=_NextPart_000_007A_01C268B7.92A0F0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable