BGP Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

BGP slow peer management

Updated: February 28, 2026

Want to summarize with AI?

Log in

Overview

Describes how BGP groups neighbors into update groups to optimize update generation and explains mechanisms to mitigate the impact of slow peers on update throughput.

BGP slow peer management is a Border Gateway Protocol (BGP) mechanism that

  • groups neighbors into update groups based on address-family configuration and shared update content

  • formats updates once per group, transmits them to all members, and retains updates until all members acknowledge receipt, and

  • mitigates the impact of slow peers to prevent group-wide backlogs and maintain update throughput.

How update groups work

Table 1. Feature History Table

Feature Name

Release

Description

BGP Slow Peer

 Release 7.9.1

BGP neighbors are grouped together to optimize update generation. BGP peers process the incoming BGP update messages at different rates. A slow peer is a peer that is processing incoming BGP update messages very slowly over a long period of time compared to other peers in the update sub-group. BGP slow peer handling is necessary to reduce the impact of the slow peer on the remaining members of the group.

This feature introduces the following commands:

This feature modifies the following commands:

  • show bgp neighbors to display the slow peer configuration state and slow peer detection or processing information.

  • show bgp update out to display the summary of the neighbor address-family update-group, sub-group, or refresh sub-group information

  • BGP neighbors are grouped using common criteria, such as the neighbor address-family configuration and processing of the same update messages, to optimize update generation.

  • For each group, messages are formatted once and transmitted to all members; messages are deleted only after all members acknowledge receipt.

  • Update generation operates per address family. A peer refers to a neighbor address family, and peers in a sub-group are neighbors for the same address family.

  • Processor is busy handling other tasks and cannot process updates on time.

  • Peers are connected over slow bandwidth links.

  • Temporary network congestion affects timely processing.

  • BGP enforces limits on update messages per process, per address family, and per sub-group. The default sub-group message limit is 32 Mbytes.

  • If one or more peers are extremely slow to process messages, those messages remain queued until acknowledged by all peers in the sub-group.

  • When the sub-group message limit is reached, all neighbors in the sub-group must wait for the slowest peer to catch up, which slows every member of the sub-group.

Slow peer management reduces these impacts by isolating or otherwise mitigating the effects of slow processing peers.

BGP distinguishes configuration types from runtime states for peers that process updates slowly. Understanding both helps you choose the right mitigation and verify behavior in operation.

Slow peer types

  • Static slow peer: Moves the peer to its own update group and requires no additional slow‑peer handling.

  • Dynamic slow peer: Keeps the peer in the original group; when detected as slow, processing occurs in a refresh sub‑group.

Slow peer states

  • Static slow peer: The neighbor address family is in the static slow peer state.

  • Dynamic detected slow peer: The neighbor address family is detected as slow and is being processed.

  • Not slow peer: The neighbor address family is not currently slow.

Table 2. Type-to-state alignment

Type

Typical runtime state

Operational behavior
Static Static slow peer Isolated in its own update group; no additional slow‑peer handling.
Dynamic Dynamic detected slow peer or Not slow peer Remains grouped; when detected slow, updates are handled in a refresh sub‑group.
None Not slow peer No slow‑peer handling.

Guidelines for managing slow peers

Queue and update hygiene

  • Ensure queues do not retain stale information; prioritize sending only the latest route state during periods of sustained route churn.

  • Monitor sub-group backlogs and message limits to identify slow peers early and take corrective action, for example, apply slow-peer handling features.

  • Maintain per–address-family hygiene to prevent a single slow peer from degrading update throughput for the entire sub-group.

Handling permanently slow peers

  • Do not rely on dynamic slow peer detection for permanently slow peers.

  • Isolate permanently slow peers using static slow peer configuration, which moves them to their own update group; apply the same route policy to all such peers.

How slow peer detection and processing works

Summary

The key components involved in the process are:

  • Update groups and sub-groups: Neighbors are grouped by address-family and shared update content; messages are formatted once and deleted only after all members acknowledge receipt.

  • Slow peer classification: Static or dynamic, with operational states tracked per neighbor address family.

  • Refresh sub-group: A child group created to process a slow peer’s updates up to the current table version while the parent sub-group continues with new updates.

  • Queues: Main queue and parallel slow peer queue used to control advertisement flow and maintain per-route ordering.

  • Detection thresholds and limits: Time threshold (default 300 seconds) and a maximum of 16 refresh sub-groups per address family.

Slow peer handling mitigates backlog and delay in BGP update groups by detecting peers that cannot keep up, isolating their processing in refresh sub-groups, and managing queues to preserve ordering and throughput.

Workflow

These stages describe how slow peer detection and processing works:

  1. Group formation and baseline behavior: BGP neighbors are grouped by address-family configuration and shared updates; messages are formatted once and retained until all members acknowledge them. This optimizes update generation but can stall on slow peers.
  2. Slow peer detection: A dynamic peer is identified as slow when all of these are true:
    • acknowledgments are missing for some messages
    • pending messages are yet to be written to TCP
    • the time since the last update exceeds the threshold
    • the number of refresh sub-groups for the address family is fewer than 16
    • the neighbor is not the only member of the sub-group; other members are already marked slow, and
    • there are nets awaiting update generation.
  3. Refresh sub-group creation: The system creates a refresh sub-group for the detected slow peer to process updates up to the current table version. The parent sub-group continues sending new updates for both slow and non-slow peers. Each slow peer gets its own refresh sub-group. When processing completes, the refresh sub-group is removed. See Refresh sub-group states for more information.
  4. Queue management: The router moves all messages queued in the peer’s main queue to a parallel slow peer queue and advertises them separately, while new messages continue to flow from the main queue. If the peer is detected slow again, the move-and-advertise cycle repeats. Ordering for updates and withdrawals is maintained per route. See Detection and queue management details for more information.
  5. State tracking and clearing: The processing slow peer state is set to true when handling starts and is cleared only after all slow peer updates are advertised and acknowledged; it does not clear on configuration changes.
  6. Recovery: The peer is no longer considered slow when all messages in the slow peer queue are advertised and acknowledged. The slow peer queue is deleted, and the refresh sub-group is removed.

Result

Update generation remains responsive and fair; slow peers are isolated without blocking faster peers, preventing sub-group stalls and preserving per-route ordering during churn.

Configure slow peer handling for BGP neighbors

Enable and verify slow peer handling globally or per neighbor address family to mitigate update backlogs and isolate permanently slow peers.

Slow peer handling supports

  • global configuration that affects all neighbors and

  • per–neighbor address-family configuration that targets a specific peer.

Dynamic detection can optionally use a threshold (seconds) for classification.

Before you begin

  • Identify the BGP autonomous system number.

  • Determine whether you need a global setting, a per–neighbor address-family setting, or both.

  • If using dynamic detection, choose the detection threshold (seconds).

Follow these steps to configure slow peer handling:

Procedure

1.

Configure global slow peer handling.

  • Enable dynamic slow peer handling for all BGP neighbor address families.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#slow-peer dynamic
Router(config-bgp)#commit

  • Disable slow peer handling for all BGP neighbor address families.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#slow-peer detection-disable 
Router(config-bgp)#commit

  • Enable dynamic slow peer handling with a detection threshold of 120 seconds.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#slow-peer dynamic threshold 120
Router(config-bgp)#commit
2.

Configure slow peer handling for a specific neighbor address family.

  • Mark a neighbor as a static slow peer (isolates the neighbor in its own update group).

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer static
Router(config-bgp-nbr-af)#commit

  • Disable dynamic slow peer handling for a neighbor address family.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer dynamic disable 
Router(config-bgp-nbr-af)#commit

  • Enable dynamic slow peer handling for a neighbor address family.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer dynamic 
Router(config-bgp-nbr-af)#commit

  • Enable dynamic slow peer handling with a detection threshold of 120 seconds for a neighbor address family.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer dynamic threshold 120
Router(config-bgp-nbr-af)#commit
3.

Run the show bgp neighbors <neighbor-address> detail command to view the effective slow peer configuration for a neighbor address family.

Slow peer handling is enabled globally or per neighbor address family as configured. Use the verification command to confirm the effective state for each neighbor.

Slow peer effective configuration state

This table summarizes the effective neighbor AF slow peer configuration or operational state, considering both the slow peer global configuration and the slow peer neighbor AF configuration.

  • For example, if the global configuration is None and the neighbor configuration is Static, then the effective configuration is Static.

Table 3. Effective slow peer configuration state

-

Global configuration

-

[None]

[Dynamic]

[Detection disable]

Neighbor address-family configuration

[None]

Detection-only

Dynamic

None

[Static]

Static

Static

Static

[Dynamic]

Dynamic

Dynamic

Dynamic

[Dynamic Disable]

Detection-only

None

None

The effective neighbor address-family configuration state can be any of the following entries in this table.

  • The show bgp neighbors <neighbor-address> detail command displays the neighbor address-family configuration states listed here.

Table 4. Effective neighbor address-family configuration state

AF configuration state

Details

Static

  • When the effective neighbor address family configuration is Static, the neighbor address family moves to its own update group, isolating it from other neighbors.

  • To place all slow peers in a single update group, remove the static slow peer configuration and apply the same outbound route policy to all neighbors.

Dynamic

  • When the effective neighbor address family configuration is Dynamic, BGP enables dynamic slow peer processing for that neighbor address family.

  • If it is detected as slow, BGP processes the neighbor address family in a dedicated refresh sub-group, isolates it from other neighbors in the sub-group, and displays an IOS message indicating the slow state.

Detection-only

  • When the effective neighbor address family configuration is Detection-only, BGP logs slow‑peer detection and recovery events but applies no mitigation.

  • The router displays an IOS message when the neighbor address family becomes slow or recovers.

None

When the effective neighbor address family configuration is None, BGP disables slow peer handling for that neighbor address family.

Examples: Configure slow peer handling with combined global and neighbor settings

  • Enable dynamic slow peer globally; mark one neighbor as static.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#slow-peer dynamic
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer static
Router(config-bgp-nbr-af)#commit

  • Enable dynamic slow peer globally; disable it for one neighbor address family.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#slow-peer dynamic
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer dynamic disable
Router(config-bgp-nbr-af)#commit

  • Use different dynamic detection thresholds globally and per neighbor.

    Router#configure
Router(config)#router bgp 100
Router(config-bgp)#slow-peer dynamic threshold 600
Router(config-bgp)#neighbor 50.0.0.1
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#slow-peer dynamic threshold 120
Router(config-bgp-nbr-af)#commit

IOS messages for slow peer events

The system logs messages when a BGP neighbor is detected as a slow peer and when it recovers. These are the available events and corresponding log messages:

  • Slow peer detected: BGP neighbor 50.0.0.1 of vrf default afi IPv4 Unicast is detected as slow-peer

  • Slow peer recovered: Slow BGP peer 50.0.0.1 of vrf default afi IPv4 Unicast has recovered