From: Omer Ansari (omer@xxxxxxxxxx)
Date: Sun Aug 18 2002 - 13:46:49 GMT-3
dmitry,
interestingly enough i was able to reproduce this behavior (and colins
workaround) pretty high up in 12.2 mainline also.
removing colin's workaround and even clearing ospf process R11 didnt put
the routes back via eigrp external (ie. the broken state)
it was only when i bounced the interface on R11 when i got back to the
broken behavior :)
if this is a bug, it doesnt seem to be fixed...so guess we should watch
out for this behaviour in the lab.
thanks for sharing this with us.
On Sun, 18 Aug 2002, Volkov, Dmitry (Toronto - BCE) wrote:
> Hi all,
>
> Tried to put the same config again.
> At the beginning I got the same as Yakout, but after clear ip ro * on R11
> I got D EX routes.
>
> Colin is right.
> If we change eigrp internal distance on R11 higher than 110 everything seems
> to be OK on R11
> Yakout, there is nothing wrong with OSPF adjacencies betw R10 & R11.
> I have 12.1(16) on R9 and R11 and 12.0(23) on R10
>
> And again If I remove OSPF from E0/0 on R10 (172.16.1.2 faced to R9) -
> Everything is OK on R11 (only O E2) Why ??
>
> r11#sh ip ospf nei
>
> Neighbor ID Pri State Dead Time Address Interface
> 172.16.5.2 1 FULL/BDR 00:00:31 172.16.5.2 Ethernet0
> r11#sh ip ospf data
>
> OSPF Router with ID (172.16.222.1) (Process ID 10)
>
>
> Router Link States (Area 0)
>
> Link ID ADV Router Age Seq# Checksum Link count
> 172.16.5.2 172.16.5.2 138 0x80000002 0xBD83 2
> 172.16.222.1 172.16.222.1 137 0x80000004 0xE269 4
>
> Net Link States (Area 0)
>
> Link ID ADV Router Age Seq# Checksum
> 172.16.5.1 172.16.222.1 137 0x80000001 0xCAAF
>
> Type-5 AS External Link States
>
> Link ID ADV Router Age Seq# Checksum Tag
> 172.16.1.0 172.16.5.2 146 0x80000001 0x9589 0
> 172.16.2.0 172.16.5.2 143 0x80000001 0xD18D 0
> 172.16.3.0 172.16.5.2 143 0x80000001 0xC697 0
> 172.16.4.0 172.16.5.2 143 0x80000001 0xBBA1 0
> 172.16.5.0 172.16.5.2 146 0x80000001 0x69B1 0
> 172.16.100.0 172.16.5.2 119 0x80000001 0xCB2D 0
> 172.16.111.0 172.16.5.2 119 0x80000001 0x529B 0
> 172.16.222.0 172.16.5.2 120 0x80000001 0x88F5 0
>
>
> Dmitry
>
>
> -----Original Message-----
> From: yakout yakout [mailto:yesmat@iprimus.com.au]
> Sent: Sunday, August 18, 2002 8:04 AM
> To: Colin Barber; Volkov, Dmitry (Toronto - BCE); ccielab@groupstudy.com
> Subject: RE: Are EIGRP external routes preferable than OSPF ext ??
>
>
> Gents,
>
> It is got to work as expected. you should be able to see O E2 route coming
> from R9.
>
> Maybe your OSPF neigbors are not forming.
>
> I just tested it and it works as expected.
>
> Yakout
> #9893
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Colin Barber
> Sent: Sunday, August 18, 2002 9:01 PM
> To: Volkov, Dmitry (Toronto - BCE); ccielab@groupstudy.com
> Subject: RE: Are EIGRP external routes preferable than OSPF ext ??
>
>
> After a bit more testing it seems that the distance for external routes is
> not being taken into account properly, it seems to be looking at the
> internal distance.
>
> If I set the distance of EIGRP to 140 on R11, when I bounce the Ethernet
> interface the EIGRP routes are installed for a short time until OSPF has
> converged and then the routes are replace by OSPF, which is correct. However
> if the distance is left a 90 the EIGRP routes remain even though they are
> external and show a distance of 170 in the routing table.
>
> The problem only occurs when the EIGRP routes a available first. Then when
> the OSPF routes are available the routing table is not updated correctly.
> When a clear ip route * is performed the routes are available from both
> EIGRP and OSPF at the same time and the router then makes the correct
> choice.
>
> I have tested this with R11 on 11.3 IOS and the same thing happens.
>
> Colin
>
> -----Original Message-----
> From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
> Sent: 17 August 2002 23:46
> To: 'ccielab@groupstudy.com'
> Subject: Are EIGRP external routes preferable than OSPF ext ??
>
>
> Hi I have simple setup:
>
> R9:(e0) (IGRP) ------(e0/0)R10(e1/0) (IGRP, EIGRP, OSPF)----(e0)R11 (EIGRP,
> OSPF)
> There is redistr between IGRP,OSPF and EIGRP on R10.
>
> So, routes from R9 are redist to EIGRP and to OSPF on R10 and received on
> R11 (via both ospf and eigrp)
>
> Somehow I see R9 loopbacks routes on R11 as learned via EIGRP (external),
> but OSPF...
> D EX has distance 170, OSPF 110, but there are no ospf routes in routing
> table on R11.
> However, they are in database as external. When I stop EIGRP on R11, I can
> see OSPF E2 routes there.
>
> If I stop ospf running on e0/0 (R10) - everything is OK - R11 see all
> external routes as O E2.
>
> Why ??
>
> R9:
> !
> interface Loopback0
> ip address 172.16.2.1 255.255.255.0
> !
> interface Loopback1
> ip address 172.16.3.1 255.255.255.0
> !
> interface Loopback2
> ip address 172.16.4.1 255.255.255.0
> !
> interface Ethernet0
> ip address 172.16.1.1 255.255.255.0
> !
> router igrp 10
> network 172.16.0.0
>
> R10:
> interface Ethernet0/0
> ip address 172.16.1.2 255.255.255.0
> no ip directed-broadcast
> !
> interface Ethernet1/0
> ip address 172.16.5.2 255.255.255.0
> no ip directed-broadcast
> !
> router eigrp 10
> redistribute ospf 10 metric 10000 100 255 1 1500
> network 172.16.0.0
> !
> router ospf 10
> redistribute igrp 10 subnets
> redistribute eigrp 10 subnets
> network 172.16.1.0 0.0.0.255 area 0
> network 172.16.5.0 0.0.0.255 area 0
>
> !
> router igrp 10
> redistribute ospf 10 metric 10000 100 255 1 1500
> passive-interface Ethernet1/0
> network 172.16.0.0
>
> R11
> !
> interface Ethernet0
> ip address 172.16.5.1 255.255.255.0
> !
> router eigrp 10
> network 172.16.0.0
> auto-summary
> no eigrp log-neighbor-changes
> !
> router ospf 10
> log-adjacency-changes
> network 172.16.0.0 0.0.255.255 area 0
>
> r11#sh ip ro
>
> Gateway of last resort is not set
>
> 172.16.0.0/24 is subnetted, 5 subnets
> D EX 172.16.4.0 [170/435200] via 172.16.5.2, 00:17:21, Ethernet0
> C 172.16.5.0 is directly connected, Ethernet0
> D 172.16.1.0 [90/307200] via 172.16.5.2, 00:35:28, Ethernet0
> D EX 172.16.2.0 [170/435200] via 172.16.5.2, 00:17:21, Ethernet0
> D EX 172.16.3.0 [170/435200] via 172.16.5.2, 00:17:21, Ethernet0
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:28 GMT-3