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/docs/network-interconnect/get-started.mdx
+99-2Lines changed: 99 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ import { Render } from "~/components"
14
14
Eligibility for CNI and port availability is determined in coordination with your Cloudflare account team. Notably:
15
15
16
16
- CNI ports are currently offered at no charge to Enterprise customers. Non-Enterprise customers (and any third party) may peer with Cloudflare via Internet Exchange/PNI according to our [open peering policy](https://www.cloudflare.com/peering-policy/).
17
-
- CNI provides benefits for certain Cloudflare products. Refer to [Product use cases section](#link) section to confirm that CNI is the right solution for your technical and business requirements.
17
+
- CNI provides benefits for certain Cloudflare products. Refer to [Product use cases section](/network-interconnect/get-started/#product-use-cases) section to confirm that CNI is the right solution for your technical and business requirements.
18
18
- CNI is available in a subset of Cloudflare data centers:
19
19
- The type of dataplane offered in that location (v1.0 or v1.1) will determine specifications of the supported connection, such as the MTU.
20
20
- The diversity offered in the location will vary.
@@ -32,4 +32,101 @@ Eligibility for CNI and port availability is determined in coordination with you
32
32
-**MTU considerations:**
33
33
-**Dataplane 1.0:** Requires GRE tunneling for Magic Transit / WAN traffic, limiting the MTU to 1476 bytes.
34
34
-**Dataplane 1.1:** Supports a native 1500-byte MTU for traffic from Cloudflare to you (ingress), but still requires a 1476-byte MTU for traffic from you to Cloudflare (egress).
35
-
-**Bidirectional Forwarding Detection (BFD):** BFD provides fast failure detection for BGP sessions and is supported on direct connections. To enable BFD, contact your account team. Note that BFD on a CNI does not impact the failover time for Magic Transit / WAN tunnels, which rely on separate health checks.
35
+
-**Bidirectional Forwarding Detection (BFD):** BFD provides fast failure detection for BGP sessions and is supported on direct connections. To enable BFD, contact your account team. Note that BFD on a CNI does not impact the failover time for Magic Transit / WAN tunnels, which rely on separate health checks.
36
+
37
+
#### Performance Characteristics
38
+
39
+
The following are the maximum throughput rates supported by the CNI connection. Actual performance will depend on your specific use case and configuration.
| From Cloudflare to Customer (all use case) | Up to 10 Gbps | Up to 100 Gbps |
44
+
| From Customer to Cloudflare (peering use case) | Up to 10 Gbps | Up to 100 Gbps |
45
+
| From Customer to Cloudflare (Magic Transit/WAN) | Up to 1 Gbps per GRE tunnel over the CNI | Up to 1 Gbps per GRE tunnel over the CNI |
46
+
47
+
### Service Expectations
48
+
49
+
Please consider the following service levels when planning your deployment:
50
+
-**No Formal SLA**:
51
+
- CNI is currently offered at no charge and without a formal Service Level Agreement (SLA).
52
+
- Cloudflare will work to restore CNI service in the event of a Cloudflare issue. In some Cloudflare Data Centers the recovery time could be several days. Therefore we always recommend backup connectivity to a different device or via an Internet tunnel.
53
+
-**Observability**: There is no visibility of the interconnect config/status within the Cloudflare dashboard.
54
+
-**Availability**: While network-resilient locations are designed to maintain connectivity during maintenance, single-homed locations can experience full service disruption.
55
+
-**Backup Connectivity**: You are required to maintain alternative Internet connectivity as a backup for all CNI implementations.
56
+
57
+
## Location Alignment
58
+
59
+
### Available Locations
60
+
61
+
Direct connections are available at any Cloudflare data center where you are also located. Make sure to check whether the location of interest has the right dataplane version and diversity requirements for your use case. Refer to [available locations](/network-interconnect/static/cni-locations-04-08-2025.pdf) for details.
62
+
63
+
### Connectivity Partners
64
+
65
+
Cloudflare partners with leading global providers, including: Console Connect, CoreSite, Digital Realty, Equinix Fabric, Megaport, PacketFabric, and Zayo.
66
+
67
+
## End-to-End Implementation Workflow
68
+
69
+
The process of provisioning a CNI can take several weeks, depending on the complexity and third-party provider timelines. The most common delays occur during the physical connection phase, which is outside of Cloudflare's direct control.
70
+
71
+
1.**Submit Request**: Work with your account team to create a CNI request ticket, providing your desired CNI type, location, use case, and technical details. An Implementation Manager will be assigned to guide the process.
72
+
2.**Review Configuration**: The Implementation Manager will provide a detailed configuration document covering IP addressing, VLANs, and other technical specifications. You must review and approve this document.
73
+
3.**Order Connection**:
74
+
- For a Direct Interconnect, you will receive a Letter of Authorization (LOA) from Cloudflare to order the physical cross-connect from the data center facility operator.
75
+
- For a Partner Interconnect, you will use the provided details to order a virtual circuit from the partner's portal.
76
+
4.**Configure Network**: Both Cloudflare and your network team will configure the respective network devices according to the approved document.
77
+
5.**Test and Verify**: Once the connection is physically established, teams will perform basic connectivity tests (for example, ping) and verify that the BGP session can be established.
78
+
6.**Activate Services**: Configure your Cloudflare products (for example, Magic Transit) to route traffic over the new CNI. The Implementation Manager will verify end-to-end traffic flow before marking the deployment as complete.
8. Enable tunnel health checks for Magic [Transit](/magic-transit/how-to/configure-tunnel-endpoints/#add-tunnels) / [WAN](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#add-tunnels).
81
+
## How-To Guides
82
+
83
+
### How-To: Provision a Direct Interconnect
84
+
85
+
1.**Project Kickoff**: In an initial kickoff call, you will confirm the scope and timeline with Cloudflare. Be prepared to provide the following information:
86
+
- desired colocation facility
87
+
- required port speeds (10G or 100G)
88
+
- BGP ASN for Peering/Magic Transit
89
+
- BGP password (optional)
90
+
2.**Order Cross-Connect**: Cloudflare will issue a Letter of Authorization (LOA). This document grants you permission to order a physical cross-connect between your equipment and a specific port on Cloudflare's hardware within the data center. This process can take one to two weeks or more, depending on the facility provider. Cloudflare's demarcation is the port that is specified in the LOA: you are responsible for the deployment, provisioning and ongoing support and operation of this connection and the commercial relationships with the facility provider and any 3rd party connectivity providers.
91
+
92
+
### How-To: Provision a Partner Interconnect
93
+
94
+
Cloudflare partners with leading connectivity providers globally. To provision a Partner Interconnect, you will initiate a connection request from your chosen provider's administrative portal. Cloudflare will then review and accept the request to activate the virtual circuit.
95
+
96
+
### How-To: Configure BGP and Routing
97
+
98
+
Once your physical cross-connect or virtual circuit is provisioned, the next phase is to configure IP routing using Border Gateway Protocol (BGP). This process typically takes about one week to complete.
99
+
100
+
#### Step 1: IP Address Provisioning
101
+
102
+
1. Cloudflare will send you a set of IPv4 and IPv6 addresses for your connection.
103
+
2. Assign the provided IPs to your router's interface that connects to Cloudflare.
104
+
3. Perform ping tests between your router and Cloudflare's router to confirm that the physical or virtual link is active and passing packets correctly.
105
+
-**For Partner Interconnects**: If you are using a partner like Megaport, ensure you have configured the correct VLAN provided by your Customer Success Manager, as an incorrect VLAN can cause IP provisioning to fail.
106
+
107
+
#### Step 2: BGP Session Establishment
108
+
109
+
After you confirm connectivity with successful ping tests, the next step is to establish the BGP session.
110
+
111
+
1. Cloudflare will configure its side of the BGP session, and notify you once ready
112
+
2. You will configure your side of the BGP session and accept the routes.
113
+
3. Once the session is established, traffic will begin to flow over the CNI. Contact your solutions engineer to verify that traffic is routing as expected.
114
+
115
+
#### BGP Configuration Options and Use Cases
116
+
117
+
Depending on the Cloudflare services you use, your BGP configuration may vary:
118
+
119
+
-**Standard Peering**: This is the most common scenario, where BGP is used to exchange routes between your network and Cloudflare. Cloudflare learns your network routes, which is useful for services like CDN-only deployments or on-demand Magic Transit. It is important to note that prefixes Cloudflare learns via CNI remain local to that specific data center and are not propagated to other Cloudflare locations.
120
+
-**Magic Transit with Controlled Advertisement**: Magic Transit customers can use a second BGP session to control which prefixes are advertised to the internet. In this setup, Cloudflare advertises no prefixes to you, and you advertise only the specific prefixes you want Cloudflare to announce on your behalf.
121
+
122
+
#### Important Note on Accepting Routes from Cloudflare
123
+
124
+
If you wish to use the CNI for egress traffic from your network to Cloudflare-advertised prefixes (such as anycast or BYOIP addresses), you can accept the BGP prefixes you receive from Cloudflare (typically there will be around 4,000 routes advertised by Cloudflare). However, be aware that there is a 1 Gbps capacity limitation for traffic you send to Cloudflare over the CNI link.
For configurations that are highly sensitive to packet loss, Bidirectional Forwarding Detection (BFD) can be enabled to monitor link status on a sub-second basis.
129
+
130
+
- BFD works by sending a rapid stream of small packets over the BGP session. If a few packets are lost, the link is immediately considered down, enabling faster failover.
131
+
- BFD is only supported for Direct Interconnect connections. Contact your account team to enable it.
132
+
- Note that enabling BFD on a CNI BGP session does not change the failover time for Magic Transit/WAN, which is controlled by its own tunnel health checks.
You can configure notifications for upcoming CNI maintenance events using the Notifications feature in the Cloudflare dashboard. It is recommended to subscribe to two types of notifications to stay fully informed.
11
+
12
+
**CNI Connection Maintenance Alert (beta):** This alert informs you about maintenance events (scheduled, updated, or canceled) that directly impact your CNI circuits used with the Magic Networking overlay only.
13
+
- You will receive warnings up to two weeks in advance for maintenance impacting your Magic Transit/WAN CNI connections.
14
+
- You will be notified if the details of a scheduled maintenance change or if it is canceled.
15
+
- For recently added maintenance, notifications are sent after a six-hour delay to prevent alerting fatigue from minor adjustments.
16
+
17
+
**Cloudflare Status Maintenance Notification:** This alert informs you about maintenance for an entire Cloudflare Point of Presence (PoP). While not specific to your CNI, this maintenance will impact all CNI services in that location, including connections that are being used only for peering use cases without Magic Networking
18
+
- You will be warned about potentially disruptive maintenance at the PoP level.
19
+
- By default, you are notified for all event types (Scheduled, Changed, Canceled), but you can filter these.
20
+
- By default, you are notified for all Cloudflare PoPs, but you can filter for only the specific locations where you have CNI circuits.
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
27
+
2. Go to **Notifications**.
28
+
3. Select **Add**.
29
+
4. From the product drop-down menu, select **Cloudflare Network Interconnect**.
30
+
5. Select **Connection Maintenance Alert**.
31
+
6. Give your notification a name and an optional description.
32
+
7. Choose your preferred notification method (for example, email address).
33
+
8. Select **Save**.
34
+
35
+
### Enable Cloudflare Status Maintenance Notification
36
+
37
+
1. First, identify the PoP code for your CNI circuit:
38
+
- Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
39
+
- Navigate to **Magic Transit / WAN > Configuration > Interconnects**.
40
+
- Select the CNI you want to enable notifications for.
41
+
- In the menu that appears, note the Data Center code (for example, `gru-b`).
42
+
2. Now, configure the alert:
43
+
- Go to **Notifications** and select **Add**.
44
+
- From the product drop-down menu, select **Cloudflare Status**.
45
+
- Select **Maintenance Notification**.
46
+
- Give your notification a name and choose your notification method.
47
+
- Select **Next**.
48
+
- Optionally, use the **Filter on Event Type** to select only the event types you want to be alerted for (Scheduled, Changed, Canceled).
49
+
- In **Filter on Points of Presence**, enter the three-letter code for your PoP (for example, for `gru-b`, enter `gru`). You can add multiple PoPs, separated by commas.
Also refer to [Monitoring and alerts](/network-interconnect/monitoring-and-alerts).
13
+
14
+
Cloudflare performs regular network maintenance that may impact CNI connectivity.
15
+
16
+
-**Maintenance Impact**: Maintenance windows average six hours.Customers who are not redundantly connected to diverse devices, for instance in single-homed PoPs will experience a complete service disruption on CNI in that location.
17
+
-**Designing for Availability**: For critical applications, deploy CNI in locations that support diversity on the device level (multi-homed PoPs) to ensure protection against a single point of hardware failure and routine maintenance. Cloudflare does not guarantee coordinated maintenance between PoP locations. This means connecting to two different PoPs does not ensure protection against coincident service disruption.
18
+
19
+
## Troubleshooting
20
+
21
+
When facing connectivity problems, your first action should be to check for broader service disruptions. Visit `https://www.cloudflarestatus.com/` to see if any scheduled maintenance or active incidents are impacting services. This helps determine if the issue originates outside your network. Refer to [Monitoring and alerts](/network-interconnect/monitoring-and-alerts).
22
+
23
+
If no system-wide problems are reported, gather the following information before submitting a support case. Providing comprehensive details facilitates a faster resolution:
24
+
25
+
-**Timeline**: When the issue began and ended (if applicable), including the timezone.
26
+
-**Identification**: The CNI IP address or point-to-point prefix for the impacted CNI. If your CNI is part of a Magic setup, please also provide the name of the Magic Transit/WAN interconnect as listed in your dashboard.
27
+
-**Physical Layer**: Light levels of the CNI link (if applicable).
28
+
-**Service Impact**: Confirmation whether Magic Transit / WAN traffic was affected.
29
+
-**Problem Description**: A clear summary of the issue (for example, CNI down, BGP session down, prefixes withdrawn).
0 commit comments