一个H3C交换机周期性断网并自动恢复的排查案例

一个朋友发我一个H3C日志,这个交换机是汇聚层交换机,1和2口是trunk口,其它接口是access接口,17-21口据说接的都是监控、终端。日志里面看到大量的拓朴改变,好几个网口up、down的日志,怀疑是环路,排除了本机环路后,我让他对access端口开启了端口保护,然后就排查两个trunk口的问题

我怀疑两个trunk口,可能一个是上联到核心,一个是下联接入,一般上联存在环路的可能性较小,有可能是下联交换机的问题,但同时有这么多口子,包括trunk和access端口短时间密集发生拓朴改变有点匪夷所思,会不会是下层交换机之间有环路,但朋友提出:如果环路,网络不会恢复,查了下H3C手册:有这样一段话:

  1. 环路监测处理模式

环路监测的处理模式,就是系统监测到环路时的处理方式,分为以下两种:

l None模式:当监测到端口出现环路时,除打印日志信息和发送告警信息外,不对该端口进行任何处理。

l Shutdown模式:当监测到端口出现环路时,除打印日志信息并发送告警信息外,还会关闭该端口,使其不能收发报文(包括环路监测报文)。

说明环路默认情况下是只记录日志,不做任何处理的 ,于是到下联的trunk端口开了环路检测,结果没有查到环路。(H3C关于环路检测的文章:14-环路检测命令-新华三集团-H3C

14-环路检测命令-新华三集团-H3C)

突然想到以前处理过一个案例:就是上游锐捷交换机一开启stp,一台下游的老的H3C(V5版本)的trunk口就down掉了,因为日志里有这样一条:bpdu格式错误,后来在H3C的trunk口设置了stp compliance dot1s //表示端口只发送标准格式(符合802.1s协议)的MSTP报文,网络就正常了。会不会是不同品牌的交换机的bpdu报文造成的呢?

于是查了下知了社区:有这么一条回答:配置了bpdu保护、边缘端口后还是有大量BPDU TC日志,原因是stp模式不一致导致,因为公司内网有思科,华为,H3C,迈普等等交换机,因此stp用的是PVST,而H3C默认的是MSTP,导致以上配置配完还是有大量TC。因此要更改STP 模式stp mode pvst

因为网络太乱了,朋友说找不到下游的交换机在哪里!所以出现故障,要多方查找可能的故障原因,一一排除。现在只有等梳理好网络再说了~ 所以说有个好的网络习惯真的很重要啊!

最后,跟朋友提议:老的网络最好批量做一下版本升级,可以避免一些不兼容的情况出现;监控和办公网最好划分到不同的网段,这样网络拓朴更简洁易于梳理、减少广播包、将来做策略也更方便些。

相关推荐
Wy_编程2 分钟前
Linux-文本搜索工具grep
linux·运维·服务器
qq998993 分钟前
AAA服务器技术
运维·服务器
xujiangyan_5 分钟前
linux的sysctl系统以及systemd系统。
linux·服务器·网络
Lovyk8 分钟前
Linux Shell 常用操作与脚本示例详解
linux·运维·服务器
iCan_qi44 分钟前
【Mac】【Minecraft】关于如何在Mac上搭建基岩版MC服务器的方法
运维·服务器·macos·minecraft
ezreal_pan3 小时前
Kubernetes 负载均衡现象解析:为何同一批次请求集中于单个 Pod
运维·云原生·k8s·traefik
朱皮皮呀3 小时前
Spring Cloud——服务注册与服务发现原理与实现
运维·spring cloud·eureka·服务发现·php
吱吱企业安全通讯软件3 小时前
吱吱企业通讯软件保证内部通讯安全,搭建数字安全体系
大数据·网络·人工智能·安全·信息与通信·吱吱办公通讯
云边云科技5 小时前
零售行业新店网络零接触部署场景下,如何选择SDWAN
运维·服务器·网络·人工智能·安全·边缘计算·零售
城管不管5 小时前
Docker核心---数据卷(堵门秘籍)
运维·docker·容器