added new content

Author: marciocloudflare

src/content/docs/magic-transit/how-to/advertise-prefixes.mdx

@@ -53,6 +53,7 @@ Cloudflare offers multiple mechanisms for customers to control the announcement
 - The [Addressing API](/api/resources/addressing/subresources/prefixes/subresources/bgp_prefixes/methods/edit/).
 - BGP peering with Cloudflare's route reflectors: Either over the Internet or over a Classic CNI connection. Contact your Cloudflare account team if you need this option.
 - [Magic Network Monitoring](/magic-network-monitoring/): Dynamically announces prefixes based on user-defined traffic thresholds observed in your network.
+- BGP peering with the Magic Transit routing table over Direct CNI.
 
 :::caution[Important]
 You should only use one control method per prefix at any given time. Mixing multiple control planes can lead to conflicting advertisement states, causing unpredictable routing behavior.
@@ -130,7 +131,7 @@ json={{
 
 AS prepending helps you gracefully transition traffic between network providers. By adding prepends to Cloudflare's advertisement, you make the route through Cloudflare less preferred for some Internet network providers. This allows you to simultaneously advertise the same prefix from an alternate provider with a shorter, more desirable `AS_PATH`. Advertising from both providers at once can provide a smoother traffic migration and minimize packet loss during a change of provider.
 
-The `"asn_prepend_count"` parameter accepts values from `0` to `3`. A higher value makes the route less preferred.
+The `"asn_prepend_count"` parameter accepts values from `0` to `3`. A higher value makes the route less preferred.  This parameter can also be changed using BGP, refer to [Use communities to set AS prepends on an anycast prefix](#use-communities-to-set-as-prepends-on-an-anycast-prefix).
 
 When you use AS prepending to migrate traffic away from Magic Transit, the typical sequence of events is as follows:
 
@@ -148,11 +149,52 @@ For traffic originated from Cloudflare's services, Cloudflare's internal network
 For example, if you have a CDN zone onboarded with a Magic Transit-protected origin that is part of a Cloudflare-advertised `/22` prefix, and you later opt to advertise a more specific and shorter `/24` prefix route directly from your network, Cloudflare's servers will continue to route proxied CDN traffic to your Magic Transit network, which will follow configured routes to your tunnel(s). This is specific to Cloudflare services: traffic from other sources will converge as expected by BGP to the direct route, because it is the most specific.
 :::
 
+## BGP control to Magic routing table
+
+### Automatically announce and withdraw anycast based on Magic BGP routes
+
+If you are a Magic Transit customer using Direct CNI with the 2.0 CNI dataplane, you can:
+- Automatically withdraw your prefixes from Cloudflare's global edge infrastructure when you withdraw all matching BGP learned prefixes from the Magic routing table.
+- Automatically advertise your prefixes via Cloudflare’s global edge infrastructure when you have at least one matching BGP learned prefix in the Magic routing table.
+
+To automatically control the withdrawal of the BGP session globally you must enable this feature on the BGP prefix using the [Addressing API](/api/resources/addressing/subresources/prefixes/subresources/bgp_prefixes/methods/edit/). For example:
+
+<APIRequest
+  path="/accounts/{account_id}/addressing/prefixes/{prefix_id}/bgp/prefixes/{bgp_prefix_id}"
+  method="PATCH"
+  json={{
+    "auto_advertise_withdraw": true
+  }}
+/>
+
+Once this is configured for a BGP prefix the following logic will apply:
+- If there are no BGP routes in the Magic routing table exactly matching the BGP prefix then the BGP prefix will be withdrawn.
+- If there is at least one BGP route in the Magic routing table exactly matching the BGP prefix then the BGP prefix will be announced.
+
+The Addressing API BGP prefix and the Magic routing table BGP route must match exactly (same IP prefix and CIDR prefix length). This means that if there is a valid route to a subnet or supernet, the BGP prefix will withdraw when there are no exactly matching Magic BGP routes.
+
+:::note
+When you withdraw a prefix using BGP, you must ensure you withdraw all matching BGP learned prefixes from the Magic routing table. Otherwise, your prefix will not be withdrawn from Cloudflare's global network.
+:::
+
+### Use communities to set AS prepends on an anycast prefix
+
+As an alternative to setting [AS prepends on any anycast prefix with the API](#use-the-api-to-set-as-prepends-on-a-bgp-prefix) you can instead use BGP Communities to control the number of AS prepends that Cloudflare announces from its edge for your prefix. The community values are:
+
+- `13335:50101`: Prepends one time with the 13335 ASN
+- `13335:50102`: Prepend two times with the 13335 ASN
+- `13335:50103`: Prepend three times with the 13335 ASN
+
+If you need to switch to your alternate service provider, you can prepend Cloudflare's ASN multiple times. The intent is typically to make the route less preferred and allow for a graceful transition to the new provider. The higher the prepend count, the less preferred Cloudflare's connection will be if there are no other prioritization rules in place.
+
+:::caution
+BGP has different mechanisms to control route priorities which are set by the peered network, not by Cloudflare. As such, this is a best effort feature. Cloudflare cannot guarantee that peers will honor AS prepends on Cloudflare’s transit and peering connections.
+:::
+
 ## BGP control with Cloudflare Route Reflectors
 
 Optionally, you can use BGP to control the advertisement status of your prefix — advertised or withdrawn — from Cloudflare's global network for on-demand deployment scenarios. BGP Control works by establishing BGP sessions to Cloudflare's globally distributed Route Reflectors, which will initiate propagation of your prefix advertisement across Cloudflare's global network. You can peer with Cloudflare's Route Reflectors via Internet or CNI. CNI peering is available through your account team.
 
-
 Prefixes can be advertised from Cloudflare's network in a supported on-demand method such as BGP Control, or dynamically via the UI, API, or [Magic Network Monitoring](/magic-transit/magic-network-monitoring/). During the onboarding of your on-demand prefixes, please specify whether you want BGP-controlled advertisement or dynamic advertisement (via dashboard/API/Magic Network Monitoring).
 
 Our network architecture utilizes multiple, redundant Route Reflectors, ensuring that the failure of any single reflector does not impact overall network resiliency or traffic forwarding. For maximum resiliency, we recommend peering with all three of Cloudflare's redundant Route Reflectors, as this architecture ensures the failure of any single reflector does not impact overall network availability or traffic forwarding.
@@ -169,6 +211,10 @@ After receiving your information, Cloudflare will update firewall filters to est
 When you withdraw a prefix using BGP, you must ensure the prefix is withdrawn across all BGP sessions on all route reflectors. Otherwise, your prefix will not be withdrawn from Cloudflare's global network.
 :::
 
+### BGP peering
+
+If you use Direct CNI as a way to on-ramp your network traffic to Magic Transit, refer to [BGP information](/magic-transit/reference/traffic-steering/#bgp-information) to learn how to use BGP to handle traffic routing between Cloudflare and your network. Note that this is a different option to using BGP as a means to control the advertisement status of your prefix.
+
 ### Regional settings
 
 Magic Transit requires static routing to steer traffic from Cloudflare's network over one of your configured tunnel off-ramps (for GRE and IPsec tunnels). For CNI, both static routing and BGP options are available. Currently, advertisement of routes for traffic engineering purposes is not supported. As a best practice to reduce last-hop latency, you should consider scoping your routes regionally.