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
相关文章
|
运维 网络协议 安全
网络故障分析
了解一些运维工作所必须要掌握的网络命令(MTR、traceroute 等)的原理和使用,并进行演示
161 1
|
2月前
|
缓存 监控 安全
Objective-C 在提升公司电脑屏幕监控性能中的探索
本文介绍了在数字化办公环境中,公司对电脑屏幕监控的重要性,并详细探讨了如何使用 Objective-C 提升屏幕监控性能。文章涵盖了屏幕监控的基本原理、数据压缩、异步传输和缓存机制等优化策略,并通过性能测试验证了这些方法的有效性。
42 2
|
3月前
|
存储 SQL Oracle
AWR,即自动工作负荷资料档案库
【10月更文挑战第16天】AWR,即自动工作负荷资料档案库
57 3
|
8月前
|
网络协议 Java 应用服务中间件
长连接黑洞重现和分析
这是一个存在多年,遍及各个不同的业务又反反复复地在集团内部出现的一个问题,本文先通过重现展示这个问题,然后从业务、数据库、OS等不同的角度来分析如何解决它,这个问题值得每一位研发同学重视起来,避免再次踩到
127 0
|
运维 监控 测试技术
故障治理:如何进行故障复盘
故障复盘的重要性无需多说,每一次故障都是宝贵的学习机会,本人接手故障复盘工作已经半年有余,从一开始的手足无措,慢慢变得游刃有余。以下内容为本人从网上查阅学习多个专家经验,并结合工作经历总结而来,仅供参考。
|
运维 监控 云计算
关于故障复盘、容忍度和SLO
关于故障复盘、容忍度和SLO
367 0
|
存储 运维 监控
十条运维经验,帮你远离故障
1. 确保变更可以回滚 佛说:“每次创伤都是一次成熟”。这是运维人员的真实写照。从某种意义上讲,运维是一份不断犯错、不断积累经验的工作。以前没有经历的东西,总是不定期的给你痛击。所以请保护好变更的现场,使得变更有回头的机会。
1124 0
|
SQL 关系型数据库 MySQL
深度分析 | MGR相同GTID产生不同transaction故障分析
MGR作为MySQL原生的高可用方案,它的基于共识协议的同步和决策机制,看起来也更为先进。吸引了一票用户积极尝试,希望通过MGR架构解决RPO=0的高可用切换。在实际使用中经常会遇到因为网络抖动的问题造成集群故障,本文以真实案例分析MGR相同GTID产生不同transaction的原因。
|
监控 Shell Perl
统计UPD丢包工具
下载位置:https://github.com/eyjian/libmooon/tree/master/shell #!/bin/bash # 统计UPD丢包工具 # 可选参数1:统计间隔(单位:秒,默认10秒) ...
1474 0
|
SQL 存储 缓存
Expert 诊断优化系列------------------给TempDB 降温
前面文章针对CPU、内存、磁盘、语句、等待讲述了SQL SERVER的一些基本的问题诊断与调优方式。为了方便阅读给出导读文章链接方便阅读: SQL SERVER全面优化-------Expert for SQL Server 诊断系列     这篇我们来说说TempDB,这个系统数据库如何进行优化,怎么样平衡他的使用。
1049 0