[c-nsp] OSPF - Prefer inter-area over intra-area

David Coulson david at davidcoulson.net
Fri Mar 14 23:05:53 EDT 2008


Why not make your life easy and just run BGP between them? Do a default 
originate towards A & B (that is from hub->A, hub->B, A->B, B->A) and 
use local preference to handle the best path arrangement. Same for 
routes originated at A or B. Should be a pretty brain dead 
configuration, I would have thought. Run private AS on it all, and if 
things end up going upstream you can pop the private AS off the path and 
push your real one on instead.

It's too late, but I can't wrap my brain around you running A & B as the 
same stub area. If you need to run OSPF at each location, I'd probably 
prefer to handle each as their own AS and not integrate them all. I've 
done pretty much what you already have using a stub area with OSPF, but 
I didn't care too much about the A&B talking without going via area 0.

I take it there is more to OSPF than just these three links at each 
location?

nachocheeze at gmail.com wrote:
> We have a client with a network that's got a main hub site and two
> 'remote' sites.  By remote, I mean they're far enough away to have to
> be connected by leased metro 1 Gb Ethernet circuits.  However, one of
> the "this is just how it is" items is that the two remotes are
> actually only a couple of blocks away from each other.  The client has
> purchased and installed a wireless radio link (also 1Gb) between the
> two sites.
>
> So what we have right now is pretty much this:
>
>             Area 0
>           Main HUB
>                /   \
>               /     \
>              /       \
> Circuit   /         \   Circuit
>            /           \
>           /             \
>          /               \
>         /                 \
> Site A------------------Site B
>             Wireless
>
> The Main Hub connects to the local enterprise OSPF area 0.  Site A was
> rolled out as a non-zero stub area (let's say 'area 666'), with one of
> the routers in the Hub acting as it's area border router (sending it a
> default).  Site B is different legacy install, put in a long time ago,
> and currently connects back to site A as a non-routed vlan trunking
> interface.  The client wants to remove the trunking bits and make site
> B a routed connection, and use the wireless link between A & B to back
> up each remote site if either of the metro circuits break.
>
> I've considered making site B the same OSPF stub area as site A so
> that the OSPF learned default from the hub can route traffic from both
> sites back to the hub if either leased circuit goes down.  That works,
> but the problem with that is that since site A and site B would be the
> same OSPF area, traffic between site A and site B would always take
> the wireless path (intra-area routes are always preferred to
> inter-area routes).  The client doesn't want that; since the leased
> lines are considered "better" than the el-cheapo wireless, they want
> all traffic from the remotes to come back to the hub (even traffic
> that is from A-to-B) unless they can't due to a carrier circuit
> failure.  Seems like what they want is something like an "on-demand
> OSPF dial backup", but instead of old school ISDN, they want it to be
> the wireless link.
>
> I suppose I could redo OSPF and make both sites A and B part of the
> OSPF area 0; then set a low metric on the wireless link between the
> two.  But then I lose the OSPF learned default route from the hub site
> that I get from the stub area implementation, and have to use static
> defaults or else originate a default from somewhere else upstream
> (which I'm loathe to do at this point for various reasons).
>
> What kind of options would I be looking at?
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


More information about the cisco-nsp mailing list