OSPF in ethernet L2 WAN w dual router and unequal bandwidth in same subnet

[darkbeer]

Hello all,

our company gets a new Ethernet WAN. I am looking for a working dynamic routing design.

The company more or less wants me to use ospf.

(But i am open to an alternative if there is a good reason)

The WAN consists of one or more vlans. The provider puts a SP-VLAN on his infrastructure for the company, and we are

able to put Customer-VLANS on top of it as needed.

I intend to use as few as possible vlans for the WAN cloud.

We will have 2 routers at each remote site, each connected via ethernet with different bandwidth!! to the WAN cloud/vlan.

My main problem is, if i define one single vlan as WAN, that the primary router at each remote site sees all other

neighbors in the WAN subnet with identical metrics, but their bandwidth is different. I don't have an idea

how to tell ospf that some of the next hops in that single broadcast domain are less preferabl than others.

Here is what i tried:

## Having one single cloud for wan: (single customer-vlan)

- easy to configure

- number of neighbors might be a problem (can grow up to approx 60 neighbors)

- backup router at each site has an high ouput cost that forces traffic to go to the primary router. So far so good.

- primary router with low cost sees all other sites in that cloud with equal metric, even the other sites have

fast and slow ethernet uplinks into the cloud.

##Having one cloud (customer vlan) for primary connections, one cloud (customer vlan) for backup connection.

  Backup basically works, BUT:

when the HQ primary connection fails, any other site might act as a transit between primary cloud and backup cloud.

I intended to use a distribute-list out to prevent remote sites from transit, but distribute-list out is not supported in ospf.

So how can i solve this? What might be a good design for that?

Can another routing protocl solve that?

[Giuseppe Larosa]

Hello Hoedl,

in interface mode

ip ospf network point-to-multipoint non-broadcast

! this is a Cisco proprietary extension to RFC2328 point-to-multipoint mode

allows to define per neighbor cost on HQ routers in router ospf process context

or even easier: define one vlan for primary routers with lower costs, one vlan for secondary routers with higher ospf costs (also on HQ side)

this should give you the correct behaviour without involving point-to-multipoint and neighbor commands

Also if possible avoid to have more then 20 neighbors for the HQ routers on the same LAN segment, OSPF DR and OSPF BDR for segment if using the standard network broadcast type causes high load

Hope to help

Giuseppe

[darkbeer]

Hello Giuseppe

Thanks for your answer. So this is more the approach that i mentioned in my drawing #2 (working with a primary cloud and a backup cloud).

This would decrease the number of neighbors in each cloud which would ne nice.

But: If the primary link in the Headquarter fails, how do i prevent a remote site becoming a transit site, routing between the primary and backup cloud.

As i mentioned, the route filtering capabilities in ospf are very limited.

One solution might be to have 2 routers at the remote site, each of them announces the remote campus lan into the backbone, but i do not exchange ospf information b-e-t-w-e-e-n the two remote site routers on their campus lan.

That would work with 2 routers at the remote site i guess, but what if i have only one router at a remote site with 2 uplinks to the core.

How can i prevent a remote site becoming a transit site if the HQ primary link fails..

[Giuseppe Larosa]

Hello Hoedl,

>> How can i prevent a remote site becoming a transit site if the HQ primary link fails..

just have the cost of link between two routers of the same remote site high enough to make the use of this path not interesting.

for example you can use ip ospf cost 1000 on that link on both sides of the link

(this applies if we are in OSPF single area)

if using multiple areas some other thoughts are needed

Edit:

above suggestion can work only if all client vlans are directly connected to both routers in each remote site otherwise can lead to a problem.

and all client vlans need to be made passive-interface.

Hope to help

Giuseppe