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 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?
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.
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;-).
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.
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...