Frank,
Many thanks for testing that. I'm glad I don't have to completely throw out my
previous ideas on routing. Everyone else around here seemed to be accepting
this as normal behaviour and I thought I must be losing the plot (OK, so bugs
*are* normal behaviour...).
I've had a look at Cisco's bug navigator, and there are a couple of bugs that
might be causing this - bit hard to tell from their descriptions. There are
quite a few weird and wonderful OSPF bugs in that release so I'm putting my
money on that. Mind you, most of them seem to involve extra unwanted LSAs in
the database, not too few!
Priscilla, thanks for your comments - you're correct that a floating static
wouldn't achieve what I need - I'm specifically intending to override OSPF in
this case. However prompted by your comment, I tried increasing the admin
distance to 10 (I have seen slightly peculiar behaviour before with admin
distance of 1 or 0). That didn't make any difference, though.
For those that are interested, having looked at it a bit further, it appears
that the LSA is 'lost' on RTB, when distributing from Area 0 to RTC's area (area
61). 'show ip ospf da' on RTB shows the summary network appearing in the Area 0
database, learned from RTA, but for area 61 there is no entry learned from RTB
itself (there is an entry learned from another router - call it RTB1 - I
mentioned there is redundancy). For an equivalent summary of a different
address, with no matching static route, there is an entry for area 61 learned
from RTB, as well as the entry for area 0. So the problem isn't with RTB
distributing to RTC, it's the inter-area distribution on RTB.
(actually, Frank, there's a bit of a difference between your setup and mine - in
mine, RTB is an ABR).
Given that I have a workaround (using the redundant router - and the static is
supposed to be a short-term kludge anyway, so it's a bandaid on a kludge now
:-), I don't think I'll be going to the hassle of breaking the network to try to
identify and fix this - my opportunities for playing with this are rather
limited. If anyone wants to exercise their minds and dig deeper, I am quite
happy to help with further details of versions, config excerpts and other info
though.
JMcL
---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 09/11/2000 11:08 am
---------------------------
Priscilla Oppenheimer <[EMAIL PROTECTED]> on 09/11/2000 06:08:58 am
Please respond to Priscilla Oppenheimer <[EMAIL PROTECTED]>
To: "Frank B." <[EMAIL PROTECTED]>
JENNY MCLEOD/NSO/CSDA@NOTES
[EMAIL PROTECTED]
cc:
Subject: Re: OSPF and static routes
I'm really glad someone tested it! Your results mean that we aren't losing
our minds. Just one question, did you misspeak here:
"When I issued the same command while the
router was configured without the static it indicated it was being
learned via 10.1.1.1 and being redistributed into ospf."
You don't mean redistributed, do you? It's part of the OSPF database in
this case, isn't it? Just want to make sure we're on the same page. Thanks.
Priscilla
At 11:20 PM 11/7/00, Frank B. wrote:
> Jenny & "da group",
>
> Like many of you I'm studying for the lab--big date(s) are
>21/22 June. This one caught my eye so I attempted to duplicate it as
>best I could...I set up the following lab:
>
> RTR~D<--serial-->RTR~A<--Eth-->RTR~B<--Eth-->RTR~C
> 2500 2500 7507 2500
> Aera 1 Area 1/0 Area0 Area 0/2
>
> RTR~D
> interface Ethernet0
> ip address 50.0.0.1 255.0.0.0
> !
> interface Serial1
> ip address 10.3.3.1 255.255.255.0
> !
> router ospf 4
> network 10.3.3.0 0.0.0.255 area 1
> network 50.0.0.0 0.255.255.255 area 1
>
> RTR~A
> !
> interface Ethernet0
> ip address 10.1.1.1 255.255.255.0
> !
> interface Serial1
> ip address 10.3.3.2 255.255.255.0
> !
> router ospf 1
> network 10.1.1.0 0.0.0.255 area 0
> network 10.3.3.0 0.0.0.255 area 1
>
> RTR~B
> interface Ethernet0/0
> ip address 10.1.1.2 255.255.255.0
> !
> interface Ethernet0/2
> ip address 10.2.2.2 255.255.255.0
> !
> router ospf 1
> network 10.1.1.0 0.0.0.255 area 0
> network 10.2.2.0 0.0.0.255 area 0
>
> RTR~C
> !
> interface Ethernet0
> ip address 10.2.2.1 255.255.255.0
> !
> router ospf 69
> network 10.2.2.0 0.0.0.255 area 0
>
> ------------------------------------------------
>
> I was unable to duplicate the problem...I did verify that the 7507
>(RTR~B) removed the inter-area for 50.0.0.0 from it's routing table
>route learned via RTR~A when configured with the static route--as
>expected. However, the LSA was passed to RTR~C under both
>configurations.
>
> While the static was configured I issued "sh ip route 50.0.0.0" on
>RTR~B and it showed known via static and DID NOT indicate
>"redistributing via ospf X." When I issued the same command while the
>router was configured without the static it indicated it was being
>learned via 10.1.1.1 and being redistributed into ospf.
>
>I expected those results but I was curious just the same. The bottom
>line in our lab scenario above, existance of the static route only
>affected the routing table of the router on which the static was
>entered. Further, the link state database on RTR~C also appeared to have
>the same contents with both configs on RTR~B.
>
> I'm convinced this is proper behavior for ospf. If you're seeing
>something else you may very well have stumbled upon a not-so-uncommon
>IOS bug. I may have overlooked something though...it's been known to
>happen ;-) Comments are welcome. Aloha, Frank
>
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Had a problem today that doesn't make much sense to me.
> > >
> > > Very simplified layout (hopefully not oversimplified...)
> > >
> > > RTA -- RTB -- RTC
> > >
> > > RTB gets a summary LSA for a network, call it 50.0.0.0, from RTA. This
> > summary
> > > LSA is visible with the command 'show ip ospf da su'.
> > > There is also a static route for 50.0.0.0 on RTB, with admin distance 1.
> > Not
> > > surprisingly, this overrides the OSPF route in RTB's routing table. The
> > static
> > > route is NOT redistributed into OSPF.
> > >
> > > RTB is adjacent with RTC. However the summary LSA for 50.0.0.0 does not
> > get to
> > > RTC (as shown by 'show ip ospf da su'), and RTC has no route to 50.0.0.0
> > (as
> > > shown by 'show ip ro').
> > > If the static route is taken off RTB, OSPF sends the summary LSA to RTC
> > again,
> > > and an OSPF route to 50.0.0.0 shows up in RTC's routing table.
> > >
> > > I was under the impression that routing protocols are generally 'ships in
> > the
> > > night' in their operation (in that they each work out what they consider
> > to be
> > > the best route, and then the routing process chooses between routing
> > protocols).
> > > Why does adding a static route (not redistributed) affect what LSAs OSPF
> > sends?
> > > Shouldn't RTC get sent the summary LSA even though RTB has a better
> static
> > route
> > > - how does the OSPF process on RTB even know about the existence of the
> > static
> > > route??
> > >
> > > Am I missing something really basic here?
> > > The layout is in reality rather more complex - the RTA-RTB link is in the
> > > backbone area, the RTB-RTC link is in a different area, and the summary
> > route
> > > originates from a third area. There are also redundant routers involved.
> > If
> > > you have any theories that involve complexities like this, I can give
> more
> > > detail.
> > >
> > > Ta,
> > > JMcL
> > >
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
