ネットワーク●●●○○

ルーティング

Routingるーてぃんぐ

パケットを宛先まで届ける経路を選択する仕組み。ネットワークをまたぐ通信の要。

概要

ルーティング(経路制御)は、パケットを宛先のIPアドレスまで届けるために「次にどこへ渡すか」を選び続ける仕組みです。インターネットは無数のネットワークの相互接続体であり、東京の端末からアメリカのサーバへの通信は、途中の何台ものルータをリレーのように経由します。各ルータは経路の全体を知っているわけではなく、「この宛先ならお隣のあのルータへ」という次の一歩(ネクストホップ)だけを判断します。この局所的な判断の連鎖が、結果として世界の裏側までパケットを届けるのです。

たとえるなら、宛先の住所だけが書かれた荷物を、各地の集配所が「この住所なら西方面の集配所へ」と順送りしていく宅配網です。どの集配所も配達の全行程は知りませんが、それぞれが正しい方面へ送り出せば荷物は届きます。この「方面別の仕分け表」にあたるのがルーティングテーブルです。

普段は意識せずに使えるルーティングですが、開発の現場では「クラウドのサブネット同士がつながらない」「VPNを張ったら一部の通信だけ届かない」といった形で顔を出します。traceroute で経路を追ったり、ip route でテーブルを読んだりする力は、インフラのトラブルシューティングの基礎体力です。

なぜ生まれたか

すべての機器が1本のケーブルや1つのスイッチにぶら下がる小さなネットワークなら、宛先を探す仕組みは単純で済みます。しかし世界中の組織がそれぞれ勝手に作ったネットワーク同士をつなぐとなると、「全機器の場所を1か所で把握する」ことは規模的にも管理的にも不可能です。しかも経路の途中の回線や拠点は故障するため、固定の経路では一部の故障が全体の不通につながってしまいます。インターネットの前身 ARPANET は軍事研究の文脈で生まれており、「一部が壊れても残りの経路で通信を継続できること」は当初からの中心的な要求でした。

この課題への答えが、「宛先ごとの完全な経路」ではなく「宛先の方面ごとの次の一歩」だけを各ルータに持たせ、ルータ同士が経路情報を交換し合って障害時には自動で迂回路に切り替える、という分散型の経路制御でした。中央の管制塔なしに、各ルータの局所的な判断だけで全体が機能する — この設計こそが、インターネットが誰の所有物でもないまま惑星規模に成長できた理由のひとつです。

詳細

ルーティングテーブルとロンゲストマッチ

ルータの判断のよりどころがルーティングテーブルです。各行は「宛先ネットワーク(プレフィックス)」と「ネクストホップ(次に渡す相手)」の対応で、たとえば「10.0.0.0/8 宛ては ルータB へ」「10.1.0.0/16 宛ては ルータC へ」のように、宛先を1台ずつではなくネットワーク単位でまとめて書きます。この集約のおかげで、テーブルは世界中の全機器を列挙せずに済みます。

パケットが届くと、ルータは宛先IPアドレスに一致するプレフィックスをテーブルから探します。このとき複数の行に一致することがあり、その場合は最も長い(=最も具体的な)プレフィックスを優先します。これが「ロンゲストマッチ(最長一致)」の原則です。宛先 10.1.2.3 のパケットは /8 と /16 の両方に一致しますが、より具体的な /16 の行が勝ちます。どの行にも一致しない宛先を受け持つのが「デフォルトルート(0.0.0.0/0)」で、家庭のPCが「よく分からない宛先は全部ルータへ」と送り出せるのはこの仕組みのおかげです。

パケット宛先 10.1.2.3ルーティングテーブル10.0.0.0/8 → ルータB 一致10.1.0.0/16 → ルータC 最長一致0.0.0.0/0 → ルータA 既定具体的な行ほど優先されるルータCネクストホップ転送
ロンゲストマッチ — 複数の候補のうち最も具体的なプレフィックスが選ばれる

このロンゲストマッチは、OSI参照モデルでいうレイヤ3(ネットワーク層)の中核動作です。レイヤ2の MACアドレスによる転送が同一ネットワーク内の配達だとすれば、ルーティングはネットワークとネットワークの間をまたぐ配達を担います。

静的ルーティングと動的ルーティング

ルーティングテーブルの作り方には2通りあります。静的ルーティングは管理者が手で経路を書く方式で、動作が予測しやすく余計な通信も発生しませんが、経路の追加や障害のたびに人手の変更が必要です。小規模な拠点や、クラウドのルートテーブル(VPC内のサブネット間経路など)ではいまも主役です。

動的ルーティングは、ルータ同士がルーティングプロトコルで経路情報を交換し合い、テーブルを自動で構築・更新する方式です。組織内(AS内)で使う IGP には、隣接ルータと距離情報を交換する RIP や、ネットワーク全体の地図を各ルータが持ち最短経路をアルゴリズム(ダイクストラ法)で計算する OSPF があります。回線障害が起きると各ルータが経路を再計算し、全体が新しい経路で合意するまでの過程を「コンバージェンス(収束)」と呼びます。収束が終わるまでの間はパケットが行き場を失ったりループしたりすることがあり、動的ルーティングの設計では収束の速さが重要な指標になります。そして組織間、つまりインターネット全体の経路交換を担うのが BGP です。

実務での顔の出し方

クラウド時代のインフラ設計は、実はルーティング設計そのものです。VPC のルートテーブルで「このサブネットからインターネットへは NATゲートウェイ経由」と書くのは静的ルートの設定であり、NAT とルーティングはここで組み合わさります。VPN の「特定の宛先だけトンネルに流す」スプリットトンネルも、Kubernetes のPod間通信も、その実体はルーティングテーブルの操作です。

典型的な落とし穴も知っておきましょう。行きと帰りで別の経路をたどる「非対称ルーティング」は、経路上にステートフルなファイアウォールがいると帰りのパケットだけ落とされる厄介な障害を起こします。また、2台のルータが互いに「その宛先はそっちだ」と押し付け合うルーティングループでは、パケットは TTL(生存時間)が尽きるまで回り続けて破棄されます。traceroute で同じルータの組が繰り返し現れたらループのサインです。「つながらない」の原因調査では、名前解決(DNS)の次にまず経路を疑う — これがネットワークデバッグの定石です。