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

[Peter Olsson]

On Wed, 11 Oct 2006 09:54 +0100, Phil Mayers wrote:

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

BGP is not an option unfortunately, only OSPF in this network.

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

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.

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

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.

> 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?

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,
the filters will stop all traffic. Very bad situation. One possible
solution that we have considered is to make the filters allow transit
traffic, but that would generate a security breach if the filters aren't
adjusted when networks in the remote site changes.

Thanks!

-- 
Peter Olsson                    pol at leissner.se