二层环路、接口频繁震荡

一、二层环路问题排查

二层环路使得网络充满广播报文，使得网络资源被消耗。所以定位故障的思路是：先找到一个mac地址，查看下mac地址是否从不同接口学习过来，找到可能形成环路的接口结合组网的排查去定位。

二、流程图相关操作说明：

1、查看MAC是否在不同接口漂移

在路由器上查看mac是否漂移。

命令： display mac-address xxxx-xxxx-xxxx

例如：通过多次查看该命令，可以看到报文是否从不同接口学习得来。

<H3C>display mac-address  xxxx-xxxx-xxxx

ZhongDu_16010F>display mac-address 6c9c-ed3b-7898

MAC Address      VLAN ID    State            Port/NickName            Aging

6c9c-ed3b-7898   3800       Learned          GE2/3/0/11               Y

ZhongDu_16010F>display mac-address 6c9c-ed3b-7898

MAC Address      VLAN ID    State            Port/NickName            Aging

6c9c-ed3b-7898   3800       Learned          GE2/3/0/12              Y

2、查看接口配置是否放通了MAC所在的vlan

查看学习到相同mac的2个接口下的配置，是否放通这个mac所在的的vlan。

命令：interface GigabitEthernet x/x/x

display this

例如：通过命令查看，可以确认2个接口都放通了mac所在的vlan。

<H3C>display current-configuration

#

interface GigabitEthernet2/3/0/11

 port link-mode bridge

 description To 云宽带固定地址上行

 port link-type trunk

 undo port trunk permit vlan 1

 port trunk permit vlan 304 1140 3800 to 3801 3803 to 3828

 speed 1000

 duplex full

#

interface GigabitEthernet2/3/0/12

 port link-mode bridge

 description To 云宽带固定地址上行

 port link-type trunk

 undo port trunk permit vlan 1

 port trunk permit vlan 304 1140 3800 to 3801 3803 to 3828

 speed 1000

 duplex full

#                                    Cost      : 0

3、查看硬件表象统计

查看硬件表象统计信息。

命令： [H3C-probe]debug L2 slot X 0 mac/move_rec/show 

[H3C-probe] debug port map slot X

例如：通过命令查看这个mac地址在接口上漂移的次数。

 <H3C>system 

[H3C]probe

[H3C-probe]debug L2 slot X 0 mac/move_rec/show  //slotX为接口所在槽位号

6c:9c:ed:3b:78:98 3808 0   38  10   ->0   38  11   56885 2016/08/09 16:07:38 1    

//6c:9c:ed:3b:78:98 为mac地址，0表示物理接口，38  10为硬件标记的物理接口标号， 0表示物理接口，38  11表示硬件标记的物理接口标号，56885为mac漂移次数

[H3C-probe]debug port mapping slot X                    //slotX为接口板所在槽位

[Interface] [Unit] [Port] [Name] [Combo?] [Active?] [IfIndex]  [MID]  [Link]

===============================================================================

GE2/3/0/11      0      10    ge10    no        no      0x7eb       38    up  

 GE2/3/0/12      0      11    ge11    no        no      0x7ec       38    up  

//和上面的0  38  10以及0  38  11对比为以上2个接口

交换机接口频繁震荡

TC报文的排查和优化

交换机偶尔出现少量STP TC日志告警可以不必过分关注，但在规模较大的二层网络域中，若交换机频繁收到TC报文，则会频繁刷新MAC地址表，可能造成短暂的未知单播流量泛洪，拥塞丢包；频繁刷新ARP表可能造成网络中瞬时出现大量ARP协议报文，导致核心设备CPU利用率升高，影响其他协议报文的处理。

因此我们应该尽可能消除频繁产生的TC报文，主要可以按照以下几点进行排查和优化：

1. 首先尽量从源头消除TC报文，找到是哪台设备的接口在频繁震荡。执行命令diplay stp tc查看频繁收到TC报文的端口，如果某端口收到的TC报文一直递增，查看该端口的对端设备的TC接收端口，一级一级往下直到找到TC源。

2. 根据上一步的排查结果，再继续定位接口震荡的原因。如果是设备间的互联接口，建议做一些硬件替换测试消除接口震荡。如果是互联终端的接口则建议配置STP边缘端口和BPDU保护功能。

3. 对于某些不便排查源头的网络，可以在端口上配置stp tc-restriction命令来开启TC-BPDU传播限制功能，此后当该端口收到TC-BPDU时，不会再向其他端口传播。

4. 在我司设备网络和其他厂商设备网络的交界处，如果只有单条路径连接，可以在该链路所连端口上配置stp disable或者bpdu drop。如果存在多条路径，则对其异常收TC情况进行监控和检查。

5. 尽可能合理规划和控制二层网络域的规模，当二层网络域规模较大，汇聚、接入和终端设备数量较多时，建议在核心和汇聚设备之间关闭STP功能，使每台汇聚设备与其下联网络构成一棵单独的STP树，每颗树之间互不影响，从而减小TC报文的泛洪和影响范围。

经典STP相关问题解析及优化案例：

组网及说明

组网如下：

问题描述

如拓扑所示，现场是一个大的二层网络，且全部为默认的配置，都在一个MSTP实例0中，图中只标出了核心以及汇聚交换机，汇聚下面还有更多的接入交换机，接入下面接有大量的AP设备，客户现场频繁出现保活报文丢失导致的AP掉线的情况。

过程分析

查看交换设备上的记录，存在拥塞丢包的情况，且前一天清除后，第二天还会继续增长，如下：

[H3C]dis qos queue-statistics interface <接口> outbound

Interface: GigabitEthernet1/7/0/2

 Direction: outbound

 Forwarded: 11698 packets, 2778275 bytes

 Dropped: 611 packets, 604469 bytes

 Queue 0

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

 Queue 1

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

 Queue 2

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 611 packets, 604469 bytes

  Current queue length: 0 packets

 Queue 3

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

 Queue 4

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

 Queue 5

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

 Queue 6

  Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

 Queue 7      

  Forwarded: 11698 packets, 2778275 bytes, 0 pps, 0 bps

  Dropped: 0 packets, 0 bytes

  Current queue length: 0 packets

Queue 2是转发数据报文的，Queue 6或者7是转发协议报文。

且各接口拥塞丢包的个数基本一致，查看设备上存在TC的日志，如下：

%Aug 29 10:16:17:104 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:16:14:291 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:10:35:111 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:10:32:292 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:07:59:115 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:07:56:226 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:07:47:116 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:07:44:296 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:04:24:123 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 10:04:21:298 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 09:58:50:135 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 09:58:47:330 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

%Aug 29 09:55:16:141 2019 W-B1F-IT-AP-1 STP/6/STP_NOTIFIED_TC: Instance 0"s port Ten-GigabitEthernet1/0/25 was notified a topology change.

        因此可以判断出，该拥塞丢包就是由于TC导致的转发表项刷新，造成大量的报文泛洪，因此造成拥塞丢包

解决方法

针对当前的组网，我们发现，几乎所有的TC报文均来自于同一个汇聚设备，因此，可以将该设备上联核心的接口stp给关闭了，这样就可以防止tc-bpdu报文的泛洪。

同时，对于这种大的二层网络环境，有如下的优化方法：

1、STP优化，在接终端的端口配置边缘端口，BPDU保护，这样可以防止不必要的TC报文产生，导致网络震荡；同时可以将大的STP域进行分割，一般而言，越靠近核心越不容易出现环路，因此可以在汇聚与核心互联的端口关闭STP，这样可以防止stp报文的广播，尤其是TC报文带来的网络震荡，同时可以在设备上指定各汇聚设备为自己的根桥，防止后期扩容接入设备出现抢根导致的STP收敛情况；

2、开启端口隔离，一般在核心上各个与汇聚之间互联的端口开启端口隔离，配置之后各汇聚之间的二层互访就是相互隔离的，可以防止二层广播的报文在网络中泛洪，如果确实又有部分二层互访的需求，可以在开启端口隔离的设备上开启本地ARP代理，通过配置 local-proxy-arp enable  开启代理后，报文在设备上就可以走三层转发，不受端口隔离的限制，从而实现互访的需求。

对于STP问题的排查方法和相关命令：

1、display stp interafce <接口>；可以查看当前接口STP状态，很多二层不通都是被stp给阻塞了

2、display stp tc；可以查看设备上的TC记录，recieve指的是该接口收到的TC报文个数，send指的是该接口的TC发送的个数，当需要查找TC的来源时，可以查看logbuffer中的记录，如果是notify，指的就是接口收到TC报文，如果是detect，指的就是接口本身产生的TC报文，可以通过这种排查方式，逐个设备去查找TC的来源

3、display stp history可以查看设备上各接口的stp状态变化情况，可以根据这个记录判断出当前拓扑的整个变化过程