spanning tree blocking wrong ling

Unanswered Question
Feb 13th, 2007

I recently added two switches into our front end connection and the gig link between them is getting blocked in favor of the 100mb connection through the isp's core switches. Is there a good way to force one of the 100mb uplink connections to be blocked instead of the gig link between the switches?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)

I looked at your jpeg dwg, it appears as though the ISP is providing the "STP ROOT BRIDGE".

In this config the Gig port is blocked because it is most likely 1gb+100mb away from the root bridge. Where as the root port on the left-side 3548 has a straight 100mb pipe, in STP terms a "shorter, least cost path".

Whay would you want the inter-switch Gig port unblocked?

Both switches still only have 100mb pipes to the ISP switches?

3msands Tue, 02/13/2007 - 13:04

the primary reason that I put the switches in place was that between the core isp switches and the firewalls there are a pair of idp's that while transparent have a bad habit of occasionally interfering with the vrrp multicast traffic between the firewalls. I want the firewall failover traffic to stay on the local switches rather than passing out to the the core switches and possibly getting blocked. It's ok to block one or the other of the uplink connections to the core switch as only one firewall is active in the cluster at a time anyways.

Francois Tallet Tue, 02/13/2007 - 12:39

The cost to the root bridge is lower via the fast-ethernet than through the gigabit link. Just put a very high cost on the fast ethernet interface you want to block if you don't want to think to much about the details;-).



Francois Tallet Tue, 02/13/2007 - 14:42

Let me restate this in a less dramatic way;-)

It is perfectly true that changing the root cost on a bridge may indeed have an impact on the topology of the tree below this bridge. I don't know where the root is in this diagram. Supposing that it is in the ISP area, by modifying the cost on fa0/47 on one of the 3548, it is possible that the other blocked port (breaking the loop between the two 3548 and the two 6500) moves. That's why I was saying, almost tongue in cheek, that you can configure a very high cost if you don't want to think to much about stp. If you want avoid any change in the topology below the 3548, you must configure on fa0/47 a cost so that it is just a little bit higher than the root path cost on the gig0/1.

Now, that said, I really disagree with the statement that changing a cost is "forcing STP out of its designed operation". It's just like saying that changing the ospf cost of an interface is "forcing ospf out of its design operation". There is nothing special about the STP cost. Just like with ospf, the cost is an STP parameter that is designed to be tuned in order to influence the final topology of the tree. You cannot break STP by configuring a cost, you may just end up with a tree that does not look the way you wanted.

The only STP parameters that you should not mess around too much are the timers. The overall idea that configuring anything STP related might affect its stability is one of the many myths associated with this protocol.




This Discussion