How to get ARP Reply！

　◆　ARP Reply してくれない時の対処

　TCP/IPを利用したEthernet LANでの通信には、IPアドレスとMACアドレスの2つの情報が必要となります。
　そのため、IPアドレスからEthernetのMACアドレスの情報を得られる ARP を使用します。しかしこちらが
　ARPリクエストを送信しても、相手側の機器の仕様によってARPリプライを返してくれない場合があります。
　そのような場合、以下の3つの手法によって対処することができます。

　�@　自身の機器でARPエントリをスタティックで登録
　⇒　ARPリプライしてくれないIPアドレスとMACアドレスのARPエントリを静的に登録します。

　�A　自身の機器で「/32」のホストルートを定義
　⇒　ARPリプレイしてくれないデバイスのI/Fをネクストホップとしたホストルートを定義します。

　�B　相手側の機器でProxy ARPを有効にする（ Juniper SRXなどの場合 ）
　⇒　ARPリプライしてくれないデバイス（SRXなど）でProxy ARPを有効化して代理応答させます。

　注意点として�@の手法を採用した場合は、相手側の機器が故障して機器交換になった時はMACアドレスが
　変更になるので、再度設定し直す必要があることから運用上の手間が発生してしまいます。その観点から、
　当方は基本的に�Aまたは�Bの手法で通信要件を満たすようにしています。では具体的なケースを見てみます。



　◆　ケース１：F5 - snat を iRule で定義した時

　F5のBIG-IPでバーチャルサーバを作成した場合、BIG-IPはそのバーチャルサーバのIPアドレスに対して
　ARPリクエストが着信すれば、ARPリプライを返してくれます。しかし、例えばアウトバウンド通信に
　対して送信元アドレス変換を行う定義をiRuleで定義した場合は、その変換後のBIG-IPアドレスに対して
　ARPリクエストを送信しても、ARPリプライを返してくれない仕様になっています。そのような場合は、
　ARPリプライを求めている上位の機器で「/32」のホストルートを定義することで要件を満たしています。

　宛先の「10.1.1.10」がBIG-IPによるNAT変換後のアドレスであり、ネクストホップの「10.1.1.1」はBIG-IPのI/Fのアドレス。



　◆　ケース2：Juniper - SRXのNAT変換時

　Juniper SRXでは、自分のI/FのIPアドレス以外のARPを返さない仕様になっていることから、NAT変換で
　Juniper SRXのIPアドレスを使用するのではなく、そのI/Fと同じセグメントのIPアドレスを使用する場合、
　構成によりARPリプライを返してくれません。そのような場合、Juniper社の実装例で紹介されている通り
　Proxy ARPをSRXのI/Fで定義します。

　SRXの I/F と同じセグメントのIPアドレスをNAT変換後のアドレスとして使用する場合でも、対向の機器で
　その変換後のアドレスを宛先としたホストルートを定義している場合は、ネクストホップのIPアドレスさえ
　MACアドレスを解決（つまりSRXのI/FのMACアドレスの解決）できれば通信できるのでProxy ARPは不要。

　また、ホストルートが定義されていない場合でも、例えば、SRX同士のルートベースVPN接続の場合において
　自身のトンネルインターフェースのセグメントと、相手のトンネルインターフェースのセグメントが異なれば
　SRXのTunnel I/Fと同じセグメントのIPアドレスをNAT変換後のアドレスとして使用する場合でもProxy ARP
　の設定は不要となります。Tunnel I/F はLAN接続とは異なり、ピア機器で異なるセグメントを定義できます。