**L3/4 DDoS** > **Network-layer DDoS Protection**.
+3. Select **Deploy a DDoS override**.
+4. In **Set scope**, specify if you wish to apply the override to all incoming packets or to a subset of the packets.
+5. If you are creating an override for a subset of the incoming packets, define the [custom expression](/ddos-protection/managed-rulesets/network/override-expressions/) that matches the incoming packets you wish to target in the override, using either the Rule Builder or the Expression Editor.
+6. Select **Next**.
+7. Depending on what you wish to override, refer to the following sections (you can perform both configurations on the same override):
+
+ 8. Select **Next**.
+ 9. Enter a name for your override in **Execution name**.
+ 10. To always apply a given action for all the rules in the ruleset, select an action in **Ruleset action**.
+ 11. To set the sensitivity level for all the rules in the ruleset, select a value in **Ruleset sensitivity**.
+
+
+
+ 12. Search for the rules you wish to override using the available filters. You can search for tags.
+ 13. To override a single rule, select the desired value for a field in the displayed dropdowns next to the rule.
+
+ To configure more than one rule, select the rules using the row checkboxes and update the fields for the selected rules using the dropdowns displayed before the table. You can also configure all the rules with a given tag. For more information, refer to [Configure rules in bulk in a managed ruleset](/waf/managed-rules/deploy-zone-dashboard/#configure-rules-in-bulk-in-a-managed-ruleset).
+ 14. Select **Next**.
+ 15. Enter a name for your override in **Execution name**.
+
+
+ :::note[Notes]
+
+ - Tag and rule overrides have priority over ruleset overrides.
+ -
+ :::
+
+8. To save and deploy the override, select **Deploy**. If you are not ready to deploy your override, select **Save as Draft**.
\ No newline at end of file
diff --git a/src/content/partials/networking-services/magic-transit/advertise-prefixes.mdx b/src/content/partials/networking-services/magic-transit/advertise-prefixes.mdx
new file mode 100644
index 000000000000000..9cb968d436d224c
--- /dev/null
+++ b/src/content/partials/networking-services/magic-transit/advertise-prefixes.mdx
@@ -0,0 +1,19 @@
+---
+{}
+---
+
+import { GlossaryTooltip } from "~/components";
+
+Once pre-flight checks are completed, Cloudflare will unlock your prefixes for you to [advertise via the dashboard, API or BGP](/magic-transit/how-to/advertise-prefixes/) at a time of your choosing. Refer to [Dynamic advertisement best practices](/byoip/concepts/dynamic-advertisement/best-practices/) to learn more about advertising prefixes.
+
+If you are using a Cloudflare IP, you do not need to advertise your prefixes.
+
+:::caution
+You must [put the appropriate MSS clamps](#set-maximum-segment-size) in place before [routing](https://www.cloudflare.com/learning/network-layer/what-is-routing/) changes are made. Failure to apply an MSS clamp can result in dropped packets and hard-to-debug connectivity issues.
+
+Also, when using [Cloudflare Network Interconnect](/magic-transit/network-interconnect/) with Magic Transit you must set the following MSS clamp sizes to accommodate additional overhead:
+- GRE tunnels over Classic CNI: 1476 bytes
+- Direct CNI / Classic CNI with a maximum transmission unit (MTU) size of 1500 bytes handoff does not require an MSS clamp.
+
+MSS clamps are used to backhaul data from the data center where traffic is ingested (close to the end user) to the facility with the CNI link.
+:::
\ No newline at end of file
diff --git a/src/content/partials/networking-services/magic-transit/cloudflare-ips.mdx b/src/content/partials/networking-services/magic-transit/cloudflare-ips.mdx
new file mode 100644
index 000000000000000..df9382e92590076
--- /dev/null
+++ b/src/content/partials/networking-services/magic-transit/cloudflare-ips.mdx
@@ -0,0 +1,21 @@
+---
+params:
+ - mtLpCreateTunnel
+ - mtLpStaticRoute
+ - mtLpBgpPeering
+
+---
+
+import { GlossaryTooltip } from "~/components"
+
+To use Magic Transit you need to own a publicly routable IP address block with a minimum size of `/24`. If you do not own a `/24` address block, you can use Magic Transit with a Cloudflare-owned IP address. This option is helpful for users who do not meet the `/24` prefix length requirements or who want to protect a smaller network.
+
+To protect your network using a Cloudflare IP address, contact your account manager. After receiving your IP address, you will need to:
+
+- Create a tunnel.
+- Set up static routes or BGP peering.
+- [Configure health checks](/magic-transit/network-health/run-endpoint-health-checks/).
+- Confirm [tunnel](/magic-transit/network-health/update-tunnel-health-checks/) and endpoint health checks were properly configured.
+- Update your infrastructure at your own pace to use the allocated Cloudflare IPs.
+
+When you use a Cloudflare-owned IP space, you do not need a Letter of Agency (LOA). When using Cloudflare-leased IPs, [Magic Transit Egress](/magic-transit/reference/egress/) is automatically enabled — that is, your egress traffic will also be destined to Cloudflare instead of the Internet. Because of this, you will need to set up policy-based routing on your end to make sure that return traffic is properly routed.
\ No newline at end of file
diff --git a/src/content/partials/networking-services/magic-transit/get-started.mdx b/src/content/partials/networking-services/magic-transit/get-started.mdx
new file mode 100644
index 000000000000000..e3e335e54d1fd37
--- /dev/null
+++ b/src/content/partials/networking-services/magic-transit/get-started.mdx
@@ -0,0 +1,152 @@
+---
+params:
+ - magicWord
+---
+
+import { AnchorHeading, Aside, GlossaryTooltip, Markdown, Render } from "~/components";
+
+{ props.magicWord === "Magic Transit" && (
+ <>
+ Before you can begin using Magic Transit, be sure to complete the onboarding steps below. Cloudflare can significantly accelerate this timeline during active-attack scenarios.
+
+ )
+}
+
+## Scope your configuration
+
+Magic Transit is not a self-serve product, and as such you need to start by [engaging with our team](https://www.cloudflare.com/network-services/products/magic-transit/) to assess the scope of your needs and a timeline to implement Magic Transit. This is where we assess specific requirements such as your prefix count and how fast you can go through the necessary steps to implement Magic Transit on your network.
+
+## IPs
+
+{ props.magicWord === "Magic Transit" && (
+ <>
+
+
+ )
+}
+
+{ props.magicWord === "Learning Path" && (
+ <>
+
+
+ )
+}
+
+## Verify router compatibility
+
+Magic Transit relies on anycast tunnels to transmit packets from Cloudflare's global network to your origin network.
+
+The routers at your tunnel endpoints must meet the following requirements to ensure compatibility with Magic Transit.
+
+- Support GRE tunnels (or IPsec if GRE is not available).
+- Allow configuration of at least one tunnel per Internet service provider (ISP).
+- Support maximum segment size (MSS) clamping.
+- Support asymmetric traffic flow (for ingress-only Magic Transit).
+
+## Draft Letter of Agency
+
+Draft a [Letter of Agency (LOA)](/byoip/concepts/loa/) — sometimes referred to as a Letter of Authorization — that identifies the prefixes you want to advertise and gives Cloudflare permission to announce them. The LOA is required by Cloudflare's transit providers so they can accept the routes Cloudflare advertises on your behalf.
+
+If you are an Internet service provider (ISP) and advertising prefixes on behalf of a customer, an LOA is required for the ISP and for the customer.
+
+If you are using a [Cloudflare IP address](#ips), you do not need to submit an LOA.
+
+:::note
+The LOA must be a PDF. Transit providers may reject the LOA if it is a JPG or PNG.
+:::
+
+### Example of a Letter of Agency
+
+
+
+## Verify IRR entries
+
+Verify that your Internet Routing Registry (IRR) entries match your corresponding origin autonomous system numbers (ASNs) to ensure Magic Transit routes traffic to the correct autonomous systems (AS). For guidance, refer to [Verify IRR entries](/byoip/concepts/irr-entries/best-practices/#verify-an-irr-entry).
+
+If you are using a [Cloudflare IP](#ips), you do not need to verify your IRR entries.
+
+### Optional: RPKI check for prefix validation
+
+You can also use the Resource Public Key Infrastructure (RPKI) as an additional option to validate your prefixes. RPKI is a [security framework method](https://blog.cloudflare.com/rpki/) that associates a route with an autonomous system. It uses cryptography to validate the information before being passed onto the routers.
+
+If you operate a network (ISP, cloud provider, enterprise, and others.), using RPKI ensures that your IP prefixes are correctly recognized. This prevents service disruptions and protects your brand's reputation. Without RPKI, attackers could announce your IP space, misdirect your traffic, and potentially harm your business.
+
+To check your prefixes, you can use [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator).
+
+## Set maximum segment size
+
+
+
+### MSS clamping recommendations
+
+#### GRE tunnels as off-ramp
+
+
+
+#### IPsec tunnels
+
+
+
+:::caution[Important]
+Refer to your device documentation to check if it sets IPsec MSS clamping automatically. If that is not the case and you are using IPsec inside GRE, you have to set MSS clamp manually.
+:::
+
+Refer to [Maximum transmission unit and maximum segment size](/magic-transit/reference/mtu-mss/) for more details.
+
+#### Clear Do not fragment (DF)
+
+If you are unable to set the MSS on your physical interfaces to a value lower than 1500 bytes, you can choose to clear the `do not fragment` bit in the IP header. When this option is enabled, Cloudflare fragments [packets](https://www.cloudflare.com/learning/network-layer/what-is-a-packet/) greater than 1500 bytes, and the packets are reassembled on your infrastructure after decapsulation. In most environments, enabling this option does not have a significant impact on traffic throughput.
+
+To enable this option for your network, contact your account team.
+
+Refer to [Maximum transmission unit and maximum segment size](/magic-transit/reference/mtu-mss/) for more details.
+
+## Follow router vendor guidelines
+
+
+
+
+{ props.magicWord === "Magic Transit" && (
+ <>
+
+ Configure the tunnelson both the Cloudflare side and your router side to connect to your origin infrastructure.
+
+
+ Configure static routes or BGP peeringto route traffic from Cloudflare's global network to your locations.
+
+
+ After setting up your tunnels and routes, Cloudflare validates tunnel connectivity, tunnel and endpoint health checks, Letter of Agency (LOA), Internet Routing Registry (IRR), and maximum segment size (MSS) configurations. Configurations for Cloudflare global network are applied and take around one day to rollout.
+
+
+
+
+
+ )
+}
+
+{ props.magicWord === "Learning Path" && (
+ <>
+
+ If you want to use BGP for prefix advertisement control then you need to let the account team know the IPs and ASN for your customer premises equipment (CPE) to use for the BGP peerings. You should allow around five working days for Cloudflare to add this to our Route Reflectors.
+
+ )
+}
+
diff --git a/src/content/partials/networking-services/magic-transit/mtu-mss/mss-clamping-ipsec.mdx b/src/content/partials/networking-services/magic-transit/mtu-mss/mss-clamping-ipsec.mdx
index 06eaefc758ee206..41718669c0cf952 100644
--- a/src/content/partials/networking-services/magic-transit/mtu-mss/mss-clamping-ipsec.mdx
+++ b/src/content/partials/networking-services/magic-transit/mtu-mss/mss-clamping-ipsec.mdx
@@ -6,7 +6,7 @@ For IPsec tunnels, the value you need to specify depends on how your network is
- **Magic Transit ingress-only traffic (DSR):**
- - **On your edge router transit ports**: TCP MSS clamp should be 1,360 bytes maximum.
+ - **On your edge router transit ports**: TCP MSS clamp should be 1,436 bytes maximum.
- **On any IPsec/GRE tunnels with third parties on your Magic Transit prefix**: on the internal tunnel interface (most likely on a separate firewall behind the GRE-terminating router) to reduce its current value by 140 bytes.
- **Magic Transit ingress + egress traffic:**
diff --git a/src/content/partials/networking-services/prerequisites/maximum-segment-size.mdx b/src/content/partials/networking-services/prerequisites/maximum-segment-size.mdx
index faf0b52e5961bc7..cf7ec039172f4a2 100644
--- a/src/content/partials/networking-services/prerequisites/maximum-segment-size.mdx
+++ b/src/content/partials/networking-services/prerequisites/maximum-segment-size.mdx
@@ -5,4 +5,4 @@ params:
import { Markdown, Render } from "~/components";
-Cloudflare {props.productName} uses tunnels to deliver [packets](https://www.cloudflare.com/learning/network-layer/what-is-a-packet/) from our global network to your data centers. Cloudflare encapsulates these packets adding new headers. You must account for the space consumed by these headers when configuring the maximum transmission unit (MTU) and maximum segment size (MSS) values for your network.
+Before enabling {props.productName}, you must make sure that you set up the maximum segment size on your network. Cloudflare {props.productName} uses tunnels to deliver [packets](https://www.cloudflare.com/learning/network-layer/what-is-a-packet/) from our global network to your data centers. Cloudflare encapsulates these packets adding new headers. You must account for the space consumed by these headers when configuring the maximum transmission unit (MTU) and maximum segment size (MSS) values for your network.
diff --git a/src/pages/learning-paths.astro b/src/pages/learning-paths.astro
index 60b8049ef4072be..6b9543019fa21e1 100644
--- a/src/pages/learning-paths.astro
+++ b/src/pages/learning-paths.astro
@@ -37,6 +37,7 @@ const icons = {
"Application security": iconToSvg("ddos-protection"),
"Cloudflare One": iconToSvg("cloudflare-one"),
"Developer platform": iconToSvg("workers"),
+ "Network security": iconToSvg("magic-transit"),
};
---