BGP is a heavy protocol and can consume a lot of CPU cycles. Use the following features to improve the CPU resources:
- Peer Groups, Dynamic Update Peer Groups and Templates
- BGP Soft Reset
Peer-Groups, Dynamic Peer-Groups and Templates
As a router gains more and more BGP neighbors, two issues arise:
- The first one is that with many neighbors, whenever the router needs to send out a BGP update, it has to create an UPDATE message for each neighbor.
- Second one, the BGP configuration can get quite long and unwieldy.
BGP peer groups were the original solution to both problems. Later, the same two problems were tackled slightly differently with dynamic update peer groups and BGP templates.
Peer-groups are templates that can be used to assign common policies and attributes, such as an AS number or source-interface, and the like for multiple neighbors. This saves a lot of time and effort while configuring, when multiple neighbors have the same policy. But the peer-groups were not designed to save typing. By grouping neighbors with common policy together, routers save a lot of CPU resources by creating a one-time route object and then advertising that object to multiple peers.
router bgp 65530 neighbor iBGP-RRC peer-group neighbor iBGP-RRC remote-as 65530 neighbor iBGP-RRC update-source loopback0 neighbor 192.168.2.2 peer-group iBGP-RRC neighbor 192.168.3.3 peer-group iBGP-RRC ! address-family ipv4 unicast neighbor iBGP-RRC route-reflector-client neighbor 192.168.2.2 activate neighbor 192.168.3.3 activate
Dynamic Update Peer Groups
- The BGP Dynamic Update Peer-Groups feature introduces a new algorithm that dynamically calculates and optimizes update-groups of neighbors that share the same outbound policies and can share the same update messages.
- In previous versions of Cisco IOS software, BGP UPDATE messages were grouped together based on peer-group configurations.
- This feature was introduced on 12.0(24)S.
It’s no longer necessary to explicitly create peer-groups for performance reasons. Instead, Cisco routers automatically create dynamic update peer-groups that allow the router to send the same UPDATE message to multiple neighbors if the outgoing policies for multiple neighbors are the same.
- A BGP neighbor can belong to only one peer-group.
- Neighbors belonging to different address-families cannot be part of same peer-group.
- Only one outbound policy can be configured per peer-group.
Peer templates were introduced to overcome the limitations of peer-group configuration. Similar to NX-OS, the peer template configuration is inheritable and can form multiple hierarchies. There are two types of peer templates: peer-session and peer-policy.
The peer-session template allows configuring session-related parameters, whereas the peer-policy template allows for address-family – dependent configuration. Both the peer-session and peer-policy templates give more flexibility on configuring neighbors and provide faster convergence.
router bgp 65200 template peer-session BGP-All timers 30 300 exit-peer-session ! template peer-session IBGP remote-as 65200 inherit peer-session BGP-All exit-peer-session ! template peer-session EBGP ttl-security hops 1 inherit peer-session BGP-All exit-peer-session ! template peer-policy BGP-All prefix-list DENY-MARTIANS in exit-peer-policy ! neighbor 10.0.1.1 remote-as 65101 neighbor 10.0.1.1 inherit peer-session EBGP neighbor 10.0.1.1 inherit peer-policy BGP-All neighbor 10.0.1.2 remote-as 65102 neighbor 10.0.1.2 inherit peer-session EBGP neighbor 10.0.2.4 inherit peer-session IBGP neighbor 10.0.2.5 inherit peer-session IBGP
Soft Reconfiguration vs Route Refresh
Long time ago there was no method to dynamically request a re-advertisement of the prefixes of one of your BGP neighbors. When you change your policy, somehow you have to compare all the prefixes from your BGP neighbor against your new policy.
BGP peers are requested for resending updates to peers when making adjustments to inbound BGP policies. BGP updates are incremental; that is, after the initial update is completed, only the changes are received. So BGP sessions are required to be reset, to request peers to send a BGP update message with all the NLRIs, so those updates can be rerun via the new filter. There are two methods to perform the session reset:
- Hard Reset: Dropping and reestablishing a BGP session. clear bgp afi safi ip-address
- Soft Reset: A soft reset uses the unaltered prefixes, stored in the Adj-RIB-In table, to reconfigure and activate BGP routing tables without tearing down the BGP session. clear bgp ipv4 unicast ip-address soft [in|out]
A Hard Reset of a BGP session is disruptive to an operational network.
Soft Reset refers to the use of either Soft Reconfiguration or Route Refresh – in any case, the ability to reapply an inbound policy without tearing down the BGP peering itself. However, Cisco likes to use the term soft reset for Soft Reconfiguration (the separate unmodified database per neighbor), and dynamic inbound soft reset for Route Refresh.
BGP stores an unmodified copy of all routes received from its peer in a separate place in memory and will re-use it whenever the Inbound Policy changes.
Keep a separate, unfiltered and unmodified copy of all routes received from a neighbor, and whenever an inbound policy for that neighbor is changed, take this unfiltered database and ‘distill’ it through the updated inbound policy. This has the same effect as having the neighbor resend all routes again, yet it is accomplished purely by local means, storing the unmodified copy of all received routes in a separate place in memory and just reuse it whenever the inbound policy changes.
BGP soft reconfiguration is enabled by using the neighbor ip-address soft-reconfiguration inbound configuration. When enabled, this causes an extra overhead on memory and CPU on the router because BGP keeps an unmodified copy of all routes received from the peer, plus the BGP RIB.
Whenever it needs to reapply a new inbound policy, it simply sends the peer a Route Refresh message, and the peer will automatically resend all routes of a particular address-family.
To overcome the challenges of soft-reconfiguration inbound configuration, BGP route refresh capability was introduced and is defined in RFC 2918. The BGP route refresh capability has a capability code of 2 and the length of 0. Using the route refresh capability, the router sends out a route refresh request to a peer to get the full table from the peer again. The advantage of route refresh capability is that no preconfiguration is needed to enable it.
The BGP Route-Refresh Message
- The AFI and SAFI in the ROUTE-REFRESH message point to the address-family where the configured peer is negotiating the route refresh capability. The Reserved bits are unused and are set to 0 by the sender and ignored by the receiver.
- A BGP speaker can send a ROUTE-REFRESH message only if it has received a route refresh capability from its peer. This implies that all the participating routes should support the route refresh capability.
- The router sends a route refresh request (REFRESH_REQ) to the peer. After the speaker receives a route refresh request, the BGP speaker readvertises to the peer the Adj-RIB-Out of the AFI, and SAFI carried in the message, to its peer.
- The requesting peer receives the prefixes after any outbound policy applied on the peer is executed.
The clear ip bgp ip-address in or clear bgp afi safi ip-address in command tells the peer to resend a full BGP announcement by sending a route refresh request, whereas the clear bgp afi safi ip-address out command resends a full BGP announcement to the peer, and it does not initiate a route refresh request. The route refresh capability is verified by using the show bgp afi safi neighbor ip-address command.
Note: When the soft-reconfiguration feature is configured, the BGP route refresh capability is not used, even though the capability is negotiated. The soft-reconfiguration configuration controls the processing or initiating route refresh.
To view the message exchange:
- Enable debug command debug bgp ipv4 unicast in and debug bgp ipv4 unicast update.
- After the debug is enabled, issue the command clear bgp ipv4 unicast ip-address in, which triggers the router to initiate a refresh request.
- The message type 5 represents the ROUTE-REFRESH message.
The BGP refresh request (REFRESH_REQ) is sent in one of the following cases:
- clear bgp afi safi [* | ip-address] in command is issued.
- clear bgp afi safi [* | ip-address] soft in command is issued.
- Adding or changing inbound filtering on the BGP neighbor via route-map.
- Configuring allowas-in for the BGP neighbor.
- Configuring soft-reconfiguration inbound for the BGP neighbor.
Note: It is recommended to use soft-reconfiguration inbound only on EBGP peering whenever it is required to know what the EBGP peer previously advertised that has been filtered out. It is not recommended to configure soft-reconfiguration inbound command when there are large numbers of prefixes being learned, such as the Internet routing table over the EBGP connection.