BGP Peering Status Persistence for Hitless Reboot Convergence
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current BGP speaker reboot processes face convergence delays due to inaccurate peer configurations and the inability to reconnect with dynamic peers, leading to network instability, especially in layered deployments.
Innovation Solution
Implementing a BGP speaker with modified shutdown and bootup processing logic that collects and stores peer status information during shutdown, allowing direct TCP connection attempts to dynamic peers and immediate best path computation upon established peer connections, bypassing idle peer timeouts.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If the BGP speaker uses the peer configuration present on the restarting BGP speaker for convergence, then the reconciliation process can be driven by existing configuration data, but the peer configuration may not accurately reflect the active peerings at reboot time leading to convergence delays
Solution Approach 1:
The patent applies preliminary action by collecting and storing peer status information (established or idle) before the reboot occurs. This pre-collected status data is then used during the reboot process to accurately identify which peers need to be reconnected, eliminating the need to rely on potentially outdated peer configuration data and significantly reducing convergence time.
2Reliability
If the BGP speaker waits for idle peer timeouts to expire before proceeding with best path computation, then all idle peers are accounted for, but convergence is delayed
Solution Approach 1:
The patent stores the peering status (including whether a peer is idle or established) before reboot. During reboot, this pre-stored status information allows the BGP speaker to immediately identify which peers are established and can proceed with best path computation without waiting for idle peer timeouts to expire, thus maintaining reliability while reducing convergence time.
Solution Approach 2:
The patent uses feedback from the stored peering status information to guide the reboot process. By knowing the actual status of each peer (established or idle) from before the reboot, the system can feedback-driven decisions about which peers to attempt reconnect to and when to proceed with routing computations, eliminating unnecessary delays.
3Adaptability or versatility
If the BGP speaker attempts to reconnect to all configured peers, then all possible peers are contacted, but dynamic peers cannot be reconnected leading to incomplete convergence
Solution Approach 1:
The patent collects and stores peer status information before reboot, distinguishing between established and idle peers. This pre-stored status data enables the BGP speaker to adaptively determine which peers should be attempted for reconnection during bootup, ensuring that dynamic peers (which were established before reboot) are successfully reconnected, thereby improving both adaptability and connection reliability.
Data Source
AI summary
Techniques for implementing Border Gateway Protocol (BGP) peering status-aware hitless reboot on a network device are provided. In one set of embodiments, at the time of shutting down for a hitless reboot, the network device can collect status information regarding its BGP peerings and can write this information to a file on non-volatile storage. Then, upon booting up after the hitless reboot, the network device can retrieve the file from the non-volatile storage and use the status information included therein to restore the BGP peerings as they existed prior to the hitless reboot.