13-05
13-05
海外拠点について、都たちのルーターのＬＡＮ側と、ベンダー設置のルーターのＬＡＮ側とは、デフォルトゲートウェイ冗長プロトコルで接続するのかどうか、都はベンダーに聞いた。ベンダーは回答をお客に促すと、お客が都の想定で合っていると答えた。メイン側は都たちのルーターで良いのかも確認したが、これもお客が肯定した。
「そうであれば、最初から私たちのルーターのＬＡＮ側に、バックアップルーターへ向けて、プライベートアドレスの集約３本をスタティックで設定しておけば良いと思います。集約の中身については、先程の国内の時と同じく、ちょっとお客様で精査いただく必要はありますが、マイグレが終わっていない拠点へのパケットが私たちのルーターに上がってきたら、ＷＡＮからルートをもらっていませんので、ロンゲストマッチでこのスタティックルートに乗って、バックアップルーターへ渡ります。あとはバックアップルーターから、当該拠点へのＩＰＳｅｃに乗せていただければ良いと思います。マイグレ前の拠点からの戻りは、同じ経路しか辿れないので、問題ないと思いますし。」
ベンダーは納得したような顔をしていた。お客は、それであれば設定変更はいらないのかと聞いてきたので、都たちの責任区分範囲では不要な旨答えた。ベンダーも同様な旨返していた。
「１拠点目のマイグレが終わって、２拠点目のマイグレが終わったとします。１拠点目と２拠点目は、私たちのルーターの方がメインとなっていて、それぞれのルートをＢＧＰでもらって来ているので、そのルートがロンゲストマッチになって、私たちの網を通り、お互いに通信することになります。マイグレ前の３拠点目のルートは、ＷＡＮからルートをもらえていないので、私たちのルータに、宛先が３拠点目へのパケットがＬＡＮから到着すると、集約ルートでバックアップルーターへ投げるので、あとは、ＩＰＳｅｃを通って、行って戻ってくる形になるかと思います。」
都は、マイグレが終わった拠点のどちらかで、メイン側の回線に断があった場合も、メインが生きている方の拠点では網からルートが来なくなるので、同じようにバックアップへ回ることが出来ることも説明した。
本社側は、ＬＡＮ側がＯＳＰＦだ。ベンダーのＩＰＳｅｃルーターでスタティックルートの再配送から生成される外部ルートと、都たちのルーターでＢＧＰの再配送から生成される外部ルートとがあることになるが、必ず都たちのルーターからの外部ルートが勝つようにしないといけない。ヒアリングシートで聞くだけでも良いが、一応口頭でも言っておこうと都は思った。
「あと、すみません、本社のＩＰＳｅｃルーターで、海外拠点むけのスタティックルート、ＬＡＮのＯＳＰＦへ再配送されていると思うのですが、コンフィグから察するに、結構強いメトリックで流していると思います。私たちのルーターからの再配送の方が強くなるようにしないといけないので、すみませんが、設計の方、ご検討お願いいたします。」
ベンダーは最初何のことやら、という顔をしていて、お客もどういうことだという顔をし出したので、都は説明しようと、ホワイトボードの本社のあたりに書き足そうと思い、マーカーのキャップを開けたところで、ベンダーの最初に喋った方の男性が、何のことを言っているのかわかったらしく、了解したことと、検討することを口早に言った。お客は、それは別工事、つまり工事費を余計に積まれるのか、と聞いていたが、本社と国内拠点の一つを同時にマイグレする時に、他の設定変更と一括で工事費を積んでいるので、追加費用はない旨説明していた。
これら移行ルーティングに必要な集約ルートの、ヒアリングシートへの記載方法ついて、都は説明を続けた。海外拠点のバックアップルーターへ向ける集約ルートについては、各拠点ルーターのスタティックルート欄に書いてもられれば良く、スタティックルートの欄には備考欄もあるので、そこにバックアップ用だというようなことを書いておいてもらえれば良い。本社については、ＢＧＰの広告ルート欄に、広告すべき集約ルートを書いてもらう。ＢＧＰ広告の元となるスタティックルートについては、ＬＡＮ内のベンダー管理のコアスイッチで作るのであれば、それをただ伝播してもらえれば良いので、特にＢＧＰ広告ルート以外には記載はいらない、もし都たちのルーターで作るなら、ネクストホップの指定とともに、本社のスタティックルートの欄に書いてもらえれば良い。
「ＢＧＰ集約みたいなのはやってもらえないんですかね？」
ベンダーが、どこか面倒をこちらへ押し付けるような、含みを持った調子で聞いてきた。都は、やれるがＮｕｌｌ０ルートが出来てしまうから、それがブラックホールになって問題を引き起こさないのであれば、大丈夫だと言った。ベンダーとお客は黙ってしまった。都は、通信必要な細かいルートについては全てＯＳＰＦでもらえるのであれば、問題はないが、一応確認した方が良い旨、追加した。やはり誰からも明確な反応はない。
「良くご検討いただいて決めていただければと思います、ＢＧＰ集約の場合は、広告ルートの欄にも備考欄がありますので、そちらに、ＢＧＰ集約で、と書いておいていただければと思います。」
都は少しお客の反応を待ったのだが、理解したのか、理解できなかったのか良くわからなかったので、とりあえずヒアリングシートの記載方法につていの説明を続けてみた。お客はわかりました、と答えたので、わかったようだが、後でベンダーと詳細については話すのだろう。ベンダーは問題の所在を、自分たちにないようにするにはどうしたら良いか、考えているようだった。
「じゃあ、これで移行期間のルーティングについては大丈夫な感じですかね？」
恰幅の良い方の客が、ベンダーに聞いた。ベンダーのＰＣを操作している方の男性が、ひとまず良いと思います、と返すと、もう一人のベンダーの男性も頷いていた。やはり、この都が喋った移行設計は、別に見新しいものでも何でもなくて、ベンダーの方で既に検討されたものだったということだ。それについて自分たちで責任を負いたくないから、移行先キャリアのエンジニアを呼んで、喋らせて、喋ったことでキャリアのエンジニアの設計だ、ということにし、何か不測の問題が起きた時の責任から逃れようということだろう。もし自分たちの想定と違うようなら、今都が受けたように、指摘をして、自分たちの想定した移行設計に、キャリアのエンジニア自ら辿りついてもらおうという意図だったのだ。万が一都が全く当てにならない移行設計を言ってきたら、キャリアのエンジニアを論破し、ベンダーの技術力の優位性をお客へ印象付け、移行設計の付加価値をお客に認めさせ、このＷＡＮ更改で請け負う見積もりの増額を狙っていたのかもしれない。
都は、引っ掛けられたかな、と思ったが、そもそも営業が移行設計もこちらで見てしまいますよ、という姿勢だから、助けはどこからもこない。一度責任区分範囲を超えて協力してしまうと、それが当たり前になってしまう危険がある。しかしそのことで、お客があてにしてくれるようになり、お客とのコミュニケーションが増え、海外の回線敷設で問題が起きた時に、ハレーションを抑えることが出来ることもある。もっとも、お客側の対他社対応の文化や、担当者の性格にもよるので、いつもこういう良い面が強調できるとは限らない。ただお客担当者をつけあがらせ、不毛な対応のみが増える場合もある。
「では、あとは私たちのＶＰＮの方へ曲げて欲しい通信についてなんですが…。」
ＰＣを操作している方のベンダーの男性が、スライドをいくつか進めた。途中に、ステップ２、ステップ３などと、海外拠点が移行していく図があった。流されてしまったのできちんと見えていないが、やはり検討済みだったということだ。
表示されたスライドには、既にマイグレーションが完了した後の、簡略化された想定ネットワーク図が描かれており、本社のＬＡＮの中に、サーバーのアイコンが置かれていて、アドレスとポート番号が傍に添えられている。そこへの通信ということだろう、海外拠点のＬＡＮから曲線が始まり、都たちが設置するルーターに一度辿り着いてから、折り返し、ベンダーのインターネットＶＰＮルーターへ向うと、ＩＰＳｅｃトンネルを通って、本社のサーバーへ矢印で辿り着いている。逆方向も同じようにサーバーから一旦都たちのルーターへ辿り着いてから、折り返し、ＩＰＳｅｃトンネルを通って海外拠点へ矢印で戻っている。
「本社のこのサーバーと、海外の端末との間で、頻繁にデータのやり取りをするのですが、まあ、結構大きいファイルのやり取りがちょくちょくありまして、結構帯域を占有してしまってですね、海外拠点の業務に差し支えが出ることが多いので、このサーバとの通信だけ、ＰＢＲでインターネット側へ曲げていただけないかなと思っております。」
「で、これをどうヒアリングシートに記載して良いかちょっとわからなくてですね、お伺いしたいな…と。」
ベンダーの説明の後に、背の高い方の客が付け足していた。ＰＢＲ、ポリシーベースルーティングとは、ルーティング通りにパケットを転送せず、意図的にルーティングとは異なるネクストホップへパケットを転送するルーティングのことだ。このお客のように、複数回線の有効利用のために使われたりするが、設定の複雑さ、行きと戻りでも揃える場合さらに煩瑣になる設計、意図的に曲げた先のパスの死活監視の難しさ、設定変更が発生した場合の考慮点・実施箇所の増加、さらには保守に渡されてから、ＰＢＲ部分でトラブルになった場合、特殊な設定のため、通常の保守担当者がコンフィグを読み取るハードルも高く、保守資料を別途作成しなければならない構築担当者への負荷、などがあって、都がいるＭＰＬＳサービスの構築担当では、基本的にネットワーク・インテグレーションとしては避けるべきとされる設計だ。トラフィックを意図的に曲げたい時は、極力お客機器で責任を持ってやってもらう、というのが取るべき対応となっている。
都が働くＭＰＬＳサービスの構築担当では、ＰＢＲに限らず、特殊な設定が必要となるような要件については、まず断るのが基本姿勢とされている。しかし都は、設計やコンフィグで可能であるのであれば、出来る限りやってしまうことにしていた。それは断るのが苦手な都の性格もあったが、出来るだけお客が希望していることは叶えてあげたいという、サービスを提供する側で働くネットワークエンジニアとしての思いもないわけではない。何でも出来かねますで断るのも、それは違うと思っていた。もっとも、基本的に特殊な要件は断る、と言う姿勢には、出来るだけ設計・設定から複雑なものを省いて行き、結果的に構築や保守で余計な稼働を減らすことで、総合的な業務の円滑化、利益率の上昇というビジネスとしては大局的な目的がある。どちらかと言えばそちらの方が正しいのだろう。
「サーバーへの通信は、海外から見て、宛先アドレスと宛先ポート番号は、その図に書いてあるもの固定だと思って大丈夫ですか？」
都は席に戻るタイミングを逸していたので、ホワイトボードの前で立ったまま聞いた。
「はい、これで大丈夫です。ですので、ＡＣＬ内の宛先アドレス、宛先ポート番号を、これで指定できるはずです。本社側では送信元に読み換えれば良いだけです。」
ベンダーはそう答えた。つまり、都たちキャリアが客宅ルーターとして提供するメーカーの筐体では、ＰＢＲをコンフィグする際、アクセスリストで対象パケットを指定する、という設定方法を知っているということだ。要するに、出来ないとは言わせない、という意味だ。そういう圧も感じた。
「…このサーバーとの通信を、バックアップ側へ曲げるのは出来そうですが、曲げた先のパスの監視はどうしましょうか。」
都は聞いた。ベンダーとお客は、全員何のことを言っているのかわからない、という顔をしていた。一瞬、ＰＣを操作しているベンダーの男性の顔には、この女難癖つけてきたのか、といった不満か怒りのような色が宿った。都には強い緊張が走る。向こうも、こちらに敵対心のようなものを持っていたということだ。
「あの…。曲げるのは良いんですが、バックアップ側が落ちた時、私たちのルーターはそのサーバーへのトラフィックを曲げ続けてしまうので、バックアップが落ちたら、通常のルーティングに従ってパケットを転送するようにしないといけないと思っています。…そうしないと、このサーバーへのパケットは不達になり続けてしまいます。」
都はそう言いながら持っていた青いマーカーをペントレイに戻して、緑色のマーカーを拾い上げた。
「…海外拠点の方でお話ししますが、まずは、バックアップ側のＬＡＮインターフェイスのＩＰをＩＣＭＰで監視します。」
都はそう言うと、海外拠点の、都たちのルーターを表す円をから、ベンダーのルーターを表す円へ、網とは逆側に、監視用のＩＣＭＰを表す曲線の矢印線を書いた。都はちょっと背伸びが必要だった。
「これで、もしＬＡＮスイッチと、バックアップルーターのＬＡＮインターフェイスの間で断があった場合は、このＩＣＭＰの監視のトラッキングでＰＢＲを無効にして、このサーバー宛の通信を通常のルーティングに戻し、サーバーとの通信を成り立たせます。」
都は、書いた矢印線の上の空中で、通信経路を指し示すようにマーカーを動かしながら言った。
「ＬＡＮ側の断はこれで救えるんですが、問題はＷＡＮ側の断ですね…。バックアップ側のルーター、ポリシーベースのＩＰＳｅｃなので、私たちのルーターのＬＡＮから出るＩＣＭＰだけは、バックアップルーター経由でインターネットへ抜けられるようにしないといけないです。しかも、この拠点のＩＳＰのプロバイダエッジを監視すれば良いかというと、それでは本社側のインターネットが落ちた時に、ＰＢＲが止まらないので、ダメなんですね。本社側のバックアップルーターの、ＷＡＮインターフェイスのグローバルＩＰを監視しないといけないです。」
都は、マーカーを指示棒がわりに使って、監視用のＩＣＭＰの流れをなぞりながら言った。客は小さく唸っていた。ベンダーは黙っているが、こちらの言っていることは理解できていて、黙っているようだ。都は続けて、都たちのルーターのＬＡＮインターフェイスからのＩＣＭＰが、ＩＰＳｅｃで暗号化される対象のパケットから除外され、尚且つ、ＮＡＴ対象とされ、インターネットへ出て行き戻って来られるようにし、もし本社側のバックアップルーターでセキュリティのためＩＣＭＰを拒否しているのであれば、このパケットだけは許可してもらうようにしてもらわないといけない、ファイヤーウォールなどあるようであれば、当然行き戻りの許可などが必要な旨、説明した。ベンダーが答えないので、恰幅の良い方の客が、出来るのかと聞いた。ベンダーは息を吸い込んでから口を開いて、可能だと思いますが、考慮すべき点が多いので、と言葉を濁した。細かくあちこち設定をいじることになるだろうから、検討は必要そうだが不可能な話ではないはずだ。ただ、お客へ見積もっている金額は上げないといけない。そういうところで明言を避けているような気がする。変更箇所も多く、面倒だと思っているかもしれない。
「ＬＡＮからグローバルのＩＰを監視するというのは、色々と面倒かもしれないですし、そのために、ＬＡＮからインターネットへパケットを通過させるのもセキュリティ的に懸念があるということであれば、今のポリシーベースで実装されているＩＰＳｅｃを、ルートベースのＩＰＳｅｃに設計変えていただいて、バーチャルトンネルインターフェイスを作ってもらえれば…。」
都はそう言うと、海外拠点のバックアップルーターから、本社拠点のバックアップルーターへ、ＩＰＳｅｃトンネルを表す、円柱を緑のマーカーで書き、本社側の円柱の端に、ＩＰと書いた。さらに、都たちのルーターのＬＡＮから、そのＩＰＳｅｃトンネルを通る曲線を書き、トンネルの本社側の端へ矢印で止めて、会議卓の方を向き直った。
「そうすれば、このトンネルのＩＰを監視すれば良いので、インターネットとＬＡＮとの間で余計なパケットの行き来がなくて良いかな、と思います。バーチャルトンネルインターフェイス使えば、ダイナミックルーティングも使えますし。」
都は、かな、と言うところでちょっと首を横に傾げてしまった。変に可愛子ぶってしまっていないだろうかと不安になった。ベンダーが一瞬見せた責めるような表情から起きた、強い緊張は続いていて、今も都は少し足が震えてはいるが、ベンダーからもお客からもそれ以上に激しい反応はない。都の説明に一定の考慮が必要だと思ってはくれているようだ。技術的に正しいことは言えているはずだという、安堵のようなものも都にはあったので、少し変な気の緩み方をしてしまったかもしれない。お客の、どうなのよ、と言うかなりざっくばらんな聞き様に、ベンダーのＰＣを操作している男性は、腕を組んで、うーん、とこちらも急に緊張感なく唸るので、お客とベンダーで笑いが起こった。都は自分が笑われているような嫌な気持ちがまた起こらないでもなかったが、それでも愛想で頬は緩めることは出来た。