07-15
07-15
「あー。わかったー。これだ。再帰ルーティングになっちゃってるね。」
都にはもう原因も回避策もわかったので、ＬＡＮ向けのスタティックルートをネクストホップのみの指定のものから、インターフェイスに紐付いたネクストホップ指定のものに修正すれば直ると、それだけ谷山に言えば良いのだが、一応原因も説明しておこうと思った。
「これさ、ＬＡＮ向けのスタティックルート、ネクストホップがどのインターフェイスの先にあるかの指定を書いてないじゃない。」
都はそう言いながら、メモリ内に保存されているコンフィグの、スタティックルートの部分だけに絞って表示するコマンドを叩いた。
「ね。ネクストホップの指定だけしかないでしょ？」
都は確認を依頼する意味で谷山を見上げた。
「あー…。はい、そうですね。普通であれば、ＬＡＮインターフェイスを指定してから、その次にネクストホップのＩＰ書きますね。」
谷山はそれがどういう役割なのかは良くわかっていないようだが、通常推奨されているスタティックルートの書き方と異なっていることは理解した。
「インターフェイスが書いてあるスタティックルートだと、指定したネクストホップは、そのインターフェイスの先にあります、って意味になるのね。だからインターフェイスを閉めたり、ケーブルが抜けて落ちちゃったりすれば、インターフェイスの先にあるネクストホップにはたどり着けないことになるから、そのスタティックルートも落ちてくれるのね。」
「はい。」
都が説明を区切ったところで、谷山は返事をした。理解はしてくれているようだ。
「で、もし、スタティックルートを、インターフェイス指定しないで、ネクストホップのみでコンフィグすると、ネクストホップへのルートがあるかないかで、スタティックルートが上がったり、落ちたりするの。」
「…はい。」
今度は微妙に理解出来なかったようなのは、谷山の返事の調子でわかった。
「具体的に見ていくとー。」
都は今のコンフィグとルーティングテーブルを実際に見せた方が早そうだと思って、メインの客宅ルーターのターミナルウィンドウを指差して、谷山に見るよう促した。
「これさあ、今このスタティックルートのネクストホップって、ＬＡＮインターフェイスに直接繋がってるセグメントのどっかでしょ？ネクストホップなんだし。」
「あー…。はい、そうですね…。」
谷山はわかったようなわからないような感じなので、都は、コンフィグのＬＡＮインターフェイス部分だけに絞って出力するコマンドを叩いてから、コンフィグのスタティックルートの部分だけに絞って出力するコマンドも叩いた。
「ほら、ＬＡＮインターフェイスにアサインしてあるＩＰアドレスって、サブネットマスク２４ビットだから、このスタティックルートのネクストホップって同じセグメントでしょ？」
都はそれぞれを指差して言った。
「あー、はい。そうですね。」
谷山はやっと意を得たようだ。
「ネクストホップのあるスタティックルートって、まず、そのネクストホップへのルートが存在するかどうか確認するのね。もし、ネクストホップへのルートがあれば、そのスタティックルートは使える、という判断で上がる。逆にネクストホップへのルートがなければ、そのスタティックルートは使えないので、落ちる。そのルートへたどり着くためには、そのネクストホップへまず行かないといけないわけだから、ネクストホップへのルートがなければ、ルーティング出来ないからね。」
「んー…。なるほど。」
都の説明はわかったようだが、それが今のトラブルとどう結びつくのか、谷山には見えてこないようだ。
「このスタティックルートのネクストホップって、ＬＡＮインターフェイスのコネクテッドセグメントに含まれるホストアドレスだから、ＬＡＮインターフェイスをシャットすれば、ネクストホップへのルートはなくなる、と思うじゃない？」
「ええ、そうですね。」
谷山は把握できた時は返事に迷いがないので、わかりやすかった。
「でも、ルーターさんはマジメだから、本当にこのネクストホップへのルートないのかどうか、って探しちゃうのね。何故ならスタティックルートに、このネクストホップがどのインターフェイスの先にあるっていう指定がないから。で、実際に、ルーティングテーブルで、このネクストホップへのルートがあるかどうか探してみると…。」
都はそう言いながら、矢印キーでさっき打った、ネクストホップアドレスへのルートがルーティングテーブル上に存在するかを探すコマンドを呼び出し、リターンキーを叩く。
「…ほら、ＢＧＰでもらっている、もっと大きいサブネット…。これって、このネクストホップのＩＰ、っていうか、このルーターのＬＡＮインターフェイスのコネクテッドセグメントを包含できるサブネットでしょ？スタティックルートのネクストホップへの到達性にはこのＢＧＰのルートが使える、ってことになって、ネクストホップへのルートはあるという判断にもなって、だからスタティックルートも落ちないで上がったまま、になっちゃってるのね。こういうの、再帰ルーティング、って言うんだけど。」
「あー…。なるほど、なるほど。んー…。ただ、メイン回線ってだいぶ前に開通していて、その時には問題にならなかったんですよね。」
都の説明はわかったようだが、少しおかしなことを谷山は言った。
「そりゃそうでしょ。だってこの拠点ってメイン回線だけだったんでしょ？このスタティックルートって、この拠点のＬＡＮネットワークじゃない？そうであれば、この客宅ルーターだけが持ってれば良かったんだから。でも今はバックアップの客宅ルーターも同じスタティックルートを持っていて、メインの客宅ルーターのＬＡＮが落ちた時は、メインの客宅ルーターからこのスタティックルートは落ちてもらわないといけないわけじゃない。」
「ま、そうですね、はい。」
要するに谷山は、谷山のミスではないのでは、と言いたいようだ。通常の案件であれば本来、海外のオフショアセンターが客宅ルーターのコンフィグ権限を持ち、客宅ルーターの設計責任も彼らにあるはずなのだが、この手の見落としについては、東京で発見し、東京から指摘して変更の依頼をしなければいけないことが多く、これは東京のＰＭにはストレスの一つになっている。
冗長試験をやるには、ＷＡＮインターフェイスやＬＡＮインターフェイスの閉塞や解放を、東京の指示で海外オフショアセンターが実施するわけだが、その時にルーティングトラブルが発生したのであれば、彼ら自身で自発的にトラブルシューティングを開始し、対応策を取って欲しいものだ。しかしおそらく今も、東京からの指示を待っているだけだろう。ＬＡＮインターフェイスを閉塞したにも関わらず、ＢＧＰ広告が止まっていないことすら、確認していないかもしれない。基本的に、彼らはトラブルの申告がない限り、対応はしないスタンスだ。上手く行っているのであれば、ルーティングの確認やコンフィグのチェックなどしても、それはＯＫだという結果にしかならないことが多い。そうであれば、問題が起きているという申告がない状況での確認作業は無駄な稼働だ。それは一理あるかもしれない。その辺りはもう仕事に対する根本的な態度の違いというか、労働文化の違いなのだろう。
「だから、メイン・バックアップ構成になったからには、このメインのルーターに入っているＬＡＮ向けのスタティックルートは、ネクストホップ指定だけのものじゃダメで、インンターフェイスを紐づけた書き方のものに変更しないといけない。なんでかって言うと、このお客さんのネットワークには、この拠点の客宅ルーターの、ＬＡＮインターフェイスのコネクテッドセグメントを包含するルートが存在していて、そのルートで再帰ルーティングが起きちゃうから。もちろん、オフショアセンター自分たちでちゃんと気がついてやってよ、っていうのはあるけど、気が付けてくれてないんで、こっちから指摘して変更してもらうしかないねー…。」
厳しい言い方をしてしまえば、こういうメイン回線のみの運用だったものに、バックアップ回線を足すようなプロジェクトであれば、ＰＭが事前に問題になりそうな設計については検討、確認しておかないといけない。しかし、こういうものは見落としがちだ。実際の工事の時に発覚するような、現状は上手く行っているため問題がないように見える設計やコンフィグについて、潜在する問題を事前に発見する、というのは誰にとっても難しい。都はそう思って、誰が悪い、ということへの言及は避けた。東京では、スタティックルートを設定する際、必ずインターフェイスとネクストホップはセットで書くことが推奨されている。そこには、こういう一回線だけで開通した後、バックアップ回線を足したような場合に見落としがちな問題を先回りして避ける、という意味もある。海外オフショアセンターにはそういう推奨はないようだ。
ＬＡＮ側がスタティックルーティングで冗長構成を持ち、ＭＰＬＳ網などのＷＡＮ側に、客宅ルーターのＬＡＮインターフェイスの接続セグメントを包含するようなルートがＢＧＰで流通している。そういう条件でなければ起こらない問題なのだから、その対策を普遍的に取る必要はない、という考えなのだろう。客宅ルーターで、どのポートがＷＡＮインターフェイスや、ＬＡＮインターフェイスにアサインされるかは、客宅ルータの筐体機種や、開通時の状況に依存するので事前の指定は難しい。事前に東京のＰＭが出さなくてはいけないパラメーターは、スタティックルートのネットワークアドレス、サブネットマスク 、ネクストホップだけだ。そのパラメータからだけでスタティックルートを起こすことにすれば、パラメータシートからマクロなどのツールでスクリプトを作ることも容易いだろう。指定のインターフェイスを間違える、という誤謬も避けることが出来る。コンフィグの間違いは、東京のＰＭがパラメーターを間違った時だけ起るというわけだ。よく考えられた仕組みだと、都はため息まじりに感心してしまう。