H3C MST BPDU exchange failing

Question

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.

Answer 1

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.

Answer 2

TL;DR:

• MST (IEEE 802.1s) exchanges BPDUs only on instance 0. Don't expect BPDUs on the other instances.
• VLAN-to-instance mapping must be identical on all MST switches (ref: richardb's answer) for the topology to converge.

Extended version:

With MST (802.1s), only instance 0 is meant to exchange BPDUs. One of the best writeups about MST I could find is this one:

http://blog.ine.com/2010/02/22/understanding-mstp/, Section "MISTP vs MSTP"

Quote & Highlight:

The IEEE 802.1s implementation does not send BDPUs for every active STP instance separately, nor does it encapsulate VLAN numbers list configuration messages. Instead, a special STP instance number 0 called Internal Spanning Tree (IST aka MSTI0, Multiple Spanning Tree Instance 0) is designated to carry all STP-related information. The BPDUs for IST contain all standard RSTP-style information for the IST itself, as well as carry additional informational fields. Among those fields are configuration name, revision number and a hash value calculated over VLANs to MSTI mapping table contents. Using just this condensed information switches may detect mis-configuration in VLAN mappings by comparing the hash value received from the peer with the local value.

As for (R)STP interoperation with MST, http://blog.ine.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/ tells us (Section "The concept of CST and STP interoperation)

This is the point where MSTP interoperates with legacy IEEE STP/RSTP regions as well. The legacy switch regions have no concept of IST, so they simply join their STP instance with the CST and perceive MSTP regions as “transparent” pseudo-bridges, staying unaware of their internal topology. (Note that it may happen so that a switch with the lowest BID belongs to RSTP/STP region. This situation results in all MSTP regions electing local CIST Regional Roots and considering the new CIST Root located outside MSTP “domain”). Naturally, MSTP detects the appropriate STP version on a boundary link and switches to the respective mode of operations (e.g. RSTP/STP).

So having the root of your MST instance 0 outside the MST region might lead to some unexpected outputs and topologies/trees for instance 0, but everything should still work.

However, with your configuration, it probably won't. Please follow richardb's advice to sort out the VLAN-to-instance mapping between core and access. His way of putting it ("so for practical purposes, it's as if you haven't configured MSTP") explains readily why the access switch considers itself root of MST instances 1-5; it won't acccept the BPDUs coming from the core because the hash value does not match.

Answer 3

It could be a spanning tree mode related problem.

Among RSTP, MSTP and PVST, each mode has some STP compatibility, with a fallback mechanism to STP for ports that receive STP BPDUs.

If a MSTP mode port receives STP BPDUs, it automatically transits to STP mode, but doesn't transit to RSTP mode when receiving RSTP BPDUs.

This may explain why your configurations works only for VLAN 1, since a fallback to STP can't be excluded.
Check that STP mode is MSTP for trunk ports of both HP5490 and HP5130.

Answer 4

Wipe the config(s) clean and start over. Use what HP calls Trunk Groups to bond uplinks into a single link. Do your inter-vlan routing on the core switch.