Re: [LARTC] traffic shaping on single ip...

[Roy]

You cant control input traffic that way at 
all.
 
you need to use imq for inbound traffic control, or 
at least policers.
 
also cbq is very old and should be replaced with 
htb
 

  - Original Message - 
  From: 
  Cristiano Soares 
  To: [EMAIL PROTECTED] 
  Sent: Thursday, April 08, 2004 7:54 
  PM
  Subject: [LARTC] traffic shaping on 
  single ip...
  
  
  Hi all. Im using the following CQB shaper to 
  shape IP addresses:
   
  DEV=eth1 (internal eth)
   
  tc qdisc del dev $DEV roottc qdisc add dev 
  $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit
  tc class add dev $DEV parent 1: classid 1:1 cbq 
  rate 256kbit allot 1500 prio 5 bounded isolatedtc class add dev $DEV 
  parent 1: classid 1:2 cbq rate 512kbit allot 1500 prio 5 bounded 
  isolated
   
  tc filter add dev $DEV parent 1: protocol ip prio 
  16 u32 match ip dst 192.168.2.230 flowid 1:2tc filter add dev $DEV parent 
  1: protocol ip prio 16 u32 match ip src 192.168.2.230 flowid 1:2
   
  tc filter add dev $DEV parent 1: protocol ip prio 
  16 u32 match ip dst 192.168.2.188 flowid 1:1tc filter add dev $DEV parent 
  1: protocol ip prio 16 u32 match ip src 192.168.2.188 flowid 1:1
   
  tc filter add dev $DEV parent 1: protocol ip prio 
  16 u32 match ip dst 192.168.2.172 flowid 1:1tc filter add dev $DEV parent 
  1: protocol ip prio 16 u32 match ip src 192.168.2.172 flowid 
  1:1
   
  The thing is, i want to be able to shape inbound 
  different from outbound traffic. I use an ADSL line so, i need to shape up 
  significantly lower than down. Thanks a lot.
  And also, is there a better way to shape traffic 
  like this? Thanks a lot.
   
  Cristiano

Re: [LARTC] First Post: Question on Ip Aliasing

[Roy]

nothing can go out through alias inetrface, alias is for input only.

so everything is going through physical interface like eth0
if you are forwarding packets, then your interface ip is ignored anyway.
(it is only used to translate ip to mac)
if you want to shape localy generated trafic, then source ip will depend on
what the user will chose,
since he can use any aliased ip of your server.

so simply ignore all virtual interaces imagine that you have none of them,


- Original Message - 
From: "Discussion Lists" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 08, 2004 11:59 PM
Subject: RE: [LARTC] First Post: Question on Ip Aliasing


Thank you for your response.  You confirmed what I understood
to be how
it works, but for some reason it isn't working like that, and I can't
understand why.  The alias gets assigned through heartbeat, during a
failover, but traffic routes through that alias as if there was no
shaping going on at all.  In other words it just isn't working the way
that it should be working.  I am not even sure where to look for
problems or errors.  I don't see how my configuration can be wrong
because it is shaping traffic just fine on the physical adapter . .. If
anyone can think of other suggestions, I would greatly appreciate it.

Thanks!

> -Original Message-
> From: Jose Luis Domingo Lopez [mailto:[EMAIL PROTECTED]

> Sent: Thursday, April 08, 2004 8:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [LARTC] First Post: Question on Ip
Aliasing
>
> On Thursday, 08 April 2004, at 06:53:27 -0700, Discussion Lists
wrote:
>
> > I did a google search on this and didn't find exactly what
I was
> > looking for.  Suppose I have a machine that has an IP
alias
> eth0:0.  I
> > have set up HTB.init so that it properly throttles

> bandwidth on eth0,
> > however when I use eth0:0, it doesn't work.  I read

> elsewhere that it
> > should work at the PHYSICAL device layer, and should
therefore work
> > for both at once.  This is not happening though.  Just

> wanted to find
> > out if
> >
> I think that the '"'hack'"' of '"'alias
interfaces'"' in Linux has
> been one major source of conceptual problems with respect to

> Linux routing and the like in past years :-). I have always

> believed that it is much better to think of IP addresses in

> Linux as assigned to physical interfaces rather than
> associated to some kind of a virtual one.
>
> The '"'ip address show'"' command shows very clearly this
fact.
> Each interface has zero or more IP addresses assigned to it,

> and with '"'ip'"'
> you will never see '"'alias interfaces'"' again, because
this
> tool is modern enough to understand the fact. I encourage

> everyone to make the move to '"'ip'"' from old
'"'ifconfig'"' and
> related tools as soon as possible.
>
> In the '"'ip'"' world you just have physical (or not so
physical,
> like bond?
> or VLAN interfaces) interfaces and IP assigned to them. And

> when you want to refer to IP addresses, you just use them.

> And when you want to refer to interfaces, use the one you
need.
>
> Also, have a look at the Stef Coene's excellent KPTD
at:
> http://www.docum.org/stef.coene/qos/kptd/
>
> Couple the above diagram with the previous explanation about

> IP and interfaces and maybe all will now be simpler to
you.
>
> Greetings.
>
> --
> Jose Luis Domingo Lopez
> Linux Registered User #189436 Debian Linux Sid (Linux
2.6.5)
> ___
> LARTC mailing list / [EMAIL PROTECTED]
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

RE: [LARTC] First Post: Question on Ip Aliasing

[Daniel Chemko]

Discussion Lists wrote:
> Thank you for your response.  You confirmed what I understood to be
> how it works, but for some reason it isn't working like that, and I
> can't understand why.  The alias gets assigned through heartbeat,
> during a failover, but traffic routes through that alias as if there
> was no shaping going on at all.  In other words it just isn't working
> the way that it should be working.  I am not even sure where to look
> for problems or errors.  I don't see how my configuration can be
> wrong because it is shaping traffic just fine on the physical adapter
> . .. If anyone can think of other suggestions, I would greatly
> appreciate it. 

Do you run the trafficing script during a failover, or just when you
boot the system? Maybe the traffic routing rules get dropped from the
system once the interface is down, much the same way that routes do?
Just a thought. I haven't bothered to setup traffic rules on my gateways
yet.
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

RE: [LARTC] First Post: Question on Ip Aliasing

[Discussion Lists]

Thank you for your response.  You confirmed what I understood to be how
it works, but for some reason it isn't working like that, and I can't
understand why.  The alias gets assigned through heartbeat, during a
failover, but traffic routes through that alias as if there was no
shaping going on at all.  In other words it just isn't working the way
that it should be working.  I am not even sure where to look for
problems or errors.  I don't see how my configuration can be wrong
because it is shaping traffic just fine on the physical adapter . .. If
anyone can think of other suggestions, I would greatly appreciate it.

Thanks!

> -Original Message-
> From: Jose Luis Domingo Lopez [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 08, 2004 8:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [LARTC] First Post: Question on Ip Aliasing
> 
> On Thursday, 08 April 2004, at 06:53:27 -0700, Discussion Lists wrote:
> 
> > I did a google search on this and didn't find exactly what I was 
> > looking for.  Suppose I have a machine that has an IP alias 
> eth0:0.  I 
> > have set up HTB.init so that it properly throttles 
> bandwidth on eth0, 
> > however when I use eth0:0, it doesn't work.  I read 
> elsewhere that it 
> > should work at the PHYSICAL device layer, and should therefore work 
> > for both at once.  This is not happening though.  Just 
> wanted to find 
> > out if
> >
> I think that the "hack" of "alias interfaces" in Linux has 
> been one major source of conceptual problems with respect to 
> Linux routing and the like in past years :-). I have always 
> believed that it is much better to think of IP addresses in 
> Linux as assigned to physical interfaces rather than 
> associated to some kind of a virtual one.
> 
> The "ip address show" command shows very clearly this fact. 
> Each interface has zero or more IP addresses assigned to it, 
> and with "ip"
> you will never see "alias interfaces" again, because this 
> tool is modern enough to understand the fact. I encourage 
> everyone to make the move to "ip" from old "ifconfig" and 
> related tools as soon as possible.
> 
> In the "ip" world you just have physical (or not so physical, 
> like bond?
> or VLAN interfaces) interfaces and IP assigned to them. And 
> when you want to refer to IP addresses, you just use them. 
> And when you want to refer to interfaces, use the one you need.
> 
> Also, have a look at the Stef Coene's excellent KPTD at:
> http://www.docum.org/stef.coene/qos/kptd/
> 
> Couple the above diagram with the previous explanation about 
> IP and interfaces and maybe all will now be simpler to you.
> 
> Greetings.
> 
> --
> Jose Luis Domingo Lopez
> Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5)
> ___
> LARTC mailing list / [EMAIL PROTECTED] 
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Squid + shaping question

[Radoslav Kolev]

Hi, Teodor!
Integrating squid with traffic control has been a big problem for all of 
us.
Besides the options listed at the docum.org faq, there's a patch at 
http://sed.pl/~mrk/qos/, which is very similar to ZPH, unfortunately the 
page is available only in Polish, so it didn't become very popular. You 
can just download the patch and figure out how to use it.
There's also the wipl/wrr proxy remap package at 
http://wipl-wrr.sourceforge.net/proxyremap.html
As a last resort, if you have a small number of clients (<256) you can 
put IP aliases on the outer intefrace of the Squid machine, then use acl 
to select different source IP for each client machine.
To me the ZPH + Patrick  McHardy's acl classify patch combination seems 
the best solutions available now, but I don't have any experience to share.
It would be interesting to hear from someone using it.

Greetings,
RAdo
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Squid + shaping question

[Evgeni Gechev]

Short: you need zph patch.
Detailed: you could use both, if you need. They just do different jobs.
With the first patch you could control outgoing connections, i.e. 
communication between squid and web servers/peers. With the second patch 
(zph), you could control communication between squid and clients, and as 
I understand, this is what you are interested in.

Teodor Yantchev wrote:

Hi folks,

So, I have a pretty simple setup - a linux router machine running as a
firewall/router for a small neighborhood LAN (approx 20 machines). I also
have squid running on the box in non-transparent mode, and also I have set
up NAT for TCP/UDP ports above 1024 for all clients and SSH/POP/SMTP/CVS
NAT'd for selected ones based on MAC filtering. No hosts whatsoever can
access ports 80 and 443 without going through squid. The uplink to the
internet is 512kbit/s downstream and 64kbit/s upstream cable modem connected
on eth1 (LAN on eth0, no DMZ).
When the LAN started to grow from a few well known friends of mine to more
people I didn't know so well 'social shaping' stopped working for us - bulk
downloaders started to saturate the link so badly that I even couldn't use
acceptably ssh from outside. So - the usual solution - www.lartc.org.
I did a lot of reading on the topic (This really got me interested in) and
finally ended up installing a self-modified version of wondershaper on the
external interface. This did solve the problem of me having usable ssh from
my office to the router machine, and the ingress qdisc partially solved the
problem of the downlink being fairly distributed between all incoming
connections - but as most of you know this is a half-baked bread. What I
think should be done is shaping the internal interface - BUT - the squid
in-between causes trouble.
So the question is - How to differentiate between traffic served from
squid's cache and traffic squid got directly from the internet ?
Shaping/policing all web traffic negates the benefits of having a caching
proxy pretty much.
After lots of googling and reading(at one point I was ready to completely
forget squid) a came up with the following alternatives, both found on the
FAQ section of www.docum.org - 'SQUID zero penalty for HIT traffic patch' by
a fellow bulgarian Marin Stavrev, and a patch giving you the ability to 'use
ACL lists to put packets in classes' by a guy named Patrick.
I'd like to ask you for your experiences with those, which one is better,
any other alternatives you know of and of course general
recipes/recommendations for solving my problem.
Well, That's it put shortly in an over-sized mail. Thanks in advance for
your advice.
Regards,
Teddy
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
 

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] traffic shaping on single ip...

[Cristiano Soares]

Hi all. Im using the following CQB shaper to shape 
IP addresses:
 
DEV=eth1 (internal eth)
 
tc qdisc del dev $DEV roottc qdisc add dev $DEV 
root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev $DEV parent 1: classid 1:1 cbq 
rate 256kbit allot 1500 prio 5 bounded isolatedtc class add dev $DEV parent 
1: classid 1:2 cbq rate 512kbit allot 1500 prio 5 bounded isolated
 
tc filter add dev $DEV parent 1: protocol ip prio 
16 u32 match ip dst 192.168.2.230 flowid 1:2tc filter add dev $DEV parent 1: 
protocol ip prio 16 u32 match ip src 192.168.2.230 flowid 1:2
 
tc filter add dev $DEV parent 1: protocol ip prio 
16 u32 match ip dst 192.168.2.188 flowid 1:1tc filter add dev $DEV parent 1: 
protocol ip prio 16 u32 match ip src 192.168.2.188 flowid 1:1
 
tc filter add dev $DEV parent 1: protocol ip prio 
16 u32 match ip dst 192.168.2.172 flowid 1:1tc filter add dev $DEV parent 1: 
protocol ip prio 16 u32 match ip src 192.168.2.172 flowid 1:1
 
The thing is, i want to be able to shape inbound 
different from outbound traffic. I use an ADSL line so, i need to shape up 
significantly lower than down. Thanks a lot.
And also, is there a better way to shape traffic 
like this? Thanks a lot.
 
Cristiano

Re: [LARTC] First Post: Question on Ip Aliasing

[Jose Luis Domingo Lopez]

On Thursday, 08 April 2004, at 06:53:27 -0700,
Discussion Lists wrote:

> I did a google search on this and didn't find exactly what I was looking
> for.  Suppose I have a machine that has an IP alias eth0:0.  I have set
> up HTB.init so that it properly throttles bandwidth on eth0, however
> when I use eth0:0, it doesn't work.  I read elsewhere that it should
> work at the PHYSICAL device layer, and should therefore work for both at
> once.  This is not happening though.  Just wanted to find out if
>
I think that the "hack" of "alias interfaces" in Linux has been one
major source of conceptual problems with respect to Linux routing and
the like in past years :-). I have always believed that it is much
better to think of IP addresses in Linux as assigned to physical
interfaces rather than associated to some kind of a virtual one.

The "ip address show" command shows very clearly this fact. Each
interface has zero or more IP addresses assigned to it, and with "ip"
you will never see "alias interfaces" again, because this tool is modern
enough to understand the fact. I encourage everyone to make the move to
"ip" from old "ifconfig" and related tools as soon as possible.

In the "ip" world you just have physical (or not so physical, like bond?
or VLAN interfaces) interfaces and IP assigned to them. And when you
want to refer to IP addresses, you just use them. And when you want to
refer to interfaces, use the one you need.

Also, have a look at the Stef Coene's excellent KPTD at:
http://www.docum.org/stef.coene/qos/kptd/

Couple the above diagram with the previous explanation about IP and
interfaces and maybe all will now be simpler to you.

Greetings.

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.5)
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] First Post: Question on Ip Aliasing

[Discussion Lists]

Hi All,
I did a google search on this and didn't find exactly what I was looking
for.  Suppose I have a machine that has an IP alias eth0:0.  I have set
up HTB.init so that it properly throttles bandwidth on eth0, however
when I use eth0:0, it doesn't work.  I read elsewhere that it should
work at the PHYSICAL device layer, and should therefore work for both at
once.  This is not happening though.  Just wanted to find out if
TC/iproute2/HTB will behave like that: Meaning, are they supposed to
throttle bandwidth for the physical, AND the alias at the same time, or
do I need a separate rule?

Thanks in advance!

P.S.
I tried setting up eth0:0 as a config file in the HTB dir, and htb.init
didn't like that at all.  I wonder if TC would react the same way?
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] How to DSMARK locally generated traffic and then apply AFHTB?

[TT TT]

Hi fellow traffic-shapers,

I am implementing a Diffserv CORE router using Linux kernel 2.4.18. I used 
this excellent website (http://www.opalsoft.net/qos/DS-38.htm) using AFHTB 
as a starting basis for my EGRESS diffserv implementation - and all works 
great so far!!!

But my project has an additional requirement. There are services running 
locally on the router which are sending/receiving IP traffic also. These 
services are leaving the DSCP set to 0x00. What I want to do is to mark 
these packets with a specific DSCP value and then treat them as if they came 
in from the INGRESS and apply the AFHTB QoS mechanism How I can I do 
this?

To restate the scenario:

- I am a CORE diffserv router.
- I am using the AFHTB script on my EGRESS
- Traffic from LAN has DSCP set, all works great using the AFHTB script!
- Traffic generated within the router has no DSCP set, but I want to set the 
DSCP values (based on a u32 filter) and THEN treat the packets just like the 
packets coming in from the LAN.
- The problem is that the AFHTB script assumes the DSCP values are already 
set, but for locally generated traffic they are not.
- As DSMARK is my root queue, I know I can "mark" the DSCP code just before 
handing the packet over to the egress interface using commands like ""tc 
class change dev eth1 classid 1:1 dsmark mask 0x3 value 0xb8"". But this 
marking is being done AFTER the AFHTB has done all its work, and I want to 
mark the DSCP values BEFORE applying the AFHTB QoS.

Any suggestions/ideas/resources are truly appreciated!

Scratching my head,
-Tony
_
Persistent heartburn? Check out Digestive Health & Wellness for information 
and advice. http://gerd.msn.com/default.asp

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] setup fail-over with redhat9...

[Damion de Soto]

Hi Cristiano,

I know that to make redundance work ill have to setup the ip route and 
ip rule in my system. To do that, i found a bash script called "NETSANE 
- http://muse.linuxmafia.org/netsane/";. I have to change somethings like 
interface of the first and second lines in netsane.conf. So, i did all 
the changes needed. Looking good so far, i can ping outside sites the 
both eth2 and eth0 doing "ping -I eth# www.kernel.org", i dont have a 
"default route" and etc.
ok, that's good.

Ok, now goes the worse part. I cant MASQUERADE the connection to my 
internal network, and even if i could, will redundance work if the first 
interface fails? I dont think so.
No, as the netsane webpage says, it does not provide redundancy.

> Because i tried a normal ping (ping
www.kernel.org ) and it always goes through eth2, 
even the i unplug the adsl line from the router/modem to simulate a down 
link.
Yes, your packet routes get cached by the kernel.  Eventually, it will realise that 
route is dead, and has a 50% chance of getting out the other active interface.


I believe that should be an IPTABLES configuration to make NAT work with 
redundance, not the usual below:

# turn on NAT (IP masquerading for outgoing packets)
$IPTABLES -A POSTROUTING -t nat -o eth0 -j MASQUERADE
#you will want to masquerade out eth2 as well.
$IPTABLES -A POSTROUTING -t nat -o eth2 -j MASQUERADE
Im using the rc.firewall-2.4 right now, and it clearly doesnt work with 
redundance.
As far as I know, the only way you can get fail-over/redundancy, is to have a program 
continually monitor both links, and bring up/down the interfaces and change the 
routes as required.

You should be able to write a shell script that pings out eth2, and if it doesn't get
a reply, brings down that interface and fixes the routes.
Then, wait, try again later and see if eth2 is working again.
Regards,

--
~~~
Damion de Soto - Software Engineer  email: [EMAIL PROTECTED]
SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809
 | Custom Embedded Solutions  fax: +61 7 3891 3630
 | and Security Appliancesweb: http://www.snapgear.com
~~~
 ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/