[c-nsp] Is there any way to prevent transit traffic through OSPF ABR/ASBR?

[Phil Mayers]

Peter Olsson wrote:
> 
> Is there a way to make sure that the WAN lines to remote sites are
> never used for transit traffic?

Use BGP with appropriate filtering so that the site routers NEVER 
re-advertise core routes. It sounds like a confederation may suit your 
purposes (which is uncommon) as it's somewhat safer and easier to filter 
routes on the eiBGP links between sub-ASes than it is to filter iBGP 
routes between a route-reflector and rr client, *and* it avoids the need 
to extend the OSPF into the remote sites at all (they can run their own 
local OSPF)

Having said that, this is not a configuration I've tried.

> 
> Could nssa be used as a solution to this problem in our scenario?

To be honest, I'm a bit puzzled - given the area structure you've 
detailed I would not expect transit via sites to ever occur (except in 
those cases where the core->site links are in area 0, which you should 
remove for this exact reason).

I don't think NSSA is relevant here - NSSA allows you to reduce the size 
of the area routing table but still advertise externals (e.g. your 
statics) which is a worth goal in some peoples opinions, but not others.

The trivial way to do this is to set the ospf cost on *both* core->site 
routes to be a very large number indeed, larger than any conceivable 
intra-core path. Of course if your core becomes partitioned then traffic 
*will* transit that pair of links, but a) so what, at least your network 
isn't down and b) you are in a disaster scenario anyway so a sluggish 
remote site is surely not an issue?

> 
> And a perhaps too general/philosophical question: How do you make
> OSPF do exactly what you want in a changing/assymetric environment? :)

You can't always force it to do certain things. The fact the link state 
database must be uniform forces certain types of behaviour. The two 
solutions you may see are distribute lists and area filter lists, but 
both are EXTREMELY DANGEROUS and SHOULD NOT BE USED.

> 
> Thanks!
>