记一次SDN网络由于LEAF点部署异常故障处理
事件起因：
一个站点的原来网络故障，疑似收发器或者光纤有问题，正好此处有新施工安装的无线网络的POE交换机，于是将网络接入此交换机，将接口配置为access口。
故障现象：
将接口设置为access口后，用户无法获取业务地址，将电脑接入vlan 4093网络，地址获取正常。
处理方式：
1. 联系400进行远程诊断，通过AD CAMPLUS控制台，操作日志，将uam改为warn。异常复现，将日志下载进行查看。
分析发现用户在认证时，无法使用认证点进行认证。怀疑认证点配置错误，经过排查，发现认证点密码设置错误（此为分发的AAA域密码），将密码重新设置，故障依旧。
2. 在排查至overlay环境时，发现LEAF点设备同步失败，通过调试发现，Netconf配置密码设置错误，此密码为交换机telnet登录密码，将密码重新设置，故障依旧。
3. 此时排查遇到难点，不过偶然在点击认证设备页面时发现，正常的LEAF节点的设备角色为Leaf，而异常的为空，下图为正常图片。日志排查也发现结点不为Leaf节点。
%% 2019-07-12 12:44:24.792 ; [LDBG] ; [24504] ; radDispatcher ; prsRawPkt: chk-sum 448050831. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [24504] ; LAN ; prsMixedUsr: in [48bd3dd91400], out [48bd3dd91400]. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [24504] ; radEnt ; setPxyType: Needn't proxy. domainname=, Code=4. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; lanAcctMsgProc.exec: begin. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; muteAuthProc: user mac is not in mute-cfg, so quit with success. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; USR ; chkIfTransparentAuthUsr: reg-status is 1 for 48:bd:3d:d9:14:00. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; lanAcctStart.exec: begin [00000004201401091852040003f65308100604]. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; c.getUsrSrvcInfoById: begin. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; accSvc ; queryServiceStrategyByID: matching rule(2) with priority 0 under srvc-templ 2. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; c.getUsrSrvcInfoById: end OK. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; lanAcctStart.setAcctOutput: Get user notify. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; AsynData ; pushOp: asyn-data msg sent 1. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; lanAcctStart.updOnline: updOnlineAtAcctStart OK. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; macReg ; entity.updTermByMac: no mac-extra-info for 48:BD:3D:D9:14:00. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; MacRegMgr ; updTermInfoAtAuth: [usrId:2, svcTmplId:2, status:1, ifPortalFast:0, prtlTmplId:0]. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; TermMgr ; respMsgProc: received an asyn-data 5672 for 48:BD:3D:D9:14:00 [usrId:2, svcTmplId:2]. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [23440] ; AsynDbSynTsk ; respMsgProc: received an asyn-data msg. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; accSvc ; getTermConlictProcessMode: the terminal conflict process mode in access rule is null, and rule id is: 2. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; macReg ; entity.chkTermConflct: old [V-T-O:--, modes:0-0-0], new [V-T-O:--, modes:0-0-0]. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; LAN ; lanAcctStart.exec: End OK. %% 2019-07-12 12:44:24.792 ; [LDBG] ; [26820] ; getDirectConnectNasIP: Campus does not enable, or auth device(100.2.1.51) is not leaf device(role: 255).
此时将认证点删除，并重新添加，进入通用组，点击部署预览，发现出现错误，无法查询已出故障的认证点设备，进行查询的时候也进行报错。
解决方法:
将认证点重新删除，并添加，用户可以正常认证，但是笔记本及台式机获取IP地址正常（但非常慢），哑终端设备不正常。
经过诊断得知：ACL3001 配置没有正常下发，通过手动写入配置，Portal认证正常，但是DHCP分配地址出现问题：获取IP地址正常（但非常慢），哑终端设备不正常。
具体表现为：
DHCP四次握手，DHCP服务器接收到哑终端请求包，但是DHCP分发包，哑终端没有回应。
后排查原因，是因为链路使用光收发器，切换到光纤模块，用户地址获取正常。
2019-7-15 16:32:40
版权声明：
作者：龙魂
链接：https://blog.wlzs.cn/%e8%ae%b0%e4%b8%80%e6%ac%a1sdn%e7%bd%91%e7%bb%9c%e7%94%b1%e4%ba%8eleaf%e7%82%b9%e9%83%a8%e7%bd%b2%e5%bc%82%e5%b8%b8%e6%95%85%e9%9a%9c%e5%a4%84%e7%90%86/
文章版权归作者所有，未经允许请勿转载。
THE END
