cloudflare · marciocloudflare · Feb 12, 2025 · Feb 11, 2025 · Feb 11, 2025 · Feb 11, 2025
@@ -9,34 +9,15 @@ description: Use Magic Transit's different analytic options for an overview of
 
 ---
 
-Magic Transit 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.
-
-- Analyze network traffic data over time in [Magic Transit Network Analytics](#magic-transit-network-analytics)
-- Perform more detailed troubleshooting with:
-  - [Traceroutes](#traceroutes)
-  - [Packet captures](#packet-captures)
-
-## Magic Transit Network Analytics
-
-Network Analytics provides detailed analytics on Magic Transit traffic over time. Customers can filter data on specific traffic characteristics and view traffic analytics over time.
-
-Refer to [Magic Transit Network Analytics](/magic-transit/analytics/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](/magic-transit/analytics/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.
-
-- [Querying Magic Transit tunnel bandwidth analytics with GraphQL](/magic-transit/analytics/query-bandwidth/)
-- [Querying Magic Transit tunnel health check results with GraphQL](/magic-transit/analytics/query-tunnel-health/)
+import { Render } from "~/components";
+
+<Render file="analytics/overview"
+	product="magic-wan"
+	params={{
+		productName: "Magic Transit",
+		analyticsAnchorHeading: "#magic-transit-network-analytics",
+		networkAnalyticsURL: "/magic-transit/analytics/network-analytics/",
+		traceRoutes: "/magic-transit/analytics/traceroutes/",
+		graphQl: "/magic-transit/"
+		 }}
+/>
@@ -12,8 +12,15 @@ description: Magic Transit uses a static configuration to route your traffic
 
 import { Render } from "~/components"
 
-<Render file="static-routes/static-routes1" params={{ productName: "Magic Transit", BGPpath: "/magic-transit/how-to/bgp-peering/", anycastURL: "/magic-transit/reference/tunnels/", trafficSteering: "/magic-transit/reference/traffic-steering/", magicWANecmp: "" }} />
-
-<Render file="static-routes/static-routes2-prefixes-smaller-24" />
-
-<Render file="static-routes/static-routes3" params={{ createPath: "Magic Transit > Configuration", tunnelEndpoints: "/magic-transit/how-to/configure-tunnels/", ipRanges: " " }} />
+<Render
+	file="static-routes"
+	params={{
+		magicProduct: "Magic Transit",
+		productName: "Magic Transit",
+		BGPpath: "/magic-transit/how-to/bgp-peering/",
+		anycastURL: "/magic-transit/reference/tunnels/",
+		trafficSteering: "/magic-transit/reference/traffic-steering/",
+		createPath: "Magic Transit > Configuration",
+		tunnelEndpoints: "/magic-transit/how-to/configure-tunnels/"
+	}}
+/>
@@ -9,12 +9,7 @@ import { Render } from "~/components";
 	file="tunnel-health/update-tunnel-health-checks-frequency"
 	params={{
 		productName: "Magic Transit.",
-		connectorExtraInfo: "",
 		healthChecksUrl: "/magic-transit/reference/tunnel-health-checks/",
-		addTunnelsPath: "/magic-transit/how-to/configure-tunnels/#add-tunnels",
-		connectorNote: "",
-		connectorTitle1: "",
-		connectorTitle2: "",
-		connectorSteps: "",
+		addTunnelsPath: "/magic-transit/how-to/configure-tunnels/#add-tunnels"
 	}}
 />
@@ -7,18 +7,10 @@ sidebar:
 
 import { Render } from "~/components";
 
-<Render file="mtu-mss/mtu-mss" params={{ productName: "Magic Transit" }} />
-
-## MSS with Magic Transit and Direct Server Return
-
-<Render file="mtu-mss/mt-dsr" />
-
-## MSS clamping recommendations
-
-### GRE tunnels as off-ramp
-
-<Render file="mtu-mss/mss-clamping-gre" />
-
-### IPsec tunnels
-
-<Render file="mtu-mss/mss-clamping-ipsec" />
+<Render
+	file="mtu-mss"
+	params={{
+		magicProduct: "Magic Transit",
+		productName: "Magic Transit"
+		}}
+/>
@@ -9,41 +9,15 @@ description: Use Magic WAN's different analytic options for an overview of the
 
 ---
 
-Magic WAN 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.
-
-- Overview in [Magic WAN Site Analytics](#magic-wan-site-analytics)
-- Analyze network traffic data overtime in [Magic WAN Network Analytics](#magic-wan-network-analytics)
-- Perform more detailed troubleshooting with:
-  - [Traceroutes](#traceroutes)
-  - [Packet captures](#packet-captures)
-
-## Magic WAN Site Analytics
-
-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](/magic-wan/analytics/site-analytics/) to learn more.
-
-## Magic WAN Network Analytics
-
-Network Analytics provides detailed analytics on Magic WAN traffic over time. Customers can filter data on specific traffic characteristics and view traffic analytics over time.
-
-Refer to [Magic WAN Network Analytics](/magic-wan/analytics/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](/magic-wan/analytics/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.
-
-- [Querying Magic WAN tunnel bandwidth analytics with GraphQL](/magic-wan/analytics/query-bandwidth/)
-- [Querying Magic WAN tunnel health check results with GraphQL](/magic-wan/analytics/query-tunnel-health/)
+import { Render } from "~/components";
+
+<Render file="analytics/overview"
+	params={{
+		magicProduct: "Magic WAN",
+		productName: "Magic WAN",
+		analyticsAnchorHeading: "#magic-wan-network-analytics",
+		networkAnalyticsURL: "/magic-wan/analytics/network-analytics/",
+		traceRoutes: "/magic-wan/analytics/traceroutes/",
+		graphQl: "/magic-wan/"
+		 }}
+/>
@@ -11,14 +11,9 @@ import { Render } from "~/components";
 	file="tunnel-health/update-tunnel-health-checks-frequency"
 	product="magic-transit"
 	params={{
+		magicProduct: "Magic WAN",
 		productName: "Magic WAN",
-		connectorExtraInfo: "For Magic WAN Connector, health checks are sent to IPsec tunnel endpoints.",
 		healthChecksUrl: "/magic-wan/reference/tunnel-health-checks/",
-		addTunnelsPath:
-			"/magic-wan/configuration/manually/how-to/configure-tunnels/#add-tunnels",
-		connectorNote: "<br /> <br /> To configure health checks frequency in Magic WAN Connector, refer to [Configure Connector](#configure-connector).",
-		connectorTitle1: "Manual configuration",
-		connectorTitle2: "Configure Connector",
-		connectorSteps: "<ol><li>Log in to the <a href='https://dash.cloudflare.com/'>Cloudflare dashboard</a> and select your account.</li><li>Go to **Magic WAN** > **Sites**.</li><li>Select your site > **Edit**.</li><li>In **Network** > **WAN configuration** > select your WAN > **Edit**.</li><li>Change the **Health check rate** to your desire rate.</li><li>Select **Save**.</li></ol>",
+		addTunnelsPath: "/magic-wan/configuration/manually/how-to/configure-tunnels/#add-tunnels"
 	}}
 />
@@ -11,9 +11,20 @@ description: Magic WAN uses a static configuration to route your traffic through
 
 import { Render } from "~/components"
 
-<Render file="static-routes/static-routes1" product="magic-transit" params={{ productName: "Magic WAN", BGPpath: "/magic-wan/configuration/manually/how-to/bgp-peering/", anycastURL: "/magic-wan/reference/tunnels/", trafficSteering: "/magic-wan/reference/traffic-steering/", magicWANecmp: "The maximum number of routes you can have with the same priority is 64." }} />
-
-<Render file="static-routes/static-routes3" product="magic-transit" params={{ createPath: "Magic WAN > Configuration", tunnelEndpoints: "/magic-wan/configuration/manually/how-to/configure-tunnels/", ipRanges: "<br /> 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/).<br>" }} />
+<Render
+	file="static-routes"
+	product="magic-transit"
+	params={{
+		productName: "Magic WAN",
+		BGPpath: "/magic-wan/configuration/manually/how-to/bgp-peering/",
+		anycastURL: "/magic-wan/reference/tunnels/",
+		trafficSteering: "/magic-wan/reference/traffic-steering/",
+		magicWANecmp: "The maximum number of routes you can have with the same priority is 64.",
+		createPath: "Magic WAN > Configuration",
+		tunnelEndpoints: "/magic-wan/configuration/manually/how-to/configure-tunnels/",
+		ipRanges: "<br /> 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/). <p></p>"
+	}}
+/>
 
 ## Next steps
 

@@ -8,17 +8,10 @@ sidebar:
 import { Render } from "~/components";
 
 <Render
-	file="mtu-mss/mtu-mss"
+	file="mtu-mss"
 	product="magic-transit"
-	params={{ productName: "Magic WAN" }}
-/>
-
-## MSS clamping recommendations
-
-### GRE tunnels as off-ramp
-
-<Render file="mtu-mss/mss-clamping-gre" />
-
-### IPsec tunnels
-
-<Render file="mtu-mss/mss-clamping-ipsec" />
+	params={{
+		magicProduct: "Magic WAN",
+		productName: "Magic WAN"
+		}}
+/>
diff --git a/...artials/magic-transit/mtu-mss/mtu-mss.mdx → ...ontent/partials/magic-transit/mtu-mss.mdx b/...artials/magic-transit/mtu-mss/mtu-mss.mdx → ...ontent/partials/magic-transit/mtu-mss.mdx
@@ -1,8 +1,15 @@
 ---
 params:
+  - magicProduct?
   - productName
 ---
 
+import { AnchorHeading } 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}
+<AnchorHeading depth={3} title={`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,84 @@ 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" && (
+  <>
+    <AnchorHeading title="MSS with Magic Transit and Direct Server Return" depth={2} />
+		<p>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).</p>
+		<p>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.</p>
+		<Image src={dsr} alt="A diagram showing how MSS works with Magic Transit and Direct Server Return." />
+		<p><em>Key takeaway from the chart above: MSS clamping affects TCP packet payload sizes flowing in the opposite direction vs. where the clamp is applied.</em></p>
+		<AnchorHeading title="Tunnel-in-tunnel scenario with Magic Transit" depth={2} />
+		<p>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).</p>
+		<Image src={tunnel} alt="A diagram showing where the MSS clamp goes with TCP traffic." />
+		<p>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.</p>
+		<Image src={mss_ipsec} alt="A diagram showing where the MSS clamp goes with an IPsec tunnel inside a GRE tunnel." />
+  </>
+  )
+}
+
+## MSS clamping recommendations
+
+### GRE tunnels as off-ramp
+
+{ props.magicProduct === "Magic WAN" && (
+  <>
+    <p>The MSS value depends on how your network is set up.</p>
+		<ul><li><strong>On your Edge router:</strong> Apply the clamp to the GRE tunnel internal interface (meaning where the egress traffic will traverse). The MSS clamp should be 1,436 bytes. This may be done automatically once the tunnel is configured, but it depends on your devices.</li></ul>
+  </>
+  )
+}
+
+{ props.magicProduct === "Magic Transit" && (
+  <>
+    <p>The MSS value depends on how your network is set up.</p>
+		<ul>
+				<li><strong>Magic Transit ingress-only traffic (DSR):</strong>
+						<ul>
+								<li><strong>On your edge router transit ports:</strong> Apply a TCP MSS clamp with a maximum of 1,436 bytes.</li>
+								<li><strong>On any IPsec/GRE tunnels with third parties on your Magic Transit prefix:</strong> Apply the MSS clamp on the internal tunnel interface (most likely on a separate firewall behind the GRE-terminating router) to reduce the current value by 24 bytes.</li>
+						</ul>
+				</li>
+				<li><strong>For Magic Transit ingress + egress traffic:</strong>
+						<ul>
+								<li><strong>On the Magic Transit GRE tunnel internal interface:</strong> Meaning where the Magic Transit egress traffic will traverse. This may be done automatically once the tunnel is configured but it depends on your devices. The TCP MSS clamp should be 1,436 bytes maximum.</li>
+								<li><strong>On any IPsec/GRE tunnels with third parties on your Magic Transit prefix:</strong> On the internal tunnel interface (most likely on a separate firewall behind the GRE-terminating router) to reduce its current value by 24 bytes.</li>
+						</ul>
+				</li>
+		</ul>
+  </>
+  )
+}
+
+
+### IPsec tunnels
+
+{ props.magicProduct === "Magic WAN" && (
+  <>
+    <p>For IPsec tunnels, the value you need to specify depends on how your network is set up. The MSS clamping value will be lower than for GRE tunnels, however, since the physical interface will see IPsec-encrypted packets, not TCP packets, and MSS clamping will not apply to those.</p>
+		<ul><li><strong>On your Edge router</strong>: Apply this on your Magic WAN IPsec tunnel internal interface (meaning where the Magic WAN egress traffic will traverse). This may be done automatically once the tunnel is configured but it depends on your devices. TCP MSS clamp should be 1,360 bytes maximum.</li></ul>
+  </>
+  )
+}
+
+{ props.magicProduct === "Magic Transit" && (
+  <>
+    <p>For IPsec tunnels, the value you need to specify depends on how your network is set up. The MSS clamping value will be lower than for GRE tunnels, however, since the physical interface will see IPsec-encrypted packets, not TCP packets, and MSS clamping will not apply to those.</p>
+		<ul>
+				<li><strong>Magic Transit ingress-only traffic (DSR):</strong>
+						<ul>
+								<li><strong>On your edge router transit ports:</strong> TCP MSS clamp should be 1,360 bytes maximum.</li>
+								<li><strong>On any IPsec/GRE tunnels with third parties on your Magic Transit prefix:</strong> on the internal tunnel interface (most likely on a separate firewall behind the GRE-terminating router) to reduce its current value by 140 bytes.</li>
+						</ul>
+				</li>
+				<li><strong>Magic Transit ingress + egress traffic:</strong>
+						<ul>
+								<li><strong>On your edge router:</strong> Apply this on your Magic Transit IPsec tunnel internal interface (that is, where the Magic Transit egress traffic will traverse). This may be done automatically once the tunnel is configured but it depends on your devices. TCP MSS clamp should be 1,360 bytes maximum.</li>
+								<li><strong>On any IPsec/GRE tunnels with third parties on your Magic Transit prefix:</strong> on the internal tunnel interface (most likely on a separate firewall behind the IPsec-terminating device in your premises) to reduce its current value by 140 bytes.</li>
+						</ul>
+				</li>
+		</ul>
+  </>
+  )
+}