光纤模块故障导致端口汇聚丢包

第一次写,语言表达能力很差,对付看吧。

今天突然收到很多网络报警,查看后发现有些IP通,有些不通。

最后发现,是接入层的捆绑没起来。其中一个端口是down的状态。

公司的核心与接入层是通过捆绑的2G线路。核心HW9303(ETH-TRUNK),接入层H3C5500(Bridge-Aggregation)。

H3C5500 IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/4 link status is DOWN.

H3C5500 LAGG/5/LAGG_INACTIVE_PHYSTATE: Member port GigabitEthernet1/0/4 of aggregation group BAGG2 becomes INACTIVE because the port‘s physical state (down) is improper for being attached.

H3C5500 IFNET/3/LINK_UPDOWN: Bridge-Aggregation2 link status is DOWN.

但核心那边端口起来了啊,dis int g2/0/7,端口是up的。最后没办法,先把核心连接入层报故障的端口2/0/7 ,shutdown了,然后网络暂时恢复正常了。

但1G线路既不够用也不安全啊,开始查问题,开始以为接入层的模块有问题,换完模块后问题依旧,还是报同样的错误。

后来检查光纤发现从核心过来的没光,端口undo shut后,端口亮一下就灭了,换个模块好了。

然后我用之前建的捆绑Bridge-Aggregation1,插上模块,把原来1/0/3,1/0/4端口的光纤都插上去后,汇聚立刻up了,收发数据正常,网络也不丢包了,问题解决。

H3C5500 IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/1 link status is UP.

H3C5500 IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/2 link status is UP.

%Apr 28 09:12:21:859 2017 NT3L-E10-H3C5500 LAGG/5/LAGG_ACTIVE: Member port GigabitEthernet1/0/1 of aggregation group BAGG1 becomes ACTIVE.

%Apr 28 09:17:43:958 2017 NT3L-E10-H3C5500 LAGG/5/LAGG_ACTIVE: Member port GigabitEthernet1/0/2 of aggregation group BAGG1 becomes ACTIVE.

再看核心上的模块,果然没光,再把它拔下来插到H3C上测试,发现日志报错,可以断定是模块的问题了。

H3C5500 OPTMOD/5/TX_ALM_ON:

GigabitEthernet1/0/4: TX_fault is detected!

所以可以肯定是模块的问题了,TMD破模块坏就彻底坏呗,还一边能UP

顺便吐个槽,坏的是CISCO的原装模块,我发现这几年坏的都是原装模块。100多买的兼容模块还真没坏过,真是让我无语。

时间: 2024-10-09 03:37:49

光纤模块故障导致端口汇聚丢包的相关文章

STP 抖动导致内网丢包

故障现象内网访问公网出现不规律丢包现象 排查解决方法1.stp类型stp为mstp 单实例 2.接口tc报文发送接收对比接入.汇聚.核心 disp stp tc 报文数量,基本锁定故障位置 3.access接口配置边缘端口接入层交换机部分接口未配置边缘端口,增加配置 4.部分特殊接口关闭stpdisp stp tc发现某个端口特别异常,tc收包特别多,且disp stp bpdu-statistc interface 发现最近也在变动,disp lldp nei l显示对端设备为mstp专线连接

Ping丢包故障案例

一.Ping丢包故障 1.Ping丢包故障现象 二.故障猜想可能存在以下问题 1.物理环境故障:2.网络环路:三.故障定位1.物理环境故障:登录交换机dis int g1/0/1查看端口下面不存在CRC报文,排除物理环境故障.2.网络环路(1)通过display interface brief | include up命令,查看所有UP接口下的流量,存在环路的接口上InUti和OutUti两个计数会逐步增加,甚至到接近100%,远远超过业务流量. ??? 第一次查询: ??? <SwitchA>

[转]nf_conntrack: table full, dropping packet 连接跟踪表已满,开始丢包 的解决办法

nf_conntrack: table full, dropping packet  连接跟踪表已满,开始丢包 的解决办法 中午业务说机器不能登录,我通过USM管理界面登录单板的时候发现机器没有僵死,然后一看日志,g一下子就明白了 tail -2000 /var/log/messages Apr 10 12:48:35 bj-push-pushserver83 kernel: [95129.138804] __ratelimit: 16523 callbacks suppressed (“连接跟

客户端本地到服务器丢包的检查方法

如果用户本地到服务器出现ping丢包或直接无法连接的时候,可以通过如下步骤进行排查分析:   客户端本地到服务器丢包的检查方法 1. ping服务器IP地址或域名,查看丢包情况:     ping 140.205.140.234 -n 100  说明: -n 后面的数字表示要进行的ping测试次数: 主要关注如下下图所示所统计的丢包率和平均超时时间: 2. 使用MTR工具跟踪下到服务器的链路情况: Windows下,使用所示的WinMTR工具进行跟踪测试: 用法:打开软件后,在[hosts]框中

Linux服务器丢包故障的解决思路及引申的TCP/IP协议栈理论

我们使用Linux作为服务器操作系统时,为了达到高并发处理能力,充分利用机器性能,经常会进行一些内核参数的调整优化,但不合理的调整常常也会引起意想不到的其他问题,本文就一次Linux服务器丢包故障的处理过程,结合Linux内核参数说明和TCP/IP协议栈相关的理论,介绍一些常见的丢包故障定位方法和解决思路. 问题现象 本次故障的反馈现象是:从办公网访问公网服务器不稳定,服务器某些端口访问经常超时,但Ping测试显示客户端与服务器的链路始终是稳定低延迟的. 通过在服务器端抓包,发现还有几个特点:

交换机端口丢包问题

H3C S5500 是核心,与邻栋建筑的S3100链接.用户反映3100下的客户端网络不稳定. 链接方式  (5500)网线(百兆光电转换)光纤到邻栋(百兆光电转换)网线(3100) 首先ping ,偶尔丢包 3%-5%,偶尔又好了..奇怪 然后查看3100和5500所在端口配置都正常 查看端口input和output 都没有errors 但是端口利用率比较高 Last 300 seconds input:  5910 packets/sec 6288557 bytes/sec 51% 然后查看

Linux NAT哈希表满导致服务器丢包

发现ECS Linux服务器出现间歇性丢包的情况,通过tracert.mtr等手段排查,外部网络未见异常. 同时,如下图所示,在系统日志中重复出现大量如下错误信息: Jun 13 15:20:23 web3 kernel: nf_conntrack: table full, dropping packet.Jun 13 15:20:24 web3 kernel: nf_conntrack: table full, dropping packet.Jun 13 15:20:24 web3 kern

关于ip_conntrack跟踪连接满导致网络丢包问题的分析

我们的线上web服务器在访问量很大时,就会出现网络连接丢包的问题,通过dmesg命令查看日志,发现如下信息: kernel: ip_conntrack: table full, dropping packet. kernel: printk: 1 messages suppressed. kernel: ip_conntrack: table full, dropping packet. kernel: printk: 2 messages suppressed. kernel: ip_conn

sendto频率过快导致发送丢包

编写一个转发模块,虽然没有要求一转多时要达到多少路(不采用组播的情况下,单纯的一路转成多路),但是本着物尽其用的原则,尽可能测试一下极限. 网络环境:1000M,直连,多网卡 系统:Linux version 3.19.0 接收模式:udp模式的raw socket(优化的话,可以直接通过网卡处理) 发送模式:udp模式的raw socket(优化的话,可以直接通过网卡处理),单线程/多线程 2M               1转N 设备A   ---------------->   转发设备