Ubuntu日本語フォーラム

ksaito · 2012-04-08 23:27:45

いつも参考にさせていただいています。

Ubuntu Server 11.10を使っているのですが特定のクライアントと通信できません。
ちょと説明が難しいのですが...

Ubuntu Server 11.10側からpingを打つと一定時間（約30秒くらい）通信出来るのですが、すぐに通信が遮断されます。
下記にクライアントからUbuntu Serverに向けたpingのログを添付します。
最初通信は遮断されているのですがseq 5のあたりでUbuntu Server側からクライアントに向けてpingを打つと、通信が回復します。
しかし、しばらくするとRequest timeoutとなってしまいます。

同じクライアント上のゲストOS（ホストOSとは別IPアドレス）は、全く問題なく通信できているので、Ubuntu Serverが特定のIPアドレスを遮断しているように見えます。
どこから手をつけて良いか分からず途方にくれています。
どなたか、アドバイスいただけないでしょうか。

＜クライアントマシンのpingのログ＞
$ ping 10.10.10.10
PING 10.10.10.10 (192.168.2.100): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
64 bytes from 10.10.10.10: icmp_seq=11 ttl=64 time=0.786 ms
64 bytes from 10.10.10.10: icmp_seq=12 ttl=64 time=1.266 ms
64 bytes from 10.10.10.10: icmp_seq=13 ttl=64 time=6.236 ms
64 bytes from 10.10.10.10: icmp_seq=14 ttl=64 time=2.036 ms
64 bytes from 10.10.10.10: icmp_seq=15 ttl=64 time=2.522 ms
64 bytes from 10.10.10.10: icmp_seq=16 ttl=64 time=1.738 ms
64 bytes from 10.10.10.10: icmp_seq=17 ttl=64 time=1.494 ms
64 bytes from 10.10.10.10: icmp_seq=18 ttl=64 time=1.702 ms
64 bytes from 10.10.10.10: icmp_seq=19 ttl=64 time=1.152 ms
64 bytes from 10.10.10.10: icmp_seq=20 ttl=64 time=7.534 ms
64 bytes from 10.10.10.10: icmp_seq=21 ttl=64 time=3.238 ms
64 bytes from 10.10.10.10: icmp_seq=22 ttl=64 time=1.571 ms
64 bytes from 10.10.10.10: icmp_seq=23 ttl=64 time=4.466 ms
64 bytes from 10.10.10.10: icmp_seq=24 ttl=64 time=1.140 ms
64 bytes from 10.10.10.10: icmp_seq=25 ttl=64 time=2.163 ms
64 bytes from 10.10.10.10: icmp_seq=26 ttl=64 time=1.252 ms
64 bytes from 10.10.10.10: icmp_seq=27 ttl=64 time=9.304 ms
64 bytes from 10.10.10.10: icmp_seq=28 ttl=64 time=1.971 ms
64 bytes from 10.10.10.10: icmp_seq=29 ttl=64 time=1.363 ms
64 bytes from 10.10.10.10: icmp_seq=30 ttl=64 time=1.376 ms
64 bytes from 10.10.10.10: icmp_seq=31 ttl=64 time=2.268 ms
64 bytes from 10.10.10.10: icmp_seq=32 ttl=64 time=3.574 ms
64 bytes from 10.10.10.10: icmp_seq=33 ttl=64 time=2.699 ms
64 bytes from 10.10.10.10: icmp_seq=34 ttl=64 time=1.495 ms
64 bytes from 10.10.10.10: icmp_seq=35 ttl=64 time=2.658 ms
64 bytes from 10.10.10.10: icmp_seq=36 ttl=64 time=1.658 ms
64 bytes from 10.10.10.10: icmp_seq=37 ttl=64 time=2.053 ms
64 bytes from 10.10.10.10: icmp_seq=38 ttl=64 time=2.507 ms
64 bytes from 10.10.10.10: icmp_seq=39 ttl=64 time=0.731 ms
64 bytes from 10.10.10.10: icmp_seq=40 ttl=64 time=0.526 ms
64 bytes from 10.10.10.10: icmp_seq=41 ttl=64 time=0.485 ms
64 bytes from 10.10.10.10: icmp_seq=42 ttl=64 time=1.056 ms
64 bytes from 10.10.10.10: icmp_seq=43 ttl=64 time=1.449 ms
64 bytes from 10.10.10.10: icmp_seq=44 ttl=64 time=3.954 ms
64 bytes from 10.10.10.10: icmp_seq=45 ttl=64 time=2.322 ms
64 bytes from 10.10.10.10: icmp_seq=46 ttl=64 time=0.744 ms
64 bytes from 10.10.10.10: icmp_seq=47 ttl=64 time=1.714 ms
64 bytes from 10.10.10.10: icmp_seq=48 ttl=64 time=2.025 ms
64 bytes from 10.10.10.10: icmp_seq=49 ttl=64 time=1.636 ms
64 bytes from 10.10.10.10: icmp_seq=50 ttl=64 time=4.989 ms
64 bytes from 10.10.10.10: icmp_seq=51 ttl=64 time=2.081 ms
64 bytes from 10.10.10.10: icmp_seq=52 ttl=64 time=1.481 ms
64 bytes from 10.10.10.10: icmp_seq=53 ttl=64 time=1.486 ms
64 bytes from 10.10.10.10: icmp_seq=54 ttl=64 time=2.103 ms
Request timeout for icmp_seq 55
^C
--- 10.10.10.10 ping statistics ---
57 packets transmitted, 44 packets received, 22.8% packet loss
round-trip min/avg/max/stddev = 0.485/2.318/9.304/1.767 ms
$

zagan · 2012-04-09 00:08:44

サーバー機（S）とクライアントA間で通信異常が発生するが、S機とクライアントBでは通信異常は発生しない。

ということですかね？

問題点を明確にするために
1)クライアントAとBとの間ではどのようなpingの結果が出るのでしょう。
2)大きなファイルをインターネットからダウンロード（例えばUbuntuのインストールイメージとか）をダウンロードしたときの、速度をAとBで比べてみる。
3)Lanケーブルの抜き差しを実施してみる。また、正常通信の実績のあるLanケーブルにつないで、S機との間でPingを実施してみる。
4)Hubやルーターの電源を落としてしばらく放置。5分ほどで再起動させて通信状況を確認してみる。

NIC名を書いておくと、詳しい方からの回答が得られるかもしれません。

ry · 2012-04-09 08:00:38

ksaitoさんによる投稿:
同じクライアント上のゲストOS（ホストOSとは別IPアドレス）

何らかの仮想マシンを使用しているのでしょうか？
仮想マシンゆえの設定ミスがあるかもしれませんので、この辺りについてももう少し詳しい説明が欲しいです

hmatsue · 2012-04-09 13:08:56

ksaito による投稿:
$ ping 10.10.10.10
PING 10.10.10.10 (192.168.2.100): 56 data bytes

の部分が不思議に感じますが、ネットワーク構成はどのようになっていますでしょうか。
ルータの設定が悪いだけということは無いでしょうか。

コード:

WAN - ルータ1(10.x.x.x) +- (10.y.y.y)ルータ2(192.168.2.z) - クライアント(192.168.2.100)
                       |
                       +- Ubuntu Server(10.10.10.10)

のような感じになっているのでしょうか。
通信に問題が無いという仮想マシンはどのような接続、アドレスになっていますでしょうか。

zagan · 2012-04-09 13:17:31

ryさんによる投稿:
ksaitoさんによる投稿:
同じクライアント上のゲストOS（ホストOSとは別IPアドレス）
何らかの仮想マシンを使用しているのでしょうか？
仮想マシンゆえの設定ミスがあるかもしれませんので、この辺りについてももう少し詳しい説明が欲しいです

あ。そうか・・・

「仮想マシン」のくだり読んでませんでした。すみません。

ルーター環境下でServerを立ち上げられてるってことで、DHCPサーバーが二重に存在しているとかですかねー
仮想マシンのネットワーク設定がブリッジモードになってるかどうかも確認した方が良いかもしれません。

ksaito · 2012-04-10 08:22:05

zaganコメントありがとうございます。（順次確認していきます。）

>

zagan による投稿:
サーバー機（S）とクライアントA間で通信異常が発生するが、S機とクライアントBでは通信異常は発生しない。
>ということですかね？

はい
サーバ機（S)とクライアントAに向けてのpingは問題ありません。
サーバ機（S)とクライアントAに向けてのpingを打つと、失敗していたクライアントAからサーバ機（S）のpingが通るようになります。
サーバ機（S)とクライアントAに向けてのpingを止めて暫くするとクライアントAからサーバ機（S）が再びTime outとなります。

>問題点を明確にするために
>1)クライアントAとBとの間ではどのようなpingの結果が出るのでしょう。
サーバ機（S）が10.10.10.10、クライアントAが10.10.10.7です。
サーバ機（S）からのpingは常に成功します。

S $ ping 10.10.10.7
PING 10.10.10.7 (10.10.10.7) 56(84) bytes of data.
64 bytes from 192.168.2.70: icmp_req=1 ttl=64 time=1.18 ms
64 bytes from 192.168.2.70: icmp_req=2 ttl=64 time=2.26 ms
64 bytes from 192.168.2.70: icmp_req=3 ttl=64 time=0.755 ms
64 bytes from 192.168.2.70: icmp_req=4 ttl=64 time=16.2 ms
64 bytes from 192.168.2.70: icmp_req=5 ttl=64 time=1.58 ms
64 bytes from 192.168.2.70: icmp_req=6 ttl=64 time=63.1 ms
64 bytes from 192.168.2.70: icmp_req=7 ttl=64 time=1.08 ms
64 bytes from 192.168.2.70: icmp_req=8 ttl=64 time=0.984 ms
64 bytes from 192.168.2.70: icmp_req=9 ttl=64 time=31.6 ms
64 bytes from 192.168.2.70: icmp_req=10 ttl=64 time=5.53 ms
^C
--- 192.168.2.70 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9004ms
rtt min/avg/max/mdev = 0.755/12.447/63.109/19.352 ms
S $

>4)Hubやルーターの電源を落としてしばらく放置。5分ほどで再起動させて通信状況を確認してみる。

これは、何度か行なっていますが一向に状況は改善していません。

>NIC名を書いておくと、詳しい方からの回答が得られるかもしれません。

サーバ側の情報です。（一部マスクしました）
$ ifconfig
eth0 Link encap:イーサネットハードウェアアドレス ***
inetアドレス:10.10.10.10 ブロードキャスト:10.10.10.255 マスク:255.255.255.0
inet6アドレス: ****/64 範囲:リンク
UP BROADCAST RUNNING MULTICAST MTU:1500 メトリック:1
RXパケット:4891738 エラー:0 損失:0 オーバラン:0 フレーム:0
TXパケット:5577531 エラー:0 損失:0 オーバラン:0 キャリア:0
衝突(Collisions):0 TXキュー長:1000
RXバイト:472324021 (472.3 MB) TXバイト:1055661002 (1.0 GB)
割り込み:40 ベースアドレス:0x6000

lo Link encap:ローカルループバック
inetアドレス:127.0.0.1 マスク:255.0.0.0
inet6アドレス: ::1/128 範囲:ホスト
UP LOOPBACK RUNNING MTU:16436 メトリック:1
RXパケット:459118 エラー:0 損失:0 オーバラン:0 フレーム:0
TXパケット:459118 エラー:0 損失:0 オーバラン:0 キャリア:0
衝突(Collisions):0 TXキュー長:0
RXバイト:151336397 (151.3 MB) TXバイト:151336397 (151.3 MB)

$

下記は、順次確認してご報告します。

>2)大きなファイルをインターネットからダウンロード（例えばUbuntuのインストールイメージとか）をダウンロードしたときの、速度をAとBで比べてみる。
>3)Lanケーブルの抜き差しを実施してみる。また、正常通信の実績のあるLanケーブルにつないで、S機との間でPingを実施してみる。

ksaito · 2012-04-10 22:26:45

hmatsueさん

ネットワーク環境は、以下の通りです。
最初からネットワーク環境の説明をしておくべきでした。

コード:

WAN - ルータ1(10.10.10.1) 
                     |
                     +- Ubuntu Server(10.10.10.10)
                     |
                     +- クライアント1(10.10.10.7)
                     |
                     +- クライアント2(10.10.10.8)
                     （クライアント1で動いているParallels Desktop上の仮想マシンでブリッジモード）

クライアント1からルータ経由でインターネットへの接続は問題ありません。
クライアント1からクライアント2へのアクセスも問題ありません。
クライアント1からUbuntu Serverへの接続が遮断されていて、Ubuntu Serverからクライアント1にpingを打つと、30秒くらいクライアント1からUbuntu Serverの通信が回復するという状況です。

クライアント1からUbuntu Serverに接続できないので、いつもクライアント2経由でUbuntu Serverを操作している状況です。

ksaito · 2012-04-10 22:29:06

ry による投稿:
ksaitoさんによる投稿:
同じクライアント上のゲストOS（ホストOSとは別IPアドレス）
何らかの仮想マシンを使用しているのでしょうか？
仮想マシンゆえの設定ミスがあるかもしれませんので、この辺りについてももう少し詳しい説明が欲しいです

ryさん

使用しているのは、Parallels Desktop 7 for Macです。
仮想OSは、Ubuntu、ホストOSはMac X 10.7.3です。
仮想OSは、ブリッジネットワークです。

ksaito · 2012-04-11 00:04:25

Ubuntu Server上でwatch "netstat -a | grep 10.10.10.7"で監視しながらsshで接続を試みるとSYN_RECVが何度か表示されます。

コード:

tcp        0      0 10.10.10.10.1:ssh 10.10.10.7:60751     SYN_RECV

暫くするとクライアント1側のsshはタイムアウトとなります。

コード:

$ ssh 192.168.2.100
ssh: connect to host 192.168.2.100 port 22: Operation timed out
$

ksaito · 2012-04-11 00:11:17

Ubuntu Serverを再起動してクライアント1からssh接続したところ、問題なく接続できるようになりました。
同じ操作でnetstatを確認するとESTABLISHEDで接続されています。

コード:

tcp        0    480 10.10.10.10.1:ssh 10.10.10.7:61044     ESTABLISHED

クライアント1は、iMacで普段スリープ／復帰を繰り返しているのが影響しているのかもしれません。
現象が再現するか、しばらく様子を見てみます。

hmatsue · 2012-04-11 00:43:28

ksaito による投稿:

コード:

WAN - ルータ1(10.10.10.1) 
         |
         +- Ubuntu Server(10.10.10.10)
         |
         +- クライアント1(10.10.10.7)
         |
         +- クライアント2(10.10.10.8)
         （クライアント1で動いているParallels Desktop上の仮想マシンでブリッジモード）

pingの結果などに登場する、192.168.2.100や、192.168.2.70が居ないのが気になります。
各マシン上で、

コード:

ifconfig
route

とすると何が起きているのか分かるかも知れません。
あとは、

コード:

nmap -sP 192.168.2.0/24
nmap -sP 10.10.10.0/24

みたいな感じでネットワーク上のデバイスを全部洗いだすか。
(サブネットマスクは適切な値に直して下さい)

ksaito · 2012-04-11 07:29:13

hmatsue による投稿:
pingの結果などに登場する、192.168.2.100や、192.168.2.70が居ないのが気になります。

MACアドレスはマスク、IPアドレスは置き換えしたほうが良いと思い結果を編集しました。
紛らわしいことをしてすみませんでした。

192.168.2.100がUbuntu Server(10.10.10.10)
192.168.2.70がクライアント1(10.10.10.7)
とで間違いありません。

ry · 2012-04-11 07:46:11

ksaitoさんによる投稿:
MACアドレスはマスク、IPアドレスは置き換えしたほうが良いと思い結果を編集しました。

IP アドレスはプライベートアドレス (10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/16 に含まれるアドレス) なら書き替える必要はありません
同じ LAN 内に居なければ手の出しようがありませんので
MAC についてもインターネットから繋がらない部分なら書き替えなくても良いと思いますが、こちらなインターフェース単位で特定できるので判断は微妙ですね

ところで、クライアント1 (ホスト OS) とクライアント2 (ゲスト OS) で NIC の MAC が同じになってしまっているということはありませんよね

hmatsue · 2012-04-11 13:15:10

なんだか状況がよくわからなくなってしまいましたが、結局のところ、192.168.2.xなIPアドレスのマシンはネットワーク上には存在しないということでよいでしょうか。
各マシンのIPドレスは、10.10.10.x/24で統一されているということかと理解しましたが、ルータも含めて設定を間違えていないか確認してみて下さい。
また、ryさんがご指摘のように(特に仮想マシンの)NICのMACアドレスに重複がでていないか確認してみて下さい。

クライアントAと呼んでいるものと、クライアント1と呼んでいるものは同じものという理解でよいでしょうか。
そして、クライアントAから、サーバー機へのアクセスが途絶えるという現象という理解でよろしいでしょうか。
また、クライアントAのOSはMAC OS Xでしょうか。

クライアントAには、仮想マシンがのっているようなので、クライアントAで仮想のNICなどが認識されていないか、また、認識されている場合はそのIPアドレスがいくつになっているのか確認が必要かと思います。
MAC OS Xは触ったことがないのでよくわかりませんが、恐らく、routeコマンドや、ifconfigが使えるのではないかと思います。
もしなければ類似のコマンドを探して、認識されているNICとその設定状況の一覧(もし気にするのであればMACは伏せていただいて、その旨連絡下さい)と、routeの設定状況を投稿してみて下さい。

ksaito · 2012-04-11 22:15:58

ry による投稿:
IP アドレスはプライベートアドレス (10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/16 に含まれるアドレス) なら書き替える必要はありません
同じ LAN 内に居なければ手の出しようがありませんので
MAC についてもインターネットから繋がらない部分なら書き替えなくても良いと思いますが、こちらなインターフェース単位で特定できるので判断は微妙ですね

ところで、クライアント1 (ホスト OS) とクライアント2 (ゲスト OS) で NIC の MAC が同じになってしまっているということはありませんよね

ryさん

アドバイスありがとうございます。
プライベートアドレスは、書き換えなしで転記するようにします。

クライアント1 (ホスト OS) とクライアント2 (ゲスト OS) で NIC の MACアドレスは別になっています。

Ubuntu Serverを再起動すると問題なく通信できるようになりますが、クライアント1（ホストOS）であるiMacをスリープして復帰すると再現します。

ksaito · 2012-04-11 23:11:01

hmatsue による投稿:
なんだか状況がよくわからなくなってしまいましたが、結局のところ、192.168.2.xなIPアドレスのマシンはネットワーク上には存在しないということでよいでしょうか。
各マシンのIPドレスは、10.10.10.x/24で統一されているということかと理解しましたが、ルータも含めて設定を間違えていないか確認してみて下さい。
また、ryさんがご指摘のように(特に仮想マシンの)NICのMACアドレスに重複がでていないか確認してみて下さい。

クライアントAと呼んでいるものと、クライアント1と呼んでいるものは同じものという理解でよいでしょうか。
そして、クライアントAから、サーバー機へのアクセスが途絶えるという現象という理解でよろしいでしょうか。
また、クライアントAのOSはMAC OS Xでしょうか。

クライアントAには、仮想マシンがのっているようなので、クライアントAで仮想のNICなどが認識されていないか、また、認識されている場合はそのIPアドレスがいくつになっているのか確認が必要かと思います。
MAC OS Xは触ったことがないのでよくわかりませんが、恐らく、routeコマンドや、ifconfigが使えるのではないかと思います。
もしなければ類似のコマンドを探して、認識されているNICとその設定状況の一覧(もし気にするのであればMACは伏せていただいて、その旨連絡下さい)と、routeの設定状況を投稿してみて下さい。

hmatsueさん

うまく説明できず、すみません。
アドバイスいただいた内容で調べてみようと思います。
macにもrouteコマンドはあるのですが、オプションの指定などが異なるようでルーティングテーブルの情報がとれていません。
少し時間がかかりそうです。

指摘いただいたコメントへの回答です。順番前後しますがご了承下さい。

hmatsue による投稿:
クライアントAと呼んでいるものと、クライアント1と呼んでいるものは同じものという理解でよいでしょうか。
そして、クライアントAから、サーバー機へのアクセスが途絶えるという現象という理解でよろしいでしょうか。
また、クライアントAのOSはMAC OS Xでしょうか。

上記、３点は指摘の通りです。

hmatsue による投稿:
また、ryさんがご指摘のように(特に仮想マシンの)NICのMACアドレスに重複がでていないか確認してみて下さい。

MACアドレスの重複はありませんでした。

hmatsue による投稿:
結局のところ、192.168.2.xなIPアドレスのマシンはネットワーク上には存在しないということでよいでしょうか。
各マシンのIPドレスは、10.10.10.x/24で統一されているということかと理解しましたが、ルータも含めて設定を間違えていないか確認してみて下さい。
クライアントAには、仮想マシンがのっているようなので、クライアントAで仮想のNICなどが認識されていないか、また、認識されている場合はそのIPアドレスがいくつになっているのか確認が必要かと思います。

IPアドレスやMACアドレスは、マスクや置き換えをしたほうが良いと思い、中途半端に置き換えたため混乱させてしまいすみませんでした。
以下、各マシンのifconfigの内容をMACアドレスのみマスクした情報です。

コード:

Client1$ ifconfig en1
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    ether **:**:**:**:**:b3 
    inet6 fe80::cabc:c8ff:fec8:e2b3%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.2.70 netmask 0xffffff00 broadcast 192.168.2.255
    media: autoselect
    status: active
Client1$ uname -srmp
Darwin 11.3.0 x86_64 i386
Client1$

コード:

UbuntuServer$ ifconfig eth0
eth0      Link encap:イーサネット  ハードウェアアドレス **:**:**:**:**:bd
          inetアドレス:192.168.2.100  ブロードキャスト:192.168.2.255  マスク:255.255.255.0
          inet6アドレス: fe80::e2cb:4eff:fe98:ddbd/64 範囲:リンク
          UP BROADCAST RUNNING MULTICAST  MTU:1500  メトリック:1
          RXパケット:107345 エラー:0 損失:0 オーバラン:0 フレーム:0
          TXパケット:113297 エラー:0 損失:0 オーバラン:0 キャリア:0
          衝突(Collisions):0 TXキュー長:1000
          RXバイト:9203021 (9.2 MB)  TXバイト:8283997 (8.2 MB)
          割り込み:40 ベースアドレス:0x6000

UbuntuServer$ route -n
カーネルIP経路テーブル
受信先サイト    ゲートウェイ    ネットマスク   フラグ Metric Ref 使用数 インタフェース
0.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
UbuntuServer$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.10
DISTRIB_CODENAME=oneiric
DISTRIB_DESCRIPTION="Ubuntu 11.10"
UbuntuServer$ 
UbuntuServer$

コード:

Client2$ ifconfig eth0
eth0      Link encap:イーサネット  ハードウェアアドレス **:**:**:**:**:f4  
          inetアドレス:192.168.2.101  ブロードキャスト:192.168.2.255  マスク:255.255.255.0
          inet6アドレス: fe80::21c:42ff:fe26:77f4/64 範囲:リンク
          UP BROADCAST RUNNING MULTICAST  MTU:1500  メトリック:1
          RXパケット:165169 エラー:0 損失:28 オーバラン:0 フレーム:0
          TXパケット:128411 エラー:0 損失:0 オーバラン:0 キャリア:0
          衝突(Collisions):0 TXキュー長:1000 
          RXバイト:15307472 (15.3 MB)  TXバイト:43382617 (43.3 MB)

Client2$ route -n
カーネルIP経路テーブル
受信先サイト    ゲートウェイ    ネットマスク   フラグ Metric Ref 使用数 インタフェース
0.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Client2$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.10
DISTRIB_CODENAME=oneiric
DISTRIB_DESCRIPTION="Ubuntu 11.10"
Client2$

Client1は、Mac OSで、Client2はClient1上で動くParallels Desktopの仮想マシンです。

hmatsue · 2012-04-12 13:15:38

MAC OS Xのrouteでは、ルーティング情報の出力はできないようですね。ネット検索してみたところ、
http://fixunix.com/unix/260853-mac-os-x-how-get-route-listing.html
が見付かりました。
netstat -rn
などで確認できそうです。

Client1には、en1以外のネットワークデバイスとして何が認識されていますでしょうか。
loだけでしょうか。
netstat -rnの出力を見ればわかるかもですが、ルーティング情報が適切で無い可能性を疑っています。

ksaito · 2012-04-14 21:05:08

hmatsueさんによる投稿:
Client1には、en1以外のネットワークデバイスとして何が認識されていますでしょうか。
loだけでしょうか。

Macは、ずいぶんたくさんのネットワークデバイスが認識されています。

コード:

Client1$ ifconfig 
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
    ether **:**:**:**:**:e0 
    media: autoselect (none)
    status: inactive
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    ether **:**:**:**:**:b3 
    inet6 fe80::cabc:c8ff:fec8:e2b3%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.2.70 netmask 0xffffff00 broadcast 192.168.2.255
    media: autoselect
    status: active
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
    lladdr 70:cd:60:ff:fe:40:88:62 
    media: autoselect <full-duplex>
    status: inactive
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
    ether **:**:**:**:**:b3 
    media: autoselect
    status: active
vboxnet0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether **:**:**:**:**:00 
vnic0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=3<RXCSUM,TXCSUM>
    ether **:**:**:**:**:08 
    inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255
    media: autoselect
    status: active
vnic1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=3<RXCSUM,TXCSUM>
    ether **:**:**:**:**:09 
    inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
    media: autoselect
    status: active
Client1$

下記は、デフォルトで設定されているデバイスのようです。
lo0 = loopback
gif0 = Software Network Interface
stf0 = 6to4 tunnel interface
en0 = Ethernet 0
fw0 = Firewire
en1 = Ethernet 1

p2p0は、よくわかりませんでしたが、AirDropで使うインタフェースのようです。

vboxnet0は、Oracle VirtualBoxの仮想マシン用のネットワークです。
vnic0とvnic1は、Parallels Desktopの仮想マシン用のネットワークです。

hmatsueさんによる投稿:
MAC OS Xのrouteでは、ルーティング情報の出力はできないようですね。ネット検索してみたところ、
http://fixunix.com/unix/260853-mac-os-x-how-get-route-listing.html
が見付かりました。
netstat -rn
などで確認できそうです。

netstat -rnの出力を見ればわかるかもですが、ルーティング情報が適切で無い可能性を疑っています。

netstat -nrコマンドでルーティングテーブルが表示されるのですね。
Client1(192.168.2.70)からUbuntuServer(192.168.2.100)にpingが通らない状態でnetstat -nrを実行した結果です。（MACアドレスはマスクしました）

コード:

Client1$ ping 192.168.2.100
PING 192.168.2.100 (192.168.2.100): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 192.168.2.100 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Client1$ netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.2.1        UGSc           27        0     en1
10.37.129/24       link#9             UC              1        0   vnic1
10.37.129.2        **:**:**:**:**:9      UHLWIi          1        1     lo0
10.211.55/24       link#8             UC              1        0   vnic0
10.211.55.2        **:**:**:**:**:8      UHLWIi          1        1     lo0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              8    80785     lo0
169.254            link#5             UCS             0        0     en1
192.168.2          link#5             UCS             6        0     en1
192.168.2.1        **:**:**:**:**:6e    UHLWIi         27        3     en1    568
192.168.2.70       127.0.0.1          UHS             0        0     lo0
192.168.2.100      **:**:**:**:**:bd  UHLWIi          0     1849     en1   1200

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     link#1                          UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en1/64                           link#5                          UCI             en1
fe80::cabc:c8ff:fec8:e2b3%en1           **:**:**:**:**:b3               UHLI            lo0
ff01::%lo0/32                           fe80::1%lo0                     UmCI            lo0
ff01::%en1/32                           link#5                          UmCI            en1
ff02::%lo0/32                           fe80::1%lo0                     UmCI            lo0
ff02::%en1/32                           link#5                          UmCI            en1
Client1$

hmatsue · 2012-04-14 22:24:45

ごめんなさい。思っていたより複雑な表示のようで、ぱっと見ただけでは正常かどうか判断つきませんでした。
どなかたMACに詳しい方の登場を待つか、これまでの状況を添えて、MAC系のフォーラム的な場所で聞いて頂いた方が良いかも知れません。
以下、分からないなりに、不思議に感じた点を列挙します。

ksaito による投稿:

コード:

Client1$ ifconfig 
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    ether **:**:**:**:**:b3 
    inet6 fe80::cabc:c8ff:fec8:e2b3%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.2.70 netmask 0xffffff00 broadcast 192.168.2.255
    media: autoselect
    status: active

上記はen1のMACアドレスの末尾がb3であるという意味ですよね。

ksaito による投稿:

コード:

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.2.1        UGSc           27        0     en1
10.37.129/24       link#9             UC              1        0   vnic1
10.37.129.2        **:**:**:**:**:9      UHLWIi          1        1     lo0
10.211.55/24       link#8             UC              1        0   vnic0
10.211.55.2        **:**:**:**:**:8      UHLWIi          1        1     lo0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              8    80785     lo0
169.254            link#5             UCS             0        0     en1
192.168.2          link#5             UCS             6        0     en1
192.168.2.1        **:**:**:**:**:6e    UHLWIi         27        3     en1    568
192.168.2.70       127.0.0.1          UHS             0        0     lo0
192.168.2.100      **:**:**:**:**:bd  UHLWIi          0     1849     en1   1200

1. 192.168.2の項目のGatewayは、192.168.2.0の意味のような気がしましたが、これは恐らくen1を指しているものと思います。
2. 192.168.2.1の項目のGatewayが末尾6eなMACアドレス(?)を指しているように見えますが、これは正常な状態でしょうか。
3. 192.168.2.100の項目のGatewayが末尾bdなMACアドレス(?)を指しているように見えますが、これは正常な状態でしょうか。
GatewayにMACアドレスというのが馴染みがないので、あくまでも不思議に感じた点、というだけのことですが。。

ry · 2012-04-15 07:51:55

hmatsueさんによる投稿:
1. 192.168.2の項目のGatewayは、192.168.2.0の意味のような気がしましたが、これは恐らくen1を指しているものと思います。
2. 192.168.2.1の項目のGatewayが末尾6eなMACアドレス(?)を指しているように見えますが、これは正常な状態でしょうか。
3. 192.168.2.100の項目のGatewayが末尾bdなMACアドレス(?)を指しているように見えますが、これは正常な状態でしょうか。

192.168.2 の行 (192.168.2.0/24 に対する情報) は、このアドレスへの通信は Link#5 を介して行うことを意味し、Link#5 は OS が各インターフェース (NIC) に割り当てた ID でありたぶん en1 を指すと断定してもいいでしょう

ひとつ飛ばして、192.168.2.100 の行では Flags の項目に H が含まれることから、同じ物理ネットワークセグメント内のホストとして直接通信が可能と認識されていることがわかります
Gateway の項目の MAC も #16 で提示された MAC と合致しており、特に問題はなさそうに見えます

ksaitoさん (#16) による投稿:

コード:

UbuntuServer$ ifconfig eth0
eth0      Link encap:イーサネット  ハードウェアアドレス **:**:**:**:**:bd
          inetアドレス:192.168.2.100  ブロードキャスト:192.168.2.255  マスク:255.255.255.0

UbuntuServer (192.168.2.100) 側で、ping が繋がるとき繋がらないときの netstat -rn の結果はどうなっているかも見てみたいですね

hmatsue · 2012-04-15 12:17:26

ああ、なるほど。arpの情報も表示されているようなイメージでよいのかしら。
ご教示多謝です。 > ryさん

と、すると、ルータが接続デバイスのＭＡＣアドレスをすぐに忘れてしまっていて、OS X側はそんなこと気にせず、Ubuntu ServerのMACアドレスを宛先にしてフレーム送信してしまい、ルータが破棄している、とかいう可能性は無いかしら、とか思ったりもします。
Expire欄の意味や単位がわからないのですが、このあたりが怪しそうな気もするので、192.168.0.100の項目のExpireをもっと短かく設定変更することはできないでしょうか。

あとバージョンなどが異なるので今のところ関連するようには思えませんが、ちょっと気になった情報を見付けたので備忘としてメモっておきます。
http://forum.parallels.com/showthread.php?t=110792
今は気にしないで下さい。

ry · 2012-04-15 16:59:53

hmatsueさん (#21) による投稿:
ルータが接続デバイスのＭＡＣアドレスをすぐに忘れてしまって

Client1 [Mac] (192.168.2.70) での　netstat -nr の結果 (#18 参照) で、UbuntuServer の 192.168.2.100 に関するエントリで MAC が表示されていることから、ルーターを介さず直接通信していることが読み取れれます
このため、ルーターが何らかの要因であるとの想定は除外していいと思います

hmatsueさん (#21) による投稿:
Expire欄の意味や単位がわからない

たぶんですが、単位は秒でしょう
OS (IP スタック) のパラメーターを弄れば Expire を短くすることも可能だと思います (具体的な手順は知りません)
ping が通らないときの Client1 における netstat -rn の結果 (#18 参照) で 192.168.2.100 に関する項目に表れている MAC は、UbuntuServer を指している現状では、これをしたところで何の意味も為さないと予想します

hmatsueさん (#21) による投稿:
あとバージョンなどが異なるので今のところ関連するようには思えませんが、ちょっと気になった情報を見付けたので備忘としてメモっておきます。
http://forum.parallels.com/showthread.php?t=110792

これも今回は IPv4 アドレスを指定して ping を実行しているので関係はなさそうですが、IPv6 と IPv4 の使い分けは実装依存の部分のあるようなので、無関係とは言い切りづらいところです

IPv6 を使っていないのであれば、思い切って Clinet1 [Mac]、UbuntuServer、Clinet2 [Parallels のゲスト] のすべてで IPv6 を無効にしてもいいかもしれません

hmatsue · 2012-04-15 18:18:35

ry による投稿:
hmatsueさん (#21) による投稿:
ルータが接続デバイスのＭＡＣアドレスをすぐに忘れてしまって
Client1 [Mac] (192.168.2.70) での　netstat -nr の結果 (#18 参照) で、UbuntuServer の 192.168.2.100 に関するエントリで MAC が表示されていることから、ルーターを介さず直接通信していることが読み取れれます
このため、ルーターが何らかの要因であるとの想定は除外していいと思います

すみません。言葉足らずでした。
ルータというよりは、スイッチといった方が良かったかもです。
# とか言いつつ、だんだんルータとスイッチの区別が良く分からなくなってきた。。

このあたりは、ksaitoさんに改めてネットワーク接続がどのようになっているか確認した方が良いかもですね。
私が想定しているのは、LAN側がスイッチングハブとして動作する、いわゆるブロードバンドルータに各PC(Server,Client)が接続されている環境です(#7のksaitoさんの投稿より)。

以下は根拠薄弱なのですが、
1. ルータのMACアドレスに投げたフレームはIPアドレスから判断して正しく転送される。
2. ルータが認識しているMACアドレスに対して投げられたフレームは正しく転送される。
3. ルータが忘れたMACアドレスに対して投げたフレームは転送(スイッチ)されずに破棄される。
というような状況になっていないかな、と想像しています。

書いていて思いましたが、もし本当に上記のような挙動をルータが示すのであれば、ルータ(あるいはスイッチとしても)として、かなりおかしな挙動ですね。。

宛 ksaitoさん
まずは、#7の図が正確かどうか。
ハブなどを使わず、#7のような接続になっているのであれば、ルータの型式、および、可能であればデータシート、マニュアル類へのリンクを投稿願えますでしょうか。

ksaito · 2012-04-15 18:32:13

ryさん(#20) による投稿:
UbuntuServer (192.168.2.100) 側で、ping が繋がるとき繋がらないときの netstat -rn の結果はどうなっているかも見てみたいですね

pingで繋がるときのnetstat -nrの結果です。
#18と同じタイミングで繋がるときの結果を取得していたのですが、192.168.2.100のエントリに変化なかったのでアップしませんでした。
改めて、見比べてMACアドレスがff:ff:ff:ff:ff:ffというのが追加されていることに気が付きました。
何度か試してみましたが、pingの疎通とは関係なくエントリに追加されたり、なくなったりしているように見えます。
192.168.2.101のエントリは、ゲストOSのClient2を起動したため追加されているので無関係のようです。

コード:

Client1$ ping 192.168.2.100
PING 192.168.2.100 (192.168.2.100): 56 data bytes
Request timeout for icmp_seq 0
...中略...
Request timeout for icmp_seq 12
64 bytes from 192.168.2.100: icmp_seq=13 ttl=64 time=1.366 ms
64 bytes from 192.168.2.100: icmp_seq=14 ttl=64 time=0.699 ms
64 bytes from 192.168.2.100: icmp_seq=15 ttl=64 time=1.661 ms
64 bytes from 192.168.2.100: icmp_seq=16 ttl=64 time=1.789 ms
64 bytes from 192.168.2.100: icmp_seq=17 ttl=64 time=3.574 ms
64 bytes from 192.168.2.100: icmp_seq=18 ttl=64 time=0.831 ms
^C
--- 192.168.2.100 ping statistics ---
19 packets transmitted, 6 packets received, 68.4% packet loss
round-trip min/avg/max/stddev = 0.699/1.653/3.574/0.947 ms
Client1$ netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.2.1        UGSc           27        0     en1
10.37.129/24       link#9             UC              2        0   vnic1
10.37.129.2        **:**:**:**:**:9      UHLWIi          1        1     lo0
10.37.129.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        2   vnic1
10.211.55/24       link#8             UC              2        0   vnic0
10.211.55.2        **:**:**:**:**:8      UHLWIi          1        1     lo0
10.211.55.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        2   vnic0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              8    80785     lo0
169.254            link#5             UCS             0        0     en1
192.168.2          link#5             UCS             8        0     en1
192.168.2.1        **:**:**:**:**:6e    UHLWIi         27        3     en1    427
192.168.2.70       127.0.0.1          UHS             0        0     lo0
192.168.2.100      **:**:**:**:**:bd  UHLWIi          0     1903     en1   1193
192.168.2.101      **:**:**:**:**:f4   UHLWIi          2      337     en1   1124
192.168.2.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        2     en1

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     link#1                          UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en1/64                           link#5                          UCI             en1
fe80::cabc:c8ff:fec8:e2b3%en1           **:**:**:**:**:b3               UHLI            lo0
ff01::%lo0/32                           fe80::1%lo0                     UmCI            lo0
ff01::%en1/32                           link#5                          UmCI            en1
ff02::%lo0/32                           fe80::1%lo0                     UmCI            lo0
ff02::%en1/32                           link#5                          UmCI            en1
Client1$

ry · 2012-04-16 07:34:29

ksaitoさん (#24) による投稿:
Client1$ netstat -nr

UbuntuServer (192.168.2.100) で実行した結果を提示ください

Ubuntu日本語フォーラム

お知らせ

#1 2012-04-08 23:27:45

特定のクライアントとの通信が一定時間たつと遮断される

#2 2012-04-09 00:08:44

Re: 特定のクライアントとの通信が一定時間たつと遮断される

#3 2012-04-09 08:00:38

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ksaitoさん による投稿:

#4 2012-04-09 13:08:56

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ksaito による投稿:

コード:

#5 2012-04-09 13:17:31

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ryさん による投稿:

ksaitoさん による投稿:

#6 2012-04-10 08:22:05

Re: 特定のクライアントとの通信が一定時間たつと遮断される

zagan による投稿:

#7 2012-04-10 22:26:45

Re: 特定のクライアントとの通信が一定時間たつと遮断される

コード:

#8 2012-04-10 22:29:06

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ry による投稿:

ksaitoさん による投稿:

#9 2012-04-11 00:04:25

Re: 特定のクライアントとの通信が一定時間たつと遮断される

コード:

コード:

#10 2012-04-11 00:11:17

Re: 特定のクライアントとの通信が一定時間たつと遮断される

コード:

#11 2012-04-11 00:43:28

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ksaito による投稿:

コード:

コード:

コード:

#12 2012-04-11 07:29:13

Re: 特定のクライアントとの通信が一定時間たつと遮断される

hmatsue による投稿:

#13 2012-04-11 07:46:11

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ksaitoさん による投稿:

#14 2012-04-11 13:15:10

Re: 特定のクライアントとの通信が一定時間たつと遮断される

#15 2012-04-11 22:15:58

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ry による投稿:

#16 2012-04-11 23:11:01

Re: 特定のクライアントとの通信が一定時間たつと遮断される

hmatsue による投稿:

hmatsue による投稿:

hmatsue による投稿:

hmatsue による投稿:

コード:

コード:

コード:

#17 2012-04-12 13:15:38

Re: 特定のクライアントとの通信が一定時間たつと遮断される

#18 2012-04-14 21:05:08

Re: 特定のクライアントとの通信が一定時間たつと遮断される

hmatsueさん による投稿:

コード:

hmatsueさん による投稿:

コード:

#19 2012-04-14 22:24:45

Re: 特定のクライアントとの通信が一定時間たつと遮断される

ksaito による投稿:

コード:

ksaito による投稿:

コード:

#20 2012-04-15 07:51:55

Re: 特定のクライアントとの通信が一定時間たつと遮断される

hmatsueさん による投稿:

ksaitoさん (#16) による投稿:

コード:

#21 2012-04-15 12:17:26

ksaitoさんによる投稿:

ryさんによる投稿:

ksaitoさんによる投稿:

ksaitoさんによる投稿:

ksaitoさんによる投稿:

hmatsueさんによる投稿:

hmatsueさんによる投稿:

hmatsueさんによる投稿: