FW: [c-nsp] Cisco Gigabit Ethernet Switch Module (CGESM) fortheHPBladeSystem

[Dave Temkin]

I found it's easier to skip spanning tree.  Use etherchannels from each
switch back to the core (or wherever) for redundancy, and to get
cross-switch redundancy have the servers use fail-on-fault teaming to fail
over to the other switch (which would then be connected to your alternate
core switch) in the event of a failure.

I believe the fail-on-fault technology can test for other variables such
as default gateway reachability.

Another option is to not run STP on the edge switches at all and create a
loop through them and allow the core switches to block/forward.  It
wastes an uplink (no real way to distribute load between the switches) but
it eliminates the edge switches from influencing STP.



On Tue, 4 Oct 2005, Kevin Graham wrote:

> On 10/4/05, christian.macnevin at uk.bnpparibas.com
> <christian.macnevin at uk.bnpparibas.com> wrote:
> > I'd rather this thing was a 3750 than a 2970, as it gives me a lot more room to move.
>
> As a Dell shop waiting for a similar solution for their blade chassis,
> I have been hoping the same. Being able to use the 3750's stacking
> within a rack worth of blades would be very appealing. The very low
> host:switch density that this solution forces -- a rack of blade
> chassis all of a sudden is 8 switches which either chews uplinks or
> creates spanning tree fun..
>
> (Somewhat related, but I've been looking at MST for this but don't
> think it'd be appropriate; is there an analogy between OSPF areas and
> MST regions? I'd love to have the cloud between these switches run as
> a single RSTP/RPVST+ network with the core switches they uplink to
> seeing each other as STP-adjacent without having to relegate that
> cloud to a unique set of VLANs).
>
> _______________________________________________
> 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/
>