[MT/MWAN/CNI] BGP patch (#18828)

marciocloudflare · Oxyjun · web-flow · commit fb26f52bb52d · 2024-12-18T10:52:53.000Z
* moved product specific info

* corrected step

* changed product names to props

* corrected text and steps

* corrected sentences

* refined text

* added bgp info to cni

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

Co-authored-by: Jun Lee &lt;junlee@cloudflare.com&gt;

---------

Co-authored-by: Jun Lee &lt;junlee@cloudflare.com&gt;
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,5 +14,6 @@ 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>"
 	}}
 />
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,5 +14,6 @@ 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>"
 	}}
 />
diff --git a/src/content/docs/network-interconnect/express-cni/bgp-peering.mdx b/src/content/docs/network-interconnect/express-cni/bgp-peering.mdx
@@ -0,0 +1,19 @@
+---
+pcx_content_type: concept
+sidebar:
+  order: 3
+title: BGP peering
+---
+
+Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using a Direct CNI on-ramp.
+
+Using BGP peering with a CNI allows customers to:
+- Automate the process of adding or removing networks and subnets.
+- Take advantage of failure detection and session recovery features.
+
+With this functionality, customers can:
+- Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via CNI.
+- Secure the session by MD5 authentication to prevent misconfigurations.
+- Exchange routes dynamically between their devices and their Magic routing table.
+
+Refer to [Magic WAN BGP peering](/magic-wan/configuration/manually/how-to/bgp-peering/) or [Magic Transit BGP peering](/magic-transit/how-to/bgp-peering/) to learn more about this feature and how to set it up.
diff --git a/src/content/docs/network-interconnect/express-cni/create-interconnects.mdx b/src/content/docs/network-interconnect/express-cni/create-interconnects.mdx
@@ -1,6 +1,8 @@
 ---
 title: Create interconnects
 pcx_content_type: how-to
+sidebar:
+  order: 2
 ---
 
 To create a new interconnect, make sure you are logged in with Admin or higher-level account permissions. This is required for the wizard to successfully request and provision a new Direct CNI connection.
diff --git a/src/content/partials/network-interconnect/bgp-peering.mdx b/src/content/partials/network-interconnect/bgp-peering.mdx
@@ -3,6 +3,7 @@ params:
   - productName
   - productPath
   - legacyHCs
+  - asnProduct
 ---
 
 import { Markdown } from "~/components";
@@ -14,15 +15,15 @@ Using BGP peering with a CNI allows customers to:
 - Take advantage of failure detection and session recovery features.
 
 With this functionality, customers can:
-- Establish an eBGP session between their devices and the {props.productName} service when connected via CNI
+- Establish an eBGP session between their devices and the {props.productName} service when connected via CNI.
 - Secure the session by MD5 authentication to prevent misconfigurations.
 - Exchange routes dynamically between their devices and their Magic routing table.
 
 ## Route distribution and convergence
 
 Routes received from the customer device will be redistributed into the Magic routing table, which is used by both Magic WAN and Magic Transit.
 
-All routes in the Magic routing table are advertised to BGP peers. Each BGP peer will receive each prefix route along with the full `AS_PATH`, with the selected Cloudflare side ASN prepended. This is so that the peer can accurately perform [loop prevention](https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2).
+All routes in the Magic routing table are advertised to BGP peers. Each BGP peer will receive each prefix route along with the full `AS_PATH`, with the selected Cloudflare side [ASN](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/) prepended. This is so that the peer can accurately perform [loop prevention](https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2).
 
 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.
 
@@ -32,35 +33,26 @@ BGP multipath is supported. If the same prefix is learned on two different inter
 
 BGP support currently has the following limitations:
 - The Cloudflare account ASN and the customer device ASN must be different. Only eBGP is supported.
-- Routes are always injected with a priority of 100.
+- Routes are always injected with a priority of `100`.
 - Bidirectional Forwarding Detection (BFD) is not supported.
 - 4-byte ASNs are not supported.
 
 ## Tunnel health checks
 
-You need to enable <a href={props.productPath}>tunnel health checks</a> alongside BGP. This is essential to determine if a specific Cloudflare datacenter is reachable from a customer router or not. Tunnel health checks will modify the route's priorities for dynamically learned BGP routes.
-
-{props.productName} customers should configure legacy <a href={props.legacyHCs}>bidirectional health checks</a>.
+{props.productName} customers need to enable legacy <a href={props.legacyHCs}>bidirectional health checks</a> alongside BGP. This is essential to determine if a specific Cloudflare datacenter 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.
 
 ## How to choose an ASN for BGP peering
 
-The Magic routing table is under the control of the customer, and the customer is able to choose both the Cloudflare side ASN and their customer device side ASN.
+The Magic routing table is managed by the customer, who can select both the Cloudflare-side ASN and the ASN for their customer device.
 
-By default each BGP peering session will use the same Cloudflare side ASN to represent peering with the Magic WAN/Transit routing table. This default ASN is called the **CF Account ASN** and should be configured to a private 2-byte ASN (64512 and 65534). To set this ASN:
+By default, each BGP peering session will use the same Cloudflare-side ASN to represent peering with the {props.productName} routing table. This default ASN is called the **CF Account ASN** and should be configured to a private 2-byte ASN (`64512` and `65534`). To set this ASN:
 
 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/), and select your account.
-2. Go to **Magic WAN / Transit** > **Configuration** > **BGP**.
-3. In CF Account ASN, enter Cloudflare's ASN.
-
-### For Magic WAN customers
-
-- The Cloudflare side ASN will be included in the `AS PATH` of announced routes to any BGP enabled interconnect.
-- The customer device ASN can be chosen by the customer, and should be different to the Cloudflare side ASN.
-
-### For Magic Transit customers
+2. Go to **{props.productName}** > **Configuration** > **BGP**.
+3. In **CF Account ASN**, enter Cloudflare's ASN.
+4. Select **Update**.
 
-- The Cloudflare side ASN will never be exposed in `AS PATH` of anycast announcements from the Cloudflare edge. In those announcements, Cloudflare will always use the Cloudflare ASN of `13335` 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)
-- 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.
+<Markdown text={props.asnProduct} />
 
 ## How to set up BGP peering
 
@@ -69,8 +61,8 @@ BGP peering is only available to {props.productName} customers with Direct CNI a
 :::
 
 You need to configure two ASNs:
-- The Cloudflare [account-scoped ASN](#how-to-choose-an-asn-for-bgp-peering).
-- One ASN for each Interconnect you want to configure with BGP.
+- The Cloudflare [account-scoped ASN](#how-to-choose-an-asn-for-bgp-peering) named **CF Account ASN**.
+- One ASN for each interconnect you want to configure with BGP.
 
 If you already have set up your Cloudflare account ASN, you can skip steps two and three below.
 
