Hello, We have a similar topology in one our facilities however we are not using 2950/2960's. In our environment we are using Multiple Spanning Tree instances. We then put every alternate van into a separate instance. Each instance then has an alternative root bridge at the distribution layer (superx). It works very well as we cut down on the spanning tree traffic. There are some downsides like 1. we need to make sure every switch has an identical configuration otherwise they negotiate into their own region. 2. if you update the MST configuration somewhere you really need to make that change to every switch. The benefits being that you move away from pvst which for a large number of vlans can become cpu intensive in the event of a failure. It also makes it easy to keep both uplinks from the top of rack switch active which can provide better performance. We currently have around 1200 vlans provisioned using this method and have yet to have any issues.
Regards, Jimmy Clint Chapman wrote: > hey, > > new to the list thanks to the guys at townsend, but I wanted get some > quick advice if anyone has a few. > > Interwebs ?> > > | | | > > NetIron XMR 4000 (Dual Management, 3 Switch Fabrics, Multiple Line > Cards) ?> > > || > > 2 x FastIron SuperX ?> > > || > > Rack Level Cisco 2950, 2960's > > > Right now I feel safe with just 1 XMR 4000 on the edge, and multiple > up-links to different NSP via BGP. > > But what I am looking for is, a good way to have redundancy from the > SuperX's > > Lets say rack1 have a 2960 and has an uplink to each SuperX what would > be the best way for, if distro1 goes out, to switch over to distro2. > > > With that being said, let me give a little more details about the > network. > > We currently CIDR out blocks we give to customers that rent dedicated > servers from us. So we give a client a /29, drop the gateway on distro > one in a vlan and put the switch port at the rack level in access mode. > > > Lets start there, please let me know if there are any questions. > > > > Thanks! > Clint > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp
