CIDR 表記とサブネットマスク：/8 から /32 の読み方
192.168.1.0/24 のスラッシュの後ろにある数字が数えているのは、アドレスの個数ではなくビット数だ。IPv4 アドレスの 32 ビットのうち何ビットがネットワーク部に属するかを示していて、残った分はそのままホスト部になる。CIDR 表記の中身は、ほぼこの一文に尽きる。
/24 ならホストビットが 8 残るので、ブロックは 2⁸ = 256 アドレスを収容する。/26 なら 6 残るので 64 だ。ホスト側に 1 ビット返すたびにブロックは倍になり、1 ビット取るたびにブロックの数が倍になる。実際に機器へ割り当てられる数は、通常この合計より 2 つ少ない。先頭のアドレスがネットワークを表し、末尾がブロードキャストになるからだ。/26 で使えるホストは 64 ではなく 62 だ。
この「マイナス2」の規則を、意図的に破るプレフィックスが 2 つある。ワイルドカードマスクはサブネットマスクではないのに、互いのフィールドへの貼り間違いは日常的に起きる。プレフィックスの読み方、マスクを手で求める手順、計算が素直でなくなる箇所を順に見ていく。1 つのブロックの答えだけが欲しいならサブネット計算ツールが出力してくれる。この記事は、それを使わずに同じ場所へたどり着くための話だ。
CIDR 表記が示しているもの
サブネットマスク自体も 32 ビットの数値で、アドレスと同じ書式で書かれる。そのビット列は 1 の連続に 0 の連続が続く形になっていて、1 がネットワークビット、0 がホストビットを示す。/26 を省略せずに書き下すと、こうなる。
11111111.11111111.11111111.11000000
255 . 255 . 255 . 192各オクテットを 10 進数に戻すと 255.255.255.192 になる。CIDR 表記は 32 個のビットを全部書く代わりに、先頭にある 1 の個数を数える。192.168.1.0/26 と 192.168.1.0 255.255.255.192 は同じことを 2 つの構文で述べたもので、機器がどちらを求めるかは打ち込むコマンド次第だ。
/8、/16、/24 はオクテットの境界にちょうど乗るので、10 進数で見ても整って見える（255.0.0.0、255.255.0.0、255.255.255.0）。ただし表記そのものはそれを要求していない。/22 や /27 も同じように有効だ。これらはオクテットの途中を切るため、255.255.252.0 のような一見でたらめなマスクになる。2 進数で書いてみるまでは。
クラスがなくなった理由。 1993 年より前は、アドレスの先頭ビットがその大きさを決めていた。クラス A は /8、クラス B は /16、クラス C は /24 で、その中間はなかった。ホストが 300 台ある組織は、クラス B を確保して 65,000 以上のアドレスを無駄にするか、クラス C を 2 つ取って経路を 2 本抱えるかしかなかった。CIDR（RFC 1519、のちに RFC 4632 として改訂）がこの結び付きを断った。プレフィックスがアドレスと一緒に運ばれるので、ブロックは 2 のべき乗であれば何でもよくなる。クラスは今も資格試験や古いドキュメントに出てくるが、クラスフルルーティングそのものは 1993 年以降ずっと過去のものだ。ネットワークの終わりを決めるのは最初のオクテットではなく、マスクだ。
サブネットマスク早見表：/8 から /32 まで
最後の列は意図して置いている。汎用の 2ⁿ − 2 の公式が返す値を示していて、下 2 行を除けば実際の利用可能数と一致する。
| プレフィックス | サブネットマスク | ワイルドカードマスク | 総アドレス数 | 利用可能ホスト数 | 素朴な 2ⁿ − 2 の結果 |
|---|---|---|---|---|---|
| /8 | 255.0.0.0 | 0.255.255.255 | 16777216 | 16777214 | 16777214 |
| /9 | 255.128.0.0 | 0.127.255.255 | 8388608 | 8388606 | 8388606 |
| /10 | 255.192.0.0 | 0.63.255.255 | 4194304 | 4194302 | 4194302 |
| /11 | 255.224.0.0 | 0.31.255.255 | 2097152 | 2097150 | 2097150 |
| /12 | 255.240.0.0 | 0.15.255.255 | 1048576 | 1048574 | 1048574 |
| /13 | 255.248.0.0 | 0.7.255.255 | 524288 | 524286 | 524286 |
| /14 | 255.252.0.0 | 0.3.255.255 | 262144 | 262142 | 262142 |
| /15 | 255.254.0.0 | 0.1.255.255 | 131072 | 131070 | 131070 |
| /16 | 255.255.0.0 | 0.0.255.255 | 65536 | 65534 | 65534 |
| /17 | 255.255.128.0 | 0.0.127.255 | 32768 | 32766 | 32766 |
| /18 | 255.255.192.0 | 0.0.63.255 | 16384 | 16382 | 16382 |
| /19 | 255.255.224.0 | 0.0.31.255 | 8192 | 8190 | 8190 |
| /20 | 255.255.240.0 | 0.0.15.255 | 4096 | 4094 | 4094 |
| /21 | 255.255.248.0 | 0.0.7.255 | 2048 | 2046 | 2046 |
| /22 | 255.255.252.0 | 0.0.3.255 | 1024 | 1022 | 1022 |
| /23 | 255.255.254.0 | 0.0.1.255 | 512 | 510 | 510 |
| /24 | 255.255.255.0 | 0.0.0.255 | 256 | 254 | 254 |
| /25 | 255.255.255.128 | 0.0.0.127 | 128 | 126 | 126 |
| /26 | 255.255.255.192 | 0.0.0.63 | 64 | 62 | 62 |
| /27 | 255.255.255.224 | 0.0.0.31 | 32 | 30 | 30 |
| /28 | 255.255.255.240 | 0.0.0.15 | 16 | 14 | 14 |
| /29 | 255.255.255.248 | 0.0.0.7 | 8 | 6 | 6 |
| /30 | 255.255.255.252 | 0.0.0.3 | 4 | 2 | 2 |
| /31 | 255.255.255.254 | 0.0.0.1 | 2 | 2 | 0 |
| /32 | 255.255.255.255 | 0.0.0.0 | 1 | 1 | −1 |
この表は行と行の関係で読むと覚えやすい。1 行下がるごとにブロックは半分になる。/24 は 256 アドレス、/25 は 128、/26 は 64。ワイルドカードの列はサブネットマスクの全ビットを反転したものなので、255.255.255.192 と 0.0.0.63 はいつも同じ行に並ぶ。太字の 2 行は、標準の公式が現実を説明しなくなる場所で、理由は後の節で扱う。
暗記が要るのはマスク列の最終オクテットの値だけだ。繰り返し現れるからだ。128、192、224、240、248、252、254、255。有効なマスクの末尾に現れうる、自明でないバイト値はこの 8 個しかない。自分で変換して理由を確かめたいなら、基数変換ツールがどれでも 2 進数で表示する。
表を逆に読む：サブネットマスクから CIDR へ
ドット付き 10 進数のマスクが与えられたら、1 のビットを数える。255 のオクテットが 1 つにつき 8 ビット、残りは 255 でも 0 でもない 1 つのオクテットが受け持つ。
| マスクの最終オクテット | 128 | 192 | 224 | 240 | 248 | 252 | 254 | 255 |
|---|---|---|---|---|---|---|---|---|
| 加わるビット数 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
したがって 255.255.255.192 は 8 + 8 + 8 + 2 = /26 だ。255.255.252.0 なら 8 + 8 + 6 + 0 = /22。252 を 2 進数にすると 11111100 で、1 が 6 個並ぶからだ。
ここから 2 つのことが導ける。255 でも 0 でもないオクテットが境界オクテットであり、有効なマスクにそれは 1 つしか存在しえない。もう 1 つ、そのオクテットの値からブロックサイズが直接得られる。
サブネットマスクとネットワークを手で計算する
機械的な手順は 3 ステップで、どのプレフィックスでも通用する。以下の例では 192.168.1.130/26 を使うが、要点はこのアドレスではなく手順のほうだ。
ステップ 1：ブロックサイズを求める
ブロックサイズは 256 − 境界オクテットのマスク値 だ。
/26 のマスクは 255.255.255.192 なので、ブロックサイズは 256 − 192 = 64。このサイズのサブネットは、第 4 オクテットの 64 の倍数の上に並ぶ。0、64、128、192。それ以外の開始点はありえない。
ブロックサイズとアドレス数は同じ数で、ビット数の側からではなくマスクの側からたどり着いただけだ。
ステップ 2：アドレスがどのブロックに入るかを求める
アドレスの境界オクテットをブロックサイズで割り、切り捨てる。
アドレスは 192.168.1.130、ブロックサイズは 64 なので、130 ÷ 64 = 2.03… を切り捨てて 2。掛け戻すと 2 × 64 = 128。このアドレスは 128 から始まるブロックに入る。
間違いのほとんどはここで起き、しかも常に同じ方向だ。渡されたアドレスがブロックの先頭だと思い込むのだが、たいていそうではない。192.168.1.130 は、その /24 の中の 3 番目の /26 に属するホストアドレスだ。
ステップ 3：ネットワーク、ブロードキャスト、最初と最後のホスト
ブロックの先頭がネットワークアドレスだ。ブロードキャストはブロック先頭にブロックサイズを足して 1 を引いたもの。その間にあるものはすべて割り当て可能だ。
Network 192.168.1.128
Broadcast 192.168.1.191
Usable 192.168.1.129 - 192.168.1.190
Usable 62 (of 64 total)
Netmask 255.255.255.192
Wildcard 0.0.0.63ブロードキャストは 128 + 64 − 1 = 191。最初のホストはネットワーク + 1、最後のホストはブロードキャスト − 1、利用可能数は 64 − 2 = 62 で、早見表の /26 の行と一致する。
覚えやすい形にまとめると、ブロックサイズは 256 からマスクのオクテットを引いた値。アドレスをその倍数に切り下げたものがネットワークで、次のブロック開始位置から 1 を引いたものがブロードキャスト。
この方法は第 4 オクテット専用ではない。/22 ならマスクは 255.255.252.0 なので境界オクテットは第 3 で、そこでのブロックサイズは 256 − 252 = 4 だ。つまりブロックは 10.0.0.0、10.0.4.0、10.0.8.0 から始まり、10.0.0.0/22 はブロードキャスト 10.0.3.255 まで伸びて、利用可能アドレスは 10.0.0.1 から 10.0.3.254 になる。1 つのブロードキャストドメインに、連続した /24 が 4 つ入っている形だ。同じ 3 ステップで、オクテットが違うだけだ。
2 進数と 10 進数の行き来で手が止まるなら、基数変換のガイドが変換そのものをこの記事より詳しく説明している。
頭の中ではなくスクリプトで検算したい場合は、Python の標準ライブラリだけで足りる。
import ipaddress
net = ipaddress.ip_network("192.168.1.130/26", strict=False)
print(net) # 192.168.1.128/26
print(net.network_address) # 192.168.1.128
print(net.broadcast_address) # 192.168.1.191
print(net.netmask) # 255.255.255.192
print(net.hostmask) # 0.0.0.63
print(net.num_addresses) # 64
print(len(list(net.hosts()))) # 62strict=False があるおかげで、ネットワークアドレスではなくホストアドレスを渡せる。既定の strict=True のままだと、同じ呼び出しは ValueError を送出する。
「マイナス2」の規則が成り立たなくなるところ
この引き算には理由がある。通常のサブネットでは、ホスト部が全 0 のパターンがネットワーク自身を表し、全 1 のパターンがダイレクテッドブロードキャストアドレスになる。どちらもインターフェイスには設定できないので、2ⁿ 個のアドレスを持つブロックがホストに提供できるのは 2ⁿ − 2 個だ。/24 が 254、/26 が 62 になるのはこのためだ。
この理由はそのまま限界でもあって、ブロックが小さすぎて予約された 2 つのアドレスを収容できないときは、引くこと自体が意味を失う。
/31 はアドレス 2 個、利用可能ホストも 2 個だ。 RFC 3021 はポイントツーポイントリンク向けに /31 を定義している。この種のリンクには端点がちょうど 2 つあるだけで共有セグメントが存在しないため、ブロードキャストアドレスにやらせる仕事もなければ、ネットワークアドレスが識別すべき対象もない。2 つのアドレスは両端にそのまま渡る。ここに 2ⁿ − 2 を当てはめると 0 が返るが、これは前提の合わないトポロジーに算術を当てはめた結果にすぎない。ただし条件は厳密で、/31 が有効なのは本当にポイントツーポイントのインターフェイスに限られる。マルチアクセスの LAN セグメントには依然として /30 かそれより短いプレフィックスが必要だし、Windows は NIC に /31 を受け付けない。
/32 はアドレス 1 個、利用可能ホストも 1 個だ。 これは単一ホストのルートで、ループバックインターフェイス、スタティックルート、エニーキャストアドレス、単一アドレスのファイアウォールルールなどに使われる。ブロードキャストアドレスが存在しないので、公式の − 2 は −1 を返してしまう。
Python も /31 と /32 を同じように扱う。
import ipaddress
p2p = ipaddress.ip_network("203.0.113.4/31")
print([str(h) for h in p2p.hosts()]) # ['203.0.113.4', '203.0.113.5']
host = ipaddress.ip_network("10.0.0.1/32")
print([str(h) for h in host.hosts()]) # ['10.0.0.1']覚え方としては「例外が 2 つある」よりも、「引き算は特定の 2 つのアドレスを取り除くものだから、取り除く前にそれらが存在するか確かめる」のほうが使える。/31 と /32 にはブロードキャストアドレスがそもそも存在しないので、取り除かれるものは何もない。
総数、利用可能数、サブネット数は別々の 3 つの数
この 3 つは絶えず取り違えられる。どれも同じプレフィックスから導かれる 2 のべき乗なので、無理もない。
- 総アドレス数 は /p に対して
2^(32 − p)。/26 なら 64。 - 利用可能ホスト数 はそこから 2 を引いた数、ただし /31 と /32 は例外だ。/26 なら 62。
- サブネット数 は、親の /p を子の /q に分割したときの
2^(q − p)。/24 を /26 に分けると 2 ビット借りるので2² = 4サブネットだ。
3 つは別の問いに答えているので、「/26 なら 4 だ」という言い方は、問いが /24 の分割についてだった場合にだけ正しくなる。分割にはアドレスの代償も伴う。子サブネットはそれぞれ自分のネットワークとブロードキャストの組を予約するからだ。/24 から切り出した 4 つの /26 が持つ利用可能アドレスは 4 × 62 = 248 で、親の 254 に対して 6 個が分割そのものに費やされる。
ワイルドカードマスクとサブネットマスク：どのコマンドがどちらを求めるか
ワイルドカードマスクはサブネットマスクのビット単位の反転だ。サブネットマスクが 1 の位置で、ワイルドカードは 0 になる。早見表の /26 の行を見るとよい。マスクは 255.255.255.192、ワイルドカードは 0.0.0.63。片方の全ビットを反転すればもう片方になるので、この 2 つは常に対で現れる。
2 つは逆の意味で使われる。覚えておくべきはそこだ。サブネットマスクはビット単位の AND で適用されるので、1 のビットは「このビットはネットワークの一部だ」を意味する。ワイルドカードはマッチのフィルタなので、0 のビットが「このビットは一致しなければならない」、1 のビットが「気にしない」を意味する。土台の演算は同じで、極性だけが逆だ。ビットレベルの仕組みが曖昧なら、ビット演算のガイドが AND、OR、NOT をより一般的な形で説明している。
どちらを求めるかは好みの問題ではなく、コマンドごとに決まっている。ブロック 192.168.1.128/26 の場合はこうなる。
! wants the subnet mask
ip address 192.168.1.129 255.255.255.192
! wants the wildcard mask
access-list 10 permit 192.168.1.128 0.0.0.63
network 192.168.1.128 0.0.0.63 area 0! Cisco ASA — wants the subnet mask, unlike IOS ACLs
access-list OUT permit ip 192.168.1.128 255.255.255.192 any# Linux iproute2 — takes the prefix directly
ip addr add 192.168.1.129/26 dev eth0Cisco IOS の ACL と OSPF の network 文はワイルドカードマスクを取り、ASA のほうはサブネットマスクを取る。同じ製品ファミリーの中で 1 つのベンダーが 2 つの流儀を抱えているわけで、コピー&ペーストの失敗はこの周辺でよく起きる。他のプラットフォームにもそれぞれの流儀があるので、見慣れないフィールドに値を貼る前に、そのフィールドがどちらを期待しているかを確認しよう。
危険なのは失敗の現れ方だ。255.255.255.192 を IOS の ACL に貼ると、ルーターはそれをワイルドカードとして読む。全 1 のオクテットが 3 つは「気にしない」を意味するので、最初の 3 オクテットはまったく照合されなくなり、ルールは想定したブロックのはるか外側にまで届く。構文エラーも出ず、ログも出ず、ただスコープの違う permit 文が残る。逆の間違いのほうは、まだ気づける見込みがある。0.0.0.63 は有効なサブネットマスクではないからだ。先頭に 1 の連続がない。あるプラットフォームがそれを拒否するのか黙って受け入れるのかは、本番で知るようなことではない。
ACL のワイルドカードには穴があってよく、サブネットマスクには許されない理由
サブネットマスクは 1 の連続に 0 が続く、途切れのない形でなければならない。これは慣習ではなく、AND 演算がアドレスをちょうど 2 つの部分に分けられる根拠そのものだ。255.0.255.0 のような値は途中に穴があり、一貫した境界を何も表さないので、機器は拒否する。Python も同じだ。
import ipaddress
ipaddress.ip_network("10.0.0.0/255.0.255.0")
# ValueError: '10.0.0.0/255.0.255.0' does not appear to be an IPv4 or IPv6 network有効なマスクは /0 から /32 までの 33 個しかない。それ以外はタイプミスだ。
ACL のワイルドカードにはそうした制約がない。アドレスをネットワーク部とホスト部に分けているわけではないからだ。ビットごとのマッチフィルタなので穴は合法で、ときには役にも立つ。たとえば穴のあるワイルドカード 1 つで、ある範囲の奇数アドレスだけをまとめて照合できる。この表現力の違いこそ、2 つの値を入れ替えられない理由だ。両者は同じ種類のものではなく、ドット付き 10 進数で書いたときにたまたま似て見えるだけだ。
プライベート、CGNAT、その他の予約範囲
プレフィックスはブロックの大きさを教えてくれる。そのブロックを自分で使ってよいかどうかを決めるのは、アドレスがどの範囲にあるかだ。
| ブロック | 範囲 | 予約元 |
|---|---|---|
| 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | RFC 1918 プライベート |
| 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | RFC 1918 プライベート |
| 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | RFC 1918 プライベート |
| 100.64.0.0/10 | 100.64.0.0 – 100.127.255.255 | RFC 6598 キャリアグレード NAT |
| 169.254.0.0/16 | 169.254.0.0 – 169.254.255.255 | RFC 3927 リンクローカル |
| 255.255.255.255/32 | 単一アドレス | リミテッドブロードキャスト |
RFC 1918 の範囲は公衆インターネット上で決してルーティングされない。だからこそ、そこから安全に割り当てられる。残る 3 つは別の理由で登場する。
100.64.0.0/10 はキャリアグレード NAT の空間だ。ISP がこの範囲のアドレスを渡してきたなら、その回線は相手の NAT の内側にあり、トンネルなしに外から届く接続はない。RFC 1918 の意味でのプライベート空間ではなく、社内の設計に使ってよいものでもない。ルーターの向こう側でプロバイダーがすでに使っている可能性があるからだ。
169.254.0.0/16 はリンクローカルだ。DHCP が失敗したときにホストが自分で 1 つ割り当てるので、インターフェイスに 169.254 のアドレスが見えたら、それは設定ではなく診断結果だ。DHCP の要求に誰も応答しなかった、ということだ。ここ宛てのトラフィックがルーターを越えることはない。
ドキュメントや手順書の例のために、RFC 5737 は 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24 を予約している。コピー&ペーストされた例が実在のホストを指してしまわないようにするためだ。
172.16.0.0/12 は /16 が 16 個であって、1 個ではない
予約範囲の中でいちばん取り違えられるのがこれで、原因はプレフィックスにある。/12 は第 2 オクテットから 4 ビット借りるので、ブロックは 172.16.0.0 から 172.31.255.255 まで広がる。連続する 16 個の /16 であって、172.16.x.x だけではない。
影響は両方向に出る。172.20.5.1 のようなアドレスは、172.16 で始まっていなくても範囲の内側に余裕で収まるプライベートアドレスだ。逆に 172.15.x.x と 172.32.x.x は他人に属するパブリックアドレスなので、172.0.0.0/8 に対して書かれたファイアウォールルールや「内部範囲なら信頼する」という判定は、インターネットの広い一部を黙って信頼してしまう。
こうした境界は早見表の算術で確かめられる。/12 のアドレス数は 2^(32−12)、第 2 オクテットは 256 − 240 = 16 刻みで動き、16 + 16 = 32 なので、ブロックは 172.32.0.0 の直前で終わる。
VLSM：1 つのブロックを不均等なサブネットに分ける
同じ大きさのサブネットは作るのが簡単で、たいてい間違っている。192.168.1.0/24 を 1 つ渡された支社に、共通点のない 4 つのセグメントが必要になることがある。ワークステーション 100 台、電話 50 台、サーバー 12 台、それに管理インターフェイスが数個。この /24 を同じ大きさの /26 4 つに割ると、ワークステーションのセグメントは 62 ホストで溢れ、管理セグメントは 10 台のために 62 アドレスを抱えることになる。
可変長サブネットマスク（VLSM）とは、各セグメントに実際に必要なプレフィックスを与えることだ。同じ /24 を /25 1 つ、/26 1 つ、/28 2 つに切り分けるとこうなる。
大きいものから小さいものへ割り当てる。 各ブロックは自分のサイズの倍数の位置から始まらなければならないので、いちばん大きいブロックから先に置く。
| セグメント | 必要ホスト数 | プレフィックス | ネットワーク | 利用可能範囲 | ブロードキャスト | サブネットマスク |
|---|---|---|---|---|---|---|
| ワークステーション | 100 | /25 | 192.168.1.0 | 192.168.1.1 – 192.168.1.126 | 192.168.1.127 | 255.255.255.128 |
| 音声 | 50 | /26 | 192.168.1.128 | 192.168.1.129 – 192.168.1.190 | 192.168.1.191 | 255.255.255.192 |
| サーバー | 12 | /28 | 192.168.1.192 | 192.168.1.193 – 192.168.1.206 | 192.168.1.207 | 255.255.255.240 |
| 管理 | 10 | /28 | 192.168.1.208 | 192.168.1.209 – 192.168.1.222 | 192.168.1.223 | 255.255.255.240 |
| 未割り当て | — | /27 | 192.168.1.224 | 192.168.1.225 – 192.168.1.254 | 192.168.1.255 | 255.255.255.224 |
3 ステップの方法でたどってみよう。
- /25 のブロックサイズは
256 − 128 = 128なので 0 から始まり、ブロードキャストは0 + 128 − 1 = 127。利用可能は 1 から 126 で 126 アドレス、ワークステーション 100 台に余裕がある。早見表の /25 の行も一致する。総数 128、利用可能 126。 - 次の空きアドレスは 128。/26 のブロックサイズは 64 で、128 は 64 の倍数なので収まる。ネットワークは 192.168.1.128、ブロードキャストは
128 + 64 − 1 = 191、利用可能は 129 から 190。電話 50 台に対して利用可能 62 だ。早見表の /26 の行は総数 64、利用可能 62。 - 次の空きは 192。/28 のブロックサイズは 16 で
192 = 16 × 12なので収まる。ネットワークは 192.168.1.192、ブロードキャストは 207、利用可能は 193 から 206 で、サーバー 12 台に 14 アドレス。早見表の /28 の行は総数 16、利用可能 14。 - 次の空きは 208 で
208 = 16 × 13なので、2 つ目の /28 は 192.168.1.208 に置かれ、ブロードキャストは 223、利用可能は 209 から 222 になる。
ここまでで 256 アドレスのうち 128 + 64 + 16 + 16 = 224 を使い、192.168.1.224 から 192.168.1.255 が残る。この 32 アドレスはちょうど整列した /27 1 つ分で、後からポイントツーポイントリンクを取るならここからだ。中に /31 が 16 個収まり、ルーター間リンク 1 本につき 1 つ使える。
なぜ大きい順なのか、そうしなかったときの代償。 2 つの /28 を先頭側に置いたとしよう。192.168.1.0/28 と 192.168.1.16/28 だ。次の空きアドレスは 192.168.1.32 だが、/25 は 128 の倍数から始まらなければならないのでそこには置けない。192.168.1.128 まで飛ぶことになる。32 から 127 までのアドレスは失われるわけではないものの、整列したより小さい断片としてしか使えない。192.168.1.32 の /27 と 192.168.1.64 の /26 だ。結果として、余りは上端の連続した 1 ブロックに収まらず散らばる。要求にセグメントをもう 1 つ足せば、この並べ方では収まらなくなる。
サイズ順に並べればそれを避けられる。あるブロックを置いた後、次の空きアドレスはそのブロックサイズの倍数になる。そして大きい 2 のべき乗の倍数は、より小さいすべての 2 のべき乗の倍数でもある。だから後続の小さいブロックは、前のブロックが終わったところにそのまま整列し、アドレスを飛ばす必要がない。この種の計画をスイッチに投入する前に、サブネット計算ツールの分割表に通したほうが、各セグメントの整列を手で確かめるより速い。
本番まで生き残る 5 つの間違い
1. 打ち込んだアドレスをネットワークアドレスとして扱う
症状： ファイアウォールルールが何にもマッチしない、あるいは経路がセグメントの意図しない側を覆っている。
原因： 192.168.1.130/26 を、ネットワーク 192.168.1.0、ブロードキャスト 192.168.1.255 と読んでしまった。これは /24 の境界で、10 進数で眺めているとまずそこが目に入るからだ。
対処： ステップ 2 を適用する。ブロックサイズ 64、130 ÷ 64 を切り捨てて 2、よってネットワークは 2 × 64 = 128。ブロックは 192.168.1.128 から 192.168.1.191 で、192.168.1.0 はまったく別のサブネットだ。プレフィックスが /24 より長いときは、渡されたアドレスはマスクを掛けるまでホストアドレスだと思っておこう。
2. /31 に 2ⁿ − 2 を当てはめる
症状： リンクが上がってトラフィックも流れているのに、IPAM ツールや表計算がそのポイントツーポイントリンクの利用可能ホストを 0 と報告する。 原因： 「マイナス2」の規則は、引くべきネットワークアドレスとブロードキャストアドレスが存在することを前提にしている。/31 には存在しない。 対処： /31 と /32 は異常値ではなく、公式の境界条件として扱う。RFC 3021 は /31 の両方のアドレスを割り当て可能にしていて、/32 はアドレス 1 個の単一ホストルートだ。0 や −1 を報告するものは、公式を適用範囲の外で使っている。例外が成り立つのは本当にポイントツーポイントのリンクだけなので、まず該当インターフェイスの /31 サポートを確認しよう。
3. 172.16.0.0/12 を 172.16.x.x だけだと思う
症状： ある拠点から社内サービスに到達できない、あるいは「プライベート範囲を全部ブロック」のルールが漏れる。 原因： /12 を /16 のつもりで読んでいた。 対処： 範囲は 172.16.0.0 から 172.31.255.255 だ。ACL や許可リストは、オクテットのパターンではなくプレフィックス 172.16.0.0/12 に対して書き、172.15.x.x と 172.32.x.x はその外側の公衆インターネットにあることを覚えておこう。手で照合するなら、境界オクテットは第 2 オクテットで、16 刻みで動く。
4. サブネットマスクを求めるフィールドにワイルドカードを貼る
症状： ACL が意図よりはるかに広く、あるいははるかに狭く許可していて、設定のどこを見ても間違って見えない。 原因： IOS の ACL と OSPF の network 文はワイルドカードを取り、ASA はサブネットマスクを取る。しかも 0.0.0.63 と 255.255.255.192 は、ぱっと見では見分けがつかない。 対処： 貼った後ではなく貼る前にフィールドを確認する。見分け方は単純で、/8 以上の長さのプレフィックスなら、サブネットマスクは 255 で始まり、ワイルドカードは 0 で始まる。ACL や OSPF の network 文に置かれた値が 255 で始まっていたら、それはワイルドカードのフィールドに入ったサブネットマスクだ。
5. 連続していないマスクを書く、あるいは意図せず生成する
症状： 機器が設定行を拒否する、あるいは自作スクリプトが、一見正しそうなマスクを吐く。 原因： 255.0.255.0 のような値は有効なサブネットマスクではない。穴がある。スクリプト側はもっと分かりにくく、JavaScript のシフト演算子は右オペランドを 32 で割った剰余として扱うため、範囲外のプレフィックスは例外を投げる代わりに、もっともらしく見える誤ったマスクを黙って作る（33 は /1 に、−1 は /31 になる）。 対処： シフトの前にプレフィックスの範囲を検証し、1 の連続に 0 が続く形になっていないマスクは拒否する。どちらの失敗も無言で起きるので、ここでは入力が不正なら例外を投げるライブラリのほうが、推測するライブラリより頼りになる。
FAQ
サブネットと VLAN の違いは何か？
VLAN はスイッチ上で設定されるレイヤー 2 のブロードキャストドメインで、サブネットはレイヤー 3 のアドレス範囲だ。通常は 1 対 1 に対応させるが、それを強制するものは何もない。1 つの VLAN に 2 つのサブネットを載せることも、1 つの VLAN を拠点間でトランクすることもできる。サブネットを付け替えても、VLAN ID は変わらない。
/24 を /26 に分割するとサブネットはいくつになるか？
4 つだ。個数は借りたビット数の 2 のべき乗で、/26 は /24 より 2 ビット長いので 2² = 4 サブネット、それぞれ 64 アドレスだ。子サブネットはそれぞれ自分のネットワークアドレスとブロードキャストアドレスを予約するので、4 つの /26 が持つ利用可能アドレスは 248 で、親の /24 の 254 に対して少なくなる。
CIDR 表記は IPv6 でも同じように働くのか？
スラッシュが先頭のネットワークビットを数えることは変わらないので、/64 は 128 ビットのうち 64 ビットがネットワーク部という意味だ。引き継がれないのは「マイナス2」の規則だ。IPv6 にはブロードキャストアドレスがないので、総数から引かれるものはない。上の早見表と、その背後にある計算ツールは IPv4 専用だ。
0.0.0.0/0 は何を意味するか？
ネットワークビットが 0 なので、すべての IPv4 アドレスにマッチする。ルーティングテーブルではデフォルトルートで、より具体的なプレフィックスがマッチしないときに使われる。バインドアドレスとしては「すべてのインターフェイス」を意味し、0.0.0.0 で待ち受けるサービスが、そのマシンの接続しているあらゆるネットワークから到達可能になるのはこのためだ。
同じネットワーク上の 2 つのサブネットが重なるとどうなるか？
ルーターはより具体的な経路を選ぶ。転送は常に最長一致のプレフィックスを優先するからだ。一方、重なりの中にいるホストは、どの宛先がローカルかについて意見が食い違う。症状は部分的だ。動く宛先と動かない宛先があり、どちらになるかは試す場所によって変わる。
クラス A・B・C はなぜ CIDR に置き換えられたのか？
クラスが提供できる大きさが /8、/16、/24 の 3 種類しかなかったからだ。300 アドレスが必要な組織は、クラス B を取ってほとんどを無駄にするか、クラス C の経路を 2 本運用するしかなかった。CIDR はプレフィックスの長さを自由にし、アドレス枯渇を遅らせ、事業者が多数の顧客ブロックを 1 本の経路に集約できるようにした。
192.168.0.0/16 のようなプライベート範囲は、好きにサブネット分割してよいのか？
できる。RFC 1918 の空間はどんなプレフィックス長で分けても自由で、ネットワークの外から見えることはない。制約は内側にある。後でピアリングする相手のネットワークやクラウドの VPC とアドレスが重なると、ほどくのに高くつく。だからこそ、家庭用ルーターがどれも使っているブロックは計画上避けられがちだ。
要点。 プレフィックスはネットワークビットを数えていて、ブロックサイズは 256 − 境界オクテットのマスク値。アドレスをブロックサイズの倍数に切り下げたものがネットワークで、そこにブロックサイズから 1 を引いた値を足したものがブロードキャスト。予約された 2 つ分を引くのは、/31 や /32 が引く理由をすでに取り去っていない場合に限る。ワイルドカードとサブネットマスクは形で見分ける。大きいブロックは小さいブロックより先に割り当てる。
手で一通りやってみれば、これらはどれもツールなしで済むようになる。ルーターに届く前に計画を検算したいとき、あるいはブロックの 2 進数の境界を一目で読みたいときは、サブネット計算ツールがブラウザー内でローカルに計算する。