はじめに
別記事https://qiita.com/Heizo_Hasegawa/items/80f348663f89dfb0ec11 のPBR（Policy Based Routing）動作確認時には内部→外部への通信が主だったため、混同を避けるために深くは触れませんでしたが、外部→内部への通信（に対する戻りである内部や外部通信）においては、このAuto Last Hopが有効に働きます。
実は今までLBの近いところに複数の上位抜け回線が存在するようなシステム案件と遭遇する縁がさほどなく・・・。大昔のみやたひろしさんLB書籍
にてAuto Last Hop記載のあったことを朧げに覚えている程度だったのですが、それこそこれも十数年ぶりのリベンジになりますでしょうか。せっかく今回PBRで組んだ環境がありますので、Auto Last Hopについても基本的なところの動作確認おさらいをしてみたいと思います。
1. Auto Last Hopとは
F5の「Auto Last Hop」は、BIG-IPがクライアントからのリクエストを受信した際、その通信元MACアドレスを記録し、サーバーからの応答を必ず同じ経路（元のMACアドレス）へ返送する機能です。
通常、ネットワークはルーティングテーブルに基づいて経路を決定しますが、この機能を使うとルーティングを無視して「来た道」へそのまま返します。これにより、クライアントとBIG-IPの間に複数のゲートウェイや複雑なルーティングが存在する場合でも、非対称ルーティングによるパケット破棄を防ぎ、通信を安定させることが可能です。
- K13876: Overview of the Auto Last Hop setting (15.x - 21.x)
- K9487: BIG-IP support for neighboring VRRP/HSRP routers
※上記K9487でも言及がありますが、LB直近にVRRP/HSRPが運用されており仮想MACも用いていない場合は、本Auto Last Hop機能を無効化することが必要です（持ち切ってしまうため）。
2. 試験環境
下記のような上位抜けが2方路あるようなものを模した環境を利用します。
Default Routeは 192.168.20.254 に向いています。
接続元クライアント相当として、下記2つのVMを用意します。OSI Layer 3 IPレベルでのroute疎通は赤VMのみが可能という状況です。
- 緑VM (5.6.7.8) ※Default Routeに含まれていないもの
- 赤VM (192.168.20.254) ※Default Routeの先にいるもの
3. VSの構築
- 192.168.20.201（青色のVMに対して分散通信を行うVS。後程Auto Last Hop有効/無効を切り替えて挙動を確認します）
- 192.168.20.202（黄色のVMに対して分散通信を行うVS）
- PBR試験で有効にしていたL3FWD（含むPBR）は無効化しておきます。
4. Auto Last Hop設定場所
System → Configuration → Local Traffic → General にて、システムとしてのAuto Last Hop有効/無効設定ができます。
（今回はVS毎に明示的設定を行いますので、本値はDon't care扱いですが、整理のため無効にしておきます。）
Auto Last Hop設定はVirtualServer毎にも指定できます。
- Default：前述のシステムGeneral設定に従う
- Enabled：有効
- Disabled：無効
5. 実験
Auto Last Hop有効→Auto Last Hop無効 とパターンを切り替えて、挙動の差異を確認してみます。
● 試験1（Auto Last Hop有効化）
192.168.20.201（青VS）および 192.168.20.202（黄VS）の両方で、Auto Last Hopを明示的に有効化します。
通信確認結果:
- 緑VM(5.6.7.8)からのアクセス：192.168.20.201(OK) / 192.168.20.202(OK)
- 赤VM(192.168.20.254)からのアクセス：192.168.20.201(OK) / 192.168.20.202(OK)
● 試験2（Auto Last Hop無効化）
192.168.20.201（青VS）のAuto Last Hopを明示的に無効化します（黄VSは有効のまま）。
通信確認結果:
- 緑VM(5.6.7.8)からのアクセス：192.168.20.201(NG) / 192.168.20.202(OK)
- 赤VM(192.168.20.254)からのアクセス：192.168.20.201(OK) / 192.168.20.202(OK)
→緑VM(5.6.7.8)からのアクセス：192.168.20.201(NG) となりました。
→通信が失敗した192.168.20.201 routeだけ抜き出したflow図。
パケットキャプチャ確認:
緑VM(5.6.7.8)からLBのVS(192.168.20.201)への 3-way handshake Syn+Ack が Default Route 方向に流れて行ってしまい、TCPセッションが張れていないことを確認しました。(想定通り
)
おわりに
差分を確認すると、Auto Last Hopの有無により、戻り通信の制御が明確に異なることが分かります。
Default Gatewayの存在を意識せず、L2レイヤーの情報を優先してパケットを返送するこの機能は、複雑なネットワークトポロジーにおけるトラブルシューティングや設計において使える武器になると思います。意識的に活用していきましょう。