12-01
12-01
翌朝は危うく寝坊しそうだったが、無事いつも通り、定時の２０分前にはオフィスについていた。一日休むと、相変わらずメールが７０通ほど溜まっている。まずは昨夜岩砂から送られているはずのメールを探し、見つけると、もう一度添付のログを開いて、昨日岸谷のスマートフォン越しに見て下した判断が間違っていないか確認する。大きいディスプレイで見た方が、見やすいは見やすいのだが、１０年くらい前の古い型のディスプレイなので、岸谷の新しいモデルのスマートフォンの方が、文字の表示などは滑らかなのは笑ってしまうしかない。今日見直しても、昨日と同じ結論にしかならない。この件に関するメールはこれしかないようで、岩砂は本筋のやりとりに都をＣＣはしなかったようだ。
水曜に結局ＷＡＮ開通出来なかった回線についてのメールは、その水曜、工事開始前に岩砂が、工事が始まったのかどうか尋ねたのに対し、現場作業員が現着したのでこれから開始する、という海外オフショアセンターからの回答が最後になっており、その後どうなったか全くわからない。都は専用端末から、対象回線が収容されるプロバイダエッジルーターにログインし、当該客のＶＲＦに関するコンフィグだけを抜き出して表示させるコマンドを叩き、対象回線が収容されているインターフェイスを特定して、そのインターフェイスの状態を確認するコマンドを叩く。インターフェイスは上がっているが、プロバイダエッジルーターのインターフェイスは、物理的には回線を収容するプロバイダエッジのスイッチとトランク接続をしているため、論理インターフェイスなので、プロバイダエッジルーターのインターフェイスが上がっているからと言って、回線が上がっているとは限らない。都は客宅ルーターのＷＡＮインターフェイスのＩＰにｐｉｎｇを打ってみるが、不達だ。一応、プロバイダエッジルーターと客宅ルーター間のＢＧＰのピアが上がっているか確認してみるが、当然のように落ちている。結局水曜は都が帰った後も上がらなかったようだし、昨日も、もっとも昨日トラブルシューティングをしたのかどうかもわからないが、上がらなかったと言うことだ。これはしばらく忘れてしまってもいいくらいかもしれない。都は小さくため息をついた。
メールを大体片付け終わったので、都はスケジューラーを確認して、近づいてきている工事があるかどうかチェックした。来週は月曜と金曜が祝日で、実質三日だけの勤務だ。しかも三連休が二回連続でやってくる。しかし、その週末の土曜に都は工事が入っていて、三連休の片方が三連休にならない。その上三連休の真ん中に工事が入っているという、この職場で一番歓迎されないパターンの休日工事だ。休日、平日に関わらず、工事は短時間で順調に終わった方が良いのだが、休日工事の場合、短時間で工事が終わってしまうと、今度は丸一日代休というのが取れなくなる。構築担当の仕事をしていれば仕方のないことなので、どうしようもないのだが、普段は工事は早く終わった方が良いのに、休日工事の時だけ、あまりにも順調に短時間で終わると、微妙だ、と言う同僚は少なくない。かといって、休日工事の際、トラブルで８時間以上もかかるような工事は、こちらの不手際でそうなってしまった場合に限らず、後日の後処理は大変になることが多い。その対応ですぐに代休を取ることができず、また残業も増えてしまって、良い事は何もない。もっとも、週末工事が短時間で終わったのであれば、その日は単純に休日出勤として、平日に消化しきれない有給休暇を当てて休む、というのもありだ。都は、代休なんか取れなくなっても良いから、どんな工事でも無事に早く終わって欲しかった。
その土曜の工事は、ヨーロッパのある拠点の移転だった。ＤＣと呼ばれる拠点とオフィスと呼ばれる拠点とが、相互バックアップ関係で存在するのだが、今回の移転はＤＣの方だった。ラック賃借契約が切れるに伴い、データーセンター内の別棟の別ラックへ移転するとのことだ。回線については、データセンター内に現地回線キャリアのノードがあり、そこから構内配線のみを新規で新ラック向けに敷設し、工事当日、客宅ルーターやお客機器の移設と同時に、回線キャリアがキャリアのノードで切り替える。来週土曜の工事はいわゆるホットカット切り替え、ＷＡＮ・ＬＡＮ同時切り替えになる。
オフィスと呼ばれる拠点と、このＤＣと呼ばれる拠点とは、都たちのキャリアから見ると、裏から別回線で接続されており、この２拠点間の通信は、別回線経由で行い、他拠点へは都たちのＷＡＮ経由で行う、というルーティングになっている。どちらかのＷＡＮが切れた時は、他拠点に対して別回線経由でバックアップ、また別回線が切れた時は、両拠点間の通信についてＷＡＮ経由でバックアップと、相互にバックアップをする必要があるので、設計にちょっと工夫が必要だった。ただ、工夫が必要なのは何も都たちの客宅ルーターだけではなくて、お客自身のＬＡＮルーターでも必要だ。ＤＣ拠点と、オフィス拠点では、ＬＡＮ側のルーティングプロトコルが異なっていて、当然お客の別回線を終端しているルーターで相互再配送や、必要に応じてルートの集約、ＡＤ値の変更などを実施しなくてはならない。この辺りでトラブルが起こる予感しかないので、色々なトラブルパターンを考えておいた方がいいかもしれない。オフィス拠点の方はＯＳＰＦなので、ＬＳＡの情報からお客ＬＡＮ内の構成は概ね把握できるのだが、移転対象のＤＣ拠点のＬＡＮ側は、客宅ルーターとして採用しているメーカー独自のルーティングプロトコルを使っており、構成の把握はＯＳＰＦ程には出来ない。
都はこのヨーロッパ拠点を持つお客担当のＳＥとしてアサインされた時、最初の仕事がこの拠点のルーティング不具合対応だった。前任のＳＥの設計ミスが一つ、それとお客機器での設計ミスが一つあり、複合要因でルーティングがおかしくなっていたのだが、それほど難解な事象でもなく、原因の特定に時間もあまりかからなかった。現地ヨーロッパのお客がかなりうるさいらしく、最初依頼を受けた時、ＰＭが気を揉んでいたのを覚えていた。しかし、欧米系のお客担当者には多いように、トラブル時は非常にプレッシャーを掛けてきていたようだが、解決してしまうと、サンキューと感謝の言葉で締めて、それっきりになってくれた。日本のお客の場合は、一つでもこちら側に責があった事項があれば、まず報告書の提出から始まり、課長以上の役職者の謝罪訪問まで求められることは少なくない。下手をすると複数回求められることもある。
今回の移転に関するヒアリングによると、ホットカット切り替えということもあり、都たちの客宅ルーターのパラメーターには、何一つ変更がない。そのため都たち的には、移転先へＬＡＮを切り替えた後何かトラブルが起こっても、客宅ルーターの事前事後のコンフィグを比較して差分がないことさえ確認出来れば、こちらはヒアリング通りやってますと言い切れる。しかし、工事を終わらせるには、お客起因のトラブルでも切り分けや対応策の提案などをしなくてはならなくなるだろう。
都は事前に移転前のＤＣ拠点、それとオフィス拠点、双方のＬＡＮのトポロジーを、それぞれのＬＡＮで回っているルーティングプロトコルの確認コマンドを使って把握しておこうと思った。以前のトラブル対応の時に、大体は把握したが、当時はこのお客担当のＳＥにアサインされたばかりで、お客のグローバルネットワークの全体設計を理解できていなかったし、その時のメモ書きや手描きの図を残していなかった。残していたとしても、現状とはＬＡＮ内で構成の変更があったかもしれないので、どちらにしろ最新の状態を把握する必要がある。
ラック移転に伴い、お客のＬＡＮ構成が全く変わらなかったとしても、一旦お客のＬＡＮ機器は全断にするわけだから、この全断後の復旧では、見落とされていた、たまたま今まで発生せずに済んでいた、潜在的な問題が露呈することがある。客宅ルーターの設計に何も変更がないからと言って、トラブルが起こらないとは限らなかった。お客のＬＡＮ構成が移転ついでに変わるのであれば、お客起因のトラブルが発生する確率はさらに高くなる。
専用端末に向かって、その両拠点のルーターのログイン情報を得るために、客宅ルーターのコンフィグ情報などを集積しているデーターベースを開いたところで、岩砂から声を掛けられた。
「間宮さん、昨日は突然連絡してしまってすいません、お休みのところ、しかも夜分に。」
岩砂は手を脇に揃えて、変にかしこまって言うので、都も椅子を回転させて、岩砂の方を向いてから、いえいえ、とんでもないです、と膝に手をついて頭を下げた。
「で、昨日の件なんですけど、プロダクトに確認したんですね、そうしたら、他のキャリアとＮＮＩサービスを開始する時って、お互いのルートをどう扱うかってきちんと決めているらしいんですね。まあ、当たり前っちゃ当たり前なんですけど。」
他キャリアのＭＰＬＳとＮＮＩサービスを開始する際は、プロダクトを担当する部署で他キャリアと、物理接続から論理接続、ＢＧＰでの接続に関する決め事などを整理し、一定のポリシーとして策定する。サービス開始後は、そのポリシーに則って、接続済みのトランクでユーザーのＶＲＦを紐づけるＶＬＡＮを合わせて繋いでいくだけになる。今回問題になっているキャリアにかかわらず、互いに受信するルートについて、デフォルトの１００以上のＬＰ値を付与するルールになっているキャリアはないという。ＮＮＩポイントである、二箇所でのＡＳＢＲ同士の接続が、明確にメイン・バックアップ構成の場合は、バックアップ側について、１００以下のＬＰ値を付与する場合もあるが、複数のＮＮＩサービスと接続する構成のユーザーで、この操作したＬＰ値がルーティングに影響を与えることがあるので、あまり都たちのキャリアからは積極的には提案していない、ともいう。
「このキャリアのＮＮＩって、いわゆる近い方がベストパス、でしたっけ？」
都は聞いた。自網のＡＳＢＲが、ある拠点から自網のプロバイダエッジルーターを介してルートを受信する時、網構成によって若干異なるが、網内では、あるＶＲＦの、とあるルートについてのネクストホップは、そのルート元のプロバイダエッジルーターのループバックアドレスになる。ループバックアドレスへのルートは、このＶＲＦのルーティングテーブルには載っておらず、グローバルルーティングテーブルに載っており、複数のＶＲＦを束ねることのできるＭＰＢＧＰのネクストホップとなる。網内でＭＰＬＳやＭＰＢＧＰを動かすために、ＯＳＰＦなどのＩＧＰをグローバルルーティングテーブルで回す。それによって、網内ルーターやプロバイダエッジルーター間でルート情報のやり取りをし、プロバイダエッジルーター同士で、互いのループバックアドレスを知ることになる。ＡＳＢＲもプロバイダエッジルーターの一つだから、この動きの中で、自分のループバックアドレスを広報し、他のプロバイダエッジルーターのループバックアドレスへのルートを受信する。
ＶＲＦルートの配信元プロバイダエッジルーターの、ループバックアドレスへのＯＳＰＦルートには、ＡＳＢＲが受信した時、当然ＯＳＰＦのメトリックがついている。例えば網内構成で、プロバイダエッジルーターが地理的に遠くなれば遠くなるほど、ＯＳＰＦコストが嵩むように設計してあれば、ＭＰＢＧＰのネクストホップである、プロバイダエッジルーターのループバックアドレスへは、最短距離のルートがグローバルルーティングテーブルでベストパスとなり、このループバックアドレスへのＯＳＰＦのメトリックが、ＶＲＦのＢＧＰルートにおけるネクストホップへのメトリックとなる。もちろん、最短距離ではなくて、バックボーンのパスで帯域に余裕のあるところを通すように、意図的にコストを操作し、最短距離ではないプロバイダエッジルーターのループバックアドレスへのルートをベストパスとさせることも可能だ。ただしこれは、基本的に、同じＡＳ内での話である。
通常、異なるＡＳ同士のＢＧＰピアリング、この場合だと、都たちの網と、問題となっているメイン側のキャリア網との接続では、ＢＧＰルート送信の際、この一つのＡＳ網内で有効なネクストホップアドレスへのメトリックは伝播されない。しかし設定によって、意図的にネクストホップアドレスへのメトリックを、ＢＧＰメトリックとして伝播させることが出来る。そうした場合、例えば、ＡＳＢＲ同士の接続が、一箇所が東京、もう一箇所が東南アジアにあったとする。都たちの網内から日本のルートを、接続先の別キャリアへ伝播させる時、都たちの網内バックボーンのＯＳＰＦのメトリックが距離に応じていると仮定すると、東京のＡＳＢＲの方が、東南アジアのＡＳＢＲよりも軽いネクストホップアドレスへのメトリックを持ったルートになっているはずだ。このネクストホップアドレスへのメトリックをＢＧＰメトリックとして、接続先のキャリアへルートを伝播させる時に付随させると、その別キャリア網から、都たちの網の日本拠点へたどり着くには、たとえ南アジアの拠点からでも、そのキャリア網内の、東京のＡＳＢＲへ一旦向かい、ＡＳＢＲ間の接続を渡り、都たちの網へ入ってくるようになる。他キャリアのローカルの拠点から日本拠点への上り通信は、都たちの網から見て近い方のＡＳＢＲを使用する、ということになる。逆方向も同じような接続方式になっていれば、同様になる。つまり、日本の拠点からその網の南アジア拠点へ行くには、一旦都たちの網の東南アジアのＡＳＢＲへ向かうことになる。
このように、二つのキャリアの網を相互接続した際、一つの網の拠点から、別の網へ抜けていく場合、別の網の宛先拠点から見て、最小メトリックのＡＳＢＲを使わせるようにルーティングすることを、コールド・ポテトという。これは一般的には、宛先網のバックボーンよりも、送信元網のバックボーンの経由経路が長くなり、バックボーン内の帯域消費などのリソース負荷も、送信元網の方が大きくなる。ホット・ポテトは、これとは逆で、接続先の網から受信するルートのメトリックは０としてしまうことなどにより、送信元から見て、メトリックが最小になるＡＳＢＲから、宛先網へ出ていくようにするルーティングのことを言う。こちらは宛先拠点の網の方が、バックボーンの経由経路は長くなり、バックボーン内の帯域消費などのリソース負荷も上がる傾向になる。
「はい、そうですね。」
岩砂は首肯した。送信元網から見て、コールド・ポテトだということだ。
「だとすると、ＬＰ値つけちゃダメですよねえ。」
順序が下のタイブレークを使って、ルート制御を行うことで両キャリア取り決めているのだから、それより順序が上回るタイブレークを、ＡＳＢＲを含む網内のプロバイダエッジルーターで使ってしまっては、この前提が崩れてしまう。ＢＧＰメトリックより前に評価されるタイブレークは、基本的にお客ＶＲＦ全体のネットワーク設計によって、客宅ルーターのコンフィグで使用するべきものとなっているはずだ。
「そうなんですよー。なので、こっちのプロダクト担当と、向こうのプロダクト担当とで一回話話し合ってもらうことになりました。」
一旦都たちの部署で対応することはなくなったが、お客には冗長構成が使えないという実影響が出ているので、岩砂がプロダクト担当に進捗を確認したり、ＳＩで客宅ルーターを提供しているＳＯ部に状況を共有したりするという。
「なので、直りました、とか言い出した時に、ログをもらうことになると思うんで、またログ見てもらったり協力をお願いしてしまうかもしれませんが…。」
岩砂は申し訳なさそうに言った。
「あ、はい。全然構いませんよ。じゃあ、また進捗あったら、教えてください。」
「ありがとうございます！」
岩砂は、いつもの勢いのある言い方で、ちょっと大仰に礼を言うので、都は否定を返した。その後、例の南アジア拠点のＷＡＮ回線の話題になって、本当にしばらく開通しなさそうだ、一昨日昨日って何かやってたんですかね、と都が聞くと、何もやってないんじないですかね、と岩砂も投げやりなので、都は笑ってしまった。今日、海外オフショアセンターの日中帯の勤務時間が始まったくらいに、向こうの本件担当者に電話して進捗を確認してみると岩砂は言って、会話は終了となった。岩砂はありがとうざいます、と言って自席へ戻ろうとするので、都もありがとうございます、と言って見送った。
岩砂は、岸谷と都のデート云々の話はしなかった。話の前後が分かっていれば、それが冗談だとわかるが、万が一、岩砂が都に対し、デートの邪魔をしてすみません、とでも言ったところだけ、周りの誰かに聞きかじられると、変な噂が広まってしまうかもしれない。都は、ちょっとそれを心配していたし、余計な詮索が、なんとなく噂で聞こえてくるようになるのは嫌だなと思っていたのだが、岩砂はおそらくそこまで気を回してくれたのだろう、一切その件は触れてこなかった。普段の都と岩砂の間柄からして、ふざけて言ってしまっても良いようなことだったから、その気配りはありがたかった。