BGP Neighbor and Session Configuration

This chapter explains how to configure BGP neighbors to ensure reliable and scalable routing in your network. You’ll learn how to simplify management with neighbor groups, fine-tune session parameters, and apply powerful policy controls using BGP communities.

BGP neighbor groups

A BGP neighbor group is a configuration template that:

  • stores address family-independent and address family-dependent settings

  • enables multiple BGP neighbors to inherit shared configuration parameters, and

  • allows centralized management and consistent application of BGP neighbor policies.

Configuration inheritance

After you configure a neighbor group, each BGP neighbor can inherit its configuration by using the use command. By default, a neighbor configured to use a neighbor group inherits all configuration from that group, including address family-independent and address family-dependent settings.

Overriding inherited configuration

You can override inherited settings by directly configuring commands for the neighbor. Alternatively, associate session groups or address family groups with the neighbor using the use command

Configuring address family-independent parameters

Configure address family-independent parameters directly within the neighbor group configuration mode.

Configuring address family-dependent parameters

To configure address family-dependent parameters, enter the address family submode under the neighbor group by using the address-family command.

Assigning options to a neighbor group

After specifying the neighbor group name with the neighbor group command, assign the configuration options you want the group to use. Downstream neighbors inherit these options.

Suppose you have several BGP neighbors that require the same password and update-source configuration. Instead of configuring these parameters for each neighbor individually, define them in a neighbor group and attach the group to each neighbor with the use command.

Configure a BGP neighbor group

Centralize and streamline BGP configuration by creating a BGP neighbor group and applying its settings to BGP neighbors.

BGP neighbor groups let you manage common settings, such as address family, remote AS number, and route policies across multiple BGP neighbors. By grouping neighbors with similar configurations, you can simplify management and reduce configuration errors.

Before you begin

  • Ensure you have administrative access to the command-line interface of the router.

  • Verify that the router supports BGP and is properly licensed.

  • Identify the autonomous system (AS) numbers and IP addresses for both local and remote peers.

  • Prepare any required route policies to apply to the neighbor group.

Follow these steps to configure a BGP neighbor group and apply it to a neighbor:

Procedure


Step 1

Enter BGP configuration mode and specify the local AS number and address family (such as IPv4 or IPv6 unicast).

Example:

Router# configure
Router(config)# router bgp 120
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# exit

Step 2

Configure a neighbor group by specifying a remote autonomous system (AS) number for that group. Apply the address family, such as IPv4 or IPv6, to the BGP neighbor group. Additionally, you can apply inbound or outbound route policies to that neighbor group.

Example:

Router(config-bgp)# neighbor-group nbr-grp-A
Router(config-bgp-nbrgrp)# remote-as 2002
Router(config-bgp-nbrgrp)# address-family ipv4 unicast
Router(config-bgp-nbrgrp-af)# route-policy drop-as-1234 in
Router(config-bgp-nbrgrp-af)# exit
Router(config-bgp-nbrgrp)# exit

Step 3

Configure a BGP neighbor to inherit configuration from the specified neighbor group.

Example:

Router(config-bgp)# neighbor 172.168.40.24
Router(config-bgp-nbr)# use neighbor-group nbr-grp-A
Router(config-bgp-nbr)# remote-as 2002
Router(config-bgp-nbr)# commit

The BGP neighbor group is configured, and its settings are successfully applied to the specified neighbor. Any changes to the group are consistently applied to all assigned neighbors for centralized management.

Example

This example illustrates centralized configuration using BGP neighbor groups and route policies:

route-policy pass-all 
  pass
end-policy 
router bgp 109
  address-family ipv4 unicast 
     network 172.16.0.0 255.255.0.0
     network 192.16831.7.0 255.255.0.0
     neighbor 172.16.200.1 
       remote-as 167 
       exit
  address-family ipv4 unicast 
     route-policy pass-all in 
     route-policy pass-out out 
     neighbor 172.26.234.2
       remote-as 109 
       exit
  address-family ipv4 unicast 
     neighbor 172.26.64.19
       remote-as 99 
       exit
  address-family ipv4 unicast 
      route-policy pass-all in 
      route-policy pass-all out

In this example:

  • The BGP router is configured to belong to AS 109.

  • The router advertises two networks, 172.16.0.0 and 192.168.7.0, as originating from AS 109.

  • There are three neighbor routers, two external and one internal:

    • The first and third neighbors use different AS numbers.

    • The second neighbor shares AS 109 and is identified as an internal neighbor.

    • Route policies are applied to inbound and outbound routing updates.

This setup allows the router to share routing information about the two networks with all configured neighbors, while distinguishing between internal and external BGP peers based on the AS number.

What to do next

  • Verify the BGP neighbor and group configuration using show commands (for example, show running-config or show bgp neighbors ) to confirm the correct application of settings.

  • Monitor BGP peer status and logs to ensure neighbor establishment and exchange of routing information.

Adjust BGP timers

Set or modify the keepalive and hold timers for BGP neighbors to control the frequency of keepalive messages and determine when a neighbor is declared down.

BGP uses timers to manage keepalive messages and neighbor status. You can set global timer defaults and override them for individual neighbors if needed.

Before you begin

  • Ensure you are in privileged EXEC mode on the router.

  • Know the autonomous system (AS) number for your BGP process.

  • Have the neighbor IP addresses ready.

Procedure


Enter BGP configuration mode, and set default BGP keepalive and hold timers for all neighbors or a specific BGP neighbor.

The values set using the timers bgp command in router configuration mode apply globally, but you can override them on a per-neighbor basis using the timers command in neighbor configuration mode.

Example:

Router# configure
Router(config)# router bgp 123
Router(config-bgp)# timers bgp 30 90
Router(config-bgp)# neighbor 172.16.40.24
Router(config-bgp-nbr)# timers 60 220

Soft reconfiguration

A soft reconfiguration is a BGP feature that

  • stores inbound routing updates received from a neighbor

  • enables policy changes to be applied without clearing the BGP session, and

  • provides the ability to reapply or review routing policies on previously received routes.

How the soft-reconfiguration inbound command works

When the soft-reconfiguration inbound command is configured for a BGP neighbor, the router stores the original, unmodified BGP paths received from that neighbor. If the neighbor supports route refresh, a route refresh request can be sent to retrieve routing information. If route refresh is not supported, soft reconfiguration ensures that all received routes are available locally for policy reapplication.

Conditions for storing BGP routes during soft reconfiguration

  • Storing updates from a neighbor is possible only if either the neighbor supports route refresh or the soft-reconfiguration inbound command is configured.

  • The soft-reconfiguration inbound always command forces the router to store a copy of the received routes even if route refresh is supported by the neighbor.

Memory considerations for soft reconfiguration

Soft reconfiguration is memory intensive, as all received paths must be stored until they are no longer needed.

Suppose a BGP router has received multiple routing updates from a neighbor. If network administrators need to change routing policies or filters, soft reconfiguration allows them to reapply new policy rules to previously stored routes without resetting the BGP session or losing any routing updates.

Configure BGP soft reconfiguration for a neighbor

Enable BGP to store incoming route updates from a neighbor, allowing policy changes to be applied with a soft clear instead of resetting the BGP session.

Use soft reconfiguration when a BGP neighbor does not support route refresh, or when you require the flexibility to apply new policies and retrieve original routes without a full session reset.

Before you begin

  • Identify the autonomous system (AS) number.

  • Obtain the IP address of the BGP neighbor.

  • Ensure sufficient memory is available, as soft reconfiguration can be resource-intensive.

Procedure


Enter BGP configuration mode, and enable soft reconfiguration for the neighbor.

Example:

Router(config)# router bgp 120 
Router(config-bgp)# neighbor 172.16.40.24
Router(config-bgp-nbr)# address-family ipv4 unicast
Router(config-bgp-nbr-af)# soft-reconfiguration inbound always

BGP large communities

BGP large community is a BGP routing attribute that

  • enables grouping of network destinations for routing policies

  • encodes both 4-byte autonomous system numbers (ASNs) and operator-assigned local values, and

  • supports complex route-matching and policy operations using community values.

BGP communities allow network operators to tag routes with information that can influence route acceptance, rejection, preference, or redistribution. Traditional BGP community attributes use 4 bytes, making them insufficient for encoding both 4-byte ASNs (introduced in RFC 6793) and local values. BGP extended communities can encode 4-byte ASNs in the global administrator field, but limitations in the local administrator field still exist.

Importance of BGP large communities

To address these limitations, BGP large communities were introduced. Each large community consists of three 4-byte, unsigned integers separated by colons (for example, 1:2:3). The first field typically encodes the ASN, while the other two fields are set by the operator.

Policy matching with BGP large communities

BGP large communities can be matched or set in route-policy languages (RPL) using flexible syntax and are compatible with various expressions for advanced policy matching.

Expressions used in BGP large community policies

You can use these expressions in route-policy statements to match or set BGP large community values (fields are separated by colons):

  • [x..y] — Specifies a range between x and y, inclusive.

  • * — Stands for any number.

  • peeras — Substitutes the ASN of the BGP neighbor (inbound or outbound as appropriate).

  • not-peeras — Matches any number except the ASN of the neighbor.

  • private-as — Matches a private ASN in the ranges [64512..65534] and [4200000000..4294967294].

Regular expressions can also be used for matches or deletes:

  • ios-regex example: '^5:.*:7$' is equivalent to the expression 5:*:7.

Restrictions and guidelines for BGP large communities

These restrictions and guidelines apply to BGP large communities.

  • All functionality available in the BGP community attribute is available for the BGP large-community attribute.

  • The send-community-ebgp command is required for the BGP speaker to send large communities to eBGP neighbors.

  • There are no well-known large communities defined.

  • The peeras expression cannot be used in a large-community-set.

  • The peeras expression can only be used in large-community match or delete statements that appear in route policies at neighbor-in or neighbor-out attach points.

  • The not-peeras expression cannot be used in a large-community-set or in policy set statements.

Configure a named large-community set

Create a named set of BGP large communities for use in route-policy matching and set statements.

Before you begin

Ensure you are in router configuration mode on a Cisco IOS XR device.

Procedure


Create a large-community set by specifying its name. Add large community values, each in the format A:B:C or with expressions as needed.

Example:

Router(config)# large-community-set catbert
Router(config-largecomm)#  1: 2: 3,
Router(config-largecomm)#  peeras:2:3
Router(config-largecomm)# end-set 

Match BGP large communities using route policies

Configure policies to match routes based on presence or pattern of large communities.

You can match if any, all, or a subset of a route’s large communities correspond to specific criteria.

Procedure


Step 1

Enter route-policy configuration mode, and use the if large-community matches-any command to match any element of a large community set.

Example:

Router(config)# route-policy elbonia
Router(config-rpl)# if large-community matches-any (1:2:3, 4:5:*) then
Router(config-rpl)# set local-preference 94
Router(config-rpl)# endif
Router(config-rpl)# end-policy

Step 2

Use the if large-community matches-every command to match every specification.

Example:

Router(config)# route-policy bob
Router(config-rpl)# if large-community matches-every (*:*:3, 4:5:*) then
Router(config-rpl)# set local-preference 94
Router(config-rpl)# endif
Router(config-rpl)# end-policy

Step 3

Use the if large-community matches-within command to match within a large community set. This command is similar to the large-community matches-any command but every large community in the route must match at least one match specification. If the route has no large communities, the condition matches.

Example:

Router(config)# route-policy bob
Router(config-rpl)# if large-community matches-within (*:*:3, 4:5:*) then
Router(config-rpl)# set local-preference 103
Router(config-rpl)# endif
Router(config-rpl)# end-policy

Set BGP large community attributes in a route policy

Assign BGP large community attributes to routes within a policy for use in route filtering and redistribution.

Before you begin

Ensure you have an existing large-community set or inline set, and are in route-policy configuration mode.

Procedure


Step 1

Use the set large-community command, specifying a set name or inline values.

Example:

Router(config)# route-policy mordac 
Router(config-rpl)# set large-community (1:2:3, peeras:2:3)
Router(config-rpl)# end-set

Step 2

(Optional) Include the additive keyword to retain existing large-community values.

Example:

router(config-rpl)# set large-community catbert additive 

The additive keyword keeps the existing large communities on a route and adds any new large communities you specify. It does not create duplicate entries.


Filter routes without large communities

Configure a route-policy that matches routes missing the large-community attribute.

Procedure


Enter route-policy configuration mode, and use the if large-community is-empty command to filter routes without large communities.

Example:

Router(config)# route-policy lrg_comm_rp4
Router(config-rpl)# if large-community is-empty then
Router(config-rpl)# set local-preference 104
Router(config-rpl)# endif
Router(config-rpl)# end-policy

Apply attribute filtering for BGP large communities

Filter BGP update messages based on large-community attributes using an attribute-filter group.

Before you begin

Ensure you are in BGP router configuration mode.

Procedure


Create an attribute-filter group specifying the LARGE-COMMUNITY attribute and desired action (for example, discard).

Example:


Router(config)# router bgp 100
Router(config-bgp)# attribute-filter group dogbert
Router(config-bgp-attrfg)# attribute LARGE-COMMUNITY discard
Router(config-bgp-attrfg)# neighbor 10.0.1.101
Router(config-bgp-nbr)# remote-as 6461
Router(config-bgp-nbr)# update in filtering
Router(config-nbr-upd-filter)# attribute-filter group dogbert

Updates containing specified large-community attributes from the neighbor are discarded as configured.

Delete BGP large communities from route policies

Remove specific BGP large-communities from routes using route-policy configuration.

Before you begin

Ensure you are in route-policy configuration mode.

Procedure


Use the delete large-community command with specific matching criteria, such as regular expressions, 'all', or inline specifications to delete large communities.

Example:


Router(config)# route-policy lrg_comm_rp2
Router(config-rpl)# delete large-community in (ios-regex '^100000:’)  
Router(config-rpl)# delete large-community all
Router(config-rpl)# delete large-community not in (peeras:*:*, 41289:*:*)

The specified large communities are removed from the affected routes according to the deletion criteria used.

Show commands for BGP large communities

  • To display routes containing specified large communities, use the show bgp large-community community-list exact-match command.

    • If exact-match keyword is specified, only routes with the exact set of listed communities are shown. Otherwise, routes with additional large communities are included.

    Example:

    Router# show bgp large-community 1:2:3 5:6:7
    Thu Mar 23 14:40:33.597 PDT
    BGP router identifier 10.4.4.4, local AS number 3
    BGP generic scan interval 60 secs
    Non-stop routing is enabled
    BGP table state: Active
    Table ID: 0xe0000000   RD version: 66
    BGP main routing table version 66
    BGP NSR Initial initsync version 3 (Reached)
    BGP NSR/ISSU Sync-Group versions 66/0
    BGP scan interval 60 secs
    
    Status codes: s suppressed, d damped, h history, * valid, > best
                  i - internal, r RIB-failure, S stale, N Nexthop-discard
    Origin codes: i - IGP, e - EGP, ? - incomplete
       Network            Next Hop            Metric LocPrf Weight Path
    * 10.0.0.3/32         10.10.10.3               0     94      0 ?
    * 10.0.0.5/32         10.11.11.5               0             0 5 ?
    
  • To display the large community for a specific network, use the show bgp ip-address / prefix-length command. The output displays route entries and the large-community attributes attached.

    Example:

    Router# show bgp 10.3.3.3/32
    Thu Mar 23 14:36:15.301 PDT
    BGP routing table entry for 10.3.3.3/32
    Versions:
      Process           bRIB/RIB  SendTblVer
      Speaker                 42          42
    Last Modified: Mar 22 20:04:46.000 for 18:31:30
    Paths: (1 available, best #1)
      Advertised to peers (in unique update groups):
        10.11.11.5
      Path #1: Received by speaker 0
      Advertised to peers (in unique update groups):
        10.11.11.5
      Local
        10.10.10.3 from 10.10.10.3 (10.3.3.3)
          Origin incomplete, metric 0, localpref 94, valid, internal, best, group-best
          Received Path ID 0, Local Path ID 0, version 42
          Community: 258:259 260:261 262:263 264:265
          Large Community: 1:2:3 5:6:7 4123456789:4123456780:4123456788