BGP Nonstop Routing (NSR)

High-availability features like GR are really useful in critical network environments, where traffic loss even for few seconds can cost a lot to the organization, whether it is a service provider network or an enterprise. But GR is not really a feasible solution in all deployments. Think about a service provider network. It is easy to deploy a GR feature everywhere in the service provider core and edge, but the service provider cannot expect to have the customers enable GR or be GR capable. There might be customer environments where the CPE might be running a platform or software that does not support GR or might be running the CPE with just a single RP. In such situations, GR is not feasible for the customers.

An RP switchover should be transparent to the customer, and this was the primary motivation behind NSR. NSR is a feature where routing protocols explicitly checkpoint state from active RP to the standby RP to maintain routing information across a switchover. Thus, NSR sessions are in established state on the standby RP prior to switchover and remain established even after the switchover. The main benefit of using NSR is it is transparent to the remote speaker; that is, the remote does not need to be NSR capable for the feature to work.

There are three phases in NSR operation. Each phase performs certain actions, and based on these phases, it becomes easier to identify any problem with BGP NSR.

  1. Synchronization: During this state, the task of session state mirroring happens between the active and the standby RP. The TCP stack is first synchronized, followed by the application stacks—in this case, BGP.
  2. NSR-ready: The active and standby stacks operate independently, but the incoming packets or updates are replicated to both the RPs. The outgoing segments or updates are sent out via the standby RP or active RP depending on the underlying platform. On IOS/IOS XE, the active RP sends the update to the peers, but on IOS XR, the update is sent out via the standby RP. Note that the system uses asynchronous inter-process communication (IPC) between the active and standby RPs to replicate the information. In this state, the active RP sends prefix/best-path information to the standby.
  3. Switchover: When the switchover occurs, TCP activates the sockets based on the application trigger and restores keepalive functionality to maintain the session states. In other words, the new active RP (previously acting standby RP) continues from where the active RP left.

The BGP NSR feature is supported on IOS/IOS XE and IOS XR platforms.

  • To enable BGP NSR on Cisco IOS, use the command neighbor ip-address ha-mode sso.
  • On IOS XR, NSR is not supported on a per-neighbor basis and can only be enabled globally for all address families using the command nsr under the router bgp configuration mode.
  • NSR is enabled globally on Cisco IOS by using the command bgp sso route-refresh-enable. This command only allows BGP NSR to be enabled to peers that are Route Refresh capable.
  • The BGP NSR related information is found for each peer by using the command show bgp afi safi neighbor ip-address.
  • On IOS XR, another command to verify if NSR is enabled for the BGP process is the command show bgp process.
router bgp 100
 bgp sso route-refresh-enable
 neighbor ha-mode sso

router bgp 100

In IOS XR, there are instances when a process crashes because of various reasons. So, if a TCP or BGP process starts on the active RP, the system can force the active RP to failover to standby RP as a recovery action in such situations. But this is not done automatically. To enable this behavior, configure the command nsr process-failures switchover. Note that if a process restarts on the standby RP, only the NSR functionality is lost until the time the process comes up again, but there is not any other service impact.

From the command-line perspective, there isn’t much information that can be viewed on the Cisco IOS or IOS XE platforms, but on IOS XR, a lot of information is available for BGP NSR. The BGP NSR goes through various states.

The following describes the different states of the BGP NSR finite state machine:

  • None: NSR is disabled (not configured).
  • Initializing: Basic initialization in progress. This is done after the first time NSR is configured.
  • Connecting: Attempting to connect to peer (ACTV/STDBY) process.
  • TCP Init-Sync: Synchronization of TCP sessions in progress.
  • BGP Init-Sync: Synchronization of BGP database in progress.
  • NSR-Ready: Ready to perform NSR-enabled switchover.

Note that in previous example output, the NSR state is None. This is because there is not a standby RP present in the system. In an ideal situation with dual RPs, the NSR state should be NSR-Ready.

  • To view the NSR state on a dual RP system, use the command show redundancy. This command displays the active and the standby RP redundancy states.
  • Use the command show bgp afi safi [prefix | summary] [standby] to view the BGP session state and the BGP table for an AFI/SAFI on the standby RP.

Note: If a manual switchover is required for maintenance purposes, ensure that the redundancy state is Standby hot and also the standby is in NSR-Ready state. This ensures seamless activity without any service impact.

After a switchover, the standby RP goes through all the NSR states.

  • To display all the various modes that the standby goes through after it moves to a standby ready state along with the timeline. It also shows the state of the BGP neighbor along with the NSR state.
    • show bgp summary nsr
    • show bgp nsr
  • To view the NSR states and the neighbor state on the standby RP:
    • show bgp summary nsr standby
  • A cumulative view of all the session states, that is, Neighbor State and NSR State, is viewed by using the command:
    • show bgp sessions.
  • If there are sessions that are not NSR ready, such sessions are viewed by using the command:
    • show bgp sessions [not-nsr-ready].
  • Because the TCP state is required to be synchronized between the active RP and the standby RP, it is vital to verify how many sessions an application (in this case BGP) ask TCP to synchronize and how many have actually synchronized. To verify this information, use the command:
    • show tcp nsr session-set brief
Tags: ,

Leave a Reply

Related Post