added mt limitations

Author: marciocloudflare

src/content/docs/magic-transit/how-to/bgp-peering.mdx

@@ -14,6 +14,7 @@ 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: "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](https://developers.cloudflare.com/magic-transit/how-to/advertise-prefixes/)"
 	}}
 />

src/content/docs/magic-wan/configuration/manually/how-to/bgp-peering.mdx

@@ -15,5 +15,6 @@ import { Render } from "~/components"
 		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>"
+		mtLimitations: " "
 	}}
 />

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

@@ -4,6 +4,7 @@ params:
   - productPath
   - legacyHCs
   - asnProduct
+	- mtLimitations
 ---
 
 import { Markdown } from "~/components";
@@ -52,6 +53,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.