ネットワークの基本¶

Ethernet¶

Ethernet は IEEE 802.3 標準で規程されたネットワークプロトコルです。ほとんどの有線のネットワークインターフェースカード (NIC) は Ethernet を使って通信します。

Ethernet は、ネットワークプロトコルの OSI model の第 2 層にあたり、データリンク層とも呼ばれます。 Ethernet の話をすると、 ローカルネットワーク、レイヤー 2、 L2、リンクレイヤー、 データリンク層 といった用語をしばしば聞くことでしょう。

Ethernet ネットワークでは、ネットワークに接続されたホストは フレーム をやり取りして通信します。 Ethernet ネットワーク上の各ホストは、MAC (media access control; メディアアクセス制御) アドレスと呼ばれるアドレスにより一意に識別されます。特に、 OpenStack 環境では、各仮想マシンインスタンスは一意な MAC アドレスを持ち、その MAC アドレスはコンピュートホストの MAC アドレスとも異なります。 MAC アドレスは 48 ビットで、通常は 08:00:27:b9:88:74 のような 16 進数で表現されます。 MAC アドレスは製造ベンダーにより NIC に書き込まれていますが、最近の NIC は MAC アドレスをプログラムして書き換えることもできます。 Linux では ip コマンドを使って NIC の MAC アドレスを取得できます。

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:b9:88:74 brd ff:ff:ff:ff:ff:ff

概念としては、 Ethernet ネットワークはそのネットワークのすべてのホストが接続する 1 本のバスとみなせます。初期の実装では、 Ethernet ネットワークは、ネットワークに接続するためにホストがつなぎ込む 1 本の同軸ケーブルで構成されていました。最近の Ethernet ネットワークはこの方法は取っておらず、代わりに各ネットワークホストは スイッチ と呼ばれるネットワークデバイスに直接接続します。依然として、この概念モデルは有用で、ネットワーク図ではしばしば Ethernet ネットワークは 1 本のバスであるかのように描かれます (OpenStack ダッシュボードが生成するネットワーク図もそうです)。時として Ethernet ネットワークは レイヤー 2 セグメント と呼ばれることもあります。

Ethernet ネットワークでは、ネットワーク上のどのホストも他のどのホストにも直接フレームを送信できます。 Ethernet ネットワークはブロードキャストもサポートしており、特別な MAC アドレス``ff:ff:ff:ff:ff:ff`` に送信することで、あるホストが 1 つのフレームでネットワーク上のすべてのホストに送信ができます。 Ethernet のブロードキャストを使う有名なプロトコルが 2 つあり、 ARP と DHCP です。 Ethernet ネットワークはブロードキャストをサポートしているため、 Ethernet ネットワークは ブロードキャストドメイン と呼ばれることもあります。

NIC がEthernet フレームを受信すると、デフォルトでは NIC は宛先 MAC アドレスが NIC のアドレス (またはブロードキャストアドレス) に一致するかを確認し、 MAC アドレスが一致しない場合はその Ethernet フレームを廃棄します。コンピュートホストでは、この動作は期待されるものではありません。なぜなら、そのフレームはインスタンスの 1 つに宛てたものかもしれないからです。 NIC は promiscuous モード (無差別モード) に設定することができ、このモードでは、 MAC アドレスが一致しない場合であっても、すべての Ethernet フレームがオペレーティングシステムに渡されます。コンピュートホストでは、必要な NIC を常に promiscuous モードに設定する必要があります。

上で述べたように、最近の Ethernet ネットワークはネットワーク間を接続するのにスイッチを使用します。スイッチは、多数のポートを持つネットワークハードウェアの箱で、スイッチに接続されたあるホストから別のホストに Ethernet フレームを転送します。ホストが最初にフレームをそのスイッチ経由で送信する際には、スイッチはどの MAC アドレスがどのポートに関連付いているかを知りません。 Ethernet フレームの宛先が知らない MAC アドレスの場合、スイッチはすべてのポートにそのフレームをブロードキャストします。ポートはどの MAC アドレスがどのポートにいるかを、トラフィックを観測して学習します。いったんどの MAC アドレスがどのポートに関連付いているかを学習すると、その後はスイッチは Ethernet フレームをブロードキャストせずに正しいポートに送信できます。スイッチは MAC アドレスからスイッチポートへの対応関係をテーブルで管理します。このテーブルは forwarding table (転送テーブル) や forwarding information base (FIB) と呼ばれます。スイッチは数珠つなぎ (daisy-chain) にすることができ、その結果、スイッチとホストの接続は 1 つのネットワークの場合と同様の動作をします。

VLAN¶

VLAN は、1 つのスイッチがあたかも複数の独立したスイッチであるかのように振る舞えるようにするネットワーク技術です。特に、同じスイッチだが別の VLAN に接続されている 2 つのホストはお互いのトラフィックを見ることはできません。 OpenStack は、複数のテナントが 1 つの同じコンピュートホスト上で動作するインスンタンスを持っている場合でも、 VLAN を使って異なるテナントのトラフィックを分離できます。各 VLAN には数値の ID が関連付けられ、 1 から 4095 の範囲です。 “VLAN 15” といった場合は、その VLAN の数値の ID が 15 ということです。

VLAN がどのように動作するかを理解するために、物理ホストが物理スイッチに接続され、仮想化が行われていない、従来の IT 環境で VLAN の利用を考えてみましょう。ここで、 3 つの分離されたネットワークが必要だが、物理スイッチは 1 つしか持っていないとしましょう。ネットワーク管理者は 3 つ VLAN ID (10, 11, 12 とします) を選んで、スイッチを設定してスイッチポートをこれらの VLAN ID に関連付けます。例えば、スイッチポート 2 は VLAN 10 に、スイッチポート 3 は VLAN 11 に関連付け、他も同様とします。スイッチポートが特定の VLAN に設定された場合、そのポートは アクセスポート と呼ばれます。ネットワークトラフィックが VLAN 間で分離されることは、スイッチの責任で保証されます。

今度は、 1 台目のスイッチのスイッチポートがすべて利用され、組織が 2 台目のスイッチを購入して、1 台目のスイッチに接続して、利用できるスイッチポート数を拡張する、というシナリオを考えましょう。 2 台目のスイッチも VLAN 10, 11, 12 が使用できるように設定します。ここで、スイッチ 1 の VLAN ID 10 に設定されたポートに接続されたホスト A が、スイッチ 2 の VLAN ID 10 に設定されたポートに接続されたホスト B に Ethernet フレームを送信する場面を考えます。スイッチ 1 は Ethernet フレームをスイッチ 2 に転送する際に、そのフレームは VLAN ID 10 に関連付けられていることを伝える必要があります。

2 台のスイッチは互いに接続されていて、両方のスイッチで VLAN が設定されている場合、スイッチ間の相互接続に使用されるスイッチポートは、どの VLAN からの Ethernet フレームももう一方のスイッチに転送できなければいけません。さらに、受信側のスイッチが VLAN に対応するホストだけがそのフレームを受信できることを保証できるように、送信側のスイッチは Ethernet フレームに VLAN ID のタグを付けなければいけません。

スイッチポートがすべての VLAN からのフレームを転送し、それらに VLAN ID のタグを付ける場合、そのポートは トランクポート と呼ばれます。 IEEE 802.1Q は、トランクポートを使う際に VLAN タグをどのように Ethernet フレームに入れるかを規程したネットワーク標準です。

OpenStack クラウドでテナント分離を行うために物理スイッチで VLAN を使う場合、すべてのスイッチポートをトランクポートとして設定する必要がある点に注意してください。

現在ネットワーク基盤で使用されていない VLAN の範囲を選択することが重要です。例えば、あなたのクラウドで最大 100 プロジェクトをサポートする必要があると見込んだ場合、 VLAN の範囲としてそれだけの数の値、例えば VLAN 200-299 など、を選びます。 OpenStack およびテナントネットワークを扱うすべての物理ネットワーク基盤でこの VLAN 範囲が利用できる必要があります。

トランクポートは、別のスイッチ間を接続するのに使用されます。各トランクでは、タグを使って、対象の VLAN を識別します。これにより、同じ VLAN のスイッチが通信していることが保証されます。

サブネットと ARP¶

NIC はネットワークホストを表すのに MAC アドレスを使用しますが、 TCP/IP アプリケーションは IP アドレスを使用します。アドレス解決プロトコル (Address Resolution Protocol; ARP) が、IP アドレスを MAC アドレスに変換して、Ethernet と IP の違いを埋めます。

IP アドレスは ネットワーク番号 と ホスト識別子 の 2 つの部分に分解できます。 2 つのホストが同じネットワーク番号を持つ場合、両者は同じ サブネット にあります。 2 つのホストが同じローカルネットワーク上にある場合、両者が通信する手段は直接 Ethernet 経由しかないことを思い出してください。 ARP は同じサブネットのすべてのマシンが同じローカルネットワーク上にあると仮定します。ネットワーク管理者は IP アドレスとネットマスクをホストに割り当てる際に、同じサブネットに属する任意の 2 つのホストが同じローカルネットワーク上にあるように気を付ける必要があります。さもなければ ARP は正しく動作しません。

IP アドレスのネットワーク番号を計算するには、そのアドレスに関連付けられた ネットマスク を知る必要があります。ネットマスクは 32 ビット IP アドレスのうち何ビットがネットワーク番号であるかを示します。

ネットマスクを表現する書式は 2 つあります。

ドット区切りの 4 つの数字
classless inter-domain routing (CIDR)

192.168.1.5 という IP アドレスで、アドレスの最初の 24 ビットがネットワーク番号であるとしましょう。ドット区切りの 4 つの数字の書式の場合、ネットワークは 255.255.255.0 と書けます。 CIDR 表記では IP アドレスとネットマスクの両方が含まれ、この例の場合は 192.168.1.5/24 と書けます。

注釈

マルチキャストアドレスやループバックアドレスを含む CIDR サブネットを作ると、OpenStack 環境では使用できません。例えば、 224.0.0.0/16 や 127.0.1.0/24 を使うサブネットの作成はサポートされません。

サブネットを参照したいが、サブネット内の特定の IP アドレスを参照したくはない場合もあります。広く使われている方法は、ホスト識別子を全部 0 にセットして、サブネットを参照する方法です。例えば、ホストの IP アドレスが 10.10.53.24/16 の場合、サブネットは 10.10.0.0/16 になります。

ARP がどのようにして IP アドレスを MAC アドレスに変換するかを理解するために、次の例を考えてみましょう。ホスト A が IP アドレス 192.168.1.5/24 と MAC アドレス fc:99:47:49:d4:a0 を持っており、 IP アドレスが 192.168.1.7 のホスト B にパケットを送信したいものとします。ネットワーク番号は両方のホストで同じで、ホスト A はホスト B に直接フレームを送信できるものとします。

ホスト A が最初にホスト B と通信する際、宛先の MAC アドレスは不明です。ホスト A はローカルネットワークに ARP リクエストを行います。リクエストは以下のようなメッセージが入ったブロードキャストです。

宛先: 全員 (ff:ff:ff:ff:ff:ff)。私は IP アドレス 192.168.1.7 を持つコンピューターを探している。署名: MAC アドレス fc:99:47:49:d4:a0。

ホスト B は次のような応答を返します。

宛先: fc:99:47:49:d4:a0。私が IP アドレス 192.168.1.7 を持っています。署名: MAC address 54:78:1a:86:00:a5。

それから、ホスト A はホスト B に Ethernet フレームを送信します。

argping コマンドを使うと、自分で ARP 要求を始めることができます。例えば、 IP アドレス 10.30.0.132 に ARP 要求を送信するには:

$ arping 10.30.0.132
ARPING 10.30.0.132 from 10.30.0.131 eth0
Unicast reply from 10.30.0.132 [54:78:1A:86:1C:0B]  0.670ms
Unicast reply from 10.30.0.132 [54:78:1A:86:1C:0B]  0.722ms
Unicast reply from 10.30.0.132 [54:78:1A:86:1C:0B]  0.723ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

ARP 要求の数を抑えるため、オペレーティングシステムは IP アドレスから MAC アドレスへの対応表を保持する ARP キャッシュを管理します。 Linux マシンでは、 arp コマンドで ARP キャッシュの内容を表示できます:

$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.2.3                 ether   52:54:00:12:35:03   C                     eth0
10.0.2.2                 ether   52:54:00:12:35:02   C                     eth0

DHCP¶

ネットワークに接続されたホストは、 Dynamic Host Configuration Protocol (DHCP) を使って、動的に IP アドレスを取得します。 DHCP サーバーは、 IP アドレスを DHCP クライアントとなるネットワークホストに払い出します。

DHCP クライアントは、ポート番号 68 からアドレス 255.255.255.255 のポート番号 67 に対して UDP パケットを送信して、 DHCP サーバーを探します。 255.255.255.255 はローカルネットワークのブロードキャストアドレスです。ローカルネットワークのすべてのホストで、このアドレスに送信された UDP パケットが見えます。しかし、このパケットは他のネットワークには転送されません。したがって、 DHCP サーバーはクライアントと同じローカルネットワークに存在しなければならないということです。さもないと、サーバーはブロードキャストを受信できません。 DHCP サーバーは、ポート番号 67 からクライアントのポート番号 68 に UDP パケットを送信して、応答を行います。やり取りは以下のようになります。

クライアントは discover を送信します (「自分は MAC アドレス 08:00:27:b9:88:74 のクライアントです。 IP アドレスがほしいです」)
サーバーは offer を送信します (「08:00:27:b9:88:74``よ、OK だ。IP アドレス ``10.10.0.112 を提供するよ」)
クライアントは request を送信します (「サーバー 08:00:27:b9:88:74、 IP 10.10.0.112 を使いたい」)
サーバーは acknowledgement を送信します (「08:00:27:b9:88:74``よ、OK だ。 ``10.10.0.112 は君のものだ」)

OpenStack は第三者製のプログラム dnsmasq を使って DHCP サーバーを実装しています。 dnsmasq は syslog に書き込みます。 DHCP 要求と応答を確認できます。:

Apr 23 15:53:46 c100-1 dhcpd: DHCPDISCOVER from 08:00:27:b9:88:74 via eth2
Apr 23 15:53:46 c100-1 dhcpd: DHCPOFFER on 10.10.0.112 to 08:00:27:b9:88:74 via eth2
Apr 23 15:53:48 c100-1 dhcpd: DHCPREQUEST for 10.10.0.112 (10.10.0.131) from 08:00:27:b9:88:74 via eth2
Apr 23 15:53:48 c100-1 dhcpd: DHCPACK on 10.10.0.112 to 08:00:27:b9:88:74 via eth2

インスタンスがネットワークに到達できないという問題を切り分ける際には、このログを確認して、上記の DHCP プロトコルの 4 つのステップが問題のインスタンスに対して実行されているかを検証するとよいでしょう。

IP¶

インターネットプロトコル (IP) は、異なるローカルネットワークに接続されたホスト間でパケットをどのようにルーティングするかを規程しています。 IP は*ルーター* や ゲートウェイ と呼ばれる特別なネットワークホストを利用します。ルーターは、少なくとも 2 つのローカルネットワークに接続されたホストで、 IP パケットをあるローカルネットワークからもう 1 つのローカルネットワークに転送します。ルーターは複数の IP アドレスを持ち、それぞれが各々のネットワークに接続されています。

IP は、ネットワークプロトコルの OSI モデルの第 3 層にあたり、ネットワーク層とも呼ばれます。 IP の話をすると、 レイヤー 3、 L3、ネットワーク層 といった用語をしばしば聞くことでしょう。

ある IP アドレスにパケットを送信するホストは、 ルーティングテーブル に問い合わせを行い、パケットをローカルネットワーク上のどのマシンに送信すべきかを決定します。ルーティングテーブルは、サブネットと各ネットワークにおいて直接接続されているホストの関連付けのリストであり、これらのローカルネットワークにいるルーターのリストでもあります。

Linux マシンでは、以下のどのコマンドを使ってもルーティングテーブルを表示できます:

$ ip route show
$ route -n
$ netstat -rn

ip route show の出力例を以下に示します:

$ ip route show
default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
192.168.27.0/24 dev eth1  proto kernel  scope link  src 192.168.27.100
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1

出力の 1 行目は、デフォルトルートの場所を示しています。デフォルトルートは、他のどのルールにもマッチしなかった場合に使用されるルーティングルールです。デフォルトルートに関連づいているルーター (上記の例では 10.0.2.2) は デフォルトゲートウェイ と呼ばれることもあります。 DHCP サーバーは、通常、クライアントの IP アドレスとネットマスクと一緒に、デフォルトゲートウェイの IP アドレスを DHCP クライアントに通知します。

出力の 2 行目は、 10.0.2.0/24 のサブネットの IP は、ネットワークインターフェース eth0 に関連付いているローカルネットワークにあることを示しています。

出力の 3 行目は、 192.168.27.0/24 のサブネットの IP は、ネットワークインターフェース eth1 に関連付いているローカルネットワークにあることを示しています。

出力の 4 行目は、 192.168.122/24 のサブネットの IP は、ネットワークインターフェース virbr0 に関連付いているローカルネットワークにあることを示しています。

コマンド route -n と netstat -rn の出力は、少し違った形で整形されます。以下の例は、これらのコマンドを使って同じ経路を表示したものです。

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.27.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

ip route get コマンドは、宛先 IP アドレスへの経路を出力します。以下の例では、IP アドレス 10.0.2.14 は eth0 のローカルネットワーク上にあり、直接送信できます:

$ ip route get 10.0.2.14
10.0.2.14 dev eth0  src 10.0.2.15

宛先 IP アドレス 93.184.216.3 は、接続されているローカルネットワーク上にはなく、 10.0.2.2 のデフォルトゲートウェイに転送されます。

$ ip route get 93.184.216.34
93.184.216.34 via 10.0.2.2 dev eth0  src 10.0.2.15

パケットが最終的な宛先に到達するまでに複数のルーターを経由することはよくあることです。 Linux マシンでは、 traceroute や最近では mtr プログラムを使うと、 IP パケットが宛先に到達するまでに通過する各ルーターの IP アドレスが表示されます。

TCP/UDP/ICMP¶

IP ネットワーク上で通信するネットワークソフトウェア・アプリケーションは、 IP の上位層のプロトコルを使用する必要があります。これらのプロトコルは OSI モデルの第 4 層にあたり、 トランスポート層 や レイヤー 4 とも呼ばれます。 Internet Assigned Numbers Authority (IANA) が管理している Protocol Numbers のウェブページを見ると、 IP の上位層に位置するプロトコルと割り当てられている番号の一覧があります。

Transmission Control Protocol (TCP) は、ネットワークアプリケーションで最も広く使用されているレイヤー 4 プロトコルです。 TCP は 接続志向 (connection-oriented) のプロトコルで、クライアントがサーバーに接続するクライアント～サーバーモデルを使用します。ここで、 サーバー というのは接続を受信するアプリケーションのことです。 TCP を使うアプリケーションでの一般的なやり取りは次の通りです。

クライアントがサーバーに接続します。
クライアントとサーバーがデータを交換します。
クライアントかサーバーが接続を終了します。

ネットワークホストでは TCP を使ったアプリケーションが複数動作する場合があるため、 TCP は ポート と呼ばれる番号付け機構を使い、 TCP を使うアプリケーションを一意に特定します。 TCP ポートは 1-65535 の範囲の数値に関連付けられ、あるホストにおいてはある時点では 1 つの TCP ポートに関連付けられるのは 1 つのアプリケーションだけで、この制約はオペレーティングシステムにより適用されます。

TCP サーバーは、ポートを リッスン (listen) します。例えば、 SSH サーバーは通常ポート 22 をリッスンします。サーバーに TCP を使って接続するクライアントは、サーバーホストの IP アドレスとサーバーでの TCP ポートの両方を知っている必要があります。

TCP クライアントアプリケーションのオペレーティングシステムは、自動的にクライアントにポート番号を割り当てます。クライアントはそのポート番号を TCP コネクションが終了するまで所有します。一定時間後にオペレーティングシステムはポート番号を回収します。このようなポートは ephemeral ポート (一時的なポート) と呼ばれます。

IANA は、多くの TCP を使うサービスやその他のポートを使うレイヤー 4 プロトコルに関して registry of port numbers (ポート番号の登録所) を管理しています。 TCP ポート番号の登録は必要ありませんが、ポート番号を登録しておくと他のサービスとの競合を避けることができます。 OpenStack のデプロイメントで使用される様々なサービスが使用するデフォルトのポート番号については OpenStack Configuration Reference の Appendix B. Firewalls and default ports を参照してください。

TCP を使ったアプリケーションを書く際に最も広く使われるアプリケーションプログラミングインターフェース (API) は Berkeley ソケット と呼ばれています。 BSD ソケット とか、単に ソケット と呼ばれることもあります。ソケット API は TCP アプリケーションを書くための ストリーム志向 のインターフェースを公開しています。プログラマーの視点では、 TCP コネクションにデータを送信するのは、ファイルにバイトストリームを書き込むのに似ています。データストリームを IP パケットに分解するのはオペレーティングシステムの TCP/IP 実装の仕事です。失われたパケットを自動的に再送したり、送信したデータが送信側のデータバッファーや受信側のデータバッファー、ネットワーク容量を超えてしまわないようにフロー制御を行うのも、オペレーティングシステムの仕事です。最後に、受信側でパケットを正しい順番で再組み立てしてデータストリームに戻すのも、オペレーティングシステムのしごとです。 TCP はパケットロスを検知して再送を行うので、 信頼性がある プロトコルだと言われます。

User Datagram Protocol (UDP) は、いくつかの有名なネットワークプロトコルで使われている別のレイヤー 4 プロトコルです。 UDP は コネクションレス プロトコルです。 UDP を使って通信する 2 つのアプリケーションは、データのやり取りを行う前にコネクションを確立する必要がありません。オペレーティングシステムは、失われた UDP パケットの再送を行いませんし、検出さえ行いません。オペレーティングシステムは、UDP パケットが送信されたときと同じ順序で受信側のアプリケーションに見えるという保証も行いません。

UDP も TCP と同じくポートという考え方で、同じシステム上で動作するアプリケーションを区別します。ただし、オペレーティングシステムは UDP ポートを TCP ポートとは別ものとして扱います。例えば、あるアプリケーションを TCP ポート 16543 に関連付けて、別のアプリケーションを UDP ポート 16543 に関連付けることができます。

TCP と同様に、ソケット API が UDP を使うアプリケーションを書く際に最も広く使われています。ソケット API は UDP を使うアプリケーションに対して メッセージ志向 インターフェースを提供します。プログラマーは固定サイズのメッセージを送信して、 UDP 上でデータ送信を行います。アプリケーションが失われたパケットの再送や受信パケットの並び替えを必要とする場合、アプリケーションのコードでこれらの機能を実装するのはプログラマーの仕事になります。

DHCP、Domain Name System (DNS)、Network Time Protocol (NTP)、Virtual extensible local area network (VXLAN) が、OpenStack 環境で使用される UDP 系のプロトコルの例です。

UDP は 1対多通信に対応しており、1 つのパケットを複数のホストに送信できます。アプリケーションは、受信者の IP アドレスを特別なブロードキャスト IP アドレス 255.255.255.255 に設定することで、ローカルネットワーク上のすべてのネットワークホストに UDP パケットをブロードキャストできます。また、アプリケーションは IP マルチキャスト を使って UDP パケットを受信者の集合に送ることができます。パケットを受信したい受信側アプリケーションは、UDP ソケットを特別な IP アドレス、つまり、有効なマルチキャストグループアドレスの 1 つにバインドすることで、マルチキャストグループに参加します。受信者のホストは送信者と同じローカルネットワークにある必要はありませんが、途中のルーターが IP マルチキャストルーティングをサポートするように設定されている必要があります。 VXLAN は IP マルチキャストを使用する UDP ベースのプロトコルの 1 例です。

Internet Control Message Protocol (ICMP) は、 IP ネットワーク上で制御メッセージを送信するのに使用されるプロトコルです。例えば、IP パケットを受信したルーターは、宛先アドレスに対応する経路がルーターのルーティングテーブルにない場合は、ICMP パケットを送信元に送ります (ICMP コード 1、宛先ホスト到達不能)。また、 IP パケットが大きすぎて、そのルーターでは処理できない場合にも、ICMP パケットを送信元に送ります (ICMP コード 4、フラグメンテーションが必要だが “don’t fragment” (フラグメント禁止) フラグがセットされている)。

Linux のコマンドラインツール ping や mtr は、 ICMP を使うネットワークユーティリティーの例です。