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: <lartc-request@xxxxxxxxxxxxxxx>
To: <lartc@xxxxxxxxxxxxxxx>
Sent: Thursday, January 29, 2004 2:55 AM
Subject: LARTC digest, Vol 1 #1563 - 9 msgs
> Send LARTC mailing list submissions to
> lartc@xxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> lartc-admin@xxxxxxxxxxxxxxx
>
> 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" <mabrown-lartc@xxxxxxxxxxxxxx>
> To: Scott Baker <bakers@xxxxxxxxxxxx>
> Cc: lartc@xxxxxxxxxxxxxxx
> Subject: Re: 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@xxxxxxxxxxxxxx
>
>
> --__--__--
>
> Message: 2
> To: LARTC@xxxxxxxxxxxxxxx
> From: David Bierce <operations@xxxxxxxxxxxxxxxx>
> Date: Wed, 28 Jan 2004 00:46:19 -0600
> Subject: 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" <mabrown-lartc@xxxxxxxxxxxxxx>
> To: Gordan Bobic <lartc@xxxxxxxxxx>
> Cc: lartc@xxxxxxxxxxxxxxx
> Subject: Re: 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@xxxxxxxxxxxxxx
>
>
> --__--__--
>
> Message: 4
> Date: Wed, 28 Jan 2004 10:25:00 +0200
> From: Alexander Trotsai <mage@xxxxxxxxxxx>
> To: "Michael S. Kazmier" <mkazmier@xxxxxxxxxx>
> Cc: lartc@xxxxxxxxxxxxxxx
> Subject: Re: 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?=
<rabs@xxxxxxxxxxxxxxxxxxxxx>
> Organization: =?iso-8859-15?q?Dimensi=F3n=20Virtual?= S.L.
> To: lartc@xxxxxxxxxxxxxxx
> Date: Wed, 28 Jan 2004 10:01:56 +0000
> Subject: 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 <adi@xxxxxxxxxxxxxxxxxx>
> Organization: NoBug Consulting
> To: lartc@xxxxxxxxxxxxxxx
> Subject: 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 <mrenzmann@xxxxxxxxxx>
> To: Adrian Coman <adi@xxxxxxxxxxxxxxxxxx>
> Cc: lartc@xxxxxxxxxxxxxxx
> Subject: Re: 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@xxxxxxxxxxxxxxx
> From: Scott Baker <bakers@xxxxxxxxxxxx>
> Subject: 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 <mrenzmann@xxxxxxxxxx>
> To: "lartc@xxxxxxxxxxxxxxx" <lartc@xxxxxxxxxxxxxxx>
> Subject: 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@xxxxxxxxxxxxxxx
> http://mailman.ds9a.nl/mailman/listinfo/lartc
>
>
> End of LARTC Digest
>
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
