CNESA - SE_You的文章

SE_You 的文章

交换机

锐捷N18012 直连ping不通

一、故障现象故障现象：交换机无法和部分直连设备通信，测试了172.31.255.2和172.31.255.54两个地址。影响范围：直连不通，服务器逃生状态全校免认证，部分服务器不可达。影响认证和其他的业务。网络拓扑如下：二、设备型号和版本设备型号：N18012 版本号：B58P2 三、故障排查思路出现故障时候做了什么操作；报文是否丢在我们交换机上；报文是什么原因被丢弃；四、故障排查过程根据现场的工程师这边说的情况，现场没有进行过操作。今天早上九点突然出现了这样的情况通过快转命令，明确了报文确实被我司交换机丢弃，丢弃的原因是因为ACL组件命中被丢弃。（ACL组件包括所有的安全命令） ACL组件包括的功能有： ACL、认证功能、绑定功能查看配置命令发现，现场有配置address-binding的命令，但是没有将对应的接口和终端进行放通导致的被IP+MAC组件丢弃。五、解决方案由于现场的误操作，配置了ip+mac命令。将对应的IP+MAC命令删除，业务恢复正常六、故障总结 show run debug efmp packet ping sip x.x.x.x smac any dip x.x.x.x dmac any count X

SE_You 2024-12-02

9 0 0
交换机

锐捷S6150-X下1栋办公楼网络时通时不通

一、故障现象描述现场S6150-48VS8CQ-X设备下接一栋办公楼办公网络出现异常，故障期间导致客户现场无法正常办公。二、故障排查分析查看设备配置、CPU、内存未发现明显异常情况查看设备生成树端口情况，发现S6150X上部分接口状态一直在跳变，初步怀疑S6150X下面接入网络存在异常，进一步查看日志是否有异常情况。异常截图如下：通过查看日志发现接口16以及18处理ARP以及ND报文的能力已经达到了水线值，此情况下会导致经过这2接口的ARP和ND包出现概率性丢弃，进而影响通信。截图如下：由于步骤3发现16和18口出站超水线的情况，进一步查看NFPP情况，发现接口16和18口存在VLAN253的ARP DOS攻击情况（终端：10.18.20.30 Mac：d431.27d7.2461信息比较多）。截图如下：进一步分析端口16和18收发数据的情况发现接口16以及18瞬间收到了大量的广播数据。结合步骤2和3，判断16和18口下面网络存在异常广播数据，现场down掉这2个接口后测试现场业务正常。截图如下：、三、故障根因说明通过分析交换机日志信息，目前判断导致办公楼网络异常的原因是S6150-48VS8CQ-X交换机的TF0/16以及TF0/18下存在环路，客户办公室网络接环到导致的。四、故障解决方案将现场办公室小交换机环路解决，业务恢复正常。

SE_You 2024-11-29

5 0 0
交换机

锐捷S2900L管理vlan ping不通核心

一、故障现象 S2900L使用管理vlan 241的地址无法ping通核心的管理vlan以及汇聚的管理vlan，汇聚的管理vlan可以ping通核心的管理vlan。网络拓扑如下：二、设备型号和版本设备型号：RG-S2900-24GT4SFP/2GT-L 软件版本：S2900L_RGOS11.4(1)B75 三、故障排查步骤 1）可以先通过acl计数明确下是接入没发，还是汇聚收到处理异常； 2）明确到对应的设备之后再进行具体排查；四、故障排查过程 1、明确现场网络拓扑如下 S2900L（g0/26)-----(ten 2/0/46)S6120-48XS8CQ 2、由于S2900L不支持acl计数，故在S6120的下联口调用acl计数，发现S6120的下联口没有收到接入的报文 3、查看发现S2900L的上联口没有学到mac地址 4、在S2900L上用命令show int counter summary up发现g0/26接口只有发出去的数据报文，没有收到的数据报文 5、在上联汇聚S6120用同样的命令查看，发现ten 2/0/46接口也只有发出去的数据报文，没有收到的数据报文 6、了解到现场S6120是使用友商的光转电模块和S2900L互联，判断是该模块异常，导致S2900L和S6120的数据不通，从而管理vlan无法互通。故障原因总结：通过上述分析，定位故障原因为客户原因。由于客户使用友商的光转电模块和S2900L互联，导致接入和汇聚的数据不通，从而导致管理vlan无法互通。五、解决方案由于S6120-48XS8CQ不支持光转电模块，故需要使用光模块和S2900L互联。

SE_You 2024-11-28

9 0 0
交换机

锐捷S7810X 视频终端掉线

一、故障现象描述 S78X作为网络的核心设备，客户突然发现部分视频终端无法上网，影响会议视频。二、故障排查分析掉线终端分布在不同的网段以及不同汇聚下，网关在S78X上。核心上查看，未学习到该终端arp表项，学习到了mac表项（终端mac：e851.9ed9.cf08）在核心上做acl计数查看，判断终端有发arp报文至核心，但是核心未回包快转debug efmp packet filter etype arp dst mac e851.9ed9.cf08 cou查看核心未回包原因发现终端回复的网关地址为10.10.212.1，携带vlan210的tag。实际该网关10.10.212.1属于vlan212。因此判断接入设备连接终端的vlan配置有误登入接入设备查看下联口配置sw access vlan 210。将sw access vlan 210改为sw access vlan 212后，终端恢复正常。三、故障根因说明由于现场异常断电，且运维人员未保存设备配置，导致多个接入设备被重启后接口配置还原成vlan 210，导致终端无法上网。四、故障解决方案将接入交换机连接终端接口sw access vlan 210配置改为sw access vlan 212恢复。

SE_You 2024-11-27

5 0 0
交换机

锐捷N18010 下联1栋楼无线AP不通AC

一、故障现象描述客户感知的故障现象：3号楼所有AP都掉线了，无线用户不能上网。故障的技术异常表现：无线工程师排查发现AP与AC之间连通性异常，AP无法ping通AC上的隧道地址。场景拓扑：两台AC6816组成VAC，两台N18010组成VSU，AC与核心N18010通过AGG1直连，所有网关都在核心上。故障区域3号楼在核心的接口是vlan 3300，通过AGG24与下联汇聚单线路互联。: 二、故障排查分析现象分析：通过故障现象和无线工程师的初步排查可以获得的有效信息如下。 AP无法ping通AC上的隧道地址2.2.2.2。 N18010直连可以ping通AC的2.2.2.2地址，并且可以通过该地址telnet登陆到AC上。客户未对网络做过变更操作。基于上述信息，说明AP掉线的原因是与AC的连通性异常导致。导致连通性异常的原因，是交互报文在中间链路上丢失。所以排查重点是找到报文的丢失点，并明确丢失原因。排查步骤：定位丢包点在核心上对连接AC的接口和连接3号楼的接口进行ACL计数，确定丢包点是否为核心，如果丢包点是核心，则进一步排查核心丢包原因，如果丢包点在上联进方向或下联进方向则进一步排查对应上下联设备的丢包原因。 a.AP ping AC计数结果表明，AC正常回包，核心正常接收到AC回包，但未从下联口送出 b.AC ping AP计数结果表明，AC正常发包，核心正常接收到AC发包，但未从下联口送出基本明确AP与AC之间的通信报文中断是发生在核心设备，进一步排查核心。排查送错接口的可能性 show log中没有异常日志。检查前往AP的路由是否正确以及核心上是否有AP的arp，确认三层通信基本条件能否满足。通过show ip ref exact-route 2.2.2.2 10.145.4.127 以及show arp，确认路由转发的出接口正确，arp学习正确，在三层表项层面可以排除送错接口的可能性，进一步明确是设备上丢包。明确设备上丢包位置 ……

SE_You 2024-11-26

13 0 0
交换机

锐捷S7910E VRRP组网服务器V6地址到网关直连不通

一、故障现象描述两台S7910E下面直连的服务器V6业务到网关直连不通。场景拓扑拓扑介绍两台S7910E使用VRRP组网，S79E1为主设备，S79E2为备份设备，两台设备之间的AGG2口使用TRUNK口互联，放通所有VLAN和VRRP报文。服务器两个网卡使用BAND6做聚合分别上联主备设备的Hu5/2端口，交换机端只做ACCESS端口配置，未做聚合。二、故障排查分析设备CPU和端口利用率正常，其他V4业务正常，排除环路可能。查看VRRP状态，两台S7910E的VRRP状态正常，主机状态为Master，备机状态为Backup，排除VRRP问题： S79E1上查看服务对应的ND表，发现ND表项是从AGG2端口即与备机的互联端口学习过来的，且状态为DELAY：同时查看S79E2设备上该服务器的MAC地址表是通过AGG2口学习，即S79E2备机学习到服务器的MAC地址是通过主机S79E1学习到的。结合组网分析，S79E1的交换机VRRP状态正常且服务器双网卡正常的情况下ND表的出接口和MAC出接口应该为Hu5/2才对，通过与备机的互联AGG2端口学习到ND表和MAC表，怀疑有环路或存在MAC迁移，反复show mac发现MAC地址确实也有从Hu5/2学习 S79E1使用debug efmp packet filter ipv6_sip XX ipv6_dip XX couter X命令开启IPV6协议栈调试，发现从AG2口一直有收到服务器的NS报文，从5/2一直收到服务器的NA报文，进一步证明S79E主设备上服务器的MAC地址会在AG2和Hu5/2端口之间迁移，可以使用show lsm inter查看聚合口对应的端口关系。交换机收到报文会触发端口下的MAC地址学习，交换机未看到MAC地址漂移是因为两个报文发送间隔过短，MAC更新有防呆保护，短时间内的漂移不会触发交换机MAC漂移日志。根据IPv6协议栈的信息，服务器一直在发NS请求，怀疑是服务器一直没有收到S7910E设备发出去的NA报文，导致服务器学习不到S7910E的ND邻居，最终导致服务器无法访问S7910E的虚……

SE_You 2024-11-25

8 0 0
交换机

锐捷N18E下联终端无法ping通网关

一、故障现象描述同一个网段内部分终端能获取到ip地址，但是无法ping通网关，导致无法弹出认证界面去认证上网。网络拓扑图如下：拓扑描述：终端接在SF2920U交换机下，通过汇聚，连接到核心N18E 二、故障排查分析检查终端侧情况，通过arp -a明确终端没有学习到网关的arp，网关ip地址为172.20.255.254；检查核心侧arp学习情况，发现核心侧可以正常学习到终端的arp；判断是核心和终端arp交互出现异常，通过arp计数明确核心有收到终端的arp请求报文，但是没有回复，异常点在核心侧；检查环境并无异常，cpp，接口均无丢包，nfpp也未有异常；进一步针对异常终端开启快转arp调试查看,发现对应arp报文被arp spoofing组件过滤了；和研发确认是触发了arp欺骗导致，若是1x或者web用户认证表项跟收到的报文表项不一致就会被判定为arp欺骗；通过debug acl efacl ef-packet srcip 172.20.0.93 count 10查看发现用户的mac之前有表项，新的ip不匹配所以被过滤了； show web-auth user ip查看发现对应mac之前确实有认证过；查看租期以及无流量下线配置，发现租期比无流量下线时间短；综上，判断是6c4b.90be.7bfd这个终端一开始获取到了172.20.0.83这个ip地址认证上线了，后面下线2小时租期到了重新获取到了172.20.0.93这个地址，但是由于无流量下线时间没到，对应的认证表项还在，此时用新ip上来，交换机校验发现不匹配原来的认证表项下发的ip+mac绑定，导致上不了网，正常无流量下线时间要比租期小，但是现场配置无流量比租期大导致。三、故障根因说明交换机无流量下线配置时间大于dhcp租期，导致用户认证后下线认证表项还在，后续重新上线由于dhcp租期到了获取了新的地址，此时由于新的地址和之前的认证表项下发的ip+mac绑定不匹配，导致触发arp欺骗，交换机不回……

SE_You 2024-11-22

5 0 0
交换机

锐捷S7805C跨设备无法ping通

一、故障现象 7805C ping S2不通，但是ping S1正常，S2 ping S1正常，S1 ping S7805C正常。网络拓扑如下：二、设备型号和版本型号：S7805C 版本：S7800C_RGOS 11.0(4)B19T3, Release(05240612) 三、故障分析思路确定网络环境是否存在环路，是否存在地址冲突； ACL计数判断是否未收到回应ICMP报文；开启快转查看ICMP报文送达驱动；专家ACL计数或者抓包查看对端回应ICMP报文是否合法；（注：对端回应ICMP不可达时ACL计数仍可以计数回应报文）四、故障分析过程解析检查双方路由均显示正常（ON2 10.0.0.0/8 10.0.15.1）；检查环境中不存在地址冲突，环路等问题。华三设备均使用静态路由进行回指，华三S1设备可以ping通两端的S7805C和S2。7805C指定静态路由 10.0.42.1 255.255.255.255 10.0.15.1 仍不通； acl计数，7805cping对端华三设备有收发但是显示不通。华三设备ping 7805c 有收到但是没有回应；设备端开启debug efmp packet filter ipv4_sip host 10.0.42.1 ipv4_dip host 10.0.15.3 v4_protocol icmp counter 5 显示未收到，acl计数结果有增长，使用debug pkt-monitor match诊断PI未发出，判断上层收到报文之后没有同步底层；接口下使能匹配源目ip的ACL计数，全局使用匹配目的mac源目ip的ACL计数显示，接口下仅匹配ip的acl能够统计到回应icmp报文，但是全局下匹配目的mac和ip的acl记不到数，故友商设备回应icmp报文时目的mac地址异常导致S7805C认为不是回音给自己的报文所以没有送达设驱动；抓包进一步确认显示友商S2回应报文在S2回应S1时显示目的MAC正常，但是S1回应S7805C时目的MAC发生变化。（实际测试每次回应报文经过S1之后目的MAC都会变化，每次变化的目的MAC不一样）；故障原因说明：友商系统异常，导致转发回应报文的目的MAC地址会随机发生变化 ……

SE_You 2024-11-21

12 0 0
交换机

锐捷S57H交换机直连ping不通

一、故障现象设备上行直连ping 172.31.12.253 不通。部分视频业务转发卡断异常。前后未做配置以及网络拓扑变更、影响业务。网络拓扑如下：二、设备型号和版本设备型号：5750H 设备版本：B12P8 三、故障排查步骤 1、了解交换机直连不通的丢包点在哪里（可以使用ACL计数初步定位） 2、确定交换机本身存在异常时控制面报文发包情况可以通过快转判断是否正常 3、了解整体端口发包机制：功能组件---》快转---》pkt---》端口 4、根据收集的信息和抓包分析出故障原因四、故障排查过程通过现场的信息分析，初步定位客户业务场景超出了设备性能详细分析如下： l 设备debug看ping 报文送到快转控制面延迟了30多秒。 l 快转发包虚线程慢，发现EFMP-1中libpkt_sock_thread占用cpu高。 PI这边进展：现象原因：从快转发包来看，协议栈将icmp报文发送给快转后，快转发包虚线程要15s后才进行发包（从log上看）。快转发包虚线程是跑在CPU核1核上。CPU1核是转发核，目前看只有EFMP-1和libpkt_sock_thread CPU高。怀疑点：进行EFMP-1这个快转转发核上gdb，发现都是卡在HZ接口，内部调用sysconf这个libc库中的系统调用，但是就算是使用该系统调用，理论上也不会卡住这么久。目前看也只有分片重组定时器使用HZ这个接口，现场需要看下是否有大量分片报文。 l 快转的报文构造的分段了，分成3段才发往驱动，说明设备收到分片报文。 l 实际抓包查看现网中存在大量的分片报文，并且有很多分片报文丢包，导致CPU收不到分片报文，导致在等大包的组包，因此造成CPU高。为什么大包送CPU慢？ l 从客户现场的信息看、部分报文速率较大，已经达到了NFPP的攻击水线，部分报文已经被隔离，导致送CPU不完整。 l 关闭NFPP后故障依旧。 l 查看芯片报文不能送CPU的原因，芯片存在MMU丢包，就是送CPU的报文太多了。缓存不够用造……

SE_You 2024-11-20

6 0 0
交换机

锐捷S5750V2-L GRE场景下同步数据异常

一、故障现象描述分部和总部的服务器同步数据异常，分部无法同步数据给总部服务器，分部上传大文件也无法获得总部服务器的响应，以及分部的考勤数据也无法传到总部服务器。场景拓扑图如下：拓扑描述：S5750V2-L和总部的核心设备建立GRE隧道来跨公网传输数据，S5750V2-L下的终端需要向总部核心下的服务器同步数据。二、故障排查分析了解到故障背景是将原思科设备替换为我司S5750V2-L交换机之后出现的问题，怀疑是我司交换机丢包导致，由于GRE报文通过acl计数无法统计到，故分别抓取正常情况和不正常情况的报文对比分析。正常情况下，终端ping小包能通，终端侧抓包如下，收发包正常。 https://www.imgdata.cn/imgs/2024/12/24/9542215b05b36124.png 正常情况下，上联防火墙抓包如下，收发包正常。异常情况下，终端ping大包不通，终端侧抓包没有reply。终端发出报文长度1514，但还未超出我司设备默认情况下最大支持的报文长度1522。（扩展说明：我司设备对报文长度设计的额外22字节，包括了Ethernet II 规范的6字节DA+6字节SA+2字节EtherType+4字节CRC，以及802.3ac增加的4字节vlan tag）异常情况下，上联防火墙抓包如下，防火墙没有收到我司设备发出的icmp request，说明大包丢包位置在我司设备上。进一步分析设备丢弃报文的原因，终端侧发出的icmp request报文是1514字节，加上4字节FCS(即CRC)和4字节vlan tag，长度刚好是1522，所以报文进入交换机接口时不会丢包。但长度超过了隧道口下的ip mtu 1360，从而导致了报文在GRE隧道口产生丢包。如果要让经过GRE封装后的报文能在交换机上正常收发，则需要在默认MTU的基础上扩展28字节，但可能会导致下一跳传输设备无法处理报文。基于客户原设备可正常转发，分析正常tcp有协商机制，会协商发送的报文大小，交换机有icmp不可达功能，正常mtu……

SE_You 2024-11-19

9 0 0