[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on flushing AS-external LSAs
Mukesh,
Comments inline.
-don
==========
Hi,
I'm looking for an answer to how OSPF would behave in the following
scenario.
Say an ASBR advertised some AS-external LSAs and then crashed. Now, OSPF (at
least v2) only allows a router to flush LSAs that it originated. Given that
the router that originated these AS-external LSAs has crashed, would these
AS-external LSAs stay in the Link State Database of all routers in the OSPF
domain for upto an hour until they get aged out? Would these not be flushed?
>>> Yes, they would remain in each LSDB until they age to 3600. At that
time,
>>> they would then be flushed on each of the other routers.
Let's assume that the forwarding address in the AS-external LSAs was set to
the IP address of one of the interfaces on the ASBR. When SPF is run after
the Router LSA (or Summary LSA if the ASBR is in another area) to this IP
address gets flushed, would this forwarding address not being reachable
anymore cause all these AS-external routes to be deleted from the routing
table of all nodes?
>>> Not exactly. When the router crashes, presumably the mechanism send out
OSPF
>>> hello packets stops. After the router dead interval, this crashed ASBRs
neighbors
>>> will remove the transit links to this ASBR. Since there is no longer
reachability
>>> to the ASBR, no routes will be formed to any of these AS externals,
although they
>>> do remain in the LSDB until MaxAge as I already stated.
What if this ASBR that crashed was one of two ASBRs advertising the same
AS-external routes, and has the higher router ID, so that the other ASBR
flushed its AS-external LSAs. When this ASBR with higher router ID crashes,
what triggers the other ASBR to re-inject its AS-external LSAs into the
network? Would the event of forwarding address for the LSAs heard from the
other ASBR not being reachable anymore trigger it to inject its own
AS-external LSAs in the network?
>>> Once the ASBR is no longer reachable (as I indicated previously), the
other
>>> ASBR "should" detect this and re-inject any equivalent AS-externals it
had
>>> previously withdrawn due to having a lower router ID (pg 142 of
RFC2328).
>>> The only "trigger" is the fact that an ASBR is no longer reachable. How
>>> this is implemented varies from vendor to vendor.
Thanks in advance
- Mukesh