【緊急】社内LANが不通に

localhost(127.0.0.1)へのpingは通って、自分のNICのアドレスにpingが通らないのが不思議ですね。通信以前に、自分自身へのpingが通らないことを解決する必要がありそうです。

とりあえず・・・

・NortonInternetFireallを切るとどうですか？

・ipconfig はどのように表示されますか？

URLは可能性のひとつ。

各クライアントがDHCPから取得してきているIPアドレスなどの情報は正しいですか？

IPがかぶってたりしませんか？

あるいはスイッチングハブが故障しているとか。ハブは意外によく壊れます。

とにかくまだ調査すべきポイントがたくさんありそうです。これだけでは何ともいえません。

幾つか思いついたものを。

・G/Wと別ノードのIPアドレスの衝突

　DHCPなので基本的にはありえないし、G/Wが関係のない通信にまで影響を与えるとは

　考え難い。

・G/W ルーティングテーブルがおかしい

　この場合は、G/WからLANにpingが飛ばないなどの現象は理解できますが、

　LAN内に影響はしないと思われる・・・のであまり可能性は高くない。

　そもそも、急に変わるとも思えない。

　この原因ならtracertコマンドで分かる範囲ですね。

　逆に、ping同様tracertでも何にも情報を取れないような状態ですと、かなり低層に

　問題があるということになります。

　なので↓

・G/W LAN側NIC（またはHubのポート）の故障

　あくまでLAN側におかしなパケットを吐きつづけているような壊れ方をした場合

　ですが、今回のような現象も起こりうるかなぁ、と。

・LAN内に変なパケットを吐くノードがある。

　機器故障もそうですが、USB-LANアダプタやUSBリンクケーブルなど、一部の製品で

　ノードをつなげた場合、ネットワーク全体がおかしくなることがあります。

　何か、LAN内に不審なものを勝手につないでいる人がいたりしませんか？

現象からしておかしなパケットが流れているようにも感じますが、その場合は大抵HUB

がフル点滅状態になるのですよね。

ご質問の場合、「点灯」はしているが「点滅」しておらず、データが流れていないよう、

とのことなので、これも違うのかもしれません。

とはいえ、Etherealなどのパケットキャプチャソフトでパケットを拾ってみるのが一番確実そうですが。

Linux で構築したサーバーでの話ですが、同様な症状が出たことがあり、そのときの原因はイーサネットカードで、カードを交換したら正常に動くようになったと言う経験があります。安モノのカードの場合、 2 年位毎日酷使すればイカレル可能性は十分あります(体験談)。

また、内部の相互通信が出来ないと書かれていますが、サーバー以外のクライアント PC 間の通信も本当に出来ないのでしょうか？Windows は DHCP で IP を取得する設定にしてもサーバーが見付からない場合は、自分で勝手に適当な IP (確か 169 で始まるアドレスのはず)を付けて Windows 間のファイル共有などの相互通信が出来るようになります。なので、内部の何かが原因であるかを確認するにはサーバーを切って、クライアント PC だけを複数台ハブにつないで(クライアント PC を再起動して、しばらく待って)相互通信が出来るかを確認すべきだと思います。(ちなみに、Windows が自分で勝手に IP をつけるまでにそんなに時間はかかりませんが、相互通信が出来るようになるまでにはやや(数分～十数分程度)かかります。)

あと、クライアント PC が Samba サーバー(Unix系のファイル共有サーバー)を構築していた場合、それが原因でネットワークが不通になった場合もあります。その場合は Samba を再起動すれば解消しました。

URLはダミーです。

スイッチングハブが怪しいです。

昨年私が勤める会社でもにたような現象が起こり、

サーバをリブートすると一時的には改善しましたが、

時間の経過と共にレスポンスが悪化しました。

当初原因はサーバの不調と考えていましたが、

後にハブの故障と判明し、ハブを交換したところ、

回復したとのことです。

一度手持ちのハブとスイッチングハブを交換してみてはいかがでしょうか？

過去、私の管理するLAN組織で起こった出来事で役に立つ対策（やってないもの）があればやってみて下さい。

1:Bフレッツモデムの再起動

2:DNSサービスの再起動（この場合サーバ後と再起動してもいいかと）

3:FireWall系を全部切断。

私もSW-HUBよりGW側の問題だと思います。

がんばってください。

まずはIPCONFIG /allコマンドでDHCPから割り当てられているはずのIPアドレスとネットマスクを確認してください。DHCPサーバ及びドメインは固定アドレスなので、上手くDHCPサーバと通信できているか確認してください。次にroute print コマンドでローカルエリア及びNICのアドレスが適切に登録されているか確認してください。出来ていないならばroute add/deleteコマンドでとりあえずテーブルを修正してください。またIPCONFIGで不適切なアドレスになっているのであればDHCPの設定を確認する必要があります。またルーティングテーブルが適切に修正されればHUBのLEDは適切なのでpingはとおるはずです。

また外への通信が出来ているので、出ていましたがPathpingコマンドやTracertコマンドで第一フォワーディングルータが見えるか？（デフォルトGW)とりあえず教えてください。

IPが重なっているのだか、どれかのマシンのファイアウォールの設定ミスが悪さしているのだか、原因は特定できませんが、どれかのマシンが(もしくは組み合わせで)悪さをしているのは確かでしょう。

自分自身さえ見えないというのは、LANが繋がったり外れたりを繰り返しているのかも。

マスタブラウザになっているPCの問題かと思ったのですが、pingが通らないというのは違うかも。

こうなると、時間かかるかもしれませんが、切り分けをして行って、原因を探していくしかないと思います。

要するに、全部LANを一旦引っこ抜いて、一個一個繋げつつどこからおかしくなるか確認していく。または、現状から半分づつになるくらいでHUB同士の連結を一旦切って、どっちか治るかみて、治らない方でまた半分づつにして・・・

地道に探すのが結局は一番近道かも。

ただ、今回の件には関係ないかもしれませんが、一応、今の状態で、マスタブラウザのマシンを確認して、そのマシンの設定を確認するのを、最初に実行してみてください。

URLはそのマスタブラウザを確認する方法の記述です。

#3です。

> ＞この原因ならtracertコマンドで分かる範囲ですね。

> そのコマンドをどのように使用することで、何がわかるのでしょう？名前は知っていて

> つかったこともありますが、ネットワークエラー時にどう使えばよいのかを理解できて

> いません。こちらでも、今からそれを調べて見ます。

前述のように、LAN内に影響はしないと思われる（同一サブネットでの通信は正常にできるハズ）ので、この可能性は無いと思うのですが、ご参考までに。

G/W、クライアント、DNSサーバなど、各ノードから別のノードや外部（yahoo）など、pingをうったようにtracertしてみて、G/W以外のネットワークアドレスを経由しようとしていたらなにかおかしいということです。（同一サブネット内ならば経由なし）

たとえば、LAN内に管理者の知らないルータ、モバイル通信機器など、G/Wになり得るものがあって、それがRIPなどで「G/Wはこっちですよー」とクライアントに対して手を挙げているという場合や、ネットワークがループ構造になってしまった場合などに役立つと思います。

G/Wサーバ自体にに原因がある場合、直接G/Wのルーティングテーブルを読んでみた方がいいかもしれません。

　G/Wサーバ上で、コマンドプロンプトからROUTE PRINTで、宛先ネットワークとインターフェイスでおかしな組み合わせがないか確認します。

　LAN側クライアントで確認するのもいいと思います。（この場合はインターフェイスよりゲートウェイに注目）

　ただ、Windows98はRIPパケットなどでルーティングテーブルを書き換えますが、Windows2000はデフォルトでそういう動作はしないと思うので、たぶんクライアントのルーティングテーブルは変に書き換わってないと思います。

　また、ルーティングに起因する問題の場合は当然今回のように同一サブネット内での通信が不能になることはありません。

>可能性として、ゲートウェイサーバに侵入され、DHCPかDNS関連ファイルなどを書き換えられた・・・という可能性もなくはないです。

DHCPは、一旦IPをリースに出してしまえば、たとえサーバ側がおかしくなってもリース期限内は正常に通信できるはずです。

DNSも、IPアドレスでpingをうってもダメ、ということですので、関係なさそうです。

個人的には、やはりソフト的な障害の前に、#3で書いた中の３つめ、４つめを疑います。

再起動後しばらくは正常通信できるので、ハード的な障害は考え難いとのことですが、

HUBやルータも結構ハングアップしますし、NICにしても（ゴミパケットを吐いているような壊れ方の場合は）いきなり通信できなくなるというものでもありません。寧ろ、動き始めてしばらくしてから影響がたまってきて、通信不能になります。

なお、追記分で気になった点

G/W

> Autoconfiguration IP Address. . . : 169.254.94.*** （この値はDHCPから自動取得）

> Subnet Mask . . . . . . . . . . . : 255.255.0.0（この値はDHCPから自動取得）

これは・・・

DHCPでは通常こんなアドレスをふりません。むしろ、DHCPからIPアドレスを取得できない場合にAPIPA（Automatic Private IP Addressing）が自動的にふるIPアドレスです。

（http://www.atmarkit.co.jp/fnetwork/rensai/troutol06/02.htmlあたりを参照

）

ただ、これが外部側のNICですし、外部への接続はできるみたいなので、Bフレッツモデムにつないでいる分にはこれでいいのでしょう。

そもそも、G/WサーバがDHCPサーバとして機能しているのは、192.168.0.xxxのネットワークに対してのはずなので、外部向けのNICにDHCPからIPが振られることはないと思います。

不具合発生時に、GWサーバ<->社内サーバ間の通信が不安定な点、クライアントからの通信がどこにも飛ばない点から、GWサーバのDHCP機能が怪しいように思えます。

切り分けとして、１．クライアントPCに固定IPの割り当て ２．GWサーバのDHCPサービス停止を試みてはいかがでしょうか。

すくなくともこれで、DHCPが関係しているか否かが判断とれます。

障害内容のURLを拝見いたしました。

障害発生時に社内サーバ、クライアントA間のPingが通っていないのが気になります。

この間ではゲートウェイは関係ないはずですし、DNSで名前解決も行われないはずです。

問題切り分けの為、クライアントAのIPを手動で設定し、障害時に社内サーバ間でPingしてみてはどうでしょうか。

この状況でPingが通らない場合、ゲートウェイサーバのLANケーブルを抜いて、HUBをoff->onして再度、Pingしてみてください。

少なくとも、これでゲートウェイが原因かははっきりすると思います。

4 の回答者です。

まず、自分がした回答の補足です：

私が書いた『同様の症状』というのは、ただ単にサーバーと通信出来なくなるというだけでなく、『サーバーの再起動後しばらくは正常に通信できるが（数十分～数時間；この時間は毎回異なり、ランダム）、その後サーバーとの通信ができなくなる』という症状のことです。その意味でも見た目は全く同じ症状です。ちなみに、なぜイーサカードと結論したかというと、1) 別のカードに取り替えたらいつまで経っても通信可能だったこと、2) クライアント PC に問題のイーサカードを挿して使用したら、最初は通信できたが、しばらく後にそのクライアントでだけ通信出来なくなった。以上の 2 点から結論しました（もちろん他の設定は変えてない）。

その経験よりイーサカードが駄目になったからといって、必ずしもいきなり通信不可…ではなく、しばらくは通信可能な場合もあることを知りました。

以下、自分がこの問題に立ち向かうとしたらとってみる行動です、箇条書きにしましたので文章が無礼ですがお許しください。

- とりあえず、B フレッツモデムなどすべての機器の再起動はやってしまう。

- 自分はゲートウェイサーバーの内部側のイーサカードを疑ってしまうが、ネットワーク不通後も（自分からの ping のみではあるが） ping が通じるところに、これが原因でない可能性もあり不確定。とりあえず自分なら DNS サーバーかクライアント PC のイーサカードと GW サーバーの内部側のイーサカードを付け替えてどうなるか試す。

- GW が怪しいと見当をつけたら（自分なら）それを徹底的に検証する。とりあえず、1) 別のマシンを設定して GW サーバーにしてみる、2) ルーター機能を持ったハブを持ってきて GW にしてみる、3) 元の GW からハブなど一切経由させず一台のクライアントを直結し様子を見る。はすぐ思い付く。

- 確かに、dhcp は怪しい。IP の取得（再取得）の際になんだかえらいことが起こってるような気もする。

- 考えてみると IP の取得時刻が実際の取得時刻より 9 時間も遅いのが解せない。関係ないと思うけど 3 台の PC の時計の時刻がちゃんと合っているかどうかは確認してしまう。

- 上を受けて、クライアント PC を別なものにして、IP の取得時刻やネットワーク不通になるまでの時間を調べてみる。

- 回答 10 へのコメントに「クライアントPCに固定IPを割り当てたところで、相互通信はできないものと思われます。なぜなら、すでにゲートウェイサーバと社内サーバで通信ができていないからです。結局これと同じになると思われます。」と書かれているが、GW の内部側のイーサカードが駄目になっていた場合は、そもそも GW と DNS サーバーとの通信は出来ないし、dhcp の IP 再取得の際にネットワーク全体が死ぬのであれば、クライアントが IP を再取得しようとした時点でネットワーク全体が死に、その後は通信が出来なくなるので、この反論は無意味。なので、試す価値はあると思う。

- 内部ネットワークの問題のようなので、 GW サーバーと外部との接続を遮断し、DHCP サーバー、DNS サーバーとクライアント PC の外部とは繋がりの無い 3 台だけのネットワークを作って、ファイヤーウォールソフトを切って問題が起こるかどうか試してみる。

- こんなことは聞いたこと無いが、サーバーのログがいっぱいだから…なんて落ちじゃないだろうなー。でも、（今までのログは別名保存して）ログをクリアするってのは、自分ではやってしまうと思う（Windows ならそんな理由もありえるかも…なんて思ってしまう自分）。