MISTP configured but not so rapid: Convergence time still 50 Seconds.
Hello, I configured two 7606 running 12.2(18)SXD3 each. They are connected via an aggregated etherchannel trunk configured to be the root port or designated port depending on the different MST instances defined.
Due to some special requests, i inserted a hub (cisco 1835) with a link to an access port of every 7606 in vlan 10. I setup the designated port of the nonroot 7606 switch with a higher cost to become in blocking state. MISTP converged as expected.
The problem is that if i disconnect the link from hub to the root bridge (which was in forwarding state), then, the designated port wich was in blocking state takes 50 seconds to be in forwarding, that is, the usual transition time of 802.1d.
2) I issued the command spanning-tree link-type point-to-point in every two ports, because the ports connected to the hub are in HALF duplex, and the switch assumes that half-duplex links are shared links and full-duplex links are point-to-point links but rapid connectivity is established only on point-to-point links.
Unfortunately, the convergence time is still 50 seconds.
Re: MISTP configured but not so rapid: Convergence time still 50
RSTP/MST will not help you a lot here, however I think it should be a little bit faster.
When the link between the root and the hub fails, the alternate port stops receiving bpdus. As it does not detect the link going down, it will age out the information in 3xhello_time = 6 seconds by default.
Then this port will move from alternate to designated discarding. As it is not receiving any kind of agreement, it will take an additional 2xforward_delay = 30 seconds to go forwarding. I rather expect 36 seconds instead of 50 seconds in your case. Please make sure that the port is not in STP compatibility mode (that would be surprising.. do "show span mst" and check there is not "Bound(STP)" in the type column).
The only way to be faster would be to tune the forward delay at that stage, I don't recommend changing the hello time (not worth it). I don't think you'll be much faster unless you can replace your hub by a bridge running at least RSTP.
Also, there is something I need to mention about your setup. Be careful that MST will consider this access port as a backup link between your two core switches for instance 0 and 1. That's probably not an issue because it seems you don't rely on STP for redundancy between your core switches, but you should be aware of it.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...