I have an OSPF area for which I wish to select which external routes enter it. This area has default routes comming from two points, so I cannot make it a stub area as to do so makes the default route injection unconditional, which I don't want.
So I can use distribute-lists to control externals on the ASBR sourcing the routes, I can use area prefix lists to filter type 3 LSAs on the ABR. I can use distribute lists on any OSPF router to prevent it from using the LSA type 5 when it receives it, but not flooding it on. I can even filter entries from the area database, a potentially very dodgy thing to do.
But I can't find any way to filter type 5s, which is essentially distance vector information, like type 3's are.
Can someone point out what I'm missing please, as this cannot actually be the case, its simply too stupid, so it must be me.
As far as I know, "distribute-list out" can only be used to prevent flooding of externals only at the advertising ASBR as you said. As per RFC 2328 (Section 2.3. Use of external routing information), "External routing information is flooded unaltered throughout the AS."
Thanks for the confirmation. It seems very odd as the externals are the thing that you are most likely to want to control. Type 5's do not convey link state information, only distance vector information so filtering them into area's is hardly going to cause a problem. Seems like a bit of an oversight to me.
Maybe you are right and this is an oversight, but I suppose it is very hard to design a protocol like OSPF. I suppose that designers when in doubt prefer the conservative option instead of the flexible (else they have to prove that the flexibility does not cause problems). Also, at the time the specification was written, the Internet was not developed as it is today. In many documents of those days you might see scenarios suggesting redistribution of BGP into OSPF, which is considered "extreme" for many years now. From the specification I infer that the general idea was to have full routing information in the OSPF routers to allow them to serve collectively as a transit backbone. The exceptions would be stubs that would have a default towards the backbone to be able to route to unknown destinations (but could not have other exit-points to external destinations), and nssa's with the potential of exit-points to external destinations (with a default either needed or not). I guess not many people could predict for sure back then how BGP and OSPF would evolve to have very distinct roles.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...