4招教你M-LAG故障定位

简介: 4招教你M-LAG故障定位


M-LAG建立失败或流量转发异常时,基本的定位思路如下图所示。


1、检查DFS配对是否成功

用户可以使用命令行display dfs-group 1 m-lag查看DFS配对状态。

<HUAWEI>displaydfs-group1m-lag *: Local node //标识为本地节点。 Heart beat state : OK //心跳状态。OK:表示正常在线状态。Lost:表示离线状态。 Node1* Dfs-Group ID : 1 //DFS Group的编号。 Priority : 150//DFS Group的优先级。 Address : ip address 192.168.61.1 //DFS Group绑定的IP地址或nickname值。 State : Master //设备的主备状态。Master:主用状态。Backup:备用状态。 Causation :-//失败原因。 System ID :0025-9e95-7c31 //系统MAC地址。 SysName : CE6881-9130//设备名称。 Version : V200R021C00//设备当前的版本。 Device Type : CE6881 //设备对应的系列。 Node2 Dfs-GroupID:1 Priority:120 Address:ipaddress192.168.61.2 State:Backup Causation:- SystemID:0025-9e95-7c11 SysName:CE6881-9130 Version:V200R021C00 DeviceType:CE6881

Causation字段可以查看到DFS配对失败的原因,“-”表示DFS配对成功,配对失败的具体原因参见如下。

Causation字段:

NOPEERLINK

失败原因:

表示没有配置peer-link。

解决办法:

检查peer-link配置,需要在两端设备上创建一个新的Eth-Trunk口并配置peer-link命令行。


Causation字段:

NOADDRESS

失败原因:

表示没有绑定地址或绑定的IP地址不能互通。

解决办法:

检查DFS-Group视图下的配置,需要在两端设备的DFS-Group试图下配置source ip命令行。


Causation字段:

SAMEMAC

失败原因:

表示本端和对端设备的系统MAC地址相同。

解决办法:

检查系统MAC地址,需要使用set system mac-address修改系统MAC,将本端和对端MAC地址配置不同。


Causation字段:

TYPEMISMATCH

失败原因:

表示绑定到DFS-Group的源地址不同。

解决办法:

检查DFS-Group视图下的配置,将DFS-Group视图下的IP地址及类型配置相同。DFS-Group视图下支持五种类型的源IP地址:IPv4/IPv4 VPN/IPv6/IPv6 VPN/Nickname(TRILL相关)。


Causation字段:

TIMEOUT

失败原因:

表示接收协议报文超时,即没有收到协议报文。可能因为链路拥塞、CPU使用率高导致协议报文丢弃等。

解决办法:

请联系华为工程师协助定位。


Causation字段:

PEERLINKDOWN

失败原因:

表示peer-link链路状态为DOWN。

解决办法:

检查两端M-LAG设备的peer-link口的物理状态,可以使用display dfs-group 1 peer-link命令行查看peer-link口。


Causation字段:

DETECT

失败原因:

表示能收到对端hello报文但收不到对端设备信息报文。可能因为链路拥塞、CPU使用率高导致协议报文丢弃等。

解决办法:

请联系华为工程师协助定位。


Causation字段:

CMTDOWN

失败原因:

表示TRILL CMT状态为DOWN。可能原因为TRILL链路异常。

解决办法:

检查TRILL CMT的状态和配置,请参考配置M-LAG双归接入TRILL。


Causation字段:AUTHENTICATION FAILED

失败原因:

表示DFS Group配对的设备验证失败。

解决办法:

检查验证模式及验证口令,通过authentication-mode hmac-sha256 password password命令行将本端和对端的验证模式和验证口令配置一致,请参考配置DFS Group。


Causation字段:DEVICETYPEMISMATCH

失败原因:

表示设备类型不匹配。

解决办法:检查两台设备的类型,保证两台设备类型一致。

2、检查peer-link口的状态

用户可以通过命令display dfs-group 1 peer-link查看peer-link口的状态。

<HUAWEI>displaydfs-group1peer-link Peer-linkInformation ---------------------------------------------------------- TotalInterface(s):1 Peer-linkId:1 PortName:Eth-Trunk0 PortState:Up

Port State字段是peer-link口的状态,正常情况下,该字段应该是“Up”的。

3、检查M-LAG口配对是否成功

用户可以通过命令行display dfs-group 1 node node-id m-lag查看M-LAG口配对是否成功。

<HUAWEI>displaydfs-group1node1m-lag *- Local node //标识为本地节点。 M-Lag ID : 1 //绑定M-LAG的ID。 Interface : Eth-Trunk 101 //对应的用户侧Eth-Trunk接口。 Port State : Up //端口的状态。Down或Up。 Status : active(*)-active //流量是否可达。active:流量可达。inactive:流量不可达。 Member Port Role : Master(*)-Backup //成员接口状态。Backup:M-LAG成员接口状态为备。Master:M-LAG成员接口状态为主。Invalid:无效状态。

Status表示M-LAG口的配对状态,如果是active-active,表明配对的两台设备的M-LAG口配对成功。

若配对不成功,用户可先查看详细的M-LAG口配对信息,查看是否是配置不一致的原因。

<HUAWEI>displaydfs-group1node1m-lagbrief *-Localnode M-LagIDInterfacePortStateStatusConsistency-check 1Eth-Trunk40Upactive(*)-activesuccess 5Eth-Trunk41Upactive(*)-inactivefailed(5) Failedreason: 1--Relationshipbetweenvlanandportisinconsistent 2--STPconfigurationundertheportisinconsistent 3--STPportpriorityconfigurationisinconsistent 4--LACPmodeofM-LAGisinconsistent 5--M-LAGconfigurationisinconsistent 6--ThenumberofM-LAGmembersisinconsistent

Consistency-check字段表示配置一致性检查是否成功,-表示未使能一致性检查,success表示检查成功,failed(n)表示检查失败,其中n表示检查失败原因的编码。若出现配置不一致,请参见配置M-LAG成员接口检查配置。

再检查M-LAG成员口学习到的MAC、ARP等表项是否同步到peer-link口,M-LAG成员口学习到的MAC、ARP等表项是否同步到对端M-LAG成员口。若没有同步需联系华为工程师确认原因。

4、检查M-LAG相关资源

用户可以通过display system tcam fail-record查看是否有ACL下发失败,若有请参考ACL资源不足怎么办,还可以联系华为工程师。

[~HUAWEI]displaysystemtcamfail-recordslot1 ----------------------------------------------------------------------------------- SlotChipTimeServiceErrInfo ----------------------------------------------------------------------------------- 112020-03-2406:40:11TrafficPolicyVLANGroupresourcefull ----------------------------------------------------------------------------------- Total:1
相关文章
|
6月前
恢复时间目标(RTO, Recovery Time Objective)缩短
恢复时间目标(RTO, Recovery Time Objective)缩短
178 2
|
运维 网络协议 安全
网络故障分析
了解一些运维工作所必须要掌握的网络命令(MTR、traceroute 等)的原理和使用,并进行演示
149 1
|
3月前
|
运维 IDE 测试技术
紧急故障处理:有效Debug技巧分享
【8月更文挑战第15天】通过掌握上述Debug技巧,你可以在面对紧急故障时更加从容不迫,迅速定位并解决问题。希望本文的分享对你有所帮助!
|
3月前
|
监控 Java 中间件
分布式链路监控系统问题之当某个Segment数据缺失的问题如何解决
分布式链路监控系统问题之当某个Segment数据缺失的问题如何解决
|
运维 监控 测试技术
故障治理:如何进行故障复盘
故障复盘的重要性无需多说,每一次故障都是宝贵的学习机会,本人接手故障复盘工作已经半年有余,从一开始的手足无措,慢慢变得游刃有余。以下内容为本人从网上查阅学习多个专家经验,并结合工作经历总结而来,仅供参考。
|
Oracle 关系型数据库
Oracle-分析函数之取上下行数据lag()和lead()
Oracle-分析函数之取上下行数据lag()和lead()
161 0
|
6月前
|
运维 监控 Java
线上故障突突突?如何紧急诊断、排查与恢复
本文简单介绍了阿里云上关于故障恢复、诊断的一些最佳实践。
线上故障突突突?如何紧急诊断、排查与恢复
|
运维 监控 云计算
关于故障复盘、容忍度和SLO
关于故障复盘、容忍度和SLO
350 0
|
SQL 关系型数据库 MySQL
深度分析 | MGR相同GTID产生不同transaction故障分析
MGR作为MySQL原生的高可用方案,它的基于共识协议的同步和决策机制,看起来也更为先进。吸引了一票用户积极尝试,希望通过MGR架构解决RPO=0的高可用切换。在实际使用中经常会遇到因为网络抖动的问题造成集群故障,本文以真实案例分析MGR相同GTID产生不同transaction的原因。