[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
[EMAIL PROTECTED]
"Even if I knew I had only 1 more week to live, I would still schedule
my CCIE lab. I would just have to work a little harder I guess. After all,
without any goals in life, I'm dead already."
~Mark Zabludovsky~
