この記事では、Cisco Embedded Event Manager（EEM）を使用して複数のアップストリームプロバイダーからのインバウンドトラフィックとアップリンク冗長性のバランスをとる、IOS XEオペレーティングシステムを使用したCiscoルーターでのBPGアナウンスメントの管理方法について説明します。

はじめに

多くの場合、小規模プロバイダーのネットワークでは、アップリンクが2つ以上のオペレーターへのBGP接続であるという状況に遭遇する可能性があります。さらに、2番目のプロバイダーはリザーブとしては使用されませんが、最初のプロバイダーと同時に、同時に使用されます。さらに、これらのチャネルは速度が対称ではない可能性があるため、状況は複雑です。たとえば、合計2 Gbpsのアップリンクが必要な場合、2つの異なるプロバイダー（1500 Mbpsと500 Mbps）から2つのチャネルが購入されます。この場合、BGPは冗長性の問題を完全に解決します。もちろん、ここには完全な準備金はありません。明らかに、加入者のサービスを低下させずに500メガビットで2ギガビットを予約することは不可能ですが、サービスの完全な障害は発生しません。また、PRNで拒否が発生しない場合（最大負荷の時間）、サービスはまったく影響を受けない可能性があります。

この状況では、冗長性ではなくバランスの問題が大幅に発生します。特に速度のチャンネルの非対称性のため。さらに、発信トラフィックのバランス調整（多かれ少なかれ制御できます）はそれほど重要ではありません。ただし、着信トラフィックを制御することははるかに困難です。

例として、次のスキームを考えます。

ネットワーク図

AS65000は、ISP＃1（AS65001）とISP＃2（AS65002）の2つのプロバイダーにそれぞれ1.5 Gbpsと500 Mbpsのチャネルで接続されています。ネットワーク内のサブスクライバーは、3つのローカルルーターR7、R8、およびR9の背後にあり、それぞれ3つのサブネットを使用しています。

172.16.7.0/24
172.16.8.0/24
172.16.9.0/24

3つのルーターが「グローバルインターネットリソース」として機能します。

R5（AS65050、10.0.5.0 / 24）-両方のプロバイダーに加入しています。
R10（AS65100、10.0.10.0 / 24）-ISP＃1のみに接続;
R11（AS65110、10.0.11.0 / 24）-ISP＃2にのみ接続されています。

プロバイダーにはピアツーピアジョイントがあります（R12とR13の間）。

ダウンロードがプロバイダーの収益に直接関連するクライアント接続とは異なり、ピアツーピア接続はプロバイダーに直接収入をもたらさないか、消費することさえできません。したがって、クライアント接続のBPG Local Preferenceを増やし、ピアのBPG Local Preferenceを減らすのが通常です。このスキームでは、ローカルプリファレンス値は赤いマーカーで示されます：両方のプロバイダーのピアリングの値は100（デフォルト）であり、クライアントとの接続では120に増加します。このオプションにより、プロバイダーはクライアントから同じBPGルートを受信できます別のプロバイダー、明示的にクライアント接続を好む。同時に、これは標準のBGPツールを使用したアップリンクバランシングの問題の原因の1つです。

バランス調整

すでに書いたように、発信トラフィックのバランス調整はほとんどのプロバイダーにとってそれほど重要ではないため、この記事のトピックは着信トラフィックの管理です。トラフィックを2つの非対称チャネルに分解する必要があります。

ISP＃1を介した1500 Mbps;
ISP＃2を介した500 Mbps

経験的に、必要な割合でトラフィックを「消費」する2つの範囲のIPアドレスを確立します。状況を簡単にするために（方法の原則はこれから変更されません）、R7およびR8ルーターの背後にあるサブスクライバーが合計着信トラフィックの約4分の3を消費し、残りの4分の1がR9ルーターのサブスクライバーに該当すると仮定します。この場合、BGPアナウンスメントを使用して、ネットワーク172.16.7.0/24および172.16.8.0/24のトラフィックがISP＃1を通過し、ネットワーク172.16.9.0/24のトラフィックがISP＃2を通過することを確認する必要があります。

2つのプレフィックスリストを作成し、チャネルごとにそれらのトラフィックを分離する方法を検討します。

ip prefix-list isp-1-out seq 5 permit 172.16.7.0/24 ip prefix-list isp-1-out seq 10 permit 172.16.8.0/24 ip prefix-list isp-2-out seq 5 permit 172.16.9.0/24

AS-PATH Prepend

この問題の標準的な解決策として、BGPはAS-PATH Prependメカニズムを提供します。その本質は、いくつかの可能なものから最適なルートを選択するときに、BGPプロトコルがAS-PATH属性の値を使用し、BGPアナウンスメントが通過したすべての自律システムの番号を順番にリストすることです。最短のAS-PATHルートが優先されます。 AS-PATH prependメソッドを使用すると、一部のルートの属性値を人為的に拡張できます。

このメソッドをネットワークに適用してみましょう。これを行うには、CSRに2つのルートマップを作成して使用します。

 route-map isp-1-out permit 10 match ip address prefix-list isp-1-out route-map isp-1-out permit 20 match ip address prefix-list isp-2-out set as-path prepend 65000 65000 65000 route-map isp-2-out permit 10 match ip address prefix-list isp-1-out set as-path prepend 65000 65000 65000 route-map isp-2-out permit 20 match ip address prefix-list isp-2-out router bgp 65000 address-family ipv4 neighbor 192.168.101.1 route-map isp-1-out out neighbor 192.168.103.3 route-map isp-2-out out

これで、ISP＃1に向けて、プレフィックス172.16.9.0/24が3つのAS65000番号によって拡張されたAS-PATHでアナウンスされ、ISP＃2に向けて、プレフィックス172.16.7.0/24および172.16.8.0/24に対して同じことが行われます。

これで、理想的には、プレフィックスの各グループのトラフィックはそのプロバイダーを経由し、アップリンクの1つが落ちた場合、prependを使用したアナウンスメントが機能し始めます。たとえば、ISP＃2がクラッシュした場合、172.16.9.0 / 24のトラフィックは中断されません。これは、AS-PATHが拡張されていても、全世界でISP＃1を通じてこのプレフィックスが表示されるためです。

この方法は機能しますが、ここではプロバイダーがクライアントとピアリングに使用するさまざまなローカル設定がゲームに干渉します。ルートを選択するとき、LOCAL PREFERENCE属性がAS-PATHよりも優先されるため、プリペンドは各プロバイダー内で役割を果たさず、トラフィックは常にクライアントチャネルを介してルーティングされます。ネットワークでは、この方法は両方のプロバイダーに接続されているため、AS65050でのみ機能します。

もっと詳しく見てみましょう。

実際、R5ではすべて問題ありません。

 R5#sh ip bgp ... * 172.16.7.0/24 192.168.45.4 0 65002 65000 65000 65000 65000 ? *> 192.168.25.2 0 65001 65000 ? * 172.16.8.0/24 192.168.45.4 0 65002 65000 65000 65000 65000 ? *> 192.168.25.2 0 65001 65000 ? *> 172.16.9.0/24 192.168.45.4 0 65002 65000 ? * 192.168.25.2 0 65001 65000 65000 65000 65000 ? R5#sh ip route ... 172.16.0.0/24 is subnetted, 3 subnets B 172.16.7.0 [20/0] via 192.168.25.2, 1d00h B 172.16.8.0 [20/0] via 192.168.25.2, 1d00h B 172.16.9.0 [20/0] via 192.168.45.4, 1d00h R5#traceroute 172.16.7.1 source 10.0.5.1 ... 1 192.168.25.2 0 msec 0 msec 1 msec 2 192.168.12.1 0 msec 1 msec 0 msec 3 192.168.101.100 3 msec 3 msec 3 msec 4 192.168.107.7 2 msec * 2 msec R5#traceroute 172.16.9.1 source 10.0.5.1 ... 1 192.168.45.4 1 msec 0 msec 1 msec 2 192.168.34.3 0 msec 1 msec 0 msec 3 192.168.103.100 3 msec 3 msec 3 msec 4 192.168.109.9 2 msec * 3 msec

AS-PATH属性に基づいて、プレフィックスの各グループに対して、プロバイダーを介して最適なルートが選択され、トレースが確認されます。

しかし、R11（AS65110）では、すべてがバラ色ではありません。

 R11#traceroute 172.16.7.1 source 10.0.11.1 ... 1 192.168.114.4 0 msec 1 msec 4 msec 2 192.168.34.3 1 msec 0 msec 0 msec 3 192.168.103.100 3 msec 3 msec 3 msec 4 192.168.107.7 2 msec * 2 msec R11#traceroute 172.16.9.1 source 10.0.11.1 ... 1 192.168.114.4 0 msec 1 msec 0 msec 2 192.168.34.3 0 msec 0 msec 0 msec 3 192.168.103.100 3 msec 2 msec 3 msec 4 192.168.109.9 2 msec * 2 msec

両方のホストへのトラフィックは、同じ5メガバイトのインターフェイスを介して送信されます。

その理由は、単に地元の好みです。 ISP＃2プロバイダーR13を確認します。

 R13>sh ip bgp ... * 172.16.7.0/24 192.168.200.12 0 65001 65000 ? *>i 192.168.103.100 0 120 0 65000 65000 65000 65000 ? * 172.16.8.0/24 192.168.200.12 0 65001 65000 ? *>i 192.168.103.100 0 120 0 65000 65000 65000 65000 ? * 172.16.9.0/24 192.168.200.12 0 65001 65000 65000 65000 65000 ? *>i 192.168.103.100 0 120 0 65000 ? R13#sh ip route ... 172.16.0.0/24 is subnetted, 3 subnets B 172.16.7.0 [200/0] via 192.168.103.100, 1d00h B 172.16.8.0 [200/0] via 192.168.103.100, 1d00h B 172.16.9.0 [200/0] via 192.168.103.100, 1d00h

ルーターでは、2つのコピーのネットワークのすべてのBGPアナウンスメント：

クライアント接続（next-hop 192.168.103.100）を介して受信。
ピアリングを介して受信（next-hop 192.168.200.12）。

ただし、AS-PATHが長いにもかかわらず、172.16.7.0 / 24および172.16.8.0/24のプレフィックスの場合、最適なルートはクライアントを介したローカルプリファレンス120のルートです。ピアリングではなく、私たちを通して。 ISP＃2は、加入者のすべてのトラフィックを500Mbpsチャネルを介して送信することがわかりました。そして、このプロバイダーが主要なコンテンツプロバイダー（VK.comなど）のデータセンターであることが判明した場合、これはチャネルの過負荷とサービスの問題につながります。

標準のAS-PATHプリペンドは役に立たないことがわかります。

お知らせの除外

トラフィックを分離する別の方法は、このプロバイダーを介してトラフィックを受信したくないプレフィックスをオペレーターへのBGPアナウンスから単に除外することです。

やってみましょう。

ルートマップの代わりに、各ネイバーにフィルタリングプレフィックスリストを設定します。

 router bgp 65000 address-family ipv4 neighbor 192.168.101.1 prefix-list isp-1-out out neighbor 192.168.103.3 prefix-list isp-2-out out

現在、このジャンクションを介してトラフィックを受信する必要があるルートのみが各プロバイダーにアナウンスされます。

 CSR#sh ip bgp neighbors 192.168.101.1 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.7.0/24 192.168.107.7 0 32768 ? *> 172.16.8.0/24 192.168.108.8 0 32768 ? Total number of prefixes 2 CSR#sh ip bgp neighbors 192.168.103.3 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.9.0/24 192.168.109.9 0 32768 ? Total number of prefixes 1

このアプローチでは、オペレーターは必要に応じてルーティングテーブルを作成します。

 R13>sh ip route ... 172.16.0.0/24 is subnetted, 3 subnets B 172.16.7.0 [20/0] via 192.168.200.12, 00:04:53 B 172.16.8.0 [20/0] via 192.168.200.12, 00:04:53 B 172.16.9.0 [200/0] via 192.168.103.100, 00:05:13

R11でのトレースは、さまざまなプロバイダーを通過します。

 R11#traceroute 172.16.7.1 source 10.0.11.1 ... 1 192.168.114.4 4 msec 4 msec 4 msec 2 192.168.134.13 1 msec 0 msec 1 msec 3 192.168.200.12 0 msec 1 msec 0 msec 4 192.168.121.1 0 msec 1 msec 1 msec 5 192.168.101.100 2 msec 4 msec 3 msec 6 192.168.107.7 2 msec * 2 msec R11#traceroute 172.16.9.1 source 10.0.11.1 ... 1 192.168.114.4 0 msec 4 msec 0 msec 2 192.168.34.3 0 msec 1 msec 0 msec 3 192.168.103.100 3 msec 3 msec 3 msec 4 192.168.109.9 2 msec * 2 msec

ただし、冗長性に問題があります。実際、ISP＃2が崩壊すると、172.16.9.0 / 24ネットワークからの加入者は、全世界がもはや彼らへのルートを「見ない」ため、サービスを失います。通常、これは予約のプレフィックスの集約を発表することで解決できます。たとえば、172.16.6.0から172.16.9.255の範囲のアドレスがある場合、プレフィックスを含む拡大されたサブネット172.16.6.0/23および172.16.8.0/23を両方のプロバイダーにさらにアナウンスできます。その後、プロバイダーの1つがクラッシュし、/ 24ルートの「特異性」がインターネット上で消失した場合、/ 23は依然として残り、サービスは1つのアップリンクでもすべてのサブスクライバーに対して機能します。しかし、この例では、これは不可能です。クライアントネットワークを1つまたは2つのプレフィックスに集約することはできません。もちろん、この例のネットワークは特別に選択されましたが、正確には、実際にはこのような状況との衝突により、メモを書くように促されました。

ご予約

着信トラフィックのバランスをとる問題を解決しました。冗長性を達成するために残っています。一般的な解決策は明確です。ピアの1つが落ちた場合、発信アナウンスメントのフィルターを、まだ生きているピアに変更します。これは、SSHまたはSNMPを介したスクリプトを使用して境界ルーターの設定を変更することにより、「外部」で実装できます。ただし、このノートの目的は、シスコのすべての組み込みツールを作成することです。

BGP条件付きアドバタイズメント

BGPネイバーフッドの状態に応じてBGPアナウンスメントを管理するオプションの1つはConditional Advertisementです 。これにより、BGPテーブル内の「制御」プレフィックスの有無に応じて、特定のプレフィックスをネイバーにアナウンスできます。

アナウンスされる必要がある、または逆にアナウンスから削除される必要があるプレフィックスは、特別なルートマップadvertise-mapによって決定されます。「制御」プレフィックスは、別のcondition-mapによって定義されます。これは、 exist-mapまたはnon-exist-mapとして宣言できます。最初の場合、advertise-mapからのプレフィックスは、BGPテーブルにexist-mapに対応するプレフィックスがある場合にのみアナウンスされます。 non-exist-mapの場合、逆のことが当てはまります。non-exist-mapがプレフィックスの空のリストを返す場合、advertise-mapプレフィックスがアナウンスされ、そうでない場合、アナウンスから除外されます。

この場合、non-exist-mapオプションが適切です。ここでのルートマップ設定には、いくつかの機能があります。

ルートマップには許可セクションのみを含める必要があります。
一致条件の各セクションには、プレフィックスリストを含める必要があります（as-pathまたはコミュニティでのみフィルターできません）。
prefix-listは「完全一致」、つまり leまたはgeパラメーターなし。
ネクストホップまたはインターフェースのフィルタリングはサポートされていません。

したがって、制御プレフィックスが必要です。プロバイダーが私たちに発表するものから何かを選択することができます（または条件付き広告を使用していることを伝え、焦点を当てることができるお知らせにプレフィックスを追加するように依頼することもできます）。ただし、ほとんどの場合（クライアントに他のプロバイダーがない場合）、フルビューではなく、親プロバイダーからデフォルトのプレフィックス0.0.0.0/0を取得します。コントロールとして使用します。また、あるプロバイダーのデフォルトを別のプロバイダーと区別するために、AS-PATHフィルターをnon-exist-mapに追加します。

プレフィックスリストと2つのas-path ACLを作成します。

 ip prefix-list default seq 5 permit 0.0.0.0/0 ip as-path access-list 1 permit ^65001.* ip as-path access-list 2 permit ^65002.*

2つの条件マップを追加します。それぞれの条件マップは、対応するISPへの接続が確立された場合にのみ空でないリストを返します。

 route-map isp-1-is-alive permit 10 match ip address prefix-list default match as-path 1 route-map isp-2-is-alive permit 10 match ip address prefix-list default match as-path 2

2つのルートマップを作成します。これは、対応するピアのアドバタイズマップになります。

 route-map isp-1-adv permit 10 match ip address prefix-list isp-2-out route-map isp-2-adv permit 10 match ip address prefix-list isp-1-out

別のルートマップを使用して、すべての発信アナウンスをフィルタリングします。

 route-map full-out permit 10 match ip address prefix-list isp-1-out isp-2-out

次に、BGPネイバーの構成にそれらを適用します。

 router bgp 65000 address-family ipv4 neighbor 192.168.101.1 advertise-map isp-1-adv non-exist-map isp-2-is-alive neighbor 192.168.101.1 route-map full-out out neighbor 192.168.103.3 advertise-map isp-2-adv non-exist-map isp-1-is-alive neighbor 192.168.103.3 route-map full-out out

ネイバー192.168.103.3の構成をさらに詳しく検討します。

アナウンスのプレフィックスはroute-map full-outによって選択されます。
non-exist-map isp-1-is-aliveがさらにチェックされます：
- isp-1-is-aliveが空でないリストを返した場合、ステータスwithdrawが advertise-map isp-1-advに割り当てられ、そのプレフィックスがアナウンスから除外されます。
- isp-1-is-aliveが空のリストを返した場合、advertise-map isp-1-advにadvertiseが割り当てられ、そのプレフィックスがアナウンスされます。

何が起こったのか見てみましょう。最初は、両方の非存在マップの「制御」プレフィックスはBGPテーブルにあり、対応するアドバタイズマップは撤回ステータスにあります。

 CSR#sh ip bgp neighbors 192.168.101.1 | i Condition Condition-map isp-2-is-alive, Advertise-map isp-1-adv, status: Withdraw CSR#sh ip bgp neighbors 192.168.103.3 | i Condition Condition-map isp-1-is-alive, Advertise-map isp-2-adv, status: Withdraw

両方のプロバイダーは「生きている」ので、プレフィックスの一部のみがそれぞれの方向にアナウンスされます：

 CSR#sh ip bgp neighbors 192.168.101.1 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.7.0/24 192.168.107.7 0 32768 i *> 172.16.8.0/24 192.168.108.8 0 32768 i Total number of prefixes 2 CSR#sh ip bgp neighbors 192.168.103.3 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.9.0/24 192.168.109.9 0 32768 i Total number of prefixes 1

ISP＃1でBGPネイバーフッドを無効にする場合、ルートマップisp-1-is-aliveのプレフィックスはBGPテーブルから消え、ISP＃2のadvertise-map isp-2-advはステータスをアドバタイズします。

 CSR#sh ip bgp neighbors 192.168.103.3 | i Condition Condition-map isp-1-is-alive, Advertise-map isp-2-adv, status: Advertise

これで、ルートマップisp-2-advプレフィックスはアナウンスから除外されなくなり、ISP＃2に向けて、プレフィックスの完全なセットがアナウンスされます。

 CSR#sh ip bgp neighbors 192.168.103.3 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.7.0/24 192.168.107.7 0 32768 i *> 172.16.8.0/24 192.168.108.8 0 32768 i *> 172.16.9.0/24 192.168.109.9 0 32768 i Total number of prefixes 3

BGPネイバーフッドを復元すると、advertise-mapのステータスはwithdrawに戻り、プレフィックスはバランシングのためにプロバイダー間で再び配布されます。

条件付きアドバタイズメントを使用する別のオプションは、問題をプロバイダーの側に、またはその責任範囲を超えて特定することです。テスト回路の場合、AS65110には大規模なコンテンツプロバイダーの中心があり、加入者にとってアクセスが重要であることが想像できます。 2つのプロバイダー間のピアリング接続が低下した場合、プレフィックスがISP＃1にのみアナウンスされるサブスクライバーの一部は、AS65110へのアクセスを失います。同時に、プロバイダーとの接続があり、そこからプレフィックスとデフォルトがありますが、サブスクライバーサービスが低下します。この場合、AS65110で重要なリソースのアドレスを使用するための「制御」プレフィックスとしてのみ、上記と同様の構成を使用できます。

Cisco Embedded Event Manager

以下に説明する方法は、BGP条件付きアドバタイズメントの機能を考えると、そのような単純なタスクを解決するために少し人工的に見えます。 この理由は、Cisco EEMについての話がメモを書く目的であったため、記事の元のバージョンでは唯一の記事であったためです。 さらに、バランスの問題は、図の最も単純で理解可能なバージョンとして選択されました。 しかし、後でコメントの中で、彼らは私に、BGPアナウンスメントの管理の問題について、この目的のために設計されていないツールに言及せずに説明していることを正しく指摘しました。 そのため、BGP条件付きアドバタイズメントに関する記事が登場しましたが、Cisco EEMの使用は面倒で冗長なようです。 ただし、これは非常に強力なツールであり、膨大な分野のアプリケーションを使用しているので、知る価値はあります。

着信トラフィックのバランスをとる問題を解決しました。冗長性を達成するために残っています。一般的な解決策は理解できます。ピアの1つが落ちた場合、発信アナウンスメントのフィルターを、まだ生きているピアに変更します。これは、SSHまたはSNMPを介したスクリプトを使用して境界ルーターの設定を変更することにより、「外部」で実装できます。ただし、このノートの目的は、シスコのすべての組み込みツールを作成することです。

これは、 Cisco Embedded Event Manager（EEM）エンジンが役立つ場所です。これは、ルーターを管理し、ネットワーク上の問題をトラブルシューティングするための非常に柔軟なメカニズムです。その機能は、説明したタスクの範囲をはるかに超えています。特定のイベント（BGP近隣のフォールまたは復元）の発生をキャッチし、特定のコマンドセットを実行する彼の能力が必要です。

最初に、すべてのプレフィックスを含むプレフィックスリストを作成します。

 ip prefix-list full-out seq 5 permit 172.16.7.0/24 ip prefix-list full-out seq 10 permit 172.16.8.0/24 ip prefix-list full-out seq 15 permit 172.16.9.0/24

次に、EEMアプレットを設定します。これは、BGPネイバーフッドのステータスの変化に関するレコードがログに表示されたときに起動されます（正規表現によって定義されます）。アプレット：

ログ内のメッセージを解析し、以下を決定します。
- メッセージをトリガーしたBGPネイバーのルーターID、
- 彼のステータス。
IPアドレスとステータスに応じて、1つまたは別のプレフィックスリストを別のBGPネイバーに適用します。
ルーティング情報の配布と加えられた変更の適用を加速するために、「ソフトに」2番目のネイバーへのアナウンスをリセットします。

アプレット構成：

 event manager applet isp event syslog pattern "neighbor 192.168.10[13].[13] (Up|Down|reset)" action 01.0 regexp "(192.168.10[13].[13])" "$_syslog_msg" _match _ip action 02.0 if $_ip eq "192.168.101.1" action 03.0 set _name "ISP #1" action 04.0 set _target_ip "192.168.103.3" action 05.0 set _list "isp-2-out" action 06.0 elseif $_ip eq "192.168.103.3" action 07.0 set _name "ISP #2" action 08.0 set _target_ip "192.168.101.1" action 09.0 set _list "isp-1-out" action 10.0 else action 11.0 exit action 12.0 end action 13.0 regexp "(Up|Down|reset)" "$_syslog_msg" _match _state action 14.0 if $_state eq "Up" action 15.0 set _status "UP" action 16.0 else action 17.0 set _status "DOWN" action 18.0 set _list "full-list" action 19.0 end action 20.0 syslog priority warnings msg "$_name now is $_status !" action 21.0 syslog priority warnings msg "Applying prefix list '$_list' to the neighbor $_target_ip" action 22.0 cli command "enable" action 23.0 cli command "configure terminal" action 24.0 cli command "router bgp 65000" action 25.0 cli command "address-family ipv4" action 26.0 cli command "neighbor $_target_ip prefix-list $_list out" action 27.0 cli command "end" action 28.0 syslog priority warnings msg "Soft clear BGP session $_target_ip" action 29.0 cli command "clear ip bgp $_target_ip soft out"

最初は、両方のBGPセッションがアクティブで、アナウンスは次のようになります。

 CSR#show ip bgp summary ... Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.101.1 4 65001 8 5 7 0 0 00:00:19 3 192.168.103.3 4 65002 8 5 7 0 0 00:00:24 3 CSR#show ip bgp neighbors 192.168.101.1 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.7.0/24 192.168.107.7 0 32768 ? *> 172.16.8.0/24 192.168.108.8 0 32768 ? Total number of prefixes 2 CSR#show ip bgp neighbors 192.168.103.3 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.9.0/24 192.168.109.9 0 32768 ? Total number of prefixes 1

ISP＃2ネットワークでの発表は次のとおりです。

 R13>show ip bgp ... Network Next Hop Metric LocPrf Weight Path *> 172.16.7.0/24 192.168.200.12 0 65001 65000 ? *> 172.16.8.0/24 192.168.200.12 0 65001 65000 ? *>i 172.16.9.0/24 192.168.103.100 0 120 0 65000 ?

R11を使用したトレースは、必要に応じてネットワークに送られます。

 R11#traceroute 172.16.7.1 source 10.0.11.1 Type escape sequence to abort. Tracing the route to 172.16.7.1 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.114.4 0 msec 1 msec 0 msec 2 192.168.134.13 0 msec 0 msec 1 msec 3 192.168.200.12 0 msec 0 msec 1 msec 4 192.168.121.1 1 msec 1 msec 1 msec 5 192.168.101.100 3 msec 3 msec 3 msec 6 192.168.107.7 2 msec * 3 msec R11#traceroute 172.16.9.1 source 10.0.11.1 Type escape sequence to abort. Tracing the route to 172.16.9.1 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.114.4 1 msec 0 msec 1 msec 2 192.168.34.3 0 msec 1 msec 0 msec 3 192.168.103.100 3 msec 3 msec 3 msec 4 192.168.109.9 2 msec * 2 msec

次に、プロバイダーからISP＃1ピアを無効にしましょう。その結果、境界上のBGPセッションの1つがIDLEに移動します。

 CSR#show ip bgp summary ... Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.101.1 4 65001 0 0 1 0 0 00:00:10 Idle 192.168.103.3 4 65002 26 26 9 0 0 00:16:31 3

同時に、イベント％BGP-5-NBR_RESET：Neighbor 192.168.101.1 reset（Peer closed the session）が発生するとすぐに、アプレットが機能し、プレフィックスリストを変更したことがログに表示されます。

 *Jul 20 09:00:58.208: %BGP-5-NBR_RESET: Neighbor 192.168.101.1 reset (Peer closed the session) *Jul 20 09:00:58.208: %BGP-5-ADJCHANGE: neighbor 192.168.101.1 Down Peer closed the session *Jul 20 09:00:58.214: %HA_EM-4-LOG: isp: ISP #1 now is DOWN ! *Jul 20 09:00:58.214: %HA_EM-4-LOG: isp: Applying prefix list 'full-list' to the neighbor 192.168.103.3 *Jul 20 09:00:58.778: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:isp) *Jul 20 09:00:58.879: %HA_EM-4-LOG: isp: Soft clear BGP session 192.168.103.3

ISP＃2に向けて現在発表しているものを見てみましょう。

 CSR#show ip bgp neighbors 192.168.103.3 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 172.16.7.0/24 192.168.107.7 0 32768 ? *> 172.16.8.0/24 192.168.108.8 0 32768 ? *> 172.16.9.0/24 192.168.109.9 0 32768 ? Total number of prefixes 3

つまり現在、ISP＃2を通じてすべてのプレフィックスを発表しています。 R13での表示は次のとおりです。

 R13>show ip bgp ... Network Next Hop Metric LocPrf Weight Path *>i 172.16.7.0/24 192.168.103.100 0 120 0 65000 ? *>i 172.16.8.0/24 192.168.103.100 0 120 0 65000 ? *>i 172.16.9.0/24 192.168.103.100 0 120 0 65000 ?

そして、ネットワーク内のすべてのトレースは1つのプロバイダーを通過します。

IPS＃1でBGPセッションを復元すると、アプレットは再びISP＃2のプレフィックスリストを元の位置に戻します。

おわりに

この記事の目的は、いくつかのアップリンクのバランスを取りながら着信トラフィックを管理するためのCisco EEMの使用を簡単に検討することでした。もちろん、この方法は最適とは言えません。むしろ、それは「額」のソリューションです。ただし、それは機能し、ある程度のフォールトトレランスを提供します。メモを書くために、回路全体がCisco IOLおよびCisco CSRv1000イメージ上のUNELABで組み立てられました。この例のすべてのデバイスの構成は、ここからダウンロードできます。

BGPとEEMに基づいた2つのプロバイダーのバランス