[Magic] Updates to BGP peering docs (#19101)

marciocloudflare · web-flow · commit 97ad5a6fb385 · 2025-01-09T15:05:09.000Z
* added timers

* added mt limitations

* refined code

* updated step 8

* refined text

* corrected text
diff --git a/src/content/docs/magic-transit/how-to/bgp-peering.mdx b/src/content/docs/magic-transit/how-to/bgp-peering.mdx
@@ -14,6 +14,8 @@ import { Render } from "~/components"
 		productName: "Magic Transit",
 		productPath: "/magic-transit/reference/tunnel-health-checks/",
 		legacyHCs: "/magic-transit/reference/tunnel-health-checks/#legacy-health-checks-system",
-		asnProduct: "<br /> Magic Transit customers should also be aware of the following: <br /> <ul><li>The Cloudflare side ASN will never be exposed in <code>AS_PATH</code> of anycast announcements from the Cloudflare edge. In those announcements, Cloudflare will always use the Cloudflare ASN of <code>13335</code> optionally prepended with a bring-your-own ASN as described in [Cloudflare ASN vs. your own ASN](/magic-transit/how-to/advertise-prefixes/#cloudflare-asn-vs-your-own-asn)</li><li>The customer device ASN can be a private ASN or the ASN they are using for Magic Transit anycast announcements at the edge: this has no impact on the ASN for the anycast announced prefix at the edge of the Cloudflare global network.</li></ul>"
+		asnProduct: "<br /> Magic Transit customers should also be aware of the following: <br /> <ul><li>The Cloudflare side ASN will never be exposed in <code>AS_PATH</code> of anycast announcements from the Cloudflare edge. In those announcements, Cloudflare will always use the Cloudflare ASN of <code>13335</code> optionally prepended with a bring-your-own ASN as described in [Cloudflare ASN vs. your own ASN](/magic-transit/how-to/advertise-prefixes/#cloudflare-asn-vs-your-own-asn)</li><li>The customer device ASN can be a private ASN or the ASN they are using for Magic Transit anycast announcements at the edge: this has no impact on the ASN for the anycast announced prefix at the edge of the Cloudflare global network.</li></ul>",
+		mtLimitations: "<br /> For Magic Transit customers, BGP with the Magic routing table is separated from the announcement of anycast prefixes at the Cloudflare edge. Anycast withdrawal must be controlled with existing methods documented in [Advertise prefixes](/magic-transit/how-to/advertise-prefixes/).",
+		productGatewayOrEgress: "Magic Transit with Egress"
 	}}
 />
diff --git a/src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx b/src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx
@@ -14,6 +14,8 @@ import { Render } from "~/components"
 		productName: "Magic WAN",
 		productPath: "/magic-wan/reference/tunnel-health-checks/",
 		legacyHCs: "/magic-wan/reference/tunnel-health-checks/#legacy-health-checks-system",
-		asnProduct: "<br /> Magic WAN customers should also be aware of the following: <br /> <ul><li>The Cloudflare side ASN will be included in the <code>AS_PATH</code> of announced routes to any BGP enabled interconnect.</li><li>The customer chooses their device ASN, which should be different to the Cloudflare-side ASN.</li></ul>"
+		asnProduct: "<br /> Magic WAN customers should also be aware of the following: <br /> <ul><li>The Cloudflare side ASN will be included in the <code>AS_PATH</code> of announced routes to any BGP enabled interconnect.</li><li>The customer chooses their device ASN, which should be different to the Cloudflare-side ASN.</li></ul>",
+		mtLimitations: " ",
+		productGatewayOrEgress: "Magic WAN with Gateway"
 	}}
 />
diff --git a/src/content/partials/network-interconnect/bgp-peering.mdx b/src/content/partials/network-interconnect/bgp-peering.mdx
@@ -4,6 +4,8 @@ params:
   - productPath
   - legacyHCs
   - asnProduct
+  - mtLimitations
+  - productGatewayOrEgress
 ---
 
 import { Markdown } from "~/components";
@@ -27,6 +29,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 timers as described below. 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.
@@ -37,6 +54,8 @@ BGP support currently has the following limitations:
 - Bidirectional Forwarding Detection (BFD) is not supported.
 - 4-byte ASNs are not supported.
 
+<Markdown text={props.mtLimitations} />
+
 ## Tunnel health checks
 
 {props.productName} customers need to enable legacy <a href={props.legacyHCs}>health checks</a> alongside BGP. This is essential to determine if a specific Cloudflare data center is reachable from a customer device or not. <a href={props.productPath}>Tunnel health checks</a> will modify the route's priorities for dynamically learned BGP routes.
@@ -73,5 +92,7 @@ If you already have set up your Cloudflare account ASN, you can skip steps two a
 5. Find the Direct CNI interconnect you want to configure with BGP > select the **three dots** next to it > **Configure BGP**.
 6. In **Customer device ASN**, enter the ASN for your network.
 7. In **MD5 key**, you can optionally enter the key for your network. Note that this is meant to prevent accidental misconfigurations, and is not a security mechanism.
-8. (Optional) In **Advertised prefix list**, input the additional static prefixes automatically assigned by Cloudflare during the creation of the CNI interconnect, to advertise alongside your existing routes. Leave blank if you do not want to advertise extra routes.
-9. Select **Enable BGP**.
+8. (Optional) In **Advertised prefix list**, input the additional prefixes automatically assigned by Cloudflare during the creation of the CNI interconnect, to advertise alongside your existing routes. Leave blank if you do not want to advertise extra routes. <br /> Typical prefixes to configure here include:
+	- A route to `0.0.0.0/0`, the default route — to attract all Internet-bound traffic if using {props.productGatewayOrEgress}.
+	- A route to `100.96.0.0/12`, the portion of CGNAT space [used by default with WARP clients](/cloudflare-one/connections/connect-networks/private-net/warp-connector/user-to-site/#add-route-to-router).
+9. Select **Enable BGP**.
