This is a resend - apologies if it appears twice. Or indeed three times.
Mark, thanks for your comments.
A couple of points that I didn't make clear in the first email...
Although the static route overrides the OSPF route on RTB, RTB does know about
the 50.0.0.0 network from OSPF as well - it shows up with 'show ip ospf da su'.
So there is an LSA for that network in the OSPF table on RTB.
My understanding, which you seem to confirm with your point 2, is that routing
protocols (in this case, OSPF and static routes) work independantly of one
another, and that barring redistribution, OSPF will not have any knowledge of
the existence of the static route. If this is the case, then regardless of the
layout of my routers or any other complexities, adding a static route should
make no difference to what LSAs are distributed by OSPF, and so there should be
no difference in what RTC gets.
However, these routers seem to think otherwise :-)
Unfortunately I can't bung on a debug of OSPF to see exactly what LSAs are being
transmitted - I don't think the routers would cope very well and I wouldn't be
very popular if I brought them down unexpectedly.
If somebody could confirm or deny my basic understanding of routing protocol
behaviour, it would be much appreciated, because if I'm wrong I have a lot of
studying to catch up on...
RTB is actually an MSM with lots of qualifiers in the IOS version, and RTC runs
a completely different major version of IOS, so it wouldn't surprise me too much
if this is the result of a bug.
JMcL
---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 07/11/2000 11:52 am
---------------------------
[EMAIL PROTECTED] on 06/11/2000 05:32:42 pm
Please respond to [EMAIL PROTECTED]
To: JENNY MCLEOD/NSO/CSDA@NOTES
cc: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Subject: Re: OSPF and static routes
In a message dated 11/6/00 1:12:18 AM Eastern Standard Time,
[EMAIL PROTECTED] writes:
> 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??
>
Ok, let me try to work at this one with you. I may be false or short on some
of this so somebody will correct me if I am wrong.
1.) The reason that router C is not getting anything from B (50.0.0.0) is
because, and you said it yourself, it is not redistributed on that device. A
static route has a lower admin dist. so it will be chosen. Therefor, the
summary that would be normally sent to router C via ospf is over-riden by the
static route which you have to manually place on router C. That's why when
you take out the static route, router C gets the route back. OSPF see's a
change in it's tables and recalculates. It see's that there now is a route to
50.0.0.0 via ospf and that there is no other route there with a lower admin
dist. so it is chosen and propogated. I could be wrong or incomplete on
this...
2.) You spoke of ships-in-the-night. Actually, I just read up on that in
terms of EIGRP. In EIGRP there is support for 3 protocols: IP, IPX, and
Appletalk. Inside of the EIGRP process, when it is running, these 3 protocols
(if all used) don't have anything to do with eachother. They are kind of
oblivious to each others operations and are in their own, lets say,
platforms. This is what ships-in-the-night means. None of them are dependant
on each other and they don't even care if the others exist. Hence the term
"ships-in-the-night".
I hope I helped with some of your questions. Somebody delve deeper, I know I
didn't hit this completely...
Mark Zabludovsky ~ CCNA, CCDA, 1/4-NP
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
