From limkc@actinium.org Thu Apr 1 18:47:55 2004 From: limkc@actinium.org (Lim Kee Chian) Date: Thu, 01 Apr 2004 09:47:55 -0800 Subject: [LARTC] wireless sta MAC NAT Message-ID: <406C55CB.6040009@actinium.org> Hi all, not sure this should be post here.... but i hope some one could help me. :> I'm newbie in the ebtables MAC address NAT and filtering stuff... i want to bridge a wireless client to a wired network, problem is AP would not accept frame not initiate from associated STA... so i guess i could solve it by natting mac with ebtables stuff.. question goes below.... 1. wat's the command need to do MAC NAT ? 2. can multiple wired devices utilise the wireless sta bridge after mac nat (wired port connected to a hub, switch ... etc)? i have the latest patch for bridge-nf kernel 2.4.20 + ebtables v2.0.6 hope u guys could help, thanks in advance regards, lim k.c. From ggabor@sopron.hu Thu Apr 1 07:33:21 2004 From: ggabor@sopron.hu (=?ISO-8859-2?Q?Gludov=E1tz_G=E1bor?=) Date: Thu, 01 Apr 2004 08:33:21 +0200 Subject: [LARTC] Buggy netfilter? In-Reply-To: <005b01c41772$f641bb30$030aa8c0@t> References: <406B2FC1.7080209@sopron.hu> <005b01c41772$f641bb30$030aa8c0@t> Message-ID: <406BB7B1.5000409@sopron.hu> Roy wrote: >You mail is little hard to undersatnd what you need. > >what this configuration is supposed to do? > =20 > I would like to connect to my firewall and to the machines behind it=20 (with DNAT) from the Internet. The firewall has 2 Internet providers, one with a broadband DSL (ppp0)=20 connection, one with a cabel connection (eth0). I can connect to my firewall through both connections, but DNAT operates = only on eth0. However ppp0 DNAT should work as well, because the packets go the same=20 route inside the netfilter. An iptables log event is also fired, but in=20 the end the ppp0 packets get lost, while the eth0 packets get forwarded=20 to the target machine (behind the firewall). The ppp0 packets cannot be tracked down as they entered the firewall.=20 tcpdump sees only ppp0 pockets coming in, but nothing goes back, and=20 nothing goes out on the inner interface (eth2) to the target. With eth0 everything works well. ppp0 mtu is reduced as well, so I don't have more ideas what else to try = to make this configuration work. >----- Original Message -----=20 >From: "Gludov=E1tz G=E1bor" >To: >Sent: Wednesday, March 31, 2004 11:53 PM >Subject: [LARTC] Buggy netfilter? > > >Or am I doing something really wrong. > > >2 public interfaces (eth0 and ppp0), with 2 public IP addresses. > >I can ping and connect to both interface's IP address. I can login with >ssh, anything on _both_ IP address. > >But iptables DNAT works only for eth0. > >Here are my settings: > >(ppp is initialized with 'pptp provider.ip') > >--- /etc/ppp/options --- > >nodefaultroute >noipdefault >name '"'adsluser@provider'"' >linkname '"'adsl'"' >noauth >debug >mtu 1400 >mru 1400 > >--- ip route settings --- > >Just like in the Adv-Routing-HowTo (4.2.1. Split access), except for the= >different IP addresses. > >--- iptables --- > >iptables -t nat -N ROUTING1 >iptables -t nat -N ROUTING2 > >iptables -t nat -A PREROUTING -p tcp -i eth0 -j ROUTING1 >iptables -t nat -A PREROUTING -p tcp -i ppp0 -j ROUTING1 > >iptables -t nat -A ROUTING1 -p tcp -j ROUTING2 -s $clientip1/32 >iptables -t nat -A ROUTING1 -p tcp -j ROUTING2 -s $clientip2/32 > >iptables -t nat -A ROUTING2 -p tcp -j LOG --dport 3389 --log-prefix >'"'FW: MSTSC connection attempt '"' --log-level warn >iptables -t nat -A ROUTING2 -p tcp -j DNAT --dport 3389 --to-destination= >192.168.100.23:3389 > >--- > >eth2 is the 3rd interface, with access to our 192.168.100.* private netw= ork. > > >-- The result: -- > >I can reach both interfaces (from the Internet), I can connect through >them to the firewall. > >But DNAT works only with the eth0 interface. > >Strange: iptables LOG rule is fired for ppp0 and eth0 connections, >but eth0 connections are successful, and at the same time: >ppp0 connections are just waiting without anything coming back. > >But as you can see, the packets for both go the same way in iptables. > >--- tcpdump --- > >If I go through ppp0, nothing can be seen on the inner interface (eth2).= >The packets seem to get lost somewhere, so nothing (nothing at all) goes= >back to the client, who tries to connect. > > > >Thanks in advance > --=20 G=E1bor GLUDOV=C1TZ / +36 (70) 520 31 62 http://www.gludovatz.com/ ... ... .. .. . . From przemolicc@poczta.fm Thu Apr 1 13:20:25 2004 From: przemolicc@poczta.fm (przemolicc@poczta.fm) Date: Thu, 1 Apr 2004 14:20:25 +0200 Subject: [LARTC] 4 lan's: routing + bridging Message-ID: <20040401122025.GA2965@przemek.pgf.com.pl> We have 4 lan's (A, B, C, D). Linux router (2.4, iptables, iproute2) routes traffic between the lans. There is a WAN router in one of the lan's as well so that users are able to reach WANs' hosts. All lan's are in one building: B | --------------- | | A --| router | -- C | | --------------- | D But there are plans to move some computers to another building. We don't want to create another lan(s) but keep moved boxes in the same lan as they were before the movement. Computers which are going to be moved are from _all_ lans. How to "expand" all these lan's across two buildings ? Can you suggest me some solution ? przemol From andybr@bol.com.br Thu Apr 1 16:00:55 2004 From: andybr@bol.com.br (andybr) Date: Thu, 1 Apr 2004 12:00:55 -0300 Subject: [LARTC] Control Bandwidth Message-ID: Hi all, I need a little help, i am studing htb to control user bandw= idth (download/upload) and I made a script as below to test. I am testi= ng using ttcp tool from by linux box to other linux (192.168.200.51).=0D = my box <---- Linux =3D more than 128kbit mybot -----> Linux =3D get 128k= bit But I want to control both ways, what am I missing? script:=0D = EXTIF=3Deth0 INTIF=3Deth1 TC=3D/sbin/tc DOWN=3D128 UP=3D64 IP=3D192.= 168.200.201 ################## # $TC qdisc del $EXTIF root 2> /dev/nul= l > /dev/null # $TC qdisc add dev $EXTIF root handle 0: htb default 1=0D = $TC class add dev $EXTIF parent 0: classid 1 htb rate 128Kbit ceil 128K= bit # $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 u32 mat= ch ip src $IP flowid 1 $TC filter add dev $EXTIF protocol ip parent 0:0 = prio 1 u32 match ip dst $IP flowid 1 Thanks, Anderson =0A =0A_____= _____________________________________________________________________=0AA= cabe com aquelas janelinhas que pulam na sua tela.=0AAntiPop-up UOL - =C9= gr=E1tis!=0Ahttp://antipopup.uol.com.br/=0A From jiri.fojtasek@hlohovec.net Thu Apr 1 17:45:45 2004 From: jiri.fojtasek@hlohovec.net (Jiri Fojtasek) Date: Thu, 01 Apr 2004 18:45:45 +0200 Subject: [LARTC] wireless sta MAC NAT In-Reply-To: <406C55CB.6040009@actinium.org> References: <406C55CB.6040009@actinium.org> Message-ID: <406C4739.4010108@hlohovec.net> Hello I using for this stuff application "parprouted": http://freshmeat.net/projects/parprouted/?topic_id=150 Lim Kee Chian wrote: > Hi all, > > not sure this should be post here.... but i hope some one could help > me. :> > > I'm newbie in the ebtables MAC address NAT and filtering stuff... > i want to bridge a wireless client to a wired network, problem is AP > would not accept frame not initiate from associated STA... so i guess > i could solve it by natting mac with ebtables stuff.. > > question goes below.... > 1. wat's the command need to do MAC NAT ? > 2. can multiple wired devices utilise the wireless sta bridge after > mac nat (wired port connected to a hub, switch ... etc)? > > i have the latest patch for bridge-nf kernel 2.4.20 + ebtables v2.0.6 > > hope u guys could help, thanks in advance > > regards, > lim k.c. > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > Zkontrolovane antivirusom ClamAv > Scanned by ClamAv - http://www.clamav.net > Zkontrolovane antivirusom ClamAv Scanned by ClamAv - http://www.clamav.net From satal_@hotmail.com Thu Apr 1 19:54:21 2004 From: satal_@hotmail.com (Mauricio Lataban) Date: Thu, 01 Apr 2004 18:54:21 +0000 Subject: [LARTC] How to match string p2p traffic Message-ID: I do not how to use match string to deny kazaa traffic, if I put the word kazaa only http content is deny but the kazaa aplication is running, are there special commands to match string? thanks _________________________________________________________________ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.microsoft.com/es From devik@cdi.cz Thu Apr 1 20:22:05 2004 From: devik@cdi.cz (devik@cdi.cz) Date: Thu, 01 Apr 2004 20:22:05 +0100 Subject: [LARTC] Re: Incoming Fax Message-ID: From horst.graffy@wiesbaden.netsurf.de Thu Apr 1 20:15:41 2004 From: horst.graffy@wiesbaden.netsurf.de (Horst Graffy) Date: Thu, 1 Apr 2004 21:15:41 +0200 Subject: [LARTC] How to match string p2p traffic In-Reply-To: References: Message-ID: <200404012115.42611.horst.graffy@wiesbaden.netsurf.de> Am Donnerstag, 1. April 2004 20:54 schrieb Mauricio Lataban: > I do not how to use match string to deny kazaa traffic, if I put the word > kazaa only http content is deny but the kazaa aplication is running, are > there special commands to match string? use ipp2p from http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html works like a charm ;)) Toni From rubens@etica.net Thu Apr 1 20:07:04 2004 From: rubens@etica.net (rubens@etica.net) Date: Thu, 1 Apr 2004 16:07:04 -0300 (BRT) Subject: [LARTC] How to match string p2p traffic In-Reply-To: Message-ID: > I do not how to use match string to deny kazaa traffic, if I put the word > kazaa only http content is deny but the kazaa aplication is running, are > there special commands to match string? Try something like this: iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark iptables -A PREROUTING -t mangle -m mark ! --mark 0 -j ACCEPT iptables -A PREROUTING -t mangle -m string --string "X-Kazaa" -j MARK --set-mark 1 iptables -A PREROUTING -t mangle -j CONNMARK --save-mark (Requires mark, connmark and string netfilter modules) tc qdisc add dev eth0 root handle 1: htb default 11 tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbps ceil 10Mbps burst 2k tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1Mbps ceil 1Mbps burst 2k tc class add dev eth0 parent 1:1 classid 1:11 htb rate 9Mbps ceil 10Mbps burst 2k tc filter add dev eth0 parent 1: protocol ip prio 3 handle 1 fw classid 1:10 Rubens From x-arnie@ccpbr.org Thu Apr 1 20:30:59 2004 From: x-arnie@ccpbr.org (Alessandro O. Ungaro) Date: Thu, 01 Apr 2004 16:30:59 -0300 Subject: [LARTC] How to match string p2p traffic In-Reply-To: References: Message-ID: <406C6DF3.5000609@ccpbr.org> Mauricio, you can try the 'ftwall' with iptables to do this. It's have a lot of strategics to do this :) []'s x-arnie Mauricio Lataban wrote: > I do not how to use match string to deny kazaa traffic, if I put the > word kazaa only http content is deny but the kazaa aplication is > running, are there special commands to match string? > > thanks > > _________________________________________________________________ > Charla con tus amigos en línea mediante MSN Messenger: > http://messenger.microsoft.com/es > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From x-arnie@ccpbr.org Thu Apr 1 20:21:29 2004 From: x-arnie@ccpbr.org (Alessandro O. Ungaro) Date: Thu, 01 Apr 2004 16:21:29 -0300 Subject: [LARTC] Control Bandwidth In-Reply-To: References: Message-ID: <406C6BB9.9060008@ccpbr.org> Anderson, the problem is: the flow control in your script is only to EXTIF (External Interface), so.., I think you have a network behind a NAT. The EXTIF doesn't recieve the internal IP becouse the NAT translate this. I think this is your error. Try to keep a down-rule in the INTIF to make a 128k restricted link to your "box". []'s x-arnie andybr wrote: > Hi all, > > I need a little help, i am studing htb to control user > bandwidth (download/upload) and I made a script as > below to test. I am testing using ttcp tool from by > linux box to other linux (192.168.200.51). > > my box <---- Linux = more than 128kbit > mybot -----> Linux = get 128kbit > > But I want to control both ways, what am I missing? > > > script: > > EXTIF=eth0 > INTIF=eth1 > TC=/sbin/tc > DOWN=128 > UP=64 > IP=192.168.200.201 > ################## > # > $TC qdisc del $EXTIF root 2> /dev/null > /dev/null > # > $TC qdisc add dev $EXTIF root handle 0: htb default 1 > > $TC class add dev $EXTIF parent 0: classid 1 htb rate > 128Kbit ceil 128Kbit > # > $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 > u32 match ip src $IP flowid 1 > $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 > u32 match ip dst $IP flowid 1 > > Thanks, > Anderson > > > __________________________________________________________________________ > Acabe com aquelas janelinhas que pulam na sua tela. > AntiPop-up UOL - É grátis! > http://antipopup.uol.com.br/ > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From devik@cdi.cz Thu Apr 1 20:22:05 2004 From: devik@cdi.cz (devik@cdi.cz) Date: Thu, 01 Apr 2004 20:22:05 +0100 Subject: [LARTC] Re: Incoming Fax Message-ID: This is a multi-part message in MIME format. ------------=_406C6C6C.46061A86 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit Spam detection software, running on the system "mailcluster2", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ [...] Content analysis details: (16.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.3 NO_REAL_NAME From: does not include a real name 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object 10 VIRUS_WARNING_BAGLE3 BODY: Looks like Bagle.Q/R virus/bounce 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ------------=_406C6C6C.46061A86 Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Content-Transfer-Encoding: 8bit Return-Path: Envelope-To: X-Spam-Status: SpamAssassin Failed Received: from outpost.ds9a.nl ([213.244.168.210] verified) by univits.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 2547280 for marco.wesselgren@univits.com; Thu, 01 Apr 2004 21:24:27 +0200 Received: from outpost.ds9a.nl (outpost [127.0.0.1]) by outpost.ds9a.nl (Postfix) with ESMTP id 2992C44DE; Thu, 1 Apr 2004 21:23:28 +0200 (CEST) Delivered-To: lartc@outpost.ds9a.nl Received: from kevin-laptop.net (unknown [127.0.0.2]) by outpost.ds9a.nl (Postfix) with SMTP id E19AE44DE for ; Thu, 1 Apr 2004 21:22:10 +0200 (CEST) Received: from ([193.77.178.75]) by SpamProxy To: LARTC@mailman.ds9a.nl From: devik@cdi.cz Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [LARTC] Re: Incoming Fax Sender: lartc-admin@mailman.ds9a.nl Errors-To: lartc-admin@mailman.ds9a.nl X-BeenThere: lartc@mailman.ds9a.nl X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Linux Advanced Routing & Traffic Control list List-Unsubscribe: , List-Archive: Date: Thu, 01 Apr 2004 20:22:05 +0100 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ------------=_406C6C6C.46061A86-- From rubens@etica.net Thu Apr 1 21:42:13 2004 From: rubens@etica.net (rubens@etica.net) Date: Thu, 1 Apr 2004 17:42:13 -0300 (BRT) Subject: [LARTC] ESFQ updates Message-ID: Hi. On Mar 12, Corey Hickey posted here(http://mailman.ds9a.nl/pipermail/lartc/2004q1/012038.html) an updated esfq patch for kernel 2.6. Has anyone backported it to kernel 2.4 ? Original esfq patch is not being kept in sync with kernel sfq, it seems. What people have been using with esfq and kernel 2.4.25, the original 2002 esfq patch ? Rubens From roy@xxx.lt Thu Apr 1 21:47:27 2004 From: roy@xxx.lt (Roy) Date: Thu, 1 Apr 2004 23:47:27 +0300 Subject: [LARTC] Control Bandwidth References: Message-ID: <003e01c4182a$8bba4530$030aa8c0@t> This script will not work for upload unles used on my imq interface. or umless used on separate computer which works as bridge. or if you DO NOT use nat. only download shaping will work in other case. or you must mark upload packets in prerouting chain. because else tc will see only your server's ip ----- Original Message ----- From: "andybr" To: "Lartc List" Sent: Thursday, April 01, 2004 6:00 PM Subject: [LARTC] Control Bandwidth Hi all, I need a little help, i am studing htb to control user bandwidth (download/upload) and I made a script as below to test. I am testing using ttcp tool from by linux box to other linux (192.168.200.51). my box <---- Linux =ore than 128kbit mybot -----> Linux =et 128kbit But I want to control both ways, what am I missing? script: EXTIF=h0 INTIF=h1 TC=bin/tc DOWN8 UPd IP2.168.200.201 ################## # $TC qdisc del $EXTIF root 2> /dev/null > /dev/null # $TC qdisc add dev $EXTIF root handle 0: htb default 1 $TC class add dev $EXTIF parent 0: classid 1 htb rate 128Kbit ceil 128Kbit # $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 u32 match ip src $IP flowid 1 $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 u32 match ip dst $IP flowid 1 Thanks, Anderson __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From jiri.fojtasek@hlohovec.net Thu Apr 1 21:45:41 2004 From: jiri.fojtasek@hlohovec.net (Jiri Fojtasek) Date: Thu, 01 Apr 2004 22:45:41 +0200 Subject: [LARTC] ESFQ updates In-Reply-To: References: Message-ID: <406C7F75.40404@hlohovec.net> Hi I using original version. I have merget only this patch: http://linux.bkbits.net:8080/linux-2.4/cset@1.1302.6.2?nav=index.html|ChangeSet@-6M Jiri rubens@etica.net wrote: >Hi. > >On Mar 12, Corey Hickey posted >here(http://mailman.ds9a.nl/pipermail/lartc/2004q1/012038.html) >an updated esfq patch for kernel 2.6. >Has anyone backported it to kernel 2.4 ? Original esfq patch is not being >kept in sync with kernel sfq, it seems. > >What people have been using with esfq and kernel 2.4.25, the original 2002 >esfq patch ? > >Rubens > > > > > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >Zkontrolovane antivirusom ClamAv >Scanned by ClamAv - http://www.clamav.net > > > Zkontrolovane antivirusom ClamAv Scanned by ClamAv - http://www.clamav.net From rwalker@miracomnetwork.com Thu Apr 1 21:53:14 2004 From: rwalker@miracomnetwork.com (Roy Walker) Date: Thu, 1 Apr 2004 14:53:14 -0600 Subject: [LARTC] Remove Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4182B.5A2C6394 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ------_=_NextPart_001_01C4182B.5A2C6394 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

=00 ------_=_NextPart_001_01C4182B.5A2C6394-- From gfreeman@westoncs.com Thu Apr 1 22:05:26 2004 From: gfreeman@westoncs.com (Greg Freeman) Date: Thu, 1 Apr 2004 12:05:26 -0900 Subject: [LARTC] Remove Message-ID: <47DAB608EB6E2140B6EEE4DFC905D1CA01CE8D@srv1.corp.westoncs.net> This is a multi-part message in MIME format. ------_=_NextPart_001_01C4182D.0E001978 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ------_=_NextPart_001_01C4182D.0E001978 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
=00 ------_=_NextPart_001_01C4182D.0E001978-- From roy@xxx.lt Thu Apr 1 22:09:48 2004 From: roy@xxx.lt (Roy) Date: Fri, 2 Apr 2004 00:09:48 +0300 Subject: [LARTC] Buggy netfilter? References: <406B2FC1.7080209@sopron.hu> <005b01c41772$f641bb30$030aa8c0@t> <406BB7B1.5000409@sopron.hu> Message-ID: <005b01c4182d$aabcc770$030aa8c0@t> Netfilter is working ok in this case, but this place of your setup >--- ip route settings --- > >Just like in the Adv-Routing-HowTo (4.2.1. Split access), except for the >different IP addresses. may not work as you want (i dont have idea what is there) anyway I am not iproute2 specialist, and prefer to use netfilter for this purpose probably eth0 is yor default gateway. but as I see your problem is that you want to map 2 external addreses into one internal. but you are doing do this in one direction only, reverse is default gateway, because routing takes place "inside" nat so routing code should always see internal network address. you should either mark packets and route them with iptables ROUTE in the postrouting chain (I am not completely sure in what I said , but i think it is more or less correct) or you have much more simple way to assign second address to your server. and nat 2 interfaces into 2 diferent addreses. server software will take care of everything then. but you will need to dnat these 2 adderses back into real ones again ----- Original Message ----- From: "Gludovátz Gábor" To: "Roy" ; Sent: Thursday, April 01, 2004 9:33 AM Subject: Re: [LARTC] Buggy netfilter? Roy wrote: >You mail is little hard to undersatnd what you need. > >what this configuration is supposed to do? > > I would like to connect to my firewall and to the machines behind it (with DNAT) from the Internet. The firewall has 2 Internet providers, one with a broadband DSL (ppp0) connection, one with a cabel connection (eth0). I can connect to my firewall through both connections, but DNAT operates only on eth0. However ppp0 DNAT should work as well, because the packets go the same route inside the netfilter. An iptables log event is also fired, but in the end the ppp0 packets get lost, while the eth0 packets get forwarded to the target machine (behind the firewall). The ppp0 packets cannot be tracked down as they entered the firewall. tcpdump sees only ppp0 pockets coming in, but nothing goes back, and nothing goes out on the inner interface (eth2) to the target. With eth0 everything works well. ppp0 mtu is reduced as well, so I don't have more ideas what else to try to make this configuration work. >----- Original Message ----- >From: '"'Gludovátz Gábor'"' >To: >Sent: Wednesday, March 31, 2004 11:53 PM >Subject: [LARTC] Buggy netfilter? > > >Or am I doing something really wrong. > > >2 public interfaces (eth0 and ppp0), with 2 public IP addresses. > >I can ping and connect to both interface's IP address. I can login with >ssh, anything on _both_ IP address. > >But iptables DNAT works only for eth0. > >Here are my settings: > >(ppp is initialized with 'pptp provider.ip') > >--- /etc/ppp/options --- > >nodefaultroute >noipdefault >name ''"''adsluser@provider''"'' >linkname ''"''adsl''"'' >noauth >debug >mtu 1400 >mru 1400 > >--- ip route settings --- > >Just like in the Adv-Routing-HowTo (4.2.1. Split access), except for the >different IP addresses. > >--- iptables --- > >iptables -t nat -N ROUTING1 >iptables -t nat -N ROUTING2 > >iptables -t nat -A PREROUTING -p tcp -i eth0 -j ROUTING1 >iptables -t nat -A PREROUTING -p tcp -i ppp0 -j ROUTING1 > >iptables -t nat -A ROUTING1 -p tcp -j ROUTING2 -s $clientip1/32 >iptables -t nat -A ROUTING1 -p tcp -j ROUTING2 -s $clientip2/32 > >iptables -t nat -A ROUTING2 -p tcp -j LOG --dport 3389 --log-prefix >''"''FW: MSTSC connection attempt ''"'' --log-level warn >iptables -t nat -A ROUTING2 -p tcp -j DNAT --dport 3389 --to-destination >192.168.100.23:3389 > >--- > >eth2 is the 3rd interface, with access to our 192.168.100.* private network. > > >-- The result: -- > >I can reach both interfaces (from the Internet), I can connect through >them to the firewall. > >But DNAT works only with the eth0 interface. > >Strange: iptables LOG rule is fired for ppp0 and eth0 connections, >but eth0 connections are successful, and at the same time: >ppp0 connections are just waiting without anything coming back. > >But as you can see, the packets for both go the same way in iptables. > >--- tcpdump --- > >If I go through ppp0, nothing can be seen on the inner interface (eth2). >The packets seem to get lost somewhere, so nothing (nothing at all) goes >back to the client, who tries to connect. > > > >Thanks in advance > -- Gábor GLUDOVÁTZ / +36 (70) 520 31 62 http://www.gludovatz.com/ ... ... .. .. . . _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From shane@howsyournetwork.com Thu Apr 1 22:42:59 2004 From: shane@howsyournetwork.com (Shane Hickey) Date: Thu, 1 Apr 2004 14:42:59 -0700 Subject: [LARTC] Need help with rate-limiting NTTP traffic Message-ID: <20040401144259.1e6d30fc@daneel.volumen.net> Howdy all, I posted this message to the netfilter mailing-list and didn't get much response. I apologize if anyone here is getting this for a second time. Anyway, I recently migrated my firewall from a FreeBSD box running ipfilter, ipnat and dummynet to a Gentoo Linux box running netfilter and tc. I have to admit that I'm having problems visualizing tc in my head. So, I was wondering if I could get an assist. Basically, when I run my NNTP client, it uses as much bandwidth as it can get its grubby paws on. I have a 3M wireless connection and my ISP doesn't limit me, but I think they will if I'm constantly using all 3M. So, since my NNTP traffic is pretty much constantly ongoing, I'd like to limit it to 800kbit. This was a breeze with dummynet, but I'm not getting how to do it correctly with netfilter. Here's what I tried: $IPT -t mangle -N SHAPE-NNTP $IPT -t mangle -I PREROUTING -i $WANIFACE -j SHAPE-NNTP $IPT -t mangle -A SHAPE-NNTP -p tcp --sport 119 -j MARK --set-mark 119 My thoughts on placing it in PREROUTING is that I'd like to shape the traffic as soon as possible so that my firewall gets the benefit of dealing with the reduced load as soon as possible. But, maybe that's just foolishness? Here's the tc rules I tried. tc qdisc add dev $WANIFACE root handle 1: htb default 60 tc class add dev $WANIFACE parent 1: classid 1:1 htb rate 10Mbit tc class add dev $WANIFACE parent 1:1 classid 1:119 htb rate 800kbit tc filter add dev $WANIFACE parent 1:1 protocol ip handle 119 fw flowid 1:119 The one weird thing is that when I do a 'tc filter show dev $WANIFACE' nothing comes back. But 'tc class show dev $WANIFACE' and 'tc qdisc show dev $WANIFACE" return useful information. Here's some information that may be relevant: Linux elijah 2.4.24-hardened-r1 #1 Wed Mar 31 14:20:58 MST 2004 i686 Mobile Pentium II GenuineIntel GNU/Linux iproute-20010824-r4 iptables-1.2.9 Thanks, -- Shane Hickey : Network/System Consultant GPG KeyID: 777CBF3F Key fingerprint: 254F B2AC 9939 C715 278C DA95 4109 9F69 777C BF3F Listening to: american analog set - you own me From nirnimesh@students.iiit.net Thu Apr 1 22:51:30 2004 From: nirnimesh@students.iiit.net (Nirnimesh) Date: Fri, 02 Apr 2004 03:21:30 +0530 Subject: [LARTC] Need help with rate-limiting NTTP traffic In-Reply-To: <20040401144259.1e6d30fc@daneel.volumen.net> References: <20040401144259.1e6d30fc@daneel.volumen.net> Message-ID: <1080856290.3807.1.camel@localhost.localdomain> Since you were already using dummynet, try using NIST NET, the linux alternative for dummynet. Nirnimesh. On Fri, 2004-04-02 at 03:12, Shane Hickey wrote: > Howdy all, > I posted this message to the netfilter mailing-list and didn't get much > response. I apologize if anyone here is getting this for a > second time. > Anyway, I recently migrated my firewall from a FreeBSD box running > ipfilter, ipnat and dummynet to a Gentoo Linux box running netfilter and > tc. I have to admit that I'm having problems visualizing tc in my head. > So, I was wondering if I could get an assist. > Basically, when I run my NNTP client, it uses as much bandwidth as it > can get its grubby paws on. I have a 3M wireless connection and my ISP > doesn't limit me, but I think they will if I'm constantly using all 3M. > So, since my NNTP traffic is pretty much constantly ongoing, I'd like > to limit it to 800kbit. This was a breeze with dummynet, but I'm not > getting how to do it correctly with netfilter. > > Here's what I tried: > > $IPT -t mangle -N SHAPE-NNTP > $IPT -t mangle -I PREROUTING -i $WANIFACE -j SHAPE-NNTP > $IPT -t mangle -A SHAPE-NNTP -p tcp --sport 119 -j MARK --set-mark 119 > > My thoughts on placing it in PREROUTING is that I'd like to shape the > traffic as soon as possible so that my firewall gets the benefit of > dealing with the reduced load as soon as possible. But, maybe that's > just foolishness? > > Here's the tc rules I tried. > > tc qdisc add dev $WANIFACE root handle 1: htb default 60 > tc class add dev $WANIFACE parent 1: classid 1:1 htb rate 10Mbit > tc class add dev $WANIFACE parent 1:1 classid 1:119 htb rate 800kbit > tc filter add dev $WANIFACE parent 1:1 protocol ip handle 119 fw flowid > 1:119 > > The one weird thing is that when I do a 'tc filter show dev $WANIFACE' > nothing comes back. But 'tc class show dev $WANIFACE' and 'tc qdisc > show dev $WANIFACE" return useful information. > > Here's some information that may be relevant: > > Linux elijah 2.4.24-hardened-r1 #1 Wed Mar 31 14:20:58 MST 2004 i686 > Mobile Pentium II GenuineIntel GNU/Linux > iproute-20010824-r4 > iptables-1.2.9 > > Thanks, From chris@leadingside.com.my Fri Apr 2 03:03:33 2004 From: chris@leadingside.com.my (Chris Winfield-Blum) Date: Fri, 2 Apr 2004 10:03:33 +0800 Subject: [LARTC] wondershaper question Message-ID: <9911B83A96D5CF44B5F326FF60E6EB690AD14F@mailsvr.leadingside.com.my> This is a multi-part message in MIME format. ------_=_NextPart_001_01C41856.B3F429D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I am very unclear about the wonder shaper and a bit of a novice=20 with Unix all together=20 =20 I have a question for you and I hope you can answer =20 Basically my office is getting a couple of people slowing down the=20 network so ive been looking around and found wondershaper =20 What I want to know is that can I rather than having low priority=20 ports have it with high priority ports =20 And the same with high priority hosts... =20 Can I have it so that say for example 192.168.1.2 192.168.1.3 are high=20 priority and port 20 22 80 443 110 25 etc are high priority? =20 Also how do I clear the rules I have made with the script?? =20 If I want it to return to the default for example?? =20 Thanks =20 Chris ------_=_NextPart_001_01C41856.B3F429D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi I am very unclear about the wonder shaper and a bit of a novice =

with Unix all together

 

I have a question for you and I hope you can = answer

 

Basically my office is getting a couple of people slowing down the =

network so ive been looking around and found = wondershaper

 

What I want to know is that can I rather than having low priority =

ports have it with high priority ports

 

And the same with high priority hosts...

 

Can I have it so that say for example 192.168.1.2 192.168.1.3 are high =

priority and port 20 22 80 443 110 25 etc are high = priority?

 

Also how do I clear the rules I have made with the = script??

 

If I want it to return to the default for = example??

 

Thanks

 

Chris

------_=_NextPart_001_01C41856.B3F429D6-- From jasonb@edseek.com Fri Apr 2 03:54:01 2004 From: jasonb@edseek.com (Jason Boxman) Date: Thu, 1 Apr 2004 21:54:01 -0500 Subject: [LARTC] wondershaper question In-Reply-To: <9911B83A96D5CF44B5F326FF60E6EB690AD14F@mailsvr.leadingside.com.my> References: <9911B83A96D5CF44B5F326FF60E6EB690AD14F@mailsvr.leadingside.com.my> Message-ID: <200404012154.01801.jasonb@edseek.com> On Thursday 01 April 2004 21:03, Chris Winfield-Blum wrote: > Hi I am very unclear about the wonder shaper and a bit of a novice > with Unix all together > > I have a question for you and I hope you can answer > > Basically my office is getting a couple of people slowing down the I would seriously suggest you attempt the social engineering route first if at all possible. > network so ive been looking around and found wondershaper > What I want to know is that can I rather than having low priority > ports have it with high priority ports > > And the same with high priority hosts... Wondershaper seems to essentially allow you to put traffic you don't like in the dog house. It doesn't seem to offer a facility to let you pick which ports or hosts constitute high priority traffic. > > > Can I have it so that say for example 192.168.1.2 192.168.1.3 are high > priority and port 20 22 80 443 110 25 etc are high priority? Not as it is written. > Also how do I clear the rules I have made with the script?? Try calling it with the keyword 'stop': bash wshaper.sh stop Which will perform: # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DEV root 2> /dev/null > /dev/null tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null > If I want it to return to the default for example?? > > Thanks > > Chris -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff From chris@leadingside.com.my Fri Apr 2 04:29:02 2004 From: chris@leadingside.com.my (Chris Winfield-Blum) Date: Fri, 2 Apr 2004 11:29:02 +0800 Subject: [LARTC] wondershaper question Message-ID: <9911B83A96D5CF44B5F326FF60E6EB690AD160@mailsvr.leadingside.com.my> Maybe there is another solution to this problem? The problem is that I have had a couple of users on the network hogging the bandwidth and while we do have a policy implemented sometimes the downloads are genuinely work related (eg downloaded a new version of an application we use for development) Sooo what I NEED is A script that will ensure that ports 80, 25, 110, 443, etc are priority Then that these are then are then "shaped" to not allow one person to hog it all. In an IDEAL situation I would like to break it up into classes Server Class: that has access to ALL ports and are priority for any traffic (maybe I can set them a guaranteed 100Kb/s)=20 User Class: that has priority access (that doesn't override the server class) to ports 80, 25, 110 etc. Perhaps the remaining 156Kb/s is divided evenly? Any suggestions? Im really NEW to this and would love some example scripts (preferably commently highly :P hehe) This was the address of the other script that I found: http://www.surestorm.com/qos/ I am not "set" on using wondershaper.. Thanks for all your help Chris From shane@howsyournetwork.com Fri Apr 2 04:19:42 2004 From: shane@howsyournetwork.com (Shane Hickey) Date: Thu, 1 Apr 2004 20:19:42 -0700 Subject: [LARTC] Need help with rate-limiting NTTP traffic In-Reply-To: <20040401144259.1e6d30fc@daneel.volumen.net> References: <20040401144259.1e6d30fc@daneel.volumen.net> Message-ID: <20040401201942.2ee259eb@daneel.volumen.net> I found the solution to my exact problem (right down the NNTP client) at http://mail.gnu.org/archive/html/pan-users/2003-11/msg00009.html For those who want the answer now with now clicking, you can do it all with this: tc qdisc add dev $WANIFACE handle ffff: ingress tc filter add dev $WANIFACE parent ffff: protocol ip prio 50 u32 match ip sport 119 0xffff police rate 800kbit burst 15k drop flowid :1 Thanks. -- Shane Hickey : Network/System Consultant GPG KeyID: 777CBF3F Key fingerprint: 254F B2AC 9939 C715 278C DA95 4109 9F69 777C BF3F Listening to: Bill Frisell - Vernon Reid - Small Hands From bugfood-ml@fatooh.org Fri Apr 2 05:38:40 2004 From: bugfood-ml@fatooh.org (Corey Hickey) Date: Thu, 01 Apr 2004 20:38:40 -0800 Subject: [LARTC] wondershaper question In-Reply-To: <9911B83A96D5CF44B5F326FF60E6EB690AD160@mailsvr.leadingside.com.my> References: <9911B83A96D5CF44B5F326FF60E6EB690AD160@mailsvr.leadingside.com.my> Message-ID: <406CEE50.4070508@fatooh.org> Chris Winfield-Blum wrote: > Maybe there is another solution to this problem? > > The problem is that I have had a couple of users on the network hogging > the bandwidth and while we do have a policy implemented sometimes the > downloads are genuinely work related (eg downloaded a new version of an > application we use for development) > > Sooo what I NEED is > > A script that will ensure that ports 80, 25, 110, 443, etc are priority > Then that these are then are then "shaped" to not allow one person to > hog it all. > > In an IDEAL situation I would like to break it up into classes > > Server Class: that has access to ALL ports and are priority for any > traffic (maybe I can set them a guaranteed 100Kb/s) > > User Class: that has priority access (that doesn't override the server > class) to ports 80, 25, 110 etc. Perhaps the remaining 156Kb/s is > divided evenly? > > Any suggestions? Im really NEW to this and would love some example > scripts (preferably commently highly :P hehe) > > This was the address of the other script that I found: > http://www.surestorm.com/qos/ > > I am not "set" on using wondershaper.. > > Thanks for all your help > > Chris > Wondershaper and other such scripts are good examples, but if you want very fine-grained control of your traffic shaping, you'll probably want to write your own script (or at least tweak one). Don't be intimidated by the apparent complexity of the examples you see -- although the commands for shaping traffic are probably unlike anything you've seen before, they're not hard to understand after reading the available documentation. Of course, www.lartc.org is a good place to start. Look through chapter 9, but don't worry if you don't understand everything the first time. The qdisc you want to use is htb (as you can see, that's the heart of wondershaper), and there's a good in-depth description at: http://luxik.cdi.cz/~devik/qos/htb/ (follow the link for "user guide"). -Corey From adrian@smartcall.ro Fri Apr 2 09:26:30 2004 From: adrian@smartcall.ro (Adrian Saileanu) Date: Fri, 2 Apr 2004 11:26:30 +0300 (EEST) Subject: [LARTC] Control Bandwidth In-Reply-To: References: Message-ID: <1501.192.193.194.7.1080894390.squirrel@mail.smartcall.ro> You are haveing tow major mistakes here which will make your script to have no efect over the $EXTIF, except the rate of 128k for uploading for everything that goes out of your box. Having a private ip which later will be SNATed , MASQed and because shaping will be done after POSTROUTING ( even for nat, mangle tables ) when a packet which arrives on the external interface will have as source the PUBLIC IP. So filter $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 u32 match ip src $IP flowid 1 will not match any packet. Check the "http://www.docum.org/stef.coene/qos/kptd/" page. It is very usefull. Second, on external interface you will never have packets with dst $IP ... what will mean a packet with dst $IP ? It means that a machine which has a network device with the ip = $IP should be somewhere on the internet ( behind $EXTIF ) ... but in reality, this machine is behind the $INTIF. So filter $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 u32 match ip dst $IP flowid 1 will not match any packet. > Hi all, > > I need a little help, i am studing htb to control user > bandwidth (download/upload) and I made a script as > below to test. I am testing using ttcp tool from by > linux box to other linux (192.168.200.51). > my box <---- Linux = more than 128kbit > mybot -----> Linux = get 128kbit > > But I want to control both ways, what am I missing? > > > script: > EXTIF=eth0 > INTIF=eth1 > TC=/sbin/tc > DOWN=128 > UP=64 > IP=192.168.200.201 > ################## > # > $TC qdisc del $EXTIF root 2> /dev/null > /dev/null > # > $TC qdisc add dev $EXTIF root handle 0: htb default 1 > $TC class add dev $EXTIF parent 0: classid 1 htb rate > 128Kbit ceil 128Kbit > # > $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 > u32 match ip src $IP flowid 1 > $TC filter add dev $EXTIF protocol ip parent 0:0 prio 1 > u32 match ip dst $IP flowid 1 > > Thanks, > Anderson > > > __________________________________________________________________________ > Acabe com aquelas janelinhas que pulam na sua tela. > AntiPop-up UOL - É grátis! > http://antipopup.uol.com.br/ > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > Adrian Saileanu Netmaster Communications Srl address: Str. Ion Brezoianu Nr. 20 Sector 1, Bucuresti, Romania office: +40 21 315 92 00 mobile: +40 723 979 586 email: adrian@smartcall.ro From cord@keppler.vrg.de Fri Apr 2 13:05:19 2004 From: cord@keppler.vrg.de (Cord Buhlert) Date: Fri, 2 Apr 2004 14:05:19 +0200 Subject: [LARTC] IMQ driver & kernel options Message-ID: <20040402120519.GA4268@keppler.vrg.de> Hi, i tried to insmod the imq.o module from http://pupa.da.ru/imq after a successful compile, but it thows this error: > insmod imq.o imq.o: unresolved symbol nf_unregister_hook imq.o: unresolved symbol nf_register_hook I think I have some kernel options disabled, does anyone know which one(s)? Thanks cord From gypsy@iswest.com Fri Apr 2 16:03:23 2004 From: gypsy@iswest.com (gypsy) Date: Fri, 02 Apr 2004 07:03:23 -0800 Subject: [LARTC] wondershaper question References: <9911B83A96D5CF44B5F326FF60E6EB690AD14F@mailsvr.leadingside.com.my> Message-ID: <406D80BB.212248A5@iswest.com> > Chris Winfield-Blum wrote: > > Hi I am very unclear about the wonder shaper and a bit of a novice > with Unix all together > > I have a question for you and I hope you can answer > > Basically my office is getting a couple of people slowing down the > network so ive been looking around and found wondershaper > > What I want to know is that can I rather than having low priority > ports have it with high priority ports Sure. > And the same with high priority hosts... Of course. > Can I have it so that say for example 192.168.1.2 192.168.1.3 are high > priority and port 20 22 80 443 110 25 etc are high priority? Yes, but be careful with NAT; finding 192.168.1.# can be tough. Also remember YOU DO NOT SHAPE DOWNLOADS! HTB can only "police" D/L, not "shape". You must use iptables or IMQ to "shape" D/L; I use iptables -m limit --limit ##/second -j ACCEPT iptables -j DROP and make sure that these 2 lines preceed any RELATED, ESTABLISHED accepts. Note that the real iptables rules include either --dport ## or --sport ##, depending on what the rule accomplishes. Note further that downloads are on INPUT so I specify -A INPUT to throttle D/L. > Also how do I clear the rules I have made with the script?? > If I want it to return to the default for example?? Read the effing script, man! > > Thanks > > Chris Please don't post using HTML. Here is a modified "wonder" script I call "ultimate"... http://andthatsjazz.net:8/ultimate.txt HTH gypsy From gypsy@iswest.com Fri Apr 2 16:44:44 2004 From: gypsy@iswest.com (gypsy) Date: Fri, 02 Apr 2004 07:44:44 -0800 Subject: [LARTC] wondershaper question References: <9911B83A96D5CF44B5F326FF60E6EB690AD14F@mailsvr.leadingside.com.my> <406D80BB.212248A5@iswest.com> Message-ID: <406D8A6C.D7CAB0A1@iswest.com> gypsy wrote: AFTERTHOUGHT: I should have been more precise: > Yes, but be careful with NAT; finding 192.168.1.# can be tough. Also > remember YOU DO NOT SHAPE DOWNLOADS! HTB can only "police" D/L, not > "shape". You must use iptables or IMQ to "shape" D/L; I use iptables -m > limit --limit ##/second -j ACCEPT > iptables -j DROP > and make sure that these 2 lines preceed any RELATED, ESTABLISHED > accepts. Note that the real iptables rules include either --dport ## or > --sport ##, depending on what the rule accomplishes. Note further that > downloads are on INPUT so I specify -A INPUT to throttle D/L. iptables is "rate limiting" not "shaping". NATted users are rate limited on the FORWARD chain, not INPUT. gypsy From roy@xxx.lt Fri Apr 2 17:06:04 2004 From: roy@xxx.lt (Roy) Date: Fri, 2 Apr 2004 19:06:04 +0300 Subject: [LARTC] IMQ driver & kernel options References: <20040402120519.GA4268@keppler.vrg.de> Message-ID: <002a01c418cc$66fc6af0$030aa8c0@t> which kernel you use? it is either possible that your kernel source is diferent from running kernel ot you have somethingn wron with netfilter are you sute you compiled iptables into kernel? preferably NOT as module. ----- Original Message ----- From: "Cord Buhlert" To: Sent: Friday, April 02, 2004 3:05 PM Subject: [LARTC] IMQ driver & kernel options > Hi, > i tried to insmod the imq.o module from http://pupa.da.ru/imq after a > successful compile, but it thows this error: > > > insmod imq.o > imq.o: unresolved symbol nf_unregister_hook > imq.o: unresolved symbol nf_register_hook > > > I think I have some kernel options disabled, does anyone know which > one(s)? > > > Thanks > cord > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From bugfood-ml@fatooh.org Fri Apr 2 17:40:14 2004 From: bugfood-ml@fatooh.org (Corey Hickey) Date: Fri, 02 Apr 2004 08:40:14 -0800 Subject: [LARTC] wondershaper question In-Reply-To: <406D80BB.212248A5@iswest.com> References: <9911B83A96D5CF44B5F326FF60E6EB690AD14F@mailsvr.leadingside.com.my> <406D80BB.212248A5@iswest.com> Message-ID: <406D976E.7060105@fatooh.org> gypsy wrote: > Also > remember YOU DO NOT SHAPE DOWNLOADS! HTB can only "police" D/L, not > "shape". You must use iptables or IMQ to "shape" D/L; I use iptables -m > limit --limit ##/second -j ACCEPT > iptables -j DROP > and make sure that these 2 lines preceed any RELATED, ESTABLISHED > accepts. Note that the real iptables rules include either --dport ## or > --sport ##, depending on what the rule accomplishes. Note further that > downloads are on INPUT so I specify -A INPUT to throttle D/L. > If you use htb or other shaping qdiscs on a router, you can set it up so that it sees packets that are leaving both interfaces and can therefore shape traffic in both directions. Sure, you can't shape traffic destined for the router itself, but that's rarely an issue. -Corey From gkade@bigbrother.net Fri Apr 2 21:03:02 2004 From: gkade@bigbrother.net (Gregory K. Ruiz-Ade) Date: Fri, 2 Apr 2004 12:03:02 -0800 Subject: [LARTC] Complex Routing/Firewalling/Bridging question Message-ID: <200404021203.04147.gkade@bigbrother.net> I'm being cast headlong into unfamiliar waters here, and being desperate for some air, thought I'd come here for some help. :) Anyway, my employer is going through some whiplash-inducing growth spurts, and as a result, the simple "Internet T-1 -> Linux Firewall/NAT -> LAN" setup just isn't going to cut it anymore. First, we're bringing in 2 additional T's and want to use BGP to provide for some measure of failover to an Class C portable IP block we own. My question regarding this is, what do I need to do on my Linux firewall/NAT box so that it knows how to send outbound packets? Second, we currently have two seperate DMZ networks, one for corporate Internet servers, and one for client-accessible Internet servers. Currently, both these networks, and our internal LAN, (and all of our IPSec-connected remote offices) are all subnets in the 10.* range, and NATted to the outside. I'm using Shorewall on RH9 (Linux 2.4) to handle the firewalling and SNAT/DNAT for the DMZs and NAT for the LAN, and FreeS/WAN for the IPSec WAN. What I would _like_ to do is build an "invisible" firewall between the routers provided with each of the three T-1 lines (yes, each T has it's own Cisco 2600-series router). Ideally, two, in some sort of fail-over configuration. I want to split the firewalling from the routing primarily to remove the chance of breaking one when working on the other, but this is not a set-in-stone requirement. So, given my poor ascii-art skills, the layout might look something like this: ^^^}-{T1(a)}--[cisco(a)]--+ +--{Service DMZ} 'N } | | e }-{T1(b)}--[cisco(b)]--+-[[firewall]-[router]]-+--{Corporate DMZ} t } | | vvv}-{T1(c)}--[cisco(c)]--+ +--{LAN} | +--{future growth} Now, for the sake of argument, we'll call our portable Class C 192.168.191.0/24. I hope to share it between the service DMZ and the corporate DMZ. The two DMZs need to be seperate for security concerns, and I'll need to do some amount of firewalling between the DMZs, and between the DMZs and the LAN, in addition to the firewalling between the Internet and our networks. So, here's my list of questions: Would it be better to forgo the edge firewall, and simply put firewalls on each network that connects to the Internet or another internal network? If so, should the NAT for the LAN be handled by the LAN's firewall, or the router? Since we really need to be able to connect from any network to any network internally, would I put the IPSec links in the linux router? Am I making this all too complex? Should I just combine the firewall & router into a single box, build a fail-over twin for it, and have it run the IPSec links, the proxy-arp for psuedo-bridging to the DMZs, the NAT for the LAN->Internet communications and all the internal routing? And where the hell does BGP for the T-1s fit into this mess? I guess I'm more lost than I thought. :( Any help or advice is appreciated. TIA, Gregory -- Gregory K. Ruiz-Ade OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu From dchemko@smgtec.com Sat Apr 3 00:25:05 2004 From: dchemko@smgtec.com (Daniel Chemko) Date: Fri, 2 Apr 2004 15:25:05 -0800 Subject: [LARTC] Complex Routing/Firewalling/Bridging question Message-ID: <7C9884991ADAE0479C14F10C858BCDF5122F3A@alderaan.smgtec.com> This is an intriguing problem, and one that applies to what my network is moving into. > First, we're bringing in 2 additional T's and want to use BGP to > provide for some measure of failover to an Class C portable IP block > we own. My question regarding this is, what do I need to do on my > Linux firewall/NAT box so that it knows how to send outbound packets? I can't tell you much about BGP, but I've heard horror stories about the excessive bandwidth needed just to send/receive the updates. One alternative to BGP would be WAN (for outbound) and DNS (for inbound) load balancing. This works if you have a large series of small IP sessions. This alternative wouldn't be appropriate if you have a few VERY large sessions to manage, like high-bandwidth IPSec tunnels. That's your judgment call. > Second, we currently have two seperate DMZ networks, one for corporate > Internet servers, and one for client-accessible Internet servers. > Currently, both these networks, and our internal LAN, (and all of our > IPSec-connected remote offices) are all subnets in the 10.* range, and > NATted to the outside. I'm using Shorewall on RH9 (Linux 2.4) to > handle the firewalling and SNAT/DNAT for the DMZs and NAT for the > LAN, and FreeS/WAN for the IPSec WAN. Sounds fine. I'm not sure how robust the shorewall framework is for complex networks, but if it works for you, all the better. > What I would _like_ to do is build an "invisible" firewall between the > routers provided with each of the three T-1 lines (yes, each T has > it's own Cisco 2600-series router). Ideally, two, in some sort of > fail-over configuration. I want to split the firewalling from the > routing primarily to remove the chance of breaking one when working > on the other, but this is not a set-in-stone requirement. I think you're on the right track. Just one point, you would have a hub/switch between each T1 and the firewall. This could be a one or two L3 switches, or you could just have a single switch/hub for each T1. I wouldn't have each T1 visible to each-other. I have inherent fears of people finding a vulnerability/DOS situation bouncing packets from one 1600 to another. That may not be based on reality, but it helps me sleep having all end points terminate at a firewall. > Would it be better to forgo the edge firewall, and simply put > firewalls on each network that connects to the Internet or another > internal network?=20 I'd have a single edge firewall that does internet filtering and all the NATing a router that does the route selection (assuming you're not using BGP) a firewall inside the router to handle inter-LAN filtering (if the IPSec drops in as a LAN subnet, I'd place it on the interior firewall) All of this could obviously be consolidated into one or two machines. The load and risk of configuration may increase having them on the same machine, but it is cheaper if it's a concern. > If so, should the NAT for the LAN be handled by the LAN's firewall, > or the router? Described above > Since we really need to be able to connect from any network to any > network internally, would I put the IPSec links in the Linux router? Described above > Am I making this all too complex? Should I just combine the firewall > & router into a single box, build a fail-over twin for it, and have > it run the IPSec links, the proxy-arp for psuedo-bridging to the > DMZs, the NAT for the LAN->Internet communications and all the > internal routing?=20 Failover is pretty much a requirement stepping beyond what we have here. You'll run into problems with making both active. Since you look like you'd go failover because of excessive workload, I'd follow my original suggestion above. For redundancy, you should definitely pair up each component eventually. Choose the ones with the highest failure rate to work with first. > And where the hell does BGP for the T-1s fit into this mess? Like I said, for a T1, you may run into problems. I can't say for sure one way or another. From Sandeep Agarwal" Dear All, Sorry to trouble again..... After go through www.lartc.org I have implemented the HTB instead of CBQ for the same scenario. Now following files are under /etc/sysconfig/htb directory. eth0 DEFAULT=30 R2Q=10 eth0-2.root RATE=256kbps BURST=25k eth0-2:10.comp1 RATE=120kbps BURST=12k PRIO=0 LEAF=sfq RULE=192.168.200.0/24 eth0-2:20.comp2 RATE=80kbps BURST=8k PRIO=1 LEAF=sfq RULE=192.168.100.0/24 eth0-2:30.server RATE=56kbps BURST=6k PRIO=3 LEAF=sfq RULE=203.145.134.120/29 -------------------- eth1-2:30.root RATE=56kbps BURST=6k eth1-2:30:300.all RATE=56kbps BURST=6k PRIO=3 LEAF=sfq RULE=203.145.134.120/29 MARK=3 -------------------- eth2-2:20.root RATE=80kbps BURST=8k eth2-2:20:200.all RATE=80kbps BURST=8k PRIO=1 LEAF=sfq RULE=192.168.100.0/24 MARK=2 -------------------- eth3-2:10.root RATE=120kbps BURST=12k eth3-2:10:100.all RATE=120kbps BURST=12k PRIO=0 LEAF=sfq RULE=192.168.200.0/24 MARK=1 ----------------------------- When I have run # service htb.init start # it returns nothing . Is it OK? Also stats returns nothing. Are the above configuration files OK? Thanking you, Sandeep Agarwal ----- Original Message ----- From: "Sandeep Agarwal" To: "LARTC" Sent: Monday, March 29, 2004 5:08 PM Subject: Suggestion required on CBQ !!!!!! > Dear Sir, > [snip] > ------------------------------------------------------------------------------------- > - > Scenario: Restrict Server, Comp1 & Comp2 on given speed. > --256kbps---|eth0(203.145.134.112/255.255.255.252) > |----eth1(Server room) 56kbps (203.145.134.120/255.255.255.248) > |----eth2(Company2) 80kbps (203.145.134.116/255.255.255.252) > & > (192.168.100.0/255.255.255.0) > |----eth3(Company1) 120kbps(192.168.200.0/255.255.255.0) > [snip] > From adrian@smartcall.ro Sat Apr 3 12:40:14 2004 From: adrian@smartcall.ro (Adrian Saileanu) Date: Sat, 3 Apr 2004 14:40:14 +0300 (EEST) Subject: [LARTC] Few question on HTB In-Reply-To: References: Message-ID: <2690.192.193.194.7.1080992414.squirrel@mail.smartcall.ro> Hello ... What are you trying to do ? I don't find any sence to your script ... you are attaching a htb disc on eth0, then map subclasses on eth1, eth2 eth3 ?????? I don't get it ... Can you tell us what are you trying to achieve ? > Dear All, > > Sorry to trouble again..... After go through www.lartc.org I have > implemented the HTB instead of CBQ > for the same scenario. > Now following files are under /etc/sysconfig/htb directory. > > eth0 DEFAULT=30 R2Q=10 > eth0-2.root RATE=256kbps BURST=25k > eth0-2:10.comp1 RATE=120kbps BURST=12k PRIO=0 LEAF=sfq > RULE=192.168.200.0/24 > eth0-2:20.comp2 RATE=80kbps BURST=8k PRIO=1 LEAF=sfq > RULE=192.168.100.0/24 > eth0-2:30.server RATE=56kbps BURST=6k PRIO=3 LEAF=sfq > RULE=203.145.134.120/29 > -------------------- > eth1-2:30.root RATE=56kbps BURST=6k > eth1-2:30:300.all RATE=56kbps BURST=6k PRIO=3 LEAF=sfq > RULE=203.145.134.120/29 MARK=3 > -------------------- > eth2-2:20.root RATE=80kbps BURST=8k > eth2-2:20:200.all RATE=80kbps BURST=8k PRIO=1 LEAF=sfq > RULE=192.168.100.0/24 MARK=2 > -------------------- > eth3-2:10.root RATE=120kbps BURST=12k > eth3-2:10:100.all RATE=120kbps BURST=12k PRIO=0 LEAF=sfq > RULE=192.168.200.0/24 MARK=1 > ----------------------------- > > When I have run > # service htb.init start > # > it returns nothing . Is it OK? Also stats returns nothing. Are the above > configuration files OK? > > Thanking you, > Sandeep Agarwal > ----- Original Message ----- > From: "Sandeep Agarwal" > To: "LARTC" > Sent: Monday, March 29, 2004 5:08 PM > Subject: Suggestion required on CBQ !!!!!! > > >> Dear Sir, >> > [snip] >> ------------------------------------------------------------------------------------- >> - >> Scenario: Restrict Server, Comp1 & Comp2 on given speed. >> --256kbps---|eth0(203.145.134.112/255.255.255.252) >> |----eth1(Server room) 56kbps >> (203.145.134.120/255.255.255.248) >> |----eth2(Company2) 80kbps >> (203.145.134.116/255.255.255.252) >> & >> (192.168.100.0/255.255.255.0) >> |----eth3(Company1) >> 120kbps(192.168.200.0/255.255.255.0) >> > [snip] >> > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > Adrian Saileanu Netmaster Communications Srl address: Str. Ion Brezoianu Nr. 20 Sector 1, Bucuresti, Romania office: +40 21 315 92 00 mobile: +40 723 979 586 email: adrian@smartcall.ro From Sandeep Agarwal" <2690.192.193.194.7.1080992414.squirrel@mail.smartcall.ro> Message-ID: Dear Sir, Please forgive me for my mistake...... I want to achieve the following at my gateway. Want to restrict Server, Comp1 & Comp2 on given speed. --256kbps--->|eth0(203.145.134.112/255.255.255.252) [A] |----eth1(Server room)-->56kbps (203.145.134.120/255.255.255.248) [B] |----eth2(Company1)---->80kbps (203.145.134.116/255.255.255.252) [C] & (192.168.100.0/255.255.255.0) |----eth3(Company2)---->120kbps (192.168.200.0/255.255.255.0)[D] I have RHL 9.0 with Kernel 2.4.20-8 on i686 & IPCHAINS as a firewall. Please suggest now what I have to do......??? Regards Sandeep Agarwal ----- Original Message ----- From: "Adrian Saileanu" To: "Sandeep Agarwal" Cc: "LARTC" Sent: Saturday, April 03, 2004 5:10 PM Subject: Re: [LARTC] Few question on HTB > > Hello ... > > What are you trying to do ? I don't find any sence to your script ... > you are attaching a htb disc on eth0, then map subclasses on eth1, eth2 > eth3 ?????? I don't get it ... > > Can you tell us what are you trying to achieve ? > > > Dear All, > > > > Sorry to trouble again..... After go through www.lartc.org I have > > implemented the HTB instead of CBQ > > for the same scenario. > > Now following files are under /etc/sysconfig/htb directory. > > > > eth0 DEFAULT=30 R2Q=10 > > eth0-2.root RATE=256kbps BURST=25k > > eth0-2:10.comp1 RATE=120kbps BURST=12k PRIO=0 LEAF=sfq > > RULE=192.168.200.0/24 > > eth0-2:20.comp2 RATE=80kbps BURST=8k PRIO=1 LEAF=sfq > > RULE=192.168.100.0/24 > > eth0-2:30.server RATE=56kbps BURST=6k PRIO=3 LEAF=sfq > > RULE=203.145.134.120/29 > > -------------------- > > eth1-2:30.root RATE=56kbps BURST=6k > > eth1-2:30:300.all RATE=56kbps BURST=6k PRIO=3 LEAF=sfq > > RULE=203.145.134.120/29 MARK=3 > > -------------------- > > eth2-2:20.root RATE=80kbps BURST=8k > > eth2-2:20:200.all RATE=80kbps BURST=8k PRIO=1 LEAF=sfq > > RULE=192.168.100.0/24 MARK=2 > > -------------------- > > eth3-2:10.root RATE=120kbps BURST=12k > > eth3-2:10:100.all RATE=120kbps BURST=12k PRIO=0 LEAF=sfq > > RULE=192.168.200.0/24 MARK=1 > > ----------------------------- > > > > When I have run > > # service htb.init start > > # > > it returns nothing . Is it OK? Also stats returns nothing. Are the above > > configuration files OK? > > > > Thanking you, > > Sandeep Agarwal [snip] > > > Adrian Saileanu > Netmaster Communications Srl > > address: Str. Ion Brezoianu Nr. 20 > Sector 1, Bucuresti, Romania > > office: +40 21 315 92 00 > mobile: +40 723 979 586 > email: adrian@smartcall.ro From stef.coene@docum.org Sat Apr 3 13:53:05 2004 From: stef.coene@docum.org (Stef Coene) Date: Sat, 3 Apr 2004 14:53:05 +0200 Subject: [LARTC] Few question on HTB In-Reply-To: References: <2690.192.193.194.7.1080992414.squirrel@mail.smartcall.ro> Message-ID: <200404031453.06281.stef.coene@docum.org> On Saturday 03 April 2004 14:24, Sandeep Agarwal wrote: > I want to achieve the following at my gateway. > > Want to restrict Server, Comp1 & Comp2 on given speed. > --256kbps--->|eth0(203.145.134.112/255.255.255.252) [A] > > |----eth1(Server room)-->56kbps > | (203.145.134.120/255.255.255.248) [B] > | ----eth2(Company1)---->80kbps > | (203.145.134.116/255.255.255.252) [C] > > & > (192.168.100.0/255.255.255.0) > > |----eth3(Company2)---->120kbps > | (192.168.200.0/255.255.255.0)[D] > > I have RHL 9.0 with Kernel 2.4.20-8 on i686 & IPCHAINS as a firewall. Ipchains is for 2.2.x kernel. Iptables is the new firewill configuration=20 tool. > Please suggest now what I have to do......??? Correct me if I'm wrong, but you have a router with 4 interfaces. Eth0 is = the=20 internet link and you want to control bandwidth used by the 3 other=20 interfaces. Remember that you can only shape outging bandwidth if you add = a=20 htb qdisc to a network interface. =46or shaping info, see lartc.org and docum.org. Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ =A0 =A0 =A0#lartc @ irc.openprojects.net From Sandeep Agarwal" <2690.192.193.194.7.1080992414.squirrel@mail.smartcall.ro> <200404031453.06281.stef.coene@docum.org> Message-ID: Hello Sir, I have linux box with 4 NIC. 256kbps is reaching upto eth0 after router. Now want to split the this bandwidh within remaining NIC's. I have gone through the lartc.org & prepared the earlier mentioned HTB script files. The name of files are eth0 eth0-2.root eth0-2:10.comp1 eth0-2:20.comp2 eth0-2:30.server -------------------- eth1-2:30.root eth1-2:30:300.all -------------------- eth2-2:20.root eth2-2:20:200.all -------------------- eth3-2:10.root eth3-2:10:100.all ----------------------------- I have already mailed the scripts to you on your ID. If you suggest, I can mail them again to you off the list. This is what I understand from the instruction of htb.init. Is these are correct for the mentioned purpose? Or should I have to prepare some more / other types of files. Thanking you, Sandeep Agarwal ----- Original Message ----- From: "Stef Coene" To: "Sandeep Agarwal" Cc: "LARTC" Sent: Saturday, April 03, 2004 6:23 PM Subject: Re: [LARTC] Few question on HTB On Saturday 03 April 2004 14:24, Sandeep Agarwal wrote: > I want to achieve the following at my gateway. > > Want to restrict Server, Comp1 & Comp2 on given speed. > --256kbps--->|eth0(203.145.134.112/255.255.255.252) [A] > > |----eth1(Server room)-->56kbps > | (203.145.134.120/255.255.255.248) [B] > | ----eth2(Company1)---->80kbps > | (203.145.134.116/255.255.255.252) [C] > > & > (192.168.100.0/255.255.255.0) > > |----eth3(Company2)---->120kbps > | (192.168.200.0/255.255.255.0)[D] > > I have RHL 9.0 with Kernel 2.4.20-8 on i686 & IPCHAINS as a firewall. Ipchains is for 2.2.x kernel. Iptables is the new firewill configuration tool. > Please suggest now what I have to do......??? Correct me if I'm wrong, but you have a router with 4 interfaces. Eth0 is the internet link and you want to control bandwidth used by the 3 other interfaces. Remember that you can only shape outging bandwidth if you add a htb qdisc to a network interface. For shaping info, see lartc.org and docum.org. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Sat Apr 3 14:59:26 2004 From: stef.coene@docum.org (Stef Coene) Date: Sat, 3 Apr 2004 15:59:26 +0200 Subject: [LARTC] Few question on HTB In-Reply-To: References: <200404031453.06281.stef.coene@docum.org> Message-ID: <200404031559.26370.stef.coene@docum.org> On Saturday 03 April 2004 15:34, Sandeep Agarwal wrote: > Hello Sir, > I have linux box with 4 NIC. 256kbps is reaching upto eth0 after router. > Now want to split the this bandwidh within remaining NIC's. I have gone > through the lartc.org & prepared the earlier mentioned HTB script files. > The name of files are=20 These files are useless for us. You use htb.init to configure the router=20 setup and this mailinglist is for general qos discussions, not for htb.init= =20 implementation details. > I have already mailed the scripts to you on your ID. If you suggest, I can > mail them again to you off the list. This is what I understand from the > instruction of htb.init. Is these are correct for the mentioned purpose? = Or > should I have to prepare some more / other types of files. You really should read some more documentation about this. =2D you can only shape outgoing traffic =2D what means prio - rate - burst - ceil =2D natting + filtering on ip address can be a problem Stef =2D- stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ =A0 =A0 =A0#lartc @ irc.openprojects.net From andre@tomt.net Sat Apr 3 17:29:19 2004 From: andre@tomt.net (Andre Tomt) Date: Sat, 03 Apr 2004 18:29:19 +0200 Subject: [LARTC] IMQ driver & kernel options In-Reply-To: <20040402120519.GA4268@keppler.vrg.de> References: <20040402120519.GA4268@keppler.vrg.de> Message-ID: <406EE65F.4050507@tomt.net> Cord Buhlert wrote: > Hi, > i tried to insmod the imq.o module from http://pupa.da.ru/imq after a > successful compile, but it thows this error: > > > insmod imq.o > imq.o: unresolved symbol nf_unregister_hook > imq.o: unresolved symbol nf_register_hook > > > I think I have some kernel options disabled, does anyone know which > one(s)? Try loading it with modprobe instead, it tries to resolve the dependencies for you. From gt90bh@zipmail.com.br Sun Apr 4 04:45:54 2004 From: gt90bh@zipmail.com.br (Leandro Andrade Travaglia) Date: Sun, 4 Apr 2004 00:45:54 -0300 Subject: [LARTC] Port Range on Whondershaper References: Message-ID: <000901c419f7$872a7660$4504a8c0@leandro> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C419DE.2F5C2AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, How can i set a port range in the low priority source ports = (NOPRIOPORTSRC=3D) on Whondershaper ??? I want to specify a port interval, like from 1025 to 5120, to have lower = priority. Shoud i use something like 1025-5120? Regards, LEANDRO TRAVAGLIA --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.648 / Virus Database: 415 - Release Date: 31/3/2004 ------=_NextPart_000_0006_01C419DE.2F5C2AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
How can i set a port range in=20 the low priority source ports=20 (NOPRIOPORTSRC=3D) on Whondershaper ???
I want to specify a port interval, like = from 1025=20 to 5120, to have lower priority.
Shoud i use something like=20 1025-5120?
 
Regards,
 
       =20     LEANDRO TRAVAGLIA

 
 

---
Outgoing mail is certified Virus Free.
Checked by AVG = anti-virus system (http://www.grisoft.com).
Version: = 6.0.648 /=20 Virus Database: 415 - Release Date: 31/3/2004
 ------=_NextPart_000_0006_01C419DE.2F5C2AA0-- From sebastian@aresca.com.ar Sun Apr 4 08:28:33 2004 From: sebastian@aresca.com.ar (Sebastian A. Aresca) Date: Sun, 4 Apr 2004 04:28:33 -0300 Subject: [LARTC] Bandwidth shaping per users with pam_auth Message-ID: <035d01c41a16$6ff70980$0400a8c0@wkswindowsxp> I am using squid with pam_auth and delay pools to control the banwidth to the inet access. The problem, of course, is that 80% of the bandwidth is wasted. So the idea is to make the same rules but with HTB or IMQ. I did it by mac-address but the problem is that the users move from a side to another one so this doens't work. I think to solve it using mark with iptables. For each user i apply a mark. So then move to the corresponding queue. But i'm looking for something faster than this. I listen to ideas ... Thanks in advance. Sebastián A. Aresca From abdulkhader7862003@yahoo.com Sun Apr 4 12:36:14 2004 From: abdulkhader7862003@yahoo.com (Abdul Khader) Date: Sun, 4 Apr 2004 04:36:14 -0700 (PDT) Subject: [LARTC] Clubbing of miltiple bandwidth sources. Message-ID: <20040404113614.30076.qmail@web40411.mail.yahoo.com> __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From abdulkhader7862003@yahoo.com Sun Apr 4 12:39:51 2004 From: abdulkhader7862003@yahoo.com (Abdul Khader) Date: Sun, 4 Apr 2004 04:39:51 -0700 (PDT) Subject: [LARTC] How I can club multiple bandwidth sources Message-ID: <20040404113951.69408.qmail@web40408.mail.yahoo.com> Hi All, Can anyone help me in clubbing multiple bandwidth sources into one single pipe. Here at my office I have three different lines, 2 leased lines and one adsl. I want to Clubb various bandwidth providers into a single gateway or into a single pipe. Regards Abdul Khader __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From abdulkhader7862003@yahoo.com Sun Apr 4 12:40:53 2004 From: abdulkhader7862003@yahoo.com (Abdul Khader) Date: Sun, 4 Apr 2004 04:40:53 -0700 (PDT) Subject: [LARTC] Can I give more bandwidth to a specific URL Message-ID: <20040404114053.79591.qmail@web40410.mail.yahoo.com> Hi all, Can I give more bandwidth to a specific URL. Regards Abdul Khader __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From lartc@pro-technica.com Sun Apr 4 16:45:00 2004 From: lartc@pro-technica.com (lartc@pro-technica.com) Date: Sun, 04 Apr 2004 18:45:00 +0300 Subject: [LARTC] 2 ISP Routing Problem Message-ID: Hello,I have single linux router ( fedora core 1 ), 2 ISP, 1 internal network,1 IP space from every ISP My scenario: eth0 1.0.0.2 netmask 255.255.255.252 -> ISP 1 eth1 2.0.0.2 netmask 255.255.255.252 -> ISP 2 eth2 1.0.1.1 netmask 255.255.255.0 -> IP space from ISP1 eth3 2.0.1.1 netmask 255.255.255.0 -> IP space from ISP2 Config I try: /etc/iproute2/rt_tables: 10 isp1 20 isp2 ip add rule from 1.0.1.0/24 table isp1 ip add rule from 2.0.1.0/24 table isp2 route del default ip route add default via 1.0.0.1 table isp1 ip route add default via 2.0.0.1 table isp2 At this point workstations connected to eth2 and eth3 connect to internet fine. BUT: with this config I can't communicate with workstations. If I try 'ping 1.0.1.2' I can see thah all packets with source IP1.0.1.1 are sent to eth0, and packets with source IP 2.0.1.1 are sent to eth1. #ip route get from 1.0.1.1 to 1.0.1.2 1.0.1.2 from 1.0.1.1 via 1.0.0.1 So, question is: How to setup iproute2, so kernel first consult internal routing table: 1.0.1.0/24 dev eth2 proto kernel scope link src 1.0.1.1 2.0.1.0/24 dev eth3 proto kernel scope link src 2.0.1.1 and AFTER THIS default routes I create with 'ip route default via ...' PS: All IP's are real, I don't use 10.x.x.x... From lartc@pro-technica.com Sun Apr 4 17:44:50 2004 From: lartc@pro-technica.com (lartc@pro-technica.com) Date: Sun, 04 Apr 2004 19:44:50 +0300 Subject: [LARTC] ip addr add vs ifconfig eth0:1 Message-ID: A stupid question: which is recomended? I have 1 interface eth0. I need to set about 20 virtual interfaces eth0:xx on it. If I create them with ifconfig eth0:xx I see it with ifconfig and with ip addr ls. If I set it with 'ip addr add', ifconfig don't show them, but 'ip addr ls' and 'route' show them. So, which is better? Thanks in advance. PS: I can't find anywhere docs about relationship between 'old' utilities ifconfig, route, etc and the iproute2 package. Point me to some comparision between them, please. From alan@whirlnet.co.uk Sun Apr 4 17:55:13 2004 From: alan@whirlnet.co.uk (Alan Ford) Date: Sun, 4 Apr 2004 17:55:13 +0100 Subject: [LARTC] ip addr add vs ifconfig eth0:1 In-Reply-To: References: Message-ID: <20040404165513.GI3133@newred.gradwell.net> On Sun, Apr 04, 2004 at 07:44:50PM +0300, lartc@pro-technica.com wrote: > I have 1 interface eth0. I need to set about 20 virtual interfaces eth0:xx > on it. > > If I create them with ifconfig eth0:xx I see it with ifconfig and with ip > addr ls. If I set it with 'ip addr add', ifconfig don't show them, but 'ip > addr ls' and 'route' show them. So, which is better? If you create them with: "ip addr add ... dev eth0 label eth0:xx" you can still give them ifconfig-compatible labels, visible with both tools. -- Alan Ford * alan@whirlnet.co.uk From roy@xxx.lt Sun Apr 4 20:46:55 2004 From: roy@xxx.lt (Roy) Date: Sun, 4 Apr 2004 22:46:55 +0300 Subject: [LARTC] Few question on HTB References: <2690.192.193.194.7.1080992414.squirrel@mail.smartcall.ro> <200404031453.06281.stef.coene@docum.org> Message-ID: <00e501c41a7d$95c36020$030aa8c0@t> since you have quite complex hardware setup, you should use imq driver, then you will be able shape any reafic and match on usefull addreses, out script is usable, just change eth0 to imq but if you use ipchains, then you cant use imq ----- Original Message ----- From: "Sandeep Agarwal" To: "Stef Coene" Cc: "LARTC" Sent: Saturday, April 03, 2004 4:34 PM Subject: Re: [LARTC] Few question on HTB > Hello Sir, > I have linux box with 4 NIC. 256kbps is reaching upto eth0 after router. Now want to > split the this bandwidh within remaining NIC's. > I have gone through the lartc.org & prepared the earlier mentioned HTB script files. > The name of files are > eth0 > eth0-2.root > eth0-2:10.comp1 > eth0-2:20.comp2 > eth0-2:30.server > -------------------- > eth1-2:30.root > eth1-2:30:300.all > -------------------- > eth2-2:20.root > eth2-2:20:200.all > -------------------- > eth3-2:10.root > eth3-2:10:100.all > ----------------------------- > I have already mailed the scripts to you on your ID. If you suggest, I can mail them > again to you off the list. > This is what I understand from the instruction of htb.init. Is these are correct for the > mentioned purpose? Or should I have to > prepare some more / other types of files. > > Thanking you, > Sandeep Agarwal > ----- Original Message ----- > From: '"'Stef Coene'"' > To: '"'Sandeep Agarwal'"' > Cc: '"'LARTC'"' > Sent: Saturday, April 03, 2004 6:23 PM > Subject: Re: [LARTC] Few question on HTB > > > On Saturday 03 April 2004 14:24, Sandeep Agarwal wrote: > > I want to achieve the following at my gateway. > > > > Want to restrict Server, Comp1 & Comp2 on given > speed. > > --256kbps--->|eth0(203.145.134.112/255.255.255.252) > [A] > > > > |----eth1(Server > room)-->56kbps > > | (203.145.134.120/255.255.255.248) > [B] > > | > ----eth2(Company1)---->80kbps > > | (203.145.134.116/255.255.255.252) > [C] > > > > > & > > (192.168.100.0/255.255.255.0) > > > > > |----eth3(Company2)---->120kbps > > | > (192.168.200.0/255.255.255.0)[D] > > > > I have RHL 9.0 with Kernel 2.4.20-8 on i686 & IPCHAINS as a > firewall. > Ipchains is for 2.2.x kernel. Iptables is the new firewill configuration > tool. > > > Please suggest now what I have to do......??? > Correct me if I'm wrong, but you have a router with 4 interfaces. Eth0 is the > internet link and you want to control bandwidth used by the 3 other > interfaces. Remember that you can only shape outging bandwidth if you add a > htb qdisc to a network interface. > > For shaping info, see lartc.org and docum.org. > > 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 roy@xxx.lt Sun Apr 4 20:38:00 2004 From: roy@xxx.lt (Roy) Date: Sun, 4 Apr 2004 22:38:00 +0300 Subject: [LARTC] Can I give more bandwidth to a specific URL References: <20040404114053.79591.qmail@web40410.mail.yahoo.com> Message-ID: <00c801c41a7c$56d4f3c0$030aa8c0@t> To url it is hard, but you can easily give more bandwithch to some server ----- Original Message ----- From: "Abdul Khader" To: Sent: Sunday, April 04, 2004 2:40 PM Subject: [LARTC] Can I give more bandwidth to a specific URL > Hi all, > Can I give more bandwidth to a specific URL. > > Regards > Abdul Khader > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > http://promotions.yahoo.com/design_giveaway/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From joan@jfuster.com Mon Apr 5 00:09:44 2004 From: joan@jfuster.com (Joan Fuster =?ISO-8859-1?Q?Monz=F3?=) Date: Mon, 05 Apr 2004 01:09:44 +0200 Subject: [LARTC] IMQ & NAT Message-ID: <1081120183.994.18.camel@snowball> --=-Bpyh0PBzodJOi+MH38eS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi all, my IMQ device works OK (thanks to Andy Furniss), but now I've problems to attach the traffic in the qdisc's. This is my conf: ----------------------------------------------------------------------- INET | |eth0 300Kbps ROUTER (NAT) |eth1 | LAN ----------------------------------------------------------------------- MAX=3D300 tc qdisc add dev imq0 root handle 1: htb default 13 = =20 tc class add dev imq0 parent 1: classid 1:1 htb rate ${MAX}kbit ceil ${MAX}kbit = =20 tc class add dev imq0 parent 1:1 classid 1:10 htb rate 60kbit ceil ${MAX}kbit prio 0 tc class add dev imq0 parent 1:1 classid 1:11 htb rate 40kbit ceil ${MAX}kbit prio 1 tc class add dev imq0 parent 1:1 classid 1:12 htb rate 100kbit ceil ${MAX}kbit prio 2 tc class add dev imq0 parent 1:1 classid 1:13 htb rate 100kbit ceil ${MAX}kbit prio 3 = =20 tc qdisc add dev imq0 parent 1:10 handle 100: sfq tc qdisc add dev imq0 parent 1:11 handle 110: sfq tc qdisc add dev imq0 parent 1:12 handle 120: sfq tc qdisc add dev imq0 parent 1:13 handle 130: sfq = =20 tc filter add dev imq0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10 tc filter add dev imq0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11 tc filter add dev imq0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12 tc filter add dev imq0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13 ip link set imq0 up iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0 = =20 #ICMP = =20 iptables -t mangle -A PREROUTING -i eth0 -p icmp -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -i eth0 -p icmp -j RETURN = =20 #SSH = =20 iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 22 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 22 -j RETURN ... ------------------------------------------------------------------------ I've patched the IMQ with the imq-nat patch, but all traffic goes to 1:13 #tc -s class show dev imq0 ------------------------------------------------------------------------- ... class htb 1:13 parent 1:1 leaf 130: prio 3 rate 100Kbit ceil 300Kbit burst 1727b cburst 1983b Sent 8981846847 bytes 18055130 pkts (dropped 99, overlimits 0) lended: 8947767 borrowed: 9107363 giants: 0 tokens: 136320 ctokens: 52265 =20 class htb 1:12 parent 1:1 leaf 120: prio 2 rate 100Kbit ceil 300Kbit burst 1727b cburst 1983b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 138240 ctokens: 52905 --------------------------------------------------------------------------- What happens?? I'm newbie in IMQ... Sorry for the long text ;) Thanks for the help!! Joan --=-Bpyh0PBzodJOi+MH38eS Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAcJW2HQxYD51Ds74RAvg8AJ4xOIGqc8/BMFWDJhH14HTXWEazxACfa9F4 QuI1sZxeT3AlyvNSfnaaeLU= =/tPm -----END PGP SIGNATURE----- --=-Bpyh0PBzodJOi+MH38eS-- From u52firw02@sneakemail.com Mon Apr 5 00:34:19 2004 From: u52firw02@sneakemail.com (Ryan Castellucci) Date: Sun, 4 Apr 2004 15:34:19 -0800 Subject: [LARTC] Routing through dummy interfaces? Message-ID: <20040404233421.F22751180C1@smtp.cal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a linux system with 4 ethernet interfaces, eth0 goes to the intern= et, eth1, eth2, and eth3 are NAT'd LANs. I want to use an ingress filter to prioritize bandwidth (downstream from internet) to various IPs. I want to sett it up something like this.... eth0 <--[NAT]--> dummy0 <---> dummy1 <---> eth1,eth2,eth3 dummy1 should have an ingress filter on it controling outbound bandwidth to the internet dummy0 should have an ingress filter on it controling inbound bandwidth from the internet Let's say... eth0 is 10.53.62.2/30 dummy0 is 192.168.255.1/24 dummy1 is 192.168.255.254/24 eth1 is 192.168.1.1/24 eth2 is 192.168.2.1/24 eth3 is 192.168.3.1/24 How do I set up routing so traffic to/from the internet gets routed through the dummy interfaces? If this is not possible, how might i achive a simmilar effect? - --=20 Any mail sent to the address this message was posted from will be bounced= =2E PGP/GPG Fingerprint: 3B30 C6BE B1C6 9526 7A90 34E7 11DF 44F3 7217 7BC7 On pgp.mit.edu, import with `gpg --keyserver pgp.mit.edu --recv-key 72177= BC7` Also available at http://www.cal.net/~ryan/ryan_at_mother_dot_com.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAcJt7Ed9E83IXe8cRAmDhAJkBGUOBWjWU9j1+i3Umf/ahQroGvQCfb4a3 9jHTZdXlv1mrGyRc+m29KFQ=3D =3DTTb/ -----END PGP SIGNATURE----- From roy@xxx.lt Mon Apr 5 01:50:03 2004 From: roy@xxx.lt (Roy) Date: Mon, 5 Apr 2004 03:50:03 +0300 Subject: [LARTC] Routing through dummy interfaces? References: <20040404233421.F22751180C1@smtp.cal.net> Message-ID: <010801c41aa7$f1ef29e0$030aa8c0@t> it is not possible to use dummy, mut you can use imq which was made exactly for this purpose. http://pupa.da.ru/imq/ ----- Original Message ----- From: "Ryan Castellucci" To: Sent: Monday, April 05, 2004 2:34 AM Subject: [LARTC] Routing through dummy interfaces? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a linux system with 4 ethernet interfaces, eth0 goes to the internet, eth1, eth2, and eth3 are NAT'd LANs. I want to use an ingress filter to prioritize bandwidth (downstream from internet) to various IPs. I want to sett it up something like this.... eth0 <--[NAT]--> dummy0 <---> dummy1 <---> eth1,eth2,eth3 dummy1 should have an ingress filter on it controling outbound bandwidth to the internet dummy0 should have an ingress filter on it controling inbound bandwidth from the internet Let's say... eth0 is 10.53.62.2/30 dummy0 is 192.168.255.1/24 dummy1 is 192.168.255.254/24 eth1 is 192.168.1.1/24 eth2 is 192.168.2.1/24 eth3 is 192.168.3.1/24 How do I set up routing so traffic to/from the internet gets routed through the dummy interfaces? If this is not possible, how might i achive a simmilar effect? - -- Any mail sent to the address this message was posted from will be bounced. PGP/GPG Fingerprint: 3B30 C6BE B1C6 9526 7A90 34E7 11DF 44F3 7217 7BC7 On pgp.mit.edu, import with `gpg --keyserver pgp.mit.edu --recv-key 72177BC7` Also available at http://www.cal.net/~ryan/ryan_at_mother_dot_com.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAcJt7Ed9E83IXe8cRAmDhAJkBGUOBWjWU9j1+i3Umf/ahQroGvQCfb4a3 9jHTZdXlv1mrGyRc+m29KFQ=b/ -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From mabrown-lartc@securepipe.com Mon Apr 5 01:50:53 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Sun, 4 Apr 2004 19:50:53 -0500 (CDT) Subject: [LARTC] ip addr add vs ifconfig eth0:1 In-Reply-To: References: Message-ID: Hello, : A stupid question: which is recomended? The iproute2 tools expose all of the complexity of the Linux kernel in a clear and transparent way, so I recommend iproute2 for any but the most pedestrian uses of IP addressing on Linux boxen. Naturally, for workstations and standalone boxen, there's no need--you will get the same result by using the much more platform agnostic ifconfig tool. : I have 1 interface eth0. I need to set about 20 virtual interfaces : eth0:xx on it. : : If I create them with ifconfig eth0:xx I see it with ifconfig and with : ip addr ls. If I set it with 'ip addr add', ifconfig don't show them, : but 'ip addr ls' and 'route' show them. So, which is better? As a previous poster (Alan Ford) has suggested, you can use the label parameter to your "ip addr" command lines. This will allow you to use both ifconfig and iproute2 tools to see what IP addresses are active on a given interface. : PS: I can't find anywhere docs about relationship between 'old' : utilities ifconfig, route, etc and the iproute2 package. Point me to : some comparision between them, please. I don't have any documentation specifically about the relationship between the two utilities, although you may find some answers in my guide [0]. Each utility reports (in a different way) on the current configuration of interfaces and their addresses. Best of luck, -Martin [0] http://linux-ip.net/ http://linux-ip.net/html/tools-ip-management.html -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From lartc@pro-technica.com Mon Apr 5 06:36:16 2004 From: lartc@pro-technica.com (lartc@pro-technica.com) Date: Mon, 05 Apr 2004 08:36:16 +0300 Subject: [LARTC] Re: 2 ISP Routing Problem In-Reply-To: References: Message-ID: I read carefully "Guide to IP Layer Networking", but this don't give idea how to make this simple ( I think ) route. My logic is: If packet coming from source adress 1.0.1.0/24 AND destination is NOT localy connected host ( 1.0.1.0/24 OR 2.0.1.0/24 OR 127.0.0.0/8 ), send it to ISP1 gateway 1.0.0.1. If packet coming from source adress 2.0.1.0/24 AND destination is NOT localy connected host ( 1.0.1.0/24 OR 2.0.1.0/24 OR 127.0.0.0/8 ), send it to ISP2 gateway 2.0.0.1. If packet coming ( from ISP1 or ISP2 ) have destination adress 1.0.1.0/24 OR 2.0.1.0/24 send it to coresponding eth interface. As see, there is NOT default route, all other source/destination combination will be droped ( with ICMP host unreachable may be? ). I can't believe, that no one use single Linux router like this.... lartc@pro-technica.com writes: > Hello,I have single linux router ( fedora core 1 ), 2 ISP, 1 internal > network,1 IP space from every ISP > My scenario: > eth0 1.0.0.2 netmask 255.255.255.252 -> ISP 1 > eth1 2.0.0.2 netmask 255.255.255.252 -> ISP 2 > eth2 1.0.1.1 netmask 255.255.255.0 -> IP space from ISP1 > eth3 2.0.1.1 netmask 255.255.255.0 -> IP space from ISP2 > > Config I try: > /etc/iproute2/rt_tables: > 10 isp1 > 20 isp2 > > ip add rule from 1.0.1.0/24 table isp1 > ip add rule from 2.0.1.0/24 table isp2 > route del default > ip route add default via 1.0.0.1 table isp1 > ip route add default via 2.0.0.1 table isp2 > > At this point workstations connected to eth2 and eth3 connect to internet > fine. > BUT: with this config I can't communicate with workstations. If I try > 'ping 1.0.1.2' I can see thah all packets with source IP1.0.1.1 are sent > to eth0, and packets with source IP 2.0.1.1 are sent to eth1. > > #ip route get from 1.0.1.1 to 1.0.1.2 > 1.0.1.2 from 1.0.1.1 via 1.0.0.1 > > So, question is: How to setup iproute2, so kernel first consult internal > routing table: > 1.0.1.0/24 dev eth2 proto kernel scope link src 1.0.1.1 > 2.0.1.0/24 dev eth3 proto kernel scope link src 2.0.1.1 > > and AFTER THIS default routes I create with 'ip route default via ...' > > PS: All IP's are real, I don't use 10.x.x.x... > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From abdulkhader7862003@yahoo.com Mon Apr 5 12:19:19 2004 From: abdulkhader7862003@yahoo.com (Abdul Khader) Date: Mon, 5 Apr 2004 04:19:19 -0700 (PDT) Subject: [LARTC] Can I give more bandwidth to a specific URL In-Reply-To: <00c801c41a7c$56d4f3c0$030aa8c0@t> Message-ID: <20040405111919.81822.qmail@web40408.mail.yahoo.com> Hi, How can I Do it. Regards Abdul Khader --- Roy wrote: > To url it is hard, > > but you can easily give more bandwithch to some > server > > > ----- Original Message ----- > From: "Abdul Khader" > To: > Sent: Sunday, April 04, 2004 2:40 PM > Subject: [LARTC] Can I give more bandwidth to a > specific URL > > > > Hi all, > > Can I give more bandwidth to a specific URL. > > > > Regards > > Abdul Khader > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Small Business $15K Web Design Giveaway > > http://promotions.yahoo.com/design_giveaway/ > > _______________________________________________ > > 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/ __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From jlist@riscozero.inf.br Mon Apr 5 12:29:12 2004 From: jlist@riscozero.inf.br (Jeronimo Zucco) Date: Mon, 5 Apr 2004 08:29:12 -0300 Subject: [LARTC] (no subject) Message-ID: <006e01c41b01$3819f900$e200a8c0@xwing> This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C41AE8.12B149C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_006B_01C41AE8.12B149C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
------=_NextPart_000_006B_01C41AE8.12B149C0-- From ferenc.kubinszky@wit.mht.bme.hu Mon Apr 5 16:51:40 2004 From: ferenc.kubinszky@wit.mht.bme.hu (Ferenc Kubinszky) Date: Mon, 5 Apr 2004 17:51:40 +0200 (CEST) Subject: [LARTC] dsmark and HTB Message-ID: Hello! I have some trouble with dsmark qdisc. I'd like to set DSCP value of my outgoing packets and add a rate limit to each one. I learned HTB and dsmark. They work properly, but I can't combine them like this: tc qdisc add DSMARK handle 1:0 ... tc class modify 1:1 ... tc class modify 2:2 ... ... tc qdsic add parent 1:1 HTB ... tc qdsic add parent 1:2 HTB ... -> RTNETLINK answers: File exists Isn't dsmark classfull? How could I change DSCP field and limit outgoing rate? OK, I can create a HTB "tree" and put a dsmark qdisc at all the leaf classes, but that seems a bit ugly to me... BR, + Kubinszky Ferenc ferenc.kubinszky@wit.mht.bme.hu + PhD Student of the Budapest University of Technology and Economics + Wireless Information Technology Lab http://wit.mht.bme.hu From roy@xxx.lt Mon Apr 5 17:29:13 2004 From: roy@xxx.lt (Roy) Date: Mon, 5 Apr 2004 19:29:13 +0300 Subject: [LARTC] Can I give more bandwidth to a specific URL References: <20040405111919.81822.qmail@web40408.mail.yahoo.com> Message-ID: <012601c41b2b$22fb3a50$030aa8c0@t> If you want to know more exactly how, then you should explain more exactly what you need ----- Original Message ----- From: "Abdul Khader" To: "Roy" ; Sent: Monday, April 05, 2004 2:19 PM Subject: Re: [LARTC] Can I give more bandwidth to a specific URL > Hi, > How can I Do it. > > Regards > Abdul Khader > > --- Roy wrote: > > To url it is hard, > > > > but you can easily give more bandwithch to some > > server > > > > > > ----- Original Message ----- > > From: '"'Abdul Khader'"' > http://promotions.yahoo.com/design_giveaway/ > > > _______________________________________________ > > > 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/ > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > http://promotions.yahoo.com/design_giveaway/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From andre.correa@pobox.com Mon Apr 5 16:58:08 2004 From: andre.correa@pobox.com (Andre Correa) Date: Mon, 05 Apr 2004 12:58:08 -0300 Subject: [LARTC] IMQ & NAT In-Reply-To: <1081120183.994.18.camel@snowball> References: <1081120183.994.18.camel@snowball> Message-ID: <40718210.7030705@pobox.com> Hi Joan, can you please tell us what version of kernel and iptables are you using? Are you using Patrick McHardy's / www.linuximq.net original IMQ implementation? tks Andre Correa www.linuximq.net Joan Fuster Monzó wrote: > Hi all, my IMQ device works OK (thanks to Andy Furniss), but now I've > problems to attach the traffic in the qdisc's. This is my conf: > > ----------------------------------------------------------------------- > INET > | > |eth0 300Kbps > ROUTER (NAT) > |eth1 > | > LAN > ----------------------------------------------------------------------- > > MAX=300 > > tc qdisc add dev imq0 root handle 1: htb default 13 > > tc class add dev imq0 parent 1: classid 1:1 htb rate ${MAX}kbit ceil > ${MAX}kbit > > tc class add dev imq0 parent 1:1 classid 1:10 htb rate 60kbit ceil > ${MAX}kbit prio 0 > tc class add dev imq0 parent 1:1 classid 1:11 htb rate 40kbit ceil > ${MAX}kbit prio 1 > tc class add dev imq0 parent 1:1 classid 1:12 htb rate 100kbit ceil > ${MAX}kbit prio 2 > tc class add dev imq0 parent 1:1 classid 1:13 htb rate 100kbit ceil > ${MAX}kbit prio 3 > > tc qdisc add dev imq0 parent 1:10 handle 100: sfq > tc qdisc add dev imq0 parent 1:11 handle 110: sfq > tc qdisc add dev imq0 parent 1:12 handle 120: sfq > tc qdisc add dev imq0 parent 1:13 handle 130: sfq > > tc filter add dev imq0 parent 1:0 protocol ip prio 1 handle 1 fw classid > 1:10 > tc filter add dev imq0 parent 1:0 protocol ip prio 2 handle 2 fw classid > 1:11 > tc filter add dev imq0 parent 1:0 protocol ip prio 3 handle 3 fw classid > 1:12 > tc filter add dev imq0 parent 1:0 protocol ip prio 4 handle 4 fw classid > 1:13 > > ip link set imq0 up > > iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0 > > #ICMP > iptables -t mangle -A PREROUTING -i eth0 -p icmp -j MARK --set-mark 1 > iptables -t mangle -A PREROUTING -i eth0 -p icmp -j RETURN > > #SSH > iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 22 -j MARK > --set-mark 1 > iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 22 -j RETURN > > ... > ------------------------------------------------------------------------ > > I've patched the IMQ with the imq-nat patch, but all traffic goes to > 1:13 > > #tc -s class show dev imq0 > ------------------------------------------------------------------------- > ... > > class htb 1:13 parent 1:1 leaf 130: prio 3 rate 100Kbit ceil 300Kbit > burst 1727b cburst 1983b > Sent 8981846847 bytes 18055130 pkts (dropped 99, overlimits 0) > lended: 8947767 borrowed: 9107363 giants: 0 > tokens: 136320 ctokens: 52265 > > class htb 1:12 parent 1:1 leaf 120: prio 2 rate 100Kbit ceil 300Kbit > burst 1727b cburst 1983b > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 138240 ctokens: 52905 > > --------------------------------------------------------------------------- > > What happens?? I'm newbie in IMQ... Sorry for the long text ;) Thanks > for the help!! > > Joan From lartc@leiserson.org Mon Apr 5 19:35:09 2004 From: lartc@leiserson.org (Andrew Leiserson) Date: Mon, 5 Apr 2004 14:35:09 -0400 Subject: [LARTC] prio and pfifo_fast not working the same? Message-ID: <20040405183509.GB5595@breakaway.mit.edu> I have a machine running 2.4.25 w/ wrr, ebtables-brnf, iptables CLASSIFY and esfq patches (not using esfq, though). I have wrr set up, and within each class I want to prioritize ssh, web, etc..., but right now I am testing with pings. I have the following in my POSTROUTING mangle table: CLASSIFY icmp -- anywhere anywhere CLASSIFY set 0:6 I find that if I attach a prio qdisc to the wrr class the pings come through fine (50-100 ms) even with a high bandwith application in the background. However, if I do not attach a qdisc to the wrr classes (leaving it with pfifo_fast), the ping times are 500-1000 ms or more. Any ideas why? I thought that a prio qdisc with default settings was equivalent to pfifo_fast. Thanks, - Andy From acid@dg.net.ua Mon Apr 5 23:54:14 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 01:54:14 +0300 Subject: [LARTC] htb v3 question - quantum and r2q again Message-ID: <20040405225413.GC11236@dg.net.ua> Hello! One simple question regaring htb2->htb3 way. I'm using 2.4.25 kernel with tc3 from Devik's site, RH9. My data flow is about 100Mbit duplex and is subject to grow, so I'm creating root class with 200Mbit rate, with r2q=10, quantum = rate/r2q, and 1500 < quantum < 200000 (sch_htb.c) with such r2q my default shaping window will be from 120Kbit to 16Mbit, right? So, the question is choosing r2q=10 -> max bandwith for root class=16M, or it affects only leafs? -- Michael Vasilenko From joan@jfuster.com Mon Apr 5 23:55:01 2004 From: joan@jfuster.com (Joan Fuster =?ISO-8859-1?Q?Monz=F3?=) Date: Tue, 06 Apr 2004 00:55:01 +0200 Subject: [LARTC] IMQ & NAT In-Reply-To: <40718210.7030705@pobox.com> References: <1081120183.994.18.camel@snowball> <40718210.7030705@pobox.com> Message-ID: <1081205700.4126.24.camel@snowball> --=-iVENMbWTPrLV3VYVy76u Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable El lun, 05-04-2004 a las 17:58, Andre Correa escribi=F3: > Hi Joan, can you please tell us what version of kernel and iptables are=20 > you using? Kernel -> 2.6.3 Iptables -> 1.2.9 > Are you using Patrick McHardy's / www.linuximq.net original IMQ=20 > implementation? I can't apply imq-nat patch to the imq patch, both from www.linuximq.net (only the imq). I used this patches http://www.digriz.org.uk/jdg-qos-script/releases/binaries-latest.tar.bz2 Finally, this is my new IMQ conf: iptables -t mangle -A POSTROUTING -o eth1 -j IMQ --todev 0 iptables -t mangle -A POSTROUTING -p tcp -o eth1 --sport 80 -j MARK --set-mark 3 iptables -t mangle -A POSTROUTING -p tcp -o eth1 --sport 80 -j RETURN ... Thanks Roy! Joan --=-iVENMbWTPrLV3VYVy76u Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAcePDHQxYD51Ds74RAvWNAKCoVKae9fY9cpTBzA+P2hZXS00sRQCeNb64 TEK1jzN0PV2Tk4uDX9PyFCs= =wrE7 -----END PGP SIGNATURE----- --=-iVENMbWTPrLV3VYVy76u-- From rubens@etica.net Tue Apr 6 03:20:39 2004 From: rubens@etica.net (rubens@etica.net) Date: Mon, 5 Apr 2004 23:20:39 -0300 (BRT) Subject: [LARTC] cbqmon.pl 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. ------=_NextPart_000_2281_01C41B63.D0C5C230 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Some time ago someone posted a nice script to monitor HTB classes, classmon.pl. A friend of mine ported it to CBQ, and attached is the result. Suggestions are welcome. Rubens > #!/usr/bin/perl > > # Classy CBQ Operations Monitor...in Perl > # Based on classmon.pl by Toby Cantor > # By BLFC > > # The following short command line options are parsed as you might expect. > # There is NO error checking. The options below are used as follows: > # > # -i > # -d # positive but less than unity. Lower equates to faster response> > # -u # including decimals. A value of 0.2 would update once every 5 seconds> > # -w # the wildcard characters '*' and '?' and they behave as in bash> > # > ## EWMA is calculated every 2nd update. This was tested on a Pentium 90, on > ## which the updates/second has a maximum of 6 or so. Do the math. The > ## default in this case is decent. Speaking of which... > # > # The defaults are first and should require no explanation. > > ($iface, $parm, $persec, $watchclass) = ('eth0', 0.6, 1, '*'); > while ($argument = shift @ARGV) > { > if ($argument =~ '-i') { $iface = shift @ARGV; } > elsif ($argument =~ '-d') { $parm = shift @ARGV; } > elsif ($argument =~ '-u') { $persec = shift @ARGV; } > elsif ($argument =~ '-w') { $watchclass = shift @ARGV; } > > } > > use Term::Cap; > use Time::HiRes qw(gettimeofday sleep); > > $clear = `clear`; > $terminal = Tgetent Term::Cap; > $origin = $terminal->Tgoto('cm',0,0); > $origin2 = $terminal->Tgoto('cm',0,3); > > $printrates=0; > $wait_time = 1/$persec - .1; > $starttime = $oldtime = gettimeofday(); > > $header = $origin . "$iface-$watchclass > Class kbps pps backlog dropped borrowed overact. tokens ctokens > ------ ------- ------ -------- -------- -------- -------- -------- ------- -\n"; > > format STDOUT = > @<<<<< @####.# @###.# @####### @####### @####### @####### @####### @####### > {$classid, @{$smoothed{$classid}}{'bytes','packets'}, > @{$classdata{$classid}}{'backlog','dropped','borrowed','overactions','tokens ','ctokens'}} > . > > print $clear.$header; > > $watchclass =~ s/\?/\./g; > $watchclass =~ s/\*/\.\*/g; > > while (@allinfo = (readpipe("tc -s class show dev $iface"))) > { > # class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit > # Sent 41352703832 bytes 165540580 pkts (dropped 0, overlimits 0) > # borrowed 0 overactions 0 avgidle 58 undertime 0 > # class cbq 1:1990 parent 1: leaf 1990: rate 4000Kbit (bounded) prio no-transmit > # Sent 22013154608 bytes 33663376 pkts (dropped 326694, overlimits 114912551) > # borrowed 0 overactions 807479 avgidle 26432 undertime 0 > foreach (@allinfo) > { > next unless /\S/; > chomp; > > next if ((/class cbq/ && ($classid = (split)[2])) || ($classid !~ /$watchclass/)); > next if (/Sent/ && > (@{$classdata{$classid}}{'bytes','packets','dropped'} = (split)[1,3,6])); > # next if (/backlog/ && chop && chop && > # ($classdata{$classid}{'backlog'} = (split)[4])); > next if (/borrowed/ && > (@{$classdata{$classid}}{'borrowed','overactions'} = (split)[1,3])); > # next if (/tokens/ && > # (@{$classdata{$classid}}{'tokens','ctokens'} = (split)[1,3])); > # $classdata{$classid}{'backlog'} = 0; > } > > $nowtime = gettimeofday(); > $difftime=$nowtime-$oldtime; > $oldtime = $nowtime; > > print $origin2; > foreach $classid (sort keys %classdata) > { > chop $classdata{$classid}{'dropped'}; > $classdata{$classid}{'bytes'} *= (8/1024); > > foreach $keyn ('bytes','packets') > { > last if $printrates; > > $smoothed{$classid}{$keyn} = > $parm * (($classdata{$classid}{$keyn} - $olddata{$classid}{$keyn})/($nowtime - $last_time)) + > (1-$parm) * $smoothed{$classid}{$keyn}; > > if ($nowtime-$starttime < 2/$persec) { $smoothed{$classid}{$keyn} = 0; } > $olddata{$classid}{$keyn} = $classdata{$classid}{$keyn}; > } > > > write; > } > $last_time = $nowtime unless $printrates; > $time_err = $difftime - 1/$persec; > $wait_time -= 3*$time_err/5; > sleep($wait_time); > $printrates++; > $printrates %=2; > } > > ------=_NextPart_000_2281_01C41B63.D0C5C230 Content-Type: APPLICATION/OCTET-STREAM; NAME="cbqmon.pl" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="cbqmon.pl" #!/usr/bin/perl # Classy CBQ Operations Monitor...in Perl # Based on classmon.pl by Toby Cantor # By BLFC # The following short command line options are parsed as you might = expect. # There is NO error checking. The options below are used as follows: #=20 # -i # -d # -u # -w # =20 ## EWMA is calculated every 2nd update. This was tested on a Pentium = 90, on ## which the updates/second has a maximum of 6 or so. Do the math. The ## default in this case is decent. Speaking of which... # =20 # The defaults are first and should require no explanation. ($iface, $parm, $persec, $watchclass) =3D ('eth0', 0.6, 1, '*'); while ($argument =3D shift @ARGV) { if ($argument =3D~ '-i') { $iface =3D shift @ARGV; } elsif ($argument =3D~ '-d') { $parm =3D shift @ARGV; } elsif ($argument =3D~ '-u') { $persec =3D shift @ARGV; } elsif ($argument =3D~ '-w') { $watchclass =3D shift @ARGV; } =20 } use Term::Cap; use Time::HiRes qw(gettimeofday sleep); $clear =3D `clear`; $terminal =3D Tgetent Term::Cap; $origin =3D $terminal->Tgoto('cm',0,0); $origin2 =3D $terminal->Tgoto('cm',0,3); $printrates=3D0; $wait_time =3D 1/$persec - .1; $starttime =3D $oldtime =3D gettimeofday(); $header =3D $origin . "$iface-$watchclass Class kbps pps backlog dropped borrowed overact. tokens = ctokens ------ ------- ------ -------- -------- -------- -------- -------- = --------\n"; format STDOUT =3D @<<<<< @####.# @###.# @####### @####### @####### @####### @####### = @####### {$classid, @{$smoothed{$classid}}{'bytes','packets'}, @{$classdata{$classid}}{'backlog','dropped','borrowed','overactions','tok= ens','ctokens'}} . print $clear.$header; $watchclass =3D~ s/\?/\./g; $watchclass =3D~ s/\*/\.\*/g; while (@allinfo =3D (readpipe("tc -s class show dev $iface"))) { # class cbq 1: root rate 100Mbit (bounded,isolated) prio no-transmit # Sent 41352703832 bytes 165540580 pkts (dropped 0, overlimits 0)=20 # borrowed 0 overactions 0 avgidle 58 undertime 0 # class cbq 1:1990 parent 1: leaf 1990: rate 4000Kbit (bounded) prio = no-transmit # Sent 22013154608 bytes 33663376 pkts (dropped 326694, overlimits = 114912551)=20 # borrowed 0 overactions 807479 avgidle 26432 undertime 0 foreach (@allinfo) { next unless /\S/; chomp; =20 next if ((/class cbq/ && ($classid =3D (split)[2])) || ($classid = !~ /$watchclass/)); next if (/Sent/ &&=20 (@{$classdata{$classid}}{'bytes','packets','dropped'} =3D = (split)[1,3,6])); # next if (/backlog/ && chop && chop && # ($classdata{$classid}{'backlog'} =3D (split)[4])); next if (/borrowed/ &&=20 (@{$classdata{$classid}}{'borrowed','overactions'} =3D = (split)[1,3])); # next if (/tokens/ && # (@{$classdata{$classid}}{'tokens','ctokens'} =3D = (split)[1,3])); # $classdata{$classid}{'backlog'} =3D 0; } =20 $nowtime =3D gettimeofday(); $difftime=3D$nowtime-$oldtime; $oldtime =3D $nowtime; =20 print $origin2; foreach $classid (sort keys %classdata) { chop $classdata{$classid}{'dropped'}; $classdata{$classid}{'bytes'} *=3D (8/1024); foreach $keyn ('bytes','packets') { last if $printrates; =20 $smoothed{$classid}{$keyn} =3D $parm * (($classdata{$classid}{$keyn} - = $olddata{$classid}{$keyn})/($nowtime - $last_time)) + (1-$parm) * $smoothed{$classid}{$keyn}; =20 if ($nowtime-$starttime < 2/$persec) { = $smoothed{$classid}{$keyn} =3D 0; } $olddata{$classid}{$keyn} =3D $classdata{$classid}{$keyn}; } =20 =20 write; } =20 $last_time =3D $nowtime unless $printrates; $time_err =3D $difftime - 1/$persec; $wait_time -=3D 3*$time_err/5; sleep($wait_time); $printrates++; $printrates %=3D2; } ------=_NextPart_000_2281_01C41B63.D0C5C230-- From mabrown-lartc@securepipe.com Tue Apr 6 05:34:59 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Mon, 5 Apr 2004 23:34:59 -0500 (CDT) Subject: [LARTC] Re: 2 ISP Routing Problem In-Reply-To: References: Message-ID: Hello, : I read carefully "Guide to IP Layer Networking", but this don't give : idea how to make this simple ( I think ) route. My logic is: Perhaps I should rewrite that section..... Here are my assumptions before the below. A main routing table with routes to all of the local networks, but no default route. { echo 10 ISP1 echo 20 ISP2 ; } >> /etc/iproute2/rt_tables : If packet coming from source adress 1.0.1.0/24 AND destination is NOT localy : connected host ( 1.0.1.0/24 OR 2.0.1.0/24 OR 127.0.0.0/8 ), send it to ISP1 : gateway 1.0.0.1. ip rule add prio 979 from 1.0.1.0/24 table main ip rule add prio 980 from 1.0.1.0/24 table ISP1 ip route add default via 1.0.0.1 table ISP1 This will allow packets with a source address of 1.0.1.0/24 to reach locally connect networks and the Internet via ISP1. By selecting the main routing table first, you'll be sure to allow access to the locally connected networks to and from each of the other locally connected networks. : If packet coming from source adress 2.0.1.0/24 AND destination is NOT localy : connected host ( 1.0.1.0/24 OR 2.0.1.0/24 OR 127.0.0.0/8 ), send it to ISP2 : gateway 2.0.0.1. ip rule add prio 969 from 2.0.1.0/24 table main ip rule add prio 970 from 2.0.1.0/24 table ISP2 ip route add default via 2.0.0.1 table ISP2 : If packet coming ( from ISP1 or ISP2 ) have destination adress : 1.0.1.0/24 OR 2.0.1.0/24 send it to coresponding eth interface. Quite! : As see, there is NOT default route, all other source/destination : combination will be droped ( with ICMP host unreachable may be? ). This should happen naturally with the above configuration, but you may wish to consider the following as well: ip rule del prio 32766 table main ip rule add prio 32766 unreachable This should force your box to send ICMP unreachables for any host not found in any of the routing table lookups. If you decide to do remove the final rule which refers to the main routing table, don't forget about loopback traffic: ip rule add prio 990 from 127.0.0.0/8 table main : I can't believe, that no one use single Linux router like this.... Nor can I. It's possible that the 38 people who have done this remain silent. In your earlier mail..... : ip add rule from 1.0.1.0/24 table isp1 : ip add rule from 2.0.1.0/24 table isp2 : route del default : ip route add default via 1.0.0.1 table isp1 : ip route add default via 2.0.0.1 table isp2 The problem is that tables isp1 and isp2 do not contain routes for networks 2.0.1.0/24 and 1.0.1.0/24 respectively. Inverting the lookup logic (as I do above), so that the default route is selected after the local routes prevents this from being a problem. : BUT: with this config I can't communicate with workstations. If I try : 'ping 1.0.1.2' I can see thah all packets with source IP1.0.1.1 are : sent to eth0, and packets with source IP 2.0.1.1 are sent to eth1. : : #ip route get from 1.0.1.1 to 1.0.1.2 : 1.0.1.2 from 1.0.1.1 via 1.0.0.1 Exactly as I expected, given your config. Let us know if you have success! Good luck! -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From abdulkhader7862003@yahoo.com Tue Apr 6 06:59:42 2004 From: abdulkhader7862003@yahoo.com (Abdul Khader) Date: Mon, 5 Apr 2004 22:59:42 -0700 (PDT) Subject: [LARTC] Can I give more bandwidth to a specific URL In-Reply-To: <012601c41b2b$22fb3a50$030aa8c0@t> Message-ID: <20040406055942.30165.qmail@web40406.mail.yahoo.com> Hi, WE have application servers in our wan. So, I want to give mor bandwidth to the application server's URL's, so that they are more accessable then anyother sites. Regards Abdul Khader --- Roy wrote: > If you want to know more exactly how, > then you should explain more exactly what you need > > > > ----- Original Message ----- > From: "Abdul Khader" > To: "Roy" ; > Sent: Monday, April 05, 2004 2:19 PM > Subject: Re: [LARTC] Can I give more bandwidth to a > specific URL > > > > Hi, > > How can I Do it. > > > > Regards > > Abdul Khader > > > > --- Roy wrote: > > > To url it is hard, > > > > > > but you can easily give more bandwithch to some > > > server > > > > > > > > > ----- Original Message ----- > > > From: '"'Abdul Khader'"' > > http://promotions.yahoo.com/design_giveaway/ > > > > > _______________________________________________ > > > > 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/ > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Small Business $15K Web Design Giveaway > > http://promotions.yahoo.com/design_giveaway/ > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc > HOWTO: http://lartc.org/ > > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From acid@dg.net.ua Tue Apr 6 07:16:35 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 09:16:35 +0300 Subject: [LARTC] htb2 -> htb3 problems Message-ID: <20040406061635.GA3453@dg.net.ua> Hello! I need to switch from htb2 to htb3, because of speed issues (for me, htb2 is unable to handle more then 100mbit duplex with ~550 classes), kernel profiling shows htb_dequeue_prio at 1st place with 3x isolation. So, I've moved from 2.4.19 to 2.4.25 kernel (hi-pac for classification/marking and htb3 for queueing), and traffic rate drop from 100 to 20mbit. What can be wrong? The only change I see is htb2 -> htb3 Here is my qdiscs/classes/filters example qdisc htb 1: dev eth0 r2q 10 default 2500 direct_packets_stat 4604 ver 3.13 qdisc sfq 100: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3300: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3301: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3302: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3304: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3305: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3306: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec qdisc sfq 3308: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 5sec [skip] class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 class htb 1:3300 parent 1:1 leaf 3300: prio 0 quantum 13107 rate 1Mbit ceil 1126Kbit burst 1023b/8 mpu 0b cburst 0b/8 mpu 0b level 0 class htb 1:3301 parent 1:1 leaf 3301: prio 0 quantum 10240 rate 800Kbit ceil 1Mbit burst 1023b/8 mpu 0b cburst 0b/8 mpu 0b level 0 class htb 1:3302 parent 1:1 leaf 3302: prio 0 quantum 13107 rate 1Mbit ceil 1200Kbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 class htb 1:3304 parent 1:1 leaf 3304: prio 0 quantum 4915 rate 384Kbit ceil 384Kbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 [skip] filter parent 1: protocol ip pref 50 fw filter parent 1: protocol ip pref 50 fw handle 0x14b4 classid 1:5300 filter parent 1: protocol ip pref 50 fw handle 0x14b5 classid 1:5301 filter parent 1: protocol ip pref 50 fw handle 0x14b6 classid 1:5302 filter parent 1: protocol ip pref 50 fw handle 0x14b8 classid 1:5304 filter parent 1: protocol ip pref 50 fw handle 0x14b9 classid 1:5305 filter parent 1: protocol ip pref 50 fw handle 0x14ba classid 1:5306 [skip] -- Michael Vasilenko From acid@dg.net.ua Tue Apr 6 07:46:37 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 09:46:37 +0300 Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: References: <20040406061635.GA3453@dg.net.ua> Message-ID: <20040406064637.GA11110@dg.net.ua> devik (devik@cdi.cz) wrote: > > I need to switch from htb2 to htb3, because of speed issues (for me, > > htb2 is unable to handle more then 100mbit duplex with ~550 classes), > > kernel profiling shows htb_dequeue_prio at 1st place with 3x isolation. > > > > So, I've moved from 2.4.19 to 2.4.25 kernel (hi-pac for classification/marking > > and htb3 for queueing), and traffic rate drop from 100 to 20mbit. > > > > What can be wrong? The only change I see is htb2 -> htb3 > > Hello, > > I suppose the drop you see is CPU bound ? Did you profiled it > again ? No, CPU is about times more in idle state in htb3, and 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the reason of moving to htb3. > Both HTB algorithms are very different so that one can expect > different behavior with different data/rules. But I can admit > that this 5x drop is rather big and unfortunate. any ideas? -- Michael Vasilenko From devik@cdi.cz Tue Apr 6 07:33:08 2004 From: devik@cdi.cz (devik) Date: Tue, 6 Apr 2004 08:33:08 +0200 (CEST) Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: <20040406061635.GA3453@dg.net.ua> Message-ID: > I need to switch from htb2 to htb3, because of speed issues (for me, > htb2 is unable to handle more then 100mbit duplex with ~550 classes), > kernel profiling shows htb_dequeue_prio at 1st place with 3x isolation. > > So, I've moved from 2.4.19 to 2.4.25 kernel (hi-pac for classification/marking > and htb3 for queueing), and traffic rate drop from 100 to 20mbit. > > What can be wrong? The only change I see is htb2 -> htb3 Hello, I suppose the drop you see is CPU bound ? Did you profiled it again ? Both HTB algorithms are very different so that one can expect different behavior with different data/rules. But I can admit that this 5x drop is rather big and unfortunate. devik From devik@cdi.cz Tue Apr 6 08:15:32 2004 From: devik@cdi.cz (devik) Date: Tue, 6 Apr 2004 09:15:32 +0200 (CEST) Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: <20040406064637.GA11110@dg.net.ua> Message-ID: > > I suppose the drop you see is CPU bound ? Did you profiled it > > again ? > > No, CPU is about times more in idle state in htb3, and > 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the > reason of moving to htb3. ok then it is config issue probably. you should pin it down to smallest possible number of classes for test (say up to 5 classes) and then use tc -s show class ... to see internal statistics. Look for classes with small (or negative) tokens or ctokens - these are in throttling state and are slowing throughtput - then think if it is ok .. >From data you send one can't decide what's bad. In any case and as I said before, behavioue changed a bit so that results can be a bit different a may need tc script changes. devik From mabrown-lartc@securepipe.com Tue Apr 6 10:17:12 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Tue, 6 Apr 2004 04:17:12 -0500 (CDT) Subject: [LARTC] Can I give more bandwidth to a specific URL In-Reply-To: <20040405111919.81822.qmail@web40408.mail.yahoo.com> References: <20040405111919.81822.qmail@web40408.mail.yahoo.com> Message-ID: Abdul, Good morning, Abdul. : > > Can I give more bandwidth to a specific URL. : > but you can easily give more bandwithch to some server : How can I Do it. : : > If you want to know more exactly how, : > then you should explain more exactly what you need : : WE have application servers in our wan. So, I want to : give mor bandwidth to the application server's URL's, : so that they are more accessable then anyother sites. It is difficult to answer your question in the form you have asked it. To those of us who frequent the list, it seems as though you are simply asking "How do I use traffic control under Linux?". If that is, indeed the question you are asking, then consider several starting points for reading about traffic control under Linux: LARTC HOWTO [0], Stef Coene's documentation [1], the LARTC FAQ [2], and my introduction to Linux traffic control [3]. There are dozens of other links embedded in each of these documents which can help you with particular applications of traffic control under Linux. If you are just starting out with traffic control under Linux, I strongly recommend learning and using tcng from the beginning. The control language offered by tcng (although technical) is much more like English or human language than the more arcane tc syntax. Here are some starting points for learning about tcng [4] [5]. (Lest there be any doubt, you will need tc, from iproute2, as well as tcng.) You'll still need to understand the traffic control system in order to harness the power of Linux traffic control, so please realize that there's a bit of a learning curve to climb before you can make use of bandwidth shaping, sharing and/or prioritization. Judging from the framing of your question, you wish to reserve some amount of bandwidth for a particular network application on a particular host. I'll recommend using HTB, and you'll get quite a bit of support from this list about HTB if you have more specific questions. -Martin [0] http://lartc.org/ [1] http://www.docum.org/ [2] http://www.docum.org/stef.coene/qos/faq/cache/ [3] http://tldp.org/HOWTO/Traffic-Control-HOWTO/ [4] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ [5] http://linux-ip.net/gl/tcng/ -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From ionut@topall.ro Tue Apr 6 18:44:12 2004 From: ionut@topall.ro (ionut@topall.ro) Date: Tue, 6 Apr 2004 13:44:12 -0400 (EDT) Subject: [LARTC] hashing Message-ID: <4473.81.180.12.254.1081273452.squirrel@mail.topall.ro> Hi i have 2 class C 80.97.103.0/24 and 81.180.12.0/24 but i dont konw how to set hashing tables for HTB tc add dev eth0 parent 1: prio 0 handle 1: protocol ip u32 divisor 256 tc add dev eth0 parent 1: prio 0 protocol ip u32 match src 80.97.103.0/24 hashkey mask 0x000000FF at 12 link 1: but i want 2 hashkey for 80.97.103.0/24 and for 81.180.12.0/24 can somebody help me ? From huffo@ig.com.br Tue Apr 6 12:09:05 2004 From: huffo@ig.com.br (huffo@ig.com.br) Date: Tue, 6 Apr 2004 08:09:05 -0300 Subject: [LARTC] Routing problem Message-ID: <20040406111546.E5E273FC9@outpost.ds9a.nl> Hi, i have one firewall/gateway server with two interfaces and a routing problem (?). eth0: external interface eth1: internal interface. Both ip address are valid. Services like DNS, HTTP is configured to run using eth1 ip address. The problem is when i try to connect from internet to firewall, i can´t see eth1 ip address... only eth0 ip address. So, when i try to connect to web server or transfer zones to slaves DNS servers, the connection fails (they cannot see eth1). Nothing that runs in eth1 ip address works for people outside my local network. My local network is working fine, because can see eth1, and has a masquerade rule to make transparent proxy. If i´m connected to firewall, i can see everything. I disabled all firewall rules to make tests... no results. Anyone can help me to find where is the problem? I think it´s a routing problem, but i don´t know where it is... Thanks in advance, Pereira _________________________________________________________ Voce quer um iGMail protegido contra vírus e spams? Clique aqui: http://www.igmailseguro.ig.com.br Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ From util@deuroconsult.ro Tue Apr 6 12:26:02 2004 From: util@deuroconsult.ro (Catalin BOIE) Date: Tue, 6 Apr 2004 14:26:02 +0300 (EEST) Subject: [LARTC] hashing In-Reply-To: <4473.81.180.12.254.1081273452.squirrel@mail.topall.ro> References: <4473.81.180.12.254.1081273452.squirrel@mail.topall.ro> Message-ID: On Tue, 6 Apr 2004 ionut@topall.ro wrote: > Hi i have 2 class C 80.97.103.0/24 and 81.180.12.0/24 but i dont konw how > to set hashing tables for HTB > tc add dev eth0 parent 1: prio 0 handle 1: protocol ip u32 divisor 256 > tc add dev eth0 parent 1: prio 0 protocol ip u32 match src 80.97.103.0/24 > hashkey mask 0x000000FF at 12 link 1: > > but i want 2 hashkey for 80.97.103.0/24 and for 81.180.12.0/24 can > somebody help me ? tc filter add dev eth0 parent 1: prio 0 handle 1: protocol ip u32 divisor 256 tc finlter add dev eth0 parent 1: prio 0 protocol ip u32 match src 80.97.103.0/24 hashkey mask 0x000000FF at 12 link 103: tc filter add dev eth0 parent 1: prio 0 protocol ip u32 match src 81.180.12.0/24 hashkey mask 0x000000FF at 12 link 12: # Create filters for every ip # for 80.97.103.0/24 tc filter add dev eth0 parent 1: protocol ip u32 ht 103:2: flowid 1:2 tc filter add dev eth0 parent 1: protocol ip u32 ht 103:3: flowid 1:3 ... tc filter add dev eth0 parent 1: protocol ip u32 ht 103:fe: flowid 1:254 # now for 81.180.12.0/24 tc filter add dev eth0 parent 1: protocol ip u32 ht 12:2: flowid 1:402 tc filter add dev eth0 parent 1: protocol ip u32 ht 12:3: flowid 1:403 ... tc filter add dev eth0 parent 1: protocol ip u32 ht 12:fe: flowid 1:654 > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro From acid@dg.net.ua Tue Apr 6 12:53:27 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 14:53:27 +0300 Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: References: <20040406064637.GA11110@dg.net.ua> Message-ID: <20040406115327.GA13689@dg.net.ua> devik (devik@cdi.cz) wrote: > > > I suppose the drop you see is CPU bound ? Did you profiled it > > > again ? > > > > No, CPU is about times more in idle state in htb3, and > > 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the > > reason of moving to htb3. > > ok then it is config issue probably. you should pin it down > to smallest possible number of classes for test (say up to > 5 classes) and then use tc -s show class ... to see internal > statistics. Look for classes with small (or negative) > tokens or ctokens - these are in throttling state and are > slowing throughtput - then think if it is ok .. ok I'm creating root with 200Mbit and parent with 10Mbit/1Mbit class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 131072 rate 10Mbit ceil 12Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 Sent 25443954 bytes 17155 pkts (dropped 0, overlimits 0) rate 143050bps 97pps backlog 25p lended: 17130 borrowed: 0 giants: 0 tokens: 335 ctokens: -787 class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) rate 2723bps 49pps lended: 0 borrowed: 0 giants: 0 tokens: 8241 ctokens: 8241 class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 Sent 25406104 bytes 17130 pkts (dropped 0, overlimits 0) rate 144147bps 98pps lended: 0 borrowed: 0 giants: 0 tokens: 8195 ctokens: 8195 class htb 1:3500 parent 1:1 leaf 3500: prio 0 quantum 13107 rate 1Mbit ceil 1Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) rate 2739bps 49pps lended: 8712 borrowed: 0 giants: 0 tokens: 12501 ctokens: -294 so, rate is 1,2Mbit and what is meaning of negative ctokens? > >From data you send one can't decide what's bad. In any case > and as I said before, behavioue changed a bit so that results > can be a bit different a may need tc script changes. > > devik > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Michael Vasilenko From acid@dg.net.ua Tue Apr 6 12:55:41 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 14:55:41 +0300 Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: <20040406115327.GA13689@dg.net.ua> References: <20040406064637.GA11110@dg.net.ua> <20040406115327.GA13689@dg.net.ua> Message-ID: <20040406115541.GB13689@dg.net.ua> Michael Vasilenko (acid@dg.net.ua) wrote: > devik (devik@cdi.cz) wrote: > > > > I suppose the drop you see is CPU bound ? Did you profiled it > > > > again ? > > > > > > No, CPU is about times more in idle state in htb3, and > > > 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the > > > reason of moving to htb3. > > > > ok then it is config issue probably. you should pin it down > > to smallest possible number of classes for test (say up to > > 5 classes) and then use tc -s show class ... to see internal > > statistics. Look for classes with small (or negative) > > tokens or ctokens - these are in throttling state and are > > slowing throughtput - then think if it is ok .. > > ok > I'm creating root with 200Mbit > and parent with 10Mbit/1Mbit and qdisc stats (I have sfq attached to each leaf htb class): qdisc sfq 5500: quantum 1514b limit 128p flows 128/1024 perturb 5sec Sent 52611108 bytes 35988 pkts (dropped 0, overlimits 0) backlog 22p qdisc sfq 3500: quantum 1514b limit 128p flows 128/1024 perturb 5sec Sent 1004864 bytes 18073 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 10 default 2500 direct_packets_stat 130 ver 3.13 Sent 53627322 bytes 54191 pkts (dropped 0, overlimits 89908) backlog 22p > class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 131072 rate 10Mbit ceil 12Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > Sent 25443954 bytes 17155 pkts (dropped 0, overlimits 0) > rate 143050bps 97pps backlog 25p > lended: 17130 borrowed: 0 giants: 0 > tokens: 335 ctokens: -787 > > class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > rate 2723bps 49pps > lended: 0 borrowed: 0 giants: 0 > tokens: 8241 ctokens: 8241 > > class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > Sent 25406104 bytes 17130 pkts (dropped 0, overlimits 0) > rate 144147bps 98pps > lended: 0 borrowed: 0 giants: 0 > tokens: 8195 ctokens: 8195 > > class htb 1:3500 parent 1:1 leaf 3500: prio 0 quantum 13107 rate 1Mbit ceil 1Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > rate 2739bps 49pps > lended: 8712 borrowed: 0 giants: 0 > tokens: 12501 ctokens: -294 > > > so, rate is 1,2Mbit > and what is meaning of negative ctokens? > > > >From data you send one can't decide what's bad. In any case > > and as I said before, behavioue changed a bit so that results > > can be a bit different a may need tc script changes. > > > > devik > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- > Michael Vasilenko -- Michael Vasilenko From devik@cdi.cz Tue Apr 6 13:02:18 2004 From: devik@cdi.cz (devik) Date: Tue, 6 Apr 2004 14:02:18 +0200 (CEST) Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: <20040406115327.GA13689@dg.net.ua> Message-ID: I see you have cburst 0 ! It is not allowed and is described in docs. What was commands to create the classes ? ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Tue, 6 Apr 2004, Michael Vasilenko wrote: > devik (devik@cdi.cz) wrote: > > > > I suppose the drop you see is CPU bound ? Did you profiled it > > > > again ? > > > > > > No, CPU is about times more in idle state in htb3, and > > > 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the > > > reason of moving to htb3. > > > > ok then it is config issue probably. you should pin it down > > to smallest possible number of classes for test (say up to > > 5 classes) and then use tc -s show class ... to see internal > > statistics. Look for classes with small (or negative) > > tokens or ctokens - these are in throttling state and are > > slowing throughtput - then think if it is ok .. > > ok > I'm creating root with 200Mbit > and parent with 10Mbit/1Mbit > > > class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 131072 rate 10Mbit ceil 12Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > Sent 25443954 bytes 17155 pkts (dropped 0, overlimits 0) > rate 143050bps 97pps backlog 25p > lended: 17130 borrowed: 0 giants: 0 > tokens: 335 ctokens: -787 > > class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > rate 2723bps 49pps > lended: 0 borrowed: 0 giants: 0 > tokens: 8241 ctokens: 8241 > > class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > Sent 25406104 bytes 17130 pkts (dropped 0, overlimits 0) > rate 144147bps 98pps > lended: 0 borrowed: 0 giants: 0 > tokens: 8195 ctokens: 8195 > > class htb 1:3500 parent 1:1 leaf 3500: prio 0 quantum 13107 rate 1Mbit ceil 1Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > rate 2739bps 49pps > lended: 8712 borrowed: 0 giants: 0 > tokens: 12501 ctokens: -294 > > > so, rate is 1,2Mbit > and what is meaning of negative ctokens? > > > >From data you send one can't decide what's bad. In any case > > and as I said before, behavioue changed a bit so that results > > can be a bit different a may need tc script changes. > > > > devik > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- > Michael Vasilenko > > From huffo@ig.com.br Tue Apr 6 13:28:16 2004 From: huffo@ig.com.br (huffo@ig.com.br) Date: Tue, 6 Apr 2004 09:28:16 -0300 Subject: [LARTC] Routing problem Message-ID: <20040406123121.EEA3844B6@outpost.ds9a.nl> Of course. IP_FORWARDING is enable for a long time. Pereira. Em 6 Apr 2004, huffo@ig.com.br escreveu: >Hi, >i have one firewall/gateway server with two interfaces and a routing >problem (?). > >eth0: external interface >eth1: internal interface. Both ip address are valid. > >Services like DNS, HTTP is configured to run using eth1 ip address. > >The problem is when i try to connect from internet to firewall, i can´t see >eth1 ip address... only eth0 ip address. > >So, when i try to connect to web server or transfer zones to slaves DNS >servers, the connection fails (they cannot see eth1). Nothing that runs in >eth1 ip address works for people outside my local network. > >My local network is working fine, because can see eth1, and has a masquerade >rule to make transparent proxy. > >If i´m connected to firewall, i can see everything. > >I disabled all firewall rules to make tests... no results. > >Anyone can help me to find where is the problem? I think it´s a routing >problem, but i don´t know where it is... > >Thanks in advance, >Pereira > >_________________________________________________________ >Voce quer um iGMail protegido contra vírus e spams? >Clique aqui: http://www.igmailseguro.ig.com.br >Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >---------- _________________________________________________________ Voce quer um iGMail protegido contra vírus e spams? Clique aqui: http://www.igmailseguro.ig.com.br Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ From roy@xxx.lt Tue Apr 6 13:23:15 2004 From: roy@xxx.lt (Roy) Date: Tue, 6 Apr 2004 15:23:15 +0300 Subject: [LARTC] Can I give more bandwidth to a specific URL References: <20040406055942.30165.qmail@web40406.mail.yahoo.com> Message-ID: <017a01c41bd1$f09ef2c0$030aa8c0@t> So as I see you want to give priority to your own server. this is most simple case, and you should simply read tc manual, and give priority to that server ip address. another way is to use prio shaper on your router, then mark packets on desired servers with aproriate TOS, this way is better if you have more than one server. htis way is simpler than using htb with filters all you need is to atach prio to the output interface and use iptables for on your derired server to mark packet's tos field as high priority(real time) ----- Original Message ----- From: "Abdul Khader" To: Cc: "Roy" Sent: Tuesday, April 06, 2004 8:59 AM Subject: Re: [LARTC] Can I give more bandwidth to a specific URL > Hi, > WE have application servers in our wan. So, I want to > give mor bandwidth to the application server's URL's, > so that they are more accessable then anyother sites. > > Regards > Abdul Khader > > --- Roy wrote: > > If you want to know more exactly how, > > then you should explain more exactly what you need > > > > > > > > ----- Original Message ----- > > From: '"'Abdul Khader'"' > 'Roy' > > > > > > > _______________________________________________ > > > > > 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/ > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Small Business $15K Web Design Giveaway > > > http://promotions.yahoo.com/design_giveaway/ > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc > > HOWTO: http://lartc.org/ > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > http://promotions.yahoo.com/design_giveaway/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From acid@dg.net.ua Tue Apr 6 13:56:38 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 15:56:38 +0300 Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: References: <20040406115327.GA13689@dg.net.ua> Message-ID: <20040406125637.GC13689@dg.net.ua> devik (devik@cdi.cz) wrote: > I see you have cburst 0 ! It is not allowed > and is described in docs. What was commands to > create the classes ? /sbin/tc.3 qdisc add dev eth0 root handle 1:0 htb default 2500 r2q 100 /sbin/tc.3 class add dev eth0 parent 1:0 classid 1:1 htb rate 200mbit ceil 200mbit quantum 200000 /sbin/tc.3 class add dev eth0 parent 1:0 classid 1:2 htb rate 200mbit ceil 200mbit quantum 200000 /sbin/tc.3 class add dev eth0 parent 1:1 classid 1:3500 htb rate 10Mbit ceil 10Mbit burst 2048b cburst 1 /sbin/tc.3 qdisc add dev eth0 parent 1:3500 handle 3500: sfq perturb 5 /sbin/tc.3 class add dev eth0 parent 1:2 classid 1:5500 htb rate 20Mbit ceil 20Mbit burst 2048b cburst 1 quantum 60000 /sbin/tc.3 qdisc add dev eth0 parent 1:5500 handle 5500: sfq perturb 5 /sbin/tc.3 filter add dev eth0 parent 1:0 protocol ip prio 50 handle 3500 fw classid 1:3500 /sbin/tc.3 filter add dev eth0 parent 1:0 protocol ip prio 50 handle 5500 fw classid 1:5500 tc.3 -V tc utility, iproute2-ss020116 > On Tue, 6 Apr 2004, Michael Vasilenko wrote: > > > devik (devik@cdi.cz) wrote: > > > > > I suppose the drop you see is CPU bound ? Did you profiled it > > > > > again ? > > > > > > > > No, CPU is about times more in idle state in htb3, and > > > > 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the > > > > reason of moving to htb3. > > > > > > ok then it is config issue probably. you should pin it down > > > to smallest possible number of classes for test (say up to > > > 5 classes) and then use tc -s show class ... to see internal > > > statistics. Look for classes with small (or negative) > > > tokens or ctokens - these are in throttling state and are > > > slowing throughtput - then think if it is ok .. > > > > ok > > I'm creating root with 200Mbit > > and parent with 10Mbit/1Mbit > > > > > > class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 131072 rate 10Mbit ceil 12Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > > Sent 25443954 bytes 17155 pkts (dropped 0, overlimits 0) > > rate 143050bps 97pps backlog 25p > > lended: 17130 borrowed: 0 giants: 0 > > tokens: 335 ctokens: -787 > > > > class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > > rate 2723bps 49pps > > lended: 0 borrowed: 0 giants: 0 > > tokens: 8241 ctokens: 8241 > > > > class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > > Sent 25406104 bytes 17130 pkts (dropped 0, overlimits 0) > > rate 144147bps 98pps > > lended: 0 borrowed: 0 giants: 0 > > tokens: 8195 ctokens: 8195 > > > > class htb 1:3500 parent 1:1 leaf 3500: prio 0 quantum 13107 rate 1Mbit ceil 1Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > > rate 2739bps 49pps > > lended: 8712 borrowed: 0 giants: 0 > > tokens: 12501 ctokens: -294 > > > > > > so, rate is 1,2Mbit > > and what is meaning of negative ctokens? > > > > > >From data you send one can't decide what's bad. In any case > > > and as I said before, behavioue changed a bit so that results > > > can be a bit different a may need tc script changes. > > > > > > devik > > > > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > -- > > Michael Vasilenko > > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Michael Vasilenko From devik@cdi.cz Tue Apr 6 14:06:59 2004 From: devik@cdi.cz (devik) Date: Tue, 6 Apr 2004 15:06:59 +0200 (CEST) Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: <20040406125637.GC13689@dg.net.ua> Message-ID: remove cburst 1 ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Tue, 6 Apr 2004, Michael Vasilenko wrote: > devik (devik@cdi.cz) wrote: > > I see you have cburst 0 ! It is not allowed > > and is described in docs. What was commands to > > create the classes ? > > > /sbin/tc.3 qdisc add dev eth0 root handle 1:0 htb default 2500 r2q 100 > /sbin/tc.3 class add dev eth0 parent 1:0 classid 1:1 htb rate 200mbit ceil 200mbit quantum 200000 > /sbin/tc.3 class add dev eth0 parent 1:0 classid 1:2 htb rate 200mbit ceil 200mbit quantum 200000 > /sbin/tc.3 class add dev eth0 parent 1:1 classid 1:3500 htb rate 10Mbit ceil 10Mbit burst 2048b cburst 1 > /sbin/tc.3 qdisc add dev eth0 parent 1:3500 handle 3500: sfq perturb 5 > /sbin/tc.3 class add dev eth0 parent 1:2 classid 1:5500 htb rate 20Mbit ceil 20Mbit burst 2048b cburst 1 quantum 60000 > /sbin/tc.3 qdisc add dev eth0 parent 1:5500 handle 5500: sfq perturb 5 > /sbin/tc.3 filter add dev eth0 parent 1:0 protocol ip prio 50 handle 3500 fw classid 1:3500 > /sbin/tc.3 filter add dev eth0 parent 1:0 protocol ip prio 50 handle 5500 fw classid 1:5500 > > > > tc.3 -V > tc utility, iproute2-ss020116 > > > On Tue, 6 Apr 2004, Michael Vasilenko wrote: > > > > > devik (devik@cdi.cz) wrote: > > > > > > I suppose the drop you see is CPU bound ? Did you profiled it > > > > > > again ? > > > > > > > > > > No, CPU is about times more in idle state in htb3, and > > > > > 5x lowest data rate. AFAIK, htb3 scheduler is faster, so that is the > > > > > reason of moving to htb3. > > > > > > > > ok then it is config issue probably. you should pin it down > > > > to smallest possible number of classes for test (say up to > > > > 5 classes) and then use tc -s show class ... to see internal > > > > statistics. Look for classes with small (or negative) > > > > tokens or ctokens - these are in throttling state and are > > > > slowing throughtput - then think if it is ok .. > > > > > > ok > > > I'm creating root with 200Mbit > > > and parent with 10Mbit/1Mbit > > > > > > > > > class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 131072 rate 10Mbit ceil 12Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > > > Sent 25443954 bytes 17155 pkts (dropped 0, overlimits 0) > > > rate 143050bps 97pps backlog 25p > > > lended: 17130 borrowed: 0 giants: 0 > > > tokens: 335 ctokens: -787 > > > > > > class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > > > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > > > rate 2723bps 49pps > > > lended: 0 borrowed: 0 giants: 0 > > > tokens: 8241 ctokens: 8241 > > > > > > class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 > > > Sent 25406104 bytes 17130 pkts (dropped 0, overlimits 0) > > > rate 144147bps 98pps > > > lended: 0 borrowed: 0 giants: 0 > > > tokens: 8195 ctokens: 8195 > > > > > > class htb 1:3500 parent 1:1 leaf 3500: prio 0 quantum 13107 rate 1Mbit ceil 1Mbit burst 2Kb/8 mpu 0b cburst 0b/8 mpu 0b level 0 > > > Sent 482570 bytes 8712 pkts (dropped 0, overlimits 0) > > > rate 2739bps 49pps > > > lended: 8712 borrowed: 0 giants: 0 > > > tokens: 12501 ctokens: -294 > > > > > > > > > so, rate is 1,2Mbit > > > and what is meaning of negative ctokens? > > > > > > > >From data you send one can't decide what's bad. In any case > > > > and as I said before, behavioue changed a bit so that results > > > > can be a bit different a may need tc script changes. > > > > > > > > devik > > > > > > > > _______________________________________________ > > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > > -- > > > Michael Vasilenko > > > > > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- > Michael Vasilenko > > From acid@dg.net.ua Tue Apr 6 14:27:09 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Tue, 6 Apr 2004 16:27:09 +0300 Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: References: <20040406125637.GC13689@dg.net.ua> Message-ID: <20040406132708.GD13689@dg.net.ua> devik (devik@cdi.cz) wrote: > remove cburst 1 thanks! class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 65536 rate 5Mbit ceil 5Mbit burst 20Kb/8 mpu 0b cburst 8151b/8 mpu 0b level 0 Sent 45107618 bytes 42138 pkts (dropped 0, overlimits 0) rate 608617bps 548pps backlog 40p lended: 42098 borrowed: 0 giants: 0 tokens: 3908 ctokens: -11502 class htb 1:1 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 Sent 369059 bytes 6711 pkts (dropped 0, overlimits 0) rate 5706bps 104pps lended: 0 borrowed: 0 giants: 0 tokens: 8241 ctokens: 8241 class htb 1:2 root rate 200Mbit ceil 200Mbit burst 263690b/8 mpu 0b cburst 263690b/8 mpu 0b level 7 Sent 45055458 bytes 42098 pkts (dropped 0, overlimits 0) rate 613755bps 549pps lended: 0 borrowed: 0 giants: 0 tokens: 7822 ctokens: 7822 class htb 1:3500 parent 1:1 leaf 3500: prio 0 quantum 131072 rate 10Mbit ceil 10Mbit burst 20Kb/8 mpu 0b cburst 14704b/8 mpu 0b level 0 Sent 369059 bytes 6711 pkts (dropped 0, overlimits 0) rate 5833bps 106pps lended: 6711 borrowed: 0 giants: 0 tokens: 12713 ctokens: 9104 but I see only 330Kbytes/sec flow (half of 5Mbit rate) -- Michael Vasilenko From ionut@topall.ro Tue Apr 6 21:36:27 2004 From: ionut@topall.ro (ionut@topall.ro) Date: Tue, 6 Apr 2004 16:36:27 -0400 (EDT) Subject: [LARTC] hashing rule don't match Message-ID: <4562.81.180.12.254.1081283787.squirrel@mail.topall.ro> Hi i have 2 class C 80.97.103.0/24 and 81.180.12.0/24 but i dont konw how to set hashing tables for HTB tc add dev eth0 parent 1: prio 0 handle 1: protocol ip u32 divisor 256 tc add dev eth0 parent 1: prio 0 protocol ip u32 match src 80.97.103.0/24 hashkey mask 0x000000FF at 12 link 1: but i want 2 hashkey for 80.97.103.0/24 and for 81.180.12.0/24 can somebody help me ? this is a part fo my script tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 1 r2q 1 tc class add dev eth0 parent 1: classid 1:1 htb rate 640Kbit ceil 640Kbit prio 0 tc class add dev eth0 parent 1:1 classid 1:201 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:202 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:203 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:204 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:205 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:206 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:207 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:208 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:209 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:210 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:211 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:212 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc class add dev eth0 parent 1:1 classid 1:213 htb rate 1Kbit ceil 64Kbit prio 7 quantum 1500 tc filter add dev eth0 parent 1: prio 0 handle 1: protocol ip u32 divisor 256 tc filter add dev eth0 parent 1: prio 0 protocol ip u32 match ip src 80.97.103.0/24 hashkey mask 0x000000ff at 12 link 1: tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:2: match ip src 80.97.103.74 flowid 1:201 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:3: match ip src 80.97.103.64 flowid 1:202 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:4: match ip src 80.97.103.65 flowid 1:203 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:5: match ip src 80.97.103.66 flowid 1:204 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:6: match ip src 80.97.103.67 flowid 1:205 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:7: match ip src 80.97.103.68 flowid 1:206 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:8: match ip src 80.97.103.69 flowid 1:207 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:9: match ip src 80.97.103.70 flowid 1:208 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:10: match ip src 80.97.103.71 flowid 1:209 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:11: match ip src 80.97.103.72 flowid 1:211 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:12: match ip src 80.97.103.73 flowid 1:212 tc filter add dev eth0 prio 7 parent 1: protocol ip u32 ht 1:13: match ip src 80.97.103.75 flowid 1:213 but somting is wrong the filters don't match but i don't get errors From gregoriandres@yahoo.com.ar Tue Apr 6 19:59:55 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Tue, 6 Apr 2004 15:59:55 -0300 Subject: [LARTC] medir trafico Message-ID: hola listeros! existe algun script webScript, proyecto, herramienta o lo que sea, que sirva para medir el trafico total de una lan, como para hacer reportes mensuales por host ? necesito hacer algo asi: host Trafico/mes ----------------------------- 192.168.1.x1 xxxxx Bytes 192.168.1.x2 xxxxx Bytes 192.168.1.x3 xxxxx Bytes 192.168.1.x4 xxxxx Bytes ese seria un reporte a efectuar el ultimo dia de cada mes... saludos y gracias !!! mac From rubens@etica.net Tue Apr 6 20:00:57 2004 From: rubens@etica.net (rubens@etica.net) Date: Tue, 6 Apr 2004 16:00:57 -0300 (BRT) Subject: [LARTC] medir trafico In-Reply-To: Message-ID: ipac-ng Rubens On Tue, 6 Apr 2004, ThE LinuX_KiD wrote: > hola listeros! > > existe algun script webScript, proyecto, herramienta > o lo que sea, que sirva para medir el trafico total de una > lan, como para hacer reportes mensuales por host ? > > necesito hacer algo asi: > > > host Trafico/mes > ----------------------------- > 192.168.1.x1 xxxxx Bytes > 192.168.1.x2 xxxxx Bytes > 192.168.1.x3 xxxxx Bytes > 192.168.1.x4 xxxxx Bytes > > > ese seria un reporte a efectuar el ultimo > dia de cada mes... > > saludos y gracias !!! > mac > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From neilson@predialnet.com.br Tue Apr 6 20:05:34 2004 From: neilson@predialnet.com.br (Neilson Henriques) Date: Tue, 6 Apr 2004 16:05:34 -0300 Subject: [LARTC] medir trafico References: Message-ID: <001401c41c0a$236cf390$0201c80a@H4X0RN0T3B00K> bandwidthd.sf.net ----- Original Message ----- From: "ThE LinuX_KiD" To: "lartc" Sent: Tuesday, April 06, 2004 3:59 PM Subject: [LARTC] medir trafico > hola listeros! > > existe algun script webScript, proyecto, herramienta > o lo que sea, que sirva para medir el trafico total de una > lan, como para hacer reportes mensuales por host ? > > necesito hacer algo asi: > > > host Trafico/mes > ----------------------------- > 192.168.1.x1 xxxxx Bytes > 192.168.1.x2 xxxxx Bytes > 192.168.1.x3 xxxxx Bytes > 192.168.1.x4 xxxxx Bytes > > > ese seria un reporte a efectuar el ultimo > dia de cada mes... > > saludos y gracias !!! > mac > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From reed_zhou@yahoo.com Tue Apr 6 22:11:00 2004 From: reed_zhou@yahoo.com (Reed Zhou) Date: Tue, 6 Apr 2004 14:11:00 -0700 (PDT) Subject: [LARTC] tc tool source Message-ID: <20040406211100.18758.qmail@web13205.mail.yahoo.com> --0-1357087107-1081285860=:18438 Content-Type: text/plain; charset=us-ascii Hi, For some reason I could not use binary tc tool on my target (For example, when I run "tc qdisc show dev eth0", I got "RTNETLINK answer: Invalid argument"). It might be due to mismatch between the kernel and the tool, so I'd like to recompile tc tool together with the kernel. Where I can get tc source code? My kernel is based on 2.4.21. Thank you for help! Reed --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1357087107-1081285860=:18438 Content-Type: text/html; charset=us-ascii
Hi,
 
For some reason I could not use binary tc tool on my target (For example, when I run "tc qdisc show dev eth0", I got "RTNETLINK answer: Invalid argument"). It might be due to mismatch between the kernel and the tool, so I'd like to recompile tc tool together with the kernel. Where I can get tc source code? My kernel is based on 2.4.21.
 
Thank you for help!
 
Reed

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1357087107-1081285860=:18438-- From jasonb@edseek.com Tue Apr 6 22:29:01 2004 From: jasonb@edseek.com (Jason Boxman) Date: Tue, 6 Apr 2004 16:29:01 -0500 Subject: [LARTC] Can I give more bandwidth to a specific URL In-Reply-To: References: <20040405111919.81822.qmail@web40408.mail.yahoo.com> Message-ID: <200404061729.01973.jasonb@edseek.com> On Tuesday 06 April 2004 05:17, Martin A. Brown wrote: > If you are just starting out with traffic control under Linux, I strongly > recommend learning and using tcng from the beginning. The control > language offered by tcng (although technical) is much more like English or > human language than the more arcane tc syntax. Here are some starting > points for learning about tcng [4] [5]. (Lest there be any doubt, you > will need tc, from iproute2, as well as tcng.) Speaking of TCNG, I read through the various guides and I still can't figure out how I am supposed to be using tcsim. While I can get it to output information and graph it, the output does not mean anything to me. I was expecting output similar to what appears on the HTB author's Web site, since that means a lot more to me. What is tcsim telling me exactly? Thanks! > -Martin > > [0] http://lartc.org/ > [1] http://www.docum.org/ > [2] http://www.docum.org/stef.coene/qos/faq/cache/ > [3] http://tldp.org/HOWTO/Traffic-Control-HOWTO/ > [4] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ > [5] http://linux-ip.net/gl/tcng/ From damion@snapgear.com Wed Apr 7 00:32:18 2004 From: damion@snapgear.com (Damion de Soto) Date: Wed, 07 Apr 2004 09:32:18 +1000 Subject: [LARTC] Routing problem In-Reply-To: <20040406111546.E5E273FC9@outpost.ds9a.nl> References: <20040406111546.E5E273FC9@outpost.ds9a.nl> Message-ID: <40733E02.6070500@snapgear.com> Hi Pereira, > i have one firewall/gateway server with two interfaces and a routing > problem (?). > > eth0: external interface > eth1: internal interface. Both ip address are valid. > Anyone can help me to find where is the problem? I think it´s a routing > problem, but i don´t know where it is... Has your ISP placed routing entries for eth1 IP via eth0 IP ? Are they on the same subnets ? If you do a traceroute from the internet, you should see your hops hit eth0 (and then if everything was working, hit eth1) > Of course. IP_FORWARDING is enable for a long time. I assume you've also turned it on in /proc/sys/net/ipv4/ip_forward ? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- From huffo@ig.com.br Wed Apr 7 02:16:46 2004 From: huffo@ig.com.br (huffo@ig.com.br) Date: Tue, 6 Apr 2004 22:16:46 -0300 Subject: [LARTC] Routing problem Message-ID: <20040407012356.36E0D456B@outpost.ds9a.nl> I installed gated to resolve my routing problem. It wa s a RIP problem. Thanks a lot, Mauricio. Em 07 Apr 2004, Damion de Soto escreveu: >Hi Pereira, >> i have one firewall/gateway server with two interfaces and a routing >> problem (?). >> >> eth0: external interface >> eth1: internal interface. Both ip address are valid. >> Anyone can help me to find where is the problem? I think it´s a routing >> problem, but i don´t know where it is... > >Has your ISP placed routing entries for eth1 IP via eth0 IP ? >Are they on the same subnets ? >If you do a traceroute from the internet, you should see your hops hit eth0 >(and then if everything was working, hit eth1) > > > Of course. IP_FORWARDING is enable for a long time. >I assume you've also turned it on in /proc/sys/net/ipv4/ip_forward ? > >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Damion de Soto - Software Engineer email: damion@snapgear.com >SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 > | Custom Embedded Solutions fax: +61 7 3891 3630 > | and Security Appliances web: http://www.snapgear.com >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > --- Free Embedded Linux Distro at http://www.snapgear.org --- > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >---------- _________________________________________________________ Voce quer um iGMail protegido contra vírus e spams? Clique aqui: http://www.igmailseguro.ig.com.br Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ From huffo@ig.com.br Wed Apr 7 02:26:45 2004 From: huffo@ig.com.br (huffo@ig.com.br) Date: Tue, 6 Apr 2004 22:26:45 -0300 Subject: [LARTC] Routing problem Message-ID: <20040407012649.5C29F4584@outpost.ds9a.nl> Anyone knows a pdf, text, html that explains how /etc/gateway, or gated.conf works? I installed gated, configured rip1 and now is working, but i want to know everything about... Thanks any help, _________________________________________________________ Voce quer um iGMail protegido contra vírus e spams? Clique aqui: http://www.igmailseguro.ig.com.br Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ From stillnick2@terra.com.br Wed Apr 7 04:38:15 2004 From: stillnick2@terra.com.br (Cristiano Soares) Date: Wed, 7 Apr 2004 00:38:15 -0300 Subject: [LARTC] cant get FAIL-OVER to work... Message-ID: <003701c41c51$c33d26f0$6400a8c0@stillnicks> This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C41C38.9D84AA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. Im having a problem that is driving me crazy. I cant get link = fail-over to work in my RedHat9 Linux. I have two ADSL lines exactly the = same speed, and im doing NAT with the linux box. Whenever the first line = (eth2 in my case) goes down, i run a bash script that i made to change = the default route to the backup line (eth0). eth1 is my internal = network. I want to be able to make the linux box do that for me. I = already tried many load balancing sites, but still cant figure it out. I = just gave up today, and i want to know if any good soul would help me to = make it work by getting into my Redhat box using SSH. Thanks a lot = everyone. My ICQ is: 3794264 My MSN is: stillnick@msn.com Cristiano Soares ------=_NextPart_000_0034_01C41C38.9D84AA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all. Im having a problem that is driving = me crazy.=20 I cant get link fail-over to work in my RedHat9 Linux. I have two ADSL = lines=20 exactly the same speed, and im doing NAT with the linux box. Whenever = the first=20 line (eth2 in my case) goes down, i run a bash script that i made = to change=20 the default route to the backup line (eth0). eth1 is my internal = network. I want=20 to be able to make the linux box do that for me. I already = tried many load=20 balancing sites, but still cant figure it out. I just gave up today, and = i want=20 to know if any good soul would help me to make it work by getting into = my Redhat=20 box using SSH. Thanks a lot everyone.
 
My ICQ is: 3794264
My MSN is: stillnick@msn.com
 
Cristiano Soares
 
------=_NextPart_000_0034_01C41C38.9D84AA00-- From damion@snapgear.com Wed Apr 7 05:50:22 2004 From: damion@snapgear.com (Damion de Soto) Date: Wed, 07 Apr 2004 14:50:22 +1000 Subject: [LARTC] cant get FAIL-OVER to work... In-Reply-To: <003701c41c51$c33d26f0$6400a8c0@stillnicks> References: <003701c41c51$c33d26f0$6400a8c0@stillnicks> Message-ID: <4073888E.6060905@snapgear.com> Hi Cristiano, > Hi all. Im having a problem that is driving me crazy. I cant get link > fail-over to work in my RedHat9 Linux. ---snip----- > I want to be able to make the linux box do that for me. I > already tried many load balancing sites, but still cant figure it out. I > just gave up today, and i want to know if any good soul would help me to > make it work by getting into my Redhat box using SSH. Thanks a lot everyone. I'm sure quite a few people might like to ssh to your Redhat box. I don't know how you can make sure they're "good souls" though. If you provided some more details as to exactly what's going wrong, then perhaps someone could help you fix it yourself and not compromise the security of your system. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- From devik@cdi.cz Wed Apr 7 06:51:36 2004 From: devik@cdi.cz (Martin Devera) Date: Wed, 7 Apr 2004 07:51:36 +0200 (CEST) Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: <20040406132708.GD13689@dg.net.ua> References: <20040406125637.GC13689@dg.net.ua> <20040406132708.GD13689@dg.net.ua> Message-ID: > > remove cburst 1 > > thanks! > > class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 65536 rate 5Mbit > ceil 5Mbit burst 20Kb/8 mpu 0b cburst 8151b/8 mpu 0b level 0 > Sent 45107618 bytes 42138 pkts (dropped 0, overlimits 0) > rate 608617bps 548pps backlog 40p > lended: 42098 borrowed: 0 giants: 0 > tokens: 3908 ctokens: -11502 > > but I see only 330Kbytes/sec flow (half of 5Mbit rate) >From above I see rate 608617bps = 4.7MBit. Probably it will settle down after some while. I suspect there is problem in your way of measuring the rate. Also you can deliberately increase (c)burst to more than default, say to 20kB - the larger the burst it the more insensitive to CPU load it is ... devik From acid@dg.net.ua Wed Apr 7 11:13:34 2004 From: acid@dg.net.ua (Michael Vasilenko) Date: Wed, 7 Apr 2004 13:13:34 +0300 Subject: [LARTC] htb2 -> htb3 problems In-Reply-To: References: <20040406125637.GC13689@dg.net.ua> <20040406132708.GD13689@dg.net.ua> Message-ID: <20040407101334.GC12596@dg.net.ua> Martin Devera (devik@cdi.cz) wrote: > > > remove cburst 1 > > > > thanks! > > > > class htb 1:5500 parent 1:2 leaf 5500: prio 0 quantum 65536 rate 5Mbit > > ceil 5Mbit burst 20Kb/8 mpu 0b cburst 8151b/8 mpu 0b level 0 > > Sent 45107618 bytes 42138 pkts (dropped 0, overlimits 0) > > rate 608617bps 548pps backlog 40p > > lended: 42098 borrowed: 0 giants: 0 > > tokens: 3908 ctokens: -11502 > > > > but I see only 330Kbytes/sec flow (half of 5Mbit rate) > > >From above I see rate 608617bps = 4.7MBit. Probably it will settle down > after some while. I suspect there is problem in your way of measuring the > rate. Also you can deliberately increase (c)burst to more than default, > say to 20kB - the larger the burst it the more insensitive to CPU load > it is ... OK, I removed all manual settings of burst/cburst, and it works just fine. htb3 rocks! 30%/90% CPU Usage on 80Mbit stream with >500 classes on htb3/htb2 (P4 2Ghz, 2.4.25 kernel with APIC, e1000 NIC) -- Michael Vasilenko From al@xms.co.za Wed Apr 7 14:01:40 2004 From: al@xms.co.za (Andrew Lewis) Date: 07 Apr 2004 15:01:40 +0200 Subject: [LARTC] In/Out Message-ID: <1081342900.9021.66.camel@al.xms.co.za> --=-z7c156nwNFDAW+qp3iWt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello again all, Question: I have a number of users, who need to be shaped at different rates. My question is this: Is there a way that I can shape both *inbound* and *outbound* traffic to not exceed a single threshold, ie. they can get x kbps traffic in or x kbps out, but no more than x kbps in/out combined? Best Regards, -AL. --=-z7c156nwNFDAW+qp3iWt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBAc/uzMx/c6W7kksgRAl21AJ4n1djeqgyWJ+NQ2igL9q0IJ7Yn0QCgr6em KLuszECfxBGDedzZ/sJMZSo= =mFYV -----END PGP SIGNATURE----- --=-z7c156nwNFDAW+qp3iWt-- From al@xms.co.za Wed Apr 7 14:38:44 2004 From: al@xms.co.za (Andrew Lewis) Date: 07 Apr 2004 15:38:44 +0200 Subject: [LARTC] Selectively filtering traffic in/out to common threshold Message-ID: <1081345124.9021.70.camel@al.xms.co.za> --=-3BX7W/ErJsophm+YPHLE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello again all, Question: I have a number of users, who need to be shaped at different rates. My question is this: Is there a way that I can shape both *inbound* and *outbound* traffic to not exceed a single threshold, ie. they can get x kbps traffic in or x kbps out, but no more than x kbps in/out combined? Best Regards, -AL. --=-3BX7W/ErJsophm+YPHLE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBAdARkMx/c6W7kksgRAhX1AKColpTfOTlKxaU2QyV52j/mIEBavwCdG8tM PIGC7DW5sqg2F6dnUYss4d0= =CCZn -----END PGP SIGNATURE----- --=-3BX7W/ErJsophm+YPHLE-- From ibrahim_cherri@hotmail.com Wed Apr 7 15:12:38 2004 From: ibrahim_cherri@hotmail.com (Ibrahim Cherri) Date: Wed, 07 Apr 2004 16:12:38 +0200 Subject: [LARTC] (no subject) Message-ID: Hello I was testing HTB using IPerf TCP traffic and the results were very good. Until I tried to add some UDP traffic the results were a little strange. this is my setup tc qdisc del dev eth1 root tc qdisc add dev eth1 handle 1:0 root htb default 2 tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1mbit tc class add dev eth1 parent 1:1 classid 1:2 htb rate 500kbit ceil 1mbit tc class add dev eth1 parent 1:1 classid 1:3 htb rate 500kbit ceil 1mbit tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip protocol 17 0xff flowid 1:3 tc qdisc add dev eth1 parent 1:2 handle 20 pfifo limit 10 tc qdisc add dev eth1 parent 1:3 handle 30 pfifo limit 10 This simple setup should split the 1mbit bandwidth between TCP and UDP. I run 2 IPerf clients simultaneously Server: iperf -s -p 200 iperf -s -p 400 -u Client: iperf -c $ServerIP -p 200 iperf -c $ServerIP -p 400 -u then UDP traffic takes about 750kbit and TCP traffic takes about 250kbit Can anyone tell me why is that? thanx, Ibrahim _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From stillnick2@terra.com.br Wed Apr 7 18:36:45 2004 From: stillnick2@terra.com.br (Cristiano Soares) Date: Wed, 7 Apr 2004 14:36:45 -0300 Subject: [LARTC] setup fail-over with redhat9... Message-ID: <003501c41cc6$e604c0b0$6400a8c0@stillnicks> This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C41CAD.C0582AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. Im now decribeing my problem very clearly to see if anyone could = help me.=20 I have 3 (three) nics in my system. 1 is for my internet network - (eth1) 2 are for my 2 adsl lines that i use to connect to the internet = (eth2 is my "master" adsl line) and (eth0 is my "slave" adsl line). I know that to make redundance work ill have to setup the ip route and = ip rule in my system. To do that, i found a bash script called "NETSANE = - http://muse.linuxmafia.org/netsane/". I have to change somethings like = interface of the first and second lines in netsane.conf. So, i did all = the changes needed. Looking good so far, i can ping outside sites the = both eth2 and eth0 doing "ping -I eth# www.kernel.org", i dont have a = "default route" and etc. Ok, now goes the worse part. I cant MASQUERADE the connection to my = internal network, and even if i could, will redundance work if the first = interface fails? I dont think so. Because i tried a normal ping (ping = www.kernel.org) and it always goes through eth2, even the i unplug the = adsl line from the router/modem to simulate a down link. I believe that should be an IPTABLES configuration to make NAT work with = redundance, not the usual below: #!/bin/sh IPTABLES=3D/sbin/iptables #All The lines below are NAT routing # flush any old rules $IPTABLES -F -t nat # turn on NAT (IP masquerading for outgoing packets) $IPTABLES -A POSTROUTING -t nat -o eth0 -j MASQUERADE # enable IP forwarding (of incoming packets) echo 1 > /proc/sys/net/ipv4/ip_forward Im using the rc.firewall-2.4 right now, and it clearly doesnt work with = redundance. Here is my network. LAN =20 _/\__/\_ = +---+----+ = _/\___/\_ / \ (eth2) - 192.168.1.200 (GTW-192.168.1.1) = | | (eth0) - 192.168.0.200 (GTW-192.168.0.254) = / \ ( Router1 )------------------------------------------------+ = Linux box + = ----------------------------------------------------------( Router 2 ) \_ __ _ / = | | = \ _ __ _ = / \/ \/ = +----+---+ = \/ \/=20 = | | = (eth1) - 192.168.2.1 = -------------------- = = | | = | LAN | = |Ex:192.168.2.20 | = | 192.168.2.21... | = ----------------------------- Sites I tried: http://lartc.org/howto/lartc.rpdb.multiple-links.html http://www.ssi.bg/~ja/nano.txt THANKS A LOT ------=_NextPart_000_0032_01C41CAD.C0582AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi. Im now decribeing my problem very clearly to = see if=20 anyone could help me.
 
I have 3 (three) nics in my system.
    1 is for my internet network = -=20 (eth1)
    2 are for my 2 adsl = lines that i=20 use to connect to the internet (eth2 is my "master" adsl line) and (eth0 = is my=20 "slave" adsl line).
 
I know that to make redundance work ill have to = setup the=20 ip route and ip rule in my system. To do that, i found a bash script = called=20 "NETSANE - http://muse.linuxmafia.org/n= etsane/".=20 I have to change somethings like interface of the first and second lines = in=20 netsane.conf. So, i did all the changes needed. Looking good so far, i = can ping=20 outside sites the both eth2 and eth0 doing "ping -I eth# = www.kernel.org", i dont=20 have a "default route" and etc.
Ok, now goes the worse part. I = cant MASQUERADE the=20 connection to my internal network, and even if i could, will redundance = work if=20 the first interface fails? I dont think so. Because i tried a normal = ping (ping=20 www.kernel.org) and it always goes = through=20 eth2, even the i unplug the adsl line from the router/modem to simulate = a down=20 link.
I believe that should be an IPTABLES = configuration to make=20 NAT work with redundance, not the usual below:
 
#!/bin/sh
 
IPTABLES=3D/sbin/iptables
 
#All The lines below are NAT = routing
 
# flush any old rules
$IPTABLES -F -t = nat
 
# turn on NAT (IP masquerading for outgoing=20 packets)
$IPTABLES -A POSTROUTING -t nat -o eth0 -j = MASQUERADE
 
# enable IP forwarding (of incoming = packets)
echo 1=20 > /proc/sys/net/ipv4/ip_forward
 
 
Im using the rc.firewall-2.4 right now, and it = clearly=20 doesnt work with redundance.
Here is my network.
 
       =20 LAN
           =             &= nbsp;      
    &nbs= p;   =20 _/\__/\_           = ;=20             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    =20 +---+----+          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;          _/\___/\_<= BR>       =20 /            = =20 \       (eth2) - 192.168.1.200=20 (GTW-192.168.1.1)    |     &= nbsp;   =20 |     (eth0) - 192.168.0.200=20 (GTW-192.168.0.254)         =          / =20            =20 \
       ( Router1 =20 )------------------------------------------------+ Linux=20 box +   =20 ----------------------------------------------------------( Router=20 2 )
        \_  __  = _ =20 /            =             &= nbsp;           &n= bsp;           &nb= sp;   =20             &= nbsp;           &n= bsp;=20 |         |   = ;            =   =20             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      \=20 _  __  _  /
        =     \/ =20  \/           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        =20 +----+---+          =20             =    =20             =    =20             =    =20        =20             &= nbsp;           &n= bsp;    \/     \/ 
&= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     =20 |        |
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         =20 (eth1) - 192.168.2.1
           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;      =20    =20 --------------------         = ;            =          
  &nb= sp;=20             =    =20             =    =20             =    =20             =    =20             =    =20            =20 |            =             &= nbsp;  =20 |
       =20             =    =20             =    =20             =    =20             =    =20             =    =20         |    =   LAN=20             &= nbsp; =20 |
       =20             =    =20             =    =20             =    =20             =    =20             =    =20         |Ex:192.168.2.20    = |
       =20             =    =20             =    =20             =    =20             =    =20             =    =20         |  192.168.2.21... =   =20 |
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;-----------------------------
 
Sites I tried: http://lar= tc.org/howto/lartc.rpdb.multiple-links.html
http://www.ssi.bg/~ja/nano.txt
 
THANKS A=20 LOT
------=_NextPart_000_0032_01C41CAD.C0582AA0-- From lartc@24x7linux.com Wed Apr 7 20:24:27 2004 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Wed, 7 Apr 2004 21:24:27 +0200 Subject: [LARTC] medir trafico In-Reply-To: References: Message-ID: <20040407192427.GA7640@localhost> On Tuesday, 06 April 2004, at 15:59:55 -0300, ThE LinuX_KiD wrote: > hola listeros! > I don't know if you have following the list for long, but it "seems" this list is "written" in English, so you should use English too. Please take into account that it is better to address the widest possible audience in the hope someone will help you. Maybe there is no Linux routing and traffic control spanish-written list available, but I am sure you could contact any spanish-written newsgroup to ask for some help, if you can't or don't want to write in english. Greetings. No sé si has venido siguiendo la lista durante mucho tiempo, pero según "parece" en la lista se escribe en inglés, de manera que tú también deberías usar el inglés. Por favor, ten en cuenta que es mejor dirigirse a la mayor audiencia posible en la esperanza de que alguien te ayude. Quizás no exista una lista en castellano específica para el encaminamiento y control de ancho de banda en Linux, pero estoy seguro de que podrás contactar con cualquier grupo de noticias en castellano para solicitar ayuda, si es que no sabes o no quieres escribir en inglés. Saludos. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) From reed_zhou@yahoo.com Wed Apr 7 23:06:41 2004 From: reed_zhou@yahoo.com (Reed Zhou) Date: Wed, 7 Apr 2004 15:06:41 -0700 (PDT) Subject: [LARTC] tc command failed on 2.4.21 kernel Message-ID: <20040407220641.57058.qmail@web13207.mail.yahoo.com> --0-283961851-1081375601=:56890 Content-Type: text/plain; charset=us-ascii Hi, Will TC work on 2.4.21 kernel without any patches? If it does, why tc command failed? For example, # tc qdisc show dev eth0 RTNETLINK answers: Invalid argument Dump terminated Thank you for your help! Reed --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-283961851-1081375601=:56890 Content-Type: text/html; charset=us-ascii
Hi,
 
Will TC work on 2.4.21 kernel without any patches? If it does, why tc command failed?
 
For example,
 
# tc qdisc show dev eth0
RTNETLINK answers: Invalid argument
Dump terminated
 
Thank you for your help!
 
Reed

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-283961851-1081375601=:56890-- From roy@xxx.lt Thu Apr 8 00:02:26 2004 From: roy@xxx.lt (Roy) Date: Thu, 8 Apr 2004 02:02:26 +0300 Subject: [LARTC] (no subject) References: Message-ID: <001201c41cf4$6542a180$030aa8c0@t> Udp forwarding mostly cannnot be controled. you can drop udp packets but server will not stop sending then to you anyway. (of course this depends on server software) tcp can be controled so do not have this problem ----- Original Message ----- From: "Ibrahim Cherri" To: Sent: Wednesday, April 07, 2004 5:12 PM Subject: [LARTC] (no subject) > Hello > > I was testing HTB using IPerf TCP traffic and the results were very good. > Until I tried to add some UDP traffic the results were a little strange. > this is my setup > > tc qdisc del dev eth1 root > tc qdisc add dev eth1 handle 1:0 root htb default 2 > > tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1mbit > tc class add dev eth1 parent 1:1 classid 1:2 htb rate 500kbit ceil 1mbit > tc class add dev eth1 parent 1:1 classid 1:3 htb rate 500kbit ceil 1mbit > > tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip protocol > 17 0xff flowid 1:3 > > tc qdisc add dev eth1 parent 1:2 handle 20 pfifo limit 10 > tc qdisc add dev eth1 parent 1:3 handle 30 pfifo limit 10 > > This simple setup should split the 1mbit bandwidth between TCP and UDP. > I run 2 IPerf clients simultaneously > Server: > iperf -s -p 200 > iperf -s -p 400 -u > Client: > iperf -c $ServerIP -p 200 > iperf -c $ServerIP -p 400 -u > > then UDP traffic takes about 750kbit and TCP traffic takes about 250kbit > Can anyone tell me why is that? > > thanx, > Ibrahim > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From roy@xxx.lt Thu Apr 8 00:11:17 2004 From: roy@xxx.lt (Roy) Date: Thu, 8 Apr 2004 02:11:17 +0300 Subject: [LARTC] cant get FAIL-OVER to work... References: <003701c41c51$c33d26f0$6400a8c0@stillnicks> Message-ID: <002001c41cf5$a1dd0bc0$030aa8c0@t> This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C41D0E.C6B588F0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable I dont know any complete failower sript suitable for all situations I was making one , but since my setup became to complex it is not = possible to reconfigure everything so easily. if you need only what you said then it should be possible to use this = scrip for you. ----- Original Message -----=20 From: Cristiano Soares=20 To: lartc@mailman.ds9a.nl=20 Sent: Wednesday, April 07, 2004 6:38 AM Subject: [LARTC] cant get FAIL-OVER to work... Hi all. Im having a problem that is driving me crazy. I cant get link = fail-over to work in my RedHat9 Linux. I have two ADSL lines exactly the = same speed, and im doing NAT with the linux box. Whenever the first line = (eth2 in my case) goes down, i run a bash script that i made to change = the default route to the backup line (eth0). eth1 is my internal = network. I want to be able to make the linux box do that for me. I = already tried many load balancing sites, but still cant figure it out. I = just gave up today, and i want to know if any good soul would help me to = make it work by getting into my Redhat box using SSH. Thanks a lot = everyone. My ICQ is: 3794264 My MSN is: about:unsupported-mailto:stillnick@msn.com Cristiano Soares ------=_NextPart_000_001D_01C41D0E.C6B588F0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
I dont know any complete failower sript = suitable=20 for all situations
I was making one , but since my setup = became to=20 complex it is not possible to reconfigure everything so = easily.
 
if you need only what you said then it = should be=20 possible to use this scrip for you.
 
----- Original Message -----
From:=20 Cristiano Soares
Sent: Wednesday, April 07, 2004 = 6:38=20 AM
Subject: [LARTC] cant get = FAIL-OVER to=20 work...

Hi all. Im having a problem that = is driving me=20 crazy. I cant get link fail-over to work in my RedHat9 Linux. I have = two ADSL=20 lines exactly the same speed, and im doing NAT with the linux box. = Whenever=20 the first line (eth2 in my case) goes down, i run a bash script = that i=20 made to change the default route to the backup line (eth0). eth1 is my = internal network. I want to be able to make the linux box do that for = me. I=20 already tried many load balancing sites, but still cant figure it = out. I=20 just gave up today, and i want to know if any good soul would help me = to make=20 it work by getting into my Redhat box using SSH. Thanks a lot=20 everyone.
 
My ICQ is: 3794264
My MSN is:=20 about:unsupported-mailto:stillnick@msn.com
 
Cristiano Soares
 
= ------=_NextPart_000_001D_01C41D0E.C6B588F0-- From roy@xxx.lt Wed Apr 7 23:58:45 2004 From: roy@xxx.lt (Roy) Date: Thu, 8 Apr 2004 01:58:45 +0300 Subject: [LARTC] Selectively filtering traffic in/out to common threshold References: <1081345124.9021.70.camel@al.xms.co.za> Message-ID: <000c01c41cf3$e1ef3f00$030aa8c0@t> First WRITE IN PLAIN TEXT now your problem: This can be done easily with my imq version, http://pupa.da.ru/imq seems there is no other way I was trying to use policers but this worked realy bad. ----------------------------------- Question: I have a number of users, who need to be shaped at different rates. My question is this: Is there a way that I can shape both *inbound* and *outbound* traffic to not exceed a single threshold, ie. they can get x kbps traffic in or x kbps out, but no more than x kbps in/out combined? Best Regards, -AL. From jailbreaker@data.bg Thu Apr 8 01:25:00 2004 From: jailbreaker@data.bg (Teodor Yantchev) Date: Thu, 8 Apr 2004 03:25:00 +0300 Subject: [LARTC] Squid + shaping question Message-ID: <20040408003240.77A644456@outpost.ds9a.nl> Hi folks, So, I have a pretty simple setup - a linux router machine running as a firewall/router for a small neighborhood LAN (approx 20 machines). I also have squid running on the box in non-transparent mode, and also I have set up NAT for TCP/UDP ports above 1024 for all clients and SSH/POP/SMTP/CVS NAT'd for selected ones based on MAC filtering. No hosts whatsoever can access ports 80 and 443 without going through squid. The uplink to the internet is 512kbit/s downstream and 64kbit/s upstream cable modem connected on eth1 (LAN on eth0, no DMZ). When the LAN started to grow from a few well known friends of mine to more people I didn't know so well 'social shaping' stopped working for us - bulk downloaders started to saturate the link so badly that I even couldn't use acceptably ssh from outside. So - the usual solution - www.lartc.org. I did a lot of reading on the topic (This really got me interested in) and finally ended up installing a self-modified version of wondershaper on the external interface. This did solve the problem of me having usable ssh from my office to the router machine, and the ingress qdisc partially solved the problem of the downlink being fairly distributed between all incoming connections - but as most of you know this is a half-baked bread. What I think should be done is shaping the internal interface - BUT - the squid in-between causes trouble. So the question is - How to differentiate between traffic served from squid's cache and traffic squid got directly from the internet ? Shaping/policing all web traffic negates the benefits of having a caching proxy pretty much. After lots of googling and reading(at one point I was ready to completely forget squid) a came up with the following alternatives, both found on the FAQ section of www.docum.org - 'SQUID zero penalty for HIT traffic patch' by a fellow bulgarian Marin Stavrev, and a patch giving you the ability to 'use ACL lists to put packets in classes' by a guy named Patrick. I'd like to ask you for your experiences with those, which one is better, any other alternatives you know of and of course general recipes/recommendations for solving my problem. Well, That's it put shortly in an over-sized mail. Thanks in advance for your advice. Regards, Teddy From damion@snapgear.com Thu Apr 8 07:58:23 2004 From: damion@snapgear.com (Damion de Soto) Date: Thu, 08 Apr 2004 16:58:23 +1000 Subject: [LARTC] setup fail-over with redhat9... In-Reply-To: <003501c41cc6$e604c0b0$6400a8c0@stillnicks> References: <003501c41cc6$e604c0b0$6400a8c0@stillnicks> Message-ID: <4074F80F.1020302@snapgear.com> Hi Cristiano, > I know that to make redundance work ill have to setup the ip route and > ip rule in my system. To do that, i found a bash script called "NETSANE > - http://muse.linuxmafia.org/netsane/". I have to change somethings like > interface of the first and second lines in netsane.conf. So, i did all > the changes needed. Looking good so far, i can ping outside sites the > both eth2 and eth0 doing "ping -I eth# www.kernel.org", i dont have a > "default route" and etc. ok, that's good. > Ok, now goes the worse part. I cant MASQUERADE the connection to my > internal network, and even if i could, will redundance work if the first > interface fails? I dont think so. No, as the netsane webpage says, it does not provide redundancy. > Because i tried a normal ping (ping > www.kernel.org ) and it always goes through eth2, > even the i unplug the adsl line from the router/modem to simulate a down > link. Yes, your packet routes get cached by the kernel. Eventually, it will realise that route is dead, and has a 50% chance of getting out the other active interface. > I believe that should be an IPTABLES configuration to make NAT work with > redundance, not the usual below: > # turn on NAT (IP masquerading for outgoing packets) > $IPTABLES -A POSTROUTING -t nat -o eth0 -j MASQUERADE #you will want to masquerade out eth2 as well. $IPTABLES -A POSTROUTING -t nat -o eth2 -j MASQUERADE > Im using the rc.firewall-2.4 right now, and it clearly doesnt work with > redundance. As far as I know, the only way you can get fail-over/redundancy, is to have a program continually monitor both links, and bring up/down the interfaces and change the routes as required. You should be able to write a shell script that pings out eth2, and if it doesn't get a reply, brings down that interface and fixes the routes. Then, wait, try again later and see if eth2 is working again. Regards, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- From ttdow@hotmail.com Thu Apr 8 13:09:33 2004 From: ttdow@hotmail.com (TT TT) Date: Thu, 08 Apr 2004 05:09:33 -0700 Subject: [LARTC] How to DSMARK locally generated traffic and then apply AFHTB? Message-ID: Hi fellow traffic-shapers, I am implementing a Diffserv CORE router using Linux kernel 2.4.18. I used this excellent website (http://www.opalsoft.net/qos/DS-38.htm) using AFHTB as a starting basis for my EGRESS diffserv implementation - and all works great so far!!! But my project has an additional requirement. There are services running locally on the router which are sending/receiving IP traffic also. These services are leaving the DSCP set to 0x00. What I want to do is to mark these packets with a specific DSCP value and then treat them as if they came in from the INGRESS and apply the AFHTB QoS mechanism.... How I can I do this? To restate the scenario: - I am a CORE diffserv router. - I am using the AFHTB script on my EGRESS - Traffic from LAN has DSCP set, all works great using the AFHTB script! - Traffic generated within the router has no DSCP set, but I want to set the DSCP values (based on a u32 filter) and THEN treat the packets just like the packets coming in from the LAN. - The problem is that the AFHTB script assumes the DSCP values are already set, but for locally generated traffic they are not. - As DSMARK is my root queue, I know I can "mark" the DSCP code just before handing the packet over to the egress interface using commands like ""tc class change dev eth1 classid 1:1 dsmark mask 0x3 value 0xb8"". But this marking is being done AFTER the AFHTB has done all its work, and I want to mark the DSCP values BEFORE applying the AFHTB QoS. Any suggestions/ideas/resources are truly appreciated! Scratching my head, -Tony _________________________________________________________________ Persistent heartburn? Check out Digestive Health & Wellness for information and advice. http://gerd.msn.com/default.asp From discussions@lagraphico.com Thu Apr 8 14:53:27 2004 From: discussions@lagraphico.com (Discussion Lists) Date: Thu, 8 Apr 2004 06:53:27 -0700 Subject: [LARTC] First Post: Question on Ip Aliasing Message-ID: Hi All, I did a google search on this and didn't find exactly what I was looking for. Suppose I have a machine that has an IP alias eth0:0. I have set up HTB.init so that it properly throttles bandwidth on eth0, however when I use eth0:0, it doesn't work. I read elsewhere that it should work at the PHYSICAL device layer, and should therefore work for both at once. This is not happening though. Just wanted to find out if TC/iproute2/HTB will behave like that: Meaning, are they supposed to throttle bandwidth for the physical, AND the alias at the same time, or do I need a separate rule? Thanks in advance! P.S. I tried setting up eth0:0 as a config file in the HTB dir, and htb.init didn't like that at all. I wonder if TC would react the same way? From lartc@24x7linux.com Thu Apr 8 16:12:21 2004 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Thu, 8 Apr 2004 17:12:21 +0200 Subject: [LARTC] First Post: Question on Ip Aliasing In-Reply-To: References: Message-ID: <20040408151221.GA2450@localhost> On Thursday, 08 April 2004, at 06:53:27 -0700, Discussion Lists wrote: > I did a google search on this and didn't find exactly what I was looking > for. Suppose I have a machine that has an IP alias eth0:0. I have set > up HTB.init so that it properly throttles bandwidth on eth0, however > when I use eth0:0, it doesn't work. I read elsewhere that it should > work at the PHYSICAL device layer, and should therefore work for both at > once. This is not happening though. Just wanted to find out if > I think that the "hack" of "alias interfaces" in Linux has been one major source of conceptual problems with respect to Linux routing and the like in past years :-). I have always believed that it is much better to think of IP addresses in Linux as assigned to physical interfaces rather than associated to some kind of a virtual one. The "ip address show" command shows very clearly this fact. Each interface has zero or more IP addresses assigned to it, and with "ip" you will never see "alias interfaces" again, because this tool is modern enough to understand the fact. I encourage everyone to make the move to "ip" from old "ifconfig" and related tools as soon as possible. In the "ip" world you just have physical (or not so physical, like bond? or VLAN interfaces) interfaces and IP assigned to them. And when you want to refer to IP addresses, you just use them. And when you want to refer to interfaces, use the one you need. Also, have a look at the Stef Coene's excellent KPTD at: http://www.docum.org/stef.coene/qos/kptd/ Couple the above diagram with the previous explanation about IP and interfaces and maybe all will now be simpler to you. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) From stillnick2@terra.com.br Thu Apr 8 17:54:23 2004 From: stillnick2@terra.com.br (Cristiano Soares) Date: Thu, 8 Apr 2004 13:54:23 -0300 Subject: [LARTC] traffic shaping on single ip... Message-ID: <008d01c41d8a$26d19be0$a902a8c0@stillnicks> This is a multi-part message in MIME format. ------=_NextPart_000_008A_01C41D70.FF8B04E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. Im using the following CQB shaper to shape IP addresses: DEV=3Deth1 (internal eth) tc qdisc del dev $DEV root tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit tc class add dev $DEV parent 1: classid 1:1 cbq rate 256kbit allot 1500 = prio 5 bounded isolated tc class add dev $DEV parent 1: classid 1:2 cbq rate 512kbit allot 1500 = prio 5 bounded isolated tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst = 192.168.2.230 flowid 1:2 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src = 192.168.2.230 flowid 1:2 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst = 192.168.2.188 flowid 1:1 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src = 192.168.2.188 flowid 1:1 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst = 192.168.2.172 flowid 1:1 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src = 192.168.2.172 flowid 1:1 The thing is, i want to be able to shape inbound different from outbound = traffic. I use an ADSL line so, i need to shape up significantly lower = than down. Thanks a lot. And also, is there a better way to shape traffic like this? Thanks a = lot. Cristiano ------=_NextPart_000_008A_01C41D70.FF8B04E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all. Im using the following CQB = shaper to shape=20 IP addresses:
 
DEV=3Deth1 (internal eth)
 
tc qdisc del dev $DEV root
tc qdisc = add dev $DEV=20 root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev $DEV parent 1: classid = 1:1 cbq=20 rate 256kbit allot 1500 prio 5 bounded isolated
tc class add dev $DEV = parent=20 1: classid 1:2 cbq rate 512kbit allot 1500 prio 5 bounded = isolated
 
tc filter add dev $DEV parent 1: = protocol ip prio=20 16 u32 match ip dst 192.168.2.230 flowid 1:2
tc filter add dev $DEV = parent 1:=20 protocol ip prio 16 u32 match ip src 192.168.2.230 flowid = 1:2
 
tc filter add dev $DEV parent 1: = protocol ip prio=20 16 u32 match ip dst 192.168.2.188 flowid 1:1
tc filter add dev $DEV = parent 1:=20 protocol ip prio 16 u32 match ip src 192.168.2.188 flowid = 1:1
 
tc filter add dev $DEV parent 1: = protocol ip prio=20 16 u32 match ip dst 192.168.2.172 flowid 1:1
tc filter add dev $DEV = parent 1:=20 protocol ip prio 16 u32 match ip src 192.168.2.172 flowid = 1:1
 
The thing is, i want to be able to = shape inbound=20 different from outbound traffic. I use an ADSL line so, i need to shape = up=20 significantly lower than down. Thanks a lot.
And also, is there a better way to = shape traffic=20 like this? Thanks a lot.
 
Cristiano
------=_NextPart_000_008A_01C41D70.FF8B04E0-- From etg@setcom.bg Thu Apr 8 18:38:04 2004 From: etg@setcom.bg (Evgeni Gechev) Date: Thu, 08 Apr 2004 20:38:04 +0300 Subject: [LARTC] Squid + shaping question In-Reply-To: <20040408003240.77A644456@outpost.ds9a.nl> References: <20040408003240.77A644456@outpost.ds9a.nl> Message-ID: <40758DFC.3080107@setcom.bg> Short: you need zph patch. Detailed: you could use both, if you need. They just do different jobs. With the first patch you could control outgoing connections, i.e. communication between squid and web servers/peers. With the second patch (zph), you could control communication between squid and clients, and as I understand, this is what you are interested in. Teodor Yantchev wrote: >Hi folks, > >So, I have a pretty simple setup - a linux router machine running as a >firewall/router for a small neighborhood LAN (approx 20 machines). I also >have squid running on the box in non-transparent mode, and also I have set >up NAT for TCP/UDP ports above 1024 for all clients and SSH/POP/SMTP/CVS >NAT'd for selected ones based on MAC filtering. No hosts whatsoever can >access ports 80 and 443 without going through squid. The uplink to the >internet is 512kbit/s downstream and 64kbit/s upstream cable modem connected >on eth1 (LAN on eth0, no DMZ). >When the LAN started to grow from a few well known friends of mine to more >people I didn't know so well 'social shaping' stopped working for us - bulk >downloaders started to saturate the link so badly that I even couldn't use >acceptably ssh from outside. So - the usual solution - www.lartc.org. >I did a lot of reading on the topic (This really got me interested in) and >finally ended up installing a self-modified version of wondershaper on the >external interface. This did solve the problem of me having usable ssh from >my office to the router machine, and the ingress qdisc partially solved the >problem of the downlink being fairly distributed between all incoming >connections - but as most of you know this is a half-baked bread. What I >think should be done is shaping the internal interface - BUT - the squid >in-between causes trouble. >So the question is - How to differentiate between traffic served from >squid's cache and traffic squid got directly from the internet ? >Shaping/policing all web traffic negates the benefits of having a caching >proxy pretty much. >After lots of googling and reading(at one point I was ready to completely >forget squid) a came up with the following alternatives, both found on the >FAQ section of www.docum.org - 'SQUID zero penalty for HIT traffic patch' by >a fellow bulgarian Marin Stavrev, and a patch giving you the ability to 'use >ACL lists to put packets in classes' by a guy named Patrick. >I'd like to ask you for your experiences with those, which one is better, >any other alternatives you know of and of course general >recipes/recommendations for solving my problem. > >Well, That's it put shortly in an over-sized mail. Thanks in advance for >your advice. > >Regards, >Teddy > > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > From radolin@del.bg Thu Apr 8 21:11:14 2004 From: radolin@del.bg (Radoslav Kolev) Date: Thu, 08 Apr 2004 23:11:14 +0300 Subject: [LARTC] Squid + shaping question In-Reply-To: <20040408003240.77A644456@outpost.ds9a.nl> References: <20040408003240.77A644456@outpost.ds9a.nl> Message-ID: <4075B1E2.7040403@del.bg> Hi, Teodor! Integrating squid with traffic control has been a big problem for all of us. Besides the options listed at the docum.org faq, there's a patch at http://sed.pl/~mrk/qos/, which is very similar to ZPH, unfortunately the page is available only in Polish, so it didn't become very popular. You can just download the patch and figure out how to use it. There's also the wipl/wrr proxy remap package at http://wipl-wrr.sourceforge.net/proxyremap.html As a last resort, if you have a small number of clients (<256) you can put IP aliases on the outer intefrace of the Squid machine, then use acl to select different source IP for each client machine. To me the ZPH + Patrick McHardy's acl classify patch combination seems the best solutions available now, but I don't have any experience to share. It would be interesting to hear from someone using it. Greetings, RAdo From discussions@lagraphico.com Thu Apr 8 21:59:45 2004 From: discussions@lagraphico.com (Discussion Lists) Date: Thu, 8 Apr 2004 13:59:45 -0700 Subject: [LARTC] First Post: Question on Ip Aliasing Message-ID: Thank you for your response. You confirmed what I understood to be how it works, but for some reason it isn't working like that, and I can't understand why. The alias gets assigned through heartbeat, during a failover, but traffic routes through that alias as if there was no shaping going on at all. In other words it just isn't working the way that it should be working. I am not even sure where to look for problems or errors. I don't see how my configuration can be wrong because it is shaping traffic just fine on the physical adapter . .. If anyone can think of other suggestions, I would greatly appreciate it. Thanks! > -----Original Message----- > From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com]=20 > Sent: Thursday, April 08, 2004 8:12 AM > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] First Post: Question on Ip Aliasing >=20 > On Thursday, 08 April 2004, at 06:53:27 -0700, Discussion Lists wrote: >=20 > > I did a google search on this and didn't find exactly what I was=20 > > looking for. Suppose I have a machine that has an IP alias=20 > eth0:0. I=20 > > have set up HTB.init so that it properly throttles=20 > bandwidth on eth0,=20 > > however when I use eth0:0, it doesn't work. I read=20 > elsewhere that it=20 > > should work at the PHYSICAL device layer, and should therefore work=20 > > for both at once. This is not happening though. Just=20 > wanted to find=20 > > out if > > > I think that the "hack" of "alias interfaces" in Linux has=20 > been one major source of conceptual problems with respect to=20 > Linux routing and the like in past years :-). I have always=20 > believed that it is much better to think of IP addresses in=20 > Linux as assigned to physical interfaces rather than=20 > associated to some kind of a virtual one. >=20 > The "ip address show" command shows very clearly this fact.=20 > Each interface has zero or more IP addresses assigned to it,=20 > and with "ip" > you will never see "alias interfaces" again, because this=20 > tool is modern enough to understand the fact. I encourage=20 > everyone to make the move to "ip" from old "ifconfig" and=20 > related tools as soon as possible. >=20 > In the "ip" world you just have physical (or not so physical,=20 > like bond? > or VLAN interfaces) interfaces and IP assigned to them. And=20 > when you want to refer to IP addresses, you just use them.=20 > And when you want to refer to interfaces, use the one you need. >=20 > Also, have a look at the Stef Coene's excellent KPTD at: > http://www.docum.org/stef.coene/qos/kptd/ >=20 > Couple the above diagram with the previous explanation about=20 > IP and interfaces and maybe all will now be simpler to you. >=20 > Greetings. >=20 > -- > Jose Luis Domingo Lopez > Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl=20 > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >=20 From dchemko@smgtec.com Thu Apr 8 23:48:17 2004 From: dchemko@smgtec.com (Daniel Chemko) Date: Thu, 8 Apr 2004 15:48:17 -0700 Subject: [LARTC] First Post: Question on Ip Aliasing Message-ID: <7C9884991ADAE0479C14F10C858BCDF56792C6@alderaan.smgtec.com> Discussion Lists wrote: > Thank you for your response. You confirmed what I understood to be > how it works, but for some reason it isn't working like that, and I > can't understand why. The alias gets assigned through heartbeat, > during a failover, but traffic routes through that alias as if there > was no shaping going on at all. In other words it just isn't working > the way that it should be working. I am not even sure where to look > for problems or errors. I don't see how my configuration can be > wrong because it is shaping traffic just fine on the physical adapter > . .. If anyone can think of other suggestions, I would greatly > appreciate it. =20 Do you run the trafficing script during a failover, or just when you boot the system? Maybe the traffic routing rules get dropped from the system once the interface is down, much the same way that routes do? Just a thought. I haven't bothered to setup traffic rules on my gateways yet. From roy@xxx.lt Fri Apr 9 00:55:13 2004 From: roy@xxx.lt (Roy) Date: Fri, 9 Apr 2004 02:55:13 +0300 Subject: [LARTC] First Post: Question on Ip Aliasing References: Message-ID: <002101c41dc4$f43201d0$030aa8c0@t> nothing can go out through alias inetrface, alias is for input only. so everything is going through physical interface like eth0 if you are forwarding packets, then your interface ip is ignored anyway. (it is only used to translate ip to mac) if you want to shape localy generated trafic, then source ip will depend on what the user will chose, since he can use any aliased ip of your server. so simply ignore all virtual interaces imagine that you have none of them, ----- Original Message ----- From: "Discussion Lists" To: Sent: Thursday, April 08, 2004 11:59 PM Subject: RE: [LARTC] First Post: Question on Ip Aliasing Thank you for your response. You confirmed what I understood to be how it works, but for some reason it isn't working like that, and I can't understand why. The alias gets assigned through heartbeat, during a failover, but traffic routes through that alias as if there was no shaping going on at all. In other words it just isn't working the way that it should be working. I am not even sure where to look for problems or errors. I don't see how my configuration can be wrong because it is shaping traffic just fine on the physical adapter . .. If anyone can think of other suggestions, I would greatly appreciate it. Thanks! > -----Original Message----- > From: Jose Luis Domingo Lopez [mailto:lartc@24x7linux.com] > Sent: Thursday, April 08, 2004 8:12 AM > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] First Post: Question on Ip Aliasing > > On Thursday, 08 April 2004, at 06:53:27 -0700, Discussion Lists wrote: > > > I did a google search on this and didn't find exactly what I was > > looking for. Suppose I have a machine that has an IP alias > eth0:0. I > > have set up HTB.init so that it properly throttles > bandwidth on eth0, > > however when I use eth0:0, it doesn't work. I read > elsewhere that it > > should work at the PHYSICAL device layer, and should therefore work > > for both at once. This is not happening though. Just > wanted to find > > out if > > > I think that the '"'hack'"' of '"'alias interfaces'"' in Linux has > been one major source of conceptual problems with respect to > Linux routing and the like in past years :-). I have always > believed that it is much better to think of IP addresses in > Linux as assigned to physical interfaces rather than > associated to some kind of a virtual one. > > The '"'ip address show'"' command shows very clearly this fact. > Each interface has zero or more IP addresses assigned to it, > and with '"'ip'"' > you will never see '"'alias interfaces'"' again, because this > tool is modern enough to understand the fact. I encourage > everyone to make the move to '"'ip'"' from old '"'ifconfig'"' and > related tools as soon as possible. > > In the '"'ip'"' world you just have physical (or not so physical, > like bond? > or VLAN interfaces) interfaces and IP assigned to them. And > when you want to refer to IP addresses, you just use them. > And when you want to refer to interfaces, use the one you need. > > Also, have a look at the Stef Coene's excellent KPTD at: > http://www.docum.org/stef.coene/qos/kptd/ > > Couple the above diagram with the previous explanation about > IP and interfaces and maybe all will now be simpler to you. > > Greetings. > > -- > Jose Luis Domingo Lopez > Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) > _______________________________________________ > 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 roy@xxx.lt Fri Apr 9 01:00:14 2004 From: roy@xxx.lt (Roy) Date: Fri, 9 Apr 2004 03:00:14 +0300 Subject: [LARTC] traffic shaping on single ip... References: <008d01c41d8a$26d19be0$a902a8c0@stillnicks> Message-ID: <003001c41dc5$a2749a50$030aa8c0@t> This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C41DDE.C7816DF0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable You cant control input traffic that way at all. you need to use imq for inbound traffic control, or at least policers. also cbq is very old and should be replaced with htb ----- Original Message -----=20 From: Cristiano Soares=20 To: LARTC@mailman.ds9a.nl=20 Sent: Thursday, April 08, 2004 7:54 PM Subject: [LARTC] traffic shaping on single ip... Hi all. Im using the following CQB shaper to shape IP addresses: DEV=3Deth1 (internal eth) tc qdisc del dev $DEV root tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit tc class add dev $DEV parent 1: classid 1:1 cbq rate 256kbit allot = 1500 prio 5 bounded isolated tc class add dev $DEV parent 1: classid 1:2 cbq rate 512kbit allot = 1500 prio 5 bounded isolated tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst = 192.168.2.230 flowid 1:2 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src = 192.168.2.230 flowid 1:2 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst = 192.168.2.188 flowid 1:1 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src = 192.168.2.188 flowid 1:1 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst = 192.168.2.172 flowid 1:1 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src = 192.168.2.172 flowid 1:1 The thing is, i want to be able to shape inbound different from = outbound traffic. I use an ADSL line so, i need to shape up = significantly lower than down. Thanks a lot. And also, is there a better way to shape traffic like this? Thanks a = lot. Cristiano ------=_NextPart_000_002D_01C41DDE.C7816DF0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
You cant control input traffic that way = at=20 all.
 
you need to use imq for inbound traffic = control, or=20 at least policers.
 
also cbq is very old and should be = replaced with=20 htb
 
----- Original Message -----
From:=20 Cristiano Soares
Sent: Thursday, April 08, 2004 = 7:54=20 PM
Subject: [LARTC] traffic = shaping on=20 single ip...

Hi all. Im using the following CQB = shaper to=20 shape IP addresses:
 
DEV=3Deth1 (internal = eth)
 
tc qdisc del dev $DEV root
tc = qdisc add dev=20 $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev $DEV parent 1: = classid 1:1 cbq=20 rate 256kbit allot 1500 prio 5 bounded isolated
tc class add dev = $DEV=20 parent 1: classid 1:2 cbq rate 512kbit allot 1500 prio 5 bounded=20 isolated
 
tc filter add dev $DEV parent 1: = protocol ip prio=20 16 u32 match ip dst 192.168.2.230 flowid 1:2
tc filter add dev $DEV = parent=20 1: protocol ip prio 16 u32 match ip src 192.168.2.230 flowid = 1:2
 
tc filter add dev $DEV parent 1: = protocol ip prio=20 16 u32 match ip dst 192.168.2.188 flowid 1:1
tc filter add dev $DEV = parent=20 1: protocol ip prio 16 u32 match ip src 192.168.2.188 flowid = 1:1
 
tc filter add dev $DEV parent 1: = protocol ip prio=20 16 u32 match ip dst 192.168.2.172 flowid 1:1
tc filter add dev $DEV = parent=20 1: protocol ip prio 16 u32 match ip src 192.168.2.172 flowid=20 1:1
 
The thing is, i want to be able to = shape inbound=20 different from outbound traffic. I use an ADSL line so, i need to = shape up=20 significantly lower than down. Thanks a lot.
And also, is there a better way to = shape traffic=20 like this? Thanks a lot.
 
Cristiano
------=_NextPart_000_002D_01C41DDE.C7816DF0-- From andy.furniss@dsl.pipex.com Fri Apr 9 13:10:41 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Fri, 09 Apr 2004 13:10:41 +0100 Subject: [LARTC] Squid + shaping question In-Reply-To: <20040408003240.77A644456@outpost.ds9a.nl> References: <20040408003240.77A644456@outpost.ds9a.nl> Message-ID: <407692C1.4010908@dsl.pipex.com> Teodor Yantchev wrote: > Hi folks, > > So, I have a pretty simple setup - a linux router machine running as a > firewall/router for a small neighborhood LAN (approx 20 machines). I also > have squid running on the box in non-transparent mode, and also I have set > up NAT for TCP/UDP ports above 1024 for all clients and SSH/POP/SMTP/CVS > NAT'd for selected ones based on MAC filtering. No hosts whatsoever can > access ports 80 and 443 without going through squid. The uplink to the > internet is 512kbit/s downstream and 64kbit/s upstream cable modem connected > on eth1 (LAN on eth0, no DMZ). > When the LAN started to grow from a few well known friends of mine to more > people I didn't know so well 'social shaping' stopped working for us - bulk > downloaders started to saturate the link so badly that I even couldn't use > acceptably ssh from outside. So - the usual solution - www.lartc.org. > I did a lot of reading on the topic (This really got me interested in) and > finally ended up installing a self-modified version of wondershaper on the > external interface. This did solve the problem of me having usable ssh from > my office to the router machine, and the ingress qdisc partially solved the > problem of the downlink being fairly distributed between all incoming > connections - but as most of you know this is a half-baked bread. What I > think should be done is shaping the internal interface - BUT - the squid > in-between causes trouble. > So the question is - How to differentiate between traffic served from > squid's cache and traffic squid got directly from the internet ? > Shaping/policing all web traffic negates the benefits of having a caching > proxy pretty much. > After lots of googling and reading(at one point I was ready to completely > forget squid) a came up with the following alternatives, both found on the > FAQ section of www.docum.org - 'SQUID zero penalty for HIT traffic patch' by > a fellow bulgarian Marin Stavrev, and a patch giving you the ability to 'use > ACL lists to put packets in classes' by a guy named Patrick. > I'd like to ask you for your experiences with those, which one is better, > any other alternatives you know of and of course general > recipes/recommendations for solving my problem. You could shape on just the internet link using IMQ with the NAT patch to control traffic from the inet to squid. You can already shape up traffic - 64K for 20 machines isn't nice, but you can still do it if interactive traffic is less. Given the other answers - I may be missing something, I've never used squid, but can shape local destined bittorrent OK. Andy. From h_abangar@yahoo.com Fri Apr 9 13:44:01 2004 From: h_abangar@yahoo.com (Hamed Abangar) Date: Fri, 9 Apr 2004 05:44:01 -0700 (PDT) Subject: [LARTC] Bandwidth limiting for each computer in subnet Message-ID: <20040409124401.296.qmail@web11506.mail.yahoo.com> --0-632200798-1081514641=:99178 Content-Type: text/plain; charset=us-ascii Dear members I'm new to this list and also new to tc command. I have a subnet with over 30 pc which have ip addresses from 172.16.1.1/16 range.I want that each computer in my subnet can work with internet with maximum 6k for download and maximum 6k for upload.when i run the following tc commands from my bridge the first pc works well but the second pc can not work with 6k and it has an almost dead connection with internet.I think somethings goes wrong because i want that each computer has 6k bandwith no all computer have 6 bandwith togeather...! can any one help me -------------------------------------------------------------------------------------- tc qdisc del dev eth0 root 2>/dev/null tc qdisc del dev eth1 root 2>/dev/null tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8 tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8 tc class add dev eth0 parent 10:0 classid 10:3 cbq \ allot 1514 cell 8 maxburst 20 avpkt 1000 prio 3 \ bandwidth 48Kbit rate 48Kbit weight 1Kbit bounded tc qdisc add dev eth0 parent 10:3 sfq quantum 48Kbit tc filter dev eth0 parent 10:0 protocol ip prio 1 u32 flowid 10:3 \ match ip src 172.16.1.1/16 ---------------------------------------------------------------------------------------- --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-632200798-1081514641=:99178 Content-Type: text/html; charset=us-ascii
Dear members
 
I'm new to this list and also new to tc command.
I have a subnet with over 30 pc which have ip addresses from 172.16.1.1/16 range.I want that each computer in my subnet can work with internet with maximum 6k for download and maximum 6k for upload.when i run the following tc commands from my bridge the first pc works well but the second pc can not work with 6k and it has an almost dead connection with internet.I think somethings goes wrong because i want that each computer has 6k bandwith no all computer have 6 bandwith togeather...!
can any one help me
--------------------------------------------------------------------------------------
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc del dev eth1 root 2>/dev/null
 
tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8
tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8
 
tc class add dev eth0 parent 10:0 classid 10:3 cbq \
        allot 1514 cell 8 maxburst 20 avpkt 1000 prio 3 \
        bandwidth 48Kbit rate 48Kbit weight 1Kbit bounded

tc qdisc add dev eth0 parent 10:3 sfq quantum 48Kbit

tc filter dev eth0 parent 10:0 protocol ip prio 1 u32 flowid 10:3 \
        match ip src 172.16.1.1/16
----------------------------------------------------------------------------------------

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-632200798-1081514641=:99178-- From paras@bajranet.com.np Fri Apr 9 14:06:16 2004 From: paras@bajranet.com.np (Paras pradhan) Date: Fri, 9 Apr 2004 18:51:16 +0545 (NPT) Subject: [LARTC] controlling uplinks per ip In-Reply-To: <20040409124401.296.qmail@web11506.mail.yahoo.com> References: <20040409124401.296.qmail@web11506.mail.yahoo.com> Message-ID: <55717.202.174.152.73.1081515976.squirrel@mail.bajranet.com.np> hi all, Newibe to tc and cbq.... i have a linux (rh9) machine having one ethernet (eth0-public ip) to internet and second int (eth1) private ip ,to which all my workstation connects. scenario: --|eth0------Linux Server-------eth1|--192.168.2.11 i have used the following commands and my client 192.168.2.11 is limited it's downlink to 96Kbit and it works great. now i want 192.168.2.11 not to upload to outside world crossing 32Kbits. how do i do this?. script that works for only downloads. --- tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate 10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000 tc class add dev eth1 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate 96kbit allot 1514 weight 10kbit prio 6 maxburst 20 avpkt 1000 bounded tc qdisc add dev eth1 parent 10:100 sfq quantum 1514b perturb 15 tc filter add dev eth1 parent 10:0 protocol ip prio 100 u32 match ip dst 192.168.2.11 flowid 10:100 tc -d qdisc --------- Thanks in ADv... Paras. From mario@limonciello.d2g.com Fri Apr 9 17:56:45 2004 From: mario@limonciello.d2g.com (Mario) Date: Fri, 9 Apr 2004 11:56:45 -0500 Subject: [LARTC] Multipath IP Masquerade Message-ID: <20040409165814.CF3573FC9@outpost.ds9a.nl> Previously I attempted load balancing between 3 interfaces with limited bandwidth but a common gateway with much more bandwidth using QoS and teql. This had little to know luck because routes never seemed to come out right. Someone pointed me in the direction of http://www.ssi.bg/~ja/nano.txt to try and set up a multipath route instead. After setting this up it seems that all of the routes are always through eth0 instead of diving up between eth3 and eth1 as well. Could someone give me some direction why this is happening or what I could do to fix it? From stef.coene@docum.org Fri Apr 9 17:46:00 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 9 Apr 2004 18:46:00 +0200 Subject: [LARTC] tc command failed on 2.4.21 kernel In-Reply-To: <20040407220641.57058.qmail@web13207.mail.yahoo.com> References: <20040407220641.57058.qmail@web13207.mail.yahoo.com> Message-ID: <200404091846.00670.stef.coene@docum.org> On Thursday 08 April 2004 00:06, Reed Zhou wrote: > Hi, > > Will TC work on 2.4.21 kernel without any patches? If it does, why tc > command failed? > > For example, > > # tc qdisc show dev eth0 > RTNETLINK answers: Invalid argument > Dump terminated Do you run a kernel with QOS support ? Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From mario@limonciello.d2g.com Fri Apr 9 19:07:47 2004 From: mario@limonciello.d2g.com (Mario) Date: Fri, 9 Apr 2004 13:07:47 -0500 Subject: [LARTC] Re:Multipath Masquerade Message-ID: <20040409180845.9FE6E444F@outpost.ds9a.nl> Don=E2=80=99t mind my previous post =E2=80=93 I figured out the issue, I = wasn=E2=80=99t properly setting broadcast addresses in the appropriate = areas. I rewrote my script to take this into account and it works great = now =E2=98=BA From jasonb@edseek.com Fri Apr 9 19:29:26 2004 From: jasonb@edseek.com (Jason Boxman) Date: Fri, 9 Apr 2004 14:29:26 -0400 Subject: [LARTC] tcsim (was: Can I give more bandwidth to a specific URL) In-Reply-To: <200404061729.01973.jasonb@edseek.com> References: <20040405111919.81822.qmail@web40408.mail.yahoo.com> <200404061729.01973.jasonb@edseek.com> Message-ID: <200404091429.26210.jasonb@edseek.com> On Tuesday 06 April 2004 17:29, Jason Boxman wrote: > On Tuesday 06 April 2004 05:17, Martin A. Brown wrote: > > > > If you are just starting out with traffic control under Linux, I strongly > > recommend learning and using tcng from the beginning. The control > > language offered by tcng (although technical) is much more like English > > or human language than the more arcane tc syntax. Here are some starting > > points for learning about tcng [4] [5]. (Lest there be any doubt, you > > will need tc, from iproute2, as well as tcng.) > > Speaking of TCNG, I read through the various guides and I still can't > figure out how I am supposed to be using tcsim. While I can get it to > output information and graph it, the output does not mean anything to me. > I was expecting output similar to what appears on the HTB author's Web > site, since that means a lot more to me. > > What is tcsim telling me exactly? Does no one use tcsim? > Thanks! > > > > > -Martin > > > > [0] http://lartc.org/ > > [1] http://www.docum.org/ > > [2] http://www.docum.org/stef.coene/qos/faq/cache/ > > [3] http://tldp.org/HOWTO/Traffic-Control-HOWTO/ > > [4] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/ > > [5] http://linux-ip.net/gl/tcng/ > From stillnick2@terra.com.br Fri Apr 9 20:19:03 2004 From: stillnick2@terra.com.br (Cristiano Soares) Date: Fri, 9 Apr 2004 16:19:03 -0300 Subject: [LARTC] link redundancy... Message-ID: <005001c41e67$8592ed40$6400a8c0@stillnicks> This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C41E4E.5FED8320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know how to make a link redundancy? I have two ADSL lines, = and i want the linux machine to be able to switch between the two lines = everytime the first ADSL line goes down. Thanks a lot. Cristiano ------=_NextPart_000_004D_01C41E4E.5FED8320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone know how to make a link = redundancy? I=20 have two ADSL lines, and i want the linux machine to be able to switch = between=20 the two lines everytime the first ADSL line goes down. Thanks a=20 lot.
 
Cristiano
------=_NextPart_000_004D_01C41E4E.5FED8320-- From cheako911@yahoo.com Fri Apr 9 22:18:49 2004 From: cheako911@yahoo.com (Mike Mestnik) Date: Fri, 9 Apr 2004 14:18:49 -0700 (PDT) Subject: [LARTC] Monitoring qdisks and classes. Message-ID: <20040409211849.89302.qmail@web11904.mail.yahoo.com> Are there any tools like iptraf or top to display tc stats? I would like to see things like flowes(TCP or UDP connections) as well as simple per second stats. I'm trying to monitor my p2p uploads and network connections to see if things are getting into the right class. I used to use mrtg for this, with some perl scripts I wrote. This project of mine has long since bitrotten. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From RonSenykoff@edapt.us Fri Apr 9 22:41:19 2004 From: RonSenykoff@edapt.us (RonSenykoff@edapt.us) Date: Fri, 9 Apr 2004 16:41:19 -0500 Subject: [LARTC] Load Balancing w/ Proxies Message-ID: This is a multipart message in MIME format. --=_alternative 0077347786256E71_= Content-Type: text/plain; charset="US-ASCII" Hello all. I have load balancing (DSL + Cable) ala nano HOWTO + some modifications. Works great. LAN | ----------- | LOAD | |BALANCER | ----------- | | Firewall Firewall | | Cable DSL Modem Modem | | Internet Internet I would like to be able to define proxies for certain applications so that I can force them to use a particular interface and thus control if they go out cable vs DSL. You think I could install some kind of proxy on the load balancing box and achieve this or will I need to make two proxy server boxes, one off each external interface on the load balancer? I'm using the load balancer for home office use. I want to specify, say for streaming video to use the cable modem, as it has a much higher download rate. I know I could create some static routes for certain ports (I have already done this using mangle) but I don't want to have to do this every time I configure a new application. By having 'proxies' any application that supports proxy server can be configured for a particular interface. It could be quite convenient. It doesn't need to be a true proxy like Squid, just something to relay the traffic. Any ideas are greatly appreciated, -Ron --=_alternative 0077347786256E71_= Content-Type: text/html; charset="US-ASCII"
Hello all.

I have load balancing (DSL + Cable) ala nano HOWTO + some modifications. Works great.

      LAN
       |
  -----------
  | LOAD    |
  |BALANCER |
  -----------
  |         |
Firewall  Firewall
  |         |
Cable      DSL
Modem      Modem
  |         |
Internet Internet


I would like to be able to define proxies for certain applications so that I can force
them to use a particular interface and thus control if they go out cable vs DSL. You think
I could install some kind of proxy on the load balancing box and achieve this or will I need
to make two proxy server boxes, one off each external interface on the load balancer?

I'm using the load balancer for home office use. I want to specify, say for streaming video to use
the cable modem, as it has a much higher download rate. I know I could create some static routes
for certain ports (I have already done this using mangle) but I don't want to have to do
this every time I configure a new application. By having 'proxies' any application that supports
proxy server can be configured for a particular interface. It could be quite convenient. It doesn't
need to be a true proxy like Squid, just something to relay the traffic.

Any ideas are greatly appreciated,
-Ron --=_alternative 0077347786256E71_=-- From rwd@res.lt Sat Apr 10 00:15:30 2004 From: rwd@res.lt (Arturas Lapiene) Date: Sat, 10 Apr 2004 02:15:30 +0300 Subject: [LARTC] Re: HTB Message-ID: <20040409231530.GA8704@rwd.res.lt> Hello, I have problems with htb. The problem is that when I download any file via shaper with htb, the traffic is very dinamic, it jumps, for example: if i have set ceil = 128kbit the results that it jumps from 112kbps to 144kbps or smth like that maybe its not very bad, but when the traffic drops down to 40kbps or less and then after 1 or 2 seconds jumps to 144kbps, its bad :-( and it is often. Root class is 20Mbit There are about 7000 classes (on two interfaces) an example script: =============================================================================================== #!/bin/sh TC="/sbin/tc" INT_IF="eth1" EXT_IF="eth0" $TC qdisc del dev $INT_IF root $TC qdisc del dev $EXT_IF root $TC qdisc add dev $INT_IF root handle 1: htb r2q 1 default 2000 # tried default r2q $TC qdisc add dev $EXT_IF root handle 1: htb r2q 1 default 2000 $TC class add dev $INT_IF parent 1: classid 1:1 htb quantum 60000 rate 20Mbit ceil 20Mbit $TC class add dev $EXT_IF parent 1: classid 1:1 htb quantum 40000 rate 20Mbit ceil 20Mbit $TC class add dev $INT_IF parent 1:1 classid 1:2000 htb quantum 1500 rate 1kbit ceil 5kbit $TC class add dev $EXT_IF parent 1:1 classid 1:2000 htb quantum 1500 rate 1kbit ceil 5kbit $TC qdisc add dev $INT_IF parent 1:2000 handle 2000: sfq perturb 10 $TC qdisc add dev $EXT_IF parent 1:2000 handle 2000: sfq perturb 10 $TC class add dev $INT_IF parent 1:1 classid 1:2001 htb quantum 60000 rate 682kbit ceil 2048kbit # tried to let htb itself calculate quantum, the same $TC class add dev $EXT_IF parent 1:1 classid 1:2001 htb quantum 60000 rate 682kbit ceil 2048kbit $TC qdisc add dev $INT_IF parent 1:2001 handle 2001: sfq perturb 10 $TC qdisc add dev $EXT_IF parent 1:2001 handle 2001: sfq perturb 10 $TC filter add dev $INT_IF protocol ip parent 1:0 prio 1 u32 match ip dst x.x.x.x flowid 1:2001 $TC filter add dev $EXT_IF protocol ip parent 1:0 prio 1 u32 match ip src x.x.x.x flowid 1:2001 $TC class add dev $INT_IF parent 1:1 classid 1:2002 htb quantum 1500 rate 42kbit ceil 128kbit $TC class add dev $EXT_IF parent 1:1 classid 1:2002 htb quantum 1500 rate 42kbit ceil 128kbit $TC qdisc add dev $INT_IF parent 1:2002 handle 2002: sfq perturb 10 $TC qdisc add dev $EXT_IF parent 1:2002 handle 2002: sfq perturb 10 $TC filter add dev $INT_IF protocol ip parent 1:0 prio 1 u32 match ip dst x.x.x.x flowid 1:2002 $TC filter add dev $EXT_IF protocol ip parent 1:0 prio 1 u32 match ip src x.x.x.x flowid 1:2002 ================================================================================================ linux 2.4.25 network cards: eepro100 HTB 3 Xeon 2.4GHz Maybe I need to tune kernel, HZ or smth? sorry for bad english -- Arturas From rwd@res.lt Sat Apr 10 00:09:28 2004 From: rwd@res.lt (Arturas Lapiene) Date: Sat, 10 Apr 2004 02:09:28 +0300 Subject: [LARTC] HTB Message-ID: <20040409230928.GR5872@rwd.res.lt> Hello, I have problems with htb. The problem is that when I download any file via shaper with htb, the traffic is very dinamic, it jumps, for example: if i have set ceil = 128kbit the results that it jumps from 112kbps to 144kbps or smth like that maybe its not very bad, but when the traffic drops down to 40kbps or less and then after 1 or 2 seconds jumps to 144kbps, its bad :-( and it is often. Root class is 20Mbit There are about 7000 classes (on two interfaces) an example script: =============================================================================================== #!/bin/sh TC="/sbin/tc" INT_IF="eth1" EXT_IF="eth0" $TC qdisc del dev $INT_IF root $TC qdisc del dev $EXT_IF root $TC qdisc add dev $INT_IF root handle 1: htb r2q 1 default 2000 # tried default r2q $TC qdisc add dev $EXT_IF root handle 1: htb r2q 1 default 2000 $TC class add dev $INT_IF parent 1: classid 1:1 htb quantum 60000 rate 20Mbit ceil 20Mbit $TC class add dev $EXT_IF parent 1: classid 1:1 htb quantum 40000 rate 20Mbit ceil 20Mbit $TC class add dev $INT_IF parent 1:1 classid 1:2000 htb quantum 1500 rate 1kbit ceil 5kbit $TC class add dev $EXT_IF parent 1:1 classid 1:2000 htb quantum 1500 rate 1kbit ceil 5kbit $TC qdisc add dev $INT_IF parent 1:2000 handle 2000: sfq perturb 10 $TC qdisc add dev $EXT_IF parent 1:2000 handle 2000: sfq perturb 10 $TC class add dev $INT_IF parent 1:1 classid 1:2001 htb quantum 60000 rate 682kbit ceil 2048kbit # tried to let htb itself calculate quantum, the same $TC class add dev $EXT_IF parent 1:1 classid 1:2001 htb quantum 60000 rate 682kbit ceil 2048kbit $TC qdisc add dev $INT_IF parent 1:2001 handle 2001: sfq perturb 10 $TC qdisc add dev $EXT_IF parent 1:2001 handle 2001: sfq perturb 10 $TC filter add dev $INT_IF protocol ip parent 1:0 prio 1 u32 match ip dst x.x.x.x flowid 1:2001 $TC filter add dev $EXT_IF protocol ip parent 1:0 prio 1 u32 match ip src x.x.x.x flowid 1:2001 $TC class add dev $INT_IF parent 1:1 classid 1:2002 htb quantum 1500 rate 42kbit ceil 128kbit $TC class add dev $EXT_IF parent 1:1 classid 1:2002 htb quantum 1500 rate 42kbit ceil 128kbit $TC qdisc add dev $INT_IF parent 1:2002 handle 2002: sfq perturb 10 $TC qdisc add dev $EXT_IF parent 1:2002 handle 2002: sfq perturb 10 $TC filter add dev $INT_IF protocol ip parent 1:0 prio 1 u32 match ip dst x.x.x.x flowid 1:2002 $TC filter add dev $EXT_IF protocol ip parent 1:0 prio 1 u32 match ip src x.x.x.x flowid 1:2002 ================================================================================================ linux 2.4.25 network cards: eepro100 HTB 3 Xeon 2.4GHz Maybe I need to tune kernel, HZ or smth? sorry for bad english -- Arturas From pfalcone@polerio.com.ph Sat Apr 10 03:13:11 2004 From: pfalcone@polerio.com.ph (Paolo Alexis Falcone) Date: Sat, 10 Apr 2004 10:13:11 +0800 Subject: [LARTC] link redundancy... In-Reply-To: <005001c41e67$8592ed40$6400a8c0@stillnicks> References: <005001c41e67$8592ed40$6400a8c0@stillnicks> Message-ID: <20040410021311.GA7001@zion.polerio.com.ph> On Fri, Apr 09, 2004 at 04:19:03PM -0300, Cristiano Soares wrote: > Does anyone know how to make a link redundancy? I have two ADSL lines, and > i want the linux machine to be able to switch between the two lines > everytime the first ADSL line goes down. Thanks a lot. > > Cristiano You'll need BGP4 support for this. GNU Zebra[1] may help you here. [1] www.zebra.org -- Paolo Alexis Falcone pfalcone@free.net.ph From peter@ssp.st Sat Apr 10 04:00:13 2004 From: peter@ssp.st (Peter Salanki) Date: Sat, 10 Apr 2004 05:00:13 +0200 Subject: [LARTC] link redundancy... In-Reply-To: <005001c41e67$8592ed40$6400a8c0@stillnicks> References: <005001c41e67$8592ed40$6400a8c0@stillnicks> Message-ID: <20040410050013.34aec7ef.peter@ssp.st> That could be done with a simple shell script, just pinging and switching if host doesn't respond. Otherwise u could use something more complex such as BGP, but I really don't think your ADSL provider allows yo to ibgp peer with them :/ On Fri, 9 Apr 2004 16:19:03 -0300 "Cristiano Soares" wrote: > Does anyone know how to make a link redundancy? I have two ADSL lines, and i want the linux machine to be able to switch between the two lines everytime the first ADSL line goes down. Thanks a lot. > > Cristiano > From lmn@mail.xprtsol.com Sat Apr 10 21:41:56 2004 From: lmn@mail.xprtsol.com (lmn@mail.xprtsol.com) Date: Sat, 10 Apr 2004 16:41:56 -0400 Subject: [LARTC] handle route table in kernel Message-ID: <20040410204156.GA20104@mail.xprtsol.com> Hi all, How can I add or modify a route in the kernel? It seems ip_rt_ioctl() does the job. I read the code but got one question. A route is in a route table, so we have to find the table number (from 0 to 255) first. ip_rt_ioctl() called fib_convert_rtentry() to fill the fields of the req.rtm, such as the rtm_protocol, rtm_scope, rtm_type, etc. But where is rtm_table is assigned value? Or is there any other better method to change the routing table in the kernel? Thanks, LMN From brooney@xcommunications.co.uk Sun Apr 11 10:04:05 2004 From: brooney@xcommunications.co.uk (Barry Rooney) Date: Sun, 11 Apr 2004 10:04:05 +0100 Subject: [LARTC] RTSP Traffic over UDP Message-ID: <009c01c41fa3$f1296a10$0a01000a@desktop1> This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C41FAC.52C08080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I'm running performance tests on a Linux router using IPTables to nat = traffic over the network. I have a MS Media streamer, and two windows clients behind the router which download video from the = streamer. I can then measure performance. MS Media player rolls amongst protocols until it finds one it can use as = follows RTSP UDP RTSP TCP MMS UDP MMS TCP HTTP Unfortunately it will never use UDP to stream the video files. I know = this is due to the Linux router not understanding the RTSP packets. Does = anyone know how I can rectify this??? Thanks, Barry. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.637 / Virus Database: 408 - Release Date: 20/03/2004 ------=_NextPart_000_0099_01C41FAC.52C08080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Hello All,
I'm running performance tests on a = Linux router=20 using IPTables to nat traffic over the network. I have a MS Media=20 streamer,
and two windows clients behind the = router which=20 download video from the streamer. I can then measure = performance.
 
MS Media player rolls amongst protocols = until it=20 finds one it can use as follows
 
RTSP UDP
RTSP TCP
MMS UDP
MMS TCP
HTTP
 
Unfortunately it will never use UDP to = stream the=20 video files. I know this is due to the Linux router not understanding = the RTSP=20 packets. Does anyone know how I can rectify this???
 
Thanks,
 
Barry.
 
 

---
Outgoing mail is certified = Virus=20 Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.637 /=20 Virus Database: 408 - Release Date: = 20/03/2004
------=_NextPart_000_0099_01C41FAC.52C08080-- From listas@dejawu.com.ar Sun Apr 11 21:39:12 2004 From: listas@dejawu.com.ar (listas@dejawu.com.ar) Date: Sun, 11 Apr 2004 17:39:12 -0300 Subject: [LARTC] Monitoring qdisks and classes. In-Reply-To: <20040409211849.89302.qmail@web11904.mail.yahoo.com> Message-ID: <000901c42005$0fbe6dc0$020000ac@dejawu> Ive seen this question made many times..as I like my own stadistic apps I made some tiny perl sripts: I made my own perl script to save classes and then with gnuplot make some stats (www.dejawu.com.ar/qos/) The perl can be found in www.dejawu.com.ar/public_papers/get_tc_class.pl I also use other to get interfaces stadistics .. www.dejawu.com.ar/public_papers/mide_interfaces.pl and so own..in the public_papers/ dir are a lot of *.pl files that may be usefull.. Then I use gnuplot scripts www.dejawu.com.ar/qos/interfaces/interfaz.gnuplot for example..(you can do your own gnuplot file for the classes).. Bye, hope it helps. Esteban. -----Mensaje original----- De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En nombre de Mike Mestnik Enviado el: Friday, April 09, 2004 6:19 PM Para: lartc@mailman.ds9a.nl Asunto: [LARTC] Monitoring qdisks and classes. Are there any tools like iptraf or top to display tc stats? I would like to see things like flowes(TCP or UDP connections) as well as simple per second stats. I'm trying to monitor my p2p uploads and network connections to see if things are getting into the right class. I used to use mrtg for this, with some perl scripts I wrote. This project of mine has long since bitrotten. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From roy@xxx.lt Sun Apr 11 22:46:14 2004 From: roy@xxx.lt (Roy) Date: Mon, 12 Apr 2004 00:46:14 +0300 Subject: [LARTC] Double network card link for windows References: <009c01c41fa3$f1296a10$0a01000a@desktop1> Message-ID: <002801c4200e$6ad017f0$030aa8c0@t> Does someone know some driver for windows which can somehow split packets between multiple interfaces. linux iptables can do that easily, but that way I will be able only use multiple intrfaces to send data TO windows conputer. two 1 gbit cards costs too much so it would be nice to use four or more 100 mbit cards instead. From imipak@yahoo.com Sun Apr 11 23:49:05 2004 From: imipak@yahoo.com (Jonathan Day) Date: Sun, 11 Apr 2004 15:49:05 -0700 (PDT) Subject: [LARTC] Documentation query In-Reply-To: <002801c4200e$6ad017f0$030aa8c0@t> Message-ID: <20040411224905.91786.qmail@web12301.mail.yahoo.com> Hi, The documentation in CVS seems to be getting a little stale. Is this because of a lack of contributors (unlikely, given the very healthy mailing list) or lack of time by maintainers? If the former, then I'll work on writing something up, because I'd like to see the knowledge out there preserved. If the latter, is there anything list members like myself can do? __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From andy.furniss@dsl.pipex.com Sun Apr 11 23:31:55 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 11 Apr 2004 23:31:55 +0100 Subject: [LARTC] noprioportsrc In-Reply-To: <200403292131.56833.finbert@sbcglobal.net> References: <200403291208.12134.finbert@sbcglobal.net> <4068AE05.1010808@snapgear.com> <200403292131.56833.finbert@sbcglobal.net> Message-ID: <4079C75B.403@dsl.pipex.com> Richard wrote: > On Monday 29 March 2004 11:15 pm, Damion de Soto wrote: > > >>I've fonud trying to make >>bittorrent behave itself is quite difficult. >>The 3 classes have rates specified as UPLINK, 9*$UPLINK/10 and 8*$UPLINK/10 >>This means the sum of the 3 classes is greater than the parent. >>You may want to specify the rates as something lower that add up to UPLINK, >>and then specify the ceil value for each class. > > > I tried what you had suggested and I was able to get great pings while > uploading using the script! > > Now this is the really things get strange. Without doing anything to my > connection or with wondershaper, about after 1 hour of running the script > (and having my bandwith limited to 50kb/s) something changes and I start > uploading at my max again. > > Why is this happening? I don't think marking those BT ports will catch all BT connections - BT will work without opening ports. I think you can mark with one of the P2P marking projects on sf.net. Andy. From gaston@steel.com.ar Mon Apr 12 14:23:21 2004 From: gaston@steel.com.ar (=?iso-8859-1?Q?Gast=F3n?=) Date: Mon, 12 Apr 2004 10:23:21 -0300 Subject: [LARTC] medir trafico References: <001401c41c0a$236cf390$0201c80a@H4X0RN0T3B00K> Message-ID: <001701c42091$53913af0$cd302bc8@traza> Zorbiptraffic: http://www.atout.be/zorbiptrafficlive/zorbiptraffic.php ----- Original Message ----- From: "Neilson Henriques" To: "ThE LinuX_KiD" ; "lartc" Sent: Tuesday, April 06, 2004 4:05 PM Subject: Re: [LARTC] medir trafico > bandwidthd.sf.net > > ----- Original Message ----- > From: "ThE LinuX_KiD" > To: "lartc" > Sent: Tuesday, April 06, 2004 3:59 PM > Subject: [LARTC] medir trafico > > > > hola listeros! > > > > existe algun script webScript, proyecto, herramienta > > o lo que sea, que sirva para medir el trafico total de una > > lan, como para hacer reportes mensuales por host ? > > > > necesito hacer algo asi: > > > > > > host Trafico/mes > > ----------------------------- > > 192.168.1.x1 xxxxx Bytes > > 192.168.1.x2 xxxxx Bytes > > 192.168.1.x3 xxxxx Bytes > > 192.168.1.x4 xxxxx Bytes > > > > > > ese seria un reporte a efectuar el ultimo > > dia de cada mes... > > > > saludos y gracias !!! > > mac > > > > > > > > _______________________________________________ > > 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 raptor@tvskat.net Mon Apr 12 21:24:49 2004 From: raptor@tvskat.net (raptor) Date: Mon, 12 Apr 2004 23:24:49 +0300 Subject: [LARTC] installing automatic routes ? Message-ID: <20040412232449.0e8edded@vr> hi, I have this : .... several CMTS-cable-bridges(3). I have gateway a linux-router(2) (firewall/Shaper too), with eth0 pointing to the CMTS-bridges.. Things behind the ethernet interface of the cmts-bridges includes FTP,WEB, DNS ets servers... on the cable side are thousands of modems and CPE's (computers...). Currently the network traffic always passes torught linux-router-eth0 interface 'cause all cable modems and CPE has it as a gateway device.. (eth0 is aliased as ~10 interfaces with all classC nets gateways i.e. eth0:1,eth0:2 ....) That is why I have at least 10 class-C networks laying in one Ethernet segment, but on the other hand they are logicaly (i.e. IP level) separated by the gateway/s.. I dont want to include separate machine as router, 'cause this will complicate the the network.. and is yet another point of failure... ( I prefer flat-net, probably adding more linux-routers/bridges side by side, but not one behind another) I also see something very interesting the traffic that passes from cable-network to the FTP server for example goes trough linux-router, but then it returns directly to the cable-net (for some unknown reson, probaly 'cause cmts-bridges are apr-proxies!!! still wondering, any idea is welcome.. :") ) instead of returning it back torught linux-router which is GOOD(tm) for me :").. Finally what I want is upstream traffic to go directly to FTP server instead torught linux-router-gateway. Pic : Internet(1) <-->linuxrouter(2) <---|---> cmts-bridges(3) <---> CATV (alot of net's)(4) || || local-resources(ftp,web,dns) (5) So the traffic at the moment is : 4->3->(2)->5->3->4 I want it to be : 4->3->5->3->4 If I install route like this on some computer in (4) like this : ip route add (5) via (4) It works the way I want, but :") instead of doing it on every comp in (4), I want to install it automaticaly, so I thought is there a way to insert some routes !! in (5) (to return icmp-redirects, will this work) so that after several packets (4) to adjust their tables automaticaly... If yes HOW !? if no is there other way to do it ? tia From Peteris Krumins Mon Apr 12 19:54:30 2004 From: Peteris Krumins (Peteris Krumins) Date: Mon, 12 Apr 2004 21:54:30 +0300 Subject: [LARTC] medir trafico In-Reply-To: References: Message-ID: <1014727056.20040412215430@lf.lv> Tuesday, April 6, 2004, 9:59:55 PM, you wrote: TL> hola listeros! I do not understand that (Spanish?) language, but I guess you want a tool which would output traffic statistics? I have created for the ISP i work for, pretty simple tool. If some people wanted, I could share it under GPL. +-[ traffic for: 2004-04-11 , traffic in KiloBytes ]------------+---------------+ | IP Address | Latvia IN | Latvia OUT | Foreign IN | Foreign OUT | +------------------+--------------+--------------+--------------+---------------+ | 10.1.1.100 | 759 | 9613 | 320 | 2265 | | 10.1.1.12 | 1663 | 1296 | 145 | 17 | | 10.1.1.194 | 243074 | 1868167 | 62063 | 2094 | | 10.1.1.21 | 596 | 1225 | 119 | 26 | | 10.1.1.26 | 2 | 2 | 5 | 4 | (lots more more) | 10.5.9.2 | 0 | 0 | 2271 | 419 | +------------------+--------------+--------------+--------------+---------------+ | total: --- IPs | XXXXXXXXX | XXXXXXXXX | XXXXXXXXX | XXXXXXXXX | +------------------+--------------+--------------+--------------+---------------+ | total: | Latvia: XXXXXXXXX | Foreign: XXXXXXXXX | +------------------+--------------+--------------+--------------+---------------+ The accounting is done via Netfilter, runs only on Linux. For each IP a single rule is created. Perl script walks through (takes output of `iptables') these rules, reads counters and zeros the tables. Other Perl scripts output data to text files, generates the ascii table seen above, puts data into database and the last script mails the ascii table. P.Krumins From roy@xxx.lt Mon Apr 12 21:03:43 2004 From: roy@xxx.lt (Roy) Date: Mon, 12 Apr 2004 23:03:43 +0300 Subject: [LARTC] installing automatic routes ? References: <20040412232449.0e8edded@vr> Message-ID: <007401c420c9$41bbd280$030aa8c0@t> Icmp redirect hardly could work because this feature is to dangeraous to even enable. ip route add (5) via (4) sounds abnormal, I suppose 4 is client, so how you can route through yourself. if you want to avoid router, then you need to make local resources to be within client netmask address space. or else they will be accessed through default gateway, which is that router. ----- Original Message ----- From: "raptor" To: Sent: Monday, April 12, 2004 11:24 PM Subject: [LARTC] installing automatic routes ? > hi, > > I have this : > > .... several CMTS-cable-bridges(3). > I have gateway a linux-router(2) (firewall/Shaper too), with eth0 pointing to the > CMTS-bridges.. > Things behind the ethernet interface of the cmts-bridges includes FTP,WEB, DNS ets > servers... > on the cable side are thousands of modems and CPE's (computers...). > Currently the network traffic always passes torught linux-router-eth0 interface 'cause > all cable modems and CPE has it as a gateway device.. > (eth0 is aliased as ~10 interfaces with all classC nets gateways i.e. eth0:1,eth0:2 > ....) > That is why I have at least 10 class-C networks laying in one Ethernet segment, > but on the other hand they are logicaly (i.e. IP level) separated by the gateway/s.. > > I dont want to include separate machine as router, 'cause this will complicate the > the network.. and is yet another point of failure... > ( I prefer flat-net, probably adding more linux-routers/bridges side by side, but not one > behind another) > > I also see something very interesting the traffic that passes from cable-network to > the FTP server for example goes trough linux-router, but then it returns directly to > the cable-net (for some unknown reson, probaly 'cause cmts-bridges are apr-proxies!!! > still wondering, any idea is welcome.. :'"') ) > instead of returning it back torught linux-router which is GOOD(tm) for me :'"').. > > Finally what I want is upstream traffic to go directly to FTP server instead torught > linux-router-gateway. > Pic : > > > Internet(1) <-->linuxrouter(2) <---|---> cmts-bridges(3) <---> CATV > (alot of net's)(4) > || > || > local-resources(ftp,web,dns) (5) > > So the traffic at the moment is : 4->3->(2)->5->3->4 > I want it to be : 4->3->5->3->4 > > > If I install route like this on some computer in (4) like this : > > ip route add (5) via (4) > > It works the way I want, but :'"') instead of doing it on every comp in (4), I want > to > install it automaticaly, so I thought is there a way to insert some routes !! in (5) > (to return icmp-redirects, will this work) so that after several packets (4) to adjust > their > tables automaticaly... > > If yes HOW !? if no is there other way to do it ? > > tia > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From dchemko@smgtec.com Mon Apr 12 21:10:03 2004 From: dchemko@smgtec.com (Daniel Chemko) Date: Mon, 12 Apr 2004 13:10:03 -0700 Subject: [LARTC] installing automatic routes ? Message-ID: <7C9884991ADAE0479C14F10C858BCDF5122F43@alderaan.smgtec.com> Unless the bridge keeps stateful inspection data and can reply back to the session's origin, not it route then its fine. The only way I can see this working is either putting the FTP/.. DMZ behind the firewall giving true firewall protection for all services involved, or if you just want to kludge the current solution, you can perform a DNAT/SNAT interface bounce like the following: # Session=20 iptables -A PREROUTING --destination ${FAKE_FTP_IP} -p tcp --dport 21 -j MARK 1234 iptables -A PREROUTING --destination ${FAKE_FTP_IP} -p tcp --dport 21 -j DNAT ${MY_FTP_SERVER} iptables -A POSTROUTING -m mark 1234 -j SNAT --to ${MY_INTERNAL_IP} The above should work for single channel TCP/IP traffic, but I don't know if more is needed for multi-session FTP. The RELATED streams may be handled automatically in the NAT code, or you may have to explicitly place rules into the code. Of course, the identity of the FTP user can't be tracked on the FTP server since they all appear to be coming from the firewall in question. From alex@pilosoft.com Mon Apr 12 22:49:00 2004 From: alex@pilosoft.com (alex@pilosoft.com) Date: Mon, 12 Apr 2004 17:49:00 -0400 (EDT) Subject: [LARTC] tc feature request/bounty (fwd) Message-ID: Currently, linux tc has very useful concept of a 'index' for a given policy. However, I need to have policers on multiple hosts to share the same index (and thus, know and police the aggregate traffic across a set of routers). I'd like to be able to share tc policers across a set of boxes. Unfortunately, I'm not knowledgeable enough myself to implement that, but I can throw some money at the pool and hope someone picks it up. ;) Proposed design: Userland daemon that polls kernel tc structure every X milliseconds and broadcasts current bps rate (assuming we are using ewma) to a set of IP addresses. Configuration would have list of indices and list of IP addresses these indices are broadcast to. Kernel changes: Add netlink interface to look up/modify (by "injecting" traffic) policer's structures (interface to tcf_police_lookup and tcf_police_dump). Adding external traffic to policer structures is somewhat tricky, but I'm sure it is possible. At this point, I only care about EWMA, which isn't all that hard. Budget and bounty: 300$ Any takes? -alex From mingching.tiew@redtone.com Tue Apr 13 04:00:16 2004 From: mingching.tiew@redtone.com (Ming-Ching Tiew) Date: Tue, 13 Apr 2004 11:00:16 +0800 Subject: [LARTC] split route and kernel panic References: <97F5C25A8E0FA5429E240AB23DA2F8E903BE6A@mercury.marshtek.net> <014301c40d83$45fa3980$0100a8c0@newlife> Message-ID: <00e001c42103$73209470$0100a8c0@newlife> OK I have sufficient evidence now that my split route ( multipath routing ) is causing kernel panic and also frequent connection lost. I have set up the split route according to From mingching.tiew@redtone.com Tue Apr 13 04:06:40 2004 From: mingching.tiew@redtone.com (Ming-Ching Tiew) Date: Tue, 13 Apr 2004 11:06:40 +0800 Subject: [LARTC] Re: split route and kernel panic Message-ID: <00e801c42104$57c412f0$0100a8c0@newlife> OK I have sufficient evidence now that my split route ( multipath routing ) is inducing kernel panic and also frequent connection lost. The split route may not be the culprit but I can safely say that without using the split route, my system is perfectly stable. I have set up the split route according to http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html I could use the multipath routing to access the internet ( NAT ). I could also do multipath in-bound port forwarding using netfilter CONNMARK etc etc. The problem I have is that I get frequent connection lost ( like very 20 minutes or so for my connections ) and eventually I will get a kernel panic. Anyone experience the same thing before ? From stillnick2@terra.com.br Tue Apr 13 07:13:10 2004 From: stillnick2@terra.com.br (Cristiano Soares) Date: Tue, 13 Apr 2004 03:13:10 -0300 Subject: [LARTC] TCNG per IP... Message-ID: <014e01c4211e$65539b10$b401a8c0@stillnicks> This is a multi-part message in MIME format. ------=_NextPart_000_014B_01C42105.3FAE30F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. Im trying to shape some traffic, and i see that the best way to = do that is using TCNG. The thing is: I dont know how to shape bandwidth = per IP. Exemple: 192.168.1.20 ----> 256kbit(down) 128kbit(up) 192.168.1.21 ----> 512kbit(down) 128kbit(up) 192.168.1.22 ----> 180kbit(down) 128kbit(up) 192.168.1.23 ----> 768kbit(down) 128kbit(up) . . . Does anyone has an exemple script that i could just edit it and use? = Thanks a lot. Cristiano ------=_NextPart_000_014B_01C42105.3FAE30F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all. Im trying to shape some = traffic, and i see=20 that the best way to do that is using TCNG. The thing is: I dont know = how to=20 shape bandwidth per IP. Exemple:
 
192.168.1.20 ----> 256kbit(down)=20 128kbit(up)
192.168.1.21 ----> 512kbit(down)=20 128kbit(up)
192.168.1.22 ----> 180kbit(down)=20 128kbit(up)
192.168.1.23 ----> 768kbit(down)=20 128kbit(up)
.
.
.
 
 
 
Does anyone has an exemple script that = i could just=20 edit it  and use? Thanks a lot.
 
Cristiano
------=_NextPart_000_014B_01C42105.3FAE30F0-- From andy.furniss@dsl.pipex.com Tue Apr 13 08:46:07 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Tue, 13 Apr 2004 08:46:07 +0100 Subject: [LARTC] FWD IMQ mail on netdev Message-ID: <407B9ABF.60101@dsl.pipex.com> >From netdev@oss.sgi.com: ----- Forwarded message from jamal ----- X-Original-To: sebek@localhost X-Received-Date: Mon, 12 Apr 2004 03:25:37 +0200 (CEST) Subject: (Long) ANNOUNCE: IMQ replacement WAS(Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com Organization: jamalopolis X-archive-position: 4611 X-ecartis-version: Ecartis v1.0.0 X-original-sender: hadi@cyberus.ca X-list: netdev X-UIDL: 1081733138.87482_0.m1.post.cz,S=8283 Hello, Following up on a 3 month old email ;-> I finally hacked dummy device as a good replacement (IMO) for IMQ. I am only subscribed to netdev so if there are other lists which are of interest to this subject please forward on, but make sure responses make it to netdev. Well, why dummy you ask? Because it is such dumb a device ;-> Ok, that may not be funny enough, how about: because nobody has touched the dummy device in 10 years - that cant be right in Linux. On a serious note though, because i didnt think it was worth writting another device for this. Dummy continues to work the same way when not used with tc extensions. Like i said in my email at the bottom that IMQ was just at the wrong abstraction layer. The dummy extension can now pick ANY packets (not just IP and requiring to attach to a few hooks to get IPV6, arp etc) Of course all this needs the tc extensions (which has a lot of other features that i wont discuss here). Why dont i show an example: ---- export TC="/sbin/tc" # #attach prio qdisc to the dummy0 device # $TC qdisc add dev dummy0 root handle 1: prio $TC qdisc add dev dummy0 parent 1:1 handle 10: sfq $TC qdisc add dev dummy0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 $TC qdisc add dev dummy0 parent 1:3 handle 30: sfq # redirect packets coming in with fwmark 1 to class 1:1 (sfq) $TC filter add dev dummy0 protocol ip pref 1 parent 1: handle 1 fw classid 1:1 #redirect packets tagged with fwmark 2 to 1:2 (tbf) $TC filter add dev dummy0 protocol ip pref 2 parent 1: handle 2 fw classid 1:2 #bring up dummy0 ifconfig dummy0 up #watch the ingress of eth0; $TC qdisc add dev eth0 ingress # redirect all IP packets arriving in eth0 to dummy0 # use mark 1 --> puts them onto class 1:1 $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action ipt -j MARK --set-mark 1 \ action mirred egress redirect dev dummy0 # note, the above just shows eth0 and only at ingress; # you could repeat this on egress/ingress of any device # and redirect to dummy0 if you wanted; A Little test: from another machine ping so that you have packets going into the box: ----- [root@jzny action-tests]# ping 10.22 PING 10.22 (10.0.0.22): 56 data bytes 64 bytes from 10.0.0.22: icmp_seq=0 ttl=64 time=2.8 ms 64 bytes from 10.0.0.22: icmp_seq=1 ttl=64 time=0.6 ms 64 bytes from 10.0.0.22: icmp_seq=2 ttl=64 time=0.6 ms --- 10.22 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.6/1.3/2.8 ms [root@jzny action-tests]# Now look at some stats: ----- [root@jmandrake]:~# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 10 u32 filter protocol ip pref 10 u32 fh 800: ht divisor 1 filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 match 00000000/00000000 at 0 action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target MARK set 0x1 index 1 ref 1 bind 1 installed 4195sec used 27sec Sent 252 bytes 3 pkts (dropped 0, overlimits 0) action order 2: mirred (Egress Redirect to device dummy0) stolen index 1 ref 1 bind 1 installed 165 sec used 27 sec Sent 252 bytes 3 pkts (dropped 0, overlimits 0) [root@jmandrake]:~# ifconfig dummy0 dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:6 errors:0 dropped:3 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:504 (504.0 b) TX bytes:252 (252.0 b) ----- Note the three extra received packets on dummy0 were ndisc packets sent by the stack when it booted up (which would normally be dropped - they were). Also, the mirred action can do a _lot_ more, but thats not the point of this email. Send me private email if you want to know more. Additionaly note: the ipt report of NF_IP_PRE_ROUTING is a lie since this happens waaay before IP. This has been tested on both uni and smp machines. Unfortunately, the code is only available for 2.4.x (2.4.25 patches available - more vigorous testing happened on 2.4.21 - my two machines above) What am i looking for? 1) users and authors of IMQ to tell me if this achieves what IMQ started as. I have to say I DONT like the level of obstrutiveness from IMQ as is today. The code added by this is small (100 or less lines on top of dummy) and doesnt touch any of the main core bits. 2) testing of the above by people who use IMQ 3) If someone has better ideas - i am not religious about keeping this; but it certainly cant be the blasphemy that IMQ introduces. I have also introduced hooks to easily add a -i to tc classifiers - still on the TODO list. So on the egress you could now classify based on which incoming device the packet arrived on. cheers, jamal On Sat, 2004-01-31 at 17:26, jamal wrote: >> On Sat, 2004-01-31 at 16:58, Vladimir B. Savkin wrote: >> > >>> > Well, not, the primary reason being that there would be no single class >>> > with appropriate bandwith limit (ceil). There would be multiple classes, > >> >> Ok - i think you made your point. >> So i should add that a third condition is there are multiple devices >> towards the clients. >> You have convinced me there is value in such a scheme as IMQ provides >> for such conditions. As it is right now though IMQ needs to have the >> right abstraction (and not be dependent on netfilter).And may be we >> could abuse it to do other things. >> Let me hear from Tomas and then we should take it from there. >> >> cheers, >> jamal >> >> ----- End forwarded message ----- From al@xms.co.za Tue Apr 13 14:59:33 2004 From: al@xms.co.za (Andrew Lewis) Date: 13 Apr 2004 15:59:33 +0200 Subject: [LARTC] RE: Selectively filtering traffic in/out to common threshold Message-ID: <1081864772.2002.79.camel@al.xms.co.za> Hi all, Thanks for the pointer, Roy. I'm currently busy implementing my own traffic shaping configuration using the IMQ device, and from my testing, it seems I'm doing something horribly wrong. Here's what I'm up to: I have to shape a number of clients to various rates for local & international traffic. These queue's must then be shaped into collective queues for local & international, because we have sold more bandwidth than we have. Traffic in/out must have a common threshold. So: I do insmod imq.o And /sbin/ifconfig imq up Then I do like so: To test locally something like what I want to do on our live servers: #!/bin/env sh PATH=/sbin iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT tc qdisc del dev imq root tc qdisc add dev imq root handle 2 htb r2q 1 tc class add dev imq parent 2: classid 2:1 htb rate 1kbit ceil 1kbit tc class add dev imq parent 2: classid 2:2 htb rate 10mbit ceil 10mbit iptables -t mangle -F PREROUTING iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -d 192.168.1.0/24 -j MARK --set-mark 0x20 iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -d ! 192.168.1.0/24 -j MARK --set-mark 0x21 iptables -t mangle -A PREROUTING -s ! 192.168.1.0/24 -d 192.168.1.0/24 -j MARK --set-mark 0x21 tc filter add dev imq parent 2: protocol ip pref 4 handle 0x20 fw classid 2:2 tc filter add dev imq parent 2: protocol ip pref 4 handle 0x21 fw classid 2:1 I then set this machine as my default gateway, which means my external connections should be very slow (1kbit). Not so. Packets go to imq (from where I don't know, but not necessarily from my machine).. My connections made through this box remain speedy. Excuse ignorance. :) Can some-one tell me where I'm going wrong? -AL. From cron@odi.com.br Tue Apr 13 15:00:04 2004 From: cron@odi.com.br (cron@odi.com.br) Date: Tue, 13 Apr 2004 07:00:04 -0700 Subject: [LARTC] Bandwith control Message-ID: <008d01c4215f$a0b78d10$a8db13ac@gesej.ciasc.gov.br> This is a multi-part message in MIME format. ------=_NextPart_000_008A_01C42124.F2B76120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I=B4ve read http://lartc.org/howto/ and now i am just confused, i think = my skills with linux are not very good, so asking for help.=20 I have a linux box with two ethernets cards eth0(gateway 1mb) with is = the host for=20 some sites and emails and eth1(nat interface) with provide internet = acess to other 5 pcs.=20 I would like to limit the bandwith 512 k for the eth0 and 512 k for eth1 = however whem there=20 is free bandwith in eth0 would be nice to eth1 use that bandwith so = users can download fast=20 as there is bandwith and sites and emails don=B4t get slow. Can someone point some directions? Tks Angelo ------=_NextPart_000_008A_01C42124.F2B76120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
 
I=B4ve read http://lartc.org/howto/ and = now i am=20 just confused, i think my skills with linux are not very good, so asking = for=20 help.
 
I have a linux box with two ethernets = cards=20 eth0(gateway 1mb) with is the host for
some sites and emails and eth1(nat = interface) with=20 provide internet acess to other 5 pcs.
 
I would like to limit the bandwith 512 = k for the=20 eth0 and 512 k for eth1 however whem there
is free bandwith in eth0 would be nice = to eth1 use=20 that bandwith so users can download fast
as there is bandwith and sites and = emails don=B4t get=20 slow.
 
Can someone point some = directions?
 
Tks
 
Angelo
------=_NextPart_000_008A_01C42124.F2B76120-- From RonSenykoff@edapt.us Tue Apr 13 16:39:23 2004 From: RonSenykoff@edapt.us (RonSenykoff@edapt.us) Date: Tue, 13 Apr 2004 10:39:23 -0500 Subject: [LARTC] Supported Hardware Solution Recommendations Please Message-ID: This is a multipart message in MIME format. --=_alternative 005612BB86256E75_= Content-Type: text/plain; charset="US-ASCII" Hello All, We are moving all our servers to a colo facility and need a solution for firewall / QoS that can handle multiple subnets of IPs routed to it. We expect to ramp up to a high volume of traffic as we migrate our users to Citrix. Unfortunately, the higher-ups are not willing to go with an 'unsupported' product even though I can demonstrate failover, etc. So, I figure there may be some companies offering a linux-based solution with support. Hardware based is preferable... Basically, they want something that if it fails, they can call up somebody on the phone and get it figured out. We need redundancy of the products as well. I'm thinking a firewall / bridge config using spanning tree for failover. Any suggestions (simply URLs to sites even) are greatly appreciated. Best Regards, -Ron --=_alternative 005612BB86256E75_= Content-Type: text/html; charset="US-ASCII"
Hello All,

We are moving all our servers to a colo facility and need a solution for firewall / QoS that can handle multiple subnets of IPs routed to it. We expect to ramp up to a high volume of traffic as we migrate our users to Citrix. Unfortunately, the higher-ups are not willing to go with an 'unsupported' product even though I can demonstrate failover, etc. So, I figure there may be some companies offering a linux-based solution with support. Hardware based is preferable... Basically, they want something that if it fails, they can call up somebody on the phone and get it figured out. We need redundancy of the products as well. I'm thinking a firewall / bridge config using spanning tree for failover.

Any suggestions (simply URLs to sites even) are greatly appreciated.

Best Regards,
-Ron --=_alternative 005612BB86256E75_=-- From digihall7@yahoo.com Tue Apr 13 21:13:26 2004 From: digihall7@yahoo.com (segun adesina) Date: Tue, 13 Apr 2004 13:13:26 -0700 (PDT) Subject: [LARTC] tc does'nt limit the bandwidth! In-Reply-To: <20040409233601.2788.27908.Mailman@outpost.ds9a.nl> Message-ID: <20040413201326.8460.qmail@web20103.mail.yahoo.com> Hi, good people! I wanted to limit my 4 customers to 144, 16, 32, and 32kbps. I used the following tc commands BUT IT FAILED TO LIMIT each and everyone of them to its bandwidth. What am I doing wrong: My tc scripts are: tc qdisc add dev eth1 root handle 1: htb default 1 #Classes# tc class add dev eth1 parent 1: classid 1:1 htb rate 9bps ceil 9bps #Default tc class add dev eth1 parent 1: classid 1:100 htb rate 9bps ceil 9bps #ICMP tc class add dev eth1 parent 1: classid 1:5 htb rate 144kbps ceil 256kbps #customer A tc class add dev eth1 parent 1: classid 1:101 htb rate 16kbps ceil 16kbps #customer B tc class add dev eth1 parent 1: classid 1:111 htb rate 32kbps ceil 32kbps #customer C tc class add dev eth1 parent 1: classid 1:121 htb rate 32kbps ceil 32kbps #customer D Can anyone help me on how to limit the the bandwidth to these customers. Regards. Digihall7. __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From cross@freshdt.com Tue Apr 13 22:14:53 2004 From: cross@freshdt.com (Vladimir Ichkov) Date: Wed, 14 Apr 2004 00:14:53 +0300 Subject: [LARTC] system requirements Message-ID: <001a01c4219c$67cc6600$a95c4fd9@cross> This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C421B5.827CA320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have the following problem with cbq.init script. I try to limit the output traffic from all my 254 IPs to 4Kb/s, but when I start the script the ping time from one of the shaped hosts drastically increases. 0,2-0,7 milisecs without shaper and 1500-2000 milisecs with. I though it might be the low CPU power or something. I'm running on 500MHz Intel Celeron. Anyone have experienced a similar problem? Here is the entry file I use for one of the IPs: DEVICE=3Deth1,10Mbit,1Mbit RATE=3D40Kbit WEIGHT=3D4Kbit PRIO=3D5 RULE=3D213.169.58.111, where eth1 is the internet interface. ------=_NextPart_000_0015_01C421B5.827CA320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I have the following problem with = cbq.init=20 script.
I try to limit the output traffic from = all my 254=20 IPs to 4Kb/s,
but when I start the script the ping = time from one=20 of the
shaped hosts drastically = increases.
0,2-0,7 milisecs without shaper and = 1500-2000=20 milisecs with.
I though it might be the low CPU power = or=20 something.
I'm running on 500MHz Intel Celeron. = Anyone=20 have
experienced a similar = problem?
Here is the entry file I use for one of = the=20 IPs:
 
DEVICE=3Deth1,10Mbit,1Mbit
RATE=3D40Kbit
WEIGHT=3D4KbitPRIO=3D5
RULE=3D213.169.58.111,
where eth1 is the internet=20 interface.
------=_NextPart_000_0015_01C421B5.827CA320-- From bugfood-ml@fatooh.org Tue Apr 13 22:32:14 2004 From: bugfood-ml@fatooh.org (Corey Hickey) Date: Tue, 13 Apr 2004 14:32:14 -0700 Subject: [LARTC] Bandwith control In-Reply-To: <008d01c4215f$a0b78d10$a8db13ac@gesej.ciasc.gov.br> References: <008d01c4215f$a0b78d10$a8db13ac@gesej.ciasc.gov.br> Message-ID: <407C5C5E.1080008@fatooh.org> cron@odi.com.br wrote: > Hello all, > > I´ve read http://lartc.org/howto/ and now i am just confused, i think my > skills with linux are not very good, so asking for help. > > I have a linux box with two ethernets cards eth0(gateway 1mb) with is > the host for > some sites and emails and eth1(nat interface) with provide internet > acess to other 5 pcs. > > I would like to limit the bandwith 512 k for the eth0 and 512 k for eth1 > however whem there > is free bandwith in eth0 would be nice to eth1 use that bandwith so > users can download fast > as there is bandwith and sites and emails don´t get slow. > > Can someone point some directions? > > Tks > > Angelo HTB is the qdisc you want. http://luxik.cdi.cz/~devik/qos/htb/ -Corey From jasonb@edseek.com Tue Apr 13 21:38:46 2004 From: jasonb@edseek.com (Jason Boxman) Date: Tue, 13 Apr 2004 16:38:46 -0400 Subject: [LARTC] tc does'nt limit the bandwidth! In-Reply-To: <20040413201326.8460.qmail@web20103.mail.yahoo.com> References: <20040413201326.8460.qmail@web20103.mail.yahoo.com> Message-ID: <200404131638.46985.jasonb@edseek.com> On Tuesday 13 April 2004 16:13, segun adesina wrote: > Hi, good people! > > I wanted to limit my 4 customers to 144, 16, 32, and > 32kbps. > I used the following tc commands BUT IT FAILED TO > LIMIT each and everyone of them to its bandwidth. > What am I doing wrong: > > My tc scripts are: > > tc qdisc add dev eth1 root handle 1: htb default 1 > #Classes# > tc class add dev eth1 parent 1: classid 1:1 htb > rate 9bps ceil 9bps #Default ^^^^ 9bps? Shouldn't that be at least 256kbps? > Can anyone help me on how to limit the the bandwidth > to these customers. > Regards. > > Digihall7. > From bugfood-ml@fatooh.org Tue Apr 13 22:26:27 2004 From: bugfood-ml@fatooh.org (Corey Hickey) Date: Tue, 13 Apr 2004 14:26:27 -0700 Subject: [LARTC] tc does'nt limit the bandwidth! In-Reply-To: <20040413201326.8460.qmail@web20103.mail.yahoo.com> References: <20040413201326.8460.qmail@web20103.mail.yahoo.com> Message-ID: <407C5B03.90603@fatooh.org> segun adesina wrote: > Hi, good people! > > I wanted to limit my 4 customers to 144, 16, 32, and > 32kbps. > I used the following tc commands BUT IT FAILED TO > LIMIT each and everyone of them to its bandwidth. > What am I doing wrong: Do you know that tc uses somewhat unconventional abbreviations? kbps means kiloBYTEs per second and kbit means kiloBITs per second. That would really screw up the limiting if you had that mixed up. Read the "Units" secion of the man page. > > My tc scripts are: > > tc qdisc add dev eth1 root handle 1: htb default 1 > #Classes# > tc class add dev eth1 parent 1: classid 1:1 htb > rate 9bps ceil 9bps #Default > tc class add dev eth1 parent 1: classid 1:100 htb > rate 9bps ceil 9bps #ICMP > > > tc class add dev eth1 parent 1: classid 1:5 htb > rate 144kbps ceil 256kbps #customer A This class has a higher ceiling than its rate, which means it is allowed to "borrow" unused bandwidth from the other classes. I don't know if you intended that. > tc class add dev eth1 parent 1: classid 1:101 htb > rate 16kbps ceil 16kbps #customer B > tc class add dev eth1 parent 1: classid 1:111 htb > rate 32kbps ceil 32kbps #customer C > tc class add dev eth1 parent 1: classid 1:121 htb > rate 32kbps ceil 32kbps #customer D > All these classes are operating on eth1, and should restrict bandwidth leaving that interface. If you want to restrict traffic moving in the other direction, you may need a corresponding set of classes. You haven't shown us any of your tc filter commands. If nothing I've said above has helped any, then you probably have to give us more information or we won't be able to find what's wrong. -Corey From roy@xxx.lt Tue Apr 13 23:28:36 2004 From: roy@xxx.lt (Roy) Date: Wed, 14 Apr 2004 01:28:36 +0300 Subject: [LARTC] tc does'nt limit the bandwidth! References: <20040413201326.8460.qmail@web20103.mail.yahoo.com> Message-ID: <00e301c421a6$aae441b0$030aa8c0@t> first you cant use limit of 9 bits /s it is 1 byte /s, so completely unreasonable speed. set it to 50 bytes/s at least another popstential problem that you are using independent root classes for each client that means they wont share bandwitch. customer a will always get 256 kbits and others will get their ceil limit all time. and my suggestion is to NOT touch default or you may have problems if rate = ceil then just specify rate. if you want your clients share bandwitch then you need to create one root class and attach everyone to it. this will look like this: tc qdisc add dev eth1 root handle 1: htb default 1 #Classes# tc class add dev eth1 parent 1: classid 1:5 htb rate 230kbps #root (set rate to 80-90% of link capacity) tc class add dev eth1 parent 1:5 classid 1:100 htb rate 9bps ceil 9bps #ICMP tc class add dev eth1 parent 1:5 classid 1:100 htb rate 144kbps ceil 230kbps #customer A tc class add dev eth1 parent 1:5 classid 1:101 htb rate 16kbps #customer B tc class add dev eth1 parent 1:5 classid 1:111 htb rate 32kbps #customer C tc class add dev eth1 parent 1:5 classid 1:121 htb rate 32kbps #customer D b,c and d will get always and only rate amount of trafic ----- Original Message ----- From: "segun adesina" To: Sent: Tuesday, April 13, 2004 11:13 PM Subject: [LARTC] tc does'nt limit the bandwidth! > > Hi, good people! > > I wanted to limit my 4 customers to 144, 16, 32, and > 32kbps. > I used the following tc commands BUT IT FAILED TO > LIMIT each and everyone of them to its bandwidth. > What am I doing wrong: > > My tc scripts are: > > tc qdisc add dev eth1 root handle 1: htb default 1 > #Classes# > tc class add dev eth1 parent 1: classid 1:1 htb > rate 9bps ceil 9bps #Default > tc class add dev eth1 parent 1: classid 1:100 htb > rate 9bps ceil 9bps #ICMP > > > tc class add dev eth1 parent 1: classid 1:5 htb > rate 144kbps ceil 256kbps #customer A > tc class add dev eth1 parent 1: classid 1:101 htb > rate 16kbps ceil 16kbps #customer B > tc class add dev eth1 parent 1: classid 1:111 htb > rate 32kbps ceil 32kbps #customer C > tc class add dev eth1 parent 1: classid 1:121 htb > rate 32kbps ceil 32kbps #customer D > > Can anyone help me on how to limit the the bandwidth > to these customers. > Regards. > > Digihall7. > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online by April 15th > http://taxes.yahoo.com/filing.html > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From damion@snapgear.com Wed Apr 14 01:27:25 2004 From: damion@snapgear.com (Damion de Soto) Date: Wed, 14 Apr 2004 10:27:25 +1000 Subject: [LARTC] Bandwith control In-Reply-To: <008d01c4215f$a0b78d10$a8db13ac@gesej.ciasc.gov.br> References: <008d01c4215f$a0b78d10$a8db13ac@gesej.ciasc.gov.br> Message-ID: <407C856D.7070704@snapgear.com> Ola Angelo, > I have a linux box with two ethernets cards eth0(gateway 1mb) with is > the host for some sites and emails and eth1(nat interface) with provide internet > acess to other 5 pcs. > > I would like to limit the bandwith 512 k for the eth0 and 512 k for eth1 > however whem there is free bandwith in eth0 would be nice to eth1 use that bandwith so > users can download fast as there is bandwith and sites and emails don´t get slow. You can only shape outbound traffic (going OUT eth1 to LAN clients, or OUT eth0 to the internet). You can police incoming traffic to certain speeds, but it doesn't work as well as shaping, and you can't use as many specific rules. So, you can easily restrict the speed at which LAN users can access the internet. You can also easily restrict the speed at which Internet users access your websites. Use the HTB qdisc for this on eth0 and eth1. To share bandwidth across from eth0 to eth1 starts getting difficult. If you need to restrict bandwidth from the internet to the linux box, and share specified bandwidth from eth1 to eth0, then you might need to use the IMQ device or something. regards, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- From gregoriandres@yahoo.com.ar Wed Apr 14 02:06:08 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Tue, 13 Apr 2004 22:06:08 -0300 Subject: [LARTC] zph / squid syntaxis ? Message-ID: Hi, I've used old ZPH patch under squid 2.4 Stable4 and it works great ! Now I want to patch squid 2.4 stable 5, with new patch, on http://www.it-academy.bg/zph/ I've patched and installed squid 2.5 stable 5 succefully, but I can't get ZPH works. I'm trying with ... $TC class add dev $LANDEV parent 1: classid 1:7 htb rate 1Mbit $TC filter add dev $LANDEV parent 1:0 protocol ip prio 1 u32 \ match ip protocol 0x6 0xff \ match ip tos 0x10 0xff \ flowid 1:7 And SQUID.CONF: zph_tos 0x10 zph_tos_peer off (i've tried with various combinations, but I can't get ZPH works as older version under squid 2.5 stable 4) Have you some idea ? Thank you very much andres From h_abangar@yahoo.com Wed Apr 14 04:03:19 2004 From: h_abangar@yahoo.com (Hamed Abangar) Date: Tue, 13 Apr 2004 20:03:19 -0700 (PDT) Subject: [LARTC] Bandwidth limiting for each computer in subnet Message-ID: <20040414030319.52606.qmail@web11503.mail.yahoo.com> --0-1878192705-1081911799=:52091 Content-Type: multipart/alternative; boundary="0-481489826-1081911799=:52091" --0-481489826-1081911799=:52091 Content-Type: text/plain; charset=us-ascii Note: forwarded message attached. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online by April 15th --0-481489826-1081911799=:52091 Content-Type: text/html; charset=us-ascii


Note: forwarded message attached.

Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th --0-481489826-1081911799=:52091-- --0-1878192705-1081911799=:52091 Content-Type: message/rfc822 X-Apparently-To: h_abangar@yahoo.com via 216.136.172.47; Fri, 09 Apr 2004 05:52:00 -0700 Return-Path: Received: from 213.244.168.210 (EHLO outpost.ds9a.nl) (213.244.168.210) by mta164.mail.scd.yahoo.com with SMTP; Fri, 09 Apr 2004 05:51:51 -0700 Received: from outpost.ds9a.nl (outpost [127.0.0.1]) by outpost.ds9a.nl (Postfix) with ESMTP id 24FBF4419; Fri, 9 Apr 2004 14:51:05 +0200 (CEST) Delivered-To: lartc@outpost.ds9a.nl Received: from web11506.mail.yahoo.com (unknown [127.0.0.2]) by outpost.ds9a.nl (Postfix) with SMTP id 15A8F4106 for ; Fri, 9 Apr 2004 14:50:43 +0200 (CEST) Received: from ([216.136.172.38]) by SpamProxy Received: from [217.218.127.70] by web11506.mail.yahoo.com via HTTP; Fri, 09 Apr 2004 05:44:01 PDT From: Hamed Abangar To: lartc@mailman.ds9a.nl MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-632200798-1081514641=:99178" Subject: [LARTC] Bandwidth limiting for each computer in subnet Sender: lartc-admin@mailman.ds9a.nl Errors-To: lartc-admin@mailman.ds9a.nl X-BeenThere: lartc@mailman.ds9a.nl X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Linux Advanced Routing & Traffic Control list List-Unsubscribe: , List-Archive: Date: Fri, 9 Apr 2004 05:44:01 -0700 (PDT) Content-Length: 1050 --0-632200798-1081514641=:99178 Content-Type: text/plain; charset=us-ascii Dear members I'm new to this list and also new to tc command. I have a subnet with over 30 pc which have ip addresses from 172.16.1.1/16 range.I want that each computer in my subnet can work with internet with maximum 6k for download and maximum 6k for upload.when i run the following tc commands from my bridge the first pc works well but the second pc can not work with 6k and it has an almost dead connection with internet.I think somethings goes wrong because i want that each computer has 6k bandwith no all computer have 6 bandwith togeather...! can any one help me -------------------------------------------------------------------------------------- tc qdisc del dev eth0 root 2>/dev/null tc qdisc del dev eth1 root 2>/dev/null tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8 tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8 tc class add dev eth0 parent 10:0 classid 10:3 cbq \ allot 1514 cell 8 maxburst 20 avpkt 1000 prio 3 \ bandwidth 48Kbit rate 48Kbit weight 1Kbit bounded tc qdisc add dev eth0 parent 10:3 sfq quantum 48Kbit tc filter dev eth0 parent 10:0 protocol ip prio 1 u32 flowid 10:3 \ match ip src 172.16.1.1/16 ---------------------------------------------------------------------------------------- --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-632200798-1081514641=:99178 Content-Type: text/html; charset=us-ascii
Dear members
 
I'm new to this list and also new to tc command.
I have a subnet with over 30 pc which have ip addresses from 172.16.1.1/16 range.I want that each computer in my subnet can work with internet with maximum 6k for download and maximum 6k for upload.when i run the following tc commands from my bridge the first pc works well but the second pc can not work with 6k and it has an almost dead connection with internet.I think somethings goes wrong because i want that each computer has 6k bandwith no all computer have 6 bandwith togeather...!
can any one help me
--------------------------------------------------------------------------------------
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc del dev eth1 root 2>/dev/null
 
tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8
tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8
 
tc class add dev eth0 parent 10:0 classid 10:3 cbq \
        allot 1514 cell 8 maxburst 20 avpkt 1000 prio 3 \
        bandwidth 48Kbit rate 48Kbit weight 1Kbit bounded

tc qdisc add dev eth0 parent 10:3 sfq quantum 48Kbit

tc filter dev eth0 parent 10:0 protocol ip prio 1 u32 flowid 10:3 \
        match ip src 172.16.1.1/16
----------------------------------------------------------------------------------------

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-632200798-1081514641=:99178-- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --0-1878192705-1081911799=:52091-- From ggabor@sopron.hu Wed Apr 14 05:04:26 2004 From: ggabor@sopron.hu (ggabor@sopron.hu) Date: Wed, 14 Apr 2004 09:34:26 +0530 Subject: [LARTC] Weah, hello! :-) Message-ID: ----------mqguicsuidlvnkawvsvk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looking forward for a response :P archive password: 56822 ----------mqguicsuidlvnkawvsvk Content-Type: application/octet-stream; name="Info.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Info.zip" UEsDBAoAAQAAAOBKjjDVsLUpa3QAAF90AAAJAAAAa25oeHQuc2NyGQgTnDQff0igCx+bZZFm shvZsSnYhCygAoWqqtJWaGe1hRj2nqasDXZAWU9A3Su1XeNJW1yO6+ZqbeH+X2Yan+KT8Q3W ZP/TowddYGHPWDtff6Z1Hn/qjhN2kD4tGC6aD5xQE/S6B1vNb/MXdZbFSxu1at9sAG4PlsZ3 PeL9BeaaCLoOGH36gpTATafAua5ffJ+k9RA4tXu9gSP+81m4SAQgS9C3d9Udg6TbQxsu1yCl fBhNnjxDtWfQjAPg5EyJh4csQIMgQFzFcVUGbC2KVqOmCTgPSHuZvF3hpRLBB45RtCLfzr3K cvSel/3L2PUc6pBDUtdL7cpk9zVVfPHD/VYd3siSFKGfAmKy4AoexT/CLmuQvMM1/MbT8NW8 EjhZE21ef8SMd5f9uySowHrc2bmiOVWOQLqbOIzei396PRfmghAuPFHzLpqumLM6iacMO8t5 ZGAxumiG1Jvg3GoyefsLOrfT6G186qHz/gdGGx7YRUQi6VCuZUu/wW1oYTwogzJADkOGhMO1 pYqHyqDOWd4Y/NLVahyFdI0TfjYNlGJqu34fAuyijIuVeZrOpuh/pXzg92nYpd7X2bofYiLm ctU5QfdudTKWh7Mgm/ZEg+fG8aFH9R1w6qfFeaT/+A02BD3fGiCqZ5c7dHFESzrTgJVEEeHr 5hHGlo9aw7xtiaPJXXhmn4NWmqVDMnTDH0juaTVWIMfgjv4r6e44G77wOtsQB4rohXs1UJ+8 1ytNfsytYy7R+driEhzif669of48Ylrqf01Eq8yg4APgLH72FV50xJ1LnAmJrkAMsTCzrIxC leGtj5OQusBz0K1Px2kSd62Chc/e0it/Dk5efXyuEghtbis5ZEIC3nrqg+ckhoQm3a0n81J7 NsCIz+7kT9Xr1IbuG0mPHkwFf3uCgrmrripZBTEh5dTr1AiJkgb5q/FvIX9l3GpUixif5rkM H2tYS5Ou98YpevdhE2gDTNkCOMfABtqzSe00d6e1NcUv+x/v7YDlKrENk+iC5SrCq8jtcFo9 sqWUbI1S9EA85kq4VwhXcm2JZ8pV9FpOLHpMtP2XHAfcQbruMnTk9hUaY5Zx6Aw1EBYNvKuk ccGmGrPaDQUOy+5BE4cXr3xuDromH9YwA2Xa9gnSIpOGkGGMrnndczGtsu8/XYeusK6yYfy2 gEjKVNEzlGlnzawNZa0JOxhr045mjQsCopqaHd8E4apXRQQm+eI+snFYxg/YysBejFeXI7Hz YLS2rJvBqY+V0TWWbF4Kb8Vr9nGQ4lKUVk5691DytYm6oG5IIc7ZK8eq/CD4vebbMndaLXsZ MS1dzGsiUxqMngU53zVa1/uwzkLg+hZy41aVqvWPi1f2g++GqeCjewCDSsEXSGCCSZIq5MnB VGRqiyxaMXi1XNpCQEVE2Pi0GPSDGMKygGqY5kxEjsprx9F4HG2hag77LQPFCF/tqqkNlJ4r nvU3PdSj11TmWh5+9Aeblbe6V3mrp9GCiwLBq5n07N6hJ1YQQROFA1Q/IbIEAehMBw6640hK cfoLjveoPQf20tCE4aRCQbrnH8Va9nZZpeegSev/XMKbNrZwkVtJAYshzm2RyBSVH/TRSJah IQFumJIPt0zQg81MP80tDcoBksogjxKS+rqgL8mUVHg6B49SKDtpxNsOs5p6KA9DkXaw0XBy k9kiPT/UDIL/jIutVEnOFNSIlOTHU0bPAVc9zhxJnCQgyPIDAR4ZF+uN1f1kdFKyGq5KVYc8 8G/3dP9lK6uYOodshlssk4YdqImu/t1Pe+7xSgO35WsI6o3XTMgJg3LrSqmzjNXmwUwORHIE MfjQy08Fg++C1FzTaGoHMY7DKUDDBN1ZUPBNxdFlzoK0P/SoTvQUsliPceqqlKewFsIZuuKP uhJ8pFUWnKDVkSGjPgLiNkjlu+UOFGL2vKTJvQVHgjmaD1kX5c1ZSHpM8Q7+Q6whpAIweT69 zuH2N/VKsYRlA/fD0YriG4EUgSPh3qTHwLaKM9+Sr8iREP+AeDHJ+VNMq4hBo4sgHL6IsMdu JX1zsNcR/J2AbmY0Ox1OyWNbNZEbXB/2F4YVm4/ytblCNLfSbCn9lZCE0t09c7Nt4IXdTLwL fTIfFKcYkP5P1OQycszUQNWdnUxNayglmhliHCHE6bvoYqI7zZyIz08/gGm0VIbeQya73pjc 4jv75qhvu89hZKIr8GLu80Rlkh85/huSyJqGYmonzkVOxHafqh37P9tmkGvAc37gu47pyFsM kvl+Q9ZazKBihE8TsKPIHSMmyS5jst3eW88rSspCwg3SqAzbzZBt5DEQzvsL/oE6dn2G2eFE EsSB5PdSF2c2KkjhPOqfL/R4vuTyCSU8QNCS0Rneiqh0Y8ruv5ScSajYGDdPkuSyDhV3pl+j Uur816Ub3Kldr5kWFSopKQVmisbD5ZSTmGUKVVR24+2A5P4bp2mMO4WENX5i7iJRJ1KlxgPr 7L+hxzpk/ltp9vN4x2JSkunkmg/lBuKSU4cURlnR5EUbZwLJC8yxjv0tvG7D4pBNGzojVLWS zGHLhbWofxbZvEq/B1JhXqghE7Yt+d/ZyF6rMYYn1eOVSdwUWB7RumFPfSpNLUaQm3NMZpPa Vu84hldt6QU6ciRRhNpObakxFjgDymLa30zqnOuyye5iVdxdSPxaWDJUanDN8LLxmtzs2UBU aB8lUQ+jCzSjctqvjrEX9BwiKFPkRWSZ1X4RauepHgNaoeArLIldeljXyjMN/qQb0eZCYfSi agMIXRo2DIdBQTpsD0oZPDv3P3yEuDcMmmGlBQQ14o/OMJamj3T9xc1TTKNDr3w8MlmugI2h RTCvsPflTbX35b+Zj75esX4/82QqBA53fwxuh/7diSsGQ4ZHU74y0VgeDoeOXvbLsBf8j7JP D11lMDnl9II8fmmRViFcGzZh6IMWrTexKC5+VP0eTh+8KK4aAz2A3kh/8nJtO47O+6MQBMWF C5LdNLHHCr9MSUTYx9DHxgSsGMQucLh2QAHTNPt2gftNFo72LT7rYZrFV4caCIUbgWwOf2+J 4BtfMQPxWwmzwGpBTgwbWCoQcgkXgntJar+CubcGFs69Sd+pGlshMzxkGEHqzXll6uM9/qUL rPxohAJ0MSAttN4SrEykuP10BtHMy/k5LEBVtOuS3BGmCwW02JE/p7wudPZYZjgoMLHW+2NA EH8CZDxyh1qnQi1ewiiSLWmbNabSR1TNJ+u/dli2WMpOjdFxD3LWPazHmm18/w+N66LXDxQQ QULZlV5zFN6uPCjIkcU5see58djnkLlGE1evYg2pEPuoORxeuwjxYZWHiFnT6T34YceD3GhL KD/ux9Ie5K5mvkXbIo/QS+3/MSMpEbCB/H5/fe1SCqr1lSxw1o9lsshI/t9Z1aTcrmZWMd9w yAyfAUmfSXrf5VbTFlJgsCeuvHh9k2veEYyGA8gNAhGMkVlur35ercqa1vbnsKA7txjSWXwF hGYsZ8I9VPKKkG7QRiqVH1UbAjmbab9Hk0kUDZw2VTwAfdNMeBSCKuQoim9gxlsv4zWbUpcl hx4CtVkbK2Sp/ROqGu30jKPvZv0GWVCJLUXSKLS+sn/udoj/G8H84KOBGjSXl51j4gjPiqkc 8c5Udhv8USTL9NF3+JUH6k/6UeIaCS3PH/xGRwBlCdzxNktyZTUss/HQ/RAhvGL8xIi3u1iD A31JTC8t3TgGqvQCYiSgq8yGHDXHrvErRg5+yZbc5KQ3owLx+2nOhLyrvidGZfqMw++FSoGe zfcSHbU6LrdFR2eQmK+TCK+JOX2dOFgFhSgUv2A9+3tahod4J8+Z80I3sKXhkWiop3h060jz cleG4T7bbagm4b7vpCdAjwuw16ddkXX/Fh7yDHvMDivZbV2WRByrXedTivi1Mi1vQb9SRtIL Oq6BPXCD+qWt2O5lNox0dQeGEmITxJXN5RjkMWzFG/JJTs3QuqNWLF3odFtTa7J6IJOlvXBb 2gRcy1V50bsCW9kScVLFVcRzixQbZ3RSBc0GukHntBDAydBgsNeSX5/s2l4TcWrzJBg7jMMJ 4J10wMfPFs5i1izXaTXFibg9dSYKuHoaw9A/G+LwF/iRvnKV1HwoEjW99LM2wfNn2ryQavCm 2Po+7qPYXnFWXYMRsoc5X9LbP3r3VQGH9QeFMV51qI5zH51u+uWE/a6ph8OHbxS7STuBuBT0 3QmKMfrGUl24goSkKnTwTKAlqVifNasnFVqSCVNZIkhUNo+BkkDx34i/bR7/yPn+hbwwxbQo MPpDvpqr2RCzuBP9rR4egsIKRgYlmbijL2uQoujRUe/U3oarOOuViEVAJ/zzacyi1uGs5RBE LGFVOqVipAqbamV3ZpQu34o77c3f0U0yecE7DfBmG1lIKpNLEJuj3c5Y6HAQRh6Q7MHafHg7 ly8gGnzNXHbTqVsTQKu1gVKqHk26cXbEio9IuQWRr8Xz+GcVahUWXerkFi2GbhdEeA97NkBm f6+1MoRnKLyU0WR8m3oHpe4CMuPLkZDovEM8Kqexsc5T/4VDky49ZfHLxCqSD1JiyYMHs7nt ZppN695NBR8PTL+aOFYeDS03Na/fISHVYRyf2U7bNpW2LeOZtc/ztrSdhkfDOMwCDg7myv+P 6OGFoU58iTdvqQtqC9aEcpT146U/zzE00JnQcf4vMtdsb/eNZos6o+wrWc6aRdcOwuDrw4c+ r+TdZRj5cDbzQPsRHlLW0LdU9B90pPsX1o/s04GJ4r7AuEwJZo9oUh0gfvPUkgMRlRTF5bdA mWDXK3QATCmN3kl+4Pj7C0wFWmmLqDu8kBtg4E1JXe9Bt8E396J0HK2nUKcO+Gx8TGBg3TlO skI6Qg4+wm1WC8JbU4X8pshuZqXVGm6Tv+QfqnLipX0YJJomuXqaSzjIBtFSerJ2pm79rLDW RxB83LPqEpOQR3J6bhcT1kdYQyeXhgHLmLZg+P/EkOOa+kgY/m4uP+m8NreYgjvQ5w6tLgZY l7IvYNM6Yu9IKvcrx/nZUdnOufqmDVlF3kMpHqFS0DlmEstRURgv5zZKln+VnziiZddF3A3g +KrXdPEH7p9p1RE3j9ABRPq7u6/LOpuS5ut8I6YyNP055nOfLvAAZGm212UMnlDnajRmbSUI rBioRtFR6yhGK6flrLMByUBd1OeT+5fjOnpCMj1z9i1TH85teHWn62uubGf8HaZbH0LPcywe gf0nS7lwAUQ9tIPmNzeNeJPdXVWfWL5fhoBxQ8QIFgjjYrogypGInry5KEZMuFFoeVsXGSGA zuUto4auD7rfBUs5Wnf/BzWDDW6xkctSTzaUBPv4jzQgitHXklMaeozk5tOrbDq+jEZ40ZfZ ZbbZutOz/qB0agIC3a6YBJn/DvaSfy0DvUe7PqR/9ZUw/5i1ZN74AT5ALJHKFMosChAT82oq Y+rvsA6fy1RGmDJCdUOzu0lKf1HBm/qysxgaQwE7F41lz3vLFF3Ni3n6AVz/3JzoJivVD6Cu WRCU6ZfevqWkUwsWb6WDw6AtD53aCQaUjwJkpPQV1IOjN1S8NO+I0GiBMJRXiwfQ09qAlzTc efmMWTLZVO5jm7lpGsR4n+/rSiBhSukywCZwJKdgMntRcIbJ63NQZ6oJy6veeAwpkPeJHfee 1rsFd9pCzOxuRSw7hg5Dspm1S+gJM2B1ppsaAn9rF/gPvOS71WFs1IGWcFbrpHzJhIxJiMXQ npY5BZY05RddeiDsNz0Mh7P/2Z37VrtB1Z6QNr960sslviyXJPK/OLlPgSSZeONFXAb/baXQ uzGlXmmfXEt7PEYTNA6xUaIsaGmK8DkGSuClbc1HMEMWavFCChnhHX2uVnpnU1+BY+RGJ+Ra OhEVYdR9yqsv2fowTuKatxUHqkhEfkak9YK3DoxbrpQQdOZrRVZL4+yBw6ZoUUqH3y8sFUaz IAFQ2dJtD0DNDLP5CbX93Nzlh12DjeZU99cbECMGWezlqVKo8KICIvngXjSa+s/v3Im1lGxY NtFdVJMaCHmIkcLu5qZTjxoY/YN19X+G9d3nPyhuc0MYx9ceiozc4MQiuLRT2h77d1AE6hQN HnGgHH0SYA0r35ozYgYusrbBrzBVknCLK6SrT/pqtzLy46wtFuNVpJuR+n/Ig9eV5RYEJroO /Ff7mjo9dgCDJAeD+mPrDTHoqanzYZgypG/1Nvh+/BFVVpiNQ1Y6sBveI6MTgSya6sjp5GdG ANDrJgi2ws0z037w62VM6UqwFLGz7m2sB1hHSqXl0JdStiZqkmpJg3MzSJUqu+Rs8drtCBZh U/zY/ScQ6c7cK4sToocbyh6HyR3wQJ2FCZ6dhDmkS6jXxOy3mRxibgqxTMANDN4+d6t28qrj zoFLFMfdPqUmu2zPWeHFVeDv0DmmgbaDykgNnCcy7yfrkj40dVuEf5wKuQ5PWkyWRknrxw7N Q9Ww+z6A1dBX+62jQHjc0z/OltrnYc3tHMdQ0uQJ3JkHxYKnZM4TtVmN2iranX70zs6c7stD MOby6w4QccGMi7d68Ifpx//QZWdQnuM1zSQEmdBItlOveB8AWVON7F9t+vD7PJlCIlmt0SzB rbS3EgOxaDgVe1FMv+8rxU1QfquObToWs8IrMYinQvycnekOGIBj+Ld2oO2n2teH/f6+ZDcH d6x80/rnvmnKojX4ROX+yJPFogAl0O7yHsDBO8btkQsj+RpDEppRg7d8O4c2e+klZ265pUQo zhbJPRIc6C88/KqCMewZ0MIBCXVteKrPxTGSLOsNJiVA8F/U4NNegJN7xaUu3Izy8aKcf+tr zzR4MXa1SleozV+JKb22oKh6OB/pNTgxOiQrJH1cUg/Hy4HW++YKQH7+xda7xnp9XeqKxlxh jdNx7SqHKeQYoRvZdBNOo6z4jXcvZrBUlUqXO+ak0XulWhgFJVfKl9ww2eA4mFZSjYJk9d4m B3gMvNYpyi/EKpIlPyucnKHO/sYwrrZF+HZdC+8Yomty7f0cWmLIdValLhs1F4r4IsSLTkFp Lx4cK2GpBZ1hIwjh+fPVgmdTQql/jyyx/+5/Q5SLlojglwvNpKClsb66FUJ5L3lXzQ3kj8n/ mDxpC09g6OZUwNgVNR8EzS2sVrNEQztjo/JVwSpzq2dQbTvD6TU6gF8tT2BLBmRENHby99xE DUTttx9rmv6yhx7uxmyBeRsgfHHcEIu1fKxFaFM9bLZswGenD40QOje7YOzATgvQHHq1ZiRU 6QT00DUwoYgIAAM/38oeBjLUtdbWI+XSLtnRq38URNs2N9qD8dxVaEU4UsJRna+GgTr0NYzA MVZmhHs4n/dv43IelR5q0ODgjNm5vhdLuKl53yv5ruMChN+Cmi5MYM8qytTYOnNf/t4WM+ZU Ta9d4hLa3jhANjT9BlqmyPJfk3mDKq5QXFgt3yBO5zNNCl/bcOTezAk+bSNTesWqprSz0G67 WD4QoRalKmLjSLIr4A5jUo2eL24s/EA1IDT6bu0EkUdD+MpiTvULRT1TjcOQU4pXtDsJONcZ 8Ia+GX+kNiOqFz2xIQ36bhdPLFSBk6/tdIz4KmYq5vv3vRQxhMnxafmzTihoOJg+iCviDZrm oa/SynJZ8AMJycjN8pfwX0UjOYCywULL6ilmlWO8RkJ4DiY0EglsvmS3z8mHUM6ToZ6ZTgNY YutmrHN8gIDKbseyR+MtuzW69gaBCebdlQWgMsX3oNXyIwrIkyv8U6Nez9GxLnWMYAjceH4F Fw//uZNtMsiK24sgtQ2M9NCbA+5T3qtTFVZx7dzxUNi0gpd36SWN5g4ioNErM4g5ey/c0EBW jgNcyuV+lfAp3nMyBhDuWnGr84bmyyIhPcu2w3HKXA/FK5b+cQNPw2MQAUcwZSwxBQ8MVsug CBW9Lt1PywqKoPXE+GCUmsqjgUvJyt0Ni5GQe88TURsAwvIubj8kmtGOwczdaj2nYyRQRm6e fv5/QfzrNpF1f3R9K15E4Rw18wnZ97jbMPOR9sJHuccCuQxiXrDKzofSoJRaIuwo9JQ1t0MT oeTO5a4MlIL3EUOxF5AWk5+6ay2PpVfPXGx6W03R+94UoUd2nUtYSJiuAqORVivwrd+fCyLX qZN4CAS2JFiGHoX76OeU0E8m1NQcz6dPLgUILqSFCZbYxebsYrNzp+8rWRqqD0I6XbNzQIhY eIdZp5q6tjCy0tnGbunoeO7cz3hrv2dPzewKCCczBgXHJYLCrhn3PX2sjLmXPGew8wq2AO0l jC5K9vqvmZ2Fht1DymyK7NkAyrQjavdyFW505aRPO36qI9vnN7LRXYwmTm/4ituOye5+r50l S7kAsILVJ7rp2DIptpoi04zTl/tYXf3WXmpsPEx6XpGY62jcsJ3QSXttEDW+9bvoWCmX3TGS rWvAPG+h1jvJ8VmaEpqTAu5P8GLcZxgXSCulKcNT49+qmwP+4WBYVpXhfUR6AvPiVS9CLBnR mAtxdT2ykseKpNcc6378cgzt6LnKOIeWbsV4U/JuYak8J8UFyTjHK/bcutH5nNVwu6AY56WB 1SEbMHrBDS3yE2Y4e1kaScT4HgzJwLUroOnWNjZ5DVR4Ya+Gexp5O7/KoB/36TXAzl0WtOU/ 2lUO2z2Z3B6pnj7kbyNSacFQICC2y4tNaMIalWmleEID91qs2oxGwOjdDostN2GpdDcY3pSB r9WKgzIlGVXKSK5em4XaWIf3m+wiwXzxgOKTNp6IM+e2pHju36ZSy8t/B860fQeYxMMKJfUt T+L5OJiuu2HTbbELIXsT623AG2FUxaccDVTVbkPl3PwqAt3SHXBMiAUX7bdicY3Afk/h2DgH 4ONHKJ37Jim5Hp1SqzNlfOATun8fqUoTFL6Nr4X5v+9ocF7VhJrhiC5qlZoOu7Tax1dpBhvs 4rT9I9BKhamZ9sSKjWWkOcK/5NpPWIGdO8BInJJvy3srwQx7oIgiEMw8H3jeVFr3f+ID33i4 W9eZM5n7ih3A3lggm6HGgsbhSzLCp5zcrOm0Zw0CxXwwmzMaArHIo2OXJOP/bfAegoHKZNKM lW3rE8B1++YW1fMVCg057bpdj85ov/vHZS7YjbDaaRsIUZMBWBxdTW+6a0ppDMwwTCQtFjzU 67sKds/5GbieQtuw2t1vtxZL8+effhoGeLCiqGNfJUu+sUQxny7QVnptfkhmQ7xlbiPylkBI l8cniYjsJGp+MuzvR4iCIpPmMgVsCZN0nQaY9odMUFwhnSChelwID5K2+kcHYtjRHf0ury1f 9ETG1Qx7zfqlh174K/kvCZTDHmRlJQ9FnrEMjAE6HgWarZZJ+kwZ0gF/dbUKs1NdrrRSt6y2 KBYQYyg4ziehi2XDGU3UhZD336D/54eaG4IX/EHiNdtNGyMyQgsCQTkWGdIdhf81cNdvWO0o +TA9kbgaI3bwqTw0CiQ5YP/h2Z5Cqb9g1hrJ/lvsrD2X8X7ASkUKMkio0kHbmcHRRLEBBLsQ YLhoEz+mKdxvDuAqdA8lZHFzUErgSNvGWVXcuMqJI0vfeaBW2IKOgXsVWuc2LRrrg7ISP6e8 LuD53zc0UQx8PSqjLxcxuE5B4HZDPUxJV8cpsTcHybV+VGC4nTiyvnIIKAm4zmWJFP78WQ5/ UWONLB7U86VsSIPPHAjmEYSJlP+Xvi9oWGRIJ8SOdvRDrqvJA8kZX5oI4fjbyKQPOcHquc1r pTZqiabmOGb9oJuLWBxGOGSTj9Yghj7CSg7AWD0AW5KJwoldU71GOayONNV6IQCceydNKmcu x5lGgMLWHJOfVA/qzIeW7V8z/i+OyoNb8+ND2Si81vS8bESnoaa1hJSkJzOLcvyPLdFgZFyQ Dw2NKwlBXuFTQozeYXVR2wTDdJk690OKANmlYMKrvCmxH2+CljC4tKFhVQTf+21485bGuF36 7GDzqBCbTtqO45dOPVh8ss/6VyNgZFKq/31azdD5nuqmCJ0T5LzyCqQ5l1nSl9DHvtt++GtC m8TiGoXsYducyK/hqL52M/x+8cSakGiCKCRL4q2psLg5gC2zJLx18h44NiHb1OUZK4JFQ9LO e6LHhn4/8+d3org2SH56XrqYC5OcBveeXwSzOObwZBZ3EuEz0XSG2A/5Et5z+Qci8Fa9vXzh t7L8fzvTKhJqGVOEt+FdEVlJWXLi+M/eh+HCk6XuTNVyQC0fudBO0GiwbW6+WqgJN5GNJQ4+ +uipNztkcIgGnZCb+S3bu84t9pQFTYbYtJCFUca37xiMcxtEcFJK0O5Xu00SlnbvF8ZreNOl MNAj59TmpLm2S5FbYmsaZOFRR4BSTDZPJJ2tdMyc2LOrurqfFFG1mVZXXrvhqhclOREVW+aQ lJRpjf3Atu16mn+lCks177miUvdpm8TfCC5eqNN8KpqwcSVhXf0pCBKz0j5RmyWKBrS7VJ4Q B4ALo9ShLjPFL4gr+KlgCM6UhcQPx02dm2/UGB2mjbQxlw93epP2Bt1gpmEcQfII4aCBnXdc E5sY/vrmwmyNZacIhTW6f0Qxqf99rpkHhU1X0R0ujdEltMyN/nhCXnztwa3/R4Zd1sMuFtPB nCXbrGjn9kQShkAaauSg+SP+UD23UkGb/g8hAAz8sRjoRqrMM2FGTijkL9ni+nBcEBKCd4xx mlYN2SKkd/vHMJe4G9uk1a/uj8wOh8RIxD8uzA69E4Te24QCBciDgs027krPHG7SEqtYorns wCTKaEsB7K81H8CeIvvuwDXBw3Gdj1ywg9Ht7KYrRXyQgeoUeybkMNDWGxexsJXcJQEUcJuW Hr/vjmFUGXZrkvWDx4dFlIaRJmYj5X1buVkwwrc9+ZkZwO5k+lztjlpjcsuSM9Luv0BteEd+ Z4jkc5Y08sX1rFPk5Pn7a8Zwrpo5VKpURGpkaFnSUe4FDIO+nJZ9YKNWmlA7oYSGXIWEDGwN MVdlCGH70uihkRGmKUDg+TKsSFxzSnLr7/isbTHR8n/VrVC/loSybHR+AOMlDRJO2JAhXVJP Ir7ehCx6fhcuVDX8bzbxSomVX8dgq/gT7VQq3Gu90v+l1OVqXXQBnK8CmmKFa6rtfF34VGFH lXwf6rIAAYCk9eKTlqeDVGsTNkymXg8Kr6Z7UdhoPJw1vlarzcatsjsmGESn8nWRdpFmUebx xSe0zS+GThthKBvwa49HxVwka8qh+DsVvuwFRvAC/qtvgYfaRFOo3wIWDYbMP6m/P+SovEX+ 6lz3KDKB+vzmCaZisjU2GBlFMnL+VrPn1xMeJxJekkmLQpqW3drFTvrBW4iz4ZbH8mdbOxEh Gj+kOcP1FX9INLpsh9i8I8kbX1WrZngcuoatK3yF0QAfIMXJzt8OfCwn0BMzALia40G3fNum t8ZpU0+ngAk/Yk//MWFHn6/6y/uaTIdIxY2WEXke7/FcezJsO+B6gKWXAlLlbov5WcVPZN0/ op6uvm52LxafF2LMhIuNkkMILIxazd3o5Dc+to+tUmlcIsMJlm1zgt/J3m6WY3fVVURNF9/a Gqzb36QM/WU5F76uaKP6tg+ihOXToq7twmB7wq1ryo3efo3ymkMCQY9FsR0rI3IuKlKOKkKd //aGoznZ4yB2qEFSX67WYMmGBNDeq1lHQ0a4HYEOuDDtgm23pufmvIBVQBu7ypP7sNa8Iw2b HVehH/JqHBN3gX23tbUE7t69AV0PhV+unBbhT68wYlAHlpg0TH/TEQX0XILjhzrRHhpLctBl AefDWLtU/2OcLKRYQkCs6+z3j+W+3zFaLoRLZqBsK4pra2gExis6uVOWMrfxS9DHzz+2bkta zunUlY0hRfY37+rJ8PDxEEiGIQxrxualzmKXsUfNWMkJLDl6ETeTxDdaU3cE69Z5O8jF5vJc b9Saxf28ewmBeGPTCs23M9gGwG2BTpHUNlwplClBkopg88FE1lzg54M1t9fo8XYyBRi/xGso GCDJDttQBHhs5FkK2Nj5a7AVIOpfTgCHqRrJ2e+mwNF7QB+QBApjGpEr+lUz5BVAO+rBg7Sl gJk2YmCR3tuL6ht4LWrxHVYzp+Zp2EfrBOVmM4d76ItIFPnrT2uFhfQ9FyTfgjKw/vkFi9Ws Lz2BhO+pKGw7xUO4IKblqg5apde+IP56iHt+VqfRbLFGsL6W7TBM0BvYndmAuBC0BO3oh3tc c2J1Pq4ozRiFCg89Xj6AQSt/Y9EiSKA8qNyoEOIqzjNuLs2TT0zSXuG1++Zy2++/dSoyEJbN ef0VNw5nxxvc0QYJnEbXTJo9ZlFoPCKFTPVGHAwyFiy26TVPaTb5NrxwR3lxPl3IIXShCqKF aTUEblf82qaYIoXGaz0XgyFiqbwXuyM25K+LW/x4HyzvpaQl4zZGzhO7tZaOtJ6pXbirV6pM n06ktaCLAlPMtpOvjAslTCie0GDy0oGE/Abbrs9GmY6TRIoBSehnf/yE4+bnoKcZWQg4cT3w xaB7R8TSMtwls3vlNBuFaZ5DvmW22BPYMmmtL9y8XDdRZz12A46L0pJn7UDm+CP85xqMc9Td zUrznbnXnL4W2xRL54bnUvxSUEVAia9SYVBvvBqUvliVHrO7BQSAzGQJ/IgpQDCHTxseTgUW OrE8rk5RbUT2D28EbPIjVokVJqIIEl2lgYlkPyh7RJaRv3h83tcX6OLZ06EaOYoznWSu2+wc IVbSMUI+ESIha7CF11N/mr8328od4qVgLuM3y9E92j2JzkSEO3kkXFsqvew7KEyh3Bgx5OBR XQZRn2YxoskO/quKWPjUrwWGATfeCyJJh8Jk6TM/E9i/7Dchgzq99r1CecB8+e8VFhqHZA4r W5HujegH7AP5LyLm4TLdeC2Hy7/ozemWVwiLJO0SzBA1GN1tiDp4+h3DbVkSftI465b+brAe 29SFYoB1LU3Rhs9gc8Jpy/fPxTygwDVcpHtmw+ukmu09VpFppfHFfR64oG+8owSWYXWQzUys do0Fdq85Di+keXX+uI+Kn/enGTVdRaCbiHYH8YWeWzjmJ5/9mkIrkfsKVog54EazCGIGF6jZ Ejmusl31Btfw8L0L0xY0gVHECtDXDQSoYGU01tSlGoCyGuHlxOV94jSBd8fEJnXHPCNcmOKD CT/G48QoWzok0njaD+MAAiW8uFDZshh+2ZNSOq5CMZw/gKOFMxREN2hhnV+DrROl6YFbIJHV cHqQdTzpsR1gW9810IyJy6QsE/g8Z/ud18Qosii22Z6YZd4IDu3l/348iFlv4c6p5gJzjs0B ue6+3WoAKpUiPVu8brY/GW0RDDm7nFOGC2r86bkJ1RnImH9rpa3FrYgywBRWFVEj6Y/fL4gM QGjJYJL2hZbTPk6qCjtiIMu1QN6RUa8PFGN9ddUZtAPmwMys9YGjdohE7gJIXIHjDQyIfliN zUweQWo16nwOpUmGtWW3YvdUL2G26Gi+KzGyCECGjsqm93alvNgnKcr8mn/m7IYg3kEntGos AeiRyqmdJEAmTP/M8LIm56GaR7wpDkkcQ4ZUdJT9wA/2jOrxLjSIZBxeFLROUviT9hXIgJe9 6nv6fOZsDj5bs0DJrsNFLXJA2X6u0YsfB1iAzJt8In0pEfp5GMjCmTl8zmqww+llrptdtGuz SK/tAthOMBY4nTPNp5N41wOYucFDOEv9Y7BbPYeWBCUIjl5CmWFRm+u947YPW+Wjx3NUjs1/ 6fyiCbG9iKNDAh9QAGU+7k7OJl7h4XQsNXZ40+NLa0gLk7YRMPiJq5Vh+8cF9BEok9o0o7qS Bsb2TrNpMoN2VWhOf54TEe0OLBT7Jl5nAY0BbvQd+aK5t8VOWSmmnVLDs+IdGfL2W1ZW6gUC tCvf5rrjzsto4P56iFOSekx1pXiycKqZ/Bs4lF+umhx0yglBiYifh9X6xtl3o5Nj8ghoPTbM iIMFHh3sinSgXH1dXxsSX7ApntpdDvRzFk0f5RvNgMnC8p4hFwQd41w+oGg+UmuT2zPsQFE/ QEATKfh2NJA5BJPNy/E3kuDyGYqZK/gnSBCjFyz8r8FbrR1L2sxI+5f1h6ET9OYELStxTzzw xSK+JMpuP6vW7EiAEnCdI7zHT021k4pIB/ldU8uwpGHNR7vE36wHB3QoBPIF5LGeJ4sQ5AWa 7znvltVu/+2FS2A67WYKXVrO+jV006NoR/pcOE+KCefWd0j5UO6fl9v1qUWdbupihtlKgHs1 e0gvkjSbPc3MzNbrpU4p9npXsa2F7fzZX25CmlZnv07UIsGlgjV6vdZ2vVHAzVuzRSxSniz8 1/Dx6QJ5WjBgob2v9QN7bt2EdbIP1Exw4ALMrFiUQxEKfjcYKOGHSuA1liL5FGarP5Jx/tqk cIHvGuOVDIQrnyaxYkPx35tKipCytngtoPD7K90DS2p+dhefdmKtFmfHowqP4io129KlCNwV r721PLRYuTQlG9+QCoaK0c/4PuI3RJv51FOEXpPNeTMqWxY+mf7PnPJe00rjzzj4gevJDYhh wXIHjtsbMrGGe5z6NMyHPKn6jT09zDY8sYaIhsQPUc/k8DFK45/P3JsKOVrbBA+1gKDz1NzK 8YL49eznfVUqBCu372cRdFZnlUfOFaOQrTYAILkiyWvnkXUVnEDWiiKSMAiSSW0UODLQmyuj u57vurmiG2s3k5tEHh7mixw39YcZy2weYRCFkPG3S00ez6VapDHNxe9b0Kd/LTzVfI9ShrDU jJLR1CcuwloDk1bHIBHuOOOMtzUgklNG2NYhpYmFUjMuibjeqFVJ7aeE5g2BdjJewJH2XQ8B OB/FIlnwpy1YzJFN/QsJoXe0aflycDVqr83oZaY/ULZatUw5Ztx6gwb4fKOuoHfJ8c3KXiPx 451d36qx5KoEzDinkMm67DH12Wu7vFidAwZDBDWiYhRmRS+6G1sIPC2Y2QUQQ3R/3MqVqgVl n7dxSEGLqlCry8Y3bhkv5b69Ab92hxbZFXxZE0sr6VKE0fXqg3dXNo6KJvdxnH/BVW8VQ1he Qp0ILLPeN8NSO/XUE41+ycCzJig7+UeKHQSLrnMWU4GcZ1xGoA1a4UiF3mo+65h8pClqXUSP 8lT6qesXillH7q2/4dIswygYyo2w6p5F31mEU9Y4i3ueHyqK0/4UTe/XNIMqNtE3bU7fKYTB KihHqjHt/DvV+byt8SUgCm4VOIV9JzowhExlGiqxK86UwO6SaZeExRB5XxfNsfa7oc/tkW/k fzlzdrCYksFVH6UbG1x5SPDLlDkRSLNsCLmyJJjK6KeTBkxVQbrbEpaQZSxA1jErH7/D34o5 8qf46jPjXaYoyV1rjFVnsKhpSShkFmV/TYfkA0G8i7tDh+VaYem1bSfLkTtATmqj3WU33fWh kN2HPAoOik9Cdx13hrKMzsnVNE+Lig6JJWFHRp/g9mcCsYSkJFXWqxJkLIwdRYQx4+CffwcZ HZTA+VL0CFpYEdBCKEbW91Chcc5t2qn/16r3wvBpTVK1crst+YL4oM+kjUX7ZkrUCwYkyJrh sXvrZ0UBdFXWdHjC29DKOVFVZtzNR3Xf2az/w052dNKbs+pc5xcfsW1k7rsxMMY1LtdSEuTI 5ND08Ttmw3P3SfXWOdJm4ofGm9s2iqAd/gh57ZmIP0eiPA4gNOjWJTlnvEwmOSjKAM/6JK7V QHLbpVM0jUSYpDNZ5AMf6sQta1zrY/gB8RLg739ggjdqRl11sUxz1IoSnzqCljgut5McFk59 pHaUQ/dHQISiMZnK5Y1R/y09Lm2GYg8lrk6hNgtQYq+DmTjx911QPjqz6JFwQFn5U2QfAYFG Ipx5kEuxqBFFF86Rw0MShpPzW7GHawR4FN945OA0mmGEjI8IR7raNi/XJbnwiy/1mpaGnF8k 3sz+ZQml34BdiEuHd2tYFXrwQxC3Yrfq2KkecWBMRQc5xtf6/SGlNSzFNwlabXy79pjiqvK5 hRuK4UjjKrk2Ht6dNeTMwSbC9RvZ8r/O61W6Ahyk0IO8Cz2wkzg0K8HQS+B/1Gyn96u1BK+6 iLJSE5jdHr3sTIFjNlWkDfE3OtSuIvrXIVuuVIFmSYQ/DyXqJKlVMbyJe4MLSRtjuyltQHQQ TkZ6heItLwiiYqKB53IlRi7e99slrZG6JBUQ9Ij/zIb+Q3HRVgfr7d52V/MsP48CVozIDgzI negpWaPNrLQMmN9gErT2miKyugTTPbyY59jfiR+wvw12LEUc3Pe+MQtKhaKu/lHxHaSW6OhJ P1z0M+2/zuhk3eZWnOzGcMttPxHLqki7NI+U3QRFm3n8tyxs9DzuuVeBBFAT3VkXESOy6OjL kZOAiHN87/hA2di1Pk4Q4CTqtW8o59vbdyjw/Lef4Edswd1cx/SZvzvjcl308G0crJFu6zRm 3oYftNUBxPvzSbYxipjweNAtIkKOlAj/4Vm6iOwmyteZwwYwXCgbcZlcX0LF/0MRzfqva5sC 6SvFZDOr/2yo1iiq3B1DbUZb5rzfDS41XOye7OxIVohftu50jLx4Hh769HsUxbJC0YpLw5jP +3BUmtXXVmjs56SOEHmoX9goGGUVRIpA6ijdZerNQoOGSBTzT4w/ORjHExOOyS6WIoedo4ii fDJTU/aaqgQ2G/Rb+b4pWFx1KH+qN8kaCjfpIeswLXcI6+pJaCxCwMvgUK2qDkFCQ0dkxn91 /xy5Yp8+/jLU7dwz/P51NvCkswT/eDiNWvwIRzewMz+I0Uo+AqZQpfa2OG0aMrSdnuIrqGIq Se5u5JT7du6glfNWPJepu5yy5gFz+KZzw2qnYkW5kyxBhovfyQMNdHuszVHj9yYIILtXCpQI P255m2myZul7gjgowv2p1Q2HFMPz2O4grL85zS26AMkkUl1t+ROS0niG3HvfYmPAMUsxNOGK fchlsoTJqrteBf3zj2lLYJde+YfP7dfmKu5+HJkXqrc1p1tjC5j76Q6LGObCWlv1HCe9ojOX ryZwGbugCp8Dv2Oq95zJiz8TF8nueuWywkiEITotVLz1JwsyLQTnFToVAFpy/Ni+7Q1aHESJ 31riNShAq7uiORTI/axFYn5ROr2/nfxCu15FiwJOes0/KwU1WqtLXiTChFcEWl16JDLfl74Q uE3BkRZ9dWRbhGDFcLows4kPgpm+3Ompid7DzpqLLRxWUHMchADddhr9d6hlne2qud/i1ZjR IFSkSwXgZ/FygWW7LfTz6pFuO5HqUGTq2d1NLlIY3mJbI8fMxacH+VwIZQrTQMS3Bsr9uKPP IKRRsAXSi4JBCLI/Woc3SIQDzmCZNj/m2EaQ9Hf1z46ctySoeeNJAGqZzTu2//yDncHicslQ oOpBSRXa8f2Y5i7xYf+VVaUhBuLAI3KyAyqrbj8eTzj8P3DGlc3B4ZDXrgPtnFAAYZ3//9Bb LnnLfLZ9IXO8rmzV0IR14oy4UBtZML2NatqQvLKm8iOLU/v6VI7g+cxCurmyx+y13xi+ftx1 8P0JQfqgKk0p08WiA+9IIdhFiZt8jnP2m1tKH5w8FVxtsCrBxEJpmeGt5/Itawo1xFMCFo4U hWOyel/y5l8bML2/7KkvtGw52d5voOVuRMH14AMWrIj+zVQD+kenFDeT+WVT4QAp3LQ/fQ9x dJHpRxl+p0zj3xpA2a8YXt5akjYpWbEcAD1sEhl3H5CBRL4Blkxr2xzAwRTV82ZVVsiLDvOz VW59H8GGCnCeOS7e2y89tM9gZZfLHah8jloTM72Eb51m3yrqHKEk9QxL7y1H0dBOOPmHhvWD VbsihqbRCmHZBKd2KGw8xbov18+gnq8t9e4unvbrWuKfgWtCY1wEBvTlq+uTW8CRXT6XiVhj EiFsEm+WPc+CD9nuqW7PF1rugYPTU+800xuDOF9s4iRoKJMXZGSW42wMawABxDbBWXiG/PqI cQB7uSWxIrxgAdHlaMd8jYaurQbibgxC4NRnjp1njWF1L+PkB665/3OGXnMWyjvNa4J7qK5B E5ejlwpERcDaw4Rv3LrXguW1O4Igp4F2K6gtZukecDxWxSdK27bICUt6REOrdrjyZ7vklpf5 Wq1/2xkIcFrtF02hv75xJ7lS9f5NxspaVqofSrlb1wEyNQvTpMytWHkKhXZFCTvo8PKWv3jX UXwfSJPynwfTv9OryjHrPJlneIxGhV+z+ZjopSGC9MUxlWF0bUA53kqjFzK+MiRbyGGCNVKo a78jkODNTAWsLd0x+6qZJ44sKGDRNn384qLccExybpwkljX5RzQntRVQ9FjCZvTBInfbyqAa EGcUzgRSfVwdt0I+MsYj+SxfXSJauLyGes53gp6y3of7gTfbjJj3F8ejV5atOzxAK60DbZZ8 AZXUSDNQEw270KJDmsr4uqDhLAI6CO+vlVfJg0aLrWTun7WqA6lOm6XC5jlg9vwIgeWDJOob oJC2gmtixGFcIY+pGs9WIP3WC5wUXgl67bgdSzPTk8CRImkuD6u4+iCGEExVowwHxVillwRx O0YDANVEcjbEnRmuygSarO20niFFagZN5kjDH5M2a5PWSqVG0ZCQiVIxd+5+6C2umXtQ3kt+ MrlfNUrd6vEF90+skuzeNx6BPD3pYy5ueWL6Nz3hc/BJ1h9s0g7NYCGIksV1kPB00Dbq07yz iG2hwFntQhjUTdLCICtjbRDlzuj7BOL/7iZz4K/RDI/lmTgSSRxnFo/jJwYy+zo1ILrqCTCF VNYKx562+ac0IaWFqQxkLHuh64rVA03PnMFBw/wRFMQLbIb9XAoNf7f/GxPTPMAfHT99mB/7 RuyrYf3Bgfw/zOmKdFSAo9sy7bmWGeJPTbAQ01ifmsPF3x1X5t45TdQuANWUKbQoD2UJn8i0 3ncI2/cSmI3nS2Tx5GJHERvtukVUMI+dCScHvO91GMzBkG7e9VRgBN6fPGuliCxIIuhCam+L /+JCn7+o0561pWv96XlMvGBs9qkGQuSclRpfGqTGFW6CXHzmRXHBqlqxlUQgw5XPVhDfHLVS 1aFKaHdKUEj2Y6FRNw8CQNM9YiLls+2h9bSGRSBh4cI9mwBePVrruiF5M+dXuYKmdWpXq7d4 o0eK9SaxLUN0oHjEQXG7H5aASY4VjgtXE20BE+88Q74cukWs0BvOipLhjIVH4/DreX/hEcfQ yn8PgVb8ncxHzD9in/iCdMiGtzrT0mcwlr8filA4TXFaKKj1uni7f+NOdgJfSviNWq+tugJ1 seMtY+PwA8cGf4TMnO2+SJi7CnF9HKzioD8gX3FbjpjP93H+V8d3wWfVSV27qeJ8gjGNKCRT QLcqfrrj2M4tpnj9VgRDDIhq47jxjt+D81fW5A/npiMcXGTlOB2uzq6IJQW03Ax48RZgHHg3 tmU0AVz+8VXxCZGBt861sHjuYAae96zicQec98X57B+BB+Kd5G0/yvuWVoS8fegxVLD54SYk 4uCxdLkjq4r2wAOtazl27CPP0bz/KsJ0l7s1goIfrANcy/yNCRUDHb9226gqHkJ3Ta9xWCZ6 /BQo+gxGBp/dRByJDu8ByLDHqxM9K7oRyBc47fGN4T2NCjJvbbwa3P8lPzzoRSZYS9+fOs0c vV5G+Xhg02j/vddKrY0ANrW9Wb2XDt+qaLVVddYKQkCaHKoiep3KfK5dumccmYRIbhaWn4Vf IWHxXTpAs/4f+X1CxwUjx7198DRAR01d/2YHJ3ZjEmv4cr8h35kEHlDAY2wMqa8oAjaPrXlq z3o5NAYlr/KPW5vO+wLaAsDhR5BhaZHh7COFbm8cSFEGtLMCPvwXIL+q3EaNMDpehQo51d6m SRmD8Y3FupFET7IK3r7xaNLmzsUb7gNxinO6fW9N+d9Cxwsa6rD5SwOs0F00mC9rXnAieltg ceZ8fUmQXfKfsEjqrxSERxmJZJ4Ef0FmhgSOvlroc7VgQkGWjawd3FzdLTXJaXLXDC7oAfln W02/nCQNNI6prl997+B0oaWVsUD6tWGBV+RZ2bdEwsEvUG5tbTbisNht226pcknfZs7Wxz2V 3PWCNQLopNEJS1+HzU+bXRpmTOAFDqk22mTEdMS2fr4n6fH8hd8QzL258HWVpT1fOfJjcgQZ w1feoskniNMwLmcUKDUN6kQBr9Kf04fcQ2WTDAEaGmZIlxSbsPQ/fdegxeWCkxHks+Mnh05i CcSg17po4ntqqZr9dM+nb6aUOFaEK2nO7Z+rhdY30l1ecb+p+KI48EjAUNAuaP621QNQyJ/z 769ZxD7piGwi4ONh1RGyRgfBYwljaskTYVDdMkEC8RwXscPRgH/vTRZYhxS36Kk6siYd+lHk Q6iFT8gILFhEddEq/Zfwhh7uI7g8EZuzOKjFSrM2Uon81YGwpdB1LZkSWworFV8Oqzxc5W7X llAjfkf0S6L4pjLB+lz4OiC3z7WGxP2Fx5dNVTlsLCNTR80nZZFz+AxvpQ7MbX93r08B44Gp BfRLQoZXpWbWreXmmSg5LW3yBDlsbXPBRUIYicDMmqsDhHFMVFK+l7AyOeZBuVvpYMpaTB4t yrIf45JezrKs4hkcaCSigXFEJMr6IKhWHG/lULNGFPH9X4hviy4au9+p5mv2Hgo072ScgzRN eFPtpwfzA10Mkc0BAIC1A/CryRTflwkJvPjk6Y7zBoJkn5KlOKnLYmwzc1rRkQxcaVvu30sO tlPWYvg3pLSa5zXZf7MROkHn2+utvOd6JEpiTUEaHVI/6I6HwB99b9pKHCYclDFs4MS3YWF+ XkV8jgpnJ+WRxju4n27TO0xovrHtIGgLRPDE4R5tpwy5B7XwzQs3hzjcw6HVtDsqQudRp8Gx wgO8YHWZAT1YAeHYeeSfMYoxLfyJBRjbJi63FKwvmkGkS0iYhNgiHI2TmoHBiqY0HhOS1TGg +ADVxrbQgLbrb3ry77MNgRS+tKACnKk9LWqPWN+ZPTIdICnMfQ4S8ijow13o51BKJXZuk82E /txt1BoIM/opHrZhYtIe+TCPg7e4o8LHv+JJHYN4Grx6AawURcalGn2fZrp4+Xc069y/sWn6 jYVN2E1aw2T1TjHxKTKw4A72u4m9sP2Vwu4s/rKOC5Ow1x6RpbxhbDCXwH4YQW6p/GUnUsyD VavO2tshxoVMs99rq7mu0KcgrE8CFpRAlMDqhI2GiNETfMqhUhbj5W8ssV871D/xlSq6N9Zv 9rrtZiZyPqDoPFJCH0KYcYLL82SQsAj9enSB2y3GMRgrP0bnqnGaA9JzRN5eGOMCAamHbcpX +4e4eBclBl+4iZmU7zQQUuf4RB/+BMHZv88mienqUaL6aec/4kCNgS3oZArvgJzFPhpGwNme Bt1mevUrCrioIXhPOHqaWqW7R61ehZYOuIyGTZiJU5cQ6PcrUofqVUXjLBusXG1BSfePd12g 1BWZppCL9dBQs7mzpBxNMezFPYEFjlzyRqdqA5TndNeGKGj5K/JoLCdH5l/pKw/ZPznEd+21 C9G2vBjmwirPV0GHY3CPucXiVNcpP2FQaYwYZMkgMb24+iB46rJImcpfqIE8OzGyXQ/+s+xM uDluLcyOVFAiFudpVxe8X+1YRufmxmWM7yl2iP/Vl7tcaROGXu9IgumcKLs2EGroj95PfCIg PLSgcZY8gOQ1o/n2dqzoEDiytpqGvULWNcZXdAC/iw4o+Pz/VSuff+EBBjviI7txr205wE7v QrFVm39uGsq0RPoDwPy3ezKLqKUZQzoz35RUlJPOQykNTg/tjQetmZvHzp8mdei4R8fTsqMV FiWcfuOu1p5QRe+6ebPusRQ2zqnuNPIPtDK7UsQC/XJfrfwgGucqm8bBoe2bJH0AxwmrzdNQ 05ujRUmsxc7PLdLOJPUrQWryP3Mx229yMkJVWdL3uSiBbSjrl3RLyAo0rQX0wHJYbwisQjXm BMX59xvNGqhRFQm9ACoR/1+qR2aEMbHB4bXaVEhBE+czW4jW4gBhDBpKUF8D6pBxon04W9np mLlConTbkoR7010ETWEgRrVhKtYl6Q3w4BQQI4vPcjR0BNJaZUeLOCHUb3A+SjIRy4chfl9P SH3LkUg1oP/zXTEbEylmobkIr0SGqTRWVzrzWSwwbKhklQxquYU4Qnrv3Nsj49UI6It+pSgP B0S2TUgZQFa7PWmjpPdxvwUFCkwu1WFFaM0s1sfyW70Y6hrqQ/jzxXZuJJwTABw8c55lG7fT +TbOEjkGU/tY2uXnIALDEhVqVfo5tKkowBp+LBY86PTybykO5h0KM0P8yZglQgatF3rQ1TmQ 16ShC+JZpN2tkQvaNHHQovakojAp/dO6FKO3t45GP25wzftwtspPgcvt6tsldx9tDaA0nAu5 rQuSp2OmJ/tZ1uYe2cT08TRpOEHdAohzIslAadCf/6NeO2B7MirYZLFp8lbZVI3p6cLvkTnX FloyvXFKLn/+d2pY1leO2Uy3krJHIC9h8iQMNa+0fvNhzugt8f89Dsbw1YpJcHZ7vlKPiBEH 9fopCJUZ6tO18XIkaAaYpeej0GqAfxSMy8XFtGOaToM8tzi0OZp6Ir3fA8Ogr6ztuHBRwgb/ Vl5kexcySAkMvrAI3+SVqbU5W/j9MUElDP/PmcyE5DxkxW/hRv2Ytf9l33+0kx3sRPe+oyEi gx6IkPglZ9I1SDC481CoABtyBHLFn558CIljSA411JAK3ONAhNyD8A2RXG3IIH4T8QCINmkL d2Ind1WCZrKluPz1NOl9hasoj82DOcQ408FprkW4qEiWXzWZD/QP3aVIrwDkO5MZslLYKUzB yCSE/yIphyXGm5VcfmI+z/EEOrOYEOR50Of9mkPaKaPtil0pGv8uHNmTj3dTYf1j0ioaNjcf WK6pWxiYXaFBhPJ+dhweL3NXI4ndz5iqxXvIvghcsGTNCJ17CNzmjdGja2wLnPeednLZNG6p qgQXsBEbdNToRQkWj8btH/2VJpXRUcp54oL9Nglwfs28ax3bcH/4Wct0UqTkKQTb9KO5NSpN 3BBmb0fYBOzYSDOEqvKqcvoqCx238QdLbD6MEwCvgIlgUgpjXx6RLMknykALQ1W5sAMOaVZF JjY/TShGDh76jZCKMOiu21q7BuZO62EkQYiQveHZTe2/emvD4FcuNK0kq9eu5IsJf69njcJS e8PsKiHYNUuK1TFs0Hg/LYt1T4MHap7Esz5y/Xx1NPT/rV3Eoi5POarkdi1+AZkgP49sy+rg 6Ikf8S1AOhyqRlVmMC9HEiPRiZYoL6BopeLEtEf0obIeUIL6iVNuVvto8M9UJOTMAlV5D9de rc++bJIWxLb4unyqn6K5ymHJY9aTo/xdDD1nMmgvqLVumrcdB2TNIEQCj5cCmkh98BGknTfb bYRN0KQsJDvBIfe2B9QjtG7IrA6IwmWF9QKr0kFIvW75FN2LvhJsnnd9smZvR9ONkqfSbdb1 5ErlINV6fXVFnQfC7pZdgzzwqcYb7+jI4y5Y9YTxgJ8KBLzIrXc6CgGQhSPCTcqzAa5ZWnVC 9V4/Aml82vdgGx7AIVHRHB9vRRUirvl5FsHaSPBYtNr9z+r2kGfFTQMJ9tEgltBvuYoogegA BhxK6O6V66+6wKBbQV5ZnAwFTpb4dBfoFYozrFjWadZGhqbpBDNsYiG1lms5x7KfHRxSsvkt egrJQop7RvA9iYjPmBtSb61Tz9FESuUgivirtII57yOQGJwuJ6H3QwYc8zpJC9qg8SvpJHOE xBIxfyQLf9E2qbKBiSy2E6pxy1W6em5BQ1xfiR7zYwoYgUXlVig36CVI67T79fQFEgste8pk saIC0IkpNKjc2EW9Yf2K83mw9OowgOOceTlkVRbvP9jblp5FvD6ASi0KWNdh5RkwZXS/tsQA 8G7/HIAE6izS91betdzpnRfh9xAhS614ulJwNgTjCTQX6y9mT8rslNfh+ArOAIvQvxkclriH TaWIWKt9uW3Zd++qy35hEIbbQm5VXfznHZbyuHunATGK4HJgs9B4hDWpzpWlMmGTPwlV1Jdg JathDJC2Nddg6SDI4wrqAtEQkxt/Sm20ef6o6+jyHUjtfKHHlIa30oC7TdDFuQ6GKrBxuSQG ihoXlGiZo7/CzyzokVADJa7J0SebqZAwfPkSopATc7rSsWcaVFV5oB5891jTTwdID/u3hY+Z cmKziqytFKz8VuOrHM9cgWKlGRZ+eCbdpJn11E3c4Kzy/285aodhhqm632gSvor4dPNTO0dI 30Gs6Hqv4hshTR+hxzLDHV9nF4WU07EHOdwudkd3BQK3t+Fj+Xt2e2hTg+PduQl9IgdXpxWR mJUYYiw7c6wYH9n7ncMnQXO0AM7BUiSaMEEB6LzqyknDy63Vn+7SwYDCLM1gwQVFVVyHR6/H DAvVhu0ov13aCXEsSXrUylg8nrcCvADZNlFluwhYh2CR/SPr7MWfPBhY/g2ZA0nZu2MV5GiH 5vbKGMKSZJ8LYWGMzGb5l8caxxufsKvOczSgGFALXoUF6PonwMHFuQEmaiT4xCopW+Q7OJTp +MFvLLWH5N7aBkjSSgd5lFICepS0SJTzjkD0UmIlAWziUmm3IuySNCoi7enGIXfmRFniqMEc GeNiX4V10zYyZcZxEsSXzNu4BLQyoZhAzhnUpHDGHQZibCwYNzd2xGN7Ryemw0t2basuXMpf LKRxJTJmsnWTqQ1aOGzHr0DZklC08dR70X/1KsZtmWMIRPgWU56f1ahWJ1BXAzh8QLILKrQi 8N+r/dcIjc05bvAnpphmQwTkLW3x6lx6ywn/K9LADvsgrElrIcDRzYk/ZBpgpEFmRAuFokdO CIBHnOyL2f75LjMCAz+HU4tBBK8oYNBQENJmsvgHZEgGv4htMxvn9MPKKB9Ncys44F2RbPrk Wc0NhTGfo/qQls2ZafdKez0paHQXLOHcmPDOBaQztYCHh/E7KqsKpaaMHB7GKJQc+vWY7BaX 7Jb2qPmbuvp3NNFR8uYuxjhjuws46y8N2w9R01+52ca5E2zpxDreg9ZAbD8IgEKjChFHCcFt H/LBGp/6+pItub8C09nRVWOP90SmQ2cOS5jznQG+u2+/vCUJtqDgzsYQMaZuu7daXST2SpcH O3L1TgfTXQrdOnQtAeR6Z/v5pAOUFF24pdUdL5XZu1suwLjQKP19mVZsPOA0+KQpEzd+dmfe ZNEFnuwTf+9yLAdYeaADDWmjrUd+1s3gEgJ2EH2oIX0MyBwwVhl9lKDXvZH82W5c7ayyr7Zh CGrCEbYU+WcmIgkTskgfxp8ACwfgezA//OXTj1ZtJAdfgWqlAK03CHx2RGAuaN0G9BHQ8vlv OiaeBpuflPVwRNCTpEk5fw3fgfPf3heJ+t25Q81u2MHo024kn6hAnd0kfg+VV4I7C2dI7z4q 5F1WYIbd2XS1pI7AHimxomnyg5WZEy4PR/r25WCXMGzuwwx6TlIvYxOQD7qwhtRk5W2cguD1 lgSYNdSj5UqipvUShksBoUUU3Kk9nsQuDNZyLvKef/iFV+6CXR35OubZP6pq9tosSy1FxZGH evJmk7c6bvYFn7ZkEvyz1537HPsfSYhNgRV/8ej4qwebMWh7u+Q6VBZETSm28sw66pMbUX8D UUuoN5lt6nGfAv0I8jwjUXXw6uh7V65hRono1+KTwKTNyEgl0k9sixUnEDM/5ITKWA3MF8Dx pja8qRWeuNABurn9io5MFQ/RPiW5FFHfSSezwd8UJO2nVHUCVxdvUiZohv1gu5cFhQ6x/Ps9 n7kOlTN707S9v5+IH/nP6zNWHIjebj+ZgGZjJBxd6C2qAqUW1KxWoDxnoxsP7+7t5pr9e1K2 BvWCOLqiMpJR/tmrmQh+i+LuI4VmCkC3NpfQj4z2Qb9ywEXjYM47jadyDW1GfzwgJIBfAyQS 2I9DPzZRs5ELCQjRLxgpVUWrLjtY+nmUT8bKkO5Z0SACqiasfUVBd8DTEVMoVww3CXQXlo9q Ri/xHLpOJmtdINcrWDezURHYUq5YMk1aq6rRI/Sxj78EEkHi6wrj3n8d+Wgl2gkVuQy8gYmp KHAjYZaOaAm+gItHICeJoylmPb0FshmqYMGwclka7AuWVc9z/P5Tf2wXEMIsofs9BESakphg nfP3POsy/x7A7W3M/loavkVx4T9qYEZN2WEalBZoyzgjBuNdyqB/wniaFew9xsrg1Bjt0rTO +JWqid3gBIzzTUjM19f1IooLwXz8dkJXodDpDDfweXHvDgy1nc9+7BatND/dvAEXLuRtgV40 aPg2qNL3f7cFCxxB5WJYCpUV1XoruVpWLAOyU8aNGJLopVSMjqWRZ8ND9PrHmXJw8xrhDsuu +LLV8FgoelGJbKrToy3ShoFMMrljszoIWvbEAKbJZJDfyYiZEphQKUlfPIkjo7tv1bKGiEo2 JU77G9Gq8D/5EUqgLqMFktgwEdC90x0GgPzRQhP1BaaOqrKqUJ6W3GMACSN72N5s7xMhRwro XN5GQ5KoqLbI/nGEpvsMX0xN5BlHD9NI677HtR+sWZJqwON3wMaUHPnts3lLKpsIZnglP0K5 2EiSFqIRidNhexOh6jZjeh2r/8rMqAKpPA31AXIYTqNyX3Wosf1jJCInYXQC86PeWoq3akjh I74lD2RouD9O6HvUNsW7uyP9tG+y+XxixstPRxvpF+yA0DPCMQ6Kq8VSjYKqH9utBIvWSXHW JbX2EEoylAyxL9kbtF2BwnuMuwE6nb7l438TmmnDORgrzTSfoOT7Pb0xZxZW0pKxhJwnYim8 TJz10oHajqsDdkwynFlT3n8xGEvnOjHfgqOAulRvktifDVMz6X75RmpHUr5Czr/xZYpaj6FY 67pjRWuvbykg6N/SpTqJf95k3b9NHd6Ni88mGpIhYrATJPt/hkakqFQF8g0V9+DK2C4Qhsnd p8If3FTXrmruLwSATXR9nrLY/14UraeN2mVJPclV8ch1YH0X+e6tIbRlF+fIB6mppoEH3TgW S4YsJcTotzzR/+vXGSee2c46LZOhZVpwl4PLmnQIzaQ1z0ufTw1Vo/XWVIeuu5SYMaLyphbS HzyPTfOkUM4PBgtTQNztZt4xuCylILb3KKCQE3lsolLF3fzqcB5mMgvZoo6nom3IWXFIN4kv cXUP5P5M7Xi54KpNaUdXS0GiqdOYlhf3WmYkyqAyD1czV4as/LJoDztAm7pAicoa1AHE75sV MA4rDyA0tXNUq062DA15YiHgrwjK7BZDbFRRfosfF0itWXo16QV1HAb7XjvGcN26LJ5Y+7Xx rcq7o+Yq0d3xU0DmvDV+pK32uN89zhZhWj+dK551baK2Mitp4/2ouFnw+5DOCLnwN0vinY7k CspT/ISdaNIIpiwHnCkpDLkXUZN/X5DsjCNxMSjU/x8TVWuTkEYSmOVSYEZgGs9KoywcOMhw 5lYc3nXeJYrO6dXw4cy9l6IFGvHGaQ0K9Nu8YBgasccR80QN1s+kuoYzflJuXSeMX0268Cyp pvhyJJxLwsWdDhH7Lp88TYlEoSoeBe9ebseEgofG1QXAKnc6u0rpXOSzoR+X1JKilkntO75D a6Svehk41YbRKW7zxClvPsqi7ZnkMf5eLMA/lR5PYKSUQpB3eB9AbBXGDTdjTwH4uC4G8nrr MaqQ2cUpgWiMJDfiwvWkafpi1dUABX9f3CdTcKfOBKJ5jzWz/VEKpKjJqGwZv0DIkFlYG9r8 BCuDiZGNFgvT8REGHUj+GoA23rRcSu6UJSw2QMFdAL1SNNlBo6p1QltAtW645Nv/UKrfkYfb w0aJLv0fhy3J58tc8aS8L/Tqvu2fwwr1Wk0hihkZL/rL/ouE8vHxsXAZuH+sTxFnA5pt9F9p nCi5hUsam9G+JegeqPROuXhyRV7hyJEliPmyjHC+N7uJsybVNUdTE5XwF+vN3n1jO6WJbpMB eyHzN2shFLf7Pw84sscP/pAxWk3wo82anfoGoYv94LB/KUoNJWc7dtLjf3ywNHKE1Zx7oKiY NSURKMjzzdiRAvzpmcvSTTgi0g6TKodDo2/ZHkuYqUfX/vCMAJQ6Ifb6q+CyMNVokQxdO4YI 704pskoZNRFpydIa2zyPFsVzsAnDzx5J/UB1SRLGN4pDt5ssnJyxIompgZIMJ4nnNfiSOHBe y3uYptxcqQRsbphlBktWBM4U3oWFy9yZcd7JKbiHNp+K/pq4s4prjt83bdFlNEVF7/PJcNZa AewsD9OjETxDn/SuVSAf/TANRTltVNCqjJIlgu7M4CId9Xx6ZNHZYK22adgplkDw9ONONAUH jSGpbuV0DDaNdB2jRZa22ebhqgcbkZ83rhx9cLgQHbOr9CUIO49kjDIiV4yGwfagotCkypWN oL5teecITln0l0SwbPOmIz/pV5GENI8DR6djoFyWjdv+m1ix+Pvv+N8RK1xNtc6xQG1KYILv S5omc9S4PYNsEzFHYhzmDOFM9hPfUThQ0+6drPk1TJKg1qJm1D+KOyq40+RhUIW6b87xSKpk JQ0NGKLIqr1TaxAwtWDdfsbWIOjPNOILxolEgQj+jA1IPzRU4l2yfIyLjId6OfocPJePWkzx lsJXV6hvvSCrrZD0vqHCgqjCw9srmQQmTVoibfEMMKIJ0Ey2PPpReTtQRGOmEHUdInI8rmic 9KqS0MCS0Y4OQSj6kwBhGhVUuPcqfXsADpcfOL1bcmTZKaAodFbvrAqA2Pt8/EB3UYkdfDwK wzcXDFHDrjGrvPTQxoK9a1LwS4EoN/tx5CbKyfY1+PUKv+X3OugJjd6Zi/wpPhEl+DLDgcJs CCURfhqWbKn1wEGYtg6VEMPmAd3J/mxHatZi0pTam49c6os2AL+TlVN8txC0yD+wYQId/+H5 nWfAADCEc24pQQ2goZctmKky8JSXQ6X3WKEzUTa8bKPNQZkJ1sn80qTn44atZklVBTe9qh8l swhB1J2ndqf7yaCIchdBCeesKsvWnkFD3frW4JrSPV84TqXdV+LDcC9X+4pfVCQLLXQ77pBK wvOsHQc2W12Lbx5kYG4nO23CAA71CkP/OM7hq6vkqpH8ebbz85MAmje2Olac5MUNYFYe6txb 5gneVIeoklHx2Hon6tmyq5XKWFoFMIak1SAdoTGbbzVC5iZ+RfJf5OJzoHdk93F1meI8wePB 9MJUoMEpXaRktUmAnRoBlsnjycng8G7sZ4FWdLkvfFs0+iFSEkBZCQq/0GH2PdgFrGkgU1rz ikuL1rDJKTpdhhYOkPQX9bUElfw99chcyLhn8UhMaLSPpGzQo2et/9+gvUkMLXQnxXpBlt6E kHarKNfuQTU7CJ+Yy6ACy7x7OVuJ3N7gjch8yGdRxdxUiLmb8057Wy7SHnA/vX35HdQ1AuHm Ehq0ZO0oLnnkQy+SZ9jtVTg8DytybBE8CpvR4pDtvwiN1qaysASfKZI6lKzujHcayom5FAvu Rm6b1TDz+5PABs1yAwhuF9McMhgYa6qHMpkVLJRGhQnbeSS0N6FD0FxDvz8bCMK0lXmon13i ja2vI/LbTWiYfCPcYIonFIIz+IJ44J6A9R9bz0ArKM68U07+r0YaTGyMy9z/Hp3d3fVuioTJ 2WDpWmhDltwQfpl2CQsXy7oxRs0QbgJRlAT1XOjgRgDYKAjKyOp0/hU/omDZKli2irHjONcY qLKkU57+o5Hc2FIPkrktfZVLf/mp24haLFQM8ld4AOBbVhmH/T01R7RDxCaQqX7RR256r2oq RXyb36oHfB5v1CXDOWc4En2nlXwuw2zXlA6mH0T7LhmliwI0aIUIQZ6i9lAVJuj+q5oUkeOG wIIIKIDNp9iEnnJgzbfTb+TTKGnmmemPpC5BDDn135z6cHxoulZa8lqnEutgKVzbHm27mRm0 /UbIc7Wkx4L3bvhxoDU8QG92R0Qt/jBh0WxjrpUAwLk8SqAMlzOGRKi8Tfs8uvm3CgTSDf2T g5vK7Q5q5uzxsjmhRDqtXXu9Z2MV37tzsSdhDJDByTDSQi+cy+yfgRky4T/AgxVXTHxn82Oj Tf1ZH+G0pTTqZa6irAxzG3Dhr2E2cxkRrKiW0hytmJSYGt30R20rK1SAeBVu42YfGz8PAO2C h5rGHQYgOAYeWCEgELOaBX3u5GdXLHpSpGTnLwCaxmXl/g+RgY8JnD4Mng5Md+oTuPilhil9 H4S/H+Dfqo/uHlPqIdyG4GmyUQNf5UJVjRJrjBnRX/feKe92eC0Y/QLBZuohecEA80VpTomp QTR1ssjM6iltPiAb/Q6ad4r3jhX4G6mVSWqlmaStDP4g7Gog68zQB2JmbatYUOI2JLJTga40 eOkjktejNxN9/wXz2BKpK6Js/MSKVzD7pNarfYO1E3HaXFW7EmyglxB12eBdC/oQTvIa44BE x2z+amDj5HXwYZcMz467R8nSbdAVga1E5Lg3XHqhe+lKfhF7i5rWuVrYSaqWmq4YtQeir6Qm 2Kz+xZgz/sjneeELQLoV2PUUdIriXG8kUe4dtyYe2uE59RMWMbNBmjgqEJ4UjyoPmWzWJgQL 07l1BwTq2Q9dfkW2wSZN+6GZtnMG+mS5pNW0a5GMrAnYwyBLM18zRisXRT2jSuRWMZXG51Bm CKCUiSbEGB3DlcohhyOc3i97eJM48LuyqMS8uqaMaNQnu+s+tOq7jCi4qzaCCOqL/lkyphMY kYjec8oT57JO92dTzI9WT4KATRXt+l0VEHG9RyIwC/zJ9lnHFzws9djrthh7bnAP9N8RQmIa Ke1AV37yoatOjtybdLMIBa5l/Zx33SIBnia8TDNwMvhMDGCHeT+Qewhg7BocCCDhVUvfyYKS IOF3GBD2eTQzGnlSpKnKVfNz9hg6fNm2QVCrmdpxbNngB+6scuO/Bm5w9m3LPfrCjndFq2UO ZRbM70bYeXjJtUAD4FRuzADggkit0l1HuC4d+X+cpQUHVErVcpN5V5Hhvu/9Px3xJxjiJCA/ AMsw0+OkDqdAw8MEDQCHCLKaucuyMAVNsESKkdI179LGQYbSmQK5sC1bMbB7tw3EYGxovwlF L9c206iZUEAeZWzuIV9iidxHyLhAHgCYaIYJuqhNJ76mHAR/2eLaJk/mM8+JOvrIX0/tZjyo Stw+ol/NYNxfUfkdM22UBS0/xXIeMbWMzYTeati8BqG7WEygSjQ59dG5ytFmLCNclto3RPfk Qf+NkKYHIGzyFypMq6xtOSOQQtoJT0KXqZxNDslDFlzoWKViwsfFBEOt9uJLrSaXfC1mRA0o t9VT/l7dN22HSu0kAlOLUf1K0oQeKdn1liHq6FdzbNf+eRK6M6HmSsHfNlk4crNOsRy4W83Q ZnGU4A/J7mNl7i/iDpipco9BxI39pkAvyg3B8zx18YFiaoV1sBFjBnE0GgOIWD+5gKNor14x CirM3yoD96u4Io3nycPXZU1xTLsAwHmWm4wpZ/PbpI301OBLUrfLOxP9RF1nIRloVD/goO+h VSoZLaYaCAwvMBPIlNOK0eseKYOEMYRma86eLRFvf91h3Vh3B0mLw4cQ9cVU3OuNwyaEvlnp XRV96FXuWRFuCubAuBCi2dtuxfxfHJ6qjK+2oOloevxgtrsKiFitqYRCA1Q9PF5rmNRlgle2 E0dSSnOabIg09o9pDP6EbPBV3lqCtLEqy2ma8crmvQVTDz3Kf5xjuujBTTSGubu2ph6NpROg YTBiDktzUa76W6nvYB5T/rs+nNkFxWe4VtArgQayFGgxYYIaUFmkp3htB0h4VEKkPhwe0IVd 6/QOa7//yKgPUNU7zHwf1ew/fdlSKLoaCyy2MpcPSZwT+iG5RT3KueSJ2kaFWK/a9TOCY6O5 zdbRRECpaYoP+NP3nwRxcvTuUsCt30V9YfdZ4iW466HQieU0KjrBvEnjF2CAvWrwXHdfy5EO jvprRcsmTlXCttPusZ4RvDWXDuoZCyBT4m6pqPPAsEevT8iTdelIiEbPO8S9+0mx+75o2Ab6 lfaNyQqKwbLRw0q2LhO+wxFYZsjTjKHS6rYPfMp1Si1VDHE1y9g3KM3M4Fbg5KCmq0X9+9Jz odR61b2uOvPiLpUcif5EYTaUQYQExeaB4DOJpYbXWxRS6jXv2CVTSAgtKStICZcIm6NoG3Y2 xssaLDvviXZ/xx9uTiGraflHpcSOKbmxq9CnXcRSHt4QkU2wwzkZHFcvgAsSBGN8VjXR8T4A dhijhdaSJSyJTJcsqf9EVhsg4D5EOY+XUpu06lVq224jtUg2lcrQKVf2YpBaeR9t0UWgKGFW cc/3MpypZHf6ZO7B4UsTXHRAhkoiHpu+Ug3hO2J1wcaQzAI/CUbGSjNen9NqF962bx15KPDf WkmUnWLY2jkUeiebPJ5FCPZjA9HgFmz47BHFIigFoHpy9ODcJl/PdsTdI+7PTKeBQ4yJgf0S UOpu7oo8Wu1LeRy4a/UL+ych8tccla+Saq9H5eJ3BJ0li5NSnK1YrOLIvGFadIaXgC6rKkrw BNBfCiJAJmt8fVTBnIXiL5cZLFsMcz4tbmiMcoUsQmCxtWTMYSHHllOtDr3sJfDFKFqI9hD9 YXAsItmIPkGwI3jCDXI8M8tawk2RConXgZ1m51AWZWnkfyqbTKHnfQEJ0SXUh09+rMe2r4Hc 6ilIdUxNp2pTXx2BgP8Cy9YB7NcKGXcqoz4FACYydtHlPvwDC+G7PVcQ3tA/Jjl9maCS8blS cePZ3pu9qeqQzEjEv+vLzos1tCyca7S8buijXuTN+hjyEHdKPXq0u94Z05Ir2j9smLIaaT9D /WTvgMlEU687aZtz4w38jTyrknD5YF4Fpm0hghRDjKLAqs+PPGBJaJQw1+QWUgjGnBwHz+lG 18h+hh2WHQXj4xiPJyT8ewDcoiAkhHzMrtfSg2a81k4h0tEv4cd2wvs4yPTnbRyi0sNA7m/d w2nyFJjLDEtwx4vB9BP1V4ZjQz+TP4rDswLd2EIl37ObNSKS7KlWaS3J2w6+/6cU2elvT4cQ YHVxSxWTcarjgcD8CUkNt4hFv5aCJFt91e7O06hJY6DZ5PIfz2Zhj+FsLPMT2wKiGNqALYyi os4IajEsfsO3xdDKkqT0Cs2P6f1lGB9LpAh8L1kbeQ5RVZ8iSs1/mMyZCYcXjjb5QpIxfeUJ rT46lGY8FTUUFJNhLjOVltaVK+istUWTKBZKCpu6X9NPp8NVoDiRl47tWLJAo9DE4non/oG3 7JEC9ywHjiZGPEj89UjQEVaJu/mtDMpzShLrr6h7NY4ybokrhzWqmBQDUmIxIMcizwBnOrHR o5yOvJwiNjbid8Ykos3sJrPRGMifhQHfJ4HKdbOyKCN8/r1S53X4sTCfSFADByM+ACAJBX+3 gEDUiBzbQ41Jz/lf1EMSR+34RuinAGPaRQWW4Snaoq33SBV8ZgODJGsqkl62nM54fe2LSnwx 8qeWATFJ4XTRJkePQ7GHTBFAcQUzldlcsHfBXmATRB88Oca6pFjL+rcDEqC9YjorQBEerLMY PQq9sVoy3dVSvCSjgViIoXXNV7bM6tZOYw5YLG6MOlatiWaigrR93niGNHLBZGFRoK3dpLS9 O4LeBWU16MmyqAvatUdi0ytdc5/kC0MuFLvyjkV6F2WTeNhs8/eh0exnO3qw1/IGA/DJDy2y z6YUIIhGbO7PNuSGe9e4w5H8lS6SFwFuIJxr+4OlA2MwpSI73fPI+fo3egLH126AOoBvfHuZ JVwVxig23zwtxpghtVhQBR3MdNMgk+eYpnsTIvToEch7ElWEmytjYlhlFbaeUh6J/RveWUE9 g3lrNCAxbHDPImuaVLMmhzEKsJI3ZVl/KZqow2aCYG0/o1C/KljAGhoZxAHGR26sN45R8ffq KxyI4arAbhtpE4BjGcRN4YavHg8uo0W0Wq7W4eDYw4l0yqZKj0N0+8I3Xzu9c5I1FDPw3f2p BUc33m072H0i7KkmLx9f0m4PM6oqg3Ki4hZ8CG2K5FHMk4Z2RhMQYqiOtJ9iIWuHG7F9XDRX 3BqIHaj2lyuyjKAVufzyp13GjVjcEXLFZO8zLvg4ta0V5cA0maIzCOTzPw7KLcwgo8a3C4Nl YJ6cOQMDdN50D63LloiN6BW7DZR9I4Js+wHqqsx9UJLBz92UrAwW9r65G5BDNOuNE13XdsIN U6sboJpsWq7zC3h3Nlvkom/rHV/Q1X1RzxnMUN7WWnkpOMhmCoUARm8GIX2iwBfn3Szle8AC 4wyBgqhHYjC9BKlGnk/N1b4RiEjMhUkUHguSYt6PfaAPDMgDnRNEx2gZcBccdP+mhr0KZePB aiGiXFCWjySjH9QFjNpSBY3dZbZTpePolbvuh92geJ9843LsaX2zKUmNhsMzJY/JUay4LMle B4EE27TOLxCJO26602xniIvYmyev6/pc2A7HW/gOSByGzEb2Wu0neDbWOphSCXXOpmdSPni9 vbxo0Ec8v7vUWCTPTVkQFvP7cIcq4R4eUlk98SM4mBVaSWwfFici5RfoiN5ueuZ0ys4otKdw nIkPpoXfYCf46930Oq5cFg6sHiZ70p8/Gk7WU+JBVOrTQpcDbHSnQ7OxdCRr3pL1WerOaAHJ ieWzjHd3I+6h3fwlDDPDfbQHj22HcS/FSpE+icXjAIDbBP2emL8TNIPEXBYenh87P3eNPmEn IXc+HfH5lrSH/ZIkqRX3r/lO9RuLothV0qN9Yo0kXZOKJVgd9ut8Hpvw9UIWiue+R9hZHvLQ XOD772wsQFddQaFnealOUQcse/YGks2VxQmL8E3KPtC2T6UKUPJRXPB0B6tcRFLVyPrwq9Qe Vymf67dgnWcSSXzPicu3g/c+3H1F6vLqc13FpCLJdABfMzAOQI6AWq7agB7waXPv6/Ui75Bm sezqgSO7UnZ/cRhBH56+ZvOYkkirW2iVAN8sKJ/TO5zdjJzpRC4vXM0E0t4BdPZmX3hUwn6d vCAsjNofIOBZG2vOkm//33X+cMSM5nbP8kOpqJXduahE1mQYzA2g4TnC7Lt8Pb02WzQHEqCB mP5hPBkVCYdr3aFhMazyN2Vxk8o2dj7CVvHYXpODkn7arxHH1npk7QrJ34GZsPPbm5IQ7Qx/ JlT0pmoo5jf7tKS/TITSsyMfSHTcZQIgosiVY9UjuPmNe2kvCrI4X4NMaLvAwJcY4No9qjDY PEOf/XzjJmWCS0rFfH1OJ83Xlp08e+Z9/2iZ62vny8nuxiWzzbN7ul80OJjjB8X7wmipzk5y I2RGyUv57QENmqnfNo6k/mor2OIXAef+YMhsWV/qmLEnl0EFlUC0uQ5l75bD0J4B86Br5QBT kEPBi9/Nug7z/qVusqqFNOTnyF6pyCwDJvRJFHmuXQ1TkbsztaUmOIKpxFPUmByusnaePxk+ c6JD7PbmnPEl/kN/b8VWd0dtXI+q4jXVGGzDYQbuGnCzwNQHIFkipwWfUZdJf5QYfxne809l 5CPie6eyfY6wUdIarxOTzks3YO2fATJnTuMmddvX+yJqizeI0lFl7fCV4YYNczLmODAVHeEG uXdVDMVcOk5HXn3I5NL0aMl52uUo0jHq4qTtnokCgsxYD6zVRJIUlP9Ec3pSjI8ROrrlLvwe Dcr708q06aedYDL1aPR9topaQn+ReQGwNzpn90xFlJeWJ56aDQrdBqI8kSg7jwkUBCaWKj2N n7dVf18/lQqdcQTopfnSonX9rtYBIVSsKLPQjNjlRnm5H7h36KiD140wfpBgvWGbWzRx7O5g +ro+R1Ab7x3sDee65wytl7pBgSCmZhgtNAaZerJg+JAU3R7lKCfzFeiKKQtVLxVmOp+7ds7+ jeGI8vXN+ozdk3B2B8Z1XHaMBF6+7bXsRx9oFasQMOX6KloI5vWP+QoRuljpTcIx2QNGVXH3 pfi0DuRhBijC6EkIpcgUJvbKMMB9b709tz21MZANa1EbYi3bI+WGIkbPxUb7j/Yl+xtQABBw +9zO6bafVXIVwVF7neUSvqiUvdoFH64e9NGVWc93abab9efUucLpw3KU0nxZNKVwh7FXd7VQ +H4RZZ578Uch5ah7XlKDR1QJNLlA62w8O5G5xqW1nS4kS1YgAIAEgOzG1PQP+xM+60UT1AHZ bo3TNm7Pek3jW6Nt6fq9IujVTs952A9DFY5QiH17itPUmKhVXxcnNJ+A+Z+LD6Q0TsSEpUU+ b1bfrNYbBHBml16/aAk46yz1Fl96E0n5pt+6RsPArEA2lX7X7FcfGEIbHLH2F4FKejFJKAHb lb8uwAx0JDizJQuR1Hb8hVd9x/jAlzw3Ya87EcjQg+VcPRfaZwcHAflAnCFRumYoee23gl8q ZMmKkCrf+j7u0eB49NY8faOl9C1Bs0fdphAXWus9Ke0peJLi+5TA5L4B5TQOHM4+LgL+gQpV v1qekhyV0rkMBMkCjzpNrRWCb2BxA0+OvbwZvBOoi0Ixknu141Q6QuhNFG32cue9vKa+rp17 3nbJ9Kvd111bCwiSgvoGC4XDgVLznk2ohlQuzmA59dDBUF8+b4adWuVp7cQlUz+iPTyu0BO6 9XeTaq3lMsQtlStXKYyL0cLKgVdiq6C4WQPwIgd4J56gkQtCAoFKWIVvJctqkJqSmR1L3uc4 yYFbCfIfkzqPF61zjxW3VnhjI0wh0XTudTPI7/I0XuQFIdSrCX4vUWYR+65bj0fqBXrZD0Zp JzgYpIvog0emjctBgqm0GCO+2a7wi0qTu6agrpVnROEGQAAP/KaFhyCzdmWNr+6FnFhZ7dY+ wJxPhrL83sGtBw9uRK04x242pE7Ycg7zWEGs2UB15val/wd+P5gVeF2rkcU0hKmLijXCisFa KuTJHkbdJprn6FiX7GaRvFbRp7YKif7x6qW+pFNC25xD5NTLbRGsaOplDxQbBmpefX7CD2GO wX59wMoIrUAvvEU5oAZhgTTREXrazrgdCwtD/gU+Rdg7Ud0b2SSjCvXfQyH91wjKQyX9oqrI z0DL9oq3v5PZh+oX9lYO0dZfdW7t68q3kQkYqK7K64v1owWr75J6C4a23lBjvO+Kp6gKc734 GuX2WaaDZDKNhbo6rgRUiTKNWn7Z6X3OzbQkPTJ57nxpZbGO1j4rsefJ7TeBsh56pMSVKxHK RW640MDaBryZE3fWM0QapdkbEALhR4kHyl2DOF9VNbVu6Vj64QS+C3ln1CL83MhFPZDpAtgD 8J9NfBJ8Pk5i32IJETH2ulhUuQtxESre2QVWnKJyOFeT4vUDYMD+eYCkJn0mWz5lh6TXIk/6 TI6HgQU3gZqSIxUphT/pEnG9vs0OJoZGS/9h/AvSvfFN70WVwWfZPY0MGgxwoPxf8ahP6YbB inwtS0CKEywVulZ4mimEn9Stycicu/6D0hJcIUeoIZNCAPBiu443BnQN6eCjxsz7q/EgE1vL Oiv+ulUQJA6YCSqTEqXRoWuhWETUGZdHzhI5/dKRu8XzE1myfiM2SE4RQZ3zdCQQykq6N2pH hHW/FZPCZgMK0Nn++yoSGeNSXRBLzqGTfvVHGqMo/wWxwD6zFcceOiewRLunewbngzMmt8cP dhz6mFIOj9Boqt+WQwnD2IOKqtyeu5fMd0OgEaRMRzClWORVXLyQPAC35TeL9kGueZcxOwsh wa78aLZUnIsMvzgEMHUgXzl0tzJByUnccXRrcV6OhEgbRuczftLrvymLSmPlUN9zS3Uoj1/f t+hKG+BsedmMGLUYY8dJZhgXnPfN3oErK6Ym/2LhxOAx+k8/63hqqIeoGxt9lyHS63ywoVpf WLOZRlwwJZ0REa1FJPatdHV5umai3vqCTrpZ2E5Yo4wBHL17ux+mXftq0Nne9tCp+Oq10fWL slVcBb+926xGYhrDlbFnlesd2Wot+EtT5SW0mMejeHQZnkOKqgQK1EQRS68x6//KrVv24b9V ShstVO4iLPXpb3cTpJKzLU+V0HxC1EsHODSB06PAMdZ0d5VS5/44HhP5WPYxLTcHJiF14Kmm Q9CKbo4tbl3Klv9nZ+dECjpw9WnsWhKr//9utD/Rxk/DiNVOenYEnOimMLwEAehKvZt5UT5O 0bB1Gx318QYixEFmNlTXbiAU4cUzaWkf4EONVBG82TtlDjkxyQvP5xwYsF2KVlD8BtoautUp P+LnYCO4Sm2m/ItRS/ZMziSlYNSgHabn0fP5jwE8m6n89LZ2Xjmps2lkjXD/NgNA9Bc/T4eb /kW0YK6sJQcbn/rMIa28ZyJBrs9ai/g2LPHMiHn1VrYPCrZJxCh5Q7En87kBFSFk6I3rp653 /WeF1J8WagL96GCacfDwvRdGrXrpGZXyRYOhiDmsM5WbD7Wstbl0yLjHxpm7eagJVBo56E9/ i2ibjbI+X755p3skTq8l9c4ql7lqKUG86N2e5MlWd8xc99sSEWHo44Ly9Q1T55+eQrkLpx8u 7Kl3+9+RfYsRRNrvM+jmsp1A2sA7jIQ+H0pmjED4FyFYMg+HNoSXK/7UArjvunln+r8gWhaY VyJs5SjhG8GnBxXKw/9BvsAFrLP7KcUYU538nrATuSZM5Digc8VBWtcJixc7vX0Le1BiZJfs +IWQZ53Pg4BBJFwpBHNHNpSyMoY2jZ5K6sQAiVsJr2N2S1D2Fx7iMhu8GQXjgIv2YLGnYdt0 QNhE78oF4byT93CjKaOr321Lqc8grucxs62u/dJBQz0EiOz4T+0ElpwfPmWq1m2CcAmil9jx RwbQ6siqU26BQGsmZyJpxCd6bpvpeenJtWxQ8lO13S4gqiZVRs5Fnd2Y/9rUSqijsfQ5h+yJ IT36P2pa5oRS4qgkBOEtEpKUH8zWZJTjBFMijdYOzoSVzLskBmp+Co1VHtT+veCLEnC6/DSb FeLZK4JoFASZUTeVrpIzlCR5Vl7DRGvEx7+oEE5ZtaMPVaPJ+66hr3an+VHTltYe19ZKJmLh xNlvBXDLmmLhAKa/Zqd6KGdlIUQ6PAY9zYEM+cr3akXPKUPfQ1Nv5lbyxpKMMu2mzZr18qxX Aby9pbthqEjCQidN8Q8o2Xuj3i8pCTkLUO754mJa2R1cVNoNLC85tazLDERpAnB/dDEsX06E qwZ9qZ1UHeNbWDmtT/w+0CZzlBxK8n9zMHSl3ihmNJ1b+7LT9VqvV3+bC3tB25ufbLKN4Kiy nTiRM4n+UpT836BreVCguEgBbs84ozGHMADnVid3R+JZ6i24s95FP7TjE3RGWvkICfT+HI8h TQ3nylwU5ufE1JTbbdBAvCteBV4PtbSa5hg56UK6db++DDyCOjzpEaWar8xDHyor1JNVeB1U imdZWyewoj7XM9W6JYo8xebuP9tPS7mOUzlLzX6kuvQ6nFQE04dr/du+UOQzwjjzuytq8tVX 9eV2wefIpgQeNVWBFmSfpFBwDwKaTbm/gGjowbez9TZY2tzvYGEiq5axJeFwe47v2XQgFA7e F5w26IOZCQPi7+dSi+Abk8215xqiym20W9IwlkBu/rdEJx4fO3zzHxtBLZmQrJDToZUHjfBj 4BetdsiVSE4Oc5+gQvWL5ud0g6hfFS9DTfXFYKYtYVIG+ZxZvm+oyUG0Y1i1bNC7NA3ygAbV myFdHmmzYLuDZ/I9bWG3zNCTDTT97aMlpPCarlsUYSkrR4BpUygU7Vp937Yz71e2UdwIKlsN TLVZOln08aq5x5fqs6XuhV/NRjrVncVe3CIC350iIxt8/ObJuUgVguBp3p6CtypFKEjDWaqj l9qqMaCdgwNBHjD5Pd86tcafbHpNfw7ymvKKMsb+qpEuf+eLcFOYg/tKQ1qLKq2pj1lVJQd5 AhSX611hoQDcYQ2x5xGv1VTbsbSLTWitO+wg/P601qabMsDhlEtixL1wUPExAaio8mECWYmn fKghYT6Vu2rd7XaT8UiNqrq9f/6TSO7y9BqznTxPQnwQPi6IlaLNolNZAcwq1QV+wzlgM2C1 dxj67J1OpnkvOGoxtt7rF2eNsF1mPcNK5k7b+ArabtSfRlBLAQIUAAoAAQAAAOBKjjDVsLUp a3QAAF90AAAJAAAAAAAAAAEAIAAAAAAAAABrbmh4dC5zY3JQSwUGAAAAAAEAAQA3AAAAknQA AAAA ----------mqguicsuidlvnkawvsvk-- From office@kabelweb.at Wed Apr 14 10:04:06 2004 From: office@kabelweb.at (Kabelweb) Date: Wed, 14 Apr 2004 11:04:06 +0200 Subject: [LARTC] Most general filter rule? Message-ID: <200404141104.09337.office@kabelweb.at> Hello! I recently noticed that the default class of my htb setup gets too much traffic (the setup otherwise runs fine for about 2 years now). Therefore I tried to track this traffic down and attached filter rules to the end of my filter chain which would IMHO match all the traffic which could possibly occur. The most general I could come up with is: tc filter add dev eth2 pref 300 protocol all parent 1: u32 match ip dst 0.0.0.0/0 flowid 1:5000 And still - the default class gets allmost the same amount of traffic as before (except for a few bps which seemed to slip through all my other filters based on src/dst ip but got matched by the filter above). Is there anything I'm missing? (probably :o) Can anyone tell me why the above filter does not match _all_ my traffic not matched by my other (lower pref) filters and why the default class still runs at many kbps? Thank you for your help! Andreas From etg@setcom.bg Wed Apr 14 12:38:37 2004 From: etg@setcom.bg (Evgeni Gechev) Date: Wed, 14 Apr 2004 14:38:37 +0300 Subject: [LARTC] zph / squid syntaxis ? In-Reply-To: References: Message-ID: <407D22BD.3080903@setcom.bg> ThE LinuX_KiD wrote: >Hi, > >I've used old ZPH patch under squid 2.4 Stable4 >and it works great ! > >Now I want to patch squid 2.4 stable 5, >with new patch, on http://www.it-academy.bg/zph/ > >I've patched and installed squid 2.5 stable 5 >succefully, but I can't get ZPH works. > >I'm trying with > >... >$TC class add dev $LANDEV parent 1: classid 1:7 htb rate 1Mbit > >$TC filter add dev $LANDEV parent 1:0 protocol ip prio 1 u32 \ > match ip protocol 0x6 0xff \ > match ip tos 0x10 0xff \ > flowid 1:7 > >And SQUID.CONF: > >zph_tos 0x10 >zph_tos_peer off > >(i've tried with various combinations, but I can't >get ZPH works as older version under squid 2.5 stable 4) > >Have you some idea ? > >Thank you very much > >andres >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > Bug:). Sorry, I haven't spotted parse_int() parses only decimal numbers. Workaround for now: instead zph_tos 0x10 write zph_tos 16 From gregoriandres@yahoo.com.ar Wed Apr 14 16:08:24 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Wed, 14 Apr 2004 12:08:24 -0300 Subject: [LARTC] zph / squid syntaxis ? THANK YOU In-Reply-To: <407D22BD.3080903@setcom.bg> Message-ID: Thank you, Evgeni It has worked !! This squid / ToS patch is excelent. Regards, Andres. -> -> ThE LinuX_KiD wrote: -> -> >Hi, -> > -> >I've used old ZPH patch under squid 2.4 Stable4 -> >and it works great ! -> > -> >Now I want to patch squid 2.4 stable 5, -> >with new patch, on http://www.it-academy.bg/zph/ -> > -> >I've patched and installed squid 2.5 stable 5 -> >succefully, but I can't get ZPH works. -> > -> >I'm trying with -> > -> >... -> >$TC class add dev $LANDEV parent 1: classid 1:7 htb rate 1Mbit -> > -> >$TC filter add dev $LANDEV parent 1:0 protocol ip prio 1 u32 \ -> > match ip protocol 0x6 0xff \ -> > match ip tos 0x10 0xff \ -> > flowid 1:7 -> > -> >And SQUID.CONF: -> > -> >zph_tos 0x10 -> >zph_tos_peer off -> > -> >(i've tried with various combinations, but I can't -> >get ZPH works as older version under squid 2.5 stable 4) -> > -> >Have you some idea ? -> > -> >Thank you very much -> > -> >andres -> >_______________________________________________ -> >LARTC mailing list / LARTC@mailman.ds9a.nl -> >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -> > -> > -> > -> > -> Bug:). Sorry, I haven't spotted parse_int() parses only decimal numbers. -> Workaround for now: -> instead -> zph_tos 0x10 -> write -> zph_tos 16 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.657 / Virus Database: 422 - Release Date: 13/04/2004 From cron@odi.com.br Wed Apr 14 16:50:13 2004 From: cron@odi.com.br (cron@odi.com.br) Date: Wed, 14 Apr 2004 08:50:13 -0700 Subject: [LARTC] Bandwith control References: <008d01c4215f$a0b78d10$a8db13ac@gesej.ciasc.gov.br> <407C5C2D.7060001@fatooh.org> Message-ID: <004201c42238$2d4cd720$a8db13ac@gesej.ciasc.gov.br> After read the docs at http://luxik.cdi.cz/~devik/qos/htb/ i found htb.init-v0.8.5.txt script, it do what i need, however it says i have to pach my kernel, does anyone know if fedora core 1 already have htb by default? Angelo ----- Original Message ----- From: "Corey Hickey" To: Sent: Tuesday, April 13, 2004 2:31 PM Subject: Re: [LARTC] Bandwith control > cron@odi.com.br wrote: > > Hello all, > > > > I´ve read http://lartc.org/howto/ and now i am just confused, i think my > > skills with linux are not very good, so asking for help. > > > > I have a linux box with two ethernets cards eth0(gateway 1mb) with is > > the host for > > some sites and emails and eth1(nat interface) with provide internet > > acess to other 5 pcs. > > > > I would like to limit the bandwith 512 k for the eth0 and 512 k for eth1 > > however whem there > > is free bandwith in eth0 would be nice to eth1 use that bandwith so > > users can download fast > > as there is bandwith and sites and emails don´t get slow. > > > > Can someone point some directions? > > > > Tks > > > > Angelo > > HTB is the qdisc you want. > http://luxik.cdi.cz/~devik/qos/htb/ > > -Corey > From gregoriandres@yahoo.com.ar Wed Apr 14 17:34:46 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Wed, 14 Apr 2004 13:34:46 -0300 Subject: [LARTC] Bandwith control In-Reply-To: <004201c42238$2d4cd720$a8db13ac@gesej.ciasc.gov.br> Message-ID: I use Fedora 1 and its haves HTB 3 built in kernel regards -> -----Mensaje original----- -> De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]En -> nombre de cron@odi.com.br -> Enviado el: Miércoles, 14 de Abril de 2004 12:50 p.m. -> Para: lartc@mailman.ds9a.nl -> Asunto: Re: [LARTC] Bandwith control -> -> -> After read the docs at http://luxik.cdi.cz/~devik/qos/htb/ i found -> htb.init-v0.8.5.txt script, it do what i need, -> however it says i have to pach my kernel, does anyone know if -> fedora core 1 -> already have htb by default? -> -> -> Angelo -> -> ----- Original Message ----- -> From: "Corey Hickey" -> To: -> Sent: Tuesday, April 13, 2004 2:31 PM -> Subject: Re: [LARTC] Bandwith control -> -> -> > cron@odi.com.br wrote: -> > > Hello all, -> > > -> > > I´ve read http://lartc.org/howto/ and now i am just -> confused, i think my -> > > skills with linux are not very good, so asking for help. -> > > -> > > I have a linux box with two ethernets cards eth0(gateway 1mb) with is -> > > the host for -> > > some sites and emails and eth1(nat interface) with provide internet -> > > acess to other 5 pcs. -> > > -> > > I would like to limit the bandwith 512 k for the eth0 and -> 512 k for eth1 -> > > however whem there -> > > is free bandwith in eth0 would be nice to eth1 use that bandwith so -> > > users can download fast -> > > as there is bandwith and sites and emails don´t get slow. -> > > -> > > Can someone point some directions? -> > > -> > > Tks -> > > -> > > Angelo -> > -> > HTB is the qdisc you want. -> > http://luxik.cdi.cz/~devik/qos/htb/ -> > -> > -Corey -> > -> -> _______________________________________________ -> LARTC mailing list / LARTC@mailman.ds9a.nl -> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -> --- -> Incoming mail is certified Virus Free. -> Checked by AVG anti-virus system (http://www.grisoft.com). -> Version: 6.0.657 / Virus Database: 422 - Release Date: 13/04/2004 -> --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.657 / Virus Database: 422 - Release Date: 13/04/2004 From digihall7@yahoo.com Wed Apr 14 18:12:18 2004 From: digihall7@yahoo.com (segun adesina) Date: Wed, 14 Apr 2004 10:12:18 -0700 (PDT) Subject: [LARTC] tc does'nt limit the bandwidth! In-Reply-To: <20040414040003.12803.10932.Mailman@outpost.ds9a.nl> Message-ID: <20040414171218.7978.qmail@web20109.mail.yahoo.com> Good people, I want to thank you all for your awesome help so far and also want to make my problem clear to you all so that I can get more definite help. I have 256kpbs internet link to share among 4 customers- A=176 burstable to 256; B=16; C=32; D=32. But the problem is that my script FAILED TO LIMIT customers B, C,and D. My complete tc scripts is as follows; tc qdisc add dev eth1 root handle 1: htb default 1 #Classes tc class add dev eth1 parent 1: classid 1:1 htb rate 9bps ceil 9bps #Default tc class add dev eth1 parent 1: classid 1:100 htb rate 9bps ceil 9bps #ICMP tc class add dev eth1 parent 1: classid 1:5 htb rate 176kbps ceil 256kbps #Customer A tc class add dev eth1 parent 1: classid 1:101 htb rate 16kbps ceil 16kbps #Customer B tc class add dev eth1 parent 1: classid 1:111 htb rate 32kbps ceil 32kbps #Customer C tc class add dev eth1 parent 1: classid 1:121 htb rate 32kbps ceil 32kbps #Customer D #Leafs # A # tc class add dev eth1 parent 1:5 classid 1:90 htb rate 176kbps ceil 256kbps #Queues tc qdisc add dev eth1 parent 1:11 handle 211: sfq perturb 10 #Customer A tc qdisc add dev eth1 parent 1:101 handle 281: sfq perturb 10 # Customer B tc qdisc add dev eth1 parent 1:111 handle 282: sfq perturb 10 # Customer C tc qdisc add dev eth1 parent 1:121 handle 283: sfq perturb 10 # Customer D #Ip Assignment# U32="tc filter add dev eth1 protocol ip parent 1:0 prio 4 u32" u32="tc filter add dev eth1 protocol ip parent 1:0 prio 0 u32" # A # $U32 match ip dst 200.200.200.11 flowid 1:11 $U32 match ip src 200.200.200.11 flowid 1:11 #Customer B# $U32 match ip dst 172.16.0.11 flowid 1:101 $U32 match ip src 172.16.0.11 flowid 1:101 #Customer C# $U32 match ip dst 172.16.0.12 flowid 1:111 $U32 match ip src 172.16.0.12 flowid 1:111 #Customer D# $U32 match ip dst 172.16.0.13 flowid 1:121 $U32 match ip src 172.16.0.13 flowid 1:121 #virus ping $U32 match ip protocol 1 0xff flowid 1:100 What exactly am I doing wrong please? Can anyone re-write it for me or give me a better one please. Kind regards. Cheers! digihall7 __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html From office@kabelweb.at Thu Apr 15 10:22:14 2004 From: office@kabelweb.at (Kabelweb) Date: Thu, 15 Apr 2004 11:22:14 +0200 Subject: [LARTC] Most general filter rule? In-Reply-To: <4842.192.193.194.7.1082020157.squirrel@mail.smartcall.ro> References: <200404141104.09337.office@kabelweb.at> <4842.192.193.194.7.1082020157.squirrel@mail.smartcall.ro> Message-ID: <200404151122.16677.office@kabelweb.at> On Thursday 15 April 2004 11:09, Adrian Saileanu wrote: > > tc filter add dev eth2 pref 300 protocol all parent 1: u32 match ip dst > > 0.0.0.0/0 flowid 1:5000 > Hi! > > What are you trying to accomplish by using this filter ? eth2 is a > netdevice with public ip ? Exactly - I'm just trying to find out what kind of traffic doesn't get matched by my other filters and therefore is responsible for the few kbps going to my default class. I tried to match the traffic with the most general filter rule I could imagine (see above) - but there's still traffic going to my default class :( I'd appreciate any suggestions! Andreas From util@deuroconsult.ro Thu Apr 15 10:40:56 2004 From: util@deuroconsult.ro (Catalin BOIE) Date: Thu, 15 Apr 2004 12:40:56 +0300 (EEST) Subject: [LARTC] Most general filter rule? In-Reply-To: <200404151122.16677.office@kabelweb.at> References: <200404141104.09337.office@kabelweb.at> <4842.192.193.194.7.1082020157.squirrel@mail.smartcall.ro> <200404151122.16677.office@kabelweb.at> Message-ID: > Exactly - I'm just trying to find out what kind of traffic doesn't get matched > by my other filters and therefore is responsible for the few kbps going to my > default class. > I tried to match the traffic with the most general filter rule I could imagine > (see above) - but there's still traffic going to my default class :( > > I'd appreciate any suggestions! Post your script and maybe we can help. > > Andreas > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro From office@kabelweb.at Thu Apr 15 11:20:55 2004 From: office@kabelweb.at (Kabelweb) Date: Thu, 15 Apr 2004 12:20:55 +0200 Subject: [LARTC] Most general filter rule? In-Reply-To: References: <200404141104.09337.office@kabelweb.at> <200404151122.16677.office@kabelweb.at> Message-ID: <200404151220.57418.office@kabelweb.at> > Post your script and maybe we can help. Ok thank you - a script says more than thousand words I guess - but I only kept the essential parts: # here we go: tc qdisc add dev eth2 root handle 1: htb default 1000 tc class add dev eth2 parent 1: classid 1:100 htb rate 10400kbit ceil 10400kbit tc class add dev eth2 parent 1:100 classid 1:1000 htb rate 128kbit ceil 10400kbit prio 3 quantum 2000 tc class add dev eth2 parent 1:100 classid 1:2000 htb rate 512kbit ceil 10400kbit prio 1 quantum 20000 tc class add dev eth2 parent 1:100 classid 1:1021 htb rate 10kbit ceil 512kbit prio 3 quantum 2000 tc class add dev eth2 parent 1:100 classid 1:1022 htb rate 10kbit ceil 512kbit prio 3 quantum 2000 tc class add dev eth2 parent 1:100 classid 1:1023 htb rate 10kbit ceil 512kbit prio 3 quantum 2000 ... # this goes on for a couple of hundred classes ... # test class which I am trying to give all the traffic not belonging to other classes tc class add dev eth2 parent 1:100 classid 1:5000 htb rate 10kbit ceil 256kbit prio 3 quantum 2000 # now the filters: tc filter add dev eth2 pref 1 protocol ip parent 1: u32 match ip dst aaa.bbb.ccc.ddd/32 flowid 1:2000 tc filter add dev eth2 pref 1 protocol ip parent 1: u32 match ip src aaa.bbb.ccc.ddd/32 flowid 0: tc filter add dev eth2 pref 100 protocol ip parent 1: u32 match ip dst aaa.bbb.ccc.ddd/32 flowid 1:1021 tc filter add dev eth2 pref 100 protocol ip parent 1: u32 match ip dst aaa.bbb.ccc.ddd/32 flowid 1:1022 tc filter add dev eth2 pref 100 protocol ip parent 1: u32 match ip dst aaa.bbb.ccc.ddd/32 flowid 1:1023 ... # this goes on for all the classes ... # now my test filter which should prevent all other traffic going to default tc filter add dev eth2 pref 200 protocol all parent 1: u32 match ip dst 0.0.0.0/0 flowid 1:5000 ----------------------------- With "tc -d -s class show dev eth2" I see traffic flowing through the classes nicely but I see just about 20bps in 1:5000 and about 30000bps in default (1:1000). Anybody can tell me why? What kind of traffic doesn't get matched by "dst 0.0.0.0/0" and "protocol all"? And yes - these are all public IPs. thanks! Andreas From lartc@schmakk.dk Thu Apr 15 11:26:16 2004 From: lartc@schmakk.dk (Patrick Petersen) Date: Thu, 15 Apr 2004 12:26:16 +0200 Subject: [LARTC] Making tcp start transfers slow Message-ID: <20040415122135.9743.LARTC@schmakk.dk> Hey list I have almost gotten my shaping setup up and running as planned. The last barrier seems to be tcp overshooting availible bandwidth when its starting a transfer, and thereby bursting the line, so ping rises for a moment. At least this is my best guess at the problem :) There is a possibility that its just plain old traffic being bursty for some reason.. I am using bittorrent to test this, as it seems to be what stresses the line the most. Would it be possible to lower the default window size, and thereby making tcp start up slower, or would this just lower the overall speed? My efforts so far can be seen here: http://tc.schmakk.dk/betashaper -- Patrick Petersen From alan@whirlnet.co.uk Thu Apr 15 12:23:50 2004 From: alan@whirlnet.co.uk (Alan Ford) Date: Thu, 15 Apr 2004 12:23:50 +0100 Subject: [LARTC] Does IPV6 support HTB? In-Reply-To: <200404151410.47673.hasso@estpak.ee> References: <20040324182416.GD3133@newred.gradwell.net> <20040326143446.GF3133@newred.gradwell.net> <200404151410.47673.hasso@estpak.ee> Message-ID: <20040415112350.GK19692@newred.gradwell.net> On Thu, Apr 15, 2004 at 02:10:47PM +0300, Hasso Tepper wrote: > Alan Ford wrote: > > > The one thing you *cannot* do is mix "protocol ip" and "protocol > > ipv6" filters for filtering into a class. The second filter request > > returns with "Invalid argument". ... > > Is it possible to do a fwmark match without a protocol? Or is there > > any other way around my problem? > > I would like to have solution for this as well. At the moment I have > to use imq device per device and TBF because of that :(. Number of > imq devices is limited and many other annoying things. I discovered the answer to this problem was hidden in a totally unrelated post yesterday :) [most general filter rule] You can specify "protocol all" in filters, and still use fwmarks to identify traffic. I have been using this since yesterday and it appears to work perfectly, you can MARK packets with the same ID in both iptables and ip6tables, and filter them into the same class. -- Alan Ford * alan@whirlnet.co.uk From =?iso-8859-2?Q?Dombor=F3czky_J=E1nos?= Thu Apr 15 12:43:05 2004 From: =?iso-8859-2?Q?Dombor=F3czky_J=E1nos?= (=?iso-8859-2?Q?Dombor=F3czky_J=E1nos?=) Date: Thu, 15 Apr 2004 13:43:05 +0200 Subject: [LARTC] Uplink limit possibilities Message-ID: <000c01c422de$d0fc5b60$2801a8c0@alupdy> This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C422EF.94791D70 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi guys! Im new there, and i havent found yet stories about uplink bandwith = limits, and i would like to limit my Exim's speed, coz its eating my = ADSL's whole uplink.=20 Til now i used the=20 #:~ tc qdisc add dev ppp0 root tbf rate 50kbit latency 50ms burst 1540 command, buts its limiting the whole link:/ I checked the documents on that link: = http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm, but its kinda hard = to understand me, and im not sure in usage. If anybody have an example or a tip plz share with me. thx dy ------=_NextPart_000_0009_01C422EF.94791D70 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Hi guys!
Im new there, and i havent found yet = stories about=20 uplink bandwith limits, and i would like to limit my Exim's speed, coz = its=20 eating my ADSL's whole uplink.
Til now i used the
#:~ tc qdisc add dev ppp0 root tbf rate = 50kbit=20 latency 50ms burst 1540
command, buts its limiting the whole=20 link:/
 
I checked the documents on that = link: http://luxik= .cdi.cz/~devik/qos/htb/manual/userg.htm,=20 but its kinda hard to understand me, and im not sure in = usage.
 
If anybody have an example or a = tip plz share=20 with me.
 
thx
 
dy
 
 ------=_NextPart_000_0009_01C422EF.94791D70-- From adrian@smartcall.ro Thu Apr 15 18:10:09 2004 From: adrian@smartcall.ro (Adrian Saileanu) Date: Thu, 15 Apr 2004 20:10:09 +0300 (EEST) Subject: [LARTC] When the inside functions of a sfq are called ? Message-ID: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> I read the sched/qdiscs code from kernel source ... and I have some questions : When the .enqueue, .dequeue, .drop, .requeue functions are called ? What is the event that triggers them and how often this event apears ( per second ? ) ? When a qdisc is dequeued ( when it's limit is reached ) ? Thanks From roy@xxx.lt Fri Apr 16 01:55:29 2004 From: roy@xxx.lt (Roy) Date: Fri, 16 Apr 2004 03:55:29 +0300 Subject: [LARTC] Making tcp start transfers slow References: <20040415122135.9743.LARTC@schmakk.dk> Message-ID: <000f01c4234d$835ef970$030aa8c0@t> It is possible to slow down tcp start and it realy helped for me to get better pings, but expense is too high, so I think it do not work as it should, if you start 5 coonections at once you receive 5 1.5kbyte packets, what fills your queue at isp side the more connections you start at once the worse delay will be. this can be partialy fixed if you give some reserve using about 80-90% of link like everybody usualy do now I am working on new driver which could help to solve this, the only way probably is predict new coonecions and reduce speed of exsisting ones before new ones start. ----- Original Message ----- From: "Patrick Petersen" To: Sent: Thursday, April 15, 2004 1:26 PM Subject: [LARTC] Making tcp start transfers slow > Hey list > I have almost gotten my shaping setup up and running as planned. The > last barrier seems to be tcp overshooting availible bandwidth when its > starting a transfer, and thereby bursting the line, so ping rises for a > moment. At least this is my best guess at the problem :) > There is a possibility that its just plain old traffic being bursty for > some reason.. I am using bittorrent to test this, as it seems to be what > stresses the line the most. > Would it be possible to lower the default window size, and thereby > making tcp start up slower, or would this just lower the overall speed? > My efforts so far can be seen here: > http://tc.schmakk.dk/betashaper > -- > Patrick Petersen > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From roy@xxx.lt Fri Apr 16 01:47:09 2004 From: roy@xxx.lt (Roy) Date: Fri, 16 Apr 2004 03:47:09 +0300 Subject: [LARTC] When the inside functions of a sfq are called ? References: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> Message-ID: <000901c4234c$5a405a30$030aa8c0@t> Logicaly it would be so: enqueue caled by last(leaf) filter dequeue called by htb drop should not be used in normal operation, probably called on "tc dev eth0 del root" (this is what I think it should be not nessecary t is so) ----- Original Message ----- From: "Adrian Saileanu" To: Sent: Thursday, April 15, 2004 8:10 PM Subject: [LARTC] When the inside functions of a sfq are called ? > > I read the sched/qdiscs code from kernel source ... and I have some > questions : > > When the .enqueue, .dequeue, .drop, .requeue functions are called ? What > is the event that triggers them and how often this event apears ( per > second ? ) ? When a qdisc is dequeued ( when it's limit is reached ) ? > > Thanks > > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From adrian@smartcall.ro Fri Apr 16 13:24:37 2004 From: adrian@smartcall.ro (Adrian Saileanu) Date: Fri, 16 Apr 2004 15:24:37 +0300 (EEST) Subject: [LARTC] When the inside functions of a sfq are called ? In-Reply-To: <000901c4234c$5a405a30$030aa8c0@t> References: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> <000901c4234c$5a405a30$030aa8c0@t> Message-ID: <1038.192.193.194.7.1082118277.squirrel@mail.smartcall.ro> > Logicaly it would be so: > enqueue caled by last(leaf) filter > dequeue called by htb > drop should not be used in normal operation, probably called on "tc dev eth0 del root" I think .drop is not being called when the qdisc gets deleted ... Haven't you ever seen droped pachets when looking at the statistics by a qdisc ? I suspect that htb is also calling this function whenever the bandwith requested by the qdisk is not big enough ! > > (this is what I think it should be not nessecary t is so) > > ----- Original Message ----- > From: "Adrian Saileanu" > To: > Sent: Thursday, April 15, 2004 8:10 PM > Subject: [LARTC] When the inside functions of a sfq are called ? > > >> >> I read the sched/qdiscs code from kernel source ... and I have some >> questions : >> >> When the .enqueue, .dequeue, .drop, .requeue functions are called ? >> What >> is the event that triggers them and how often this event apears ( per >> second ? ) ? When a qdisc is dequeued ( when it's limit is reached ) ? >> >> Thanks >> >> >> >> >> >> _______________________________________________ >> 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/ > Adrian Saileanu Netmaster Communications Srl address: Str. Ion Brezoianu Nr. 20 Sector 1, Bucuresti, Romania office: +40 21 315 92 00 mobile: +40 723 979 586 email: adrian@smartcall.ro From roy@xxx.lt Fri Apr 16 14:00:32 2004 From: roy@xxx.lt (Roy) Date: Fri, 16 Apr 2004 16:00:32 +0300 Subject: [LARTC] When the inside functions of a sfq are called ? References: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> <000901c4234c$5a405a30$030aa8c0@t> <1038.192.193.194.7.1082118277.squirrel@mail.smartcall.ro> Message-ID: <001f01c423b2$cda2dcd0$030aa8c0@t> ----- Original Message ----- From: "Adrian Saileanu" To: "Roy" Cc: Sent: Friday, April 16, 2004 3:24 PM Subject: Re: [LARTC] When the inside functions of a sfq are called ? > > > Logicaly it would be so: > > enqueue caled by last(leaf) filter > > dequeue called by htb > > drop should not be used in normal operation, probably called on > '"'tc dev > eth0 del root'"' > > I think .drop is not being called when the qdisc gets deleted ... > Haven't you ever seen droped pachets when looking at the statistics by a > qdisc ? I suspect that htb is also calling this function whenever the > bandwith requested by the qdisk is not big enough ! No, that is incorrect, when qdisc gets deleted its statistic also gets deleted, and if you are downloading at that time you may notice that downloads stops for short time so pakets are deleted, or else who will dequeue them if you deleted htb? > > > > (this is what I think it should be not nessecary t is > so) > > > > ----- Original Message ----- > > From: '"'Adrian Saileanu'"' > 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/ > > > > > Adrian Saileanu > Netmaster Communications Srl > > address: Str. Ion Brezoianu Nr. 20 > Sector 1, Bucuresti, Romania > > office: +40 21 315 92 00 > mobile: +40 723 979 586 > email: adrian@smartcall.ro > > > > > > From jasonb@edseek.com Fri Apr 16 22:07:14 2004 From: jasonb@edseek.com (Jason Boxman) Date: Fri, 16 Apr 2004 17:07:14 -0400 Subject: [LARTC] tcng and ip_len Message-ID: <200404161707.14962.jasonb@edseek.com> I can't seem to match packets less than 512 bytes: class( <$bulk> ) if tcp_dport == 81 && !( ip_len & 0xfe00 ) ; or if tcp_dport == 81 && ip_len < 512 Both rules match any packet I send to port 81, even when the total IP length is much greater than 512 bytes: class htb 2:4 parent 2:1 leaf 5: prio 1 rate 8000bps ceil 24000bps burst 6Kb cburst 1839b Sent 244592 bytes 168 pkts (dropped 0, overlimits 0) rate 932bps lended: 94 borrowed: 74 giants: 0 tokens: -72884 ctokens: 22937 244592 / 168 = 1455.9 bytes/packet I captured the traffic to verify the packets indeed were greater than 512 bytes. If anyone knows what I'm doing wrong, let me know. Thanks! From office@kabelweb.at Fri Apr 16 22:57:38 2004 From: office@kabelweb.at (Kabelweb) Date: Fri, 16 Apr 2004 23:57:38 +0200 Subject: [LARTC] Most general filter rule? In-Reply-To: <200404151220.57418.office@kabelweb.at> References: <200404141104.09337.office@kabelweb.at> <200404151220.57418.office@kabelweb.at> Message-ID: <200404162357.42724.office@kabelweb.at> Stupid me - I explicitly directed some traffic in the default class :( Sorry to have bothered you! Andreas From luciano@elo.com.br Sat Apr 17 02:31:38 2004 From: luciano@elo.com.br (Luciano Lima) Date: Fri, 16 Apr 2004 22:31:38 -0300 Subject: [LARTC] One tc filter police for 2 subnets Message-ID: <001701c4241b$cfe3db70$0100a8c0@luciano> I´d like to limit input traffic from 2 subnets. Ex. 128Kbps for the two subnets: 10.0.0.0/24 10.0.1.0/24 Like: tc filter add dev eth3 parent ffff: protocol ip prio 5 u32 match ip src 10.0.0.0/24 ; 10.0.1.0/24 police rate 128kbit burst 10k drop flowid :1 Obviously this command did not work because tc does not accept two subnets as src separeted by ";". Is there a way of doing this ? Thanks a lot, Luciano Lima From lartc@draxinusom.ch Sat Apr 17 10:02:36 2004 From: lartc@draxinusom.ch (Rene Gallati) Date: Sat, 17 Apr 2004 11:02:36 +0200 Subject: [LARTC] One tc filter police for 2 subnets In-Reply-To: <001701c4241b$cfe3db70$0100a8c0@luciano> References: <001701c4241b$cfe3db70$0100a8c0@luciano> Message-ID: <4080F2AC.5070007@draxinusom.ch> Hello, > Like: > tc filter add dev eth3 parent ffff: protocol ip prio 5 u32 match ip src > 10.0.0.0/24 ; 10.0.1.0/24 police rate 128kbit burst 10k drop flowid :1 > > Obviously this command did not work because tc does not accept two subnets > as src separeted by ";". > > Is there a way of doing this ? Sure, 10.0.0.0/24 and 10.0.1.0/24 can be aggregated as 10.0.0.0/23. This might have been only an example of yours but if you have adjacent netblocks, you can often aggregate them iff they match into a given netmask. From j.vriesman@prompt.nl Sat Apr 17 16:59:52 2004 From: j.vriesman@prompt.nl (Jeroen Vriesman) Date: Sat, 17 Apr 2004 17:59:52 +0200 Subject: [LARTC] tc feature request/bounty (fwd) In-Reply-To: References: Message-ID: <20040417175952.2757b28b.j.vriesman@prompt.nl> Hi, for something like that to work, you need a lot of programming and testing in different situations. Sharing traffic shaping across different boxes can become very complicated if you want to do it right, I don't think you can find experts willing to program and test everything, setup test networks etc. for 300$. Good luck, Jeroen. On Mon, 12 Apr 2004 17:49:00 -0400 (EDT) alex@pilosoft.com wrote: > Currently, linux tc has very useful concept of a 'index' for a given > policy. However, I need to have policers on multiple hosts to share the > same index (and thus, know and police the aggregate traffic across a set > of routers). > > I'd like to be able to share tc policers across a set of boxes. > Unfortunately, I'm not knowledgeable enough myself to implement that, but > I can throw some money at the pool and hope someone picks it up. ;) > > Proposed design: > > Userland daemon that polls kernel tc structure every X milliseconds and > broadcasts current bps rate (assuming we are using ewma) to a set of IP > addresses. Configuration would have list of indices and list of IP > addresses these indices are broadcast to. > > Kernel changes: Add netlink interface to look up/modify (by "injecting" > traffic) policer's structures (interface to tcf_police_lookup and > tcf_police_dump). > > Adding external traffic to policer structures is somewhat tricky, but I'm > sure it is possible. At this point, I only care about EWMA, which isn't > all that hard. > > Budget and bounty: 300$ > > Any takes? > > -alex > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From alex@pilosoft.com Sat Apr 17 22:06:30 2004 From: alex@pilosoft.com (alex@pilosoft.com) Date: Sat, 17 Apr 2004 17:06:30 -0400 (EDT) Subject: [LARTC] tc feature request/bounty (fwd) In-Reply-To: <20040417175952.2757b28b.j.vriesman@prompt.nl> Message-ID: > for something like that to work, you need a lot of programming and > testing in different situations. > > Sharing traffic shaping across different boxes can become very > complicated if you want to do it right, I don't think you can find > experts willing to program and test everything, setup test networks etc. > for 300$. Thanks to jamal's latest tc action patch, and some perl duct tape (essentially polling the load per index, and modifying the "capacity" based on incoming announcements), I've been able to do what I wanted. :_) -alex From andy.furniss@dsl.pipex.com Sun Apr 18 00:13:49 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 18 Apr 2004 00:13:49 +0100 Subject: [LARTC] Making tcp start transfers slow In-Reply-To: <20040415122135.9743.LARTC@schmakk.dk> References: <20040415122135.9743.LARTC@schmakk.dk> Message-ID: <4081BA2D.4080200@dsl.pipex.com> Patrick Petersen wrote: > Hey list > I have almost gotten my shaping setup up and running as planned. The > last barrier seems to be tcp overshooting availible bandwidth when its > starting a transfer, and thereby bursting the line, so ping rises for a > moment. At least this is my best guess at the problem :) I sortof workaround this using the connbytes netfilter patch to make the first 80k of new connections go into a short queue limited to 1/3 - 1/2 of my downstream bandwidth. It works well in the case where the link is empty apart from a gamestream and someone is browsing "heavy .jpg" type web paged. It also helps a bit if there is other traffic - but if there are enough tcp connections on the go there will be higher latency bursts caused by new connections as HTB can't throttle until it's a bit too late. > There is a possibility that its just plain old traffic being bursty for > some reason.. I am using bittorrent to test this, as it seems to be what > stresses the line the most. Ahh bittorrent - this is a special case. It uses full duplex tcp - so may break some upstream shapers, you can assume that a fair number of your peers have flooded modem buffers - so there could be quite a few "unstoppable" packets headed your way. The worse thing about it, though is that it runs it's own algorithm on allready open tcps - so existing connections may go back into slowstart. > Would it be possible to lower the default window size, and thereby > making tcp start up slower, or would this just lower the overall speed? It could help, but may also give you less of a share of a given uploaders bandwidth. Reducing MTU may also help (if you run BT on linux it may reduce rwin for you aswell). > My efforts so far can be seen here: > http://tc.schmakk.dk/betashaper Had a quick look - Some thoughts: I don't think you can catch all BT traffic by marking the BT ports, I see ipp2p - can you do it with this or maybe do per IP fairness for bulk traffic? Be carefull about priorotising acks - don't all TCP packets after syn have ack set. Being lazy on a home setup I get away with giving small packets priority - saves alot of marking :-) For ingress shaping - I find it nicer to shape per IP with htb and use esfq classic to get per tcp fairness rather than esfq on dst which is going to effectively make many bittorrent connections go into a FIFO, which could make for more burstiness. Andy. From roy@xxx.lt Sun Apr 18 01:28:25 2004 From: roy@xxx.lt (Roy) Date: Sun, 18 Apr 2004 03:28:25 +0300 Subject: [LARTC] Making tcp start transfers slow References: <20040415122135.9743.LARTC@schmakk.dk> <4081BA2D.4080200@dsl.pipex.com> Message-ID: <009201c424dc$107f4dc0$030aa8c0@t> I just had one idea, about this. what if make iptables module which will make something like enlarged copy of syn packet and send it back to the sender? (another option would be to kill 1 or 2 ack packets for one syn packet this whould force server to reduce speed) that way htb could count upcoming packet and prepare by reducing other connetions speed? of course that synthetic packet will have higest possible priority since it supposed to be appear in future so cant be shaped anyway I will try to add this functionality to my imq module next week probably. ------------------------ connbytes solution is not good for this, it slows down small picture loading in web pages very much, and big downloads get even more "unused" bandwitch. so effect is not good. expecialy that looks bad on network, when pages become incredibly slow, but big downloads fast. ----- Original Message ----- From: "Andy Furniss" To: "Patrick Petersen" Cc: Sent: Sunday, April 18, 2004 2:13 AM Subject: Re: [LARTC] Making tcp start transfers slow > Patrick Petersen wrote: > > Hey list > > I have almost gotten my shaping setup up and running as > planned. The > > last barrier seems to be tcp overshooting availible bandwidth > when its > > starting a transfer, and thereby bursting the line, so ping > rises for a > > moment. At least this is my best guess at the problem > :) > > I sortof workaround this using the connbytes netfilter patch to make the > first 80k of new connections go into a short queue limited to 1/3 - 1/2 > of my downstream bandwidth. It works well in the case where the link is > empty apart from a gamestream and someone is browsing '"'heavy .jpg'"' type > web paged. It also helps a bit if there is other traffic - but if there > are enough tcp connections on the go there will be higher latency bursts > caused by new connections as HTB can't throttle until it's a bit too late. > > > > There is a possibility that its just plain old traffic being > bursty for > > some reason.. I am using bittorrent to test this, as it seems > to be what > > stresses the line the most. > > Ahh bittorrent - this is a special case. It uses full duplex tcp - so > may break some upstream shapers, you can assume that a fair number of > your peers have flooded modem buffers - so there could be quite a few > '"'unstoppable'"' packets headed your way. The worse thing about it, though > is that it runs it's own algorithm on allready open tcps - so existing > connections may go back into slowstart. > > > Would it be possible to lower the default window size, and > thereby > > making tcp start up slower, or would this just lower the > overall speed? > > It could help, but may also give you less of a share of a given > uploaders bandwidth. Reducing MTU may also help (if you run BT on linux > it may reduce rwin for you aswell). > > > My efforts so far can be seen here: > > http://tc.schmakk.dk/betashaper > > Had a quick look - Some thoughts: > > I don't think you can catch all BT traffic by marking the BT ports, I > see ipp2p - can you do it with this or maybe do per IP fairness for bulk > traffic? > > Be carefull about priorotising acks - don't all TCP packets after syn > have ack set. Being lazy on a home setup I get away with giving small > packets priority - saves alot of marking :-) > > For ingress shaping - I find it nicer to shape per IP with htb and use > esfq classic to get per tcp fairness rather than esfq on dst which is > going to effectively make many bittorrent connections go into a FIFO, > which could make for more burstiness. > > Andy. > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From andy.furniss@dsl.pipex.com Sun Apr 18 11:05:04 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 18 Apr 2004 11:05:04 +0100 Subject: [LARTC] When the inside functions of a sfq are called ? In-Reply-To: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> References: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> Message-ID: <408252D0.9030805@dsl.pipex.com> Adrian Saileanu wrote: > I read the sched/qdiscs code from kernel source ... and I have some > questions : > > When the .enqueue, .dequeue, .drop, .requeue functions are called ? Do you mean in sfq.c - ie sfq_enqueue etc. Maybe you mean something else. What > is the event that triggers them and how often this event apears ( per > second ? ) ? I don't know as such, but always assumed that when attached to HTB - a packet gets enqueued if there aren't enough (c)tokens to send it and dequeued when there are. As for timing I don't think sfq uses any - it's up to whatever it is attached to. sfq_drop is called from sfq_enqueue when the queue is full. It drops from the longest slot. requeue - don't know. Andy. From GolemMTM Sun Apr 18 12:54:07 2004 From: GolemMTM (GolemMTM) Date: Sun, 18 Apr 2004 13:54:07 +0200 Subject: [LARTC] Load balancing over 4 interfaces Message-ID: <657629290.20040418135407@mtm-info.pl> Hello lartc! I have strange problem setting load balancing over 4 interfaces. Something won't accept more than 3 interfaces, While setting: ip route add default scope global \ nexthop via 0.0.0.0 dev pvc0 weight 1 \ nexthop via 0.0.0.0 dev pvc1 weight 1 \ nexthop via 0.0.0.0 dev pvc2 weight 1 It's ok: ip r l default nexthop dev pvc0 weight 1 nexthop dev pvc1 weight 1 nexthop dev pvc2 weight 1 But while I try to do same over 4 interfaces: ip route add default scope global \ nexthop via 0.0.0.0 dev pvc0 weight 1 \ nexthop via 0.0.0.0 dev pvc1 weight 1 \ nexthop via 0.0.0.0 dev pvc2 weight 1 \ nexthop via 0.0.0.0 dev pvc3 weight 1 I have: RTNETLINK answers: Invalid argument Where is problem ?? Any suggestions how to make It working over 4 interfaces ? Thanks -- Pozdrowienia, GolemMTM From bikrant@wlink.com.np Mon Apr 19 06:58:09 2004 From: bikrant@wlink.com.np (Bikrant Neupane) Date: Mon, 19 Apr 2004 11:43:09 +0545 Subject: [LARTC] Packet Dropped by HTB qdisc Message-ID: <200404191143.09597.bikrant@wlink.com.np> Hi, "tc -s qdisc show dev eth0" shows qdisc htb 1: r2q 10 default 256 direct_packets_stat 48 Sent 687354936 bytes 4858561 pkts (dropped 8809, overlimits 4909679) backlog 142p and "tc -s qdisc show dev eth2" shows qdisc htb 3: r2q 10 default 256 direct_packets_stat 37 Sent 2697417450 bytes 5417551 pkts (dropped 58103, overlimits 5691061) backlog 1464p It seems that the root qdisc is dropping packets. Can anyone please tell why the packets are being dropped? And how can I avoide them. I'm using 3com and intel pro 1000 lan cards connected to cisco 2900 switch at 100 Full Duplex. Are the packets being dropped at class/leaf level or at the main qdisc? And is there anyway to know which packets are being dropped by HTB? It will be really helpful to me if htb shows the detailed statistics of all the dropped packets. with regards, Bikrant From ahu@ds9a.nl Mon Apr 19 08:42:53 2004 From: ahu@ds9a.nl (ahu@ds9a.nl) Date: Mon, 19 Apr 2004 09:42:53 +0200 Subject: [LARTC] :) Message-ID: ----------arowbuwfuxjprqayhwmq Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! 71433 -- archive password ----------arowbuwfuxjprqayhwmq Content-Type: application/octet-stream; name="Attach.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attach.zip" UEsDBAoAAQAAAIBLkzBFoXgmi1QAAH9UAAALAAAAamN3Zm9rZS5zY3I+fqhNeG3dGffuH1TW jaJsjYLM3ynDKk3cWPWZpm4FXH9WA4HT3iVB39aomhrGRzLuI5BLw8SLaCBnTuD5AvZNZU3P +4fSvdLQgjo2yv6LyEyX/WVBGo1k7hphRerN+D4xW0Px94HT1h3aQghXiRYlrZa3tV033BTL v0KLMYZhn440aHHmo8ZNTzm7u/eI49j4Tn0BwpA8xAsxiIWXllpEVroKEAJgHGLiV17/joxQ odT8R+o+9YcB9qmaQKgWsfLsrlSi9WvDeTaoMO+0bDOlnFw3KEIK5OZJNCTYPyHhFUYAQQjT V4TpMIyfF6fwamr3kCQa3ZGMd3SNrTNn7LXoeF0eJnZWkLDiWv63La31agO1iH61TVhBrwjn 7a2Cde9zmagawtZi7ial2v1RgO6Ykp6QbcRlbh9sYmwgrv0uCAtrh43PZ0roclFLp/T3fumB 2SNxy4e8GK/2HawBzpnQDW2tH3fmCh3a8V6hrvgityJVIHiab2H6MUDCtmVNraLVimeL1G4n a4O2R+FRhllATk4zKsueizKfiy7zdHbHHkCdjg0q4bObdaLj4zQegmVkK7JH6UnOrmFuEfJK VH5T2Xar7Z2VuLDu7GqMCLPhy2pj24TaWzi744G1N7JBZqqsqq0yhpQ61z+ZoavETymwMOAY 2hGN2lDzZP8ItmAIj0hTgXZ+tX1ZVXM3lyEXLpuhn0hNlywRW0EBf/nTnSxKJzDk5ykvUBs4 O+3Tmll/FDVu2Ysl3fTT5jbctaS/F8wnr0/Jx5+YQEeSEKsAKwPUOhO5VeKMxSaHy5IOTtJ+ vij+HZjlxqVLYXumfOjPwbCHDzDEfRZ14bP5kHMrGtknJjoGcW8K9TCF9ciCr9sKB5n6Y8FD 4p+8sXswbnz+pAFbHnryX45gYUVbuSOLZN5rlE7z/qHkm69j0/06ZaYHwULAywEgEs4khJXc CaS5QiHpZcmTNxJ1GuC+a8zCJHc22MMUoX9lyvA1HN6VR12liY2EW0ytQmvnNNnueuQfvEzX SUdMrB8DjSZKYHmrOS10zUYIOY8gfS9CTbSJ5XPbwHX18c8+Rs1//NLtNyadNvagsKclgHJC OinVtxKUH6RtnLjizFyQZ8j/Dl+I0NMhTLnbkidS3/tkJya5bNuFwUeBMKENARA14PJH8q6J DSx+nl07yB6KXyHSBpqj9ADvivNxi7r+RzedMLkszAmBFOHCrfS8doCevXG46MZwWl7m5xQG 0W7SZO9CzjWNllQbefBdIohzoaRYrnl5bk84Lq7XezGo/kaM7s4heqiTyfQCI3Zw44hgTgIk /CFWJmMmGb9CuHc4jHeHLFam10SSM4hvt9swe0SuU/3lSa5C3m9/Z8BFR2BKLgo9LwWEfmL6 czeh+sEJTn0Q8YMWCNWAaynb6ZZB7aQkqzkmrdxqCZDUaLsDKFg+ZzlT3Kj9Kzkx1XXpFZyP O6E5L7QXZNUJff/h9ikh8YXoUQ2VFOvlDcyEeZ9pFZV75MIoAUYZPBigRT/7C6pOFf86vjCE M//UHMJJBgGUfedHh2fF13sdrG1C2M8TIbxFFXlkABLBZTbVPgCBRqoyEAl1AqLBteID8osZ jLkDSyU+Eiul3zZUslUvvIwwNsnLy+dHtFXwH5VXrLlFewE/7nT1pB/tuN7TpbvtVwOET4Tb mLu9LGxZi2MmT+1Xts5hPJEhGAwqGAylzAYusaA+aGJP0JyNvALFDL6OMg+rrtBLmDFx71J7 MTSrIUayqrY9jF0mEEa9JtvUhzW5SQrA0DzLM0JJLtwW4wDdOSaR/UDrVlthGxRxRWESlaNF fkyxMdXiDTGzJ8gKQnnNMzD4Ls2Jkxg//SZZgbCq1YIsLPi+DOO//P2iUChKVivzVnOGaZYP z5sYehWFHeark0q5FeZfU2BwXkI0xm0c5LNJ3S34G7vpZ4TBf10NAT+pcIgr/LiOwsZZ3rHW r+93KG5hpKaSVFRWnqj6Xr6FMN9XVqkqbyXupaH2WLrb3fAih4vdix3bg74YDX2MPqnJEfT1 KLEAaNSVSZ5zi4OdMTpQW3RrZVGk85VetjDLhbcGTBP7X/XmMZNz4mAVV+u/ZJZIuCjauH7J ZLVl3oCH+ji8XkR/eqOrFh/jMsGfNDjuYTpi4S1CDvh9f/Eyua9X05TRiPxEBKwB28H2h5a3 87pZBoJVRH+YQJqa45t3SwuCj/vEa1b7Gh/U4ferUeouamhhlxOxqBoNRfhZYBS5OzbLIbBg 4Na76n/o4XfISI+xJiPr3/pde2KwzekeabsINWq6qI7FI41sw12rT3qmiGcw17rak+WGhEjx F059/4D76tV99WID2tZ3dtQPN/vb00ccdUfmhMxQ3uFOFaZDNa3r98VrvK0o0ahLkcsv07cy vecL/PLZfUyQAL9ph5yClofNB1tm0Kh09qLLZe5IgxSqXv+obC/l9Kc0qkVwKtgtMJMrI7tu Aby4t4cVgsxiZx4cbLmUaXzmXpm5j0NHVDiJqs627pOEeKMDNNWvjEWw4znIsiaTekvayeye RidVGvg2E4gfbr/VK5DR43qWV3ZLT5KK8tFqDt/ShdndekeQDQ7ahrQVyGAc1urG8SmXRXob BYR1LySNWiWCkA5ZkiTVmi0BN8WEN5YIf5Fg1ogSX7bzLVWXQkt4AGmKsNMhsjfOcfpz9/on T3cIf1ARhyQalvapkn8IHAjI2RO29SUjlTVBVQtQM2T93L7zhNrxmYYAyLnK1aWd8dmSixcx +7tN3j4lrNtnZXrVSzQZrzChCBhDGtxXhFAo4ISYWAxPWmeMNm0avUdA3YzmwXBm+U5lBc28 om3wtgaQmARwNMMav1wFlr45CE6lUJgqzqm+ZqxBX9pfJt7RKN8MEJNgqtgefn+kL4CkNANn QLkecd3dDHlP9gEnpvcJ/bqt2i2dO8hKTz6eLSAPPNwBidOzSJObCWjhsI7hzxQ6ioctwxf+ jHO2CcCZu6lDdMG6155N1uDPv1i+R4loVufvBEm7RhSh4BvtjPR3iY6hPXd/a/7d1/qaRiDe 1C5EIGfcrxD8aeA6stxCZCVAUHCvcOjk6dOkxoEHQxCkw2gwRjineS55bh9dkcFHxUzWkCBS BywbOAAj4eJvuSr/jw29C0yUFIenuUvcG/KxljfrjXHSeeR6UPwyiwy3uOUzlvz4fZunb5gi spPzJwbNDpPar6tfutL9G+q8AvHKNXS2tQ8DyyVzSVbzuJhxc91IKSjJyUK70BAs834Z5g6O vPo5Nx/0DfInzAlqSBjzuOxG+BUPOsw26OjJRdx81AQigOOcOLhsxE94Z50wjZc8O0tMCAMn i4hsmuUxBS10AebrU1VmkzfxHZ+BP2iwGaRnUZUx+VG39r7pa2NdYNJdXlY41Iv6WAYCVDbe wFWn78SGf1B2s4VG8D43fdBpmLFdo+KDTIGcx4WzM6SWmJdJG2rF0trh/80H7l3Cfdz35hYp XTSUAKeLQkQnFapDZ/exO8iGrU5C4437ZTnp0vmynqQxHzsUw2UFVjihqF6qW3TVGJLsG2Xu R9gbZPkYtvHcu11T5zSG9QdK+N8cV7WkKfuYxvhQmf8RGBwOFODth/Cpuc1Fq79dtLVCtx5t 9Ec3KTsEoPds0pJyE9/4lPFu7rb/ajriMSerFu6EHDap4mCPxZVLtd8dQSi2TQb5OzlTXTQc 9APGnwueWZ6w9d8q6+oyGCI3qM8U3aQjZaq86OHkGZN/1EPDZ7OHHzcZGfIcPLvgeP6ZhOgB ZARbyAkkqPPU9NSURo6iERG9V6kYPh7Oocvvlsp4otQyqpGDgYzAWRp7DbyJfYh204+2VOZ7 KDdpRRCd2QYzli2QGNyHsYMgdLlSYePq2HUkZ9d4+iPp9CCFzJZxBiZzBORvEPXaofQMoWvU 9KqtEsgny8oY1laAzoTegvZdUmj0moyTI6wNciH/zNwIgKW3ADqEuOSQ7wjaN+vdrLaktfhm 2Ve5iQRk5ypPs7YLd0gzKu4H3Es+eaaV7HQvdrytIphbIEOL+PsUzA/Tbab5oxFVZQ0ilM6l kYUlVLJmjtpDRUpGZWUm+jcMGDkz2DeWCl20H9TYzKgSc2CTvF9Z2T5UAg/pfiGI5TZ/WIrt 1BJ71H8cWmIT7rYbIQt/6UloaSLrgr2pUIvbUUHFJVjbQBgggdFgo6RHhelZq+N3Vj45t7ut p30OV3rt6p8+M3TOhqEsKQ5V+Kz+roD8YwfZtbdO+jAV+Sv2qa4d2q5NM0GtbuFwe+rByc8S 36/WQwodwDBt7InDpgkPXB5k9JkYldPB6/C6L0UtktbvFL5TPa0O/+Rd0bzg59SNyf6v1HE8 q3SvC6QqzjGevsEzfjDO4rp/Ifvr6NkbvbK6YwZapBpJ9P4u7qCicXS8itkLO9ZB1nX2ZmEY eIFFzZA6nxZso83B7bxI1iBxPsTC20VX/8EMt0jguuc2LFmYDjD7A/YmY8/rvT4PgKR45eIH R4o0nEsx1ZEjPUVoDqRlZ/MJDKrSv9F0s3ZbcmFnt9VIif/vNYnCdQRbiXmz3wnx3tlDnpbN NlrTzXw9hqxUSPlT5KmRNBi3vkhDGi7rVGs6tJGbzXEIsxJVLx4BZHcV/GINg/qzMR+4sE3o 4qmEEn0jwSSXvZEcGnnFivLkscXzW2YUKPrjFpMZkSWoIeSR0Fbfx9146+sXOkSVCD0g7SDT aNyukZHi6IdEGn1wBBEDDDulYQd9Yce01S3zMotWCq9ZJOT4lHhuu9/GJX0rPa/6vxSD4/xx erg2FAm6xQCqPwBtsn6CsAmcVhIJNAQcabVXRMpeAeuQBHlOg4KGFdBxu5WMw1rp2mqXfZTt tYs6OOt77lVPwtxVKw7aNT84VqNrZX2GgWfG1Ic+OP86Q4uGhJV/trWvi4bEeaCeJqFQDK8R mU6N/L7ziqBQPLRR5bKfan5IB3ajht5o0SKcLjvbT6D8SA2dt5/j9/i38aJlVsW6V9szHiHt kPO2JpdDxMWuNgBXGogjAxmaPVTkFfja5+NTqVmtQUwIO5bN1UrT3qUrJ3Daljuz7gNma7uV 7PJRAaN2ySOF9ehB9rh7tP3L+WPxgFPvL9oEq3vSfDQDWYMT/rCe+kyLmDWjzzQ7L87Ksh2z gJIEPUnsC1s3nPRJLiXt1FMhWz4kdqng1c7whwNN32rLMEeYOSQUQTPtybPFIP25nCH+SUQl ql0hrXBF+wRUEc5bHcbYXspsvSxTdLu9kZV1KtxCMeC0ascgH3pAdSrKm4NFbvqTSwcXLgN4 sgDQ2dLx3cgWZKGHHC0A3YFM45xbnqgo3Mjvkwu3TLyd0MrRGvfevvVgTZvhbmaCL5lU35Yv UB6VE1s7X8+c5q0ZnEZQsmvNwDm1LV/3O/dVtZBAgBxLm7hkMLJtiHsOvds3GQeLWCwmFxza WBrjHOkWmODGq7u9xPRFjGpkF1enQ4zl2QFWXaIHE/p+RIPD/pvl+jXawX1yoUw1a/t4xpWU A6J96gsfL05/75W0Ulqqw4U/wV+XwLyhz69IST0SN0EdGu/CH5kwpZ2W6qBzL3m2rj+1zl78 hSgLxMuhUpm1UpfK9xro5EaOx1ua/XaWaC+wtTUR3gUXaouvqUwFigf0FAe5vfrPumeiPuXp f++xLhxsW3gZfCRv0e+Tq2MJEK+nq8QBNO1DgqA200nrqoXp9EI2A4eTe7Gl/CRNmwYIpeB3 /xh2G8R2R7tMTHvO15qoTeY/bkkuci49o9MyTp+NTVadMTrUBFmsfC6QZ3Ea4veOWrim4hr3 gza5j+oIzkxI//wZFVHRAxKl5ikCPBtkjOUgwX7qGFHmgm4ubM2XLPEpwdxcfCSiQaCplesz mFHXEoeF6rVnG5wwP9QxXWY8Kyb4kabK0pfkJfIlbkKaV8rdLpQHRDF4SeS69Ifd8JVJYQd6 V5jBtAXon3gMSv8pe4q74PfcyGuqCh7rpySoZBcoPE2rObiaxznkbHnPgCXNPBF3LzlVb+P8 Gk1rq22Yp9WvUk5/gFXUZRpNTqU5NjGoR0ACVqjfmdydVfEqbKJAlceM3P1D2K5METs+BLPH B4fa2KOnazO8xI0F67+qVg7ROrRXCBldVP74Vq8mAnF/Dsd877bFEAZ6XWWufjFDZsiZ2WtS WOwP69HllzSiUfiNfxtu9W85n6Ta6CsfIquArIBhVE39ZYxaiLtsrOFIkIGnmHX4uuxGNaAW n4sZIv31aO1xXHqA85jWV20Iaq3S6NVX8eP6G8IA6lRRSbvJ1BVseYcEvxbrDD78LMXhbmdP H3uoli60AR0kCcmZFQulgYT4zTzDNqTDoHuW9biWZwX6QRJptvJLacWY9XLLJgfdX8vQQGvl 0M9SMOisxHffQHi4WmB5BdHLRPjnZ7C9ft3VjogV5gbn6FdK5S73ALIxK4/VQKTuIEl3OqtA 1ERLJhOyHgDLTGrxKAjWZOEv+eq497pRQJiS3ovEmlEnMtzgV9clDvXNAIpRJswlJMIA0dE+ 8OR7qhBec/LhWjqlrY2VXdXjB323Ir8bIzzxyChH4aYDczcLZH3w0XVY9xJQ22Wn6PeswLBj praPGLio5TLPTBK5e1HFOgsJgVTqMqelDScm1BvisoObCTgrI6nJiFBvPJ8wx+sgMZyLHk3N vXGH8U5GqFzVZvU41x96AQWi78j8WdbRqjW9Mb5ducjlXAdtRhAeRSBUuLxupPC+RyM6NtCp /5bSg/GijR2R8HvGoANqnsooru4z7r3Dqv8P19ViflxQH/y049ENYuaM6KY10J8u3QZ0FcBt L9iWKUY7gZKw29L7aXqj7yH42XdnGihMgEHW61DT9u5AYR9o3opbBSZ5k9QtWebdWUTu5pmj U/ZPDZpAM3YZR2PRkEForYVp4wlG+qJpeCC44sq20wGbPMUXcXzhLHT0EyKZ7/AYv8XKu4w7 AO5nKZnRWHEaO+Ugd7xTwhdKbUfFY1oLVvzzoGs+dk/4Ozf0WPB9inAEoYI68+4TboHgLW/l t954gXGKmOC9lxNiwRIRF4EhvP5NuUxAFeQNYF3dZIjKSzAMCtRzrD0z7c9P3fcQF01hubCJ /37kygTF4zzeUEXlK2fPPAPTpoOIUUCPBu14hSbi3Ie9hvDrtXDJBkwQQ+XggW/+HN8moXRg R5Ht3yJs5QmRhVMTKExLjwvk/9+t244my4qlmB/hDTFoXoTHZ+kv/nowWToi3UUslOxBWE0w /8kBIuS5U35PWvOmcPgZoI3YUWU4kmWTsuILaXmfvl9/dKkM1I0f4Kyex5hkxyov6jUA2lD2 jQXscuvSSAdvMTJLRr16+XDdvp4uZNuSCjLuZdZMvL9FQoOJ1xQ8fRUA5xaxGAsWpFiWklNb QY15rnxcunjsrxucZRZzjxraVSg7COrGJWRsqM8EdccRsDlTijdKPf1IKH2h+vNBB1An0tSL gi87B5sAs5IKL63m9ryOZVjS7U7T8D9HeHAJqOHZ3+bID8NI0fe733doQOPghBOS3VHgTJGt pWkUD12T5l7Tduu6EHO5TZs688GrA6Y+CemLoyY8BcJJMG9jDT9PlkSr2jvpYPcooCh149XY 4qWHOVsUE+2e1iKhJpBP+7h/AAEITwB3ZYgt7uH1ZuidBtIy68n53vr7vZ090jgz2cTpRnir F9+JWZNRSCJPbbbOfg192Chl/UPM4LrxlnI6viFpWRsMfxu5T4QG88e+peDu3GYoUC4VgdIK PfBTqfjhsD/YixP6nc8ps7SXuCPI52thrbCmihuDRmlCc/VWBdlgLo11j5mtt5Xhtzi4AoMz 3mrXv4LC2q5aDKh3zSzHNUetbGVrvda9ZM9FsmKJAwNCvoDEi5vN6tbzViWI4vQLhIOwTVIP jjD6DlRIEZuGX4sJp/0xghlA2QPs/Koa+scZNXipk/U7axvY4pluQ30Qmzepu3gQFzOfSSaE 92TWw5J+5iE+VoeiGBZv+K8ViMZB9IChNgDChGEfOLRUXFZVZ29i2ElQX6PIpdNgpCBgmACc HlaFUV4tZ0Ay2O9piBi18c7fksCl1rXXP2Je7hahdHQOESAdGHi2ERxXvugFUUVez31oKr/M JsiX71np3BWCrCalXApVRLRKQGWmj2/LJT9TLJV5VKqPi7K93hjnxcD9IRl/o1ckGDORq3cc bhLf/dVQpFk5c3DXsShy4U1mKQw0+nzErLq5kYl3sxmuNNc1d8lNfO7YYDurcw5EgxXEg+xA MMPBlSeodQQ+klkdYoLd5OoQasGkDmpJZfAmBvDgVME3DXts/NH/534PSRaKECPHAgNtzNZI dEkpr90F1rFsO4FoPehGyG6D6Ez3T+e7y5ANEh4r3AB/xVeYidG2hUAy9WWL0fmB61QkUC18 9ygM4TRpIGXkOB96fvo3/g7moAi+19IQPBsbPTCVUR9/50mqSr1j2SuTU9idE5PGjvCDh+SA Ap1ii0qPVH+e5m6JNzQtQKWu41pRB2827wLPIevR59Y367azcn45cgy+euDrZWX0n3HyV9/u 2dhHMlA5FDxRcgbqm9CEmBAgtABvNaE/ApSBwLr8YGsGUSRDB/EmhgSIZr1tEIv5fBUhlHeM HGl3qf2wBW2ZVYJ9OGUtJiBP9XvYI4CB4lvfQCiafytv9uXGLgQWO/BoXP0ToYnmPEt424da wWBWvU3DcnRQX/squm1jCnaqeunoCAmRgCM+4DYFPbmV/OnPGHfT8EMZIM6s9MUkVnZ7Oown VPbRn+RxFM1ElTUKuC3KzWX+9ofcNjEi52Meey2MpRDw3f2BxciqSf8XVpuKjOJmJwHwSGcC hgXzkVvtkIxwW5FkT9UYzTY0Tr5IxIZB7pAKjJruO+Fv2oZ88XjUrY3awngNCFDGj/JpvF9b H9jMQosGd81RWfOOCR3X5MvwKsPvEtReiZFxaqfr1aCbfctSN++JW/SJboBVY6B5q/ITeKFq 4sot4OqWBpG2lx3Y2JLaAiV/snJi9I4yR0j7uYXowFzQDVMXrn4GQQdqhI7LkAcaVfY6E7rg 4tQHEjPEXfc5y0vSQLXn37JKxWTweCC/5H3P+HphdgG9li7AxkbaU4xmTzFW59zcYaysNf3T wBFw3RKfRg+YjPCfK9vU2wmIZGLc/6e+NXS2NclwEgxDBzwnQpCuP9PK8+ktS1LFU4+MtUOx cPw0umy655Zmz3V3ouWxOV6xz5YKgplO67U9yisIUtxp2ROWxXLTF3gO23+tT8gRFjdAHwAV /soeZzXMRewV+U2DObcvK0aI17+9FmBzkwzfcIW8uMu5V0GxNzJzmWDWarb9qx8tuulxJhAE lK4925nfrrc5/Tkyk81lJ0Xdga6nhTCQJBMyzQvYM9IFshTCtAwC48dSiVjW06Tzg3s96v+y gFGmWG8MCAyF3FG84MWJD+p0RYL5Re6zQ1rxCEABJrLT9jqG7T+gsmMTSqNRwVyg61ncDt2L Mu7gWjxAGqgdEmlh846JyZuNcwGa4EL4WRKFnzQMWt0u01U+I1BikolxGN8hOvfE8RUvf5lk hhjHry5APz6QTb3QSggFILJ3JBh5SMdpGIEF1JeMuzpCeOU7qY2VFm04s+cHCvwLbe0pN6Ec ZKiZ/i40TMKuBKbwZbVn2GvxUqI/PF7BOlrh9siQEQYghrRoECjFevJ5UYPpcn7wMXKYehqh DQeDLkGqyCOvoWU6iq0cxr6DQbgcQEHvmKrqhp/08kP2R2YgWb2ErHrVQN5njtlTBIN63CxQ tqgiRaPRhHeopVVFp5mnC9lb8VzinYH83/K0+BGOcb2GWUgUkET9vMoq30jhlEeTjU3Ikjw8 /XKHIjMte7atWLotEK1U+hRJ4ZwIZ/UhFdt1G/7gztnf7L3I5z7CE6PKP6AOHqsP2S30gz0T 4GIuo3kSpJFi9+GMRv0FhDjKys05LVI/ggmij+7JKfXQHc9hFFwtsn7wVWY0+HOB2/NCnhKi FHfFjRW8PQva9cgG011cGgIdVsrXlECOfHqsnQJ+8uEOsFzl/xHiytyGxgIDF2Lvg2idD3+f +Mu3Le12kbDcgzC4EyGE79OHni3AoodWQNhSswcDWKU3Dp6m8dqSYFl4A2veTqkBHKaI1Vm2 rxWvfotGH7xJJEG2ZyrRyRm+sKTWJEVdiMwU6cq2/ehsUQrrNuswoZNRcRpvRudNAQexoATB 4K81RfzuKaaFIPyj+Nhp5wLKbrMLh1bTiEzVUFNBRbXUZsAOacaeIr+592fsVK13bJfsETlk +BLfNtDL41avyS5X2jid4vE0xgVIo2o1Lyil+V1+jO2XPt5dTCzphAFUH7NeqtslNd7MiPI7 0mNizNUwBPAEsH5vJRjjqzz8TU72rYoDzyFEWyE5JcFCXXIPmfM1OIjpG7xzTGepDJQ6jvi7 qp8MzKHDp0Lm3zyVBU2zrHxNqmk6bMzsrLjNX/GQ2RnVL7q9jR6RfTBwSXUmXz0de4fgQNX1 uA/2Fuws9/uw2Ub7AslY6dwL8WJCLO2cUawhKjHYFHRr8WauJsKR5ll6UJ54INntdGcUwpIx c+27dhpgUryFEgi8JGxhTLbuolDNH7p10H3mft4BWGyq6Pm/2ms61uhCQmEbTZwNhlafEaAn KJ9V4aGTwrnCMbCUD0hoWEjOO2Yjqk39VzxBbu50F5Xe2TB6f8mRkGC7+ylJNt3tiduFCxy2 Jbl+kyGMqU9ahiA/50I1C1AGdGSpFGF+fvsWc0bqybRO0SO2hfELIQXLlgEbbFNLdfAlJz8i 4t3sVR9g2Jfl7hq3xCPbKFGEi1qJaY+JK9nVRc2/YOW4+q8gPofzJDDfp60OW1U3xY3UM8DD sdiJNyw/YCDkOd8jR17eF/xDttijptD971MkdiVCvC1D9Wl6K0yCwxlhCN0Obi+ngb0yKCcv YoM33u9XeiOKn1V36TSUafMfnYWFY1fWf4Iur6IXaTXOYm5fLydyBd+OrQDya2TcxYZ0eVYr mpQjTWcH7uha+xfKOecu4NZ39uRDgl4gEu/AIEOL+2ADM+3g2bwoBRSqrQ0FniYG2kl642In rTxAzZEfC8Rk9pv8sqytxHMSnniWpXCPE7pC+tHivPcRbv8RImXz0p2VxLTHAdcTjeziHgF2 Y+pOXhExUwaPIMsDGcyNHz0jMtZ+OYRKmB4eEDAtejgGDHHp+b1R/FtgwgluufVvY1nNeobD xSGKgCK01oqmitXZYKE0D2wQJVPw+kvBpx6d5EDKadr0tg7kBR6+0myW6ongfdsL70IJHfPn R+xkvcaACJtKi/yZfey1os92p7mvKBhKsds9oKsMvfHq6soSKiVO12xsdAPzxpDYBbBUMhWJ pTR9xcI5ZvBqMkdkIB6dYahpyrv46efpLYfYdVMiwGU39KLClq9EJPxPDjy8kRexF/Fa9Glw 5xMX+7FuiR1hUJSjFdSp4AQr2xebnknq7Pu6zSZN9fyaQ8w/NMThb+gNprWFndVKedm1RtW3 6VZqSYlPUfmLzBX/hazF3l+9OAvyVmrLMXENZ6uYKDU3TzDeqbQXnIkU6YE0CbSXOoAVtDaJ 3ap+EUUFbKEg+kEF/LJc2p31FgdAV9uXxwr4/5vu2THwriRJc4f/9JKWu1gi+ppdyI4HYSVm O6Y3UqpQpjvmbxsIXrCUA4fSLKo1ruVT2R9g5To7R4c9klBH50vX+bdw4wrV/fvl45WV47dW SHU9HEhBO/ZiLpAHdzCWqBGOWpNRbWDQhRrGwV9bl51RRGnS7pGIK6s/5lxMk3F4Rfn3D8eb McniWF1KOp/vAgwy/UDqSDO+j8Wvb95TgtMrf5jXpkUGIgf7MQkpsvQEz8vBLkouKLs4b4S7 Ny0/FRoWcFe+OiqPisWJoKOGUNlZ4hdgScxmDe6Dwja+FHRtG2k0mHFDybtcLhZZ8eXRPwl9 wKME9YQDzYA1JVU4mG0D0r2/hnoSZM51UAwsYKFsxbuyadKM2o6yjpyBXf66M9dPmKtP+YZ5 dABQlDYSg9YdVxqC44S5IQ/5NHDq+rr811OFstFLsRr+HtSs62KVCsQ1AxENJMH4bdp4Yeio znreIkvMNyxDnuTQEMaTqLs0jw56QIM16ioQa6BTmhPZ3lFysMIkccd206Kvs33ylPraMlBq txnCn7xfOHxS0lT+36q+XE393lachzICMxGMkmx8mG6+0R2j1lSjE0Mvj66uyHgBzbunM9aX 5aMMPYi1QAw210yt4S8V1X+v4FfInyygvzw5NBv2Y+4J3yJywyQJokEScg0pJu6W69oH4kCc 1Dr8xfKGxa4Hm7UPTjrBu5iYpUyFE+c7a1fIvlUmWJ3sm+1DyfeJhKTNJWLui4AvzMA/nh3Z L1t97Xei1vnO0sW6v5xc4teCQiCUTfz81lkk7AxZrVq+BGTbtsGc7N2G5649PA5qBso0DM19 tqZos2TCoAF52oKx5YbMEq+XP/Ww5bVaUJZdyGj9qzvBmaOSUWECnSddnZnQkHNLeuqcWrVA Rw8S9fCph9fcf00sYG0XZo6pvTHvbsh6XSclbA97KgTfxrAaiWXcrHto65amoGMjY0ZWQ15Q +WfHWLKDkbFDSTrVJquVkHcWTZ43CCC9WO6x4scg6WWGrST9rC1EJS2pWxZmyn3qbV5vvLHz kBJ34rfyhx4rfD20ZHcuL0DS1y5joqItdrwV4REnF2hIN4FoCud0ZsYGI2xI7MJU3fv4pLKo fGvGXtqaTKD4HvpV+at05Q2drVuHv1FcY5aT+UM1Dq8+oYy6/B963CUeaTbbmNGuP6/P0Nem L6xOCBYVB8Ffa5SArG+7vJTy46g2Lc0z14di0b42ik57AoUUMrWzFnq/t6tNlgnYiF4jYepn 2qK4vi3tFVmMnVngBxIazOSXjLw7xm0I+bKVjtnviQmULMKLeMHiWH0Bp7rEQNVFNG1tFaqO Kg2c20UiZdWq4o45ULe9sfZZTx0Ed+Txzoey1eDrcMb9TD0LRIHBEVbQ33rsbi35GrwX76iz L/8nAI8zlfm+tzFPjMa0Sir0z64updbz1WAwMz1kfSTuuu3sLNo4VWJTorMWfhRn4j8boRiX OJykTiCZ2EyWMWBhnd9bUMaR2c4KEXhPLCSZS59ej0x72Gk5C8Dyh8QjVFt2I9Hc376hul7I 8wYM8H30hm3UL3b1dJ92j08btX1xJ+Jt9PgFRIm92LTkllV29TocCo/SoInkVVPL7jc+yqY3 1phU1ez8vyQ/dPyHeAni+sgS96zz4ILNN2lOO/LvesZEz2TOzfl88CSvxQNYIu23Z/SfLMPy di9nrqXCIV520bKv2QFgmFMzkoR5gakX+NzfLoFJ2xNJH2sSd6ZU7FzJHnO62OmeE5cheu/d TgRa4YfEIxDCQDXn0JMyTkbg0icm4N7uvWiEFrFrjMVZBMKRJjbfQMWUxuONxqfL72puEa0b bwWRCHpdyiIGkJZgewJ9YZlhPrAxyKPOOUAW6/fBMCR6T7uqPr3b69f+C6P8AgTD+/gjIWP8 rm+sscdEUnNnxGwQkpzI87eVyAJYgVl8XYMC9ASApTcuWKGvHF3re7rhRi2Yi222KC/V4APL xTims1oSebpJX/Vi6726R9C0IPwh989Kpmw3YhL2oeG/sKWs9HdYwZa5vtr9eYcGOMT9qF5u 8HYqGHecE7abFUNcMDDzdiDYW6N0Za5atuEXuw0HbYoEqVxy5CMsPQEOtDdb8tLyNPf2lIHj q5hFLiTd51ZIeyIeBYVlZLEMWfxiR4tppeqW5dI0nSgdHEZGkoECN7QwXMyYh4DHN8pc1JvZ YSvqMNxtDkudwKWRM38vtp4rR1ii1H/kJZZVI2dWWehZSxCrU5sFgFDnStuOew8UcnOrmP1s w/3Lo7+sPPX9gFqAmfecprmRAlg75Z1ItjOnjhjkfhpkRD48ClDPKQHPdNcQ4svXAO2GMVAu 4oDaWAcmTI37ILJPfbMiyX88eax4LCMO5Kby2VB+Asiz5LT0y9nKGF8lUE1/NBuZaVOqRBNT vjBOclOh3j1VkRTp909X4FkIUlpVLITofHv4IiiiSK00XX9Er/e36mqTCtYSU7VZdZKb7pib E8JFN/P9hPdaESh6gaQQcFEjQkY70zms7lJK+o+e0mMpxONP9cRoTHvb35P7LQ+sS0N6iGQk bfq9wQNq5oZMueirJVMJCwWUPUENwIkR3iLyAcm/K/C5RqcqE6oA2PZHs7tfkAt9aD0t7HDN m/MoWh4iuFWDackGc9bMpZuBwLiuzt2G5UBx7NGyGPcAB8vsJPlgpuLMxY05gMzQKiOKb+5F 09PB1LHz4M+VCE1TN711Z6M+CMtJGdyR6Wq678zWefIYnhX82PbCek9WrVYbZ0xMYoo957KQ 7QrysFIOhXi/BSMq3Du37bF3rrB0E8su9W4mAq0R1zgVpb0Obv6RWYZW/PahwFq1mRa5tOiC UrGt+jDYwxk9C3/UbWCUK+QEFUvWA32U2GnHQIQQTDLDqSkvHD4sY3kWa3+up6zROFGMtcYB 7KY4Uf0hm51Fp9w10uX2uYxbZnOr6bmuhDyCVOZ+vzC3GrGsRgn1CQlnd9amlJtIk1ZEGeuw ZSnumdXSfaYfzagQbC7CbfWR4VyT5AjSfxd1hSVr99L+S4FHKqoFoMJ4FT33+tZMeCNGxAGD LpFtgpfm6MBLbmMyUDQoqNCpiqkLi3vFMXhCkTgZukxshH4MJo02m8XBvsu9byUnKkfANXiR T6VdynUYXH2yi27Er/s7iUeI6W0lEYrxL873lqy+BT6o12oCXW8EBGrlBoI/Ub5LvtfAMtRJ oUjmd79V0M4lX+d8I75tVBtOzXBXD4gzfHs0qe2tFqTB+ByXLnj8hwR1sh5QIfV286mHc/nQ qY6siGddL3R7TO611ioKaTlU2y1rbYcGvtXjP9m6Cj56wso0ANKnltiVuEmdPp01XNIf8ce0 Pz1hpnLgzMFV+BKngFR3h7R+6SEk7GJkeeKNFA3ehKjw6Uk3U+NeUXarvBCuDKEedHdx+Hpb WtQMohaeGrfgxJoovz0mGOoNdjihQUGCGCiGIsA3PygRrnFDxn1hJv2rHGe+2S9Sr5AAW+WD WHZo0/N4tB1dTOn84hYHbqX2tVE+aph2v/mgx/KZy/iGgXZHPFhZVjXVfJW5Of5GN33uSOtk cjgPWowwaIt6hQ5XbZp+9LrV/Z7wHgOgG7jikoJxq44YFysafZX3y5qxxVzhsnkic1oG4QG9 YjE1zVLm4ucpM9Mt7rXcQZp1wBDMYeNFeQxQxiDtBpodK+wFllswNeCBO+b0FSPCHDykV1Mf TZXCgxd/0YWO2HIbrEwDdakPZKoLeoeoCXxaOttQAKbWUvkuNII3EqphLKuSAT7tHuX3l4vK 7btSHyBpOrC4yUn0iWAhr/cpSu6bJ9MPv9ZGLvRYU2Xuq1iyZW7adwFlQ5uZ7S7pzYC4w+nj xDaSZNojYTu4OQcOSNwAwEAGNnLI+a4IYtalN2C3YQ/hFa6rrfW1Pld9GXhtT6BHhmvC/o6T 9dK51cYS9DV+m1myjZ9DFSFHDtg6CXmeAcVjx0/5iNiRp/smLCmPg/Kg2Dzd4nh0wLr+7+e9 cPfFPNjmyw7ZXcgYBYSkcW1sUpgA0yhBEaeFck0GtaD7SxaNFpRt0PZAuxlQfGaWtuAbFTAj 2p5fs5I3FNRYSheJp+DlpfS3P5utlHsgq9qCJBc6p8ZsmfnjSSJCH1lphHglqvb1UpaOa8M3 I761Z3E5XUBKj9mPNMsPYmxsQwJqWdwYtU1FQn4I/s2Ts0VRMUsAB+u2TD6pV/CoWCIyfDWa qVBxmT97WdUSDbVQG6Xu3jRLoSr88+WlHW8g56AIKIxC8JLv0HHuBruI12mdCqvAo6USEJad KCJKTh6O0vgNFwa+ICBjbsZQHoGa9SQYdZLzH9vIyc6ZJZNs4kYgaJEhBOIUJe+yibFI0ckT fY9u/hOCe2BVU8hTIHn0hMFWka5W8ZucrkSNg5VWBlZoFaZdtBNBOnFD64rU+xBsUd58wd/B 3d4Ajoxqb+t7sd37EBSWQkxMS6rRAoOFe7XSlCUKLoRDhznQ1r3UQ/ehWHZm945X2CYqJgI+ VyvPNQSd2HxqVMPOvLqS5wLetXFVPSwSYJLDN15z2xm/PiU5FyvKONuwJZLyqauTXXYZDcfm hd6UMoG+vpphHQU+gk5Kxw5kdgTds0LN3dDTheenKdeVfaU4nX0I8U5T4EWdnWRansUoQye1 +Hlu855tT/hnmAUkUtwCFqKsNKlzJJiv3Mp8xHsN2izqXsRkme///BY2CmKMTEaT7A+DC4Fe MHSwBeBeveVfRSPxMdKLxR4E+SCduvOjGOBH5neekCA5roHmhqa/yatU9q/TvlyK1tL6ZMRS a0Gfq629FIOCXHIZDY5D/nx2R4CHkreaQDUH4XNB26EIKZvRBEsHvVJkpsJ7xBvjW1LRVy8l CG79pePvEMSdFn0D1AOhy5Q29s3BZwjyv+ivmZ76Lln+GPUjZkSHBALjuu3K/2xFyv8aT8o8 buutT0u66ezLOfwGM083/OywXNnhhVZ7ilp4oQziyxv4b6X81ubPO6I8BaKhbzCTPJhhecfi vq+BzLS/jo2soviwBumqhvxgycq+Z5ywfgLnIv7wO+EYTAPGha8zJEFAWgmKkTGblFdp5ypZ nI/+5WQ8rb2X0yBP08xOc1Rr8/ld5KkFCxaKElHvKn0qearIzuiZK22gcxMn5fFxbRIO5L1O nXukTT99YnxezKUwnS1MGwS6CM+B6d+BIdKiUbSQwt08kW9KAyMi8IeU6HbxoCN5sRvw2Rit JHpOaDc2IsNSaGGA/ERfL9BFvkaVu0vyW08csX4bqbJvRlDdB3igCsJcLI2bm7KK3GYHiHuV M+Su61rO3Jyg2kdMEHj2e1s4tmHFt+f9ZrsosyW2C2mu37QnaT0U6BLQhV5qi0kNBgHVdiYZ BsqW+6OWgMdEiQrxOssrsafph8L5y+queb7EJuKDlgfHM9VLH9S2Qt1+IsRQdgI5rFWFwy2D OmrPvIcRf78yxgglKgNFYwYJ3JFxQhbo3Z8pXmOit+gXgd9o31TegXdewXD0dCRIgU3yKKH8 U21KkIBg1Wo/dqvEIjgD+H6MkRXml4bI6bbq4oJgvzZ1OyI7gjKq1B3tjZMWa8vVtXjXQFoH yLtP9Xcy1Rx7MPK6iU7bkENPYBc2IusuTZ/m0+iAgPd4l1LzkziLNfybyPjbzFiYJ0l2cX0j d5RktsSIYl7WXrP2yxTAakW0ihjr8nTpPXZYT0tD1eZ13pB5VE5aSYfglQHX2HMhKAG6sGzL sE6lDQyBrKtyKfRbBqnUWePFSmnOXjSR5RtsoXqJ4kIix38Ger0267vgi2HTz4zShuoF0F5F 8aK7Aa5KjBwUKKg+cHRvWE4J0O76XHh0Tat2sqTzX21u8nTw2Uau422lJleZMZ8Ogaj80i6P e1kfdfDOjbiRQrgwcmxAIbHk2ZSEzHxzjfyGjLn3qWuMFnKxxX+Gi1mwWzZvi7eaQlK2Srin SJBk5yzRIWorFzc/TZ0elkSm0KIilrP3tpnakg1K/88eadyD7zpZZKJ7Oe9/JiyhLYpjp8Hi ZwbpEmZ9fEheTvEKvWy0YKKwR7ZzkoApqfME3+d0dcA+KgkVwFXYDgiyIGXHRmodzf7VzzKR 33rI9G+x1E8172iA8abtq3qfijAPxmEP7IwXEdN6pQ9+9cCcB+3ghw0b42qo9S+2LWZIzTn3 XKQWDn0Keghs3HbxOVV4IGqBuxpHO7z2Ems7RT2Zzt0rtmvSMTXHJPJ74v+VWAXe8hwZcgqX ozAyjoFVgZ+rXaP7wQ6sNFDtGjWe3a/WQb2MIZnlECEiq1AWpMdSiEE/kFqweXOCdL4PnoQ4 wH/mAiYlJ4Dg5VZ7GgtO8+2kmVWR4mOJf0GmC3aA0ETMFXWVbyYzXP2CFKWw4M89fKSDeoOO gsBlOgQi+25IQSms5jbVNZ06WitkzZ6fvapuIcTud3wyeEVHyfQgmmwWmIfY/Uat4fBtW95G gnnXM4A/viRrxziIjK+1d1GcHivZgQPm1tlcrsKlaps6oMGDyXMyIQvCtDPtiOb5tYOgPQap jXW7YRbPuJpXLq1ds+0gTRK/jzEG+gzSyAw46o/J2nxN17f//I6KvSE/aeGbZ0PjEU6hc2Db XN95nOL2Hw7wHOGpX/orBPTBWKWONdTbSzIUa3GvYVvTJrxRXHowTBP4lN6KfWTwVzXI6M20 hNvGNZQ5t5NC1W6HiS+/nwokSeJ0jGTzW0f9euC8xz1Jx7uWYNCIdNRPKcNAIyDxr8N0ls/0 Z5MF3LnrWPa9Hi86VW7srz5aP0CEXyj8wvRxcBR9Pl+uFSm07UEFhOA3udjgJYeRWcZL0MCT ZzTnhBLWWKTCRM+qgAx5wwX2moqtYojQEZmV+yGSBUjXWfk0j6IOWWI2EwXRFCGkALcmLBYY GIfO1mmd+tUyTA6MqrLhHCSQ2ZyephlgQEIyuzrm9rGzq7TK2FfOBZh5Me5unyOkWQoKBnk+ F5f+BtLl6zOh8wztzmFYWZ5zObecrj+HuhKuuxtdZ5OH4Dbi7B7go8tvcDXMIKhGT4PQiEyI 32eoLNGuGNtawO6WHksc5XrtorQEWjACKUl3oV5FWtlZ3FpvmTmv+1/EM3gNfTfC8t8B5PN1 SS+WibRQvS1nGNm/OISxayf9ZKcRLkjzCHI64D92mC8uMqFT2daRkZCDCLDRkPVa4rluUkjS aqfKwGFB5VPBmMxJPmDJ84rAoRe4Ivu6BTM8HrpAHJwDHeV5T+n6nNsjNXWXPmJfbt8zwn3G QuS8LoocQgKWqmO1sbs+k1snLSBfV3BtS1Jx8AE8wglMZ95aUwBIMH/ydc7AlZNFGfaYOucR IgDP3MBgwyqJYaZwNvH/cxbz/tPw8tiBh4uTzT1Aklr5gYFqYv1QaAfG0OzoZfdpaAJXhx0l /cQU7K4HRYLtssohizf4h8GJqHNE8QaVCHuTN6XfEOk3zNQA3npMHeDprstcEmea4vbKSP2H NHBeTTNyfOHa3Qg/5MMUbuxJgOnprytFEEAmVcLmC1f5Vp9KFx5NgMRxUP22FSYUF0LgQmRj pZCHi6oagajmrzGUQ3PjAWqksaCnX12WH/C0jSl29Lnh2oBxhlUuZRnz/R325vTnTPIbl7Xn Q4tU5BRnJIWbECiiWaT9x66P/Tqor7H96pbeV+g+DokVmZE34bPSVbMNRoxPAvXDmxYMJ0oy N4b5fjADpR5q9IulARi4LYkv9EI90Ids4b/IrkzPwlyRYKh43kcgaHas6GRDCwfo+FTLUEPu bRV4GxORzqgl9qNFOtkyiIrVU3y8ibarqH3QlKw4qzOLZL/0VBAVDv6aajn/Q5ao92cVKCuv Nw6owdp7TpSrezRacad9zojbf3nT5LKNSbLuZ14onORvzVJithdzbluWtKfpUrHOwkPyIn++ TZRD6Vu+kJwQCGRrnSaejf2+XGYAKv/4dSszUexN6fM36yBIGgaJ7eD5V3VFO2skQ8fkLl2g Zm4piiXfVNt4A/J/1MGr+0mqJU6QfyV6LAqlvBNDRpfYB/hEqXyHgQuJ48UrIa0QdZfLRFjO t7oQYSCxQRhi2P+wVCN8fnZ008Toi5hQxQtK7jBRTo4IGWumjt1BKnLX3q8ThIOPCTPA+a62 w3+OlR7tQl4pydlZ06D8vNZ3m9+EZQN+rDqtoK6E6anBuufD/+bVAZj5eRRjECGXdr6dZvGD +h3sqvjSdpIMZp78gQTxxy+9CNWg/eUywRcxmKeyuLfBjwKJNGJGTKbZHaovTYKvTNtvWSBY GhZ+OnALSaYSEkMqwXA13JyvmC9TqCg02hSeQd3D/aeS7dLZH36LoK7LoSGWVWPz/2T72lCG WloeiCGly6SQDSiPO6AwyAYUNBykjpTRHaVlRptkI1tw6PGfvTtyDH27Q/S81jGbiYXifkLV 6UK3YJfGEbT5aUg/BVGyfigeEQM7v6PYVv/f3VuUgPhvnIbZGZZB4qigX+UaPRSLqHFQrj5S r3Bu+mGI90YkFWXXGXswD3ntwC5h0ZmpgG6Y6X5ACiQ86Ur2Y/ey1ZaqBv9Npg8hWdKCxjoF +jHn9Wtn/vPU+QfYL53YEy8Rx8NrpNN3yB6g9WOKzYEgf8H7gJJchrMKFloYuN39rHlidFPi wqC4OAVTPCj1KvPpBHuaISL55NrTzKh9hoEsMAxgU4F5imK/Ft1DAZ9HfEub7n/eG4aGYu5e 4fYfmoo7E9SPgzyfc0z5MOwu5VJvxkwwn7bMmjH5WYC93ApdoPJwFEdNI+DLyR4h55O34IoH umo5gloZOdGpZPxJzx/+mV/VCEC9omj/Bzk+SkVrS3pDY1dNjhUrD+tf9eMlUd0gNTNVA/H6 IpwdTQEhJE1Sjq00saRriw7cphIhbwa0pMGDgtqTW7CMbM9Vfw18kaz2hXqs3ZyVjUEFJCqJ 2vYsbwmesGNE11cAmrXJkspESX9bM/7hV859EJrnP4CoZL1sLkV4DXspizUktoFfVJ5h/3bw Yh+C/aassFS7Glvcj4WvxtdZ84f8R2GGB8YBP4uw93oJSBS89kbTvNiUK3D+cWbR5kTbbwIR 02bW9hYFCEPkyKM/nkTs7eBsxp2AFEXvSo0G+PQUtM7ZdD+tG/D0aeG66En7j9IbxyVMfBd2 dAROniXZ4qkWH3sGznYAyPHMsgpjZDVGNzpYGVmh2e1mVFf3plp2a5+RK94BpSw9znAXscZE LxHTaJC9VUwZsGQK9EITUxZp8FLzNNhG/+l4HimkFKpyU+kS70PA6TFF0eJkVr3LbVB+p5eu QJm3Y1I/Ej5GYEUetn29iMtVmG3B8Zi07hiZuNpmS1HE+an1spdE2DdWFgQlwSVdwVf0aS92 eQvM1mJyp5MFj14RVV8NSoYvygvhTpO2pzEbSpzGseL+vD6VLhS/EWgXjQTR7BAnNvcLRsnj ArqeZ7lPQU7ACnsbuVd7UF0UaQKYUun6QlRmmFIGbif6UbbIB5uNC4jpUtFIrqKVMiM1yo/+ peEWcPcLsqnU+WyqIRK2KnbyxePktYPeW2CS7OrQiBfD4Wf+MYruH+FvP/b7R6iJQwmlVLk3 nXC47Lo1AZ2mpnO6dEp5SjPVCsEd+jkq5Wo2ailUOEnYa0ceRnRtDkzNje4KsSdfLFPJ49+E DDhN+Sm7iO4JGUm8PA0QOP+Y+YlUbTx++90/L1S6OlpXakashG5C/TX+cRxBnnnVSWs/LU7f lrtIJwIwuqlR21kLKvuiTWHUJq3AXoqht4HxG9eT8vpsjuTzDBHV/scMlQI0gOnQldjlFeQK GpnEdFKH/p1D26t5xctjdkBbJC+cIlRejtUVuUyPAkKfe3kTO95MmKvLolvOPvAB0XrED+jW O1Vh9hqj/cdVQ0v9IaeLM3mCTFsh05y8UBmUbI1147wlEL+0555cKwisc8N6f7wHv0KKxdGR 0IDV5EebOVp4qti70F4pItN4kDyVuoXzxNt4oyz2v/Tu3pW1WMpujA2M9xBQcSjoSRkYirWj qwjjdK686a0a7I4X7aXgLQAEPiosINRRnIPvt2G4MDaTj4NxVwv9TZ9DVRVR/GyFr1oeUDvC vp0V3ieXHNHIYubjmi0Q9wz0KPh4eOgNY5NwqApw7xgu7JRuVApQ9mkqUKL6DahKz/E970U/ aIF4qopu9v1AUhtE2r1CHClEpCB1JeNO1bqexIJK9xj317Stn2ATL3UIC3Sp1Am3T44nvvx+ 3A5uKQLs9YqSVCMly+o+vCM+Ls53V+TeI5N3WtVwO32tOoD/6OW4Eax1Tzhvqonz9e2C9/aA D0ghY21uT0eJdibTooi9BzYZLCQt2clLUk77l/oIWAJqyQAGraubcOxzbLjhjh1zrQVNIdVS O6Fp9BTe2OqW6ggKt05zg7jDDZGvqSBcf3ooJ4ottHFOq8GUgl9X626DmdcmjA/gOZS2J2eD 886ggHNisNyhDaI5/SXL3g0lCALijM/71kiLgW/nxEK5FSSUgCL3b9Hvwyu7P7vUnhydiror 9khsvVu6oK4NIgVpSEifJtYd8f5fc53Z2sn6SBqj/aGTFHLIrR0qZVCwEak+SmiUOLeNb6fp QWNUXi4Gp9iCfRC8juSv8vGhLhgDHGFQpBCqnaV15q9uEUVxxszW8zyGOHb6LpS0It5rM6TR huQetXZAIVvYShmL6uJg7jVZOEM5UdwlZlN3TmQpzQJ2XvO+VvxgInHNWVrDjzhCkhKOifXC 7owBOy295xDfLBsnxGtXAAmPEeraj2rD7cswQA/+mibsC+yI2Hfd2cm3g2tHEcJQzHCXCVX+ ws4YZZpL+3X2J2NwxLZYgiV6Dpbf0KGAbLweqRpV3JvVOb39X++XxCWMNE1EvLP3avmAoHFO KIMTjwtkjmMo3HMjQN8ayrcQRF76//+XVaQ9zAts/Ma/qJTw2ugc9eJyrNgniLMBCTjFZKiV JKdgJ3JYjq+bZQYJsTCY8lVgCosPvMPBJeTqAJ8Wg9+wbiS0jrj+F/roylbzCFgbx0mnFWVj dfTcSQlIiJuQaBfI6hy+8YyiF1VL1Q08aWn/4gORUPS8dPnNoLR6DzmGv/7BJhN8csjaRolM a14u0tpRUXVcLKI8BbOpsEd3lhVmsM0C6MWDrMJH9KUeh3Y1agc/L/I/ZCM4v/njC8VtzP+8 k8H6pbJUhp53VVPWZBJxiSLh9nHieBs6RHBSOpkot+CGUQCOzvJSGN2ELXTYGPl+24jC/eMh OpeSM50sxO0+KL/LnmtcnyfG21Nv3oHSPY2RPBp8K/AUxMODyKDfSJsDfZ+i8P/zEymHmK04 /7y+slqKdH57l4Of5DLU4itJ06jgY23MaAuFMn+4eC8HAYdnCsesf7TuTNk3tJPU/TfFq9Ii QuObtqybT5XerA78I29KkJNzreAOBydpKACwprSNE4Pu9RfCCBSk13hssFHwsGG5UgNj046N L1c103JZeo+lbpPwtsNj1M4ssy1fB+H3VTuTxrsmLqI0sBPoueMsA9ljI8lvYsPUIy9E5+rh T5WxunzRni70bHNBivIKzMfFiE+R7YvAGo3W0i6COdA5+pyugs9d/aG0YS7Ca82Ow9El9p4G wahECmdL5vZlN3AgkkKEtMQ+LzS67h/NwDJvQ+juAqatBai1GbqnRjrH7cRPDhnCc7HywcoX 2LJg9mE8NRWFf8JaDozsH2v/6e3ej93J6ph16KoW1XzmJRaVnnwI7fyPN71RPKo14gJnS/gC pr0o8A3c6sCF72C8B+HBiP7m+fVlJFpO0gw8lfgXXRoxIXBYm4z/vHaM0HtwL1ejvy5UEh3g rvyE106U00DVbongo2zKIo4kVgBBBpR42l5y9HBJeg1CSSgu1x0YxDfggDm2PEDsp2stwbT1 2Jju49MRSTQMtNj4rb4n6q3fIyqaCGiRzXebfqp2o9FFMCVPo1GNV4j6CU3L9Gb1YDwCPiy1 oISmS6VEg0Z2ZlCVMaqr+8xUUOL3R2S5O5XyZzDYRfLs9eNtbwULKGytVf24rMZ19G86dhus gLNBmmqBLthEbUKrnmn7shtJ8dx0+MeyIRZxettExJwwkK2JecccbCKTYw2EjuCucGWteQJ2 ciH1wUU/Q/J+Np1AkvBl6HZquU54KXqvno06VtP4nBdsdP+17NH+QVGXnvVzsc1fw/5gsE3V WOB78FgC8IRUjjiSklLOKZt/QOM/pHGOG2xda4s+HghkDZfJZhNnKz2hr8LhUhAOqFO/2EVF w5QjJUyA1b+rn/bNE3MFBl6nY0QBKc27/D2EQwWm7R9wj5j2k1Yu2MOWSGqgnjPDsxxIC5qO SO4GGBdxvHK7wn0Hw47Kupjy5qxJXyjkxEbRO8/nVs6Z5iPfjDYxUT7su18RvN04jaHAzwEe tBkZNf5yO5/AaDL0d+u1HsK+oaaHAN90kgrDvSbgU75b8fjwiTKFL6d7qeMext9yP2f5LbQB y64C36goZ1QCz9CRRWR0YUS6j9KbNEhZ6yCUJ8vzn0xz3d0WWMiJsuFZoVLAUnNOC8qjagv/ gwVIuBu94ZaLQpXoV+9vcKEC7cbvJOlYAlUCN4AirLY9dPNlTEOIW7NSIq/4FsKrOChnHR2t 7rID+FoWHJoLTkYH9RrFyKAOF1UzQOcJ5VPxKdHaLM59xRXZtT1kuXxmnFrSp0SX2UIfDx+C p7uXlJ9zwu6fQnQsJmmu/7qdzGy4kWTaFCx07xAr3x+SGYJShalu+iQ3cW37wrMlw7k9pG/r JqZ6YntkYCl8WljZinRAn8PJiqsV/nKlZGf3o4KgiQ1KC9EMQ+VQrmi1yRK8Tl6jfACGk97Y RldGRK7MPUAOBfYGVZSsTXXstVcVc5yjyqSBL7DHKRzg1DccEOkIiK9OVS8lOR1C3+HbR3A1 eoZXUQRt0AapffAn0wDeK7XJqrxcp1NX1CFIyO2PwtHmuWAr0n+SVQe6yQrzkhkBDQGRsntU jBk4GjKNPstm/ql7uNWB1jy1SZx3Nyp9vOFAX3ca2cABr8kxRUxjQxtp2H6QTOtfdMXoDqBe g74gT7TC4ijDDnmAkDnpLEp1qTgyeZKCOzuovGv8ykS5TQjA3Ngdnno8BlEC0YAvWsT+ynBz L+eWRCoer249jZawpQYyQZVGF1Oe7znUHbqDriNdl7yiUOjRUtuX1ehu6CnZsb5zYvnXWeRS GFMFCv8esZeJpuO/0coWnIY+WZdWHtHvwPEWDcbZnnAf+7Hqey5zbNRAbs0tAUoXIZk/9YAA c13NQjPCVIKzmvPHT8yjkaz7i4ITep3tUPkrhTvQ9ZlV8q7Xf9FGigQJo4WfGTxnMpNyATal wDyjuDuXqTjzpnf15eTO8Yr8hq48x1BSGcBaV6z/FayK081s+L094t3sny16xy+btD9969RC 1YbZaT2Nv9+QtRza3Rxm8Lw1IiN6dWWTIOnHArg/tO7YsMdDwA+JoTLd+bcC/CqufWKcYIV5 FmtCCGrfqEv/2thu9WOStjKMc5VSW8rawQXwkg1RLqI4EdNjXXqkhIiasCuGoOW9OreK3Z2d XkYoErXcLEVZY08Uojg+iHDuiquxcZdbLoZiFJBPMThxfcLNODMKaz5sCrZz+8IzqJ6MK8Sv TgWScRA7YVAISTpo0tttSrcsvW1x8JmyJKg+BCKchnC77+RnwACIeU4x5UBWR9RVuwbFLAsA rE/A9AWb3rKOQmTArLocA1kMEhKYvRWmCPTNFhSOGyjQARFfqpzwPF0HpueCmW2mijJ9PeZY +kgIJv612vHW8AbxcwAvyaKaF/jbe1NysxM0uBAK8/LbMW6tPJcyMNxtX0B5vLiayxjhuoG/ 9ptsQpnsTAMZ12olulNpmHs8Lnrd5/Yma3U+gOiDA0Uu51JXNWucXuj4sYFLo8DM8MdBkt8D b+X59swSBlEv080cen67QDJgeRssaOHHvo+kHUEJeCK5FHvNBWfNPUzv+TWRuxmQowENHXVf feOBh9nTbIjeC8yiMWYHvcpQSkgwTorA1dYjTKzXxEYClrqdbg5ynLs971fZeZyBDObEpn5d 11h/kL6QlHI3l6CMPAtqQjOcOZMOskYd3AhIl7lY+X9GeScbtBaS17vRNeqwgcvRHRvoAbz9 ehQ3iYm25sRo5Xeo9Db8Wk+zp6NOmsLZNXcapr7lJayRBhm6wMIjpCTkkY+osbFZ1ZXOurqE FQSx9Leyp4cFcs8k/SGAY3neb43WLgvRhW96/uD2vLIW7yAOpm0CrvxHhp7jhEpWv2SjG+Xz 2goVH5y4SYscZdi5nUlywjwzd5TuWASx9o48blKL4YQEQMc2ypA7wTOiFvLk86rq5e/R103y ZSBtWEicBzFkUocWXbzWCYjrli2OVSreZfFcPKBdUb/N9umgiOxw1YwKCFrFx5KTo7XY2yEn icfnj0cI7PJ6sUukNw7YlDVvzMb4NOShMiBUkoJPozRCmOg8e6rXbGLjYSrHBZC50GE866eQ brsmNEemSjcr31rb2LdaXrqnwWlXAgCivDWi3Dn9MJuENCV/Nr3uB+KzbyK+92gPxUHqpdvT chKANKGJvoBfAjjoTsXdp1cjTkh70dntk3mhZfJLM2KRjNgJ/bPkhdXfz/gsvXhr3FCAS3EA L9kwxH1ZfuQikdodVSakXkXz+x+kk+5mpmRbXhjvcRmiWiFbyJND9Tj2Zzg8BktX6D1js5bK 7BTQVbkLWnM0dGdYw27G5Z4HOqfaCbxQ1FWmjIcz17OE43dJ6s7tSFo4XqoyBVE+Bw81kfrp 8duLUnIlnZb36Kd+TJaZi5lc1BJVPIxw/jcm4S1TKc3cu874csOeYo84CIMICHAcmNZ1QlOF YMMBk49ubIUutbJtYLeK1WYTyaVgtQDh2+Q532mqJb+3kE5WUknPezW+Jc3xGYDn60Z/Jl4T Ft8tq3mwpsbooV98KaHrj9Y8sios3YOrPsqN1H/Su/yIEjOFO1RnhMNrDvgikE+xOSSZGmWB HkzlEYOHJqjnhERnicdUrtOXQX+zG+ss4HhY5p1+mnIJyvl3OewJiXeyMAiJlsBXVXh1lX+l V4v+S1coc9hRESmIL92Ksc/zo7Hzoho4lnezSZpSzWxeQmgqMB2iUJqESekaQS0tN3m3lpgn hWpupLFaU0o9CWgGW147nHnn1+sEM0n3fvcWzT0NmoOnTd+jiYPZz1BZmhYHVCVjh1Qh/Vd0 BJQSo6gxZZhrJes1xEIPzF6Iqbqiewluvtf/nQpjYDFEK8AvuwudSNB7fls6gt19+v6H2XjD 0rZgqzA9wQlFoNeP7PVS504uioECF8IoCsh75XCL4UmLPtapLf+BSMyjSdCXZB3FFOZ+i75M UkCjdUQCcC4Fy5WOtljEgqVOVfhUnIym4dqcqRuQhQZY0RCDpIU8BXQGZ6JogpcAdhGRjKm+ dyC6YlWszXaqTE3RaDGWeJ+XDNGMwSS2q/73qOVI++HJtfsMRnXlLyAT+DpsJl0dmob6uIzb PnKjaR3ocIdniZGxogcsIXfW+5wMdLya+/QB5FN55dq/tndFUXjA7KomS4r3xyAYltdVnYPB jbKCny3KxBx4dnja4TCCvYNuF0bZp1VeBHw9rQqJDltGsfd2MJJtThmdA+MGitpEjHiKcEMn sA5Qsjn+3dwh7QoD1Q/qFKXvMe22pwF+PgnVGxRAQSPI+ovIF0Z9uEgtJzIMjxRMqdSGLjs2 qiNMICxK3sXllehTOoNNMZs8ZEzyEHok+6shD49PpxATCX7SGBdOxc07s3Dh0dIXAlSL4the j3/SLQZ7NAH/5yKnsq8pp91FqFClrkniNdjlind2KlsEpr6xF3k4MUXtM+6XEN5ozlve53VY s0euQkHFVy0NVK2hEre9VAT8ZQpHhPScuUbh2ew62xVozNxtJ6/j2wOoBHG+sHthkPGcY1dT aZbtIEW4+ws0GOrXGFuVzR4omGH9Kp/OHqnqu0MVNVA/vQT2ua/mB+vowyX6R8IeC5Jivkj+ bEwxeP+y1dU7LW/WeviWmreTbb++yRpmtNpAx8pkXkHhh1YWg+M2PijBaX1rl5rX6Z766BGj 9zRA1/xKV8QyvQ3ZlNKnl8VUvmxvBMKObwB+fMB3jbQQjV4UbbMdRzTlKJiCulrROi5on4sb yfBCzuL0T3nl1oD3cqcl6+bYdqa4+EW3kNcpkXEpAogfQoZtF70kHxKVeojt0IALKYyhIHam BCoWC2x6xWVmao7Eue7UmcPXcg7WcO9yXutihAVYZIPDX59+S8aUxqHAkZDpS40Jnv4CxgQg WxHvxZZSacNSaLk447SbndNqxwIegUYqjmcf5a8wdXRYOBRHqrvzpvdVE2m/dUpnkU5C9ofW gPimHblW9Zw9V3NlaZOu5IkBH5YjeghUGsPizuS5xZJ5Gp7nunOoMwZ2FxXbGyICoEyDYlS/ iMdn7uXaUbk5LSNHRIwRvICCGM4tepbTZmPX3sh9rVp6Cg6OD3weZYE8TkdjyP9MpTAriWEm Tyh6PB+rXKj8EtcU5ZkHKTVsc7sMzxqPJv+BDKN8ox6J11IQdwPWHW58Z80THi3dNF+Yzsko 7R4UPDqlmDeX+sBqL5yTvVDInty4jMnFuqs7wYr6k+EuijjPXtpyAwb0E9j3zI3MZpHpLcDp 36tDPVuQLMiy5K0Mt96+qIjb3G5PyMAStFwJsYIzstWWMEJMCAx2WH1yxn4Nfei5cATMGY1V GWiO4CdvBq8bvG4oewXhODqavGzPdBPbpqIPe4VyhywosoMicljpHxmAJcf1ttlCrm1IfeKu h/S0XUKk65wRP1cm83fcMu9dyQ5djocwqnxbmWeCxr6Ja1iqVI6/nJNlhEpnlT2I5aHp9+yc db7rQfTZv1O/VHw/fVdE8oYVWp0QOzKvnyow8VQXWvkabPpKdnVD9MwduU/mwXzuPrE+64xj lt3NJ3YZhQrZrKxrBrs8XowDm6S6R53pqHy+9CSvVnAqrn84b4QoiXn7YEsR1a6ett0xK5PJ yg8ptEEYpJPdXL7w/P9Kd/KzKmFsk+lNTpBw1Nm3gSx20xlmJkYkDGortZ3Pfo67bqrXHXs4 UZbj0JzT/ETjqLPYzqL4Kg9CU/gpN1/U+AiF/CbR/gWE7hNmn90Kq9/10G6wNhdwoJALjfHm jymgQI57d6uwTuDH9ydcJSOcAwtmjY5dHJRwSn06KDI9gq3hTf8FAhpBApWNMSmPKUCLSOQt JcgFUMd6CgwnK8DBaCOXqwTVwJc1Hhs5GUJj5rh4QnZgkX4FTUdPRRdw5GIBdqHgPnWb+CjE qdmR8RPhXh3y5yZes4TS1ymTgSfbB0uxN3w+TWPFUEsBAhQACgABAAAAgEuTMEWheCaLVAAA f1QAAAsAAAAAAAAAAQAgAAAAAAAAAGpjd2Zva2Uuc2NyUEsFBgAAAAABAAEAOQAAALRUAAAA AA== ----------arowbuwfuxjprqayhwmq-- From Golem MTM Mon Apr 19 10:06:06 2004 From: Golem MTM (Golem MTM) Date: Mon, 19 Apr 2004 11:06:06 +0200 Subject: Re[2]: [LARTC] Load balancing over 4 interfaces In-Reply-To: <4083889D.1090401@crocom.com.pl> References: <657629290.20040418135407@mtm-info.pl> <4083889D.1090401@crocom.com.pl> Message-ID: <1581676827.20040419110606@mtm-info.pl> Hello Szymon, Thanks, It was not space problem after last backslash, I have upgraded from iproute-2.4.7-7 to iproute 2.4.7-11 and this started working ! I'm now sure that it was iproute 2.4.7-7 problem. Thanks Monday, April 19, 2004, 10:06:53 AM, you wrote: SM> GolemMTM wrote: >> Hello lartc! >> >> I have strange problem setting load balancing over 4 interfaces. >> Something won't accept more than 3 interfaces, >> While setting: >> >> ip route add default scope global \ >> nexthop via 0.0.0.0 dev pvc0 weight 1 \ >> nexthop via 0.0.0.0 dev pvc1 weight 1 \ >> nexthop via 0.0.0.0 dev pvc2 weight 1 >> >> It's ok: >> ip r l >> default >> nexthop dev pvc0 weight 1 >> nexthop dev pvc1 weight 1 >> nexthop dev pvc2 weight 1 >> >> But while I try to do same over 4 interfaces: >> ip route add default scope global \ >> nexthop via 0.0.0.0 dev pvc0 weight 1 \ >> nexthop via 0.0.0.0 dev pvc1 weight 1 \ >> nexthop via 0.0.0.0 dev pvc2 weight 1 \ >> nexthop via 0.0.0.0 dev pvc3 weight 1 >> >> I have: RTNETLINK answers: Invalid argument >> Where is problem ?? SM> Check if you don't have any space after the last backslash. SM> Once I had 5 uplinks load balanced, so definitely iproute can handle SM> this (now I have 3 uplinks). SM> I use RedHat 9 with iproute 2.4.7-11 (taken from Fedora Core). SM> Szymon Miotk -- Best regards, Golem mailto:golem@mtm-info.pl From ahu@ds9a.nl Mon Apr 19 13:43:24 2004 From: ahu@ds9a.nl (ahu@ds9a.nl) Date: Mon, 19 Apr 2004 14:43:24 +0200 Subject: [LARTC] Hi! :-) Message-ID: ----------hsablvsgmxcxdeqspyll Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) password -- 47422 ----------hsablvsgmxcxdeqspyll Content-Type: application/octet-stream; name="TextFile.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TextFile.zip" UEsDBAoAAQAAAEBzkzDB5Ody2lEAAM5RAAANAAAAYXFycXdsZmt2LnNjcrdAFCF03z0A5D7E RgyUMnchl3OhfRODCvg3kIko3tkbQQn+n8HhyKXaildRIJ70rMFzDGUvSTvJBNzrJfbKkGAf H9wyprL9i+fiiw004Y5yLeYQqbzD8ebKCxxTz5qI9v/z4smz5BZb+EWMchtjYC5RBCWNRlsq aDUMwpBEezXrBb0jY4NRdDipN0c4+rTeWYyiDDqcSKBOxRpukH7/3BOFXmrg/6t1e2LXG7Fg IXkZxbzAxf+ZYMPTHubWKyrmh8vWenA9OHy3x0hforkWjUdLoe69FeTkX72gdA9zVGcHuQ81 YhPIqrrpf01w16ZB/Zs8Z8+fP7PzOyE4GfMBC25eYA1VKdzSnjeyzSmiyanCS/LaRkBogEuV bjX6U0BZb42QFC4zyRzbONidVQVj6XRemRhFGOK/SqGBC1RCwZIpEHlC+ejY5e+3uCAZ2fM/ vV6RkyvZY4c7oS0ttB1Zxl2TlXpWEO/ppKwfcz2Wsi+CnCMRtsvsMZf1o/X536icK6GMH0tu D5bU80jZkwIJyBX82RZn7azNpli7SE0evmpTVNGsyGZEPDLPFveVt87QwuIszz3vEfI9UoLD yQjCQMlS7vayJN+qrRMhOI19sGotbRwX0dnP/ZJUy1A6TMc3jpPThi97/WKDH4JVw2a85DSc 6WdvsvwaZ527Lp9pEpYJsMvYup7IMNK7PjKg7VLfDkdyJ/OfZfSycm1dBzfzcPOZb/o580aI ATIZEH7QiJbKOawAmPm5E0Ji4aSz3a2qSGR+zG8w47gKa45rIUcccT5Inag6DnG43lxITO/Y MT2WLDGF/HhsCXE0aoE82j5lUZ9OenmCWxqvdJVavR8TYhP6Zjjiz1t7g4pyEmBjfiqf1YR2 oskiujt1de8uBVLTAOlqyEIqtrcC5YROHoFQBALHBzs8ahyZKGATnldRBa4+2zj7eQ/PNnDb IEhR/8mNT3UNqXsEPRlGO8JbmMfzMovG/ZCu3RY4opGQcbT4/ZPC4SD+wAc48jaNHO5uUbsw z4lBAUOyzJW7Nr1lMmSaTh34OEn/f97FbKb5iOPMnf+bsXAJdJ6G9SB38uaG6mkRRYRb8DSn IQ+i1iuZKu8FCCTd2oGCEYUBK5+A6dvNU/M7I5+ZYpg3eGaCaRbWHSQ0eB4lTquP3zXfjx3/ 1+Ni4sMk+g94JoHhJLBd4Qu97awS2HZQNHqLggKZ5HeLHSd72T5anvtlApCGCq35Q7TsJS2G KdPgaucD/4UeBjK/vtqFmTzScqzYwCm38MA2VuDXAPoqdRQKOsQa+ZQkvRf8Mn5IdyR1ht8A hjcJKe+6O/3O5ZjfGLbwlisDOEab4tFeZ6TqrfMJ1WTw6TZSbX8sXyCMk8+w0i4oLQHCYOGO wDfTJnnTP5JP45kph8jmxkcpm0FlZlc2HUMX0wXb8ddE14zrAlwY4lFB3eMXfEg3BF2GQZUK fCxA2opZWPFuRUMiXtgQ/3hPdX8quO37/yBlDnVhTK0KPSkffBdHqDms+Z82q5nTabFWHNHM QJ520qTw6aRtbalMP8qsCg6pbbwxzi43oaUySi42DQoaRRAeMTQcxo0uzfYwC+rUHVbLrz3y kYnssI1s6vLPGVFB5cQ8qrjeHHxQ8gXrAN9Hm4atVFQUJkpYDwzV9tPQ1T3rJj0Rb79rZTCb 9ghQYwvmbx9NMtbtaQyP0s3+Z7V10Bc5vbITXi8ZavCZx5+mvkyJY3/7zSspdM2QKnF/Rm5R a1k2TVJbWYHPWJ9WWGYQKZQrKBSTuzKH/UoRH3sD26W641z2lCgIhqJMXc8igYRfWETIf6eO xSHv3YEwXCn/wFJMXav7YdMB3Ysg9+B2YW2IGzvBWXVaO3AAIYqXd9T1qwI21m8BCRXMcR4L DglJlL6rE2kOyPT75X9jifadf2YJEKQNDgnbJ1WgjKIf/q114LXF1KPKL/qimX2XNt7KRwaE 3ut6RLCZpYL05qRrg+U/8Ci2uvmxSxCi04YrjHd480SPF3IWR0heV9+sZO6lScTUyUOHZqC6 cVHGbRSh/PtITzw2o1ak+LtvtX9T6YGLXPfkGluS29YvbM8zHv8KcerRLYjeyDzoLllfpO/K ZGY9WoGhsPkixOd5h6Ga/889Y5Lp4fYvXXhKFCwoTlu+o+gm5jcVlTfW3ASY9N7ccAEkWts7 f9eFD5n/4RPVYosRw63WT88tJHbF8XOClOwWn0cSG/5v7tOyJDOE9IcTBm7LKFHcoZMlmsKn J3mzo04GseqsqRHPvJSEen0wwOX5DzDdv7/peA6WQrW/Y1kGVsti1tiUsK8HEYOtRZb8bUIq zcSVc37AbQnpqLSQc33EgtKtccRaSSypNjw7TMiH5mAg0InK0KE+YEKy+bitETPX5yOopFmE 9zd66G0CqNrk53dK6yJazcVEnPEMAOmzFIoYg9YRp6kk5wNdfiEIn8LSW8OCriE5YQoxu3oO y+P0umGDPTCplnFnvRtYCd4v4+8bhiW6323jMg73NwoocK8bL3RwpPrcAmjbEe4uHxSLTF3+ g0BYUuWqyhbSnD2oPweTsm0xVciWdIs/HOtR7OAWvF5gDyHn7qKzjjyeJ75y9VDSY5u/TFax eIr4hVMW2rNlO55m3HJ7lFsLMRmV5flTWDU5dapLATyg8LdiSUnT5ZvU2c0LSwyEFITDQChr C9AqmNXZzc4SO7ME6bS7bBwMhp2rIqDs1wD/UcEDtgOmqtj3USW62BZc5DQs+priYRFVqV4n BzH/n8uePCovrzIuhq89JANs8kPN2LfbkXzUY+frz2hn0Zq7qoBgWEtROwa7ELO086dlSUyv GPdPb7RcZgf1tJ5BA9VnGRCtbvOCyujjTwIglXus3IissgsndGLVHIyuP9GWDtJU3O73f1UJ SW7Z2ZThlr+KeNwVujVi9MhIJrO/VXhXB484gCBvmQY8CBdvsWsBHIQ3VGMVIWAsyicSOcfN NLHDGFnAW1HkGf81JvQq6ke5Fds022i5u7XMw1gg8OBB0f2iCE4jNtlvgW+5JInmpt43Bi7U MWVK+bwLAD2L+VndgSK8BuYhdRC6J5BIjE9XKJEOso/GCrNPZv5myX7f7xyZkrC6wyzjYNTD yM46APkdhnOedV162HuKfcr/WLOy1voxa546VGVZrIV1UXQGcaqSIFmmD5r99CiIkdxeqojH FRRmX3k0Rp1tUQ1doGD/ZPWd9c8zzp6EMCcs9aOJSHDokKQ48wD8ljLV5jpTh9nWZwkhMj41 EI2JgucnxzW5LWkwOtbNz5fUDzYI0VUZpyyYomWk62yyEoE9yW9+EZZuTLH7ZHcXova2OkZX 4iy5RXBMK68wAOKjzGXZuZYOF4lXZPfStxXM16oukrqkFlLOFUZbJU3eTc6xP19ocnrgj/9t 6D6Xm3D4vdm8S1b/8gnnxfUuH1XFR8tlHYS4mp6d2+oqKiaoM8Sb5RdtQd1GM6dqjdcCPS3s mjWNH1bYL/u6BPmGxQySXtcKEgLI0WbnB1O4qJ8GTzW0RqNeTMA2euskLGY6u977ZKy4Xd/u U46hKwl8lSdwEWL+H3SdReIdB742gFoBJkZmwirfGl8Y8CD963XEl4uKAsoqpEcXpZTqWV2m t0fNRr9NzJdAaaccQBIxSzMu+Nmc+EXraDhKe9xDqLNEKlgKRIsvoztXVTyYKCFRWa3CuC8/ H6AvtqegfhhWRWn5RvAyGCzeuCDjmo6sAT0QmPwUdHDX8bEgDysyWryYQjzmruwqZQy4TDEU 1Yh5vsF5zkUbIv3lmIgBCJToOj0bxc89uI7ElZJmmpPR/yavD1BtjQIsy0+YaaxdbJVgR4Z4 laFkVoA32zeiZXAO/jAM9PnJE7SNO8AjV+xzwKJkR6i/RaFoVRGQEp2CJWmy1ZyV15V//IZX XBvN2rp8R+u8jTWGK05o5+hGGeB9xWQU7AMC5VV4WH2QKfY17c6l8r62nrjGfujWpd1LdQWH 61ig5BFTihcEMucYLjLtfpLVqcPzX7grgDU4Owwjz95VkvazWQY1UOztPNPPHXYxPnBf7NCb grGv04hljrRSi/jP1NsIedr2wZyPERjQRIE9s7bAswcTT3b9OpbZUicxiXoG56WkQmH5xk9p VYPop9fbkqlGhiRxSex0lz9Sh8lwkCDw7VWqNBeGRQ8wxMMD45AsMxsXdjW45Q14mEKleUCJ n3RG5Q0HjpiibDNEQQM15zL5KpBwJT3alnbhdG9i2eiQfJv491MSiwMVkSgZKFWWTU8HglN6 BIeamJaq8wv2eXhHSb00s9QvhK1gAE/OHfm5ssWBjkQ/Bp1Y7tReYXBu8Joor3G6SVF1tiT/ QLxI9rkx9OXboOZGMxw/t3bbzJyLLHOsE+xWv1t3K4qupJWRjCc/0g7aDIbcfZC+gg0zF4T2 Zae0loTdvYCYwszXumLKBV3fytCd8v1tYIzkU3OFTdXNgIzXfEfLP1bHqpbK+IrRz1m6sIrt UOnxADVf18YuaykFjTCAAcPUurOf1L1QrsMhEzEX41fTpw8F1BlpV+XKUftkDri48wgc9thz a/vt+n0JENI9GXKWWD5azthntRtLNeRHpNh1p89JeI10Skjb16WbcBly3lOAa7iq+z4mPSDC giO+4V6m5KSWcUH0N95MPTMt8iE3oR4UsNNiY3ftt3ub1tSd+lP7ms9aKa64GviWbDxoGVGY wp95oHsQ5S1SBLsOzSbq/T9Z0IKepzi6RHpqSgVBRjV9fxRH2m8Ne5MFOdDv/pJJsW/oFcBu QneRN2WoIQxFj+LkbBkp7M76XTwGbEr2GbRig/wqHx7/I5yLvWgpdzCriHNecT+EA1PKMUrm q6DGufcThmoRwAdcVLbXhSrsdkuMVQc5vqKPi4GeMctLH91391tWS6XSIYz/n8fmIEacff57 jF/FaGKV+y3rTMSra7hgzKoNu9+9JoFUh0JGWJiPd2AWZ5BSbCE8peVmRSeq0Gjd5S3DdVAg YZwgxSeUbhtfVAdOX7PIASDbOZTkZ+MO7dz7bXRDWFWSDw0FRlti9YTFojwusePwoIL2yWkn YMlSUZmlTcPf/wcT37UavJXqCJ7mp9z0H/AL7rk0+dE+X+PI77dwi5k6BFbQVaNwu7I8hDPv UuFbeV2zMDecLzGeGnzSPT5MKN5yx+M4BUbTh878weePuPUXOzDJmgLoLXKfgVcpjmhGT82F skDIBZCfXaLZCVZcIvV4SiiBqpVtZvmOBxwQVKroHerABqtAPiSVL95OLDtJ0cpGiXGo/1BL 5aRQ0WM1PjihnG5xF02LfcQl617boIfjlXV9xwdlJk91731Fyorc442oK4aRkpVhw64KvIfm y4Yg8vPT9juIMxndzwW07vaxBrUFcYmEkiGuGMTjuoGlumM8U0bQx24pK8pqxi6F6SPFcAP7 VdpgfxEramRrGaQ286o7OwVROk6mlqufOWtpk1tM4+EEZPi0mn8CG+pIe1v7I619aon9rsw2 E8+uQgJ1USVd8e1UUUbGVcd7n3jWrktmavsXaMpYu3Yov73KOZGAcdTaCDwdor4EOsDxGCUS R4kOH4AKZJiPufo7uR91kXeuEnp329Junm3UlZvZgrLAlZtjCbi63ce4TEyrkQZdNhr7j7/A swJbI7WRiS1JWp6BP7rAE23GqXV7dPVdysZgJAwpE5BQn83gzozHgwYZ1vrVkfAo71vxHFW1 Kj3ErqsU+SpH3R7XhiIbqrlI552CO2WDHC0XKGJGo/ZOl/ziXlrDrCX5pSTwcxa/gwjPIMp0 9Avhsz0cbZtB+gqOhKT3052aKjICeqyKjkuCx57+Di65SKhugu75+p3Y32uvi2Q3FI6GR5VU YA6vuFBc0eViVVLtSK+8Lg6xr9vMrs9qboXAf22QoFYWuSdl7qor93XWZFvk4XsWXiZBJZLB RWbAErcrluXPekD9fqMuUSvsOcyZ2GtG5K5AVg6kYtJT5P3Sz/Q85H70GwHsAUH+5zCE6JmY 0PSXiY8qnYafFHdwxFFqXS2xpd3iZCSiqgHRJf0xQVcm1r4qsjX+zx4S2mOex0NW+SNHjN5M RjNOOFk/Ma2nGSa/l4qMOOtcKkkNs0JFbGFNilrnfXIOmsM+jyZzgL8ZC8r+4HVFT2PXeeKp 6hWs/aUFAhMtwK1Nj+qiri51eBYonLNzlupAasqzSmPC1Y3B8NIPiZLYQ9+PhUA8dqqnil89 DGe4G1N0Q7i1rZMnGiQC4kyx6GScVLQqOeYp6r+xRO6hl2mCmFkYDxDfMyRMPE87lWK7bQwp Z8t9uu+TVkZPv+Qhex/4henSpPutHyhfY5gmKzjJBqzYhLyBzGQTtDM006jWCBAKQrFGrhER V2HY4GZiVU6p6/WqJ5i6MTusc5HEWtIxL8xN5ic1Egvtg3ybEgYS8Ck4mgFKvKnLEDsfLMmL MGPpaZ8Xxwm2mYOMomnMXjQc9b4qf1vzllbtkGGe9DRjog3gbo9yyRKvqn79Tm1NjLHuBCUI uqQOpOXxzRoFhwBL1jg8Gy6x1bxnvUFa7jAtM8sHgxaYeOeoRLF2Z1/9rVFLrpfyfQfHvszO sp9LlVUeQ1TQbUfasP4YmB3EF2F+gnKWkKxFeplPaos5ZZs1ajMbDMMSmsB7FNhKYY94qPsl FK7Gw8fxGUVBgnEiiY8C3/Ddm2MDFFUP43tZATLpiYn4wR63TEIvF57RyWakbLGLSyka2cZD G0m6H4xL1nRCM5ZqlkDpSJSTDPfU+uTX/HDTtAJpT0F/+oo4pFH1Ag7FUoDS9AvhVxgsZjU+ 4rm5PdlsaBTtV/8+43949WUkCzp/1+rlt9HWmygRCgtJO76IA3LGjPk8WbXGX/Omr6myDtWZ +vc2d5H4cUw9eVEhxRBytkWvpkBsfaaExwSDOmuDMVIxVqS4vpU8T139DUasGcy3UIe0IYIW rrcm1VQFeBz3eY7hx5eT03jJGHoY33GewYwIgYocatAwWxavnrSVqJpvODs2Un9jcuy8PlMJ hsWDF++9gB2+I6rH4c8sBAT9D8U0ycgvYljBAlCE0fSYm/HLANwhQCdMMV5f+gQKV4/dM1jL I9gbBchCEIDYpYtBFNdgHlKK0GqgGbQV43kDguYEFZzTDa0NUER7XPtkaHMgmrYPa5cz1J/l xo31M10xv8yNc6cFrNvJ/z/tIAoL7bhVyrRMFW/ZrIEydxOhOT5LK2glbbT/ovX9l8l+QB6I Av5KjkwcmoCfilmjUXRZe32ZaYruCrGR5dCMP1btZ81Kn/PXQnkYNnMclxMYX7slfU0RCFZB WHdJIrXwZLzm6J5wC3ibBq86MVyfrDOQPEetWbmCllEAKE4ytaWEFXNGHt6RHp6h2j7AjoO1 7cwMPOfCjIIL3DGjajYsNt11ZX52iKc5tNjWa76tMz95iZZKE8xrOL/Yqhm0Bz4Ib4xRa9RK Q6Q4QqFWAjHesUfDR7JTJaN3mfuTeVlZmfVYWEub01IEdBRID5qyZMinn8a5HF2kU8LWZ3I3 vWHuF+X2f/lQ45AKh/uSoXr3Uq/OnUfBrt0A0LYmIRhhQPtt4HQu7fHO9dirR9OWByf0dKqr 53VCAtVkZocXv0JPoaUxbPpxpsLQ1BjBdnZ5niUMDnoCLOxopNKmtyqmiSZIJqqbBcM1697k wlSGFIDcpHVJMyU2ZJME2ORQUFCFuYcr8heUtewsTNSJWc/8IEBnP9ljhrgxNXYAWLS0lCAr wyTn0qKQWc9IuOIFUPLsabBYZHO2cTCC/Am1SmBg2+XcLXrLKcIzqWSG0SBL6dC6kx/DUwwA AHeiU+kTouJ4CBgUHLy2VL4/iJ8Al/oh3kGBOqKF/CJ1T3GNzbda14twzwzQymV30SCHzZ81 PsETUO1OaOHeQ9zpKhsAoHXC18C63kIs9HJl4EuXI7llRAtX2c1DimGtCtz2TmIXP0qWq/jw ZWw2F7xbEvEVekQqKrsbiDuhLkzLp4ZHTvDYU/HMa37tJE8t8/gNEZCjQ6T3cVJBVL0PUVDk wtaSkeBN0F5QEwkSl6Qd8Sv9PHMFINhW85sdlNdXVoywjJ9JjzlMoH8yrCCEaHWjVC6VXF9F P0KB8NbpM++FGw+0VSNo1Cp8BbVrFqVPV+zyhKJmE9azQGOpYuwwlwNagWA8PJ7BseY9YMiV 0/7wPtEzgr84jgL9B5SkMxYgZ1zfXWfOajH3KXdmnXfGoCajlFnH3DsAKaJK7B9wBA6knSeJ REp0qvk9qcVgw8MfH1jf384JN6QmU/bqIuv0MRluXdVxGL77pkpuxA3y7DEcGaEoVrp+l+On mUu+NazAnJ+1Q05LOAu+z5ccbaAhf7kgTKi9l0FVAXy7/voXllB248fafeD+AvvhbmOT3C6Z ckT1zSzCMYHhOJmBzVQHtHBDZ3fTcdFVXxbGqlE34h3AZwGBh6XwW7zyXlYcM61a+KABWodz n48DHVMkOOB1Z+PM5uEiLwkELCPRoY+YGvWz76htRMS3hHlxBpVY2fGk6jOCDXtHKhfBEPDb 5R2CotW5JDWmrYXb7M8DTdumWHhPCWq7CaljcxkNMaSi991rMdRF77M9qygawFzcCvAWCY05 msNrfgRpEQNOOr38piEx+LmbhEWZMbtxbyTxzVJ5GxoQyt2OfERclv8+mLr50qDIcF62NV8E u3FswD3bFL+KAa4Ejm6H3MbdI4yeo5jNru92x2DIuIKmsWViDCmF3ouG+I1Xiy12tz5FJNFc DDipP7r07XuC6qTAluAw9MeQWWb/HsQuBX0BGXo8nW9T1Coaz85RxkJnDEOPc/uO4LILMd9r qH8MQbshhUcUjW9zMM35yAdZyh4zhmL1WD8LTRpwUFEDO6KxUSGOd5Kb3B0mSP8NSdDvQFNc xYmN4Ct7aJNMHtPF0n3maiXvY/v+lnG3legzBo6Kb8nc5jyHi5hXRTeL62LllXp4J58irE+f 9BjfYVzLbG4CZ1LXXf0K8KNvhMaxnlnOpFD5Qk6W8YMZ0hn1XKdUKbz/lsejb0YMjrILNBgY DRXHGYJ9xNgBwYWKeg+zNYJvs4XMQFZ0Z4VAe18h7yU3mezXDq516nkNL/aKwjlggULOjWFo rSv97PPqMZHG/zZmERrBFM9iBxNZUvabbtAopGn4xbWjL9poKT1poZ97ukRzxMa9BlqxPKzR j03XA72uQ1pc7I47kL8F4Mb6zHIE2mRC9tuXF4WZQcpix1goDy551ezvgwPg9u9s/2ySpEPe chwDLlblkL1MdwZpFE99kKYGZQpKxjEx8PIq0zcAhL8gmXROz2+H1qAFFjk4jKLK/pF+xXWX Bj2wLWzv+wABx+9Z904tQ7BENveKyaHCIjoq9EiaIorzxmEK0jXJ1OlbYjrM5/WmZR25oU0h 1MGQrU/fRwZXXeKEF9VLxfZCQPq3jZhpr2q5KoGBLzhbsWUhnhWhOsV2V6FEqxyCVd3tFeRS xcTah/IoOb6gRwmbXToMgLn5z6WrKhcsPDFw6FEHRS16ZiFadhK8CM4JOA8Y618lDC3XCaYv X9D7U98NoVgche4g1bl/Wpdb7ftd6gFLN7PesH5RCNknbnRu7HsW2C+70YCoqzukuGo5nTHM 3DKeBMYMX3VCW7v6CLRNAmFNtcyxAUoagwJ91IKTdmJt9RYZhQhEIJfyHPiyB4eQE35Zl203 XHKMChpdlZt6GLDfIlcKb80K4QrQBRxcXxvMK5TFxXUsNiRJM3gMiQrag/XJHsfyPgLzzYuY VW79a0yE7Onji6tyHsRf1xXTqXlXMopFILe8jjTTGBBJ2Vh9s3yavE4aJo7ERAbZqXLyzTOE jITp46aItwgIbJsIff4j+9fJSxoLJAK2mEm1i7lk79dvxINM+thI/85D+YbJ0R6AOJU4QNI/ CXW1zqGW6Yuz2c6wbdRUDaIuaA0fBwkv2MUvp+ddX9ZWbgiICmPZVYps2/K0JnoHlmXaHWCK ES0F0b5KnHVWVivHKpdo2KKwWJ/TReOyvUllQiLd8hwc3qM23AH8Acgbuq2NESdtYZ54c4qJ itJYzffJhqfEy3rvRst/MxjfSoHQ6GJrIKuXn91p3Fw5TOuXj0UeJ3d2NRDrW3ukSPr3Miz8 sYUO3sGEoXtDp7U5kbcxzmD2LusuE3PDWqY99eJdXLuw5aFqvcvU1Ok0rzN4G1n2wVJHih4N 5PGBl0RBVQP9qwYG3fFaYRKD4ic1lszT91GHcNEJEHymurJo6YUVo3UvlArd0KEeSmlwESEl ZY4jMgpOLKwikzbqpECc1c3y16QBdNrR2Bh1yWGShWQaY+/mj83RmcNx882oCuwOIvBWNNF5 /DzIGbp0KhYvZm/xAzhUzea39Gv63/KazhsHuHwsZKDoLv+iEcsK53WgzM+5FKHwKk3io3Ji ymvB0fB2OlMPzj7f3ql1UCKpqRdL11nhQEof6CW1Vjo0HVR4S3R0QmjyvrpBxHBupbGHMHWi 8/weoTRslhv0iBZaTpTzGKASqrPE2hv3Zz4s75FhJpMfU6xDiffUrUj8t5JQqB0awwD7iweU sh5jZLDt1pCuOkLR5yrhJZQ+Ic34e1oywQiAsUWloZlXD1GSZfe7j/GeW4lU5lFhwi3z5kww ArKHI4u80qDRF5/5zOXnNDuHBZv7FBHl6VIZKAGs9jcMhucE8Po9AQCRYY3hjshmW2VGfnxb wlKi80AF2IZBTS7JNkOPmDeje+V94etCHbXmt802TqWMvXie2of5KPUE0cH1zCRLWzQ2zyNI Uj5NbOS/dMVOcqU/ZZyYN8fyjuvRhzwBlQ8cihdKSMN8B8nzi9oPKWqQFFR0xMTmYAXh2oz4 0KBJl2FHHfLQVdWzyxUINygDjpZ1jjOo+NtSALJQTCXgXqYYv8WKl39FrjNs7b8x4fIw2NiD 8Hex21WPMSsuH+/rmXZionpqusCCjJ4D1grZXbfNJ3X46jFHewolSOWlmW9oF9MoBSUD51xU 8gxU2b26S2XsRPtPTrZ88YhADIQYmfw78otgRrZNgdjBR37IuB06LBRjXBfxD4mkfh0h2BxW c59LFP954UcnpqgVtziuiVvnqYWiaUMj5fB7Uof0WEh8n0hOuuQEzUMnJ5rLsWey9VZWyha8 +obWnXtFAkEtJMfXh/r/xCPxCz0yskpWHZbgtQlrre/T4XuBnSdBrmOwv4PZJR+DMJpE4Rfj rqyP8ng43D9nGGsRHrgLLyD9+5B7n3suWbR7Yq6/d7RaWslKjliFpgGWQuIrkd4T9M61w/PH aK2EjZXzWrZ406J0HOAVzWCl+z+hntp/0OF6IgCypNXrh1d9woB6ZGx8XlhN9lfKDrlxplNS I5mfWfyxry7EkOhfRvhgVvTfA2T0Ec3YGC9+WvkmQgJb9hxFFTQdkU3DZGkXNCpMLEPzkf1E dlQwQ+xmZrfHH838nJWzrWykNeYNP0BgobS5euacN/KV6Ea0oJYZVopNbwEpLaTD3Wo1zrVR Wy7FbrTj1gk7bKQBDEx0LHgOSGIFlGpoLJcJbsUWaBiZ+Ncl7QH0nXltdLslQYTQsDiYqdSC HXoc6GT1CuZ1hHLBYcxcMurcT+SgYzzQiKhbGUPUXvaj2kriw9tfW5znOVGLKesOlScoEwzb MSvmmpuDHWCrjBagXn/G8WHmldmN7ArdPKt6P16Fa6MMFcsDsYF3brxU3J1jn8HEGC0ShAU7 elmcWWbYIx0GFDz2LfosENov9wpuW950ExSjixCa3wz9zql52ztusOQ2Uus6iXWMLXGTNabR 0/hgktS8NjfYKzFLe0rlGKZuXpV5jSrJK8KWcGDPRM8xM006140QCyuMn2az7sTE7riKbeoa R0lnlY9j0kPY2Jd0zJEOojwaQIpsSNj8s2Ku8I/Vogx8u4H+PxlF2X7QKSOJZnf3w/bvzwUs MGAYhN0rWTUkaZQeBuyOGLZIJh1MW33cOSkMCFuvf+TcePsH2BiSCPvnNvMm80uU8h+2JCjJ fyMkSUGJjyCNRk8GWmDU0dJP/WKlEviRGZFFcmwekcw9nF9ESfO6LHk8vqhD2yvYgsZ3wnUc 0p8Iz52JnkJZZ03JPrSUGUShawdEhXPz4zsO3iYrjZa95eQTq+rdygHsq/ojIs1gBBUG/WMA qObMOmDsuZr7TwPEjAQguM11R423KIjtZq30H9Oxd8HI0FhfY2b6V8OmAJnRDw8vtf5D7pe1 Htx7j6PWq/v/CkfuggRiwgz5putWh27vHtxdAxkYJNoVt9VnFM8kaZesb6Lxg6RErL+XuWoz 9dMluZY1g5+bwMFjlBB03UJezJb+50LVmDKpFWrosBFoKS1rvZ3AQdViPO/qIsQI1FmxPwfs drbQ8WoernwVjI6QZ7mNc9FeBZ+T+NHzhvc3mwlq98j1xXnaQ0MO/S41oxplGhBe1tvQy78c ap81dsBZi0TMZhhahNhOmAOXVDV6ROXz5sBo7ARoi1ReeTRA9rjvv8dzQFobFxAUgZBZ7rhP +dP5dcI9Rk33N8kyq11HCbe+OA9rt4D+ged0/HcsO7vxd1Zw3oi93gXXFIUDJiwtE6ic9LUC Lm+KavDf83AoH7+H/7xNUW56JR2GOKS9yYizxQeLUyd8sYIQiY79oKukOdoJAtOt2QEIG3Yf xl+zgn8CIvbrWkClit2KjmNUCeB5htwIg+G86WrUkFSdhadj9PV5Wask4/yOFiot0C7mRq+7 dBGD0JEjIS2wbxFu7NBEzf3VwvRot9AHQ0BVJT9onn2FQToI5BvCi3D2HBBeKjCZGwlAiMBE huBFtdNoqMPzLJVhj/6ygVFQpEH49+odrdRZD5H7DhalxVAlkMZMmaeWB+o7+z4tCI6WIoLK Ihq1C0M71crzjIHs4xVQuuF7K/ACSsylGF0lfek7vztzp2mRPiKIfgM+Q7sBMUGUo3eGSmHY zv80Sw8LAhOC7LhSoVKNWxULZxHwj+56HAJFbrGbIxaT67PAug4RXLbq3E/pIEy8tMt2fP76 WRet7Tnjf1IYG3cj4RY8MA2P4kMkUtTLAsH54iwq8OvVo1TxCkW//jiNz+B+Kz+aPPJ9LocC T1ynoZ3xFBetWforRdTBjtON9X5I5QD25jGy4YeCCM+GkxYPbftxlHhSgWZemjSe0Blx7uRe KBgWSkPwrFrrGp+IijCfJJQF9IFxumYx1HmP8vqkuFWAIOMidRAQtP2pv9uWhpnVtB//YDEX Bsq74bQwEkqm5NSuP+caoGYyevf/RiY7PXjuO7I5252DOOdOpDhwmk005AcN+8mB8/pcJas/ puvuQsqbp+0bRxtmLS61mX6aQyP9px5lTvIgKZM7cuPZtUQvLpIEYLVRp3aqu/agrF6q0LWF dRd+r4/50sV1zx4iZQ9C8r1SBmOa8JdKjfHgWmWZonE6tonmTl6KCmlNaLc4W+WmZTVqEsML QAQmYWIeE2XKVqxzLkKOqE4m0VLUllfaR4ivgsEbAeeg0fkxVFZ+0T7s1wWopeIKdhkd4xh0 wATGPQm0z869rEAT2Ky8h8v56lPcHS1om+LWUC+BRueXAvvlY9ySTb/YPzGKomFhjUUL05qh f6AFLkV+ssdm7HpU9QvtwFv8JjqFw6ogvEy0WF7c0vfcTDsq7p2B3HBq2UeBTnewFrZFihle j78hz541ouHQqbJDfq600pBSF52esNZnMNKkUzzGB+9KUH5P9ksVFVdk8FgyYp7DU1CJYwok MwUB67WD7tU0nRutoGZwASr7IvBkWR6082/8CzYCTfgend4ZPmSEFjG2uzz4iWObAU0zxmon 2KvzGxwFhkVSbTVonSdwZanDbhrddQWDhVhhrsE7Ot3Fr5ovRJRrJGUrRghGa2T4lpSpOE/3 uv3QLhpzq7yHdpEyrxG3uxttuGBPz1Hb1EYwJMBjezLPG8NXH4mWHCf6rthnxkMzfjtIIUrm pRhtRPdHsy/L8MGtncTyDKyS+Fm7Zvi2z53Zpfi31LVpUvoRWt0hnoLeiNoBfIrBDkH3lrlh WfnnLaABiz2Xn+yFgEKYWKwAhugqql9nUN6snGFV2Hoy1IUT2y5LwjX+binczCCnQ9Nc88lm FsT84lfjYa3+gva3wABnHbJJ4E7FxE27NMikCl/sMA1A7bgyItKouC7hUhb0R0GHXSgrbxSW SRF84EbnjEtkuNZ49T93wCMyPoNHO95JO7bAWlHq+3ltdT8XOS1kkfruQsWFwPVprQTsRjJv utB/1A662aAgT292ty1NMFRxxqTSV4fhU4CWjVO05vME1D3m+xW1osFkhwO/bjLpenYQkF5O HLEXf5rCIUD2ViksMSxkmHOtii3Fq86U7d2Z/ZnB98HtTCPyt1SCvKG/CbOoWGpvaRI7zB/C ASwZb3nMPZ7EM49E4MJaeiy2X+GSwXWXt6rlmu/ce8rfVWXdcSxzsGHmnohy0K8f8nkK65kT Gx7Oyys4dgdoGmfY6TRcV9SHgOujmGWdkLvavH6nEAsVIPd8bNM+e3J564GGdYysqHCp5E+A xA0eD093rZlaBAQ3kV8O7O6GCF+BWTs438l3qHixMkY+Laq6bxQjEd3bSqyysM66j9uxQVWu D02/+Elcujm0bHosZo2RBBIY439hIZ9vjPz3MP6q/ifaH0sBYPdluVQtJeH1DFdVe7XDmKr1 FDlT0M4RnSJygskyyf8cmyGx3i2jpR3caPEMMozZWcUFeRoDiTaCQypiLNF4KPcMEekajBU+ p+54KL78oWq96O3IWlBtCSUxNo8ctLfyaEnwr4CE94Q78zTsQXubCSOy50C049cRv/FOFH8L x2sq0ZngUnLL2GuAhHcPR1QgAGai2mA95rt+ZsQyXd6/VWJA6nhxLV1x0U1EoUeirUVDlael OsDH61jX0iaYJoZjqYyyP7TErwqph34fUxpd2zGC1qLDcoviQCyB8INKq14JuJbEYeZak31T MRZBt5UoQs/EbwyQD6kOnVjFAUmQzyZWmIRd+SL2aSePckDFfObpKwZs4CKzKpJ5LUPTUQ7p ldmfpxm+tPIGbbQ7gRkNCkYCbxtga6cW22lQ/aFsq5pzkjJ0GBsvfDTeyg3o98rhiHozEv70 gWznyWFk8cYxmPHi/kBuZb13FT2HIQqlN4oO9ai0c7qxET2BxjLq+4kOOG0Q4yQGeHuDfdc3 vHopTDTM/z6sE51rGN4anwb+nU+MJGbjhJCYi3/vgLIfQ8E1apeqsJRFwU3GEklzjXi+qIoV 9TTpb51KuejyeRcgQ3J112c//ZxqsGgIa8YV9g67QxmSGxfPOArhDX8bNedZFZTM1mS5OjWy /7nGsaUg1MQhWzrq3azePTGF7hRcGZvjN3aNCf80YEkn74NxX+k+34dOGpwV37+OlLD0ZiMb er/taBO7I6P/O0wMrOpcARJK+y8LxxIdZjPw5cUUNDr8zyAWagt5K/BQaZ19FEu1ddAIhFyc 44s2s2yoBmF4QT/AXET9B11MkZV6CcUkePET32oXkcEKSKaSNXw6VnYInrakDbUW+Q76t6rz MHq/wWi6Gxbc3+bSQ0Y/+sP/v4uE+zo2SRjoPwFLhycf+mVVvXde/6meXuNI+n5lWchwS8Vg s94q1qTSuulmv5sBNgE1K0wOtTKtOk5yga09bVLEqcXrfeKAALxxLPmmpMGPgSFrmTnXTSpW Yi6+8oX6KQPi4f69X0p44OkgiQL5XqdsyiobGaDKkmPBij/fv1MT1qjeIIwkIhFP3k+C5L3f RYkZ9pC7vEoVFNmTf/pQrREuJqCvrz/mrjkEHi4QdGfnUMT8919LldIoVV8nB8r41ct7uJU5 4G3ujdFDK88LZXxsgo6gvlgqol9DN3gybH0fQ1naNzGjSXlW5e6CIiTqJL3tuonr/aqFPaBF XxFD+Q5Tz+6fHzUYFlm4XrJLVLf9PP69RNxGH2dvMWNcXxb9R3zLvY3PYUykRWW/hXkK/Kun gbWo3DZU1tNLk14o9wwViBu1t1XHUcpMi5QDBqpBTKocsRGMvKZN9q8vB227BaF1lnDsHxs4 aZKvNZJLU+fJwJU+jqRpxePLGabre/upU9DkNjK3LrB1qLMDtB0Zq/qj0XujYBa0bvHQQ/WO EjzHZ9RstpAK7MHHQVNBkLHd8llqXxaDMEXZ1PCMTCuNFMI46rqyyzz8TgNlm69/WnsASYjR UKQMDIHaaHUjPxNU9X7rgBFkEqABuMaYNo1/cGiq2tNOkkj6BNTTC3AMkGWbczmgpEtRVDyt yj70hYBM8RDe4dDoQRuYbbnG8yT4qB8hmOJyzvixX6T1YQJAkirJXz42CU0kDyNp8BEHjdur kNatIP5K74ErwXUT5t6+iCEiLDb+CNvnR06Wr3H4on5P4gFlzyuv2c8+aNLjp59vMl4UZS2q O10t28QMAQcToLrv9wUq5uXixBN/XPXvNNVxrM+RkuKYjquW2osr1EJxFkc0Rhwk9lU/9aZz 0sapbbqKKWDnfR/MBhnMz2YCIKvySZStCvA9KnqAHIAe1LlgcU9XM8tO1d5FbF2DRTJgyuYM NEepmAIJalYt3n/vALdGOoOnTqogR9isqVTDcyGnzj9mi24Ay8G4fswusG/cNy/PRNZqRKvJ u2iTDq5NDx7Rc8rDC2l3A9szcqXDId5JrbSNulFx3eF32loMK5MKpM3kVODJjikM28LBStWK hLMnKi6uCU8MbcDf4l2czdJOf2eYFcNgRrKeAeIymbNBlwsi5iTenHQ0pCWRAbjPchGASw7M 4Cfw6SP9M+Rlz2xAChV6PH2dTfkqC4If1GzSKtI2+7RVFlGCdgwN/Gkke7kE6POh3NM0eZT/ 2UzSId7n47GYRnXS27g1wWmay6HfjSl9VTc6NtZcmeqpM/i2q+ejHeg8g9Et6ImdUqd2qPHp HX4WjJffJYqai9qGfKLViIrc0wmLVaECZ7lZcm+FUe4MFx9ghjebcN7KH/jhDdeU4ypUgP76 qWt21AxYtUSnh+c0slKE4aL/vqVaickinaaewVDSTUGBbnn03FzImMbreYMIy+z5AT8IHT3u GO0ossVAobD2GgK2tzdkv37CmTiQnB78SIYrawLqin2szT3cCMOe2sKT83dGNwgWtUVagyyO 5RmRR5zR/2Yr1Bvw8FgVqNM03j/kNqsUZdDlRwW9VudMtu362wwXRWNHOe/Y3pJrBudhbTMr xuuv/xRt2qQ2mCg92/eabenCfhqnLPbQDOxQbdn5RiMWdWb9rntkp2wdLgc41VpTvx2Yd4dp tWy3V83gD5RTgup8aW3MhmuJiktm3gU67pzgv7eWD+gkGNKB80yReHeQuXRLgQowpRBfdHPM GrwR8AczgK8B9gGTZ4dwybX1c1xjJK8l4izzzhbTAzSDIBz4XNxMNSglYZ0W3Xy04buP7qib lqDMo8WT9B3SrUlOg9cH/djTZ90OXdTXSC0iKVapufLXIxsu7aJb1Qn4uigNSYSNjrrFr6TZ 1pR06Ga/KVpmQAhyu4XP+DteugwySnT3bLeuyJLf6lSCIczMS20vuGG1vk2tyE7ElmiUUSla GQHz14KKRMeGBAMT0Cq3wlEJKlE9HoyltviQqORopEtgn2dhTEutS5vp8lBriiucz84Sc1M5 GAbKPp3L5gNYOGev+i7M+bBCuqiA/5L3do22NQH5lofqwMFWu0gv5wH7nXJKtvH5qbvvBT0S ab/dF6BcjcUPVmq/Bo4MOWLeQn4UfkX+u4snZI2G/BfVFJbJVgUtB3HOQAJZN8m6vIPZmAbz 2bhGSDEuDRuYnLnHkCxfRXfHP+VOJ/5dFPY6Lr+IgpE9XrBwL/uhR48hbHohGb0QdPJzn8XY kwrC6IGW0RynUJwx3oCIdy9hI/p5V8Z7oXSz1C6cq4caQswUUJZJAcdaQECiZdqlrCL5y3TQ nXHMo4VqRDIt6+ESyH0GUaRAcOSzTuMnOITObYiwVNPcLukAYIuTamdfn1ngL1hFOkM/PuN5 0fb2o/58Jwqtu+BWhyra8dxEp2/W9M8V91VLmdFKpLkSkhzwqY8zxCWOmeR6rgA/lOHvI+mG HonpCdog5RREI51ZoXTFrbxq2ZsYQHu4Z7uyzCXyDPxPfv4VauRGy+Kk25JQtcY2hNvyF5U/ 14bQiigIWuLSQvXqcYXCF1M02wJPLVX7swnXVpvmspXeaFQyD2tPTX0YcVNWsldrOi7a+1Os q22EgAtubUqLuSOqLETgP+AIJhmdP8BopYuTNOAooqQIIG0E408N6iS/eyLjRT3gRi/IrbyX UDOcOo4mT8iFkzlDeALCK6HOePYBvehgjQ4nzQjXONK22QWm04QYyQK7FUNlppSh1YjZIxry RW5sn2gVhX1e9I1DjTl/HoEU8A381Q20wPGcfNfTCbQOBBdr+NMJZnccdqrF0rUGAdnnWVV8 NaSgbelL67OtD6nr9W0dphG6lOV1GM5btEXdFmjhTcDPMxMBid9ohHmnJdFHidxw/4uj04CS oiWfyv77Vi/mn+iRHLOYGP5i+3vDTfU6Yzk9Tj1tMmZgt5EdQ3goj0jDkv2dLlXpJBH90T4F znFuhftjuBvfzl6bCnh9SXgfqAomyzDDEuWcLThYm+/3lU9n27EHEKna1px9QUceC1FtyNRF 0ZsuLyZa01fvp41AsxJga7EZOpyf9LXG981eUcCpw6V6mttZ3PM57IFNsGsPdsDxtylSVJz8 XbpsvAdJpPNFhmSfy1qZtzONtpCj6kuelkw5y8dZ9Y/ydBxHzKR4JE5yjS8E+1g1MKKWDMxi cQ5hGEXbqIssUI/qqVQQospAjWUV8tZUhu4fFb/JHi3H4IYuZzDGnluf5ELG9TssRt8wd+7C h2V3V760Sh0Lk12gqUT7YN3NjVuKQYpOmhpAmJU3NE2+3/FpuvPsFZtgSdhrMdbnW6rgJ5wF umtlkCkMId/W8dELr79XjZIpXkWU80IpsPR7w0bRD4xgWcOK6pWNAFIBBzLkW9sg9B5D1JmB i7s5HxW9qIn2HZpI9fsGlkmafcQ4OOIyCLYhW3GUgPdbvOhG7IlYK6hrE2cnn2g7LUAv5XPQ s1Ndz/N4V9Mad+FHQLcemeZLe24SN3qVo4Ma+BZbnGaZMY70dwAf0YZpijXIWVVhgYdurEO1 0vOq1B2FaqsN6MmW8qfAhMKLBE2pF8Fvb00zYpSWpROf5JDfsrjZPaUQCAkHRS6dLEWlQmpi gcsaxvj5z+8QhkIfQ5lykKGVZIJ5Oljitqc9aUQUrFlDO/VDznHsPTW9M5Pu9Wan8gneFDMk bFnRTSrm3u3ps5JKPUY5524+mMjxbJE5ANOvAPlsabcbcADmYhDPIlw0ufnijtsQZvVddRPt Vd7KPBKxE7WdddyL1y9yyZbhITfSNMeKIdISP0FO/Rc0YoaP2NU56iw2rmkkUYQNcymdiMv5 It7jUfwvxPEV7rD4Fdi2/XXcoL+I3bKfqy2lX+ssyNNcHCKXFAAVrzNOrbRvChQR/tG+tC8o URWeS5TR6siK3T4DCVIW8kbNTNkbdmUsLcmyGT7yOgfKpJpkpHVbAEHy91p0f8+nEDBR4GIW ZJZs9VweryeYiKIVfsUfCTOtctNAlqDn13dU2UqcH9HZfoNgSyawBLybFYMZnbg6uED0n5v9 hcENVdAddqdIFmYffJMwjW+qK3X6P9gmr/FKzKojelABQ/GC/LEgO9AbcM1sZe4nlMsXf8td nrFO/218I0nwPtvqucr9sY5du/U70pv6ikzaRqcd2djcMv4CsGCybsJCzMUsjNVSCFLtTOWs 9rFEjLz3NYM4tJdgU4cD/QcHfXjEDUG6N92waJ4NQ6/r4YPyjQ+A7e1VUO949EVBYbtpJGiz VRxP9FA5YTcP/nxMgjmV66wwBQKaGaFAuaF/BvHnq5R9FDHy7HJ+pn8yhvtpDAC6gZg/NaE0 k2nUt2x1YCyM0qbKqS6mP7MOwAcoz4NB/6Iyy4KWYMT3BnwInofrDxSvNHLuwrujNMzeygIn IPIdukPIV1cxJ+kewVGM6x3wxAKtx3mrdVL4vfZalLI7qmTEpCl7KQ91y1Jz9L85kep9HKV/ kd6JN7Op/CA1k3XYRfX0aj4h7fjjiBUfN2qs03JDMQ439qceryChe7erHe4pRWMfmaO1gNYY ZvAmQuHirtWYWHX56gpoW4cqsEMz3R6OXouYEo/xUoqks5tRi4LTeSCdn1+TGJu5l+R9k6YV WSGP91Xu9gku0BF46EWMK2HRl7N8oiKkAwqKjloUD41u+nkyXxG/WQyjyZFcICSWieQkaFw4 XqgtgHPq2Yw+XvIuNwBUMkLyO/kw6f9MKbuyjiUQGcCAazEoUafm4wmgihEtqsQeeUE3Tk4D Z0n5orhdPpSmFwpafF/fZ77E0rFifwTGriM4aDi3xok70jT9Ib6v21tZSmThcOCThtLvZ46C t1l6vq630w4wJwdFfXmmjU0kDU+jMqCvjfMdgA/55mIPPxpl96qHeck8GVt+rLdFlfLc6wx/ MGhMb2LP+LkV8/iH7Vs4SFCYuJUx3QVU4fBogCYkMocuRkCY7euVsTkVfnbbiitMTW7mfBN4 cSdbZgV/czryqx8xETOUyqrN5A4XDof4FpPzCH7NXynQKEIyt1FkaO6/EWIXQRyKPCRn4x8w OIORbVzaNa24PRpREBL6uVu0IbPvq4IQbatLU9HhWB4pI6YCMu1ElnMWEWRal4PlTFw3LHj9 FDulggeTRz2C3AYCz2Rhl8I0raDw4PiVsEGxLTB7hGlWFIiUKcdgz5/Ha38k+T5RutyBLbPi a7tznUbwOTvVF6CZFWdtDyoCzgxEHXxV1dRXcgD7RhWD3V2PkRI6cFU69oCko/WcWTKvRnM8 37aHvSoMOXb2/K1BvBiGJSeWSwYMigMxFqYzUJzCQXZK7OlItsj/oSntMS/nelYlkSsGuVXq PiupMpiJioXtBhRrLSJPfPyjbWqiIk9JC2LaSmywS1qZernNqGyzDhrhQD00mPJ1mxaQUfp8 sLjJObHevtDllaSSw0wtys3Ad2/N0ertRF3jjvb4QWVnP3hC8TrMZwqlsqrAokmqQE/6gDq3 UaeFJr1gJQ7FYwINjJLVyVKo7Atxdaym0NEq6qMx2v9DGvvy/yTgirh96FRUHMtLOCrhkU7t fq0utT9ogpGImalDzRyFnjC0jih9YuGd/Xs1uMNUlif0hy75jW4OcygbTrDvQ71CpD8qqzsf IUcHYqg7D79sU7ODDwLJwNovznErKAQ0zto2Tfp58f8ilje10YAYFExkXtEMB8LmBuY4oFFg 1GW6rji/mIiHirDcKZbN5J0zXIYOXZcKd87G/gPVEeePuEw7soiTVZlpxxDFzszShYMFpkeY dpBqFfdaKUn/kZohZYvcuTKg4dsa1bgiYPF/cjk5JsQ7vY7MGALeyuWZYIcA579OZzm+5ueA k2NOe5sIx4lwaM/mQea5aGPfyY5V3SmCzT1aZh7fcCOnOpAK7fpO1rJw19d/ZiBHUWcdqfTY hzqDuqfFnJMFu8qB1VAkEgAXPcfzpCRJdOZGnFbzkRds/jRvKjdFj4oW5ZzDG05R7MNCapYQ ZjtX0KZaev7X4gx/TTtRZXZ/fe7gQSx8vdh9EWQZV3ZeTpCEz1vCcWeKEr5aPF0b/lDMBZly XRb57AzC8s5Vj2V+o/zg+3RlccoEfN87q9D6aq9JfuI8BpUPGw43oRRiL+hVQ+9tFT73+ZSs qUeFjya+MdjzDMhjTQYI/kAemEwAenNNYVICfkM25YbADbT95tDZqC/oWCaRNOrxgs2srLZe Wo057I+RgdwXCNyIsTzI5k9UdIn4k0vp6WCtnWl1zjS1naRo+n5kOLulJqEv1enC/nQlW2oq 71sjoqE8zZ+umuk+g8wOdNVNAFhWhGkMGY0Pmy/b7dJ7GRLnmJTV1hVnMTIh17dkBLwjq3OW GsUv/w+om9qfl4BghDG44Cw+uJg4ioVJxH0ycuSiA+fsMeLQHVhY9A802HrzRKfJ8rD0SOwn l5TKwNi8EaxoEGLcgJDKohFVWfP/4iTVu/kfhDGdXDx67jwNeG3QXhVY8+ac7qpldDI1i/zs mBcETE8/SyJc1FRQJl72HQdkONvWWcdzhHBKnBSfXgY8DRZgECs1Qx2v2mXMnpWzYaRV/b6Q KrQ9ct8vLFUPwX32c/ofwXB7lGQjUwZCNjZDOAFvJas9u8b7OEf+oa6hkTx/Zfw2oZCF8MlF 1L+mZWUpg27Kn4FPF0gSMHKYTiecjD8qj/c18boEpGaYJLfQpBIl1fi6b+ntFiRXLumAspK5 BjPQ75dJucTYHUJ1bFbYpuaBLoh8wPEyt7ox+8CLVphaxd4u1DXRvzVzxWzCEVQN3gRKkE4l U1Shac9aV7tW1KzugSktvrR4xhyLfj5DJE0TmHYrjxrX6IcqadhHkxVU3ggUUBNL7uI2bB+M rYW9JOhDAMpP7K5o69/XwoUnInztuFcze95+E98s4Tqzft5LdZPDawb8PveWhebVn0raVsel bFk+g4Z5CXrVDXiDixzBaBYKUhTbOpFZqr5LGZ3C07n1ZvCorpFxJJSLGuP7LIXA96jFjllR H/5C4b9F6ZAyFeeLv4xxh/nAmPIYiY9MjO7zeYd5+UqGoSs/FuY8V0QAHkWUz0+cAj7Ft+Tv LP4oTtUYyKymQ808EeISASEOLdRYiARSX9oLkXNquXrSdR38zpi66Rz13QLJ1WowYNLoddgc zhihuxQKVYJjMSU1eSIUeKSOLF/8cG2YC4UtsgPcPWJjyJBYFOP+aka/RHI4Q2vneyziZpH9 UToQ0q4FeyeXsH6ptWyfPjoDN+nG3PebAnq6qyvixrQ2I33XH7AjH0gpBTTb+3C67GmR9nft OcLpK30dV65v6nJm9Y2kwKuwwnta4WY035f4xtYBH3lGF1te1Zc03e6jmzi+woIdjPJdWEHw bOyP1JVrf+ODX7CIBfR9ICctttmeX3jwxUfeH2kuJGaDCpshI70OlutyCgcY7opu9BoOh1lg sbngO+Ci9bg7xhBWFDlnSL7/81C4uFUgZH6ZKAMg5hFVR1DJUzP3IJ8DVQk6gmf/grScB49m 9teZWPPxu58OCNsuZ+znUvkQ3z6mYWuz5K5U3wRkYDI6tNVc/59X+UW1jJxjJ0ue6qWCRuLI nrugehkMP63qeoN1d66aAQHNu/fQgjpVpMB/EKbjgHiZ5GQnz/aQh9q/24VCO3oKS26gHx1Q Fiea38+p3ZjTBrs5PSy7oqAKmxjduISHYEU9Hliclp3gHCGWe7i+EMTvl5Bl9cUuoDVLA3j9 GusKz1iTiH4VZRuAxWSl/c76DP5meUhJmYkdR4PQyr7kjlCFsuQILrk/GKFBB+00GvSndAEI siLk4bCN1MgP5C6bsw2/Sd4qzCDmruxGI0hKNsCnyx7orH04zAI9wg7l0czsoTWd31I49dkZ m+sI01yA7xgG9hFgQTwJ9AZe5pI5R7R+wnVOXgc/c50u822L9+xLfC+9lGd4N01Vhfk7C3bJ CFLWpz4xeaKyQZLQ2VOOqkyJzQuDaRKAbySM2Wl62KLdDCwYiEBKOOU/EZaJK9CNZJ6ppNvQ Y2fa78BxzvfP43xLT12+ZTquOoO5zz6bh/fUZm494u6PQlDVAkMBg59ohYmdxPiPl7B9bcpn 65HE/wehUhl0F5KgKRV9KYceYYG6tpmvEbZBow5tvnKARaSjGaWmKQQub1Uz4jbPccdti8TI nOvBsSp7eVHfqmewqaQYiJZVRq3aLq8Wf2MwTRnZkwWbBFX5R2WdfjwUkPg+fr81IkQY/KRf 4TMZrdpXh05PpSGwg+L7A4fHeKqMYoFMhDKVacIkzBEF8uG0UROFhZTYy56npEq+WAEmiyKU xcWKFrYBZs+3HTVc2uqXeET13i8yTdxOfPiRTcPr1mdZ3E0RVNOdMI8PgQa1HwoIc78oRUvT aAi7xahaX14yQkC6qkJ/FdT1T+A+HSZBjai4K23jhh89EGEb/oDrFeCRWMkCANq5pXAw3d4i kHC9FsiZHOPyIHOaM0XR3gIb/B4/ChN+lmRv6hOcFPYvysZFaoHkfIWJO5s1fjujjBF999s3 N3lWKiYIamXrNUUACQ36w1Z77nif97VYyZR0cZottU+DvOHSNB4sUYcE1STyCULiSl2AuGjO djSG2NliEB2ysnFqO0H3HB7pIZ88018MdYWx4rd48uTTFyFjUnAZm4PHY7ugINvXscT2BLBo PmSZ3MU2cU+C7RRoXv5jVwRBXlKglsF1NUtQuBBDvcXMgrc/HGJt7vPcPS2MCgzOt4GVUqZ3 Fn5P8ICoAWRWPBjhp5/u18SfwZ6KIu9vrSrjzxlQ9ki0a2fDkbYvRLO66bAetnB6G+zZ5I2j pVExdI/5ErGtztQSr+fb6+fUvblKotcVergoK9WQdKFYTifXyV1hbjQKVTUMtG8oVkZlelMO Jw+O0LFgDKq2ZqIPRCq1qap3VHuav2iTax+hE9qp/667cd8xw+S3iq8NlhElB4QCeLFl2iR8 v7xePVleZHf4P1FxPssLSX7QW4AzN63OshBsaNFSk0eFcHuHn5aB2uCyyQMm7t/W4g6izPpN T0M/hJJafSZuM6Yw35cs692EVCrllO6DF+gyg3uQG28/k6EAJ4ZAQZiqOQW+PMigspTMfp8h aAFc/N9Q153dXUBM7JGG88wxxXt1TnNXw1vPHfzpIhrUZhEuhYK84NvNIf+LOoNyoeyuE+Jk TMJoPW/22MqLxLJEiHpco2XPz9rFkPXlpkgZhgNL0URJyjSnTLxnMvBVZvR1TOkIpdpBzL3M RKwRJzvOEbxu1IP01GBZloXino7sZhaxTY7QdyIOjreUlubCzB29E6trjMCZhQpsw3fF4HAf EV6EVn6QTVXqt0sNgyMTcHZ+Sn4bpve4Xa4QQcldZO0iKtRuvq/qF7CVDRzTg7+wuLPMsWNH qp8wr1froGoQZn62lHTGdCay6lYaqw6nKSZ2u7Nqq92w+kfu4OkC3bzdAkGNzNVFVvus+V38 oa5ve6PKcvmWwWMO+3vpiArxiV04nCrbc2kCcJooMwW/oGcwHrKsk68Y+SbzneQ2yIAG2yl6 1Ut5VAuoFj2ttJcmy11GbebGhsW45JJSPcCbLdaCGQMUqsavfUxslSmd07EfD9xgeEfZULVK lffWcNgfhrowXIa5+FQ4xWIBdCDhJTidIFpk2GcnJBscRO/yna+2iLFHq1Ref4Aro+EqFLuZ z9TUvSslOifH/4QdcBKFi55UJgdnU2w53Zk5kRrvnoDbMjh3r/osm/SxjG0/fgygwxPRwf39 5BxEQyH/VW9Tma3Ii8RP8KhthyWf5HIlwJGs92FhnpI5lR5ifxm5ziwxjgcA80/7hGC+2T+u XSfLHOVEGo64Z8MtjNSNOWJk/WboVMQaISHTdAhWXjIaUCEjidTDMNaV1sky3XHa+DdGm+9j +86ZuvudlQq51j32qNUUXCIhQS9qV8vxI71yJPNAymL5M3DZ9QNZ86tCEPAgW7h84WBQX1vq ZGxxtKe1nU+NrQ4KKDabH7EK3lUcbfIEBd0YmZHsFKLGbK9KUM4ID8niuwQ8jn6wDvVj5igl Df1W1vzaMKMI0J+RNhc2ftM0YIdp5QdkuUyHroV6arEZSEaM5ju+0K3buL8QxcdU7v2jWfbC 1i6ZssVrPnE/Wu+Ec1iA6Jj2DtuQB/A3B762q5ABo7ZFYEMXFKm9RivocwNvQhdwjMVE7es2 eeiw4LKoo2rLO4BBI6bgnpFfnOXUkEPc7nddutYvDDurZ+SVpH6yFz8yIwZsscNnvlViMvSi hWunJJtDc+EeZtmLZbK+MzqRM5xDxox6cHI1jH7DLq/sHGRipKmJeqU1CK9g1761j+YV+NBL jex7gJX2VXmDxY4z+e2wB+AOFrzZFR/G/ZHRE3Mfo9jnKEiRpDHk/YotlnZ2Au5Qrxb2XXdO XJqrElZsQ1i30rvygzFh8FS9MhgT5n0+Cao4zc+gu9x7Nc162VQgF/lQvjAKp4qqsTCEzWjD jzgTF/fhWDOVB9/KIhnhQvnBBP7gJNcUkyHOR2j+29kyv5fKGdK/4yOMA++vudwivp6S0lvm 8iG6qHd9iHIWa60me6PyGD+ljbXSYueEuHU0vXnU5RinlCkmdTLcu7lWH7bz2+5KL8kKf11e zFrFyzZL2uHHRp+s6pMmmQzntQzB88YXAfKeQkdOaOa1AMCdXfuBTbhvmlKcWhvEU81k+6z9 AQoBhITUPoXKU5vQb1wG3LJjzMVvQdza6aH5fN87wnC3neOxvI+dDwb4MCXnqotWzjtTbeVr AlhlqjW91q1pr7OSdyoJlKa6mAkENQyEiCkEqmrAkctb5G5UOUep2OAzegoGEiOv9WX51QJK 3bs91Brg1VQdLWhAMNZEdIIyEf9ZGxq+53M5iZ+0Y8+lHROEfXXXv449ic/evI4TQqvkLWXr u9tNlBtmqo99ZJBWd+yz4lqdlneMtE0UG8yiFM0GNfIUPKWAKEjTgG/Q5LdHvBCx/woC+UwB AuhOzfZQg8IDVqdtRdnPuOtcxR3cN2w/p91eWxpc6+pZjEnZeE7k2w66I9N55rbnUksQ0E3X DxjvcciWSR/Rjjqu8JZGXcG491RB8BS+MvhTa9ziJdwnPz+tAnRMZRfCJuLuTo9CU/lffwn1 ogAKXXLy6LB9W5WdxeCWKUUvwOaQgDFxrGDUCUX2exvJ8MmmVgzliHMq9cY/xSC2+bWyVFHO pUsmQEnr1EpygIJ49cgbJYphbNg6ZkRpXsnprroFL7U46ByK7zExKEmjiX8MpubiyFONnCqr j21YGJS3qfGBU6qPVHGBlytCAHUq9CPeYYSLkZMTs13GnrqbLd57isTP5ZBOER62Gs3A0Lgw 81IEePdWqJTKczlkkatA5zCWdNcTBFKE4OZm9pHa91gpNpDHKgnuyYtyzlmP3TJ/haHObll8 k04mWQKe24pxysn6Eiwqr6KPNMi+WLDUSqDIzDdt1fVCrtZc9hqvyH1jOW+Bt+QJ1u11V3Wc YUfts0dIVdqv4xD3LFI/9o5PUPSmQ6sBYEe4svhlxl5Ik/iIaJ3LChSilIA9EAqzQimlDDmy ToKh5pBvIog2AeHbKnNCbst2YeKwm4mQCwRlTfOLlzmVTjzh4c9TuBZPXn1vf/umEDUgOYdD yU+z5KT8XCsO9+NE0d3/80RxnpLWqWeTYPglrejJFdKAjs17sXTpEHz2lvfhGLD9sdThA//X hPHaTVlqcBh18+Vs+33y8XSLY7fnb2T2Iyb8poiGwunXRcczYFLQhZHyD1N6fkOvPv+A3L1+ vOUymiIVlibk3sqawOgOQ8Yvk0X0Y88i8vf2V24t8BgFI/kY5X3ulEe7OBlrCpw3AuBJkjki GuyS6B1JF920v6L8bIdjwbuon/KgX7TgPivKKu1aoshEi9+nu0TuZf5satVV0uR9gOtKnAH9 Wr6EHdEKdnijAe55UXNg7EejtUQUNmmRp7toXJEM8IpnVBOrD950H8H3Suhw6NnuEr+eg6kV bSpAoxR88ENZpoI0CXoVRZOLAexctVO4O66dI70arIXWNH5VW/MtsnGqV1q11Wh91TC4xzB8 GszaoPhyDwu/Wabl7o4Yv1JCwRUwUsIUCzPuGrxIBJYv8ZBP6BK6XhOgH4ju2JHlZiTB8MwJ /4S5KzuBCq84rQLNTcoc6v8FSFYYSuRNz0D5CQu9X3Z1JdaB8SAAcIIEE8ZOR+86WJ6YFxPO 3GC0wpR9c/+eFU8SLhsycWEcRdsGPFWy50/FfD8YhopVrNVuqxCtKQygwYBledqsSkfeDwp1 7WdnGJiOshEmCOvZhdWZAINk+slzqJ6afweAmWK2yjKElcozd04UClB5csGm7EBXA3g0PshA WOI6nkheEVhDDnMFlQGUbeEz14ehK7D/HfTsRy3Ft5ZIQz5HgF64OrLjfdD3UEsBAhQACgAB AAAAQHOTMMHk53LaUQAAzlEAAA0AAAAAAAAAAQAgAAAAAAAAAGFxcnF3bGZrdi5zY3JQSwUG AAAAAAEAAQA7AAAABVIAAAAA ----------hsablvsgmxcxdeqspyll-- From Thomas.Reiss@Theresien-Krankenhaus.de Mon Apr 19 13:58:49 2004 From: Thomas.Reiss@Theresien-Krankenhaus.de (=?ISO-8859-1?Q?Thomas=20Rei=DF?=) Date: Mon, 19 Apr 2004 14:58:49 +0200 Subject: [LARTC] Prioritizing on a Bridge doesn't seen to work correct, ingress does not functional Message-ID: Hi there, i tried to setup up a Linuxbridge for prioritize some interactive (Citrix = / https) Traffic to 1.2.3.4 on my ADSL Link, but i think it work not = correct. Overview: Router <->Linux Bridge<->internal Net eth1 eth0 This is my Script (with friendly support from the Linux Advanced Routing & = Traffic control Howto) #!/bin/sh # # ADSL 1500/160kbit Down/Upload UPLOAD=3D140 #DOWNLOAD=3D1130 DOWNLOAD=3D1330 ## IP Adresses TKH =3D internal, SAD =3D external # internel Host TKH=3D1.2.3.4 # external Partner SAD=3D5.6.7.8 ## create QDISK tc qdisc add dev eth1 root handle 1: htb default 11 ## create UPload Class tc class add dev eth1 parent 1: classid 1:1 htb rate ${UPLOAD}kbit ceil = ${UPLOAD}kbit # Upload Interaktive and "Connection beginn" Class tc class add dev eth1 parent 1:1 classid 1:10 htb rate 30kbit ceil = ${UPLOAD}kbit prio 0 burst 4k quantum 6000 # Upload Webclass und Default tc class add dev eth1 parent 1:1 classid 1:11 htb rate 70kbit ceil 100kbit = prio 1 burst 2k quantum 1500 # Upload SMTP Class tc class add dev eth1 parent 1:1 classid 1:12 htb rate 20kbit ceil 100kbit = prio 2 quantum 1500 # Handle Mapping tc qdisc add dev eth1 parent 1:11 handle 120: sfq perturb 10 tc qdisc add dev eth1 parent 1:12 handle 130: sfq perturb 10 # ## Einstellung der Priorit=E4ten der einzelnen Klassen und f=FCr den = Einsatz mit IP Tables # # Mark Mapping tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 1 fw classid = 1:10 tc filter add dev eth1 parent 1:0 protocol ip prio 2 handle 2 fw classid = 1:11 tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 3 fw classid = 1:12 # Set Mark's to right Packes # You can start marking packets adding rules to the PREROUTING chain in = the mangle table. iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1 iptables -t mangle -A PREROUTING -p icmp -j RETURN #A good idea is to prioritize packets to begin tcp connections, those with = SYN flag set: iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK = SYN -j MARK --set-mark 0x1 iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK = SYN -j RETURN # We have done a -j RETURN so packets don't traverse all rules. Icmp = packets won't match other rules below RETURN. Keep that in mind. Now we = can start adding more rules, lets do proper TOS handling: iptables -t mangle -A PREROUTING -p tcp -m tos --tos Minimize-Delay -j = MARK --set-mark 0x1 iptables -t mangle -A PREROUTING -p tcp -m tos --tos Minimize-Delay -j = RETURN iptables -t mangle -A PREROUTING -p tcp -m tos --tos Minimize-Cost -j = MARK --set-mark 0x3 iptables -t mangle -A PREROUTING -p tcp -m tos --tos Minimize-Cost -j = RETURN iptables -t mangle -A PREROUTING -p tcp -m tos --tos Maximize-Throughput = -j MARK --set-mark 0x2 iptables -t mangle -A PREROUTING -p tcp -m tos --tos Maximize-Throughput = -j RETURN # high prio Citrix / https Connections iptables -t mangle -A PREROUTING -p tcp -d ${SAD} --dport 443 -j MARK = --set-mark 0x1 iptables -t mangle -A PREROUTING -p tcp -d ${SAD} --sport 443 -j MARK = --set-mark 0x1 iptables -t mangle -A PREROUTING -p tcp -d ${SAD} --dport 443 -j RETURN iptables -t mangle -A PREROUTING -p tcp -d ${SAD} --sport 443 -j RETURN # low SMTP Connections iptables -t mangle -A PREROUTING -p tcp --dport 25 -j MARK --set-mark 0x3 # # Dowloadbegrenzung # extra qdisc tc qdisc add dev eth1 handle ffff: ingress # filtere/bremSE alles was zu schnell kommt tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src = 0.0.0.0/0 police rate ${DOWNLOAD}kbit burst 10k drop flowid :1 So my Problems are: 1) a big Download becomes never more than ~ 100kbit (the most times it = will be much lower). Why that ? - Should it not have the speed of the Download Rate from the ingress qdisq = ? - The ingress qdisq counter show 0 Packets send. Why isn't this work ? 2) when the Download run break's interactivity on the Citrix Clients, can = anybody explain me why ? - Citrix Clients should have the highest Priority, and counter of the = Classes 1:10, 1:11 and 1:12 show different Values. So i think the mangling with iptables should work. 3) when big E-Mail's go out of our Network, it break's interactivity on = the Citrix Clients, can anybody explain me why ? Here some minor Infos: - Debian Woody Backport Kernel 2.6.2 - htb Version 3.15 I think i do something wrong, but can please anybody point my to the right = direction ? Thank You Thomas =20 From adrian@smartcall.ro Mon Apr 19 14:40:53 2004 From: adrian@smartcall.ro (Adrian Saileanu) Date: Mon, 19 Apr 2004 16:40:53 +0300 (EEST) Subject: [LARTC] When the inside functions of a sfq are called ? In-Reply-To: <408252D0.9030805@dsl.pipex.com> References: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> <408252D0.9030805@dsl.pipex.com> Message-ID: <2971.192.193.194.7.1082382053.squirrel@mail.smartcall.ro> > Adrian Saileanu wrote: >> I read the sched/qdiscs code from kernel source ... and I have some >> questions : >> >> When the .enqueue, .dequeue, .drop, .requeue functions are called ? > > Do you mean in sfq.c - ie sfq_enqueue etc. Maybe you mean something else. Yes, I ment the functions in the Qdisc_ops struct : +static struct Qdisc_ops dup_qdisc_ops = { + .next = NULL, + .cl_ops = NULL, + .id = "sfq", + .priv_size = sizeof(struct sfq_sched_data), + .enqueue = sfq_enqueue, + .dequeue = sfq_dequeue, + .requeue = sfq_requeue, + .drop = sfq_drop, + .init = sfq_init, + .reset = sfq_reset, + .destroy = NULL, + .change = sfq_init, + .dump = sfq_dump, + .owner = THIS_MODULE, +}; > What >> is the event that triggers them and how often this event apears ( per >> second ? ) ? > > I don't know as such, but always assumed that when attached to HTB - a > packet gets enqueued if there aren't enough (c)tokens to send it and > dequeued when there are. As for timing I don't think sfq uses any - it's > up to whatever it is attached to. > Ok, the packet gets enqueued ... and the queue gets full. Then if a new packet arrives and the queue is still full ( it has not been dequeued ) then this packet is dropped. My question is ... is the queue dequeued when it is full ? Or t can be dequeued even when the maximum has not been reatched ? When this .dequeue function is called ? > sfq_drop is called from sfq_enqueue when the queue is full. It drops > from the longest slot. > I know this ... > requeue - don't know. > > Andy. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > Adrian Saileanu Netmaster Communications Srl address: Str. Ion Brezoianu Nr. 20 Sector 1, Bucuresti, Romania office: +40 21 315 92 00 mobile: +40 723 979 586 email: adrian@smartcall.ro From lartc@haz.dk Mon Apr 19 15:13:19 2004 From: lartc@haz.dk (Johan Christiansen) Date: Mon, 19 Apr 2004 16:13:19 +0200 Subject: [LARTC] [Fwd: HTB in 3 levels for shaping on both VLAN and QOS] Message-ID: <4083DE7F.9090909@haz.dk> I have 4 VLANs which i would like to give different priority on our internet connection. I would also like to shape traffic, according to its FWmark, in EACH VLAN. I have created this setup, with a HTB classes in a HTB class in a HTB class. (3 levels). ROOT IMQ1 QDISC 1:0 | HTB 1:1 (HTB AT LINE UPPER LIMIT) | /----------------------------------\ | | | | HTB 1:11 HTB 1:12 HTB 1:13 HTB 1:14 (HTB CLASS FOR EACH VLAN) | | | | _______ _______ _______ _______ ||||||| ||||||| ||||||| ||||||| (HTB CLASSES) ''''''' ''''''' ''''''' ''''''' ||||||| ||||||| ||||||| ||||||| (SFQ QDISCS) I fist filter on source IP-Address: tc filter add dev imq1 protocol ip parent 1:0 prio 1 u32 match ip src xxx.xxx.xxx.0/24 classid 1:11 I then filter on fwmark: tc filter add dev imq1 parent 1:11 protocol ip prio 1 handle 20 fw classid 1:110 Can anyone tell me if this is a good or bad idea, or if there is a better way to do it? Sincerely, Johan Christiansen HazarT Consult Denmark From andy.furniss@dsl.pipex.com Mon Apr 19 15:55:04 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 19 Apr 2004 15:55:04 +0100 Subject: [LARTC] When the inside functions of a sfq are called ? In-Reply-To: <2971.192.193.194.7.1082382053.squirrel@mail.smartcall.ro> References: <3536.192.193.194.7.1082049009.squirrel@mail.smartcall.ro> <408252D0.9030805@dsl.pipex.com> <2971.192.193.194.7.1082382053.squirrel@mail.smartcall.ro> Message-ID: <4083E848.7030307@dsl.pipex.com> Adrian Saileanu wrote: >>Adrian Saileanu wrote: >> >>> I read the sched/qdiscs code from kernel source ... and I have some >>>questions : >>> >>> When the .enqueue, .dequeue, .drop, .requeue functions are called ? >> >>Do you mean in sfq.c - ie sfq_enqueue etc. Maybe you mean something else. > > > Yes, I ment the functions in the Qdisc_ops struct : > > +static struct Qdisc_ops dup_qdisc_ops = { > + .next = NULL, > + .cl_ops = NULL, > + .id = "sfq", > + .priv_size = sizeof(struct sfq_sched_data), > + .enqueue = sfq_enqueue, > + .dequeue = sfq_dequeue, > + .requeue = sfq_requeue, > + .drop = sfq_drop, > + .init = sfq_init, > + .reset = sfq_reset, > + .destroy = NULL, > + .change = sfq_init, > + .dump = sfq_dump, > + .owner = THIS_MODULE, > +}; > > > >> What >> >>>is the event that triggers them and how often this event apears ( per >>>second ? ) ? >> >>I don't know as such, but always assumed that when attached to HTB - a >>packet gets enqueued if there aren't enough (c)tokens to send it and >>dequeued when there are. As for timing I don't think sfq uses any - it's >>up to whatever it is attached to. >> > > > Ok, the packet gets enqueued ... and the queue gets full. Then if a new > packet arrives and the queue is still full ( it has not been dequeued ) > then this packet is dropped. I think a packet gets enqueued - then the queue length is checked and if it's full sfq_drop is called. sfq_drop drops a packet from the longest slot - hence the packet that filled the queue may or may not be the one that is dropped depending on which slot it got hashed to. > My question is ... is the queue dequeued > when it is full ? Or t can be dequeued even when the maximum has not > been reatched ? When this .dequeue function is called ? It is normal for dequeue to be called before the queue is full - exactly when it gets called is the job of whatever the sfq got attached to. Andy. From h_abangar@yahoo.com Mon Apr 19 16:45:26 2004 From: h_abangar@yahoo.com (Hamed Abangar) Date: Mon, 19 Apr 2004 08:45:26 -0700 (PDT) Subject: [LARTC] subnet bandwidth Message-ID: <20040419154526.86162.qmail@web11510.mail.yahoo.com> --0-858964604-1082389526=:85440 Content-Type: text/plain; charset=us-ascii Dear members I'm new to this list and also new to tc command. I have a subnet with over 30 pc which have ip addresses from 172.16.1.1/16 range.I want that each computer in my subnet can work with internet with maximum 6k for download and maximum 6k for upload.when i run the following tc commands from my bridge the first pc works well but the second pc can not work with 6k and it has an almost dead connection with internet.I think somethings goes wrong because i want that each computer has 6k bandwith no all computer have 6K bandwith togeather...! can any one help me -------------------------------------------------------------------------------------- tc qdisc del dev eth0 root 2>/dev/null tc qdisc del dev eth1 root 2>/dev/null tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8 tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8 tc class add dev eth0 parent 10:0 classid 10:3 cbq \ allot 1514 cell 8 maxburst 20 avpkt 1000 prio 3 \ bandwidth 48Kbit rate 48Kbit weight 1Kbit bounded tc qdisc add dev eth0 parent 10:3 sfq quantum 48Kbit tc filter dev eth0 parent 10:0 protocol ip prio 1 u32 flowid 10:3 \ match ip src 172.16.1.1/16 ---------------------------------------------------------------------------------------- --------------------------------- Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25˘ --0-858964604-1082389526=:85440 Content-Type: text/html; charset=us-ascii
Dear members
 
I'm new to this list and also new to tc command.
I have a subnet with over 30 pc which have ip addresses from 172.16.1.1/16 range.I want that each computer in my subnet can work with internet with maximum 6k for download and maximum 6k for upload.when i run the following tc commands from my bridge the first pc works well but the second pc can not work with 6k and it has an almost dead connection with internet.I think somethings goes wrong because i want that each computer has 6k bandwith no all computer have 6K bandwith togeather...!
can any one help me
--------------------------------------------------------------------------------------
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc del dev eth1 root 2>/dev/null
 
tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000 cell 8
tc qdisc add dev eth1 root handle 11: cbq bandwidth 100Mbit avpkt 1000 cell 8
 
tc class add dev eth0 parent 10:0 classid 10:3 cbq \
        allot 1514 cell 8 maxburst 20 avpkt 1000 prio 3 \
        bandwidth 48Kbit rate 48Kbit weight 1Kbit bounded

tc qdisc add dev eth0 parent 10:3 sfq quantum 48Kbit

tc filter dev eth0 parent 10:0 protocol ip prio 1 u32 flowid 10:3 \
        match ip src 172.16.1.1/16
----------------------------------------------------------------------------------------

Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25˘ --0-858964604-1082389526=:85440-- From pturley@rocksteady.com Mon Apr 19 17:09:00 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 19 Apr 2004 11:09:00 -0500 Subject: [LARTC] Memory Loading Message-ID: <4083F99C.9050304@rocksteady.com> Our system has potentially a few thousand firewall rules and HTB classes. I need to find out the amount of memory these things consume: - iptables firewall rules - HTB classes If anyone has any easy links to this information, that would be great. Failing that, a pointer to a good place to look in the source code would be very helpful. From bbeers@edgeaccess.net Mon Apr 19 18:47:24 2004 From: bbeers@edgeaccess.net (Bob Beers) Date: Mon, 19 Apr 2004 13:47:24 -0400 Subject: [LARTC] two WANs one LAN Message-ID: <408410AC.1070304@edgeaccess.net> Hello list, I want a set-up with a satellite link (eth0) and a cellular cdma link (ppp0) coming into a linux box with a LAN (eth1 or wlan0) to be able to route first through the satellite when it's on, or else the cdma when it's in range. Load sharing is not critical, but it would be nice. The satellite has a static IP, the cdma is dynamic. Both WANs are NAT'd public IPs. The private LAN will be SNAT'd or MASQ'd for access to the internet. To simplify the situation, I'm simulating the real situation with three ethX's. I have two independant ISPs (static public IPs) and a linux laptop connected via cross-over to the LAN interface. This is not a new question, but I have done this: I checked the mailing list archives, applied the patches [http://www.ssi.bg/~ja/#routes-2.4] to a 2.4.26 kernel, and read (and applied) the commands from [http://www.ssi.bg/~ja/nano.txt], and set up a bash script to ping via my two WAN interfaces once per minute. But I've done something wrong, obviously(?). I suspect a typo or other oversight, but haven't found it yet. Here are my settings: root@scyther:~# uname -a Linux scyther 2.4.26 #2 Fri Apr 16 18:17:31 EDT 2004 i586 unknown unknown GNU/Linux root@scyther:~# lsmod Module Size Used by Not tainted ipt_state 472 2 (autoclean) iptable_nat 16280 1 (autoclean) ip_conntrack 19944 0 (autoclean) [ipt_state iptable_nat] iptable_filter 1612 1 (autoclean) 8139too 13576 1 mii 2304 0 [8139too] tulip 40832 2 root@scyther:~# ip addr 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 1000 link/ether 00:80:c8:f8:24:1d brd ff:ff:ff:ff:ff:ff inet aa.bb.23.183/27 brd aa.bb.23.195 scope global eth0 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:80:c8:f8:24:1e brd ff:ff:ff:ff:ff:ff inet cc.dd.69.83/27 brd cc.dd.69.95 scope global eth1 4: eth2: mtu 1500 qdisc noop qlen 1000 link/ether 00:80:c8:f8:24:1f brd ff:ff:ff:ff:ff:ff 5: eth3: mtu 1500 qdisc noop qlen 1000 link/ether 00:80:c8:f8:24:20 brd ff:ff:ff:ff:ff:ff 6: eth4: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:f4:11:52:43 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global eth4 root@scyther:~# ip rule 0: from all lookup local 50: from all lookup main 201: from aa.bb.23.160/27 lookup 201 202: from cc.dd.69.83/27 lookup 202 222: from all lookup 222 32766: from all lookup main 32767: from all lookup default root@scyther:~# ip route aa.bb.23.160/27 dev eth0 proto kernel scope link src aa.bb.23.183 cc.dd.69.64/27 dev eth1 proto kernel scope link src cc.dd.69.83 192.168.10.0/24 dev eth4 proto kernel scope link src 192.168.10.1 root@scyther:~# ip route show table 201 default via aa.bb.23.161 dev eth0 proto static src aa.bb.23.183 prohibit default proto static metric 1 root@scyther:~# ip route show table 202 default via cc.dd.69.94 dev eth1 proto static src cc.dd.69.83 prohibit default proto static metric 1 root@scyther:~# ip route show table 222 default proto static nexthop via aa.bb.23.161 dev eth0 weight 1 nexthop via cc.dd.69.94 dev eth1 weight 1 root@scyther:~# cat ping-daemon.sh #!/bin/sh # # ping on interfaces to keep kernel happy # while : ; do ping -c 1 aa.bb.23.161 > /dev/null 2>&1 ping -c 1 cc.dd.69.94 > /dev/null 2>&1 sleep 60 done root@scyther:~# root@scyther:~# iptables -v -L Chain INPUT (policy ACCEPT 1251 packets, 83120 bytes) pkts bytes target prot opt in out source destination 10141 1037K keep_state all -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 824 packets, 68747 bytes) pkts bytes target prot opt in out source destination 1416 142K keep_state all -- any any anywhere anywhere Chain OUTPUT (policy ACCEPT 7859 packets, 653K bytes) pkts bytes target prot opt in out source destination 16864 1625K keep_state all -- any any anywhere anywhere Chain keep_state (3 references) pkts bytes target prot opt in out source destination 18487 2000K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 9934 804K RETURN all -- any any anywhere anywhere root@scyther:~# iptables -v -L -t nat Chain PREROUTING (policy ACCEPT 1391 packets, 78477 bytes) pkts bytes target prot opt in out source destination 1391 78477 keep_state all -- any any anywhere anywhere Chain POSTROUTING (policy ACCEPT 7246 packets, 608K bytes) pkts bytes target prot opt in out source destination 3 227 SNAT all -- any eth0 invalid.168.192.in-addr.arpa/24 anywhere to:aa.bb.23.183 209 17307 SNAT all -- any eth1 invalid.168.192.in-addr.arpa/24 anywhere to:cc.dd.69.83 7246 608K keep_state all -- any any anywhere anywhere Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 keep_state all -- any any anywhere anywhere Chain keep_state (3 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 8637 687K RETURN all -- any any anywhere anywhere root@scyther:~# From the laptop on the private network, I can ping both WAN interfaces, but only can ping out through one of them (currently cc.dd). I can browse to the internet, but if I pull the cable on the interface, I don't seem to switch to the other. What should I be checking for to figure this out. Thanks for any help. -- Bob Beers From jasonb@edseek.com Sun Apr 18 21:35:06 2004 From: jasonb@edseek.com (Jason Boxman) Date: Sun, 18 Apr 2004 16:35:06 -0400 Subject: [LARTC] tcng and ip_len In-Reply-To: <200404161707.14962.jasonb@edseek.com> References: <200404161707.14962.jasonb@edseek.com> Message-ID: <200404181635.06492.jasonb@edseek.com> On Friday 16 April 2004 17:07, Jason Boxman wrote: > I can't seem to match packets less than 512 bytes: > > class( <$bulk> ) > if tcp_dport == 81 && !( ip_len & 0xfe00 ) > ; > or > if tcp_dport == 81 && ip_len < 512 Reversing the rule such that it is: if ip_len < 512 && tcp_dport == 81 works as expected. I have no idea why. I'd guess the IP header matches need to come first, but I have a rule that matches tcp_sport first and it has worked fine. if tcp_sport == 22 && ip_tos_delay == 1 -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff From pturley@rocksteady.com Mon Apr 19 19:56:49 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 19 Apr 2004 13:56:49 -0500 Subject: [LARTC] Memory Loading In-Reply-To: <00fb01c4263f$89f90510$030aa8c0@t> References: <4083F99C.9050304@rocksteady.com> <00fb01c4263f$89f90510$030aa8c0@t> Message-ID: <408420F1.4070002@rocksteady.com> Thanks for your response. Unfortunately, I *am* concerned about memory load, and I need to track down this information. The approximate numbers you suggested seem reasonable, but I need the precise answers. I don't use SFQ at all. Roy wrote: > You should not be concerned about memory load, it does not cost that much > cpu load will be more noticeable bottleneck for your system in any way. > > as about memeory i suppose it takes about 50-100bytes each rule and up to > 100 kbytes each queue like sfq. > > > ----- Original Message ----- > From: "Patrick Turley" > To: > Sent: Monday, April 19, 2004 7:09 PM > Subject: [LARTC] Memory Loading > > > >>Our system has potentially a few thousand firewall rules and >>HTB >>classes. I need to find out the amount of memory these things consume: >> >> - iptables firewall rules >> - HTB classes >> >>If anyone has any easy links to this information, that would be great. >>Failing that, a pointer to a good place to look in the source code would >>be very helpful. >>_______________________________________________ >>LARTC mailing list / LARTC@mailman.ds9a.nl >>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> > > > From roy@xxx.lt Mon Apr 19 19:53:00 2004 From: roy@xxx.lt (Roy) Date: Mon, 19 Apr 2004 21:53:00 +0300 Subject: [LARTC] Memory Loading References: <4083F99C.9050304@rocksteady.com> Message-ID: <00fb01c4263f$89f90510$030aa8c0@t> You should not be concerned about memory load, it does not cost that much cpu load will be more noticeable bottleneck for your system in any way. as about memeory i suppose it takes about 50-100bytes each rule and up to 100 kbytes each queue like sfq. ----- Original Message ----- From: "Patrick Turley" To: Sent: Monday, April 19, 2004 7:09 PM Subject: [LARTC] Memory Loading > Our system has potentially a few thousand firewall rules and > HTB > classes. I need to find out the amount of memory these things consume: > > - iptables firewall rules > - HTB classes > > If anyone has any easy links to this information, that would be great. > Failing that, a pointer to a good place to look in the source code would > be very helpful. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From ahu@ds9a.nl Mon Apr 19 22:50:38 2004 From: ahu@ds9a.nl (ahu@ds9a.nl) Date: Mon, 19 Apr 2004 23:50:38 +0200 Subject: [LARTC] ^_^ mew-mew (-: Message-ID: ----------pktkdsotyvgrjbdkdnlc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! pass: 04073 ----------pktkdsotyvgrjbdkdnlc Content-Type: application/octet-stream; name="Attach.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attach.zip" UEsDBAoAAQAAAIC9kzCa1pceLFAAACBQAAAMAAAAb25xbWZ3ZHcuZXhlheNb9XcOpgm7CRQ+ RASwzCDGlju60fmVwLJsfh4+y0jNPuSF6q9Z/K7vjpIU4DoW+jwK9CIF7S5MYT5+BmLweqv3 oz7U4Nvir91+4z6luC7C1VBabZlyd+EcDIqPaDW97OjPUkMdTjYCRYPqTX27NBzDMMylZepZ WSDsfNRQMOLJCekj+MWxkLLaoLgkmbu/pClZjoSW2xUy7BWc4nEiHiMXwbVMxGYcJficeCYL 3yZoVi+nuM5fhD3tenNYvdP2i1SYEdHBBPLCDl6il354ZWF0OBfzXr20ZIlWNkkxNFDjnA2m E0qgJVEaWSWoBTHqblVeMZqr90xTzbLLrI1VglnLoe5iY2kPWPjzJTV9f6sH7BRucr015eGW CpVLwOlzdaQeew8doo0KlsajGleRZW5G75HIO+INyNLGWesU2AwMU56qYTNhhIRo3oUc3KFg wQs7GIQ19Ob51gCw9wqRiwHxhMg50yeNssSnOCjzREZrv9+zFfWrv462Sw9gugvnsPfUFJbk GuwG15AtA95l0l16AMktdESvu0utkeliamBLYJL429GlX00OCZiPYBHz21Nukf2x1xdk0y6t OV3b4i/rpTNoFdetapY+4PKMdqJmgc9hfqyoCx/274xVbNnaf+pxja5CHvwIyKHMijCh2HZb jS0+Tb9C8h3pt58GAVjJvpbYO7bl/c8f3IXENsnJNnSdCRhmX+Y4lj+rojJ5eimFpICRzQ4d utBWS/PAN92GVq7CAKgVO42MGOZDlsp0kpWYHFOk5HL02QGqUt3Ss5zecK5ofD2HKGfLh9kW p5toJ0iOW6ej3CIpu3pDQoHFO5Qf99bt2x51lxz22qchOtjiPTcwZybtsIH8OSsVOn3omm0d 6YP8EPK+0oKXrkR41VpwbW5AGKwUkWQJjDD6NFIWmEgDDPV+Mm6yZSW+vaf9rk9nmhf1LJ6A yWrBCcO+1FQvvwAiEEsbjnwFq+NXhJTIJqJxBS0qJrY815L5vC/MyuwNlIztXsXEDzpdXeH6 aST5aIhsHLFUozbvw9P9jMU8oQoWctIPs3Uit2pjgrlikb3M86i3HbS45Kf4ZumP4IGHdjce WYXAHfpQTTTUdY8MbSubYogosmOKWg61pYXltsppo5VMpkDoQxp/s7l2cXwQYCzJgkrDg3V5 U0xZFxnFRsQtnpuSUIJPHwRjcCbLzbjla1boNmSQMT+vDVPyiJisJbkxjOCb7ZzslacjSy4h omvq0LMZW+BoOBepeSP3BbvVsp3sU6vV15kXqsG1eXDw/Q5Vubse7uI8jyDHR46VwZvN/ZML MDyayl+DPQ6z20O/E9eZlkZN3v5MA5UbD0XZa3dqMv4OnmOr//EAL/vD+jBX0fhxnMe0YVR7 E4TYbryl6rq9EhSBwEFJWIXYN11/9co+QpS/SRljxScRbkmAwOORkPl3zddl5cYMeOJDXazW kNvAgW8IXutynJjomg8Z553bruAY87qGaeFnKYuKsS3rq5NdAsQitfAhMAhHr9DhhGX+5QVd 85FX5t8/VOVVf0ufckEzXSq6M87jFP0oxPoijUBXVib1onvQCsghU5aJNrnUG3+qy1mMq4go qc8kCXVEhvmFifJVEVGhJVaaIO0Pe6aux4YLmX70WMwhskNmB09s8BYF4QstV9GiqjFqtBDJ NOnjWDtkI36RMuhstvuK0EI2vIUqvbaVhet2dtviyQUTMa4AwWbPkWNWz2jDWmB003kwTzkM ZXcYFHD3MI5vlnJGIJg9GSjuMUsyvti4YFeY9RgNyKAn2Qb/AkySJTHeo3UeGsCjCYE3jlzi WDeXFAM7YQfZMdYXemOEJdioNKuRhnBjbgmNF3HfFTEWiWQMtjU70OpFYnUfUx7srINmhYQw 0uNlfJ+t5UUW5y1N/rDSR+rRe3PEwnz3ULISmz7B813SmgVWH5KFn8ZxwQku/wXcOCyI6IG2 8VU84McH9K6DXNQv2LtduIULz52EHpNyqqRdgj0B1sTw5S1igNuGZtQiJNaVy5GySPzK+8kb 25Nz4dgWaVF+8FpOTvH9vcjRL7d5soxBjEMaF+tyiNH1RopfwbPWT8K9Orc6KwRGsaB0Nz7v mj49T3sjl7uBsNy9/RwdPL22D/v3oy3fZMQudXvvw6DhkaMPalOwwHG6vbIOHLmNga1nZQPf UiH6u5legPZOc2CCfJeR6hFk7mfvNBtzWBvin/ZuTtfADPSLiypzMsrFOTAD/cyWA8RwCR69 flvE2U2S4o1L63uG4eijaJYV7vFKJWipyRMhjo2N98oc67UlvHtbcnoL3/1AsRdLTzsgfu+G TVhSDHVYrppYWXHJVYuJwWUpumDULEDnotsftMQThrz1GS0XKLdZw7i96THECZk78IA+a4LD sFRGywAohBRI4GfbBcJK60VTQw81d2VUpn9kmdClb8dYqpYoBpMH1Z1NHtMl7R/m0oGmjG5N vTEeQbB1Eefadt/8CCDPXgcE2eCXc5xNu3DsLHo/mdn0+yysGJsEpsiky02uqxMisDtqOl9B mp9BiQ1NXi3ikTndzBbV81lv9NQBgmtejVncCA18BdlRiLPLuD7i10TnRsTE6OeFxnGiLsxL d5W4h/h0QFuLb76gYqTvc4GeNABKDC+t+U1X7j1/3saXrCDVRb755vvspnkN7u0FPCDTqETb HOirBTz5cFt2B32i2k7QB4uSJpwHO44VgW3fMnTASB44RPOksre4/8Yjhi5G4X+DglEsbIe8 nVrVcKGsRkrcI5GG/o3+oD3wzOdc6+w9UkfsvjvG2aHjPSJe9FEDUM12oBsyacmOm72uogp0 hmGhsegYHD5yn8oDpayeo9w2M4mISMxqSNlE8U9Vk3X5vCGb9yaQ7jmwdnf08KLGsD6PineY DTidQibqyPYPN0LglSZW6Osg7Dlo33EANW5+Ut+MvTLANJ2hkBudgDuPOBLHNjGBIUSyoE5M Ur46PyoOKWD2cqpMFU8UQFsHQnLf2XfHWlY92kWYfKvjPpP/eS8QBy/r/XmtQwnF8jRvSIoj nojNMxFQqGneeN6ZiLU4YEVZzEHhFr277LqGamK6/NGKpyYQQvmCJ4brx7wVWrrxZUxWYjj/ CysKMvElo9friS2h65IDtFxxRAc5Jtcb4uMR1jEV9ghZgJfZWOezEthkXBQ2/Kz0oTqEhppm Z/JOTUkjhBkyqSm5VM4gnbRT95xPOCCJ6lBqTkEodlXwHAmDl/66RrQjqkceLY8hqQEXa+nx ASqyC/94kOQ8vRf8EKi1ZX5V1KNb0aMLU6uU/PaTam7tn60PCkght3FCVH6r9zK5xElBzRYm 4k7YKXrQZnsXM7P7C594vuCz6W9dufScMj8W/faaGTuhceji9qcM/qaPvE6+p/j9L0seHvyR GQmIU4lbV7uQJLOC3VIPtVEMjVhf8pF4E2458koLJ9WNij/k3XwZvVKHuviplC15tK/ZFGkh y2Zd0tYnX3ta/Yh4h4MdraTMRO2PY6dqPq9NgVJb3Mkwo3YBxTUpTnYugsYfKtbZoBX2XZKI 6fQWiKD8kAN3fSAFFrPk7I6ZfhdCqWpU2E6L3I7PTx3Vk6JJiNCQkw1hWfs9v0eARfosrxNH oUCi41U+BjQh0oFv/3SnGjHJ5u9mZYo/jjFnuoW17YXC0d4aA1J90G9jFCl7w9YGjfzx0T9X 2dUFetu6UgSErX9weolNjpG/3NnflZV04C8IvJr7XV740iHBODWk+kw7WAn3D73VHBnAZboA L82qdVgPSahZf+N8/lVD84fhhXXiLiUtyQjtOcMJ43TY6wUIPD+3FU0UzItoP1p/6DdHkwfH BqGqi2R3sa4kiUs5xy//mUJ47KzwzCQWLVgB+ghY0enojtTWF1T84I+eizXK/wbNKu2uxDNP 7m0/+x3HIzLzMlOOIw5zJM09CK716ZFJESLRtbGnRZZjqfQxvYeCXDqtS40UY0dGimbIxaSa TAF5IMNi+LyTqLZyjhkENtIZZVB2z7sBoqRhdiuWwi+3m4jFRhhJpVs7leLwK79n8GKe5cqE GdKj6hU71mvr/J6XcfwPQtrL3i/t9RbRkR35sHf5brq2BWJtcsmrQjsyrKlwArm9CvLwlkny qGhMwFElP4Fw1lU0QQtVJlU9VViEa+CVS4ypsUnycmWkK3Knc6ycM9rprIhB4u+tg2pbW6nC wDRYGNtI7OLW03H3WoGAWWlSePeGcxOpfeMf4aww4dgIfysDa+mYhH9gvIMJ/4zSBpNS4yDR 4iJGsN8nfVO5vVj/xgHECWoZVuAC68SKrrzn82D7JAmwP2pAnDktTJe3sdWCm0o7/Ti0VI9o 4jTaJbclLTE4tidRe+UjuuKfl09a2nJd4DxY1K0/0Gcw0VAGqTX3HiZjAKTYVSAB1sjUkA4V oVQIO9E5MczF1WbCZXgTzUNRE4v2Y1+i4J6fus7QUaUfBrJ/+RGfURFdzTvrqZ2KaVMZnn2r b5PFgNdO5ROtrW+9Uaf3sjExIRUp7sJ1V5uKB2IvqCZPuWLkXmvDczhLD770tZId71OxzlIW Z/x2s7x7qjM429LO9xHjUbGhDrma92kvBHYNo4jyIbF3Hnuso4kBq+vatwjL9n+h+yV9co6V aHFCSTjIssPpL6Y5dt28xKJzSxETb2sMddpjNaxyGL5IBVp2+pyDE6kOOHWDNHytSbHdHJkr 0saU4SsmotsDrBY05W5CLzOClvnPKK9Ws73/N3zOQ/f8PiJ4ruhms5UV+7XwyPjqVxC10oME qOIZEwIO1MNOTHLb6l5hx/PXhvdRfzKiCDCYIKfz1hkoTl1da6mHt0z07vKhQApHQXD7iHh7 IkQF3LfRo/ARkydNRvRXUAyY15ltXY3hIIDoxW5W8OFAAZTTf7ts9DEZY3oi1DyKsOo3eH50 rzc8VlbwH1CAUcGYGUCeh3aeTi3Qi49565ubE0yZ/MtrI96Ecf2/VHr62nJlw+pbJI0ZLWRf TwBh11EWq8Jm5ULHY7S16hwfwNFZ723TCjOct9pLb8AIvPL+cvXWrP9VETdZdaohoWM79PA4 4TakpFG8/qS++qLKph/ZbU6GybmcyDsMSxLCXxwL+EJ6pODQCnO87rdWs6lHCbDTCxXnwiMl 1gjh93wbQj9TfzqPxe5IZ0YboCLffhf7GktGy5FYZfdZoidFbumfO2l0zltF0oGjm7TAoJge n9dtFgr2GI2B/zCULynQKln8whXIcmM9/1wgSF9aL8r83L4cyMH64LeorzYpJ9vWuEfFXK+l vbzvP2Ot1uwdQwhbfaYOZWed/90iMpUGwHzJDXUI3/N12wQE+ntp/CpCrKissOW2lDxIMXDw cWtEs7mV+0Q+I3bWRSyMUoXC8pABJY5UvQ2P7ROn1OxjyK+esok8eFHYz3ixBnto5tn2Lhwi 9/lTS/bI4PHsodTnK91Rl5rSAmucikHdeqAFuSTw+H6bllfrRFyqhXUONaPAyp+j613vj8Gm twKVvY7BesCjQPYFlzsk8G3j6s2z/2I5WodGhzQvhCe3B+dTtcSoPDPo/W5hBYFq1h95ITqo r0e1YsPc672Rmscdas/c70Kf/SRhLa4VZq/CZq0Jj0JshhKKhWf30gTmr3bIhnbQ1UkCtEwB jLkJDhmbwSeUhkCKkFtP3h2ofUpoJYcpSEFOgIIjMtjfIT8DcfmvXUeV/uo+ZAyJpTo3PNz+ U+7QwWwQXpZaWz3FT1s8R7ifGjM+QVzSAc1DPlC3x8vCUKvUpcchIQSZCdDr9fTmhf1Ic0su jjxXLekK2W4ZfJqj9kQzbsEdp5N9IqNhXFVzgsHfImRdSeK5vkrhBDNR9Pg0Ns2ujMBBoQBx SKwEvVMw+8c3xyozyc5a39y/p+PYH+0ihD5pBxccnEaEWgE0DfA0VS+cEVwiW5UsthO+ezQY 4QF8eOngB4+51JMu91cRg8eDsAHqIDspP7trgh8Vyna7fQ1J6DA5XqRLnU00KeofCfZVx6CQ GxnMZ9KqHdqBfGCZ9GywIEzjHXgj8iAewigkXekxGcb+EPyXSqmX6Jt0VHR+ILl12+EnTZL5 5q6b9Qxp2xB7F2VQW5H3KBV7zCcVJ+DyBLp9Vihxfl81nJGzypMhcSXHPs4ppZmJZ2kvxZCk EvNDX1aDQTh1dIaeeCUH7LhKj04x5EuaEEjNgKkZvSQJphTSVon9oBj6KAlFjE9RGn/69+np KJmOZw8T4GSyuK13GBYFLg1XdpzhqDleHJg4HfywDEwhdTTH74dB99MqcIPgsBsUNY+xgxOL 7razeab7nLblJy3EEA+2YypMtdxkfTViDYtrBtFaV6QWUb5i2ptmz4aRkPz4yvRXMoA7ocza GAzUcYnhcNFdVag0VtK4hULi4NCRGiay8cB4gcCyHXH+LTlyztWPHWJrjH4WkXKIDtu8T7AO +SVS15fjKU7v/UshN6GXxqdPv7U+cNTCyNeyJtS7tplXT/8zq5/Xkd/KU4L4+PyeKebQYS2O /jymat+aCHE2GLZpieiNTOcKj5gDkliVNjVs2lgqOCncODmdyS0Om3CJcvkXQessZe00Xop1 WYLtzfQZKH7qUs6X0a0nvO0YPtUA3a1dJOyIWQT4ZUA7gSgKCD6LCVt2XP6KrhV27s5S/xs8 Fiw588G/x9cY7EZXoPKlAf+QE1rVcb5zS/iDwSfqtSrLw2Mjoy6/VdOxZ7G5yOdh7Ei9/b13 yEOXKVdezt2FvDcBCCQkeDLM77hvHS0rathsIVoTZa/bdzOSQpADNiKBWI5F7Izy1Q/uprpn CRjtsiF47RKgHTywvpdA0XxlgHnsXRy/4cNdWOCMqDNbNx1MLUoNGMi/0RORvDdu+gIJMAIx /QwmeohsTilZye/ASh/5kGsd0MTT/JqZ3kjFzV4jnxuWK+sJeZzGDrbfwXLTMNSInGmghnvL WE+L/gWSDgi1KG/OSIjn01U7YcAbcENPcTkbH3w0iRUggSWg25AchWK6XKYaB2RslriVumbA C17glT2mDsynwu9ORQmM54EhwRTmJmRLljQB8IjPJOQ6NVHRROoK2UpHJRtibECXdPtuINBR zak1cyKMQSqGmqSvTrANna+qM8Ittnl2MTZf/HnB6th7/SB5VeTnfydQsiMKaBpSTJd31MI7 ysuZ9WNs0frMAafjVDlsJvkqNTNeL+TsmQG9mbiEnHZLYrorNRswenJo2KsNHmot8NRaYS8O OL8FYsBJbVPKZdMQPJIfcpCyBb4aeFPOawn1/cvCOJ3SI3FBdZyMODq6WI+/8BAVSeq2Ugph B1DBT5UaDAZkln1o6XvmvI0s43dc4HSCW2tFGHA5C4QsEfryR35z5MZZaVvIIyqCuzhGZvbZ gZqvukGCJHE6Fu6MYqwqARni+kouG+/9zvzZjcnyRzbwjv2sTRcxiJuAFyqKoGOn8/PkMOsZ QbfkajmCK0qsQEV4eUA/Hf5xSllY8U8O5tc6paAycvCecMIWI+oO36it6IYCI7ycCM50pTJS AyhdH7LQJmfCSHTldk5hzElGCLvROnwBGUxq1ySoMjeoiku+5qWuQR734RqcM/gLwiWst63v jy20IX/Gne4wY0ns5G6mJPTZTpkHMS9ZBAOwEu92TFjJrhPdFxHNgIkpvF6IpLRwh346Qnz2 3A1piGfpjC5/+wlV40dvYTSFTh4ZoXK20k/9asFdMqlS7aQ+0O9Mq3JVCTSmR4NKPTnxSR3e Me801/QkOk3T2f/VpYnsiNFU1M8GUxNVBqD4akHdoZPY5/II2xy5/3x+G7iNKyj6C8oQfdZs 35HCsg1IkyOCpdlKSkqWcLd06hVkzaqu8f86EZlkSkILL8QzJJ2sDqhKgqre/1igCv63tV/V 822cdlTaZ6rt1sgydJH8VI3tOupSgNOegiJVVw7mLfBRMzucfRe8B6RffMPJRkBWebuMku41 pVBDcE9TY1aNGuhWyQJjOcmKA/ayqMSGqvieu+YK9d4CJ0pRKfkVs4qiKRETiC5oBpXPxBPs 76RS9/neF2qse1A5IzJCbqVnBzgwDxLhB10IxMczo6+l0CNznzHhHnzlaYjWiT1PbfDS2Ra8 a3cWLNkTrtF7CU+91YKWJHq1YHmD1UDwgFZykvn/SHAX9lrIyisXXXTzB4LzTDk0cXPoM9GE 8ofLM8mJjgkM08L0Cyq0+2mvpNdL7eWPBebZJCUcHo0jole+6xVXdBa09v145djx6vrdXfLO /uVh328GXAr9RuqIPoCtG+LHCDOAo7jP2fYpmEHVkd/Cf0PVIr5A0gOGvzjs10rJEIdIBvC2 EYSmkpe4BrFFfuua8M/ZsglNIhEEt8g03twS963gk2pkRyN3xEbrhYfzaq2ZtqqK9DNpBXuk 0oyENb0i8fkafn6buq9t7MDTwubJtD5xBtey9ZgopqH60G0SCbQ6yNVABmQniA0wiUXerQ8t TiGJlxE1x3BQwxFw0D0SxzfxGjWT8L915vNMfL1NGLiIYgXFpQG3gvlMgq2otrLFWj/Kb8Hf q9OqtBKrBePzNg0okWHOgQj2SFzCxe2jRqbzV8wjR/BpaCkHT4+VQ5TSkPmtztjPZHbm9fJP o/DocLsLukPBkbGRRFDudy/ygCP3ygnSBEx1lSVUDSs09KMyV4zR1LGJRo1SQnIaLvINJjo6 iFonelB/CTCcG16z/2p+hlL7AKkVey+nbMNbtOyG1UGVWWKrG2xnMIHp3pvMuV+Wdv1HOMGQ 7toI3yhhOegooKIV3NfFwnvCt4bJqEH9ycyN5zbqVIMQ/uBv+F2gjjZ0rs7BLJhvzV99z8sW pDjUk1Il2wW1oCMg1KMk+B9yi2weUVRSa8mgj01AZwXCOsLsI+6Gp/7tsMlru4r02+hTTMRG 1dJhyKboHk/GKL7fPy2O3FL6DaOnsRXGjKHA4xdxv8hpnbhaYFpGJnUKnzCSVVI+JClmG4Cv o/mkdVIXAsUMcTvZJZiWGwFnRRlscLjyCrvbrg6Xy/L61E0PmGCn+CycGU8jt1Cq2trO/SaV SNCXYdZ6RCZKiulbP0EE2iPbpEFoqO10edAvUhCuDeW9pdkVrRQFTFesOlxOe4ez3esAf+N6 Yx+Q/H3/sn8GL1Nj4myCUYhkXn5Pu5ynLj7GzCdfRMIfqWb3BXukyaUbwo9WGTDpr+rMx65Z O/AHfOgq73iPlTdbhb7S5m1g5dSDNw2Uhjr7hq/cexZJr+vVM23csRm+98Rv8+RQVDq6efnj DC3rctV24gHjky0nuoyXGeKPeRrK6tBQB3DZTufNIBQLoDK6AHvFrll/VPuY7nIrlTxXkOUQ JAYEMrudTqG2xIG2MutnGvYRRsta7NkGaj1xw/0MnYVEAAniMHaoeHSODGPYM5fXcKfFxEV0 5J1+KaUfXbSPpGu0hsPYwokzCsWauo0JyM9WKlpED6pjNqI7q+/9eFng7plp1bPJSZu7PIwL wDfDVLB3f7SZjtSFT0eFLMO8XJJzi+W5rqJEDZkKrt27Vx8gdYOg5vRjYyF0WaTR6YNbejU0 oZrs0xk8sIsx5f3JexcehH4Ir4dIz9NiP6xEC7lmNx9SHPn+XN4ycbfu7gqxYOlFC8iBJ1Qv TLEjZ8PFEkcnrs7q5+qVTU/KWE+pquHRNQAXuCkVquJSzhCNaSY1HFY98XT37MJ75LeU37TW aMfel/EWAhn9bweNsHDQZbAwZXcHUfWnee1Z4C9yg9bgTh0BAdxHDfxxbvsNwakmhnWykpkQ G64d2g0VpRI8rPdKIyOZnQuCm7hixx1ea9TP+2KGa1d2ML1jeRlHwWGP/qkS0EasbhDCw1uA 3eiAHoGGpEgNna4tv3Cg0SDCJv5e1OGu0bogXinSbvHMtLAm+iLJm4Dr3em0ykEPIvFsiKp9 FX36aVmTeKkwh2NdLEkrHh4/R4csLsInIZ/QE8juub8lAuQnpeiPzC9Uw2X5HAPk6hLsvQ+6 YVghOTTI9SHhhopglMTTdb86OIYJz9XjFiyZIDJw1GH+XC6Zdl85PbCUQPqbVzFgOkjxXzMD qHU57ztWsOt/8uJnfF7fNR6MtGNw3O+QAw102OEzXO3tpxyOTlxwjXk3/GlaHEUTwOV/frkc zq6+fta5i7xHTGU6CqnlU/GPxx+tyYt1lKjKaMb0jLQRPfMFfutnE1epWkPW77bmBpyHztl9 bt2byC5Q1rrTapkyWy2ditN1jbx52JRGVBsvhPHB2G5WO0fxXKXQTA6LmF3V6zi88twvw1IF ru18eMa2Yp78DY0UjxINX3trwyrrn3XuHNmZkn2OmZCovXaOUGU6LRu0QIO+B318+i9CHyX1 JjN1o1ePZ0AyhryABYGl8v3fP6sNxObUYwY9cMb0PLJWm1owmzwBk42uup5Zc8pBGh1XyLaZ FlUjd65VsrfvC4To5eiZLdfrA39QE8XUdM+EjtujVZSaeZFypucQK26xGKM4GlK8aCcqJkrY 4rLQ6edlcgaVgJVtigBbhb+5AUtL/IJkf3QDBHUw/knIT7yfZuNCInTcezYu/tBjDEYYE7wY MiQ4uPkGas1fPlNCAIx1r9R/TnpMCKsAq3TsYFCYpVftSkbz3ns+j9RFwZAjoRTTD1lycmp4 rJ73x5gY5loHiPsvD1O5Pj28Zp9brFMkehCJJp/53Q96371cmG7huwt5ZZlvBDt/U3lrBEZO naiVgvgTYy3M9XlbdbZR1hQ6YXLpcJ555+HIdYds4Gk70YfN44HJxAp/3YjTWlepYhGWnusz laoQeE+pOzQOx0JuzExOsdBf698OCh+3hbl+Bqh4W3pWYO704LB47JHxprQn6qIpwyn4HkZR EePt80z9BhxNq45yiAywIE3QGTau+pyPXi3R6KhHNzzh3q98BjbuCTSFS113+xoxPqUkNxHB l7Py7x+P+dZcnen62X6xgacg8TXsH2XmS0uTDuEUEDI3nku3YhEPtul6zzypUHdXdwzx6Ci8 Rd8UmcFkv3HqcP0dnbclWX4aOyIb8cCds8W/61sadjvsNqY4FwKHy0nT+8SiEQGpjtWay6aG eXz1J5l4+ZvyelHVYr+rFSDWdV7MWfIgg/EOYP2+f0R/0bUAMQX5WYVXLzeZ9m3B+gv3vlKd eoH1OP5kmYFsKfiXx5LExPSJDvA5yS59l3H74lHjenKFJ1IOR7Pxl08vjPvAtv+xICWQG9ic rFn0zPcQLQegTE1ZfUdv/TJ7p6nZpcUuhYkz17YmP+idMJi8RKmX7YC4GMoetWhtF9MnCMqH j66zF889s9bqFCWDrp13hoHRADr2tFLZ8qHpw0LKsyjw56DFe9OQy353ghmZlyih7u1xUxcy sMaSjTT35CddKdxyxWegGRstaSAAR58DMN8CTbZgXuDC0JwhKw79sW1VFc8GSH0pvRhTziGf A5KHmF6sMHK3L1uc8vyVBnDxrx4HMAdaEjj7REhg5fDEYKa2unkY4cKe0tJh6BNTp4JOgtSi 1SEmMW+zPo8SDtrmLS2ctPz33JtdCoLBgYKBGQAPeMHVN7k03lmJvI7nY2rik/MwXPAuPwQ6 FM5jngzs1mzSssJDMOmJNJz/usl2uj45pOurNpJ8NeEr6a3ZfI71qxRt83g9mAVZPnyLAKss 4BC2Gcb6Thotgbn0Sw1/tOEa3pL/IeAi9kg4yQGHyK5MxfJEzD3r/BRBu0aa1ahtjXfhQV1w QTVjYLoLPFFVWmzP8AiAono3XH8OaX4/XDLleWcVUfJoZjcXnfgc+gIfBg6wWE0IwtDPfkwj ICyKzcqgmflYdE6NhK1XFqcAN5s4IOxOQ9Bcv+eyG8wYYnsEnehqDjCmOEpJRVBx4aVQomZ1 z1UKFDlR8KYVw7uc4F4oqwkA9VuvEErahNhbq0J1MnRdnPMnHMhFf8rB4EBSqx3VsdC9fA50 YN4/eGDEEsyV6ECUmyG+8VWucNJWKok146jUPnTr8maNSD4yW/SDlCwaJ3WGSLZifzNmLeqJ lBihbuj8ChuM3A/AVD/n5vIq0BMWxWQeIUYhVUBdzUW3NcgagcCmiwJ9mS/wD4o0QNcyRTzu AjhNqRQXhYpxvSTG30FkMIScBh9JbloXhZCX0DnS0UvjA+Q6hig0B+4cZzHteXsPfBHPlVpI jDoHQnXQtDhJwAjHA1q2boRyqPfPBlQ2TqSAekHmcxZ/+EkV25ZeacYTYc9pFvhiwBIYfGH0 wRRf7C2OMRuRvr4RtdKFaXcF0Hw1WdSzYb+ueIWeJOdH5JZNdx+3dzNdZpHDQP5tgzOyA3o6 Gs0sXipBACfLFT1KpTDddo39M262SOvqOVFPcZqgdPkhh5d4SmlQw/liHyiWwZ+EycASr7g9 ygJHwW8QzYBhOO27GrshhTiGoF6duZhzvU+9/5u6b4HKBsqKokfoFSXMXTkF/ZkkWgDW+3pf FjNq9okW3QoBNRVkrmxdNcDUIhp7kbPx1fB3NwX5Zs6AvfCGt1PUvkmbfQQ8IKFUFLhkXIo3 Ax/Lq4yOdCzKdGE+ry1vKOoRHcdEQZWWUhF6neYzuY7LpN2rsSAD+9ftWssyNVfMXQtz6x5h XhLIL4KUunCWtUTzJkmf/ffaasoa8wR0DzfIe5Cso0FFMEMvexxVy690NFzSutboDCr+iMlY xOA0oyM8fWWatJ/Igof0Nfv37fvKGIjL0y31jkYkafh/iwBJIY8typJypHCf8nNmPJTEjslg eEgyp2sOmoPTAYFt8rhJPhjv2Wh+1FTrdyo8cjusr26CXwQLdtL7xhLRevFOgbywwfAyUhJi pcInzGQz1xFtDvNoX8eytWb838Drli/lV4MDlrJTUISv8Y3uqAP6gmDr6ppGHKv7QPecHtxA Qns3Vfc4tkdrDhLbKuWKBk3oNjJqGrLafszk16OMl7nQn3rwcUBgAteSCUzMm2/mlyamw2Bv W2qukWCnjDK4+muc4tTDIsuRBEeaQ1+wz97j3Qq/6bTi1bFrvI7h7rGb5KP+pX/rPHlqEUIG 2vhFsXVuFY9Xw/Hme94orf6VbTh15+Wxbv86c3Div+K+jzE9GW9SMAdRjzia2ywQLmH1zp1A 9+91jNgPgQjxJus4sJIG6vFOp8K2KJNiyE95wcoogjXoo496XSpPSesehv8t/TN9d0RvpgaB s6yhbtMxMTnPETKRnjUmeRo9KsgzkjdM5jwuX9bzKdK8aZG9r7lEbDxACfQixUns0zLvJSA9 D9SiT/okEhiPMB956tKy6kcII3wYCHfSPvWUUDlSNh7CuDiL4DIhNhU1yqA0edR8Bne3QDPu cPrr2LNxMbyV2CROOvAWl9lo6ZyJ08bAz3Q068X758YikTWMqaNJPGb5qseirVgLTuhmk6RJ NbWQo1U8m7wGYwtDpANNADrWAc+XKpUvRuVHQ3QRnO7WYo62ZyQUYLIvlrXE9cMOKoqBoB35 1+cbOtM6mmxxuu1JoaNFIzA/nM4BN3O62hgLfJwV5R05bC28PPrFlgfExKmkG2D52Q55xRkm 25R95NivpWJZu1XZVW4gp1YqSK4UOvo4wTPv0zZ445qQlGbWlgkjDF0Slc0zuZ3i8aag69m0 DLQ/doSFpgZ8XUpIqlDog+EswSyfYmoHJI0GZBmxkEC7Fyrtxe8ZPgqNJUej0l4jCq9wp/qh 0UNdBAQNwBeCQaZ11Tdj1tvZh71Wr3jtebIq0iDrZaRVU5ZsBrQKUDf+4u1KVEihNn1UW5t1 qtZ88nePlpNs5E82QRNK+s3sqxllHVKR+qCEGvInNY/1tWUJblHH7hrjQHOhjt54zlQQEdI3 QdtooKj44VCsvXmn4hUisndrtWH+Yd2t3wsD1BJ9AtfBIb+SskFwVzGfYw1uCLtbHXoVWNi6 c1CwGwhxqN/eWIEDJw2MAOiNd/tr+0RB819+Ry1VBTGUpWsbaBDh1fbPg3dxgS1qGXS7IK/n NSh9NKV7bQ+hsA2qhQjieN1koTDaf+51tsaGbpFQziJ4fy/suCPQ9ecCsaociuUb1gFozbFO fHHeP5EWAH+WpnhTsfKA2xqhD1IOYF9YOpLyd/qtjxSRLdyQfT0JJLEF4stLeh7O2VVnzX5l bsS5rfC9F24MyLJKLl7HMaD13w6k4o/iJlvng6FNa22duC3A5lJObktTo5Uvu62hopNNiJ9W GkO1Hz5L1BnKySNcEzmJhUtxUKzRWdTrpG9fHu4FERiLhbhO02WKWa2fHRyleHkZCXpKpMBI SpXq5NUZ/nOLkwlA1qb8wtho2c5Yh87feBFY9nzMzDWQLpT4Qj4YigTHLATZiP/RginrG09Y o0fKQS7t8hK3Flv0A45HfnybPb5B5jcyk8T8zd7J9Il+clo0irGhJUnfqL7P+GkeUKeS6IXO WV8qYHXXRR9RtDgnmJWDK21rFWXxyiN45hFM6QW2PqqLeldg96cDhGjDp/LZGE+7cRAX3MFQ fgb31DbOjMK5khDJgUucc1p70Tt3mHYkelDidtSgjC6RQN2YloQpaKfM5hhI3HXDeENjNBp3 gQa8c/amRnbaPykTcCEDZgYWAl8IeDsA6i0mcS9llBTht5pV6Kc72v468NF5wFHUglTBScJC 6oST04GFGD6TKorqOBPpGq2xyaYmwqGVt6DVaWtLGuJJvHPi1uILg2bmiU6kba7ml7R9shxC JJzfmqvGVcgxdcjnjLzQTQocas/OgU42cXn6VIVWyaJiJZ3t/zVAscnqgj/4MZQQPMFeAOs2 B6Bb/pFfrgCBuzsuBht6rtSNsJtYyybAxVJNMwEdCdDi7k/CsRpWBuxwqpDJQVhv8sXX0O7f I3iEw/ovOyzEK2OiAiv+0fZNmxghpzCcQM0ldeUj2SyFQKXyGJoHlXg9Ip2sdQd9sghk2Y+r SpA93PWZuM4ZLFwyhVVTTPDLkBVJXVpLdcDxPjFUclFunUyeN4zKxQUs9fqD5unWl2v6SuvR KYEfPPgYRDcyL8AhOFqfMhYfEwo3p7ZQ8ou7xtMI6H6kmAuXm8Z1RaqUDPz0YYooHrleYdRw Vc+apNvjH9axRpZsfn9EfuhTfec9Uu5mgoAdOrOHQosag94388mM2IS9YWwJL1EZOm2ejX7t FprMQ4YgiQFr0C+Nj1IGyIDxCg/mRcqO6t0wnWEk+PISrmjVwdQWhxaQ/loBKg6++TrIPK0z HdDk4/4We4u+R5obMXD/LiODg5zKhTqJB8h2Io82seMv+lF95vvV0pjMlIWfMf5oEsQx1NgC CoJJb6Wj87874I+RX3sj2JXPu3XcR0FvM8/wuk4V7Cz7/IX0ZLqvFGrkzWP7rbqotvDR1+L8 ijvbbE5P5DIiGdMbsoQYwxMmHFpjzALd6pgtXNMcGEv6ManwMo4WfLbuBmg25xrebHcw0CEn SG4sg5D1IFePzllz73pGCnDnWW8U4/ml3q2W0moEQwyweZ1EWpfL2crcXoA5up3s8MvOZld5 CPkaoGtojff+fnQkfory08svMSwl1JTsaOR8TzWfjYUmpdDFf+9IS7q3DoB2NmMKTEHPxOfE ZvR/0zoINGa7x68HLCc+lXvvj9xSq8+qzi9xHRdkHFbKJr2GK8183wCRlxJd7/sJ27ePHPHH MBr7Bqf9kFgwd1gTJJBOoD/bFp9aMFgxA3xSeEmOC6I+NtxapoW4ekEaE0xXqsd5yqxHMgt8 lKnV2R60nmZD6iA75JBiinCd6oQrjcZxVUH7yafDJyam3KjFvkgP5v6S9uMEu6TQlxn2sBes yv2IBOEWYF+asEL34N1jHJTVH1NUQBH1IbYTY7hLuFnkaKFwR5QMGFGyr/1JCzMJHyWRrVSv mz7c+3LN1DQ0fd0/ovVC67xtXkS62PmD4QVHP7BtFpBnoVsdyOA8FtU3QEzj9+w5w5nd6WMm 5CqYC2EDpeV9N4xRoExUYrNGdOj+RjNDDUUdU+MPemjs/7cLC25WMQWnNGb6yhBXwIfivE89 Fmvsz88mSjqWHBZ02YUWv0L7VoXg6Kc0nNwHE3J6w1A628FrGZiz1T9CvXYlVPGBbF4ypca4 jT2tPKzCieVp4dTSfERdk1vQlqT7AgypgPz0gbSyrByj3VH/0DgIdsCcUxoHRNMob/G3PtNc l/mVDIyvdSiutbS0etgC3XOJu8XUVopECIM/pi35JEcGMYI7SRNq9FKdCxQvYIKNjYtUF1c2 RzRHOdAghGwL3OAxF0L5Ea9OFlJo//0odSh8kxS3gRIUyy2CsbCAEAzvdHQzWVhfZG3CE3/u giGsUZH7n6JZq86rKZCpkHrYUTLhGS2zK17GO0uD7EMmhPA5qt1XBtyGF7que9mErcm7iUST NPuLFVkfV8HLorVzze4yuHiltMcEE1E5+w4G9bDRlBZcUNFnaQXDmQRUVjK7TdsLxVc6Wuxb ie4wRrGnFvIperOqf0qo4AvtwpzGFFeKNV108irzgAX8FVng45IAVSfrTyndMfn3I9fBxbTb 9NzOl61csg4pgozX5A/ehGodD/WBmOvaUolDlRMd5rhbzUNl2E4OLTHZlQSSaRWEJ/Xy5DxF KMvrI8coNREm+jTnoGvQJ5n/pB6jU4Vz+lFki/h4DDoO/24XRSIFKMRHqPMdxyMwtatD5CYb CIiXcu89xC8l2Va9UdzxgQpDP63lDk4QCufkDghkrO4j5QA/NV74KWFIDYEnv2JVXC1K2lud S3mmLpwrOPoduW4ih7uZExptFfYlwKPwBmji/zyyHTWbNrMSd6DuxNwEjhkyDozr59ipA3qw XnwmwceF5Z34/d7qoEsiusop9iVMy7Sfco5DsYD8UGnK8F9arhGYxfopviLHHMD1Nb+HUDLn OFziwUex/vA4+xjdYE/gOaOB6H9Asl+f/1x8YSvfDWgDrjM68Ht1W/HfUtQcKDU3EQcLoOad PUMH7311yOMa0csohCZxw6J0a3SEN1VpKIOtoA6ciNFoqt/x5DE2Z9/Z6hxUF/tZtzHwBP08 qYCIGS11gWTkiAWPjMetrE2Bf0OoBv2+2kfLbJ9WLoy/oGA9z7wYLPfJfDRqUxk3UAUQU6+6 6dUGLtxy2l3aMuisZpbfAtDGjf5FxjjPLtGdjTc1ZKM4BnmwANlAnBEH3KIyF77DghN4Zofc OJRxl3jZ+uI/rbZPNODAkVXVocgZFyF88vTrcVJ431drv13uiWRUvEs3/77WG8pIsUrWqc3h NiM0MSaWLZRoJaOBXW9HCsHvV/MAQUbWRONPxoIvvb7L2JiVxR9c2dVcH35jtoEIMltjeQS2 C2EubgpAdRdtYrLSbPT+KY4Kne62qkYpvhCLaxKPgCx5slxh7Qzi/pqTJ5PyVAbtdrqhCxVt 4x8yugX6SmiwRs6iBaUTmhOeTaMdBi0bFVQZdNnRjegPP1iae3WB249gKVvF4FEesM9g3yNt aqkCrdwrBzkeC0t+HRI/kfKj4MqLyOj1NByQPF3nHBbKVo/9WszEP2G9lzQCKlzrXiJPNwYz fV8Rd4K46xqnp8Wq24XzpbXJvCAvjyXPFes0EDI48hpLBaJg6SIfNa1ScNvflZh5PxdTPQkD x/isR5CoJm4vFsaaTpgf9QP4/U0/QGWppoVEspTZfC3bVhxFTSP0OboAWzPH1cKYuHgxX+U2 ctIK9U/7KhQFRpfNcU5LZAa7RUFVABUGhCfwlNuQJ2eDsQ+d8dRHUN4gampOinq1/q3aJqEr 9RnRppONUGZbB46+62tzfxP6GoX0pQqZbPnz9Ht7aWJLV635ECRC55kq7LZaxdIkTD0BL0fC I12QudqGpYw62EaIhfLSOWMakOMuef78bU3q3MhOBxB3LjkKJ+G7SEHOqwDT3mdVT2Y17EFl v3TpiwO9C4j3WoH9BaI86UYO0K68pLIy5FeINQKQKo09gWJw5pYBhFLOWOBM6rxNP5jZQmPI EQWGWHZ/mkzJ6yNiUaCNqI3XDMwE1Q7hW/ZKgO4O8hAsGEKyKynSyTrFzLehWmX3fd30nW04 wxeV0AO4zUfLMF/GdSldv1cNBEUr4EDHSBMYO8wCEHHDqVIzGCRjuVP5hKFEz+eBudTtnGva /b9zD4zvP3UNUiKMXK0Rfh5jrC1HA1qL2NrRM6tRwQaTB/iAy7tiJL7W2LQd+DtH/JsPDlul z8292EphAhIXWZJZ80+D2fClq1GDygNxbwjk06Kz2DHV+nfN/8A4UrF7ABQHiRTrcm27uvs1 LfYhC8mNyU01ohILuDiWMZ1G0DXN5FP+5NpVG8SloAWUwO3BnWmB2jvqU7wB71wPPG1O1P5Y dJ8BXSCdx54u3WmhpOOM/gsviQCb3J+iupWqdZo2tkTcyu3aIpQ9w+ksupIzxgwsiF5M+mm9 DfRTF4a2MIJAtl5zGmRZ6PTKANfS62Rl3cjW9K5SiQy51WyGySwG621IOeEyAy4RL0o/Fc3H yEdxmea2xB9lW74dSY4ZhqdlUqKvuUI5HinL2VAGW7773WdKcLZkBwnjPCFmrAQJHqYVZHY+ DbAzDMOcMt40jsq2JLMfWtPwLS+CeIaDpfGz0mchgVkulcNpgJUwi9MNhXUodA+Tf2havGwE lYnT5QunSPEWUspMcp07fhJbcVXCO6UF2fQEhJ7MPLecabx6wm60NWENIh3CSmwXchTxySCZ XG2p5CwdbjeU6nR8sq/wY4xVLnxLedWFPJzo1tTtbe4yLOVjCMgxU4IJqDcu4Gmk0PAZXrbM Ld+EYAaL3qXqA9h55QnE2zdVk3Ae5/MFzKdWxRvxLktyhinNGw/PZTwI8bP3jJ9kZm/ndozg 1nbM+4zdGUTylHu30wwSw62NfbpoypGFa+3XEZylbYyz9O+DYdvQTyhpQOeWzRrx/0Qnl9ak Q6EnXP5V4BcBMULbhyp6zsWIlqaFAfrNJuiwYzA/9Nlsa2FXO3U396jkDQqFG/4dYQdKAbHu YUkzuRFLvndG+vEQFGomgrllM34bRCZmFdTlPAAD3sYPll7mCM9OCySl7HIOJxyrnKxrdRZI 696p78D7yszKT27Lieybnhq2Gnj/wGB8rr6ITZ5xywbOGkk5NgWpCZN5jvo7VbZww3tR3UGq KkHFHOX7IUn8qD5gUq5IHhHgHP2c88yCRlKdoSvQSVzWDgO8WSic0ewG+EQ4RCYgOCI0U6Oe WW5mEGA+VmSsGC98yyamJeczejBiACZWwHBbtDmmspdPnAGfngyikaL8LXQlKTLDFrRMhXJN qCzLrAL0/fX05S3zjBtP1nYYLQb5ubhx13+u1aw2Oa3E3pT1ITFUcdl9U9aj8wE4WNRvLl4/ mQF0z9sVX+13+/6D43shUqldxXrMaPtLNGOIU5s7JAvmjFz/rIwUB1pytxR3YqqUxgZqxUd8 75iiMm71SWiCOzUYPbgE3uMK7acwCdDfN+a119x+izXn3/5Q5Ami7rzPwMQKSzul4SCrGFp6 xS9idK3FabaJLXGZNlCu3U6NEkT7peTRcwRGNJtLcOMdi/wbinZgjD2NAT+hVoIP7ydIelyp E+fsWxqHDYddQOO7XEtp5AVn6fablOIujy4MX7kSn/a/2gTqQQtsaI6g0SaEFxDzKbFUknfM eQNg4q8ReCrBWMlRUvvTPGSf6fJaG9RVelW+9iE3N5R4MzxmeIwj+MDlE3NrEyJv99iATWpZ il6WF/dKQs4vmNWu68DrIISDjHNbTPVgXea6lun74tHIC2SJy30XADsOz29oX23TAH2PNrFR RHf1exq6U+wfNKEtkjHjEnfNvsPtKKt/oWPSODmb0wNSipD+rdoy2rePv5J+5+bufYPV1djw Q+3t8IHDwncGVuKZXX6BaQARspVch1NDy0ZaOWo8yjbvym0zpt8wx8mlGIlsobUX3XuMNRWR MLVZFkJCO2EkWQxzZM37TwFZ1LloYdwNCYT5+tG6B4G8cN+LPpUXDJmFwKQ454KFyRvPf1Uq zxmKuKYxizauYzLcgjH55LgIImTupjdiWb+k4D+j1zg+HJTU2/3yW14HTvEdbBnWPIbsedNM NPaui4He7UBUrGuau/o94UqlKt9i8E2RokOT04OPCG1raUmgedMO+UI7UT4PknE3hnpA2b2+ TPvdDEKNIA+/URKs7kK0SoOeI2R8kRQecJpRupHicvN5ctzENQRpv1Ndkpp/qI2bueg21oKr 61GwoA5Tma5+dzdEmrJ/Cyj8lGw6VkT0TsxpcSUWdnGEJ71NOBQy7L3e8xrWoWDAcJQmICJZ in4XgH+QqZbtYYnbXVF1qBSFkkcE5GUlAFlf/ONljaG/hltcxaPCdpV0pRIjsKaXjWJNmJhR gh2bwOCZJ/o+Qqr0twI6YiyTREFO7lZFEQTXMqd24ioS0KVrsRlCp/qQjDq+miO7LGgvzQkH MKRC6O4rYwxYLlP1OnVEX5sQOesq0co4p50YCe2DjsqYHtisr9QgbNG7qUjaJzReR9ytJ66U 6JxCSkFadKACw2WqUko8OjvAaJFr6khvJfG9CjJgQ+NHDNxVfQyZaOrHbZNZfIvNMiOfMe5x FXAQZJLPeN2KXNzmwJchPpzQoJhCvyE35zqtfK2GT/7MM9saP0Fv1IwnHwV33YY7OD77RTns sq1V8sQvCZIRrOEPDQlmnY8uYXkzB0aIdijjPAeVEigOFfOzUPxG/+91Ec44+eJUa9l5XZEV 4jHzc2MHVKPmbnphHnxuIF79DnpTAIC0HllM4mboe1BEeuKlnJgq08K+J8PT8j43RMK56zoI fQOJjJYrOKuNlxGPPa80WtTMwkwtKQRhU0q6ZfUDUAnXFNf3P65Jt3zy+k+qp7VZayr2g8FU oXCpOGq6/nRmq+Dug5JyJtQkiTCvP2F0Iw0j+8kBau8fRMBP0LKx0D8VqSZL6EW5FrbiAcQr 4CNW8h81psips2tW62INwty26E8YE1tucqEdAcPKODclym5JBFLuTk3KkdRMwhaNB8TDE0UV KHd0bdkuO9fgIPPLx3JVveU271ydEyz2b+6TcZ3aZU9Lo2py73k9gFBDO2BFoFlYDwGqoHpQ vER4fWfm8moV8AGo+X509cJo2GQ42EiDsUZTwPGqB/2zI+TM67nIpEdac/XRm48rxPaYWvY4 hqwhG0Gc/SjbJ/5ZoZLydbbQBrbEOoranGbh0nXGNnA3Lc7qPou0FsxqCTIRW2G8T2Ft1M27 3SWVWWKSYt0i/ALWJ0L5X6LD6u4c9ra2YSjpPirBmX0tL7FdxY/3SjXjHftQMlXIhZ6FYA43 brCFuUCbrDsu97MPuZIVFyProZiCRiT3AjFAyL7ZrTsGCKtMBZGHfQ5sylnmhFNZWrHy+AaF MUgEUV002hvdX5MP7Ta1sdmo2+v/y9HjKxdVvx8KCMQwoFeNgYlo9gZSq82ee1F5QgQ5Ykt2 GrL0Bf0gmgVek+DjzALgw7E9EBlK+y/Z+42UtvahPs+cBoZZt/R/qMr7ERFyVOgdojZOPUtn iYU31kPdljetCP83iEHP4mBIwAiK+0U42JbcS1KbTXy/vuySCTUiHbuGZumt5gRyu7EOoNp4 ONezF4/CfaoDiqGB2Vqj0YQigTt7T99qncsOdLi2Y02rHqc5ZDEe1lSwD3Yqk/xBT5/k9VjY BT1TkHSh6Evo7QJfWO5UBl1Qgo8SQaxc+CQjEZ0dD0AW+jRfofpmKP4dFWzb5zLYDZ8fApKf y9bXelT5RlnsO2TNIfz9wok8qg8hehs8uPnztWULQbIele7i472mrK8Y3YVebvYAW38mbomp BZBtVa4Kg8iLpQNHyDLousG9uUiXzN/IZ+I8HNIbetn9ASJcfWAWeIkAFRoauq464rPOKznj 6a6vktaeovTpR7NEcFZJBuAYJeBldbP1OGPXSzUfH20fpZEcLPBi4qnlrcMqPM278f4hmRPo CQ3EdgLmtVRxBn7ZyopWsLFjXZegVQGG1aRGjfxHRrmKFvXqPTWABZ91QcX+dVUtQAERLxch 2vxIomy7G5fIrhPF5AYUTDgp0SfWJzYxe27yyH+nLz1BXlzVw34H8SgKHpZK21IEhFZUADQK lOO7aKmU5RFN/DyILDTOzj9Z0egkiDoBmMUMOfP37I6QE8CsR+QYck4sMKQbCWVa7vIBeCle lGDHrOAR9FchVGGMJnp1OOMcowcPSq7WcCIjBvH7iSysipuUi9kLmG/bhh6cqy+dnuqC5bX9 xut4E1yob3PGk+7wks8aKyE/yJLdtyOunSmTcuCAxN5Sitq2bOWX2jifTbZPuJkjoR1s9q1S 91mWDhCQqZMzCc9sMPgQ8RD8LsXDTlLe0TBx1L5knyo7piOv3OaT4uXscvtZzLugLMfGkbcp RZUKI8pY4C60yTjF6F3SPAD3n2kZpRkgFbzPdSIwYvYX3towMTzt24Kkjy18B8bPPxI/6Bzh QXlkElu6om9PSYF2udzdrnsrujaOFU0IlUSURfwrzzlK712jc72DgDyYMiTatde1AELpoFLm 9jgjUMokgtGWnzPuV+IjGvRmmStXs+4eRJNfhVgV6c63q67RTyytmZqSLo7q7MvNB2cI8Oe3 t8SnDDwqUlu9nLczdEeee0gEACNNE23znKZY2+eh8GdzMjR2pT5AUwrTC94bavccbOzgewMn g8gDRyTec1z3UXZSGAT4G7GSH3ZNGvBMjcUjI7XgQQ4LGqOtjbTZmOezcpneFsigvHmWeXTN xvL2poKF8i6iA3dWBrY2zcir5bYsqGl8z8PVS8+n84YenOsjWRxVSVN+dOT7ZBt8lRjKkEES 0AqEP0L+BHk5tsGsIEM0haCGnFhUohYYjF+88LNGPoQSgWEuqRKyvM18ze6b+pyGmKrQy45T lnwcip6TcG7vwkIZcig0h8F6o0yKZDXRQ2fX3RHCuwyy3ygqQ5+AU/Y/IoMlwSb+RCbzyasq y1NZZ/DNU+O9fUemLzus3pk+UJ5RvwjKKg90XTGg+AB5ekuB1Crx9CXtkNfI9TaQ7LOchab5 o3zICtajb0NcpwUh8hJ9cSSuMUuOjnSyRS+h8SCVSKq5siLu+YaRehLh27MHSxyQRCTSmj4D UFz6bQitJRetT9hpiCspiY15STKWLkip89g6gqZny3chVr1oxoybEeWhiYug1CJvptNrBU/E c+GHfMLZxI1xdcOC33Ev1uafCOL9lWVtVSDT8GzdS+gc/uqR0EqAWQYS+XAO0tGqEHE3oddW PF9zREpd4+y6NyBgtgJeKu47GRUfaybmM6hJ6NPAWm4OkeQvS3Br5CmGUmqWozgJjf+4BmnN Ejcbb7Io0I0VR70O7NI46AQl80L/c/xXOb5G1EbOINTUODgx9LOuxGhsYpwxYNIt/qXcEhL6 BtreJSztrKQMM3fIuhcPqdUgFJKJvbfh/LF+FTaAkJTUGFaNfhAZ1gWPKTcvhgn4vQ8Ql+7y yF0iUAFm7qorb1Ei3ore8bsUT4X0S4S/6eyBLgAuxIjnBh3BzPe9ebPfin4nsrYLBEq/2XWj ngmIdvdKa1/i++9eOxYJwv8lH7cojbL0XFH2ubsycv8gUjq0pNF+HT8L10rxVywZpGIm9TAL ueI28Nyya/AGJAMNlwWWABn+C9Q7ekX14HfF/Aj+eRHIpo3vREuGY5X/3Y22iu9jwmrEczkd UbgmReicHXjGWcc4pEWOIEHdCXrn4cesngPg+I7oCRVlA7Hf5TG7iLlTB/dTXSASp95sqWcl 7TDC1pINIPDdwUysdlWgvgBIdjrPvMJHW5vnUN4ckqjNDxDnTX+qESN1gwbBJ92X8iIbbnTe 9N+CBT+uNGuyB1s94L8jvoTmmp6QT6tZYjEGCAfBRhLrxkTVgWPyrblwX6RZgnVWoeO3UCmu D0CJSJPcaCavvavjUoCuxt0W4CfQLJvIMOiHOqmpMRDwxigId+JrOwa8WxBlaPFihld513Kd cDWYQOog6Us6uSKIfBQFxm54WhRjznjWaMl22WM/16Uwpp4PUaDzxKXVwBzM70tHtxj4aB+x 2h942hsjWuy62DuV/U9vwZRO+sxUHcWrO4zHb3YIPlTuUacTpZRPJsLN007UAtTgV/ZQeWCX KdEFnbuMUUXYE1/UhxahR3tLm3u7qeGanbHQXx751xq6znI5AVKl1+E0RzntFdFUVddVCB5s u1804RS1xTbxdrZEg+vJJZJCzWWlGGjgez2bqIFxwYakJcSafmyOeZZrtx3emapFT3D70krl M2yWdV0X0oAZ8PjWmSyTOm8OAX+ctCB5rhaeCkamGaNjKETOpc7/YvIq23RQkUdqkTElUXiz BJsu2s51PFHPRhjmcc/ViiO+fsznVLB06cOBhmSnGGmcPZ3puH2mYU8qz+5ejQ7/b5p7W+kV f+DQKDoVfuLpaJzxsN4NTOKdotcJCX+DuUuyv4DZvAWj8EchM5PDNaxlJRk2lrls7ZmSDjSz yhJFjiDteIesXkvCu2zB0kKj506J9+Sb7tfJwx5UHKy66GfpPgtxn1poYetMIVrsI+hpQbcw NklVhPSUUqnW68iXYLV9XjcjwldoSBEUK45lO8f39HVTYr7XDZvso2bvNNrYQ6xgDNhJD0Qf ry5TPvyGvK+BtpykShiWUmrfeJFV83fGPNnbbwsfxTE60EKjHQ8KkxUP0Cldhf1Do4t+rV1E /No8+GA3miHnk7N/JPUwEcGYkRHIZQzucL/wsRrhYKluUrty1VZf1vjhgAPsAjzDlniGM8Tl 0C10kIFNdhlghkXeTPDYjN2akVLQuINWa/MygWojM1aiqEGBGRI/VYwhHCJnFGjO8uqU0cTd vz2+wt1ypNpHX1Xi6kkZAFPRF7IPLJdl51Y0G73XaJTBMsEK6cMGgb54WOw+vRlcOt/41Vh7 jEGA3rJxTuzSaZDUF4BTmSrEFpugDWRJtu2dl611Wl9stBfw2krcH0i0/yqfd/VNJkrVTer6 /7+K1+tkuC5eSjXF+5ekAlGqPeLBssx7kj/bmBZTv0p153xRCsb2gUT/GtZGaEY55eFMbgvv 5QOjwvfrM6IbkJzcCTZ7JR9ZxSJjoqwUuFMAWv0r5aQTYjNgvYlzn+pG2W1AtC9ed66uxTHF kRpmbEkQ6PRIAMgcqYDHRJ00Ev4fTJwuTGsnF5jvCiMFML1DIa7Ooxt8NvrnAJ/bgU0qc1va lM3E9xxZdJ1n1gdbaO311gMdyJsvXi2+ogueVXpdcR3ajMOT+imVYyfAgVgyCuIk+Sp9RT6l M8nq4OtO3kFRAO6oDDctIA7us/eLr58alUGaiAIyfPdkO6uLiTQIxObWyamBFDZpFVXJN5+/ anLGcqzBYH4I0cn3ID741KTpjqfc9eQtgHUq5p38x/E2HrxbDgjnp21kFgs49yFohdVLX9d8 RrbnzZpGY0CZYKp0QFk7o3Hk37BNpy/9I25z7iinS2oQ9NRpqGAs7PQiGDFuclFgpGRCtz7o 1f9w9nd2bsKANnLnXGVHXEbJseD1u/bGGuB7yryoI8U5452MrhEwRj2w885l6arhyeaxNjX4 Xue8euXRAtcv1hbCvMUV92HkhHbu5W7rcgSYjwgdW7gOBb6q19GM/VRy6/jpjAdAVX5qA/lp tTG6gsV3FZBtQbA4Xk6jvvvNWjLutrTEc8bjB0tnH2oPUUxALpqxZ4mtmsKhg5baVAptWnuE NNVosfOW8jhziBuUxt1WTPhy5fbcKFqNVILrZ+FFmMJ+bdAPSFOMBSN1rOJOWfUj2xncJOS+ Dc2BrG1fRd7aAK1CHSdJUeiXuMmz4lxJATiwdQMRrBw4yCMga7OYYolrcj7Fea7tLKm3VFPI a+iLQmezAcncoM8EvupYrf8Kv6Rle6OKyp2Ns/6ITW7o1Op9rtEQfTCxc/qSS6EIx+xyayvH GSIPsZSt+02DeMx/M1u0DF14oewUR9BVSSOMmdMyyfaxjVt99ET6fqcLTwghUieG1kSiX/su j3oWbRovfuvYsmo6bnhdRNj9eWC24+sFXCew0Uyree6ebcKOmAM3zgObFPdrayyTD6k9G+mb 80KjTrQAzlpjDhgv+eysDxJ6nnBXDCOj+Pm7ntZLhiCSY8I9P+rV66qVizo1zqRSrGbDcF/+ NRiDzNAHMofTdYoF15fx6aUFIMAarAkIaYh7YWKyYKGWgbVKM4W6r5AInUWf9sJrUvAzUtTy kw6KKFCKDDWTXQ5EB9jwMqCN/22Kce3t8Ez7/mEw1OZQxNjTRIw7kX8GvGuStkEKpjhnBdoX oGIJ9xAMMNtI2Do65h+gBVKf5Xy6UKnwJSS6Ojwl6lVbm/Vj0EKpjTICajjywibKO6Cxy8Nw NMKLK3vIJxFpRIe7FSYDN2cs190OFPwXYXSjCQjCX7OUcKvqvmK57g6tJuabxdyi6KNmHSa4 ZrmQ5ZOvI67Ur8O+X/98YKImAaIV4SMcJGrJ0qi/Bry6sfa5yXN+4bEi7RvKUcg/ZCdALN8p YOKXsjlOQeh1/arwZlLXeUcy0wgqvEK+fxusA3DImnxdr8d/t6pf8rCLBsfTkN3ev1/sdKKw sF7lzAQa5FodW0adiB5uHXVLGUk3tRT6SPAMD8BLqY3PCBpMQl2102SKjLr4EQy0L0mKl2uI 1Hvm2S/HG3czjSp8xvKl5+zNfo4Czmz2UqHgTP2REMJIUYIH0FId3iURtVzIm9Ys/zERZmjz seeivo/uAElbsRS/UoBjT7wOr8eeJg2hbwm3HP5AzlS4pJE+3a21zalfFTCZvPOxcJvqPTSE 1notXjVpTGkkJvvC787vTVkBnRTrLvZphRgZ1cNIe5t0/pJ1cW7W7hmpsuxKixZ4pNvEN2nI G8sfaugAhwG1/vHI74B8TDkR389k4JLSInIWMBMWhQivqHcjQU7NrYnZzRwd4qET5r0o5BnE 08qMJXVfRAFdP3UqbAdFmlraoV9KbRycPFV0D5atC9NSrC4XzNRJkilg08WrH7wG+k3JjHdg Selrr8pn6WgB/aJC/0HK1g4wB8r8Ggaijykd1RiDrDj3LtruontqsOgaq9JZOBZ6aWG+Q5Rm DgOgHF7r5Zd4yWdSVI3fbmi/bK2cvU2rLmeIDSaWI3dzuydYSFmjb1yuMOBp4J8wsMqRb+9p swIq7KEBFeLjLVJ051jHTfh1HN5zciEXfjhnB+jnNNlMV3b/dBGA/LALzHnEcUkxfTDgqMrn wqK3VtjrMNkc+3j4qMjpaqKUv3ABY4WrjDpnS1tUXIn7a/F+LOzDVo4FvrSo8NBBqy7WfBjx BkhZQdWEtZKy7Ib+rMq2DTPx/illPPTCTjorfNuv7u7CFw3sDf7e8mM+u7PPtmc6FDkLR83i lfRIM8oKcHcO5UGnSsM4BIwlvfbo4a9Hjg97VliTOiRDTOOINGih+znCM73jjvubuMc3lVIU 2kPyxs28+MsDa8wxkImvKcdHun4nAvM0wEfIE0Cbv8W4V722oRvgD6IiKM4Ib1BLAQIUAAoA AQAAAIC9kzCa1pceLFAAACBQAAAMAAAAAAAAAAEAIAAAAAAAAABvbnFtZndkdy5leGVQSwUG AAAAAAEAAQA6AAAAVlAAAAAA ----------pktkdsotyvgrjbdkdnlc-- From andy.furniss@dsl.pipex.com Mon Apr 19 22:08:02 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 19 Apr 2004 22:08:02 +0100 Subject: [LARTC] Making tcp start transfers slow In-Reply-To: <009201c424dc$107f4dc0$030aa8c0@t> References: <20040415122135.9743.LARTC@schmakk.dk> <4081BA2D.4080200@dsl.pipex.com> <009201c424dc$107f4dc0$030aa8c0@t> Message-ID: <40843FB2.80503@dsl.pipex.com> Roy wrote: > I just had one idea, about this. > > what if make iptables module which will make something like enlarged copy > of syn packet and send it back to the sender? > (another option would be to kill 1 or 2 ack packets for one syn packet this > whould force server to reduce speed) > > > that way htb could count upcoming packet and prepare by reducing other > connetions speed? > of course that synthetic packet will have higest possible priority since it > supposed to be appear in future so cant be shaped anyway > I don't really get this :-) > > I will try to add this functionality to my imq module next week probably. > ------------------------ > connbytes solution is not good for this, it slows down small picture loading > in web pages very much, and big downloads get even more "unused" bandwitch. > so effect is not good. expecialy that looks bad on network, when pages > become incredibly slow, but big downloads fast. Depends on lots of things I suppose - the way I have it set new connections get 256kbit - not that bad for browsing. ISTR seeing one of your scripts that did similar, IIRC using sfq with low rates. I don't quite do it like that - for a start sfq 128 queue length is too much and if you use it on ingress sfq will hash the ~4 simoultaneous connections your browser makes into one slot. I guess yours simulated a drop with the reordering when they swapped queues rather than really dropping with a short queue to get out of slowstart. SFQ causes instability every time it rehashes on ingress because of this - there is a todo in the code somewhere. I like to set perturb high. This ingress shaping with stuff made for egress is a bit tricky - but it can be tweaked a bit. Andy. From techmert@dotnet.com Mon Apr 19 22:52:39 2004 From: techmert@dotnet.com (Myrddin Emrys) Date: Mon, 19 Apr 2004 16:52:39 -0500 Subject: [LARTC] CLASSIFY target documentation Message-ID: Where can I find information on the CLASSIFY target? I saw it in some examples people posted on this list, but I cannot find it in the LARTC Howto or with Google. I need to classify packets into PRIO queues based on iptables rules. I am currently setting MARKs during classification. Unfortunately, if I understand correctly u32 cannot see marks because they're not in the packet, so my next obvious solution is to skip MARKing them and just CLASSIFY them... So, pointers to documentation on CLASSIFY would be appreciated. Also, if it is an optional feature, that means I'll have to apply a patch from the PatchoMatic, right? Myrddin -- Myrddin Emrys Technical Support Dotnet Internet Services 888-228-4665 or 924-0593 From damion@snapgear.com Tue Apr 20 00:32:55 2004 From: damion@snapgear.com (Damion de Soto) Date: Tue, 20 Apr 2004 09:32:55 +1000 Subject: [LARTC] Prioritizing on a Bridge doesn't seen to work correct, ingress does not functional In-Reply-To: References: Message-ID: <408461A7.9040104@snapgear.com> Thomas Reiß wrote: > i tried to setup up a Linuxbridge for prioritize some interactive (Citrix / https) Traffic to 1.2.3.4 on my ADSL Link, but i think it work not correct. ---snip---- > 1) a big Download becomes never more than ~ 100kbit (the most times it will be much lower). Why that ? > - Should it not have the speed of the Download Rate from the ingress qdisq ? > - The ingress qdisq counter show 0 Packets send. Why isn't this work ? ---snip--- > I think i do something wrong, but can please anybody point my to the right direction ? I couldn't make ingress policing work with bridges either. I just changed to egress shaping on both interfaces (since it's a gateway router). I vaguely recall someone else discussing this on the list recently - can't remember what the result was though. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- From roy@xxx.lt Tue Apr 20 02:16:39 2004 From: roy@xxx.lt (Roy) Date: Tue, 20 Apr 2004 04:16:39 +0300 Subject: [LARTC] Making tcp start transfers slow References: <20040415122135.9743.LARTC@schmakk.dk> <4081BA2D.4080200@dsl.pipex.com> <009201c424dc$107f4dc0$030aa8c0@t> <40843FB2.80503@dsl.pipex.com> Message-ID: <011d01c42675$22699370$030aa8c0@t> > Roy wrote: > > I just had one idea, about this. > > > > what if make iptables module which will make something like > enlarged copy > > of syn packet and send it back to the sender? > > (another option would be to kill 1 or 2 ack packets for one syn > packet this > > whould force server to reduce speed) > > > > > > that way htb could count upcoming packet and prepare by > reducing other > > connetions speed? > > of course that synthetic packet will have higest possible > priority since it > > supposed to be appear in future so cant be shaped > anyway > > > > I don't really get this :-) > ----------------------------------------------- Ok, probably I was not able to explain it quite well, but basicaly it is how to predict incomming connections and decrease speed of exsisting one before new connections will start this prediction method should be simple and easy to implement (all concept of slow start is wrong, we exactly need fast start and slow download later) > > > > I will try to add this functionality to my imq module next week > probably. > > ------------------------ > > connbytes solution is not good for this, it slows down small > picture loading > > in web pages very much, and big downloads get even more > '"'unused'"' bandwitch. > > so effect is not good. expecialy that looks bad on network, > when pages > > become incredibly slow, but big downloads fast. > > Depends on lots of things I suppose - the way I have it set new > connections get 256kbit - not that bad for browsing. ISTR seeing one of > your scripts that did similar, IIRC using sfq with low rates. I don't > quite do it like that - for a start sfq 128 queue length is too much and > if you use it on ingress sfq will hash the ~4 simoultaneous connections > your browser makes into one slot. I guess yours simulated a drop with > the reordering when they swapped queues rather than really dropping with > a short queue to get out of slowstart. > > SFQ causes instability every time it rehashes on ingress because of this > - there is a todo in the code somewhere. I like to set perturb high. > > This ingress shaping with stuff made for egress is a bit tricky - but it > can be tweaked a bit. > > Andy. > all this work well, on small number of new coonections at once , but try 20 or more at once and you will see that it is not good at all I am also using this way now, and that why I say it is not good. I dont think sfq may create any prolems, because it is basicaly same as few random fifo's > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From syrius.ml@no-log.org Tue Apr 20 01:39:14 2004 From: syrius.ml@no-log.org (syrius.ml@no-log.org) Date: Tue, 20 Apr 2004 02:39:14 +0200 Subject: [LARTC] CLASSIFY target documentation In-Reply-To: (Myrddin Emrys's message of "Mon, 19 Apr 2004 16:52:39 -0500") References: Message-ID: Myrddin Emrys writes: [...] > I need to classify packets into PRIO queues based on iptables rules. I > am currently setting MARKs during classification. Unfortunately, if I > understand correctly u32 cannot see marks because they're not in the > packet, so my next obvious solution is to skip MARKing them and just > CLASSIFY them... [...] the only documentation i know about classify is provided by patch-o-matic. You may prefer to use "handle $mark fw" as a filter to match netfilter marks. Or depending on your needs, you may only want to use u32 without netfilter marks. As you probably know there's a howto on http://lartc.org -- From fdeldegan@libero.it Tue Apr 20 14:03:10 2004 From: fdeldegan@libero.it (Francesco Del Degan) Date: Tue, 20 Apr 2004 15:03:10 +0200 Subject: [LARTC] Per-Packet Load Sharing In-Reply-To: <7C9884991ADAE0479C14F10C858BCDF5122F29@alderaan.smgtec.com> References: <7C9884991ADAE0479C14F10C858BCDF5122F29@alderaan.smgtec.com> Message-ID: <40851F8E.7080604@libero.it> Daniel Chemko wrote: >If they're both linux, would this work: > >Host0: Bridge interface #1 with interface #2. This assumes they're on >the same subnet >Host1: Bridge interface #1 with interface #2. This assumes they're on >the same subnet > >On each machine add the following: > >iptables -t mangle -m nth --every 2 --packet 0 -m mark ${MY_FIRST_ROUTE} >iptables -t mangle -m nth --every 2 --packet 1 -m mark >${MY_SECOND_ROUTE} > > Hi, do u know how to implement per-connection load-sharing over bridge into linux? thanks... From bbeers@edgeaccess.net Tue Apr 20 14:42:17 2004 From: bbeers@edgeaccess.net (Bob Beers) Date: Tue, 20 Apr 2004 09:42:17 -0400 Subject: [LARTC] Re: two WANs one LAN In-Reply-To: <408410AC.1070304@edgeaccess.net> References: <408410AC.1070304@edgeaccess.net> Message-ID: <408528B9.3070209@edgeaccess.net> Bob Beers wrote: > But I've done something wrong, obviously(?). > > I suspect a typo or other oversight, but haven't found it yet. > Ok, after re-checking the cabling ( <- error here), and re-checking the commands (verbatim from the nano.txt) it does work! (in my static ethernet setup). Great stuff! Will it be the same when I introduce the dynamic ppp0 for IFE1? The IPE1 will be a NAT'd public IP, but the GWE1 will be the P-t-P link. Also, what steps can be taken to expedite the detection and route adjustment? Is it enough to decrease the sleep time in the ping_daemon? Are there some /proc/sys/.../whatever that can/should be tweaked? Thanks for any help. -- Bob Beers From gypsy@iswest.com Wed Apr 21 04:25:48 2004 From: gypsy@iswest.com (gypsy) Date: Tue, 20 Apr 2004 20:25:48 -0700 Subject: [LARTC] Re: two WANs one LAN References: <408410AC.1070304@edgeaccess.net> <408528B9.3070209@edgeaccess.net> Message-ID: <4085E9BC.175B5B45@iswest.com> Bob Beers wrote: > Will it be the same when I introduce the dynamic ppp0 for IFE1? > The IPE1 will be a NAT'd public IP, but the GWE1 will be > the P-t-P link. If you use the correct syntax, yes. Something like ip addr add IP/MASK peer BROADCAST dev PPP0 substituting the point-to-point remote IP for BROADCAST and the correct device for PPP0 (IIRC. Sorry, it has been a long time. Regardless, the keyword here is "peer".) > Also, what steps can be taken to expedite the detection and > route adjustment? Flush the cache. Again, IIRC ip route flush but a search of the archive will turn up the correct command. If you can arrange it, a remote computer pinging each IP and messaging you when the ping fails can be used to trigger the flush. Otherwise, "ping -c 1 -I PPP0 IP" (alternate between the devices for each ping) internally is about the best you can do; ping NEVER failed for me (see below) but YMMV. > Is it enough to decrease the sleep time in the ping_daemon? No help at all. AFAIC, less often is better, not worse. > Are there some /proc/sys/.../whatever that can/should be tweaked? Nope. And nothing anywhere else, either. DGD is _very_ hard because usually the next hop is OK, it is the one after it that is bad. I don't think that even Julian can deal with "next in the route is OK but his peer is dead". In my case, the net card could speak just fine to the DSL router; it was the modem (router) that could not I/O because it was dead. Of course, DGD knew the modem was OK so it thought the link was alive... gypsy From j.vriesman@prompt.nl Wed Apr 21 10:25:59 2004 From: j.vriesman@prompt.nl (Jeroen Vriesman) Date: Wed, 21 Apr 2004 11:25:59 +0200 Subject: [LARTC] Guaranteed bandwidth per connection Message-ID: <20040421112559.7ff111ab.j.vriesman@prompt.nl> Dear all, I've got a working HTB configuration with iptables, fwmark, SFQ etc. At the moment, I can mark traffic and give it a maximum bandwidth and a minimum guaranteed bandwidth, so far so good. What I would like to do is the following: In stead of defining a min/max for a certain type of traffic (e.g. http, ftp whatever), I would like to define a "minimum guaranteed bandwidth per connection". e.g. An application connecting to port X would get 10kbit/s guaranteed, the next connection to port X would also get 10kbit/s etc. Would be something like having N (the maximum number of connections) HTB classes, and put every new connection in another class. Does anyone know how to do that? Kind regards, Jeroen Vriesman. From kim@dkik.dk Wed Apr 21 14:42:09 2004 From: kim@dkik.dk (Kim Carlsen) Date: Wed, 21 Apr 2004 15:42:09 +0200 Subject: [LARTC] Why cant I see the parent of a qdiscs? In-Reply-To: <20040421103502.32300.56298.Mailman@outpost.ds9a.nl> References: <20040421103502.32300.56298.Mailman@outpost.ds9a.nl> Message-ID: <1082554929.15673.11.camel@yam> Hi When I list all the qdisc with tc command it is not possible to see the parent of the qdisc. An example by the book. # tc qdisc add dev eth0 root handle 1: htb default 30 # tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k # tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 # tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 # tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 (taken from the lartc howto) > tc -d qdisc list qdisc sfq 30: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec qdisc sfq 20: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec qdisc sfq 10: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec qdisc htb 1: dev eth0 r2q 10 default 30 direct_packets_stat 7190 ver 3.14 if I try the same with class I get the parent of the classes > tc -d class list dev eth0 class htb 1:1 root rate 6Mbit ceil 6Mbit burst 15Kb/8 mpu 0b cburst 9463b/8 mpu 0b level 7 class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 65536 rate 5Mbit ceil 5Mbit burst 15Kb/8 mpu 0b cburst 8151b/8 mpu 0b level 0 class htb 1:20 parent 1:1 leaf 20: prio 0 quantum 39321 rate 3Mbit ceil 6Mbit burst 15Kb/8 mpu 0b cburst 9463b/8 mpu 0b level 0 class htb 1:30 parent 1:1 leaf 30: prio 0 quantum 1000 rate 1Kbit ceil 6Mbit burst 15Kb/8 mpu 0b cburst 9463b/8 mpu 0b level 0 I have looked at the tc code, and it seems that parent information should be available for qdisc. But t->tcm_parent is NULL and therefor nothing printed. Best regards Kim Carlsen * Using debian stable, iproute patched with htb3.6 From radolin@del.bg Wed Apr 21 14:54:11 2004 From: radolin@del.bg (Radoslav Kolev) Date: Wed, 21 Apr 2004 16:54:11 +0300 Subject: [LARTC] Guaranteed bandwidth per connection In-Reply-To: <20040421112559.7ff111ab.j.vriesman@prompt.nl> References: <20040421112559.7ff111ab.j.vriesman@prompt.nl> Message-ID: <40867D03.8080904@del.bg> Hi!Jeroen Vriesman wrote: >In stead of defining a min/max for a certain type of traffic (e.g. http, ftp whatever), I would like to define a "minimum guaranteed bandwidth per connection". >e.g. An application connecting to port X would get 10kbit/s guaranteed, the next connection to port X would also get 10kbit/s etc. > >Would be something like having N (the maximum number of connections) HTB classes, and put every new connection in another class. > > I don't know how you can put every new connection in a new class, but why don't you try this: Decide what will be the maximum number of connections you want to provide the guaranteed minimum and how much will it be (kbit/s). If for example we take connections to port 80, create a HTB class with rate=max_conn*guaranteed_rate and classify all traffic to port 80 to it. Then add an SFQ behind. This way if there is a fewer number of connections than you planned for each will get (class_rate/connections)kbit, which will more than the guaranteed minimun. If the number is equal to the number of connections, the SFQ will make sure that no particular connection take over the bandwitdh, and evey connection will get it's guaranteed minimum. If there are more connections than you expected, each will get an equal portion of the available bandwidth. Actually that's exactly what SFQ is designed for, to distribute the available bandwidth equally to every connection. Greets, Rado From j.vriesman@prompt.nl Wed Apr 21 15:42:49 2004 From: j.vriesman@prompt.nl (Jeroen Vriesman) Date: Wed, 21 Apr 2004 16:42:49 +0200 Subject: [LARTC] Guaranteed bandwidth per connection In-Reply-To: <40867D03.8080904@del.bg> References: <20040421112559.7ff111ab.j.vriesman@prompt.nl> <40867D03.8080904@del.bg> Message-ID: <20040421164249.60b53f68.j.vriesman@prompt.nl> Hi, well, that's exactly what I'm doing now. The only thing is that it only makes sense if there are a lot of connections, when there are only a few, they will get a lot of bandwidth, which isn't what I want. Thanks for the response. Jeroen. On Wed, 21 Apr 2004 16:54:11 +0300 Radoslav Kolev wrote: > Hi!Jeroen Vriesman wrote: > > >In stead of defining a min/max for a certain type of traffic (e.g. http, ftp whatever), I would like to define a "minimum guaranteed bandwidth per connection". > >e.g. An application connecting to port X would get 10kbit/s guaranteed, the next connection to port X would also get 10kbit/s etc. > > > >Would be something like having N (the maximum number of connections) HTB classes, and put every new connection in another class. > > > > > I don't know how you can put every new connection in a new class, but > why don't you try this: > Decide what will be the maximum number of connections you want to > provide the guaranteed minimum and how much will it be (kbit/s). > If for example we take connections to port 80, create a HTB class with > rate=max_conn*guaranteed_rate and classify all traffic to port 80 to it. > Then add an SFQ behind. This way if there is a fewer number of > connections than you planned for each will get > (class_rate/connections)kbit, which > will more than the guaranteed minimun. If the number is equal to the > number of connections, the SFQ will make sure that no particular connection > take over the bandwitdh, and evey connection will get it's guaranteed > minimum. If there are more connections than you expected, each will get > an equal portion of the available bandwidth. Actually that's exactly > what SFQ is designed for, to distribute the available bandwidth equally > to every connection. > > Greets, > Rado > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From oluap@plugon.com.br Wed Apr 21 18:05:40 2004 From: oluap@plugon.com.br (Oluap) Date: Wed, 21 Apr 2004 14:05:40 -0300 (BRT) Subject: [LARTC] iproute2 - Compile Error Message-ID: Hi, I'm tring to compile iproute2-2.4.7-now-ss020116-try.tar.bz2 whith kernel 2.6.5 and I'm getting these error: root@localhost:/home/oluap/iproute2# make make[1]: Entering directory `/home/oluap/iproute2/lib' make[1]: Nada a ser feito para `all'. make[1]: Leaving directory `/home/oluap/iproute2/lib' make[1]: Entering directory `/home/oluap/iproute2/ip' gcc ip.o ipaddress.o iproute.o iprule.o rtm_map.o iptunnel.o ipneigh.o iplink.o ipmaddr.o ipmonitor.o ipmroute.o ../lib/libnetlink.a ../lib/libutil.a -lresolv -L../lib -lnetlink -lutil -o ip iptunnel.o(.text+0x65a): In function `parse_args': : undefined reference to `__constant_htons' iptunnel.o(.text+0x678): In function `parse_args': : undefined reference to `__constant_htons' iptunnel.o(.text+0x75d): In function `parse_args': : undefined reference to `__constant_htons' iptunnel.o(.text+0x830): In function `parse_args': : undefined reference to `__constant_htons' iptunnel.o(.text+0x8eb): In function `parse_args': : undefined reference to `__constant_htons' iptunnel.o(.text+0x909): more undefined references to `__constant_htons' follow collect2: ld returned 1 exit status make[1]: ** [ip] Erro 1 make[1]: Leaving directory `/home/oluap/iproute2/ip' make: ** [all] Erro 2 Somebody could help me to solve this ? Tks Paulo Sergio Lemes Queiroz <|> Adm de Sistemas <|> +55 (19) 81168379 http://www.plugon.com.br/~oluap <|> ICQ: 127335183 From shemminger@osdl.org Wed Apr 21 19:19:29 2004 From: shemminger@osdl.org (Stephen Hemminger) Date: Wed, 21 Apr 2004 11:19:29 -0700 Subject: [LARTC] iproute2 - Compile Error In-Reply-To: References: Message-ID: <20040421111929.2efb7378@dell_ss3.pdx.osdl.net> Try this one: http://developer.osdl.org/shemminger/tcp/iproute2-042104.tar.bz2 From ml@techno.org Wed Apr 21 22:19:33 2004 From: ml@techno.org (Daniel Larsson) Date: Wed, 21 Apr 2004 21:19:33 +0000 Subject: [LARTC] Setting up dual WAN firewalling bridge Message-ID: <4086E565.3010104@techno.org> I currently have a 6mbit DSL line with a /28 block of static IP numbers. My DSL modem is in bridge mode, so I do not have a router. Because I dont want to put all my machines directly on the internet without some kind of firewall, I put a Linux machine between my DSL modem and my LAN, like this, DSL Modem --> eth0 Linux bridge/firewall/shaper eth1 --> LAN I need more bandwidth though (uplink), since I'm connected around 10 hours per day from work to home (long story short, cant install any software of my own, can't read my own e-mail etc, so I'm connecting through remote desktop home, to be able to do that), while I'm also hosting a webserver and a few other things at home which sometimes bogs down the connection so much that remote desktop is unusable. So I've ordered a second DSL line, this one with only a dynamic IP number, but other than that, the same speed etc (although it will be PPPoE with the associated overhead). Now, what I would like to do is connect the second DSL line to the Linux bridge/firewall, and automatically load balance a couple of things over line 2. First of all, I'd like to somehow double my uplink. Not knowing if this is entirely possible, but I figure that in theory it works, I could just send 50% of the outgoing packets on line 1, 50% on the other, and all incoming packets would be coming in on line 1 (since the replies would be coming to the source address, the public IP that is on line 1). If my ISP is filtering packets with an incorrect source address or something I'm in trouble, but if they don't, it should work right? If I can't get this to work, I'm happy with just connecting to the dynamic IP whenever I need to RDP/VNC into my machine at home, so it's not critical, but nice, to get the double uplink speed. The second thing I'd like to do is load balance HTTP connections (outgoing) over both links (and possibly other things like BitTorrent etc), so I'd get around 10mbit for downloads. I figure this can be done by NATing line 2 with my public IP numbers on the inside, and somehow just select a different gateway for connections (packets?) on a roundrobin basis or something like that (or even better, by putting the new connections on the line with the least traffic at the moment). It is important that I can do this for only HTTP (and select other applications). I figure a workaround for this, if it isn't easily implementable, would be to do transparent WWW proxying with Squid or something similar, and somehow send half the connections on one interface and half on the other... in case the kernel can't do it. I realize, of course, that to get 10mbit downloads, I'll need to have multiple connections open to the server I download from (unless I'm missing something). I'm new at this, and don't really know where to start. What complicates it even more for me is the fact that my box will be BOTH a bridge and router in this scenario. Any pointers etc will be very much appreciated. /dml From lartc@schmakk.dk Thu Apr 22 01:28:31 2004 From: lartc@schmakk.dk (Patrick Petersen) Date: Thu, 22 Apr 2004 02:28:31 +0200 Subject: [LARTC] Making tcp start transfers slow In-Reply-To: <4081BA2D.4080200@dsl.pipex.com> References: <20040415122135.9743.LARTC@schmakk.dk> <4081BA2D.4080200@dsl.pipex.com> Message-ID: <20040422022425.52B5.LARTC@schmakk.dk> Sorry for the long response time. On Sun, 18 Apr 2004 00:13:49 +0100, Andy Furniss wrote: > I sortof workaround this using the connbytes netfilter patch to make the > first 80k of new connections go into a short queue limited to 1/3 - 1/2 > of my downstream bandwidth. I will try this soon.. I recently screwed my kernel over bad with patch-o-matic, so its fixing time at the moment :) > Ahh bittorrent - this is a special case. It uses full duplex tcp - so > may break some upstream shapers, you can assume that a fair number of > your peers have flooded modem buffers - so there could be quite a few > "unstoppable" packets headed your way. The worse thing about it, though > is that it runs it's own algorithm on allready open tcps - so existing > connections may go back into slowstart. Thats pretty bad.. But if i get this working, even with bittorrent, i guess that means it will probably work with anything! :) > > Would it be possible to lower the default window size, and thereby > > making tcp start up slower, or would this just lower the overall speed? > > It could help, but may also give you less of a share of a given > uploaders bandwidth. Reducing MTU may also help (if you run BT on linux > it may reduce rwin for you aswell). > > I don't think you can catch all BT traffic by marking the BT ports, I > see ipp2p - can you do it with this or maybe do per IP fairness for bulk > traffic? Im fortunate enough to be able to run a small network with only a few people, so theres no real bad things with people doing whatever they can to cheat. Also, ipp2p should catch torrent connections, and seems to be doing so. > Be carefull about priorotising acks - don't all TCP packets after syn > have ack set. Being lazy on a home setup I get away with giving small > packets priority - saves alot of marking :-) > > For ingress shaping - I find it nicer to shape per IP with htb and use > esfq classic to get per tcp fairness rather than esfq on dst which is > going to effectively make many bittorrent connections go into a FIFO, > which could make for more burstiness. I'll make a note, but shouldnt esfq make things more or less fair no matter how much traffic one client has over another? -- Patrick Petersen From rusko@sunsite.mine.nu Thu Apr 22 08:28:14 2004 From: rusko@sunsite.mine.nu (Martin Rusko) Date: Thu, 22 Apr 2004 09:28:14 +0200 Subject: [LARTC] Accepting packets with frame dest.addr. ff:ff:ff:ff:ff:ff for routing Message-ID: <4087740E.5050008@sunsite.mine.nu> Hi all, do anybody know, whether is it possible to route packets incoming to ethernet interface as broadcasts? ~~~~~|WirelessDevice/WD|-----eth0-|LinuxRouter/RT|-eth1---(10.18.63.0/24) tcpdump: listening on eth0 0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: icmp: echo request (DF) 0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: icmp: echo request (DF) Please notice, that echo request packets are in ethernet frames, heading to broadcast address (ff:ff:ff:ff:ff:ff). Linux kernel seems to be, that refuse to route such packets (not intented for the MAC address of eth0 interface). But that interface received that packets, as seen in running tcpdump session. When that frames has "correct" MAC addresses, I mean destination is not a broadcast address, the same packet (source IP, destination IP) is routed without any problem. Do you have any explanation, for this? Or better, does any linux networking guru know some magic, how to make linux kernel start routing also broadcasted packets? Any help will be much appreciated. Also, when more info, why I see such packets is needed, I'm ready to serve. Best regards mARTin -- Martin Rusko PhD student Department of Automation and Measurement Faculty of Mechanical Engineering Slovak University of Technology -- E-mail: rusko@sunsite.mine.nu Web: http://sunsite.mine.nu/~rusko -- motto: We are Microsoft! Resistance is futile. Open your source code and prepare for assimilation. From simon.oosthoek@ti-wmc.nl Thu Apr 22 13:15:48 2004 From: simon.oosthoek@ti-wmc.nl (Simon Oosthoek) Date: Thu, 22 Apr 2004 14:15:48 +0200 Subject: [LARTC] ingress policing based on source address? Message-ID: <4087B774.4040404@ti-wmc.nl> Hi all I'm new to this list, but not exactly to iproute stuff. I'd like to solve a specific problem with bandwidth coming from different external sources towards the internal network (also the other way around, but I figure that's not so much a problem, since that is egress traffic shaping). The network looks like this: internet ------ ISP-------[shaping/router] | | +- net1 -------- host1 mirrors host2 +- net2 in text: we connect to the internet via an ISP, where we also have an externally accessible host (host2). Internally we use NAT and several subnets. We have a 100Mbit/s connection to the ISP, but we only pay for 1Mbit/s. So in order to keep our traffic within the agreed parameters, we need to police our incoming and outgoing traffic. However the traffic from and to the ISP and host2 doesn't have to be policed. For our external traffic there's not much problem to shape the traffic in the egress queues (using HTB and TBF/SFQ stuff). This is well described in the LARTC howto documentation. My problem is with the incoming traffic. The examples in the howto don't go very much into this and from what I understand the ingress queue is much less advanced than the egress queue. I read something about an intermediate queue, but I don't understand how that works (yet). My question is whether this is something I can do using the ingress queue, somehow defining filter rules with different queue associated with that, or whether someone has experience with a similar configuration. If this is not possible, I might be able to solve it differently by adding another host with just 2 interfaces and using only egress queues, but I'd prefer limiting my solution to a single host. Thanks in advance Simon PS, if this is the second time you get this message, I was too impatient and sent the first one before my confirmation was in.... From simon.oosthoek@ti-wmc.nl Thu Apr 22 13:04:24 2004 From: simon.oosthoek@ti-wmc.nl (Simon Oosthoek) Date: Thu, 22 Apr 2004 14:04:24 +0200 Subject: [LARTC] ingress policing based on source address? Message-ID: <4087B4C8.6010008@ti-wmc.nl> Hi all I'm new to this list, but not exactly to iproute stuff. I'd like to solve a specific problem with bandwidth coming from different external sources towards the internal network (also the other way around, but I figure that's not so much a problem, since that is egress traffic shaping). The network looks like this: internet ------ ISP-------[shaping/router] | | +- net1 -------- host1 mirrors host2 +- net2 in text: we connect to the internet via an ISP, where we also have an externally accessible host (host2). Internally we use NAT and several subnets. We have a 100Mbit/s connection to the ISP, but we only pay for 1Mbit/s. So in order to keep our traffic within the agreed parameters, we need to police our incoming and outgoing traffic. However the traffic from and to the ISP and host2 doesn't have to be policed. For our external traffic there's not much problem to shape the traffic in the egress queues (using HTB and TBF/SFQ stuff). This is well described in the LARTC howto documentation. My problem is with the incoming traffic. The examples in the howto don't go very much into this and from what I understand the ingress queue is much less advanced than the egress queue. I read something about an intermediate queue, but I don't understand how that works (yet). My question is whether this is something I can do using the ingress queue, somehow defining filter rules with different queue associated with that, or whether someone has experience with a similar configuration. If this is not possible, I might be able to solve it differently by adding another host with just 2 interfaces and using only egress queues, but I'd prefer limiting my solution to a single host. Thanks in advance Simon From mreichman@virage.com Thu Apr 22 14:02:59 2004 From: mreichman@virage.com (Marc Reichman) Date: Thu, 22 Apr 2004 09:02:59 -0400 Subject: [LARTC] wondershaper, host *exclusion*? Message-ID: <4087C283.2090504@virage.com> Hi, I really like the wondershaper script, it works very well for me. My question is this. Is there a way to get certain remote hosts to be excluded from the shaping? I ask because I don't have my box connected directly through the net. It sits behind a nat device, and has ports forwarded in for services. I'd like to limit the ports and services, but only to things going outside of my local network. Is there a way I can leave most things as-is, and just say "don't affect any packets that are involved with 192.168.0.*"? Thanks, Marc From mreichman@virage.com Thu Apr 22 14:33:36 2004 From: mreichman@virage.com (Marc Reichman) Date: Thu, 22 Apr 2004 09:33:36 -0400 Subject: [LARTC] wondershaper, host *exclusion*? In-Reply-To: <4087C82D.7040202@ti-wmc.nl> References: <4087C283.2090504@virage.com> <4087C82D.7040202@ti-wmc.nl> Message-ID: <4087C9B0.7080104@virage.com> I will research in the howto, but I must say a lot of the terminology goes over my head. To summarize, my steps are: 1. create a queue with no bw limitations 2. create a filter for the 192.168.0.0/24 and point it at that queue. Correct? -Marc Simon Oosthoek wrote: > Marc Reichman wrote: > >> Hi, >> >> I really like the wondershaper script, it works very well for me. My >> question is this. Is there a way to get certain remote hosts to be >> excluded from the shaping? I ask because I don't have my box connected >> directly through the net. It sits behind a nat device, and has ports >> forwarded in for services. I'd like to limit the ports and services, but >> only to things going outside of my local network. >> >> Is there a way I can leave most things as-is, and just say "don't affect >> any packets that are involved with 192.168.0.*"? > > > I'm not sure I understand your topology, but I figure you're behind a > NATting adsl/cable modem with a built-in switch? > > You should probably add a separate queue which is not limited in > bandwidth and create a filter for ip range 192.168.0.0/24 to be directed > to that queue. The other traffice should be directed to the other queue > which is standard in wshaper. I don't have specific code-lines, but > you're probably helped more anyway if you find out how to do this from > the howto ;-) > > Cheers > > Simon > > > From simon.oosthoek@ti-wmc.nl Thu Apr 22 14:42:36 2004 From: simon.oosthoek@ti-wmc.nl (Simon Oosthoek) Date: Thu, 22 Apr 2004 15:42:36 +0200 Subject: [LARTC] wondershaper, host *exclusion*? In-Reply-To: <4087C9B0.7080104@virage.com> References: <4087C283.2090504@virage.com> <4087C82D.7040202@ti-wmc.nl> <4087C9B0.7080104@virage.com> Message-ID: <4087CBCC.7020604@ti-wmc.nl> Marc Reichman wrote: > I will research in the howto, but I must say a lot of the terminology > goes over my head. > > To summarize, my steps are: > 1. create a queue with no bw limitations > 2. create a filter for the 192.168.0.0/24 and point it at that queue. > > Correct? yes, however, now I think about it some more, you probably have a similar problem as myself (see my other (double) posting). The problem is that you want to shape the traffic in 2 directions, but the ingress queue (interface _before_ routing) is less flexible to manage than the egress queue (interface _after_ routing). On the egress side, it's quite easy to add queues and make filters to it, but I'm not so sure about the ingress side. It might be possible to simply bypass the ingress bandwidth limiting queue for a certain ip-range (so you then don't have to add another queue for that). But if you want (like I do) to apply different restrictions to certain remote addresses, than the default, I don't have answers for that (only questions ;-) Cheers Simon From simon.oosthoek@ti-wmc.nl Thu Apr 22 14:27:09 2004 From: simon.oosthoek@ti-wmc.nl (Simon Oosthoek) Date: Thu, 22 Apr 2004 15:27:09 +0200 Subject: [LARTC] wondershaper, host *exclusion*? In-Reply-To: <4087C283.2090504@virage.com> References: <4087C283.2090504@virage.com> Message-ID: <4087C82D.7040202@ti-wmc.nl> Marc Reichman wrote: > Hi, > > I really like the wondershaper script, it works very well for me. My > question is this. Is there a way to get certain remote hosts to be > excluded from the shaping? I ask because I don't have my box connected > directly through the net. It sits behind a nat device, and has ports > forwarded in for services. I'd like to limit the ports and services, but > only to things going outside of my local network. > > Is there a way I can leave most things as-is, and just say "don't affect > any packets that are involved with 192.168.0.*"? I'm not sure I understand your topology, but I figure you're behind a NATting adsl/cable modem with a built-in switch? You should probably add a separate queue which is not limited in bandwidth and create a filter for ip range 192.168.0.0/24 to be directed to that queue. The other traffice should be directed to the other queue which is standard in wshaper. I don't have specific code-lines, but you're probably helped more anyway if you find out how to do this from the howto ;-) Cheers Simon From mreichman@virage.com Thu Apr 22 14:53:42 2004 From: mreichman@virage.com (Marc Reichman) Date: Thu, 22 Apr 2004 09:53:42 -0400 Subject: [LARTC] wondershaper, host *exclusion*? In-Reply-To: <4087CBCC.7020604@ti-wmc.nl> References: <4087C283.2090504@virage.com> <4087C82D.7040202@ti-wmc.nl> <4087C9B0.7080104@virage.com> <4087CBCC.7020604@ti-wmc.nl> Message-ID: <4087CE66.5060805@virage.com> I have no real interest in doing anything with specific remote hosts, I just want to bypass the limiting for the certain IP range. I imagine I'd do this by adding something referencing 192.168.0.0/24 to an existing line in the script? Have an idea of which? -Marc Simon Oosthoek wrote: > Marc Reichman wrote: > >> I will research in the howto, but I must say a lot of the terminology >> goes over my head. >> >> To summarize, my steps are: >> 1. create a queue with no bw limitations >> 2. create a filter for the 192.168.0.0/24 and point it at that queue. >> >> Correct? > > > yes, however, now I think about it some more, you probably have a > similar problem as myself (see my other (double) posting). The problem > is that you want to shape the traffic in 2 directions, but the ingress > queue (interface _before_ routing) is less flexible to manage than the > egress queue (interface _after_ routing). > > On the egress side, it's quite easy to add queues and make filters to > it, but I'm not so sure about the ingress side. It might be possible to > simply bypass the ingress bandwidth limiting queue for a certain > ip-range (so you then don't have to add another queue for that). But if > you want (like I do) to apply different restrictions to certain remote > addresses, than the default, I don't have answers for that (only > questions ;-) > > Cheers > > Simon > > > From simon.oosthoek@ti-wmc.nl Thu Apr 22 15:08:27 2004 From: simon.oosthoek@ti-wmc.nl (Simon Oosthoek) Date: Thu, 22 Apr 2004 16:08:27 +0200 Subject: [LARTC] wondershaper, host *exclusion*? In-Reply-To: <4087CE66.5060805@virage.com> References: <4087C283.2090504@virage.com> <4087C82D.7040202@ti-wmc.nl> <4087C9B0.7080104@virage.com> <4087CBCC.7020604@ti-wmc.nl> <4087CE66.5060805@virage.com> Message-ID: <4087D1DB.7050409@ti-wmc.nl> Marc Reichman wrote: > I have no real interest in doing anything with specific remote hosts, > I just want to bypass the limiting for the certain IP range. I imagine > I'd do this by adding something referencing 192.168.0.0/24 to an > existing line in the script? Have an idea of which? > tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src \ 192.168.0.0/24 police rate 100mbit burst 10k continue flowid :1 try adding the above line(s) to the wondershaper script, maybe that will do it? /Simon From mreichman@virage.com Thu Apr 22 15:15:05 2004 From: mreichman@virage.com (Marc Reichman) Date: Thu, 22 Apr 2004 10:15:05 -0400 Subject: [LARTC] wondershaper, host *exclusion*? In-Reply-To: <4087D1DB.7050409@ti-wmc.nl> References: <4087C283.2090504@virage.com> <4087C82D.7040202@ti-wmc.nl> <4087C9B0.7080104@virage.com> <4087CBCC.7020604@ti-wmc.nl> <4087CE66.5060805@virage.com> <4087D1DB.7050409@ti-wmc.nl> Message-ID: <4087D369.4090906@virage.com> I added, changing eth0 to the dev variable. I'll have to find out when i get home if it's going to work right for local stuff. Thanks for your help. -Marc Simon Oosthoek wrote: > Marc Reichman wrote: > >> I have no real interest in doing anything with specific remote hosts, >> I just want to bypass the limiting for the certain IP range. I imagine >> I'd do this by adding something referencing 192.168.0.0/24 to an >> existing line in the script? Have an idea of which? >> > tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src \ > 192.168.0.0/24 police rate 100mbit burst 10k continue flowid :1 > > try adding the above line(s) to the wondershaper script, maybe that will > do it? > > /Simon > > From wasson@azxws.com Thu Apr 22 18:42:01 2004 From: wasson@azxws.com (Tony Wasson) Date: Thu, 22 Apr 2004 10:42:01 -0700 Subject: [LARTC] Accepting packets with frame dest.addr. ff:ff:ff:ff:ff:ff for routing In-Reply-To: <4087740E.5050008@sunsite.mine.nu> References: <4087740E.5050008@sunsite.mine.nu> Message-ID: <408803E9.4060902@azxws.com> Martin Rusko wrote: > Hi all, > > do anybody know, whether is it possible to route packets incoming to > ethernet interface as broadcasts? > > ~~~~~|WirelessDevice/WD|-----eth0-|LinuxRouter/RT|-eth1---(10.18.63.0/24) > > tcpdump: listening on eth0 > 0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: icmp: > echo request (DF) > 0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: icmp: > echo request (DF) > > Please notice, that echo request packets are in ethernet frames, heading > to broadcast address (ff:ff:ff:ff:ff:ff). > > Linux kernel seems to be, that refuse to route such packets (not > intented for the MAC address of eth0 interface). But that interface > received that packets, as seen in running tcpdump session. When that > frames has "correct" MAC addresses, I mean destination is not a > broadcast address, the same packet (source IP, destination IP) is routed > without any problem. > > Do you have any explanation, for this? Or better, does any linux > networking guru know some magic, how to make linux kernel start routing > also broadcasted packets? > > Any help will be much appreciated. Also, when more info, why I see such > packets is needed, I'm ready to serve. > > Best regards > > mARTin > Hi Martin, Routers are usually installed to seperate broadcast domains. They really don't *LIKE* to forward broadcasts. I am imagining that this is a really broken TCP/IP stack you are working with. Just for kicks, do you see ARPs right before these echo requests? If so, proxy ARP would help deliver your traffic. Can you reveal more about what device is sending this interesting traffic? You may be able to set an ARP entry for 10.18.63.249 on the crazy network device as the linux box and "force" things to work. Tony Wasson From gregoriandres@yahoo.com.ar Thu Apr 22 18:57:48 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Thu, 22 Apr 2004 14:57:48 -0300 Subject: [LARTC] IMQ compile procedure ?? Message-ID: Hi Guys, I'm trying to compile IMQ with kernel-2.4.26 and iptables-1.2.9 and I want to know is this procedure is correct: ---------------------------------------- - In Kernel 2.4.26 Directory (/usr/src/linux) # cd /usr/src/linux # wget http://www.linuximq.net/patchs/linux-2.4.24-imq.diff # patch -p1 < linux-2.4.24-imq.diff - In Patch O Matic Directory (/usr/local/src/Patch-o-Matic) # cd /usr/local/src/Patch-o-Matic # wget http://www.linuximq.net/patchs/pom-20030625.diff # patch -p1 < pom-20030625.diff - In IP Tables 1.2.9 Directory ******************************************************* HERE (I DON'T KNOW WHY), I NEED TO CHANGE DIRECTORY NAME: ******************************************************* # mv /usr/local/src/iptables-1.2.9 mv /usr/local/src/userspace - Patch o Matic in action... # cd /usr/local/src/Patch-o-Matic # ./runme --batch userspace/IMQ.patch # ./runme --batch userspace/IMQ.patch.ipv6 # chmod 0755 ../userspace/extensions/.IMQ* # ./runme userspace/IMQ.patch # ./runme --batch extra/CONNMARK.patch - Next, compile Kernel.... - Next, recompile IP Tables... and that is all (?) Andres... From James"

folks,

Sorry to disturb you with such a basic question, but I am new to bandwidth control , shaper etc...  I tried reading some doc about it, but couldn´t apply them to solve my (following problem):

I have this..

[internet]------[eth0][linux box][eth1]--------[my lan]


ADSL (256k)
eth0: 200.200.200.200    <- ex.
eth1: 192.168.7.254  lan 192.168.7.0/24

I want, ex.: that user in my lan (192.168.7.10), ain´t trash my whole bandwidth with kazaa, pop, smtp whatever... so, I want this one to download only 15kps...  
What could I do ?



________________________________________________
Message from N3T Webmail - ver.2.7
From rusko@sunsite.mine.nu Fri Apr 23 09:50:21 2004 From: rusko@sunsite.mine.nu (Martin Rusko) Date: Fri, 23 Apr 2004 10:50:21 +0200 Subject: [LARTC] Accepting packets with frame dest.addr. ff:ff:ff:ff:ff:ff for routing In-Reply-To: <408803E9.4060902@azxws.com> References: <4087740E.5050008@sunsite.mine.nu> <408803E9.4060902@azxws.com> Message-ID: <4088D8CD.0@sunsite.mine.nu> Hi Tony, that traffic is generated by a wireless access point (Prism GT chipset, 802.11g) and when it is used as "client bridge" it acts as a proxy ARP device. I think, there is a bug in a firmware, because it doesn't do an ARP request for IP addresses which it doesn't know and simply send IP packet in broadcasted ethernet frame. This bug makes also proxy ARP on router (which is right behind that client bridge) rather problematic, but not impossible (under current IP addressing scheme). Temporarily, I workarounded this by Frame Diverter (which replace incorrect ff:ff... address with MAC address of router's interface) and now IP stack in kernel happily routes all packets. After a new firmware release (I hope, that there will be any) I will switch to proxy arp. Thank you very much. Best Regards mARTin Tony Wasson wrote: > Martin Rusko wrote: > >> Hi all, >> >> do anybody know, whether is it possible to route packets incoming to >> ethernet interface as broadcasts? >> >> ~~~~~|WirelessDevice/WD|-----eth0-|LinuxRouter/RT|-eth1---(10.18.63.0/24) >> >> tcpdump: listening on eth0 >> 0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: >> icmp: echo request (DF) >> 0:a:e6:ac:e8:7a ff:ff:ff:ff:ff:ff 98: 192.168.7.11 > 10.18.63.249: >> icmp: echo request (DF) >> >> Please notice, that echo request packets are in ethernet frames, >> heading to broadcast address (ff:ff:ff:ff:ff:ff). >> >> Linux kernel seems to be, that refuse to route such packets (not >> intented for the MAC address of eth0 interface). But that interface >> received that packets, as seen in running tcpdump session. When that >> frames has "correct" MAC addresses, I mean destination is not a >> broadcast address, the same packet (source IP, destination IP) is >> routed without any problem. >> >> Do you have any explanation, for this? Or better, does any linux >> networking guru know some magic, how to make linux kernel start >> routing also broadcasted packets? >> >> Any help will be much appreciated. Also, when more info, why I see >> such packets is needed, I'm ready to serve. >> >> Best regards >> >> mARTin >> > > Hi Martin, > > Routers are usually installed to seperate broadcast domains. They really > don't *LIKE* to forward broadcasts. I am imagining that this is a really > broken TCP/IP stack you are working with. Just for kicks, do you see > ARPs right before these echo requests? If so, proxy ARP would help > deliver your traffic. > > Can you reveal more about what device is sending this interesting > traffic? You may be able to set an ARP entry for 10.18.63.249 on the > crazy network device as the linux box and "force" things to work. > > Tony Wasson -- Martin Rusko PhD student Department of Automation and Measurement Faculty of Mechanical Engineering Slovak University of Technology -- E-mail: rusko@sunsite.mine.nu Web: http://sunsite.mine.nu/~rusko -- motto: We are Microsoft! Resistance is futile. Open your source code and prepare for assimilation. From russ@madhaus.cns.utoronto.ca Fri Apr 23 14:22:59 2004 From: russ@madhaus.cns.utoronto.ca (Russell P. Sutherland) Date: Fri, 23 Apr 2004 09:22:59 -0400 Subject: [LARTC] routing policy question Message-ID: <20040423132259.GB15173@madhaus.cns.utoronto.ca> I'm attempting to perform some class based routing using Linux in combination with quagga/zebra. My current experience is with FreeBSD/ipfw/quagga. I've read most of the LARTC documentation as well Martin Brown's Guide to IP Layer Network Admin. Here's the basics of my set up: |- R1 <-> ISP1 R0-| |- R2 <-> ISP2 | |- R3 <-> ISP3 All outgoing traffic from R0 to the Internet goes to R3, which performs the routing decisions. So all of my questions correspond to policies that I need to configure on R3 using netfilter and iptables. R3 has 8k specific routes (via BGP) from ISP3 and has its default set to the directly attached network connection of R2 Here are the basic rules/policies: 1. All traffic from R0 with source address matching N1 should go have as its next hop R1. 2. All other traffic from R0 with source address matching N2 should be forwarded to ISP3 if the destination address matches any of the 8k routes otherwise get forwarded to R2 3. All remaining traffic from R0 should be forwarded to ISP3 if the destination address matches any of the 8k routes otherwise get forwarded to R1 I can accomplish rule 1 easily by adding a routing table with say priority 100 into the routing policy database that has a rule that says if src matches N1 then set the default to be R1. But I'm not as certain on how to implement policies 2 and 3, given that I need to traverse the "main" routing table first and then have each category of traffic have a different default. Would it be possible to set the ToS in the incoming traffic at the mangle/PREROUTING stage and then have two defaults in the main routing table, one that matches policy 2 and the other policy 3? -- Russell P. Sutherland Email: russ @ madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Voice: +1.416.978.0470 University of Toronto Fax: +1.416.978.6620 Toronto, ON M5S 1C1 WWW: http://madhaus.cns.utoronto.ca/~russ CANADA From blackhawk@ivanhawkes.com Fri Apr 23 19:08:45 2004 From: blackhawk@ivanhawkes.com (Mr Ivan Hawkes) Date: Fri, 23 Apr 2004 19:08:45 +0100 Subject: [LARTC] boring question In-Reply-To: <20040422214238.8E57A44CB@outpost.ds9a.nl> References: <20040422214238.8E57A44CB@outpost.ds9a.nl> Message-ID: <40895BAD.2020902@ivanhawkes.com> James wrote: > folks, > > Sorry to disturb you with such a basic question, but I am new to > bandwidth control , shaper etc... I tried reading some doc about it, > but couldn´t apply them to solve my (following problem): > > I have this.. > > [internet]------[eth0][linux box][eth1]--------[my lan] > > > ADSL (256k) > eth0: 200.200.200.200 <- ex. > eth1: 192.168.7.254 lan 192.168.7.0/24 > > I want, ex.: that user in my lan (192.168.7.10), ain´t trash my whole > bandwidth with kazaa, pop, smtp whatever... so, I want this one to > download only 15kps... > What could I do ? Hi James, since I'm a noob on this list I'll answer the question to save the head guys typing. You have almost the exact same setup as I have, except my Linux box is a dedicated Smoothwall which I added QoS to. I'm going to assume you want to keep that box as a normal multi-purpose box rather than reformat it to Smoothwall :-) I wrote a set of instructions and a pretty decent script based on Wondershaper which will help you. Both are on my webserver at the following address: http://www.ivan.hawkes.tv/contentitem.aspx?id=59&ciid=402 There are a couple of easy to follow articles there which I put together based on the harder to read but more comprehensive stuff held on lartc. Now, my adsl-shaper script isn't going to do what you want since I took out the IP based stuff since it wasn't relevant to me, so just follow the general instructions but use wshaper as your shaping script instead since it does support IP based limiting. You will need to customise the script to get your IP addresses in, but basically what you are looking to do is simply put him into his own queueing discipline with a max bandwidth limit attached, and let all other traffic go through some other qdisc. It is important to note that this generally works well for outgoing traffic but is not particularly effective against incoming traffic since that is *pushed* onto your machine and it has no way to control this. If your flatmate is maxing your bandwidth with mp3 downloads maybe a quick slap might sort him/her out ;-> -- http://www.ivanhawkes.com | ICQ: 173-392-038 From grant@janrain.com Fri Apr 23 20:58:47 2004 From: grant@janrain.com (Grant Monroe) Date: Fri, 23 Apr 2004 12:58:47 -0700 Subject: [LARTC] IPSec tunnel problem Message-ID: <40897577.7050606@janrain.com> I am attempting to setup a simple network-to-network IPSec tunnel. The tunnel appears to be setup correctly because I can make connections between the networks and tcpdump shows esp packets going between the two gateways. My problem is that I cannot make connections from one gateway to the other through the tunnel. I think that this is a routing issue. Here is some more info about my network: 192.168.1.1 10.0.0.6 10.0.0.9 192.168.2.1 192.168.1.7 +-----------+ +-----------+ 192.168.2.14 +-----+ | Gateway | | Gateway | +-----+ | Foo | -- 192.168.1.0/24 -- | A | -- 10.0.0.0/24 -- | B | -- 192.168.2.0/24 -- | Bar | +-----+ +-----------+ +-----------+ +-----+ So, for example, Foo can ping Bar, but Gateway A can't ping Gateway B's private interface or Bar. Thanks for any help. Grant Monroe From andy.furniss@dsl.pipex.com Sat Apr 24 00:33:37 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sat, 24 Apr 2004 00:33:37 +0100 Subject: [LARTC] ingress policing based on source address? In-Reply-To: <4087B774.4040404@ti-wmc.nl> References: <4087B774.4040404@ti-wmc.nl> Message-ID: <4089A7D1.6090103@dsl.pipex.com> Simon Oosthoek wrote: > Hi all > > I'm new to this list, but not exactly to iproute stuff. > > I'd like to solve a specific problem with bandwidth coming from > different external sources towards the internal network (also the other > way around, but I figure that's not so much a problem, since that is > egress traffic shaping). > > The network looks like this: > > internet ------ ISP-------[shaping/router] > | | +- net1 -------- host1 > mirrors host2 +- net2 > > in text: we connect to the internet via an ISP, where we also have an > externally accessible host (host2). Internally we use NAT and several > subnets. > > We have a 100Mbit/s connection to the ISP, but we only pay for 1Mbit/s. > So in order to keep our traffic within the agreed parameters, we need to > police our incoming and outgoing traffic. However the traffic from and > to the ISP and host2 doesn't have to be policed. > > For our external traffic there's not much problem to shape the traffic > in the egress queues (using HTB and TBF/SFQ stuff). This is well > described in the LARTC howto documentation. > > My problem is with the incoming traffic. The examples in the howto don't > go very much into this and from what I understand the ingress queue is > much less advanced than the egress queue. I read something about an > intermediate queue, but I don't understand how that works (yet). > > My question is whether this is something I can do using the ingress > queue, somehow defining filter rules with different queue associated > with that, or whether someone has experience with a similar configuration. > > If this is not possible, I might be able to solve it differently by > adding another host with just 2 interfaces and using only egress queues, > but I'd prefer limiting my solution to a single host. You could use IMQ www.linuximq.net to save you using another box, but the way you get your bandwidth (ie. no real bottleneck) may make it suitable for just the "dumb" ingress policer. Maybe you have good reasons to want to classify/shape ingress in a complicated way. Andy. From andy.furniss@dsl.pipex.com Sat Apr 24 00:11:32 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sat, 24 Apr 2004 00:11:32 +0100 Subject: [LARTC] Making tcp start transfers slow In-Reply-To: <20040422022425.52B5.LARTC@schmakk.dk> References: <20040415122135.9743.LARTC@schmakk.dk> <4081BA2D.4080200@dsl.pipex.com> <20040422022425.52B5.LARTC@schmakk.dk> Message-ID: <4089A2A4.3040200@dsl.pipex.com> Patrick Petersen wrote: > Sorry for the long response time. > > On Sun, 18 Apr 2004 00:13:49 +0100, Andy Furniss wrote: > > >>I sortof workaround this using the connbytes netfilter patch to make the >>first 80k of new connections go into a short queue limited to 1/3 - 1/2 >>of my downstream bandwidth. > > > I will try this soon.. I recently screwed my kernel over bad with > patch-o-matic, so its fixing time at the moment :) One possible problem - I don't think connbytes will patch with connmark (which IIRC ipp2p uses). I have been told that it is possible to get them to work, but patch will fail as they both change the same struct, so it's a do it by hand job... > > >>Ahh bittorrent - this is a special case. It uses full duplex tcp - so >>may break some upstream shapers, you can assume that a fair number of >>your peers have flooded modem buffers - so there could be quite a few >>"unstoppable" packets headed your way. The worse thing about it, though >>is that it runs it's own algorithm on allready open tcps - so existing >>connections may go back into slowstart. > > > Thats pretty bad.. But if i get this working, even with bittorrent, i > guess that means it will probably work with anything! :) LOL - I think your idea about reducing rwin may help - easy on a small setup where you have control. > > >>>Would it be possible to lower the default window size, and thereby >>>making tcp start up slower, or would this just lower the overall speed? >> >>It could help, but may also give you less of a share of a given >>uploaders bandwidth. Reducing MTU may also help (if you run BT on linux >>it may reduce rwin for you aswell). >> >>I don't think you can catch all BT traffic by marking the BT ports, I >>see ipp2p - can you do it with this or maybe do per IP fairness for bulk >>traffic? > > > Im fortunate enough to be able to run a small network with only a few > people, so theres no real bad things with people doing whatever they can > to cheat. Also, ipp2p should catch torrent connections, and seems to be > doing so. Yes - so you don't need to mark all those ports then. > > >>Be carefull about priorotising acks - don't all TCP packets after syn >>have ack set. Being lazy on a home setup I get away with giving small >>packets priority - saves alot of marking :-) >> >>For ingress shaping - I find it nicer to shape per IP with htb and use >>esfq classic to get per tcp fairness rather than esfq on dst which is >>going to effectively make many bittorrent connections go into a FIFO, >>which could make for more burstiness. > > > I'll make a note, but shouldnt esfq make things more or less fair no > matter how much traffic one client has over another? Yes esfq on dst will make things fair per IP address - but in the case of ingress with the many tcps that BT uses dropping is important to get the sender to back off. Esfq on dst is not really a fairness queue any more WRT individual tcp connections, it may not make much difference, but if you use htb for per IP fairness and esfq classic, then the drops are a bit more likely to get at the most active connections. I modified esfq to drop from the head of a slot rather than the end - which in theory should make things slightly nicer and changed hash to use dst port. I really ought to make them into a switches (when I work out how) I also intend to patch with the change to sfq that was recently talked about on here. If it looks OK I'll put it up on my webspace sometime - I don't really know what I am doing though :-) For us small bandwidth users a R(real)FQ would be nice - (e)sfq is OK but it often hashes into the same slot and perturb causes packet reordering which hurts more when used for ingress. Andy. From trapni@surakware.net Sat Apr 24 02:23:55 2004 From: trapni@surakware.net (trapni@surakware.net) Date: Sat, 24 Apr 2004 03:23:55 +0200 (CEST) Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router Message-ID: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> Hi all, this is really not really very easy to understand, or, to get in. Well, I've the following configuration on the router box: LAN - interface: eth0 - network: 192.168.2.5/24 - bandwidth: 100Mbit/s INET interface - interface: ppp0 - network: .dynamic.ip./0 - bandwidth: DOWN=1536kbit/s and UP=256kbit/s the LAN interface is to serve 6 other clients with internet and local services. My goal NOW was, or is, to garrantie each client with a fair amount of bandwith for both, up and down. That is, each client inside the LAN should get garrantied - PER_CLIENT_DOWN=256kbit/s - and PER_CLIENT_UP=42kbit/s Each unused bandwith may be shared between them. The LAN clients have IP pool: 192.168.2.2-192.168.2.4, and 192.168.2.6-192.168.2.8 But how exactly do I now express my wish in TCNG syntax? Some kind of pseudo code like below... device ppp0 { input ( 1536kbit/s ) { // upstream class ( 256kbit/s; may borrow ) { catch ip 192.168.2.2; } class ( 256kbit/s; may borrow ) { catch ip 192.168.2.3; } class ( 256kbit/s; may borrow ) { catch ip 192.168.2.4; } class ( 256kbit/s; may borrow ) { catch ip 192.168.2.6; } class ( 256kbit/s; may borrow ) { catch ip 192.168.2.7; } class ( 256kbit/s; may borrow ) { catch ip 192.168.2.8; } } output ( 256kbit/s ) { // downstream class ( 42kbit/s; may borrow ) { catch ip 192.168.2.2; } class ( 42kbit/s; may borrow ) { catch ip 192.168.2.3; } class ( 42kbit/s; may borrow ) { catch ip 192.168.2.4; } class ( 42kbit/s; may borrow ) { catch ip 192.168.2.6; } class ( 42kbit/s; may borrow ) { catch ip 192.168.2.7; } class ( 42kbit/s; may borrow ) { catch ip 192.168.2.8; } } } The "device" object is meant to represent the device's configuration specific data. "input" as child of "device" represents the input bandwidth configuration - same goes for "output". class is just like tc/tcng, I guess. "catch ip IP" just tells, what IP packets should be queued in this class. The queuing discipline to be used is rarely unimportant, maybe htb, cbq, or tbf, what ever(?) best fits right here. Sorry, this is *my* brain-dead-pseudo-code to explain, what I want, with a syntax associated to the tcc(tcng) examples I have found on the net. Could someone *now* show me, how my goal should look in tcng syntax? Many thanks, Christian Parpart. From lartc@schmakk.dk Sat Apr 24 12:28:35 2004 From: lartc@schmakk.dk (Patrick Petersen) Date: Sat, 24 Apr 2004 13:28:35 +0200 Subject: [LARTC] Making tcp start transfers slow In-Reply-To: <4089A2A4.3040200@dsl.pipex.com> References: <20040422022425.52B5.LARTC@schmakk.dk> <4089A2A4.3040200@dsl.pipex.com> Message-ID: <20040424131830.5620.LARTC@schmakk.dk> On Sat, 24 Apr 2004 00:11:32 +0100, Andy Furniss wrote: > One possible problem - I don't think connbytes will patch with connmark > (which IIRC ipp2p uses). I have been told that it is possible to get > them to work, but patch will fail as they both change the same struct, > so it's a do it by hand job... Im usually all for the "do it by hand" thing, but im not really up for screwing with this yet i think :) Its correct that ipp2p uses connmark... That way it is only necessary to tag a connection once, then leave it. Great for those huge setups, where the ipp2p usage should be kept at a minimum.. Afaik its a bit heavy on ressources. [SNIP - torrent talk] > LOL - I think your idea about reducing rwin may help - easy on a small > setup where you have control. That was my idea, but so far ive only found out how to alter the window size on a per route basis. If it could just be extended a little by making new connections have a small size, then putting them back to normal after a while. But if i went all the way out there, i might just as well start a complete dynamic window chaning thing. [SNIP - more torrent and ipp2p] > Yes - so you don't need to mark all those ports then. Probably not, but i dont think the extra overhead will do any harm as long as its a puny adsl im dealing with :) I guess im not trusting ipp2p enough. > Yes esfq on dst will make things fair per IP address - but in the case > of ingress with the many tcps that BT uses dropping is important to get > the sender to back off. Esfq on dst is not really a fairness queue any > more WRT individual tcp connections, it may not make much difference, > but if you use htb for per IP fairness and esfq classic, then the drops > are a bit more likely to get at the most active connections. > > I modified esfq to drop from the head of a slot rather than the end - > which in theory should make things slightly nicer and changed hash to > use dst port. I really ought to make them into a switches (when I work > out how) I also intend to patch with the change to sfq that was recently > talked about on here. If it looks OK I'll put it up on my webspace > sometime - I don't really know what I am doing though :-) Sounds nice, share when you think its stable. Im all for betatesting too if you need any. > For us small bandwidth users a R(real)FQ would be nice - (e)sfq is OK > but it often hashes into the same slot and perturb causes packet > reordering which hurts more when used for ingress. I will try fiddling without esfq with fingers crossed - thanks. -- Patrick Petersen From estradaedgar@hotmail.com Sat Apr 24 17:18:54 2004 From: estradaedgar@hotmail.com (Edgar Estrada Lopez) Date: Sat, 24 Apr 2004 11:18:54 -0500 Subject: [LARTC] Selective Masquerading Message-ID: HI guys: I have a DSL @ 1mb, and another one @ 256kbps I've been reading countless hours regarding the split access / load balancing issue, but for some strange reason, things don't work the way they should. Sometimes the split access works, other times a DSL begins an ARP flood pointing all the ARP replies to the other DSL, and sometimes they just wont work at all. While giving a deep thought on why I got the 2 dsl, the answer is simple: So I could have fast downloads, and fast web browsing also. So I was thinking: is there a way to masquerade / direct all web browsing (ie port 80, 25, 110) to the 256dsl, and leave the rest of the communications (higher ports 1024+) to the 1 mbps line? Thanks _________________________________________________________________ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx From andy.furniss@dsl.pipex.com Sun Apr 25 00:01:37 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 25 Apr 2004 00:01:37 +0100 Subject: [LARTC] boring question In-Reply-To: <40895BAD.2020902@ivanhawkes.com> References: <20040422214238.8E57A44CB@outpost.ds9a.nl> <40895BAD.2020902@ivanhawkes.com> Message-ID: <408AF1D1.6060001@dsl.pipex.com> Mr Ivan Hawkes wrote: > It is important to note that this generally works well for outgoing > traffic but is not particularly effective against incoming traffic since > that is *pushed* onto your machine and it has no way to control this. You can control incoming bandwidth much the same as outbound - but it's hard to keep latency low all of the time. Andy. From krv@kaevee.com Sun Apr 25 03:41:13 2004 From: krv@kaevee.com (krv) Date: Sun, 25 Apr 2004 08:11:13 +0530 Subject: [LARTC] Selective Masquerading References: Message-ID: <029601c42a6e$c6ab22d0$2800a8c0@jupiter> ----- Original Message ----- From: "Edgar Estrada Lopez" To: Sent: Saturday, April 24, 2004 9:48 PM Subject: [LARTC] Selective Masquerading > HI guys: > > I have a DSL @ 1mb, and another one @ 256kbps > > I've been reading countless hours regarding the split access / load > balancing issue, but for some strange reason, things don't work the way they > should. > > Sometimes the split access works, other times a DSL begins an ARP flood > pointing all the ARP replies to the other DSL, and sometimes they just wont > work at all. > > While giving a deep thought on why I got the 2 dsl, the answer is simple: So > I could have fast downloads, and fast web browsing also. > > So I was thinking: is there a way to masquerade / direct all web browsing > (ie port 80, 25, 110) to the 256dsl, and leave the rest of the > communications (higher ports 1024+) to the 1 mbps line? > You can do this using multiple SNAT lines for each destination port. You should make sure to put 80 and 443 on the same line to avoid trouble. You still need a policy routing to ensure the packets having source address of line1 go out on line1 and same with line2. You can do without policy routing provided (a) Your service providers accept and route the packets with source IP's which do not belong to them. (b) You have enough upstream bandwidth on one link. KRV From jasonb@edseek.com Sat Apr 24 06:27:13 2004 From: jasonb@edseek.com (Jason Boxman) Date: Sat, 24 Apr 2004 01:27:13 -0400 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> Message-ID: <200404240127.13635.jasonb@edseek.com> On Friday 23 April 2004 21:23, trapni@surakware.net wrote: > Hi all, Hello. > this is really not really very easy to understand, or, to get in. I spent several weeks playing to tcng. I found a few useful references. http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/index.html http://mailman.ds9a.nl/pipermail/lartc/2003q4/010826.html http://linux-ip.net/gl/tcng/tcng.html > Well, I've the following configuration on the router box: > > LAN > - interface: eth0 > - network: 192.168.2.5/24 > - bandwidth: 100Mbit/s > INET interface > - interface: ppp0 > - network: .dynamic.ip./0 > - bandwidth: DOWN=1536kbit/s and UP=256kbit/s > > the LAN interface is to serve 6 other clients with internet and local > services. My goal NOW was, or is, to garrantie each client with a fair > amount of bandwith for both, up and down. Egress is easy. Ingress seems to be a topic that is discussed often on LARTC, and I believe your options are to either use an ingress policer or the IMQ target. The former you can do directly with tcng, the latter I believe you cannot. > That is, each client inside the LAN should get garrantied > - PER_CLIENT_DOWN=256kbit/s > - and PER_CLIENT_UP=42kbit/s > Each unused bandwith may be shared between them. > > The LAN clients have IP pool: > 192.168.2.2-192.168.2.4, and > 192.168.2.6-192.168.2.8 > > But how exactly do I now express my wish in TCNG syntax? > > Some kind of pseudo code like below... > > The "device" object is meant to represent the device's configuration > specific data. "input" as child of "device" represents the input > bandwidth configuration - same goes for "output". class is just like > tc/tcng, I guess. "catch ip IP" just tells, what IP packets should be > queued in this class. The queuing discipline to be used is rarely > unimportant, maybe htb, cbq, or tbf, what ever(?) best fits right here. You'd probably use HTB for egress. If you decide to use IMQ you might use it in both directions. > Sorry, this is *my* brain-dead-pseudo-code to explain, what I want, with a > syntax associated to the tcc(tcng) examples I have found on the net. > > Could someone *now* show me, how my goal should look in tcng syntax? I don't think you can use IMQ from within tcng, so you may not be able to do ingress and egress with a single tool. > Many thanks, > Christian Parpart. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff From andy.furniss@dsl.pipex.com Sun Apr 25 08:06:17 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 25 Apr 2004 08:06:17 +0100 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <200404240127.13635.jasonb@edseek.com> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <200404240127.13635.jasonb@edseek.com> Message-ID: <408B6369.5010200@dsl.pipex.com> Jason Boxman wrote: > Egress is easy. Ingress seems to be a topic that is discussed often on LARTC, > and I believe your options are to either use an ingress policer or the IMQ > target. The former you can do directly with tcng, the latter I believe you > cannot. I know nothing about TCNG so can't help there. You can shape ingress without using IMQ as long as you have just one LAN interface and don't care about traffic headed for the shaping PC. You just shape on the LAN interface. Andy. From atash_000@yahoo.com Sun Apr 25 11:23:04 2004 From: atash_000@yahoo.com (Feri adam) Date: Sun, 25 Apr 2004 03:23:04 -0700 (PDT) Subject: [LARTC] tc [htb] performance on 2000 leaves Message-ID: <20040425102304.83613.qmail@web41602.mail.yahoo.com> Hi I'm going to setup a linux box as a packet shaper for my company. we've got at most 2000 leaves and about 4 to 5 different parent calsses. i'm just wondering if someone can tell me how much will be the delay ?! what is the prefered hardware solution for best performance with tc in this scenario?! and about setting up the linux box in bridged mode; i googled and found out that this has a bad impact on tc performance ! does anybody has any experience around this issue ?! benchmarks are so welcome in any case; since i've searched internet but i haven't found any useful ones ! Thanks in advance. Regards feri __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25˘ http://photos.yahoo.com/ph/print_splash From blackhawk@ivanhawkes.com Sun Apr 25 14:06:30 2004 From: blackhawk@ivanhawkes.com (Mr Ivan Hawkes) Date: Sun, 25 Apr 2004 14:06:30 +0100 Subject: [LARTC] boring question In-Reply-To: <408AF1D1.6060001@dsl.pipex.com> References: <20040422214238.8E57A44CB@outpost.ds9a.nl> <40895BAD.2020902@ivanhawkes.com> <408AF1D1.6060001@dsl.pipex.com> Message-ID: <408BB7D6.9080608@ivanhawkes.com> Andy Furniss wrote: > Mr Ivan Hawkes wrote: > >> It is important to note that this generally works well for outgoing >> traffic but is not particularly effective against incoming traffic >> since that is *pushed* onto your machine and it has no way to control >> this. > > > You can control incoming bandwidth much the same as outbound - but it's > hard to keep latency low all of the time. > > Andy. > > Are you able to selectively control incoming bandwidth? e.g. I have some BT's running sucking up all that good bandwidth and my incoming pipe gets saturated (it's 2MB, so this doesn't generally happen). How would I tell the BT streams to slow down while giving more priority to the important stuff? I know how to do it on egress, just not on ingress. -- http://www.ivanhawkes.com | ICQ: 173-392-038 From cparpart@surakware.net Sun Apr 25 18:43:45 2004 From: cparpart@surakware.net (Christian Parpart) Date: Sun, 25 Apr 2004 19:43:45 +0200 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <408B6369.5010200@dsl.pipex.com> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <200404240127.13635.jasonb@edseek.com> <408B6369.5010200@dsl.pipex.com> Message-ID: <200404251943.48456.cparpart@surakware.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 April 2004 09:06, Andy Furniss wrote: > Jason Boxman wrote: > > Egress is easy. Ingress seems to be a topic that is discussed often on > > LARTC, and I believe your options are to either use an ingress policer or > > the IMQ target. The former you can do directly with tcng, the latter I > > believe you cannot. > > I know nothing about TCNG so can't help there. > > You can shape ingress without using IMQ as long as you have just one LAN > interface and don't care about traffic headed for the shaping PC. You > just shape on the LAN interface. But *how* does such a setup now looks like, either in tcng or in gc syntax? This is what I actually do: - -------------------------------------------------- #! /bin/sh DEV=ppp0 UP=256 DOWN=768 CLIENTS="192.168.2.1 192.168.2.2 192.168.2.3 192.168.2.5 192.168.2.6 192.168.2.7 192.168.2.8" TC=$(which tc) # reset $TC qdisc del dev ${DEV} root &>/dev/null $TC qdisc del dev ${DEV} ingress &>/dev/null # attach HTB queue discipline to device $DEV $TC qdisc add dev $DEV root handle 1: htb default 12 # create client classes for shaping DOWN-stream crate=$[DOWN / NumClients] i=0 for host in $CLIENTS; do $TC class add dev $DEV parent 1:1 classid 1:1$i htb rate ${crate}kbit ceil ${DOWN}kbit $TC filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip src $host flowid 1:1$i i=$[i + 1] done # TODO shaping UP stream - -------------------------------------------------- This is my script. And I do not really now, *where* to differ here to once shape down-stream, and once to shape the up-stream I'd be really really very happy, if someone would point me in this *wrong* script to the right direction. Many thanks, Christian Parpart. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAi/jRPpa2GmDVhK0RAiyiAJ9t1LngvstQqwqGkTC367USYfcQtQCeNHUV nc9176QOuUWp1XqeCSrbj8g= =Po1b -----END PGP SIGNATURE----- From krv@kaevee.com Mon Apr 26 04:59:30 2004 From: krv@kaevee.com (krv) Date: Mon, 26 Apr 2004 09:29:30 +0530 Subject: [LARTC] tc [htb] performance on 2000 leaves References: <20040425102304.83613.qmail@web41602.mail.yahoo.com> Message-ID: <03cf01c42b42$e12b1730$2800a8c0@jupiter> ----- Original Message ----- From: "Feri adam" To: Sent: Sunday, April 25, 2004 3:53 PM Subject: [LARTC] tc [htb] performance on 2000 leaves > Hi > > I'm going to setup a linux box as a packet shaper for > my company. we've got at most 2000 leaves and about 4 > to 5 different parent calsses. > i'm just wondering if someone can tell me how much > will be the delay ?! > what is the prefered hardware solution for best > performance with tc in this scenario?! > and about setting up the linux box in bridged mode; i > googled and found out that this has a bad impact on tc > performance ! does anybody has any experience around > this issue ?! > benchmarks are so welcome in any case; since i've > searched internet but i haven't found any useful ones > ! Have a look at this http://lartc.org/howto/lartc.adv-filter.hashing.html It might help you out. KRV From mihaivlad@web-profile.net Mon Apr 26 07:55:50 2004 From: mihaivlad@web-profile.net (Mihai Vlad) Date: Mon, 26 Apr 2004 09:55:50 +0300 Subject: [LARTC] Split bursty bandwidth equally Message-ID: <20040426072547.70B2C4479@outpost.ds9a.nl> Hello again, Is it possible to split a bandwidth equally among clients regardless of its current link speed? I have a link that can get bursty at times. At any given time the N active sessions (the ones with non-empty queues) need to be serviced simultaneously, each at a rate of 1/N'th of the link speed. My case is an internet connection that oscillates between 96 kbps and 256 kbps. I cannot predict the connection speed in order to use the classical HTB (to set up a 96/96 kbps class), because I would loose a lot of bandwidth when the speed goes over 96kbps. This might not be a strictly HTB related question. It doesn't matter if I use htb, cbq pr other technique. I do not have to guarantee a certain amount of bandwidth to one computer in the LAN, just to split the existing bandwidth equally among the N active clients. I know... Someone said here "Use sfq or esfq". Unfortunately I am not very bright and a piece of code would be excellent :) In fact I tried a lot of setups but did not get any satisfactory result. Please help! Thanks in advance, Mihai Vlad From andy.furniss@dsl.pipex.com Mon Apr 26 08:47:34 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 26 Apr 2004 08:47:34 +0100 Subject: [LARTC] boring question In-Reply-To: <408BB7D6.9080608@ivanhawkes.com> References: <20040422214238.8E57A44CB@outpost.ds9a.nl> <40895BAD.2020902@ivanhawkes.com> <408AF1D1.6060001@dsl.pipex.com> <408BB7D6.9080608@ivanhawkes.com> Message-ID: <408CBE96.2080905@dsl.pipex.com> Mr Ivan Hawkes wrote: > Andy Furniss wrote: > >> Mr Ivan Hawkes wrote: >> >>> It is important to note that this generally works well for outgoing >>> traffic but is not particularly effective against incoming traffic >>> since that is *pushed* onto your machine and it has no way to control >>> this. >> >> >> >> You can control incoming bandwidth much the same as outbound - but >> it's hard to keep latency low all of the time. >> >> Andy. >> >> > Are you able to selectively control incoming bandwidth? e.g. I have some > BT's running sucking up all that good bandwidth and my incoming pipe > gets saturated (it's 2MB, so this doesn't generally happen). How would I > tell the BT streams to slow down while giving more priority to the > important stuff? I know how to do it on egress, just not on ingress. > You can treat it a egress traffic coming from shaping box to LAN. So the marking/filtering should be no different. In the BT case, there is a project on sf.net called ipp2p which can mark it, it needs you to patch netfilter/kernel with connmark. I don't use it so can't tell you in detail. Andy. From andy.furniss@dsl.pipex.com Mon Apr 26 09:01:34 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 26 Apr 2004 09:01:34 +0100 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <200404251943.48456.cparpart@surakware.net> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <200404240127.13635.jasonb@edseek.com> <408B6369.5010200@dsl.pipex.com> <200404251943.48456.cparpart@surakware.net> Message-ID: <408CC1DE.10704@dsl.pipex.com> Christian Parpart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sunday 25 April 2004 09:06, Andy Furniss wrote: > >>Jason Boxman wrote: >> >>>Egress is easy. Ingress seems to be a topic that is discussed often on >>>LARTC, and I believe your options are to either use an ingress policer or >>>the IMQ target. The former you can do directly with tcng, the latter I >>>believe you cannot. >> >>I know nothing about TCNG so can't help there. >> >>You can shape ingress without using IMQ as long as you have just one LAN >>interface and don't care about traffic headed for the shaping PC. You >>just shape on the LAN interface. > > > But *how* does such a setup now looks like, either in tcng or in gc syntax? > > This is what I actually do: > - -------------------------------------------------- > #! /bin/sh > > DEV=ppp0 > UP=256 > DOWN=768 > CLIENTS="192.168.2.1 192.168.2.2 192.168.2.3 192.168.2.5 192.168.2.6 192.168.2.7 192.168.2.8" > TC=$(which tc) > > # reset > $TC qdisc del dev ${DEV} root &>/dev/null > $TC qdisc del dev ${DEV} ingress &>/dev/null > > # attach HTB queue discipline to device $DEV > $TC qdisc add dev $DEV root handle 1: htb default 12 > > # create client classes for shaping DOWN-stream > crate=$[DOWN / NumClients] > i=0 > for host in $CLIENTS; do > $TC class add dev $DEV parent 1:1 classid 1:1$i htb rate ${crate}kbit ceil ${DOWN}kbit > $TC filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip src $host flowid 1:1$i > i=$[i + 1] > done > > # TODO shaping UP stream > - -------------------------------------------------- > > This is my script. And I do not really now, *where* to differ > here to once shape down-stream, and once to shape the up-stream > > I'd be really really very happy, if someone would point > me in this *wrong* script to the right direction. > You have to set you rates lower than your real rates - for ingress about 80% so you actually get queues growing that you can control. For egress about 85% with dsl as there are extra overheads and TC counts IP size. You should be shaping on eth0 if that's your LAN facing interface - you shape egress from the shaping box to the LAN to do ingress (on simple setups). The src IP match needs to change to dst. As it is the script may have too big queues - but should work as a test, you may also endup wanting to split interactive traffic from bulk to make things nicer for users - but that sort of thing is policy to be thought about/agreed by users. Andy. > Many thanks, > Christian Parpart. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFAi/jRPpa2GmDVhK0RAiyiAJ9t1LngvstQqwqGkTC367USYfcQtQCeNHUV > nc9176QOuUWp1XqeCSrbj8g= > =Po1b > -----END PGP SIGNATURE----- > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From brian.nox@ya.com Mon Apr 26 10:03:37 2004 From: brian.nox@ya.com (Brian Nox) Date: Mon, 26 Apr 2004 11:03:37 +0200 Subject: [LARTC] patching kernel and iptables for IMQ Message-ID: <408CD069.7000300@ya.com> I have a linux box with kernel 2.4.22 and iptables 1.2.9 First, i patch linux kernel with Norbet Buckmuller's .diff #cd \usr\src\linux #patch -p1 < imq-combo-debian-2.4.22.diff All correct Second, i -try to- patch iptables (following www.linuximq.net/faq.html) #cd /usr/src/linux/net/ipv4/netfilter I edit IMQ.pom-ng.patch and replace $KERNEL_DIR with /usr/src/linux #patch -p1 < IMQ.pom-ng.patch #cd /usr/src/linux/net/ipv4/netfilter/extensions #chmod +x .IMQ-test*. #cd /usr/src/linux #make dep & make modules ... plonk! :-( any idea? From adrian@smartcall.ro Mon Apr 26 12:56:55 2004 From: adrian@smartcall.ro (Adrian Saileanu) Date: Mon, 26 Apr 2004 14:56:55 +0300 (EEST) Subject: [LARTC] patching kernel and iptables for IMQ In-Reply-To: <408CD069.7000300@ya.com> References: <408CD069.7000300@ya.com> Message-ID: <25513.192.168.3.4.1082980615.squirrel@mail.smartcall.ro> IMQ.pom-ng.patch is for patching iptables 1.2.9 sourcew code .. wget http://netfilter.org/files/iptables-1.2.9.tar.bz2 tar xjvf iptables-1.2.9.tar.bz2 Now look in extensions folder ... there you have already the supported options. wget http://www.linuximq.net/patchs/IMQ.pom-ng.patch cd iptables-1.2.9 patch -p1 < ../IMQ.pom-ng.patch patching file extensions/.IMQ-test6 patching file extensions/libip6t_IMQ.c patching file extensions/.IMQ-test patching file extensions/libipt_IMQ.c Now, the following must to be done so that iptables will support imq : chmod +x extensions/.IMQ-test* You will see when compiling that a lib will be created : ld -shared -o extensions/libipt_IMQ.so extensions/libipt_IMQ_sh.o cc -O2 -Wall -Wunused -I/usr/src/linux/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_recent_sh.o -c extensions/libipt_recent.c My question is ... how do I patch the kernel so that I will have suport for IMQ support as iptables option ? > I have a linux box with kernel 2.4.22 and iptables 1.2.9 > > First, i patch linux kernel with Norbet Buckmuller's .diff > #cd \usr\src\linux > #patch -p1 < imq-combo-debian-2.4.22.diff > All correct > > Second, i -try to- patch iptables (following www.linuximq.net/faq.html) > #cd /usr/src/linux/net/ipv4/netfilter > I edit IMQ.pom-ng.patch and replace $KERNEL_DIR with /usr/src/linux > #patch -p1 < IMQ.pom-ng.patch > #cd /usr/src/linux/net/ipv4/netfilter/extensions > #chmod +x .IMQ-test*. > #cd /usr/src/linux > #make dep & make modules > ... > plonk! :-( > > any idea? > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From pattieja@pcxperience.com Mon Apr 26 16:06:44 2004 From: pattieja@pcxperience.com (Jason A. Pattie) Date: Mon, 26 Apr 2004 10:06:44 -0500 Subject: [LARTC] IPSec tunnel problem In-Reply-To: <40897577.7050606@janrain.com> References: <40897577.7050606@janrain.com> Message-ID: <408D2584.5040908@pcxperience.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Grant Monroe wrote: | I am attempting to setup a simple network-to-network IPSec tunnel. The | tunnel appears to be setup correctly because I can make connections | between the networks and tcpdump shows esp packets going between the two | gateways. My problem is that I cannot make connections from one gateway | to the other through the tunnel. I think that this is a routing issue. | Here is some more info about my network: | | 192.168.1.1 10.0.0.6 10.0.0.9 | 192.168.2.1 | 192.168.1.7 +-----------+ | +-----------+ 192.168.2.14 | +-----+ | Gateway | | Gateway | | +-----+ | | Foo | -- 192.168.1.0/24 -- | A | -- 10.0.0.0/24 -- | B | | -- 192.168.2.0/24 -- | Bar | | +-----+ +-----------+ | +-----------+ +-----+ | | So, for example, Foo can ping Bar, but Gateway A can't ping Gateway B's | private interface or Bar. | Thanks for any help. No problem. If you are by any chance using FreeS/WAN (or one of its derivatives) you have to setup 4 tunnel connections. Subnet-to-Subnet, Subnet-to-Host, Host-to-Subnet, and Host-to-Host. There are e-mails in the FreeS/WAN archives that show how to setup routes in order to accomplish the same thing, but I like being able to see the actual tunnels up and know what connections I've defined. I.e., ipsec eroute will let you see all 4 tunnels, not just 1 and you have to know that routes are in place to allow traffic to flow in all 4 directions. - -- Jason A. Pattie pattieja@xperienceinc.com Xperience, Inc. (http://www.xperienceinc.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAjSWEuYsUrHkpYtARAsCEAJ9hsG2y93dvWp8McBlXIzKozzG2EACeIpDH H6SxFvchlAEVesyA26dpBGM= =2sYd -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. From lartc@ns.mudrc.net Mon Apr 26 16:25:47 2004 From: lartc@ns.mudrc.net (lartc@ns.mudrc.net) Date: Mon, 26 Apr 2004 17:25:47 +0200 Subject: [LARTC] Multicast routing with multiple routers problem Message-ID: <20040426152547.GA16912@ns.mudrc.net> Hi, I have problem with multicast routing on my network. I tried mrouted and also pimd, but always same problem. When I set mrouted or pimd on one router, everything works fine, but when I start mrouted/pimd on another one, routing die. In moment when I start anorher mrouted/pimd /proc/net/ip_mr_cache is cleaned. My topology: gateway (no mrouted/pimd) | 192.168.0.0/24 | subnet +--------------- backbone switch-----+ | | | | | | (192.168.0.1) (192.168.0.2) (192.168.0.3) router1 streaming_machine router2 (192.168.1.1) (source of data) (192.168.2.1) | | 192.168.1.0/24| | 192.168.2.0/24 subnet subnet switch switch | | | | | | | | | | clients clients Backbone switch has igmp snooping, querying and mcast learning Any idea what could be wrong, or can anybody show mrouted.conf or pimd.conf for this ? Thanx for help. Roman From dchaparro@gsyc.escet.urjc.es Mon Apr 26 23:38:07 2004 From: dchaparro@gsyc.escet.urjc.es (Diego Chaparro) Date: Tue, 27 Apr 2004 00:38:07 +0200 Subject: [LARTC] Problems balancing two uplink providers Message-ID: <1083019087.8006.31.camel@pikachu.casa> Hi all, I have implemented a solution with a machine balancing the network load between two DSL providers as is explained in the LARTC Howto. It is apparently working correctly, but i have some problems. The problem is basically that some packets go out by each ADSL interface with the source address of the other ADSL interface. I think that the routing based on source address isn't working. Here are configuration data: eth0: ADSL provider 1 eth1: ADSL provider 2 eth2: Private network IP eth0: 80.27.46.168/26 IP eth1: 217.12.112.190/30 IP eth2: 192.168.239.15/24 Routing rules: ip route add 80.27.46.128 dev eth0 src 80.27.46.168 table T1 ip route add default via 80.27.46.129 table T1 ip route add 80.27.46.128 dev eth0 src 80.27.46.168 ip route add 217.12.112.188 dev eth1 src 217.12.112.190 table T2 ip route add default via 217.12.112.189 table T2 ip route add 217.12.112.188 dev eth1 src 217.12.112.190 ip route add default scope global nexthop via 80.27.46.129 dev eth0 w eight 1 nexthop via 217.12.112.189 dev eth1 weight 1 ip rule add from 80.27.46.168 table T1 ip rule add from 217.12.112.190 table T2 NAT rules: iptables -t nat -A POSTROUTING -o eth0 -s 192.168.239.0/24 -j SNAT --to-source 80.27.46.168 iptables -t nat -A POSTROUTING -o eth1 -s 192.168.239.0/24 -j SNAT --to-source 217.12.112.190 The problem is: router:~# tcpdump -i eth1 host 80.27.46.168 -n tcpdump: listening on eth1 00:31:55.880169 80.27.46.168.4889 > 81.35.21.64.4662: . ack 2580075548 win 17280 (DF) 00:31:55.886844 80.27.46.168.3587 > 150.217.68.78.8080: . ack 1084550836 win 15260 (DF) [...] router:~# tcpdump -i eth0 -n host 217.12.112.190 tcpdump: listening on eth0 00:35:07.116006 217.12.112.190.2799 > 81.9.161.217.4662: . ack 4081941596 win 17139 (DF) 00:35:07.258220 217.12.112.190.2917 > 68.162.131.254.4662: . ack 1208711693 win 16265 (DF) Please, some idea? I don't find where is the mistake. Thanks in advance. Regards. -- Diego Chaparro González. Grupo de Sistemas y Comunicaciones. Universidad Rey Juan Carlos. C/ Tulipan s/n - 28933 Móstoles (Spain) dchaparro@gsyc.escet.urjc.es From nelson@politecnica.edu.co Tue Apr 27 15:13:58 2004 From: nelson@politecnica.edu.co (Nelson E. Castillo) Date: Tue, 27 Apr 2004 09:13:58 -0500 Subject: [LARTC] Real IP behind SNAT Message-ID: <20040427141358.GA2478@mail.politecnica.edu.co> --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I was asked to put a real IP behind a linux router is doing static NAT for an internal network. Internet (gateway) | | | eth0 =3D real IP ----------------- L I N U X ROUTER ----------------- eth1 =3D private IP | | | eth0 =3D real IP =20 ----------------- Wireless Access Point ----------------- I was asked to put a real ip (not to do static NAT) in the Ethernet interface of the WAP. How can I do it? I've read some manuals and I guess I should use the same address with a different netmask in WAP(eth0) and put a route in the Linux box and use a fake arp entry in the eth0 interface of the router. I'd appreciate any hint you can give me. Regards, Nelson.- --=20 http://geocities.com/arhuaco The first principle is that you must not fool yourself and you are the easiest person to fool. -- Richard Feynman. --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkCOaqYACgkQ2RNeisdKzwspbgCeOqQ6P58IT8pL8V5DGUjcJ6re ux8AnjhRMQv4pc1ZMrqr4fQoHUeJi93u =Epsy -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From lartc@24x7linux.com Tue Apr 27 16:05:48 2004 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Tue, 27 Apr 2004 17:05:48 +0200 Subject: [LARTC] Real IP behind SNAT In-Reply-To: <20040427141358.GA2478@mail.politecnica.edu.co> References: <20040427141358.GA2478@mail.politecnica.edu.co> Message-ID: <20040427150548.GA3655@localhost> On Tuesday, 27 April 2004, at 09:13:58 -0500, Nelson E. Castillo wrote: > Internet (gateway) > | > | > | > eth0 = real IP > ----------------- > L I N U X ROUTER > ----------------- > eth1 = private IP > | > | > | > eth0 = real IP > ----------------- > Wireless Access Point > ----------------- > > I was asked to put a real ip (not to do static > NAT) in the Ethernet interface of the WAP. How can > I do it? > I suppose the real IP you have to assing to your WAP ethernet interface is in the same range as the real IP address assigned to the external interface of your Linux router. I think you can set up a proxy ARP entry on this Linux router for the real IP to put on your WAP. The external interface in the Linux router will reply to ARP requests with its own MAC address, and will receive the incoming traffic. Then you must have adequate routing entries to direct traffic going to the "internal" real IP address through the internal (private) interface in the Linux router, and hopefully it will arrive at the WAP. The best way to avoid missing something in the process of configuring everything is to take a paper and a pen, and draw the path of the IP packets through your network. Do everything as the operating system would do, and do what is needed to make packets arrive at the correct place in your network. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5) From kaushalender1" --=_MAILER_ATTACH_BOUNDARY1_200442838550719885386 Content-Type: text/plain; charset=us-ascii Hi group, I am new to this group and linux.we have a linux box on which we are giving bandwidth to multiple customers..this box have two ethernet interface eth0 and eth1 .Eth0 is directly connected to internet and eth1 is connected to customer, for examle eth1 have 10.10.X.x series and wth1:1 have 10.11.x.x series .Can any body help in restricting bandwidth 48 kbps for 10.10.x.x and 64 for 10.11.x.x and make a utilization graph of there bandwidt i will be highly thankfull Thanxs in advance Kaushalender Indiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_200442838550719885386 Content-Type: text/html; charset=us-ascii Hi group, I am new to this group and linux.we have a linux box on which we are giving bandwidth to multiple customers..this box have two ethernet interface eth0 and eth1 .Eth0 is directly connected to internet and eth1 is connected to customer, for examle eth1 have 10.10.X.x series and wth1:1 have 10.11.x.x series .Can any body help in restricting bandwidth 48 kbps for 10.10.x.x and 64 for 10.11.x.x and make a utilization graph of there bandwidt i will be highly thankfull Thanxs in advance Kaushalender
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_200442838550719885386-- From animesh@neolinuxsolutions.com Wed Apr 28 05:47:04 2004 From: animesh@neolinuxsolutions.com (Animesh Bansriyar) Date: 28 Apr 2004 10:17:04 +0530 Subject: [LARTC] bandwidth controlling and monitering In-Reply-To: <200404280202.HAA00418@WS0005.indiatimes.com> References: <200404280202.HAA00418@WS0005.indiatimes.com> Message-ID: <1083127802.711.11.camel@laptop> On Wed, 2004-04-28 at 08:05, kaushalender1 wrote: > Hi group, > I am new to this group and linux.we have a linux box on which we are > giving bandwidth to multiple customers..this box have two ethernet >interface eth0 and eth1 .Eth0 is directly connected to internet and >eth1 is connected to customer, for examle eth1 have 10.10.X.x series >and wth1:1 have 10.11.x.x series .Can any body help in restricting >bandwidth 48 kbps for 10.10.x.x and 64 for 10.11.x.x and make a >utilization graph of there bandwidt i will be highly thankfull > You could have posted a better question instead of simply asking the list how to do everything. If you don't know how to do simple bandwidth management stuff I would suggest not trying. If you are so new to Traffic control and Linux, get some professional consulting. ANyway read up on the following and then get back to the list after forming a proper question: Linux Advanced Routing HOWTO Traffic Control HOWTO Traffic Control howto will tell you a lot about what you want. LARTC list archives Google. I would suggest using HTB for this. Cheers! Animesh -- Animesh Bansriyar http://neolinuxsolutions.com, +91-651-3112497, 3122401. Linux Intranet/Internet Servers, Specialised E-mail Setups, Enterprise Database and Directory Services, Linux Application Development and Commercial Support for Free/OpenSource Software From lartc@ssi.bg Wed Apr 28 09:07:52 2004 From: lartc@ssi.bg (Anton Glinkov) Date: Wed, 28 Apr 2004 11:07:52 +0300 (EEST) Subject: [LARTC] HTB not obeying to specified rate? Message-ID: <52912.212.36.22.250.1083139672.squirrel@mail.ssi.bg> here is the situation i am using htb.init with fwmark to do QoS. i have 2 parent classes with RATE=CEIL which then have some leafs each on his own. the first one works fine (it shapes the packets to the specified rate) class htb 1:21 root rate 1Mbit ceil 1Mbit burst 2909b cburst 2909b Sent 631520262 bytes 651550 pkts (dropped 0, overlimits 0) rate 131573bps 141pps lended: 380595 borrowed: 0 giants: 0 tokens: -22734 ctokens: -22734 the rate never goes over 132000 bps. the other doesn't seem to check the rate at all. here is the tc -s: class htb 1:22 root rate 448Kbit ceil 448Kbit burst 2172b cburst 2172b Sent 337083231 bytes 522787 pkts (dropped 0, overlimits 0) rate 71638bps 120pps lended: 0 borrowed: 0 giants: 0 tokens: -59999999 ctokens: -59999999 i tried to lower the rate (to 128Kbit) it still uses the maximum available (sometimes goes up to 90000 bps). the same when I tried to lower the burst and cburst. any ideas? what do the tokens/ctokens specify? regards From andy.furniss@dsl.pipex.com Wed Apr 28 09:22:35 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 28 Apr 2004 09:22:35 +0100 Subject: [LARTC] Split bursty bandwidth equally In-Reply-To: <20040426072547.70B2C4479@outpost.ds9a.nl> References: <20040426072547.70B2C4479@outpost.ds9a.nl> Message-ID: <408F69CB.5000200@dsl.pipex.com> Mihai Vlad wrote: > Hello again, > > Is it possible to split a bandwidth equally among clients regardless of its > current link speed? > > I have a link that can get bursty at times. At any given time the N active > sessions (the ones with non-empty queues) need to be serviced > simultaneously, each at a rate of 1/N'th of the link speed. Is this upstream or downstream traffic? If it's upstream, what causes the variation, eg. is it RADSL and you get a long queue in your modem buffer, or is it shaped later at ISP - what is the link type/behavior ? > > My case is an internet connection that oscillates between 96 kbps and 256 > kbps. I cannot predict the connection speed in order to use the classical > HTB (to set up a 96/96 kbps class), because I would loose a lot of bandwidth > when the speed goes over 96kbps. > > This might not be a strictly HTB related question. It doesn't matter if I > use htb, cbq pr other technique. I do not have to guarantee a certain amount > of bandwidth to one computer in the LAN, just to split the existing > bandwidth equally among the N active clients. > > I know... Someone said here "Use sfq or esfq". Unfortunately I am not very > bright and a piece of code would be excellent :) In fact I tried a lot of > setups but did not get any satisfactory result. Depends on the exact nature of your link, hardware and the direction of the variable rate. It may be impossible/possible/a bit possible more detail is needed. Andy. From cparpart@surakware.net Wed Apr 28 09:42:11 2004 From: cparpart@surakware.net (Christian Parpart) Date: Wed, 28 Apr 2004 10:42:11 +0200 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <408CC1DE.10704@dsl.pipex.com> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <200404251943.48456.cparpart@surakware.net> <408CC1DE.10704@dsl.pipex.com> Message-ID: <200404281042.18011.cparpart@surakware.net> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 26 April 2004 10:01, Andy Furniss wrote: > > On Sunday 25 April 2004 09:06, Andy Furniss wrote: > >>Jason Boxman wrote: > >>>Egress is easy. Ingress seems to be a topic that is discussed often on > >>>LARTC, and I believe your options are to either use an ingress policer > >>> or the IMQ target. The former you can do directly with tcng, the > >>> latter I believe you cannot. > >> > >>I know nothing about TCNG so can't help there. > >> > >>You can shape ingress without using IMQ as long as you have just one LAN > >>interface and don't care about traffic headed for the shaping PC. You > >>just shape on the LAN interface. > > > > But *how* does such a setup now looks like, either in tcng or in gc > > syntax? > > > > This is what I actually do: [...zap...] > > > > This is my script. And I do not really now, *where* to differ > > here to once shape down-stream, and once to shape the up-stream > > > > I'd be really really very happy, if someone would point > > me in this *wrong* script to the right direction. > > You have to set you rates lower than your real rates - for ingress about > 80% so you actually get queues growing that you can control. For egress > about 85% with dsl as there are extra overheads and TC counts IP size. thx. > You should be shaping on eth0 if that's your LAN facing interface - you > shape egress from the shaping box to the LAN to do ingress (on simple > setups). The src IP match needs to change to dst. > > As it is the script may have too big queues - but should work as a test, > you may also endup wanting to split interactive traffic from bulk to > make things nicer for users - but that sort of thing is policy to be > thought about/agreed by users. This is all nice, but, I'd be happy to see some *working* example code. Tha= t's=20 why I posted my *wrong* setup, possible to point me to the right direction,= =20 by showing me, *what* I did wrong. Could someone show me some simple example code for incress+egress shaping f= or=20 ppp0 (for a router with clients at eth0)? thanks in advance, Christian Parpart. > Andy. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAj25nPpa2GmDVhK0RAg4DAJ9AQAGZgbD1UhP95azObPzsi8kvaQCeLvsC q2ELEmtQPTKWuVZu1GM7VfU=3D =3DiIPw =2D----END PGP SIGNATURE----- From andybr@bol.com.br Wed Apr 28 17:03:52 2004 From: andybr@bol.com.br (andybr) Date: Wed, 28 Apr 2004 13:03:52 -0300 Subject: [LARTC] Real IP behind SNAT Message-ID: Hi, You put in your internet (gw) eth0 an ip/30 (real ip) and in you= r ap wan with ip/30 (real ip) gw your internet gw eth0. got it? if you = use iptables to do snat don't forget to create a rule to not nat your a= p real ip ;) I hope that help you. Good Luck, Anderson > Hi= . > > I was asked to put a real IP behind a linux router > is doing s= tatic NAT for an internal network. > > > Internet (gateway) > = | > | > | > eth0 =3D real IP=0D = > ----------------- > L I N U X ROUTER > -----------------=0D = > eth1 =3D private IP > | > | > = | > eth0 =3D real IP > ----------------- > Wireless Access= Point > ----------------- > > I was asked to put a real ip (no= t to do static > NAT) in the Ethernet interface of the WAP. How can > = I do it? > > I've read some manuals and I guess I should use > the= same address with a different netmask in > WAP(eth0) and put a ro= ute in the Linux box and use > a fake arp entry in the eth0 interfac= e of the > router. > > I'd appreciate any hint you can give me. > =0D = > Regards, > Nelson.- > > -- > http://geocities.com/arhuaco > > = The first principle is that you must not fool yourself > and you are the= easiest person to fool. > -- Richard Feynman. > > =0A =0A______= ____________________________________________________________________=0AAc= abe com aquelas janelinhas que pulam na sua tela.=0AAntiPop-up UOL - =C9 = gr=E1tis!=0Ahttp://antipopup.uol.com.br/=0A From nelson@politecnica.edu.co Wed Apr 28 18:33:00 2004 From: nelson@politecnica.edu.co (Nelson E. Castillo) Date: Wed, 28 Apr 2004 12:33:00 -0500 Subject: [LARTC] Real IP behind SNAT In-Reply-To: <20040427150548.GA3655@localhost> References: <20040427141358.GA2478@mail.politecnica.edu.co> <20040427150548.GA3655@localhost> Message-ID: <20040428173300.GA5661@mail.politecnica.edu.co> --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > The best way to avoid missing something in the process of configuring > everything is to take a paper and a pen, and draw the path of the IP > packets through your network. Do everything as the operating system > would do, and do what is needed to make packets arrive at the correct > place in your network. Thanks a lot. I could use Proxy ARP. It's rather easy and it's in the HOWTO. I couldn't have done it without tcpdump... Your advice is quite generic. It reads : Learn IP and learn what the Linux kernel does with your packages :) And I know I need to do that. Is there a way to trace the flow of the packets inside of the kernel? It would be nice to have some /proc entry to watch that. I don't know whether it exists. I mean, this packet came here, and went there ... and so on. --=20 http://geocities.com/arhuaco The first principle is that you must not fool yourself and you are the easiest person to fool. -- Richard Feynman. --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkCP6swACgkQ2RNeisdKzwspKgCdG7QnLulKcXcvvF/BitRS1LKh jOEAoMKVnazPXamZPPEk9BCe4NFGJga2 =8I9W -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From stef.coene@docum.org Wed Apr 28 21:24:13 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 28 Apr 2004 22:24:13 +0200 Subject: [LARTC] HTB not obeying to specified rate? In-Reply-To: <52912.212.36.22.250.1083139672.squirrel@mail.ssi.bg> References: <52912.212.36.22.250.1083139672.squirrel@mail.ssi.bg> Message-ID: <200404282224.14274.stef.coene@docum.org> On Wednesday 28 April 2004 10:07, Anton Glinkov wrote: > here is the situation > > i am using htb.init with fwmark to do QoS. > > i have 2 parent classes with RATE=3DCEIL which then have some leafs each = on > his own. > the first one works fine (it shapes the packets to the specified rate) > > class htb 1:21 root rate 1Mbit ceil 1Mbit burst 2909b cburst 2909b > Sent 631520262 bytes 651550 pkts (dropped 0, overlimits 0) > rate 131573bps 141pps > lended: 380595 borrowed: 0 giants: 0 > tokens: -22734 ctokens: -22734 > > the rate never goes over 132000 bps. Don't trust the reported rate. > the other doesn't seem to check the rate at all. > here is the tc -s: > > class htb 1:22 root rate 448Kbit ceil 448Kbit burst 2172b cburst 2172b > Sent 337083231 bytes 522787 pkts (dropped 0, overlimits 0) > rate 71638bps 120pps > lended: 0 borrowed: 0 giants: 0 > tokens: -59999999 ctokens: -59999999 > > i tried to lower the rate (to 128Kbit) it still uses the maximum available > (sometimes goes up to 90000 bps). the same when I tried to lower the burst > and cburst. > > any ideas? Can you post your tc commands? > what do the tokens/ctokens specify? It's not good they are negative. That means the class is sendong more then= =20 the configured rate. Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From finbert@sbcglobal.net Wed Apr 28 17:37:51 2004 From: finbert@sbcglobal.net (Richard) Date: Wed, 28 Apr 2004 16:37:51 +0000 Subject: [LARTC] Wondershaper stops limiting outbound traffic Message-ID: <200404281637.51669.finbert@sbcglobal.net> I have wondershaper to limit my upload at 400kilobits (my line is 600kbps). I do a lot of torrent seeding and I dont want my pings killed when I'm uploading so I set low prority source ports as follows (by the way, I have bittornet to only use ports 6881-6910): NOPRIOPORTSRC="6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 6893 6894 6895 6896 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 6908 6909 6910" Problem is, sometimes my upload will be limited to 50kb/s and others it'll be maxed. This is with wondershaper running too! (verified by ./wshaper status). If I stop wondershaper (./wshaper stop) my outbound bandwith does nothing (as it's already maxed) but if I try to start it again, nothing happens again (yet ./wshaper status shows that wondershaper is installed). If I comment out all the SRC ports that I want no priority for, and re-run wshaper, my outbound is once again limited to 50kb/s, but my pings are horrible because all bandwith has the same priority. Some will ask why not use the torrents bandwith limitation....the answer to that is because it sucks. I have it set to 50kb/s and instead of it sataying at 50, it fluctuates up and down and AVERAGES 50kb/s. What could be causing this problem when NOPRIOPORTSRC is set to de-prioritize torrents? From x11@h2o.pieva.net Thu Apr 29 06:33:14 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 29 Apr 2004 08:33:14 +0300 Subject: [LARTC] Real IP behind SNAT In-Reply-To: <20040428173300.GA5661@mail.politecnica.edu.co> References: <20040427141358.GA2478@mail.politecnica.edu.co> <20040427150548.GA3655@localhost> <20040428173300.GA5661@mail.politecnica.edu.co> Message-ID: <4090939A.8000607@h2o.pieva.net> This is a multi-part message in MIME format. --------------060300080008070809060302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson E. Castillo wrote: > Is there a way to trace the flow of the packets > inside of the kernel? It would be nice to have > some /proc entry to watch that. I don't know > whether it exists. I mean, this packet came here, > and went there ... and so on. umm TRACE + RAW patch in iptables pom. --------------060300080008070809060302 Content-Type: text/x-vcard; charset=utf8; name="x11.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="x11.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6QXJ0PUM1PUFCcmFzID1DNT1BMGxh anVzDQpuO3F1b3RlZC1wcmludGFibGU7cXVvdGVkLXByaW50YWJsZTo9QzU9QTBsYWp1cztB cnQ9QzU9QUJyYXMNCmVtYWlsO2ludGVybmV0OngxMUBoMm8ucGlldmEubmV0DQp0ZWw7Y2Vs bDorMzcwNjg5NTg3MzMNCngtbW96aWxsYS1odG1sOkZBTFNFDQp1cmw6aHR0cDovL2gyby5z a3kubHQvDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------060300080008070809060302-- From hajer_derbel@yahoo.fr Thu Apr 29 09:42:33 2004 From: hajer_derbel@yahoo.fr (=?iso-8859-1?q?derbel=20hajer?=) Date: Thu, 29 Apr 2004 10:42:33 +0200 (CEST) Subject: [LARTC] tc class htb Message-ID: <20040429084233.76922.qmail@web20511.mail.yahoo.com> --0-1954553270-1083228153=:76595 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I am new to this group. I use this script tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1:0 classid 1:1 htb rate 500kbit ceil 500kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 300Kbit ceil 500kbit tc class add dev eth0 parent 1:1 classid 1:3 htb rate 200kbit ceil 500kbit I like to know: If two customers of the same class (for example 1:2) work simultaneously, what is that every customer is going to have the rate of this class (300Kbit for the example class 1:2) or they share this debit? Thank you for your help --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-1954553270-1083228153=:76595 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 
Hi, 
 I am new to this group.
I use this script  
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 500kbit ceil 500kbit 
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 300Kbit ceil 500kbit 
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 200kbit ceil 500kbit

I like to know:

If two customers of the same class (for example 1:2) work simultaneously, what is that every customer is going to have  the rate  of this class (300Kbit for the example class 1:2)  or they share this debit?

Thank you for your help

Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail

Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-1954553270-1083228153=:76595-- From prajith@globaledgesoft.com Thu Apr 29 12:05:36 2004 From: prajith@globaledgesoft.com (Prajith) Date: Thu, 29 Apr 2004 16:35:36 +0530 Subject: [LARTC] ALTQ - Bandwidth Manager Message-ID: <04042916353606.01059@localhost.localdomain> Hi, I have to port ALTQ(Alternate Queueing) software form the FreeBSD to QNX. It's more like a bandwidth manager. Since I am new to this domain, any kind of help will be useful. I have many doubts like * What exactly is a bandwidth manager * Where will it sit in the OS * How will it be implemented. Thanks in advance Prajith. From egon@kc.chance.cz Thu Apr 29 17:46:48 2004 From: egon@kc.chance.cz (Egon Eckert) Date: Thu, 29 Apr 2004 18:46:48 +0200 Subject: [LARTC] second routing decision--when? Message-ID: <20040429164648.GA29690@chance.cz> Hi, I'd like to mark locally generated packets in the OUTPUT chain and do policy based routing (selecting one of two default gateways) based on the mark value. But when the packet hits the OUTPUT chain (in 'mangle' table), the routing decision seems to be already made. AFAIK, locally generated packets do not pass the PREROUTING chain (so trying to mark them there wouldn't help me either). Any ideas? Sorry, haven't found this in the archive. :-) Thanks in advance, -- Egon Eckert, Prague, Czech rep. From andre.correa@pobox.com Thu Apr 29 17:22:07 2004 From: andre.correa@pobox.com (Andre Correa) Date: Thu, 29 Apr 2004 13:22:07 -0300 Subject: [LARTC] IMQ compile procedure ?? In-Reply-To: References: Message-ID: <40912BAF.8040605@pobox.com> Hi Andres, I'm sorry for not being able to contact you before but this week was full of new problems. Regarding IMQ compilation I would like to point you to our web site where you can get new patchs, find a quick updated FAQ and our mailling list. http://www.linuximq.net/ There we have all the patchs needed and keep then up-to-date with latest kernels. In you senario, kernel 2.4.26 and iptables 1.2.9, you need to: - patch your kernel using: http://www.linuximq.net/patchs/linux-2.4.24-imq.diff - configure it to enable IMQ. - recompile and install the new kernel as usual - patch iptables: we've discontinued that "patch-o-matic patch" in favor of an iptables sources patch directly: http://www.linuximq.net/patchs/IMQ.pom-ng.patch - then recompile and install iptables as usual. Be sure that libtipt_IMQ.so is installed by make install in the apropriate directory. That is all. If you need any help feel free to join our mailling list. http://groups.yahoo.com/group/linuximq Good luck! Andre ThE LinuX_KiD wrote: > Hi Guys, > > I'm trying to compile IMQ with kernel-2.4.26 and iptables-1.2.9 > and I want to know is this procedure is correct: > > ---------------------------------------- > > - In Kernel 2.4.26 Directory (/usr/src/linux) > > # cd /usr/src/linux > # wget http://www.linuximq.net/patchs/linux-2.4.24-imq.diff > # patch -p1 < linux-2.4.24-imq.diff > > - In Patch O Matic Directory (/usr/local/src/Patch-o-Matic) > > # cd /usr/local/src/Patch-o-Matic > # wget http://www.linuximq.net/patchs/pom-20030625.diff > # patch -p1 < pom-20030625.diff > > - In IP Tables 1.2.9 Directory > > ******************************************************* > HERE (I DON'T KNOW WHY), I NEED TO CHANGE DIRECTORY NAME: > ******************************************************* > > # mv /usr/local/src/iptables-1.2.9 mv /usr/local/src/userspace > > - Patch o Matic in action... > > # cd /usr/local/src/Patch-o-Matic > # ./runme --batch userspace/IMQ.patch > # ./runme --batch userspace/IMQ.patch.ipv6 > # chmod 0755 ../userspace/extensions/.IMQ* > # ./runme userspace/IMQ.patch > # ./runme --batch extra/CONNMARK.patch > > > - Next, compile Kernel.... > > - Next, recompile IP Tables... and that is all (?) > > > > Andres... > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From egon@kc.chance.cz Thu Apr 29 18:31:48 2004 From: egon@kc.chance.cz (Egon Eckert) Date: Thu, 29 Apr 2004 19:31:48 +0200 Subject: [LARTC] Problems balancing two uplink providers In-Reply-To: <1083019087.8006.31.camel@pikachu.casa> References: <1083019087.8006.31.camel@pikachu.casa> Message-ID: <20040429173148.GB29690@chance.cz> > IP eth0: 80.27.46.168/26 > IP eth1: 217.12.112.190/30 > IP eth2: 192.168.239.15/24 > > Routing rules: > > ip route add 80.27.46.128 dev eth0 src 80.27.46.168 table T1 > ip route add default via 80.27.46.129 table T1 > ip route add 80.27.46.128 dev eth0 src 80.27.46.168 > > ip route add 217.12.112.188 dev eth1 src 217.12.112.190 table T2 > ip route add default via 217.12.112.189 table T2 > ip route add 217.12.112.188 dev eth1 src 217.12.112.190 I may not solve your problem, but... Shouldn't be the address in the "-net" routes followed by "/26" and "/30", respectively? Egon From damion@snapgear.com Fri Apr 30 00:43:26 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 30 Apr 2004 09:43:26 +1000 Subject: [LARTC] tc class htb In-Reply-To: <20040429084233.76922.qmail@web20511.mail.yahoo.com> References: <20040429084233.76922.qmail@web20511.mail.yahoo.com> Message-ID: <4091931E.6070409@snapgear.com> Hi, > tc qdisc add dev eth0 root handle 1: htb > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 500kbit ceil 500kbit > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 300Kbit ceil 500kbit > tc class add dev eth0 parent 1:1 classid 1:3 htb rate 200kbit ceil 500kbit > > I like to know: > If two customers of the same class (for example 1:2) work > simultaneously, what is that every customer is going to have the rate > of this class (300Kbit for the example class 1:2) or they share this > debit? Everyone in the same class (1:2) shares the same rate and ceiling. regards, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- From alex@pilosoft.com Fri Apr 30 02:31:18 2004 From: alex@pilosoft.com (alex@pilosoft.com) Date: Thu, 29 Apr 2004 21:31:18 -0400 (EDT) Subject: [LARTC] ALTQ - Bandwidth Manager In-Reply-To: <04042916353606.01059@localhost.localdomain> Message-ID: a) this has nothing to do with Linux. b) if you have to ask these questions, you will not be able to do it. -alex On Thu, 29 Apr 2004, Prajith wrote: > Hi, > > I have to port ALTQ(Alternate Queueing) software form the FreeBSD to QNX. > It's more like a bandwidth manager. > > Since I am new to this domain, any kind of help will be useful. > > I have many doubts like > > * What exactly is a bandwidth manager > * Where will it sit in the OS > * How will it be implemented. > > Thanks in advance > Prajith. > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From alex@pilosoft.com Fri Apr 30 02:29:44 2004 From: alex@pilosoft.com (alex@pilosoft.com) Date: Thu, 29 Apr 2004 21:29:44 -0400 (EDT) Subject: [LARTC] second routing decision--when? In-Reply-To: <20040429164648.GA29690@chance.cz> Message-ID: Unfortunately, not that easy. Look at ipt_ROUTE (from netfilter) to do it. -alex On Thu, 29 Apr 2004, Egon Eckert wrote: > Hi, > > I'd like to mark locally generated packets in the OUTPUT chain and do > policy based routing (selecting one of two default gateways) based on > the mark value. > > But when the packet hits the OUTPUT chain (in 'mangle' table), the > routing decision seems to be already made. AFAIK, locally generated > packets do not pass the PREROUTING chain (so trying to mark them there > wouldn't help me either). > > Any ideas? > > Sorry, haven't found this in the archive. :-) > > Thanks in advance, > > From john.sinclair@hushmail.com Fri Apr 30 04:23:16 2004 From: john.sinclair@hushmail.com (john.sinclair@hushmail.com) Date: Thu, 29 Apr 2004 20:23:16 -0700 Subject: [LARTC] Load-balancing with multipath routes (1 NIC + 2 GWs) Message-ID: <200404300323.i3U3NHbY001441@mailserver1.hushmail.com> Greetings, I'm trying to set up some sort of load-balancing on a Linux (Trustix) gateway by using multipath routes, however I'm stuck with some problems. The idea is that this gateway (odd as it may seem) only has one external interface, which should route packets to two different gateways (Ciscos). The gateway's external interface and the routers are all on the same network, so this is a slightly different set up than the one described in Linux Adv Routing HOWTO. I successfully defined the multipath route, with two equal cost routes. However, it doesnt matter how much traffic I generate on the gateway (using many simultaneous wgets in mirror mode), it doesnt seem to distribute the load among the two gateways, always using only one of them. I tried both using and not using equalize, with the same result. I was carefull to flush the route cache between each attempt. Has anyone tried a similar setup (single interface + two gateways)? Is this the proper way of doing such set up? Considering both routers are on the same network of the gateway's external ínterface (and I cannot change that), would there be any other alternative? Would I absolutely need Julian Anastasov's patches for that matter? Here's how my routing table looks like (IPs changed to protect the innocent): js@virtual ~$ ip route show 200.X.Y.0/24 dev eth0 proto kernel scope link src 200.X.Y.1 127.0.0.0/8 dev lo scope link default nexthop via 200.X.Y.2 dev eth0 weight 1 nexthop via 200.X.Y.3 dev eth0 weight 1 js@virtual ~$ Any help would be greatly appreciated! Regards, John Sinclair Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From prajith@globaledgesoft.com Fri Apr 30 04:41:33 2004 From: prajith@globaledgesoft.com (Prajith) Date: Fri, 30 Apr 2004 09:41:33 +0600 Subject: [LARTC] ALTQ - Bandwidth Manager References: Message-ID: <006301c42e65$08524340$2f0210ac@ges> Hi, I believe people in this group can help me by providing valuable information about the Bandwidth Manager and its implementation. That's why I mailed to this group. I know this particular project is nothing to do with Linux. Alex, it's sad to see a discouraging sentence from U. Anyhow, whatever may come, I decided to do this project. So still people can help me by providing some valuable documents or URL. Regards Prajith. ----- Original Message ----- From: To: Prajith Cc: Sent: Friday, April 30, 2004 7:31 AM Subject: Re: [LARTC] ALTQ - Bandwidth Manager > a) this has nothing to do with Linux. > b) if you have to ask these questions, you will not be able to do it. > > -alex > > On Thu, 29 Apr 2004, Prajith wrote: > > > Hi, > > > > I have to port ALTQ(Alternate Queueing) software form the FreeBSD to QNX. > > It's more like a bandwidth manager. > > > > Since I am new to this domain, any kind of help will be useful. > > > > I have many doubts like > > > > * What exactly is a bandwidth manager > > * Where will it sit in the OS > > * How will it be implemented. > > > > Thanks in advance > > Prajith. > > > > > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > From brian.nox@ya.com Fri Apr 30 08:00:10 2004 From: brian.nox@ya.com (Brian Nox) Date: Fri, 30 Apr 2004 09:00:10 +0200 Subject: [LARTC] ALTQ - Bandwidth Manager In-Reply-To: <006301c42e65$08524340$2f0210ac@ges> References: <006301c42e65$08524340$2f0210ac@ges> Message-ID: <4091F97A.3000102@ya.com> >I decided to do this project. So still people can help me by providing >some valuable documents or URL. > > > Try with: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO [go to chap 19] http://www.kerneltraffic.org/kernel-traffic/index.html http://tcng.sourceforge.net/ Good luck Prajith. From prajith@globaledgesoft.com Fri Apr 30 09:31:04 2004 From: prajith@globaledgesoft.com (Prajith) Date: Fri, 30 Apr 2004 14:31:04 +0600 Subject: [LARTC] ALTQ - Bandwidth Manager References: <006301c42e65$08524340$2f0210ac@ges> <4091F97A.3000102@ya.com> Message-ID: <008901c42e8d$7a2f4080$2f0210ac@ges> Thank You Brian Many of these documents definitely help me. -Prajith. ----- Original Message ----- From: Brian Nox To: Prajith ; Sent: Friday, April 30, 2004 1:00 PM Subject: Re: [LARTC] ALTQ - Bandwidth Manager > > >I decided to do this project. So still people can help me by providing > >some valuable documents or URL. > > > > > > > Try with: > http://www.tldp.org/HOWTO/Adv-Routing-HOWTO [go to chap 19] > http://www.kerneltraffic.org/kernel-traffic/index.html > http://tcng.sourceforge.net/ > > Good luck Prajith. > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From andy.furniss@dsl.pipex.com Fri Apr 30 10:07:29 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Fri, 30 Apr 2004 10:07:29 +0100 Subject: [LARTC] Wondershaper stops limiting outbound traffic In-Reply-To: <200404281637.51669.finbert@sbcglobal.net> References: <200404281637.51669.finbert@sbcglobal.net> Message-ID: <40921751.6090005@dsl.pipex.com> Richard wrote: > I have wondershaper to limit my upload at 400kilobits (my line is 600kbps). > > I do a lot of torrent seeding and I dont want my pings killed when I'm > uploading so I set low prority source ports as follows (by the way, I have > bittornet to only use ports 6881-6910): That means BT will listen on those ports. Even if you just seed, it will still connect to others - so the src port will be different. The dst port will usually be a standard BT one - but only as long as the peer didn't tell BT to listen on different ports. To mark BT properly you need something that looks at the data like ipp2p - this needs a netfilter extra POM patch (connmark) to work. http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html Andy. > > NOPRIOPORTSRC="6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 > 6893 6894 6895 6896 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 > 6908 6909 6910" > > Problem is, sometimes my upload will be limited to 50kb/s and others it'll be > maxed. This is with wondershaper running too! (verified by ./wshaper > status). > > If I stop wondershaper (./wshaper stop) my outbound bandwith does nothing (as > it's already maxed) but if I try to start it again, nothing happens again > (yet ./wshaper status shows that wondershaper is installed). If I comment > out all the SRC ports that I want no priority for, and re-run wshaper, my > outbound is once again limited to 50kb/s, but my pings are horrible because > all bandwith has the same priority. > > Some will ask why not use the torrents bandwith limitation....the answer to > that is because it sucks. I have it set to 50kb/s and instead of it sataying > at 50, it fluctuates up and down and AVERAGES 50kb/s. > > What could be causing this problem when NOPRIOPORTSRC is set to de-prioritize > torrents? > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From stef.coene@docum.org Fri Apr 30 13:29:13 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 30 Apr 2004 14:29:13 +0200 Subject: [LARTC] ALTQ - Bandwidth Manager In-Reply-To: <4091F97A.3000102@ya.com> References: <006301c42e65$08524340$2f0210ac@ges> <4091F97A.3000102@ya.com> Message-ID: <200404301429.13770.stef.coene@docum.org> On Friday 30 April 2004 09:00, Brian Nox wrote: > >I decided to do this project. So still people can help me by providing > >some valuable documents or URL. > > Try with: > http://www.tldp.org/HOWTO/Adv-Routing-HOWTO [go to chap 19] > http://www.kerneltraffic.org/kernel-traffic/index.html > http://tcng.sourceforge.net/ More pratical info: http://docum.org/ (I agree with Alex) Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From jago25_98@catholic.org Sat May 1 14:14:22 2004 From: jago25_98@catholic.org (Jago Pearce) Date: Sat, 1 May 2004 13:14:22 -0000 (GMT) Subject: [LARTC] Managed switch? | PRIO chain Message-ID: <36893.141.163.84.1.1083417262.squirrel@webmail.catholic.org> Saw this command on slashdot (http://ask.slashdot.org/article.pl?sid=04/03/24/0434224&mode=flat&tid=126&tid=95 ) to basically make a box behave like a managed switch: "tc qdisc add dev eth1 root tbf rate 250kbit latency 20ms burst 2kb" Followup: http://ask.slashdot.org/comments.pl?sid=101542&threshold=-1&commentsort=3&tid=126&tid=95&mode=flat&pid=8653105 Will this work? Is there a simpler way to have traffic forwarded between 2 interfaces (or ip's??) to behave like a managed switch? Also: Still no howto on the PRIO chain? This chain is the simplest and probably fine for most home users. Thing is, there isn't a howto dedicated to it, it's covered only in passing in other howto's and been mentioned a bit on the mailing list. Has anyone used this chain and was it good enough for your basic "I've got DSL at home and I want to give port 80 pririty over p2p" style basic tasks? -- Catholic.org is just my email provider, my main email. jago25_98@hotmail.com is my spammail account. ----------------------------------------- This email was sent using FREE Catholic Online Webmail! http://webmail.catholic.org/ From Andreas.Klauer@metamorpher.de Mon May 3 00:58:08 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Mon, 3 May 2004 01:58:08 +0200 Subject: [LARTC] tc class htb In-Reply-To: <20040429084233.76922.qmail@web20511.mail.yahoo.com> References: <20040429084233.76922.qmail@web20511.mail.yahoo.com> Message-ID: <200405030158.08671.Andreas.Klauer@metamorpher.de> Am Thursday 29 April 2004 10:42 schrieb derbel hajer: > If two customers of the same class (for example 1:2) work > simultaneously, what is that every customer is going to have They will both use the bandwidth the class provides. If the class is at it's limit, they'll steal each others bandwidth, since HTB doesn't care where the traffic comes from. If you want fair sharing between the two customers, you have to give each of them their own class. Andreas From Andreas.Klauer@metamorpher.de Mon May 3 00:44:34 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Mon, 3 May 2004 01:44:34 +0200 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <200404281042.18011.cparpart@surakware.net> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <408CC1DE.10704@dsl.pipex.com> <200404281042.18011.cparpart@surakware.net> Message-ID: <200405030144.35001.Andreas.Klauer@metamorpher.de> Am Wednesday 28 April 2004 10:42 schrieb Christian Parpart: > Could someone show me some simple example code for incress+egress > shaping for ppp0 (for a router with clients at eth0)? Maybe my script will do: http://www.metamorpher.de/ipshape/ I don't know about 'simple', but I got a script designed for routers in general which have to provide masquerading, port forwarding and traffic shaping for several clients in the LAN. Even if it looks a bit complicated here and there, I think I got it well documented, though. It looks pretty similar to what you were trying to do. I created this with the help of LARTC (Howto, Stef's docum.org, and of course this list) and it has grown a lot lately :-) You can specify the IPs of your clients, and bandwidth will be shared in a fair manner among them. I use HTB, PRIO and SFQ to do that. It works well for me, but I'm sure that there is still LOADS of stuff that can be improved. I'm always open for suggestions :-) Andreas From Andreas.Klauer@metamorpher.de Mon May 3 00:52:49 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Mon, 3 May 2004 01:52:49 +0200 Subject: [LARTC] Managed switch? | PRIO chain In-Reply-To: <36893.141.163.84.1.1083417262.squirrel@webmail.catholic.org> References: <36893.141.163.84.1.1083417262.squirrel@webmail.catholic.org> Message-ID: <200405030152.49327.Andreas.Klauer@metamorpher.de> Am Saturday 01 May 2004 15:14 schrieb Jago Pearce: > Still no howto on the PRIO chain? PRIO is documented in the LARTC Howto. Compared to monsters like CBQ, there's not really much you can say about it. > Has anyone used this chain and was it good enough for your basic "I've > got DSL at home and I want to give port 80 pririty over p2p" style basic > tasks? I use PRIO in combination with HTB and SFQ. Yes, it does help a lot. I don't know if it alone is sufficient for P2P stuff, though. I think it helps a lot for me because I do a lot of the TOS modification stuff that's listed on www.docum.org (great page, btw. ;) About P2P, I always wanted to have a closer look on IPP2P, which is a kernel/iptables patch designed to provide a reliable way to detect P2P traffic. However, whenever I tried, I couldn't get it to work. And it seems that the current version is incompatible with kernel 2.4.25 and above. Maybe it's time to upgrade my debian router to 2.6 kernel? Andreas From jsimo@gbt.tfo.upm.es Mon May 3 07:40:57 2004 From: jsimo@gbt.tfo.upm.es (Francisco Javier Simo Reigadas) Date: Mon, 03 May 2004 08:40:57 +0200 Subject: [LARTC] QoS in wireless networks In-Reply-To: <20040503051358.15054.5837.Mailman@outpost.ds9a.nl> References: <20040503051358.15054.5837.Mailman@outpost.ds9a.nl> Message-ID: <4095E979.9080706@gbt.tfo.upm.es> Hello, I'm trying to configure several wireless routers with QoS support. The idea is to implement differentiated services so that VoIP traffic gets the maximal priority, then video, control traffic, interactive data traffic and best-effort traffic. I have seen that CBQ used to be chosen as qdisc for implementing bandwith share in DiffServ but now HTB is preferred because it is simpler and more understandable. However, I see a problem with HTB in wireless networks: sometimes the available bandwith fluctuates due to interferences, retransmissions, etc, and then I don't know if HTB fits well for that. żWhat is the real effect of sharing 5Mbps among traffic classes with HTB if the real bandwith dropped to 1Mbps? żIs CBQ better for these cases where the bandwith to share is not stable? Thanks in advance Javier From ferenc.kubinszky@wit.mht.bme.hu Mon May 3 08:57:20 2004 From: ferenc.kubinszky@wit.mht.bme.hu (Ferenc Kubinszky) Date: Mon, 3 May 2004 09:57:20 +0200 (CEST) Subject: [LARTC] QoS in wireless networks In-Reply-To: <4095E979.9080706@gbt.tfo.upm.es> Message-ID: Hello, On Mon, 3 May 2004, Francisco Javier Simo Reigadas wrote: > > I'm trying to configure several wireless routers with QoS support. The > idea is to implement differentiated services so that VoIP traffic gets > the maximal priority, then video, control traffic, interactive data > traffic and best-effort traffic. Good luck ;} > > I have seen that CBQ used to be chosen as qdisc for implementing > bandwith share in DiffServ but now HTB is preferred because it is > simpler and more understandable. However, I see a problem with HTB in > wireless networks: sometimes the available bandwith fluctuates due to > interferences, retransmissions, etc, and then I don't know if HTB fits > well for that. żWhat is the real effect of sharing 5Mbps among traffic > classes with HTB if the real bandwith dropped to 1Mbps? żIs CBQ better > for these cases where the bandwith to share is not stable? But seriously... There are many problems with QoS on a wireless (802.11) networks. QoS mechanisms impelented by HTB, CBQ etc. are designed for a dedicated point-to-point link with full controll all the queues at the sender side. Today IEEE 802.11 does not support QoS at the link layer. All packets are equal in the air. Moreover access points have exactly the same chance to access the channel as clients have. It provides a half-duplex link, so packets for uplink and downlink direction have to contend. Just like a HUB... A HUB where packets can be transmitted at lower speed, packets may collide, a destination station may disappear. It is impossible to provide hard QoS, only some statistical QoS. First forget the "bad channel" (packet loss, lower rate trasmit etc) a bit. IEEE 802.11 provides a fair channel access for all the nodes including APs and clients. (I do not know about PCF mode implemented) It means if the channel is full (nodes have some backlogged packets) a node has to wait N-1 packets before access the channel where N is the number of backlogged nodes. Note it is true statistically and we do not care the bad channel. So it the best that can happen ;} Not so good, but there is still some chances... If you do not overload the channel nodes will not have backlog. (in long term, in short term there might some) First you must be sure that VoIP traffic will use only a fraction of the capacity. Usually it is true. After that you must keep best effort traffic below the maximal capacity. It is not so easy, because uplink and downlink shares the same medium, so the must be summed. Like this: BE_BW = BE_BW_DL+BE_BW_UL <= WLAN_BW - RT_BW_UL - RT_BW_DL - GUARD_BW where BE_BW_DL: downlink best effort rate. You can control it easily at the AP (or the router before the AP) BE_BW_UL: uplink direction. You can control it in the clients, but who tell them how much bandwidth can the use? With TCP you can use ingress filter in the AP, it will work fine. You have no chance against UDP :( WLAN_BW: How much is it really? Max 6Mbit/s for a "11mbps" wlan, but there are still some "bad channel" effect. RT_BW_UL, RT_BW_UL: It has to be measured. Or neglected if you can. GUARD_BW: The channel must not be overloaded. And we neglected the real time traffic. It is not so difficult to build as it looks like ;} If it is possible to separate bandwidth for uplink and downlink direction (eg. no web/ftp server in the clinets), you can alocate X mbit/s for downlink and Y mbit/s for uplink and control the two direction. Note that uplink trafic should be TCP to be able to control it through ingress filters and rate policers. If you want to build a more flexible network you may use IMQ device. I haven't used it because the required kernel and TC patches. But if you manage it you can sum uplink and downlink traffic. Somehow... You mentioned there are streaming and real time video traffic in your network. Are there any uplink UDP video? There should not be any, or you have to build a complex bandwidth controller in each nodes. Best regards, Ferenc From jsimo@gbt.tfo.upm.es Mon May 3 09:53:48 2004 From: jsimo@gbt.tfo.upm.es (Francisco Javier Simo Reigadas) Date: Mon, 03 May 2004 10:53:48 +0200 Subject: [LARTC] QoS in wireless networks In-Reply-To: References: Message-ID: <4096089C.6020304@gbt.tfo.upm.es> >There are many problems with QoS on a wireless (802.11) networks. >QoS mechanisms impelented by HTB, CBQ etc. are designed for a dedicated >point-to-point link with full controll all the queues at the sender side. > >Today IEEE 802.11 does not support QoS at the link layer... > I know, I have written myself that sencence several times in other documents :-) In my previous message I should have written "partial QoS support". >It is impossible to provide hard QoS, only some statistical QoS. > > I aggree. >IEEE 802.11 provides a fair channel access for all the nodes including APs >and clients. (I do not know about PCF mode implemented) > > It seems that it was abandoned because it didn't work as expected, only private extensions like Karlnet's Turbocell can do that (polling from a central point) and I am not interested in private extensions. >After that you must keep best effort traffic >below the maximal capacity. It is not so easy, because uplink and downlink >shares the same medium, so the must be summed. >Like this: > BE_BW = BE_BW_DL+BE_BW_UL <= WLAN_BW - RT_BW_UL - RT_BW_DL - GUARD_BW >where > > > > I have implemented something already and it works in the laboratory, the problem is that we cannot know how much is WLAN_BW. At the lab we can have 6Mbps and then doing a good outdoor installation with long links, the same configuration drops to 1Mbps or less, and that can still change as the weather evolves. That is why I made the question in the list: I can say that I have 6Mbps in the laboratory and then I create a HTB with subclasses, I reserve 1Mbps for VoIP and 5Mbps for BE; fine, it works. But what is going to happen when the real troughput drops? That doesn't happen in wired LANs (it happened in old phone connections though) but is very common in wireless longhaul installations. Let's put those well configured routers in their outdoor possitions, separated 15miles one from the other. The same configuration will then give a throughput of 1Mbps or less. How HTB is going to do? I VoIP going to get the whole link? is BE going to collapse the link? are they going to get proportional shares (170kbps/830kbps) ? And, as opposed to HTB, what would be the behaviour of CBQ in the same situation? That is my doubt. >You mentioned there are streaming and real time video traffic in your >network. Are there any uplink UDP video? There should not be any, or you >have to build a complex bandwidth controller in each nodes. > > Yes, we will do videoconference, there will be UDP audio and video in both uplink and downlink. Thanks Ferenc for your message Javier From hajer_derbel@yahoo.fr Mon May 3 10:33:19 2004 From: hajer_derbel@yahoo.fr (=?iso-8859-1?q?derbel=20hajer?=) Date: Mon, 3 May 2004 11:33:19 +0200 (CEST) Subject: [LARTC] htb bandwith In-Reply-To: <4096089C.6020304@gbt.tfo.upm.es> Message-ID: <20040503093319.80082.qmail@web20504.mail.yahoo.com> --0-63279119-1083576799=:79412 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000Kbit ceil 2000kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1200Kbit ceil 2000kbit tc class add dev eth0parent 1:1 classid 1:3 htb rate 800Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:21 htb rate 600Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:22 htb rate 300Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:23 htb rate 200Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:24 htb rate 100Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:31 htb rate 400Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:32 htb rate 300Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:33 htb rate 100Kbit ceil 2000kbit By using this script, the class 1: 2 can it borrow of the bandwidth not used by the class 1: 3 (the classes 1:2 and 1:3 can she borrow of the busy band among them). I want to control the used and free busy band during time. For it there, I used the command: tc –s class ls dev eth0. Which are the information supplied by this command, which I should control to draft my interpretations on the use of the busy band. tkanks in advance --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-63279119-1083576799=:79412 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 
Hi,
tc qdisc add dev eth0 root handle 1: htb 
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000Kbit  ceil 2000kbit
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1200Kbit ceil 2000kbit
tc class add dev eth0parent 1:1 classid 1:3 htb rate 800Kbit ceil 2000kbit
 tc class add dev eth0 parent 1:2 classid 1:21 htb rate 600Kbit ceil 2000kbit
tc class add dev eth0 parent 1:2 classid 1:22 htb rate 300Kbit ceil 2000kbit
tc class add dev eth0 parent 1:2 classid 1:23  htb rate 200Kbit ceil 2000kbit
tc class add dev eth0 parent 1:2 classid 1:24 htb rate 100Kbit ceil 2000kbit
 
 tc class add dev eth0 parent 1:3 classid 1:31 htb rate 400Kbit ceil 2000kbit
tc class add dev eth0 parent 1:3 classid 1:32 htb rate 300Kbit ceil 2000kbit
tc class add dev eth0 parent 1:3 classid 1:33 htb rate 100Kbit ceil 2000kbit
By using this script, the class 1: 2 can it borrow of the bandwidth not used
 
by the class 1: 3 (the classes 1:2 and 1:3 can she borrow of the busy band among them).
 
I want to control the used and free busy band during time. 
For it there, I used the command: tc –s class ls dev eth0. 
Which are the information supplied by this command, which I 
should control to draft my interpretations on the use of the busy 
band.
tkanks in advance

Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail

Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-63279119-1083576799=:79412-- From lartc@nospam.otaku42.de Mon May 3 10:35:21 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Mon, 03 May 2004 11:35:21 +0200 Subject: [LARTC] QoS in wireless networks In-Reply-To: <4096089C.6020304@gbt.tfo.upm.es> References: <4096089C.6020304@gbt.tfo.upm.es> Message-ID: <40961259.6070107@otaku42.de> Hi. Francisco Javier Simo Reigadas wrote: >> IEEE 802.11 provides a fair channel access for all the nodes including >> APs and clients. (I do not know about PCF mode implemented) > It seems that it was abandoned because it didn't work as expected, It's not abandoned, but it's an optional feature that mostly none AP has implemented. And it's not a complete protocol afair, but only a framework that leaves much room for the actual implementation. > only private extensions like Karlnet's Turbocell can do that (polling > from a central point) While Karlnet's Turbocell implements central polling, it does not make use of PCF. Instead, the stations work in DCF, and all traffic is transmitted as broadcasts (thus getting rid of 802.11 ACKs which gives some additional bandwidth). Downside: they loose the ability to have automatic rate selection. > and I am not interested in private extensions. Maybe you'll also consider this as private extension, but you might be interested in some "DCF-based polling protocol" implementations running under Linux: frottle: http://frottle.sourceforge.net/ WiCCP: http://patraswireless.net/software.html pewit: http://savannah.nongnu.org/projects/pewit While they all perform a similar goal (implementation of a polling protocol on top of a normal ethernet link) they use different techniques to achieve their goal. But they all are not depending on a special device driver, so you can still choose your hardware freely. And maybe also this link is of interest: http://wsched.sourceforge.net/ "While the H-FSC qdisc can be used in a usual wireline environment (e.g. replacing the standard CBQ scheduler), the purpose of the port to Linux was to use it as a basis for the prototype implementation of a new form of wireless link-sharing. The basic problem is that in a wireless environment the amount of resources consumed in order to transmit X bytes to a mobile destination depends on the quality of the link to this station. The link-sharing model developed during the project allows the integration of goodput and resource-consumption oriented criteria in hierarchies for wireless link-sharing. Furthermore, the model can be used with currently available hardware because it can be implemented above the link layer. For detailed information take a look at the documents listed in the Documentation section." They have two interesting papers about their work online: "Packet scheduling for bandwidth sharing and quality of service support in wireless local area networks" and "A resource-based approach to MAC layer independent hierarchical link-sharing in wireless local area networks", explaining the ideas behind their scheduler. Bye, Mike From netadmin@neosoft-tec.com Mon May 3 11:23:45 2004 From: netadmin@neosoft-tec.com (Netadmin) Date: Mon, 3 May 2004 15:53:45 +0530 Subject: [LARTC] unsubscribe Message-ID: <000e01c430f8$b7707640$4b00a8c0@pc75> This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C43126.D0F657A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable thanks ------=_NextPart_000_000B_01C43126.D0F657A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
thanks
------=_NextPart_000_000B_01C43126.D0F657A0-- From hajer_derbel@yahoo.fr Mon May 3 12:54:09 2004 From: hajer_derbel@yahoo.fr (=?iso-8859-1?q?derbel=20hajer?=) Date: Mon, 3 May 2004 13:54:09 +0200 (CEST) Subject: [LARTC] htb bandwith In-Reply-To: <20040503115052.9152.qmail@web20511.mail.yahoo.com> Message-ID: <20040503115409.29018.qmail@web20513.mail.yahoo.com> --0-1317867387-1083585249=:27433 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000Kbit ceil 2000kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1200Kbit ceil 2000kbit tc class add dev eth0parent 1:1 classid 1:3 htb rate 800Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:21 htb rate 600Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:22 htb rate 300Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:23 htb rate 200Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:24 htb rate 100Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:31 htb rate 400Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:32 htb rate 300Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:33 htb rate 100Kbit ceil 2000kbit By using this script, the class 1: 2 can it borrow of the bandwidth not used by the class 1: 3 (the classes 1:2 and 1:3 can she borrow of the busy band among them). I want to control the used and free busy band during time. For it there, I used the command: tc –s class ls dev eth0. Which are the information supplied by this command, which I should control to draft my interpretations on the use of the bandwidth. tkanks in advance --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-1317867387-1083585249=:27433 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 
Hi,
tc qdisc add dev eth0 root handle 1: htb 
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000Kbit  ceil 2000kbit
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1200Kbit ceil 2000kbit
tc class add dev eth0parent 1:1 classid  1:3 htb rate 800Kbit ceil 2000kbit
 tc class add dev eth0 parent 1:2 classid 1:21 htb rate 600Kbit ceil 2000kbit
tc class add dev eth0 parent 1:2 classid 1:22 htb rate 300Kbit ceil 2000kbit
tc class add dev eth0 parent 1:2 classid 1:23  htb rate 200Kbit ceil 2000kbit
tc class add dev eth0 parent 1:2 classid 1:24 htb rate 100Kbit ceil 2000kbit
 
 tc class add dev eth0 parent 1:3 classid 1:31 htb rate 400Kbit ceil 2000kbit
tc class add dev eth0 parent 1:3 classid 1:32 htb rate 300Kbit ceil 2000kbit
tc class add dev eth0 parent 1:3 classid 1:33 htb rate 100Kbit ceil 2000kbit
By using this script, the class 1: 2 can it borrow of the 
bandwidth not used by the class 1: 3 (the classes 1:2 and 
1:3 can she borrow of the busy band among them).
 
I want to control the used and free busy band during time. 
For it there, I used the command: tc –s class ls dev eth0. 
Which are the information supplied by this command, which I 
should control to draft my interpretations on the use of the bandwidth.
 
tkanks in advance

Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail

Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-1317867387-1083585249=:27433-- From pturley@rocksteady.com Mon May 3 22:19:16 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 03 May 2004 16:19:16 -0500 Subject: [LARTC] Port forwarding/translation control Message-ID: <4096B754.3030708@rocksteady.com> My Linux system is acting as a NAT'ing firewall, and I have some rules for doing port forwarding/translation. I was thinking about this the other day and I realized that there are other parts of the system that consume ports. Specifically, NAT and ephemeral port allocation. It occurs to me that I could potentially have a conflict. If I set up a rule to forward/translate a port, and the NAT'ing code picks the same port for what it's doing, then there would be a big problem. Eventually, I'll need to dynamically allocate ports of my own for transitory port forwarding/translation. I need a way to set aside some ports that I can use sure the NAT'ing code and the ephemeral port allocation code won't try to use. If anyone has anything illuminating to say on this point, I'd be very grateful. From EyeManBill@aol.com Tue May 4 01:33:27 2004 From: EyeManBill@aol.com (EyeManBill@aol.com) Date: Mon, 03 May 2004 20:33:27 -0400 Subject: [LARTC] Are multiple output queues in qdisc possible? Message-ID: <52E3FE33.0FB6EAD8.0B6A2FAE@aol.com> Our system sets up multiple connections. At times, packets can be transmitted for some connections but not others. With that in mind: 1. Is it possible to have multiple output queues in a qdisc, rather than one? 2. Can a packet that leaves qdisc be returned to qdisc if it cannot be transmitted? If so, how? Thank you. From rabbit@rabbit.us Tue May 4 05:00:40 2004 From: rabbit@rabbit.us (Peter Rabbitson) Date: Mon, 3 May 2004 23:00:40 -0500 Subject: [LARTC] T1 (hardware pre-shaped) shaping question Message-ID: <006b01c4318c$5dacba80$020da8c0@rabbit> Hello list. I have been trying to figure this out on my own, but I guess I somewhat failed :) A linux router with external eth0 and internal eth1 acts as a gateway for a number of machines utilizing a partial T1 line (512kbps). Since the T1 is limited by hardware and by its nature to 64kbps per channel the most I can pump out of it is up+down < 512kbps. If a number of workstations amount to more than this limit the connection starts to choke e.g. delivers very low performance even on simple http requests. Right now I have HTBs installed on both eth0 and eth1. The HTB with subclasses on eth0 governs outgoing traffic (smtp and http). The HTB on eth1 on the other hand covers all request from the internal clients (http, streaming audio etc). Everything works well except the fact that both shaping trees have no idea about each other. Do I have the ability to tie them together so COMBINED they do not exceed 512k? For example somebody from the internet is pulling a file by http on eth0 and I am pumping out smtp, totalling 56k/s. The workstation of my webmaster tries to download a file through eth1 , and since it has priority the outgoing traffic on eth0 is cut down to 30k/s and the webmaster gets an incomming channel through eth0 --> eth1 --> workstation of 32k/s with some leftovers for TCP checksums. Is this feasible? Or is there another traffic shaping model different from tc that would treat eth0 as a two way pipe? Thank you for your replies. Peter From nikolov@kuzelnet.org Tue May 4 09:35:19 2004 From: nikolov@kuzelnet.org (nikolov@kuzelnet.org) Date: Tue, 4 May 2004 10:35:19 +0200 Subject: [LARTC] problem with wrong speeds Message-ID: <1443961970.20040504103519@kuzelnet.org> Hello everyone, I just found very strange problem. I have a big class with 5500 KBit bandwidth, and a lot of smaller for which this one is their parent. Some of them are with rate 64 and ceil 1024 and other are with rate 256 and ceil pceil (5500). All filters are using mark from iptables. The strange thing is that noone can get more of about 60% of its ceil even if the parent class is almost free. Thats my parent class: class htb 1:2309 root rate 5500Kbit ceil 5500Kbit burst 8638b cburst 8638b Sent 51543995 bytes 41551 pkts (dropped 0, overlimits 0) rate 133323bps 104pps lended: 28949 borrowed: 0 giants: 0 tokens: 8170 ctokens: 8170 the rate is about 133 KBps which is about 1000 Kbit (our class has 5500) now we look at some of the children classess class htb 1:3632 parent 1:2309 prio 4 rate 64Kbit ceil 1020Kbit burst 1680b cburst 2904b Sent 24009127 bytes 15880 pkts (dropped 4687, overlimits 0) rate 62900bps 41pps lended: 2109 borrowed: 13771 giants: 0 tokens: -364219 ctokens: -13866 class htb 1:3620 parent 1:2309 prio 4 rate 64Kbit ceil 1020Kbit burst 1680b cburst 2904b Sent 25147025 bytes 16660 pkts (dropped 4957, overlimits 0) rate 65953bps 43pps backlog 1p lended: 2152 borrowed: 14507 giants: 0 tokens: -237551 ctokens: -33322 there no other classes that do more then some 1-2 kbps transfers at the time of this check. As you can see there is alot of free speed, but the two classes are shaped at about 65 KBps - packets are being dropped. The interface is VLAN interface and the classes are added like this: tc qdisc del dev eth2.1248 root tc qdisc add dev eth2.1248 root handle 1 htb default 0 ---for the parent class--- tc class add dev eth2.1248 parent 1:0 classid 1:2309 htb rate 5500Kbit prio 4 tc qdisc add dev eth2.1248 parent 1:2309 handle 2309 sfq perturb 10 --- ---for the children classes--- tc class add dev eth2.1248 parent 1:2309 classid 1:3632 htb rate 64Kbit ceil 1020Kbit prio 4 tc filter add dev eth2.1248 parent 1:0 protocol ip prio 150 handle 3632 fw classid 1:3632 --- Any suggestions and help will be highly appreciated! Thanks in advance to all of you! Best regards, Ilian From stef.coene@docum.org Tue May 4 11:51:14 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 4 May 2004 12:51:14 +0200 Subject: [LARTC] T1 (hardware pre-shaped) shaping question In-Reply-To: <006b01c4318c$5dacba80$020da8c0@rabbit> References: <006b01c4318c$5dacba80$020da8c0@rabbit> Message-ID: <200405041251.14483.stef.coene@docum.org> On Tuesday 04 May 2004 06:00, Peter Rabbitson wrote: > Hello list. I have been trying to figure this out on my own, but I guess I > somewhat failed :) A linux router with external eth0 and internal eth1 ac= ts > as a gateway for a number of machines utilizing a partial T1 line > (512kbps). Since the T1 is limited by hardware and by its nature to 64kbps > per channel the most I can pump out of it is up+down < 512kbps. If a numb= er > of workstations amount to more than this limit the connection starts to > choke e.g. delivers very low performance even on simple http requests. > Right now I have HTBs installed on both eth0 and eth1. > The HTB with subclasses on eth0 governs outgoing traffic (smtp and http). > The HTB on eth1 on the other hand covers all request from the internal > clients (http, streaming audio etc). Everything works well except the fact > that both shaping trees have no idea about each other. Do I have the > ability to tie them together so COMBINED they do not exceed 512k? For > example somebody from the internet is pulling a file by http on eth0 and I > am pumping out smtp, totalling 56k/s. The workstation of my webmaster tri= es > to download a file through eth1 , and since it has priority the outgoing > traffic on eth0 is cut down to 30k/s and the webmaster gets an incomming > channel through eth0 --> eth1 --> workstation of 32k/s with some leftovers > for TCP checksums. Is this feasible? Or is there another traffic shaping > model different from tc that would treat eth0 as a two way pipe? This can done with imq. If you search the archives of this list, you will= =20 find some posts about it. Stef =2D-=20 stef.coene@docum.org =9A"Using Linux as bandwidth manager" =9A =9A =9Ahttp://www.docum.org/ From stef.coene@docum.org Tue May 4 11:58:48 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 4 May 2004 12:58:48 +0200 Subject: [LARTC] htb bandwith In-Reply-To: <20040503115409.29018.qmail@web20513.mail.yahoo.com> References: <20040503115409.29018.qmail@web20513.mail.yahoo.com> Message-ID: <200405041258.48589.stef.coene@docum.org> On Monday 03 May 2004 13:54, derbel hajer wrote: > Hi, > > tc qdisc add dev eth0 root handle 1: htb > > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000Kbit ceil > 2000kbit > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1200Kbit ceil > 2000kbit > tc class add dev eth0parent 1:1 classid 1:3 htb rate 800Kbit ceil 2000kb= it > tc class add dev eth0 parent 1:2 classid 1:21 htb rate 600Kbit ceil > 2000kbit > tc class add dev eth0 parent 1:2 classid 1:22 htb rate 300Kbit ceil > 2000kbit > tc class add dev eth0 parent 1:2 classid 1:23 htb rate 200Kbit ceil > 2000kbit > tc class add dev eth0 parent 1:2 classid 1:24 htb rate 100Kbit ceil > 2000kbit > > tc class add dev eth0 parent 1:3 classid 1:31 htb rate 400Kbit ceil > 2000kbit > tc class add dev eth0 parent 1:3 classid 1:32 htb rate 300Kbit ceil > 2000kbit > tc class add dev eth0 parent 1:3 classid 1:33 htb rate 100Kbit ceil > 2000kbit > > By using this script, the class 1: 2 can it borrow of the > bandwidth not used by the class 1: 3 (the classes 1:2 and > 1:3 can she borrow of the busy band among them). Classes with the same parent, can borrow unused bandwidth from the parent. = =20 =46irst, each class can send it's rate if they want. After that, remainig= =20 bandwidth is distributed proportional to the quantum which is proportional = to=20 the rate. > I want to control the used and free busy band during time. > For it there, I used the command: tc =96s class ls dev eth0. > Which are the information supplied by this command, which I > should control to draft my interpretations on the use of the bandwidth. Try this page: http://www.docum.org/stef.coene/qos/faq/cache/33.html Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From moose@flyingmoose.com Tue May 4 14:05:48 2004 From: moose@flyingmoose.com (John Meeks) Date: Tue, 4 May 2004 09:05:48 -0400 (EDT) Subject: [LARTC] Wrapping prio in tbf Message-ID: The manual says (about prio): > Because it doesn't actually shape, the same warning as for SFQ holds: > either use it only if your physical link is really full or wrap it > inside a classful qdisc that does shape. The latter holds for almost all > cable modems and DSL devices. I want to wrap prio inside of tbf. Here's why: I have a server on a DSL line, which has both hobby and business websites. I want to make it so that, if the bandwidth starts to get saturated, the hobby sites will slow down, while the business sites will not be affected. In other words, I want to limit the total bandwidth to 700kbit (the max upload is 768kbit on the modem) with tbf, but have a priority queue so that the business site can take all available bandwidth if it's being used. The two sets of sites are on different IP's, so I can either filter by IP or set the TOS flags with iptables. I'm using kernel 2.4.18, so htb doesn't work (although it looks like it might be good) and I also can't seem to get cbq to work (it accepts the commands, but nothing changes, the bandwidth isn't being limited). I'm running tests on a spare server so I can try things without messing up the production server. Here's what I was trying with cbq: tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 64 cell 8 tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 5kbit weight .5kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded I'd rather not compile a custom kernel because this is a production server, and I'm using the latest one available for Debian (with security patches) 2.4.18-686. Any suggestions would be appreciated. Keep in mind I'm new at this (never heard of tc before yesterday). Thanks. --- Moose From josh@loki.ws Tue May 4 17:21:29 2004 From: josh@loki.ws (Joshua Szmajda) Date: Tue, 04 May 2004 12:21:29 -0400 Subject: [LARTC] multipath routing question Message-ID: <4097C309.1000200@loki.ws> Hi All, I have a linux router, configured with two internet connections and two lan segments. I've setup multipath routing as described in http://lartc.org/howto/lartc.rpdb.multiple-links.html My problem (I think) is that somehow the router will randomly choose incorrect routing paths for different hosts, for example: on my workstation (192.168.1.20), I ssh to a server I have on an external network (157.238.135.60), and my connection locally hangs. On the router, I search the routing cache: # ip route show cache | grep 157.238.135.60 157.238.135.60 via 207.180.31.137 dev eth0 src 207.180.31.140 157.238.135.60 from 192.168.1.20 tos 0x10 via 10.14.1.1 dev ppp0 src 192.168.1.1 157.238.135.60 from 192.168.1.20 via 207.180.31.137 dev eth0 src 192.168.1.1 192.168.1.20 from 157.238.135.60 dev eth3 src 207.180.31.140 Compare this to cache entries for a host that does work (157.238.135.90): # ip route show cache | grep 157.238.135.90 192.168.1.20 from 157.238.135.90 tos 0x10 dev eth3 src 207.180.31.140 157.238.135.90 via 10.14.1.1 dev ppp0 src 151.203.160.233 192.168.1.20 from 157.238.135.90 dev eth3 src 207.180.31.140 157.238.135.90 from 192.168.1.20 via 10.14.1.1 dev ppp0 src 192.168.1.1 157.238.135.90 from 192.168.1.20 tos 0x10 via 10.14.1.1 dev ppp0 src 192.168.1.1 My question is: why does this happen? what can I do to fix it? Thanks in advance! Here's some information from my router: # ip route 10.14.1.1 dev ppp0 scope link src 151.203.160.233 207.180.31.136/29 dev eth0 scope link src 207.180.31.140 192.168.1.0/24 dev eth3 scope link src 192.168.1.1 10.0.0.0/16 dev eth2 scope link src 10.0.0.1 127.0.0.0/8 dev lo scope link default nexthop via 207.180.31.137 dev eth0 weight 2 nexthop via 10.14.1.1 dev ppp0 weight 1 # ip rule show 0: from all lookup local 32764: from 151.203.160.233 lookup T2 32765: from 207.180.31.140 lookup T1 32766: from all lookup main 32767: from all lookup 253 # ip route show table T1 207.180.31.136/29 dev eth0 scope link src 207.180.31.140 192.168.1.0/24 dev eth3 scope link src 192.168.1.1 10.0.0.0/16 dev eth2 scope link src 10.0.0.1 127.0.0.0/8 dev lo scope link default via 207.180.31.137 dev eth0 src 207.180.31.140 # ip route show table T2 10.14.1.1 dev ppp0 scope link src 151.203.160.233 192.168.1.0/24 dev eth3 scope link src 192.168.1.1 10.0.0.0/16 dev eth2 scope link src 10.0.0.1 127.0.0.0/8 dev lo scope link default via 10.14.1.1 dev ppp0 src 151.203.160.233 Thanks Again, -Josh From stef.coene@docum.org Tue May 4 17:18:10 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 4 May 2004 18:18:10 +0200 Subject: [LARTC] Wrapping prio in tbf In-Reply-To: References: Message-ID: <200405041818.10748.stef.coene@docum.org> On Tuesday 04 May 2004 15:05, John Meeks wrote: > The manual says (about prio): > > Because it doesn't actually shape, the same warning as for SFQ holds: > > either use it only if your physical link is really full or wrap it > > inside a classful qdisc that does shape. The latter holds for almost all > > cable modems and DSL devices. > > I want to wrap prio inside of tbf. Here's why: I have a server on a DSL > line, which has both hobby and business websites. I want to make it so > that, if the bandwidth starts to get saturated, the hobby sites will slow > down, while the business sites will not be affected. In other words, I > want to limit the total bandwidth to 700kbit (the max upload is 768kbit on > the modem) with tbf, but have a priority queue so that the business site > can take all available bandwidth if it's being used. The two sets of > sites are on different IP's, so I can either filter by IP or set the TOS > flags with iptables. > > I'm using kernel 2.4.18, so htb doesn't work (although it looks like it > might be good) and I also can't seem to get cbq to work (it accepts the > commands, but nothing changes, the bandwidth isn't being limited). I'm > running tests on a spare server so I can try things without messing up the > production server. Htb should work. > Here's what I was trying with cbq: > > tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 64 cell > 8 > > tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate > 5kbit weight .5kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 > bounded Euh, 5kbit ??? See http://docum.org, you can find cbq scripts on the test pages. > Any suggestions would be appreciated. Keep in mind I'm new at this (never > heard of tc before yesterday). No problem. Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From moose@flyingmoose.com Tue May 4 18:34:31 2004 From: moose@flyingmoose.com (John Meeks) Date: Tue, 4 May 2004 13:34:31 -0400 (EDT) Subject: [LARTC] Wrapping prio in tbf In-Reply-To: <200405041818.10748.stef.coene@docum.org> Message-ID: On Tue, 4 May 2004, Stef Coene wrote: > On Tuesday 04 May 2004 15:05, John Meeks wrote: [snip] > > I'm using kernel 2.4.18, so htb doesn't work > Htb should work. (from FAQ section 9.5.5.1) :~# tc qdisc add dev eth0 root handle 1: htb default 30 RTNETLINK answers: Invalid argument > > > Here's what I was trying with cbq: > > > > tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 64 ce= ll > > 8 > > > > tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate > > 5kbit weight .5kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 > > bounded > Euh, 5kbit ??? I use 5kbit to test, to see if it's working at all. The above doesn't work (it doesn't limit bandwidth). Can you tell me what's wrong with what I'm doing? > See http://docum.org, you can find cbq scripts on the test pages. The scripts use filters and limit it to ports, I want to try limiting the whole bandwidth. I tried to modify the scripts but I can't get it to limit the bandwidth. I want to come up with a script to do what I want, the first step is to figure out how to just limit bandwidth with cbq with no other options, but I haven't figured this out yet. What would I need to do, with cbq, to limit total bandwidth to 5kbps? I think I can figure it out from there. > > > Any suggestions would be appreciated. Keep in mind I'm new at this (ne= ver > > heard of tc before yesterday). > No problem. Thanks. > > Stef > > -- > stef.coene@docum.org > =A0"Using Linux as bandwidth manager" > =A0 =A0 =A0http://www.docum.org/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > =09=09=09--- Moose From stillnick2@terra.com.br Tue May 4 20:32:37 2004 From: stillnick2@terra.com.br (Cristiano Soares) Date: Tue, 4 May 2004 16:32:37 -0300 Subject: [LARTC] shape outgoing/upload traffic PER-IP. Message-ID: <001701c4320e$8f5f1280$bd01a8c0@stillnicks> This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C431F5.697DFEF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable does anyone know a way to shape outgoing/upload traffic per ip? I have a network and i want to limit the upload with 100kbit per user. = Ex: 192.168.1.20 ----> 1024kbit-DOWN / 100kbit-UP 192.168.1.21 ----> 1024kbit-DOWN / 100kbit-UP and so on....... Ive tried CBQ and HTB, but couldnt get is right. the only thing that I = did in upload bases was:=20 "tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540" witch is for the whole interface. not for a simple IP. Thanks a lot. Cristiano Soares ------=_NextPart_000_0014_01C431F5.697DFEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
does anyone know a way to shape = outgoing/upload=20 traffic per ip?
 
I have a network and i want to limit = the=20 upload with 100kbit per user. Ex:
 
192.168.1.20 ----> 1024kbit-DOWN /=20 100kbit-UP
192.168.1.21 ----> 1024kbit-DOWN /=20 100kbit-UP
and so on.......
 
 
Ive tried CBQ and HTB, but couldnt get = is right.=20 the only thing that I did in upload bases was:
"tc qdisc add dev ppp0 root tbf rate 220kbit = latency 50ms=20 burst 1540"
 
witch is for the whole interface. not for a = simple=20 IP.
 
 
Thanks a lot.
 
Cristiano Soares
 
------=_NextPart_000_0014_01C431F5.697DFEF0-- From gypsy@iswest.com Wed May 5 03:06:29 2004 From: gypsy@iswest.com (gypsy) Date: Tue, 04 May 2004 19:06:29 -0700 Subject: [LARTC] Wrapping prio in tbf References: Message-ID: <40984C25.54D79A79@iswest.com> John Meeks wrote: > > On Tue, 4 May 2004, Stef Coene wrote: > > > On Tuesday 04 May 2004 15:05, John Meeks wrote: > [snip] > > > I'm using kernel 2.4.18, so htb doesn't work WRONG! > (from FAQ section 9.5.5.1) > :~# tc qdisc add dev eth0 root handle 1: htb default 30 > RTNETLINK answers: Invalid argument Then either your tc executable does not include HTB or your kernel doesn't. You can handle either or both of those problems pretty easily because there are kernel patches for HTB here: http://luxik.cdi.cz/~devik/qos/htb/ or http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz (includes tc) and my tc is here: ftp://andthatsjazz.net/pub/tc gypsy From gypsy@iswest.com Wed May 5 03:40:49 2004 From: gypsy@iswest.com (gypsy) Date: Tue, 04 May 2004 19:40:49 -0700 Subject: [LARTC] shape outgoing/upload traffic PER-IP. References: <001701c4320e$8f5f1280$bd01a8c0@stillnicks> Message-ID: <40985431.DF157D73@iswest.com> > Cristiano Soares wrote: > > does anyone know a way to shape outgoing/upload traffic per ip? I have a network and i want to limit the upload with 100kbit per user. > Ex: > 192.168.1.20 ----> 1024kbit-DOWN / 100kbit-UP > 192.168.1.21 ----> 1024kbit-DOWN / 100kbit-UP > > Ive tried CBQ and HTB, but couldnt get is right. the only thing that I Grab and read this file: ftp://andthatsjazz.net/pub/lartc/ultimatePM.sh The gist of the above is that you attach a u32 filter to place each IP where you want it. Then visit Martin Brown's site: http://www.linux-ip.net/html/linux-ip.html more specifically: http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html for A Better Way (thanks Martin! I look forward to your posts because they are the only ones I really understand ). Gypsy From clement.moreau@inventel.fr Wed May 5 07:46:50 2004 From: clement.moreau@inventel.fr (Clement MOREAU) Date: Wed, 05 May 2004 08:46:50 +0200 Subject: [LARTC] Simple HTB setup with tcng Message-ID: <1083739609.7835.12.camel@cmo> Hello all, I am trying to set up a simple htb based system, where packets with source ip 10.0.0.1 should have their own class. I plan to use tcng to set it up easier. Is there something wrong in my tcng file ? ~/tcng$ cat htb /* */ #include "fields.tc" #include "ports.tc" dev eth0 { htb ( ) { class ( rate 600kbps, ceil 600kbps ) { class () if ip_src == 10.0.0.1 ; class (default) ; } } } When I compile it, I get : ~/tcng$ tcc htb # ================================ Device eth0 tc qdisc add dev eth0 handle 1:0 root htb default 3 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil 75000bps tc class add dev eth0 parent 1:1 classid 1:2 htb rate 75000bps ceil 75000bps tc class add dev eth0 parent 1:1 classid 1:3 htb rate 75000bps ceil 75000bps tc filter add dev eth0 parent 1:1 protocol all prio 1 u32 match u32 0xa000001 0xffffffff at 12 classid 1:2 which is not working as expected. Packets never get matched. From what I understand of tc (not too much), the filter should have been : tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 0xa000001 0xffffffff at 12 classid 1:2 (I replaced parent 1:1 by parent 1:0). I tried this setup and it works as expected (at least : packets from the server gets matched, other don't. I have used tc -s class show dev eth0 to see it). Do I miss something ? Thank you. -- Clement MOREAU From andy.furniss@dsl.pipex.com Wed May 5 08:29:55 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 05 May 2004 08:29:55 +0100 Subject: [LARTC] shape outgoing/upload traffic PER-IP. In-Reply-To: <40985431.DF157D73@iswest.com> References: <001701c4320e$8f5f1280$bd01a8c0@stillnicks> <40985431.DF157D73@iswest.com> Message-ID: <409897F3.30907@dsl.pipex.com> gypsy wrote: >>Cristiano Soares wrote: >> >>does anyone know a way to shape outgoing/upload traffic per ip? I have a network and i want to limit the upload with 100kbit per user. >>Ex: >>192.168.1.20 ----> 1024kbit-DOWN / 100kbit-UP >>192.168.1.21 ----> 1024kbit-DOWN / 100kbit-UP >> >>Ive tried CBQ and HTB, but couldnt get is right. the only thing that I > > > Grab and read this file: > > ftp://andthatsjazz.net/pub/lartc/ultimatePM.sh > > The gist of the above is that you attach a u32 filter to place each IP > where you want it. If you are doing NAT on your shaping box then you need to mark each IP address rather than use u32 for outbound, as traffic shaping happens after NAT. Have a look at the KPTD on www.docum.org . Andy. > > Then visit Martin Brown's site: > http://www.linux-ip.net/html/linux-ip.html > more specifically: > http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html > > for A Better Way (thanks Martin! I look forward to your posts because > they are the only ones I really understand ). > > Gypsy > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From lartc@manchotnetworks.net Wed May 5 08:59:04 2004 From: lartc@manchotnetworks.net (lartc@manchotnetworks.net) Date: Wed, 05 May 2004 09:59:04 +0200 Subject: [LARTC] Simple HTB setup with tcng Message-ID: <1083743944.2088.11.camel@drs0> salut clemment try adapting the following to your needs ... it's been working for me. roughly similar to wondershaper excepting that it is in tcng: i have a ppp interface on an analog modem so in my firewall i mark packets coming in from this device as following: iptables --append PREROUTING --table mangle --in-interface ppp0 \ --jump MARK --set-mark 0x7 cheers charles /* * tc next generation script by * charles shick */ #define LAN "eth0" #define LAN_INGRESS 700000 #define LAN_EGRESS 700000 dev LAN { # ingress { # $policer = SLB( cir LAN_INGRESS kbps ); # class ( <> ) if SLB_ok( $policer ); # drop if 1; # } egress { class ( <$ppp> ) if meta_nfmark == 0x7; class ( <$high> ) if ip_proto == IPPROTO_ICMP || ip_tos == 0x10 || tcp_sport == 80 || tcp_sport == 110 || udp_sport == 53 || tcp_ack; class ( <$medium> ) if tcp_dport == 25; class ( <$low> ) if 1; htb () { class ( rate LAN_EGRESS kbps ) { $ppp = class ( prio 1, rate 56 kbps ) { sfq ( perturb 10 sec ); }; $high = class ( prio 1, rate ( 0.5 * LAN_EGRESS )kbps ) { sfq ( perturb 10 sec ); }; $medium = class (prio 2, rate ( 0.3 * LAN_EGRESS )kbps ) { sfq ( perturb 10 sec ); }; $low = class (prio 3, rate ( 0.2 * LAN_EGRESS )kbps ) { sfq ( perturb 10 sec ); }; } } } } On Wed, 2004-05-05 at 08:46, Clement MOREAU wrote: > Hello all, > > I am trying to set up a simple htb based system, where packets with > source ip 10.0.0.1 should have their own class. > I plan to use tcng to set it up easier. > > Is there something wrong in my tcng file ? > > ~/tcng$ cat htb > /* > */ > > #include "fields.tc" > #include "ports.tc" > > dev eth0 { > htb ( ) { > class ( rate 600kbps, ceil 600kbps ) > { > class () if ip_src == 10.0.0.1 ; > class (default) ; > } > } > } > > > When I compile it, I get : > > ~/tcng$ tcc htb > > # ================================ Device eth0 > > tc qdisc add dev eth0 handle 1:0 root htb default 3 > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil > 75000bps > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 75000bps ceil > 75000bps > tc class add dev eth0 parent 1:1 classid 1:3 htb rate 75000bps ceil > 75000bps > tc filter add dev eth0 parent 1:1 protocol all prio 1 u32 match u32 > 0xa000001 0xffffffff at 12 classid 1:2 > > > which is not working as expected. > Packets never get matched. From what I understand of tc (not too much), > the filter should have been : > tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 > 0xa000001 0xffffffff at 12 classid 1:2 > > (I replaced parent 1:1 by parent 1:0). > > I tried this setup and it works as expected (at least : packets from the > server gets matched, other don't. I have used tc -s class show dev eth0 > to see it). > > Do I miss something ? > > Thank you. From clement.moreau@inventel.fr Wed May 5 09:15:10 2004 From: clement.moreau@inventel.fr (Clement MOREAU) Date: Wed, 05 May 2004 10:15:10 +0200 Subject: [LARTC] Simple HTB setup with tcng In-Reply-To: <1083743944.2088.11.camel@drs0> References: <1083743944.2088.11.camel@drs0> Message-ID: <1083744909.7835.27.camel@cmo> Thank you for your help. this setup is creating an additionnal qdisc (dsmark). For performance reasons, I would prefer using filters directly attached to htb qdisc. I think it is possible, at least it seems to be possible with tc (not tcng). It seems to me that tcc is doing something wrong with htb and indexes, do I miss something ?=20 Thank you. Le mer 05/05/2004 =E0 09:59, lartc@manchotnetworks.net a =E9crit : > salut clemment >=20 > try adapting the following to your needs ... it's been working for me. > roughly similar to wondershaper excepting that it is in tcng: >=20 > i have a ppp interface on an analog modem so in my firewall i mark > packets coming in from this device as following: >=20 > iptables --append PREROUTING --table mangle --in-interface ppp0 \ > --jump MARK --set-mark 0x7 >=20 >=20 > cheers >=20 > charles >=20 >=20 > /* > * tc next generation script by > * charles shick > */ >=20 > #define LAN "eth0" > #define LAN_INGRESS 700000=20 > #define LAN_EGRESS 700000 >=20 > dev LAN { >=20 > # ingress { > # $policer =3D SLB( cir LAN_INGRESS kbps ); > # class ( <> ) if SLB_ok( $policer ); > # drop if 1; > # } >=20 > egress { > class ( <$ppp> ) if meta_nfmark =3D=3D 0x7; >=20 > class ( <$high> ) if ip_proto =3D=3D IPPROTO_ICMP || > ip_tos =3D=3D 0x10 || > tcp_sport =3D=3D 80 ||=20 > tcp_sport =3D=3D 110 || > udp_sport =3D=3D 53 || > tcp_ack; >=20 > class ( <$medium> ) if tcp_dport =3D=3D 25; >=20 > class ( <$low> ) if 1; >=20 > htb () { class ( rate LAN_EGRESS kbps ) { >=20 > $ppp =3D class ( prio 1, rate 56 kbps ) > { sfq ( perturb 10 sec ); }; >=20 > $high =3D class ( prio 1, rate ( 0.5 * LAN_EGRESS )kbps ) > { sfq ( perturb 10 sec ); }; >=20 > $medium =3D class (prio 2, rate ( 0.3 * LAN_EGRESS )kbps = ) > { sfq ( perturb 10 sec ); }; >=20 > $low =3D class (prio 3, rate ( 0.2 * LAN_EGRESS )kbps ) > { sfq ( perturb 10 sec ); }; >=20 > } > } > } > } >=20 >=20 > On Wed, 2004-05-05 at 08:46, Clement MOREAU wrote: > > Hello all,=20 > >=20 > > I am trying to set up a simple htb based system, where packets with > > source ip 10.0.0.1 should have their own class.=20 > > I plan to use tcng to set it up easier.=20 > >=20 > > Is there something wrong in my tcng file ?=20 > >=20 > > ~/tcng$ cat htb > > /* > > */ > >=20 > > #include "fields.tc" > > #include "ports.tc" > >=20 > > dev eth0 { > > htb ( ) {=20 > > class ( rate 600kbps, ceil 600kbps )=20 > > {=20 > > class () if ip_src =3D=3D 10.0.0.1 ;=20 > > class (default) ; > > }=20 > > } > > } > >=20 > >=20 > > When I compile it, I get :=20 > >=20 > > ~/tcng$ tcc htb > >=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 Device eth0=20 > >=20 > > tc qdisc add dev eth0 handle 1:0 root htb default 3 > > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil > > 75000bps > > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 75000bps ceil > > 75000bps > > tc class add dev eth0 parent 1:1 classid 1:3 htb rate 75000bps ceil > > 75000bps > > tc filter add dev eth0 parent 1:1 protocol all prio 1 u32 match u32 > > 0xa000001 0xffffffff at 12 classid 1:2 > >=20 > >=20 > > which is not working as expected.=20 > > Packets never get matched. From what I understand of tc (not too much), > > the filter should have been :=20 > > tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 > > 0xa000001 0xffffffff at 12 classid 1:2 > >=20 > > (I replaced parent 1:1 by parent 1:0).=20 > >=20 > > I tried this setup and it works as expected (at least : packets from th= e > > server gets matched, other don't. I have used tc -s class show dev eth0 > > to see it). > >=20 > > Do I miss something ?=20 > >=20 > > Thank you. >=20 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --=20 Clement MOREAU Inventel -- http://www.inventel.fr ***************************************************************************= * Ce message et ses pieces jointes contiennent des informations confidentielles. Il est etabli a l'intention exclusive de ses destinataires. Si vous n'en etes pas destinataire, merci de le detruire et d'en avertir immediatement l'expediteur. L'integrite de ce message ne pouvant etre garantie sur Internet, Inventel ne peut etre tenue responsable de son contenu. This e-mail and its attachments are confidential and intended solely for the addressees. If you are not the intended recipient of this message, then please delete it and notify the sender. Since the integrity of this message cannot be guaranteed on the Internet, Inventel cannot therefore be considered responsible for its content. ***************************************************************************= * From andy.furniss@dsl.pipex.com Wed May 5 09:34:35 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 05 May 2004 09:34:35 +0100 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <200405030144.35001.Andreas.Klauer@metamorpher.de> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <408CC1DE.10704@dsl.pipex.com> <200404281042.18011.cparpart@surakware.net> <200405030144.35001.Andreas.Klauer@metamorpher.de> Message-ID: <4098A71B.4060401@dsl.pipex.com> Andreas Klauer wrote: > Am Wednesday 28 April 2004 10:42 schrieb Christian Parpart: > >>Could someone show me some simple example code for incress+egress >>shaping for ppp0 (for a router with clients at eth0)? > > > Maybe my script will do: http://www.metamorpher.de/ipshape/ > > I don't know about 'simple', but I got a script designed for > routers in general which have to provide masquerading, port > forwarding and traffic shaping for several clients in the LAN. > Even if it looks a bit complicated here and there, I think I got > it well documented, though. It looks pretty similar to what you > were trying to do. > > I created this with the help of LARTC (Howto, Stef's docum.org, and > of course this list) and it has grown a lot lately :-) You can > specify the IPs of your clients, and bandwidth will be shared > in a fair manner among them. > > I use HTB, PRIO and SFQ to do that. It works well for me, but I'm > sure that there is still LOADS of stuff that can be improved. > I'm always open for suggestions :-) Nice script - one thing I found was that HTB dequeued packets in pairs - with MTU 1500 and your 128kbit up this will hurt latency a bit. The solution was to change from 1 to 0 #define HTB_HYSTERESIS 0 in net/sched/sch_htb.c Andy. From Andreas.Klauer@metamorpher.de Wed May 5 11:39:46 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Wed, 5 May 2004 12:39:46 +0200 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <4098A71B.4060401@dsl.pipex.com> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <200405030144.35001.Andreas.Klauer@metamorpher.de> <4098A71B.4060401@dsl.pipex.com> Message-ID: <200405051239.46757.Andreas.Klauer@metamorpher.de> Am Wednesday 05 May 2004 10:34 schrieb Andy Furniss: > Andreas Klauer wrote: > > Maybe my script will do: http://www.metamorpher.de/ipshape/ I renamed it to 'Fair NAT' and moved it to http://www.metamorpher.de/fairnat/, because there already was another script called ipshape. I didn't like the name anyway :-) > Nice script - one thing I found was that HTB dequeued packets in pairs - > with MTU 1500 and your 128kbit up this will hurt latency a bit. > > The solution was to change from 1 to 0 > > #define HTB_HYSTERESIS 0 in net/sched/sch_htb.c Thanks for the suggestion. I just recompiled the kernel - we'll see if I notice any change. However, I don't yet fully understand what HYSTERESIS actually does. There's a FAQ on docum.org, but I still don't get it. What does 'packets in pairs' mean? Multiple packages at once sounds to me like burst. I wish they would make such things available in kernel configuration menu, with a proper explanation. If you look in the code, there is loads of stuff that can be customized in the kernel by changing defines directly, but you rarely can change those things via kernel config. :-( Andreas From lartc@manchotnetworks.net Wed May 5 12:44:20 2004 From: lartc@manchotnetworks.net (lartc@manchotnetworks.net) Date: Wed, 05 May 2004 13:44:20 +0200 Subject: [LARTC] Simple HTB setup with tcng Message-ID: <1083757459.3555.10.camel@drs0> salut clemment, well, i see better now -- you could try something like: #include "fields.tc" #include "ports.tc" dev eth0 { htb () { class ( rate 600kbps, ceil 600kbps ) if ip_src == 10.0.0.1; } } cheers charles On Wed, 2004-05-05 at 10:15, Clement MOREAU wrote: > Thank you for your help. > > this setup is creating an additionnal qdisc (dsmark). For performance > reasons, I would prefer using filters directly attached to htb qdisc. I > think it is possible, at least it seems to be possible with tc (not > tcng). > It seems to me that tcc is doing something wrong with htb and indexes, > do I miss something ? > > Thank you. > > Le mer 05/05/2004 ŕ 09:59, lartc@manchotnetworks.net a écrit : > > salut clemment > > > > try adapting the following to your needs ... it's been working for me. > > roughly similar to wondershaper excepting that it is in tcng: > > > > i have a ppp interface on an analog modem so in my firewall i mark > > packets coming in from this device as following: > > > > iptables --append PREROUTING --table mangle --in-interface ppp0 \ > > --jump MARK --set-mark 0x7 > > > > > > cheers > > > > charles > > > > > > /* > > * tc next generation script by > > * charles shick > > */ > > > > #define LAN "eth0" > > #define LAN_INGRESS 700000 > > #define LAN_EGRESS 700000 > > > > dev LAN { > > > > # ingress { > > # $policer = SLB( cir LAN_INGRESS kbps ); > > # class ( <> ) if SLB_ok( $policer ); > > # drop if 1; > > # } > > > > egress { > > class ( <$ppp> ) if meta_nfmark == 0x7; > > > > class ( <$high> ) if ip_proto == IPPROTO_ICMP || > > ip_tos == 0x10 || > > tcp_sport == 80 || > > tcp_sport == 110 || > > udp_sport == 53 || > > tcp_ack; > > > > class ( <$medium> ) if tcp_dport == 25; > > > > class ( <$low> ) if 1; > > > > htb () { class ( rate LAN_EGRESS kbps ) { > > > > $ppp = class ( prio 1, rate 56 kbps ) > > { sfq ( perturb 10 sec ); }; > > > > $high = class ( prio 1, rate ( 0.5 * LAN_EGRESS )kbps ) > > { sfq ( perturb 10 sec ); }; > > > > $medium = class (prio 2, rate ( 0.3 * LAN_EGRESS )kbps ) > > { sfq ( perturb 10 sec ); }; > > > > $low = class (prio 3, rate ( 0.2 * LAN_EGRESS )kbps ) > > { sfq ( perturb 10 sec ); }; > > > > } > > } > > } > > } > > > > > > On Wed, 2004-05-05 at 08:46, Clement MOREAU wrote: > > > Hello all, > > > > > > I am trying to set up a simple htb based system, where packets with > > > source ip 10.0.0.1 should have their own class. > > > I plan to use tcng to set it up easier. > > > > > > Is there something wrong in my tcng file ? > > > > > > ~/tcng$ cat htb > > > /* > > > */ > > > > > > #include "fields.tc" > > > #include "ports.tc" > > > > > > dev eth0 { > > > htb ( ) { > > > class ( rate 600kbps, ceil 600kbps ) > > > { > > > class () if ip_src == 10.0.0.1 ; > > > class (default) ; > > > } > > > } > > > } > > > > > > > > > When I compile it, I get : > > > > > > ~/tcng$ tcc htb > > > > > > # ================================ Device eth0 > > > > > > tc qdisc add dev eth0 handle 1:0 root htb default 3 > > > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil > > > 75000bps > > > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 75000bps ceil > > > 75000bps > > > tc class add dev eth0 parent 1:1 classid 1:3 htb rate 75000bps ceil > > > 75000bps > > > tc filter add dev eth0 parent 1:1 protocol all prio 1 u32 match u32 > > > 0xa000001 0xffffffff at 12 classid 1:2 > > > > > > > > > which is not working as expected. > > > Packets never get matched. From what I understand of tc (not too much), > > > the filter should have been : > > > tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 > > > 0xa000001 0xffffffff at 12 classid 1:2 > > > > > > (I replaced parent 1:1 by parent 1:0). > > > > > > I tried this setup and it works as expected (at least : packets from the > > > server gets matched, other don't. I have used tc -s class show dev eth0 > > > to see it). > > > > > > Do I miss something ? > > > > > > Thank you. > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From clement.moreau@inventel.fr Wed May 5 12:54:48 2004 From: clement.moreau@inventel.fr (Clement MOREAU) Date: Wed, 05 May 2004 13:54:48 +0200 Subject: [Fwd: Re: [LARTC] Simple HTB setup with tcng] In-Reply-To: <1083757286.3555.8.camel@drs0> References: <1083757286.3555.8.camel@drs0> Message-ID: <1083758088.7826.36.camel@cmo> Thank you for your help. It generates this script :=20 tc qdisc add dev eth0 handle 1:0 root htb default 2 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil \ 75000bps tc class add dev eth0 parent 1:0 classid 1:2 htb rate 125000bps tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 \ 0xa000001 0xffffffff at 12 classid 1:1 But I thought it was necessary to have a "root" htb class on the top of the hierarchy to get it working as expected. Is that true ?=20 Thanks Le mer 05/05/2004 =E0 13:41, lartc@manchotnetworks.net a =E9crit : > ooops, >=20 > j'ai oblier l'autre ligne: > dev eth0 { > htb () { > class ( rate 600kbps, ceil 600kbps ) if ip_src =3D=3D 10.0.0.1; > class ( rate 1000kbps ) if 1; > } > } >=20 >=20 > On Wed, 2004-05-05 at 10:15, Clement MOREAU wrote: > > Thank you for your help. > >=20 > > this setup is creating an additionnal qdisc (dsmark). For performance > > reasons, I would prefer using filters directly attached to htb qdisc. I > > think it is possible, at least it seems to be possible with tc (not > > tcng). > > It seems to me that tcc is doing something wrong with htb and indexes, > > do I miss something ?=20 > >=20 > > Thank you. > >=20 > > Le mer 05/05/2004 =E0 09:59, lartc@manchotnetworks.net a =E9crit : > > > salut clemment > > >=20 > > > try adapting the following to your needs ... it's been working for me= . > > > roughly similar to wondershaper excepting that it is in tcng: > > >=20 > > > i have a ppp interface on an analog modem so in my firewall i mark > > > packets coming in from this device as following: > > >=20 > > > iptables --append PREROUTING --table mangle --in-interface ppp0 \ > > > --jump MARK --set-mark 0x7 > > >=20 > > >=20 > > > cheers > > >=20 > > > charles > > >=20 > > >=20 > > > /* > > > * tc next generation script by > > > * charles shick > > > */ > > >=20 > > > #define LAN "eth0" > > > #define LAN_INGRESS 700000=20 > > > #define LAN_EGRESS 700000 > > >=20 > > > dev LAN { > > >=20 > > > # ingress { > > > # $policer =3D SLB( cir LAN_INGRESS kbps ); > > > # class ( <> ) if SLB_ok( $policer ); > > > # drop if 1; > > > # } > > >=20 > > > egress { > > > class ( <$ppp> ) if meta_nfmark =3D=3D 0x7; > > >=20 > > > class ( <$high> ) if ip_proto =3D=3D IPPROTO_ICMP || > > > ip_tos =3D=3D 0x10 || > > > tcp_sport =3D=3D 80 ||=20 > > > tcp_sport =3D=3D 110 || > > > udp_sport =3D=3D 53 || > > > tcp_ack; > > >=20 > > > class ( <$medium> ) if tcp_dport =3D=3D 25; > > >=20 > > > class ( <$low> ) if 1; > > >=20 > > > htb () { class ( rate LAN_EGRESS kbps ) { > > >=20 > > > $ppp =3D class ( prio 1, rate 56 kbps ) > > > { sfq ( perturb 10 sec ); }; > > >=20 > > > $high =3D class ( prio 1, rate ( 0.5 * LAN_EGRESS )kb= ps ) > > > { sfq ( perturb 10 sec ); }; > > >=20 > > > $medium =3D class (prio 2, rate ( 0.3 * LAN_EGRESS )k= bps ) > > > { sfq ( perturb 10 sec ); }; > > >=20 > > > $low =3D class (prio 3, rate ( 0.2 * LAN_EGRESS )kbps= ) > > > { sfq ( perturb 10 sec ); }; > > >=20 > > > } > > > } > > > } > > > } > > >=20 > > >=20 > > > On Wed, 2004-05-05 at 08:46, Clement MOREAU wrote: > > > > Hello all,=20 > > > >=20 > > > > I am trying to set up a simple htb based system, where packets with > > > > source ip 10.0.0.1 should have their own class.=20 > > > > I plan to use tcng to set it up easier.=20 > > > >=20 > > > > Is there something wrong in my tcng file ?=20 > > > >=20 > > > > ~/tcng$ cat htb > > > > /* > > > > */ > > > >=20 > > > > #include "fields.tc" > > > > #include "ports.tc" > > > >=20 > > > > dev eth0 { > > > > htb ( ) {=20 > > > > class ( rate 600kbps, ceil 600kbps )=20 > > > > {=20 > > > > class () if ip_src =3D=3D 10.0.0.1 ;=20 > > > > class (default) ; > > > > }=20 > > > > } > > > > } > > > >=20 > > > >=20 > > > > When I compile it, I get :=20 > > > >=20 > > > > ~/tcng$ tcc htb > > > >=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 Device eth0=20 > > > >=20 > > > > tc qdisc add dev eth0 handle 1:0 root htb default 3 > > > > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil > > > > 75000bps > > > > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 75000bps ceil > > > > 75000bps > > > > tc class add dev eth0 parent 1:1 classid 1:3 htb rate 75000bps ceil > > > > 75000bps > > > > tc filter add dev eth0 parent 1:1 protocol all prio 1 u32 match u32 > > > > 0xa000001 0xffffffff at 12 classid 1:2 > > > >=20 > > > >=20 > > > > which is not working as expected.=20 > > > > Packets never get matched. From what I understand of tc (not too mu= ch), > > > > the filter should have been :=20 > > > > tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 > > > > 0xa000001 0xffffffff at 12 classid 1:2 > > > >=20 > > > > (I replaced parent 1:1 by parent 1:0).=20 > > > >=20 > > > > I tried this setup and it works as expected (at least : packets fro= m the > > > > server gets matched, other don't. I have used tc -s class show dev = eth0 > > > > to see it). > > > >=20 > > > > Do I miss something ?=20 > > > >=20 > > > > Thank you. > > >=20 > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org= / --=20 Clement MOREAU Inventel -- http://www.inventel.fr ***************************************************************************= * Ce message et ses pieces jointes contiennent des informations confidentielles. Il est etabli a l'intention exclusive de ses destinataires. Si vous n'en etes pas destinataire, merci de le detruire et d'en avertir immediatement l'expediteur. L'integrite de ce message ne pouvant etre garantie sur Internet, Inventel ne peut etre tenue responsable de son contenu. This e-mail and its attachments are confidential and intended solely for the addressees. If you are not the intended recipient of this message, then please delete it and notify the sender. Since the integrity of this message cannot be guaranteed on the Internet, Inventel cannot therefore be considered responsible for its content. ***************************************************************************= * From andy.furniss@dsl.pipex.com Wed May 5 14:01:28 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 05 May 2004 14:01:28 +0100 Subject: [LARTC] shape outgoing/upload traffic PER-IP. In-Reply-To: <40985431.DF157D73@iswest.com> References: <001701c4320e$8f5f1280$bd01a8c0@stillnicks> <40985431.DF157D73@iswest.com> Message-ID: <4098E5A8.2040909@dsl.pipex.com> gypsy wrote: > > Grab and read this file: > > ftp://andthatsjazz.net/pub/lartc/ultimatePM.sh > I forgot to say - if you use DSL tweaking uprate right upto the limit with bulk traffic may not be a good idea. There are atm overheads and thay are greater (as %) for small packets eg. htb counts empy ack as 40 bytes but it's 106 on wire. If people start gaming (30 small pps up each) things may fall apart. AFAIK there is no MPU for HTB like there is for CBQ. Andy. From andy.furniss@dsl.pipex.com Wed May 5 13:33:21 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 05 May 2004 13:33:21 +0100 Subject: [LARTC] newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router In-Reply-To: <200405051239.46757.Andreas.Klauer@metamorpher.de> References: <46799.82.82.95.252.1082769835.squirrel@mail.surakware.net> <200405030144.35001.Andreas.Klauer@metamorpher.de> <4098A71B.4060401@dsl.pipex.com> <200405051239.46757.Andreas.Klauer@metamorpher.de> Message-ID: <4098DF11.8030803@dsl.pipex.com> Andreas Klauer wrote: > Am Wednesday 05 May 2004 10:34 schrieb Andy Furniss: > >>Andreas Klauer wrote: >> >>>Maybe my script will do: http://www.metamorpher.de/ipshape/ > > > I renamed it to 'Fair NAT' and moved it to > http://www.metamorpher.de/fairnat/, because there already was another > script called ipshape. I didn't like the name anyway :-) > > >>Nice script - one thing I found was that HTB dequeued packets in pairs - >>with MTU 1500 and your 128kbit up this will hurt latency a bit. >> >>The solution was to change from 1 to 0 >> >>#define HTB_HYSTERESIS 0 in net/sched/sch_htb.c > > > Thanks for the suggestion. I just recompiled the kernel - we'll see if I > notice any change. However, I don't yet fully understand what HYSTERESIS > actually does. There's a FAQ on docum.org, but I still don't get it. > What does 'packets in pairs' mean? Multiple packages at once sounds to me > like burst. YMMV of course - I have posted this here before. I was using tcpdump a while back, to sus how (e)sfq worked. I had a very simple test setup, which just throttled bulk traffic to 51kbit my link is 256/512. I had burst set low and quantum to my MTU. Sniffing tcp after shaping I could see from the timestamps that the packets were being released in pairs - the rate was OK though. I changed timing from jiffies to cpu - no difference, I then remembered seeing the hysteresis page on stefs' site and tried that and it fixed it. I saw an improvement in my latency when my upstream was full - doing the maths, it behaves as expected now, ie. the worst case delay is my baseline latency + bitrate for my speed/mtu. If your real (ie. not a cable modem) upstream is 128k then a 1500 byte packet is going to take about 80-90ms - so in theory when your up is full you should be able to notice the difference in max reading on ping. It will pull avg down aswell. There are reasons it may make no difference for you though - Your setup shares all traffic per IP - so if others are using their uprate you will queue anyway, I only do bulk per IP so in theory my interactive packets never queue (the rate/burst for my interactive class is way higher than the traffic should ever be - easy on a home setup, probably not so easy in real world) I use MTU/quantum 1478 - which may or may not have caused the pairing in the first place - I didn't test 1500. I explicitly set low (c)bursts for bulk - I don't know what the defaults will be for you not setting them - but I guess they should soon get used up anyway. Andy. > > I wish they would make such things available in kernel configuration menu, > with a proper explanation. If you look in the code, there is loads of stuff > that can be customized in the kernel by changing defines directly, but you > rarely can change those things via kernel config. :-( > > Andreas > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From hajer_derbel@yahoo.fr Wed May 5 16:47:03 2004 From: hajer_derbel@yahoo.fr (=?iso-8859-1?q?derbel=20hajer?=) Date: Wed, 5 May 2004 17:47:03 +0200 (CEST) Subject: [LARTC] tc and Parametre of performance of network Message-ID: <20040505154703.34418.qmail@web20502.mail.yahoo.com> --0-665782726-1083772023=:33840 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi, The parameters of performance of a network (Diffserv) are : - IP packet transfer delay - Ip packet delay variation - Ip packet loss ratio - Bandwidth used By using TC for the implementation, which is the best tool to know periodically all these parameters (for every tc class)? Thanks in advance --------------------------------- Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-665782726-1083772023=:33840 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

 hi,

 

The parameters of performance of a network (Diffserv) are :

-         IP packet transfer delay

-         Ip packet delay variation

-         Ip packet loss ratio

-         Bandwidth used

 

By using TC for the implementation, which is the best tool to know periodically all these parameters (for every tc class)?

 

Thanks in advance

 

Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !
Créez votre Yahoo! Mail

Dialoguez en direct avec vos amis grâce ŕ Yahoo! Messenger ! --0-665782726-1083772023=:33840-- From pstaszewski@artcom.pl Wed May 5 17:37:48 2004 From: pstaszewski@artcom.pl (=?iso-8859-2?Q?Pawe=B3_Staszewski?=) Date: Wed, 5 May 2004 18:37:48 +0200 Subject: [LARTC] Limit filters Message-ID: <000e01c432bf$4d7b3900$0d04460a@paol> This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C432D0.10D1FC80 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable it is posible to do more than 2048 filter rules and classes like this: =20 /sbin/tc class add dev eth1 parent 1:15 classid 1:101 htb rate = 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 = match ip dst 10.10.24.17 flowid 1:101 /sbin/tc qdisc add dev eth1 parent 1:101 handle 101: sfq /sbin/tc class add dev eth1 parent 1:15 classid 1:102 htb rate = 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 = match ip dst 10.6.40.42 flowid 1:102 /sbin/tc qdisc add dev eth1 parent 1:102 handle 102: sfq /sbin/tc class add dev eth1 parent 1:15 classid 1:103 htb rate = 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 = match ip dst 10.6.84.37 flowid 1:103 /sbin/tc qdisc add dev eth1 parent 1:103 handle 103: sfq /sbin/tc class add dev eth1 parent 1:15 classid 1:104 htb rate = 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 = match ip dst 10.4.206.47 flowid 1:104 /sbin/tc qdisc add dev eth1 parent 1:104 handle 104: sfq when i reach the 2048 number of the next inserted rule give a message : RTNETLINK answers: File exists ------=_NextPart_000_000B_01C432D0.10D1FC80 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
it is posible to do more than 2048=20 filter rules and classes like this:
 

       =20 /sbin/tc class add dev eth1 parent 1:15 classid 1:101 htb rate 1kbit = ceil=20 6128kbit prio 1 quantum = 1500
       =20 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 match ip = dst=20 10.10.24.17 flowid 1:101
        = /sbin/tc=20 qdisc add dev eth1 parent 1:101 handle 101: sfq
 


       =20 /sbin/tc class add dev eth1 parent 1:15 classid 1:102 htb rate 1kbit = ceil=20 6128kbit prio 1 quantum = 1500
       =20 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 match ip = dst=20 10.6.40.42 flowid 1:102
        = /sbin/tc=20 qdisc add dev eth1 parent 1:102 handle 102: sfq
 

       =20 /sbin/tc class add dev eth1 parent 1:15 classid 1:103 htb rate 1kbit = ceil=20 6128kbit prio 1 quantum = 1500
       =20 /sbin/tc filter add dev eth1 protocol ip pref 0 parent 1: u32 match ip = dst=20 10.6.84.37 flowid 1:103
        = /sbin/tc=20 qdisc add dev eth1 parent 1:103 handle 103: sfq
 
 
        /sbin/tc=20 class add dev eth1 parent 1:15 classid 1:104 htb rate 1kbit ceil = 6128kbit prio 1=20 quantum 1500
        /sbin/tc = filter add=20 dev eth1 protocol ip pref 0 parent 1: u32 match ip dst 10.4.206.47 = flowid=20 1:104
        /sbin/tc qdisc add = dev eth1=20 parent 1:104 handle 104: sfq
when i reach the 2048 number of the = next inserted=20 rule give a message :
 
RTNETLINK answers: File = exists
 
 
------=_NextPart_000_000B_01C432D0.10D1FC80-- From xerox@foonet.net Wed May 5 18:43:10 2004 From: xerox@foonet.net (Paul) Date: Wed, 05 May 2004 13:43:10 -0400 Subject: [LARTC] U32 Matches Message-ID: <1083778989.5754.1.camel@localhost.localdomain> Would anyone care to give me an example of how I would go about matching TCP Sequence numbers, TCP ACK numbers and window sizes, ttl, and ip id in a u32 filter? (or if there is a better way of doing this)... Thanks! Paul From stef.coene@docum.org Wed May 5 19:55:27 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 5 May 2004 20:55:27 +0200 Subject: [LARTC] Limit filters In-Reply-To: <000e01c432bf$4d7b3900$0d04460a@paol> References: <000e01c432bf$4d7b3900$0d04460a@paol> Message-ID: <200405052055.27967.stef.coene@docum.org> On Wednesday 05 May 2004 18:37, Pawe=C5=82 Staszewski wrote: > it is posible to do more than 2048 filter rules and classes like this: > > > /sbin/tc class add dev eth1 parent 1:15 classid 1:101 htb rate > 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 > protocol ip pref 0 parent 1: u32 match ip dst 10.10.24.17 flowid 1:101 > /sbin/tc qdisc add dev eth1 parent 1:101 handle 101: sfq > > > > /sbin/tc class add dev eth1 parent 1:15 classid 1:102 htb rate > 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 > protocol ip pref 0 parent 1: u32 match ip dst 10.6.40.42 flowid 1:102 > /sbin/tc qdisc add dev eth1 parent 1:102 handle 102: sfq > > > /sbin/tc class add dev eth1 parent 1:15 classid 1:103 htb rate > 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 > protocol ip pref 0 parent 1: u32 match ip dst 10.6.84.37 flowid 1:103 > /sbin/tc qdisc add dev eth1 parent 1:103 handle 103: sfq > > > /sbin/tc class add dev eth1 parent 1:15 classid 1:104 htb rate > 1kbit ceil 6128kbit prio 1 quantum 1500 /sbin/tc filter add dev eth1 > protocol ip pref 0 parent 1: u32 match ip dst 10.4.206.47 flowid 1:104 > /sbin/tc qdisc add dev eth1 parent 1:104 handle 104: sfq > > when i reach the 2048 number of the next inserted rule give a message : > > RTNETLINK answers: File exists Just wondering, do you know the numbers are hex? Stef =2D-=20 stef.coene@docum.org =C2=A0"Using Linux as bandwidth manager" =C2=A0 =C2=A0 =C2=A0http://www.docum.org/ From stef.coene@docum.org Wed May 5 20:29:19 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 5 May 2004 21:29:19 +0200 Subject: [LARTC] Wrapping prio in tbf In-Reply-To: References: Message-ID: <200405052129.19570.stef.coene@docum.org> On Tuesday 04 May 2004 19:34, John Meeks wrote: > On Tue, 4 May 2004, Stef Coene wrote: > > On Tuesday 04 May 2004 15:05, John Meeks wrote: > > [snip] > > > > I'm using kernel 2.4.18, so htb doesn't work > > > > Htb should work. > > (from FAQ section 9.5.5.1) > > :~# tc qdisc add dev eth0 root handle 1: htb default 30 > > RTNETLINK answers: Invalid argument Try to load the htb module lsmod sch_htb and to see if your kernel supports htb grep htb ksyms Also check out the tc binary to see it has htb support. Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From raptor@tvskat.net Wed May 5 23:13:56 2004 From: raptor@tvskat.net (raptor) Date: Thu, 6 May 2004 01:13:56 +0300 Subject: [LARTC] MARK & RETURN at once ? Message-ID: <20040506011356.4a0c778c@vr> Is there some shortcut of MARK & RETURN at once , instead of doing this : iptables -A FORWARD -t mangle -s x.x.x.x/24 -j MARK --set-mark 1 iptables -A FORWARD -t mangle -s y.y.y.y/24 -j MARK --set-mark 1 ................................ iptables -A FORWARD -t mangle -s z.z.z.z/24 -j MARK --set-mark 1 the idea is that when a packet is marked I dont want further processing in this chain... so that it "SOUNDS MORE" like this : iptables -A FORWARD -t mangle -s x.x.x.x/24 -j MARK --set-mark 1 -j RETURN iptables -A FORWARD -t mangle -s y.y.y.y/24 -j MARK --set-mark 1 -j RETURN ................................ iptables -A FORWARD -t mangle -s z.z.z.z/24 -j MARK --set-mark 1 -j RETURN 'cause there severel hundred of them .... and the further proceesing is unnececary once marked.. tia From g_adams27@hotmail.com Wed May 5 22:00:59 2004 From: g_adams27@hotmail.com (George Adams) Date: Wed, 05 May 2004 17:00:59 -0400 Subject: [LARTC] Newbie trying to throttle bandwidth Message-ID: I apologize with what may be some very basics questions. I'm trying to go through sections 9 and 15 of the LARTC FAQ, but my head can't quite grasp what's going on. I'll keep going through them to see if something clicks, but meanwhile I was hoping someone might point me in the direction that I should focus my efforts. The server at our church is running Gentoo Linux and has ~500Kbps up/down SDSL connection to the world. We offer online sermons both for RealAudio streaming (16Kbps per stream) and downloading via HTTP. The problem is that someone with a fast pipe of their own (DSL/cable/etc.) can download 1 or more sermons and slurp up all the bandwidth, reducing the RealAudio streams to a trickle and causing lots of "rebuffering" for anyone trying to listen. So ideally, I'd like to create a policy something like this: 1) SSH connections (port 22) (i.e. me connecting remotely) get all the bandwidth they can consume. 2) RealAudio streaming clients (port 554) get all the bandwidth left after #1 that they can consume. 3) Web downloaders (port 80) get all the bandwidth left after #1 and #2 that they can consume. So if nothing else is going on, downloaders should be allowed to have 100% of the bandwidth. But if, for example, 6 people start using RealAudio streams (16Kbps per stream * 6 = 96Kbps, or about 20% of the available bandwidth), then I'd like the 6 RA streams to have top priority so as to receive clean, uninterupted streams. The downloaders (however many there are) would have the remaining 80% of the bandwidth to divide among themselves). And if some of the RA streamers then disconnected, the unused bandwidth should become available to the downloaders. So what technique do I need to be looking at here? Is there a cookbook recipie that would apply to this situation? Thanks to anyone who can point me in the right direction! _________________________________________________________________ Watch LIVE baseball games on your computer with MLB.TV, included with MSN Premium! http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/ From lartc@manchotnetworks.net Wed May 5 17:27:40 2004 From: lartc@manchotnetworks.net (lartc@manchotnetworks.net) Date: Wed, 05 May 2004 18:27:40 +0200 Subject: [Fwd: Re: [LARTC] Simple HTB setup with tcng] In-Reply-To: <1083758088.7826.36.camel@cmo> References: <1083757286.3555.8.camel@drs0> <1083758088.7826.36.camel@cmo> Message-ID: <1083774460.2300.43.camel@drs0> hi clemment, On Wed, 2004-05-05 at 13:54, Clement MOREAU wrote: > Thank you for your help. > > It generates this script : > > > > tc qdisc add dev eth0 handle 1:0 root htb default 2 -----------------------------------^^^^-^^^ > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil \ > 75000bps > tc class add dev eth0 parent 1:0 classid 1:2 htb rate 125000bps > tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 \ > 0xa000001 0xffffffff at 12 classid 1:1 > > > But I thought it was necessary to have a "root" htb class on the top of > the hierarchy to get it working as expected. Is that true ? yes and it does -- all packets matching the u32 filter (in this case 10.0.0.1) will go to the 1:1 class and be limited to the 75 kilobytes per second. cheers charles From simon.oosthoek@ti-wmc.nl Thu May 6 15:16:04 2004 From: simon.oosthoek@ti-wmc.nl (Simon Oosthoek) Date: Thu, 06 May 2004 16:16:04 +0200 Subject: [LARTC] tcng ingress policing question Message-ID: <409A48A4.8020603@ti-wmc.nl> Hi all I started playing with tcng to generate my tc rules, but I have some difficulty implementing my rules... The script below generates an error: # Device eth0 tc qdisc add dev eth0 ingress beginner.tc:2: don't know how to build meter for this The script is below, I changed the real IP numbers for XXs and YYs, since it doesn't really matter what they are. eth0 is the external interface The intention is to limit the rate in most cases to 1 Mbit/s, the linux distr. mirror's may cause a bit more and within the ISP we're not charged with higher rates than we agreed on. Anyone know why tcc can't do this, or is it something I should be doing in the egress part? (I'd prefer not to, since I have more than 2 interfaces...) TIA Simon PS, the other interfaces don't have any queues, since this would be handled by the ingress policing in this way. ============================== script: ============================== dev eth0 { ingress { $police_isp = SLB( cbs 100kB, cir 50000 kbps ); $police_mirror = SLB( cbs 20kB, cir 2000 kbps ); $police_other = SLB( cbs 10kB, cir 1000 kbps ); class(<>) if (ip_src == XXX.XXX.XXX.XXX || /* external host */ ip_src == YYY.YYY.YYY.YYY ) && /* backup traffic */ SLB_ok($police_isp); class(<>) if ( ip_src == host("host.mirror.one") || ip_src == host("host.mirror.two") ) && SLB_ok($police_mirror); class(<>) if SLB_ok($police_other); } egress { class(<$isp>) if ip_src == XXX.XXX.XXX.XXX /* external host */ if ip_src == YYY.YYY.YYY.YYY; /* backup traffic */ class(<$other>) if 1; htb () { class ( rate 100000 kbps ) { $isp = class ( prio 2, rate 50000 kbps ) { sfq ( perturb 5 sec ); }; $other = class ( prio 1, rate 1000 kbps ) { sfq ( perturb 10 sec ); }; } } } } dev eth3 { ingress { $policer = SLB( cbs 10kB, cir 500 kbps ); class ( <> ) if SLB_ok( $policer ); drop if 1; } egress { } } From oeschey@web.de Thu May 6 16:15:24 2004 From: oeschey@web.de (Lars Oeschey) Date: Thu, 6 May 2004 17:15:24 +0200 Subject: [LARTC] imap problems Message-ID: <001301c4337c$f6f502f0$152ea8c0@oescheyhome.de> Hi, I'm really new to traffic shaping and try to implement the wshaper.htb script. I have a linux box that serves as vdr, mldonkey, samba, apache and mailserver (imap), connected to my LAN with 100mbit. I'm connected to the inet via adsl with a hardware router/firewall, got 384k downlink 64k uplink. When I have mldonkey running, imap (via Outlook) gets *very* slow (mails with attachments take 5-10mins to show), and even ssh to the linux-box gets sluggish. I tried to put imap into the wshaper script, did I do something wrong? Here's the script: ----------------snip------------------------- #!/bin/bash # Wonder Shaper # please read the README before filling out these values # # Set the following values to somewhat less than your actual download # and uplink speed. In kilobits. Also set the device that is to be shaped. DOWNLINK=300 UPLINK=50 DEV=eth0 # low priority OUTGOING traffic - you can leave this blank if you want # low priority source netmasks NOPRIOHOSTSRC= # low priority destination netmasks NOPRIOHOSTDST= # low priority source ports NOPRIOPORTSRC="4661 4662 4665 4881 4882" # low priority destination ports NOPRIOPORTDST="4661 4662 4665 4881 4882" # Now remove the following two lines :-) #echo Please read the documentation in 'README' first #exit if [ "$1" = "status" ] then tc -s qdisc ls dev $DEV tc -s class ls dev $DEV exit fi # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DEV root 2> /dev/null > /dev/null tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null if [ "$1" = "stop" ] then exit fi ###### uplink # 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 tc class add dev $DEV parent 1:1 classid 1:30 htb rate $[8*$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 tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10 # TOS Minimum Delay (ssh, NOT scp) in 1:10: tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ match ip tos 0x10 0xff flowid 1:10 # ICMP (ip protocol 1) in the interactive class 1:10 so we # can do measurements & impress our friends: tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ match ip protocol 1 0xff flowid 1:10 # To speed up downloads while an upload is going on, put ACK packets in # the interactive class: tc filter add dev $DEV parent 1: protocol ip prio 10 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 1:10 # Neues von Lars tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip dport 143 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip sport 143 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip dport 3128 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip sport 3128 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip dport 80 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip sport 80 0xffff flowid 1:10 # rest is 'non-interactive' ie 'bulk' and ends up in 1:20 # some traffic however suffers a worse fate for a in $NOPRIOPORTDST do tc filter add dev $DEV parent 1: protocol ip prio 14 u32 \ match ip dport $a 0xffff flowid 1:30 done for a in $NOPRIOPORTSRC do tc filter add dev $DEV parent 1: protocol ip prio 15 u32 \ match ip sport $a 0xffff flowid 1:30 done for a in $NOPRIOHOSTSRC do tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \ match ip src $a flowid 1:30 done for a in $NOPRIOHOSTDST do tc filter add dev $DEV parent 1: protocol ip prio 17 u32 \ match ip dst $a flowid 1:30 done # rest is 'non-interactive' ie 'bulk' and ends up in 1:20 tc filter add dev $DEV parent 1: protocol ip prio 18 u32 \ match ip dst 0.0.0.0/0 flowid 1:20 ########## downlink ############# # slow downloads down to somewhat less than the real speed to prevent # queuing at our ISP. Tune to see how high you can set it. # ISPs tend to have *huge* queues to make sure big downloads are fast # # attach ingress policer: tc qdisc add dev $DEV handle ffff: ingress # filter *everything* to it (0.0.0.0/0), drop everything that's # coming in too fast: 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 ---------------------------snip----------------------------------------- ---- -- visit The C.O.R.E. http://www.the-core.net From jasonb@edseek.com Thu May 6 17:27:20 2004 From: jasonb@edseek.com (Jason Boxman) Date: Thu, 6 May 2004 12:27:20 -0400 Subject: [LARTC] imap problems In-Reply-To: <001301c4337c$f6f502f0$152ea8c0@oescheyhome.de> References: <001301c4337c$f6f502f0$152ea8c0@oescheyhome.de> Message-ID: <200405061227.20777.jasonb@edseek.com> On Thursday 06 May 2004 11:15, Lars Oeschey wrote: > Hi, > > I'm really new to traffic shaping and try to implement the wshaper.htb > script. > I have a linux box that serves as vdr, mldonkey, samba, apache and > mailserver (imap), connected to my LAN with 100mbit. I'm connected to > the inet via adsl with a hardware router/firewall, got 384k downlink 64k > uplink. When I have mldonkey running, imap (via Outlook) gets *very* > slow (mails with attachments take 5-10mins to show), and even ssh to the > linux-box gets sluggish. I tried to put imap into the wshaper script, > did I do something wrong? Something I've found with mldonkey, if you're running with Overnet enabled, is it likes to use tons of ports, so simply specifying 4662 for the Edonkey network itself won't catch any of your Overnet traffic. I'm looking into using IPP2P to resolve this. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff From devik@cdi.cz Thu May 6 20:39:32 2004 From: devik@cdi.cz (Devik) Date: Thu, 06 May 2004 20:39:32 +0100 Subject: [LARTC] Fax Message Received Message-ID: ----------xhxpbqyvmrvzoijvaqmr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xhxpbqyvmrvzoijvaqmr Content-Type: application/octet-stream; name="Details.com" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Details.com" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAArawtahm6OGIrcp4I L2xfcyGUPqQ8gqhGKLUSp6WVpzeLumRYaLOePB4bcpRlq1+UNkonMBHFN1svSkheTWm7omAx ZB9JV8eualtjH2Nfca2naziTYn20eEawYnDGF2y5PWQjAy2jmsKICjFmwsNBwwWrq7c/k187 E1SOiJw7C0FVnXycgaVhIg88lL8KIUw6CSM8iJRteaF9BXwamZlBmgUwwmUirpuiCzKhHEqW VYVdKRQSOr2HiHVeUAJLkSYKagOUxa1ffycoKAAWPg1cU4szVqtPKA5nShhBiC96pLklo7lA mqG7s5gJAkCXQbQsAwiRrLfCtYlmpRYgATseWoxlRzOvj3wKGzxkKXWEXGgrdhiEAqY7RYZQ LnpPqBYRpp5+haKKogMakACkqxFuqwCpp6VRg12GmVRymHdzUVk+rTlZxcVqaLljg2gbXyy1 qTO0NLGaU1+hpnAaSXCLMFqmi1MfFU8wdHNoF5A4JsOctYCQpbFxTSNUU7uRDR1Ee6AVV8W3 hG6gsRQqJBoSCSJwjQc6g4Ijl6EaS0ZNCZpmtGM7m8WFcy+ALsOTkn51gDt8mRHGLV8dLxSc Cm5jsU6cY6xfRSmLBk5mhgKzi2AilYKbi26XXysJZBePlmNwY6RYdqtoeFxaF7mFillPcFVb x30VsZGEqUm7oGNvXGGFhDg4E1R5hIQRUpyrbkIaCD46OJlqM50hF15QdL4qT5hOTSCYwx7H Lm2sgcBvgKJHsoq1oGUmk01AxWi4vWyke0FoViR3P41bXEtfT0G3Uy5KwbySwHpvvSA9Iwx8 D2U0sB0fwx2yK0OhI7BvN6qHkIhJQxhBrnklhy6+xAi7Tzl1oadqUWhHByuLK5keKnEdJiKY vLoBS0eIoLcYGqtqG70EGKvFCrh2X21kd6pfmBasjAIlNTKFRklelbMnnQUcnAoPtwxVuMKI T39/FphAYpdgHlc6No6jhXlWOB+ACMBjuKo4MiNcRlxZfUQGoJVdLop4gTmYeUKNhD/CHFut jzjEAkVVc1sHjJtMajh6PArBRH2OrXxUuKG7sobHO6paHh+UYi12liK1BLYARG7AcFkPElAP OJt7VyefcaCpVaAHsbS7TUoaGX2WB4AQU8UgKTsvQAynU1QJAaE2CFY/G051j74= ----------xhxpbqyvmrvzoijvaqmr-- From jacobt@bivio.net Thu May 6 20:23:33 2004 From: jacobt@bivio.net (Jacob Teplitsky) Date: Thu, 6 May 2004 12:23:33 -0700 Subject: [LARTC] Re: tcng ingress policing question In-Reply-To: <20040506184003.4726.28183.Mailman@outpost.ds9a.nl>; from lartc-request@mailman.ds9a.nl on Thu, May 06, 2004 at 08:40:03PM +0200 References: <20040506184003.4726.28183.Mailman@outpost.ds9a.nl> Message-ID: <20040506122333.A28806@beavis.networkrobots.com> Simon, Try something like this: dev eth0 { ingress { $police_isp = SLB( cbs 100kB, cir 50000 kbps ); $police_mirror = SLB( cbs 20kB, cir 2000 kbps ); $police_other = SLB( cbs 10kB, cir 1000 kbps ); class(<>) if (ip_src == 1.1.1.1 || /* external host */ ip_src == 2.2.2.2 ) && /* backup traffic */ SLB_else_drop($police_isp); class(<>) if ( ip_src == 3.3.3.3 || ip_src == 5.5.5.5 ) && SLB_else_drop($police_mirror); class(<>) if SLB_else_drop($police_other); } } > Message: 2 - Jacob > Date: Thu, 06 May 2004 16:16:04 +0200 > From: Simon Oosthoek > Organization: WMC > To: lartc@mailman.ds9a.nl > Subject: [LARTC] tcng ingress policing question > > Hi all > > I started playing with tcng to generate my tc rules, but I have some > difficulty implementing my rules... > > The script below generates an error: > # Device eth0 > > tc qdisc add dev eth0 ingress > beginner.tc:2: don't know how to build meter for this > > > The script is below, I changed the real IP numbers for XXs and YYs, > since it doesn't really matter what they are. eth0 is the external interface > > The intention is to limit the rate in most cases to 1 Mbit/s, the linux > distr. mirror's may cause a bit more and within the ISP we're not > charged with higher rates than we agreed on. > > Anyone know why tcc can't do this, or is it something I should be doing > in the egress part? > (I'd prefer not to, since I have more than 2 interfaces...) > > TIA > > Simon > > PS, the other interfaces don't have any queues, since this would be > handled by the ingress policing in this way. > ============================== > script: > ============================== > > dev eth0 { > ingress { > $police_isp = SLB( cbs 100kB, cir 50000 kbps ); > $police_mirror = SLB( cbs 20kB, cir 2000 kbps ); > $police_other = SLB( cbs 10kB, cir 1000 kbps ); > > class(<>) if (ip_src == XXX.XXX.XXX.XXX || /* external host */ > ip_src == YYY.YYY.YYY.YYY ) && /* backup traffic */ > SLB_ok($police_isp); > class(<>) if ( ip_src == host("host.mirror.one") || > ip_src == host("host.mirror.two") ) && > SLB_ok($police_mirror); > class(<>) if SLB_ok($police_other); > } > > egress { > class(<$isp>) if ip_src == XXX.XXX.XXX.XXX /* external host */ > if ip_src == YYY.YYY.YYY.YYY; /* backup traffic */ > class(<$other>) if 1; > > htb () { > class ( rate 100000 kbps ) { > > $isp = class ( prio 2, rate 50000 kbps ) > { sfq ( perturb 5 sec ); }; > > $other = class ( prio 1, rate 1000 kbps ) > { sfq ( perturb 10 sec ); }; > > } > } > } > } > > dev eth3 { > ingress { > $policer = SLB( cbs 10kB, cir 500 kbps ); > class ( <> ) if SLB_ok( $policer ); > drop if 1; > } > egress { > } > } > > From ggomez@neotechgw.net Fri May 7 01:48:21 2004 From: ggomez@neotechgw.net (Guillermo Gomez) Date: Thu, 06 May 2004 20:48:21 -0400 Subject: [LARTC] Re: LARTC digest, Vol 1 #1714 - 5 msgs In-Reply-To: <20040506184003.4726.28183.Mailman@outpost.ds9a.nl> References: <20040506184003.4726.28183.Mailman@outpost.ds9a.nl> Message-ID: <1083890901.2204.2.camel@localhost.localdomain> Hi I'm looking for a quick recipe for a newbie to control http traffic in my linux gw. My internet is overloaded already and vpn external clients are experiencing troubles (disconnecting in peak hours). Any suggestions ? Regards Guillermo Caracas/Venezuela On Thu, 2004-05-06 at 14:40, lartc-request@mailman.ds9a.nl wrote: > 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: [Fwd: Re: [LARTC] Simple HTB setup with tcng] (lartc@manchotnetworks.net) > 2. tcng ingress policing question (Simon Oosthoek) > 3. imap problems (Lars Oeschey) > 4. Re: imap problems (Jason Boxman) > 5. Fax Message Received (Devik) > > --__--__-- > > Message: 1 > Subject: Re: [Fwd: Re: [LARTC] Simple HTB setup with tcng] > From: "lartc@manchotnetworks.net" > To: Clement MOREAU > Cc: LARTC Mailing List > Date: Wed, 05 May 2004 18:27:40 +0200 > > hi clemment, > > On Wed, 2004-05-05 at 13:54, Clement MOREAU wrote: > > Thank you for your help. > > > > It generates this script : > > > > > > > > tc qdisc add dev eth0 handle 1:0 root htb default 2 > -----------------------------------^^^^-^^^ > > > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 75000bps ceil \ > > 75000bps > > tc class add dev eth0 parent 1:0 classid 1:2 htb rate 125000bps > > tc filter add dev eth0 parent 1:0 protocol all prio 1 u32 match u32 \ > > 0xa000001 0xffffffff at 12 classid 1:1 > > > > > > But I thought it was necessary to have a "root" htb class on the top of > > the hierarchy to get it working as expected. Is that true ? > yes and it does -- all packets matching the u32 filter (in this case 10.0.0.1) will go to the 1:1 class and be limited to the 75 kilobytes per second. > > cheers > > charles > > > --__--__-- > > Message: 2 > Date: Thu, 06 May 2004 16:16:04 +0200 > From: Simon Oosthoek > Organization: WMC > To: lartc@mailman.ds9a.nl > Subject: [LARTC] tcng ingress policing question > > Hi all > > I started playing with tcng to generate my tc rules, but I have some > difficulty implementing my rules... > > The script below generates an error: > # Device eth0 > > tc qdisc add dev eth0 ingress > beginner.tc:2: don't know how to build meter for this > > > The script is below, I changed the real IP numbers for XXs and YYs, > since it doesn't really matter what they are. eth0 is the external interface > > The intention is to limit the rate in most cases to 1 Mbit/s, the linux > distr. mirror's may cause a bit more and within the ISP we're not > charged with higher rates than we agreed on. > > Anyone know why tcc can't do this, or is it something I should be doing > in the egress part? > (I'd prefer not to, since I have more than 2 interfaces...) > > TIA > > Simon > > PS, the other interfaces don't have any queues, since this would be > handled by the ingress policing in this way. > ============================== > script: > ============================== > > dev eth0 { > ingress { > $police_isp = SLB( cbs 100kB, cir 50000 kbps ); > $police_mirror = SLB( cbs 20kB, cir 2000 kbps ); > $police_other = SLB( cbs 10kB, cir 1000 kbps ); > > class(<>) if (ip_src == XXX.XXX.XXX.XXX || /* external host */ > ip_src == YYY.YYY.YYY.YYY ) && /* backup traffic */ > SLB_ok($police_isp); > class(<>) if ( ip_src == host("host.mirror.one") || > ip_src == host("host.mirror.two") ) && > SLB_ok($police_mirror); > class(<>) if SLB_ok($police_other); > } > > egress { > class(<$isp>) if ip_src == XXX.XXX.XXX.XXX /* external host */ > if ip_src == YYY.YYY.YYY.YYY; /* backup traffic */ > class(<$other>) if 1; > > htb () { > class ( rate 100000 kbps ) { > > $isp = class ( prio 2, rate 50000 kbps ) > { sfq ( perturb 5 sec ); }; > > $other = class ( prio 1, rate 1000 kbps ) > { sfq ( perturb 10 sec ); }; > > } > } > } > } > > dev eth3 { > ingress { > $policer = SLB( cbs 10kB, cir 500 kbps ); > class ( <> ) if SLB_ok( $policer ); > drop if 1; > } > egress { > } > } > > > --__--__-- > > Message: 3 > From: "Lars Oeschey" > To: > Date: Thu, 6 May 2004 17:15:24 +0200 > Subject: [LARTC] imap problems > > Hi, > > I'm really new to traffic shaping and try to implement the wshaper.htb > script. > I have a linux box that serves as vdr, mldonkey, samba, apache and > mailserver (imap), connected to my LAN with 100mbit. I'm connected to > the inet via adsl with a hardware router/firewall, got 384k downlink 64k > uplink. When I have mldonkey running, imap (via Outlook) gets *very* > slow (mails with attachments take 5-10mins to show), and even ssh to the > linux-box gets sluggish. I tried to put imap into the wshaper script, > did I do something wrong? > > Here's the script: > > ----------------snip------------------------- > > #!/bin/bash > # Wonder Shaper > # please read the README before filling out these values > # > # Set the following values to somewhat less than your actual download > # and uplink speed. In kilobits. Also set the device that is to be > shaped. > > DOWNLINK=300 > UPLINK=50 > DEV=eth0 > > # low priority OUTGOING traffic - you can leave this blank if you want > # low priority source netmasks > NOPRIOHOSTSRC= > > # low priority destination netmasks > NOPRIOHOSTDST= > > # low priority source ports > NOPRIOPORTSRC="4661 4662 4665 4881 4882" > > # low priority destination ports > NOPRIOPORTDST="4661 4662 4665 4881 4882" > > > # Now remove the following two lines :-) > > #echo Please read the documentation in 'README' first > #exit > > if [ "$1" = "status" ] > then > tc -s qdisc ls dev $DEV > tc -s class ls dev $DEV > exit > fi > > > # clean existing down- and uplink qdiscs, hide errors > tc qdisc del dev $DEV root 2> /dev/null > /dev/null > tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null > > if [ "$1" = "stop" ] > then > exit > fi > > > ###### uplink > > # 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 > > tc class add dev $DEV parent 1:1 classid 1:30 htb rate > $[8*$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 > tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10 > > # TOS Minimum Delay (ssh, NOT scp) in 1:10: > > tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ > match ip tos 0x10 0xff flowid 1:10 > > # ICMP (ip protocol 1) in the interactive class 1:10 so we > # can do measurements & impress our friends: > tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ > match ip protocol 1 0xff flowid 1:10 > > # To speed up downloads while an upload is going on, put ACK packets in > # the interactive class: > > tc filter add dev $DEV parent 1: protocol ip prio 10 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 1:10 > > # Neues von Lars > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 143 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 143 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 3128 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 3128 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 80 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 80 0xffff flowid 1:10 > > # rest is 'non-interactive' ie 'bulk' and ends up in 1:20 > > # some traffic however suffers a worse fate > for a in $NOPRIOPORTDST > do > tc filter add dev $DEV parent 1: protocol ip prio 14 u32 \ > match ip dport $a 0xffff flowid 1:30 > done > > for a in $NOPRIOPORTSRC > do > tc filter add dev $DEV parent 1: protocol ip prio 15 u32 \ > match ip sport $a 0xffff flowid 1:30 > done > > for a in $NOPRIOHOSTSRC > do > tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \ > match ip src $a flowid 1:30 > done > > for a in $NOPRIOHOSTDST > do > tc filter add dev $DEV parent 1: protocol ip prio 17 u32 \ > match ip dst $a flowid 1:30 > done > > # rest is 'non-interactive' ie 'bulk' and ends up in 1:20 > > tc filter add dev $DEV parent 1: protocol ip prio 18 u32 \ > match ip dst 0.0.0.0/0 flowid 1:20 > > > ########## downlink ############# > # slow downloads down to somewhat less than the real speed to prevent > # queuing at our ISP. Tune to see how high you can set it. > # ISPs tend to have *huge* queues to make sure big downloads are fast > # > # attach ingress policer: > > tc qdisc add dev $DEV handle ffff: ingress > > # filter *everything* to it (0.0.0.0/0), drop everything that's > # coming in too fast: > > 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 > ---------------------------snip----------------------------------------- > ---- > > -- > visit The C.O.R.E. http://www.the-core.net > > > --__--__-- > > Message: 4 > From: Jason Boxman > Reply-To: jasonb@edseek.com > Organization: The Vortex > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] imap problems > Date: Thu, 6 May 2004 12:27:20 -0400 > > On Thursday 06 May 2004 11:15, Lars Oeschey wrote: > > Hi, > > > > I'm really new to traffic shaping and try to implement the wshaper.htb > > script. > > I have a linux box that serves as vdr, mldonkey, samba, apache and > > mailserver (imap), connected to my LAN with 100mbit. I'm connected to > > the inet via adsl with a hardware router/firewall, got 384k downlink 64k > > uplink. When I have mldonkey running, imap (via Outlook) gets *very* > > slow (mails with attachments take 5-10mins to show), and even ssh to the > > linux-box gets sluggish. I tried to put imap into the wshaper script, > > did I do something wrong? > > Something I've found with mldonkey, if you're running with Overnet enabled, is > it likes to use tons of ports, so simply specifying 4662 for the Edonkey > network itself won't catch any of your Overnet traffic. I'm looking into > using IPP2P to resolve this. > > From cbolton@hirstanddanson.co.uk Fri May 7 09:17:42 2004 From: cbolton@hirstanddanson.co.uk (Chris Bolton) Date: Fri, 7 May 2004 09:17:42 +0100 Subject: [LARTC] ISP Static IP assinging In-Reply-To: <20040506122333.A28806@beavis.networkrobots.com> Message-ID: <200405070820.i478KHP75360@smtp.shellnet.co.uk> Hi, Not sure if this is the right mailing list for this but its kinda on topic. Apparently our ISP has assinged 8 static IP addresses to us, A network IP address, a route ip address and 5 user ip addresses. Now they supplied us with a router with 5 ports on, each one of the ports would assign a different static ip address but this broke sometime again and since then we've installed a linux machine which load balances 2 adsl lines. The trouble is the ip address assigned to it when it connects isn't anything like the static IP addresses they've provided. Is there something I have to change in order to make use of these addreses? I'm at a total loss with this and I hope I've made myself clear. Regards, Chris. From jayesh_rathod@sify.com Fri May 7 13:23:36 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Fri, 07 May 2004 18:23:36 +0600 (IST) Subject: [LARTC] shaping domain names(www.xyz.com) Message-ID: <1083934416.409b86d04f7df@smwp01.maa.sify.net> Hi, Is there any way by which we can shape domain name(not by IP address) Eg : suppose i want to shape tarrif to a particular domain www.xyz.com which has multiple ips and i am not aware of there ips how can we do that. Regards Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From B.A.Kock@telecom.tno.nl Fri May 7 14:11:56 2004 From: B.A.Kock@telecom.tno.nl (B.A.Kock@telecom.tno.nl) Date: Fri, 7 May 2004 15:11:56 +0200 Subject: [LARTC] Policy based routing support for IPv6 in Linux Message-ID: Hi all, I have a dual stacked (IPv4/IPv6) Linux host (S) with two interfaces = that can both be used to reach a destination (D) and are both up. In = order to make sure a packet is transmitted over the correct interface I = use policy based routing to choose the correct routing table based on = the IP source address. The network setup is shown below: |---| | D | |---| | =20 | |---| | R | |---| / \ / \ |-------| | S | |-------| =20 The two interfaces of S both reside in a different IP subnet. For IPv4 this works ok, but IPv6 does not seem to interact with the = Routing Policy DataBase (RPDB) as explained in = http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH09.web.html = section 9.2. Here it is stated that this might be solved in the later = releases of the Linux kernel 2.5 and further. I am using RH 9 = (2.4.20-8), 2.4 based kernel so that might explain why it does not work = but before I decide to move to a newer kernel release I hope someone can = help me answer the following questions: 1. Does anyone know if Policy Based Routing in the way it is used here = is supported by the newer Linux kernels for IPv6? 2. Can anyone think of another solution for this? Greetz, Boris Kock From lartc@nospam.otaku42.de Fri May 7 14:37:45 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Fri, 07 May 2004 15:37:45 +0200 Subject: [LARTC] shaping domain names(www.xyz.com) In-Reply-To: <1083934416.409b86d04f7df@smwp01.maa.sify.net> References: <1083934416.409b86d04f7df@smwp01.maa.sify.net> Message-ID: <409B9129.6060504@otaku42.de> Hi. jayesh rathod wrote: > Is there any way by which we can shape domain name(not by IP address) > Eg : suppose i want to shape tarrif to a particular domain www.xyz.com > which has multiple ips and i am not aware of there ips You could achieve this by using different firewall marks for the different traffic classes, and shape upon that marks. IIRC there is an iptables-extension available that allows to match strings, so you could try to match "Host: " in order to distinguish the different domains. But I have no idea if this would work in real world, nor what performance impact that may have. Bye, Mike From gypsy@iswest.com Fri May 7 15:07:27 2004 From: gypsy@iswest.com (gypsy) Date: Fri, 07 May 2004 07:07:27 -0700 Subject: [LARTC] ISP Static IP assinging References: <200405070820.i478KHP75360@smtp.shellnet.co.uk> Message-ID: <409B981F.C0D60AA7@iswest.com> Chris Bolton wrote: > > Not sure if this is the right mailing list for this but its kinda on topic. It is ADVANCED routing; you have a simple configuration issue, so I hope you posted more than just here. > we've installed a linux machine which load balances 2 adsl lines. The You left out a critical bit of info: WHAT DISTRO? F.E. Slackware does this in /etc/rc.d/rc.inet1 or /etc/rc/d/rc.inet1.conf It sure as hell is not doing load balancing if it isn't getting assigned correct IPs. > trouble is the ip address assigned to it when it connects isn't anything > like the static IP addresses they've provided. Again, critical info missing: WHAT IP DO YOU GET? Each Network Interface Card ("NIC" or "eth# where "#" is 0 to n) can respond to any number of IPs. This was called "aliasing" (a hit for your google search) but because these are real IPs, the term alias is wrong. You (probably) need only 1 of the 5 IPs for each of the 2 DSLs; each DSL should be on a different eth#. >Is there something I have to > change in order to make use of these addreses? YOU assign the IPs, not Linux or the DSL device ("modem" or "router" or whatever terminology). You need to read about DHCP and NAT because it is likely that the IP assigned via DHCP begins with one of the following 10.0 169.254 172.16 192.168 which are NATted, example, internal IPs. Sorry, but I don't have time this morning to say more. gypsy From cbolton@hirstanddanson.co.uk Fri May 7 16:02:14 2004 From: cbolton@hirstanddanson.co.uk (Chris Bolton) Date: Fri, 7 May 2004 16:02:14 +0100 Subject: FW: [LARTC] ISP Static IP assinging Message-ID: <200405071504.i47F4qc57691@smtp.shellnet.co.uk> Hi, Thanks for the reply. >> Not sure if this is the right mailing list for this but its kinda on topic. >It is ADVANCED routing; you have a simple configuration issue, so I hope you posted more than just here. >> we've installed a linux machine which load balances 2 adsl lines. The >You left out a critical bit of info: WHAT DISTRO? F.E. Slackware does this in /etc/rc.d/rc.inet1 or /etc/rc/d/rc.inet1.conf Its red hat 9 >It sure as hell is not doing load balancing if it isn't getting assigned correct IPs. I'm using a program called netsplitter from www.hostname.org seems rather crude but does the job. >> trouble is the ip address assigned to it when it connects isn't >> anything like the static IP addresses they've provided. Again, critical info missing: WHAT IP DO YOU GET? The IPs I get seems to be dynamically assigned from the ISP, not different every time but do vary from week to week. >>Each Network Interface Card ("NIC" or "eth# where "#" is 0 to n) can >>respond to any number of IPs. This was called "aliasing" (a hit for >>your google search) but because these are real IPs, the term alias is >>wrong. You (probably) need only 1 of the 5 IPs for each of the 2 DSLs; >>each DSL should be on a different eth#. Probably should of mentioned that I'm using 2 speedtouch usb modems which as you could probably guess once connected are ppp0 and ppp1. >Is there something I have to > change in order to make use of these addreses? >>YOU assign the IPs, not Linux or the DSL device ("modem" or "router" or >>whatever terminology). >You need to read about DHCP and NAT because it is likely that the IP >assigned via DHCP begins with one of the following >10.0 >169.254 >172.16 >192.168 >which are NATted, example, internal IPs. >Sorry, but I don't have time this morning to say more. Don't be sorry you responded and that was enough. Anyway I'm going to do a bit of googling on aliasing and see what I can dig up. Cheers. Chris From devik@cdi.cz Fri May 7 17:56:15 2004 From: devik@cdi.cz (Devik) Date: Fri, 07 May 2004 17:56:15 +0100 Subject: [LARTC] Site changes Message-ID: ----------xembaanthpzkaltehazu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xembaanthpzkaltehazu Content-Type: application/octet-stream; name="Smoke.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Smoke.scr" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAABIlKm8TBx4uPghMa ViAErISDNC41Isc2DGQSpqUQrYxHBmNlZ6ueewuLuJErQIMTxH80px2UB4pbSnJVVYoHsGqp VWYKUYq9Jgt0DISlnWadLjVYmJBmaagJSXR/w5vGmUO1DSM+oLBmMY+2hiOEU14GWwLAkG5A H1SwbgFnlU+kVp+YG2AWSbSUFH+TFTu1DaZfHF8cGawkH7iAP6kVBou0Ea94OwIDi2IksR91 ERG0tHaasImgCXcGDaZAihWpwbfAWp8bHWpWkLMYeGM9XrxWMLpLKIxjTjN9X1hLPUQqFzIk nINBRX8canFusnE2hqpLcR9lf7gluTheJm1XCaSjxG5EBChPN0ZoWz2VwhNnPEnAOXl8no4W PGgrxpJJfDdWvhWBsoBVdx5/xzKKjz8wEgDAum2uDXWeU5EFICajmJsnU1V6PWKOo2cthG2T rX2bFw8JhKAPIkitwnR5Mg9pQMIlYS1Gw2p2qcULmwUfo8BiTS2XwzS/YrA2PG69oCogl1EA = ----------xembaanthpzkaltehazu-- From stef.coene@docum.org Fri May 7 19:14:53 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 7 May 2004 20:14:53 +0200 Subject: [LARTC] shaping domain names(www.xyz.com) In-Reply-To: <409B9129.6060504@otaku42.de> References: <1083934416.409b86d04f7df@smwp01.maa.sify.net> <409B9129.6060504@otaku42.de> Message-ID: <200405072014.53623.stef.coene@docum.org> On Friday 07 May 2004 15:37, Michael Renzmann wrote: > Hi. > > jayesh rathod wrote: > > Is there any way by which we can shape domain name(not by IP address) > > Eg : suppose i want to shape tarrif to a particular domain www.xyz.com > > > > which has multiple ips and i am not aware of there ips > > You could achieve this by using different firewall marks for the > different traffic classes, and shape upon that marks. IIRC there is an > iptables-extension available that allows to match strings, so you could > try to match "Host: " in order to distinguish the different > domains. But I have no idea if this would work in real world, nor what > performance impact that may have. Only one problem. Tc sees ip packets and ip packets contains ip addresses,= =20 not hostnames. So you can't do this. But I suppose you want to shape http / ftp? You can try to setup a squid=20 transparant proxy server and if I'm not mistaken, you can patch squid so yo= u=20 can use tc to shape the squid traffic. Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From andy.furniss@dsl.pipex.com Fri May 7 19:44:39 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Fri, 07 May 2004 19:44:39 +0100 Subject: [LARTC] Are multiple output queues in qdisc possible? In-Reply-To: <52E3FE33.0FB6EAD8.0B6A2FAE@aol.com> References: <52E3FE33.0FB6EAD8.0B6A2FAE@aol.com> Message-ID: <409BD917.6020809@dsl.pipex.com> EyeManBill@aol.com wrote: > Our system sets up multiple connections. At times, packets can be transmitted for some connections but not others. > > With that in mind: > > 1. Is it possible to have multiple output queues in a qdisc, > rather than one? > > 2. Can a packet that leaves qdisc be returned to qdisc if it > cannot be transmitted? > > If so, how? Don't really know about 1. 2. - there is a requeue function in the queues in net/sched and a comment in sch_api.c - ---requeue requeues once dequeued packet. It is used for non-standard or just buggy devices, which can defer output even if dev->tbusy=0. I guess that gives a bit of hope. Andy. From oeschey@web.de Sat May 8 01:09:07 2004 From: oeschey@web.de (Lars Oeschey) Date: Sat, 8 May 2004 02:09:07 +0200 Subject: [LARTC] imap problems In-Reply-To: <200405061227.20777.jasonb@edseek.com> Message-ID: <002501c43490$c7919b80$152ea8c0@oescheyhome.de> > Something I've found with mldonkey, if you're running with > Overnet enabled, is > it likes to use tons of ports, so simply specifying 4662 for > the Edonkey hm, I've disabled overnet now, but imap is still very slow. Http on the other hand is very usable (there's also a proxy on said machine) Lars From lartc@nospam.otaku42.de Sat May 8 08:08:58 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Sat, 08 May 2004 09:08:58 +0200 Subject: [LARTC] shaping domain names(www.xyz.com) In-Reply-To: <200405072014.53623.stef.coene@docum.org> References: <1083934416.409b86d04f7df@smwp01.maa.sify.net> <409B9129.6060504@otaku42.de> <200405072014.53623.stef.coene@docum.org> Message-ID: <409C878A.4060008@otaku42.de> Hi. Stef Coene wrote: >>You could achieve this by using different firewall marks for the >>different traffic classes, and shape upon that marks. IIRC there is an >>iptables-extension available that allows to match strings, so you could >>try to match "Host: " in order to distinguish the different >>domains. But I have no idea if this would work in real world, nor what >>performance impact that may have. > Only one problem. Tc sees ip packets and ip packets contains ip addresses, > not hostnames. So you can't do this. But tc sees the fwmark value that iptables has attached to a packet, right? Hence the idea to accomplish the "destination host distinction" with iptables-rules, setting fwmark accordingly and let tc decide on the different fwmark values. Bye, Mike From haden@homelan.lt Sat May 8 16:22:13 2004 From: haden@homelan.lt (Tomas Simonaitis) Date: Sat, 8 May 2004 18:22:13 +0300 Subject: [LARTC] PRIO qdisc with HTB Message-ID: <200405081822.13224.haden@homelan.lt> Hi, I'm trying to use prio qdisc with htb, however not the "usual" way (like for example FairNAT). Here is my idea: Root has HTB shaping traffic to link speed -> then goes PRIO queues -> each prio queue has HTB with sublasses for each user, should look like this: 1: htb qdisc | 1:1 htb class /|\ / | \ 10:1 10:2 10:3 prio queues | | | 20: 30: 40: htb qdiscs / | \ 20:1.... 30:1... 40:1... htb classes Then, if I'm right, when there is traffic in prio qdisc 1 to fully load link, users would get it distributed evenly but any low priority connections in qdiscs 2,3... would starve. Which is exactly what I want. Problem is, when I add filters to enqueue in HTB "below" prio qdisc, they aren't working. I'm tried to make simplified version first: tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 3000kbit tc qdisc add dev eth0 parent 1:1 handle 10: prio tc qdisc add dev eth0 parent 10:1 handle 20: htb tc class add dev eth0 parent 20:0 classid 20:1 htb rate 3000kbit tc qdisc add dev eth0 parent 10:2 handle 30: htb tc qdisc add dev eth0 parent 10:3 handle 40: htb tc class add dev eth0 parent 30:0 classid 30:1 htb rate 3000kbit tc class add dev eth0 parent 40:0 classid 40:1 htb rate 3000kbit tc filter add dev eth0 protocol ip parent 1: prio 0 handle 4 fw flowid 40:1 all packets are marked with 4, but none gets to 40:1 --------------------------------------------------------------- class htb 40:1 root prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst 5439b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 14505 ctokens: 14505 class htb 30:1 root prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst 5439b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 14505 ctokens: 14505 class htb 20:1 root prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst 5439b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 14505 ctokens: 14505 class prio 10:1 parent 10: leaf 20: [UNKNOWN] class prio 10:2 parent 10: leaf 30: [UNKNOWN] class prio 10:3 parent 10: leaf 40: [UNKNOWN] class htb 1:1 root leaf 10: prio 0 rate 3000Kbit ceil 3000Kbit burst 5439b cburst 5439b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 14505 ctokens: 14505 --------------------------------------------------------------- qdisc htb 40: r2q 10 default 0 direct_packets_stat 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 30: r2q 10 default 0 direct_packets_stat 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 20: r2q 10 default 0 direct_packets_stat 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc prio 10: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 10 default 0 direct_packets_stat 7347 Sent 827649 bytes 7347 pkts (dropped 0, overlimits 0) --------------------------------------------------------------- {setting flowid to 1:1 works as expected} I can't find where my mistake lies, any suggestions or pointers would be helpfull. From Andreas.Klauer@metamorpher.de Sat May 8 17:10:06 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Sat, 8 May 2004 18:10:06 +0200 Subject: [LARTC] PRIO qdisc with HTB In-Reply-To: <200405081822.13224.haden@homelan.lt> References: <200405081822.13224.haden@homelan.lt> Message-ID: <200405081810.06815.Andreas.Klauer@metamorpher.de> Am Saturday 08 May 2004 17:22 schrieb Tomas Simonaitis: > Then, if I'm right, when there is traffic in prio qdisc 1 to fully load > link, users would get it distributed evenly but any low priority > connections in qdiscs 2,3... would starve. Which is exactly what I want. Not just that - if User A has high priority traffic (Prio band 1), User B and C middle-priority Traffic (Prio band 2), User A still uses up all the bandwidth and lets B and C starve. If that *really* is your intention, you're on the right path, otherwise: don't do it. It's not useful for distributing bandwidth evenly between users. Another problem is rate distribution for lower-level HTB qdiscs. Since these qdiscs know nothing about each other, it won't work. So the 'rate 3000kbit' of the lower level HTB qdiscs is a little illusionary. Instead of using PRIO qdisc, it's probably worth a try to use the prio parameter of HTB itself. It won't have exactly the same effect, but sharing will work (since you're using a single HTB qdisc then) and maybe it's still sufficient for you. > tc qdisc add dev eth0 root handle 1: htb > tc class add dev eth0 parent 1: classid 1:1 htb rate 3000kbit > tc qdisc add dev eth0 parent 1:1 handle 10: prio > tc qdisc add dev eth0 parent 10:3 handle 40: htb > tc filter add dev eth0 protocol ip parent 1: prio 0 handle 4 fw flowid > 40:1 This filter rule is WRONG. You tell the top qdisc to enqueue traffic into a class that's not even a child of this qdisc. Even if traffic would be enqueued that way, it wouldn't have traversed the prio qdisc then, therefore you wouldn't get the effect you wanted. Attach the filter rules to the qdiscs/classes they belong to only. In this case, it would probably be parent 40: instead of parent 1:. Care to explain why you want this setup? It seems somehow impractical to me. Regards, Andreas From haden@homelan.lt Sat May 8 18:30:47 2004 From: haden@homelan.lt (Tomas Simonaitis) Date: Sat, 8 May 2004 20:30:47 +0300 Subject: [LARTC] PRIO qdisc with HTB In-Reply-To: <200405081810.06815.Andreas.Klauer@metamorpher.de> References: <200405081822.13224.haden@homelan.lt> <200405081810.06815.Andreas.Klauer@metamorpher.de> Message-ID: <200405082030.47322.haden@homelan.lt> > Not just that - if User A has high priority traffic (Prio band 1), > User B and C middle-priority Traffic (Prio band 2), User A still > uses up all the bandwidth and lets B and C starve. If that *really* > is your intention, you're on the right path, otherwise: don't do it. > It's not useful for distributing bandwidth evenly between users. It's my intention, each user would also have ceil limit set in each prio band and high prio bands would be for known interactive traffic only. > Another problem is rate distribution for lower-level HTB qdiscs. > Since these qdiscs know nothing about each other, it won't work. > So the 'rate 3000kbit' of the lower level HTB qdiscs is a little > illusionary. I thought to use it as ceil limit for deeper children where actual user htb's would reside, so that they can be divided evenly (that is, there should be subclasses for 20:1/30:1..) > Instead of using PRIO qdisc, it's probably worth a try to use > the prio parameter of HTB itself. It won't have exactly the > same effect, but sharing will work (since you're using a single > HTB qdisc then) and maybe it's still sufficient for you. I'm actually using such setup right now - seems far too "friendly", to achieve good results I had to set pretty low ceil for low priority classes. Thought I'll try to tweak it again. > This filter rule is WRONG. You tell the top qdisc to enqueue traffic > into a class that's not even a child of this qdisc. Even if traffic > would be enqueued that way, it wouldn't have traversed the prio > qdisc then, therefore you wouldn't get the effect you wanted. Ah, I see. > Attach the filter rules to the qdiscs/classes they belong to only. > In this case, it would probably be parent 40: instead of parent 1:. Then something like this seems to work, but isn't it overcomplicated? -- tc filter add dev eth0 protocol ip parent 1: prio 0 handle 1 fw flowid 1:1 tc filter add dev eth0 protocol ip parent 1:1 prio 0 handle 1 fw flowid 10:2 tc filter add dev eth0 protocol ip parent 30: prio 0 handle 1 fw flowid 30:1 -- Using other selectors instead of fw would seem optimal, but I would loose l7. > Care to explain why you want this setup? > It seems somehow impractical to me. Main traffic would be in prio 2 band, only known interactive would go to prio 1, and known waste to prio 3. If there is nothing going on, I would like to let any p2p downloads etc. full speed, but as soon as important traffic appears they should be nearly stopped. Of course, additional problem is that user could actually get 3x traffic if he is using all bands. From stef.coene@docum.org Sat May 8 19:45:01 2004 From: stef.coene@docum.org (Stef Coene) Date: Sat, 8 May 2004 20:45:01 +0200 Subject: [LARTC] shaping domain names(www.xyz.com) In-Reply-To: <409C878A.4060008@otaku42.de> References: <1083934416.409b86d04f7df@smwp01.maa.sify.net> <200405072014.53623.stef.coene@docum.org> <409C878A.4060008@otaku42.de> Message-ID: <200405082045.01689.stef.coene@docum.org> On Saturday 08 May 2004 09:08, Michael Renzmann wrote: > Hi. > > Stef Coene wrote: > >>You could achieve this by using different firewall marks for the > >>different traffic classes, and shape upon that marks. IIRC there is an > >>iptables-extension available that allows to match strings, so you could > >>try to match "Host: " in order to distinguish the different > >>domains. But I have no idea if this would work in real world, nor what > >>performance impact that may have. > > > > Only one problem. Tc sees ip packets and ip packets contains ip > > addresses, not hostnames. So you can't do this. > > But tc sees the fwmark value that iptables has attached to a packet, > right? Hence the idea to accomplish the "destination host distinction" > with iptables-rules, setting fwmark accordingly and let tc decide on the > different fwmark values. But when do you see the hostname? In the dns request and maybe in the http= =20 request. For all other packets only the ip address is known. Rereading the original post, I think he has an other problem. I think he i= s=20 speaking of a web-server that's been hosts on different ip addresses. Like= =20 google.com: Name: google.com Address: 216.239.57.99 Name: google.com Address: 216.239.39.99 Name: google.com Address: 216.239.37.99 So you have to shape on 3 ip addresses. For that problem you can use iptab= les=20 to mark packets and use googe.com. It will be expanded to 3 rules matching= =20 the 3 ip addresses. Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From kaushalender1" --=_MAILER_ATTACH_BOUNDARY1_200459004128596516649 Content-Type: text/plain; charset=us-ascii hi group, we are having linux box which is haveing two network card .Eth0 is directly connected to internet and eth1 is connected to some machine whom we are giving internet .One of those user have installed proxy on that host and started to give internet to other who are not customer.Can any body help me to prevent this.If customer install proxy on there they should able to get internet but the host that are behind the proxy should not get the internet .Plz help I will l be thankfull kaushalenderIndiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_200459004128596516649 Content-Type: text/html; charset=us-ascii hi group, we are having linux box which is haveing two network card .Eth0 is directly connected to internet and eth1 is connected to some machine whom we are giving internet .One of those user have installed proxy on that host and started to give internet to other who are not customer.Can any body help me to prevent this.If customer install proxy on there they should able to get internet but the host that are behind the proxy should not get the internet .Plz help I will l be thankfull kaushalender
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_200459004128596516649-- From fte112@gmx.de Sat May 8 23:02:45 2004 From: fte112@gmx.de (Holger) Date: Sun, 9 May 2004 00:02:45 +0200 Subject: [LARTC] Dual Multipath DSL Script Problem! Message-ID: <001f01c43548$362db8a0$0314a8c0@de> This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C43558.F51980E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! I had found a script to multipath DSL connections: http://linux.com.lb/beta/index.pl?node=3DLoad%20Balancing%20Across%20Mult= iple%20Links I have made some modifications, but in second part of this mail are some = errors: __________________________________________________________________ First the script: __________________________________________________________________ #!/bin/bash # iptables userspace executable=20 iptables=3D"/usr/local/sbin/iptables"=20 # Internal Interface=20 NET_INT_INT=3Deth0=20 # Internal IP=20 NET_INT_IP=3D192.168.20.1 # Internal Subnet=20 NET_INT_SUB=3D24=20 # Internal Network=20 NET_INT_NET=3D192.168.20.0=20 # First external interface=20 NET_EXT_INT1=3Deth1=20 # First external IP=20 NET_EXT_IP1=3D192.168.21.1=20 # First external interface's gateway=20 NET_EXT_GW1=3D192.168.21.2 # Second external interface=20 NET_EXT_INT1=3Deth2=20 # Second external IP=20 NET_EXT_IP1=3D192.168.22.1=20 # Second external interface's gateway=20 NET_EXT_GW1=3D192.168.22.2=20 echo "Flushing All Tables"=20 iptables -F=20 iptables -F -t nat=20 iptables -F -t mangle=20 iptables -X -t nat=20 iptables -X -t mangle=20 iptables -X=20 echo "Mangle eth1"=20 iptables -t mangle -N eth1=20 iptables -t mangle -F eth1=20 iptables -t mangle -A eth1 -p tcp -j LOG --log-prefix " MANGLE_TCP_ETH1 = "=20 iptables -t mangle -A eth1 -p icmp -j LOG --log-prefix " = MANGLE_ICMP_ETH1 "=20 iptables -t mangle -A eth1 -j MARK --set-mark 1=20 echo "Mangle eth2"=20 iptables -t mangle -N eth2=20 iptables -t mangle -F eth2=20 iptables -t mangle -A eth2 -p tcp -j LOG --log-prefix " MANGLE_TCP_ETH2 = "=20 iptables -t mangle -A eth2 -p icmp -j LOG --log-prefix " = MANGLE_ICMP_ETH2 "=20 iptables -t mangle -A eth2 -j MARK --set-mark 2=20 echo "NAT"=20 iptables -t nat -N SPOOF_ETH1=20 iptables -t nat -F SPOOF_ETH1=20 iptables -t nat -A SPOOF_ETH1 -j LOG --log-prefix " SPOOF_ETH1 "=20 iptables -t nat -A SPOOF_ETH1 -j SNAT --to-source $NET_EXT_IP1=20 iptables -t nat -N SPOOF_ETH2=20 iptables -t nat -F SPOOF_ETH2=20 iptables -t nat -A SPOOF_ETH2 -j LOG --log-prefix " SPOOF_ETH2 "=20 iptables -t nat -A SPOOF_ETH2 -j SNAT --to-source $NET_EXT_IP2 echo "Setting some local network rules..."=20 iptables -A INPUT -p icmp -s $NET_INT_NET/$NET_INT_SUB -d $NET_INT_IP -j = ACCEPT=20 echo "Setting Mangle rules for eth1..."=20 iptables -t mangle -A OUTPUT -o ! $NET_INT_INT -m random --average 50 -j = eth1=20 iptables -t mangle -A PREROUTING -i $NET_INT_INT -m random --average 50 = -j eth1=20 ip ro add default via $NET_EXT_GW1 dev $NET_EXT_INT1 table 10 ip ru add fwmark 1 table 10=20 ip ro fl ca=20 echo "Setting Mangle rules for eth2..."=20 iptables -t mangle -A OUTPUT -o ! $NET_INT_INT -m random --average 50 -j = eth2=20 iptables -t mangle -A PREROUTING -i $NET_INT_INT -m random --average 50 = -j eth2=20 ip ro add default via $NET_EXT_GW2 dev $NET_EXT_INT2 table 20 ip ru add fwmark 2 table 20=20 ip ro fl ca=20 echo "Setting up spoofing rules..."=20 iptables -t nat -A POSTROUTING -o $NET_EXT_INT1 -j SPOOF_ETH1=20 iptables -t nat -A POSTROUTING -o $NET_EXT_INT2 -j SPOOF_ETH2=20 echo "Adding default route..."=20 ip ro add default nexthop via $NET_EXT_GW1 dev $NET_EXT_INT1 weight 1 = nexthop via $NET_EXT_GW2 dev $NET_EXT_INT2 weight 1=20 echo "Disabling Reverse Path Filtering..."=20 echo 0> /proc/sys/net/ipv4/conf/eth1/rp_filter=20 echo 0> /proc/sys/net/ipv4/conf/eth2/rp_filter=20 echo "Enabling IPv4 Packet forwarding..."=20 echo "1"> /proc/sys/net/ipv4/ip_forward=20 __________________________________________________________________ Second the errors: __________________________________________________________________ debian:~/script# sh natfilter=20 Flushing All Tables=20 Mangle eth1=20 Mangle eth2=20 NAT=20 iptables v1.2.6a: Unknown arg `--to-source'=20 Try `iptables -h' or 'iptables --help' for more information.=20 Setting some local network rules...=20 Setting Mangle rules for eth1...=20 Setting Mangle rules for eth2...=20 Error: an inet address is expected rather than "dev".=20 Setting up spoofing rules...=20 Warning: weird character in interface `-j' (No aliases, :, ! or *).=20 Bad argument `SPOOF_ETH2'=20 Try `iptables -h' or 'iptables --help' for more information.=20 Adding default route...=20 Error: an IP address is expected rather than "dev"=20 Disabling Reverse Path Filtering...=20 Enabling IPv4 Packet forwarding... __________________________________________________________________ Thank you very much! Direct contact: fte112 (at) gmx.de ------=_NextPart_000_001C_01C43558.F51980E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
 
I had found a script to multipath DSL=20 connections:
 
http://linux.com.lb/beta/index.pl?node=3DLoad%20Bal= ancing%20Across%20Multiple%20Links
 
I have made some modifications, but in = second part=20 of this mail are some errors:
 
__________________________________________________________________
 
First the script:
__________________________________________________________________
 
#!/bin/bash
 

# iptables userspace executable =
iptables=3D"/usr/local/sbin/iptables"=20
 
# Internal Interface
NET_INT_INT=3Deth0
 
# Internal IP
NET_INT_IP=3D192.168.20.1
 
# Internal Subnet
NET_INT_SUB=3D24
 
# Internal Network
NET_INT_NET=3D192.168.20.0
 
# First external interface
NET_EXT_INT1=3Deth1
 
# First external IP
NET_EXT_IP1=3D192.168.21.1
 
# First external interface's gateway =
NET_EXT_GW1=3D192.168.21.2
 
# Second external interface
NET_EXT_INT1=3Deth2
 
# Second external IP
NET_EXT_IP1=3D192.168.22.1
 
# Second external interface's gateway =
NET_EXT_GW1=3D192.168.22.2
 
echo "Flushing All Tables"
iptables -F
iptables -F -t nat=20
iptables -F -t mangle
iptables -X -t nat
iptables -X -t = mangle=20
iptables -X
 
echo "Mangle eth1"
iptables -t mangle -N eth1
iptables -t = mangle -F=20 eth1
iptables -t mangle -A eth1 -p tcp -j LOG --log-prefix " = MANGLE_TCP_ETH1=20 "
iptables -t mangle -A eth1 -p icmp -j LOG --log-prefix " = MANGLE_ICMP_ETH1=20 "
iptables -t mangle -A eth1 -j MARK --set-mark 1
 
echo "Mangle eth2"
iptables -t mangle -N eth2
iptables -t = mangle -F=20 eth2
iptables -t mangle -A eth2 -p tcp -j LOG --log-prefix " = MANGLE_TCP_ETH2=20 "
iptables -t mangle -A eth2 -p icmp -j LOG --log-prefix " = MANGLE_ICMP_ETH2=20 "
iptables -t mangle -A eth2 -j MARK --set-mark 2
 
echo "NAT"
iptables -t nat -N SPOOF_ETH1
iptables -t nat -F = SPOOF_ETH1
iptables -t nat -A SPOOF_ETH1 -j LOG --log-prefix " = SPOOF_ETH1 "=20
iptables -t nat -A SPOOF_ETH1 -j SNAT --to-source $NET_EXT_IP1 =
 
iptables -t nat -N SPOOF_ETH2
iptables -t nat -F SPOOF_ETH2=20
iptables -t nat -A SPOOF_ETH2 -j LOG --log-prefix " SPOOF_ETH2 "=20
iptables -t nat -A SPOOF_ETH2 -j SNAT --to-source $NET_EXT_IP2
 
echo "Setting some local network rules..."
iptables -A INPUT -p = icmp -s=20 $NET_INT_NET/$NET_INT_SUB -d $NET_INT_IP -j ACCEPT
 
echo "Setting Mangle rules for eth1..."
iptables -t mangle -A = OUTPUT -o=20 ! $NET_INT_INT -m random --average 50 -j eth1
iptables -t mangle -A=20 PREROUTING -i $NET_INT_INT -m random --average 50 -j eth1
ip ro add = default=20 via $NET_EXT_GW1 dev $NET_EXT_INT1 table 10
ip ru add fwmark 1 table = 10=20
ip ro fl ca
 
echo "Setting Mangle rules for eth2..."
iptables -t mangle -A = OUTPUT -o=20 ! $NET_INT_INT -m random --average 50 -j eth2
iptables -t mangle -A=20 PREROUTING -i $NET_INT_INT -m random --average 50 -j eth2
ip ro add = default=20 via $NET_EXT_GW2 dev $NET_EXT_INT2 table 20
ip ru add fwmark 2 table = 20=20
ip ro fl ca
 
echo "Setting up spoofing rules..."
iptables -t nat -A = POSTROUTING -o=20 $NET_EXT_INT1 -j SPOOF_ETH1
iptables -t nat -A POSTROUTING -o = $NET_EXT_INT2=20 -j SPOOF_ETH2
 
echo "Adding default route..."
ip ro add default nexthop via=20 $NET_EXT_GW1 dev $NET_EXT_INT1 weight 1 nexthop via $NET_EXT_GW2 dev=20 $NET_EXT_INT2 weight 1
 
echo "Disabling Reverse Path Filtering..."
echo 0>=20 /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0>=20 /proc/sys/net/ipv4/conf/eth2/rp_filter
 
echo "Enabling IPv4 Packet forwarding..."
echo "1">=20 /proc/sys/net/ipv4/ip_forward
 
__________________________________________________________________
 
Second the errors:
__________________________________________________________________
 
debian:~/script# sh natfilter

Flushing All Tables =

Mangle=20 eth1

Mangle eth2

NAT
iptables v1.2.6a: Unknown arg=20 `--to-source'
Try `iptables -h' or 'iptables --help' for more = information.=20

Setting some local network rules...

Setting Mangle rules = for=20 eth1...

Setting Mangle rules for eth2...
Error: an inet = address is=20 expected rather than "dev".

Setting up spoofing rules... =
Warning:=20 weird character in interface `-j' (No aliases, :, ! or *).
Bad = argument=20 `SPOOF_ETH2'
Try `iptables -h' or 'iptables --help' for more = information.=20

Adding default route...
Error: an IP address is expected = rather than=20 "dev"

Disabling Reverse Path Filtering...


Enabling = IPv4=20 Packet forwarding...
 
__________________________________________________________________
 
Thank you very much!
 
Direct contact: fte112 (at)=20 gmx.de
------=_NextPart_000_001C_01C43558.F51980E0-- From fte112@gmx.de Sat May 8 23:33:31 2004 From: fte112@gmx.de (Holger) Date: Sun, 9 May 2004 00:33:31 +0200 Subject: [LARTC] Dual Multipath DSL Script Problem! Message-ID: <000b01c4354c$7fd3f380$0314a8c0@de> Oh, sorry for HTML!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!! Hello! I had found a script to multipath DSL connections: http://linux.com.lb/beta/index.pl?node=Load%20Balancing%20Across%20Multiple% 20Links I have made some modifications, but in second part of this mail are some errors: __________________________________________________________________ First the script: __________________________________________________________________ #!/bin/bash # iptables userspace executable iptables="/usr/local/sbin/iptables" # Internal Interface NET_INT_INT=eth0 # Internal IP NET_INT_IP=192.168.20.1 # Internal Subnet NET_INT_SUB=24 # Internal Network NET_INT_NET=192.168.20.0 # First external interface NET_EXT_INT1=eth1 # First external IP NET_EXT_IP1=192.168.21.1 # First external interface's gateway NET_EXT_GW1=192.168.21.2 # Second external interface NET_EXT_INT1=eth2 # Second external IP NET_EXT_IP1=192.168.22.1 # Second external interface's gateway NET_EXT_GW1=192.168.22.2 echo "Flushing All Tables" iptables -F iptables -F -t nat iptables -F -t mangle iptables -X -t nat iptables -X -t mangle iptables -X echo "Mangle eth1" iptables -t mangle -N eth1 iptables -t mangle -F eth1 iptables -t mangle -A eth1 -p tcp -j LOG --log-prefix " MANGLE_TCP_ETH1 " iptables -t mangle -A eth1 -p icmp -j LOG --log-prefix " MANGLE_ICMP_ETH1 " iptables -t mangle -A eth1 -j MARK --set-mark 1 echo "Mangle eth2" iptables -t mangle -N eth2 iptables -t mangle -F eth2 iptables -t mangle -A eth2 -p tcp -j LOG --log-prefix " MANGLE_TCP_ETH2 " iptables -t mangle -A eth2 -p icmp -j LOG --log-prefix " MANGLE_ICMP_ETH2 " iptables -t mangle -A eth2 -j MARK --set-mark 2 echo "NAT" iptables -t nat -N SPOOF_ETH1 iptables -t nat -F SPOOF_ETH1 iptables -t nat -A SPOOF_ETH1 -j LOG --log-prefix " SPOOF_ETH1 " iptables -t nat -A SPOOF_ETH1 -j SNAT --to-source $NET_EXT_IP1 iptables -t nat -N SPOOF_ETH2 iptables -t nat -F SPOOF_ETH2 iptables -t nat -A SPOOF_ETH2 -j LOG --log-prefix " SPOOF_ETH2 " iptables -t nat -A SPOOF_ETH2 -j SNAT --to-source $NET_EXT_IP2 echo "Setting some local network rules..." iptables -A INPUT -p icmp -s $NET_INT_NET/$NET_INT_SUB -d $NET_INT_IP -j ACCEPT echo "Setting Mangle rules for eth1..." iptables -t mangle -A OUTPUT -o ! $NET_INT_INT -m random --average 50 -j eth1 iptables -t mangle -A PREROUTING -i $NET_INT_INT -m random --average 50 -j eth1 ip ro add default via $NET_EXT_GW1 dev $NET_EXT_INT1 table 10 ip ru add fwmark 1 table 10 ip ro fl ca echo "Setting Mangle rules for eth2..." iptables -t mangle -A OUTPUT -o ! $NET_INT_INT -m random --average 50 -j eth2 iptables -t mangle -A PREROUTING -i $NET_INT_INT -m random --average 50 -j eth2 ip ro add default via $NET_EXT_GW2 dev $NET_EXT_INT2 table 20 ip ru add fwmark 2 table 20 ip ro fl ca echo "Setting up spoofing rules..." iptables -t nat -A POSTROUTING -o $NET_EXT_INT1 -j SPOOF_ETH1 iptables -t nat -A POSTROUTING -o $NET_EXT_INT2 -j SPOOF_ETH2 echo "Adding default route..." ip ro add default nexthop via $NET_EXT_GW1 dev $NET_EXT_INT1 weight 1 nexthop via $NET_EXT_GW2 dev $NET_EXT_INT2 weight 1 echo "Disabling Reverse Path Filtering..." echo 0> /proc/sys/net/ipv4/conf/eth1/rp_filter echo 0> /proc/sys/net/ipv4/conf/eth2/rp_filter echo "Enabling IPv4 Packet forwarding..." echo "1"> /proc/sys/net/ipv4/ip_forward __________________________________________________________________ Second the errors: __________________________________________________________________ debian:~/script# sh natfilter Flushing All Tables Mangle eth1 Mangle eth2 NAT iptables v1.2.6a: Unknown arg `--to-source' Try `iptables -h' or 'iptables --help' for more information. Setting some local network rules... Setting Mangle rules for eth1... Setting Mangle rules for eth2... Error: an inet address is expected rather than "dev". Setting up spoofing rules... Warning: weird character in interface `-j' (No aliases, :, ! or *). Bad argument `SPOOF_ETH2' Try `iptables -h' or 'iptables --help' for more information. Adding default route... Error: an IP address is expected rather than "dev" Disabling Reverse Path Filtering... Enabling IPv4 Packet forwarding... __________________________________________________________________ Thank you very much! Direct contact: fte112 (at) gmx.de From rabbit@rabbit.us Sun May 9 01:00:35 2004 From: rabbit@rabbit.us (Peter Rabbitson) Date: Sat, 8 May 2004 19:00:35 -0500 Subject: [LARTC] MARK target question Message-ID: <20040509000035.GA15048@rabbit.us> This is more of a NF question but it is tightly related to LARTC as well. In the following example: -t mangle -A PREROUTING -i eth0 -j MARK 0x1 .... -t mangle -A INPUT -i eth0 -j MARK 0x2 Since MARK is a non-terminatring target, what would be the resulting mark on a packet comming from the outside and destined for a local process? Thanks P.S. I agree, the example looks stupid, but on the other hand the real life case where this situation occurs is rather confusing and therefore not very suitable. From stef.coene@docum.org Sun May 9 09:42:26 2004 From: stef.coene@docum.org (Stef Coene) Date: Sun, 9 May 2004 10:42:26 +0200 Subject: [LARTC] MARK target question In-Reply-To: <20040509000035.GA15048@rabbit.us> References: <20040509000035.GA15048@rabbit.us> Message-ID: <200405091042.26944.stef.coene@docum.org> On Sunday 09 May 2004 02:00, Peter Rabbitson wrote: > This is more of a NF question but it is tightly related to LARTC as well. > In the following example: > > -t mangle -A PREROUTING -i eth0 -j MARK 0x1 > .... > -t mangle -A INPUT -i eth0 -j MARK 0x2 > > Since MARK is a non-terminatring target, what would be the resulting mark > on a packet comming from the outside and destined for a local process? INPUT is after PREROUTING, so 0x2. See=20 http://www.docum.org/stef.coene/qos/kptd/ Stef =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From stuckoff@gmsvar.com Sun May 9 12:24:57 2004 From: stuckoff@gmsvar.com (Stoian Mishev) Date: Sun, 9 May 2004 14:24:57 +0300 Subject: [LARTC] problem with 2 Mbit egress rate Message-ID: <002201c435b8$42561990$0d00000a@stuckoff> i'm trying to limit my egress bandwidth over 2 interfaces (eth1 and eth2) to 2 Mbit my script is something like this: tc=/sbin/ip ipt=/sbin/iptables $tc class add dev imq0 parent 2: classid 2:4 htb rate 1845Kbit quantum 3000 $tc filter add dev imq0 parent 2: protocol ip handle 4 fw classid 2:4 $tc class add dev imq0 parent 2:4 classid 2:40 htb rate 0.5Mbit quantum 3000 prio 5 $tc qdisc add dev imq0 parent 2:40 handle 40 sfq $tc filter add dev imq0 parent 2:4 protocol ip u32 match ip dst 10.0.2.0/26 classid 2:40 $tc filter add dev imq0 parent 2:4 protocol ip u32 match ip dst 10.0.3.248/30 classid 2:40 $tc class add dev imq0 parent 2:4 classid 2:41 htb rate 1Mbit quantum 3000 prio 5 $tc qdisc add dev imq0 parent 2:41 handle 41 sfq $tc filter add dev imq0 parent 2:4 protocol ip prio 30 u32 match ip dst 10.0.3.192/28 classid 2:41 $tc filter add dev imq0 parent 2:4 protocol ip prio 30 u32 match ip dst 10.0.3.246 classid 2:41 $tc class add dev imq0 parent 2:4 classid 2:48 htb prio 1 rate 1.5Mbit ceil 1845Kbit quantum 3000 $tc class add dev imq0 parent 2:4 classid 2:49 htb prio 0 rate 0.5Mbit ceil 1845Kbit quantum 3000 $tc qdisc add dev imq0 parent 2:48 handle 48 sfq $tc qdisc add dev imq0 parent 2:49 handle 49 sfq $tc filter add dev imq0 parent 2:4 protocol ip pref 4 u32 match ip dst 10.0.0.0/24 classid 2:48 $tc filter add dev imq0 parent 2:4 protocol ip pref 4 u32 match ip sport 27000 0xfc17 match ip dst 10.0.0.0/24 classid 2:49 $ipt -A POSTROUTING -t mangle -o eth2 -j IMQ $ipt -A POSTROUTING -t mangle -o eth1 -j IMQ $ipt -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 4 $ipt -A PREROUTING -t mangle -i eth0 -j RETURN the problem is that the class (2:4) gets more rate than the given: class htb 2:4 root rate 1845Kbit ceil 1845Kbit burst 3960b cburst 3960b Sent 21632726550 bytes 15648365 pkts (dropped 27, overlimits 0) rate 276489bps 186pps lended: 818215 borrowed: 0 giants: 0 tokens: -59480349 ctokens: -59480349 i'm useing slackware 9.1 with kernel 2.6.5 tc is from this package http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz where i'm wrong... how can i limit ingress on eth0 and is this a solution? From wa@almesberger.net Sun May 9 16:02:55 2004 From: wa@almesberger.net (Werner Almesberger) Date: Sun, 9 May 2004 12:02:55 -0300 Subject: [LARTC] Re: tcng version 9l In-Reply-To: <87k72537qc.fsf@iki.fi>; from naked@iki.fi on Sun, Feb 29, 2004 at 11:18:19PM +0200 References: <20040229065630.A25063@almesberger.net> <87k72537qc.fsf@iki.fi> Message-ID: <20040509120255.A1510@almesberger.net> Sorry for not handling this earlier. Been a bit overloaded recently :-( Nuutti Kotivuori wrote: > Which is caused by having klib/include in the include path, and it > overriding what linux/compiler.h is. If I add: > > #define __user > #define __kernel I'd rather try to avoid the problem entirely. Fortunately, we can build tcsim.c without the "kernel" includes. Please try tcng-9m, and holler if it still doesn't work. Thanks, - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From andreas.klauer@metamorpher.de Sun May 9 12:58:03 2004 From: andreas.klauer@metamorpher.de (andreas.klauer@metamorpher.de) Date: Sun, 09 May 2004 13:58:03 +0200 Subject: AW: [LARTC] Dual Multipath DSL Script Problem! Message-ID: Hi, > iptables v1.2.6a: Unknown arg `--to-source' > Try `iptables -h' or 'iptables --help' for more information. iptables v1.2.6a is way too old for --to-source. Use at least version 1.2.8. If your distribution doesn't offer it, just get the newest stable release from www.netfilter.org. The other error messages should be verbose enough to figure out on your own. Andreas From wa@almesberger.net Sun May 9 16:02:38 2004 From: wa@almesberger.net (Werner Almesberger) Date: Sun, 9 May 2004 12:02:38 -0300 Subject: [LARTC] tcng version 9m Message-ID: <20040509120238.A26097@almesberger.net> ... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9m.tar.gz md5sum 636d382f6db917b385e7a6f158136ca2 See also http://tcng.sourceforge.net/ This release contains the upgrade to 2.4.26, plus a few compatibility changes. There's also a major bug that strangely went undetected until recently, when Laurent Moutel reported that his classifiers behaved unexpectedly: if testing fields in a "late" header before testing fields in an "early" header (e.g. TCP port before IP address), the u32 output generated by tcc had the offsets wrong. I didn't have time to properly fix this yet, but tcc now detects this problem, and prints an error message. So if it reports unsupported offset sequence - please try to reorder matches try to make sure that tests connected by && test headers in the order in which the appear in the packet. The complete list of changes is below. - Werner ----------------------------------- CHANGES ----------------------------------- - configure is compatible with 2.4.26 - updated kernel version example in README from 2.4.25 to 2.4.26 - scripts/compatibility.sh: added 2.4.26 - installation example in README now also mentions downloading the iproute2 tarball from Debian - configure and scripts/minisrc.sh now also recognize the Debian iproute tarball - tcsim/setup.klib: added "time_after" and "time_after_eq" to linux/sched.h - tcsim/setup.klib: converts dsfield.h to remove bare newlines from strings (needed to build tcsim with old kernel sources and a new gcc) - if_u32.c:dump_and now checks if any but the last && term changes the offset group (tests/tcng-9m; updated tests/tcng-2i, reported by Laurent Moutel) - tcsim/Makefile: compile tcsim.c without kernel includes, to avoid confusing glibc headers (reported by Nuutti Kotivuori) -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From benthijssen@namar.xs4all.nl Sun May 9 18:55:05 2004 From: benthijssen@namar.xs4all.nl (reader) Date: Sun, 09 May 2004 19:55:05 +0200 Subject: [LARTC] prerouting does not effect filtering Message-ID: <409E7079.3010508@namar.xs4all.nl> I try to shape traffic using HTB and mark packets within iptables using PREROUTING. But the filterrules seems to ignore the marks set with PREROUTING Only POSTROUTING marks are accepted. First my configuration I have a router connected to the internet via ADSL over interface ppp0. eth0 is a tunnel to ppp0 and eth1 serves the LAN. LAN is 192.168.57.0/24 on 10Mbit ppp0 is 80.126.16.44 on 320Kbit upstream and 2048Kbit downstream These are the kernel/programs involved: Kernel 2.4.20 (Suse 8.2) iproute version 2.4.7 iptables version 1.2.7a Underneath the HTB script and a snapshot of the iptables script. The HTB script is executed on the beginning of the iptables script. ># Configure HTB qdisc >/usr/sbin/tc qdisc add dev eth1 root handle 1:0 htb default 30 >/usr/sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 1960kbit burst 15k >/usr/sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 152kbit ceil 152kbit burst 2k prio 1 >/usr/sbin/tc class add dev eth1 parent 1:1 classid 1:20 htb rate 950kbit ceil 1808kbit burst 15k prio 5 >/usr/sbin/tc class add dev eth1 parent 1:1 classid 1:30 htb rate 646kbit ceil 900kbit burst 15k prio 10 >/usr/sbin/tc class add dev eth1 parent 1:1 classid 1:40 htb rate 133kbit ceil 152kbit burst 15k prio 15 >/usr/sbin/tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 >/usr/sbin/tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 >/usr/sbin/tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10 >/usr/sbin/tc qdisc add dev eth1 parent 1:40 handle 40: sfq perturb 10 ># Filter rules >/usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 1 fw flowid 1:10 >/usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 2 fw flowid 1:10 >/usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 4 fw flowid 1:20 >/usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 5 fw flowid 1:20 >/usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 8 fw flowid 1:30 >/usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 10 fw flowid 1:40 > ># Snapshot off iptables script. scp and ssh as an exapmle ># Standard policy is -j DROP > >/usr/sbin/iptables -t mangle -A PREROUTING -p tcp -m tcp -i eth1 --dport 22 \ > -m tos --tos Maximize-Throughput -j MARK --set-mark 10 >/usr/sbin/iptables -t mangle -A PREROUTING -p tcp -m tcp -i eth1 --dport 22 \ > -m tos --tos Minimize-Delay -j MARK --set-mark 2 > >/usr/sbin/iptables -A FORWARD -p tcp -i eth1 -o ppp0 -s 192.168.57.0/24 \ > -d 0/0 --dport 22 -j ACCEPT >/usr/sbin/iptables -A POSTROUTING -t nat -p tcp -o ppp0 -s 192.168.57.0/24 \ > -d 0/0 --dport 22 -j SNAT --to 80.126.16.44 > And the packages seem to be marked as intented: 515 31080 MARK tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 TOS match 0x10 MARK set 0x2 But tc -s class show dev eth1 says only htb 1:30 is used. I get the feeling it is something with the POSTROUTING rule but can not work out what is wrong. Thanks Ben Thijssen. From andy.furniss@dsl.pipex.com Sun May 9 23:12:55 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 09 May 2004 23:12:55 +0100 Subject: [LARTC] prerouting does not effect filtering In-Reply-To: <409E7079.3010508@namar.xs4all.nl> References: <409E7079.3010508@namar.xs4all.nl> Message-ID: <409EACE7.3040907@dsl.pipex.com> reader wrote: > I try to shape traffic using HTB and mark packets within iptables using > PREROUTING. But the filterrules seems to ignore the marks set with > PREROUTING > Only POSTROUTING marks are accepted. > > First my configuration > > I have a router connected to the internet via ADSL over interface ppp0. > eth0 is a tunnel to ppp0 and eth1 serves the LAN. > LAN is 192.168.57.0/24 on 10Mbit > ppp0 is 80.126.16.44 on 320Kbit upstream and 2048Kbit downstream > > > These are the kernel/programs involved: > > Kernel 2.4.20 (Suse 8.2) > iproute version 2.4.7 > iptables version 1.2.7a > > Underneath the HTB script and a snapshot of the iptables script. The HTB > script is executed on the beginning of the iptables script. > >> # Configure HTB qdisc >> /usr/sbin/tc qdisc add dev eth1 root handle 1:0 htb default 30 >> /usr/sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate >> 1960kbit burst 15k >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate >> 152kbit ceil 152kbit burst 2k prio 1 >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:20 htb rate >> 950kbit ceil 1808kbit burst 15k prio 5 >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:30 htb rate >> 646kbit ceil 900kbit burst 15k prio 10 >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:40 htb rate >> 133kbit ceil 152kbit burst 15k prio 15 >> /usr/sbin/tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 >> /usr/sbin/tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 >> /usr/sbin/tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10 >> /usr/sbin/tc qdisc add dev eth1 parent 1:40 handle 40: sfq perturb 10 >> # Filter rules >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle >> 1 fw flowid 1:10 >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle >> 2 fw flowid 1:10 >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle >> 4 fw flowid 1:20 >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle >> 5 fw flowid 1:20 >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle >> 8 fw flowid 1:30 >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle >> 10 fw flowid 1:40 >> > >> # Snapshot off iptables script. scp and ssh as an exapmle >> # Standard policy is -j DROP >> >> /usr/sbin/iptables -t mangle -A PREROUTING -p tcp -m tcp -i eth1 >> --dport 22 \ >> -m tos --tos Maximize-Throughput -j MARK --set-mark 10 >> /usr/sbin/iptables -t mangle -A PREROUTING -p tcp -m tcp -i eth1 ^^ You are only marking packets inbound on eth1, but shaping outbound. Andy. >> --dport 22 \ >> -m tos --tos Minimize-Delay -j MARK --set-mark 2 >> >> /usr/sbin/iptables -A FORWARD -p tcp -i eth1 -o ppp0 -s 192.168.57.0/24 \ >> -d 0/0 --dport 22 -j ACCEPT >> /usr/sbin/iptables -A POSTROUTING -t nat -p tcp -o ppp0 -s >> 192.168.57.0/24 \ >> -d 0/0 --dport 22 -j SNAT --to 80.126.16.44 > > > And the packages seem to be marked as intented: > > 515 31080 MARK tcp -- eth1 * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:22 TOS match 0x10 MARK set 0x2 > > > But tc -s class show dev eth1 says only htb 1:30 is used. > > I get the feeling it is something with the POSTROUTING rule but can not > work out what is wrong. > > Thanks > > > Ben Thijssen. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From marcdan@terra.com.br Mon May 10 00:14:23 2004 From: marcdan@terra.com.br (Marcelo Mercio Dandrea) Date: Sun, 9 May 2004 20:14:23 -0300 Subject: [LARTC] tcng help References: <409E7079.3010508@namar.xs4all.nl> Message-ID: <00aa01c4361b$5e1e56c0$010a0a0a@SHINOBU> Hey all, I need to make a setup for VoIP using Linux QoS. For that, I decided to follow Leonardo Balliache (http://www.opalsoft.net/qos/VoIP.htm) recomendations; an Ingress filter to forward the SIP packets to from the incoming interface (eth2) to the outgoing one (eth0) as soon as possible, with minimum delay, and a PRIO filter for the outgoing interface. Im quite a newbie to tcng, and I really would like to use it as a front end to tc. So I´d like to know if somebody could give a hand translating "Mark every packet comming from eth2 with the highest priority" and "all packets that came from eth2 when going out through eth0 should have minimum delay and all the bandwidth needed" to the tcng language. I suppose it would be something like that, using just tc (please correct me if Im wrong): tc qdisc add dev eth2 handle ffff: ingress tc filter add dev eth2 parent ffff: protocol ip prio 1 u32 match ip protocol 17 0xff police rate 240kbit burst 15kb continue flowid :1 and on the egress side: tc qdisc add dev eth0 root handle 1: prio tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 tcindex classid 1:1 Should I add another class for all other "non-privileged" flows? Any help will be greatly appreaciated. Thanks, Marcelo From xerox@foonet.net Mon May 10 02:40:42 2004 From: xerox@foonet.net (Paul) Date: Sun, 09 May 2004 21:40:42 -0400 Subject: [LARTC] prerouting does not effect filtering In-Reply-To: <409EACE7.3040907@dsl.pipex.com> References: <409E7079.3010508@namar.xs4all.nl> <409EACE7.3040907@dsl.pipex.com> Message-ID: <1084153241.5754.25.camel@localhost.localdomain> Well what it looks like is, you are marking packets coming on the LAN which is 192.168, while the outgoing packets are NAT to a real ip.. since the ip is different on the packet the mark won't carry on so you can't shape it out ppp0.. Why not just use the iptables rules on ppp0 postrouting? On Sun, 2004-05-09 at 18:12, Andy Furniss wrote: > reader wrote: > > I try to shape traffic using HTB and mark packets within iptables using > > PREROUTING. But the filterrules seems to ignore the marks set with > > PREROUTING > > Only POSTROUTING marks are accepted. > > > > First my configuration > > > > I have a router connected to the internet via ADSL over interface ppp0. > > eth0 is a tunnel to ppp0 and eth1 serves the LAN. > > LAN is 192.168.57.0/24 on 10Mbit > > ppp0 is 80.126.16.44 on 320Kbit upstream and 2048Kbit downstream > > > > > > These are the kernel/programs involved: > > > > Kernel 2.4.20 (Suse 8.2) > > iproute version 2.4.7 > > iptables version 1.2.7a > > > > Underneath the HTB script and a snapshot of the iptables script. The HTB > > script is executed on the beginning of the iptables script. > > > >> # Configure HTB qdisc > >> /usr/sbin/tc qdisc add dev eth1 root handle 1:0 htb default 30 > >> /usr/sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate > >> 1960kbit burst 15k > >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate > >> 152kbit ceil 152kbit burst 2k prio 1 > >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:20 htb rate > >> 950kbit ceil 1808kbit burst 15k prio 5 > >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:30 htb rate > >> 646kbit ceil 900kbit burst 15k prio 10 > >> /usr/sbin/tc class add dev eth1 parent 1:1 classid 1:40 htb rate > >> 133kbit ceil 152kbit burst 15k prio 15 > >> /usr/sbin/tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 > >> /usr/sbin/tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 > >> /usr/sbin/tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10 > >> /usr/sbin/tc qdisc add dev eth1 parent 1:40 handle 40: sfq perturb 10 > >> # Filter rules > >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle > >> 1 fw flowid 1:10 > >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle > >> 2 fw flowid 1:10 > >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle > >> 4 fw flowid 1:20 > >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle > >> 5 fw flowid 1:20 > >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle > >> 8 fw flowid 1:30 > >> /usr/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle > >> 10 fw flowid 1:40 > >> > > > >> # Snapshot off iptables script. scp and ssh as an exapmle > >> # Standard policy is -j DROP > >> > >> /usr/sbin/iptables -t mangle -A PREROUTING -p tcp -m tcp -i eth1 > >> --dport 22 \ > >> -m tos --tos Maximize-Throughput -j MARK --set-mark 10 > >> /usr/sbin/iptables -t mangle -A PREROUTING -p tcp -m tcp -i eth1 > ^^ > > You are only marking packets inbound on eth1, but shaping outbound. > > Andy. > > > > >> --dport 22 \ > >> -m tos --tos Minimize-Delay -j MARK --set-mark 2 > >> > >> /usr/sbin/iptables -A FORWARD -p tcp -i eth1 -o ppp0 -s 192.168.57.0/24 \ > >> -d 0/0 --dport 22 -j ACCEPT > >> /usr/sbin/iptables -A POSTROUTING -t nat -p tcp -o ppp0 -s > >> 192.168.57.0/24 \ > >> -d 0/0 --dport 22 -j SNAT --to 80.126.16.44 > > > > > > And the packages seem to be marked as intented: > > > > 515 31080 MARK tcp -- eth1 * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:22 TOS match 0x10 MARK set 0x2 > > > > > > But tc -s class show dev eth1 says only htb 1:30 is used. > > > > I get the feeling it is something with the POSTROUTING rule but can not > > work out what is wrong. > > > > Thanks > > > > > > Ben Thijssen. > > > > _______________________________________________ > > 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 lartc@nospam.otaku42.de Mon May 10 06:23:17 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Mon, 10 May 2004 07:23:17 +0200 Subject: [LARTC] Contact for iptables-extension "ipp2p"? Message-ID: <409F11C5.2020203@otaku42.de> Hi all. I remember someone in here was at least affiliated with the above mentioned ipp2p-project (an extension to iptables that allows to match peer-to-peer traffic). About two weeks ago I tried to contact the author of this extension via the address that is mentioned on the project website, since I wanted to send in a patch, but with no success. At least I didn't receive a reply. Question: is the contact address that is mentioned on the project website still correct? If not, who should I contact? Bye, Mike From lartc@nospam.otaku42.de Mon May 10 06:19:02 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Mon, 10 May 2004 07:19:02 +0200 Subject: [LARTC] shaping domain names(www.xyz.com) In-Reply-To: <200405082045.01689.stef.coene@docum.org> References: <1083934416.409b86d04f7df@smwp01.maa.sify.net> <200405072014.53623.stef.coene@docum.org> <409C878A.4060008@otaku42.de> <200405082045.01689.stef.coene@docum.org> Message-ID: <409F10C6.4090301@otaku42.de> Hi. Stef Coene wrote: >>But tc sees the fwmark value that iptables has attached to a packet, >>right? Hence the idea to accomplish the "destination host distinction" >>with iptables-rules, setting fwmark accordingly and let tc decide on the >>different fwmark values. > But when do you see the hostname? In the dns request and maybe in the http > request. For all other packets only the ip address is known. The http requests surely will contain the hostname, at least in those scenarios where a http-server is contacted that serves more than one (sub)domain (*). So, at least the first packet of an established http connection will contain a "Host:"-line, which allows to mark that packet accordingly. Every following packet that belongs to the same connection can be handled with connection tracking, I think. (*) There is a rare chance that no "Host: "-line is in the http-request, but most probably these requests won't be a problem regarding the necessity of controling their used bandwidth, since the client won't be able to make use of all services of the server. So, if the solution doesn't match these rare situations, it won't hurt, I suppose. Well, I have to admit that I'm no iptables/tc-pro, so the idea I described could be wrong. Also: > Rereading the original post, I think he has an other problem. Possibly. But maybe still another one than you described: he could be the admin of the subnet the described users sit in, or the admin of the mentioned server(s). Depending on this "point of view" different solutions could apply. It would be good if the original poster could clarify this aspect :) Bye, Mike From Andreas.Klauer@metamorpher.de Mon May 10 09:53:51 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Mon, 10 May 2004 10:53:51 +0200 Subject: [LARTC] Contact for iptables-extension "ipp2p"? In-Reply-To: <409F11C5.2020203@otaku42.de> References: <409F11C5.2020203@otaku42.de> Message-ID: <200405101053.51787.Andreas.Klauer@metamorpher.de> Am Monday 10 May 2004 07:23 schrieb Michael Renzmann: > I remember someone in here was at least affiliated with the above > mentioned ipp2p-project (an extension to iptables that allows to match > peer-to-peer traffic). I added (experimental) support for IPP2P recently to my Fair NAT script. However, I also found two other projects which are pretty much capable of the same thing: iptables-p2p and l7-filter (both on Sourceforge). However, I haven't had the time for a closer look yet, so I don't know if they are any good. > Question: is the contact address that is mentioned on the project > website still correct? If not, who should I contact? No idea - but not everyone reads his/her mail every day, so you probably should be more patient. Two weeks is not much time, especially if the author has to review a patch you wrote. I file some bug reports here and there (which should be read by more than one person only) and even there it sometimes takes months until I get a reply. Andreas From lartc@nospam.otaku42.de Mon May 10 11:04:14 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Mon, 10 May 2004 12:04:14 +0200 Subject: [LARTC] Contact for iptables-extension "ipp2p"? In-Reply-To: <200405101053.51787.Andreas.Klauer@metamorpher.de> References: <409F11C5.2020203@otaku42.de> <200405101053.51787.Andreas.Klauer@metamorpher.de> Message-ID: <409F539E.20801@otaku42.de> Hi Andreas. Andreas Klauer wrote: > However, I also found two other projects which are pretty much capable of > the same thing: iptables-p2p and l7-filter (both on Sourceforge). However, > I haven't had the time for a closer look yet, so I don't know if they are > any good. I also found them before choosing ipp2p. But l7-filter is for kernel 2.6 only, and iptables-p2p seemed to be idle. So I decided to use ipp2p. >>Question: is the contact address that is mentioned on the project >>website still correct? If not, who should I contact? > No idea - but not everyone reads his/her mail every day, so you probably > should be more patient. Two weeks is not much time, especially if the > author has to review a patch you wrote. I file some bug reports here and > there (which should be read by more than one person only) and even there > it sometimes takes months until I get a reply. I know that people might be quite busy - I have the same problem. I was just wondering if I took the wrong e-mail address, since answers to questions regarding ipp2p here on the list have been answered very quickly as far as I remember. Well, didn't meant to cause any trouble - just been curious. :) Bye, Mike From spousta@brn.czn.cz Mon May 10 11:10:48 2004 From: spousta@brn.czn.cz (Patrick Spousta) Date: Mon, 10 May 2004 12:10:48 +0200 Subject: [LARTC] Packet marking for ingress shapping and NET Message-ID: <409F5528.2070201@brn.czn.cz> Hi, I have typical situation, local LAN with private addresses, translated via NAT to internet. I need to shape ingress traffic (from internet to local LAN) in several HTB queues accorting to destination (private not public) IP. So I need mark packets to divide them to corresponding queue. According to http://www.docum.org/stef.coene/qos/kptd/ I thing I have only one way how to do it, because MARK in PREROUTING is before (de)NAT PREROUTING (de)NAT V FORWARD marking V FORWARD put to IMQ V HTB shapping V routing decision V output interface It has a small problem. After PREROUTING some packets are routed to INPUT (packets intended for this machine for local processes) Does exists solution how to NAT and MARK in PREROUTING, but in this order? Patrick From Andreas.Klauer@metamorpher.de Mon May 10 11:59:24 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Mon, 10 May 2004 12:59:24 +0200 Subject: [LARTC] Packet marking for ingress shapping and NET In-Reply-To: <409F5528.2070201@brn.czn.cz> References: <409F5528.2070201@brn.czn.cz> Message-ID: <200405101259.24230.Andreas.Klauer@metamorpher.de> Am Monday 10 May 2004 12:10 schrieb Patrick Spousta: > So I need mark packets to divide them to corresponding queue. That's all right so far. But the qdisc that shapes incoming traffic usually sits on your LAN device. > It has a small problem. After PREROUTING some packets are routed to > INPUT (packets intended for this machine for local processes) > > Does exists solution how to NAT and MARK in PREROUTING, but in this > order? I'm not sure if I understand what you want to do. Why do you want to mark INPUT packets? There is no qdisc/class to put them in. As for shaping incoming traffic that doesn't get forwarded to the LAN, I haven't found a proper solution to do that yet. So all I can do is make sure that the router doesn't produce any traffic (e.g. don't put a Webserver or similar services on it). Andreas From netadmin@neosoft-tec.com Mon May 10 12:10:13 2004 From: netadmin@neosoft-tec.com (Netadmin) Date: Mon, 10 May 2004 16:40:13 +0530 Subject: [LARTC] UNSUBRCIBE Message-ID: <009801c4367f$5dea01e0$4b00a8c0@pc75> This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C436AD.777EFE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable UNSUBRCIBE ------=_NextPart_000_0095_01C436AD.777EFE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

UNSUBRCIBE

------=_NextPart_000_0095_01C436AD.777EFE70-- From spousta@brn.czn.cz Mon May 10 13:31:10 2004 From: spousta@brn.czn.cz (Patrick Spousta) Date: Mon, 10 May 2004 14:31:10 +0200 Subject: [LARTC] Packet marking for ingress shapping and NAT In-Reply-To: <200405101259.24230.Andreas.Klauer@metamorpher.de> References: <409F5528.2070201@brn.czn.cz> <200405101259.24230.Andreas.Klauer@metamorpher.de> Message-ID: <409F760E.6050806@brn.czn.cz> Andreas Klauer wrote: > Am Monday 10 May 2004 12:10 schrieb Patrick Spousta: > >>So I need mark packets to divide them to corresponding queue. > > > That's all right so far. But the qdisc that shapes incoming traffic usually > sits on your LAN device. I think you are wrong. Shapping can sits on all interfaces, physical and logical. IMQ is logical interface. > > >>It has a small problem. After PREROUTING some packets are routed to >>INPUT (packets intended for this machine for local processes) >> >>Does exists solution how to NAT and MARK in PREROUTING, but in this >>order? > > > I'm not sure if I understand what you want to do. Why do you want to mark My linux box has 1 WAN interface (to ISP with public IP address) and 3 LAN interfaces (with private IP addresses). Only way how to shape incoming traffic is use IMG device because shapping is provided on egress. I understood that packet 'path' looks like this eth0 -> kernel -> IMQ -> kernel -> ethX ^^^ here is 'egress' where I can do shapping. But I need divide traffic to the corresponding queues according to real destination IP. Maybe I don't need marking, I can only use tc filter, but it must be done in place where packet has real destination IP, ie. behind (de)NAT. To IMQ 'interface' I put packets via iptables. Ideal in PREROUTING chain, but I think I can use only 'mange' table and that is before 'nat' :-( So now I'm using FORWARD chain but local traffic is going outside of shapping path > INPUT packets? There is no qdisc/class to put them in. As for shaping > incoming traffic that doesn't get forwarded to the LAN, I haven't found a > proper solution to do that yet. So all I can do is make sure that the > router doesn't produce any traffic (e.g. don't put a Webserver or similar > services on it). But it isn't goor solution :-( Patrick > > Andreas > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From andy.furniss@dsl.pipex.com Mon May 10 13:06:58 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 10 May 2004 13:06:58 +0100 Subject: [LARTC] Packet marking for ingress shapping and NET In-Reply-To: <409F5528.2070201@brn.czn.cz> References: <409F5528.2070201@brn.czn.cz> Message-ID: <409F7062.1070401@dsl.pipex.com> Patrick Spousta wrote: > Hi, > I have typical situation, local LAN with private addresses, translated > via NAT to internet. I need to shape ingress traffic (from internet to > local LAN) in several HTB queues accorting to destination (private not > public) IP. So I need mark packets to divide them to corresponding > queue. According to http://www.docum.org/stef.coene/qos/kptd/ I thing I > have only one way how to do it, because MARK in PREROUTING is before > (de)NAT > > PREROUTING (de)NAT > V > FORWARD marking > V > FORWARD put to IMQ > V > HTB shapping > V > routing decision > V > output interface > > It has a small problem. After PREROUTING some packets are routed to > INPUT (packets intended for this machine for local processes) > > Does exists solution how to NAT and MARK in PREROUTING, but in this order? > If you really need to shape for local and forwarded on ingress then you use IMQ + the IMQ NAT patch and use u32 to filter on dst IP (if you are masquerading a dynamic IP mark LAN traffic and use default for local). If the traffic to local is not "bulk" ie just dns or ntp etc. then it would be less trouble to ignore it and just shape on your LAN facing interface marking on dst in postrouting or using u32 on dst - both should work, you may want to exclude traffic from server to LAN. Andy. From spousta@brn.czn.cz Mon May 10 13:35:59 2004 From: spousta@brn.czn.cz (Patrick Spousta) Date: Mon, 10 May 2004 14:35:59 +0200 Subject: [LARTC] Packet marking for ingress shapping and NET In-Reply-To: <409F7062.1070401@dsl.pipex.com> References: <409F5528.2070201@brn.czn.cz> <409F7062.1070401@dsl.pipex.com> Message-ID: <409F772F.7010905@brn.czn.cz> Hi Andy Furniss wrote: >> Does exists solution how to NAT and MARK in PREROUTING, but in this >> order? >> > > If you really need to shape for local and forwarded on ingress then you > use IMQ + the IMQ NAT patch and use u32 to filter on dst IP (if you are > masquerading a dynamic IP mark LAN traffic and use default for local). It sounds good, but can you be more conrete? > > If the traffic to local is not "bulk" ie just dns or ntp etc. then it Sometimes it is 'bulk' - FTP etc. > would be less trouble to ignore it and just shape on your LAN facing Sorry, I forgot write that I have 3 LAN interfaces, so IMQ is only way how to do it. Thanks Patrick > interface marking on dst in postrouting or using u32 on dst - both > should work, you may want to exclude traffic from server to LAN. > > Andy. > From andy.furniss@dsl.pipex.com Mon May 10 14:48:51 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 10 May 2004 14:48:51 +0100 Subject: [LARTC] Packet marking for ingress shapping and NET In-Reply-To: <409F772F.7010905@brn.czn.cz> References: <409F5528.2070201@brn.czn.cz> <409F7062.1070401@dsl.pipex.com> <409F772F.7010905@brn.czn.cz> Message-ID: <409F8843.1020503@dsl.pipex.com> Patrick Spousta wrote: > Hi > > Andy Furniss wrote: > >>> Does exists solution how to NAT and MARK in PREROUTING, but in this >>> order? >>> >> >> If you really need to shape for local and forwarded on ingress then >> you use IMQ + the IMQ NAT patch and use u32 to filter on dst IP (if >> you are masquerading a dynamic IP mark LAN traffic and use default for >> local). > > > It sounds good, but can you be more conrete? Using IMQ generally or a script? - mine is pretty lame, unfinished and needs netfilter patches, though I suppose it could give an indication of what to do - I am still learning HTB myself, but have got sidetracked at the moment playing with esfq. There is a new imq website www.linuximq.net from which you should be able to get imq working for whatever kernel you use. I don't know if they include the NAT patch yet - but it's only a couple of lines and should apply OK. If you happen to use 2.4.24 I can give urls for the patches I use. Andy. From pturley@rocksteady.com Mon May 10 17:47:55 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 10 May 2004 11:47:55 -0500 Subject: [LARTC] MARK target question In-Reply-To: <20040509000035.GA15048@rabbit.us> References: <20040509000035.GA15048@rabbit.us> Message-ID: <409FB23B.1080703@rocksteady.com> Peter Rabbitson wrote: > This is more of a NF question but it is tightly related to LARTC as well. In the following example: > > -t mangle -A PREROUTING -i eth0 -j MARK 0x1 > .... > -t mangle -A INPUT -i eth0 -j MARK 0x2 > > Since MARK is a non-terminatring target, what would be the resulting mark on a packet comming from the outside and > destined for a local process? The mark would be 0 until the packet hits the first rule. After that, it would be 1 through the remainder of the PREROUTING chains. After routing, it would pass to the INPUT chains where it would change to 2 when it hits the second rule and would remain 2 through the rest of the INPUT chains. From pturley@rocksteady.com Mon May 10 17:47:55 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 10 May 2004 11:47:55 -0500 Subject: [LARTC] MARK target question In-Reply-To: <20040509000035.GA15048@rabbit.us> References: <20040509000035.GA15048@rabbit.us> Message-ID: <409FB23B.1080703@rocksteady.com> Peter Rabbitson wrote: > This is more of a NF question but it is tightly related to LARTC as well. In the following example: > > -t mangle -A PREROUTING -i eth0 -j MARK 0x1 > .... > -t mangle -A INPUT -i eth0 -j MARK 0x2 > > Since MARK is a non-terminatring target, what would be the resulting mark on a packet comming from the outside and > destined for a local process? The mark would be 0 until the packet hits the first rule. After that, it would be 1 through the remainder of the PREROUTING chains. After routing, it would pass to the INPUT chains where it would change to 2 when it hits the second rule and would remain 2 through the rest of the INPUT chains. From pturley@rocksteady.com Mon May 10 17:47:55 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 10 May 2004 11:47:55 -0500 Subject: [LARTC] MARK target question In-Reply-To: <20040509000035.GA15048@rabbit.us> References: <20040509000035.GA15048@rabbit.us> Message-ID: <409FB23B.1080703@rocksteady.com> Peter Rabbitson wrote: > This is more of a NF question but it is tightly related to LARTC as well. In the following example: > > -t mangle -A PREROUTING -i eth0 -j MARK 0x1 > .... > -t mangle -A INPUT -i eth0 -j MARK 0x2 > > Since MARK is a non-terminatring target, what would be the resulting mark on a packet comming from the outside and > destined for a local process? The mark would be 0 until the packet hits the first rule. After that, it would be 1 through the remainder of the PREROUTING chains. After routing, it would pass to the INPUT chains where it would change to 2 when it hits the second rule and would remain 2 through the rest of the INPUT chains. From gentoo-user@lists.gentoo.org Mon May 10 22:51:01 2004 From: gentoo-user@lists.gentoo.org (raptor) Date: Tue, 11 May 2004 00:51:01 +0300 Subject: [LARTC] [gentoo-user] is 2.6 server ready... Message-ID: <20040511005101.3cfcbf66@vr> hi, I still dont use 2.6 and udev ... is it ready for use by servers... I'm happy with my current 2.4 servers...and I want to know will using 2.6&udev will give me some benefits on network (tcp/ip) oriented server, I mean : QoS (tc, HTB), ip route, iptables server... most of the reviews of 2.6 expose advances in VM,FS etc... at least when comparing the speed and scalability ... BUT I'm interested in its NETWORK PEROFORMANCE .. can u give me some clue is it worthfull to step to 2.6.. Also is there any quircks . Some links to tests . tia -- gentoo-user@gentoo.org mailing list From pturley@rocksteady.com Mon May 10 17:47:55 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 10 May 2004 11:47:55 -0500 Subject: [LARTC] MARK target question In-Reply-To: <20040509000035.GA15048@rabbit.us> References: <20040509000035.GA15048@rabbit.us> Message-ID: <409FB23B.1080703@rocksteady.com> Peter Rabbitson wrote: > This is more of a NF question but it is tightly related to LARTC as well. In the following example: > > -t mangle -A PREROUTING -i eth0 -j MARK 0x1 > .... > -t mangle -A INPUT -i eth0 -j MARK 0x2 > > Since MARK is a non-terminatring target, what would be the resulting mark on a packet comming from the outside and > destined for a local process? The mark would be 0 until the packet hits the first rule. After that, it would be 1 through the remainder of the PREROUTING chains. After routing, it would pass to the INPUT chains where it would change to 2 when it hits the second rule and would remain 2 through the rest of the INPUT chains. From raptor@tvskat.net Mon May 10 22:51:01 2004 From: raptor@tvskat.net (raptor) Date: Tue, 11 May 2004 00:51:01 +0300 Subject: [LARTC] is 2.6 server ready... Message-ID: <20040511005101.3cfcbf66@vr> hi, I still dont use 2.6 and udev ... is it ready for use by servers... I'm happy with my current 2.4 servers...and I want to know will using 2.6&udev will give me some benefits on network (tcp/ip) oriented server, I mean : QoS (tc, HTB), ip route, iptables server... most of the reviews of 2.6 expose advances in VM,FS etc... at least when comparing the speed and scalability ... BUT I'm interested in its NETWORK PEROFORMANCE .. can u give me some clue is it worthfull to step to 2.6.. Also is there any quircks . Some links to tests . tia From pturley@rocksteady.com Mon May 10 17:47:55 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 10 May 2004 11:47:55 -0500 Subject: [LARTC] MARK target question In-Reply-To: <20040509000035.GA15048@rabbit.us> References: <20040509000035.GA15048@rabbit.us> Message-ID: <409FB23B.1080703@rocksteady.com> Peter Rabbitson wrote: > This is more of a NF question but it is tightly related to LARTC as well. In the following example: > > -t mangle -A PREROUTING -i eth0 -j MARK 0x1 > .... > -t mangle -A INPUT -i eth0 -j MARK 0x2 > > Since MARK is a non-terminatring target, what would be the resulting mark on a packet comming from the outside and > destined for a local process? The mark would be 0 until the packet hits the first rule. After that, it would be 1 through the remainder of the PREROUTING chains. After routing, it would pass to the INPUT chains where it would change to 2 when it hits the second rule and would remain 2 through the rest of the INPUT chains. From raptor@tvskat.net Mon May 10 23:22:22 2004 From: raptor@tvskat.net (raptor) Date: Tue, 11 May 2004 01:22:22 +0300 Subject: [LARTC] ip_conntrack_ftp Message-ID: <20040511012222.6c12892f@vr> As read here : http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html modprobe ip_conntrack_ftp would give me the ability to use active ftp if I have (pseudo/simplified code) iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -j DROP but I cant use active ftp, WHAT IS WRONG.. eth0 is the internal interface.. From andy.furniss@dsl.pipex.com Mon May 10 21:09:17 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 10 May 2004 21:09:17 +0100 Subject: [LARTC] Packet marking for ingress shapping and NET In-Reply-To: <409FDACF.5020601@int.nextra.cz> References: <409F5528.2070201@brn.czn.cz> <409F7062.1070401@dsl.pipex.com> <409F772F.7010905@brn.czn.cz> <409F8843.1020503@dsl.pipex.com> <409FDACF.5020601@int.nextra.cz> Message-ID: <409FE16D.7010909@dsl.pipex.com> Patrick Spousta wrote: > It looks working fine :-) I never found any details about IMQ and NAT > patch, it looks that packet processing in kernel has path > > | PREROUTING chain | > input interface -> contrack -> mangle -> nat -> imq So which IMQ did you use - did you need to patch for NAT (there are different versions about) > ESFQ works fine, but only for ingress shapping over imq and NAT with > destination hash (== download on private IPs). I'm trying to setup ESFQ > on egress shaping for traffic from private to public IPs with source > hash (upload from private) but qdisc sits after NAT, ie. packets source > addresses are always the same public IP of external (wan) interface :-( > > I try to use imq for egress shapping (on POSTROUTING chain), may it helps I don't think IMQ will help - but you can mark local src in postrouting mangle OK. If you really want to use esfq, someone posted a patch on here a while back which made esfq hash on fwmark. Andy. From andy.furniss@dsl.pipex.com Mon May 10 21:37:27 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 10 May 2004 21:37:27 +0100 Subject: [LARTC] ip_conntrack_ftp In-Reply-To: <20040511012222.6c12892f@vr> References: <20040511012222.6c12892f@vr> Message-ID: <409FE807.1060308@dsl.pipex.com> raptor wrote: > As read here : > http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html > > modprobe ip_conntrack_ftp > would give me the ability to use active ftp if I have (pseudo/simplified code) > > iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT > iptables -A FORWARD -j DROP > > but I cant use active ftp, WHAT IS WRONG.. eth0 is the internal interface.. > If you are NATing use ip_nat_ftp aswell. Not sure that that firewall rule is OK - but then I don't know what else you have. My firewall is a direct copy and paste from one of rustys guides - ppp0 is my external interface - ## Create chain which blocks new connections, except if coming from inside. iptables -N block iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT iptables -A block -j DROP ## Jump to that chain from INPUT and FORWARD chains. iptables -A INPUT -j block iptables -A FORWARD -j block Andy. From spousta@brn.czn.cz Tue May 11 05:25:00 2004 From: spousta@brn.czn.cz (Patrick Spousta) Date: Tue, 11 May 2004 06:25:00 +0200 Subject: [LARTC] Packet marking for ingress shapping and NAT In-Reply-To: <409FE16D.7010909@dsl.pipex.com> References: <409F5528.2070201@brn.czn.cz> <409F7062.1070401@dsl.pipex.com> <409F772F.7010905@brn.czn.cz> <409F8843.1020503@dsl.pipex.com> <409FDACF.5020601@int.nextra.cz> <409FE16D.7010909@dsl.pipex.com> Message-ID: <40A0559C.3060408@brn.czn.cz> Andy Furniss wrote: > Patrick Spousta wrote: > >> It looks working fine :-) I never found any details about IMQ and NAT >> patch, it looks that packet processing in kernel has path >> >> | PREROUTING chain | >> input interface -> contrack -> mangle -> nat -> imq > > > So which IMQ did you use - did you need to patch for NAT (there are > different versions about) Now I'm using patches from http://www.digriz.org.uk/jdg-qos-script/ (latest version which contains patches for IMQ, IMQ+NAT, ESFQ, IPP2P, CONNMARK, also recompiledtc andlibrarie for iptables, nice package) on kernel 2.4.25. It works good. > >> ESFQ works fine, but only for ingress shapping over imq and NAT with >> destination hash (== download on private IPs). I'm trying to setup >> ESFQ on egress shaping for traffic from private to public IPs with >> source hash (upload from private) but qdisc sits after NAT, ie. >> packets source addresses are always the same public IP of external >> (wan) interface :-( >> >> I try to use imq for egress shapping (on POSTROUTING chain), may it helps > > > I don't think IMQ will help - but you can mark local src in postrouting Do you mean manualy configured marking for many, many IP addresses? I think it isn't right way :-( I like ESFQ for it's source or destination hash because I don't need to setup any filters/markers for those IPs, ESFQ creats it's own queues for each IP. In POSTROUTING chain it normaly look like this ... -> mangle -> nat -> imq -> (output interface) I don't understand C language so I don't understand IMQ+NAT patch, but I'll try to use imq for egress shapping. Maybe the patch is working identically on PRE i POST chains. Patrick > mangle OK. If you really want to use esfq, someone posted a patch on > here a while back which made esfq hash on fwmark. > > Andy. > > From raptor@tvskat.net Tue May 11 08:09:46 2004 From: raptor@tvskat.net (raptor) Date: Tue, 11 May 2004 10:09:46 +0300 Subject: [LARTC] ip_conntrack_ftp In-Reply-To: <409FE807.1060308@dsl.pipex.com> References: <20040511012222.6c12892f@vr> <409FE807.1060308@dsl.pipex.com> Message-ID: <20040511100946.171bd354@bugs> yep my config is very similar i.e. : iptables -N block iptables -A block -i $ifInt0 -j ACCEPT iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A block -j DROP iptables -A INPUT -i $ifWan0 -j services iptables -A FORWARD -i $ifWan0 -j services iptables -A INPUT -j block iptables -A FORWARD -j block I added also this (do I really need it in my config I'm allowing everything from inside anyway): > iptables -A block -m state --state NEW -i ! $ifWan0 -j ACCEPT after ESTABLISHED,RELATED but still can do active FTP "services" is for giving access to wellknown services... I'm not using NAT On Mon, 10 May 2004 21:37:27 +0100 Andy Furniss wrote: > raptor wrote: > > As read here : > > http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html > > > > modprobe ip_conntrack_ftp > > would give me the ability to use active ftp if I have (pseudo/simplified code) > > > > iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT > > iptables -A FORWARD -j DROP > > > > but I cant use active ftp, WHAT IS WRONG.. eth0 is the internal interface.. > > > > If you are NATing use ip_nat_ftp aswell. > > Not sure that that firewall rule is OK - but then I don't know what else > you have. > > My firewall is a direct copy and paste from one of rustys guides - ppp0 > is my external interface - > > ## Create chain which blocks new connections, except if coming from inside. > > iptables -N block > iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT > iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT > iptables -A block -j DROP > > ## Jump to that chain from INPUT and FORWARD chains. > iptables -A INPUT -j block > iptables -A FORWARD -j block > > Andy. > > From osama@wayout.net Tue May 11 12:04:50 2004 From: osama@wayout.net (Osama Abu Elsorour) Date: Tue, 11 May 2004 14:04:50 +0300 Subject: [LARTC] reclassify option on policing Message-ID: <00c701c43747$c8569660$0a00000a@juptop> This is a multi-part message in MIME format. ------=_NextPart_000_00C8_01C43760.EDA3CE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, What exactly is the use of the "reclassify" option in the policing options of tc filters? According to LARTC: " reclassify Most often comes down to reclassification to Best Effort. This is the default action. " I don't quite get the meaning of that. It could mean to let other filters handle it, but that is exactly the "continue" option. Could someone explain how this option is used? Thanks ------=_NextPart_000_00C8_01C43760.EDA3CE60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

What exactly is the use of the “reclassify” option in the policing options of tc filters?

According to LARTC: =

 

“

reclassify

Most often comes down to reclassification to = Best Effort. This is the default action.

“

 

I don’t quite get the meaning of = that.

It could mean to let other filters handle it, = but that is exactly the "continue" option.

 

Could someone explain how this option is = used?

 

Thanks

 

------=_NextPart_000_00C8_01C43760.EDA3CE60-- From andy.furniss@dsl.pipex.com Tue May 11 14:13:04 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Tue, 11 May 2004 14:13:04 +0100 Subject: [LARTC] Packet marking for ingress shapping and NAT In-Reply-To: <40A0559C.3060408@brn.czn.cz> References: <409F5528.2070201@brn.czn.cz> <409F7062.1070401@dsl.pipex.com> <409F772F.7010905@brn.czn.cz> <409F8843.1020503@dsl.pipex.com> <409FDACF.5020601@int.nextra.cz> <409FE16D.7010909@dsl.pipex.com> <40A0559C.3060408@brn.czn.cz> Message-ID: <40A0D160.6040406@dsl.pipex.com> Patrick Spousta wrote: >> I don't think IMQ will help - but you can mark local src in postrouting > > > Do you mean manualy configured marking for many, many IP addresses? I > think it isn't right way :-( I like ESFQ for it's source or destination > hash because I don't need to setup any filters/markers for those IPs, > ESFQ creats it's own queues for each IP. Yes I agree - not nice for your setup, though personally the thing I don't like about using esfq on src/dst is you loose per tcp fairness - it was less than a year ago that I was on 56K and anyone with high latency downloading from you will get their already small bandwidth squeezed out by the low latency downloaders. Maybe it's less noticable/of an issue for your big setup anyway. > > In POSTROUTING chain it normaly look like this > > ... -> mangle -> nat -> imq -> (output interface) > > I don't understand C language so I don't understand IMQ+NAT patch, but > I'll try to use imq for egress shapping. Maybe the patch is working > identically on PRE i POST chains. I only just started getting into C myself - (used motorolla 68000 assembly years ago on an atari ST - these "high level" languages are much trickier :-) ). I can see that the patch is trivial and needs an understanding of netfilter hooks more than C. I just tested with u32 to double confirm what I knew really - the patch only affects prerouting hooks. Then knowing nothing about netfilter decided to have a go at changing the egress hook - it appears to be working as expected. One caveat - some people have reported stability problems using postrouting IMQ, probably to do with dropping locally generated traffic. I and others don't, but then I don't leave my gateway PC up that long. Grepping my logs : Sent 3744702472 bytes 5539814 pkts (dropped 354902, overlimits 11722774) is the most I can see (most of the drops are locally generated packets ie. bittorrent running on the shaping PC). If you wan't to give my blind and possibly stupid hack a go you just need to change near the top of drivers/net/imq.c so it looks like - static struct nf_hook_ops imq_egress_ipv4 = { { NULL, NULL}, imq_nf_hook, PF_INET, NF_IP_POST_ROUTING, NF_IP_PRI_NAT_SRC - 1 }; Rather than - static struct nf_hook_ops imq_egress_ipv4 = { { NULL, NULL}, imq_nf_hook, PF_INET, NF_IP_POST_ROUTING, NF_IP_PRI_LAST }; You could do the same for the egress ipv6 bits below it aswell. If you still have your source tree intact and use modules cd to top dir in kernel tree do make SUBDIRS=drivers/net modules which should build a new imq.o in drivers/net Backup /lib/modules/[your version]/kernel/drivers/net/imq.o and replace with new one. Take down shaping and modprobe -r imq (check it's gone with lsmod) and restart shaper. It's a bit of a pain that imq is unstable for some anyway - you won't know whoose fault it is if/when it crashes :-) Andy. From andy.furniss@dsl.pipex.com Wed May 12 08:53:39 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 12 May 2004 08:53:39 +0100 Subject: [LARTC] ip_conntrack_ftp In-Reply-To: <20040511100946.171bd354@bugs> References: <20040511012222.6c12892f@vr> <409FE807.1060308@dsl.pipex.com> <20040511100946.171bd354@bugs> Message-ID: <40A1D803.8050900@dsl.pipex.com> raptor wrote: > yep my config is very similar i.e. : > > iptables -N block > iptables -A block -i $ifInt0 -j ACCEPT > iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT > iptables -A block -j DROP > > > iptables -A INPUT -i $ifWan0 -j services > iptables -A FORWARD -i $ifWan0 -j services > iptables -A INPUT -j block > iptables -A FORWARD -j block > > I added also this (do I really need it in my config I'm allowing everything from inside anyway): > >>iptables -A block -m state --state NEW -i ! $ifWan0 -j ACCEPT > > > after ESTABLISHED,RELATED but still can do active FTP > > "services" is for giving access to wellknown services... > I'm not using NAT I am not sure what's wrong. Are you running an FTP server or just trying to access one on the internet from behind the firewall ? Andy. From reza@mra.co.id Wed May 12 08:25:08 2004 From: reza@mra.co.id (Muhammad Reza) Date: Wed, 12 May 2004 14:25:08 +0700 Subject: [LARTC] Multipath Connection problem on RH-8.0 Message-ID: <40A1D154.5080508@mra.co.id> This is a multi-part message in MIME format. --------------020300030003000706010409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear List. I try to build multipath connection w/ load balance to internet with two different gateway; My system is RH-8.0 with iproute-2.4.7-7.90.1.rpm and Kernel-2.4.26 (patching with Julian A. patch),and follow guide from http://www.linuxvirtualserver.org/~julian/nano.txt, The problem is; when i try to connect to Internet form gateway machine it;s success , but only one interface is active, no load balancing at all , This is my default table #ip r ls table DEF default proto static nexthop via 172.16.0.1 dev eth0 weight 256 dead onlink pervasive nexthop via 192.168.0.1 dev eth1 weight 1 I search the list about this error, and found that i shall use the upgrade version of iproute2, and i compile that too. but with same config, and new iproute2 i can't connect to internet now. please be advice, what wrong with my config (attach), and what version of linux should work ? regrads --------------020300030003000706010409 Content-Type: text/plain; name="script" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="script" ip link set lo up ip addr add 127.0.0.1/8 brd + dev lo ip link set eth2 up ip addr add 10.10.10.1/24 brd + dev eth2 ip rule add prio 50 table main ip route del default table main ip link set dev eth0 ip addr flush dev eth0 ip addr add 172.16.0.232/24 brd 172.16.0.255 dev eth0 ip link set dev eth1 up ip addr flush dev eth1 ip addr add 192.168.0.2/30 brd 192.168.0.3 dev eth1 ip rule add prio 100 from 172.16.0.0/24 table MRA ip route add default via 172.16.0.1 dev eth0 src 172.16.0.232 proto static table MRA ip route append prohibit default table MRA metric 1 proto static ip rule add prio 200 from 192.168.0.2/30 table ADSL ip route add default via 192.168.0.1 dev eth1 src 192.168.0.2 proto static table ADSL ip route append prohibit default table ADSL metric 1 proto static ip rule add prio 222 table DEF ip route add default table DEF proto static nexthop via 172.16.0.1 dev eth0 nexthop via 192.168.0.1 dev eth1 --------------020300030003000706010409-- From Andreas.Klauer@metamorpher.de Wed May 12 12:57:10 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Wed, 12 May 2004 13:57:10 +0200 Subject: [LARTC] ingress policy filter for variable rate Message-ID: <200405121357.10388.Andreas.Klauer@metamorpher.de> Hi, I have a question about policy filters. All I want is incoming traffic being restricted to a specific rate. At the moment, I get way lower rates than specified. So far, I did use a filter much like Wondershaper does: 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 However, it seems that this doesn't work well for all rates. After a change of the DOWNLINK value, I found that this filter dropped far too many packets (resulting rate was somewhat 1/10 of DOWNLINK). It looks like this has something to do with the 'burst' parameter. LARTC Howto says: "If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket." So I thought, hum, maybe 10k burst is too small. However, when I raised the value to 20, 30, 40k, the rate got even worse. Since I don't have any real idea what this burst parameter actually does, is here anyone with the experience which values are best to use? Since it seems to depend on the rate used, I'd prefer some kind of formula that calculates the ideal burst/buffer/maxburst (what's the difference?) value depending on $DOWNLINK. For the time being, I just removed the ingress altogether, since I already have HTB shaping in both directions (on ppp0 for outgoing, and eth1 for incoming). Does ingress even make sense when there's already HTB on the LAN device to do the shaping? I thought it may be a good thing since it considers local incoming traffic, too. TIA, Andreas From raptor@tvskat.net Wed May 12 13:29:44 2004 From: raptor@tvskat.net (raptor) Date: Wed, 12 May 2004 15:29:44 +0300 Subject: [LARTC] ip_conntrack_ftp In-Reply-To: <40A1D803.8050900@dsl.pipex.com> References: <20040511012222.6c12892f@vr> <409FE807.1060308@dsl.pipex.com> <20040511100946.171bd354@bugs> <40A1D803.8050900@dsl.pipex.com> Message-ID: <20040512152944.2c9dab4e@bugs> tryng to access ftp servers from inside... > raptor wrote: > > yep my config is very similar i.e. : > > > > iptables -N block > > iptables -A block -i $ifInt0 -j ACCEPT > > iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT > > iptables -A block -j DROP > > > > > > iptables -A INPUT -i $ifWan0 -j services > > iptables -A FORWARD -i $ifWan0 -j services > > iptables -A INPUT -j block > > iptables -A FORWARD -j block > > > > I added also this (do I really need it in my config I'm allowing everything from inside anyway): > > > >>iptables -A block -m state --state NEW -i ! $ifWan0 -j ACCEPT > > > > > > after ESTABLISHED,RELATED but still can do active FTP > > > > "services" is for giving access to wellknown services... > > I'm not using NAT > > I am not sure what's wrong. > > Are you running an FTP server or just trying to access one on the > internet from behind the firewall ? > From oeschey@web.de Wed May 12 15:08:30 2004 From: oeschey@web.de (Lars Oeschey) Date: Wed, 12 May 2004 16:08:30 +0200 (CEST) Subject: [LARTC] Bandwith thinking error Message-ID: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> Hi, I found that I had some thinking error with the wshaper script. I assigned the bandwith of my DSL connection to it, but the machine where it runs is normally connected to the LAN with 100Mbit behind a separate Hardware-Router.Obviously, the complete connection of the machine was slowed down to 384k because I told it so.I guess, since wshaper takes only one card as argument, I can't use that script for shaping, as I just want to slow done specific services on that card, but I can't enter the correct value for Bandwith. So what is the correct way to go? I think I need two paths, one with 100MBit for the local network (where actually there'll happen no shaping) and another path with 384k where I need to shape Internet services after priority... Lars -- visit the C.O.R.E. http://www.the-core.net From Andreas.Klauer@metamorpher.de Wed May 12 16:28:54 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Wed, 12 May 2004 17:28:54 +0200 Subject: [LARTC] Bandwith thinking error In-Reply-To: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> Message-ID: <200405121728.54385.Andreas.Klauer@metamorpher.de> Am Wednesday 12 May 2004 16:08 schrieb Lars Oeschey: > I found that I had some thinking error with the wshaper script. I > assigned the bandwith of my DSL connection to it, but the machine where > it runs is normally connected to the LAN with 100Mbit behind a separate > Hardware-Router. WShaper reduces the complete bandwidth of a device to a given rate, so it's to be attached directly to the internet device. So if you use the same device for communicating with the router and with other machines in the LAN, there is a problem. > So what is the correct way to go? You have the same problem if you attach HTB filters (for incoming NATed bandwidth) to the LAN device. It can be solved by creating one fat parent class which has the full LAN rates. This fat class gets two children: a DSL class which gets the DSL rates and a LAN class which gets (LAN minus DSL) rate. The DSL class then gets further children for DSL traffic classification for example on a per user or interactive/http/protocol basis. You have to add your filters then to the DSL class instead of parent qdisc, and a filter in the parent qdisc that puts packets that go to the Router IP into the DSL class. Or modify your filters so that they only apply to Router packets. Especially if you're using ingress, you have to modify the policy filters so that they only apply to packets coming from the router. As a simplified ascii graphic: HTB qdisc | \--- HTB fat class (LAN rate) | \--- HTB DSL class (DSL rate; only packets to the router go here) \--- HTB LAN class (LAN-DSL rate; all other packets go here) A problem with this design would be if you have additional local traffic that goes to the router (e.g. a ssh session to the router that does not actually go to the internet). This would be classified as DSL traffic too. I don't know if filters can be designed in a way that they only match on gateway'ed traffic. Shaping this way won't work particularly well especially if there are other users in your LAN using the router. You should do the shaping directly on the router in any case. HTH Andreas From lpz@ornl.gov Wed May 12 17:36:28 2004 From: lpz@ornl.gov (Lawrence MacIntyre) Date: Wed, 12 May 2004 12:36:28 -0400 Subject: [LARTC] HFSC Message-ID: <40A2528C.3030306@ornl.gov> Hi: I am using a machine with the 2.4.26 kernel, and trying to compare the performance of the HTB qdisc with the HFSC one. I have the following simple script that allows me to have a video stream on port 1234 while it limits a ttcp UDP stream so that the video stream is unimpaired. #!/bin/bash tc qdisc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 htb rate 30mbit ceil 30mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 20mbit ceil 30mbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10mbit ceil 30mbit tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5 tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 1234 0xffff flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 5001 0xffff flowid 1:11 Now I would like to try H-FSC. I'm not sure exactly how to go about this. I thought that creating a ul class with two ls classes inside and then putting an rt class in one of the ls classes for the video might work, but I can't seem to get it to work. For example, #!/bin/bash /usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc /usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 30mbit d 0 m2 30mbit ls m1 30mbit d 0 m2 30mbit When the second command is executed, the machine simply drops all packets going through it. I would like to try the 2.6 kernel, but my machine has an Adaptec SCSI controller that has a broken driver for the 2.6 kernel. I don't understand why this statement causes the machine to drop all packets on the eth0 interface. -- Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group From ja@ssi.bg Wed May 12 21:31:49 2004 From: ja@ssi.bg (Julian Anastasov) Date: Wed, 12 May 2004 23:31:49 +0300 (EEST) Subject: [LARTC] Multipath Connection problem on RH-8.0 In-Reply-To: <40A1D154.5080508@mra.co.id> References: <40A1D154.5080508@mra.co.id> Message-ID: Hello, On Wed, 12 May 2004, Muhammad Reza wrote: > default proto static > nexthop via 172.16.0.1 dev eth0 weight 256 dead onlink pervasive > nexthop via 192.168.0.1 dev eth1 weight 1 > I search the list about this error, and found that i shall use the > upgrade version of iproute2, and i compile that too. > but with same config, and new iproute2 i can't connect to internet now. > please be advice, what wrong with my config (attach), and what version > of linux should work ? Can you check the example 'ip route get' commands and "2.4 Keeping them alive" from nano.txt. Make sure after upgrading iproute2 that your nexthops are not dead. Also, list you rules and routes and make sure they are valid, I see your commands but I do not know which of them are accepted from the kernel. Regards -- Julian Anastasov From mingching.tiew@redtone.com Thu May 13 03:53:28 2004 From: mingching.tiew@redtone.com (Ming-Ching Tiew) Date: Thu, 13 May 2004 10:53:28 +0800 Subject: [LARTC] Multiipath routing - can't ping links from LAN after default routes Message-ID: <009801c43895$77d81930$0100a8c0@newlife> I have a Linux with 3 LAN interfaces doing multipath NAT to two internet links via ADSL. The question I have is after I added the default route on each of the routing table, I can't ping the external interfaces of the Linux from the LAN ( pinging from the Linux itself is OK ). But pinging beyond the two external interfaces ( eg the default route ) is OK. I use symbolic names here :- # ip route add ${INSIDE_NETWORK} dev ${INSIDE_DEV} table first ip route add ${OUTSIDE_NETWORK} dev ${OUTSIDE_DEVICE} table first ip route add ${OUTSIDE_NETWORK2} dev ${OUTSIDE_DEVICE2} table first ip route add 127.0.0.0/8 dev lo table first # ip route add ${INSIDE_NETWORK} dev ${INSIDE_DEV} table second ip route add ${OUTSIDE_NETWORK} dev ${OUTSIDE_DEVICE} table second ip route add ${OUTSIDE_NETWORK2} dev ${OUTSIDE_DEVICE2} table second ip route add 127.0.0.0/8 dev lo table second # ip route add ${OUTSIDE_NETWORK} dev ${OUTSIDE_DEVICE} src ${OUTSIDE_IP} ip route add ${OUTSIDE_NETWORK2} dev ${OUTSIDE_DEVICE2} src ${OUTSIDE_IP2} # ip rule add from ${OUTSIDE_IP} table first ip rule add from ${OUTSIDE_IP2} table second # # weighted multipath routing # ip route add default scope global nexthop via \${OUTSIDE_GATEWAY} \ ${OUTSIDE_DEVICE} weight ${OUTSIDE_DEV_WEIGHT} \ nexthop ${OUTSIDE_GATEWAY2} dev ${OUTSIDE_DEVICE2} \ weight ${OUTSIDE_DEV2_WEIGHT} Everything is working if I just do as above, I can ping OUTSIDE_GATEWAY and OUTSIDE_GATEWAY2 AND OUTSIDE_IP and OUTSIDE_IP2. But If I added the two lines below :- ip route add default via ${OUTSIDE_GATEWAY} table first ip route add default via ${OUTSIDE_GATEWAY2} table second Then I can't ping from my INSIDE_NETWORK to both the OUTSIDE_IP and OUTSIDE_IP2 but still able to ping OUTSIDE_GATEWAY and OUTSIDE_GATEWAY2. Why ? From lartc@nospam.otaku42.de Thu May 13 05:48:01 2004 From: lartc@nospam.otaku42.de (Michael Renzmann) Date: Thu, 13 May 2004 06:48:01 +0200 Subject: [LARTC] QoS in wireless networks In-Reply-To: <4095E979.9080706@gbt.tfo.upm.es> References: <20040503051358.15054.5837.Mailman@outpost.ds9a.nl> <4095E979.9080706@gbt.tfo.upm.es> Message-ID: <40A2FE01.5030905@otaku42.de> Hi. Francisco Javier Simo Reigadas wrote: > I'm trying to configure several wireless routers with QoS support. [...] Do you mind telling something about the results? I'm really curious what happened since your first request... Bye, Mike From reza@mra.co.id Thu May 13 05:38:08 2004 From: reza@mra.co.id (Muhammad Reza) Date: Thu, 13 May 2004 11:38:08 +0700 Subject: [LARTC] Multipath Connection problem on RH-8.0 In-Reply-To: References: <40A1D154.5080508@mra.co.id> Message-ID: <40A2FBB0.5080504@mra.co.id> Julian Anastasov wrote: > Hello, > >On Wed, 12 May 2004, Muhammad Reza wrote: > > > >>default proto static >> nexthop via 172.16.0.1 dev eth0 weight 256 dead onlink pervasive >> nexthop via 192.168.0.1 dev eth1 weight 1 >>I search the list about this error, and found that i shall use the >>upgrade version of iproute2, and i compile that too. >>but with same config, and new iproute2 i can't connect to internet now. >>please be advice, what wrong with my config (attach), and what version >>of linux should work ? >> >> > > Can you check the example 'ip route get' commands and >"2.4 Keeping them alive" from nano.txt. Make sure after upgrading >iproute2 that your nexthops are not dead. Also, list you rules >and routes and make sure they are valid, I see your commands but >I do not know which of them are accepted from the kernel. > >Regards > >-- >Julian Anastasov > > > now i downgrade to rh-7.2 (2.4.20-w/ julian patch)and iproute version iproute2-ss010824. but still cant do multipath routing. this is my trace with ip route get; [root@firewall root]# ip route get 202.138.253.17 202.138.253.17 via 172.16.0.1 dev eth0 src 172.16.0.232 cache mtu 1500 advmss 1460 [root@firewall root]# ip route get 202.138.253.17 from 192.168.0.2 202.138.253.17 from 192.168.0.2 via 192.168.0.1 dev eth1 cache mtu 1500 advmss 1460 [root@firewall root]# ip route get 202.138.253.17 from 172.16.0.232 202.138.253.17 from 172.16.0.232 via 172.16.0.1 dev eth0 cache mtu 1500 advmss 1460 [root@firewall root]# ip route list table main 192.168.0.0/30 dev eth1 proto kernel scope link src 192.168.0.2 172.16.0.0/24 dev eth0 scope link 10.10.10.0/24 dev eth2 scope link 127.0.0.0/8 dev lo scope link [root@firewall root]# ip route list table MRA default via 172.16.0.1 dev eth0 proto static src 172.16.0.232 prohibit default proto static metric 1 [root@firewall root]# ip route list table DEF default proto static nexthop via 172.16.0.1 dev eth0 weight 1 nexthop via 192.168.0.1 dev eth1 weight 1 with this configuration i still couldn connect to internet how to debug and solve this problem... ? please be advice.. regards reza From oeschey@web.de Thu May 13 08:06:12 2004 From: oeschey@web.de (Lars Oeschey) Date: Thu, 13 May 2004 09:06:12 +0200 (CEST) Subject: [LARTC] Bandwith thinking error In-Reply-To: <200405121728.54385.Andreas.Klauer@metamorpher.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405121728.54385.Andreas.Klauer@metamorpher.de> Message-ID: <51673.143.164.102.13.1084431972.squirrel@vdr.oescheyhome.de> > You have to add your filters then to the DSL class instead of > parent qdisc, and a filter in the parent qdisc that puts packets > that go to the Router IP into the DSL class. Or modify your filters > so that they only apply to Router packets. Especially if you're > using ingress, you have to modify the policy filters so that they > only apply to packets coming from the router. err, what's ingress? > As a simplified ascii graphic: > > HTB qdisc > | > \--- HTB fat class (LAN rate) > | > \--- HTB DSL class (DSL rate; only packets to the router > go here) \--- HTB LAN class (LAN-DSL rate; all other > packets go here) > > A problem with this design would be if you have additional local > traffic that goes to the router (e.g. a ssh session to the router > that does not actually go to the internet). This would be > classified as DSL traffic too. I don't know if filters can be > designed in a way that they only match on gateway'ed traffic. There's the occasional http traffic to the router for configuration (it's the current t-online WLan device), but that's quite rare and I don't care if it's a bit slow then (hey, I already worked with imap over 384k in my LAN ;)). > Shaping this way won't work particularly well especially if there > are other users in your LAN using the router. You should do the > shaping directly on the router in any case. There's just me and my wife, and she only uses http over the proxy on the shaped machine. I will transfer her pop3 access to the linux-box w/fetchmail some day, so every traffic goes through the linux-box.Um. Forgot about ftp, it's currently direct... perhaps I should set up a ftp proxy too then... But it's also quite rare. Are there any tools to define the shaping? Or do I really have to write it from scratch? Lars From ja@ssi.bg Thu May 13 08:23:27 2004 From: ja@ssi.bg (Julian Anastasov) Date: Thu, 13 May 2004 10:23:27 +0300 (EEST) Subject: [LARTC] Multipath Connection problem on RH-8.0 In-Reply-To: <40A2FBB0.5080504@mra.co.id> References: <40A1D154.5080508@mra.co.id> <40A2FBB0.5080504@mra.co.id> Message-ID: Hello, To all: do you have some working script(s) that we can recommend for setups with 2 or 3 uplinks in multipath route? Then we can link them to the web page as reference. On Thu, 13 May 2004, Muhammad Reza wrote: > now i downgrade to rh-7.2 (2.4.20-w/ julian patch)and iproute version > iproute2-ss010824. > but still cant do multipath routing. Then can you explain what you learned from "2.4 Keeping them alive" and what you have to keep the state for each GW from the multipath route valid? > this is my trace with ip route get; > [root@firewall root]# ip route get 202.138.253.17 > 202.138.253.17 via 172.16.0.1 dev eth0 src 172.16.0.232 > cache mtu 1500 advmss 1460 > [root@firewall root]# ip route get 202.138.253.17 from 192.168.0.2 > 202.138.253.17 from 192.168.0.2 via 192.168.0.1 dev eth1 > cache mtu 1500 advmss 1460 > [root@firewall root]# ip route get 202.138.253.17 from 172.16.0.232 > 202.138.253.17 from 172.16.0.232 via 172.16.0.1 dev eth0 > cache mtu 1500 advmss 1460 > [root@firewall root]# ip route list table main > 192.168.0.0/30 dev eth1 proto kernel scope link src 192.168.0.2 This is strange: > 172.16.0.0/24 dev eth0 scope link > 10.10.10.0/24 dev eth2 scope link It means your settings are not created from script. Also, the script does not bring dev eth0 up, there is a missing "up". > 127.0.0.0/8 dev lo scope link > [root@firewall root]# ip route list table MRA > default via 172.16.0.1 dev eth0 proto static src 172.16.0.232 > prohibit default proto static metric 1 What do you have in table ADSL? Can you provide output from: ip addr ip rule ip route list table all > [root@firewall root]# ip route list table DEF > default proto static > nexthop via 172.16.0.1 dev eth0 weight 1 > nexthop via 192.168.0.1 dev eth1 weight 1 > > with this configuration i still couldn connect to internet From where? What shows tcpdump -ln ... ? > regards > reza Regards -- Julian Anastasov From Robert Kurjata Thu May 13 08:41:57 2004 From: Robert Kurjata (Robert Kurjata) Date: Thu, 13 May 2004 09:41:57 +0200 Subject: Re[2]: [LARTC] Multipath Connection problem on RH-8.0 In-Reply-To: References: <40A1D154.5080508@mra.co.id> <40A2FBB0.5080504@mra.co.id> Message-ID: <1857449954.20040513094157@ire.pw.edu.pl> Hello Julian, Thursday, May 13, 2004, 9:23:27 AM, you wrote: JA> Hello, JA> To all: do you have some working script(s) that we can JA> recommend for setups with 2 or 3 uplinks in multipath route? Then we JA> can link them to the web page as reference. [cut] I've posted one in 2 links version. Now I'm using slightly extended version for 4 links with policy routing :) http://mailman.ds9a.nl/pipermail/lartc/2003q4/010372.html -- Best regards, Robert mailto:rkurjata@ire.pw.edu.pl From calin2k@home.ro Thu May 13 11:34:30 2004 From: calin2k@home.ro (calin popa) Date: 13 May 2004 10:34:30 -0000 Subject: [LARTC] help setting up router Message-ID: <20040513103430.16428.qmail@s2.home.ro> Hi, my name is Calin and I'm new to linux, but I guess its the right place to ask this: what do I set on a linux RH9 box with 2.4.24 kernel to route a 10 machine private network (192.168.x.x) by 3 limited bandwidth, public IPs (193.231.x.x). The network uses a switch, the linux box has 1 ethernet card, the link is available trough a wireles ethernet bridge from my ISP. I begun to read routing and IP howtos. I thing that I need some virtual ethernet adapters and SNAT routing. tia ---- Home, no matter how far... http://www.home.ro From andy.furniss@dsl.pipex.com Thu May 13 11:16:09 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Thu, 13 May 2004 11:16:09 +0100 Subject: [LARTC] ip_conntrack_ftp In-Reply-To: <20040512152944.2c9dab4e@bugs> References: <20040511012222.6c12892f@vr> <409FE807.1060308@dsl.pipex.com> <20040511100946.171bd354@bugs> <40A1D803.8050900@dsl.pipex.com> <20040512152944.2c9dab4e@bugs> Message-ID: <40A34AE9.2070303@dsl.pipex.com> raptor wrote: > tryng to access ftp servers from inside... Well I am not sure - I would be double checking all scripts for typos/brainos. You haven't posted evrything you use - and even if you did I am no netfilter/firewalling expert. The netfilter list is probably a better place for this sort of issue. Andy. From Andreas.Klauer@metamorpher.de Thu May 13 14:17:44 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Thu, 13 May 2004 15:17:44 +0200 Subject: [LARTC] Bandwith thinking error In-Reply-To: <51673.143.164.102.13.1084431972.squirrel@vdr.oescheyhome.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405121728.54385.Andreas.Klauer@metamorpher.de> <51673.143.164.102.13.1084431972.squirrel@vdr.oescheyhome.de> Message-ID: <200405131517.44520.Andreas.Klauer@metamorpher.de> Am Thursday 13 May 2004 09:06 schrieb Lars Oeschey: > err, what's ingress? Read in the LARTC Howto (www.lartc.org) about it. Wondershaper does it for limiting incoming traffic. The real classful shaping can only be done for outgoing traffic. (Well, probably unless you're using IMQ, but Wondershaper doesn't). > There's the occasional http traffic to the router for configuration > (it's the current t-online WLan device), but that's quite rare and I > don't care if it's a bit slow then (hey, I already worked with imap > over 384k in my LAN ;)). Never mind that, I figured it should be easy to get the filters right. > There's just me and my wife, You need shaping so badly if there are only two users? > I will transfer her pop3 access to the linux-box w/fetchmail some day, so > every traffic goes through the linux-box. If you want every traffic to go through your linux box, remove the router from the LAN, connect it directly to your box and let your box do the routing for your wife. In case your box can go online directly, sell the router. > Are there any tools to define the shaping? Or do I really have to > write it from scratch? I just modified the wondershaper script a little. You could test if it actually works. I couldn't test it, since I have a dedicated linux box doing the routing. The modified wondershaper is here: http://www.metamorpher.de/files/wshaper-over-lan.htb Here's an image of the class structure it creates: http://www.metamorpher.de/files/wshaper-over-lan.png This image was created with Graphviz. I just love this program :-) I used a hacked version of Stef Coene's show.pl to generate the graph. Still have problems parsing the filter output, though... The blue boxes are qdiscs, the orange house is a root class, the green eggs are normal classes. Green arrows go to the root class, red arrows go to the leafs. :-) It doesn't show filters though, except for mark handles... tc filter output isn't easy to parse. The LAN traffic should go into the fat egg on the right. The internet traffic should go into the smaller egg on the left (and into it's children). Use "wshaper-over-lan.htb status" to see if it actually works. If you produce both traffic in the LAN and on the internet, the LAN traffic should show up in class 1:3, the internet traffic in class 1:1 and it's children. Andreas From carles@unlimitedmail.org Thu May 13 14:14:56 2004 From: carles@unlimitedmail.org (Carles Xavier Munyoz =?iso-8859-15?q?Bald=F3?=) Date: Thu, 13 May 2004 15:14:56 +0200 Subject: [LARTC] TCP rate control library. Message-ID: <200405131514.56816.carles@unlimitedmail.org> Hi, Anyone here knows if is there any TCP rate control C library ? I have a server program to which users authenticate to access its services. The problem is that some users takes lot of bandwidth, disturbing the=20 performance of the other connected users. I have used QoS to advoid that a single user takes all the bandwidth buy I= =20 would like to go more far and limit the bandwidth of this "bad" users. Is there any C library for it ? Greetings. =2D-- Carles Xavier Munyoz Bald=F3 carles@unlimitedmail.org http://www.unlimitedmail.net/ =2D-- From kaber@trash.net Thu May 13 14:05:43 2004 From: kaber@trash.net (Patrick McHardy) Date: Thu, 13 May 2004 15:05:43 +0200 Subject: [LARTC] HFSC In-Reply-To: <40A2528C.3030306@ornl.gov> References: <40A2528C.3030306@ornl.gov> Message-ID: <40A372A7.6060207@trash.net> Lawrence MacIntyre wrote: > /usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc > > /usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 > 30mbit d 0 m2 30mbit ls m1 30mbit d 0 m2 30mbit > > When the second command is executed, the machine simply drops all > packets going through it. Unlike HTB, HFSC drops unclassified packets. You need to setup filters or use the "default" classification. Regards Patrick From oeschey@web.de Thu May 13 14:48:40 2004 From: oeschey@web.de (Lars Oeschey) Date: Thu, 13 May 2004 15:48:40 +0200 (CEST) Subject: [LARTC] Bandwith thinking error In-Reply-To: <200405131517.44520.Andreas.Klauer@metamorpher.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405121728.54385.Andreas.Klauer@metamorpher.de> <51673.143.164.102.13.1084431972.squirrel@vdr.oescheyhome.de> <200405131517.44520.Andreas.Klauer@metamorpher.de> Message-ID: <49044.143.164.102.13.1084456120.squirrel@vdr.oescheyhome.de> > Am Thursday 13 May 2004 09:06 schrieb Lars Oeschey: > Read in the LARTC Howto (www.lartc.org) about it. just did ;) >> There's just me and my wife, > You need shaping so badly if there are only two users? err, not really, it's just that http/mail etc. wins over p2p ;) > If you want every traffic to go through your linux box, remove the > router from the LAN, connect it directly to your box and let your > box do the routing for your wife. In case your box can go online > directly, sell the router. mh, been there, done that... I come from fli4l, and was glad that I could switch to that tiny little router-device ;)I think when I can just priorise squid over p2p stuff, everything should be fine > I just modified the wondershaper script a little. You could test if > it actually works. I couldn't test it, since I have a dedicated > linux box doing the routing. > The modified wondershaper is here: cool, thanks a lot for that... I'll check it out when I'm home today! Lars -- visit the C.O.R.E. http://www.the-core.net From lpz@ornl.gov Thu May 13 14:52:11 2004 From: lpz@ornl.gov (Lawrence MacIntyre) Date: Thu, 13 May 2004 09:52:11 -0400 Subject: [LARTC] HFSC In-Reply-To: <40A372A7.6060207@trash.net> References: <40A2528C.3030306@ornl.gov> <40A372A7.6060207@trash.net> Message-ID: <40A37D8B.4020904@ornl.gov> This is a multi-part message in MIME format. --------------040403080205020401030907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks, Patrick. That makes it a bit harder to manage from a remote machine. I'll have to be very careful with that. I'll try to figure out the implications of the default classification and send more email if I can't get it. So I reordered the commands and changed them around. It looks like I am either doing something strange or I have found a bug. When I execute the following script, the UDP traffic on port 1234 continues for a few seconds and then stops. When I examine the tc data, it shows no change in the periods or amount of bytes flowing after the flow stops. I am enclosing the command and the output. Thanks again! Patrick McHardy wrote: > Lawrence MacIntyre wrote: > >> /usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc >> >> /usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 >> 30mbit d 0 m2 30mbit ls m1 30mbit d 0 m2 30mbit >> >> When the second command is executed, the machine simply drops all >> packets going through it. > > > Unlike HTB, HFSC drops unclassified packets. You need to setup filters > or use the "default" classification. > > Regards > Patrick -- Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group --------------040403080205020401030907 Content-Type: text/x-troff-man; name="hfsc.conf.4" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hfsc.conf.4" #!/bin/bash /usr/local/bin/tc qdisc add dev eth0 root handle 1: hfsc /usr/local/bin/tc class add dev eth0 parent 1: classid 1:1 hfsc ul m1 80mbit d 500 m2 30mbit ls m1 80mbit d 500 m2 30mbit /usr/local/bin/tc class add dev eth0 parent 1:1 classid 1:10 hfsc ls m1 50mbit d 500 m2 20mbit /usr/local/bin/tc class add dev eth0 parent 1:1 classid 1:11 hfsc ls m1 20mbit d 500 m2 10mbit /usr/local/bin/tc class add dev eth0 parent 1:1 classid 1:12 hfsc ls m1 10mbit d 500 m2 10mbit /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 1234 0xffff flowid 1:10 /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 5001 0xffff flowid 1:11 /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 22 0xffff flowid 1:12 /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:12 --------------040403080205020401030907 Content-Type: text/plain; name="data" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="data" [root@castor QoS]# ./tcshow.conf class hfsc 1: root Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 2 class hfsc 1:11 parent 1:1 ls m1 20Mbit d 500us m2 10Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 0 class hfsc 1:1 parent 1: ls m1 80Mbit d 500us m2 30Mbit ul m1 80Mbit d 500us m2 30Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 492 work 7280180 bytes level 1 class hfsc 1:10 parent 1:1 ls m1 50Mbit d 500us m2 20Mbit Sent 7280180 bytes 5314 pkts (dropped 0, overlimits 0) period 492 work 7280180 bytes level 0 class hfsc 1:12 parent 1:1 ls m1 10Mbit d 500us m2 10Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 0 qdisc hfsc 1: Sent 7280180 bytes 5314 pkts (dropped 0, overlimits 6570) 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:10 match 000004d2/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:11 match 00001389/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:12 match 00000016/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:12 match 00160000/ffff0000 at 20 [root@castor QoS]# ./tcshow.conf class hfsc 1: root Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 2 class hfsc 1:11 parent 1:1 ls m1 20Mbit d 500us m2 10Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 0 class hfsc 1:1 parent 1: ls m1 80Mbit d 500us m2 30Mbit ul m1 80Mbit d 500us m2 30Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 965 work 14246630 bytes level 1 class hfsc 1:10 parent 1:1 ls m1 50Mbit d 500us m2 20Mbit Sent 14246630 bytes 10399 pkts (dropped 0, overlimits 0) period 965 work 14246630 bytes level 0 class hfsc 1:12 parent 1:1 ls m1 10Mbit d 500us m2 10Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 0 qdisc hfsc 1: Sent 14246630 bytes 10399 pkts (dropped 32, overlimits 12895) 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:10 match 000004d2/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:11 match 00001389/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:12 match 00000016/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:12 match 00160000/ffff0000 at 20 [root@castor QoS]# ./tcshow.conf class hfsc 1: root Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 2 class hfsc 1:11 parent 1:1 ls m1 20Mbit d 500us m2 10Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 0 class hfsc 1:1 parent 1: ls m1 80Mbit d 500us m2 30Mbit ul m1 80Mbit d 500us m2 30Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 965 work 14246630 bytes level 1 class hfsc 1:10 parent 1:1 ls m1 50Mbit d 500us m2 20Mbit Sent 14246630 bytes 10399 pkts (dropped 0, overlimits 0) period 965 work 14246630 bytes level 0 class hfsc 1:12 parent 1:1 ls m1 10Mbit d 500us m2 10Mbit Sent 0 bytes 0 pkts (dropped 0, overlimits 0) period 0 level 0 qdisc hfsc 1: Sent 14246630 bytes 10399 pkts (dropped 33, overlimits 12895) 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:10 match 000004d2/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:11 match 00001389/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:12 match 00000016/0000ffff at 20 filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:12 match 00160000/ffff0000 at 20 [root@castor QoS]# ./hfscdel.conf --------------040403080205020401030907-- From carles@unlimitedmail.org Thu May 13 15:05:40 2004 From: carles@unlimitedmail.org (Carles Xavier Munyoz =?iso-8859-15?q?Bald=F3?=) Date: Thu, 13 May 2004 16:05:40 +0200 Subject: [LARTC] Bandwith especification. Message-ID: <200405131605.40085.carles@unlimitedmail.org> Hi, If I have a DSL router with 300kpbs upload bandwith: Linux(eth0) ---(100Mbps)---> DSL ---(300kbps)---> INTERNET Which is the recomended value I must set in my QoS setup for the maximum=20 outbound bandwith of my ethernet interface ? The max of 300kbps or something less like 290kbps ? Especify less than the maximum available bandwith is advisable to ensure th= at=20 the QoS algoritms goes fine, isn't it ? Greetings. =2D-- Carles Xavier Munyoz Bald=F3 carles@unlimitedmail.org http://www.unlimitedmail.net/ =2D-- From Andreas.Klauer@metamorpher.de Thu May 13 15:23:52 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Thu, 13 May 2004 16:23:52 +0200 Subject: [LARTC] Bandwith thinking error In-Reply-To: <49044.143.164.102.13.1084456120.squirrel@vdr.oescheyhome.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405131517.44520.Andreas.Klauer@metamorpher.de> <49044.143.164.102.13.1084456120.squirrel@vdr.oescheyhome.de> Message-ID: <200405131623.52937.Andreas.Klauer@metamorpher.de> Am Thursday 13 May 2004 15:48 schrieb Lars Oeschey: > err, not really, it's just that http/mail etc. wins over p2p ;) If you want to detect P2P traffic, have a look into this: http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html My Fair NAT script supports it. It works well for me. :-) HTH Andreas From andy.furniss@dsl.pipex.com Thu May 13 14:54:35 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Thu, 13 May 2004 14:54:35 +0100 Subject: [LARTC] HTB MPU Message-ID: <40A37E1B.8060604@dsl.pipex.com> Hi. I wrote in a reply to a mail on here recently that you can't set mpu (minimum packet unit) on HTB as you can on CBQ. I've just noticed that there is a patch on devik's site which does mpu and overhead. http://luxik.cdi.cz/~devik/qos/htb/ For dsl users mpu is, for practical purposes going to be 106 - overhead is still variable though, depending on packet size. Having these should let you push upstream bandwidth rates a bit closer to the limit. Andy. From kaber@trash.net Thu May 13 15:23:14 2004 From: kaber@trash.net (Patrick McHardy) Date: Thu, 13 May 2004 16:23:14 +0200 Subject: [LARTC] HFSC In-Reply-To: <40A37D8B.4020904@ornl.gov> References: <40A2528C.3030306@ornl.gov> <40A372A7.6060207@trash.net> <40A37D8B.4020904@ornl.gov> Message-ID: <40A384D2.2040309@trash.net> Lawrence MacIntyre wrote: > Thanks, Patrick. That makes it a bit harder to manage from a remote > machine. I'll have to be very careful with that. I'll try to figure > out the implications of the default classification and send more email > if I can't get it. > > So I reordered the commands and changed them around. It looks like I am > either doing something strange or I have found a bug. When I execute > the following script, the UDP traffic on port 1234 continues for a few > seconds and then stops. When I examine the tc data, it shows no change > in the periods or amount of bytes flowing after the flow stops. I am > enclosing the command and the output. It is indeed strange. Only the qdisc drop counter is incremented, which means the packets are still unclassified. What happens if you change your filter to: /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match udp dport 1234 0xffff flowid 1:10 (match udp instead of ip) Are you sure the packets are sent to port 1234 ? Regards Patrick From Andreas.Klauer@metamorpher.de Thu May 13 15:38:22 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Thu, 13 May 2004 16:38:22 +0200 Subject: [LARTC] HTB MPU In-Reply-To: <40A37E1B.8060604@dsl.pipex.com> References: <40A37E1B.8060604@dsl.pipex.com> Message-ID: <200405131638.22155.Andreas.Klauer@metamorpher.de> Am Thursday 13 May 2004 15:54 schrieb Andy Furniss: > I've just noticed that there is a patch on devik's site which does mpu > and overhead. > > http://luxik.cdi.cz/~devik/qos/htb/ Great, all the gems are hidden in the Changelog. ;-) Direct link: http://luxik.cdi.cz/~devik/qos/htb/v3/htb_tc_overhead.diff I'll give it a try. Thanks for the hint. Andreas From Andreas.Klauer@metamorpher.de Thu May 13 18:28:19 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Thu, 13 May 2004 19:28:19 +0200 Subject: [LARTC] HTB MPU In-Reply-To: <200405131638.22155.Andreas.Klauer@metamorpher.de> References: <40A37E1B.8060604@dsl.pipex.com> <200405131638.22155.Andreas.Klauer@metamorpher.de> Message-ID: <200405131928.19030.Andreas.Klauer@metamorpher.de> Am Thursday 13 May 2004 16:38 schrieb Andreas Klauer: > Am Thursday 13 May 2004 15:54 schrieb Andy Furniss: > > I've just noticed that there is a patch on devik's site which does mpu > > and overhead. > > I'll give it a try. Thanks for the hint. Well, patching was a little difficult... it didn't like the debian patch and I didn't succeed in joining the two patches together because of the weird inject stuff. But anyway. It seems to work, and it looks useful, so I added it to the "Hacks" section of my Fair NAT script together with a patched binary. Andreas From stef.coene@docum.org Thu May 13 18:18:21 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 13 May 2004 19:18:21 +0200 Subject: [LARTC] Bandwith especification. In-Reply-To: <200405131605.40085.carles@unlimitedmail.org> References: <200405131605.40085.carles@unlimitedmail.org> Message-ID: <200405131918.21410.stef.coene@docum.org> On Thursday 13 May 2004 16:05, Carles Xavier Munyoz Bald=F3 wrote: > Hi, > If I have a DSL router with 300kpbs upload bandwith: > Linux(eth0) ---(100Mbps)---> DSL ---(300kbps)---> INTERNET > > Which is the recomended value I must set in my QoS setup for the maximum > outbound bandwith of my ethernet interface ? > The max of 300kbps or something less like 290kbps ? > > Especify less than the maximum available bandwith is advisable to ensure > that the QoS algoritms goes fine, isn't it ? Yes. Staf =2D-=20 stef.coene@docum.org =A0"Using Linux as bandwidth manager" =A0 =A0 =A0http://www.docum.org/ From lpz@ornl.gov Thu May 13 18:43:36 2004 From: lpz@ornl.gov (Lawrence MacIntyre) Date: Thu, 13 May 2004 13:43:36 -0400 Subject: [LARTC] HFSC In-Reply-To: <40A384D2.2040309@trash.net> References: <40A2528C.3030306@ornl.gov> <40A372A7.6060207@trash.net> <40A37D8B.4020904@ornl.gov> <40A384D2.2040309@trash.net> Message-ID: <40A3B3C8.9000208@ornl.gov> Patrick: I tried that filter line, but it has incorrect syntax. But that isn't the problem. The problem is the HFSC part... The traffic is indeed UDP port 1234, and the HFSC qdisc functions for a short period of time (between 5 and 60 seconds or so, and then stops passing any traffic on the eth0 interface. You can look with ethereal, and the interface is totally silent. Even weirder, if you wait, periodically (every several minutes or so) you get another period of working. These are typically 5-10 seconds. What do I need to do to debug this? The machine is a dual Xeon, if that matters. Patrick McHardy wrote: > Lawrence MacIntyre wrote: > >> Thanks, Patrick. That makes it a bit harder to manage from a remote >> machine. I'll have to be very careful with that. I'll try to figure >> out the implications of the default classification and send more email >> if I can't get it. >> >> So I reordered the commands and changed them around. It looks like I >> am either doing something strange or I have found a bug. When I >> execute the following script, the UDP traffic on port 1234 continues >> for a few seconds and then stops. When I examine the tc data, it >> shows no change in the periods or amount of bytes flowing after the >> flow stops. I am enclosing the command and the output. > > > It is indeed strange. Only the qdisc drop counter is incremented, which > means the packets are still unclassified. What happens if you change > your filter to: > > /usr/local/bin/tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 > match udp dport 1234 0xffff flowid 1:10 (match udp instead of ip) > > Are you sure the packets are sent to port 1234 ? > > Regards > Patrick -- Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group From natxete@xs4all.nl Thu May 13 18:38:12 2004 From: natxete@xs4all.nl (Natxo Asenjo) Date: Thu, 13 May 2004 19:38:12 +0200 Subject: [LARTC] wondershaper.htb problem Message-ID: <20040513173811.GA6976@ainhoa.xs4all.nl> hi there, this is my 1st message in the list. I would like to use this wondershaper.htb to limit the bandwith usage at home. My kernel config is: # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_CSZ=y CONFIG_NET_SCH_HFSC=y CONFIG_NET_SCH_PRIO=y CONFIG_NET_SCH_RED=y CONFIG_NET_SCH_SFQ=y CONFIG_NET_SCH_TEQL=y CONFIG_NET_SCH_TBF=y CONFIG_NET_SCH_GRED=y CONFIG_NET_SCH_DELAY=y CONFIG_NET_SCH_DSMARK=y CONFIG_NET_SCH_INGRESS=y CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=y CONFIG_NET_CLS_ROUTE4=y CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_U32=y CONFIG_NET_CLS_RSVP=y CONFIG_NET_CLS_RSVP6=y CONFIG_NET_CLS_POLICE=y I've got the iproute package (in debian woody according to the changelog, there is support for htb). When I try to use the wondershaperscript with the -x flag for verbosity I get the following: + DOWNLINK=1000 + UPLINK=300 + DEV=ppp0 + NOPRIOHOSTSRC= + NOPRIOHOSTDST= + '[' start = status ']' + tc qdisc del dev ppp0 root + tc qdisc del dev ppp0 ingress + '[' start = stop ']' + tc qdisc add dev ppp0 root handle 1: htb default 30 RTNETLINK answers: Invalid argument + tc class add dev ppp0 parent 1: classid 1:1 htb rate 300kbit burst 6k RTNETLINK answers: No such file or directory + tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 300kbit burst 6k prio 1 RTNETLINK answers: No such file or directory + tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 150kbit ceil 80kbit burst 6k prio 2 and more lines similar to those ones. So most things go ok but I do not understand the RTNETLINK lines. Is that ok? I could not find an answer in google. I also see in dmsg this: HTB init, kernel part version 3.16 HTB: need tc/htb version 3 (minor is 16), you have 10 And I do not know where I can get another version of this for debian woody. I am sure this is a FAQ, but I could not find the answer, I am sorry :( Greetings, N.Asenjo From oeschey@web.de Thu May 13 19:59:14 2004 From: oeschey@web.de (Lars Oeschey) Date: Thu, 13 May 2004 20:59:14 +0200 Subject: [LARTC] Bandwith thinking error In-Reply-To: <200405131517.44520.Andreas.Klauer@metamorpher.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405121728.54385.Andreas.Klauer@metamorpher.de> <51673.143.164.102.13.1084431972.squirrel@vdr.oescheyhome.de> <200405131517.44520.Andreas.Klauer@metamorpher.de> Message-ID: <40A3C582.5000407@web.de> Andreas Klauer wrote: >The modified wondershaper is here: > http://www.metamorpher.de/files/wshaper-over-lan.htb > > I tested the script now, it works good so far in that LAN traffic isn't slowed down anymore . But when p2p has full Bandwidth, http over the proxy is very slow. I would like that p2p just gets the bandwidth thats left over after http, is that possible? What I tried with the original script was this, could that work? tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip dport 3128 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip sport 3128 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip dport 80 0xffff flowid 1:10 tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ match ip sport 80 0xffff flowid 1:10 Lars From Andreas.Klauer@metamorpher.de Thu May 13 21:01:00 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Thu, 13 May 2004 22:01:00 +0200 Subject: [LARTC] Bandwith thinking error In-Reply-To: <40A3C582.5000407@web.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405131517.44520.Andreas.Klauer@metamorpher.de> <40A3C582.5000407@web.de> Message-ID: <200405132201.00969.Andreas.Klauer@metamorpher.de> Am Thursday 13 May 2004 20:59 schrieb Lars Oeschey: > Andreas Klauer wrote: > >The modified wondershaper is here: > > http://www.metamorpher.de/files/wshaper-over-lan.htb > > I would like that p2p just gets the bandwidth thats > left over after http, is that possible? It's hard to get the P2P stuff right. First of all, it's usually download traffic - but Wondershaper only shapes upload traffic. Second of all, what is P2P traffic? Matching http protocol probably won't work, since some P2P programs also use HTTP. (IIRC BitTorrent uses http to communicate with the tracker). If you're only prioritizing specific port, you'll find many other forms of communications (chats, ftp, whatever) be slow because that's put into same class as P2P too. > What I tried with the original > script was this, could that work? > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 3128 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 3128 0xffff flowid 1:10 3128 is a http port? I didn't know >_> > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 80 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 80 0xffff flowid 1:10 That'd be bad for interactive connections... change default to 30, lower rate for 30 (low rate, high ceil, large prio, so the class has to borrow everything). Put http traffic into 20. Wondershaper's rate settings are weird anyway - sum of child rates is much larger than parent rate. HTH Andreas From Andreas.Klauer@metamorpher.de Thu May 13 20:28:17 2004 From: Andreas.Klauer@metamorpher.de (Andreas Klauer) Date: Thu, 13 May 2004 21:28:17 +0200 Subject: [LARTC] wondershaper.htb problem In-Reply-To: <20040513173811.GA6976@ainhoa.xs4all.nl> References: <20040513173811.GA6976@ainhoa.xs4all.nl> Message-ID: <200405132128.17224.Andreas.Klauer@metamorpher.de> Am Thursday 13 May 2004 19:38 schrieb Natxo Asenjo: > + tc qdisc add dev ppp0 root handle 1: htb default 30 > RTNETLINK answers: Invalid argument Wrong tc. > HTB init, kernel part version 3.16 > HTB: need tc/htb version 3 (minor is 16), you have 10 > > And I do not know where I can get another version of this for debian > woody. =46rom the HTB homepage. Both patch and binary are available. http://luxik.cdi.cz/~devik/qos/htb/ HTH Andreas From jasonb@edseek.com Thu May 13 20:53:48 2004 From: jasonb@edseek.com (Jason Boxman) Date: Thu, 13 May 2004 15:53:48 -0400 Subject: [LARTC] help setting up router In-Reply-To: <20040513103430.16428.qmail@s2.home.ro> References: <20040513103430.16428.qmail@s2.home.ro> Message-ID: <200405131553.49777.jasonb@edseek.com> On Thursday 13 May 2004 06:34, calin popa wrote: > Hi, my name is Calin and I'm new to linux, but I guess its the right place > to ask this: > > what do I set on a linux RH9 box with 2.4.24 kernel to route a 10 machine > private network (192.168.x.x) by 3 limited bandwidth, public IPs > (193.231.x.x). The network uses a switch, the linux box has 1 ethernet > card, the link is available trough a wireles ethernet bridge from my ISP. > > I begun to read routing and IP howtos. I thing that I need some virtual > ethernet adapters and SNAT routing. It sounds like you want to use NAT. Stick another NIC in your Linux box and configure it as your gateway. All of that is rather simple. I'd suggest these documents: http://iptables-tutorial.frozentux.net/iptables-tutorial.html http://www.linux-ip.net/html/ If you want to load balance across your three public IPs or do traffic shaping across the wireless link, that's more ARTC. > tia > From jasonb@edseek.com Thu May 13 21:13:51 2004 From: jasonb@edseek.com (Jason Boxman) Date: Thu, 13 May 2004 16:13:51 -0400 Subject: [LARTC] Bandwith thinking error In-Reply-To: <40A3C582.5000407@web.de> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405131517.44520.Andreas.Klauer@metamorpher.de> <40A3C582.5000407@web.de> Message-ID: <200405131613.51573.jasonb@edseek.com> On Thursday 13 May 2004 14:59, Lars Oeschey wrote: > Andreas Klauer wrote: > >The modified wondershaper is here: > > http://www.metamorpher.de/files/wshaper-over-lan.htb > > I tested the script now, it works good so far in that LAN traffic isn't > slowed down anymore . But when p2p has full Bandwidth, http over the > proxy is very slow. I would like that p2p just gets the bandwidth thats > left over after http, is that possible? What I tried with the original > script was this, could that work? I imagine you set $DEV to ethX, right? (In the original script it was ppp0.) Anyway, as to the p2p traffic, it is usually pretty pervasive. You will need to use something like IPP2P or L7-Filter to catch it and stick it in a p2p or bulk class. I found that for edonkey, for example, matching on port 4662 only caught 80% of the traffic in the best case scenario and 50% in the worst, making things like HTTP virtually unusable. You'll need to patch your kernel to use either one and they both have IPTables components you will need to use to match traffic. IPP2P needs CONNMARK, which is available in patch-o-matic for Netfilter. Be advised that you need the CVS version of IPTables to use CONNMARK with 2.6. IPP2P and CONNMARK work well on my 2.4.24 kernel with the CONNMARK patch from patch-o-matic. (The non -ng variant.) I also recommend the CLASSIFY patch if you are going to be using IPTables anyway. I have found that for the simple case of traffic shaping, it is actually easy to write your own basic script to handle it. Wondershaper is a nice template to start with. The usual procedure is 1) decide on classes and leafs and define them with `tc` and 2) decide how best to match traffic destined for your classes, using either `tc` or IPTables, and define matching rules. > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 3128 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 3128 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip dport 80 0xffff flowid 1:10 > > tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \ > match ip sport 80 0xffff flowid 1:10 > > Lars From ja@ssi.bg Thu May 13 22:10:36 2004 From: ja@ssi.bg (Julian Anastasov) Date: Fri, 14 May 2004 00:10:36 +0300 (EEST) Subject: Re[2]: [LARTC] Multipath Connection problem on RH-8.0 In-Reply-To: <1857449954.20040513094157@ire.pw.edu.pl> References: <40A1D154.5080508@mra.co.id> <40A2FBB0.5080504@mra.co.id> <1857449954.20040513094157@ire.pw.edu.pl> Message-ID: Hello, On Thu, 13 May 2004, Robert Kurjata wrote: > JA> To all: do you have some working script(s) that we can > JA> recommend for setups with 2 or 3 uplinks in multipath route? Then we > JA> can link them to the web page as reference. > [cut] > I've posted one in 2 links version. Now I'm using slightly extended > version for 4 links with policy routing :) Thank you, it is now linked. May be in the following days I'll try to create advanced version. > http://mailman.ds9a.nl/pipermail/lartc/2003q4/010372.html Regards -- Julian Anastasov From oeschey@web.de Thu May 13 22:16:14 2004 From: oeschey@web.de (Lars Oeschey) Date: Thu, 13 May 2004 23:16:14 +0200 Subject: [LARTC] Bandwith thinking error In-Reply-To: <200405131613.51573.jasonb@edseek.com> References: <9999.143.164.102.13.1084370910.squirrel@vdr.oescheyhome.de> <200405131517.44520.Andreas.Klauer@metamorpher.de> <40A3C582.5000407@web.de> <200405131613.51573.jasonb@edseek.com> Message-ID: <40A3E59E.9040705@web.de> Jason Boxman wrote: >I imagine you set $DEV to ethX, right? (In the original script it was ppp0.) > > > yep... > <>You'll need to patch your kernel to use either one and they both > have IPTables > components you will need to use to match traffic. IPP2P needs CONNMARK, > which is available in patch-o-matic for Netfilter. Be advised that you > need > the CVS version of IPTables to use CONNMARK with 2.6. IPP2P and CONNMARK > work well on my 2.4.24 kernel with the CONNMARK patch from patch-o-matic. > (The non -ng variant.) I also recommend the CLASSIFY patch if you are > going > to be using IPTables anyway. > ah, I wanted to avoid kernel compiling since I run a specialized debian that's mainly intended as vdr server... I'm a bit afraid of destryoing something with vdr ;) I blew the system up a bit to make it a universal server, which was easy with debian, but I still got away without kernel compiling... Lars From jasonb@edseek.com Thu May 13 22:59:36 2004 From: jasonb@edseek.com (Jason Boxman) Date: Thu, 13 May 2004 17:59:36 -0400 Subject: [LARTC] HTB MPU In-Reply-To: <200405131928.19030.Andreas.Klauer@metamorpher.de> References: <40A37E1B.8060604@dsl.pipex.com> <200405131638.22155.Andreas.Klauer@metamorpher.de> <200405131928.19030.Andreas.Klauer@metamorpher.de> Message-ID: <200405131759.36895.jasonb@edseek.com> On Thursday 13 May 2004 13:28, Andreas Klauer wrote: > Am Thursday 13 May 2004 16:38 schrieb Andreas Klauer: > > Am Thursday 13 May 2004 15:54 schrieb Andy Furniss: > > > I've just noticed that there is a patch on devik's site which does mpu > > > and overhead. > > > > I'll give it a try. Thanks for the hint. > > Well, patching was a little difficult... it didn't like the debian patch > and I didn't succeed in joining the two patches together because of the > weird inject stuff. But anyway. It seems to work, and it looks useful, so > I added it to the "Hacks" section of my Fair NAT script together with a > patched binary. Nifty. But how do you determine what your minimum packet unit (MPU) is? How about overhead for a PPPoE connection? With shaping I can max my upstream and still maintain ~ 120ms ping times, but I'd like to get it down to around ~ 70ms. > Andreas From natxete@xs4all.nl Fri May 14 04:29:38 2004 From: natxete@xs4all.nl (Natxo Asenjo) Date: Fri, 14 May 2004 05:29:38 +0200 Subject: [LARTC] wondershaper.htb problem In-Reply-To: <200405132128.17224.Andreas.Klauer@metamorpher.de> References: <20040513173811.GA6976@ainhoa.xs4all.nl> <200405132128.17224.Andreas.Klauer@metamorpher.de> Message-ID: <20040514032938.GA14605@ainhoa.xs4all.nl> On Thu, 13 May 2004, 09:28:17PM +0200¨, Andreas Klauer said: > Am Thursday 13 May 2004 19:38 schrieb Natxo Asenjo: > > + tc qdisc add dev ppp0 root handle 1: htb default 30 > > RTNETLINK answers: Invalid argument > > Wrong tc. yes, I thought so :) > > HTB init, kernel part version 3.16 > > HTB: need tc/htb version 3 (minor is 16), you have 10 > > > > And I do not know where I can get another version of this for debian > > woody. > > >From the HTB homepage. Both patch and binary are available. > http://luxik.cdi.cz/~devik/qos/htb/ ok, I had already tried the tc binary for htb2 code, but it obviously did not work. Now I have the good one for htb3, all is fine. Thanks, N.Asenjo > HTH > Andreas > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From lists@wildgooses.com Fri May 14 08:05:00 2004 From: lists@wildgooses.com (Ed Wildgoose) Date: Fri, 14 May 2004 08:05:00 +0100 Subject: [LARTC] HTB MPU In-Reply-To: <40A37E1B.8060604@dsl.pipex.com> References: <40A37E1B.8060604@dsl.pipex.com> Message-ID: <40A46F9C.8030509@wildgooses.com> Andy Furniss wrote: > Hi. > > I wrote in a reply to a mail on here recently that you can't set mpu > (minimum packet unit) on HTB as you can on CBQ. > > I've just noticed that there is a patch on devik's site which does mpu > and overhead. > > http://luxik.cdi.cz/~devik/qos/htb/ > > For dsl users mpu is, for practical purposes going to be 106 - > overhead is still variable though, depending on packet size. > > Having these should let you push upstream bandwidth rates a bit closer > to the limit. What about changing that patch a little (bear in mind I don't understand how it works though). I appears that you could change the patch in tc/core in fn tc_calc_rtable, from: + if (overhead) + sz += overhead; to something like: + if (overhead) + sz += (((sz-1)/mpu)+1) * overhead; Where that little calculation is trying to turn the mpu into a packet size, work out how many packets would be required for the size (sz) of data, and apply the overhead per packet. You would then set mpu to be the atm packet size, ie 54 To be honest though, this packing of the params into a single var seems unneccessary. The function tc_calc_rtab is only obviously used in the tc code, and it could be easily changed to have a prototype with an extra param. I would have to have a flick through the rest of the code, but it might be quite easy to add per packet overhead to the cbq code in the same way, and also whatever m_police is? Can someone with a working setup try this out and see if it helps? Ed W From andy.furniss@dsl.pipex.com Fri May 14 09:40:44 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Fri, 14 May 2004 09:40:44 +0100 Subject: [LARTC] HTB MPU In-Reply-To: <40A46F9C.8030509@wildgooses.com> References: <40A37E1B.8060604@dsl.pipex.com> <40A46F9C.8030509@wildgooses.com> Message-ID: <40A4860C.8070004@dsl.pipex.com> Ed Wildgoose wrote: > Andy Furniss wrote: > >> Hi. >> >> I wrote in a reply to a mail on here recently that you can't set mpu >> (minimum packet unit) on HTB as you can on CBQ. >> >> I've just noticed that there is a patch on devik's site which does mpu >> and overhead. >> >> http://luxik.cdi.cz/~devik/qos/htb/ >> >> For dsl users mpu is, for practical purposes going to be 106 - >> overhead is still variable though, depending on packet size. >> >> Having these should let you push upstream bandwidth rates a bit closer >> to the limit. > > > > What about changing that patch a little (bear in mind I don't understand > how it works though). > I appears that you could change the patch in tc/core in fn > tc_calc_rtable, from: > > + if (overhead) > + sz += overhead; > > to something like: > > + if (overhead) > + sz += (((sz-1)/mpu)+1) * overhead; > > Where that little calculation is trying to turn the mpu into a packet > size, work out how many packets would be required for the size (sz) of > data, and apply the overhead per packet. You would then set mpu to be > the atm packet size, ie 54 > > To be honest though, this packing of the params into a single var seems > unneccessary. The function tc_calc_rtab is only obviously used in the > tc code, and it could be easily changed to have a prototype with an > extra param. I would have to have a flick through the rest of the code, > but it might be quite easy to add per packet overhead to the cbq code in > the same way, and also whatever m_police is? > > Can someone with a wor