H3C MST交换失败
我遇到了下面的MST问题。
在HP5940网络内核和HP5130网络访问层之间，我使用了5个MST实例，配置如下：
核心开关
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接入交换机
实例0没有映射到任何vlans。它的唯一用途是与运行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但是，在access开关上，我可以看到，除了实例0之外，其他实例没有得到正确的根桥：
接入交换机
[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查看bpdu统计数据，它表明几乎没有bpdu在核心和访问之间进行交换：
核心开关
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接入交换机
--------------------------- ---------- -----------------
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我可以清楚地看到，只有实例0正确地交换了BPDU。那是为什么？例如，根桥正在运行RSTP这一事实是否比在我的核心交换机上配置的MST优先？
谢谢你的回答。
回答 3
Network Engineering用户
发布于 2017-09-18 22:30:31
TL;DR：
- MST (IEEE802.1s)只在实例0上交换BPDU。不要期望在其他实例上使用BPDU。
- VLAN到实例的映射必须在所有MST交换机(ref: richardb的答案)上相同，才能使拓扑收敛。
扩展版本：
对于MST (802.1s)，只有实例0才能交换BPDU。我能找到的关于MST的最好的文章之一是：
http://blog.ine.com/2010/02/22/understanding-mstp/，"MISTP对MSTP“一节
引用和突出：
IEEE802.1s实现不为每个活动STP实例分别发送BDPU，也不封装VLAN编号列表配置消息。相反，一个特殊的STP实例号0称为内部生成树(IST又名MSTI0，多生成树实例0)，用于携带所有与STP相关的信息。IST的BPDU包含IST本身的所有标准的RSTP样式信息，以及附加的信息字段。这些字段包括配置名称、修订号和通过VLAN到MSTI映射表内容计算的哈希值。仅使用此浓缩信息交换机可以通过比较从对等端接收的哈希值和本地值来检测VLAN映射中的错误配置。
至于(R)STP与MST的互操作，http://blog.ine.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/告诉我们( CST和STP互操作的概念)。
这就是MSTP与传统的IEEE STP/RSTP区域的互操作点。遗留的交换区域没有IST的概念，因此它们只是将STP实例与CST连接起来，并将MSTP区域看作是“透明的”伪桥，不知道它们的内部拓扑结构。(请注意，这种情况可能发生，以便出价最低的交换机属于RSTP/STP区域。这种情况导致所有MSTP区域选择本地CIST区域根，并考虑位于MSTP“域”之外的新CIST根)。自然，MSTP检测边界链路上的适当STP版本并切换到相应的操作模式(例如RSTP/STP)。
因此，将MST实例0的根放在MST区域之外可能会导致一些意外的输出和拓扑/树(例如0)，但一切都应该仍然正常。
但是，使用您的配置，它可能不会。请遵循richardb的建议，整理出核心和访问之间的VLAN到实例映射。他的说法(“所以出于实际目的，就好像您还没有配置MSTP")很容易地解释了为什么访问交换机认为自己是MST实例1-5的根；它不会接收来自核心的BPDU，因为哈希值不匹配。
Network Engineering用户
发布于 2017-09-18 13:19:04
这可能是一个与生成树模式相关的问题。
在RSTP、MSTP和PVST中，每种模式都具有一定的STP兼容性，对于接收STP的端口，每种模式都有一种STP的回退机制。
如果一个MSTP模式端口接收到STP，它会自动传输到STP模式，但在接收RSTP时不会传输到RSTP模式。
这可能解释了为什么您的配置只适用于VLAN 1，因为不能排除对STP的退步。
检查HP5490和HP5130的主干端口的STP模式是否为MSTP。
Network Engineering用户
发布于 2017-09-17 17:19:16
擦拭配置(S)干净，重新开始。使用HP所称的主干群将上行链路连接到单个链接中。在核心交换机上做vlan间路由。
https://networkengineering.stackexchange.com/questions/44161
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号