Skip to content
Cloudflare Docs

Configure BGP peering

Magic WAN 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 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 ↗.

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.

BGP timers and settings

Cloudflare uses the timers as described below. These are not configurable:

SettingDescription
Hold timer240 seconds
(To establish a session, Cloudflare will compare our hold timer and the peer's hold timer, and use the smaller of the two values to establish the BGP session.)
Keepalive timerOne third of the hold time.
Graceful restart120 seconds
  • Hold timer: Specifies the maximum amount of time that a BGP peer will wait to receive a keepalive, update, or notification message before declaring the BGP session down. Cloudflare will use the smaller of this default hold time and that received from the peer in the open message.
  • Keepalive timer: BGP systems exchange keepalive messages to determine whether the peer router is reachable. If keepalive messages are not received within the Hold Timer, the session is assumed to be down, indicating that the peer is no longer reachable at the BGP protocol level.
  • Graceful restart timer: Tracks how long a router will wait for a peer to re-establish a BGP session after the peer initiates a graceful restart. If the peer does not reconnect within this time, the router declares the session down and removes stale routes.

Limitations

BGP multipath is supported. If the same prefix is learned on two different interconnects then traffic destined for that prefix will be distributed across each interconnect according to the usual ECMP behavior.

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.
  • Bidirectional Forwarding Detection (BFD) is not supported.
  • 4-byte ASNs are not supported.

Tunnel health checks

Magic WAN customers need to enable legacy health checks alongside BGP. This is essential to determine if a specific Cloudflare data center is reachable from a customer device or not. Tunnel health checks will modify the route's priorities for dynamically learned BGP routes.

How to choose an ASN for BGP peering

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 routing table. This default ASN is called the CF Account ASN and should be configured to a private 2-byte ASN (for example, any values between 64512 and 65534). To set this ASN:

  1. Log in to the Cloudflare dashboard ↗, and select your account.
  2. Go to Magic WAN > Configuration > BGP.
  3. In CF Account ASN, enter Cloudflare's ASN.
  4. Select Update.

Magic WAN customers should also be aware of the following:
  • The Cloudflare side ASN will be included in the AS_PATH of announced routes to any BGP enabled interconnect.
  • The customer chooses their device ASN, which should be different to the Cloudflare-side ASN.

How to set up BGP peering

You need to configure two ASNs:

  • The Cloudflare account-scoped ASN 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.

  1. Log in to the Cloudflare dashboard ↗, and select your account.
  2. Go to Magic WAN > Configuration > BGP.
  3. In CF Account ASN, enter Cloudflare's ASN.
  4. Go to Interconnects.
  5. Find the Direct CNI interconnect you want to configure with BGP > select the three dots next to it > Configure BGP.
  6. In Customer device ASN, enter the ASN for your network.
  7. In MD5 key, you can optionally enter the key for your network. Note that this is meant to prevent accidental misconfigurations, and is not a security mechanism.
  8. (Optional) In Advertised prefix list, input the additional prefixes automatically assigned by Cloudflare during the creation of the CNI interconnect, to advertise alongside your existing routes. Leave blank if you do not want to advertise extra routes.
    Typical prefixes to configure here include:
    • A route to 0.0.0.0/0, the default route — to attract all Internet-bound traffic if using Magic WAN with Gateway.
    • A route to 100.96.0.0/12, the portion of CGNAT space used by default with WARP clients.
  9. Select Enable BGP.