PING応答がない時に確認すべき点を紹介していきます。とても基本的な確認も含めています。
本記事の解説図は下図です。ここでは、クライアントPCを送信元（192.168.1.10）として、異なるネットワークのサーバ（192.168.4.10）へPINGを実行して、応答がない時の確認点を紹介しています。
1. PCのNIC（LANボード）がリンクアップしているかを確認
・ PCのNICにLANケーブルを接続していますか？
・ PCのNICのLANアダプターの設定は「有効」ですか？
・ PCの接続先（L2スイッチなどの）ポートでは、ポートLEDがグリーンですか？
2. 有線LAN、無線LANの両方がリンクアップしていないか確認
適切なルーティングが行われる場合には、有線LAN、無線LANの両方が有効でも問題なく通信できますが、問題切り分けのために、PCで有効化させるのは「有線LANだけ」にしましょう。
また、「有線だけ有効」あるいは「無線だけ有効」にするだけでなく、USBテザリングなどを使用している場合はもちろんそれも切断しましょう。
恥ずかしながら、当方も検証している時にテストPCがUSBテザリングしている状態であることを忘れていて「意図した通信ができない、なぜだろう・・」と思ってしまう時があります。
3. PCに設定しているIPアドレスが適切であるかを確認
PCに設定しているIPアドレスが適切であるかどうか、コマンドプロンプトを開いてipconfigと入力して設定されているIPアドレス、サブネットマスク、デフォルトゲートウェイの設定情報を確認しましょう。
4. 先ず、デフォルトゲートウェイのPING応答があるかを確認
デフォルトゲートウェイとなる「L3スイッチ」または「ルータ」で、ICMPをブロックしたACL設定がなければPING応答があるはずです。ここでPING応答が得られない場合には以下の原因が考えられます。
・ PCに設定しているIPアドレス、サブネットマスクの値が間違っている。
・ デフォルトゲートウェイのL3デバイスのIPアドレスの設定が間違っている。
・ デフォルトゲートウェイのL3デバイスのLANポートを有効化（no shut）していない。
・ デフォルトゲートウェイのL3デバイスのLANポートにストレートケーブルまたはクロスケーブルの適切なLANケーブルが接続されておらず、ポートLEDがグリーン状態ではない。
・ PCとデフォルトゲートウェイのL3デバイスの間にあるL2スイッチで、適切なVLANが設定されていないなど、L2スイッチに問題がある。
◆ PINGを実行した時の応答結果で表示される意味 ⇒ ICMP – ping を実行した時に応答結果
5. 次に、宛先デバイスの宛先IPアドレスにtracertを実行
Windowsでtracertを実行すると宛先デバイスに到達するまでの経路で、どのL3デバイスまでが正常に（意図した）ルーティングができているのかを確認できます。PCから tracert を実行すると説明図の赤丸部分のIPアドレスがコマンドプロンプトに表示されます。
宛先デバイスへ到達するまでに経由するL3デバイスでACLのフィルタリング設定がなければ、宛先デバイスへ到達するまでに経由するL3デバイスのIPアドレスが表示されていくことから、応答がないL3デバイス（タイムアウト状態となるL3デバイス）を特定できます。
解説図の構成では、192.168.1.254 ⇒ 192.168.2.254 ⇒ 192.168.3.254 ⇒ 192.168.4.10の順番で正常時にtracertの結果が出力されていきます。
◆ tracert（traceroute）の解説 ⇒ trace（traceroute）とは
6. 正常にルーティングできていないL3デバイスの確認
traceにより正常にルーティングできていないL3デバイスを特定できれば、そのL3デバイスのルーティングテーブルの内容を確認します。ルーティングテーブル上で以下の2つのルートが存在するかどうかを確認します。
・ 送信元デバイスのネットワーク（192.168.1.0/24）
・ あて先デバイスのネットワーク（192.168.4.0/24）
宛先ネットワークへと通信できないので、宛先ネットワークのルート情報だけを確認する・・ではなく、送信元ネットワークのルート情報も確認する必要があります。ルーティングでは、「行きのルート」と「帰りのルート」を双方向で必要となります。ダイナミックルーティングの場合は動的にルート情報がやりとりされるので問題ないですが、スタティックルートの場合この点を忘れないように。また、ネクストホップのアドレスが正しいかも確認しましょう。
◆ ルーティングの解説 ⇒ ルーティングとは
7. サーバ側のNICやIPアドレスの設定に問題がないかを確認
・ サーバのNICにLANケーブルを接続していますか？
・ サーバのNICのLANアダプターの設定は「有効」ですか？
・ サーバの接続先（L2スイッチなどの）ポートでは、ポートLEDがグリーンですか？
・ サーバ側のIPアドレス、サブネットマスク、デフォルトゲートウェイを正しいですか？
・ サーバ側でiLO専用ポート以外に、データ通信用NICに複数のLANケーブルが接続されている場合、問題切り分けのため（可能である場合）ケーブルを抜き1リンクにしてみましょう。
・ サーバからデフォルトゲートウェイ（192.168.4.254）にPINGを実行して応答があるかどうかを確認しましょう。
・ サーバ側にWindowsファイアウォールなどでICMPがブロックされていないかどうか確認しましょう。ルータなど同じセグメントにいるデバイスからサーバにPINGをして確認します。
8. サーバ側に route add が設定されていないかを確認
これは見落としやすいポイントです。PCやサーバはルーティングテーブルを持っており、その内容はコマンドプロンプトでroute printと入力すれば確認できます。GUI上でのTCP/IPの設定以外にコマンドプロンプトで静的にスタティックルートを定義できます。
意図しないスタティックルート（route add）が残っている場合はそれを削除しましょう。
◆ route addの解説（route addとは、route addの設定、削除） ⇒ route addとは
以上です。トラブルシューティング時にお役に立てて頂ければと思います。
もう少しステップアップしたネタとして、ARPリプライが得られない時の対処法やその事例を紹介したARP応答しない原因と対処法の記事もご参考頂ければと思います。F5のBIG-IP製品で「snat」をiRuleで定義しているNW構成でうまく動作しない時に「助けて下さい」と時々質問を受けるのですが、こちらの内容を読んでもらっています、こちらも役立つかもしれません。