cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6741
Views
0
Helpful
12
Replies

what is th eminimum convergence time with MSTP 0 Catalyst 3750

yoram12345
Level 1
Level 1

Hi all ,

I have configured a very small LAN betwee 3750 switches

I have configured the MSTP to regioen 0 with minimum timers, however switching time is 10 sec.

Can't i achieve 1 sec as in RSTP ?

Pls  find teh sh spannning tree status :

MST00
  Spanning tree enabled protocol mstp
  Root ID    Priority    32768
             Address     0015.faa0.4b80
             This bridge is the root
             Hello Time   1 sec  Max Age  6 sec  Forward Delay  4 sec

  Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)
             Address     0015.faa0.4b80
             Hello Time   1 sec  Max Age  6 sec  Forward Delay  4 sec

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/0/1          Desg FWD 200000    128.1    P2p
Gi1/0/5          Desg FWD 200000    128.5    P2p
Gi1/0/7          Desg FWD 200000    128.7    P2p
Gi1/0/10         Desg FWD 20000     128.10   P2p

BR,

Yoram

12 Replies 12

Peter Paluch
Cisco Employee
Cisco Employee

Hello Yoram,

Have you created an explicit identical MSTP configuration on each of your switches? If the MSTP region configuration is empty (i.e. you just turned MSTP on but did not create the spanning-tree mst configuration section) then per IEEE 802.1Q standard, each switch is in a separate region, so you may actually have 3 regions, one on each switch. That will cause the inter-switch MSTP communication to revert to legacy 802.1D STP if the switches are interconnected with trunks, possibly resulting in long convergence times.

Best regards,

Peter

hi  Peter

I have attached the main lines in teh config refers to spanning tree.

Can u tell what is teh problem.

spanning-tree mode mst
spanning-tree extend system-id
spanning-tree uplinkfast
!
spanning-tree mst configuration
name e
!
spanning-tree mst hello-time 1
spanning-tree mst forward-time 4
spanning-tree mst max-age 6
no spanning-tree vlan 5,99
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
!
interface GigabitEthernet1/0/1
switchport access vlan 99
spanning-tree portfast
spanning-tree bpdufilter enable
!       

interface GigabitEthernet1/0/5
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 5
switchport mode trunk
spanning-tree portfast
spanning-tree bpdufilter enable

!
interface GigabitEthernet1/0/9
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 5,10
switchport mode trunk
spanning-tree portfast
spanning-tree link-type point-to-point
!
interface GigabitEthernet1/0/10
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 5,10
switchport mode trunk
spanning-tree portfast
spanning-tree link-type point-to-point

Hello Yoram,

My suggestions:

  1. Remove the spanning-tree portfast from all your interfaces configured as trunks. This command is absolutely inappropriate on trunks.
  2. Remove the switchport trunk allowed vlan from all your interfaces configured as trunks. MSTP does not cope well with this command until the command is applied to all VLANs under a particular MSTP instance. As you are using only the MSTP instance 0, you would have to (dis)allow all VLANs on your trunks. For the troubleshooting of your problems, it is best to not to limit any VLANs on your trunks for the moment.
  3. Remove the spanning-tree uplinkfast command - it is inappropriate for MSTP.
  4. Complete the MSTP region configuration on all your switches: name e , revision 1 , instance 0 vlan 1-4094
  5. Use the show spanning-tree mst configuration digest command on all your switches and compare the MD5 digest of the MSTP region configuration. The digest must be identical on all three switches. Also, using the show spanning-tree command, verify that no ports are identified as Boundary ports (as designated by the "Bound" comment in the command's output).

Best regards,

Peter

Hi Peter,

I have done your suggestions however without any change still 10 sec switching time.

Important note : there is only one cisco 3750 switch in teh topology.(see attached topology)

Since the cisco is connected with 2 links to other vendor that does not support MSTP, I had to send the STP as regular service that connect the Cisco back.

Maybe this topology is not supported for fast switching.

another note the interfaces are electrical.

BR,

Yoram

:

spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name eci
!
spanning-tree mst hello-time 1
spanning-tree mst forward-time 4
spanning-tree mst max-age 6
no spanning-tree vlan 5,99
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
!        
interface GigabitEthernet1/0/1
switchport access vlan 99
spanning-tree portfast
spanning-tree bpdufilter enable


interface GigabitEthernet1/0/5
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree bpdufilter enable
!
interface GigabitEthernet1/0/9
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport mode trunk
duplex full
speed 1000
spanning-tree link-type point-to-point
!
interface GigabitEthernet1/0/10
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport mode trunk
duplex full
speed 1000
spanning-tree link-type point-to-point
!

Yoram,

Okay, now, this clarifies the issue.

There is no way to make the legacy 802.1D STP perform rapid operations. Decreasing the STP timers may somewhat shorten the failover time but it also may introduce dangerous instability to the network, possibly resulting in switching loops. The legacy STP waits for max_age for a BPDU to expire on a port, and twice the forward_delay to move from Listening through Learning to Forwarding. With your current settings, the minimum convergence time is twice the forward_delay (2x4=8 secs) and maximum convergence time is max_age + 2*forward_delay = 6+8 = 14 secs.

I stress once again that STP timers must be tuned very carefully. It is obvious that STP was not intended to provide rapid reconvergence, which is the reason why RSTP was developed. If your other switches do not support MSTP nor RSTP, you cannot have comparable convergence speed.

Regarding tuning the STP timers, I strongly suggest reading the following document:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

Best regards,

Peter

Hi Peter,

I might wrote STP but as you can see with the configuration it is configured as MSTP 0 which is compatible with RSTP.

RSTP switching time is sub sec .

So it is not 802.1d else if 802.1s 0 that should hopefully behave as 802.1w.

Correct me if i am wrong

BR,

Yoram

Hello Yoram,

I am sorry but I am now confused. First, I thought that all your devices are running MSTP. Then, later you indicated that some of your switches do not understand MSTP and speak STP so I understood that literally. Now, you are saying something about RSTP and I am completely lost as to what exact version of Spanning Tree Protocol is being run on your individual switches.

Please try to clarify that, otherwise we're just shooting blind.

Regarding MSTP - yes, it is built on top of RSTP and behaves just as quickly as RSTP. But in order to achieve fast convergence with MSTP, both interconnected switches must speak MSTP or one of them must be RSTP and the second MSTP. Connecting MSTP to a 802.1D legacy STP switch will not provide you with fast convergence, as the MSTP will revert back to the legacy 802.1D STP operation.

There is another unexplained issue regarding specifically Cisco Catalyst switches: if MSTP detects a boundary port on a trunk (i.e. a neighboring switch in a different MSTP region or not speaking MSTP), it will revert to using legacy 802.1D STP even the neighbor is RSTP/MSTP capable. In other words, on trunk boundary ports, MSTP reverts to slow 802.1D STP. On access boundary ports, MSTP reverts to RSTP if possible. I do not know why Catalysts do this, and I see no logic to that. I have asked about this behavior in this thread but nobody responded.

Best regards,

Peter

Hi Peter,

There is one issue that i must clarify and it seems i did not explained exactly.

There is only one cisco switch that runs MSTP 0 and it closes the MSTP on itself.

The other PE1,2,3 are MPLS switches that do not participate in the MSTP nor support any type of STP.

That's why i tagged the MSTP from Cisco to vlan 10 and it pass as a L2 service through PE 1 and PE 2 back to Cisco.

So in this case we can say there is only 1 Cisco switch that participate in MSTP 0  , isnt it ?

BR,

Yoram

Hello Yoram,

As you are using the vlan dot1q tag native I am not sure how is the MSTP encapsulated on your trunks. Under normal circumstances, MSTP BPDUs are always sent untagged on trunks. However, I am not sure how the MSTP behaves when the vlan dot1q tag native is configured - I will have to verify it in the morning when I get to our lab.

That's why i tagged the MSTP from Cisco to vlan 10

Hmmm... I do not understand this one. How did you do that? By defining a native VLAN on your trunks?

In any case... I suppose that what you have essentially created is a "segment" (created by the PE routers) into which your switch connects via two links. I believe that one port is Designated Forwarding, and the other is Backup Discarding - can you please confirm this? Check the output of the show spanning-tree command.

If this is the case then we have to use a different approach. A Backup port does not rapidly transition to Designated Forwarding state after the former Designated port disappears. Rapid convergence in MSTP/RSTP is achieved only on Alternate ports, and of course, on edge ports.

I would personally try using the Flex Link feature as described here:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swflink.html

However, I am not sure how it combines with the MSTP in your situation, so I have definitely to test in the lab tomorrow morning.

Ideally, the PE routers should also run RSTP or MSTP, as that would provide for near-immediate reconvergence in case of failure, and also, it would solve the problem with appropriate MAC address aging on PE routers in case of topology change.

Best regards,

Peter

Hello Yoram,

I have made the experiments I have promised. I hope you are still interested

First of all - I have confirmed that the topology equivalent to yours - a switch connected via two ports to the same segment - will declare one of these ports as Designated Forwarding and the other as Backup Discarding. Neither RSTP nor MSTP will provide fast recovery if the Designated port fails. That is given by their design.

Second, I have confirmed that the MSTP BPDUs are always sent untagged, regardless of the vlan dot1q tag native command. Thus, neither this command nor the native VLAN setting in any way influences how the MSTP BPDUs are encapsulated.

Third, I have tested the Flex Link feature and it appears that it is probably what you are looking for. The Flex Link allows you to configure a backup port for an active port. While the active port is operational, the backup port is automatically blocked. As soon as the active port is disconnected, the backup port is automatically and immediately enabled and starts forwarding frames. When the active port is connected again, it may resume its forwarding role and place the backup port back to the blocked state, or the backup port may remain in forwarding state and the active port will stay blocked until the backup port fails.

As soon as you configure ports as a Flex Link pair, the STP/RSTP/MSTP is automatically deactivated on them. Their blocking and ublocking is provided exclusively by the Flex Link feature, and these ports do not participate in STP algorithm anymore until the Flex Link configuration is removed.

Assuming that the Fa0/1 is the active (primary) port and the Fa0/2 should be the backup port, the configuration would be as follows:

interface FastEthernet0/1

switchport trunk encapsulation dot1q

switchport mode trunk

switchport backup interface Fa0/2

switchport backup interface Fa0/2 preemption mode forced

switchport backup interface Fa0/2 preemption delay 10

interface FastEthernet0/2

switchport trunk encapsulation dot1q

switchport mode trunk

This configuration will make the Fa0/2 to be the backup interface for the primary interface Fa0/1. Under normal circumstances, the Fa0/1 will be forwarding and the Fa0/2 will be blocked. If the Fa0/1 fails, the Fa0/2 will become forwarding. After Fa0/1 becomes operational again, it will retake the forwarding role (the preemption) after 10 seconds and Fa0/2 will again become blocked.

Note that both Fa0/1 and Fa0/2 stop participating in STP - they do not emit nor process BPDUs. If there are other switches connected to the VPLS service, you have to make sure that no loop can be formed as a result.

Please give it a try and let me know if it solved your issue.

Best regards,

Peter

hi Peter,

First,Thanks for your great efforts and support.

Regarding the BPDU which are untagged , i can assure you that they were tagged using whireshark sniffer.

At first i did not see the tagged frames , but when i connecetd to smartbit directed to the links and analyze it i saw the frames.

It turned out that :

1. port mirroring in cisco filters the tagg , and you need to add at the destination encapsulation replicate.

2.The NIC card need to be updated so it want strip by default the VLAN

check following link, how to make sure your PC will capture vlan-tags when using wireshark
http://wiki.wireshark.org/CaptureSetup/VLAN

3. Do you know what is the swicthing time with flex link .is it sub 50 ms ?

    Which is faster copper links or optical links ?

BR,

Yoram

Hi Yoram,

Regarding the BPDU which are untagged , i can assure you that they were tagged using whireshark sniffer.

In that case, I strongly doubt they were MSTP BPDUs. I am familiar with problems when capturing tagged frames (it belongs to my daily routine) and displaying them in Wireshark, and I have verified that I am seeing 802.1Q tags during my capture. I am absolutely certain that MSTP BPDUs were untagged while other frames (ARPs for example) were tagged appropriately. Please note that MSTP BPDUs shall be untagged according to the IEEE standard. If your MSTP BPDUs were tagged then I am forced to believe that what you saw was not what your switch originally sent.

I do not have exact information about the switching time for Flex Link but according to the available information, the switchover shall take place as soon as the active port is detected to be down. You may want to decrease the detection time on the active port using the carrier-delay msec 30 command to shorten the delay between the real loss of the carrier and the IOS declaring the port down. Note, however, that this makes the port vulnerable to transient link flaps.

Regarding the carrier loss time difference between fiber and metalic ports, I honestly do not know. My first take on this is that the times are roughly identical, or - at least for your needs - similar. But I hope that if someone knows better he'll share his knowledge with us.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco