Subject: How to handle stray type-4 in stub areas?

From: Igor Miroshnik <[email-masked]>
Date: Thu, 11 Dec 2003 13:10:18 -0500

Group,

As specified in Section 12.4.3 of RFC 2328, Type 4 summary-LSAs (ASBR-
summary-LSAs) are never originated into stub areas, just like AS-external
LSAs. But, in contrary to AS-external LSAs, ASBR-summary-LSAs are not
discarded during the flooding procedure in a stub area. (See Section 13,
step 3.) Nor routers in a stub area doubt such instances during Database
Description Exchange. I can undestand why ASBR-summary-LSAs are not simply
dropped: it would violate the consistency of LSDB throughout the area. But
why not reset the adjacency with the trespasser? Otherwise, we give up the
principle of not originating type-4 LSAs into stub areas.

Have I missed the point?

Thanks,
Igor

---

From: Don Goodspeed <[email-masked]>
Date: Thu, 11 Dec 2003 16:16:36 -0500

Igor,

Resetting an adjacency to get rid of a single LSA is a bit
harsh and usually would not do the trick.  If a router is
constantly injecting (incorrectly) a type-4 LSA into a stub
area, then your proposal would keep the adjacencies to that
router in a constant state of flux (very harmful and unneeded)
preventing "good" destinations from being reached.

Being liberal in what you accept is the edict here.  Basically,
silently ignore the type-4 LSA.  Whether or not you install it
is up to your implementation but definitely do not use it to
build any paths to ASBRs outside the area.  Essentially, you
keep one or more extra LSAs in your structure (if this is an
issue, there are larger problems in that network).

Others might have additional thoughts to add.

Cheers,
Don

============================
Group,

Have I missed the point?

Thanks,
Igor

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!