/24はなぜ254台なのか
一言でいうと
CIDRは、IPアドレスの前のほうの何ビットがネットワークかを書く表記です。この数字1つが、そのネットワークに何台入れるかを決めます。
なぜ必要なのか
VPCを作るときに、10.0.0.0/16を入れるようにという案内にそのまま従えば、さしあたりはうまくいきます。問題は2年後です。
- 別のチームのVPCとアドレスが重なって、ピアリングできません
- オンプレミスのアドレス範囲と重なって、VPN接続ができません
- 買収した会社と重なって、統合が進みません
アドレス範囲は、あとから変えられません。リソースをすべて新しく作って移す必要があります。そのため、最初に計画を立てることの価値が、ほかのどんな決定よりも大きいのです。
ビットで数える方法
IPv4アドレスは32ビットです。/24は、前の24ビットがネットワークという意味で、残りの8ビットがホストの場所です。
10.0.1.0/24
└─ 네트워크 24비트 ─┘└ 호스트 8비트 ┘
호스트 자리 = 32 − 24 = 8비트 → 2^8 = 256개 주소
256個なのに、なぜ254台なのでしょうか。最初のアドレスはネットワークアドレス、最後はブロードキャストアドレスなので、使えません。そのため254です。
クラウドは、ここからさらに引きます。AWSはサブネットごとに5個を予約します(ネットワーク、VPCルーター、DNS、予備、ブロードキャスト)。そのため、/24サブネットの実際に使えるIPは251個です。これを知らずに250台を計画すると、ぎりぎりになります。
| CIDR | 全アドレス | AWSで使える数 |
|---|---|---|
| /28 | 16 | 11 |
| /27 | 32 | 27 |
| /26 | 64 | 59 |
| /24 | 256 | 251 |
| /22 | 1,024 | 1,019 |
| /20 | 4,096 | 4,091 |
| /16 | 65,536 | —(VPCの最大) |
覚えるコツ: /24が256で、プレフィックスが1減るたびに2倍になります。/23 = 512、/22 = 1,024。逆に1増えると半分です。
プライベート範囲
RFC 1918が定めた3つの区間だけを、社内で使います。
| 範囲 | 大きさ | よくある用途 |
|---|---|---|
10.0.0.0/8 |
1,677万 | 大きな組織。クラウドVPCの大半 |
172.16.0.0/12 |
104万 | Dockerの標準ブリッジがここ |
192.168.0.0/16 |
6.5万 | 家庭用ルーター |
172.17.0.0/16がDockerの標準ブリッジの範囲であるという事実が、実務でよく事故を起こします。社内ネットワークを172.17.x.xで使うと、コンテナの中からそのアドレスに行けません。
計画を立てる順序
- 全体の範囲を大きく取る。組織全体に
10.0.0.0/8を割り当てておいて始めます。アドレスはタダです。節約しても得にはなりません。 - 環境ごとに切る。本番
10.0.0.0/12、ステージング10.16.0.0/12、開発10.32.0.0/12のように、重ならないようにします。 - リージョンごとに切る。リージョンごとに別のアドレス範囲にします。あとでリージョン間の接続が楽になります。
- VPCはゆったり取る。
/16が既定値のように使われます。6.5万アドレスあれば、たいてい十分です。 - サブネットは用途別に。下で扱います。
- オンプレミス・パートナーのアドレス範囲をドキュメントに書く。あとで接続するアドレス範囲と重なってはいけません。
重なると何が起きるか
2つのVPCが同じ10.0.0.0/16を使うと、ピアリングは不可能です。ルートテーブルが、同じ宛先を2か所に送れないからです。解決策は、片方を新しいアドレス範囲に移すことだけで、それは事実上の再構築です。
そのため、組織にはIPアドレス範囲台帳が必要です。スプレッドシート1枚で十分で、なければ必ず事故が起きます。
計算を速くする方法と、ミスが出る場所
CIDRの計算は、慣れれば数秒で、慣れていなければ、毎回電卓を探すことになります。覚えることは2行だけです。
アドレス数は2^(32-prefix)です。/24は256個、/23は512個、/25は128個です。プレフィックスが1減ると、2倍になります。
境界は、その大きさの倍数からしか始まりません。/24は第3オクテットがどんな値でもよいのですが、/23は第3オクテットが偶数でなければならず、/22は4の倍数でなければなりません。10.0.3.0/23は誤った表記で、実際には10.0.2.0/23を意味することになります。これが最もよくあるミスです。
| プレフィックス | アドレス数 | 第3オクテットになれる値 |
|---|---|---|
| /24 | 256 | どんな値でも |
| /23 | 512 | 0, 2, 4, … |
| /22 | 1024 | 0, 4, 8, … |
| /20 | 4096 | 0, 16, 32, … |
クラウドは前後でいくつか持っていきます。ほとんどのクラウドが、サブネットごとに5個を予約します(ネットワークアドレス、ゲートウェイ、DNS、予備、ブロードキャスト)。/28は16個なのに、使えるのは11個です。小さなサブネットに細かく切るほど、この損失の割合が大きくなります。
重なるかを見るには、大きいほうのプレフィックスで切ります。10.1.0.0/16と10.1.128.0/17が重なるかは、あとのほうを/16で切って、10.1.0.0が出てくるかを見ればよいです。出てくれば、重なります。
python3 -c "
import ipaddress as ip
a = ip.ip_network('10.1.0.0/16'); b = ip.ip_network('10.1.128.0/17')
print(a.overlaps(b), list(a.subnets(new_prefix=18))[:2])"
計画書に残すのは、アドレス範囲ではなく、ルールです。「どのチームがどのアドレス範囲を使う」という表は、すぐに古くなります。「リージョンごとに/16、AZごとに/20、用途ごとに/24」のように、次の人が自分で選べるルールを書いておけば、表を見なくても衝突しません。
現場での姿
- 2つのチームがそれぞれ
10.0.0.0/16でVPCを作り、1年後に2つのサービスをつなげる必要が出たとき、ピアリングが拒否されました。片方を新しいアドレス範囲で再構築しました。 - 社内ネットワークを
172.17.x.xで使っている会社で、コンテナの中でだけ社内APIが使えませんでした。Dockerの標準ブリッジと重なっていたもので、症状がコンテナでだけ現れたため、原因を見つけるのに数日かかりました。 - サブネットを
/28で細かく切っておいたら、Podが増えてIPが枯渇しました。16個に見えましたが、実際に使えるのは11個でした。 - 買収した会社とアドレス範囲が重なって、システム統合が半年遅れました。スプレッドシート1枚あれば、最初から避けられたことです。
次に見ること
VPCの中をサブネットに分けて、何をどこに置くかを決めます。