IP : ボーダー ゲートウェイ プロトコル(BGP)

遅いピア問題を解決するのに BGP 「遅いピア」機能を使用して下さい

2016 年 6 月 18 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2016 年 4 月 21 日) | フィードバック

概要

この資料に BGP更新 グループの遅いピアを識別し、アップデート グループから遅いピアを永久にまたは一時的に移動できる Border Gateway Protocol (BGP)遅いピア 機能の使用における遅いピア問題を解決する方法を記述されています。

Contributed by Luc De Ghein, Cisco TAC Engineer.

背景説明

このセクションは遅いピア 機能の外観およびアップデート グループの使用を提供します。

アップデート グループ

遅いピア 機能はアップデート グループで使用されます。 アップデート グループは同じアウトバウンドポリシーの BGPピアをグループ化するために使用する動的メソッドです。 アップデート グループの利点は次にメッセージを一度フォーマットするためにグループ ポリシーが使用される彼らはグループの他のメンバーに複製され、送信されますことであり。 この方式は各ピアのための BGP更新を別々にフォーマットする必要より効率的です。

この方式が設定されている時、アウトバウンド ポリシー の 変更がアップデート グループごとに、同位グループ変更する場合。 アップデート グループはアドレス ファミリー(AF)ごとに形成されます。

AF IPv4 ユニキャストのための、しかし AF VPNv4 のための同じアップデート グループの異なるアップデート グループの 2 人の BGPピアの例はここにあります:

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  Has 1 member (* indicates the members currently being sent updates):
   10.1.3.4

BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
  Has 1 member (* indicates the members currently being sent updates):
   10.1.2.3

R2#show ip bgp vpnv4 all update-group
BGP version 4 update-group 1, external, Address Family: VPNv4 Unicast
  Has 2 members (* indicates the members currently being sent updates):
   10.1.2.3         10.1.3.4

アップデート グループはアップデート グループ増加に含まれている数 BGPピアとして効率的になります。 通常、Internal BGP (iBGP)同位に同じアウトバウンドポリシーがあります。 iBGP の場合、ルート リフレクタ(RR)は多くの iBGP 同位がある場合があります; 従って、それに大きいアップデート グループがあります。 Provider Edge (PE) ルータは 1 基のバーチャル/ルーティング転送の Customer Edge (CE) ルータの方の多くの external BGP (eBGP) 同位がある場合があります(VRF)。 PE ルータは VRF インターフェイスの CE ルータとのピアリングのための大きいアップデート グループを同様に備える場合があります。

問題

遅いピアはルータがアップデート グループの時間の BGP更新 メッセージを(分の順序で)長い期間にわたって生成する比率に遅れずについていくことができないピアです。 この理由は耐久性があるネットワーク上の問題である場合もあります。 ネットワーク原因はパケットロスやロードされたリンクである可能性がありますまたはスループットは BGPセッションにおいての発行します。 また、BGPピアは CPU の点では過剰にロードされるかもしれないし、必要な速度の TCP 接続を保守できません。

遅い同位影響完全なアップデート グループの BGP 統合。 1 人の BGPピアが遅い場合、それにより全体のアップデート グループは減速します。 結果は他のアップデート グループ メンバーにより遅い統合が同様にあることです。 従って、問題は解決されるはずです。

遅いピアを識別し、アップデート グループからそれを移動できます。 このタスクを完了するために、その BGPピアのためのアウトバウンドポリシーを変更できます; ただし、これは手動タスクです。 遅い識別し、次にアップデート グループからそれを最初にピアを移動して下さい。 遅いピア 機能はユーザ 介入が必要とならないようにこれを自動的にすることができます。

解決策

遅いピア 機能へ 3 人の部があります:

  • 遅いピアの検出

  • 遅いアップデート グループへの遅いピアの移動

  • (オリジナル アップデート グループに戻って回復 された ピアを移動する)のリカバリ遅いピア

これらのプロセスは続くセクションの更に詳しい情報に説明があります。

検出方法

遅いピア 機能はアップデート グループの遅い同位を検出する。 各アップデート グループにフォーマットされていた BGP更新が伝達の前に一時的に保存されるキャッシング キューがあります。

そのようなアップデート グループ キャッシュの例はここにあります:

R2#show ip bgp replication

                                                                    Current    Next
Index  Members          Leader       MsgFmt    MsgRepl     Csize    Version Version
    1        1        10.1.1.1            0          0    0/100           6/0
    2        3        10.1.2.3            2          6    0/1000          6/0
    3        1        10.1.2.6            3          0    0/100           6/0

キャッシュのサイズは動的に計算され、依存します:

  • アップデート グループの同位の数

  • インストール済みシステムメモリ

  • アップデート グループの同位の種類

  • AF の種類

伝達を待つフォーマットされていた BGP更新の数は 1 アップデート グループで 1 ピア(遅い 1)が他のメンバー程に BGP メッセージをすぐに確認しないとき構築できます。 キャッシュ制限が達するとき、グループに新しいメッセージを並べるもうクォータがありません。 新しいメッセージは(いくつかのメッセージが遅いピアによって確認されるまで)キャッシュが減るまでフォーマットしていることができません。 これは BGPピアを禁止し、それがグループのより速いメンバーに新しいメッセージを(更新はまたは撤回します)送ることを可能にしません。 それ故に、これはアップデート グループのすべての同位の統合を減速します。

遅いピアを識別する遅いピア 機能のためにそれは BGP更新タイムスタンプおよびピア TCP パラメータを示します。

遅いピア 検出はデフォルトでディセーブルにされます。 遅いピア検知を有効にするために、これらのメソッドの 1 つを使用して下さい:

  • BGPプロセスのための機能を有効に して下さい(AF/VRF から設定することができます):
    bgp slow-peer detection [threshold <seconds>]

    [no] bgp slow-peer detection

    : 閾値は 120 秒から 3,600 秒の間に及ぶことができデフォルト値は 300 秒です。

  • ピアごとの機能を有効に して下さい:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection [threshold < seconds >]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection
  • ピア ポリシー テンプレートで機能を有効に して下さい:
    slow-peer detection [threshold < seconds >]

    [no] slow-peer detection

遅いピアが検出するとき、これと同じような syslog メッセージは印刷されます:

%BGP-5-SLOWPEER_DETECT: Neighbor IPv4 Unicast 10.1.6.7 has been detected
as a slow peer.

遅い同位を表示するためにこれらの show コマンドを入力できます:

  • 遅い show ip bgp summary

  • 遅い show ip bgp neighbors

  • 遅い show ip bgp アップデート グループ概略

遅いキーワードが使用されるとき showコマンド出力例はここにあります:

R2#show ip bgp update-group summary slow
Summary for  Update-group 1, Address Family IPv4 Unicast
Summary for  Update-group 2, Address Family IPv4 Unicast
Summary for  Update-group 3, Address Family IPv4 Unicast
Summary for  Update-group 4, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 966013, main routing table version 966013
BGP main update table version 966013
50000 network entries using 6050000 bytes of memory
50000 path entries using 2600000 bytes of memory
5001/5000 BGP path/bestpath attribute entries using 700140 bytes of memory
5000 BGP AS-PATH entries using 183632 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9533772 total bytes of memory
BGP activity 208847/158847 prefixes, 508006/458006 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.6.7        4     7     165   50309        0    0  100 00:10:35        0

出力に示すように、ピア 10.1.6.7 は AF IPv4 ユニキャストのための遅いピアです。 他の AF は遅い同位を示しません。

現在 検出 タイマー実行および値が、このコマンドを入力するかどうか確かめるため:

R2#show ip bgp update-group
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
  BGP Update version : 116013/0, messages 164 queue 164, not converged
  Private AS number removed from updates to this neighbor
  Update messages formatted 5948, replicated 11589
  Number of NLRIs in the update sent: max 249, min 1
  Minimum time between advertisement runs is 30 seconds
Slow-peer detection timer (expires in 111 seconds)
  Has 3 members (* indicates the members currently being sent updates):
   10.1.4.5         10.1.5.6         10.1.6.7       

出力例に示すように、検出 タイマーは開始しました。 検出 タイマーはアップデート グループ キャッシュが完全であると開始します。

この例では、遅いピア 検出 タイマーが切れた後だけ遅いピアが検出するが、アップデート グループを出て行くことがわかります:

R2#show ip bgp update-group

BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
  BGP Update version : 516013/566013, messages 357 queue 357, not converged
  Private AS number removed from updates to this neighbor
  Update messages formatted 27044, replicated 53645
  Number of NLRIs in the update sent: max 249, min 0
  Minimum time between advertisement runs is 30 seconds
  Slow-peer detection timer (expires in 20 seconds)
  Has 3 members (* indicates the members currently being sent updates)
  (1 dynamically detected as slow):

  *10.1.4.5        *10.1.5.6         10.1.6.7

ピア 識別を遅らせて下さい

遅いピア 検出 機能が有効に ならない場合、遅いピアを手動で識別して下さい。 最初に、アップデート グループの同位のテーブルバージョンおよび出力キューをチェックして下さい:

R2#show ip bgp update-group 3 summary
Summary for  Update-group 3, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 552583, main routing table version 552583
BGP main update table version 552583
37870 network entries using 4582270 bytes of memory
37870 path entries using 1969240 bytes of memory
5002/3788 BGP path/bestpath attribute entries using 700280 bytes of memory
5001 BGP AS-PATH entries using 183656 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7435446 total bytes of memory
BGP activity 158847/108847 prefixes, 295876/258006 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.4.5        4     5      77   26840   516013    0    0 01:07:12        0
10.1.5.6        4     6      69   26833   516013    0    0 01:00:30        0
10.1.6.7        4     7      79   26761   516013    0  194 00:45:42        0

この例では、同位のテーブルバージョン(TblVer)が主要な BGPテーブル バージョンに追いつくか、または後ろ常にあるかどうか確かめて下さい。 2 番目に、非常に高出力キュー 値と 1つ以上の同位があるように確認して下さい。 これらが遅い同位である可能性が高いといえます。

疑われた遅い BGPピアを表示するとき、これらの質問を考慮して下さい(BGPセッションの両側で):

  • どの位前に最後は書きます実行されてありましたか。

  • キープアライブはスロットルにありますか。

  • 出力キューは高いですか。

  • SRTT/RTTO は高いですか。

  • 数の再送信します増加するためにか。

  • 並べられるあらゆる再送信しますパケットをありますか。

  • TCP Send ウィンドウまたはゼロは非常に低くありますか。

次に例を示します。

R2#show ip bgp neighbors 10.1.6.7
BGP neighbor is 10.1.6.7,  remote AS 7, external link
Member of peer-group group3 for session parameters
  BGP version 4, remote router ID 10.1.6.7
  BGP state = Established, up for 00:56:09
  Last read 00:00:43, last write 00:00:17, hold time is 180, keepalive interval
is 60 seconds
  Keepalives are temporarily in throttle due to closed TCP window
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast:
advertised and received
  Message statistics
    InQ depth is 0
    OutQ depth is 0    Partial message pending
                         Sent       Rcvd
    Opens:                  5          4
    Notifications:          0          0
    Updates:            29004          0
    Keepalives:             0       1426
    Route Refresh:          0          0
    Total:              30336       1431
  Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
  BGP table version 250001, neighbor version 200001/250001
  Output queue size : 410
  Index 3, Offset 0, Mask 0x8
  3 update-group member
  group3 peer-group member
  Inbound soft reconfiguration allowed
  Private AS number removed from updates to this neighbor
  Inbound path policy configured
  Route map for incoming advertisements is eBGP-in
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:            2596          0
    Prefixes Total:            102624          0
    Implicit Withdraw:             28          0
    Explicit Withdraw:         100000          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Maximum prefixes allowed 20000
  Threshold for warning message 80%, restart interval 300 min
  Number of NLRIs in the update sent: max 249, min 0
  Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
  Oldest update message was formatted: 00:02:24
  Address tracking is enabled, the RIB does have a route to 10.1.6.7
  Connections established 4; dropped 3
  Last reset 00:57:39, due to User reset
  Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0      
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.6.2, Local port: 20298
Foreign host: 10.1.6.7, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 15
, input: 0  mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x4A63D14):
Timer          Starts    Wakeups            Next
Retrans           697         29       0x4A6590C
TimeWait            0          0             0x0
AckHold            64         63             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger          128        127       0x4A64CB7
DeadWait            0          0             0x0
Linger              0          0             0x0

iss:  130287252  snduna:  131516888  sndnxt:  131532233     sndwnd:  16384
irs: 1184181084  rcvnxt: 1184182346  rcvwnd:      15123  delrcvwnd:   1261

SRTT: 20122 ms, RTTO: 20440 ms, RTV: 318 ms, KRTT: 0 ms
minRTT: 20028 ms, maxRTT: 20796 ms, ACK hold: 200 ms
Status Flags: none
Option Flags: nagle, path mtu capable, higher precendence

Datagrams (max data segment is 1460 bytes):
Rcvd: 922 (out of order: 0), with data&colon; 65, total data bytes: 1261
Sent: 1463 (retransmit: 29 fastretransmit: 1),with data&colon; 1391, total
data bytes: 1245129

移動

このセクションは遅いピア 機能に関して移動プロセスをさまざまなシナリオで説明します。

遅いピア 機能のない移動

遅いピアは遅いピア 機能なしで新しいアップデート グループに手動で移動することができます。

遅いピア 機能が利用できた前に、遅いピアを識別し、次にアップデート グループからそれを手動で移動するために必要となりました。 これはその BGPピアのアウトバウンドポリシーへの変更と完了します。 このアウトバウンドポリシーは遅いピアは現在 存在 します別のアップデート グループに移動しないようにする必要があるように、使用される他のどのと異なる必要があり、(そのアップデート グループに問題を移動して下さい)。 加えることができる最もよい変更は実際のポリシーに影響を与えない 1 つです。 たとえば、ピアの最小ルート アドバタイズメント 間隔(MRAI)を変更する可能性があります(仕様 AF の下で)。

遅いピア 機能が利用できないとき遅いピアの手動移動を示す例はここにあります:

RR1#debug ip bgp groups 
BGP groups debugging is on

RR1(config)#router bgp 1                                   
RR1(config-router)#address-family vpnv4                          
RR1(config-router-af)#neighbor 10.100.1.3 advertisement-interval 3 

BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
mismatch
BGP(4): Scheduling withdraws and update-group membership change for 10.100.1.3
BGP(4): Resetting 10.100.1.3's version for its transition out of update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
mismatch
BGP-DYN(4): Removing 10.100.1.3 from update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
mismatch
BGP-DYN(4): Created update-group 0 from neighbor 10.100.1.3
BGP-DYN(4): Adding 10.100.1.3 to update-group 0

静的ピア移動を遅らせて下さい

1 ピアを新しいアップデート グループにアップデート グループから移動するために、静的ので遅らせますピアをそれを設定できます。 多重遅い同位がある場合、同じアウトバウンドポリシーの静的で遅い同位は同じ遅いアップデート グループに置かれます。

遅いピアを静的に移動するために、これらのコマンドの使用でそれを設定できます:

  • ネイバーまたは peer-group ごとの静的なピア移動を有効に して下さい:
    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group static
  • ピア ポリシー テンプレートで静的なピア移動を有効に して下さい:
    [no] slow-peer split-update-group static

ダイナミック ピア移動を遅らせて下さい

遅いピア移動はデフォルトでディセーブルにされます。 遅いピア移動を有効に するために、これらのメソッドの 1 つによってそれを設定できます:

  • イネーブル BGPプロセスのための遅いピア移動:
    bgp slow-peer split-update-group dynamic [permanent]

    [no] bgp slow-peer split-update-group dynamic

    : これは address-family/topology/VRF ビューから設定することができます。

  • イネーブル ピアごとの遅いピア移動:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group dynamic [permanent]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group dynamic
  • ピア ポリシー テンプレートで遅いピア移動を有効に して下さい:
    slow-peer split-update-group dynamic [permanent]

    [no] slow-peer split-update-group dynamic

常置キーワードは遅いピアが自動的に回復 しないことを示します。 この場合、clear コマンドの 1 つによってオリジナル アップデート グループに戻って回復 された遅いピアを移動できます

静的で遅い同位およびダイナミック遅い同位は同じ遅いピア アップデート グループにあります。 この例で遅いアップデート グループの 1 遅いピアを次のように表示できます:

R2#show ip bgp update-group

BGP version 4 update-group 4, external, Address Family: IPv4 Unicast
  BGP Update version : 0/566013, messages 100 queue 100, not converged
  Slow update group
  Private AS number removed from updates to this neighbor
  Update messages formatted 2497, replicated 0
  Number of NLRIs in the update sent: max 10, min 1
  Minimum time between advertisement runs is 30 seconds
  Has 1 member (* indicates the members currently being sent updates)
  (1 dynamically detected as slow):
  *10.1.6.7

Recovery

遅いピアはオリジナル アップデート グループの下でそれはもはや遅いピア(追いつきます)ではないことが確認されればことができます(アウトバウンドポリシーと一致しますその)再グループ化する。 リカバリ タイマーは遅いピア アップデート グループがコンバージしたと開始します。 リカバリ タイマーが切れるとき、遅いピアは定期的なアップデート グループに戻って移動されます。

検出/リカバリ タイマーと関連している動作を見るために、debug ip bgp updates イベント コマンドを入力して下さい。

遅いピアがオリジナル アップデート グループに戻って(これはリカバリを意味します)移動される時、これと同じような syslog メッセージは印刷されます:

%BGP-5-SLOWPEER_RECOVER: Slow peer IPv4 Unicast 10.1.6.7 has recovered.

現在リカバリ タイマー実行および値が、このコマンドを入力するかどうか確かめるため:

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  BGP Update version : 165973/0, messages 0 queue 0, converged
  Route map for outgoing advertisements is dummy
  Update messages formatted 0, replicated 0
  Number of NLRIs in the update sent: max 0, min 0
  Minimum time between advertisement runs is 30 seconds
  Slow-peer recovery timer (expires in 16 seconds)
  Has 1 member (* indicates the members currently being sent updates):
   10.1.1.1

この例では、16 秒の値のリカバリ タイマーは、可能性のある遅いピアが 16 秒のオリジナル アップデート グループに戻って移動するかもしれませんことを示します。

この例では、遅いピア ステータスから回復 した ピアを表示できます:

R2#show ip bgp neighbor 10.1.6.7 

BGP neighbor is 10.1.6.7,  remote AS 7, external link
Member of peer-group group3 for session parameters
  BGP version 4, remote router ID 10.1.6.7

3 update-group member
  group3 peer-group member

Number of NLRIs in the update sent: max 249, min 0
  Last detected as dynamic slow peer: 00:12:49
  Dynamic slow peer recovered: 00:01:57
Oldest update message was formatted: 00:00:55

遅いピア ステータスをクリアして下さい

遅いピア ステータスはこれらのコマンドで手動でクリアすることができます:

  • 遅い clear ip bgp *

  • clear ip bgp AF {ユニキャスト|遅いマルチキャスト} <AS number>

  • clear ip bgp AF {ユニキャスト|マルチキャスト} peer-group <group 名前は > 遅れます

  • 遅い clear ip bgp <neighbor-address>

  • クリア bgp AF {ユニキャスト|マルチキャスト} *遅らせて下さい

  • bgp AF {ユニキャストをクリアして下さい|遅いマルチキャスト} <AS number>

  • クリア bgp AF {ユニキャスト|マルチキャスト} peer-group <group 名前は > 遅れます

  • クリア bgp AF {ユニキャスト|遅いマルチキャスト} <neighbor-address>

: これらのコマンドを使用するとき、実 アドレス ファミリーによって AF を取り替えて下さい。

これらのコマンドの使用によって、ピアはオリジナル アップデート グループに戻って移動されます。

遅いピア 検出および移動設定を表示するために show ip bgp 内部コマンドを入力して下さい:

R2#show ip bgp internal
Time left for bestpath timer: 593 secs
Address-family IPv4 Unicast, Mode : RW
    Table Versions : Current 622091, RIB 622091
    Start time : 00:00:01.168    Time elapsed 01:21:56.740
    First Peer up in : 00:00:07    Exited Read-Only in : 00:02:16
    Done with Install in : 00:02:26    Last Update-done in : never
    0 updates expanded
    Attribute list queue size: 0
    Slow-peer detection is enabled  Threshold is 300 seconds
    Slow-peer split-update-group dynamic is enabled

    BGP Nexthop scan:-
        penalty: 0, Time since last run: never,  Next due in: none
        Max runtime : 0 ms Latest runtime : 0 ms Scan count: 0
    BGP General Scan:-
        Max runtime : 14572 ms Latest runtime : 14572 ms Scan count: 78
    BGP future scanner version: 79
    BGP scanner version: 0

: 要約すると、BGP 遅いピアはアップデート グループから BGP更新 グループの遅いピアおよび遅いピアの移動とのより速い BGP 統合を可能にを検出する 機能です。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 119000