15-02
15-02
それぞれの席の島が近いので、岸谷の席から門乃園と一緒に戻ってきた都は、自席の島の方へ折れる前に、もう一度門乃園に礼を行った。門乃園は謙遜を返してくれた。
席へ戻ると、机に出していたノートの空きページを立ったまま開いて、座ると同時に検証用のトポロジーを描き始める。海外拠点のＬＡＮはデフォルトゲートウェイ冗長プロトコルを回すのだから、Ｌ２スイッチを挟んで、ＬＡＮホストを表すルーターと、メイン側ルーター、バックアップ側ルーターとを接続する。ＭＰＬＳ網は１台のルーターで表せば良く、そのルーターに、海外拠点のメイン側ルーター、本社のメイン側ルーターのＷＡＮを接続。本社側のＬＡＮにもＬ２スイッチを挟んで、本社のコアスイッチを表すルーターと、さらにバックアップ側のルーターとを接続する。
都は最初、独立したＬ３のパスを、コアスイッチとメイン側ルーター、コアスイッチとバックアップ側ルーター、それぞれの接続にあったほうが良い、その方がお客コアスイッチから見てルート制御がしやすい、と考えていたのだが、良く考えると、それではＰＢＲをお客コアスイッチでやらなくてはいけなくなる。メイン側ルーターのＬＡＮ、バックアップ側ルーターのＬＡＮ、コアスイッチのアップリンクは同一セグメントでなければ、都たちのルーター、つまりメイン側ルーターでＰＢＲする意味がない。しかし、ヒアリングシートはきちんとこの想定でパラメーターが入ってきていた。既存コンフィグの本社拠点ルーターのＬＡＮ側サブネットと同じサブネットが、都たちの本社ルーターのＬＡＮインターフェイスのＩＰアドレスとしてアサインされていた。
インターネット側、つまりお客ベンダー構築の既存ネットワークも同様に、両拠点のバックアップ側ルーターのＬＡＮをそれぞれの拠点のＬ２スイッチに接続、ＷＡＮには、インターネットを表すルーターを一台置き、両拠点のバックアップ側ルーターを接続する。こうすると、検証用トポロジーではルーターは合計８台になる。通常端末のスペック的には、かなり重たい処理だ。これを始めてしまったら、スプレッドシートどころか、メール一通を開くのも難しくなるだろう。しかし、とにかくこれを先にやってしまうしかない。余程緊急でなければ、他の用件や仕事は後回しにしておくしかないだろう。
シミュレーターのパレットの上に、ルーターを並べて、それぞれのイーサーネットインターフェイスを接続して行く。両拠点のＬＡＮをそれぞれ同一セグメントにするためのＬ２スイッチも含めると合計１０台になるが、実際にシミュレーター上で起動が必要なのはルーターの８台だ。一気に起動させると、どうせどこかで止まったり、上手く起動しないルーターが出てくるので、一台ずつ起動して行く。４台目を起動させたあたりから、都の机の上の左端に、隣の机との間の仕切りのように立ててあるデスクトップ端末のファンが、うるさく回転音を吐き出してくるようになる。８台全て起動が終わったら、今度は一番最初に起動させたルーターからコンソール接続をして行く。このシミュレーターソフトに紐づけてある、ターミナルソフトが立ち上がり、本物のルーターと同じ起動シーケンスが、ターミナルウィンドウ上に走っている。
都は、パレットの左端の一台を海外拠点のＬＡＮホストを表すルーター、右端の一台を本社拠点のコアスイッチを表すルーターとし、コンフィグを始めた。この両端のルーター間を接続するパスは上と下２本あるが、上を都たちが新規に構築するＭＰＬＳ側、つまりメインパスとし、下のパスをお客ベンダーのインターネットＶＰＮ、つまりバックアップパスとしてコンフィグして行く。海外拠点側の、メイン側ルーターのコンフィグが終わったところで、ＬＡＮホストを表すルーターから、メイン側ルーターのＷＡＮインターフェイスまでｐｉｎｇを打ち、その到達性でコンフィグの正常性を確認する。そうやって、ルーターをコンフィグする途中途中で到達性の確認を取りながら、右端の本社拠点の、コアスイッチを表すルーターまでコンフィグして行き、最終的には、そのコアスイッチ上のサーバーを表すループバックＩＰから、海外拠点のＬＡＮホストＩＰまでｐｉｎｇが通れば、ＭＰＬＳ側はコンフィグ完了ということになる。詰まることも、到達性が取れないということもなく、すんなりと環境が構築できた。
一息入れたいな、と思ったが、バックアップ側もこのまま作ってしまおうと、都は海外拠点側のバックアップルーターからコンフィグを始めた。ポリシーベースのＩＰＳｅｃのコンフィグ例を上げているメーカーサイトのページは開いておいたので、タスクバーのブラウザをクリックして画面を表示させる。海外拠点側はそれを見ながら手打ちでコマンドを叩いて行った。鍵交換ポリシーの辺りは打ち慣れているので何のことはないし、ポリシーベース独特の部分も一度やったばかりなのでそれほど戸惑いはない。ＩＰＳｅｃ対象にするパケットについて、海外拠点はＬＡＮ側の接続セグメントを送信元アドレス、本社拠点のコアスイッチとルーター間の接続セグメント、それにコアスイッチにコンフィグした擬似サーバー役のループバックＩＰアドレスを宛先アドレスとするものとした。本社拠点に設定するＩＰＳｅｃ対象パケットは、送信元アドレス、宛先アドレスを海外拠点のものと逆にすれば良い。本社拠点のメイン側ではＢＧＰで伝播してきたルートをＯＳＰＦへ、タイプ１の軽いメトリックで再配送しているので、本社拠点のバックアップ側でもＯＳＰＦを回し、メイン側よりも重くなるタイプ１のメトリックで、ＷＡＮ側へ切ったスタティックルートを再配送すれば良い。
バックアップ側環境のコンフィグが全て終わり、本社拠点のコアスイッチ役のルーターでルーティングを確認すると、ルートはきちんとメイン側によっているし、ＬＳＡのタイプ５情報を見れば、メイン側のルーターからベストパスになっている小さいメトリックのもの、バックアップ側ルーターから大きいメトリックのものが設定通りに来ている。海外拠点側も、冗長デフォルトゲートウェイのペアはルーター間で組めていて、きちんとメイン側ルーターがアクティブとなっている。通常のルーティングは大丈夫そうだ。ポリシーベースのＩＰＳｅｃはちゃんと動くだろうか。ポリシーベースなので、対象のトラフィックが発生しない限りＩＰＳｅｃを張らないから、いつものＶＴＩインターフェイスを使ったルートベースのもののように、ＬＡＮからのトラフィックなしで、ＩＰＳｅｃが上がった、トンネルインターフェイスが上がった、ＶＴＩインターフェイス間のｐｉｎｇが通った、などのような確認は出来ない。
バックアップ側のルーターのルーティングテーブルには、対向拠点のＬＡＮネットワークに対して、ＷＡＮ側へ向けたスタティックルートしかない。また、自身のＬＡＮインターフェイスを送信元とした、対向拠点のバックアップ側ルーターのＬＡＮインターフェイスへのｐｉｎｇは、このポリシーベースＩＰＳｅｃの対象トラフィックに含まれる。つまり、バックアップ側ルーター間のＬＡＮインターフェイス同士のｐｉｎｇが到達すれば、設計やコンフィグに問題はないことになる。都は海外拠点のバックアップ側ルーターから、自身のＬＡＮインターフェイスをソースにして、本社拠点のバックアップ側ルーターのＬＡＮインターフェイスへｐｉｎｇを打ってみた。ポリシーベースＩＰＳｅｃの場合、トラフィックが発生してからＩＰＳｅｃを確立させるので、どうしても最初の一発は不達になってしまうから、最初の一発は落ちても構わない。しかし、５発のｐｉｎｇは全て不達だった。
「あれ？」
都は小さい声でそう呟いてから、海外拠点側、本社拠点側のバックアップルーターで運用中のコンフィグを表示させ、二つのターミナルウィンドウを並べて、コンフィグを比較した。都は海外拠点のバックアップ側ルーターをコンフィグしてから、ポリシーベースＩＰＳｅｃに関する設定部分については、海外拠点のものをテキストファイルにコピーし、値を本社拠点用に変更しなければいけないところを手で修正し、その修正したスクリプトを本社側のバックアップルーターへ流し込んでコンフィグした。そのため、流し込む前に直さなければいけなかった値を直し忘れたとか、必要なコンフィグが抜けているとかあるかと思って見比べたが、漏れなはないように思える。
もう一度、同様にｐｉｎｇを打ってみるが、全部不達になってしまう。やはりどこか設定が間違っている。もしかして、自発のｐｉｎｇはＩＰＳｅｃにカプセリングされない、とかあるのだろうか。先日、ポリシーベースＩＰＳｅｃに閉じて検証した時は、これは試さなかった。しまったな、と都は思いながらも、そもそもＩＰＳｅｃ化されるパケットとして引っ掛かっているのかと、アクセリストのカウンタを確認した。すると引っ掛かっている。海外拠点側ではＩＰＳｅｃを張ろうとしているということだ。
それなら本社側はどうだろうと思い、バックアップ側ルーターの、ＩＰＳｅｃ対象パケットを引っ掛けるアクセスリストのカウンタを見てみるが、こちらは引っ掛っていない。ＩＰＳｅｃが張れないのか、ルーティングの問題でｐｉｎｇが戻れないのか。都はもう一度、本社側のバックアップルーターの運用中のコンフィグを表示させ、上からじっくり眺めてみた。どこもおかしいところはない、もう一度、ＩＰＳｅｃ対象パケットを引っ掛けるアクセスリストのカウンタを表示させる。そこでやっと気がついた。海外拠点側のＬＡＮの接続セグメントの第３オクテットは３桁なのだが、都は本社側のこのアクセスリストだけは、カットアンドペーストで送信元、宛先の値をひっくり返さず、手打ちでやったことを思い出した。どうも第３オクテットの１桁目を打ち損じたらしく、入っておらず、下２桁だけになっている。つまり、全く異なるアドレスを対象にしてしまっているのだから引っ掛かるわけがない。
「…あちゃ。またやった…。」
小さ声でそう言うと、単純なミスだったことへの安堵と、自分の良くやる凡ミスに可笑しくなってにやけてしまう。都は検証環境を作る時、多くの場合手打ちでコンフィグを打っていくので、この手のミスは良くやってしまい、疎通確認などで上手くいかず、一人で焦ってしまうことは多かった。
都は急いでアクセスリストを直し、再度海外拠点のバックアップ側ルーターから、自身のＬＡＮインターフェイスをソースにして、本社拠点のバックアップ側ルーターのＬＡＮインターフェイスへｐｉｎｇを打ってみる。最初の一発が不達だっただけで、あとは到達を示すエクスクラメーション・マークが続いた。試しに１００発ほど打ってみるが、全て到達した。ＩＰＳｅｃも張れているし、本社側のアクセリストカウンタも上がった。都はひとまず基本の環境を作り終えたことに溜息をついて、ＰＢＲなしの状態で、冗長設計に問題がないかを確認することにした。海外拠点のメイン側ルーターの、ＬＡＮの断・復旧、ＷＡＮの断・復旧、それに本社拠点のメイン側ルーターでも同様にＷＡＮとＬＡＮの断・復旧。計４箇所の障害試験だ。海外拠点であれば、デフォルトケードウェイ冗長プロトコルがきちんと切り替わり、切り戻るか。本社側であればＯＳＰＦのベストパスがきちんと切り替わり、切り戻るか。
海外拠点のＬＡＮホストから、本社コアスイッチのループバックアドレスへのｐｉｎｇと通過ノード確認。もちろん非対称ルーティングになっていないか確認するために逆方向もチェックする必要がある。これらを、正常時である障害試験前に実施し、あとは、障害試験の各ステップ毎の、障害時と復旧時に実施する。双方向からｐｉｎｇを１００００発で打ちっ放しにし、対象の障害ポイントで、断を起こしたり、復旧したりする。障害時、復旧時にｐｉｎｇ不達期間が長過ぎたり、あるいは到達性が回復しなかったりもチェックする。
この障害試験には問題はなく、全て上手く行った。これでＰＢＲを試験するための環境がきちんと整ったことになる。都は、一応切りの良さに満足したので、上の階の自販機へドリップコーヒーを買いに行った。席に戻ってコーヒーを一口飲んでから、ＰＢＲのコンフィグを始めた。
海外拠点のＬＡＮホストから、本社コアスイッチのループバックアドレスへの遠隔ログインを、実際の要件である海外拠点のＬＡＮホストから本社サーバーへのアクセスの代替トラフィックとすることにした。これをポリシーベースルーティングで、強引にバックアップ側ルーターへ曲げるコンフィグを書いて行く。具体的には、海外拠点のＬＡＮホストから、本社コアスイッチのループバックアドレスへの遠隔ログインのパケットは、デフォルトゲートウェイ冗長プロトコルでアクティブとなっている、海外拠点のメイン側ルーターへ入ってくるが、ルーティングに従わせず、バックアップルーターのＬＡＮインターフェイスＩＰをネクストホップとして曲げてしまう。バックアップ側パスが生きていないければ、曲げてしまっても不達になってしまうので、先日のお客との打ち合わせで話した通り、バッックアップ側パスを監視する必要がある。曲げ先のネクストホップであるバックアップ側ルーターのＬＡＮインターフェイスのＩＰと、バックアップ側ルーターのＷＡＮインターフェイスが接続するインターネットを表すルーターのＩＰとを、ポーリングし、どちらかが不達になっても、ダウンと判断するトラッキングを作成し、それをＰＢＲに設定する。このトラッキングが落ちれば、ＰＢＲのトラフィックを曲げる設定は無視され、対象のトラフィックも通常通りルーティングされる。
同様に、本社から、この遠隔ログインの戻りパケットが、バックアップ側を通るように、メイン側ルーターに入ってきた戻りパケットを、バックアップルーターへ曲げる設定と、海外拠点同様の到達性の監視、トラッキングの設定とをメイン側のルーターに施す。
インターネットを表すルーターは、どちらの拠点のＬＡＮ空間へもルーティングを持たない。そのため、どちらのバックアップ側ルーターにも、インターネットを表すルーターを監視するパケットの送信元が、自身のＷＡＮインターフェイスＩＰに変換される設定を追加する必要がある。
都は設定が上手く行ったことを確認するために、海外拠点のＬＡＮホストから、本社コアスッチのループバックＩＰへ遠隔ログインしてみる。最初、パスワードが設定されていないというエラーメッセージが出て、本社拠点のコアスイッチに遠隔ログインのための設定が漏れていたという、検証環境で良くある凡ミスをまたやってしまっていることを都に気付かせたが、両拠点のメイン側ルーターのＰＢＲのカウンターを見ると上がっているので、上手く引っ掛かってはいるようだ。コアスイッチに遠隔ログインを可能にする設定をしてから、再度試すと、今度はきちんとログインできた。そのままリターンキーを何回か叩いたり、適当な確認コマンドを叩いたりして、両拠点のメイン側ルーターのＰＢＲのカウンターをチェックすると、どんどん上がっている。きちんと曲がっていると判断出来そうだ。複数条件のトラッキング設定もアップになっている。
ＰＢＲの設定が、通常のトラフィックに影響を与えていないか確認するために、都は、先ほど実施した４箇所の障害試験を、試験項目にこの遠隔ログインも入れて実施した。通常のトラフィックには影響がなく、遠隔ログインにも問題はなかった。どちらかの拠点でメイン側ルーターのＬＡＮインターフェイスを閉塞した時、閉塞した拠点では、まっすぐバックアップルーターへ行くので、当然ＰＢＲのカウンターは上がらないが、閉塞してない方では、メイン側ルーターへ一度上がってからＰＢＲされ、バックアップパスへ回る。
メイン側のパスには影響がないことがわかったので、次は、ＰＢＲされるトラフィックが、バックアップ側で障害が発生した際に、きちんとメイン側のパスを使えるかどうかを試験する必要がある。都はノートに書いたネットワーク図上で、障害を起こす箇所に、シャープペンシルで空中でバツ印をつけながら、頭の中でこのバックアップパスの監視先ＩＰや、どこを切ったらどこへ到達しなくなり、トラッキングが落ちてＰＢＲが処理されず通常のルーティングになるかを、辿った。しかし、都は空中で回していたペンの動きを止めざるを得なかった。
都はまずいことに気がついた。凡ミスを見つけた時なんかは、声が出るのに、本当にまずいことを見つけた時には声も出ない。この設計では、バックアップ側パスの何処かで障害があった際に、ＰＢＲがブラックホールになってしまう。最初にバツ印を空中で切った、海外拠点のＬＡＮ側の断ですら、ブラックホールを作ってしまう。しまった、お客の前で間違ったことを喋ってしまったと、強い焦燥感が都に押し寄せてくる。汗が出てきた。お客に早くこの件を伝えないといけないが、代替手段があるのかどうか、先に考えないといけない。まずは状況を整理なのだが、都は強く緊張もしたし、焦ってもいた。
都は深爪気味の爪を立てて、自分の頬を何度か強く掻いた。ビジネスアワーのオフィス内はあちらこちらで電話や会話でやかましいはずなのに、都の机の上で唸っている、通常端末のファンが、うるさいくらい耳に付く。
都が先日のお客との打ち合わせで、メイン側ルーターのＰＢＲの可用性を監視するためには、バックアップ側ルーター、つまりお客ベンダー提供のインターネットＶＰＮを終端しているルーターのＬＡＮインターフェイスＩＰ、それと、そのルーターのＷＡＮが接続しているインターネット回線の、プロバイダエッジ側のＩＰへの到達性で大丈夫だと言った。実際この検証環境もそれで設計、コンフィグしている。しかし、このＰＢＲは、海外拠点からの上りトラフィックだけではなく、本社からの戻りトラフィックについても、ＰＢＲする必要があるのだ。検証では遠隔ログインだけだが、実要件は本社サーバーからのダウンロードのトラフィックが大きく、これをオフロードしたいというものだ。今の検証環境の設計では、海外拠点のバックアップ側ルーターのＬＡＮに断が起こった時、いや海外拠点のバックアップ側ルータのＷＡＮ、ＬＡＮ、どちらで断が発生しても、本社拠点はそれを探知できない。そうすると、海外拠点からのＰＢＲ対象のトラフィックはメイン側パスへ切り替わっても、本社から戻りのパケットは、相変わらずＰＢＲされ続け、海外拠点のＬＡＮが断であれば、ＩＰＳｅｃを確立させた後、海外拠点のバックアップルーターで宛先知れずになるし、海外拠点のＷＡＮが断であれば、ＩＰＳｅｃ対象のパケットがバックアップ側ルーターにＰＢＲされて来ても、ＩＰＳｅｃが確立できず、本社のバックアップ側ルーターでパケットが落ちてしまう。もちろん、逆方向も然りだ。
対抗拠点のバックアップ側ルーターのＷＡＮインターフェイスＩＰを監視すれば良いか。それでは結局反対側拠点のＬＡＮインターフェイスの断が拾えない。そうなると、メイン側のルーターから、対抗拠点のメイン側ルーターのＬＡＮインターフェイスＩＰを、メイン側のパスではなく、バックアップ側ルーターを通して、監視しないといけない。こうすれば、バックアップ側パス、つまりＰＢＲで通過する経路全てを監視出来る。メイン側ルーターに、バックアップ側のＬＡＮインターフェイスＩＰをネクストホップとした、対抗拠点のＬＡＮインターフェイスＩＰへのスタティックルートを、３２ビットルートで設定すれば良い。行きの監視パケットが、バックアップ側パスを通りさえすれば、戻りはどちらから返ってきても良いのだが、対抗拠点に逆のルートを書くことなるので、メイン側ルーターから、対抗拠点のメイン側ルーターの、ＬＡＮインターフェイスＩＰへのｐｉｎｇは、行きも戻りもバックアップパスを通ることになる。これでＰＢＲ先の経路は全て監視可能になり、どこで断が起きても、トラッキングが落ち、通信対向拠点の両方で、ＰＢＲをキャンセルし、対象トラフィックを通常のルーティングに乗せることが出来る。
都は、監視ポーリングの設定や、トラッキングの設定をコンフィグし直した。これでうまく行くはずだ、という楽観的な感覚と、上手くいかなかったらどうしようという悲観的な感覚が混ざって落ち着かない。早くやろうと思うと、タイプミスが多くなり、コンフィグに時間がかかる。これは事前の検証なのだ。事前の検証で問題が発覚したのは、むしろ良かったと思うべきだ。実際の切り替え工事時に発生したはずのトラブルを未然に防いだのだ。そう考えようとしても、間違ったことをお客に説明してしまったという瑕疵は現実だ。
コンフィグの変更が完了し、通常のトラフィック、ＰＢＲ対象のトラフィック共に問題ないことを確認してから、通常のトラフィックの代わりである、海外拠点ＬＡＮホストから、本社コアスッチのループバックインターフェイスへのｐｉｎｇと、その逆方向へのｐｉｎｇとを、回数１０００００回で流し続けて、バックアップ側の断試験に入った。４箇所の断試験の都度、断の時に、遠隔ログインが出来ること、かつＰＢＲのカウンタが上がっていないことを確認、復旧した後は、遠隔ログインが出来、かつＰＢＲのカウンタが上がっていることを確認する。結果、無事ＰＢＲにも冗長性を持たせることに成功した。
都は最後の断試験の復旧で、遠隔ログインとＰＢＲのカウンタアップを確認出来た途端、キーボードの上に覆い被さるように背中を曲げ、声が出てしまうほど深く溜息をついた。短い髪の毛が、キーボードの上を撫でる感触と、脇から降りてきて顔を隠す髪の中に、このまま隠れてしまいたいという思いとが喧嘩をする。
出来ると言ったことを、出来ません、とならなくて良かった。しかし、間違った説明をしたことについては謝罪と訂正をしないといけない。ＰＭは岸谷だ。新入社員に古株の派遣社員の尻拭いのような真似をさせるのは気が引ける。都は自分でお客に連絡をして謝るべきだと思ったが、しかしお客のカウンターパートはＰＭであり、こういう時でも、お客の正面に立つのはＰＭの仕事の一つだ。都がＰＭをやっていた時もそうしてきた。
せっかく当てにしてもらっていたのに失敗をしてしまって、きっと岸谷を失望させてしまうだろう。すごく岸谷とは仲が良くなれたのに、これで少し避けられるようになるかも知れない。自分で客に連絡して謝るにしろ、ＰＭが謝るにしろ、ＳＥとしてはまずＰＭに報告しないといけない。都はノートとシャープペンシルを持って席を立ち上がった。最初に下山に紹介されて岸谷と会った時に、岸谷が見せた、この人は信用できるんだろうかと言いたいような、自分より年上の非正規雇用の女とどう接していいのかわからないと言ったような、そんな色が、あの長い睫毛が飾り付けられた大きな瞳にあったのを、都は思い出した。