Solved: OSPF design question

branfarm1 · ‎07-20-2009

Hi there,

I have 3 sites, and in each site I have a collapsed core/distribution/access layer setup. I don't have any users, only servers.

There are two 4500 switches in each location, both running OSPF. The problem I'm noticing is that since I basically have all networks participating in OSPF (via network commands), I see a lot of routes like this:

O 10.3.0.0/24 [110/12] via 10.10.3.2, 00:23:40, Vlan20

[110/12] via 10.10.1.2, 00:23:40, Vlan40

[110/12] via 10.5.0.67, 00:23:40, Vlan100

[110/12] via 10.5.0.35, 00:23:40, Vlan110

Each one of those Vlan's are stub network at this particular site and really shouldn't be used as transit networks for any traffic inside the site. All of my WAN links use a specific subnet, 10.5.0.0/24. Would my best bet be to remove all of the network statements for the stub networks in each site, keep only the network 10.5.0.0 0.0.0.255 area 1 command, and add a redistribute connected command? What do you guys think?

Thanks in advance,

--Brandon

Giuseppe Larosa · ‎07-20-2009

Hello Brandon,

the passive-interface command allows to announce the ip subnets without building OSPF adjacencies on client vlans/subnets.

I prefer the passive-interface approach to the red conn because the latter method introduce O Ex routes that are less manageable.

With passive interface you still have your O or O IA routes where needed

Hope to help

Giuseppe

View solution in original post

Giuseppe Larosa · ‎07-20-2009

Hello Brandon,

the passive-interface command allows to announce the ip subnets without building OSPF adjacencies on client vlans/subnets.

I prefer the passive-interface approach to the red conn because the latter method introduce O Ex routes that are less manageable.

With passive interface you still have your O or O IA routes where needed

Hope to help

Giuseppe

branfarm1 · ‎07-20-2009

Thanks Giuseppe

Joseph W. Doherty · ‎07-20-2009

Like Giuseppe, I too like passives for this. A few more points: I've found elmination of the extra transits tends to improve OSPF stability and speed convergence (the topology graph is smaller). I've bumped into issues with more OSPF paths than whatever current limit is set for (not recently, though), passives can help avoid this. I found it sometimes worthwhile to retain a non-intentional usage transit to provide redundancy for an intended transit (i.e. you might not want to make all the "stubs" passives).