```html

凌晨两点，网络我盯着终端上第37行输出，工程OSPF邻居卡在EXSTART状态。师查这不是网络我第一次遇到这个毛病，但每次原因都不一样。工程上一次是师查MTU不匹配，上上次是网络组播被ACL拦了，这回呢？工程我敲下show ip ospf neighbor detail，看到DR字段是师查0.0.0.0——得，又得查。网络

网络工程师的工程日常，一半时间在配置，师查另一半在“查”。网络查路由表、工程查ARP、师查查MAC、查会话、查日志、查抓包。查这个动作，比配更磨人。配是主动的，你知道要做什么；查是被动的，你只知道它不对，但不知道哪儿不对。

有个刚入行的同事问我：“哥，你平时查故障有什么套路？”我想了想，还真没有固定套路。非要说的话，就是先分层，再分段，最后分设备。分层是OSI那套，物理层看灯、看光衰、看CRC；数据链路层看VLAN、看STP、看MAC漂移；网络层看路由、看ACL、看NAT。分段就是A到B不通，先ping网关，再ping对端网关，再ping目标。分设备更简单——把路径上每台设备都登上去，逐跳看。

但现实往往比这乱。有一次用户报“上不了网”，我查了半小时，最后发现是DNS服务器地址配错了。还有一次更离谱，整个楼层断网，查了半天，结果是保洁阿姨把接入交换机的电源碰掉了。你没法用分层模型解释这个。

工具方面，我习惯用ping和traceroute先摸个底，然后telnet或ssh上去看配置。抓包的话，tcpdump和Wireshark是标配，但别迷信抓包——有时候抓了半天，发现是应用层的问题，跟网络半毛钱关系没有。我见过一个案例，用户说“网页打不开”，抓包显示TCP三次握手正常，HTTP请求也发出去了，但服务器返回403。这能怪网络吗？

查日志是个细活。华为设备看display logbuffer，思科看show logging。别只看error级别，warning和notice里也藏着线索。有次我查一个间歇性丢包，日志里啥都没有，最后是看接口计数器发现input errors在缓慢增长，换了根网线就好了。计数器这玩意儿，比日志实在。

还有个经验：别忽略物理层。我见过太多人一上来就查路由协议，结果发现是光模块坏了。看接口状态，show interface里如果CRC计数在涨，或者late collisions有值，先查线、查光、查模块。电口的话，换根跳线试试，成本最低。

说到查，不得不提“查什么”和“怎么查”的区别。查什么靠经验，怎么查靠工具。经验这东西，就是踩坑踩出来的。我有个本子，记了各种奇葩故障：VLAN没放行、STP根桥被抢、ARP欺骗、DHCP地址池耗尽、路由重分发环路。每次翻本子，都能想起当时怎么查的。

现在云网融合了，查的范围更大了。以前查物理机，现在查虚机；以前查VLAN，现在查VXLAN；以前查OSPF，现在查BGP EVPN。但底层逻辑没变——还是分层、分段、分设备。只是工具变了，tcpdump变成tcpdump加ovs-tcpdump，show interface变成show interface加ovs-vsctl show。

最后说个真事。上个月，一个客户说“网络慢”。我登上去看，接口利用率不高，路由表正常，CPU也正常。查了俩小时，最后发现是DNS解析慢——他们用的公共DNS，那会儿正好抽风。换成内网DNS，秒好。这事告诉我：查网络，别只盯着网络层。应用层、系统层、甚至外部服务，都可能是根因。

网络工程师查询，查的是故障，练的是心性。急不得，也懒不得。你跳过一步，后面就得花十步补回来。就这么简单。

```