LAB2的实验拓扑里，我见过太多这样的场景：IP配好了，路由也写了，VLAN也划了，PC1去ping PC2，终端里一串timeout。学生第一反应往往是“哪里配错了”，但真正高效的思路不是从头到尾翻配置，而是顺着网络数据通信过程，把ping不通的原因一层层剥出来。这篇文章就围绕Cisco环境下的这个经典问题，把一次ping从发出到返回到底走了哪些路径、每一步该查什么、用什么命令查，完整拆开讲一遍。
不管你是在某高校的实验课上被这个LAB2折磨过，还是准备网络工程师面试的时候想把ICMP排错逻辑理顺，这篇都适用。核心方法不挑厂商，命令只要是Cisco命令行环境就能跑，后面讲的思路换到其他牌子设备上一样成立。
1. 先搞清楚一次Ping到底经历了什么
我在带别人做实验的时候发现，很多人在排错阶段慌，是因为他从头到尾就没想过“正常情况”下，一个ICMP报文从PC1到PC2究竟是怎么走的。你不先画清楚正常路径，就永远只能瞎猜。这一节我们不敲任何命令，先把通信过程彻底说透。
1.1 同网段与跨网段：目的MAC填的是谁
先记住一个总原则：IP数据包在网络上转发时，从源主机到目的主机的整个过程中，源IP和目的IP是始终不变的；但是数据链路层的源MAC和目的MAC，是每一跳都会被重写的。
这是很多人第一个认知盲区。PC1要ping PC2，如果两台PC在同一网段，那么PC1发出的数据帧里，目的MAC就是PC2网卡的MAC，这个要靠ARP广播解析出来，一问PC2的MAC是谁，PC2回答，然后PC1把包发过去。这是同网段的情况，比较简单。
但LAB2的拓扑里，PC1和PC2通常是跨网段的。假设PC1是192.168.1.10/24，网关是192.168.1.1，PC2是192.168.2.10/24，网关是192.168.2.1。PC1要发数据给PC2，它去ARP解析谁？解析网关R1的MAC，而不是PC2的MAC。因为PC1知道目标IP不在自己的网段里，它会把数据帧交给默认网关。
所以这个帧是这么构成的：源MAC是PC1的MAC，目的MAC是R1 Gi0/0接口的MAC，但是IP头里的源IP是192.168.1.10，目的IP是192.168.2.10。
R1收到这个帧之后，先看目的MAC是自己，然后剥掉二层头看三层IP头，发现目的IP是192.168.2.10，不是自己。R1去查路由表，找到去192.168.2.0/24该走哪个接口、下一跳是谁。假设下一跳是R2的10.0.0.2。R1就会把帧重写：源MAC改成R1 Gi0/1接口的MAC，目的MAC改成R2 Gi0/0接口的MAC，IP头依然原封不动。到了R2，再做一次类似的动作，最终把帧交给交换机，由交换机根据目的MAC把帧转发给PC2。
你可以用生活里的快递来类比：包裹上的寄件人和收件人地址（IP）从头到尾不变，但每经过一个中转站，站里贴的“上一站、下一站”的转运标签（MAC）都会被重新贴一遍。理解这个之后，你就知道排错时查APR表不是在查“目标主机在哪”，而是在查“下一跳的MAC解析出来没有”。
1.2 去程和回程是两条独立的转发路径
第二件事也要刻在脑子里：ICMP Echo Request和ICMP Echo Reply，本质上是两个完全独立的数据包，各自都要走一遍完整的封装、转发、解封装流程。
也就是说，PC1发给PC2的请求报文，需要沿途每一台路由器都有去往192.168.2.0/24的路由。而PC2收到请求后，要回复给PC1，PC2自己必须有一张去往192.168.1.0/24的路由，而且沿途的每一跳，也得有对应的路由把这些回包送回去。
我在实验里反复看到一种现象：一台路由器上配了去程的静态路由，回程路由忘了配，结果PC1 ping PC2一直超时。有人觉得奇怪：“我路由明明写了啊，为什么不通？”因为他只站在单方向去想网络通不通，没想到回程报文也需要路由。
更反直觉的是“单通”现象。比如PC1 ping PC2超时，但你在PC2上去ping PC1，结果是通的。这种情况下很多人完全懵掉，觉得“是不是刚才哪个配置改坏了”。其实造成这个现象的原因很可能很朴素：某一台路由器只缺了去往某一个网段的路由。正是因为去程和回程各自独立，才可能形成这种“一台通、一台不通”的诡异局面。以后遇到这种单通，不要惊讶，它是定位方向性问题的绝佳线索。
1.3 从通信过程中提炼排查点
把上面整个通信过程拆成阶段，每个阶段都有自己独立的“证据链”需要验证。我排错的时候脑子里始终挂着这样一个表，你也可以抄下来用：
| 阶段 | 检查对象 | 涉及设备 | 验证手段 |
|---|---|---|---|
| 物理链路 | 接口是否up/up | 所有设备 | show ip interface brief |
| 二层转发 | MAC地址表学习、VLAN归属 | 交换机、路由器接口 | show mac address-table、show vlan brief |
| 地址解析 | 下一跳ARP是否解析成功 | PC、路由器 | show arp、arp -a |
| 三层路由 | 去程和回程路由是否完整 | 路由器 | show ip route、trace |
| 转发策略 | ACL是否放行、NAT方向是否正确 | 路由器 | show access-lists、show ip nat translations |
这个表的好处在于，它把“ping不通”这个抽象的结果，拆成了一个个具体的、可验证的问题。接下来排错就像剥洋葱：从最外层开始，剥到哪一层发现问题，就停在哪一层处理。
2. 分层的排查思路：别一上来就拼命Ping
原理拆完，就该说方法论了。我见过最典型的错误习惯是：ping不通，先把所有路由配置从头看到尾，看不出问题，然后又分别ping网关、ping对端接口，还是不通，最后没辙了，把所有配置删了重写。这不行，排错要讲顺序。
2.1 自下而上：每层验证只依赖下一层
我推荐的做法是自下而上，从物理层开始逐层往上验证。为什么不自上而下？因为上层所有功能的正常运行，都依赖下层是好的。你要是在路由表已经没问题、但接口物理层down的情况下，去纠结路由条目的下一跳写得对不对，那是白费力气。
具体顺序是这样的：
- 物理层：接口状态是不是up/up。端口是不是被shutdown了，线缆是不是接错口了。
- 数据链路层：交换机端口划分在哪个VLAN，两台PC的MAC地址有没有被交换机学到，ARP表里能不能解析到下一跳的MAC。
- 网络层：路由表里有没有目标网段的路由，去程和回程各查一遍。网关地址和掩码有没有配错。
- 传输和策略层：接口上是否挂了ACL，ACL方向对不对，NAT转换表是否在正常工作。
每一层验证完，如果正常，就放心去查上一层；如果不正常，就地解决，不需要再往上看了。这套方法看起来很笨，但它是所有花哨技巧的地基。
2.2 双向Ping法：最容易被忽略的第一步
进入具体命令之前，先教你一个所有老工程师都在用、但新手经常忽略的小动作：双向ping。
具体操作就是，PC1 ping PC2不通的时候，别急着查配置，先到PC2上去反向ping一下PC1。然后把结果分成四种情况来看：
| 现象 | 大概率问题方向 |
|---|---|
| PC1 ping PC2通，PC2 ping PC1通 | 基础通信正常，问题在具体业务层面 |
| PC1 ping PC2不通，PC2 ping PC1通 | 问题出在PC1到PC2这个方向上的路径或策略 |
| PC1 ping PC2通，PC2 ping PC1不通 | 问题出在PC2到PC1这个方向上 |
| 双向都不通 | 问题可能出在两端之间的公共环节，比如中间路由缺了整段回程，或者网关配置错误 |
这里要小心一件事：单纯地反向ping一下还不够，你最好换一台设备再确认一次。比如PC1 ping PC2不通，你再看R1 ping PC2是否通，R2 ping PC1是否通。把两端、两方向、多组源的数据都拿到，排错的范围就能缩得很小。
我实测下来，这个方法至少能把80%的“路由缺失”或“策略方向配反”类问题定位到“某一跳路由器上”，剩下再慢慢查具体配置，效率高很多。
2.3 动手前先画数据流路径图
查命令之前，强烈建议你先在一张纸上把“应该走通的路径”画出来。不需要多专业，能把每跳的接口和IP标清楚就行。
举个例子，LAB2里典型的预期路径可以写成这样：
- PC1（192.168.1.10/24），网关192.168.1.1
- R1：Gi0/0 = 192.168.1.1，Gi0/1 = 10.0.0.1/30
- R2：Gi0/0 = 10.0.0.2/30，Gi0/1 = 192.168.2.1/24
- PC2（192.168.2.10/24），网关192.168.2.1
去程预期：PC1 → R1（网关） → R1查路由 → 下一跳10.0.0.2 → R2 → PC2。 回程预期：PC2 → R2（网关） → R2查路由 → 下一跳10.0.0.1 → R1 → PC1。
把这张图贴在屏幕上，每敲一条show命令，就问自己一个问题：这个输出结果跟图中期望的下一步对得上吗？对得上就往下走，对不上就停。这样排错就从“碰运气式翻配置”，变成了“逐段验证式排查”。
3. Cisco环境下的关键命令与输出判读
方法有了，接下来是看家本领：命令。我见过不少人能背出show ip route，但是不知道看到什么输出代表什么。这里我把排错链路里最实用的命令逐个过一遍，重点放在输出怎么解读。
3.1 show ip interface brief：接口状态是第一道关口
排错第一步永远是看接口，在Cisco设备上就是show ip interface brief。
R1#show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 192.168.1.1 YES manual up up GigabitEthernet0/1 10.0.0.1 YES manual up up很多人只盯着IP地址看，忽略了最后两列。Status和Protocol每一列都不是多余的：
- Status是“线路状态”，表明这个接口有没有被物理激活。
- Protocol是“协议状态”，表明链路层协议能不能正常协商。
四个常见组合我列个表，以便对照：
| Status | Protocol | 含义 | 常见原因 |
|---|---|---|---|
| up | up | 正常，往下查 | 无 |
| administratively down | down | 接口被人为关闭 | no shutdown没敲 |
| up | down | 线路通了但协议起不来 | 时钟、封装、双工不匹配 |
| down | down | 物理链路有问题 | 线缆没接、对端设备关机 |
特别想说一下Serial接口。实验里如果用串口连接两台路由器，经常出现down/down，这时候第一时间检查一侧是否配置了clock rate，因为串行链路里必须有一侧是DCE侧提供时钟。这是LAB2实验里高频出现的低级坑，直接用show controllers serial 0/0/0就可以看哪侧是DCE。
3.2 show vlan brief 与 show mac address-table：二层细节决定上层命运
接口没问题不代表二层就通了，特别是有交换机参与的拓扑。交换机的默认行为是每个端口都在VLAN 1，如果你的实验里规划了VLAN 10和VLAN 20，结果PC1的接口忘了加入VLAN 10，那PC1发出的ARP请求交换机根本不会转发到路由器那边去。
用show vlan brief看交换机端口归属：
SW1#show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default ACTIVE Gi0/1 10 PC_VLAN ACTIVE Gi0/2, Gi0/3 20 Server_VLAN ACTIVE Gi0/4如果你发现PC1所在的端口Gi0/2确实在VLAN 10里，路由器的端口也在VLAN 10里，那二层通信的基座就算确认了。
接下来用show mac address-table看MAC学习情况。这个表很有意思，它告诉你交换机“目前学到了哪些MAC地址、从哪个端口学到的”。比如你show完发现PC1的MAC和R1网关接口的MAC都出现在VLAN 10下面，说明交换机确实收到了来自这两个方向的帧。如果只看到PC1的MAC，看不到R1的MAC，说明帧根本没到交换机，要么接口配置不对，要么线缆有问题。
我实测的一个案例：两台PC在同一个交换机上，一个在VLAN 10一个在VLAN 20，PC1能ping通网关但ping不通PC2。show mac address-table之后发现PC2的MAC一直在VLAN 20里学习，而不是VLAN 10，最后查出来是PC2的端口被误配成了access vlan 20。配置改回来后秒通。这种问题不查MAC表，光看配置是很难发现的。
3.3 show arp 与 show ip route：地址解析和路由表必须一起看
到了网络层，我把show arp和show ip route两个命令放在一起说，因为它们的验证逻辑是承接的：先看路往哪走，再看下一跳地址能不能被解析成MAC。
在Cisco设备上敲show ip route，先看有没有目标网段的路由条目：
R1#show ip route Codes: C - connected, S - static, R - RIP, O - OSPF, ... 10.0.0.0/30 is subnetted, 1 subnets C 10.0.0.0/30 is directly connected, GigabitEthernet0/1 S 192.168.2.0/24 [1/0] via 10.0.0.2这里的S条目说明R1有一条去192.168.2.0/24的路由，下一跳是10.0.0.2，而这个10.0.0.0/30网段又是R1的直连网段，所以下一跳是可达的。如果路由表里压根找不到192.168.2.0/24，那PC1发来的包要么被R1丢弃，要么只能靠默认路由，如果也没有默认路由就直接掉包。
有了路，还得看下一跳能不能解析到MAC。用show arp：
R1#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.0.0.2 1 aabb.cc00.1111 ARPA GigabitEthernet0/1 Internet 192.168.1.1 0 aabb.cc00.2222 ARPA GigabitEthernet0/0如果10.0.0.2的ARP条目不存在，那说明R1发出ARP请求之后没有得到响应，这通常是二层链路问题——比如中间交换机端口配置错误，或者对端R2的接口down了。ARP能解析出来，路由表也有，链路层物理层都正常，那就可以往上走，查策略了。
3.4 扩展Ping与扩展Tracert：换个源地址来看路径
这里分享一个我排LAB2类拓扑时最常用的杀手锏，普通的学习者很少主动用，但效果极好。Cisco设备上的普通ping和扩展ping有一点本质区别：普通ping用的源IP是路由表选出接口的主IP地址，而扩展ping可以让你手动指定源IP。
操作方式很简单，在特权模式下直接敲ping，然后回车，会进入交互式设置：
R1#ping Protocol [ip]: Target IP address: 192.168.2.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.1.1 ...注意最后一行，Source address我填的是192.168.1.1，也就是R1 Gi0/0接口的IP。这意味着这段ICMP报文以192.168.1.0/24网段为源地址往外发，去程路径跟PC1发ping的时候几乎一致，但回程就不一样了——回包要回到192.168.1.1这个地址，中间路由器必须会查表去往192.168.1.0/24。
我说一个我实际碰到的场景。PC1 ping PC2不通。敲普通ping，R1 ping 192.168.2.10是通的；但用扩展ping，R1 ping 192.168.2.10 source 192.168.1.1就变成超时。这就把问题精确锁定到了“回程路由缺失”上：因为普通ping的源IP是10.0.0.1，R2有直连路由知道怎么回10.0.0.0/30，所以通了；但用192.168.1.1做源地址，R2根本没有去192.168.1.0/24的路由，回包直接被丢弃，所以超时。
这种“我换了源头以后通不通”的实验方法，比单纯翻配置快得多。同理，traceroute也可以用扩展模式指定源IP，用来观察报文走到哪一跳被丢弃。这个技巧建议每个做实验的人都在自己的工具清单里存一份。
3.5 需要谨慎的Debug：debug ip icmp 与 debug ip packet
当所有show命令都看不出问题时，才轮到debug上场。Cisco的debug命令是实时的，会一直往终端刷信息，所以务必小心。
优先推荐debug ip icmp，它只打印ICMP报文相关的事件，输出量相对可控：
R1#debug ip icmp ICMP packet debugging is on然后让PC1再ping一次，如果R1能看到“ICMP echo reply sent”或者“dst 192.168.2.10 unreachable”这类输出，就能判断R1这个节点对ICMP报文做了什么处理。如果在R1上看不到任何ICMP的进和出，那问题就不在R1，继续去下一跳找。
debug ip packet输出量非常大，因为在Cisco设备上“packet”泛指所有IP数据包。建议务必配合ACL使用，只debug你关心的一小段流量：
R1(config)#access-list 100 permit icmp host 192.168.1.10 host 192.168.2.10 R1#debug ip packet 100这样路由器的CPU只对192.168.1.10到192.168.2.10的ICMP流量打印信息，不至于刷屏。我当年在模拟器上没加过滤条件直接debug ip packet，刷了几屏之后终端几乎卡死，后来只能重启模拟器，这是真实教训。用完记得undebug all，别留着debug在后台耗CPU。
4. 实战排错中我遇到最多的坑
这一节不按教科书来，只讲我在LAB2的实验和答疑过程中真正撞见过、也帮别人处理过的高频坑。每个都是“现象描述-根因分析-修复过程”的完整链路。
4.1 只配了去程路由，忘了回程路由
这是全网最经典的Cisco实验坑，没有之一。拓扑就是上面那两台路由器的结构。R1上写了去192.168.2.0/24的静态路由，R2上却忘了写回192.168.1.0/24的静态路由。现象是PC1 ping PC2一直超时。
此时你去R1上直接ping PC2，会发现它能通。这就是最容易让人迷惑的地方：R1自己发出的ping，源IP是Gi0/1的10.0.0.1，R2上有直连10.0.0.0/30的路由，回包能顺利回来，所以通。但PC1发出的ping，源IP是192.168.1.10，到了R2之后，R2查路由表发现根本没有192.168.1.0/24这个网段，直接丢弃，PC1自然收不到回包。
修复很简单，在R2补上路由：
R2(config)#ip route 192.168.1.0 255.255.255.0 10.0.0.1排查的关键是：当PC1 ping不通PC2时，你用扩展ping验证一下从R1的192.168.1.1地址到PC2通不通。一旦发现只有换了源IP才不通，那就基本可以断定问题出在回程方向的某个网段上，然后逐台设备检查回程路由就够了。
4.2 NAT的inside/outside标反
LAB2如果加了一个NAT需求，让内网PC通过R1的出口访问外部服务器，那么最常见的坑就是接口的inside/outside方向标反。
现象往往是这样的：内网PC ping不通外部服务器，但R1自己ping外部服务器是通的。理由前面已经点过一次：设备自己发起的流量走的是本地出接口逻辑，不经过“由inside接口进入、outside接口出去”的NAT转换过程，所以设备间的连通不代表业务流量的连通。
这时候别急着改路由，先看NAT的转换情况：
R1#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 200.1.1.1:12 192.168.1.10:12 210.1.1.10:12 210.1.1.10:12如果转换表里一条条目都没有，或者只有静态配置的条目而没有动态转换产生的条目，就要重点检查ip nat inside命令是不是标在了正确的接口上。NAT的接口方向标反、或者漏标inside，都会导致内网流量进路由器的时候没被识别为“需要做转换的流量”，结果内网地址原封不动地被转发出去，回包当然回不来。
改法就是重新检查接口配置：
R1(config)#interface GigabitEthernet0/0 R1(config-if)#ip nat inside R1(config)#interface GigabitEthernet0/1 R1(config-if)#ip nat outside改完再show ip nat translations，能看到动态转换条目在产生和老化，业务也通了。
4.3 ACL方向配反与隐式拒绝
ACL是另一个高频坑，而且它最大的迷惑性在于：链路、路由、ARP全部正常，但就是ping不通。我遇到过学生配置了访问控制列表，想要“只允许某个网段访问服务器”，结果把规则挂在了入方向，实际应该挂在出方向，导致所有ICMP包在接口处被隐式deny。
怎么判断是ACL的问题？先看接口上挂了什么：
R1#show ip interface GigabitEthernet0/1 GigabitEthernet0/1 is up, line protocol is up Internet address is 10.0.0.1/30 Inbound access list is 100 Outbound access list is not set这里Inbound方向挂着acl 100，然后再看这个ACL的具体规则和命中计数：
R1#show access-lists 100 Extended IP access list 100 10 permit icmp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 (4 matches) 20 deny ip any any (10 matches)注意看matches计数。如果permit规则后面的计数在增长，说明流量确实命中了这条放行规则，那问题可能不在ACL；如果permit规则的计数是0，而deny any any的计数在增长，那基本可以断定，流量被这条隐式deny或者显式deny拦截了。
Cisco的ACL默认在末尾有一条隐式的deny any any，很多人规划的时候只写了deny规则，忘了要把需要放行的ICMP流量explicitly放行。修法就是在ACL里加一条permit：
R1(config)#ip access-list extended 100 R1(config-ext-nacl)#10 permit icmp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255加完了再看show access-lists的匹配计数，icmp放行计数开始增长，就说明ACL不再挡路了。这里还有一个经验：ACL计数是排错神器，它会直接告诉你流量到底有没有走到这个策略点。计数不涨，更多是流量没有到达接口；计数涨却不通，那才是策略本身拦了。
4.4 交换机VLAN/Trunk链路配置
LAB2的另一种拓扑是两台交换机级联，PC1和网关在一台交换机上，PC2在另一台交换机上。现象是PC1能ping通网关，但ping不通PC2。
先别怀疑路由，因为PC1能通网关，说明它的三层转发路径是好的，问题大概率出在二层链路。我当时的排查步骤是这样的：
第一，在两台交换机上看VLAN：
SW1#show vlan brief确认PC1和网关的接口都在同一个VLAN，比如VLAN 10；SW2上PC2的接口也在VLAN 10。如果PC2的接口不在VLAN 10，交换机根本不会把VLAN 10的帧从这里发出去。
第二，看两台交换机之间的级联口，是不是Trunk，并且Trunk允许了VLAN 10：
SW1#show interfaces trunk Port Mode Encapsulation Status Native vlan Gi0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Gi0/1 1-4094如果级联口还是access模式，或者trunk里allowed vlan没有10，那VLAN 10的帧过不了这条链路。加入VLAN：
SW1(config)#interface GigabitEthernet0/1 SW1(config-if)#switchport mode trunk SW1(config-if)#switchport trunk allowed vlan 10第三，用show mac address-table验证学习情况。在SW1上如果能同时看到PC1的MAC和PC2的MAC（从级联口方向学来的），说明二层链路已经通了，那问题方向就要重新评估。如果只看到PC1的MAC，看不到PC2的MAC，那基本就是链路或者VLAN的问题，继续往Trunk和VLAN配置上找。
还有一个小坑是native VLAN不匹配。两端Trunk的native vlan一个设成1一个设成99，不打标签的帧会在对端被划进另一个VLAN，于是交换机之间“看起来通了”，但具体VLAN的报文全被错误归类。排查方法是show interfaces trunk两端对比Native vlan列，不一致就改回来。这个坑非常隐蔽，因为接口和链路的状态都是up的。
4.5 ARP缓存残留引起的“假故障”
最后说一个特别容易让人抓狂的问题，它甚至不属于配置错误，但实际排障中会频繁碰到：ARP缓存残留。
有次实验课，几乎连续三组同学遇到同一个诡异现象：改了PC的IP地址之后，怎么ping网关都不通。我把设备配置翻了个底朝天，路由、VLAN、接口全正常。后来想到，是不是之前这台PC的网卡MAC地址已经被换过IP了，但交换机和路由器上还留着旧的ARP映射。于是我在路由器上执行了：
R1#clear arp-cache把ARP缓存清掉之后，PC再ping网关，秒通。原理很简单：路由器或者交换机缓存里的“IP对应MAC”关系是旧的，数据帧仍然被发往旧MAC，而旧MAC对应的设备可能已经不在那个端口上了，或者已经下线了。PC端也可能出现同样问题，Windows上可以先arp -d再ping，或者直接重启网卡。
这个案例告诉我们，排错的时候不要理所应当地认为“表项都是最新的”。ARP表会老化，但如果设备刚改过IP、刚换过网卡，表项更新可能滞后。遇到“配置看半天都正常，就是不通”的僵局，不管是设备还是PC，把ARP缓存清一遍，成本最低，收益最高。
包括PC端也是一样的：ipconfig /flushdns是清DNS，真正清ARP缓存用的是arp -d。很多人分不清这两个命令，结果清了半天DNS，问题依然在ARP。这也是我对新手多说一句的原因。
排错做多了之后，我的体会是：ping不通永远不是“玄学”，它只是通信链条上某个环节断了，而这个链条上的每个节点都留下了可以被查询的证据。先画数据流路径，再按接口、ARP、路由、ACL、NAT的顺序逐层验证，配合扩展ping去模拟不同的源地址，最后用debug和你确认最后的怀疑点，基本上很少有查不出来的问题。LAB2式的拓扑是练这个思路最合适的地方——设备少，链路短，坑却一个不少，踩过一轮之后，你会慢慢形成自己的排错肌肉记忆。
