Don't forget you could use summarization to make routes learned from one
neighbor less specific which would still provide redundancy.
Lloyd
________________________________
From: nobody_at_groupstudy.com on behalf of Chris Breece
Sent: Fri 5/22/2009 6:18 PM
To: ccielab_at_groupstudy.com
Subject: Re: OSPF Distance Command .!
" I never bothered with worrying about the AD ... although perhaps that was
the preferred solution. "
Hey Andrew,
Funny you said that, because when I read your email, I thought your solution
was better. Probably woulda been easier to cost instead of trying to do it
with AD :P. The scenario I had, I think a route-map on one of my
redistribution points that matched a set of routes and set a better ospf
cost would have have be some added redundancy I lost. Man, there really is
100 ways to skin a cat, huh?
Chris
On Fri, May 22, 2009 at 6:00 PM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
> Hey team,
>
> Not to change the topic too much ... but I had a practice lab pretty
> similar, in which I had a router with two neighbors, off of two different
> interfaces. Two equal routes showed up in the routing table, one from each
> neighbor, and the lab asked me to prefer the path out of only one of the
> neighbors.
>
> I changed the cost on one interface and the desired outcome was achieved.
> To be sure, i cleared ospf, cleared the routing table and even rebooted the
> routers at the end of the night. Next day, the desired behavior was still
> present, and the router was still preferring the routes from only one of
the
> neighbors. Nothing too fancy ... and after reading this long thread, I
> realize that I need to practice setting the AD for a particular neighbor
...
> ;-)
>
> An interesting caveat is this ... if another router has redist into OSPF
> and used a default type E2. This default type, E2, can not change it's
cost
> when it gets advertised across the network. So the method os using
> interface cost will not work.
>
> To be quick about it, I changed and redid the redistribution and this time
> chose type 1 instead of the deafult type. I never bothered with worrying
> about the AD ... although perhaps that was the preferred solution. HTH,
>
>
> Andrew Lee Lissitz
>
>
>
>
> On Fri, May 22, 2009 at 12:07 PM, Paul Cosgrove
<paul.cosgrove_at_gmail.com>wrote:
>
>> It might be clearer for other people if you replied to my email about that
>> topology. When you are testing OSPF I recommend you shut interfaces
between
>> all routers before clearing the process on each. Otherwise, in many
>> instances you can see very different behaviour (especially with external
>> routes).
>>
>> I do not know if the behviour which I see in my lab applies to all
>> releases, which was why I included the IOS version and router model.
>> Perhaps it is different, perhaps not. The version of IOS you are using
>> may contain a bug, perhaps mine does. Try the same release as me if you
>> wish to like: c7200-k91p-mz.122-25.S15. The point is that selection of
>> external routes follows very different rules to that of internal routes,
and
>> you don't need to take my word for it as the rfc's contains the details.
>>
>> Paul.
>>
>> Divin Mathew John wrote:
>>
>>> Paul Cosgrove,
>>>
>>> I tried your topology..
>>> R3
>>> / \
>>> R1 R2
>>> \ /
>>> R0
>>>
>>> R3 does not run any routing protocols, but has Lo0: 3.3.3.3 for testing.
>>> R1 and R2 both have static routes to R3's loopback.
>>> R0, R1 and R2 run OSPF between each other.
>>>
>>> this is my config
>>> ***********************
>>> R0********************
>>> ***********************
>>> interface Loopback0
>>> ip address 100.100.100.100 255.255.255.0
>>> !
>>> interface Serial0/0
>>> ip address 10.1.1.1 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/1
>>> ip address 20.1.1.1 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/2
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> interface Serial0/3
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> router ospf 1
>>> router-id 100.100.100.100
>>> log-adjacency-changes
>>> network 10.1.1.1 0.0.0.0 area 0
>>> network 20.1.1.1 0.0.0.0 area 0
>>> network 100.100.100.100 0.0.0.0 area 0
>>> !
>>> ip http server
>>> ip forward-protocol nd
>>> !
>>>
>>> ***********************
>>> R1********************
>>> ***********************
>>> interface Loopback0
>>> ip address 1.1.0.1 255.255.255.0
>>> !
>>> interface Serial0/0
>>> ip address 10.1.1.2 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/1
>>> ip address 13.1.1.1 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/2
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> interface Serial0/3
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> router ospf 1
>>> router-id 1.1.0.1
>>> log-adjacency-changes
>>> redistribute static subnets
>>> network 1.1.0.1 0.0.0.0 area 0
>>> network 10.1.1.2 0.0.0.0 area 0
>>> !
>>> ip http server
>>> ip forward-protocol nd
>>> ip route 3.3.0.3 255.255.255.255 Serial0/1 13.1.1.2
>>> !
>>> ***********************
>>> R2********************
>>> ***********************
>>> interface Loopback0
>>> ip address 2.2.0.2 255.255.255.0
>>> !
>>> interface Serial0/0
>>> ip address 20.1.1.2 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/1
>>> ip address 23.1.1.1 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/2
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> interface Serial0/3
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> router ospf 1
>>> router-id 2.2.0.2
>>> log-adjacency-changes
>>> redistribute static subnets
>>> network 2.2.0.2 0.0.0.0 area 0
>>> network 20.1.1.2 0.0.0.0 area 0
>>> !
>>> ip http server
>>> ip forward-protocol nd
>>> ip route 3.3.0.3 255.255.255.255 Serial0/1 23.1.1.2
>>> !
>>> ***********************
>>> R3********************
>>> ***********************
>>> !
>>> interface Loopback0
>>> ip address 3.3.0.3 255.255.255.0
>>> !
>>> interface Serial0/0
>>> ip address 13.1.1.2 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/1
>>> ip address 23.1.1.2 255.255.255.252
>>> serial restart-delay 0
>>> !
>>> interface Serial0/2
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> interface Serial0/3
>>> no ip address
>>> shutdown
>>> serial restart-delay 0
>>> !
>>> ip http server
>>> ip forward-protocol nd
>>> !
>>> !
>>> !
>>>
>>> and this is my routing table at R0
>>> R0#sir
>>> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
>>> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
>>> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
>>> E1 - OSPF external type 1, E2 - OSPF external type 2
>>> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
>>> level-2
>>> ia - IS-IS inter area, * - candidate default, U - per-user static
>>> route
>>> o - ODR, P - periodic downloaded static route
>>>
>>> Gateway of last resort is not set
>>>
>>> 1.0.0.0/32 is subnetted, 1 subnets
>>> O 1.1.0.1 [110/65] via 10.1.1.2, 00:00:01, Serial0/0
>>> 2.0.0.0/32 is subnetted, 1 subnets
>>> O 2.2.0.2 [110/65] via 20.1.1.2, 00:00:01, Serial0/1
>>> 100.0.0.0/24 is subnetted, 1 subnets
>>> C 100.100.100.0 is directly connected, Loopback0
>>> 3.0.0.0/32 is subnetted, 1 subnets
>>> O E2 3.3.0.3 [110/20] via 20.1.1.2, 00:00:01, Serial0/1
>>> [110/20] via 10.1.1.2, 00:00:01, Serial0/0
>>> 20.0.0.0/30 is subnetted, 1 subnets
>>> C 20.1.1.0 is directly connected, Serial0/1
>>> 10.0.0.0/30 is subnetted, 1 subnets
>>> C 10.1.1.0 is directly connected, Serial0/0
>>>
>>> It does Load balancing.!
>>>
>>> R0#show ip ospf neighbor
>>>
>>> Neighbor ID Pri State Dead Time Address
>>> Interface
>>> 1.1.0.1 0 FULL/ - 00:00:38 10.1.1.2
>>> Serial0/0
>>> 2.2.0.2 0 FULL/ - 00:00:34 20.1.1.2
>>> Serial0/1
>>>
>>> i did try shutting interafces... clear ip route * , clear ip ospf process
>>>
>>> no change in the OUTcome.!
>>>
>>> Thanking You
>>>
>>> Yours Sincerely
>>>
>>> Divin Mathew John
>>> divinjohn_at_gmail.com
>>> divin_at_dide3d.com
>>> http://www.dide3d.com
>>> +91 9945430983
>>> +91 9846697191
>>> +974 5008916
>>> PGP PUBLIC KEY BLOCK @ http://www.dide3d.com/divin_Public_PGP_key.txt
>>> Sent from Bangalore, KA, India
>>>
>>> On Fri, May 22, 2009 at 8:59 PM, Paul Cosgrove <paul.cosgrove_at_gmail.com
>>> >wrote:
>>>
>>>
>>>
>>>> Hi Sadiq,
>>>>
>>>> I would have to recommend trying it again yourself, as it does work:
>>>>
>>>> R1 ----- R2
>>>> \ /
>>>> \ /
>>>> \ /
>>>> R0
>>>>
>>>> All links are network type point to point. Shutdown interfaces, cleared
>>>> ospf process, no shut and waited for neighbors to establish.
>>>>
>>>> R0 then shows the following:
>>>>
>>>> Gateway of last resort is not set
>>>>
>>>> O 192.168.12.0/24 [110/128] via 192.168.20.2, 00:00:58, Serial1/1
>>>> [110/128] via 192.168.10.1, 00:00:58, Serial1/0
>>>> 1.0.0.0/32 is subnetted, 1 subnets
>>>> O 1.1.1.1 [110/65] via 192.168.10.1, 00:00:58, Serial1/0
>>>> 2.0.0.0/32 is subnetted, 1 subnets
>>>> O 2.2.2.2 [110/65] via 192.168.20.2, 00:00:58, Serial1/1
>>>> C 192.168.10.0/24 is directly connected, Serial1/0
>>>> C 192.168.20.0/24 is directly connected, Serial1/1
>>>> 10.0.0.0/32 is subnetted, 1 subnets
>>>> C 10.10.10.10 is directly connected, Loopback0
>>>>
>>>> R0(config)#access-list 10 permit 192.168.12.0
>>>> R0(config)#router ospf 1
>>>> R0(config-router)#distance 90 1.1.1.1 0.0.0.0 10
>>>> R0(config-router)#do sh ip ro
>>>> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
>>>> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
>>>> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
>>>> E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
>>>> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
>>>> level-2
>>>> ia - IS-IS inter area, * - candidate default, U - per-user static
>>>> route
>>>> o - ODR, P - periodic downloaded static route
>>>>
>>>> Gateway of last resort is not set
>>>>
>>>> O 192.168.12.0/24 [90/128] via 192.168.10.1, 00:00:05, Serial1/0
>>>> 1.0.0.0/32 is subnetted, 1 subnets
>>>> O 1.1.1.1 [110/65] via 192.168.10.1, 00:00:05, Serial1/0
>>>> 2.0.0.0/32 is subnetted, 1 subnets
>>>> O 2.2.2.2 [110/65] via 192.168.20.2, 00:00:05, Serial1/1
>>>> C 192.168.10.0/24 is directly connected, Serial1/0
>>>> C 192.168.20.0/24 is directly connected, Serial1/1
>>>> 10.0.0.0/32 is subnetted, 1 subnets
>>>> C 10.10.10.10 is directly connected, Loopback0
>>>> R0(config-router)#
>>>>
>>>> AD can and is often used to differentiate routes in the same protocol.
>>>> EIGRP externals and BGP internal routes being some obvious examples.
>>>> Paul.
>>>>
>>>>
>>>>
>>>> Sadiq Yakasai wrote:
>>>>
>>>>
>>>>
>>>>> Gents, a little search over GS archives would second Bryan's point!
>>>>> This
>>>>> issue hunted me down in my first attempt!
>>>>>
>>>>> While some have even gone to TAC, others have tried bugging it! But
>>>>> from
>>>>> the
>>>>> research I carried out a while ago, my conclusion is you are not to use
>>>>> AD
>>>>> to influence prefix selection WITHIN the same routing protocol - use
>>>>> metric
>>>>> instead! BETWEEN 2 or more routing protocols, use AD.
>>>>>
>>>>> Otherwise, you are in for a long, unreliable and incoherent exercise.
>>>>>
>>>>> Sadiq
>>>>>
>>>>> On Fri, May 22, 2009 at 3:23 PM, Bryan Bartik <bbartik_at_ipexpert.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Divin, I think you hit it right on :) I have labbed this several times
>>>>>> before and what I found was that you cannot use AD to prefer one ospf
>>>>>> route
>>>>>> over another in the same ospf process (There may be crazy scenarios
>>>>>> where
>>>>>> you can, but I don't recall finding any). Makes sense, since like you
>>>>>> said
>>>>>> AD is to prefer one protocol over another. You could place the link to
>>>>>> R1
>>>>>> in
>>>>>> another process on R0 and then change the distance in that process.
>>>>>>
>>>>>> Bryan Bartik
>>>>>> CCIE #23707 (R&S), CCNP
>>>>>> Sr. Support Engineer - IPexpert, Inc.
>>>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>>>>>>
>>>>>>
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>
>>>>>>
>>>>>>
Received on Fri May 22 2009 - 19:20:19 ART
This archive was generated by hypermail 2.2.0 : Mon Jun 01 2009 - 07:04:43 ART