- PR -

【CentOS5】BondingでのARPチェックについて

1
投稿者投稿内容
juggly
会議室デビュー日: 2006/08/09
投稿数: 11
お住まい・勤務地: 都内
投稿日時: 2007-09-11 16:41
現在、CentOS5で2枚のNICでBondingを構成しています。
上位スイッチ−ルータでのリンクダウンを検出して切り替わるように、モジュールパラメータにarp_intervalとarp_ip_targetを/etc/modprobe.confに追加して構成してActive-Backupで動作させています。

現象は、以下の構成でスイッチA−ルータ間の線を切ってもサーバ側ではリンクアップのままとってしまいます。スイッチB経由での通信に切り替わりません。
具体的には、/proc/net/bonding/bond0の「Currently Active Slave:」がeth1に変わってくれないといけないはずなんですが、変わらずeth0のままとなってしまいます。
MIIリンクはupのままです。また、同じセグメントのマシンからサーバに対してpingを打っても通りません。

しかし、予期せぬことなんですが、
/etc/modprobe.confでprimary=eth1として、スイッチB経由のアクセスからテストを行って見ると、今度はeth0に切り替わり、スイッチA経由でアクセスが可能となってしまいました。
eth0→eth1の切り替えはNGで、eth1→eth0の切り替えはOKといった理解しがたい動作をしています。
ハードウェアを変更して同様のテストをやって見ましたが、現象は変わりません。ハードウェアの問題ではなさそうです。
また、<サーバ>−<スイッチA>を切断しての切り替えは正常に動作しています。
(スイッチB経由のアクセスに切り替ります)

この現象は何が原因となっているのでしょうか?
以下の出力から、設定自体に問題はないと思っています。今のところソフトウェアのバグではないかとにらんでいます。

■カーネル
2.6.18-8.1.8.el5 64bit

■NIC
Broadcom Corporation NetXtreme II BCM5706S ×2

■構成図は以下のとおりです。
     <ルータ>
     |   |  ←このラインを切ってテストしています。
<スイッチA>  <スイッチB>
     |   |
    < サーバ >

# cat ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
IPADDR=192.168.1.2
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
USERCTL=no
TYPE=Ethernet
GATEWAY=192.168.1.1

# cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=no
MASTER=bond0
SLAVE=yes
USERCTL=no
TYPE=Ethernet
HWADDR=00:1c:c4:11:74:b2

# cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=no
MASTER=bond0
SLAVE=yes
USERCTL=no
TYPE=Ethernet
HWADDR=00:1c:c4:11:74:70

# cat /etc/modprobe.conf
alias eth0 bnx2
alias eth1 bnx2
alias scsi_hostadapter cciss
alias scsi_hostadapter1 usb-storage
alias bond0 bonding
options bond0 mode=1 arp_interval=2000 arp_ip_target=192.168.1.1 primary=eth0

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.0.3 (March 23, 2006)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth0
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 2000
ARP IP target/s (n.n.n.n form): 192.168.1.1

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1c:c4:11:74:b2

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1c:c4:11:74:70

# ifconfig
bond0 Link encap:Ethernet HWaddr 00:1C:C4:11:74:B2
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21c:c4ff:fe11:74b2/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:4226 errors:0 dropped:0 overruns:0 frame:0
TX packets:730 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:310292 (303.0 KiB) TX bytes:61088 (59.6 KiB)

eth0 Link encap:Ethernet HWaddr 00:1C:C4:11:74:B2
inet6 addr: fe80::21c:c4ff:fe11:74b2/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:2278 errors:0 dropped:0 overruns:0 frame:0
TX packets:724 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:170120 (166.1 KiB) TX bytes:60596 (59.1 KiB)
Interrupt:82 Memory:fa000000-fa011100

eth1 Link encap:Ethernet HWaddr 00:1C:C4:11:74:B2
inet6 addr: fe80::21c:c4ff:fe11:74b2/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1948 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:140172 (136.8 KiB) TX bytes:492 (492.0 b)
Interrupt:90 Memory:f8000000-f8011100

といった設定内容で、/proc以下のステータスとifconfigの出力から、設定自体に問題はないと思っています。

以上、宜しくお願い致します。
未記入
常連さん
会議室デビュー日: 2006/04/11
投稿数: 21
投稿日時: 2007-09-13 16:41
BondingのARP監視は、Arp要求の返信が帰ってくるとUPステータスと判断するのではなく、
何らかのパケットを受信することができればUPステータスだと判断します。
その為、同じネットワーク内にブロードキャストを送信するような機器が存在し、パケットを受信できた場合
ネットワークのダウンを検知することはできません。
また、スイッチにProx ARP機能が実装されている場合も同様にスイッチ以降の断線を検知することができません。

状況を確認するため
     <ルータ>
     |   |  ←このラインを切ってテストしています。
<スイッチA>  <スイッチB>
     |   |
    < サーバ >
の確認ではなく。

     <ルータ>
     |   |
<スイッチA>  <スイッチB>
     |   |  ←このラインを切ってテストを実施してみてください。
    <サーバ>

のネットワーク構成にて確認してみてください。
============================================
追記
すいません、もう検証されているということでしたね。
やはり、<スイッチA>-<サーバ>の断線の検知は可能ということであれば、
断線後も、何らかのパケットを受信している可能性が非常に高いです。

watch -n 1 ifconfig 等で断線側のデバイスで受信パケットが増加していないか確認を行ってみてください。


[ メッセージ編集済み 編集者: 未記入 編集日時 2007-09-13 17:18 ]
BackDoor
ぬし
会議室デビュー日: 2006/02/20
投稿数: 831
投稿日時: 2007-09-13 17:49
net上でちょっと調べただけで、未確認ですが・・・。
一部設定変更して再度確認して下さい。(引用太字部分)

引用:
jugglyさんの書き込み (2007-09-11 16:41) より:

# cat ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
IPADDR=192.168.1.2
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
USERCTL=no
TYPE=Ethernet
GATEWAY=192.168.1.1
options bond0 mode=0
options bond0 miimon=100


# cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
TYPE=Ethernet
HWADDR=00:1c:c4:11:74:b2

# cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
TYPE=Ethernet
HWADDR=00:1c:c4:11:74:70


参照したサイトはこちら
1

スキルアップ/キャリアアップ(JOB@IT)