Cisco IP prefix lists are one of the most precise tools available for controlling routes. They are also easy to misread. The most common confusion is the difference between permitting one exact prefix and permitting every more specific route contained inside that prefix. That difference is usually controlled by the ge and le values.
Why It Matters: A single le 32 statement can permit thousands of IPv4 prefixes. Used intentionally, it simplifies a policy. Used carelessly, it can advertise far more routing information than the design requires.
01 What an IP Prefix List Actually Matches
A prefix list evaluates two separate properties of a route:
- The route must fall inside the address space defined by the prefix list entry.
- The route must have a prefix length allowed by that entry.
This is important because le and ge refer to prefix length. They do not compare the numerical value of the IP address.
ip prefix-list EXAMPLE seq 10 permit 10.0.0.0/8 le 24
This statement can match the 10.0.0.0/8 route and any valid subnet contained within 10.0.0.0/8 with a prefix length from /9 through /24. It does not match 172.16.0.0/16 because that route is outside the 10.0.0.0/8 address space. It also does not match 10.10.10.0/25 because /25 is more specific than the configured maximum of /24.
| Route | Match | Reason |
|---|---|---|
| 10.0.0.0/8 | Yes | Exact base prefix |
| 10.20.0.0/16 | Yes | Inside 10.0.0.0/8 and no longer than /24 |
| 10.20.30.0/24 | Yes | Inside 10.0.0.0/8 and exactly at the maximum |
| 10.20.30.128/25 | No | The prefix length exceeds /24 |
| 192.168.10.0/24 | No | The route is outside 10.0.0.0/8 |
02 Exact Match Without ge or le
When a prefix list entry does not include ge or le, it matches only the exact network and exact prefix length written in the statement.
ip prefix-list AWS-OUT seq 10 permit 10.193.131.0/24
This permits only 10.193.131.0/24. It does not permit the covering route 10.193.0.0/16. It also does not permit any more specific route such as 10.193.131.128/25 or 10.193.131.10/32.
Architect’s Note: Exact matching is usually the safest approach when only a defined set of production prefixes should be advertised. It creates more configuration lines, but the policy clearly documents every approved route.
03 What le 32 Really Means
For IPv4, /32 is the longest possible prefix length. Therefore, le 32 means permit the configured prefix and every more specific route contained within it, all the way down to individual host routes.
ip prefix-list PRIVATE-10 seq 10 permit 10.0.0.0/8 le 32
This can permit all of the following routes, provided they are present in the routing policy being evaluated:
10.0.0.0/8 10.64.0.0/10 10.100.0.0/16 10.100.25.0/24 10.100.25.128/25 10.100.25.10/32
The entry does not mean that the router will automatically advertise every possible subnet between /8 and /32. It means that any existing route within that range is allowed to match.
Common Mistake: Engineers sometimes read 10.0.0.0/8 le 32 as only permitting the /8 and /32. It actually permits every valid prefix length from /8 through /32.
04 How ge and le Build Prefix Length Ranges
The base prefix defines the address boundary. The ge and le values define the acceptable prefix length range inside that boundary.
| Statement | What It Matches |
|---|---|
| 10.0.0.0/8 | Only 10.0.0.0/8 |
| 10.0.0.0/8 le 24 | The /8 and all contained prefixes through /24 |
| 10.0.0.0/8 ge 16 | All contained prefixes from /16 through /32 |
| 10.0.0.0/8 ge 16 le 24 | All contained prefixes from /16 through /24 |
| 10.0.0.0/8 ge 24 le 24 | Only /24 routes contained inside 10.0.0.0/8 |
The last example is useful when the requirement is not one exact /24, but every /24 inside a larger allocation.
ip prefix-list BRANCH-SUBNETS seq 10 permit 10.0.0.0/8 ge 24 le 24
That entry permits 10.1.10.0/24 and 10.200.50.0/24. It does not permit 10.1.0.0/16 or 10.1.10.128/25.
05 How Prefix Lists Affect BGP Advertisements
An outbound prefix list controls which eligible BGP routes are sent to a neighbor. It does not originate routes, install routes in the routing table, or create aggregates.
router bgp 65001 address-family ipv4 unicast neighbor 192.0.2.10 prefix-list AWS-OUT out
The router starts with routes that BGP is prepared to advertise to 192.0.2.10. The prefix list then permits or denies those routes.
BGP routes eligible for the neighbor
|
v
Outbound prefix list evaluation
|
permit or deny
|
v
Routes advertised to the neighbor
Consider this policy:
ip prefix-list AWS-OUT seq 10 permit 10.0.0.0/8 le 32
Assume the local BGP table contains these routes:
10.20.0.0/16 10.20.30.0/24 10.20.30.10/32 172.16.50.0/24 0.0.0.0/0
The first three routes match. The 172.16.50.0/24 route and the default route do not match. Because prefix lists have an implicit deny at the end, those unmatched routes are blocked unless another sequence permits them.
Why It Matters: The prefix list is a filter, not a route generator. If 10.20.30.0/24 is not in BGP and is not otherwise eligible for advertisement, adding a permit statement for it does not cause BGP to advertise it.
The same principle applies to aggregates. A prefix list entry for 10.0.0.0/8 does not create a 10.0.0.0/8 aggregate. The aggregate must already exist through a valid BGP origination method, such as a matching BGP network statement, redistribution policy, or aggregate configuration.
06 Enterprise BGP Examples
Example 1: Permit specific approved routes only
ip prefix-list AWS-OUT seq 10 permit 10.193.131.0/24 ip prefix-list AWS-OUT seq 20 permit 10.194.40.0/22 ip prefix-list AWS-OUT seq 30 permit 10.205.64.0/18
This is restrictive and easy to audit. Only those exact prefixes are permitted. More specific routes are not automatically included.
Example 2: Permit all RFC 1918 routes, including host routes
ip prefix-list AWS-OUT seq 10 permit 10.0.0.0/8 le 32 ip prefix-list AWS-OUT seq 20 permit 172.16.0.0/12 le 32 ip prefix-list AWS-OUT seq 30 permit 192.168.0.0/16 le 32
This policy permits every IPv4 prefix contained within the three private address ranges. It is concise, but it is also broad. Any new private route that enters BGP can become eligible for advertisement without another prefix list change.
Common Mistake: Treating RFC 1918 membership as sufficient authorization. A route can be private and still be inappropriate for a specific cloud, partner, tenant, or security zone.
Example 3: Permit private routes only through /24
ip prefix-list AWS-OUT seq 10 permit 10.0.0.0/8 le 24 ip prefix-list AWS-OUT seq 20 permit 172.16.0.0/12 le 24 ip prefix-list AWS-OUT seq 30 permit 192.168.0.0/16 le 24
This blocks /25 through /32 routes. That can prevent host routes, loopbacks, and very specific traffic engineering routes from leaking across the boundary. However, it also blocks any legitimate subnet longer than /24. The maximum length must reflect the actual addressing design.
Example 4: Permit private routes plus one exact default route
ip prefix-list AWS-OUT seq 10 permit 10.0.0.0/8 le 32 ip prefix-list AWS-OUT seq 20 permit 172.16.0.0/12 le 32 ip prefix-list AWS-OUT seq 30 permit 192.168.0.0/16 le 32 ip prefix-list AWS-OUT seq 40 permit 0.0.0.0/0
The final statement permits only the default route because it has no ge or le qualifier.
Real World Example: In an AWS Direct Connect design, the private range statements may permit thousands of on premises routes while the exact 0.0.0.0/0 statement permits a default route. This is very different from using 0.0.0.0/0 le 32, which permits the entire IPv4 routing space.
07 The Default Route and the Dangerous Permit Everything Statement
The difference between these two statements is enormous:
ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0 ip prefix-list PERMIT-EVERYTHING seq 10 permit 0.0.0.0/0 le 32
0.0.0.0/0 without a length qualifier matches only the default route.
0.0.0.0/0 le 32 matches the default route and every IPv4 prefix from /1 through /32. Because every IPv4 route is contained within 0.0.0.0/0, this is effectively a permit all statement for routes.
Warning: Never use 0.0.0.0/0 le 32 as a substitute for permitting only the default route. In an outbound BGP policy, it can expose every eligible IPv4 route to the neighbor.
A related policy can match all IPv4 routes except the default route:
ip prefix-list NON-DEFAULT seq 10 permit 0.0.0.0/0 ge 1 le 32
08 Direct Prefix List Filtering Versus Route Maps
A prefix list can be applied directly to a BGP neighbor or referenced by a route map. The evaluation behavior is related, but the policy structure is different.
Direct neighbor filtering
neighbor 192.0.2.10 prefix-list AWS-OUT out
In this case, prefix list permit entries allow routes and prefix list deny entries block routes. Any unmatched route reaches the implicit deny.
Route map filtering and attribute changes
ip prefix-list AWS-HIGH seq 10 permit 10.193.131.0/24 route-map AWS-OUT permit 10 match ip address prefix-list AWS-HIGH set community 7224:7300 additive route-map AWS-OUT permit 100 match ip address prefix-list AWS-APPROVED router bgp 65001 address-family ipv4 unicast neighbor 192.0.2.10 route-map AWS-OUT out
When a prefix list is used in a route map match clause, a prefix list permit entry means the route matches that clause. A prefix list deny entry means the match fails, which can allow the route map to continue evaluating later sequences. The final result depends on the route map sequence that eventually matches, or on the route map implicit deny if no sequence matches.
Architect’s Note: Use a direct prefix list when the requirement is simple permit and deny filtering. Use a route map when routes also need communities, AS path prepending, MED changes, local preference changes, next hop handling, or multiple policy branches.
09 Verification and Troubleshooting
Never validate an outbound routing policy by reading the configuration alone. Verify the prefix list, the BGP table, and the actual routes advertised to the neighbor.
Display the prefix list
show ip prefix-list AWS-OUT
Test whether a route matches
show ip prefix-list AWS-OUT 10.193.131.0/24
Verify the route exists in BGP
show bgp ipv4 unicast 10.193.131.0/24
Verify what is actually advertised
show bgp ipv4 unicast neighbors 192.0.2.10 advertised-routes
On platforms or releases that use the older command form:
show ip bgp neighbors 192.0.2.10 advertised-routes
After changing an outbound policy, confirm that the router has recalculated and sent the expected updates. A controlled soft outbound refresh can be used when needed:
clear ip bgp 192.0.2.10 soft out
Common Mistake: Seeing a route in the local routing table does not prove it is in BGP, eligible for that neighbor, permitted by the outbound policy, or accepted by the remote side. Each stage must be verified independently.
10 Design Recommendations
- Use exact entries for tightly controlled advertisements. This is the clearest policy for partner connections, cloud boundaries, extranet routing, and production migrations.
- Use le 32 only when every possible more specific prefix is intentionally allowed. Remember that this includes /32 host routes.
- Choose a realistic maximum length. If the design should never advertise anything longer than /24, use le 24 rather than le 32.
- Keep the default route exact. Use 0.0.0.0/0 without le 32 when the requirement is default only.
- Account for the implicit deny. A route that does not match a permit entry is denied when the prefix list is applied directly.
- Do not confuse permission with origination. A prefix list can allow a route, but another BGP mechanism must make that route eligible for advertisement.
- Verify advertised routes before and after changes. The neighbor advertisement output is the authoritative local check for what the router is sending.
- Document the design intent in remarks and sequence numbers. The configuration should explain why a range is broad, not merely show that it is broad.
ip prefix-list AWS-OUT description Approved private routes and exact default ip prefix-list AWS-OUT seq 10 permit 10.0.0.0/8 le 24 ip prefix-list AWS-OUT seq 20 permit 172.16.0.0/12 le 24 ip prefix-list AWS-OUT seq 30 permit 192.168.0.0/16 le 24 ip prefix-list AWS-OUT seq 40 permit 0.0.0.0/0
Final Takeaway: Without ge or le, a Cisco prefix list matches one exact prefix. With le 32, it matches the base prefix and every more specific IPv4 route contained within it. The statement controls which existing routes pass the policy. It does not create the routes being advertised.