Advertise prefixes
Cloudflare measures the Magic Transit prefix count based on the number of prefixes a customer announces through Cloudflare. The size of the prefix does not matter; there is no commercial or technical restriction. However, prefixes can only be announced exactly as they were provisioned. For example, a /20
prefix onboarded to Magic Transit can only be announced as a /20
. Smaller subnets that constitute the /20
cannot be announced individually. To announce the 16x /24s
within the /20
, for example, requires onboarding all 16 prefixes individually. If this disaggregated setup is desired, the total Magic Transit prefix count will increase.
List all prefixes and the ASNs where they should originate. When specifying prefixes, observe these guidelines:
- Prefixes must support at least 256 hosts (
/24
in classless inter-domain routing CIDR notation. - Internet Routing Registry entries and Letters of Authorization must match the prefixes and originating prefixes you submit to Cloudflare.
- When using contiguous prefixes, specify aggregate prefixes where possible.
- When using Route Origin Authorizations (ROAs) to sign routes for resource public key infrastructure (RPKI), the prefix and originating ASN must match the onboarding submission.
- If you do not own an ASN, you can use the Cloudflare Customer ASN (AS209242).
- Prefixes using BGP-controlled advertisements cannot be used in conjunction with on-demand auto-advertisement. You must use dynamic advertisement.
Prefix configuration example
Prefix | Originating AS |
---|---|
103.21.244.0/23 | AS209242 |
131.0.72.0/22 | AS395747 |
103.21.245.0/24 | AS395747 |
Add an IP prefix
- Log in to your Cloudflare dashboard, and select your account.
- Go to Magic Transit > Manage Magic Transit configuration > Configure.
- From the IP Prefixes tab, select Add IP Prefix.
- Fill out the information for your prefix and select Add IP Prefix.
After you add the prefix, you can edit its status.
Edit the status of a prefix
- From the IP Prefixes tab, locate the prefix you want to modify and select Edit.
- On the Edit IP Prefix page under Status, choose a status.
- (Optional) Edit the description for your prefix.
- Select Edit IP Prefix to save your changes.
Delete a prefix
You can only delete a prefix with an Unapproved status. To delete prefixes with a different status, contact your administrator or account manager.
- From the IP Prefixes tab, locate the prefix you want to modify and select Delete.
- Confirm your choice from the modal by selecting Delete.
Border Gateway Protocol (BGP) control for advertisements
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.
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 Flow-based monitoring. Prefixes advertised via BGP Control cannot be advertised dynamically as this method is configured during the onboarding of your prefix.
To begin using BGP control, contact your account team with the following information:
- BGP endpoint IP addresses
- Prefixes you want to use with BGP control
- Your ASN for the BGP session
After receiving your information, Cloudflare will update firewall filters to establish the BGP session and provide you with the BGP endpoints to control your prefixes.
Regional settings
Magic Transit requires static routing to steer traffic from Cloudflare’s network over one of your configured tunnel off-ramps (GRE, IPsec or CNI). 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. The default setting for static route regions is All Regions. Refer to Configure static routes for more information.
Example router configurations
Below you can find example peering configurations for Cisco IOS and Juniper Junos OS for on-demand deployments leveraging BGP Control. The IP addresses used are from Cloudflare’s route reflectors and should be left as is.
Cisco IOS
ip route {{ <YOUR-MAGIC-TRANSIT-PREFIX> }} Null0ip prefix-list magic-transit-prefix seq 5 permit {{ <YOUR-MAGIC-TRANSIT-PREFIX> }} route-map cloudflare-magic-transit-out permit 1match ip address prefix-list magic-transit-prefix!route-map cloudflare-magic-transit-out deny 99 route-map reject-all deny 99 router bgp {{ <YOUR-ASN> }}neighbor 141.101.67.22 remote-as 13335neighbor 141.101.67.22 ebgp-multihop 64neighbor 141.101.67.22 timers 60 900neighbor 162.158.160.22 remote-as 13335neighbor 162.158.160.22 ebgp-multihop 64neighbor 162.158.160.22 timers 60 900neighbor 173.245.63.66 remote-as 13335neighbor 173.245.63.66 ebgp-multihop 64neighbor 173.245.63.66 timers 60 900!address-family ipv4 unicastredistribute staticneighbor 141.101.67.22 route-map cloudflare-magic-transit-out outneighbor 141.101.67.22 route-map reject-all inneighbor 162.158.160.22 route-map cloudflare-magic-transit-out outneighbor 162.158.160.22 route-map reject-all inneighbor 173.245.63.66 route-map cloudflare-magic-transit-out outneighbor 173.245.63.66 route-map reject-all inexit-address-family
Juniper MX (Junos OS set commands)
set protocols bgp group CF_ROUTE_REFLECTORS neighbor 162.158.160.22 description "CF RR#1 SIN"set protocols bgp group CF_ROUTE_REFLECTORS neighbor 173.245.63.66 description "CF RR#2 IAD"set protocols bgp group CF_ROUTE_REFLECTORS neighbor 141.101.67.22 description "CF RR#3 CDG"set protocols bgp group CF_ROUTE_REFLECTORS peer-as 13335set protocols bgp group CF_ROUTE_REFLECTORS import REJECT-ALLset protocols bgp group CF_ROUTE_REFLECTORS export BGP-CONTROL-OUT set policy-options policy-statement REJECT-ALL then rejectset policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-filter 104.245.62.0/24 exactset policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from protocol staticset policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-type internalset policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> then acceptset policy-options policy-statement BGP-CONTROL-OUT then reject
Juniper MX (Junos OS XML format)
@rtr01> show configuration routing-instances STAGE protocols bgp group CF_ROUTE_REFLECTORStype external;multihop { ttl 64;}local-address {{customer router IP}}import NONE;export NONE;peer-as 13335;local-as {{customer AS}} loops 2;neighbor 162.158.160.22 { description "CF RR#1 SIN";}neighbor 173.245.63.66 { description "CF RR#2 IAD";}neighbor 141.101.67.22 { description "CF RR#3 CDG";}