📙 pingに応答するもの

2026/11/13公開 2026/11/13更新

  • 質問者: Shigeru Morifuku

  • 回答者: Claude Opus 5.5

  • 回答日: 2026/11/13

  • 免責: 回答者は AI であり、間違えることがあります。

🟩 Q: ICMP echoって、NICが返しているの？Kernelのお世話になっているの？

基本的にはカーネルが返しています。 NICはパケットを受信して送信するだけで、ICMPの中身は見ていません。

🟨 Linuxでの流れ

NIC受信 → DMAでRXリングへ書き込み → IRQ → NAPI poll (softirq)
  → __netif_receive_skb → ip_rcv → ip_local_deliver
  → icmp_rcv → icmp_echo → icmp_reply   (net/ipv4/icmp.c)
  → ip_push_pending_frames → dev_queue_xmit → NIC送信

  • 処理はすべてsoftirqコンテキストで完結します。ユーザ空間のプロセスは関わらず、コンテキストスイッチも起きません。

  • 応答パケットはカーネルが組み立てます。受信したペイロードをそのままコピーして、type 0 (Echo Reply) にするだけです。ICMPのチェックサムも普通はソフトウェアで計算します。NICのTXチェックサムオフロードの対象はTCP/UDPが中心です。

  • 次の設定で応答を止められます。

    • net.ipv4.icmp_echo_ignore_all / icmp_echo_ignore_broadcasts

    • IPv6では net.ipv6.icmp.echo_ignore_all

    • ほかに netfilter で落とす方法もあります。

  • Windowsも同じで、カーネルドライバの tcpip.sys が返しています。

🟨 このことから分かる実用上のポイント

pingが返る＝カーネルのネットワークスタックとNICドライバが生きている、という意味でしかありません。 ユーザ空間がハングしていても、OOMでアプリが死んでいても、ping は返ります。逆にカーネルパニックしたホストは基本的に返しません。死活監視でpingを使うなら、この点に注意が必要です。

🟨 例外：NICやカーネル以外が返すケース

ケース

誰が返すか

DPDK などのカーネルバイパス

カーネルがNICを手放すので、誰も返しません。自分のアプリでARPやICMPを実装するか、KNI / virtio-user などでカーネルに処理を回す必要があります

BMC (IPMI/iDRAC/iLO) の共有NIC (NC-SI)

NICがBMC宛てのパケットを振り分け、BMC側のファームウェアが返します。ホストOSが落ちていても返ります

Intel AMT / ME

NIC経由で、ME側のファームウェアが応答する構成があります

SmartNIC / DPU (BlueField等)

NIC上のArm CPUで動くLinuxやファームウェアが返します。結局はそこで動く「カーネル」が返していることが多いです

ルータ / L3スイッチ

転送はASICが行いますが、自分宛てのICMPはコントロールプレーンのCPUに上げて処理します。CoPPでレート制限されるので、ルータへのpingの遅延やロスは転送性能の指標になりません

DPDKを触る予定があるなら、「ping が返らなくなる」はハマりどころなので覚えておくと役に立ちます。

🟩 Q: ARPは？どこまで動く？

ARPも基本的にはカーネルが返します。ただしICMPより低い層で処理されるので、ICMPよりもしぶとく動きます。

🟨 Linuxでの流れ

NIC受信 → NAPI poll (softirq) → __netif_receive_skb
  → EtherType 0x0806 で振り分け → arp_rcv → arp_process  (net/ipv4/arp.c)
     ├ 自分宛てのRequestなら → arp_send で Reply を返す
     └ 送信元の情報を近隣テーブル(neighbour)に学習・更新

ARPは ip_rcv を通りません。IPスタックとは別の入口(packet_type)から入り、IP層とは近隣テーブル(ip neigh)だけを共有しています。

🟨 どこまで動くか

状態

ARP応答

ping応答

ユーザ空間がハング / OOM

○

○

icmp_echo_ignore_all=1

○

×

iptables/nftables の ip ファミリで全部DROP

○(素通り)

×

arptables / nft の arp ファミリでDROP

×

×(実質)

IFにIPが付いていない

×

×

ip link set down

×

×

カーネルパニック

×

×

DPDKでNICをバインド

×(自前で実装が必要)

×

スリープ(S3)中 + NICのARP Offload

○(NICが返す)

×

ポイントは次の3つです。

  • iptablesではARPを止められません。 ARPはIPパケットではないからです。ping は通らないのに arping は通る、という状況が普通に起こります。生存確認を「L2の到達性」と「L3/カーネルIPスタック」に分けたいときは、arping と ping を使い分けると便利です。

  • 最後の行がNICだけで返す数少ない例です。 Intelなどの一部のNICは「ARP Offload」「NS Offload」に対応しています。ホストがスリープしている間、OSが事前に登録しておいたIPに対してNICのハードウェアがARP Replyを返します。WindowsのNICのプロパティ(電源の管理)に出てくる設定がそれです。スイッチやルータのARPエントリが消えないので、WoLで起こすときにも都合がよい仕組みです。

  • IPv6のNDP(Neighbor Solicitation/Advertisement)はICMPv6の上に乗っています。それでも net.ipv6.icmp.echo_ignore_all が止めるのはEchoだけで、NDPは動き続けます。

🟨 Linux特有のクセ(weak host model)

Linuxはデフォルト(arp_ignore=0)の状態だと、どのインタフェースに来たARP Requestでも、ホストが持つIPなら答えます。eth0宛てのARPにeth1のIPで答えることもあります。マルチホームやLVS-DRで問題になる挙動です。

  • arp_ignore=1: 受信したIFに付いているIPにだけ応答する

  • arp_announce=2: 送信するARPの送信元IPに、出ていくIFのIPを使う

  • arp_filter、proxy_arp も関係するノブです

現場(産業系のLANで複数セグメントにまたがる構成など)で「なぜか違うMACが返ってくる」ときは、たいていこれが原因です。

🟩 Q: カーネルが止まっいても動くのはWoLくらい？

WoLだけではありません。ただし、カーネルが止まっているときに応答するのは、カーネルとは別に動いているハードウェアやファームウェアに限られます。誰が動いているかで分けると次のとおりです。

🟨 1. NICのハードウェア/ファームウェアだけで動くもの

機能

内容

リンク維持(PHY)

オートネゴシエーションとリンクアップは続きます。スイッチ側からは「リンクは上がっているのに無反応」に見えます

WoL

マジックパケットやパターンマッチで電源投入を要求します。S3/S4/S5でも待機電源で動きます

ARP/NS Offload

スリープ時だけ有効です。OSが寝る前にドライバ経由でNICへ登録しておく仕組みなので、パニック時には効きません

PAUSEフレーム(フロー制御)

RXバッファがあふれるとNICが自発的に出します。止まったホストがPAUSEを出し続けて、スイッチのポートを詰まらせる事故もあります

ファームウェアLLDP

Intel X710/E810などは、NICファームウェアがOSと無関係にLLDPを喋ります(ethtool --set-priv-flags ... disable-fw-lldp)

🟨 2. 別のCPU/OSで動くもの(本命)

  • BMC (IPMI / Redfish / iDRAC / iLO): サーバ管理用のSoCが独立して動いています。電源OFFやパニック中でもping・ARPに応答し、SOL(Serial over LAN)でパニック画面を見たり、電源をリセットしたりできます。専用ポートかNC-SIの共有NIC経由で使います。カーネルが止まった後に頼れるのは、事実上これです。

  • Intel AMT / vPro(ME): BMCのクライアントPC版です。KVM over IPまで使えます。

  • SmartNIC / DPU: NIC上のArm Linuxはホストとは独立して動きます。

🟨 3. 止まりかけのカーネル自身が最後にやること

  • netconsole: パニック時に、割り込みを使わないポーリングモードでUDPのログを送ります。

  • kdump: 予約しておいたメモリ上で第2カーネルが起動し、ダンプを保存します。

  • kernel.panic=N やハードウェアウォッチドッグ(iTCO、BMCウォッチドッグ)による自動リセット。

🟨 補足:「止まっている」の程度で変わります

  • プロセスだけ詰まっている(softirqは生きている): ping・ARPとも返ります。

  • soft lockup: CPUによっては返ったり返らなかったりします。

  • hard lockup / パニック: 返りません。RXリングがいっぱいになると、NICは受信パケットを捨てるだけになります。

つまり、pingは返らないがBMCにはpingが通る状態なら、ハードウェアと電源は生きていてOS側で止まっている、と切り分けられます。