音信不通 － 通信ができない
ネットワークの開始、運用している場合、どうもうまく通信ができていないことがあります。
筆者も、「なぜ、送ったメッセージが相手に届かないのか」ということで、切り分けのテストをしたり、各ネットワーク機器のセットアップ状況を調査したり、考えられることをホワイトボードに書き出したりなど、いつも悩みます。もう一つの悩みは、全く同じ理由で障害が起きたということが無く、いろいろな障害ケースを積み重ねても、なかなか「これだ！」と即座にわかるケースが多くないということです。
もう半世紀前にやっていたトラブルシューティングの方法を時折思い出します。
中学に入学して、すぐに、友人が、アンプを手作りしたり、ラジオを修理したりして、結構な小遣い稼ぎをしていました。「こいつにできるのなら、俺もできるだろう」と、自分の真空管式アンプを作ってみようと始めました。手元にある情報は回路図だけ、電気の知識はオームの法則ぐらい。稼業が鉄工場でしたので、ケースやシャーシの加工は問題なく、半田鏝と手作りテスターで挑戦が始まりました。そこで分かったことですが、回路図は紙上に部品の記号と配線を書いたものですが、良い部品配置は、回路図そのものになるということでした。そして、そこを信号がどのように流れているのか手に取るように分かりました。
全体構成が美しく書かれると、それだけでも何かトラブルが起きた時に、対処をする上で大きな助けになります。ですから、ネットワーク構成図は1枚で全体が見渡せて、データがどのように流れてゆくか分かりやすいものを入手することで、半分解決したようなものです。
物理層では、リンクアップされているが、いざ通信をしようとするとできないことがあります。ほとんどの場合、データの流れるルートが何らかの理由で、一気通貫で繋がっていないということが殆どです。なるべく広い範囲で、データの流れを把握しましょう。
通信できないケースがいろいろありますが、我々がなぜ悩んだか、どうしようもない様な失敗例も紹介したいと思います。
- MTUという値 Pingは通すが通常データが通らない。
初期のころは、Hubという、あるポートがパケットを受信するとその他のすべてのポートに送り出すという半二重通信でした。 IEEE802.3では、CSMA/CDそのままだったのですが、Switch(交換機)という概念が広まってきました。あるポートから入ったパケットは、一旦バッファに送られ宛先アドレスにより指定のポートに送り出すという仕組みになっています。よって、AポートからBポートへ、CポートからDポートへ、パケットのバッファリングと転送が間に合えば、パケットの衝突を起こすことなく通信ができるというものです。
当初のEthernetですと、パケットは、宛先アドレス(6バイト)/送信元アドレス(6バイト)/タイプ(2バイト)/ペイロード(48-1500バイト)/フレームチェックシーケンスFCS(4バイト)合計1518バイトでした。もともと同軸ケーブルが500ｍと規定しており、パケットのサイズが1500バイトより大きくなると、同軸ケーブルを通る信号の劣化によるビット化けをしてしまい、転送効率が落ちてしまうのではないかとの懸念がありました。
その後、ケーブルやアナログエンコーダー/デコーダの品質向上により、より転送効率を上げるジャンボパケットなるものが出てきています。最小ペイロードサイズは48バイトで、最大サイズはマシンにより変わりますが、おおよそ9000バイトまで使用可能になりました。ところが、ほとんどのマシンが1500バイトで使用することを前提としていますので、この値を超えるとパケットは破棄されることとなり、通信ができなくなります。
ここで、Maximum Transfer Unit(MTU)という、そのマシンが使用可能なサイズを宣言し、最小ペイロードサイズが48バイト以上でパケットサイズがMTU以下のパケットだけを転送し、それ以外は捨てられます。
下図がおそらく典型的なEnd to End通信の例だと思われます。Node 1から送られたパケットは、最終的に、Node 2へ行き、そしてNode １へ返ってきます。
ノードから送られたパケットが、ネットワーク機器(スイッチ、ルーター等)を通過する間に、MTU サイズがパケットのペイロードサイズより小さい値がセットされているとそこでパケットが捨てられます。 また、VLAN機能や、リンクアグリゲーション機能を使っている場合、それらのインターフェースごとにMTUを設定しなければなりません。
例えば、Switch 1を例にとって見ましょう。Router1のポートはSwitch 1のあるスイッチポートに接続されます。スイッチポート自身のMTUに加え、もしそのスイッチポートがあるVLANに属していたり、リンクアグリゲーションに属している場合は、同様にMTUをセットしなくてはなりません。つまり、本当に一気通貫でMTUを満たすように考慮した上で、ネットワークの設計をしなければなりません。
ここでの失敗例は、スイッチポートのMTUはきちんとジャンボパケットが通るようにMTUを設定していたのですが、VLANや、リンクアグリゲーションのMTUをディフォルトの1500バイトから9000バイトのジャンボパケットに設定されていなかったために、MTU 以上のサイズを持つパケットが捨てられてしまっていたということでした。そういえば、Pingが通っているのにもかかわらず、実際の通信ができないというのは、PingはパケットサイズがMTU以下なので通してしまうということでした。
- ファイアーウォール/セキュリティー 大切だがたまには迷惑
検証作業をしていると、通信できない理由の一つとして、セキュリティー機能があります。私見ではありますが、特にWindowsでは、リリースが新しくなるに従って、セキュリティー機能を使うにあたって複雑になり、一発で稼働させることは難しく、またユーザーからいろいろな要求仕様の変更などがあると一層困難になります。
我々は検証作業をする場合は、必ずと言っていいほど、最初なセキュリティー機能、特にファイアーウォールは、無効にして行います。これは、デバック項目を限定し、まずは動く状態を作ってから、動けなくなるようにセットするのが早道になります。
失敗談としては、Windows 使用時にFirewallをEnableにされたまま何のセットアップもしなかったということです。
Windowsのあるバージョンから、ICPMパケットを正しく受信しても、送信元に返事をしない設定になっており、「Pingが返ってこない」と頭を抱える状態に陥っていたということでした。
- VLAN設定について
初めのVLAN機能は、1台のスイッチのポートを複数の論理ユニットに分け、ユニットごとに独立したスイッチとして使用することです。従って、そのユニット間の通信はしないというものでした。下図のようにスイッチVLAN 10とVLAN 20に分けます。分かれたVLANに属するポート間は通信できません。
例えば、VLAN 10は営業部、VLAN20は経理部としますと、同じスイッチを複数の組織で分けて使えます。
次に、スイッチ間で同じVLAN IDを共用しようということで、1つのスイッチポートを利用して、スイッチ間で接続することになりました。
ここでは、VLANごとに1本のケーブルを使う必要があります。VLANを増やすとその分ケーブルが必要になるということになります。
そこで、VLAN IDを加えることで、このパケットはどのVLANに属しているかと示すことで、複数のVLANをサポートする特別なスイッチポートの設定をすることによって、1本のケーブルでもスイッチ間通信が行えるようになります。これをトランクポートと呼びます。トランクポートには、どのVLAN IDのパケットかを区別するVLAN Tagを付加することになります。
トランクポートは通常Default 1にセットされ、Switch 1のVLAN 10またはVLAN 20から入ってきたパケットは、トランクポートを通してSwitch 2のVLAN 10またはVLAN20のノードと通信が可能となります。
ポートモードにより
Switchport VLANタグなしのパケットを送受 VLANタグのついたパケットは受信しない
Trunk port VLANタグありのパケットを送受 VLANタグのついていないパケットは受信しない
上記トランクポートは、特定のVLANに属することが可能です。例えば、トランクポートをVLAN ID 20としてセットすると、VLAN 20のVLANタグを持ったパケットしかトランクポートに流れません。 もし、VLAN 10に属するポート間でも通信できるようにするには、設定時に”allowed vlan add 10”と付けます。
Mellanoxの Ethernetスイッチはもう一つのポートモードを持っています。
Hybrid VLANタグ有り、無しの両方のパケットを受信します。
もしVLANタグ有りのパケットを受信し、Allowed vlan listにあるVLAN IDのパケットを受信した場合、VLANタグをつけて送り出します。
また、属するVLAN IDを持ったパケットを受信した場合、VLANタグを付けずに送り出します。
もしVLANタグなしのパケットを受信した場合、VLANタグを付けずに送り出します。
よってタグ有か無しかで、使用するモードをうまく使い分けることが可能です。
これも、思い込みで通信ができなかった失敗談です。今は、NIC(Network Interface Card）にも、VLANタグをつけたパケットを送る様な機能があります。
NICでVLANタグを付けて送っているのに、VLANタグ無しのつもりで、トランクポートにつなぐべきところを、スイッチポートに接続しパケットをバンバン捨てていたり、トランクポートにVLANを設定していながら、allowed vlan listに登録がなく、パケットをバンバン落とすようなことをやって、「通信できない」と悩んだ自分が恥ずかしいのです。
- 思い違いと思い込み どうもPingがうまく通らない。
これが結構奥深いものがありまして、ちゃんと行って来いができることで相手と通信ができるということになりますが、どこか正しいパラメータでセットできていないケースがあります。私もよく遭遇するのが、正しくセットアップしているつもりで “うーん。 返ってこない“ という場面です。 ここでやりがちなのが、終端から終端へと考えがちですが、途中どこをどのようにパケットが通過するかを見た上で、最終目的地に行くということを見つめなおすプロセスが大切です。
我々がやってしまった失敗談を一つ挙げてみましょう。通信できるはずの構成で通信できなかったというネットワークがありました。これはLinuxシステムとWindowsシステムの混成ネットワークでMellanoxのスイッチを通してネットワークの上位層のルーターに接続され、そのルーターをディフォルトゲートウェイとして通信するというものでした。 ネットワーク設計上通信できるはずが、Pingを出してみると、返ってこないということで、われわれはネットワーク設定を正しくセットしており、中間にあるMellanoxスイッチの問題ではないかと考えてしまいました。
スイッチOSのバージョンがちょっと古いバージョンだったため、早速アップグレードしましたが、それでも通信はできません。ここで、出てきた疑問が、「正しいセットアップがされているのか。」
ここで、全体的にどのようにデータが流れるのか、その相関図を作ることになります。そして段階を追ってどこまで届いているかというのを確認します
この問題点は、LinuxシステムでDefault GatewayのIPアドレスの設定に誤りがあったという「自分は正しい」という思い込みが、問題点を隠してしまうことで、トラブルシューティング時は頭の片隅に置くことが大事ですね。