You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/partials/network-interconnect/bgp-peering.mdx
+46-11Lines changed: 46 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,42 +2,78 @@
2
2
params:
3
3
- productName
4
4
- productPath
5
+
- legacyHCs
5
6
---
6
7
7
8
import { Markdown } from"~/components";
8
9
9
-
{props.productName} customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and Cloudflare when using a Direct CNI on-ramp. Using BGP peering with a CNI allows customers to:
10
-
- Exchange routes dynamically
10
+
{props.productName} 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.
11
+
12
+
Using BGP peering with a CNI allows customers to:
11
13
- Automate the process of adding or removing networks and subnets
12
14
- Take advantage of failure detection and session recovery features
13
-
- Establish an eBGP session between their routers and Cloudflare in a single-hop link, secured by MD5 authentication to prevent misconfigurations.
14
-
- Established sessions both with dedicated ports using Direct CNI, as well as Cloud CNI dedicated and virtual circuits.
15
+
16
+
With this functionality, customers can:
17
+
- Establish an eBGP session between their devices and the {props.productName} service when connected via CNI
18
+
- Secure the session by MD5 authentication to prevent misconfigurations.
19
+
- Exchange routes dynamically between their devices and their Magic routing table.
20
+
15
21
16
22
## Route distribution and convergence
17
23
18
-
All {props.productName} routes are distributed into BGP announcements. Each BGP peer will receive each prefix route along with the full `AS_PATH`, with the selected overlay ASN prepended. This is so that the peer can accurately perform [loop prevention](https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2).
24
+
Routes received from the customer device will be redistributed into the Magic routing table, which is used by both Magic WAN and Magic Transit.
25
+
26
+
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.
19
27
20
-
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.
28
+
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.
29
+
30
+
## Limitations
31
+
32
+
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.
33
+
34
+
BGP support currently has the following limitations:
35
+
- The Cloudflare account ASN and the customer device ASN must be different. Only eBGP is supported.
36
+
- Routes are always injected with a priority of 100
37
+
- Bidirectional Forwarding Detection (BFD) is not supported
38
+
- 4-byte ASNs are not supported
21
39
22
40
## Tunnel health checks
23
41
24
42
You need to enable <ahref={props.productPath}>tunnel health checks</a> alongside BGP. This is essential to determine if a specific Cloudflare datacenter is reachable from a customer router or not. Tunnel health checks will modify the route's priorities for dynamically learned BGP routes.
25
43
26
-
{props.productName} customers should configure unidirectional health checks.
44
+
{props.productName} customers should configure legacy <ahref={props.legacyHCs}>bidirectional health checks</a>.
45
+
46
+
## How to choose an ASN for BGP peering
47
+
48
+
The Magic routing table is under the control of the customer, and the customer is able to choose both the Cloudflare side ASN and their customer device side ASN.
49
+
50
+
By default each BGP peering session will use the same Cloudflare side ASN to represent peering with the Magic WAN/Transit routing table. This default ASN is called the **CF Account ASN** and should be configured to a private 2-byte ASN (64512 and 65534). To set this ASN:
51
+
52
+
1. Log in to the Cloudflare dashboard, and select your account.
53
+
2. Go to Magic WAN / Transit > Configuration > BGP.
54
+
3. In CF Account ASN, enter Cloudflare's ASN.
55
+
56
+
### For Magic WAN customers
57
+
- The Cloudflare side ASN will be included in the `AS PATH` of announced routes to any BGP enabled interconnect.
58
+
- The customer device ASN can be chosen by the customer, and should be different to the Cloudflare side ASN.
59
+
60
+
### For Magic Transit customers
61
+
- The Cloudflare side ASN will never be exposed in `AS PATH` of anycast announcements from the Cloudflare edge. In those announcements, Cloudflare will always use the Cloudflare ASN of `13335` 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)
62
+
- 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.
63
+
27
64
28
65
## How to set up BGP peering
29
66
30
67
:::caution
31
-
BGP peering is only available to Magic WAN/Transit customers with Direct CNI as an on-ramp. If your network is set up with GRE or IPsec tunnels, you cannot use BGP peering.
68
+
BGP peering is only available to {props.productName} customers with Direct CNI as an on-ramp. If your network is set up with GRE or IPsec tunnels, you cannot use BGP peering.
32
69
:::
33
70
34
71
You need to configure two ASNs:
35
-
- The Cloudflare global account one.
72
+
- The Cloudflare [account-scoped ASN](#how-to-choose-an-asn-for-bgp-peering).
36
73
- One ASN for each Interconnect you want to configure with BGP.
37
74
38
75
If you already have set up your Cloudflare account ASN, you can skip steps two and three below.
39
76
40
-
41
77
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login), and select your account.
42
78
2. Go to **{props.productName}** > **Configuration** > **BGP**.
43
79
3. In **CF Account ASN**, enter Cloudflare's ASN.
@@ -47,4 +83,3 @@ If you already have set up your Cloudflare account ASN, you can skip steps two a
47
83
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.
48
84
8. (Optional) In **Advertised prefix list**, input the additional static 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.
0 commit comments