Yu,
Sorry if I wasn't clear enough. There is no current way to adjust traffic
share, except when using EIGRP/IGRP.
chris
> -----Original Message-----
> From: Yu Ning [mailto:yuning@cndata.com]
> Sent: Wednesday, September 27, 2000 7:06 AM
> To: Martin, Christian; Andy Li; cisco-nsp@puck.nether.net
> Cc: Chinanet-vt
> Subject: Re: How to adjust the "traffic share count/ratio" of
> equal cost IGP path ?
>
>
> Hi Chris,
>
> Thanks your patient and detailed answer, but I already know
> it, and it's not
> related with what I've asked,:-) I know we can achieve it via
> MPLS, or BGP.
> What I want to know, if you really have a detail look to my
> original message
> is in the normal IGP enabled with CEF condition.
>
> thanks anyway.
>
> Yu Ning.
> ------------------------------------------
> (Mr.) Yu(2) Ning(2)
> Support,Int'l/Domestic Routing
> ChinaNET(AS4134) Backbone Operation
> Beijing,P.R.C. +86-10-66418105/8121/8122
> ------------------------------------------
> ----- Original Message -----
> From: "Martin, Christian" <cmartin@gnilink.net>
> To: "'Yu Ning'" <yuning@cndata.com>; "Andy Li"
> <ali@cisco.com>; <cisco-nsp@puck.nether.net>
> Cc: "Chinanet-vt" <Chinanet-vt@cisco.com>
> Sent: Tuesday, September 26, 2000 7:38 PM
> Subject: RE: How to adjust the "traffic share count/ratio" of
> equal cost IGP path ?
>
>
> > Yu,
> >
> > The router, in general, is attempting to find one and only
> one path to a
> > destination - the best path. If all things are equal in
> regards to the
> > particular protocols path selection algorithm, then a Cisco will
> > load-balance among up to 6 equal cost paths. If your links
> are of different
> > bandwidth/delay/cost - if their metrics differ, then they
> should not be part
> > of this equal cost balancing, because they violate the very
> premise of
> > equality itself. This is why IGPs do not allow for very
> robust traffic
> > engineering. BGP can do a little more, but the
> configuration nightmare is
> > to be avoided. This brings us to MPLS.
> >
> > In a nutshell, MPLS allows one to choose an arbitrary path
> through the
> > network that uses an arbitrary (acyclic) sequence of
> node,link pairs to form
> > a Label Switched Path. You can choose the path based on an
> administrative
> > 'color', the amount of bandwidth needed, the level of QoS
> based on IP ToS,
> > etc. Since the LSPs are set up before traffic flows, and
> because Label
> > Switching Routers merely have to look up label mappings in
> a table, the
> > forwarding is fast - even when only partially hardware
> accelerated - at all
> > available interface speeds. In the Cisco world, there is
> still some legacy
> > nomenclature (Tag Switching), but there is full support for
> MPLS, and it
> > interpoerates well with Juniper (although jnpr does MPLS
> better - no fast
> > reroute in Cisco yet.)
> >
> > If you don't want to use EIGRP, then look at MPLS. It may
> help you out a
> > bunch.
> >
> > ./chris
> >
> > -----Original Message-----
> > From: Yu Ning [mailto:yuning@ns.chinanet.cn.net]
> > Sent: Tuesday, September 26, 2000 1:38 AM
> > To: Andy Li; cisco-nsp@puck.nether.net
> > Cc: Chinanet-vt
> > Subject: Re: How to adjust the "traffic share count/ratio"
> of equal cost IGP
> > path ?
> >
> >
> > Hi Andy,
> >
> > Here is the result:
> >
> > rtr4-c-1-bjbj#sh ip cef 202.97.9.60
> > 202.97.9.60/30, version 35751988, per-destination sharing,
> 0 packets, 0
> > bytes
> > via 202.97.9.17, POS2/0, 21 dependencies
> > traffic share 1
> > next hop 202.97.9.17, POS2/0
> > valid adjacency
> > via 202.97.9.161, POS2/3, 21 dependencies
> > traffic share 1, current path
> > next hop 202.97.9.161, POS2/3
> > valid adjacency
> > via 202.97.10.173, ATM4/1.1, 22 dependencies
> > traffic share 1
> > next hop 202.97.10.173, ATM4/1.1
> > valid adjacency
> > 0 packets, 0 bytes switched through the prefix
> >
> > rtr4-c-1-bjbj#sh ip cef 202.97.9.60 int
> > 202.97.9.60/30, version 35751988, per-destination sharing,
> 0 packets, 0
> > bytes
> > via 202.97.9.17, POS2/0, 21 dependencies
> > traffic share 1
> > next hop 202.97.9.17, POS2/0
> > valid adjacency
> > via 202.97.9.161, POS2/3, 21 dependencies
> > traffic share 1, current path
> > next hop 202.97.9.161, POS2/3
> > valid adjacency
> > via 202.97.10.173, ATM4/1.1, 22 dependencies
> > traffic share 1
> > next hop 202.97.10.173, ATM4/1.1
> > valid adjacency
> >
> > 0 packets, 0 bytes switched through the prefix
> > Load distribution: 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 (refcount 65)
> >
> > Hash OK Interface Address Packets
> > 1 Y POS2/0 point2point 0
> > 2 Y POS2/3 point2point 0
> > 3 Y ATM4/1.1 point2point 0
> > 4 Y POS2/0 point2point 0
> > 5 Y POS2/3 point2point 0
> > 6 Y ATM4/1.1 point2point 0
> > 7 Y POS2/0 point2point 0
> > 8 Y POS2/3 point2point 0
> > 9 Y ATM4/1.1 point2point 0
> > 10 Y POS2/0 point2point 0
> > 11 Y POS2/3 point2point 0
> > 12 Y ATM4/1.1 point2point 0
> > 13 Y POS2/0 point2point 0
> > 14 Y POS2/3 point2point 0
> > 15 Y ATM4/1.1 point2point 0
> > 16 Y POS2/0 point2point 0
> >
> > Just like in the "sh ip ro", all the three links have equal
> share of the
> > traffic.
> > Because of them is ATM PVC, can I set him to share a small
> amount of traffic
> > ?
> > Unequal share ? Note we'd not use MPLS tunnel tricks.
> >
> > regards,
> >
> > ------------------------------------------
> > (Mr.) Yu(2) Ning(2)
> > Support Engineer, Int'l/Domestic Routing
> > ChinaNET (AS4134) Backbone Operation
> > Beijing, P.R.C. +86-10-66418105/8121/8122
> > ------------------------------------------
> > ----- Original Message -----
> > From: "Andy Li" <ali@cisco.com>
> > To: "Yu Ning" <yuning@ns.chinanet.cn.net>;
> <cisco-nsp@puck.nether.net>
> > Cc: "Chinanet-vt" <Chinanet-vt@cisco.com>
> > Sent: Monday, September 25, 2000 11:56 PM
> > Subject: RE: How to adjust the "traffic share count/ratio"
> of equal cost IGP
> > path ?
> >
> >
> > > Please give theo utput of the following command
> > >
> > > sh ip cef 202.97.9.60
> > >
> > > Thanks
> > > Andy
> > >
> > > -----Original Message-----
> > > From: Yu Ning [mailto:yuning@ns.chinanet.cn.net]
> > > Sent: Monday, September 25, 2000 12:21 AM
> > > To: cisco-nsp@puck.nether.net
> > > Cc: Chinanet-vt
> > > Subject: How to adjust the "traffic share count/ratio" of
> equal cost IGP
> > > path ?
> > >
> > >
> > > Hi All,
> > >
> > > We know that if we see equal cost IGP routes, the Cisco
> box will load
> > > balance between
> > > the different output interfaces. For example:
> > >
> > > Routing entry for 202.97.9.60/30
> > > Known via "isis", distance 115, metric 5, type level-2
> > > Redistributing via isis
> > > Last update from 202.97.10.173 on ATM4/1.1, 5d04h ago
> > > Routing Descriptor Blocks:
> > > * 202.97.9.17, from 202.97.9.17, via POS2/0
> > > Route metric is 5, traffic share count is 1
> > > 202.97.9.161, from 202.97.9.161, via POS2/3
> > > Route metric is 5, traffic share count is 1
> > > 202.97.10.173, from 202.97.10.173, via ATM4/1.1
> > > Route metric is 5, traffic share count is 1
> > >
> > > The "*" sign indicate the current route used. But
> normally the traffic
> > load
> > > will evenly
> > > shared in all the parallel paths, no matter how different
> BW they are.
> > Then
> > > I wonder if
> > > there is any method to adjust the "traffic share count"
> of the different
> > > output interface,
> > > so that I can get an uneven load share?
> > >
> > > The possibility of this idea comes to me when I dig some
> document on cisco
> > > MPLS-TE, it says
> > > that if two MPLS tunnels have different BW, the "traffic
> share count" will
> > > be adjusted according
> > > to the bandwidth ratio automatically. Because the load
> share is based on
> > the
> > > CEF, and is generic
> > > to all kinds of IGP, then I think it maybe possible in ISIS.
> > >
> > > Our environment is: GSR with dCEF enable, IOS 12.0 train.
> IGP=ISIS.
> > >
> > > Any input? Thanks!
> > >
> > >
> > > Yu Ning
> > > -------------------------------------------
> > > (Mr.) Yu(2) Ning(2)
> > > ChinaNet Backbone Operation
> > > Networking Dep.,Datacom Bureau
> > > China Telecom.,Beijing,P.R.C
> > > +86-10-66418105/66418121/66418122
> > > -------------------------------------------
> > >
> > >
> >
> >
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:17 EDT