BGP Functional Overview
BGP uses TCP as its transport protocol. Two BGP routers form a TCP connection between one another (peer routers) and exchange messages to open and confirm the connection parameters.
BGP routers exchange network reachability information. This information is mainly an indication of the full paths (BGP autonomous system numbers) that a route should take to reach the destination network. This information helps construct a graph that shows which autonomous systems are loop free and where routing policies can be applied to enforce restrictions on routing behavior.
Any two routers forming a TCP connection to exchange BGP routing information are called peers or neighbors. BGP peers initially exchange their full BGP routing tables. After this exchange, incremental updates are sent as the routing table changes. BGP keeps a version number of the BGP table, which is the same for all of its BGP peers. The version number changes whenever BGP updates the table due to routing information changes. Keepalive packets are sent to ensure that the connection is alive between the BGP peers and notification packets are sent in response to error or special conditions.
 Note |
VPNv4 address family is supported effective from Cisco IOS XR Release 6.1.31. However, VPNv6 and VPN routing and forwarding (VRF) address families will be supported in a future release. |
Enable BGP Routing
Perform this task to enable BGP routing and establish a BGP routing process. Configuring BGP neighbors is included as part of enabling BGP routing.
Note |
|
Before you begin
BGP must be able to obtain a router identifier (for example, a configured loopback address). At least, one address family must be configured in the BGP router configuration and the same address family must also be configured under the neighbor.
Note |
If the neighbor is configured as an external BGP (eBGP) peer, you must configure an inbound and outbound route policy on the neighbor using the route-policy command. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
route-policy route-policy-name Example:(Optional) Creates a route policy and enters route policy configuration mode, where you can define the route policy. |
| Step 3 |
end-policy Example:(Optional) Ends the definition of a route policy and exits route policy configuration mode. |
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
| Step 5 |
configure Example:Enters mode. |
| Step 6 |
router bgp as-number Example:Specifies the BGP AS number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 7 |
bgp router-id ip-address Example:Configures the local router with a specified router ID. |
| Step 8 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 9 |
exit Example:Exits the current configuration mode. |
| Step 10 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 11 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 12 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 13 |
route-policy route-policy-name { in | out } Example:(Optional) Applies the specified policy to inbound IPv4 unicast routes. |
| Step 14 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Enabling BGP: Example
The following shows how to enable BGP.
prefix-set static
2020::/64,
2012::/64,
10.10.0.0/16,
10.2.0.0/24
end-set
route-policy pass-all
pass
end-policy
route-policy set_next_hop_agg_v4
set next-hop 10.0.0.1
end-policy
route-policy set_next_hop_static_v4
if (destination in static) then
set next-hop 10.1.0.1
else
drop
endif
end-policy
route-policy set_next_hop_agg_v6
set next-hop 2003::121
end-policy
route-policy set_next_hop_static_v6
if (destination in static) then
set next-hop 2011::121
else
drop
endif
end-policy
router bgp 65000
bgp fast-external-fallover disable
bgp confederation peers
65001
65002
bgp confederation identifier 1
bgp router-id 1.1.1.1
address-family ipv4 unicast
aggregate-address 10.2.0.0/24 route-policy set_next_hop_agg_v4
aggregate-address 10.3.0.0/24
redistribute static route-policy set_next_hop_static_v4
address-family ipv6 unicast
aggregate-address 2012::/64 route-policy set_next_hop_agg_v6
aggregate-address 2013::/64
redistribute static route-policy set_next_hop_static_v6
neighbor 10.0.101.60
remote-as 65000
address-family ipv4 unicast
neighbor 10.0.101.61
remote-as 65000
address-family ipv4 unicast
neighbor 10.0.101.62
remote-as 3
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-all out
neighbor 10.0.101.64
remote-as 5
update-source Loopback0
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-all out
Adjust BGP Timers
BGP uses certain timers to control periodic activities, such as the sending of keepalive messages and the interval after which a neighbor is assumed to be down if no messages are received from the neighbor during the interval. The values set using the timers bgp command in router configuration mode can be overridden on particular neighbors using the timers command in the neighbor configuration mode.
Perform this task to set the timers for BGP neighbors.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
timers bgp keepalive hold-time Example:Sets a default keepalive time and a default hold time for all neighbors. |
| Step 4 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 5 |
timers keepalive hold-time Example:(Optional) Sets the keepalive timer and the hold-time timer for the BGP neighbor. |
| Step 6 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Change BGP Default Local Preference Value
Perform this task to set the default local preference value for BGP paths.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
bgp default local-preference value Example:Sets the default local preference value from the default of 100, making it either a more preferable path (over 100) or less preferable path (under 100). |
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Configure MED Metric for BGP
Perform this task to set the multi exit discriminator (MED) to advertise to peers for routes that do not already have a metric set (routes that were received with no MED attribute).
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
default-metric value Example:Sets the default metric, which is used to set the MED to advertise to peers for routes that do not already have a metric set (routes that were received with no MED attribute). |
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Configure BGP Weights
A weight is a number that you can assign to a path so that you can control the best-path selection process. If you have particular neighbors that you want to prefer for most of your traffic, you can use the weight command to assign a higher weight to all routes learned from that neighbor. Perform this task to assign a weight to routes received from a neighbor.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 5 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 6 |
weight weight-value Example:Assigns a weight to all routes learned through the neighbor. |
| Step 7 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
What to do next
You the clear bgp command for the newly configured weight to take effect.
Tune BGP Best-Path Calculation
-
Step 1—Compare two paths to determine which is better.
-
Step 2—Iterate over all paths and determines which order to compare the paths to select the overall best path.
-
Step 3—Determine whether the old and new best paths differ enough so that the new best path should be used.
Note |
The order of comparison determined by Step 2 is important because the comparison operation is not transitive; that is, if three paths, A, B, and C exist, such that when A and B are compared, A is better, and when B and C are compared, B is better, it is not necessarily the case that when A and C are compared, A is better. This nontransitivity arises because the multi exit discriminator (MED) is compared only among paths from the same neighboring autonomous system (AS) and not among all paths. BGP Best Path Algorithm provides additional conceptual details. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
bgp bestpath med missing-as-worst Example:Directs the BGP software to consider a missing MED attribute in a path as having a value of infinity, making this path the least desirable path. |
| Step 4 |
bgp bestpath med always Example:Configures the BGP speaker in the specified autonomous system to compare MEDs among all the paths for the prefix, regardless of the autonomous system from which the paths are received. |
| Step 5 |
bgp bestpath med confed Example:Enables BGP software to compare MED values for paths learned from confederation peers. |
| Step 6 |
bgp bestpath as-path ignore Example:Configures the BGP software to ignore the autonomous system length when performing best-path selection. |
| Step 7 |
bgp bestpath compare-routerid Example:Configure the BGP speaker in the autonomous system to compare the router IDs of similar paths. |
| Step 8 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Set BGP Administrative Distance
|
Distance |
Default Value |
Function |
|---|---|---|
|
External |
20 |
Applied to routes learned from eBGP. |
|
Internal |
200 |
Applied to routes learned from iBGP. |
|
Local |
200 |
Applied to routes originated by the router. |
Note |
Distance does not influence the BGP path selection algorithm, but it does influence whether BGP-learned routes are installed in the IP routing table. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
distance bgp external-distance internal-distance local-distance Example:Sets the external, internal, and local administrative distances to prefer one class of routes over another. The higher the value, the lower the trust rating. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Indicate BGP Back-door Routes
In most cases, when a route is learned through eBGP, it is installed in the IP routing table because of its distance. Sometimes, however, two ASs have an IGP-learned back-door route and an eBGP-learned route. Their policy might be to use the IGP-learned path as the preferred path and to use the eBGP-learned path when the IGP path is down.
Perform this task to set the administrative distance on an external Border Gateway Protocol (eBGP) route to that of a locally sourced BGP route, causing it to be less preferred than an Interior Gateway Protocol (IGP) route.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
network { ip-address / prefix-length | ip-address mask } backdoor Example:Configures the local router to originate and advertise the specified network. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Back Door: Example
Here, Routers A and C and Routers B and C are running eBGP. Routers A and B are running an IGP (such as Routing Information Protocol [RIP], Interior Gateway Routing Protocol [IGRP], Enhanced IGRP, or Open Shortest Path First [OSPF]). The default distances for RIP, IGRP, Enhanced IGRP, and OSPF are 120, 100, 90, and 110, respectively. All these distances are higher than the default distance of eBGP, which is 20. Usually, the route with the lowest distance is preferred.
Router A receives updates about 160.10.0.0 from two routing protocols: eBGP and IGP. Because the default distance for eBGP is lower than the default distance of the IGP, Router A chooses the eBGP-learned route from Router C. If you want Router A to learn about 160.10.0.0 from Router B (IGP), establish a BGP back door. See .
In the following example, a network back-door is configured:
RP/0/RP0/CPU0:router(config)# router bgp 100
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# network 160.10.0.0/16 backdoor
Router A treats the eBGP-learned route as local and installs it in the IP routing table with a distance of 200. The network is also learned through Enhanced IGRP (with a distance of 90), so the Enhanced IGRP route is successfully installed in the IP routing table and is used to forward traffic. If the Enhanced IGRP-learned route goes down, the eBGP-learned route is installed in the IP routing table and is used to forward traffic.
Although BGP treats network 160.10.0.0 as a local entry, it does not advertise network 160.10.0.0 as it normally would advertise a local entry.
Configure Aggregate Addresses
Perform this task to create aggregate entries in a BGP routing table.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
aggregate-address address/mask-length [ as-set ] [ as-confed-set ] [ summary-only ] [ route-policy route-policy-name ] Example:Creates an aggregate address. The path advertised for this route is an autonomous system set consisting of all elements contained in all paths that are being summarized.
|
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Understanding BGP MD5 Authentication
BGP provides a mechanism, known as Message Digest 5 (MD5) authentication, for authenticating a TCP segment between two BGP peers by using a clear text or encrypted password.
MD5 authentication is configured at the BGP neighbor level. BGP peers using MD5 authentication are configured with the same password. If the password authentication fails, then the packets are not transmitted along the segment.
Configuring BGP MD5 Authentication
You can use the configuration in this section to configure BGP MD5 authentication between two BGP peers.
Note |
The configuration for MD5 authentication is identical on both peers. |
Configuration
Use the following configuration to configure BGP MD5:
RP/0/RP0/CPU0:router(config)# router bgp 50
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.1.1.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 51
RP/0/RP0/CPU0:router(config-bgp-nbr)# password encrypted a1b2c3
RP/0/RP0/CPU0:router(config-bgp-nbr)# commit
Running Configuration
Validate the configuration.
RP/0/RP0/CPU0:router# show running-config
...
!
router bgp 50
address-family ipv4 unicast
!
neighbor 10.1.1.1
remote-as 51
password encrypted a1b2c3
!
!
Hiding the Local AS Number for BGP Networks
Changing the autonomous system number is necessary when two separate BGP networks are combined under a single autonomous system. The neighbor local-as command is used to configure BGP peers to support two local autonomous system numbers to maintain peering between two separate BGP networks.
However, when the neighbor local-as command is configured on a BGP peer, the local AS number is automatically prepended to all routes that are learned from eBGP peers by default. This behavior, however, makes changing the autonomous system number for a service provider or large BGP network difficult, because the routes with the prepended AS number are rejected by internal BGP (iBGP) peers that belong to the same AS.
Hiding the local AS number by using the no-prepend command simplifies the process of changing the autonomous system number in a Border Gateway Protocol (BGP) network. Without this feature, internal BGP (iBGP) peers reject external routes from peers with a local AS number in the as-path attribute to prevent routing loops. Hiding the local AS number allows you to transparently change the autonomous system number for the entire BGP network and ensure that routes can be propagated throughout the autonomous system, while the AS number transition is incomplete.
Configuring BGP to Hide the Local AS Number
Hiding the local AS number for eBGP peers by using the no-prepend command can be used to transparently change the AS number of a BGP network, and ensure that routes are propagated throughout the AS during the transition. Because the local AS number is not prepended to these routes, external routes are not rejected by internal peers during the transition from one AS number to another.
This section describes the configuration and verification of the feature.
Note |
BGP prepends the autonomous system number from each BGP network that a route traverses. This behavior is designed to maintain network reachability information and to prevent routing loops from occurring. Configuring the no-prepend command incorrectly could create routing loops. So, the configuration of this command should only be attempted by an experienced network operator. |
Configuration
Use the following configuration to hide the local AS number for eBGP peers.
RP/0/RP0/CPU0:router# config
RP/0/RP0/CPU0:router(config)# router bgp 100
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# network 10.1.1.1 255.255.0.0
RP/0/RP0/CPU0:router(config-bgp-af)# neighbor 10.1.1.1 remote-as 100
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.1.1.1 local-as 300 no-prepend
RP/0/RP0/CPU0:router(config-bgp)# commit
Running Configuration
RP/0/RP0/CPU0:router# show running-configuration
...
!
router bgp 100
address-family ipv4 unicast
network 10.1.1.1 255.255.0.0
neighbor 10.1.1.1 remote-as 100
neighbor 10.1.1.1 local-as 300 no-prepend
!
Verification
Use the following command to verify your configuration.
RP/0/RP0/CPU0:router# show ip bgp neighbors
BGP neighbor is 10.1.1.1, remote AS 100, local AS 300 no-prepend, external link
BGP version 4, remote router ID 10.1.1.1
BGP state = Established, up for 00:00:49
Last read 00:00:49, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
IPv4 MPLS Label capability:
Received 10 messages, 1 notifications, 0 in queue
Sent 10 messages, 0 notifications, 0 in queue
Default minimum time between advertisement runs is 30 seconds
Autonomous System Number Formats in BGP
Autonomous system numbers (ASNs) are globally unique identifiers used to identify autonomous systems (ASs) and enable ASs to exchange exterior routing information between neighboring ASs. A unique ASN is allocated to each AS for use in BGP routing. ASNs are encoded as 2-byte numbers and 4-byte numbers in BGP.
RP/0/RP0/CPU0:router(config)# as-format [asdot | asplain]
RP/0/RP0/CPU0:router(config)# as-format asdot
2-byte Autonomous System Number Format
The 2-byte ASNs are represented in asplain notation. The 2-byte range is 1 to 65535.
4-byte Autonomous System Number Format
To prepare for the eventual exhaustion of 2-byte Autonomous System Numbers (ASNs), BGP has the capability to support 4-byte ASNs. The 4-byte ASNs are represented both in asplain and asdot notations.
The byte range for 4-byte ASNs in asplain notation is 1-4294967295. The AS is represented as a 4-byte decimal number. The 4-byte ASN asplain representation is defined in draft-ietf-idr-as-representation-01.txt.
For 4-byte ASNs in asdot format, the 4-byte range is 1.0 to 65535.65535 and the format is:
high-order-16-bit-value-in-decimal . low-order-16-bit-value-in-decimal
The BGP 4-byte ASN capability is used to propagate 4-byte-based AS path information across BGP speakers that do not support 4-byte AS numbers. See draft-ietf-idr-as4bytes-12.txt for information on increasing the size of an ASN from 2 bytes to 4 bytes. AS is represented as a 4-byte decimal number
as-format Command
The as-format command configures the ASN notation to asdot. The default value, if the as-format command is not configured, is asplain.
BGP Multi-Instance and Multi-AS
-
Mechanism to consolidate the services provided by multiple routers using a common routing infrastructure into a single IOS-XR router.
-
Mechanism to achieve AF isolation by configuring the different AFs in different BGP instances.
-
Means to achieve higher session scale by distributing the overall peering sessions between multiple instances.
-
Mechanism to achieve higher prefix scale (especially on a RR) by having different instances carrying different BGP tables.
-
Improved BGP convergence under certain scenarios.
-
All BGP functionalities including NSR are supported for all the instances.
-
The load and commit router-level operations can be performed on previously verified or applied configurations.
Restrictions
-
The router supports maximum of 4 BGP instances.
-
Each BGP instance needs a unique router-id.
-
Only one Address Family can be configured under each BGP instance (VPNv4, VPNv6 and RT-Constrain can be configured under multiple BGP instances).
-
IPv4/IPv6 Unicast should be within the same BGP instance in which IPv4/IPv6 Labeled-Unicast is configured.
-
IPv4/IPv6 Multicast should be within the same BGP instance in which IPv4/IPv6 Unicast is configured.
-
All configuration changes for a single BGP instance can be committed together. However, configuration changes for multiple instances cannot be committed together.
-
Cisco recommends that BGP update-source should be unique in the default VRF over all instances while peering with the same remote router.
Configure Multiple BGP Instances for a Specific Autonomous System
Perform this task to configure multiple BGP instances for a specific autonomous system. All configuration changes for a single BGP instance can be committed together. However, configuration changes for multiple instances cannot be committed together.
Procedure
| Step 1 |
configure Example:Enters mode. |
||
| Step 2 |
router bgp as-number [instance instance name ] Example:Enters BGP configuration mode for the user specified BGP instance. |
||
| Step 3 |
bgp router-id ip-address Example:Configures a fixed router ID for the BGP-speaking router (BGP instance).
|
||
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Routing Domain Confederation
One way to reduce the iBGP mesh is to divide an autonomous system into multiple sub-autonomous systems and group them into a single confederation. To the outside world, the confederation looks like a single autonomous system. Each autonomous system is fully meshed within itself and has a few connections to other autonomous systems in the same confederation. Although the peers in different autonomous systems have eBGP sessions, they exchange routing information as if they were iBGP peers. Specifically, the next hop, MED, and local preference information is preserved. This feature allows you to retain a single IGP for all of the autonomous systems.
Configure Routing Domain Confederation for BGP
Perform this task to configure the routing domain confederation for BGP. This includes specifying a confederation identifier and autonomous systems that belong to the confederation.
Configuring a routing domain confederation reduces the internal BGP (iBGP) mesh by dividing an autonomous system into multiple autonomous systems and grouping them into a single confederation. Each autonomous system is fully meshed within itself and has a few connections to another autonomous system in the same confederation. The confederation maintains the next hop and local preference information, and that allows you to retain a single Interior Gateway Protocol (IGP) for all autonomous systems. To the outside world, the confederation looks like a single autonomous system.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
bgp confederation identifier as-number Example:Specifies a BGP confederation identifier. |
| Step 4 |
bgp confederation peers as-number Example:Specifies that the BGP autonomous systems belong to a specified BGP confederation identifier. You can associate multiple AS numbers to the same confederation identifier, as shown in the example. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Confederation: Example
The following is a sample configuration that shows several peers in a confederation. The confederation consists of three internal autonomous systems with autonomous system numbers 6001, 6002, and 6003. To the BGP speakers outside the confederation, the confederation looks like a normal autonomous system with autonomous system number 666 (specified using the bgp confederation identifier command).
In a BGP speaker in autonomous system 6001, the bgp confederation peers command marks the peers from autonomous systems 6002 and 6003 as special eBGP peers. Hence, peers 171.16 .232.55 and 171.16 .232.56 get the local preference, next hop, and MED unmodified in the updates. The router at 171 .19 .69.1 is a normal eBGP speaker, and the updates received by it from this peer are just like a normal eBGP update from a peer in autonomous system 666.
router bgp 6001
bgp confederation identifier 666
bgp confederation peers
6002
6003
exit
address-family ipv4 unicast
neighbor 171.16.232.55
remote-as 6002
exit
address-family ipv4 unicast
neighbor 171.16.232.56
remote-as 6003
exit
address-family ipv4 unicast
neighbor 171.19.69.1
remote-as 777
router bgp 6002
bgp confederation identifier 666
bgp confederation peers
6001
6003
exit
address-family ipv4 unicast
neighbor 171.17.70.1
remote-as 6002
exit
address-family ipv4 unicast
neighbor 171.19.232.57
remote-as 6001
exit
address-family ipv4 unicast
neighbor 171.19.232.56
remote-as 6003
exit
address-family ipv4 unicast
neighbor 171.19.99.2
remote-as 700
exit
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-all out
router bgp 6003
bgp confederation identifier 666
bgp confederation peers
6001
6002
exit
address-family ipv4 unicast
neighbor 171.19.232.57
remote-as 6001
exit
address-family ipv4 unicast
neighbor 171.19.232.55
remote-as 6002
exit
address-family ipv4 unicast
neighbor 192.168.200.200
remote-as 701
exit
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-all out
router bgp 701
address-family ipv4 unicast
neighbor 172.16.232.56
remote-as 666
exit
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-all out
exit
address-family ipv4 unicast
neighbor 192.168.200.205
remote-as 701
BGP Additional Paths
The Border Gateway Protocol (BGP) Additional Paths feature modifies the BGP protocol machinery for a BGP speaker to be able to send multiple paths for a prefix. This gives 'path diversity' in the network. The add path enables BGP prefix independent convergence (PIC) at the edge routers.
BGP add path enables add path advertisement in an iBGP network and advertises the following types of paths for a prefix:
-
Backup paths—to enable fast convergence and connectivity restoration.
-
Group-best paths—to resolve route oscillation.
-
All paths—to emulate an iBGP full-mesh.
Configure BGP Additional Paths
Perform these tasks to configure BGP Additional Paths capability:
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
route-policy route-policy-name Example:Defines the route policy and enters route-policy configuration mode. |
| Step 3 |
if conditional-expression then action-statement else Example:Decides the actions and dispositions for the given route. |
| Step 4 |
pass endif Example:Passes the route for processing and ends the if statement. |
| Step 5 |
end-policy Example:Ends the route policy definition of the route policy and exits route-policy configuration mode. |
| Step 6 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 7 |
address-family {ipv4 {unicast } | ipv6 {unicast | l2vpn vpls-vpws | vpnv4 unicast | vpnv6 unicast } Example:Specifies the address family and enters address family configuration submode. |
| Step 8 |
additional-paths receive Example:Configures receive capability of multiple paths for a prefix to the capable peers. |
| Step 9 |
additional-paths send Example:Configures send capability of multiple paths for a prefix to the capable peers . |
| Step 10 |
additional-paths selection route-policy route-policy-name Example:Configures additional paths selection capability for a prefix. |
| Step 11 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Maximum Prefix
The maximum-prefix feature imposes a maximum limit on the number of prefixes that are received from a neighbor for a given address family. Whenever the number of prefixes received exceeds the maximum number configured, the BGP session is terminated, which is the default behavior, after sending a cease notification to the neighbor. The session is down until a manual clear is performed by the user. The session can be resumed by using the clear bgp command. It is possible to configure a period after which the session can be automatically brought up by using the maximum-prefix command with the restart keyword. The maximum prefix limit can be configured by the user. Default limits are used if the user does not configure the maximum number of prefixes for the address family.
Discard Extra Paths
An option to discard extra paths is added to the maximum-prefix configuration. Configuring the discard extra paths option drops all excess prefixes received from the neighbor when the prefixes exceed the configured maximum value. This drop does not, however, result in session flap.
The benefits of discard extra paths option are:
-
Limits the memory footstamp of BGP.
-
Stops the flapping of the peer if the paths exceed the set limit.
When the discard extra paths configuration is removed, BGP sends a route-refresh message to the neighbor if it supports the refresh capability; otherwise the session is flapped.
On the same lines, the following describes the actions when the maximum prefix value is changed:
-
If the maximum value alone is changed, a route-refresh message is sourced, if applicable.
-
If the new maximum value is greater than the current prefix count state, the new prefix states are saved.
-
If the new maximum value is less than the current prefix count state, then some existing prefixes are deleted to match the new configured state value.
There is currently no way to control which prefixes are deleted.
Configure Discard Extra Paths
The discard extra paths option in the maximum-prefix configuration allows you to drop all excess prefixes received from the neighbor when the prefixes exceed the configured maximum value. This drop does not, however, result in session flap.
The benefits of discard extra paths option are:
-
Limits the memory footstamp of BGP.
-
Stops the flapping of the peer if the paths exceed the set limit.
Note |
|
Perform this task to configure BGP maximum-prefix discard extra paths.
Procedure
| Step 1 |
configure Example:Enters XR Config mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. |
| Step 5 |
maximum-prefix maximum discard-extra-paths Example:Configures a limit to the number of prefixes allowed. Configures discard extra paths to discard extra paths when the maximum prefix limit is exceeded. |
| Step 6 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Example
The following example shows how to configure discard extra paths feature for the IPv4 address family:
RP/0//CPU0:router# configure
RP/0//CPU0:router(config)# router bgp 10
RP/0//CPU0:router(config-bgp)# neighbor 10.0.0.1
RP/0//CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0//CPU0:router(config-bgp-nbr-af)# maximum-prefix 1000 discard-extra-paths
RP/0//CPU0:router(config-bgp-vrf-af)# commit
The following screen output shows details about the discard extra paths option:
RP/0//CPU0:ios# show bgp neighbor 10.0.0.1
BGP neighbor is 10.0.0.1
Remote AS 10, local AS 10, internal link
Remote router ID 0.0.0.0
BGP state = Idle (No best local address found)
Last read 00:00:00, Last read before reset 00:00:00
Hold time is 180, keepalive interval is 60 seconds
Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
Last write 00:00:00, attempted 0, written 0
Second last write 00:00:00, attempted 0, written 0
Last write before reset 00:00:00, attempted 0, written 0
Second last write before reset 00:00:00, attempted 0, written 0
Last write pulse rcvd not set last full not set pulse count 0
Last write pulse rcvd before reset 00:00:00
Socket not armed for io, not armed for read, not armed for write
Last write thread event before reset 00:00:00, second last 00:00:00
Last KA expiry before reset 00:00:00, second last 00:00:00
Last KA error before reset 00:00:00, KA not sent 00:00:00
Last KA start before reset 00:00:00, second last 00:00:00
Precedence: internet
Multi-protocol capability not received
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Minimum time between advertisement runs is 0 secs
For Address Family: IPv4 Unicast
BGP neighbor version 0
Update group: 0.1 Filter-group: 0.0 No Refresh request being processed
Route refresh request: received 0, sent 0
0 accepted prefixes, 0 are bestpaths
Cumulative no. of prefixes denied: 0.
Prefix advertised 0, suppressed 0, withdrawn 0
Maximum prefixes allowed 10 (discard-extra-paths) <<<<<<<<<<<<<<<<<<<<<
Threshold for warning message 75%, restart interval 0 min
AIGP is enabled
An EoR was not received during read-only mode
Last ack version 1, Last synced ack version 0
Outstanding version objects: current 0, max 0
Additional-paths operation: None
Send Multicast Attributes
Connections established 0; dropped 0
Local host: 0.0.0.0, Local port: 0, IF Handle: 0x00000000
Foreign host: 10.0.0.1, Foreign port: 0
Last reset 00:00:00
BGP Best-External Path
The best–external path functionality supports advertisement of the best–external path to the iBGP and Route Reflector peers when a locally selected bestpath is from an internal peer. BGP selects one best path and one backup path to every destination. By default, selects one best path . Additionally, BGP selects another bestpath from among the remaining external paths for a prefix. Only a single path is chosen as the best–external path and is sent to other PEs as the backup path. BGP calculates the best–external path only when the best path is an iBGP path. If the best path is an eBGP path, then best–external path calculation is not required.
The procedure to determine the best–external path is as follows:
-
Determine the best path from the entire set of paths available for a prefix.
-
Eliminate the current best path.
-
Eliminate all the internal paths for the prefix.
-
From the remaining paths, eliminate all the paths that have the same next hop as that of the current best path.
-
Rerun the best path algorithm on the remaining set of paths to determine the best–external path.
BGP considers the external and confederations BGP paths for a prefix to calculate the best–external path. BGP advertises the best path and the best–external path as follows:
-
On the primary PE—advertises the best path for a prefix to both its internal and external peers
-
On the backup PE—advertises the best path selected for a prefix to the external peers and advertises the best–external path selected for that prefix to the internal peers
Configure Best-External Path Advertisement
Perform the following tasks to advertise the best–external path to the iBGP and route-reflector peers:
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
Do one of the following
Example:Specifies the address family or VRF address family and enters the address family or VRF address family configuration submode. |
| Step 4 |
advertise best-external Example:Advertise the best–external path to the iBGP and route-reflector peers. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Local Label Retention
When a primary PE-CE link fails, BGP withdraws the route corresponding to the primary path along with its local label and programs the backup path in the Routing Information Base (RIB) and the Forwarding Information Base (FIB), by default.
However, until all the internal peers of the primary PE reconverge to use the backup path as the new bestpath, the traffic continues to be forwarded to the primary PE with the local label that was allocated for the primary path. Hence the previously allocated local label for the primary path must be retained on the primary PE for some configurable time after the reconvergence. BGP Local Label Retention feature enables the retention of the local label for a specified period. If no time is specified, the local lable is retained for a default value of five minutes.
Retain Allocated Local Label for Primary Path
Perform the following tasks to retain the previously allocated local label for the primary path on the primary PE for some configurable time after reconvergence:
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { vpnv4 unicast | vpnv6 unicast } Example:Specifies the address family and enters the address family configuration submode. |
| Step 4 |
retain local-label minutes Example:Retains the previously allocated local label for the primary path on the primary PE for 10 minutes after reconvergence. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Allocated Local Label Retention: Example
The following example shows how to retain the previously allocated local label for the primary path on the primary PE for 10 minutes after reconvergence:
router bgp 100
address-family l2vpn vpnv4 unicast
retain local-label 10
end
BGP Labeled Unicast Multiple Label Stack Overview
BGP Labeled Unicast Multiple Label Stack feature enables the user to make the XR router receive and advertise BGP LU updates with a stack of one or more labels associated with the encoded prefix.
This feature provides the ability for a controller to push a multiple label stack through BGP labeled unicast session onto the headend.
Prerequisites
BGP Labelled unicast address-family needs to be supported.
Restrictions
Due to hardware limitations, only a maximum of three label stacks is supported; from Release 6.6.1, a maximum of five labels are supportedTopology
The following section illustrates the topology for the BGP Labeled Unicast Multiple Label Stack feature.
Based on the multi-label stack pushed by the controller on to the head end E, the traffic is steered through the network. In this topology, as the controller is pushing the label stack 14001, 16001, and 32001 with NH 172.6.0.1, traffic is steered through the nodes B, D, and G sequentially. If the controller needs to change the traffic path to nodes C, F, and G sequentially, it pushes the label stack 15002, 17002, and 32001 with NH of 93.4.3.1.
Configuration
This section describes how you can configure the BGP Labeled Unicast Multiple Label Stack feature.
Configure the nexthop mpls forwarding ibgp command in BGP configuration mode. Configure the BGP labeled unicast session with Nexthop 10.3.2.2 so the "ImpNULL" label is pushed as the first label into the multiple-label stack.
Router# configure
Router(config)# router bgp 100
Router(config-bgp)# neighbor 10.0.1.101
Router(config-bgp)# nexthop mpls forwarding ibgp
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# allocate-label all
Router(config-bgp-af)# exit
Router(config-bgp)# neighbor 10.3.2.2
Router(config-bgp-nbr)# remote-as 100
Router(config-bgp-nbr)# address-family ipv4 labeled-unicast
Router(config-bgp)# exit
Router(config-bgp)# neighbor-group group 1
Router(config-bgp-nbrgrp)# neighbor-group group 1
Router(config-bgp-nbrgrp)# remote-as 65535
Router(config-bgp-nbrgrp)# address-family ipv4 labeled-unicast
Router(config-bgp-nbrgrp-af)# route-policy pass in
Router(config-bgp-nbrgrp-af)# route-policy pass out
Router(config-bgp-nbrgrp-af)# enforce-multiple-labels
Router(config-bgp-nbrgrp-af)# exit
Router(config-bgp-nbrgrp)# exit
Router(config-bgp)# neighbor 10.0.1.101
Router(config-bgp-nbr)# use neighbor-group ipv4lu_ng1
Router(config-bgp-nbr)# exit
Router(config-bgp)# exit
Router(config-bgp)# neighbor 10.0.1.101
Router(config-bgp-nbr)# remote-as 65535
Router(config-bgp-nbr)# address-family ipv4 labeled-unicast
Router(config-bgp-nbr-af)# route-policy pass in
Router(config-bgp-nbr-af)# route-policy pass out
Router(config-bgp-nbr-af)# route-reflector-client
Router(config-bgp-nbr-af)# enforce-multiple-labels
Running Configuration
router bgp 100
bgp router-id 10.0.1.101
nexthop mpls forwarding ibgp
address-family ipv4 unicast
allocate-label all
!
neighbor 10.3.2.2
remote-as 100
address-family ipv4 labeled-unicast
!
neighbor-group ipv4lu_ng1
remote-as 100
address-family ipv4 labeled-unicast
route-policy pass in
route-policy pass out
enforce-multiple-labels
neighbor 10.0.1.101
use neighbor-group ipv4lu_ng1
!
!
neighbor 10.0.1.101
remote-as 100
address-family ipv4 labeled-unicast
route-policy pass out
route-policy pass in
route-reflector-client
enforce-multiple-labels
!
Verification
The show outputs given in the following section display the details of configuration of the BGP LU Multiple Label Stack feature, and the status of their configuration.
/* Verify the multiple label stack. */
Router# show bgp ipv4 labeled-unicast 10.1.1.1/32
...
10.3.2.2 from 10.0.1.101
Received Label 14001 16001 32001
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
...
/* Verify if the multiple label stack is enabled.*/
Router# show bgp neighbor 10.0.1.101
...
For Address Family: IPv4 Labeled-unicast
BGP neighbor version 177675
Update group: 0.8 Filter-group: 0.4 No Refresh request being processed
Route-Reflector Client
Send Multicast Attributes
Multiple label stack: Enabled
/* Verify that the multiple label stack is enabled. */
Router# show bgp ipv4 labeled-unicast update-group 0.8
Update group for IPv4 Labeled-unicast, index 0.8:
Attributes:
Neighbor sessions are IPv4
Outbound policy: ibgp-rpl1
Internal
Common admin
First neighbor AS: 100
Send communities
Send GSHUT community if originated
Send extended communities
Route Reflector Client
4-byte AS capable
Send AIGP
Send multicast attributes
Multiple label stack: Enabled
/* Verify that the multiple label stack is enabled. */
Router# show bgp labels
...
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 Rcvd Label Local Label
*>i10.1.1.1/32 10.3.2.2 14001 16001 24193
32001
*>i1.2.2.2/32 10.4.3.1 15002 17002 24199
32002
*>i1.3.3.3/32 10.3.2.2 14001 16001 24200
32002
...
/* */
Router# show route 10.1.1.1/32 detail
Routing entry for 10.1.1.1/32
Known via "bgp 100", distance 200, metric 476387081, [ei]-bgp, labeled unicast (3107)
...
Routing Descriptor Blocks
209.165.201.1, from 10.0.1.101
Route metric is 476387081
Labels: 0x36b1 0x3e81 0x7d01 (14001 16001 32001)
Tunnel ID: None
Binding Label: None
Extended communities count: 0
NHID:0x0(Ref:0)
MPLS eid:0x1380b00000003
/* Verify that the multiple label stack is enabled. */
Router# show cef 10.1.1.1/32 detail
10.1.1.1/32, version 251579, internal 0x5000001 0x0 (ptr 0xa0241200) [1], 0x0 (0xa03feab8), 0xa08
(0x9fced2b0)
...
via 10.3.2.2/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0x9e873ca0 0x0]
recursion-via-/32
next hop 10.3.2.2/32 via 24192/0/21
local label 24193
next hop 10.3.2.2/32 Te0/0/0/0/1 labels imposed {ImplNull 14001 16001 32001}
/* Verify the maximum supported depth of the label stack. If the number of labels received exceeds the maximum
supported by the platform, the prefix is not downloaded to the RIB and hence routing issues may occur. */
Router# show bgp ipv4 labeled-unicast process performance detail
...
Address Family: IPv4 Labeled-unicast
State: Normal mode.
BGP Table Version: 177675
Attribute download: Disabled
ASBR functionality enabled
Label retention timer value 5 mins
Soft Reconfig Entries: 367
Table bit-field size : 1 Chunk element size : 3
Maximum supported label-stack depth:
For IPv4 Nexthop: 3
For IPv6 Nexthop: 0
...
iBGP Multipath Load Sharing
When a Border Gateway Protocol (BGP) speaking router that has no local policy configured, receives multiple network layer reachability information (NLRI) from the internal BGP (iBGP) for the same destination, the router will choose one iBGP path as the best path. The best path is then installed in the IP routing table of the router. The iBGP Multipath Load Sharing feature enables the BGP speaking router to select multiple iBGP paths as the best paths to a destination. The best paths or multipaths are then installed in the IP routing table of the router.
iBGP Multipath Load Sharing Reference provides additional details.
Configure iBGP Multipath Load Sharing
Perform this task to configure the iBGP Multipath Load Sharing:
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family {ipv4 |ipv6 } {unicast |multicast } Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. |
| Step 4 |
maximum-paths ibgp number Example:Configures the maximum number of iBGP paths for load sharing. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
iBGP Multipath Loadsharing Configuration: Example
The following is a sample configuration where 30 paths are used for loadsharing:
router bgp 100
address-family ipv4 multicast
maximum-paths ibgp 30
!
!
end
Route Dampening
Route dampening is a BGP feature that minimizes the propagation of flapping routes across an internetwork. A route is considered to be flapping when it is repeatedly available, then unavailable, then available, then unavailable, and so on.
For example, consider a network with three BGP autonomous systems: autonomous system 1, autonomous system 2, and autonomous system 3. Suppose the route to network A in autonomous system 1 flaps (it becomes unavailable). Under circumstances without route dampening, the eBGP neighbor of autonomous system 1 to autonomous system 2 sends a withdraw message to autonomous system 2. The border router in autonomous system 2, in turn, propagates the withdrawal message to autonomous system 3. When the route to network A reappears, autonomous system 1 sends an advertisement message to autonomous system 2, which sends it to autonomous system 3. If the route to network A repeatedly becomes unavailable, then available, many withdrawal and advertisement messages are sent. Route flapping is a problem in an internetwork connected to the Internet, because a route flap in the Internet backbone usually involves many routes.
The route dampening feature minimizes the flapping problem as follows. Suppose again that the route to network A flaps. The router in autonomous system 2 (in which route dampening is enabled) assigns network A a penalty of 1000 and moves it to history state. The router in autonomous system 2 continues to advertise the status of the route to neighbors. The penalties are cumulative. When the route flaps so often that the penalty exceeds a configurable suppression limit, the router stops advertising the route to network A, regardless of how many times it flaps. Thus, the route is dampened.
The penalty placed on network A is decayed until the reuse limit is reached, upon which the route is once again advertised. At half of the reuse limit, the dampening information for the route to network A is removed.
Note |
No penalty is applied to a BGP peer reset when route dampening is enabled, even though the reset withdraws the route. |
Configuring BGP Route Dampening
Perform this task to configure and monitor BGP route dampening.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
bgp dampening [ half-life [ reuse suppress max-suppress-time ] | route-policy route-policy-name ] Example:Configures BGP dampening for the specified address family. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Routing Policy Enforcement
External BGP (eBGP) neighbors must have an inbound and outbound policy configured. If no policy is configured, no routes are accepted from the neighbor, nor are any routes advertised to it. This added security measure ensures that routes cannot accidentally be accepted or advertised in the case of a configuration omission error.
Note |
This enforcement affects only eBGP neighbors (neighbors in a different autonomous system than this router). For internal BGP (iBGP) neighbors (neighbors in the same autonomous system), all routes are accepted or advertised if there is no policy. |
Apply Policy When Updating Routing Table
The table policy feature in BGP allows you to configure traffic index values on routes as they are installed in the global routing table. This feature is enabled using the table-policy command and supports the BGP policy accounting feature. Table policy also provides the ability to drop routes from the RIB based on match criteria. This feature can be useful in certain applications and should be used with caution as it can easily create a routing traffic drop where BGP advertises routes to neighbors that BGP does not install in its global routing table and forwarding table.
Perform this task to apply a routing policy to routes being installed into the routing table.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either the IPv4 or IPv6 address family and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
table-policy policy-name Example:Applies the specified policy to routes being installed into the routing table. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Applying routing policy: Example
In the following example, for an eBGP neighbor, if all routes should be accepted and advertised with no modifications, a simple pass-all policy is configured:
RP/0/RP0/CPU0:router(config)# route-policy pass-all
RP/0/RP0/CPU0:router(config-rpl)# pass
RP/0/RP0/CPU0:router(config-rpl)# end-policy
RP/0/RP0/CPU0:router(config)# commit
Use the route-policy (BGP) command in the neighbor address-family configuration mode to apply the pass-all policy to a neighbor. The following example shows how to allow all IPv4 unicast routes to be received from neighbor 192.168.40.42 and advertise all IPv4 unicast routes back to it:
RP/0/RP0/CPU0:router(config)# router bgp 1
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.40.24
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 21
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# route-policy pass-all in
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# route-policy pass-all out
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit
Use the show bgp summary command to display eBGP neighbors that do not have both an inbound and outbound policy for every active address family. In the following example, such eBGP neighbors are indicated in the output with an exclamation (!) mark:
RP/0/RP0/CPU0:router# show bgp all all summary
Address Family: IPv4 Unicast
============================
BGP router identifier 10.0.0.1, local AS number 1
BGP generic scan interval 60 secs
BGP main routing table version 41
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RecvTblVer bRIB/RIB SendTblVer
Speaker 41 41 41
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.0.101.1 0 1 919 925 41 0 0 15:15:08 10
10.0.101.2 0 2 0 0 0 0 0 00:00:00 Idle
Configure BGP Neighbor Group and Neighbors
Perform this task to configure BGP neighbor groups and apply the neighbor group configuration to a neighbor. A neighbor group is a template that holds address family-independent and address family-dependent configurations associated with the neighbor.
After a neighbor group is configured, each neighbor can inherit the configuration through the use command. If a neighbor is configured to use a neighbor group, the neighbor (by default) inherits the entire configuration of the neighbor group, which includes the address family-independent and address family-dependent configurations. The inherited configuration can be overridden if you directly configure commands for the neighbor or configure session groups or address family groups through the use command.
You can configure an address family-independent configuration under the neighbor group. An address family-dependent configuration requires you to configure the address family under the neighbor group to enter address family submode. From neighbor group configuration mode, you can configure address family-independent parameters for the neighbor group. Use the address-family command when in the neighbor group configuration mode. After specifying the neighbor group name using the neighbor group command, you can assign options to the neighbor group.
Note |
All commands that can be configured under a specified neighbor group can be configured under a neighbor. |
Note |
In Cisco IOS-XR versions prior to 6.3.2, you cannot remove a autonomous system that belongs to a BGP neighbour and move it under a BGP neigbhorgroup using a single IOS-XR commit. Effective with 6.3.2, you can move the autonoums system from a neighbour to a neighbour group in a single IOS-XR commit. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
exit Example:Exits the current configuration mode. |
| Step 5 |
neighbor-group name Example:Places the router in neighbor group configuration mode. |
| Step 6 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 7 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 8 |
route-policy route-policy-name { in | out } Example:(Optional) Applies the specified policy to inbound IPv4 unicast routes. |
| Step 9 |
exit Example:Exits the current configuration mode. |
| Step 10 |
exit Example:Exits the current configuration mode. |
| Step 11 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 12 |
use neighbor-group group-name Example:(Optional) Specifies that the BGP neighbor inherit configuration from the specified neighbor group. |
| Step 13 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 14 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Neighbor Configuration: Example
The following example shows how BGP neighbors on an autonomous system are configured to share information. In the example, a BGP router is assigned to autonomous system 109, and two networks are listed as originating in the autonomous system. Then the addresses of three remote routers (and their autonomous systems) are listed. The router being configured shares information about networks 172 .16 .0.0 and 192.168 .7.0 with the neighbor routers. The first router listed is in a different autonomous system; the second neighbor and remote-as commands specify an internal neighbor (with the same autonomous system number) at address 172 .26 .234.2; and the third neighbor and remote-as commands specify a neighbor on a different autonomous system.
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.168.7.0 255.255.0.0
neighbor 172.16.200.1
remote-as 167
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-out out
neighbor 172.26.234.2
remote-as 109
address-family ipv4 unicast
neighbor 172.26.64.19
remote-as 99
address-family ipv4 unicast
route-policy pass-all in
route-policy pass-all out
Disable BGP Neighbor
Perform this task to administratively shut down a neighbor session without removing the configuration.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
shutdown Example:Disables all active sessions for the specified neighbor. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Resetting Neighbors Using BGP Inbound Soft Reset
Perform this task to trigger an inbound soft reset of the specified address families for the specified group or neighbors. The group is specified by the * , ip-address , as-number , or external keywords and arguments.
Resetting neighbors is useful if you change the inbound policy for the neighbors or any other configuration that affects the sending or receiving of routing updates. If an inbound soft reset is triggered, BGP sends a REFRESH request to the neighbor if the neighbor has advertised the ROUTE_REFRESH capability. To determine whether the neighbor has advertised the ROUTE_REFRESH capability, use the show bgp neighbors command.
Procedure
| Command or Action | Purpose | |
|---|---|---|
| Step 1 |
show bgp neighbors Example: |
Verifies that received route refresh capability from the neighbor is enabled. |
| Step 2 |
soft [ in [ prefix-filter ] | out ] Example: |
Soft resets a BGP neighbor.
|
Resetting Neighbors Using BGP Outbound Soft Reset
Perform this task to trigger an outbound soft reset of the specified address families for the specified group or neighbors. The group is specified by the * , ip-address , as-number , or external keywords and arguments.
Resetting neighbors is useful if you change the outbound policy for the neighbors or any other configuration that affects the sending or receiving of routing updates.
If an outbound soft reset is triggered, BGP resends all routes for the address family to the given neighbors.
To determine whether the neighbor has advertised the ROUTE_REFRESH capability, use the show bgp neighbors command.
Procedure
| Command or Action | Purpose | |
|---|---|---|
| Step 1 |
show bgp neighbors Example: |
Verifies that received route refresh capability from the neighbor is enabled. |
| Step 2 |
Example: |
Soft resets a BGP neighbor.
|
Reset Neighbors Using BGP Hard Reset
Perform this task to reset neighbors using a hard reset. A hard reset removes the TCP connection to the neighbor, removes all routes received from the neighbor from the BGP table, and then re-establishes the session with the neighbor. If the graceful keyword is specified, the routes from the neighbor are not removed from the BGP table immediately, but are marked as stale. After the session is re-established, any stale route that has not been received again from the neighbor is removed.
Procedure
|
clear bgp { ipv4 { unicast | labeled-unicast | all | tunnel tunnel | mdt } | ipv6 unicast | all | labeled-unicast } | all { unicast | multicast | all | labeled-unicast | mdt | tunnel } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 unicast | labeled-unicast } | ipv6 unicast } | vpnv6 unicast } { * | ip-address | as as-number | external } [ graceful ] soft [ in [ prefix-filter ] | out ] clear bgp { ipv4 | ipv6} { unicast | labeled-unicast } Example:Clears a BGP neighbor.
The graceful keyword specifies a graceful restart. |
Configure Software to Store Updates from Neighbor
Perform this task to configure the software to store updates received from a neighbor.
The soft-reconfiguration inbound command causes a route refresh request to be sent to the neighbor if the neighbor is route refresh capable. If the neighbor is not route refresh capable, the neighbor must be reset to relearn received routes using the clear bgp soft command.
Note |
Storing updates from a neighbor works only if either the neighbor is route refresh capable or the soft-reconfiguration inbound command is configured. Even if the neighbor is route refresh capable and the soft-reconfiguration inbound command is configured, the original routes are not stored unless the always option is used with the command. The original routes can be easily retrieved with a route refresh request. Route refresh sends a request to the peer to resend its routing information. The soft-reconfiguration inbound command stores all paths received from the peer in an unmodified form and refers to these stored paths during the clear. Soft reconfiguration is memory intensive. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 5 |
soft-reconfiguration inbound [ always] Example:Configures the software to store updates received from a specified neighbor. Soft reconfiguration inbound causes the software to store the original unmodified route in addition to a route that is modified or filtered. This allows a “soft clear” to be performed after the inbound policy is changed. Soft reconfiguration enables the software to store the incoming updates before apply policy if route refresh is not supported by the peer (otherwise a copy of the update is not stored). The always keyword forces the software to store a copy even when route refresh is supported by the peer. |
| Step 6 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Log Neighbor Changes
Logging neighbor changes is enabled by default. Use thebgp log neighbor changes disable command to turn off logging. Use the no bgp log neighbor changes disable command to turn logging back on, if it has been disabled.
RP/0/RP0/CPU0:(config)# router bgp 100
RP/0/RP0/CPU0:(config-bgp)# bgp log neighbor changes disable
RP/0/RP0/CPU0:(config)# router bgp 100
RP/0/RP0/CPU0:(config-bgp)# no bgp log neighbor changes disable
BGP Route Reflectors
BGP requires that all iBGP speakers be fully meshed. However, this requirement does not scale well when there are many iBGP speakers. Instead of configuring a confederation, you can reduce the iBGP mesh by using a route reflector configuration. With route reflectors, all iBGP speakers need not be fully meshed because there is a method to pass learned routes to neighbors. In this model, an iBGP peer is configured to be a route reflector responsible for passing iBGP learned routes to a set of iBGP neighbors.
In #concept_3069A67F47124831B884817915F11DF3__ , Router B is configured as a route reflector. When the route reflector receives routes advertised from Router A, it advertises them to Router C, and vice versa. This scheme eliminates the need for the iBGP session between routers A and C.
See BGP Route Reflectors Reference for additional details on route reflectors.
Configure Route Reflector for BGP
Perform this task to configure a route reflector for BGP.
All the neighbors configured with the route-reflector-clientcommand are members of the client group, and the remaining iBGP peers are members of the nonclient group for the local route reflector.
Together, a route reflector and its clients form a cluster. A cluster of clients usually has a single route reflector. In such instances, the cluster is identified by the software as the router ID of the route reflector. To increase redundancy and avoid a single point of failure in the network, a cluster can have more than one route reflector. If it does, all route reflectors in the cluster must be configured with the same 4-byte cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster. The bgp cluster-id command is used to configure the cluster ID when the cluster has more than one route reflector.
The bgp cluster-id option is used in this task to configure the router as one of the route reflectors serving the cluster. The cluster-id option is also available in the BGP neighbor address-family (config-bgp-nbr-af) mode. To enable a router to accept BGP routes which have the same first cluster-ID as the router’s own cluster-ID in the list of cluster-IDs, use the cluster-id allow-equal command. You must use this command with care to avoid routing loops.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
bgp cluster-id cluster-id Example:Configures the local router as one of the route reflectors serving the cluster. It is configured with a specified cluster ID to identify the cluster. |
| Step 4 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 5 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 6 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 7 |
route-reflector-client Example:Configures the router as a BGP route reflector and configures the neighbor as its client. |
| Step 8 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Route Reflector: Example
The following example shows how to use an address family to configure internal BGP peer 10.1.1.1 as a route reflector client for unicast prefixes:
router bgp 140
address-family ipv4 unicast
neighbor 10.1.1.1
remote-as 140
address-family ipv4 unicast
route-reflector-client
exit
Configure BGP Route Filtering by Route Policy
Perform this task to configure BGP routing filtering by route policy.
Procedure
| Command or Action | Purpose | |
|---|---|---|
| Step 1 |
configure Example: |
Enters mode. |
| Step 2 |
route-policy name Example: |
(Optional) Creates a route policy and enters route policy configuration mode, where you can define the route policy. |
| Step 3 |
end-policy Example: |
(Optional) Ends the definition of a route policy and exits route policy configuration mode. |
| Step 4 |
router bgp as-number Example: |
Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 5 |
neighbor ip-address Example: |
Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 6 |
address-family { ipv4 | ipv6 } unicast Example: |
Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 7 |
route-policy route-policy-name { in | out } Example: |
Applies the specified policy to inbound routes. |
| Step 8 |
Use the commit or end command. |
commit —Saves the configuration changes and remains within the configuration session.
|
Configure BGP Attribute Filtering
The BGP Attribute Filter checks integrity of BGP updates in BGP update messages and optimizes reaction when detecting invalid attributes. BGP Update message contains a list of mandatory and optional attributes. These attributes in the update message include MED, LOCAL_PREF, COMMUNITY, and so on. In some cases, if the attributes are malformed, there is a need to filter these attributes at the receiving end of the router. The BGP Attribute Filter functionality filters the attributes received in the incoming update message. The attribute filter can also be used to filter any attributes that may potentially cause undesirable behavior on the receiving router. Some of the BGP updates are malformed due to wrong formatting of attributes such as the network layer reachability information (NLRI) or other fields in the update message. These malformed updates, when received, causes undesirable behavior on the receiving routers. Such undesirable behavior may be encountered during update message parsing or during re-advertisement of received NLRIs. In such scenarios, its better to filter these corrupted attributes at the receiving end.
The Attribute-filtering is configured by specifying a single or a range of attribute codes and an associated action. When a received Update message contains one or more filtered attributes, the configured action is applied on the message. Optionally, the Update message is also stored to facilitate further debugging and a syslog message is generated on the console. When an attribute matches the filter, further processing of the attribute is stopped and the corresponding action is taken. Perform the following tasks to configure BGP attribute filtering:
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
attribute-filter group attribute-filter group name Example:Specifies the attribute-filter group name and enters the attribute-filter group configuration mode, allowing you to configure a specific attribute filter group for a BGP neighbor. |
| Step 4 |
attribute attribute code { discard | treat-as-withdraw } Example:
|
BGP Next Hop Tracking
BGP receives notifications from the Routing Information Base (RIB) when next-hop information changes (event-driven notifications). BGP obtains next-hop information from the RIB to:
-
Determine whether a next hop is reachable.
-
Find the fully recursed IGP metric to the next hop (used in the best-path calculation).
-
Validate the received next hops.
-
Calculate the outgoing next hops.
-
Verify the reachability and connectedness of neighbors.
BGP Next Hop Reference provides additional conceptual details on BGP next hop.
Configure BGP Next-Hop Trigger Delay
Perform this task to configure BGP next-hop trigger delay. The Routing Information Base (RIB) classifies the dampening notifications based on the severity of the changes. Event notifications are classified as critical and noncritical. This task allows you to specify the minimum batching interval for the critical and noncritical events.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 4 |
nexthop trigger-delay { critical delay | non-critical delay } Example:Sets the critical next-hop trigger delay. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Disable Next-Hop Processing on BGP Updates
Perform this task to disable next-hop calculation for a neighbor and insert your own address in the next-hop field of BGP updates. Disabling the calculation of the best next hop to use when advertising a route causes all routes to be advertised with the network device as the next hop.
Note |
Next-hop processing can be disabled for address family group, neighbor group, or neighbor address family. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 5 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 6 |
next-hop-self Example:Sets the next-hop attribute for all routes advertised to the specified neighbor to the address of the local router. Disabling the calculation of the best next hop to use when advertising a route causes all routes to be advertised with the local network device as the next hop. |
| Step 7 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
BGP Cost Community
The BGP cost community is a nontransitive extended community attribute that is passed to internal BGP (iBGP) and confederation peers but not to external BGP (eBGP) peers. The cost community feature allows you to customize the local route preference and influence the best-path selection process by assigning cost values to specific routes. The extended community format defines generic points of insertion (POI) that influence the best-path decision at different points in the best-path algorithm.
BGP Cost Community Reference provides additional conceptual details on BGP cost community.
Configure BGP Cost Community
BGP receives multiple paths to the same destination and it uses the best-path algorithm to decide which is the best path to install in RIB. To enable users to determine an exit point after partial comparison, the cost community is defined to tie-break equal paths during the best-path selection process. Perform this task to configure the BGP cost community.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
route-policy name Example:Enters route policy configuration mode and specifies the name of the route policy to be configured. |
| Step 3 |
set extcommunity cost { cost-extcommunity-set-name | cost-inline-extcommunity-set } [ additive ] Example:Specifies the BGP extended community attribute for cost. |
| Step 4 |
end-policy Example:Ends the definition of a route policy and exits route policy configuration mode. |
| Step 5 |
router bgp as-number Example:Enters BGP configuration mode allowing you to configure the BGP routing process. |
| Step 6 |
Do one of the following:
Applies the cost community to the attach point (route policy). |
| Step 7 |
Do one of the following:
|
| Step 8 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
| Step 9 |
show bgp ip-address Example:Displays the cost community in the following format: Cost: POI : cost-community-ID : cost-number |
Configure BGP Community and Extended-Community Advertisements
Perform this task to specify that community/extended-community attributes should be sent to an eBGP neighbor. These attributes are not sent to an eBGP neighbor by default. By contrast, they are always sent to iBGP neighbors. This section provides examples on how to enable sending community attributes. The send-community-ebgp keyword can be replaced by the send-extended-community-ebgp keyword to enable sending extended-communities.
If the send-community-ebgp command is configured for a neighbor group or address family group, all neighbors using the group inherit the configuration. Configuring the command specifically for a neighbor overrides inherited values.
Note |
BGP community and extended-community filtering cannot be configured for iBGP neighbors. Communities and extended-communities are always sent to iBGP neighbors under VPNv4, MDT, IPv4, and IPv6 address families. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 5 |
address-family {ipv4 {labeled-unicast | unicast | mdt | | mvpn | rt-filter | tunnel } | ipv6 {labeled-unicast | mvpn | unicast }} Example:Enters neighbor address family configuration mode for the specified address family. Use either ipv4 or ipv6 address family keyword with one of the specified address family sub mode identifiers.
|
| Step 6 |
Use one of these commands:
Example:or Specifies that the router send community attributes or extended community attributes (which are disabled by default for eBGP neighbors) to a specified eBGP neighbor. |
| Step 7 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Configuring BGP Large Communities
BGP communities provide a way to group destinations and apply routing decisions such as acceptance, rejection, preference, or redistribution on a group of destinations using community attributes. BGP community attributes are variable length attributes consisting of a set of one or more 4-byte values which are split into two parts of 16 bits. The higher-order 16 bits represents the AS number and the lower order bits represents a locally defined value assigned by the operator of the AS.
Since the adoption of 4-byte ASNs (RFC6793), the BGP communities attribute can no longer accommodate the 4 byte ASNs as you need more than 4 bytes to encode the 4-byte ASN and an AS specific value that you want to tag with the route. Although BGP extended community permits a 4-byte AS to be encoded as the global administrator field, the local administrator field has only 2-byte of available space. So, 6-byte extended community attribute is also unsuitable. To overcome this limitation, you can configure a 12-byte BGP large community which is an optional attribute that provides the most significant 4-byte value to encode autonomous system number as the global administrator and the remaining two 4-byte assigned numbers to encode the local values.
Similar to BGP communities, routers can apply BGP large communities to BGP routes by using route policy languages (RPL) and other routers can then perform actions based on the community that is attached to the route. The policy language provides sets as a container for groups of values for matching purposes.
When large communities are specified in other commands, they are specified as three non negative decimal integers separated by colons. For example, 1:2:3. Each integer is stored in 32 bits. The possible range for each integer is 0 to 4294967295.
In route-policy statements, each integer in the BGP large community can be replaced by any of the following expressions :
-
[x..y] — This expression specifies a range between x and y, inclusive.
-
* —This expression stands for any number.
-
peeras — This expression is replaced by the AS number of the neigbhor from which the community is received or to which the community is sent, as appropriate.
-
not-peeras —This expression matches any number other than the peeras.
-
private-as — This expression specifies any number in the private ASN range: [64512..65534] and [4200000000..4294967294].
These expressions can be also used in policy-match statements.
IOS regular expression (ios-regex) and DFA style regular expression (dfa-regex) can be used in any of the large-community policy match and delete statements. For example, the IOS regular expression ios-regex '^5:.*:7$' is equivalent to the expression 5:*:7.
The send-community-ebgp command is extended to include BGP large communities. This command is required for the BGP speaker to send large communities to ebgp neighbors.
Restrictions and Guidelines
The following restrictions and guidelines apply for BGP large communities:
-
All functionalities of 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.
-
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 that are applied at the neighbor-in or neighbor-out attach points.
-
The not-peeras expression cannot be used in a large-community-set or in policy set statements.
Configuration Example: Large Community Set
A large-community set defines a set of large communities. Named large-community sets are used in route-policy match and set statements.
This example shows how to create a named large-community set.
RP/0/RP0/CPU0:router(config)# large-community-set catbert
RP/0/RP0/CPU0:router(config-largecomm)# 1: 2: 3,
RP/0/RP0/CPU0:router(config-largecomm)# peeras:2:3
RP/0/RP0/CPU0:router(config-largecomm)# end-set
Configuration Example: Set Large Community
The following example shows how to set the BGP large community attribute in a route, using the set large-community {large-community-set-name | inline-large-community-set | parameter } [additive ] command. You can specify a named large-community-set or an inline set. The additive keyword retains the large communities already present in the route and adds the new set of large communities. However the additive keyword does not result in duplicate entries.
If a particular large community is attached to a route and you specify the same large community again with the additive keyword in the set statement, then the specified large community is not added again. The merging operation removes duplicate entries. This also applies to the peeras keyword.
The peeras expression in the example is replaced by the AS number of the neighbor from which the BGP large community is received or to which the community is sent, as appropriate.
RP/0/RP0/CPU0:router(config)# route-policy mordac
RP/0/RP0/CPU0:router(config-rpl)# set large-community (1:2:3, peeras:2:3)
RP/0/RP0/CPU0:router(config-rpl)# end-set
RP/0/RP0/CPU0:router(config)# large-community-set catbert
RP/0/RP0/CPU0:router(config-largecomm)# 1: 2: 3,
RP/0/RP0/CPU0:router(config-largecomm)# peeras:2:3
RP/0/RP0/CPU0:router(config-largecomm)# end-set
RP/0/RP0/CPU0:router(config)# route-policy wally
RP/0/RP0/CPU0:router(config-rpl)# set large-community catbert additive
RP/0/RP0/CPU0:router(config-rpl)# end-set
In this example, if the route-policy mordac is applied to a neighbor, the ASN of which is 1, then the large community (1:2:3) is set only once.
Note |
You should configure the send-community-ebgp command to send large communities to ebgp neighbors. |
Configuration Example: Large Community Matches-any
The following example shows how to configure a route policy to match any element of a large -community set. This is a boolean condition and returns true if any of the large communities in the route match any of the large communities in the match condition.
RP/0/RP0/CPU0:router(config)# route-policy elbonia
RP/0/RP0/CPU0:router(config-rpl)# if large-community matches-any (1:2:3, 4:5:*) then
RP/0/RP0/CPU0:router(config-rpl)# set local-preference 94
RP/0/RP0/CPU0:router(config-rpl)# endif
RP/0/RP0/CPU0:router(config-rpl)# end-policy
Configuration Example: Large Community Matches-every
The following example shows how to configure a route policy where every match specification in the statement must be matched by at least one large community in the route.
RP/0/RP0/CPU0:router(config)# route-policy bob
RP/0/RP0/CPU0:router(config-rpl)# if large-community matches-every (*:*:3, 4:5:*) then
RP/0/RP0/CPU0:router(config-rpl)# set local-preference 94
RP/0/RP0/CPU0:router(config-rpl)# endif
RP/0/RP0/CPU0:router(config-rpl)# end-policy
In this example, routes with these sets of large communities return TRUE:
-
(1:1:3, 4:5:10)
-
(4:5:3) —This single large community matches both specifications.
-
(1:1:3, 4:5:10, 7:6:5)
Routes with the following set of large communities return FALSE:
(1:1:3, 5:5:10)—The specification (4:5:*) is not matched.
Configuration Example: Large Community Matches-within
The following example shows how to configure a route policy to match within a large community set. This is similar to the large-community matches-any command but every large community in the route must match at least one match specification. Note that if the route has no large communities, then it matches.
RP/0/RP0/CPU0:router(config)# route-policy bob
RP/0/RP0/CPU0:router(config-rpl)# if large-community matches-within (*:*:3, 4:5:*) then
RP/0/RP0/CPU0:router(config-rpl)# set local-preference 103
RP/0/RP0/CPU0:router(config-rpl)# endif
RP/0/RP0/CPU0:router(config-rpl)# end-policy
For example, routes with these sets of large communities return TRUE:
-
(1:1:3, 4:5:10)
-
(4:5:3)
-
(1:2:3, 6:6:3, 9:4:3)
Routes with this set of large communities return FALSE:
(1:1:3, 4:5:10, 7:6:5) —The large community (7:6:5) does not match
Configuration Example: Community Matches-within
The following example shows how to configure a route policy to match within the elements of a community set. This command is similar to the community matches-any command, but every community in the route must match at least one match specification. If the route has no communities, then it matches.
RP/0/RP0/CPU0:router(config)# route-policy bob
RP/0/RP0/CPU0:router(config-rpl)# if community matches-within (*:3, 5:*) then
RP/0/RP0/CPU0:router(config-rpl)# set local-preference 94
RP/0/RP0/CPU0:router(config-rpl)# endif
RP/0/RP0/CPU0:router(config-rpl)# end-policy
For example, routes with these sets of communities return TRUE:
-
(1:3, 5:10)
-
(5:3)
-
(2:3, 6:3, 4:3)
Routes with this set of communities return FALSE:
(1:3, 5:10, 6:5) —The community (6:5) does not match.
Configuration Example: Large Community Is-empty
The following example shows using the large-community is-empty clause to filter routes that do not have the large-community attribute set.
RP/0/RP0/CPU0:router(config)# route-policy lrg_comm_rp4
RP/0/RP0/CPU0:router(config-rpl)# if large-community is-empty then
RP/0/RP0/CPU0:router(config-rpl)# set local-preference 104
RP/0/RP0/CPU0:router(config-rpl)# endif
RP/0/RP0/CPU0:router(config-rpl)# end-policy
Configuration Example: Attribute Filter Group
The following example shows how to configure and apply the attribute-filter group with large-community attributes for a BGP neighbor. The filter specifies the BGP path attributes and an action to take when BGP update message is received. If an update message is received from the BGP neighbor that contains any of the specified attributes, then the specified action is taken. In this example, the attribute filter named dogbert is created and applied to the BGP neighbor 10.0.1.101. It specifies the large community attribute and the action of discard. That means, if the large community BGP path attribute is received in a BGP UPDATE message from the neighbor 10.0.1.101 then the attribute will be discarded before further processing of the message.
RP/0/RP0/CPU0:router(config)# router bgp 100
RP/0/RP0/CPU0:router(config-bgp)# attribute-filter group dogbert
RP/0/RP0/CPU0:router(config-bgp-attrfg)# attribute LARGE-COMMUNITY discard
RP/0/RP0/CPU0:router(config-bgp-attrfg)# neighbor 10.0.1.101
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 6461
RP/0/RP0/CPU0:router(config-bgp-nbr)# update in filtering
RP/0/RP0/CPU0:router(config-nbr-upd-filter)# attribute-filter group dogbert
Configuration Example: Deleting Large Community
The following example shows how to delete specified BGP large-communities from a route policy using the delete large-community command.
RP/0/RP0/CPU0:router(config)# route-policy lrg_comm_rp2
RP/0/RP0/CPU0:router(config-rpl)# delete large-community in (ios-regex '^100000:’)
RP/0/RP0/CPU0:router(config-rpl)# delete large-community all
RP/0/RP0/CPU0:router(config-rpl)# delete large-community not in (peeras:*:*, 41289:*:*)
Verification
This example displays the routes with large-communities given in the show bgp large-community list-of-large-communities [exact-match ] command. If the optional keyword exact-match is used, then the listed routes will contain only the specified large communities. Otherwise, the displayed routes may contain additional large communities.
RP/0/0/CPU0:R1# show bgp large-community 1:2:3 5:6:7
Thu Mar 23 14:40:33.597 PDT
BGP router identifier 4.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 ?
This example displays the large community attached to a network using the show bgp ip-address/ prefix-length command.
RP/0/0/CPU0:R4# 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:4123456788Redistribute iBGP Routes into IGP
Perform this task to redistribute iBGP routes into an Interior Gateway Protocol (IGP), such as Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF).
Note |
Use of the bgp redistribute-internal command requires the clear route * command to be issued to reinstall all BGP routes into the IP routing table. |
 Caution |
Redistributing iBGP routes into IGPs may cause routing loops to form within an autonomous system. Use this command with caution. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
bgp redistribute-internal Example:Allows the redistribution of iBGP routes into an IGP, such as IS-IS or OSPF. |
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Redistribute IGPs to BGP
Perform this task to configure redistribution of a protocol into the VRF address family.
Even if Interior Gateway Protocols (IGPs) are used as the PE-CE protocol, the import logic happens through BGP. Therefore, all IGP routes have to be imported into the BGP VRF table.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
vrf vrf-name Example:Enables BGP routing for a particular VRF on the PE router. |
| Step 4 |
address-family { ipv4 | ipv6 } unicast Example:Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode. To see a list of all the possible keywords and arguments for this command, use the CLI help (?). |
| Step 5 |
Do one of the following:
Example:Configures redistribution of a protocol into the VRF address family context. The redistribute command is used if BGP is not used between the PE-CE routers. If BGP is used between PE-CE routers, the IGP that is used has to be redistributed into BGP to establish VPN connectivity with other PE sites. Redistribution is also required for inter-table import and export. |
| Step 6 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Update Groups
The BGP Update Groups feature contains an algorithm that dynamically calculates and optimizes update groups of neighbors that share outbound policies and can share the update messages. The BGP Update Groups feature separates update group replication from peer group configuration, improving convergence time and flexibility of neighbor configuration.
Monitor BGP Update Groups
This task displays information related to the processing of BGP update groups.
Procedure
|
show bgp [ ipv4 { unicast | multicast | all | tunnel } | ipv6 { unicast | all } | all { unicast | multicast | all labeled-unicast | tunnel } | vpnv4 unicast | vrf { vrf-name | all } [ ipv4 unicast ipv6 unicast ] | vpvn6 unicast ] update-group [ neighbor ip-address | process-id.index [ summary | performance-statistics ]] Example:Displays information about BGP update groups.
|
Displaying BGP Update Groups: Example
The following is sample output from the show bgp update-group command run in EXEC configurationXR EXEC mode:
show bgp update-group
Update group for IPv4 Unicast, index 0.1:
Attributes:
Outbound Route map:rm
Minimum advertisement interval:30
Messages formatted:2, replicated:2
Neighbors in this update group:
10.0.101.92
Update group for IPv4 Unicast, index 0.2:
Attributes:
Minimum advertisement interval:30
Messages formatted:2, replicated:2
Neighbors in this update group:
10.0.101.91
L3VPN iBGP PE-CE
The L3VPN iBGP PE-CE feature helps establish an iBGP (internal Border Gateway Protocol) session between the provider edge (PE) and customer edge (CE) devices to exchange BGP routing information. A BGP session between two BGP peers is said to be an iBGP session if the BGP peers are in the same autonomous systems.
Restrictions for L3VPN iBGP PE-CE
-
When the iBGP PE CE feature is toggled and the neighbor no longer supports route-refresh or soft-reconfiguration inbound, a manual session flap must be done to see the change. When this occurs, the following message is displayed: RP/0/RP0/CPU0: %ROUTING-BGP-5-CFG_CHG_RESET: Internal VPN client configuration change on neighbor 10.10.10.1 requires HARD reset (clear bgp 10.10.10.1) to take effect.
-
iBGP PE CE CLI configuration is not available for peers under default-VRF, except for neighbor/session-group.
-
This feature does not work on regular VPN clients (eBGP VPN clients).
-
Attributes packed inside the ATTR_SET reflects changes made by the inbound route-policy on the iBGP CE and does not reflect the changes made by the export route-policy for the specified VRF.
-
Different VRFs of the same VPN (that is, in different PE routers) that are configured with iBGP PE-CE peering sessions must use different Route Distinguisher (RD) values under respective VRFs. The iBGP PE CE feature does ot work if the RD values are the same for the ingress and egress VRF.
Configuring L3VPN iBGP PE-CE
L3VPN iBGP PE-CE can be enabled on the neighbor, neighbor-group, or session-group. To configure L3VPN iBGP PE-CE, follow these steps:
Before you begin
The CE must be an internal BGP peer.
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
vrf vrf-name Example:Configures a VRF instance. |
| Step 4 |
neighbor ip-address internal-vpn-client Example:Configures a CE neighboring device with which to exchange routing information. The neighbor internal-vpn-client command stacks the iBGP-CE neighbor path in the VPN attribute set. |
| Step 5 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
| Step 6 |
show bgp vrf vrf-name neighbors ip-address Displays whether the iBGP PE-CE feature is enabled for the VRF CE peer, or not. |
| Step 7 |
show bgp { vpnv4| vpnv6 } unicast rd Displays the ATTR_SET attributes in the command output when the L3VPN iBGP PE-CE is enabled on a CE. |
Example
R1(config-bgp-vrf-nbr)#neighbor 10.10.10.1 ?
. . .
internal-vpn-client Preserve iBGP CE neighbor path in ATTR_SET across VPN core
. . .
R1(config-bgp-vrf-nbr)#neighbor 10.10.10.1 internal-vpn-client
router bgp 65001
bgp router-id 100.100.100.2
address-family ipv4 unicast
address-family vpnv4 unicast
!
vrf ce-ibgp
rd 65001:100
address-family ipv4 unicast
!
neighbor 10.10.10.1
remote-as 65001
internal-vpn-client
The following is an example of the output of the show bgp vrf vrf-name neighbors ip-address command when the L3VPN iBGP PE-CE is enabled on a CE peer:
R1#show bgp vrf ce-ibgp neighbors 10.10.10.1
BGP neighbor is 10.10.10.1, vrf ce-ibgp
Remote AS 65001, local AS 65001, internal link
Remote router ID 100.100.100.1
BGP state = Established, up for 00:00:19
. . .
Multi-protocol capability received
Neighbor capabilities:
Route refresh: advertised (old + new) and received (old + new)
4-byte AS: advertised and received
Address family IPv4 Unicast: advertised and received
CE attributes will be preserved across the core
Received 2 messages, 0 notifications, 0 in queue
Sent 2 messages, 0 notifications, 0 in queue
. . .
The following is an example of the output of the show bgp vpn4/vpn6 unicast rd command when the L3VPN iBGP PE-CE is enabled on a CE peer:
BGP routing table entry for 1.1.1.0/24, Route Distinguisher: 200:300
Versions:
Process bRIB/RIB SendTblVer
Speaker 10 10
Last Modified: Aug 28 13:11:17.000 for 00:01:00
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
Local, (Received from a RR-client)
20.20.20.2 from 20.20.20.2 (100.100.100.2)
Received Label 24000
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate,
not-in-vrf Received Path ID 0, Local Path ID 1, version 10
Extended community: RT:228:237
ATTR-SET [
Origin-AS: 200
AS-Path: 51320 52325 59744 12947 21969 50346 18204 36304 41213 23906 33646
Origin: incomplete
Metric: 204
Local-Pref: 234
Aggregator: 304 34.3.3.3
Atomic Aggregator
Community: 1:60042 2:41661 3:47008 4:9280 5:39778 6:1069 7:15918 8:8994 9:52701
10:10268 11:26276 12:8506 13:7131 14:65464 15:14304 16:33615 17:54991 18:40149 19:19401
Extended community: RT:100:1 RT:1.1.1.1:1]
Flow-tag propagation
The flow-tag propagation feature enables you to establish a co-relation between route-policies and user-policies. Flow-tag propagation using BGP allows user-side traffic-steering based on routing attributes such as, AS number, prefix lists, community strings and extended communities. Flow-tag is a logical numeric identifier that is distributed through RIB as one of the routing attribute of FIB entry in the FIB lookup table. A flow-tag is instantiated using the 'set' operation from RPL and is referenced in the C3PL PBR policy, where it is associated with actions (policy-rules) against the flow-tag value.
You can use flow-tag propagation to:
-
Classify traffic based on destination IP addresses (using the Community number) or based on prefixes (using Community number or AS number).
-
Select a TE-group that matches the cost of the path to reach a service-edge based on customer site service level agreements (SLA).
-
Apply traffic policy (TE-group selection) for specific customers based on SLA with its clients.
-
Divert traffic to application or cache server.
Restrictions for Flow-Tag Propagation
Some restrictions are placed with regard to using Quality-of-service Policy Propagation Using Border Gateway Protocol (QPPB) and flow-tag feature together. These include:
- A route-policy can have either 'set qos-group' or 'set flow-tag,' but not both for a prefix-set.
- Route policy for qos-group and route policy flow-tag cannot have overlapping routes. The QPPB and flow tag features can coexist (on same as well as on different interfaces) as long as the route policy used by them do not have any overlapping route.
- Mixing usage of qos-group and flow-tag in route-policy and policy-map is not recommended.
Source and destination-based flow tag
The source-based flow tag feature allows you to match packets based on the flow-tag assigned to the source address of the incoming packets. Once matched, you can then apply any supported PBR action on this policy.
Configure Source and Destination-based Flow Tag
This task applies flow-tag to a specified interface. The packets are matched based on the flow-tag assigned to the source address of the incoming packets.
Note |
You will not be able to enable both QPPB and flow tag feature simultaneously on an interface. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
interface type interface-path-id Example:Enters interface configuration mode and associates one or more interfaces to the VRF. |
| Step 3 |
ipv4 | ipv6 bgp policy propagation input flow-tag{destination | source} Example:Enables flow-tag policy propagation on source or destination IP address on an interface. |
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes, and remains within the configuration session.
|
Example
show running-config interface gigabitEthernet 0/0/0/12
Thu Feb 12 01:51:37.820 UTC
interface GigabitEthernet0/0/0/12
service-policy type pbr input flowMatchPolicy
ipv4 bgp policy propagation input flow-tag source
ipv4 address 192.5.1.2 255.255.255.0
!
RP/0/RSP0/CPU0:ASR9K-0#show running-config policy-map type pbr flowMatchPolicy
Thu Feb 12 01:51:45.776 UTC
policy-map type pbr flowMatchPolicy
class type traffic flowMatch36
transmit
!
class type traffic flowMatch38
transmit
!
class type traffic class-default
!
end-policy-map
!
RP/0/RSP0/CPU0:ASR9K-0#show running-config class-map type traffic flowMatch36
Thu Feb 12 01:52:04.838 UTC
class-map type traffic match-any flowMatch36
match flow-tag 36
end-class-map
!
BGP Keychains
BGP keychains enable keychain authentication between two BGP peers. The BGP endpoints must both comply with draft-bonica-tcp-auth-05.txt and a keychain on one endpoint and a password on the other endpoint does not work.
BGP is able to use the keychain to implement hitless key rollover for authentication. Key rollover specification is time based, and in the event of clock skew between the peers, the rollover process is impacted. The configurable tolerance specification allows for the accept window to be extended (before and after) by that margin. This accept window facilitates a hitless key rollover for applications (for example, routing and management protocols).
The key rollover does not impact the BGP session, unless there is a keychain configuration mismatch at the endpoints resulting in no common keys for the session traffic (send or accept).
Configure Keychains for BGP
Keychains provide secure authentication by supporting different MAC authentication algorithms and provide graceful key rollover. Perform this task to configure keychains for BGP. This task is optional.
Note |
If a keychain is configured for a neighbor group or a session group, a neighbor using the group inherits the keychain. Values of commands configured specifically for a neighbor override inherited values. |
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
| Step 3 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
| Step 4 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
| Step 5 |
keychain name Example:Configures keychain-based authentication. |
| Step 6 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Master Key Tuple Configuration
This feature specifies TCP Authentication Option (TCP-AO), which replaces the TCP MD5 option. TCP-AO uses the Message Authentication Codes (MACs), which provides the following:
-
Protection against replays for long-lived TCP connections
-
More details on the security association with TCP connections than TCP MD5
-
A larger set of MACs with minimal other system and operational changes
Note |
TCPAO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. |
-
keychain configuration
-
tcp ao keychain configuration
The system translates each key, such "key_id" that is under a keychain, as MKT. The keychain configuration owns part of the configuration like secret, lifetimes, and algorithms. While the "tcp ao keychain" mode owns the TCP AO-specific configuration for an MKT (send_id and receive_id).
Keychain Configurations
Configuration Guidelines
In order to run a successful configuration, ensure that you follow the configuration guidelines:
-
An allowed value range for both Send_ID and Receive_ID is 0 to 255.
-
You can link only one keychain to an application neighbor.
-
Under the same keychain, if you configure the same send_id key again under the keys that have an overlapping lifetime, then the old key becomes unusable until you correct the configuration.
-
The system sends a warning message in the following scenarios: - If there is a change in Send_ID or Receive_ID.
-
If the corresponding key is currently active, and is in use by some connection.
-
BGP neighbor can ONLY use one of the authentication options: -
MD5
-
EA
-
AO
Note
If you configure one of these options, the system rejects the other authentication options during the configuration time.
-
Configuration Guidelines for TCP AO BGP Neighbor
The configuration guidelines are:
-
Configure all the necessary configurations (key_string, MAC_algorithm, send_lifetime, accept_lifetime, send_id, receive_id) under key_id with the desired lifetime it wants to use the key_id for.
-
Configure a matching MKT in the peer side with exactly same lifetime.
-
Once a keychain-key is linked to tcp-ao, do not change the components of the key. If you want TCP to consider another key for use, you can configure that dynamically. Based on the ‘start-time’of send lifetime, TCP AO uses the key.
-
Send_ID and Receive_ID under a key_id (under a keychain) must have the same lifetime range. For example, send-lifetime==accept-lifetime.
TCP considers only expiry of send-lifetime to transition to next active key and it does not consider accept-lifetime at all.
-
Do not configure a key with send-lifetime that is covered by another key’s send-lifetime.
For example, if there is a key that is already configured with send-lifetime of “04:00:00 November 01, 2017 07:00:00 November 01, 2017” and the user now configures another key with send-lifetime of “05:00:00 November 01, 2017 06:00:00 November 01, 2017”, this might result into connection flap.
TCP AO tries to transition back to the old key once the new key is expired. However, if the new key has already expired, TCP AO can’t use it, which might result in segment loss and hence connection flap.
-
Configure minimum of 15 minutes of overlapping time between the two overlapping keys. When a key expires, TCP does not use it and hence out-of-order segments with that key are dropped.
-
We recommend configuring send_id and receive_id to be same for a key_id for simplicity.
-
TCP does not have any restriction on the number of keychains and keys under a keychain. The system does not support more than 4000 keychains, any number higher than 4000 might result in unexpected behaviors.
Keychain Configuration
key chain <keychain_name>
key <key_id>
accept-lifetime <start-time> <end-time>
key-string <master-key>
send-lifetime <start-time> <end-time>
cryptographic-algorithm <algorithm>
!
!
TCP Configuration
tcp ao
keychain <keychain_name1>
key-id <key_id> send_id <0-255> receive_id <0-255>
!
tcp ao
keychain bgp_ao
key 0 SendID 0 ReceiveID 0
key 1 SendID 1 ReceiveID 1
key 2 SendID 3 ReceiveID 4
!
keychain ldp_ao
key 1 SendID 100 ReceiveID 200
key 120 SendID 1 ReceiveID 1
!
BGP Configurations
Applications like BGP provide the tcp-ao keychain and related information that it uses per neighbor. Following are the optional configurations per tcp-ao keychain:
-
include-tcp-options
-
accept-non-ao-connections
router bgp <AS-number>
neighbor <neighbor-ip>
remote-as <remote-as-number>
ao <keychain-name> include-tcp-options enable/disable <accept-ao-mismatch-connections>
!
XML Configurations
BGP XML
TCP-AO XML
<?xml version="1.0" encoding="UTF-8"?>
<Request>
<Set>
<Configuration>
<IP_TCP>
<AO>
<Enable>
true
</Enable>
<KeychainTable>
<Keychain>
<Naming>
<Name> bgp_ao_xml </Name>
</Naming>
<Enable>
true
</Enable>
<KeyTable>
<Key>
<Naming>
<KeyID> 0 </KeyID>
</Naming>
<SendID> 0 </SendID>
<ReceiveID> 0 </ReceiveID>
</Key>
</KeyTable>
</Keychain>
</KeychainTable>
</AO>
</IP_TCP>
</Configuration>
</Set>
<Commit/>
</Request>BGP Nonstop Routing
The Border Gateway Protocol (BGP) Nonstop Routing (NSR) with Stateful Switchover (SSO) feature enables all bgp peerings to maintain the BGP state and ensure continuous packet forwarding during events that could interrupt service. Under NSR, events that might potentially interrupt service are not visible to peer routers. Protocol sessions are not interrupted and routing states are maintained across process restarts and switchovers.
BGP Nonstop Routing Reference for additional details.
Configure BGP Nonstop Routing
Note |
In some scenarios, it is possible that some or all bgp sessions are not NSR-READY. The |
Disable BGP Nonstop Routing
Perform this task to disable BGP Nonstop Routing (NSR):
Procedure
| Step 1 |
configure Example:Enters mode. |
| Step 2 |
router bgp as-number Example:Specifies the BGP AS number, and enters the BGP configuration mode, for configuring BGP routing processes. |
| Step 3 |
nsr disable Example:Disables BGP Nonstop routing. |
| Step 4 |
Use the commit or end command. commit —Saves the configuration changes and remains within the configuration session.
|
Disable BGP Nonstop Routing: Example
The fo