分类： 网络

1、执行命令display aaa online-fail-record all，查看User online fail reason字段，其取值为Remote user is blocked；可以执行以下步骤排查问题。

执行命令display remote-user authen-fail blocked，确认远端认证账号被锁定是否需要立即激活。

●如果需要，请在AAA视图下执行命令remote-user authen-fail unblock激活该用户。同时激活后需要使用正确的用户名密码登录，否则失败次数达到条件后仍会被锁定，请执行步骤2。

●如果不需要，请执行步骤2。

2、检查所有接入的终端是否采用同一个账号认证。

●如果未采用，请执行步骤3。

●如果采用，一旦网络中有多台终端使用同一个账号认证失败被加入静默，将会导致整个网络其它正常认证的用户也出现认证失败的情况，所以V200R019C00之前版本，需要在AAA视图下执行命令undo remote-aaa-user authen-fail关闭AAA远端认证失败后账号锁定功能；V200R019C00及之后版本，需要在AAA视图下执行命令undo access-user remote authen-fail关闭接入用户远端认证失败后账号锁定功能。

3、执行命令display aaa online-fail-record，根据User online fail reason字段检查其他上线失败原因来定位问题。

在系统视图下执行命令trace object mac-address mac-address可以看到提示User is still in quiet status，说明终端处于静默状态。

可以执行以下步骤进行排查。
1、执行命令display dot1x quiet-user all，查看用户MAC处于静默状态的剩余静默时间。

该终端用户在60s内连续802.1X认证失败达到一定次数，需等到用户MAC退出静默状态后再重新尝试。也可以在系统视图下执行命令dot1x timer quiet-period quiet-period-times调小802.1X用户被静默的时间。

2、执行命令display aaa online-fail-record，根据User online fail reason字段检查其他上线失败原因来定位问题。

有两种方式快速确认RADIUS服务器是否回应。

方法一：执行命令display aaa online-fail-record all，发现User online fail reason字段显示为The radius server is up but has no reply或者The radius server is not reachable。

方法二：在系统视图下执行命令trace object mac-address mac-address可以看到服务器没有回应。

出现服务器无响应的情况首先确认服务器是否添加了设备IP。如果没有添加，请添加正确的设备IP。如果已经添加，那么需要确定服务器添加的设备IP与认证请求的源IP是否一致（设备默认出接口的IP地址作为向RADIUS服务器发送RADIUS报文时使用的源IP地址）。

用户可以执行命令display radius-server configuration template查看RADIUS服务器模板下是否配置了source-ip。

如果已配置，则服务器上添加的设备IP必须要是这个source-ip。

如果未配置，则可以执行命令display ip routing-table查路由确认认证请求报文的源IP是否是服务器添加的设备IP。例如RADIUS服务器IP是192.168.1.1，通过查询路由的命令可以看到NextHop是192.168.1.101，这个地址即作为认证请求报文的源IP。

如果服务器上添加设备IP没有问题，就需要在设备和服务器上同时获取报文确认中间链路是否存在问题，例如中间网络存在防火墙，防火墙未放通RADIUS（默认认证端口：1812）报文。

另外一种服务器无响应场景是服务器和设备配置的shared-key不一致，可以通过test-aaa命令测试。Debug信息如下所示，出现这种情况需要确保设备和服务器上的shared-key一致。

如果出现大量用户无法认证，日志里出现RADIUS服务器Down记录：

那么可能是服务器或中间网络出现异常，需要逐一排查；也可能是设备封装的报文较大，分片发送至服务器，服务器无法正确识别处理，不做回应采集trace信息，查看未回应报文长度是否大于1500，若大于，可调小接口MTU值。也可在设备侧抓包，查看是否有类似下图的radius报文：

 

有两种方式快速确认RADIUS服务器是否回应认证拒绝。

方法一：执行命令display aaa online-fail-record all，发现User online fail reason字段显示为Radius authentication reject。

方法二：在系统视图下执行命令trace object mac-address mac-address可以看到服务器回应了拒绝报文。
[

服务器回应认证拒绝有多种原因，最常见的有用户名密码错误、RADIUS服务器授权策略无法匹配等，这些问题需要首先通过排查服务器日志找到根因后，再调整服务器、终端或设备配置解决。具体可参见Radius authentication reject。

此外，对于使用到证书的802.1X认证，终端或服务器需要检验证书的合法性，例如终端采用EAP-TLS、EAP-PEAP（可以取消验证服务器证书）。遇到这类问题需要在终端或者服务器获取报文分析。常见的证书错误包括CA证书未加入终端信任列表，证书过期等，例如报错Unknown CA。

注：R21C00及之前版本，802.1x认证配置radius-server user-name domain-included命令，radius报文用户名不携带域名。升级至R21C10及之后版本，配置此命令用户名会携带域名。若升级前业务交互正常，升级后可能会出现用户名携带域名导致的radius服务器拒绝。此时可以undo radius-server user-name domain-included恢复业务。

执行命令display authentication mode确认NAC配置模式：
unified-mode：统一模式。
common-mode：传统模式。

统一模式

执行命令display dot1x-access-profile configuration，根据Authentication method字段检查设备配置的802.1X用户认证方式与RADIUS服务器是否一致。

统一模式下，802.1X用户认证方式默认为 eap（即EAP中继认证方式）。如果不一致，请在802.1X接入模板视图下执行命令dot1x authentication-method { chap | pap | eap }修改802.1X用户认证方式。

注：对于绝大多数终端，设备需配置认证方式为EAP中继认证方式。

 

传统模式

执行命令display current-configuration | include dot1x authentication-method，

传统模式下，802.1X用户认证方式默认为chap（即CHAP的EAP终结认证方式）。如果不一致，请在系统视图或接口视图下执行命令dot1x authentication-method { chap | pap | eap }修改802.1X用户认证方式。

注:

系统视图和接口视图下同时配置dot1x authentication-method时， 接口视图下配置优先生效。

对于绝大多数终端，设备需配置认证方式为EAP中继认证方式。

执行命令display authentication mode确认NAC配置模式：
unified-mode：统一模式。
common-mode：传统模式。

统一模式

统一模式下，认证域之间存在优先级，终端在优先级高的认证域中进行认证：指定接入类型的强制域 > 非指定接入类型的强制域 > 用户名中携带的合法域 > 指定接入类型的默认域 > 非指定接入类型的默认域 > 全局默认域。

首先确认认证接口下绑定的认证模板是否通过access-domain指定了默认域或强制域，然后再确认全局默认域。可以执行以下步骤进行检查。

1、执行命令display authentication-profile configuration检查认证模板下认证域是否配置。

●未配置时，请确认是否需要配置。如果无需配置，请执行步骤2；如果需要配置，请在认证模板视图下执行命令access-domain domain-name dot1x [ force ]。

●已配置时，请确认配置是否正确。如果不正确，请在认证模板视图下执行命令access-domain domain-name dot1x [ force ]。

2、执行命令display aaa configuration确认全局默认域。

根据全局默认域，执行命令display domain name domain-name确认该域下的认证、计费方案以及绑定的认证服务器配置。

传统模式

认证域之间存在优先级，终端在优先级高的认证域中进行认证：接口下指定的802.1X认证域 > 用户名中携带的合法域 > 全局默认域。

先确认接口下是否指定了802.1X认证域，最后再确认全局默认域。可以执行以下步骤进行排查。

1、执行命令display current-configuration | include dot1x domain查看802.1X认证用户强制域是否配置

●如果未配置，请在接口视图下执行命令dot1x domain domain-name。
●如果已配置，请执行步骤2。

2、执行命令display aaa configuration确认全局默认域。

根据全局默认域，执行命令display domain name domain-name确认该域下的认证、计费方案以及绑定的认证服务器配置。

然后执行命令display authentication-scheme、display accounting-scheme、display radius-server configuration template确认配置是否正确。如果不正确，请执行相应的命令修改。

组网情况
如图所示，两台S6500和Switch组成RSTP环，稳定状态下阻塞点为Switch与S6500-2相连的端口

Switch和S6500 RSTP互连端口DOWN了重新UP后RSTP无法快速收敛组网图

现象描述
通过shutdown S6500-1与Switch相连的端口，再恢复该端口来检查RSTP快速收敛机制，发现S6500-1与Switch之间的链路恢复后，S6500-1与Switch的端口一直为discarding状态，30s后才转换为forwarding状态。

原因分析

使用命令debugging stp all，查看Flags字段是否有Agreement标记，如下只有Proposal

S6500-1与Switch相连的端口UP后，S6500-1发出的Proposal报文，没有携带Agreement标记，导致接口无法快速迁移，即Proposal/Agreement机制不生效。

操作步骤

在Switch与S6500相连的接口下配置stp no-agreement-check

建议与总结

当Switch和其他厂商的设备进行互通时，需要根据其他厂商设备的Proposal/Agreement机制，使用stp no-agreement-check命令来选择接口使用增强的快速迁移机制还是普通的快速迁移机制。

组网情况
如图所示，SwitchA、SwitchB和SwitchC构成RRPP环，SwitchB是环上主节点，SwitchC和SwitchA是环上的传输节点，SwitchA、SwitchB和SwitchC上的保护VLAN保护实例0下的VLAN。

多实例配置错误RRPP破环失败组网图

现象描述
部署主节点SwitchB时，未关注设备上的多实例配置，导致非0实例下的VLAN数据成环，造成很多接入设备脱管。

原因分析

1、检查SwitchB上RRPP的配置。
执行命令display current-configuration configuration rrpp-domain-region查看RRPP域的配置。

2、检查多实例配置
执行命令display stp region-configuration查看SwitchB的多实例配置。

3、检查VLAN配置
执行命令display vlan查看实例1中的VLAN下的接口。

SwicthB的配置如下：

SwitchC的配置如下：

SwitchA的配置如下：

发现环上的每个接口都允许VLAN 2500通过，且有环外的端口也允许VLAN 2500通过，VLAN 2500在实例1下，RRPP环保护实例0下的VLAN，导致VLAN 2500的数据成环。

操作步骤

此案例中，部署RRPP环的目的是保护所有VLAN，可以将实例1删除。以SwitchB为例

建议与总结

部署RRPP环的时候，需要关注设备之前的多实例配置是否对部署有影响。

组网情况
如图所示，交换机SwitchA上配置SmartLink，接口GE1/0/2和GE1/0/3分别为主接口和从接口。

交换机上SmartLink主从切换后流量断流问题案例组网图

现象描述
SwitchA上SmartLink因为接口GE1/0/2链路故障发送主从切换后发生断流，必须手动刷新MAC和IP地址，业务才可以恢复正常。

原因分析

当Smart Link组发生链路切换时，原有的转发表项将不适用于新的拓扑网络，需要整网进行MAC表项和ARP表项的更新。这时，Smart Link组通过发送Flush报文通知其他设备进行地址表的刷新操作。必须在上行设备配置Flush报文接收功能，才能正常接收刷新的MAC表项和ARP表项，否则无法正常接收下游设备发送的Flush报文，链路切换后无法正常转发报文。

对于该问题，SwitchD上对应的端口上没有配置接受Flush报文，当SwitchA切换的时候发送的Flush报文到SwitchD，SwitchD没有刷新对应的ARP表项（应该从SwitchA的GE1/0/2刷新到SwitchA的GE1/0/3），经过SwitchD的流量还是发送到切换前的链路，但是原来链路已经阻塞，报文无法通过，导致流量中断。

操作步骤

在SwitchB、SwitchC和SwitchD三台设备主、备链路上的接口下（即SwitchB的接口GE1/0/2和GE1/0/3、SwitchC的接口GE1/0/3和GE1/0/4、SwitchD的接口GE1/0/4和GE1/0/5）查看是否配置了命令：smart-link flush receive control-vlan vlan-id。

经过查看，发现没有相关的命令，在SwitchB、SwitchC和SwitchD三台设备主、备链路上的接口下配置命令：smart-link flush receive control-vlan vlan-id，且配置的Flush控制VLAN和密码与SwitchA上配置发送的相关信息必须相同。

建议与总结

只有为接口配置了控制VLAN编号并将接口加入该VLAN，接口才能接收到Flush报文。

并非需要在相关设备的所有接口上都配置从指定控制VLAN接收Flush报文功能，只有那些处于从Smart Link设备到其目的设备主、备链路上的接口才需进行此配置。

组网情况
如图所示，Switch通过L2 Switch交换机下挂PC用户，PC用户希望访问内网服务器Server。

交换机误配置loopback internal导致环路故障案例组网图

现象描述
当Switch下挂PC用户访问服务器Server时，发现丢包严重，业务中断。

原因分析
设备上存在loopback internal误配置，导致MAC漂移，通信异常。

操作步骤
1、删除L2 Switch上误配置的loopback internal。

在Switch的VLAN视图下执行命令loop-detect eth-loop alarm-only，使能MAC-Flapping检测机制。

2、执行命令display trapbuffer，查看告警信息，找寻是否存在MAC Flapping以及漂移的端口告警。通过告警得知Switch上接口GE0/0/1下接口存在MAC漂移，可以先排查下游设备配置。

3、登录L2 Switch设备，执行命令display current-configuration，查询L2 Switch接口配置，发现有接口下配置了loopback internal，导致Server的MAC地址学习到Switch与L2 Switch相连的端口。

建议与总结
对于二层转发丢包，MAC漂移是较常见的一种原因。当出现此类问题时，可以查看设备是否发生了MAC漂移，并排除此故障。