17-03
17-03
都は事前にも事後にも、その南アジアのノードのプロバイダエッジルーターが更改になることを知らなかったが、プロバイダエッジルーターのホストネームには命名規則があるから、更改後のホストネームはだいたい検討がつく。都はＰＨＳを右耳と右肩で強引に挟んだまま、専用端末のマウスを動かし、専用端末をスリープ状態から叩き起こして、共通のパスワードでロックを解除し、急いで踏み台サーバーへログインする。そこから、ホスト名を直に叩いて任意のプロバイダエッジルーターへログイン出来るコマンドがあるので、それを使って、都が多分これだろうと思った更改後のプロバイダエッジルーターのホストネームを打ち、リターンキーを叩く。するとクレデンシャルを聞かれる画面になったので、これもドキュメントとしてどこにも保存されてはいないが、保守の人間と一部の構築の人間に口伝で引き継がれている、クレデンシャルを試してみた。ログイン出来た。ホストネームは想定した通りだ。
「新しいプロバイダエッジルーターのホストネームって…。」
都は電話の向こうの大森に、ホストネームを読み上げてみた。
「はい、それですね。」
「ちょっと待ってください…。今ログイン出来たんで…。」
電話の向こうで大森は、すみません、と言っている。保守の問題なのに、構築のリソースを使ってしまって、という意味もあるだろう。確かに、全く構築担当は関与していないのだから、保守で閉じてやってくれ、ということも出来るだろうが、都は性格的にそういう断り方が出来なかったし、そもそも保守に頼られた時は、出来る限り応えるべきだという仕事態度だから、大森の言葉に否定を返した。
このキャリアのプロバイダエッジルーターには、３種類のメーカーのものが混在している。一つは客宅ルーターに提供している筐体を作っているメーカーと同じもので、このキャリアでは最も古くから採用されている。もう一つはヨーロッパのメーカーのもので、プロバイダエッジルーターも客宅ルーターも、東京が設計、コンフィグ作業をやっていた頃は、このメーカーのものが主流だった。コマンド体系がかなり違うので、プロバイダエッジルーターで何か確認したい時は苦労したものだが、東京のプロバイダエッジルーターの担当者が何かミスをすると言うことはほとんどなかったから、そもそも、そんな頻繁に確認する必要もなく、コマンドを覚える必要もなかった。しかし、プロバイダエッジルーターの業務が海外オフショアセンターに完全に移った後は、このヨーロッパのメーカーの筐体の確認コマンドを、かなり研究して使えるようにならないといけなくなった。
最後の一つは、都が勤めるこのキャリアで、客宅ルーターとして提供してる筐体のメーカーと、二大巨頭をなす世界的なネットワーク機器メーカーのものだ。こちらもコマンド体系が全く異なるのだが、海外オフショアセンターへプロバイダエッジルーターの業務が移行した後は、このメーカーのプロバイダエッジルーターへ回線を収容することが多く、トラブルも増えた。そのため確認コマンドについては、東京のＳＥは誰でもある程度詳しくなってしまっている。このメーカーのものは、そもそも海外オフショアセンターが彼らのＭＰＬＳサービスのプロバイダエッジルーターとして採用していたものだ。彼らのＭＰＬＳは、都が務めるキャリアがもともと持っていたＭＰＬＳとインターＡＳで接続して、既に都たちのＭＰＬＳの一部となっている。東京だけでやっていた頃主流だった二つのメーカーのプロバイダエッジルーターは、どちらも既に製造メーカーでＥＯＬになっていて、更改は喫緊の課題でもあった。海外オフショアセンターは、自分たちが使い慣れ、あるいは安価に購入できる経路を持っている、この三つ目のメーカーの筐体を更改機器として選定し、更改作業を進めていた。
このメーカーの筐体のプロバイダエッジルーターを、海外オフショアセンターがコンフィグする時のルールの一つに、ＶＲＦ名の命名規則があるが、東京でやっていた時とそれは異なる。ＶＲＦ名にはお客の名前の一部か全部が含まれるから、都は、まずはその正確なＶＲＦ名を知るために、このお客の名前が含まれるコンフィグ行のみを表示させるコマンドを叩く。表示された関連のコンフィグ行から、ＶＲＦ名がわかるので、次にその当該ＶＲＦのコンフィグだけに絞って表示するコマンドを叩く。そうすると、このＶＲＦのＢＧＰで、ＭＰＢＧＰのルートから取り込むべきルートに付いている、ルート・ターゲットと呼ばれるＢＧＰの拡張コミュニティが、何であるかを定義している部分を確認出来る。
このＶＲＦに絞ったコンフィグ部分で見える、取り込むべきルート・ターゲットは何か、という部分は、対象のルート・ターゲットをリスト化したそのリストを、このＶＲＦにインポートする、と言った体裁になっている。つまり、この出力で見えているのは、ルート・ターゲットのリスト名に過ぎない。このリストの中身を確認して、実際の拡張コミュティの値を見ないといけないが、都はこの筐体でどうやってコミュニティリストの中身を表示させるのかよくわからなかった。あれこれ試して時間を潰している暇はないので、都は今このプロバイダエッジルーターにログインしているターミナルウィンドウのログ取りを開始する。ファイル名を考えている暇もないので、１とかしておいてデスクトップへ保存、そしてターミナルウィンドウへの出力行の制限をなくすコマンドを打ってから、コンフィグ全体を表示させるコマンドを叩いた。プロバイダエッジルーターのコンフィグは、そのルーターに収容している全お客ＶＲＦのコンフィグだけではなく、バックボーンやアクセススイッチ側へのコンフィグなどを含む、とても長いコンフィグなのだが、このメーカーのコンフィグ出力は、ターミナルウィンドウへの出力制限をなくすと、あっという間に終わる。
都は取得したログファイルを開き、そのテキストファイルのウィンドウと、ターミナルウィンドウとを並列に並ぶよう調整してから、ターミナルウィンドウをクリックし、もう一度このＶＲＦに絞ったコンフィグ部分だけを表示させ、このＶＲＦに呼び込むコミュニティリストの名前をコピーする。そしてログを開いたテキストファイルの上で検索のショートカットキーを叩いて、検索ボックスの中にペーストする。リターンキーを叩いて行くと、何回かそれをネストしているコンフィグに引っ掛かる。中には当然このＶＲＦのコンフィグの部分で、このＶＲＦへ入れ込むルート・ターゲットの定義部分、また客宅ルーターから受け取ったルートをＭＰＬＳへ流す時、ルートに付与するルート・ターゲットの定義部分とがある。都は、この時点で、コンフィグが正しく更改後のプロバイダエッジルーターに移植されていないことはわかった。ＶＲＦへ入れ込むルート・ターゲットのリストと、ＭＰＬＳへ流す時に、ルートに付与するルート・ターゲットのリストとが同じだからだ。通常のお客であれば、これで構わない。しかし、このお客の網内の設計はそうなっていない。
都は３、４回リターンキーを叩いて、ようやくコミュニティリスト自体を定義しているコンフィグにたどり着いた。やはり、一つのルート・ターゲットしか定義されていない。都は想定通りだったという、クイズにでも正解したような快感と、行き止まりに突き当たった失望感とがごっちゃになった感覚に襲われて、どういう反応をして良いのかわからなくなる。緊張からだろうか、手も震えてきたし、胸が一杯になる。
このお客のＶＲＦには、３つの異なるルート・ターゲットをインポートするようになっていなければならない。しかし、この更改後のプロバイダエッジルーターでは、一つのルート・ターゲットのみがインポートされるだけだ。
「あああ…。これは、ダメです。大事な設計が落ちちゃってます。これだと、大森さん見たみたいに、網内には存在するんだけど、このプロバイダエッジルーターから客宅ルーターに広告できない、ってことが起こっちゃいます。」
都は、これを一体どうやって、しかも早急に直させれば良いんだ、ということの手詰まり感に困っていることが、そのまま声の調子に出てしまう。都は構築担当の派遣社員だから、バックボーンのメンテナンス工事など、どういう指揮命令系統でやっているのかすら知らない。
「ええええ？まじですか…。」
電話の向こうの大森は絶句という感じだった。大仰に驚いたのはわざとではなく、正直な反応だろう。
多くのお客のネットワークを同じプロバイダエッジルーターに収容するには、ＶＲＦで論理的に分割する。そのルーティング情報を物理的にも論理的にも１本のＭＰＬＳへ一緒くたんに流し込んで、他拠点を収容しているプロバイダエッジルーターへ伝播させる。伝播先のプロバイダエッジルーターで、その雑多なルートの集積から、それぞれのＶＲＦが正しいルートを拾い上げられるように使われるのがルート・ターゲットだ。荷札やタグのようなものと言って良い。各ＶＲＦでどのルート・ターゲットを拾い上げるのか、これをインポート設定と呼んで、ＭＰＬＳバックボーンへ流す時にどのルート・ターゲットを付与するのか、これをエクスポート設定と呼ぶ。基本的にＶＲＦでは、このインポートするルート・ターゲットと、エクスポートするルート・ターゲットは、一致していなければならない。そのため、通常一つのお客がＭＰＬＳ網の中で使用するルート・ターゲットは一つだけだ。
しかし、極端な例になるが、同じキャリアのＭＰＬＳ網を企業ネットワークのＷＡＮとして使っている別々の会社が二社あったとする。各々の会社の企業ネットワークは、通常決して混ざることはない。もし、この二つの会社が合併した、あるいはどちらかが買収したとして、さらに二つの会社で別々のアドレス体系を使っており、混じったとしてもアドレスが被らない前提になるが、至急ネットワークを統合する必要が出てきたとする。その場合、プロバイダエッジルーターで、どちのお客のＶＲＦでも、自分の会社のルート・ターゲットしかインポートしていないところを、この併合した互いの会社のルート・ターゲットもインポートするように設定する。そうすると、この二つの会社は互いのネットワークのリソースに、ＷＡＮルーティング上はアクセスができるようになる。
つまり、基本エクスポートは一つでも、インポートは場合によっては複数にすることはあって、これは会社の統合という理由以外にも利用方法がある。それは地域ごとにデフォルトルートを分けたい場合などだ。
例えば、日本のある拠点と、北米のある拠点から、同一ＡＳパス長、同一メトリックのデフォルトルートをＭＰＬＳ網へ広告し、アジア拠点群は日本発のデフォルトルートを使い、ヨーロッパとアメリカ拠点については、北米のデフォルトルートを使わせたいとしても、そうは意図通りには行かず、各プロバイダエッジルーターのベストパス選択アルゴリズムによりどちらか一方がベストパスとなってしまい、世界中すべての拠点でどちらのデフォルトルートを使うかは、普通制御は出来ない。
この時、デフォルトルートを客宅ルーターから受信している、日本か北米のプロバイダエッジルーターのどちらかで、例えば北米拠点で、エクスポートするルート・ターゲットを他のものと違うものへ変更する。もちろん、この拠点からはデフォルトルート以外にもアジア拠点とだって通信が必要なルートも存在するだろうから、全ての拠点のプロバイダエッジルーターで、インポートするルート・ターゲットを通常のものだけではなく、この北米拠点専用のルート・ターゲットもインポートするようにする。そうすれば、この２つのルート・ターゲットが、このお客のＶＲＦのルートとして、ＶＲＦのルーティングテーブルに載ってくることが出来る。しかし、これだけでは、デフォルトルートの一つがこの北米独自のルート・ターゲットで伝播しただけで、ベストパス選択を意図通りにできるようになる訳ではない。
北米のデフォルトルートを使いたい、アメリカ・ヨーロッパ拠点を収容しているプロバイダエッジルーターでは、ただ二つのルート・ターゲットをインポートをするだけではなく、北米拠点だけが使っているルート・ターゲットを持つルートをインポートする時、ローカル・プリファレンスを高く付与する。逆に、アジア拠点のプロバイダエッジルーターでは、通常のルート・ターゲットを持つルートに、高いローカル・プレファレンスを付与してＶＲＦへインポートする。こうすることで、意図通りのデフォルトルートの使い分けが達成できる。
あるいは、アジア拠点の方が拠点数が多ければ、日本拠点を収容するプロバイダエッジルーターから網内へ広告するときは、ローカル・プリファレンス１５０を付与して、基本的に全ての拠点のプロバイダエッジルーターは、日本発のデフォルトルートをベストパストするようにする。このままだと、北米拠点を収容しているプロバイダエッジルーターでも、網からもらった日本発のデフォルトルートが、北米拠点の客宅ルーターから受信するデフォルトルートよりも強くなってしまい、網内へ流すことが出来なくなる。そこで、この北米拠点のプロバイダエッジルーターでは、客宅ルーターから受信するルートには、ローカル・プリファレンス２００を付与する。今度はこのままだと、網の中で、この北米拠点のデフォルトルートがベストパスになってしまい、日本拠点のプロバイダエッジルーターで同じ現象が起きてしまう。そうならないために、北米拠点のプロバイダエッジルーターで、網内へルートを伝播する際には、ローカルプリファレンスをデフォルトの１００に戻して、網内へ流す。こうすると、基本的に北米拠点以外では、何もしない限りは、日本発のデフォルトルートがベストパスとなるが、北米発のデフォルトルートをベストパスとしたい、アメリカ・ヨーロッパ拠点のプロバイダエッジルーターで、この北米拠点のルート・ターゲットのルートを、ＶＲＦへ取り込む時に、ローカルプリファレンス３００を付与し、意図的にベストパスとする。このやり方でも、意図通りにデフォルトルートを使い分けることができる。
設計の仕方は要件などに応じて色々あるが、このように複数のルート・ターゲットを使うことにより、網内で意図的にルーティングを操作することが出来る。もちろん、回線断があった時の、ベストパス切り替わり、回線復旧時の、ベストパスの切り戻りなど考慮し、慎重な設計は必要になる。
そして今、この一部通信不可に陥っているお客ネットワークでは、３つのルート・ターゲットを使っていた。マルチ・ルート・ターゲットをデフォルトルートに使っているわけではない。お客の子会社のネットワークが、お客のＬＡＮの向こうで、別キャリアのＭＰＬＳ網を使い拠点を広げている。ある子会社ネットワークから、本体会社のネットワークへの接続ポイントが、日本とアメリカのある拠点の二つあり、同一ルートがその接続ポイントから本体会社のネットワークへ伝播するので、意図的にどちらかを経由とするよう操作をするため、また別の子会社のネットワークから本体会社ネットワークへの接続ポイントは、アジアのある拠点と、ヨーロッパのある拠点の二つになっており、やはり同一ルートがその接続ポイントから本体会社のネットワークへ伝播するから、どちらかを経由するよう意図的に操作をするため、この３つのルートターゲットを使い分けて、網内ルーティングの設計をしている。
都がこのお客のＳＥを担当した時にはすでにこの設計は入っていて、最初資料を見た時は、こんなこと出来るんだと本当に驚いた。ＭＰＬＳは「網」と表現されるように、ネットワーク図に書く時には、雲か丸ひとつで表現され、あたかも一つのルーターに、客宅ルーターを放射状に接続していくようなイメージだったから、こんな細かい操作ができるんだということに、感嘆の声を漏らしてしまったものだ。ＭＰＬＳのバックボーンの構成がどうなっているのか、ルーティングをどうしているのかにも興味がすごく湧いた。プロバイダエッジルーターやルートリフレクターなどのコンフィグを良く見て研究し、シミュレーターでＭＰＬＳを自分で構築したりすることで、論理的に覚えるというよりは、作って試して行くことで体に染み込ませて、肉体的な感覚で設計を覚えていった。
この特殊なルート・ターゲットの処理をしている拠点の構成が変更になり、さらにローカル・プリファレンス処理をしているプロバイダエッジルーターの収容の変更と増加があるプロジェクトがあった時、全体の設計をするために都は検証もし、実際にその工事を成功させたことで、さらに理解も進んだ。この検証の時は、シュミレーター上で２０台近くのルーターを動かさなくてはいけなくて、当時のシミュレーターソフトのバージョンだと、なんとか２０台は動くけれど、どんなにアイドル値を調整しても、メーラーすら使えないし、時々クラッシュしてしまったりして、苦労したものだった。今のバージョンだとアプリケーション自体の動作が当時よりもう少し快適だが、逆に１３台程度以上は、都が使っている通常端末では動かすことが出来ないから、もうこの検証は、職場の通常端末では出来ない。
「あー…。それですかー…。うわー、まじかよー。」
大森もこの特殊網内設計はだいたいは知ってはいるが、詳細については明るくないので、都は設計内容を簡単に説明し、それが更改したルーターに漏れていて、今の現象になっていることを伝えると、大森は率直な感想を漏らした。当初トラブルチケットが上がった時は、お客のＬＡＮ起因だと高を括ってしまっていただけに、落胆も大きい。それはこの後お客に一次報告しなければいけないこともそうだが、その後の報告書の提出や謝罪など、重たい仕事がやってくることも保障されてしまったのだから。
このお客のネットワークでは、アジアのある拠点からデフォルトルートが網内へ流れていて、それを使わない拠点は、客宅ルーターからＬＡＮ側へ流さないようにしているのだが、問題となっている南アジア拠点はこのデフォルトルートを使う拠点だった。そのため、網へデフォルトルートが向いているので、この特殊設計が漏れていたとしても、通常はこのデフォルトルートで救済できるはずで、事実今現在このマルチ・ルート・ターゲットのインポート漏れにより、客宅ルーターへ降りてきていない他のサブネットへのルーティングは救済されている。しかし問題となっている宛先サブネットについては、自拠点の大きいサブネットに含まれてしまうので、ロンゲストマッチでＬＡＮへ戻ってしまっている。
大森は東京の保守担当のマネージャーから、海外オフショアセンターの保守のマネージャーへエスカレーションして、大至急直すように伝えるとのことだった。その際何が足りないか、きちんと伝えたいから、都に具体的な内容をまとめてもらえないかと依頼してきた。都は、漏れているルート・ターゲットをこのお客のＶＲＦに取り込む設定を追加すれば良いだけだから、そのルート・ターゲットを羅列して、取り込むべきＶＲＦを大森にすぐ書き送ると伝えて、電話を切った。
都はログインしているプロバイダエッジルーターから、ＶＲＦのルート・ターゲットのインポートの設定の部分と、そこで定義されているコミュニティリストの中身を定義する部分ををコピーし、空のテキストファイルに貼り付けた、これを専用端末でも通常端末でもアクセスできるサーバーを介して、通常端末へダウンロードし、後は現在こうなっているのを、こうしてほしいという書き方でメールに書けば良い。足りないルート・ターゲットは諳んじているが、念の為設計資料からコピー・アンド・ペーストする。手が震えてしまっているが、作業は出来ている。
都が大森へのメールを書いて、内容を確認し、送信したところで、席の島と島の間を通って、岸谷と門乃園が何か話しながら都の席の方へ歩いてきた。大森との電話の前、都と岸谷とで検収したルーターを片付けようとしたら、天板が少したわんでいるのを発見してしまった。都が電話中に、門乃園が岸谷と一緒にそれを確認してから、同一機種の在庫をこれの他にも３台確保しているから、それを見に行こうと言って、倉庫になっているラックスペースへ岸谷と二人で行ったのは、都は大森と話しながらなんとなく聞いていた。在庫の確認が終わって二人は帰ってきたようだ。力仕事なのに、二人で行かせてしまって、手伝いもせず申し訳ないと思っていたから、ごめんね、と出迎えようとしたが、二人が手ぶらなのに気がついて、頭がルート・ターゲットのトラブルで一杯になっていることもあり、言葉が出てこなかった。
門乃園はいつもの品を感じさせる口調ながら、笑うしかないよ、という感じで言った。
「みやみやー、在庫で確保した同じ機種、全部天板ゆがんでたー。」
「えーーーーー！」