- PR -

interfaceの設定について

«前のページへ 1|2
投稿者投稿内容
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2008-01-11 07:22
おはようございます。
申し訳ありません。問題点を少し勘違いしていました。
先のコメントでの私の「想像」は無視してくださるようお願いします。

で、問題は、F/A氏のコメントの通り、「同一セグメントのIPを別々のNICに割り当てる」でしょう。

ルーティングの設定によって回避することは可能と言えば可能です。
ここで気にすべき点は、戻りのパケットが何処から出るか、です。
今回、eth0 を先にリンクアップした場合、XXX.XXX.XXX.10, XXX.XXX.XXX.20 いずれに来た ping の応答も、eth0 から出るように自動的にルーティングが設定されると考えられます。
なので、戻りのパケットのソースIPに応じてパケット送出元のNICを変えるように、つまり XXX.XXX.XXX.20 をソースIPとするパケットが eth1 から出るようにルーティングを設定することで回避できます。
これは、Linux の iproute2 の持つ機能 ( Advanced Routing ) により実現できます。
※戻りパケットが何処から出るかは、「どのNIC宛てに来た通信に関連しているか」とは直接の関係が無い事に注意。eth1 に来たパケットに対する応答等が eth1 から出ると決まっている訳ではない。

ただし、わざわざこのような設定を行うよりは、次の方法をお勧めします。

　・同一セグメントのアドレスは、全て同じNICに割り当てる ( IPエイリアス )
　・もし複数NIC使いたい場合は、bonding により、仮想的に1つのI/Fとして束ねる。これには冗長性が確保できるというメリットがあります。
　　※今回の例であれば、eth0, eth1 を束ねて bondX ( bond0 等 ) を作り、bondX に XXX.XXX.XXX.10,20 を割り当てる。
blunder
ベテラン
会議室デビュー日: 2003/09/11
投稿数: 65
投稿日時: 2008-01-11 11:25
単純な問題のような気もするんですけどね。

eth0/eth1の両方をupしたときにnetstat -nrすると

コード:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1


とか

コード:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0


のようになっていませんか？

/sbin/ifupや/sbin/ifdownでは自動的にルートがadd/deleteされませんか？

しかしケーブルを抜いたときなんかには、自動的にはルートがdeleteされずに両方のルート
が残っていませんか？それだとまずいですよね。無効なルートが使われてしまうケースだと
pingできないでしょう。

その場合はrouteコマンドなんかで、手で無効なルートをdeleteすれば、うまく行くんじゃ
ないですか？

忙しいので、あまり深く考えないで書いてます（すいません）。念のために言っているだけで、
外れているかもしれません。
BackDoor
ぬし
会議室デビュー日: 2006/02/20
投稿数: 831
投稿日時: 2008-01-11 12:05
割り込み失礼。

引用:
beerさんの書き込み (2008-01-10 11:35) より:

現在、Linux（redhat）OSにてサーバ構築をし、インターフェースの設定を
しているところなのですが、不思議な現象が発生し困っています。

LinuxOSの場合、上記のような設定を行うことが可能なのでしょうか？
今回は、解除しなければいけないため、解除方法等ご教授お願い致します。

そもそも同一セグメントに複数NICを接続する目的は何でしょうか？

フォールトトレラントを意識したチーミングを行いたいのでしたら
こちらのサイトを参考にされると宜しいでしょう。
ゆうじゅん
ぬし
会議室デビュー日: 2004/01/16
投稿数: 347
投稿日時: 2008-01-11 15:49
すみません。便乗質問ですが、戻りのインターフェイスがeth0に固定されていたとして

・eth0のケーブルを抜きeth1のアドレスに対してpingをたたいたところ
　pingが返ってこない状態

これは、戻りのパケットが飛ばないので、pingが返ってこないのはわかるのですが


・eth1のケーブルを抜き、eth1のアドレスに対しpingを実行したところ、
　pingが返ってくる状態

これは、eth1のケーブルが抜けているので、pingの要求パケットを受け取れないと
思うのですが、違うIPアドレスが振られているeth0経由で、eth1宛てのパケットを
受信できるのでしょうか
blunder
ベテラン
会議室デビュー日: 2003/09/11
投稿数: 65
投稿日時: 2008-01-11 16:49
引用:

・eth1のケーブルを抜き、eth1のアドレスに対しpingを実行したところ、
　pingが返ってくる状態

これは、eth1のケーブルが抜けているので、pingの要求パケットを受け取れないと
思うのですが、違うIPアドレスが振られているeth0経由で、eth1宛てのパケットを
受信できるのでしょうか


おっしゃる意味分かります。ごもっともな疑問だと思うのですが、実際はeth1のケーブル
を抜いた状態でも、IPアドレス(eth1)宛てのpingはちゃんと返ってきます。手元のRedHat
Linux(RHEL4)ではそうなりますね。

何だか不思議ですが、まず普通のケースとして、eth1のケーブルがささった状態だと、
IPアドレス(eth1)に対するARP要求に対してMACアドレス(eth1)が返ってきます。これは
当然ですね。

ところがeth1のケーブルを抜いた状態では、IPアドレス(eth1)に対するARP要求に対
してMACアドレス(eth0)が返ってきます。

ですのでIPアドレス(eth1)宛てのpingは、MACアドレス(eth0)宛てに送られ、ケーブル
が抜けた状態でも、eth0側で受け取られます。

ちなみに試した環境は
eth0 192.168.1.61/24
eth1 192.168.1.65/24
です。eth1のケーブルを抜いた状態のときも、ifconfigで見たときのステータスはUP
です。

ですので
コード:

$ sudo mii-tool

eth0: negotiated 100baseTx-FD flow-control, link ok

eth1: no link



$ ifconfig -a

eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  

          inet addr:192.168.1.61  Bcast:192.168.1.255  Mask:255.255.255.0

          .....

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          .....

eth1      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  

          inet addr:192.168.1.65  Bcast:192.168.1.255  Mask:255.255.255.0

          .....

          UP BROADCAST MULTICAST  MTU:1500  Metric:1



$ netstat -nr

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

.....

コード:

$ sudo tcpdump -n -i eth0 icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:20:07.341726 IP 192.168.1.170 > 192.168.1.61: icmp 64: echo request seq 1

16:20:07.341800 IP 192.168.1.61 > 192.168.1.170: icmp 64: echo reply seq 1

16:20:08.340983 IP 192.168.1.170 > 192.168.1.61: icmp 64: echo request seq 2

16:20:08.341021 IP 192.168.1.61 > 192.168.1.170: icmp 64: echo reply seq 2

16:20:12.723027 IP 192.168.1.170 > 192.168.1.65: icmp 64: echo request seq 1

16:20:12.723093 IP 192.168.1.65 > 192.168.1.170: icmp 64: echo reply seq 1

16:20:13.722287 IP 192.168.1.170 > 192.168.1.65: icmp 64: echo request seq 2

16:20:13.722328 IP 192.168.1.65 > 192.168.1.170: icmp 64: echo reply seq 2

16:20:14.721918 IP 192.168.1.170 > 192.168.1.65: icmp 64: echo request seq 3

16:20:14.721963 IP 192.168.1.65 > 192.168.1.170: icmp 64: echo reply seq 3

.....

のような状態です。

なぜこうなるかの理由は分かりません。これだけじゃ分かりにくいと思いますが、時間が
ないのでとりあえずこれで失礼します。

あと、2個のNICに同一IPネットワーク番号を割り当てるのが適切かどうかですが、私も
その方法は別に推奨はしていません。
ただNIC failoverをするときなどには、そういうことはするとは思うので、ケースバイ
ケースのような気はしなくもありませんが。


[ メッセージ編集済み 編集者: blunder 編集日時 2008-01-11 16:56 ]

[ メッセージ編集済み 編集者: blunder 編集日時 2008-01-11 17:01 ]

[ メッセージ編集済み 編集者: blunder 編集日時 2008-01-11 17:03 ]
blunder
ベテラン
会議室デビュー日: 2003/09/11
投稿数: 65
投稿日時: 2008-01-11 20:07
先の件ですが、理由が分かりました。

LinuxのARPの仕様によるもののようです。arp_ignoreでググればいろいろ出てきますが、
例えば下記URLなどが分かりやすいです。
http://www.valinux.co.jp/contents/tech/techlib/eos/linux_arp/linux_arp.html

というわけで、eth1側のケーブルが抜けている場合
net.ipv4.conf.eth0.arp_ignore=1
を設定すると、IPアドレス(eth1)に対するpingは応答しなくなりました。

次に
net.ipv4.conf.eth0.arp_ignore=0
を設定すると、pingに応答するようになりました。これがデフォルトの挙動ですね。

では。
ゆうじゅん
ぬし
会議室デビュー日: 2004/01/16
投稿数: 347
投稿日時: 2008-01-15 16:40
>blunderさん

わかりやすい説明ありがとうございます。
勉強になりました。

やはり、ネットワークは一筋縄ではいかないですね
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）