As a network engineer that works on spanning-tree daily, I can certainly appreciate the complexity of the situation. Spanning Tree in itself is a fairly easy protocol to understand. But, when combining it with HSRP, VTP, Trunking protocols, Ether(or gigE)channels, inter-vlan routing, etc things can quickly become out of hand.
The problem most certainly could have been resolved quicker with proper documentation of the as-built network. Cisco is no slob at solving these things. With all the manpower they put behind this, I'd have to say the team of StormTroopers sent by Cisco had to actually had to first document the as-is network before they could really pinpoint the problems.
I don't really agree with the second additional network.. Now we can have two broken things instead of one. Any time you increase your redundancy you also increase complexity. I think that this will serve as a good lessons learned for the IT staff there.
Slashdot Mirror
As a network engineer that works on spanning-tree daily, I can certainly appreciate the complexity of the situation. Spanning Tree in itself is a fairly easy protocol to understand. But, when combining it with HSRP, VTP, Trunking protocols, Ether(or gigE)channels, inter-vlan routing, etc things can quickly become out of hand. The problem most certainly could have been resolved quicker with proper documentation of the as-built network. Cisco is no slob at solving these things. With all the manpower they put behind this, I'd have to say the team of StormTroopers sent by Cisco had to actually had to first document the as-is network before they could really pinpoint the problems. I don't really agree with the second additional network.. Now we can have two broken things instead of one. Any time you increase your redundancy you also increase complexity. I think that this will serve as a good lessons learned for the IT staff there.