IPv4プレフィックス早見表
/24はマスク255.255.255.0、ワイルドカード0.0.0.255、256アドレス、使用可能ホスト254台です。プレフィックス長の範囲を選ぶと1行ずつ表になり、試験対策やアクセスリスト作りに使えます。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 開始プレフィックス
- 24
- 終了プレフィックス
- 30
- 行数
- 7
IPv4の分割は今もプレフィックス長から始まります。/24 は当てずっぽうではなく、マスク 255.255.255.0、8ビットのホスト部、256アドレス、ネットワークとブロードキャストを除いた254の使用可能ホストです。学生、CCNA受験者、ファイアウォール運用者、ACL作成者はその対応を一日に何度も参照し、ホワイトボードで2の累乗をやり直すべきではありません。各行はドット付きサブネットマスク、Cisco風アクセスリストで使う反転ワイルドカードマスク、ホストビットの2乗の総アドレス数、そして現行の /31 ポイントツーポイントと /32 ホストルート規約に従う使用可能ホスト数を示します。
プレフィックス長がマスク・ワイルドカード・ホスト数になる仕組み
IPv4アドレスは32ビットの列です。その横にプレフィックス長 n を書くことは契約です。先頭の n ビットがネットワークを名乗り、残りの32引く n ビットがそのネットワーク内のホストを名乗ります。
サブネットマスクは、その n 個の1のあとに32引く n 個の0を続け、10進4オクテットとして印字したものです。したがって /24 は 255.255.255.0、/16 は 255.255.0.0、/8 は 255.0.0.0、/0 は 0.0.0.0 になります。
ワイルドカードマスクはサブネットマスクのビットごとの補数であり、Cisco IOS のアクセスリスト、一部の OSPF ネットワーク文、驚くほど多くの試験問題がいまだに求める形です。/24 は 0.0.0.255、/16 は 0.0.255.255 になります。ブロック内の総アドレス数はホストビット数の2乗です。
/0 から /30 までの各プレフィックスでは、授業の規則が予約アドレスを2つ(全0のネットワーク識別子と全1のブロードキャスト)引き、使用可能ホスト数を得ます。/31 は RFC 3021 のポイントツーポイント例外で、両方のアドレスが使え、ブロードキャストはありません。/32 はアドレス1つのホストルートです。
サブネットプレフィックス早見表が役立つ場面
認定講座や教室の演習では、今も受験者にプレフィックス長の表を暗記で埋めさせます。/26 が与えられたらマスク、ワイルドカード、ブロックサイズ、使用可能ホスト数を書け、という具合です。ファイアウォールと ACL の作成者は、CIDR 許可リストを古典的な拡張アクセスリストへ移すとき、プレフィックスをワイルドカードマスクへ変換します。
計画範囲の各プレフィックスを出せば、/23 と /25 のひとつずれを避けられます。24から30を貼り付けた来訪者は、継続的インテグレーションの仕事が後で固定するのと同じ数字を見ます。手順書生成は /0 から /32 の全表を内部ウィキへ一度流し込み、/31 の使用可能アドレスが0か2かの議論を止めます。
検証失敗は残高を消費しません。必要なプレフィックス範囲だけを求め、/31 と /32 をここに記した RFC 3021 とホストルートの規約で扱えば、宿題、ACL点検、エッジワーカー向けに再現可能な IPv4 プレフィックス表が得られ、IPアドレス管理の大きな仕組みは不要です。
活用例
CCNAと授業用のプレフィックス表
古典的な /8 から /32 の早見表を記入または採点します。各プレフィックス長のマスク、ワイルドカード、ブロックサイズ、使用可能ホストです。
ACLワイルドカードの計画
許可する CIDR 一覧を拡張アクセスリストへ移すとき、プレフィックス範囲を Cisco 風ワイルドカードマスクへ翻訳します。
手順書と生成ドキュメント
安定した IPv4 プレフィックス表をウィキや CI フィクスチャへ出し、チームが /31 と /32 のホスト数で争うのを止めます。
よくある質問
各 IPv4 プレフィックスの使用可能ホスト数はいくつですか?
プレフィックス 0–30 では使用可能ホストは 2^(32-prefix) から 2 を引いた値(ネットワークとブロードキャスト)です。/31 は使用可能アドレスが 2(RFC 3021)、/32 はアドレス 1 のホストルートです。
サブネットマスクとワイルドカードマスクの違いは何ですか?
サブネットマスクはプレフィックスの1のあとにホスト部の0が続きます(/24 は 255.255.255.0)。ワイルドカードマスクはそのビットごとの補数(0.0.0.255)で、古典的な Cisco ACL が照合に使います。
/0 から /32 の全表を得るにはどうしますか?
応答は IPv4 プレフィックス長ごとに1行、計33行で、/31 ポイントツーポイントと /32 ホストルートの規約も含みます。
192.168.1.0/24 を受けるサブネット計算機と同じですか?
いいえ。 あちらは具体的な1ネットワーク(先頭ホスト、末尾ホスト、ブロードキャスト)を寸法します。こちらは各プレフィックス長をマスク、ワイルドカード、総アドレス、使用可能ホストへ対応づけます。
各ブロックから2つのアドレスを引くのはなぜですか?
すべて0のアドレスがネットワークを表し、すべて1のアドレスがブロードキャストになるためです。/24は256アドレスで使用可能ホストは254台です。例外は両方使える/31と、1アドレスだけの/32です。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/dev/subnet-hosts-table \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"prefix_from":24,"prefix_to":30}'const res = await fetch("https://api.kit.forhosting.com/dev/subnet-hosts-table", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"prefix_from": 24,
"prefix_to": 30
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/subnet-hosts-table",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"prefix_from": 24,
"prefix_to": 30
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/subnet-hosts-table", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"prefix_from":24,"prefix_to":30}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"prefix_from":24,"prefix_to":30}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/subnet-hosts-table", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"prefix_from": 24,
"prefix_to": 30
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.subnet_hosts_table",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
このサブネットプレフィックス早見表は、求められた IPv4 プレフィックス長を prefix_from から prefix_to まで両端込みで参照表にします。
プレフィックス長がマスク・ワイルドカード・ホスト数になる仕組み
この早見表は prefix_from から prefix_to までの各整数プレフィックスを歩き、それら4つの派生列を出すので、学生、ACL作成者、文書生成器は行ごとに2の累乗をやり直さず、1回の応答で完全な参照表を読めます。
入力契約、表の形、/31 と /32 の例外
どちらも0から32までの整数でなければなりません。具体的な CIDR の先頭ホスト・末尾ホスト・ブロードキャストも必要なら、ご自身のネットワークアドレス演算と組み合わせてください。この端点はプレフィックス長の参照であり、1ネットワークの計算機ではありません。必須の整数フィールドを2つ持つ JSON 本体を POST してください。prefix_from は IPv4 プレフィックス長範囲の含む開始、prefix_to は含む終了です。prefix_from には別名 from と min_prefix、prefix_to には別名 to と max_prefix を受け付けます。prefix_from が prefix_to より大きいと、順序規則を示して invalid_input で失敗します。欠落、非整数、真偽値、0から32の外の値も invalid_input で失敗し、課金されません。成功時は本体が prefix_from と prefix_to を返し、row_count を出力行数に設定し、rows をプレフィックス昇順の配列として返します。各行は prefix(整数長)、cidr(/24 のようなスラッシュ形)、ドット付き10進文字列の subnet_mask と wildcard_mask、host_bits(32引く prefix)、2の整数乗の total_addresses、上記の現行規約による usable_hosts を含みます。例: prefix_from が24、prefix_to が30なら7行で、先頭は /24(マスク 255.255.255.0、ワイルドカード 0.0.0.255、256アドレス、254使用可能ホスト)、末尾は /30(マスク 255.255.255.252、ワイルドカード 0.0.0.3、4アドレス、2使用可能ホスト)です。
サブネットプレフィックス早見表が役立つ場面
APIでもあるライブの早見表なら、自動採点は私設の表計算を保守せずにその4セルを採点できます。実装は純粋な parse の tier A のため、成功した呼び出しは毎回公開の基本価格 $0.002 で、モデルトークンも外向きネットワークもありません。
技術的な質問
サブネットプレフィックス早見表の料金はいくらですか。
ブラウザ上の用具は無料です。API 要求は成功した呼び出しごとに前払い KIT 残高の $0.002 を使い、不正な入力は課金されません。