Cisco 300-410: BGPのポリシー、スケーラビリティ、経路選択 — 学習ガイド
こちらの一部です: Cisco CCNP Enterprise 300-410 ENARSI — 学習ガイド. 検証済みの解答で練習: Cisco試験ハブ, または時間制限付き模擬試験に挑戦: ExamRoll.io.
概要
Border Gateway Protocol (BGP)は、AS間のルーティングポリシーを制御し、スケーラブルな到達可能性情報の配布を管理します。耐障害性の高いセッションの設計、ネクストホップとアップデートの動作の理解、そしてベストパスアルゴリズムを完全に意識したポリシーの適用は、基本となります。大規模環境では、iBGPはルートリフレクタやコンフェデレーションに依存します。一方、conditional advertisement、default-origination、multipath、dampeningなどの高度なツールが動作を調整します。このセクションでは、運用メカニズム、設計上のトレードオフ、予測すべき障害モードを詳述し、プレフィックスの欠落と予期しないパス選択の両方に対する体系的なトラブルシューティングアプローチを提供します。
セッション設計とネイバー確立
- eBGP vs. iBGP隣接関係
- eBGPピアは異なるASNに属し、デフォルトでTTL 1を使用するため、別途設定しない限りシングルホップの隣接関係が必要です。
- iBGPピアは同じASNに属し、フルメッシュまたはスケーリングのための代替策(ルートリフレクタやコンフェデレーション)が必要です。iBGPはTTL 255を使用し、セッションは安定性のためにループバックインターフェースを頻繁に使用します。
- TCP到達可能性とBGP FSM
- BGPはTCPポート179上で動作します。セッションの確立は、一般的なIP/TCPの到達可能性とBGPの有限状態マシン(Idle → Connect/Active → OpenSent → OpenConfirm → Established)に依存します。
- 一般的な阻害要因:TCP/179に対するACL/ファイアウォール、BGPをレートリミットするControl-Plane Policing (CoPP)、TCPを破壊する非対称ルーティング。
- 実践的な確認:show ip bgp summaryを実行し、フラッピングしている場合はshow policy-map control-planeを調査してCoPPを検証します。ポリシー検証中は、意図しないドロップを避けるためにconform/exceedアクションをtransmitに設定します。
- 認証とTTLの強化
- MD5認証(neighbor x password y)は、なりすましセッションから保護します。不一致があるとセッションはActive状態に留まります。
- GTSM/TTLセキュリティ(neighbor x ttl-security hops n)は、CPUベースの攻撃を緩和します。同じネイバーでebgp-multihopと組み合わせないでください。
- ループバックピアリング、update-source、およびmultihop
ループバック間のピアリングはインターフェース障害に対してより耐障害性が高くなります。送信元の一意化とTTLの拡張が必要です:
undefined
-
undefined
- 静的ルートまたはIGPを介してループバックへのユニキャスト到達可能性を確保してください。ループバックへの再帰的な経路解決ができない場合、セッションは警告なく確立されません。
- ネクストホップ処理とnext-hop-self
- eBGPはデフォルトで、アドバタイズ元のネイバーをネクストホップに設定します。
iBGPはデフォルトではネクストホップを変更しません。エッジルーターは、サードパーティのネクストホップによるブラックホールを避けるために、iBGPでnext-hop-selfを設定する必要があります。
undefined
undefined
ネクストホップ処理とベストパス選択
CiscoプラットフォームにおけるBGPベストパス選択(優先度の高い順):
- Weight(Cisco独自、ルーターローカル。値が大きい方を優先)。デフォルト:ローカルで生成されたルートは32768、その他は0。
- Local Preference(AS内。値が大きい方を優先)。デフォルトは100。iBGP内で伝播されます。
- 学習したルートよりも、ローカルで生成されたルート(network/aggregate/redistribute)を優先。
- AS-path長(短い方を優先)。プリペンドは認識される距離を増加させます。
- Originコード(IGP < EGP < Incomplete)。
- MED(値が小さい方を優先)。bgp always-compare-medが有効でない限り、同じネイバーASからのパス間でのみ比較されます。bgp deterministic-medは、ピア間での一貫したMED比較を保証します。
- iBGPよりもeBGPを優先。
- BGPネクストホップへのIGPメトリックが最も低いパス(ホットポテト)。
- 最も古いルートを優先してチャーンを削減(有効な場合、ダンピング/マルチパスの影響を受ける)。
- タイブレーカー:最小のcluster-list長、最小のoriginator-ID、最小のネイバーBGPルーターID、そして最後に最小のネイバーIPアドレス。
設計上の注意点と落とし穴:
- ネクストホップの到達可能性は基本です。あるパスがBGPでベストパスに選ばれても、ネクストホップが解決できなければCEFの再帰検索に失敗します。
- eBGPから学習したルートをiBGPにアドバタイズする際は、next-hop-selfを忘れないでください。さもないと、iBGPルーターが到達不能なeBGPネクストホップを参照し、トラフィックをドロップする可能性があります。
- MEDはしばしば誤解されます。always-compare-medがないと、異なるネイバーAS間のMEDは評価されず、値が「無視」されているように見える原因となります。
ポリシーツール: アトリビュート、コミュニティ、フィルタリング
- Local Preference、Weight、AS-path prepending、MED
- 低遅延のISPを優先するには、それらの経路のLOCAL_PREFを上げます(例:
set local-preference 200)。これにより、IPデータプレーンに触れることなく、AS全体のアウトバウンドトラフィック選択が変更されます。 - Weightはローカルのみです。ルーター固有の優先設定に使用します(
neighbor 198.51.100.1 weight 50またはroute-map経由のset weight)。 - AS-path prepending(
set as-path prepend 65000 65000 …)は、見かけ上の距離を増やすことで、自ASへのインバウンドパスの魅力を下げます。選択的に適用してください。使いすぎると到達可能性が低下します。 - MED(
set metric)は、ネイバーに対して、自ASへの出口(egress)を提案します。その効果はネイバーのポリシーに依存します。
- 低遅延のISPを優先するには、それらの経路のLOCAL_PREFを上げます(例:
- コミュニティポリシー
- コミュニティの送信は自動ではありません。
neighbor x send-community [both | extended]で有効にします。 - well-knownコミュニティ:
no-export、no-advertise、internet、local-AS、およびno-export-subconfed(コンフェデレーションで有用)。 - 標準コミュニティは32ビットの値です(
ip bgp community new-formatを使用したAA:NN形式)。 - 拡張コミュニティ(64ビット)は、追加のセマンティクス(意味情報)を伝達します(例: VPNv4におけるルートターゲット)。
- ラージコミュニティ(96ビット、A:B:C)は、4バイトASNにおいてスケーラビリティと明確さを提供します。
- 例: コミュニティにマッチさせ、アトリビュートを設定する
ip community-list standard PREFERED permit 65000:100route-map INBOUND-POLICY permit 10match community PREFEREDset local-preference 200
- コミュニティの送信は自動ではありません。
- プレフィックスとAS-pathのフィルタリング
ip prefix-listはNLRIの粒度を制御します。as-path access-listは正規表現(regex)を使用してASパスを制約します。どちらもroute-mapで、またはneighbor … prefix-list/as-path access-groupで直接アタッチされます。- インバウンド vs. アウトバウンド:
- インバウンドフィルタリングは、BGPテーブルに入る経路を形成し、最適パスの選択に影響を与えます。
- アウトバウンドフィルタリングは、何を広告するかを制御します。不適切に適用されたアウトバウンドのroute-mapは、ローカルで生成された経路のアトリビュートを予期せず変更する可能性があります(例: すべての広告にローカルASをプリペンドすると、外部ネイバーはあなたのプレフィックスを1ASホップ先ではなく2ASホップ先として認識します)。route-mapは常に明示的なmatch条件で制約してください。
- 最小限のターゲットを絞ったポリシーは、チャーンを減らし、ブラックホール化を回避します。意図しない拒否を避けるため、prefix-listの最後には必ずpermitを含めてください。
短く、的を絞った設定例:
- ISP-Aからの経路に対してlocal preferenceを上げる:
route-map SET-LP permit 10set local-preference 200neighbor 203.0.113.1 route-map SET-LP in
- 特定のアウトバウンド広告に対するAS-path prepend:
ip prefix-list OUT-ONLY permit 192.0.2.0/24route-map PREPEND permit 10match ip address prefix-list OUT-ONLYset as-path prepend 65000 65000neighbor 198.51.100.1 route-map PREPEND out
iBGPのスケーリングと高度な動作
- ルートリフレクタ (RR)
- クライアントと非クライアント間でルートをリフレクト(反射)するRRを指定することで、iBGPフルメッシュを置き換えます。ループはoriginator-IDとcluster-list属性によって防止されます。
- クラスタIDはデフォルトでRRのルータIDになります。複数のRRが存在する場合は、永続的なループを防ぎ、パスの多様性を向上させるために、一意のクラスタIDを使用します。
- トレードオフ: RRは最適でないパス選択(パスハイディング)を引き起こす可能性があります。クライアントの配置、多様なクラスタ、add-path、およびbestpathの調整によって緩和します。
- コンフェデレーション
- 大規模なASをサブASに分割します。サブAS間では内部的にeBGPを話しますが、外部からは単一のASとして見えます。
- 長所: iBGPメッシュとポリシーの影響範囲を削減します。短所: 運用が複雑になり、サブASの境界を越える際にMED/ネクストホップの扱いに微妙な差異が生じる可能性があります。
- 条件付き広告とデフォルトルート
条件付き広告を使用すると、他の特定のルートが存在しない/存在する場合にのみ、ルートを広告できます。
undefined
undefined
undefined
undefined
undefined
undefined
- デフォルトルートの生成:
neighbor 198.51.100.1 default-originate [route-map RM]は、RIBに0.0.0.0/0が存在するかどうかに関わらず、それを広告します(RMで条件を制御)。一方、network 0.0.0.0は、RIB内に一致するルートが存在する必要があります。
- マルチパス
maximum-paths [ebgp|ibgp] nを使用して、複数の等コストBGPパスにわたって負荷分散します。bgp bestpath as-path multipath-relaxを使用すると、制御された条件下で、異なるASパスを持つeBGPマルチパスを許可できます。MPLS L3VPNでは、maximum-paths ibgp nによりPE-to-PEのECMPが可能になります。
- ルート再帰とRIB障害
- BGPは、ネクストホップが有効なフォワーディングエントリに再帰的に解決でき、かつ、より低いアドミニストレーティブディスタンスを持つルートがそのプレフィックスを既に所有していない場合にのみ、パスをインストールします。
- 一般的なRIB障害の原因:
- より優れたADを持つルートが存在する(connected/static/IGP)。
- ネクストホップが未解決(ネクストホップへのIGP/スタティックルートがない)。
- より長く、より具体的なルートが存在する(トラフィックはより具体的なルートにマッチする)。
- 役立つ確認コマンド:
show ip bgp <prefix>,show ip bgp rib-failure,show ip route [vrf NAME] <prefix>、および再帰検証のためのCEFルックアップ。
- ダンピング
bgp dampeningは、フラッピングするプレフィックスにペナルティを課し、安定するまでそれを抑制します。パラメータには、half-life、reuse、suppress、max-suppress-timeがあります。- トレードオフ: 正当な回復を隠蔽し、収束を遅らせる可能性があります。不安定なエッジに限定して適用し、コアの到達可能性や顧客の重要なプレフィックス空間へのダンピングは避けてください。
体系的なトラブルシューティング(プレフィックスの欠落と不正なパス):
- BGPセッションの健全性を確認:
show ip bgp summary。フラッピングしている場合は、CoPPとTCP/179への到達可能性を調査します。 - ポリシーによる受け入れを確認:
show ip bgp neighbors x received-routes/advertised-routes。必要に応じて、ソフトリコンフィグレーションまたはルートリフレッシュを確保します。 - ネクストホップを検証:
show ip bgp <prefix>とshow ip route [vrf NAME] <next-hop>。属性を調整する前に、IGP/再帰の問題を修正します。 - フィルタを確認: プレフィックスリスト、as-pathアクセスリスト、コミュニティ。
neighbor send-communityを確認します。 - 属性を調査: weight/local-pref/AS-path/origin/MED。適切な場合は、deterministic/always-compare MEDを有効にします。
- RIB障害と具体性を調査: ADが低いconnected/static/IGPルート、またはより具体的なルートは、BGPを上書きします。
- スケール機構を確認: RRでは、パスハイディングとcluster-listループに注意します。コンフェデレーションでは、
no-export-subconfedの使用を検証します。
実践的な問題シナリオ
Acme Manufacturing社はAS 65010を運用しており、2つのISP(ISP-A(低遅延)とISP-B(バックアップ))を利用しています。Acme社は3台のコアルータでiBGPを実行し、2台のルートリフレクタを使用しており、203.0.113.0/24を広告しています。ISP-Bのエッジでアウトバウンドのルートマップを追加した後、リモートサイトから遅延の増加が報告され、一部のパスが予期せずISP-Bを優先するようになりました。
アプローチ:
セッションとポリシーの健全性を確認
show ip bgp summaryとshow policy-map control-planeを実行し、CoPPによるBGPのフラップがないことを確認します。根拠: 不安定なコントロールプレーンは、ポリシーの効果を覆い隠すような頻繁な変動(チャーン)を生み出します。
ネクストホップへの到達可能性を検証
show ip bgp 203.0.113.0/24とshow ip route <next-hop>を実行します。根拠: 属性が意味を持つ前に、ネクストホップの再帰が成功しなければなりません。
ISP-Bのアウトバウンドポリシーを調査
show run | sec router bgpを実行し、neighbor … route-map OUT outをレビューします。根拠: 広範なルートマップは、ローカルで生成されたプレフィックスを含む、広告されるすべてのプレフィックスを意図せず変更してしまう可能性があります。
AS-pathプリペンドを対象のNLRIに限定
undefined
undefined
undefined
undefined
undefined
undefined
根拠: 具体的なマッチングにより、プリペンドを意図したプレフィックスに限定し、他の広告の属性を変更することを回避します。明示的な permit 20 は、マッチしなかったルートが破棄されないことを保証します。
アウトバウンドトラフィックでグローバルにISP-Aを優先
undefined
undefined
undefined
根拠: LOCAL_PREFはAS全体での出力パスの選択に影響を与え(値が高いほど優先)、低遅延のISPを優先するための最もクリーンな手段です。
コミュニティが意図した動作を伝播することを確認
undefined
undefined
undefined
undefined
undefined
根拠: タグ付けにより、下流でのポリシー決定(例: RRベースの優先制御)が可能になり、その伝播には send-community が必要です。
RRの動作を検証し、パスハイディングを回避
- 両方のRRで、一意のクラスタIDとクライアントの割り当てを確認します。サポートされている場合は
bgp additional-paths send receive select best 2を有効にします。 根拠: 複数の出口を持つ環境では、RRがより良いパスを隠してしまう可能性があります。Additional-pathsや慎重なクライアントトポロジの設計により、最適でない状態を軽減できます。
- 両方のRRで、一意のクラスタIDとクライアントの割り当てを確認します。サポートされている場合は
結果とインストール状態を検証
show ip bgp 203.0.113.0/24を実行して、weight/local-pref/AS-path/MEDを確認します。iBGPよりもeBGPが選択されること、およびネクストホップへのIGPメトリックを確認します。show ip bgp rib-failureを実行して、選択されたパスがRIBにインストールされることを確認します。 根拠: コントロールプレーンとデータプレーンの両方が意図した設計を反映していることを確認します。
この一連の手順により、意図しないAS-pathの変更が修正され(外部ASがAcmeのプレフィックスを望ましい距離で認識するように保証)、LOCAL_PREFを介してISP-Aの優先が強制され、コミュニティによってポリシーの可視性が維持され、ネクストホップとインストールが検証されることで、最終的なフォワーディングが設計と一致するようになります。
← EIGRPの設計、メトリック、収束 · すべてのドメイン · 経路再配送とポリシーベースルーティング →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →