12-06
12-06
デフォルトゲートウェイ冗長プロトコルがフラッピングしている拠点は、都が今緊急で設定を変更した拠点だけではないと言う。都は驚きながらも、一気に今やってしまいましょうか、と言ったが、この拠点のように酷くフラッピングしておらず、お客通信への影響も出ていないので、きちんとアサインされたＳＥに設計し直させ、コンフィグさせ直す、と岩砂は言う。つまり、今日はアサインされたＳＥは二人とも休みか、夜間工事のためシフト勤務だ、ということらしい。それであれば、都は聞いてみることにした。
「あの…。言っていいか迷うんですけど、これ、結構設計としてはいい加減ですよ。ちょっと考えればわかることですけど…。」
「そーなんですよねえ…。」
都のもっともな指摘に、岩砂は申し訳なさそうな同意を示した。設計レビューはしていないのか、と聞いたが、基本既存踏襲であることと、回線数が多いこともあり、あまりやっていないと言う。ＳＥ二人には、ダブルチェックをするように依頼はしてある、と言う。
「それやってますかね…。」
都は素直な感想を述べた。
「やってはいると思うんですけどねえ…。」
岩砂はそう言うが、もしやっていたとしても、そのＳＥ二人の、この案件に対するやる気というか、取り組み具合が同じだと、こういう設計ミスは見落とされるような気がした。見落とされている、のではなく、この設計はおかしくはない、と判断されているのかもしれない。
設計は既存踏襲、という時、本当に全く同じ設計にする場合と、現時点での目線から、設計の調整をする場合とがある。それはプロジェクトの志向によっても変わるし、担当するＳＥの志向によっても変わる。
しかし、古くから運用されており、長い間全く動きのなかった拠点などの、こういった契約更改に伴うプロジェクトでは、担当者が変わったりして、今となってはなんのために入っているのかよくわからない設計やコンフィグを、どうするかが問題になることがある。こういった場合、現在の担当者が調査・考察すると、今は意味をなしていないと考えられるコンフィグでも、既存踏襲、という言葉のもと、残すことは多い。そうしてしまうと、それがまた数年経って、担当者が変わった時、再度謎のコンフィグとして残ることになってしまうとしても。このやり方は意外に幅を利かせていて、既存踏襲というと、ＷＡＮのＩＰや、インターフェイスアサインなど、切り替えによってどうしても変更になる箇所を除いては、そのままのコンフィグをコピー・アンド・ペーストしてしまうプロジェクトは多い。
今回、都が見たもののように、ＩＴの利用状況が現在とは全く異なる、構築当初はそれでも良かったのかもしれないが、今は通用せず、深刻な影響を与えるような古い設定が、そのまま残ってしまい、切り替え時に問題が発覚すれば良いが、構築段階では発覚せず、保守に入ってからすぐに発覚して、大問題になったりする。切り替え後かなり時間が経ってから、問題が発覚することもあり、そうなると、切り替え構築当時は既存踏襲の設計で合意していたからと、責任の在処は有耶無耶になりがちだ。結果、問題がその場で解決しても、その後のプロジェクトや工事について、要改善・要検討事項として受け継がれず、根本的な対策はおざなりにされることが多い。
既存踏襲というと、そのままやれば良いんだと、ＳＥ的には一見楽なプロジェクトに映るのだが、落とし穴は結構多い。都は、自分が今まで関わったことのないお客案件や、自分が担当しているお客でも初めて触る拠点の工事で、既存踏襲の場合、基本的にはコンフィグは全部見直すようにしていた。何に使っているかはっきりしないコンフィグについても、意味をなさないと判断できれば、基本は消してしまう。もちろん、意味をなさない、と判断できなければ、残すしかなくて、嫌だな、と思うこともあるが、自分の考えの正しさを立証できない限りはどうしようもない。
都はそんな仕事のやり方をしているから、この岩砂の案件のトラブルはちょっと信じられなかった。どう見たって、見直すべき箇所でトラブルになっている。
「既存踏襲、だからそのままにしました、ってことですかね？」
都は聞いた。
「そうかもしれませんねえ…。」
岩砂は、遠くを見やるような視線を上に向けて、そう言った後、一度プロジェクトとして、設計方針をどうするのか、プロジェクトメンバーで良く話し合うことにする、と言っていた。都はその方が良い旨答えて、この件はお役御免にしてもらった。
都は自席に戻る前に、植松の席に寄った。彼の席は通路側の角なので、横から覗き込むようにして声を掛ければ良かった。電話もしていないし、声をかけても良さそうだ。
「植松くん、ごめんね。で、何かな？…つか、今大丈夫？」
都は相手の都合を考えず、自分の用向きばかり言ってしまっていることに、笑ってしまいながら、植松の都合を聞いた。
「あー。こちらこそほんとすみません、お忙しいのに。」
植松は、待ってましたよくらいの勢いで迎えてくれたが、これは彼が気を遣ったのだろう。
「で、どーしたの？」
都は少し首を傾げながら聞いた。
「あのですねえ…。」
植松はそう言うと、立ち上って近くの柱の側に置いてあった丸椅子を持ってきて、都に座るよう促した。都は礼を言ってから座ったが、座らせたということは長いんだな、と思い、ＣＭの大森から受けている相談に返事を書いてからにした方が良いだろうか、と少し悩んだ。都の席の方からは、通る声で、それは難しいですね、と突き放すようでもなく、かと言ってどこか阿るような調子でもない、きちんとした言い方で電話の向こうに話しているのが聞こえる。岸谷が統制している国内案件の工事は、まだトラブル中らしかった。
植松の相談事は、植松がＰＭをしている案件で、お客さんから来た設計変更の相談について、どうしたものかというものだった。そのお客は、日本にあるＤＣ拠点が冗長構成なのだが、網からその日本ＤＣへの下りトラフィックについては、ロードシェアリングになるよう、同じサブネットを２台の客宅ルーターから網へ広告している。この２台の客宅ルーターは、ロードシェアリングを実現するため、異なるプロバイダエッジルーターに収容されており、それぞれのプロバイダエッジルーターで異なるルート識別子を、その客用のＶＲＦにアサインしてある。ＭＰＢＧＰの中を、異なるルート識別子で、同一ルートターゲットになるサブネットを、二つのソースから他のプロバイダエッジルーターまで伝播させ、そのサブネットが、お客ＶＲＦ上のベストパス選択で、マルチパス設定により、マルチパスとして採用されるようになっている。このように、ロードシェアリングのためには、網内でそのお客ＶＲＦを収容する、全プロバイダエッジルーターの設計を、網全体として施工する必要がある。このロードシェアリングサービスを使っているお客は、数が多いわけではないが、一定数はいて、新規拠点追加や、拠点移転の際は、この網全体の設計をきちんと確認する必要があり、プロジェクト担当者がこれに慣れていなかったり、ＰＭ業務がメインで、あまりこの辺りの技術事情に詳しくないと、必要な設計を未実施のまま構築してしまい、新規拠点でロードシェアリングサービスを実現出来ないという、問題を起こすことがある。
せっかくロードシェアリングを提供しているのに、植松の担当しているこのお客は、この冗長拠点の両ルーターから、広告するサブネットを分けたい、とのことだった。ロードシェアリングは同じサブネットを２つの回線から広告し、網からの下りトラフィックを分散できることが利点だが、どうやって２つのパスに、実際のトラフィックを分散させるかは、指定できるわけではなく、送信元・宛先の組み合わせで、勝手にどちらのパスを使用するかは決まってしまう。このため、例えば、もし一つ目のパスを使うことになった、サーバー・レプリケーションのトラフィックでその回線の帯域を逼迫させてしまうと、もう片方の回線が空いていても、トラフィック量を見てパス選択を行えるわけではないので、送信元・宛先の組み合わせによっては、わざわざ輻輳している回線のパスを選んでしまうものが出てくる。
都が担当している案件でも、一年に一度くらい、ロードシェアリングが効いていない、とお客から保守にクレームが上がってくるので、やはり一年に一度、このサービスと挙動の仕組みを説明しなくてはならない。解消方法は、ロードシェアリングを止めて、きちんと帯域の使用量の多いサブネットと、そうでないサブネットをお客自身で精査してもらい、広告するルートの分割、あるいは受信するルートに重み付けを、設計変更としてオーダーしてもらうしか、基本的にはない。回線の遅延やパケットロスなどをモニターし、それによってトラフィックのパスを自動で切り替える、というのは、ＳＤ-ＷＡＮでは可能だが、都たちが担当しているグローバルＭＰＬＳのメニューとしては未だ組み込まれていないし、多くの営業にもお客にも、ＳＤ-ＷＡＮの浸透が進んでもいない。
植松が都に相談したい拠点は、２台のルーターが、それぞれ同じルートを、網内へ広告している。大きなサブネットを４本、ただ広告しているだけだが、網からＢＧＰで受信したルートについては、サブネット毎に定義し、あるサブネットは、１号機のルーターからＬＡＮ内のルーティングプロトコルへ再配送する時に、２号機よりもメトリックが軽くなるように操作し、別のサブネットはその逆で、と言ったようにサブネット毎に、ＬＡＮからの上りトラフィックが分散されるような設計になっている。
「お客さんからですね、ＢＧＰの広告経路を変更したい、と言われてるんですが、今の広告ルートよりも細かくしたいそうなんですよ。で、どうしたら良いかちょっとよくわからなくてですね、間宮さんに相談したいなあと思いまして。」
「え…？それは言われた通り変えれば良いんじゃないの…？お客さんが変えたい、って言っているルートって、ちゃんとＬＡＮからもらってる？」
植松の言葉をそのまま取れば、都にはそう答えるしかない。パラメターシートをもらって、ＢＧＰの広告経路を変更してやれば良い。むしろ簡易設定変更で済むものだ。わざわざＰＭが入らなくたって良い。このお客案件は、東京でＳＥを置く案件という扱いだったはずなので、そのためＰＭにこういった設計変更、設定変更の事前相談が来てしまうということだろう。
しかし、そんな簡単な事情で植松がわざわざ聞いてくるのも変だと思ったので、都は事情を掘り下げてみようと思った。
「あー…。もらえていないですね。」
「もらえてないルートを広告してくれ、って言われてるってこと？」
都が確認すると、そうだと言う。
「えー。じゃあ、そのルート配信するようにしてください、そのまま広告してます、で良くない？」
都は語尾を上げ気味に言った。都は若干責めるような調子になっているが、怒っているわけではなく、植松との間では、ふざけてなんとなくそう言う立ち位置でいることが多く、その延長だ。
「そうなんですけどねえ。」
植松はそう言うと、メーラーからメールを探して、ある一通のメールを開いた。それはこのお客担当者から植松へ来ているメールだった。このお客は、大手商事会社のネットワークを見ている、ＩＴベンダーだ。エンドユーザーの商事会社は、都たちのキャリアからは全く見えず、ＭＰＬＳサービスの利用者登録も、このＩＴベンダーの名前になっている。
そのメールには、現在はこの４本に集約してもらっているが、と、現在広告中のサブネットを４本、ネットワークアドレスと、プレフィックス長で列記した後、１号機はこの１０本、２号機はこの８本、で集約し直し、メイン・バックアップで広告するようにしたいが可能か、とあった。現在広告しているルートのプレフィックス長が１６ビットと大きなサブネットであるのに対し、新しいものは２０ビットから２５ビットと細かい。１８本中８本が２５ビットだ。
「え？すら２５？」
植松の隣で丸椅子に座って、植松の通常端末のディスプレイを覗き込みながら、都は思わず口に出した。プレフィックス長は、スラッシュの後に数字、という表記になるので、すらいくつ、という言い方をする。もし、２５ビットで集約してくれ、と言うのであれば、２６ビット以上の細かいサブネットのルートが存在しないといけない。集約する、と言った場合、幾つもの細かいルートを包含できるような、大きいサブネットへまとめる、ということになる。稀に、こういう狭いサブネットへの集約がないことはないが、今まで１６ビット４本、と大きく綺麗にまとめてあったものを、随分細かく変えてくるな、と都は思った。文面に「集約し直す」とあったのが気になった。
「これ、もっと細かいルート流れている、ってこと？」
都は植松に聞いた。
「あ、いえ、そこまで確認してないです。」
植松はそう言うので、都は、じゃあ、確認してみようよ、と言い、植松と隣の席の人とで共用で使っている専用端末のスクリーンロックを解いた。隣の席は出社はしているようだが、打ち合せか何かで席を外しているようだった。都は、植松に、このお客のＶＲＦ番号や、対象の客宅ルーターの管理番号などを聞いて、コンフィグ情報集積データベースから、当該ルーターのログイン情報を引っ張り出し、ログインサーバーから、１号機の方のルーターへログインしてみた。
まずは、運用中のコンフィグをざっと見てみた。集約しているルートは、ＢＧＰの集約設定ではなく、意図的に作成したＮｕｌｌ０ルートを拾い上げる設定になっていた。そしてＮｕｌｌ０ルートにトラッキング設定は入っていないから、ＬＡＮが断になった時に、ブラックホールと化してしまう。こんな危険な設定をやっているお客案件やルーターは、先日の岸谷と行った現場作業員の案件もそうだったが、見かけることは多い。しかし、このルーターにはＬＡＮが２本ある。ＬＡＮが冗長されているため、そうはＬＡＮが両系断になることはないから、これで大丈夫という合意が、客となされているのかもしれない。
ＬＡＮ側のルーティングプロトコルは、このルーター筐体メーカー独自のルーティングプロトコルだった。都は、ルーティングテーブルを表示するコマンドに、このルーティングプロトコルのものだけに絞るオプションを足してから、リターンキーを叩いた。ルートのプレフィックス長は、確かに２９ビットのものがいくつかあるが、それは機器間接続用のサブネットと想定して良さそうだ。それを除けば、２４ビットか、それよりもやや大きめのプレフィックス長のサブネットばかりだった。
「ないよ。」
都は植松に文句を言うように言っているのが自分で可笑しくなって、笑って言った。
「あー…。そうですかー…。」
植松もそれに笑ってしまいながらも、今一つ都の言っていることが理解できていないような、中途半端な様子だ。都は念の為、２９ビットのルートだけ表示させるようにして、植松が開いているメールにお客が列記してきた、２５ビットのサブネットと比べてみたが、第１、第２オクテットは一致するものの、第３オクテットが一致するものがないので、この２９ビットのサブネットを使って、お客指定の２５ビットマスクのルートには集約できない。都は念のためこの２５ビットルートを、プレフィックス長をつけず、客宅ルーターのルーティングテーブルに存在するかどうか、コマンドを使って調べてみる。すると、この２５ビットマスクのルートが含まれる、２４ビットマスクのルートが、その２５ビットのネットワークへのルートとして存在している。都は、通常端末、専用端末のディスプレイを交互に指差しながら、植松にこれらの事情を説明した。２５ビットについては、要するにその２４ビット前半のホストと後半のホストへの下りトラフィックを分散させたい、と言う意図なのだろう。
「実はお客さんから電話ももらっていてですね、今の１６ビットマスクの集約ルートみたいに、メールに書いたルートを、うちの客宅ルーターで作ってくれないか、って言われてまして。」
「あー…。えー。Ｎｕｌｌ０ルート作って広告してくれ、ってことー？」
都は、お客の意図はわかったが、それは２系統あるＬＡＮが両系断になった時にブラックホール化するという、そもそも今の集約設定も孕んでいる問題があるから、お客には、そのプレフィックス長のルートをＬＡＮ機器から、都たちの客宅ルーターへ広告してもらい、都たちの客宅ルーターがそれを単純にピックアップし、ＢＧＰで網へ広告する方が、障害発生時に想定外のトラブルの発生を抑えることが出来ると、誘導してしまった方が良い、と言った。
それに、２５ビットルートについては、Ｎｕｌｌ０ルートを作ってしまうと、それがロンゲストマッチルートになってしまって、客宅ルーターでブラックホールになってしまうから出来ない。もし、客宅ルーターでこの２５ビットルートを作るのであれば、２つあるＬＡＮに向けて、スタティックルートを２本づつ作らないといけなくなる。そうなると、そもそもＬＡＮでダイナミックルーティング使っている意味がなくなってしまう。なので、やはりお客機器から、必要なルートを広告してもらうべきだ。都はこの点を強調した。
どうしてもＮｕｌｌ０ルートやスタティックルートで、となったら、両系のＬＡＮの、対向機器のＩＰへの到達性をモニタリングする設定をそれぞれ作って、それぞれのモニタリングに対応したトラッキングを個々に作り、さらにそのトラッキング両方が落ちたらダウン、両方が上がっている時はアップ、と判断する親トラッキングを作って、それをＮｕｌｌ０ルートに引っ掛けるようにした方が良い、２５ビットルートのネクストホップ付きスタティックルートを本当に作るとなると、これについては個々のネクストホップをモニタリングするトラッキングをそれぞれに引っ掛けないといけない、ということも都は植松に追加で説明した。
「だから、まずはエグザクト・マッチのルートをお客さん機器からもらうようにした方が良いよ。そうしないとダメですくらいの勢いで。」
都は最後にそうまとめた。
「了解しましたー。ありがとうございまーす。」
植松はいつも都に何か相談に乗ってもらった時にそうしているように、東南アジアの人が丁寧な挨拶をする感じで、手を合わせて、軽く頭を下げながら礼を言った。しかし彼が卒業しているのはヨーロッパの大学だ。
「あ、あとこの回線って、プロバイダエッジルーターは、フィルタリング？それともノー・フィルタリング？もしフィルタリングだったら、広告ルート変更する時はプロバイダエッジルーターにも穴あけ必要だよ。」
都がそう言うと、植松は固まった。
「調べてないね。」
都は、またちょっと責めるような言い方をした。
「すみませーん。」
植松は膝に手をついて大げさに頭を下げた。都は笑ってしまった。