BGP RRスケールの考慮事項とKPIモニタリング
内容
はじめに
このドキュメントでは、ボーダーゲートウェイプロトコル(BGP)ルートリフレクタ(RR)が実現できる最大スケールの主な要因と、BGP RRのパフォーマンスモニタリングのガイダンスについて説明します。
ハードウェア/ソフトウェアプラットフォームの選択
大規模なBGP RRは、通常、インターネットサービスプロバイダー(ISP)が提供するサービスを伝送するパケットの転送パスには含まれません。そのため、データパスでパケットの転送を主に行うBGP RRとルータのハードウェア要件は異なります。標準ルータは、強力なデータパス転送要素と比較的中程度のコントロールパス要素で構築されています。BGP RRは、コントロールプランですべてのタスクを実行します。
Cisco IOS® XR製品ファミリでは、BGP RRロールに対して3種類のHW/SWプラットフォームを選択できます。
| 物理Cisco IOS XRルータ |
Cisco IOS XRv 9000アプライアンス |
Cisco IOS XRv 9000ルータ（別名XRv9k） |
|
|
|
このドキュメントの作成時点では、XRv9kアプライアンスは最大のパフォーマンスで最高のコントロールプレーン容量を提供するため、BGP RRに最適なプラットフォームの選択です。
拡張性とパフォーマンスの考慮事項
データパス要素のパフォーマンスがスケールに依存することはほとんどないため、データプレーンエンティティのサポートされているスケールは比較的簡単に表現できます。たとえば、TCAMルックアップは、アクティブなTCAMエントリの数に関係なく同じ時間がかかります。
サポートされるコントロールプレーンエンティティのスケールは、スケールとパフォーマンスが相互接続されるため、より複雑になることがよくあります。1Mのルートを持つBGP RRについて考えます。このBGPテーブルを維持するためにBGPプロセスが実行する必要のある作業は、次の要素に依存します。
- BGPピアはいくつアクティブですか。
- どのアドレスファミリがアクティブですか。
- 更新グループにどのように分散されるか。
- RPL（ルートポリシー）の複雑さ
- 更新の頻度（着信アップデートと発信アップデート – アドバタイズメント間隔）。
- TCP MSS、インターフェイス/パスMTU：これを調整すると、パフォーマンスの向上に役立ちます
- デュアルRPの場合は、NSRが有効
- 別のアップデートグループにない既知の低速ピア
- ネクストホップtrigger-delay値
BGPピア数
BGPのスケールを検討する際に思い浮かぶのは、通常はBGPピアの数が最初で、残念ながら唯一です。サポートされるBGPスケールは、BGPピアの数を示さなければ表すことはできませんが、最も重要な要素ではありません。その他の多くの側面も同様に関連性があります。
アドレスファミリ
アドレスファミリ(AF)のタイプは、一般的な導入では単一ルートのサイズに影響を与えるため、BGPパフォーマンスの考慮事項における重要な要素です。 単一のTCPセグメントにパッキングできるIPv4ルートの数は、VPNv4ルートの数よりも大幅に多くなります。したがって、同じ規模のBGPテーブル変更に対して、IPv4 BGP RRはVPNv4 BGP RRと比較して実行する作業が少なくなります。明らかに、多数のコミュニティがすべてのルートに追加される導入では、AF間の違いはそれほど重要ではなくなりますが、単一ルートのサイズはさらに大きく、考慮が必要です。
アップデートグループの数
BGPプロセスは、同じアップデートグループのすべてのメンバーに対して1つのアップデートを準備します。次に、TCPプロセスはアップデートデータを（TCP MSSに応じて）必要な数のTCPセグメントに分割し、アップデートグループの各メンバーに向けます。アクティブなアップデートグループとそのメンバーは、show bgp update-groupコマンドを使用して表示できます。同じアップデートグループに含めるピアのグループに対して共通のアウトバウンドポリシーを作成することで、アップデートグループのメンバーとなるピアの種類と数を調整できます。BGP RRによって多数のBGP RRクライアントに送信される1つのアップデートによって、TCP ACKのバーストがトリガーされる可能性があります。このバーストは、Cisco IOS XRルータのLocal Packet Transport Service(LPTS)コンポーネントでドロップされる場合があります。
RPL（ルートポリシー）の複雑さ
BGPで使用されるルートポリシーの複雑さは、BGPプロセスのパフォーマンスに影響します。受信または送信されたすべてのルートは、設定されたルートポリシーに照らして評価する必要があります。非常に長いポリシーでは、このアクションに多くのCPUサイクルを費やす必要があります。正規表現を含むルートポリシーは、特に処理が重くなります。正規表現を使用すると、ルートポリシーの表現ライン数は少なくなりますが、正規表現を使用しない同等のルートポリシーよりも多くのCPUサイクルを処理に必要とします。
更新の頻度
アップデートの頻度は、BGPスケールに重要な影響を与えます。アップデートの数は予測が難しい場合がよくあります。「advertisement-interval」コマンドを使用して、アップデートの頻度を調整することができます。このコマンドは、BGPルーティングアップデートの送信間隔の最小値を設定します。iBGPピアへのデフォルト値は0秒で、eBGPピアへのデフォルト値は30秒です。
TCP MSSおよびインターフェイス/パスMTU
アップデートを多数のTCPセグメントに分割すると、大規模でアップデートの頻度が高い環境では、TCPプロセスのリソースに大きな負荷がかかる可能性があります。パスMTUとTCP MSSが大きいほど、BGPとTCPのパフォーマンスが向上します。
デュアルRPルータのNSR
NSRは冗長性のための優れた機能ですが、BGPのパフォーマンスに影響を与えます。Cisco IOS XRルータでは、両方のRPが入力ラインカード上のNPUから直接すべてのBGPアップデートを同時に受信します。これは、アクティブRPがスタンバイRPにアップデートを複製するために時間を費やす必要がないことを意味します。ただし、アクティブRPによって生成されるすべてのアップデートは、スタンバイRPに送信され、そこからBGPピアに送信される必要があります。これにより、スタンバイRPがシーケンス番号と確認応答番号で常に最新の状態になりますが、BGP全体のパフォーマンスに影響を与えることはありません。このため、BGP RRはシングルRPルータであることが推奨されます。
低速ピア
低速ピアでは、アップデートグループのすべてのメンバーに対するアップデートの速度が低下することがあります。これは、BGPプロセスでは、すべてのピアがアップデートを確認応答するまで、そのアップデートをメモリ内に保持する必要があるためです。一部のピアが低速であることがわかっている場合（ネットワークのレガシー部分にあるルータなど）、それらのピアを事前にアップデートグループに分けます。デフォルトでは、Cisco IOS XRはsyslogメッセージによって低速ピアを報告します。スタティック低速ピア（アップデートグループを他のユーザと共有しない）を作成したり、グローバルまたはネイバー単位の設定モードでBGPslow-peerコンフィギュレーションコマンドを使用してダイナミック低速ピアの動作を微調整したりできます。これについての詳細は、『Cisco xrdocs.ioポータルのIOS-XRでの最適ではないルートポリシーが原因で発生するBGPコンバージェンスの速度低下のトラブルシューティング』を参照してください。
ネクストホップのトリガー遅延
複数のBGPネクストホップが短い時間間隔で変更され、重要なネクストホップのトリガー遅延値である0が、ルートの数が多いアドレスファミリ(AF)で設定されている場合は、ネクストホップ変更イベントごとにAFのフルウォークを実行する必要があります。そのAFを繰り返し走査すると、より低いcritical nexthop trigger-delay値を持つアドレスファミリでコンバージェンス時間が増加します。「show bgp all nexthops」コマンドを実行すると、next-hop trigger-delay値を確認できます。
検証済みの多次元BGP RRスケールの例
多次元スケールの結果、特にコントロールプレーン機能に関しては、特定のテスト環境に大きく依存します。一部のパラメータを変更すると、テスト結果が大幅に異なる場合があります。
| パラメータ |
値 |
値 |
| Platform |
XRv9kアプライアンス（UCS M5ベース） |
ASR9902 |
| IOS XR リリース |
7.5.2 + Cisco Bug ID CSCwf09600の包括SMU （この包括的なSMUの構成要素は、Cisco IOS XRリリース7.9.2以降で統合されています） |
7.11.2 |
| ピア |
VPNv4 eBGP:2500 VPNv4 iBGP:1700 |
VPNv4 iBGP:2000 |
| BGP ルート |
セッションあたり：200 合計：40万 ルートごとのパス：1 |
セッションあたり：750 VPNv4:1.36M VPNv6:15万 IPv4:950k IPv6:20万 合計：約260万 ルートごとのパス：1 |
| IGPルート |
10k(ISIS) |
10k(ISIS) |
| BGPアップデートグループ |
1 |
1 |
| BGPタイマー |
デフォルト |
デフォルト |
| LPTS BGP既知ポリサーレート |
50,000 |
25,000 |
| TCP Num-Thread設定 |
16 16 |
16 16 |
| BGP送信バッファサイズ |
デフォルト |
デフォルト |
| 主要業績評価指標(KPI)の概要 |
|
|
設計上の考慮事項
ネットワークでのBGP RRの配置には、次の2つのアプローチがあります。
- 集中型/フラットBGP RR設計。
- 分散型/階層型BGP RR設計。
集中型/フラット設計では、ネットワーク内のすべてのBGP RRクライアントが、まったく同じ情報を保持するBGP RRデバイスのセット（通常はペア）とのBGPピアリングを確立します。このアプローチは実装が簡単で、小規模から中規模のネットワークに適しています。BGPテーブルでの変更は、すべてのBGP RRクライアントに迅速に伝搬されます。BGP RRクライアントの数が増加すると、BGP RRデバイスのTCP接続数がパフォーマンスに影響を与える範囲まで増加し、設計がスケール制限に達する可能性があります。
分散/階層型設計では、ネットワークは複数の領域に分割されます。リージョン内のすべてのルータは、まったく同じ情報を保持するBGP RRデバイスのセット（通常はペア）とのBGPピアリングを確立します。これらのBGP RRデバイスは、BGP RRデバイスの別のセット（通常はペア）に対するBGP RRクライアントとして機能します。この設計アプローチでは、各BGP RRのTCP接続数を一定の制限下に保ちながら、ネットワークを簡単に拡張できます。
もう1つの設計上の考慮事項は、BGPアップデートの受信者の範囲を調整することです。BGP RRクライアント間でのVRFの分布に応じて、RT Constrained Route Distributionを検討する必要があります。すべてのBGP RRクライアントが同じVRF内にインターフェイスを持つ場合、RT Constrained Route Distribution(CRD)には多くの利点はありません。ただし、VRFがすべてのBGP RRクライアントの間で疎に分散されている場合、RT Constrained Route Distribution(CRD)の使用によってƒBGP RRでのBGPプロセスの負荷が大幅に軽減されます。
BGP重要業績評価指標(KPI)の監視
BGP RRの主要業績評価指標(KPI)のモニタリングは、ネットワークの適切な運用を確保するために重要です。
ネットワークトポロジの重大な変更（たとえば、主要なDWDMリンクフラップ）により、BGP RRへの過剰なトラフィックやBGP RRからの過剰なトラフィックを生成するルーティングアップデートがトリガーされる可能性があります。BGP RRにヒットする重要なトラフィックは通常、次の内容を伝送します。
- BGPピアからのアップデート。
- BGP RRによって送信されたアップデートに応答してBGPピアによって生成されるTCP ACK（逆も同様）
このセクションでは、一般的なBGP RRでモニタする必要があるKPIについて説明し、コントロールプレーントラフィックレートが高くなる原因となっている2つの重要なBGPトラフィックタイプを特定する方法についても説明します。
ルータ内のBGPパケットのパスは、次のように表示できます。
| パント |
| イーサネットコントローラ – （パケット） – >データパスフォワーダ – （パケット） – > LPTS – （パケット） – > SPP – （パケット） -> NetIO – （パケット） – > TCP – （メッセージ） – > BGP |
| 挿入 |
| BGP – （メッセージ） – > TCP – （パケット） – > NetIO – （パケット） – > SPP – （パケット） ->データパスフォワーダ – （パケット） – >イーサネットコントローラ |
KPIは次のように分類できます。
要点：
- データパスフォワーダ
- LPTS（ハードウェアパントポリサー設定、acceptカウンタ、およびdropカウンタ）
- SPP
- Netio
- IPCキュー(NetIO <==> TCP <==> BGP)
- BGP InQ/OutQサイズ
オプション：
- CPU使用率
- メモリ使用率
- TCP統計情報
- BGPプロセスパフォーマンス
- BGPコンバージェンス
データパスフォワーダの監視
XRv9000では、データパスフォワーダはデータプレーンエージェント(DPA)ですが、ASR9000プラットフォームではネットワークプロセッサ(NP)です。
XRv9000データプレーンエージェント(DPA)のモニタ
DPAの負荷と統計情報を表示する便利なコマンドは、次のとおりです。
show controllers dpa statistics global
次のコマンドでは、ゼロ以外のすべてのカウンタが表示されます。このカウンタによって、ネットワークインターフェイスからRP CPUにパントされたパケットの種類と数、RP CPUからネットワークインターフェイスに注入されたパケットの数、およびドロップされたパケットの数に関する情報が得られます。
RP/0/RP0/CPU0:xrv9k-01#show controllers dpa statistics global Index Debug Count ---------------------------------------------------------------------------- 350 TBPG L2 mailbox events 1 Index Punt Count ---------------------------------------------------------------------------- 1500 CDP 46790 1503 ARP 212 1611 IFIB 595305 1776 LLDP 94037 2001 IPv4 incomplete Tx adjacency 2 Index Inject Count ---------------------------------------------------------------------------- 744 CLNS multicast from fabric pre-route 321250 749 IPv4 from fabric 273993 765 Inject to fabric 595245 766 Inject to port 141033 Index Drop Count ---------------------------------------------------------------------------- 416 Egress UIDB in down state 1 474 IPv4 egress UIDB down 2 673 Pre-route PIT lookup missed 2
ASR9000ネットワークプロセッサ(NP)のモニタ
システム内の各NPの負荷と統計情報を表示するのに便利なコマンドは次のとおりです。
show controllers np load all
show controllers np counters all
ASR9000のNPには、処理および廃棄されたパケットの数、レート、タイプを示す豊富なカウンタのセットがあります。
RP/0/RSP0/CPU0:ASR9k-B#show controllers np load all
Node: 0/0/CPU0:
----------------------------------------------------------------
Load Packet Rate
NP0: 0% utilization 937 pps
NP1: 0% utilization 538 pps
RP/0/RSP0/CPU0:ASR9k-B#
RP/0/RSP0/CPU0:ASR9k-B#show controllers np counters all
Node: 0/0/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v4
Last clearing of counters for this NP: NEVER
Read 92 non-zero NP counters:
Offset Counter FrameValue Rate (pps)
-------------------------------------------------------------------------------------
16 MDF_TX_LC_CPU 25475368 10
17 MDF_TX_WIRE 681957877 267
21 MDF_TX_FABRIC 683500690 267
33 PARSE_FAB_RECEIVE_CNT 681767730 267
37 PARSE_INTR_RECEIVE_CNT 1323024637 517
41 PARSE_INJ_RECEIVE_CNT 13949634 5
45 PARSE_ENET_RECEIVE_CNT 677655725 265
49 PARSE_TM_LOOP_RECEIVE_CNT 49331192 19
53 PARSE_TOP_LOOP_RECEIVE_CNT 1520846 1
109 RSV_DROP_EGR_UIDB_NO_MATCH 10 0
146 RSV_DROP_IPV4_RXADJ_DROP 1 0
164 RSV_DROP_ING_LAG_NO_MATCH 3 0
241 RSV_DROP_MPLS_LEAF_NO_MATCH 1312 0
<. . .>
LPTSの監視
標準BGP RRは転送パスにないため、ネットワークインターフェイスで受信されたすべてのパケットはコントロールプレーンにパントされます。BGP RR上のデータパス要素は、パケットがコントロールプレーンにパントされる前に、少数の単純な操作を実行します。データパス要素が輻輳ポイントになる可能性は低いため、ラインカード上で監視が必要な要素はLPTS統計情報だけです。
XRv9kの場合、ハードウェア統計情報はvPPにマッピングされます
コマンド：
show lpts pifib hardware police location <location> | inc "Node|flow_type|BGP"
例：
RP/0/RP0/CPU0:xrv9k-01#sh lpts pifib hardware police location 0/0/CPU0 | i "Node|flow_type|BGP"
Node 0/0/CPU0:
flow_type priority sw_police_id hw_policer_addr Cur. Rate burst static_avgrate avgrate_type AggrAccepts AggrDrops TOS Value
BGP-known high 6 220 50000 1250 2500 Global 16401392 0 01234567
BGP-cfg-peer medium 7 221 4000 1000 2000 Global 355976 1563 01234567
BGP-default low 8 222 3000 750 1500 Global 5212380 0 01234567
RP/0/RP0/CPU0:xrv9k-01#
確認する内容:
BGP既知のフロータイプに対するAggDropsが大幅に増加する場合は、このような大規模なコントロールプレーンの変更を引き起こしたネットワークトポロジの変更を探し始めます。
テレメトリデータパス：
Cisco-IOS-XR-lpts-pre-ifib-oper:lpts-pifib
注:LPTS統計情報カウンタはクリアできます。この可能性は、モニタリングシステムで考慮する必要があります。
SPPの監視
SPPは、NPまたはDPAから内部ファブリックを介してパントされたパケットを受信する、ルートプロセッサまたはラインカードのCPU上の最初のエンティティであり、NPまたはDPAに注入するためにファブリックに渡される前のソフトウェアパケット処理の最後のポイントです。
SPPモニタリングに関連するコマンド：
show spp node-counters
show spp client
show spp node-countersコマンドは、パント/インジェクトされたパケットのレートを示し、読みやすく理解しやすいコマンドです。BGPセッションの場合、関連するカウンタはアクティブなRPのclient/puntおよびclient/injectの下にあります。
show spp clientは出力が豊富で、クライアントに対してキューに入れられているパケット数やドロップされたパケット数、および高水準点に関するより詳細な情報を提供します。
RP/0/RP0/CPU0:xrv9k-01#show spp node-counters
0/RP0/CPU0:
socket/rx
Punted packets: 595305
Punt bulk reads: 6
Punt non-bulk reads: 595293
Management packets: 74200158
Management bulk reads: 1775930
Management non-bulk reads: 70031734
-------------------------------
socket/tx
Injected packets: 595245
Management packets: 139939168
-------------------------------
xrv9k/classify
Forwarded to SPP clients: 74795463
-------------------------------
client/inject
Injected from client: 140534413
Non-bulk injects: 140534413
-------------------------------
client/punt
punted to client: 74795371
no client found - send to defa: 92
-------------------------------
0/0/CPU0:
<. . .>
RP/0/RP0/CPU0:xrv9k-01#show spp client Sat Apr 20 17:11:40.725 UTC 0/RP0/CPU0: Clients ======= <. . .> netio, JID 254 (pid 4591) ---------------------------------------------------------- Reconnect Pending: F, Exited: F, Keep Queues: F, Pakman Client: T Quota Current: 0, Limit: 16384, Drops 0 Queues: Key Cur Max Enqueues High Watermark (Timestamp) Drops 0xffffffff 0 10 0 0 (22:13:52.195 Feb 21 24 UTC) 0 0x03000006 0 2048 0 0 (22:13:52.196 Feb 21 24 UTC) 0 0x03000007 0 3072 414881 1 (23:03:30.721 Feb 21 24 UTC) 0 0x03000008 0 1024 5 1 (13:41:28.389 Mar 13 24 UTC) 0 0x03000009 0 2048 180411 1 (23:03:31.565 Feb 21 24 UTC) 0
NetIOの監視
LPTSポリサーでは、対応するポリサーで受け入れられたかドロップされたパケットの数のみが表示されますが、NetIOレベルでは、RP CPUにパントされたパケットのレートを確認できます。一般的なBGP RRでは、受信されたパケットの大部分がBGPパケットであるため、全体的なNetIOレートはBGPパケットの受信レートに非常に近いものになります。
Command:show netio rates
例：
RP/0/RP0/CPU0:xrv9k-01#show netio rates Netio packet rate for node 0/RP0/CPU0 ----------------------------------- Current rate (updated 0 seconds ago): Input: 7845 pkts/s Output: 10570 pkts/s Driver Output: 10598 pkts/s 1 minute rate (updated 0 seconds ago): Input: 7825 pkts/s Output: 10542 pkts/s Driver Output: 10569 pkts/s 5 minute rate (updated 0 seconds ago): Input: 7997 pkts/s Output: 10677 pkts/s Driver Output: 10704 pkts/s RP/0/RP0/CPU0:xrv9k-01#
確認する内容:
- NetIOレートの大幅な増加が観察された場合は、このような大規模なコントロールプレーンの変更を引き起こしたネットワークトポロジの変更を探し始めます。
テレメトリデータパス:
- テレメトリはレートではなくカウンタ値をストリーミングする必要があるため、適用できません。BGP既知のLPTSポリサー受け入れカウンターをテレメトリコレクターで使用すると、既知のピアから受信したBGPパケットの平均レートを概算できます。
XIPCキューの監視
パントパスでは、LPTSからNetIOで受信されたパケットは、TCPおよびBGPに渡されます。次のキューを監視することが重要です。
1. NetIOがパケットをTCPに配信するTCP高優先度キュー
2. BGP制御キュー
3. BGPデータキュー
インジェクトパスでは、パケットはTCPによって作成され、NetIOに渡されます。次のキューを監視することが重要です。
- OutputL XIPCキュー
コマンド：
show netio clients
show processes bgp | i "Job Id"
show xipcq jid
show xipcq jid
queue-id
例:
NetIOからTCPへ、NetIOの観点から見る：
RP/0/RP0/CPU0:xrv9k-01#show netio clients
<. . .>
Input Punt XIPC InputQ XIPC PuntQ
ClientID Drop/Total Drop/Total Cur/High/Max Cur/High/Max
<. . .>
tcp L 0/340774 0/0 L 0/10/12800 0/0/0
H 0/44774091 H 0/784/12800
TCPからNetIOへ、NetIOの観点から見る：
RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> XIPC queues Dropped/Queued Cur/High/Max ------------------------------------------------------------ OutputL 124860/9355257 0/14000/14000
NetIOからTCP、TCPプロセスの観点から：
RP/0/RP0/CPU0:xrv9k-01#show processes tcp | i "Job Id"
Job Id: 430
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 430 Mon Apr 17 16:16:11.315 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 17 XIPC_xipcq_12_0_9854_6506_i... 60000 0 39010269 0 960 16 XIPC_xipcq_12_0_9854_6506_i... 24000 0 31518436 0 1364 15 XIPC_tcp_124 3200 0 0 0 0 14 XIPC_tcp_125 9600 0 0 0 0 13 XIPC_tcp_psb_0 25600 0 0 0 0 10 XIPC_tcp_iq_9 102400 0 9486010 0 312 12 XIPC_tcp_iq_8 102400 0 8892274 0 280 9 XIPC_tcp_iq_5 102400 0 8291392 0 289 11 XIPC_tcp_iq_7 102400 0 9700123 0 319 8 XIPC_tcp_iq_6 102400 0 9378703 0 332 7 XIPC_tcp_iq_3 102400 0 7221706 0 261 6 XIPC_tcp_iq_4 102400 0 9791070 0 308 4 XIPC_tcp_ctrl_iq_1 4266 0 0 0 0 5 XIPC_tcp_iq_2 102400 0 9699027 0 295 3 XIPC_tcp_ctrl_iq_0 4266 0 209909 0 9 2 XIPC_tcp_i1 12800 0 39460564 0 784 1 XIPC_tcp_i0 12800 0 212540 0 10
TCPからBGP:
RP/0/RP0/CPU0:xrv9k-01#show processes bgp | i "Job Id"
Job Id: 1078
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078
Mon Apr 17 16:09:33.046 CEST
Id Name Size Cur Size Produced Dropped HWM
------ ------------------------------- ------ --------- ----------- ----------- --------
2 XIPC_xipcq_12_0_9854_6506_i... 60000 2 35546667 0 15034
1 XIPC_xipcq_12_0_9854_6506_i... 24000 0 1369029 0 50
RP/0/RP0/CPU0:xrv9k-01#
BGPデータキュー：
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 1
XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp:
Magic: 12344321
Version: 0
SHM Size: 192392
Owner PID: 9854
Owner JID: 1078
Queue ID: 1
Owner MQ handle: 483
User Context: 0x64
Interrupt Flag: 0
Sent-on-full Flag: 0
Max Queue Size: 24000
Queue Size: 0
Client Queue Size: 24000
High watermark: 50
Last Trigger Sent: Mon Apr 17 16:11:10.009 CEST
MQ Send Errors: 0
Priority Queues:
Prio Size Drops Total
---------- ---------- ---------- ----------
Unspec 24000 0 0
Normal 24000 0 1396159
Medium 24000 0 0
High 24000 0 0
Crucial 24000 0 0
RP/0/RP0/CPU0:xrv9k-01#
BGP制御キュー：
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 2
XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp:
Magic: 12344321
Version: 0
SHM Size: 480392
Owner PID: 9854
Owner JID: 1078
Queue ID: 2
Owner MQ handle: 485
User Context: 0x64
Interrupt Flag: 0
Sent-on-full Flag: 0
Max Queue Size: 60000
Queue Size: 0
Client Queue Size: 60000
High watermark: 15034
Last Trigger Sent: Mon Apr 17 16:12:49.483 CEST
MQ Send Errors: 0
Priority Queues:
Prio Size Drops Total
---------- ---------- ---------- ----------
Unspec 60000 0 0
Normal 60000 0 37313633
Medium 60000 0 0
High 60000 0 0
Crucial 60000 0 0
RP/0/RP0/CPU0:xrv9k-01#
確認する内容:
- 関連するキューで廃棄が発生しないようにする
- XIPCキュー統計の高水準点(HWM)は、キューサイズの50%を超えてはなりません
高水準点値の変化をより適切に追跡するには、読み取りのたびに高水準点値をクリアする必要があります。このコマンドは、HWMカウンタだけをクリアするのではなく、すべてのキュー統計情報もクリアすることに注意してください。XIPCキューの統計情報をクリアするコマンドの形式は、次のとおりです。 clear xipcq statistics queue-name
キュー名にはプロセスID (PID)が含まれることが多いため、プロセスの再起動後にキュー名が変更されます。
関連するキューの統計情報をクリアするコマンドの例を次に示します。
clear xipcq statistics queue-name XIPC_tcp_i0
clear xipcq statistics queue-name XIPC_tcp_i1
clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp
clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp
テレメトリパス:
- XIPCのテレメトリセンサーパスがありません。
BGP入出力キューのモニタ
BGPは、すべてのBGPピアに対して入力キューと出力キューを維持します。TCPがBGPにデータを渡したが、BGPがまだそれらを処理していない場合、データはInQに存在します。BGPがデータをパケットに分割して送信するためにTCPで待機している間、データはOutQに配置されます。BGP InQ/OutQの瞬間的なサイズは、BGPプロセスのビジー状態を示しています。
コマンド：
show bgp <AFI> <SAFI> summary
例：
RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100
確認する内容:
- ネットワークが安定している場合、InQ/OutQのサイズはゼロである必要があります。更新が交換されると、すぐに変更されます。
- InQ/OutQのサイズは、時間の経過とともに単調に増加してはなりません。
テレメトリパス：
- Cisco-IOS-XR-ipv4-bgp-oper:bgp
BGPメッセージレートの監視
ネットワークトポロジが不安定な場合、一部のBGPネイバーは更新または取り消しを継続的に送信できます。次に、BGP RRは、このようなルーティングテーブルの変更をすべてのRRクライアントに対して数千回複製する必要があります。したがって、不安定性の原因を追跡するには、ネイバーから受信するメッセージレートをモニタすることが重要です。
コマンド：
show bgp <AFI> <SAFI> summary
例：
RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100
RRクライアントキューのMsgSentの量はほぼ同じですが、一部のネイバーは他のネイバーよりも多い数のMsgRcvdを保持できます。メッセージのレートを評価するには、このコマンドの複数のスナップショットをキャプチャする必要があります。
問題のピアを特定したら、show bgp neighbor
、show bgp neighbor
、show bgp recent-prefixesなどの他のコマンドを実行して、どのプレフィックスがフラッピングしているか、また常に同じプレフィックスか別のプレフィックスであるかを把握できます。
注：MsgRcvdおよびMsgSentのカウンタはネイバーごとですが、アドレスファミリごとではありません。そのため、show bgp all all summaryなどのコマンドを実行すると、さまざまなアドレスファミリのセクションでネイバーごとに同じカウンタが表示されます。これらは、そのアドレスファミリのネイバーとの間で送受信されるメッセージの数ではなく、複数のアドレスファミリ間のメッセージの数です。
CPU使用率の監視
すべてのルータでCPU使用率を監視する必要がありますが、コントロールプレーン専用のCPUコアの数が多いルータでは、一部の読み取りが直感的に理解できない場合があります。ルーティングプロセッサ(RP)専用のCPUコアの数が多いBGP RRでは、XRv9kアプライアンスの場合と同様に、アクティブスレッドは異なるCPUコアで動作しますが、多くのCPUコアはアイドル状態のままです。その結果、一部のCPUコアは非常にビジー状態になる可能性がありますが、すべてのCPUコアについて計算された全体的なCPU使用率は中程度のままです。
そのため、CLIを使用してCPUコアの使用率を適切に監視するには、show processes cpu threadコマンドを使用します。
TCP統計情報の監視
Cisco IOS®は、各TCPセッションの詳細な統計情報を維持します。CLIコマンドshow tcp briefは、既存のすべてのTCPセッションのリストを表示します。この要約出力では、各TCPセッションについて次の情報を確認できます。
- PCB:一意のTCPセッション識別子。
- VRF-ID：セッションが存在するVRFのID。
- 対応するVRF名を表示するには、次のコマンドを実行します。
show cef vrf all summary | utility egrep "^VRF:|Vrfid" | utility egrep -B1
- Recv-Q：受信キューの瞬間的なサイズ。受信キューはNetIOから受信したパケットを保持します。tcpプロセスはパケットからデータを抽出し、対応するアプリケーションにそれを送信します。
- Send-Q：送信Qの瞬間的なサイズ。送信キューは、アプリケーションから受信したデータを保持します。tcpプロセスはデータをTCPセグメント(ネゴシエートされた最大セグメントサイズ(TCP MSS)で指定)に分割し、各セグメントを対応するアドレスファミリ（IPv4またはIPv6）のレイヤ3ヘッダーにカプセル化して、パケットをNetIOに送信します。
- ローカルアドレス:TCPソケットに関連付けられたローカルIPv4またはIPv6アドレス。LISTEN状態のTCPセッションは通常、「any」のIPアドレスにバインドされます。これは、IPv4の場合は「0.0.0.0」と、IPv6の場合は「::」と表されます。
- 外部アドレス:TCPソケットに関連付けられているリモートIPv4またはIPv6アドレス。LISTEN状態のTCPセッションは通常、「any」のIPアドレスにバインドされます。これは、IPv4の場合は「0.0.0.0」と、IPv6の場合は「::」と表されます。
- State:TCPセッションの状態。TCPセッションの状態には、LISTEN、SYNSENT、SYNRCVD、ESTAB、LASTACK、CLOSING、CLOSEWAIT、FINWAIT1、FINWAIT2、TIMEWAIT、CLOSEDがあります。
既知のBGPポート番号が179であるため、表示されるTCPセッションを、BGPアプリケーションに関連付けられたセッションに制限できます。
例：
RP/0/RSP0/CPU0:ASR9k-B#show tcp brief | include "PCB|:179 " PCB VRF-ID Recv-Q Send-Q Local Address Foreign Address State 0x00007ff7d403bde0 0x60000000 0 0 :::179 :::0 LISTEN 0x00007ff7d403b020 0x60000002 0 0 :::179 :::0 LISTEN 0x00007ff7d403d130 0x60000000 0 0 192.168.0.4:50144 192.168.0.5:179 ESTAB 0x00007ff7a4025650 0x60000000 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN 0x00007ff7a4024a50 0x60000002 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN
表示されたPCB値を使用して、特定のTCPセッションの統計情報を取得できます。TCPプロセスの統計情報を表示するCLIコマンド：
グローバル：
show tcp statistics clients location <active_RP>
show tcp statistics summary location <active_RP>
PCB単位：
show tcp brief | i ":179"
show tcp detail pcb <pcb> location 0/RP0/CPU0
show tcp statistics pcb <pcb> location <active_RP>
グローバルTCP statisticsコマンドは、TCPセッションの全体的な健全性を表示します。データパケットの統計情報(in/out)とは別に、たとえば、チェックサムエラー、不正なパケット、認証エラーによるドロップされたパケット、不正なパケット、Data Afterウィンドウを持つパケットの有無を確認できます。この情報から、TCPピアの動作がわかります。
PCB単位のコマンドでは、MSS、最大ラウンドトリップ時間など、TCPセッションの重要なパラメータを確認できます。
show tcp detail pcbコマンドの出力の関連カウンタは次のとおりです。
- Retrans Timer Starts：再送信タイマーが開始した回数を示します。
- Retrans Timer Wakeups：再送信タイマーが使い果たされた回数を示し、TCPセグメントの再送信がトリガーされます。
- 現在の送信キューのサイズ（バイト単位）：ピアからの確認応答されていないバイト。
- 現在の受信キューのサイズ(バイト/パケット単位)：アプリケーション(BGP)による読み取りが未完了のバイト/パケット。
- mis-ordered bytes:TCP受信ウィンドウにホールがあるためにセーブキューにキューイングされるバイト。
RP/0/RSP0/CPU0:ASR9k-B#show tcp detail pcb 0x4a4400e4 ============================================================== Connection state is ESTAB, I/O status: 0, socket status: 0 Established at Sat Apr 20 18:26:26 2024 PCB 0x4a4400e4, SO 0x4a42c0ac, TCPCB 0x4a43b708, vrfid 0x60000000, Pak Prio: Normal, TOS: 64, TTL: 255, Hash index: 402 Local host: 10.10.10.229, Local port: 179 (Local App PID: 856311) Foreign host: 10.10.10.254, Foreign port: 46980 (Local App PID/instance/SPL_APP_ID: 856311/0/0) Current send queue size in bytes: 0 (max 16384) Current receive queue size in bytes: 0 (max 65535) mis-ordered: 0 bytes Current receive queue size in packets: 0 (max 60) Timer Starts Wakeups Next(msec) Retrans 2795 0 0 SendWnd 1341 0 0 TimeWait 0 0 0 AckHold 274 2 0 KeepAlive 333 1 299983 PmtuAger 0 0 0 GiveUp 0 0 0 Throttle 0 0 0 FirstSyn 0 0 0 iss: 2030796738 snduna: 2034498828 sndnxt: 2034498828 sndmax: 2034498828 sndwnd: 3291 sndcwnd: 4200 irs: 285455091 rcvnxt: 285455710 rcvwnd: 64917 rcvadv: 285520627
SRTT: 162 ms, RTTO: 415 ms, RTV: 253 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 247 ms ACK hold time: 200 ms, Keepalive time: 300 sec, SYN waittime: 30 sec Giveup time: 0 ms, Retransmission retries: 0, Retransmit forever: FALSE Connect retries remaining: 0, connect retry interval: 0 secs <...> RP/0/RSP0/CPU0:ASR9k-B#
メモリ使用率の監視
BGPルートテーブルは、BGPプロセスのヒープメモリに保存されます。ルーティングテーブルはRIBプロセスのヒープメモリに保存されます。
ヒープメモリモニタリングに便利なコマンド：
show memory summary
show memory summary detail
show memory-top-consumers
show memory heap summary all
テレメトリセンサーパス：
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail
FIBは、転送エントリを共有メモリ領域に保存します。
共有メモリの監視に便利なコマンド：
show memory summary
show memory summary detail
show shmwin summary
BGPプロセスのパフォーマンスの監視
BGPプロセスのパフォーマンスに関する内部データを提供する便利なコマンド：
show bgp process performance-statistics
show bgp process performance-statistics detail
BGPコンバージェンスの監視
もう1つの便利なコマンドは、BGPコンバージェンスの全体的なステータスを表示するコマンドです。 show bgp convergence
ネットワークが安定している場合は、次のように表示されます。
RP/0/RP0/CPU0:ASR9k-B#show bgp convergence Mon Dec 18 13:55:47.976 UTC Converged. All received routes in RIB, all neighbors updated. All neighbors have empty write queues. RP/0/RP0/CPU0:ASR9k-B#
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
01-Aug-2024 |
初版 |
フィードバック