- - PR -
冗長化サーバ接続のSwicthの設定
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-12-09 13:32
おはようございます。
>こうさん 対応、大変ですね。お察しします。 ご参考になりそうもありませんが、幾つか確認をば。
これは、すごく不思議です。 アドレスの異なる複数の Windows サーバ達が、 皆一様に「IP 重複エラー」を返しているのですか?? アドレスの異なるサーバ達が、皆、アドレス重複エラーを表示しているのですか??? 「一台だけと重複している」なら分かる気もするのですが、 「アドレスの異なる、全てのサーバとアドレス重複」ですか??
片側の NIC からケーブルを抜き、Teaming のメンバーが不在 (自分しかいない) 状況を作れば、 上記の動作をしているのかどうか、切り分けられないでしょうか? 「SW 側にキャプチャーを」とのことですので、 もちろん、キャプチャーしたデータからも判断できると思います。
「通信が上手くできない」とは、どのような症状でしょうか?全断でしょうか?? パケットをキャプチャして、往復それぞれどこまでパケットが到達 | 不到達なのか、 切り分けられないでしょうか?
ALB の考え方は正しいと思います。 そもそもセカンダリ側の NIC から送信されたフレームの 送信元 MAC アドレスは「セカンダリ NIC の MAC アドレス」になるのでしょうか?? こういった動作もキャプチャーしたパケットから分かるかも知れませんね Backdoor さんと同じく、ぜひぜひ自分も顛末が知りたいです。 (私も勉強します) ではでは、うえだ@すもものお酒、でした。 | ||||||||||||||||
|
投稿日時: 2006-12-11 15:36
うえださん、皆様
今回、初めてこのIT会議室を使用させて頂きましたが、返信を頂いて 嬉しいです。 (電車男風に「おまいら、ありがとう!」) 1.「通信にも影響が出ていた」件について サーバNICとSWのduplexが合っていなかった事による事が 先週の打合せで判明しました。設定を合わせた後は安定しているそうです。 ALBの動きも正常とのことです。 (NW構築後に固定Fullの設定をしている事を伝えており、 もし、サーバ側で固定設定が出来ない場合は連絡を貰う事に していたのですが、連絡なしの状態でした。) 2.「IP重複メッセージ」について 再び、純粋にこの問題のみとなりました。 「IP重複メッシージ」は各サーバがそれぞれのALB仮想IPに対して メッセージを出しています。サーバのLOGではプライマリポートでのメッセージだそうです。 サーバの1本のケーブルを抜いた切り分けは先週行ないました。 →結果は「IP重複メッセージ」は出ませんでした。やはりプライマリとセカンダリの ポート(MAC)の関係のようです。 >そもそもセカンダリ側の NIC から送信されたフレームの >送信元 MAC アドレスは「セカンダリ NIC の MAC アドレス」になるのでしょうか?? →先日キャプチャを仕掛けた時に確認したのですが、やはりそれぞれの プライマリとセカンダリのNICのMACアドレスでフレームを送信していました。 キャプチャは私は使い方も分からない古いSnifferで仕掛ける時にSnifferで duplicate_Addressは頻繁に検知していました。 ただ、サーバ側では1日に1回位で、かつ決まった時間ではないのです(朝や夕方)。 Snifferで見られたように頻繁にIP重複が発生するのは当然として、ALBの動きが それを上手く処理している。 と想像していいのですかね。 ただ、サーバ側で1日に1回くらいメッセージがなぜ出るのか? 累積したカウンター値が閾値を越えてメッセージを出すのか? それともアプリレベルで特別な通信確認を行なっているのか? webで調べたのですが、windows系のOSはIPアドレスの変更等を行なった時に 自分が接続するNW内にに設定されたIPのArp要求をブロードキャストし、他の端末が 先にそのIPを使っていないか確認し、IPが使われていたらIP重複のエラーを表示する そうですね。 似たような確認をサーバが不定期にしている?もしくは他のアプリケーション通信の一部として そのようなことをする? プローブパケットについても疑って見たいと思います。 どのようなパケットなのでしょう?調べてみます。 また、 明日、キャプチャーデータの回収する予定です。 長文になりすみません。 | ||||||||||||||||
|
投稿日時: 2006-12-11 16:17
お忙しい中、中間報告頂きありがとうございました。
つっこみではありませんが、L3SWをL2SWに変更した訳ではないのでしょうか? → Catalyst3550をL2SWモードで動作させる試みはこれからでしょうか?
これは本当に不思議です。 しつこいですが、いまだにセットアップ手順に誤りがないのか疑っています。 # こちらが出なくなれば、接続先の機器をL2SWにすれば解決と思うのですが。 結果報告お待ちしています。頑張って下さい。 | ||||||||||||||||
|
投稿日時: 2006-12-11 22:46
こんばんは&お疲れ様です。
Backdoor 先生なら「担当を変えた方が (略)」って仰るんじゃないでしょうか?(笑)
すいません、 「Sniffer で Duplicate Address が頻発」というのが、 よく理解できません。 お手数をおかけして申し訳ありませんが、 Sniffer がどういうメッセージを受信しているのか、 教えて頂けないでしょうか?ご多忙の中、本当に申し訳ないです...
これは Gratuitous ARP のことですよね? 先の返信に書いたはず、、、と思ったら、書いてないみたいですね?>私 返信を推敲しているうちに、削除してしまったようです 「ただ、サーバ側で1日に1回くらいメッセージがなぜ出るのか?」は、 私も答えが見つかりません。この、メッセージを表示する前後で、 どのようなパケットが流通しているのか、ぜひ知りたいです。 ではでは、うえだ@焼酎で軽い頭痛...でした。。。 | ||||||||||||||||
|
投稿日時: 2006-12-13 17:37
こんにちは
Windowsのハナシじゃありませんが、以下のような資料を 見つけましたので、掲載いたします。 http://osdn.jp/event/kernel2005/pdf/nec.pdf #Linuxワールドかなにかのプレゼン資料のようです。。 Linuxでも同様にbondingした場合にNW監視装置が IP重複の警告を発する場合もあるようですね。 Windowsだと回避できるといいですねぇ。。。 | ||||||||||||||||
|
投稿日時: 2006-12-15 15:10
Intel NIC のチーミングで Express Teaming (高速チーミング)
を使用すると、同じような現象となったことがあります。 | ||||||||||||||||
|
投稿日時: 2007-04-01 02:41
こんばんは。
長い間の沈黙から再び投稿させていただきます。 実はこの掲示板があまりにも有名で、WEB上のキーワード検索で ヒットしてしまうため、関係者(お客様など)にも「みえみえ」に なてしまうという懸念にかられていました。 これまでご返信頂いた方々には申し訳なく思っていました。 よく考えれば、ネットワークの技術的な話で情報漏えいなどにも ならないと思いますし、すべてはお客様や関係者の為と思ったこと、 返信頂いた方々へ報告の義務もあると思いましたので 投稿を再開させていただきます。 ---------前回の投稿以降に調査して分かったことを記します--------- 【現象】 ALBが動作するサーバでIP重複を検知する引き金となっているものは パケットキャプチャした結果、サーバから送出される「Gratuitous ARP (リクエスト)」 でした。 http://www.7key.jp/nw/tcpip/ip/garp.html ALBのプライマリポート、セカンダリポート両方からほぼ同じタイミングで 同じIPアドレス(仮想IP?)について送出していました。 「Gratuitous ARP 」はブロードキャストなので同一サーバのチームのNICに届きます。 プライマリポート → セカンダリポート セカンダリポート → プライマリポート このとき、プライマリポートからの問い合わせに対しセカンダリポートは返答しないが、 セカンダリポートからの問い合わせに対しプライマリポートが「仮想IPはプライマリポートの MACアドレスである」という返答をセカンダリポートに返答し、セカンダリポートのMACアドレス と違う為、IP重複エラーとしてサーバが検知していました。 【不可解なこと1】 検証などもいろいろ行ったのですが、実環境とは別の環境(NW構成は同じ) を作り、実際IP重複エラーを検知しているサーバを繋げても、IP重複エラーは検知 されませんでした。 キャプチャデータを確認した結果、サーバからGratuitous ARP は送出されている のですが、ALBの仮想IPについてのものではなく、「別の設定情報?」 からのものでした。 具体的にいうと、 実環境で192.168.0.0/24のNW、NICのALB仮想IPを192.168.0.1で実際エラーを 検知していたサーバを、検証環境172.16.0.0/24に接続し、サーバ側のNICの ALB仮想IPを172.16.0.1に設定してもらい確認したところ、サーバは192.168.0.1 についてのGratuitous ARPを送出しており、結果としてエラーは検知しませんでした。 (Ping試験は172.16.0.1でサーバで通信できています) ※このGratuitous ARPはNICの設定をは別のアプリやOS等の設定情報から IPを掴んでいるのでしょうか? 【不可解なこと2】 同じALBで動作しているサーバが存在し、IP重複エラーがこれまで発生して いない別のネットワークがあったので、そこでの調査も実施しました。 キャプチャデータを確認した結果、 プライマリポート → セカンダリポートのGratuitous ARPは送出しているが、 セカンダリポート → プライマリポートのGratuitous ARPは送出していない。 よって、IP重複エラー検知はされていない事が分かりました。 ※どのような設定でこの違いができるのか? このGratuitous ARPはサーバのリブートやIPアドレスの設定変更によるものでは ありません。 現在、同じネットワークで10台位のサーバがIP重複エラーを検知していますが、 発生頻度も15分おきであったり、1日に1回であったりして、また、 タイミングも一定ではありません。 ------------------------------------------------------------------- 以上が報告になります。 ネットワーク側の担当としては、これからどのような調査をすれば 良いのか、、、 サーバのGratuitous ARP送出のトリガーとなるNW的要素など何か思い当たる 経験のある方はいらっしゃいますでしょうか? やはり、サーバ側の設定の可能性があると思っています。 以前、はむさんから 「Intel NIC のチーミングで Express Teaming (高速チーミング) を使用すると、同じような現象となったことがあります。」 と返信いただいていたのですが、現象としては同じでしょうか? また、Express Teamingの設定はNICの設定でしょうか? サーバに詳しい方の意見が聞きたいです。 | ||||||||||||||||
|
投稿日時: 2007-04-02 09:31
こんにちは。
ServerのNIC DriverとNICのファームを確認された方がよろしいかと。 # IntelのDriverは(盲目的に)信用しちゃいけません |