Clarifying anycast on egress (#18702)

* Clarifying anycast on egress Adds explicit messaging to clarify that the egress traffic reaches Cloudflare at an anycast location where it will exit to the connectivity available in said location to the internet * Update src/content/docs/magic-transit/reference/egress.mdx --------- Co-authored-by: marciocloudflare <[email protected]>
cloudflare · Dec 12, 2024 · 958a3f4 · 958a3f4
1 parent e6631e0
commit 958a3f4
Showing 1 changed file with 1 addition and 0 deletions.
diff --git a/src/content/docs/magic-transit/reference/egress.mdx b/src/content/docs/magic-transit/reference/egress.mdx
@@ -13,3 +13,4 @@ If you have implemented Magic Transit with egress traffic, below is a list of te
 - You may need to configure multiple GRE/IPsec tunnels as a way to load-share traffic sent to the Internet via Cloudflare. You can achieve this by applying two different PBR. Thus, traffic sourced from one IP/subnet is routed via one tunnel, and traffic from another IP/subnet is sent out via a different tunnel.
 - Your Magic Firewall rules will apply in both directions. Ensure that your Magic Firewall rules are set up for your intended traffic flows, both in and out.
 - If using Magic Transit egress then we recommend you set your GRE or IPSEC tunnel health check configuration to [bidirectional](/magic-transit/how-to/configure-tunnels/#add-tunnels), so that Cloudflare health checks are in-sync with the [data plane](https://en.wikipedia.org/wiki/Forwarding_plane) traffic flow.
+- Once your traffic is configured to egress through the GRE/IPsec tunnel, it is encapsulated and sent to a Cloudflare anycast endpoint. Your ISP then routes the encapsulated traffic to the nearest available Cloudflare point of presence (PoP), where it exits to the Internet via Cloudflare's connectivity options at that location.