サーバー負荷分散のためのSNATとPBR

ワンアームSLB構成では、SNATを使用して、リターントラフィックがSLBを通過するように強制します。これには1つの欠点があります。単に、XFF（X-Forwarded-For）ヘッダーで渡され、Webサーバーがログに記録できる場合を除き、Webログは真のクライアントIPをキャプチャできないということです。

別の方法は、PBR（ポリシーベースのルーティング）を使用して戻りトラフィックをSLBに戻すことですが、SUP720 / PFC3Bを備えた6500Eプラットフォームで他に優れた解決策がない限り、PBRを回避しようとします-そして、私は特定のことを知っていますIOSバージョンも要因になる可能性があります-PBRがすべてハードウェアで行われていると仮定すると、PBRはSNATを実行するよりも遅延を追加しますか？ PBRが現在サポートされているコマンドのみを使用してハードウェアで実行される場合、将来IOSをアップグレードするとPBRがソフトウェア/プロセス切り替えで実行されるように変更される可能性はありますか？

現在、当社のロードバランサーは、ほとんどのWebサーバーVLANの真後ろにあり（デフォルトのg / wはSLBを指しています）、非SLB VLANのSQLなどの他のサーバーです。ただし、このWeb-SQLトラフィックはSLBを通過します。私たちの目標は、SLBを超えないようにし、SQLトラフィックを分離したままにし、本当のクライアントをWebログに保持することです。PBRでのトラブルシューティングの複雑さを導入したくないので、将来的にハードウェアからソフトウェアにこの変更を処理する可能性があります。 前述のXFFとSNATが不足している場合、PBRはここでの唯一のオプションであり、PBRを緊密に構成しておくための最良の方法は何ですか？

PBRがすべてハードウェアで行われていると仮定すると、PBRはSNATを実行するよりも遅延を追加しますか

Sup720はHWでPBRをサポートします。PBRはインターフェイスキューイングを追加しないため、追加のレイテンシ（存在する場合）は無視できます。PBRは必要以上に難しくなると思います（そして、それが機能するかどうかさえまだわかりません...そのオプションの詳細は完全に明確ではありません）。

前述のXFFとSNATが不足している場合、PBRはここでの唯一のオプションであり、PBRを緊密に構成しておくための最良の方法は何ですか？

PBRだけが選択肢ではありません。提案されたオプションは少し不明確ですが、PBRは通常、静的ルーティングを行うためのより洗練された方法にすぎません。

通常、これは、SQLクエリを必要とする負荷分散サービスに最適なトポロジです...

• VIPをフロントサイドサブネットに配置します...図の172.16.1.0/24
• サーバープールをバックサイドサブネットに配置します...図の172.16.2.0/24
• SQLクエリを別のインターフェイスに配置します...図の172.16.3.0/24。SQLクエリを必要とするすべてのサーバーに2番目のインターフェイスを追加します。このサブネット上のアドレスに対してすべてのSQLクエリを作成します。SQLの接続はARPまたはホストルート（設定によって異なります）のみに依存しているため、このトポロジはUnixとWindowsの両方で機能します。

図：

このトポロジには追加の利点があります。

• SQLクエリはバースト性があり、Webトラフィックの輻輳を引き起こす可能性があるため、SQLインターフェースをWebトラフィックから分離します。
• 負荷分散サービス（インターネットを通過する場合は通常1500以下に保つ必要がある）とSQLサービス（ジャンボフレームを優先する）に異なるMTUを提供します。

ワンアームトポロジのために最大スループットが半分になってしまうため、ワンアームロードバランサートポロジはあまり望ましくないオプションです。

Sup720でのHWとSWの切り替えに関する質問の編集

これは深いトピックですが、要約バージョンを提供します... Sup720は各方向（入力/出力）にACLを適用し、プラットフォームが選択したマージアルゴリズムに基づいてACLをTCAMに適合させる必要があります。Sup720の機能マネージャ（つまりfm）は、機能をTCAMに仲介し、パント隣接（SW切り替えを意味する）があるかどうか、またはプロトコルと方向の組み合わせがHWで切り替えられたかどうかを報告します。かどうかを分離するには

1. まず、PBRトラフィックが通過できるすべての入力および出力レイヤ3インターフェイスを特定します
2. 次に、の出力を調べます（ステップ1で、すべてのインターフェースの入力方向と出力方向の両方をshow fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config確認する必要があります）。CAPSの値が下に表示される値と一致する場合、トラフィックはHWスイッチングされます...私が使用しているコマンドの出力は、表示されるものと非常に似ています...show fm fie summary

Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS      <--- in HW
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS   <--- in HW
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS    <--- in HW
Interface Vl220 [Ingress]:
 FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT                        <--- in HW
 Features Configured : V4_DEF   - Protocol : IP
 FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT                     <--- in HW
 Features Configured : OTH_DEF   - Protocol : OTHER
 FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT                      <--- in HW
 Features Configured : V6_DEF   - Protocol : IPV6
Interface Vl220 [Egress]:
 No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#

上記のインターフェースは出力の出力を示していませんが、それは無関係です...出力は入力方向に似ています。 TCAMバンクのダイナミクス/マージ結果の詳細を知りたい場合は、Ricky Mickyが「sh fm fie interface」の優れた説明を書きました。

ロードバランサーがサポートしている場合、Direct Server Returnも必要な処理を実行します。ロードバランサーでサポートする必要があり、オペレーティングシステムの問題がいくつかあります。サーバーにはループバックインターフェイスがあるため、実サーバーのアドレスが実サーバーのMACアドレスのみを使用してパケットを転送する一方で、VIPのIPアドレスを持つすべてのサーバーに「ループバック」インターフェースを配置する必要があります。その中のVIP、サーバーはパケットを受け入れます。

特定のLBベンダーのドキュメントを参照する必要があり、サーバーチームは仮想アダプターを管理できる必要があります（自動サーバープロビジョニングでMSループバックアダプターを管理できるとは考えていなかったため、この機能は使用しません。

ただし、これはLBでNATを使用しないため、PBRを実行する必要はありません。