Configuration",
+ tunnelEndpoints: "/magic-wan/configuration/manually/how-to/configure-tunnels/",
+ ipRanges: "
When using Magic WAN and Cloudflare Tunnel together, remember to consider the IP ranges utilized in the static routes of Cloudflare Tunnel when selecting static routes for Magic WAN. For more information, refer to [Cloudflare Tunnel](/magic-wan/zero-trust/cloudflare-tunnel/). "
+ }}
+/>
## Next steps
diff --git a/src/content/docs/magic-wan/reference/mtu-mss.mdx b/src/content/docs/magic-wan/reference/mtu-mss.mdx
index 774a56e6522b315..45043fd8461c277 100644
--- a/src/content/docs/magic-wan/reference/mtu-mss.mdx
+++ b/src/content/docs/magic-wan/reference/mtu-mss.mdx
@@ -10,15 +10,8 @@ import { Render } from "~/components";
-
-## MSS clamping recommendations
-
-### GRE tunnels as off-ramp
-
-
-
-### IPsec tunnels
-
-
+ params={{
+ magicProduct: "Magic WAN",
+ productName: "Magic WAN"
+ }}
+/>
\ No newline at end of file
diff --git a/src/content/partials/magic-transit/mtu-mss/mt-dsr.mdx b/src/content/partials/magic-transit/mtu-mss/mt-dsr.mdx
deleted file mode 100644
index b61db301ed0617b..000000000000000
--- a/src/content/partials/magic-transit/mtu-mss/mt-dsr.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-{}
----
-
-Asymmetric routing is a common scenario especially with Magic Transit. Ingress traffic from the Internet enters the Cloudflare network, then traverses a GRE tunnel (MTU of 1,476 bytes), and egress traffic from the datacenter is sent via Direct Server Return (DSR) over the Internet (MTU of 1,500 bytes).
-
-In an asymmetric scenario, we want to reduce the MSS value of packets sent by Magic Transit users to the Internet in order to reduce the size of packets sent from the Internet towards their network. To accomplish this, the configuration must be done either on the customer's end-hosts or through an MSS clamp on an intermediary device on the egress path of traffic leaving their network. How MSS values affect payload sizes on both routing paths is detailed below.
-
-
-
-_Key takeaway from the chart above: MSS clamping affects TCP packet payload sizes flowing in the opposite direction vs. where the clamp is applied._
-
-## Tunnel-in-tunnel scenario with Magic Transit
-
-MSS clamping only affects TCP traffic. If, for example, you have a web server on your Magic Transit prefix, then the MSS clamp will take effect on the TCP data from direct server return traffic. However, be aware that you will have to take a different approach for any tunnels inside of your Magic Transit tunnel (tunnel-in-tunnel scenario).
-
-
-
-For example, if you have a Magic Transit GRE tunnel set up, and then another IPsec or GRE tunnel running from third-party devices on your premises, MSS clamp will have no impact on the outer packets of the encapsulated traffic. This is because MSS clamping affects only TCP traffic, and IPsec/GRE encapsulated traffic is IP. For this scenario, you will have to lower the MTU of the internal tunnel interface further, both for your ingress and egress traffic.
-
-
diff --git a/src/content/partials/magic-transit/mtu-mss/mtu-mss.mdx b/src/content/partials/magic-transit/mtu-mss/mtu-mss.mdx
index 2b6b5110a1ac544..f51fafcb006ce35 100644
--- a/src/content/partials/magic-transit/mtu-mss/mtu-mss.mdx
+++ b/src/content/partials/magic-transit/mtu-mss/mtu-mss.mdx
@@ -1,8 +1,15 @@
---
params:
+ - magicProduct?
- productName
---
+import { AnchorHeading, Render } from "~/components";
+import { Image } from 'astro:assets';
+import dsr from "~/assets/images/magic-transit/mtu-mss/dsr.png"
+import tunnel from "~/assets/images/magic-transit/mtu-mss/tcp-mss.png"
+import mss_ipsec from "~/assets/images/magic-transit/mtu-mss/ipsec-mss.png"
+
{props.productName} has operation requirements that customers should know about to make sure their network works as intended. Customers should pay particular attention to the maximum transmission unit (MTU) and maximum segment size (MSS) values. The incorrect configuration of these values might lead to loss of performance or inability to deliver data packets.
## MTU and MSS
@@ -17,7 +24,7 @@ One common misconception about MSS/MTU is that setting these values negatively i
Since {props.productName} uses encapsulation to deliver its services, it is also important to understand why MTU and MSS matter in this case.
-Encapsulation adds bytes to the packet, since we add a new IP header and (often) some sort of encapsulating header to every packet. For example, in the case of GRE for IPv4, we add 24 bytes - 20 bytes for the IPv4 header, and 4 bytes for the GRE tunnel header.
+Encapsulation adds bytes to the packet, since we add a new IP header and (often) some sort of encapsulating header to every packet. For example, in the case of GRE for IPv4, we add 24 bytes — 20 bytes for the IPv4 header, and 4 bytes for the GRE tunnel header.
A network interface which performs GRE encapsulation needs to account for the added overhead by reducing its MTU. Since the MTU maximum size is 1,500 bytes, for IPv4 this means that the MTU can be 1,476 bytes (the original 1,500 bytes minus the 24 bytes from the GRE encapsulation). This reduced MTU defines the maximum size of the IP packet that can be encapsulated by GRE.
@@ -29,7 +36,7 @@ Setting the `do not fragment` (DF) bit in the TCP header to `1` denotes that the
If you are experiencing issues with fragmentation and are unable to set an MSS clamp, Cloudflare can clear the `do not fragment` (DF) bit for you. When this option is enabled, Cloudflare fragments packets greater than 1,500 bytes, and the packets are reassembled on your infrastructure after decapsulation. This should be a last resort option. Contact your account team for more information.
-### Fragmentation in {props.productName}
+
Consider a UDP datagram of size 3,000 bytes (8 bytes for the UDP header + 2,992 bytes for the UDP data). To fit within a standard 1,500 bytes MTU, this UDP datagram would be fragmented across three IP packets as follows:
@@ -64,3 +71,53 @@ Refer to [MSS clamping recommendations](#mss-clamping-recommendations) for infor
:::caution
Cloudflare only recommends applying a MSS clamp to adjust the size of TCP packets. Changing the MTU of a network interface is not recommended as this might have unforeseen impacts on traffic.
:::
+
+{ props.magicProduct === "Magic Transit" && (
+ <>
+
+ Asymmetric routing is a common scenario especially with Magic Transit. Ingress traffic from the Internet enters the Cloudflare network, then traverses a GRE tunnel (MTU of 1,476 bytes), and egress traffic from the datacenter is sent via Direct Server Return (DSR) over the Internet (MTU of 1,500 bytes).
+ In an asymmetric scenario, we want to reduce the MSS value of packets sent by Magic Transit users to the Internet in order to reduce the size of packets sent from the Internet towards their network. To accomplish this, the configuration must be done either on the customer's end-hosts or through an MSS clamp on an intermediary device on the egress path of traffic leaving their network. How MSS values affect payload sizes on both routing paths is detailed below.
+
+ Key takeaway from the chart above: MSS clamping affects TCP packet payload sizes flowing in the opposite direction vs. where the clamp is applied.
+
+ MSS clamping only affects TCP traffic. If, for example, you have a web server on your Magic Transit prefix, then the MSS clamp will take effect on the TCP data from direct server return traffic. However, be aware that you will have to take a different approach for any tunnels inside of your Magic Transit tunnel (tunnel-in-tunnel scenario).
+
+ For example, if you have a Magic Transit GRE tunnel set up, and then another IPsec or GRE tunnel running from third-party devices on your premises, MSS clamp will have no impact on the outer packets of the encapsulated traffic. This is because MSS clamping affects only TCP traffic, and IPsec/GRE encapsulated traffic is IP. For this scenario, you will have to lower the MTU of the internal tunnel interface further, both for your ingress and egress traffic.
+
+
+ )
+}
+
+## MSS clamping recommendations
+
+### GRE tunnels as off-ramp
+
+{ props.magicProduct === "Magic WAN" && (
+ <>
+
+
+ )
+}
+
+{ props.magicProduct === "Magic Transit" && (
+ <>
+
+
+ )
+}
+
+### IPsec tunnels
+
+{ props.magicProduct === "Magic WAN" && (
+ <>
+
+
+ )
+}
+
+{ props.magicProduct === "Magic Transit" && (
+ <>
+
+
+ )
+}
diff --git a/src/content/partials/magic-transit/static-routes/static-routes3.mdx b/src/content/partials/magic-transit/static-routes.mdx
similarity index 65%
rename from src/content/partials/magic-transit/static-routes/static-routes3.mdx
rename to src/content/partials/magic-transit/static-routes.mdx
index b2cf97c0e7515d8..1403f00bd012406 100644
--- a/src/content/partials/magic-transit/static-routes/static-routes3.mdx
+++ b/src/content/partials/magic-transit/static-routes.mdx
@@ -1,11 +1,72 @@
---
params:
+ - magicProduct?
+ - productName
+ - BGPpath
+ - anycastURL
+ - trafficSteering
+ - magicWANecmp?
- createPath
- tunnelEndpoints
- - ipRanges
+ - ipRanges?
---
-import { GlossaryTooltip, Markdown, Render, TabItem, Tabs } from "~/components";
+import { GlossaryTooltip, Markdown, AnchorHeading, Render, TabItem, Tabs } from "~/components";
+
+:::note
+If you are connecting to Cloudflare via a [Direct CNI connection](/network-interconnect/express-cni/), refer to BGP peering to learn how to take advantage of this routing protocol. If not, continue reading.
+:::
+
+{props.productName} uses a static configuration to route your traffic through anycast tunnels from Cloudflare's global network to your locations.
+
+You must assign a route priority to each tunnel-subnet pair in your configuration, as follows:
+
+- Lower values have greater priority.
+- When the priority values for prefix entries match, Cloudflare uses equal-cost multi-path (ECMP) packet forwarding to route traffic. {props.magicWANecmp} For more on how Cloudflare uses ECMP packet forwarding, refer to Traffic steering.
+
+You can also create and edit static routes using the [Magic Static Routes API](/api/resources/magic_transit/subresources/routes/methods/list/).
+
+## Edge routing configuration example
+
+| Prefix | NextHop | Priority |
+| ----------------- | -------------- | -------- |
+| `10.10.10.100/24` | `TUNNEL_1_IAD` | `100` |
+| `10.10.10.100/24` | `TUNNEL_2_IAD` | `100` |
+| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` |
+| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` |
+| `10.10.10.100/24` | `TUNNEL_1_IAD` | `200` |
+| `10.10.10.100/24` | `TUNNEL_2_IAD` | `200` |
+| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` |
+| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` |
+
+Optionally, you can assign weights to distribute traffic more effectively among multiple tunnels. The weight values determine the proportion of traffic directed to each tunnel, with higher weights resulting in a greater share of traffic. The maximum weight value is `256`.
+
+In the example below, `TUNNEL_2_IAD` is likely to receive twice as much traffic as `TUNNEL_1_IAD`.
+
+| Prefix | NextHop | Priority | Weight |
+| ----------------- | -------------- | -------- | ------ |
+| `10.10.10.100/24` | `TUNNEL_1_IAD` | `100` | `64` |
+| `10.10.10.100/24` | `TUNNEL_2_IAD` | `100` | `128` |
+| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` | `192` |
+| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` | `255` |
+
+{ props.magicProduct === "Magic Transit" && (
+ <>
+
+ You must provide your prefixes and the tunnels that should be mapped to for Cloudflare to route your traffic from our global network to your data centers via anycast tunnels. Use the table below as reference.
+
+ The minimum advertising prefix is /24, but because Cloudflare uses anycast tunnels as an outer wrapper for your traffic, we can route prefixes within that /24 to different tunnel endpoints. For example, you can send x.x.x.0/29 to Data Center 1 and x.x.x.8/29 to Data Center 2. This is helpful when you operate in an environment with constrained IP resources.
+
+ )
+}
## Scoped routes for anycast GRE or IPsec tunnels
@@ -179,3 +240,4 @@ https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/routes/{route_i
```
+
diff --git a/src/content/partials/magic-transit/static-routes/static-routes1.mdx b/src/content/partials/magic-transit/static-routes/static-routes1.mdx
deleted file mode 100644
index f87b0e15b66e7a2..000000000000000
--- a/src/content/partials/magic-transit/static-routes/static-routes1.mdx
+++ /dev/null
@@ -1,47 +0,0 @@
----
-params:
- - productName
- - BGPpath
- - anycastURL
- - trafficSteering
- - magicWANecmp
----
-
-import { GlossaryTooltip, Markdown } from "~/components";
-
-:::note
-If you are connecting to Cloudflare via a [Direct CNI connection](/network-interconnect/express-cni/), refer to BGP peering to learn how to take advantage of this routing protocol. If not, continue reading.
-:::
-
-{props.productName} uses a static configuration to route your traffic through anycast tunnels from Cloudflare's global network to your locations.
-
-You must assign a route priority to each tunnel-subnet pair in your configuration, as follows:
-
-- Lower values have greater priority.
-- When the priority values for prefix entries match, Cloudflare uses equal-cost multi-path (ECMP) packet forwarding to route traffic. {props.magicWANecmp} For more on how Cloudflare uses ECMP packet forwarding, refer to Traffic steering.
-
-You can also create and edit static routes using the [Magic Static Routes API](/api/resources/magic_transit/subresources/routes/methods/list/).
-
-## Edge routing configuration example
-
-| Prefix | NextHop | Priority |
-| ----------------- | -------------- | -------- |
-| `10.10.10.100/24` | `TUNNEL_1_IAD` | `100` |
-| `10.10.10.100/24` | `TUNNEL_2_IAD` | `100` |
-| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` |
-| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` |
-| `10.10.10.100/24` | `TUNNEL_1_IAD` | `200` |
-| `10.10.10.100/24` | `TUNNEL_2_IAD` | `200` |
-| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` |
-| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` |
-
-Optionally, you can assign weights to distribute traffic more effectively among multiple tunnels. The weight values determine the proportion of traffic directed to each tunnel, with higher weights resulting in a greater share of traffic. The maximum weight value is `256`.
-
-In the example below, `TUNNEL_2_IAD` is likely to receive twice as much traffic as `TUNNEL_1_IAD`.
-
-| Prefix | NextHop | Priority | Weight |
-| ----------------- | -------------- | -------- | ------ |
-| `10.10.10.100/24` | `TUNNEL_1_IAD` | `100` | `64` |
-| `10.10.10.100/24` | `TUNNEL_2_IAD` | `100` | `128` |
-| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` | `192` |
-| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` | `255` |
diff --git a/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx b/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx
deleted file mode 100644
index c3302e122d5ca41..000000000000000
--- a/src/content/partials/magic-transit/static-routes/static-routes2-prefixes-smaller-24.mdx
+++ /dev/null
@@ -1,15 +0,0 @@
----
-{}
-
----
-
-## Map route prefixes smaller than `/24`
-
-You must provide your prefixes and the tunnels that should be mapped to for Cloudflare to route your traffic from our global network to your data centers via anycast tunnels. Use the table below as reference.
-
-| Prefix | NextHop |
-| ----------------- | -------------- |
-| `103.21.244.0/29` | `TUNNEL_1_IAD` |
-| `103.21.244.8/29` | `TUNNEL_2_ATL` |
-
-The minimum advertising prefix is `/24`, but because Cloudflare uses anycast tunnels as an outer wrapper for your traffic, we can route prefixes within that `/24` to different tunnel endpoints. For example, you can send `x.x.x.0/29` to Data Center 1 and `x.x.x.8/29` to Data Center 2. This is helpful when you operate in an environment with constrained IP resources.
diff --git a/src/content/partials/magic-transit/tunnel-health/update-tunnel-health-checks-frequency.mdx b/src/content/partials/magic-transit/tunnel-health/update-tunnel-health-checks-frequency.mdx
index 92340937b913979..4ca32c025eb09ce 100644
--- a/src/content/partials/magic-transit/tunnel-health/update-tunnel-health-checks-frequency.mdx
+++ b/src/content/partials/magic-transit/tunnel-health/update-tunnel-health-checks-frequency.mdx
@@ -1,24 +1,39 @@
---
params:
+ - magicProduct?
- productName
- healthChecksUrl
- addTunnelsPath
- - connectorExtraInfo
- - connectorNote
- - connectorTitle1
- - connectorTitle2
- - connectorSteps
---
import {AnchorHeading, GlossaryTooltip, Markdown, TabItem, Tabs } from "~/components";
-By default, Cloudflare servers send health checks to each GRE, CNI, or IPsec tunnel endpoint you configure to receive traffic from {props.productName}. {props.connectorExtraInfo}
+By default, Cloudflare servers send health checks to each GRE, CNI, or IPsec tunnel endpoint you configure to receive traffic from {props.productName}.
+
+{ props.magicProduct === "Magic WAN" && (
+ <>
+ For Magic WAN Connector, health checks are sent to IPsec tunnel endpoints.
+
+ )
+}
You can configure the health check frequency via the dashboard or [the API](/api/resources/magic_transit/subresources/gre_tunnels/methods/update/) to suit your use case. For example, if you are connecting a lower-traffic site for which you do not need immediate failover and would rather receive a lower volume of health check traffic, you should set the frequency to `low`. On the other hand, if you are connecting a site that is extremely sensitive to any issues, and you want a more proactive failover at the earliest sign of a potential problem, you should set this to `high`.
-Available options are `low`, `mid`, and `high`.
+Available options are `low`, `mid`, and `high`.
+
+{ props.magicProduct === "Magic WAN" && (
+ <>
+ To configure health checks frequency in Magic WAN Connector, refer to Configure Connector
+
+ )
+}
-{ props.connectorTitle1 && }
+{ props.magicProduct === "Magic WAN" && (
+ <>
+
+
+ )
+}
@@ -45,6 +60,10 @@ https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/gre_tunnels/{tu
-{ props.connectorTitle2 && }
-
-
+{ props.magicProduct === "Magic WAN" && (
+ <>
+
+ - Log in to the Cloudflare dashboard and select your account.
- Go to Magic WAN {'>'} Sites.
- Select your site {'>'} Edit.
- In Network {'>'} WAN configuration {'>'} select your WAN {'>'} Edit.
- Change the Health check rate to your desire rate.
- Select Save.
+
+ )
+}
\ No newline at end of file
diff --git a/src/content/partials/magic-wan/analytics/overview.mdx b/src/content/partials/magic-wan/analytics/overview.mdx
new file mode 100644
index 000000000000000..58f01daf3a974df
--- /dev/null
+++ b/src/content/partials/magic-wan/analytics/overview.mdx
@@ -0,0 +1,69 @@
+---
+params:
+ - magicProduct?
+ - productName
+ - analyticsAnchorHeading
+ - networkAnalyticsURL
+ - traceRoutes
+ - graphQl
+---
+
+import { AnchorHeading } from "~/components";
+
+{props.productName} customers can follow the troubleshooting steps listed below to gather information at the beginning of a troubleshooting process, then move to more detailed network data collection and analysis to identify the root cause of a problem.
+
+
+{ props.magicProduct === "Magic WAN" && (
+ <>
+
+
+ )
+}
+- Analyze network traffic data over time in {props.productName} Network Analytics
+- Perform more detailed troubleshooting with:
+ - [Traceroutes](#traceroutes)
+ - [Packet captures](#packet-captures)
+
+{ props.magicProduct === "Magic WAN" && (
+ <>
+
+ Magic WAN Site Analytics provides an overview of the connectivity status and traffic analytics of all Magic WAN sites. This is a great place to start if you receive an alert, need to begin the Magic WAN troubleshooting process, or are performing routine monitoring.
+ Refer to Magic WAN Site Analytics to learn more.
+
+ )
+}
+
+
+
+Network Analytics provides detailed analytics on {props.productName} traffic over time. Customers can filter data on specific traffic characteristics and view traffic analytics over time.
+
+Refer to {props.productName} Network Analytics to learn more.
+
+## Traceroutes
+
+Traceroutes provide a hop by hop breakdown of the Internet path network traffic follows as it traverses from Cloudflare's network to a customer's network.
+
+Refer to Traceroutes to learn more.
+
+## Packet captures
+
+Packet captures allow customers to analyze the raw packet data that a customer is sending and receiving from Cloudflare's network.
+
+Refer to [packet captures](/magic-firewall/packet-captures/) to learn more.
+
+## Query Analytics with GraphQL
+
+GraphQL Analytics provides customers with a GraphQL API that they can query to receive raw JSON data of their Magic WAN traffic analytics. This data can be ingested into a SIEM or other tool and analyzed further.
+
+