added timers

Author: marciocloudflare

src/content/partials/network-interconnect/bgp-peering.mdx

@@ -27,6 +27,21 @@ All routes in the Magic routing table are advertised to BGP peers. Each BGP peer
 
 BGP peering sessions can advertise reachable prefixes to a peer and withdraw previously advertised prefixes. This should not take more than a few minutes to propagate.
 
+## BGP timers and settings
+
+Cloudflare uses the following BGP timers. These are not configurable:
+
+| Setting 				 | Description |
+| --- 						 | --- |
+| Hold timer 			 | 240 seconds <br /> (_To establish a session, Cloudflare will compare our hold timer and the peer's hold timer, and use the smaller of the two values to establish the BGP session._) |
+| Keepalive timer  | One third of the hold time. |
+| Graceful restart | 120 seconds |
+
+- **Hold timer**: Specifies the maximum amount of time that a BGP peer will wait to receive a keepalive, update, or notification message before declaring the BGP session down. Cloudflare will use the smaller of this default hold time and that received from the peer in the open message.
+- **Keepalive timer**: BGP systems exchange keepalive messages to determine whether the peer router is reachable. If keepalive messages are not received within the Hold Timer, the session is assumed to be down, indicating that the peer is no longer reachable at the BGP protocol level.
+- **Graceful restart timer**: Tracks how long a router will wait for a peer to re-establish a BGP session after the peer initiates a graceful restart. If the peer does not reconnect within this time, the router declares the session down and removes stale routes.
+
+
 ## Limitations
 
 BGP multipath is supported. If the same prefix is learned on two different interconnects then traffic destined for that prefix will be distributed across each interconnect according to the usual ECMP behavior.