From: Joe Rothstein (ziutek@mac.com)
Date: Tue Aug 24 2004 - 00:32:45 GMT-3
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 GhandiJoseph 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/
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:47 GMT-3