私は2つの記事「
BGPを 使用し ないCiscoルーター上のデュアルISP 」と「
Ciscoルーター上の2つのプロバイダーの同時使用 」を読みました。 少し標準的ではない別のタスクの解決策を描いて説明しようとする考えが浮かびました。
そこで、簡単な例を考えてみましょう。 クライアントがあり、2つのプロバイダーがあります（アップリンク）。 BGPピアを構築するための自律システムはありませんが、1つのチャネルが落ちたときに何らかの形で作業する必要があります。 さらに、ネットワークの内部クライアントがありますが、これは他の全員と同じようには機能しませんが、まったく逆です。 通常（両方のチャネルが機能する）、このクライアントは引き続きバックアップチャネル（Dialer1）を通過しますが、全員がメインチャネル（Dialer0）で作業し、バックアップがドロップした場合にのみメインチャネルに切り替えます（！）など）。
考えられる解決策の1つは（いわゆる「正面」）、次のようになります。
インターフェイスVlan1
IPアドレス192.168.0.1 255.255.255.0
IPポリシールートマップトラッキング
！
ルートマップトラッキング許可10
一致するIPアドレス1
デフォルトのインターフェースを設定しますDialer1 Dialer0
！
ルートマップトラッキング許可20
一致するIPアドレス2
デフォルトのインターフェイスを設定しますDialer0 Dialer1
！
アクセスリスト1許可192.168.0.101
アクセスリスト2は192.168.0.101を拒否します
アクセスリスト2許可192.168.0.0 0.0.0.255
はい、この設計は機能しますが、1つの欠点があり、十分に明らかではありません。
このような状況では、ステータスとプロトコルの両方がUp状態にあり、チャネルが機能しないことがあります。 この場合、この設計は役に立ちません。
どうする？ すべてが非常に簡単です。slaの機能を使用します。
これには何が必要ですか？ ルートマップトラッキングを書き直し、slaのルールを記述するだけです。
インターフェイスVlan1
IPアドレス192.168.0.1 255.255.255.0
IPポリシールートマップトラッキング
！
123 rtr 1到達可能性の追跡
！
トラック124 RTR 2到達可能性
！
ip sla 1
icmp-echo 195.5.5.208 source-interface Dialer1
タイムアウト2000
しきい値2
頻度3
ip sla schedule 1 life forever forever start-time now
ip sla 2
icmp-echo 193.34.140.1 source-interface Dialer0
タイムアウト2000
しきい値2
頻度3
ip sla schedule 2 life forever forever start-time now
！
ルートマップトラッキング許可100
一致するIPアドレス1
set ip next-hop verify-availability 195.5.5.208 10 track 123
set ip next-hop verify-availability 193.34.140.1 20 track 124
！
ルートマップトラッキング許可120
一致するIPアドレス2
set ip next-hop verify-availability 193.34.140.1 10 track 124
set ip next-hop verify-availability 195.5.5.208 20 track 123
！
ルートマップトラッキング許可200
set ip next-hop verify-availability 195.5.5.208 10 track 123
set ip next-hop verify-availability 193.34.140.1 20 track 124
！
アクセスリスト1許可192.168.0.101
アクセスリスト2は192.168.0.101を拒否します
アクセスリスト2許可192.168.0.0 0.0.0.255
実際、すべてがシンプルです。 ;）
route-mapは、最初の一致を検出した後、パケットのルールの作成を中止します。 したがって、実際には、シーケンスを決定する順序が重要です！
インターフェースの状態を見ると、次のことがわかります。
#sh ip int br | i ^ダイヤラ
Dialer0 193.34.141.151 YES IPCP up up
Dialer1は割り当てられていません
同時に、ステータスとDialer1プロトコルの両方がアップ状態になっていることがわかります。 最初のオプションのルートマップトラッキングは機能せず、クライアント192.168.0.101は単に機能しません。 しかし、2番目のオプションからルートマップトラッキングに関する統計を見ると、次のように表示されます。
#shルートマップトラッキング
ルートマップトラッキング、許可、シーケンス100
一致句：
IPアドレス（アクセスリスト）：1
セット句：
ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
ポリシールーティングの一致：711パケット、95929バイト
ルートマップトラッキング、許可、シーケンス120
一致句：
IPアドレス（アクセスリスト）：2
セット句：
ip next-hop verify-availability 193.34.140.1 10 track 124 [up]
ip next-hop verify-availability 195.5.5.208 20 track 123 [down]
ポリシールーティングの一致：216パケット、14100バイト
ルートマップトラッキング、許可、シーケンス200
一致句：
セット句：
ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
ポリシールーティングの一致：0パケット、0バイト ip next-hop verify-availability 195.5.5.208 10の状態はダウンとして示されているため、これらのルートは確立されません。
ps：挿入できるコメントの多くは省略されています。これは、上記の2つの記事が以前に読まれたことが理解されているため、読者は何が問題かを知っているからです。