From tusharthakker@elitecore.com Fri Jan 2 19:08:21 2004 From: tusharthakker@elitecore.com (Tushar Thakker) Date: Fri, 2 Jan 2004 11:08:21 -0800 Subject: [LARTC] Load balancing with failover Message-ID: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C3D120.BC05A0F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, i have network setup with 3 gateways and a large number of intranet = nodes, i want to do automatic load balancing with failover, i have put following ip rules and routes, ip rule add prio 222 table 222 ip route add default table 222 proto static \ nexthop via $GWE1 dev $IFE1 \ nexthop via $GWE2 dev $IFE2 \ nexthop via $GWE2 dev $IFE3 \ Now, i also want to do failover, but the point is that what shall i need to do about deleting the route = cache as soon as some gateway becomes dead or unavailable, what the system will do on its own and what we need to do for this, i need a help, please guide me, thanx in advance, Regards, ---------------------------------------------------------------- Tushar Thakker Elitecore Technologies Ltd. Ph: 9824080066 / 6405600 Ext-535 ---------------------------------------------------------------- Life gives all that one deserves, but not all that one desires... ---------------------------------------------------------------- ------=_NextPart_000_004B_01C3D120.BC05A0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
i have network setup with 3 gateways = and a large=20 number of intranet nodes,
i want to do automatic load balancing = with=20 failover,
i have put following ip rules and=20 routes,
 
        ip rule=20 add prio 222 table 222
        ip = route=20 add default table 222 proto static=20 \
           &n= bsp;   =20 nexthop via $GWE1 dev $IFE1=20 \
           &n= bsp;   =20 nexthop via $GWE2 dev $IFE2 \
          &nbs= p;    =20 nexthop via $GWE2 dev $IFE3 \
Now, i also want to do = failover,
but the point is that what shall i need = to do about=20 deleting the route cache as soon as some gateway becomes dead or=20 unavailable,
what the system will do on its own and = what we need=20 to do for this,
i need a help,
please guide me,
thanx in advance,
Regards,
 
----------------------------------------------------------------=
Tushar=20 Thakker
Elitecore Technologies Ltd.
Ph: 9824080066 / 6405600=20 Ext-535
--------------------------------------------------------------= --
Life=20 gives all that one deserves, but not all that one=20 desires...
-----------------------------------------------------------= -----
------=_NextPart_000_004B_01C3D120.BC05A0F0-- From steen@suder.dk Fri Jan 2 13:46:10 2004 From: steen@suder.dk (Steen Suder, privat) Date: Fri, 02 Jan 2004 14:46:10 +0100 Subject: [LARTC] Load balancing with failover In-Reply-To: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> References: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> Message-ID: <3FF57622.8030003@suder.dk> Tushar Thakker wrote: > Hi all, > i have network setup with 3 gateways and a large number of intranet nodes, > i want to do automatic load balancing with failover, > i have put following ip rules and routes, > > ip rule add prio 222 table 222 > ip route add default table 222 proto static \ > nexthop via $GWE1 dev $IFE1 \ > nexthop via $GWE2 dev $IFE2 \ > nexthop via $GWE2 dev $IFE3 \ > > Now, i also want to do failover, > but the point is that what shall i need to do about deleting the route cache as soon as some gateway becomes dead or unavailable, > what the system will do on its own and what we need to do for this, > i need a help, AFAIK, You'd have to look at Julian's routepatch(es): . Search for "Dead Gateway Detection". It may not be the entire solution, but a step in the right direction. -- Mvh. / Best regards, Steen Suder ICQ UIN 4133803 From andybr@bol.com.br Fri Jan 2 12:59:57 2004 From: andybr@bol.com.br (Anderson O Muniz) Date: Fri, 2 Jan 2004 10:59:57 -0200 Subject: [LARTC] Load balancing with failover References: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> Message-ID: <004201c3d130$538c87e0$16c8a8c0@honeyids> This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C3D11F.8F463440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Put a script to monitor a gateway with crond job and if it fails = automatically change to gateway 2, you gotta it? []'s Anderson ----- Original Message -----=20 From: Tushar Thakker=20 To: lartc@mailman.ds9a.nl=20 Sent: Friday, January 02, 2004 5:08 PM Subject: [LARTC] Load balancing with failover Hi all, i have network setup with 3 gateways and a large number of intranet = nodes, i want to do automatic load balancing with failover, i have put following ip rules and routes, ip rule add prio 222 table 222 ip route add default table 222 proto static \ nexthop via $GWE1 dev $IFE1 \ nexthop via $GWE2 dev $IFE2 \ nexthop via $GWE2 dev $IFE3 \ Now, i also want to do failover, but the point is that what shall i need to do about deleting the route = cache as soon as some gateway becomes dead or unavailable, what the system will do on its own and what we need to do for this, i need a help, please guide me, thanx in advance, Regards, ---------------------------------------------------------------- Tushar Thakker Elitecore Technologies Ltd. Ph: 9824080066 / 6405600 Ext-535 ---------------------------------------------------------------- Life gives all that one deserves, but not all that one desires... ---------------------------------------------------------------- ------=_NextPart_000_003F_01C3D11F.8F463440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Put a script to monitor a gateway with = crond job=20 and if it fails automatically change to gateway 2, you gotta = it?
 
[]'s
Anderson
 
----- Original Message -----
From:=20 Tushar Thakker
To: lartc@mailman.ds9a.nl
Sent: Friday, January 02, 2004 = 5:08=20 PM
Subject: [LARTC] Load balancing = with=20 failover

Hi all,
i have network setup with 3 gateways = and a large=20 number of intranet nodes,
i want to do automatic load balancing = with=20 failover,
i have put following ip rules and=20 routes,
 
        ip=20 rule add prio 222 table = 222
        ip=20 route add default table 222 proto static=20 = \
           &n= bsp;   =20 nexthop via $GWE1 dev $IFE1=20 = \
           &n= bsp;   =20 nexthop via $GWE2 dev $IFE2 \
          &nbs= p;    =20 nexthop via $GWE2 dev $IFE3 \
Now, i also want to do = failover,
but the point is that what shall i = need to do=20 about deleting the route cache as soon as some gateway becomes dead or = unavailable,
what the system will do on its own = and what we=20 need to do for this,
i need a help,
please guide me,
thanx in advance,
Regards,
 
----------------------------------------------------------------=
Tushar=20 Thakker
Elitecore Technologies Ltd.
Ph: 9824080066 / 6405600=20 = Ext-535
--------------------------------------------------------------= --
Life=20 gives all that one deserves, but not all that one=20 = desires...
-----------------------------------------------------------= -----
------=_NextPart_000_003F_01C3D11F.8F463440-- From Jurrie Overgoor" <004201c3d130$538c87e0$16c8a8c0@honeyids> Message-ID: <010601c3d149$77cc95a0$0100a8c0@RADON> > Put a script to monitor a gateway with crond job and if it fails > automatically change to gateway 2, you gotta it? Does that address the problem of routes being cached? Greetz -- Jurrie jurrie.overgoor@zonnet.nl From eric@regit.org Fri Jan 2 16:02:21 2004 From: eric@regit.org (Eric Leblond) Date: Fri, 02 Jan 2004 17:02:21 +0100 Subject: [LARTC] Load balancing with failover In-Reply-To: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> References: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> Message-ID: <1073059340.4917.114.camel@tech004.alphalink.fr> --=-xCixgWwoczboLryEiCKO Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Le ven 02/01/2004 =E0 20:08, Tushar Thakker a =E9crit : > Hi all, > i have network setup with 3 gateways and a large number of intranet > nodes, > i want to do automatic load balancing with failover, One find way to do this is to use a combination of : - nth : http://www.netfilter.org/documentation/pomlist/pom-base.html#nth - condition : http://www.netfilter.org/documentation/pomlist/pom-extra.html#condition - CONNMARK : http://www.netfilter.org/documentation/pomlist/pom-extra.html#CONNMARK - iproute2 the first three are patch available in patch-o-matic from netfilter, see provided link for explanation. The idea is the following : let say that we've got a link A at 512 and a link B at 1024 kbits. I want to have twice the number of connection on B as on A to really use link B so i set a counter with 3 slots, I fed slots 0 and 2 to B and slots 1 to A. iptables -t mangle -A FORWARD -m state --state NEW NEW -m nth --counter 1 \ --every 3 --packet 0 -j MARK --set-mark 0x1 iptables -t mangle -A FORWARD -m state --state NEW -m nth --counter 1 \ --every 3 --packet 1 -j MARK --set-mark 0x2 iptables -t mangle -A FORWARD -m state --state NEW -m nth --counter 1 \ --every 3 --packet 1 -j MARK --set-mark 0x1 You need to restore and save the mark with connmark to have mark follow connection and tcp session coming from the same IP. Next route mark 0x1 on link B and route 0x2 on link A (use ip rules and diferrent routing tables) Here you've got a good load-balancing. Next thing use condition on each line to have packet being marked only if the corresponding link is detected as UP (else marked it with the other link mark if it is itself not down). To test if the link is up you'll have to write a simple daemon which ping gateway and set the corresponding condition to 0 or 1 if link is down or up. BR, --=20 Eric Leblond NuFW, Now User Filtering Works (http://www.nufw.org) --=-xCixgWwoczboLryEiCKO Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/9ZYMnxA7CdMWjzIRAq03AJ41R8cCIgsPr4wBQn2qk2o/Z6MzCwCbBSMG Iz0Kdgvz86Q8a4ZXUQBbJvw= =/X/i -----END PGP SIGNATURE----- --=-xCixgWwoczboLryEiCKO-- From brooney@xcommunications.co.uk Fri Jan 2 22:01:56 2004 From: brooney@xcommunications.co.uk (Barry Rooney) Date: Fri, 2 Jan 2004 22:01:56 -0000 Subject: [LARTC] Bandwidth Analysis Message-ID: <001d01c3d17c$09a787f0$0a01000a@xcom1> This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C3D17C.09674AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Can anyone recommend an opensource bandwidth monitoring tool that can = plot throughtput and breakdown into sockets/services for proving the performance of my qdiscs? Many thanks Barry. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.555 / Virus Database: 347 - Release Date: 23/12/2003 ------=_NextPart_000_001A_01C3D17C.09674AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
Can anyone recommend an opensource = bandwidth=20 monitoring tool that can plot throughtput and breakdown into=20 sockets/services
for proving the performance of my=20 qdiscs?
 
Many thanks
 
Barry.
 
 

---
Outgoing mail is certified = Virus=20 Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.555 /=20 Virus Database: 347 - Release Date: = 23/12/2003
------=_NextPart_000_001A_01C3D17C.09674AA0-- From roy@xxx.lt Sat Jan 3 00:24:07 2004 From: roy@xxx.lt (Roy) Date: Sat, 3 Jan 2004 02:24:07 +0200 Subject: [LARTC] low delay stuff.. References: <20031224192245.02cc3dcd.raptor@tvskat.net> Message-ID: <015f01c3d18f$e67e20e0$030aa8c0@t> I think all htb shaper is based in this idea shaper do not drop packets it just queues them and dequeues acording priority and bandwitch if there is no space in queue then forwarded packet wil be lost what can you suggest better? what do you mean with "shortened network-path" I think it is exactly bad that htb is optimized for speed and not for functionality. > i was thinking is there a way to include some mechanism > for high priority selection&queueing mechnism... so that we can > get better support for low-delay traffic.. > Every now and then I see a question on the list, how to handle > video&audio&game traffic, and no definitive answer to this question.. > There has to be solution :"), let me tell i'm not a c-programmer so i cant do that, > but think there is a way to achieve this in not so hard way...my proposal is > to make something similar to the way cisco do it..i.e. > Have one high priority queue/class that have higher priority over the other classes, > probably we can do this now but it is not made as exception i.e. depends from > your setup, what other classes do u have...etc... > > My idea is to have an exception for this super class with shortened "network-path", > so that we get lower possible delays.. i thik in cisco they called it priority-queue > > Is such thing feasable or it can be acomplished with current qdiscs and > work even under heavy load with thousand of classes... > > > tia > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From tusharthakker@elitecore.com Sat Jan 3 19:42:42 2004 From: tusharthakker@elitecore.com (Tushar Thakker) Date: Sat, 3 Jan 2004 11:42:42 -0800 Subject: [LARTC] Re: Load balancing with failover References: <20040103060204.10513.3161.Mailman@outpost.ds9a.nl> Message-ID: <006901c3d231$c0a49d70$3301a8c0@elitecore1> hi Steen, i want to know that does the julian's patch provide automatic cache deletion and logging in case of failover? this would help me much, thanx, regards, ----------------------------------------------------------Tushar Thakker Elitecore Technologies Ltd. --------------------------------------------------------------- Original Message ----- From: To: Sent: Friday, January 02, 2004 10:02 PM Subject: LARTC digest, Vol 1 #1519 - 6 msgs > 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: Load balancing with failover (Steen Suder, privat) > 2. Re: Load balancing with failover (Anderson O Muniz) > 3. Re: Load balancing with failover (Jurrie Overgoor) > 4. Re: Load balancing with failover (Eric Leblond) > 5. Bandwidth Analysis (Barry Rooney) > 6. Re: low delay stuff.. (Roy) > > --__--__-- > > Message: 1 > Date: Fri, 02 Jan 2004 14:46:10 +0100 > From: "Steen Suder, privat" > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Load balancing with failover > > Tushar Thakker wrote: > > Hi all, > > i have network setup with 3 gateways and a large number of intranet nodes, > > i want to do automatic load balancing with failover, > > i have put following ip rules and routes, > > > > ip rule add prio 222 table 222 > > ip route add default table 222 proto static \ > > nexthop via $GWE1 dev $IFE1 \ > > nexthop via $GWE2 dev $IFE2 \ > > nexthop via $GWE2 dev $IFE3 \ > > > > Now, i also want to do failover, > > but the point is that what shall i need to do about deleting the route cache as soon as some gateway becomes dead or unavailable, > > what the system will do on its own and what we need to do for this, > > i need a help, > > AFAIK, You'd have to look at Julian's routepatch(es): > . > > Search for "Dead Gateway Detection". > > It may not be the entire solution, but a step in the right direction. > > -- > Mvh. / Best regards, > Steen Suder > ICQ UIN 4133803 > > > --__--__-- > > Message: 2 > From: "Anderson O Muniz" > To: > Subject: Re: [LARTC] Load balancing with failover > Date: Fri, 2 Jan 2004 10:59:57 -0200 > > This is a multi-part message in MIME format. > > ------=_NextPart_000_003F_01C3D11F.8F463440 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi, > > Put a script to monitor a gateway with crond job and if it fails = > automatically change to gateway 2, you gotta it? > > []'s > Anderson > > ----- Original Message -----=20 > From: Tushar Thakker=20 > To: lartc@mailman.ds9a.nl=20 > Sent: Friday, January 02, 2004 5:08 PM > Subject: [LARTC] Load balancing with failover > > > Hi all, > i have network setup with 3 gateways and a large number of intranet = > nodes, > i want to do automatic load balancing with failover, > i have put following ip rules and routes, > > ip rule add prio 222 table 222 > ip route add default table 222 proto static \ > nexthop via $GWE1 dev $IFE1 \ > nexthop via $GWE2 dev $IFE2 \ > nexthop via $GWE2 dev $IFE3 \ > > Now, i also want to do failover, > but the point is that what shall i need to do about deleting the route = > cache as soon as some gateway becomes dead or unavailable, > what the system will do on its own and what we need to do for this, > i need a help, > please guide me, > thanx in advance, > Regards, > > ---------------------------------------------------------------- > Tushar Thakker > Elitecore Technologies Ltd. > Ph: 9824080066 / 6405600 Ext-535 > ---------------------------------------------------------------- > Life gives all that one deserves, but not all that one desires... > ---------------------------------------------------------------- > > ------=_NextPart_000_003F_01C3D11F.8F463440 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Diso-8859-1"> > > > > >
Hi,
>
 
>
Put a script to monitor a gateway with = > crond job=20 > and if it fails automatically change to gateway 2, you gotta = > it?
>
 
>
[]'s
>
Anderson
>
 
>
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = > BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> >
----- Original Message -----
> style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = > black">From:=20 > href=3D"mailto:tusharthakker@elitecore.com">Tushar Thakker > >
Sent: Friday, January 02, 2004 = > 5:08=20 > PM
>
Subject: [LARTC] Load balancing = > with=20 > failover
>

>
Hi all,
>
i have network setup with 3 gateways = > and a large=20 > number of intranet nodes,
>
i want to do automatic load balancing = > with=20 > failover,
>
i have put following ip rules and=20 > routes,
>
 
>
size=3D2>        ip=20 > rule add prio 222 table = > 222
        ip=20 > route add default table 222 proto static=20 > = > \
           &n= > bsp;   =20 > nexthop via $GWE1 dev $IFE1=20 > = > \
           &n= > bsp;   =20 > nexthop via $GWE2 dev $IFE2 \
>
= > size=3D2>          &nbs= > p;    =20 > nexthop via $GWE2 dev $IFE3 \
>
Now, i also want to do = > failover,
>
but the point is that what shall i = > need to do=20 > about deleting the route cache as soon as some gateway becomes dead or = > > unavailable,
>
what the system will do on its own = > and what we=20 > need to do for this,
>
i need a help,
>
please guide me,
>
thanx in advance,
>
Regards,
>
 
>
= > size=3D2>----------------------------------------------------------------= >
Tushar=20 > Thakker
Elitecore Technologies Ltd.
Ph: 9824080066 / 6405600=20 > = > Ext-535
--------------------------------------------------------------= > --
Life=20 > gives all that one deserves, but not all that one=20 > = > desires...
-----------------------------------------------------------= > -----
> > ------=_NextPart_000_003F_01C3D11F.8F463440-- > > > --__--__-- > > Message: 3 > Reply-To: "Jurrie Overgoor" > From: "Jurrie Overgoor" > To: "Anderson O Muniz" , > Subject: Re: [LARTC] Load balancing with failover > Date: Fri, 2 Jan 2004 16:59:56 +0100 > > > Put a script to monitor a gateway with crond job and if it fails > > automatically change to gateway 2, you gotta it? > > Does that address the problem of routes being cached? > > Greetz -- Jurrie > jurrie.overgoor@zonnet.nl > > > --__--__-- > > Message: 4 > Subject: Re: [LARTC] Load balancing with failover > From: Eric Leblond > To: Tushar Thakker > Cc: lartc@mailman.ds9a.nl > Organization: Regit.org > Date: Fri, 02 Jan 2004 17:02:21 +0100 > > > --=-xCixgWwoczboLryEiCKO > Content-Type: text/plain; charset=iso-8859-15 > Content-Transfer-Encoding: quoted-printable > > Le ven 02/01/2004 =E0 20:08, Tushar Thakker a =E9crit : > > Hi all, > > i have network setup with 3 gateways and a large number of intranet > > nodes, > > i want to do automatic load balancing with failover, > > One find way to do this is to use a combination of : > - nth : > http://www.netfilter.org/documentation/pomlist/pom-base.html#nth > - condition : > http://www.netfilter.org/documentation/pomlist/pom-extra.html#condition > - CONNMARK : > http://www.netfilter.org/documentation/pomlist/pom-extra.html#CONNMARK > - iproute2 > > the first three are patch available in patch-o-matic from netfilter, see > provided link for explanation. > > The idea is the following : > let say that we've got a link A at 512 and a link B at 1024 kbits. > I want to have twice the number of connection on B as on A to really use > link B so i set a counter with 3 slots, I fed slots 0 and 2 to B and > slots 1 to A. > iptables -t mangle -A FORWARD -m state --state NEW NEW -m nth --counter > 1 \ > --every 3 --packet 0 -j MARK --set-mark 0x1 > iptables -t mangle -A FORWARD -m state --state NEW -m nth --counter 1 \ > --every 3 --packet 1 -j MARK --set-mark 0x2 > iptables -t mangle -A FORWARD -m state --state NEW -m nth --counter 1 \ > --every 3 --packet 1 -j MARK --set-mark 0x1 > You need to restore and save the mark with connmark to have mark follow > connection and tcp session coming from the same IP. > > Next route mark 0x1 on link B and route 0x2 on link A (use ip rules and > diferrent routing tables) > > Here you've got a good load-balancing. > > Next thing use condition on each line to have packet being marked only > if the corresponding link is detected as UP (else marked it with the > other link mark if it is itself not down). To test if the link is up > you'll have to write a simple daemon which ping gateway and set the > corresponding condition to 0 or 1 if link is down or up. > > BR, > --=20 > Eric Leblond > NuFW, Now User Filtering Works (http://www.nufw.org) > > --=-xCixgWwoczboLryEiCKO > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: Ceci est une partie de message > =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?= > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQA/9ZYMnxA7CdMWjzIRAq03AJ41R8cCIgsPr4wBQn2qk2o/Z6MzCwCbBSMG > Iz0Kdgvz86Q8a4ZXUQBbJvw= > =/X/i > -----END PGP SIGNATURE----- > > --=-xCixgWwoczboLryEiCKO-- > > > --__--__-- > > Message: 5 > From: "Barry Rooney" > To: > Date: Fri, 2 Jan 2004 22:01:56 -0000 > Subject: [LARTC] Bandwidth Analysis > > This is a multi-part message in MIME format. > > ------=_NextPart_000_001A_01C3D17C.09674AA0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi All, > Can anyone recommend an opensource bandwidth monitoring tool that can = > plot throughtput and breakdown into sockets/services > for proving the performance of my qdiscs? > > Many thanks > > Barry. > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.555 / Virus Database: 347 - Release Date: 23/12/2003 > ------=_NextPart_000_001A_01C3D17C.09674AA0 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Diso-8859-1"> > > > > >
Hi All,
>
Can anyone recommend an opensource = > bandwidth=20 > monitoring tool that can plot throughtput and breakdown into=20 > sockets/services
>
for proving the performance of my=20 > qdiscs?
>
 
>
Many thanks
>
 
>
Barry.
>
 
>
 
>

---
Outgoing mail is certified = > Virus=20 > Free.
Checked by AVG anti-virus system ( href=3D"http://www.grisoft.com">http://www.grisoft.com).
Version: = > 6.0.555 /=20 > Virus Database: 347 - Release Date: = > 23/12/2003
> > ------=_NextPart_000_001A_01C3D17C.09674AA0-- > > > --__--__-- > > Message: 6 > From: "Roy" > To: > Subject: Re: [LARTC] low delay stuff.. > Date: Sat, 3 Jan 2004 02:24:07 +0200 > > > I think all htb shaper is based in this idea > shaper do not drop packets it just queues them and dequeues acording > priority and bandwitch if there is no space in queue then forwarded packet > wil be lost > what can you suggest better? > > what do you mean with "shortened network-path" > > I think it is exactly bad that htb is optimized for speed and not for > functionality. > > > > > i was thinking is there a way to include some mechanism > > for high priority selection&queueing mechnism... so that we can > > get better support for low-delay traffic.. > > Every now and then I see a question on the list, how to handle > > video&audio&game traffic, and no definitive answer to this question.. > > There has to be solution :"), let me tell i'm not a c-programmer so i cant > do that, > > but think there is a way to achieve this in not so hard way...my proposal > is > > to make something similar to the way cisco do it..i.e. > > Have one high priority queue/class that have higher priority over the > other classes, > > probably we can do this now but it is not made as exception i.e. depends > from > > your setup, what other classes do u have...etc... > > > > My idea is to have an exception for this super class with shortened > "network-path", > > so that we get lower possible delays.. i thik in cisco they called it > priority-queue > > > > Is such thing feasable or it can be acomplished with current qdiscs and > > work even under heavy load with thousand of classes... > > > > > > tia > > > > _______________________________________________ > > 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 > > > End of LARTC Digest > From lartc@mailman.ds9a.nl Sun Jan 4 00:48:13 2004 From: lartc@mailman.ds9a.nl (Robert Walker) Date: Sun, 4 Jan 2004 00:48:13 +0000 Subject: [LARTC] IMQ problems :-( In-Reply-To: <20040103060204.10513.3161.Mailman@outpost.ds9a.nl> References: <20040103060204.10513.3161.Mailman@outpost.ds9a.nl> Message-ID: <1045377672.20040104004813@yahoo.co.uk> Hi I have built a custom TMB Mandrake kernel (2.4.22) with IMQ and ESFQ support. I statically compiled both (mistake?) ESFQ is sorted and working fine (I have succesfully patched IPROUTE2). I have got to the stage where I can see the IMQ device as UP with ifconfig. I can use TC to add QDISCs to the IMQ device. However I just cannot sort out IPTABLES to actually redirect packets to the IMQ device!! I have been trying for weeks to sort this problem out and its really helping to develop my Linux Zen awareness... Currently I am trying to patch iptables-1.2.8 with iptables-1.2.7a IMQ patch. I am not getting a .d dependency file for the lipipt_IMQ.c file in the iptables - extensions directory. I think this is because the IMQ patch looks for an ipt_IMQ.c file in directory .../net/ipv4/netfilter/ in my kernel sources. But my kernel source doesn't have this file. This is the common problem for all the older iptables -IMQ patches I have tried. Why don't I have this file in my kernel sources? Is it because I statically linked in supported for IMQ into the kernel? Do I need to recompile the kernel with IMQ selected as a module?? I am very new to Linux so these patches for this and patches for that plus something called 'patch-o-matic' are all getting a bit.... Yours in patchyness... Robert From roy@xxx.lt Sun Jan 4 02:12:16 2004 From: roy@xxx.lt (Roy) Date: Sun, 4 Jan 2004 04:12:16 +0200 Subject: [LARTC] IMQ problems :-( References: <20040103060204.10513.3161.Mailman@outpost.ds9a.nl> <1045377672.20040104004813@yahoo.co.uk> Message-ID: <004d01c3d268$2d2447d0$030aa8c0@t> Imq is very invasive componemt which requires to recompile almost everyhing this diver is very unstable and will crash for sure, sooner or later depending on load. I sugest you to leave iptables alone and just modify imq.c source to catch what you need. ir you dont have too much trafic it may not crash for all day. ( if you will use it for download shaping) From jayesh_rathod@sify.com Sun Jan 4 06:27:21 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Sun, 04 Jan 2004 12:27:21 +0600 (IST) Subject: [LARTC] HTB filters - pls help me Message-ID: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> Hi, we r using HTB algorithm,for traffic shaping, we are facing a problem. we are able to create multiple classes,filters. But when we delete 1 filter all filter gets deleted. how do we avoid that. waiting for you reply Regards Jayesh ------------------------------------------------- Shop & Save at Sifymall.com! Special Festive Offers - up to 60% off on DVD players, MP3 Players. Mobile phones and more. Click here: http://sify.com/deals From saptah2000@yahoo.es Sun Jan 4 11:30:40 2004 From: saptah2000@yahoo.es (saptah) Date: Sun, 04 Jan 2004 12:30:40 +0100 Subject: [LARTC] problem whith htb script Message-ID: <1073215840.582.16.camel@debian> Hi all && happy new Year ;) I'm try to made a script for shaping my outgoing traffic, but it doesn't work fine. The script work good if all packets go thru the default class, but, if I try to send packets by other class, the packes doesn't go by this class go also by the default class. This script is installed in a router linux with ip masquerading for the clients. ¿how I can classify the packets in this classes? thx 4 all ;) and sorry for my (bad) english :P ##### My script ###### #!/bin/bash #QoS ;)= DEV=eth1 RATEUP=100 #En KiloBytes # borro las bandas tc qdisc del dev $DEV root 2> /dev/null > /dev/null tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null tc qdisc del dev $DEV root 2> /dev/null > /dev/null iptables -F #también las relgas iptables #creacion del arbol de bandas tc qdisc add dev $DEV root handle 2: htb default 60 tc class add dev $DEV parent 2: classid 2:1 htb rate 120kbps ceil ${RATEUP}kbps tc class add dev $DEV parent 2:5 classid 2:50 htb rate $[70*$RATEUP/100]kbps ceil ${RATEUP}kbps tc class add dev $DEV parent 2:6 classid 2:60 htb rate $[20*$RATEUP/100]kbps ceil ${RATEUP}kbps prio 1 tc class add dev $DEV parent 2:7 classid 2:70 htb rate $[10*$RATEUP/100]kbps ceil ${RATEUP}kbps prio 2 #asociacion de colas sfq con bandas tc qdisc add dev $DEV parent 2:50 handle 50: sfq tc qdisc add dev $DEV parent 2:60 handle 60: sfq tc qdisc add dev $DEV parent 2:70 handle 70: sfq #se asocian marcas con bandas tc filter add dev $DEV protocol ip parent 2: handle 5 fw classid 2:50 tc filter add dev $DEV protocol ip parent 2: handle 6 fw classid 2:60 tc filter add dev $DEV protocol ip parent 2: handle 7 fw classid 2:70 #reglas de filtrado #tc filter add dev $DEV parent 2: protocol ip prio 0 u32 match ip dport 21 0xffff flowid 2:50 #envia algo #tc filter add dev $DEV parent 2: protocol ip prio 0 u32 match ip dport 20 0xffff flowid 2:50 #envia algo From lartc@mailman.ds9a.nl Sun Jan 4 15:47:09 2004 From: lartc@mailman.ds9a.nl (Robert Walker) Date: Sun, 4 Jan 2004 15:47:09 +0000 Subject: [LARTC] IMQ problems :-( In-Reply-To: <20040104060557.3690.88353.Mailman@outpost.ds9a.nl> References: <20040104060557.3690.88353.Mailman@outpost.ds9a.nl> Message-ID: <219601369.20040104154709@yahoo.co.uk> Hi Roy, Thanks for getting back to me so promptly. > Imq is very invasive componemt which requires to recompile almost everyhing > this diver is very unstable and will crash for sure, sooner or later > depending on load. I have read about people having lots of problems with IMQ. So I just wanted to try it and see how stable it is on my box. I gather it could actually be problems with the Kernel and not the IMQ code?? > I sugest you to leave iptables alone and just modify imq.c source to catch > what you need. > ir you dont have too much trafic it may not crash for all day. ( if you will > use it for download shaping) I think that sounds even more messy :-) I only wanted to ingress shape with IMQ to ensure that I don't drop UDP or small TCP ACK packets for upload streams. I guess I will just give up on the idea and using ingress policing... Its not so important anyway as my DSL connection is very asymetric (2mbit D/L & 256kbit U/L) and upload shaping is more important. Even if IMQ is fixed in kernel 2.6 (is it??) I won't be able to use it until I can update the driver for my conexant PCI ADSL modem (which works fine just now under kernel 2.4.22).... -- Best regards, Robert From roy@xxx.lt Sun Jan 4 17:33:11 2004 From: roy@xxx.lt (Roy) Date: Sun, 4 Jan 2004 19:33:11 +0200 Subject: [LARTC] IMQ problems :-( References: <20040104060557.3690.88353.Mailman@outpost.ds9a.nl> <219601369.20040104154709@yahoo.co.uk> Message-ID: <002301c3d2e8$d3885a00$030aa8c0@t> > I have read about people having lots of problems with IMQ. So I just wanted to > try it and see how stable it is on my box. I gather it could actually > be problems with the Kernel and not the IMQ code?? > That is possible but prpbably not because of bug in kernel I as I think it is because kernel handles local trafic diferently than forwarded so you cant use imq to shape trafic generated by server I am comtinuing development of imq abd I face this problem most of the time. > I think that sounds even more messy :-) > I only wanted to ingress shape with IMQ to ensure that I don't drop UDP > or small TCP ACK packets for upload streams. I guess I will just give > up on the idea and using ingress policing... Its not so important anyway as my > DSL connection is very asymetric (2mbit D/L; 256kbit U/L) and upload > shaping is more important. > if only want to shape incoming trafic probably you can use imq quite safely, anyway as I see you dont need it at all you can easily shape all uploads anyway and since your download speed is high enough you dont need to worry about it. however imq can be usefull to control trafic so that you can download with kaza and browse web or play game without high latency. From gdh@acentral.co.uk Sun Jan 4 18:49:47 2004 From: gdh@acentral.co.uk (Gavin Hamill) Date: Sun, 4 Jan 2004 18:49:47 +0000 Subject: [LARTC] Ingress with WonderShaper Message-ID: <200401041849.47701.gdh@acentral.co.uk> Hullo :) I appear to be having a common problem, but the standard fix hasn't worked for me :/ I'm using a 2.4.23 kernel, with QoS options thusly: # QoS and/or fair queueing # CONFIG_NET_SCHED=y # CONFIG_NET_SCH_CBQ is not set CONFIG_NET_SCH_HTB=m # CONFIG_NET_SCH_CSZ is not set CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set CONFIG_NET_CLS_POLICE=y The whole wshaper.htb script executes fine until the final two commands, and running the first one manually gives me: $ tc qdisc add dev eth0 handle ffff: ingress RTNETLINK answers: Invalid argument Now, the standard solution I've seen is "get a newer tc", and one report [1] said that Debian's unstable one worked fine... so I backported it to woody, but had exactly the same problem :/ I even saw the q_ingress.c and q_htb.c files being compiled OK during the 'debian/rules binary-arch' procedure so the code must be in the tc binary. If I mis-type 'ingress', then the error changes to "RTNETLINK answers: No such file or directory" so it must be seeing /something/ ... Any ideas? :D Cheers, Gavin. [1] http://www.cs.helsinki.fi/linux/linux-kernel/2002-06/0035.html From stef.coene@docum.org Sun Jan 4 18:44:32 2004 From: stef.coene@docum.org (Stef Coene) Date: Sun, 4 Jan 2004 19:44:32 +0100 Subject: [LARTC] problem whith htb script In-Reply-To: <1073215840.582.16.camel@debian> References: <1073215840.582.16.camel@debian> Message-ID: <200401041944.32047.stef.coene@docum.org> On Sunday 04 January 2004 12:30, saptah wrote: > Hi all && happy new Year ;) > > I'm try to made a script for shaping my outgoing traffic, but it doesn't > work fine. > The script work good if all packets go thru the default class, but, if I > try to send packets by other class, the packes doesn't go by this class > go also by the default class. > > This script is installed in a router linux with ip masquerading for the > clients. > > =BFhow I can classify the packets in this classes? > > thx 4 all ;) and sorry for my (bad) english :P No problem. Are you trying to match ftp traffic? Is so, you can have a problem because= =20 ftp can use dynamic ports. So it's not easy to filter out ftp traffic. You also use a combination of fw and u32 filter. But for that fw filter, I= =20 don't see the needed iptables rules. Stef =2D-=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Sun Jan 4 18:41:53 2004 From: stef.coene@docum.org (Stef Coene) Date: Sun, 4 Jan 2004 19:41:53 +0100 Subject: [LARTC] HTB filters - pls help me In-Reply-To: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> References: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> Message-ID: <200401041941.53005.stef.coene@docum.org> On Sunday 04 January 2004 07:27, jayesh rathod wrote: > Hi, > > we r using HTB algorithm,for traffic shaping, we are facing a problem. > > we are able to create multiple classes,filters. But when we delete 1 filter > all filter gets deleted. how do we avoid that. > > waiting for you reply What I do, is creating a script that delets the root qdisc and re-add everything. Deleting the root qdisc delets all classes and filters. So I never delete a filter. Anyway, can you post your commands ? Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From andrius@andrius.org Sun Jan 4 19:13:57 2004 From: andrius@andrius.org (Andrius Kazimieras =?iso-8859-13?q?Kasparavi=E8ius?=) Date: Sun, 4 Jan 2004 21:13:57 +0200 Subject: [LARTC] QoS with > 1 interface Message-ID: <200401042113.57805.andrius@andrius.org> hi, as far I know, iproute QoS works in interface, not in all interfaces. I= =20 want give one inner interface priority over other inner, like PRIO one IP=20 over other. HOW? =2D-=20 Andrius K. Kasparavi=E8ius From alen@smartnet.ba Mon Jan 5 04:55:30 2004 From: alen@smartnet.ba (alen sarkinovic) Date: Sun, 4 Jan 2004 20:55:30 -0800 Subject: [LARTC] virtual interface References: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> <200401041941.53005.stef.coene@docum.org> Message-ID: <001601c3d348$25749810$b8a14150@dijana> can i add HTB rule on virtual interface\ example: eth0:0 alens ----- Original Message ----- From: "Stef Coene" To: "jayesh rathod" ; Sent: Sunday, January 04, 2004 10:41 AM Subject: Re: [LARTC] HTB filters - pls help me > On Sunday 04 January 2004 07:27, jayesh rathod wrote: > > Hi, > > > > we r using HTB algorithm,for traffic shaping, we are facing a problem. > > > > we are able to create multiple classes,filters. But when we delete 1 filter > > all filter gets deleted. how do we avoid that. > > > > waiting for you reply > What I do, is creating a script that delets the root qdisc and re-add > everything. Deleting the root qdisc delets all classes and filters. So I > never delete a filter. > Anyway, can you post your commands ? > > 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 Jan 4 20:11:58 2004 From: roy@xxx.lt (Roy) Date: Sun, 4 Jan 2004 22:11:58 +0200 Subject: [LARTC] QoS with > 1 interface References: <200401042113.57805.andrius@andrius.org> Message-ID: <005d01c3d2ff$020c7490$030aa8c0@t> Labas, What do you mean give priority to interface ? Do you want to route high priority packets to one interface and low priority to other? Or you want to give higer priority to packets forwarded from one interface than from another? hi, as far I know, iproute QoS works in interface, not in all interfaces. I want give one inner interface priority over other inner, like PRIO one IP over other. HOW? -- Andrius K. Kasparavièius From stef.coene@docum.org Sun Jan 4 20:36:13 2004 From: stef.coene@docum.org (Stef Coene) Date: Sun, 4 Jan 2004 21:36:13 +0100 Subject: [LARTC] virtual interface In-Reply-To: <001601c3d348$25749810$b8a14150@dijana> References: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> <200401041941.53005.stef.coene@docum.org> <001601c3d348$25749810$b8a14150@dijana> Message-ID: <200401042136.13915.stef.coene@docum.org> On Monday 05 January 2004 05:55, alen sarkinovic wrote: > can i add HTB rule on virtual interface\ > example: eth0:0 No. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From roy@xxx.lt Sun Jan 4 20:44:37 2004 From: roy@xxx.lt (Roy) Date: Sun, 4 Jan 2004 22:44:37 +0200 Subject: [LARTC] Port limiting on forward References: <3FA803F1.00000C.00972@VARZOSU> Message-ID: <007601c3d303$91762eb0$030aa8c0@t> I heard that matching ports with mangle and shape with CBQ or HTB will cost me some resources so i want to limit that way : 1. On forward I want to limit a port range like 0 to 79 at 8kbps .And after that i want to be able to add lines with other port range , also at 8kbps, but only on forward .Today i had just started to use BBQ and HTB are you so low on resources? or yo want to manage 10000 users? the simple way to do everything that is to mark packets with iptables there is no other way to match port range. also you can know if pcket is forwarded of not by marking it with iptables or by source ip. And how do you use cbq and htb at once? From mabrown-lartc@securepipe.com Sun Jan 4 20:40:36 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Sun, 4 Jan 2004 14:40:36 -0600 (CST) Subject: [LARTC] virtual interface In-Reply-To: <001601c3d348$25749810$b8a14150@dijana> References: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> <200401041941.53005.stef.coene@docum.org> <001601c3d348$25749810$b8a14150@dijana> Message-ID: Alen, : can i add HTB rule on virtual interface? : example: eth0:0 First, it's not really a virtual interface--it's just a convention from the old days of IP aliasing to have names like eth0:0. The IP exists and is active on an interface, eth0 in your case. The short answer is "no". Traffic control occurs just prior to the release of the packet for transmission by the hardware driver. See the KPTD [0]. You can however select packets based on many characteristics, so you may be able to accomplish what you need. You'll use characteristics other than the label "eth0:0". -Martin [0] http://www.docum.org/stef.coene/qos/kptd/ -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From andrius@andrius.org Sun Jan 4 20:52:05 2004 From: andrius@andrius.org (Andrius Kazimieras =?iso-8859-13?q?Kasparavi=E8ius?=) Date: Sun, 4 Jan 2004 22:52:05 +0200 Subject: [LARTC] QoS with > 1 interface In-Reply-To: <005d01c3d2ff$020c7490$030aa8c0@t> References: <200401042113.57805.andrius@andrius.org> <005d01c3d2ff$020c7490$030aa8c0@t> Message-ID: <200401042252.06002.andrius@andrius.org> there is 3 interfaces on router, one - internet, other two - client's. On o= ne=20 interface there is girls lan, on other - boys. I want give higher internet= =20 priority to girls, there is NAT, so ingress resheduling IMO won't work. 2004 m. Sausio 4 d., Sekmadienis 22:11, Roy ra=F0=EB: > Labas, > > What do you mean give priority to interface ? > Do you want to route high priority packets to one interface and low > priority to other? > Or you want to give higer priority to packets forwarded from one interface > than from another? > > > hi, as far I know, iproute QoS works in interface, not in all interfaces.= I > want give one inner interface priority over other inner, like PRIO one IP > over other. HOW? =2D-=20 Andrius K. Kasparavi=E8ius GSM +370 687 256 30 From x11@h2o.pieva.net Sun Jan 4 20:45:09 2004 From: x11@h2o.pieva.net (=?ISO-8859-13?Q?Art=FBras_=D0lajus?=) Date: Sun, 04 Jan 2004 22:45:09 +0200 Subject: [LARTC] QoS with > 1 interface In-Reply-To: <005d01c3d2ff$020c7490$030aa8c0@t> References: <200401042113.57805.andrius@andrius.org> <005d01c3d2ff$020c7490$030aa8c0@t> Message-ID: <3FF87B55.3010201@h2o.pieva.net> Roy wrote: > Labas, > > What do you mean give priority to interface ? > Do you want to route high priority packets to one interface and low priority > to other? > Or you want to give higer priority to packets forwarded from one interface > than from another? I believe that he wants to send packets po some interface as soon as they arrive, not sending packets on other interfaces. From roy@xxx.lt Sun Jan 4 22:06:24 2004 From: roy@xxx.lt (Roy) Date: Mon, 5 Jan 2004 00:06:24 +0200 Subject: [LARTC] Port limiting on forward References: <3FA813B2.000007.00348@VARZOSU> Message-ID: <009e01c3d30e$fea70f30$030aa8c0@t> So what is the problem? create root class /qos/bin/tc qdisc del dev eth0 root /qos/bin/tc qdisc add dev eth0 root handle 2 and add these # mark 23 /qos/bin/tc class add dev eth0 parent 2: classid 2:41 htb rate 8Kbit ceil 8Kbit /qos/bin/tc qdisc add dev eth0 parent 2:41 sfq /qos/bin/tc filter add dev eth0 parent 2: protocol ip pref 4 handle 23 fw classid 2:41 # mark 24 /qos/bin/tc class add dev eth0 parent 2: classid 2:42 htb rate 1000Kbit ceil 1000Kbit /qos/bin/tc qdisc add dev eth0 parent 2:42 sfq /qos/bin/tc filter add dev eth0 parent 2: protocol ip pref 4 handle 24 fw classid 2:42 ----------------------------------------------------- I have 40 Users on P2 200 MMX 32 RAM . So i know how to match packets . iptables -t mangle -N MYSHAPER-OUT iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT iptables -t mangle -A MYSHAPER-OUT -s! 192.168.0.5 -p tcp --dport 0:1024 -j MARK --set-mark 23 iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 6660:65000 -j MARK --set-mark 24 How do i shape mark 23 at 1 KB/s and mark 24 at 1 MB/s ? From roy@xxx.lt Sun Jan 4 22:10:43 2004 From: roy@xxx.lt (Roy) Date: Mon, 5 Jan 2004 00:10:43 +0200 Subject: [LARTC] QoS with > 1 interface References: <200401042113.57805.andrius@andrius.org> <005d01c3d2ff$020c7490$030aa8c0@t> <200401042252.06002.andrius@andrius.org> Message-ID: <00a101c3d30f$98f6b0e0$030aa8c0@t> there is 3 interfaces on router, one - internet, other two - client's. On one interface there is girls lan, on other - boys. I want give higher internet priority to girls, there is NAT, so ingress resheduling IMO won't work. Imq will work there but it will crash anyway ;) imq has nothing to do with ingress except that it can shape it too. there is no way to do this in other way, you can do some shaping by using police index but this way it will not work very well it can probably do this: if girls rate is > x then drop all packets for boys. I suggest you to use only one interface, or you want to separate networks so much. From damion@snapgear.com Mon Jan 5 00:42:51 2004 From: damion@snapgear.com (Damion de Soto) Date: Mon, 05 Jan 2004 10:42:51 +1000 Subject: [LARTC] Ingress with WonderShaper References: <200401041849.47701.gdh@acentral.co.uk> Message-ID: <3FF8B30B.1080700@snapgear.com> Hi Gavin, You're missing the INGRESS option in the kernel, you should have: > # QoS and/or fair queueing > # > CONFIG_NET_SCHED=y > # CONFIG_NET_SCH_CBQ is not set > CONFIG_NET_SCH_HTB=m > # CONFIG_NET_SCH_CSZ is not set > CONFIG_NET_SCH_PRIO=m > CONFIG_NET_SCH_RED=m > CONFIG_NET_SCH_SFQ=m > CONFIG_NET_SCH_TEQL=m > CONFIG_NET_SCH_TBF=m > CONFIG_NET_SCH_GRED=m > CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=y > CONFIG_NET_QOS=y > CONFIG_NET_ESTIMATOR=y > CONFIG_NET_CLS=y > CONFIG_NET_CLS_TCINDEX=m > CONFIG_NET_CLS_ROUTE4=m > CONFIG_NET_CLS_ROUTE=y > CONFIG_NET_CLS_FW=m > CONFIG_NET_CLS_U32=m > # CONFIG_NET_CLS_RSVP is not set > # CONFIG_NET_CLS_RSVP6 is not set > CONFIG_NET_CLS_POLICE=y You'll need the NETFILTER kernel option turned on to be able to see/select the INGRESS option. > I even saw the q_ingress.c and q_htb.c files being compiled OK during the > 'debian/rules binary-arch' procedure so the code must be in the tc binary. > > If I mis-type 'ingress', then the error changes to "RTNETLINK answers: No such > file or directory" so it must be seeing /something/ ... yeah, it looks like the tc binary is right, so once you fix the kernel, everything should work. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 rio@martin.mu Mon Jan 5 02:04:57 2004 From: rio@martin.mu (Rio Martin) Date: Mon, 5 Jan 2004 09:04:57 +0700 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200312311649.36278.lartc@bobich.net> References: <200312311649.36278.lartc@bobich.net> Message-ID: <200401050904.57737.rio@martin.mu> Dear Bobic, I am sure you havent read Lartc Document clearly. Find inside the document, "iproute2" Those are clue for setting up local area network to connect using two or more connections to ISP. Regards, Rio Martin. On Wednesday 31 December 2003 23:49, Gordan Bobic wrote: > Hi. > I have a networking problem that is driving me nuts at the moment. I > have a multi homed network: Cable + DSL. > The problem I have is that although I am 99% sure that I have the > routing table rules set up correctly, for some reason > masqueraded/NATed traffic doesn't go out of the correct interface. > i.e. I am getting traffic leaving eth2 with the source IP header set > to eth3 and vice versa. > There are 3 network interfaces: > eth0 (internal) > eth2 (DSL) > eth3 (Cable) > (eth1 is unused at present) > > Here is my iptables setup (/etc/sysconfig/iptables): > ################################ > # Generated by iptables-save v1.2.7a on Sat Dec 27 10:47:54 2003 > *nat > > :PREROUTING ACCEPT [0:0] > > # Port forwarding to an internal machine > -A PREROUTING -i eth2 -d 217.79.103.2 -p tcp -m tcp --dport 18001 -j > DNAT --to-destination 192.168.0.10:18001 > -A PREROUTING -i eth3 -d 62.252.21.17 -p tcp -m tcp --dport 18001 -j > DNAT --to-destination 192.168.0.10:18001 > # SSH Port Forwarding > -A PREROUTING -i eth2 -d 217.79.103.3 -p tcp -m tcp --dport 22 -j DNAT > --to-destination 192.168.0.10:22 > > :POSTROUTING ACCEPT [0:0] > > # IP Masquerading Traffic From eth2 and eth3 > -A POSTROUTING -o eth2 -j MASQUERADE > -A POSTROUTING -o eth3 -j MASQUERADE > > :OUTPUT ACCEPT [0:0] > > COMMIT > # Completed on Sat Dec 27 10:47:54 2003 > # Generated by iptables-save v1.2.7a on Sat Dec 27 10:47:54 2003 > *filter > > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > > -A FORWARD -i eth0 -o eth2 -s 192.168.0.0/16 -d 0.0.0.0/0 -m state > --state NEW,ESTABLISHED,RELATED -j ACCEPT > -A FORWARD -i eth0 -o eth3 -s 192.168.0.0/16 -d 0.0.0.0/0 -m state > --state NEW,ESTABLISHED,RELATED -j ACCEPT > -A FORWARD -i eth2 -o eth0 -s 0.0.0.0/0 -d 192.168.0.0/16 -m state > --state ESTABLISHED,RELATED -j ACCEPT > -A FORWARD -i eth3 -o eth0 -s 0.0.0.0/0 -d 192.168.0.0/16 -m state > --state ESTABLISHED,RELATED -j ACCEPT > > :OUTPUT ACCEPT [0:0] > > COMMIT > # Completed on Sat Dec 27 10:47:54 2003 > ################################### > > Additionally, here is the script I use to set up the multi homed > routing: > > #################################### > # Add ip rules for routing > ip rule add from 217.79.103.0/29 table Griffin > ip rule add from 62.252.21.17 table NTL > > # Add routing rules for specific interfaces to insure connectivity > ip route add to default via 217.79.103.1 dev eth2 table Griffin > ip route add to default via 62.252.21.254 dev eth3 table NTL > > ip route add to 217.79.103.0/29 dev eth2 table Griffin > ip route add to 62.252.21.0/24 dev eth3 table NTL > > # Default route is multi homed > ip route add to default \ > nexthop via 217.79.103.1 dev eth2 weight 1 \ > nexthop via 62.252.21.254 dev eth3 weight 1 > > # Commit routing changes > ip route flush cache > ############################# > > However, looking at tcpdump output from eth2: > 11:19:27.153771 cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com.18001 > > 217.81.134.183.57626: R 0:0(0) ack 2502579442 win 0 (DF) > 11:19:30.212427 cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com.18001 > > 217.81.134.183.57626: R 0:0(0) ack 1 win 0 (DF) > 11:20:23.928900 cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com.18001 > > 217.81.134.183.58367: R 0:0(0) ack 2551899092 win 0 (DF) > > This is wrong because cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com is > 62.252.21.17, which is the IP address of eth3. > > Similarly, tcpdump from eth3 says things like: > 11:18:32.787404 217.79.103.2.adsl.griffin.net.uk.18001 > > p50811062.dip.t-dialin.net.33062: R 0:0(0) ack 4066315873 win 0 (DF) > 11:18:35.683228 217.79.103.2.adsl.griffin.net.uk.18001 > > p50811062.dip.t-dialin.net.33062: R 0:0(0) ack 1 win 0 (DF) > 11:18:41.744790 217.79.103.2.adsl.griffin.net.uk.18001 > > p50811062.dip.t-dialin.net.33062: R 0:0(0) ack 1 win 0 (DF) > > This is again wrong, because 217.79.103.2.adsl.griffin.net.uk is the > IP address of eth2. > > I am pretty sure the IP rules I set up should work. They assign all > packets with source IP of a particular interface to a routing table > that is routed out via the correct gateway. However, some packets > (from what I have been able to tell, only the masqueraded packets, > but the test was not exhaustive) get sent out of the wrong interface. > > Can anybody see a problem with this setup? > > TIA. > > Gordan > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From rio@martin.mu Mon Jan 5 02:55:06 2004 From: rio@martin.mu (Rio Martin) Date: Mon, 5 Jan 2004 09:55:06 +0700 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401050904.57737.rio@martin.mu> References: <200312311649.36278.lartc@bobich.net> <200401050904.57737.rio@martin.mu> Message-ID: <200401050955.06557.rio@martin.mu> Ooops .. Sorry, i havent read the entire email sent to the list by Bobic. My mistake. Bobic having the problem similar to what i got with one of my server running kernel-2.4.20. All the interface i have are under the same brand (Realtek), eth0 would be for clients, eth1 for DSLCable, eth2 for Wireless 2.4Ghz. Weirdly, several of my clients set up correctly to use both eth1 and eth2, but there are many clients having the wrong route packets just as Bobic. This problem can be solved if i change to use SNAT instead of MASQUERADE. Try it Bobic. This Masquerade problem didnt appeared under my Linux 2.4.21 Regards, Rio Martin. On Monday 05 January 2004 09:04, Rio Martin wrote: > Dear Bobic, > I am sure you havent read Lartc Document clearly. > Find inside the document, "iproute2" > Those are clue for setting up local area network to connect using two or > more connections to ISP. > > Regards, > Rio Martin. > > On Wednesday 31 December 2003 23:49, Gordan Bobic wrote: > > Hi. > > I have a networking problem that is driving me nuts at the moment. I > > have a multi homed network: Cable + DSL. > > The problem I have is that although I am 99% sure that I have the > > routing table rules set up correctly, for some reason > > masqueraded/NATed traffic doesn't go out of the correct interface. > > i.e. I am getting traffic leaving eth2 with the source IP header set > > to eth3 and vice versa. > > There are 3 network interfaces: > > eth0 (internal) > > eth2 (DSL) > > eth3 (Cable) > > (eth1 is unused at present) > > > > Here is my iptables setup (/etc/sysconfig/iptables): > > ################################ > > # Generated by iptables-save v1.2.7a on Sat Dec 27 10:47:54 2003 > > *nat > > > > :PREROUTING ACCEPT [0:0] > > > > # Port forwarding to an internal machine > > -A PREROUTING -i eth2 -d 217.79.103.2 -p tcp -m tcp --dport 18001 -j > > DNAT --to-destination 192.168.0.10:18001 > > -A PREROUTING -i eth3 -d 62.252.21.17 -p tcp -m tcp --dport 18001 -j > > DNAT --to-destination 192.168.0.10:18001 > > # SSH Port Forwarding > > -A PREROUTING -i eth2 -d 217.79.103.3 -p tcp -m tcp --dport 22 -j DNAT > > --to-destination 192.168.0.10:22 > > > > :POSTROUTING ACCEPT [0:0] > > > > # IP Masquerading Traffic From eth2 and eth3 > > -A POSTROUTING -o eth2 -j MASQUERADE > > -A POSTROUTING -o eth3 -j MASQUERADE > > > > :OUTPUT ACCEPT [0:0] > > > > COMMIT > > # Completed on Sat Dec 27 10:47:54 2003 > > # Generated by iptables-save v1.2.7a on Sat Dec 27 10:47:54 2003 > > *filter > > > > :INPUT ACCEPT [0:0] > > :FORWARD ACCEPT [0:0] > > > > -A FORWARD -i eth0 -o eth2 -s 192.168.0.0/16 -d 0.0.0.0/0 -m state > > --state NEW,ESTABLISHED,RELATED -j ACCEPT > > -A FORWARD -i eth0 -o eth3 -s 192.168.0.0/16 -d 0.0.0.0/0 -m state > > --state NEW,ESTABLISHED,RELATED -j ACCEPT > > -A FORWARD -i eth2 -o eth0 -s 0.0.0.0/0 -d 192.168.0.0/16 -m state > > --state ESTABLISHED,RELATED -j ACCEPT > > -A FORWARD -i eth3 -o eth0 -s 0.0.0.0/0 -d 192.168.0.0/16 -m state > > --state ESTABLISHED,RELATED -j ACCEPT > > > > :OUTPUT ACCEPT [0:0] > > > > COMMIT > > # Completed on Sat Dec 27 10:47:54 2003 > > ################################### > > > > Additionally, here is the script I use to set up the multi homed > > routing: > > > > #################################### > > # Add ip rules for routing > > ip rule add from 217.79.103.0/29 table Griffin > > ip rule add from 62.252.21.17 table NTL > > > > # Add routing rules for specific interfaces to insure connectivity > > ip route add to default via 217.79.103.1 dev eth2 table Griffin > > ip route add to default via 62.252.21.254 dev eth3 table NTL > > > > ip route add to 217.79.103.0/29 dev eth2 table Griffin > > ip route add to 62.252.21.0/24 dev eth3 table NTL > > > > # Default route is multi homed > > ip route add to default \ > > nexthop via 217.79.103.1 dev eth2 weight 1 \ > > nexthop via 62.252.21.254 dev eth3 weight 1 > > > > # Commit routing changes > > ip route flush cache > > ############################# > > > > However, looking at tcpdump output from eth2: > > 11:19:27.153771 cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com.18001 > > > 217.81.134.183.57626: R 0:0(0) ack 2502579442 win 0 (DF) > > 11:19:30.212427 cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com.18001 > > > 217.81.134.183.57626: R 0:0(0) ack 1 win 0 (DF) > > 11:20:23.928900 cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com.18001 > > > 217.81.134.183.58367: R 0:0(0) ack 2551899092 win 0 (DF) > > > > This is wrong because cpc4-cbly1-3-0-cust17.glfd.cable.ntl.com is > > 62.252.21.17, which is the IP address of eth3. > > > > Similarly, tcpdump from eth3 says things like: > > 11:18:32.787404 217.79.103.2.adsl.griffin.net.uk.18001 > > > p50811062.dip.t-dialin.net.33062: R 0:0(0) ack 4066315873 win 0 (DF) > > 11:18:35.683228 217.79.103.2.adsl.griffin.net.uk.18001 > > > p50811062.dip.t-dialin.net.33062: R 0:0(0) ack 1 win 0 (DF) > > 11:18:41.744790 217.79.103.2.adsl.griffin.net.uk.18001 > > > p50811062.dip.t-dialin.net.33062: R 0:0(0) ack 1 win 0 (DF) > > > > This is again wrong, because 217.79.103.2.adsl.griffin.net.uk is the > > IP address of eth2. > > > > I am pretty sure the IP rules I set up should work. They assign all > > packets with source IP of a particular interface to a routing table > > that is routed out via the correct gateway. However, some packets > > (from what I have been able to tell, only the masqueraded packets, > > but the test was not exhaustive) get sent out of the wrong interface. > > > > Can anybody see a problem with this setup? > > > > TIA. > > > > Gordan > > _______________________________________________ > > 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 rjm@zenucom.com Mon Jan 5 04:03:58 2004 From: rjm@zenucom.com (Rick Marshall) Date: Mon, 05 Jan 2004 15:03:58 +1100 Subject: [LARTC] vpn control Message-ID: <1073275438.3942.61.camel@znote.zenucom.com> we have an external 2Mbit dsl connection and running on it are several gre vpn tunnels so far i've given priority to the vpn traffic (using htb) can i now put rules in for the tunnels to control traffic within each tunnel (that's where our video conferencing etc runs)? or can i only control the real interface (eth1 in our setup)? if not can i somehow see the packets inside the vpn packets and then control them? thanks rick From damion@snapgear.com Mon Jan 5 05:24:14 2004 From: damion@snapgear.com (Damion de Soto) Date: Mon, 05 Jan 2004 15:24:14 +1000 Subject: [LARTC] vpn control References: <1073275438.3942.61.camel@znote.zenucom.com> Message-ID: <3FF8F4FE.3000702@snapgear.com> Hi Rick, > can i now put rules in for the tunnels to control traffic within each > tunnel (that's where our video conferencing etc runs)? What type of VPNs are you using? IPSec ? You can put htb rules on ipsecX interfaces and they will work. the pppX interfaces for pptp and l2tp VPNs should work just as well. > control the real interface (eth1 in our setup)? if not can i somehow see > the packets inside the vpn packets and then control them? With some clever kernel hackery, you probably could do this, I don't think it would be any fun at all though. 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 damion@snapgear.com Mon Jan 5 06:46:54 2004 From: damion@snapgear.com (Damion de Soto) Date: Mon, 05 Jan 2004 16:46:54 +1000 Subject: [LARTC] vpn control References: <1073275438.3942.61.camel@znote.zenucom.com> <3FF8F4FE.3000702@snapgear.com> <1073283356.5018.5.camel@znote.zenucom.com> Message-ID: <3FF9085E.7090308@snapgear.com> Rick Marshall wrote: > linux-linux using ip tunnels - modprobe ip_gre > > ip tunnel add china mode gre remote xxx.xxx.xxx.xxx local \ > xxx.xxx.xxx.xxx ttl 255 > ip link set china up > ip addr add 192.168.1.11 dev china > ip route add 192.168.5.0/24 dev china Hrrm, not 100% sure on GRE tunnels, but I can't see why they wouldn't. You should be able to just create all your tc rules on the 'china' device. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 rjm@zenucom.com Mon Jan 5 06:15:56 2004 From: rjm@zenucom.com (Rick Marshall) Date: Mon, 05 Jan 2004 17:15:56 +1100 Subject: [LARTC] vpn control In-Reply-To: <3FF8F4FE.3000702@snapgear.com> References: <1073275438.3942.61.camel@znote.zenucom.com> <3FF8F4FE.3000702@snapgear.com> Message-ID: <1073283356.5018.5.camel@znote.zenucom.com> linux-linux using ip tunnels - modprobe ip_gre eg ip tunnel add china mode gre remote xxx.xxx.xxx.xxx local \ xxx.xxx.xxx.xxx ttl 255 ip link set china up ip addr add 192.168.1.11 dev china ip route add 192.168.5.0/24 dev china ps - any hackers - don't bother - the firewalls will only accept connections from specific ip addresses On Mon, 2004-01-05 at 16:24, Damion de Soto wrote: > Hi Rick, > > can i now put rules in for the tunnels to control traffic within each > > tunnel (that's where our video conferencing etc runs)? > What type of VPNs are you using? IPSec ? > You can put htb rules on ipsecX interfaces and they will work. > the pppX interfaces for pptp and l2tp VPNs should work just as well. > > > control the real interface (eth1 in our setup)? if not can i somehow see > > the packets inside the vpn packets and then control them? > With some clever kernel hackery, you probably could do this, I don't think it would > be any fun at all though. > > regards, From hare ram" <200401041941.53005.stef.coene@docum.org> Message-ID: <026f01c3d364$7fb710c0$c2bf09ca@huecal> Hi Stef what happend if already existing people on the class so in the short gap time when we delete and add the rule, is the session will be disconects ? they will get maximum available throughput, when we remove and add, since the IP no more belong to any class but when i re-run the script, they going to same marked and kept in the same class, is this right what happend if so many class like 1000 rules... thanks hare ----- Original Message ----- From: "Stef Coene" To: "jayesh rathod" ; Sent: Monday, January 05, 2004 12:11 AM Subject: Re: [LARTC] HTB filters - pls help me > On Sunday 04 January 2004 07:27, jayesh rathod wrote: > > Hi, > > > > we r using HTB algorithm,for traffic shaping, we are facing a problem. > > > > we are able to create multiple classes,filters. But when we delete 1 filter > > all filter gets deleted. how do we avoid that. > > > > waiting for you reply > What I do, is creating a script that delets the root qdisc and re-add > everything. Deleting the root qdisc delets all classes and filters. So I > never delete a filter. > Anyway, can you post your commands ? > > 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 Aron@sofaware.com Mon Jan 5 09:14:38 2004 From: Aron@sofaware.com (Aron Brand) Date: Mon, 5 Jan 2004 11:14:38 +0200 Subject: [LARTC] virtual interface Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE2DADBF@mail.sofaware.com> >Alen, > > : can i add HTB rule on virtual interface? > : example: eth0:0 > >First, it's not really a virtual interface--it's just a convention from the old days of IP aliasing to have names like eth0:0. =20 > The IP exists and is active on an interface, eth0 in your case. > The short answer is "no". Traffic control occurs just prior to the release of the packet for transmission by the hardware driver. See the KPTD [0]. > > You can however select packets based on many characteristics, so you may be able to accomplish what you need. You'll use characteristics other than the=20 > label "eth0:0". Hi guys, I have this problem too. I have two Internet routers connected to the same Ethernet interface (using a hub). And each one obviously needs to be shaped seperately. It seems like a very common and logical scenario and this issue seems like a design problem. Any Ideas on a workaround? Perhaps IMQ can be used somehow (although I hear it has serious stability problems...)? Aron From gdh@acentral.co.uk Mon Jan 5 09:20:43 2004 From: gdh@acentral.co.uk (Gavin Hamill) Date: Mon, 05 Jan 2004 09:20:43 +0000 Subject: [LARTC] Ingress with WonderShaper In-Reply-To: <3FF8B30B.1080700@snapgear.com> References: <200401041849.47701.gdh@acentral.co.uk> <3FF8B30B.1080700@snapgear.com> Message-ID: <1073294443.1785.1.camel@gdh.walshsimmons.co.uk> On Mon, 2004-01-05 at 00:42, Damion de Soto wrote: > Hi Gavin, > You're missing the INGRESS option in the kernel, > you should have: > CONFIG_NET_SCH_INGRESS=y > You'll need the NETFILTER kernel option turned on to be able to see/select the > INGRESS option. You wonderful man :) I didn't even realise this box didn't have netfilter enabled, so that kills two birds with one stone :) Thanks so much! Cheers, Gavin. From lartc@bobich.net Mon Jan 5 11:17:40 2004 From: lartc@bobich.net (Gordan Bobic) Date: Mon, 5 Jan 2004 11:17:40 +0000 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401050955.06557.rio@martin.mu> References: <200312311649.36278.lartc@bobich.net> <200401050904.57737.rio@martin.mu> <200401050955.06557.rio@martin.mu> Message-ID: <200401051117.40800.lartc@bobich.net> On Monday 05 Jan 2004 02:55, Rio Martin wrote: > Bobic having the problem similar to what i got with one of my server > running kernel-2.4.20. All the interface i have are under the same brand > (Realtek), eth0 would be for clients, eth1 for DSLCable, eth2 for Wireless > 2.4Ghz. Weirdly, several of my clients set up correctly to use both eth1 > and eth2, but there are many clients having the wrong route packets just as > Bobic. > > This problem can be solved if i change to use SNAT instead of MASQUERADE. > Try it Bobic. Hmm. Just replace -j MASQUERADE with -j SNAT? Will that not break other things? > This Masquerade problem didnt appeared under my Linux 2.4.21 So, it is a 2.4.20 kernel problem? I was hoping to avoid home-brewing a kernel again like I did back with my old setup (RH 7.0, 2.2 kernel), and stick with a standard release kernel. Thanks. Gordan From x11@h2o.pieva.net Mon Jan 5 11:28:59 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Mon, 05 Jan 2004 13:28:59 +0200 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401051117.40800.lartc@bobich.net> References: <200312311649.36278.lartc@bobich.net> <200401050904.57737.rio@martin.mu> <200401050955.06557.rio@martin.mu> <200401051117.40800.lartc@bobich.net> Message-ID: <3FF94A7B.2030909@h2o.pieva.net> Gordan Bobic wrote: > Hmm. Just replace -j MASQUERADE with -j SNAT? Will that not break other > things? -j SNAT your_ip man iptables From lartc@bobich.net Mon Jan 5 12:06:57 2004 From: lartc@bobich.net (Gordan Bobic) Date: Mon, 5 Jan 2004 12:06:57 +0000 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401051154.53035.lartc@bobich.net> References: <200312311649.36278.lartc@bobich.net> <3FF94A7B.2030909@h2o.pieva.net> <200401051154.53035.lartc@bobich.net> Message-ID: <200401051206.57266.lartc@bobich.net> On Monday 05 Jan 2004 11:54, Gordan Bobic wrote: > On Monday 05 Jan 2004 11:28, Art=C5=ABras =C5=A0lajus wrote: > > Gordan Bobic wrote: > > > Hmm. Just replace -j MASQUERADE with -j SNAT? Will that not break oth= er > > > things? > > > > -j SNAT your_ip > > Or rather -j SNAT --to-source your_ip. I get it. I'll check if that works > better than masquerading. Just tried it - no difference. Packets still come out with source IP addres= s=20 not matching the interface. :-( Gordan From eddieknows@ananzi.co.za Mon Jan 5 12:46:06 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Mon, 05 Jan 2004 14:46:06 +0200 Subject: [LARTC] Cisco Message-ID: <1073306766.2491.8.camel@testbox.co.za> Hi I know this does not have anything to do with the list But I'm looking for books,doc's or anything on these Cisco exams I looking to do them this year.Please CCNP Exams & Recommended Training Required Exam(s) Recommended Training 642-801 BSCI Building Scalable Cisco Internetworks v2.0 (BSCI) 642-811 BCMSN Building Cisco Multilayer Switched Networks v2.0 (BCMSN) 642-821 BCRAN Building Cisco Remote Access Networks v2.0 (BCRAN) 642-831 CIT Cisco Internetwork Troubleshooting Support v5.0 (CIT) Thanks Eddie From roy@xxx.lt Mon Jan 5 14:29:40 2004 From: roy@xxx.lt (Roy) Date: Mon, 5 Jan 2004 16:29:40 +0200 Subject: [LARTC] virtual interface References: <50F73B338A7FD943B7937BBCF99BFBDE2DADBF@mail.sofaware.com> Message-ID: <002701c3d398$5be4b1f0$030aa8c0@t> There is no need to use imq ant everything is easy to do anyway interface name is usefull only to attach qdisc to something and that all you need to clasify packets by source or destination ip antway if you have idea how to use imq there then just use your interface instead. also why it is so obvious that they must be shaped separately, ususly it is much better to shape everything in one einterface Hi guys, I have this problem too. I have two Internet routers connected to the same Ethernet interface (using a hub). And each one obviously needs to be shaped seperately. It seems like a very common and logical scenario and this issue seems like a design problem. Any Ideas on a workaround? Perhaps IMQ can be used somehow (although I hear it has serious stability problems...)? Aron From lartc@bobich.net Mon Jan 5 11:54:52 2004 From: lartc@bobich.net (Gordan Bobic) Date: Mon, 5 Jan 2004 11:54:52 +0000 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <3FF94A7B.2030909@h2o.pieva.net> References: <200312311649.36278.lartc@bobich.net> <200401051117.40800.lartc@bobich.net> <3FF94A7B.2030909@h2o.pieva.net> Message-ID: <200401051154.53035.lartc@bobich.net> On Monday 05 Jan 2004 11:28, Art=C5=ABras =C5=A0lajus wrote: > Gordan Bobic wrote: > > Hmm. Just replace -j MASQUERADE with -j SNAT? Will that not break other > > things? > > -j SNAT your_ip Or rather -j SNAT --to-source your_ip. I get it. I'll check if that works=20 better than masquerading. Thanks. Gordan From lartc@bobich.net Fri Jan 2 18:52:25 2004 From: lartc@bobich.net (Gordan Bobic) Date: Fri, 2 Jan 2004 18:52:25 +0000 Subject: [LARTC] Load balancing with failover In-Reply-To: <010601c3d149$77cc95a0$0100a8c0@RADON> References: <004e01c3d163$ca39a9d0$3301a8c0@elitecore1> <004201c3d130$538c87e0$16c8a8c0@honeyids> <010601c3d149$77cc95a0$0100a8c0@RADON> Message-ID: <200401021852.25768.lartc@bobich.net> On Friday 02 Jan 2004 3:59 pm, Jurrie Overgoor wrote: > > Put a script to monitor a gateway with crond job and if it fails > > automatically change to gateway 2, you gotta it? > > Does that address the problem of routes being cached? ip route flush cache Gordan From stef.coene@docum.org Mon Jan 5 19:57:33 2004 From: stef.coene@docum.org (Stef Coene) Date: Mon, 5 Jan 2004 20:57:33 +0100 Subject: [LARTC] HTB filters - pls help me In-Reply-To: <026f01c3d364$7fb710c0$c2bf09ca@huecal> References: <1073199441.3ff7b9512bb72@webmail7.maa.sify.net> <200401041941.53005.stef.coene@docum.org> <026f01c3d364$7fb710c0$c2bf09ca@huecal> Message-ID: <200401052057.33841.stef.coene@docum.org> On Monday 05 January 2004 09:18, hare ram wrote: > Hi Stef > > what happend if already existing people on the class > so in the short gap time when we delete and add the rule, > > is the session will be disconects ? I don't know, but I don't think so. The state of the connections exists in kernel space and not in "tc" space. Tc only sees packets. > they will get maximum available throughput, when we remove and add, since > the IP no more belong to any class That only takes a few micro seconds, so I don't bother. > but when i re-run the script, they going to same marked and kept in the > same class, is this right If you use the fw filter + iptables, yes. > what happend if so many class like 1000 rules... I only execute the tc scripts when my router boots or if I changed something. So not evey second. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From andybr@bol.com.br Mon Jan 5 20:32:11 2004 From: andybr@bol.com.br (andybr) Date: Mon, 5 Jan 2004 18:32:11 -0200 Subject: [LARTC] Multihomed Masquerading, routing and iptables Message-ID: Hi all, I dont understando what the problem is, can you explain so i can help you out. []=B4s Anderson > On Monday 05 Jan 2004 02:55, Rio Martin wrote: > > > Bobic having the problem similar to what i got with o ne of my server > > running kernel- 2.4.20. All the interface i have are under the same brand > > (Realtek), eth0 would be for clients, eth1 for DSLCab le, eth2 for Wireless > > 2.4Ghz. Weirdly, several of my clients set up correct ly to use both eth1 > > and eth2, but there are many clients having the wrong route packets just as > > Bobic. > > > > This problem can be solved if i change to use SNAT in stead of MASQUERADE. > > Try it Bobic. > > Hmm. Just replace -j MASQUERADE with - j SNAT? Will that not break other > things? > > > This Masquerade problem didnt appeared under my Linux 2.4.21 > > So, it is a 2.4.20 kernel problem? I was hoping to avoi d home-brewing a kernel > again like I did back with my old setup (RH 7.0, 2.2 ke rnel), and stick with > a standard release kernel. > > Thanks. > > Gordan > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From lartc@bobich.net Mon Jan 5 21:43:03 2004 From: lartc@bobich.net (Gordan Bobic) Date: Mon, 5 Jan 2004 21:43:03 +0000 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: References: Message-ID: <200401052143.03941.lartc@bobich.net> On Monday 05 Jan 2004 8:32 pm, andybr wrote: > Hi all, > > I dont understando what the problem is, can you explain > so i can help you out. 2 interfaces, eth2 and eth3. ip rules ip route are set up correctly. Yet, for some reason, there are packets coming out of eth2 with the IP address of eth3 and vice versa. This seems to be related mainly to forwarded/NATed connections (which tend to break quite quickly). It is almost as if the connection tracking code in the kernel is broken. I am not pretty certain it is a kernel bug in the shipping RH9 kernel. There was an update released today by RH, but I'm not holding much hope it will behave any differently. But it doesn't matter, as I have a fresh patched kernel that will hopefully work to try in a bit. Thanks for the help. Gordan From pturley@rocksteady.com Tue Jan 6 00:23:09 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Mon, 5 Jan 2004 18:23:09 -0600 Subject: [LARTC] Bandwidth Control Tolerances References: <3FC45CE2.8020108@crocom.com.pl> Message-ID: <002801c3d3eb$4634da30$6401a8c0@pturley> I have measured the performance of HTB with iperf and found it to be very close to expected (i.e., within 5%). I have a colleague who is measuring the performance by ftp'ing large files and recording the time required to make the transfer. He is seeing an average throughput that is nearly 10% away from the theoretical, with occasional excursions to nearly 30%. My colleague is now questioning the quality of the traffic control algorithms and wondering two things: 1) What tolerance can we guarantee and advertise? 2) Can the tolerance be improved, since the values he has measured are unacceptable? I believe that my colleague's measurements are unusable. It would help me greatly if anyone who is knowledgeable on these points could respond - either agreeing or disagreeing with me (either would be helpful). From john@cci.net.au Tue Jan 6 02:16:46 2004 From: john@cci.net.au (John Hanlon - Central Coast Internet) Date: Tue, 06 Jan 2004 12:16:46 +1000 Subject: [LARTC] Intermediate Interface? Message-ID: <6.0.1.1.2.20040106120642.05656960@mail.cci.net.au> Is there a way to force ingress traffic into appearing as egress traffic for the purpose of traffic shaping. e.g. eth0 ------> TestMachine -------> lo ---------> TestMachine ---------> eth1 Can you use a loopback or similar interface so that it appears that the data is being sent out and back in a pseudo-interface? This would allow egress filtering as it was passed out the loopback interface before it was then forwarded along to eth1. The reason I am trying this is I have multiple ppp0 interfaces running over the eth1 interface. Rather than trying to manage each one individually, it would be easier for my purposes to use u32 identifiers on a single interface in order to manage traffic. Kind regards, John Hanlon. Central Coast Internet. From rio@martin.mu Tue Jan 6 01:49:38 2004 From: rio@martin.mu (Rio Martin) Date: Tue, 6 Jan 2004 08:49:38 +0700 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401051206.57266.lartc@bobich.net> References: <200312311649.36278.lartc@bobich.net> <200401051154.53035.lartc@bobich.net> <200401051206.57266.lartc@bobich.net> Message-ID: <200401060849.38380.rio@martin.mu> On Monday 05 January 2004 19:06, Gordan Bobic wrote: > On Monday 05 Jan 2004 11:54, Gordan Bobic wrote: > > On Monday 05 Jan 2004 11:28, Art=C5=ABras =C5=A0lajus wrote: > > > Gordan Bobic wrote: > > > > Hmm. Just replace -j MASQUERADE with -j SNAT? Will that not break > > > > other things? > > > -j SNAT your_ip > > Or rather -j SNAT --to-source your_ip. I get it. I'll check if that wor= ks > > better than masquerading. > Just tried it - no difference. Packets still come out with source IP > address not matching the interface. :-( Try it switch manually, first you set up without iproute. Remove all the=20 tables you have created and flush it. Try with ISP1 first. Do SNAT --to=20 ip.of.ISP1 Is it work? Okay, now switch to the ISP2. Do SNAT --to ip.of.ISP2.=20 It should be work, otherwise something wrong with the kernel or iptables yo= u=20 had on your machine. =46inish this step first, report back to the list. Regards, Rio Martin. From Aron@sofaware.com Tue Jan 6 09:43:03 2004 From: Aron@sofaware.com (Aron Brand) Date: Tue, 6 Jan 2004 11:43:03 +0200 Subject: [LARTC] RE: LARTC digest, Vol 1 #1523 - 17 msgs Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE2DAE95@mail.sofaware.com> Hi Roy, It seems that I wasn't clear. Lets give an example. I have a machine with a single ethernet interface, with two IP addresses A and B. This is done using two virtual interfaces.=20 A is my IP address in ISP-A. B is my IP address in ISP-B. The physical line to ISP-A is 1.5Mbps. The physical line to ISP-B is 256kbps. I want to shape the traffic so that, for example, HTTP traffic will take no more than 10% of the ISP-B link, and no more than 20% of the ISP-A link. There seems to be no way to do this without the ability to attach a qdisc to a virtual interface. Please correct me if I am wrong... Aron ------------------------------- From: "Roy" To: Subject: Re: [LARTC] virtual interface Date: Mon, 5 Jan 2004 16:29:40 +0200 There is no need to use imq ant everything is easy to do anyway interface name is usefull only to attach qdisc to something and that all you need to clasify packets by source or destination ip antway if you have idea how to use imq there then just use your interface instead. also why it is so obvious that they must be shaped separately, ususly it is much better to shape everything in one einterface Hi guys, I have this problem too. I have two Internet routers connected to the same Ethernet interface (using a hub). And each one obviously needs to be shaped seperately. It seems like a very common and logical scenario and this issue seems like a design problem. Any Ideas on a workaround? Perhaps IMQ can be used somehow (although I hear it has serious stability problems...)? Aron From Lars.Heineken@gmx.de Tue Jan 6 13:30:54 2004 From: Lars.Heineken@gmx.de (Lars Heineken) Date: Tue, 06 Jan 2004 14:30:54 +0100 Subject: [LARTC] Wonder Shaper Message-ID: <3FFAB88E.2030406@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As stated by your message, I'll try it again on the mailing list.. I tried your wondershaper today and there is one thing I am puzzling about. If I add port 80 and 21 like this NOPRIOPORTSRC='80 21' The uploads from my webserver and ftp server are a lot faster then without adding the ports and surfing the web is a pain. If I leave all the upload specific variables empty, uploads are a lot slower but surfing speed and ssh is fine. Additionaly I noticed that it seems that only one ssh connection is beeing "accelrated" while the dsl is under high load, but that could be because of my relatively slow dsl connection. Maybe you could tell me what _you_ as the creator, usually expect from the shaping effect. So I can adjust my judgings Regards, Lars Heineken. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/+riNrp9JEomxNXERAnf3AJwIf+t1tIFv8IPZE27pdvjDAoVfowCg3VYu h5mGhWKnMfUYr60JvpgtSOI= =hT2n -----END PGP SIGNATURE----- From lartc@bobich.net Tue Jan 6 09:25:04 2004 From: lartc@bobich.net (Gordan Bobic) Date: Tue, 6 Jan 2004 09:25:04 +0000 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401060849.38380.rio@martin.mu> References: <200312311649.36278.lartc@bobich.net> <200401051206.57266.lartc@bobich.net> <200401060849.38380.rio@martin.mu> Message-ID: <200401060924.42879.gordan@bobich.net> On Tuesday 06 Jan 2004 01:49, Rio Martin wrote: > > > > > Hmm. Just replace -j MASQUERADE with -j SNAT? Will that not break > > > > > other things? > > > > > > > > -j SNAT your_ip > > > > > > Or rather -j SNAT --to-source your_ip. I get it. I'll check if that > > > works better than masquerading. > > > > Just tried it - no difference. Packets still come out with source IP > > address not matching the interface. :-( > > Try it switch manually, first you set up without iproute. Remove all the > tables you have created and flush it. Try with ISP1 first. Do SNAT --to > ip.of.ISP1 > Is it work? Okay, now switch to the ISP2. Do SNAT --to ip.of.ISP2. > It should be work, otherwise something wrong with the kernel or iptables > you had on your machine. > > Finish this step first, report back to the list. If one of the default routes is removed, everything works OK. However, if there are two default routes, packets get misdirected. ChangeLog for 2.4.21 lists a few conntrack bug fixes, which I suspect to be the cause of this. Basically, the non-deterministic default route selection/rotation seems to take precedence over maintaining the same interface for serving a particular established connection through the firewall. I'm compiling a new clean 2.4.24 with the jumbo routes patch at the moment, which will hopefully fix things. I'm hoping to try it out tonight. And BTW, the latest RH9 kernel released yesterday (2.4.20-28.9 IIRC), is still broken as far as routing is concerned. Gordan From andybr@bol.com.br Tue Jan 6 15:53:12 2004 From: andybr@bol.com.br (andybr) Date: Tue, 6 Jan 2004 13:53:12 -0200 Subject: [LARTC] problem whith htb script Message-ID: Hi all, The ftp uses dynamic ports in source not in destiny so it is possible mark ftp traffic and shape. []=B4s Anderson > On Sunday 04 January 2004 12:30, saptah wrote: > > Hi all && happy new Year ;) > > > > I'm try to made a script for shaping my outgoing traf fic, but it doesn't > > work fine. > > The script work good if all packets go thru the defau lt class, but, if I > > try to send packets by other class, the packes doesn' t go by this class > > go also by the default class. > > > > This script is installed in a router linux with ip ma squerading for the > > clients. > > > > =BFhow I can classify the packets in this classes? > > > > thx 4 all ;) and sorry for my (bad) english :P > No problem. > Are you trying to match ftp traffic? Is so, you can ha ve a problem because > ftp can use dynamic ports. So it's not easy to filter out ftp traffic. > You also use a combination of fw and u32 filter. But f or that fw filter, I > don't see the needed iptables rules. > > 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: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From eric@regit.org Tue Jan 6 16:32:52 2004 From: eric@regit.org (Eric Leblond) Date: Tue, 06 Jan 2004 17:32:52 +0100 Subject: [LARTC] problem whith htb script In-Reply-To: References: Message-ID: <1073406772.25970.29.camel@tech004.alphalink.fr> --=-Su+NzeaFrqIyZmcvX8zW Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Le mar 06/01/2004 =E0 16:53, andybr a =E9crit : > Hi all, >=20 > The ftp uses dynamic ports in source not in destiny so=20 > it is possible mark ftp traffic and shape. Use CONNMARK to mark packet it put the same MARK on all the packet of the connection. So mark follow any non-linear protocol recognized by Netfilter. For more information on usage see : http://home.regit.org/connmark.html BR, --=20 Eric Leblond NuFW, Now User Filtering Works (http://www.nufw.org) --=-Su+NzeaFrqIyZmcvX8zW Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/+uM0nxA7CdMWjzIRAkqnAJ9M6EPAoST87RhA/nhAbh0vl0/uRwCeO5+y bDGGMAnkpq0r9+kpF/FomKw= =YQ9X -----END PGP SIGNATURE----- --=-Su+NzeaFrqIyZmcvX8zW-- From rsmckown@yahoo.com Tue Jan 6 16:57:07 2004 From: rsmckown@yahoo.com (R. Steve McKown) Date: Tue, 6 Jan 2004 09:57:07 -0700 Subject: [LARTC] Multihomed Masquerading, routing and iptables In-Reply-To: <200401060924.42879.gordan@bobich.net> References: <200312311649.36278.lartc@bobich.net> <200401060849.38380.rio@martin.mu> <200401060924.42879.gordan@bobich.net> Message-ID: <200401060957.08704.rsmckown@yahoo.com> On Tuesday 06 January 2004 02:25 am, Gordan Bobic wrote: > If one of the default routes is removed, everything works OK. However, if > there are two default routes, packets get misdirected. ChangeLog for 2.4.21 > lists a few conntrack bug fixes, which I suspect to be the cause of this. > Basically, the non-deterministic default route selection/rotation seems to > take precedence over maintaining the same interface for serving a > particular established connection through the firewall. You are right. This is because the routing core is often queried more than once to set up a usable route cache entry for a given connection/session. Have a look at ip_route_connect() in linux/include/net/route.h as an example: static inline int ip_route_connect(struct rtable **rp, u32 dst, u32 src, u32 tos, int oif) { int err; err = ip_route_output(rp, dst, src, tos, oif); if (err || (dst && src)) return err; dst = (*rp)->rt_dst; src = (*rp)->rt_src; ip_rt_put(*rp); *rp = NULL; return ip_route_output(rp, dst, src, tos, oif); } Consider when this function is called with src==0, which happens for locally generated output (SNAT is similar I believe). The first ip_route_output() call returns a pointer to a route cache entry, which includes a src ip in (*rp)->rt_src. The first route cache entry doesn't work for us, because its 'key' has src==0 and so won't match subsequent traffic. So a second ip_route_output() is called using the new src as part of its key. The new key matches no existing route cache and as a result the default multipath route is again consulted and a nexthop is determined. This latter process does not use src in its processing so there is no guarantee that the nexthop returned is the same as that returned by the first query. Hence, src ip is not guaranteed to match outbound interface. Julian Anastasov's patches, noted earlier in this thread, provide a solution to this problem. He allows for additional route rules and route tables that are matched by the second route query in preference to the default route so the src ip and outbound interface can be forced to be consistent. I'm still pretty new to all this, so I hope Julian or someone else can correct any errors I have made. The example above is in the non-NAT case of locally generated traffic, but I believe it's representative of what happens in the SNAT case as well. > I'm compiling a new clean 2.4.24 with the jumbo routes patch at the moment, > which will hopefully fix things. I'm hoping to try it out tonight. And BTW, > the latest RH9 kernel released yesterday (2.4.20-28.9 IIRC), is still > broken as far as routing is concerned. I haven't looked at RedHat's route patch; it'd be killer if they solved this without requiring the additional route rules and tables setups as required by Julian's patches. Let us know the outcome, would you? The reason for this behavior makes sense from a code perspective, but not IMO from a route administration perspective. I have a patch in its infancy that attempts to address this problem without requiring extra route administration (rules and tables). It works in the non-nat case, but there is still much more testing to go before it's worth publishing. If it survives the next few weeks of testing, I'd be happy to pass it on to anyone else who might be interested in playing with it. Best Regards, Steve From mabrown-lartc@securepipe.com Tue Jan 6 17:20:46 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Tue, 6 Jan 2004 11:20:46 -0600 (CST) Subject: [LARTC] Bandwidth Control Tolerances In-Reply-To: <002801c3d3eb$4634da30$6401a8c0@pturley> References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> Message-ID: Hello Patrick, Please excuse my suggestion if you have already considered the issue I indicate below from Stef's FAQ. : I have measured the performance of HTB with iperf and found it to be : very close to expected (i.e., within 5%). I have a colleague who is : measuring the performance by ftp'ing large files and recording the time : required to make the transfer. He is seeing an average throughput that : is nearly 10% away from the theoretical, with occasional excursions to : nearly 30%. How have you defined your PSCHED_CLOCK_SOURCE? See this URL: http://www.docum.org/stef.coene/qos/faq/cache/40.html : My colleague is now questioning the quality of the traffic control : algorithms and wondering two things: Let's be careful with the baby and the bathwater. The algorithms have been vetted. The implementation may not be ideal, but implementations always suffer from compromises, right? : 1) What tolerance can we guarantee and advertise? Measure the deviations from your specified bandwidth after changing your setting for PSCHED_CLOCK_SOURCE. Advertise your measured tolerance accordingly. : 2) Can the tolerance be improved, since the values he has measured are : unacceptable? I don't know--see the above link, and check how your kernel was compiled. Others on this list may have further suggestions for you. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From pturley@rocksteady.com Tue Jan 6 18:02:29 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 12:02:29 -0600 Subject: [LARTC] Bandwidth Control Tolerances References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> Message-ID: <003901c3d47f$4800e860$6401a8c0@pturley> This is, of course, very valuable feedback. Unfortunately, given the responses I've had so far, I see that I didn't make it clear what I'm really looking for. I believe that my colleague's test methodology is flawed. I believe that you cannot generate reliable bandwidth measurements by ftp'ing files and measuring the time it takes. I believe this because I have seen iperf generate very stable measurements with a variability of only plus or minus 1 kbit/s. I think it is inappropriate to spend time examining the quality of the underlying bandwidth algorithms when the problem is really with the measurement technique. If I don't prove that his tests are flawed, then I *will* be asked to do a bunch of investigation that I think will only waste my time. The ideal response would be something like this: Patrick, Timing an FTP transfer is well known to be a poor choice for measuring bandwidth for the following reasons: 1) Even under ideal conditions, you will be guaranteed to under-measure the bandwidth because you are not accounting for FTP protocol overhead, which is considerable. 2) FTP does a lot of related work that isn't directly helpful in simply moving the bits, which is why your colleague is seeing such variability in his measurements. 3) The resolution of the Linux clock depends on the underlying hardware but, at user level, is one half second at best. This can introduce substantial error and variability in such a simple measurement. 4) Iperf is specifically designed to measure bandwidth without protocol overhead or any other operations that introduce undue error or variability, and accounts for clock skew. This is why you're seeing such stable measurements and your colleague is not. You don't measure voltage with a light bulb - you use a voltmeter. Don't measure bandwidth with FTP, use a bandwidth meter. These are my assertions. If you can authoritatively agree or disagree with any of these claims, please say so. Also, if any of you have measured HTB accuracy and can point me to a web site, that would be ideal. Yes, I've visited the HTB home page, but I haven't found what I'm looking for there. Please see below for my additional responses to Martin's e-mail. > : I have measured the performance of HTB with iperf and found it to be > : very close to expected (i.e., within 5%). I have a colleague who is > : measuring the performance by ftp'ing large files and recording the time > : required to make the transfer. He is seeing an average throughput that > : is nearly 10% away from the theoretical, with occasional excursions to > : nearly 30%. > > How have you defined your PSCHED_CLOCK_SOURCE? See this URL: > > http://www.docum.org/stef.coene/qos/faq/cache/40.html Thank you for the reference. Yes, I found this and read it. We are using stock RedHat kernels and are unwilling to recompile. I will try to figure out how the RedHat kernel is configured. Can you give me an easy way to discover this? Something in /proc perhaps? > : My colleague is now questioning the quality of the traffic control > : algorithms and wondering two things: > > Let's be careful with the baby and the bathwater. The algorithms have > been vetted. The implementation may not be ideal, but implementations > always suffer from compromises, right? I agree entirely. I am convinced that the bandwidth algorithms have been closely examined by many people and work quite well. However, because my colleague believes his tests are accurate, he has concluded otherwise. If you can help me prove that the problem is the measurement technique, I would be very grateful. > : 1) What tolerance can we guarantee and advertise? > > Measure the deviations from your specified bandwidth after changing your > setting for PSCHED_CLOCK_SOURCE. Advertise your measured tolerance > accordingly. Yes - that's fine, if you think you are measuring correctly. But that's the problem at hand, isn't it? > : 2) Can the tolerance be improved, since the values he has measured are > : unacceptable? > > I don't know--see the above link, and check how your kernel was compiled. > Others on this list may have further suggestions for you. > > Good luck, > > -Martin As always, Martin. Thanks very much for your help. From pturley@rocksteady.com Tue Jan 6 18:02:33 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 12:02:33 -0600 Subject: [LARTC] Bandwidth Control Tolerances References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> Message-ID: <003e01c3d47f$4b0304d0$6401a8c0@pturley> This is, of course, very valuable feedback. Unfortunately, given the responses I've had so far, I see that I didn't make it clear what I'm really looking for. I believe that my colleague's test methodology is flawed. I believe that you cannot generate reliable bandwidth measurements by ftp'ing files and measuring the time it takes. I believe this because I have seen iperf generate very stable measurements with a variability of only plus or minus 1 kbit/s. I think it is inappropriate to spend time examining the quality of the underlying bandwidth algorithms when the problem is really with the measurement technique. If I don't prove that his tests are flawed, then I *will* be asked to do a bunch of investigation that I think will only waste my time. The ideal response would be something like this: Patrick, Timing an FTP transfer is well known to be a poor choice for measuring bandwidth for the following reasons: 1) Even under ideal conditions, you will be guaranteed to under-measure the bandwidth because you are not accounting for FTP protocol overhead, which is considerable. 2) FTP does a lot of related work that isn't directly helpful in simply moving the bits, which is why your colleague is seeing such variability in his measurements. 3) The resolution of the Linux clock depends on the underlying hardware but, at user level, is one half second at best. This can introduce substantial error and variability in such a simple measurement. 4) Iperf is specifically designed to measure bandwidth without protocol overhead or any other operations that introduce undue error or variability, and accounts for clock skew. This is why you're seeing such stable measurements and your colleague is not. You don't measure voltage with a light bulb - you use a voltmeter. Don't measure bandwidth with FTP, use a bandwidth meter. These are my assertions. If you can authoritatively agree or disagree with any of these claims, please say so. Also, if any of you have measured HTB accuracy and can point me to a web site, that would be ideal. Yes, I've visited the HTB home page, but I haven't found what I'm looking for there. Please see below for my additional responses to Martin's e-mail. > : I have measured the performance of HTB with iperf and found it to be > : very close to expected (i.e., within 5%). I have a colleague who is > : measuring the performance by ftp'ing large files and recording the time > : required to make the transfer. He is seeing an average throughput that > : is nearly 10% away from the theoretical, with occasional excursions to > : nearly 30%. > > How have you defined your PSCHED_CLOCK_SOURCE? See this URL: > > http://www.docum.org/stef.coene/qos/faq/cache/40.html Thank you for the reference. Yes, I found this and read it. We are using stock RedHat kernels and are unwilling to recompile. I will try to figure out how the RedHat kernel is configured. Can you give me an easy way to discover this? Something in /proc perhaps? > : My colleague is now questioning the quality of the traffic control > : algorithms and wondering two things: > > Let's be careful with the baby and the bathwater. The algorithms have > been vetted. The implementation may not be ideal, but implementations > always suffer from compromises, right? I agree entirely. I am convinced that the bandwidth algorithms have been closely examined by many people and work quite well. However, because my colleague believes his tests are accurate, he has concluded otherwise. If you can help me prove that the problem is the measurement technique, I would be very grateful. > : 1) What tolerance can we guarantee and advertise? > > Measure the deviations from your specified bandwidth after changing your > setting for PSCHED_CLOCK_SOURCE. Advertise your measured tolerance > accordingly. Yes - that's fine, if you think you are measuring correctly. But that's the problem at hand, isn't it? > : 2) Can the tolerance be improved, since the values he has measured are > : unacceptable? > > I don't know--see the above link, and check how your kernel was compiled. > Others on this list may have further suggestions for you. > > Good luck, > > -Martin As always, Martin. Thanks very much for your help. From pturley@rocksteady.com Tue Jan 6 18:03:21 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 12:03:21 -0600 Subject: [LARTC] Bandwidth Control Tolerances References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> Message-ID: <005101c3d47f$61d1f270$6401a8c0@pturley> This is, of course, very valuable feedback. Unfortunately, given the responses I've had so far, I see that I didn't make it clear what I'm really looking for. I believe that my colleague's test methodology is flawed. I believe that you cannot generate reliable bandwidth measurements by ftp'ing files and measuring the time it takes. I believe this because I have seen iperf generate very stable measurements with a variability of only plus or minus 1 kbit/s. I think it is inappropriate to spend time examining the quality of the underlying bandwidth algorithms when the problem is really with the measurement technique. If I don't prove that his tests are flawed, then I *will* be asked to do a bunch of investigation that I think will only waste my time. The ideal response would be something like this: Patrick, Timing an FTP transfer is well known to be a poor choice for measuring bandwidth for the following reasons: 1) Even under ideal conditions, you will be guaranteed to under-measure the bandwidth because you are not accounting for FTP protocol overhead, which is considerable. 2) FTP does a lot of related work that isn't directly helpful in simply moving the bits, which is why your colleague is seeing such variability in his measurements. 3) The resolution of the Linux clock depends on the underlying hardware but, at user level, is one half second at best. This can introduce substantial error and variability in such a simple measurement. 4) Iperf is specifically designed to measure bandwidth without protocol overhead or any other operations that introduce undue error or variability, and accounts for clock skew. This is why you're seeing such stable measurements and your colleague is not. You don't measure voltage with a light bulb - you use a voltmeter. Don't measure bandwidth with FTP, use a bandwidth meter. These are my assertions. If you can authoritatively agree or disagree with any of these claims, please say so. Also, if any of you have measured HTB accuracy and can point me to a web site, that would be ideal. Yes, I've visited the HTB home page, but I haven't found what I'm looking for there. Please see below for my additional responses to Martin's e-mail. > : I have measured the performance of HTB with iperf and found it to be > : very close to expected (i.e., within 5%). I have a colleague who is > : measuring the performance by ftp'ing large files and recording the time > : required to make the transfer. He is seeing an average throughput that > : is nearly 10% away from the theoretical, with occasional excursions to > : nearly 30%. > > How have you defined your PSCHED_CLOCK_SOURCE? See this URL: > > http://www.docum.org/stef.coene/qos/faq/cache/40.html Thank you for the reference. Yes, I found this and read it. We are using stock RedHat kernels and are unwilling to recompile. I will try to figure out how the RedHat kernel is configured. Can you give me an easy way to discover this? Something in /proc perhaps? > : My colleague is now questioning the quality of the traffic control > : algorithms and wondering two things: > > Let's be careful with the baby and the bathwater. The algorithms have > been vetted. The implementation may not be ideal, but implementations > always suffer from compromises, right? I agree entirely. I am convinced that the bandwidth algorithms have been closely examined by many people and work quite well. However, because my colleague believes his tests are accurate, he has concluded otherwise. If you can help me prove that the problem is the measurement technique, I would be very grateful. > : 1) What tolerance can we guarantee and advertise? > > Measure the deviations from your specified bandwidth after changing your > setting for PSCHED_CLOCK_SOURCE. Advertise your measured tolerance > accordingly. Yes - that's fine, if you think you are measuring correctly. But that's the problem at hand, isn't it? > : 2) Can the tolerance be improved, since the values he has measured are > : unacceptable? > > I don't know--see the above link, and check how your kernel was compiled. > Others on this list may have further suggestions for you. > > Good luck, > > -Martin As always, Martin. Thanks very much for your help. From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From andy.furniss@dsl.pipex.com Tue Jan 6 21:43:33 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Tue, 6 Jan 2004 21:43:33 +0000 Subject: [LARTC] IMQ problems :-( In-Reply-To: <002301c3d2e8$d3885a00$030aa8c0@t> References: <20040104060557.3690.88353.Mailman@outpost.ds9a.nl> <219601369.20040104154709@yahoo.co.uk> <002301c3d2e8$d3885a00$030aa8c0@t> Message-ID: <04010621433300.00693@amd> On Sunday 04 January 2004 5:33 pm, Roy wrote: > > I have read about people having lots of problems with IMQ. So I just > > wanted to > > > try it and see how stable it is on my box. I gather it could actually > > be problems with the Kernel and not the IMQ code?? > > That is possible but prpbably not because of bug in kernel I > as I think it is because kernel handles local trafic diferently than > forwarded > > so you cant use imq to shape trafic generated by server > I am comtinuing development of imq abd I face this problem most of the > time. Do you mean because it crashes ? I seem to be able to shape upstream from my gateway and forward OK using IMQ - I know I don't really need it for up because I could mark, and the nat patch only works down, but I've been testing the jdg script recently and haven't managed a crash yet. I am only on a home network that gets shutdown after 18 hours, though. > > > I think that sounds even more messy :-) > > I only wanted to ingress shape with IMQ to ensure that I don't drop > > UDP or small TCP ACK packets for upload streams. I guess I will just > > give up on the idea and using ingress policing... Its not so important > > anyway > > as my > > > DSL connection is very asymetric (2mbit D/L; 256kbit U/L) and upload > > shaping is more important. > > if only want to shape incoming trafic probably you can use imq quite > safely, > > anyway as I see you dont need it at all you can easily shape all uploads > anyway > and since your download speed is high enough you dont need to worry > about it. > > however imq can be usefull to control trafic so that you can download > with kaza and browse web or play game without high latency. ______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From cal_kaiwen@hotmail.com Wed Jan 7 03:31:45 2004 From: cal_kaiwen@hotmail.com (kaiwen) Date: Wed, 7 Jan 2004 11:31:45 +0800 Subject: [LARTC] Match packet mark with --set-mark to ip rule fwmark Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_01A0_01C3D511.D4E00F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here I am trying something simple. My objective is to make ip rule fwmark command work :) Network Diagram: --- 192.168.250.197 (eth0) Linux Box (eth1) 192.168.8.88 = -------------192.168.8.122 (eth0) Windows XP Client Configuration done on Linux Box:- (1) [root@g webauth]# iptables -t mangle -A PREROUTING -j MARK = --set-mark 5 [root@g webauth]# iptables -t mangle -L Chain PREROUTING (policy ACCEPT) target prot opt source destination MARK all -- anywhere anywhere MARK set 0x5 (2) [root@g webauth]# ip rule add fwmark 5 table test2 [root@g webauth]# ip rule 0: from all lookup local 32765: from all fwmark 5 lookup test2 32766: from all lookup main 32767: from all lookup 253 (3) [root@g webauth]# ip ro show table test2 prohibit 192.168.8.122 I expect ping from 192.168.8.122 to 192.168.250.197 to be drop, BUT is = is successful. Why? Did I miss out anything? Please advice. Thank you Kaiwen ------=_NextPart_000_01A0_01C3D511.D4E00F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

Here=20 I am trying something simple.
My objective is to make ip rule fwmark = command=20 work :)

Network Diagram:
--- 192.168.250.197 (eth0) Linux Box = (eth1)=20 192.168.8.88 -------------192.168.8.122 (eth0) Windows XP=20 Client

Configuration done on Linux Box:-

(1) [root@g = webauth]#=20 iptables -t mangle -A PREROUTING -j MARK --set-mark 5
[root@g = webauth]#=20 iptables -t mangle -L
Chain PREROUTING (policy=20 ACCEPT)
target     prot opt=20 source           &= nbsp;  =20 destination
MARK       all  = -- =20 anywhere           = ; =20 anywhere           = MARK set=20 0x5

(2) [root@g webauth]# ip rule add fwmark 5 table=20 test2

[root@g webauth]# ip = rule
0:      from=20 all lookup local
32765:  from all=20 fwmark        5 lookup = test2
32766: =20 from all lookup main
32767:  from all lookup 253

(3) = [root@g=20 webauth]# ip ro show table test2
prohibit 192.168.8.122

I = expect ping=20 from 192.168.8.122 to 192.168.250.197 to be drop, BUT is = is
successful.=20 Why?
Did I miss out anything? Please advice.

Thank=20 you
Kaiwen

------=_NextPart_000_01A0_01C3D511.D4E00F80-- From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From smb23@csufresno.edu Wed Jan 7 04:39:29 2004 From: smb23@csufresno.edu (Steve M Bibayoff) Date: Tue, 06 Jan 2004 20:39:29 -0800 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) Message-ID: <16092e166644.16664416092e@cvip.net> Hello, for the umpteen time Patrick Turley sent: > Too bad this wasn't on the, then I could set by watch to it. Steve From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From eddieknows@ananzi.co.za Wed Jan 7 06:20:14 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Wed, 07 Jan 2004 08:20:14 +0200 Subject: [LARTC] Again,Bandwidth&htb Message-ID: <1073456413.2496.5.camel@testbox.co.za> Good Day All Just 2 questions on htb 1,My Wan link is on eth1 and my Lan on eth0,where do I put my htb on?I want to limit web serving and ftp ens. 2.Im going to use the u32 filter.Can I use sub-netting for IP,i.o.w where src is can I do 192.168.1.0/24? Thanks and Please Help Eddie From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From xxd@sym.zapto.org Wed Jan 7 07:42:40 2004 From: xxd@sym.zapto.org (xxd) Date: Tue, 6 Jan 2004 21:42:40 -1000 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) In-Reply-To: <16092e166644.16664416092e@cvip.net> References: <16092e166644.16664416092e@cvip.net> Message-ID: <20040106214240.195cf3c6.xxd@sym.zapto.org> --Signature=_Tue__6_Jan_2004_21_42_40_-1000_j4s4Ziz1e5u2CF6x Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit I agree, I am beginning to wonder if this is user error, or some malicious attempt by an idiot that is not P. Turley. Or even worse, some horrible new bug in M$ mail clients... On Tue, 06 Jan 2004 20:39:29 -0800 Steve M Bibayoff wrote: > Hello, > > for the umpteen time Patrick Turley sent: > > > > > Too bad this wasn't on the, then I could set by watch to it. > > Steve xxd -- ############################################################## # ________ ___ ________ # # # )_ ( '-,) ) _( # Email: xxd at sym dot zapto dot # )_ \_//_/ _( # # # )___ ___( # Lo Tek Sym Designs # # )) # # # (( # Scott Scheurman # # ``- # # ############################################################## --Signature=_Tue__6_Jan_2004_21_42_40_-1000_j4s4Ziz1e5u2CF6x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/+7h2cUsimwt3hhIRAsG0AJ99gewNu2m6F1QzLEp/KAclRzzPAQCgxPlY aVvtmHQkacql1eH6fonZ1Ec= =N1LH -----END PGP SIGNATURE----- --Signature=_Tue__6_Jan_2004_21_42_40_-1000_j4s4Ziz1e5u2CF6x-- From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From Jurrie Overgoor" I recently suffer badly from low bandwith. At first I thought it was my Linux box, but after tracing the problem it turns out it was the ammount of double posts I get from Patrick Turley... :) Isn't there a way to block mail.rocksteady.com? It seems the mail originates from 10.50.23.3, and is forwarded by this host (which would make sense). Greetz -- Jurrie jurrie.overgoor@zonnet.nl From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From stef.coene@docum.org Wed Jan 7 17:09:52 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 7 Jan 2004 18:09:52 +0100 Subject: [LARTC] Again,Bandwidth&htb In-Reply-To: <1073456413.2496.5.camel@testbox.co.za> References: <1073456413.2496.5.camel@testbox.co.za> Message-ID: <200401071809.52233.stef.coene@docum.org> On Wednesday 07 January 2004 07:20, Eddie wrote: > Good Day All > Just 2 questions on htb > > 1,My Wan link is on eth1 and my Lan on eth0,where do I put my htb on?I > want to limit web serving and ftp ens. eth1 for downloads from your web/ftp server eth0 for uploads to your web/ftp server > 2.Im going to use the u32 filter.Can I use sub-netting for IP,i.o.w > where src is can I do 192.168.1.0/24? Yes you can. See http://docum.org/stef.coene/qos/docs/u32-filter.html Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Wed Jan 7 17:36:56 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 7 Jan 2004 18:36:56 +0100 Subject: [LARTC] Bandwidth Control Tolerances In-Reply-To: <003e01c3d47f$4b0304d0$6401a8c0@pturley> References: <3FC45CE2.8020108@crocom.com.pl> <003e01c3d47f$4b0304d0$6401a8c0@pturley> Message-ID: <200401071836.56689.stef.coene@docum.org> On Tuesday 06 January 2004 19:02, Patrick Turley wrote: > This is, of course, very valuable feedback. Unfortunately, given the > responses I've had so far, I see that I didn't make it clear what I'm > really looking for. I also did some htb tests. I created scripts that uses iptables or tc counters to log the number of bytes. And most of the time I had bursty results. But I think this burst is more reated to the test setup: collisions, retransmits, CPU/disk, ... I did some burst tests and recorded the rate each 500ms: http://docum.org/stef.coene/qos/tests/htb/burst/ I used ethloop. Ethloop can be used to simulate a htb qdisc on the lo device (it can be found on the htb homepag). So there is no network involved, it only records bytes like they should be sended if this was a real device. So this is the perfect situation for htb. And.... as you can see on the graphs, the rate is very stable and allmost perfect accurate. So the bursts or rate deviation are not htb related. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From stef.coene@docum.org Wed Jan 7 17:17:49 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 7 Jan 2004 18:17:49 +0100 Subject: [LARTC] RE: LARTC digest, Vol 1 #1523 - 17 msgs In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE2DAE95@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE2DAE95@mail.sofaware.com> Message-ID: <200401071817.49598.stef.coene@docum.org> On Tuesday 06 January 2004 10:43, Aron Brand wrote: > Hi Roy, > > It seems that I wasn't clear. Lets give an example. > > I have a machine with a single ethernet interface, with two IP addresses > A and B. This is done using two virtual interfaces. > A is my IP address in ISP-A. B is my IP address in ISP-B. The physical > line to ISP-A is 1.5Mbps. The physical line to ISP-B is 256kbps. > > I want to shape the traffic so that, for example, HTTP traffic will take > no more than 10% of the ISP-B link, and no more than 20% of the ISP-A > link. > > There seems to be no way to do this without the ability to attach a > qdisc to a virtual interface. Please correct me if I am wrong... You can do this if this box is also natting. The difference between packets leaving the 2 links is the source address. You can use the source address to put the traffic in 2 different classes. After that you can create subclasses for http traffic. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From pturley@rocksteady.com Tue Jan 6 19:08:32 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 6 Jan 2004 13:08:32 -0600 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> Message-ID: <002001c3d488$7de13da0$6401a8c0@pturley> From x11@h2o.pieva.net Wed Jan 7 21:26:01 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Wed, 07 Jan 2004 23:26:01 +0200 Subject: [LARTC] Random ping jumps Message-ID: <3FFC7969.1040103@h2o.pieva.net> Hello, I've got this problem. There is an linux server with 2.4.24 kernel and pinging from him to internet (or from lan) ping randomly jumps up: 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=387 ttl=59 time=30.0 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=388 ttl=59 time=32.6 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=389 ttl=59 time=34.9 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=390 ttl=59 time=198 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=391 ttl=59 time=407 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=392 ttl=59 time=407 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=393 ttl=59 time=430 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=394 ttl=59 time=30.9 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=395 ttl=59 time=31.6 ms Internet line isn't loaded up, server load fine. QOS isn't used, qdiscs default. I don't realize what the problem is and even how to debug it. Sysctl config: net/ipv4/ip_forward = 1 net/ipv4/icmp_ignore_bogus_error_responses = 1 net/ipv4/icmp_echo_ignore_broadcasts = 1 net/ipv4/tcp_syncookies = 1 net/ipv4/tcp_timestamps = 0 net/ipv4/tcp_window_scaling = 0 net/ipv4/tcp_sack = 0 net/ipv4/tcp_fin_timeout = 30 net/ipv4/tcp_keepalive_time = 1800 net/ipv4/tcp_low_latency = 1 Thanks for any thoughts. From brooney@xcommunications.co.uk Wed Jan 7 22:05:18 2004 From: brooney@xcommunications.co.uk (Barry Rooney) Date: Wed, 7 Jan 2004 22:05:18 -0000 Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) References: <3FC45CE2.8020108@crocom.com.pl> <002801c3d3eb$4634da30$6401a8c0@pturley> <005101c3d47f$61d1f270$6401a8c0@pturley> <002001c3d488$7de13da0$6401a8c0@pturley> Message-ID: <001401c3d56a$56716eb0$0b01000a@xcom1> Yawn! ----- Original Message ----- From: "Patrick Turley" To: Sent: Tuesday, January 06, 2004 7:08 PM Subject: [LARTC] Very sorry about the triple post (grrrr Outlook Express) > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.555 / Virus Database: 347 - Release Date: 23/12/2003 From neilson@predialnet.com.br Wed Jan 7 22:31:34 2004 From: neilson@predialnet.com.br (Neilson Henriques) Date: Wed, 7 Jan 2004 20:31:34 -0200 Subject: [LARTC] TC rule numbering Message-ID: <000801c3d56e$01ddae50$0201c80a@H4X0RN0T3B00K> Hello list, I'm developing an application that needs to number the TC rule (and keep it in a internal array table) to be possibly deleted later if its needed. I didn't find a easy way to do that and will be thankful if somebody can help me. Sorry if the question has a simple answer ... I'm a beginner in TC ... :-) Happy 2004 ... Neilson From neilson@predialnet.com.br Wed Jan 7 23:39:30 2004 From: neilson@predialnet.com.br (Neilson Henriques) Date: Wed, 7 Jan 2004 21:39:30 -0200 Subject: [LARTC] TC rule numbering References: Message-ID: <000c01c3d577$7f08e620$0201c80a@H4X0RN0T3B00K> Do I can specify a handle or it is generated automatically by TC ? The main idea is let the application control these numbers instead of check the TC rule table ... ----- Original Message ----- From: To: "Neilson Henriques" Cc: Sent: Wednesday, January 07, 2004 9:01 PM Subject: Re: [LARTC] TC rule numbering > > TC objects have handles or class identifiers associated with them. You can > delete or modify the object by its id. > > > Rubens > > > On Wed, 7 Jan 2004, Neilson Henriques wrote: > > > Hello list, > > > > I'm developing an application that needs to number the TC rule > > (and keep it in a internal array table) to be possibly deleted later > > if its needed. > > > > I didn't find a easy way to do that and will be thankful if somebody > > can help me. > > > > Sorry if the question has a simple answer ... I'm a beginner > > in TC ... :-) > > > > Happy 2004 ... > > > > Neilson > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > From roy@xxx.lt Wed Jan 7 23:25:00 2004 From: roy@xxx.lt (Roy) Date: Thu, 8 Jan 2004 01:25:00 +0200 Subject: [LARTC] Random ping jumps References: <3FFC7969.1040103@h2o.pieva.net> Message-ID: <00c401c3d575$78fa37e0$030aa8c0@t> I think it is your privider fault, Isnt your provider litnet? and you connected with some wlan card to debug it trace the patch (with traceroute or tracert) and try to ping the most near routers, this way you will easy find the problem > Hello, > > I've got this problem. There is an linux server with 2.4.24 kernel > and pinging from him to internet (or from lan) ping randomly jumps up: > > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=387 ttl=59 time=30.0 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=388 ttl=59 time=32.6 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=389 ttl=59 time=34.9 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=390 ttl=59 time=198 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=391 ttl=59 time=407 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=392 ttl=59 time=407 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=393 ttl=59 time=430 ms From hare ram" Hi all iam trying to setup Dual gate using Julian patch DGD, but when i try tp patch to my kernel with fedora iam getting the following eroor can some one suggest me what is wrong or i need a latest patch for fedora [root@linux-2.4.22-1.2115.nptl]# patch -p1 < /root/update/update/routes-2.4.20-9.diff patching file include/linux/netfilter_ipv4/ip_nat.h patching file include/linux/rtnetlink.h patching file include/net/ip_fib.h patching file include/net/route.h Hunk #2 succeeded at 130 (offset 2 lines). patching file net/ipv4/arp.c Hunk #1 succeeded at 317 (offset 1 line). patching file net/ipv4/fib_frontend.c patching file net/ipv4/fib_hash.c Hunk #2 succeeded at 337 (offset 24 lines). Hunk #4 succeeded at 489 (offset 24 lines). Hunk #5 succeeded at 629 (offset -2 lines). patching file net/ipv4/fib_rules.c patching file net/ipv4/fib_semantics.c Hunk #4 succeeded at 366 with fuzz 2. Hunk #5 FAILED at 384. Hunk #6 succeeded at 436 with fuzz 1. 1 out of 12 hunks FAILED -- saving rejects to file net/ipv4/fib_semantics.c.rej patching file net/ipv4/ip_nat_dumb.c patching file net/ipv4/netfilter/ip_fw_compat_masq.c patching file net/ipv4/netfilter/ip_nat_core.c Hunk #1 succeeded at 962 (offset 9 lines). patching file net/ipv4/netfilter/ip_nat_standalone.c Hunk #1 succeeded at 221 (offset -5 lines). Hunk #2 succeeded at 300 with fuzz 2 (offset 1 line). Hunk #3 succeeded at 330 with fuzz 2 (offset -5 lines). patching file net/ipv4/netfilter/ipt_MASQUERADE.c Hunk #1 FAILED at 88. 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/netfilter/ipt_MASQUERADE.c.rej patching file net/ipv4/route.c Hunk #1 succeeded at 918 (offset 68 lines). Hunk #2 succeeded at 1275 (offset 1 line). Hunk #3 succeeded at 1356 (offset 68 lines). Hunk #4 succeeded at 1329 (offset 1 line). Hunk #5 succeeded at 1416 (offset 68 lines). Hunk #6 succeeded at 1380 (offset 1 line). Hunk #7 succeeded at 1462 (offset 68 lines). Hunk #8 succeeded at 1409 (offset 1 line). Hunk #9 succeeded at 1515 (offset 68 lines). Hunk #10 succeeded at 1470 (offset 1 line). Hunk #11 succeeded at 1564 (offset 68 lines). Hunk #12 succeeded at 1510 (offset 1 line). Hunk #13 succeeded at 1588 (offset 68 lines). Hunk #14 succeeded at 1545 (offset 1 line). Hunk #15 succeeded at 1646 (offset 68 lines). Hunk #16 succeeded at 1592 (offset 1 line). Hunk #17 succeeded at 1725 (offset 68 lines). Hunk #18 succeeded at 1674 (offset 1 line). Hunk #19 succeeded at 1789 (offset 69 lines). Hunk #20 succeeded at 1758 (offset 1 line). Hunk #21 succeeded at 1916 (offset 69 lines). Hunk #22 succeeded at 1856 (offset 1 line). Hunk #23 succeeded at 1967 (offset 69 lines). Hunk #24 succeeded at 1907 (offset 1 line). Hunk #25 succeeded at 2038 (offset 69 lines). Hunk #26 succeeded at 2051 (offset 1 line). patching file net/netsyms.c Hunk #1 succeeded at 254 (offset 6 lines). [root@linux-2.4.22-1.2115.nptl]# hare From hare ram" Hi all iam trying to migrate from my QOS Services from RH 9.0 to Fedora i saw that fedora shipping with latest TC with HTB patch Does any one see any problem with this version some expert coment will be apprciate hare From eddieknows@ananzi.co.za Thu Jan 8 09:50:10 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Thu, 08 Jan 2004 11:50:10 +0200 Subject: [LARTC] Again,Bandwidth&htb In-Reply-To: <200401071809.52233.stef.coene@docum.org> References: <1073456413.2496.5.camel@testbox.co.za> <200401071809.52233.stef.coene@docum.org> Message-ID: <1073555410.2495.19.camel@testbox.co.za> OK but how do I specify a range of ports,for examples 15000-15010 15000:15010?? On Wed, 2004-01-07 at 19:09, Stef Coene wrote: > *This message was transferred with a trial version of CommuniGate(tm) Pro* > On Wednesday 07 January 2004 07:20, Eddie wrote: > > Good Day All > > Just 2 questions on htb > > > > 1,My Wan link is on eth1 and my Lan on eth0,where do I put my htb on?I > > want to limit web serving and ftp ens. > eth1 for downloads from your web/ftp server > eth0 for uploads to your web/ftp server > > > 2.Im going to use the u32 filter.Can I use sub-netting for IP,i.o.w > > where src is can I do 192.168.1.0/24? > Yes you can. See > http://docum.org/stef.coene/qos/docs/u32-filter.html > > Stef From skwerl@aperfectcircle.net Thu Jan 8 08:46:35 2004 From: skwerl@aperfectcircle.net (Skwerl) Date: Thu, 8 Jan 2004 00:46:35 -0800 Subject: [LARTC] transparently passing url requests to local servers sharing ip? Message-ID: <2A870C7C-41B7-11D8-BA35-000393147D48@aperfectcircle.net> hey, i'm hoping there's someone out there that can help me out... i found http://lartc.org/howto/index.html through a friend who was trying to help with something i'm trying to accomplish. for various practical and educational reasons, i have a few servers set up on my home network, all running apache on various operating systems, all accessible through port forwarding. i only have one ip which they all share. for instance: http://24.30.102.177:1721/ is an osx server on the network (192.168.0.104) http://24.30.102.177:1722/ is a slackware linux server on the network (192.168.0.101) http://24.30.102.177:1723/ is a windows nt server on the network (192.168.0.106) what i want to do is have something running on the linux box (which the router would dmz) that would take a url requested and let a particular server on the network serve a web site. i'd like it to be transparent to the client, so they never see port numbers in their address bar, and i'd like the web serving to be done by the box the files rest on; not strictly the linux box's apache. i don't need someone to hold my hand through the whole process which i expect to be tricky, but i'd like to know if what i'm trying to do is even possible with linux routing- if i'm barking up the right tree so to speak. also, i don't seem to have iproute installed and every site which is supposed to have it seems to be down. do you know where i can get it? if i need it, that is. i've been searching for a clue for some time now, and any light on this subject would be hugely appreciated! skwerl From reveng@arc.net.au Thu Jan 8 09:48:33 2004 From: reveng@arc.net.au (Bryan Nolen) Date: Thu, 8 Jan 2004 20:48:33 +1100 Subject: [LARTC] transparently passing url requests to local servers sharing ip? In-Reply-To: <2A870C7C-41B7-11D8-BA35-000393147D48@aperfectcircle.net> Message-ID: <000001c3d5cc$94f625b0$dd02a8c0@unwired> Check out Apache's ProxyPass feature: http://www.linuxfocus.org/English/March2000/article147.html > -----Original Message----- what i want to do is have something running on the linux box (which the router would dmz) that would take a url requested and let a particular server on the network serve a web site. i'd like it to be transparent to the client, so they never see port numbers in their address bar, and i'd like the web serving to be done by the box the files rest on; not strictly the linux box's apache. From ja@ssi.bg Thu Jan 8 10:57:22 2004 From: ja@ssi.bg (Julian Anastasov) Date: Thu, 8 Jan 2004 12:57:22 +0200 (EET) Subject: [LARTC] Multihome- routes patch problem In-Reply-To: <04d001c3d5b2$6a8e1fe0$c2bf09ca@huecal> Message-ID: Hello, On Thu, 8 Jan 2004, hare ram wrote: > [root@linux-2.4.22-1.2115.nptl]# patch -p1 < > /root/update/update/routes-2.4.20-9.diff What happens with routes-2.4.22-9.diff ? Regards -- Julian Anastasov From hare ram" Message-ID: <061501c3d5d5$3040a880$c2bf09ca@huecal> See the the error, its not patched perfectly its giving some problems, while iam patching patching file net/ipv4/fib_rules.c patching file net/ipv4/fib_semantics.c Hunk #4 succeeded at 366 with fuzz 2. Hunk #5 FAILED at 384. --------------------------------------- Hunk #6 succeeded at 436 with fuzz 1. 1 out of 12 hunks FAILED -- saving rejects to file net/ipv4/fib_semantics.c.rej ------------------------- patching file net/ipv4/ip_nat_dumb.c patching file net/ipv4/netfilter/ip_fw_compat_masq.c patching file net/ipv4/netfilter/ip_nat_core.c Hunk #1 succeeded at 962 (offset 9 lines). patching file net/ipv4/netfilter/ip_nat_standalone.c Hunk #1 succeeded at 221 (offset -5 lines). Hunk #2 succeeded at 300 with fuzz 2 (offset 1 line). Hunk #3 succeeded at 330 with fuzz 2 (offset -5 lines). patching file net/ipv4/netfilter/ipt_MASQUERADE.c Hunk #1 FAILED at 88. 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/netfilter/ipt_MASQUERADE.c.rej hare ----- Original Message ----- From: "Julian Anastasov" To: "hare ram" Cc: Sent: Thursday, January 08, 2004 4:27 PM Subject: Re: [LARTC] Multihome- routes patch problem > > Hello, > > On Thu, 8 Jan 2004, hare ram wrote: > > > [root@linux-2.4.22-1.2115.nptl]# patch -p1 < > > /root/update/update/routes-2.4.20-9.diff > > What happens with routes-2.4.22-9.diff ? > > Regards > > -- > Julian Anastasov > > From rabs@dimension-virtual.com Thu Jan 8 15:07:25 2004 From: rabs@dimension-virtual.com (=?iso-8859-15?q?Ra=FAl_Alexis_Betancort_Santana?=) Date: Thu, 8 Jan 2004 15:07:25 +0000 Subject: [LARTC] Multihomed router problems Message-ID: <200401081507.26233.rabs@dimension-virtual.com> Hi all, i'm new at LARTC, and after reading the docs I found no solution to my problem ... On one side I have eth0 conected to the LAN, on the other side I have eth1 conected to a switch and to 3 DSL routers with 3 diferent providers, and also eth2 conected to a cisco 2600 conected to a LDMS line. I have readed the larct docs about multihomed conections to internet, but I'm been unable to setup the routes with iproute2. I have setup a default multihop route, but if I receive a ssh conection throught one of the DSL lines it get not answered by the same line, it's answered throught the default route, How could I change this? I want to begin by answering the traffic by the line it is coming in. On eth1 I have 3 publics IP's, one from each DSL provider. Any sugestions? .. From x11@h2o.pieva.net Thu Jan 8 15:28:01 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 08 Jan 2004 17:28:01 +0200 Subject: [LARTC] Random ping jumps In-Reply-To: <00c401c3d575$78fa37e0$030aa8c0@t> References: <3FFC7969.1040103@h2o.pieva.net> <00c401c3d575$78fa37e0$030aa8c0@t> Message-ID: <3FFD7701.6000905@h2o.pieva.net> Roy wrote: > I think it is your privider fault, Isnt your provider litnet? and you > connected with some wlan card no. my provider is Lithuania telecom. And i'm on DSL 320/128. > to debug it trace the patch (with traceroute or tracert) and try to ping the > most near routers, this way you will easy find the problem i'll try using mrt. From x11@h2o.pieva.net Thu Jan 8 15:32:05 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 08 Jan 2004 17:32:05 +0200 Subject: [LARTC] Multihomed router problems In-Reply-To: <200401081507.26233.rabs@dimension-virtual.com> References: <200401081507.26233.rabs@dimension-virtual.com> Message-ID: <3FFD77F5.20201@h2o.pieva.net> Raúl Alexis Betancort Santana wrote: > Hi all, i'm new at LARTC, and after reading the docs I found no solution to my > problem ... > > On one side I have eth0 conected to the LAN, on the other side I have eth1 > conected to a switch and to 3 DSL routers with 3 diferent providers, and also > eth2 conected to a cisco 2600 conected to a LDMS line. > > I have readed the larct docs about multihomed conections to internet, but I'm > been unable to setup the routes with iproute2. I have setup a default > multihop route, but if I receive a ssh conection throught one of the DSL > lines it get not answered by the same line, it's answered throught the > default route, How could I change this? I want to begin by answering the > traffic by the line it is coming in. Well. this should be done automatically otherwise it would break TCP/ip. I think you messed up your config. Mine setup with 2 ip's: rasnet:/etc/blootbot# ip rule 0: from all lookup local 32760: from all to 213.226.172.0/24 lookup parabole 32761: from all to 213.252.224.0/24 lookup parabole 32763: from all to 213.226.161.0/24 lookup parabole 32764: from all to 213.226.147.0/24 lookup parabole 32765: from all to 213.226.146.0/24 lookup parabole 32766: from all lookup main 32767: from all lookup default rasnet:/etc/blootbot# ip route 192.168.20.0/24 dev eth1 proto kernel scope link src 192.168.20.59 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 81.0.0.0/8 dev eth0 proto kernel scope link src 81.7.84.36 default via 81.7.84.1 dev eth0 src 81.7.84.36 rasnet:/etc/blootbot# ip route ls table parabole default via 192.168.20.1 dev eth1 From andre.correa@pobox.com Thu Jan 8 16:17:35 2004 From: andre.correa@pobox.com (Andre Correa) Date: Thu, 08 Jan 2004 14:17:35 -0200 Subject: [LARTC] Strange behavior deleting filters Message-ID: <3FFD829F.304@pobox.com> Hi list, I'm playing with tc and found a strange behavior when I try to delete filters. For example, this simple scenario: tc qdisc add dev eth1 root handle 1: htb default 100 tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 works just fine, but when I try to delete oen of the filters with something like this: tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 both filters are deleted. I've found a post from Dimitry V. Ketov in the kernel list on may/2003 with a situation like this one, but there are no answers. I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? I'm suposed to be able to delete filters separately right? May it be a bug? Deleting the whole qdisc is not an opition in my setup and trying to delete the parent class gives me a "device or resource busy" error because of the filters. tc class del doesn't seen to delete its "child" filter. tks for any information... Andre From telles@devel-it.com.br Thu Jan 8 18:46:55 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Thu, 08 Jan 2004 16:46:55 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFD829F.304@pobox.com> References: <3FFD829F.304@pobox.com> Message-ID: <3FFDA59F.2070700@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre, I've had the same problem when I try to remove one filter rule. This is ocurred when you have the same prio for all filter rules. I've "solved" my problem using diferent "prio" values in filter rules. I don't now if this is a BUG ! Anything else ? Telles Andre Correa wrote: | | Hi list, I'm playing with tc and found a strange behavior when I try to | delete filters. For example, this simple scenario: | | tc qdisc add dev eth1 root handle 1: htb default 100 | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | 10.10.10.20 flowid 1:2 | | works just fine, but when I try to delete oen of the filters with | something like this: | | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src | 10.10.10.20 flowid 1:2 | | both filters are deleted. | | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 | with a situation like this one, but there are no answers. | | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? | I'm suposed to be able to delete filters separately right? May it be a bug? | | Deleting the whole qdisc is not an opition in my setup and trying to | delete the parent class gives me a "device or resource busy" error | because of the filters. tc class del doesn't seen to delete its "child" | filter. | | tks for any information... | | Andre | | _______________________________________________ | LARTC mailing list / LARTC@mailman.ds9a.nl | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//aWeiLK8unYgEMQRAgPcAJ9iqsF9V5m4QqKrLgI3iUF6rLW8hACeJ0GP 6DYjQf0/5NVNRrojAXvgcw8= =d0PR -----END PGP SIGNATURE----- From rsmckown@yahoo.com Thu Jan 8 18:15:37 2004 From: rsmckown@yahoo.com (R. Steve McKown) Date: Thu, 8 Jan 2004 11:15:37 -0700 Subject: [LARTC] Random ping jumps In-Reply-To: <3FFC7969.1040103@h2o.pieva.net> References: <3FFC7969.1040103@h2o.pieva.net> Message-ID: <200401081115.39334.rsmckown@yahoo.com> Can you provide some more detail on your network configuration? I'm unclea= r=20 if the linux server is your internet router or just another client computer= =20 on your local LAN, where the test pings to "the internet" are going (i.e.=20 nexthop router, etc.), and if/where CIPE tunnels are involved in the=20 equation. Perhaps a small network map would be helpful. I'm also unclear about the pings that you've tried. After you've shown the= =20 network map, perhaps you can identify the two machines (and interfaces)=20 involved in each of the different ping tests you've performed. I had a similar problem recently. A linux-based router with four interface= s=20 serving three local LANs and a T-1 (via the provider's router) to the=20 internet. The router was forwarding traffic between all combinations of=20 networks (that were allowed by rule) correctly, except between LANs 1 and 2= =2E =20 In this case, pings would vary much as in your case. Interestingly, it=20 turned out to be bad hardware. Moved the boot media to an identically=20 configured machine and the problem went away. Returned the boot media to t= he=20 original machine and the problem returned. On Wednesday 07 January 2004 02:26 pm, Art=C5=ABras =C5=A0lajus wrote: > Hello, > > I've got this problem. There is an linux server with 2.4.24 kernel > and pinging from him to internet (or from lan) ping randomly jumps up: > > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=3D387 ttl=3D59 > time=3D30.0 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=3D= 388 > ttl=3D59 time=3D32.6 ms 64 bytes from fortas.ktu.lt (193.219.160.131): > icmp_seq=3D389 ttl=3D59 time=3D34.9 ms 64 bytes from fortas.ktu.lt > (193.219.160.131): icmp_seq=3D390 ttl=3D59 time=3D198 ms 64 bytes from > fortas.ktu.lt (193.219.160.131): icmp_seq=3D391 ttl=3D59 time=3D407 ms 64= bytes > from fortas.ktu.lt (193.219.160.131): icmp_seq=3D392 ttl=3D59 time=3D407 = ms 64 > bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=3D393 ttl=3D59 time= =3D430 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=3D394 ttl=3D59 > time=3D30.9 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=3D= 395 > ttl=3D59 time=3D31.6 ms > > Internet line isn't loaded up, server load fine. QOS isn't used, qdiscs > default. I don't realize what the problem is and even how to debug it. > Sysctl config: net/ipv4/ip_forward =3D 1 > net/ipv4/icmp_ignore_bogus_error_responses =3D 1 > net/ipv4/icmp_echo_ignore_broadcasts =3D 1 > net/ipv4/tcp_syncookies =3D 1 > net/ipv4/tcp_timestamps =3D 0 > net/ipv4/tcp_window_scaling =3D 0 > net/ipv4/tcp_sack =3D 0 > net/ipv4/tcp_fin_timeout =3D 30 > net/ipv4/tcp_keepalive_time =3D 1800 > net/ipv4/tcp_low_latency =3D 1 > > Thanks for any thoughts. > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From stef.coene@docum.org Thu Jan 8 19:02:13 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 8 Jan 2004 20:02:13 +0100 Subject: [LARTC] Again,Bandwidth&htb In-Reply-To: <1073555410.2495.19.camel@testbox.co.za> References: <1073456413.2496.5.camel@testbox.co.za> <200401071809.52233.stef.coene@docum.org> <1073555410.2495.19.camel@testbox.co.za> Message-ID: <200401082002.13209.stef.coene@docum.org> On Thursday 08 January 2004 10:50, Eddie wrote: > OK but how do I specify a range of ports,for examples 15000-15010 > 15000:15010?? You can't with u32. But you can use iptables to mark packets and filter the packets with the fw filter. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From telles@devel-it.com.br Thu Jan 8 19:27:56 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Thu, 08 Jan 2004 17:27:56 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFDA59F.2070700@devel-it.com.br> References: <3FFD829F.304@pobox.com> <3FFDA59F.2070700@devel-it.com.br> Message-ID: <3FFDAF3C.6040206@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre, In my last e-mail about deleting filters (I'm sorry): s/Anything else ?/Anyone has idea about that strange "problem" ?/ Stef ? Telles Rodrigo P. Telles wrote: | Andre, | | I've had the same problem when I try to remove one filter rule. | This is ocurred when you have the same prio for all filter rules. I've | "solved" | my problem using diferent "prio" values in filter rules. | I don't now if this is a BUG ! | | Anything else ? | | Telles | | Andre Correa wrote: | | | | Hi list, I'm playing with tc and found a strange behavior when I try to | | delete filters. For example, this simple scenario: | | | | tc qdisc add dev eth1 root handle 1: htb default 100 | | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit | | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit | | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit | | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 | | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 flowid 1:2 | | | | works just fine, but when I try to delete oen of the filters with | | something like this: | | | | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 flowid 1:2 | | | | both filters are deleted. | | | | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 | | with a situation like this one, but there are no answers. | | | | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? | | I'm suposed to be able to delete filters separately right? May it be a | bug? | | | | Deleting the whole qdisc is not an opition in my setup and trying to | | delete the parent class gives me a "device or resource busy" error | | because of the filters. tc class del doesn't seen to delete its "child" | | filter. | | | | tks for any information... | | | | Andre | | | | _______________________________________________ | | LARTC mailing list / LARTC@mailman.ds9a.nl | | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | | | | | -- | ------------------------------------------------------ | Rodrigo P. Telles | Gerente de Projetos - http://www.devel-it.com.br | Devel-IT - Uma empresa do Grupo TDKOM | ------------------------------------------------------ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//a88iLK8unYgEMQRAkJ1AJ498bVg/9cOGlmlnkpNVsb0WudUlACfUny6 Wz0hejIwM5z3cz417//1LCg= =f/u2 -----END PGP SIGNATURE----- From x11@h2o.pieva.net Thu Jan 8 20:01:28 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 08 Jan 2004 22:01:28 +0200 Subject: [LARTC] Random ping jumps In-Reply-To: <200401081115.39334.rsmckown@yahoo.com> References: <3FFC7969.1040103@h2o.pieva.net> <200401081115.39334.rsmckown@yahoo.com> Message-ID: <3FFDB718.7080303@h2o.pieva.net> R. Steve McKown wrote: > Can you provide some more detail on your network configuration? I'm unclear > if the linux server is your internet router or just another client computer > on your local LAN It's network router. > , where the test pings to "the internet" are going (i.e. > nexthop router, etc.), and if/where CIPE tunnels are involved in the > equation. Perhaps a small network map would be helpful. No CIPE (whatever is that ;-). Nexthop? You mean gateway? eth0:1 Link encap:Ethernet HWaddr 00:50:22:B1:67:6D inet addr:81.7.84.36 Bcast:81.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 Interrupt:10 Base address:0xd000 gateway: 81.7.84.1 Map is at http://h2o.pieva.net/net.png > I'm also unclear about the pings that you've tried. After you've shown the > network map, perhaps you can identify the two machines (and interfaces) > involved in each of the different ping tests you've performed. The machine is totaly random. x11@rasnet:~$ traceroute fortas.ktu.lt traceroute to fortas.ktu.lt (193.219.160.131), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 26.269 ms 23.333 ms 25.156 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 63.079 ms 33.146 ms 26.117 ms 3 telecom-gw.is.lt (193.219.13.99) 35.978 ms 26.476 ms 103.138 ms 4 litnet-gw.is.lt (193.219.13.98) 22.715 ms 24.531 ms 209.984 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 52.826 ms 98.040 ms 81.609 ms 6 ktu-lan.litnet.lt (193.219.61.252) 38.696 ms 182.582 ms 241.836 ms 7 fortas.ktu.lt (193.219.160.131) 215.523 ms 126.815 ms 29.217 ms x11@rasnet:~$ traceroute cs.mes.lt traceroute to cs.mes.lt (193.219.67.253), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 748.174 ms 66.331 ms 135.586 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 21.645 ms 21.588 ms 24.597 ms 3 telecom-gw.is.lt (193.219.13.99) 30.584 ms 31.065 ms 29.612 ms 4 litnet-gw.is.lt (193.219.13.98) 24.602 ms 143.212 ms 143.096 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 292.196 ms 163.870 ms 84.549 ms 6 ktu-lan.litnet.lt (193.219.61.252) 84.982 ms 54.801 ms 69.143 ms 7 diz.ktu.lt (193.219.67.253) 33.831 ms 29.877 ms 30.005 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=5 ttl=59 time=34.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=6 ttl=59 time=32.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=7 ttl=59 time=33.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=8 ttl=59 time=324 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=9 ttl=59 time=836 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=10 ttl=59 time=850 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=11 ttl=59 time=321 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=12 ttl=59 time=147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=13 ttl=59 time=115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=14 ttl=59 time=118 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=15 ttl=59 time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=16 ttl=59 time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=17 ttl=59 time=272 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=18 ttl=59 time=312 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=19 ttl=59 time=102 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=20 ttl=59 time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=21 ttl=59 time=114 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=22 ttl=59 time=89.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=23 ttl=59 time=91.2 ms x11@rasnet:~$ traceroute cs.bbd.lt traceroute to cs.bbd.lt (193.219.184.7), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 23.803 ms 24.813 ms 56.163 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 171.425 ms 21.174 ms 24.321 ms 3 telecom-gw.is.lt (193.219.13.99) 27.882 ms 30.782 ms 26.219 ms 4 litnet-gw.is.lt (193.219.13.98) 22.842 ms 23.025 ms 24.079 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 24.201 ms 25.130 ms 27.256 ms 6 ktu-lan.litnet.lt (193.219.61.252) 26.811 ms 27.362 ms 27.785 ms 7 193.219.184.7 (193.219.184.7) 27.928 ms 29.185 ms 28.067 ms x11@rasnet:~$ ping cs.bbd.lt PING cs.bbd.lt (193.219.184.7) 56(84) bytes of data. 64 bytes from 193.219.184.7: icmp_seq=1 ttl=123 time=133 ms 64 bytes from 193.219.184.7: icmp_seq=2 ttl=123 time=122 ms 64 bytes from 193.219.184.7: icmp_seq=3 ttl=123 time=118 ms 64 bytes from 193.219.184.7: icmp_seq=4 ttl=123 time=109 ms 64 bytes from 193.219.184.7: icmp_seq=5 ttl=123 time=725 ms 64 bytes from 193.219.184.7: icmp_seq=6 ttl=123 time=668 ms 64 bytes from 193.219.184.7: icmp_seq=7 ttl=123 time=120 ms 64 bytes from 193.219.184.7: icmp_seq=8 ttl=123 time=102 ms 64 bytes from 193.219.184.7: icmp_seq=9 ttl=123 time=91.5 ms 64 bytes from 193.219.184.7: icmp_seq=10 ttl=123 time=91.7 ms > I had a similar problem recently. Interestingly, it > turned out to be bad hardware. Another person told me that bad hw could be reason. But it works for LAN perfectly. > Moved the boot media to an identically > configured machine and the problem went away. Returned the boot media to the > original machine and the problem returned. Sad, but i can't do that :( My /etc/network/interfaces: auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 autho eth0:1 iface eth0:1 inet static address 81.7.84.36 netmask 255.0.0.0 gateway 81.7.84.1 mtu 1492 I hadn't set mtu before. After setting it ping times decreased. (afterall it's dsl). Also, what exatcly net/ipv4/tcp_low_latency = 1 in sysctl do? -- Sincerely, ArtÅ«ras Å lajus ICQ: 157929934 Jabber: arturaz@akl.lt Oh, and please'o'please use UTF-8! :-) From andre.correa@pobox.com Thu Jan 8 18:02:20 2004 From: andre.correa@pobox.com (Andre Correa) Date: Thu, 08 Jan 2004 16:02:20 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFDA59F.2070700@devel-it.com.br> References: <3FFD829F.304@pobox.com> <3FFDA59F.2070700@devel-it.com.br> Message-ID: <3FFD9B2C.2040800@pobox.com> Hi Rodrigo, tks for the answer. It sounds like a starting point but this is not that good if there are several filters pointing to classes with high load. In this case lower prio classes will really have higher priority. Isn't it supposed to work as expected: delete only the right filter? May it be reported as a bug? Is it a known behavior? tks... Andre Rodrigo P. Telles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andre, > > I've had the same problem when I try to remove one filter rule. > This is ocurred when you have the same prio for all filter rules. I've > "solved" > my problem using diferent "prio" values in filter rules. > I don't now if this is a BUG ! > > Anything else ? > > Telles > > Andre Correa wrote: > | > | Hi list, I'm playing with tc and found a strange behavior when I try to > | delete filters. For example, this simple scenario: > | > | tc qdisc add dev eth1 root handle 1: htb default 100 > | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit > | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit > | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit > | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src > | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 > | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src > | 10.10.10.20 flowid 1:2 > | > | works just fine, but when I try to delete oen of the filters with > | something like this: > | > | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src > | 10.10.10.20 flowid 1:2 > | > | both filters are deleted. > | > | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 > | with a situation like this one, but there are no answers. > | > | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? > | I'm suposed to be able to delete filters separately right? May it be a > bug? > | > | Deleting the whole qdisc is not an opition in my setup and trying to > | delete the parent class gives me a "device or resource busy" error > | because of the filters. tc class del doesn't seen to delete its "child" > | filter. > | > | tks for any information... > | > | Andre > | > | _______________________________________________ > | LARTC mailing list / LARTC@mailman.ds9a.nl > | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > | > | > > - -- > - ------------------------------------------------------ > Rodrigo P. Telles > Gerente de Projetos - http://www.devel-it.com.br > Devel-IT - Uma empresa do Grupo TDKOM > - ------------------------------------------------------ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQE//aWeiLK8unYgEMQRAgPcAJ9iqsF9V5m4QqKrLgI3iUF6rLW8hACeJ0GP > 6DYjQf0/5NVNRrojAXvgcw8= > =d0PR > -----END PGP SIGNATURE----- > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From andre.correa@pobox.com Thu Jan 8 19:02:31 2004 From: andre.correa@pobox.com (Andre Correa) Date: Thu, 08 Jan 2004 17:02:31 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFDBE2B.4090700@trash.net> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> Message-ID: <3FFDA947.2070504@pobox.com> Patrick, tks for the info but I'm sure I got your idea. A filter handle is something like: "804::800" right? I've tried this (supose classes 1:1 and 1:2 exist): tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 match ip src 10.10.10.10 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.11 flowid 1:2 and then: tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 but both filter are deleted... Am I missing something? tks a lot... Andre Patrick McHardy wrote: > Andre Correa wrote: > >> >> Hi list, I'm playing with tc and found a strange behavior when I try >> to delete filters. For example, this simple scenario: >> >> tc qdisc add dev eth1 root handle 1: htb default 100 >> tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit >> tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit >> tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit >> tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src >> 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 >> tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src >> 10.10.10.20 flowid 1:2 >> >> works just fine, but when I try to delete oen of the filters with >> something like this: >> >> tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src >> 10.10.10.20 flowid 1:2 >> >> both filters are deleted. > > > The kernel only regards priorities when deleting a filter without > giving a handle. Use the handle if you want to delete a specific filter. > > Regards, > Patricky > > > From kaber@trash.net Thu Jan 8 21:26:24 2004 From: kaber@trash.net (Patrick McHardy) Date: Thu, 08 Jan 2004 22:26:24 +0100 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFDA947.2070504@pobox.com> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> Message-ID: <3FFDCB00.6000908@trash.net> Andre Correa wrote: > > Patrick, tks for the info but I'm sure I got your idea. > > A filter handle is something like: "804::800" right? Not exactly. How handles are handled depends on the classifier, fw classifier for example uses its own handle to match the nfmark, route creates handles of its own and errors if the handle supplied from userspace differs. Maybe a example clears things up: tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 filter protocol ip pref 1 route filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 As you can see the route classifier uses realm | 0x8000. tc filter del dev lo pref 1 handle 0x00048000 route tc filter del dev lo pref 1 handle 0x00058000 route tc filter del dev lo pref 1 handle 0x00068000 route tc filter del dev lo pref 1 handle 0x00078000 route tc filter del dev lo pref 1 handle 0x00088000 route filter protocol ip pref 1 route Only the container of the single filters is left. To destroy it, delete by priority: "tc filter del dev lo pref 1". Hope that helps. Patrick > I've tried this (supose classes 1:1 and 1:2 exist): > > tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 > match ip src 10.10.10.10 flowid 1:1 > tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 > match ip src 10.10.10.11 flowid 1:2 > > and then: > > tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 > > but both filter are deleted... > > Am I missing something? > > tks a lot... > > Andre > From kaber@trash.net Thu Jan 8 20:31:39 2004 From: kaber@trash.net (Patrick McHardy) Date: Thu, 08 Jan 2004 21:31:39 +0100 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFD829F.304@pobox.com> References: <3FFD829F.304@pobox.com> Message-ID: <3FFDBE2B.4090700@trash.net> Andre Correa wrote: > > Hi list, I'm playing with tc and found a strange behavior when I try > to delete filters. For example, this simple scenario: > > tc qdisc add dev eth1 root handle 1: htb default 100 > tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit > tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit > tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit > tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src > 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 > tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src > 10.10.10.20 flowid 1:2 > > works just fine, but when I try to delete oen of the filters with > something like this: > > tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src > 10.10.10.20 flowid 1:2 > > both filters are deleted. The kernel only regards priorities when deleting a filter without giving a handle. Use the handle if you want to delete a specific filter. Regards, Patricky From telles@devel-it.com.br Thu Jan 8 22:55:06 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Thu, 08 Jan 2004 20:55:06 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFD9B2C.2040800@pobox.com> References: <3FFD829F.304@pobox.com> <3FFDA59F.2070700@devel-it.com.br> <3FFD9B2C.2040800@pobox.com> Message-ID: <3FFDDFCA.60005@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre, I don't now, when I've had that problem, I didn't find anything about that ! I've tried to report this problem, but all mails that I sent to the list, they had simply desappeared, and I've found this "solution" (for my case this solution is good). Later, my mail was started to work and I forgot to notify the list about that. I remembered that when I saw your mail about filter rules :-) I expect that someone have an idea about that, because is impossible that only you and me are having this behavior. Telles Andre Correa wrote: | | Hi Rodrigo, tks for the answer. It sounds like a starting point but this | is not that good if there are several filters pointing to classes with | high load. In this case lower prio classes will really have higher | priority. | | Isn't it supposed to work as expected: delete only the right filter? May | it be reported as a bug? Is it a known behavior? | | tks... | | Andre | | | Rodrigo P. Telles wrote: | |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Andre, |> |> I've had the same problem when I try to remove one filter rule. |> This is ocurred when you have the same prio for all filter rules. I've |> "solved" |> my problem using diferent "prio" values in filter rules. |> I don't now if this is a BUG ! |> |> Anything else ? |> |> Telles |> |> Andre Correa wrote: |> | |> | Hi list, I'm playing with tc and found a strange behavior when I try to |> | delete filters. For example, this simple scenario: |> | |> | tc qdisc add dev eth1 root handle 1: htb default 100 |> | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit |> | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit |> | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit |> | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src |> | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 |> | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src |> | 10.10.10.20 flowid 1:2 |> | |> | works just fine, but when I try to delete oen of the filters with |> | something like this: |> | |> | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src |> | 10.10.10.20 flowid 1:2 |> | |> | both filters are deleted. |> | |> | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 |> | with a situation like this one, but there are no answers. |> | |> | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? |> | I'm suposed to be able to delete filters separately right? May it be |> a bug? |> | |> | Deleting the whole qdisc is not an opition in my setup and trying to |> | delete the parent class gives me a "device or resource busy" error |> | because of the filters. tc class del doesn't seen to delete its "child" |> | filter. |> | |> | tks for any information... |> | |> | Andre |> | |> | _______________________________________________ |> | LARTC mailing list / LARTC@mailman.ds9a.nl |> | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ |> | |> | |> |> - -- |> - ------------------------------------------------------ |> Rodrigo P. Telles |> Gerente de Projetos - http://www.devel-it.com.br |> Devel-IT - Uma empresa do Grupo TDKOM |> - ------------------------------------------------------ |> -----BEGIN PGP SIGNATURE----- |> Version: GnuPG v1.0.7 (GNU/Linux) |> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |> |> iD8DBQE//aWeiLK8unYgEMQRAgPcAJ9iqsF9V5m4QqKrLgI3iUF6rLW8hACeJ0GP |> 6DYjQf0/5NVNRrojAXvgcw8= |> =d0PR |> -----END PGP SIGNATURE----- |> |> _______________________________________________ |> 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/ | | | - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//d/KiLK8unYgEMQRAlgLAJ4torQ3qVFfOLujnSMiFUkKG+CiIgCfZ2q9 jTggAS7kT2eIyiMnNqeEvEk= =bzBz -----END PGP SIGNATURE----- From telles@devel-it.com.br Thu Jan 8 23:32:37 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Thu, 08 Jan 2004 21:32:37 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFDCB00.6000908@trash.net> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> Message-ID: <3FFDE895.1040309@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick, Based in your explanation, I tried that: # adding root qdisc, class and filters tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:10 htb rate 768Kbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate 512Kbit tc class add dev eth0 parent 1:1 classid 1:12 htb rate 256Kbit tc qdisc add dev eth0 parent 1:11 handle 11: sfq tc qdisc add dev eth0 parent 1:12 handle 12: sfq tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.10 flowid 1:11 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip src 10.10.10.11 flowid 1:12 # tc filter show dev eth0 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::11 order 17 key ht 800 bkt 0 flowid 1:11 ~ match 0a0a0a0a/ffffffff at 12 filter parent 1: protocol ip pref 1 u32 fh 800::12 order 18 key ht 800 bkt 0 flowid 1:12 ~ match 0a0a0a0b/ffffffff at 12 # deleting a rule tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 Must specify filter type when using "handle" Humm, I got back to LARTC Howto, but I can't found anything about "filter type" ! What's wrong ? Telles Patrick McHardy wrote: | Andre Correa wrote: | |> |> Patrick, tks for the info but I'm sure I got your idea. |> |> A filter handle is something like: "804::800" right? | | | Not exactly. How handles are handled depends on the classifier, | fw classifier for example uses its own handle to match the nfmark, | route creates handles of its own and errors if the handle supplied | from userspace differs. | | Maybe a example clears things up: | | tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 | tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 | tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 | tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 | tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 | | | filter protocol ip pref 1 route | filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 | filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 | filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 | filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 | filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 | | As you can see the route classifier uses realm | 0x8000. | | | tc filter del dev lo pref 1 handle 0x00048000 route | tc filter del dev lo pref 1 handle 0x00058000 route | tc filter del dev lo pref 1 handle 0x00068000 route | tc filter del dev lo pref 1 handle 0x00078000 route | tc filter del dev lo pref 1 handle 0x00088000 route | | | filter protocol ip pref 1 route | | Only the container of the single filters is left. To destroy it, delete by | priority: "tc filter del dev lo pref 1". | | Hope that helps. | | Patrick | | |> I've tried this (supose classes 1:1 and 1:2 exist): |> |> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 |> match ip src 10.10.10.10 flowid 1:1 |> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 |> match ip src 10.10.10.11 flowid 1:2 |> |> and then: |> |> tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 |> |> but both filter are deleted... |> |> Am I missing something? |> |> tks a lot... |> |> Andre |> | | | _______________________________________________ | LARTC mailing list / LARTC@mailman.ds9a.nl | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//eiViLK8unYgEMQRAv1PAJ96witXRlYUwPW5fqDySWURu3VLcQCdGrx3 Ly6eZtiaSTtrWMrpPm9MxnQ= =rhE2 -----END PGP SIGNATURE----- From andybr@bol.com.br Fri Jan 9 01:57:39 2004 From: andybr@bol.com.br (andybr) Date: Thu, 8 Jan 2004 23:57:39 -0200 Subject: [LARTC] Again,Bandwidth&htb Message-ID: Hi all, 1.) You can put in your internal interface to slow down the traffic. 2.) You set the filter by single ip or network. []=B4s Anderson > Good Day All > Just 2 questions on htb > > 1,My Wan link is on eth1 and my Lan on eth0,where do I put my htb on?I > want to limit web serving and ftp ens. > > 2.Im going to use the u32 filter.Can I use sub- netting for IP,i.o.w > where src is can I do 192.168.1.0/24? > > Thanks and Please Help > Eddie > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From rsmckown@yahoo.com Fri Jan 9 02:43:48 2004 From: rsmckown@yahoo.com (R. Steve McKown) Date: Thu, 8 Jan 2004 19:43:48 -0700 Subject: [LARTC] Random ping jumps In-Reply-To: <3FFDB718.7080303@h2o.pieva.net> References: <3FFC7969.1040103@h2o.pieva.net> <200401081115.39334.rsmckown@yahoo.com> <3FFDB718.7080303@h2o.pieva.net> Message-ID: <200401081943.49913.rsmckown@yahoo.com> On Thursday 08 January 2004 01:01 pm, Art=C5=ABras =C5=A0lajus wrote: > Map is at http://h2o.pieva.net/net.png Ah, nice. > > I'm also unclear about the pings that you've tried. After you've shown > > the network map, perhaps you can identify the two machines (and > > interfaces) involved in each of the different ping tests you've > > performed. > > The machine is totaly random. What happens if you ping from the linux box to the linux box's default=20 gateway? If the problem doesn't exhibit in this test nor in any test betwe= en=20 machines in your LAN, the problem is probably your providers: the DSL modem= =20 or something 'downstream' from it. You should consider doing tests #2 and = #3=20 anyway as support for your position when you call your ISP to open a troubl= e=20 ticket. If the latency problem does exhibit pinging from the linux box to the defau= lt=20 gateway, you haven't learned much yet. Continue testing by removing=20 variables, attempting to isolate the smallest 'configuration' that exhibits= =20 the problem. The variables are: computers, hubs/switches, cables, and the= =20 like. Here's some suggestions for testing: 1. plug the linux router directly into the DSL modem and ping from the rout= er=20 to the default gateway. If the problem goes away, it's something in the=20 hardware and cables that were 'bypassed' in this test. You can continue th= is=20 strategy to test into your network. Read my security note below. 2. plug a PC, configured as the linux router's eth0:1 interface (with prope= r=20 default gateway) and ping from the pc to the default gateway. If the probl= em=20 goes away, its probably the linux router (hardware or software). 3. If #1 and #2 don't cause it to go away, be sure you used a different cab= le=20 in tests #1 and #2. If the problem still doesn't go away, it's an issue fo= r=20 your network provider. * security note * Running both your LAN and the internet provider subnets on the same etherne= t=20 network puts you at a much greater security risk. You should seriously=20 consider installing a third network interface into your linux box and movin= g=20 eth0:1's ip info to eth2. Then plug the DSL modem into eth2 with a=20 cross-over cable with no computers attached. I'm guessing your thirty users using Windows. If they have windows network= =20 enabled, they are all generating broadcast traffic. That traffic will most= =20 likely be crossing the DSL modem (since it is bridging). Aside from securi= ty=20 implications, the local traffic that does get bridged is tying up your DSL= =20 bandwidth. It seems unlikely that 30 PC's could saturate your 128kbps=20 uplink, but I'm no expert on windows networking. 128kbps is not a huge pip= e,=20 so perhaps it's possible. If so, the solution to your security problem is= =20 also the solution to the latency variability issue. If this is the case,=20 both tests #2 and #3 will not show the variability, since your local LAN is= =20 effectively removed from the test. Hope this helps, Steve > x11@rasnet:~$ traceroute fortas.ktu.lt > traceroute to fortas.ktu.lt (193.219.160.131), 30 hops max, 38 byte packe= ts > 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 26.269 ms 23.333 ms= =20 > 25.156 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 63.079 ms 33.1= 46 > ms 26.117 ms 3 telecom-gw.is.lt (193.219.13.99) 35.978 ms 26.476 ms=20 > 103.138 ms 4 litnet-gw.is.lt (193.219.13.98) 22.715 ms 24.531 ms=20 > 209.984 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 52.826 ms=20 > 98.040 ms 81.609 ms 6 ktu-lan.litnet.lt (193.219.61.252) 38.696 ms=20 > 182.582 ms 241.836 ms 7 fortas.ktu.lt (193.219.160.131) 215.523 ms=20 > 126.815 ms 29.217 ms > > x11@rasnet:~$ traceroute cs.mes.lt > traceroute to cs.mes.lt (193.219.67.253), 30 hops max, 38 byte packets > 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 748.174 ms 66.331 m= s=20 > 135.586 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 21.645 ms=20 > 21.588 ms 24.597 ms 3 telecom-gw.is.lt (193.219.13.99) 30.584 ms 31.0= 65 > ms 29.612 ms 4 litnet-gw.is.lt (193.219.13.98) 24.602 ms 143.212 ms=20 > 143.096 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 292.196 ms=20 > 163.870 ms 84.549 ms 6 ktu-lan.litnet.lt (193.219.61.252) 84.982 ms=20 > 54.801 ms 69.143 ms 7 diz.ktu.lt (193.219.67.253) 33.831 ms 29.877 ms= =20 > 30.005 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D5 ttl=3D59 > time=3D34.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D6 tt= l=3D59 > time=3D32.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D7 tt= l=3D59 > time=3D33.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D8 tt= l=3D59 > time=3D324 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D9 ttl= =3D59 > time=3D836 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D10 tt= l=3D59 > time=3D850 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D11 tt= l=3D59 > time=3D321 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D12 tt= l=3D59 > time=3D147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D13 tt= l=3D59 > time=3D115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D14 tt= l=3D59 > time=3D118 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D15 tt= l=3D59 > time=3D107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D16 tt= l=3D59 > time=3D107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D17 tt= l=3D59 > time=3D272 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D18 tt= l=3D59 > time=3D312 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D19 tt= l=3D59 > time=3D102 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D20 tt= l=3D59 > time=3D107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D21 tt= l=3D59 > time=3D114 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D22 tt= l=3D59 > time=3D89.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D23 t= tl=3D59 > time=3D91.2 ms > > x11@rasnet:~$ traceroute cs.bbd.lt > traceroute to cs.bbd.lt (193.219.184.7), 30 hops max, 38 byte packets > 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 23.803 ms 24.813 ms= =20 > 56.163 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 171.425 ms=20 > 21.174 ms 24.321 ms 3 telecom-gw.is.lt (193.219.13.99) 27.882 ms 30.7= 82 > ms 26.219 ms 4 litnet-gw.is.lt (193.219.13.98) 22.842 ms 23.025 ms=20 > 24.079 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 24.201 ms=20 > 25.130 ms 27.256 ms 6 ktu-lan.litnet.lt (193.219.61.252) 26.811 ms=20 > 27.362 ms 27.785 ms 7 193.219.184.7 (193.219.184.7) 27.928 ms 29.185 = ms > 28.067 ms x11@rasnet:~$ ping cs.bbd.lt > PING cs.bbd.lt (193.219.184.7) 56(84) bytes of data. > 64 bytes from 193.219.184.7: icmp_seq=3D1 ttl=3D123 time=3D133 ms > 64 bytes from 193.219.184.7: icmp_seq=3D2 ttl=3D123 time=3D122 ms > 64 bytes from 193.219.184.7: icmp_seq=3D3 ttl=3D123 time=3D118 ms > 64 bytes from 193.219.184.7: icmp_seq=3D4 ttl=3D123 time=3D109 ms > 64 bytes from 193.219.184.7: icmp_seq=3D5 ttl=3D123 time=3D725 ms > 64 bytes from 193.219.184.7: icmp_seq=3D6 ttl=3D123 time=3D668 ms > 64 bytes from 193.219.184.7: icmp_seq=3D7 ttl=3D123 time=3D120 ms > 64 bytes from 193.219.184.7: icmp_seq=3D8 ttl=3D123 time=3D102 ms > 64 bytes from 193.219.184.7: icmp_seq=3D9 ttl=3D123 time=3D91.5 ms > 64 bytes from 193.219.184.7: icmp_seq=3D10 ttl=3D123 time=3D91.7 ms > > > I had a similar problem recently. Interestingly, it > > turned out to be bad hardware. > > Another person told me that bad hw could be reason. But it works for > LAN perfectly. > > > Moved the boot media to an identically > > > > configured machine and the problem went away. Returned the boot media = to > > the original machine and the problem returned. > > Sad, but i can't do that :( > > My /etc/network/interfaces: > auto eth0 > iface eth0 inet static > address 192.168.0.1 > netmask 255.255.255.0 > > autho eth0:1 > iface eth0:1 inet static > address 81.7.84.36 > netmask 255.0.0.0 > gateway 81.7.84.1 > mtu 1492 > > I hadn't set mtu before. After setting it ping times decreased. (afterall > it's dsl). Also, what exatcly net/ipv4/tcp_low_latency =3D 1 in sysctl do? From rajkumars@asianetindia.com Thu Jan 8 20:09:20 2004 From: rajkumars@asianetindia.com (Rajkumar S) Date: Fri, 09 Jan 2004 01:39:20 +0530 Subject: [LARTC] [ot]Bridging and Cisco switch Message-ID: <3FFDB8F0.60209@asianetindia.com> Hi, I was trying to setup QoS for my network in my machine. It had a Ethernet interface connected to a cisco switch. I connected one more interface on to the same switch and setup and bridge, zeroed out both the interfaces and assigned my old ip to the bridge interface. After this when I pinged outside, all the lights in my switch started blinking fast. I immediately pulled the network cable from my box. Is the configuration I attempted "legal"? Is their any problem with bridges and Switchs? When a packet comes to bridge ip, which interface does it go? I am bit confused! Thanks for your help raj From x11@h2o.pieva.net Fri Jan 9 07:23:21 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Fri, 09 Jan 2004 09:23:21 +0200 Subject: [LARTC] Random ping jumps In-Reply-To: <200401081943.49913.rsmckown@yahoo.com> References: <3FFC7969.1040103@h2o.pieva.net> <200401081115.39334.rsmckown@yahoo.com> <3FFDB718.7080303@h2o.pieva.net> <200401081943.49913.rsmckown@yahoo.com> Message-ID: <3FFE56E9.1030505@h2o.pieva.net> R. Steve McKown wrote: > What happens if you ping from the linux box to the linux box's default > gateway? If the problem doesn't exhibit in this test nor in any test between > machines in your LAN, the problem is probably your providers: the DSL modem > or something 'downstream' from it. You should consider doing tests #2 and #3 > anyway as support for your position when you call your ISP to open a trouble > ticket. It's not an ISP. Now it's morning and only 5 users online. The ping is flawless... Well almost :) Hostname Last 50 pings 1. adsl-213-190-40-129.taka ..........>....................................... 2. fe22-acc0-tai.kns.teleco ..........c...................................... 3. telecom-gw.is.lt ..........b...................................... 4. litnet-gw.is.lt .........3a...................................... 5. cat6506-p2-1.kttc.litnet .........b3...1a................................. 6. ktu-lan.litnet.lt .........c..........................1............ 7. diz.ktu.lt .........>......1................................ Scale: .:30 ms 1:46 ms 2:62 ms 3:99 ms a:193 ms b:283 ms c:441 ms > 2. plug a PC, configured as the linux router's eth0:1 interface (with proper > default gateway) and ping from the pc to the default gateway. If the problem > goes away, its probably the linux router (hardware or software). The problem goes away. I tried it here on my winxp box. > * security note * > > Running both your LAN and the internet provider subnets on the same ethernet > network puts you at a much greater security risk. You should seriously > consider installing a third network interface into your linux box and moving > eth0:1's ip info to eth2. Then plug the DSL modem into eth2 with a > cross-over cable with no computers attached. Huh, would be great, but there is one but. Modem is at one house and server is at another :) It's zyxel, maybe he has allow by mac or sth. I will look at his firmware setup. Or maybe you have some thoughts how to connect server and modem? (about 200 m) :) > I'm guessing your thirty users using Windows. If they have windows network > enabled, they are all generating broadcast traffic. That traffic will most > likely be crossing the DSL modem (since it is bridging). Aside from security > implications, the local traffic that does get bridged is tying up your DSL > bandwidth. It seems unlikely that 30 PC's could saturate your 128kbps > uplink, but I'm no expert on windows networking. 128kbps is not a huge pipe, > so perhaps it's possible. If so, the solution to your security problem is > also the solution to the latency variability issue. If this is the case, > both tests #2 and #3 will not show the variability, since your local LAN is > effectively removed from the test. Yes, this may be true and solution. But is C class subnet traffic routed? I think it isn't. It seems that when many users is browsing or doing normal day activities such as email checking and irc download/upload? is saturated and it causes ping jumps. I will try to move ACKs into front of queue and also prioritize some traffic. Bad that tc syntax is so unreadable.. Once it took 4 days for me to write tc script ;-) Also as roy mentioned, there is no such ip: 81.7.84.1 But if i set nexthop as my gw it says net unreachable... Maybe that gw has multiple addresses or some magic is done on ISP side. -- Sincerely, ArtÅ«ras Å lajus ICQ: 157929934 Jabber: arturaz@akl.lt Oh, and please'o'please use UTF-8! :-) From eddieknows@ananzi.co.za Fri Jan 9 07:41:03 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Fri, 09 Jan 2004 09:41:03 +0200 Subject: [LARTC] ap 450 Message-ID: <1073634063.2477.4.camel@testbox.co.za> Good dat all I have a Lucent AP450 I'm havin trouble administratin it with the web interface under linux.Under windows all seem to be 100 but the menus is not showing under linux.I dont think this is a ap proble maybe a mozilla.I dont know.Anyone have the same problem? Thanks Eddie From x11@h2o.pieva.net Fri Jan 9 07:07:47 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Fri, 09 Jan 2004 09:07:47 +0200 Subject: [LARTC] Random ping jumps In-Reply-To: <016e01c3d635$96a1e930$030aa8c0@t> References: <3FFC7969.1040103@h2o.pieva.net> <200401081115.39334.rsmckown@yahoo.com> <3FFDB718.7080303@h2o.pieva.net> <016e01c3d635$96a1e930$030aa8c0@t> Message-ID: <3FFE5343.3070900@h2o.pieva.net> Roy wrote: > Your network configutration is nonsense > you say > >> address 81.7.84.36 >> gateway 81.7.84.1 > > > trace shows > > > traceroute to fortas.ktu.lt (193.219.160.131), 30 hops max, 38 byte > packets > yor computer> 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 26.269 ms > 23.333 ms 25.156 ms > gateway > 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 63.079 ms > 33.146 ms 26.117 ms > >> 3 telecom-gw.is.lt (193.219.13.99) 35.978 ms 26.476 ms 103.138 ms >> 4 litnet-gw.is.lt (193.219.13.98) 22.715 ms 24.531 ms 209.984 ms > > > so everything incorect Yes, that's DAMN strange... From x11@h2o.pieva.net Fri Jan 9 07:51:32 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Fri, 09 Jan 2004 09:51:32 +0200 Subject: [LARTC] ap 450 In-Reply-To: <1073634063.2477.4.camel@testbox.co.za> References: <1073634063.2477.4.camel@testbox.co.za> Message-ID: <3FFE5D84.40006@h2o.pieva.net> Eddie wrote: > Good dat all > I have a Lucent AP450 > I'm havin trouble administratin it with the web interface under > linux.Under windows all seem to be 100 but the menus is not showing > under linux.I dont think this is a ap proble maybe a mozilla.I dont > know.Anyone have the same problem? Probably menus are some IEscript (formerly javascript ;-) based so you need to install ie under wine... Try using mozilla under windows, if it's same then it's got to be it. -- Sincerely, Artûras Ãlajus ICQ: 157929934 Jabber: arturaz@akl.lt Oh, and please'o'please use UTF-8! :-) From telles@devel-it.com.br Fri Jan 9 10:45:37 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Fri, 09 Jan 2004 08:45:37 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> <3FFDE895.1040309@devel-it.com.br> Message-ID: <3FFE8651.8000506@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars, I knew that (I use this form, but with handle, it doesn't work), but if what you said is truth, the folowing command would have work: tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip src 10.10.10.10 flowid 1:12 RTNETLINK answers: No such file or directory |>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip src 10.10.10.11 flowid 1:12 What you thing about that ? Telles Lars Landmark wrote: | | Hi Rodrigo; | | When you add a new filter rule, you write "tc filter add .....". If you | now substitute add with del, you are able to delete the right filter | without any other filters being deleted. | | Hope this helps. | | Lars | | | On Thu, 8 Jan 2004, Rodrigo P. Telles wrote: | | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Patrick, |> |>Based in your explanation, I tried that: |> |># adding root qdisc, class and filters |>tc qdisc add dev eth0 root handle 1: htb |>tc class add dev eth0 parent 1: classid 1:10 htb rate 768Kbit |>tc class add dev eth0 parent 1:1 classid 1:11 htb rate 512Kbit |>tc class add dev eth0 parent 1:1 classid 1:12 htb rate 256Kbit |> |>tc qdisc add dev eth0 parent 1:11 handle 11: sfq |>tc qdisc add dev eth0 parent 1:12 handle 12: sfq |> |>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::11 u32 match ip |>src 10.10.10.10 flowid 1:11 |>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip |>src 10.10.10.11 flowid 1:12 |> |># tc filter show dev eth0 |>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::11 order 17 key ht 800 bkt 0 |>flowid 1:11 |>~ match 0a0a0a0a/ffffffff at 12 |>filter parent 1: protocol ip pref 1 u32 fh 800::12 order 18 key ht 800 bkt 0 |>flowid 1:12 |>~ match 0a0a0a0b/ffffffff at 12 |> |># deleting a rule |>tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 |>Must specify filter type when using "handle" |> |>Humm, I got back to LARTC Howto, but I can't found anything about "filter type" ! |> |>What's wrong ? |> |>Telles |> |> |>Patrick McHardy wrote: |>| Andre Correa wrote: |>| |>|> |>|> Patrick, tks for the info but I'm sure I got your idea. |>|> |>|> A filter handle is something like: "804::800" right? |>| |>| |>| Not exactly. How handles are handled depends on the classifier, |>| fw classifier for example uses its own handle to match the nfmark, |>| route creates handles of its own and errors if the handle supplied |>| from userspace differs. |>| |>| Maybe a example clears things up: |>| |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 |>| |>| |>| filter protocol ip pref 1 route |>| filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 |>| filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 |>| filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 |>| filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 |>| filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 |>| |>| As you can see the route classifier uses realm | 0x8000. |>| |>| |>| tc filter del dev lo pref 1 handle 0x00048000 route |>| tc filter del dev lo pref 1 handle 0x00058000 route |>| tc filter del dev lo pref 1 handle 0x00068000 route |>| tc filter del dev lo pref 1 handle 0x00078000 route |>| tc filter del dev lo pref 1 handle 0x00088000 route |>| |>| |>| filter protocol ip pref 1 route |>| |>| Only the container of the single filters is left. To destroy it, delete by |>| priority: "tc filter del dev lo pref 1". |>| |>| Hope that helps. |>| |>| Patrick |>| |>| |>|> I've tried this (supose classes 1:1 and 1:2 exist): |>|> |>|> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 |>|> match ip src 10.10.10.10 flowid 1:1 |>|> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 |>|> match ip src 10.10.10.11 flowid 1:2 |>|> |>|> and then: |>|> |>|> tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 |>|> |>|> but both filter are deleted... |>|> |>|> Am I missing something? |>|> |>|> tks a lot... |>|> |>|> Andre |>|> |>| |>| |>| _______________________________________________ |>| LARTC mailing list / LARTC@mailman.ds9a.nl |>| http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ |>| |>| |> |>- -- |>- ------------------------------------------------------ |>Rodrigo P. Telles |>Gerente de Projetos - http://www.devel-it.com.br |>Devel-IT - Uma empresa do Grupo TDKOM |>- ------------------------------------------------------ |>-----BEGIN PGP SIGNATURE----- |>Version: GnuPG v1.0.7 (GNU/Linux) |>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |> |>iD8DBQE//eiViLK8unYgEMQRAv1PAJ96witXRlYUwPW5fqDySWURu3VLcQCdGrx3 |>Ly6eZtiaSTtrWMrpPm9MxnQ= |>=rhE2 |>-----END PGP SIGNATURE----- |> |>_______________________________________________ |>LARTC mailing list / LARTC@mailman.ds9a.nl |>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ |> | | | - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//oZRiLK8unYgEMQRArqRAJwN4Ho/a7sQHVQAejb32iIdNbKYqACdG7kI C+1AYYFiTKvXabVcluSnR6E= =C9Xe -----END PGP SIGNATURE----- From larslan@solan.zapto.org Fri Jan 9 11:00:11 2004 From: larslan@solan.zapto.org (Lars Landmark) Date: Fri, 9 Jan 2004 12:00:11 +0100 (CET) Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFE8651.8000506@devel-it.com.br> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> <3FFDE895.1040309@devel-it.com.br> <3FFE8651.8000506@devel-it.com.br> Message-ID: Hi; no clue :-( May I ask why you are using "handle" and not "parent" since HTB is used? And what eventually are the differences? Lars > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lars, > > I knew that (I use this form, but with handle, it doesn't work), but if what you > said is truth, the folowing command would have work: > > tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip > src 10.10.10.10 flowid 1:12 > RTNETLINK answers: No such file or directory > > |>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip > src 10.10.10.11 flowid 1:12 > > What you thing about that ? > > Telles > > Lars Landmark wrote: > | > | Hi Rodrigo; > | > | When you add a new filter rule, you write "tc filter add .....". If you > | now substitute add with del, you are able to delete the right filter > | without any other filters being deleted. > | > | Hope this helps. > | > | Lars > | > | > | On Thu, 8 Jan 2004, Rodrigo P. Telles wrote: > | > | > |>-----BEGIN PGP SIGNED MESSAGE----- > |>Hash: SHA1 > |> > |>Patrick, > |> > |>Based in your explanation, I tried that: > |> > |># adding root qdisc, class and filters > |>tc qdisc add dev eth0 root handle 1: htb > |>tc class add dev eth0 parent 1: classid 1:10 htb rate 768Kbit > |>tc class add dev eth0 parent 1:1 classid 1:11 htb rate 512Kbit > |>tc class add dev eth0 parent 1:1 classid 1:12 htb rate 256Kbit > |> > |>tc qdisc add dev eth0 parent 1:11 handle 11: sfq > |>tc qdisc add dev eth0 parent 1:12 handle 12: sfq > |> > |>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::11 u32 match ip > |>src 10.10.10.10 flowid 1:11 > |>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip > |>src 10.10.10.11 flowid 1:12 > |> > |># tc filter show dev eth0 > |>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::11 order 17 key ht 800 bkt 0 > |>flowid 1:11 > |>~ match 0a0a0a0a/ffffffff at 12 > |>filter parent 1: protocol ip pref 1 u32 fh 800::12 order 18 key ht 800 bkt 0 > |>flowid 1:12 > |>~ match 0a0a0a0b/ffffffff at 12 > |> > |># deleting a rule > |>tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 > |>Must specify filter type when using "handle" > |> > |>Humm, I got back to LARTC Howto, but I can't found anything about "filter type" ! > |> > |>What's wrong ? > |> > |>Telles > |> > |> > |>Patrick McHardy wrote: > |>| Andre Correa wrote: > |>| > |>|> > |>|> Patrick, tks for the info but I'm sure I got your idea. > |>|> > |>|> A filter handle is something like: "804::800" right? > |>| > |>| > |>| Not exactly. How handles are handled depends on the classifier, > |>| fw classifier for example uses its own handle to match the nfmark, > |>| route creates handles of its own and errors if the handle supplied > |>| from userspace differs. > |>| > |>| Maybe a example clears things up: > |>| > |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 > |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 > |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 > |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 > |>| tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 > |>| > |>| > |>| filter protocol ip pref 1 route > |>| filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 > |>| filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 > |>| filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 > |>| filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 > |>| filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 > |>| > |>| As you can see the route classifier uses realm | 0x8000. > |>| > |>| > |>| tc filter del dev lo pref 1 handle 0x00048000 route > |>| tc filter del dev lo pref 1 handle 0x00058000 route > |>| tc filter del dev lo pref 1 handle 0x00068000 route > |>| tc filter del dev lo pref 1 handle 0x00078000 route > |>| tc filter del dev lo pref 1 handle 0x00088000 route > |>| > |>| > |>| filter protocol ip pref 1 route > |>| > |>| Only the container of the single filters is left. To destroy it, delete by > |>| priority: "tc filter del dev lo pref 1". > |>| > |>| Hope that helps. > |>| > |>| Patrick > |>| > |>| > |>|> I've tried this (supose classes 1:1 and 1:2 exist): > |>|> > |>|> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 > |>|> match ip src 10.10.10.10 flowid 1:1 > |>|> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 > |>|> match ip src 10.10.10.11 flowid 1:2 > |>|> > |>|> and then: > |>|> > |>|> tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 > |>|> > |>|> but both filter are deleted... > |>|> > |>|> Am I missing something? > |>|> > |>|> tks a lot... > |>|> > |>|> Andre > |>|> > |>| > |>| > |>| _______________________________________________ > |>| LARTC mailing list / LARTC@mailman.ds9a.nl > |>| http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > |>| > |>| > |> > |>- -- > |>- ------------------------------------------------------ > |>Rodrigo P. Telles > |>Gerente de Projetos - http://www.devel-it.com.br > |>Devel-IT - Uma empresa do Grupo TDKOM > |>- ------------------------------------------------------ > |>-----BEGIN PGP SIGNATURE----- > |>Version: GnuPG v1.0.7 (GNU/Linux) > |>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > |> > |>iD8DBQE//eiViLK8unYgEMQRAv1PAJ96witXRlYUwPW5fqDySWURu3VLcQCdGrx3 > |>Ly6eZtiaSTtrWMrpPm9MxnQ= > |>=rhE2 > |>-----END PGP SIGNATURE----- > |> > |>_______________________________________________ > |>LARTC mailing list / LARTC@mailman.ds9a.nl > |>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > |> > | > | > | > > - -- > - ------------------------------------------------------ > Rodrigo P. Telles > Gerente de Projetos - http://www.devel-it.com.br > Devel-IT - Uma empresa do Grupo TDKOM > - ------------------------------------------------------ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQE//oZRiLK8unYgEMQRArqRAJwN4Ho/a7sQHVQAejb32iIdNbKYqACdG7kI > C+1AYYFiTKvXabVcluSnR6E= > =C9Xe > -----END PGP SIGNATURE----- > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From telles@devel-it.com.br Fri Jan 9 11:27:16 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Fri, 09 Jan 2004 09:27:16 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> <3FFDE895.1040309@devel-it.com.br> <3FFE8651.8000506@devel-it.com.br> Message-ID: <3FFE9014.2060401@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars, It's about the discussion of "deleting filter rules", and this "method" (using handle) was explaned by Patrick (see the list history). Telles Lars Landmark wrote: | Hi; | | no clue :-( | May I ask why you are using "handle" and not "parent" since HTB is used? | And what eventually are the differences? | | Lars | | | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Lars, |> |>I knew that (I use this form, but with handle, it doesn't work), but if what you |>said is truth, the folowing command would have work: |> |>tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip |>src 10.10.10.10 flowid 1:12 |>RTNETLINK answers: No such file or directory |> |>|>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip |>src 10.10.10.11 flowid 1:12 |> |>What you thing about that ? |> |>Telles |> |>Lars Landmark wrote: |>| |>| Hi Rodrigo; |>| |>| When you add a new filter rule, you write "tc filter add .....". If you |>| now substitute add with del, you are able to delete the right filter |>| without any other filters being deleted. |>| |>| Hope this helps. |>| |>| Lars |>| |>| |>| On Thu, 8 Jan 2004, Rodrigo P. Telles wrote: |>| |>| |>|>-----BEGIN PGP SIGNED MESSAGE----- |>|>Hash: SHA1 |>|> |>|>Patrick, |>|> |>|>Based in your explanation, I tried that: |>|> |>|># adding root qdisc, class and filters |>|>tc qdisc add dev eth0 root handle 1: htb |>|>tc class add dev eth0 parent 1: classid 1:10 htb rate 768Kbit |>|>tc class add dev eth0 parent 1:1 classid 1:11 htb rate 512Kbit |>|>tc class add dev eth0 parent 1:1 classid 1:12 htb rate 256Kbit |>|> |>|>tc qdisc add dev eth0 parent 1:11 handle 11: sfq |>|>tc qdisc add dev eth0 parent 1:12 handle 12: sfq |>|> |>|>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::11 u32 match ip |>|>src 10.10.10.10 flowid 1:11 |>|>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip |>|>src 10.10.10.11 flowid 1:12 |>|> |>|># tc filter show dev eth0 |>|>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::11 order 17 key ht 800 bkt 0 |>|>flowid 1:11 |>|>~ match 0a0a0a0a/ffffffff at 12 |>|>filter parent 1: protocol ip pref 1 u32 fh 800::12 order 18 key ht 800 bkt 0 |>|>flowid 1:12 |>|>~ match 0a0a0a0b/ffffffff at 12 |>|> |>|># deleting a rule |>|>tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 |>|>Must specify filter type when using "handle" |>|> |>|>Humm, I got back to LARTC Howto, but I can't found anything about "filter type" ! |>|> |>|>What's wrong ? |>|> |>|>Telles |>|> |>|> |>|>Patrick McHardy wrote: |>|>| Andre Correa wrote: |>|>| |>|>|> |>|>|> Patrick, tks for the info but I'm sure I got your idea. |>|>|> |>|>|> A filter handle is something like: "804::800" right? |>|>| |>|>| |>|>| Not exactly. How handles are handled depends on the classifier, |>|>| fw classifier for example uses its own handle to match the nfmark, |>|>| route creates handles of its own and errors if the handle supplied |>|>| from userspace differs. |>|>| |>|>| Maybe a example clears things up: |>|>| |>|>| tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 |>|>| tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 |>|>| tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 |>|>| tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 |>|>| tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 |>|>| |>|>| |>|>| filter protocol ip pref 1 route |>|>| filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 |>|>| filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 |>|>| filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 |>|>| filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 |>|>| filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 |>|>| |>|>| As you can see the route classifier uses realm | 0x8000. |>|>| |>|>| |>|>| tc filter del dev lo pref 1 handle 0x00048000 route |>|>| tc filter del dev lo pref 1 handle 0x00058000 route |>|>| tc filter del dev lo pref 1 handle 0x00068000 route |>|>| tc filter del dev lo pref 1 handle 0x00078000 route |>|>| tc filter del dev lo pref 1 handle 0x00088000 route |>|>| |>|>| |>|>| filter protocol ip pref 1 route |>|>| |>|>| Only the container of the single filters is left. To destroy it, delete by |>|>| priority: "tc filter del dev lo pref 1". |>|>| |>|>| Hope that helps. |>|>| |>|>| Patrick |>|>| |>|>| |>|>|> I've tried this (supose classes 1:1 and 1:2 exist): |>|>|> |>|>|> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 |>|>|> match ip src 10.10.10.10 flowid 1:1 |>|>|> tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 |>|>|> match ip src 10.10.10.11 flowid 1:2 |>|>|> |>|>|> and then: |>|>|> |>|>|> tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 |>|>|> |>|>|> but both filter are deleted... |>|>|> |>|>|> Am I missing something? |>|>|> |>|>|> tks a lot... |>|>|> |>|>|> Andre |>|>|> |>|>| |>|>| |>|>| _______________________________________________ |>|>| LARTC mailing list / LARTC@mailman.ds9a.nl |>|>| http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ |>|>| |>|>| |>|> |>|>- -- |>|>- ------------------------------------------------------ |>|>Rodrigo P. Telles |>|>Gerente de Projetos - http://www.devel-it.com.br |>|>Devel-IT - Uma empresa do Grupo TDKOM |>|>- ------------------------------------------------------ |>|>-----BEGIN PGP SIGNATURE----- |>|>Version: GnuPG v1.0.7 (GNU/Linux) |>|>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |>|> |>|>iD8DBQE//eiViLK8unYgEMQRAv1PAJ96witXRlYUwPW5fqDySWURu3VLcQCdGrx3 |>|>Ly6eZtiaSTtrWMrpPm9MxnQ= |>|>=rhE2 |>|>-----END PGP SIGNATURE----- |>|> |>|>_______________________________________________ |>|>LARTC mailing list / LARTC@mailman.ds9a.nl |>|>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ |>|> |>| |>| |>| |> |>- -- |>- ------------------------------------------------------ |>Rodrigo P. Telles |>Gerente de Projetos - http://www.devel-it.com.br |>Devel-IT - Uma empresa do Grupo TDKOM |>- ------------------------------------------------------ |>-----BEGIN PGP SIGNATURE----- |>Version: GnuPG v1.0.7 (GNU/Linux) |>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |> |>iD8DBQE//oZRiLK8unYgEMQRArqRAJwN4Ho/a7sQHVQAejb32iIdNbKYqACdG7kI |>C+1AYYFiTKvXabVcluSnR6E= |>=C9Xe |>-----END PGP SIGNATURE----- |> |>_______________________________________________ |>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/ | | - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//pAUiLK8unYgEMQRAjeLAJ9ZCyPiKNcoENEgcCvfzIF1wJ2IlgCfel0D BmAJ97csB8BxXywGwmLVrDM= =JpSS -----END PGP SIGNATURE----- From andre.correa@pobox.com Fri Jan 9 13:37:54 2004 From: andre.correa@pobox.com (Andre Correa) Date: Fri, 09 Jan 2004 11:37:54 -0200 Subject: [LARTC] Strange behavior deleting filters In-Reply-To: <3FFE9014.2060401@devel-it.com.br> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> <3FFDE895.1040309@devel-it.com.br> <3FFE8651.8000506@devel-it.com.br> <3FFE9014.2060401@devel-it.com.br> Message-ID: <3FFEAEB2.6040505@pobox.com> The matter here is not really about using parent or handle (wich I'm still not confortable with), but it is about the way a filter should be deleted. In situations like mine I cannot just delete filters by parent, because parent qdiscs have dozens of child classes each one with a filter poiting to it. If I have to "disable a customer", for example, I need to delete its classes and consequently its filters, and today it is not possible. Using Rodrigo's trick with prio is doing the job, but doesn't look like the right way to do it. I'm not involved in tc, HTB or any other kernel-related development but in my user point of view the sintax to add and delete filters should be the same and when I delete a filter just that specific filter should be delete, not all those that have the same prio. Maybe there was some important problem during development that made it difficult or impossible to be this way, we don't know yet... Just getting back to the basic sitation, when I try (supose classes 1:1 and 1:2 exist): tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 match ip src 10.10.10.10 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.11 flowid 1:2 and then: tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 both filter are deleted... and it is supposed to delete just the second filter. With or without handle the same result is reproducible in my setup and in Rodrigo's too. Anybody else have the same behavior or it is just us? My kernel is 2.4.23. Anyway filters are still a bit difficult to fully understand. There are too many undocumented options that should be described in Advanced-Routing-HOWTO or somewhere else... Where is the active development of tc going on for 2.4? May we report it as a bug there? Is the Advanced-Routing-Howto being updated? I would like to help with it... tc is doing such a good job here that I want to give something back to the community... tks in advance... Andre Rodrigo P. Telles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lars, > > It's about the discussion of "deleting filter rules", and this "method" > (using > handle) was explaned by Patrick (see the list history). > > Telles > > Lars Landmark wrote: > | Hi; > | > | no clue :-( > | May I ask why you are using "handle" and not "parent" since HTB is used? > | And what eventually are the differences? > | > | Lars > | > | > | > |>-----BEGIN PGP SIGNED MESSAGE----- > |>Hash: SHA1 > |> > |>Lars, > |> > |>I knew that (I use this form, but with handle, it doesn't work), but > if what you > |>said is truth, the folowing command would have work: > |> > |>tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 > match ip > |>src 10.10.10.10 flowid 1:12 > |>RTNETLINK answers: No such file or directory > |> > |>|>tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 > match ip > |>src 10.10.10.11 flowid 1:12 > |> > |>What you thing about that ? > |> > |>Telles > |> From tatooin@kelkoo.com Fri Jan 9 18:28:47 2004 From: tatooin@kelkoo.com (Vincent Jaussaud) Date: Fri, 09 Jan 2004 19:28:47 +0100 Subject: [LARTC] High speed traffic filtering Message-ID: <1073672927.23676.102.camel@tatooin.kelkoo.net> Hi; First, sorry if this question is mostly netfilter related, than lartc, but I think you guys may have a your opinion about this. I'm using Linux 2.4.x with netfilter packet filtering / NAT on our front-end firewalls (P500 with 1Gb RAM), which are filtering traffic going to our Public Web Sites. The traffic is growing very fast since several months.. The average traffic filtered by our firewalls, is around 30/40 Mbits/s, with peaks around 70 Mbits/s sometimes, so that we had to switch to gigabit technologies, to keep a good safe margin. Our firewalls are not so high speed machines (P500 with 1Gb RAM), but are doing good so far. It seems, however, that we are reaching the limits, when approaching 70 Mb/s... cpu utilization is then near 100%, and the machines start dropping packets. So, my question is, is netfilter able to handle, let's say gigabit traffic filtering ? What kind of hardware would be necessary to handle such traffic ? Have you guys any experience with filtering such high speed traffic ? I also thought of two possible solutions, to optimize our current firewalls, on which you may have an opinion. 1) Disabling statefull inspection, by unloading connection tracking modules. I believe netfilter without connection tracking, might be much more efficient (We don't need connection tracking actually, since we are only filtering HTTP traffic from the others traffics at this point) 2) Replace iptables by nf-hipac for packet filtering. Have you guys any experience with nf-hipac ? (http://www.hipac.org/) I would be really thanksfull to hear of any solutions / workarounds / optimization to keep our linux firewalls handling growing traffic :-) Thanks ! Vincent. --- Vincent Jaussaud Kelkoo.com Security Manager email: tatooin@kelkoo.com "Those who desire to give up freedom in order to gain security will not have, nor do they deserve, either one." -- President Thomas Jefferson. 1743-1826 From andre.correa@pobox.com Fri Jan 9 19:08:24 2004 From: andre.correa@pobox.com (Andre Correa) Date: Fri, 09 Jan 2004 17:08:24 -0200 Subject: [LARTC] Some good news - Strange behavior deleting filters In-Reply-To: <20040109104649.A10514@crescent.rt.cs.boeing.com> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> <3FFDE895.1040309@devel-it.com.br> <3FFE8651.8000506@devel-it.com.br> <3FFE9014.2060401@devel-it.com.br> <3FFEAEB2.6040505@pobox.com> <20040109104649.A10514@crescent.rt.cs.boeing.com> Message-ID: <3FFEFC28.9070301@pobox.com> Hi list, I've got a private e-mail from O. Brewer pointing something important that we hadn't figured out yet: tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1:0 htb tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1mbit tc class add dev eth1 parent 1:0 classid 1:2 htb rate 1mbit tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle ::10 u32 match ip src 10.10.10.10 classid 1:1 tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.11 classid 1:2 tc -r filter show dev eth1 parent 1: filter protocol ip pref 1 u32 filter protocol ip pref 1 u32 fh 800:[80000000] ht divisor 1 filter protocol ip pref 1 u32 fh 800::10[80000010] order 16 key ht 800 bkt 0 flowid 1:1 match 0a0a0a0a/ffffffff at 12 filter protocol ip pref 1 u32 fh 800::11[80000011] order 17 key ht 800 bkt 0 flowid 1:2 match 0a0a0a0b/ffffffff at 12 tc filter del dev eth1 parent 1: protocol ip prio 1 handle 800::11 u32 tc -r filter show dev eth1 parent 1: filter protocol ip pref 1 u32 filter protocol ip pref 1 u32 fh 800:[80000000] ht divisor 1 filter protocol ip pref 1 u32 fh 800::10[80000010] order 16 key ht 800 bkt 0 flowid 1:1 match 0a0a0a0a/ffffffff at 12 as we expect... So we figure out that using handle and u32 in the end of our command line works fine. Good... There is still a lot of trouble to figure out what is the value of handle XXX::yy when it is a script that manages filters, but it is better then nothing... tks for pointing this out Orlie... Anybody else replicated the behavior? Does anybody know is tc development is taking place? tks a lot... Andre From kaber@trash.net Fri Jan 9 23:10:16 2004 From: kaber@trash.net (Patrick McHardy) Date: Sat, 10 Jan 2004 00:10:16 +0100 Subject: [LARTC] High speed traffic filtering In-Reply-To: <1073672927.23676.102.camel@tatooin.kelkoo.net> References: <1073672927.23676.102.camel@tatooin.kelkoo.net> Message-ID: <3FFF34D8.8000507@trash.net> Vincent Jaussaud wrote: > Hi; > > First, sorry if this question is mostly netfilter related, than lartc, > but I think you guys may have a your opinion about this. You should post this question to the netfilter-devel list, people there can give you very good advice. > > I'm using Linux 2.4.x with netfilter packet filtering / NAT on our > front-end firewalls (P500 with 1Gb RAM), which are filtering traffic > going to our Public Web Sites. > > The traffic is growing very fast since several months.. The average > traffic filtered by our firewalls, is around 30/40 Mbits/s, with peaks > around 70 Mbits/s sometimes, so that we had to switch to gigabit > technologies, to keep a good safe margin. > > Our firewalls are not so high speed machines (P500 with 1Gb RAM), but > are doing good so far. > > It seems, however, that we are reaching the limits, when approaching 70 > Mb/s... cpu utilization is then near 100%, and the machines start > dropping packets. > > So, my question is, is netfilter able to handle, let's say gigabit > traffic filtering ? What kind of hardware would be necessary to handle > such traffic ? > > Have you guys any experience with filtering such high speed traffic ? Netfilter sure is able to handle 1gbit, but it doesn't depend that much on the raw speed. The number of conntracks and simultaneos active connections matters much more. > I also thought of two possible solutions, to optimize our current > firewalls, on which you may have an opinion. > > 1) Disabling statefull inspection, by unloading connection tracking > modules. > I believe netfilter without connection tracking, might be much more > efficient (We don't need connection tracking actually, since we are only > filtering HTTP traffic from the others traffics at this point) That might help, although without stateful filtering the rules have to be evaluated for each single packet. > 2) Replace iptables by nf-hipac for packet filtering. Have you guys any > experience with nf-hipac ? (http://www.hipac.org/) nf-hipac is very good with a large number of rules, for just http filtering I suspect iptables will do equally good or better. > > I would be really thanksfull to hear of any solutions / workarounds / > optimization to keep our linux firewalls handling growing traffic :-) Try without conntrack if you don't need it, otherwise start with increasing the hash table size and limit ip_conntrack_max to 2 times the hash size. There was a thread about optimizing iptables on netfilter-devel 1-2 month ago, it was started by Hervé Eychenne, search the archives. Best regards, Patrick > > Thanks ! > Vincent. > > --- > > Vincent Jaussaud > Kelkoo.com Security Manager > email: tatooin@kelkoo.com > > "Those who desire to give up freedom in order to gain security will not > have, nor do they deserve, either one." > -- President Thomas Jefferson. 1743-1826 > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From jayesh_rathod@sify.com Sat Jan 10 05:28:43 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Sat, 10 Jan 2004 11:28:43 +0600 (IST) Subject: [LARTC] setting quantum values Message-ID: <1073714323.3fff9493e2c30@webmail7.maa.sify.net> Hi, when we add a class we get an error "HTB Quantum too small,or too big" i read in docum.org that we need to set the quantun value which should be >1500 and <60000. but i need to add classes with diff type of rates. eg : Min : 32 kbit and Max : 512 kbit. now in this case how do i set my quantum value which satifies all types of rates. Pls let me know,This is very urgent for me. Regadrs Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From jayesh_rathod@sify.com Sat Jan 10 05:22:33 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Sat, 10 Jan 2004 11:22:33 +0600 (IST) Subject: [LARTC] htb info needed Message-ID: <1073713953.3fff9321f34d3@webmail7.maa.sify.net> Hi, Want to know few things abt tc rules getting stored. 1.When a tc rule is added where does tc store it( in memory or in some flat file or some DB). 2.When the rules are added does it do any I/O operations. Regards Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From tusharthakker@elitecore.com Sat Jan 10 19:20:43 2004 From: tusharthakker@elitecore.com (Tushar Thakker) Date: Sat, 10 Jan 2004 11:20:43 -0800 Subject: [LARTC] Two routing cache entries with different interface Message-ID: <006501c3d7ae$f60945b0$3301a8c0@elitecore1> This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C3D76B.C9066D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, i am setting up a load balancing netwrok with failover, i have applied julian patch, but whenever i try to traceroute from any client node, it gives me two = entries for that destination, but i get different interface for that = entries, so it doesn't forward my requests, i have done masquerading for client nodes, the ip rule/route are as follows, ip rule add prio 222 table 222 ip route add default table 222 proto static \ nexthop via $GWE1 dev $IFE1 weight 1\ nexthop via $GWE2 dev $IFE2 weight 1 Now after traceroute failure, if i see the routing cache for that ip, it = shows following, 205.158.62.141 via 203.88.135.213 dev eth1 src 203.88.135.212=20 cache mtu 1500 advmss 1460 205.158.62.141 from 192.168.1.51 via 203.88.135.205 dev eth2 src = 192.168.1.242=20 cache mtu 1500 advmss 1460 iif eth0 please see eth1 and eth2 in both entries, now it does not forward this request, what can be the reason behind this and please can anyone suggest me the = solution, thanx in advance, Regards, ---------------------------------------------------------------- Tushar Thakker Elitecore Technologies Ltd. ---------------------------------------------------------------- Life gives all that one deserves, but not all that one desires... ---------------------------------------------------------------- ------=_NextPart_000_005B_01C3D76B.C9066D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi all,
i am setting up a load balancing = netwrok with=20 failover,
i have applied julian = patch,
but whenever i try to traceroute from = any client=20 node, it gives me two entries for that destination, but i get different=20 interface for that entries,
so it doesn't forward my = requests,
i have done masquerading for client=20 nodes,
 
the ip rule/route are as = follows,
 
        ip rule=20 add prio 222 table 222
        ip = route=20 add default table 222 proto static=20 \
           &n= bsp;   =20 nexthop via $GWE1 dev $IFE1 weight=20 1\
           &= nbsp;   =20 nexthop via $GWE2 dev $IFE2 weight 1
 
Now after traceroute failure, if i see = the routing=20 cache for that ip, it shows following,
 
205.158.62.141 via 203.88.135.213 dev=20 eth1  src 203.88.135.212
   =20 cache  mtu 1500 advmss 1460
205.158.62.141 from 192.168.1.51 via = 203.88.135.205 dev eth2  src 192.168.1.242=20
    cache <src-direct>  mtu 1500 advmss = 1460 iif=20 eth0
 
please see eth1 and eth2 in both=20 entries,
now it does not forward this = request,
what can be the reason behind this and = please can=20 anyone suggest me the solution,
thanx in advance,
Regards,
 
----------------------------------------------------------------=
Tushar=20 Thakker
Elitecore Technologies=20 Ltd.
----------------------------------------------------------------<= BR>Life=20 gives all that one deserves, but not all that one=20 desires...
-----------------------------------------------------------= -----
------=_NextPart_000_005B_01C3D76B.C9066D60-- From ja@ssi.bg Sat Jan 10 10:41:34 2004 From: ja@ssi.bg (Julian Anastasov) Date: Sat, 10 Jan 2004 12:41:34 +0200 (EET) Subject: [LARTC] Two routing cache entries with different interface In-Reply-To: <006501c3d7ae$f60945b0$3301a8c0@elitecore1> Message-ID: Hello, On Sat, 10 Jan 2004, Tushar Thakker wrote: > hi all, > i am setting up a load balancing netwrok with failover, > i have applied julian patch, > but whenever i try to traceroute from any client node, it gives me two entries for that destination, but i get different interface for that entries, > so it doesn't forward my requests, > i have done masquerading for client nodes, > > the ip rule/route are as follows, > > ip rule add prio 222 table 222 > ip route add default table 222 proto static \ > nexthop via $GWE1 dev $IFE1 weight 1\ > nexthop via $GWE2 dev $IFE2 weight 1 > > Now after traceroute failure, if i see the routing cache for that ip, it shows following, output route, probably created from -j MASQUERADE?: > 205.158.62.141 via 203.88.135.213 dev eth1 src 203.88.135.212 > cache mtu 1500 advmss 1460 input route: > 205.158.62.141 from 192.168.1.51 via 203.88.135.205 dev eth2 src 192.168.1.242 > cache mtu 1500 advmss 1460 iif eth0 > > please see eth1 and eth2 in both entries, Nothing strange so far, may be they are created from different connections. In fact, there should be more cache entries. > now it does not forward this request, Can you provide more information, in private mail if you prefer so, including: - tcpdump output(s) for all interfaces during the traceroute - topology: are eth1 and eth2 connected to same hub? - ip rules and routes I hope you really have the "routes" patch applied and running. > what can be the reason behind this and please can anyone suggest me the solution, > thanx in advance, > Regards, > > ---------------------------------------------------------------- > Tushar Thakker > Elitecore Technologies Ltd. Regards -- Julian Anastasov From Robert Kurjata Sat Jan 10 13:03:05 2004 From: Robert Kurjata (Robert Kurjata) Date: Sat, 10 Jan 2004 14:03:05 +0100 Subject: Re[2]: [LARTC] Two routing cache entries with different interface In-Reply-To: References: <006501c3d7ae$f60945b0$3301a8c0@elitecore1> Message-ID: <1585420594.20040110140305@ire.pw.edu.pl> Witaj Julian, W Twoim liœcie datowanym 10 stycznia 2004 (11:41:34) mo¿na przeczytaæ: JA> Hello, JA> On Sat, 10 Jan 2004, Tushar Thakker wrote: >> hi all, >> i am setting up a load balancing netwrok with failover, >> i have applied julian patch, >> but whenever i try to traceroute from any client node, it gives >> me two entries for that destination, but i get different interface >> for that entries, >> so it doesn't forward my requests, >> i have done masquerading for client nodes, >> >> the ip rule/route are as follows, >> >> ip rule add prio 222 table 222 >> ip route add default table 222 proto static \ >> nexthop via $GWE1 dev $IFE1 weight 1\ >> nexthop via $GWE2 dev $IFE2 weight 1 >> >> Now after traceroute failure, if i see the routing cache for that ip, it shows following, JA> output route, probably created from -j MASQUERADE?: >> 205.158.62.141 via 203.88.135.213 dev eth1 src 203.88.135.212 >> cache mtu 1500 advmss 1460 JA> input route: >> 205.158.62.141 from 192.168.1.51 via 203.88.135.205 dev eth2 src 192.168.1.242 >> cache mtu 1500 advmss 1460 iif eth0 >> >> please see eth1 and eth2 in both entries, JA> Nothing strange so far, may be they are created from different JA> connections. In fact, there should be more cache entries. >> now it does not forward this request, JA> Can you provide more information, in private mail if you JA> prefer so, including: JA> - tcpdump output(s) for all interfaces during the traceroute JA> - topology: are eth1 and eth2 connected to same hub? JA> - ip rules and routes JA> I hope you really have the "routes" patch applied and JA> running. >> what can be the reason behind this and please can anyone suggest me the solution, >> thanx in advance, >> Regards, >> >> ---------------------------------------------------------------- >> Tushar Thakker >> Elitecore Technologies Ltd. JA> Regards JA> -- JA> Julian Anastasov JA> _______________________________________________ JA> LARTC mailing list / LARTC@mailman.ds9a.nl JA> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ try this, after applying routes patch it works fine (for me it works when I upgraded it to 3 uplinks): ---------------------------cut here------------------------------------------ #!/bin/bash # This script is done by : Robert Kurjata Sep, 2003. # feel free to use it in any usefull way # CONFIGURATION IP=/sbin/ip PING=/bin/ping #--------------- LINK PART ----------------- # EXTIFn - interface name # EXTIPn - outgoing IP # EXTMn - netmask length (bits) # EXTGWn - outgoing gateway #------------------------------------------- # LINK 1 EXTIF1=eth2 EXTIP1= EXTM1= EXTGW1= # LINK 2 EXTIF2=eth1 EXTIP2= EXTM2= EXTGW2= #ROUTING PART # removing old rules and routes echo "removing old rules" ${IP} rule del prio 50 table main ${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201 ${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202 ${IP} rule del prio 221 table 221 echo "flushing tables" ${IP} route flush table 201 ${IP} route flush table 202 ${IP} route flush table 221 echo "removing tables" ${IP} route del table 201 ${IP} route del table 202 ${IP} route del table 221 # setting new rules echo "Setting new routing rules" # main table w/o default gateway here ${IP} rule add prio 50 table main ${IP} route del default table main # identified routes here ${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201 ${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202 ${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201 ${IP} route append prohibit default table 201 metric 1 proto static ${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202 ${IP} route append prohibit default table 202 metric 1 proto static # mutipath ${IP} rule add prio 221 table 221 ${IP} route add default table 221 proto static \ nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\ nexthop via ${EXTGW2} dev ${EXTIF2} weight 3 ${IP} route flush cache while : ; do ${PING} -c 1 ${EXTGW1} ${PING} -c 1 ${EXTGW2} sleep 60 done ---------------------------cut here------------------------------------------ -- Pozdrowienia, Robert From lartc@innovabit.com Sat Jan 10 13:45:51 2004 From: lartc@innovabit.com (Carlos L) Date: Sat, 10 Jan 2004 14:45:51 +0100 Subject: [LARTC] Router serving several inet ips References: Message-ID: <000a01c3d780$0fa4a520$1000a8c0@keithar> Hi all, i have a router with debian 3.0 kernel 2.4.20, working with htb quite well, limiting bandwidth and doing port and ip priorizations. Now i want to server more than 1 internet ip, later i will do priorizations on each ip.. but.. i can´t manage yet the first thing. The idea is that it works as a "dhcp server", assigning the ips.. but the traffic must go through the linux box (so i can priorize and limit bandwidth). i have set up the second internet ip with ipalias in eth1:0, and it is active, i get ping from internet.. no problem.. but it does not work fine when i try to assign it to a private ip The idea is assigning 192.168.0.3 to eth1:0 (no natting, .. just the entire ip) The iptables after '#' is what i tried.. but it did not work, it gave me this message: debian:/etc/init.d# sh nat.sh Warning: weird character in interface `eth1:0' (No aliases, :, ! or *). Warning: weird character in interface `eth1:0' (No aliases, :, ! or *). iptables v1.2.7a: multiple -j flags not allowed Thanks in advance, Carlos The script, below.. #!/bin/sh echo "AthoS LaN Generando iptables..." > /dev/tty12 #limpiamos las tablas de iptables iptables -F iptables -t nat -F iptables -t filter -F #eth1 sera la interfaz de internet iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE #eth0 la interfaz de la red local iptables --append FORWARD --in-interface eth0 -j ACCEPT #iptables -t nat -F PREROUTING #iptables -t nat -P PREROUTING ACCEPT #iptables -t nat -F POSTROUTING #iptables -t nat -P POSTROUTING ACCEPT #iptables -t nat -A POSTROUTING -o eth1:0 #iptables -A FORWARD -i eth0 -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED #iptables -A FORWARD -i eth1:0 -j ACCEPT -m state --state ESTABLISHED,RELATED -j MASQUERADE #activamos el forward echo 1 > /proc/sys/net/ipv4/ip_forward #reglas para enrutado de paketes... #1.- redirecciona las peticiones del puerto 21 a mi pc iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 21 -j DNAT --to 192.168 .0.2:21 From will@netmindz.net Sat Jan 10 15:25:34 2004 From: will@netmindz.net (Will Tatam) Date: Sat, 10 Jan 2004 15:25:34 +0000 Subject: [LARTC] Newbie: Backup internet connection Message-ID: <4000196E.3060908@netmindz.net> I manage internet access for our company. We have our main link which is a 2 meg leased line, we then have a 2 meg adsl line for backup from a different ISP What i want is live failover for outgoing traffic, not only for complete link failures but also when then main isp has routing issues to a given ip range (e.g during the recent disruption to 2 of the transatlantic links) The solution should require little or no involvement from either isp, and if possible 'sensible routing'. What i mean by this is if we are making a connection to a ip that is on our backup ip's network it used that line rather than the main line I have had a quick look at both BGP and OSPF but was not sure if either of them was the right solution for me -- Will Tatam ------------------------------------------------------------ Email / JID will@netmindz.net Web www.netmindz.net PGP Key www.netmindz.net/will/will_tatam.asc ------------------------------------------------------------ Registered Linux user 294695 Linux Counter http://counter.li.org ------------------------------------------------------------ See http://www.jabber.org/ to find out more about the most advanced cross platform, open source enterprise messaging solution ------------------------------------------------------------ From Robert Kurjata Sat Jan 10 17:00:05 2004 From: Robert Kurjata (Robert Kurjata) Date: Sat, 10 Jan 2004 18:00:05 +0100 Subject: Re[4]: [LARTC] Two routing cache entries with different interface In-Reply-To: <028501c3d7ec$9b428ef0$3301a8c0@elitecore1> References: <006501c3d7ae$f60945b0$3301a8c0@elitecore1> <1585420594.20040110140305@ire.pw.edu.pl> <028501c3d7ec$9b428ef0$3301a8c0@elitecore1> Message-ID: <1891783384.20040110180005@ire.pw.edu.pl> Witaj Tushar, W Twoim liœcie datowanym 11 stycznia 2004 (03:42:51) mo¿na przeczytaæ: TT> hello, TT> i have seen the script you sent, TT> but i is for static load balancing, TT> but i want to do automatic load balancing, It is automatic load balancing. And it works for me with 3 uplinks dynamically shared at about 8 Mbits traffic. TT> allowing nodes to select the gateway dynamically, TT> so i think tables 201 and 202 are not needed, No, No, No! Please read the Nano-HOWTO Carefully. Those tables are essential for proper operation. They take care of the subsequent packets of the connection. After the first one is matched by multipath route the gateway is selected and the output adress is selected. Subsequent connection packets NEED to go through the SAME interface. Without additional tables they may (and probably will) go out through invalid interface with invalid source IP thus if there is properly configured router on their way (eg. a provider which filters packets not comming from their subnet) everything will die. (Info taken from Nano currently at: http://www.ssi.bg/~ja/nano.txt ). As you can see after reading my script is an adopted version of nano proved to work. TT> i want to use only 221 (table having nexthop), TT> and my gateway itself allocates connections very correctly, TT> but in case of requests from other nodes, it can not transfer, TT> i hope you would help me in this regard, TT> Thanx and regards, TT> ---------------------------------------------------------------- TT> Tushar Thakker TT> Elitecore Technologies Ltd. TT> ---------------------------------------------------------------- TT> Life gives all that one deserves, but not all that one desires... TT> ---------------------------------------------------------------- TT> ----- Original Message ----- TT> From: "Robert Kurjata" TT> To: "Julian Anastasov" TT> Cc: "Tushar Thakker" ; TT> Sent: Saturday, January 10, 2004 5:03 AM TT> Subject: Re[2]: [LARTC] Two routing cache entries with different interface >> Witaj Julian, >> >> W Twoim liœcie datowanym 10 stycznia 2004 (11:41:34) mo¿na przeczytaæ: >> >> >> JA> Hello, >> >> JA> On Sat, 10 Jan 2004, Tushar Thakker wrote: >> >> >> hi all, >> >> i am setting up a load balancing netwrok with failover, >> >> i have applied julian patch, >> >> but whenever i try to traceroute from any client node, it gives >> >> me two entries for that destination, but i get different interface >> >> for that entries, >> >> so it doesn't forward my requests, >> >> i have done masquerading for client nodes, >> >> >> >> the ip rule/route are as follows, >> >> >> >> ip rule add prio 222 table 222 >> >> ip route add default table 222 proto static \ >> >> nexthop via $GWE1 dev $IFE1 weight 1\ >> >> nexthop via $GWE2 dev $IFE2 weight 1 >> >> >> >> Now after traceroute failure, if i see the routing cache for that ip, TT> it shows following, >> >> JA> output route, probably created from -j MASQUERADE?: >> >> >> 205.158.62.141 via 203.88.135.213 dev eth1 src 203.88.135.212 >> >> cache mtu 1500 advmss 1460 >> >> JA> input route: >> >> >> 205.158.62.141 from 192.168.1.51 via 203.88.135.205 dev eth2 src TT> 192.168.1.242 >> >> cache mtu 1500 advmss 1460 iif eth0 >> >> >> >> please see eth1 and eth2 in both entries, >> >> JA> Nothing strange so far, may be they are created from different >> JA> connections. In fact, there should be more cache entries. >> >> >> now it does not forward this request, >> >> JA> Can you provide more information, in private mail if you >> JA> prefer so, including: >> >> JA> - tcpdump output(s) for all interfaces during the traceroute >> JA> - topology: are eth1 and eth2 connected to same hub? >> JA> - ip rules and routes >> >> JA> I hope you really have the "routes" patch applied and >> JA> running. >> >> >> what can be the reason behind this and please can anyone suggest me the TT> solution, >> >> thanx in advance, >> >> Regards, >> >> >> >> ---------------------------------------------------------------- >> >> Tushar Thakker >> >> Elitecore Technologies Ltd. >> >> JA> Regards >> >> JA> -- >> JA> Julian Anastasov >> >> JA> _______________________________________________ >> JA> LARTC mailing list / LARTC@mailman.ds9a.nl >> JA> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> >> try this, after applying routes patch it works fine (for me it works >> when I upgraded it to 3 uplinks): >> >> ---------------------------cut TT> here------------------------------------------ >> >> #!/bin/bash >> # This script is done by : Robert Kurjata Sep, 2003. >> # feel free to use it in any usefull way >> >> # CONFIGURATION >> IP=/sbin/ip >> PING=/bin/ping >> >> #--------------- LINK PART ----------------- >> # EXTIFn - interface name >> # EXTIPn - outgoing IP >> # EXTMn - netmask length (bits) >> # EXTGWn - outgoing gateway >> #------------------------------------------- >> >> # LINK 1 >> EXTIF1=eth2 >> EXTIP1= >> EXTM1= >> EXTGW1= >> >> # LINK 2 >> EXTIF2=eth1 >> EXTIP2= >> EXTM2= >> EXTGW2= >> >> #ROUTING PART >> # removing old rules and routes >> >> echo "removing old rules" >> ${IP} rule del prio 50 table main >> ${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201 >> ${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202 >> ${IP} rule del prio 221 table 221 >> echo "flushing tables" >> ${IP} route flush table 201 >> ${IP} route flush table 202 >> ${IP} route flush table 221 >> echo "removing tables" >> ${IP} route del table 201 >> ${IP} route del table 202 >> ${IP} route del table 221 >> >> # setting new rules >> echo "Setting new routing rules" >> >> # main table w/o default gateway here >> ${IP} rule add prio 50 table main >> ${IP} route del default table main >> >> # identified routes here >> ${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201 >> ${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202 >> >> ${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto TT> static table 201 >> ${IP} route append prohibit default table 201 metric 1 proto static >> >> ${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto TT> static table 202 >> ${IP} route append prohibit default table 202 metric 1 proto static >> >> # mutipath >> ${IP} rule add prio 221 table 221 >> >> ${IP} route add default table 221 proto static \ >> nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\ >> nexthop via ${EXTGW2} dev ${EXTIF2} weight 3 >> >> ${IP} route flush cache >> >> while : ; do >> ${PING} -c 1 ${EXTGW1} >> ${PING} -c 1 ${EXTGW2} >> sleep 60 >> done >> >> ---------------------------cut TT> here------------------------------------------ >> >> >> >> -- >> Pozdrowienia, >> Robert >> >> -- Pozdrowienia, Robert From stef.coene@docum.org Sat Jan 10 17:59:16 2004 From: stef.coene@docum.org (Stef Coene) Date: Sat, 10 Jan 2004 18:59:16 +0100 Subject: [LARTC] htb info needed In-Reply-To: <1073713953.3fff9321f34d3@webmail7.maa.sify.net> References: <1073713953.3fff9321f34d3@webmail7.maa.sify.net> Message-ID: <200401101859.16293.stef.coene@docum.org> On Saturday 10 January 2004 06:22, jayesh rathod wrote: > Hi, > > Want to know few things abt tc rules getting stored. > > 1.When a tc rule is added where does tc store it( in memory or in some flat > file or some DB). Memory. > 2.When the rules are added does it do any I/O operations. No. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Sat Jan 10 17:57:03 2004 From: stef.coene@docum.org (Stef Coene) Date: Sat, 10 Jan 2004 18:57:03 +0100 Subject: [LARTC] setting quantum values In-Reply-To: <1073714323.3fff9493e2c30@webmail7.maa.sify.net> References: <1073714323.3fff9493e2c30@webmail7.maa.sify.net> Message-ID: <200401101857.03732.stef.coene@docum.org> On Saturday 10 January 2004 06:28, jayesh rathod wrote: > Hi, > > when we add a class we get an error "HTB Quantum too small,or too big" > > i read in docum.org that we need to set the quantun value which should be > >1500 and <60000. > > but i need to add classes with diff type of rates. > > eg : Min : 32 kbit and Max : 512 kbit. > > now in this case how do i set my quantum value which satifies all types of > rates. If you can't find a good r2q parameter, choose a r2q so the smallest quantum is 3000 or so. And overrule the calculated quantum when you add the classes so quantum is 60000 for the highest rated classes. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From telles@devel-it.com.br Sat Jan 10 22:06:42 2004 From: telles@devel-it.com.br (Rodrigo P. Telles) Date: Sat, 10 Jan 2004 20:06:42 -0200 Subject: [LARTC] Some good news - Strange behavior deleting filters In-Reply-To: <3FFEFC28.9070301@pobox.com> References: <3FFD829F.304@pobox.com> <3FFDBE2B.4090700@trash.net> <3FFDA947.2070504@pobox.com> <3FFDCB00.6000908@trash.net> <3FFDE895.1040309@devel-it.com.br> <3FFE8651.8000506@devel-it.com.br> <3FFE9014.2060401@devel-it.com.br> <3FFEAEB2.6040505@pobox.com> <20040109104649.A10514@crescent.rt.cs.boeing.com> <3FFEFC28.9070301@pobox.com> Message-ID: <40007772.1060600@devel-it.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre, Very good, I tried that too and its work :-) Note: I'm using kernel 2.4.21. Telles Andre Correa wrote: | | Hi list, | | I've got a private e-mail from O. Brewer pointing something important | that we hadn't figured out yet: | | tc qdisc del dev eth1 root | tc qdisc add dev eth1 root handle 1:0 htb | tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1mbit | tc class add dev eth1 parent 1:0 classid 1:2 htb rate 1mbit | tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle ::10 u32 | match ip src 10.10.10.10 classid 1:1 | tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle ::11 u32 | match ip src 10.10.10.11 classid 1:2 | | | tc -r filter show dev eth1 parent 1: | filter protocol ip pref 1 u32 filter protocol ip pref 1 u32 fh | 800:[80000000] ht divisor 1 filter protocol ip pref 1 u32 fh | 800::10[80000010] order 16 key ht 800 bkt 0 flowid 1:1 match | 0a0a0a0a/ffffffff at 12 | filter protocol ip pref 1 u32 fh 800::11[80000011] order 17 key ht 800 | bkt 0 flowid 1:2 match 0a0a0a0b/ffffffff at 12 | | tc filter del dev eth1 parent 1: protocol ip prio 1 handle 800::11 u32 | | tc -r filter show dev eth1 parent 1: | filter protocol ip pref 1 u32 filter protocol ip pref 1 u32 fh | 800:[80000000] ht divisor 1 filter protocol ip pref 1 u32 fh | 800::10[80000010] order 16 key ht 800 bkt 0 flowid 1:1 match | 0a0a0a0a/ffffffff at 12 | | as we expect... | | So we figure out that using handle and u32 in the end of our command | line works fine. Good... There is still a lot of trouble to figure out | what is the value of handle XXX::yy when it is a script that manages | filters, but it is better then nothing... | | tks for pointing this out Orlie... | | Anybody else replicated the behavior? Does anybody know is tc | development is taking place? | | tks a lot... | | Andre | _______________________________________________ | LARTC mailing list / LARTC@mailman.ds9a.nl | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | - -- - ------------------------------------------------------ Rodrigo P. Telles Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - ------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAAHdyiLK8unYgEMQRAnpvAJ9jyj2AJJDwrPZLdJMnXiuIJ4qqyQCePOjC XLtX5GIX2SnByWadnTU1QwQ= =zlOC -----END PGP SIGNATURE----- From raptor@tvskat.net Sun Jan 11 18:23:36 2004 From: raptor@tvskat.net (raptor) Date: Sun, 11 Jan 2004 20:23:36 +0200 Subject: [LARTC] esearch problems ?! Message-ID: <20040111202336.05ae9936@bugsbunny.tvskat.net> any idea why i get this : # esearch cfg-update Traceback (most recent call last): File "/usr/bin/esearch", line 3, in ? from output import bold, red, green, darkgreen, turquoise, nocolor ImportError: No module named output # eupdatedb Traceback (most recent call last): File "/usr/sbin/eupdatedb", line 7, in ? from output import red, darkgreen, green, bold, nocolor ImportError: No module named output app-portage/esearch-0.5.2 tia From alan@whirlnet.co.uk Sun Jan 11 20:42:15 2004 From: alan@whirlnet.co.uk (Alan Ford) Date: Sun, 11 Jan 2004 20:42:15 +0000 Subject: [LARTC] Multicast Routing Message-ID: <20040111204215.GB12492@newred.gradwell.net> Hi, Anybody know anything about multicast routing? :) I see the HOWTO is rather lacking in this area... On my home network, I have multiple subnets attached to my router. I'd like multicast packets on either interface to be distributed on the other interface. (For context, this is to get Apple's Rendezvous protocol to work across multiple subnets). I thought this should be simple with multicast, but I can find zero documentation on it. The HOWTO cuts off just before the useful bit! Could anybody please shed any light? many thanks, -- Alan Ford * alan@whirlnet.co.uk From fredrik@dolda2000.com Sun Jan 11 21:08:06 2004 From: fredrik@dolda2000.com (Fredrik Tolf) Date: Sun, 11 Jan 2004 22:08:06 +0100 Subject: [LARTC] HTB rates aren't enforced correctly Message-ID: <16385.47926.561559.830659@pc7.dolda2000.com> Hi! I recently changed my qdisc from CBQ and PRIO to only HTB, and I can't really seem to get the rates to work as I want them to. I have eight classes, which I set up as follows: tc qdisc add dev eth1 root handle 1: htb default 122 tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit ceil 1000kbit cburst 1500 burst 50kb tc class add dev eth1 parent 1:1 classid 1:11 htb prio 0 rate 25kbit ceil 50kbit burst 10kbit tc class add dev eth1 parent 1:1 classid 1:12 htb prio 1 rate 400kbit ceil 1000kbit burst 10kb tc class add dev eth1 parent 1:1 classid 1:13 htb prio 1 rate 150kbit ceil 1000kbit burst 50kb tc class add dev eth1 parent 1:1 classid 1:14 htb prio 1 rate 400kbit ceil 1000kbit burst 10kb tc class add dev eth1 parent 1:1 classid 1:15 htb prio 2 rate 25kbit ceil 500kbit burst 10kb tc class add dev eth1 parent 1:12 classid 1:121 htb prio 1 rate 300kbit ceil 1000kbit tc class add dev eth1 parent 1:12 classid 1:122 htb prio 1 rate 100kbit ceil 1000kbit tc filter add dev eth1 parent 1: protocol ip prio 1 handle 1 fw flowid 1:15 tc filter add dev eth1 parent 1: protocol ip prio 2 handle 2 fw flowid 1:14 tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip tos 0x10 0x1e flowid 1:11 tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip tos 0x08 0x1e flowid 1:121 tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip sport 80 0xffff flowid 1:13 (Sorry for the long lines) Along with these iptables rules in the mangle table: -A POSTROUTING -m tos --tos 0x1e -j MARK --set-mark 0x1 -A POSTROUTING -m tos --tos 0x1e -j TOS --set-tos 0x00 -A POSTROUTING -m owner --cmd-owner vsftpd -j MARK --set-mark 0x2 As you can see, one of the things I'm trying to do is to de-prioritize traffic with TOS 0x1E (I set this through iptables on other machines on the network for processes that belong to a certain group) - these packets go to class 1:15. It doesn't work as I expect it to, though. In my test case, I let a friend download something from me over FTP, which goes through class 1:14, at the same time as I'm letting a multitude of TCP connections transfer data through the low priority class (1:15). This friend of mine has a downstream bandwidth of 512 kbit. My upstream bandwidth, in case it is unclear, is 1 mbit. Therefore, I would expect each to go at about 500 kbit each. When only one of the transfers is running alone, the correct bandwidth is reached. However, when both are running at the same time, the low priority goes at 500 kbit (its ceil), while the FTP transfer drops to only about 300 kbit. I have verified that everything goes through the right classes (with tc -s class ls), so the filters are working as they should, at least. If someone can explain this, I'd be grateful. Fredrik Tolf From fredrik@dolda2000.com Sun Jan 11 21:39:36 2004 From: fredrik@dolda2000.com (Fredrik Tolf) Date: Sun, 11 Jan 2004 22:39:36 +0100 Subject: [LARTC] HTB rates aren't enforced correctly In-Reply-To: <16385.47926.561559.830659@pc7.dolda2000.com> References: <16385.47926.561559.830659@pc7.dolda2000.com> Message-ID: <16385.49816.917662.815433@pc7.dolda2000.com> Please, disregard the message that I sent. I have since discovered that my bandwidth actually wasn't 1mbit (as my ISP had told me), but actually 800kbit. That was the cause of my problems. I'm terribly sorry for my ignorance, and hope for your forgiveness. Fredrik Tolf Fredrik Tolf writes: > Hi! > > I recently changed my qdisc from CBQ and PRIO to only HTB, and I can't > really seem to get the rates to work as I want them to. I have eight > classes, which I set up as follows: > > tc qdisc add dev eth1 root handle 1: htb default 122 > tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit ceil 1000kbit cburst 1500 burst 50kb > tc class add dev eth1 parent 1:1 classid 1:11 htb prio 0 rate 25kbit ceil 50kbit burst 10kbit > tc class add dev eth1 parent 1:1 classid 1:12 htb prio 1 rate 400kbit ceil 1000kbit burst 10kb > tc class add dev eth1 parent 1:1 classid 1:13 htb prio 1 rate 150kbit ceil 1000kbit burst 50kb > tc class add dev eth1 parent 1:1 classid 1:14 htb prio 1 rate 400kbit ceil 1000kbit burst 10kb > tc class add dev eth1 parent 1:1 classid 1:15 htb prio 2 rate 25kbit ceil 500kbit burst 10kb > tc class add dev eth1 parent 1:12 classid 1:121 htb prio 1 rate 300kbit ceil 1000kbit > tc class add dev eth1 parent 1:12 classid 1:122 htb prio 1 rate 100kbit ceil 1000kbit > tc filter add dev eth1 parent 1: protocol ip prio 1 handle 1 fw flowid 1:15 > tc filter add dev eth1 parent 1: protocol ip prio 2 handle 2 fw flowid 1:14 > tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip tos 0x10 0x1e flowid 1:11 > tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip tos 0x08 0x1e flowid 1:121 > tc filter add dev eth1 parent 1: protocol ip prio 3 u32 match ip sport 80 0xffff flowid 1:13 > > (Sorry for the long lines) > > Along with these iptables rules in the mangle table: > -A POSTROUTING -m tos --tos 0x1e -j MARK --set-mark 0x1 > -A POSTROUTING -m tos --tos 0x1e -j TOS --set-tos 0x00 > -A POSTROUTING -m owner --cmd-owner vsftpd -j MARK --set-mark 0x2 > > As you can see, one of the things I'm trying to do is to de-prioritize > traffic with TOS 0x1E (I set this through iptables on other machines > on the network for processes that belong to a certain group) - these > packets go to class 1:15. It doesn't work as I expect it to, > though. > > In my test case, I let a friend download something from me over FTP, > which goes through class 1:14, at the same time as I'm letting a > multitude of TCP connections transfer data through the low priority > class (1:15). This friend of mine has a downstream bandwidth of 512 > kbit. My upstream bandwidth, in case it is unclear, is 1 > mbit. Therefore, I would expect each to go at about 500 kbit > each. When only one of the transfers is running alone, the correct > bandwidth is reached. However, when both are running at the same time, > the low priority goes at 500 kbit (its ceil), while the FTP transfer > drops to only about 300 kbit. > > I have verified that everything goes through the right classes (with > tc -s class ls), so the filters are working as they should, at least. > > If someone can explain this, I'd be grateful. > > Fredrik Tolf > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From andybr@bol.com.br Sun Jan 11 21:51:08 2004 From: andybr@bol.com.br (andybr) Date: Sun, 11 Jan 2004 19:51:08 -0200 Subject: [LARTC] ap 450 Message-ID: Hi all, Do you know if the menu is java or javascript? Maybe something with mozilla. []=B4s Anderson > Good dat all > I have a Lucent AP450 > I'm havin trouble administratin it with the web interfa ce under > linux.Under windows all seem to be 100 but the menus is not showing > under linux.I dont think this is a ap proble maybe a mo zilla.I dont > know.Anyone have the same problem? > Thanks > Eddie > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From andybr@bol.com.br Sun Jan 11 21:39:55 2004 From: andybr@bol.com.br (andybr) Date: Sun, 11 Jan 2004 19:39:55 -0200 Subject: [LARTC] transparently passing url requests to local servers sharing ip? Message-ID: Hi all, Unless I understood wrongly you can do this by using iptables. Or if I understood wrongly please give example of url. []=B4s Anderson > hey, i'm hoping there's someone out there that can help me out... > i found http://lartc.org/howto/index.html through a fri end who was > trying to help with something i'm trying to accomplish. > > for various practical and educational reasons, i have a few servers set > up on my home network, all running apache on various op erating systems, > all accessible through port forwarding. i only have one ip which they > all share. for instance: > > http://24.30.102.177:1721/ is an osx server on the netw ork > (192.168.0.104) > http://24.30.102.177:1722/ is a slackware linux server on the network > (192.168.0.101) > http://24.30.102.177:1723/ is a windows nt server on th e network > (192.168.0.106) > > what i want to do is have something running on the linu x box (which the > router would dmz) that would take a url requested and l et a particular > server on the network serve a web site. i'd like it to be transparent > to the client, so they never see port numbers in their address bar, and > i'd like the web serving to be done by the box the file s rest on; not > strictly the linux box's apache. > > i don't need someone to hold my hand through the whole process which i > expect to be tricky, but i'd like to know if what i'm t rying to do is > even possible with linux routing- if i'm barking up the right tree so > to speak. also, i don't seem to have iproute installed and every site > which is supposed to have it seems to be down. do you k now where i can > get it? if i need it, that is. > > i've been searching for a clue for some time now, and a ny light on this > subject would be hugely appreciated! > skwerl > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From damion@snapgear.com Mon Jan 12 01:57:03 2004 From: damion@snapgear.com (Damion de Soto) Date: Mon, 12 Jan 2004 11:57:03 +1000 Subject: [LARTC] Router serving several inet ips References: <000a01c3d780$0fa4a520$1000a8c0@keithar> Message-ID: <4001FEEF.8060903@snapgear.com> Hi Carlos, > The iptables after '#' is what i tried.. but it did not work, it gave me > this message: > debian:/etc/init.d# sh nat.sh > Warning: weird character in interface `eth1:0' (No aliases, :, ! or *). > Warning: weird character in interface `eth1:0' (No aliases, :, ! or *). > iptables v1.2.7a: multiple -j flags not allowed > > #iptables -t nat -A POSTROUTING -o eth1:0 > #iptables -A FORWARD -i eth0 -j ACCEPT -m state --state > NEW,ESTABLISHED,RELATED > #iptables -A FORWARD -i eth1:0 -j ACCEPT -m state --state > ESTABLISHED,RELATED -j MASQUERADE You need to fix those 3 lines just like the error messages say. Iptables uses the real interface (eth1) not the aliased one. and you can't combine two -j flags ACCEPT and MASQUERADE. I assume the -j MASQUERADE option is a mistake and should belong elsewhere. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 jayesh_rathod@sify.com Mon Jan 12 05:40:01 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Mon, 12 Jan 2004 10:40:01 +0500 (IST) Subject: [LARTC] sum of child rates exceeds parent rate Message-ID: <1073884201.40022c299ffd2@webmail1.maa.sify.net> Hi, i have created a parent class with 45Meg rate/ceiling Note : The actual traffic flowing via that pc is around 6Meg to 15Meg I assume the problem will come only when the traffic is more than 45Meg. Now if i create child classes whose sum of rates crosses more than 45Meg ? 1.How that tc behaves. 2.Will this affect browsing. Pls let me know this details Regards Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From ams@wiw.org Mon Jan 12 08:06:56 2004 From: ams@wiw.org (Abhijit Menon-Sen) Date: Mon, 12 Jan 2004 13:36:56 +0530 Subject: [LARTC] throwing away unmarked traffic Message-ID: <20040112133656.D18450@lustre.dyn.wiw.org> A Linux gateway has two interfaces: eth0, with a routable address on an ISP's network, and eth1, which is 10.0.0.1 on a private network. There are several hosts connected to eth1, and these are allowed to send packets out of eth0 only after they login via a form at http://10.0.0.1. Once a host logs out, the gateway should no longer route packets for it. Each host also has a specific bandwidth allocation. I configured the gateway as follows (and it works fine): iptables -t nat -A POSTROUTING -s 10/8 -o eth0 -j SNAT --to ... ## Per-user rules, created upon login and deleted upon logout. # # One class per interface. N is some arbitrary number. tc class add dev eth1 parent 1: classid 1:N htb rate ... ceil ... tc class add dev eth0 parent 1: classid 1:N htb rate ... ceil ... # Mark traffic from host A.B.C.D with a unique mark 0xABCD. iptables -t mangle -I PREROUTING 1 -i eth1 -s A.B.C.D -j MARK --set-mark 0xABCD iptables -t mangle -I PREROUTING 2 -i eth1 -s A.B.C.D -j RETURN # Classify outgoing traffic by mark; incoming by private destination. tc filter add dev eth0 parent 1: protocol ip handle 0xABCD fw classid 1:N tc filter add dev eth1 parent 1: protocol ip u32 match ip dst A.B.C.D flowid 1:N My problem is with efficiently discarding all unmarked traffic. I am now doing this as follows: # This goes after all the per-user "good mark" rules: iptables -t mangle -A PREROUTING -j MARK --set-mark 0xfffffff # And this throws away "bad mark" packets. tc filter add dev eth0 parent 1: protocol ip handle 0xfffffff fw \ police mpu 0 mtu 1 action drop/drop This works fine, but I'd love to hear any suggestions about how to do it in a better way. (I tried a few other approaches, such as having a rule in filter/FORWARD that ACCEPTed only "-m mark \! --mark 0" packets, but that and similar solutions that are O(1) in the number of hosts did not work as I expected, due to the persistence of conntrack entries.) Questions, comments, and suggestions are welcome. -- ams From tatooin@kelkoo.com Mon Jan 12 11:14:07 2004 From: tatooin@kelkoo.com (Vincent Jaussaud) Date: Mon, 12 Jan 2004 12:14:07 +0100 Subject: [LARTC] High speed traffic filtering In-Reply-To: <3FFF34D8.8000507@trash.net> References: <1073672927.23676.102.camel@tatooin.kelkoo.net> <3FFF34D8.8000507@trash.net> Message-ID: <1073906046.23676.178.camel@tatooin.kelkoo.net> On Sat, 2004-01-10 at 00:10, Patrick McHardy wrote: > Vincent Jaussaud wrote: > > Hi; Hi, and thanks for you reply. > > > That might help, although without stateful filtering the rules > have to be evaluated for each single packet. Okay, we'll give it a try. > > > > 2) Replace iptables by nf-hipac for packet filtering. Have you guys any > > experience with nf-hipac ? (http://www.hipac.org/) > > nf-hipac is very good with a large number of rules, for just http > filtering I suspect iptables will do equally good or better. To be tested then, ok I'll try to see if we could build a test network and try to simulate such traffic. > > > > > I would be really thanksfull to hear of any solutions / workarounds / > > optimization to keep our linux firewalls handling growing traffic :-) > > Try without conntrack if you don't need it, otherwise start with > increasing the hash table size and limit ip_conntrack_max to 2 times > the hash size. There was a thread about optimizing iptables on > netfilter-devel 1-2 month ago, it was started by Hervé Eychenne, > search the archives. Thanks, I found the post. Indeed, there is a lot of helpful informations within. I'll investigate these post deeper. Thanks ! Regards, Vincent. > > Best regards, > Patrick > > > > > Thanks ! > > Vincent. > > > > --- > > > > Vincent Jaussaud > > Kelkoo.com Security Manager > > email: tatooin@kelkoo.com > > > > "Those who desire to give up freedom in order to gain security will not > > have, nor do they deserve, either one." > > -- President Thomas Jefferson. 1743-1826 > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Vincent Jaussaud Kelkoo.com Security Manager email: tatooin@kelkoo.com "Those who desire to give up freedom in order to gain security will not have, nor do they deserve, either one." -- President Thomas Jefferson. 1743-1826 From stef.coene@docum.org Mon Jan 12 17:31:13 2004 From: stef.coene@docum.org (Stef Coene) Date: Mon, 12 Jan 2004 18:31:13 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: <1073884201.40022c299ffd2@webmail1.maa.sify.net> References: <1073884201.40022c299ffd2@webmail1.maa.sify.net> Message-ID: <200401121831.13114.stef.coene@docum.org> On Monday 12 January 2004 06:40, jayesh rathod wrote: > Hi, > > i have created a parent class with 45Meg rate/ceiling > > Note : The actual traffic flowing via that pc is around 6Meg to 15Meg > I assume the problem will come only when the traffic is more than 45Meg. Indeed. > Now if i create child classes whose sum of rates crosses more than 45Meg ? > 1.How that tc behaves. It will try to give each class it's configured rate. An other problem is the bottleneck. YOU have to be the bottleneck and if you send more then your modem can handle, the modem will be the bottleneck and undo the traffic shaping. > 2.Will this affect browsing. It depends on the setup. But yes, it can. It's more likely it will affect real time traffic like icmp, VoIP, gaming, ... Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From jame_sj@yahoo.com Mon Jan 12 18:14:45 2004 From: jame_sj@yahoo.com (james jones) Date: Mon, 12 Jan 2004 10:14:45 -0800 (PST) Subject: [LARTC] (no subject) Message-ID: <20040112181445.30123.qmail@web60004.mail.yahoo.com> Woops you might like to ask this question to the Gentoo mailing list :-). Unfortunatly I haven't had these problems with esearch, so I am not of much help to ya. James |any idea why i get this : | |# esearch cfg-update |Traceback (most recent call last): | File "/usr/bin/esearch", line 3, in ? | from output import bold, red, green, darkgreen, turquoise, ||nocolor |ImportError: No module named output | | # eupdatedb |Traceback (most recent call last): | File "/usr/sbin/eupdatedb", line 7, in ? | from output import red, darkgreen, green, bold, nocolor |ImportError: No module named output | | | app-portage/esearch-0.5.2 |tia From totya@mail.ajkanet.hu Tue Jan 13 08:34:09 2004 From: totya@mail.ajkanet.hu (Toth Szabolcs) Date: Tue, 13 Jan 2004 09:34:09 +0100 (CET) Subject: [LARTC] problem with the new htb 3.14 patch (fwd) Message-ID: Hello ! I have patched with htb 3.14 and recompiled my 2.4.23 kernel but after that the tc didn't use the htb modul and said that for the command: yoda:~# tc -d qdisc qdisc pfifo_fast 0: dev eth0 [Unknown qdisc, optlen=20] qdisc pfifo_fast 0: dev eth1 [Unknown qdisc, optlen=20] My system runs on a dual 2.4 Intel Xeon system with Debian Woody rc1 and use SMP support. please if you need any further info or have idea for the promlem write me. thanx Szabolcs Toth From cbolton@hirstanddanson.co.uk Tue Jan 13 10:05:10 2004 From: cbolton@hirstanddanson.co.uk (Chris Bolton) Date: Tue, 13 Jan 2004 10:05:10 -0000 Subject: [LARTC] simple(?!?) source routing Message-ID: <003101c3d9bc$bb8795d0$0b00000a@Server2.hd> This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C3D9BC.BACA8760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've set up a Linux box with redhat on to act as an internet gateway and = I'm running into a few problems. Its got two adsl modems connected to = it, both connected to seperate 512kbs lines. Now I've followed the = simple source routing in the advanced routing howto to the letter but it = doesnt work. I've got it autoconnecting on startup and redhat puts ppp1 as the = default gateway, this is then setup for masquerading for the entire = network. Therefore I've tried setting up ppp0 as the deafult gateway = for only one computer (10.0.0.11), as it says at = http://lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE I've done = everything it says there and im 99% sure I've put the right ip addreses = in etc. When Ive gone through it that computer is no longer able to = access the net (the rest of the network is unaffected). I'm pretty sure its the way ppp0 is configured, if I set it up so = 10.0.0.11 uses ppp1 instead of ppp0 (ip rule add default via = xxx.xxx.xxx.xxx dev ppp1 table chris) it works fine but obviously thers = no point in that. Hope all this makes sence to someone, it baerly does ti me. May thanks = in advance. Chris ------=_NextPart_000_002E_01C3D9BC.BACA8760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I've set up a Linux box with = redhat on to act=20 as an internet gateway and I'm running into a few problems.  Its = got two=20 adsl modems connected to it, both connected to seperate 512kbs = lines.  Now=20 I've followed the simple source routing in the advanced routing howto to = the=20 letter but it doesnt work.
 
I've got it autoconnecting on startup = and redhat=20 puts ppp1 as the default gateway, this is then setup for masquerading = for the=20 entire network.  Therefore I've tried setting up ppp0 as the = deafult=20 gateway for only one computer (10.0.0.11), as it says at http://= lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE I've=20 done everything it says there and im 99% sure I've put the right ip = addreses in=20 etc.  When Ive gone through it that computer is no longer able to = access=20 the net (the rest of the network is unaffected).
 
I'm pretty sure its the way ppp0 is = configured, if=20 I set it up so 10.0.0.11 uses ppp1 instead of ppp0 (ip = rule add=20 default via xxx.xxx.xxx.xxx dev ppp1 table chris) it works fine but = obviously thers no point in that.
 
Hope all this makes sence to someone, = it baerly=20 does ti me.  May thanks in advance.
 
Chris
------=_NextPart_000_002E_01C3D9BC.BACA8760-- From arek@chelmnet.pl Tue Jan 13 10:13:16 2004 From: arek@chelmnet.pl (arek@chelmnet.pl) Date: Tue, 13 Jan 2004 11:13:16 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: <200401121831.13114.stef.coene@docum.org> Message-ID: > > Note : The actual traffic flowing via that pc is around 6Meg to 15Meg > > I assume the problem will come only when the traffic is more > than 45Meg. > Indeed. > > > Now if i create child classes whose sum of rates crosses more > than 45Meg ? > > 1.How that tc behaves. > It will try to give each class it's configured rate. An other > problem is the > bottleneck. YOU have to be the bottleneck and if you send more > then your > modem can handle, the modem will be the bottleneck and undo the traffic > shaping. Wow wow, wait ! you can have 100 child classess in a sum of 100Megs, root class equal 10Megs. the sum of all child classes will be 10Megs, and no more (if you ceil root rate to 10Megs it at htb) The behave of which child class get more /equal tokens than other you set by priority parameter. That is my theory with HTB+linux. With cbq many times total rate exceeds, so i use it no more (it was not accurate). But HTB is accurate. A.Binder From wouter.coppens@dedigate.com Tue Jan 13 16:15:25 2004 From: wouter.coppens@dedigate.com (Wouter Coppens) Date: Tue, 13 Jan 2004 17:15:25 +0100 Subject: [LARTC] Bridge + leased line + tc Message-ID: Hi, I can't get traffic shaping working. This is my situation: -------- ------ Net1 ----- |router| -------------------- | TC | ----------- Net2 -------- leased line ------ eth1 eth0 We use the leased line for normal traffic but also for synchronisation between 2 servers. The leased line is 2mbit. The synchronisation generates too much traffic and uses completely the 2mbit capacity of the leased line. This is no problem during night, but we want to limit the synchronisation traffic during day (or in other words: the sync-traffic should get the lowest priority and the other traffic can use up to 2mbit). According to the documentation, you can only shape outgoing traffic. We took a PC (named TC) and put the network interfaces in bridge mode. The synchronisation happens from Net1 to Net2, so TC is after the leased line. Normally you would shape the outgoing traffic on eth0, but this doesn't work. We even tried to limit eth0 to 20kbit, but the synch-traffic completely fills the leased line and no other traffic gets through. We found a temporary fix by using IMQ with iptables: /sbin/tc qdisc del root dev imq0 /sbin/tc qdisc add dev imq0 root handle 1: htb default 20 /sbin/tc class add dev imq0 parent 1: classid 1:1 htb rate 2Mbit burst 6k /sbin/tc class add dev imq0 parent 1:1 classid 1:10 htb rate 64kbit ceil 787kbit /sbin/tc class add dev imq0 parent 1:1 classid 1:20 htb rate 2Mbit /sbin/tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 /sbin/tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10 /sbin/tc filter add dev imq0 parent 1: protocol ip prio 18 u32 match ip dst 10.10.10.10 flowid 1:10 (10.10.10.10 is ip of server in Net2). Is there a better way to give the sync-traffic the lowest priority? If somybody starts a download it should get 2mbit and the sync-traffic should get the rest (if any). We would like to upgrade to 2.6, but imq is not maintained. Any help? Thanks in advance, Wouter =09 From 2084964@campus.uab.es Tue Jan 13 18:49:34 2004 From: 2084964@campus.uab.es (Felipe Herrera) Date: Tue, 13 Jan 2004 19:49:34 +0100 Subject: [LARTC] Bandwith Aggregation Message-ID: <0HRF00D4WZ6FBV@campus.uab.es> I am working on my Diploma Thesis on Computer Science Engineering. The main idea behind of my work is to make it possible to have a Linux box combining multiple ISP/network connections together providing a single connection with an aggregated bandwith. I have been surfing the Internet and I haven't found anything like that running on Linux. I would like to implement it using iproute 2 tools, but I don't really know it it is possible now. By the way, I have seen that in the LARTC jobs list there is one called "Multipath routing". Has anyone any idea of what is it about? Thank you in advance. From Robert Kurjata Tue Jan 13 19:36:31 2004 From: Robert Kurjata (Robert Kurjata) Date: Tue, 13 Jan 2004 20:36:31 +0100 Subject: [LARTC] Bandwith Aggregation In-Reply-To: <0HRF00D4WZ6FBV@campus.uab.es> References: <0HRF00D4WZ6FBV@campus.uab.es> Message-ID: <681354627.20040113203631@ire.pw.edu.pl> Witaj Felipe, W Twoim liœcie datowanym 13 stycznia 2004 (19:49:34) mo¿na przeczytaæ: FH> I am working on my Diploma Thesis on Computer Science Engineering. FH> The main idea behind of my work is to make it possible to have FH> a Linux box combining multiple ISP/network connections together FH> providing a single connection with an aggregated bandwith. FH> I have been surfing the Internet and I haven't found anything FH> like that running on Linux. I would like to implement it using FH> iproute 2 tools, but I don't really know it it is possible now. FH> By the way, I have seen that in the LARTC jobs list there is FH> one called "Multipath routing". FH> Has anyone any idea of what is it about? Yes, I suppose this is what you want - Equal Cost Multipath Routes. This issue is discussed here almost every few days :( so for the start just -READ THE ARCHIVES- and you will find everything you need. IMHO the idea is well known but sometimes makes some troubles (I have such a setup with 3 ISP and no BGP just plain bandwidth aggregation), and there were much more examples in last year :) on the list. For the start read my posting from 15th Oct 03 as an working example. FH> Thank you in advance. FH> _______________________________________________ FH> LARTC mailing list / LARTC@mailman.ds9a.nl FH> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Pozdrowienia, Robert From stef.coene@docum.org Tue Jan 13 21:24:39 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Jan 2004 22:24:39 +0100 Subject: [LARTC] Bridge + leased line + tc In-Reply-To: References: Message-ID: <200401132224.39848.stef.coene@docum.org> On Tuesday 13 January 2004 17:15, Wouter Coppens wrote: > Hi, > > I can't get traffic shaping working. > > This is my situation: > > > -------- ------ > Net1 ----- |router| -------------------- | TC | ----------- Net2 > -------- leased line ------ > > eth1 eth0 > > We use the leased line for normal traffic but also for synchronisation > between 2 servers. The leased line is 2mbit. The synchronisation > generates too much traffic and uses completely the 2mbit capacity of the > leased line. This is no problem during night, but we want to limit the > synchronisation traffic during day (or in other words: the sync-traffic > should get the lowest priority and the other traffic can use up to > 2mbit). > > According to the documentation, you can only shape outgoing traffic. We > took a PC (named TC) and put the network interfaces in bridge mode. > The synchronisation happens from Net1 to Net2, so TC is after the leased > line. > Normally you would shape the outgoing traffic on eth0, but this doesn't > work. We even tried to limit eth0 to 20kbit, but the synch-traffic > completely fills the leased line and no other traffic gets through. > > We found a temporary fix by using IMQ with iptables: > /sbin/tc qdisc del root dev imq0 > /sbin/tc qdisc add dev imq0 root handle 1: htb default 20 > /sbin/tc class add dev imq0 parent 1: classid 1:1 htb rate 2Mbit burst > 6k > /sbin/tc class add dev imq0 parent 1:1 classid 1:10 htb rate 64kbit ceil > 787kbit > /sbin/tc class add dev imq0 parent 1:1 classid 1:20 htb rate 2Mbit > /sbin/tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 > /sbin/tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10 > /sbin/tc filter add dev imq0 parent 1: protocol ip prio 18 u32 match ip > dst 10.10.10.10 flowid 1:10 (10.10.10.10 is ip of server in Net2). > > > Is there a better way to give the sync-traffic the lowest priority? If > somybody starts a download it should get 2mbit and the sync-traffic > should get the rest (if any). > > We would like to upgrade to 2.6, but imq is not maintained. Any help? Your idea of using eth0 for shaping should work. What if you add a simple tbf qdisc to eth0? This limits all traffic leaving eth0 and can be used to "test" tc. If the tbf works, you can try to replace it with htb or cbq to do more fancy shaping. I never used a bridge to shape the traffic, but I found this im own faq : http://docum.org/stef.coene/qos/faq/cache/41.html Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Tue Jan 13 21:20:08 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 13 Jan 2004 22:20:08 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: References: Message-ID: <200401132220.08618.stef.coene@docum.org> On Tuesday 13 January 2004 11:13, arek@chelmnet.pl wrote: > > It will try to give each class it's configured rate. An other > > problem is the > > bottleneck. YOU have to be the bottleneck and if you send more > > then your > > modem can handle, the modem will be the bottleneck and undo the traffic > > shaping. > > Wow wow, wait ! Ok :) > you can have 100 child classess in a sum of 100Megs, root class equal > 10Megs. > > the sum of all child classes will be 10Megs, and no more (if you ceil root > rate to 10Megs it at htb) Wrong. The configured rate of a class is _always_ satisfied. If you have a 100M link, a parent class ceiled to 10M and 100 classes with rate = 1M, each class will get 1M. So together they will get 100M. And even if that is more the the ceil of the parent. So you can overlimit a parent class. > The behave of which child class get more /equal tokens than other you set > by priority parameter. Yes and no. Each class will get his configured rate as a minimum. If the parent class has some bandwidth left, it will be given to the class with the lowest prio. At the same time, the class with the lowest prio will be able to send it's packets first and so will have a lower delay. BUT, if a low prio class uses more bandwidth then the configured rate, the latency goes up. > That is my theory with HTB+linux. With cbq many times total rate exceeds, > so i use it no more (it was not accurate). But HTB is accurate. Yes, but trust me, you need to follow some rules. You can find them on the faq page on docum.org. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From Vinh.Q.Nguyen@uts.edu.au Tue Jan 13 22:26:19 2004 From: Vinh.Q.Nguyen@uts.edu.au (Vinh Nguyen) Date: Wed, 14 Jan 2004 09:26:19 +1100 Subject: [LARTC] ingress policing Message-ID: Hi, I'm trying to police the incoming traffic by using ingress qdisc,this is what I have in my script tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 4 \ handle 1: u32 divisor 1 tc filter add dev eth0 parent ffff: protocol ip prio 4 u32 \ match ip dport 4001 0xffff \ police rate 2000kbit burst 50k drop \ flowid 1:1 I'm sending a 9Mb traffic using iperf but noticed that the bandwith at the receiving end is 4 MB instead of 2M. When Im changing the police rate to 3MB, the traffic at the receiving end is 6MB. Any ideas why does this happen? Your help is greatly appreciated. Vince UTS CRICOS Provider Code: 00099F DISCLAIMER ======================================================================== This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. ======================================================================== From arek@chelmnet.pl Tue Jan 13 22:58:08 2004 From: arek@chelmnet.pl (arek@chelmnet.pl) Date: Tue, 13 Jan 2004 23:58:08 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: <200401132220.08618.stef.coene@docum.org> Message-ID: > > Wow wow, wait ! > Ok :) > > you can have 100 child classess in a sum of 100Megs, root class equal > > 10Megs. > > the sum of all child classes will be 10Megs, and no more (if > you ceil root > > rate to 10Megs it at htb) > Wrong. The configured rate of a class is _always_ satisfied. > If you have a > 100M link, a parent class ceiled to 10M and 100 classes with > rate = 1M, each > class will get 1M. So together they will get 100M. And even if > that is more > the the ceil of the parent. > So you can overlimit a parent class. Well, i must practice that. I've always thougght that root/parent queue tell lower queues to start dropping packets. Sure, you must be right, the queues will be told to drop packets, but they will not do it unless they get their typed rate. So if any of my 100 queues have 1Mbit traffic, then lower queues will start to drop anything that is above 1Mbit for each queue individually. So we overlimit 10Mbit celi about 10 times (in special case). A.Binder From fin51@charter.net Wed Jan 14 05:37:53 2004 From: fin51@charter.net (PSC) Date: Wed, 14 Jan 2004 00:37:53 -0500 Subject: [LARTC] public subnet routing Message-ID: <1074058673.1174.11.camel@boxen.charter.net> Just wondering if someone could answer this question for me. I would like to route public addresses only. Their will be no firewall but maybe a few rules to deny certain types of traffic. Here is the configuration of the router. My provider gave a me a /30 link to their router also they gave me a /25 network for my customers public ip's Their cisco router has static route entrys for my public subnet The router has been configured as follows eth0 has been configured with : 205.95.67.102/30 eth1 is configured as 209.95.45.1/25 and is the gateway for my customers. Beside ip_forwarding being enabled is their anything that I need to do so my customers can access the ouside and the public to access their ip's. Thanks in advance for the help From cal_kaiwen@hotmail.com Wed Jan 14 08:07:18 2004 From: cal_kaiwen@hotmail.com (kaiwen) Date: Wed, 14 Jan 2004 16:07:18 +0800 Subject: [LARTC] Precedence of iptables chain, local routing table and newly created routing table Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0124_01C3DAB8.7BF72D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I been trying on ip rule fwmark and iptables MARK.=20 I will show my testing in detail, but my ultimate question is why ONLY = marking in Mangle OUTPUT tables works, but not others? Network Diagram ------------ 192.168.250.197 eth0 LINUX ROUTER eth1 192.168.8.88 = ------------------ 192.168.8.112 eth0 Windows XP Client Steps (performed on LINUX ROUTER) (1) Delete route to 192.168.8.0 from local routing table on (2) Add route to 192.168.8.0 at table test2 (3) Mark packet with --set-mark 3 at MANGLE OUTPUT table (4) Forward all packet marked 3 to table test2 using ip rule fwmark (5) Do a ip ro flush cache (6) Ping from 192.168.8.112 to 192.168.8.88 is successful [root@son-ag webauth]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use = Iface 192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0 = eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 = lo 0.0.0.0 192.168.250.254 0.0.0.0 UG 0 0 0 = eth0 [root@son-ag webauth]# ip route show table test2 192.168.8.0/24 via 192.168.8.88 dev br0 [root@son-ag webauth]# iptables -t mangle -L Chain OUTPUT (policy ACCEPT) target prot opt source destination MARK all -- anywhere anywhere MARK set 0x3 [root@son-ag webauth]# ip ru 0: from all lookup local 32764: from all fwmark 3 lookup test2 32766: from all lookup main 32767: from all lookup 253 I wish to know why is that ONLY marking at OUTPUT table works? The network setup is for testing purpose, I wish to know the precedence = of iptables chains, local routing table and newly created table (e.g. = test2) Looking at the iptables chain diagram, my guess is MARKING at mangle = INPUT or mangle PREROUTING should work as well.=20 When packet comes off from wire, I mark it with 3 at mangle PREROUTING. = Since it is a ping to 192.168.8.88, it should be a local process. Then the ping is successful. But from my testing, no.=20 Another possiblity is packet is route to test2 routing table after = mangle OUTPUT and before mandle POSTROUTING. I am getting confuse :) Please advice. Thank you Kaiwen ------=_NextPart_000_0124_01C3DAB8.7BF72D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I been trying on ip rule fwmark and = iptables MARK.=20
 
I will show my testing in detail, but = my ultimate=20 question is why ONLY marking in Mangle OUTPUT tables works, but not=20 others?
 
Network Diagram
 
------------ 192.168.250.197 eth0 LINUX = ROUTER eth1=20 192.168.8.88 ------------------ 192.168.8.112 eth0 Windows XP=20 Client
 
Steps (performed on LINUX = ROUTER)
(1) Delete route to 192.168.8.0 from = local routing=20 table on
(2) Add route to 192.168.8.0 at table=20 test2
(3) Mark packet with --set-mark 3 at = MANGLE OUTPUT=20 table
(4) Forward all packet marked 3 to = table test2=20 using ip rule fwmark
(5) Do a ip ro flush cache
(6) Ping from 192.168.8.112 to = 192.168.8.88 is=20 successful
 
 
[root@son-ag webauth]# route = -n
Kernel IP=20 routing table
Destination    =20 Gateway        =20 Genmask         Flags Metric=20 Ref    Use Iface
192.168.250.0  =20 0.0.0.0        =20 255.255.255.0   U    =20 0      = 0        0=20 eth0
127.0.0.0      =20 0.0.0.0        =20 255.0.0.0       U    =20 0      = 0        0=20 lo
0.0.0.0         = 192.168.250.254=20 0.0.0.0         = UG   =20 0      = 0        0=20 eth0
 
[root@son-ag webauth]# ip route show = table=20 test2
192.168.8.0/24 via 192.168.8.88 dev br0
 
[root@son-ag webauth]# iptables -t = mangle=20 -L
Chain OUTPUT (policy=20 ACCEPT)
target     prot opt=20 source           &= nbsp;  =20 destination
MARK       all  = -- =20 anywhere           = ; =20 anywhere           = MARK set=20 0x3
 
[root@son-ag webauth]# ip=20 ru
0:      from all lookup = local
32764: =20 from all fwmark        3 lookup=20 test2
32766:  from all lookup main
32767:  from all = lookup=20 253
 
I wish to know why is that ONLY marking = at OUTPUT=20 table works?
The network setup is for testing = purpose, I wish to=20 know the precedence of iptables chains, local routing table and = newly=20 created table (e.g. test2)
 
Looking at the iptables chain diagram, = my guess is=20 MARKING at mangle INPUT or mangle PREROUTING should work as well. =
When packet comes off from wire, I mark = it with 3=20 at mangle PREROUTING. Since it is a ping to 192.168.8.88, it should be a = local=20 process.
Then the ping is successful. But from = my testing,=20 no.
 
Another possiblity is packet is route = to test2=20 routing table after mangle OUTPUT and before mandle POSTROUTING. I am = getting=20 confuse :)
 
Please advice. Thank you
 
Kaiwen
------=_NextPart_000_0124_01C3DAB8.7BF72D20-- From eddieknows@ananzi.co.za Wed Jan 14 09:22:14 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Wed, 14 Jan 2004 11:22:14 +0200 Subject: [LARTC] htb+redhat7.3 Message-ID: <1074072134.2557.8.camel@testbox.co.za> HI all Just doing so recon before doing a installation Will htb work on redhat 7.3,default kernel,i think 2.4.18? Thanks From mind@bi.lt Wed Jan 14 09:14:10 2004 From: mind@bi.lt (Mindaugas Riauba) Date: Wed, 14 Jan 2004 11:14:10 +0200 Subject: [LARTC] Problems while mixing protocols Message-ID: <008f01c3da7e$c84a41b0$f20214ac@bite.lt> Hello, I'm trying to shape traffic by IP addresses and by 802.1q vlans. But when I add 802.1q filter filters output looks strange. Maybe I'm missing some options to TC? Thanks, Mindaugas # ./bin/tc -s -d filter show dev eth0 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 d5e2b800/fffffe00 at 12 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:11 match d5e28af0/fffffff8 at 12 filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:11 match d5e28af8/fffffffc at 12 filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:200 match d5e2a020/fffffffc at 12 filter parent 1: protocol ip pref 1 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:300 match d5e2a024/fffffffc at 12 # ./bin/tc filter add dev eth0 parent 1: protocol 802.1Q u32 match u16 5 0x0fff flowid 1:500 # ./bin/tc -s -d filter show dev eth0 filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:500 match 00050000/0fff0000 at 0 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 d5e2b800/fffffe00 at 12 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:11 match d5e28af0/fffffff8 at 12 filter parent 1: protocol ip pref 1 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:11 match d5e28af8/fffffffc at 12 filter parent 1: protocol ip pref 1 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:200 match d5e2a020/fffffffc at 12 filter parent 1: protocol ip pref 1 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:300 match d5e2a024/fffffffc at 12 filter parent 1: protocol 802.1Q pref 49152 u32 filter parent 1: protocol 802.1Q pref 49152 u32 fh 801: ht divisor 1 filter parent 1: protocol 802.1Q pref 49152 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:500 match 00050000/0fff0000 at 0 filter parent 1: protocol 802.1Q pref 49152 u32 fh 800: ht divisor 1 filter parent 1: protocol 802.1Q pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 match d5e2b800/fffffe00 at 12 filter parent 1: protocol 802.1Q pref 49152 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:11 match d5e28af0/fffffff8 at 12 filter parent 1: protocol 802.1Q pref 49152 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:11 match d5e28af8/fffffffc at 12 filter parent 1: protocol 802.1Q pref 49152 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:200 match d5e2a020/fffffffc at 12 filter parent 1: protocol 802.1Q pref 49152 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:300 match d5e2a024/fffffffc at 12 From rabs@dimension-virtual.com Wed Jan 14 09:35:01 2004 From: rabs@dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancort_Santana?=) Date: Wed, 14 Jan 2004 09:35:01 +0000 Subject: [LARTC] Bandwith Aggregation In-Reply-To: <681354627.20040113203631@ire.pw.edu.pl> References: <0HRF00D4WZ6FBV@campus.uab.es> <681354627.20040113203631@ire.pw.edu.pl> Message-ID: <200401140935.01080.rabs@dimension-virtual.com> El Martes, 13 de Enero de 2004 19:36, Robert Kurjata escribi=F3: > For the start read my posting from 15th Oct 03 as an working example. I have just a question about your script (I found it on the archives)... I have 3 DSL lines, linke you, but all of them are conected to a switch and= =20 then to my eth1 interface on wich I have 3 public ip's and 2 public ip's=20 ranges, let me try to draw it. DMZ Zone | eth3 DSL1\ | DSL2 - - Switch - eth1 [Linux Box] - eth0 -Switch - LAN DSL3 / | eth2 | LDMS What I need is to send all SMTP/POP3 traffic throught DSL1, and the rest of= =20 traffict througth a load balancing between DSL2 and DSL3 giving preference= =20 on DSL3 over DSL2 (moreover because DSL3 it's a 2Mbits simetric line with t= he=20 local cable company, and DSL2 it's a ADSL 256Kbit), but if DSL1 fails, the= =20 SMTP/POP3 traffic should go out by any of the other interfaces, also if DSL= 2=20 or DLS3 get out, rest of traffic should go by DSL1. =20 The LDMS link its used only for IPSec tunnels and should never be user for= =20 nomal traffic. DSL1 -> ADSL 256 with a /30 public range on the ethernet side. DSL2 -> ADSL 256 in bridge mode, so I have it's public IP on my side. DSL3 -> Cable 2Mbit with a /30 public range on the ethernet side. By now I only have setup a simple link with it's gateway using DSL1 for all= =20 traffic, and I'm been unable to do that if a ssh conection (for example)=20 reach eth1 by DSL3 or reach eth2 by LDMS and get answered by the same link. May someone give me a hit on what I'm doing wrong or what must I do to get = it=20 working. Best regards From rabs@dimension-virtual.com Wed Jan 14 09:47:44 2004 From: rabs@dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancort_Santana?=) Date: Wed, 14 Jan 2004 09:47:44 +0000 Subject: [LARTC] Bandwith Aggregation In-Reply-To: <200401140935.01080.rabs@dimension-virtual.com> References: <0HRF00D4WZ6FBV@campus.uab.es> <681354627.20040113203631@ire.pw.edu.pl> <200401140935.01080.rabs@dimension-virtual.com> Message-ID: <200401140947.44620.rabs@dimension-virtual.com> I forgot to mention that I'm running Debian Sid, with kernel 2.6.1 patched with NANO patchs and iproute2 with HTB support (but by now I'm not interested on clasiffiying traffic, that will be later) From andy.furniss@dsl.pipex.com Wed Jan 14 09:21:41 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Wed, 14 Jan 2004 09:21:41 +0000 Subject: [LARTC] Bridge + leased line + tc In-Reply-To: References: Message-ID: <04011409214100.00678@amd> On Tuesday 13 January 2004 4:15 pm, Wouter Coppens wrote: > Hi, > > I can't get traffic shaping working. > > This is my situation: > > > -------- ------ > Net1 ----- |router| -------------------- | TC | ----------- Net2 > -------- leased line ------ > > eth1 eth0 > > We use the leased line for normal traffic but also for synchronisation > between 2 servers. The leased line is 2mbit. The synchronisation > generates too much traffic and uses completely the 2mbit capacity of the > leased line. This is no problem during night, but we want to limit the > synchronisation traffic during day (or in other words: the sync-traffic > should get the lowest priority and the other traffic can use up to > 2mbit). > > According to the documentation, you can only shape outgoing traffic. We > took a PC (named TC) and put the network interfaces in bridge mode. > The synchronisation happens from Net1 to Net2, so TC is after the leased > line. > Normally you would shape the outgoing traffic on eth0, but this doesn't > work. We even tried to limit eth0 to 20kbit, but the synch-traffic > completely fills the leased line and no other traffic gets through. > > We found a temporary fix by using IMQ with iptables: > /sbin/tc qdisc del root dev imq0 > /sbin/tc qdisc add dev imq0 root handle 1: htb default 20 > /sbin/tc class add dev imq0 parent 1: classid 1:1 htb rate 2Mbit burst > 6k > /sbin/tc class add dev imq0 parent 1:1 classid 1:10 htb rate 64kbit ceil > 787kbit > /sbin/tc class add dev imq0 parent 1:1 classid 1:20 htb rate 2Mbit > /sbin/tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 10 > /sbin/tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10 > /sbin/tc filter add dev imq0 parent 1: protocol ip prio 18 u32 match ip > dst 10.10.10.10 flowid 1:10 (10.10.10.10 is ip of server in Net2). > > > Is there a better way to give the sync-traffic the lowest priority? If > somybody starts a download it should get 2mbit and the sync-traffichttp > should get the rest (if any). > > We would like to upgrade to 2.6, but imq is not maintained. Any help? IMQ has been ported to 2.6 http://www.digriz.org.uk/jdg-qos-script/ Andy. From Robert Kurjata Wed Jan 14 10:46:31 2004 From: Robert Kurjata (Robert Kurjata) Date: Wed, 14 Jan 2004 11:46:31 +0100 Subject: [LARTC] public subnet routing In-Reply-To: <1074058673.1174.11.camel@boxen.charter.net> References: <1074058673.1174.11.camel@boxen.charter.net> Message-ID: <1381903767.20040114114631@ire.pw.edu.pl> Witaj PSC, W Twoim liœcie datowanym 14 stycznia 2004 (06:37:53) mo¿na przeczytaæ: P> Just wondering if someone could answer this question for me. P> I would like to route public addresses only. Their will be no firewall P> but maybe a few rules to deny certain types of traffic. Here is the P> configuration of the router. P> My provider gave a me a /30 link to their router P> also they gave me a /25 network for my customers public ip's P> Their cisco router has static route entrys for my public subnet P> The router has been configured as follows P> eth0 has been configured with : P> 205.95.67.102/30 P> eth1 is configured as P> 209.95.45.1/25 and is the gateway for my customers. just set properly your router default route :) (guessing the gateway ip :) ip ro add default via 205.95.67.103 dev eth0 and should work :) (works for me :) P> Beside ip_forwarding being enabled is their anything that I need to do P> so my customers can access the ouside and the public to access their P> ip's. P> Thanks in advance for the help P> _______________________________________________ P> LARTC mailing list / LARTC@mailman.ds9a.nl P> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Pozdrowienia, Robert mailto:rkurjata@ire.pw.edu.pl From cord@keppler.vrg.de Wed Jan 14 11:47:22 2004 From: cord@keppler.vrg.de (Cord Buhlert) Date: Wed, 14 Jan 2004 12:47:22 +0100 Subject: [LARTC] imq-patch for 2.4.24 kernel Message-ID: <20040114114722.GA15636@keppler.vrg.de> Hi, is there an IMQ-patch available for kernel version 2.4.24? If so, where can I get it? greetz cord From cord@keppler.vrg.de Wed Jan 14 14:17:31 2004 From: cord@keppler.vrg.de (Cord Buhlert) Date: Wed, 14 Jan 2004 15:17:31 +0100 Subject: [LARTC] question about major:minor numbers Message-ID: <20040114141731.GA15980@keppler.vrg.de> Hi, the documentation says "[the major number of a class] must be unique within a egress or ingress setup. The minor number must be unique within a qdisc and his classes." What is meant by "setup"? Does that include all qdiscs attached to any network device? Ie, if I have a qdisc attached to eth0 and another attached to eth1, do the major numbers I use have to be different at all or could I use the same number structure in eth0 and eth1? Short example to explain: tc qdisc add dev eth0 root handle 1: htb default 13 tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps... tc class add dev eth0 parent 1:1 classid 1:10 htb rate... ... tc qdisc add dev eth1 root handle 1: htb default 13 tc class add dev eth1 parent 1: classid 1:1 htb rate 100kbps... tc class add dev eth1 parent 1:1 classid 1:10 htb rate... ... Is this valid? Or do I have to use "2:" instead of "1:" in the second part? thanx cb From andre.correa@pobox.com Wed Jan 14 12:30:09 2004 From: andre.correa@pobox.com (Andre Correa) Date: Wed, 14 Jan 2004 10:30:09 -0200 Subject: [LARTC] question about major:minor numbers In-Reply-To: <20040114141731.GA15980@keppler.vrg.de> References: <20040114141731.GA15980@keppler.vrg.de> Message-ID: <40053651.9040100@pobox.com> Cord, you can use the same major numbers in diferent devices, no problem. You cannot have repeated minor numbers in the same device, but in diferent devices it is OK. Note that sometimes using diferent major numbers may be a good idea, for example, when you are scripting this may help... Andre Cord Buhlert wrote: > Hi, > the documentation says "[the major number of a class] must be unique > within a egress or ingress setup. The minor number must be unique within > a qdisc and his classes." > > What is meant by "setup"? Does that include all qdiscs attached to any > network device? Ie, if I have a qdisc attached to eth0 and another > attached to eth1, do the major numbers I use have to be different at all > or could I use the same number structure in eth0 and eth1? > > Short example to explain: > tc qdisc add dev eth0 root handle 1: htb default 13 > tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps... > tc class add dev eth0 parent 1:1 classid 1:10 htb rate... > ... > > tc qdisc add dev eth1 root handle 1: htb default 13 > tc class add dev eth1 parent 1: classid 1:1 htb rate 100kbps... > tc class add dev eth1 parent 1:1 classid 1:10 htb rate... > ... > > Is this valid? Or do I have to use "2:" instead of "1:" in the second > part? > > thanx > cb > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From andre.correa@pobox.com Wed Jan 14 11:48:36 2004 From: andre.correa@pobox.com (Andre Correa) Date: Wed, 14 Jan 2004 09:48:36 -0200 Subject: [LARTC] ingress policing In-Reply-To: References: Message-ID: <40052C94.3060106@pobox.com> Hi Vinh, I've noticed the same thing some months ago and couldn't figure out why. The workarround for this is to use half speed in your "upload" classes... It seens that it just happens to outgoing traffic (ingress or not). Maybe somone else can explian it... I just figured out the same problem... Andre Vinh Nguyen wrote: > Hi, > > I'm trying to police the incoming traffic by using ingress qdisc,this is what I have in my script > > tc qdisc add dev eth0 handle ffff: ingress > > tc filter add dev eth0 parent ffff: protocol ip prio 4 \ > handle 1: u32 divisor 1 > > tc filter add dev eth0 parent ffff: protocol ip prio 4 u32 \ > match ip dport 4001 0xffff \ > police rate 2000kbit burst 50k drop \ > flowid 1:1 > > I'm sending a 9Mb traffic using iperf but noticed that the bandwith at the receiving end is 4 MB instead of 2M. When Im changing the police rate to 3MB, the traffic at the receiving end is 6MB. Any ideas why does this happen? Your help is greatly appreciated. > > Vince > > > > UTS CRICOS Provider Code: 00099F > > DISCLAIMER > ======================================================================== > This email message and any accompanying attachments may contain > confidential information. If you are not the intended recipient, do not > read, use, disseminate, distribute or copy this message or attachments. > If you have received this message in error, please notify the sender > immediately and delete this message. Any views expressed in this message > are those of the individual sender, except where the sender expressly, > and with authority, states them to be the views the University of > Technology Sydney. Before opening any attachments, please check them for > viruses and defects. > ======================================================================== > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From ionut@topall.ro Fri Jan 9 23:14:59 2004 From: ionut@topall.ro (ionut@topall.ro) Date: Fri, 9 Jan 2004 18:14:59 -0500 (EST) Subject: [LARTC] brige conf In-Reply-To: <20040108225602.26395.4607.Mailman@outpost.ds9a.nl> References: <20040108225602.26395.4607.Mailman@outpost.ds9a.nl> Message-ID: <4477.80.97.103.2.1073690099.squirrel@mail.topall.ro> Hi i'm using a bridge for traffic control and now i have 300 user the problem is there is a large script for tc for incomming and outgoing traffic about 1300 lines. Evrithing is fine but it seams i lost 2ms on bridge . I ping from my machine (linux gateway) to the my internet gateway an ATI router, my conncetion is at 100Mbit from my machine to the ATI. Wen i'm not using bridge evrything is fine i have 0.400ms. I read something about HZ=100 but i don't understanding wath i need to do ! Any sugestio is wellcome! Thx Guy's From ricardo_soria@yahoo.com Wed Jan 14 17:50:33 2004 From: ricardo_soria@yahoo.com (=?iso-8859-1?q?Ricardo=20Soria?=) Date: Wed, 14 Jan 2004 11:50:33 -0600 (CST) Subject: [LARTC] htb+redhat7.3 Message-ID: <20040114175033.97148.qmail@web41501.mail.yahoo.com> Hi there: The original kernel included in RedHat 7.3 does *not* include htb support. You have to patch that kernel if you want to use htb. Visit http://luxik.cdi.cz/~devik/qos/htb/ for further instrucctions. Good luck. Ricardo Soria. _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com From mwitkowski@e-ar.pl Wed Jan 14 19:42:22 2004 From: mwitkowski@e-ar.pl (=?ISO-8859-2?Q?Micha=B3_Witkowski?=) Date: Wed, 14 Jan 2004 20:42:22 +0100 Subject: [LARTC] wich tools Message-ID: <40059B9E.80602@e-ar.pl> Hello I have two DSL modems witch are connected to my isp, in future my boss want to buy another connection via DSL modem. Then i will have 3 DSL modems. With every DSL modem i get 3x8 IP`s (netmask 248) from my ISP, now i have question how to configure gateway wich tools should i use. Because ip route and next hop via. wich i use now makes his work fine but with new kernels there is an error in syslog "route sent us somewhere else", and i think that with 3 DSL`s i will have problem (there can be situation when 1DSL is busy and 2DSL aren`t). Greetings Michal Witkowski From mstavrev@it-academy.bg Wed Jan 14 21:07:54 2004 From: mstavrev@it-academy.bg (Marin Stavrev) Date: Wed, 14 Jan 2004 23:07:54 +0200 (EET) Subject: [LARTC] Any NISTNet alternative or fix ? Message-ID: <3195.212.104.98.70.1074114474.squirrel@oldmail.it-academy.bg> Hi, I need to simulate (with a certain degree of control) common WAN problems like packet loss/duplication, delay and conditions of limited bandwidth. I found that NISTNet is what i need, but it seems the package has not been updated since October, 2000. This is not really a problem as I found NISTNet runs perfectly with Linux kernels up to 2.4.23 (officially 2.4.18 is the latest mentioned in documentation). What then am I complaining about ? Well, it seems that NISTNet is intercepting IP packets before the conntrack can do its job in the PREROUTING phase. So if you are doing SNAT or DNAT on the same machine where NISTNet is running, you can not use the de-NATed IP addresses to build rules. I certainly can find solution to this problem by altering my test topology and tweaking a little bit network configuration, but still the question remains: Is there any fresh substitute for what NISTNet does ? From Robert Kurjata Wed Jan 14 20:46:15 2004 From: Robert Kurjata (Robert Kurjata) Date: Wed, 14 Jan 2004 21:46:15 +0100 Subject: Re[2]: [LARTC] Bandwith Aggregation In-Reply-To: <200401140935.01080.rabs@dimension-virtual.com> References: <0HRF00D4WZ6FBV@campus.uab.es> <681354627.20040113203631@ire.pw.edu.pl> <200401140935.01080.rabs@dimension-virtual.com> Message-ID: <1317673654.20040114214615@ire.pw.edu.pl> Witaj Raúl, W Twoim liœcie datowanym 14 stycznia 2004 (10:35:01) mo¿na przeczytaæ: RABS> El Martes, 13 de Enero de 2004 19:36, Robert Kurjata escribió: >> For the start read my posting from 15th Oct 03 as an working example. RABS> I have just a question about your script (I found it on the archives)... RABS> I have 3 DSL lines, linke you, but all of them are conected to a switch and RABS> then to my eth1 interface on wich I have 3 public ip's and 2 public ip's RABS> ranges, let me try to draw it. RABS> DMZ Zone RABS> | RABS> eth3 RABS> DSL1\ | RABS> DSL2 - - Switch - eth1 [Linux Box] - eth0 -Switch - LAN RABS> DSL3 / | RABS> eth2 RABS> | RABS> LDMS RABS> What I need is to send all SMTP/POP3 traffic throught DSL1, and the rest of RABS> traffict througth a load balancing between DSL2 and DSL3 giving preference RABS> on DSL3 over DSL2 (moreover because DSL3 it's a 2Mbits simetric line with the RABS> local cable company, and DSL2 it's a ADSL 256Kbit), but if DSL1 fails, the RABS> SMTP/POP3 traffic should go out by any of the other interfaces, also if DSL2 RABS> or DLS3 get out, rest of traffic should go by DSL1. RABS> The LDMS link its used only for IPSec tunnels and should never be user for RABS> nomal traffic. DSL1 ->> ADSL 256 with a /30 public range on the ethernet side. DSL2 ->> ADSL 256 in bridge mode, so I have it's public IP on my side. DSL3 ->> Cable 2Mbit with a /30 public range on the ethernet side. RABS> By now I only have setup a simple link with it's gateway using DSL1 for all RABS> traffic, and I'm been unable to do that if a ssh conection (for example) RABS> reach eth1 by DSL3 or reach eth2 by LDMS and get answered by the same link. Multipath with load balancing is in my script. If you use it (just try to adopt to 3 links) your host will be reachable at all adresses. Adding special rules with firewall mark and dedicated routing tables for classified traffic will give you what you want. But later you will have a problem when you go to the traffic shaping (and I thing sooner or later you will) TC does not accept aliases on interfaces :( RABS> May someone give me a hit on what I'm doing wrong or what must I do to get it RABS> working. RABS> Best regards RABS> _______________________________________________ RABS> LARTC mailing list / LARTC@mailman.ds9a.nl RABS> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Pozdrowienia, Robert From Robert Kurjata Wed Jan 14 20:30:48 2004 From: Robert Kurjata (Robert Kurjata) Date: Wed, 14 Jan 2004 21:30:48 +0100 Subject: [LARTC] wich tools In-Reply-To: <40059B9E.80602@e-ar.pl> References: <40059B9E.80602@e-ar.pl> Message-ID: <1148909502.20040114213048@ire.pw.edu.pl> Witaj Micha³, W Twoim liœcie datowanym 14 stycznia 2004 (20:42:22) mo¿na przeczytaæ: MW> Hello MW> I have two DSL modems witch are connected to my isp, in future my boss MW> want to buy another connection via DSL modem. Then i will have 3 DSL MW> modems. With every DSL modem i get 3x8 IP`s (netmask 248) from my ISP, MW> now i have question how to configure gateway wich tools should i use. MW> Because ip route and next hop via. wich i use now makes his work fine MW> but with new kernels there is an error in syslog "route sent us MW> somewhere else", and i think that with 3 DSL`s i will have problem MW> (there can be situation when 1DSL is busy and 2DSL aren`t). MW> Greetings MW> Michal Witkowski I have 3 uplinks, kernel 2.4.22+patch-o-matic+htb+esfq+julian's routes patch working load balancing and have no problems :) Classic configuration. Maybe something with missing patches? MW> _______________________________________________ MW> LARTC mailing list / LARTC@mailman.ds9a.nl MW> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Pozdrowienia, Robert From stef.coene@docum.org Wed Jan 14 22:00:42 2004 From: stef.coene@docum.org (Stef Coene) Date: Wed, 14 Jan 2004 23:00:42 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: References: Message-ID: <200401142300.42294.stef.coene@docum.org> On Tuesday 13 January 2004 23:58, arek@chelmnet.pl wrote: > > > Wow wow, wait ! > > > > Ok :) > > > > > you can have 100 child classess in a sum of 100Megs, root class equal > > > 10Megs. > > > the sum of all child classes will be 10Megs, and no more (if > > > > you ceil root > > > > > rate to 10Megs it at htb) > > > > Wrong. The configured rate of a class is _always_ satisfied. > > If you have a > > 100M link, a parent class ceiled to 10M and 100 classes with > > rate = 1M, each > > class will get 1M. So together they will get 100M. And even if > > that is more > > the the ceil of the parent. > > So you can overlimit a parent class. > > Well, i must practice that. > I've always thougght that root/parent queue tell lower queues to start > dropping packets. It's the other way around. The class needs a token to send a packet. As long as the class has tokens, it can send packets. If the class has used all his tokens, it asks the parent if he has tokens left. > Sure, you must be right, the queues will be told to drop packets, but they > will not do it unless they get their typed rate. Think about a bucket with tokens, not rate: bucket size = burst rate of new token entering bucket = rate 1 token = 1 packet (this is for rate and ceil) > So if any of my 100 queues have 1Mbit traffic, then lower queues will start > to drop anything that is above 1Mbit for each queue individually. Yes. > So we overlimit 10Mbit celi about 10 times (in special case). Yes. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From andybr@bol.com.br Thu Jan 15 01:11:05 2004 From: andybr@bol.com.br (andybr) Date: Wed, 14 Jan 2004 23:11:05 -0200 Subject: [LARTC] simple(?!?) source routing Message-ID: Hi all, This is easy. First let ppp0 as your default gateway and use iproute to create a table call any name you want and then you put ppp1 default route inside that table. After that you have to create a rule to put the host you would like insede it and dont forget to put a rule in the iptables saying that everything going out via ppp1 SNAT - -to IP_PPP1_EXTERNAL. ;) []=B4s Anderson > Hi, > > I've set up a Linux box with redhat on to act as an int ernet gateway and I'm running into a few problems. Its g ot two adsl modems connected to it, both connected to sep erate 512kbs lines. Now I've followed the simple source routing in the advanced routing howto to the letter but i t doesnt work. > > I've got it autoconnecting on startup and redhat puts p pp1 as the default gateway, this is then setup for masque rading for the entire network. Therefore I've tried sett ing up ppp0 as the deafult gateway for only one computer (10.0.0.11), as it says at http://lartc.org/howto/lartc.r pdb.html#LARTC.RPDB.SIMPLE I've done everything it says t here and im 99% sure I've put the right ip addreses in et c. When Ive gone through it that computer is no longer a ble to access the net (the rest of the network is unaffec ted). > > I'm pretty sure its the way ppp0 is configured, if I se t it up so 10.0.0.11 uses ppp1 instead of ppp0 (ip rule a dd default via xxx.xxx.xxx.xxx dev ppp1 table chris) it w orks fine but obviously thers no point in that. > > Hope all this makes sence to someone, it baerly does ti me. May thanks in advance. > > Chris __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From virgil@vipnet.ro Thu Jan 15 07:21:42 2004 From: virgil@vipnet.ro (Cristea Virgil Ionut) Date: Thu, 15 Jan 2004 09:21:42 +0200 Subject: [LARTC] HTB Message-ID: Hi, I have the following questions: I only have one htb computer (2 nics) to shape the international traffic as well as the metropolitan traffic (i have a list of metropolitan ip's to use). Can this be achived using iptables with packet marking (on that htb computer the 2 nics are bridged)? If it can will there be delays introduced by the shaping operation (the metropolitan link is a 100M fiber - full almost all the time)??? From Robert Kurjata Thu Jan 15 08:27:42 2004 From: Robert Kurjata (Robert Kurjata) Date: Thu, 15 Jan 2004 09:27:42 +0100 Subject: Re[2]: [LARTC] wich tools In-Reply-To: <073101c3db3e$d323cd20$c2bf09ca@huecal> References: <40059B9E.80602@e-ar.pl> <1148909502.20040114213048@ire.pw.edu.pl> <073101c3db3e$d323cd20$c2bf09ca@huecal> Message-ID: <772939256.20040115092742@ire.pw.edu.pl> Witaj hare, W Twoim liœcie datowanym 15 stycznia 2004 (09:08:56) mo¿na przeczytaæ: hr> Hi Robert hr> iam trying setup like yours hr> for my DNS Services hr> i have patched all what u did hr> can i share your script for the load balance hr> or failover links script script is in the archives http://mailman.ds9a.nl/pipermail/lartc/2003q4/010372.html and its free for all :) as the source for the idea - nano-howto :) hr> to get an indea how can i create them for my server hr> thanks hr> hare hr> ----- Original Message ----- hr> From: "Robert Kurjata" hr> To: "Micha³ Witkowski" hr> Cc: hr> Sent: Thursday, January 15, 2004 2:00 AM hr> Subject: Re: [LARTC] wich tools >> Witaj Micha³, >> >> W Twoim liœcie datowanym 14 stycznia 2004 (20:42:22) mo¿na przeczytaæ: >> >> MW> Hello >> MW> I have two DSL modems witch are connected to my isp, in future my boss >> MW> want to buy another connection via DSL modem. Then i will have 3 DSL >> MW> modems. With every DSL modem i get 3x8 IP`s (netmask 248) from my ISP, >> MW> now i have question how to configure gateway wich tools should i use. >> MW> Because ip route and next hop via. wich i use now makes his work fine >> MW> but with new kernels there is an error in syslog "route sent us >> MW> somewhere else", and i think that with 3 DSL`s i will have problem >> MW> (there can be situation when 1DSL is busy and 2DSL aren`t). >> MW> Greetings >> MW> Michal Witkowski >> >> I have 3 uplinks, kernel 2.4.22+patch-o-matic+htb+esfq+julian's routes >> patch working load balancing and have no problems :) >> >> Classic configuration. >> >> Maybe something with missing patches? >> >> MW> _______________________________________________ >> MW> LARTC mailing list / LARTC@mailman.ds9a.nl >> MW> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> >> -- >> Pozdrowienia, >> Robert >> >> _______________________________________________ >> LARTC mailing list / LARTC@mailman.ds9a.nl >> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> -- Pozdrowienia, Robert mailto:rkurjata@ire.pw.edu.pl From cbolton@hirstanddanson.co.uk Thu Jan 15 08:37:33 2004 From: cbolton@hirstanddanson.co.uk (Chris Bolton) Date: Thu, 15 Jan 2004 08:37:33 -0000 Subject: Fw: Re:[LARTC] simple(?!?) source routing Message-ID: <006c01c3db42$d2627c20$0b00000a@Server2.hd> Hi, Thanks for the reply. Thats where the problem starts. If I set ppp0 as the default gw the internet doesnt work anymore. This is how im doing it... route del default route add default gw 217.32.81.74 dev ppp0 if I put it back to ppp1... route del default route add default gw 217.32.68.73 dev ppp1 It works fine again. Whats up with that? Cheers, Chris ----- Original Message ----- From: "andybr" To: Cc: Sent: Thursday, January 15, 2004 1:11 AM Subject: Re:[LARTC] simple(?!?) source routing > Hi all, > > This is easy. First let ppp0 as your default gateway and > use iproute to create a table call any name you want and > then you put ppp1 default route inside that table. After > that you have to create a rule to put the host you would > like insede it and dont forget to put a rule in the > iptables saying that everything going out via ppp1 SNAT - > -to IP_PPP1_EXTERNAL. ;) > > []´s > Anderson > > > > Hi, > > > > I've set up a Linux box with redhat on to act as an int > ernet gateway and I'm running into a few problems. Its g > ot two adsl modems connected to it, both connected to sep > erate 512kbs lines. Now I've followed the simple source > routing in the advanced routing howto to the letter but i > t doesnt work. > > > > I've got it autoconnecting on startup and redhat puts p > pp1 as the default gateway, this is then setup for masque > rading for the entire network. Therefore I've tried sett > ing up ppp0 as the deafult gateway for only one computer > (10.0.0.11), as it says at http://lartc.org/howto/lartc.r > pdb.html#LARTC.RPDB.SIMPLE I've done everything it says t > here and im 99% sure I've put the right ip addreses in et > c. When Ive gone through it that computer is no longer a > ble to access the net (the rest of the network is unaffec > ted). > > > > I'm pretty sure its the way ppp0 is configured, if I se > t it up so 10.0.0.11 uses ppp1 instead of ppp0 (ip rule a > dd default via xxx.xxx.xxx.xxx dev ppp1 table chris) it w > orks fine but obviously thers no point in that. > > > > Hope all this makes sence to someone, it baerly does ti > me. May thanks in advance. > > > > Chris > > > __________________________________________________________________________ > 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 cord@keppler.vrg.de Thu Jan 15 09:05:11 2004 From: cord@keppler.vrg.de (Cord Buhlert) Date: Thu, 15 Jan 2004 10:05:11 +0100 Subject: [LARTC] put shaping on ppp or eth? Message-ID: <20040115090510.GA17117@keppler.vrg.de> Hi, I wanna do some shaping on a DSL line that is plugged to the eth1 nic. Should I attach the qdiscs directly to the ppp device or can I use the eth1 device instead? What (and why) makes more sense? thx cb From cbolton@hirstanddanson.co.uk Thu Jan 15 09:28:43 2004 From: cbolton@hirstanddanson.co.uk (Chris Bolton) Date: Thu, 15 Jan 2004 09:28:43 -0000 Subject: [LARTC] simple(?!?) source routing References: <006c01c3db42$d2627c20$0b00000a@Server2.hd> Message-ID: <007801c3db49$fe076960$0b00000a@Server2.hd> Hi, Found the problem, usb timeout errors in /var/log.messages relating to speedtouch modems, had the problem before so its nothing new. Thanks again, Chris ----- Original Message ----- From: "Chris Bolton" Cc: Sent: Thursday, January 15, 2004 8:37 AM Subject: Fw: Re:[LARTC] simple(?!?) source routing > Hi, > > Thanks for the reply. Thats where the problem starts. If I set ppp0 as > the > default gw the internet doesnt work anymore. This is how im doing it... > > route del default > route add default gw 217.32.81.74 dev ppp0 > > if I put it back to ppp1... > > route del default > route add default gw 217.32.68.73 dev ppp1 > > It works fine again. Whats up with that? > > Cheers, > Chris > ----- Original Message ----- > From: "andybr" > To: > Cc: > Sent: Thursday, January 15, 2004 1:11 AM > Subject: Re:[LARTC] simple(?!?) source routing > > > > Hi all, > > > > This is easy. First let ppp0 as your default gateway and > > use iproute to create a table call any name you want and > > then you put ppp1 default route inside that table. After > > that you have to create a rule to put the host you would > > like insede it and dont forget to put a rule in the > > iptables saying that everything going out via ppp1 SNAT - > > -to IP_PPP1_EXTERNAL. ;) > > > > []´s > > Anderson > > > > > > > Hi, > > > > > > I've set up a Linux box with redhat on to act as an int > > ernet gateway and I'm running into a few problems. Its g > > ot two adsl modems connected to it, both connected to sep > > erate 512kbs lines. Now I've followed the simple source > > routing in the advanced routing howto to the letter but i > > t doesnt work. > > > > > > I've got it autoconnecting on startup and redhat puts p > > pp1 as the default gateway, this is then setup for masque > > rading for the entire network. Therefore I've tried sett > > ing up ppp0 as the deafult gateway for only one computer > > (10.0.0.11), as it says at http://lartc.org/howto/lartc.r > > pdb.html#LARTC.RPDB.SIMPLE I've done everything it says t > > here and im 99% sure I've put the right ip addreses in et > > c. When Ive gone through it that computer is no longer a > > ble to access the net (the rest of the network is unaffec > > ted). > > > > > > I'm pretty sure its the way ppp0 is configured, if I se > > t it up so 10.0.0.11 uses ppp1 instead of ppp0 (ip rule a > > dd default via xxx.xxx.xxx.xxx dev ppp1 table chris) it w > > orks fine but obviously thers no point in that. > > > > > > Hope all this makes sence to someone, it baerly does ti > > me. May thanks in advance. > > > > > > Chris > > > > > > > __________________________________________________________________________ > > 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/ > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From gomi@perezoso.net Thu Jan 15 10:00:38 2004 From: gomi@perezoso.net (GoMi) Date: Thu, 15 Jan 2004 11:00:38 +0100 Subject: [LARTC] QoS not working In-Reply-To: <007801c3db49$fe076960$0b00000a@Server2.hd> Message-ID: I have a setup based on htb and sfq qdiscs. When more than 100 users get connected to my lan, my internet setup works considerably bad. - I have a linux box with 1 eth card going to my switch (where the hubs connect to) and to eth cards to both adsl (2Mbit each) doing load balancing - My question is, is there a possibility the single ethcard cant cope with all the load? I have found no answers My setup: My adsl are 2Mbit down / 300kbit up -> but i only let each eth card send to each adsl router 150kbit to avoid collapsing during high load. DEV=eth1 tc qdisc add dev ${DEV} handle 1: root htb default 20 tc class add dev ${DEV} parent 1:1 classid 1:1 htb rate 150kbit burst 6k ######################################## ## Interactive traffic tc class add dev ${DEV} parent 1:1 classid 1:10 htb rate 50kbit ceil 150kbit b tc qdisc add dev ${DEV} parent 1:10 handle 10: sfq perturb 10 tc filter add dev ${DEV} protocol ip parent 1:0 handle 1 fw classid 1:10 ######################################## ## Non-Interactive Trafic tc class add dev ${DEV} parent 1:1 classid 1:20 htb rate 50kbit ceil 100kbit qu tc qdisc add dev ${DEV} parent 1:20 handle 20: esfq perturb 10 depth 15 tc filter add dev ${DEV} protocol ip parent 1:0 handle 2 fw classid 1:20 tc filter add dev ${DEV} protocol ip parent 1:0 handle 6 fw classid 1:20 ######################################## ## SYN,ACK Trafic tc class add dev ${DEV} parent 1:1 classid 1:30 htb rate 45kbit ceil 100kbit qu tc qdisc add dev ${DEV} parent 1:30 handle 30: sfq perturb 10 tc filter add dev ${DEV} protocol ip parent 1:0 handle 3 fw classid 1:30 ######################################## ## ICMP Trafic tc class add dev ${DEV} parent 1:1 classid 1:40 htb rate 5kbit quantum 1500 bur tc qdisc add dev ${DEV} parent 1:40 handle 40: pfifo tc filter add dev ${DEV} protocol ip parent 1:0 handle 4 fw classid 1:40 From x11@h2o.pieva.net Thu Jan 15 09:57:05 2004 From: x11@h2o.pieva.net (=?windows-1252?Q?Artu-ras_=8Alajus?=) Date: Thu, 15 Jan 2004 11:57:05 +0200 Subject: [LARTC] put shaping on ppp or eth? In-Reply-To: <20040115090510.GA17117@keppler.vrg.de> References: <20040115090510.GA17117@keppler.vrg.de> Message-ID: <400663F1.3040209@h2o.pieva.net> Cord Buhlert wrote: > Hi, > I wanna do some shaping on a DSL line that is plugged to the eth1 nic. > Should I attach the qdiscs directly to the ppp device or can I use the > eth1 device instead? What (and why) makes more sense? i think you should use ppp device :) dunno why -- Sincerely, ArtÅ«ras Å lajus ICQ: 157929934 Jabber: arturaz@akl.lt Oh, and please'o'please use UTF-8! :-) From hare ram" Hi all i have installed the FEDORA and i saw the fedora ships with latest IP and TC and HTB too when i add the with TC Script with HTB iam getting that HTB version. HTB init, kernel part version 3.12 and iam comparing with my old version which is installed and patched with TC 3.6 patch that is on RH 9.0 with TC and HTB patch shows HTB init, kernel part version 3.7 so which one is latest , iam concused could some one recomend me.. hare From nikolaou@ellemedia.com Thu Jan 15 11:08:47 2004 From: nikolaou@ellemedia.com (Nikos A. Nikolaou) Date: Thu, 15 Jan 2004 13:08:47 +0200 Subject: [LARTC] HTB and IP over ATM In-Reply-To: <200303172107.07636.stef.coene@docum.org> References: <200303172107.07636.stef.coene@docum.org> Message-ID: <400674BF.5030408@ellemedia.com> Hi there, Is there a way to have HTB working oven an ATM NIC that is running IP over ATM? Should you have any hints, please let me know. Regards, Nikos --- Nikos A. Nikolaou Ellemedia Technologies 223 Sygrou Ave. & 2 Tralleon St. GR-171 21, Athens, Hellas Tel: (+30) 210 9373 093 Fax: (+30) 210 9370 386 Email: nikolaou@ellemedia.com nikolaou@ieee.org --- From larslan@solan.zapto.org Thu Jan 15 12:48:32 2004 From: larslan@solan.zapto.org (Lars Landmark) Date: Thu, 15 Jan 2004 13:48:32 +0100 (CET) Subject: [LARTC] Two Gateways and NAT?? Message-ID: Hi; I have two dsl lines, which the low bandwidth connection(ISP2) is only used for failover. My setup is showed below; \ ISP1 \ / \ ____/NAT My internal net |-----|___| / \NAT / \ / ISP2 However, my interfaces which these lines are connected are both using NAT. My question is; will TCP connections that NAT.ed over interface ISP1 break if a failover happens and rerouted over ISP2?? Lars From andre.correa@pobox.com Thu Jan 15 12:12:11 2004 From: andre.correa@pobox.com (Andre Correa) Date: Thu, 15 Jan 2004 10:12:11 -0200 Subject: [LARTC] HTB In-Reply-To: References: Message-ID: <4006839A.9060505@pobox.com> Cristea, you are too vague in your question. I can tell you that you can shape MAN and WAN traffic separately using diferent classes and filters. 100Mbits for a single machine looks like too much traffic. Maybe you should divide load between more machines and have redundancy in your setup. If this is not what you meant, please let us know... Andre Cristea Virgil Ionut wrote: > Hi, I have the following questions: > > I only have one htb computer (2 nics) to shape the international traffic > as well as the metropolitan traffic (i have a list of metropolitan ip's > to use). Can this be achived using iptables with packet marking (on that > htb computer the 2 nics are bridged)? > If it can will there be delays introduced by the shaping operation (the > metropolitan link is a 100M fiber - full almost all the time)??? > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From virgil@vipnet.ro Thu Jan 15 15:47:06 2004 From: virgil@vipnet.ro (Cristea Virgil Ionut) Date: Thu, 15 Jan 2004 17:47:06 +0200 Subject: [LARTC] Re: HTB Message-ID: I have a fiber connection to MAN1, an ethernet connection to MAN2 (another city), and an ethernet connection to the WAN. My question was (well actually my new question is...) if i can shape all of the traffic using a computer with 4 nics (2xMAN,1 WAN,1 LAN) and what delays will this introduce (if it works)? Can a nic be part of multiple bridges???? If yes how will this affect my marking of the packets??? Sorry for the new questions (after some google i found the answer for my previous question) From damion@snapgear.com Fri Jan 16 01:26:22 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 16 Jan 2004 11:26:22 +1000 Subject: [LARTC] Two Gateways and NAT?? References: Message-ID: <40073DBE.8060102@snapgear.com> Hi, Lars Landmark wrote: > I have two dsl lines, which the low bandwidth connection(ISP2) is only > used for failover. -----8<----- > > However, my interfaces which these lines are connected are both using NAT. > My question is; will TCP connections that NAT.ed over interface ISP1 > break if a failover happens and rerouted over ISP2?? Yes, all your tcp connections will need to be re-established. the only way around this is to have both main and failover ISP/s do some multi-path routing trickery - which is probabaly very unlikely. 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 damion@snapgear.com Fri Jan 16 01:22:56 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 16 Jan 2004 11:22:56 +1000 Subject: [LARTC] put shaping on ppp or eth? References: <20040115090510.GA17117@keppler.vrg.de> <400663F1.3040209@h2o.pieva.net> Message-ID: <40073CF0.5010706@snapgear.com> Artu-ras Šlajus wrote: > Cord Buhlert wrote: > >> Hi, >> I wanna do some shaping on a DSL line that is plugged to the eth1 nic. >> Should I attach the qdiscs directly to the ppp device or can I use the >> eth1 device instead? What (and why) makes more sense? > > i think you should use ppp device :) > dunno why yes, you should use the ppp device, because you'll only get PPPoE packets on the ethernet device, and you won't be able to shape them. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 lartc@bobich.net Thu Jan 15 11:18:34 2004 From: lartc@bobich.net (Gordan Bobic) Date: Thu, 15 Jan 2004 11:18:34 +0000 Subject: [LARTC] Shaping Device Aliases Message-ID: <200401151118.04852.gordan@bobich.net> Hi. I understand that device aliases (e.g. eth2:3) are not shapeable. Does anybody know if this functionality is planned in the future? Anyway, for the time being the only option that seems to leave is to fwmark packets differently for each device alias and then shape based on that. Is it possible to set multiple marks on the packets? Alternatively, is it possible to check for a specific bit in a fwmark, and use these are individual flags by XOR-ing the fwmark against some mask that is being checked for? Gordan From damion@snapgear.com Fri Jan 16 06:23:33 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 16 Jan 2004 16:23:33 +1000 Subject: [LARTC] Shaping Device Aliases References: <200401151118.04852.gordan@bobich.net> Message-ID: <40078365.5030500@snapgear.com> Gordan Bobic wrote: > I understand that device aliases (e.g. eth2:3) are not shapeable. Does > anybody know if this functionality is planned in the future? None of the new(er) networking tools recognise device aliases, because on all recent linux releases, aliases don't exist. the ethX:X notation is a legacy notation used only by the ifconfig program. everything else just sees a ethX with more than one IP address. So you just run your shaping rules on the real interfaces, and restrict it's operation with IP address filtering. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 cal_kaiwen@hotmail.com Fri Jan 16 08:34:27 2004 From: cal_kaiwen@hotmail.com (kaiwen) Date: Fri, 16 Jan 2004 16:34:27 +0800 Subject: [LARTC] NAT with ip rule and ip route Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00F0_01C3DC4E.9C03CB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I am trying to achieve Stateless NAT with ip rule and ip route. Thanks = to LARTC doc, I have done it :) But, I have a lot of client wanted access to Internet, setting up 2 = rules for each of them is not desirable. For example I have 2 clients: Current setting: [root@son-ag webauth]# ip ru 0: from all lookup local 32760: from 192.168.8.113 lookup main map-to 192.168.250.113 32761: from 192.168.8.112 lookup main map-to 192.168.250.112 32766: from all lookup main 32767: from all lookup 253 [root@son-ag webauth]# ip route show table local | grep nat nat 192.168.250.113 via 192.168.8.113 scope host nat 192.168.250.112 via 192.168.8.112 scope host Can I do the following? [root@son-ag webauth]# ip ru 0: from all lookup local 32760: from 192.168.8.113 lookup main map-to 192.168.250.111 32761: from 192.168.8.112 lookup main map-to 192.168.250.111 32766: from all lookup main 32767: from all lookup 253 [root@son-ag webauth]# ip route show table local | grep nat nat 192.168.250.111 via 192.168.8.113 scope host nat 192.168.250.111 via 192.168.8.112 scope host Or, is there a better way to achieve what I want? Please advice. Thank you.,=20 Kaiwen ------=_NextPart_000_00F0_01C3DC4E.9C03CB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am trying to achieve Stateless NAT = with ip rule=20 and ip route. Thanks to LARTC doc, I have done it :)
But, I have a lot of client wanted = access to=20 Internet, setting up 2 rules for each of them is not = desirable.
 
For example I have 2 = clients:
 
Current setting:
 
[root@son-ag webauth]# ip=20 ru
0:      from all lookup = local
32760: =20 from 192.168.8.113 lookup main map-to 192.168.250.113
32761:  = from=20 192.168.8.112 lookup main map-to 192.168.250.112
32766:  from = all lookup=20 main
32767:  from all lookup 253
[root@son-ag webauth]# ip route show = table local |=20 grep nat
nat 192.168.250.113 via 192.168.8.113  scope = host
nat=20 192.168.250.112 via 192.168.8.112  scope host
Can I do the following?
 
[root@son-ag webauth]# ip=20 ru
0:      from all lookup = local
32760: =20 from 192.168.8.113 lookup main map-to 192.168.250.111
32761:  = from=20 192.168.8.112 lookup main map-to 192.168.250.111
32766:  from = all lookup=20 main
32767:  from all lookup 253
[root@son-ag webauth]# ip route show = table local |=20 grep nat
nat 192.168.250.111 via 192.168.8.113  scope = host
nat=20 192.168.250.111 via 192.168.8.112  scope host
 
Or, is there a better way to achieve = what I want?=20 Please advice.
 
Thank you.,
Kaiwen
------=_NextPart_000_00F0_01C3DC4E.9C03CB40-- From cord@keppler.vrg.de Fri Jan 16 13:47:47 2004 From: cord@keppler.vrg.de (Cord Buhlert) Date: Fri, 16 Jan 2004 14:47:47 +0100 Subject: [LARTC] put shaping on ppp or eth? In-Reply-To: <20040115090510.GA17117@keppler.vrg.de> References: <20040115090510.GA17117@keppler.vrg.de> Message-ID: <20040116134747.GA20114@keppler.vrg.de> Hi, just tried it - must use ppp0 ethx doesn't work cb From totya@mail.ajkanet.hu Fri Jan 16 22:04:22 2004 From: totya@mail.ajkanet.hu (Toth Szabolcs) Date: Fri, 16 Jan 2004 23:04:22 +0100 (CET) Subject: [LARTC] iproute2 source compiling problem In-Reply-To: <20040115055740.5948.43902.Mailman@outpost.ds9a.nl> Message-ID: Hello ! Have anyone got an iproute2 source with HTB which I can compile with the includes of kernel 2.4.21 or higher. I had one but I get the following error msgs: q_htb.c:338: redefinition of `explain' q_htb.c:32: `explain' previously defined here q_htb.c:357: redefinition of `explain1' q_htb.c:51: `explain1' previously defined here q_htb.c:366: redefinition of `htb_parse_opt' q_htb.c:60: `htb_parse_opt' previously defined here q_htb.c:406: redefinition of `htb_parse_class_opt' q_htb.c:100: `htb_parse_class_opt' previously defined here q_htb.c:523: redefinition of `htb_print_opt' q_htb.c:217: `htb_print_opt' previously defined here q_htb.c:578: redefinition of `htb_print_xstats' q_htb.c:272: `htb_print_xstats' previously defined here q_htb.c:593: redefinition of `htb_util' q_htb.c:287: `htb_util' previously defined here q_htb.c:604: redefinition of `htb2_util' q_htb.c:298: `htb2_util' previously defined here q_htb.c:644: redefinition of `explain' q_htb.c:338: `explain' previously defined here q_htb.c:663: redefinition of `explain1' q_htb.c:357: `explain1' previously defined here q_htb.c:672: redefinition of `htb_parse_opt' q_htb.c:366: `htb_parse_opt' previously defined here q_htb.c:712: redefinition of `htb_parse_class_opt' q_htb.c:406: `htb_parse_class_opt' previously defined here q_htb.c:829: redefinition of `htb_print_opt' q_htb.c:523: `htb_print_opt' previously defined here q_htb.c:884: redefinition of `htb_print_xstats' q_htb.c:578: `htb_print_xstats' previously defined here q_htb.c:899: redefinition of `htb_util' q_htb.c:593: `htb_util' previously defined here q_htb.c:910: redefinition of `htb2_util' q_htb.c:604: `htb2_util' previously defined here q_htb.c:950: redefinition of `explain' q_htb.c:644: `explain' previously defined here q_htb.c:973: redefinition of `explain1' q_htb.c:663: `explain1' previously defined here q_htb.c:982: redefinition of `htb_parse_opt' q_htb.c:672: `htb_parse_opt' previously defined here q_htb.c:1022: redefinition of `htb_parse_class_opt' q_htb.c:712: `htb_parse_class_opt' previously defined here q_htb.c:1155: redefinition of `htb_print_opt' q_htb.c:829: `htb_print_opt' previously defined here q_htb.c:1217: redefinition of `htb_print_xstats' q_htb.c:884: `htb_print_xstats' previously defined here q_htb.c:1232: redefinition of `htb_util' q_htb.c:899: `htb_util' previously defined here q_htb.c:1243: redefinition of `htb2_util' q_htb.c:910: `htb2_util' previously defined here make[1]: *** [q_htb.o] Error 1 make[1]: Leaving directory `/usr/src/iproute2/tc' make: *** [all] Error 2 yoda:/usr/src/iproute2 please help me. thanx Szabolcs Toth From vica_s@mail.ru Sat Jan 17 04:59:36 2004 From: vica_s@mail.ru (vica_s@mail.ru) Date: Sat, 17 Jan 2004 07:59:36 +0300 Subject: [LARTC] Random ping jumps In-Reply-To: <3FFC7969.1040103@h2o.pieva.net> References: <3FFC7969.1040103@h2o.pieva.net> Message-ID: <20040117075936.78b04b19.vica_s@mail.ru > Hi All ! On Wed, 07 Jan 2004 23:26:01 +0200 Art wrote: > I've got this problem. There is an linux server with 2.4.24 kernel > and pinging from him to internet (or from lan) ping randomly jumps up: > > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=387 ttl=59 time=30.0 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=388 ttl=59 time=32.6 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=389 ttl=59 time=34.9 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=390 ttl=59 time=198 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=391 ttl=59 time=407 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=392 ttl=59 time=407 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=393 ttl=59 time=430 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=394 ttl=59 time=30.9 ms > 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=395 ttl=59 time=31.6 ms yesterday i have like that trouble when change ( test ) named.conf , try off DNS , and ping to ip. Best regards vica. From Jurrie Overgoor" <20040117075936.78b04b19.vica_s@mail.ru > Message-ID: <000f01c3dce0$65378bf0$5668a8c0@RADON> Hello all, > On Wed, 07 Jan 2004 23:26:01 +0200 > Art wrote: > > > I've got this problem. There is an linux server with 2.4.24 kernel > > and pinging from him to internet (or from lan) ping randomly jumps up: [snip] > > yesterday i have like that trouble when change ( test ) named.conf , > try off DNS , and ping to ip. I don't think this is the problem. Afaik the dns server is only queried once, to get the ip adres of the target host. After that, dns is left alone. I suspect the problem to be a faulty cable or nic... Greetz -- Jurrie jurrie.overgoor@zonnet.nl From janzun@rosanegra.org Sun Jan 18 12:58:07 2004 From: janzun@rosanegra.org (JaNzUn) Date: Sun, 18 Jan 2004 13:58:07 +0100 Subject: [LARTC] HTB + ESFQ in nat router for shape incoming by ip Message-ID: <400A82DF.7060003@rosanegra.org> Hi, i´ve read about this problem but i didn´t find any solution. I have a router with nat like that: internet - eth0 - Router - eth1 - Lan I made a htb script for shaping outgoing in eth0 and it works great. The problem begin with the incoming traffic... Like other people said, when somebody in the lan uses the tipical download accelerator, the line is out because the bandwidth is divided by conexions. So, i decided to use htb (with one class, filter and iptables mark per ip) for shaping an ceil traffic if it isn´t in use. All ok. Now i need to shape by ip, so i use esfq... but nothing happend. A few lines of my script can be read here: (Only for 2 ips, there are a lot of them, but i do the test with two machines, one with daccelerator an other with simple download). $tc qdisc add dev eth1 root handle 2:0 htb default 20 $tc class add dev eth1 parent 2:0 classid 2:2 htb rate 10mbit ceil 100mbit $tc class add dev eth1 parent 2:2 classid 2:9 htb rate 10mbit prio 2 $tc class add dev eth1 parent 2:2 classid 2:10 htb rate $DOWN ceil $TDOWN prio 2 $tc class add dev eth1 parent 2:2 classid 2:11 htb rate $DOWN ceil $TDOWN prio 2 $tc class add dev eth1 parent 2:2 classid 2:20 htb rate 10kbit ceil 100mbit prio 2 $tc qdisc add dev eth1 parent 2:10 handle 10: esfq perturb 10 hash dst $tc qdisc add dev eth1 parent 2:11 handle 11: esfq perturb 10 hash dst $tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 1 fw classid 2:9 $tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 10 fw classid 2:10 $tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 11 fw classid 2:11 iptables -A POSTROUTING -t mangle -o eth1 -p tcp --destination 192.168.1.88 -j MARK --set-mark 10 iptables -A POSTROUTING -t mangle -o eth1 -p tcp --destination 192.168.1.222 -j MARK --set-mark 11 I know rates are a bit stranges, but its only a test and htb works fine. The problem is the esfq, not work! Has anybody make to work esfq? In this case, could you put a real script with it? Or... anybody knows any metod to split incoming traffic by ip testing and working? Thanks. From andy.furniss@dsl.pipex.com Sun Jan 18 18:53:57 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sun, 18 Jan 2004 18:53:57 +0000 Subject: [LARTC] HTB + ESFQ in nat router for shape incoming by ip In-Reply-To: <400A82DF.7060003@rosanegra.org> References: <400A82DF.7060003@rosanegra.org> Message-ID: <04011818535700.00676@amd> On Sunday 18 January 2004 12:58 pm, JaNzUn wrote: > Hi, i´ve read about this problem but i didn´t find any solution. > > I have a router with nat like that: > internet - eth0 - Router - eth1 - Lan > > I made a htb script for shaping outgoing in eth0 and it works great. The > problem begin with the incoming traffic... Like other people said, when > somebody in the lan uses the tipical download accelerator, the line is > out because the bandwidth is divided by conexions. So, i decided to use > htb (with one class, filter and iptables mark per ip) for shaping an > ceil traffic if it isn´t in use. All ok. Now i need to shape by ip, so i > use esfq... but nothing happend. > A few lines of my script can be read here: (Only for 2 ips, there are a > lot of them, but i do the test with two machines, one with daccelerator > an other with simple download). > > $tc qdisc add dev eth1 root handle 2:0 htb default 20 > $tc class add dev eth1 parent 2:0 classid 2:2 htb rate 10mbit ceil > 100mbit $tc class add dev eth1 parent 2:2 classid 2:9 htb rate 10mbit > prio 2 $tc class add dev eth1 parent 2:2 classid 2:10 htb rate $DOWN > ceil $TDOWN prio 2 > $tc class add dev eth1 parent 2:2 classid 2:11 htb rate $DOWN ceil > $TDOWN prio 2 > $tc class add dev eth1 parent 2:2 classid 2:20 htb rate 10kbit ceil > 100mbit prio 2 > > $tc qdisc add dev eth1 parent 2:10 handle 10: esfq perturb 10 hash dst > $tc qdisc add dev eth1 parent 2:11 handle 11: esfq perturb 10 hash dst > > $tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 1 fw > classid 2:9 > $tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 10 fw > classid 2:10 > $tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 11 fw > classid 2:11 > > iptables -A POSTROUTING -t mangle -o eth1 -p tcp --destination > 192.168.1.88 -j MARK --set-mark 10 > iptables -A POSTROUTING -t mangle -o eth1 -p tcp --destination > 192.168.1.222 -j MARK --set-mark 11 > > I know rates are a bit stranges, but its only a test and htb works > fine. The problem is the esfq, not work! > > Has anybody make to work esfq? In this case, could you put a real script > with it? > Or... anybody knows any metod to split incoming traffic by ip testing > and working? > > Thanks. I think if you want esqf to do dst filtering, then you should use htb to seperate interactive traffic and have just one class for everyones bulk traffic with one esqf attached. You are already splitting with htb the ips to 10 and 11 then giving them one queue each - they should go to one esqf. I'm not sure, but shouldn't you use flowid rather than classid in the $tc filter add lines. Andy. From rubens@etica.net Sun Jan 18 18:37:59 2004 From: rubens@etica.net (rubens@etica.net) Date: Sun, 18 Jan 2004 16:37:59 -0200 (BRST) Subject: [LARTC] HTB + ESFQ in nat router for shape incoming by ip In-Reply-To: <400A82DF.7060003@rosanegra.org> Message-ID: > I made a htb script for shaping outgoing in eth0 and it works great. The > problem begin with the incoming traffic... Like other people said, when > somebody in the lan uses the tipical download accelerator, the line is > out because the bandwidth is divided by conexions. So, i decided to use Only if sfq is the outgoing scheduler; other schedulers will give different results. > htb (with one class, filter and iptables mark per ip) for shaping an > ceil traffic if it isn=B4t in use. All ok. Now i need to shape by ip, so = i > use esfq... but nothing happend. If you want to share the bandwidth equally among IPs, you can use ESFQ as root qdisc. What your script is doing is creating a class for each IP and defining a rate for it. Rubens From jayesh_rathod@sify.com Mon Jan 19 07:41:32 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Mon, 19 Jan 2004 12:41:32 +0500 (IST) Subject: [LARTC] tool to monitor HTB class utilisation Message-ID: <1074496292.400b8324cb99a@smwp01.maa.sify.net> Hi, can any body suggest any tool which can show the utilisation for individual classes for HTB. preferable written in C/or shell script. Regards Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From tusharthakker@elitecore.com Mon Jan 19 22:49:34 2004 From: tusharthakker@elitecore.com (Tushar Thakker) Date: Mon, 19 Jan 2004 14:49:34 -0800 Subject: [LARTC] failover does not work for static ip rules Message-ID: <019e01c3dede$8256d2e0$3301a8c0@elitecore1> hello all, previously i had some problems setting up a load balancing network, but now after re-applying the julian patch, it works good, but my doubt is that if we have statically provided and IP Rule for some network to use some particular gateway like follows, ip rule add prio 203 from 192.168.1.0/24 table 203 ip route add default via 203.88.135.213 dev eth1 src 203.88.135.212 proto static table 203 ip route append prohibit default table 203 metric 1 proto static but now, if the gateway goes down, then will it refer to the next priority table , i.e. 221? the next priority table is as follows, ip rule add prio 221 table 221 ip route add default table 221 proto static \ nexthop via 203.88.135.213 dev eth1 weight 1\ nexthop via 203.88.135.193 dev eth2 weight 1 so, if the static route fails, will that refer the next priotiry table? failover works if i have not specified the static ip rule, but it does not work in case of this rule 203, can anyone explain why this happens? thanks and regards ----------------------------------------------------------Tushar Thakker Elitecore Technologies Ltd. ----------------------------------------------------------Life gives all that one deserves, but not all that one desires... ---------------------------------------------------------- From Aron@sofaware.com Mon Jan 19 13:19:08 2004 From: Aron@sofaware.com (Aron Brand) Date: Mon, 19 Jan 2004 15:19:08 +0200 Subject: [LARTC] Ingress Shaping using IMQ Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE2DB8BC@mail.sofaware.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DE8E.5F509146 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guys, Here is a question that is probably of concern to many of us. I am under pressure to provide some solution for ingress traffic shaping. What my customer demands is to divide the downstream (ingress) of an ADSL lines to two classes of traffic - important traffic and non important downloads. He has a very reasonable requirement: he wants a guarantee of at least 1000kbps at all times for the important traffic on the downstream.=20 Using ingress policing would be the trivial solution. But no says the customer - when the important traffic is not fully utilizing its rate, I want it to share the excess with other classes.=20 After looking around, the answer I found was to use imq, which claims to allow traffic shaping on ingress traffic. So far so good. And now I arrive to the question: It is possible to configure everything in THEORY. The question is, it it really possible for me to give the guarantee that my customer is asking for? I can think of examples why it seems that the answer is no. For example, lets say the ingress line is completely saturated with non-important traffic. How on earth can the poor HTB determine whether important traffic is being drowned out - or there is simply no important traffic? My speculation so far - it is possible to configure these rules, and indeed this is what IMQ was invented for, but in true life there is no solution that works - since it is inherently impossible! Has anyone really created and tested a working ingress traffic shaping solution? Aron ------_=_NextPart_001_01C3DE8E.5F509146 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ingress Shaping using IMQ

Hi = Guys,

Here is = a question that is probably of concern to many of us.

I am = under pressure to provide some solution for ingress traffic shaping. = What my customer demands is to divide the downstream (ingress) of an = ADSL lines to two classes of traffic - important traffic and non = important downloads. He has a very reasonable requirement: he wants a = guarantee of at least 1000kbps at all times for the important traffic on = the downstream.

Using = ingress policing would be the trivial solution. But no says the customer = - when the important traffic is not fully utilizing its rate, I want it = to share the excess with other classes.

After = looking around, the answer I found was to use imq, which claims to allow = traffic shaping on ingress traffic. So far so good.

And now = I arrive to the question: It is possible to configure everything in = THEORY. The question is, it it really possible for me to give the = guarantee that my customer is asking for? I can think of examples why it = seems that the answer is no. For example, lets say the ingress line is = completely saturated with non-important traffic. How on earth can the = poor HTB determine whether important traffic is being drowned out - or = there is simply no important traffic?

My = speculation so far - it is possible to configure these rules, and indeed = this is what IMQ was invented for, but in true life there is no solution = that works - since it is inherently impossible!

Has = anyone really created and tested a working ingress traffic shaping = solution?

Aron


------_=_NextPart_001_01C3DE8E.5F509146-- From javier@talika.eii.us.es Mon Jan 19 12:35:04 2004 From: javier@talika.eii.us.es (Javier Miguel Rodríguez) Date: Mon, 19 Jan 2004 13:35:04 +0100 Subject: [LARTC] Problems with source routing Message-ID: <20040119123504.GA29774@talika.eii.us.es> Hello I have the following problem: LAN<--->LINUX_ROUTER<--> 2 internet gateways gateway1: adsl gateway2: ppp connection I want the following Machines from LAN going to Internet tcp port 80 :-> gateway1 Machines from LAN goint to Internet tcp port 22 :-> gateway2 Everything else: -> gateway1 How can I acomplish this? I am using kernel 2.4.24 Can I combine dead gateway detection with the previous? how? Greetings from Spain! From vinokurov@mail.ru Mon Jan 19 14:07:58 2004 From: vinokurov@mail.ru (Nikita Vinokurov) Date: Mon, 19 Jan 2004 17:07:58 +0300 Subject: [LARTC] Two ISP load balancing + One ISP' subnet explicit routing Message-ID: <400BE4BE.8020404@mail.ru> Hello! I have a problem. May be here exist anyone who has encountered with the following problem. I have a router which is connected to 2 ISP from external side and one LAN internal interface. The feature is that the one ISP allocates a subnet xxx.xxx.xxx.160/28 for me but I split it into two subnets xxx.xxx.xxx.160/29 and xxx.xxx.xxx.168/29 and assign the latter to the internal interface. Also I have organiezed an DNAT+SNAT so all internet requests is DNATted to and SNATted from xxx.xxx.xxx.170 (which is a second firewall running Microsoft ISA). So ip route list: y.y.y.96/30 dev eth1 proto kernel scope link src y.y.y.98 x.x.x.168/29 dev eth0 proto kernel scope link src x.x.x.169 x.x.x.160/29 dev eth2 proto kernel scope link src x.x.x.162 Also loadbalancing between eth1 and eth2 is organized with the 'ip' tool: ip route list table 222 default table 222 proto static nexthop via y.y.y.97 dev eth1 weight 1 nexthop via x.x.x.161 dev eth2 weight 10 SNAT was set to: iptables -t nat -L POSTROUTING -o eth2 -j SNAT --to-destination x.x.x.162 iptables -t nat -L POSTROUTING -o eth1 -j SNAT --to-destination y.y.y.98 But now I have to establish VPN channel to connect a given external machine with known IP (z.z.z.z) to my ISA firewall, but avoiding NAT. I have tried to implement it the such way: ip route list: y.y.y.96/30 dev eth1 proto kernel scope link src y.y.y.98 x.x.x.168/29 dev eth0 proto kernel scope link src x.x.x.169 x.x.x.160/28 dev eth2 proto kernel scope link src x.x.x.162 and SNAT is test to: iptables -t nat -L POSTROUTING -o eth2 -d ! z.z.z.z -j SNAT --to-destination x.x.x.162 But when I try to access from z.z.z.z, for example, the x.x.x.170 address, it does not reply. Where is a mistake? -- Nikita Vinokurov From Robert Kurjata Mon Jan 19 14:10:21 2004 From: Robert Kurjata (Robert Kurjata) Date: Mon, 19 Jan 2004 15:10:21 +0100 Subject: [LARTC] Problems with source routing In-Reply-To: <20040119123504.GA29774@talika.eii.us.es> References: <20040119123504.GA29774@talika.eii.us.es> Message-ID: <16023647222.20040119151021@ire.pw.edu.pl> Witaj Javier, W Twoim liœcie datowanym 19 stycznia 2004 (13:35:04) mo¿na przeczytaæ: JMR> Hello JMR> I have the following problem: JMR> LAN<--->LINUX_ROUTER<--> 2 internet gateways JMR> gateway1: adsl JMR> gateway2: ppp connection JMR> I want the following JMR> Machines from LAN going to Internet tcp port 80 :-> gateway1 JMR> Machines from LAN goint to Internet tcp port 22 :-> gateway2 Everything else: ->> gateway1 JMR> How can I acomplish this? I am using kernel 2.4.24 JMR> Can I combine dead gateway detection with the previous? how? JMR> Greetings from Spain! Hint: firewall mark + policy routing Read the archives, its trivial. -- Pozdrowienia, Robert mailto:rkurjata@ire.pw.edu.pl From serge.maandag@staff.zeelandnet.nl Mon Jan 19 14:52:09 2004 From: serge.maandag@staff.zeelandnet.nl (Serge Maandag) Date: Mon, 19 Jan 2004 15:52:09 +0100 Subject: [LARTC] a couple of questions regarding htb Message-ID: <91FC132ACA694F45A6E42CE8E593838C39C2CE@zmx.staff.zeelandnet.nl> This is a multi part message in MIME format. --_NextPart_1_qmZrHLajoetbkwlTZTViemHPfyb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear list, =20 I want to rate-limit a couple of customers in both up and down directions. They get a different speed for traffic staying on our network than for traffic towards/from the internet, so that's a master class and 2 child classes per customer per interface. =20 I made a test setup with cbq which worked, but wasn't too reliable I measured a tolerance of about 30%. I read that cbq is not maintained, htb is much more reliable, and I believe I can do the same classful=20 stuff mentioned above with htb. =20 Am I correct? =20 The box I will use to limit the traffic on has 3 ethernet connections with customers and 1 uplink. I read somewhere that only outgoing traffic can be limited.=20 =20 Is that correct or will limiting of incoming traffic work but isn't it just as reliable? =20 If I would filter outgoing traffic from the customer on the box, I would have to do that on every=20 interface except for the one the customer is on. Therefore the client will be able to sent out more traffic than allowed, if it is spread over multiple outgoing interfaces.=20 =20 Is there a solution to this? =20 I figure I can not make classes that span multiple interfaces to limit the total traffic leaving the=20 box and coming from the customer? =20 If I use ip aliasing (a la eth0:1), does that mean I would have to make qdiscs/classes for eth0:1 or will the traffic be covered by the qdisc/classes on eth0? =20 Uhmm, that's enough for now. =20 Thanks a lot to everyone who can help me a bit further. =20 Serge. ------------- Op de inhoud van dit e-mailbericht en de daaraan gehechte bijlagen is de = inhoud van de volgende disclaimer van toepassing: = http://www.zeelandnet.nl/disclaimer.php --_NextPart_1_qmZrHLajoetbkwlTZTViemHPfyb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Dear=20 list,
 
I want = to rate-limit=20 a couple of customers in both up and down = directions.
They get = a different=20 speed for traffic staying on our network than for traffic = towards/from=20 the internet,
so = that's a master=20 class and 2 child classes per customer per interface.
 
I made a = test setup=20 with cbq which worked, but wasn't too reliable I measured a tolerance of = about=20 30%.
I read = that cbq is=20 not maintained, htb is much more reliable, and I  = believe I can do = the same=20 classful
stuff = mentioned=20 above with htb.
 
Am I=20 correct?
 
The box = I will=20 use to limit the traffic on has 3 ethernet connections with customers = and 1=20 uplink.
I read = somewhere=20 that only outgoing traffic can be limited.
 
Is that = correct=20 or will limiting of incoming traffic work but = isn't it just=20 as reliable?
 
If I = would filter=20 outgoing traffic from the customer on the box, I would have to do that on = every=20
interface except for=20 the one the customer is on. Therefore the client will be able to sent=20 out
more = traffic than=20 allowed, if it is spread over multiple outgoing interfaces.=20
 
Is there = a solution=20 to this?
 
I figure = I can not=20 make classes that span multiple interfaces to limit the total traffic = leaving=20 the
box and = coming from=20 the customer?
 
If I use = ip aliasing=20 (a la eth0:1), does that mean I would have to make qdiscs/classes for=20 eth0:1
or will = the traffic=20 be covered by the qdisc/classes on eth0?
 
Uhmm, = that's enough=20 for now.
 
Thanks a = lot to=20 everyone who can help me a bit further.
 
Serge.

-------------
Op de inhoud van dit e-mailbericht en de daaraan gehechte bijlagen is de = inhoud van de volgende disclaimer van toepassing: = http://www.zeelandnet.nl/disclaimer.php
--_NextPart_1_qmZrHLajoetbkwlTZTViemHPfyb-- From lartc@netwrox.org Mon Jan 19 15:21:57 2004 From: lartc@netwrox.org (Andy Hawthorn) Date: Mon, 19 Jan 2004 15:21:57 -0000 Subject: [LARTC] Problem implementing split access Message-ID: <003101c3de9f$fa117400$1101a8c0@andy17> Hello, I am attempting to implement load balancing on a firewall to allow me to use two ISPs. I have followed the instructions in section 4.2 of the LARTC HOWTO but have got stuck on the split access section I have the options CONFIG_IP_ADVANCED_ROUTER and CONFIG_IP_MULTIPLE_TABLES in my kernel (2.4.24) and have added routes to the /etc/iproute2/rt_tables file but when I try a command in the form of: ip route add $P1_NET dev $IF1 src $IP1 table T1 such as: ip route add 192.168.10.0/24 dev eth0 src 192.168.10.250 table myisp I get the error: RTNETLINK answers: Invalid argument This sounds like I have missed something that I need in the kernel but everything that was listed in the HOWTO has been included in my kernel. If I try the command without the src argument such as: ip route add 192.168.10.0/24 dev eth0 table myisp ..then I get no errors which would seem to sugest that the src argument is the problem here. Any insight someone might have would be most apreciated! Thanks, Andy From hare ram" Message-ID: <00f301c3dea4$d90fccc0$c2bf09ca@huecal> i think you can find the very good tools in docum.org hare ----- Original Message ----- From: "jayesh rathod" To: Sent: Monday, January 19, 2004 1:11 PM Subject: [LARTC] tool to monitor HTB class utilisation > > Hi, > > can any body suggest any tool which can show the utilisation for individual classes for HTB. > > preferable written in C/or shell script. > > Regards > Jayesh > > ------------------------------------------------- > Still single? Click here to find the perfect match. > > http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From rubens@etica.net Mon Jan 19 16:35:48 2004 From: rubens@etica.net (rubens@etica.net) Date: Mon, 19 Jan 2004 14:35:48 -0200 (BRST) Subject: [LARTC] a couple of questions regarding htb In-Reply-To: <91FC132ACA694F45A6E42CE8E593838C39C2CE@zmx.staff.zeelandnet.nl> Message-ID: > They get a different speed for traffic staying on our network than for > traffic towards/from the internet, > so that's a master class and 2 child classes per customer per interface. Ok. > I made a test setup with cbq which worked, but wasn't too reliable I > measured a tolerance of about 30%. > I read that cbq is not maintained, htb is much more reliable, and I > believe I can do the same classful > stuff mentioned above with htb. Correct. > The box I will use to limit the traffic on has 3 ethernet connections > with customers and 1 uplink. > I read somewhere that only outgoing traffic can be limited. Only outgoing traffic can be classfully shaped or limited. > Is that correct or will limiting of incoming traffic work but isn't it > just as reliable? It's just not very flexible. > If I would filter outgoing traffic from the customer on the box, I would > have to do that on every > interface except for the one the customer is on. Therefore the client > will be able to sent out > more traffic than allowed, if it is spread over multiple outgoing > interfaces. What is your concern, inter-customer traffic ? Or even the Internet traffic can go thru more than one interface ? > Is there a solution to this? Yes, IMQ. You can do ingress shaping with it, or you can bundle output traffic from various interfaces and shape at a single point. > If I use ip aliasing (a la eth0:1), does that mean I would have to make > qdiscs/classes for eth0:1 > or will the traffic be covered by the qdisc/classes on eth0? No qdiscs for aliases, all traffic is covered at that the main interface. Rubens From gaston@steel.com.ar Mon Jan 19 17:08:43 2004 From: gaston@steel.com.ar (=?iso-8859-1?Q?Gast=F3n?=) Date: Mon, 19 Jan 2004 14:08:43 -0300 Subject: [LARTC] Shaping inbound ok, outbound wrong Message-ID: <000901c3deae$e465abd0$cd302bc8@traza> Hi, I´m shaping traffic using htb on both interfaces, I noticed that shaping download traffic is workinggreat but shaping upload traffic is not working at all (no sent packets, no dropped, no overlimits)I have eth0 facing the backbone and eth1 facing the LAN. Thanks for your help.These are the commands I run:tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1 htb default 10 r2q 5 tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1 htb default 10 r2q 5 tc class add dev eth0 parent 1: classid 1:2 htb rate 3Mbit tc class add dev eth0 parent 1:2 classid 1:100 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:100 handle 100 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.15 classid 1:100 tc class add dev eth0 parent 1:2 classid 1:101 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:101 handle 101 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.16 classid 1:101 tc class add dev eth0 parent 1:2 classid 1:102 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:102 handle 102 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.17 classid 1:102 tc class add dev eth0 parent 1:2 classid 1:103 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth0 parent 1:103 handle 103 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.18 classid 1:103 tc class add dev eth0 parent 1:2 classid 1:104 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:104 handle 104 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.22 classid 1:104 tc class add dev eth0 parent 1:2 classid 1:105 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:105 handle 105 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.21 classid 1:105 tc class add dev eth0 parent 1:2 classid 1:106 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:106 handle 106 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.19 classid 1:106 tc class add dev eth0 parent 1:2 classid 1:107 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:107 handle 107 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.23 classid 1:107 tc class add dev eth0 parent 1:2 classid 1:108 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:108 handle 108 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.24 classid 1:108 tc class add dev eth0 parent 1:2 classid 1:2211 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth0 parent 1:2211 handle 2211 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.220 classid 1:2211 tc class add dev eth0 parent 1:2 classid 1:2212 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:2212 handle 2212 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.225 classid 1:2212 tc class add dev eth0 parent 1:2 classid 1:53 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth0 parent 1:53 handle 53 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.4 classid 1:53 tc class add dev eth0 parent 1:2 classid 1:54 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth0 parent 1:54 handle 54 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.100 classid 1:54 tc class add dev eth0 parent 1:2 classid 1:55 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:55 handle 55 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 10.10.100.4 classid 1:55 tc class add dev eth0 parent 1:2 classid 1:56 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:56 handle 56 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.50.13 classid 1:56 tc class add dev eth0 parent 1:2 classid 1:58 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:58 handle 58 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.27 classid 1:58 tc class add dev eth0 parent 1:2 classid 1:60 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth0 parent 1:60 handle 60 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.26 classid 1:60 tc class add dev eth0 parent 1:2 classid 1:82 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth0 parent 1:82 handle 82 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.6 classid 1:82 tc class add dev eth0 parent 1:2 classid 1:84 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:84 handle 84 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.25 classid 1:84 tc class add dev eth0 parent 1:2 classid 1:85 htb rate 384Kbit ceil 384Kbit tc qdisc add dev eth0 parent 1:85 handle 85 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.1 classid 1:85 tc class add dev eth0 parent 1:2 classid 1:86 htb rate 384Kbit ceil 384Kbit tc qdisc add dev eth0 parent 1:86 handle 86 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.2 classid 1:86 tc class add dev eth0 parent 1:2 classid 1:88 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth0 parent 1:88 handle 88 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.5 classid 1:88 tc class add dev eth0 parent 1:2 classid 1:89 htb rate 1024Kbit ceil 1024Kbit tc qdisc add dev eth0 parent 1:89 handle 89 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.3 classid 1:89 tc class add dev eth0 parent 1:2 classid 1:90 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth0 parent 1:90 handle 90 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.7 classid 1:90 tc class add dev eth0 parent 1:2 classid 1:91 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:91 handle 91 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.8 classid 1:91 tc class add dev eth0 parent 1:2 classid 1:92 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:92 handle 92 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.20 classid 1:92 tc class add dev eth0 parent 1:2 classid 1:93 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:93 handle 93 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.10 classid 1:93 tc class add dev eth0 parent 1:2 classid 1:94 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:94 handle 94 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.9 classid 1:94 tc class add dev eth0 parent 1:2 classid 1:95 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth0 parent 1:95 handle 95 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.210 classid 1:95 tc class add dev eth0 parent 1:2 classid 1:96 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth0 parent 1:96 handle 96 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.11 classid 1:96 tc class add dev eth0 parent 1:2 classid 1:97 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:97 handle 97 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.12 classid 1:97 tc class add dev eth0 parent 1:2 classid 1:98 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:98 handle 98 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.13 classid 1:98 tc class add dev eth0 parent 1:2 classid 1:99 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth0 parent 1:99 handle 99 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.14 classid 1:99 tc class add dev eth1 parent 1: classid 1:2 htb rate 3Mbit tc class add dev eth1 parent 1:2 classid 1:2254 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:2254 handle 2254 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.220 classid 1:2254 tc class add dev eth1 parent 1:2 classid 1:2255 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:2255 handle 2255 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.225 classid 1:2255 tc class add dev eth1 parent 1:2 classid 1:53 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth1 parent 1:53 handle 53 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.4 classid 1:53 tc class add dev eth1 parent 1:2 classid 1:54 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth1 parent 1:54 handle 54 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.100 classid 1:54 tc class add dev eth1 parent 1:2 classid 1:55 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:55 handle 55 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.10.100.4 classid 1:55 tc class add dev eth1 parent 1:2 classid 1:56 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:56 handle 56 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.50.13 classid 1:56 tc class add dev eth1 parent 1:2 classid 1:58 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:58 handle 58 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.27 classid 1:58 tc class add dev eth1 parent 1:2 classid 1:60 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth1 parent 1:60 handle 60 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.26 classid 1:60 tc class add dev eth1 parent 1:2 classid 1:60 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:60 handle 60 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.6 classid 1:60 tc class add dev eth1 parent 1:2 classid 1:62 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:62 handle 62 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.25 classid 1:62 tc class add dev eth1 parent 1:2 classid 1:63 htb rate 384Kbit ceil 384Kbit tc qdisc add dev eth1 parent 1:63 handle 63 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.1 classid 1:63 tc class add dev eth1 parent 1:2 classid 1:64 htb rate 384Kbit ceil 384Kbit tc qdisc add dev eth1 parent 1:64 handle 64 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.2 classid 1:64 tc class add dev eth1 parent 1:2 classid 1:66 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:66 handle 66 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.5 classid 1:66 tc class add dev eth1 parent 1:2 classid 1:67 htb rate 1024Kbit ceil 1024Kbit tc qdisc add dev eth1 parent 1:67 handle 67 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.3 classid 1:67 tc class add dev eth1 parent 1:2 classid 1:68 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth1 parent 1:68 handle 68 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.7 classid 1:68 tc class add dev eth1 parent 1:2 classid 1:69 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:69 handle 69 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.8 classid 1:69 tc class add dev eth1 parent 1:2 classid 1:70 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:70 handle 70 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.20 classid 1:70 tc class add dev eth1 parent 1:2 classid 1:71 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:71 handle 71 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.10 classid 1:71 tc class add dev eth1 parent 1:2 classid 1:72 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:72 handle 72 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.9 classid 1:72 tc class add dev eth1 parent 1:2 classid 1:73 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:73 handle 73 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.210 classid 1:73 tc class add dev eth1 parent 1:2 classid 1:74 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth1 parent 1:74 handle 74 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.11 classid 1:74 tc class add dev eth1 parent 1:2 classid 1:75 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:75 handle 75 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.12 classid 1:75 tc class add dev eth1 parent 1:2 classid 1:76 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:76 handle 76 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.13 classid 1:76 tc class add dev eth1 parent 1:2 classid 1:77 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:77 handle 77 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.14 classid 1:77 tc class add dev eth1 parent 1:2 classid 1:78 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:78 handle 78 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.15 classid 1:78 tc class add dev eth1 parent 1:2 classid 1:79 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:79 handle 79 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.16 classid 1:79 tc class add dev eth1 parent 1:2 classid 1:80 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:80 handle 80 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.17 classid 1:80 tc class add dev eth1 parent 1:2 classid 1:81 htb rate 256Kbit ceil 256Kbit tc qdisc add dev eth1 parent 1:81 handle 81 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.18 classid 1:81 tc class add dev eth1 parent 1:2 classid 1:82 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:82 handle 82 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.22 classid 1:82 tc class add dev eth1 parent 1:2 classid 1:83 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:83 handle 83 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.21 classid 1:83 tc class add dev eth1 parent 1:2 classid 1:84 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:84 handle 84 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.19 classid 1:84 tc class add dev eth1 parent 1:2 classid 1:85 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:85 handle 85 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.23 classid 1:85 tc class add dev eth1 parent 1:2 classid 1:86 htb rate 128Kbit ceil 128Kbit tc qdisc add dev eth1 parent 1:86 handle 86 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.24 classid 1:86 From lartc@bobich.net Fri Jan 16 11:17:46 2004 From: lartc@bobich.net (Gordan Bobic) Date: Fri, 16 Jan 2004 11:17:46 +0000 Subject: [LARTC] Shaping Device Aliases In-Reply-To: <40078365.5030500@snapgear.com> References: <200401151118.04852.gordan@bobich.net> <40078365.5030500@snapgear.com> Message-ID: <200401161117.46491.lartc@bobich.net> On Friday 16 Jan 2004 06:23, Damion de Soto wrote: > Gordan Bobic wrote: > > I understand that device aliases (e.g. eth2:3) are not shapeable. > > Does anybody know if this functionality is planned in the future? > > None of the new(er) networking tools recognise device aliases, > because on all recent linux releases, aliases don't exist. > the ethX:X notation is a legacy notation used only by the ifconfig > program. everything else just sees a ethX with more than one IP > address. > > So you just run your shaping rules on the real interfaces, and > restrict it's operation with IP address filtering. Yes, I am aware of that. However, that makes shaping multiple independent "streams" going through one interface much more difficult. The only other thing I can think of is setting up a dummy network device and giving it the IP addresses on all the non-primary subnets (e.g. multiple DSL lines), and setting up the arp and routing to make the packet actually go via the primary interface. However, therein lies another problem - it means that the primary (real) interface (with the first subnet) could then not be shaped properly (I THINK), because shaping it would shape the overall traffic on that interface, and not only the traffic on the primary connection. So, the solution might be to set up the real interface with a dummy IP address, and assigning all valid, real subnets to the dummy interfaces, and set up the routes for those subnets to go via the real interface, and set up arp to make sure things go via the real interface. Has anybody got any thoughts on this? If this would work, maybe it should be documented in the advanced routing howto, as I can see how there might be a lot of people out there who would find it useful. Regards. Gordan From stef.coene@docum.org Mon Jan 19 18:29:16 2004 From: stef.coene@docum.org (Stef Coene) Date: Mon, 19 Jan 2004 19:29:16 +0100 Subject: [LARTC] tool to monitor HTB class utilisation In-Reply-To: <00f301c3dea4$d90fccc0$c2bf09ca@huecal> References: <1074496292.400b8324cb99a@smwp01.maa.sify.net> <00f301c3dea4$d90fccc0$c2bf09ca@huecal> Message-ID: <200401191929.16445.stef.coene@docum.org> On Monday 19 January 2004 16:56, hare ram wrote: > i think you can find the very good tools in > docum.org Yep, see the monitor page: http://www.docum.org/stef.coene/qos/monitor/monitor_tc.pl Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Mon Jan 19 18:27:45 2004 From: stef.coene@docum.org (Stef Coene) Date: Mon, 19 Jan 2004 19:27:45 +0100 Subject: [LARTC] Ingress Shaping using IMQ In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE2DB8BC@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE2DB8BC@mail.sofaware.com> Message-ID: <200401191927.45852.stef.coene@docum.org> On Monday 19 January 2004 14:19, Aron Brand wrote: > Hi Guys, > > Here is a question that is probably of concern to many of us. > > I am under pressure to provide some solution for ingress traffic > shaping. What my customer demands is to divide the downstream (ingress) > of an ADSL lines to two classes of traffic - important traffic and non > important downloads. He has a very reasonable requirement: he wants a > guarantee of at least 1000kbps at all times for the important traffic on > the downstream. > > Using ingress policing would be the trivial solution. But no says the > customer - when the important traffic is not fully utilizing its rate, I > want it to share the excess with other classes. > After looking around, the answer I found was to use imq, which claims to > allow traffic shaping on ingress traffic. So far so good. > > And now I arrive to the question: It is possible to configure everything > in THEORY. The question is, it it really possible for me to give the > guarantee that my customer is asking for? I can think of examples why it > seems that the answer is no. For example, lets say the ingress line is > completely saturated with non-important traffic. How on earth can the > poor HTB determine whether important traffic is being drowned out - or > there is simply no important traffic? It can, but it will take some time before the non-important traffic will slow down. > My speculation so far - it is possible to configure these rules, and > indeed this is what IMQ was invented for, but in true life there is no > solution that works - since it is inherently impossible! It's impossible because you can never control what people send to you. Tcp will throttle down if there is less bandwidth, but this can take some time. So you can only hope the other side will stop sending packets if you drop packets (I try the same with spam but it'snot woring :( ) > Has anyone really created and tested a working ingress traffic shaping > solution? You don't need imq for this. If you put a router (or bridge) between the ADSL and the LAN, you can shape on both interfaces. So the LAN interface can be used to shape incoming traffic. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Mon Jan 19 18:22:53 2004 From: stef.coene@docum.org (Stef Coene) Date: Mon, 19 Jan 2004 19:22:53 +0100 Subject: [LARTC] Shaping inbound ok, outbound wrong In-Reply-To: <000901c3deae$e465abd0$cd302bc8@traza> References: <000901c3deae$e465abd0$cd302bc8@traza> Message-ID: <200401191922.53682.stef.coene@docum.org> On Monday 19 January 2004 18:08, Gast=F3n wrote: > Hi, I=B4m shaping traffic using htb on both interfaces, I noticed that > shaping download traffic is workinggreat but shaping upload traffic is not > working at all (no sent packets, no dropped, no overlimits) If you don't have dropped packets, you are not shaping. That means that yo= ur=20 rates are too high. You will ony be able to shape if YOU are the bottlenec= k=20 and not the router. So try to lower the rate/ceil untill you see some dropped packets. Also,=20 check out the filter rules and make sure that the traffic ends up in the=20 class you want. If you don't have any sent packets, your filters are proba= ly=20 not working. Stef =2D-=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From gdamjan@mail.net.mk Mon Jan 19 21:11:42 2004 From: gdamjan@mail.net.mk (Damjan) Date: Mon, 19 Jan 2004 22:11:42 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: <200401142300.42294.stef.coene@docum.org> References: <200401142300.42294.stef.coene@docum.org> Message-ID: <20040119211142.GA10704@legolas.on.net.mk> > It's the other way around. The class needs a token to send a packet. As long > as the class has tokens, it can send packets. If the class has used all his > tokens, it asks the parent if he has tokens left. Hmm, then you should correct this: http://www.docum.org/stef.coene/qos/tests/ """ If a child is using a token to send a packet, the same tocken is requested from the parent. So the child class is using the tokens/ctokens of it's parent. And without tokens, the parent can't give remaining bandwidth to it's child classes. """ And by the way, the next paragraph after that one is incomplete: "...there is less traffic. That bur" -- Damjan Georgievski jabberID: damjan@bagra.net.mk From lartc@leiserson.org Mon Jan 19 22:05:32 2004 From: lartc@leiserson.org (Andrew Leiserson) Date: Mon, 19 Jan 2004 17:05:32 -0500 Subject: [LARTC] problem with wrr+prio Message-ID: <20040119220532.GD15991@breakaway.mit.edu> I have set up wrr successfully on my bridge/shaper machine. That much works fine. I originally used sfq in the inner classes. However, there was a problem with high-bandwidth connections (web downloads, bittorrent) starving low-bandwidth low-latency connections like ssh. I would like to use prio or similar to prioritize the interactive traffic, but it does not seem to work. I have tested with "ping -Q 0x10" and qualitative evaluation of ssh latency. Both tests get very bad (~ 0.5-1 sec) as soon as I start a web download. I have checked with tcpdump that the TOS is set to 0x10. The machine is 2.4.23, with ebtables and wrr patches. Any ideas? Thanks. Here is my script: shape () { DEV=$1 WRR_DIRECTION=$2 # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DEV root 2> /dev/null > /dev/null # install root HTB tc qdisc add dev $DEV root handle 8000: htb default 1 tc class add dev $DEV parent 8000:0 classid 8000:1 htb \ rate ${RATE}kbit prio 2 # add wrr for correct direction, matching ip, # classes, no proxy # remap tc qdisc add dev $DEV parent 8000:1 handle 8001: \ wrr $WRR_DIRECTION ip $WRR_MAX_CLASSES 0 declare -i NUM=$WRR_MAX_CLASSES; while [ $NUM -ge 1 ]; do HNUM=$(printf %X $NUM) tc qdisc add dev $DEV parent 8001:$HNUM handle $HNUM: prio NUM=$NUM-1 done tc class add dev $DEV parent 8000:0 classid 8000:2 htb prio 1 \ rate ${RATE}kbit tc filter add dev $DEV parent 8000: protocol ip pref 10 \ u32 match ip src $LOCAL_ADDR flowid 8000:2 tc filter add dev $DEV parent 8000: protocol ip pref 10 \ u32 match ip dst $LOCAL_ADDR flowid 8000:2 tc qdisc add dev $DEV parent 8000:2 handle 8002: pfifo tc qdisc change handle 8001 dev $DEV wrr qdisc \ wmode1=3 wmode2=0 declare -i NUM=$WRR_MAX_CLASSES; while [ $NUM -ge 1 ]; do HNUM=$(printf %X $NUM) tc class change classid 8001:$HNUM dev $DEV \ wrr min1=0.5 max1=1.0 decr1=0.0000000254 \ incr1=0.00083333333 weight1=1.0 \ min2=0.1 max2=1.0 decr2=0 incr2=0 weight2=1.0 NUM=$NUM-1 done } shape $IFACE_IN dest shape $IFACE_OUT sour From gdamjan@mail.net.mk Mon Jan 19 23:03:52 2004 From: gdamjan@mail.net.mk (Damjan) Date: Tue, 20 Jan 2004 00:03:52 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: <20040119211142.GA10704@legolas.on.net.mk> References: <200401142300.42294.stef.coene@docum.org> <20040119211142.GA10704@legolas.on.net.mk> Message-ID: <20040119230352.GA15715@legolas.on.net.mk> > > It's the other way around. The class needs a token to send a packet. As long > > as the class has tokens, it can send packets. If the class has used all his > > tokens, it asks the parent if he has tokens left. > > Hmm, then you should correct this: > > http://www.docum.org/stef.coene/qos/tests/ Correction of the correction, the real URL is: http://www.docum.org/stef.coene/qos/tests/htb/burst/ PS. one more example why frames in HTML are bad. -- Damjan Georgievski jabberID: damjan@bagra.net.mk From rio@martin.mu Tue Jan 20 01:39:24 2004 From: rio@martin.mu (Rio Martin) Date: Tue, 20 Jan 2004 08:39:24 +0700 Subject: [LARTC] tool to monitor HTB class utilisation In-Reply-To: <200401191929.16445.stef.coene@docum.org> References: <1074496292.400b8324cb99a@smwp01.maa.sify.net> <00f301c3dea4$d90fccc0$c2bf09ca@huecal> <200401191929.16445.stef.coene@docum.org> Message-ID: <200401200839.24004.rio@martin.mu> On Tuesday 20 January 2004 01:29, Stef Coene wrote: > On Monday 19 January 2004 16:56, hare ram wrote: > > i think you can find the very good tools in > > docum.org > Yep, see the monitor page: > http://www.docum.org/stef.coene/qos/monitor/monitor_tc.pl > Stef This is great, Stef .. I wonder how to trap it to mrtg ? Thanks.. Regards, Rio Martin. From gaston@steel.com.ar Tue Jan 20 04:34:19 2004 From: gaston@steel.com.ar (gaston) Date: Tue, 20 Jan 2004 01:34:19 -0300 Subject: [LARTC] Shaping inbound ok, outbound wrong In-Reply-To: <200401191922.53682.stef.coene@docum.org> References: <000901c3deae$e465abd0$cd302bc8@traza> <200401191922.53682.stef.coene@docum.org> Message-ID: Yes, I think my problem is on the filters. Actually I`m quite confused. If I have eth0 facing the link and eth1 facing the LAN. I should shape download in eth1 and upload in eth0, right? So, for example I should use this filter for shapìng upload tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 200.43.134.17 classid 1:102 And this one for download tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 200.43.134.17 classid 1:80 Is this correct? Thanks a lot Stef. -----Original Message----- From: Stef Coene To: Gastón , Date: Mon, 19 Jan 2004 19:22:53 +0100 Subject: Re: [LARTC] Shaping inbound ok, outbound wrong > On Monday 19 January 2004 18:08, Gastón wrote: > > Hi, I´m shaping traffic using htb on both interfaces, I noticed that > > shaping download traffic is workinggreat but shaping upload traffic > is not > > working at all (no sent packets, no dropped, no overlimits) > If you don't have dropped packets, you are not shaping. That means > that your > rates are too high. You will ony be able to shape if YOU are the > bottleneck > and not the router. > So try to lower the rate/ceil untill you see some dropped packets. > Also, > check out the filter rules and make sure that the traffic ends up in > the > class you want. If you don't have any sent packets, your filters are > probaly > not working. > > Stef > > -- > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net From damion@snapgear.com Tue Jan 20 04:59:43 2004 From: damion@snapgear.com (Damion de Soto) Date: Tue, 20 Jan 2004 14:59:43 +1000 Subject: [LARTC] Shaping inbound ok, outbound wrong References: <000901c3deae$e465abd0$cd302bc8@traza> <200401191922.53682.stef.coene@docum.org> Message-ID: <400CB5BF.2040006@snapgear.com> > Yes, I think my problem is on the filters. Actually I`m quite confused. > If I have eth0 facing the link and eth1 facing the LAN. I should shape > download in eth1 and upload in eth0, right? Correct. > So, for example I should use this filter for shapìng upload > tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src > 200.43.134.17 classid 1:102 > > And this one for download > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 200.43.134.17 classid 1:80 What is 200.43.134.17? Is that a machine on your LAN? Is your network fully routed or are you using MASQ/NAT ? If that is a PC on your LAN, and you have a fully routed subnet, and all your qdiscs/classes are setup correctly, then yes, those filters should work. otherwise no. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 jayesh_rathod@sify.com Tue Jan 20 09:05:49 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Tue, 20 Jan 2004 15:05:49 +0600 (IST) Subject: [LARTC] example clarification needed Message-ID: <1074591348.400cf67500950@smwp01.maa.sify.net> Hi, I have a parent class 1:1 with rate=ceil=64kbit i create 3 classes under it(1:1). class 1:2 rate=ceil=32kbit class 1:3 rate=ceil=16kbit class 1:4 rate=ceil=16kbit if 64kbit traffic is flowing from the cable all the 3 classes will get their respective shape. 1 .if only 32kbit data is flowing(for some reason). a. Then how will the traffic gets distributed.? b. Is it in first come first serve bases or gets equally distributed.if distributed equally then what is the logic behind it. 2. if more than 64kbit is flowing then what happens ? Regards Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From lartc@netwrox.org Tue Jan 20 13:34:05 2004 From: lartc@netwrox.org (Andy Hawthorn) Date: Tue, 20 Jan 2004 13:34:05 -0000 Subject: [LARTC] Problem implementing split access References: <0HRS00M4C76YVZ@campus.uab.es> Message-ID: <001101c3df5a$13237f50$1101a8c0@andy17> Hi, ----- Original Message ----- From: "Felipe Herrera" <2084964@campus.uab.es> To: "Andy Hawthorn" Sent: Tuesday, January 20, 2004 9:13 AM Subject: RE: [LARTC] Problem implementing split access > Hello Andy, > > >===== Original Message From Andy Hawthorn ===== > >Hello, > > > >I am attempting to implement load balancing on a firewall to allow me to use > >two ISPs. I have followed the instructions in section 4.2 of the LARTC HOWTO > >but have got stuck on the split access section > > > >I have the options CONFIG_IP_ADVANCED_ROUTER and CONFIG_IP_MULTIPLE_TABLES > >in my kernel (2.4.24) and have added routes to the /etc/iproute2/rt_tables > >file but when I try a command in the form of: > > > > ip route add $P1_NET dev $IF1 src $IP1 table T1 > > > >such as: > > > > ip route add 192.168.10.0/24 dev eth0 src 192.168.10.250 table myisp > > > >I get the error: > > > > RTNETLINK answers: Invalid argument > > > probe with: > > ip route add 192.168.10.0/24 dev eth0 src 192.168.10.250 proto static / > > table myisp > > > Good Luck; > > > Thanks for ths tip, but this still comes up with the same "RTNETLINK answers: Invalid argument" eror that I got before. What should the proto argument actualy do? > > > >This sounds like I have missed something that I need in the kernel but > >everything that was listed in the HOWTO has been included in my kernel. If I > >try the command without the src argument such as: > > > > ip route add 192.168.10.0/24 dev eth0 table myisp > > > >.then I get no errors which would seem to sugest that the src argument is > >the problem here. > > > >Any insight someone might have would be most apreciated! > > > >Thanks, > >Andy > > > >_______________________________________________ > >LARTC mailing list / LARTC@mailman.ds9a.nl > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > Felipe Herrera Martínez > Andy From eddieknows@ananzi.co.za Tue Jan 20 13:46:41 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Tue, 20 Jan 2004 15:46:41 +0200 Subject: [LARTC] htb+beginner+error Message-ID: <1074606400.2617.9.camel@testbox.co.za> Good day all So at log last I did my script We have a 256kbite connection.This scrip runs on my gateway box(the same for script for eth1(ext) and eth0(int) I want to limit all other traffic to 10kbites but when I do it I give me this error: HTB quantum of class 10034 is to small.consider r2q <7>htb*g j=42801780 Here is my script.If you have any Idea to better it let me know.Its a bit from here and there and some of my own #!/bin/bash DEV=eth1 RATEUP=256 #To get stats if [ "$1" = "stats" ] then echo "[qdisc]" tc -s qdisc show dev $DEV echo "[class]" tc -s class show dev $DEV #echo "[filter]" #tc -s filter show dev $DEV #echo "[iptables]" exit fi #Reset tc qdisc del dev $DEV root if [ "$1" = "stop" ] then echo "Shaping removed on $DEV." exit fi ########################################################### # # Outbound Shaping (limits total bandwidth to RATEUP) # set queue size to give latency of about 2 seconds on low-prio packets ip link set dev $DEV qlen 30 # changes mtu on the outbound device. Lowering the mtu will result # in lower latency but will also cause slightly lower throughput due # to IP and TCP protocol overhead. ip link set dev $DEV mtu 1000 # add HTB root qdisc tc qdisc add dev $DEV root handle 1: htb default 23 # add main rate limit classes tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit # add leaf classes - We grant each class at LEAST it's "fair share" of bandwidth. # this way no class will ever be starved by another class. Each # class is also permitted to consume all of the available bandwidth # if no other classes are in use. tc class add dev $DEV parent 1:1 classid 1:20 htb rate ${RATEUP}kbit ceil ${RATEUP}kbit prio 0 tc class add dev $DEV parent 1:1 classid 1:21 htb rate 192kbit ceil 256kbit prio 1 tc class add dev $DEV parent 1:1 classid 1:22 htb rate 54kbit ceil 256kbit prio 2 tc class add dev $DEV parent 1:1 classid 1:23 htb rate 10kbit ceil 256kbit prio 3 # attach qdisc to leaf classes - here we at SFQ to each priority class. SFQ insures that # within each class connections will be treated (almost) fairly. tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10 tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 10 tc qdisc add dev $DEV parent 1:23 handle 23: sfq perturb 10 tc filter add dev $DEV protocol ip parent 1:0 prio 2 u32 \ match ip dport 20 0xffff flowid 1:22 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 22 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 3000 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 2 u32 \ match ip dport 25 0xffff flowid 1:22 tc filter add dev $DEV protocol ip parent 1:0 prio 2 u32 \ match ip dport 110 0xffff flowid 1:22 tc filter add dev $DEV protocol ip parent 1:0 prio 2 u32 \ match ip sport 25 0xffff flowid 1:22 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip dport 80 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip dport 443 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip dport 1443 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip sport 1443 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip dport 1494 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip sport 1494 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip dport 4400 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 \ match ip sport 4400 0xffff flowid 1:21 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15000 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15001 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15002 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15003 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15004 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15005 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15006 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15007 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15008 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15009 0xffff flowid 1:20 tc filter add dev $DEV protocol ip parent 1:0 prio 0 u32 \ match ip dport 15010 0xffff flowid 1:20 From Aron@sofaware.com Tue Jan 20 14:05:55 2004 From: Aron@sofaware.com (Aron Brand) Date: Tue, 20 Jan 2004 16:05:55 +0200 Subject: [LARTC] Ingress Shaping using IMQ Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE2DB9CF@mail.sofaware.com> Hi Stef, Thanks for the helpful information. What do I need to set as the line rate for the LAN side shaper? I assume that if I want it to work it must be slower than the real downlink speed - is this right? Are there recommended values - such as 10% lower than the real downlink speed? I am wondering, has anyone done any benchmarks that indicate how accurate is shaping of TCP streams in the inbound direction? For example, say that during peak periods the customer wants to enforce 20% of the traffic to web and 80% to FTP downloads, how long will it take until it stabilizes on these rates? And how accurate can I expect it to be? Thanks, Aron -----Original Message----- From: Stef Coene [mailto:stef.coene@docum.org]=20 Sent: Monday, January 19, 2004 8:28 PM To: Aron Brand; lartc@mailman.ds9a.nl Subject: Re: [LARTC] Ingress Shaping using IMQ On Monday 19 January 2004 14:19, Aron Brand wrote: > Hi Guys, > > Here is a question that is probably of concern to many of us. > > I am under pressure to provide some solution for ingress traffic=20 > shaping. What my customer demands is to divide the downstream=20 > (ingress) of an ADSL lines to two classes of traffic - important=20 > traffic and non important downloads. He has a very reasonable=20 > requirement: he wants a guarantee of at least 1000kbps at all times=20 > for the important traffic on the downstream. > > Using ingress policing would be the trivial solution. But no says the=20 > customer - when the important traffic is not fully utilizing its rate, > I want it to share the excess with other classes. > After looking around, the answer I found was to use imq, which claims=20 > to allow traffic shaping on ingress traffic. So far so good. > > And now I arrive to the question: It is possible to configure=20 > everything in THEORY. The question is, it it really possible for me to > give the guarantee that my customer is asking for? I can think of=20 > examples why it seems that the answer is no. For example, lets say the > ingress line is completely saturated with non-important traffic. How=20 > on earth can the poor HTB determine whether important traffic is being > drowned out - or there is simply no important traffic? It can, but it will take some time before the non-important traffic will slow down. > My speculation so far - it is possible to configure these rules, and=20 > indeed this is what IMQ was invented for, but in true life there is no > solution that works - since it is inherently impossible! It's impossible because you can never control what people send to you. Tcp will throttle down if there is less bandwidth, but this can take some time. =20 So you can only hope the other side will stop sending packets if you drop packets (I try the same with spam but it'snot woring :( ) > Has anyone really created and tested a working ingress traffic shaping > solution? You don't need imq for this. If you put a router (or bridge) between the ADSL and the LAN, you can shape on both interfaces. So the LAN interface can be used to shape incoming traffic. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From luciano@elo.com.br Tue Jan 20 15:11:24 2004 From: luciano@elo.com.br (Luciano Lima) Date: Tue, 20 Jan 2004 13:11:24 -0200 Subject: [LARTC] Quantum of class nnnnn is big Message-ID: <400D451C.4060708@elo.com.br> My gateway is showing these messages: htb*g j=4929 htb*r7 m=0 htb*r6 m=0 htb*r5 m=0 htb*r4 m=0 htb*r3 m=0 htb*r2 m=0 htb*r1 m=0 htb*r0 m=0 HTB: quantum of class 10001 is big. Consider r2q change. What does it means ? Thanks, Luciano Lima From stef.coene@docum.org Tue Jan 20 17:45:51 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 20 Jan 2004 18:45:51 +0100 Subject: [LARTC] Ingress Shaping using IMQ In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE2DB9CF@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE2DB9CF@mail.sofaware.com> Message-ID: <200401201845.51967.stef.coene@docum.org> On Tuesday 20 January 2004 15:05, Aron Brand wrote: > Hi Stef, > > Thanks for the helpful information. > > What do I need to set as the line rate for the LAN side shaper? I assume > that if I want it to work it must be slower than the real downlink speed > - is this right? Are there recommended values - such as 10% lower than > the real downlink speed? It depends. But try 10% and measure the link usage. > I am wondering, has anyone done any benchmarks that indicate how > accurate is shaping of TCP streams in the inbound direction? For > example, say that during peak periods the customer wants to enforce 20% > of the traffic to web and 80% to FTP downloads, how long will it take > until it stabilizes on these rates? And how accurate can I expect it to > be? It can be very accurate and very fast. Like said before, it depends on the software you use and how quick to software reacts on a change in the bandwidth. I did some bursts test with htb. You can see on some of the graphs that if there is an other tcp stream, htb reacts very fast. But this only for outoing packets and measered on the loopback interface. So the problem is not htb, but application, routers, modems, ... http://docum.org/stef.coene/qos/tests/htb/burst/ Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Tue Jan 20 17:47:45 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 20 Jan 2004 18:47:45 +0100 Subject: [LARTC] example clarification needed In-Reply-To: <1074591348.400cf67500950@smwp01.maa.sify.net> References: <1074591348.400cf67500950@smwp01.maa.sify.net> Message-ID: <200401201847.45199.stef.coene@docum.org> On Tuesday 20 January 2004 10:05, jayesh rathod wrote: > Hi, > > I have a parent class 1:1 with rate=ceil=64kbit > i create 3 classes under it(1:1). > class 1:2 rate=ceil=32kbit > class 1:3 rate=ceil=16kbit > class 1:4 rate=ceil=16kbit > > if 64kbit traffic is flowing from the cable all the 3 classes will get > their respective shape. > > 1 .if only 32kbit data is flowing(for some reason). > a. Then how will the traffic gets distributed.? > b. Is it in first come first serve bases or gets equally distributed.if > distributed equally then what is the logic behind it. > > 2. if more than 64kbit is flowing then what happens ? I'm not going to answer your questions, but I point you to the faq page on docum.org for answers. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Tue Jan 20 17:43:00 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 20 Jan 2004 18:43:00 +0100 Subject: [LARTC] Quantum of class nnnnn is big In-Reply-To: <400D451C.4060708@elo.com.br> References: <400D451C.4060708@elo.com.br> Message-ID: <200401201843.00020.stef.coene@docum.org> On Tuesday 20 January 2004 16:11, Luciano Lima wrote: > My gateway is showing these messages: > > htb*g j=4929 > htb*r7 m=0 > htb*r6 m=0 > htb*r5 m=0 > htb*r4 m=0 > htb*r3 m=0 > htb*r2 m=0 > htb*r1 m=0 > htb*r0 m=0 > HTB: quantum of class 10001 is big. Consider r2q change. > > What does it means ? Lower the quantum:) You can ignore these messages or change the quantum of your classes or r2q of your htb qdisc. For an explanation, see http://docum.org/stef.coene/qos/faq/cache/31.html Make sure 1500 < quantum < 60000 quantum = rate / r2q Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Tue Jan 20 17:50:43 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 20 Jan 2004 18:50:43 +0100 Subject: [LARTC] tool to monitor HTB class utilisation In-Reply-To: <200401200839.24004.rio@martin.mu> References: <1074496292.400b8324cb99a@smwp01.maa.sify.net> <200401191929.16445.stef.coene@docum.org> <200401200839.24004.rio@martin.mu> Message-ID: <200401201850.43949.stef.coene@docum.org> On Tuesday 20 January 2004 02:39, Rio Martin wrote: > On Tuesday 20 January 2004 01:29, Stef Coene wrote: > > On Monday 19 January 2004 16:56, hare ram wrote: > > > i think you can find the very good tools in > > > docum.org > > > > Yep, see the monitor page: > > http://www.docum.org/stef.coene/qos/monitor/monitor_tc.pl > > Stef > > This is great, Stef .. > I wonder how to trap it to mrtg ? You can. There is a snmp patch available so you can query the tc counters with snmp. I wrote some software for it to query the counters and I use rrd for the graphs: http://docum.org/stef.coene/qos/tc-snmp/index.html (the example page is broken) Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From pturley@rocksteady.com Tue Jan 20 19:14:26 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Tue, 20 Jan 2004 13:14:26 -0600 Subject: [LARTC] Quantum of class nnnnn is big In-Reply-To: <400D451C.4060708@elo.com.br> References: <400D451C.4060708@elo.com.br> Message-ID: <400D7E12.9030309@rocksteady.com> I ran into this problem as well. Here's something quoted from our bug database that came from the research I did: --- This message comes from the root qdisc when we attach a class to it. It examines the data rate of the subordinate class and computes the "quantum" for that class. A "quantum" is the unit of sharing for bandwidth allocation. It is the number of bytes the the root qdisc will collect at one time from a given class before moving on to the next one. It's important that the quantum be at least 1500, since that's the maximum size of an Ethernet packet. The root qdisc computes the quantum size for a class by dividing its data rate, expressed in bits per second, by a configurable constant called "r2q" (short for rate to quantum). The default value for this constant is 10, but you can set it to anything you want. --- So, it looks like the quantum being computed for you is very large, and the message is suggesting that you reduce the value of r2q so the quantum isn't so big. According to Stef's FAQ at http://qos.dyndns.org:3389/cgi-bin/fom?_highlightWords=r2q&file=31, the buit-in limit for the quantum is 60000 bytes. Luciano Lima wrote: > My gateway is showing these messages: > > htb*g j=4929 > htb*r7 m=0 > htb*r6 m=0 > htb*r5 m=0 > htb*r4 m=0 > htb*r3 m=0 > htb*r2 m=0 > htb*r1 m=0 > htb*r0 m=0 > HTB: quantum of class 10001 is big. Consider r2q change. > > What does it means ? > > Thanks, > > Luciano Lima > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From simon@igrin.co.nz Tue Jan 20 20:11:34 2004 From: simon@igrin.co.nz (Simon Byrnand) Date: Wed, 21 Jan 2004 09:11:34 +1300 (NZDT) Subject: [LARTC] Fair bandwidth oversubscribing ? How with HTB ? Message-ID: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> Hopefully someone has a suggestion on how I might do this...as I can't figure it out :( I need to be able to set up a group of seperate users who have a "bandwidth pool" they share, but also be able to limit their individual bandwidth as well. Example: I have 5 customers and would like to be able to provide them with a maximum of 256Kbit each, with a CIR of 33%. To do this, I'd like the 5 customers to share a parent group which is therefore limited to 426Kbit, Which is 5*256Kbit/3. The idea being that individual customers can achieve up to a maximum of 256Kbit provided that the total group pool doesn't exceed 426Kbit, and if the total group pool maxes out, then each customer should get reduced bandwidth in fair ratios based on their individual maximum setting. (Currently 256Kbit for all of them, but I'd like to be able to differentiate them later) If all 5 were trying to fully utilize their bandwidth at the same time, they should get a fairly distributed 33% of their maximum - eg about 85Kbit. The problem I can see is that both CBQ and HTB don't seem to honour situations where the sum of all the child rates exceeds the parent rate - the parent rate is ignored so the 426Kbit cap is exceeded. The HTB docs even explicitely say this won't work. So is there any tricky way to do this with slightly different semantics ? Surely there must be some way :-) I've spent many long hours studying CBQ and trying things out and finally came to the conclusion that CBQ alone just can't do it, but I was hoping HTB could, but thus far I've been unsuccessful here too.. Currently I'm using CBQ but I'm limited in that the individual maximum speeds can only equal the parent group maximum bandwidth which is workable for a few customers, but not very satisfactory and not flexible enough as I add more customers. If someone could point me in the right direction or just give me a firm "nope, can't be done" that would be great.... I'd also like to enable short term bursting over and above this as well, to improve responsiveness during downloading, say, 33% overbandwidth for 5 seconds, that sort of thing, but I'll cross that bridge when (if) I get to it...(any comments here on how effective enabling bursting is for reducing the dreaded unresponsiveness-during-downloads problem would be welcome too) Regards, Simon From santiago@avatar.com.co Tue Jan 20 21:22:06 2004 From: santiago@avatar.com.co (Santiago J. R=?ISO-8859-1?B?dWFubyBSaW5j824=?=) Date: Tue, 20 Jan 2004 16:22:06 -0500 Subject: [LARTC] Fair bandwidth oversubscribing ? How with HTB ? In-Reply-To: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> References: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> Message-ID: <1074633726.400d9bfec0223@webmail.avatar.com.co> try HFSC, Hierarchical Fair Service Curve: http://trash.net/~kaber/hfsc http://www-2.cs.cmu.edu/~hzhang/HFSC/ i'm going to test it in this week. Quoting Simon Byrnand : > Hopefully someone has a suggestion on how I might do this...as I can't > figure it out :( > > I need to be able to set up a group of seperate users who have a > "bandwidth pool" they share, but also be able to limit their individual > bandwidth as well. > > Example: > > I have 5 customers and would like to be able to provide them with a > maximum of 256Kbit each, with a CIR of 33%. > > To do this, I'd like the 5 customers to share a parent group which is > therefore limited to 426Kbit, Which is 5*256Kbit/3. > > The idea being that individual customers can achieve up to a maximum of > 256Kbit provided that the total group pool doesn't exceed 426Kbit, and if > the total group pool maxes out, then each customer should get reduced > bandwidth in fair ratios based on their individual maximum setting. > (Currently 256Kbit for all of them, but I'd like to be able to > differentiate them later) > > If all 5 were trying to fully utilize their bandwidth at the same time, > they should get a fairly distributed 33% of their maximum - eg about > 85Kbit. > > The problem I can see is that both CBQ and HTB don't seem to honour > situations where the sum of all the child rates exceeds the parent rate - > the parent rate is ignored so the 426Kbit cap is exceeded. The HTB docs > even explicitely say this won't work. > > So is there any tricky way to do this with slightly different semantics ? > Surely there must be some way :-) I've spent many long hours studying CBQ > and trying things out and finally came to the conclusion that CBQ alone > just can't do it, but I was hoping HTB could, but thus far I've been > unsuccessful here too.. > > Currently I'm using CBQ but I'm limited in that the individual maximum > speeds can only equal the parent group maximum bandwidth which is workable > for a few customers, but not very satisfactory and not flexible enough as > I add more customers. > > If someone could point me in the right direction or just give me a firm > "nope, can't be done" that would be great.... > > I'd also like to enable short term bursting over and above this as well, > to improve responsiveness during downloading, say, 33% overbandwidth for 5 > seconds, that sort of thing, but I'll cross that bridge when (if) I get to > it...(any comments here on how effective enabling bursting is for reducing > the dreaded unresponsiveness-during-downloads problem would be welcome > too) > > Regards, > Simon > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > Santiago J. Ruano Rincón Avatar Ltda. ParqueSoft Popayán +57-2 8221214 From kaber@trash.net Wed Jan 21 00:13:04 2004 From: kaber@trash.net (Patrick McHardy) Date: Wed, 21 Jan 2004 01:13:04 +0100 Subject: [LARTC] Fair bandwidth oversubscribing ? How with HTB ? In-Reply-To: <1074633726.400d9bfec0223@webmail.avatar.com.co> References: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> <1074633726.400d9bfec0223@webmail.avatar.com.co> Message-ID: <400DC410.1060201@trash.net> Santiago J. Ruano Rincón wrote: >try HFSC, Hierarchical Fair Service Curve: > >http://trash.net/~kaber/hfsc >http://www-2.cs.cmu.edu/~hzhang/HFSC/ > >i'm going to test it in this week. > > This should indeed work with HFSC if the custumer-classes have only links-haring service curves and no realtime service curves. The parent class would be limited with an upper-limit service curve. With link-sharing service curves, only the relative differences of virtual time on a level of the heirarchy are relevant, so there is no problem oversubscribing the parent class. the upper-limit service curve of the parent limits the total bandwidth, unlike the link-sharing curve it uses wall-clock time. Best regards, Patrick PS: Please let me know if you are successful. >Quoting Simon Byrnand : > > > >>Hopefully someone has a suggestion on how I might do this...as I can't >>figure it out :( >> >>I need to be able to set up a group of seperate users who have a >>"bandwidth pool" they share, but also be able to limit their individual >>bandwidth as well. >> >>Example: >> >>I have 5 customers and would like to be able to provide them with a >>maximum of 256Kbit each, with a CIR of 33%. >> >>To do this, I'd like the 5 customers to share a parent group which is >>therefore limited to 426Kbit, Which is 5*256Kbit/3. >> >>The idea being that individual customers can achieve up to a maximum of >>256Kbit provided that the total group pool doesn't exceed 426Kbit, and if >>the total group pool maxes out, then each customer should get reduced >>bandwidth in fair ratios based on their individual maximum setting. >>(Currently 256Kbit for all of them, but I'd like to be able to >>differentiate them later) >> >>If all 5 were trying to fully utilize their bandwidth at the same time, >>they should get a fairly distributed 33% of their maximum - eg about >>85Kbit. >> >>The problem I can see is that both CBQ and HTB don't seem to honour >>situations where the sum of all the child rates exceeds the parent rate - >>the parent rate is ignored so the 426Kbit cap is exceeded. The HTB docs >>even explicitely say this won't work. >> >>So is there any tricky way to do this with slightly different semantics ? >>Surely there must be some way :-) I've spent many long hours studying CBQ >>and trying things out and finally came to the conclusion that CBQ alone >>just can't do it, but I was hoping HTB could, but thus far I've been >>unsuccessful here too.. >> >>Currently I'm using CBQ but I'm limited in that the individual maximum >>speeds can only equal the parent group maximum bandwidth which is workable >>for a few customers, but not very satisfactory and not flexible enough as >>I add more customers. >> >>If someone could point me in the right direction or just give me a firm >>"nope, can't be done" that would be great.... >> >>I'd also like to enable short term bursting over and above this as well, >>to improve responsiveness during downloading, say, 33% overbandwidth for 5 >>seconds, that sort of thing, but I'll cross that bridge when (if) I get to >>it...(any comments here on how effective enabling bursting is for reducing >>the dreaded unresponsiveness-during-downloads problem would be welcome >>too) >> >>Regards, >>Simon >> >>_______________________________________________ >>LARTC mailing list / LARTC@mailman.ds9a.nl >>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> >> >> > > >Santiago J. Ruano Rincón > >Avatar Ltda. >ParqueSoft Popayán >+57-2 8221214 > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From arek@chelmnet.pl Wed Jan 21 01:11:34 2004 From: arek@chelmnet.pl (arek@chelmnet.pl) Date: Wed, 21 Jan 2004 02:11:34 +0100 Subject: [LARTC] failover does not work for static ip rules In-Reply-To: <019e01c3dede$8256d2e0$3301a8c0@elitecore1> Message-ID: > hello all, > previously i had some problems setting up a load balancing network, > but now after re-applying the julian patch, it works good, > but my doubt is that if we have statically provided and IP Rule for some > network to use some particular gateway like follows, > > ip rule add prio 203 from 192.168.1.0/24 table 203 > ip route add default via 203.88.135.213 dev eth1 src 203.88.135.212 proto > static table 203 > ip route append prohibit default table 203 metric 1 proto static > > but now, if the gateway goes down, then will it refer to the > next priority > table , i.e. 221? > the next priority table is as follows, > > ip rule add prio 221 table 221 > > ip route add default table 221 proto static \ > nexthop via 203.88.135.213 dev eth1 weight 1\ > nexthop via 203.88.135.193 dev eth2 weight 1 > > so, if the static route fails, will that refer the next priotiry table? > failover works if i have not specified the static ip rule, > but it does not work in case of this rule 203, > can anyone explain why this happens? > thanks and regards Yes, i think that all is working fine, take a look, you have only rule from 192.168.1.0/24 to table 203 in normal operational status. So propably, when you are tracerouting , etc, system bind uses different source ip, so you don't see the same thing as being done by kernel for packet with sources 192.168.1.0/24. Add the same rule as "ip rule add prio 221 table 221" to put everything to table 203, then everything to table 221. Try it, and hope to hear you soon. Arkadiusz Binder From rama_tulasi_99@yahoo.com Wed Jan 21 05:56:14 2004 From: rama_tulasi_99@yahoo.com (tulasi) Date: Tue, 20 Jan 2004 21:56:14 -0800 (PST) Subject: [LARTC] rshaper Config Message-ID: <20040121055614.99289.qmail@web40405.mail.yahoo.com> Hi Every One, I am using Linux 2.4 with 8390 Network driver. For configuring rshaper in one of the manual i have studied that need to insert the following line in Global space of Kernel. int (*net_shaper_rx_hook)(struct sk_buff *skb) = NULL; Can you suggest me anyone steps to insert the line and where in my Linux System. I am very new to kernel part. I am very greatful to you if any one help me in this regard. Thanks in Advance Tulasi __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From siddharth@unipune.ernet.in Wed Jan 21 06:53:00 2004 From: siddharth@unipune.ernet.in (Siddharth Kulkarni (M.T.S.@C.N.C.)) Date: Wed, 21 Jan 2004 12:23:00 +0530 (IST) Subject: [LARTC] traffic shaping and kernel 2.6.0 Message-ID: <49947.196.1.114.240.1074667980.squirrel@unipune.ernet.in> hello all, I am newbie to this list, Is anybody has did some experimentation about traffic control with kernel 2.6.0 as there is one special module called traffic shapper in experimental category. Has anybody tried it? Are there any other special tools for the same? Is there any documentation regarding the same? I myself is going to try it with kernel 2.6.0 so welcome to advices. Thanks in advance. -SIDDHARTH From mrenzmann@otaku42.de Wed Jan 21 08:19:29 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Wed, 21 Jan 2004 09:19:29 +0100 Subject: [LARTC] Slightly offtopic: IRC channel archives Message-ID: <400E3611.4080000@otaku42.de> Hi all. I fear I'm slightly offtopic with this question, but I'll keep it short: who is (or feels) responsible for the #lartc irc-channel in oftc.net? I'd appreciate if that person would get in contact with me (off-list) in order to discuss some ideas I have. Thanks in advance. Bye, Mike From jvr_78@yahoo.com.ar Wed Jan 21 13:28:12 2004 From: jvr_78@yahoo.com.ar (Javier Ramirez) Date: Wed, 21 Jan 2004 10:28:12 -0300 Subject: [LARTC] Slightly offtopic: IRC channel archives In-Reply-To: <400E3611.4080000@otaku42.de> References: <400E3611.4080000@otaku42.de> Message-ID: <1074691691.2072.9.camel@Morocha.bit2NET.com> --=-zmS6jGivvxQCBObvmJI2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I have a litle problem with this code I have two virtual ips (50 y 51) and this ips are the gateway ip address add 192.168.0.50 dev eth1 ip address add 192.168.0.51 dev eth1 tc qdisc add dev eth1 root handle 1: cbq bandwidth 512kbit cell 8 avpkt 1000 \ mpu 64 tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 512kbit rate \ 100kBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21 tc class add dev eth1 parent 1:0 classid 1:2 cbq bandwidth 512kbit rate \ 100kbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21 tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1 tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.0.50 flowid 1:1 tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.0.51 flowid 1:2 and this scrip say: RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument RTNETLINK answers: Invalid argument Anybody can help me? Regards Javier --=-zmS6jGivvxQCBObvmJI2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I have a litle problem with this code

I have two virtual ips (50 y 51) and this ips are the gateway

ip address add 192.168.0.50 dev eth1
ip address add 192.168.0.51 dev eth1
tc qdisc add dev eth1 root handle 1: cbq bandwidth 512kbit cell 8 avpkt 1000 \
mpu 64
tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 512kbit rate \
100kBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21
tc class add dev eth1 parent 1:0 classid 1:2 cbq bandwidth 512kbit rate \
100kbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21
tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1
tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.0.50 flowid 1:1
tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.0.51 flowid 1:2

and this scrip say:


RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument
RTNETLINK answers: Invalid argument

Anybody can help me?
Regards
Javier
--=-zmS6jGivvxQCBObvmJI2-- From geoff@cmcnetworks.net Wed Jan 21 14:31:38 2004 From: geoff@cmcnetworks.net (Geoff Dornan) Date: Wed, 21 Jan 2004 16:31:38 +0200 Subject: [LARTC] IS there any way to see what IP's or traffic is flowing in the default class Message-ID: <085685C10448FA4E853E4C5FCD2CB31F396EAC@OBELIX.cmcnetworks.net> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E02B.475FB9F3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsDQogDQpJIGhhdmUgYW4gb2RkIHJlcXVlc3QgYnV0IHdlIGFyZSBtYW5hZ2luZyBhbG90 IG9mIEhUQiBxdWV1ZXMgYW5kIHdlIHNlZW0gdG8gc3RpbGwgYmUgZ2V0dGluZyB0cmFmZmljIGlu IHRoZSBkZWZhdWx0IGNsYXNzLCBlYWNoIGNsaWVudCBpcyBhbGxvY2F0ZWQgYW4gSVAgYWRkcmVz cyBvciBibG9jayBhbmQgaGFzIHN1Y2ggbm8gdHJhZmZpYyB1bmRlciBub3JtYWwgY2lyY3Vtc3Rh bmNlcyBzaG91bGQgYmUgZGVmYXVsdCB0cmFmZmljLCBhcyBldmVyeSBJUCBzaG91bGQgYmUgaW4g YSBjbGFzcywgaXMgdGhlcmUgYW55IHdheSB0byBzZWUgd2hhdCBJUCdzLCBzb3VyY2UgYW5kIGRl c3RpbmF0aW9uLCBhcmUgYmVlbiBmb3JjZWQgaW4gdGhlIGRlZmF1bHQgY2xhc3M/IHNvIHRoYXQg d2UgY2FuIG1vdmUgdGhlbSBpbnRvIHRoZSByZWxhdmVudCBjbGllbnQgY2xhc3MuDQogDQpLaW5k IFJlZ2FyZHMNCiANCkdlb2ZmDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXkNCmFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeQ0KdGhlIHN5c3RlbSBtYW5hZ2VyLg0KDQpUaGlz IG1haWwgZG9lcyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBvZiBDTUMgTmV0 d29ya3MNCmFuZCBzaG91bGQgYmUgdHJlYXRlZCBhY2NvcmRpbmdseS4NCg0KVGhpcyBmb290bm90 ZSBhbHNvIGNvbmZpcm1zIHRoYXQgdGhpcyBlbWFpbCBtZXNzYWdlIGhhcyBiZWVuIA0KY2hlY2tl ZCBieSBDTUMgTmV0d29ya3MgZm9yIHRoZSBwcmVzZW5jZSBvZiBjb21wdXRlciB2aXJ1c2VzLg0K DQpDTUMgTmV0d29ya3MgU2VjdXJpdHkgU2VydmljZXMNCioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KDQo= ------_=_NextPart_001_01C3E02B.475FB9F3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI4MDAuMTE3MCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxT UEFOIGNsYXNzPTU1MDEyMjgxNC0yMTAxMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPkhpIA0KYWxsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9 NTUwMTIyODE0LTIxMDEyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz01NTAxMjI4MTQt MjEwMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JIGhhdmUgDQph biBvZGQgcmVxdWVzdCBidXQgd2UgYXJlIG1hbmFnaW5nIGFsb3Qgb2YgSFRCIHF1ZXVlcyBhbmQg d2Ugc2VlbSB0byBzdGlsbCBiZSANCmdldHRpbmcgdHJhZmZpYyBpbiB0aGUgZGVmYXVsdCBjbGFz cywgZWFjaCBjbGllbnQgaXMgYWxsb2NhdGVkIGFuIElQIGFkZHJlc3Mgb3IgDQpibG9jayBhbmQg aGFzIHN1Y2ggbm8gdHJhZmZpYyB1bmRlciBub3JtYWwgY2lyY3Vtc3RhbmNlcyBzaG91bGQgYmUg ZGVmYXVsdCANCnRyYWZmaWMsIGFzIGV2ZXJ5IElQIHNob3VsZCBiZSBpbiBhIGNsYXNzLCBpcyB0 aGVyZSBhbnkgd2F5IHRvIHNlZSB3aGF0IElQJ3MsIA0Kc291cmNlIGFuZCBkZXN0aW5hdGlvbiwg YXJlIGJlZW4gZm9yY2VkIGluIHRoZSBkZWZhdWx0IGNsYXNzPyBzbyB0aGF0IHdlIGNhbiANCm1v dmUgdGhlbSBpbnRvIHRoZSByZWxhdmVudCBjbGllbnQgY2xhc3MuPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9NTUwMTIyODE0LTIxMDEyMDA0PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48 U1BBTiBjbGFzcz01NTAxMjI4MTQtMjEwMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj5LaW5kIA0KUmVnYXJkczwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTU1MDEyMjgxNC0yMTAxMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg DQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTUw MTIyODE0LTIxMDEyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5H ZW9mZjwvRk9OVD48L1NQQU4+PC9ESVY+PENPREU+PEZPTlQgU0laRT0zPjxCUj4NCjxCUj4NCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKjxCUj4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kPEJSPg0KaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXk8QlI+ DQphcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnk8QlI+DQp0aGUgc3lzdGVtIG1hbmFnZXIuPEJSPg0KPEJSPg0KVGhpcyBt YWlsIGRvZXMgbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3Mgb2YgQ01DIE5ldHdv cmtzPEJSPg0KYW5kIHNob3VsZCBiZSB0cmVhdGVkIGFjY29yZGluZ2x5LjxCUj4NCjxCUj4NClRo aXMgZm9vdG5vdGUgYWxzbyBjb25maXJtcyB0aGF0IHRoaXMgZW1haWwgbWVzc2FnZSBoYXMgYmVl biA8QlI+DQpjaGVja2VkIGJ5IENNQyBOZXR3b3JrcyBmb3IgdGhlIHByZXNlbmNlIG9mIGNvbXB1 dGVyIHZpcnVzZXMuPEJSPg0KPEJSPg0KQ01DIE5ldHdvcmtzIFNlY3VyaXR5IFNlcnZpY2VzPEJS Pg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPg0KPC9GT05UPjwvQ09ERT4NCjwvQk9EWT48 L0hUTUw+DQo= ------_=_NextPart_001_01C3E02B.475FB9F3-- From serge.maandag@staff.zeelandnet.nl Wed Jan 21 14:48:05 2004 From: serge.maandag@staff.zeelandnet.nl (Serge Maandag) Date: Wed, 21 Jan 2004 15:48:05 +0100 Subject: [LARTC] a couple of questions regarding htb Message-ID: <91FC132ACA694F45A6E42CE8E593838C39C328@zmx.staff.zeelandnet.nl> > Only outgoing traffic can be classfully shaped or limited. > > Is that correct or will limiting of incoming traffic work=20 > but isn't it just as reliable? >=20 > It's just not very flexible. In what manner? As in no borrowing / lending or as in hard to configure or as in ... ? > > Therefore the clientwill be able to sent out > > more traffic than allowed, if it is spread over multiple outgoing > > interfaces. >=20 > What is your concern, inter-customer traffic ? Or even the Internet > traffic can go thru more than one interface ? No, there is one uplink to the internet. The other links go to networks with other customers. But there's quite some inter-customer traffic. > > Is there a solution to this? >=20 > Yes, IMQ. You can do ingress shaping with it, or you can bundle output > traffic from various interfaces and shape at a single point. I will check it out then. Is that bundling as in bundling on a loopback=20 interface? I remember that's how Cisco likes to do things. Thanks for the answers! Serge. ------------- Op de inhoud van dit e-mailbericht en de daaraan gehechte bijlagen is de = inhoud van de volgende disclaimer van toepassing: = http://www.zeelandnet.nl/disclaimer.php From mrenzmann@otaku42.de Wed Jan 21 15:26:51 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Wed, 21 Jan 2004 16:26:51 +0100 Subject: [LARTC] a couple of questions regarding htb In-Reply-To: <91FC132ACA694F45A6E42CE8E593838C39C328@zmx.staff.zeelandnet.nl> References: <91FC132ACA694F45A6E42CE8E593838C39C328@zmx.staff.zeelandnet.nl> Message-ID: <400E9A3B.8090907@otaku42.de> Hi. Serge Maandag wrote: >>Yes, IMQ. You can do ingress shaping with it, or you can bundle output >>traffic from various interfaces and shape at a single point. > I will check it out then. Is that bundling as in bundling on a loopback > interface? I remember that's how Cisco likes to do things. That's what the IMQ Faq answers to your questions: === cut === 1. What can i do with imq ? The imq device has two common usage cases: * Ingress shaping: With linux only egress shaping is possible (except for the ingress queue which can only do ratelimiting). IMQ enables you to use egress qdiscs for real ingress shaping. * Shaping over multiple interfaces: Qdiscs get attached to devices. A consequence of this is that one qdisc can only handle traffic going to the interface it is attached to. Sometimes it is desireable to have global limits on multiple interfaces. With imq you can use iptables to specify which packets the qdiscs sees, so global limits can be placed. === cut === Source: http://trash.net/~kaber/imq/faq.html Hth. Bye, Mike From serge.maandag@staff.zeelandnet.nl Wed Jan 21 15:32:22 2004 From: serge.maandag@staff.zeelandnet.nl (Serge Maandag) Date: Wed, 21 Jan 2004 16:32:22 +0100 Subject: [LARTC] a couple of questions regarding htb Message-ID: <91FC132ACA694F45A6E42CE8E593838C39C32D@zmx.staff.zeelandnet.nl> Haha, I see that even was the top question in the Faq, sorry.. Thanks for the help. Serge. > > >=20 > That's what the IMQ Faq answers to your questions: >=20 > =3D=3D=3D cut =3D=3D=3D > 1. What can i do with imq ? >=20 > * Ingress shaping: > * Shaping over multiple interfaces: > Hth. >=20 > Bye, Mike >=20 >=20 ------------- Op de inhoud van dit e-mailbericht en de daaraan gehechte bijlagen is de = inhoud van de volgende disclaimer van toepassing: = http://www.zeelandnet.nl/disclaimer.php From rubens@etica.net Wed Jan 21 16:18:00 2004 From: rubens@etica.net (rubens@etica.net) Date: Wed, 21 Jan 2004 14:18:00 -0200 (BRST) Subject: [LARTC] Quantum of class nnnnn is big In-Reply-To: <200401201843.00020.stef.coene@docum.org> Message-ID: > Make sure 1500 < quantum < 60000 > quantum = rate / r2q Stef, Would it be 1500 < quantum, or 1500 <= quantum ? Rubens From vishal@southernonline.net Thu Jan 22 07:55:19 2004 From: vishal@southernonline.net (Vishal Gandhi Kommineni) Date: Wed, 21 Jan 2004 23:55:19 -0800 Subject: [LARTC] iproute2 source routing problem Message-ID: <002401c3e0bd$14866a60$0b6f3fca@southernonline.net> This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C3E07A.064198A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am using a redhat 8.x linux box configured with zebra routing software = which is also configured with ospfd I have 2 backbone routers running ospf connected to different isp's I have 3 local routers also running ospf within themselfs and also with = the 2 backbone routers (all are linux boxes) router A - backbone router 1 router B - backbone router 2 router C - local router 1 (has 3 subnets routed via it) router D - local router 2 (has 2 subnets routed via it) router E - local router 3 (has 5 subnets routed via it) my pc connected to local router D whose default gw is router A In our local router we are trying to have policy routing without any policy routing when I try to trace ip in the subnet behind = router C the next hop is learnt by the ospf routing entry in the main = table and the packet is landing in router C while when I try to trace = yahoo.com the packet is landing into router A and reaching yahoo.com but when I am trying to deploy policy route-map in which if I say = packets originating from X network's default gw is router B I find that = the packets are always landing on the router B even if the destination = is know network via ospf. I deployed policy routing as below in my linux box (router D) echo "200 GWA" > > /etc/iproute2/rt_tables /sbin/ip rule add from x.x.x.x/28 table GWA /sbin/ip route add default via y.y.y.1 table GWA when I try to see the main table by giving the command below ip route list table main I find all the ospf routes in that table ended with the default gw entry when I see the table GWA I find only the default next hop entry ie., = router B (y.y.y.1) is there any way of dynamically updating even in GWA table with the ospf = entries followed by default next hop y.y.y.1 Kindly help me in this regard Visha ------=_NextPart_000_0021_01C3E07A.064198A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I am using a redhat 8.x linux box = configured with=20 zebra routing software which is also configured with ospfd
I have 2 backbone routers running=20 ospf connected to different isp's
I have 3 local routers also running = ospf within=20 themselfs and also with the 2 backbone routers  (all are linux=20 boxes)
 
router A -  backbone router = 1
router B -  backbone router = 2
 
router C - local router 1 (has 3 = subnets routed via=20 it)
router D - local router 2 (has 2 = subnets routed via=20 it)
router E - local router 3 (has 5 = subnets routed via=20 it)
 
my pc connected to local = router D whose=20 default gw is router A
In our local router we are trying to = have policy=20 routing
 
 
without any policy routing when I try = to trace ip=20 in the subnet behind router C the next hop is learnt by the ospf routing = entry=20 in the main table and the packet is landing in router C while when I try = to=20 trace yahoo.com the packet is landing into router A and reaching=20 yahoo.com
 
but when I am trying to deploy policy = route-map in=20 which if I say packets originating from X network's default gw is router = B I=20 find that the packets are always landing on the router B even if the = destination=20 is know network via ospf.
 
I deployed policy routing as below in = my linux box=20 (router D)
 
echo "200 GWA" > >=20 /etc/iproute2/rt_tables
/sbin/ip rule add from x.x.x.x/28 = table=20 GWA
/sbin/ip route add default = via y.y.y.1 table=20 GWA
 
when I try to see the main table by = giving the=20 command below
 
ip route list table main
 
I find all the ospf routes in that = table ended with=20 the default gw entry
 
when I see the table GWA I find only = the default=20 next hop entry ie., router B (y.y.y.1)
 
is there any way of dynamically = updating even in=20 GWA table with the ospf entries followed by default  next hop=20 y.y.y.1
 
Kindly help me in this = regard
 
 
Visha
 
------=_NextPart_000_0021_01C3E07A.064198A0-- From mkazmier@sofast.net Wed Jan 21 22:12:29 2004 From: mkazmier@sofast.net (Michael S. Kazmier) Date: Wed, 21 Jan 2004 15:12:29 -0700 Subject: [LARTC] Traffic Shaping QoS and rate-limiting clients Message-ID: <00a701c3e06b$a8fa3c00$b53afea9@kazvx88> Hello all, I am trying to figure out a way to traffic shape for QoS (ie, prioritize different types of traffic) for an entire network and ALSO rate limit / shape individual users on this network. =20 Now, I understand it all for rate control on users - what I can't figure = out is how we can shape / prioritize by protocol (ie, treat ssh / telnet = higher than www which is higher than ftp, etc). I suppose we could use the = "split" command (9.5.4.5. Other CBQ parameters: split & defmap) but we would = still require a separate rule for each user. =20 What does that mean -> well, we have one rule for each interface = (minimum 2) - one rule for each customer for each interface - AND one rule for each traffic filter for each customer for each interface!!! Obviously with several hundred users and 4 or 5 or 10 or 20 traffic prioritizations, we = are looking at an unmanageable situation. For those that are graphically inclined, here is what I am wanting to do utilizing CBQ: ROOT 1: / \ Business(1:1) Residential(1:2) <-- Each PRIO Business 3, = Residential 4, possible rate limit / \ (Traffic Flow) (Traffic Flow) <-- PRIO and rate limit web, ftp, = ssh, etc. / \ (Individual Cust) (Individual Cust) <-- Individual rate limit per = customer Please - Any thoughts on achieving the above would be greatly = appreciated! Thanks in advance!=20 --Mike From damion@snapgear.com Thu Jan 22 00:08:55 2004 From: damion@snapgear.com (Damion de Soto) Date: Thu, 22 Jan 2004 10:08:55 +1000 Subject: [LARTC] script says RTNETLINK answers: Invalid argument References: <400E3611.4080000@otaku42.de> <1074691691.2072.9.camel@Morocha.bit2NET.com> Message-ID: <400F1497.8050305@snapgear.com> Hi Javier, 1) don't 'reply' to messages if you are starting a new question/topic/thread 2) a relevent subject would help too. > Hi, I have a litle problem with this code > > I have two virtual ips (50 y 51) and this ips are the gateway > > ip address add 192.168.0.50 dev eth1 > ip address add 192.168.0.51 dev eth1 > tc qdisc add dev eth1 root handle 1: cbq bandwidth 512kbit cell 8 avpkt \ > 1000 mpu 64 > tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 512kbit rate \ > 100kBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21 > tc class add dev eth1 parent 1:0 classid 1:2 cbq bandwidth 512kbit rate \ > 100kbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21 > tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1 > tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.0.50 \ > flowid 1:1 > tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.0.51 \ > flowid 1:2 > > and this scrip say: > > RTNETLINK answers: Invalid argument > RTNETLINK answers: Invalid argument > RTNETLINK answers: Invalid argument 3) You should really run the commands in the script one by one, so you can find out exactly which ones are failing. I would suggest that the 'tc qdisc .... cbq' commands are failing - probabaly because you don't have the cbq module in your kernel. but, it could be the filter commands (u32 module), or something else. 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 terry@baycitymicro.com Thu Jan 22 06:50:33 2004 From: terry@baycitymicro.com (Terry Tse) Date: Wed, 21 Jan 2004 22:50:33 -0800 Subject: [LARTC] Puzzled why my scripts don't give me the desired result Message-ID: <5.1.0.14.2.20040121223250.030feaa0@mail.baycitymicro.com> I am wondering if someone can examine why my set up does not give me the desired result. What I aim to achieve is to make DNS, ICMP, POP3, HTTP, SSH, SMTP traffic at a higher priority than FTP serving and Kazza traffic. However, when the FTP server is busy servicing FTP traffic, web browsing traffic has dragged to almost unusable. Abstract of my iptables script follows:- # Mark traffic on the firewall machine itself $IPTABLES -t mangle -A MANGLE_OUTPUT -p 1 -j MARK --set-mark 1 $IPTABLES -t mangle -A MANGLE_OUTPUT -p 6 -m multiport --sport 22,53 -j MARK --set-mark 2 $IPTABLES -t mangle -A MANGLE_OUTPUT -p 17 --sport 53 -j MARK --set-mark 2 $IPTABLES -t mangle -A MANGLE_OUTPUT -p 6 -m length --length :64 -j MARK --set-mark 1 $IPTABLES -t mangle -A MANGLE_OUTPUT -m mark --mark 0 -j MARK --set-mark 3 # Mark traffic on LAN outgoing traffic through the firewall machine $IPTABLES -t mangle -A MANGLE_PREROUTING -p 6 -m multiport --sport 22,80 -j MARK --set-mark 1 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 6 -m multiport --sport 25,110,21 -j MARK --set-mark 2 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 6 -m multiport --dport 22,80 -j MARK --set-mark 1 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 6 --sport 1214 -j MARK --set-mark 4 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 6 --dport 1214 -j MARK --set-mark 4 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 17 --sport 1214 -j MARK --set-mark 4 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 17 --dport 1214 -j MARK --set-mark 4 $IPTABLES -t mangle -A MANGLE_PREROUTING -p 6 -m length --length :64 -j MARK --set-mark 1 $IPTABLES -t mangle -A MANGLE_PREROUTING -m mark --mark 0 -j MARK --set-mark 3 Abstract of my TC script:- tc qdisc add $DEV root handle 1: htb default 40 # shape everything at $UPLINK speed - this prevents huge queues in the DSL modem that destroy latency tc class add $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit ceil ${UPLINK}kbit burst 12k # divide traffic into 4 classes with high prio class 1:10: tc class add $DEV parent 1:1 classid 1:10 htb rate $[UPLINK/2]kbit ceil ${UPLINK}kbit burst 12k prio 0 tc class add $DEV parent 1:1 classid 1:20 htb rate $[UPLINK/4]kbit ceil ${UPLINK}kbit burst 12k prio 1 tc class add $DEV parent 1:1 classid 1:30 htb rate $[UPLINK/6]kbit ceil ${UPLINK}kbit burst 12k prio 2 tc class add $DEV parent 1:1 classid 1:40 htb rate $[UPLINK/12]kbit ceil ${UPLINK}kbit burst 12k prio 3 # both get Stochastic Fairness tc qdisc add $DEV parent 1:10 handle 10: sfq perturb 10 tc qdisc add $DEV parent 1:20 handle 20: sfq perturb 10 tc qdisc add $DEV parent 1:30 handle 30: sfq perturb 10 tc qdisc add $DEV parent 1:40 handle 40: sfq perturb 10 tc filter add $DEV parent 1:0 prio 0 protocol ip handle 1 fw flowid 1:10 tc filter add $DEV parent 1:0 prio 0 protocol ip handle 2 fw flowid 1:20 tc filter add $DEV parent 1:0 prio 0 protocol ip handle 3 fw flowid 1:30 tc filter add $DEV parent 1:0 prio 0 protocol ip handle 4 fw flowid 1:40 From lartc@nikhiljogia.com Thu Jan 22 07:46:48 2004 From: lartc@nikhiljogia.com (Nikhil Jogia) Date: Thu, 22 Jan 2004 15:46:48 +0800 Subject: [LARTC] Problems with netfilter Message-ID: Hi, I have 2 internet connections (1 adsl/1 cable). I am try to route all outgoing mail from the mail server (on the same box), through the ADSL connection routing through the cable will mean mail will get rejected by AOL :( I am using qmail as the mail server. The configuration is: eth0 : cable connection ppp0 : adsl connection eth2 : internal lan connection I have configured split access as described in LARTC section 4.2.1, and that is working fine, however, routing outgoing mail is proving to be elusive. I have turned off reverse path filtering, and, have loaded probably every netfilter related kernel module. Here are some more information : IPTABLES RULES (I did them for all interfaces to see if it worked - it didnt.) iptables -t mangle -A PREROUTING -p tcp -i eth0 --dport 25 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -i eth1 --dport 25 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -i eth2 --dport 25 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -i lo --dport 25 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -i ppp0 --dport 25 -j MARK --set-mark 1 iptables -L -v -t mangle Chain PREROUTING (policy ACCEPT 89929 packets, 26M bytes) pkts bytes target prot opt in out source destination 0 0 MARK tcp -- eth0 any anywhere anywhere tcp dpt:smtp MARK set 0x1 0 0 MARK tcp -- eth1 any anywhere anywhere tcp dpt:smtp MARK set 0x1 11 1204 MARK tcp -- eth2 any anywhere anywhere tcp dpt:smtp MARK set 0x1 26 2152 MARK tcp -- lo any anywhere anywhere tcp dpt:smtp MARK set 0x1 0 0 MARK tcp -- ppp0 any anywhere anywhere tcp dpt:smtp MARK set 0x1 ip route show yyy.yyy.yyy.yyy dev ppp0 proto kernel scope link src xxx.xxx.xxx.xxx zzz.zzz.zzz.zzz dev eth0 scope link src zzz.zzz.zzz.zzz 192.168.0.0/24 dev eth2 scope link zzz.zzz.zzz.zzz/22 dev eth0 proto kernel scope link src zzz.zzz.zzz.zzz 127.0.0.0/8 dev lo scope link default via zzz.zzz.zzz.zzz dev eth0 ip rule show 0: from all lookup local 32755: from xxx.xxx.xxx.xxx lookup T2 32756: from zzz.zzz.zzz.zzz lookup T1 32760: from all fwmark 0x1 lookup mail 32766: from all lookup main 32767: from all lookup 253 ip route show table mail default via xxx.xxx.xxx.xxx dev ppp0 I feel that I have tried everything to get this to work - read the archives, googled, played with a million iptables rules, iproutes and loaded kernel modules - but to no avail! rtacct shows nothing. Using mandrake 9.2 btw. Please help!!! --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.563 / Virus Database: 355 - Release Date: 17/01/2004 From anderson@mino.skyweb.co.ke Thu Jan 22 07:54:21 2004 From: anderson@mino.skyweb.co.ke (Anderson Levi) Date: Thu, 22 Jan 2004 10:54:21 +0300 Subject: [LARTC] Search Engine Message-ID: <400F81AD.9060300@mino.skyweb.co.ke> Hi all, I was wondering whether there is a search engine I could use to search the list. It would help get info quicker and reduce redundancy :-). Thanks. From cord@keppler.vrg.de Thu Jan 22 11:33:16 2004 From: cord@keppler.vrg.de (Cord Buhlert) Date: Thu, 22 Jan 2004 12:33:16 +0100 Subject: [LARTC] IPsec and u32 filters Message-ID: <20040122113316.GA2014@keppler.vrg.de> Hi, how can I filter IPsec traffic with u32 filters? I know IPsec needs Port 500/UDP and IP protocols 50 and 51. I know how to get the port stuff, but how can I make u32 to match the protocol number? thx, cb From nirmala_t@hotmail.com Thu Jan 22 14:13:33 2004 From: nirmala_t@hotmail.com (Nirmala Thiagarajan) Date: Thu, 22 Jan 2004 14:13:33 +0000 Subject: [LARTC] request from nimal Message-ID:

hi lartc members,

     I am trying to implement LARTC in a small Lan with ethernet 100 mbits. I want to configure packet filters, scheduling and shaping using tc command. My problem is i dont know how to show the result in the small lan . Plz help me.

thanking u all.



 



Play the prediction game on MEZ. Win Sehwag’s autographed T-shirts. Predict and win on myenjoyzone.com From white@bookmaster.com Wed Jan 21 17:08:21 2004 From: white@bookmaster.com (Dan White) Date: Wed, 21 Jan 2004 09:08:21 -0800 Subject: [LARTC] HTB and VOIP- Choppy voice quality: What am I doing wrong? Desperate! Message-ID: <005a01c3e041$2c6023a0$e40a0a0a@bmi2541.com> This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C3DFFE.1E2C1AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, ( I apologize if this posts twice ) Here is my situation. I have 3 buildings linked with 100mbit fiber = optics (2 runs that come to the corporate office). I have 3 RH9 boxes, = one at each location. Each box at the remote locations have 4 NICs, one = for the fiber link, one for LAN, one for the VOIP box and one for the = internet connection. The corporate office has 4 NICs also, 1 for each = fiber run to the remotes, one for the VOIP box, one for the LAN = (corporate gets its internet from the remotes). I have drawn a diagram = here Http://208.45.203.98/fiber.jpg All of the gateways are set up properly, and I can communicate in = all directions, and can place calls clearly when the traffic is low. Now = here is my problem. When I dump a big file over the fiber link, the = voice quality goes down considerably. I hit "cancel" on the file, the = quality is back. Here is what I know about the Inter-Tel VOIP box we = use: it uses UDP streams on ports 5000-5018 and 16384 @ 8-18k per side, = per call, over 7 possible channels. Each site has 7 channels, which are = rarely all in use. So, the total bandwidth should be, at max (18k x 2 = directions x 7 channels) is 252k I came in on Saturday alone, and was = able to kill the quality with one call, and one 1gb file in transit. I = have set HTB up as follows: ( 1: ) (1:1) (1:2) (1:10) (1:11)(1:12) Here is my script, it is the same at all 3 sites = http://208.45.203.97/script.txt (I would post it, but it is pretty = long). As you can see I have given 80mbit to the phones (remember, they = should only need 252k!), 16mbit to default, and cut windows file sharing = back to 1mbit, but I still have voice issues during file transfers! I = know the filters are catching the traffic (I did "tc -s -d class show = dev eth1" and watched my numbers while calling, and transferring files, = and the incremented properly) Can anybody help me, I have been screwing = with this for days, and I am at my wits end! I am still relatively new = to all of this, but I always bite off more than I can chew :) Dan White Senior IT Manager=20 Bookmasters Inc. ------=_NextPart_000_0057_01C3DFFE.1E2C1AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
 
    ( I apologize if = this posts=20 twice )
 
    Here is my = situation. I have 3=20 buildings linked with 100mbit fiber optics (2 runs that come to the = corporate=20 office). I have 3 RH9 boxes, one at each location. Each box at the = remote=20 locations have 4 NICs, one for the fiber link, one for LAN, one for=20 the VOIP box and one for the internet connection. The corporate = office has=20 4 NICs also, 1 for each fiber run to the remotes, one for the VOIP box, = one for=20 the LAN (corporate gets its internet from the remotes). I have drawn a = diagram=20 here Http://208.45.203.98/fiber.jpg
 
    All of the gateways = are set up=20 properly, and I can communicate in all directions, and can place calls = clearly=20 when the traffic is low. Now here is my problem. When I dump a big file = over the=20 fiber link, the voice quality goes down considerably. I hit "cancel" on = the=20 file, the quality is back. Here is what I know about the Inter-Tel VOIP = box we=20 use: it uses UDP streams on ports 5000-5018 and 16384 @ 8-18k per = side, per=20 call, over 7 possible channels. Each site has 7 channels, which are = rarely all=20 in use. So, the total bandwidth should be, at max (18k x 2 = directions x 7=20 channels) is 252k I came in on Saturday alone, and was able to kill = the=20 quality with one call, and one 1gb file in transit. I have set HTB up as = follows:
 
           ( = 1:=20 )
 (1:1)         = ;   =20 (1:2)
(1:10)       (1:11)(1:12)
 
Here is my script, it is the same at = all 3 sites http://208.45.203.97/script.txt<= /A> =20 (I would post it, but it is pretty long). As you can see I have given = 80mbit to=20 the phones (remember, they should only need 252k!), 16mbit to default, = and cut=20 windows file sharing back to 1mbit, but I still have voice issues during = file=20 transfers! I know the filters are catching the traffic (I did "tc -s -d = class=20 show dev eth1" and watched my numbers while calling, and transferring = files, and=20 the incremented properly) Can anybody help me, I have been screwing with = this=20 for days, and I am at my wits end! I am still relatively new to all of = this, but=20 I always bite off more than I can chew :)
 
Dan White
Senior IT Manager
Bookmasters Inc.
 
------=_NextPart_000_0057_01C3DFFE.1E2C1AC0-- From santiago@avatar.com.co Thu Jan 22 17:06:41 2004 From: santiago@avatar.com.co (Santiago J. R=?ISO-8859-1?B?dWFubyBSaW5j824=?=) Date: Thu, 22 Jan 2004 12:06:41 -0500 Subject: [LARTC] Fair bandwidth oversubscribing ? How with HTB ? In-Reply-To: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> References: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> Message-ID: <1074791201.40100321e731b@webmail.avatar.com.co> Did you think something like this?: tc class add dev eth0 parent x: ... htb rate 83kbps ceil 256kbps Quoting Simon Byrnand : > Hopefully someone has a suggestion on how I might do this...as I can't > figure it out :( > > I need to be able to set up a group of seperate users who have a > "bandwidth pool" they share, but also be able to limit their individual > bandwidth as well. > > Example: > > I have 5 customers and would like to be able to provide them with a > maximum of 256Kbit each, with a CIR of 33%. > > To do this, I'd like the 5 customers to share a parent group which is > therefore limited to 426Kbit, Which is 5*256Kbit/3. > > The idea being that individual customers can achieve up to a maximum of > 256Kbit provided that the total group pool doesn't exceed 426Kbit, and if > the total group pool maxes out, then each customer should get reduced > bandwidth in fair ratios based on their individual maximum setting. > (Currently 256Kbit for all of them, but I'd like to be able to > differentiate them later) > > If all 5 were trying to fully utilize their bandwidth at the same time, > they should get a fairly distributed 33% of their maximum - eg about > 85Kbit. > > The problem I can see is that both CBQ and HTB don't seem to honour > situations where the sum of all the child rates exceeds the parent rate - > the parent rate is ignored so the 426Kbit cap is exceeded. The HTB docs > even explicitely say this won't work. > > So is there any tricky way to do this with slightly different semantics ? > Surely there must be some way :-) I've spent many long hours studying CBQ > and trying things out and finally came to the conclusion that CBQ alone > just can't do it, but I was hoping HTB could, but thus far I've been > unsuccessful here too.. > > Currently I'm using CBQ but I'm limited in that the individual maximum > speeds can only equal the parent group maximum bandwidth which is workable > for a few customers, but not very satisfactory and not flexible enough as > I add more customers. > > If someone could point me in the right direction or just give me a firm > "nope, can't be done" that would be great.... > > I'd also like to enable short term bursting over and above this as well, > to improve responsiveness during downloading, say, 33% overbandwidth for 5 > seconds, that sort of thing, but I'll cross that bridge when (if) I get to > it...(any comments here on how effective enabling bursting is for reducing > the dreaded unresponsiveness-during-downloads problem would be welcome > too) > > Regards, > Simon > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > Santiago J. Ruano Rincón Avatar Ltda. ParqueSoft Popayán +57-2 8221214 From stef.coene@docum.org Thu Jan 22 17:31:18 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 18:31:18 +0100 Subject: [LARTC] Search Engine In-Reply-To: <400F81AD.9060300@mino.skyweb.co.ke> References: <400F81AD.9060300@mino.skyweb.co.ke> Message-ID: <200401221831.18555.stef.coene@docum.org> On Thursday 22 January 2004 08:54, Anderson Levi wrote: > Hi all, > > I was wondering whether there is a search engine I could use to search > the list. It would help get info quicker and reduce redundancy :-). You can use google. Include site:mailman.ds9a.nl in your search and google will search the LARTC mailing list archives. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Jan 22 17:26:32 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 18:26:32 +0100 Subject: [LARTC] request from nimal In-Reply-To: References: Message-ID: <200401221826.32228.stef.coene@docum.org> On Thursday 22 January 2004 15:13, Nirmala Thiagarajan wrote: > hi lartc members, > > > I am trying to implement LARTC in a small Lan with ethernet 100 mbits. > I want to configure packet filters, scheduling and shaping using tc > command. My problem is i dont know how to show the result in the small lan > . Plz help me. You can start with disabling html email. What do you mean exacly? Do you have problems configuring LARTC? Or do you want to see the results? Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From x11@h2o.pieva.net Thu Jan 22 17:39:46 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 22 Jan 2004 19:39:46 +0200 Subject: [LARTC] HTB and VOIP- Choppy voice quality: What am I doing wrong? Desperate! In-Reply-To: <005a01c3e041$2c6023a0$e40a0a0a@bmi2541.com> References: <005a01c3e041$2c6023a0$e40a0a0a@bmi2541.com> Message-ID: <40100AE2.80303@h2o.pieva.net> Dan White wrote: > All of the gateways are set up properly, and I can communicate in > all directions, and can place calls clearly when the traffic is low. Now > here is my problem. When I dump a big file over the fiber link, the > voice quality goes down considerably. I hit "cancel" on the file, the > quality is back. Does VoIP set quality automaticaly by latency or traffic capabilities? > Here is what I know about the Inter-Tel VOIP box we > use: it uses UDP streams on ports 5000-5018 and 16384 @ 8-18k per side, > per call, over 7 possible channels. Each site has 7 channels, which are > rarely all in use. So, the total bandwidth should be, at max (18k x 2 > directions x 7 channels) is 252k I came in on Saturday alone, and was > able to kill the quality with one call, and one 1gb file in transit. I > have set HTB up as follows: > > ( 1: ) > (1:1) (1:2) > (1:10) (1:11)(1:12) > > Here is my script, it is the same at all 3 sites > http://208.45.203.97/script.txt You have many u32 filters. It's not an issue, but i usualy get with fw and marking packets in iptables. That would make script much easier to read. Example follows: # $IPT -t mangle -A FORWARD -s $LAN_NET -d $ADDR -i $LAN -o $PARABOLE -j MARK --set-mark 20 # tc filter add dev $LAN protocol ip parent 1:0 prio 1 handle 20 fw flowid 1:20 > (I would post it, but it is pretty > long). As you can see I have given 80mbit to the phones (remember, they > should only need 252k!), 16mbit to default, and cut windows file sharing > back to 1mbit, but I still have voice issues during file transfers! I > know the filters are catching the traffic (I did "tc -s -d class show > dev eth1" and watched my numbers while calling, and transferring files, > and the incremented properly). Well, did you try assigning priorities of sending? There should be something as prio (cosult HTB manual). If real, i don't know "The Real Solution", I'm just trying to help :) I had no expierence with VoIP. From stef.coene@docum.org Thu Jan 22 19:48:07 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 20:48:07 +0100 Subject: [LARTC] Puzzled why my scripts don't give me the desired result In-Reply-To: <5.1.0.14.2.20040121223250.030feaa0@mail.baycitymicro.com> References: <5.1.0.14.2.20040121223250.030feaa0@mail.baycitymicro.com> Message-ID: <200401222048.07519.stef.coene@docum.org> On Thursday 22 January 2004 07:50, Terry Tse wrote: > I am wondering if someone can examine why my set up does not give me the > desired result. What I aim to achieve is to make DNS, ICMP, POP3, HTTP, > SSH, SMTP traffic at a higher priority than FTP serving and Kazza traffic. > > However, when the FTP server is busy servicing FTP traffic, web browsing > traffic has dragged to almost unusable. You have to shape in both directions if you want to get good results. Also, if you use different prio's for the class, you can get in trouble when a low prio class sends more data then the configured rate. If this is the case, the latency will be very high for the low prio class. And ftp traffic is more than port 22. It can be any port. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Jan 22 19:49:24 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 20:49:24 +0100 Subject: [LARTC] Quantum of class nnnnn is big In-Reply-To: References: Message-ID: <200401222049.24745.stef.coene@docum.org> On Wednesday 21 January 2004 17:18, rubens@etica.net wrote: > > Make sure 1500 < quantum < 60000 > > quantum = rate / r2q > > Stef, > > Would it be 1500 < quantum, or 1500 <= quantum ? No, 1500 < quantim < 60.000. So quantum must be at least 1500, that's the maximum packet size. And < 60000 and this is hard decoded in htb to prevent cass starvation. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Jan 22 19:52:50 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 20:52:50 +0100 Subject: [LARTC] rshaper Config In-Reply-To: <20040121055614.99289.qmail@web40405.mail.yahoo.com> References: <20040121055614.99289.qmail@web40405.mail.yahoo.com> Message-ID: <200401222052.50121.stef.coene@docum.org> On Wednesday 21 January 2004 06:56, tulasi wrote: > Hi Every One, > > I am using Linux 2.4 with 8390 Network driver. For > configuring rshaper in one of the manual i have > studied that need to insert the following line in > Global space of Kernel. > > int (*net_shaper_rx_hook)(struct sk_buff *skb) = NULL; > > > Can you suggest me anyone steps to insert the line and > where in my Linux System. I am very new to kernel > part. Forget rshaper, use tc :) That's where this list is about. See lartc.org and docum.org for more info. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From rubens@etica.net Thu Jan 22 19:56:51 2004 From: rubens@etica.net (rubens@etica.net) Date: Thu, 22 Jan 2004 17:56:51 -0200 (BRST) Subject: [LARTC] Problems with netfilter In-Reply-To: Message-ID: On Thu, 22 Jan 2004, Nikhil Jogia wrote: > I have 2 internet connections (1 adsl/1 cable). I am try to route all > outgoing mail from the mail server (on the same box), through the ADSL > connection routing through the cable will mean mail will get rejected by AOL > :( I am using qmail as the mail server. Have you tried binding the mail server to the ADSL IP address ? > I feel that I have tried everything to get this to work - read the archives, > googled, played with a million iptables rules, iproutes and loaded kernel > modules - but to no avail! Are the FORWARD tables configured to ACCEPT the packets, either by default policy or explicit rules ? One thing I feel is missing are POSTROUTING SNAT rules, so that if a packet is going out to an interface with an IP source that is not its address, it's natted to the IP address. You should have two of that rules, one for the cable and for the ADSL. Rubens From rubens@etica.net Thu Jan 22 19:29:26 2004 From: rubens@etica.net (rubens@etica.net) Date: Thu, 22 Jan 2004 17:29:26 -0200 (BRST) Subject: [LARTC] a couple of questions regarding htb In-Reply-To: <91FC132ACA694F45A6E42CE8E593838C39C328@zmx.staff.zeelandnet.nl> Message-ID: On Wed, 21 Jan 2004, Serge Maandag wrote: > > Only outgoing traffic can be classfully shaped or limited. > > > Is that correct or will limiting of incoming traffic work > > but isn't it just as reliable? > > > > It's just not very flexible. > > In what manner? As in no borrowing / lending or as in hard to > configure or as in ... ? Ingress only limit, do not shape. Egress can shape or limit, depending on qdisc/classes configuration. > > What is your concern, inter-customer traffic ? Or even the Internet > > traffic can go thru more than one interface ? > > No, there is one uplink to the internet. The other links go to networks > with other customers. But there's quite some inter-customer traffic. Inter-customer traffic will me limited anyway according to target downlink (from you to customer); it's a freebie that you probably shouldn't mind to give away. Rubens From stef.coene@docum.org Thu Jan 22 20:11:03 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 21:11:03 +0100 Subject: [LARTC] Quantum of class nnnnn is big In-Reply-To: References: Message-ID: <200401222111.03359.stef.coene@docum.org> On Wednesday 21 January 2004 17:18, rubens@etica.net wrote: > > Make sure 1500 < quantum < 60000 > > quantum = rate / r2q > > Stef, > > Would it be 1500 < quantum, or 1500 <= quantum ? I checked the htb code in kernel 2.6.1: if quantum < 1000 or quantum > 200000, an eror is logged. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Thu Jan 22 19:50:45 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 22 Jan 2004 20:50:45 +0100 Subject: [LARTC] htb+beginner+error In-Reply-To: <1074606400.2617.9.camel@testbox.co.za> References: <1074606400.2617.9.camel@testbox.co.za> Message-ID: <200401222050.45773.stef.coene@docum.org> On Tuesday 20 January 2004 14:46, Eddie wrote: > Good day all > So at log last I did my script > We have a 256kbite connection.This scrip runs on my gateway box(the same > for script for eth1(ext) and eth0(int) > I want to limit all other traffic to 10kbites but when I do it I give me > this error: > > HTB quantum of class 10034 is to small.consider r2q <7>htb*g j=42801780 See some other, recent posts on the mailinglist and the faq page on docum.org for the quantum problems. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From damion@snapgear.com Thu Jan 22 23:46:32 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 23 Jan 2004 09:46:32 +1000 Subject: [LARTC] IPsec and u32 filters References: <20040122113316.GA2014@keppler.vrg.de> Message-ID: <401060D8.6080301@snapgear.com> Cord Buhlert wrote: > how can I filter IPsec traffic with u32 filters? > I know IPsec needs Port 500/UDP and IP protocols 50 and 51. I know how > to get the port stuff, but how can I make u32 to match the protocol > number? Same as matching tcp packets: match ip protocol 0x32 0xff (ESP proto 50) or match ip protocol 0x33 0xff (AH proto 51) 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 simon@igrin.co.nz Thu Jan 22 23:49:29 2004 From: simon@igrin.co.nz (Simon Byrnand) Date: Fri, 23 Jan 2004 12:49:29 +1300 Subject: [LARTC] Fair bandwidth oversubscribing ? How with HTB ? In-Reply-To: <400DC410.1060201@trash.net> References: <1187.202.49.246.211.1074629494.squirrel@webmail.igrin.co.nz> <1074633726.400d9bfec0223@webmail.avatar.com.co> <400DC410.1060201@trash.net> Message-ID: <6.0.1.1.1.20040123124902.03f72c90@mail.igrin.co.nz> At 13:13 21/01/2004, Patrick McHardy wrote: >Santiago J. Ruano Rinc=F3n wrote: > >>try HFSC, Hierarchical Fair Service Curve: >> >>http://trash.net/~kaber/hfsc >>http://www-2.cs.cmu.edu/~hzhang/HFSC/ >> >>i'm going to test it in this week. >> > >This should indeed work with HFSC if the custumer-classes have only >links-haring service curves and no realtime service curves. The parent >class would be limited with an upper-limit service curve. With >link-sharing service curves, only the relative differences of virtual >time on a level of the heirarchy are relevant, so there is no problem >oversubscribing the parent class. the upper-limit service curve of the >parent limits the total bandwidth, unlike the link-sharing curve it >uses wall-clock time. > >Best regards, >Patrick > >PS: Please let me know if you are successful. Hi, I quickly looked at HFSC's page, but from what I see it is not in the=20 standard kernel, so I'd like to see if HTB can do it first before trying=20 HFSC as the machine is running 2.4.24 which has HTB built in. From some=20 other replies it looks like HTB can do it. Regards, Simon From rmocius@auste.elnet.lt Fri Jan 23 09:15:34 2004 From: rmocius@auste.elnet.lt (Remus) Date: Fri, 23 Jan 2004 09:15:34 -0000 Subject: [LARTC] Traffic shaping and IP aliases Message-ID: <09d901c3e191$86e66720$6e69690a@RIMAS> This is a multi-part message in MIME format. ------=_NextPart_000_09D4_01C3E191.74A7D710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, I have the traffic shaping (HTB and IMQ) on my eth0 (of course no = problems with it). And now I would like add some extra IPs on it ( ifconfig eth0:0 = xxx.xxx.xxx.xxx and ifconfig eth0:1 xxx.xxx.xxx.xxx). So do I have to set up a new tc rools ( tc qdisc add dev eth0:0 root = handle 1: htb default 20 r2q 5 ...) for the eth0:0 and eth0:1=20 or can still be only tc rules for the eth0? Thanks in advance Remus ------=_NextPart_000_09D4_01C3E191.74A7D710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
 
I have the traffic shaping (HTB and = IMQ) on my eth0=20 (of course no problems with it).
And now I would like add some extra IPs = on it=20 ( ifconfig eth0:0 xxx.xxx.xxx.xxx and ifconfig eth0:1=20 xxx.xxx.xxx.xxx).
 
So do I have to set up a new tc rools ( = tc qdisc=20 add dev eth0:0 root handle 1: htb default 20 r2q 5 ...) for = the eth0:0=20 and eth0:1
or can still be only tc rules for the=20 eth0?
 
 
Thanks in advance
 
Remus
 
 
 

 
------=_NextPart_000_09D4_01C3E191.74A7D710-- From lartc@manchotnetworks.net Fri Jan 23 14:39:33 2004 From: lartc@manchotnetworks.net (lartc@manchotnetworks.net) Date: Fri, 23 Jan 2004 15:39:33 +0100 Subject: [LARTC] kptd & ipsec Message-ID: <1074868772.3782.5.camel@drs0.manchotnetworks.net> hi all, could someone describe where the encryption & de-encryption is in the kptd? thanks! charles From lartc@bobich.net Fri Jan 23 10:52:20 2004 From: lartc@bobich.net (Gordan Bobic) Date: Fri, 23 Jan 2004 10:52:20 +0000 Subject: [LARTC] Traffic shaping and IP aliases In-Reply-To: <09d901c3e191$86e66720$6e69690a@RIMAS> References: <09d901c3e191$86e66720$6e69690a@RIMAS> Message-ID: <200401231052.20954.lartc@bobich.net> On Friday 23 Jan 2004 09:15, Remus wrote: > Hi folks, > > > I have the traffic shaping (HTB and IMQ) on my eth0 (of course no > problems with it). And now I would like add some extra IPs on it ( > ifconfig eth0:0 xxx.xxx.xxx.xxx and ifconfig eth0:1 xxx.xxx.xxx.xxx). > > So do I have to set up a new tc rools ( tc qdisc add dev eth0:0 root > handle 1: htb default 20 r2q 5 ...) for the eth0:0 and eth0:1 or can > still be only tc rules for the eth0? I've been wondering about the same thing recently. :-) As far as I have managed to find, the only way to do this is to set up dummy devices pointed at the real interface, and shape those instead. I haven't had a chance to try it yet, though... Gordan From mike@superiorholidayadventures.ca Fri Jan 23 16:54:57 2004 From: mike@superiorholidayadventures.ca (Mike) Date: Fri, 23 Jan 2004 11:54:57 -0500 Subject: [LARTC] Traffic shaping and IP aliases Message-ID: Can you even shape on aliases? I thought you could only shape on the actual device. Why not shape on the source or destination IP? Mike. > -----Original Message----- > From: Gordan Bobic [mailto:lartc@bobich.net] > Sent: Friday, January 23, 2004 5:52 AM > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Traffic shaping and IP aliases >=20 > On Friday 23 Jan 2004 09:15, Remus wrote: > > Hi folks, > > > > > > I have the traffic shaping (HTB and IMQ) on my eth0 (of course no > > problems with it). And now I would like add some extra IPs on it ( > > ifconfig eth0:0 xxx.xxx.xxx.xxx and ifconfig eth0:1 xxx.xxx.xxx.xxx). > > > > So do I have to set up a new tc rools ( tc qdisc add dev eth0:0 root > > handle 1: htb default 20 r2q 5 ...) for the eth0:0 and eth0:1 or can > > still be only tc rules for the eth0? >=20 > I've been wondering about the same thing recently. :-) >=20 > As far as I have managed to find, the only way to do this is to set up > dummy devices pointed at the real interface, and shape those instead. I > haven't had a chance to try it yet, though... >=20 > Gordan > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From mike@superiorholidayadventures.ca Fri Jan 23 16:56:43 2004 From: mike@superiorholidayadventures.ca (Mike) Date: Fri, 23 Jan 2004 11:56:43 -0500 Subject: [LARTC] Traffic shaping and IP aliases Message-ID: Yes: http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg07410.html search for the text "alias" bummer. Mike. > -----Original Message----- > From: Gordan Bobic [mailto:lartc@bobich.net] > Sent: Friday, January 23, 2004 5:52 AM > To: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Traffic shaping and IP aliases >=20 > On Friday 23 Jan 2004 09:15, Remus wrote: > > Hi folks, > > > > > > I have the traffic shaping (HTB and IMQ) on my eth0 (of course no > > problems with it). And now I would like add some extra IPs on it ( > > ifconfig eth0:0 xxx.xxx.xxx.xxx and ifconfig eth0:1 xxx.xxx.xxx.xxx). > > > > So do I have to set up a new tc rools ( tc qdisc add dev eth0:0 root > > handle 1: htb default 20 r2q 5 ...) for the eth0:0 and eth0:1 or can > > still be only tc rules for the eth0? >=20 > I've been wondering about the same thing recently. :-) >=20 > As far as I have managed to find, the only way to do this is to set up > dummy devices pointed at the real interface, and shape those instead. I > haven't had a chance to try it yet, though... >=20 > Gordan > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From mkazmier@sofast.net Fri Jan 23 17:29:13 2004 From: mkazmier@sofast.net (Michael S. Kazmier) Date: Fri, 23 Jan 2004 10:29:13 -0700 Subject: [LARTC] IMQ Stability Message-ID: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> Hello all, I have been doing a lot of archive searching over the last week reading posts on IMQ and it's apparent stability / instability. I have seen a number of posts about it not being maintained as well. Can anyone talk to me about IMQ's stability in a heavy throughput environment (20 Mbps) and what was causing IMQ to fail if you know. Thanks, Mike From reza@mra.co.id Fri Jan 23 17:38:57 2004 From: reza@mra.co.id (Mohammad Reza) Date: Sat, 24 Jan 2004 00:38:57 +0700 Subject: [LARTC] htbinit and redhat-9.0 Message-ID: ZGVhciBBbGwsDQpJJ20gYSBuZXcgc3R1ZGVudCBhbmQgbXkgam9iIGlzIHRvbyBzaGFwcGluZyBi YW5kd2l0aCBmb3Igb3VyIGNhbXB1cyBmYWN1bHR5IG5ldHdvcmsuDQpJIHdhbnQgdG8gaW1wbGVt ZW50IGh0YiB3aXRoIFJlZGhhdC05LjAgZGlzdHJvLg0KZG9lcyB0aGlzIGRpc3RybyBrZXJuZWwg c3VwcG9ydCBodGIgYW5kIHRjIGdvb2QgPyBvciBpIHNob3VsZCBhcHBseSBzb21lIHBhdGNoIG9y IHVwZ3JhZGUga2VybmVsID8NCiANCnJlZ2FyZHMNCnJlemENCiANCg== From stef.coene@docum.org Fri Jan 23 18:29:47 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 23 Jan 2004 19:29:47 +0100 Subject: [LARTC] htbinit and redhat-9.0 In-Reply-To: References: Message-ID: <200401231929.47249.stef.coene@docum.org> On Friday 23 January 2004 18:38, Mohammad Reza wrote: > dear All, > I'm a new student and my job is too shapping bandwith for our campus > faculty network. I want to implement htb with Redhat-9.0 distro. > does this distro kernel support htb and tc good ? or i should apply some > patch or upgrade kernel ? Patch the kernel yourself so you are sure you have the latest htb. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From 2084964@campus.uab.es Fri Jan 23 18:14:31 2004 From: 2084964@campus.uab.es (Felipe Herrera) Date: Fri, 23 Jan 2004 19:14:31 +0100 Subject: [LARTC] Set IP Options Message-ID: <0HRY00474G85SY@campus.uab.es> Hi All, I'm trying to do something regarding Bandwith Aggregation and I would need to set new options in the IP-header. I had been studying some kernel source that concern to the IP layer, but I don't really know how to set a new option. Does anyone have any idea to add new custom options into the IP header ? Thank you in advance Felipe Herrera From stef.coene@docum.org Fri Jan 23 20:56:56 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 23 Jan 2004 21:56:56 +0100 Subject: [LARTC] sum of child rates exceeds parent rate In-Reply-To: <20040119211142.GA10704@legolas.on.net.mk> References: <200401142300.42294.stef.coene@docum.org> <20040119211142.GA10704@legolas.on.net.mk> Message-ID: <200401232156.56520.stef.coene@docum.org> On Monday 19 January 2004 22:11, Damjan wrote: > > It's the other way around. The class needs a token to send a packet. As > > long as the class has tokens, it can send packets. If the class has used > > all his tokens, it asks the parent if he has tokens left. > > Hmm, then you should correct this: > > http://www.docum.org/stef.coene/qos/tests/ > """ > If a child is using a token to send a packet, the same tocken is > requested from the parent. So the child class is using the > tokens/ctokens of it's parent. And without tokens, the parent can't > give remaining bandwidth to it's child classes. > """ It's not wrong. The word "remaining" is important. If the parent has no tokens left, it can't give remaining bandwidth. But the child class can always send packets equal to the rate even if the parent has no tokens left so it can drag the parent (c)tokens negative. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From pturley@rocksteady.com Sat Jan 24 03:23:43 2004 From: pturley@rocksteady.com (Patrick Turley) Date: Fri, 23 Jan 2004 21:23:43 -0600 Subject: [LARTC] Deleting tc filters In-Reply-To: <0HRY00474G85SY@campus.uab.es> References: <0HRY00474G85SY@campus.uab.es> Message-ID: <4011E53F.5000500@rocksteady.com> I have a fairly sophisticated bandwidth control tree. I am using filters to allocate traffic to various HTB buckets according to packet marks. Nothing about that is terribly hard. The problem is that my user population is dynamic. Users appear and disappear over time. Also, the priority to which a user is entitled changes over time. So, as these changes occur, I need to delete and recreate various classes, and I need to change the associated filters in order to route user traffic to the appropriate places. Deleting and reconstructing the entire tree is not an option. The problem I'm running into is that it's *very* hard to figure out how to delete filters. And I'm not the only one who has found this difficult. After a lot of painful Googling, I found the following two outstanding examples: http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg07359.html http://lists.nocat.net/pipermail/nocat/2003-April/003004.html Has anyone made any progress in figuring out the best way to do this? From akucheria@metricsystems.com Sat Jan 24 03:11:00 2004 From: akucheria@metricsystems.com (Amit Kucheria) Date: Fri, 23 Jan 2004 19:11:00 -0800 Subject: [LARTC] sending same packet stream over both links Message-ID: <1074913860.3329.7.camel@amit.metricsystems.com> --=-Hqj1Tp38UXrbk05FLcbx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I have an application requirement that hints at the use of multicast, but I think it can be solved without it. |------- [Receiver 1] [Sender] ------- [Relay/Router] ----| |------- [Receiver 2] There is a UDP stream from the [sender] that needs to reach both the receivers. Is it possible to direct the stream to the [Router] and have iproute2/iptable rules that modify the packets and send it to both the receivers? Thanks for your time. Regards, Amit --=20 .| Amit Kucheria |. ...| Wireless Systems Engineer |... .....| Metric Systems Corp., San Diego, CA |..... ......| www.metricsystems.com |...... --=-Hqj1Tp38UXrbk05FLcbx 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) iD8DBQBAEeJEtLg6PvU36DYRAkdyAJ9OI+QL58bY6+ySArTLiwRYCH1fjgCfc/JR yB7N5+UwmfeVY1sdZL/GqjQ= =hrni -----END PGP SIGNATURE----- --=-Hqj1Tp38UXrbk05FLcbx-- From simon@igrin.co.nz Sat Jan 24 10:46:45 2004 From: simon@igrin.co.nz (Simon Byrnand) Date: Sat, 24 Jan 2004 23:46:45 +1300 (NZDT) Subject: [LARTC] Deleting tc filters In-Reply-To: <4011E53F.5000500@rocksteady.com> References: <0HRY00474G85SY@campus.uab.es> <4011E53F.5000500@rocksteady.com> Message-ID: <1558.202.49.246.101.1074941205.squirrel@webmail.igrin.co.nz> > I have a fairly sophisticated bandwidth control tree. I am using filters > to allocate traffic to various HTB buckets according to packet marks. > Nothing about that is terribly hard. > > The problem is that my user population is dynamic. Users appear and > disappear over time. Also, the priority to which a user is entitled > changes over time. So, as these changes occur, I need to delete and > recreate various classes, and I need to change the associated filters in > order to route user traffic to the appropriate places. Deleting and > reconstructing the entire tree is not an option. Why not ? My traffic control script starts with: /sbin/tc qdisc del dev eth0 root >/dev/null 2>/dev/null Which deletes *all* classes and qdisc's etc for eth0, then the script re-adds things.. So I simply make a change to the tc entries in my script and re-execute it. At worst a user might be unthrottled for 1/100 of a second or less that it takes the script to execute.... Seems a heck of a lot easier than trying to figure out how to delete classes and recreate them etc... (not to mention having to keep track of the heirachy - eg deleting and readding in the correct order) Regards, Simon From jayesh_rathod@sify.com Sat Jan 24 13:57:46 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Sat, 24 Jan 2004 18:57:46 +0500 (IST) Subject: [LARTC] 1000's of classes and filters Message-ID: <1074950866.401272d23b136@smwp01.maa.sify.net> Hi, More than 1000's of classes and filters gets created/deleted in run time. Are we doing it correctly( as our requirement is such). Since few days we are facing lots of problems, like the server gets hanged, we get some junk messages in our logs. we have to reboot our server every now and then. What is the max limit of classes/filters can be created. we are using redhat 7.3. Can any body suggest why is this hapenning. Is any thing to do with tc, we are also using IPtables (but not for shaping). Regards Jayesh ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From raph@raph.com Sat Jan 24 18:16:26 2004 From: raph@raph.com (Raphael Benedet) Date: Sat, 24 Jan 2004 19:16:26 +0100 Subject: [LARTC] rules/routes traversal misunderstanding Message-ID: <4012B67A.4050402@raph.com> Hi, I've been experimenting with ip route for the last few days to get load sharing accross 2 providers working. While it works most of the time, on a few occasions, packets are routed to the wrong interface. I'm not sure to understand rules and routes traversal correctly (I couldn't find answers in the howto). So, here are my questions: 1. How does the rule traversal work exactly? If I have rules like this: 100: from all lookup provider1 200: from all lookup provider2 What does make stop the traversal? For instance, does a default route in provider1 would stop the traversal? 2. are tables entirely separated? Say, if you have this: 100: from all lookup table_part1 200: from all lookup table_part2 and table_part1 contains the route for a provider and table_part2 contains the default route statement for this provider. Obviously, both tables would be checked. But once in table_part2, would the default route work with what was defined in table_part1 or are routes "forgotten" from table to table? I'm pretty new to all this stuff. So, this may sound like stupid questions but I couldn't find the answers in the howto nor the man pages. Thanks in advance. Raphael Benedet From mkazmier@sofast.net Sat Jan 24 23:38:23 2004 From: mkazmier@sofast.net (mkazmier@sofast.net) Date: Sat, 24 Jan 2004 16:38:23 -0700 (MST) Subject: [LARTC] IMQ Stability In-Reply-To: <005a01c3e2d1$337ba7d0$030aa8c0@t> References: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> <005a01c3e2d1$337ba7d0$030aa8c0@t> Message-ID: <32781.204.120.161.2.1074987503.squirrel@webmail.sofast.net> Thank you for the detailed discussion. There is no doubt that there is a need for an IMQ type device/funtionality. What would work really great, IMHO, is a "fake" or psuedo ethernet driver that simply sits as a shim between one or more real drivers. This fake device could allow us to "Stack" qdiscs in a way to allow one to shape traffic in multiple "policies" - ie, prioritize traffic AND allocate / rate shape end users. I have actually thought of utilizing the kernel bonding driver for this - attaching only a single slave to it - but haven't had time as yet. Not sure that this would do anything for ingress shaping though. Thanks again... Mike > Probably I am going to continue imq development, so I know about it > something. > > IMQ is very unpredictable you can use it all week or it may crash at once. > and what is the most strange - crashes osccur everywhere in the kernel > except in the driver itself > this can be kernel bug as well. > under high loag it crashes quite soom while in low load it can hold > forewer > this probably depends on cpu speed and looks that it tends to crash if you > try to shape localy generated trafic > if you use it for ingress only it wont have much problems. > > I have no hope to make it work, I rewrote the code completely few times > and > no use > probably this way just cant work. > > I am going to use completely other way to do the same job. > imq is trying to use userspace queue which dont like when packets are > droped > and seems there is no way to avoid droping > while doing trafic shaping, so I will use another way by completely > removing > packets from iptables at some place and transmitting them directly where > needed. > thus replacing part of kernel code. > this way I will be able at least to track the bug. > > P.S. iptables have another similar module ( ROUTE target ) i tryed it and > it > works in some cases ( i redirect trafic to lo interface) but not very > good. > > > ----- Original Message ----- > From: "Michael S. Kazmier" > To: > Sent: Friday, January 23, 2004 7:29 PM > Subject: [LARTC] IMQ Stability > > >> Hello all, >> >> I have been doing a lot of archive searching over the last week reading >> posts on IMQ and it's apparent stability / instability. I have seen a >> number of posts about it not being maintained as well. Can anyone talk >> to >> me about IMQ's stability in a heavy throughput environment (20 Mbps) and >> what was causing IMQ to fail if you know. >> >> Thanks, >> >> Mike >> >> _______________________________________________ >> LARTC mailing list / LARTC@mailman.ds9a.nl >> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> > > From roy@xxx.lt Sat Jan 24 23:24:23 2004 From: roy@xxx.lt (Roy) Date: Sun, 25 Jan 2004 01:24:23 +0200 Subject: [LARTC] IMQ Stability References: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> Message-ID: <005a01c3e2d1$337ba7d0$030aa8c0@t> Probably I am going to continue imq development, so I know about it something. IMQ is very unpredictable you can use it all week or it may crash at once. and what is the most strange - crashes osccur everywhere in the kernel except in the driver itself this can be kernel bug as well. under high loag it crashes quite soom while in low load it can hold forewer this probably depends on cpu speed and looks that it tends to crash if you try to shape localy generated trafic if you use it for ingress only it wont have much problems. I have no hope to make it work, I rewrote the code completely few times and no use probably this way just cant work. I am going to use completely other way to do the same job. imq is trying to use userspace queue which dont like when packets are droped and seems there is no way to avoid droping while doing trafic shaping, so I will use another way by completely removing packets from iptables at some place and transmitting them directly where needed. thus replacing part of kernel code. this way I will be able at least to track the bug. P.S. iptables have another similar module ( ROUTE target ) i tryed it and it works in some cases ( i redirect trafic to lo interface) but not very good. ----- Original Message ----- From: "Michael S. Kazmier" To: Sent: Friday, January 23, 2004 7:29 PM Subject: [LARTC] IMQ Stability > Hello all, > > I have been doing a lot of archive searching over the last week reading > posts on IMQ and it's apparent stability / instability. I have seen a > number of posts about it not being maintained as well. Can anyone talk to > me about IMQ's stability in a heavy throughput environment (20 Mbps) and > what was causing IMQ to fail if you know. > > Thanks, > > Mike > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From alex-lartc@digriz.org.uk Sun Jan 25 02:04:37 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Sun, 25 Jan 2004 02:04:37 +0000 Subject: [LARTC] IMQ Stability In-Reply-To: <32781.204.120.161.2.1074987503.squirrel@webmail.sofast.net> References: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> <005a01c3e2d1$337ba7d0$030aa8c0@t> <32781.204.120.161.2.1074987503.squirrel@webmail.sofast.net> Message-ID: <20040125020437.GA31901@inskipp.digriz.org.uk> --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jan 24, mkazmier@sofast.net wrote: > Thank you for the detailed discussion. There is no doubt that there is a > need for an IMQ type device/funtionality. What would work really great, > IMHO, is a "fake" or psuedo ethernet driver that simply sits as a shim > between one or more real drivers. This fake device could allow us to > "Stack" qdiscs in a way to allow one to shape traffic in multiple > "policies" - ie, prioritize traffic AND allocate / rate shape end users.= =20 > I have actually thought of utilizing the kernel bonding driver for this - > attaching only a single slave to it - but haven't had time as yet. Not > sure that this would do anything for ingress shaping though. >=20 I have been working on this with using what I call a ppp-pipe. The result = is Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8 where ppp0----ppp1 is on the local machine (and simulates two NICs with a= =20 crossover cable between them in the same machine). What you throw in at pp= p0=20 appears at ppp1 and vice versa. This works fine, it also means you can sha= pe=20 on the ppp0/ppp1 interfaces and leave all the NAT stuff on the real=20 interfaces. The command to create this ppp-pipe is (as root), so far I am not completel= y=20 sure if you need to add to the first pppd command ":" for= =20 its parameters (you might also need 'xonxoff' too in both): # mkfifo /tmp/ppp-pipe # pppd noauth nodefaultroute notty < /tmp/ppp-pipe | pppd noauth \ notty > /tmp/ppp-pipe However there is a major problem......connection tracking. In the above=20 setup you do iptables -t nat -I POSTROUTING -s 10.0.0.0/8 \ -d ! 10.0.0.0/8 -o eth0 -j MASQUERADE the '-o eth0' is very important, you also create some advance routing bits = to make all traffic crossing the router to pass through the ppp-pipe; easy enough, but depends on your needs. Conntrack unfortunately notices that you did not want to NAT the packet straight away when it arrives on eth1 (if you do then you will be unable to shape fairly per IP, for example with ESFQ), but then later on when the packet resurfaces at ppp0 the 'nat' table is=20 skipped. The only way about this is to use the patch-o-matic RAW patch and= =20 instruct it to skip connection tracking for packets on eth1 destined for th= e=20 Internet. As I am now pure 2.6.x goodness I am in the middle of porting the patch=20 myself (the patch-o-matic-ng does not work for me, could be me being lame= =20 though). Sure this is replacing one patch dependency with another, however IMQ really seems that it has been left out to rot; whilst the RAW patch probably is going to stay better maintained, hell its in the patch-o-matic for starters= =2E=20 Besides there are lots of advantages with the ppp-pipe, as now all you folks who want to shape over with IP-Aliasing can just use cunning ppp-pipes instead; whilst still keeping things very simple. So far the above should work in non-NAT (or rather connection tracking) setups but where you want t= he equilivent of IP-Aliased style shaping. Anyway thoughts would be apprieated, however when I was on #lartc it was it= s=20 normal dead self so I was left dead in the water myself :( have fun Alex --=20 ___________________________=20 < Fortune favors the lucky. > ---------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAEyQ1Nv5Ugh/sRBYRAqfdAJwOfI5N7Cl+M9X20Kkh3T+oFZ66sQCfStRS hpfBb5mmbOcTpcpWQvGtWtE= =QcOZ -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From roy@xxx.lt Sun Jan 25 03:49:15 2004 From: roy@xxx.lt (Roy) Date: Sun, 25 Jan 2004 05:49:15 +0200 Subject: [LARTC] IMQ Stability References: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> <005a01c3e2d1$337ba7d0$030aa8c0@t> <32781.204.120.161.2.1074987503.squirrel@webmail.sofast.net> <20040125020437.GA31901@inskipp.digriz.org.uk> Message-ID: <007b01c3e2f6$487698f0$030aa8c0@t> Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8 this way dont seem excelent because it still lacks some functionality and what about using LO or dummy type interface instead of ppp? the new imq driver that i am developing will have unlimited posibilities it willbe fake interface wich passes all ip trafic without exception no mater which direction, destination and so on even localy generated and received trafic should pass it I removed iptables module so noo need to configure it just everything is catched. so you will be able to shape in + out in one also I am thinking about the chaining functionality is there any need to make chain of imq devices ? ( they will get the all same trafic) you will be able to use few shapers then but it will add latency. I almost finished my driver , but unfortunately there is no way to avoid patching kernel. I need to export ip_finish_output2 and ip_local_deliver_finish functions but dont know how to do that, and where is the best place. From Aron@sofaware.com Sun Jan 25 08:56:26 2004 From: Aron@sofaware.com (Aron Brand) Date: Sun, 25 Jan 2004 10:56:26 +0200 Subject: [LARTC] IMQ Stability Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE33AE62@mail.sofaware.com> Hi Roy, This is great news!=20 Shaping in+out at once is not always wanted... Usually you want to shape them seperately because each direction has a different bandwidth and limits. So I think it should be optional (i.e. you should be able to configure if you want the ingress and/or the egress side). Your efforts are highly appreciated! Aron ------------------------------------------------------------------------ ----------------------------------- From: "Roy" To: Subject: Re: [LARTC] IMQ Stability Date: Sun, 25 Jan 2004 05:49:15 +0200 Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8 this way dont seem excelent because it still lacks some functionality and what about using LO or dummy type interface instead of ppp? the new imq driver that i am developing will have unlimited posibilities it willbe fake interface wich passes all ip trafic without exception no mater which direction, destination and so on even localy generated and received trafic should pass it I removed iptables module so noo need to configure it just everything is catched. so you will be able to shape in + out in one also I am thinking about the chaining functionality is there any need to make chain of imq devices ? ( they will get the all same trafic) you will be able to use few shapers then but it will add latency. I almost finished my driver , but unfortunately there is no way to avoid patching kernel. I need to export ip_finish_output2 and ip_local_deliver_finish functions but dont know how to do that, and where is the best place. From reza@mra.co.id Sun Jan 25 09:01:03 2004 From: reza@mra.co.id (Muhammad Reza) Date: Sun, 25 Jan 2004 16:01:03 +0700 Subject: [LARTC] htbinit and redhat-9.0 In-Reply-To: <200401231929.47249.stef.coene@docum.org> References: <200401231929.47249.stef.coene@docum.org> Message-ID: <401385CF.10803@mra.co.id> Stef Coene wrote: >On Friday 23 January 2004 18:38, Mohammad Reza wrote: > > >>dear All, >>I'm a new student and my job is too shapping bandwith for our campus >>faculty network. I want to implement htb with Redhat-9.0 distro. >>does this distro kernel support htb and tc good ? or i should apply some >>patch or upgrade kernel ? >> >> >Patch the kernel yourself so you are sure you have the latest htb. > >Stef > > > Hi All.. i'm already start to build shapping with RH-9.0 and htb (htb.init-v0.8.4..actually), tc is support htb my topology like this ISP---eth1-----eth0---LAN 512kbps output from tc. ------------------- #/sbin/htb.init-v0.8.4 compile tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1 htb default 0 r2q 2 tc class add dev eth0 parent 1: classid 1:10 htb rate 512kbps tc class add dev eth0 parent 1:10 classid 1:20 htb rate 256kbps ceil 512kbps tc qdisc add dev eth0 parent 1:20 handle 20 sfq perturb 10 quantum 1500 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.16.0.228/32 classid 1:20 tc class add dev eth0 parent 1:10 classid 1:30 htb rate 128kbps ceil 512kbps tc qdisc add dev eth0 parent 1:30 handle 30 sfq perturb 10 quantum 1500 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.16.0.22/32 classid 1:30 tc class add dev eth0 parent 1:10 classid 1:40 htb rate 128kbps ceil 512kbps tc qdisc add dev eth0 parent 1:40 handle 40 sfq perturb 10 quantum 1500 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.16.0.20/32 classid 1:40 #/sbin/htb.init-v0.8.4 stats ### eth0: queueing disciplines qdisc sfq 40: quantum 1500b perturb 10sec Sent 95338 bytes 529 pkts (dropped 0, overlimits 0) qdisc sfq 30: quantum 1500b perturb 10sec Sent 86915 bytes 136 pkts (dropped 0, overlimits 0) qdisc sfq 20: quantum 1500b perturb 10sec Sent 5835201 bytes 78341 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 2 default 0 direct_packets_stat 45 Sent 6019344 bytes 79051 pkts (dropped 0, overlimits 0) ### eth0: traffic classes class htb 1:10 root rate 4Mbit ceil 4Mbit burst 6841b cburst 6841b Sent 6019972 bytes 79025 pkts (dropped 0, overlimits 0) rate 23bps lended: 0 borrowed: 0 giants: 0 tokens: 10317 ctokens: 10317 class htb 1:20 parent 1:10 leaf 20: prio 0 rate 2Mbit ceil 4Mbit burst 4220b cburst 6841b Sent 5837719 bytes 78360 pkts (dropped 0, overlimits 0) lended: 78360 borrowed: 0 giants: 0 tokens: 12441 ctokens: 10317 class htb 1:30 parent 1:10 leaf 30: prio 0 rate 1Mbit ceil 4Mbit burst 2909b cburst 6841b Sent 86915 bytes 136 pkts (dropped 0, overlimits 0) lended: 136 borrowed: 0 giants: 0 tokens: 8888 ctokens: 8366 class htb 1:40 parent 1:10 leaf 40: prio 0 rate 1Mbit ceil 4Mbit burst 2909b cburst 6841b Sent 95338 bytes 529 pkts (dropped 0, overlimits 0) rate 15bps lended: 529 borrowed: 0 giants: 0 tokens: 16688 ctokens: 10316 ### eth0: filtering rules filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:20 match ac1000e4/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:30 match ac100016/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:40 match ac100014/ffffffff at 16 When i tried to check with iperf from 172.16.0.228 (classid 10:20 with 256kbps rate). $ ./iperf -c 172.16.0.232 ------------------------------------------------------------ Client connecting to 172.16.0.232, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 5] local 172.16.0.228 port 49385 connected with 172.16.0.232 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0-10.0 sec 112 MBytes 93.9 Mbits/sec I didnt see bandwith rate that i expected..is there something wrong with my config.. please help me.... From tc@me.net.ng Sun Jan 25 23:33:45 2004 From: tc@me.net.ng (tc) Date: Mon, 26 Jan 2004 00:33:45 +0100 Subject: [LARTC] IMQ Runtime error Message-ID: <1075073625.40145259a53ea@mail.psnet.gov.ng> hi all, i have applied all patches and compiled the kernel (2.4.21), iptables (1.2.9) and iproute2 (2.4.7-now-ss020116) however when i run "modprobe imq numdevs=1", the system returns - imq.o: init_module: Device or resource busy the transcript is below - [root@vmlinux project]# modprobe imq numdevs=1 /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: init_module: Device or resource busy Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o failed /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod imq failed what could be wrong? thanks all, bye joseph From roy@xxx.lt Mon Jan 26 00:50:25 2004 From: roy@xxx.lt (Roy) Date: Mon, 26 Jan 2004 02:50:25 +0200 Subject: [LARTC] IMQ Runtime error References: <1075073625.40145259a53ea@mail.psnet.gov.ng> Message-ID: <003901c3e3a6$68de9600$030aa8c0@t> even if imq is quite useless right now this eeror is caused probably by other loaded modules for userspace queue nf_queue probably since imq uses the same function ----- Original Message ----- From: "tc" To: Sent: Monday, January 26, 2004 1:33 AM Subject: [LARTC] IMQ Runtime error > hi all, i have applied all patches and compiled the kernel > (2.4.21), iptables > (1.2.9) and iproute2 (2.4.7-now-ss020116) however when i run '"'modprobe imq > numdevs=1'"', the system returns - imq.o: init_module: Device or resource busy > > the transcript is below - > > [root@vmlinux project]# modprobe imq numdevs=1 > /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: init_module: Device or resource > busy > Hint: insmod errors can be caused by incorrect module parameters, including > invalid IO or IRQ parameters. > You may find more information in syslog or the output from dmesg > /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod > /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o failed > /lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod imq failed > > what could be wrong? thanks all, > bye > joseph > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From lartc@nikhiljogia.com Mon Jan 26 08:22:15 2004 From: lartc@nikhiljogia.com (Nikhil Jogia) Date: Mon, 26 Jan 2004 16:22:15 +0800 Subject: [LARTC] Re: Problems with netfilter Message-ID: I have fixed half of the problem with: iptables -A OUTPUT -t mangle -p tcp --dport 25 -j MARK --set-mark 25 ip rule add fwmark 25 lookup mail ip route add default via xxx.xxx.xxx.xxx dev ppp0 table mail Running tcpdump it appears that port 25 traffic is be routed through the ADSL connection. However, the source IP address appears to be the cable IP address (cable is the default gateway). I have put SNAT rules in place, however they don't seem to work. The SNAT rules I used were: iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to yyy.yyy.yyy.yyy and the same thing with the cable connection. Rememeber, the packets are being generated locally through the mail server (qmail). --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.563 / Virus Database: 355 - Release Date: 17/01/2004 From rmocius@auste.elnet.lt Mon Jan 26 10:36:04 2004 From: rmocius@auste.elnet.lt (Remus) Date: Mon, 26 Jan 2004 10:36:04 -0000 Subject: [LARTC] IMQ Stability References: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> <005a01c3e2d1$337ba7d0$030aa8c0@t> <32781.204.120.161.2.1074987503.squirrel@webmail.sofast.net> <20040125020437.GA31901@inskipp.digriz.org.uk> <007b01c3e2f6$487698f0$030aa8c0@t> Message-ID: <0c7a01c3e3f8$450b0310$6e69690a@RIMAS> Hi Roy, Excelent Roy!!! Good job. Where we can get your IMQ port to test? Best Regards Remus ----- Original Message ----- From: "Roy" To: Sent: Sunday, January 25, 2004 3:49 AM Subject: Re: [LARTC] IMQ Stability > Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8 > > > this way dont seem excelent because it still lacks some functionality > and what about using LO or dummy type interface instead of ppp? > > the new imq driver that i am developing will have unlimited posibilities > it willbe fake interface wich passes all ip trafic without exception no > mater which direction, destination and so on > even localy generated and received trafic should pass it > I removed iptables module so noo need to configure it just everything is > catched. > so you will be able to shape in + out in one > > also I am thinking about the chaining functionality > is there any need to make chain of imq devices ? ( they will get the all > same trafic) > you will be able to use few shapers then but it will add latency. > > I almost finished my driver , but unfortunately there is no way to avoid > patching kernel. > > I need to export ip_finish_output2 and ip_local_deliver_finish functions but > dont know how to do that, and where is the best place. > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From gomi@perezoso.net Mon Jan 26 12:49:25 2004 From: gomi@perezoso.net (GoMi) Date: Mon, 26 Jan 2004 13:49:25 +0100 Subject: [LARTC] Maximum number of paralel connections Message-ID: =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was wondering, most of the p2p programs are bandwith wasters, because = they open lots of parallel connections.=20 I have 5 queues to prioritize traffic, but these p2p open thousands of = connections and my systems gets REALLY HIGH latence. Does anybody of you know by any means, for a DSL connections, the = ammount of parallel connections for a good rate of utilization? That way = i can limit with netfilter the ammount of parallel connections assigned = to each user. Just wondering... :) -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQBUM1H7diNnrrZKsEQIb1wCeMLGhRi8CKZFZUXycRpV2fjYx1LwAnjqS Qx6wtyiPeY4L+FOnwg1s8CwR =3DjWzC -----END PGP SIGNATURE----- From rubens@etica.net Mon Jan 26 14:38:00 2004 From: rubens@etica.net (rubens@etica.net) Date: Mon, 26 Jan 2004 12:38:00 -0200 (BRST) Subject: [LARTC] Re: Problems with netfilter In-Reply-To: Message-ID: > iptables -A OUTPUT -t mangle -p tcp --dport 25 -j MARK --set-mark 25 > ip rule add fwmark 25 lookup mail > ip route add default via xxx.xxx.xxx.xxx dev ppp0 table mail > > Running tcpdump it appears that port 25 traffic is be routed through the > ADSL connection. However, the source IP address appears to be the cable IP Correct routing is kinda odd in this case, as IPTABLES OUTPUT happens after OUTPUT ROUTING, according to KPTD (http://www.docum.org/stef.coene/qos/kptd). > address (cable is the default gateway). I have put SNAT rules in place, > however they don't seem to work. > > The SNAT rules I used were: > > iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to yyy.yyy.yyy.yyy > and the same thing with the cable connection. > > Rememeber, the packets are being generated locally through the mail server > (qmail). IPTABLES POSTROUTING happens for both locally originated and forwarded traffic (see KPTD); it should have worked. Anyway, binding the mail server to the intended IP address (by adding it to the tcpserver call) should also do this part of the job. Rubens From andy.furniss@dsl.pipex.com Mon Jan 26 15:09:29 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 26 Jan 2004 15:09:29 +0000 Subject: [LARTC] IMQ Runtime error In-Reply-To: <003901c3e3a6$68de9600$030aa8c0@t> References: <1075073625.40145259a53ea@mail.psnet.gov.ng> <003901c3e3a6$68de9600$030aa8c0@t> Message-ID: <40152DA9.2030004@dsl.pipex.com> Roy wrote: > even if imq is quite useless right now I thought it was OK for inbound traffic. What sort of load/traffic do you see crashes with. I have an old P200 as a gateway and can run bittorrents on it, with IMQ doing outbound for locally generated traffic (not that I really need to) and can do > a gig/day without ever crashing. I do close down at night though, and only have 256/512 bandwidth. Is this way below what you need to do to crash? > this eeror is caused probably by other loaded modules for userspace queue > nf_queue probably > since imq uses the same function Yea this is a pain, I would like to run a userspace for up and IMQ for down, but can't use lib_ipq at the same time as IMQ. It has been suggested that I can work round this, but I haven't tried yet. Do you think it's possible? Andy. > ----- Original Message ----- > From: "tc" > To: > Sent: Monday, January 26, 2004 1:33 AM > Subject: [LARTC] IMQ Runtime error > > > >>hi all, i have applied all patches and compiled the kernel >>(2.4.21), iptables >>(1.2.9) and iproute2 (2.4.7-now-ss020116) however when i run '"'modprobe > > imq > >>numdevs=1'"', the system returns - imq.o: init_module: Device or resource > > busy > >>the transcript is below - >> >>[root@vmlinux project]# modprobe imq numdevs=1 >>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: init_module: Device or > > resource > >>busy >>Hint: insmod errors can be caused by incorrect module parameters, > > including > >>invalid IO or IRQ parameters. >> You may find more information in syslog or the output from dmesg >>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod >>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o failed >>/lib/modules/2.4.21-BW/kernel/drivers/net/imq.o: insmod imq failed >> >>what could be wrong? thanks all, >>bye >>joseph >>_______________________________________________ >>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@nikhiljogia.com Mon Jan 26 15:42:15 2004 From: lartc@nikhiljogia.com (Nikhil Jogia) Date: Mon, 26 Jan 2004 23:42:15 +0800 Subject: [LARTC] Re: Problems with netfilter In-Reply-To: Message-ID: PROBLEM SOLVED! I didn't have to bind the output to the mail server. The problem was that I didn't have a SNAT rule for eth0 (the network interface attached to the ADSL modem). Thank god for that! > iptables -A OUTPUT -t mangle -p tcp --dport 25 -j MARK --set-mark 25 > ip rule add fwmark 25 lookup mail > ip route add default via xxx.xxx.xxx.xxx dev ppp0 table mail > > Running tcpdump it appears that port 25 traffic is be routed through the > ADSL connection. However, the source IP address appears to be the cable IP Correct routing is kinda odd in this case, as IPTABLES OUTPUT happens after OUTPUT ROUTING, according to KPTD (http://www.docum.org/stef.coene/qos/kptd). > address (cable is the default gateway). I have put SNAT rules in place, > however they don't seem to work. > > The SNAT rules I used were: > > iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to yyy.yyy.yyy.yyy > and the same thing with the cable connection. > > Rememeber, the packets are being generated locally through the mail server > (qmail). IPTABLES POSTROUTING happens for both locally originated and forwarded traffic (see KPTD); it should have worked. Anyway, binding the mail server to the intended IP address (by adding it to the tcpserver call) should also do this part of the job. Rubens --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.563 / Virus Database: 355 - Release Date: 17/01/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.563 / Virus Database: 355 - Release Date: 17/01/2004 From mkazmier@sofast.net Mon Jan 26 15:53:28 2004 From: mkazmier@sofast.net (Michael S. Kazmier) Date: Mon, 26 Jan 2004 08:53:28 -0700 Subject: [LARTC] IMQ Stability In-Reply-To: <20040125020437.GA31901@inskipp.digriz.org.uk> Message-ID: <002601c3e424$8a1148d0$b53afea9@kazvx88> Hello Alex, Perhaps I missed something below which ties eth0 and eth1 to the PPP = pipe, or its just my unfamiliarity with PPP. Regardless, an interesting methodology. Do you think you could do the following: --------------=20 The reason I ask is that I would like to, at the PPP level, apply CBQ or = HTB rate shaping to my each end user (ie, limit traffic to 256K or something like that). And then, after each customer has their rate shaping, at = the ETH level I would like to priorize traffic (ie, all www prio 3, ssh - telnet, prio 1, ftp prio 4, everything else prio 7) Thoughts? -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] = On Behalf Of Alexander Clouter Sent: Saturday, January 24, 2004 7:05 PM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] IMQ Stability On Jan 24, mkazmier@sofast.net wrote: > Thank you for the detailed discussion. There is no doubt that there = is a > need for an IMQ type device/funtionality. What would work really = great, > IMHO, is a "fake" or psuedo ethernet driver that simply sits as a shim > between one or more real drivers. This fake device could allow us to > "Stack" qdiscs in a way to allow one to shape traffic in multiple > "policies" - ie, prioritize traffic AND allocate / rate shape end = users.=20 > I have actually thought of utilizing the kernel bonding driver for = this - > attaching only a single slave to it - but haven't had time as yet. = Not > sure that this would do anything for ingress shaping though. >=20 I have been working on this with using what I call a ppp-pipe. The = result is Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8 where ppp0----ppp1 is on the local machine (and simulates two NICs with = a=20 crossover cable between them in the same machine). What you throw in at ppp0=20 appears at ppp1 and vice versa. This works fine, it also means you can shape=20 on the ppp0/ppp1 interfaces and leave all the NAT stuff on the real=20 interfaces. The command to create this ppp-pipe is (as root), so far I am not = completely sure if you need to add to the first pppd command ":" = for=20 its parameters (you might also need 'xonxoff' too in both): # mkfifo /tmp/ppp-pipe # pppd noauth nodefaultroute notty < /tmp/ppp-pipe | pppd noauth \ notty > /tmp/ppp-pipe However there is a major problem......connection tracking. In the above = setup you do iptables -t nat -I POSTROUTING -s 10.0.0.0/8 \ -d ! 10.0.0.0/8 -o eth0 -j MASQUERADE the '-o eth0' is very important, you also create some advance routing = bits to make all traffic crossing the router to pass through the ppp-pipe; easy enough, but depends on your needs. Conntrack unfortunately notices that = you did not want to NAT the packet straight away when it arrives on eth1 (if = you do then you will be unable to shape fairly per IP, for example with = ESFQ), but then later on when the packet resurfaces at ppp0 the 'nat' table is=20 skipped. The only way about this is to use the patch-o-matic RAW patch = and=20 instruct it to skip connection tracking for packets on eth1 destined for = the Internet. As I am now pure 2.6.x goodness I am in the middle of porting the patch=20 myself (the patch-o-matic-ng does not work for me, could be me being = lame=20 though). Sure this is replacing one patch dependency with another, however IMQ = really seems that it has been left out to rot; whilst the RAW patch probably is going to stay better maintained, hell its in the patch-o-matic for = starters. Besides there are lots of advantages with the ppp-pipe, as now all you = folks who want to shape over with IP-Aliasing can just use cunning ppp-pipes instead; whilst still keeping things very simple. So far the above = should work in non-NAT (or rather connection tracking) setups but where you = want the equilivent of IP-Aliased style shaping. Anyway thoughts would be apprieated, however when I was on #lartc it was = its normal dead self so I was left dead in the water myself :( have fun Alex --=20 ___________________________=20 < Fortune favors the lucky. > ---------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || From rubens@etica.net Mon Jan 26 18:49:08 2004 From: rubens@etica.net (rubens@etica.net) Date: Mon, 26 Jan 2004 16:49:08 -0200 (BRST) Subject: [LARTC] IMQ Stability In-Reply-To: <007b01c3e2f6$487698f0$030aa8c0@t> Message-ID: > the new imq driver that i am developing will have unlimited posibilities > it willbe fake interface wich passes all ip trafic without exception no > mater which direction, destination and so on > even localy generated and received trafic should pass it May I suggest that if it's new code with new approach it should get a different name ? Rubens From jradke@canbytel.com Mon Jan 26 22:42:27 2004 From: jradke@canbytel.com (jradke@canbytel.com) Date: Mon, 26 Jan 2004 14:42:27 -0800 Subject: [LARTC] Help with a simple config Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E45D.AC8F74C0 Content-Type: text/plain Here's the scenario: - 4 NIC's; 1 Upstream, 3 subscribers each with different rates. NIC-1: NO CAP simply 100mbit I want to cap the traffic on each of the subscriber NIC's to a specific rate i.e.: - NIC-2: 8mbit - NIC-3: 5mbit - NIC-4: 3mbit Just to summarize, ALL I'm trying to do is limit the bandwidth on each NIC (ingress & egress) whether it is 10/100/1000Base-T. Right now I am using a Cisco using rate-limiting which is very simple. I'd like to perform this task on Linux box for easier scalibility and as a backup. Thanks for your assistance! -JGR ------_=_NextPart_001_01C3E45D.AC8F74C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Help with a simple config

Here's the scenario:
- 4 NIC's; 1 Upstream, 3 subscribers each with = different rates.

NIC-1: NO CAP simply 100mbit
I want to cap the traffic on each of the subscriber = NIC's to a specific rate i.e.:
    - NIC-2: 8mbit
    - NIC-3: 5mbit
    - NIC-4: 3mbit

Just to summarize, ALL I'm trying to do is limit the = bandwidth on each NIC (ingress & egress) whether it is = 10/100/1000Base-T. Right now I am using a Cisco using rate-limiting = which is very simple. I'd like to perform this task on Linux box for = easier scalibility and as a backup.

Thanks for your assistance!

-JGR

------_=_NextPart_001_01C3E45D.AC8F74C0-- From jradke@canbytel.com Mon Jan 26 22:39:47 2004 From: jradke@canbytel.com (jradke@canbytel.com) Date: Mon, 26 Jan 2004 14:39:47 -0800 Subject: [LARTC] I can't get TCNG to compile!!! Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E45D.4D33D5C0 Content-Type: text/plain Help! I can't get TCNG to compile!!! It did this on 2 different machines! Here are the errors: -------------------------------------------- Kernel: 2.4.22 [root@localhost tcng]# uname -a Linux localhost.localdomain 2.4.22-1.2149.nptl #1 Wed Jan 7 13:08:26 EST #if KFULLVERSIONNUM >= 0x20416 /* gratuitous interface change in 2.4.22 :-( */ ERROR: ake -f Makefile.unclean tcsim make[2]: Entering directory `/home/jradke/tcng/tcsim' cc -E -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -I../shared -Iklib -Iklib/include -Iulib/iproute2/include -I. -DVERSION=\"`cat ../VERSION`\" -DTOPDIR=\"/home/jradke/tcng\" -DTCC_CMD=\"/home/jradke/tcng/bin/tcc\" -DKFULLVERSION=\"2.4.22-1.2149.nptlcustom\" -DKFULLVERSIONNUM=`printf "0x%02x%02x%02x" 2 4 22`-1.2149.nptlcustom -DIVERSION=\"010824\" -I. -M *.c >.depend || \ { rm -f .depend; exit 1; } trace.c:41:5: too many decimal points in number make[2]: *** [.depend] Error 1 make[2]: Leaving directory `/home/jradke/tcng/tcsim' make[1]: *** [tcsim] Error 2 make[1]: Leaving directory `/home/jradke/tcng/tcsim' make: *** [all] Error 1 -------------------------------------------- Kernel: 2.6.1 ERROR: klib/include/linux/errno.h:4:31: asm-generic/errno.h: No such file or directory make[2]: *** [.depend] Error 1 make[2]: Leaving directory `/home/jradke/tcng/tcsim' make[1]: *** [tcsim] Error 2 make[1]: Leaving directory `/home/jradke/tcng/tcsim' make: *** [all] Error 1 ------_=_NextPart_001_01C3E45D.4D33D5C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable I can't get TCNG to compile!!!

Help! I can't get TCNG to compile!!! It did this on 2 = different machines! Here are the errors:
 
--------------------------------------------
Kernel: 2.4.22
[root@localhost tcng]# uname -a
Linux localhost.localdomain 2.4.22-1.2149.nptl #1 = Wed Jan 7 13:08:26 EST

#if KFULLVERSIONNUM >=3D 0x20416  /* = gratuitous interface change in 2.4.22 :-(
*/
ERROR:
ake -f Makefile.unclean tcsim
make[2]: Entering directory = `/home/jradke/tcng/tcsim'
cc -E -g -Wall -Wstrict-prototypes = -Wmissing-prototypes -Wmissing-declarations -I../shared -Iklib = -Iklib/include -Iulib/iproute2/include -I. -DVERSION=3D\"`cat = ../VERSION`\" -DTOPDIR=3D\"/home/jradke/tcng\" = -DTCC_CMD=3D\"/home/jradke/tcng/bin/tcc\" = -DKFULLVERSION=3D\"2.4.22-1.2149.nptlcustom\" = -DKFULLVERSIONNUM=3D`printf "0x%02x%02x%02x" 2 4 = 22`-1.2149.nptlcustom -DIVERSION=3D\"010824\" -I. -M *.c = >.depend || \

          &nb= sp;       { rm -f .depend; exit 1; = }
trace.c:41:5: too many decimal points in = number
make[2]: *** [.depend] Error 1
make[2]: Leaving directory = `/home/jradke/tcng/tcsim'
make[1]: *** [tcsim] Error 2
make[1]: Leaving directory = `/home/jradke/tcng/tcsim'
make: *** [all] Error 1


--------------------------------------------
Kernel: 2.6.1
ERROR:

klib/include/linux/errno.h:4:31: asm-generic/errno.h: = No such file or directory
make[2]: *** [.depend] Error 1
make[2]: Leaving directory = `/home/jradke/tcng/tcsim'
make[1]: *** [tcsim] Error 2
make[1]: Leaving directory = `/home/jradke/tcng/tcsim'
make: *** [all] Error 1
 

 
 

------_=_NextPart_001_01C3E45D.4D33D5C0-- From rubens@etica.net Mon Jan 26 22:57:30 2004 From: rubens@etica.net (rubens@etica.net) Date: Mon, 26 Jan 2004 20:57:30 -0200 (BRST) Subject: [LARTC] I can't get TCNG to compile!!! In-Reply-To: Message-ID: ./configure --no-tcsim will make your life easier if you just want tcc (compiler) not tcsim (simulator) Rubens On Mon, 26 Jan 2004 jradke@canbytel.com wrote: > Help! I can't get TCNG to compile!!! It did this on 2 different machines! > Here are the errors: > > -------------------------------------------- > Kernel: 2.4.22 > [root@localhost tcng]# uname -a > Linux localhost.localdomain 2.4.22-1.2149.nptl #1 Wed Jan 7 13:08:26 EST > > #if KFULLVERSIONNUM >= 0x20416 /* gratuitous interface change in 2.4.22 :-( > */ > ERROR: > ake -f Makefile.unclean tcsim > make[2]: Entering directory `/home/jradke/tcng/tcsim' > cc -E -g -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -I../shared -Iklib -Iklib/include > -Iulib/iproute2/include -I. -DVERSION=\"`cat ../VERSION`\" > -DTOPDIR=\"/home/jradke/tcng\" -DTCC_CMD=\"/home/jradke/tcng/bin/tcc\" > -DKFULLVERSION=\"2.4.22-1.2149.nptlcustom\" -DKFULLVERSIONNUM=`printf > "0x%02x%02x%02x" 2 4 22`-1.2149.nptlcustom -DIVERSION=\"010824\" -I. -M *.c > >.depend || \ > { rm -f .depend; exit 1; } > trace.c:41:5: too many decimal points in number > make[2]: *** [.depend] Error 1 > make[2]: Leaving directory `/home/jradke/tcng/tcsim' > make[1]: *** [tcsim] Error 2 > make[1]: Leaving directory `/home/jradke/tcng/tcsim' > make: *** [all] Error 1 > > > -------------------------------------------- > Kernel: 2.6.1 > ERROR: > > klib/include/linux/errno.h:4:31: asm-generic/errno.h: No such file or > directory > make[2]: *** [.depend] Error 1 > make[2]: Leaving directory `/home/jradke/tcng/tcsim' > make[1]: *** [tcsim] Error 2 > make[1]: Leaving directory `/home/jradke/tcng/tcsim' > make: *** [all] Error 1 > > > > > From mihaivlad@web-profile.net Mon Jan 26 23:04:58 2004 From: mihaivlad@web-profile.net (Mihai Vlad) Date: Tue, 27 Jan 2004 01:04:58 +0200 Subject: [LARTC] R2Q Message-ID: <20040126233508.9F4C03FC8@outpost.ds9a.nl> Hello again, I need to change the R2Q for my script, as setting the quantum manually for each class is painful. Can you tell me exactly where to set R2Q = x? I get syntax errors all the time. Should it be specified for each class? I do not know where to place this setting... Thanks in advance, Vlad Mihai From roy@xxx.lt Mon Jan 26 23:47:17 2004 From: roy@xxx.lt (Roy) Date: Tue, 27 Jan 2004 01:47:17 +0200 Subject: [LARTC] NEW imq driver References: Message-ID: <002a01c3e466$bb7f8700$030aa8c0@t> Finaly I made imq driver stable it did not crashed for all 5 hours under high load, soo looks stable. (old one was crashing after 1-5 min for me) no need to patch anything just compile and insmod, should work with any kernel probably must be > than 2.4.20 This is completely diferent code than old imq. you can find it on my server http://pupa.da.ru please tell how it works for you and how stable it is. From andy.furniss@dsl.pipex.com Mon Jan 26 23:54:33 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Mon, 26 Jan 2004 23:54:33 +0000 Subject: [LARTC] HTB/SFQ dequeueing in pairs Message-ID: <4015A8B9.1010100@dsl.pipex.com> I set up a little test to see what the behaviour of (e)sfq was - because I couldn't work it out from the source :-) . I wanted to see where from a slot the packets got dropped when the queue was full. (e)sfq drops from the longest slot to make space for an incoming packet, so it's not tail drop as such, but the results show me it does drop from the tail of the slot - which if you are trying to shape inbound, is a PITA as tcp "slow" start grows exponentially and overflows into my ISP/telecos buffer, causing a latency bump. I think it would be alot nicer if It head dropped to make the sender go into congestion control quicker. However this is not the reason for this post. I tested by capturing with tcpdump before and after the queue. I noticed that the packets were being released in pairs, which probably doesn't help either. I assume it is htb that calls esfq to dequeue a packet - but I don't know. For the test my DWIFLIMIT bandwidth was set at 51kbit/s which is 10% of my bandwidth. My mtu is set at 1478 as it's slightly more efficient for adsl using pppoa/vcmux in the UK. I used - $TC class add dev $DWIF parent 1:2 classid 1:21 htb rate $[$DWIFLIMIT/2]kbit \ ceil ${DWIFLIMIT}kbit burst 0b cburst 0b mtu 1478 quantum 1478 prio 1 $TC qdisc add dev $DWIF parent 1:21 handle 21: esfq perturb 0 hash classic limit 10 This is part of tc -s -d class show dev imq1 class htb 1:21 parent 1:2 leaf 21: prio 1 quantum 1478 rate 25Kbit ceil 51Kbit burst 1507b/8 mpu 0b cburst 1540b/8 mpu 0b level 0 Is there anything obvious here that would cause the packets to dequeue in pairs. TIA Andy. From mkazmier@sofast.net Tue Jan 27 00:07:27 2004 From: mkazmier@sofast.net (Michael S. Kazmier) Date: Mon, 26 Jan 2004 17:07:27 -0700 Subject: [LARTC] Filter not listed for firewall filter - and not running! Message-ID: <538101c3e469$8cbab090$b53afea9@kazvx88> Hello all, I am having some trouble getting a firewall filter to work with TC. I = am actually setting the mark via EBTables (which is working as far as I can tell, I am also logging the packet and my syslog reports lots of marks): ebtables -t broute -A BROUTING -p ipv4 -i eth1 -s 08:00:46:60:B3:57 -j = mark --set-mark 7 --mark-target CONTINUE --log --log-level debug --log-prefix "EBFW Mark 7" Now, with the marked packet, I want to rate shape it on ETH0 on its way = out. tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 1000 = cell 8 tc class change dev eth0 root cbq weight 10Mbit allot 1514 tc class add dev eth0 parent 1: classid 1:2500 cbq bandwidth 100Mbit = rate 1512Kbit weight 51Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded tc qdisc add dev eth0 parent 1:2500 handle 2500 sfq perturb 10 tc class add dev eth0 parent 1:2500 classid 1:3500 cbq bandwidth 100Mbit rate 256Kbit weight 26Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt = 1000 bounded tc qdisc add dev eth0 parent 1:3500 handle 3500 sfq perturb 10 tc filter add dev eth0 parent 1:2500 protocol ip prio 100 handle 7 fw = flowid 1:3500 But the problem is, when I look at stats, my 3500 queue has no traffic = and my filters are blank, I run a " tc filter show dev eth0" and its empty. = I have various u32 filters on eth1 and they show up. If add: tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 0.0.0.0/0 classid 1:2500 I can now see that I have filters on eth0 [root@cbq]# tc filter show dev eth0 [root@cbq]# tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 = match ip dst 0.0.0.0/0 classid 1:2500 [root@cbq]# tc filter show dev eth0 filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht = 800 bkt 0 flowid 1:2500 match 00000000/00000000 at 16 [root@cbq]# What am I missing here??? Thanks, Mike From alex-lartc@digriz.org.uk Tue Jan 27 00:39:52 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Tue, 27 Jan 2004 00:39:52 +0000 Subject: [LARTC] IMQ Stability In-Reply-To: <002601c3e424$8a1148d0$b53afea9@kazvx88> References: <20040125020437.GA31901@inskipp.digriz.org.uk> <002601c3e424$8a1148d0$b53afea9@kazvx88> Message-ID: <20040127003952.GF14211@inskipp.digriz.org.uk> --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jan 26, Michael S. Kazmier wrote: > Hello Alex, >=20 > Perhaps I missed something below which ties eth0 and eth1 to the PPP pipe, > or its just my unfamiliarity with PPP. >=20 sorry I should of made it cleaner. If you read up on Advanced Routing HOWT= O,=20 its hopefully easy to understand. lets say: ------------ alex@inskipp:~$ cat /etc/iproute2/rt_tables=20 # # reserved values # 255 local 254 main 253 default 0 unspec # # local # 1 inr.ruhep # inskipp 32 ppp-upstream 33 ppp-downstream ------------ you then type (something along the lines of): --------- ip route add default dev ppp1 table ppp-upstream ip route add default dev ppp0 table ppp-downstream ip rule add from 10.0.0.0/8 iif eth1 table ppp-upstream ip rule add to 10.0.0.0/8 iif eth0 table ppp-downstream ip route flush cache --------- In summary, this setups linux to do exactly what is in the diagram (below).= =20 The nice thing is after the above is setup you treat it as if its a physica= l=20 interface, its a real ppp session. Any traffic that goes into ppp0 appears= =20 on ppp1 and vice versa; treat it like a fancy wormhole :) The advantage here over the IMQ-ng that is being made, from what I uderstan= d,=20 is here the only patch you need is to bypass connection tracking on the=20 Internet bound traffic from eth1 (for techie reasons), when it 'appears' fr= om=20 ppp1 then the connection tracking should be allowed to continue. This is= =20 where the RAW netfilter patch comes into play. Although you are swapping one kernel patch for another, the RAW one looks= =20 like its going to be around much longer and actually maintained, the other= =20 very important fact is that you can now (if you think about it, I will leav= e=20 it as an exercise for you) use it to simulate those IP-Aliasing interfaces= =20 and actually now shape on that basis per pipe. The clue is true _source_= =20 based routing ;) > Regardless, an interesting methodology. Do you think you could do the > following: >=20 > --------------= =20 >=20 > The reason I ask is that I would like to, at the PPP level, apply CBQ or = HTB > rate shaping to my each end user (ie, limit traffic to 256K or something > like that). And then, after each customer has their rate shaping, at the > ETH level I would like to priorize traffic (ie, all www prio 3, ssh - > telnet, prio 1, ftp prio 4, everything else prio 7) >=20 > Thoughts? >=20 in theory I guess you could setup a linu bridge over the ppp-pipe, however= =20 there is no point (from what I can see) as you are NATing, so the box is th= e=20 default gateway for the other machines, plus more importantly, if you want = a=20 bridge why not just forget about the ppp-pipe and bridge over eth0<->eth1. = =20 This is what my jdg-qos-script[1] from more or less day one. Anyway, feedback would be great on the above idea. Regards Alex [1] http://www.digriz.org.uk/jdg-qos-script/ --=20 _________________=20 / Genius is pain. \ | | \ -- John Lennon / -----------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAFbNYNv5Ugh/sRBYRAkiEAJ48TiGkTL1wf6hbnAbtL+zt+7sL1QCcDQH2 TgPAGXiI2XzZ2rkvaLcaTEE= =viSM -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX-- From roy@xxx.lt Tue Jan 27 02:03:39 2004 From: roy@xxx.lt (Roy) Date: Tue, 27 Jan 2004 04:03:39 +0200 Subject: [LARTC] connbytes and connmark References: <538101c3e469$8cbab090$b53afea9@kazvx88> Message-ID: <007f01c3e479$ccb55f00$030aa8c0@t> I need them both but POM fefuses to include them in kennes saying that they are incompatible what is that nonsense? anybody have them both at once? From rubens@etica.net Tue Jan 27 03:56:35 2004 From: rubens@etica.net (rubens@etica.net) Date: Tue, 27 Jan 2004 01:56:35 -0200 (BRST) Subject: [LARTC] NEW imq driver In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t> Message-ID: > Finaly I made imq driver stable it did not crashed for all 5 hours under > high load, soo looks stable. > (old one was crashing after 1-5 min for me) It seems to capture ingress and egress traffic of all interfaces; wouldn't this count packets twice ? If the machine is doing SNAT or DNAT, what IP addresses would be seen by the qdisc ? Rubens From roy@xxx.lt Tue Jan 27 04:42:29 2004 From: roy@xxx.lt (Roy) Date: Tue, 27 Jan 2004 06:42:29 +0200 Subject: [LARTC] NEW imq driver References: Message-ID: <009201c3e48f$fcd5eb80$030aa8c0@t> Seems I was to fast to declare success, my version is not much more stable than the original one,everything depends on dropped packets. This is even not imq fault afterall, can be prowed in other way also: atempts to police outgoing trafic it will be ok until you dont touch localy generated packets if you try to drop them you will be sorry, because kernel will resend then together with new ones of cource policer will drop them too, but linux kernel keeps resending then thus increasing rate progresively. I noticed that with my trafic counter. internal trafic grew to enormous levels 10X more than it can be. In reality there was almost no output at all. so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s it probably can kill computer (not tested). Seems imq have similar problem even if driver itself have no leaks kernel consumes all resousces on resnending droped packets so that computer stops responding for now I dont have good idea how to fix it so I will try to avoid localy generated trafic so it will me possible to shape ingress and forward, egress will be left for real device. maybe later I will find how fix that > > It seems to capture ingress and egress traffic of all interfaces; wouldn't > this count packets twice ? No, ingress is for local and egress for everything so everything should be ok (in theory) > If the machine is doing SNAT or DNAT, what IP addresses would be seen by > the qdisc ? > I made driver see the final destination address because it is more usefull > Rubens > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From mrenzmann@otaku42.de Tue Jan 27 04:33:09 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Tue, 27 Jan 2004 05:33:09 +0100 Subject: [LARTC] NEW imq driver In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t> References: <002a01c3e466$bb7f8700$030aa8c0@t> Message-ID: <4015EA05.5080105@otaku42.de> Hi. Roy wrote: > Finaly I made imq driver stable [...] > This is completely diferent code than old imq. May I then second the proposal to give the driver another name? How about IMQ2, IMQng (next generation) or something like that? Bye, Mike From jayesh_rathod@sify.com Tue Jan 27 06:20:26 2004 From: jayesh_rathod@sify.com (jayesh rathod) Date: Tue, 27 Jan 2004 12:20:26 +0600 (IST) Subject: [LARTC] 1000's of classes and filters Message-ID: <1075186226.40160a32c8c2e@webmail1.maa.sify.net> Hi , Let me rephrase my problem with more details and some history. We are running an application on a system which does NAT'ting and shaping. TC and iptable rules are added and deleted at runtime. A TC rule will be, tc class add dev eth1 parent 1:1 classid 1:5001 htb rate 256kbit ceil 256kbit tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 10.1.1.1 match ip flowid 1:5001 At peak some 700 to 800 such rules will be present. Same rules for the other inteface. Deleting a rule is flush out all the rules and reapply :) ( handler could have been used to delete a particular rule, but we have not yet upgraded ) We had ext3 filesystem installed at he beginning. But regularly the box would go down with a kernel panic. The stack trace when this occured is attached. We then moved to resiserfs filesystem. This time although there was no kernel panic, the box hanged with junk messages printed in all our application logs. The box doesnt even respond on the console. Hard reboot is the only thing we can do. Pls find all the details given below. Any suggestions/solutions are welcome. Regards Jayesh System details : Kernel version : 2.4.23 HTB init, kernel part version 3.13 SCSI Adaptec storage controllers 1 GB RAM lspci ----------- 00:00.0 Host bridge: Intel Corp.: Unknown device 254c (rev 01) 00:02.0 PCI bridge: Intel Corp. e7500 HI_B Virtual PCI-to-PCI Bridge (F0) (rev 01) 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) 01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 03:01.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 03:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 04:01.0 Ethernet controller: Intel Corp.: Unknown device 100f (rev 01) 04:04.0 SCSI storage controller: Adaptec: Unknown device 801f (rev 03) 04:04.1 SCSI storage controller: Adaptec: Unknown device 801f (rev 03) Ksymoops output with ext3 filesystem ----------------------------- Dec 21 06:57:02 theseus kernel: kernel BUG at checkpoint.c:587! Dec 21 06:57:02 theseus kernel: invalid operand: 0000 Dec 21 06:57:02 theseus kernel: CPU: 0 Dec 21 06:57:02 theseus kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Dec 21 06:57:02 theseus kernel: EFLAGS: 00010292 Dec 21 06:57:02 theseus kernel: eax: 00000069 ebx: f6c46660 ecx: fffffffe edx: 00000000 Dec 21 06:57:02 theseus kernel: esi: f7ecc660 edi: f6c46660 ebp: e03fdc10 esp: f7de9e1c Dec 21 06:57:02 theseus kernel: ds: 0018 es: 0018 ss: 0018 Dec 21 06:57:02 theseus kernel: Process kjournald (pid: 11, stackpage=f7de9000) Dec 21 06:57:02 theseus kernel: Stack: c0257500 c02558c6 c025583d 0000024b c02558a9 f6c46660 c0166173 f7ecc660 Dec 21 06:57:02 theseus kernel: f6c46660 cd59ce60 e03fdc10 c0165b6f e03fdc10 e03fdc10 c01660fb e03fdc10 Dec 21 06:57:02 theseus kernel: 00000012 f19f0540 f19f0540 f19f0d40 f7ecc660 00000000 f7ecc660 c01643ef Dec 21 06:57:02 theseus kernel: Call Trace: [] [] [] [] [] Dec 21 06:57:02 theseus kernel: [] [] [] [] [] [] Dec 21 06:57:02 theseus kernel: [] [] Dec 21 06:57:02 theseus kernel: Code: 0f 0b 4b 02 3d 58 25 c0 83 c4 14 8b 53 1c 85 d2 74 29 68 a0 >>EIP; c01662ec <__journal_drop_transaction+5c/282> <===== Trace; c0166173 <__journal_remove_checkpoint+53/80> Trace; c0165b6f <__try_to_free_cp_buf+1f/40> Trace; c01660fb <__journal_clean_checkpoint_list+5b/80> Trace; c01643ef Trace; c020036c Trace; c0109cea Trace; c011a94b Trace; c0109e9c Trace; c01142c3 Trace; c0166e26 Trace; c0166d00 Trace; c0107136 Trace; c0166d20 Code; c01662ec <__journal_drop_transaction+5c/282> 00000000 <_EIP>: Code; c01662ec <__journal_drop_transaction+5c/282> <===== 0: 0f 0b ud2a <===== Code; c01662ee <__journal_drop_transaction+5e/282> 2: 4b dec %ebx Code; c01662ef <__journal_drop_transaction+5f/282> 3: 02 3d 58 25 c0 83 add 0x83c02558,%bh Code; c01662f5 <__journal_drop_transaction+65/282> 9: c4 14 8b les (%ebx,%ecx,4),%edx Code; c01662f8 <__journal_drop_transaction+68/282> c: 53 push %ebx Code; c01662f9 <__journal_drop_transaction+69/282> d: 1c 85 sbb $0x85,%al Code; c01662fb <__journal_drop_transaction+6b/282> f: d2 (bad) Code; c01662fc <__journal_drop_transaction+6c/282> 10: 74 29 je 3b <_EIP+0x3b> c0166327 <__journal_drop_transaction+97/282> Code; c01662fe <__journal_drop_transaction+6e/282> 12: 68 a0 00 00 00 push $0xa0 ------------------------------------------------- Still single? Click here to find the perfect match. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?141 From lartc@manchotnetworks.net Tue Jan 27 07:39:05 2004 From: lartc@manchotnetworks.net (lartc@manchotnetworks.net) Date: Tue, 27 Jan 2004 08:39:05 +0100 Subject: [LARTC] I can't get TCNG to compile!!! In-Reply-To: References: Message-ID: <1075189145.2334.6.camel@drs0.manchotnetworks.net> hi, i have had the same problem ... after running ./configure, edit the "config" file and change the line with KFULLVERSION=2.4.21-9 to just KFULLVERSION=2.4.21 without the "-" or "smp" -- these symbols cause problems. make and enjoy cheers charles On Mon, 2004-01-26 at 23:39, jradke@canbytel.com wrote: > Help! I can't get TCNG to compile!!! It did this on 2 different > machines! Here are the errors: > > -------------------------------------------- > Kernel: 2.4.22 > [root@localhost tcng]# uname -a > Linux localhost.localdomain 2.4.22-1.2149.nptl #1 Wed Jan 7 13:08:26 > EST > > #if KFULLVERSIONNUM >= 0x20416 /* gratuitous interface change in > 2.4.22 :-( > */ > ERROR: > ake -f Makefile.unclean tcsim > make[2]: Entering directory `/home/jradke/tcng/tcsim' > cc -E -g -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -I../shared -Iklib -Iklib/include > -Iulib/iproute2/include -I. -DVERSION=\"`cat ../VERSION`\" > -DTOPDIR=\"/home/jradke/tcng\" -DTCC_CMD=\"/home/jradke/tcng/bin/tcc\" > -DKFULLVERSION=\"2.4.22-1.2149.nptlcustom\" -DKFULLVERSIONNUM=`printf > "0x%02x%02x%02x" 2 4 22`-1.2149.nptlcustom -DIVERSION=\"010824\" -I. > -M *.c >.depend || \ > > { rm -f .depend; exit 1; } > trace.c:41:5: too many decimal points in number > make[2]: *** [.depend] Error 1 > make[2]: Leaving directory `/home/jradke/tcng/tcsim' > make[1]: *** [tcsim] Error 2 > make[1]: Leaving directory `/home/jradke/tcng/tcsim' > make: *** [all] Error 1 > > > -------------------------------------------- > Kernel: 2.6.1 > ERROR: > > klib/include/linux/errno.h:4:31: asm-generic/errno.h: No such file or > directory > make[2]: *** [.depend] Error 1 > make[2]: Leaving directory `/home/jradke/tcng/tcsim' > make[1]: *** [tcsim] Error 2 > make[1]: Leaving directory `/home/jradke/tcng/tcsim' > make: *** [all] Error 1 > > > > > From mihaivlad@web-profile.net Tue Jan 27 08:28:52 2004 From: mihaivlad@web-profile.net (Mihai Vlad) Date: Tue, 27 Jan 2004 10:28:52 +0200 Subject: [LARTC] R2q Setting Message-ID: <20040127085857.A80A74419@outpost.ds9a.nl> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C3E4C0.5C021540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello again, I need to change the R2Q for my script, as setting the quantum manually for each class is painful. Can you tell me exactly where to set R2Q = x? I get syntax errors all the time. Should it be specified for each class? I do not know where to place this setting... Thanks in advance, Vlad Mihai ------=_NextPart_000_0010_01C3E4C0.5C021540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = again,

 

I need to change = the R2Q for my script, as setting the quantum manually for each class is painful. = Can you tell me exactly where to set R2Q =3D x?

 

I get syntax errors = all the time. Should it be specified for each class? I do not know where to = place this setting...

 

Thanks in = advance,

Vlad Mihai

------=_NextPart_000_0010_01C3E4C0.5C021540-- From andy.furniss@dsl.pipex.com Tue Jan 27 08:42:05 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Tue, 27 Jan 2004 08:42:05 +0000 Subject: [LARTC] NEW imq driver In-Reply-To: <009201c3e48f$fcd5eb80$030aa8c0@t> References: <009201c3e48f$fcd5eb80$030aa8c0@t> Message-ID: <4016245D.7070101@dsl.pipex.com> Roy wrote: > Seems I was to fast to declare success, > my version is not much more stable than the original one,everything depends > on dropped packets. > This is even not imq fault afterall, can be prowed in other way also: > > atempts to police outgoing trafic it will be ok until you dont touch localy > generated packets > if you try to drop them you will be sorry, because kernel will resend then > together with new ones > of cource policer will drop them too, but linux kernel keeps resending then > thus increasing rate progresively. > > I noticed that with my trafic counter. internal trafic grew to enormous > levels 10X more than it can be. In reality there was almost no output at > all. > so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s > it probably can kill computer (not tested). > > Seems imq have similar problem even if driver itself have no leaks kernel > consumes all resousces on resnending droped packets so that computer stops > responding > > > for now I dont have good idea how to fix it so I will try to avoid localy > generated trafic > so it will me possible to shape ingress and forward, egress will be left for > real device. > maybe later I will find how fix that Which queue do you use to drop the packets? Andy. From Aron@sofaware.com Tue Jan 27 09:30:54 2004 From: Aron@sofaware.com (Aron Brand) Date: Tue, 27 Jan 2004 11:30:54 +0200 Subject: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE33B0D5@mail.sofaware.com> Hi Roy, Strange. "kernel will resend then together with new ones" - this is interesting, since the firewall DOES know how to drop locally generated packets and the kernel doesn't attempt to retry them. I am not an expert on this, but I think it might be interesting to check how the firewall does this. Another option would be to trick the kernel that the packet has been transmitted, to prevent the immediate retries, while actually vanishing the packet. Aron --__--__-- Message: 8 From: "Roy" To: Cc: Subject: Re: [LARTC] NEW imq driver Date: Tue, 27 Jan 2004 06:42:29 +0200 Seems I was to fast to declare success, my version is not much more stable than the original one,everything depends on dropped packets. This is even not imq fault afterall, can be prowed in other way also: atempts to police outgoing trafic it will be ok until you dont touch localy generated packets if you try to drop them you will be sorry, because kernel will resend then together with new ones of cource policer will drop them too, but linux kernel keeps resending then thus increasing rate progresively. I noticed that with my trafic counter. internal trafic grew to enormous levels 10X more than it can be. In reality there was almost no output at all. so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s it probably can kill computer (not tested). Seems imq have similar problem even if driver itself have no leaks kernel consumes all resousces on resnending droped packets so that computer stops responding for now I dont have good idea how to fix it so I will try to avoid localy generated trafic so it will me possible to shape ingress and forward, egress will be left for real device. maybe later I will find how fix that > > It seems to capture ingress and egress traffic of all interfaces; wouldn't > this count packets twice ? No, ingress is for local and egress for everything so everything should be ok (in theory) > If the machine is doing SNAT or DNAT, what IP addresses would be seen by > the qdisc ? > I made driver see the final destination address because it is more usefull > Rubens > > From remco@virtu.nl Tue Jan 27 11:19:29 2004 From: remco@virtu.nl (remco@virtu.nl) Date: Tue, 27 Jan 2004 12:19:29 +0100 Subject: [LARTC] Ovffyxl Message-ID: <20040127111705.7CE2B3F6B@outpost.ds9a.nl> This is a multi-part message in MIME format. ------=_NextPart_000_0000_CB99A25A.B13C8D9F Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. ------=_NextPart_000_0000_CB99A25A.B13C8D9F Content-Type: application/octet-stream; name="readme.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="readme.zip" UEsDBAoAAAAAAG5aOzDKJx+eAFgAAABYAAAKAAAAcmVhZG1lLnNjck1akAADAAAABAAAAP//AAC4 AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA 4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAACAAAEAAAAAAAAAAQAAAAA AAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA6MEAADAB AAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA VVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAABwAAAA UAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQAAABUAAAAAAAAAAAAAAAA AABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKSAFAmSgBAA/2yaZosEAT0 JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lIAEQHODA0TdN0AygkHBgQ 0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym6ZrBB1RMA0Q4mqZpmiwk HBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhwKHto3mzTdQdcA1RMKP/7 C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTMyMCapmm6uCewrKigmGma pmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgmzwPo4Nhnm85tVDRDA0A0 NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//////dawCmVBHbrY95c3WHo cv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqihnZyeo6u2xNXpABo3//// /1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBmlpaj+8sPSqPgSLEprj7bg DT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/LagyxQ3qy/////3MXzohH BciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MCNHmh3Bpbj+Ywbc0gds8r ivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4/////3q/B1Kg8UVsllOz GnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCid08qCOnNtJ6Le25kXVlY /////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3pwJw4VXMBsNDxlzVYWFk anN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF/XT2d/uADJkp/////7xS 64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1FUF5vg5q00fEUOmPPvvDl bLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP2W6V/9/+/ykDI+mUCb/m 86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cmlt2XnSJgD0aezf0sQH// ////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOtYNrRUhXOZl+3QcAU5GWT n3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3QvbjBupvXWHO0//////2xSC QhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTsc5gBTQad8qKvwmLz5V43 3wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F///4HZAEq5YABgYQK++Z 1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3Gl1v7CkQo/////+88+31 b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8wCo+uhOF1QKFimLL1MErg 4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1vP////+e+x9W5m6Q4DtH s6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUMXmBJcvX0rvRTF/wWFfKO mv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////mChg/OpWfgYLjc6RHPQkC 1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2R/lK9//////Y+y20imdi /1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+SdBRuXetvMs/s3jyXxOR2y fBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv///wud07BbjSo2QhvK0eQ0 UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3hqSCPa6Hw/////+HsIC2 30Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9aSU/xQ/M3y282GD1nLaHx mEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N/////0obAzp9Dz8LTxjxK+GI tTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnTyKVPNvpoAL4+XRnW/9v/ //XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HISteCv13loJ6TkCXYQC8x oAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBMLGk3/v//6PoRxnD3Q/tH otqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRbh0I8/////zM0gDX2HfMk pl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkpEXNaQVYLOj3wUh2sL6Ya 8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CVJZrIztaCA6XOe/G08x02 //9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudzhm7VsFdwOg9+pNxQ1UI/ D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D///4dwgw9++Z/Pyg0niuv Is0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl7ODt4vj5DmeXVpG79FzN 19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ//////Enb5m9SRr06wQUig 7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhhFPbj4VKT/8L//9rIX5t3 xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/t5sxWrWR0gg0cE6MJqNp v/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAgSn4yQb7lYUvpcn8nvAZD k1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/xv/2fAp/R8NqdrmZ/l2u bFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH/////NcaYZoAiWI9VLHjYQbE6 LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B+TLGpQd0Gf////8s886o INbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCSVqL/Em5agE/9LvZoK6H3 ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28Y04+A/OGhB4e59Kee0Oh vjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gLZIH/l/7/zDVEcN3wEDJH SYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YXEspnD63/b5T+d0e0zR44 vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9SG/3//7dSpCoQS7DvKZAv 72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo////9vITkyKEN+q8OpjiHA +SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6f1HJaHmdjrHC7P////8W JF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcByarVvw+YZGy61G8bM6Ya2g Zsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c3tYtqqytryuFym8V2Csj UTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y50mNuS+7NKKqhkjh7TgMJ 83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//WXq16vvvk7tmY6PVVOAsd 9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB4LPzn965m56I+v9/+/SL GIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv///9bEkxrr77b2wB7Mhl1 wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/Fr5IOYdf//wL/cj91DzwF Qn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX//TBuvVXOm//9/idxR1/7/ Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXmZ/aF/vSNWaP9xgn//y1+ Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bREBuu8NojQKbqlXlH9JJ4S W/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzDLUpiTzTfRjZ4W5HRvkZQ MYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSak4+OkP9f+P+Vnai2x9vy DClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/Qv//mqCptcTW6wMePF2B qNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8oghvVz+o0v2/1v8/6RVCcB6 N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0JluTzgxNkdgib78SaH/j ///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav6ypssflEkuM3juhFpQj/ /1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PClGlBHPrbv6aQfW1gVk9L SkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ9GLTR744tTW4PsdTU1Zc ZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG////72roae10/osbrkTd eRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83QlBhdYymw+MGLFWBsOIX T4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY1qn//1uiQmyZyfwya6fm KG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQPu+jWhTRPDQa41RQJf3Y tpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8Cb3MAlu3FnjdVbAeDwN6 //////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0eU7VE7t9o8Ucyln+MHVvI Jal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXtoiZWigJ3m6/OJ/9/4239t WwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt7fD2/wsa//8v/SxBWXSS s5koVYW47idjouQpcbwKW68GYL0d/xZf6oDmT46cEYkEuocOmCW1SN7/////dxOyVPmhTPqrXxbQ jU0Q1p9rOgzhuZRyUzceCPXl2M7/hf7/x8PCxMnR3Or7DyZAXX2gTxtKfLHpJGKj/wL//+cueMUV aL4Xc9I0mQFs2ksAsC2tMLY/y///jf7LztTd6fgKQFJwkbXcBjNjlswFQYDCB0//Uv//mug5jeQ+ m/texC2ZCHrvZ1PhZex2A5Mm/l/q/7xV8ZAy138q2Ik96Gsr7rR9SRjqv5dy6P//l8AV/ObTw7as paGgoqevusjZ7QQeO1v1//9fQc35KFqPxyhzeW5jLmMsdiAwLjEgMjAwNP0j22+TMS94eCACOiBh bmR5KQB7uwUbzAItDAAFHAA5Cc4Q/5kPAQAQAAkAEtcDByF++2Z1dnp0TXYucXl5N0Zi/b/7/3Nn am5lclxadnBlYmYNXEp2YXFiamZcUGhlf/n/vxdhZ0lyZWZ2YmFcUmtjeWJlcmVielF5dDO3+C3Y MlwZQ2pyb0Z2a0Z6ur/99mdrRjBTZ25meHoXLnJrcgBHC1orNAX2I2dFeZeW//a/bm90ZXBhZCAl cwtNZXNzYWdlACwl+5jbD3USBS4ydToEim57zxQGAy8tPyv7b/9vQ2VjAE5vdgBPY3QAU00AQXVn AEp1bAO2udutblNheQ9wcgcDRpC3v122E2FTYSdGcmkAVGhEV2X2zt22ZAd1c01vFy9hYmNkn/vC b/9naGlqa2xtnHBxcnN0Tnd4eXpn9v//f0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaG7Xt1tpW uNdjZ1QCUNzoWuG2CHAOcUYgBZ9qHD6CWwB2Go5haHhy3ffCtj2TYu52ml8nbnB4D6Fw+LeeYmd4 dmdLQ8MHad8u/H8tdHZleS0yLjBvcXCMX2NOcHVyZpmh3QozXHZpC0Q72da+bUhkVi1R4Hlz5577 /m56YzUAdGdhW18pj4JZdu5zY18HcGku5d4OGNtRZzAjWG76blxHK9za3lthZnPVAApobKMtdoFX fC5kbGyz3VF1Jm7JyvZ5X0ELZBkwdE6w0GrcAndvD/DobeXWHM7Ra7YLB2xp/PzbvmGXdQllB2lt bXllcnIzDW3jG2xuBGQPRd4u8GNsM2RpOGJyZe+95bdGbj4AYWM/F9tuw9caOmgXdMdmcgSF2Qh/ U2Fja19pr8ErRP5rPQ9zbWl0aFtD3itf420HQgAOB2iM7N4mam9lP25lby+vtc7U8QslcNgHZ809 t7Vvbs95O7ZLFb33xhpsj2lk1xsfYt3OufNlb09zSwZldxyFgnMvrtoi5rXP8Pt3abBrZc6PaQlQ Giudv20JD2MjR3YPrhfzuQBLaG5jYxjuCo5vqiOZaWZpza09XTtf1Yt2bhVQ7625f5t1cHBvvCHF c29m6/BOYw0vbWtwaM/XvW+6eC5iD2dvbGQtUHhjvCTDmGFmZSVDYjWn4zDYQ6Nw83aFu2it0Fpn iwZbr4I5d1grZA8nH2sQW7bWpYkfdGlKjJLB0Td0tiufG9jhtW5tFXnJA1pH73sOw296wQZzaDDl 9t5rB10PFpN3ZQxr7blhnjTgCAwWuxk2W3BsOTNmb28vW/jCsYcKCsNfbG95RzpzltrNcW96FeB1 dP/aLr62azEwpDByZAxPZ+tawdHiPu1S52OYG1ugEFqZbwdpIxpOjRb2DTfmbo215vgHc6KDVnNm 2E7tK7VUaUFiB2EKhubOt3UkElfxjdDi9EoP9PtyNNe2rhc5Z6tnuy/a4C05GgVjeGZaup6hYGMf gHcvZI4Yxz6zaE9uaROdI7ezpms6eecKN29vLmJu9r1tj1d2Dwif5trB0YgqS4ezT4YIjdl5B2E8 Ozq0Hw3Vc/tybLqT2ybFWPxvL78MdOobRqwU3fpbJy/QmnR5bZ+Ily5fITu473sLB0ATYv23ALQR tlqfxHrrcOOFsu81fXULIyAAgXxFRm4oACmm+e5RIAIHvC1KAAG4kpODfA+0/CqwQJoBGawDqKQb kGYEoAZfmIUt6QYFD5CxybaBXQILDAEAzVLYYBIBAD2dqmyRHwAmbpQchy1tcAc7RHcdzcZjRShA Ka9AQLcgFgjFMLtff6l9LSIDNARsIFN2eXIglkpfjUH7T3cQT2wB88QHi2Jo93TfFIM2+WRieHHH i/zUonl+y3NodAb/vzV2bWIveEgqLioAVVNFUlBST0ZJxRYL/ExFAFlicDUg1Wdqlfi1FmF5R3L9 G8PYsOhaIJmCZgr////kOlyWMAd3LGEO7rpRCZkZxG0Hj/RqcDWl/////2Ppo5VknjKI2w6kuNx5 HunV4IjZ0pcrTLYJvXyxfgct/////7jnkR2/kGQQtx3yILBqSHG5895BvoR91Noa6+TdbVG1v/z/ /9T0x4XTg1aYbBPAqGtkevli/ezJZYoBFNlsBvT//wa5PQ/69Q0IjcggbjteEGlM5EFg1f///y8p Z6LR5AM8R9QES/2FDdJrtQql+qi1NWyYskLW/7/Q/8m720D5vKzjbNjyXN9Fzw3W3Fk90ausMP// v8DZJs3eUYBR18gWYdC/tfS0ISPEs1aZlbr/////zw+lvbieuAIoCIgFX7LZDMYk6Quxh3xvLxFM aFirHWH/////wT0tZraQQdx2BnHbAbwg0pgqENXviYWxcR+1tgal5L/8////nzPUuOiiyQd4NPkA D46oCZYYmA7huw1qfy09bQiX/xL/SyaRAVxj5vRRa2s3bBzYMGWFTv///wIt8u2VBmx7pQEbwfQI glfED/XG2bBlUOn+////txLquL6LfIi5/N8d3WJJLdoV83zTjGVM1PtYYbJNzu3/FxYsOsm8o+Iw u9RBpd9K15XYYf/////E0aT79NbTaulpQ/zZbjRGiGet0Lhg2nMtBETlHQMzX63+//9MCqrJfA3d PHEFUKpBAicQEAu+hiAMyf7//7/xaFezhWcJ1Ga5n+Rhzg753l6YydkpIpjQsLT/////qNfHFz2z WYENtC47XL23rWy6wCCDuO22s7+aDOK2A5r/////0rF0OUfV6q930p0VJtsEgxbccxILY+OEO2SU PmptDaj/N/j/Wmp6C88O5J3/CZMnrmaxngd9RJMP8NKj/yX+/wiHaPIBHv7CBmldV2L3y1KAcTZs GecGa/8G//9udhvU/uAr04laetoQzErdfd+5+fnvvo7/////Q763F9WOsGDoo9bWfpPRocTC2DhS 8t9P8We70WdXvKb/////3Qa1P0s2skjaKw3YTBsKr/ZKAzZgegRBw+9g31XfZ6j/////745uMXm+ aUaMs2HLGoNmvKDSbyU24mhSlXcMzANHC7v/////uRYCIi8mBVW+O7rFKAu9spJatCsEarNcp//X wjHP0LW/0f//i57ZLB2u3luwwmSbJvJj7JyjkQqTbQKp/xf4/wYJnD82DuuFZwdyE1cegkq/lRR6 uOKuK/////+xezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PH4s/7/f6HdlIPaH80WvoFbJrn2 4Xewb3dHtxjmWv+3+jd9cGoP/8o7BvkLARH/nmWPaa5i///f+PjT/2thxGwWeOIKoO7SDddUgwRO wrMDOWEm/////2en9xZg0E1HaUnbd24+SmrRrtxa1tlmC99A8DvYN1Ou/////7ypxZ673n/Pskfp /7UwHPK9vYrCusowk7NTpqO0JAU23+r//9C6kwbXzSlX3lS/Z9kjLnpms7jsxAIbaP////9dlCtv Kje+C7ShjgzDG98FWo3vAi1UUkcgLyBVR0dDL1a3b/0xLjENClWzZzogagAuZmo9as3VLm0SAXPA gbGWETMeAyCDdBuzDwcgHDSDNM0UCgwEBWaQZtn8MxH07BmkaZoA6DLk4AZpmqYP3AXY1AUbbMAv DAcjV0jTDPIH0MgIsEjTDDKYiAqARYEDNnhPUmWtFnAb4JuraGYHK2nGAwbeAiBFcj2UWskGOECB Vgl11nIFSvFFELAXXMBtdVEDdi1jRmz0biMsPXIgdRJ5YgcTtB01bW+7cHorH2wU+QVDZQBjdnPO cbVtgwjPDGZVdBtu8letOj2ncW5nYbTAZHsHF2vbAEpwrHUmcS8LaHpFR3AbxGs2eoabbG5iC0No DaX6YQm1RmcNuhsl5wLu0Knu9+hjJ7fr92ChB9/9Y1cj0NZcqRgQCgRNa2qh1uAgl/FzvWnFCnAh dyBmEKsuINajkWDbD2EbbaggKGoDV2gg7xvPbFmrR3AQTyQeqNFGKv9pRWaUa93WrAtkEGhAUoXW usB4zSANB2Waa021ZV8bdBEUDrvaCtAuWAh0OGhtVUvZcxZWVzzttYXOGjoge3ACPZ32t3ZrjEc3 LT8XQVNDSUkgFAbCXLlyPWl0IAlmrvNt6/9PYUEhMDEyMzQ1Njc4OSsf/ya9L0NCB0stWkYxLWtL tcZDZUMC6TqlB/yy2EK8eRsUMwAJYryF3QLaZJk9IpIiO61wwxZOZ/AtR2y7IXijVON6aHmGQ5sv enaE+O3dVnE7YQNaVlpSLVhc65baI9AwE1H7L1wLWs9/RmiUkg7dt/HdC0diFVP2egctAD3z0721 X2oCLjN1BDQ4WC5hh62+O04YdPbPv2GttS0rA9k/JWZgaWFko3ljF3AKrTW+oC+uGBcu7QztOr96 rAlhAtpmIo3PgoA0Zy1SYa3ZN5qLcb5BOGZyNjQi4V4rfVF2Zo/cUV6nd1pq44t1BFAsRTYhYFQP n7TXtqdXL6JuakBKnBFtK01tZz+nLay9yC7FNTKeN2+KYnBCtx1HdZogAm6ZLaHRgvSaINgXZpl+ 2IfGdetnLpVRVUlU+vPOzacSD0RBVEFFUENHb/3b3mtCOjyyPg9aTlZZb0VCWnbnt2QR0lVSWUIg C1JV1YDXS1RvuziMZi3wy1rVIMiX205GAxBOcNBoDBps11qj4K1lXA9mgvW1xXvnZTVuO9YBZ7vl YXkKAAAxC4Z47x14IAcRY3829t50cAgjB3goVYvsgez5///GCASNVjPJM/Y5TQzGRf/HfmhXiz1U EEr//391gfmxchWNRfhqAFCNhfj7//9RUP91EAbitxK2L4tFCLuFI0S7++0EBjI1QYiEDfcei8aZ BmD/b78CsgP26gAVRjt1DHy5hclbdBNDJcexD19eycOBLAH6xkSUiG8i7GhMJInv/u6/zjZai3UI ix14hlkz/1mJvgwjiX0IOZv7cmsCQ9T+dQ5oGBJJFdtssbt0I+sMUA4NcIC9Iey62dY5cSojbBWN jd3v2f9JgDwIXHQOGWhIbv/TeVDYn/hhK9NXaIBiAldqAyV/05kgDURoi/iF/3QFg9s2k3V/I1xk g/gRN6jy9m1h/xSDoQIPjFRK/+tBL2LboAIABBSic2+z/Sjcg8QMVy9gx4bQArr3YOZsCgsCUo1G CFays8dOXPcBdRQSWDnCGxZeLT9bQI1sJIxCCy+Z5IgAYH18PNstbN0vH4hdf74xgB5wJxmb7v/O PCdTUIpFf/bYG8ADxlkEhcCbe//tdFX+E4B9fwJ81ccHnDgqbDJlu79QN1NoBjhTUzoUYWZbOHUJ AHAMAEPDydrdxaCDxXSjGevt799N8naD7ECmwGikWQ5ZUGoBat1mMw2+gAV8Lbd/9x7kYHRkQCU0 AuhotNiVC8s7Msz95mgENhxm+w5TPJCcw1y84X4R9B4FEBt1iUX8zbLhuIs1VEpdXdAR/g4lOJ0h D4SpneRADozQTdDQPTusu9ahUCvWCGogeQbj1DaMU1xT0Gbc8SE7w3QySHQtUCSzQrLJcIgMevBh vCMNd4TrEBiHhz2TMQ+FGQwgdQ/mwHD9M6RP0C55I8loyEBQaMA1PXRsPBe1EAC//lA62qPpLsdo TdwxFqWDTOYaFQF1Lb3CNuHhfIHGdVYu4lbghhnDuVwlDQgWFyNGS5QmG2pt2Dpd8PGYMlDIBSS8 cITObBKU1/Q7xHYFM1i21n4VcwQGBRL48Ca5rNEmKkH48OzlQEYU/PRyGjZn4XX3chLnXDdo5/6c cuMcjO5uZARenP4Y7xjLV1BfiJ0OGrHkOXKcgAGcQA7k42EgnJwTRuTZDQQlEpybI8kgwLRjB9nc ZjDaCP4bX1TAv9qWbMfCXoH//AF3NsfSpRj0HUH88P/ftYfw1ibhMh0Pt8BqTJlZ9/mF0mEP9vt1 E8aEPSUNRwgK6xok/7H/9Jm573b5gMIQiJQcR/9N+HWbO/ubmw3YdBJgV1wEjGBO9w0z0x776Ph6 fLvcwTwRakQ3oF9XU1GgcGuUS0unTeS3ttatXcqgUQgDU0BR4czVdpuVtzglU2bW0Nb0ZKtfkagQ aqDkDnpP6N6kZQjWdnQNcDU0TUkc9qDMuVF7B2ZzIw2wQVaJRgR30iNssCqfSqwzOT5ZH+O2td1W EitOXApqD3QPwWjtAmX8qvc9IAbs+/sV/x0pXgUtalkkRS/OwMhvhBcs06zIB25ysN04sgRMwz/Z XBMmJWTHUS5WVkF53B5OP1nEA3dxEcQ8/F7NQsH8K3xo48MRTJPgKDC+KEosM7Z7jX3wpQC+OAvg BXjAtBulIy+toDu0MBHJTQFheNDk5rhQAEzUhGYG2ICOHDly3HzgeOR06HDIkSNH7GykaKhkHDly 5KxgsFy0WLhUkSNHjrxQwEzESAtz5MjIRMxA0DwEx/ZwUtTECBsLnD1bL8hSCKHAEOM8Tfc2I/CJ tQUSuIv/S2+cjfsCdQWymAPI99mLwXkCm+NbS+xm4fQGdgYtBgDIrn23ZunydQvy+BjyDLt3L7UG Ps65OIB9Bbk0Bmo871to/Jle9/5SUOexUQX6BNPdeJ748PJWhaAM9jDj48301GgMJXYMyrfPcLFn MLJco7CBBMOh6T32fwVpwDVOWgFAEWahshdOtx7SB8jB4RBZC8GqRCT8d///BFbrJYtUJAyL8ITJ dBGKCgULOA51B0ZCgD59i1svJ+878iuAOrkJQIoIhR5buhp11SheNesHOhn7u+3sCHQHFvMFKg72 2RvJ99EjV9Intkf19RAddDGQ9iXX3Qyqi10M+LoQD7Y4Ah38QdcDZlf91llDHFlG+73Ai00EwXUN M3XYY5pAzG0gUuv2SRSbu8TSWV1NRFUMQ5OKVuL20gGEigg6AhhBQsRQ0U7g2wECCivBXXAkdmjr b2xpCG6JdfiAPwCjSK1Dv3XO9z4mD4UxtSS/gFm6Rg0jI0lGD74EPn9zzxc3EVlcDohEHdxDRqD9 1v6D+w9y4oBkCiXJOE3ciX8b32L7XtwvEDEMiYA4H0yjGzn3StB18BdPWgFGWQuW+30Pjs4AVGoU KGP49u1Qk589XZYgXd2IGUFH++LrFrjcJWwItGejtohQDSnIfWvY7j4LVItd/CAr81Cu9Gx4eRZ6 bPDwdFErA/M/CPwb4Bw+jTQIA/fhzyvLO/Mbv7VvjQgBcxv3hX4ri8MrMQPtG7VvL4oUM4it9/F8 9eu77t++/EH/hcB8DwYr3kAZC4gRSUh192bhWxgGKBlQDY0PeVhwn7l0tp74LQAm5aBjuvdbpiaQ kUkaZxj8G/yFB2Ulm1ZENwGLHRzZDAvOxPvTXNvqbMEcgnEYDOgoQzLWUehZIMmAv/3bt2UyRjxB WSjpfAw8Wn8IG8iD6TfrH9basQYHMIo/HBjAg+hoKP07BzDB4ASdCnwUumlbSQhD6dnoiE0IwfBD KFFNdEEDw0lDzU/CQks4Rs473o1EEdzwF26LfiElig6IDDNGJOsUSMkhzSc6GCvzDuiDDEkzCOj8 57ZSOyf8Xm00dLO9s9cEAzwDEu04yPTlBFk4aga+pOuVk+7fT33k86VmpaQPiMj7021zrmzkFVCk zYFZWV+c6ks7eF50FMlqGgZZg8ANzX6u3/X5ikQV5B0qyFAnoVzIsyVZyMhF3RbcbQgEVouR0nwE igbo0v81Xg00Nd+IB0dZRmOAJ8iXemYWnURWL7xo3CWan64OvFmP0PCF9v7NIZ1bFRUUWDR0WWJI vi85wFZczFNvsAWb/DlR/9BnIMAGtwPrA4hYlHCfLcxokJiEJkE+W8y9bhNIF9h8JmYrbcNZf/iE FfiVTkwS6RwYbAyrGZ1DUx1pYnbILaNTDqk0kO3F9wBSU1gkDDJCY2YuEABw+PbQejAZ3ebJVz26 0Bp7jb1DT9//OC+SfQvW2FMOxgQ4XAw8ZLbqG1wVeJD47ExCl9ciBxsh9oT+/zSVkBGuhAVBQufC fjYdWWh4JjoGsJe3/zvTfE6D+gF+NAQDfhoEdT9pGWz3bHQuaHAH6z0UbEEGeQZoKGRmkEGeYBNc WBKu2WHQ1wjOTnstCzOEZBE7A5h6Z/wKeBkGo2ezE8vzWeoA8ArwdVwQRgw9gwG5yAD8DPJmiZiu LY0WZlgUcwwCNt2GAjMkM9IOBDgXmpPt3CSdBgYICnT4pQI3wTQ7It3rCYD5Ln4MLjVI0Qw4x8gq y4iMsaXfFe0iQjvYfR4rrbwNb6Uv8IvIA9jmFMHpAnwLg+ED3HIB9wPQ86Sf9zsuQwb2K7QNo6ys zX2ApDNWuFUi3i5yDRVzht2274Q1p0akRg1qEA9OGOwmxoPGAtpWM3iHFm/6vMnND57BXlg8xK3j E0tl/GDw6EMEgpt7LApwBVYkdjXVDRzcz30wX/4EMPBv8dbmBVAF6w6cQH0GjXQGAeGeaysKDwaF ODG59/rWFTkMfMuLxodYWaChZypD2WCfO2hbzd+ofWuB/v8AX+oDVd5ujRcG0nRKNk8XQAl+C4p1 4y/QEw8+RkBKdfXJPi75rSyxFied/GbAAolF+HfqVGkBk/tqpRLvvvYl/z8LVBIEfKbrC9G+tX2B inw3/y6oThF/9IAkOdh6BRxAugNXd4ytq5IBGucwG9gQ5TPeniV41PaxdeheG6KpC7goXxwMWDpF bYu3VoM8AvR9Bx3pFiEMhQJpRVOnu8V/qt4VOe+L2Fk7d1l8H0tsFwY8AEYKA042wWHi0m01+AgG O8dU4FwXLLTg+AM6L71cA7C10kYUaAOZpW8Z+lzD2ty2A8quYWA6SItDCt7QomC6NZwCqbt7t5Oh Q2Zb4EMSDIPDBg6gYRes4g0K5EOPQ8Be796CiV3oPn9hviRG+nRvE2Lc3qvsdEMYV6hx7GH9jbWV RVmLhha+6BfkENg/7E8Lt43CgyAsxgUJ9OuQAY7HABO6VQ+MIm48dKkBq41fyb8MI36uJ0dTVbZt M+0Yh7Ue8VXHAWF92AosPOE73XU8Prp0EY2D26GvGGDOVv2JKDXClWsk/CF+m9t4swgQiWwkFHSL GFE5p7+tcwsPGEBoVesBVZv4BXN/2bQkRBAG1TjeRME8YEZejtttd9fIIdddOFBVCjxVBm3QDpXH xF+gQPzszNZTRElkMY5cBFVTn+3YIRtVyFNXpmjohVO82brtLygnNDvuD4bavLSkJg4CRleD5g82 am4bmwPKIQH+Uw9rmFv3IBqEX4gNf5mL7WNu9H1lOvpZiY0kqhW6pRvfkiEcAxgRpnjJ3bEQ6wT8 4YO/CiZZms5sNp8NCA+Rwte8OQwDD4KDvRlV9Me6J0YudhVW1YHHUsfOAD7biwc9GFsGdOEIPEAo TyjGW7cWjW7Bi/1AkkVI+tZBK1l1ElZDui63ob/2HImsJgYHGJtz/DohMKyLP2IHnkHS9tseJCUg R9uDEhjZciG67R7/DxQKFLwl/tlTjPANi4S2x/FTZbpnoQuRJHlsRGENP/ViNGBLGtVdW4ETrliP xHd7b48r5FymVPlyxeLgEl2dnBYRAhBqZIzahjGoRpF81j10cyEHB764dBfopXLN4iFzpHq/fZvF 2yYOEHUNdCJorHaLk84qD8wSX/RWeZXrgYUcD23Qb1c7at1Y63GLQ8M7/jDtqHB4dGFTu5OmT3VL GHJKcFGZPlMukMFdg0cctIMOaP8ushCfOncY1+BTdyO4A5NVaz+g/nWm6m4TUkIcYL6cole2KU4a A9AFMgdWw+uEuGPihNEAa8iW2eq17MTQHCyyBTvr7x2kvgBAQdOunsaqy+0UUULXX4YfjbbwK14h gVSF6wobcPdhjXcE0lhqNZ/k0na6rpOiVp7mgBEK45Hd2eiTFaNcESiLQI1XHHBbSQAbsyMc/IxR FWjkPsRZDTP0owupBlx1mzGVAQwRBtQZD+Rd39cxMAQx+i0FZz8MZfCAyF8JUTapHy08bKr4V0CA R6Pb1QOIwEBAQ3RZ3mC1K490T0Qks91BButeJA8gL4oOaDpJtYLU9hx1GxjI9pGwdcXrEhnMl7jl tiNGLhF15+WJXObqDUzoTUB0P2lQVWolAxRtYO/PYOoMBCtDWTxK9gwL3b1rQJQziHZPwaq1xPkQ Kw1QNiDdRv1OwCs+Nhf2DtkrlnUqI4Mr7f92JAZcK0B1A0t5r4BkKxVq0Eq4i4G9EXupAdu21T4+ Bj0T+DxLHFk8G7ArgLSTvUvudA8ty1lDtdpe4zUrvbSAs7rTe8C2XyHrTI08LigHuDqKB7fJZbMj JyF4B1PlbhtxP7ROebF1kbo2OFrkfAreQLS8cAeGA+7OXVnD74vxV9oaFloOMIBCJ/83yw6Nu7sg hduRnYR3y8K7BhmIA0NHDDfZHwOAI7A7bLgADCgyERA8jYR2CRqH1XQcxRfGXBnkJAU67uZxa6Dh NR0SECcLVjaabNS/FOlcTw+Iv23UlEZVtUBdw4MluL2F2lZ4YPlsggULLtE4GGTtU0HOOR1WZsP9 EqO8BAE5P6MXFggv6wtMB/+WDXBL7hM83xwce7sHr2Mqf+QQWyiLy70RLd4rDRTEjaPAgrvNx9pJ jO8rBA+P5rvIE73AM3DDdyJTi8WLz1pDEVmRLgPLyPO8gZ0YlMzukUG+GQaDKn9+Fc+28W7ugLhK BQkIx3Rkt/eyZ5GKDWH4IQXRcnvbiEQguzB8C/05f8UaDg+KiMEDAOUjDfhbyodIoRlrwGSHv41+ sVUVggx+wT0MMuuf/O2IHQQgVRUGfAk86wdhCcdnCEZ94QfJw3konJFqXbcAvEYvNV1g6wWeD2cG OsOqiDlmtQr5JBHUHrJR38fAhD102ISpG1RGgbA5fN63MNJdmQASF5xf37gOPjpTt1P/MKkRUMNL 27dKRzuDRo85HnXjM7DJELJzSyuwERTvDV4ts/jeWOv33XUV+arycRBB+MJcV2q8C6MgwKe+U7ti NXdGR56n2jNbrJkepBTd8IOsSHZzeBInuHivtjTYwODkSIbgGDM1Tdzw8HWo7V4g051/JqoGaOgq zWYnoYTwUC3RZDI3CK2BKEbkyMFuLCFqBRmUKTZkk1xN3DMzw0tYyM/0JLj0RzBhxZIQJlG+rx9t DflLQQQ8OBZWBqUPPvGbwfzjKWAytQiThVe9EH8qz2EDSHnw6A8Dx0Gp1ij23RI+xO6x2jh1yNS9 i8c/RRZTs2DWwrIKlULxCpAMbY5VC7Chfk3XPTZ/Eo2NYOB2h439MkcU1ZiC0W3qSGNszIOCFx18 ssQtNApQ9ugsizargpUa3RsaFq2tLH74g8cPV35p2D8sXoheFutZV4aAZggAqy6GBBSMik7+mgl7 iEYJZFyhfGj0KiTEBusjBhyJkF0Oc7SFD/43n+GAdmEiZjVRPoSubKqhdHcR+ROEnwbE/s87NTPS M8n39iklevcj3w8qg0E7ynzx3HiDwAowBj20F3YMMfQQWoo/F2JAak80gDHb22FBuTFPWffxooCo EY4F9SgTAFzJrXLJyRnd/CpiwSDLgICAgU+DoR98hFlZZ3XUFHLJQgOrCHIICuJtHzTo08YDoSZ9 q1rrPNvszvoiOVhctv6FG08788CLVlg7UFhzavDCP7z10lHmgfn8f1xqYFOg3EHYQi5170oqHSWj UxOgeicfQrCu84gQ87NYiV7bnTW8XH+aia5AeLY5FbMP4H91sVeNfgjHRlz+HzCTY3fu/3YEM1tA 4VlPFFdzr851aRRKaV9n/PTRHomfhEkwU/9AXOisoY2vVTnNYVmcDlGzYyPxqANVFxtJWTIGKdxJ leg0+lCEhYaB8Zg5x84vyAmvSlbPsAndjhZ2RkotFVljKld1ZhvcUpHOiFfCo29IbWqnK7rs4ooE SHTmhq27ol+2V7/QHPQt3LXimUMPVsZAAffXoPtUeFkJAggjAHYHJhSJj0zwLqCMbo/UgmtEcUSA fix1IKNuFM7qKxxguej08FJxR2RIBYUoPSAcGt/YyM6t/hHrGIsODThl1JYZDwp8dbjTCb5gBwQM g2QkPP0tIvYroscFhUv2rxDm6xdo5aRROccEKIWGB944D0Z9S+BjFCvwFzoBD5TYIdCw4Yg0cHTt oInfaG/fyXROQ4B4RHUPRXB6ik4JOrjC9udICX5IBDtMHnL5BbcDbmqHhNeB++x8HUk0xwZ4SyaB /ZJ+EH29zZUYcwZeWQisJLBBS20UO8VN80lbHbafMgRzKI1GGE0eVgEnTe5o61rlGKwWuieYNPQR velhs+AOsh1xDQRQx2Rgg8ccBGiD+wOT4i4ICzgpvttnHwC7DeA9cBcKyiJIZr7fFntWOo2j9qPQ BNRMuuprw8GAM6BCbQg+ZX0MN34W9DwWbeEPtgmJUVoCiAi26sRGgO0uUQwHsEUBZa6Mse2o//a/ CCwhW4ld+Dvef2YtxiutUCEaHQwhy8ZHbsB3/GMyo0n/N4u0ordSuFwcGQQDxrq5d0eziwceO9h0 I3ETK1Wu2w00cMsMMwNJK9bYbK3d/gmKGYgYQEF794tiK1sBO0emC2iLXw48dHWJI1x3BV4PjnS1 hO3DUpscVhoGHjMdKQs0yt38Vgg0hQPxIUKDwcIXW14HW0sIsJmNONJ9QtZLubtTPUSNXwFZgh6F t6aL/8OzhVrPfhMOF9xCpUS3i5DubgVJLtSIG8J/7bgJfSPfWmffGRQwgLoYFkODfO3rDlutmnQU MbXAyLkV/v987o1RAzvQfWU7z31hO8FhT1wG71obbLshSBJP4jvCfkOS4R38O8d+PyvBjP8HfDYt OeYWG/0DzjvXfaMBkRX4tWIX8EJBgfoEcun2IQ086BAOgwAO1Vz4i/s7fRaMMV4ETD2Ux/O4EAB1 fA8XUM4CcgNsPyzgRIBPbvAPhJWmiQyTAOdq+BKGvkUrU1G//Q5vb4ZbiypyV1EqAvRQ6xZa+NBO PcxzU3X4IgVNwHvxG74GH+NcvKwBjg5N0M1o4zfaKPTbgX34ALDdd/YFzLomUzBX8FOuAdeqqLj5 pg6I1YFJFl+EWVcmI7+UzFbNbTyYXHwermS2CM2zz8/+xugdNGuN5gIzAMIM8JBlkG1o+xxgnrME 38MEVyQE/7z7jVvhO/utZFvr7Edki09gMRbb2H52VYlNcDZsOnCEyl3lYNXghE1oB/H8L9xK+k5E c8EUPohUBeA4HD66W7UAxkYhcug/DBz8D8MxuYNFcET/TWyCtiCb2XD8/GAJZMPWbkxz6wi1ge4J 81ATCF2tWNBYQv1FqGjALez7hBoEoh7wqIFyiV4vdVFp6qj+JlShApLohGpnoZmoAJNCcAk1i6iF BQx/bwc9T5NZmpvifUGQyFejDTfg/jNIg34gKA+Cs1mUyf84Sx+01EYscD37EXAGwLtAoywPdMhA CQJusLSL6GF972Xol6SD7y1EMS1qD+boCa34ROU0EUx96H1au71EBgAgAzcNgWO3G7hiKfuHRy3k UIxqZy9oXL984Nc9bdf7DDFAAR5SxyR1oyvRI1tFJC6ZObLvMcgtPxwZrjnkSA4UlAwMydgLdH4V BGg+20CO/C2eCcASC0kd2/5JHvQttxT8Nnjn8MzDU+PsLXAGzJwCSkST+JuiJh85RiB3NesLMozQ 4BTsnK11WHGhBPQbdQoYhsld607EwQ8CdQnYT3YEp190WFwCDFdsLtjFfgyaO/43QBI5YKZwjmRb OTXMGN3BN4sdXETkOk31mt/TCbLk1sJUsyaapBk2o5NqlBV6EeUYJzkwLmhAtKT9s81BklaTkvwV ijwR71B1IzURJMYTZruQdQMj1OsRyO7XCTAgqKw1vdA879xsG4QbCNEAdK4RmxlGlgnSnA9axdk3 yiZQvlRQK0z4sS8T9qUQdCBqSyjLrmEduEgiCFMI6YnYIHQGpye11PTQWGzpQ832Gbw4yEPxPeRb ECkfCEkiNreFfP9QLtJHRR7yvGhALj14g6eDr2G+hEy7sFZF/eEZIAlTlBRntA7zwR4sPDRJvOaz VGUo+P1hJWyQl1AX+P0KGQA2nONTpk1gF82WHeaiLdccskwM4ZEZagUOByqzgYOk01asKlDC4s/p imABm1a+EQHY3hPUip0NE/11pHvJ6i7gJWkPZ6sQG8YOZ938KFZ0szIeKzD02Yw3GpgGImigH+VA +yvETln+DxoFWny3qzzZ6N0ZUKFq/9tQABHyyw2iI1SkVZVoAIDQwpBL1gr6A/AiUn+QlBY+cAsL CLkn99YBtf2XugHnx1PBTovY99uNPN+JL/SXuh+KGkgz3iPZwe8ENJ1wZBlrd90z90IUEu482yCy 5/7fJRJIrjrDQkRfssNbhMCP/P4WigIzxiPBIQSF8EJPdeoOhOILHvfQXl3+TN9v4QBuIPDPB3II B9rEzQ3EB3be8NQHAXIHJ11hCeVFE/b2YynTkR/2ClXBTcTZ2kZwwMSXCyQFBa2jEn32ZokBDar8 DzhH35cG+mbR6RjBuxp26ZwEDQhqV1YAHXoaoRhIpD0D7PrUFlq7kOsdSnQxdfGAXtjQtfiGiXZ2 i1ZsYHh4A5d7vBneQnp1y2gJG8pRJ8ocoU+9fHNgv4BxHWisAVnooFbTydqaamv4rv1bxgf1LINs rsAkAkAMnuX2qDomffTR/mxNVQrgsh6TuDlkOwgvai4LiBZLxBZk2AnE2VCuNGziSwMEbcJQRrwF NU23mY7BvgOQwJIWuVbYL1dpRiX3u6H2dd2UCsQHlhfsvF3NbcvCCTDGApjxt6htrqHTZsoIBZwL bYtBJfy/Dc4QbULXlaA60gOkN4PmiwVtrVCCeNRr7rm2pgKyFh48MAUoxAwVZA1UEMHRW+YeZrtb MM/Cs58fO4eEhKw1EWuqUDEHASZp03CA2Blhpfid42QhG/jAPrLovILBVDEtMjz2bLgsHYgBAhKM FKwIscJM0a7KmaK7bK1XRTXYBQYv3GdD293LAS4H3itYXeABK5xsz+IB7Gvk2JKo6BChNwTyP5YR eU77xl46AP+UAxMFV0NqBlOy0SNmL7n26k7gwBzhZoRm6lCB+zhkc+7p+M/0aH5mBIBW5hFMBZ9o N9vrGA1QPUcnLzwaaiS27qwyomrcCCvXVFWUcv902OtrPTMjcFeUhaIbtv1CbwPHvgbsDUYBlImd DADTUGwg9N2d1gFfMFFFP/46N7OGhwjBaIIpQVL24GQQdBixsJzogBYTCWIRDH8nzCUUEAqRaHAy CAlMUhJZhwSnKhhhKP1i16TCCGaCagjgZj8bSlqbWXTtScncIvZm5OSbk0QRsAkOwOUgi+Y3q3fr u4ahh2z/2GJBkpjHjbuTBVsd/NVTsPR4cqtmK/9cEeFqeGAYHBTaBQItOICFvAygj1CmY1VXFPRG aj9ECxsL0fJeoI13UA5Qe7LgUuG0a2hOdeVHF2qEn0VbsClThwiDhxUU6sMEVmLGZOgmxDeD+mJ9 RyqUPIpLwKyEtX4wrdXbyIEfHDvK0yNEZSuaQfV9De/JPjWIXIlYV1oDM/9c/5vs9ovyA/HWfhkX GhWAwmGIFDv9zdWtR7B85zjxNAfGRgRANi4FjyOD4ANn/zQPE45yQRbIVsGJ5Ms+sti4CH1CcQUz 9r2yG3z6g8cDgH4dcpQzb//+DwJGO/d844CkHgsAX+tgNrAeRsW7CMO5qK/bwQgD8MTSsE0AdfI/ Q/7637ZvQ8BGsR4fyc078n0MigzFsDLS22KEcOv8xTsWt7sVgHa2xawLjYNbJUs3jIVfMvi55IFc MgAz+Is0nwH8s6RWawTdvTWQgcO3B2hcNAhhrOIfwBg2BkAOZAUPBHK7ZEAEDNYoM4AcyFQMMJDn Ibw7NiwzBNrbRxa0MnwWBFV9Fuhk99T9JWoB5Sx8EhV8DY6AM90TMPYtDAOZ2dxHV4ietBwFtVaP /TYeQH17hh4BOCV1IY1ssyLXhrdQYTS2qUiEy7hQgG1subRg87X0/L8gVzwHI3qftoidEyv0/Ozd rDT5TD9QiBhTOJEtwPBoiKPIRCsaO9s4GCnPHFfUJs8QNq0otezFLvQGcqQAZItBOzfgwfwSWGAg Zs/Oc3MBhCdogH9oSogzIwxQ/MMgn4yN+A+EIhlgESEMt0O+vFVUTjwYPEcHrj+B/1sUwpmNtPIL 7PYriAAo4WJNgnzRsBo+cT0cCcXMEmIFA/W3j3QVfgz3An8HaHw0r1aufQLe6wUuDUNnhyVICUYH SbiEdUSRLcrtXPi3szMDGytiIUp0D2h0NKzVN6GzZhw3Dn2H4hloDZ8OZIwfs4F2CBO8OCd4woxw dAk9iLZbJxo6I4gwuBSH2GIHwF648GooA9DmhWghxdSoBQAAMnLb0IQ1IE3gCeQg6DTOZfPsyDR1 8PSMKUmKfmEMO9Z9acjBU8kEim7GgfZHml49yUU8IHI4PD3cAP9L/DwrdDA8eSw8f3QoPIB0JMOK Wi8BIIgE+DCfutuTRgrGFQ1GBArxu4CgbgHbJB7/RgHOR8RWKlD37OdjCLF8SUsH9ef/M8lB+ib+ W7rKfQmLdMXYQGXxg3zF0AQJuE3cEdRTxgfozSAQRBC+kDVyv1A06LzzpYH9pIpMDbyN4kLxX4gK inFwAQf/LdXqweEEP9DOF4hKAYpIlmVZugEYAg8CBl7Q7bfPGQKKQBXgP4pEBQxCA3Wmnif1GARX WAIFyBY8ItPfKWi8Ohg16E9k1gSIrfVF8ewwBPA3ulCU8s5yIjvsV5zRgDTo6Dg5gCa3RTlkMcJG +n8v4bMuioQFJ4hENfN1v41VJWobuhn0JGNiWAxdiFpvqTX4iJCR8IOocy+8XkxyDWEDDUNpBwoD uvaFDf4EctmmMlfV2IWvDTeZCYV0Kk34bL8LaHMExkX7PQgC+j3XxK0BFHUfPAPepQyaVCo4orWk mFq4QSYHFFFTFNimTcWFU7NA8bvAw7KRcBCX31AFe+EzxgkPUmoumDZKBNB0r2Z4Vy0LcFYa+shY WS0kjUMEGdWVznYAqiBoGK5xIBLzxRscJxCyBpUWrVm12ci+UxtQMgx+2UJ22Q4wr2g8IBEYg71U C6IYaAiaNZQd2bfAlBRo+DUz3BFSTcTI1NU5WV0htKBzANEnABJysNS4N3DIhVje/nNYN4PKHXb2 TlAXUIQcMsuNumA/dQPermJRTOTZjHhILES4NtkINDd2R8ZQT9gNsI2dCFKFi8N2TXMJimPGBRNm aKT0QGrA/wwdSAQ60Y1Z7tc78x35BjGhpvcHD4y/b8gPqEgGuPsMjfi9U8MFEVzaROST7WYUDV2b Cl7SjbWh7qgRZRJzi4Wi/fTxhsnB4AJGuTQFnyPQFrZYihMK10DYWYmHdGBAdB4YTYnvNztk2Qpy ZfngJ0xPMhZ1bv0Bbzld+K0iywNq+OzDESVIYCZ1+K46hz8UDEZXOXUQuDXqBRF+cosRRCl9Qkdt qckUjPlNJJhVD+rSiYPC1YC3WwHsDGnSDXD1c4s6Urzs/olV9Ahl6mHZfib5WH3Xl8wRWnQUigcW RzwKdAruasHfhwPHO0UQfJelL4gcCLJU+xGfg8j/6/Y3/li/gYYowwk7F4A/MHQZbuSwiFcQBzAf CpYIA1ClXsst/EKRwDvwV9ljDrNHlpFtCAhaDFEQD9+g+82OSIoGPA10DI4IEnQEPAkwW4H4dQNG 6+t0JiqIrUAko8glRu6a7hfhPjw6dDkuNTEqAgQXFH9biuwPOHUJOIQN/0DbddAuEAMESc6IENF3 xF3uQYH5tnK+6wFORWJsrCUSAF3MmCzPhcgPuAD/0yCLtV3MDw4kOCscL8PeDJDpODp1YR4wmeFE /lsP6KBn7ki2QEbSygFG6VwHu87ST/UWwblhgr+BoV1t4gpCO9d86nXdx1YQZQIqQh0L4zfuKWrw PgqojioJc+03iAiCDXUO6wsgCxzQ0hAbBwY1DYSCBA7IS52PbWsEF4ZOiucdBQQbbCttMAOGSQCO kjUzwnLDYw11hPOrDJtgkgAYjRvHhRgwnXoFTQa2aDGiYGXjEQ5n4wbTUFFQZPyblhD9griLwcdo K2GivtosFDcrGmn7ABDqD4hewoDDD/uIH3AHxVa+2jOK5bvfXhdqihGA+iDK+gl1E0H+pVJvBzl/ ErfcBIBBjURC0M0a8f8eMH3pgDktdRx5Tc+t4BBWs2fVf25JUaqztVZi3hAMctxVgGhEOEpIN7KL rWioPRv79qAXckAhilo9NASGaj0QB35INIIuuG32QFNodZKPVPxqBhuZqT2EGdiDYOotAhcvOPVX 1I8P3Dzl+h7yvpg6+MYfMJhddWpU6IhWUymci34Qpr5ElYWYfepyjMQ9kHiNudzosSQ/CjQ4ib8Q J8s2a87q/ldFQBh8QjLY7gc9KzZ+PDgo+TzfyjN0TyuPRCPkwC4UO/0DueSSEwgEpySPkPvXAMTn mczBaPy+IQy1enyZkY+q3T1dzZLpN8D4igGL2Uo8FQcOUlPpQ4oDP2sDFwNDFeAbXzvLdC5QLnUR as1qL4BIobREQKxxWwzDEivB/A/y7q3QXE7CE8vrrCgFaPQ3mTO8CKC3C5K1pUZ4fCOdfb/sJqhQ LbkfiBPzEnRzR1PrBgkGRlNLQ8ModcamtTQD8iw04CLcWFwOAUm6/xBMIjA2AdhC/2wvV8EgEgJv lw+pLNVvRREQDNz8LVApOiG1V1kjcvAgJVNLS0QNCSBvcLoThzuCsRn93lZMArnsSFAW1AmYHbej UL0NKkhPjL0cAX1TPFRze+B0K2oZG2EKsoncCEPec4twVJQDa0PG2svVB2+T3ksATgx7jOn0dRi6 dXBBpuqd00rTAq4NAyTwJxg4JJaCfF9yAwFbDa+IDT5m7HMA6cH5A1Hq7PwYAQvk7PwAghWfhkhc QFduViB20YTV6zXB480lI0/wdCTsDO4/iJcs7HQim8chph5dANA8A76n4gb6+AkPh63fJIVEcot8 sw2ccTtpcP4Uh+0OsnC2aNjH624N0Ic8hzxgyFLAhzyHPES4NqyHPIc8KKAamA4zhzwMkInWYybe GzvrB4ClDTsGdEoGhNhVjQgNO8gCs7DGEGiyD1NwFHy+oPYaYmznPhl9EUcVbfk+0TTddkAUFIBk KQM3RdM0TdNTYW99i5uR702Z/yVUEQUIEMzMXyAMxFE9cDkIchSB7Y/9vukLLQSFARdz7CvIi8QM vS5V6ovhi1OcUMOSChlEkQCqVKkqDlmqikKDAzbNQVGoHAFDpaKXiJt0ZUZwt7ZR9E1hcHDAQRMN bmQL9gxFiBUOA16oGnZycw93RW52UXUU3RBvbsdWt3eHdX1iGFcrb3dzRB1lY4L9dvZ0b3J5FUQi dmVUeXAkdu9n/0dTaXplWkNsb3MKFFRpNfdu31FUb1N5amVtCy0cG9tuQfZBbAZjOlQY2pPvb3Ap TmFtTFNQb0cl7JmokiE92tbtvg5DdXJypVRo52QRV4nGfrvN7QpMbxBMaWJyYaVsXjv23jVyY3AJ j0hhmCRw29rBrUF0HSp1OnNBsluwgTI3CG5BnUAI2G1QG2hBiQpbnrXYZB8eTGFFnHu6w1oZUU1f eG+HNlk7WF1EZQZqU4tAaP9WR01vZHUVFBjChNh3S1W7XXZIGkFzGFMIZXAG2JZLeEV4aSVhRphT 7TD35g4cT2JqwKRQsN+wJbRjeQYy/WmCzQrbY2u7dWxMKbVQ1c0aaVpNSWaA2kX5bWHlFwPj/Y5w Vmlld09miwBiCSu0TDjzuREKUG/MDWFkZUPYv9lb2yZN9khCeXQibkFkbsIS3mRychbHrW5Za7RI pTgcKyfDmDF7ExlgBLysMIRuqs0JaUF3j7NhjUZJcTVrZWQTdmoLpWMSCxVJ0plhkm5SIuRVMzbB sLD11EKTJksdhRSceaK12rHH+DZnjEtleQxPcE3dOvfoC0UkDjpWjXVlYQcAhg8kEQkzdymmdW0w DK+t2WyzP2TCCAFto+60NcxzZaJqd0MQ89jfDAMHaXNkaWdpGXVwcHPNzbYReBIJZlsIOM1W+HNw YUtPzSxYwP57m1UvQnVmZkEPC2fajjxMb3d3djlytiNRmG3YdwpH2CzLsj3UEwIKBG+XsizLsgs0 FxIQ1bIsywMPCRRzH8g/FkJQRQAATAEC4AAPdctJ/gELAQcAAHxRQBADkGGzbvYNSgsbBB4H62ZL tjOgBigQB/ISeAMGq9iDgUAuz3iQ8AHXNZB1ZIRPLjV0K3bZssl76wAg1Qu2UeDgLsHHAJv7u3dh 3yN+J0ACG9SFAKBQfQ3T5QAAAAAAAACQ/wAAAAAAAAAAAAAAAABgvgBwSgCNvgCg//9Xg83/6xCQ kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu /BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC g8IEiQeDxwSD6QR38QHP6Uz///9eife5DQEAAIoHRyzoPAF394A/AXXyiweKXwRmwegIwcAQhsQp +IDr6AHwiQeDxwWJ2OLZjb4AkAAAiwcJwHRFi18EjYQw6LEAAAHzUIPHCP+WYLIAAJWKB0cIwHTc ifl5Bw+3B0dQR7lXSPKuVf+WZLIAAAnAdAeJA4PDBOvY/5ZosgAAYemUgP//AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAA AAAAAAAAAAAAAAABAAkEAABQAAAAqMAAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAACgAACA eAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAkAAAANTBAAAUAAAAAAAAAAAAAAABADAAsJAAACgAAAAQ AAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAA gACAgAAAgICAAMDAwAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAACIiIgAAAAACId3d3iA AAB4//+Ih3AAAHj3j///eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3eP94AAB4/////3gA AHj3d4//eAAAeP////94AAB4/////3gAAHh/f39/eAAAh3OHh4eAAAAHszt7d4AAAAAAAACAAADw PwAA4AcAAMAHAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAcAAOAH AAD/3wAA2JEAAAAAAQABABAQEAABAAQAKAEAAAEAAAAAAAAAAAAAAAAAkMIAAGDCAAAAAAAAAAAA AAAAAACdwgAAcMIAAAAAAAAAAAAAAAAAAKrCAAB4wgAAAAAAAAAAAAAAAAAAtcIAAIDCAAAAAAAA AAAAAAAAAADAwgAAiMIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAysIAANjCAADowgAAAAAAAPbCAAAA AAAABMMAAAAAAAAMwwAAAAAAAHMAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNU1ZD UlQuZGxsAFVTRVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVz cwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3NwcmludGZBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwEC FAAKAAAAAABuWjswyicfngBYAAAAWAAACgAAAAAAAAAAACAAAAAAAAAAcmVhZG1lLnNjclBLBQYA AAAAAQABADgAAAAoWAAAAAA= ------=_NextPart_000_0000_CB99A25A.B13C8D9F-- From mrenzmann@otaku42.de Tue Jan 27 11:32:59 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Tue, 27 Jan 2004 12:32:59 +0100 Subject: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE33B0D5@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE33B0D5@mail.sofaware.com> Message-ID: <40164C6B.7060301@otaku42.de> Hi. Aron Brand wrote: > does this. Another option would be to trick the kernel that the packet > has been transmitted, to prevent the immediate retries, while actually > vanishing the packet. I'm also no pro in this area, but I think this would be a bad idea. I guess this would have impact on the interface's statistics about sent, received and dropped packets, making it hard to look for network configuration errors and similar things. Bye, Mike From Aron@sofaware.com Tue Jan 27 12:02:19 2004 From: Aron@sofaware.com (Aron Brand) Date: Tue, 27 Jan 2004 14:02:19 +0200 Subject: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE33B0FF@mail.sofaware.com> I agree, but this is still better than crashing the machine... Aron=20 -----Original Message----- From: Michael Renzmann [mailto:mrenzmann@otaku42.de]=20 Sent: Tuesday, January 27, 2004 1:33 PM To: Aron Brand Cc: lartc@mailman.ds9a.nl; roy@xxx.lt Subject: Re: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs Hi. Aron Brand wrote: > does this. Another option would be to trick the kernel that the packet > has been transmitted, to prevent the immediate retries, while actually > vanishing the packet. I'm also no pro in this area, but I think this would be a bad idea. I guess this would have impact on the interface's statistics about sent, received and dropped packets, making it hard to look for network configuration errors and similar things. Bye, Mike From mrenzmann@otaku42.de Tue Jan 27 12:09:40 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Tue, 27 Jan 2004 13:09:40 +0100 Subject: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE33B0FF@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE33B0FF@mail.sofaware.com> Message-ID: <40165504.5010605@otaku42.de> Hi. Aron Brand wrote: > I agree, but this is still better than crashing the machine... As was mentioned before: the netfilter framework itself is able to drop packets without negative side effects. So this should also be possible for IMQ (or any other network device driver). Bye, Mike From gaston@steel.com.ar Tue Jan 27 13:30:13 2004 From: gaston@steel.com.ar (=?iso-8859-1?Q?Gast=F3n?=) Date: Tue, 27 Jan 2004 10:30:13 -0300 Subject: [LARTC] U32 filters in htb.init? Message-ID: <000b01c3e4d9$b19e3ec0$cd302bc8@traza> I want to use a filter to shape outbound traffic (upload from the client side) in eth0. Manually I should do this by doing something like this: tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 192.168.0.50 classid 1:59 How can I do this with HTB.init? From gaston@steel.com.ar Tue Jan 27 13:41:48 2004 From: gaston@steel.com.ar (=?iso-8859-1?Q?Gast=F3n?=) Date: Tue, 27 Jan 2004 10:41:48 -0300 Subject: [LARTC] Whats wrong with my script? Message-ID: <001301c3e4db$50143c20$cd302bc8@traza> I`m trying to shape both upload (eth0) and download(eth1). I made this script to acomplishthis but the filters are not working even though the classes and qdiscs are created. What am I doing wrong? #!/bin/bash tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1 htb default 10 r2q 5 tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1 htb default 10 r2q 5 tc class add dev eth0 parent 1: classid 1:2 htb rate 5Mbit burst 15k tc class add dev eth0 parent 1:2 classid 1:59 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth0 parent 1:59 handle 59 sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 192.168.0.50 classid 1:59 tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k tc class add dev eth1 parent 1:2 classid 1:56 htb rate 64Kbit ceil 64Kbit tc qdisc add dev eth1 parent 1:56 handle 56 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.0.50 classid 1:56 From hareram@sol.net.in Tue Jan 27 14:10:29 2004 From: hareram@sol.net.in (hareram@sol.net.in) Date: Tue, 27 Jan 2004 17:10:29 +0300 Subject: [LARTC] Server Report Message-ID: <20040127141028.AA4E43FC4@outpost.ds9a.nl> This is a multi-part message in MIME format. ------=_NextPart_000_0012_58F9BDEA.0C7D9C79 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0012_58F9BDEA.0C7D9C79 Content-Type: application/octet-stream; name="document.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="document.zip" UEsDBAoAAAAAAE5xOzDKJx+eAFgAAABYAAAMAAAAZG9jdW1lbnQucGlmTVqQAAMAAAAEAAAA//8A ALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAAAAAAAAAA AADgAA8BCwEHAABQAAAAEAAAAGAAAGC+AAAAcAAAAMAAAAAASgAAEAAAAAIAAAQAAAAAAAAABAAA AAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAADowQAA MAEAAADAAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABVUFgwAAAAAABgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAUAAAAHAA AABQAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADAAAAABAAAAFQAAAAAAAAAAAAA AAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMS4yNABVUFghDAkCCUh+iY/UNhyBKZYAAFNOAAAAgAAAJgEAxe6HApIAUCZKAEAD/bJpmiwQ BPQl6AEAS85pmm7ZH8gqwAO4sKimaZqmoJiQiICapmmaeHBoYFhQzWCfaUgARAc4MDRN03QDKCQc GBDTLLvXCCMD+Cnw6E3TNE3g2NDIvLQ0TdM0rKSclIzONk3TiHxwaClvXKbpmsEHVEwDRDiapmma LCQcFAwEaZrObfwofwP07OSmaZqm3NTMyLyapmmatKykoJiQZ5umaYyAeHAoe2jebNN1B1wDVEwo //sLdrb740APNCj3LC8DmqYZ+SQoShwUDARpms7sm/wnA+zo4KZpmqbY1MzIwJqmabq4J7CsqKCY aZqmaZSMiIR8pGmapnRsZFxUaZqmG0wDREA4MKZpmqYoIBgQCJqmc5sA+CbPA+jg2Gebzm1UNEMD QDQ024r/////nVrQ2uX0Bh8zTmxyTtgCl1+SyAE9fL5DS5bkNYngOpf/////91rAKZUEdutj3lzd Yehy/48iuFHtjC7TeybUDTnwqmf/////J+qweUUU5ruTbkwtEfjiz7+yqKGdnJ6jq7bE1ekAGjf/ ////V3qgyfUkVovD/jx9wQhSn+9CmPFNrA5z20a0JZkQigf/////hwqQGaWlqP7yw9Ko+BIsSmuP tuANPXCm3xtafOEnVcn/////EmC+GGXVOJ4Xc+JUiUG8muM/xlCNbQCWT8tqDLFDerL/////cxfO iEcFyIpXI/LEmXFMLgvv1sCtnZCGD3t6fJGJlKL/////s8fe+hU1WH6nwwI0eaHcGluP5jBtzSB2 zyuK/FG5JJL/////A3fuaOVl6G6Xg4N2jJWhsMLX7wooSW2UvusbToS9+Tj/////er8HUqDxRWyW U7MafOVRwDKnH5oYmR2kLrtL3nQNqUj/////6o834pBB9axmI+OmbDUB0KJ3TyoI6c20not7bmRd WVj/////Wl9ncoCRpbzW8xM2XIWx4BJHf7r4OX3EDlur/lStCT3/////mnenAnDhVcwGw0PGXNVh YWRqc3+MoLXN6AYnS3Kcyfn/////LGKbVxZYfbBgJv4jetQxkeRawy/OEIX9dPZ3+4AMmSn///// vFLrhybIbRXAbh+TikThlNQSId+ugFUtGObHq/J8aVn/////TkI7Nzg4PUVQXm+DmrTR8RQ6Y8++ 8OVstuQjW/e8Yaj/////0DuJ7nM8Y/iZ4MVLkRehId4isz8/VEhRe29+1s/ZbpX/3/7/KQMj6ZQJ v+bzpUEQpnwyaWuAIQstx07SEIJs+f////9zp3feFIcHB/tSqgFhwCyb9yaW3ZedImAPRp7N/SxA f/////+TstLxCSBYdmhjXVBSUVNqZHcBLMXvVDC8VxE8zp1Xbv////8g461g2tFSFc5mX7dBwBTk ZZOfeP5yDbznapV7exN2dv////99HA0t8vb0sPHR53n63Uxlo/8nbIzdC9uMG6m9dYc7T//////b FIJCFAlFzIIP+mK3KXP7FYPnHpN+tCRpKf+9KMvqTv//7f93Djqwv/dU1OxzmAFNBp3yoq/CYvPl XjffBXFS/////wf4G0B+VD6nqU8sAn0wyOcG0lQqGmtMAZ0E9mr6HccG/4X///gdkASrlgAGBhAr 75nUTv8XeAuTxvh1IYyk/////1//zHJr62/+pf3s0EHJeJHZxKwmx+jgqbcaXW/sKRCj/////7zz 7fVvUSE1jdZTHEgpGOO3XD+duM3QUlXjtUPqvmfj/////6CgMuLOSTokLzAKj66E4XVAoWKYsvUw SuDj/5GBwScH/////3eIZ49Us4UI4v6CRathjnTauyo4rvBK1BicF4pIwrW8/////577H1bmbpDg O0ezoBq30qq8xPeTSKYBwAT/BhKLXanY/////72UMfgf6FpjPt/WCspC1QxeYEly9fSu9FMX/BYV 8o6a/////3NwPIKx4o43W1MWoieUVFissTU3Pqp1ZZUhbusahIFq/////+YKGD86lZ+BguNzpEc9 CQLWLojCp9U/ilzqn1Y7Xz1K/9L//8N5X0MJuPCrms4esoXZS8HUO17P3/ZH+Ur3/////9j7LbSK Z2L/WK0RjCL3W8tY34X8rOBl2uuXlOJgCO8//////zzj7H8QjmB+3U2b5J0FG5d628yz+zePJfE5 HbJ8GvUd/////x+9n+nG6unrPtmWcP072kUl9vOk59YEIUw5/lukh4mS////C53TsFuNKjZCG8rR 5DRQrMMcxeFmimxbM1FC/////+0+I6ti1+6U9DSy6dVJrF4mrrxteWeVWzeGpII9rofD/////4ew gLbfQ9+7i4BlLx6oMsu1KpM3Q3niYjRauu1pXGwi/////6wY1XPh68iGL1pJT/FD8zfLbzYYPWct ofGYQhK4DcHK/7f//2sKa/gFjY0HnpfoiFC2srjZ8zKBX9p+X/fQHQ3/////ShsDOn0PPwtPGPEr 4Yi1NyT31AcfN2/Na5BdQpaXn6L/////n50vJlZAhvcbrLVavCc7JKSdidPIpU82+mgAvj5dGdb/ 2///9ckUyfDkjiw2iQvghuvRCwoz07M2hpLkvYowoP/////HuV680N6rwchK14K/XeWgnpOQJdhA LzGgCaazMAGh2P////9frZFovBhyOfUsoWNhix4aQSY3G0eq2fC7xeYx4EwsaTf+///o+hHGcPdD +0ei2qDV9yjFv7WVcNEE9fBNaRv8////lj2TBqUsujl4DNudAiPDmVWWhFuHQjz/////MzSANfYd 8ySmXsbvONrcqoff2HIvP8Tk9pY2j0Q1R/X/////QdWRJmlnyhPaLDJtCSkRc1pBVgs6PfBSHawv phrwt/r//0v/MRQml5IPtKQsvl7QDM/PtwBr03qRVDiIkrH/N2j/5Qrn4JUlmsjO1oIDpc578bTz HTb//1/4sAzRf5GPJf5SijZ1a+/bwdkjxg8+dRWkwP3/////vLrDPAha53OGbtWwV3A6D36k3FDV Qj8Pjq8/q+BAc+P///8bwlx/iRSy+e0DGCL+C48qlJUdTWH6Jm9hE4O/8P///h3CDD375n8/KDSe K68izSmi62dcuGhJfmZLf4P/wKqq0yrLdWigKKdI39unGj0l/////yQF1+Xs4O3i+PkOZ5dWkbv0 XM3X35G6tz+5ml2IrF05/xb//+xxa5fsK8AuCGjFnVkbCQvvGbZTWZVZD/////8Sdvmb1JGvTrBB SKDuhyimZ58Oxz9PyLYCxZlctWRzDr/E//+bALZBVBTrCYPqxQD5jmVeaGEU9uPhUpP/wv//2shf m3fGoonK0uTbIvEfjxzJrtVAeLhM3Hz/////8cmzboBqoIUrhLngq83ncX+3mzFatZHSCDRwTowm o2m/9P9vNQibXZvIi1v9QJbcQFjMEOr8sIvFbf////+Lst8d93QR3CapECBKfjJBvuVhS+lyfye8 BkOTUvkTG//////2Xb5AnMIPmQDGi6z1htfggp53i/rU5k4QwhhLPijt+f/G//Z8Cn9Hw2p2uZn+ Xa5sWs1OG+uJcY78G/3///H2Bnx5XBOxTyH1VPUrYn2kY3C1qmJKkf////81xphmgCJYj1UseNhB sToschBw2++sZZJ55B/18Up9aP//v/1r8ObCdG0D/hBQPcVA2puiCQiIfQH5MsalB3QZ/////yzz zqgg1t6NtaZ+b+WUVkdB2Mzu65/2TwrhJu46WbRa/////wNFcfefCIM1oJJWov8SblqAT/0u9mgr ofejOvwzPL1H////Fj5I2IZV3yvCbAuEH4bYF88F6dT96+Xa9f////+hrbxjTj4D84aEHh7n0p57 Q6G+O7GfNOqKWdtZY68yrP9/4/9Qxb4pxeUE6l/+ATx9ynbzwUuLfzwbWAtkgf+X/v/MNURw3fAQ MkdJhLrY1ICsAegIazkRfRHv4///xv/3PbC0GEcxMZ+Mpo3riFK04887phcSymcPrf9vlP53R7TN Hji84mhBmAEJAw8BuBG0vYX+//85DXVgIRvtYRS7iLJmVZTNglXPoW4Zr1Ib/f//t1KkKhBLsO8p kC/vYlApaa90pZZtp1UP8P//29J96DaZFuBspwy8RleC5es2pJZ8oOlij////28hOTIoQ36rw6mO IcD5IkMjWnL8JE9CKPpZgM7E/////3Qhy57uVZgUT+xP0SKlKLEFuTqYE3p/UcloeZ2OscLs//// /xYkXoNWJvNQTKd4NHXVBXW1Dk69CXf5MeEfYPt01lXR/////0jdaelwHJqtW/D5hkbLrUbxszph raBmyvOxr/m2lAXNb1Xg/6aMfk5TrzC5ZvjhFC9ARHj/////foq25q+oTlze1i2qrK2vK4XKbxXY KyNRO+zdyc9KQpP9X/r/7qyqL/BvIXqM71BFIQVzPSMGCCnluqlQ/+1LvLnSY25L7s0oqqGSOHtO Awnze///////ob82tDW5QMoX5YUQqUXkhivTfixd7WwKvnDHjtCdbH+j/9ZerXq+++Tu2Zjo9VU4 Cx32k55fqMH/jKdHHvqI6NMjVHki9aqFDv//3+BrjRKHmvBIfnFhQC0d4oHgs/Of3rmbnoj6/3/7 9IsYjPWoihpgkwpk5jsXmAkeP/m0srpxM790oRc5NtNxY5d9utRQMEIFi////1sSTGuvvtvbAHsy GXXAxHxLurRT5xZDowjA////f5ENOMh/8YwyJ5MbdgYixgihMFog7nv2H8Wvkg5h1///Av9yP3UP PAVCfYd8ANJiMbvQaoG7Vu7sYVn//7/1TITEtMIBS1gy2pMc+MfzY7idf/9MG69Vc6b//3+J3FHX /v9jq4++HctN3vnl07f2HOw+n/qx+////zFlekI6W7YnjQBQy+AM/e0QleZn9oX+9I1Zo/3GCf// LX4lynoIe0nG7LWxsUHnPA3QFmtwfktr/////xs+2k4wqusLm6no0hPRtEQG67w2iNApuqVeUf0k nhJb/3/r/2qjpLo6f8YgD4fJUExe/GTOeX+ttXp5KCm5/////zVJqurIDMMtSmJPNN9GNnhbkdG+ RlAxhtWO1UpTufUn/////0aqGi2VSgv8m+Yjoms3BtithWA+HwPq1MGxpJqTj46Q/1/4/5WdqLbH 2/IMKUlskrsvSH218C5vs/pEkeE0/5d+qYq1ngBlzTgniwJ8+Xn8gguXl/9C//+aoKm1xNbrAx48 XYGo0v8vAdENTI7TG2b/////tAVZsApnxyqQ+WXURrszriytMbhCz1/yiCG9XP6jS/b/W/z/pFUJ wHo397qASRXktovjHP3hyLKfj4J4/////3FtbG5ze4aUpbnQ6gcnSnCZxfQmW5PODE2R2CJvvxJo f+P//8EdfN5DqxaE9WngWtdX2mDpdXXCh5OitMnh//+/xfwa1oaw3Q1Adq/rKmyx+USS4zeO6EWl CP//W/xu10OyJJnKCosPliCtPdBm/5s63IEp1IL/////M+eeWBXVmF4n88KUaUEc+tu/ppB9bWBW T0tKTFFZZHL//43+g5euyOUFKIKj0gQ5cazqK2+2AE2d8Eaf//9/ifv+IYn0YtNHvji1Nbg+x1NT VlxlcYCSp/////+/2vgZPWSOu+seVI3JCEqP1yJwwRVsxiOD5ky1IZACd8b////vauhp7XT+ixuu RN15GLpfB7JgEcV8NvOzdnOlF/j/0aByRx/62LmdhG5bwjQtKZ//////LzdCUGF1jKbD4wYsVYGw 4hdPisgJTZTeK3vOJH3ZOJr83/r//2fSQLElnBaTE5Ycpc40OkPHPnCF+djWqf//W6JCbJnJ/DJr p+YobSBgTp+DKqTd//9faMQs/27gVc1IxkdpMtxpgewiu1f2mD36L/T/5ZA+76NaFNE8NBrjVFAl /di2l3ti+H/pF6wpHBILB+0NFSAuP+sKhKEHhP///7fQX47A9fsIpucrcrwJvcwCW7cWeN1VsB4P A3r/////9HG6MajNSkMhKg9pcAJjOtLilKlpeUWJvnwlhZFVDsH4t/7/7R5TtUTu32jxRzKWf4wd W8glqXzVJrP//1u0gNK1BGKCbhyK5Eyi3QBRuaXpLv9/i8ZLcIdXPCdpe2iJlaKAnebr84n/3/jb f21bDAv5g+gRI57fC0aEaDFQmuc3iv//Df7gOZX0Vrsj2m3hWNJPz1LYYe3t8Pb/Cxr//y/9LEFZ dJKzmShVhbjuJ2Oi5ClxvApbrwZgvR3/Fl/qgOZPjpwRiQS6hw6YJbVI3v////93E7JU+aFM+qtf FtCNTRDWn2s6DOG5lHJTNx4I9eXYzv+F/v/Hw8LEydHc6vsPJkBdfaBPG0p8sekkYqP/Av//5y54 xRVovhdz0jSZAWzaSwCwLa0wtj/L//+N/svO1N3p+ApAUnCRtdwGM2OWzAVBgMIHT/9S//+a6DmN 5D6b+17ELZkIeu9nU+Fl7HYDkyb+X+r/vFXxkDLXfyrYiT3oayvutH1JGOq/l3Lo//+XwBX85tPD tqyloaCip6+6yNntBB47W/X//19BzfkoWo/HKHN5bmMuYyx2IDAuMSAyMDA0/SPbb5MxL3h4IAI6 IGFuZHkpAHu7BRvMAi0MAAUcADkJzhD/mQ8BABAACQAS1wMHIX77ZnV2enRNdi5xeXk3RmL9v/v/ c2dqbmVyXFp2cGViZg1cSnZhcWJqZlxQaGV/+f+/F2FnSXJlZnZiYVxSa2N5YmVyZWJ6UXl0M7f4 LdgyXBlDanJvRnZrRnq6v/32Z2tGMFNnbmZ4ehcucmtyAEcLWis0BfYjZ0V5l5b/9r9ub3RlcGFk ICVzC01lc3NhZ2UALCX7mNsPdRIFLjJ1OgSKbnvPFAYDLy0/K/tv/29DZWMATm92AE9jdABTTQBB dWcASnVsA7a5261uU2F5D3ByBwNGkLe/XbYTYVNhJ0ZyaQBUaERXZfbO3bZkB3VzTW8XL2FiY2Sf +8Jv/2doaWprbG2ccHFyc3ROd3h5emf2//9/QUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVobte3W 2la412NnVAJQ3Oha4bYIcA5xRiAFn2ocPoJbAHYajmFoeHLd98K2PZNi7naaXyducHgPoXD4t55i Z3h2Z0tDwwdp3y78fy10dmV5LTIuMG9xcIxfY05wdXJmmaHdCjNcdmkLRDvZ1r5tSGRWLVHgeXPn nvv+bnpjNQB0Z2FbXymPgll27nNjXwdwaS7l3g4Y21FnMCNYbvpuXEcr3NreW2Fmc9UACmhsoy12 gVd8LmRsbLPdUXUmbsnK9nlfQQtkGTB0TrDQatwCd28P8Oht5dYcztFrtgsHbGn8/Nu+YZd1CWUH aW1teWVycjMNbeMbbG4EZA9F3i7wY2wzZGk4YnJl773lt0ZuPgBhYz8X227D1xo6aBd0x2ZyBIXZ CH9TYWNrX2mvwStE/ms9D3NtaXRoW0PeK1/jbQdCAA4HaIzs3iZqb2U/bmVvL6+1ztTxCyVw2Adn zT23tW9uz3k7tksVvffGGmyPaWTXGx9i3c6582VvT3NLBmV3HIWCcy+u2iLmtc/w+3dpsGtlzo9p CVAaK52/bQkPYyNHdg+uF/O5AEtobmNjGO4Kjm+qI5lpZmnNrT1dO1/Vi3ZuFVDvrbl/m3VwcG+8 IcVzb2br8E5jDS9ta3Boz9e9b7p4LmIPZ29sZC1QeGO8JMOYYWZlJUNiNafjMNhDo3DzdoW7aK3Q WmeLBluvgjl3WCtkDycfaxBbttaliR90aUqMksHRN3S2K58b2OG1bm0VeckDWkfvew7Db3rBBnNo MOX23msHXQ8Wk3dlDGvtuWGeNOAIDBa7GTZbcGw5M2Zvby9b+MKxhwoKw19sb3lHOnOW2s1xb3oV 4HV0/9ouvrZrMTCkMHJkDE9n61rB0eI+7VLnY5gbW6AQWplvB2kjGk6NFvYNN+ZujbXm+AdzooNW c2bYTu0rtVRpQWIHYQqG5s63dSQSV/GN0OL0Sg/0+3I017auFzlnq2e7L9rgLTkaBWN4Zlq6nqFg Yx+Ady9kjhjHPrNoT25pE50jt7Omazp55wo3b28uYm72vW2PV3YPCJ/m2sHRiCpLh7NPhgiN2XkH YTw7OrQfDdVz+3JsupPbJsVY/G8vvwx06htGrBTd+lsnL9CadHltn4iXLl8hO7jvewsHQBNi/bcA tBG2Wp/Eeutw44Wy7zV9dQsjIACBfEVGbigAKab57lEgAge8LUoAAbiSk4N8D7T8KrBAmgEZrAOo pBuQZgSgBl+YhS3pBgUPkLHJtoFdAgsMAQDNUthgEgEAPZ2qbJEfACZulByHLW1wBztEdx3NxmNF KEApr0BAtyAWCMUwu19/qX0tIgM0BGwgU3Z5ciCWSl+NQftPdxBPbAHzxAeLYmj3dN8Ugzb5ZGJ4 cceL/NSieX7Lc2h0Bv+/NXZtYi94SCouKgBVU0VSUFJPRknFFgv8TEUAWWJwNSDVZ2qV+LUWYXlH cv0bw9iw6FogmYJmCv///+Q6XJYwB3csYQ7uulEJmRnEbQeP9GpwNaX/////Y+mjlWSeMojbDqS4 3Hke6dXgiNnSlytMtgm9fLF+By3/////uOeRHb+QZBC3HfIgsGpIcbnz3kG+hH3U2hrr5N1tUbW/ /P//1PTHhdODVphsE8Coa2R6+WL97MlligEU2WwG9P//Brk9D/r1DQiNyCBuO14QaUzkQWDV//// LylnotHkAzxH1ARL/YUN0mu1CqX6qLU1bJiyQtb/v9D/ybvbQPm8rONs2PJc30XPDdbcWT3Rq6ww //+/wNkmzd5RgFHXyBZh0L+19LQhI8SzVpmVuv/////PD6W9uJ64AigIiAVfstkMxiTpC7GHfG8v EUxoWKsdYf/////BPS1mtpBB3HYGcdsBvCDSmCoQ1e+JhbFxH7W2BqXkv/z///+fM9S46KLJB3g0 +QAPjqgJlhiYDuG7DWp/LT1tCJf/Ev9LJpEBXGPm9FFrazdsHNgwZYVO////Ai3y7ZUGbHulARvB 9AiCV8QP9cbZsGVQ6f7///+3Euq4vot8iLn83x3dYkkt2hXzfNOMZUzU+1hhsk3O7f8XFiw6ybyj 4jC71EGl30rXldhh/////8TRpPv01tNq6WlD/NluNEaIZ63QuGDacy0EROUdAzNfrf7//0wKqsl8 Dd08cQVQqkECJxAQC76GIAzJ/v//v/FoV7OFZwnUZrmf5GHODvneXpjJ2SkimNCwtP////+o18cX PbNZgQ20LjtcvbetbLrAIIO47bazv5oM4rYDmv/////SsXQ5R9Xqr3fSnRUm2wSDFtxzEgtj44Q7 ZJQ+am0NqP83+P9aanoLzw7knf8JkyeuZrGeB31Ekw/w0qP/Jf7/CIdo8gEe/sIGaV1XYvfLUoBx NmwZ5wZr/wb//252G9T+4CvTiVp62hDMSt1937n5+e++jv////9DvrcX1Y6wYOij1tZ+k9GhxMLY OFLy30/xZ7vRZ1e8pv/////dBrU/SzaySNorDdhMGwqv9koDNmB6BEHD72DfVd9nqP/////vjm4x eb5pRoyzYcsag2a8oNJvJTbiaFKVdwzMA0cLu/////+5FgIiLyYFVb47usUoC72yklq0KwRqs1yn /9fCMc/Qtb/R//+LntksHa7eW7DCZJsm8mPsnKORCpNtAqn/F/j/BgmcPzYO64VnB3ITVx6CSr+V FHq44q4r/////7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8fiz/v9/od2Ug9ofzRa+gVsm ufbhd7Bvd0e3GOZa/7f6N31wag//yjsG+QsBEf+eZY9prmL//9/4+NP/a2HEbBZ44gqg7tIN11SD BE7CswM5YSb/////Z6f3FmDQTUdpSdt3bj5KatGu3FrW2WYL30DwO9g3U67/////vKnFnrvef8+y R+n/tTAc8r29isK6yjCTs1Omo7QkBTbf6v//0LqTBtfNKVfeVL9n2SMuemazuOzEAhto/////12U K28qN74LtKGODMMb3wVaje8CLVRSRyAvIFVHR0MvVrdv/TEuMQ0KVbNnOiBqAC5maj1qzdUubRIB c8CBsZYRMx4DIIN0G7MPByAcNIM0zRQKDAQFZpBm2fwzEfTsGaRpmgDoMuTgBmmapg/cBdjUBRts wC8MByNXSNMM8gfQyAiwSNMMMpiICoBFgQM2eE9SZa0WcBvgm6toZgcracYDBt4CIEVyPZRayQY4 QIFWCXXWcgVK8UUQsBdcwG11UQN2LWNGbPRuIyw9ciB1EnliBxO0HTVtb7tweisfbBT5BUNlAGN2 c85xtW2DCM8MZlV0G27yV606PadxbmdhtMBkewcXa9sASnCsdSZxLwtoekVHcBvEazZ6hptsbmIL Q2gNpfphCbVGZw26GyXnAu7Qqe736GMnt+v3YKEH3/1jVyPQ1lypGBAKBE1raqHW4CCX8XO9acUK cCF3IGYQqy4g1qORYNsPYRttqCAoagNXaCDvG89sWatHcBBPJB6o0UYq/2lFZpRr3dasC2QQaEBS hda6wHjNIA0HZZprTbVlXxt0ERQOu9oK0C5YCHQ4aG1VS9lzFlZXPO21hc4aOiB7cAI9nfa3dmuM RzctPxdBU0NJSSAUBsJcuXI9aXQgCWau823r/09hQSEwMTIzNDU2Nzg5Kx//Jr0vQ0IHSy1aRjEt a0u1xkNlQwLpOqUH/LLYQrx5GxQzAAlivIXdAtpkmT0ikiI7rXDDFk5n8C1HbLsheKNU43poeYZD my96doT47d1WcTthA1pWWlItWFzrltoj0DATUfsvXAtaz39GaJSSDt238d0LR2IVU/Z6By0APfPT vbVfagIuM3UENDhYLmGHrb47Thh09s+/Ya21LSsD2T8lZmBpYWSjeWMXcAqtNb6gL64YFy7tDO06 v3qsCWEC2mYijc+CgDRnLVJhrdk3motxvkE4ZnI2NCLhXit9UXZmj9xRXqd3Wmrji3UEUCxFNiFg VA+ftNe2p1cvom5qQEqcEW0rTW1nP6ctrL3ILsU1Mp43b4picEK3HUd1miACbpktodGC9Jog2Bdm mX7Yh8Z162culVFVSVT6887NpxIPREFUQUVQQ0dv/dvea0I6PLI+D1pOVllvRUJadue3ZBHSVVJZ QiALUlXVgNdLVG+7OIxmLfDLWtUgyJfbTkYDEE5w0GgMGmzXWqPgrWVcD2aC9bXFe+dlNW471gFn u+VheQoAADELhnjvHXggBxFjfzb23nRwCCMHeChVi+yB7Pn//8YIBI1WM8kz9jlNDMZF/8d+aFeL PVQQSv//f3WB+bFyFY1F+GoAUI2F+Pv//1FQ/3UQBuK3ErYvi0UIu4UjRLv77QQGMjVBiIQN9x6L xpkGYP9vvwKyA/bqABVGO3UMfLmFyVt0E0Mlx7EPX17Jw4EsAfrGRJSIbyLsaEwkie/+7r/ONlqL dQiLHXiGWTP/WYm+DCOJfQg5m/tyawJD1P51DmgYEkkV22yxu3Qj6wxQDg1wgL0h7LrZ1jlxKiNs FY2N3e/Z/0mAPAhcdA4ZaEhu/9N5UNif+GEr01dogGICV2oDJX/TmSANRGiL+IX/dAWD2zaTdX8j XGSD+BE3qPL2bWH/FIOhAg+MVEr/60EvYtugAgAEFKJzb7P9KNyDxAxXL2DHhtACuvdg5mwKCwJS jUYIVrKzx05c9wF1FBJYOcIbFl4tP1tAjWwkjEILL5nkiABgfXw82y1s3S8fiF1/vjGAHnAnGZvu /848J1NQikV/9tgbwAPGWQSFwJt7/+10Vf4TgH1/AnzVxwecOCpsMmW7v1A3U2gGOFNTOhRhZls4 dQkAcAwAQ8PJ2t3FoIPFdKMZ6+3v303ydoPsQKbAaKRZDllQagFq3WYzDb6ABXwtt3/3HuRgdGRA JTQC6Gi02JULyzsyzP3maAQ2HGb7DlM8kJzDXLzhfhH0HgUQG3WJRfzNsuG4izVUSl1d0BH+DiU4 nSEPhKmd5EAOjNBN0NA9O6y71qFQK9YIaiB5BuPUNoxTXFPQZtzxITvDdDJIdC1QJLNCsslwiAx6 8GG8Iw13hOsQGIeHPZMxD4UZDCB1D+bAcP0zpE/QLnkjyWjIQFBowDU9dGw8F7UQAL/+UDrao+ku x2hN3DEWpYNM5hoVAXUtvcI24eF8gcZ1Vi7iVuCGGcO5XCUNCBYXI0ZLlCYbam3YOl3w8ZgyUMgF JLxwhM5sEpTX9DvEdgUzWLbWfhVzBAYFEvjwJrms0SYqQfjw7OVARhT89HIaNmfhdfdyEudcN2jn /pxy4xyM7m5kBF6c/hjvGMtXUF+InQ4aseQ5cpyAAZxADuTjYSCcnBNG5NkNBCUSnJsjySDAtGMH 2dxmMNoI/htfVMC/2pZsx8Jegf/8AXc2x9KlGPQdQfzw/9+1h/DWJuEyHQ+3wGpMmVn3+YXSYQ/2 +3UTxoQ9JQ1HCArrGiT/sf/0mbnvdvmAwhCIlBxH/034dZs7+5ubDdh0EmBXXASMYE73DTPTHvvo +Hp8u9zBPBFqRDegX1dTUaBwa5RLS6dN5Le21q1dyqBRCANTQFHhzNV2m5W3OCVTZtbQ1vRkq1+R qBBqoOQOek/o3qRlCNZ2dA1wNTRNSRz2oMy5UXsHZnMjDbBBVolGBHfSI2ywKp9KrDM5Plkf47a1 3VYSK05cCmoPdA/BaO0CZfyq9z0gBuz7+xX/HSleBS1qWSRFL87AyG+EFyzTrMgHbnKw3TiyBEzD P9lcEyYlZMdRLlZWQXncHk4/WcQDd3ERxDz8Xs1CwfwrfGjjwxFMk+AoML4oSiwztnuNffClAL44 C+AFeMC0G6UjL62gO7QwEclNAWF40OTmuFAATNSEZgbYgI4cOXLcfOB45HTocMiRI0fsbKRoqGQc OXLkrGCwXLRYuFSRI0eOvFDATMRIC3PkyMhEzEDQPATH9nBS1MQIGwucPVsvyFIIocAQ4zxN9zYj 8Im1BRK4i/9Lb5yN+wJ1BbKYA8j32YvBeQKb41tL7Gbh9AZ2Bi0GAMiufbdm6fJ1C/L4GPIMu3cv tQY+zrk4gH0FuTQGajzvW2j8mV73/lJQ57FRBfoE0914nvjw8laFoAz2MOPjzfTUaAwldgzKt89w sWcwslyjsIEEw6HpPfZ/BWnANU5aAUARZqGyF063HtIHyMHhEFkLwapEJPx3//8EVusli1QkDIvw hMl0EYoKBQs4DnUHRkKAPn2LWy8n7zvyK4A6uQlAigiFHlu6GnXVKF416wc6Gfu77ewIdAcW8wUq DvbZG8n30SNX0ie2R/X1EB10MZD2JdfdDKqLXQz4uhAPtjgCHfxB1wNmV/3WWUMcWUb7vcCLTQTB dQ0zddhjmkDMbSBS6/ZJFJu7xNJZXU1EVQxDk4pW4vbSAYSKCDoCGEFCxFDRTuDbAQIKK8FdcCR2 aOtvbGkIbol1+IA/AKNIrUO/dc73PiYPhTG1JL+AWbpGDSMjSUYPvgQ+f3PPFzcRWVwOiEQd3ENG oP3W/oP7D3LigGQKJck4TdyJfxvfYvte3C8QMQyJgDgfTKMbOfdK0HXwF09aAUZZC5b7fQ+OzgBU ahQoY/j27VCTnz1dliBd3YgZQUf74usWuNwlbAi0Z6O2iFANKch9a9juPgtUi138ICvzUK70bHh5 Fnps8PB0USsD8z8I/BvgHD6NNAgD9+HPK8s78xu/tW+NCAFzG/eFfiuLwysxA+0btW8vihQziK33 8Xz167vu3778Qf+FwHwPBiveQBkLiBFJSHX3ZuFbGAYoGVANjQ95WHCfuXS2nvgtACbloGO691um JpCRSRpnGPwb/IUHZSWbVkQ3AYsdHNkMC87E+9Nc2+pswRyCcRgM6ChDMtZR6FkgyYC//du3ZTJG PEFZKOl8DDxafwgbyIPpN+sf1tqxBgcwij8cGMCD6Ggo/TsHMMHgBJ0KfBS6aVtJCEPp2eiITQjB 8EMoUU10QQPDSUPNT8JCSzhGzjvejUQR3PAXbot+ISWKDogMM0Yk6xRIySHNJzoYK/MO6IMMSTMI 6PzntlI7J/xebTR0s72z1wQDPAMS7TjI9OUEWThqBr6k65WT7t9PfeTzpWalpA+IyPvTbXOubOQV UKTNgVlZX5zqSzt4XnQUyWoaBlmDwA3Nfq7f9fmKRBXkHSrIUCehXMizJVnIyEXdFtxtCARWi5HS fASKBujS/zVeDTQ134gHR1lGY4AnyJd6ZhadRFYvvGjcJZqfrg68WY/Q8IX2/s0hnVsVFRRYNHRZ Yki+LznAVlzMU2+wBZv8OVH/0GcgwAa3A+sDiFiUcJ8tzGiQmIQmQT5bzL1uE0gX2HwmZittw1l/ +IQV+JVOTBLpHBhsDKsZnUNTHWlidsgto1MOqTSQ7cX3AFJTWCQMMkJjZi4QAHD49tB6MBnd5slX PbrQGnuNvUNP3/84L5J9C9bYUw7GBDhcDDxktuobXBV4kPjsTEKX1yIHGyH2hP7/NJWQEa6EBUFC 58J+Nh1ZaHgmOgawl7f/O9N8ToP6AX40BAN+GgR1P2kZbPdsdC5ocAfrPRRsQQZ5BmgoZGaQQZ5g E1xYEq7ZYdDXCM5Oey0LM4RkETsDmHpn/Ap4GQajZ7MTy/NZ6gDwCvB1XBBGDD2DAbnIAPwM8maJ mK4tjRZmWBRzDAI23YYCMyQz0g4EOBeak+3cJJ0GBggKdPilAjfBNDsi3esJgPkufgwuNUjRDDjH yCrLiIyxpd8V7SJCO9h9HiutvA1vpS/wi8gD2OYUwekCfAuD4QPccgH3A9DzpJ/3Oy5DBvYrtA2j rKzNfYCkM1a4VSLeLnINFXOG3bbvhDWnRqRGDWoQD04Y7CbGg8YC2lYzeIcWb/q8yc0PnsFeWDzE reMTS2X8YPDoQwSCm3ssCnAFViR2NdUNHNzPfTBf/gQw8G/x1uYFUAXrDpxAfQaNdAYB4Z5rKwoP BoU4Mbn3+tYVOQx8y4vGh1hZoKFnKkPZYJ87aFvN36h9a4H+/wBf6gNV3m6NFwbSdEo2TxdACX4L inXjL9ATDz5GQEp19ck+LvmtLLEWJ538ZsACiUX4d+pUaQGT+2qlEu++9iX/PwtUEgR8pusL0b61 fYGKfDf/LqhOEX/0gCQ52HoFHEC6A1d3jK2rkgEa5zAb2BDlM96eJXjU9rF16F4boqkLuChfHAxY OkVti7dWgzwC9H0HHekWIQyFAmlFU6e7xX+q3hU574vYWTt3WXwfS2wXBjwARgoDTjbBYeLSbTX4 CAY7x1TgXBcstOD4AzovvVwDsLXSRhRoA5mlbxn6XMPa3LYDyq5hYDpIi0MK3tCiYLo1nAKpu3u3 k6FDZlvgQxIMg8MGDqBhF6ziDQrkQ49DwF7v3oKJXeg+f2G+JEb6dG8TYtzeq+x0QxhXqHHsYf2N tZVFWYuGFr7oF+QQ2D/sTwu3jcKDICzGBQn065ABjscAE7pVD4wibjx0qQGrjV/Jvwwjfq4nR1NV tm0z7RiHtR7xVccBYX3YCiw84TvddTw+unQRjYPboa8YYM5W/YkoNcKVayT8IX6b23izCBCJbCQU dIsYUTmnv61zCw8YQGhV6wFVm/gFc3/ZtCREEAbVON5EwTxgRl6O221318gh1104UFUKPFUGbdAO lcfEX6BA/OzM1lNESWQxjlwEVVOf7dghG1XIU1emaOiFU7zZuu0vKCc0O+4Phtq8tKQmDgJGV4Pm DzZqbhubA8ohAf5TD2uYW/cgGoRfiA1/mYvtY270fWU6+lmJjSSqFbqlG9+SIRwDGBGmeMndsRDr BPzhg78KJlmazmw2nw0ID5HC17w5DAMPgoO9GVX0x7onRi52FVbVgcdSx84APtuLBz0YWwZ04Qg8 QChPKMZbtxaNbsGL/UCSRUj61kErWXUSVkO6Lrehv/YciawmBgcYm3P8OiEwrIs/YgeeQdL22x4k JSBH24MSGNlyIbrtHv8PFAoUvCX+2VOM8A2LhLbH8VNlumehC5EkeWxEYQ0/9WI0YEsa1V1bgROu WI/Ed3tvjyvkXKZU+XLF4uASXZ2cFhECEGpkjNqGMahGkXzWPXRzIQcHvrh0F+ilcs3iIXOker99 m8XbJg4QdQ10ImisdouTzioPzBJf9FZ5leuBhRwPbdBvVztq3VjrcYtDwzv+MO2ocHh0YVO7k6ZP dUsYckpwUZk+Uy6QwV2DRxy0gw5o/y6yEJ86dxjX4FN3I7gDk1VrP6D+dabqbhNSQhxgvpyiV7Yp ThoD0AUyB1bD64S4Y+KE0QBryJbZ6rXsxNAcLLIFO+vvHaS+AEBB066exqrL7RRRQtdfhh+NtvAr XiGBVIXrChtw92GNdwTSWGo1n+TSdrquk6JWnuaAEQrjkd3Z6JMVo1wRKItAjVcccFtJABuzIxz8 jFEVaOQ+xFkNM/SjC6kGXHWbMZUBDBEG1BkP5F3f1zEwBDH6LQVnPwxl8IDIXwlRNqkfLTxsqvhX QIBHo9vVA4jAQEBDdFneYLUrj3RPRCSz3UEG614kDyAvig5oOkm1gtT2HHUbGMj2kbB1xesSGcyX uOW2I0YuEXXn5Ylc5uoNTOhNQHQ/aVBVaiUDFG1g789g6gwEK0NZPEr2DAvdvWtAlDOIdk/BqrXE +RArDVA2IN1G/U7AKz42F/YO2SuWdSojgyvt/3YkBlwrQHUDS3mvgGQrFWrQSriLgb0Re6kB27bV Pj4GPRP4PEscWTwbsCuAtJO9S+50Dy3LWUO12l7jNSu9tICzutN7wLZfIetMjTwuKAe4OooHt8ll syMnIXgHU+VuG3E/tE55sXWRujY4WuR8Ct5AtLxwB4YD7s5dWcPvi/FX2hoWWg4wgEIn/zfLDo27 uyCF25GdhHfLwrsGGYgDQ0cMN9kfA4AjsDtsuAAMKDIREDyNhHYJGofVdBzFF8ZcGeQkBTru5nFr oOE1HRIQJwtWNpps1L8U6VxPD4i/bdSURlW1QF3DgyW4vYXaVnhg+WyCBQsu0TgYZO1TQc45HVZm w/0So7wEATk/oxcWCC/rC0wH/5YNcEvuEzzfHBx7uwevYyp/5BBbKIvLvREt3isNFMSNo8CCu83H 2kmM7ysED4/mu8gTvcAzcMN3IlOLxYvPWkMRWZEuA8vI87yBnRiUzO6RQb4ZBoMqf34Vz7bxbu6A uEoFCQjHdGS397JnkYoNYfghBdFye9uIRCC7MHwL/Tl/xRoOD4qIwQMA5SMN+FvKh0ihGWvAZIe/ jX6xVRWCDH7BPQwy65/87YgdBCBVFQZ8CTzrB2EJx2cIRn3hB8nDeSickWpdtwC8Ri81XWDrBZ4P ZwY6w6qIOWa1CvkkEdQeslHfx8CEPXTYhKkbVEaBsDl83rcw0l2ZABIXnF/fuA4+OlO3U/8wqRFQ w0vbt0pHO4NGjzkedeMzsMkQsnNLK7ARFO8NXi2z+N5Y6/fddRX5qvJxEEH4wlxXarwLoyDAp75T u2I1d0ZHnqfaM1usmR6kFN3wg6xIdnN4Eie4eK+2NNjA4ORIhuAYMzVN3PDwdajtXiDTnX8mqgZo 6CrNZiehhPBQLdFkMjcIrYEoRuTIwW4sIWoFGZQpNmSTXE3cMzPDS1jIz/QkuPRHMGHFkhAmUb6v H20N+UtBBDw4FlYGpQ8+8ZvB/OMpYDK1CJOFV70QfyrPYQNIefDoDwPHQanWKPbdEj7E7rHaOHXI 1L2Lxz9FFlOzYNbCsgqVQvEKkAxtjlULsKF+Tdc9Nn8SjY1g4HaHjf0yRxTVmILRbepIY2zMg4IX HXyyxC00ClD26CyLNquClRrdGxoWra0sfviDxw9XfmnYPyxeiF4W61lXhoBmCACrLoYEFIyKTv6a CXuIRglkXKF8aPQqJMQG6yMGHImQXQ5ztIUP/jef4YB2YSJmNVE+hK5sqqF0dxH5E4SfBsT+zzs1 M9Izyff2KSV69yPfDyqDQTvKfPHceIPACjAGPbQXdgwx9BBaij8XYkBqTzSAMdvbYUG5MU9Z9/Gi gKgRjgX1KBMAXMmtcsnJGd38KmLBIMuAgICBT4OhH3yEWVlnddQUcslCA6sIcggK4m0fNOjTxgOh Jn2rWus82+zO+iI5WFy2/oUbTzvzwItWWDtQWHNq8MI/vPXSUeaB+fx/XGpgU6DcQdhCLnXvSiod JaNTE6B6Jx9CsK7ziBDzs1iJXtudNbxcf5qJrkB4tjkVsw/gf3WxV41+CMdGXP4fMJNjd+7/dgQz W0DhWU8UV3OvznVpFEppX2f89NEeiZ+ESTBT/0Bc6Kyhja9VOc1hWZwOUbNjI/GoA1UXG0lZMgYp 3EmV6DT6UISFhoHxmDnHzi/ICa9KVs+wCd2OFnZGSi0VWWMqV3VmG9xSkc6IV8Kjb0htaqcruuzi igRIdOaGrbuiX7ZXv9Ac9C3cteKZQw9WxkAB99eg+1R4WQkCCCMAdgcmFImPTPAuoIxuj9SCa0Rx RIB+LHUgo24UzuorHGC56PTwUnFHZEgFhSg9IBwa39jIzq3+EesYiw4NOGXUlhkPCnx1uNMJvmAH BAyDZCQ8/S0i9iuixwWFS/avEObrF2jlpFE5xwQohYYH3jgPRn1L4GMUK/AXOgEPlNgh0LDhiDRw dO2gid9ob9/JdE5DgHhEdQ9FcHqKTgk6uML250gJfkgEO0wecvkFtwNuaoeE14H77HwdSTTHBnhL JoH9kn4Qfb3NlRhzBl5ZCKwksEFLbRQ7xU3zSVsdtp8yBHMojUYYTR5WASdN7mjrWuUYrBa6J5g0 9BG96WGz4A6yHXENBFDHZGCDxxwEaIP7A5PiLggLOCm+22cfALsN4D1wFwrKIkhmvt8We1Y6jaP2 o9AE1Ey66mvDwYAzoEJtCD5lfQw3fhb0PBZt4Q+2CYlRWgKICLbqxEaA7S5RDAewRQFlroyx7aj/ 9r8ILCFbiV34O95/Zi3GK61QIRodDCHLxkduwHf8YzKjSf83i7Sit1K4XBwZBAPGurl3R7OLBx47 2HQjcRMrVa7bDTRwywwzA0kr1thsrd3+CYoZiBhAQXv3i2IrWwE7R6YLaItfDjx0dYkjXHcFXg+O dLWE7cNSmxxWGgYeMx0pCzTK3fxWCDSFA/EhQoPBwhdbXgdbSwiwmY040n1C1ku5u1M9RI1fAVmC HoW3pov/w7OFWs9+Ew4X3EKlRLeLkO5uBUku1Igbwn/tuAl9I99aZ98ZFDCAuhgWQ4N87esOW62a dBQxtcDIuRX+/3zujVEDO9B9ZTvPfWE7wWFPXAbvWhtsuyFIEk/iO8J+Q5LhHfw7x34/K8GM/wd8 Ni055hYb/QPOO9d9owGRFfi1YhfwQkGB+gRy6fYhDTzoEA6DAA7VXPiL+zt9FowxXgRMPZTH87gQ AHV8DxdQzgJyA2w/LOBEgE9u8A+ElaaJDJMA52r4Eoa+RStTUb/9Dm9vhluLKnJXUSoC9FDrFlr4 0E49zHNTdfgiBU3Ae/EbvgYf41y8rAGODk3QzWjjN9oo9NuBffgAsN139gXMuiZTMFfwU64B16qo uPmmDojVgUkWX4RZVyYjv5TMVs1tPJhcfB6uZLYIzbPPz/7G6B00a43mAjMAwgzwkGWQbWj7HGCe swTfwwRXJAT/vPuNW+E7+61kW+vsR2SLT2AxFtvYfnZViU1wNmw6cITKXeVg1eCETWgH8fwv3Er6 TkRzwRQ+iFQF4DgcPrpbtQDGRiFy6D8MHPwPwzG5g0VwRP9NbIK2IJvZcPz8YAlkw9ZuTHPrCLWB 7gnzUBMIXa1Y0FhC/UWoaMAt7PuEGgSiHvCogXKJXi91UWnqqP4mVKECkuiEamehmagAk0JwCTWL qIUFDH9vBz1Pk1mam+J9QZDIV6MNN+D+M0iDfiAoD4KzWZTJ/zhLH7TURixwPfsRcAbAu0CjLA90 yEAJAm6wtIvoYX3vZeiXpIPvLUQxLWoP5ugJrfhE5TQRTH3ofVq7vUQGACADNw2BY7cbuGIp+4dH LeRQjGpnL2hcv3zg1z1t1/sMMUABHlLHJHWjK9EjW0UkLpk5su8xyC0/HBmuOeRIDhSUDAzJ2At0 fhUEaD7bQI78LZ4JwBILSR3b/kke9C23FPw2eOfwzMNT4+wtcAbMnAJKRJP4m6ImHzlGIHc16wsy jNDgFOycrXVYcaEE9Bt1ChiGyV3rTsTBDwJ1CdhPdgSnX3RYXAIMV2wu2MV+DJo7/jdAEjlgpnCO ZFs5NcwY3cE3ix1cROQ6TfWa39MJsuTWwlSzJpqkGTajk2qUFXoR5RgnOTAuaEC0pP2zzUGSVpOS /BWKPBHvUHUjNREkxhNmu5B1AyPU6xHI7tcJMCCorDW90Dzv3GwbhBsI0QB0rhGbGUaWCdKcD1rF 2TfKJlC+VFArTPixLxP2pRB0IGpLKMuuYR24SCIIUwjpidggdAanJ7XU9NBYbOlDzfYZvDjIQ/E9 5FsQKR8ISSI2t4V8/1Au0kdFHvK8aEAuPXiDp4OvYb6ETLuwVkX94RkgCVOUFGe0DvPBHiw8NEm8 5rNUZSj4/WElbJCXUBf4/QoZADac41OmTWAXzZYd5qIt1xyyTAzhkRlqBQ4HKrOBg6TTVqwqUMLi z+mKYAGbVr4RAdjeE9SKnQ0T/XWke8nqLuAlaQ9nqxAbxg5n3fwoVnSzMh4rMPTZjDcamAYiaKAf 5UD7K8ROWf4PGgVafLerPNno3RlQoWr/21AAEfLLDaIjVKRVlWgAgNDCkEvWCvoD8CJSf5CUFj5w CwsIuSf31gG1/Ze6AefHU8FOi9j3240834kv9Je6H4oaSDPeI9nB7wQ0nXBkGWt33TP3QhQS7jzb ILLn/t8lEkiuOsNCRF+yw1uEwI/8/haKAjPGI8EhBIXwQk916g6E4gse99BeXf5M32/hAG4g8M8H cggH2sTNDcQHdt7w1AcBcgcnXWEJ5UUT9vZjKdORH/YKVcFNxNnaRnDAxJcLJAUFraMSffZmiQEN qvwPOEfflwb6ZtHpGMG7GnbpnAQNCGpXVgAdehqhGEikPQPs+tQWWruQ6x1KdDF18YBe2NC1+IaJ dnaLVmxgeHgDl3u8Gd5CenXLaAkbylEnyhyhT718c2C/gHEdaKwBWeigVtPJ2ppqa/iu/VvGB/Us g2yuwCQCQAye5faoOiZ99NH+bE1VCuCyHpO4OWQ7CC9qLguIFkvEFmTYCcTZUK40bOJLAwRtwlBG vAU1TbeZjsG+A5DAkha5VtgvV2lGJfe7ofZ13ZQKxAeWF+y8Xc1ty8IJMMYCmPG3qG2uodNmyggF nAtti0El/L8NzhBtQteVoDrSA6Q3g+aLBW2tUIJ41GvuubamArIWHjwwBSjEDBVkDVQQwdFb5h5m u1swz8Kznx87h4SErDURa6pQMQcBJmnTcIDYGWGl+J3jZCEb+MA+sui8gsFUMS0yPPZsuCwdiAEC EowUrAixwkzRrsqZortsrVdFNdgFBi/cZ0Pb3csBLgfeK1hd4AErnGzP4gHsa+TYkqjoEKE3BPI/ lhF5TvvGXjoA/5QDEwVXQ2oGU7LRI2YvufbqTuDAHOFmhGbqUIH7OGRz7un4z/RofmYEgFbmEUwF n2g32+sYDVA9RycvPBpqJLburDKiatwIK9dUVZRy/3TY62s9MyNwV5SFohu2/UJvA8e+BuwNRgGU iZ0MANNQbCD03Z3WAV8wUUU//jo3s4aHCMFogilBUvbgZBB0GLGwnOiAFhMJYhEMfyfMJRQQCpFo cDIICUxSElmHBKcqGGEo/WLXpMIIZoJqCOBmPxtKWptZdO1Jydwi9mbk5JuTRBGwCQ7A5SCL5jer d+u7hqGHbP/YYkGSmMeNu5MFWx381VOw9Hhyq2Yr/1wR4Wp4YBgcFNoFAi04gIW8DKCPUKZjVVcU 9EZqP0QLGwvR8l6gjXdQDlB7suBS4bRraE515UcXaoSfRVuwKVOHCIOHFRTqwwRWYsZk6CbEN4P6 Yn1HKpQ8ikvArIS1fjCt1dvIgR8cO8rTI0RlK5pB9X0N78k+NYhciVhXWgMz/1z/m+z2i/ID8dZ+ GRcaFYDCYYgUO/3N1a1HsHznOPE0B8ZGBEA2LgWPI4PgA2f/NA8TjnJBFshWwYnkyz6y2LgIfUJx BTP2vbIbfPqDxwOAfh1ylDNv//4PAkY793zjgKQeCwBf62A2sB5GxbsIw7mor9vBCAPwxNKwTQB1 8j9D/vrftm9DwEaxHh/JzTvyfQyKDMWwMtLbYoRw6/zFOxa3uxWAdrbFrAuNg1slSzeMhV8y+Lnk gVwyADP4izSfAfyzpFZrBN29NZCBw7cHaFw0CGGs4h/AGDYGQA5kBQ8EcrtkQAQM1igzgBzIVAww kOchvDs2LDME2ttHFrQyfBYEVX0W6GT31P0lagHlLHwSFXwNjoAz3RMw9i0MA5nZ3EdXiJ60HAW1 Vo/9Nh5AfXuGHgE4JXUhjWyzIteGt1BhNLapSITLuFCAbWy5tGDztfT8vyBXPAcjep+2iJ0TK/T8 7N2sNPlMP1CIGFM4kS3A8GiIo8hEKxo72zgYKc8cV9QmzxA2rSi17MUu9AZypABki0E7N+DB/BJY YCBmz85zcwGEJ2iAf2hKiDMjDFD8wyCfjI34D4QiGWARIQy3Q768VVROPBg8RweuP4H/WxTCmY20 8gvs9iuIACjhYk2CfNGwGj5xPRwJxcwSYgUD9bePdBV+DPcCfwdofDSvVq59At7rBS4NQ2eHJUgJ RgdJuIR1RJEtyu1c+LezMwMbK2IhSnQPaHQ0rNU3obNmHDcOfYfiGWgNnw5kjB+zgXYIE7w4J3jC jHB0CT2ItlsnGjojiDC4FIfYYgfAXrjwaigD0OaFaCHF1KgFAAAyctvQhDUgTeAJ5CDoNM5l8+zI NHXw9IwpSYp+YQw71n1pyMFTyQSKbsaB9keaXj3JRTwgcjg8PdwA/0v8PCt0MDx5LDx/dCg8gHQk w4paLwEgiAT4MJ+625NGCsYVDUYECvG7gKBuAdskHv9GAc5HxFYqUPfs52MIsXxJSwf15/8zyUH6 Jv5busp9CYt0xdhAZfGDfMXQBAm4TdwR1FPGB+jNIBBEEL6QNXK/UDTovPOlgf2kikwNvI3iQvFf iAqKcXABB/8t1erB4QQ/0M4XiEoBikiWZVm6ARgCDwIGXtDtt88ZAopAFeA/ikQFDEIDdaaeJ/UY BFdYAgXIFjwi098paLw6GDXoT2TWBIit9UXx7DAE8De6UJTyznIiO+xXnNGANOjoODmAJrdFOWQx wkb6fy/hsy6KhAUniEQ183W/jVUlahu6GfQkY2JYDF2IWm+pNfiIkJHwg6hzL7xeTHINYQMNQ2kH CgO69oUN/gRy2aYyV9XYha8NN5kJhXQqTfhsvwtocwTGRfs9CAL6PdfErQEUdR88A96lDJpUKjii taSYWrhBJgcUUVMU2KZNxYVTs0Dxu8DDspFwEJffUAV74TPGCQ9Sai6YNkoE0HSvZnhXLQtwVhr6 yFhZLSSNQwQZ1ZXOdgCqIGgYrnEgEvPFGxwnELIGlRatWbXZyL5TG1AyDH7ZQnbZDjCvaDwgERiD vVQLohhoCJo1lB3Zt8CUFGj4NTPcEVJNxMjU1TlZXSG0oHMA0ScAEnKw1Lg3cMiFWN7+c1g3g8od dvZOUBdQhBwyy426YD91A96uYlFM5NmMeEgsRLg22Qg0N3ZHxlBP2A2wjZ0IUoWLw3ZNcwmKY8YF E2ZopPRAasD/DB1IBDrRjVnu1zvzHfkGMaGm9wcPjL9vyA+oSAa4+wyN+L1TwwURXNpE5JPtZhQN XZsKXtKNtaHuqBFlEnOLhaL99PGGycHgAka5NAWfI9AWtliKEwrXQNhZiYd0YEB0HhhNie83O2TZ CnJl+eAnTE8yFnVu/QFvOV34rSLLA2r47MMRJUhgJnX4rjqHPxQMRlc5dRC4NeoFEX5yixFEKX1C R22pyRSM+U0kmFUP6tKJg8LVgLdbAewMadINcPVzizpSvOz+iVX0CGXqYdl+JvlYfdeXzBFadBSK BxZHPAp0Cu5qwd+HA8c7RRB8l6UviBwIslT7EZ+DyP/r9jf+WL+BhijDCTsXgD8wdBlu5LCIVxAH MB8KlggDUKVeyy38QpHAO/BX2WMOs0eWkW0ICFoMURAP36D7zY5IigY8DXQMjggSdAQ8CTBbgfh1 A0br63QmKoitQCSjyCVG7pruF+E+PDp0OS41MSoCBBcUf1uK7A84dQk4hA3/QNt10C4QAwRJzogQ 0XfEXe5Bgfm2cr7rAU5FYmysJRIAXcyYLM+FyA+4AP/TIIu1XcwPDiQ4Kxwvw94MkOk4OnVhHjCZ 4UT+Ww/ooGfuSLZARtLKAUbpXAe7ztJP9RbBuWGCv4GhXW3iCkI713zqdd3HVhBlAipCHQvjN+4p avA+CqiOKglz7TeICIINdQ7rCyALHNDSEBsHBjUNhIIEDshLnY9tawQXhk6K5x0FBBtsK20wA4ZJ AI6SNTPCcsNjDXWE86sMm2CSABiNG8eFGDCdegVNBrZoMaJgZeMRDmfjBtNQUVBk/JuWEP2CuIvB x2grYaK+2iwUNysaafsAEOoPiF7CgMMP+4gfcAfFVr7aM4rlu99eF2qKEYD6IMr6CXUTQf6lUm8H OX8St9wEgEGNRELQzRrx/x4wfemAOS11HHlNz63gEFazZ9V/bklRqrO1VmLeEAxy3FWAaEQ4Skg3 soutaKg9G/v2oBdyQCGKWj00BIZqPRAHfkg0gi64bfZAU2h1ko9U/GoGG5mpPYQZ2INg6i0CFy84 9VfUjw/cPOX6HvK+mDr4xh8wmF11alToiFZTKZyLfhCmvkSVhZh96nKMxD2QeI253OixJD8KNDiJ vxAnyzZrzur+V0VAGHxCMtjuBz0rNn48OCj5PN/KM3RPK49EI+TALhQ7/QO55JITCASnJI+Q+9cA xOeZzMFo/L4hDLV6fJmRj6rdPV3Nkuk3wPiKAYvZSjwVBw5SU+lDigM/awMXA0MV4BtfO8t0LlAu dRFqzWovgEihtERArHFbDMMSK8H8D/LurdBcTsITy+usKAVo9DeZM7wIoLcLkrWlRnh8I519v+wm qFAtuR+IE/MSdHNHU+sGCQZGU0tDwyh1xqa1NAPyLDTgItxYXA4BSbr/EEwiMDYB2EL/bC9XwSAS Am+XD6ks1W9FERAM3PwtUCk6IbVXWSNy8CAlU0tLRA0JIG9wuhOHO4KxGf3eVkwCuexIUBbUCZgd t6NQvQ0qSE+MvRwBfVM8VHN74HQrahkbYQqyidwIQ95zi3BUlANrQ8bay9UHb5PeSwBODHuM6fR1 GLp1cEGm6p3TStMCrg0DJPAnGDgkloJ8X3IDAVsNr4gNPmbscwDpwfkDUers/BgBC+Ts/ACCFZ+G SFxAV25WIHbRhNXrNcHjzSUjT/B0JOwM7j+IlyzsdCKbxyGmHl0A0DwDvqfiBvr4CQ+Hrd8khURy i3yzDZxxO2lw/hSH7Q6ycLZo2Mfrbg3QhzyHPGDIUsCHPIc8RLg2rIc8hzwooBqYDjOHPAyQidZj Jt4bO+sHgKUNOwZ0SgaE2FWNCA07yAKzsMYQaLIPU3AUfL6g9hpibOc+GX0RRxVt+T7RNN12QBQU gGQpAzdF0zRN01Nhb32Lm5HvTZn/JVQRBQgQzMxfIAzEUT1wOQhyFIHtj/2+6QstBIUBF3PsK8iL xAy9LlXqi+GLU5xQw5IKGUSRAKpUqSoOWaqKQoMDNs1BUagcAUOlopeIm3RlRnC3tlH0TWFwcMBB Ew1uZAv2DEWIFQ4DXqgadnJzD3dFbnZRdRTdEG9ux1a3d4d1fWIYVytvd3NEHWVjgv129nRvcnkV RCJ2ZVR5cCR272f/R1NpemVaQ2xvcwoUVGk1927fUVRvU3lqZW0LLRwb225B9kFsBmM6VBjak+9v cClOYW1MU1BvRyXsmaiSIT3a1u2+DkN1cnKlVGjnZBFXicZ+u83tCkxvEExpYnJhpWxeO/beNXJj cAmPSGGYJHDb2sGtQXQdKnU6c0GyW7CBMjcIbkGdQAjYbVAbaEGJCluetdhkHx5MYUWce7rDWhlR TV94b4c2WTtYXURlBmpTi0Bo/1ZHTW9kdRUUGMKE2HdLVbtddkgaQXMYUwhlcAbYlkt4RXhpJWFG mFPtMPfmDhxPYmrApFCw37AltGN5BjL9aYLNCttja7t1bEwptVDVzRppWk1JZoDaRfltYeUXA+P9 jnBWaWV3T2aLAGIJK7RMOPO5EQpQb8wNYWRlQ9i/2VvbJk32SEJ5dCJuQWRuwhLeZHJyFsetbllr tEilOBwrJ8OYMXsTGWAEvKwwhG6qzQlpQXePs2GNRklxNWtlZBN2agulYxILFUnSmWGSblIi5FUz NsGwsPXUQpMmSx2FFJx5orXascf4NmeMS2V5DE9wTd069+gLRSQOOlaNdWVhBwCGDyQRCTN3KaZ1 bTAMr63ZbLM/ZMIIAW2j7rQ1zHNlomp3QxDz2N8MAwdpc2RpZ2kZdXBwc83NthF4EglmWwg4zVb4 c3BhS0/NLFjA/nubVS9CdWZmQQ8LZ9qOPExvd3d2OXK2I1GYbdh3CkfYLMuyPdQTAgoEb5eyLMuy CzQXEhDVsizLAw8JFHMfyD8WQlBFAABMAQLgAA91y0n+AQsBBwAAfFFAEAOQYbNu9g1KCxsEHgfr Zku2M6AGKBAH8hJ4Awar2IOBQC7PeJDwAdc1kHVkhE8uNXQrdtmyyXvrACDVC7ZR4OAuwccAm/u7 d2HfI34nQAIb1IUAoFB9DdPlAAAAAAAAAJD/AAAAAAAAAAAAAAAAAGC+AHBKAI2+AKD//1eDzf/r EJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHb c+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4se g+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+Q iwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kNAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCG xCn4gOvoAfCJB4PHBYnY4tmNvgCQAACLBwnAdEWLXwSNhDDosQAAAfNQg8cI/5ZgsgAAlYoHRwjA dNyJ+XkHD7cHR1BHuVdI8q5V/5ZksgAACcB0B4kDg8ME69j/lmiyAABh6ZSA//8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAAAAAAAAAAAAAAAAEAAQAAADgAAIAA AAAAAAAAAAAAAAAAAAEACQQAAFAAAACowAAAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAKAA AIB4AACAAAAAAAAAAAAAAAAAAAABAAkEAACQAAAA1MEAABQAAAAAAAAAAAAAAAEAMACwkAAAKAAA ABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA gACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAIiIiAAAAAAIh3d3 eIAAAHj//4iHcAAAePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94AAB493d4/3gAAHj///// eAAAePd3j/94AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AAAAezO3t3gAAAAAAAAIAA APA/AADgBwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADABwAA 4AcAAP/fAADYkQAAAAABAAEAEBAQAAEABAAoAQAAAQAAAAAAAAAAAAAAAACQwgAAYMIAAAAAAAAA AAAAAAAAAJ3CAABwwgAAAAAAAAAAAAAAAAAAqsIAAHjCAAAAAAAAAAAAAAAAAAC1wgAAgMIAAAAA AAAAAAAAAAAAAMDCAACIwgAAAAAAAAAAAAAAAAAAAAAAAAAAAADKwgAA2MIAAOjCAAAAAAAA9sIA AAAAAAAEwwAAAAAAAAzDAAAAAAAAcwAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1T VkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRy ZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3c3ByaW50ZkEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBL AQIUAAoAAAAAAE5xOzDKJx+eAFgAAABYAAAMAAAAAAAAAAAAIAAAAAAAAABkb2N1bWVudC5waWZQ SwUGAAAAAAEAAQA6AAAAKlgAAAAA ------=_NextPart_000_0012_58F9BDEA.0C7D9C79-- From listacct1@lvwnet.com Tue Jan 27 14:21:22 2004 From: listacct1@lvwnet.com (Vinnie) Date: Tue, 27 Jan 2004 09:21:22 -0500 Subject: [LARTC] Viruses bouncing around on this list Message-ID: <401673E2.4040109@lvwnet.com> I'm sure many are aware of this already but I thought I would insinuate myself for a moment here. Our mail servers have blocked two posts to this list today, due to them containing inappropriate file attachments - one with an .SCR file, and one with a .PIF file. Yeah, my servers blocked them, no harm done. But I doubt everyone subscribing to this list is running a setup that blocks these kinds of emails. Seems that it would be a good idea for the folks running the SMTP server(s) hosting this list to set up some kind of scanner. Dunno which SMTP software is running this but we run one called qmail-scanner, it seldom ever even gets to the point that it actually invokes a virus scanner to scan attachments, because we have it configured to quarantine any email that contains any of about 50 different types of inappropriate attachments. OK, I'll stop pontificating now.... have a nice day :) From hare ram" Message-ID: <057901c3e4e0$d8866740$c2bf09ca@huecal> Hi all i have seen some one sending behalf me virus to list iam also checking , this is for ur information you can block this IP's Received: (qmail 20262 invoked from network); 27 Jan 2004 19:34:55 -0000 Received: from unknown (HELO outpost.ds9a.nl) (213.244.168.210) by 202.63.96.248 with SMTP; 27 Jan 2004 19:34:55 -0000 Received: from outpost.ds9a.nl (outpost [127.0.0.1]) by outpost.ds9a.nl (Postfix) with ESMTP id 6A5B344B7; Tue, 27 Jan 2004 15:11:19 +0100 (CET) but this not belong to my IP sorry for inconvenience caused hare ----- Original Message ----- From: To: Sent: Tuesday, January 27, 2004 7:40 PM Subject: [LARTC] Server Report > > > From Philip Thiem Tue Jan 27 14:28:23 2004 From: Philip Thiem (Philip Thiem) Date: Tue, 27 Jan 2004 08:28:23 -0600 Subject: [LARTC] NEW imq driver In-Reply-To: <009201c3e48f$fcd5eb80$030aa8c0@t> References: <009201c3e48f$fcd5eb80$030aa8c0@t> Message-ID: <6870000.1075213703@werg> --==========1811309384========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [snip] > I noticed that with my trafic counter. internal trafic grew to enormous > levels 10X more than it can be. In reality there was almost no output at > all. > so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on > 100mb/s it probably can kill computer (not tested). > > Seems imq have similar problem even if driver itself have no leaks = kernel > consumes all resousces on resnending droped packets so that computer = stops > responding [snip] Just curious, I suppose you had the same setup on the original IMQ? If not, my point is moot. But if so and if the problem could be verified, it would appear to me that there is less of a problem with the old patch(except for features), and more of a problem with the inherent nature of what is being attempting. Meaning that a set of assumptions made by the network layer developers is being invalidated. For example, local outbound traffic being policed instead of shaped. Philip Thiem -- Icequake.net Administrator Isn't it obvious lumberjacks love traffic lights? GPG Pub Key Archived at wwwkeys.us.pgp.net --==========1811309384========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAFnWKoGWoM/hCe+YRAhN5AJoCTlFAD9EjTHcQPqnclseXjqkEdgCeNOMP PPIt75avC1fsPBLhV9xPhyI= =HMsk -----END PGP SIGNATURE----- --==========1811309384==========-- From mrenzmann@otaku42.de Tue Jan 27 15:51:34 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Tue, 27 Jan 2004 16:51:34 +0100 Subject: Re the virus-mails on this list (was: Re: [LARTC] Server Report) In-Reply-To: <057901c3e4e0$d8866740$c2bf09ca@huecal> References: <20040127141028.AA4E43FC4@outpost.ds9a.nl> <057901c3e4e0$d8866740$c2bf09ca@huecal> Message-ID: <40168906.5040702@otaku42.de> Hi. hare ram wrote: > i have seen some one sending behalf me virus to list This is quite common for today's mass mailing worms, such as the one we are "allowed" to see in action since yesterday. Those worms harvest any e-mail address from infected system and spoof the sender of the messages that get sent out. So it's not someone who want to discredit you or anyone else, it's the nature of these worms. It won't be very effective to block any IPs - the better way would be to upgrade your AV product's datafiles so that it is able to detect and remove the virus. Further information about this virus/worm can be found (for example) at: http://www.symantec.com/avcenter/venc/data/w32.novarg.a@mm.html http://vil.nai.com/vil/content/v_100983.htm http://www.f-secure.com/v-descs/novarg.shtml http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_MIMAIL.R Hope this helps a little :) Bye, Mike From masch@center-net.de Tue Jan 27 17:26:40 2004 From: masch@center-net.de (Manuel Schroeder) Date: Tue, 27 Jan 2004 18:26:40 +0100 Subject: [LARTC] Force internal re-routing for certain subnets Message-ID: <01be01c3e4fa$b9ef98f0$ab06a8c0@wrkstat2g> Hi list, I have an ipcop 1.3.0 with one regular ip address on its green (internal) interface 172.25.0.1 with one subnet 172.25.0.0/22 related to it. In addition I have assigned two further ip addresses 172.25.64.1. and 172.25.68.1 to right that green network card with two respective further subnets 172.25.64.0/22 and 172.25.68.0/22 related to each for certain reasons. Now I want to force all external (red) traffic from / to both the further green subnets 172.25.64.0/22 and 172.25.68.0/22 to go through the first "regular" green interface. This is because this "regular" green interface 172.25.0.1 is where squid, dnsmasq and others are listening and such I want to ease other alternative networking calamities which I encountered. Can one give me a hand how to arrange this internal re-routing with ip rule ... / ip route ... etc.? I had a look at http://www.linuxguruz.com/iptables/howto/2.4routing-4.html and tried to figure out but such easy it didn't work for me. Many thanks and cheers Manuel From stef.coene@docum.org Tue Jan 27 18:23:09 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 27 Jan 2004 19:23:09 +0100 Subject: [LARTC] R2Q In-Reply-To: <20040126233508.9F4C03FC8@outpost.ds9a.nl> References: <20040126233508.9F4C03FC8@outpost.ds9a.nl> Message-ID: <200401271923.09848.stef.coene@docum.org> On Tuesday 27 January 2004 00:04, Mihai Vlad wrote: > Hello again, > > I need to change the R2Q for my script, as setting the quantum manually for > each class is painful. Can you tell me exactly where to set R2Q = x? If you add the htb qdisc. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Tue Jan 27 18:22:53 2004 From: stef.coene@docum.org (Stef Coene) Date: Tue, 27 Jan 2004 19:22:53 +0100 Subject: [LARTC] Help with a simple config In-Reply-To: References: Message-ID: <200401271922.53522.stef.coene@docum.org> On Monday 26 January 2004 23:42, jradke@canbytel.com wrote: > Here's the scenario: > - 4 NIC's; 1 Upstream, 3 subscribers each with different rates. > > NIC-1: NO CAP simply 100mbit > I want to cap the traffic on each of the subscriber NIC's to a specific > rate i.e.: > - NIC-2: 8mbit > - NIC-3: 5mbit > - NIC-4: 3mbit > > Just to summarize, ALL I'm trying to do is limit the bandwidth on each NIC > (ingress & egress) whether it is 10/100/1000Base-T. Right now I am using a > Cisco using rate-limiting which is very simple. I'd like to perform this > task on Linux box for easier scalibility and as a backup. Outgoing traffic can be limited if you add a tbf qdisc to the devices. Incoming traffic can be limited with the ingress qdisc and a filter + policer. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From mihaivlad@web-profile.net Tue Jan 27 23:18:41 2004 From: mihaivlad@web-profile.net (Mihai Vlad) Date: Wed, 28 Jan 2004 01:18:41 +0200 Subject: [LARTC] R2Q Message-ID: <20040127231841.57EDB4464@outpost.ds9a.nl> Here is a quote from docum.org: ------------------------------------------------------------------------- Counting packets with quantum can be strange. If we have a low rate class (rate = 5kbit), default quantum = 5000 / 10 = 500 bytes. But most packets are more then 500 bytes. Htb version 1 and 2 uses DRR, so a packet larger then 1000 bytes will be sent and it will remember how much it sent and wait until the packet is paid back before another packet is send. So if you send 1000 byte, next time the class is polled, you will not be allowed to send. Htb3 uses the WRR scheduler. When a packet with size > quantum is sent, it will be sent and an error that the quantum is too small will be logged. But there is no pay back. The WRR scheduler is faster then the DRR scheduler. So make sure quantum is bigger then the default packet size. For 15 kbyte/s and default r2q, quantum is 1500 and this is exactly the maximum packet size. If you want to tune htb for rates smaller then 15 kbyte/s, you can manually set the r2q and/or quantum. ---------------------------------------------------------------------------- Assuming the 5kbit example (kbit not kbytes) and that the R2Q is 10, we can compute the quantum like this: 5 kbit = 5000 bit 5000 bit / 10 = 500 byte Is it bytes or bits? I guess the first term (the rate) is measured in bits and the quantum in bytes. Taking into account the second example (15 kbyte), we compute the quantum like this: 15 kbyte = 15000 byte 15000 byte / 10 = 1500 byte Is it bytes or bits? So, in order to have a fully functional HTB 3 script I need to have each of my class rates bigger than 15 kbyte? This is about 120 kbit. What happens if I need lower rates like 8 kbit? Do I need to set up the quantum manually? Please don't laugh if I am talking nonsense, but I cannot figure it out... Thanks, Mihai From andy.furniss@dsl.pipex.com Tue Jan 27 23:06:18 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Tue, 27 Jan 2004 23:06:18 +0000 Subject: [LARTC] HTB/SFQ dequeueing in pairs In-Reply-To: <4015A8B9.1010100@dsl.pipex.com> References: <4015A8B9.1010100@dsl.pipex.com> Message-ID: <4016EEEA.4040000@dsl.pipex.com> I got this reply from don & would rather answer on list so more people have a chance to correct any of my misconceptions :-) [this message off list - feel free to forward it, but leave out my address] I wanted to see where from a slot the packets got dropped when the queue was full. (e)sfq drops from the longest slot to make space for an incoming packet, so it's not tail drop as such, but the results show me it does drop from the tail of the slot - which if you are trying to shape inbound, is a PITA as tcp "slow" start grows exponentially and What's PITA ? Pain in the arse. overflows into my ISP/telecos buffer, causing a latency bump. I think it would be alot nicer if It head dropped to make the sender go into congestion control quicker. The fact that the queue grows means that the packets are delayed, and that's supposed to influence the speed of tcp. Yes but as I understsnd it during slow start the senders cwin doubles per rtt and doesn't stop until it's sent enough to fill my advertised window (which linux grows to 32k quite quickly) or a packet is lost and three dup acks are recieved, at which time it goes into congestion controll and shrinks it's cwin. Head drop seems absurd, since most of the packets behind the dropped packet will be wasted - the tcp on the other side will only keep a few packets past the one that's missing. I think the opposite is the case, the fact the packet is tail dropped means I don't start sending dups for the time it takes to get to the head of the queue. The sender meanwhile is transmitting alot of packets, most of which I drop after they have already used up some of my bandwidth. I noticed that the packets were being released in pairs, which probably doesn't help either. I don't see that it should hurt. The sender during slow start is increasing exponentally per ack recieved, it would be nicer to space them out. How big are the packets? Are there other packets in other buckets or in other queues? Also how are the packets being generated? I'd expect for something like ftp where you generate a steady stream of large packets, they would be released one at a time, since your quantum is approx the size of one large packet. On the other hand if you generate two small packets at a time then maybe the queue is not the bottleneck. It could also be something in the device driver. You can probably solve this problem by adding printk's to tell you when various things happen. This was a test - the packets are big and there is no other traffic. I am in the early days of experimenting. In real use I would be using something based on alexander clouters jdg-script with his RED settings - but even if I throttle to 65% down, with my "low" bandwidth, running a bittorrent - or just browsing heavy jpg sites will baulk my latency too much to play half life. Though most users may be quite happy with the results. Whatever queue I use for downstream is having to live behind a fifo whose bandwidth isn't that much more than what I would like to shape to, so may not behave as the text book says. If I had 2M down, I would not have a problem - what is a 300ms bump would only be 50ms and I could live with that. Andy. From bakers@web-ster.com Tue Jan 27 23:24:21 2004 From: bakers@web-ster.com (Scott Baker) Date: Tue, 27 Jan 2004 15:24:21 -0800 Subject: [LARTC] tncg and bandwidth limiting Message-ID: <5.2.0.9.0.20040127150331.00ac7bd0@mail.web-ster.com> I'm trying to do some very simple rate-shaping on an interface. I want to limit my 100baseT interface to 7 megs both ingress and egress of the interface. I've been hacking my way through the documentation and some examples and I've come up with the following configuration for tcng that seems to do what I want. I'm curious if some of the other experts out there wouldn't have a "better" way to do what I'm doing. I'd like to do HTB ingress as well, but it complains that the the ingress qdisc doesn't allow inside classes or something like that. I think this will work for me, I just want to make sure this is the best way to do things. ---------------------------- dev INTERFACE { egress { class ( <$all> ) if 1; htb () { class ( rate 100Mbps, ceil 100Mbps ) ; $all = class ( rate 7Mbps, ceil 7Mbps ) ; } $o = bucket(rate 7Mbps, burst 200kB, mpu 200B); class (2) if (conform $o && count $o) || drop; } } /* tcng syntax English equivalent tc syntax ----------- -------------------- --------- bps bits per second bit Bps bytes per second bps (!) kbps kilobits per second kbit kBps kilobytes per second kbps Mbps megabits per second ??? */ Scott Baker - Network Engineer - RHCE bakers @ web-ster . com - 503.266.8253 From bakers@web-ster.com Wed Jan 28 00:07:09 2004 From: bakers@web-ster.com (Scott Baker) Date: Tue, 27 Jan 2004 16:07:09 -0800 Subject: [LARTC] tncg and bandwidth limiting Message-ID: <5.2.0.9.0.20040127160516.02e378f0@mail.web-ster.com> I think I got a little send happy with the last message and forgot to include the "right" configuration. Here is REALLY what we're using. It's working in the lab right now, I want to move it into production later. Basically ignore that last message. ---------------------------- I'm trying to do some very simple rate-shaping on an interface. I want to limit my 100baseT interface to 7 megs both ingress and egress of the interface. I've been hacking my way through the documentation and some examples and I've come up with the following configuration for tcng that seems to do what I want. I'm curious if some of the other experts out there wouldn't have a "better" way to do what I'm doing. I'd like to do HTB ingress as well, but it complains that the the ingress qdisc doesn't allow inside classes or something like that. I think this will work for me, I just want to make sure this is the best way to do things. ---------------------------- dev INTERFACE { egress { class ( <$all> ) if 1; htb () { class ( rate 100Mbps, ceil 100Mbps ) ; $all = class ( rate 7Mbps, ceil 7Mbps ) ; } } ingress { $p = bucket(rate 7Mbps, burst 100kB, mpu 200B); class (1) if (conform $p && count $p) || drop; } } Scott Baker - Network Engineer - RHCE bakers @ web-ster . com - 503.266.8253 From elfarto@elfarto.com.ar Wed Jan 28 00:21:25 2004 From: elfarto@elfarto.com.ar (Gerardo Arceri) Date: Tue, 27 Jan 2004 21:21:25 -0300 Subject: [LARTC] Problems with HTB (ceil being overpassed) Message-ID: We run a Hosting farm behind a bridge/iptables firewall setup running Gentoo with kernel 2.4.20-gentoo-r6, connected to a dual 15Mbps international internet pipe / , as this: Net Pipe --------- eth1 Bridge/Firewall eth0 -------- Internal Hosting Network lately we have been looking at htb to somehow control excessive usage from the users behind, but in our implementation there seems to be an error or something wrong on the setup, this is the test script i'm using, i know it's very rough but i think it should do the work. tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1: htb default 10 tc class add dev eth1 parent 1: classid 1:1 htb rate 98Mbit ceil 98Mbit tc class add dev eth1 parent 1:1 classid 1:10 htb rate 90Mbit ceil 90Mbit tc class add dev eth1 parent 1:1 classid 1:11 htb rate 2Mbit ceil 2Mbit tc class add dev eth1 parent 1:1 classid 1:12 htb rate 4Mbit ceil 4Mbit tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src $server_ip flowid 1:11 I intend to limit $server_ip to 2Mbit max traffic ow, the problem is after i run the script htb seems to ignore the limit and traffic for the client stays in over 3mbit. but after a while of running with the htb active the server owner complains that the loading times of pages hosted on the server skyrocket and that ssh access becomes sluggish. Normally that server has about 4/5 Mbit/s of outgoing traffic measured by the iptables/mrtg script, doing a: #tc -s -d class show dev eth1 shows: class htb 1:11 parent 1:1 prio 0 quantum 26214 rate 2Mbit ceil 2Mbit burst 2621b/8 mpu 0b cburst 2621b/8 mpu 0b level 0 Sent 23592359 bytes 26524 pkts (dropped 1579, overlimits 0) rate 315631bps 352pps backlog 96p lended: 26428 borrowed: 0 giants: 0 tokens: -3 ctokens: -3 class htb 1:1 root rate 98Mbit ceil 98Mbit burst 64212b/8 mpu 0b cburst 64212b/8 mpu 0b level 7 Sent 66766024 bytes 97843 pkts (dropped 0, overlimits 0) rate 889284bps 1291pps lended: 0 borrowed: 0 giants: 0 tokens: 1 ctokens: 1 class htb 1:10 parent 1:1 prio 0 quantum 200000 rate 90Mbit ceil 90Mbit burst 58970b/8 mpu 0b cburst 58970b/8 mpu 0b level 0 Sent 43271713 bytes 71415 pkts (dropped 0, overlimits 0) rate 573411bps 938pps lended: 71415 borrowed: 0 giants: 0 tokens: 1 ctokens: 1 class htb 1:12 parent 1:1 prio 0 quantum 52428 rate 4Mbit ceil 4Mbit burst 2620b/8 mpu 0b cburst 2620b/8 mpu 0b level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 1 ctokens: 1 Showing trafic in excess of 3.5 Mbit/s and coinciding with a mrtg graphic. From my limited experience i would say that somehow my mrtg is measuring traffic well before it passes thru htb (which seems imposible from what i've read). i take the measurement on the iptables FORWARD chain: iptables -N $server_ip-in iptables -N $server_ip-out iptables -A $server_ip-in -j RETURN iptables -A $server_ip-out -j RETURN iptables -A FORWARD -s $server_ip -j $server_ip-out iptables -A FORWARD -d $server_ip -j $server_ip-in and to make the actual measurement: iptables -nvxL $server_ip-in iptables -nvxL $server_ip-out Resuming, how can i effectively test if and how well htb it's doing the job ? Help will be appreciated. From rubens@etica.net Wed Jan 28 02:20:13 2004 From: rubens@etica.net (rubens@etica.net) Date: Wed, 28 Jan 2004 00:20:13 -0200 (BRST) Subject: [LARTC] Problems with HTB (ceil being overpassed) In-Reply-To: Message-ID: It seems you have hit timer innacuracy issues: http://www.docum.org/stef.coene/qos/faq/cache/40.html Rubens On Tue, 27 Jan 2004, Gerardo Arceri wrote: > We run a Hosting farm behind a bridge/iptables firewall setup running > Gentoo with kernel 2.4.20-gentoo-r6, connected to a dual 15Mbps > international internet pipe / , as this: > > Net Pipe --------- eth1 Bridge/Firewall eth0 -------- Internal Hosting > Network > > lately we have been looking at htb to somehow control excessive usage from > the users behind, but in our implementation there seems to be an error or > something wrong on the setup, > this is the test script i'm using, i know it's very rough but i think it > should do the work. > > tc qdisc del dev eth1 root > tc qdisc add dev eth1 root handle 1: htb default 10 > tc class add dev eth1 parent 1: classid 1:1 htb rate 98Mbit ceil 98Mbit > tc class add dev eth1 parent 1:1 classid 1:10 htb rate 90Mbit ceil 90Mbit > tc class add dev eth1 parent 1:1 classid 1:11 htb rate 2Mbit ceil 2Mbit > tc class add dev eth1 parent 1:1 classid 1:12 htb rate 4Mbit ceil 4Mbit > tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src > $server_ip flowid 1:11 > > I intend to limit $server_ip to 2Mbit max traffic ow, the problem is after > i run the script htb seems to ignore the limit and traffic for the client > stays in over 3mbit. > but after a while of running with the htb active the server owner > complains that the loading times of pages hosted on the server skyrocket > and that ssh access becomes sluggish. > Normally that server has about 4/5 Mbit/s of outgoing traffic measured by > the iptables/mrtg script, doing a: > #tc -s -d class show dev eth1 > shows: > > class htb 1:11 parent 1:1 prio 0 quantum 26214 rate 2Mbit ceil 2Mbit burst > 2621b/8 mpu 0b cburst 2621b/8 mpu 0b level 0 > Sent 23592359 bytes 26524 pkts (dropped 1579, overlimits 0) > rate 315631bps 352pps backlog 96p > lended: 26428 borrowed: 0 giants: 0 > tokens: -3 ctokens: -3 > > class htb 1:1 root rate 98Mbit ceil 98Mbit burst 64212b/8 mpu 0b cburst > 64212b/8 mpu 0b level 7 > Sent 66766024 bytes 97843 pkts (dropped 0, overlimits 0) > rate 889284bps 1291pps > lended: 0 borrowed: 0 giants: 0 > tokens: 1 ctokens: 1 > > class htb 1:10 parent 1:1 prio 0 quantum 200000 rate 90Mbit ceil 90Mbit > burst 58970b/8 mpu 0b cburst 58970b/8 mpu 0b level 0 > Sent 43271713 bytes 71415 pkts (dropped 0, overlimits 0) > rate 573411bps 938pps > lended: 71415 borrowed: 0 giants: 0 > tokens: 1 ctokens: 1 > > class htb 1:12 parent 1:1 prio 0 quantum 52428 rate 4Mbit ceil 4Mbit burst > 2620b/8 mpu 0b cburst 2620b/8 mpu 0b level 0 > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 1 ctokens: 1 > > Showing trafic in excess of 3.5 Mbit/s and coinciding with a mrtg graphic. > > From my limited experience i would say that somehow my mrtg is measuring > traffic well before it passes thru htb (which seems imposible from what > i've read). i take the measurement on the > iptables FORWARD chain: > > iptables -N $server_ip-in > iptables -N $server_ip-out > iptables -A $server_ip-in -j RETURN > iptables -A $server_ip-out -j RETURN > iptables -A FORWARD -s $server_ip -j $server_ip-out > iptables -A FORWARD -d $server_ip -j $server_ip-in > > and to make the actual measurement: > iptables -nvxL $server_ip-in > iptables -nvxL $server_ip-out > > Resuming, how can i effectively test if and how well htb it's doing the > job ? > > > Help will be appreciated. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From rubens@etica.net Wed Jan 28 02:12:14 2004 From: rubens@etica.net (rubens@etica.net) Date: Wed, 28 Jan 2004 00:12:14 -0200 (BRST) Subject: [LARTC] tncg and bandwidth limiting In-Reply-To: <5.2.0.9.0.20040127150331.00ac7bd0@mail.web-ster.com> Message-ID: On Tue, 27 Jan 2004, Scott Baker wrote: > I'm curious if some of the other experts out there wouldn't have a "better" > way to do what I'm doing. I'd like to do HTB ingress as well, but it > complains that the the ingress qdisc doesn't allow inside classes or > something like that. I think this will work for me, I just want to make > sure this is the best way to do things. You don't need classes if you just want to shape traffic to a specific rate. Use a classless qdisc like tbf: tbf (mtu 1.5kB,limit 10kB,rate 1kBps,burst 2kB) { fifo; } Rubens From roy@xxx.lt Wed Jan 28 04:57:25 2004 From: roy@xxx.lt (Roy) Date: Wed, 28 Jan 2004 06:57:25 +0200 Subject: [LARTC] RE: LARTC digest, Vol 1 #1558 - 9 msgs References: <50F73B338A7FD943B7937BBCF99BFBDE33B0FF@mail.sofaware.com> <40165504.5010605@otaku42.de> Message-ID: <00bc01c3e55b$3964fc50$030aa8c0@t> > As was mentioned before: the netfilter framework itself is able to drop > packets without negative side effects. So this should also be possible > for IMQ (or any other network device driver). > Well, this needs to be tested. I will try nerfilter module which can drop each n-th packet. I wonder what will happen. At least policer was not sucessfull for dropping packets. Basicaly all this could be fixed if to find a way to tell kernel that device is busy and dont want more data. From mabrown-lartc@securepipe.com Wed Jan 28 06:18:24 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Wed, 28 Jan 2004 00:18:24 -0600 (CST) Subject: [LARTC] tncg and bandwidth limiting In-Reply-To: <5.2.0.9.0.20040127160516.02e378f0@mail.web-ster.com> References: <5.2.0.9.0.20040127160516.02e378f0@mail.web-ster.com> Message-ID: Scott, : Basically ignore that last message. Earlier message ignored. : I'm trying to do some very simple rate-shaping on an interface. I want : to limit my 100baseT interface to 7 megs both ingress and egress of the : interface. You'll notice that Rubens suggested you use a TBF. This would be perfectly adequate solution for your transmitted traffic. Note that an HTB class and a TBF qdisc are essentially performing the same function. Shaping! Note there is a difference in the traffic control structures created by your tcng configuration. Your egress section will actually be two HTB classes inside an HTB qdisc attached to the INTERFACE in question. In your situation, you do not need both classes (created as siblings), since you are classifying everything into class $all. : I'm curious if some of the other experts out there wouldn't have a : "better" way to do what I'm doing. I'd like to do HTB ingress as well, : but it complains that the the ingress qdisc doesn't allow inside : classes or something like that. I think this will work for me, I just : want to make sure this is the best way to do things. This is a limitation of traffic control under Linux. You can only shape what you transmit [ see IMQ if you want to know how to break this rule ]. So, unless you are going to use IMQ, you'll not be able to shape your local input traffic (if you are a router, you should be able to slow down conversations by "artificially" delaying the packets on the internal interface). However, you don't need to care that you are not shaping on your inbound traffic. You can police the traffic. For the difference between shaping and policing, try here [0]. [ snip ] : htb () { : class ( rate 100Mbps, ceil 100Mbps ) ; /* remove this */ : $all = class ( rate 7Mbps, ceil 7Mbps ) ; : } : ingress { : $p = bucket(rate 7Mbps, burst 100kB, mpu 200B); : class (1) if (conform $p && count $p) || drop; : } After you run your tcng config file through tcc ("tcc < $FILE | less"), you should see (lines broken for readability) the following for the ingress traffic control. I left INTERFACE in the config file--obviously you have #defined it someplace else. tc qdisc add dev INTERFACE ingress tc filter add dev INTERFACE parent ffff:0 protocol all prio 1 \ u32 match u32 0x0 0x0 at 0 classid ffff:1 \ police index 2 rate 875000bps burst 102400 mpu 200 action drop/pass ^^^^^^ Note that the policer will (somewhat harshly) accommodate your desires to limit the traffic accepted inbound on an interface. Best of luck, -Martin [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-shaping http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-policing -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From operations@cynicbytrade.com Wed Jan 28 06:46:19 2004 From: operations@cynicbytrade.com (David Bierce) Date: Wed, 28 Jan 2004 00:46:19 -0600 Subject: [LARTC] IProute and Traffic Control of PPC Message-ID: Has any one ever done it? We are in the planning stages and the majority of the hardware we have available is PPC, what are some thoughts? From mabrown-lartc@securepipe.com Wed Jan 28 06:54:39 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Wed, 28 Jan 2004 00:54:39 -0600 (CST) Subject: [LARTC] Shaping Device Aliases In-Reply-To: <200401161117.46491.lartc@bobich.net> References: <200401151118.04852.gordan@bobich.net> <40078365.5030500@snapgear.com> <200401161117.46491.lartc@bobich.net> Message-ID: Gordan, I've noticed that you are trying to use aliased IP addresses and traffic control together, and you are a bit frustrated that tc doesn't handle aliased interface names. : > > I understand that device aliases (e.g. eth2:3) are not shapeable. : > > Does anybody know if this functionality is planned in the future? : > : > None of the new(er) networking tools recognise device aliases, : > because on all recent linux releases, aliases don't exist. : > the ethX:X notation is a legacy notation used only by the ifconfig : > program. everything else just sees a ethX with more than one IP : > address. : > : > So you just run your shaping rules on the real interfaces, and : > restrict it's operation with IP address filtering. : : Yes, I am aware of that. However, that makes shaping multiple : independent "streams" going through one interface much more difficult. I don't understand why this becomes much more difficult--it just becomes a little more difficult, depending on the number of IP addresses you have active on a given interface. If you can handle multiple addresses on an interface, then shaping traffic on these (known) addresses shouldn't be much more difficult than managing each address. : The only other thing I can think of is setting up a dummy network : device and giving it the IP addresses on all the non-primary subnets : (e.g. multiple DSL lines), and setting up the arp and routing to make : the packet actually go via the primary interface. This sounds like a very confused idea. I'm not sure it's worth the hassle--as I hope I can convince you below. [ more stuff snipped ] : Has anybody got any thoughts on this? I have some thoughts, which I hope can help you understand why you will be able to use the traffic control tools to accomplish your filtering. For posterity, I'll reiterate some of what has come before. IP aliases don't exist. This is a convention for ifconfig. "ip addr show" will display all IP addresses active on a given interface. Traffic control is the last thing performed before turning the packet over to the device driver and hardware. Similarly, it is the first thing called on receipt of a packet. See diagrams KPTD [0] and ebtables packet flow [1]. In this case, you can use any number of techniques to identify the packets with tc tools based on their IP addresses--the convenience of the aliased interface naming is simply an obstruction of the real path the packet takes. : If this would work, maybe it should be documented in the advanced : routing howto, as I can see how there might be a lot of people out : there who would find it useful. Let me suggest a possibility, if we assume a nested configuration. Let's say you have IP0 and IP1 active on interface eth3 and you want to make sure that bandwidth is split 75/25 between these two and you want them to share bandwidth. Classic bandwidth-sharing situation....in the tcng config below, you'd need to #define IP0 and IP1, but then you'd have a simple configuration. If you needed to further subdivide traffic within each of the IP0 and IP1 classes, you'd have an easy way to do so. dev eth0 { egress { class ( <$ip0> ) if ip_src == IP0 ; class ( <$ip1> ) if ip_src == IP1 ; htb () { class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */ $ip0 = class ( rate 1024kbps, ceil 1544kbps ) ; $ip1 = class ( rate 384kbps, ceil 1544kbps ) ; } } } } Alternately, you may wish to simulate virtual circuits with each of the IP addresses on a machine. In this case, you could use separate root classes attached to the HTB qdisc, or another class. You can prevent the two classes from competing with each other by setting the rate and ceil to the same value. Here's a very simple permutation of the above. dev eth0 { egress { class ( <$ip0> ) if ip_src == IP0 ; class ( <$ip1> ) if ip_src == IP1 ; htb () { class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */ $ip0 = class ( rate 1024kbps, ceil 1024kbps ) ; $ip1 = class ( rate 384kbps, ceil 384kbps ) ; } } } } Best of luck, Gordan! -Martin [0] http://www.docum.org/stef.coene/qos/kptd/ [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From mage@adamant.net Wed Jan 28 08:25:00 2004 From: mage@adamant.net (Alexander Trotsai) Date: Wed, 28 Jan 2004 10:25:00 +0200 Subject: [LARTC] IMQ Stability In-Reply-To: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> References: <004601c3e1d6$6b6778a0$b53afea9@kazvx88> Message-ID: <20040128082500.GQ2302@blackhole.adamant.ua> On Fri, Jan 23, 2004 at 10:29:13AM -0700, Michael S. Kazmier wrote: MSK>Hello all, MSK>I have been doing a lot of archive searching over the last week reading MSK>posts on IMQ and it's apparent stability / instability. I have seen a MSK>number of posts about it not being maintained as well. Can anyone talk to MSK>me about IMQ's stability in a heavy throughput environment (20 Mbps) and MSK>what was causing IMQ to fail if you know. I use it and it's work OK for me Traffic at some router up to 30-40 Mbit IMQ has one trouble Don't assing address to imq interface becase kernel crash it you do this. -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Big trouble - ..disk or the processor is on fire. From rabs@dimension-virtual.com Wed Jan 28 10:01:56 2004 From: rabs@dimension-virtual.com (=?iso-8859-15?q?Ra=FAl=20Alexis=20Betancort=20Santana?=) Date: Wed, 28 Jan 2004 10:01:56 +0000 Subject: [LARTC] Problems with multipath routing. Message-ID: <200401281002.00051.rabs@dimension-virtual.com> Hi all, I have setup two multipath route tables on my system for doing failover routing, What I want it's that if GW at route1 of the MP is dead, traffic goes by route2, for doing that I have created the multipath routes as follows: ip route add table mail.traffic proto static nexthop via ${GW1} dev eth1 weight 1 nexthop via ${GW2} dev eth1 weight 250 But it does not run as I espected, I want that most (all if posible) the traffic goes by GW1, and if it is down (DgD patches are applied) traffic must goes by GW2, the kernel it's not taking into account the weight parameter or maybe I'm doing it wrong. Any hit will be apreciated ... Best regards From adi@nobugconsulting.ro Wed Jan 28 14:03:33 2004 From: adi@nobugconsulting.ro (Adrian Coman) Date: Wed, 28 Jan 2004 16:03:33 +0200 Subject: [LARTC] small netwok traffic shaping Message-ID: <4017C135.8040703@nobugconsulting.ro> Hi, First of all I must say that I'm a newbie in the network adimistration domain. I have the following situation: a network composed of ~10 computers which are connected to the internet through a gateway. The connection speed is 128kbps for the addresses outside my country, and 10mbps for the addresses in my country. I would like to set-up a traffic shaper on the router machine with the following features: - if all the users are browsing/downloading in the same time, the bandwidth must be equally shared - if the users are using file sharing software, their bandwidth for such applications must be limited to maximum 10kbps if noone else is requesting bandwidth for normal http transfers, else the bandwidth must be 0 for such applications. - i want also that some computers from the network to get priviledged access, with no restrictions If possible i wold also like that: - the users who are using network scanning software to have their bandwidth cut to 0 for a period The router has 2 NIC's eth0 and eth1. eth0 is connected to the outside world and eth1 to the internal network. Can you help me with examples? What solutions do you advise me to implement? I know I can read the manuals (as most of my friends say), but it's very difficult for me to get it right form the first time. Thanks, Adrian From mrenzmann@otaku42.de Wed Jan 28 14:55:36 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Wed, 28 Jan 2004 15:55:36 +0100 Subject: [LARTC] small netwok traffic shaping In-Reply-To: <4017C135.8040703@nobugconsulting.ro> References: <4017C135.8040703@nobugconsulting.ro> Message-ID: <4017CD68.6080508@otaku42.de> Buna ziua, Adrian :) Adrian Coman wrote: > - if the users are using file sharing software, their bandwidth for such > applications must be limited to maximum 10kbps if noone else is > requesting bandwidth for normal http transfers, else the bandwidth must > be 0 for such applications. There are two things that might be interesting for your work: 1. http://l7-filter.sf.net That's a facility for either the QoS framework or iptables that enables to distinct between several application layer (iso layer 7, hence the name) protocols such as http and ftp. You could use that to apply special marks to packets which then help you to classify the packets. 2. http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html That's an extenstion to iptables which allows to mark connections that belong to common peer-to-peer applications (which would be helpful to apply the above quoted rule). Unfortunately I can't give you any more pointers, as I'm myself new to the whole QoS-stuff. But I hope this will help you a little. La revedere. Mike From bakers@web-ster.com Thu Jan 29 00:03:45 2004 From: bakers@web-ster.com (Scott Baker) Date: Wed, 28 Jan 2004 16:03:45 -0800 Subject: [LARTC] Burst Rate? Message-ID: <5.2.0.9.0.20040128160128.00ac83d0@mail.web-ster.com> If I'm using the following to very simply police my incoming bandwidth: ingress { $p = bucket(rate 7Mbps, burst 1000kB, mpu 200B); class (1) if (conform $p && count $p) || drop; } How should i be calculate the burst rate? Cisco has their own special algorithm for calculating the correct burst rate, is there a similar method I should be using to calculate burst on a linux box? Also are there any improvement in the 2.6.x kernel with regards to traffic shaping? Scott Scott Baker - Network Engineer - RHCE bakers @ web-ster . com - 503.266.8253 From mrenzmann@otaku42.de Thu Jan 29 00:06:29 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Thu, 29 Jan 2004 01:06:29 +0100 Subject: [LARTC] Question(s) for the programming gurus Message-ID: <40184E85.6000807@otaku42.de> Hi all. I'm quite new to the concepts of the "traffic control" framework, and I've got a programming-related question. Hopefully someone has the answer... Is it possible, either for the device driver itself or for a userspace program, to get information about how many packets are currently queued for a given network interface? Let's describe it a little more in detail: I have a network interface eth0 in my linux box. Now I apply traffic shaping to that interface, for example the outgoing traffic is shaped down to 1 MBit/s. There is an application that creates packets which are meant to be sent out via eth0, and the application creates its packets with a much higher rate than 1 MBit/s. This would result in the shaper enqueuing packets for eth0 and, sooner or later, in dropping some of the packets if the queue is full. So I want to slow down the rate at which the application creates its packets. The easiest way would be to take a look at the "traffic control" queues for eth0 and check their current state. When the queue is filled up to a specified level, the application should stop creation of new packets until the queue has been emptied. (*) So, is there any way for my application to check the state of the eth0-queues? Or is this possible for the driver of eth0 (as I'm in control of this driver, I could implement a way to pass the needed information down to the application if necessary)? Next question: if I understood the concepts of the "traffic control" system correctly, one could add several queues to a single device. Is there any way to simply get the total amount of packets that are waiting in all attached queues? Or would I need to check each queue and sum up the values? And last question: what kind of information can I get about the currently enqueued packets? Just the amount of packets that are enqueued, or only the amount of enqueued bytes, or both? I'd appreciate any kind of help very much. Pointers to existing documentation welcome - I didn't find the answers in the docs I found, but maybe I just didn't search well enough (or in the wrong places)? Thanks in advance. Bye, Mike (*) In other words: I want to have the effects of slowing down the traffic generation of my application without having to care about the actual implementation of the traffic shaping. In my special case this makes sense and would save me a lot of work. From x11@h2o.pieva.net Thu Jan 29 06:44:22 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 29 Jan 2004 08:44:22 +0200 Subject: [LARTC] small netwok traffic shaping In-Reply-To: <4017CD68.6080508@otaku42.de> References: <4017C135.8040703@nobugconsulting.ro> <4017CD68.6080508@otaku42.de> Message-ID: <4018ABC6.6060306@h2o.pieva.net> Michael Renzmann wrote: > 2. http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html > That's an extenstion to iptables which allows to mark connections that > belong to common peer-to-peer applications (which would be helpful to > apply the above quoted rule). I personally use ipt_p2p for that and it gets job done pretty well. http://freshmeat.net/projects/ipt_p2p/ From markryan@cfl.rr.com Thu Jan 29 03:11:42 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Wed, 28 Jan 2004 22:11:42 -0500 Subject: [LARTC] wonder shaper problems Message-ID: <001c01c3e615$9f02ac00$6501a8c0@underworld> I just installed Xandros 2.0 Desktop. I used apt-get to install iproute. I then downloaded wondershaper 1.1a from the website. I edited the script as the readme says. I went to console and started the wondershaper script...and i get the following error messages. RTNETLINK answers: Invalid Argument many times. Any ideas what is wrong? MArk From mrenzmann@otaku42.de Thu Jan 29 07:42:57 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Thu, 29 Jan 2004 08:42:57 +0100 Subject: [LARTC] small netwok traffic shaping In-Reply-To: <4018ABC6.6060306@h2o.pieva.net> References: <4017C135.8040703@nobugconsulting.ro> <4017CD68.6080508@otaku42.de> <4018ABC6.6060306@h2o.pieva.net> Message-ID: <4018B981.9010303@otaku42.de> Hi. Artu-ras Šlajus wrote: > I personally use ipt_p2p for that and it gets job done pretty well. > http://freshmeat.net/projects/ipt_p2p/ Thanks for the hint, I'll give it a try. Bye, Mike From larslan@solan.zapto.org Thu Jan 29 08:43:16 2004 From: larslan@solan.zapto.org (Lars Landmark) Date: Thu, 29 Jan 2004 09:43:16 +0100 (CET) Subject: [LARTC] Question(s) for the programming gurus In-Reply-To: <40184E85.6000807@otaku42.de> References: <40184E85.6000807@otaku42.de> Message-ID: Hi Michael Renzmann; On Thu, 29 Jan 2004, Michael Renzmann wrote: > Is it possible, either for the device driver itself or for a userspace > program, to get information about how many packets are currently queued > for a given network interface? Yes, if a small extension to the scheduler in question is carried out. You may add a variable counting packets in the enqueue () and dequeue(), and either write this to the /proc file system or poll the result with the help from tc. Look at sch_fifo.c, it counts packets in the queue. But it does not report it any further. Lars > > Let's describe it a little more in detail: > > I have a network interface eth0 in my linux box. Now I apply traffic > shaping to that interface, for example the outgoing traffic is shaped > down to 1 MBit/s. There is an application that creates packets which are > meant to be sent out via eth0, and the application creates its packets > with a much higher rate than 1 MBit/s. This would result in the shaper > enqueuing packets for eth0 and, sooner or later, in dropping some of the > packets if the queue is full. > > So I want to slow down the rate at which the application creates its > packets. The easiest way would be to take a look at the "traffic > control" queues for eth0 and check their current state. When the queue > is filled up to a specified level, the application should stop creation > of new packets until the queue has been emptied. (*) > > So, is there any way for my application to check the state of the > eth0-queues? Or is this possible for the driver of eth0 (as I'm in > control of this driver, I could implement a way to pass the needed > information down to the application if necessary)? > > Next question: if I understood the concepts of the "traffic control" > system correctly, one could add several queues to a single device. Is > there any way to simply get the total amount of packets that are waiting > in all attached queues? Or would I need to check each queue and sum up > the values? Using class based queuing you may isolate each queue from each other and count packets each queue holds. On the other hand, if you want the total amount of queued packets, then a global variable would help you. > And last question: what kind of information can I get about the > currently enqueued packets? Just the amount of packets that are > enqueued, or only the amount of enqueued bytes, or both? You may obtain both. > I'd appreciate any kind of help very much. Pointers to existing > documentation welcome - I didn't find the answers in the docs I found, > but maybe I just didn't search well enough (or in the wrong places)? > > Thanks in advance. > > Bye, Mike > > (*) In other words: I want to have the effects of slowing down the > traffic generation of my application without having to care about the > actual implementation of the traffic shaping. In my special case this > makes sense and would save me a lot of work. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From mrenzmann@otaku42.de Thu Jan 29 10:23:39 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Thu, 29 Jan 2004 11:23:39 +0100 Subject: [LARTC] Question(s) for the programming gurus In-Reply-To: References: <40184E85.6000807@otaku42.de> Message-ID: <4018DF2B.5060202@otaku42.de> Hi Lars. First of all, thanks for your fast reply. Lars Landmark wrote: >>Is it possible, either for the device driver itself or for a userspace >>program, to get information about how many packets are currently queued >>for a given network interface? > Yes, if a small extension to the scheduler in question is carried out. > You may add a variable counting packets in the enqueue () and dequeue(), > and either write this to the /proc file system or poll the result with the > help from tc. Look at sch_fifo.c, it counts packets in the queue. But it > does not report it any further. Hmm... just to get it right: if I modify the source of any scheduler, there is no need to recompile the kernel, as the schedulers are "encapsulated" completely as loadable kernel modules? Because that is a important criterion for my decision, I want to (better: have to) avoid to recompile the kernel at any costs. >>Next question: if I understood the concepts of the "traffic control" >>system correctly, one could add several queues to a single device. Is >>there any way to simply get the total amount of packets that are waiting >>in all attached queues? Or would I need to check each queue and sum up >>the values? > Using class based queuing you may isolate each queue from each other and > count packets each queue holds. On the other hand, if you want the total > amount of queued packets, then a global variable would help you. As far as I understood the concepts of the tc framework, each interface has a queuing discipline attached. Optionally, this discipline may have several filters and classes. Filters decide which packet belongs to which class, and each class may optionally have other qdiscs attached to it. Is this understanding correct? If so, then in the following situation... +----[client1] | (Internet)---eth0--[router]--eth1--+----[client2] | +----[client3] ... I'd choose a discipline that implements classes. At least one class per client with one qdisc attached to each class would be necessary to allow bandwidth shaping for traffic that passes the router on its way from the clients to the Internet. Right? In this case I need to modify the "root discipline" in order to implement a "per class" counter, so that I can see if the queue for a client fills up. While thinking about the above, another idea came to my mind. Maybe there is a way to avoid to modify every scheduler that might become interesting for the described task. Wouldn't it be more reasonable to write my own dummy qdisc handler that just implements the very basic functions needed to attach another qdisc to it? In this case, the dummy only needed to have the functions enqueue() and dequeue() which keep the counter up-to-date. Of course one counter per class would be necessary in the above described scenario, but that shouldn't be much harder than having a global counter. That could be thought to be a "statistic qdisc" which also could be used for simple accounting purposes... hmm, do you think that this could work? If so, I'd like to try that one. Bye, Mike From tusharthakker@elitecore.com Fri Jan 30 01:38:46 2004 From: tusharthakker@elitecore.com (Tushar Thakker) Date: Thu, 29 Jan 2004 17:38:46 -0800 Subject: [LARTC] Problems with multipath routing. References: <20040129105532.10106.92017.Mailman@outpost.ds9a.nl> Message-ID: <01a401c3e6d1$cd410690$3301a8c0@elitecore1> hello, you can use the following script, IP=/sbin/ip ${IP} route add default via ${STATICGW1} dev ${STATICIF1} src ${STATICIP1} proto static table 200 ${IP} route append prohibit default table 200 metric 1 proto static ${IP} route add default via ${STATICGW2} dev ${STATICIF2} src ${STATICIP2} proto static table 200 ${IP} rule add prio 200 from all lookup 200 this will first lookup the first line, i.e. gateway-1 and if it is failed, it will try for gateway-2, it would be good if you apply julian's routing patch fromm the following location, http://www.ssi.bg/~ja/#routes-2.4 for more info. you can refer this document too, http://www.ssi.bg/~ja/nano.txt regards, Tushar Thakker ---------------------------------------------------------------- Success usually comes to those who are too busy to be looking for it ---------------------------------------------------------------- ----- Original Message ----- From: To: Sent: Thursday, January 29, 2004 2:55 AM Subject: LARTC digest, Vol 1 #1563 - 9 msgs > 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: tncg and bandwidth limiting (Martin A. Brown) > 2. IProute and Traffic Control of PPC (David Bierce) > 3. Re: Shaping Device Aliases (Martin A. Brown) > 4. Re: IMQ Stability (Alexander Trotsai) > 5. Problems with multipath routing. (=?iso-8859-15?q?Ra=FAl=20Alexis=20Betancort=20Santana?=) > 6. small netwok traffic shaping (Adrian Coman) > 7. Re: small netwok traffic shaping (Michael Renzmann) > 8. Burst Rate? (Scott Baker) > 9. Question(s) for the programming gurus (Michael Renzmann) > > --__--__-- > > Message: 1 > Date: Wed, 28 Jan 2004 00:18:24 -0600 (CST) > From: "Martin A. Brown" > To: Scott Baker > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] tncg and bandwidth limiting > > Scott, > > : Basically ignore that last message. > > Earlier message ignored. > > : I'm trying to do some very simple rate-shaping on an interface. I want > : to limit my 100baseT interface to 7 megs both ingress and egress of the > : interface. > > You'll notice that Rubens suggested you use a TBF. This would be > perfectly adequate solution for your transmitted traffic. Note that an > HTB class and a TBF qdisc are essentially performing the same function. > Shaping! > > Note there is a difference in the traffic control structures created by > your tcng configuration. Your egress section will actually be two HTB > classes inside an HTB qdisc attached to the INTERFACE in question. In > your situation, you do not need both classes (created as siblings), since > you are classifying everything into class $all. > > : I'm curious if some of the other experts out there wouldn't have a > : "better" way to do what I'm doing. I'd like to do HTB ingress as well, > : but it complains that the the ingress qdisc doesn't allow inside > : classes or something like that. I think this will work for me, I just > : want to make sure this is the best way to do things. > > This is a limitation of traffic control under Linux. You can only shape > what you transmit [ see IMQ if you want to know how to break this rule ]. > So, unless you are going to use IMQ, you'll not be able to shape your > local input traffic (if you are a router, you should be able to slow down > conversations by "artificially" delaying the packets on the internal > interface). > > However, you don't need to care that you are not shaping on your inbound > traffic. You can police the traffic. For the difference between shaping > and policing, try here [0]. > > [ snip ] > > : htb () { > : class ( rate 100Mbps, ceil 100Mbps ) ; /* remove this */ > : $all = class ( rate 7Mbps, ceil 7Mbps ) ; > : } > > : ingress { > : $p = bucket(rate 7Mbps, burst 100kB, mpu 200B); > : class (1) if (conform $p && count $p) || drop; > : } > > After you run your tcng config file through tcc ("tcc < $FILE | less"), > you should see (lines broken for readability) the following for the > ingress traffic control. I left INTERFACE in the config file--obviously > you have #defined it someplace else. > > tc qdisc add dev INTERFACE ingress > tc filter add dev INTERFACE parent ffff:0 protocol all prio 1 \ > u32 match u32 0x0 0x0 at 0 classid ffff:1 \ > police index 2 rate 875000bps burst 102400 mpu 200 action drop/pass > ^^^^^^ > > Note that the policer will (somewhat harshly) accommodate your desires to > limit the traffic accepted inbound on an interface. > > Best of luck, > > -Martin > > [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-shaping > http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-policing > > -- > Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com > > > --__--__-- > > Message: 2 > To: LARTC@mailman.ds9a.nl > From: David Bierce > Date: Wed, 28 Jan 2004 00:46:19 -0600 > Subject: [LARTC] IProute and Traffic Control of PPC > > Has any one ever done it? We are in the planning stages and the > majority of the hardware we have available is PPC, what are some > thoughts? > > > --__--__-- > > Message: 3 > Date: Wed, 28 Jan 2004 00:54:39 -0600 (CST) > From: "Martin A. Brown" > To: Gordan Bobic > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Shaping Device Aliases > > Gordan, > > I've noticed that you are trying to use aliased IP addresses and traffic > control together, and you are a bit frustrated that tc doesn't handle > aliased interface names. > > : > > I understand that device aliases (e.g. eth2:3) are not shapeable. > : > > Does anybody know if this functionality is planned in the future? > : > > : > None of the new(er) networking tools recognise device aliases, > : > because on all recent linux releases, aliases don't exist. > : > the ethX:X notation is a legacy notation used only by the ifconfig > : > program. everything else just sees a ethX with more than one IP > : > address. > : > > : > So you just run your shaping rules on the real interfaces, and > : > restrict it's operation with IP address filtering. > : > : Yes, I am aware of that. However, that makes shaping multiple > : independent "streams" going through one interface much more difficult. > > I don't understand why this becomes much more difficult--it just becomes a > little more difficult, depending on the number of IP addresses you have > active on a given interface. If you can handle multiple addresses on an > interface, then shaping traffic on these (known) addresses shouldn't be > much more difficult than managing each address. > > : The only other thing I can think of is setting up a dummy network > : device and giving it the IP addresses on all the non-primary subnets > : (e.g. multiple DSL lines), and setting up the arp and routing to make > : the packet actually go via the primary interface. > > This sounds like a very confused idea. I'm not sure it's worth the > hassle--as I hope I can convince you below. > > [ more stuff snipped ] > > : Has anybody got any thoughts on this? > > I have some thoughts, which I hope can help you understand why you will be > able to use the traffic control tools to accomplish your filtering. For > posterity, I'll reiterate some of what has come before. > > IP aliases don't exist. This is a convention for ifconfig. "ip addr > show" will display all IP addresses active on a given interface. > > Traffic control is the last thing performed before turning the packet over > to the device driver and hardware. Similarly, it is the first thing > called on receipt of a packet. See diagrams KPTD [0] and ebtables packet > flow [1]. > > In this case, you can use any number of techniques to identify the packets > with tc tools based on their IP addresses--the convenience of the aliased > interface naming is simply an obstruction of the real path the packet > takes. > > : If this would work, maybe it should be documented in the advanced > : routing howto, as I can see how there might be a lot of people out > : there who would find it useful. > > Let me suggest a possibility, if we assume a nested configuration. Let's > say you have IP0 and IP1 active on interface eth3 and you want to make > sure that bandwidth is split 75/25 between these two and you want them to > share bandwidth. Classic bandwidth-sharing situation....in the tcng > config below, you'd need to #define IP0 and IP1, but then you'd have a > simple configuration. If you needed to further subdivide traffic within > each of the IP0 and IP1 classes, you'd have an easy way to do so. > > dev eth0 { > egress { > class ( <$ip0> ) if ip_src == IP0 ; > class ( <$ip1> ) if ip_src == IP1 ; > htb () { > class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */ > $ip0 = class ( rate 1024kbps, ceil 1544kbps ) ; > $ip1 = class ( rate 384kbps, ceil 1544kbps ) ; > } > } > } > } > > Alternately, you may wish to simulate virtual circuits with each of the IP > addresses on a machine. In this case, you could use separate root > classes attached to the HTB qdisc, or another class. You can prevent the > two classes from competing with each other by setting the rate and ceil to > the same value. Here's a very simple permutation of the above. > > dev eth0 { > egress { > class ( <$ip0> ) if ip_src == IP0 ; > class ( <$ip1> ) if ip_src == IP1 ; > htb () { > class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */ > $ip0 = class ( rate 1024kbps, ceil 1024kbps ) ; > $ip1 = class ( rate 384kbps, ceil 384kbps ) ; > } > } > } > } > > > Best of luck, Gordan! > > -Martin > > [0] http://www.docum.org/stef.coene/qos/kptd/ > [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png > > -- > Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com > > > --__--__-- > > Message: 4 > Date: Wed, 28 Jan 2004 10:25:00 +0200 > From: Alexander Trotsai > To: "Michael S. Kazmier" > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] IMQ Stability > > On Fri, Jan 23, 2004 at 10:29:13AM -0700, Michael S. Kazmier wrote: > MSK>Hello all, > > MSK>I have been doing a lot of archive searching over the last week reading > MSK>posts on IMQ and it's apparent stability / instability. I have seen a > MSK>number of posts about it not being maintained as well. Can anyone talk to > MSK>me about IMQ's stability in a heavy throughput environment (20 Mbps) and > MSK>what was causing IMQ to fail if you know. > > I use it and it's work OK for me > Traffic at some router up to 30-40 Mbit > > IMQ has one trouble > Don't assing address to imq interface becase kernel crash it > you do this. > > -- > Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC > My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] > Big trouble - ..disk or the processor is on fire. > > --__--__-- > > Message: 5 > From: =?iso-8859-15?q?Ra=FAl=20Alexis=20Betancort=20Santana?= > Organization: =?iso-8859-15?q?Dimensi=F3n=20Virtual?= S.L. > To: lartc@mailman.ds9a.nl > Date: Wed, 28 Jan 2004 10:01:56 +0000 > Subject: [LARTC] Problems with multipath routing. > > Hi all, I have setup two multipath route tables on my system for doing > failover routing, What I want it's that if GW at route1 of the MP is dead, > traffic goes by route2, for doing that I have created the multipath routes as > follows: > > ip route add table mail.traffic proto static nexthop via ${GW1} dev eth1 > weight 1 nexthop via ${GW2} dev eth1 weight 250 > > But it does not run as I espected, I want that most (all if posible) the > traffic goes by GW1, and if it is down (DgD patches are applied) traffic must > goes by GW2, the kernel it's not taking into account the weight parameter or > maybe I'm doing it wrong. > > Any hit will be apreciated ... > > Best regards > > --__--__-- > > Message: 6 > Date: Wed, 28 Jan 2004 16:03:33 +0200 > From: Adrian Coman > Organization: NoBug Consulting > To: lartc@mailman.ds9a.nl > Subject: [LARTC] small netwok traffic shaping > > Hi, > > First of all I must say that I'm a newbie in the network adimistration domain. > > I have the following situation: a network composed of ~10 computers which are connected to > the internet through a gateway. The connection speed is 128kbps for the addresses outside > my country, and 10mbps for the addresses in my country. > > I would like to set-up a traffic shaper on the router machine with the following features: > > - if all the users are browsing/downloading in the same time, the bandwidth must be > equally shared > - if the users are using file sharing software, their bandwidth for such applications must > be limited to maximum 10kbps if noone else is requesting bandwidth for normal http > transfers, else the bandwidth must be 0 for such applications. > - i want also that some computers from the network to get priviledged access, with no > restrictions > > If possible i wold also like that: > - the users who are using network scanning software to have their bandwidth cut to 0 for a > period > > The router has 2 NIC's eth0 and eth1. eth0 is connected to the outside world and eth1 to > the internal network. > > Can you help me with examples? What solutions do you advise me to implement? > > I know I can read the manuals (as most of my friends say), but it's very difficult for me > to get it right form the first time. > > > > Thanks, > Adrian > > > > --__--__-- > > Message: 7 > Date: Wed, 28 Jan 2004 15:55:36 +0100 > From: Michael Renzmann > To: Adrian Coman > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] small netwok traffic shaping > > Buna ziua, Adrian :) > > Adrian Coman wrote: > > - if the users are using file sharing software, their bandwidth for such > > applications must be limited to maximum 10kbps if noone else is > > requesting bandwidth for normal http transfers, else the bandwidth must > > be 0 for such applications. > > There are two things that might be interesting for your work: > > 1. http://l7-filter.sf.net > That's a facility for either the QoS framework or iptables that enables > to distinct between several application layer (iso layer 7, hence the > name) protocols such as http and ftp. You could use that to apply > special marks to packets which then help you to classify the packets. > > 2. http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html > That's an extenstion to iptables which allows to mark connections that > belong to common peer-to-peer applications (which would be helpful to > apply the above quoted rule). > > Unfortunately I can't give you any more pointers, as I'm myself new to > the whole QoS-stuff. But I hope this will help you a little. > > La revedere. > Mike > > > --__--__-- > > Message: 8 > Date: Wed, 28 Jan 2004 16:03:45 -0800 > To: lartc@mailman.ds9a.nl > From: Scott Baker > Subject: [LARTC] Burst Rate? > > If I'm using the following to very simply police my incoming bandwidth: > > ingress { > $p = bucket(rate 7Mbps, burst 1000kB, mpu 200B); > class (1) if (conform $p && count $p) || drop; > } > > How should i be calculate the burst rate? Cisco has their own special > algorithm for calculating the correct burst rate, is there a similar method > I should be using to calculate burst on a linux box? Also are there any > improvement in the 2.6.x kernel with regards to traffic shaping? > > Scott > > > Scott Baker - Network Engineer - RHCE > bakers @ web-ster . com - 503.266.8253 > > > --__--__-- > > Message: 9 > Date: Thu, 29 Jan 2004 01:06:29 +0100 > From: Michael Renzmann > To: "lartc@mailman.ds9a.nl" > Subject: [LARTC] Question(s) for the programming gurus > > Hi all. > > I'm quite new to the concepts of the "traffic control" framework, and > I've got a programming-related question. Hopefully someone has the answer... > > Is it possible, either for the device driver itself or for a userspace > program, to get information about how many packets are currently queued > for a given network interface? > > Let's describe it a little more in detail: > > I have a network interface eth0 in my linux box. Now I apply traffic > shaping to that interface, for example the outgoing traffic is shaped > down to 1 MBit/s. There is an application that creates packets which are > meant to be sent out via eth0, and the application creates its packets > with a much higher rate than 1 MBit/s. This would result in the shaper > enqueuing packets for eth0 and, sooner or later, in dropping some of the > packets if the queue is full. > > So I want to slow down the rate at which the application creates its > packets. The easiest way would be to take a look at the "traffic > control" queues for eth0 and check their current state. When the queue > is filled up to a specified level, the application should stop creation > of new packets until the queue has been emptied. (*) > > So, is there any way for my application to check the state of the > eth0-queues? Or is this possible for the driver of eth0 (as I'm in > control of this driver, I could implement a way to pass the needed > information down to the application if necessary)? > > Next question: if I understood the concepts of the "traffic control" > system correctly, one could add several queues to a single device. Is > there any way to simply get the total amount of packets that are waiting > in all attached queues? Or would I need to check each queue and sum up > the values? > > And last question: what kind of information can I get about the > currently enqueued packets? Just the amount of packets that are > enqueued, or only the amount of enqueued bytes, or both? > > I'd appreciate any kind of help very much. Pointers to existing > documentation welcome - I didn't find the answers in the docs I found, > but maybe I just didn't search well enough (or in the wrong places)? > > Thanks in advance. > > Bye, Mike > > (*) In other words: I want to have the effects of slowing down the > traffic generation of my application without having to care about the > actual implementation of the traffic shaping. In my special case this > makes sense and would save me a lot of work. > > > > --__--__-- > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc > > > End of LARTC Digest > From Aron@sofaware.com Thu Jan 29 12:58:20 2004 From: Aron@sofaware.com (Aron Brand) Date: Thu, 29 Jan 2004 14:58:20 +0200 Subject: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE33B338@mail.sofaware.com> Martin, If I understand whay you are suggesting, there is a problem in your design: It will only work if you use Hide NAT. The problem is that the ip_src =3D=3D IP0 rule is wrong: The ip_src is not changed by the router = and it is not equal to the IP of any of the machine interfaces. Can you think of a solution that will work in the following reasonabl scenario: Lets say I have two T1 internet connections connected to one ethernet interface. I do not use Hide-NAT. I want to guarantee at least 512kbps to HTTP traffic on each line (seperately) in the 'virtual circuit' method that you mentioned. I see no way do do this unless I can attach a qdisc to a specific virtual interface. Aron > Message: 3 > Date: Wed, 28 Jan 2004 00:54:39 -0600 (CST) > From: "Martin A. Brown" > To: Gordan Bobic > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Shaping Device Aliases > > Gordan, > > I've noticed that you are trying to use aliased IP addresses and=20 > traffic control together, and you are a bit frustrated that tc doesn't > handle aliased interface names. > > : > > I understand that device aliases (e.g. eth2:3) are not shapeable. > : > > Does anybody know if this functionality is planned in the future? > : > > : > None of the new(er) networking tools recognise device aliases, > : > because on all recent linux releases, aliases don't exist. > : > the ethX:X notation is a legacy notation used only by the=20 > ifconfig > : > program. everything else just sees a ethX with more than one IP > : > address. > : > > : > So you just run your shaping rules on the real interfaces, and > : > restrict it's operation with IP address filtering. > : > : Yes, I am aware of that. However, that makes shaping multiple > : independent "streams" going through one interface much more difficult. > > I don't understand why this becomes much more difficult--it just=20 > becomes a little more difficult, depending on the number of IP=20 > addresses you have active on a given interface. If you can handle=20 > multiple addresses on an interface, then shaping traffic on these=20 > (known) addresses shouldn't be much more difficult than managing each address. > > : The only other thing I can think of is setting up a dummy network > : device and giving it the IP addresses on all the non-primary=20 > subnets > : (e.g. multiple DSL lines), and setting up the arp and routing to=20 > make > : the packet actually go via the primary interface. > > This sounds like a very confused idea. I'm not sure it's worth the=20 > hassle--as I hope I can convince you below. > > [ more stuff snipped ] > > : Has anybody got any thoughts on this? > > I have some thoughts, which I hope can help you understand why you=20 > will be able to use the traffic control tools to accomplish your=20 > filtering. For posterity, I'll reiterate some of what has come before. > > IP aliases don't exist. This is a convention for ifconfig. "ip addr=20 > show" will display all IP addresses active on a given interface. > > Traffic control is the last thing performed before turning the packet=20 > over to the device driver and hardware. Similarly, it is the first=20 > thing called on receipt of a packet. See diagrams KPTD [0] and=20 > ebtables packet flow [1]. > > In this case, you can use any number of techniques to identify the=20 > packets with tc tools based on their IP addresses--the convenience of=20 > the aliased interface naming is simply an obstruction of the real path > the packet takes. > > : If this would work, maybe it should be documented in the advanced > : routing howto, as I can see how there might be a lot of people out > : there who would find it useful. > > Let me suggest a possibility, if we assume a nested configuration. =20 > Let's say you have IP0 and IP1 active on interface eth3 and you want=20 > to make sure that bandwidth is split 75/25 between these two and you=20 > want them to share bandwidth. Classic bandwidth-sharing=20 > situation....in the tcng config below, you'd need to #define IP0 and=20 > IP1, but then you'd have a simple configuration. If you needed to=20 > further subdivide traffic within each of the IP0 and IP1 classes, you'd have an easy way to do so. > > dev eth0 { > egress { > class ( <$ip0> ) if ip_src =3D=3D IP0 ; > class ( <$ip1> ) if ip_src =3D=3D IP1 ; > htb () { > class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */ > $ip0 =3D class ( rate 1024kbps, ceil 1544kbps ) ; > $ip1 =3D class ( rate 384kbps, ceil 1544kbps ) ; > } > } > } > } > > Alternately, you may wish to simulate virtual circuits with each of=20 > the IP addresses on a machine. In this case, you could use separate=20 > root classes attached to the HTB qdisc, or another class. You can=20 > prevent the two classes from competing with each other by setting the=20 > rate and ceil to the same value. Here's a very simple permutation of the above. > > dev eth0 { > egress { > class ( <$ip0> ) if ip_src =3D=3D IP0 ; > class ( <$ip1> ) if ip_src =3D=3D IP1 ; > htb () { > class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */ > $ip0 =3D class ( rate 1024kbps, ceil 1024kbps ) ; > $ip1 =3D class ( rate 384kbps, ceil 384kbps ) ; > } > } > } > } > > > Best of luck, Gordan! > > -Martin > > [0] http://www.docum.org/stef.coene/qos/kptd/ > [1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png > > -- > Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From andybr@bol.com.br Thu Jan 29 13:05:52 2004 From: andybr@bol.com.br (andybr) Date: Thu, 29 Jan 2004 11:05:52 -0200 Subject: [LARTC] Whats wrong with my script? Message-ID: Hello, According with rules you are controlling only download (src ip) you should add a (dst rule) also. Make a try. []'s Anderson > I`m trying to shape both upload (eth0) and download (eth1). I made this > script to acomplishthis but the filters are not working even though the > classes and qdiscs are created. What am I doing wrong? #!/bin/bash > > > tc qdisc del dev eth0 root > tc qdisc add dev eth0 root handle 1 htb default 10 r2q 5 > > tc qdisc del dev eth1 root > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 5 > > tc class add dev eth0 parent 1: classid 1:2 htb rate 5M bit burst 15k > > tc class add dev eth0 parent 1:2 classid 1:59 htb rate 64Kbit ceil 64Kbit > tc qdisc add dev eth0 parent 1:59 handle 59 sfq perturb 10 > tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src > 192.168.0.50 classid 1:59 > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5M bit burst 15k > > tc class add dev eth1 parent 1:2 classid 1:56 htb rate 64Kbit ceil 64Kbit > tc qdisc add dev eth1 parent 1:56 handle 56 sfq perturb 10 > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 192.168.0.50 classid 1:56 > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From andybr@bol.com.br Thu Jan 29 12:57:05 2004 From: andybr@bol.com.br (andybr) Date: Thu, 29 Jan 2004 10:57:05 -0200 Subject: [LARTC] Bandwidth Control Message-ID: Hello All, I have a link of 1 mbit from my ISP and some clients with link 128kbit when possible to get 100% but at least 64kbit they must have but until now I couldn't do it with tc and or htb. I was wondering if is possible to make a control like that? Thanks in advance, Anderson __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From larslan@solan.zapto.org Thu Jan 29 13:12:10 2004 From: larslan@solan.zapto.org (Lars Landmark) Date: Thu, 29 Jan 2004 14:12:10 +0100 (CET) Subject: [LARTC] Question(s) for the programming gurus In-Reply-To: <4018DF2B.5060202@otaku42.de> References: <40184E85.6000807@otaku42.de> <4018DF2B.5060202@otaku42.de> Message-ID: > Hmm... just to get it right: if I modify the source of any scheduler, > there is no need to recompile the kernel, as the schedulers are > "encapsulated" completely as loadable kernel modules? Because that is a > important criterion for my decision, I want to (better: have to) avoid > to recompile the kernel at any costs. It is optional to compile it as module or into the kernel. > > As far as I understood the concepts of the tc framework, each interface > has a queuing discipline attached. Optionally, this discipline may have > several filters and classes. Filters decide which packet belongs to > which class, and each class may optionally have other qdiscs attached to > it. Is this understanding correct? You may change the default FIFO discipline, for instance to sfq. Read the lartc documentation, where you can see an example for HTB, if I do remember right :-). > > If so, then in the following situation... > > +----[client1] > | > (Internet)---eth0--[router]--eth1--+----[client2] > | > +----[client3] > > ... I'd choose a discipline that implements classes. At least one class > per client with one qdisc attached to each class would be necessary to > allow bandwidth shaping for traffic that passes the router on its way > from the clients to the Internet. Right? > > In this case I need to modify the "root discipline" in order to > implement a "per class" counter, so that I can see if the queue for a > client fills up. As you explains; a client is associated to a class, then you need an extension to the "class struct" and not the global root "struct". > > > While thinking about the above, another idea came to my mind. Maybe > there is a way to avoid to modify every scheduler that might become > interesting for the described task. Wouldn't it be more reasonable to > write my own dummy qdisc handler that just implements the very basic > functions needed to attach another qdisc to it? In this case, the dummy > only needed to have the functions enqueue() and dequeue() which keep the > counter up-to-date. Of course one counter per class would be necessary > in the above described scenario, but that shouldn't be much harder than > having a global counter. That could be thought to be a "statistic qdisc" > which also could be used for simple accounting purposes... hmm, do you > think that this could work? If so, I'd like to try that one. I do not understand why you should do this, while a class has full control of the packets entering or leaving independent of the qdisc in use. Note; Packets may enter and/or leaving an interface at variable rate, which most likely leads to high oscillation of the packets counted. :( > > Bye, Mike > From hare ram" Message-ID: <018f01c3e66a$b1d5b340$c2bf09ca@huecal> Hi yes its very much possible please visit http://lartc.og or docum.org for examples hare ----- Original Message ----- From: "andybr" To: "Lartc List" Sent: Thursday, January 29, 2004 6:27 PM Subject: [LARTC] Bandwidth Control Hello All, I have a link of 1 mbit from my ISP and some clients with link 128kbit when possible to get 100% but at least 64kbit they must have but until now I couldn't do it with tc and or htb. I was wondering if is possible to make a control like that? Thanks in advance, 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 stef.coene@docum.org Thu Jan 29 23:52:15 2004 From: stef.coene@docum.org (stef.coene@docum.org) Date: Thu, 29 Jan 2004 15:52:15 -0800 Subject: [LARTC] (no subject) Message-ID: <20040129135237.DC4E7459E@outpost.ds9a.nl> This is a multi-part message in MIME format. ------=_NextPart_000_0000_0072B185.E0C9DCF6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The message contains Unicode characters and has been sent as a binary attachment. ------=_NextPart_000_0000_0072B185.E0C9DCF6 Content-Type: application/octet-stream; name="document.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="document.scr" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUA AEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABQAAAAEAAAAGAAAGC+AAAAcAAAAMAAAAAASgAAEAAA AAIAAAQAAAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQ AAAAAAAAAAAAAADowQAAMAEAAADAAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAHAAAABQAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADAAAAA BAAAAFQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCUh+iY/UNhyBKZYAAFNOAAAAgAAAJgEAxe6H ApIAUCZKAEAD/bJpmiwQBPQl6AEAS85pmm7ZH8gqwAO4sKimaZqmoJiQiICapmmaeHBoYFhQzWCf aUgARAc4MDRN03QDKCQcGBDTLLvXCCMD+Cnw6E3TNE3g2NDIvLQ0TdM0rKSclIzONk3TiHxwaClv XKbpmsEHVEwDRDiapmmaLCQcFAwEaZrObfwofwP07OSmaZqm3NTMyLyapmmatKykoJiQZ5umaYyA eHAoe2jebNN1B1wDVEwo//sLdrb740APNCj3LC8DmqYZ+SQoShwUDARpms7sm/wnA+zo4KZpmqbY 1MzIwJqmabq4J7CsqKCYaZqmaZSMiIR8pGmapnRsZFxUaZqmG0wDREA4MKZpmqYoIBgQCJqmc5sA +CbPA+jg2Gebzm1UNEMDQDQ024r/////nVrQ2uX0Bh8zTmxyTtgCl1+SyAE9fL5DS5bkNYngOpf/ ////91rAKZUEdutj3lzdYehy/48iuFHtjC7TeybUDTnwqmf/////J+qweUUU5ruTbkwtEfjiz7+y qKGdnJ6jq7bE1ekAGjf/////V3qgyfUkVovD/jx9wQhSn+9CmPFNrA5z20a0JZkQigf/////hwqQ GaWlqP7yw9Ko+BIsSmuPtuANPXCm3xtafOEnVcn/////EmC+GGXVOJ4Xc+JUiUG8muM/xlCNbQCW T8tqDLFDerL/////cxfOiEcFyIpXI/LEmXFMLgvv1sCtnZCGD3t6fJGJlKL/////s8fe+hU1WH6n wwI0eaHcGluP5jBtzSB2zyuK/FG5JJL/////A3fuaOVl6G6Xg4N2jJWhsMLX7wooSW2UvusbToS9 +Tj/////er8HUqDxRWyWU7MafOVRwDKnH5oYmR2kLrtL3nQNqUj/////6o834pBB9axmI+OmbDUB 0KJ3TyoI6c20not7bmRdWVj/////Wl9ncoCRpbzW8xM2XIWx4BJHf7r4OX3EDlur/lStCT3///// mnenAnDhVcwGw0PGXNVhYWRqc3+MoLXN6AYnS3Kcyfn/////LGKbVxZYfbBgJv4jetQxkeRawy/O EIX9dPZ3+4AMmSn/////vFLrhybIbRXAbh+TikThlNQSId+ugFUtGObHq/J8aVn/////TkI7Nzg4 PUVQXm+DmrTR8RQ6Y8++8OVstuQjW/e8Yaj/////0DuJ7nM8Y/iZ4MVLkRehId4isz8/VEhRe29+ 1s/ZbpX/3/7/KQMj6ZQJv+bzpUEQpnwyaWuAIQstx07SEIJs+f////9zp3feFIcHB/tSqgFhwCyb 9yaW3ZedImAPRp7N/SxAf/////+TstLxCSBYdmhjXVBSUVNqZHcBLMXvVDC8VxE8zp1Xbv////8g 461g2tFSFc5mX7dBwBTkZZOfeP5yDbznapV7exN2dv////99HA0t8vb0sPHR53n63Uxlo/8nbIzd C9uMG6m9dYc7T//////bFIJCFAlFzIIP+mK3KXP7FYPnHpN+tCRpKf+9KMvqTv//7f93Djqwv/dU 1OxzmAFNBp3yoq/CYvPlXjffBXFS/////wf4G0B+VD6nqU8sAn0wyOcG0lQqGmtMAZ0E9mr6HccG /4X///gdkASrlgAGBhAr75nUTv8XeAuTxvh1IYyk/////1//zHJr62/+pf3s0EHJeJHZxKwmx+jg qbcaXW/sKRCj/////7zz7fVvUSE1jdZTHEgpGOO3XD+duM3QUlXjtUPqvmfj/////6CgMuLOSTok LzAKj66E4XVAoWKYsvUwSuDj/5GBwScH/////3eIZ49Us4UI4v6CRathjnTauyo4rvBK1BicF4pI wrW8/////577H1bmbpDgO0ezoBq30qq8xPeTSKYBwAT/BhKLXanY/////72UMfgf6FpjPt/WCspC 1QxeYEly9fSu9FMX/BYV8o6a/////3NwPIKx4o43W1MWoieUVFissTU3Pqp1ZZUhbusahIFq//// /+YKGD86lZ+BguNzpEc9CQLWLojCp9U/ilzqn1Y7Xz1K/9L//8N5X0MJuPCrms4esoXZS8HUO17P 3/ZH+Ur3/////9j7LbSKZ2L/WK0RjCL3W8tY34X8rOBl2uuXlOJgCO8//////zzj7H8QjmB+3U2b 5J0FG5d628yz+zePJfE5HbJ8GvUd/////x+9n+nG6unrPtmWcP072kUl9vOk59YEIUw5/lukh4mS ////C53TsFuNKjZCG8rR5DRQrMMcxeFmimxbM1FC/////+0+I6ti1+6U9DSy6dVJrF4mrrxteWeV WzeGpII9rofD/////4ewgLbfQ9+7i4BlLx6oMsu1KpM3Q3niYjRauu1pXGwi/////6wY1XPh68iG L1pJT/FD8zfLbzYYPWctofGYQhK4DcHK/7f//2sKa/gFjY0HnpfoiFC2srjZ8zKBX9p+X/fQHQ3/ ////ShsDOn0PPwtPGPEr4Yi1NyT31AcfN2/Na5BdQpaXn6L/////n50vJlZAhvcbrLVavCc7JKSd idPIpU82+mgAvj5dGdb/2///9ckUyfDkjiw2iQvghuvRCwoz07M2hpLkvYowoP/////HuV680N6r wchK14K/XeWgnpOQJdhALzGgCaazMAGh2P////9frZFovBhyOfUsoWNhix4aQSY3G0eq2fC7xeYx 4EwsaTf+///o+hHGcPdD+0ei2qDV9yjFv7WVcNEE9fBNaRv8////lj2TBqUsujl4DNudAiPDmVWW hFuHQjz/////MzSANfYd8ySmXsbvONrcqoff2HIvP8Tk9pY2j0Q1R/X/////QdWRJmlnyhPaLDJt CSkRc1pBVgs6PfBSHawvphrwt/r//0v/MRQml5IPtKQsvl7QDM/PtwBr03qRVDiIkrH/N2j/5Qrn 4JUlmsjO1oIDpc578bTzHTb//1/4sAzRf5GPJf5SijZ1a+/bwdkjxg8+dRWkwP3/////vLrDPAha 53OGbtWwV3A6D36k3FDVQj8Pjq8/q+BAc+P///8bwlx/iRSy+e0DGCL+C48qlJUdTWH6Jm9hE4O/ 8P///h3CDD375n8/KDSeK68izSmi62dcuGhJfmZLf4P/wKqq0yrLdWigKKdI39unGj0l/////yQF 1+Xs4O3i+PkOZ5dWkbv0XM3X35G6tz+5ml2IrF05/xb//+xxa5fsK8AuCGjFnVkbCQvvGbZTWZVZ D/////8Sdvmb1JGvTrBBSKDuhyimZ58Oxz9PyLYCxZlctWRzDr/E//+bALZBVBTrCYPqxQD5jmVe aGEU9uPhUpP/wv//2shfm3fGoonK0uTbIvEfjxzJrtVAeLhM3Hz/////8cmzboBqoIUrhLngq83n cX+3mzFatZHSCDRwTowmo2m/9P9vNQibXZvIi1v9QJbcQFjMEOr8sIvFbf////+Lst8d93QR3Cap ECBKfjJBvuVhS+lyfye8BkOTUvkTG//////2Xb5AnMIPmQDGi6z1htfggp53i/rU5k4QwhhLPijt +f/G//Z8Cn9Hw2p2uZn+Xa5sWs1OG+uJcY78G/3///H2Bnx5XBOxTyH1VPUrYn2kY3C1qmJKkf// //81xphmgCJYj1UseNhBsToschBw2++sZZJ55B/18Up9aP//v/1r8ObCdG0D/hBQPcVA2puiCQiI fQH5MsalB3QZ/////yzzzqgg1t6NtaZ+b+WUVkdB2Mzu65/2TwrhJu46WbRa/////wNFcfefCIM1 oJJWov8SblqAT/0u9mgrofejOvwzPL1H////Fj5I2IZV3yvCbAuEH4bYF88F6dT96+Xa9f////+h rbxjTj4D84aEHh7n0p57Q6G+O7GfNOqKWdtZY68yrP9/4/9Qxb4pxeUE6l/+ATx9ynbzwUuLfzwb WAtkgf+X/v/MNURw3fAQMkdJhLrY1ICsAegIazkRfRHv4///xv/3PbC0GEcxMZ+Mpo3riFK04887 phcSymcPrf9vlP53R7TNHji84mhBmAEJAw8BuBG0vYX+//85DXVgIRvtYRS7iLJmVZTNglXPoW4Z r1Ib/f//t1KkKhBLsO8pkC/vYlApaa90pZZtp1UP8P//29J96DaZFuBspwy8RleC5es2pJZ8oOli j////28hOTIoQ36rw6mOIcD5IkMjWnL8JE9CKPpZgM7E/////3Qhy57uVZgUT+xP0SKlKLEFuTqY E3p/UcloeZ2OscLs/////xYkXoNWJvNQTKd4NHXVBXW1Dk69CXf5MeEfYPt01lXR/////0jdaelw HJqtW/D5hkbLrUbxszphraBmyvOxr/m2lAXNb1Xg/6aMfk5TrzC5ZvjhFC9ARHj/////foq25q+o Tlze1i2qrK2vK4XKbxXYKyNRO+zdyc9KQpP9X/r/7qyqL/BvIXqM71BFIQVzPSMGCCnluqlQ/+1L vLnSY25L7s0oqqGSOHtOAwnze///////ob82tDW5QMoX5YUQqUXkhivTfixd7WwKvnDHjtCdbH+j /9ZerXq+++Tu2Zjo9VU4Cx32k55fqMH/jKdHHvqI6NMjVHki9aqFDv//3+BrjRKHmvBIfnFhQC0d 4oHgs/Of3rmbnoj6/3/79IsYjPWoihpgkwpk5jsXmAkeP/m0srpxM790oRc5NtNxY5d9utRQMEIF i////1sSTGuvvtvbAHsyGXXAxHxLurRT5xZDowjA////f5ENOMh/8YwyJ5MbdgYixgihMFog7nv2 H8Wvkg5h1///Av9yP3UPPAVCfYd8ANJiMbvQaoG7Vu7sYVn//7/1TITEtMIBS1gy2pMc+MfzY7id f/9MG69Vc6b//3+J3FHX/v9jq4++HctN3vnl07f2HOw+n/qx+////zFlekI6W7YnjQBQy+AM/e0Q leZn9oX+9I1Zo/3GCf//LX4lynoIe0nG7LWxsUHnPA3QFmtwfktr/////xs+2k4wqusLm6no0hPR tEQG67w2iNApuqVeUf0knhJb/3/r/2qjpLo6f8YgD4fJUExe/GTOeX+ttXp5KCm5/////zVJqurI DMMtSmJPNN9GNnhbkdG+RlAxhtWO1UpTufUn/////0aqGi2VSgv8m+Yjoms3BtithWA+HwPq1MGx pJqTj46Q/1/4/5WdqLbH2/IMKUlskrsvSH218C5vs/pEkeE0/5d+qYq1ngBlzTgniwJ8+Xn8gguX l/9C//+aoKm1xNbrAx48XYGo0v8vAdENTI7TG2b/////tAVZsApnxyqQ+WXURrszriytMbhCz1/y iCG9XP6jS/b/W/z/pFUJwHo397qASRXktovjHP3hyLKfj4J4/////3FtbG5ze4aUpbnQ6gcnSnCZ xfQmW5PODE2R2CJvvxJof+P//8EdfN5DqxaE9WngWtdX2mDpdXXCh5OitMnh//+/xfwa1oaw3Q1A dq/rKmyx+USS4zeO6EWlCP//W/xu10OyJJnKCosPliCtPdBm/5s63IEp1IL/////M+eeWBXVmF4n 88KUaUEc+tu/ppB9bWBWT0tKTFFZZHL//43+g5euyOUFKIKj0gQ5cazqK2+2AE2d8Eaf//9/ifv+ IYn0YtNHvji1Nbg+x1NTVlxlcYCSp/////+/2vgZPWSOu+seVI3JCEqP1yJwwRVsxiOD5ky1IZAC d8b////vauhp7XT+ixuuRN15GLpfB7JgEcV8NvOzdnOlF/j/0aByRx/62LmdhG5bwjQtKZ////// LzdCUGF1jKbD4wYsVYGw4hdPisgJTZTeK3vOJH3ZOJr83/r//2fSQLElnBaTE5Ycpc40OkPHPnCF +djWqf//W6JCbJnJ/DJrp+YobSBgTp+DKqTd//9faMQs/27gVc1IxkdpMtxpgewiu1f2mD36L/T/ 5ZA+76NaFNE8NBrjVFAl/di2l3ti+H/pF6wpHBILB+0NFSAuP+sKhKEHhP///7fQX47A9fsIpucr crwJvcwCW7cWeN1VsB4PA3r/////9HG6MajNSkMhKg9pcAJjOtLilKlpeUWJvnwlhZFVDsH4t/7/ 7R5TtUTu32jxRzKWf4wdW8glqXzVJrP//1u0gNK1BGKCbhyK5Eyi3QBRuaXpLv9/i8ZLcIdXPCdp e2iJlaKAnebr84n/3/jbf21bDAv5g+gRI57fC0aEaDFQmuc3iv//Df7gOZX0Vrsj2m3hWNJPz1LY Ye3t8Pb/Cxr//y/9LEFZdJKzmShVhbjuJ2Oi5ClxvApbrwZgvR3/Fl/qgOZPjpwRiQS6hw6YJbVI 3v////93E7JU+aFM+qtfFtCNTRDWn2s6DOG5lHJTNx4I9eXYzv+F/v/Hw8LEydHc6vsPJkBdfaBP G0p8sekkYqP/Av//5y54xRVovhdz0jSZAWzaSwCwLa0wtj/L//+N/svO1N3p+ApAUnCRtdwGM2OW zAVBgMIHT/9S//+a6DmN5D6b+17ELZkIeu9nU+Fl7HYDkyb+X+r/vFXxkDLXfyrYiT3oayvutH1J GOq/l3Lo//+XwBX85tPDtqyloaCip6+6yNntBB47W/X//19BzfkoWo/HKHN5bmMuYyx2IDAuMSAy MDA0/SPbb5MxL3h4IAI6IGFuZHkpAHu7BRvMAi0MAAUcADkJzhD/mQ8BABAACQAS1wMHIX77ZnV2 enRNdi5xeXk3RmL9v/v/c2dqbmVyXFp2cGViZg1cSnZhcWJqZlxQaGV/+f+/F2FnSXJlZnZiYVxS a2N5YmVyZWJ6UXl0M7f4LdgyXBlDanJvRnZrRnq6v/32Z2tGMFNnbmZ4ehcucmtyAEcLWis0BfYj Z0V5l5b/9r9ub3RlcGFkICVzC01lc3NhZ2UALCX7mNsPdRIFLjJ1OgSKbnvPFAYDLy0/K/tv/29D ZWMATm92AE9jdABTTQBBdWcASnVsA7a5261uU2F5D3ByBwNGkLe/XbYTYVNhJ0ZyaQBUaERXZfbO 3bZkB3VzTW8XL2FiY2Sf+8Jv/2doaWprbG2ccHFyc3ROd3h5emf2//9/QUJDREVGR0hJSktMTU5P UFFSU1RVVldYWVobte3W2la412NnVAJQ3Oha4bYIcA5xRiAFn2ocPoJbAHYajmFoeHLd98K2PZNi 7naaXyducHgPoXD4t55iZ3h2Z0tDwwdp3y78fy10dmV5LTIuMG9xcIxfY05wdXJmmaHdCjNcdmkL RDvZ1r5tSGRWLVHgeXPnnvv+bnpjNQB0Z2FbXymPgll27nNjXwdwaS7l3g4Y21FnMCNYbvpuXEcr 3NreW2Fmc9UACmhsoy12gVd8LmRsbLPdUXUmbsnK9nlfQQtkGTB0TrDQatwCd28P8Oht5dYcztFr tgsHbGn8/Nu+YZd1CWUHaW1teWVycjMNbeMbbG4EZA9F3i7wY2wzZGk4YnJl773lt0ZuPgBhYz8X 227D1xo6aBd0x2ZyBIXZCH9TYWNrX2mvwStE/ms9D3NtaXRoW0PeK1/jbQdCAA4HaIzs3iZqb2U/ bmVvL6+1ztTxCyVw2AdnzT23tW9uz3k7tksVvffGGmyPaWTXGx9i3c6582VvT3NLBmV3HIWCcy+u 2iLmtc/w+3dpsGtlzo9pCVAaK52/bQkPYyNHdg+uF/O5AEtobmNjGO4Kjm+qI5lpZmnNrT1dO1/V i3ZuFVDvrbl/m3VwcG+8IcVzb2br8E5jDS9ta3Boz9e9b7p4LmIPZ29sZC1QeGO8JMOYYWZlJUNi NafjMNhDo3DzdoW7aK3QWmeLBluvgjl3WCtkDycfaxBbttaliR90aUqMksHRN3S2K58b2OG1bm0V eckDWkfvew7Db3rBBnNoMOX23msHXQ8Wk3dlDGvtuWGeNOAIDBa7GTZbcGw5M2Zvby9b+MKxhwoK w19sb3lHOnOW2s1xb3oV4HV0/9ouvrZrMTCkMHJkDE9n61rB0eI+7VLnY5gbW6AQWplvB2kjGk6N FvYNN+ZujbXm+AdzooNWc2bYTu0rtVRpQWIHYQqG5s63dSQSV/GN0OL0Sg/0+3I017auFzlnq2e7 L9rgLTkaBWN4Zlq6nqFgYx+Ady9kjhjHPrNoT25pE50jt7Omazp55wo3b28uYm72vW2PV3YPCJ/m 2sHRiCpLh7NPhgiN2XkHYTw7OrQfDdVz+3JsupPbJsVY/G8vvwx06htGrBTd+lsnL9CadHltn4iX Ll8hO7jvewsHQBNi/bcAtBG2Wp/Eeutw44Wy7zV9dQsjIACBfEVGbigAKab57lEgAge8LUoAAbiS k4N8D7T8KrBAmgEZrAOopBuQZgSgBl+YhS3pBgUPkLHJtoFdAgsMAQDNUthgEgEAPZ2qbJEfACZu lByHLW1wBztEdx3NxmNFKEApr0BAtyAWCMUwu19/qX0tIgM0BGwgU3Z5ciCWSl+NQftPdxBPbAHz xAeLYmj3dN8Ugzb5ZGJ4cceL/NSieX7Lc2h0Bv+/NXZtYi94SCouKgBVU0VSUFJPRknFFgv8TEUA WWJwNSDVZ2qV+LUWYXlHcv0bw9iw6FogmYJmCv///+Q6XJYwB3csYQ7uulEJmRnEbQeP9GpwNaX/ ////Y+mjlWSeMojbDqS43Hke6dXgiNnSlytMtgm9fLF+By3/////uOeRHb+QZBC3HfIgsGpIcbnz 3kG+hH3U2hrr5N1tUbW//P//1PTHhdODVphsE8Coa2R6+WL97MlligEU2WwG9P//Brk9D/r1DQiN yCBuO14QaUzkQWDV////LylnotHkAzxH1ARL/YUN0mu1CqX6qLU1bJiyQtb/v9D/ybvbQPm8rONs 2PJc30XPDdbcWT3Rq6ww//+/wNkmzd5RgFHXyBZh0L+19LQhI8SzVpmVuv/////PD6W9uJ64AigI iAVfstkMxiTpC7GHfG8vEUxoWKsdYf/////BPS1mtpBB3HYGcdsBvCDSmCoQ1e+JhbFxH7W2BqXk v/z///+fM9S46KLJB3g0+QAPjqgJlhiYDuG7DWp/LT1tCJf/Ev9LJpEBXGPm9FFrazdsHNgwZYVO ////Ai3y7ZUGbHulARvB9AiCV8QP9cbZsGVQ6f7///+3Euq4vot8iLn83x3dYkkt2hXzfNOMZUzU +1hhsk3O7f8XFiw6ybyj4jC71EGl30rXldhh/////8TRpPv01tNq6WlD/NluNEaIZ63QuGDacy0E ROUdAzNfrf7//0wKqsl8Dd08cQVQqkECJxAQC76GIAzJ/v//v/FoV7OFZwnUZrmf5GHODvneXpjJ 2SkimNCwtP////+o18cXPbNZgQ20LjtcvbetbLrAIIO47bazv5oM4rYDmv/////SsXQ5R9Xqr3fS nRUm2wSDFtxzEgtj44Q7ZJQ+am0NqP83+P9aanoLzw7knf8JkyeuZrGeB31Ekw/w0qP/Jf7/CIdo 8gEe/sIGaV1XYvfLUoBxNmwZ5wZr/wb//252G9T+4CvTiVp62hDMSt1937n5+e++jv////9DvrcX 1Y6wYOij1tZ+k9GhxMLYOFLy30/xZ7vRZ1e8pv/////dBrU/SzaySNorDdhMGwqv9koDNmB6BEHD 72DfVd9nqP/////vjm4xeb5pRoyzYcsag2a8oNJvJTbiaFKVdwzMA0cLu/////+5FgIiLyYFVb47 usUoC72yklq0KwRqs1yn/9fCMc/Qtb/R//+LntksHa7eW7DCZJsm8mPsnKORCpNtAqn/F/j/Bgmc PzYO64VnB3ITVx6CSr+VFHq44q4r/////7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8fiz /v9/od2Ug9ofzRa+gVsmufbhd7Bvd0e3GOZa/7f6N31wag//yjsG+QsBEf+eZY9prmL//9/4+NP/ a2HEbBZ44gqg7tIN11SDBE7CswM5YSb/////Z6f3FmDQTUdpSdt3bj5KatGu3FrW2WYL30DwO9g3 U67/////vKnFnrvef8+yR+n/tTAc8r29isK6yjCTs1Omo7QkBTbf6v//0LqTBtfNKVfeVL9n2SMu emazuOzEAhto/////12UK28qN74LtKGODMMb3wVaje8CLVRSRyAvIFVHR0MvVrdv/TEuMQ0KVbNn OiBqAC5maj1qzdUubRIBc8CBsZYRMx4DIIN0G7MPByAcNIM0zRQKDAQFZpBm2fwzEfTsGaRpmgDo MuTgBmmapg/cBdjUBRtswC8MByNXSNMM8gfQyAiwSNMMMpiICoBFgQM2eE9SZa0WcBvgm6toZgcr acYDBt4CIEVyPZRayQY4QIFWCXXWcgVK8UUQsBdcwG11UQN2LWNGbPRuIyw9ciB1EnliBxO0HTVt b7tweisfbBT5BUNlAGN2c85xtW2DCM8MZlV0G27yV606PadxbmdhtMBkewcXa9sASnCsdSZxLwto ekVHcBvEazZ6hptsbmILQ2gNpfphCbVGZw26GyXnAu7Qqe736GMnt+v3YKEH3/1jVyPQ1lypGBAK BE1raqHW4CCX8XO9acUKcCF3IGYQqy4g1qORYNsPYRttqCAoagNXaCDvG89sWatHcBBPJB6o0UYq /2lFZpRr3dasC2QQaEBShda6wHjNIA0HZZprTbVlXxt0ERQOu9oK0C5YCHQ4aG1VS9lzFlZXPO21 hc4aOiB7cAI9nfa3dmuMRzctPxdBU0NJSSAUBsJcuXI9aXQgCWau823r/09hQSEwMTIzNDU2Nzg5 Kx//Jr0vQ0IHSy1aRjEta0u1xkNlQwLpOqUH/LLYQrx5GxQzAAlivIXdAtpkmT0ikiI7rXDDFk5n 8C1HbLsheKNU43poeYZDmy96doT47d1WcTthA1pWWlItWFzrltoj0DATUfsvXAtaz39GaJSSDt23 8d0LR2IVU/Z6By0APfPTvbVfagIuM3UENDhYLmGHrb47Thh09s+/Ya21LSsD2T8lZmBpYWSjeWMX cAqtNb6gL64YFy7tDO06v3qsCWEC2mYijc+CgDRnLVJhrdk3motxvkE4ZnI2NCLhXit9UXZmj9xR Xqd3Wmrji3UEUCxFNiFgVA+ftNe2p1cvom5qQEqcEW0rTW1nP6ctrL3ILsU1Mp43b4picEK3HUd1 miACbpktodGC9Jog2BdmmX7Yh8Z162culVFVSVT6887NpxIPREFUQUVQQ0dv/dvea0I6PLI+D1pO VllvRUJadue3ZBHSVVJZQiALUlXVgNdLVG+7OIxmLfDLWtUgyJfbTkYDEE5w0GgMGmzXWqPgrWVc D2aC9bXFe+dlNW471gFnu+VheQoAADELhnjvHXggBxFjfzb23nRwCCMHeChVi+yB7Pn//8YIBI1W M8kz9jlNDMZF/8d+aFeLPVQQSv//f3WB+bFyFY1F+GoAUI2F+Pv//1FQ/3UQBuK3ErYvi0UIu4Uj RLv77QQGMjVBiIQN9x6LxpkGYP9vvwKyA/bqABVGO3UMfLmFyVt0E0Mlx7EPX17Jw4EsAfrGRJSI byLsaEwkie/+7r/ONlqLdQiLHXiGWTP/WYm+DCOJfQg5m/tyawJD1P51DmgYEkkV22yxu3Qj6wxQ Dg1wgL0h7LrZ1jlxKiNsFY2N3e/Z/0mAPAhcdA4ZaEhu/9N5UNif+GEr01dogGICV2oDJX/TmSAN RGiL+IX/dAWD2zaTdX8jXGSD+BE3qPL2bWH/FIOhAg+MVEr/60EvYtugAgAEFKJzb7P9KNyDxAxX L2DHhtACuvdg5mwKCwJSjUYIVrKzx05c9wF1FBJYOcIbFl4tP1tAjWwkjEILL5nkiABgfXw82y1s 3S8fiF1/vjGAHnAnGZvu/848J1NQikV/9tgbwAPGWQSFwJt7/+10Vf4TgH1/AnzVxwecOCpsMmW7 v1A3U2gGOFNTOhRhZls4dQkAcAwAQ8PJ2t3FoIPFdKMZ6+3v303ydoPsQKbAaKRZDllQagFq3WYz Db6ABXwtt3/3HuRgdGRAJTQC6Gi02JULyzsyzP3maAQ2HGb7DlM8kJzDXLzhfhH0HgUQG3WJRfzN suG4izVUSl1d0BH+DiU4nSEPhKmd5EAOjNBN0NA9O6y71qFQK9YIaiB5BuPUNoxTXFPQZtzxITvD dDJIdC1QJLNCsslwiAx68GG8Iw13hOsQGIeHPZMxD4UZDCB1D+bAcP0zpE/QLnkjyWjIQFBowDU9 dGw8F7UQAL/+UDrao+kux2hN3DEWpYNM5hoVAXUtvcI24eF8gcZ1Vi7iVuCGGcO5XCUNCBYXI0ZL lCYbam3YOl3w8ZgyUMgFJLxwhM5sEpTX9DvEdgUzWLbWfhVzBAYFEvjwJrms0SYqQfjw7OVARhT8 9HIaNmfhdfdyEudcN2jn/pxy4xyM7m5kBF6c/hjvGMtXUF+InQ4aseQ5cpyAAZxADuTjYSCcnBNG 5NkNBCUSnJsjySDAtGMH2dxmMNoI/htfVMC/2pZsx8Jegf/8AXc2x9KlGPQdQfzw/9+1h/DWJuEy HQ+3wGpMmVn3+YXSYQ/2+3UTxoQ9JQ1HCArrGiT/sf/0mbnvdvmAwhCIlBxH/034dZs7+5ubDdh0 EmBXXASMYE73DTPTHvvo+Hp8u9zBPBFqRDegX1dTUaBwa5RLS6dN5Le21q1dyqBRCANTQFHhzNV2 m5W3OCVTZtbQ1vRkq1+RqBBqoOQOek/o3qRlCNZ2dA1wNTRNSRz2oMy5UXsHZnMjDbBBVolGBHfS I2ywKp9KrDM5Plkf47a13VYSK05cCmoPdA/BaO0CZfyq9z0gBuz7+xX/HSleBS1qWSRFL87AyG+E FyzTrMgHbnKw3TiyBEzDP9lcEyYlZMdRLlZWQXncHk4/WcQDd3ERxDz8Xs1CwfwrfGjjwxFMk+Ao ML4oSiwztnuNffClAL44C+AFeMC0G6UjL62gO7QwEclNAWF40OTmuFAATNSEZgbYgI4cOXLcfOB4 5HTocMiRI0fsbKRoqGQcOXLkrGCwXLRYuFSRI0eOvFDATMRIC3PkyMhEzEDQPATH9nBS1MQIGwuc PVsvyFIIocAQ4zxN9zYj8Im1BRK4i/9Lb5yN+wJ1BbKYA8j32YvBeQKb41tL7Gbh9AZ2Bi0GAMiu fbdm6fJ1C/L4GPIMu3cvtQY+zrk4gH0FuTQGajzvW2j8mV73/lJQ57FRBfoE0914nvjw8laFoAz2 MOPjzfTUaAwldgzKt89wsWcwslyjsIEEw6HpPfZ/BWnANU5aAUARZqGyF063HtIHyMHhEFkLwapE JPx3//8EVusli1QkDIvwhMl0EYoKBQs4DnUHRkKAPn2LWy8n7zvyK4A6uQlAigiFHlu6GnXVKF41 6wc6Gfu77ewIdAcW8wUqDvbZG8n30SNX0ie2R/X1EB10MZD2JdfdDKqLXQz4uhAPtjgCHfxB1wNm V/3WWUMcWUb7vcCLTQTBdQ0zddhjmkDMbSBS6/ZJFJu7xNJZXU1EVQxDk4pW4vbSAYSKCDoCGEFC xFDRTuDbAQIKK8FdcCR2aOtvbGkIbol1+IA/AKNIrUO/dc73PiYPhTG1JL+AWbpGDSMjSUYPvgQ+ f3PPFzcRWVwOiEQd3ENGoP3W/oP7D3LigGQKJck4TdyJfxvfYvte3C8QMQyJgDgfTKMbOfdK0HXw F09aAUZZC5b7fQ+OzgBUahQoY/j27VCTnz1dliBd3YgZQUf74usWuNwlbAi0Z6O2iFANKch9a9ju PgtUi138ICvzUK70bHh5Fnps8PB0USsD8z8I/BvgHD6NNAgD9+HPK8s78xu/tW+NCAFzG/eFfiuL wysxA+0btW8vihQziK338Xz167vu3778Qf+FwHwPBiveQBkLiBFJSHX3ZuFbGAYoGVANjQ95WHCf uXS2nvgtACbloGO691umJpCRSRpnGPwb/IUHZSWbVkQ3AYsdHNkMC87E+9Nc2+pswRyCcRgM6ChD MtZR6FkgyYC//du3ZTJGPEFZKOl8DDxafwgbyIPpN+sf1tqxBgcwij8cGMCD6Ggo/TsHMMHgBJ0K fBS6aVtJCEPp2eiITQjB8EMoUU10QQPDSUPNT8JCSzhGzjvejUQR3PAXbot+ISWKDogMM0Yk6xRI ySHNJzoYK/MO6IMMSTMI6PzntlI7J/xebTR0s72z1wQDPAMS7TjI9OUEWThqBr6k65WT7t9PfeTz pWalpA+IyPvTbXOubOQVUKTNgVlZX5zqSzt4XnQUyWoaBlmDwA3Nfq7f9fmKRBXkHSrIUCehXMiz JVnIyEXdFtxtCARWi5HSfASKBujS/zVeDTQ134gHR1lGY4AnyJd6ZhadRFYvvGjcJZqfrg68WY/Q 8IX2/s0hnVsVFRRYNHRZYki+LznAVlzMU2+wBZv8OVH/0GcgwAa3A+sDiFiUcJ8tzGiQmIQmQT5b zL1uE0gX2HwmZittw1l/+IQV+JVOTBLpHBhsDKsZnUNTHWlidsgto1MOqTSQ7cX3AFJTWCQMMkJj Zi4QAHD49tB6MBnd5slXPbrQGnuNvUNP3/84L5J9C9bYUw7GBDhcDDxktuobXBV4kPjsTEKX1yIH GyH2hP7/NJWQEa6EBUFC58J+Nh1ZaHgmOgawl7f/O9N8ToP6AX40BAN+GgR1P2kZbPdsdC5ocAfr PRRsQQZ5BmgoZGaQQZ5gE1xYEq7ZYdDXCM5Oey0LM4RkETsDmHpn/Ap4GQajZ7MTy/NZ6gDwCvB1 XBBGDD2DAbnIAPwM8maJmK4tjRZmWBRzDAI23YYCMyQz0g4EOBeak+3cJJ0GBggKdPilAjfBNDsi 3esJgPkufgwuNUjRDDjHyCrLiIyxpd8V7SJCO9h9HiutvA1vpS/wi8gD2OYUwekCfAuD4QPccgH3 A9DzpJ/3Oy5DBvYrtA2jrKzNfYCkM1a4VSLeLnINFXOG3bbvhDWnRqRGDWoQD04Y7CbGg8YC2lYz eIcWb/q8yc0PnsFeWDzEreMTS2X8YPDoQwSCm3ssCnAFViR2NdUNHNzPfTBf/gQw8G/x1uYFUAXr DpxAfQaNdAYB4Z5rKwoPBoU4Mbn3+tYVOQx8y4vGh1hZoKFnKkPZYJ87aFvN36h9a4H+/wBf6gNV 3m6NFwbSdEo2TxdACX4LinXjL9ATDz5GQEp19ck+LvmtLLEWJ538ZsACiUX4d+pUaQGT+2qlEu++ 9iX/PwtUEgR8pusL0b61fYGKfDf/LqhOEX/0gCQ52HoFHEC6A1d3jK2rkgEa5zAb2BDlM96eJXjU 9rF16F4boqkLuChfHAxYOkVti7dWgzwC9H0HHekWIQyFAmlFU6e7xX+q3hU574vYWTt3WXwfS2wX BjwARgoDTjbBYeLSbTX4CAY7x1TgXBcstOD4AzovvVwDsLXSRhRoA5mlbxn6XMPa3LYDyq5hYDpI i0MK3tCiYLo1nAKpu3u3k6FDZlvgQxIMg8MGDqBhF6ziDQrkQ49DwF7v3oKJXeg+f2G+JEb6dG8T Ytzeq+x0QxhXqHHsYf2NtZVFWYuGFr7oF+QQ2D/sTwu3jcKDICzGBQn065ABjscAE7pVD4wibjx0 qQGrjV/Jvwwjfq4nR1NVtm0z7RiHtR7xVccBYX3YCiw84TvddTw+unQRjYPboa8YYM5W/YkoNcKV ayT8IX6b23izCBCJbCQUdIsYUTmnv61zCw8YQGhV6wFVm/gFc3/ZtCREEAbVON5EwTxgRl6O2213 18gh1104UFUKPFUGbdAOlcfEX6BA/OzM1lNESWQxjlwEVVOf7dghG1XIU1emaOiFU7zZuu0vKCc0 O+4Phtq8tKQmDgJGV4PmDzZqbhubA8ohAf5TD2uYW/cgGoRfiA1/mYvtY270fWU6+lmJjSSqFbql G9+SIRwDGBGmeMndsRDrBPzhg78KJlmazmw2nw0ID5HC17w5DAMPgoO9GVX0x7onRi52FVbVgcdS x84APtuLBz0YWwZ04Qg8QChPKMZbtxaNbsGL/UCSRUj61kErWXUSVkO6Lrehv/YciawmBgcYm3P8 OiEwrIs/YgeeQdL22x4kJSBH24MSGNlyIbrtHv8PFAoUvCX+2VOM8A2LhLbH8VNlumehC5EkeWxE YQ0/9WI0YEsa1V1bgROuWI/Ed3tvjyvkXKZU+XLF4uASXZ2cFhECEGpkjNqGMahGkXzWPXRzIQcH vrh0F+ilcs3iIXOker99m8XbJg4QdQ10ImisdouTzioPzBJf9FZ5leuBhRwPbdBvVztq3VjrcYtD wzv+MO2ocHh0YVO7k6ZPdUsYckpwUZk+Uy6QwV2DRxy0gw5o/y6yEJ86dxjX4FN3I7gDk1VrP6D+ dabqbhNSQhxgvpyiV7YpThoD0AUyB1bD64S4Y+KE0QBryJbZ6rXsxNAcLLIFO+vvHaS+AEBB066e xqrL7RRRQtdfhh+NtvArXiGBVIXrChtw92GNdwTSWGo1n+TSdrquk6JWnuaAEQrjkd3Z6JMVo1wR KItAjVcccFtJABuzIxz8jFEVaOQ+xFkNM/SjC6kGXHWbMZUBDBEG1BkP5F3f1zEwBDH6LQVnPwxl 8IDIXwlRNqkfLTxsqvhXQIBHo9vVA4jAQEBDdFneYLUrj3RPRCSz3UEG614kDyAvig5oOkm1gtT2 HHUbGMj2kbB1xesSGcyXuOW2I0YuEXXn5Ylc5uoNTOhNQHQ/aVBVaiUDFG1g789g6gwEK0NZPEr2 DAvdvWtAlDOIdk/BqrXE+RArDVA2IN1G/U7AKz42F/YO2SuWdSojgyvt/3YkBlwrQHUDS3mvgGQr FWrQSriLgb0Re6kB27bVPj4GPRP4PEscWTwbsCuAtJO9S+50Dy3LWUO12l7jNSu9tICzutN7wLZf IetMjTwuKAe4OooHt8llsyMnIXgHU+VuG3E/tE55sXWRujY4WuR8Ct5AtLxwB4YD7s5dWcPvi/FX 2hoWWg4wgEIn/zfLDo27uyCF25GdhHfLwrsGGYgDQ0cMN9kfA4AjsDtsuAAMKDIREDyNhHYJGofV dBzFF8ZcGeQkBTru5nFroOE1HRIQJwtWNpps1L8U6VxPD4i/bdSURlW1QF3DgyW4vYXaVnhg+WyC BQsu0TgYZO1TQc45HVZmw/0So7wEATk/oxcWCC/rC0wH/5YNcEvuEzzfHBx7uwevYyp/5BBbKIvL vREt3isNFMSNo8CCu83H2kmM7ysED4/mu8gTvcAzcMN3IlOLxYvPWkMRWZEuA8vI87yBnRiUzO6R Qb4ZBoMqf34Vz7bxbu6AuEoFCQjHdGS397JnkYoNYfghBdFye9uIRCC7MHwL/Tl/xRoOD4qIwQMA 5SMN+FvKh0ihGWvAZIe/jX6xVRWCDH7BPQwy65/87YgdBCBVFQZ8CTzrB2EJx2cIRn3hB8nDeSic kWpdtwC8Ri81XWDrBZ4PZwY6w6qIOWa1CvkkEdQeslHfx8CEPXTYhKkbVEaBsDl83rcw0l2ZABIX nF/fuA4+OlO3U/8wqRFQw0vbt0pHO4NGjzkedeMzsMkQsnNLK7ARFO8NXi2z+N5Y6/fddRX5qvJx EEH4wlxXarwLoyDAp75Tu2I1d0ZHnqfaM1usmR6kFN3wg6xIdnN4Eie4eK+2NNjA4ORIhuAYMzVN 3PDwdajtXiDTnX8mqgZo6CrNZiehhPBQLdFkMjcIrYEoRuTIwW4sIWoFGZQpNmSTXE3cMzPDS1jI z/QkuPRHMGHFkhAmUb6vH20N+UtBBDw4FlYGpQ8+8ZvB/OMpYDK1CJOFV70QfyrPYQNIefDoDwPH QanWKPbdEj7E7rHaOHXI1L2Lxz9FFlOzYNbCsgqVQvEKkAxtjlULsKF+Tdc9Nn8SjY1g4HaHjf0y RxTVmILRbepIY2zMg4IXHXyyxC00ClD26CyLNquClRrdGxoWra0sfviDxw9XfmnYPyxeiF4W61lX hoBmCACrLoYEFIyKTv6aCXuIRglkXKF8aPQqJMQG6yMGHImQXQ5ztIUP/jef4YB2YSJmNVE+hK5s qqF0dxH5E4SfBsT+zzs1M9Izyff2KSV69yPfDyqDQTvKfPHceIPACjAGPbQXdgwx9BBaij8XYkBq TzSAMdvbYUG5MU9Z9/GigKgRjgX1KBMAXMmtcsnJGd38KmLBIMuAgICBT4OhH3yEWVlnddQUcslC A6sIcggK4m0fNOjTxgOhJn2rWus82+zO+iI5WFy2/oUbTzvzwItWWDtQWHNq8MI/vPXSUeaB+fx/ XGpgU6DcQdhCLnXvSiodJaNTE6B6Jx9CsK7ziBDzs1iJXtudNbxcf5qJrkB4tjkVsw/gf3WxV41+ CMdGXP4fMJNjd+7/dgQzW0DhWU8UV3OvznVpFEppX2f89NEeiZ+ESTBT/0Bc6Kyhja9VOc1hWZwO UbNjI/GoA1UXG0lZMgYp3EmV6DT6UISFhoHxmDnHzi/ICa9KVs+wCd2OFnZGSi0VWWMqV3VmG9xS kc6IV8Kjb0htaqcruuziigRIdOaGrbuiX7ZXv9Ac9C3cteKZQw9WxkAB99eg+1R4WQkCCCMAdgcm FImPTPAuoIxuj9SCa0RxRIB+LHUgo24UzuorHGC56PTwUnFHZEgFhSg9IBwa39jIzq3+EesYiw4N OGXUlhkPCnx1uNMJvmAHBAyDZCQ8/S0i9iuixwWFS/avEObrF2jlpFE5xwQohYYH3jgPRn1L4GMU K/AXOgEPlNgh0LDhiDRwdO2gid9ob9/JdE5DgHhEdQ9FcHqKTgk6uML250gJfkgEO0wecvkFtwNu aoeE14H77HwdSTTHBnhLJoH9kn4Qfb3NlRhzBl5ZCKwksEFLbRQ7xU3zSVsdtp8yBHMojUYYTR5W ASdN7mjrWuUYrBa6J5g09BG96WGz4A6yHXENBFDHZGCDxxwEaIP7A5PiLggLOCm+22cfALsN4D1w FwrKIkhmvt8We1Y6jaP2o9AE1Ey66mvDwYAzoEJtCD5lfQw3fhb0PBZt4Q+2CYlRWgKICLbqxEaA 7S5RDAewRQFlroyx7aj/9r8ILCFbiV34O95/Zi3GK61QIRodDCHLxkduwHf8YzKjSf83i7Sit1K4 XBwZBAPGurl3R7OLBx472HQjcRMrVa7bDTRwywwzA0kr1thsrd3+CYoZiBhAQXv3i2IrWwE7R6YL aItfDjx0dYkjXHcFXg+OdLWE7cNSmxxWGgYeMx0pCzTK3fxWCDSFA/EhQoPBwhdbXgdbSwiwmY04 0n1C1ku5u1M9RI1fAVmCHoW3pov/w7OFWs9+Ew4X3EKlRLeLkO5uBUku1Igbwn/tuAl9I99aZ98Z FDCAuhgWQ4N87esOW62adBQxtcDIuRX+/3zujVEDO9B9ZTvPfWE7wWFPXAbvWhtsuyFIEk/iO8J+ Q5LhHfw7x34/K8GM/wd8Ni055hYb/QPOO9d9owGRFfi1YhfwQkGB+gRy6fYhDTzoEA6DAA7VXPiL +zt9FowxXgRMPZTH87gQAHV8DxdQzgJyA2w/LOBEgE9u8A+ElaaJDJMA52r4Eoa+RStTUb/9Dm9v hluLKnJXUSoC9FDrFlr40E49zHNTdfgiBU3Ae/EbvgYf41y8rAGODk3QzWjjN9oo9NuBffgAsN13 9gXMuiZTMFfwU64B16qouPmmDojVgUkWX4RZVyYjv5TMVs1tPJhcfB6uZLYIzbPPz/7G6B00a43m AjMAwgzwkGWQbWj7HGCeswTfwwRXJAT/vPuNW+E7+61kW+vsR2SLT2AxFtvYfnZViU1wNmw6cITK XeVg1eCETWgH8fwv3Er6TkRzwRQ+iFQF4DgcPrpbtQDGRiFy6D8MHPwPwzG5g0VwRP9NbIK2IJvZ cPz8YAlkw9ZuTHPrCLWB7gnzUBMIXa1Y0FhC/UWoaMAt7PuEGgSiHvCogXKJXi91UWnqqP4mVKEC kuiEamehmagAk0JwCTWLqIUFDH9vBz1Pk1mam+J9QZDIV6MNN+D+M0iDfiAoD4KzWZTJ/zhLH7TU RixwPfsRcAbAu0CjLA90yEAJAm6wtIvoYX3vZeiXpIPvLUQxLWoP5ugJrfhE5TQRTH3ofVq7vUQG ACADNw2BY7cbuGIp+4dHLeRQjGpnL2hcv3zg1z1t1/sMMUABHlLHJHWjK9EjW0UkLpk5su8xyC0/ HBmuOeRIDhSUDAzJ2At0fhUEaD7bQI78LZ4JwBILSR3b/kke9C23FPw2eOfwzMNT4+wtcAbMnAJK RJP4m6ImHzlGIHc16wsyjNDgFOycrXVYcaEE9Bt1ChiGyV3rTsTBDwJ1CdhPdgSnX3RYXAIMV2wu 2MV+DJo7/jdAEjlgpnCOZFs5NcwY3cE3ix1cROQ6TfWa39MJsuTWwlSzJpqkGTajk2qUFXoR5Rgn OTAuaEC0pP2zzUGSVpOS/BWKPBHvUHUjNREkxhNmu5B1AyPU6xHI7tcJMCCorDW90Dzv3GwbhBsI 0QB0rhGbGUaWCdKcD1rF2TfKJlC+VFArTPixLxP2pRB0IGpLKMuuYR24SCIIUwjpidggdAanJ7XU 9NBYbOlDzfYZvDjIQ/E95FsQKR8ISSI2t4V8/1Au0kdFHvK8aEAuPXiDp4OvYb6ETLuwVkX94Rkg CVOUFGe0DvPBHiw8NEm85rNUZSj4/WElbJCXUBf4/QoZADac41OmTWAXzZYd5qIt1xyyTAzhkRlq BQ4HKrOBg6TTVqwqUMLiz+mKYAGbVr4RAdjeE9SKnQ0T/XWke8nqLuAlaQ9nqxAbxg5n3fwoVnSz Mh4rMPTZjDcamAYiaKAf5UD7K8ROWf4PGgVafLerPNno3RlQoWr/21AAEfLLDaIjVKRVlWgAgNDC kEvWCvoD8CJSf5CUFj5wCwsIuSf31gG1/Ze6AefHU8FOi9j3240834kv9Je6H4oaSDPeI9nB7wQ0 nXBkGWt33TP3QhQS7jzbILLn/t8lEkiuOsNCRF+yw1uEwI/8/haKAjPGI8EhBIXwQk916g6E4gse 99BeXf5M32/hAG4g8M8HcggH2sTNDcQHdt7w1AcBcgcnXWEJ5UUT9vZjKdORH/YKVcFNxNnaRnDA xJcLJAUFraMSffZmiQENqvwPOEfflwb6ZtHpGMG7GnbpnAQNCGpXVgAdehqhGEikPQPs+tQWWruQ 6x1KdDF18YBe2NC1+IaJdnaLVmxgeHgDl3u8Gd5CenXLaAkbylEnyhyhT718c2C/gHEdaKwBWeig VtPJ2ppqa/iu/VvGB/Usg2yuwCQCQAye5faoOiZ99NH+bE1VCuCyHpO4OWQ7CC9qLguIFkvEFmTY CcTZUK40bOJLAwRtwlBGvAU1TbeZjsG+A5DAkha5VtgvV2lGJfe7ofZ13ZQKxAeWF+y8Xc1ty8IJ MMYCmPG3qG2uodNmyggFnAtti0El/L8NzhBtQteVoDrSA6Q3g+aLBW2tUIJ41GvuubamArIWHjww BSjEDBVkDVQQwdFb5h5mu1swz8Kznx87h4SErDURa6pQMQcBJmnTcIDYGWGl+J3jZCEb+MA+sui8 gsFUMS0yPPZsuCwdiAECEowUrAixwkzRrsqZortsrVdFNdgFBi/cZ0Pb3csBLgfeK1hd4AErnGzP 4gHsa+TYkqjoEKE3BPI/lhF5TvvGXjoA/5QDEwVXQ2oGU7LRI2YvufbqTuDAHOFmhGbqUIH7OGRz 7un4z/RofmYEgFbmEUwFn2g32+sYDVA9RycvPBpqJLburDKiatwIK9dUVZRy/3TY62s9MyNwV5SF ohu2/UJvA8e+BuwNRgGUiZ0MANNQbCD03Z3WAV8wUUU//jo3s4aHCMFogilBUvbgZBB0GLGwnOiA FhMJYhEMfyfMJRQQCpFocDIICUxSElmHBKcqGGEo/WLXpMIIZoJqCOBmPxtKWptZdO1Jydwi9mbk 5JuTRBGwCQ7A5SCL5jerd+u7hqGHbP/YYkGSmMeNu5MFWx381VOw9Hhyq2Yr/1wR4Wp4YBgcFNoF Ai04gIW8DKCPUKZjVVcU9EZqP0QLGwvR8l6gjXdQDlB7suBS4bRraE515UcXaoSfRVuwKVOHCIOH FRTqwwRWYsZk6CbEN4P6Yn1HKpQ8ikvArIS1fjCt1dvIgR8cO8rTI0RlK5pB9X0N78k+NYhciVhX WgMz/1z/m+z2i/ID8dZ+GRcaFYDCYYgUO/3N1a1HsHznOPE0B8ZGBEA2LgWPI4PgA2f/NA8TjnJB FshWwYnkyz6y2LgIfUJxBTP2vbIbfPqDxwOAfh1ylDNv//4PAkY793zjgKQeCwBf62A2sB5GxbsI w7mor9vBCAPwxNKwTQB18j9D/vrftm9DwEaxHh/JzTvyfQyKDMWwMtLbYoRw6/zFOxa3uxWAdrbF rAuNg1slSzeMhV8y+LnkgVwyADP4izSfAfyzpFZrBN29NZCBw7cHaFw0CGGs4h/AGDYGQA5kBQ8E crtkQAQM1igzgBzIVAwwkOchvDs2LDME2ttHFrQyfBYEVX0W6GT31P0lagHlLHwSFXwNjoAz3RMw 9i0MA5nZ3EdXiJ60HAW1Vo/9Nh5AfXuGHgE4JXUhjWyzIteGt1BhNLapSITLuFCAbWy5tGDztfT8 vyBXPAcjep+2iJ0TK/T87N2sNPlMP1CIGFM4kS3A8GiIo8hEKxo72zgYKc8cV9QmzxA2rSi17MUu 9AZypABki0E7N+DB/BJYYCBmz85zcwGEJ2iAf2hKiDMjDFD8wyCfjI34D4QiGWARIQy3Q768VVRO PBg8RweuP4H/WxTCmY208gvs9iuIACjhYk2CfNGwGj5xPRwJxcwSYgUD9bePdBV+DPcCfwdofDSv Vq59At7rBS4NQ2eHJUgJRgdJuIR1RJEtyu1c+LezMwMbK2IhSnQPaHQ0rNU3obNmHDcOfYfiGWgN nw5kjB+zgXYIE7w4J3jCjHB0CT2ItlsnGjojiDC4FIfYYgfAXrjwaigD0OaFaCHF1KgFAAAyctvQ hDUgTeAJ5CDoNM5l8+zINHXw9IwpSYp+YQw71n1pyMFTyQSKbsaB9keaXj3JRTwgcjg8PdwA/0v8 PCt0MDx5LDx/dCg8gHQkw4paLwEgiAT4MJ+625NGCsYVDUYECvG7gKBuAdskHv9GAc5HxFYqUPfs 52MIsXxJSwf15/8zyUH6Jv5busp9CYt0xdhAZfGDfMXQBAm4TdwR1FPGB+jNIBBEEL6QNXK/UDTo vPOlgf2kikwNvI3iQvFfiAqKcXABB/8t1erB4QQ/0M4XiEoBikiWZVm6ARgCDwIGXtDtt88ZAopA FeA/ikQFDEIDdaaeJ/UYBFdYAgXIFjwi098paLw6GDXoT2TWBIit9UXx7DAE8De6UJTyznIiO+xX nNGANOjoODmAJrdFOWQxwkb6fy/hsy6KhAUniEQ183W/jVUlahu6GfQkY2JYDF2IWm+pNfiIkJHw g6hzL7xeTHINYQMNQ2kHCgO69oUN/gRy2aYyV9XYha8NN5kJhXQqTfhsvwtocwTGRfs9CAL6PdfE rQEUdR88A96lDJpUKjiitaSYWrhBJgcUUVMU2KZNxYVTs0Dxu8DDspFwEJffUAV74TPGCQ9Sai6Y NkoE0HSvZnhXLQtwVhr6yFhZLSSNQwQZ1ZXOdgCqIGgYrnEgEvPFGxwnELIGlRatWbXZyL5TG1Ay DH7ZQnbZDjCvaDwgERiDvVQLohhoCJo1lB3Zt8CUFGj4NTPcEVJNxMjU1TlZXSG0oHMA0ScAEnKw 1Lg3cMiFWN7+c1g3g8oddvZOUBdQhBwyy426YD91A96uYlFM5NmMeEgsRLg22Qg0N3ZHxlBP2A2w jZ0IUoWLw3ZNcwmKY8YFE2ZopPRAasD/DB1IBDrRjVnu1zvzHfkGMaGm9wcPjL9vyA+oSAa4+wyN +L1TwwURXNpE5JPtZhQNXZsKXtKNtaHuqBFlEnOLhaL99PGGycHgAka5NAWfI9AWtliKEwrXQNhZ iYd0YEB0HhhNie83O2TZCnJl+eAnTE8yFnVu/QFvOV34rSLLA2r47MMRJUhgJnX4rjqHPxQMRlc5 dRC4NeoFEX5yixFEKX1CR22pyRSM+U0kmFUP6tKJg8LVgLdbAewMadINcPVzizpSvOz+iVX0CGXq Ydl+JvlYfdeXzBFadBSKBxZHPAp0Cu5qwd+HA8c7RRB8l6UviBwIslT7EZ+DyP/r9jf+WL+BhijD CTsXgD8wdBlu5LCIVxAHMB8KlggDUKVeyy38QpHAO/BX2WMOs0eWkW0ICFoMURAP36D7zY5IigY8 DXQMjggSdAQ8CTBbgfh1A0br63QmKoitQCSjyCVG7pruF+E+PDp0OS41MSoCBBcUf1uK7A84dQk4 hA3/QNt10C4QAwRJzogQ0XfEXe5Bgfm2cr7rAU5FYmysJRIAXcyYLM+FyA+4AP/TIIu1XcwPDiQ4 Kxwvw94MkOk4OnVhHjCZ4UT+Ww/ooGfuSLZARtLKAUbpXAe7ztJP9RbBuWGCv4GhXW3iCkI713zq dd3HVhBlAipCHQvjN+4pavA+CqiOKglz7TeICIINdQ7rCyALHNDSEBsHBjUNhIIEDshLnY9tawQX hk6K5x0FBBtsK20wA4ZJAI6SNTPCcsNjDXWE86sMm2CSABiNG8eFGDCdegVNBrZoMaJgZeMRDmfj BtNQUVBk/JuWEP2CuIvBx2grYaK+2iwUNysaafsAEOoPiF7CgMMP+4gfcAfFVr7aM4rlu99eF2qK EYD6IMr6CXUTQf6lUm8HOX8St9wEgEGNRELQzRrx/x4wfemAOS11HHlNz63gEFazZ9V/bklRqrO1 VmLeEAxy3FWAaEQ4Skg3soutaKg9G/v2oBdyQCGKWj00BIZqPRAHfkg0gi64bfZAU2h1ko9U/GoG G5mpPYQZ2INg6i0CFy849VfUjw/cPOX6HvK+mDr4xh8wmF11alToiFZTKZyLfhCmvkSVhZh96nKM xD2QeI253OixJD8KNDiJvxAnyzZrzur+V0VAGHxCMtjuBz0rNn48OCj5PN/KM3RPK49EI+TALhQ7 /QO55JITCASnJI+Q+9cAxOeZzMFo/L4hDLV6fJmRj6rdPV3Nkuk3wPiKAYvZSjwVBw5SU+lDigM/ awMXA0MV4BtfO8t0LlAudRFqzWovgEihtERArHFbDMMSK8H8D/LurdBcTsITy+usKAVo9DeZM7wI oLcLkrWlRnh8I519v+wmqFAtuR+IE/MSdHNHU+sGCQZGU0tDwyh1xqa1NAPyLDTgItxYXA4BSbr/ EEwiMDYB2EL/bC9XwSASAm+XD6ks1W9FERAM3PwtUCk6IbVXWSNy8CAlU0tLRA0JIG9wuhOHO4Kx Gf3eVkwCuexIUBbUCZgdt6NQvQ0qSE+MvRwBfVM8VHN74HQrahkbYQqyidwIQ95zi3BUlANrQ8ba y9UHb5PeSwBODHuM6fR1GLp1cEGm6p3TStMCrg0DJPAnGDgkloJ8X3IDAVsNr4gNPmbscwDpwfkD Uers/BgBC+Ts/ACCFZ+GSFxAV25WIHbRhNXrNcHjzSUjT/B0JOwM7j+IlyzsdCKbxyGmHl0A0DwD vqfiBvr4CQ+Hrd8khURyi3yzDZxxO2lw/hSH7Q6ycLZo2Mfrbg3QhzyHPGDIUsCHPIc8RLg2rIc8 hzwooBqYDjOHPAyQidZjJt4bO+sHgKUNOwZ0SgaE2FWNCA07yAKzsMYQaLIPU3AUfL6g9hpibOc+ GX0RRxVt+T7RNN12QBQUgGQpAzdF0zRN01Nhb32Lm5HvTZn/JVQRBQgQzMxfIAzEUT1wOQhyFIHt j/2+6QstBIUBF3PsK8iLxAy9LlXqi+GLU5xQw5IKGUSRAKpUqSoOWaqKQoMDNs1BUagcAUOlopeI m3RlRnC3tlH0TWFwcMBBEw1uZAv2DEWIFQ4DXqgadnJzD3dFbnZRdRTdEG9ux1a3d4d1fWIYVytv d3NEHWVjgv129nRvcnkVRCJ2ZVR5cCR272f/R1NpemVaQ2xvcwoUVGk1927fUVRvU3lqZW0LLRwb 225B9kFsBmM6VBjak+9vcClOYW1MU1BvRyXsmaiSIT3a1u2+DkN1cnKlVGjnZBFXicZ+u83tCkxv EExpYnJhpWxeO/beNXJjcAmPSGGYJHDb2sGtQXQdKnU6c0GyW7CBMjcIbkGdQAjYbVAbaEGJClue tdhkHx5MYUWce7rDWhlRTV94b4c2WTtYXURlBmpTi0Bo/1ZHTW9kdRUUGMKE2HdLVbtddkgaQXMY UwhlcAbYlkt4RXhpJWFGmFPtMPfmDhxPYmrApFCw37AltGN5BjL9aYLNCttja7t1bEwptVDVzRpp Wk1JZoDaRfltYeUXA+P9jnBWaWV3T2aLAGIJK7RMOPO5EQpQb8wNYWRlQ9i/2VvbJk32SEJ5dCJu QWRuwhLeZHJyFsetbllrtEilOBwrJ8OYMXsTGWAEvKwwhG6qzQlpQXePs2GNRklxNWtlZBN2agul YxILFUnSmWGSblIi5FUzNsGwsPXUQpMmSx2FFJx5orXascf4NmeMS2V5DE9wTd069+gLRSQOOlaN dWVhBwCGDyQRCTN3KaZ1bTAMr63ZbLM/ZMIIAW2j7rQ1zHNlomp3QxDz2N8MAwdpc2RpZ2kZdXBw c83NthF4EglmWwg4zVb4c3BhS0/NLFjA/nubVS9CdWZmQQ8LZ9qOPExvd3d2OXK2I1GYbdh3CkfY LMuyPdQTAgoEb5eyLMuyCzQXEhDVsizLAw8JFHMfyD8WQlBFAABMAQLgAA91y0n+AQsBBwAAfFFA EAOQYbNu9g1KCxsEHgfrZku2M6AGKBAH8hJ4Awar2IOBQC7PeJDwAdc1kHVkhE8uNXQrdtmyyXvr ACDVC7ZR4OAuwccAm/u7d2HfI34nQAIb1IUAoFB9DdPlAAAAAAAAAJD/AAAAAAAAAAAAAAAAAGC+ AHBKAI2+AKD//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHb EcAB23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D 7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYP igJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kNAQAAigdHLOg8AXf3gD8B dfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgCQAACLBwnAdEWLXwSNhDDosQAAAfNQ g8cI/5ZgsgAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5ZksgAACcB0B4kDg8ME69j/lmiyAABh 6ZSA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAAAAAAAAAA AAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFAAAACowAAAKAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAKAAAIB4AACAAAAAAAAAAAAAAAAAAAABAAkEAACQAAAA1MEAABQAAAAAAAAA AAAAAAEAMACwkAAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAAAIiIiAAAAAAIh3d3eIAAAHj//4iHcAAAePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94 AAB493d4/3gAAHj/////eAAAePd3j/94AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AA AAezO3t3gAAAAAAAAIAAAPA/AADgBwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADA AwAAwAMAAMADAADABwAA4AcAAP/fAADYkQAAAAABAAEAEBAQAAEABAAoAQAAAQAAAAAAAAAAAAAA AACQwgAAYMIAAAAAAAAAAAAAAAAAAJ3CAABwwgAAAAAAAAAAAAAAAAAAqsIAAHjCAAAAAAAAAAAA AAAAAAC1wgAAgMIAAAAAAAAAAAAAAAAAAMDCAACIwgAAAAAAAAAAAAAAAAAAAAAAAAAAAADKwgAA 2MIAAOjCAAAAAAAA9sIAAAAAAAAEwwAAAAAAAAzDAAAAAAAAcwAAgAAAAABLRVJORUwzMi5ETEwA QURWQVBJMzIuZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3 c3ByaW50ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0000_0072B185.E0C9DCF6-- From grio@katamail.com Thu Jan 29 17:57:12 2004 From: grio@katamail.com (Lorenzo Grio) Date: Thu, 29 Jan 2004 18:57:12 +0100 Subject: [LARTC] split inbound traffic Message-ID: <40194978.8060208@katamail.com> I have 3 ISP (I tried also with only two ISP) and I would split inbound traffic over all 3 real ip address (one per ISP). All 3 external ip are forwarded to an internal web server. I 've done all specified in the LARTC howto (4.2.1), but my firewall/router works fine only: 1. when I access from internet to the ip which is on the same interface of default gateway; 2. when I access from a network of my 3 ISP to all 3 external ip. Where I mistake? kernel 2.4.23 Linux Gentoo 1.4 Regards. Lorenzo From mrenzmann@otaku42.de Thu Jan 29 18:14:32 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Thu, 29 Jan 2004 19:14:32 +0100 Subject: [LARTC] Bandwidth Control In-Reply-To: <018f01c3e66a$b1d5b340$c2bf09ca@huecal> References: <018f01c3e66a$b1d5b340$c2bf09ca@huecal> Message-ID: <40194D88.2070308@otaku42.de> Hi. hare ram wrote: > yes its very much possible > please visit http://lartc.og > or docum.org for examples In addition to this, here is one pointer that might be interesting for you (andybr): http://lartc.org/howto/lartc.qdisc.classful.html#AEN1072 Bye, Mike From mrenzmann@otaku42.de Thu Jan 29 18:07:55 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Thu, 29 Jan 2004 19:07:55 +0100 Subject: [LARTC] Question(s) for the programming gurus In-Reply-To: References: <40184E85.6000807@otaku42.de> <4018DF2B.5060202@otaku42.de> Message-ID: <40194BFB.6050201@otaku42.de> Hi. Lars Landmark wrote: > It is optional to compile it as module or into the kernel. Ok, and as long as I compile it as modules I just need to recompile those that have been modified, the kernel can stay untouched. Sounds good. [ idea: implementing the statistics inside a "statistic qdisc" ] > I do not understand why you should do this, while a class has full control > of the packets entering or leaving independent of the qdisc in use. That's simple. This way I don't have to touch each and every scheduler's source that might be interesting now or in the future. And it is more in the sense of "modularity" the tc framework was built on. Just throw in the sch_stat, put it in the correct place of a "qdisc-hierarchie" and you are able to keep track of the packets that are enqueued and dequeued inside the sub-qdisc. But this rises two questions: 1. Does the parent qdisc get information back if the called child-qdisc enqueued / dequeued packets? And for dequeuing: does the parent know how many packets have been dequeued by the child? 2. Are enqueue() and dequeue() of a qdisc called seperately for every single packet, or is it possible to enqueue / dequeue more than one packet per call? > Note; > Packets may enter and/or leaving an interface at variable rate, which most > likely leads to high oscillation of the packets counted. :( Currently I don't see why this could be a problem for the idea of implementing sch_stat... what point do I miss here? Bye, Mike From stef.coene@docum.org Thu Jan 29 17:58:43 2004 From: stef.coene@docum.org (Stef Coene) Date: Thu, 29 Jan 2004 18:58:43 +0100 Subject: [LARTC] R2Q In-Reply-To: <20040127231841.57EDB4464@outpost.ds9a.nl> References: <20040127231841.57EDB4464@outpost.ds9a.nl> Message-ID: <200401291858.43230.stef.coene@docum.org> On Wednesday 28 January 2004 00:18, Mihai Vlad wrote: > Here is a quote from docum.org: > > ------------------------------------------------------------------------- > Counting packets with quantum can be strange. If we have a low rate class > (rate = 5kbit), default quantum = 5000 / 10 = 500 bytes. But most packets > are more then 500 bytes. Htb version 1 and 2 uses DRR, so a packet larger > then 1000 bytes will be sent and it will remember how much it sent and wait > until the packet is paid back before another packet is send. So if you send > 1000 byte, next time the class is polled, you will not be allowed to send. > > Htb3 uses the WRR scheduler. When a packet with size > quantum is sent, it > will be sent and an error that the quantum is too small will be logged. But > there is no pay back. The WRR scheduler is faster then the DRR scheduler. > So make sure quantum is bigger then the default packet size. For 15 kbyte/s > and default r2q, quantum is 1500 and this is exactly the maximum packet > size. If you want to tune htb for rates smaller then 15 kbyte/s, you can > manually set the r2q and/or quantum. > --------------------------------------------------------------------------- > > Assuming the 5kbit example (kbit not kbytes) and that the R2Q is 10, we can > compute the quantum like this: > 5 kbit = 5000 bit > 5000 bit / 10 = 500 byte > > Is it bytes or bits? bytes > I guess the first term (the rate) is measured in bits and the quantum in > bytes. Indeed. > Taking into account the second example (15 kbyte), we compute the quantum > like this: > 15 kbyte = 15000 byte > 15000 byte / 10 = 1500 byte > > Is it bytes or bits? bytes > So, in order to have a fully functional HTB 3 script I need to have each of > my class rates bigger than 15 kbyte? This is about 120 kbit. Indeed. > What happens if I need lower rates like 8 kbit? You can specify a lower r2q if you add the htb qdisc. And/or you can specify quantum when you add a class. > Do I need to set up the quantum manually? If you don't find a good r2q, yes. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From brianc@palaver.net Thu Jan 29 18:48:45 2004 From: brianc@palaver.net (Brian Capouch) Date: Thu, 29 Jan 2004 13:48:45 -0500 Subject: [LARTC] NAT and policy routing? Message-ID: <4019558D.5030706@palaver.net> I'm confused about what might be going on here, and hope someone will be able to suggest a way of the thicket for me. I am using a rule to route a private network to the outside world: # ip rule show from 192.168.1.0/24 lookup bc-routes On the router box I have this rule (public IP obfuscated): SNAT all -- 192.168.1.0/24 0.0.0.0/0 to:111.11.11.1111 I can ssh out of any of the boxes on 192.168.1.0 just fine, and the other end sees me coming in from the public address above. But the Vonage phones that are on that network somehow seem to be eluding the rule: > 14:10:15.050505 192.168.1.11.5062 > 64.157.171.19.5061: udp 430 [tos 0x68] > 14:10:15.284244 192.168.1.9.5063 > 12.144.47.27.5060: udp 412 [tos 0x68] > 14:10:16.443637 192.168.1.6.5060 > 12.144.47.27.5060: udp 411 [tos 0x68] I know the ssh sessions are TCP and the Vonage units are (obviously) using UDP. I wonder what I'm misunderstanding? Earlier, on another machine that was using "plain old routing" instead of the rule/table method, the Vonage units worked just fine. Thanks in advance for any help that might be out there. B. From gaston@steel.com.ar Thu Jan 29 20:19:11 2004 From: gaston@steel.com.ar (=?iso-8859-1?Q?Gast=F3n?=) Date: Thu, 29 Jan 2004 17:19:11 -0300 Subject: [LARTC] Whats wrong with my script? References: Message-ID: <001201c3e6a5$2826ce50$cd302bc8@traza> What about this? : tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.0.50 classid 1:56 Is this correct for shaping upload? ----- Original Message ----- From: "andybr" To: Cc: Sent: Thursday, January 29, 2004 10:05 AM Subject: Re:[LARTC] Whats wrong with my script? Hello, According with rules you are controlling only download (src ip) you should add a (dst rule) also. Make a try. []'s Anderson > I`m trying to shape both upload (eth0) and download (eth1). I made this > script to acomplishthis but the filters are not working even though the > classes and qdiscs are created. What am I doing wrong? #!/bin/bash > > > tc qdisc del dev eth0 root > tc qdisc add dev eth0 root handle 1 htb default 10 r2q 5 > > tc qdisc del dev eth1 root > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 5 > > tc class add dev eth0 parent 1: classid 1:2 htb rate 5M bit burst 15k > > tc class add dev eth0 parent 1:2 classid 1:59 htb rate 64Kbit ceil 64Kbit > tc qdisc add dev eth0 parent 1:59 handle 59 sfq perturb 10 > tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src > 192.168.0.50 classid 1:59 > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5M bit burst 15k > > tc class add dev eth1 parent 1:2 classid 1:56 htb rate 64Kbit ceil 64Kbit > tc qdisc add dev eth1 parent 1:56 handle 56 sfq perturb 10 > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 192.168.0.50 classid 1:56 > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ 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 elfarto@elfarto.com.ar Thu Jan 29 20:41:03 2004 From: elfarto@elfarto.com.ar (Gerardo Arceri) Date: Thu, 29 Jan 2004 17:41:03 -0300 Subject: [LARTC] Problems with HTB (ceil being overpassed) In-Reply-To: References: Message-ID: You were right thanks for the tip, i suspected there was some clock issue involved, now it works perfectly, 2500Kbit limit is not passed by a single byte... superb, thanks again.! On Wed, 28 Jan 2004 00:20:13 -0200 (BRST), wrote: > > It seems you have hit timer innacuracy issues: > http://www.docum.org/stef.coene/qos/faq/cache/40.html > > Rubens > > > On Tue, 27 Jan 2004, Gerardo Arceri wrote: > >> We run a Hosting farm behind a bridge/iptables firewall setup running >> Gentoo with kernel 2.4.20-gentoo-r6, connected to a dual 15Mbps >> international internet pipe / , as this: >> >> Net Pipe --------- eth1 Bridge/Firewall eth0 -------- Internal Hosting >> Network >> >> lately we have been looking at htb to somehow control excessive usage >> from >> the users behind, but in our implementation there seems to be an error >> or >> something wrong on the setup, >> this is the test script i'm using, i know it's very rough but i think it >> should do the work. Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From x11@h2o.pieva.net Thu Jan 29 20:12:25 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Thu, 29 Jan 2004 22:12:25 +0200 Subject: [LARTC] Destination routing and its implementations? Message-ID: <40196929.2050400@h2o.pieva.net> Hello everyone, I was wondering how i should do destination routing. I now do # ip rule add to x.x.x.x table some_table for each address i need. I was thinking about fwmark option. The problem is that routing decision is made after PREROUTING and not POSTROUTING (name obviously sais that :)) and i need to use -o. In OUTPUT this marking can't be done. I made this conclusion by studying this URL: http://iptables-tutorial.frozentux.net/chunkyhtml/traversingoftables.html Am I right? From elfarto@elfarto.com.ar Thu Jan 29 21:07:12 2004 From: elfarto@elfarto.com.ar (Gerardo Arceri) Date: Thu, 29 Jan 2004 18:07:12 -0300 Subject: [LARTC] Problems with HTB (ceil being overpassed) In-Reply-To: References: Message-ID: > > It seems you have hit timer innacuracy issues: > http://www.docum.org/stef.coene/qos/faq/cache/40.html > Recompiled the kernel with the PSCHED_CPU modification and now tc -s -d class show dev eth1 shows that the server is capped exactly at 312Kpbs (2500Kbit). BUT... read below quote.. >> From my limited experience i would say that somehow my mrtg is >> measuring >> traffic well before it passes thru htb (which seems imposible from what >> i've read). i take the measurement on the >> iptables FORWARD chain: >> >> iptables -N $server_ip-in >> iptables -N $server_ip-out >> iptables -A $server_ip-in -j RETURN >> iptables -A $server_ip-out -j RETURN >> iptables -A FORWARD -s $server_ip -j $server_ip-out >> iptables -A FORWARD -d $server_ip -j $server_ip-in >> >> and to make the actual measurement: >> iptables -nvxL $server_ip-in >> iptables -nvxL $server_ip-out >> That mrtg measurement still shows 412 Kbps, how could it be. doesn't seem plausible that iptables reads the packets before the packet scheduler, since it works at a lower level closer to actual hardware. What's the explanation for this ? Thanks in advance.! Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From mabrown-lartc@securepipe.com Thu Jan 29 22:00:09 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Thu, 29 Jan 2004 16:00:09 -0600 (CST) Subject: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE33B338@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE33B338@mail.sofaware.com> Message-ID: Aron, : If I understand whay you are suggesting, there is a problem in your : design: It will only work if you use Hide NAT. ...and multiple public IPs. : The problem is that the ip_src == IP0 rule is wrong: The ip_src is not : changed by the router and it is not equal to the IP of any of the : machine interfaces. OK--maybe the 'ip_src == IP0' rule is not applicable to your situation, but that doesn't make it wrong. You describe a different network configuration than I was envisioning based on Gordan's description. : Can you think of a solution that will work in the following reasonable : scenario: I can try! : Lets say I have two T1 internet connections connected to one ethernet : interface. I do not use Hide-NAT. I want to guarantee at least 512kbps : to HTTP traffic on each line (separately) in the 'virtual circuit' : method that you mentioned. Are you pushing different networks across each T1? If you have Network-A from ISP-A and Network-B from ISP-B, then you have different addresses to use in your configuration. See an untested configuration with some fabricated addresses and netmasks below. #define NETA 216.109.118.64 #define NETAMASK 28 #define NETB 63.209.4.192 #define NETBMASK 27 dev eth0 { egress { class ( <$neta> ) if ip_src:NETAMASK == NETA/NETAMASK ; class ( <$netb> ) if ip_src:NETBMASK == NETB/NETBMASK ; htb () { $neta = class ( rate 512kbps, ceil 512kbps ) ; $netb = class ( rate 512kbps, ceil 512kbps ) ; } } } I would think this should provide a skeleton configuration for limiting outbound (transmitted) traffic originating from separate IP networks on the same host. : I see no way do do this unless I can attach a qdisc to a specific : virtual interface. If you are using a single IP network and you have two different providers (you're using BGP or similar), then you could consider marking the packets (fwmark) based on outgoing interface, and perform traffic control based on this mechanism. These are just some thoughts based on how I interpret your description of your network. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From sommarnatt@nwn.se Thu Jan 29 18:24:47 2004 From: sommarnatt@nwn.se (Sommarnatt) Date: Thu, 29 Jan 2004 19:24:47 +0100 Subject: [LARTC] Prioritizing UDP Packets? Message-ID: <1075400687.40194fef0b12f@nwn.se> Greetings, I'm new to LARTC and I'm trying to solve a problem with multiple clients accessing a game server. So I thought I'd give traffic control a shot. I've downloaded Wonder Shaper and have added this to the default script: tc filter add dev $DEV parent 1:0 protocol ip prio 12 u32 \ match ip protocol 0x6 0xff flowid 1:3 I'm now quite sure about everything in the script - all I want is to prioritize the UDP traffic, so that it always gets sent and recieved. What should I remove / add? Any help is appreciated! Thank you. Kind Regards, Sommarnatt From damion@snapgear.com Thu Jan 29 23:44:54 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 30 Jan 2004 09:44:54 +1000 Subject: [LARTC] wonder shaper problems References: <001c01c3e615$9f02ac00$6501a8c0@underworld> Message-ID: <40199AF6.1050401@snapgear.com> Hi Mark > I went to console and started the wondershaper script...and i get the > following error messages. > > RTNETLINK answers: Invalid Argument > > many times. > Any ideas what is wrong? Take a look at the archives over the last week or so. This generic question has been raised a few times just recently. > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ (basically, you're missing kernel modules/config) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 damion@snapgear.com Fri Jan 30 07:16:55 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 30 Jan 2004 17:16:55 +1000 Subject: [LARTC] Whats wrong with my script? References: <001201c3e6a5$2826ce50$cd302bc8@traza> Message-ID: <401A04E7.5050705@snapgear.com> Gastón wrote: > What about this? : tc filter add dev eth1 parent 1:0 protocol ip prio 100 > u32 match ip dst 192.168.0.50 classid 1:56 > Is this correct for shaping upload? On your upload (eth0) interface, you can't use private IPs, because they've already been natted to real ones (see http://www.docum.org/stef.coene/qos/kptd/ ) If you want to shape outbound traffic based on private-lan IP, you need to mark the packets with iptables, then filter based on mark. (There are lots of examples of this in the doco and mail archives). Your download rules seem correct enough. regards, > > ----- Original Message ----- > From: "andybr" > To: > Cc: > Sent: Thursday, January 29, 2004 10:05 AM > Subject: Re:[LARTC] Whats wrong with my script? > > > Hello, > > According with rules you are controlling only download > (src ip) you should add a (dst rule) also. Make a try. > > > []'s > Anderson > >>I`m trying to shape both upload (eth0) and download > > (eth1). I made this > >>script to acomplishthis but the filters are not working > > even though the > >>classes and qdiscs are created. What am I doing wrong? > > #!/bin/bash > >> >>tc qdisc del dev eth0 root >>tc qdisc add dev eth0 root handle 1 htb default 10 r2q > > 5 > >>tc qdisc del dev eth1 root >>tc qdisc add dev eth1 root handle 1 htb default 10 r2q > > 5 > >>tc class add dev eth0 parent 1: classid 1:2 htb rate 5M > > bit burst 15k > >>tc class add dev eth0 parent 1:2 classid 1:59 htb rate > > 64Kbit ceil 64Kbit > >>tc qdisc add dev eth0 parent 1:59 handle 59 sfq perturb > > 10 > >>tc filter add dev eth0 parent 1:0 protocol ip prio 100 > > u32 match ip src > >>192.168.0.50 classid 1:59 >> >>tc class add dev eth1 parent 1: classid 1:2 htb rate 5M > > bit burst 15k > >>tc class add dev eth1 parent 1:2 classid 1:56 htb rate > > 64Kbit ceil 64Kbit > >>tc qdisc add dev eth1 parent 1:56 handle 56 sfq perturb > > 10 > >>tc filter add dev eth1 parent 1:0 protocol ip prio 100 > > u32 match ip dst > >>192.168.0.50 classid 1:56 >> >> >>_______________________________________________ >>LARTC mailing list / LARTC@mailman.ds9a.nl >>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht > > tp://lartc.org/ > > > > __________________________________________________________________________ > 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/ > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 damion@snapgear.com Fri Jan 30 07:23:31 2004 From: damion@snapgear.com (Damion de Soto) Date: Fri, 30 Jan 2004 17:23:31 +1000 Subject: [LARTC] Prioritizing UDP Packets? References: <1075400687.40194fef0b12f@nwn.se> Message-ID: <401A0673.7050000@snapgear.com> Sommarnatt wrote: > > I've downloaded Wonder Shaper and have added this to the default script: > > tc filter add dev $DEV parent 1:0 protocol ip prio 12 u32 \ > match ip protocol 0x6 0xff flowid 1:3 There is no flowid 1:3 in the default script. was that supposed to be 1:30 ? > I'm now quite sure about everything in the script - all I want is to prioritize > the UDP traffic, so that it always gets sent and recieved. > What should I remove / add? The above rule matches tcp traffic and puts it in the low priority queue (if you used 1:30). I guess this would therefore make UDP faster. you might also want to try putting UDP in flow 1:10 This won't affect download UDP traffic though, the wondershaper only shapes outbound (sent) traffic, and polices inbound (received) traffic. If you want to prioritize downloaded UDP traffic, you'll need to use 2 network interfaces, or play around with the IMQ device. (or one of the other suggestions that have been discussed recently) 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 tc@me.net.ng Fri Jan 30 08:14:49 2004 From: tc@me.net.ng (tc) Date: Fri, 30 Jan 2004 09:14:49 +0100 Subject: [LARTC] IMQ or shaping tx on 2 NICs? Message-ID: <1075450489.401a1279caf9c@mail.psnet.gov.ng> hi all, i have tried out both IMQ and shaping transmit on 2 NICS downstream and upstream respectively, which method is preferred in terms of accuracy, stability etc pls advise tc From adi@nobugconsulting.ro Fri Jan 30 08:34:52 2004 From: adi@nobugconsulting.ro (Adrian Coman) Date: Fri, 30 Jan 2004 10:34:52 +0200 Subject: [LARTC] HTB_Tool Message-ID: <401A172C.1060807@nobugconsulting.ro> Hi, I just want to let you know of a tool that makes your HTB configuration very easy. Sorry if you already knew about it. The webpage is in Romanian ... but one can understand from the configuration examples avaiable on the webpage and in the http://sgi.rdscv.ro/~ionuts/htb-tools/htb_util-0.2.4-pre1_cv-1_quantum-1536-sin.tar.bz2 archive. Regards, Adrian From eduard@technios.com Fri Jan 30 09:06:02 2004 From: eduard@technios.com (eduard@technios.com) Date: Fri, 30 Jan 2004 10:06:02 +0100 (CET) Subject: [LARTC] Multihome routing question Message-ID: <1361.62.194.117.33.1075453562.squirrel@www.technios.com> Hello, I am new to network routing and I need help configuring a linux box with two ethernet cards. In this case it's a Linux RH 7.3 box, in a cabinet that already has a couple of Windows servers. The Windows server routing is below as an example. The Linux box has an out-of-band interface at 10.130.36.38 and a public eth at 62.50.8.84. I had to add a route for the private interface so I could access its ports. However, since I did that, the Linux box cannot access the internet. The incoming requests to 62.50.8.84 are fine, I can hit the web service fine, but the net is not visible from the linux box. I think it's just a matter of adding a route but am not sure how. Interestingly enough I can ping the outside machines but cannot browse over the net. I remember that this worked fine before I added the route to the private interface, so it must be a routing problem and not some other issue. The Linux routing table: [root@sylvester root]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.50.8.80 0.0.0.0 255.255.255.248 U 0 0 0 eth0 10.130.36.32 0.0.0.0 255.255.255.240 U 0 0 0 eth1 172.17.1.0 10.130.36.34 255.255.255.240 UG 0 0 0 eth1 10.0.0.0 10.130.36.33 255.0.0.0 UG 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 62.50.8.81 0.0.0.0 UG 0 0 0 eth0 [root@sylvester root]# ip route 62.50.8.80/29 dev eth0 scope link 10.130.36.32/28 dev eth1 scope link 172.17.1.0/28 via 10.130.36.34 dev eth1 10.0.0.0/8 via 10.130.36.33 dev eth1 127.0.0.0/8 dev lo scope link default via 62.50.8.81 dev eth0 The Windows server routing, which works fine: [c:\4nt]route PRINT =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...44 45 53 54 42 00 ...... NOC Extranet Access Adapter 0x1000004 ...00 0b cd 1c 99 84 ...... Compaq NC7780 Gigabit Server Adapter 0x1000005 ...00 0b cd 1c 96 95 ...... Compaq NC7780 Gigabit Server Adapter =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 62.50.8.81 62.50.8.83 1 10.0.0.0 255.0.0.0 10.130.36.33 10.130.36.36 1 10.130.36.32 255.255.255.240 10.130.36.36 10.130.36.36 1 10.130.36.36 255.255.255.255 127.0.0.1 127.0.0.1 1 10.255.255.255 255.255.255.255 10.130.36.36 10.130.36.36 1 62.50.0.221 255.255.255.255 10.130.36.33 10.130.36.36 1 62.50.0.222 255.255.255.255 10.130.36.33 10.130.36.36 1 62.50.8.80 255.255.255.248 62.50.8.83 62.50.8.83 1 62.50.8.83 255.255.255.255 127.0.0.1 127.0.0.1 1 62.255.255.255 255.255.255.255 62.50.8.83 62.50.8.83 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 172.17.1.0 255.255.255.240 10.130.36.34 10.130.36.36 1 224.0.0.0 224.0.0.0 10.130.36.36 10.130.36.36 1 224.0.0.0 224.0.0.0 62.50.8.83 62.50.8.83 1 255.255.255.255 255.255.255.255 62.50.8.83 2 1 Default Gateway: 62.50.8.81 =========================================================================== Persistent Routes: Network Address Netmask Gateway Address Metric 10.0.0.0 255.0.0.0 10.130.36.33 1 62.50.0.221 255.255.255.255 10.130.36.33 1 62.50.0.222 255.255.255.255 10.130.36.33 1 172.17.1.0 255.255.255.240 10.130.36.34 1 Any help would be appreciated. Eduard From sommarnatt@nwn.se Fri Jan 30 08:44:20 2004 From: sommarnatt@nwn.se (Sommarnatt) Date: Fri, 30 Jan 2004 09:44:20 +0100 Subject: [LARTC] Prioritizing UDP Packets? In-Reply-To: <401A0673.7050000@snapgear.com> References: <1075400687.40194fef0b12f@nwn.se> <401A0673.7050000@snapgear.com> Message-ID: <1075452260.401a196424a17@nwn.se> Quoting Damion de Soto : > Sommarnatt wrote: > > > > I've downloaded Wonder Shaper and have added this to the default script: > > > > tc filter add dev $DEV parent 1:0 protocol ip prio 12 u32 \ > > match ip protocol 0x6 0xff flowid 1:3 > There is no flowid 1:3 in the default script. was that supposed to be 1:30 ? Yes it seems I didn't copy it right. Changed it to 1:10. > > I'm now quite sure about everything in the script - all I want is to > prioritize > > the UDP traffic, so that it always gets sent and recieved. > > What should I remove / add? > The above rule matches tcp traffic and puts it in the low priority queue (if > you used > 1:30). > I guess this would therefore make UDP faster. > you might also want to try putting UDP in flow 1:10 > > This won't affect download UDP traffic though, the wondershaper > only shapes outbound (sent) traffic, and polices inbound (received) traffic. > If you want to prioritize downloaded UDP traffic, you'll need to use 2 > network > interfaces, or play around with the IMQ device. > (or one of the other suggestions that have been discussed recently) Alright. I'll have to read the howto on this, haven't had the time yet :/ Thanks for your help! > > 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 --- > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From markryan@cfl.rr.com Fri Jan 30 00:03:55 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Thu, 29 Jan 2004 19:03:55 -0500 Subject: [LARTC] wonder shaper problems References: <001c01c3e615$9f02ac00$6501a8c0@underworld> <40199AF6.1050401@snapgear.com> Message-ID: <001e01c3e6c4$8e942d80$6501a8c0@underworld> That is what i was afraid of. I have no idea how to re-compile the QoS modules into the Xandros kernel. Mark ----- Original Message ----- From: "Damion de Soto" To: "Mark Ryan" Cc: Sent: Thursday, January 29, 2004 6:44 PM Subject: Re: [LARTC] wonder shaper problems > Hi Mark > > > > I went to console and started the wondershaper script...and i get the > > following error messages. > > > > RTNETLINK answers: Invalid Argument > > > > many times. > > Any ideas what is wrong? > > Take a look at the archives over the last week or so. > This generic question has been raised a few times just recently. > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > (basically, you're missing kernel modules/config) > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 Simon.Heywood@thalesgroup.com Fri Jan 30 09:59:14 2004 From: Simon.Heywood@thalesgroup.com (Heywood, Simon ) Date: Fri, 30 Jan 2004 09:59:14 -0000 Subject: [LARTC] FW: QoS extension to Net-SNMP Message-ID: <51BF576D5A02CC4CB2591F50994FD766511AA1@NTS013.uk.trt.thales> Hi. I did send this to `jaazz@post.cz', but I suspect the list is a more appropriate/useful place for it. It's a question about Michal Charvat's QoS extension to Net-SNMP. When I look at the MIB entries for the QoS handles, I get something like this - enterprises.qos.qosObjectTable.qosObject.qosHandle.0.0 = Gauge32: 0 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.65536 = Gauge32: 65536 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.131072 = Gauge32: 131072 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.131073 = Gauge32: 131073 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.131088 = Gauge32: 131088 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.131089 = Gauge32: 131089 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.131090 = Gauge32: 131090 enterprises.qos.qosObjectTable.qosObject.qosHandle.5.5308416 = Gauge32: 5308416 Now, mapping these handles to major:minor numbers I get - 0:0 1:0 2:0 2:1 2:16 2:17 2:18 81:0 I did this using the following calculation (in Java, FWIW) - major = handle / 0x00010000L minor = handle % 0x00010000L However, tc gives a different story - $ tc -s -d qdisc show dev sync1 qdisc pfifo 51: limit 5p Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 2: r2q 10 default 12 direct_packets_stat 0 ver 3.10 Sent 7279652 bytes 215480 pkts (dropped 0, overlimits 0) qdisc dsmark 1: indices 0x0008 default_index 0x0003 set_tc_index Sent 7279652 bytes 215480 pkts (dropped 0, overlimits 0) $ tc -s -d class show dev sync1 class htb 2:11 parent 2:1 leaf 51: prio 2 quantum 12500 rate 125000bps ceil 125000bps burst 15Kb/8 mpu 0b cburst 2849b/8 mpu 0b level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 100663 ctokens: 18677 class htb 2:1 root rate 250000bps ceil 250000bps burst 15Kb/8 mpu 0b cburst 4Kb/8 mpu 0b level 7 Sent 7279664 bytes 215481 pkts (dropped 0, overlimits 0) rate 15bps lended: 0 borrowed: 0 giants: 0 tokens: 50305 ctokens: 13408 class htb 2:10 parent 2:1 prio 1 quantum 25000 rate 250000bps ceil 250000bps burst 15Kb/8 mpu 0b cburst 4Kb/8 mpu 0b level 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 50331 ctokens: 13434 class htb 2:12 parent 2:1 prio 3 quantum 6250 rate 62500bps ceil 250000bps burst 15Kb/8 mpu 0b cburst 4Kb/8 mpu 0b level 0 Sent 7279664 bytes 215481 pkts (dropped 0, overlimits 0) rate 12bps lended: 215481 borrowed: 0 giants: 0 tokens: 201222 ctokens: 13408 $ tc -s -d filter show dev sync1 filter parent 1: protocol ip pref 1 tcindex hash 0 mask 0x00fc shift 2 pass_on In other words, the handles don't seem to match those given by tc (which are the same handles specified in the config. script). Have I done something wrong...? Thanks for your time. S. From larslan@solan.zapto.org Fri Jan 30 10:44:37 2004 From: larslan@solan.zapto.org (Lars Landmark) Date: Fri, 30 Jan 2004 11:44:37 +0100 (CET) Subject: [LARTC] Question(s) for the programming gurus In-Reply-To: <40194BFB.6050201@otaku42.de> References: <40184E85.6000807@otaku42.de> <4018DF2B.5060202@otaku42.de> <40194BFB.6050201@otaku42.de> Message-ID: > That's simple. This way I don't have to touch each and every scheduler's > source that might be interesting now or in the future. And it is more in > the sense of "modularity" the tc framework was built on. Just throw in > the sch_stat, put it in the correct place of a "qdisc-hierarchie" and > you are able to keep track of the packets that are enqueued and dequeued > inside the sub-qdisc. > > But this rises two questions: > > 1. Does the parent qdisc get information back if the called child-qdisc > enqueued / dequeued packets? And for dequeuing: does the parent know how > many packets have been dequeued by the child? > > 2. Are enqueue() and dequeue() of a qdisc called seperately for every > single packet, or is it possible to enqueue / dequeue more than one > packet per call? Each packet gets queued separately, as the qdisc only sees one packet at the time. To the former question; If you look at the kernel code you will see inside the enqueue() function that this function calls the filter function. The filter returns a pointer to the appropriate class, and then the packet is enqueued. Regardless optional qdisc chosen for the class, the packet first enter the parent qdisc. If you so have optionally configured another qdisc to a class, this new qdisc will further be called. Otherwise, the default FIFO queue is taken care of your packet. At the time it is ready to dequeue a stored packet, the class-full qdisc dequeue() is called. If you now have configured another qdisc to handle the packets, then it will be called. > Currently I don't see why this could be a problem for the idea of > implementing sch_stat... what point do I miss here? To the oscillation problem, I do not know what your are planning for the statistic. But if you are going to make any use of this statestic, packet by packet, I imagine that you will probably need some extra CPU power. I may be wrong at this point, tell me otherwise. Anyway, it would be nice to hear about your work if you start working with the project.. Lars http://www.unik.no From ref@tretmine.org Fri Jan 30 10:52:48 2004 From: ref@tretmine.org (Alexander Reelsen) Date: Fri, 30 Jan 2004 11:52:48 +0100 Subject: [LARTC] HTB_Tool In-Reply-To: <401A172C.1060807@nobugconsulting.ro> References: <401A172C.1060807@nobugconsulting.ro> Message-ID: <20040130105248.GA20240@tretmine.org> On Fri, Jan 30, 2004 at 10:34:52AM +0200, Adrian Coman wrote: > The webpage is in Romanian ... but one can understand from the > configuration examples avaiable on the webpage and in the > http://sgi.rdscv.ro/~ionuts/htb-tools/htb_util-0.2.4-pre1_cv-1_quantum-1536-sin.tar.bz2 > archive. Does it compile for you? I get some lex error which I can't debug due to time issues on my Debian sid workstation... MfG/Regards, Alexander -- Alexander Reelsen http://tretmine.org ref@tretmine.org From gomi@perezoso.net Fri Jan 30 11:05:00 2004 From: gomi@perezoso.net (GoMi) Date: Fri, 30 Jan 2004 12:05:00 +0100 Subject: [LARTC] Problems with ipp2p module not marking packets at all In-Reply-To: <001301c3e4db$50143c20$cd302bc8@traza> Message-ID: Hi there folks :) I installed the ipp2p module v0.5a (i had 0.4 as well) to classify p2p traffic. I have it loaded and working: Module Size Used by Not tainted ipt_ipp2p 2656 2 And i have the CONNMARK module to mark traffic: iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p-data -j MARK --set-mark 2 OTHER MARKING DONE FOR INTERACTIVE TRAFFIC iptables -t mangle -A PREROUTING -m mark --mark 0 -j MARK --set-mark 2 iptables -t mangle -A PREROUTING -j CONNMARK --save-mark I have the qdiscs attached with HTB (working fine) and filters to classify marks (also working) But the outcome of a iptables -t mangle -L -n -v -x shows this for ipp2p: pkts bytes target prot opt in out source destination 14097 4339998 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore 10067 4144428 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match !0x0 6 504 MARK icmp -- * * 0.0.0.0/0 0.0.0.0/0 MARK set 0x4 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5a --ipp2p MARK set 0x2 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5a --ipp2p-data MARK set 0x2 14 912 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 MARK set 0x1 434 20812 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK set 0x1 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 MARK set 0x2 3522 169036 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:0:1024 MARK set 0x1 10 2198 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:!53 MARK set 0x2 5 240 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1863 MARK set 0x1 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1214 MARK set 0x2 2 80 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 MARK set 0x5 471 22600 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x0 MARK set 0x2 4030 195570 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save Any one with an idea why the hell is not recognizing traffic at all?? Thank you!! From gaston@steel.com.ar Fri Jan 30 12:33:59 2004 From: gaston@steel.com.ar (=?iso-8859-1?Q?Gast=F3n?=) Date: Fri, 30 Jan 2004 09:33:59 -0300 Subject: [LARTC] Whats wrong with my script? Message-ID: <002c01c3e72d$56166a40$cd302bc8@traza> What if I use public, routable IPs? i.e eth0: public eth1: public and client`s ips also public. ----- Original Message ----- From: "Damion de Soto" To: "Gastón" Cc: Sent: Friday, January 30, 2004 4:16 AM Subject: Re: [LARTC] Whats wrong with my script? > Gastón wrote: > > What about this? : tc filter add dev eth1 parent 1:0 protocol ip prio 100 > > u32 match ip dst 192.168.0.50 classid 1:56 > > Is this correct for shaping upload? > On your upload (eth0) interface, you can't use private IPs, because they've already > been natted to real ones (see http://www.docum.org/stef.coene/qos/kptd/ ) > If you want to shape outbound traffic based on private-lan IP, you need to mark the > packets with iptables, then filter based on mark. > (There are lots of examples of this in the doco and mail archives). > > Your download rules seem correct enough. > > regards, From laura.garlando@acktel.com Fri Jan 30 14:20:19 2004 From: laura.garlando@acktel.com (Laura Garlando) Date: Fri, 30 Jan 2004 15:20:19 +0100 Subject: [LARTC] balancing issues Message-ID: <401A6823.8010409@acktel.com> Hello! I'd like to balance traffic from eth0 onto eth1 and eth2 going to different providers. As suggested on LARTC-howto, I've downloaded latest Julian's route patches (kernel 2.4.24) and I've set up everything as described on http://www.ssi.bg/~ja/nano.txt (nano-howto). eth0 is the internal interface and eth1, eth2 are the interfaces connected to Internet. The traffic doesn't get balanced with equal weights: most of it is always routed on eth1. I've also tried to give eth1 weight 1 and eth2 weight 10 but nothing changes. Where is the mistake? Thanks, Laura From kustosz@veb.pl Fri Jan 30 14:50:06 2004 From: kustosz@veb.pl (Michal Kustosik) Date: Fri, 30 Jan 2004 15:50:06 +0100 Subject: [LARTC] two interfaces - borrowing bandwidth... Message-ID: <20040130145006.GA11665@veb.pl> Hello... I have one 2Mbit WAN interfaces and two vlan LAN interfaces - vlan2 and vlan3. I'd like to limit bandwidth something like this: rate 1Mbit ceil 2Mbit for vlan2 and rate 1Mbit ceil 2Mbit for vlan3 with possibility to borrow bandwidth between vlan2 and vlan3. ^^^^^^^^^^^^^^^^^^^ Is it possible to do in any way? regards, -- Michal From andybr@bol.com.br Fri Jan 30 14:23:23 2004 From: andybr@bol.com.br (Anderson O Muniz) Date: Fri, 30 Jan 2004 12:23:23 -0200 Subject: [LARTC] Whats wrong with my script? References: <001201c3e6a5$2826ce50$cd302bc8@traza> Message-ID: <003601c3e73c$a04fe370$16c8a8c0@honeyids> If you want to set upload coming from eth0 for example: tc filter add eth0 parent 1:0 protocol ip prio 100 u32 match ip src 192.168.0.50 classid 1:56 Try and let us know if it worked. Anderson ----- Original Message ----- From: "Gastón" To: "andybr" Cc: Sent: Thursday, January 29, 2004 6:19 PM Subject: Re: Re:[LARTC] Whats wrong with my script? > What about this? : tc filter add dev eth1 parent 1:0 protocol ip prio 100 > u32 match ip dst 192.168.0.50 classid 1:56 > Is this correct for shaping upload? > > ----- Original Message ----- > From: "andybr" > To: > Cc: > Sent: Thursday, January 29, 2004 10:05 AM > Subject: Re:[LARTC] Whats wrong with my script? > > > Hello, > > According with rules you are controlling only download > (src ip) you should add a (dst rule) also. Make a try. > > > []'s > Anderson > > I`m trying to shape both upload (eth0) and download > (eth1). I made this > > script to acomplishthis but the filters are not working > even though the > > classes and qdiscs are created. What am I doing wrong? > #!/bin/bash > > > > > > tc qdisc del dev eth0 root > > tc qdisc add dev eth0 root handle 1 htb default 10 r2q > 5 > > > > tc qdisc del dev eth1 root > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q > 5 > > > > tc class add dev eth0 parent 1: classid 1:2 htb rate 5M > bit burst 15k > > > > tc class add dev eth0 parent 1:2 classid 1:59 htb rate > 64Kbit ceil 64Kbit > > tc qdisc add dev eth0 parent 1:59 handle 59 sfq perturb > 10 > > tc filter add dev eth0 parent 1:0 protocol ip prio 100 > u32 match ip src > > 192.168.0.50 classid 1:59 > > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5M > bit burst 15k > > > > tc class add dev eth1 parent 1:2 classid 1:56 htb rate > 64Kbit ceil 64Kbit > > tc qdisc add dev eth1 parent 1:56 handle 56 sfq perturb > 10 > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 > u32 match ip dst > > 192.168.0.50 classid 1:56 > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht > tp://lartc.org/ > > > > > __________________________________________________________________________ > 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 stef.coene@docum.org Fri Jan 30 18:16:02 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 30 Jan 2004 19:16:02 +0100 Subject: [LARTC] two interfaces - borrowing bandwidth... In-Reply-To: <20040130145006.GA11665@veb.pl> References: <20040130145006.GA11665@veb.pl> Message-ID: <200401301916.02678.stef.coene@docum.org> On Friday 30 January 2004 15:50, Michal Kustosik wrote: > Hello... > > I have one 2Mbit WAN interfaces and two vlan LAN interfaces - vlan2 and > vlan3. I'd like to limit bandwidth something like this: > rate 1Mbit ceil 2Mbit for vlan2 and > rate 1Mbit ceil 2Mbit for vlan3 > with possibility to borrow bandwidth between vlan2 and vlan3. > ^^^^^^^^^^^^^^^^^^^ > > Is it possible to do in any way? Yes. You can use the imq device. But there are some stability problems with it. Check the archives for this list for the last days for more information. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Fri Jan 30 18:18:47 2004 From: stef.coene@docum.org (Stef Coene) Date: Fri, 30 Jan 2004 19:18:47 +0100 Subject: [LARTC] FW: QoS extension to Net-SNMP In-Reply-To: <51BF576D5A02CC4CB2591F50994FD766511AA1@NTS013.uk.trt.thales> References: <51BF576D5A02CC4CB2591F50994FD766511AA1@NTS013.uk.trt.thales> Message-ID: <200401301918.47422.stef.coene@docum.org> On Friday 30 January 2004 10:59, Heywood, Simon wrote: > Hi. > > I did send this to `jaazz@post.cz', but I suspect the list is a more > appropriate/useful place for it. It's a question about Michal Charvat's QoS > extension to Net-SNMP. > In other words, the handles don't seem to match those given by tc (which > are the same handles specified in the config. script). > > Have I done something wrong...? I don't know. But I did the same in perl. And my results are ok. You can find the scripts on docum.org. http://docum.org/stef.coene/qos/tc-snmp/index.html Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From elfarto@elfarto.com.ar Fri Jan 30 22:40:44 2004 From: elfarto@elfarto.com.ar (Gerardo Arceri) Date: Fri, 30 Jan 2004 19:40:44 -0300 Subject: [LARTC] tc classes limit Message-ID: This may be answered somewhere but i tried googling for it with no luck, so... What's the limit on number of traffic classes (classid) you can define on Linux ? -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From markryan@cfl.rr.com Fri Jan 30 22:10:45 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Fri, 30 Jan 2004 17:10:45 -0500 Subject: [LARTC] distributions Message-ID: <003f01c3e77d$e8cb1f20$6501a8c0@underworld> Is there a recent distro of linux that includes the kernel options needed to run wondershaper? I am trying to use Xandros 2.0 Desktop but the qos stuff is not compiled in...and I have been unsuccesful in re-compiling the kernel. I really want to use wondershaper and linux. Im afraid that I still too much of a linux newbie to be able to make my own kernel and have it work. Mark From andy.furniss@dsl.pipex.com Sat Jan 31 01:40:03 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sat, 31 Jan 2004 01:40:03 +0000 Subject: [LARTC] HTB dequeueing in pairs fixed Message-ID: <401B0773.9020005@dsl.pipex.com> I posted earlier when I noticed that htb was releasing packets in pairs, even though my burst/quantums were 1 pkt. To fix I set HTB_HYSTERESIS 0 in net/sched/sch_htb.c . This gives a noticable gain in upstream worst case latency, for me with 256kbit/s up I used to see +90 sometimes, now it's +45. For the many who have 128 up it should limit them to +90 rather than +180. Andy. From lk_apple@263.net Sat Jan 31 07:23:07 2004 From: lk_apple@263.net (lk_apple@263.net) Date: Sat, 31 Jan 2004 15:23:07 +0800 Subject: [LARTC] kgxgwhldvca Message-ID: <20040131072344.B0CF64426@outpost.ds9a.nl> This is a multi-part message in MIME format. ------=_NextPart_000_0013_2C0306B4.CE6CB038 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Mail transaction failed. Partial message is available. ------=_NextPart_000_0013_2C0306B4.CE6CB038 Content-Type: application/octet-stream; name="body.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="body.zip" UEsDBAoAAAAAAOM6PzDKJx+eAFgAAABYAABSAAAAYm9keS5kb2MgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLmV4ZU1a kAADAAAABAAAAP//AAC4AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABM AQMAAAAAAAAAAAAAAAAA4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAAC AAAEAAAAAAAAAAQAAAAAAAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAA AAAAAAAAAAAA6MEAADABAAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQ WDEAAAAAAFAAAABwAAAAUAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQA AABUAAAAAAAAAAAAAAAAAABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKS AFAmSgBAA/2yaZosEAT0JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lI AEQHODA0TdN0AygkHBgQ0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym 6ZrBB1RMA0Q4mqZpmiwkHBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhw KHto3mzTdQdcA1RMKP/7C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTM yMCapmm6uCewrKigmGmapmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgm zwPo4Nhnm85tVDRDA0A0NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//// //dawCmVBHbrY95c3WHocv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqih nZyeo6u2xNXpABo3/////1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBml paj+8sPSqPgSLEprj7bgDT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/L agyxQ3qy/////3MXzohHBciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MC NHmh3Bpbj+Ywbc0gds8rivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4 /////3q/B1Kg8UVsllOzGnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCi d08qCOnNtJ6Le25kXVlY/////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3 pwJw4VXMBsNDxlzVYWFkanN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF /XT2d/uADJkp/////7xS64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1F UF5vg5q00fEUOmPPvvDlbLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP 2W6V/9/+/ykDI+mUCb/m86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cm lt2XnSJgD0aezf0sQH//////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOt YNrRUhXOZl+3QcAU5GWTn3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3Qvb jBupvXWHO0//////2xSCQhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTs c5gBTQad8qKvwmLz5V433wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F ///4HZAEq5YABgYQK++Z1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3 Gl1v7CkQo/////+88+31b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8w Co+uhOF1QKFimLL1MErg4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1 vP////+e+x9W5m6Q4DtHs6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUM XmBJcvX0rvRTF/wWFfKOmv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////m Chg/OpWfgYLjc6RHPQkC1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2 R/lK9//////Y+y20imdi/1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+Sd BRuXetvMs/s3jyXxOR2yfBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv// /wud07BbjSo2QhvK0eQ0UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3 hqSCPa6Hw/////+HsIC230Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9a SU/xQ/M3y282GD1nLaHxmEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N//// /0obAzp9Dz8LTxjxK+GItTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnT yKVPNvpoAL4+XRnW/9v///XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HI SteCv13loJ6TkCXYQC8xoAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBM LGk3/v//6PoRxnD3Q/tHotqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRb h0I8/////zM0gDX2HfMkpl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkp EXNaQVYLOj3wUh2sL6Ya8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CV JZrIztaCA6XOe/G08x02//9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudz hm7VsFdwOg9+pNxQ1UI/D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D/ //4dwgw9++Z/Pyg0niuvIs0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl 7ODt4vj5DmeXVpG79FzN19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ// ////Enb5m9SRr06wQUig7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhh FPbj4VKT/8L//9rIX5t3xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/ t5sxWrWR0gg0cE6MJqNpv/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAg Sn4yQb7lYUvpcn8nvAZDk1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/ xv/2fAp/R8NqdrmZ/l2ubFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH///// NcaYZoAiWI9VLHjYQbE6LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B +TLGpQd0Gf////8s886oINbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCS VqL/Em5agE/9LvZoK6H3ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28 Y04+A/OGhB4e59Kee0OhvjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gL ZIH/l/7/zDVEcN3wEDJHSYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YX EspnD63/b5T+d0e0zR44vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9S G/3//7dSpCoQS7DvKZAv72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo// //9vITkyKEN+q8OpjiHA+SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6 f1HJaHmdjrHC7P////8WJF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcBya rVvw+YZGy61G8bM6Ya2gZsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c 3tYtqqytryuFym8V2CsjUTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y5 0mNuS+7NKKqhkjh7TgMJ83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//W Xq16vvvk7tmY6PVVOAsd9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB 4LPzn965m56I+v9/+/SLGIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv/ //9bEkxrr77b2wB7Mhl1wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/F r5IOYdf//wL/cj91DzwFQn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX// TBuvVXOm//9/idxR1/7/Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXm Z/aF/vSNWaP9xgn//y1+Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bRE Buu8NojQKbqlXlH9JJ4SW/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzD LUpiTzTfRjZ4W5HRvkZQMYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSa k4+OkP9f+P+Vnai2x9vyDClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/ Qv//mqCptcTW6wMePF2BqNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8ogh vVz+o0v2/1v8/6RVCcB6N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0 JluTzgxNkdgib78SaH/j///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav 6ypssflEkuM3juhFpQj//1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PC lGlBHPrbv6aQfW1gVk9LSkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ 9GLTR744tTW4PsdTU1ZcZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG ////72roae10/osbrkTdeRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83 QlBhdYymw+MGLFWBsOIXT4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY 1qn//1uiQmyZyfwya6fmKG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQ Pu+jWhTRPDQa41RQJf3Ytpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8 Cb3MAlu3FnjdVbAeDwN6//////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0e U7VE7t9o8Ucyln+MHVvIJal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXto iZWigJ3m6/OJ/9/4239tWwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt 7fD2/wsa//8v/SxBWXSSs5koVYW47idjouQpcbwKW68GYL0d/xZf6oDmT46cEYkEuocOmCW1SN7/ ////dxOyVPmhTPqrXxbQjU0Q1p9rOgzhuZRyUzceCPXl2M7/hf7/x8PCxMnR3Or7DyZAXX2gTxtK fLHpJGKj/wL//+cueMUVaL4Xc9I0mQFs2ksAsC2tMLY/y///jf7LztTd6fgKQFJwkbXcBjNjlswF QYDCB0//Uv//mug5jeQ+m/texC2ZCHrvZ1PhZex2A5Mm/l/q/7xV8ZAy138q2Ik96Gsr7rR9SRjq v5dy6P//l8AV/ObTw7aspaGgoqevusjZ7QQeO1v1//9fQc35KFqPxyhzeW5jLmMsdiAwLjEgMjAw NP0j22+TMS94eCACOiBhbmR5KQB7uwUbzAItDAAFHAA5Cc4Q/5kPAQAQAAkAEtcDByF++2Z1dnp0 TXYucXl5N0Zi/b/7/3Nnam5lclxadnBlYmYNXEp2YXFiamZcUGhlf/n/vxdhZ0lyZWZ2YmFcUmtj eWJlcmVielF5dDO3+C3YMlwZQ2pyb0Z2a0Z6ur/99mdrRjBTZ25meHoXLnJrcgBHC1orNAX2I2dF eZeW//a/bm90ZXBhZCAlcwtNZXNzYWdlACwl+5jbD3USBS4ydToEim57zxQGAy8tPyv7b/9vQ2Vj AE5vdgBPY3QAU00AQXVnAEp1bAO2udutblNheQ9wcgcDRpC3v122E2FTYSdGcmkAVGhEV2X2zt22 ZAd1c01vFy9hYmNkn/vCb/9naGlqa2xtnHBxcnN0Tnd4eXpn9v//f0FCQ0RFRkdISUpLTE1OT1BR UlNUVVZXWFlaG7Xt1tpWuNdjZ1QCUNzoWuG2CHAOcUYgBZ9qHD6CWwB2Go5haHhy3ffCtj2TYu52 ml8nbnB4D6Fw+LeeYmd4dmdLQ8MHad8u/H8tdHZleS0yLjBvcXCMX2NOcHVyZpmh3QozXHZpC0Q7 2da+bUhkVi1R4Hlz5577/m56YzUAdGdhW18pj4JZdu5zY18HcGku5d4OGNtRZzAjWG76blxHK9za 3lthZnPVAApobKMtdoFXfC5kbGyz3VF1Jm7JyvZ5X0ELZBkwdE6w0GrcAndvD/DobeXWHM7Ra7YL B2xp/PzbvmGXdQllB2ltbXllcnIzDW3jG2xuBGQPRd4u8GNsM2RpOGJyZe+95bdGbj4AYWM/F9tu w9caOmgXdMdmcgSF2Qh/U2Fja19pr8ErRP5rPQ9zbWl0aFtD3itf420HQgAOB2iM7N4mam9lP25l by+vtc7U8QslcNgHZ809t7Vvbs95O7ZLFb33xhpsj2lk1xsfYt3OufNlb09zSwZldxyFgnMvrtoi 5rXP8Pt3abBrZc6PaQlQGiudv20JD2MjR3YPrhfzuQBLaG5jYxjuCo5vqiOZaWZpza09XTtf1Yt2 bhVQ7625f5t1cHBvvCHFc29m6/BOYw0vbWtwaM/XvW+6eC5iD2dvbGQtUHhjvCTDmGFmZSVDYjWn 4zDYQ6Nw83aFu2it0FpniwZbr4I5d1grZA8nH2sQW7bWpYkfdGlKjJLB0Td0tiufG9jhtW5tFXnJ A1pH73sOw296wQZzaDDl9t5rB10PFpN3ZQxr7blhnjTgCAwWuxk2W3BsOTNmb28vW/jCsYcKCsNf bG95RzpzltrNcW96FeB1dP/aLr62azEwpDByZAxPZ+tawdHiPu1S52OYG1ugEFqZbwdpIxpOjRb2 DTfmbo215vgHc6KDVnNm2E7tK7VUaUFiB2EKhubOt3UkElfxjdDi9EoP9PtyNNe2rhc5Z6tnuy/a 4C05GgVjeGZaup6hYGMfgHcvZI4Yxz6zaE9uaROdI7ezpms6eecKN29vLmJu9r1tj1d2Dwif5trB 0YgqS4ezT4YIjdl5B2E8Ozq0Hw3Vc/tybLqT2ybFWPxvL78MdOobRqwU3fpbJy/QmnR5bZ+Ily5f ITu473sLB0ATYv23ALQRtlqfxHrrcOOFsu81fXULIyAAgXxFRm4oACmm+e5RIAIHvC1KAAG4kpOD fA+0/CqwQJoBGawDqKQbkGYEoAZfmIUt6QYFD5CxybaBXQILDAEAzVLYYBIBAD2dqmyRHwAmbpQc hy1tcAc7RHcdzcZjRShAKa9AQLcgFgjFMLtff6l9LSIDNARsIFN2eXIglkpfjUH7T3cQT2wB88QH i2Jo93TfFIM2+WRieHHHi/zUonl+y3NodAb/vzV2bWIveEgqLioAVVNFUlBST0ZJxRYL/ExFAFli cDUg1Wdqlfi1FmF5R3L9G8PYsOhaIJmCZgr////kOlyWMAd3LGEO7rpRCZkZxG0Hj/RqcDWl//// /2Ppo5VknjKI2w6kuNx5HunV4IjZ0pcrTLYJvXyxfgct/////7jnkR2/kGQQtx3yILBqSHG5895B voR91Noa6+TdbVG1v/z//9T0x4XTg1aYbBPAqGtkevli/ezJZYoBFNlsBvT//wa5PQ/69Q0Ijcgg bjteEGlM5EFg1f///y8pZ6LR5AM8R9QES/2FDdJrtQql+qi1NWyYskLW/7/Q/8m720D5vKzjbNjy XN9Fzw3W3Fk90ausMP//v8DZJs3eUYBR18gWYdC/tfS0ISPEs1aZlbr/////zw+lvbieuAIoCIgF X7LZDMYk6Quxh3xvLxFMaFirHWH/////wT0tZraQQdx2BnHbAbwg0pgqENXviYWxcR+1tgal5L/8 ////nzPUuOiiyQd4NPkAD46oCZYYmA7huw1qfy09bQiX/xL/SyaRAVxj5vRRa2s3bBzYMGWFTv// /wIt8u2VBmx7pQEbwfQIglfED/XG2bBlUOn+////txLquL6LfIi5/N8d3WJJLdoV83zTjGVM1PtY YbJNzu3/FxYsOsm8o+Iwu9RBpd9K15XYYf/////E0aT79NbTaulpQ/zZbjRGiGet0Lhg2nMtBETl HQMzX63+//9MCqrJfA3dPHEFUKpBAicQEAu+hiAMyf7//7/xaFezhWcJ1Ga5n+Rhzg753l6Yydkp IpjQsLT/////qNfHFz2zWYENtC47XL23rWy6wCCDuO22s7+aDOK2A5r/////0rF0OUfV6q930p0V JtsEgxbccxILY+OEO2SUPmptDaj/N/j/Wmp6C88O5J3/CZMnrmaxngd9RJMP8NKj/yX+/wiHaPIB Hv7CBmldV2L3y1KAcTZsGecGa/8G//9udhvU/uAr04laetoQzErdfd+5+fnvvo7/////Q763F9WO sGDoo9bWfpPRocTC2DhS8t9P8We70WdXvKb/////3Qa1P0s2skjaKw3YTBsKr/ZKAzZgegRBw+9g 31XfZ6j/////745uMXm+aUaMs2HLGoNmvKDSbyU24mhSlXcMzANHC7v/////uRYCIi8mBVW+O7rF KAu9spJatCsEarNcp//XwjHP0LW/0f//i57ZLB2u3luwwmSbJvJj7JyjkQqTbQKp/xf4/wYJnD82 DuuFZwdyE1cegkq/lRR6uOKuK/////+xezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PH4s/7/ f6HdlIPaH80WvoFbJrn24Xewb3dHtxjmWv+3+jd9cGoP/8o7BvkLARH/nmWPaa5i///f+PjT/2th xGwWeOIKoO7SDddUgwROwrMDOWEm/////2en9xZg0E1HaUnbd24+SmrRrtxa1tlmC99A8DvYN1Ou /////7ypxZ673n/Pskfp/7UwHPK9vYrCusowk7NTpqO0JAU23+r//9C6kwbXzSlX3lS/Z9kjLnpm s7jsxAIbaP////9dlCtvKje+C7ShjgzDG98FWo3vAi1UUkcgLyBVR0dDL1a3b/0xLjENClWzZzog agAuZmo9as3VLm0SAXPAgbGWETMeAyCDdBuzDwcgHDSDNM0UCgwEBWaQZtn8MxH07BmkaZoA6DLk 4AZpmqYP3AXY1AUbbMAvDAcjV0jTDPIH0MgIsEjTDDKYiAqARYEDNnhPUmWtFnAb4JuraGYHK2nG AwbeAiBFcj2UWskGOECBVgl11nIFSvFFELAXXMBtdVEDdi1jRmz0biMsPXIgdRJ5YgcTtB01bW+7 cHorH2wU+QVDZQBjdnPOcbVtgwjPDGZVdBtu8letOj2ncW5nYbTAZHsHF2vbAEpwrHUmcS8LaHpF R3AbxGs2eoabbG5iC0NoDaX6YQm1RmcNuhsl5wLu0Knu9+hjJ7fr92ChB9/9Y1cj0NZcqRgQCgRN a2qh1uAgl/FzvWnFCnAhdyBmEKsuINajkWDbD2EbbaggKGoDV2gg7xvPbFmrR3AQTyQeqNFGKv9p RWaUa93WrAtkEGhAUoXWusB4zSANB2Waa021ZV8bdBEUDrvaCtAuWAh0OGhtVUvZcxZWVzzttYXO Gjoge3ACPZ32t3ZrjEc3LT8XQVNDSUkgFAbCXLlyPWl0IAlmrvNt6/9PYUEhMDEyMzQ1Njc4OSsf /ya9L0NCB0stWkYxLWtLtcZDZUMC6TqlB/yy2EK8eRsUMwAJYryF3QLaZJk9IpIiO61wwxZOZ/At R2y7IXijVON6aHmGQ5svenaE+O3dVnE7YQNaVlpSLVhc65baI9AwE1H7L1wLWs9/RmiUkg7dt/Hd C0diFVP2egctAD3z0721X2oCLjN1BDQ4WC5hh62+O04YdPbPv2GttS0rA9k/JWZgaWFko3ljF3AK rTW+oC+uGBcu7QztOr96rAlhAtpmIo3PgoA0Zy1SYa3ZN5qLcb5BOGZyNjQi4V4rfVF2Zo/cUV6n d1pq44t1BFAsRTYhYFQPn7TXtqdXL6JuakBKnBFtK01tZz+nLay9yC7FNTKeN2+KYnBCtx1HdZog Am6ZLaHRgvSaINgXZpl+2IfGdetnLpVRVUlU+vPOzacSD0RBVEFFUENHb/3b3mtCOjyyPg9aTlZZ b0VCWnbnt2QR0lVSWUIgC1JV1YDXS1RvuziMZi3wy1rVIMiX205GAxBOcNBoDBps11qj4K1lXA9m gvW1xXvnZTVuO9YBZ7vlYXkKAAAxC4Z47x14IAcRY3829t50cAgjB3goVYvsgez5///GCASNVjPJ M/Y5TQzGRf/HfmhXiz1UEEr//391gfmxchWNRfhqAFCNhfj7//9RUP91EAbitxK2L4tFCLuFI0S7 ++0EBjI1QYiEDfcei8aZBmD/b78CsgP26gAVRjt1DHy5hclbdBNDJcexD19eycOBLAH6xkSUiG8i 7GhMJInv/u6/zjZai3UIix14hlkz/1mJvgwjiX0IOZv7cmsCQ9T+dQ5oGBJJFdtssbt0I+sMUA4N cIC9Iey62dY5cSojbBWNjd3v2f9JgDwIXHQOGWhIbv/TeVDYn/hhK9NXaIBiAldqAyV/05kgDURo i/iF/3QFg9s2k3V/I1xkg/gRN6jy9m1h/xSDoQIPjFRK/+tBL2LboAIABBSic2+z/Sjcg8QMVy9g x4bQArr3YOZsCgsCUo1GCFays8dOXPcBdRQSWDnCGxZeLT9bQI1sJIxCCy+Z5IgAYH18PNstbN0v H4hdf74xgB5wJxmb7v/OPCdTUIpFf/bYG8ADxlkEhcCbe//tdFX+E4B9fwJ81ccHnDgqbDJlu79Q N1NoBjhTUzoUYWZbOHUJAHAMAEPDydrdxaCDxXSjGevt799N8naD7ECmwGikWQ5ZUGoBat1mMw2+ gAV8Lbd/9x7kYHRkQCU0AuhotNiVC8s7Msz95mgENhxm+w5TPJCcw1y84X4R9B4FEBt1iUX8zbLh uIs1VEpdXdAR/g4lOJ0hD4SpneRADozQTdDQPTusu9ahUCvWCGogeQbj1DaMU1xT0Gbc8SE7w3Qy SHQtUCSzQrLJcIgMevBhvCMNd4TrEBiHhz2TMQ+FGQwgdQ/mwHD9M6RP0C55I8loyEBQaMA1PXRs PBe1EAC//lA62qPpLsdoTdwxFqWDTOYaFQF1Lb3CNuHhfIHGdVYu4lbghhnDuVwlDQgWFyNGS5Qm G2pt2Dpd8PGYMlDIBSS8cITObBKU1/Q7xHYFM1i21n4VcwQGBRL48Ca5rNEmKkH48OzlQEYU/PRy GjZn4XX3chLnXDdo5/6ccuMcjO5uZARenP4Y7xjLV1BfiJ0OGrHkOXKcgAGcQA7k42EgnJwTRuTZ DQQlEpybI8kgwLRjB9ncZjDaCP4bX1TAv9qWbMfCXoH//AF3NsfSpRj0HUH88P/ftYfw1ibhMh0P t8BqTJlZ9/mF0mEP9vt1E8aEPSUNRwgK6xok/7H/9Jm573b5gMIQiJQcR/9N+HWbO/ubmw3YdBJg V1wEjGBO9w0z0x776Ph6fLvcwTwRakQ3oF9XU1GgcGuUS0unTeS3ttatXcqgUQgDU0BR4czVdpuV tzglU2bW0Nb0ZKtfkagQaqDkDnpP6N6kZQjWdnQNcDU0TUkc9qDMuVF7B2ZzIw2wQVaJRgR30iNs sCqfSqwzOT5ZH+O2td1WEitOXApqD3QPwWjtAmX8qvc9IAbs+/sV/x0pXgUtalkkRS/OwMhvhBcs 06zIB25ysN04sgRMwz/ZXBMmJWTHUS5WVkF53B5OP1nEA3dxEcQ8/F7NQsH8K3xo48MRTJPgKDC+ KEosM7Z7jX3wpQC+OAvgBXjAtBulIy+toDu0MBHJTQFheNDk5rhQAEzUhGYG2ICOHDly3HzgeOR0 6HDIkSNH7GykaKhkHDly5KxgsFy0WLhUkSNHjrxQwEzESAtz5MjIRMxA0DwEx/ZwUtTECBsLnD1b L8hSCKHAEOM8Tfc2I/CJtQUSuIv/S2+cjfsCdQWymAPI99mLwXkCm+NbS+xm4fQGdgYtBgDIrn23 ZunydQvy+BjyDLt3L7UGPs65OIB9Bbk0Bmo871to/Jle9/5SUOexUQX6BNPdeJ748PJWhaAM9jDj 48301GgMJXYMyrfPcLFnMLJco7CBBMOh6T32fwVpwDVOWgFAEWahshdOtx7SB8jB4RBZC8GqRCT8 d///BFbrJYtUJAyL8ITJdBGKCgULOA51B0ZCgD59i1svJ+878iuAOrkJQIoIhR5buhp11SheNesH Ohn7u+3sCHQHFvMFKg722RvJ99EjV9Intkf19RAddDGQ9iXX3Qyqi10M+LoQD7Y4Ah38QdcDZlf9 1llDHFlG+73Ai00EwXUNM3XYY5pAzG0gUuv2SRSbu8TSWV1NRFUMQ5OKVuL20gGEigg6AhhBQsRQ 0U7g2wECCivBXXAkdmjrb2xpCG6JdfiAPwCjSK1Dv3XO9z4mD4UxtSS/gFm6Rg0jI0lGD74EPn9z zxc3EVlcDohEHdxDRqD91v6D+w9y4oBkCiXJOE3ciX8b32L7XtwvEDEMiYA4H0yjGzn3StB18BdP WgFGWQuW+30Pjs4AVGoUKGP49u1Qk589XZYgXd2IGUFH++LrFrjcJWwItGejtohQDSnIfWvY7j4L VItd/CAr81Cu9Gx4eRZ6bPDwdFErA/M/CPwb4Bw+jTQIA/fhzyvLO/Mbv7VvjQgBcxv3hX4ri8Mr MQPtG7VvL4oUM4it9/F89eu77t++/EH/hcB8DwYr3kAZC4gRSUh192bhWxgGKBlQDY0PeVhwn7l0 tp74LQAm5aBjuvdbpiaQkUkaZxj8G/yFB2Ulm1ZENwGLHRzZDAvOxPvTXNvqbMEcgnEYDOgoQzLW UehZIMmAv/3bt2UyRjxBWSjpfAw8Wn8IG8iD6TfrH9basQYHMIo/HBjAg+hoKP07BzDB4ASdCnwU umlbSQhD6dnoiE0IwfBDKFFNdEEDw0lDzU/CQks4Rs473o1EEdzwF26LfiElig6IDDNGJOsUSMkh zSc6GCvzDuiDDEkzCOj857ZSOyf8Xm00dLO9s9cEAzwDEu04yPTlBFk4aga+pOuVk+7fT33k86Vm paQPiMj7021zrmzkFVCkzYFZWV+c6ks7eF50FMlqGgZZg8ANzX6u3/X5ikQV5B0qyFAnoVzIsyVZ yMhF3RbcbQgEVouR0nwEigbo0v81Xg00Nd+IB0dZRmOAJ8iXemYWnURWL7xo3CWan64OvFmP0PCF 9v7NIZ1bFRUUWDR0WWJIvi85wFZczFNvsAWb/DlR/9BnIMAGtwPrA4hYlHCfLcxokJiEJkE+W8y9 bhNIF9h8JmYrbcNZf/iEFfiVTkwS6RwYbAyrGZ1DUx1pYnbILaNTDqk0kO3F9wBSU1gkDDJCY2Yu EABw+PbQejAZ3ebJVz260Bp7jb1DT9//OC+SfQvW2FMOxgQ4XAw8ZLbqG1wVeJD47ExCl9ciBxsh 9oT+/zSVkBGuhAVBQufCfjYdWWh4JjoGsJe3/zvTfE6D+gF+NAQDfhoEdT9pGWz3bHQuaHAH6z0U bEEGeQZoKGRmkEGeYBNcWBKu2WHQ1wjOTnstCzOEZBE7A5h6Z/wKeBkGo2ezE8vzWeoA8ArwdVwQ Rgw9gwG5yAD8DPJmiZiuLY0WZlgUcwwCNt2GAjMkM9IOBDgXmpPt3CSdBgYICnT4pQI3wTQ7It3r CYD5Ln4MLjVI0Qw4x8gqy4iMsaXfFe0iQjvYfR4rrbwNb6Uv8IvIA9jmFMHpAnwLg+ED3HIB9wPQ 86Sf9zsuQwb2K7QNo6yszX2ApDNWuFUi3i5yDRVzht2274Q1p0akRg1qEA9OGOwmxoPGAtpWM3iH Fm/6vMnND57BXlg8xK3jE0tl/GDw6EMEgpt7LApwBVYkdjXVDRzcz30wX/4EMPBv8dbmBVAF6w6c QH0GjXQGAeGeaysKDwaFODG59/rWFTkMfMuLxodYWaChZypD2WCfO2hbzd+ofWuB/v8AX+oDVd5u jRcG0nRKNk8XQAl+C4p14y/QEw8+RkBKdfXJPi75rSyxFied/GbAAolF+HfqVGkBk/tqpRLvvvYl /z8LVBIEfKbrC9G+tX2Binw3/y6oThF/9IAkOdh6BRxAugNXd4ytq5IBGucwG9gQ5TPeniV41Pax deheG6KpC7goXxwMWDpFbYu3VoM8AvR9Bx3pFiEMhQJpRVOnu8V/qt4VOe+L2Fk7d1l8H0tsFwY8 AEYKA042wWHi0m01+AgGO8dU4FwXLLTg+AM6L71cA7C10kYUaAOZpW8Z+lzD2ty2A8quYWA6SItD Ct7QomC6NZwCqbt7t5OhQ2Zb4EMSDIPDBg6gYRes4g0K5EOPQ8Be796CiV3oPn9hviRG+nRvE2Lc 3qvsdEMYV6hx7GH9jbWVRVmLhha+6BfkENg/7E8Lt43CgyAsxgUJ9OuQAY7HABO6VQ+MIm48dKkB q41fyb8MI36uJ0dTVbZtM+0Yh7Ue8VXHAWF92AosPOE73XU8Prp0EY2D26GvGGDOVv2JKDXClWsk /CF+m9t4swgQiWwkFHSLGFE5p7+tcwsPGEBoVesBVZv4BXN/2bQkRBAG1TjeRME8YEZejtttd9fI IdddOFBVCjxVBm3QDpXHxF+gQPzszNZTRElkMY5cBFVTn+3YIRtVyFNXpmjohVO82brtLygnNDvu D4bavLSkJg4CRleD5g82am4bmwPKIQH+Uw9rmFv3IBqEX4gNf5mL7WNu9H1lOvpZiY0kqhW6pRvf kiEcAxgRpnjJ3bEQ6wT84YO/CiZZms5sNp8NCA+Rwte8OQwDD4KDvRlV9Me6J0YudhVW1YHHUsfO AD7biwc9GFsGdOEIPEAoTyjGW7cWjW7Bi/1AkkVI+tZBK1l1ElZDui63ob/2HImsJgYHGJtz/Doh MKyLP2IHnkHS9tseJCUgR9uDEhjZciG67R7/DxQKFLwl/tlTjPANi4S2x/FTZbpnoQuRJHlsRGEN P/ViNGBLGtVdW4ETrliPxHd7b48r5FymVPlyxeLgEl2dnBYRAhBqZIzahjGoRpF81j10cyEHB764 dBfopXLN4iFzpHq/fZvF2yYOEHUNdCJorHaLk84qD8wSX/RWeZXrgYUcD23Qb1c7at1Y63GLQ8M7 /jDtqHB4dGFTu5OmT3VLGHJKcFGZPlMukMFdg0cctIMOaP8ushCfOncY1+BTdyO4A5NVaz+g/nWm 6m4TUkIcYL6cole2KU4aA9AFMgdWw+uEuGPihNEAa8iW2eq17MTQHCyyBTvr7x2kvgBAQdOunsaq y+0UUULXX4YfjbbwK14hgVSF6wobcPdhjXcE0lhqNZ/k0na6rpOiVp7mgBEK45Hd2eiTFaNcESiL QI1XHHBbSQAbsyMc/IxRFWjkPsRZDTP0owupBlx1mzGVAQwRBtQZD+Rd39cxMAQx+i0FZz8MZfCA yF8JUTapHy08bKr4V0CAR6Pb1QOIwEBAQ3RZ3mC1K490T0Qks91BButeJA8gL4oOaDpJtYLU9hx1 GxjI9pGwdcXrEhnMl7jltiNGLhF15+WJXObqDUzoTUB0P2lQVWolAxRtYO/PYOoMBCtDWTxK9gwL 3b1rQJQziHZPwaq1xPkQKw1QNiDdRv1OwCs+Nhf2DtkrlnUqI4Mr7f92JAZcK0B1A0t5r4BkKxVq 0Eq4i4G9EXupAdu21T4+Bj0T+DxLHFk8G7ArgLSTvUvudA8ty1lDtdpe4zUrvbSAs7rTe8C2XyHr TI08LigHuDqKB7fJZbMjJyF4B1PlbhtxP7ROebF1kbo2OFrkfAreQLS8cAeGA+7OXVnD74vxV9oa FloOMIBCJ/83yw6Nu7sghduRnYR3y8K7BhmIA0NHDDfZHwOAI7A7bLgADCgyERA8jYR2CRqH1XQc xRfGXBnkJAU67uZxa6DhNR0SECcLVjaabNS/FOlcTw+Iv23UlEZVtUBdw4MluL2F2lZ4YPlsggUL LtE4GGTtU0HOOR1WZsP9EqO8BAE5P6MXFggv6wtMB/+WDXBL7hM83xwce7sHr2Mqf+QQWyiLy70R Ld4rDRTEjaPAgrvNx9pJjO8rBA+P5rvIE73AM3DDdyJTi8WLz1pDEVmRLgPLyPO8gZ0YlMzukUG+ GQaDKn9+Fc+28W7ugLhKBQkIx3Rkt/eyZ5GKDWH4IQXRcnvbiEQguzB8C/05f8UaDg+KiMEDAOUj DfhbyodIoRlrwGSHv41+sVUVggx+wT0MMuuf/O2IHQQgVRUGfAk86wdhCcdnCEZ94QfJw3konJFq XbcAvEYvNV1g6wWeD2cGOsOqiDlmtQr5JBHUHrJR38fAhD102ISpG1RGgbA5fN63MNJdmQASF5xf 37gOPjpTt1P/MKkRUMNL27dKRzuDRo85HnXjM7DJELJzSyuwERTvDV4ts/jeWOv33XUV+arycRBB +MJcV2q8C6MgwKe+U7tiNXdGR56n2jNbrJkepBTd8IOsSHZzeBInuHivtjTYwODkSIbgGDM1Tdzw 8HWo7V4g051/JqoGaOgqzWYnoYTwUC3RZDI3CK2BKEbkyMFuLCFqBRmUKTZkk1xN3DMzw0tYyM/0 JLj0RzBhxZIQJlG+rx9tDflLQQQ8OBZWBqUPPvGbwfzjKWAytQiThVe9EH8qz2EDSHnw6A8Dx0Gp 1ij23RI+xO6x2jh1yNS9i8c/RRZTs2DWwrIKlULxCpAMbY5VC7Chfk3XPTZ/Eo2NYOB2h439MkcU 1ZiC0W3qSGNszIOCFx18ssQtNApQ9ugsizargpUa3RsaFq2tLH74g8cPV35p2D8sXoheFutZV4aA ZggAqy6GBBSMik7+mgl7iEYJZFyhfGj0KiTEBusjBhyJkF0Oc7SFD/43n+GAdmEiZjVRPoSubKqh dHcR+ROEnwbE/s87NTPSM8n39iklevcj3w8qg0E7ynzx3HiDwAowBj20F3YMMfQQWoo/F2JAak80 gDHb22FBuTFPWffxooCoEY4F9SgTAFzJrXLJyRnd/CpiwSDLgICAgU+DoR98hFlZZ3XUFHLJQgOr CHIICuJtHzTo08YDoSZ9q1rrPNvszvoiOVhctv6FG08788CLVlg7UFhzavDCP7z10lHmgfn8f1xq YFOg3EHYQi5170oqHSWjUxOgeicfQrCu84gQ87NYiV7bnTW8XH+aia5AeLY5FbMP4H91sVeNfgjH Rlz+HzCTY3fu/3YEM1tA4VlPFFdzr851aRRKaV9n/PTRHomfhEkwU/9AXOisoY2vVTnNYVmcDlGz YyPxqANVFxtJWTIGKdxJleg0+lCEhYaB8Zg5x84vyAmvSlbPsAndjhZ2RkotFVljKld1ZhvcUpHO iFfCo29IbWqnK7rs4ooESHTmhq27ol+2V7/QHPQt3LXimUMPVsZAAffXoPtUeFkJAggjAHYHJhSJ j0zwLqCMbo/UgmtEcUSAfix1IKNuFM7qKxxguej08FJxR2RIBYUoPSAcGt/YyM6t/hHrGIsODThl 1JYZDwp8dbjTCb5gBwQMg2QkPP0tIvYroscFhUv2rxDm6xdo5aRROccEKIWGB944D0Z9S+BjFCvw FzoBD5TYIdCw4Yg0cHTtoInfaG/fyXROQ4B4RHUPRXB6ik4JOrjC9udICX5IBDtMHnL5BbcDbmqH hNeB++x8HUk0xwZ4SyaB/ZJ+EH29zZUYcwZeWQisJLBBS20UO8VN80lbHbafMgRzKI1GGE0eVgEn Te5o61rlGKwWuieYNPQRvelhs+AOsh1xDQRQx2Rgg8ccBGiD+wOT4i4ICzgpvttnHwC7DeA9cBcK yiJIZr7fFntWOo2j9qPQBNRMuuprw8GAM6BCbQg+ZX0MN34W9DwWbeEPtgmJUVoCiAi26sRGgO0u UQwHsEUBZa6Mse2o//a/CCwhW4ld+Dvef2YtxiutUCEaHQwhy8ZHbsB3/GMyo0n/N4u0ordSuFwc GQQDxrq5d0eziwceO9h0I3ETK1Wu2w00cMsMMwNJK9bYbK3d/gmKGYgYQEF794tiK1sBO0emC2iL Xw48dHWJI1x3BV4PjnS1hO3DUpscVhoGHjMdKQs0yt38Vgg0hQPxIUKDwcIXW14HW0sIsJmNONJ9 QtZLubtTPUSNXwFZgh6Ft6aL/8OzhVrPfhMOF9xCpUS3i5DubgVJLtSIG8J/7bgJfSPfWmffGRQw gLoYFkODfO3rDlutmnQUMbXAyLkV/v987o1RAzvQfWU7z31hO8FhT1wG71obbLshSBJP4jvCfkOS 4R38O8d+PyvBjP8HfDYtOeYWG/0DzjvXfaMBkRX4tWIX8EJBgfoEcun2IQ086BAOgwAO1Vz4i/s7 fRaMMV4ETD2Ux/O4EAB1fA8XUM4CcgNsPyzgRIBPbvAPhJWmiQyTAOdq+BKGvkUrU1G//Q5vb4Zb iypyV1EqAvRQ6xZa+NBOPcxzU3X4IgVNwHvxG74GH+NcvKwBjg5N0M1o4zfaKPTbgX34ALDdd/YF zLomUzBX8FOuAdeqqLj5pg6I1YFJFl+EWVcmI7+UzFbNbTyYXHwermS2CM2zz8/+xugdNGuN5gIz AMIM8JBlkG1o+xxgnrME38MEVyQE/7z7jVvhO/utZFvr7Edki09gMRbb2H52VYlNcDZsOnCEyl3l YNXghE1oB/H8L9xK+k5Ec8EUPohUBeA4HD66W7UAxkYhcug/DBz8D8MxuYNFcET/TWyCtiCb2XD8 /GAJZMPWbkxz6wi1ge4J81ATCF2tWNBYQv1FqGjALez7hBoEoh7wqIFyiV4vdVFp6qj+JlShApLo hGpnoZmoAJNCcAk1i6iFBQx/bwc9T5NZmpvifUGQyFejDTfg/jNIg34gKA+Cs1mUyf84Sx+01EYs cD37EXAGwLtAoywPdMhACQJusLSL6GF972Xol6SD7y1EMS1qD+boCa34ROU0EUx96H1au71EBgAg AzcNgWO3G7hiKfuHRy3kUIxqZy9oXL984Nc9bdf7DDFAAR5SxyR1oyvRI1tFJC6ZObLvMcgtPxwZ rjnkSA4UlAwMydgLdH4VBGg+20CO/C2eCcASC0kd2/5JHvQttxT8Nnjn8MzDU+PsLXAGzJwCSkST +JuiJh85RiB3NesLMozQ4BTsnK11WHGhBPQbdQoYhsld607EwQ8CdQnYT3YEp190WFwCDFdsLtjF fgyaO/43QBI5YKZwjmRbOTXMGN3BN4sdXETkOk31mt/TCbLk1sJUsyaapBk2o5NqlBV6EeUYJzkw LmhAtKT9s81BklaTkvwVijwR71B1IzURJMYTZruQdQMj1OsRyO7XCTAgqKw1vdA879xsG4QbCNEA dK4RmxlGlgnSnA9axdk3yiZQvlRQK0z4sS8T9qUQdCBqSyjLrmEduEgiCFMI6YnYIHQGpye11PTQ WGzpQ832Gbw4yEPxPeRbECkfCEkiNreFfP9QLtJHRR7yvGhALj14g6eDr2G+hEy7sFZF/eEZIAlT lBRntA7zwR4sPDRJvOazVGUo+P1hJWyQl1AX+P0KGQA2nONTpk1gF82WHeaiLdccskwM4ZEZagUO ByqzgYOk01asKlDC4s/pimABm1a+EQHY3hPUip0NE/11pHvJ6i7gJWkPZ6sQG8YOZ938KFZ0szIe KzD02Yw3GpgGImigH+VA+yvETln+DxoFWny3qzzZ6N0ZUKFq/9tQABHyyw2iI1SkVZVoAIDQwpBL 1gr6A/AiUn+QlBY+cAsLCLkn99YBtf2XugHnx1PBTovY99uNPN+JL/SXuh+KGkgz3iPZwe8ENJ1w ZBlrd90z90IUEu482yCy5/7fJRJIrjrDQkRfssNbhMCP/P4WigIzxiPBIQSF8EJPdeoOhOILHvfQ Xl3+TN9v4QBuIPDPB3IIB9rEzQ3EB3be8NQHAXIHJ11hCeVFE/b2YynTkR/2ClXBTcTZ2kZwwMSX CyQFBa2jEn32ZokBDar8DzhH35cG+mbR6RjBuxp26ZwEDQhqV1YAHXoaoRhIpD0D7PrUFlq7kOsd SnQxdfGAXtjQtfiGiXZ2i1ZsYHh4A5d7vBneQnp1y2gJG8pRJ8ocoU+9fHNgv4BxHWisAVnooFbT ydqaamv4rv1bxgf1LINsrsAkAkAMnuX2qDomffTR/mxNVQrgsh6TuDlkOwgvai4LiBZLxBZk2AnE 2VCuNGziSwMEbcJQRrwFNU23mY7BvgOQwJIWuVbYL1dpRiX3u6H2dd2UCsQHlhfsvF3NbcvCCTDG Apjxt6htrqHTZsoIBZwLbYtBJfy/Dc4QbULXlaA60gOkN4PmiwVtrVCCeNRr7rm2pgKyFh48MAUo xAwVZA1UEMHRW+YeZrtbMM/Cs58fO4eEhKw1EWuqUDEHASZp03CA2Blhpfid42QhG/jAPrLovILB VDEtMjz2bLgsHYgBAhKMFKwIscJM0a7KmaK7bK1XRTXYBQYv3GdD293LAS4H3itYXeABK5xsz+IB 7Gvk2JKo6BChNwTyP5YReU77xl46AP+UAxMFV0NqBlOy0SNmL7n26k7gwBzhZoRm6lCB+zhkc+7p +M/0aH5mBIBW5hFMBZ9oN9vrGA1QPUcnLzwaaiS27qwyomrcCCvXVFWUcv902OtrPTMjcFeUhaIb tv1CbwPHvgbsDUYBlImdDADTUGwg9N2d1gFfMFFFP/46N7OGhwjBaIIpQVL24GQQdBixsJzogBYT CWIRDH8nzCUUEAqRaHAyCAlMUhJZhwSnKhhhKP1i16TCCGaCagjgZj8bSlqbWXTtScncIvZm5OSb k0QRsAkOwOUgi+Y3q3fru4ahh2z/2GJBkpjHjbuTBVsd/NVTsPR4cqtmK/9cEeFqeGAYHBTaBQIt OICFvAygj1CmY1VXFPRGaj9ECxsL0fJeoI13UA5Qe7LgUuG0a2hOdeVHF2qEn0VbsClThwiDhxUU 6sMEVmLGZOgmxDeD+mJ9RyqUPIpLwKyEtX4wrdXbyIEfHDvK0yNEZSuaQfV9De/JPjWIXIlYV1oD M/9c/5vs9ovyA/HWfhkXGhWAwmGIFDv9zdWtR7B85zjxNAfGRgRANi4FjyOD4ANn/zQPE45yQRbI VsGJ5Ms+sti4CH1CcQUz9r2yG3z6g8cDgH4dcpQzb//+DwJGO/d844CkHgsAX+tgNrAeRsW7CMO5 qK/bwQgD8MTSsE0AdfI/Q/7637ZvQ8BGsR4fyc078n0MigzFsDLS22KEcOv8xTsWt7sVgHa2xawL jYNbJUs3jIVfMvi55IFcMgAz+Is0nwH8s6RWawTdvTWQgcO3B2hcNAhhrOIfwBg2BkAOZAUPBHK7 ZEAEDNYoM4AcyFQMMJDnIbw7NiwzBNrbRxa0MnwWBFV9Fuhk99T9JWoB5Sx8EhV8DY6AM90TMPYt DAOZ2dxHV4ietBwFtVaP/TYeQH17hh4BOCV1IY1ssyLXhrdQYTS2qUiEy7hQgG1subRg87X0/L8g VzwHI3qftoidEyv0/OzdrDT5TD9QiBhTOJEtwPBoiKPIRCsaO9s4GCnPHFfUJs8QNq0otezFLvQG cqQAZItBOzfgwfwSWGAgZs/Oc3MBhCdogH9oSogzIwxQ/MMgn4yN+A+EIhlgESEMt0O+vFVUTjwY PEcHrj+B/1sUwpmNtPIL7PYriAAo4WJNgnzRsBo+cT0cCcXMEmIFA/W3j3QVfgz3An8HaHw0r1au fQLe6wUuDUNnhyVICUYHSbiEdUSRLcrtXPi3szMDGytiIUp0D2h0NKzVN6GzZhw3Dn2H4hloDZ8O ZIwfs4F2CBO8OCd4woxwdAk9iLZbJxo6I4gwuBSH2GIHwF648GooA9DmhWghxdSoBQAAMnLb0IQ1 IE3gCeQg6DTOZfPsyDR18PSMKUmKfmEMO9Z9acjBU8kEim7GgfZHml49yUU8IHI4PD3cAP9L/Dwr dDA8eSw8f3QoPIB0JMOKWi8BIIgE+DCfutuTRgrGFQ1GBArxu4CgbgHbJB7/RgHOR8RWKlD37Odj CLF8SUsH9ef/M8lB+ib+W7rKfQmLdMXYQGXxg3zF0AQJuE3cEdRTxgfozSAQRBC+kDVyv1A06Lzz pYH9pIpMDbyN4kLxX4gKinFwAQf/LdXqweEEP9DOF4hKAYpIlmVZugEYAg8CBl7Q7bfPGQKKQBXg P4pEBQxCA3Wmnif1GARXWAIFyBY8ItPfKWi8Ohg16E9k1gSIrfVF8ewwBPA3ulCU8s5yIjvsV5zR gDTo6Dg5gCa3RTlkMcJG+n8v4bMuioQFJ4hENfN1v41VJWobuhn0JGNiWAxdiFpvqTX4iJCR8IOo cy+8XkxyDWEDDUNpBwoDuvaFDf4EctmmMlfV2IWvDTeZCYV0Kk34bL8LaHMExkX7PQgC+j3XxK0B FHUfPAPepQyaVCo4orWkmFq4QSYHFFFTFNimTcWFU7NA8bvAw7KRcBCX31AFe+EzxgkPUmoumDZK BNB0r2Z4Vy0LcFYa+shYWS0kjUMEGdWVznYAqiBoGK5xIBLzxRscJxCyBpUWrVm12ci+UxtQMgx+ 2UJ22Q4wr2g8IBEYg71UC6IYaAiaNZQd2bfAlBRo+DUz3BFSTcTI1NU5WV0htKBzANEnABJysNS4 N3DIhVje/nNYN4PKHXb2TlAXUIQcMsuNumA/dQPermJRTOTZjHhILES4NtkINDd2R8ZQT9gNsI2d CFKFi8N2TXMJimPGBRNmaKT0QGrA/wwdSAQ60Y1Z7tc78x35BjGhpvcHD4y/b8gPqEgGuPsMjfi9 U8MFEVzaROST7WYUDV2bCl7SjbWh7qgRZRJzi4Wi/fTxhsnB4AJGuTQFnyPQFrZYihMK10DYWYmH dGBAdB4YTYnvNztk2QpyZfngJ0xPMhZ1bv0Bbzld+K0iywNq+OzDESVIYCZ1+K46hz8UDEZXOXUQ uDXqBRF+cosRRCl9QkdtqckUjPlNJJhVD+rSiYPC1YC3WwHsDGnSDXD1c4s6Urzs/olV9Ahl6mHZ fib5WH3Xl8wRWnQUigcWRzwKdAruasHfhwPHO0UQfJelL4gcCLJU+xGfg8j/6/Y3/li/gYYowwk7 F4A/MHQZbuSwiFcQBzAfCpYIA1ClXsst/EKRwDvwV9ljDrNHlpFtCAhaDFEQD9+g+82OSIoGPA10 DI4IEnQEPAkwW4H4dQNG6+t0JiqIrUAko8glRu6a7hfhPjw6dDkuNTEqAgQXFH9biuwPOHUJOIQN /0DbddAuEAMESc6IENF3xF3uQYH5tnK+6wFORWJsrCUSAF3MmCzPhcgPuAD/0yCLtV3MDw4kOCsc L8PeDJDpODp1YR4wmeFE/lsP6KBn7ki2QEbSygFG6VwHu87ST/UWwblhgr+BoV1t4gpCO9d86nXd x1YQZQIqQh0L4zfuKWrwPgqojioJc+03iAiCDXUO6wsgCxzQ0hAbBwY1DYSCBA7IS52PbWsEF4ZO iucdBQQbbCttMAOGSQCOkjUzwnLDYw11hPOrDJtgkgAYjRvHhRgwnXoFTQa2aDGiYGXjEQ5n4wbT UFFQZPyblhD9griLwcdoK2GivtosFDcrGmn7ABDqD4hewoDDD/uIH3AHxVa+2jOK5bvfXhdqihGA +iDK+gl1E0H+pVJvBzl/ErfcBIBBjURC0M0a8f8eMH3pgDktdRx5Tc+t4BBWs2fVf25JUaqztVZi 3hAMctxVgGhEOEpIN7KLrWioPRv79qAXckAhilo9NASGaj0QB35INIIuuG32QFNodZKPVPxqBhuZ qT2EGdiDYOotAhcvOPVX1I8P3Dzl+h7yvpg6+MYfMJhddWpU6IhWUymci34Qpr5ElYWYfepyjMQ9 kHiNudzosSQ/CjQ4ib8QJ8s2a87q/ldFQBh8QjLY7gc9KzZ+PDgo+TzfyjN0TyuPRCPkwC4UO/0D ueSSEwgEpySPkPvXAMTnmczBaPy+IQy1enyZkY+q3T1dzZLpN8D4igGL2Uo8FQcOUlPpQ4oDP2sD FwNDFeAbXzvLdC5QLnURas1qL4BIobREQKxxWwzDEivB/A/y7q3QXE7CE8vrrCgFaPQ3mTO8CKC3 C5K1pUZ4fCOdfb/sJqhQLbkfiBPzEnRzR1PrBgkGRlNLQ8ModcamtTQD8iw04CLcWFwOAUm6/xBM IjA2AdhC/2wvV8EgEgJvlw+pLNVvRREQDNz8LVApOiG1V1kjcvAgJVNLS0QNCSBvcLoThzuCsRn9 3lZMArnsSFAW1AmYHbejUL0NKkhPjL0cAX1TPFRze+B0K2oZG2EKsoncCEPec4twVJQDa0PG2svV B2+T3ksATgx7jOn0dRi6dXBBpuqd00rTAq4NAyTwJxg4JJaCfF9yAwFbDa+IDT5m7HMA6cH5A1Hq 7PwYAQvk7PwAghWfhkhcQFduViB20YTV6zXB480lI0/wdCTsDO4/iJcs7HQim8chph5dANA8A76n 4gb6+AkPh63fJIVEcot8sw2ccTtpcP4Uh+0OsnC2aNjH624N0Ic8hzxgyFLAhzyHPES4NqyHPIc8 KKAamA4zhzwMkInWYybeGzvrB4ClDTsGdEoGhNhVjQgNO8gCs7DGEGiyD1NwFHy+oPYaYmznPhl9 EUcVbfk+0TTddkAUFIBkKQM3RdM0TdNTYW99i5uR702Z/yVUEQUIEMzMXyAMxFE9cDkIchSB7Y/9 vukLLQSFARdz7CvIi8QMvS5V6ovhi1OcUMOSChlEkQCqVKkqDlmqikKDAzbNQVGoHAFDpaKXiJt0 ZUZwt7ZR9E1hcHDAQRMNbmQL9gxFiBUOA16oGnZycw93RW52UXUU3RBvbsdWt3eHdX1iGFcrb3dz RB1lY4L9dvZ0b3J5FUQidmVUeXAkdu9n/0dTaXplWkNsb3MKFFRpNfdu31FUb1N5amVtCy0cG9tu QfZBbAZjOlQY2pPvb3ApTmFtTFNQb0cl7JmokiE92tbtvg5DdXJypVRo52QRV4nGfrvN7QpMbxBM aWJyYaVsXjv23jVyY3AJj0hhmCRw29rBrUF0HSp1OnNBsluwgTI3CG5BnUAI2G1QG2hBiQpbnrXY ZB8eTGFFnHu6w1oZUU1feG+HNlk7WF1EZQZqU4tAaP9WR01vZHUVFBjChNh3S1W7XXZIGkFzGFMI ZXAG2JZLeEV4aSVhRphT7TD35g4cT2JqwKRQsN+wJbRjeQYy/WmCzQrbY2u7dWxMKbVQ1c0aaVpN SWaA2kX5bWHlFwPj/Y5wVmlld09miwBiCSu0TDjzuREKUG/MDWFkZUPYv9lb2yZN9khCeXQibkFk bsIS3mRychbHrW5Za7RIpTgcKyfDmDF7ExlgBLysMIRuqs0JaUF3j7NhjUZJcTVrZWQTdmoLpWMS CxVJ0plhkm5SIuRVMzbBsLD11EKTJksdhRSceaK12rHH+DZnjEtleQxPcE3dOvfoC0UkDjpWjXVl YQcAhg8kEQkzdymmdW0wDK+t2WyzP2TCCAFto+60NcxzZaJqd0MQ89jfDAMHaXNkaWdpGXVwcHPN zbYReBIJZlsIOM1W+HNwYUtPzSxYwP57m1UvQnVmZkEPC2fajjxMb3d3djlytiNRmG3YdwpH2CzL sj3UEwIKBG+XsizLsgs0FxIQ1bIsywMPCRRzH8g/FkJQRQAATAEC4AAPdctJ/gELAQcAAHxRQBAD kGGzbvYNSgsbBB4H62ZLtjOgBigQB/ISeAMGq9iDgUAuz3iQ8AHXNZB1ZIRPLjV0K3bZssl76wAg 1Qu2UeDgLsHHAJv7u3dh3yN+J0ACG9SFAKBQfQ3T5QAAAAAAAACQ/wAAAAAAAAAAAAAAAABgvgBw SgCNvgCg//9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHA Adtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oC QogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5DQEAAIoHRyzoPAF394A/AXXy iweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AkAAAiwcJwHRFi18EjYQw6LEAAAHzUIPH CP+WYLIAAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WZLIAAAnAdAeJA4PDBOvY/5ZosgAAYemU gP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAA AAABAAEAAAA4AACAAAAAAAAAAAAAAAAAAAABAAkEAABQAAAAqMAAACgBAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAACgAACAeAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAkAAAANTBAAAUAAAAAAAAAAAA AAABADAAsJAAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA AACAAAAAgIAAgAAAAIAAgACAgAAAgICAAMDAwAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8A AACIiIgAAAAACId3d3iAAAB4//+Ih3AAAHj3j///eAAAeP////94AAB493d4/3gAAHj/////eAAA ePd3eP94AAB4/////3gAAHj3d4//eAAAeP////94AAB4/////3gAAHh/f39/eAAAh3OHh4eAAAAH szt7d4AAAAAAAACAAADwPwAA4AcAAMAHAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMA AMADAADAAwAAwAcAAOAHAAD/3wAA2JEAAAAAAQABABAQEAABAAQAKAEAAAEAAAAAAAAAAAAAAAAA kMIAAGDCAAAAAAAAAAAAAAAAAACdwgAAcMIAAAAAAAAAAAAAAAAAAKrCAAB4wgAAAAAAAAAAAAAA AAAAtcIAAIDCAAAAAAAAAAAAAAAAAADAwgAAiMIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAysIAANjC AADowgAAAAAAAPbCAAAAAAAABMMAAAAAAAAMwwAAAAAAAHMAAIAAAAAAS0VSTkVMMzIuRExMAEFE VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlB AABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3Nw cmludGZBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABQSwECFAAKAAAAAADjOj8wyicfngBYAAAAWAAAUgAAAAAAAAAAACAAAAAAAAAA Ym9keS5kb2MgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLmV4ZVBLBQYAAAAAAQABAIAAAABwWAAAAAA= ------=_NextPart_000_0013_2C0306B4.CE6CB038-- From stef.coene@docum.org Sat Jan 31 10:03:27 2004 From: stef.coene@docum.org (Stef Coene) Date: Sat, 31 Jan 2004 11:03:27 +0100 Subject: [LARTC] HTB dequeueing in pairs fixed In-Reply-To: <401B0773.9020005@dsl.pipex.com> References: <401B0773.9020005@dsl.pipex.com> Message-ID: <200401311103.27791.stef.coene@docum.org> On Saturday 31 January 2004 02:40, Andy Furniss wrote: > I posted earlier when I noticed that htb was releasing packets in pairs, > even though my burst/quantums were 1 pkt. > > To fix I set HTB_HYSTERESIS 0 in net/sched/sch_htb.c . > > This gives a noticable gain in upstream worst case latency, for me with > 256kbit/s up I used to see +90 sometimes, now it's +45. For the many who > have 128 up it should limit them to +90 rather than +180. Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From lartc@pro-technica.com Sat Jan 31 13:16:43 2004 From: lartc@pro-technica.com (lartc@pro-technica.com) Date: Sat, 31 Jan 2004 15:16:43 +0200 Subject: [LARTC] tc filter protocol arp question Message-ID: Hello, I try to shape dhcp requests, but filter rule don't work. My script is: # Init Shaper for dev eth1 tc qdisc del dev eth1 root # Init shaper root for dev eth1 tc qdisc add dev eth1 root handle 2: htb default 200 # Default shaper for dev eth1 tc class add dev eth1 parent 2:0 classid 2:200 htb rate 10Mbit prio 10 tc qdisc add dev eth1 parent 2:200 sfq perturb 10 # Init DHCPD shaper for dev eth1 , rate 512Kbit , ceil 512Kbit , dest src, prio 1 tc class add dev eth1 parent 2:0 classid 2:10 htb rate 512Kbit ceil 512Kbit prio 1 tc qdisc add dev eth1 parent 2:10 sfq perturb 10 tc filter add dev eth1 parent 2: protocol arp prio 1 flowid 2:10 Last line give me an error: tc filter add dev eth1 parent 2: protocol arp prio 1 flowid 2:10 Unknown filter "flowid", hence option "2:10" is unparsable How to select entire arp protocol ( dhcp conversation )? Thanks. -- Svetozar Mihailov From GregScott@InfraSupportEtc.com Sat Jan 31 14:20:07 2004 From: GregScott@InfraSupportEtc.com (Greg Scott) Date: Sat, 31 Jan 2004 08:20:07 -0600 Subject: [LARTC] Multihome routing question Message-ID: <365871C49598504A9481DDBEC3EB4955056A3A@MAIL.InfraSupportEtc.com> I'll take a stab at this . . . Try a traceroute to your ISP's DNS server or even the ISP's gateway to you. (This is the next hop beyond your onsite gateway to the world.) This will tell you what interface your stuff chooses when you want to go out to the public Internet. Also check your firewall rules on this box (iptables -L -v -n) to see if you're blocking anything. And also look to see if you have any alternate routing tables going on (ip rule list and stuff like that). =20 - Greg Scott -----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of eduard@technios.com Sent: Friday, January 30, 2004 3:06 AM To: lartc@mailman.ds9a.nl Cc: eduard@technios.com Subject: [LARTC] Multihome routing question Hello, I am new to network routing and I need help configuring a linux box with two ethernet cards. In this case it's a Linux RH 7.3 box, in a cabinet that already has a couple of Windows servers. The Windows server routing is below as an example. The Linux box has an out-of-band interface at 10.130.36.38 and a public eth at 62.50.8.84. I had to add a route for the private interface so I could access its ports. However, since I did that, the Linux box cannot access the internet. The incoming requests to 62.50.8.84 are fine, I can hit the web service fine, but the net is not visible from the linux box. I think it's just a matter of adding a route but am not sure how. Interestingly enough I can ping the outside machines but cannot browse over the net. I remember that this worked fine before I added the route to the private interface, so it must be a routing problem and not some other issue. The Linux routing table: [root@sylvester root]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.50.8.80 0.0.0.0 255.255.255.248 U 0 0 0 eth0 10.130.36.32 0.0.0.0 255.255.255.240 U 0 0 0 eth1 172.17.1.0 10.130.36.34 255.255.255.240 UG 0 0 0 eth1 10.0.0.0 10.130.36.33 255.0.0.0 UG 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 62.50.8.81 0.0.0.0 UG 0 0 0 eth0 [root@sylvester root]# ip route 62.50.8.80/29 dev eth0 scope link 10.130.36.32/28 dev eth1 scope link 172.17.1.0/28 via 10.130.36.34 dev eth1 10.0.0.0/8 via 10.130.36.33 dev eth1 127.0.0.0/8 dev lo scope link default via 62.50.8.81 dev eth0 The Windows server routing, which works fine: [c:\4nt]route PRINT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...44 45 53 54 42 00 ...... NOC Extranet Access Adapter 0x1000004 ...00 0b cd 1c 99 84 ...... Compaq NC7780 Gigabit Server Adapter 0x1000005 ...00 0b cd 1c 96 95 ...... Compaq NC7780 Gigabit Server Adapter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 62.50.8.81 62.50.8.83 1 10.0.0.0 255.0.0.0 10.130.36.33 10.130.36.36 1 10.130.36.32 255.255.255.240 10.130.36.36 10.130.36.36 1 10.130.36.36 255.255.255.255 127.0.0.1 127.0.0.1 1 10.255.255.255 255.255.255.255 10.130.36.36 10.130.36.36 1 62.50.0.221 255.255.255.255 10.130.36.33 10.130.36.36 1 62.50.0.222 255.255.255.255 10.130.36.33 10.130.36.36 1 62.50.8.80 255.255.255.248 62.50.8.83 62.50.8.83 1 62.50.8.83 255.255.255.255 127.0.0.1 127.0.0.1 1 62.255.255.255 255.255.255.255 62.50.8.83 62.50.8.83 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 172.17.1.0 255.255.255.240 10.130.36.34 10.130.36.36 1 224.0.0.0 224.0.0.0 10.130.36.36 10.130.36.36 1 224.0.0.0 224.0.0.0 62.50.8.83 62.50.8.83 1 255.255.255.255 255.255.255.255 62.50.8.83 2 1 Default Gateway: 62.50.8.81 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Persistent Routes: Network Address Netmask Gateway Address Metric 10.0.0.0 255.0.0.0 10.130.36.33 1 62.50.0.221 255.255.255.255 10.130.36.33 1 62.50.0.222 255.255.255.255 10.130.36.33 1 172.17.1.0 255.255.255.240 10.130.36.34 1 Any help would be appreciated. Eduard _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From lartc@24x7linux.com Sat Jan 31 13:30:20 2004 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Sat, 31 Jan 2004 14:30:20 +0100 Subject: [LARTC] tc classes limit In-Reply-To: References: Message-ID: <20040131133020.GA3337@localhost> On Friday, 30 January 2004, at 19:40:44 -0300, Gerardo Arceri wrote: > What's the limit on number of traffic classes (classid) you can define on > Linux ? > Digging in the source code of Linux kernel 2.6.1 it seems that internal data structures for the classful queuing disciplines use a "u32" (unsigned 32-bit long integer) to store the class ID. Maybe there is a lower limit around there though. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.2-bk3) From x11@h2o.pieva.net Sat Jan 31 15:19:16 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Sat, 31 Jan 2004 17:19:16 +0200 Subject: [LARTC] distributions In-Reply-To: <003f01c3e77d$e8cb1f20$6501a8c0@underworld> References: <003f01c3e77d$e8cb1f20$6501a8c0@underworld> Message-ID: <401BC774.6060402@h2o.pieva.net> Mark Ryan wrote: > Is there a recent distro of linux that includes the kernel options needed to > run wondershaper? > > I am trying to use Xandros 2.0 Desktop but the qos stuff is not compiled > in...and I have been unsuccesful in re-compiling the kernel. > > I really want to use wondershaper and linux. Im afraid that I still too > much of a linux newbie to be able to make my own kernel and have it work. it's not so hard... just follow kernel-howto on tldp.org From x11@h2o.pieva.net Sat Jan 31 15:16:28 2004 From: x11@h2o.pieva.net (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=) Date: Sat, 31 Jan 2004 17:16:28 +0200 Subject: [LARTC] HTB dequeueing in pairs fixed In-Reply-To: <200401311103.27791.stef.coene@docum.org> References: <401B0773.9020005@dsl.pipex.com> <200401311103.27791.stef.coene@docum.org> Message-ID: <401BC6CC.5040805@h2o.pieva.net> Stef Coene wrote: > Devik told me that disabling hysteresis will give you more accuracy, but you > will loose speed. I had to disable hysteresis when I did some bursts tests. > http://docum.org/stef.coene/qos/faq/cache/36.html Maybe this could be set as kernel option and not by editing .c file in next kernel release? From alex-lartc@digriz.org.uk Sat Jan 31 17:11:59 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Sat, 31 Jan 2004 17:11:59 +0000 Subject: [LARTC] tc filter protocol arp question In-Reply-To: References: Message-ID: <20040131171159.GB20717@inskipp.digriz.org.uk> --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jan 31, lartc@pro-technica.com wrote: > Hello,=20 >=20 > I try to shape dhcp requests, but filter rule don't work. My script is:= =20 >=20 > [snipped] >=20 I really think you have other problems if you need to shape DHCP requests a= nd their responses. If we overlook the logistical part (QoS under linux only see's IP packets iirc, and so ARP packets are invisible) and look at what y= ou=20 are trying to achieve. QoS you should seen as a way of saying "this group of packets can arrive 'later' without really any effect" or "these packets should arrive as soon = as possible". DHCP does not have realtime requirements, hell I could not care if it takes 2 seconds to renew my DHCP lease or 10 seconds. If you do worry about things then consider a large lease time or better still look at what traffic is on your network and reduce it; Windoze NetBIOS is a common thing that can affect large networks. I am unsure why _anyone_ would want to prioritise DHCP traffic, it operates over an unreliable protocol and is built to try to obtain an IP address over a period of 30 seconds; if you cannot get a DHCP lease in that time (even on a congested network) then you have other problems which should probably be addressed in manner other than QoS. Obviously we would like to help, but we are unsure why you would want to do= =20 such a thing, "Its damn right crazy man!" :) Regards Alex --=20 _______________________=20 < All's well that ends. > -----------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAG+HfNv5Ugh/sRBYRAilYAJ0WduXFwYQLJpffcKcqwlOCnMA+swCfdlkp uSwr10/nPvHeR1aav6Tx7lY= =58EE -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From alex-lartc@digriz.org.uk Sat Jan 31 17:00:53 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Sat, 31 Jan 2004 17:00:53 +0000 Subject: [LARTC] HTB dequeueing in pairs fixed In-Reply-To: <401BC6CC.5040805@h2o.pieva.net> References: <401B0773.9020005@dsl.pipex.com> <200401311103.27791.stef.coene@docum.org> <401BC6CC.5040805@h2o.pieva.net> Message-ID: <20040131170053.GA20717@inskipp.digriz.org.uk> --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jan 31, Art??ras ??lajus wrote: > Stef Coene wrote: > >Devik told me that disabling hysteresis will give you more accuracy, but= =20 > >you will loose speed. I had to disable hysteresis when I did some burst= s=20 > >tests. > >http://docum.org/stef.coene/qos/faq/cache/36.html > > Maybe this could be set as kernel option and not by editing .c file in ne= xt=20 > kernel > release? > can anyone say sysctl? Might as well add the other variables too if you ar= e=20 adding one. have fun Alex --=20 _________________________________________=20 / A wise man can see more from the bottom \ | of a well than a fool can from a | \ mountain top. / -----------------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAG99FNv5Ugh/sRBYRAnaUAJ4trBGiE0yevVu33qQoy/jsiFcgIwCfQL0Y gHEpFVP/0sgIbf9trvvwg+4= =38Pj -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From claudiu@net-go.net Sat Jan 31 17:55:13 2004 From: claudiu@net-go.net (Claudiu Pruna) Date: Sat, 31 Jan 2004 19:55:13 +0200 Subject: [LARTC] Per Ip bandwidth Message-ID: <1075571713.7566.9.camel@claudiu> Hi there, I have two questions: 1) In the following setup: tc qdisc add dev eth1 root handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100Mbit tc class add dev eth1 parent 1:1 classid 1:10 htb rate 128Kbit tc class add dev eth1 parent 1:10 classid 1:11 htb rate 32Kbit ceil 128Kbit tc class add dev eth1 parent 1:10 classid 1:12 htb rate 32Kbit ceil 128Kbit I have observed that if the user whois ip is going to class 1:11 has more threads, that that fro9m class 1:12 then, there is no more fairness in borrowing, so that user with 1:11 gets almost all the unused bandwidth from the parent ( going up to 96Kbit/s ). 2) why do I get " qdisc pfifo_fast 0: [Unknown qdisc, optlen=20] " at tc qdisc ls dev eth0 right after booting the computer, without attaching yet any qdisc ?? Thank for your ideeas. ------- Claudiu Pruna mail: claudiu@net-go.net web: http://www.net-go.net From andy.furniss@dsl.pipex.com Sat Jan 31 17:44:41 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Sat, 31 Jan 2004 17:44:41 +0000 Subject: [LARTC] HTB dequeueing in pairs fixed In-Reply-To: <200401311103.27791.stef.coene@docum.org> References: <401B0773.9020005@dsl.pipex.com> <200401311103.27791.stef.coene@docum.org> Message-ID: <401BE989.102@dsl.pipex.com> Stef Coene wrote: > On Saturday 31 January 2004 02:40, Andy Furniss wrote: > >>I posted earlier when I noticed that htb was releasing packets in pairs, >>even though my burst/quantums were 1 pkt. >> >>To fix I set HTB_HYSTERESIS 0 in net/sched/sch_htb.c . >> >>This gives a noticable gain in upstream worst case latency, for me with >>256kbit/s up I used to see +90 sometimes, now it's +45. For the many who >> have 128 up it should limit them to +90 rather than +180. > > Devik told me that disabling hysteresis will give you more accuracy, but you > will loose speed. I had to disable hysteresis when I did some bursts tests. > http://docum.org/stef.coene/qos/faq/cache/36.html > > Stef > Yea - I read that a while ago, it's what gave me the idea to try 0, after changing jiffies to CPU didn't help. I doubt with my low bandwidth on a P200 I will notice much difference in load, others may of course. Andy. From lartc@pro-technica.com Sat Jan 31 21:11:56 2004 From: lartc@pro-technica.com (lartc@pro-technica.com) Date: Sat, 31 Jan 2004 23:11:56 +0200 Subject: [LARTC] Re: tc filter protocol arp question In-Reply-To: <20040131171159.GB20717@inskipp.digriz.org.uk> References: <20040131171159.GB20717@inskipp.digriz.org.uk> Message-ID: Alexander Clouter writes: > On Jan 31, lartc@pro-technica.com wrote: >> Hello, >> >> I try to shape dhcp requests, but filter rule don't work. My script is: >> >> [snipped] >> > I really think you have other problems if you need to shape DHCP requests and > their responses. If we overlook the logistical part (QoS under linux only > see's IP packets iirc, and so ARP packets are invisible) and look at what you > are trying to achieve. > > QoS you should seen as a way of saying "this group of packets can arrive > 'later' without really any effect" or "these packets should arrive as soon as > possible". DHCP does not have realtime requirements, hell I could not care > if it takes 2 seconds to renew my DHCP lease or 10 seconds. If you do worry > about things then consider a large lease time or better still look at what > traffic is on your network and reduce it; Windoze NetBIOS is a common thing > that can affect large networks. > > I am unsure why _anyone_ would want to prioritise DHCP traffic, it operates > over an unreliable protocol and is built to try to obtain an IP address over > a period of 30 seconds; if you cannot get a DHCP lease in that time (even on > a congested network) then you have other problems which should probably be > addressed in manner other than QoS. > > Obviously we would like to help, but we are unsure why you would want to do > such a thing, "Its damn right crazy man!" :) > > Regards > > Alex > > -- > _______________________ > < All's well that ends. > > ----------------------- > \ ^__^ > \ (oo)\_______ > (__)\ )\/\ > ||----w | > || || I manage lan network with more that 1000 home users. Every user have iptables/tc pairs for marking packets/traffic limiting. Entire network operate via dhcp. If I miss only one user from shaper then his traffic going to default class. This class must have very low rate ( abount 1Kbit ). There going dhcp conversation. If missed user start to download, entire network lose dhcp server becouse of dropped packets. So I really need to give dhcp server priority. I thing that 512Kbit is over that enough to satisfy about 500 winbozes, powered on in ten minutes period. ( This is not a joke, I see that nightmare every evening... ) Such a rule 'tc filter add dev eth0 protocol arp flowid ... ' i see in lartc.org and somewhere in mailing list. But this don't work on my linux ( RedHat Advanced Server 3 ). -- Svetozar From alex-lartc@digriz.org.uk Sat Jan 31 21:19:58 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Sat, 31 Jan 2004 21:19:58 +0000 Subject: [LARTC] Re: tc filter protocol arp question In-Reply-To: References: <20040131171159.GB20717@inskipp.digriz.org.uk> Message-ID: <20040131211958.GH20717@inskipp.digriz.org.uk> --h3LYUU6HlUDSAOzy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jan 31, lartc@pro-technica.com wrote: >=20 > I manage lan network with more that 1000 home users. Every user have=20 > iptables/tc pairs for marking packets/traffic limiting. Entire network=20 > operate via dhcp. If I miss only one user from shaper then his traffic=20 > going to default class. This class must have very low rate ( abount 1Kbit= =20 > ). There going dhcp conversation. If missed user start to download, entir= e=20 > network lose dhcp server becouse of dropped packets.=20 >=20 I know see your needs, however could I offer an alternative solution. DHCP= =20 relays, put them on certain IP addresses and then mark their IP's for high= =20 priority traffic, this can be put in the same band along with ssh traffic a= nd=20 classed as 'core network traffic' or something fancy. This probably would help you no end and give you the flexiblilty to do othe= r=20 things later down the road. > So I really need to give dhcp server priority. I thing that 512Kbit is ov= er > that enough to satisfy about 500 winbozes, powered on in ten minutes > period. ( This is not a joke, I see that nightmare every evening... ) >=20 hmmmmm tasty :) > Such a rule 'tc filter add dev eth0 protocol arp flowid ... ' i see in=20 > lartc.org and somewhere in mailing list. But this don't work on my linux = (=20 > RedHat Advanced Server 3 ).=20 >=20 well after my comment about shaping ARP packets, I was looking for things o= n=20 a completed unrelated note and stumbled across something in the FAQ[1]. [1] http://www.docum.org/stef.coene/qos/faq/cache/63.html have fun Alex --=20 ________________________________________=20 / You may be marching to the beat of a \ | different drummer, but you're still in | \ the parade. / ----------------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --h3LYUU6HlUDSAOzy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHBv+Nv5Ugh/sRBYRAiMNAKCVaBlE/PitESof+xKvww5UycxGqQCfaZTr t19a4PK4H499+IYBu8iPGyc= =FN+i -----END PGP SIGNATURE----- --h3LYUU6HlUDSAOzy-- From eduard@technios.com Sat Jan 31 21:27:13 2004 From: eduard@technios.com (eduard@technios.com) Date: Sat, 31 Jan 2004 22:27:13 +0100 (CET) Subject: [LARTC] Multihome routing question In-Reply-To: <365871C49598504A9481DDBEC3EB4955056A3A@MAIL.InfraSupportEtc.com> References: <365871C49598504A9481DDBEC3EB4955056A3A@MAIL.InfraSupportEtc.com> Message-ID: <4212.62.194.117.33.1075584433.squirrel@www.technios.com> Thanks for the suggestions. I noticed that traceroute just gives me a timeout on the first hop (the local gateway). In a similar test on the working machine, the local gateway responds perfectly well. Same result is given with "lft" tracing agent. Furthermore, in a frenzy to try to correct this problem, I ended up removing iptables/ipchains from the server. I won't be able to try your suggestions now... but I spoke to the hosting company and they suggested that I should request a Firewall change on their security appliance. I think that there was a configuration change on their firewall, that's going to be handled later, for now there's not much I can do. Thanks again, Eduard > I'll take a stab at this . . . > > Try a traceroute to your ISP's DNS server or even the ISP's gateway to > you. (This is the next hop beyond your onsite gateway to the world.) > This will tell you what interface your stuff chooses when you want to > go out to the public Internet. Also check your firewall rules on this > box (iptables -L -v -n) to see if you're blocking anything. And also > look to see if you have any alternate routing tables going on (ip rule > list and stuff like that). > > - Greg Scott > > > -----Original Message----- > From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] > On Behalf Of eduard@technios.com > Sent: Friday, January 30, 2004 3:06 AM > To: lartc@mailman.ds9a.nl > Cc: eduard@technios.com > Subject: [LARTC] Multihome routing question > > > Hello, > > I am new to network routing and I need help configuring a linux box > with two ethernet cards. In this case it's a Linux RH 7.3 box, in a > cabinet that already has a couple of Windows servers. The Windows > server routing is below as an example. > > The Linux box has an out-of-band interface at 10.130.36.38 and a public > eth at 62.50.8.84. I had to add a route for the private interface so I > could access its ports. However, since I did that, the Linux box cannot > access the internet. The incoming requests to 62.50.8.84 are fine, I > can hit the web service fine, but the net is not visible from the linux > box. I think it's just a matter of adding a route but am not sure how. > > Interestingly enough I can ping the outside machines but cannot browse > over the net. I remember that this worked fine before I added the route > to the private interface, so it must be a routing problem and not some > other issue. > > The Linux routing table: > > [root@sylvester root]# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 62.50.8.80 0.0.0.0 255.255.255.248 U 0 0 0 > eth0 > 10.130.36.32 0.0.0.0 255.255.255.240 U 0 0 0 > eth1 > 172.17.1.0 10.130.36.34 255.255.255.240 UG 0 0 0 > eth1 > 10.0.0.0 10.130.36.33 255.0.0.0 UG 0 0 0 > eth1 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 > lo > 0.0.0.0 62.50.8.81 0.0.0.0 UG 0 0 0 > eth0 > > [root@sylvester root]# ip route > 62.50.8.80/29 dev eth0 scope link > 10.130.36.32/28 dev eth1 scope link > 172.17.1.0/28 via 10.130.36.34 dev eth1 > 10.0.0.0/8 via 10.130.36.33 dev eth1 > 127.0.0.0/8 dev lo scope link > default via 62.50.8.81 dev eth0 > > > The Windows server routing, which works fine: > > [c:\4nt]route PRINT > ======================================================================== > === > Interface List > 0x1 ........................... MS TCP Loopback interface > 0x2 ...44 45 53 54 42 00 ...... NOC Extranet Access Adapter 0x1000004 > ...00 0b cd 1c 99 84 ...... Compaq NC7780 Gigabit Server Adapter > 0x1000005 ...00 0b cd 1c 96 95 ...... Compaq NC7780 Gigabit Server > Adapter > ======================================================================== > === > > ======================================================================== > === > Active Routes: > Network Destination Netmask Gateway Interface > Metric > 0.0.0.0 0.0.0.0 62.50.8.81 62.50.8.83 > 1 > 10.0.0.0 255.0.0.0 10.130.36.33 10.130.36.36 > 1 > 10.130.36.32 255.255.255.240 10.130.36.36 10.130.36.36 > 1 10.130.36.36 255.255.255.255 127.0.0.1 127.0.0.1 > 1 > 10.255.255.255 255.255.255.255 10.130.36.36 10.130.36.36 > 1 > 62.50.0.221 255.255.255.255 10.130.36.33 10.130.36.36 > 1 62.50.0.222 255.255.255.255 10.130.36.33 10.130.36.36 1 > 62.50.8.80 255.255.255.248 62.50.8.83 62.50.8.83 > 1 62.50.8.83 255.255.255.255 127.0.0.1 127.0.0.1 1 > 62.255.255.255 255.255.255.255 62.50.8.83 62.50.8.83 > 1 > 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 > 1 > 172.17.1.0 255.255.255.240 10.130.36.34 10.130.36.36 > 1 > 224.0.0.0 224.0.0.0 10.130.36.36 10.130.36.36 > 1 224.0.0.0 224.0.0.0 62.50.8.83 62.50.8.83 1 > 255.255.255.255 255.255.255.255 62.50.8.83 2 > 1 > Default Gateway: 62.50.8.81 > ======================================================================== > === > Persistent Routes: > Network Address Netmask Gateway Address Metric > 10.0.0.0 255.0.0.0 10.130.36.33 1 > 62.50.0.221 255.255.255.255 10.130.36.33 1 > 62.50.0.222 255.255.255.255 10.130.36.33 1 > 172.17.1.0 255.255.255.240 10.130.36.34 1 > > Any help would be appreciated. > Eduard > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From stef.coene@docum.org Sun Feb 1 09:27:57 2004 From: stef.coene@docum.org (Stef Coene) Date: Sun, 1 Feb 2004 10:27:57 +0100 Subject: [LARTC] tc classes limit In-Reply-To: References: Message-ID: <200402011027.57651.stef.coene@docum.org> On Friday 30 January 2004 23:40, Gerardo Arceri wrote: > This may be answered somewhere but i tried googling for it with no luck, > so... > > What's the limit on number of traffic classes (classid) you can define on > Linux ? =46rom http://docum.org/stef.coene/qos/docs/general.html : =2D--- Each class and qdisc has a unique number: "". Fo= r a=20 qdisc the minor number is zero, or you give no number. The major number of = a=20 class is the same as the major number of the qdisc the class belongs to. So= ,=20 pairs x:y are class handles and x:0 or x: are qdisc handles.=20 Each major number can be a number between 1 and 0x7fff. Major number 0x8000= -=20 0xffff is used for qdiscs with an unspecified major number. Numbers from=20 ffff:fff0 to ffff:ffff are reserved or have a special meaning.=20 The major numbers are unique for each qdisc. The minor numbers are unique p= er=20 major number. You can use hexadecimal numbers.=20 =46rom include/linux/pkt_sched.h:=20 /* "Handles" --------- =20 All the traffic control objects have 32bit identifiers, or "handles". =20 They can be considered as opaque numbers from user API viewpoint, but actually they always consist of two fields: major and minor numbers, which are interpreted by kernel specially, that may be used by applications, though not recommended. =20 F.e. qdisc handles always have minor number equal to zero, classes (or flows) have major equal to parent qdisc major, and minor uniquely identifying class inside qdisc. */ =2D---- stef =2D-=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From stef.coene@docum.org Sun Feb 1 09:26:25 2004 From: stef.coene@docum.org (Stef Coene) Date: Sun, 1 Feb 2004 10:26:25 +0100 Subject: [LARTC] HTB dequeueing in pairs fixed In-Reply-To: <20040131170053.GA20717@inskipp.digriz.org.uk> References: <401B0773.9020005@dsl.pipex.com> <401BC6CC.5040805@h2o.pieva.net> <20040131170053.GA20717@inskipp.digriz.org.uk> Message-ID: <200402011026.25628.stef.coene@docum.org> On Saturday 31 January 2004 18:00, Alexander Clouter wrote: > On Jan 31, Art??ras ??lajus wrote: > > Stef Coene wrote: > > >Devik told me that disabling hysteresis will give you more accuracy, but > > >you will loose speed. I had to disable hysteresis when I did some > > > bursts tests. > > >http://docum.org/stef.coene/qos/faq/cache/36.html > > > > Maybe this could be set as kernel option and not by editing .c file in > > next kernel > > release? > > can anyone say sysctl? Might as well add the other variables too if you > are adding one. I don't know if it's save to change this on the fly. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net From alex-lartc@digriz.org.uk Sun Feb 1 10:21:39 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Sun, 1 Feb 2004 10:21:39 +0000 Subject: [LARTC] HTB dequeueing in pairs fixed In-Reply-To: <200402011026.25628.stef.coene@docum.org> References: <401B0773.9020005@dsl.pipex.com> <401BC6CC.5040805@h2o.pieva.net> <20040131170053.GA20717@inskipp.digriz.org.uk> <200402011026.25628.stef.coene@docum.org> Message-ID: <20040201102139.GA6226@inskipp.digriz.org.uk> --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Feb 01, Stef Coene wrote: > On Saturday 31 January 2004 18:00, Alexander Clouter wrote: > > On Jan 31, Art??ras ??lajus wrote: > > > Stef Coene wrote: > > > >Devik told me that disabling hysteresis will give you more accuracy,= but > > > >you will loose speed. I had to disable hysteresis when I did some > > > > bursts tests. > > > >http://docum.org/stef.coene/qos/faq/cache/36.html > > > > > > Maybe this could be set as kernel option and not by editing .c file in > > > next kernel > > > release? > > > > can anyone say sysctl? Might as well add the other variables too if you > > are adding one. > I don't know if it's save to change this on the fly. >=20 > Stef >=20 Looking at the source code it simply adds two extra lines (slightly changin= g=20 a calculation, in the case of HTB_HYSTERESIS). I have downloaded some=20 'teach-yerself-linux-hacking' about sysctl and probably when I am looking t= o=20 avoid doing work will have a go :) Alex --=20 _______________________________=20 < The early worm gets the bird. > -------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHNMzNv5Ugh/sRBYRAitDAJ0RsXTSHotVnLRUbM3yIIgo9ECaEQCgkTK+ E09rpxnE0/bhIamu/Au1a0Q= =/f86 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From alan@whirlnet.co.uk Sun Feb 1 17:09:39 2004 From: alan@whirlnet.co.uk (Alan Ford) Date: Sun, 1 Feb 2004 17:09:39 +0000 Subject: [LARTC] Private Address Routing via Tunnels Message-ID: <20040201170938.GC87073@newred.gradwell.net> Hi, I'm trying to do some horrible private address routing between networks. Is there a way to handle the following? I'm guessing policy routing *might* be the way, but anyway... Two networks, accessible via public addresses -- a /29 on each. Each network, however, has more machines than this, so one also has 192.168.0.0/24 and the other has 192.168.1.0/24. I have an IPIP tunnel between the networks -- 192.168.0.252 -> .253, and routing entries like: 192.168.0.253 * 255.255.255.255 UH 0 0 0 tunl1 192.168.1.0 192.168.0.253 255.255.255.0 UG 0 0 0 tunl1 On the other end, .252 and network 192.168.0.0 via it. My problem is routing from *public* addresses on network A to *private* addresses on network B, or vice versa. (Private <-> private is fine). I presume that the problem is that returning packets from the private address to the public address tries to send it over the wider Internet, but the packets are lost since they have private source addresses. Somehow, I need to send only packets *from* private addresses *to* public addresses on my other network back via the IPIP tunnel. Am I right in that assumption? If so, is policy routing the way to go there, or is there some other way? Thanks, Alan -- Alan Ford * alan@whirlnet.co.uk From lartc@24x7linux.com Sun Feb 1 22:10:43 2004 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Sun, 1 Feb 2004 23:10:43 +0100 Subject: [LARTC] Private Address Routing via Tunnels In-Reply-To: <20040201170938.GC87073@newred.gradwell.net> References: <20040201170938.GC87073@newred.gradwell.net> Message-ID: <20040201221043.GB8937@localhost> On Sunday, 01 February 2004, at 17:09:39 +0000, Alan Ford wrote: > My problem is routing from *public* addresses on network A to *private* > addresses on network B, or vice versa. (Private <-> private is fine). > The routing table on both gateways apply to all traffic that arrives to them, so if traffic from one gateway's private network can reach the other remote private network correctly, I think the same should happen to the public IP ranges from both networks. The IPIP tunnel should encapsulate whole packets inside newly created ones, which will be using public IP addressing, in fact the tunnel is working nice because you can reach from one private network to the other. You should try to troubleshoot the problem with the usual tools, for example ping, traceroute, "ip route get", tcpdump, ethereal, telnet, etc. Try to see the path that take your packets, maybe they are not being tunneled, maybe there is a route missing from some router, maybe just a typo prevents it from working. > Am I right in that assumption? If so, is policy routing the way to go > there, or is there some other way? > I don't think your setup needs policy routing to work ok, so first check routing tables and do some tests to see where packets go and die :-) Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.1-rc3) From damion@snapgear.com Sun Feb 1 23:09:58 2004 From: damion@snapgear.com (Damion de Soto) Date: Mon, 02 Feb 2004 09:09:58 +1000 Subject: [LARTC] Whats wrong with my script? References: <002c01c3e72d$56166a40$cd302bc8@traza> Message-ID: <401D8746.8010308@snapgear.com> Gastón wrote: > What if I use public, routable IPs? i.e eth0: public eth1: public and > client`s ips also public. Yes, you can also do that. You don't have to though, iptables marking private IP and then filtering on marks works quite fine. 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 qha@infoeq.com Mon Feb 2 02:27:49 2004 From: qha@infoeq.com (Q-ha Park) Date: Mon, 2 Feb 2004 11:27:49 +0900 Subject: [LARTC] match ip dst works, match ip dport doens't. Message-ID: <001b01c3e934$27886fd0$2a21a8c0@qha> Hi, I'm trying to limit the maximum outbound bandwidth for each destination port using "match ip dport $port 0xffff" u32 classifier. But it seems that it's not filtered by this classifier. I'm using kernel 2.4.24 with almost all filter-related options configured, and tc patched to support HTB. Below is all commands I used to configure the outbound rate. ------------------------------- $TC qdisc del dev eth0 root > /dev/null 2>&1 $TC qdisc add dev eth0 root handle 1: htb $TC class add dev eth0 parent 1: classid 1:1 htb rate $RATEmbit ceil $RATEmbit $TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport $PORT 0xffff flowid 1:1 ------------------------------- Please let me know what i'm probably doing wrong or missing. Thanks in advance. :::::::::::::::::::::::::::::::::::::::::::::::::::::: Q-ha Park From roy@xxx.lt Mon Feb 2 03:10:10 2004 From: roy@xxx.lt (Roy) Date: Mon, 2 Feb 2004 05:10:10 +0200 Subject: [LARTC] match ip dst works, match ip dport doens't. References: <001b01c3e934$27886fd0$2a21a8c0@qha> Message-ID: <00b201c3e93a$11874ac0$030aa8c0@t> > Hi, > > I'm trying to limit the maximum outbound bandwidth for each destination > port using '"'match ip dport $port 0xffff'"' u32 classifier. But it seems > that it's not filtered by this classifier. I'm using kernel 2.4.24 with > almost all filter-related options configured, and tc patched to support > HTB. > > Below is all commands I used to configure the outbound rate. > ------------------------------- > $TC qdisc del dev eth0 root > /dev/null 2>&1 > $TC qdisc add dev eth0 root handle 1: htb > $TC class add dev eth0 parent 1: classid 1:1 htb rate $RATEmbit ceil > $RATEmbit > $TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport > $PORT 0xffff flowid 1:1 > ------------------------------- Is it ALL script? since filter priorities means alot and are you sure you want to limit destination(client) ports not source(sever)? From qha@infoeq.com Mon Feb 2 04:44:30 2004 From: qha@infoeq.com (Q-ha Park) Date: Mon, 2 Feb 2004 13:44:30 +0900 Subject: [LARTC] match ip dst works, match ip dport doens't. In-Reply-To: <00b201c3e93a$11874ac0$030aa8c0@t> Message-ID: <001e01c3e947$40cc3360$2a21a8c0@qha> > [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Roy > Is it ALL script? Yes, it was just a test script to see if the port filtering works okay. What I found right after posting to the mailing list, it did work with TCP port. I added "match ip protocol 17 0xff" (UDP) to just see if it changes anything. I don't understand why it only filters TCP, it should behave the same unless I use "match ip protocol 17 0xff". It did filter "match ip dst" for both TCP and UDP. Does anyone have idea? > filter priorities means alot Hmm, I didn't know it means a lot, but does this have anything to do with port filtering? If so, what changes should I make? > and are you sure you want to limit destination(client) ports > not source(sever)? Yes, I want to limit the destination port, since the server wants to be fed at certain bitrate. (spoiled rotten) Thanks! From hare ram" Hi iam running FEDORA, i have installed Source of iptable 1.2.9 with the patch layer7-iptables patch done with out any errors and i applied patch in kernel to the layer 7 patch and i have select the required option by doing make menyconfig done make dep make bzImage make modules make modules_install make install and rebooted with customer kernel when i type iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK --set-mark 1 iptables v1.2.9: Couldn't load match `layer7':/usr/local/lib/iptables/libipt_layer7.so: cannot open shared object file: No such file or directory when i try to do manual compile, iam getting this error cc -O2 -Wall -Wunused -I/usr/src/linux-2.4.22-1.2115.nptl/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_layer7_sh.o -c extensions/libipt_layer7.c extensions/libipt_layer7.c:21:45: linux/netfilter_ipv4/ipt_layer7.h: No such file or directory extensions/libipt_layer7.c:52: warning: `struct ipt_layer7_info' declared inside parameter list extensions/libipt_layer7.c:52: warning: its scope is only this definition or declaration, which is probably not what you want extensions/libipt_layer7.c: In function `parse_protocol_file': extensions/libipt_layer7.c:84: error: `MAX_PROTOCOL_LEN' undeclared (first use in this function) extensions/libipt_layer7.c:84: error: (Each undeclared identifier is reported only once extensions/libipt_layer7.c:84: error: for each function it appears in.) extensions/libipt_layer7.c:87: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:87: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:87: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:93: error: `MAX_PATTERN_LEN' undeclared (first use in this function) extensions/libipt_layer7.c:95: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:95: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:95: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c: At top level: extensions/libipt_layer7.c:219: warning: `struct ipt_layer7_info' declared inside parameter list extensions/libipt_layer7.c: In function `parse_layer7_protocol': extensions/libipt_layer7.c:246: warning: passing arg 3 of `parse_protocol_file' from incompatible pointer type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: `MAX_PATTERN_LEN' undeclared (first use in this function) extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c: In function `parse': extensions/libipt_layer7.c:278: warning: passing arg 2 of `parse_layer7_protocol' from incompatible pointer type extensions/libipt_layer7.c:280: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c: In function `print': extensions/libipt_layer7.c:325: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:326: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c: In function `save': extensions/libipt_layer7.c:334: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c:334: error: dereferencing pointer to incomplete type extensions/libipt_layer7.c: At top level: extensions/libipt_layer7.c:340: error: invalid application of `sizeof' to an incomplete type extensions/libipt_layer7.c:341: error: invalid application of `sizeof' to an incomplete type any help will be apprciate hare From hare ram" Message-ID: <04fd01c3e963$20fea7e0$c2bf09ca@huecal> Hello sorry continuation to the last mail when make menuconfig iam not able to see this options tooo "Layer 7 match support" and "Child Level match support". but i followed the proceedures mentioned in the docs but i could not find this option where did i went wrong.. iam not sure some one guide me hare ----- Original Message ----- From: "hare ram" To: Cc: Sent: Monday, February 02, 2004 12:35 PM Subject: [LARTC] layer7-filter with iptables problem > Hi > > iam running FEDORA, > > i have installed Source of iptable 1.2.9 with the patch layer7-iptables > patch done with out any errors > > and i applied patch in kernel to the layer 7 patch > > and i have select the required option by doing > > make menyconfig > done > > make dep > make bzImage > make modules > make modules_install > make install > > and rebooted with customer kernel > > when i type > > iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j > MARK --set-mark 1 > iptables v1.2.9: Couldn't load match > `layer7':/usr/local/lib/iptables/libipt_layer7.so: cannot open shared object > file: No such file or directory > > > when i try to do manual compile, iam getting this error > > cc -O2 -Wall -Wunused -I/usr/src/linux-2.4.22-1.2115.nptl/include -Iinclude/ > -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_layer7_sh.o -c > extensions/libipt_layer7.c > > > extensions/libipt_layer7.c:21:45: linux/netfilter_ipv4/ipt_layer7.h: No such > file or directory > extensions/libipt_layer7.c:52: warning: `struct ipt_layer7_info' declared > inside parameter list > extensions/libipt_layer7.c:52: warning: its scope is only this definition or > declaration, which is probably not what you want > extensions/libipt_layer7.c: In function `parse_protocol_file': > extensions/libipt_layer7.c:84: error: `MAX_PROTOCOL_LEN' undeclared (first > use in this function) > extensions/libipt_layer7.c:84: error: (Each undeclared identifier is > reported only once > extensions/libipt_layer7.c:84: error: for each function it appears in.) > extensions/libipt_layer7.c:87: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:87: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:87: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:93: error: `MAX_PATTERN_LEN' undeclared (first > use in this function) > extensions/libipt_layer7.c:95: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:95: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:95: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c: At top level: > extensions/libipt_layer7.c:219: warning: `struct ipt_layer7_info' declared > inside parameter list > extensions/libipt_layer7.c: In function `parse_layer7_protocol': > extensions/libipt_layer7.c:246: warning: passing arg 3 of > `parse_protocol_file' from incompatible pointer type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: `MAX_PATTERN_LEN' undeclared (first > use in this function) > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:264: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c: In function `parse': > extensions/libipt_layer7.c:278: warning: passing arg 2 of > `parse_layer7_protocol' from incompatible pointer type > extensions/libipt_layer7.c:280: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c: In function `print': > extensions/libipt_layer7.c:325: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:326: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c: In function `save': > extensions/libipt_layer7.c:334: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c:334: error: dereferencing pointer to incomplete > type > extensions/libipt_layer7.c: At top level: > extensions/libipt_layer7.c:340: error: invalid application of `sizeof' to an > incomplete type > extensions/libipt_layer7.c:341: error: invalid application of `sizeof' to an > incomplete type > > > any help will be apprciate > > hare > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From arek@chelmnet.pl Mon Feb 2 08:01:41 2004 From: arek@chelmnet.pl (arek@chelmnet.pl) Date: Mon, 2 Feb 2004 09:01:41 +0100 Subject: [LARTC] Re: tc filter protocol arp question In-Reply-To: <20040131211958.GH20717@inskipp.digriz.org.uk> Message-ID: > > ). There going dhcp conversation. If missed user start to > download, entire > > network lose dhcp server becouse of dropped packets. Moment, DHCP is not arp packet. and ARP is not DHCP. DHCP is always IP addressed /check via tcpdump/ so you can mark these addresses with tc without any problems. ARP packets are low level packets of ethernet interconnectivity. They will work always, unless your LAN is overloaded or somebody will do nasty things like /arp poisoning/. The only way you can increase your network performance for arp packets is enabling broadcast storm control in layer-2 devices. Some limmitations of arp-settings in linux /proc filesystem (gc_thresh_... etc) You can neither set static arp from Server side /and client side too (more complex)/ Arkadiusz Binder From x11@h2o.pieva.net Mon Feb 2 07:55:12 2004 From: x11@h2o.pieva.net (=?windows-1257?Q?Art=FBras_=D0lajus?=) Date: Mon, 02 Feb 2004 09:55:12 +0200 Subject: [LARTC] Per Ip bandwidth In-Reply-To: <1075571713.7566.9.camel@claudiu> References: <1075571713.7566.9.camel@claudiu> Message-ID: <401E0260.30005@h2o.pieva.net> Claudiu Pruna wrote: > 1) > I have observed that if the user whois ip is going to class 1:11 has > more threads, that that fro9m class 1:12 then, there is no more fairness > in borrowing, so that user with 1:11 gets almost all the unused > bandwidth from the parent ( going up to 96Kbit/s ). well htb isn't just for this case. i would make one class and atach wrr/esfq qdisc to it. they're made esspecialy for round-robin fairness. When i used wrr i've got absolute fairness (1 or 2 bytes difference :) > 2) > why do I get " qdisc pfifo_fast 0: [Unknown qdisc, optlen=20] " at tc > qdisc ls dev eth0 right after booting the computer, without attaching > yet any qdisc ?? because there is default qdisc which is simple pfifo. From kustosz@veb.pl Mon Feb 2 09:39:55 2004 From: kustosz@veb.pl (Michal Kustosik) Date: Mon, 2 Feb 2004 10:39:55 +0100 Subject: [LARTC] limiting p2p In-Reply-To: References: Message-ID: <20040202093955.GA5450@veb.pl> On Fri, Nov 07, 2003 at 12:27:25PM -0300, ThE PhP_KiD wrote: > Hi List ! > > I'm trying excelent module ipt_p2p from Filipe > Almeida in a Linux Box with several connections, > in order to block p2p traffic with next rule: > [...] > how ever, I've noted that after two days running, > that Linux Box (RH 7,2 updated - Kernel 2.4.22 > - iptables 1.2.8 with String and ConnMark modules, > Pentium 4, 1.8 Mhz, 256 Mgbytes RAM, and 3c509 eth0, > eth1 and eth2), > begins to drop others packets and a simple ping > look like this: > > > # ping 192.168.210.3 (by example) > > PING 192.168.210.3 (192.168.210.3) from 192.168.210.254 : 56(84) bytes of > data. > 64 bytes from 192.168.210.3: icmp_seq=0 ttl=64 time=499 usec > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > 64 bytes from 192.168.210.3: icmp_seq=1 ttl=64 time=478 usec > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > 64 bytes from 192.168.210.3: icmp_seq=2 ttl=64 time=489 usec > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > Hi! I have the same problem... Have you solved it? I can't see any answer for your email :( best -- michal From alex-lartc@digriz.org.uk Mon Feb 2 10:12:49 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Mon, 2 Feb 2004 10:12:49 +0000 Subject: [LARTC] Re: tc filter protocol arp question In-Reply-To: References: <20040131211958.GH20717@inskipp.digriz.org.uk> Message-ID: <20040202101249.GA3072@inskipp.digriz.org.uk> --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Feb 02, arek@chelmnet.pl wrote: >=20 > Moment, DHCP is not arp packet. > and ARP is not DHCP. >=20 however every dhcp request fires off a bunch of ARP requests. I am=20 suggesting using DHCP-relay so you put the 'long distance' DHCP requests in= to=20 a kind of IP tunnel (?). If this is not true then you could accomplish the= =20 same with IPSec/ssh tunnels. The idea of this is to shunt the DHCP (and=20 related traffic) into something that is managable. > DHCP is always IP addressed /check via tcpdump/ > so you can mark these addresses with tc without any problems. > good point :) =20 > ARP packets are low level packets of ethernet interconnectivity. > They will work always, unless your LAN is overloaded or somebody will do > nasty things like /arp poisoning/. > The only way you can increase your network performance for arp packets is > enabling broadcast storm control in layer-2 devices. > Some limmitations of arp-settings in linux /proc filesystem (gc_thresh_... > etc) > You can neither set static arp from Server side /and client side too (more > complex)/ >=20 I would still be keen on shunting things into a managable IP(Sec)/ssh tunne= l,=20 although it sounds overboard, if you are dealing with thousands of PC's (ev= en=20 hundreds) thats likely to cross several subnets. As I mentioned before it would give you the infrastructure to have=20 'maintainence' tunnel, you could put all the insecure telnet traffic in thi= s=20 tunnel to prevent it crossing the whole distance un-encrypted :) More so y= ou=20 can give it a high priority which would help you get access to machines whe= n=20 you need to during a crisis. Regards Alex --=20 __________________________________=20 / A likely impossibility is always \ | preferable to an unconvincing | | possibility. | | | \ -- Aristotle / ----------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHiKhNv5Ugh/sRBYRAmvqAJ9s6Eyri2aeUCdXm013EfX50au8egCfXFc6 a866KUWiIPNgbKbjrcs20Ks= =s1TP -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From boka@sto-procent.art.pl Mon Feb 2 10:26:09 2004 From: boka@sto-procent.art.pl (boka) Date: Mon, 02 Feb 2004 11:26:09 +0100 Subject: [LARTC] configuration question Message-ID: <401E25C1.9010703@sto-procent.art.pl> Hi ! I have working qos configuration made with htb, imq, imqnat, iptables, nat etc. I'm thinking over how to shape incoming and outgoing traffic, not using all not maintaind patches for kernel, iptables etc. What do You think about below conf.: INTERNET -- NAT_BOX -- QoS_BOX -- LAN On QoS_BOX - iptables marking, htb and IMQ Do You know some other solutions ? greetz boka From eddieknows@ananzi.co.za Mon Feb 2 10:14:25 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Mon, 02 Feb 2004 12:14:25 +0200 Subject: [LARTC] limiting p2p In-Reply-To: <20040202093955.GA5450@veb.pl> References: <20040202093955.GA5450@veb.pl> Message-ID: <1075716864.1984.28.camel@testbox.co.za> Ok What I did was blocking all forwarding,in and out, traffic on my gateway with iptables.Only allowing establish related traffic in and out ports thy use,80,25,110 ens.This will stop it connecting to a weard port Now the thing about kazaa is the after it tryed all 65XXXXXXX ports it will try in port 80,this can take a while and the stoopid user will have close it Now what you do is setup a transparent proxy with iptables and squid.On squid you create acl's to stop .mp3 and .wav ens. files And .dat files,wat kazaa uses. Now this worked for me. On Mon, 2004-02-02 at 11:39, Michal Kustosik wrote: > *This message was transferred with a trial version of CommuniGate(tm) Pro* > On Fri, Nov 07, 2003 at 12:27:25PM -0300, ThE PhP_KiD wrote: > > Hi List ! > > > > I'm trying excelent module ipt_p2p from Filipe > > Almeida in a Linux Box with several connections, > > in order to block p2p traffic with next rule: > > > [...] > > > how ever, I've noted that after two days running, > > that Linux Box (RH 7,2 updated - Kernel 2.4.22 > > - iptables 1.2.8 with String and ConnMark modules, > > Pentium 4, 1.8 Mhz, 256 Mgbytes RAM, and 3c509 eth0, > > eth1 and eth2), > > begins to drop others packets and a simple ping > > look like this: > > > > > > # ping 192.168.210.3 (by example) > > > > PING 192.168.210.3 (192.168.210.3) from 192.168.210.254 : 56(84) bytes of > > data. > > 64 bytes from 192.168.210.3: icmp_seq=0 ttl=64 time=499 usec > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > 64 bytes from 192.168.210.3: icmp_seq=1 ttl=64 time=478 usec > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > 64 bytes from 192.168.210.3: icmp_seq=2 ttl=64 time=489 usec > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > > > Hi! > > I have the same problem... Have you solved it? > I can't see any answer for your email :( > > best From eddieknows@ananzi.co.za Mon Feb 2 11:19:46 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Mon, 02 Feb 2004 13:19:46 +0200 Subject: [LARTC] adsl on/off Message-ID: <1075720786.1984.43.camel@testbox.co.za> Good day all Now I'm from South-Africa,here we have adsl router/modems You set the router to do the dialup and authentication and the set it as your gateways box's gateway.Now sometimes the links gets drop and is off for a while.Are there any way,for linux,my gateway of letting me now that the link was/is down.Note that the box is not dialing so there is no adsl-status. What I NEED to do it be able to know if the link is down,and if the link is down use a modem dialup and when the link get back up stop the modem.Any Ideas Thanks From gomi@perezoso.net Mon Feb 2 11:22:32 2004 From: gomi@perezoso.net (GoMi) Date: Mon, 2 Feb 2004 12:22:32 +0100 Subject: [LARTC] adsl on/off In-Reply-To: <1075720786.1984.43.camel@testbox.co.za> Message-ID: Read the Nano-howto, yo might find some info...Thats only for multipath gateways, but... :) -----Mensaje original----- De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En nombre de Eddie Enviado el: lunes, 02 de febrero de 2004 12:20 Para: lartc Asunto: [LARTC] adsl on/off Good day all Now I'm from South-Africa,here we have adsl router/modems You set the router to do the dialup and authentication and the set it as your gateways box's gateway.Now sometimes the links gets drop and is off for a while.Are there any way,for linux,my gateway of letting me now that the link was/is down.Note that the box is not dialing so there is no adsl-status. What I NEED to do it be able to know if the link is down,and if the link is down use a modem dialup and when the link get back up stop the modem.Any Ideas Thanks _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From kustosz@veb.pl Mon Feb 2 11:30:54 2004 From: kustosz@veb.pl (Michal Kustosik) Date: Mon, 2 Feb 2004 12:30:54 +0100 Subject: [LARTC] limiting p2p In-Reply-To: <1075716864.1984.28.camel@testbox.co.za> References: <20040202093955.GA5450@veb.pl> <1075716864.1984.28.camel@testbox.co.za> Message-ID: <20040202113052.GA12174@veb.pl> On Mon, Feb 02, 2004 at 12:14:25PM +0200, Eddie wrote: > Ok > What I did was blocking all forwarding,in and out, traffic on my gateway > with iptables.Only allowing establish related traffic in and out ports > thy use,80,25,110 ens.This will stop it connecting to a weard port > Now the thing about kazaa is the after it tryed all 65XXXXXXX ports it > will try in port 80,this can take a while and the stoopid user will have > close it > Now what you do is setup a transparent proxy with iptables and squid.On > squid you create acl's to stop .mp3 and .wav ens. files > And .dat files,wat kazaa uses. > Now this worked for me. > ok ;) I have done the same some times ago ;) But I'm interesting what is wrong with ipt_p2p or someting, that icmp works bad when using ipt_p2p... Anybody known ?!? Have anybody run ipt_p2p with no problems ? best... -- michal > > On Mon, 2004-02-02 at 11:39, Michal Kustosik wrote: > > *This message was transferred with a trial version of CommuniGate(tm) Pro* > > On Fri, Nov 07, 2003 at 12:27:25PM -0300, ThE PhP_KiD wrote: > > > Hi List ! > > > > > > I'm trying excelent module ipt_p2p from Filipe > > > Almeida in a Linux Box with several connections, > > > in order to block p2p traffic with next rule: > > > > > [...] > > > > > how ever, I've noted that after two days running, > > > that Linux Box (RH 7,2 updated - Kernel 2.4.22 > > > - iptables 1.2.8 with String and ConnMark modules, > > > Pentium 4, 1.8 Mhz, 256 Mgbytes RAM, and 3c509 eth0, > > > eth1 and eth2), > > > begins to drop others packets and a simple ping > > > look like this: > > > > > > > > > # ping 192.168.210.3 (by example) > > > > > > PING 192.168.210.3 (192.168.210.3) from 192.168.210.254 : 56(84) bytes of > > > data. > > > 64 bytes from 192.168.210.3: icmp_seq=0 ttl=64 time=499 usec > > > ping: sendto: Operation not permitted > > > ping: sendto: Operation not permitted > > > ping: sendto: Operation not permitted > > > 64 bytes from 192.168.210.3: icmp_seq=1 ttl=64 time=478 usec > > > ping: sendto: Operation not permitted > > > ping: sendto: Operation not permitted > > > 64 bytes from 192.168.210.3: icmp_seq=2 ttl=64 time=489 usec > > > ping: sendto: Operation not permitted > > > ping: sendto: Operation not permitted > > > ping: sendto: Operation not permitted > > > > > > > Hi! > > > > I have the same problem... Have you solved it? > > I can't see any answer for your email :( > > > > best > From alan@whirlnet.co.uk Mon Feb 2 11:26:48 2004 From: alan@whirlnet.co.uk (Alan Ford) Date: Mon, 2 Feb 2004 11:26:48 +0000 Subject: [LARTC] Private Address Routing via Tunnels In-Reply-To: <20040201221043.GB8937@localhost> References: <20040201170938.GC87073@newred.gradwell.net> <20040201221043.GB8937@localhost> Message-ID: <20040202112648.GD87073@newred.gradwell.net> On Sun, Feb 01, 2004 at 11:10:43PM +0100, Jose Luis Domingo Lopez wrote: > On Sunday, 01 February 2004, at 17:09:39 +0000, > Alan Ford wrote: > > > My problem is routing from *public* addresses on network A to *private* > > addresses on network B, or vice versa. (Private <-> private is fine). > > The routing table on both gateways apply to all traffic that arrives to > them, so if traffic from one gateway's private network can reach the > other remote private network correctly, I think the same should happen > to the public IP ranges from both networks. I've now done some packet sniffing to confirm what I suggested in my first mail. The packets get there OK, but responses don't come back. They can route from the public to the private blocks, because they get to the router and the router knows to send it down the IPIP tunnel. But how can I configure the router at the other end to know to send responses from the private block to the public block down the tunnel? I think that's what I am needing to do here, does that make sense? Thanks, Alan -- Alan Ford * alan@whirlnet.co.uk From adi@nobugconsulting.ro Mon Feb 2 11:37:58 2004 From: adi@nobugconsulting.ro (Adrian Coman) Date: Mon, 02 Feb 2004 13:37:58 +0200 Subject: [LARTC] HTB_Tool In-Reply-To: <20040130105248.GA20240@tretmine.org> References: <401A172C.1060807@nobugconsulting.ro> <20040130105248.GA20240@tretmine.org> Message-ID: <401E3696.9090807@nobugconsulting.ro> Yes, it compiled OK for me on RH 7.3 Alexander Reelsen wrote: > On Fri, Jan 30, 2004 at 10:34:52AM +0200, Adrian Coman wrote: > >>The webpage is in Romanian ... but one can understand from the >>configuration examples avaiable on the webpage and in the >>http://sgi.rdscv.ro/~ionuts/htb-tools/htb_util-0.2.4-pre1_cv-1_quantum-1536-sin.tar.bz2 >>archive. > > Does it compile for you? I get some lex error which I can't debug due to > time issues on my Debian sid workstation... > > > MfG/Regards, Alexander > From Simon.Heywood@thalesgroup.com Mon Feb 2 12:05:02 2004 From: Simon.Heywood@thalesgroup.com (Heywood, Simon ) Date: Mon, 2 Feb 2004 12:05:02 -0000 Subject: [LARTC] FW: QoS extension to Net-SNMP Message-ID: <51BF576D5A02CC4CB2591F50994FD766511AA4@nts013.uk.trt.thales> Michal Charvat wrote: > But as I see yours output.... I have one question. Do you have x86 > platform? I didn't try that on other than x86 and there can be > problem with __u32 interpretation. No, it's all x86. Anyway, I think I've solved the problem - the numbers I've got out of SNMP and converted to major:minor values are in base 10, whereas tc apparently uses hexadecimal for class IDs. Of course, no-one bothered to tell me this when I was introduced to tc. :-) (Thanks to Stef Coene for unwittingly pointing this out to me via his scripts.) S. From gregoriandres@yahoo.com.ar Mon Feb 2 18:27:39 2004 From: gregoriandres@yahoo.com.ar (ThE PhP_KiD) Date: Mon, 2 Feb 2004 15:27:39 -0300 Subject: [LARTC] limiting p2p In-Reply-To: <20040202113052.GA12174@veb.pl> Message-ID: Hi Michal. Now I'm testing ipt_ipp2p netfilter 3rd module You can reach it at: http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html At the momment I've not problems with it. (It's works well) But I haven't tested ipt_ipp2p module strongly with a large LAN regards Andres. -> ok ;) I have done the same some times ago ;) -> -> But I'm interesting what is wrong with ipt_p2p or someting, that -> icmp works bad when using ipt_p2p... Anybody known ?!? -> Have anybody run ipt_p2p with no problems ? -> -> best... -> -- -> michal From gregoriandres@yahoo.com.ar Mon Feb 2 23:03:19 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Mon, 2 Feb 2004 20:03:19 -0300 Subject: [LARTC] IMQ update ? Message-ID: Hello I'm trying the excelent IMQ patch for iptbles and kernel 2.4.21 and works very well... but, there is a IMQ patch for 2.4.24 ? I've tested IMQ for kernels > 2,4,21 but patch fails ! Best regards andres From gregoriandres@yahoo.com.ar Tue Feb 3 00:01:34 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Mon, 2 Feb 2004 21:01:34 -0300 Subject: [LARTC] limiting p2p In-Reply-To: <000201c3e9e1$c0ee9340$510000ac@dejawu> Message-ID: Interesante !! lo probaste con 2.4 ? o 2.6 ? -> -----Mensaje original----- -> De: Esteban Ribicic [mailto:esteban@dejawu.com.ar] -> Enviado el: Lunes, 02 de Febrero de 2004 08:11 p.m. -> Para: 'ThE PhP_KiD' -> Asunto: RE: [LARTC] limiting p2p -> -> -> Probaste layering 7 matching? -> -> -> -----Mensaje original----- -> De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En -> nombre de ThE PhP_KiD -> Enviado el: Monday, February 02, 2004 3:28 PM -> Para: lartc; Michal Kustosik -> Asunto: RE: [LARTC] limiting p2p -> -> -> Hi Michal. -> -> Now I'm testing ipt_ipp2p netfilter 3rd module -> You can reach it at: -> http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html -> -> At the momment I've not problems with it. -> (It's works well) -> -> But I haven't tested ipt_ipp2p module strongly -> with a large LAN -> -> regards -> -> Andres. -> -> -> -> ok ;) I have done the same some times ago ;) -> -> -> -> But I'm interesting what is wrong with ipt_p2p or someting, that icmp -> -> -> works bad when using ipt_p2p... Anybody known ?!? Have anybody run -> -> ipt_p2p with no problems ? -> -> -> -> best... -> -> -- -> -> michal -> -> _______________________________________________ -> LARTC mailing list / LARTC@mailman.ds9a.nl -> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -> -> From gregoriandres@yahoo.com.ar Tue Feb 3 00:03:24 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Mon, 2 Feb 2004 21:03:24 -0300 Subject: [LARTC] Jim diGriz's QoS Script Message-ID: Hi sombody know what is happen with Jim diGriz's QoS Script Web Page ? www.digriz.org.uk/jdg-qos-script Regards From alex-lartc@digriz.org.uk Tue Feb 3 00:13:06 2004 From: alex-lartc@digriz.org.uk (Alexander Clouter) Date: Tue, 3 Feb 2004 00:13:06 +0000 Subject: [LARTC] Jim diGriz's QoS Script In-Reply-To: References: Message-ID: <20040203001306.GC13196@inskipp.digriz.org.uk> --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Well its being maintained by me if that what you are asking :) However most of the people here 'poo-poo' it so do not expect much help fro= m=20 them :-/ So much for my contibution to the OSS world....pah...every man to= =20 themselves. /me goes back to his ppp-pipe have fun Alex On Feb 02, ThE LinuX_KiD wrote: >=20 > Hi >=20 > sombody know what is happen with=20 > Jim diGriz's QoS Script Web Page ? >=20 > www.digriz.org.uk/jdg-qos-script >=20 > Regards >=20 >=20 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --=20 __________________________________=20 < Flee at once, all is discovered. > ----------------------------------=20 \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHueSNv5Ugh/sRBYRAoPBAJwLnpXGZR8gNWi30c1HXhSsSth7fQCeJsBD 6D2d57Q8PWpxAEgqNsoI58Y= =JjZq -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- From lartc@24x7linux.com Tue Feb 3 00:19:16 2004 From: lartc@24x7linux.com (Jose Luis Domingo Lopez) Date: Tue, 3 Feb 2004 01:19:16 +0100 Subject: [LARTC] Private Address Routing via Tunnels In-Reply-To: <20040202112648.GD87073@newred.gradwell.net> References: <20040201170938.GC87073@newred.gradwell.net> <20040201221043.GB8937@localhost> <20040202112648.GD87073@newred.gradwell.net> Message-ID: <20040203001916.GB10578@localhost> On Monday, 02 February 2004, at 11:26:48 +0000, Alan Ford wrote: > They can route from the public to the private blocks, because they get to > the router and the router knows to send it down the IPIP tunnel. But how > can I configure the router at the other end to know to send responses > from the private block to the public block down the tunnel? I think that's > what I am needing to do here, does that make sense? > Traditional routing is always based solely on the destination IP address of packages arriving at a router. With Linux policy routing you can route based on both destination and source IP address, and based on more parameters, for example, any parameter selectable via iptables. The router on the other end already has a working routing table based on both information from IP addresses for each interface and static routes you should have added manually. If the router on the other end doesn't know how to route packets back to the other router , then the routing table on the distant router is not correct. As the two internal networks are far away and connected by a tunnel using public IP addressing, I guess what is missing in the remote router is a route that sends traffic directed to the other private network through the tunnel. Exactly the same you seem to have done on your "local" router to make traffic directed to the remote LAN be encapsulated through the IPIP tunnel. Just for completeness, in this setup I don't think policy routing (based on source IP addresses) is the correct way to handle the problem. Greetings. -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.2-bk3) From andy.furniss@dsl.pipex.com Tue Feb 3 01:18:16 2004 From: andy.furniss@dsl.pipex.com (Andy Furniss) Date: Tue, 03 Feb 2004 01:18:16 +0000 Subject: [LARTC] Jim diGriz's QoS Script In-Reply-To: <20040203001306.GC13196@inskipp.digriz.org.uk> References: <20040203001306.GC13196@inskipp.digriz.org.uk> Message-ID: <401EF6D8.1030107@dsl.pipex.com> Alexander Clouter wrote: > Well its being maintained by me if that what you are asking :) > > However most of the people here 'poo-poo' it so do not expect much help from > them :-/ So much for my contibution to the OSS world....pah...every man to > themselves. How could they :-) To LinuX_Kid Re your imq post - if you use the patches in alexanders' binaries package you only have to change the first one slightly (IIRC) - anyway I'm using the first four on 2.4.24 now - I don't know about the p2p one. I don't use it as it needs connmark and I wanted to play with connbytes, and they don't get on. These work for me. www.jessingale.dsl.pipex.com/01_linux-2.4.24-imq-1.diff www.jessingale.dsl.pipex.com/02_netfilter-imq-patch-2.4.24.diff www.jessingale.dsl.pipex.com/03_linux-2.4.24-imq-nat-support.diff www.jessingale.dsl.pipex.com/04_linux-2.4.24-esfq.diff I think I only changed 01 so they are basically alexanders' with the numbers changed :-) I managed to get esfq to head drop - but that's the normal one, I am still waiting for mine to go bang, which it probably will soon. There's going to be an imq site and sf page soon, also roy has a rewritten version. There's a different patch for 2.4.24 here http://imq.hiperlinks.com.br/ I didn't have to do that much, which is a bit worrying :-) Andy. From markryan@cfl.rr.com Tue Feb 3 02:51:35 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Mon, 2 Feb 2004 21:51:35 -0500 Subject: [LARTC] wondershaper Message-ID: <001301c3ea00$a3d59910$6501a8c0@underworld> Hi, I just installed wondershapper 1.1a on my ipcop firewall box. I have roadrunner cable with a ftp server setup. My download speed is 2mbit (I get 225 KBytes) and my upload is 384kbit (I send at 43 KBytes). What should the settings in wshaper? I can ping yahoo.com at 90msec with little traffic.....and at around 220msec with full upload traffic. Mark From hare ram" <200402030308.02789.admin@osmium-work.com> Message-ID: <027101c3ea1e$eeaadf40$c2bf09ca@huecal> Hi thanks for the quick reply iam using the following things iptables-1.2.9-layer7-0.4.1.patch layer7-kernel2.4patch-qos-0.4.1b i did the proceedure [root@pdn linux-2.4.22-1.2115.nptl]# patch -p1 < /root/update/layer7-kernel2.4patch-qos-0.4.1b patching file Documentation/Configure.help Hunk #1 succeeded at 10626 (offset 283 lines). patching file include/linux/netfilter_ipv4/ip_conntrack.h Hunk #1 succeeded at 190 (offset 1 line). patching file include/linux/pkt_cls.h patching file net/ipv4/netfilter/Config.in patching file net/sched/Config.in patching file net/sched/Makefile patching file net/sched/cls_api.c patching file net/sched/cls_layer7.c patching file net/sched/regexp/regerror.c patching file net/sched/regexp/regexp.c patching file net/sched/regexp/regexp.h patching file net/sched/regexp/regmagic.h patching file net/sched/regexp/regsub.c [root@pdn linux-2.4.22-1.2115.nptl]# [root@pdn linux-2.4.22-1.2115.nptl]# iptables patching [root@pdn iptables-1.2.9]# patch -p1 < ../iptables-1.2.9-layer7-0.4.1.patch.1 patching file extensions/.childlevel-test patching file extensions/.layer7-test patching file extensions/libipt_childlevel.c patching file extensions/libipt_layer7.c patching file iptables.8 chmod +x extensions/.layer7-test extensions/.childlevel-test make KERNEL_DIR=/usr/src/linux-2.4.22-1.2115.nptl make install KERNEL_DIR=/usr/src/linux-2.4.22-1.2115.nptl iam not able to find the ipt_layer.h file and iam not able to see the menus in when i make .. make menuconfig hare ----- Original Message ----- From: "Nabil SEFRIOUI" To: "hare ram" ; Cc: Sent: Tuesday, February 03, 2004 8:38 AM Subject: Re: [LARTC] layer7-filter with iptables problem try patching and installing kernel before iptables Le Lundi 02 Février 2004 07:05, hare ram a écrit : > Hi > > iam running FEDORA, > > i have installed Source of iptable 1.2.9 with the patch > layer7-iptables patch done with out any errors > > and i applied patch in kernel to the layer 7 patch > > and i have select the required option by doing > > make menyconfig > done > > make dep > make bzImage > make modules > make modules_install > make install > > and rebooted with customer kernel > > when i type > > iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j > MARK --set-mark 1 > iptables v1.2.9: Couldn't load match > `layer7':/usr/local/lib/iptables/libipt_layer7.so: cannot open shared > object file: No such file or directory > > > when i try to do manual compile, iam getting this error > > cc -O2 -Wall -Wunused -I/usr/src/linux-2.4.22-1.2115.nptl/include > -Iinclude/ -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o > extensions/libipt_layer7_sh.o -c extensions/libipt_layer7.c > > > extensions/libipt_layer7.c:21:45: linux/netfilter_ipv4/ipt_layer7.h: > No such file or directory > extensions/libipt_layer7.c:52: warning: `struct ipt_layer7_info' > declared inside parameter list > extensions/libipt_layer7.c:52: warning: its scope is only this > definition or declaration, which is probably not what you want > extensions/libipt_layer7.c: In function `parse_protocol_file': > extensions/libipt_layer7.c:84: error: `MAX_PROTOCOL_LEN' undeclared > (first use in this function) > extensions/libipt_layer7.c:84: error: (Each undeclared identifier is > reported only once > extensions/libipt_layer7.c:84: error: for each function it appears > in.) extensions/libipt_layer7.c:87: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:87: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:87: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:93: error: `MAX_PATTERN_LEN' undeclared > (first use in this function) > extensions/libipt_layer7.c:95: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:95: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:95: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c: At top level: > extensions/libipt_layer7.c:219: warning: `struct ipt_layer7_info' > declared inside parameter list > extensions/libipt_layer7.c: In function `parse_layer7_protocol': > extensions/libipt_layer7.c:246: warning: passing arg 3 of > `parse_protocol_file' from incompatible pointer type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: `MAX_PATTERN_LEN' undeclared > (first use in this function) > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:264: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c: In function `parse': > extensions/libipt_layer7.c:278: warning: passing arg 2 of > `parse_layer7_protocol' from incompatible pointer type > extensions/libipt_layer7.c:280: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c: In function `print': > extensions/libipt_layer7.c:325: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:326: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c: In function `save': > extensions/libipt_layer7.c:334: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c:334: error: dereferencing pointer to > incomplete type > extensions/libipt_layer7.c: At top level: > extensions/libipt_layer7.c:340: error: invalid application of > `sizeof' to an incomplete type > extensions/libipt_layer7.c:341: error: invalid application of > `sizeof' to an incomplete type > > > any help will be apprciate > > hare > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > http://lartc.org/ -- __________________________________ Osmium Work - Ingénierie Open Source http://www.osmium-work.com/ From hare ram" <014d01c3e998$49b056e0$c2bf09ca@huecal> Message-ID: <029301c3ea20$6ed965a0$c2bf09ca@huecal> Hi Mathew I was not understand is that what you saying I need to use any one of the Patch iptables-1.2.9-layer7-0.4.1.patch This above patch for Marking the Packets with Iptables right ? layer7-kernel2.4patch-qos-0.4.1b this Patch is for TC to work with layer 7 aplication so what did iam doing wrong ok take example, i re did my setup like below extract new kernel extract iptables source extract pom i have just patched only iptables with layer7 patch (iptables-1.2.9-layer7-0.4.1.patch) then i patched kernel with POM make mrproper make menuconfig ------ here iam not able to see that optiond what mentioned in the docs ("Layer 7 match support" and "Child Level match support". ) make dep make bzImage make modules make modules_install make install rebooted with new kernel iam not able to mark pacjets using iptables iam getting the following error iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK --set-mark 1 iptables v1.2.9: Couldn't load match layer7':/usr/local/lib/iptables/libipt_layer7.so: cannot open shared object file: No such file or directory when i try to compile manually, iam geeting the ipt_layer7.h not found. cc -O2 -Wall -Wunused -I/usr/src/linux-2.4.22-1.2115.nptl/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_layer7_sh.o -c extensions/libipt_layer7.c extensions/libipt_layer7.c:21:45: linux/netfilter_ipv4/ipt_layer7.h: No such file or directory extensions/libipt_layer7.c:52: warning: `struct ipt_layer7_info' declared inside parameter list extensions/libipt_layer7.c:52: warning: its scope is only this definition or declaration, which is probably not what you want extensions/libipt_layer7.c: In function `parse_protocol_file': extensions/libipt_layer7.c:84: error: `MAX_PROTOCOL_LEN' undeclared (first use in this function) any suggestion or any proceedure iam doing correct me give me the right proceedure hare ----- Original Message ----- From: "Matthew Strait" To: "hare ram" Cc: ; ; Sent: Monday, February 02, 2004 8:17 PM Subject: Re: where is ipt_layer.h > > i am using the following things > > > > iptables-1.2.9-layer7-0.4.1.patch > > layer7-kernel2.4patch-qos-0.4.1b > > You are using the QoS version of the kernel patch and the Netfilter > (iptables) version of the userspace patch. You need to either use QoS > with iproute2 or Netfilter with iptables. > > -matthew > > From qha@infoeq.com Tue Feb 3 07:35:24 2004 From: qha@infoeq.com (Q-ha Park) Date: Tue, 3 Feb 2004 16:35:24 +0900 Subject: [LARTC] port filtering for UDP packets? In-Reply-To: <029301c3ea20$6ed965a0$c2bf09ca@huecal> Message-ID: <005501c3ea28$49f61000$2a21a8c0@qha> This is what I did to filter outbound UDP packets with the desination port number 6003 thru HTB queue 1:1. tc filter add dev eth0 parent 1: protocol ip prio 1 \ u32 match ip dport 6003 0xffff flowid 1:1 However, it only worked for TCP port, not UDP. Does anyone know why this happens and how to solve it? Your help would be greatly appreciated.. thanks in advance! Q-ha Park From raptor@tvskat.net Tue Feb 3 13:10:24 2004 From: raptor@tvskat.net (raptor) Date: Tue, 3 Feb 2004 15:10:24 +0200 Subject: [LARTC] port filtering for UDP packets? In-Reply-To: <005501c3ea28$49f61000$2a21a8c0@qha> References: <029301c3ea20$6ed965a0$c2bf09ca@huecal> <005501c3ea28$49f61000$2a21a8c0@qha> Message-ID: <20040203151024.030dbb13@bugs.tvskat.net> opsi... i dont want u32 filter I need libpcap(tcpdump) expression so that i can watch to which direction these stuff goes from/to which address... et cetera.. |This is what I did to filter outbound UDP packets with the desination |port number 6003 thru HTB queue 1:1. | |tc filter add dev eth0 parent 1: protocol ip prio 1 \ |u32 match ip dport 6003 0xffff flowid 1:1 | |However, it only worked for TCP port, not UDP. Does anyone know why this |happens and how to solve it? | |Your help would be greatly appreciated.. thanks in advance! | |Q-ha Park | | | |_______________________________________________ |LARTC mailing list / LARTC@mailman.ds9a.nl |http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | From andre.correa@pobox.com Tue Feb 3 12:55:51 2004 From: andre.correa@pobox.com (Andre Correa) Date: Tue, 03 Feb 2004 10:55:51 -0200 Subject: [LARTC] IMQ update ? In-Reply-To: References: Message-ID: <401F9A57.5020301@pobox.com> Hi Andres, there is a patch for 2.4.24 available at www.linuximq.net ... have a try on it and please let us know if you have any trouble using it. tks Andre ThE LinuX_KiD wrote: > Hello > > I'm trying the excelent IMQ patch for > iptbles and kernel 2.4.21 and works > very well... > > but, there is a IMQ patch for 2.4.24 ? > > I've tested IMQ for kernels > 2,4,21 but > patch fails ! > > Best regards > andres > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > From gregoriandres@yahoo.com.ar Tue Feb 3 15:22:31 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Tue, 3 Feb 2004 12:22:31 -0300 Subject: [LARTC] IMQ update ? In-Reply-To: <401F9A57.5020301@pobox.com> Message-ID: Hi, I've patched 2.4.24 with IMQ successfully !! thank you Andres -> -----Mensaje original----- -> De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]En -> nombre de Andre Correa -> Enviado el: Martes, 03 de Febrero de 2004 09:56 a.m. -> Para: ThE LinuX_KiD -> CC: lartc -> Asunto: Re: [LARTC] IMQ update ? -> -> -> -> Hi Andres, there is a patch for 2.4.24 available at www.linuximq.net ... -> have a try on it and please let us know if you have any trouble using it. -> -> tks -> -> Andre -> -> -> ThE LinuX_KiD wrote: -> > Hello -> > -> > I'm trying the excelent IMQ patch for -> > iptbles and kernel 2.4.21 and works -> > very well... -> > -> > but, there is a IMQ patch for 2.4.24 ? -> > -> > I've tested IMQ for kernels > 2,4,21 but -> > patch fails ! -> > -> > Best regards -> > andres -> > _______________________________________________ -> > 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 Aron@sofaware.com Tue Feb 3 17:08:17 2004 From: Aron@sofaware.com (Aron Brand) Date: Tue, 3 Feb 2004 19:08:17 +0200 Subject: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs Message-ID: <50F73B338A7FD943B7937BBCF99BFBDE33B6C7@mail.sofaware.com> Hi Martin, The scenario I am working on is the second one - there is one internal network and two ISPs. How can I do fwmark based on the outgoing interface? Remember that there is just one physical WAN interface, with two IP addresses. Is it possible to fwmark somehow based on the routing decision? Thanks Aron -----Original Message----- From: Martin A. Brown [mailto:mabrown-lartc@securepipe.com]=20 Sent: Friday, January 30, 2004 12:00 AM To: Aron Brand Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs Aron, : If I understand whay you are suggesting, there is a problem in your : design: It will only work if you use Hide NAT. ...and multiple public IPs. : The problem is that the ip_src =3D=3D IP0 rule is wrong: The ip_src = is not : changed by the router and it is not equal to the IP of any of the : machine interfaces. OK--maybe the 'ip_src =3D=3D IP0' rule is not applicable to your = situation, but that doesn't make it wrong. You describe a different network configuration than I was envisioning based on Gordan's description. : Can you think of a solution that will work in the following reasonable : scenario: I can try! : Lets say I have two T1 internet connections connected to one ethernet : interface. I do not use Hide-NAT. I want to guarantee at least 512kbps : to HTTP traffic on each line (separately) in the 'virtual circuit' : method that you mentioned. Are you pushing different networks across each T1? If you have Network-A from ISP-A and Network-B from ISP-B, then you have different addresses to use in your configuration. See an untested configuration with some fabricated addresses and netmasks below. #define NETA 216.109.118.64 #define NETAMASK 28 #define NETB 63.209.4.192 #define NETBMASK 27 dev eth0 { egress { class ( <$neta> ) if ip_src:NETAMASK =3D=3D NETA/NETAMASK ; class ( <$netb> ) if ip_src:NETBMASK =3D=3D NETB/NETBMASK ; htb () { $neta =3D class ( rate 512kbps, ceil 512kbps ) ; $netb =3D class ( rate 512kbps, ceil 512kbps ) ; } } } I would think this should provide a skeleton configuration for limiting outbound (transmitted) traffic originating from separate IP networks on the same host. : I see no way do do this unless I can attach a qdisc to a specific : virtual interface. If you are using a single IP network and you have two different providers (you're using BGP or similar), then you could consider marking the packets (fwmark) based on outgoing interface, and perform traffic control based on this mechanism. These are just some thoughts based on how I interpret your description of your network. Good luck, -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From alan@whirlnet.co.uk Tue Feb 3 17:41:06 2004 From: alan@whirlnet.co.uk (Alan Ford) Date: Tue, 3 Feb 2004 17:41:06 +0000 Subject: [LARTC] iproute2 and ethX:X subdevices Message-ID: <20040203174106.GI87073@newred.gradwell.net> Hi, Quick question -- is it possible to create eth0:0 - style psuedo-devices using the 'ip' tool? I see they recognise them when using 'ip addr show': 5: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 inet 192.168.0.1/24 brd 192.168.0.255 scope global eth2:0 But I can't see a way of creating them. Is it possible? (I know somebody may say "why would I want to" -- it's just for neatness, so that people using 'ifconfig' can still see all the addresses in use.) Thanks, -- Alan Ford * alan@whirlnet.co.uk From andybr@bol.com.br Tue Feb 3 17:47:42 2004 From: andybr@bol.com.br (andybr) Date: Tue, 3 Feb 2004 15:47:42 -0200 Subject: [LARTC] adsl on/off Message-ID: Hi, Try to look in your modem userguide if it is capable to do it. []'s Anderson > Good day all > Now I'm from South- Africa,here we have adsl router/modems > You set the router to do the dialup and authentication and the set it as > your gateways box's gateway.Now sometimes the links get s drop and is off > for a while.Are there any way,for linux,my gateway of l etting me now > that the link was/is down.Note that the box is not dial ing so there is > no adsl-status. > > What I NEED to do it be able to know if the link is dow n,and if the link > is down use a modem dialup and when the link get back u p stop the > modem.Any Ideas > Thanks > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From andybr@bol.com.br Tue Feb 3 17:44:54 2004 From: andybr@bol.com.br (andybr) Date: Tue, 3 Feb 2004 15:44:54 -0200 Subject: [LARTC] limiting p2p Message-ID: Hi all, Do you have a firewall enabled? If yes, did you try to flush the rules to see if it still happening? []'s Anderson > On Fri, Nov 07, 2003 at 12:27:25PM - 0300, ThE PhP_KiD wrote: > > Hi List ! > > > > I'm trying excelent module ipt_p2p from Filipe > > Almeida in a Linux Box with several connections, > > in order to block p2p traffic with next rule: > > > [...] > > > how ever, I've noted that after two days running, > > that Linux Box (RH 7,2 updated - Kernel 2.4.22 > > - iptables 1.2.8 with String and ConnMark modules, > > Pentium 4, 1.8 Mhz, 256 Mgbytes RAM, and 3c509 eth0, > > eth1 and eth2), > > begins to drop others packets and a simple ping > > look like this: > > > > > > # ping 192.168.210.3 (by example) > > > > PING 192.168.210.3 (192.168.210.3) from 192.168.210.2 54 : 56(84) bytes of > > data. > > 64 bytes from 192.168.210.3: icmp_seq=3D0 ttl=3D64 time=3D4 99 usec > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > 64 bytes from 192.168.210.3: icmp_seq=3D1 ttl=3D64 time=3D4 78 usec > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > 64 bytes from 192.168.210.3: icmp_seq=3D2 ttl=3D64 time=3D4 89 usec > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > ping: sendto: Operation not permitted > > > > Hi! > > I have the same problem... Have you solved it? > I can't see any answer for your email :( > > best > -- > michal > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - =C9 gr=E1tis! http://antipopup.uol.com.br/ From gregoriandres@yahoo.com.ar Tue Feb 3 19:58:17 2004 From: gregoriandres@yahoo.com.ar (ThE LinuX_KiD) Date: Tue, 3 Feb 2004 16:58:17 -0300 Subject: [LARTC] Ip layer 7 Message-ID: Hi, I'm trying to install under 2.4.24 layer 7 patch I've patched kernel with http://sf.net/projects/l7-filter Kernel 2.4 QoS patch and next iptables 1.2.9 with patch taken from same url. when I make menuconfig, I can set new layer 7 options under QoS (network options) but no new options under netfilter secion Of course, iptables 1.2.9 doesn't compile layer7 module A patch is missing for this combination? (iptables 1.2.9 and kernel 2.4.24) regards andres From miller69@gmx.net Tue Feb 3 23:21:44 2004 From: miller69@gmx.net (miller69@gmx.net) Date: Wed, 4 Feb 2004 00:21:44 +0100 (MET) Subject: [LARTC] Problems with HTB (ceil being overpassed) References: Message-ID: <32002.1075850504@www60.gmx.net> > It seems you have hit timer innacuracy issues: > http://www.docum.org/stef.coene/qos/faq/cache/40.html Well, I've tried this on a vanilla 2.4.24 kernel but was not able to load sched_htb anymore. The system was a P4 1700MHz - wich should support it. I'm also experiencing HTB overlimiting as I describe here at the list a while ago. Regards, Mike. -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ From miller69@gmx.net Tue Feb 3 23:52:54 2004 From: miller69@gmx.net (miller69@gmx.net) Date: Wed, 4 Feb 2004 00:52:54 +0100 (MET) Subject: [LARTC] limiting p2p References: Message-ID: <2843.1075852374@www60.gmx.net> > Now I'm testing ipt_ipp2p netfilter 3rd module > You can reach it at: > http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html Thanks for making this public I just forgot about posting the link to the list :-) > But I haven't tested ipt_ipp2p module strongly > with a large LAN Well we ran it at a campus network for about 6 weeks without any issue. Some results of our delay investigations are coming soon - the first graphs look not to bad (0.1-1ms average delay introduced by the bridging firewall). Cheers, Mike. -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ From ii@took.ekilat.com Wed Feb 4 00:53:24 2004 From: ii@took.ekilat.com (Angus D Madden) Date: Tue, 3 Feb 2004 19:53:24 -0500 Subject: [LARTC] iproute2 and ethX:X subdevices In-Reply-To: <20040203174106.GI87073@newred.gradwell.net> References: <20040203174106.GI87073@newred.gradwell.net> Message-ID: <20040204005324.GK16670@took> --7fwXp2o0gOrkU5lS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alan Ford, Tue, Feb 03, 2004 at 05:41:06PM +0000:=20 > Hi, >=20 > Quick question -- is it possible to create eth0:0 - style psuedo-devices > using the 'ip' tool? >=20 ip addr add 10.0.0.1/24 dev eth0 label eth0:0 g --7fwXp2o0gOrkU5lS 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 iD8DBQFAIEKEhS/HVM1dDfsRAhujAJ4tVhwoA+PwfUrwlBMjXYHFxl8LaACg3G9u Mrbphc45ujs+Bc3akqbWJm0= =EeXc -----END PGP SIGNATURE----- --7fwXp2o0gOrkU5lS-- From markryan@cfl.rr.com Wed Feb 4 00:26:40 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Tue, 3 Feb 2004 19:26:40 -0500 Subject: [LARTC] wondershaper Message-ID: <009001c3eab5$8fd3fa00$6501a8c0@underworld> Hi, I have wondershaper running on my firewall/router. It has 2 ethernet cards (eth0 and eth1). Eth1 connects to a cablemodem (2mbit down, 384kbit up) and eth0 connects to a switch. I run a ftp server on a machine connected to the swicth. I want to be able to keep my ftp server from affecting my browsing speed. Problem: I don't see any difference with wondershaper running. I have tried all different speeds and both eth0 and eth1 in wondershaper. Am I doing something wrong? I am testing by pinging yahoo.com. Mark From markryan@cfl.rr.com Wed Feb 4 01:19:21 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Tue, 3 Feb 2004 20:19:21 -0500 Subject: [LARTC] wondershaper htb Message-ID: <00ac01c3eabc$eb9f9040$6501a8c0@underworld> I got wshaper.htb working.....however I have 1 question. How can i limit just ftp server traffic? I have ftp server on port 21 with passive ports of 50000-60000. I currently have wondershaper with htb working on my router....but im afraid that it is also affecting all of my send traffic....not just the ftp server. I want to be able to limit the ftp server traffic only. Thanks, Mark From damion@snapgear.com Wed Feb 4 01:46:14 2004 From: damion@snapgear.com (Damion de Soto) Date: Wed, 04 Feb 2004 11:46:14 +1000 Subject: [LARTC] wondershaper References: <009001c3eab5$8fd3fa00$6501a8c0@underworld> Message-ID: <40204EE6.7070209@snapgear.com> Hi Mark, > I have wondershaper running on my firewall/router. It has 2 ethernet cards > (eth0 and eth1). Eth1 connects to a cablemodem (2mbit down, 384kbit up) and > eth0 connects to a switch. I run a ftp server on a machine connected to the > swicth. > I want to be able to keep my ftp server from affecting my browsing speed. > > Problem: > I don't see any difference with wondershaper running. I have tried all > different speeds and both eth0 and eth1 in wondershaper. You will want to run the wondershaper on eth1. If you run it on eth0 it will be backwards. You should be able to drop the speeds down to something like DOWNLINK=1800 UPLINK=300 and see some difference. Are you using the htb wondershaper or the old cbq one? > Am I doing something wrong? I am testing by pinging yahoo.com. That's probabaly not the best test, you should probably check with real HTTP requests. Are you trying to throttle people uploading TO your ftp server (same as you downloads) or downloading FROM your ftp server ? (you uploading) 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 mabrown-lartc@securepipe.com Wed Feb 4 02:34:34 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Tue, 3 Feb 2004 20:34:34 -0600 (CST) Subject: [LARTC] iproute2 and ethX:X subdevices In-Reply-To: <20040203174106.GI87073@newred.gradwell.net> References: <20040203174106.GI87073@newred.gradwell.net> Message-ID: Alan, : Quick question -- is it possible to create eth0:0 - style : psuedo-devices using the 'ip' tool? They aren't really "pseudo-devices", but we understand what you mean. In the days prior to the iproute2 tools, when a device would have one interface, which would have one IP address, they were called IP aliases. : I see they recognise them when using 'ip addr show': : : 5: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 : inet 192.168.0.1/24 brd 192.168.0.255 scope global eth2:0 : : But I can't see a way of creating them. Is it possible? The answer is yes, there is a way to create interfaces using the "ip address" tool, so that they are recognizable to ifconfig. You are looking for the "label" keyword to the "ip address add" command [0]. : (I know somebody may say "why would I want to" -- it's just for : neatness, so that people using 'ifconfig' can still see all the : addresses in use.) I know exactly why an administrator would wish to do this. Some administrators, who a) have not joined the 21st century with Linux, or b) do not commonly use Linux, but rather other UNIX-like operating systems, may not know about the "ip" utility, but they certainly know about ifconfig! So, if only for the humans, this can be helpful. -Martin [0] http://linux-ip.net/html/tools-ip-address.html#ex-tools-ip-address-del -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From mabrown-lartc@securepipe.com Wed Feb 4 02:34:18 2004 From: mabrown-lartc@securepipe.com (Martin A. Brown) Date: Tue, 3 Feb 2004 20:34:18 -0600 (CST) Subject: [LARTC] RE: LARTC digest, Vol 1 #1564 - 6 msgs In-Reply-To: <50F73B338A7FD943B7937BBCF99BFBDE33B6C7@mail.sofaware.com> References: <50F73B338A7FD943B7937BBCF99BFBDE33B6C7@mail.sofaware.com> Message-ID: Aron, I do not understand your network. In a prior note, I thought I understood that you had multiple serial (T1) interfaces. If you have multiple interfaces, then your statement about having "one physical WAN interface" is misleading. You may have only one T1 card (physical device), with several logical interfaces (for example, wan0, wan1 ...), which is not an uncommon configuration. Anyway, I don't understand your network, so cannot help. Please give "ip addr" and a small ASCII netmap. : The scenario I am working on is the second one - there is one internal : network and two ISPs. Then you have two WAN interfaces? : How can I do fwmark based on the outgoing interface? iptables -t mangle -A POSTROUTING -o wan0 -j MARK --set-mark $wan0_mark iptables -t mangle -A POSTROUTING -o wan1 -j MARK --set-mark $wan1_mark : Remember that there is just one physical WAN interface, with two IP : addresses. Is it possible to fwmark somehow based on the routing : decision? I'm not sure. Maybe somebody else can pick up that question. It's certainly possible to use -j ROUTE based on the fwmark, though [0]. I don't really think that will be required in your situation, but I won't know until I understand your network better. Best of luck, -Martin [0] http://netfilter.gnumonks.org/documentation/pomlist/pom-extra.html#ROUTE -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com From mrenzmann@otaku42.de Wed Feb 4 05:28:28 2004 From: mrenzmann@otaku42.de (Michael Renzmann) Date: Wed, 04 Feb 2004 06:28:28 +0100 Subject: [LARTC] IRC channel archives are up Message-ID: <402082FC.6040302@otaku42.de> Hi all. I finally managed to get some work done with my bot. You maybe already noticed o42bot in #lartc, it will log channel conversations from now on. Archives are accessible via http://bot.otaku42.de . This service could help for example when you want to take a look at what happened while you were not in the channel, or if there was a conversation that you want to refer to inside the list without quoting complete conversation logs. There is a help available that explains most of the features. One thing that still needs improvement is navigation inside the calendar. I'll try to fix the known issues during the next days. If you have any suggestions or notice problems, feel free to contact me, either here or off-list. Bye, Mike From hare ram" Message-ID: <00ce01c3eaee$22d05320$c2bf09ca@huecal> Hi yes i have same problem but layer-7 patch for netfilter now yet ready they only have available for 2.6 kernel i feel they going to release soon lets wait, or upgrade the kernel to 2.6, iam trying to do i will post if iam success hare ----- Original Message ----- From: "ThE LinuX_KiD" To: "lartc" Sent: Wednesday, February 04, 2004 1:28 AM Subject: [LARTC] Ip layer 7 > Hi, > > I'm trying to install under 2.4.24 > layer 7 patch > > I've patched kernel with http://sf.net/projects/l7-filter > Kernel 2.4 QoS patch > > and next iptables 1.2.9 with patch taken from same url. > > when I make menuconfig, I can set new layer 7 options under > QoS (network options) but no new options under netfilter secion > > Of course, iptables 1.2.9 doesn't compile layer7 module > > A patch is missing for this combination? > (iptables 1.2.9 and kernel 2.4.24) > > regards > andres > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > From gomi@perezoso.net Wed Feb 4 12:55:32 2004 From: gomi@perezoso.net (GoMi) Date: Wed, 4 Feb 2004 13:55:32 +0100 Subject: [LARTC] limiting p2p In-Reply-To: <2843.1075852374@www60.gmx.net> Message-ID: =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, i am having really big troubles setting up ipp2p. I have a = woody with kernel upgraded to 2.4.20 and iptables 1.2.8. I changed the = makefile to include these modifications, but still it captures no = traffic at all.. Do i need to run it under 2.4.18?=20 - -----Mensaje original----- De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En = nombre de miller69@gmx.net Enviado el: mi=E9rcoles, 04 de febrero de 2004 0:53 Para: lartc@mailman.ds9a.nl Asunto: RE: [LARTC] limiting p2p > Now I'm testing ipt_ipp2p netfilter 3rd module > You can reach it at:=20 > http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html Thanks for making this public I just forgot about posting the link to = the list :-) > But I haven't tested ipt_ipp2p module strongly > with a large LAN Well we ran it at a campus network for about 6 weeks without any issue. = Some results of our delay investigations are coming soon - the first = graphs look not to bad (0.1-1ms average delay introduced by the bridging = firewall).=20 Cheers, Mike. - --=20 GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) = jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel = +++ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl = http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQCDrxH7diNnrrZKsEQIDHwCfX6GsnRvFUS7zhWzxlUz7Tb9L9GAAn0Vj qXwsBA1B/dXI8TdWqPMuLYdn =3Dk0xx -----END PGP SIGNATURE----- From miller69@gmx.net Wed Feb 4 13:31:58 2004 From: miller69@gmx.net (Mike Miller) Date: Wed, 4 Feb 2004 14:31:58 +0100 (MET) Subject: [LARTC] limiting p2p References: Message-ID: <11914.1075901518@www50.gmx.net> > Hi there, i am having really big troubles setting up ipp2p. I have a > woody with kernel upgraded to 2.4.20 and iptables 1.2.8. I changed the > makefile to include these modifications, but still it captures no > traffic at all.. Do i need to run it under 2.4.18? Well, for us it was working with all kernels from 2.4.18 on. We are currently struggeling problems with 2.4.24 but not sure if this is a kernel issue since we got a whole new box - investigation will take place soon. First of all: are you sure there is any P2P traffic occuring at your link? Is the IPP2P rule put at the correct place (PREROUTING of mangle for example)? Go to http://rnvs.informatik.uni-leipzig.de/ipp2p/ documentation page - there are a couple of examples how to use IPP2P. If this doesn't help come back to me with your setup and ruleset - maybe traffic is accepted somewhere else before IPP2P comes into play. Regards, Mike. -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ From eddieknows@ananzi.co.za Wed Feb 4 14:01:38 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Wed, 04 Feb 2004 16:01:38 +0200 Subject: [LARTC] network monitor Message-ID: <1075903298.2564.63.camel@testbox.co.za> Good Day all I need to know what is going on/in/out on my network.Now I know of ntop and mrtg's but aren't there something different Thanks From marcelorosa2000@yahoo.com.br Wed Feb 4 14:36:39 2004 From: marcelorosa2000@yahoo.com.br (=?iso-8859-1?q?Marcelo=20Rosa?=) Date: Wed, 4 Feb 2004 11:36:39 -0300 (ART) Subject: [LARTC] Direct SQUID Traffic to eth0 Message-ID: <20040204143639.90686.qmail@web14306.mail.yahoo.com> Hi, I have a Linux box in the border of a customer and have the following setup: Eth0 - ADSL with dinamic IP Eth1 - Internet conn with 6 IP available eth2 - Internal net 1 eth3 - internal net 2 This box runs Squid, in transparent mode. I redirect all traffic to internet on port 80 to port 3128 on the box, when coming from eth2 and eth3. I need to make all traffic from eth2 and eth3 get to the Internet through eth0 and the traffic the firewall origintates too. Only traffic recieved from a single host in eth3 and coming from eth1 should get out through eth1. how can I acomplish this? ===== Marcelo de Azevedo Rosa Consultor/Instrutor em Tecnologias de Rede Network Technologies Consultant/Instructor - CCDA/CCNA/CCSI/MCNE GnuPG (www.gnupg.org) - Key ID: 0xFE26FC98 Key fingerprint = B055 B875 67FB 40A3 FBBF A1CB 903D DBB0 FE26 FC98 http://signature.coola.com/?marcelorosa2000@yahoo.com.br ______________________________________________________________________ Yahoo! GeoCities: 15MB de espaço grátis para criar seu web site! http://br.geocities.yahoo.com/ From mike@superiorholidayadventures.ca Wed Feb 4 14:46:11 2004 From: mike@superiorholidayadventures.ca (Mike) Date: Wed, 4 Feb 2004 09:46:11 -0500 Subject: [LARTC] network monitor Message-ID: You may, or may not, have heard of RRDTool: http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ There is also a lot of great stuff at CAIDA: http://www.caida.org/ who sponsor RRDTool. Mike Fetherston > -----Original Message----- > From: Eddie [mailto:eddieknows@ananzi.co.za] > Sent: Wednesday, February 04, 2004 9:02 AM > To: lartc > Subject: [LARTC] network monitor >=20 > Good Day all > I need to know what is going on/in/out on my network.Now I know of ntop > and mrtg's but aren't there something different > Thanks >=20 >=20 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ From miller69@gmx.net Wed Feb 4 15:13:48 2004 From: miller69@gmx.net (Mike Miller) Date: Wed, 4 Feb 2004 16:13:48 +0100 (MET) Subject: [LARTC] network monitor References: <1075903298.2564.63.camel@testbox.co.za> Message-ID: <24540.1075907628@www23.gmx.net> > I need to know what is going on/in/out on my network.Now I know of ntop > and mrtg's but aren't there something different If you're looking for a console based tool try iptraf to monitor current stats of network devices. Regards, Mike. -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ From eddieknows@ananzi.co.za Wed Feb 4 15:27:14 2004 From: eddieknows@ananzi.co.za (Eddie) Date: Wed, 04 Feb 2004 17:27:14 +0200 Subject: [LARTC] network monitor In-Reply-To: <24540.1075907628@www23.gmx.net> References: <1075903298.2564.63.camel@testbox.co.za> <24540.1075907628@www23.gmx.net> Message-ID: <1075908434.2539.1.camel@testbox.co.za> I need to have some sort of web interface so that windows users can also access it and it needs to save the data so we can se it over a period of time On Wed, 2004-02-04 at 17:13, Mike Miller wrote: > *This message was transferred with a trial version of CommuniGate(tm) Pro* > > I need to know what is going on/in/out on my network.Now I know of ntop > > and mrtg's but aren't there something different > If you're looking for a console based tool try iptraf to monitor current > stats of network devices. > > Regards, > Mike. From gomi@perezoso.net Wed Feb 4 15:39:29 2004 From: gomi@perezoso.net (GoMi) Date: Wed, 4 Feb 2004 16:39:29 +0100 Subject: [LARTC] limiting p2p In-Reply-To: <11914.1075901518@www50.gmx.net> Message-ID: =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is my config iptables -t mangle -i eth2 -A PREROUTING -j CONNMARK --restore-mark iptables -t mangle -i eth2 -A PREROUTING -m mark ! --mark 0 -j = ACCEPT iptables -t mangle -i eth2 -A PREROUTING -p icmp -j MARK --set-mark = 4 iptables -t mangle -i eth2 -A PREROUTING -p tcp -m ipp2p --ipp2p -j = MARK --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -p tcp -m ipp2p = --ipp2p-data -j MARK --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -p tcp --dport 1214 -j = MARK --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -p tcp -m string --string = X-Kazaa -j MARK --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -p tcp --dport 2234 -j = MARK --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -p udp --dport 53 -j MARK = --set-mark 1 iptables -t mangle -i eth2 -A PREROUTING -p tcp --dport 80 -m = string ! --string X-Kazaa -j MARK --set-mark 1 iptables -t mangle -i eth2 -A PREROUTING -p tcp --dport 25 -j MARK = --set-mark 1 iptables -t mangle -i eth2 -A PREROUTING -p tcp --dport 0:1024 -j = MARK --set-mark 1 iptables -t mangle -i eth2 -A PREROUTING -p udp --dport ! 53 -j = MARK --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -p tcp --dport 1863 -j = MARK --set-mark 1 iptables -t mangle -i eth2 -A PREROUTING -p tcp -d 0/0 --sport 80 = -j MARK --set-mark 5 iptables -t mangle -i eth2 -A PREROUTING -m mark --mark 0 -j MARK = --set-mark 2 iptables -t mangle -i eth2 -A PREROUTING -j CONNMARK --save-mark ipt_ipp2p 2656 0 (unused) Thats my module working... 0 0 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 ipp2p v0.5a --ipp2p MARK set 0x2 0 0 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 ipp2p v0.5a --ipp2p-data MARK set 0x2 And my rules. There are 100 users, all using p2p, but i have it restricted under my = fw, but some get access though port 80... I am currently downloading, = and for a day or so, no traffic recognized at all... I have no messages at my syslog or messages files at all ... - -----Mensaje original----- De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En = nombre de Mike Miller Enviado el: mi=E9rcoles, 04 de febrero de 2004 14:32 Para: lartc@mailman.ds9a.nl Asunto: RE: [LARTC] limiting p2p > Hi there, i am having really big troubles setting up ipp2p. I have a > woody with kernel upgraded to 2.4.20 and iptables 1.2.8. I changed the = > makefile to include these modifications, but still it captures no=20 > traffic at all.. Do i need to run it under 2.4.18?=20 Well, for us it was working with all kernels from 2.4.18 on. We are = currently struggeling problems with 2.4.24 but not sure if this is a = kernel issue since we got a whole new box - investigation will take = place soon.=20 First of all: are you sure there is any P2P traffic occuring at your = link? Is the IPP2P rule put at the correct place (PREROUTING of mangle = for example)? Go to http://rnvs.informatik.uni-leipzig.de/ipp2p/ = documentation page - there are a couple of examples how to use IPP2P.=20 If this doesn't help come back to me with your setup and ruleset - maybe = traffic is accepted somewhere else before IPP2P comes into play. Regards, Mike. - --=20 GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) = jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel = +++ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl = http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQCESMH7diNnrrZKsEQJq4QCbByR7N5bRYmOis4+UHDYkHYlQWbAAn2oD Ylle5BNIpEkJJiAAFoIwPKsf =3DDROl -----END PGP SIGNATURE----- From miller69@gmx.net Wed Feb 4 16:57:32 2004 From: miller69@gmx.net (Mike Miller) Date: Wed, 4 Feb 2004 17:57:32 +0100 (MET) Subject: [LARTC] limiting p2p References: Message-ID: <31947.1075913852@www61.gmx.net> > iptables -t mangle -i eth2 -A PREROUTING -p tcp -m ipp2p --ipp2p -j > MARK --set-mark 2 > iptables -t mangle -i eth2 -A PREROUTING -p tcp -m ipp2p > --ipp2p-data -j MARK --set-mark 2 There is no need to use --ipp2p and --ipp2p-data on one box. Use --ipp2p only this should be sufficient for most systems. But IPP2P should work with this ruleset anyway. Please do me a favour and remove both rules containing string matches from your ruleset let it run for a while and give me the full output of "iptables -t mangle -L -n -v -x". I guess you're using Kazaa? Is it a (nat-)router or a bridge? Regards, Mike -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ From gomi@perezoso.net Wed Feb 4 17:48:34 2004 From: gomi@perezoso.net (GoMi) Date: Wed, 4 Feb 2004 18:48:34 +0100 Subject: [LARTC] limiting p2p In-Reply-To: <31947.1075913852@www61.gmx.net> Message-ID: =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There it goes, btw..thank you very much ;) Chain PREROUTING (policy ACCEPT 26236333 packets, 12882098667 bytes) pkts bytes target prot opt in out source = destination 249121 26462887 CONNMARK all -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 CONNMARK restore 142502 21317691 ACCEPT all -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 MARK match !0x0 24 14682 MARK icmp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 MARK set 0x4 0 0 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 ipp2p v0.5a --ipp2p MARK set 0x2 27 1296 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp dpt:1214 MARK set 0x2 3 144 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp dpt:2234 MARK set 0x2 438 33099 MARK udp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 udp dpt:53 MARK set 0x1 6712 321889 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp dpt:80 STRING match !X-Kazaa MARK set 0x1 0 0 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp dpt:25 MARK set 0x1 98629 4733897 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp dpts:0:1024 MARK set 0x1 2746 133990 MARK udp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 udp dpt:!53 MARK set 0x2 95 4560 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp dpt:1863 MARK set 0x1 0 0 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp spt:80 MARK set 0x5 4622 221848 MARK all -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 MARK match 0x0 MARK set 0x2 106580 5143324 CONNMARK all -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 CONNMARK save 103317 4959216 MARK tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp flags:0x16/0x02 MARK set 0x3 15 601 chkack tcp -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 tcp flags:0x16/0x10 106556 5142172 chgtos all -- eth2 * 0.0.0.0/0 = 0.0.0.0/0 Chain INPUT (policy ACCEPT 116314 packets, 17066648 bytes) pkts bytes target prot opt in out source = destination Chain FORWARD (policy ACCEPT 39662528 packets, 15020457598 bytes) pkts bytes target prot opt in out source = destination Chain OUTPUT (policy ACCEPT 127443 packets, 41248573 bytes) pkts bytes target prot opt in out source = destination Chain POSTROUTING (policy ACCEPT 32254661 packets, 14698686461 bytes) pkts bytes target prot opt in out source = destination Chain chgtos (1 references) pkts bytes target prot opt in out source = destination 99134 4770212 TOS all -- * * 0.0.0.0/0 = 0.0.0.0/0 CONNMARK match 0x1 TOS set 0x10 7398 357278 TOS all -- * * 0.0.0.0/0 = 0.0.0.0/0 CONNMARK match 0x2 TOS set 0x08 0 0 TOS all -- * * 0.0.0.0/0 = 0.0.0.0/0 CONNMARK match 0x3 TOS set 0x10 0 0 TOS all -- * * 0.0.0.0/0 = 0.0.0.0/0 CONNMARK match 0x5 TOS set 0x02 106556 5142172 RETURN all -- * * 0.0.0.0/0 = 0.0.0.0/0 Chain chkack (1 references) pkts bytes target prot opt in out source = destination 15 601 MARK all -- * * 0.0.0.0/0 = 0.0.0.0/0 length 0:128 MARK set 0x3 0 0 MARK all -- * * 0.0.0.0/0 = 0.0.0.0/0 length 128:65535 MARK set 0x2 15 601 RETURN all -- * * 0.0.0.0/0 = 0.0.0.0/0 - -----Mensaje original----- De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En = nombre de Mike Miller Enviado el: mi=E9rcoles, 04 de febrero de 2004 17:58 Para: GoMi CC: lartc@mailman.ds9a.nl Asunto: RE: [LARTC] limiting p2p > iptables -t mangle -i eth2 -A PREROUTING -p tcp -m ipp2p --ipp2p=20 > -j > MARK --set-mark 2 > iptables -t mangle -i eth2 -A PREROUTING -p tcp -m ipp2p=20 > --ipp2p-data -j MARK --set-mark 2 There is no need to use --ipp2p and --ipp2p-data on one box. Use --ipp2p = only this should be sufficient for most systems. But IPP2P should work = with this ruleset anyway. Please do me a favour and remove both rules containing string matches = from your ruleset let it run for a while and give me the full output of = "iptables -t mangle -L -n -v -x". I guess you're using Kazaa? Is it a = (nat-)router or a bridge? Regards, Mike - --=20 GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) = jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel = +++ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl = http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQCEwcX7diNnrrZKsEQJP/wCg+tPDcIcUPa8EN/DlaHvn64quoCQAoNd9 9x0EfDRmwAAAS6iR27eaFhE5 =3DLtdq -----END PGP SIGNATURE----- From gomi@perezoso.net Wed Feb 4 17:49:17 2004 From: gomi@perezoso.net (GoMi) Date: Wed, 4 Feb 2004 18:49:17 +0100 Subject: [LARTC] limiting p2p In-Reply-To: <31947.1075913852@www61.gmx.net> Message-ID: =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I forgot to tell you, i am with load balancing with 2 DSL connectios = also doing natting on my machine.. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQCEwnH7diNnrrZKsEQIGxgCfWuKXVFV/7hu6YqIEjMvBqH59hxkAn3b0 UpjrpQWYDFt8vnaiERK3er2w =3DuBcX -----END PGP SIGNATURE----- From bench@silentmedia.com Wed Feb 4 19:30:14 2004 From: bench@silentmedia.com (Ben) Date: Wed, 4 Feb 2004 11:30:14 -0800 (PST) Subject: [LARTC] per-session QoS Message-ID: Hey guys, I'm looking for a way to limit ingress throughput for each tcp session to a destination port on my server. I've found lots of ways to limit total throughput to a given port on an ip-level, but that's not quite the same thing. I'm somewhat surprised this doesn't seem to be implemented already. Maybe it is and I'm not seeing it? From bench@silentmedia.com Wed Feb 4 21:15:17 2004 From: bench@silentmedia.com (Ben) Date: Wed, 4 Feb 2004 13:15:17 -0800 (PST) Subject: [LARTC] per-session QoS In-Reply-To: <11898935171.20040204230329@lf.lv> Message-ID: That's the closest thing I've seen to what I want, but it's not quite there. From what I understand, this lets me identify all sessions that have sent more than x bytes. I want something that says "for every session going to port x, limit incoming throughput to no more than 50KB/5s" - or some other throughput definition that allows bursting. On Wed, 4 Feb 2004, Peteris Krumins wrote: > Wednesday, February 4, 2004, 9:30:14 PM, you wrote: > > B> Hey guys, I'm looking for a way to limit ingress throughput for each tcp > B> session to a destination port on my server. I've found lots of ways to > B> limit total throughput to a given port on an ip-level, but that's not > B> quite the same thing. > > B> I'm somewhat surprised this doesn't seem to be implemented already. Maybe > B> it is and I'm not seeing it? > > Take a look at a 'connbytes patch' in the iptables patch-o-matic. > > It is supposed to limit per connection bandwidth amount, 4GB at > maximum. > > > P.Krumins > > From Peteris Krumins Wed Feb 4 21:03:29 2004 From: Peteris Krumins (Peteris Krumins) Date: Wed, 4 Feb 2004 23:03:29 +0200 Subject: [LARTC] per-session QoS In-Reply-To: References: Message-ID: <11898935171.20040204230329@lf.lv> Wednesday, February 4, 2004, 9:30:14 PM, you wrote: B> Hey guys, I'm looking for a way to limit ingress throughput for each tcp B> session to a destination port on my server. I've found lots of ways to B> limit total throughput to a given port on an ip-level, but that's not B> quite the same thing. B> I'm somewhat surprised this doesn't seem to be implemented already. Maybe B> it is and I'm not seeing it? Take a look at a 'connbytes patch' in the iptables patch-o-matic. It is supposed to limit per connection bandwidth amount, 4GB at maximum. P.Krumins From Peteris Krumins Wed Feb 4 23:44:04 2004 From: Peteris Krumins (Peteris Krumins) Date: Thu, 5 Feb 2004 01:44:04 +0200 Subject: Re[2]: [LARTC] per-session QoS In-Reply-To: References: Message-ID: <81108570265.20040205014404@lf.lv> Wednesday, February 4, 2004, 11:15:17 PM, you wrote: B> That's the closest thing I've seen to what I want, but it's not quite B> there. From what I understand, this lets me identify all sessions that B> have sent more than x bytes. Right. B> I want something that says "for every session going to port x, limit B> incoming throughput to no more than 50KB/5s" - or some other throughput B> definition that allows bursting. Well, that is easy. Create as many classes needed, add filters based on MARK value to put the traffic in the correspoing classes, then simply put the connbytes rules (-m connbytes max_bw:) together with a jump to MARK target (-j MARK) in the mangle table. As soon as max_bw will be reached, the packet will get marked and the filter will put the traffic in the appropriate class. P.Krumins From bench@silentmedia.com Thu Feb 5 00:48:13 2004 From: bench@silentmedia.com (Ben) Date: Wed, 4 Feb 2004 16:48:13 -0800 (PST) Subject: Re[2]: [LARTC] per-session QoS In-Reply-To: <81108570265.20040205014404@lf.lv> Message-ID: So maybe I'm dense, but I thought that throughput limit on classes where class-wide, not for each session in the class. In otherwords, if I limit class A to 50KB/5s, every tcp session in that class fights for the same 50KB/5s. Instead, I want every tcp session to have a thoughput limit of 50KB/5s. Maybe I don't understand your example? On Thu, 5 Feb 2004, Peteris Krumins wrote: > B> I want something that says "for every session going to port x, limit > B> incoming throughput to no more than 50KB/5s" - or some other throughput > B> definition that allows bursting. > > Well, that is easy. > > Create as many classes needed, add filters based on MARK value to put > the traffic in the correspoing classes, then simply put the connbytes > rules (-m connbytes max_bw:) together with a jump to MARK target > (-j MARK) in the mangle table. > As soon as max_bw will be reached, the packet will get marked and the > filter will put the traffic in the appropriate class. > > > P.Krumins > > From markryan@cfl.rr.com Thu Feb 5 01:01:59 2004 From: markryan@cfl.rr.com (Mark Ryan) Date: Wed, 4 Feb 2004 20:01:59 -0500 Subject: [LARTC] wondershaper Message-ID: <000d01c3eb83$a98fe9d0$6501a8c0@underworld> I am using wondershaper with htb to shape my network. I want to limit only outbound ftp traffic (me uploading) from 192.168.1.101. I am using port 21 for ftp with passive ports 50,000-60,000. What else do I need to put in the config to do this? Here is my config. DOWNLINK=3000 UPLINK=340 DEV=eth1 # low priority OUTGOING traffic - you can leave this blank if you want # low priority source netmasks NOPRIOHOSTSRC=192.168.1.101 # low priority destination netmasks NOPRIOHOSTDST= # low priority source ports NOPRIOPORTSRC= # low priority destination ports NOPRIOPORTDST= Thanks, Mark From damion@snapgear.com Thu Feb 5 05:39:43 2004 From: damion@snapgear.com (Damion de Soto) Date: Thu, 05 Feb 2004 15:39:43 +1000 Subject: [LARTC] Direct SQUID Traffic to eth0 References: <20040204143639.90686.qmail@web14306.mail.yahoo.com> Message-ID: <4021D71F.4040809@snapgear.com> Hi Marcelo, > I have a Linux box in the border of a customer and have the following setup: > > This box runs Squid, in transparent mode. I redirect all traffic to internet on port 80 > to port 3128 on the box, when coming from eth2 and eth3. > I need to make all traffic from eth2 and eth3 get to the Internet through eth0 and the > traffic the firewall origintates too. > Only traffic recieved from a single host in eth3 and coming from eth1 should get out > through eth1. You should be able to use 2 routing tables. one with a default gateway via eth1, and the other via eth0 you then use policy routing rules: like this, i think: ip route add 0/0 via eth2-gw-IP table 1 ip rule add pref 1000 from eth2-gw-IP lookup 1 ip route add default nexthop via eth2-gw-IP dev eth2 ip route add 0/0 via eth1-gw-IP table 2 ip rule add pref 1001 from eth1-gw-IP lookup 2 ip rule add pref 1002 from eth3-single-IP lookup 2 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 damion@snapgear.com Thu Feb 5 05:2