Which Prefix List Matches /1 to /16 in a Control Policy?
An engineer is configuring a list that matches all IP prefixes with lengths from /1 to /16 in a centralized control policy. Which list accomplishes this task?
Community Insight
The question tests knowledge of the 'le' (less-than-or-equal) prefix-length operator in SD-WAN prefix lists, and the trap is assuming that a list starting at 0.0.0.0/0 must also match the /0 default route rather than beginning at /1.
In Cisco Catalyst SD-WAN centralized control policies, an IP prefix list written as 0.0.0.0/0 le 16 matches all IP prefixes with lengths from /1 through /16. This page explains why option A is the documented syntax and why the /1-based alternatives fail the requirement.
Option B (0.0.0.0/1 le 16) is the most common wrong pick because learners reason that /1 must be stated explicitly to cover /1 to /16; in SD-WAN prefix-list syntax the base 0.0.0.0/0 with le 16 already yields exactly the /1–/16 range Cisco documents.
Community Discussion (20 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Cisco documents thatip-prefix 0.0.0.0/0 le 16 matches all IP prefixes with lengths from /1 through /16, which is precisely the requirement in this centralized control policy question. The le keyword constrains the match to prefixes whose length is less than or equal to 16, so every concrete network prefix from a /1 up to a /16 is accepted. As FlipCCNP quoted directly from the Cisco policy-basics documentation, 0.0.0.0/0 le 16 matches all IP prefixes with lengths from /1 through /16, making option A the documented, verifiable answer. Because the base 0.0.0.0/0 entry itself carries no usable network information for a route match in this context, the effective matched range starts at /1.Why the Other Options Are Wrong
Option B,0.0.0.0/1 le 16, anchors the list at a /1 network boundary, which restricts matches to only the address space under that first /1 rather than the full documented /1–/16 behavior; as gladpark argued, it does not reproduce the documented semantics. Option C, 0.0.0.0/0 ge 1, uses ge (greater-than-or-equal) without an upper bound, so it matches /1 through /32 and beyond the requested /16 ceiling. Option D, 0.0.0.0/16 ge 1, is doubly wrong: it anchors on a /16 prefix and uses ge, producing neither the intended base nor the intended length ceiling. None of B, C, or D reproduce the vendor-documented /1-to-/16 match.Community Comment Notes
Most commenters converged on A, with FlipCCNP pasting the Cisco example verbatim and CCNPCollab1297 reinforcing that the quoted line reads "ip-prefix 0.0.0.0/0 le 16 matches all IP prefixes with lengths from /1 through /16." A dissenting voice, gladpark, voted B on the reasoning that "0.0.0.0/0 le 16 matches all IP prefixes with lengths from /0 to /16," while isaacmejia similarly argued from broadcast-address arithmetic that "i would go with B." immphoenix raised a narrower caveat that "Technically A is flawed becasue A match the default route 0.0.0.0/0," a nuance the official example resolves in favor of A.Official Reference
Exam Strategy
When a prefix-list question cites an exact range like /1 to /16, look for the Cisco-documented 0.0.0.0/0 le <n> idiom rather than re-deriving the match yourself; memorize that le sets the upper bound and ge sets a lower bound only.
Frequently Asked Questions
Why does 0.0.0.0/0 le 16 start matching at /1 instead of /0?
Cisco documents that ip-prefix 0.0.0.0/0 le 16 matches all IP prefixes with lengths from /1 through /16. The /0 base carries no network information to match, so effective matches begin at /1.
Why is 0.0.0.0/1 le 16 not the right list for the /1 to /16 range?
Anchoring on 0.0.0.0/1 binds the match to a single /1 address block instead of providing the general /1–/16 prefix-length range that 0.0.0.0/0 le 16 delivers.
Related Analysis
Practice All 300-415 Questions
Access 120 questions with complete answers and detailed explanations.
View Full 300-415 Practice Test →