H3C MST BPDU exchange failing

hpieee-802.1sieee-802.1wspanning tree

I am coming across the following MST issue.

Between a HP5940 network core and HP5130 network access layer, I am using 5 instances of MST, configured like this :

CORE switch

stp region-configuration
 region-name ***edited***
 instance 1 vlan 200 to 399 2100 to 2199
 instance 2 vlan 400 to 599 2003 to 2004 2007 2009 2200 to 2299
 instance 3 vlan 600 to 799 2300 to 2399
 instance 4 vlan 800 to 999 2400 to 2499
 instance 5 vlan 2500 to 2699
 active region-configuration
#
 stp instance 0 root secondary
 stp instance 1 to 6 root primary
 stp bpdu-protection
 stp global enable
#



 [Core-sw]dis stp region-configuration
  Oper Configuration
    Format selector      : 0
    Region name          : ***edited***
    Revision level       : 0
    Configuration digest : 0x950fe4b63ba3d47dc4a539d00f613bb9

    Instance  VLANs Mapped
    0         1 to 199, 1000 to 2002, 2005 to 2006, 2008, 2010 to 2099,
              2700 to 4094
    1         200 to 399, 2100 to 2199
    2         400 to 599, 2003 to 2004, 2007, 2009, 2200 to 2299
    3         600 to 799, 2300 to 2399
    4         800 to 999, 2400 to 2499
    5         2500 to 2699

ACCESS SWITCH

The instance 0 is not mapped to any vlans. Its sole use is interoperability with the older infrastructure switches who run RSTP.

 stp region-configuration
 region-name ***edited***
 instance 1 vlan 200 to 399 2100 to 2199
 instance 2 vlan 400 to 599 2003 to 2004 2007 2009 2200 to 2299
 instance 3 vlan 600 to 799 2300 to 2399
 instance 4 vlan 800 to 999 2400 to 2499
 instance 5 vlan 2500 to 2599
 active region-configuration
#
 stp global enable



  [Acc-sw]dis stp region-configuration
 Oper Configuration
   Format selector      : 0
   Region name          : ***edited***
   Revision level       : 0
   Configuration digest : 0xfe4856d79d2dad1ea4a696c8592b5a63

   Instance  VLANs Mapped
   0         1 to 199, 1000 to 2002, 2005 to 2006, 2008, 2010 to 2099,
             2600 to 4094
   1         200 to 399, 2100 to 2199
   2         400 to 599, 2003 to 2004, 2007, 2009, 2200 to 2299
   3         600 to 799, 2300 to 2399
   4         800 to 999, 2400 to 2499
   5         2500 to 2599

However, on the access switch, I can see that, bar the instance 0, the other instances are not getting the correct Root Bridge :

ACCESS SWITCH

 [Acc-sw]dis stp root
  MST ID   Root Bridge ID        ExtPathCost IntPathCost Root Port
  0        0.0011-85ce-9a00      33          0           BAGG1
  1        32768.40b9-3ca6-0b7f  0           0
  2        32768.40b9-3ca6-0b7f  0           0
  3        32768.40b9-3ca6-0b7f  0           0
  4        32768.40b9-3ca6-0b7f  0           0
  5        32768.40b9-3ca6-0b7f  0           0

Looking at the bpdu-statistics, it shows that almost no BPDUs are being exchanged between CORE and ACCESS :

CORE switch

   Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Invalid BPDUs               0
  Looped-back BPDUs           0
  Max-aged BPDUs              0
  TCN sent                    0
  TCN received                0
  TCA sent                    33306      17:06:33 09/14/2017
  TCA received                0
  Config sent                 0
  Config received             0
  RST sent                    0
  RST received                0
  MST sent                    1261144    17:06:49 09/14/2017
  MST received                33310      17:06:31 09/14/2017

  Instance 0:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          01:02:43 01/01/2011
  TC sent                     204        15:18:57 09/14/2017
  TC received                 33307      17:06:31 09/14/2017

  Instance 1:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          01:02:43 01/01/2011
  TC sent                     186        15:18:57 09/14/2017
  TC received                 0

  Instance 2:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          01:02:43 01/01/2011
  TC sent                     186        15:18:57 09/14/2017
  TC received                 0

  Instance 3:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          01:02:43 01/01/2011
  TC sent                     186        15:18:57 09/14/2017
  TC received                 0

  Instance 4:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          01:02:43 01/01/2011
  TC sent                     204        15:18:57 09/14/2017
  TC received                 0

  Instance 5:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          01:02:43 01/01/2011
  TC sent                     186        15:18:57 09/14/2017
  TC received                 0

ACCESS switch

  --------------------------- ---------- -----------------
  Invalid BPDUs               0
  Looped-back BPDUs           0
  Max-aged BPDUs              0
  TCN sent                    0
  TCN received                0
  TCA sent                    0
  TCA received                176        17:12:21 09/14/2017
  Config sent                 0
  Config received             0
  RST sent                    0
  RST received                0
  MST sent                    178        17:12:19 09/14/2017
  MST received                6600       17:12:51 09/14/2017

  Instance 0:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          13:32:59 09/14/2017
  TC sent                     176        17:12:19 09/14/2017
  TC received                 24         15:18:57 09/14/2017

  Instance 1:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          13:32:59 09/14/2017
  TC sent                     1          13:32:59 09/14/2017
  TC received                 0

  Instance 2:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          13:32:59 09/14/2017
  TC sent                     1          13:32:59 09/14/2017
  TC received                 0

  Instance 3:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          13:32:59 09/14/2017
  TC sent                     1          13:32:59 09/14/2017
  TC received                 0

  Instance 4:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          13:32:59 09/14/2017
  TC sent                     1          13:32:59 09/14/2017
  TC received                 0

  Instance 5:
  Type                        Count      Last Updated
  --------------------------- ---------- -----------------
  Timeout BPDUs               0
  Max-hoped BPDUs             0
  TC detected                 1          13:32:59 09/14/2017
  TC sent                     1          13:32:59 09/14/2017
  TC received                 0

I can clearly see that only Instance 0 is correctly exchanging BPDU. Why is that ?
Could it be that the fact that the Root Bridge for Instance 0 is running RSTP is taking precedence over the MST configured on my Core switch ?

Thank you for your answers.

Best Answer

You have a fundamental problem with your configuration, which is that the configuration digests on core and access switches don't match.

 [Core-sw]dis stp region-configuration
  Oper Configuration
    Format selector      : 0
    Region name          : ***edited***
    Revision level       : 0
    Configuration digest : 0x950fe4b63ba3d47dc4a539d00f613bb9

  [Acc-sw]dis stp region-configuration
 Oper Configuration
   Format selector      : 0
   Region name          : ***edited***
   Revision level       : 0
   Configuration digest : 0xfe4856d79d2dad1ea4a696c8592b5a63

As the digests don't match, you have two regions with the same name, not one region. RSTP rules apply between regions, so for practical purposes, it's as if you haven't configured MSTP.

The only discrepancy I found was that the VLANs mapped to Instance 5 differ. Still, a miss is as good as a mile with a cryptographic checksum.

Related Solutions

Cisco – How to make a PVST+ switch root towards MST network

The way it works when connecting MST and PVST domain is that the MST switch at the edge of the domain will simulate PVST+ by sending same BPDU for all VLANs configured on the trunk towards the PVST+ switch.

The CIST replicates BPDU for every VLAN. Because there is not one instance per VLAN for MST the sys ID is set to 0 on these BPDUs. When connecting MST and PVST+ domain VLAN 1 is used to connect the domains.

When the PVST+ side sends a BPDU with priority 0 for VLAN 1 it is actually 1 because of extended system ID. If VLAN 2 is also configured then PVST+ side sends BPDU with ID of 2 because of the extended system ID.

The way PVST simulation works on MST switch is that the port can only have one role because there is not one instance running per VLAN. The CIST is now sending BPDU that it knows a root which has a priority of 1. This means that MST switch should be root forwarding but then it sees a BPDU with a priority of 2. Because the MST switch has better root information it should become designated forwarding on the port but the port can only have one role so the PVST simulation fails.

To make this work the PVST+ side must have worse priority on VLAN 1 than all the other VLANs on the trunk. The following configuration will work:

spanning-tree vlan 1 priority 4096
spanning-tree vlan 2-4094 priority 0

This way the PVST simulation will work and the following log message should be seen:

%SPANTREE-2-PVSTSIM_OK: PVST Simulation inconsistency cleared

More information can be found in the following link.

Easy PVST to MST transition

I recently went through a similar migration that eradicated proprietary protocols (i.e., PVST+, HSRP, etc.); our transition was focused on posturing us for a 'vendor neutral' network. Since you're running Cisco devices, you're likely running PVST+.

Cisco covers this in more detail, but the crux of it is fairly simple: establish a hierarchy and, contrary to what common sense would tell you, start from the core and move outward.

Set your priorities in a manner that cascades down. Base this hierarchy on what is closest to a central node. All nodes participating in this STP setup should be on a common structure, so for simplicities sake, manually set one root bridge with the spanning-tree vlan xx,xx root primary.

Once you're ready for the migration to begin, start with the core. The reason for this is because MST is backwards compatible with PVST, not the other way around. A PVST core won't be able to communicate with BPDUs from MST nodes; those trunk links will drop. If everything is going right, you'll see a small drop while the new STP protocol comes online and figures out the current lay of the land.

Then just trickle these protocol changes down all the way to your furthest nodes.

End-users might not even notice the small blip while MST elects a root bridge.

Best Answer

Related Solutions

Cisco – How to make a PVST+ switch root towards MST network

Easy PVST to MST transition

Related Topic