お世話になります。
本設問の解答では
「VIPアドレスに対するARPリクエストに応答しないように設定する。」
とのことでした。

これにより、SSOサーバがLBのGARPに応答することを防ぎ、IP重複時にも問題発生しないようにできることは理解できました。

疑問なのは、LBからSSOサーバに通信する際に、LBからSSOサーバのVIPへのARPに対しても、SSOサーバから応答ができなくなるので、果たして通信できるのか？という点です。

参考書など拝読すると、windowsサーバではデフォルトでARPに応答しない等見かけましたので、実際には問題ないのだろうと思います。
しかし、なぜ問題がないのか（LBがARP応答を得られず、宛先MACアドレスを知らずにどうやってSSOサーバと通信するのか？）がどうしても分からないため、御教示くださいますと幸いでございます。

私も学習中の身なので正誤は定かではないですが....
そもそも、自分のIPアドレスとは異なる、VIPアドレス宛ての通信を破棄せずに処理するためにループバックインターフェースを活用するという話なので、"VIPアドレスに対するARPリクエストに応答しないように設定" したのであれば、ループバックインターフェースのVIPアドレス宛てではない、各SSOサーバ(の物理インターフェースとでも呼びましょうか)が持つIPアドレスに対するARPには応答すると考えていました。  

そうであれば、LBは各SSOサーバのMACアドレスを知りえるので、SW2経由でリクエストパケットの転送ができるのではないかなと  

nuyuyu様
お返事ありがとうございます。
なるほど、メタ的な視点でしょうか。そういう発想もアリなのかもですね。

＞ループバックインターフェースのVIPアドレス宛てではない、各SSOサーバ(の物理インターフェースとでも呼びましょうか)が持つIPアドレスに対するARPには応答する
私もこれは正しいと思います。

私が疑問なのは、
①LBはSSOサーバのVIPと通信したい
②LBはSSOサーバのVIPと紐づくMACアドレスを知る必要がある（実IPと紐づくMACアドレスではなく…）
③LBはSSOサーバのVIPに関してARP解決しなければならない・・・
となるのではないかと思った点です。

仰る通り、LBは、SSOサーバの実IP「A」とMACアドレス「X」の組は、ARPによって知りえて、ARPテーブルに登録できるのだと思います。

このことによってLB⇔SSOサーバのVIPが通信可能になる、ということですと、このARPテーブルのMACアドレス「X」の情報を、VIPと関連付けて、VIPのMACアドレスは「X」である、とすることができるということなのでしょうかね・・・。

多分私の疑問は、未熟な自分が初歩的な何かに躓いているせいだとは思うのですが、複数のサイトや参考書、ChatGPTやら試したのですが、全然分からず困っています・・・。

この投稿は投稿者により削除されました。(2024.04.02 10:44)

>私が疑問なのは、
>①LBはSSOサーバのVIPと通信したい
>②LBはSSOサーバのVIPと紐づくMACアドレスを知る必要がある（実IPと紐づくMACアドレスではなく…）
>③LBはSSOサーバのVIPに関してARP解決しなければならない・・・

CentOS7のループバックI/Fにマスク長32ビットのIPアドレスを設定し、他の端末からループバックI/Fへの通信をWiresharkで確認しました。
ループバックI/FのアドレスをTARGET IP addressにセットしARPリクエストを送出したところ、ARPリプライのSender MAC addressは、物理アドレスのMACアドレスとなっていました。
また、ループバックI/Fのアドレス宛のPingも応答があります。

VIPと紐づくMACアドレスと実IPと紐づくMACアドレスは、同一だったので①②③は解決ではないでしょうか？

サイト上のBIG-IPのnPathの設定例を見ると、特にリアサーバのMACアドレスの手動登録もなく、実サーバのIPアドレスがコンフィグ上に書かれている点で、No4.の私の説明は間違いだと気づきました。大変失礼しました。
また、「ネットワークエンジニアとして」のサイトのDSRのページにリアサーバのMACアドレスをARPで取得される旨説明されているので、nuyuyuさんの説明が正しいと思います。

hisashi様

御教示ありがとうございます。疑問が残っております。

「VIPアドレスに対するARPリクエストに応答しないように設定する。」という設定をしたのに
LBはVIPに対してARPを送り、その応答を受けて通信ができる（応答しないのではなかったのか？）、というのがどうも理解が追い付いていない点です。

＞ループバックI/FのアドレスをTARGET IP addressにセットしARPリクエストを送出したところ、ARPリプライのSender MAC addressは、物理アドレスのMACアドレスとなっていました。

ここでいう「物理アドレス」とは、VIPとは異なる「実IPアドレス」のことでしょうか？
もしかして、
①LBが、ターゲットIPをVIPとしてARP要求
②実IPからARP応答がある（VIPからはARP応答なし）
③②で得たmacアドレス宛・VIP宛のパケット送出
ということでしょうか？

飲み込みが悪くて本当に申し訳ございません。
どうかお助けください。

混乱させてしまい申し訳ありません。
少し話を戻させてください。
LBは、VIPを通過するフレームを通信を適切なサーバに振り分けるのが本来の動作です。LBの振り分け先は、コマンドにより実IPのアドレスが設定されています。
今回の場合、SSOサーバ1、SSOサーバ2の実IPアドレスです
ここで、LBからSSOサーバ1に振り分ける場合の流れを例にします。

フレームの流れは下記の通りです。

①VIPで受信
②SSOサーバ1の物理MACアドレスを得るためARPを送信
③SSOサーバ1からARP応答
④LBからSSOサーバ1に転送

この時のフレームの宛先は、
宛先MACアドレス：SSOサーバ1の物理MACアドレス
宛先IPアドレス:SSOサーバ1の物理IPアドレス

上記にDSRの設定が加わると、宛先アドレスがVIPになりますが、上述の①～④の流れは同じです。
宛先MACアドレス：SSOサーバ1の物理MACアドレス
宛先IPアドレス:SSOサーバ1のループバックI/FのIPアドレス

ここで、VIPをループバックI/Fに持つサーバが宛先IPアドレスがVIP,宛先MACアドレスが物理MACアドレスであるフレームを受け取れるかどうかが懸念されますが、検証の結果、応答があったため問題ありませんでした。ループバックI/Fも物理MACアドレスが使われておりました。この点がNo.5の前半説明部分となります。

>ここでいう「物理アドレス」とは、VIPとは異なる「実IPアドレス」のことでしょうか？
実IPアドレスのことです。

>「VIPアドレスに対するARPリクエストに応答しないように設定する。」という設定をしたのに
>LBはVIPに対してARPを送り、その応答を受けて通信ができる（応答しないのではなかったのか？）、というのがどうも理解が追い付いていない点です。
混乱させてしまい申し訳ありません。検証は、ループバックI/FにARPに応答しない設定を投入していなかったため、応答していますが、DSRを設定する場合は応答しない設定が投入されます。

>①LBが、ターゲットIPをVIPとしてARP要求
>②実IPからARP応答がある（VIPからはARP応答なし）
VIPからARP応答です。

>③②で得たmacアドレス宛・VIP宛のパケット送出
>ということでしょうか？
VIPと紐づくMACアドレスを得ましたが、物理MACアドレスと同じアドレスでした。
パケット送出は、ご認識のとおりです。

文字数制限のため次に続きます。

=====================================
>①LBはSSOサーバのVIPと通信したい
>②LBはSSOサーバのVIPと紐づくMACアドレスを知る必要がある（実IPと紐づくMACアドレスではなく…）
>③LBはSSOサーバのVIPに関してARP解決しなければならない・・・
>となるのではないかと思った点です。
=====================================
この部分をおさらいします。

>①LBはSSOサーバのVIPと通信したい
LBがSSOサーバのVIPのMACアドレスに向けて通信をする場合、VIPに対してARPを投げるのが本来の動作と思います。
しかし、LBが通信したいのは、振り分け先であるSSOサーバの実IPアドレスです。VIPは、SSOサーバのループバックI/FでDSR用にフレームを受け取れるようにLBがフレームの宛先IPアドレスにセットしているに過ぎません。

>②LBはSSOサーバのVIPと紐づくMACアドレスを知る必要がある（実IPと紐づくMACアドレスではなく…）
LBは、実IPアドレスに紐づくMACアドレスを知りたいのでVIPに紐づくMACアドレスを知る必要はありません。
(SSOサーバ1のVIPのMACアドレスを知ろうとし、SSOサーバ2のVIPのMACアドレスが返ると誤った転送になる恐れがあります)

>③LBはSSOサーバのVIPに関してARP解決しなければならない・・・

この部分は、DNSリクエストに置き換えると少しイメージしやすいと思います。
WEBにアクセスする際、事前にURLのFQDNのAレコードをDNSサーバ（フルリゾルバ)にリクエストをし、得られたAレコードからIPアドレスを宛先にセットして通信するかと思います。

③を置き換えると「PCは、URLのFQDNに関して名前解決しなければならない」となります。

しかし、プロキシサーバを経由すると、事情が変わります。
プロキシサーバ経由では、宛先IPアドレスにプロキシサーバのIPアドレスがセットされるため、URLのFQDNの如何に関わらず、PCの宛先IPアドレスはプロキシサーバになります。

また、プロキシサーバの指定にプロキシサーバのFQDNが設定されていると、PCがDNSサーバに投げるクエリのFQDNは、プロキシサーバになります。

②③を置き換えると
「PCは、プロキシサーバのFQDNに紐づくIPアドレスを知る必要がある(URLのFQDNではなく・・）」
「PCは、プロキシサーバのFQDNに関して名前解決をしなければならない」
となります

DSRは、LBがVIPを持ちながら、宛先IPアドレスにVIPをセットして転送する特殊な機能です。ARPリクエストについても異例であると一旦受け止めるほかないと思います。

hisashi様

ご丁寧にありがとうございます。

＞①VIPで受信
＞②SSOサーバ1の物理MACアドレスを得るためARPを送信
＞③SSOサーバ1からARP応答
＞④LBからSSOサーバ1に転送

＞この時のフレームの宛先は、
＞宛先MACアドレス：SSOサーバ1の物理MACアドレス
＞宛先IPアドレス:SSOサーバ1の物理IPアドレス

＞上記にDSRの設定が加わると、宛先アドレスがVIPになりますが、上述の①～④の流れは同じです。

通常、宛先IPアドレスに対するARP解決を行って通信すると思います。
ですが、DSRの場合に関しては、LBは、宛先IPアドレス（VIP）に対してではなく、
あらかじめ設定した？IPアドレス（この場合は、SSOサーバ1の物理IPアドレス）に対してARP解決をし、
それにも関わらず、フレームは
  宛先MACアドレス：物理MACアドレス（物理IPアドレスからARP解決したもの）
  宛先IPアドレス：VIP
というものを送出する・・・
この理解で合っていますでしょうか。

それにしても、ここまでのことをARPの基礎知識のみで導出するのはかなり厳しいですね。
私は「宛先IPアドレスに対するARP解決を行って通信する」という原則から、公式の「VIPアドレスに対するARPリクエストに応答しないように設定する」はあり得ないと思って違う回答をしてしまいました。難しいですね。

すみません、横から失礼します。書き込みを拝見して、ARPについてたいへん勉強になりました。ありがとうございます。自分でもいろいろ考えているうちにふと思ったのですが、
>VIPアドレスに対するARPリクエストに応答しないように設定する。
こちらの解答で対象にしているのはLBではなくて、PCやサーバ等～SSOサーバの通信をするときに行われるARPリクエストのことかなと思いました。
（設定しないと、LB,SSOサーバから応答が返ってきてしまう。設定すれば、LBから返ってくるだけ。）
私見を書かせていただきました。ピントがずれていたらすみません。

>あらかじめ設定した？IPアドレス（この場合は、SSOサーバ1の物理IPアドレス）に対してARP解決をし、
>それにも関わらず、フレームは
>  宛先MACアドレス：物理MACアドレス（物理IPアドレスからARP解決したもの）
>  宛先IPアドレス：VIP
>というものを送出する・・・
>この理解で合っていますでしょうか。

ご認識のとおりです。振り分け先サーバに対してARPを投げます。
私もループバックI/Fを設定するまで、ARPのリプライ挙動が判っていなかったので勉強になりました。

>こちらの解答で対象にしているのはLBではなくて、PCやサーバ等～SSOサーバの通信をするときに行われるARPリクエストのことかなと思いました。

触れておりませんでしたがこれも理由の1つとしてあります。
ルータ、LB、SSOサーバが同一セグメントに位置しているため、ルータがLBのVIP向けにARPリクエストをする際、関係のないSSOサーバが先に応答しLBを経由しなくなる可能性があります。

hisashi 様

本当にありがとうございました。
正直、本番でこのような論理展開の問題が出たら、私の頭では正答できる自信はありませんが、今回のDSRの件についてはきちんと勉強することができました。
丁寧な御指導、大変感謝申し上げます。