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

[Phil Mayers]

Peter Olsson wrote:
> 
> BGP is not an option unfortunately, only OSPF in this network.

Ah.

>> 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).
> 
> We sometimes get this situation when lines between two core nodes go down.
> There are remote sites which connect to both of these nodes, and have both
> their WAN lines up and working. Then some traffic goes through that remote
> site instead of taking the longer redundant way through the network of 
> nodes.

Ok, but are those WAN links in area 0 or area X (and what type of area 
is area X)?


> We have considered that, but ospf cost manipulation will probably require
> manual reconfiguration whenever there are bandwidth upgrades? Otherwise
> the remote site will still load balance its traffic based on the old static
> ospf cost. Static ospf cost could be the way we must solve the problem, but
> a more automatic solution would be preferred if possible.

I was assuming the links to the core were equal-cost. If not, then yes 
this is tedious, but I can't see a way around it (except maybe one, see 
below)

> 
>> Of course if your core becomes partitioned then traffic
> 
> The problem isn't so much sluggish remote sites but a filter problem.
> All remote sites have filters on their WAN links, and these filters
> don't allow transit traffic. So while the routing says it's an ok path,


Ah.

I suppose, these being ciscos, there might be a solution where you could 
run two OSPF processes on the site routers, like so:

router ospf 1
  redistribute ospf 2 route-map site2core
router ospf 2
  redistribute ospf 1 route-map core2site

Have the core2site route maps set the tag=1, have the site2core maps 
drop any routes with tag=1

Nasty, nasty, nasty.