IP ルーティング

NAT 機能を利用したパフォーマンス ルーティング

ホワイトペーパー





NAT 機能を利用したパフォーマンス ルーティング



最終更新:2008 年 3 月


同じルータ上にパフォーマンス ルーティング(PfR)と Network Address Translation(NAT; ネットワーク アドレス変換)機能の両方を設定する場合は、特定の動作について考慮する必要があります。このホワイト ペーパーでは、スタティック ルーティングを使用してプレフィクスのルーティングを制御する場合の PfR の動作について説明します。


はじめに


PfR と NAT の両方を使用する場合は、動的な最適化について考慮する必要があります。PfR でトラフィック フローまたはアプリケーションを最適化することが決定されると、実際的な問題として、PfR と NAT の間の緊密なコラボレーションが必要となる場合があります。このホワイト ペーパーでは、この緊密なコラボレーションについて説明し、このような環境での PfR の動作について考察します。

この実際的な問題が生じるのは、次の条件にすべて当てはまる場合です。

  1. 同じルータ(ルータ A)から複数の ISP(ISP A、ISP B など)へのスタティック ルーティング
  2. ルータ A が PfR ボーダルータとして構成されている
  3. NAT がルータ A 上に設定されている
    ip nat inside source list <X> interface <INTERFACE_ISP_A> overload
  4. 1 つ以上の ISP に Strict Unicast Reverse Path Forwarding(uRPF)が設定されている

この状況で何が起きるか


上記の条件に当てはまるサイトでは、最適化後、アプリケーションが失敗する可能性があります。根本的な原因は、ISP での Unicast Reverse Path Forwarding(uRPF; ユニキャスト リバース パス転送)の使用状況に基づいて特定できます。多くの ISP では、セキュリティ上の理由から、またインフラストラクチャで最適化されていないトラフィック フローが発生しないように、uRPF フィルタリングを有効にしています。uRPF により ISP の入力インターフェイスでパケットがドロップされる可能性があるため、uRPF はアプリケーションに影響を与えます。

パケットがドロップされるのはなぜか

NAT では、変換スロットを作成するときに、接続先の ISP から(たとえば、ISP A から)、IPv4 グローバル アドレスを取得します。ここで、PfR によってアプリケーションが最適化され、最適なパスが変更されて、ISP A 経由ではなく ISP B 経由が最適なパスになったとします。この場合、フローで使用されている IPv4 送信元アドレスは ISP A のアドレス範囲からのものであり、必要とされる ISP B のアドレス範囲からではないため、ISP B でアプリケーション パケットがドロップされます。

ソリューション


ソリューションは、PfR と NAT を緊密に連携させることです。これを行うには、次の設定を追加します。

interface virtual-template 1

コマンドを変更します。元のコマンドは次のとおりです。

"ip nat inside source <X> interface <Interface_ISP_A> overload"

変更後のコマンドは次のとおりです。

"ip nat inside source <x> interface Virtual-Template 1 overload oer"

どのように問題が修正されるのか

この設定を使用すると、PfR と NAT が連携します。PfR により、新しい変換で、パケットがルーティングされる ISP インターフェイスから送信元 IP アドレスが取得されるようになります。これにより、uRPF でパケットがドロップされなくなります。PfR により、既存のフローは、強制的に、変換が作成されたインターフェイス上でルーティングされます。PfR によってプレフィクスのルートが変更された場合、新しい変換に対するフローは、新しいインターフェイスにルーティングされます。ただし、既存の変換と一致するフローは、再ルーティングされません。したがって、ドロップされる uRPF パケットはありません。

副作用はあるか

長時間経過したフローが再ルーティングされません。PfR の目標は、アプリケーションのパフォーマンスを保証することです。フローが再ルーティングされると、uRPF によってパケットがドロップされ、アプリケーションが停止します。そのため、PfR では、ドロップされないように、既存のフローのルーティングを維持します。新しいフローが既存の変換と一致しないように、一部の変換タイマーの短縮が必要となる場合があります。理想は、新しいフローごとに新しい変換を作成することです。

ISP に uRPF が設定されているかどうかを、どのように確認するか

シスコとインターネット コミュニティでは、直接接続する顧客のために、すべての ISP で uRPF を使用することを推奨しています。uRPF により、送信元アドレスが ISP インターフェイスに到達できるネットワークと一致する必要があるため、アドレスのスプーフィングを防止できます。一般的には、ISP には uRPF が設定されていると考えられます。uRPF が設定されていない場合でも、ISP は、独自の判断でいつでも設定できます。

顧客は、uRPF を設定しないよう ISP に求めることもできます。ただし、これにより、偽装アドレスがその ISP を通過できるようになるため、ISP と顧客の間に疑念が生じる可能性があります。

Q&A


この問題がスタティック ルーティングに限定されるのはなぜですか。

PfR、NAT、uRPF、および Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)のインターネットへのルーティングでは、uRPF によるパケットのドロップは発生しません。

ISP へのルーティングには、BGP とスタティック ルーティングの 2 つの方法があります。どちらの場合でも、ISP には uRPF を設定する必要があります。ただし、BGP では、すべての ISP に対して同じネットワークがアドバタイズされます。そのネットワークは、そのネットワークからの送信元アドレスを使用してどの ISP からも到達できるため、uRPF チェックを通過します。ドロップされるパケットはありません。

このソリューションに制限はありますか。

このソリューションは、PfR と NAT が設定されている同じルータが終端となる回線にのみ適用されます。NAT を使用して複数のルータで回線を終端することはサポートされません。このソリューションは、PfR を設定できない IOS 以外のデバイス上に NAT が設定されているネットワーク設定には対応していません。

お問い合わせ