diff --git a/public/__redirects b/public/__redirects index 7070fd9e718f3e..9f43f5e0a9d214 100644 --- a/public/__redirects +++ b/public/__redirects @@ -403,6 +403,7 @@ /network-interconnect/express-cni/create-interconnects/ /network-interconnect/ 301 /network-interconnect/express-cni/ /network-interconnect/ 301 /network-interconnect/pni-and-peering/ /network-interconnect/ 301 +/network-interconnect/static/cni-locations-04-08-2025.pdf /network-interconnect/static/cni-locations-30-10-2025.pdf 301 # Constellation /constellation/ /workers-ai/ 301 diff --git a/public/network-interconnect/static/cni-locations-04-08-2025.pdf b/public/network-interconnect/static/cni-locations-04-08-2025.pdf deleted file mode 100644 index 701a10bc40cb7c..00000000000000 Binary files a/public/network-interconnect/static/cni-locations-04-08-2025.pdf and /dev/null differ diff --git a/public/network-interconnect/static/cni-locations-30-10-2025.pdf b/public/network-interconnect/static/cni-locations-30-10-2025.pdf new file mode 100644 index 00000000000000..79f8db9cbf9946 Binary files /dev/null and b/public/network-interconnect/static/cni-locations-30-10-2025.pdf differ diff --git a/src/content/docs/network-interconnect/get-started.mdx b/src/content/docs/network-interconnect/get-started.mdx index eed3e294940922..fb19a470aea26f 100644 --- a/src/content/docs/network-interconnect/get-started.mdx +++ b/src/content/docs/network-interconnect/get-started.mdx @@ -13,11 +13,12 @@ import { Render } from "~/components" Eligibility for CNI and port availability is determined in coordination with your Cloudflare account team. Notably: -- 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/). -- CNI provides benefits for certain Cloudflare products. Refer to [Product use cases](/network-interconnect/get-started/#product-use-cases) section to confirm that CNI is the right solution for your technical and business requirements. -- CNI is available in a subset of Cloudflare data centers: - - The type of dataplane offered in that location (v1.0 or v1.1) will determine specifications of the supported connection, such as the MTU. +- 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 according to our [open peering policy](https://www.cloudflare.com/peering-policy/). +- CNI is available at select Cloudflare data centers: + - The type of dataplane offered in that location (v1 or v1.1) will determine specifications of the supported connection, such as the MTU. - The diversity offered in the location will vary. +- Customers must have a BGP session established for CNI v1/1.1 to be operational. ### Product use cases @@ -25,15 +26,24 @@ Eligibility for CNI and port availability is determined in coordination with you ### Technical specifications -- **Supported port types (Direct CNI):** 10G-LR (single-mode fiber) and 100G-LR4 (single-mode fiber). +- **Supported port types (Direct CNI)**: + - **Dataplane v1 & v1.1**: 10GBASE-LR (single-mode fiber) and 100GBASE-LR (single-mode fiber). + - **Dataplane v2 (beta)**: 10GBASE-LR (single-mode fiber) and 100GBASE-LR4 (single-mode fiber) optics are supported. - **Distance limitations:** Cloudflare does not support optical links longer than 10 km. For longer distances, you must use intermediate hardware or a third-party provider to extend the connection. -- **IP addressing:** All CNI connections use a `/31` subnet for point-to-point IP connectivity between your router and Cloudflare's. -- **VLAN support:** CNI ports may be assigned a single 802.1Q VLAN tag. +- **IP addressing:** All Direct and Partner CNI connections use a `/31` subnet for point-to-point IP connectivity between your router and Cloudflare. +- **VLAN support:** + - **Dataplane v1 & v1.1**: CNI ports may be assigned a single 802.1Q VLAN tag. + - **Dataplane v2 (beta)**: VLAN tagging (802.1Q) and QinQ are not yet supported. - **MTU considerations:** - - **Dataplane 1.0:** Requires GRE tunneling for Magic Transit / WAN traffic, limiting the MTU to 1,476 bytes. - - **Dataplane 1.1:** Supports a native 1,500-byte MTU for traffic from Cloudflare to you (ingress), but still requires a 1,476-byte MTU for traffic from you to Cloudflare (egress). -- **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. -- **Link Aggregation Control Protocol (LACP)**: To increase bandwidth and provide link resiliency, Cloudflare supports combining multiple physical CNI ports into a single logical channel using LACP. You can bundle multiple connections to increase total throughput and add redundancy to your private connection with Cloudflare. + - **Dataplane v1**: Requires GRE tunneling for Magic Transit / WAN traffic, limiting the MTU to 1,476 bytes. + - **Dataplane v1.1**: Supports a native 1,500-byte MTU for traffic from Cloudflare to you (ingress), but still requires a 1,476-byte MTU for traffic from you to Cloudflare (egress). + - **Dataplane v2 (beta)**: Supports a maximum MTU of 1,500 bytes bidirectionally with no GRE requirement. +- **Bidirectional Forwarding Detection (BFD):** + - **Dataplane v1 & v1.1**: 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. + - **Dataplane v2 (beta)**: Not yet supported. +- **Link Aggregation Control Protocol (LACP)**: + - **Dataplane v1 & v1.1**: To increase bandwidth and provide link resiliency, Cloudflare supports combining multiple physical CNI ports into a single logical channel using Link Aggregation Control Protocol (LACP). You can bundle multiple connections to increase total throughput and add redundancy to your private connection with Cloudflare. + - **Dataplane v2 (beta)**: Not yet supported. Use ECMP instead. ### Performance characteristics @@ -43,9 +53,9 @@ The following are the maximum throughput rates supported by the CNI connection. |----------------------|-------------|--------------| | From Cloudflare to Customer (all use cases) | Up to 10 Gbps | Up to 100 Gbps | | From Customer to Cloudflare (peering use case) | Up to 10 Gbps | Up to 100 Gbps | -| 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 | +| From Customer to Cloudflare (Magic Transit/WAN) | • **v1 & v1.1**: Up to 1 Gbps per GRE tunnel over the CNI
• **v2 (beta)**: Up to 1 Gbps per CNI connection | • **v1 & v1.1**: Up to 1 Gbps per GRE tunnel over the CNI
• **v2 (beta)**: Up to 1 Gbps per CNI connection | -### Service Expectations +### Service expectations Consider the following service levels when planning your deployment: - **No Formal SLA**: @@ -54,36 +64,35 @@ Consider the following service levels when planning your deployment: - **Observability**: There is no visibility of the interconnect config/status within the Cloudflare dashboard. - **Availability**: While network-resilient locations are designed to maintain connectivity during maintenance, single-homed locations can experience full service disruption. - **Backup Connectivity**: You are required to maintain alternative Internet connectivity as a backup for all CNI implementations. -- **BGP**: Customers must have a BGP session established for Dataplane 1.0/1.1 to be operational. -## Location Alignment +## Location alignment -### Available Locations +### Available locations -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) (PDF) for details. +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-30-10-2025.pdf) (PDF) for details. -### Connectivity Partners +### Connectivity partners Cloudflare partners with leading global providers, including: Console Connect, CoreSite, Digital Realty, Equinix Fabric, Megaport, PacketFabric, and Zayo. -## End-to-End Implementation Workflow +## End-to-end implementation workflow The process of provisioning a CNI typically takes two to four weeks, depending on the complexity of implementation and third-party provider timelines. The most common delays occur during the physical connection phase, which is outside of Cloudflare's direct control. -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. -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. -3. **Order Connection**: - - 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. - - For a Partner Interconnect, you will use the provided details to order a virtual circuit from the partner's portal. -4. **Configure Network**: Both Cloudflare and your network team will configure the respective network devices according to the approved document. -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. -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. +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. +2. **Review configuration**: For the v1 dataplane, The Implementation Manager will provide a detailed configuration document covering IP addressing, VLANs, and other technical specifications. You must review and approve this document. For the v2 dataplane, this step is not necessary. +3. **Order connection**: + - 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. + - For a **Partner Interconnect**, you will use the provided details to order a virtual circuit from the partner's portal. +4. **Configure network**: Both Cloudflare and your network team will configure the respective network devices according to the approved document. +5. **Test and verify**: Once the connection is physically established, teams will perform basic connectivity tests (for example, ping) and, if applicable, verify that the BGP session can be established. +6. Enable tunnel health checks for [Magic Transit](/magic-transit/how-to/configure-tunnel-endpoints/#add-tunnels) and / or [Magic WAN](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#add-tunnels). +7. **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. 7. [Add maintenance notifications](/network-interconnect/monitoring-and-alerts/#enable-cloudflare-status-maintenance-notification). -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). -## How-To guides +## How-to guides -### How-To: Provision a Direct Interconnect +### How-to: Provision a Direct Interconnect 1. **Project Kickoff**: In an initial kickoff call, you will confirm the scope and timeline with Cloudflare. Be prepared to provide the following information: - desired colocation facility @@ -92,44 +101,51 @@ The process of provisioning a CNI typically takes two to four weeks, depending o - BGP password (optional) 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. The end-to-end process for ordering a cross-connect 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 third-party connectivity providers. -### How-To: Provision a Partner Interconnect +### How-to: Provision a Partner Interconnect 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. -### How-To: Configure BGP and routing +### How-to: Provision a Cloud Interconnect -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. +Enterprise customers using Magic WAN can get started with Cloud Interconnect by contacting their account team. -#### Step 1: IP Address provisioning +#### AWS Direct Connect (beta) -1. Cloudflare will send you a set of IPv4 and IPv6 addresses for your connection. -2. Assign the provided IPs to your router's interface that connects to Cloudflare. -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. - - **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. +If you are a Magic WAN customer, you can connect to [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/) using Cloud Interconnect. Cloud Interconnect supports AWS Dedicated Direct Connect, which provides a full physical port allocation in AWS. AWS Hosted Direct Connect is not yet supported. -#### Step 2: BGP session establishment +For your AWS Dedicated Direct Connect, you can choose between connection speeds of 10 Gbps or 1 Gbps. -After you confirm connectivity with successful ping tests, the next step is to establish the BGP session. +To connect to AWS Direct Connect: -1. Cloudflare will configure its side of the BGP session, and notify you once ready. -2. You will configure your side of the BGP session and accept the routes you need. -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. +1. Contact your account team to start the Cloud Interconnect provisioning process. Your team will let you know of available interconnect locations so you can choose the best one for you, as well as all the details involved in this process. +2. Log in to your AWS portal and order a Direct Connect. +3. AWS will provide you a Letter of Authorization (LOA) and a VLAN ID that you need to send to your account team. +4. Your account team will continue the process of provisioning your Cloud Interconnect with the AWS documents you have provided. Overall, this process should take around four weeks to finish. -#### BGP configuration options and use cases +#### Google Cloud interconnect (beta) -Depending on the Cloudflare services you use, your BGP configuration may vary: +1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/), and select your account. +2. Select **Interconnects** > **Create new**. +3. Under **Cloud Interconnect**, select **Create new**. +4. Under **Google Integration**, select **Select integration**. +5. Give your interconnect a name and optionally a description. Make sure the MTU value matches the MTU configured on the [GCP VLAN attachment](https://cloud.google.com/network-connectivity/docs/interconnect/how-to/dedicated/creating-vlan-attachments). +6. Select **Continue**. +7. From the **Interface speed** drop-down menu, select an interface speed. GCP will charge you based on the speed of the interconnect that you choose. +8. Enter your [VLAN attachment pairing key](https://cloud.google.com/network-connectivity/docs/interconnect/how-to/partner/creating-vlan-attachments). +9. Select **Continue**. +10. Review the details you provided, and select **Confirm order**. -- **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 this is not peering with the Magic Transit routing table, which is global. Instead, this is peering with the specific data center's Internet edge network. This means that prefixes Cloudflare learns via CNI remain local to that specific data center and are not propagated to other Cloudflare locations. -- **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. +Your Google Cloud Platform (GCP) interconnect will take a few minutes to be available. A BGP session will be established but no routes will be exchanged. -#### Important note on accepting routes from Cloudflare +#### GCP next steps -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 to 6,000 routes advertised by Cloudflare). +You can now select **View interconnects** for a list of all interconnects on your account. Select the interconnect name to show the interconnect details. The interconnect has a unique **Interconnect ID**. -#### Optional: Bidirectional Forwarding Detection (BFD) +After you have configured your Google Cloud Interconnect, you will need to add routes to use the interconnect: -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. - -- 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. -- BFD is only supported for Direct Interconnect connections. Contact your account team to enable it. -- 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. +- To create routes in the Magic routing table to direct traffic towards GCP: + - Add [static routes](/magic-wan/configuration/manually/how-to/configure-routes/#configure-static-routes) to your Magic WAN routing table with [legacy bidirectional tunnel health checks](/magic-wan/configuration/manually/how-to/configure-tunnel-endpoints/#legacy-bidirectional-health-checks) to detect failures and steer traffic to alternative paths. + - Note that routes advertised by BGP from GCP Cloud Router will be ignored. +- To create routes in GCP routing table to direct traffic towards Cloudflare, you must use the GCP Cloud Router: + - Add [custom learned routes to Cloud Router](https://cloud.google.com/network-connectivity/docs/router/how-to/configure-custom-learned-routes). + - Use the BGP session. Reach out to your account team to request a list of one or more prefixes to advertise, and specify the interconnect ID you want to advertise over. diff --git a/src/content/docs/network-interconnect/index.mdx b/src/content/docs/network-interconnect/index.mdx index 7dba6f78f095c3..1725448cbc1653 100644 --- a/src/content/docs/network-interconnect/index.mdx +++ b/src/content/docs/network-interconnect/index.mdx @@ -16,33 +16,35 @@ Connect your network infrastructure directly to Cloudflare -Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly to Cloudflare — rather than using the public Internet — for a more reliable and secure experience. With CNI, you can bring Cloudflare's full suite of network functions to your physical network edge. +Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly to Cloudflare — rather than using the public Internet — for a more performant and secure experience. With CNI, you can bring Cloudflare's full suite of network functions to your network edge. -## Why Use CNI? Key Benefits +## Why Use CNI? Key benefits Enterprises use CNI to achieve: - **Enhanced Performance**: Gain lower latency and more consistent network throughput. - **Increased Security**: Reduce your network's attack surface by connecting privately and avoiding the public Internet. -## Connection Types +## Connection types Choose the model that best fits your infrastructure and operational needs. -| | Direct Interconnect | Partner Interconnect | -| - | - | - | -| **Port type** | A dedicated physical fiber connection between your network equipment and Cloudflare's hardware in a shared data center. | A virtual connection to Cloudflare established through one of our global connectivity partners. | -| **Operations** | You are responsible for procuring and managing the physical cross-connect to Cloudflare's equipment. | Your partner manages the connection logistics, often through a software-defined networking portal. | -| **Ideal use case** | For customers collocated with Cloudflare who require maximum control, performance, and reliability. | For customers who are not in the same data center as Cloudflare or prefer a managed connectivity solution. | +| | Direct Interconnect | Partner Interconnect | Cloud Interconnect | +| --- | --- | --- | --- | +| **Port type** | A dedicated physical fiber connection between your network equipment and Cloudflare's hardware in a shared data center. | A virtual connection to Cloudflare established through one of our global connectivity partners. | A private connection between a customer's cloud environments (for example, AWS, Google Cloud) and Cloudflare | +| **Operations** | You are responsible for procuring and managing the physical cross-connect to Cloudflare's equipment. | Your partner manages the connection logistics, often through a software-defined networking portal. | Cloudflare connects to cloud providers' dedicated services, and customers establish private virtual circuits from their virtual private clouds. | +| **Ideal use case** | For customers collocated with Cloudflare who require maximum control, performance, and reliability. | For customers who are not in the same data center as Cloudflare or prefer a managed connectivity solution. | For customers with workloads in public clouds who need secure, reliable connectivity to Cloudflare services. | ## Dataplane Cloudflare's data centers may support one or more interconnect dataplanes. The dataplane is the type of equipment that terminates your direct connection: -- **Dataplane v1.0**: A peering connection to a Cloudflare edge data center that supports GRE tunnels for connecting with the Magic Networking overlay. -- **Dataplane v1.1**: An enhanced version of the 1.0 dataplane that supports GRE-less delivery for Magic Transit Direct Server Return. +- **Dataplane v1**: A peering connection to a Cloudflare edge data center that supports GRE tunnels for connecting with the Magic Networking overlay. +- **Dataplane v1.1**: An enhanced version of the v1 dataplane that supports GRE-less delivery for Magic Transit Direct Server Return. +- **Dataplane v2 (beta)**: Is based on the Customer Connectivity Router (CCR), which is specifically designed for customer connectivity. It provides simplified routing without GRE tunneling and supports a 1,500-byte MTU bidirectionally. -When you review the [available locations](/network-interconnect/static/cni-locations-04-08-2025.pdf) (PDF), you can see which dataplane version(s) are available. -## Product Use Cases +When you review the [available locations](/network-interconnect/static/cni-locations-30-10-2025.pdf) (PDF), you can see which dataplane version(s) are available. + +## Product use cases @@ -63,3 +65,4 @@ Magic Transit is a network security and performance solution that offers DDoS pr Improve security and performance for your entire corporate network, reducing cost and operation complexity. + diff --git a/src/content/docs/network-interconnect/monitoring-and-alerts.mdx b/src/content/docs/network-interconnect/monitoring-and-alerts.mdx index 7377371e10e52f..779ae4382e1e54 100644 --- a/src/content/docs/network-interconnect/monitoring-and-alerts.mdx +++ b/src/content/docs/network-interconnect/monitoring-and-alerts.mdx @@ -7,6 +7,18 @@ sidebar: import { Render, DashButton } from "~/components" +## Monitoring + +The Cloudflare dashboard shows a list of all previously created interconnects, as well as useful information such as IP addresses, speed, type of interconnect, and status. + +The [Status column](https://dash.cloudflare.com/?to=/:account/interconnects/all) in the dashboard shows three different status: + +- **Active**: The link operational state at the interconnect port on the Customer Connectivity Router (CCR) is up. This means that the CCR port sees sufficient light levels and has negotiated an Ethernet link. +- **Unhealthy**: The link operational state at interconnect port is down. This might mean the CCR does not see light, cannot negotiate an Ethernet signal, or the light levels are below -20 dBm. You can take general troubleshooting steps to solve the issue (such as checking cables and status lights for connectivity issues). If you are unable to solve the issue in this way, contact your account team. +- **Pending**: The link is not yet active. This is expected and can occur for several reasons: the customer has not received a cross-connect, the device is unresponsive, or physical adjustments may be required, such as swapping RX/TX fibers. The `Pending` status will disappear after the customer completes the cross-connect and status moves to `Active`. + +## Alerts (v1 dataplane only) + 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. **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. @@ -25,7 +37,7 @@ You can configure notifications for upcoming CNI maintenance events using the No 1. In the Cloudflare dashboard, go to the **Notifications** page. - + 2. Select **Add**. 3. From the product drop-down menu, select **Cloudflare Network Interconnect**. @@ -36,19 +48,24 @@ You can configure notifications for upcoming CNI maintenance events using the No ### Enable Cloudflare Status Maintenance Notification -1. First, identify the PoP code for your CNI circuit: - - In the Cloudflare dashboard, go to the **Configuration** page in Magic Transit or Magic WAN. - - For Magic Transit: - - For Magic WAN: - - Select the **Interconnects** tab. - - Select the CNI you want to enable notifications for. - - In the menu that appears, note the Data Center code (for example, `gru-b`). -2. Now, configure the alert: - - Go to **Notifications** and select **Add**. - - From the product drop-down menu, select **Cloudflare Status**. - - Select **Maintenance Notification**. - - Give your notification a name and choose your notification method. - - Select **Next**. - - Optionally, use the **Filter on Event Type** to select only the event types you want to be alerted for (Scheduled, Changed, Canceled). - - 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. - - Select **Create**. +First, identify the PoP code for your CNI circuit: +1. In the Cloudflare dashboard, go to the **Configuration** page in Magic Transit or Magic WAN. + + - **For Magic Transit**: + + - **For Magic WAN**: + +2. Select the **Interconnects** tab. +3. Select the CNI you want to enable notifications for. +4. In the menu that appears, note the Data Center code (for example, `gru-b`). + +Now, configure the alert: + +1. Go to **Notifications** and select **Add**. +2. From the product drop-down menu, select **Cloudflare Status**. +3. Select **Maintenance Notification**. +4. Give your notification a name and choose your notification method. +5. Select **Next**. +6. Optionally, use the **Filter on Event Type** to select only the event types you want to be alerted for (Scheduled, Changed, Canceled). +7. 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. +8. Select **Create**. diff --git a/src/content/docs/network-interconnect/operational-guidance.mdx b/src/content/docs/network-interconnect/operational-guidance.mdx index 73a1c4b4aa1327..6ab182e8c988b6 100644 --- a/src/content/docs/network-interconnect/operational-guidance.mdx +++ b/src/content/docs/network-interconnect/operational-guidance.mdx @@ -13,8 +13,8 @@ Also refer to [Monitoring and alerts](/network-interconnect/monitoring-and-alert Cloudflare performs regular network maintenance that may impact CNI connectivity. -- **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. -- **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. +- **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. +- **Designing for availability**: For critical applications, deploy CNI in locations that support diversity on the device level (multi-homed PoPs). Cloudflare does not guarantee coordinated maintenance between PoP locations. ## Troubleshooting diff --git a/src/content/partials/networking-services/cni-product-use-cases.mdx b/src/content/partials/networking-services/cni-product-use-cases.mdx index b7851f060f07e1..fa954e254ba12a 100644 --- a/src/content/partials/networking-services/cni-product-use-cases.mdx +++ b/src/content/partials/networking-services/cni-product-use-cases.mdx @@ -5,12 +5,12 @@ CNI provides a private point-to-point IP connection with Cloudflare. There are two dataplanes that come with different technical specifications. -| | Dataplane v1.0 | Dataplane v1.1 | +| | Dataplane v1 & 1.1 | Dataplane v2 (beta) | | ---- | ---- | ---- | -| **Magic Transit Direct Server Return (DSR)**
DDoS protection for all ingress traffic from the Internet to your public network. Send egress traffic via your ISP. | Supported with a GRE tunnel established over the interconnect circuit. | Supported with or without a GRE tunnel established over the interconnect circuit. | -| **Magic Transit with Egress**
DDoS protection for all ingress traffic from the Internet to your public network. Send egress traffic via Cloudflare. | Supported with a GRE tunnel established over the interconnect circuit. | Supported with a GRE tunnel established over the interconnect circuit. | -| **Magic WAN and Zero Trust**
Build a secure, private network backbone connecting your Zero Trust users and applications with all your sites, data centers, and clouds. | Supported with a GRE tunnel established over the interconnect circuit. | Supported with or without a GRE tunnel established over the interconnect circuit. | -| **Peering**
Exchange public routes with a single Cloudflare PoP (Point of Presence). | Supported. All customers connecting with the edge data center will exchange public routes at that PoP with AS13335. Connectivity is established at each individual PoP. Routes for other edge locations in Cloudflare's network may not be available. Routes for customer-advertised prefixes will be available only in the connected PoP. | Supported. All customers connecting with the edge data center will exchange public routes at that PoP with AS13335. Connectivity is established at each individual PoP. Routes for other edge locations in Cloudflare's network may not be available. Routes for customer-advertised prefixes will be available only in the connected PoP. | -| **Application Security and Performance**
Improve the performance and security of your web applications | **Supported via peering**: Customers can use Argo Smart Routing to direct origin traffic via the edge peering connection when it is determined to be the lowest latency option. Customers must maintain a direct Internet connection which will always be used for a portion of traffic and during failure scenarios.
**Supported Via Magic Transit**: Customers may configure any product with an origin server IP address that is protected by Magic Transit. Magic Transit will direct this traffic via the overlay and customer can control interconnect next-hops using the Magic networking routing table. | **Supported via peering**: Customers can use Argo Smart Routing to direct origin traffic via the edge peering connection when it is determined to be the lowest latency option. Customers must maintain a direct Internet connection which will always be used for a portion of traffic and during failure scenarios.
**Supported Via Magic Transit**: Customers may configure any product with an origin server IP address that is protected by Magic Transit. Magic Transit will direct this traffic via the overlay and customer can control interconnect next-hops using the Magic networking routing table. | +| **Magic Transit Direct Server Return (DSR)**
DDoS protection for all ingress traffic from the Internet to your public network. Send egress traffic via your ISP. | Supported with a GRE tunnel established over the interconnect circuit. For v1.1, supported with or without a GRE tunnel established over the interconnect circuit. | Supported. | +| **Magic Transit with Egress**
DDoS protection for all ingress traffic from the Internet to your public network. Send egress traffic via Cloudflare. | Supported with a GRE tunnel established over the interconnect circuit. For v1.1, supported with or without a GRE tunnel established over the interconnect circuit. | Supported. | +| **Magic WAN and Zero Trust**
Build a secure, private network backbone connecting your Zero Trust users and applications with all your sites, data centers, and clouds. | Supported with a GRE tunnel established over the interconnect circuit. For v1.1, supported with or without a GRE tunnel established over the interconnect circuit. | Supported. | +| **Peering**
Exchange public routes with a single Cloudflare PoP (Point of Presence). | Supported.

All customers connecting with the edge data center will exchange public routes at that PoP with AS13335. Connectivity is established at each individual PoP. Routes for other edge locations in Cloudflare's network may not be available. Routes for customer-advertised prefixes will be available only in the connected PoP. | Not supported. | +| **Application Security and Performance**
Improve the performance and security of your web applications | **Supported via peering**: Customers can use Argo Smart Routing to direct origin traffic via the edge peering connection when it is determined to be the lowest latency option. Customers must maintain a direct Internet connection which will always be used for a portion of traffic and during failure scenarios.
**Supported Via Magic Transit**: Customers may configure any product with an origin server IP address that is protected by Magic Transit. Magic Transit will direct this traffic via the overlay and customer can control interconnect next-hops using the Magic networking routing table. | When the origin IPs are behind Magic Transit over a CNI v2, all Cloudflare services that work with public origins (like Load Balancer, WAF, Cache) will run over the CNI. | For more details refer to the [prerequisites section](/network-interconnect/get-started/#prerequisites). \ No newline at end of file