ネットワーク接続が不安定な場合の対処方法

「ネットワーク接続が不安定になる」というトラブルは…残念ながら結構な頻度で発生する事象だと思います。私自身何度も様々なパターンで体験しています。 そして今日もまた…。 「ネットワーク接続が不安定」という問題は様々な要素が複合的にくみあわさって「完全につながらないわけじゃないけど、なんだか不安定」というような事が多いです。下記にかかれているものは私の経験上「よくあるもの」ではあるのですが必ずしも該当するわけでも設定変更することが必ずしも良いものでも全くありません。ですが、とりあえずパフォーマンスを犠牲にしてでも「安定」する方向の設定であることは間違いありません。一度下記を参考に「安定」方向に設定を変更してみて問題を切り分けてみるのは良いかと思います。 ドライバを最新版にする まずはNICのドライバを最新版にすることをお勧めします。この記事を見ている方はコンシューマー向けのPCを使われている方が多いと思いますので、各メーカーのドライバ更新用の専用ユーティリティーなどを利用してもらえればと思います。 ワイヤレスアダプタの省電力設定を無効化する ワイヤレスアダプタに関しては省電力の設定が存在するものがあります。とりあえず「最大パフォーマンス」で可動させるようにしましょう。 ※PC(NIC)によっては存在しない設定項目です。 NICの各種オフロード機能を無効化する NICの各種のオフロード機能は本来ハードウェアにネットワーク関連の処理を行ってもらうことによりネットワークパフォーマンスを向上させるための仕組みなのですが、場合よってうまく動作せずむしろ接続不良の原因となることがあります。一度各種オフロード機能を無効にして切り分けてみるのは多くの場合有効です。 オフロード系の機能を無効化します。どの項目が無効化していいものかわからないということもあると思いますが、項目名と現在の設定値を控えておいた上で無効化できるものは何から何まで全部無効化してまわってまず挙動の変化を確認するようなやり方を個人的にお勧めします。 MTUの引き下げ MTUはMaximum Transfer Unitの略でようはNICが送信するパケットの最大サイズに関係するものです。途中の経路で小さなパケットしか通せない部分があるにもかかわらず大きなパケットを送信することで経路の途中でパケットが破棄されてしまうような挙動が比較的多くあります。この場合通信できないわけではないのですが異様に遅い…というような挙動になります。最適なサイズを検出するような手法もありますが、まずは一度小さく設定してみて挙動を確認することをお勧めします。 これはコマンドプロンプトで設定するのが簡単です。 コマンドプロンプトを管理者として実行します。 まずはインターフェースの一覧を表示して名前や現在のMTUを確認します。 netsh interface ipv4 show subinterface 今回は「Wi-Fi」というInterfaceのMTUを1430に変更してみます。 netsh interface ipv4 set subinterface “Wi-Fi” mtu=1430 store=persistent 再度インターフェースの一覧を表示するとMTUが変更できたことが確認できます。 確認 設定を変更したら一度再起動した上で確認先のホストに継続的にping(icmp echo)を送信し応答を確認するのがお手軽です。 下記の例ではwww.google.comを宛先に設定させてもらっています。安定的に通信できている様子が見えますね。 これでもだめなら私としてはもうパケットをキャプチャしてしまってパケットレベルで処理を追うことをしてしまいます。流石にそれは必要となる前提知識の量が違いすぎるのでまた別エントリにしたいと思います。要望あれば…書くかも…しれません。

December 17, 2018 · 1 min · 胡田昌彦

マルチホーム構成時の注意

今回はマルチホーム構成時の注意点についてです。マルチホームというのは要するにNICが2つ以上あって、複数のネットワークに足を出している状態のことです。結構な頻度でマルチホーム構成を選択し、やってはいけない構成でトラブルに遭遇するケースを見ています。しっかり抑えておきましょう。 デフォルトゲートウェイは1つだけ まず、一番初めに理解してほしいのは「デフォルトゲートウェイを2つ以上設定してはいけない」ということです。よく理解していない人は多くのケースで2つNICがあったら2つゲートウェイを設定してしまうようです。 でも、ちょっとよく考えてみてください。デフォルトゲートウェイというのは、自分が所属していないネットワークに向かって通信するときにパケットを投げる相手ですよね?それが2つ設定されていたら、どっちに投げたらいいんでしょう?困ってしまいますよね? どっちに投げてもきちんと相手まで届く構成であれば問題がおきないこともあるでしょうけれども、やはりこれはよくない構成です。場合によっては通信できないことになるでしょう。 - デフォルトゲートウェイは1つだけ設定する(1つのNICだけで入力し、ほかのNICでは空白にしておく) - 必要な経路に関してはスタティックルートを記述する このようにしておかなくてはいけません。 スタティックルートを記述 スタティックルートの記述・・・といってピンとこない方も多いかもしれませんね。基本的にNICが1つであれば必要ない設定ですから。でも2つ以上になったら、「このネットワークアドレスに向けての通信は、こっちの足からあのルーターに投げる」ということをしっかりと記述してあげる必要があります。 Windowsではこの設定は「route」コマンドで実施できます。経路の追加はroute addコマンドです。コマンドの説明は例のごとく@ITにお願いしちゃいます。 - [route - ルーティングテーブルの表示/設定を行う](http://www.atmarkit.co.jp/fnetwork/netcom/route/route.html) 注意点としては、再起動しても消えないように設定するには-pオプションをつける必要があることです。route printコマンドで経路情報を表示した際に、きちんと追加した経路が「Persistent Routes」として表示されることを確認しておきましょう。そうでないと、うまくいったと思っていたら1月くらいたって再起動したらまたおかしくなったなんていうことになってしまいます。 DNSを2つ以上設定しない またデフォルトゲートウェイの次に気をつけてたいのはDNSの設定です。特にInternet側とIntranet側なんていうようにNICが分かれていた場合、Internet側のNICにはインターネットの名前解決ができるDNSを、Intranet側のNICには社内のDNSを設定したくなる人も多いかと思います。 でも、よく考えてみてほしいのですが、両方に問い合わせるわけにはいきませんよね。もしも両方のDNSに同じドメインが存在したりしていたうえに異なるレコードが登録されているような場合には(これはありえないことではありません)、通信しようとするたびに名前解決の結果が異なるようなことにもなってしまいます。これはやはりだめです。 DNSに関してはどれが正解ということはないです。そのホストの必要に応じて、正しいDNSを参照させる必要があります。「両方のDNSを参照したい」と思ってしまうのなら、それはDNSの設計、構成が間違っている可能性があります。場合によってはhostsファイルを併用してもいいでしょう。 DNSへの登録に気をつける マルチホームの場合にはDNSへの登録にも気をつけてください。特に何も考えないと、ホストについている2つ以上のIPアドレスをすべて登録して、ラウンドロビンになってしまいます。特にDCでこれをやってしまうとかなりクリティカルな障害にもつながってしまいますので、特に気をつけてください。 DCに関してはマルチホーム時のマスタブラウザの問題もあるのでそもそもマルチホームにしないほうが良いです。でも、それでもどうしてもDCをマルチホームにしたいのであれば、Aレコードの自動登録をやめさせる必要があります。DCはNetlogonサービスが定期的に自身のDCとして動作するためのレコードをDNSに定期的に登録に行くようになっているからです。このあたりの手順は以下のKBを参考にしてください。 - [Active Directory communication fails on multihomed domain controllers](http://support.microsoft.com/?scid=kb%3Ben-us%3B272294&x=7&y=17) その他まだまだありますが・・・ 今回紹介したこと意外にもマルチホーム構成の時の注意点は色々あります。特にDMZとLANに足をだしていて、DMZ側のIPでサービスを提供しているようなときに、入力と出力で使うNICが異なるようになってしまったりとか・・・。2つ経路があるときに意図的に片方のネットワークを使わせようと思ってもうまくいかなかったりとか・・・。バックアップ専用のネットワークを作ろうとしたりするときとか・・・。 このあたりはちょっと複雑になりすぎるので、また機会を改めて解説させてもらおうと思います。とりあえず今回紹介した注意事項が基本中の基本ですので、まずはここから気をつけていってみていただければと思います。 参考URL - [マルチホーム コンピュータのデフォルト ゲートウェイ設定](http://support.microsoft.com/kb/157025/ja) - [[NT]同一ネットワークに複数のアダプタを接続した場合の障害](http://support.microsoft.com/kb/175767/) - [マルチホーム化されたブラウザに関する問題](http://support.microsoft.com/kb/191611/ja)

October 30, 2009 · 1 min · 胡田昌彦

レイヤ2 -データリンク層- スイッチングハブの動作

レイヤ2においてはまずMACアドレスを意識することが重要だという話をしました。 - 参考:[レイヤ2 –データリンク層- 宛先はMACアドレス](https://windowsadmin.ebisuda.net/2009/02/12/%e3%83%ac%e3%82%a4%e3%83%a42-%e3%83%87%e3%83%bc%e3%82%bf%e3%83%aa%e3%83%b3%e3%82%af%e5%b1%a4-%e5%ae%9b%e5%85%88%e3%81%afmac%e3%82%a2%e3%83%89%e3%83%ac%e3%82%b9/) MACアドレスを理解したら、次に理解したいのはリピータハブとスイッチングハブの違いです。 リピータハブで接続されたネットワーク上の通信 まずは復習です。リピータハブで接続されているネットワークでは大まかに以下のような動きをします。 - コンピューターが通信を行う - NICがデータを受け取り、宛先MACアドレスをセットする(レイヤ2) - NICが電気信号としてデータを流す(レイヤ1) - リピータハブは電気信号をそのまま伝える(レイヤ1) - **リピータハブは受け取った電気信号を全ポートにそのまま流す(レイヤ1) ** - (別のコンピューターの)NICが電気信号を受け取る(レイヤ1) - **受け取るべきフレームであるかどうかをMACアドレスを元に判断する(レイヤ2) ** - 受け取るべきであれば上位層にデータを渡す。受け取るべきフレームでなければ破棄する。(レイヤ2) ここでのポイントは、5と7の動きです。リピータハブは全ポートに電気信号をそのまま流すので、リピータハブにつながっている全PCで受信してしまいます。PC-1からPC-2への通信をしているときに、その全てが他のコンピューターにまで全部届くのです。1GBのファイルをコピーするとしたら、まったく無関係なのに1GB分のデータが流れてくるのです。これは非常に無駄ですし、ネットワークがすぐに混雑してしまいます。 本来、PC-1宛ての通信であればPC-1だけに届き、PC-2宛ての通信であればPC-2だけに届いてくれさえすればいいのです。 スイッチングハブの動き で、これを実現してくれるのがスイッチングハブです。結局必要なコンピューター(=ポート)にだけ、電気信号を流してあげればいいわけです。コンピューター(NIC)が7で行っていることをスイッチングハブもしてあげればいいわけです。 はい。あとは考えればどうしたら良いのかは考えれば分かると思いますので、考えてみてください。 [問題]スイッチングハブはどのような動きをするでしょうか? 考えましたか?間違っていたとしても、きちんと自分の頭で考えてみることで血肉になっていきますのできちんと考えてくださいね。 スイッチングハブの動作 - MACアドレステーブル 「スイッチングハブがフレーム内の宛先MACアドレスを見て、そのMACアドレスがつながっているポートにのみ電気信号を流せばいい。」のですが、それでは「どのポートにどのMACアドレスがつながっている」ということはどのように把握できるでしょうか。 これを実現するために、スイッチングハブには「MACアドレステーブル」が備わっています(Arpテーブルとは別物ですので注意)。どのポートの先にどんなMACアドレスがあるかを記憶しておくわけです。 以下はスイッチングハブの気持ちになって一緒にMACアドレステーブルを更新してみましょう。 まずポート1からフレームが流れてきました。フレームにはもちろん送信元MACアドレスが書いてありますから(ここではMAC Aとしましょう)、ポート1の先にはMAC Aがある、とMACアドレステーブルに書き留めておきます。 ポート1 MAC A 流れてきたフレームにはもちろん宛先MACアドレスも書いてあります(ここではMAC Bとしましょう)。MAC B宛のフレームはどのポートに流せばいいでしょうか?MACアドレステーブルを見てみると、MAC Bがどのポートの先にいるかはわかりません(まだ学習していません)。ですから全てのポートに対してとりあえず流します。この「全てのポートに対してフレームを流す」という動作を「フラッディング」と言います。 MAC Bの持ち主は実際にはポート2の先にいたとしましょう。全ポートに対してフラッディングしましたので、もちろんポート2の先にいるコンピューター(NIC)もフレームを受け取ります。その上で宛先MACが自分宛ですから受け取って上位層に渡し処理をしてもらいます。ここでは、お返事をする必要があったことにしましょう。 (スイッチの気持ちになって。)今度はポート2からフレームが流れてきました。送信元MACアドレスはMAC Bです。MACアドレステーブルに書き留めておきます。 ポート1 MAC A ポート2 MAC B 流れてきたフレームの宛先MACアドレスはMAC Aになっています。MAC Aはポート1の先に繋がっていることを知っているので、ポート1のみにフレームを流します。 ・・・。 文字だけで書くとかなりわかりづらいですが、このようにフレームから「送信元MACアドレス」を読み取り、それをポートに対して対応付けておくことで、次回以降の通信の際には宛先MACアドレスを見て必要なポートにのみフレームを流すことができる。これがスイッチングハブの動作です。 ちなみに明示的にブロードキャストを要求された場合(宛先MACアドレスがFFFFFFの場合)にはきちんとフラッディングしてくれるので大丈夫です。 MACアドレステーブルはいつまで覚えているのか? でも、ちょっと待ってください。それは確かにあるときは1つのポートに繋がっているでしょうけど、そのうちポートを変更するかもしれません(座席移動などで)。そうなると、必要なフレームが必要な場所に流れてこないのではないでしょうか? この疑問は正しくて、MACアドレステーブルが更新されないとフレームは流れてきません。なので、きちんとMACアドレステーブルが更新される以下のような仕組みが備わっています。 - 一度覚えたMACアドレスは一定時間たつと消える - 学習済みのMACアドレスからのフレームが別のポートから入ってきたら、既存のものを消し、新しいポートに学習しなおす 基本的には何も考えなくてもポートを差し替えただけで繋がりますが、何かおかしいと思ったときにはMACアドレステーブルをチェックするということを発想できるようになりましょう。 ...

February 18, 2009 · 1 min · 胡田昌彦

レイヤ2 –データリンク層- 宛先はMACアドレス

今回はレイヤ2の話です。 レイヤ2と一口に言ってもPPPやHDLCやADCCP等多数のデータリンクプロトコルがありますが、まずはなんといってもイーサネットに関しての理解が必要です。 MACアドレス レイヤ2において色々と理解すべきことはありますが、まずは何と言っても「MACアドレス」を理解しなくてはいけません。大げさに言えば、私はMACアドレス、レイヤ2の概念をきちんと理解しているかどうかが素人とプロのまず大きな違いだと思っています。そのくらい重要です。 昨今ではTCP/IPが全盛なので、「コンピューターはIPアドレスを持っていて、IPアドレスを住所のように使って通信している」という理解をしている人が多いですし、確かにそれは間違いではありません。ですが、それはレイヤ3を考えた時の話です。レイヤ2で同じようなレベルで理解をするならば「NICはMACアドレスを持っていて、MACアドレスを住所のように使って通信している」ということになります。 「NIC」というのは「Network Interface Card」の略で「LANカード」などとも言われます。このNICに、MACアドレスというものが指定されているわけです。 MACアドレスを確認する 「IPアドレスは設定したことあるけど、MACアドレスなんて設定したことないよ?」という人も多いと思います。まずは自分が今使っているコンピューター(についているNIC)のMACアドレスを確認してみましょう。 コマンドプロンプトで「ipconfig /all」を実行してみてください。 「Physical Address. . . . . . . . . : XX-XX-XX-XX-XX-XX」という行があります。これがMACアドレスです。上の例だと「00-0F-B5-8E-0B-54」ですね。 このMACアドレスはメーカーが工場でNICを生産する際に埋め込みます。ですので基本的に私たちが設定するものではありません。(例外はありますがまずはこの理解でいいでしょう。) MACアドレスからベンダーを調べる このMACアドレスは重複しないようにメーカーごとに割り当てることができる範囲が決まっています。ですので、MACアドレスを見ればどのメーカーのNICなのかわかるようになっています。具体的にはMACアドレスの先頭24ビットがベンダーをあらわしています。具体的には以下のようなサイトで調べることができます。 IEEE Registration Authority - IEEE OUI and Company_id Assignments サイトに行って「Search the public OUI listing . . .」という項目に自分のNICのMACアドレスの先頭24ビットの値を入力して「Search!」して見ましょう。 上の例であれば「00-0F-B5」というのは「NETGEAR Inc」のNICであることがわかります。 フレームの構造 レイヤ2のレベルで考えたときには宛先、送信元にMACアドレスが入力され、Ethernetに電気信号として伝えられます。これの塊をレイヤ2では「フレーム」と呼びます。「フレーム」は以下のような構造をしています。 「プリアンブル」「タイプ」「FCS」などの理解はとりあえず後回しで大丈夫です。重要なのは「宛先MACアドレス」と「送信元MACアドレス」です。 原則としてEthernetでは全てのフレームが全てのコンピューターに届けられます。レイヤ1レベルではただの電気信号なので繋がっている全てのコンピューターまで届くわけです。NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す、という動きをします。(※例外あり、後述) どうやって通信相手のMACアドレスを知るのか では、何か通信をしたい時、送信元MACアドレスには自分が知っている自分自身のMACアドレスを入れればいいとして、宛先MACアドレスはどうしたらいいでしょうか?どうしたらわかるでしょうか? たとえばpingを考えてみましょう。「ping x.x.x.x」という形でコマンドを打つときには、宛先のipアドレスはコマンドを打つ人が入力してくれますが、このときにMACアドレスを入力するということはしません。 ですので、IPアドレスからMACアドレスを知る仕組みが必要になるわけです。NICの気持ちになって考えてみると「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という事をネットワークに流せばよさそうです。そしてMACアドレスを教えてもらう。このやり取りを**ARP(Address Resolution Protocol)**と言います。 ARPは正確にはレイヤ3に属するプロトコルなのですがレイヤ2のMACアドレスを理解するために重要なのでここで登場してもらいました。 ブロードキャスト ところで、「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という時には宛先MACアドレスには何を入れればいいでしょうか?宛先MACアドレスを知るための通信をするときの宛先MACアドレスです。 なかなか難しいですが、正解は「全員宛て」です。全員に通信を受け取ってもらって、受けとったコンピューターのうち、x.x.x.xのIPアドレスを持っているコンピューターからのみ返事をもらえればいいわけです。 このような「全員宛て」という意味で「FF-FF-FF-FF-FF-FF」というMACアドレスが使われます。先ほど「NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す」というように説明しましたが、より正確にはここで宛先MACアドレスとして「ブロードキャストアドレス(FF-FF-FF-FF-FF-FF)」やマルチキャストアドレス「01-00-5E…」であっても受け取って上位層に渡します。 MACアドレスだけではなぜいけないのか? さて、MACアドレスというものを知りました。宛先のアドレスはブロードキャスト、ARPを使って知ることができます。この仕組みだけあれば他にアドレスは必要ないようにも思います。なぜMACアドレスだけでは駄目なのでしょうか? 実際、昔Windowsネットワークで使われていたNETBEUIというプロトコルには他にアドレスは存在しません。NETBIOS名というものはつけますが、NETBEUIにおいてNETBIOS名はMACアドレスと一対一に対応付けられます。サブネットマスクだのデフォルトゲートウェイだのルーティングだの面倒なことはなにもありません。ネットワークに接続しさえすればきちんと通信できるのです。こっちのほうが楽でいいのではないでしょうか? この問いへの答えはブロードキャストのことを考えるとわかります。実際にデータを届けるには相手のMACアドレスが必要なわけですからブロードキャストするわけです。そのフレームは全コンピューターに届かなくてはいけません。これは小規模なネットワークなら問題にならないでしょう。ですが、今日最大のネットワークであるインターネットではどうでしょうか? インターネット上の全てのコンピューターの発するブロードキャストが全てのコンピューターが受信する必要があるとしたら、おそらくブロードキャストパケットだけでネットワークは飽和してしまうでしょう。 ...

February 12, 2009 · 1 min · 胡田昌彦