相關命令：
	display arp
	display arp interface vlanifvlanif-id

相關命令：
display mac-addressmac-address
display mac-addressmac-addressvlanvlan-id

	 ping -c 100000 ip-address 也可視情況添加-t/-m等參數將Ping的速率適當調整。

們好，我的網工朋友。

Ping是我們網絡工程師排除設備訪問故障的常見方法，它使用Internet控制消息協議ICMP確定以下內容：

遠程設備是否處于可訪問狀態。

訪問遠程設備時是否丟失報文。

本端與遠程設備之間通信的往返延遲。

但是也常常聽網工朋友在群里抱怨:咋又不通呢?

所以今天有空就總結了一下網絡Ping不通的一些常見故障和處理方法，希望能幫到你。

今日文章閱讀福利：《 H3C經典Ping命令詳解 》

連ping都沒用好，更別說用別的命令了，你說是吧？

還不熟的朋友，看看這份命令詳解，深入學習。私信我，發送暗號“ping”，領取這份詳解資料。

01 Ping命令格式

Ping命令的參數非常的豐富，用戶可以依據檢測目的、網絡類型、當前網絡狀況等因素選擇不同的參數。

ping [ ip ] [ -a source-ip-address | -c count | -d | { -f | ignore-mtu } | -h ttl-value | -nexthop nexthop-ip-address | -i interface-type interface-number | -m time | -n | -name | -p pattern | -q | -r | { -s packetsize | -range [ min min-size | max max-size | step step-size ] * } | -system-time | -t timeout | -tos tos-value | -v | -vpn-instance vpn-instance-name ] * host [ ip-forwarding ]

02 Ping不通介紹

01故障分析

Ping不通是指Ping報文在網絡中傳輸，由于各種原因（如鏈路故障、ARP學習失敗等）而接收不到所有Ping應答報文的現象。

如果您需要了解Ping的原理

如圖1所示，以一個Ping不通的嘗試示例，介紹Ping不通故障的定位思路。

02現象描述

SwitchA Ping不通SwitchD。

表1 Ping命令輸出信息描述

03故障定位

如圖1所示，Ping操作涉及三個角色：

——源端：Ping報文發起端SwitchA

——中間設備：SwitchB和SwitchC

——目的端：Ping報文接收端SwitchD

當在源端SwitchA上直接Ping IP地址192.168.3.11不通時，直接判定故障出現的原因比較困難。

此時可以縮小故障范圍，在SwitchA上分別Ping SwitchB、SwitchC、SwitchD，然后在SwitchB上分別Ping SwitchC、SwitchD，依此類推，最后可以判斷出哪一段網絡出現故障。

以下述兩種情況為例，介紹Ping不通的故障定位方法。

04情況一

假設故障發生在SwitchA和SwitchB之間，即SwitchA Ping SwitchB的IP地址192.168.1.11不通，定位流程如圖2所示（其他直連網段Ping不通的故障處理方法類似），詳細的定位方法請參見Ping不通故障定位指導。

05情況二

假設SwitchA Ping SwitchB的IP地址192.168.1.11能通，SwitchB Ping SwitchC的IP地址192.168.2.21能通，但是SwitchA Ping SwitchC的IP地址192.168.2.21不通。@ 網 絡 工 程 師 俱 樂 部

這種情況需要在SwitchA、SwitchB和SwicthC上做ICMP報文的流量統計，進而判斷流量是在哪丟棄的，關于流量統計的方法，請參見ICMP報文流量統計。

圖2 直連Ping不通流程圖

03 Ping不通故障定位指導

01檢查Ping命令是否合理

在SwitchA上檢查是否執行了 ping –f 192.168.1.11 命令。

如果執行了此操作，則ICMP報文發送的過程中不支持分片，此時需要檢查鏈路上出接口的MTU值。

如果MTU值小于ICMP報文長度，由于ICMP報文的發送過程中不支持分片，如果ICMP報文的大小超過鏈路的MTU值，ICMP報文將會被丟棄，所以會導致Ping不通。

此時可以通過不使用-f參數或者增大鏈路MTU值的方式使ICMP報文不被丟棄。

02檢查配置是否正確

若PC直連交換機，確保PC與所屬VLAN配置的VLANIF IP地址為同一網段。

若交換機與其他網絡設備直連，確保兩端設備接口類型、VLAN配置一致，兩端VLANIF IP地址為同一網段。以SwitchA為例，查看方法如下：

執行命令 display port vlan 查看GE1/0/1接口的接口類型和VLAN配置。

其中Link Type代表的是接口鏈路類型，Trunk VLAN List代表的是接口動態加入和靜態配置允許通過的VLAN ID。

執行命令 display ip interface brief 查看VLANIF10接口下的IP地址配置。其中IP Address/Mask代表的是接口的IP地址和掩碼。

03檢查物理鏈路狀態是否正常

1、檢查物理鏈路連接

查看設備接口指示燈狀態，如果是常滅，說明無連接。此時需要更換接口或者網線再進行嘗試。

查看光纖或網線連接的接口和網絡要求的部署是否一致。

如果不一致，需要重新對接口進行部署。

光纖所帶的光模塊波長參數需要一致，光模塊建議使用華為認證光模塊。

如果是通過Eth-Trunk接口連接，執行命令 display eth-trunk trunk-id 檢查兩端設備上Eth-Trunk中加入的物理成員接口數量是否一致，如果不一致，需要進行Eth-Trunk的重新配置。

如果是手工模式Eth-Trunk，回顯如下，其中PortName代表的是加入Eth-Trunk的接口。

如果是LACP模式Eth-Trunk，回顯如下，其中ActorPortName代表的是加入Eth-Trunk的接口。

2、檢查對應的VLANIF接口是否Up

VLANIF接口UP是能Ping通的前提。

執行命令display ip interface brief查看VLANIF接口的狀態，如果VLANIF接口Down，說明該VLAN下沒有成員接口Up。

執行命令display interface brief 查看接口狀態，保證接口Up。如果接口為Down狀態，請首先排除接口Down的故障。

3、如果VLANIF和物理接口均為UP狀態，檢查設備上是否運行了STP、RRPP或Smart Link等二層協議，確認Ping業務經過的物理接口是否被阻塞。

如果接口被阻塞，需要修改相關的配置。

1）執行命令 display stp brief 命令，查看STP狀態，回顯信息中STP State為FORWARDING表示轉發狀態，為DISCARDING表示阻塞狀態。

2）執行命令 display rrpp verbose [ domain domain-id [ ring ring-id ] ]，查看RRPP配置的詳細信息，回顯信息中Port status為UP表示轉發狀態，為BLOCKED表示阻塞狀態

3）執行命令 display smart-link group all ，查看Smart Link組的狀態信息，回顯信息中State為Active表示轉發狀態，為Inactive表示阻塞狀態。

04檢查路由是否正常

1、 檢查是否有直連路由

如果和交換機連接的是終端設備，檢查終端設備上是否配置了正確的網關地址。

如果和交換機連接的是交換機或路由設備，檢查設備上是否有正確的回程路由。

在源端執行命令display ip routing-table ip-address 檢查有無到對端的路由。

如有路由則顯示如下信息，回顯字段中Proto為Direct表示為直連路由。

由于遵循最長匹配原則，同一路由前綴，當非直連路由掩碼長度大于直連路由時，將導致報文無法從直連接口轉發。

若檢查目的IP匹配的路由為非直連路由，需排查路由故障。

如果沒有路由，則輸入上述命令后無任何信息顯示，需要檢查路由協議配置是否正確。

2、檢查是否配置了策略路由

例如：SwitchB在GE1/0/2接口調用策略路由，將SwitchA上送的源IP地址為192.168.1.10的報文重定向到下一跳192.168.2.11。

可以通過下述步驟查看策略路由配置并做相應配置的修改。

a、執行display traffic-policy applied-record命令，查看流策略的應用記錄。

b、執行display traffic behavior user-defined behavior-name命令，查看已配置的流行為信息。

c、執行display traffic classifier user-defined classifier-name命令，查看策略中流分類關聯的ACL編號。

<SwitchB> display traffic classifier user-defined c1User Defined Classifier Information: Classifier: c1Precedence: 15Operator: ANDRule(s) : if-match acl 3000 //流分類c1關聯的ACL為acl 3000

d、執行display acl acl-number命令，查看ACL具體內容。

<SwitchB> display acl 3000
Advanced ACL 3000, 1 rule
Acl's step is 5
rule 5 permit ip source 192.168.1.10 0 //acl 3000中匹配了源地址為192.168.1.10的所有IP

3、修改流策略，保證SwitchA與SwitchB之間的流量正常轉發。

配置思路：新建ACL，匹配SwitchA到SwitchB的流量，這部分流量不做重定向。

配置順序：配置流分類時，先創建不做重定向的流分類，再配置用于重定向的流分類。

配置流策略時，先綁定不做重定向的流分類和流行為，再綁定用于重定向的流分類和流行為。

<SwitchB> system-view[SwitchB] acl 3001 //新建ACL[SwitchB-acl-adv-3001] rule permit ip source 192.168.1.10 0 destination 192.168.1.11 0.0.0.255 //匹配SwitchA到SwitchB的IP報文（不做重定向的流量）[SwitchB-acl-adv-3001] quit[SwitchB] traffic behavior b2 //新建流行為[SwitchB-behavior-b2] permit //動作為允許（正常轉發，不做重定向動作）[SwitchB-behavior-b2] quit//由于之前的策略已經調用在接口，所以需要先在接口下取消策略調用，再到流策略中解除綁定的流分類，在全局刪除流分類后再按順序配置。[SwitchB] interface GigabitEthernet1/0/1[SwitchB-GigabitEthernet1/0/1] undo traffic-policy inbound //進入接口下取消策略調用[SwitchB-GigabitEthernet1/0/1] quit[SwitchB] traffic policy p1[SwitchB-trafficpolicy-p1] undo classifier c1 //解除策略下綁定的流分類[SwitchB-trafficpolicy-p1] quit[SwitchB] undo traffic classifier c1 //全局下取消之前創建的流分類[SwitchB] traffic classifier c2 //先創建不做重定向的流分類c2[SwitchB-classifier-c2] if-match acl 3001 //在c2中匹配acl 3001[SwitchB-classifier-c2] quit[SwitchB] traffic classifier c1 //再創建用于重定向的流分類c1[SwitchB-classifier-c1] if-match acl 3000 //在c1中匹配acl 3000[SwitchB-classifier-c1] quit[SwitchB] traffic policy p1 //進入流策略，先綁定不做重定向的流分類和流行為，再綁定需要重定向的流分類和流行為[SwitchB-trafficpolicy-p1] classifier c2 behavior b2[SwitchB-trafficpolicy-p1] classifier c1 behavior b1[SwitchB-trafficpolicy-p1] quit[SwitchB] interface GigabitEthernet1/0/1 //進入接口下調用流策略[SwitchB-GigabitEthernet1/0/1] traffic-policy p1 inbound[SwitchB-GigabitEthernet1/0/1] quit

05檢查ARP學習是否正確

執行display arp all命令，檢查直連地址的ARP是否學習正常。

下述回顯信息中，如果MAC ADDRESS顯示的是MAC地址，則代表ARP學習正確；

如果顯示的是Incomplete，表示當前表項為臨時ARP表項，尚未學習到ARP，出現MAC地址后，代表ARP學習完成。

如果ARP學習正確，通過display mac-address interface-type interface-number命令查看MAC表項，確認MAC地址的出接口和ARP的物理出接口是否一致。

若不一致，排查是否存在環路或MAC沖突。

如果ARP學習失敗，有以下幾種可能性，請參照表1進行排查ARP學習失敗的原因（SwitchA向SwitchB發送ARP請求報文）。

表1 ARP學習失敗可能的原因

06檢查是否配置黑名單

配置cpu-defend黑名單后，設備將直接丟棄黑名單用戶上送的報文

通過display cpu-defend policy查看調用在全局或特定槽位的策略名，然后通過display cpu-defend policy policy-name查看策略中是否配置黑名單（Blacklist），再通過display acl acl-number查看黑名單調用的ACL具體內容

黑名單中應用的ACL，無論其rule配置為permit還是deny，命中該ACL的報文均會被丟棄。

如果策略中配置了黑名單，且黑名單中包含對端IP，請嘗試刪除黑名單或修改黑名單關聯的ACL，保證報文可以被正常處理。

例如：取消防攻擊策略test1下的黑名單配置。

如果策略中沒有配置黑名單，或者黑名單中不包含對端IP，進行下一步排查。

07檢查報文收發是否正常

如果通過以上步驟排查配置、鏈路、ARP表項和路由表項均正常，但是仍然Ping不通，接下來檢查ICMP報文收發是否正常。

1.ICMP統計查詢

進行Ping操作時，通過命令display icmp statistics查看ICMP報文的收發情況，ICMP Echo Request和ICMP Echo Reply報文收發是否一致，是否存在checksum錯誤統計計數。

SwitchA Ping SwitchB，以SwitchA的回顯為例，Output方向的echo字段代表的是請求報文數目，Input方向的echo reply代表的是應答報文數目，bad checksum代表的是校驗錯誤的報文數目。

在SwitchA上執行Ping操作的前后查看bad checksum計數是否一直增長，如果一直增長，需要檢查對端設備SwitchB的協議棧軟件回應ICMP報文的格式是否正確。

如果echo和echo reply數目一致，但是仍然Ping不通，接下來需要進行ICMP報文流量統計進而判斷報文的收發情況。

如果echo和echo reply數目不一致：

如果SwitchA發出的echo報文數目少于Ping發送的報文數目，說明報文在SwitchA上被丟棄。

如果SwitchA發出的echo報文數目多于SwitchB接收到的echo報文的數目，說明報文在傳輸鏈路上被丟棄。

如果SwitchA發出的echo報文數目等于SwitchB接收到的echo報文的數目，但是離開SwitchB的echo reply報文數目少于進入SwitchB的echo報文的數目，說明報文在SwitchB上被丟棄。

如果報文在鏈路上被丟棄，請更換鏈路再進行Ping測試；

如果報文在終端或其他廠商設備被丟棄，請排查終端或者其他廠商設備；

如果報文在華為交換機被丟棄，可進入下一步排查或者聯系技術支持人員處理。

2.ICMP報文流量統計

以SwitchA為例，介紹如何對ICMP報文做流量統計。

（1）配置進入SwitchA報文的流量統計。

? 配置ACL規則。這里的ACL一定要是高級ACL，編號范圍為3000～3999。

? 配置流分類。

? 配置流行為。

? 配置流策略。

在接口上應用流策略

（2）配置離開SwitchA報文的流量統計

配置ACL規則。這里的ACL一定要是高級ACL，編號范圍為3000～3999。

? 配置流分類。

? 配置流行為。

? 配置流策略。

? 在接口上應用流策略

如果是交換機直連PC，在連接PC的接口出、入方向調用流統策略；

如果是交換機與其他網絡設備直連，建議在兩臺設備兩個接口的出、入方向都使用流量統計。

配置完成后，先執行reset命令清空計數信息，以保證接口流統計數歸零，相關命令如下：

reset traffic policy statistics interface GigabitEthernet 1/0/1 inboundreset traffic policy statistics interface GigabitEthernet 1/0/1 outbound

在SwitchA上持續Ping SwitchB，通過display traffic policy statistics interface interface-type interface-number { inbound | outbound } verbose rule-base命令查看接口流量統計信息。

以SwitchA出方向為例，介紹上述display命令的回顯，其中Packets和Bytes分別代表報文包個數和報文字節數。

如果離開SwitchA的報文數目少于Ping發送的報文數目，說明報文在SwitchA上被丟棄。

如果離開SwitchA的報文數目多于進入SwitchB的報文數目，說明報文在傳輸鏈路上被丟棄。

如果離開SwitchA的報文數目等于進入SwitchB的報文數目，但是離開SwitchB的報文數目少于進入SwitchB的報文數目，說明報文在SwitchB上被丟棄。

如果報文在鏈路上被丟棄，請更換鏈路再進行Ping測試；

如果報文在終端或其他廠商設備被丟棄，請排查終端或者其他廠商設備；如果報文在華為交換機被丟棄，可進入下一步排查或者聯系技術支持人員處理。

08檢查CPCAR統計是否有過多ICMP報文被丟棄

查看CPCAR的統計情況，檢查ICMP報文是否由于CPCAR超出限制被丟棄，相關命令行如下（不同形態、不同版本的命令行有所不同）：

對于框式交換機V100R002版本、盒式交換機V100R005版本，執行display cpu-defend icmp statistics all命令查看Drop計數是否在增加。

對于框式交換機V100R003及之后版本、盒式交換機V100R005及之后版本，執行display cpu-defend statistics packet-type icmp all命令查看Drop計數是否在增加。

對于框式交換機V100R003及之后版本、盒式交換機V100R005及之后版本，執行display cpu-defend statistics packet-type icmp all命令查看Drop計數是否在增加。

如果Drop計數在增加，說明存在CAR丟包，可以適當增加CAR值再進行Ping測試，看問題是否解決，最后建議恢復CAR值。

調整CPCAR不當將會影響網絡業務，如果需要調整CPCAR，建議聯系技術支持人員處理。

修改CAR的命令如下：

配置cpu-defend policy，執行命令car packet-type icmp cir cir-value指定新的CAR值。

將該Policy策略在全局或者指定的接口板應用。全局應用：

[HUAWEI] cpu-defend-policy 1 global  

在指定的接口板應用：

09檢查報文格式是否正確

有時雖然交換機收到了報文，但是可能報文的格式不對，導致無法得到正確處理。例如目的MAC錯誤，VLAN的CFI被置為1等，此時則需要通過獲取報文信息來確認。

在端口獲取報文可以更加直接的看到設備上報文的收發情況，可以使用端口鏡像或者流鏡像獲取端口下的所有報文，然后分析ICMP報文格式是否正確。

在鏡像獲取報文無法實施時，使用capture命令確認報文接收情況，然后分析ICMP報文格式是否正確。

配置鏡像查看報文收發情況

如果端口上流量不大，可以配置端口鏡像，確認報文的收發情況（以SwitchA為例）。

配置觀察口。

配置鏡像口，獲取雙向報文。

如果端口上流量比較大，可以配置流鏡像（以SwitchA為例）。配置觀察口。

配置ACL規則。

配置流分類。

配置流行為。

配置流策略。

在接口上應用流策略。

通過對鏡像報文進行分析，不僅可以確認報文的收發情況，同時可以對報文進行校驗，包括：報文的VLAN是否正確、報文的目的MAC地址是否是設備系統MAC地址、報文IP頭的checksum是否正確、ICMP的checksum是否正確。

使用capture命令確認報文接收情況 在鏡像獲取報文無法實施時，也可以使用Capture命令來確認端口收到的報文情況，可以將報文打印到登錄終端進行顯示，也可以存入.cap文件中保存到設備上，然后對獲取到的報文進行分析。

capture命令如下：

10收集信息并尋求技術支持

1.收集信息

收集上述各個操作步驟的執行結果。

采集logbuffer信息、trapbuffer信息。

采集一鍵式診斷信息。

<HUAWEI> display diagnostic-information  

若輸出診斷信息過長，可以按Ctrl+C停止。

此命令主要用于問題定位，搜集系統診斷信息，搜集時可能會影響系統的性能（例如CPU占用率升高等）。

因此，在系統正常運行時不建議執行此命令。

嚴禁在連接到設備的多個終端上同時執行display diagnostic-information命令，否則可能造成設備的CPU占用率明顯增高，導致設備性能下降。

保存交換機的日志、診斷日志

將框式交換機CF卡中保存的日志、診斷日志文件導出到相關文件路徑。

<HUAWEI> cd cfcard:/logfile 

將盒式交換機Flash中保存的日志、診斷日志文件導出到相文件路徑。

<HUAWEI> cd logfile/  

2.尋求技術支持

請聯系華為技術支持人員獲取技術支持。

整理：老楊丨10年資深網絡工程師，更多網工提升干貨，請關注公眾號：網絡工程師俱樂部