テクノロジーの本質と落とし穴について簡単に説明します。
したがって、1つの内部ポート（g0 / 0）と2つの外部（f0 / 0、f0 / 1）を備えた1つのCiscoボーダールーターを用意します。 2つのプロバイダーへの接続があり、それぞれがアドレスプール（ISP1）とプール（ISP2）のプールを発行しました（これらは特定のプロバイダーに属するいくつかのネットワークです）。 簡単にするために、同じプールのインターフェイスのアドレスをf0 / 0およびf0 / 1とします。 そして、同じプールからのゲートウェイのアドレス（それぞれゲート（ISP1）とゲート（ISP2））。
BGPを上げる機能がないため、各プロバイダーのデフォルトルートを登録する必要があります。 そして、ここで最初の質問が発生します：どの問題を解決したいですか？ 2つのプロバイダーとの予約または同時作業ですか？
ご予約
このトポロジでは、一度に1つのプロバイダーのみが機能します。 つまり、ISP1プロバイダーがチェックされるように手配し、生きている場合はそれを通過し、「死んでいる」場合はISP2バックアッププロバイダーに切り替える必要があります。 落とし穴があります：NAT。 いくつかの変換ルールを記述できますが、何らかの方法でISP1を終了するときにプール（ISP1）を使用し、ISP2を終了するときにプール（ISP2）を使用することを示す必要があります。 ISP2を通過し、ソースアドレスがプール（ISP1）からのものである場合、最適な場合は非対称ルーティングを取得し、最悪の場合はパケットがまったく届かないことは明らかです。たとえば、プロバイダーはRFC2827フィルタリングを使用する要件を満たしているためです。ネットワークからではなく送信元アドレスを持つパケットを受信します。
したがって、2つのサブタスクがあります。出力インターフェースを考慮して、プロバイダー（ルート）の活性をチェックし、アドレス変換を行います。
活気を確認してください。
Ciscoルーターには、SLAと呼ばれるすばらしい技術があります。 これを使用すると、pingを使用して特定のアドレスを確認できるだけでなく、特定のサービス（ftp-connect、tcp-connect）または通信チャネルパラメーター（icmp-jitter、udp-jitter）の活性も確認できます。 ここでは、最も単純で最も一般的な方法である特定のホストへのpingを検討します。 簡単にするために、ゲートプロバイダー（ISPX）のゲートウェイアドレスにpingを実行します。 別のアドレスをpingする必要がある場合は、チェックする特定のプロバイダーを介してこのアドレスへのルートを明示的に登録する必要があります。
！ 「pingoval」のパラメーターを設定します
ip sla {＃}
icmp-echo {ip} [ソースインターフェイス{int}]
！
！ pingovalkuを開始します
ip sla schedule {＃}今すぐ永遠に開始
！
！ ルートが依存する「スイッチ」（トラック）を設定します
追跡{＃} ip sla {＃}到達可能性
！
！ 追跡付きのデフォルトルートを設定する
ip route 0.0.0.0 0.0.0.0 {next-hop} track {＃}
注：古いIOSでは、slaへのトラックのバインディングコマンドは次のようになりました
{＃} rtr {sla＃}到達可能性を追跡する
ホストが応答すると、トラックはUP状態になり、ルートはルーティングテーブルになります。 A
pingが消えた場合、設定された期間（デフォルトでは3 * 10秒）後に追跡します
状態をDOWNに変更し、ルートが再び変更されるまでルートが削除されます
状態。
例：
ip sla 1 icmp-echo Gate（ISP1） ip sla schedule 1 start now life forever トラック11 ip sla 1到達可能性 ip route 0.0.0.0 0.0.0.0 Gate（ISP1）トラック11
ISP2は、チャネルに不要なサービストラフィックを作成しないようにチェックできません。 予備のものがあり、高価な場合があります（たとえば、衛星チャンネル、または勤務時間で支払われるダイヤルアップチャンネル）。 アドミニストレーティブディスタンスが大きい2番目のプロバイダーへのルートを作成し、メインプロバイダーが消えたときにのみ機能するようにします。
発信インターフェイスに基づいてアドレス変換ルールを設定します。
実際には、動的変換と静的アドレス変換の2つのタスクがあります。 最初に外出する必要があり、2つ目はサービスの発表用です。 どちらの場合も、ルートマップと呼ばれる構成が必要です（各プロバイダーのルートマップを作成する必要があります）
！ ルートマップを作成する
ルートマップISPX許可{＃}
！ この段落ルートマップに入るための基準を指定する
一致インターフェース{送信インターフェース}
微妙な点があります：ツールチップでword interfaceを指定すると、
ルートの最初のホップインターフェイスと一致します
つまり 一般的に言えば、このパラメーターが何であるかは明確ではありません。 さらに、インターフェイス自体に書かれている内容によっては、この基準は着信インターフェイスと発信インターフェイスの両方を意味する場合があります！ そして、それはインターフェイスのip natコマンドで何が書かれているかに依存します：
ip nat inside-基準は着信インターフェースを意味します
ip nat outside-基準は発信インターフェースを意味します
次に、各プロバイダーからのアドレスのプールが必要です
ip nat pool PoolX {start-ip（ISPX）} {end-ip（ISPX）}
そして、あなたはすでに各プロバイダーのNATルールを書くことができます
ソースルートマップISPX poolXオーバーロード内のip nat
オーバーロード-PAT（ポートアドレス変換、ソースポート変換）を使用することを意味するキーワード
静的なブロードキャストを追加する必要がある場合、ほぼ同じことを行います（サーバーが各プロバイダーからSrv（ISPX）アドレスを、サーバーSrv（LAN）からローカルアドレスを予約できるようにします）。
ソーススタティックSrv（ISPX）Srv（LAN）ルートマップISPX内のip nat
____________
UPD注意：アッパーミッション！
でなければならない
ソーススタティックSrv（LAN）Srv（ISPX）ルートマップISPX内のip nat
____________
この場合、もちろん、DNSサーバー上の両方のアドレス（Srv（ISP1）とSrv（ISP2））が登録され、同じ名前を指していることを確認する必要があります。
合計、我々は得た：
！
！ インターフェース
int g0 / 0
IPアドレス[LAN]
内部IP NAT
！
int f0 / 0
IPアドレスアドレス（ISP1）
ip nat outside
！
int f0 / 1
IPアドレスアドレス（ISP2）
ip nat outside
！
！ ルーティング
ip sla 1
icmp-echo Gate（ISP1）
ip sla schedule 1 start now life forever
トラック11 ip sla 1到達可能性
ip route 0.0.0.0 0.0.0.0 Gate（ISP1）トラック11
ip route 0.0.0.0 0.0.0.0 Gate（ISP2）50
！
！ NATのプール
ip nat pool POOL1 {start-ip（ISP1）} {end-ip（ISP1）}
ip nat pool POOL2 {start-ip（ISP2）} {end-ip（ISP2）}
！
！ NATaのルートマップ
ルートマップISP1許可10
インターフェースf0 / 0と一致
！
ルートマップISP2許可10
インターフェースf0 / 1に一致
！
！ NATaルール
ソースルートマップISP1 POOL1オーバーロード内のip nat
ソースルートマップISP2 POOL2オーバーロード内のip nat
ソーススタティックSrv（LAN）Srv（ISP1）ルートマップISP1内のip nat
ソーススタティックSrv（LAN）Srv（ISP2）ルートマップISP2内のip nat
2つのプロバイダーの同時使用
最初のケースですべてが明確で曖昧でない場合、2つのプロバイダーを同時に使用する場合に問題が発生します。
このトピックは面白いですか？ どんな考えや問題がありますか？
書く：私は私の考えでコンパイルし、必要に応じてレイアウトします。