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

[Morgan McLean]

Chris,

Could you elaborate on:

Just need to be careful to bridge the VLAN across the trunk link as
necessary. (i.e. only bridge what you need - switch to switch - don't use
'vlan members all').
What would be the problem if I did all? I might have say tag 2001 going to a
switch that doesn't play on that vlan, but I wouldn't have problems
necessarily would I?

Thanks,
Morgan

On Tue, Aug 30, 2011 at 11:28 PM, Chris Kawchuk <juniperdude at gmail.com>wrote:

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