From: marc van hoof (mvh@marcvanhoof.com)
Date: Tue Aug 24 2004 - 00:52:57 GMT-3
Just while we're talking about things that get passed to other routers, do
tag values get moved around within the routing protocols ?
So if rtrA and rtrB both are border routers between the SAME OSPF and ISIS
domain (or any routing protocols for that matter), and I have to do mutual
redistribution on both of them, can I use tags to avoid loops.
Eg.
rtrA:
redist from prot A to prot B and set tag = AtoB
redist from prot B to prot A and set tag = BtoA
rtrB:
redist from prot A to prot B where tag != BtoA
redist from prot B to prot A where tag != AtoB
I know that a router won't loop mutual redistribution. Locally it
understands that if it's redistributed 1.1.1.0 from prot A to prot B, it
shouldn't also redist 1.1.1.0 from prot B back into prot A.
But what about other routers that share areas ? they don't understand this.
I'm assuming that tags is the way to solve this problem ?
And if they are moved around the area, do ALL routing protocols support the
option of tags ?
Thanks,
-marc.
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Joe Rothstein
> Sent: Tuesday, 24 August 2004 1:33 PM
> To: ccielab@groupstudy.com
> Subject: Re: distance command...
>
> Administrative distance is only locally significant and does not get
> passed to other routers.
>
> On Tuesday, Aug 24, 2004, at 03:43 Europe/Berlin, James wrote:
>
> > Hi,
> >
> > (sorry for top posting!)
> >
> > The reason is b/c administrative distance only works on a protocol
> > basis,
> > even if you use an access list to be specific of what you want.
> >
> > The problem you are seeing is that you see a prefix (i.e. 1.1.1.0/24)
> > duplicated
> > from two different routers using same ospf protocol. So your distance
> > command
> > even with ACL specification will apply distance the same on prefix
> > heard from
> > both routers, aka not accomplishing your needs.
> >
> > The solution is to set ospf cost metric on the specified routes heard
> > from
> > a specific ospf adjacency. There are various ways to do this, you can
> > set
> > cost while redistributing prefixes into ospf, or set cost on a circuit
> > (which
> > would not accomplish your even/odds goal though), or set cost while
> > summarizing them in, etc...
> >
> > It is still doable, but setting cost like this on specific per-prefix
> > basis
> > in OSPF is a bit pain in the butt. In my opinion, distance/path vector
> > based
> > routing protocols are easier to deal with for this type of scenario,
> > such as
> > RIP, EIGRP using offset lists or BGP using attribs.
> >
> > HTH,
> > -J
> >
> > On Mon, Aug 23, 2004 at 04:18:02PM -0700, Edwards, Andrew M wrote:
> >> All,
> >>
> >> I'm struggling with getting this to work in a development environment.
> >>
> >> I have four routers in a single OSPF area. There is connectivity
> >> between all routers in a full mesh. (e.g. distribution to core
> >> configuration). So, from any one core router there are 2 equal cost
> >> routes to all distribution subnets.
> >>
> >> I have setup the distribution routers to split the load on even and
> >> odd
> >> subnets. I have fixed the spanning tree root bridge selection and
> >> HSRP
> >> to reflect this in the distribution layer.
> >>
> >> What I want to do now is setup the OSPF process on the core routers
> >> such
> >> that even routes prefer router 10.10.10.25 and odd routes prefer
> >> router
> >> 10.10.10.9.
> >>
> >> I have decided to try and use distance for this:
> >>
> >> So, I match the source router-id for the 10.10.10.25 router and
> >> increment the distance of odd routes sourced from it. This should
> >> leave
> >> even routes at default distance.
> >>
> >> Next, I match the source router-id for the 10.10.10.9 router and
> >> increment the distance of even routes sourced from it. This should
> >> leave odd routes at default distance.
> >>
> >> What I expect is that the even routes would prefer 10.10.10.25 and odd
> >> routes would prefer 10.10.10.9. What I get in the routing table
> >> though
> >> is weird.
> >>
> >> I end up AGAIN with two equal cost paths to the either subnet (even or
> >> odd). The cost is the same as before (expected) and the distance for
> >> BOTH sources has incremented (not expected).
> >>
> >> Show ip route
> >>
> >> 10.10.100.0/24 [112/2] via 10.10.10.9
> >> [112/2] via 10.10.10.25
> >>
> >> Maybe I'm not implementing the distance command effectively or there
> >> is
> >> another way... I'm trying to stay away from PBR at this point and use
> >> the routing protocol... any ideas?
> >>
> >> Configs below:
> >> ------------
> >>
> >> CorerouterB:
> >>
> >> Int g1/1
> >> Ip address 10.10.10.10 255.255.255.248
> >>
> >> Int g1/2
> >> Ip address 10.10.10.26 255.255.255.248
> >>
> >> Router ospf 1
> >> Router-id 10.10.10.26
> >> Network 10.10.10.0 0.0.0.255 area 0
> >> Distance 112 10.10.10.9 0.0.0.0 20
> >> Distance 112 10.10.10.25 0.0.0.0 10
> >>
> >> Access-list 10 remark match odd subnets
> >> Access-lsit 10 permit 0.0.1.0 255.255.254.255
> >>
> >> Access-list 20 remark match even subnets
> >> Access-list 20 permit 0.0.0.0 255.255.254.255
> >>
> >>
> >> DistributionrouterA:
> >>
> >> Int g3/1
> >> Ip address 10.10.10.9 255.255.255.248
> >>
> >> Router ospf 1
> >> Router-id 10.10.10.9
> >> Network 10.10.10.0 0.0.0.255 area 0
> >>
> >>
> >> DistributionrouterB:
> >>
> >> Int g3/1
> >> Ip address 10.10.10.25 255.255.255.248
> >>
> >> Router ospf 1
> >> Router-id 10.10.10.25
> >> Network 10.10.10.0 0.0.0.255 area 0
> >>
> >> ______________________________________________________________________
> >> _
> >> Please help support GroupStudy by purchasing your study materials
> >> from:
> >> http://shop.groupstudy.com
> >>
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >
> > --
> > James Jun TowardEX
> > Technologies, Inc.
> > Technical Lead Network Design, Consulting, IT
> > Outsourcing
> > james@towardex.com Boston-based Colocation &
> > Bandwidth Services
> > cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> > www.twdx.net
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> --
> There is more to life than increasing its speed. - Mahatma Ghandi
>
>
> Joseph Rothstein
> Ridlerstr. 32
> 80339 Munich
> Germany
>
> ziutek@mac.com
> http://www.geocities.com/jozek444
> http://www.rothstein.no-ip.org/
> http://waywardgenuses.blogspot.com/
> http://ziutek.journalspace.com/
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:47 GMT-3