[j-nsp] Running OSPF to manage loopbacks, only have trunks

[Chris Kawchuk]

On 2011-08-31, at 4:12 PM, Morgan McLean wrote:

> Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right?
> 
> Chris, thanks for the reply; thats what I was sort of leaning towards. I still think even that is sort of an ugly solution, and like I mentioned in my original email I thought that in a big enough network it still might not scale but...I think it might be nearly impossible to get to that point. 
> 
> Any other ideas? So far thats my #1 I think.

Agreed - it's not pretty.

Dale's idea is the simplest and the most straightforward. 

- VLAN800 is simply bridged everywhere, and every core/access switch has a vlan.800 RVI into that shared LAN. 
- Core switches run OSPF passive (to inject reachability of the management LAN IP Block) on vlan.800
- Core switches run VRRP between each other on vlan 800 (floating the proverbial '.1' out of the LAN)
- Access switches default route to the VRRP .1 address anchored on the aforementioned core switches.
- No need for loopback IPs / Router-IDs
- No need to build an OSPF area, nor an OSPF database
- All switches are 1 hop away, routing-wise.

Assuming you already have some kind of loop-avoidance mechanism (RSTP, RTGs, LAG Groups, or combinations thereof...) you shouldn't run into any broadcast-related issues. You're just as likely to run into bridging loops on the rest of our VLANs as you are on this one. (This one is simply no different than any of the other VLANs in the Access Network).

Downside is that it doesn't show you the undelrying topology if that's important to you.

Anyways, we designed ours to scale to approx 700 switches total. (was a specific need we had for a specific access network in the wireless/mobility space. We'd never be putting in more than 700 switches due to geographical constraints - so we knew our maximum scale beforehand).

- Chris.