Skip to content

[Magic] Traffic scoping priorities #21879

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 22, 2025
Merged

[Magic] Traffic scoping priorities #21879

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
badb157
added details over geo scoping priority
marciocloudflare Apr 22, 2025
a903437
refined text
marciocloudflare Apr 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 12 additions & 4 deletions src/content/partials/networking-services/reference/traffic-steering.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,6 +74,8 @@ The priority value for static routes is directly configured as part of the route
| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` |
| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` |

In the example above, tunnels with priority of `100` will be preferred to tunnels with priority of `200` since lower numbers have greater priority.

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`.
Expand All @@ -85,6 +87,8 @@ In the example below, `TUNNEL_2_IAD` is likely to receive twice as much traffic
| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` | `192` |
| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` | `255` |

Aside from priority, scoping static routes to specific geographic regions will also impact how traffic is steered. Refer to [Scoping routes to specific regions](#scoping-routes-to-specific-regions) for more details.

### Set priority for BGP routes

When BGP advertises a route, it is automatically added to the Magic routing table with a default priority of `100` which applies to [all regions](#scoping-routes-to-specific-regions). However, if a static route exists with the same prefix and priority, the static route will always take precedence over the BGP route. You will have to set a different priority for static routes, to be more or less than `100`, depending on which you want to prioritize. Lower values have greater priority.
Expand Down Expand Up @@ -136,20 +140,24 @@ Cloudflare adjusts route priority when using AS prepending with communities. For

If you have multiple connectivity paths to a network segment and you would like to apply different route prioritization based on where the traffic arrives at the Cloudflare network, you can scope routes to specific Cloudflare data center regions. This is useful, for example, if you run your own anycast network and want your end-user traffic to arrive at your network location closest to the user. When a route is scoped to a Cloudflare data center region it will only show up in the Magic routing table in that region, along with all global routes that do not have any region scope. Route prioritization and ECMP logic apply across both region-scoped and global routes.

Adding region scoping to routes is only available to statically configured routes at this time.
:::note
Scoping routes to specific regions is not supported with BGP peering, and is only available to statically configured routes at this time.
:::

When using region-scoped routes, you should ensure that all prefixes have routes covering all regions. Otherwise, traffic may arrive at a Cloudflare region which is not covered by any route, in which case the traffic will be dropped.

Scoping routes to specific regions is not supported with BGP peering at this time.

### Scoping configuration data example
The following table exemplifies how to use geographic scoping for routes:

| Prefix | NextHop | Priority | Region code |
| ----- | ----- | ----- | ----- |
| `10.10.10.100/24` | `TUNNEL_1_IAD` | `100` | `AFR` |
| `10.10.10.100/24` | `TUNNEL_2_IAD` | `100` | `EEUR` |
| `10.10.10.100/24` | `TUNNEL_3_ATL` | `100` | `ENAM` |
| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` | `ME` |
| `10.10.10.100/24` | `TUNNEL_5_ATL` | `100` | `WNAM` |
| `10.10.10.100/24` | `TUNNEL_4_ATL` | `100` | `ENAM` |

When there are multiple routes to the same prefix with equal priority, and those routes are assigned to different geographic regions (like WNAM and ENAM), traffic entering the network in a specific region — for example, WNAM — will egress through the route associated with that same region.

### Region codes and associated regions

Expand Down