Inhalt

Einführung

Hintergrundinformationen

Gruppen aktualisieren

Problem

Lösung

Erkennung

Langsame Peer-Identifizierung

Bewegung

Bewegung ohne langsame Peer-Funktion

Statische langsame Peer-Bewegung

Dynamische, langsame Peer-Bewegung

Wiederherstellung

Löschen Sie den langsameren Peer-Status.

Einführung

In diesem Dokument wird beschrieben, wie ein langsame Peer-Problem durch die Verwendung der langsamen Border Gateway Protocol (BGP)-Peer-Funktion gelöst werden kann, die einen langsamen Peer in einer BGP-Update-Gruppe identifiziert und den langsamen Peer dauerhaft oder vorübergehend aus der Update-Gruppe entfernen kann.

Hintergrundinformationen

Dieser Abschnitt bietet eine Übersicht über die langsame Peer-Funktion und die Verwendung von Update-Gruppen.

Gruppen aktualisieren

Die Funktion "slow peer" wird in Aktualisierungsgruppen verwendet. Eine Aktualisierungsgruppe ist eine dynamische Methode, mit der BGP-Peers mit derselben Richtlinie für ausgehenden Datenverkehr gruppiert werden. Der Vorteil von Aktualisierungsgruppen besteht darin, dass die Gruppenrichtlinie verwendet wird, um Nachrichten einmal zu formatieren. Anschließend werden sie repliziert und an die anderen Mitglieder der Gruppe übertragen. Diese Methode ist effizienter als die separate Formatierung von BGP-Updates für jeden Peer.

Wenn diese Methode implementiert ist und sich die Richtlinie für ausgehende Anrufe ändert, ändern sich die Peergruppen je Aktualisierungsgruppe. Die Aktualisierungsgruppen werden nach Adressenfamilie (Address Family, AF) gebildet.

Im Folgenden finden Sie ein Beispiel für zwei BGP-Peers in verschiedenen Aktualisierungsgruppen für AF-IPv4-Unicast, jedoch mit derselben Aktualisierungsgruppe für AF-VPNv4:

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

Die Aktualisierungsgruppe wird effizienter, wenn die Anzahl der BGP-Peers, die in der Aktualisierungsgruppe enthalten sind, zunimmt. In der Regel haben interne BGP (iBGP)-Peers die gleiche Richtlinie für ausgehenden Datenverkehr. Für iBGP kann ein Route Reflector (RR) viele iBGP-Peers haben. Daher werden große Aktualisierungsgruppen vorhanden sein. Provider Edge (PE)-Router können in einem Virtual/Routing Forwarding (VRF) viele externe BGP (eBGP)-Peers zum Kunden-Edge (CE)-Router aufweisen. Die PE-Router können auch große Update-Gruppen für Peerings mit CE-Routern an den VRF-Schnittstellen aufweisen.

Problem

Ein langsamer Peer ist ein Peer, der nicht mit der Geschwindigkeit Schritt halten kann, mit der der Router BGP-Aktualisierungsnachrichten über einen längeren Zeitraum (in der Reihenfolge von Minuten) in einer Aktualisierungsgruppe generiert. Der Grund hierfür können persistente Netzwerkprobleme sein. Netzwerkgründe können Paketverluste und/oder geladene Links oder Durchsatzprobleme bei den BGP-Sitzungen sein. Außerdem kann ein BGP-Peer in Bezug auf die CPU stark ausgelastet sein und die TCP-Verbindung nicht mit der erforderlichen Geschwindigkeit bedienen können.

Langsame Peers wirken sich auf die BGP-Konvergenz der gesamten Aktualisierungsgruppe aus. Wenn ein BGP-Peer langsam ist, führt dies dazu, dass die gesamte Aktualisierungsgruppe langsamer wird. Das Ergebnis ist, dass die anderen Mitglieder der Aktualisierungsgruppe auch eine langsamere Konvergenz aufweisen. Aus diesem Grund sollte das Problem gelöst werden.

Sie können den langsamen Peer identifizieren und ihn aus der Aktualisierungsgruppe entfernen. Um diese Aufgabe abzuschließen, können Sie die Richtlinie für ausgehenden Datenverkehr für diesen BGP-Peer ändern. Dies ist jedoch eine manuelle Aufgabe. Sie müssen zuerst den langsamen Peer identifizieren und ihn dann aus der Aktualisierungsgruppe entfernen. Die langsame Peer-Funktion kann dies automatisch durchführen, sodass kein Benutzereingriff erforderlich ist.

Lösung

Die langsame Peer-Funktion besteht aus drei Teilen:

- Erkennung des langsamen Peers

- Bewegung des langsamen Peers in eine langsame Aktualisierungsgruppe

- Wiederherstellung des langsamen Peers (der den wiederhergestellten Peer wieder in seine ursprüngliche Aktualisierungsgruppe zurückversetzt)

Diese Prozesse werden in den folgenden Abschnitten genauer beschrieben.

Erkennung

Die langsame Peer-Funktion erkennt langsame Peers in einer Aktualisierungsgruppe. Jede Aktualisierungsgruppe verfügt über eine Caching-Warteschlange, in der formatierte BGP-Updates temporär vor der Übertragung gespeichert werden.

Hier ein Beispiel für einen solchen Aktualisierungsgruppencache:

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

Die Größe des Cache wird dynamisch berechnet und hängt von folgenden Faktoren ab:

- Die Anzahl der Peers in der Aktualisierungsgruppe

- Der installierte Systemspeicher

- Der Peertyp in der Aktualisierungsgruppe

- Der AF-Typ

Die Anzahl der formatierten BGP-Updates, die auf die Übertragung warten, kann in einer Update-Gruppe erstellt werden, wenn ein Peer (der langsame) die BGP-Nachrichten nicht so schnell wie die anderen Mitglieder erkennt. Wenn der Cache-Grenzwert erreicht ist, verfügt die Gruppe nicht über mehr Kontingente, um neue Nachrichten in die Warteschlange zu stellen. Neue Nachrichten können erst formatiert werden, wenn der Cache reduziert wurde (bis einige Nachrichten von den langsamen Peers bestätigt wurden). Dies untersagt dem BGP-Peer und ermöglicht es ihm nicht, neue Nachrichten (Updates oder Rückzug) an die schnelleren Mitglieder der Gruppe zu senden. Dadurch wird die Konvergenz aller Peers in der Aktualisierungsgruppe verlangsamt.

Damit die langsame Peer-Funktion einen langsamen Peer identifiziert, bezieht sie sich auf die BGP-Aktualisierungs-Zeitstempel und Peer-TCP-Parameter.

Die langsame Peer-Erkennung ist standardmäßig deaktiviert. Verwenden Sie eine der folgenden Methoden, um die langsame Peer-Erkennung zu aktivieren:

- Aktivieren Sie die Funktion für den BGP-Prozess (kann über AF/VRF konfiguriert werden):

bgp slow-peer detection [threshold

]

[no] bgp slow-peer detection

Hinweis: Der Grenzwert kann zwischen 120 und 3.600 Sekunden liegen, der Standardwert beträgt 300 Sekunden.

- Aktivieren Sie die Funktion pro Peer:

neighbor {

/

} slow-peer detection [threshold < seconds >]

[no] neighbor {

/

} slow-peer detection

- Aktivieren Sie die Funktion mithilfe der Peer-Richtlinienvorlage:

slow-peer detection [threshold < seconds >]

[no] slow-peer detection

Wenn ein langsamer Peer erkannt wird, wird eine ähnliche Syslog-Meldung ausgegeben:

%BGP-5-SLOWPEER_DETECT: Neighbor IPv4 Unicast 10.1.6.7 has been detected

as a slow peer.

Sie können die folgenden show-Befehle eingeben, um die langsamen Peers anzuzeigen:

- show ip bgp summary langsam

- show ip bgp neighbors slow

- show ip bgp update-group summary slow

Im Folgenden finden Sie ein Beispiel show-Befehlsausgabe, wenn das slow-Schlüsselwort verwendet wird:

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

Wie in der Ausgabe gezeigt, ist der Peer 10.1.6.7 ein langsamer Peer für das AF-IPv4-Unicast. Die anderen AFs zeigen keine langsamen Peers an.

Geben Sie den folgenden Befehl ein, um zu überprüfen, ob der Erkennungs-Timer derzeit ausgeführt wird und welchen Wert er hat:

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

Wie in der Beispielausgabe gezeigt, wurde der Erkennungs-Timer gestartet. Der Erkennungs-Timer startet, wenn der Aktualisierungsgruppencache voll ist.

In diesem Beispiel sehen Sie, dass ein langsamer Peer erkannt wird, der jedoch erst nach Ablauf des Timers für langsame Peer-Erkennung aus der Update-Gruppe entfernt wird:

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

Langsame Peer-Identifizierung

Wenn die Funktion zur langsamen Peer-Erkennung nicht aktiviert ist, müssen Sie den langsamen Peer manuell identifizieren. Überprüfen Sie zunächst die Tabellenversion und die Ausgabewarteschlange der Peers in der Aktualisierungsgruppe:

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

In diesem Beispiel überprüfen Sie, ob die Tabellenversion (TblVer) der Peers die Hauptversion der BGP-Tabelle jemals abfängt oder immer zurückliegt. Prüfen Sie anschließend, ob mindestens ein Peer mit sehr hohen Ausgabewarteschlangenwerten vorhanden ist. Es ist wahrscheinlich, dass dies die langsamen Peers sind.

Wenn Sie den vermutlich langsamen BGP-Peer anzeigen, berücksichtigen Sie folgende Fragen (auf beiden Seiten der BGP-Sitzung):

- Wie lange wurde die letzte Ausgabe ausgeführt?

- Sind die Keepalives gedrosselt?

- Ist die Ausgabewarteschlange hoch?

- Ist SRTT/RTTO hoch?

- Erhöht sich die Anzahl der Neuübertragungen?

- Gibt es Warteschlangen für die erneute Übertragung von Paketen?

- Ist das TCP-Sendefenster sehr niedrig oder Null?

Hier ein Beispiel:

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

Bewegung

In diesem Abschnitt wird der Bewegungsprozess in Bezug auf die langsame Peer-Funktion in verschiedenen Szenarien beschrieben.

Bewegung ohne langsame Peer-Funktion

Ein langsamer Peer kann ohne die langsame Peer-Funktion manuell in eine neue Update-Gruppe verschoben werden.

Bevor die Funktion für langsame Peers verfügbar war, mussten Sie den langsamen Peer identifizieren und ihn dann manuell aus der Aktualisierungsgruppe verschieben. Abgeschlossen wird dies durch eine Änderung der Richtlinie für ausgehenden Datenverkehr dieses BGP-Peers. Diese Richtlinie für ausgehende Anrufe muss sich von den anderen Richtlinien unterscheiden, die verwendet werden, da Sie sicherstellen müssen, dass der langsame Peer nicht in eine andere aktuell vorhandene Aktualisierungsgruppe verschoben wird (und das Problem in diese Aktualisierungsgruppe verschieben). Die beste Änderung, die Sie anwenden können, ist eine, die sich nicht auf die tatsächliche Richtlinie auswirkt. Sie können beispielsweise das MRAI (Minimum Route Advertisement Interval) des Peers (unter dem spezifischen AF) ändern.

Das folgende Beispiel zeigt die manuelle Verschiebung eines langsamen Peers, wenn die langsame Peer-Funktion nicht verfügbar ist:

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

Statische langsame Peer-Bewegung

Um einen Peer aus einer Aktualisierungsgruppe in eine neue Aktualisierungsgruppe zu verschieben, können Sie ihn als statischen langsamen Peer konfigurieren. Wenn mehrere langsame Peers vorhanden sind, werden statische langsame Peers mit derselben Richtlinie für ausgehenden Datenverkehr in derselben langsamen Aktualisierungsgruppe platziert.

Um einen langsamen Peer statisch zu verschieben, können Sie ihn mithilfe der folgenden Befehle konfigurieren:

- Statische Peer-Bewegung pro Nachbar oder pro Peer-Gruppe aktivieren:

[no] neighbor {

/

} slow-peer split-update-group static

- Statische Peer-Verlagerung über eine Peer-Richtlinienvorlage aktivieren:

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

Dynamische, langsame Peer-Bewegung

Die langsamere Peer-Bewegung ist standardmäßig deaktiviert. Um die langsame Peer-Bewegung zu aktivieren, können Sie sie mit einer der folgenden Methoden konfigurieren:

- Slow Peer-Verlagerung für den BGP-Prozess aktivieren:

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

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

Hinweis: Dies kann über die address-family/Topologie/VRF-Ansicht konfiguriert werden.

- Langsame Peer-Bewegung pro Peer aktivieren:

neighbor {

/

} slow-peer split-update-group dynamic [permanent]

[no] neighbor {

/

} slow-peer split-update-group dynamic

- Langsame Peer-Verlagerung über eine Peer-Richtlinienvorlage aktivieren:

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

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

Hinweis: Das permanente Schlüsselwort gibt an, dass der langsame Peer nicht automatisch wiederhergestellt wird. In diesem Fall können Sie den wiederhergestellten langsamen Peer über einen der Clear-Befehle wieder in die ursprüngliche Update-Gruppe zurücksetzen.

Die statischen langsamen Peers und dynamischen langsamen Peers befinden sich in derselben langsamen Peer-Update-Gruppe. In diesem Beispiel wird ein langsamer Peer in einer langsamen Aktualisierungsgruppe angezeigt:

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

Wiederherstellung

Ein langsamer Peer kann unter seiner ursprünglichen Aktualisierungsgruppe (die der Richtlinie für ausgehende Datenverkehr entspricht) neu gruppiert werden, sobald bestätigt wird, dass er kein langsamer Peer mehr ist (er fängt an). Der Wiederherstellungs-Timer startet, wenn die Gruppe für langsame Peer-Updates konvergiert ist. Wenn der Wiederherstellungs-Timer abläuft, wird der langsame Peer zurück in die reguläre Aktualisierungsgruppe verschoben.

Hinweis: Um das Verhalten anzuzeigen, das sich auf den Erkennungs-/Wiederherstellungs-Timer bezieht, geben Sie den Befehl debug ip bgp updates events ein.

Wenn ein langsamer Peer zurück in die ursprüngliche Aktualisierungsgruppe verschoben wird (d. h. eine Wiederherstellung), wird eine ähnliche Syslog-Meldung ausgegeben:

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

Geben Sie den folgenden Befehl ein, um zu überprüfen, ob der Wiederherstellungs-Timer derzeit ausgeführt wird und der Wert:

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

In diesem Beispiel gibt der Wiederherstellungs-Timer mit einem Wert von 16 Sekunden an, dass ein möglicherweise langsamer Peer in 16 Sekunden zu seiner ursprünglichen Aktualisierungsgruppe zurückkehren könnte.

In diesem Beispiel sehen Sie einen Peer, der vom langsamen Peer-Status wiederhergestellt wurde:

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

Löschen Sie den langsameren Peer-Status.

Der langsame Peer-Status kann mit den folgenden Befehlen manuell gelöscht werden:

- clear ip bgp * langsam

- clear ip bgp AF {Unicast|multicast} <AS-Nummer> langsam

- clear ip bgp AF {unicast|multicast} peer-group <group-name> slow

- clear ip bgp <Nachbaradresse> langsam

- clear bgp AF {unicast|multicast} * langsam

- clear bgp AF {unicast|multicast} <AS-Nummer> langsam

- clear bgp AF {unicast|multicast} peer-group <group-name> slow

- clear bgp AF {Unicast|Multicast} <Nachbaradresse> langsam

Hinweis: Wenn Sie diese Befehle verwenden, ersetzen Sie AF durch die tatsächliche Adressfamilie.

Mit diesen Befehlen wird der Peer zurück in die ursprüngliche Aktualisierungsgruppe verschoben.

Geben Sie den Befehl show ip bgp internal ein, um die Einstellungen für die langsame Peer-Erkennung und -Bewegung anzuzeigen:

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

Hinweis: Zusammenfassend lässt sich sagen, dass der langsame BGP-Peer eine Funktion ist, die einen langsamen Peer in einer BGP-Update-Gruppe erkennt und eine schnellere BGP-Konvergenz ermöglicht, indem der langsame Peer aus der Update-Gruppe verschoben wird.