3-1 IP アドレッシング詳細

1. 1-6 からの踏み込み地点

第 3 章は L3 編です。1-6「IP アドレスとサブネットマスク」で 32 ビット構造、ネットワーク部とホスト部、サブネットマスクと CIDR (Classless Inter-Domain Routing) 表記、クラスフルからクラスレスへの移行、プライベートアドレスまでを整理しました。本節はその先、設計と実装で実際に手を動かす領域に入ります。

本節で扱うのは VLSM (Variable Length Subnet Mask)、CIDR / 経路集約 (Supernetting)、/31 リンク (RFC 3021)、Router-ID 用の /32 Loopback の 4 つです。最後に CSR1000v 2 台で /31 を実機に張り、IOS-XE が直結ルートをどう表示するか、Loopback 間で ping が届くのかを確かめます。

直結ルートだけで構成された世界がどこまで届き、どこから届かなくなるかを実機で押さえることで、次節 3-2 で扱う静的ルートや動的ルーティングプロトコルが何を解決しに来ているのかが自然に見えてきます。

2. クラスフルアドレッシングの限界

1-6 で扱ったとおり、IPv4 (Internet Protocol version 4) の運用初期は クラスフルアドレッシング で割り当てが行われていました。先頭ビットのパターンから A/B/C/D/E の 5 クラスに分け、A は /8、B は /16、C は /24 と ネットワーク部の境界が 8 ビット刻みで固定 されていました。割り当てる側は組織規模を見て「これはクラス B」と決めるだけで、サブネットマスクを設計するという発想自体がありません。

クラスフルの不経済は容易に発生します。500 台のホストを持つ組織に /24（254 ホスト）では足りず、/16（65534 ホスト）を割り当てると 6 万 5 千個のアドレスを一括消費します。実際に使うのは 500 台分だけで、残りはクラス境界に縛られて他に転用できません。組織単位で全世界に積み上がった結果が、1990 年代前半のアドレス枯渇危機です。

同時期に インターネットバックボーンのルーティングテーブル肥大化 も進行していました。クラス C を細切れに配布した結果、コアルーターが抱えるプレフィックス数が増え続け、このまま放置すると数年でルーター能力を超えるという予測が立てられ、メモリと検索コストが課題になっていました（経路表が数十万〜100 万本級に達するのは後年のことで、CIDR はその増加カーブを折る目的で導入されました）。

これらを同時に解決する枠組みとして 1993 年に標準化されたのが CIDR (RFC 1518/1519) です。CIDR はクラス境界を捨て、サブネットマスクを 任意のビット位置に置ける 設計に切り替えました。500 台の組織には /23（510 ホスト）、両端 2 台だけの P2P (Point-to-Point) リンクには /30（4 アドレス消費・利用可能ホスト 2 個）、というように必要量に応じた粒度で割り当てられます。同時に、配下の細かいプレフィックスを上位ルーターで 1 本に束ねる 経路集約 が現実的に成立し、コアのルーティングテーブルを抑えられるようになりました。

3. VLSM: 同一プレフィックスを必要量に応じて細切れにする

VLSM では、親プレフィックスの内側で サブネットごとに異なるマスク長 を設定できます。これに対して FLSM (Fixed Length Subnet Mask) は全サブネットで同一のマスク長を使う方式で、192.168.10.0/24 を 4 分割するなら全部 /26、8 分割するなら全部 /27 となります。

FLSM では、50 台 LAN (Local Area Network)・20 台 LAN・P2P 区間が混在するときに一番大きい 50 台に合わせて /26（62 ホスト）を全サブネットに当てることになります。その結果、P2P 区間で 62 個分のアドレスを抱えながら実際に使うのは 2 個だけ、という浪費が生まれます。

VLSM は親プレフィックス内でマスク長を切り替えられます。192.168.10.0/24 を「50 台 LAN × 1 + 20 台 LAN × 2 + 6 台 LAN × 1」に分割した例は以下のとおりです。

分割は 大きい順に切り出す のが原則です。最初に 50 台 LAN を /26 で取り、20 台 LAN を /27 で 2 本、最後に 6 台 LAN を /29 で取ります。逆順だと後から大きい区画を取りたいときに連続領域が残っていない事故が起きます。

境界計算はビット演算ですが、慣れないうちは off-by-one を踏みやすい部分です。/26 は +64 番地刻み、/27 は +32、/28 は +16、/29 は +8 で次のサブネットに進みます。192.168.10.64/27 の次が .96 になるのは、.64 から 32 個進んで最後が .95、その次が .96 となるためです。落とし穴の節で再度触れます。

4. CIDR と経路集約 (Supernetting)

VLSM が親プレフィックスを小さく割る方向の操作であるのに対し、経路集約 (Route Summarization / Supernetting) は複数の隣接プレフィックスを 1 本に束ねる方向の操作です。両者は CIDR の表と裏の関係にあります。

典型例として、ある拠点ルーターが配下に次の 4 本の /24 を持っているとします。

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 192.168.3.0/24

これらの上位ビットを 2 進で並べると、先頭 22 ビットが共通します。したがって個別の 4 本を上流に広告する必要はなく、192.168.0.0/22 という 1 本に束ねて広告できます。上流から見れば、このプレフィックス宛のパケットは拠点ルーターに送れば届くという情報だけが必要で、内訳は知る必要がありません。

集約の利点は、コアのルーティングテーブル削減、配下リンクのフラップ隔離、運用上の見通しの良さの 3 点に整理できます。配下のいずれかのリンクが上下しても集約された 1 本の経路は安定したままなので、上流側にイベントが伝播しない点が特に効きます。

集約には罠もあります。集約範囲の中に 実在しないアドレス が含まれていると、その宛先のパケットが拠点ルーターまで吸い込まれて行き場を失います。たとえば /22 を広告しながら配下に 192.168.2.0/24 が実在しない場合、192.168.2.5 宛のパケットは拠点まで届いて drop されます（ブラックホール化）。集約は実在する連続領域だけを束ねる、というのが運用上の原則です。

5. /31 P2P リンクの実機挙動

/31 リンク (RFC 3021) の実機検証に入ります。検証は CML (Cisco Modeling Labs) 上に CSR1000v 2 台を立てた構成で行います。

R1 と R2 の CSR1000v 2 台を GigabitEthernet2 同士で直結し、各 GigabitEthernet1 を管理ネットワーク (172.16.1.0/24) に繋いで Mgmt-vrf で外部 SSH (Secure Shell) を受けます。各ルーターには Router-ID 用の Loopback0 を /32 で 1 つずつ載せます。

アドレス計画は以下のとおりです。

P2P で使う 192.0.2.0/24 は RFC 5737 で文書化用に予約された範囲であり、インターネットに広告されない教材向きのアドレスです。

R1/R2 の day0 config は対称形でホスト名と IP アドレスのみ異なります。

hostname R1
no ip domain-lookup
ip domain name lab.local
!
username admin privilege 15 secret 0 C1sc012345
enable secret 0 C1sc012345
!
ip ssh version 2
crypto key generate rsa modulus 2048
!
vrf definition Mgmt-vrf
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet1
 description Management to lab gateway
 vrf forwarding Mgmt-vrf
 ip address 172.16.1.211 255.255.255.0
 no shutdown
!
interface GigabitEthernet2
 description P2P link
 ip address 192.0.2.0 255.255.255.254
 no shutdown
!
interface Loopback0
 description Router-ID
 ip address 10.0.1.1 255.255.255.255
!
ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 172.16.1.1
!
line vty 0 4
 transport input ssh
 login local
!
end

hostname R2
no ip domain-lookup
ip domain name lab.local
!
username admin privilege 15 secret 0 C1sc012345
enable secret 0 C1sc012345
!
ip ssh version 2
crypto key generate rsa modulus 2048
!
vrf definition Mgmt-vrf
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet1
 description Management to lab gateway
 vrf forwarding Mgmt-vrf
 ip address 172.16.1.212 255.255.255.0
 no shutdown
!
interface GigabitEthernet2
 description P2P link
 ip address 192.0.2.1 255.255.255.254
 no shutdown
!
interface Loopback0
 description Router-ID
 ip address 10.0.2.1 255.255.255.255
!
ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 172.16.1.1
!
line vty 0 4
 transport input ssh
 login local
!
end

P2P リンクへの設定は ip address 192.0.2.0 255.255.255.254 で、マスク 255.255.255.254 が /31 に対応します。

リンクが up になった状態で R1 の show ip interface brief を見ます。

R1#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       172.16.1.211    YES TFTP   up                    up      
GigabitEthernet2       192.0.2.0       YES TFTP   up                    up      
Loopback0              10.0.1.1        YES TFTP   up                    up

G2 の IP-Address が 192.0.2.0 で表示されています。クラスフルの感覚では .0 で終わるアドレスはネットワークアドレスとして予約されていましたが、/31 ではホスト部が 1 ビットしかないので .0 と .1 の両方をホストアドレスに割り当てます。それぞれ R1 と R2 の P2P 端にあたります。

次に R1 の show ip route connected で直結ルートを見ます。

R1#show ip route connected
（凡例は省略）
Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 1 subnets
C        10.0.1.1 is directly connected, Loopback0
      192.0.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.0.2.0/31 is directly connected, GigabitEthernet2
L        192.0.2.0/32 is directly connected, GigabitEthernet2

192.0.2.0/24 is variably subnetted, 2 subnets, 2 masks という親見出しの下に /31 のサブネット（C ルート）と /32 のローカル（L ルート）が 2 本並んでいます。クラス C 親プレフィックス内で複数のマスク長が混在していることを、IOS-XE は variably subnetted で明示します。

C (Connected) は IF (Interface) に設定したサブネット全体を指すルートで、宛先がこの範囲のパケットを G2 から L2 (Layer 2) で送出する経路にあたります。

L (Local) は IF に設定した IP アドレスそのものを /32 ホストルートとして登録するもので、ルーター自身宛のパケット（ping や SSH）を CPU プロセスに上げるための内部ルートです。IOS 12.x 系には無く、IOS 15 / IOS-XE で導入された挙動で、落とし穴の節で再度触れます。

R2 側も同じ形になります。

R2#show ip route connected
（凡例は省略）
Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 1 subnets
C        10.0.2.1 is directly connected, Loopback0
      192.0.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.0.2.0/31 is directly connected, GigabitEthernet2
L        192.0.2.1/32 is directly connected, GigabitEthernet2

C の行は両端で同じ 192.0.2.0/31 を指し、L の行だけがそれぞれ自分の IP（R1 は .0/32、R2 は .1/32）になっています。

続けて G2 IF の詳細を見ます。

R1#show ip interface GigabitEthernet2 | include Internet|Broadcast|MTU|Mask
  Internet address is 192.0.2.0/31
  Broadcast address is 255.255.255.255
  MTU is 1500 bytes

Internet address is 192.0.2.0/31 は /31 表記で出ます。一方 Broadcast address is 255.255.255.255 は、/24 リンクなら 192.0.2.255 のようなサブネットブロードキャストが出るところに、限定ブロードキャスト（全 1 アドレス）が表示されています。

/31 はホスト部が 1 ビットしか無く、.0 と .1 がいずれも両端ホストアドレスとして使われているため、サブネット内ブロードキャストを置く余地がありません。サブネットブロードキャストと限定ブロードキャストの 2 種類のうち、前者が定義不能になる結果 IOS-XE は後者の 255.255.255.255 を表示します。R2 側も同じです。

Loopback0 の表示は単純です。

R1#show interfaces Loopback0 | include line protocol|Internet
Loopback0 is up, line protocol is up 
  Internet address is 10.0.1.1/32

Loopback は /32 ホストルートで、物理 IF と違って外部接続を持たないためリンク状態は常に up に保たれます。OSPF (Open Shortest Path First) / BGP (Border Gateway Protocol) の Router-ID にも使われるため、description Router-ID を入れてあります。

6. P2P ping で /31 が機能していることを確認する

R1 から R2 の P2P 端宛に ping を打ちます。

R1#ping 192.0.2.1 source GigabitEthernet2 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.0 
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 9/12/18 ms

結果は 80% (4/5)、表示の .!!!! が 1 回目失敗・以降 4 回成功を意味します。1 回目が落ちるのは ARP (Address Resolution Protocol) 解決待ち で、R1 の ARP キャッシュにまだ 192.0.2.1 の MAC (Media Access Control) アドレスが無い状態で送ろうとした初回 ICMP (Internet Control Message Protocol) Echo Request が、ARP Request/Reply のやりとり待ちで timeout します。2 回目以降はキャッシュに乗っているので即座に届きます。ARP の仕組みは 2-8 の Dynamic ARP Inspection の前提として既に触れたとおりで、L3 から見るとこの形で副作用が表面化します。

実運用で 4/5 だった場合はもう一度同じ ping を打ち、5/5 なら初回 ARP 解決による drop でリンクは正常、と判断できます。

初回 drop の原因を ARP debug で直接見る

「初回 ICMP が ARP 解決待ちで落ちる」は地の文の説明だけだと推論に見えます。debug arp を仕掛けて R1 自身に何が起きているかを直接撮ると、初回 . の正体が見えます。

ARP キャッシュを確実に空にしてから初回 ping を撮るため、ここでは G2 を一度 shutdown → no shutdown で bounce し、リンク再 up 後の ping 192.0.2.1 repeat 2 を debug arp 付きで観察しました（clear ip arp 192.0.2.1 単体だと CSR1000v が直結隣接を即座に再解決してしまい、初回 drop の窓が撮れないためです。落とし穴の節で再度触れます）。debug の行頭タイムスタンプは省いてあります。

IP ARP: creating incomplete entry for IP address: 192.0.2.1 interface GigabitEthernet2 tableid 0
 In ip_arp_sendrequest_internal: ELse case using src: 192.0.2.0
IP ARP: sent req src 192.0.2.0 5254.0099.7b79,
                 dst 192.0.2.1 0000.0000.0000 GigabitEthernet2
IP ARP: rcvd rep src 192.0.2.1 5254.00a1.899d, dst 192.0.2.0 GigabitEthernet2 tableid 0.!
Success rate is 50 percent (1/2), round-trip min/avg/max = 1/1/1 ms

順に読むと初回 drop の因果が 1 本で繋がります。

1. creating incomplete entry for IP address: 192.0.2.1 — まず ARP キャッシュに「解決待ち (Incomplete)」のエントリを作ります。この時点で宛先 MAC はまだ分かりません。
2. sent req ... dst 192.0.2.1 0000.0000.0000 — 宛先 MAC を全 0 にした ARP Request をブロードキャストで送出します。「192.0.2.1 の MAC を持っている人は教えて」という問い合わせです。
3. rcvd rep src 192.0.2.1 5254.00a1.899d — R2 から ARP Reply を受信し、192.0.2.1 の MAC が 5254.00a1.899d だと学習します。
4. 末尾の .! が ping の結果です。1 回目の . は、上記の ARP Request/Reply を待っている間に timeout したもの。2 回目の ! は、キャッシュに MAC が乗った後なので即座に届いたものです（最後の rcvd rep 行に ping の出力が続けて表示されているのは、debug と ping が同じ画面に流れているためです）。

解決が済むと、ARP キャッシュには Reply で得た MAC がそのまま載ります。

R1#show ip arp 192.0.2.1
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.0.2.1               0   5254.00a1.899d  ARPA   GigabitEthernet2

Hardware Addr の 5254.00a1.899d は、先ほどの debug の rcvd rep で受信した MAC と一致します。Age (min) が 0 なのは、たった今学習し直したばかりであることを示します。初回 . の drop は、この ARP Request/Reply のひとやりとり分の遅延がそのまま表面化したもの、というわけです。

7. Lo0 間 ping は届かない: 直結ルートの限界

次に、直結ルートの限界を見るため R1 Lo0 から R2 Lo0 宛に ping を打ちます。両者の Lo0 は 10.0.1.1 と 10.0.2.1 で、いずれも /32 のホストルートとして両端に存在しています。

R1#ping 10.0.2.1 source Loopback0 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1 
.....
Success rate is 0 percent (0/5)

結果は 0% (0/5)、1 つも届きません。

原因は、R1 のルーティングテーブルに 10.0.2.1 宛のルートが無い ことです。先ほどの show ip route connected で R1 が知っているのは自分の 10.0.1.1/32、P2P リンクの 192.0.2.0/31 と 192.0.2.0/32 の 3 本だけで、R2 の 10.0.2.1 はどのプレフィックスにも含まれません。R1 は宛先不明としてパケットを破棄します。

これを推論で終わらせず、R1 に直接 10.0.2.1 を引かせて確かめます。

R1#show ip route 10.0.2.1
% Subnet not in table
R1#show ip cef 10.0.2.1
0.0.0.0/0
  no route

show ip route 10.0.2.1（ルーティングテーブル = control plane の検索）は % Subnet not in table を返し、10.0.2.1 に一致するルートが 1 本も無いことを明示します。続く show ip cef 10.0.2.1（CEF (Cisco Express Forwarding) = 実際にパケットを転送する forwarding plane の検索）も、デフォルトルート (Gateway of last resort is not set) すら無いため 0.0.0.0/0 に落ちて no route と表示します。control plane と forwarding plane の両方で宛先不明、これが 0/5 の正体です。

Loopback0 を /32 で切ったアドレスは「Loopback 自身の 1 アドレスだけ」のルートで、隣接ルーターからは直結ルートとして見えません。同じ 10.0.0.0/8 空間にあっても、互いに学習する手段が無ければ届きません。

R1 が 10.0.2.1 宛のパケットを R2 に渡すには、R1 のルーティングテーブルに「10.0.2.1 宛は next-hop 192.0.2.1」というルートを入れる必要があります。これを管理者が手で書くのが 静的ルート、ルーター同士で経路情報を自動で交換するのが 動的ルーティングプロトコル (RIP (Routing Information Protocol) / OSPF / EIGRP (Enhanced Interior Gateway Routing Protocol) / BGP) で、いずれも 3-2 で扱います。

8. VLSM 演習

VLSM の境界計算を手で動かす演習を 1 題置きます。

問題: 192.168.20.0/24 から「30 ホスト LAN × 2 + 10 ホスト LAN × 1」を大きい順に切り出し、各サブネットのプレフィックス、アドレス範囲、ブロードキャストアドレスを示してください。

9. 落とし穴・補足

実運用や検証で踏みやすい注意点を 6 点挙げておきます。

• /31 リンクと RFC 3021: /31 を P2P リンクで使う運用は RFC 3021 (2000 年 12 月) で標準化される前は「P2P でもサブネットブロードキャストとネットワークアドレスを予約する必要がある」という考えが支配的で、/30 が慣行でした。/31 採用で 1 リンクあたり 2 アドレス節約でき、ISP (Internet Service Provider) バックボーンを中心に普及しています。Broadcast address is 255.255.255.255 はサブネット内ブロードキャストを置けない /31 固有の見え方です。一方 variably subnetted ... 2 masks は /31 固有ではなく、同一 major network 内に複数のマスク長が混在すると IOS-XE で常に出る一般的な表示で、IOS 15 / IOS-XE では IF アドレスごとに L の /32 Local ルートが入るため通常の /24 直結でも C /24 + L /32 で「2 masks」表示になります。
• /32 Loopback の Router-ID 慣行: Loopback は仮想 IF で物理ポートのリンク状態に依存せず常に up に保たれるため、OSPF / BGP の Router-ID 自動選出規則でも Loopback の最大 IP が優先されます。Router-ID は OSPF / BGP プロセスの初期化時に一度選出されると、以後はプロセス再起動 (clear ip ospf process 等) やルーター再起動まで変わりません。つまり物理 IF の IP を Router-ID に選んでしまうと、その IF が down してもその瞬間に自動で切り替わるわけではない一方、次にプロセスが再起動した時に Router-ID が変わって隣接関係を組み直す事故につながります。物理 IF down に依存せず安定して選ばれる /32 の Lo0 を 1 本載せておくのが定石です。
• VLSM 境界計算の off-by-one: 192.168.10.64/27 の次のサブネットの先頭は .96 です。/27 はホスト部 5 ビット = 32 個のアドレスを含むので、.64 から 32 個進んで最後が .95、その次のサブネットが .96 から始まります。/26 は 64 個刻み、/28 は 16 個刻み、/29 は 8 個刻みです。
• 集約の罠 (ブラックホール化): 経路集約は集約範囲の中身がすべて実在する前提で動きます。集約広告した範囲に存在しないプレフィックスがあると、上流はそちらに送り込み、受け取った側は drop します。本来他経路で届くはずだったパケットを意図せず奪う動きになるため、集約は実在する連続領域だけを束ね、予備領域は別プレフィックスとして広告しない、というのが原則です。
• Local ルート (L) の意味: show ip route の L 行は IOS-XE の Local ルート で、自 IF に付けた IP アドレスを /32 ホストルートとしてルーティングテーブルに載せます。自分宛のパケットを CPU プロセスに上げるための内部ルートで、外部に広告される性質のものではありません。IOS 12.x には無く、IOS 15 / IOS-XE で導入された挙動です。C は IF に設定したサブネット、L は IF に設定した IP そのもの、と区別します。
• 初回 drop を検証で再現するときの注意: §6 で初回 ICMP が ARP 解決待ちで落ちる様子を debug arp で撮りましたが、clear ip arp 192.0.2.1 でエントリを消すだけでは初回 drop の窓が撮れないことがあります。CSR1000v / IOS-XE は P2P 直結隣接を proactive に再解決するため、clear の直後にはもうキャッシュに戻っているからです。本節では G2 を shutdown / no shutdown で bounce し、リンク再 up で隣接を一から ARP し直させることで初回 drop と Request/Reply を確実に観察しました。なお debug の出力を SSH (VTY) セッションに表示するには terminal monitor が必要です（入れないとコンソールやロギングバッファにしか出ず、画面では debug が空振りに見えます）。

10. 次節 (3-2 ルーティングの基本) への接続

本節ではクラスフルから VLSM・CIDR の歴史を整理し、/31 P2P と /32 Loopback を CSR1000v 2 台で実機に張って IOS-XE の見え方を確認しました。Lo0 間 ping が 0/5 で落ちたのは、直結ルートだけで構成された世界には届かない宛先が残るためです。

続く 3-2 ルーティング基礎 では、この届かない 10.0.2.1 宛を届かせるための 静的ルート と 動的ルーティングプロトコル (RIP / OSPF / EIGRP / BGP の総論) を見ていきましょう。