display logbuffer 是什么命令？

华为/华三等设备上查看日志缓冲区的命令，输出设备记录的最新事件与错误，相当于设备的「黑匣子」。排障第一铁律就是遇事不决先看日志，它常比配置更能暴露真相。

为什么排障要先看日志？

配置没变、端口流量正常时，问题往往藏在事件里：环路、ARP 欺骗、端口 err-disable 都会在日志留下记录。先读日志能直接锁定方向，避免一头扎进命令行空转。

怎么过滤日志找元凶？

用管道过滤，如 display logbuffer | include ARP|IP 查地址冲突，或 display logbuffer level warnings 看警告以上事件。日志刷屏时过滤能快速抓到关键一条。

MAC 地址漂移说明什么？

日志出现 MAC_FLAPPING（MAC 在多个端口间反复横跳）几乎肯定是网络环路或 ARP 欺骗：同一 MAC 从 G1/0/10 与 G1/0/25 来回跳，说明存在重复地址或闭环，导致数据包发错地方。

顺藤摸瓜怎么定位到端口？

拿到异常 MAC 后，display mac-address 查它当前所挂端口，再 display interface 看端口下联设备；若下联是接入交换机，登入继续查，直到定位具体物理端口与用户，拔掉或修复即恢复。

用日志定位环路/欺骗的步骤？

① display logbuffer 直切主题；② 过滤 ARP/IP 或 warnings 找漂移/冲突日志；③ display mac-address 定位端口；④ 逐层登交换机下钻到物理口；⑤ 隔离端口验证恢复。全程围绕日志，分钟级定位。

网络排障先看日志：display logbuffer 实战

01 前言：为什么日志是网工的“第一现场”？

兄弟们，不知道你们有没有这种经历：网络突然卡了，用户疯狂打电话，你一头汗地登设备，ping也丢包，display interface一看端口流量也没错，配置display current-configuration对比上周的备份也没变过… 直接陷入僵局！

网络排障先看日志：display logbuffer 实战 — 图片素材来自免费商用图库（pixabay），非本站项目实拍。

这时候，能告诉你真相的，不是配置，而是日志（Log）。它就像设备的“黑匣子”或“行车记录仪”，忠实记录了每个关键事件和错误。我个人的故障排查第一铁律就是：遇事不决，先看日志！

今天，我就把我的私藏排查流程和命令分享出来，让你在5分钟内，像个老手一样定位问题。

02 实战背景：某医院网络频繁掉线

场景复现:

上周，某医院门诊楼的无线网络频繁出现“假死”，Ping延迟忽高忽低，时通时断，但有线网络正常。作为驻场工程师，我接到了这个棘手的任务。

我的排查装备：

一台笔记本（装好SSH/Telnet客户端，如SecureCRT）

核心交换机（H3C S6850）的管理IP地址和账号密码

核心武器：display logbuffer 命令

03 5分钟故障定位四步法

第1分钟：登上设备，直切主题

打开终端，第一时间不是去看配置或者端口，而是直接查看日志缓冲区。这是最快的方式。

<H3C-S6850>display logbuffer

*(如果提示权限不够，记得用 super 命令提权到 level-3)*

这个命令会输出设备记录的最新日志。但内容太多怎么办？我们直接用管道符 | 进行过滤。

第2分钟：精准过滤，抓住元凶

根据“无线不稳定”这个现象，我首先怀疑的是ARP或DHCP相关问题。于是我用了两个过滤命令：

# 查找包含 ARP 或 IP 冲突相关的日志

<H3C-S6850>display logbuffer | include ARP|IP

# 或者查找所有警告级别以上的日志（更严重）

<H3C-S6850>display logbuffer level warnings

果然，命令一回车，屏幕上就疯狂刷出同一条“诡异”的日志：

%Aug 18 14:23:15:509 2025 H3C L2MGNT/5/MAC_FLAPPING: MAC address 5489-98b3-2111 has been moving between port GigabitEthernet1/0/10 and port GigabitEthernet1/0/25.

翻译一下：MAC地址 5489-98b3-2111 一直在接口 G1/0/10 和 G1/0/25 之间反复横跳！（这种现象叫 MAC地址漂移）

破案了！这百分之九十九是网络环路或者ARP欺骗的典型症状。无线用户获取到了错误的IP-MAC映射，导致数据包发错了地方。

第3分钟：顺藤摸瓜，定位端口

现在知道了搞事的MAC地址和两个端口。下一步就是找到这个MAC地址到底对应哪台设备。

# 查看MAC地址表，找到这个MAC具体挂在哪个端口上

<H3C-S6850>display mac-address 5489-98b3-2111

输出结果：

MAC Address VLAN ID State Port/NickName

5489-98b3-2111 100 Learned GigabitEthernet1/0/10

Aging time: 300s

确认了，这个设备现在稳定地连接在 GigabitEthernet1/0/10 上。

接下来，查这个端口下接了什么设备：

# 查看端口G1/0/10的详细信息，包括描述（通常好的规划会写明下联设备）

<H3C-S6850>display interface GigabitEthernet 1/0/10

如果描述不清，怎么办？登入下一层交换机！ G1/0/10下很可能接的是一台接入层交换机。用同样display mac-address的命令在那台交换机上继续查，最终定位到具体的物理端口和连接这个端口的用户。

第4分钟：解决问题，验证结果

我们最终在接入层交换机上定位到了这个MAC对应的端口是 GigabitEthernet0/5。

处置方法：

1,保守治疗：shutdown 掉这个端口，观察网络是否立即恢复正常。

2,根治问题：联系该端口所属的区域（比如门诊三楼护士站），让同事去现场查看。结果发现是一台私接的家用路由器，网线错误地插在了LAN口上，形成了一个环路，引发了ARP广播风暴。

3,拔掉违规设备，重新 undo shutdown 开启端口。

验证：再次使用 display logbuffer | include MAC_FLAPPING，发现那条烦人的日志不再刷屏了。网络Ping测试完全恢复正常。搞定！

过程：

04 必备命令清单：

我把我总结的日志分析高频命令清单送给你，遇到不同问题，直接套用：

怀疑方向推荐命令命令说明

综合查看 display logbuffer 查看日志缓冲区所有内容

display logbuffer level 0-7 按等级查看（0最高，常见4-warnings及以上）

精准过滤 display logbuffer | include ARP 只看包含“ARP”关键词的日志

display logbuffer | include up|down

display logbuffer reverse 反向显示日志（最新的在最下面）

端口问题

display interface brief

查看所有端口状态摘要

查看端口震荡日志

反向显示日志（最新的在最下面）

display counters interface inbound 查看端口入方向错误包统计

MAC/IP问题 display mac-address <mac> 根据MAC查端口

display arp | include <ip> 根据IP查MAC

保存日志

display logbuffer save logfile.zip

将日志导出为文件，方便后续分析

05 常见故障日志解读词典（新手必存）

看到一条日志别发懵，对照这个表快速理解：

日志关键词/示例	白话翻译	可能原因
`LINK_UPDOWN: GigabitEthernet1/0/1 link status is DOWN`	端口物理状态Down了	网线没插好、对端设备断电、光模块故障、端口损坏
`MAC_FLAPPING: MAC address X has been moving between port Y and port Z`	MAC地址在Y和Z端口间反复横跳	网络环路（最常见）、ARP欺骗攻击、非法私接设备（如HUB、路由器LAN口互联）
`INPUTODDROPPED: 1000 packets dropped on interface GigabitEthernet1/0/1 last 1 minute`	端口在1分钟内丢掉了1000个入向包	广播风暴、端口速率/双工模式不匹配、设备性能瓶颈
`ARP_DUPLICATE: IP address 10.1.1.100 is conflicted with another device`	IP地址10.1.1.100和别的设备冲突了	用户手动设置了重复的静态IP、DHCP服务器分配地址冲突

06 总结

兄弟们，日志分析不是死记硬背命令，而是培养一种“侦探思维”：

接收报警（用户说网络卡）-> 2. 收集证据（display logbuffer） -> 3. 寻找线索（include 过滤关键词） -> 4. 锁定目标（display mac-address） -> 5. 解决问题（shutdown端口或现场处理）。

最后送大家一句话：最好的故障解决，是预防。养成定期查看核心设备日志的习惯，很多问题在萌芽阶段就会被你发现。

一、分层排障模型（从物理层到应用层）

网络故障排查最忌”乱试”。按 OSI 自底向上：物理层（网卡/线缆/光模块/端口灯）→ 数据链路层（VLAN、MAC、STP、协商速率）→ 网络层（IP、网关、路由、ARP）→ 传输层（TCP/UDP 端口、ACL）→ 应用层（DNS、代理、证书）。先确认链路通断（网卡 up、协商速率正常），再 ping 网关，再 traceroute 看断点在第几跳，最后查应用端口与日志。

二、排障工具箱

ping / pathping / mtr：看连通性与逐跳丢包延迟。
traceroute / tracert：定位故障跳点，区分运营商侧还是内网侧。
Wireshark：抓包看 TCP 重传、RST、DNS 超时、ARP 风暴，可复现 NAT 穿透与三次握手异常。
交换机端口：err-disable、CRC 错包、双工不匹配、loop guard 是端口故障高频原因，show interface 看 counters 是第一步。
防火墙：iptables/firewalld/nftables/ufw 规则顺序与默认策略决定放行，改前先备份规则、确认 SSH 不会被锁死。

三、工程经验

交换机端口频繁 err-disable 多因 BPDU guard 或线缆接触不良；无线与有线混排时优先固化上联端口；变更防火墙前在测试环境验证并保留回滚命令。运维类故障的闭环是：复现 → 定位 → 临时恢复 → 根因修复 → 复盘沉淀。