I'm trying to figure out some details regarding BGP GR functionality.
The basic concept is pretty simple, but I cannot find answer to my question:
How BGP peers knows when SSO-performing router switches to standby supervisor?
BGP peers should somehow distinguish real supervisor fail from some other fails.
I think it's very important, because if not so - when 'other fail' occurs BGP peer will keep routes during `Restart Timer` that equal to 120 sec by default. It may cause a blackhole.
Also such a big pause (dead timer + restart timer) is not acceptable for HA infrastructure.
Does really BGP Peers each time when BGP TCP session timed out (no matter why) keeps routes during `Restart Timer`? Or how Restarter notify its peers?
On the other hand - when I simulate termination of the BGP session (add route to the neighbor to Null0 at the Restarter), peer just wait for the holdtime and does not mark routes as stale after. In other words it does not start NSF process. What should happen to start that process in the context of neighbors?
If the BGP session is lost during the RP switchover, the NSF-aware BGP peer marks all the routes associated with the NSF-capable router as stale; however, it continues to use these routes to make forwarding decisions for a set period of time. This functionality means that no packets are lost while the newly active RP is waiting for convergence of the routing information with the BGP peers.
After an RP switchover occurs, the NSF-capable router reestablishes the session with the BGP peer. In establishing the new session, it sends a new graceful restart message that identifies the NSF-capable router as having restarted.
Inviting all network professionals in operations! We'd like to understand what would be valuable for you in a mobile application. Your response will help Cisco improve a product feature that could benefit you. Thanks!
Click here to take the sur...
Cisco’s software-defined wide area network (SD-WAN) solution allows user to quickly and seamlessly establish an overlay fabric to connect an enterprise’s data centers, branch and campus locations, as well as colocation facilities in order to imp...
1. Log into CLI of DNAC:
ssh maglev@< DNAC appliance IP> -p 2222
2. Run this curl command to get token to get member id:
curl -X POST -u admin:<admin user password> -H -V https://<CLUSTER-IP>/api/system/v1/identitymgmt/token
Enterprise Switching Business Unit is glad to announce Beta release 16.12.2 for all Catalyst 9200/9300/9400/9500/9600 and Catalyst 3650/3850 Platforms. This release is made available to allow users to test, evaluate and share fee...
Purpose of the document
This document describes the general recommendations or best practices when designing and deploying the Cisco SD-Access technology. The document assumes that the reader has a general overview of Cisco's SD-Access for Distributed C...