02-13-2007 12:22 PM - edited 03-05-2019 02:20 PM
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?
02-13-2007 12:30 PM
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?
02-13-2007 01:04 PM
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.
02-13-2007 12:39 PM
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;-).
Regards,
Francois
02-13-2007 01:23 PM
As tfallet correctly described earlier, you can change the portcost of fa interface to be higher than the whole path via the gig link, but I would strongly recommend you lab test the possible negative ramifications of forcing STP out of it's designed operation.
Good luck
02-13-2007 02:42 PM
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.
Regards,
Francois
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide