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 16 individual /24s subnets within the /20 subnet mask, for example, requires onboarding all 16 subnets individually. If this disaggregated setup is desired, the total Magic Transit prefix count will increase.

List all prefixes and the autonomous systems (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). Refer to Use a Cloudflare IP if you do not meet the /24 prefix length requirement.
• Internet Routing Registry entries and Letters of Agency (LOA) 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 (AS13335).
• Prefixes using BGP-controlled advertisements cannot be used in conjunction with dynamic advertisement (via dashboard/API). Please specify your preferred on-demand advertisement method during the prefix onboarding.

Prefix configuration example

Prefix	Originating AS
103.21.244.0/23	AS13335
131.0.72.0/22	AS395747
103.21.245.0/24	AS395747

Cloudflare ASN vs. your own ASN

When customers supply their own ASN, Cloudflare prepends the main Cloudflare ASN (AS13335) to the BGP AS_PATH. For example, if the customer ASN is AS64496, anyone directly peering with Cloudflare sees the path as 13335 64496.

If you do not have an ASN or do not want to bring your ASN to Cloudflare, you can use the Cloudflare Customer ASN (AS13335).

Note

Current customers who are still using Cloudflare's AS209242 can continue using this same ASN. No further change is required.

Advertise or withdraw a prefix

Note

You can only advertise your prefix after running pre-flight checks with Cloudflare. If your prefix status is greyed out and shows an Withdrawn status, your prefix is locked. Contact your account team to close the pre-flight checks phase with you and unlock your prefixes.

1. Log in to the Cloudflare dashboard ↗, and select your account.
2. Go to Magic Transit > Configuration.
3. From IP Prefixes tab, select the prefix you want to modify > Edit.
4. From the dropdown menu Status, choose weather the status of your IP is Advertised or Withdrawn.
5. (Optional) Edit the description for your prefix.
6. Select Edit IP Prefix to save your changes.

Edit the status of a prefix

1. Go to Magic Transit > Configuration.
2. From the IP Prefixes tab, locate the prefix you want to modify.
3. Select the three dots in front of the IP prefix > Delete.
4. Confirm your choice from the modal by selecting Delete.

To avoid latency and potentially dropped routes, enable prefix advertisement from Cloudflare before withdrawing the advertisement from your data center.

You should also be aware that announcing or withdrawing a prefix should propagate across Cloudflare's global network almost instantly, with changes typically taking effect within a few minutes at most. However, Cloudflare has no control over how long ISPs take to refresh their routes. Keep this in mind when announcing or withdrawing a prefix from your account, and plan accordingly.

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.

1. From the IP Prefixes tab, locate the prefix you want to modify and select Delete.
2. 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 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).

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.

Note

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 peering to learn how to configure BGP peering.

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> }} Null0
ip prefix-list magic-transit-prefix seq 5 permit {{ <YOUR-MAGIC-TRANSIT-PREFIX> }}

route-map cloudflare-magic-transit-out permit 1
match 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 13335
neighbor 141.101.67.22 ebgp-multihop 64
neighbor 141.101.67.22 timers 60 900
neighbor 162.158.160.22 remote-as 13335
neighbor 162.158.160.22 ebgp-multihop 64
neighbor 162.158.160.22 timers 60 900
neighbor 173.245.63.66  remote-as 13335
neighbor 173.245.63.66  ebgp-multihop 64
neighbor 173.245.63.66  timers 60 900
!
address-family ipv4 unicast
redistribute static
neighbor 141.101.67.22 route-map cloudflare-magic-transit-out out
neighbor 141.101.67.22 route-map reject-all in
neighbor 162.158.160.22 route-map cloudflare-magic-transit-out out
neighbor 162.158.160.22 route-map reject-all in
neighbor 173.245.63.66  route-map cloudflare-magic-transit-out out
neighbor 173.245.63.66  route-map reject-all in
exit-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 13335
set protocols bgp group CF_ROUTE_REFLECTORS import REJECT-ALL
set protocols bgp group CF_ROUTE_REFLECTORS export BGP-CONTROL-OUT

set policy-options policy-statement REJECT-ALL then reject
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-filter 104.245.62.0/24 exact
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from protocol static
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-type internal
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> then accept
set 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_REFLECTORS
type 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";
}

Was this helpful?

What did you like?

Accurate

Easy to understand

Solved my problem

Helped me decide to use the product

Other

What went wrong?

Hard to understand

Incorrect information

Missing the information

Other

Thank you for helping improve Cloudflare's documentation!