OSPF/IS-ISおよびBGPルーティングのためのCisco IOS XR導入のベストプラクティス 

 

内容

[UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 3

[UPDATE THE TABLE] 3

[UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE] 5

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 7

[UPDATE THE TABLE][UPDATE THE TABLE] 7

[UPDATE THE TABLE] 8

[UPDATE THE TABLE] 9

[UPDATE THE TABLE][UPDATE THE TABLE] 9

[UPDATE THE TABLE][UPDATE THE TABLE] 10

[UPDATE THE TABLE][UPDATE THE TABLE] 11

[UPDATE THE TABLE] 12

[UPDATE THE TABLE][UPDATE THE TABLE] 12

[UPDATE THE TABLE][UPDATE THE TABLE] 14

[UPDATE THE TABLE][UPDATE THE TABLE] 14

[UPDATE THE TABLE][UPDATE THE TABLE] 17

[UPDATE THE TABLE][UPDATE THE TABLE] 18

[UPDATE THE TABLE] 19

免責事項  

このドキュメントでは、OSPF/IS-ISおよびBGPルーティングに関して確立されているベストプラクティスの推奨事項の概要を示します。これらの推奨事項はシスコ検証済みデザインを表すものではなく、特定の運用環境への導入には十分な注意と注意が必要です。これらのベストプラクティスの推奨事項を実装する方法を詳細に説明した関連製品の設定ガイドおよび技術文書と併せてお読みください。 このドキュメントでは、特定の製品の設定ガイドおよびテクニカルドキュメントへの参照は、例としてのみ提供されています。特定の製品の設定ガイドとテクニカルドキュメントを参照してください。

はじめに  

このドキュメントでは、IOS XRルーティングプラットフォームを使用して、簡素化された効率的でスケーラブルなネットワークを構築するための、確立されたベストプラクティスと推奨事項について説明します。このドキュメントでは、OSPF/IS-ISおよびBGPの展開をカスタマイズするためにIOS XRで使用できる特定の実装技術と機能サポートオプションに焦点を当てています。 

OSPFの実装  

RFC 2328で定義されているOSPFプロトコルは、単一の自律システム内でルーティング情報を配布するために使用されるIGPです。OSPFは他のプロトコルに比べていくつかの利点がありますが、スケーラブルでフォールトトレラントなネットワークを作成するには適切な設計が必要です。  

OSPFの詳細については、次を参照してください。 

■ OSPFのテクニカルノート：
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html#anc13 

■ OSPFの設定ガイド：https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-6/routing/configuration/guide/b-routing-cg-asr9000-76x/implementing-ospf.html 

■ コマンドリファレンス： https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/711x/routing/configuration/guide/b-routing-cg-asr9000-711x/implementing-ospf.html?dtid=osscdc000283

主要概念 

■階層：階層型ネットワークモデルは、信頼性の高いネットワークインフラストラクチャを設計するための有用な高レベルツールであり、複雑なネットワーク設計問題を、より小規模で管理可能なエリアに分割するのに役立ちます。  

■モジュール性：ネットワーク上のさまざまな機能をモジュールに分割することで、ネットワークの設計が容易になります。シスコは、エンタープライズキャンパス、サービスブロック、データセンター、インターネットエッジなど、いくつかのモジュールを特定しています。  

■復元力：ネットワークは正常な状態と異常な状態の両方で利用できます。通常の状態には、予想されるトラフィックフロー、パターン、およびメンテナンス時間帯などのスケジュールされたイベントが含まれます。異常な状態には、ハードウェアまたはソフトウェアの障害、過剰なトラフィック負荷、異常なトラフィックパターン、サービス拒否(DoS)イベント、その他の計画的または予期しないイベントが含まれます。   

■柔軟性：大規模なフォークリフトアップグレード（つまり、主要なハードウェアデバイスの交換）を行うことなく、ネットワークの一部の変更、新しいサービスの追加、または容量の増加を行う機能。 

一般的なベストプラクティスとして、ネットワークの「スパン」を考慮して、特定の境界内のルートと、ドメイン内のルータが転送に必要とする関連ルートを含める必要があります。OSPFエリアを効果的に使用すると、ネットワークを介して送信されるリンクステートアドバタイズメント(LSA)およびその他のオーバーヘッドトラフィックの数を削減できます。階層を作成する利点の1つは、このアプローチによって、各ルータが維持する必要があるトポロジデータベースのサイズを管理しやすく、ルータのメモリプロファイルに確実に準拠できることです。   

OSPFドメインとBGPの再配布 

OSPFは、数千のルートだけを伝送するように設計されています。OSPFの「エリア」とは、ネットワークの各セクションであり、すべてのルータがエリア内の他のすべてのルータのルーティング機能を認識します。これにより、デバイスに問題が発生した場合に高速コンバージェンスが可能になりますが、拡張性は低下します。そのため、OSPFはサービスプロバイダーのコアで使用され、すべてのコアデバイス間に基本レベルの接続を提供し、すべてのコアデバイスは同じOSPFエリア内に設定されます。    

これに対し、BGPは、OSPFなどのほとんどのIGPよりもはるかに多くのルートを伝送するように設計されています。OSPFなどのIGPへのBGPルートの再配布に関連するリスク。サービスプロバイダーが、BGPルートを何らかのユースケースのためにIGPドメインに再配布する必要がある場合、このルートは、自律システム境界ルータ(ASBR)での適切なフィルタリングおよび受信ルータで設定されたオーバーロード保護によって、サービスプロバイダーによって管理される必要があります。BGP再配布がOSPFにフィルタリングされていない場合、ASBR内のすべてのOSPFデバイスは、同時に処理できるキャパシティをはるかに超えたルートの受信を開始します。たとえば、Cisco IOS XRルータでは、デフォルトで10,000のBGPルートしかOSPFに再配布できません。BGPルートがIGPに再配布される場合、IGPドメイン内のすべてのルータが、IGPの設計に応じてこれらのルートを受信する可能性があります。OSPFプロトコルのRFCに従って、OSPFに再配布される外部ルートは、OSPFエリア内のすべてのルータに配布される必要があります。   

IGPへの再配布の管理  

一般的なベストプラクティスとして、再配布は、再配布ファンクションが提供する到達可能性のルートを学習する他のオプションがない場合に限り、慎重かつ計画的に行う必要があります。  

一般的に、次の手順を実行する必要があります。 

■ 再配布の回避  

■ IGPドメインでのルート伝送の回避 

■ 外部到達可能性のためのBGPの実装  

■ IGPを使用してネクストホップ情報のみを伝送する（Loopback 0など）  

OSPFルート再配布の制限事項  

BGPからOSPFに再配布されるプレフィックスのスケールは、オーバーロード保護(max-lsa)設定で管理されます。これは、多数のルートがOSPFドメインにリークするのを防ぐ唯一の保護です。単一のOSPFエリアに再配布する場合は、ルート再配布に対して複数の保護レイヤを実装する必要があります。 

ルート再配布に対する保護に使用できるオプションの一部を次に示します。 

■ ACLを使用した再配布フィルタリング   

■ 再配布の制限 – グローバル設定で、特定の数を超えるルートが再配布されないようにします。フィルタを削除した場合、グローバル再配布の制限が2番目の防衛線になり、コアが保護されます。 

■ OSPFエリア内のすべてのデバイスのMax-LSA設定：上記の項目で説明されている保護が失敗した場合、受信側ルータに過剰な着信LSAを拒否するように強制します。

OSPFリンクステートデータベース過負荷保護  

OSPFリンクステートデータベース過負荷保護機能は、特定のOSPFプロセスに対して自己生成されないLSAの数を制限するメカニズムをOSPFレベルで提供します。ネットワーク内の他のルータの設定に誤りがあると、大量のLSAが生成される可能性があります。たとえば、多数のプレフィックスをOSPFに再配布する場合などです。この保護メカニズムは、ルータが多数のLSAを受信して、CPUとメモリの不足が発生するのを防ぐのに役立ちます。  

機能の動作

この機能の動作を次に示します。 

■ この機能を有効にすると、ルータは受信した（自己生成ではない）すべてのLSAの数をカウントします。  

■ 設定されているしきい値に達すると、エラーメッセージがログに記録されます。  

■ 受信したLSAの設定済みの最大数を超過すると、ルータは新しいLSAの受け入れを停止します。   

max-lsa <max-lsa-count> <%-threshold-to-log-warning> ignore-count <ignore-count-value> ignore-time <ignore-time-in-minutes> reset-time <time-to-reset-ignore-count-in-minutes>   

OSPFの状態

1分後に受信したLSAの数が、設定されているmaxの数よりも多くなった場合、OSPFプロセスはすべての隣接関係をダウンさせ、OSPFデータベースをクリアします。この状態はignore状態と呼ばれます。この状態では、OSPFインスタンスに属するすべてのインターフェイスで受信されたすべてのOSPFパケットは無視され、インターフェイスでOSPFパケットは生成されません。OSPFプロセスは、設定されたignore-time(デフォルトは5分)の間、ignore状態のままです。ignore-timeが期限切れになると、OSPFプロセスは通常の動作に戻り、すべてのインターフェイスで隣接関係を構築します。   

OSPFインスタンスがignore状態から戻るとすぐにLSAカウントがmax数を超えると、OSPFインスタンスは通常の状態とignore状態の間で無限に揺れ動くことができます。この無限の発振を防ぐために、OSPFインスタンスはignore状態になった回数をカウントします。このカウンタはignore-countと呼ばれます。ignore-count (デフォルトのignore-count は5)が設定値を超えると、OSPFインスタンスは永続的にignore状態になります。   

OSPFインスタンスを通常の状態に戻すには、clear ospfコマンドを発行する必要があります。ignore-countは、reset-timeキーワードで設定された時間内にLSAカウントが再び最大数を超えない場合に0にリセットされます。   

warning-onlyキーワードを使用すると、OSPFインスタンスはignore状態にはなりません。LSAカウントが最大数を超えると、OSPFプロセスはエラーメッセージをログに記録し、OSPFインスタンスは通常の状態の動作を続行します。  

max-lsaにはデフォルト値はありません。この制限は、明示的に設定されている場合にのみチェックされます。  

max-lsaが設定されると、他のパラメータはデフォルト値を持つことができます。

■ デフォルトの%-threshold-to-log-warning - 75%  

■ デフォルトのignore-count-value - 5

■ デフォルトのignore-time-in-minutes - 5分  

■ default time-to-reset-ignore-count - 10分

VRF V1で自己生成されないLSAを1000個、および自己生成されないLSAを1000個12000受け入れるようにOSPFインスタンスを設定する方法を示す実装例を次に示します。

RP/0/RSP0/CPU0:router#設定  

RP/0/RSP0/CPU0:router(config)# router ospf 0   

RP/0/RSP0/CPU0:router(config-ospf)# max-lsa 12000  

RP/0/RSP0/CPU0:router(config-ospf)# vrf V1  

RP/0/RSP0/CPU0:router(config-ospf)# max-lsa 1000   

次の例は、OSPFインスタンスの現在のステータスを表示する方法を示しています。  

RP/0/RSP0/CPU0:router# show ospf 0  

    ID 10.0.0.2のルーティングプロセス「ospf 0」  

    NSR（ノンストップルーティング）が無効  

    単一のTOS(TOS0)ルートのみをサポート  

    不透明なLSAをサポート  

    エリア境界ルータである  

    自己生成されないLSAの最大許容12000数  

       自己生成されないLSA 1の現在の数  

       警告メッセージのしきい値75 %  

       無視時間5分、リセット時間10分  

       Ignore-count allowed 5, current ignore-count 0（無視カウントが5回、現在の無視カウントが0回）  

BGPの実装 

BGPアドレスファミリは、BGPを「マルチプロトコル」ルーティングプロトコルにします。実装と管理が容易なスケーラブルなトポロジを作成するために、アドレスファミリがどのように使用されるかを理解しておくことを強くお勧めします。アドレスファミリを使用すると、オペレータは異なるテクノロジーに対して異なるトポロジ（EVPN、マルチキャストなど）を作成できます。  

BGPの詳細については、次のBGPコンフィギュレーションガイドを参照してください。https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html 

BGPおよびBFD 

サービスプロバイダーネットワークでのBGPコンバージェンスは、復元力のあるフォールトトレラントネットワークの構築に対するお客様の期待を満たすために重要です。デフォルトでは、BGPのキープアライブタイマーは60秒、ホールドタイマーは180秒です。これは、サポートしているプロトコルの支援がない限り、BGPのコンバージが非常に遅くなることを意味します。BFD Bi-directional Forwarding(BFD)は、クライアントプロトコルのコンバージェンスを高速化するために設計されたプロトコルの1つです。BFDを使用すると、プロトコルは数秒以内に収束できます。   

追加情報

■ このガイドでは、BFDの概念および設定情報について説明します。https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/76x/b-routing-cg-ncs5500-76x/implementing-bfd.html 

■ このホワイトペーパーでは、Cisco NCS 5500およびCisco Network Convergence System 500シリーズルータでのBFDを使用した高速コンバージェンスに関する、サービスプロバイダー中心の見解を示します。https://xrdocs.io/ncs5500/tutorials/bfd-architecture-on-ncs5500-and-ncs500/  

■ バンドルインターフェイスでのBFDの使用とマルチパスおよびマルチホップBFDの実装の詳細については、https://xrdocs.io/のリポジトリを参照してください。  

BGP低速ピア検出  

低速ピアとは、ルータがアップデートグループ内で長時間（分単位）にわたってアップデートメッセージを生成するレートに追いつけないピアのことです。アップデートグループ内に低速ピアが存在する場合、送信を保留しているフォーマット済みアップデートの数が増えます。キャッシュの上限に達すると、グループには新しいメッセージをフォーマットするためのクォータがなくなります。新しいメッセージをフォーマットするには、既存のメッセージの一部を低速ピアを使用して送信し、キャッシュから削除する必要があります。低速ピアよりも高速で、フォーマットされたメッセージの送信を完了したグループの残りのメンバーは、新しく変更されたBGPネットワークがアドバタイズまたは取り消されるのを待っている場合でも、新しく送信するものは何も持ちません。グループ内のピアの1つが更新の消費が遅い場合に、グループ内のすべてのピアのフォーマットをブロックする効果は、「低速ピア」の問題です。  

BGPテーブルで大幅な変更を引き起こすイベント（接続リセットなど）は、アップデートの生成率の瞬間的な急上昇を引き起こす可能性があります。このようなイベントの発生時に一時的に遅れをとるものの、イベント後すぐに回復するピアは、低速ピアとは見なされません。ピアを低速としてマークするには、生成された更新の平均速度をより長い期間（数分程度）維持できない必要があります。  

BGP低速ピアの原因は次のとおりです。   

■ ピアへのリンクでパケット損失または高トラフィック。 

■ BGPピアはCPUの観点から負荷が高い可能性があるため、必要な速度でTCP接続にサービスを提供できません。  

■ この場合、プラットフォームハードウェアの機能と提供される負荷を確認する必要があります。 

■ BGP接続のスループットの問題  

■ BGP低速ピア検出の詳細については、次のサイトを参照してください。https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html#concept_ir5_j4w_p4b  

低速ピアを管理するための緩和策とベストプラクティスを次に示します。   

■ エンドツーエンドQoS。輻輳時にBGPコントロールプレーントラフィック用に帯域幅を予約します。 

■ BGP PMTUDおよび/またはTCP MSS設定を使用した、正しく適切なMSS/MTU値の使用。 

■ 正しいハードウェアを使用し、ハードウェアに対するルートの数を最小限にします。 

Cisco IOS XRリリース7.1.2以降では、低速ピア検出はデフォルトで有効になっています。低速ピアとは、着信BGPアップデートの受信と処理、および送信側へのアップデートの確認応答が遅いピアのことです。低速ピアが他のピアと同じアップデートグループに参加している場合、すべてのピアのアップデートプロセスの速度が低下する可能性があります。このリリースでは、IOS XRが低速ピアを検出すると、特定のピアに関する詳細を含むsyslogを作成します。   

BGP Prefix Independent Convergenceを使用した高速コンバージェンス  

BGPプレフィックスの場合、高速コンバージェンスはBGP Prefix Independent Convergence(PIC)を使用して実現されます。PICでは、代替ベストパスとプライマリベストパスが計算され、両方のパスがプライマリパスおよびバックアップパスとしてルーティングテーブルにインストールされます。   

BGPネクストホップリモートが到達不能になると、BGPは障害発生後にパスを再計算する代わりに、BGP PICを使用して代替パスに即時に切り替えます。   

BGPネクストホップリモートPEが機能していても、パスに障害が発生している場合、IGP TI-LFA FRRは代替パスへの高速な再コンバージェンスを処理し、BGPはリモートPEのIGPネクストホップを更新します。   

BGP PICは、リモートPEが到達不能になった場合にVPNプレフィクスを高速コンバージェンスするために、VRFアドレスファミリで設定されます。  

BGP Prefix Independent Convergenceの詳細については、次のサイトを参照してください。
 https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/bgp-pic.html 

 

BGP Flowspecを使用したBGPセキュリティ  

BGP Flowspecは、BGPアップデートを介して、IPv4/IPv6トラフィックフロー仕様（送信元X、宛先Y、プロトコルUDP、送信元ポートAなど）と、そのトラフィックに対して実行する必要があるアクション（ドロップ、ポリシング、リダイレクトなど）を受信できるようにする機能です。BGPアップデート
内では、Flowspec一致基準はBGP NLRIによって表され、BGP拡張コミュニティがアクションをします。

この機能はRFC 5575に基づいており、DDoS攻撃の緩和に使用できます。ネットワーク内の特定のホストが攻撃を受けると、エッジルータにFlowspecアップデートを送信して、攻撃トラフィックをポリシングまたはドロップしたり、トラフィックをクリーニングできるアプライアンスにリダイレクトしたりできます（「不正な」トラフィックをフィルタリングして、「正常な」トラフィックだけを該当ホストに転送します）。  

Flowspecがルータによって受信され、該当するラインカードにプログラムされると、これらのラインカード上のアクティブなL3ポートはすべて、Flowspecルールに従って入力トラフィックの処理を開始します。  

BGP FlowSpecの実装の詳細については、次を参照してください。  

■ BGP FlowSpecホワイトペーパー：https://xrdocs.io/ncs5500/tutorials/bgp-flowspec-on-ncs5500/  

■ BGPコンフィギュレーションガイド：https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html#concept_uqv_bxq_h2b 

 

BGP最大プレフィクス機能

最大プレフィクス機能は、リモートピアリングサイトでの発信ポリシーの変更時に、ピアリングルータのリソースが処理できる量よりも多いプレフィクスをルータが受信し始めると同時に、これらの外部プレフィクスの転送先のリソースや内部BGPピアを保護する場合に役立ちます。このようなリソースのオーバーヘッドは混乱を招く可能性があります。

BGPの最大プレフィクス機能では、特定のアドレスファミリに対してネイバーから受信するプレフィクスの数に上限が課されます。デフォルトでは、受信したプレフィクスの数が設定された最大数を超えると、BGPセッションはネイバーに停止通知を送信し、セッションが終了します。最大プレフィクスを超える1つのアドレスファミリは、BGPセッション全体をダウンさせ、そのBGPセッションで有効になっている他のすべてのアドレスファミリに影響を与えます。

この機能は通常、サービスプロバイダーの内部インフラストラクチャを保護するために外部BGP(eBGP)ピアで使用されます。ローカルまたはリモートネイバーでの誤設定によって発生する可能性があるルータリソースの枯渇を防ぐためのガードレールとして機能します。ルートテーブルのフラッディングを引き起こす可能性があるローカルまたはリモートの設定ミスから保護するために、最大プレフィクスを設定することを強く推奨します。これにより、プレフィクスのアグリゲーション解除攻撃からも保護されます。

顧客またはピアリングASに関係なく、特定のネイバーから受信するプレフィックスの数を制限するには、すべてのeBGPルータでBGP最大プレフィックス設定を明示的に有効にする必要があります。オペレータは、使用可能なシステムメモリを慎重に評価した後で、システムが維持できる追加プレフィクスの許容マージンを設定することをお勧めします。1つのサイズがすべてのルータに適用できるすべての設定に適合するわけではないことに注意してください。しきい値は、ネットワーク内のデバイスの役割に基づいて慎重に調整する必要があります。たとえば、IBGPネイバーでBGP最大プレフィックスを設定する場合、ルートリフレクタクライアントで設定されたネイバーの最大プレフィックス値よりも、ルートリフレクタクライアントで設定されたネイバーの最大プレフィックス値の方が小さい必要があります。ルートリフレクタは、複数のピアリングルータから受信したプレフィックスを集約し、ルートリフレクタクライアントにフルテーブルを再アドバタイズします。したがって、ルートリフレクタは、個々のピアから受信するプレフィクスよりも多くのプレフィクスをクライアントにアドバタイズします。同様に、ピアリングルータでも、各外部ピアから受信するプレフィクスよりも多くのプレフィクスをルートリフレクタに再アドバタイズする可能性があります。

要約すると、実稼働デバイスで最大プレフィクスのしきい値に達したときに実行される適切なアクションを慎重に確認して設定することが推奨されます。maximum-prefixコマンドオプションの属性の一部を次に示します。

• 最大プレフィクス機能を使用してBGPセッションを明示的に設定し、追加のキーワード（warning-onlyやpotentially restartなど）がない場合、そのセッションはデフォルトの動作としてティアダウンされます。 自動リカバリを行わずにピアセッションをダウンさせるデフォルトのアクションでは、コア内で長時間の停止が発生する可能性があります。

%ROUTING-BGP-5-ADJCHANGE_DETAIL : neighbor 10.10.10.10 Down - BGP通知を受信しました。プレフィクスの最大数に到達しました(VRF:default; AFI/SAFI: 1/1, 1/128, 2/4, 2/128, 1/133, 2/133) (AS: 65000) "

%ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY：ピアが最大プレフィクス制限（VRF：デフォルト）を超過したため、スタンバイRPのネイバー10.10.10.10でNSRが無効になりました。

• Discard Extra Pathsオプションを設定すると、設定された最大値のしきい値を超えてネイバーから受信したすべての超過プレフィックスが廃棄されます。このドロップでは、セッションフラップは発生しません。このオプションの利点には、BGPプロセスのメモリ使用率の制限、およびコアネットワーク内のピアのフラッピングの停止が含まれます。ただし、フォワーディングエントリがネットワーク内のルータ間で一致しなくなるため、プレフィクスのフォワーディングループが廃棄される可能性があります。
• add-pathを使用する場合、NLRIはプレフィクスとパス属性で構成されるため、設定済みの最大プレフィクス値はプレフィクスではなくパスに適用されます。詳細については、次のコマンドリファレンスを参照してください。

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/b-ncs5500-bgp-cli-reference/b-ncs5500-bgp-cli-reference_chapter_01.html

推奨事項:maximum-prefixコマンドを設定する際は、次のオプションを慎重に評価してください。

• 明示的なアクションが定義されていない：ルータはセッションをダウンさせ、オペレータが手動でBGPセッションをクリアするまで、BGPネイバー関係をダウンしたままにします。[clear bgpコマンド]
• Restart [time-interval]：セッションをダウンさせ、設定されたタイマーの後に、定期的にBGPセッションの自動再起動を試行します。これは、リモートピアが過剰なプレフィックスのアドバタイズを停止した場合に成功します。そうしないと、BGPセッションが再びダウンします（そのため、定期的な不安定が発生します）。
• Discard-extra-paths:discard-extra-pathsオプションを使用すると、BGPセッションはアップ状態のままですが、最大プレフィクスの制限を超えたプレフィクスは廃棄されます。このオプションは、最大プレフィクスに到達していない他のアドレスファミリには影響を与えず、ローカルリソースを使い果たさないことを保証しますが、これが原因で廃棄されるプレフィクスに対する転送ループが発生する可能性があります。 「余分なパスを破棄」オプションは、ソフト再構成ノブと共存できません。
• Warning-only：しきい値に達した場合にのみ警告をログに記録し、オペレータが手動でアクションを実行して条件をクリアできるようにします。

詳細については、次に示す『ルーティング設定ガイド』を参照してください。

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-3/routing/configuration/guide/b-routing-cg-asr9000-73x/implementing-BGP.html#concept_5AF38064B1D044B7B5F439C10BCF9808

ベストプラクティスと推奨事項

次に、一般的なベストプラクティスと推奨事項の概要を示します。具体的な順序は記載されていません。  

■ システムの全般的な健全性に関するネットワーク監査。設定監査から始め、インターフェイス設定からルーティングおよびサービスまで順番に移行します。   

■ モニタリング戦略を策定する。SNMPは標準的な手法ですが、ストリーミングテレメトリを使用して、より堅牢で記述的な手法を導入することを検討してください。IOS XRルータでのテレメトリの実装に関するベストプラクティスの推奨事項については、次のホワイトペーパーを参照してください。https://xrdocs.io/telemetry/  

OSPF  

OSPFの一般的なベストプラクティスと推奨事項を次に示します。 

■ OSPFのエリア内ルートのルート集約を実装します。  

■ OSPF内部のルータIDを、OSPF対応ループバックアドレスの1つとして明示的に設定します。  

■ OSPFのエリア内のLSAを制限する階層型ネットワークを設計します。エリアのABRの数を妥当な範囲内(3 ～ 4)に保ちます。  

■ OSPF用のOSPF「max-lsa」設定、または同等の設定を実装して、データベース内のLSAを制限し、システムのメモリを効果的に使用します。   

■ BGPからOSPFに配布できるルートの最大数を制限します。IOS-XRでは、デフォルトの制限は10Kです。 

■ ルートポリシー(RPL)を使用して、ルートをOSPFに再配布します。 

■ 必要に応じて、エリア間ルートと外部タイプ5ルートを集約します。   

■ 必要に応じて認証を使用します。   

■ 常にNSFとNSRを使用してください。 

■ 再配布フィルタリングを宛先ではなく送信元で設定します。   

■ 必要に応じてパッシブインターフェイスを使用します。   

■ OSPFはループバックルートとルータインターフェイスルートのみを伝送する必要があります。他のBGPからOSPFへの再配布はすべて削除してください。   

■ 各プライマリハブをそれ自体のエリア(NSSA)に移動することを検討してください。   

■ アグレッシブルーティングプロトコルタイマーに対して、迅速な障害検出にはBFDを使用します。   

■ mtu-ignoreコマンドは、できるだけ使用しないでください。  

■ MPLS環境でIGP-LDP同期を使用して、ラベルなしパスでのトラフィックの送信を回避することを検討してください。 

■ サポートされているプラットフォームの制限内でのスケールを検討してください（プレフィクスの数、ラベルの数、ECMP、エリアの数など）。 

■ 複数のポイントでの相互再配布の回避  

■ 各プロトコルまたはプロセスのネイティブな各プレフィクスが、対応するドメインのプロトコルまたはプロセスを介して到達するように、アドミニストレーティブディスタンスを設定します。  

■ 同じプレフィクスが発信元ドメインにアドバタイズして戻されないように、プレフィクスを制御します（ディスタンスまたはプレフィックスリストの組み合わせを使用）。   

■ OSPFプロセスIDはルータにとってローカルで意味を持ちますが、同じOSPFドメイン内のすべてのルータに対して同じプロセスIDを持つことをお勧めします。これにより、設定の一貫性が向上し、自動設定タスクが容易になります。  

■ ハブアンドスポーク環境向けにOSPFを設定する場合は、ルータの数を減らしてOSPFエリアを設計します。   

■ OSPFドメイン全体のOSPF自動コスト参照帯域幅を、ネットワーク内で最も高い帯域幅のリンクに設定します。  

■ 設計の観点からは、計画外または不正なIGPアップデートがネットワーク全体に伝播されるのを防ぐため、同じ管理コントロールまたは運用コントロール下でドメインとのIGPピアリングを実装することをお勧めします。これにより、メンテナンス性が向上し、エラーが発生した場合のトラブルシューティングが容易になります。大規模なIGPドメインがビジネス上の必要性である場合は、BGPを使用してIGPネットワークドメイン内のルート数を制限するように計画してください。  

■ エンドツーエンドのMPLS接続が必要な場合は、階層/セグメンテーションの使用を続行し、RFC3107 BGP-LUやPCE経由のドメイン間パス計算などのオプションを使用するか、または最後の手段としてポリシーによる再配布またはリークを選択します。  

■ OSPF Shortest Path Firstスロットリング機能は、SPFスケジューリングをミリ秒間隔で設定し、ネットワークが不安定な場合にSPF計算を遅延させる可能性がある場合に使用できます。 

OSPF SPFプレフィクス優先順位付け機能■より、管理者はルートのインストール中に重要なプレフィクスをより迅速に収束できます。  

IS-IS  

IS-ISの一般的なベストプラクティスと推奨事項を次に示します。 

■ フラットなシングルレベルネットワークを運用している場合は、スケールについて考えてください。すべてのルータをL2のみとして設定します。デフォルトでは、ルータはL1-L2であり、L1からL2へのルーティング情報のリークはデフォルトで有効になっています。これにより、すべてのルータがすべてのL1ルートをL2にリークし、リンクステートデータベースが肥大化する可能性があります。  

■ マルチレベル（複数エリア）ネットワークを実行している場合は、レイヤ3トポロジがISIS階層に従っていることを確認します。L1エリア間にバックドアリンクを作成しないでください。  

■ マルチレベル（複数エリア）ネットワークを実行している場合は、L1およびL2ルータがL1とL2の両方のエリアを介して接続されていることを確認します。これには、ルータ間に複数の物理接続または仮想接続は必要ありません。L1ルータとL2ルータ間のリンクをL1/L2回線として実行します。  

■ マルチレベル（複数エリア）ネットワークを実行している場合は、集約できる内容を要約してください。たとえばMPLSの場合、PEルータのループバックをエリア間で伝搬する必要がありますが、インフラストラクチャリンクアドレスではこれはできません。  

■ 可能であれば、適切なアドレッシング計画を作成し、それに従います。集約が可能で、拡張に役立ちます。  

■ LSPライフタイムを最大18時間に設定します。 

■ 何らかの手段で再配布を回避します。再配布は複雑で、ルーティングループを回避するために手動で管理する必要があります。可能であれば、マルチエリア/レベル設計を使用します。  

■ 再配布を使用する必要がある場合は、再配布時にルートタギングを使用し、タグに基づいて「distribute-list in」フィルタリングを使用して管理します。可能であれば、再配布中に集約します。  

■ 可能な限り、インターフェイスを「ポイントツーポイント」として設定します。これにより、プロトコルのパフォーマンスとスケーラビリティが向上します。 

■ 高度にメッシュ化されたトポロジではISISを使用しないでください。リンクステートプロトコルは、高度にメッシュ化された環境では適切に動作しません。  

■ ISISアドレスファミリサブモードで高いデフォルトメトリックを設定します。これにより、新しく追加されたリンクがメトリックなしで誤って設定された場合に、トラフィックが引き付けられるのを防ぎます。  

■ 接続のトラブルシューティングに役立つように、「ログ隣接関係の変更」を設定します。

■ ISISアドレスファミリipv4サブモードで「metric-style wide」を使用します。狭いメトリックはあまり役に立たず、セグメントルーティングやflex-algoなどの機能はサポートされません。  

■ SR-MPLS TI-LFAを使用している場合は、ISISが必要に応じてTEトンネルを割り当てられるように「ipv4 unnumbered mpls traffic-eng Loopback0」を設定に追加することを忘れないようにしてください。  

■より高速なネイティブコンバージェンスが必要であると確信できる場合を除き、「lsp-gen-interval」および「spf-interval」の設定はデフォルトのままにします。TI-LFAでは、高速再ルーティングが50 ms以下で単一のトポロジ変更を処理するため、ネイティブコンバージェンスはそれほど重要ではありません。  

■ 「lsp-gen-interval」または「spf-interval」を変更する場合は、50 msより短い初期遅延時間を使用しないでください。  

■ 多くの場合、「set-overload-bit」は高速再ルーティングでサポートされるアトミックな変更であるため、「max-metric」よりも適した選択です。  

■ Hello(hello-password)およびLSP(lsp-password)に暗号化認証を使用します。キーチェーンは最も柔軟性が高く、ヒットレスキーロールオーバーに
対応できます。  

■ ISISプロセスの再起動とSMUインストールのヒットレス認証を「nsf cisco」に設定します。名前は伏せられていますが、「nsf ietf」以外のベンダーとの相互運用性が向上しています。 

■ デュアルRPのプラットフォームでは、RPスイッチオーバーを処理するように「nsr」も設定します。  

■ 「group」および「apply-group」テンプレートを使用して、繰り返される設定セクションを設定します。これはエラーが発生しにくく、必要に応じて簡単に変更できます。  

■ マルチレベルネットワークでは、プレフィックスをレベル2からレベル1にリークするために「プロパゲート」を使用する必要があるかどうかを慎重に検討します。これは拡張性を制限する可能性があり、多くの場合、Attachedビットによって提供されるレベル1デフォルトルートで十分です。 

■ 同じVRFで複数のISISインスタンスを使用している場合は、インスタンスに固有の「distance」値を設定することを検討してください。これにより、同じプレフィックスへのルートが各RIBに存在する場合に、RIBでのルートのインストールがより確定的になります。  

■ 迅速なリンクダウン検出にBFDを使用します。この機能を提供するBFDを使用すると、ISIS hello-intervalを安全に増やしてスケーラビリティを向上させることができます。  

BGP  

BGPに関する一般的なベストプラクティスと推奨事項を次に示します。 

■ 予想されるスケールに応じて、慎重に調整されたタイマーでNSRおよびNSF/グレースフルリスタートを使用します。 

■ IBGPピアリングの物理インターフェイスではなく、「always UP」ループバックインターフェイスを使用してBGPを設定します。 

■ 適切なRPLを使用せずにBGP（大量）ルートをIGP（比較的少量）に再配布したり、その逆を再配布したりしないでください。これにより、BGPからIGP(OSPF/ISIS)への再配布ルートの数が制限されます。   

■ 十分にテストされた適切なポリシー(ACL)を使用せずにBGPからIGPへの再配布を実行すると、ルータでリソース（メモリ）が使い果たされる可能性があります。  

■ ルーティングテーブルのサイズを縮小し、メモリを使用するために、BGPで集約ルートを使用します。ルートは集約ルートで集約され、集約ルートが意味を持つ場所に限定されます  

■ ルートのアドバタイズと受信に、ルートのフィルタリングを効率的に使用します(特にBGP)。  

■ ルートリフレクタ(RR)とコンフェデレーションを使用してネットワークを拡張することをお勧めします。   

■ ルートリフレクタの設計上の考慮事項の一部を次に示します。 

■ パススケールは、クライアント/非クライアントの数に応じて増加します。 

■ 階層型RRでは、ループの防止とスケールのために同じレベル（冗長RR）で同じクラスタIDを使用します。  

■ BGPパス内でMTUを制御するか、PMTUDプロトコルを使用してBGP MSSを自動的に調整します。  

■ 障害検出を高速化するには、BFDを使用するか、BGPタイマーを調整します。 

■ BGPのスケールは設定とユースケースに従い、1つのサイズですべてに適合することはありません。次の点について十分に理解しておく必要があります。  

■ルートスケール  

—パスの拡張（ソフト再構成では増加）  

—属性尺度  

■ add-pathが設定されている場合は、より多くのメモリを消費します。  

■ BGPネイバーポリシーについて注意深く理解する。 

—パスオール（特に境界ルータ）は、メモリスケールの増大に伴い混乱を引き起こす可能性があります。 

— RPLでの正規表現の一致を回避するポリシー構造を使用します。  

■ NSRを使用すると、スタンバイRPはアクティブよりも約30 %多くの仮想メモリを使用します。スタンバイRPがある場合は、この点を考慮してください。 

■ 多数のルートで連続的なチャーンが発生している（バージョンバンプ）ことに注意してください。これにより、アップデート生成メモリが高水準点に保たれます。 

■ 最大プレフィックスノブによるピアの保護  

■ スケールとコンバージェンスの目標に従って、ネクストホップトリガー遅延パラメータを使用します。 

■ ネットワーク設計では、新しい属性を避けるようにしてください。一意の属性は非効率的なパッキングにつながり、結果としてより多くのBGPアップデートが発生します。  

■ ネットワーク全体でマルチパスを設定すると、フォワーディングループが発生する可能性があります。注意して使用してください。  

■ RRがinline-RR(no next-hop-self)でない場合は、table-policyを使用してribへのルートインストールを回避します。   

ルーティングプロセスのシステムメモリの監視

リソースが無限に存在するデバイスがない：デバイスに無数のルートを送信する場合、デバイスは障害発生方法を選択する必要があります。ルータは、メモリの制限がなくなるまで、すべてのルートにサービスを提供しようとします。これにより、すべてのルーティングプロトコルとプロセスが失敗する可能性があります。  

コアルータの各プロセスには「RLIMIT」が定義されています。「RLIMIT」は、各プロセスが消費できるシステムメモリの量です。   

このセクションでは、BGPプロセスで使用されるシステムメモリを監視およびチェックするための標準的なテクニックについて説明します。 

プロセスメモリ  

プロセスによって消費されたメモリの量を表示します。

RP/0/RP0/CPU0:NCS-5501#show proc memory  

JIDテキスト(KB)データ(KB)スタック(KB)ダイナミック(KB)プロセス  

------ ---------- ---------- ---------- ----------- ------------------------------  

1150 896 368300 136 33462 lspv_server  

380 316 1877872 136 32775 parser_server  

1084 2092 2425220 136 31703 bgp  

1260 1056 1566272 160 31691 ipv4_rib  

1262 1304 1161960 152 28962 ipv6_rib  

1277 4276 1479984 136 21555 pim6  

1301 80 227388 136 21372 schema_server  

1276 4272 1677244 136 20743 pim  

250 124 692436 136 20647 invmgr_proxy  

1294 4540 2072976 136 20133 l2vpn_mgr  

211 212 692476 136 19408 sdr_invmgr  

1257 4 679752 136 17454 statsd_manager_g  

 

各プロセスには、消費できるメモリの最大量が割り当てられます。これは制限として定義されます。  

RP/0/RP0/CPU0:NCS-5501#show proc memory detail  

JIDテキストデータスタックの動的Dyn-Limit Shm-Tot Phy-Totプロセス  

0.============================================================================================================  

1150 896K 359M 136K 32M 1024M 18M 24M lspv_server  

1084 2M 2368M 136K 30M 7447M 43M 69M BGP  

1260 1M 1529M 160K 30M 8192M 38M 52M ipv4_rib  

380 316K 1833M 136K 29M 2048M 25M 94M parser_server  

1262 1M 1134M 152K 28M 8192M 22M 31M ipv6_rib  

1277 4M 1445M 136K 21M 1024M 18M 41M pim6  

1301 80K 222M 136K 20M 300M 5M 33M schema_server  

1276 4M 1637M 136K 20M 1024M 19M 41M PIM  

250 124K 676M 136K 20M 1024M 9M 31M invmgr_proxy  

1294 4M 2024M 136K 19M 1861M 48M 66M l2vpn_mgr  

211 212K 676M 136K 18M 300M 9M 29M sdr_invmgr  

1257 4K 663M 136K 17M 2048M 20M 39M statsd_manager_g  

288 4K 534M 136K 16M 2048M 15M 33M statsd_manager_l  

...    

上位のメモリコンシューマ  

RP/0/RP0/CPU0:NCS-5501#show memory-top-consumers  

##############################################################################  

 0/0/CPU0の上位メモリコンシューマ（2022年4月13日、15:54:12）  

##############################################################################  

    PIDプロセス合計(MB)ヒープ(MB)共有(MB)  

   3469 fia_driver 826 492.82 321  

   4091 fib_mgr 175 1094.43 155  

   3456 spp 130 9.68 124  

   4063 dpa_port_mapper 108 1.12 105  

   3457パケット104 1.36 101  

   5097 l2fib_mgr 86 52.01 71  

   4147 bfd_agent 78 6.66 66  

   4958 eth_intf_ea 66 4.76 61  

   4131 optics_driver 62 141.23 22  

   4090 ipv6_nd 55 4.13 49  

##############################################################################  

 0/RP0/CPU0の上位メモリコンシューマ(20xx/MMM/HH:MM:SS)  

##############################################################################  

    PIDプロセス合計(MB)ヒープ(MB)共有(MB)  

   3581 spp 119 9.62 114  

   4352 dpa_port_mapper 106 2.75 102  

   4494 fib_mgr 99 7.71 90  

   3582パケット96 1.48 94  

   3684 parser_server 95 64.27 25  

   8144 te_control 71 15.06 55  

   8980 bgp 70 27.61 44  

   7674 l2vpn_mgr 67 23.64 48  

   8376 mibd_interface 65 35.28 28  

   3608 gsp 65 15.75 48   

合計メモリ – 使用済みメモリと使用可能メモリ  

システムコンポーネントの使用可能なメモリの量は固定です。  

RP/0/RP0/CPU0:NCS-5501#show memory summary location all  

ノード：node0_0_CPU0  

0.------------------------------------------------------------------  

 物理メモリ：合計8,192 M(6,172 M)  

 アプリケーションメモリ：8,192 M（6,172 M使用可能）  

 画像：4M（ブートトラム：0M）  

 予約済み：0M、IOMem:0M、フラッシュシステム：0M  

 合計共有ウィンドウ数：2,260万  

ノード：node0_RP0_CPU0  

0.------------------------------------------------------------------  

 物理メモリ：合計18432 M(15344 M使用可能)  

 アプリケーションメモリ：18432 M(15344 M使用可能)  

 画像：4M（ブートトラム：0M）  

 予約済み：0M、IOMem:0M、フラッシュシステム：0M  

 合計共有ウィンドウ：181M  

 

共有メモリウィンドウには、システム上の共有メモリ割り当てに関する情報が表示されます。  

RP/0/RP0/CPU0:NCS-5501#show memory summary detail location 0/RP0/CPU0  

ノード：node0_RP0_CPU0  

0.------------------------------------------------------------------  

 物理メモリ：合計18432 M(15344 M使用可能)  

 アプリケーションメモリ：18432 M(15344 M使用可能)  

 画像：4M（ブートトラム：0M）  

 予約済み：0M、IOMem:0M、フラッシュシステム：0M  

 共有ウィンドウsoasync-app-1:243.328K  

 共有ウィンドウsoasync-12:3.328K  

 ...  

 共有ウィンドウrewrite-db:272.164K  

 共有ウィンドウl2fib_brg_shm: 139.758K  

 共有ウィンドウim_rules:384.211K  

 共有ウィンドウgrid_svr_shm: 44.272M  

 共有ウィンドウSPP:86.387M  

 共有ウィンドウim_db: 1.306M  

 合計共有ウィンドウ：180.969M  

 割り当てメモリ：2.337G  

 プログラムテキスト：127.993T  

 プログラムデータ：64.479G  

 プログラムスタック：2.034G  

システムRAM:18432 M(19327352832)  

合計使用量：3088 M(3238002688)  

 使用プライベート： 0M ( 0)  

 使用共有：3088M(3238002688)  

 

共有メモリウィンドウを使用して、参加者のプロセスを確認できます。  

RP/0/RP0/CPU0:NCS-5501#sh shmwin spp participants list  

ウィンドウ「spp」のデータ：  

0.-----------------------------  

現在の参加者のリスト：-  

名前PID JIDインデックス  

spp 3581 113 0  

パケット3582 345 1  

ncd 4362 432 2  

netio 4354 234  3  

nsr_ping_reply 4371 291 4  

aib 4423 296 5  

ipv6_io 4497 430 6  

ipv4_io 4484 438 7  

fib_mgr 4494 293 8  

...  

snmpd 8171 1002 44  

ospf 8417 1030 45  

mpls_ldp 7678 1292 46  

bgp 8980 1084 47  

立憲民主党9295 337 48  

RP/0/RP0/CPU0:NCS-5501#sh shmwin soasync-1 participants list  

ウィンドウ「soasync-1」のデータ：  

0.-----------------------------  

現在の参加者のリスト：-  

名前PID JIDインデックス    

tcp 5584 168 0        

bgp 8980 1084    

 

リソースモニタリングとウォッチドッグ  

メモリ使用率は、cXRではシステムウォッチドッグを使用して監視され、eXRではResmonを使用します。  

RP/0/RP0/CPU0:NCS-5501#show watchdog memory-state  

---- node0_RP0_CPU0 ----  

メモリ情報：  

    物理メモリ：18432.0 MB  

    空きメモリ：15348.0 MB  

    メモリの状態：正常  

RP/0/RP0/CPU0:NCS-5501#  

RP/0/RP0/CPU0:NCS-5501#show watchdog threshold memory defaults location 0/RP0/CPU0  

---- node0_RP0_CPU0 ----  

 デフォルトメモリしきい値：  

 マイナー：1843 MB  

 重大：1474 MB  

 クリティカル：921.599 MB  

メモリ情報：  

    物理メモリ：18432.0 MB  

    空きメモリ：15340.0 MB  

    メモリの状態：正常  

RP/0/RP0/CPU0:NCS-5501#  

RP/0/RP0/CPU0:NCS-5501(config)#watchdog threshold memory minor ?  

  <5 ～ 40>メモリ消費の割合  

 

しきい値を超えると、警告が表示されます。  

RP/0/RP0/CPU0:Feb 17 23:30:21.663 UTC: resmon[425]: %HA-HA_WD-4-MEMORY_ALARM ：メモリしきい値を超えました：1840.000MBの空き容量を持つマイナー。前の状態：標準  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USERS_INFO：システムメモリの上位5つのコンシューマ(1884160 Kバイトの空き容量):  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 0：プロセス名： bgp[0]、pid: 7861、ヒープ使用量： 12207392 KB。  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 1：プロセス名： ipv4_rib[0]、pid: 4726、ヒープ使用量： 708784 KB。  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 2：プロセス名： fib_mgr[0]、pid: 3870、ヒープ使用量： 584072 KB。  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 3：プロセス名： netconf[0]、pid: 9260、ヒープ使用量： 553352 KB。  

RP/0/RP0/CPU0:Feb 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO : 4：プロセス名： netio[0]、pid: 3655、ヒープ使用量： 253556 KB。  

LC/0/3/CPU0:Mar 8 05:48:58.414 PST: resmon[172]: %HA-HA_WD-4-MEMORY_ALARM ：メモリしきい値を超えました： 600.182MBの空き容量で重大です。前の状態：標準  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USERS_WARNING ：システムメモリの上位5つのコンシューマ(624654 Kバイトの空き容量):  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING : 0:Process Name: fib_mgr[0], pid: 5375, Heap usage 1014064 KB.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING : 1：プロセス名： ipv4_mfwd_partner[0], pid: 5324, Heap usage 185596 Kバイト。  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING : 2：プロセス名： nfsvr[0], pid: 8357, Heap usage 183692 Kバイト。  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING : 3:Process Name: fia_driver[0], pid: 3542, Heap usage 177552 KB.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA-HA_WD-4-TOP_MEMORY_USER_WARNING : 4:Process Name: npu_driver[0], pid: 3525, Heap usage 177156 KB.   

一部のプロセスは、ウォッチドッグメモリの状態に基づいて特定のアクションを実行します。たとえば、BGPは次の処理を行います。  

■ マイナーステートになると、BGPは新しいピアの起動を停止します  

■ severe状態の場合、BGPは徐々に一部のピアをダウンさせます。  

■ 重大な状態になると、BGPプロセスはシャットダウンします。  

プロセスは、メモリ状態通知に登録するように設定できます。  

ウォッチドッグまたは認識型プロセスの表示  

 

ウォッチドッグタイムアウトが原因の自動プロセスシャットダウンを無効にすることができます。  

watchdog restart memory-hogディセーブル

詳細情報の入手先  

■ Cisco IOS XRブログおよびホワイトペーパーのリポジトリ(xrdocs.io) 

■ コアファブリックの設計：https://xrdocs.io/design/blogs/latest-core-fabric-hld：このホワイトペーパーでは、コアバックボーンネットワークにおける最近の傾向と進化について説明します。   

■ ピアリングファブリック設計：https://xrdocs.io/design/blogs/latest-peering-fabric-hld：このホワイトペーパーでは、ネットワークの簡素化に重点を置いた、ピアリング設計の課題の包括的な概要とベストプラクティスの推奨事項について説明します。  

■コンフィギュレーションガイドのリファレンス：BGPの実装https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/710x/b-bgp-cg-ncs5500-710x/implementing-bgp.html

機能の強化