- - PR -
冗長構成時のARP代理応答について(不具合では?)
1|2|3
次のページへ»
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2005-02-03 19:30
メーカ(導入ベンダのSE)は正常な動作だと言うのですが、実際不具合がおきている為正式な文書を確認してから再度SEへ説明、もしくは諦めるかしたいと思っています。よろしくお願いします。
2台のルータで冗長構成を組み、PCからは仮想アドレスをデフォルトゲートウェイとして設定しています。 ================================ (IP1,MAC1) (IP2,MAC2) [ルータ1] [ルータ2] | | | (仮想IP,仮想MAC) | +---------+ +---------+ | | < SW-HUB > | +---+ | (PC) ================================ この構成で、スイッチングハブがリピータハブと同じ動作をしてしまっているので、実際にパケットをキャプチャして内容を見てみると、 1. PC接続時に、(PC)がARP要求 ・・・ 仮想IPのMACアドレスは何? 2. [ルータ1](MAC1)がARP応答 ・・・ 仮想IPのMACアドレスは仮想MACだよ 3. [ルータ2](MAC2)がARP応答 ・・・ 仮想IPのMACアドレスは仮想MACだよ 4. (PC)のARPテーブルに仮想IP=仮想MACが学習される と、一見問題はなさそうに見えたのですが、 "2."のフレームの送信元MACアドレスには[ルータ1]のMAC1が、"3."の送信元には[ルータ2]のMAC2が記載されていました。 その結果、(PC)は外部ネットワークとの通信の為に、仮想IPの仮想MAC宛に多量の通信を送付しますが、中間の< SW-HUB >は、仮想MACからの通信が一切発生しない為に、一生仮想MACの接続されているポートを学習する事ができず、仮想IP宛(仮想MAC宛)の通信を全てのポートに転送してしまっている様なのです。 メーカの人に聞くと、「ARP要求に対しては誰がARP応答をしてもいい事になっているので正しい動きだ」との事でしたが、仮に代理でARP応答する場合には、送信元のMACアドレスも(この場合は)仮想MACで置き換えて配信しなければ、全てのスイッチングハブがスイッチングハブでない(リピータハブの動作をし)てしまうのでNGなのではないかと思います。 本来、この様な応答(自分のMACアドレスを送信元にしてのARPの代理応答)は本当に許されているのでしょうか。。。 もしできるなら、その定義が書かれている文書またはURLを教えて頂けないでしょうか。 よろしくお願いします。。。 |
|
投稿日時: 2005-02-04 00:24
すいません。図が崩れていてよくわからんのですが、ここら辺の話ですか?
http://www.atmarkit.co.jp/fnetwork/netcom/arp/arp.html |
|
投稿日時: 2005-02-04 09:34
おはようございます。
Proxy ARPの動作と同じです。ほろりんさんが示しているURL参照。 ただ、冗長構成をしているルータが2台ともARPに反応するのはどうかと思います。 ルータ1がActiveでルータ2がStandbyの場合、仮想IPを使って通信するのは ルータ1になります。ところがルータ2がARPに反応して、PCのARP Tableに乗ると PCはルータ2にパケットを投げてしまいます。 これでは冗長構成の意味が無いような気がします。 実際のところどうなんでしょうか。 |
|
投稿日時: 2005-02-04 13:09
冗長化の仕組みはVRRPですか、それともメーカー独自?
今回の仕様は、WindowsのNLBと同じですね。仮想IPと仮想MACが生成されて、ARP応答も同じ仕組みで、よってスイッチでフラッディングが発生します。 フラッディング対策は幾つかあるのですが、最も簡単なのはルータを一つはさむことで、これによりフラッディング範囲が冗長ルータのセグメントに限定されますが、今回はルータそのものの冗長化が目的なので、その前にルータをかますのは意味ないですかね。 その他には仮想MACをマルチキャストアドレスで定義して、それを話せるL2SWで制限するとかあるのですが、MACマルチキャストはシスコルータあたりで制限があるらしいので、この方法も意味ないですかね。 というわけで今回の問題は普通に考えると発生するものと思いますが、これでは実際に困るケースがあるので、冗長化プロトコルの選択あるいは設定で逃げてがあると確信しているのですが。===>ルータのプロの方、お願いします。 |
|
投稿日時: 2005-02-05 14:54
ほろりんさん、くおんさん、zousanさん、返信をありがとうございました。
最初の図は、先頭と途中のブランクがなぜか詰められてしまって崩れてしまった様です。 もしよろしければブランクを"."で埋めなおしましたので、見難いですが確認頂ければと思います。 ================================ (IP1,MAC1)...........(IP2,MAC2) .[ルータ1].............[ルータ2] ....|.....................| ....|..(仮想IP,仮想MAC)..| ....+---------+.+---------+ ..............|.| ...........< SW-HUB > ...............| ...........+---+ ...........| ..........(PC) ================================ また今回の現象をもう少し詳しく書かせていただくと、ARP応答のフレームが以下の様になっており、ARP応答の中身自体は(仮想IP)と(仮想MAC)となっている為に、PCのARPテーブルは正しい組み合わせで学習されるのですが、MACフレームの送信元MACアドレスが、2台のルータの実MACであるために、[ルータ]〜(PC)間に設置されている<SW-HUB>はいつまで経っても(仮想IP)と(仮想MAC)を学習できず、結果的にPCから仮想MAC宛の多量の通信が、<SW-HUB>の全ポートに常に転送されてしまうと言うものです。 +------------- |(MACフレーム) |あて先MACアドレス=(PC) |送信元MACアドレス=(MAC1) or (MAC2) |※ SW-HUBはここしかハンドリングできないので、仮想MACを学習する機会がない |+------------ ||(IPパケット) ||プロトコル=ARP応答 ||+----------- |||(ARP応答) |||応答IPアドレス=(仮想IP) |||応答MACアドレス=(仮想MAC) |||※ PC等のIP端末はここをハンドリングできるので、仮想MACを正しく学習できる ||+----------- |+------------ +------------- >ほろりんさん、くおんさん 教えて頂いたURLも確認したのですが、"代理応答する端末が、送信元MACアドレスを本来の端末(この例では仮想MAC)に書き換えて応答"してくれれば今回の様な現象は起きないと思うのですが、そこまでは規定されていないのでしょうか。。。 >zousanさん 冗長化の仕組みですが、すみません確認していません。通常のネットワークはCISCO機でSTPで冗長構成となっています(CISCO機間はHSRPです)。今回問題となっているのは特殊なネットワークで、<SW-HUB>はSTPもVRRPもサポートしていない、ノンインテリのSW-HUBです(実際は何か理由があってDual-Speed-HUBがルータとSW-HUBの間にかましてあります)。 ちなみにCISCOのSTPでは、やはり2台のルータの実アドレスがARPの代理応答をしているのですが、送信元MACアドレスには実MACではなく、仮想MACをきちんと(?)セットして送信しているため、SW-HUBは仮想IPの仮想MACを学習できているのです。 "今回の問題は普通に考えると発生するものと思いますが、これでは実際に困るケースがあるので、冗長化プロトコルの選択あるいは設定で逃げてがある"というコメントを、ありがたく頂戴します。今回のケースでは、「ARPの仕様として認められているから配下LAN側で対応」ではなく、「ルータ側で配下LAN側で発生している障害を考慮して冗長プロトコルの選択あるいは設定でなんとかしてください」とお願いしたいと思います。 もしも"代理応答の際の送信元MACアドレスを本来ARP応答すべき端末のMACアドレスに書き換えなくてもよい(もしくは書き換えなければならない)"といった事に関する文書あるいはURLがありましたらご紹介ください。 みなさん、返信を本当にありがとうございます。もし可能であれば、もう少しお付き合い頂ければ幸いです。 |
|
投稿日時: 2005-02-05 14:59
くおんさんの質問に回答していませんでした。すみません。。。
>ところがルータ2がARPに反応して、PCのARP Tableに乗ると >PCはルータ2にパケットを投げてしまいます。 >これでは冗長構成の意味が無いような気がします。 全くの素人考えなのですが、[ルータ1]か[ルータ2]のどちらかが外部ネットワークへのルータとなってくれればいいので、(PC)がどちらにパケットを投げても問題ないのかなと思います。。。 いずれにせよ、冗長化の仕組み(プロトコルや、完全にACTIVE/STANDBYにしているのか、優先度を決めていないのか、等)を確認しようと思います。 |
|
投稿日時: 2005-02-06 00:02
>"代理応答する端末が、送信元MACアドレスを本来の端末(この例では仮想MAC)に書き
>換えて応答"してくれれば今回の様な現象は起きないと思うのですが そのままではSWの2つのポートに同じMACが学習されて、うまく動作しないはず。 >実際は何か理由があってDual-Speed-HUBがルータとSW-HUBの間にかましてあります それそれそれ!2つのルータはDual-Speed-HUBに接続されてるのですね。忘れてましたがNLBでのフラッディング対策に、その手がありました。特殊な設定をして、仮想MACをイーサフレームで使うようにします。仮想MACを学習するSWのポートは1つですから、発狂しません。これは想像ですが、設計者はそれを意図してDual-Speed-HUBを用意した可能性があります。 ところでNLBでその方法は、一つ欠点があります。言うまでも無く、バカハブが単一障害点になることです。SWでないのでSTPとかで逃げてがないんですね。これはルータ冗長構成でも同じと思うのですが。 |
|
投稿日時: 2005-02-06 15:09
zousanさん、ありがとうございます。
>特殊な設定をして、仮想MACをイーサフレームで使うようにします。 と言う事は、やっぱりイーサフレームで仮想MACが送信元MACアドレスになる様にルータで設定してもらわなければいけないんですよね。。。 |
1|2|3
次のページへ»