BGP prefix-list examples for Cisco, Juniper, and FRR

A BGP prefix list should describe both the address space and the permitted prefix lengths. Filtering only on an aggregate can accidentally accept every more-specific route beneath it; filtering every route individually works, but creates longer policies that are harder to review. The useful middle ground is a compact rule whose length bounds match the intended routes exactly.

What exact, ge, and le mean

A route matches only when it falls inside the rule's base prefix and its prefix length meets the rule's length constraint. On Cisco IOS and FRRouting, a prefix-list entry containing only203.0.113.0/24 is an exact match. Adding ge 26 le 28 changes it to accept contained routes from /26 through /28, inclusive. It does not accept the base /24 or a /25.

Junos expresses the same ideas with route-filter match types. exact accepts only the listed prefix. prefix-length-range /26-/28 accepts contained routes whose lengths fall within that inclusive range. The address-containment check still matters: a198.51.100.0/26 does not match a rule rooted at 203.0.113.0/24.

Exact-match prefix-list examples

Suppose customer AS 64501 is authorized to announce only203.0.113.0/24. The Cisco IOS and FRR entry needs no length modifier:

ip prefix-list CUSTOMER-IN seq 10 permit 203.0.113.0/24

The equivalent Junos route-filter states the match type explicitly:

set policy-options policy-statement CUSTOMER-IN term ALLOW-DOC from route-filter 203.0.113.0/24 exact
set policy-options policy-statement CUSTOMER-IN term ALLOW-DOC then accept

Neither rule permits 203.0.113.0/25. This is the safest starting point when the routing authorization names a single aggregate.

Lossless example: four /26 routes in one rule

Now assume the approved inventory contains these four routes:

• 203.0.113.0/26
• 203.0.113.64/26
• 203.0.113.128/26
• 203.0.113.192/26

They fill 203.0.113.0/24, but accepting the /24 itself would change the policy. A lossless compressed rule keeps the parent as the address boundary and pins both length limits to /26:

ip prefix-list CUSTOMER-IN seq 10 permit 203.0.113.0/24 ge 26 le 26

set policy-options policy-statement CUSTOMER-IN term ALLOW-DOC from route-filter 203.0.113.0/24 prefix-length-range /26-/26

A /24 contains exactly four aligned /26 routes, so these rules accept exactly four possible /26 routes—the same set as the inventory. They reject the covering /24, both /25s, and every route longer than /26.

Paste the four routes into the generator and keep its default lossless mode. The tool does not put bulk prefix inventories into shareable URLs, so the list remains in your browser rather than becoming part of link history or server logs.

Why a permissive le 32 rule is different

This Cisco IOS or FRR rule is not a shorter spelling of the four-route policy:

ip prefix-list CUSTOMER-IN seq 10 permit 203.0.113.0/24 le 32

It accepts the /24 plus every contained prefix from /25 through/32: 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 + 256 =511 distinct prefixes. That may be intentional for an allocation whose holder may announce any more-specific, but it is vastly broader than four approved /26s.

Even ge 26 le 32 accepts 508 possible prefixes, not just the four/26s. Length ranges are authorization boundaries. Choose them from the routing agreement or source-of-truth inventory, not merely from the shortest covering aggregate.

Complete inbound policy examples

The following configurations apply the lossless four-/26 policy to a documentation neighbor at 192.0.2.2. Names and hierarchy differ by platform, but the accepted route set is the same.

Cisco IOS configuration

ip prefix-list CUSTOMER-IN seq 10 permit 203.0.113.0/24 ge 26 le 26
!
router bgp 64500
 neighbor 192.0.2.2 remote-as 64501
 neighbor 192.0.2.2 prefix-list CUSTOMER-IN in

Cisco prefix lists have an implicit deny after their configured entries. Verify the list withshow ip prefix-list CUSTOMER-IN and inspect the received or accepted routes using commands supported by the deployed IOS release.

Juniper Junos configuration

set policy-options policy-statement CUSTOMER-IN term ALLOW-DOC from route-filter 203.0.113.0/24 prefix-length-range /26-/26
set policy-options policy-statement CUSTOMER-IN term ALLOW-DOC then accept
set policy-options policy-statement CUSTOMER-IN term REJECT then reject
set protocols bgp group CUSTOMER type external
set protocols bgp group CUSTOMER peer-as 64501
set protocols bgp group CUSTOMER neighbor 192.0.2.2
set protocols bgp group CUSTOMER import CUSTOMER-IN

The explicit final reject makes this policy's boundary visible instead of relying on what a later policy or protocol default might do. Use show policy CUSTOMER-IN and inspect received routes before and after import-policy evaluation.

FRRouting configuration

ip prefix-list CUSTOMER-IN seq 10 permit 203.0.113.0/24 ge 26 le 26
!
router bgp 64500
 neighbor 192.0.2.2 remote-as 64501
 address-family ipv4 unicast
  neighbor 192.0.2.2 prefix-list CUSTOMER-IN in
 exit-address-family

FRR also denies prefixes that reach the end of a prefix list without matching a permit entry. Check the generated entries with show ip prefix-list CUSTOMER-IN, then confirm the neighbor's accepted IPv4 routes.

Deployment checklist

1. Normalize every input to its network boundary and remove duplicates.
2. Confirm prefix ownership, intended direction, and permitted lengths in the source of truth.
3. Compare the generated policy's possible route set with the approved inventory.
4. Stage the configuration and run platform syntax or commit checks.
5. Inspect prefix-list and policy output before applying it to a live neighbor.
6. Apply during a controlled change and verify accepted routes, route count, and traffic.
7. Add a suitable maximum-prefix limit and alerting as a separate safety control.

Authoritative sources

• RFC 4271 defines BGP-4.
• RFC 7454 documents BGP operations and security practices, including prefix filtering.
• Cisco prefix-list documentationexplains IOS prefix-list matching and ge/le use.
• Juniper route-filter documentationdefines Junos route-filter match types.
• FRRouting filtering documentationcovers prefix-list syntax and matching.
• Example addresses and AS numbers come fromRFC 5737 andRFC 5398.