【网络Ping不通如何解决？】

Ping不通故障是现网中经常遇到的问题，那如何定位Ping不通故障呢，莫急，小微先给各位大侠介绍几个Ping不通的典型案例，拿走不谢哦。案例一：ICMP报文携带Checksum错误导致Ping不通现象描述交换机做网关，下挂门禁、PC等终端，从交换机上Ping某一台终端不通。原因分析交换机对端回应的ICMP Reply报文携带的Checksum错误，协议检查不过，导致Ping不通现象。处理步骤方法一

GLAB-Mary

7729人浏览 · 2022-04-06 11:54:14

GLAB-Mary · 2022-04-06 11:54:14 发布

Ping不通故障是现网中经常遇到的问题，那如何定位Ping不通故障呢，莫急，小微先给各位大侠介绍几个Ping不通的典型案例，拿走不谢哦。

案例一：
ICMP报文携带Checksum错误导致Ping不通

现象描述

交换机做网关，下挂门禁、PC等终端，从交换机上Ping某一台终端不通。

原因分析

交换机对端回应的ICMP Reply报文携带的Checksum错误，协议检查不过，导致Ping不通现象。

处理步骤

方法一：

在设备ARP学习正常情况下，通过流量统计判断ICMP Request报文是否正常发出以及ICMP Reply报文是否正常回应到达交换机，也可以通过获取报文来判断：

在这里插入图片描述

从获取报文结果的分析软件也能够看出，ICMP Reply报文的Checksum值有误。

方法二：

在交换机上执行Ping操作的前后通过执行 display icmp statistics 命令查看"bad checksum"观察ICMP协议层面的Checksum错误包计数是否一直增长。

display icmp statistics
Input: bad formats 0 bad checksum 3
echo 8 destination unreachable 0

source quench 0 redirects 0

echo reply 0 parameter problem 0
timestamp request 0 information request 0
mask requests 0 mask replies 0
time exceeded 0 timestamp reply 0

Mping request 0 Mping reply 0
Output:echo 0 destination unreachable 0
source quench 0 redirects 0
echo reply 8 parameter problem 0
timestamp request 0 information reply 0
mask requests 0 mask replies 0
time exceeded 0 timestamp reply 0

Mping request 0 Mping reply 0
从上述回显可以看出，Checksum错误包计数一直增长。

解决方案：

需要检查对端设备的协议栈软件回应ICMP报文的格式是否正确。

案例二：
错误的静态ARP表项导致直连设备两端不能Ping通
现象描述

用户用SwitchA替换现网中设备，替换完成后组网如图1-2所示。替换完成后发现SwitchA和SwitchB无法正常Ping通。同时在SwitchA查看OSPF状态为 Exchange ，但是还原到替换之前的组网时一切恢复正常。图1-1 错误的静态ARP表项导致直连设备两端不能Ping通的组网图

在这里插入图片描述

原因分析

1、因为恢复之前的组网后一切正常，所以SwitchA和SwitchB之间的链路没有问题，SwitchA和SwitchB之间是直连，因此不存在路由问题。SwitchA和SwitchB不能正常Ping通有可能是ARP的学习问题。

2、在SwitchA上执行 display arp all 命令，检查SwitchA是否学习到了SwitchB的ARP表项。
display arp all
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE

                                  VLAN/CEVLAN

1.1.1.1 0025-9e80-2494 I - Vlanif20
1.1.1.2 0025-9e80-248e 18 D-0 GE1/0/1

Total:2 Dynamic:1 Static:0 Interface:1
发现ARP表项已经正常建立。

3、在SwitchB上执行 display arp all 命令，检查SwitchB是否正常学习到了SwitchA的ARP表项。
display arp all
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE

                                   VLAN/CEVLAN

1.1.1.2 0025-9e80-248e I - Vlanif20
1.1.1.1 0016-ecb9-0eb2 S-- GE1/0/1
33
--------------------------------------------------------------------------Total:2 Dynamic:0 Static:1 Interface:1
输出信息显示IP地址 1.1.1.1 对应的MAC地址为 0016-ecb9-0eb2 ，表项类型“S”表示该ARP表项为静态ARP。此时对比SwitchA上的ARP表项发现，在SwitchB上1.1.1.1对应的MAC地址并非SwitchA上 1.1.1.1 地址对应的MAC地址。
因此，问题可能是SwitchB在网络调整前配置了IP+MAC+端口号的静态绑定，网络调整后因为对端的MAC变更，而SwitchB上并未同步刷新IP+MAC+端口号的静态ARP，从而导致SwitchA和SwitchB无法正常Ping通。

处理步骤：
1、在SwitchB执行命令 system-view ，进入系统视图。

2、执行命令 undo arp static ip-address ，删除当前错误的静态用户绑定表项。

说明

此时删除前错误的静态ARP表项后SwitchA和SwitchB可以正常Ping通。这里通过配置静态用户绑定表项，能有效地防范网络中通过修改源地址而进行的恶意攻击行为的发生。
3、执行命令 arp static ip-address

mac-address vid vlan-id interface interface-type interface-number，按照对端新加入的设备MAC地址配置正确的静态用户绑定表项。
完成上述步骤后SwitchA和SwitchB可以正常Ping通。同时使用 display ospf peer 查看OSPF的邻居状态为“FULL”。
display ospf peer
OSPF Process 1 with Router ID 11.11.11.105
Neighbors

Area 0.0.0.0 interface 1.1.1.1(Vlanif33)'s neighbors
Router ID: 2.1.1.1.168.10.2 Address: 1.1.1.2
State: Full Mode:Nbr is Master Priority: 1
DR: 1.1.1.2 BDR: 2.1.1.1 MTU: 0
Dead timer due in 34 sec
Retrans timer interval: 8
Neighbor is up for 00:28:17
Authentication Sequence: [ 0 ]

案例总结：

如果某设备上配置了IP和MAC地址的静态绑定，一旦该MAC地址对应设备被替换，则需要同步刷新静态绑定表项。此案例中如果SwitchB的对端设备为其他厂商设备，在出现故障时无法正常登录设备查看对端设备配置，此时可以在SwitchA上Ping SwitchB，同时通过镜像获取SwitchA和SwitchB之间的报文，然后对报文进行分析，从而判断报文中的目的MAC是否正确。

案例三：
能Ping通但是不能远程登录交换机
现象描述

如图1-3所示，在SwitchC上可以Ping通SwitchA的VLANIF20的地址，但是在SwitchC上不能telnet登录到SwitchA。图1-2 能Ping通但是不能远程登录交换机组网图

在这里插入图片描述

原因分析

1、因为Switch支持Ping快回功能，它可以对收到的目的地址是自己的ICMP Echo报**快速应答。
在SwitchC上可以Ping通SwitchA但不能远程登录，有可能是SwitchA上开启Ping快回功能导致。如果SwitchA上开启Ping快回功能即使SwitchA上未配置到目的地址是2.1.1.1的路由，SwitchA也能快速应答ICMP Request报文，此时SwitchC能Ping通SwitchA证明SwitchC和SwitchA之间的链路没有问题，但不能排除路由没有问题，因此要先判断SwitchC到SwitchA之间网络是否可达。2、在SwitchC上执行 tracert 1.1.1.1 检查SwitchC到SwitchA之间网络是否可达。
tracert 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1), max hops: 30 ,packet length: 40
1 2.1.1.2 10 ms 1 ms 1 ms
2 * * *

输出信息显示SwitchC到SwitchB之间网络层是可达的，SwitchC到SwitchA之间网络不可达。怀疑是SwitchA上未配置或配置错误的到目地址是2.1.1.1的路由。
3、在SwitchC上执行 telnet 2.1.1.2 命令先登录到SwitchB，然后再在SwitchB上执行 telnet 1.1.1.1 命令登录到SwitchA，此时证明SwitchA的Telnet相关配置没有问题。
4、在SwitchA上执行 display ip routing-table 2.1.1.1 命令，显示到目的地址为2.1.1.1最长匹配的路由表项发现为空。此时在SwitchA上执行 undo icmp-reply fast 命令关闭Ping快回功能。然后在SwitchC上PingSwitchA发现不能Ping通。

以上分析可以得出在SwitchC上能Ping通SwitchA是因为SwitchA上开启了Ping快回功能。从SwitchC上不能远程登录到SwitchA是因为SwitchA上没有配置到目的地址是2.1.1.1的路由。

处理步骤：

1、在SwitchC上执行命令 system-view ，进入系统视图。
2、执行命令 ip route-static 2.1.1.0 255.255.255.0 1.1.1.2 ，配置到目的网段为1.1.1.2的静态路由。完成上述步骤后从SwitchC上可以远程登录到SwitchA。

案例四：
交换机受到ARP报文攻击导致Ping不通
现象描述

如图1-4所示，Switch为网关，Switch_1（框式交换机）经常脱管，且Switch_1下用户存在上网掉线，Ping网关存在时延、不通等现象，而Switch_2下联业务正常，Ping网关正常。图1-3 交换机受到ARP报文攻击导致Ping不通组网图

在这里插入图片描述

原因分析

Switch_1上存在源MAC固定的ARP攻击导致用户无法进行正常ARP交互。

处理步骤

在Switch_1上执行以下操作：
1、查看设备CPU占用率，判断CPU占用率较高。

<Switch_1> display cpu-usage

CPU Usage Stat. Cycle: 10 (Second)

CPU Usage : 82% Max: 99%

CPU Usage Stat. Time : 2010-12-18 15:35:56

CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.

发现CPU占用率达到82%。

2、查看存在临时ARP表项，初步判断设备的ARP表项学习存在问题。

<Switch_1> display arp

IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE VPN-INSTANCE INTERFACEVLAN/CEVLAN

10.137.222.139 00e0-fc01-4422 I -Eth0/0/0
10.137.222.1 0025-9e36-e8c1 20 D-0 Eth0/0/0
10.137.222.100 0025-9e80-b278 6 D-0 Eth0/0/0
10.137.222.99 00e0-4c77-b0e1 9 D-0 Eth0/0/0
10.137.222.173 000f-3d80-cba4 18 D-0 Eth0/0/0
10.137.222.34 0025-9e36-e8c1 1 D-0 Eth0/0/010.137.222.172 0016-ec71-ea8c 7 D-0 Eth0/0/010.137.222.35 0025-9e36-e8c1 18 D-0 Eth0/0/010.137.222.179 0014-2ae2-3128 20 D-0 Eth0/0/010.137.222.38 0025-9e36-e8c1 17 D-0 Eth0/0/010.137.222.175 0014-2261-2b22 1 D-0 Eth0/0/050.1.1.3 Incomplete 1 D-0 GE5/0/0500/-50.1.1.2 Incomplete 1 D-0 GE5/0/0500/-6.1.1.2 00e0-fc01-4422 I - Vlanif610.0.0.139 00e0-fc01-4422 I - Vlanif10

192.0.0.4 00e0-fc01-4422 I - Vlanif192
20.1.1.1 00e0-fc01-4422 I - Vlanif200
192.168.2.2 00e0-fc01-4422 I - Vlanif100
Total:16 Dynamic:10 Static:0 Interface:6

发现有两条ARP表项的“MAC ADDRESS”字段为“Incomplete”即为临时表项，表示有ARP表项学习不到。

3、判断设备正遭受ARP攻击。
a、由于有未学习到的ARP表项，查看上送CPU的ARP-Request报文统计信息。
<Switch_1> display cpu-defend arp-request statistics all

Statistics on mainboard:

Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)

arp-request 67908288 0 1061067 0

Statistics on slot 4:

Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)

arp-request 80928 44380928 2301 693450

Statistics on slot 5:

Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)

arp-request N/A N/A 0 0

Statistics on slot 6:

Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)

arp-request N/A N/A 0 0

发现交换机的4号单板上存在大量ARP-Request报文丢包。

b、配置攻击溯源识别攻击源。
<Switch_1> system-view
[Switch_1] cpu-defend policy policy1
[Switch_1-cpu-defend-policy-policy1] auto-defend enable
[Switch_1-cpu-defend-policy-policy1]auto-defend attack-packet sample 5 //每5个报文抽样识别一次，抽样值过小会消耗过多CPU
[Switch_1-cpu-defend-policy-policy1] auto-defend threshold 30 //报文达30pps即被识别为攻击，若攻击源较多可调低该值
[Switch_1-cpu-defend-policy-policy1] undo auto-defend trace-type source-ip source-portvlan //基于源MAC进行攻击源识别
[Switch_1-cpu-defend-policy-policy1] undo auto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp //针对ARP攻击进行识别

[Switch_1-cpu-defend-policy-policy1] quit
[Switch_1] cpu-defend-policy policy1
[Switch_1] cpu-defend-policy policy1 global
c、查看攻击源信息。
[Switch_1] display auto-defend attack-source

Attack Source User Table (MPU):

MacAddress InterfaceName Vlan:Outer/Inner TOTAL

0000-0000-00db GigabitEthernet2/0/22 193 416

发现攻击源的MAC地址为0000-0000-00db，位于GigabitEthernet2/0/22端口。如果该MAC有对应ARP，还可以执行命令 display arp | include 0000-0000-00db 查询对应的IP。

解决方案

l 配置黑名单。

acl number 4000
rule 10 permit type 0806 ffff source-mac 0000-0000-00db ffff-ffff-ffff

cpu-defend policy 1

blacklist 1 acl 4000 //针对来自特定用户恶意报文的攻击，设备通过ACL把符合特定特征的用户纳入到黑名单中，被纳入黑名单的用户所发的报文到达设备后均会被丢弃

cpu-defend-policy 1
cpu-defend-policy 1 global

l 配置攻击溯源的惩罚功能。

cpu-defend policy policy1
auto-defend enable
auto-defend threshold 30
undo auto-defend trace-type source-ip source-portvlan
undo auto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp
auto-defend action deny //使能攻击溯源的惩罚功能，并指定惩罚措施。在默认惩罚时间300s内，将识别为攻击的报文全部丢弃

cpu-defend-policy policy1 global cpu-defend-policy policy1

案例五：
PE私网之间无法Ping通
现象描述

两台PE上分别建立两个Loopback接口。Loopback1接口为公网接口，IP地址分别为1.1.1.1/32和1.1.1.2/32。Loopback2接口绑定VPN实例test，且IP地址分别为10.1.1.1/24和10.1.1.2/24，两台PE之间无法交换VPN私网路由，相互之间Ping不通。
图1-4 PE私网之间无法Ping通的组网图

在这里插入图片描述

原因分析：

当设备上存在两条相同的路由，一条为直连路由，一条为BGP路由。此时设备会优选直连路由创建到自身路由表，所以私网路由表中没有BGP私网路由导致无法Ping通。

处理步骤
1、在PE1和PE2上执行 display ip routing-table 命令，检查是否有去往对端网段的路由。可以看到路由表中有去往对端Loopback1接口网段的路由。2、在PE1和PE2上执行 display ip routing-table vpn-instance vpn-instance-name命令查看私网路由表中的路由。发现只有一条路由：10.1.1.0/24 Direct，是路由设备自身Loopback2接口路由。同时发现掩码是24位，而不是32位。
这样的话两台PE的Loopback2接口地址便在同一网段内了。其实设备已经收到了私网路由，但是与其自身Loopback2接口地址在同一网段，相当有两条相同的路由，一条为直连路由，一条为BGP路由。此时设备会优选直连路由创建到自身路由表，所以私网路由表中没有BGP私网路由，导致PE间无法Ping通。

解决方案

在PE1和PE2上分别执行下列步骤，

1、执行命令 system-view ，进入系统视图。

2、执行命令 interface loopback loopback-number，进入Loopback2接口视图。

3、执行命令 ip address ip-address { mask | mask-length }，配置接口的IP地址，将Loopback接口IP地址的掩码改为32位。

经验及总结

如果到同一个网段有两条相同的路由，设备只会选择其中之一更新到路由表。

案例六：
交换机与C厂商C3750对接出现Ping不通

现象描述

S9300设备与C厂商C3750直连，通过VLAN200建立OSPF邻居，分别发布各自设备上VLAN100以及VLAN300的网段路由到对端。在网络中，Monitor Server 172.19.2.2通过Ping操作监控下游的Server 172.19.3.2是否在线。

图1-5 交换机与C厂商C3750对接出现Ping不通组网图

在这里插入图片描述

问题发生时，每隔18个小时，大约发生一次Ping不通的现象，半小时后自动恢复，影响了客户的视频监控业务。

原因分析

C厂商设备上路由非正常老化，使到Monitor server的网段路由172.19.2.0消失，造成Ping不通。

处理步骤

1、通过流量统计发现监控服务器发出的ICMP请求通过S9300正常转发，但未收到ICMP Reply回应报文，初步判断问题出现在C厂商设备上。

2、在C厂商设备上观察路由信息，发现问题发生时，到监控服务器的网段路由消失，导致回程的ICMP Reply报文在C厂商设备上丢弃。

对比一下故障发生时，C厂商和S9300设备上LSDB的所有信息，发现C厂商设备比S9300设备少如下两个Network LSA。

Type LinkState ID AdvRouter Age Len Sequence Metric

Network 172.19.5.1 172.19.1.250 1256 32 80000208 0

Network 172.19.5.1 172.19.99.10 3600 32 800026C9 0

172.19.99.10产生的这个LSA是S9300后收到的，向所有邻居洪泛，C厂商收到之后的处理是将原先172.19.1.250发布的LSA删除，造成路由计算时路由丢失。30分钟之后，172.19.1.250，也就是S9300设备做LSA刷新，会把自己的Network LSA再发给C厂商C3750设备，C厂商C3750设备上路由就自然恢复了。

请注意：

− OSPF协议中，LSA由三要素唯一标识，Type、LinkStateID，AdvRouter，也就是说，这两个LSA在S9300上认为是不同的LSA。怀疑C厂商设备将两个LSA认为是同一个LSA，因此使用172.19.99.10发布的这个将原LSDB中的覆盖，另外由于该LSA的Age是3600，因此将其老化删除，造成路由丢失。

− 172.19.99.10产生的这个LSA有DC标识。

Type : Network

Ls id : 172.19.5.1

Adv rtr : 172.19.99.10

Ls age : 3600

Len : 32

Options : DC E

seq# : 800026c9

chksum : 0xd55

Net mask : 255.255.255.0

Attached Router 172.19.99.10

Attached Router 172.19.8.1