音声は、戻った。
第26話でイトが組み直したUDP datagramが、二台のrouterを抜け、遠隔stageのvoice applicationを青く光らせている。
一個が欠けても、その後ろは止まらない。
小さな空白を挟みながら、ユイの案内音声がlabに響いた。
「次のcueまで、六秒です」
イトは、現在の経路を示すcyanの線を見上げた。
source router。
中央の中継router。
遠隔stage。
三点を結ぶ道の横には、いちばん小さなcost tokenが置かれている。
別の中継所を回るamberの道もあるが、遠回りだ。cost tokenは二枚多い。
いまの道が使えるなら、切り替える理由はない。
残り五秒。
中央のlinkが、音もなく消えた。
宛先は正しいのに、同じ出口で落ちた
次のdatagramがsource routerへ入った。
destination IP addressは遠隔stageを指している。
destination portもvoice applicationの入口と合っている。
headerは壊れていない。
routerはforwarding tableから、さきほどまで使っていたentryを選んだ。
next hopは中央の中継router。
outgoing interfaceはcyanの出口。
第21話で確かめたlookupとしては、間違っていない。
datagramはcyanの出口へ送られた。
だが、消えたlinkの手前で光を失った。
二個目も、同じentryを選ぶ。
同じ場所で落ちる。
イト
destinationもportも合ってる。routerの選び方だって、さっきまでは正しかった
ユイ
正しかった、というところが気になります。いまも使える道ですか？
ピコ
packetを見る処理は変わっていない。でも、packetを見る前の地図が古くなった
残り三秒。
イトは、cyanの出口へ三個目を置きかけて、手を止めた。
forwardingは、いまある表で一個を送る
routerの前面に、二つの作業台がせり上がった。
下段は、packetが一個ずつ通る高速な照合台。
destinationを見て、forwarding tableのentryからnext hopと出口を選ぶ。
これが forwarding だ。
IPv4 routerの要件をまとめたRFC 1812も、forwarderがpacketのdestinationをrouting tableへ照合し、next-hop addressと送信interfaceを決める流れを示している。
第21話でイトが行ったlongest-prefix matchは、この下段の仕事だった。
だが、下段は「このlinkが、たったいま切れた」と自分で物語を書き換えない。
渡された表を使い、packetを送る。
表のentryが古ければ、同じ古い答えを正しく出し続ける。
上段には、linkとrouterを結んだnetwork graphがある。
どのdestinationへ到達できるか。
どの経路に、どんなcostがあるか。
管理者のpolicyで、使ってよい経路か。
それらの経路情報を受け、使うrouteを選び、下段が使う表へ反映する。
この上段の仕事が routing だ。
マコト
forwardingは一個を送る。routingは、その判断に使うrouteを整える
イト
いま直すべきなのはpacketじゃない。下段へ渡しているentryだ
残り二秒。
routeは、三つの入口から来る
上段の端に、三つのtrayが開いた。
一つ目は connected route。
router自身のinterfaceへ直結しているnetworkから分かる経路だ。
二つ目は static route。
管理者がnext hopなどを設定して置く経路だ。
三つ目は dynamic routing protocol が運ぶ情報。
routerどうしが到達可能性やnetworkの状態を交換し、変化に合わせて経路を計算するために使う。
どのprotocolも同じ計算をするわけではない。
costの意味も、routeの選び方も、変化を知る方法も異なる。
今回のlabは、linkの状態を共有してgraphから経路を計算するlink-state型の縮小模型だ。
cyan linkが切れると、中央routerから「この接続は使えない」という新しいstate tileが届いた。
OSPF Version 2の仕様であるRFC 2328では、routerがlink-state databaseからshortest-path treeを計算してrouting tableを作る。topology changeを受ければ、関係する計算とtable entryも更新される。
ただし、現実の切替が必ず二秒で終わるという意味ではない。
故障を知り、情報が伝わり、計算し、表へ反映するまでには時間がある。
networkが新しい状態へ落ち着くまでを、ここでは 収束 と呼ぶ。
残り一秒。
三つの選択
上段に、三枚のdecision cardが出た。
- cyan routeを残す。直前まで最小costだったから、そのうち戻ると考える
- 全routeへ同じdatagramを複製する。どれか一つが届けばよいと考える
- broken linkを反映してcyan routeを候補から外し、使える経路を再計算して一つをforwarding tableへ入れる
一つ目は、計算をやり直さなくてよい。
だが、古いentryが残る限り、forwardingは落ちる出口を選び続ける。
二つ目なら、alternate pathを探す前に投げられる。
しかし、毎回すべてへ複製すれば、同じdatagramが重なり、使えるlinkの負荷も増える。失敗時の一般的なrouting方法にはならない。
三つ目には、切替の空白がある。
cyan routeを外してからamber routeを入れるまで、下段には遠隔stageへ使えるentryがない瞬間も生まれる。
それでも、壊れた道を「いまも最良」として残さない。
cue lampが白から赤へ変わった。
イトは、三枚目を取った。
イトは、古い最短路を外した
イトは、上段のgraphでbroken linkへ黒い断線tileを置いた。
cyan route cardの端から、reachableを示す光が消える。
次に、下段のforwarding slotからcyan next-hop tokenを引き抜いた。
この一瞬、使えるentryはない。
待っていた一個のdatagramが、unreachable trayへ落ちた。
イトは目をそらさなかった。
失った一個を、存在しなかったことにはしない。
上段の計算wheelを回す。
broken linkを含むrouteは、候補から外れた。
残ったのは、別の中継routerを二台通るamber route。
cyanよりcostは高い。
けれど、いま到達可能で、labのpolicyにも反していない。
イトはamber route cardを選び、そこに結び付いたnext-hop tokenをforwarding slotへ差し込んだ。
遠回りの先で、声が戻った
fresh datagramが下段へ入る。
forwardingは、新しい表を使った。
destinationは同じ遠隔stage。
選ばれたnext hopは、amber側の中継router。
packetは、以前より長い弧を描いて進む。
一台目。
二台目。
遠隔stage。
voice applicationの波形が、再び立ち上がった。
ユイの声には、短い欠けが残った。
第26話でapplication側へ置いたplayoutとconcealmentが、空白を小さく丸める。
だが、消すことはできない。
切れる前にcyan routeへ出た二個と、entryの空白で落ちた一個は戻らない。
routeを切り替えれば、過去のpacketまで救えるわけではなかった。
ユイ
声は戻りました。でも、途中の三個は欠けたままです
イト
routingが直すのは、これから使う道だ。落ちたdataを巻き戻す仕事じゃない
ピコ
それに、新しい道には新しいcostがあるよ
最短は、地図で近く見えることではない
amber routeは、画面上では大きく迂回している。
今回は、labがlinkごとに置いたcost tokenを足し、使用可能なrouteの中で小さいものを選んだ。
このcostは、地理的な距離そのものではない。
routing protocolや設定に応じて、linkへ異なる値が与えられる。
また、costが小さくても、管理policyで受け入れないrouteなら使わない場合がある。
「近そう」「空いていそう」「いつも速そう」という見た目だけで決まらない。
ここでイトが選んだのは、世界共通の一本の最短路ではない。
このlabが受け取った現在のtopology、cost、policyから選べるalternate routeだ。
そして、routeが見つかることは、遅延が同じになることも、packet lossがゼロになることも保証しない。
alternate routeがなければ、魔法は起きない
ピコが、amber route cardを一度伏せた。
上段から、遠隔stageへ到達できるrouteが消えた。
下段の照合台には、選べるentryがない。
この状態では、routerは目的地へforwardできない。
RFC 1812は、default routeを含めてrouteがなくpacketをforwardできない場合、network unreachableのICMP messageを生成する要件を示している。
routingは、存在しない道を作る魔法ではない。
使える接続と、受け入れられる経路情報があって初めて、別のrouteを表へ入れられる。
イトはamber cardを戻した。
遠隔stageへの波形が、少し遅れて揺れる。
短い道を失い、遠い道で続けている。
それが今回の成功だった。
routingが更新し、forwardingが送り続ける
上段では、broken linkを反映したgraphとamber routeが点灯している。
下段では、fresh datagramが一個ずつ新しいnext hopへ出ていく。
routingとforwardingは、同じrouterの中でつながっている。
だが、同じ仕事ではない。
routingは、使える経路情報を選び、計算し、forwardingが参照する表を更新する。
forwardingは、その時点の表でpacketごとの次の一歩を決める。
古い表のままなら、forwardingが正確でも届かない。
新しい表へ入れ替える間には、空白とlossが生まれ得る。
切替後の道には、以前とは違うcostが残る。
イトは、unreachable trayに落ちた三個を横へ並べた。
その奥で、amber routeを小さなvoice datagramが流れ続けている。
次回：長い映像を、この細い道へどう入れる？
遠隔stageへ続くamber routeに、新しい荷物が運ばれてきた。
次のanime cutを収めた、長い一本のfilm ribbonだ。
そのままでは、一台目の中継gateさえ通らない。
voice datagramは、ribbonの後ろで行き場を失った。
イトは、長い光の端を持ち上げた。
「道を選べても、これが一個のままじゃ、みんなで使えない」
ピコは、空の小箱を作業台へ並べた。
壊れた道を外し、別の一歩は選べた。
次は、その道へdataをどんな大きさで載せるか。
次回、ピコルート第28話。
パケット通信はなぜ小分けにする？
画面のむこう側をもっと知る
routing、routing table、next hopの関係を図で整理するなら、ルーティングとは？で確かめられます。