[Magic Transit] Use RFC 5737 prefixes in route examples - #33407
Open
SomSamantray wants to merge 2 commits into
Open
SomSamantray wants to merge 2 commits into
SomSamantray wants to merge 2 commits into
Conversation
SomSamantray
requested review from
a team,
alpdot,
jeffh-cloudflare and
steve-cloudflare
as code owners
September 13, 2026 11:27
Contributor
Review✅ No issues found in commit Code ReviewThis code review is in beta and may not always be helpful — use your judgment. No code review issues found. ConventionsNo convention issues found. Style Guide ReviewNo style-guide issues found. CommandsOnly codeowners can run commands. Post a comment with the command to trigger it.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Five Magic Transit pages used non-reserved addresses as placeholders for a customer's onboarded or advertised prefix. Magic Transit routes public prefixes only, and the style guide already mandates the RFC 5737 blocks for IPv4 examples, so the examples were both impossible as written and inconsistent with the rest of the docs.
Two kinds of placeholder were wrong: RFC 1918 private addresses, and — on two pages — subnets of Cloudflare's own published
103.21.244.0/22range presented as if they were a customer's prefixes. Both now use reserved documentation space.reference/traffic-steering.mdxalready carried an Aside stating that these blocks are reserved for documentation examples, so this change makes that page consistent with its own note.The
bandwidth-measurementexample keeps its Longest Prefix Match shape. RFC 5737 reserves only/24blocks, so its covering prefix and the more-specific ISP route become203.0.113.0/24and203.0.113.128/25, and the prose reference to the covering/20becomes/24.Addresses that are factual references to real infrastructure are deliberately unchanged — Cloudflare's tunnel health-check source range, tunnel-interface addresses, documented CGNAT space, and a captured traceroute's hops would all become untrue if converted.
One non-reserved prefix is deliberately left alone: the
/24-into-/23summarization example atreference/traffic-steering.mdx:225-228uses192.0.3.0/24. RFC 5737's three blocks are not contiguous, so no reserved-space pair can be summarized into a/23, and the same page documents a/24minimum advertising prefix, which rules out a sub-/24rewrite. Removing it means reshaping the example, which is a separate editorial change. The Aside just below that example also claims RFC 5737 coverage for192.0.3.0/24, which is inaccurate.Fixes #31625
Documentation checklist