Filtering OSPF Type 5 LSA's

baldy · ‎02-18-2009

Hi Chaps,

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.

Thanks

Pete

Giuseppe Larosa · ‎02-18-2009

Hello Pete,

actually OSPF LSA type 5 cannot be filtered.

You can play with OSPF area types, for example you can use an OSPF NSSA area to be able to accept external routes within the area and to decide to convert LSA type 7 to LSA type 5 at area border.

This comes probably from the fact that LSA type 5 flooding scope is domain wide.

to be noted with NSSA area the ABR doesn't generate an O IA default route automatically.

but unfortunately it cannot be conditioned with a route-map

area area-id nssa [no-redistribution] [default-information-originate [metric] [metric-type]] [no-summary]

You can see this as a protocol characteristic coming from its link state nature, or as a limit.

Hope to help

Giuseppe

marikakis · ‎02-18-2009

Pete,

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."

Kind Regards,

M.

baldy · ‎02-18-2009

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.

marikakis · ‎02-18-2009

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.