 |
≫ |
|
|
|
| HUBの Linkランプが点灯し続けるが？ |
|
|
| |
サーバ本体の電源を落としても ACケーブルが接続されていれば Ethernetコントローラが
WOL(wakeup-on LAN)機能を搭載している場合、Ethernet HUBの Link LEDは点灯し続けます。 |
|
| 25-MAY-00 |
| チーミング切替えが遅いが？ |
|
|
| |
チーミングドライバに bondingを利用、Ethernet I/Fを 3本利用、且つ集線先が switching HUB/bridgeの場合、クライアントから見た場合の切り替え時間が数十秒掛かる場合があります。下記の例の様にオプションを付与することで bridgeが保持する MAC addressをクリアさせ再接続時間の短縮化が可能です。
|
#vi /etc/modules.conf
alias bond0 bonding
options bond0 miimon=100 mode=1 arp_interval=1000 arp_ip_target=192.168.1.73
⇒ 共に単位は ms |
HUB/repeaterを利用する場合、もしくは baspドライバを利用する場合、本現象は発生しません。
[30-MAY-03] bonding v1.0.2-6HPでは miimonと arp_intervalが同時に利用できなくなったため、この方法は利用できなくなりました。HUB/bridge側の table expiration等のタイミング調整を行ってください。 |
|
| revised 30-MAY-03 |
| ビルドに失敗するが？ |
|
|
| |
Red Hat, Miracleの場合、#make oldconfig, #make depを行っただけの状態だと、kernel環境と NICドライバの組み合わせによっては正常にビルドできない場合があります。この場合、KERNELRELEASEを指定してください。
|
cd /usr/src/linux-2.4
#make mrproper
#make -e KERNELRELEASE=`uname -r` oldconfig
#make -e KERNELRELEASE=`uname -r` dep |
|
|
| 24-JUN-03 |
| チーミング時 gatewayが設定されないが？ |
|
|
| |
bondingが MAC addressの設定に失敗しているために発生しています。/etc/sysconfig/network-scripts/ifcfg-bond0に
'MACADDR'として直接 eth0のものを指定することで回避できます。
|
DEVICE=bond0
USERCTL=no
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.10
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
GATEWAY=192.168.1.254
MACADDR=xx:xx:xx:xx:xx:xx |
技術的には、ifenslaveが master deviceへ slave deviceを attachする時、master deviceの MAC addressを見て
"00:00:00:00:00:00"(ifcfg-bind0へMACADDRを指定していない場合)であれば、一度、master deviceを
downさせ、slave deviceから MAC addressを取得したあと、master deviceを upさせます。
master deviceが downすると、ルーティングテーブルが flushされ、ifup bond0で設定された default gatewayが消えてしまいます。その後、ifup
ethX(ifenslave bond0 ethX)で slave deviceが upされても default gatewayを設定する処理が skipされる(これは
ifupスクリプトの仕様)ため、結果的に default gatewayが消えているということになります。
従って、回避方法としては MACADDRを設定するか、最後に default gatewayを設定するスクリプトを作成する方法を取る必要があります。
なお、この現象は bonding driver moduleが kernelへ 最初にロードされた時にのみ発生します。いったん ifenslaveで master
deviceへ slave deviceの MAC addressが設定されてしまうと、kernel内の NIC情報として設定された MAC addressを保持してしまう(ifcfg-bond0でMACADDRが設定されている状態になる)ため、bonding
driver moduleをリロードするまで現象は発生しません。詳細は、 Ethernetについての技術情報をご覧ください。
この問題は、利用する NIC driverの種類に関係なく bondingの v1.0.4m-1迄の全てのバージョンで発生することを確認しています。但し、bonding
v1.0.4o-1では、bondingドライバ自体の機能修正により、default gatewayが設定される様になりました。
|
|
| revised 22-NOV-04 |
| バッククォートが打てないが？ |
|
|
| |
昨今の Red Hat等で Ethernetモジュールをビルドする際に必要な作業、#make -e KERNELRELEASE=`uname -r` oldconfig(もしくは dep)の `の入力を間違っても oldconfigや depは通ってしまいます(もちろん NICモジュールの buildは失敗します)。
ここでの `はクォートではなく、バッククォートです。日本語キーボードの場合、[Shift]+[@]で入力できます。インストール時やリカバリー時で、キーマップが合致していない等の状況で入力が困難な場合には、`uname -r`の部分には #uname -rで表示される値をそのまま入力してください。これは、Ethernetのモジュールがビルドに失敗するものの内で、一番陥りやすいミスです。 |
|
| 20-AUG-03 |
| bondingで primaryオプションを指定するとシステムが起動しなくなるが？ |
|
|
| |
bonding v1.0.3-3と bcm5700 v6.0.2dの組み合わせにおいて primaryオプションを指定した場合にシステムが起動できなくなる可能性があります。bonding v1.0.3-12HPと bcm5700 v6.2.11a以降をお使いください。 |
|
| 07-NOV-03 |
| bondingの各モードの特徴は？ |
|
|
| |
| round-robin: |
|
送信に関してはslave deviceの中で有効なデバイスの中の１つから送信されます。
受信に関しては負荷分散が行われます。 |
| active-backup: |
|
slave deviceの中から１つだけが有効になります。
一般的にこのモードは２つのハブを使いhigh availabilityを実現するときに使用されます。 |
| balance-xor: |
|
転送先のMACアドレスに対して一定のslave deviceが割り当てられます。 |
| broadcast: |
|
すべてのslave device上で転送を行います。 |
|
|
| 11-NOV-03 |
| bondingで NIC障害後も ＭＡＣアドレスを同じにしたいが？ |
|
|
| |
/etc/sysconfig/network-script/ifcfg-bond0のファイルの中で下記の様に staticに MACアドレスを指定してください。
|
MACADDR=00:11:22:33:44:55 |
|
|
| 28-NOV-03 revised 11-OCT-07 |
| bondingの active-backupモードで障害発生時の動作は？ |
|
|
| |
active-backupモードで運用中に activeの NICに障害が発生すると backupの slave deviceが activeになりますが、障害が復旧してもモードは切り替わりません。すなわち、最初 backupだった salve deviceが activeのまま運用が続きます。
但し、 primaryオプションを指定されている場合には primaryオプションが指定された slave deviceが復旧した時にその slave deviceが activeとなります。 |
|
| 01-DEC-03 |
| bonding利用時にNICモジュールのロード順序が入れ替わってしまうが？ |
|
|
| |
master deviceが複数の異なるNICのslave deviceで構成されている時、NICモジュールのロード順序が入れ替わってしまう場合があります。これは、インターフェイスを適切な順序でアップ(およびenslave)することで回避可能です。詳細は異なる複数のNICドライバでbondingドライバを利用する例をご覧ください。 |
|
| 11-MAY-04 |
| initscriptsのバージョンによってネットワークの動きが異なるが？ |
|
|
| |
ネットワーク環境は initscriptsの機能に大きく影響を受けます。initscriptsのバージョン
によっては bonding利用時に gatewayを設定するには MACADDRを指定する必要があったり、ifupスクリプトが再起的にコールされる事が原因で
bondingの slave deviceへ IPが設定されない等の問題が発生します。これらの問題は一見 bondingドライバの問題に見えます。
HPでは適時 NICドライバと付随する他のドライバを組み合わせた問題をレポートしていきます。詳細は、Ethernetについての技術情報をご覧ください。 |
|
| revised 22-NOV-04 |
| bondingの設定が反映されないが？ |
|
|
| |
bonding driverのオプション(/etc/modules.conf)を変更した場合、単にネットワークを再起動(/etc/init.d/network restart等)しただけではロードされているbonding driverに設定が反映されず、以前の設定のままでbonding driverが動作し続けます。このような事態を防止するため、/etc/modules.confを変更したら、必ずrebootするか、bonding driverと下位 driver一式をアンロード(#/etc/init.d/network stop;rmmod bonding;rmmod bcm5700(もしくは e100/e1000); /etc/init.d/network start)して最新の設定を反映させてください。 |
|
| 01-SEP-04 |
| NICの割当てを固定したいが？ |
|
|
| |
/etc/mactabでの指定、ifcfg-ethxでの HWADDR指定、#nameifでの指定等を行う事で、特定の NICを
eth0等へ固定する方法があります。但し、これらの方法を利用した場合、ネットワーク環境への影響が及ぶ場合がありますので利用される場合には慎重に動作確認を行う必要があります。特に、複数の
NICドライバを利用する環境で bondingを利用する場合には、インターフェースの消失等の影響が発生します。ちなみに /etc/mactabで記述しただけでは
Red Hat EL2.1, EL3(initscriptが更新されている U3でも)等では実際に配置を固定する事はできません。
[22-AUG-07] 昨今の状況として、SLES10等では積極的に MAC addressを利用したデバイスの固定化を行っているディストリもあります。また、bonding等でのインターフェースの消失は昨今発生しなくなっています。 |
|
| 08-DEC-04, revised 22-AUG-07 |
| e1000と bondingを組み合わせると
linkが up/downを繰り返すが？ |
|
|
| |
/var/log/messagesには下記のメッセージが交互に繰り返して記録される事があります。このメッセージが対になって連続で現れる場合、実際には linkは消失せずにメッセージが誤って表示されているだけですので無視してください。
|
kernel: bonding: bond0:
link status definitely down for interface eth0, disabling it
kernel: bonding: bond0: link status definitely up for interface eth0 |
この問題は e1000と bondingの MII監視モードを組み合わせた状況で、下記の動作のどちらかがあった場合に発生します。
- ethtoolのような ioctl()を発行するアプリケーションが e1000 driverから情報を取得する
- /proc/net/devを連続で readする
この問題は将来の e1000ドライバで解決される予定です。現時点では bondingを MII監視モードではなく arp監視モードにする事で防げます。
また bondingの use_carrierオプションを '1'にする事でも回避が可能ですが、hpが提供する bondingに於いては(現時点で v1.0.4t)この機能は装備されていません。ディストリビューションに標準搭載されている
bondingを利用される場合にのみこの方法での回避が有効です。
[11-OCT-05] この問題は e1000 v6.1.10b-1にて解決しています。 |
|
| 07-JUN-05, revised 13-DEC-05 |
| サーバー直結のARP監視 bonding interface(active-backup)は必ず
degradeになるが？ |
|
|
| |
active-backupモードで動作する bonding interfaceを図のようにサーバー直結(クロスケーブルで接続)で構成した場合、ARP監視モードでは、link
upする slave interafceは必ず1つだけになる(他の slave interfaceは必ず link down)ので、Insight Management
Agentでの bonding interface statusは必ず"劣化(degrade)" になってしまいます。但し、MII監視モードでは、全ての
slave interfaceが link upするので "劣化(degrade)" になりません。
ARP監視モードでの link up/downは slave interfaceの"最後のpacket受信時刻"で判定します。ARP監視
active-backupモードでは、active slave interfaceが送信する arp request packetを slave interfaceが受信することで
link upとみなします。サーバー直結の場合、active interfaceが送信した arp request packetが相手側の1つの slave
interafceにしか届かないため、残りの slave interface が全て link downになってしまいます。なお、switchに全ての slave
interafceが接続されている場合、switchが arp request packetを activeな全 portへ broadcastするため問題ありません。
基本的に active-backupモードは slave interfaceを switching HUBに接続する構成をお勧めしますが、サーバー直結で使う場合は、bonding
interfaceを MII監視モードにするか、active-backupモードではなく round-robinモードで構成してください。 |
|
| 05-JUL-05 |
| EL3で
bonding, vlanドライバはどれを使えばいいのか？ |
|
|
| |
HPは EL3上で bonding, vlanドライバを安定利用させるために、これらのドライバを提供してきましたが、最近のドライバ安定状況を鑑みて PSP7.51以降では kernel 2.4.21-37.0.1以降の環境に於いては、導入しない形態に変更しました。また、kernel環境に関係なく
bondingと vlanドライバを併用する場合には EL3標準搭載のドライバを利用する必要が生じます。詳細はbondingドライバとvlanドライバの構成例をご覧ください。
|
|
| 30-AUG-06 |
| 起動ログで ethXの link upが遅いがハードウェアの問題か？ |
|
|
| |
これはハードウェアの問題ではなく、Linuxの仕様になります。/var/log/messagesに記録される
Bringin...表示から Link is Upまで 30秒程度の差が出る場合がありますが、これは processや kernelからの logに記録される迄の時間差によるもので、実際には
30秒よりも早い段階(数秒程度)で link upしています。Bringing...メッセージは、/etc/rc.d/init.d/networkから直接
syslogdに渡されますが、kernel landから発行される NICドライバからのメッセージは一旦 ring bufferに入り、klogdが syslogdに引き渡した後
/var/log/messagesに記録され、記録される時刻は実際にイベントが発生した時刻ではなく、syslogdが klogdから受け取ったものとなります。このため、システムの起動等の様に多重の処理が行われている場合、ログ上での時刻の遅延が見られる事になります。試しに
klogdのサービスを停止した状態でシステムを起動し、起動が終わってから klogdを起動すると /var/log/messages上に記録される kernel
landからのメッセージは全て klogdを手動起動した時刻になる事が分かります。 |
|
| 19-MAR-07 |
| NICポートが逆転しているが？ |
|
|
| |
Ethernetの NICポートが逆転する原因としては、firmware側での MAC addressの配置と ACPI table上での配置の違い、x86 kernelと x86_64 kernelでの違い(RHEL3)、kernelのスキャン方法自体のアルゴリズム変更(RHEL4/U5)、インストーラの問題(beta版インストーラ等で eth0が eth12になったり)等と、多岐に渡りますので、このシステムではこの配置になる…等、予め NICポートがどこに割り当てられるかを特定するのはかなり困難です。
このためインストール後にどの NIC portが eth0にアサインされるのかは実際の環境で試さなければならない事になります。これを避けるには /etc/sysconfig/network-scripts/ifcfg-eth0等で HWADDR=として直接インターフェースの固定化を行うのが有効です。 |
|
| 22-AUG-07 |
| NAPIとは？ |
|
|
| |
ネットワークの処理速度向上のための仕組みで New APIから NAPIと呼ばれます。Ethernetの速度向上に伴い、割り込み処理を行うためのシステム負荷が非常に高くなってきています。従来システムはネットワーク関連の処理は NIC側からのハードウェア割り込みを受けて、都度優先的に処理を行ってきました。例えば 10Gigabit Ethernet用ドライバが 1500byteのパケット毎に割り込みを発生させる場合、一秒間の割り込み回数は 80万回を超える事となり、この処理だけで CPUは殆どの時間を費やしてしまう事になります。これを改善するために割り込み処理が高い状況においては 10ms程度の割り込みを停止し、後から CPU側から NIC上の DMA ring buffer上のパケットをまとめて取りにいきます。 |
|
| 16-JAN-08 |
| DHCPで IPが取れない場合があるが？ |
|
|
| |
DHCPを利用している場合、システム起動時に IPの取得に失敗する場合があります。この現象を防ぐには /etc/sysconfig/network-scripts/ifcfg-eth0の最後に下記のどちらかを追加し、link downしていると認識させない事で防げます。但し、LINKDELAY patch(それも本問題に関する)の適用が行われているのを確認できたのは RHEL5.0以降だけです。RHEL4.6等の patch未適用のディストリビューションでは、check_link_downの方法を利用してください。 ちなみに、LINKDELAY=で指定する値の単位は、秒になります。この値は適時調整してください。
|
check_link_down ( ) {
return 1;
} |
|
LINKDELAY=30 |
この現象は NICの初期化スクリプトに起因する問題で、ProLiantや特定のディストリビューションに特化したものではなく広く発生する可能性があります。 |
|
| 27-MAR-08, revised 02-MAY-08 |
| ethtoolで速度が Unknownになるが？ |
|
|
| |
ethtoolが version 6未満の場合、#ethtoll eth0等で表示される速度表示は 1Gbpsを超える速度は表示に Unknownが付与されます。また、3.4Gbps等の様な c-Classの Flex10による速度分割をした速度の場合にも `Speed: Unknown! (3400)`と云う表示となります。 |
|
| 01-DEC-08 |
| Virtual Connectだと bondingが切り替わらないが？ |
|
|
| |
c-Classブレード用 Virtual Connectと e1000(本バージョンのみに限りません)ドライバを組み合わせた構成の場合、NICの link up/downが正常検知できないため、bondingが正常に切り替わりません。この問題は bondingの mode=6を利用しても回避できません。現状に於いては Broadcom系 NICを利用してください。状況が変わりましたら、本サイトの What's Newで案内させて頂きます。 |
|
| 10-DEC-08 |
|
印刷用画面へ
