BGP Prefix List Generator

Platform syntax:

Choose the syntax family you intend to paste into the route policy configuration.

List name:

Keep names paste-safe, for example PL-CUSTOMER-IN or CUSTOMER_ACCEPTED_ROUTES.

Default row action:

Individual rows may still start with permit or deny to override this default.

Prefix rows:

Use one row per prefix. CSV columns are prefix, minimum prefix length, maximum prefix length, optional action, and optional note.

Terminal rule:

Cisco and FRR have an implicit deny when a defined prefix list has no match; explicit terminal rows make that behavior visible.

Review prefix-list inputs

{{ message }}

Start sequence:

Use a gap such as 10 so future rows can be inserted without resequencing.

Sequence step:

A step of 5 or 10 is common; the generator clamps invalid values to 1.

Output order:

Input order is safest when row order is part of the policy review.

{{ result.configText }}

Seq	Action	Prefix	Length range	Match type	Statement	Row status	Copy
{{ row.sequence }}	{{ row.action }}	{{ row.prefix }}	{{ row.lengthRange }}	{{ row.matchType }}	{{ row.statement }}	{{ row.status }}{{ row.statusDetail }}

Check	State	Evidence	Operator action	Copy
{{ row.check }}	{{ row.state }}	{{ row.evidence }}	{{ row.action }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Route filters sit between the routes a router learns and the routes a routing policy is willing to use, advertise, or reject. In Border Gateway Protocol (BGP) work, a prefix list is one of the most common ways to express that filter because it talks in the same units as the routing table: network prefixes and prefix lengths.

A prefix such as 198.51.100.0/23 names a block of addresses. The number after the slash says how many leading bits identify the network portion. A longer prefix length is more specific, so /24 is narrower than /23, /28 is narrower again, and a host route is /32 for IPv4 or /128 for IPv6. Many mistakes in prefix-list reviews come from reading those length comparisons as if they were address sizes rather than mask lengths.

Base prefix: The CIDR block that route candidates must share before any length test can matter.
Exact match: Only the same prefix length matches, such as a /23 route matching a /23 rule.
More-specific match: Longer routes inside the base prefix may match, such as covered /24 routes inside a /23.

Prefix lists are used in route maps, policy statements, redistribution rules, neighbor filters, and change-control reviews. A transit provider may use them to accept only customer-owned aggregates. An enterprise may use them to block accidental private-address leaks. A lab may use them to prove which more-specific test routes will pass before a policy is moved to production.

Flow from candidate BGP routes through a prefix rule to a policy result.

Syntax is not portable even when the idea is the same. Cisco-style, Arista EOS, FRRouting, and SONiC-style statements usually use permit, deny, sequence numbers, and ge/le length bounds. Junos route-filter-list entries use match types such as exact, longer, orlonger, upto, and prefix-length-range, and the surrounding policy statement decides how the list is used.

Good prefix filtering is not only a syntax exercise. The same row can be harmless in an outbound customer policy and risky in an inbound transit policy. A broad permit can make a later deny unreachable, a mixed IPv4 and IPv6 list can clash with team standards, and an explicit catch-all row can change the visible policy intent even when the platform already has a default action for unmatched routes.

Check whether the route is meant to be exact, more specific, or a bounded range.
Read ge and le as prefix-length bounds, not as address-number comparisons.
Review ordering before production use because first-match platforms stop at the first applicable sequence.

How to Use This Tool:

Start with the policy intent, then turn each intended route match into one row. The generated configuration is most useful when the input rows already reflect the order and address family you want reviewed.

Choose Platform syntax for Cisco IOS / IOS-XE, Cisco NX-OS, Arista EOS, FRRouting / SONiC, or Junos route-filter-list output.
Enter List name as it should appear in the configuration; spaces and unsupported characters are normalized to paste-safe underscores.
Set Default row action for rows that do not explicitly say permit, deny, accept, or reject.
Junos output converts permit to accept and deny to reject, but the surrounding policy statement still decides how the route-filter-list is used.
Paste Prefix rows with one rule per line, using CSV columns or text forms such as permit 203.0.113.0/24 ge 24 le 28.
Use Load sample, Normalize rows, or Browse CSV/TXT when you need to confirm accepted row shapes before editing the real list. CSV/TXT imports are kept to 512 KiB, so split larger route-policy inventories before loading them.
Choose Terminal rule only when the change plan calls for an explicit catch-all deny or permit.
Open Advanced to adjust start sequence, sequence step, or output order; keep input order when row order is part of the policy review.
Review Prefix-List Config, Prefix Ledger, and Policy Review, then fix invalid, normalized, duplicate, or shadowed rows before copying the result.
A broad earlier permit or deny can make a later row unreachable on first-match syntax families even when every generated statement is syntactically valid.

Interpreting Results:

The summary tells you how many statements were generated and whether the draft is ready, waiting for prefixes, carrying warnings, or blocked by invalid input. Treat a ready status as a syntax and parser check, not as approval to deploy. Prefix filters must still match the intended neighbor direction, address family, route-map or policy term, and operational change record.

BGP prefix-list result areas and verification cues
Result area	What it gives you	Review cue
`Prefix-List Config`	Paste-ready statements for the selected syntax family.	Confirm the config belongs in the correct address family and policy context before applying it.
`Prefix Ledger`	Sequence or order, action, normalized prefix, length range, match type, generated statement, and row status.	Inspect rows marked `invalid`, `normalized`, `duplicate`, `shadowed`, or `terminal`.
`Policy Review`	Checks for source-row validity, syntax family, address-family mix, terminal behavior, normalization, duplicates, and earlier-match shadowing.	Use the operator action as the pre-change checklist, especially when warnings appear.
`JSON`	A structured snapshot of inputs, totals, generated config, ledger rows, review rows, and validation messages.	Store it only where route-policy details are allowed to be shared.

The most important warning is earlier-match shadowing. On first-match syntax families, a broad row can match a later route before the more specific row is reached. The usual fixes are to move the more specific exception earlier, tighten the broad length range, or split the policy into clearer lists.

Technical Details:

CIDR matching begins with network-bit comparison. The advertised route must share the significant bits of the configured base prefix, then its prefix length must fall inside the allowed range. Address-family width sets the hard ceiling: IPv4 routes cannot be longer than /32, and IPv6 routes cannot be longer than /128.

When an input address contains host bits, the network base is recovered by applying the prefix mask. For example, 203.0.113.9/24 normalizes to 203.0.113.0/24. That may be a harmless typing shortcut or it may reveal that the wrong block was entered, so normalized rows deserve review before deployment.

Rule Core:

The governing rules are address masking plus an inclusive prefix-length range.

\begin{array}{lll} network & = & address \land mask (baseLength) \\ routeMatches & = & sameBaseBits \land minLength \leq routeLength \leq maxLength \end{array}

A row written as 198.51.100.0/23,23,24,permit matches the aggregate /23 and the covered /24 routes. A row written as 10.44.0.0/16,24,28,deny does not deny the /16 itself; it denies routes from /24 through /28 inside that /16.

Transformation Core:

Prefix-list row transformation rules
Row condition	Normalized match range	Generated syntax effect
No explicit bounds	`minLength = maxLength = base prefix length`	Exact match for Cisco-style output and `exact` for Junos route-filter-list output.
Only a lower bound	`minLength` through the address-family maximum.	`ge` for Cisco-style output, or `longer`/`orlonger` when a Junos shorthand is an exact fit.
Only an upper bound	Base prefix length through `maxLength`.	`le` for Cisco-style output or `upto` for Junos route-filter-list output.
Lower and upper bounds	`minLength` through `maxLength`, inclusive.	`ge`/`le` for Cisco-style output or `prefix-length-range` for Junos.
Host bits in a source prefix	The address is masked to the network base.	`Prefix Ledger` marks the row as `normalized` and reports the resulting CIDR.
Explicit catch-all	`0.0.0.0/0` or `::/0` across the full family width.	A terminal permit or deny row is appended after the source rows for each detected address family.

Evaluation differs by syntax family. Cisco-style, Arista EOS, FRRouting, and SONiC-style prefix lists are sequence-oriented, so earlier matching rows can prevent later rows from being reached. Junos route-filter-list entries are reusable match objects inside routing policy, and overlapping match types should be checked against the surrounding policy statement rather than treated like a standalone neighbor prefix list.

Validation Boundaries:

BGP prefix-list validation boundaries
Check	Boundary	Reason
Minimum length	`minLength >= base prefix length`	A rule cannot match a route shorter than the base block it names.
Maximum length	`maxLength >= minLength`	The allowed range must run from broader to more specific lengths.
Family ceiling	`maxLength <= 32` for IPv4 and `maxLength <= 128` for IPv6.	Prefix lengths cannot exceed the address-family width.
Duplicate row	Same address family, normalized prefix, length bounds, and action appeared earlier.	Duplicates add review noise and may hide the row that should be edited.
Shadowed row	An earlier row can match the later row before it is evaluated.	Ordering can change the effective permit or deny decision.

Accuracy and Privacy Notes:

The generated configuration is a draft based on CIDR parsing, selected syntax family, row order, and visible options. It does not know the route-map sequence, policy-statement term order, neighbor direction, address-family activation, communities, AS-path matches, local preference changes, prefix-list attachment point, or peer-specific routing policy.

Prefix text and uploaded CSV/TXT files are parsed in the browser after the page loads. The generator does not need a server-side lookup to build the statements, but copied text, downloaded files, and saved JSON should still be handled as routing-policy data.

Lab-test the final policy when a mistake could withdraw, leak, or accept unwanted routes.
Keep the original row list and review output with the change record.
Split IPv4 and IPv6 entries when the target platform or local standard expects separate objects.

Advanced Tips:

Keep IPv4 and IPv6 rows in separate source lists when the target platform, change record, or reviewer ownership treats address families separately.
Use sequence gaps such as 5 or 10 for Cisco-style output so future exception rows can be inserted without resequencing the whole list.
Leave Output order on input order when the source file already reflects a reviewed policy sequence.
Use least-specific or most-specific sorting only for cleanup drafts, then recheck Policy Review for new shadowing after sorting.
Check Network normalization rows carefully; host-bit cleanup can turn a typed host address into a broader network than intended.
Use an explicit Terminal rule only when the platform standard or surrounding policy term expects a visible catch-all outcome.
Use Normalize rows to turn accepted input into prefix,min,max,action CSV before peer review, then compare that normalized list with the generated statements.
Keep the Prefix Ledger with the change record so reviewers can see normalized CIDR, length range, generated statement, and row status together.

Worked Examples:

A customer inbound policy may need to accept only an aggregate and its directly covered /24 routes. The row 198.51.100.0/23,23,24,permit,customer aggregate generates a range that includes 198.51.100.0/23, 198.51.100.0/24, and 198.51.101.0/24, but not a more-specific /25.

A private-address leak guard might use 10.44.0.0/16,24,28,deny,block leaked deaggregates. The base /16 establishes the address block, while the minimum and maximum lengths target more-specific advertisements from /24 through /28.

A troubleshooting case starts with 203.0.113.9/24,24,24,permit. The ledger normalizes it to 203.0.113.0/24 because .9 is a host address inside that subnet. If the intended customer block was actually 203.0.113.8/29, the row needs a different base prefix and range.

A broad permit such as 10.0.0.0/8 ge 8 le 32 before a later deny for 10.44.0.0/16 ge 24 le 28 can trigger shadowing. Move the deny earlier or narrow the permit so the exception is reached.

FAQ:

What do ge and le mean in a prefix list?

ge sets the minimum prefix length and le sets the maximum prefix length. In 10.0.0.0/8 ge 16 le 24, matching routes must stay inside 10.0.0.0/8 and have lengths from /16 through /24.

Why did the prefix change after parsing?

The address contained host bits for the stated prefix length. The ledger shows the network-aligned CIDR so you can decide whether the normalized block is the block you meant to filter.

Should every prefix list end with an explicit deny all?

No. Use an explicit terminal row only when the target policy standard calls for one. Some syntax families already deny unmatched prefixes when a list is defined, and Junos policy outcome depends on the surrounding policy terms.

Can IPv4 and IPv6 prefixes be mixed?

The generator can parse both families and reports a mixed-family warning. Many operations teams still keep separate IPv4 and IPv6 policy objects because neighbor address families, review ownership, and platform conventions are often separate.

Glossary:

BGP: Border Gateway Protocol, the inter-domain routing protocol commonly filtered with prefix lists and routing policy.
CIDR: Classless Inter-Domain Routing notation, such as 203.0.113.0/24, combining an address block with a prefix length.
Prefix length: The slash number that says how many leading bits identify the network portion.
More-specific route: A route with a longer prefix length inside a broader block, such as a /24 inside a /16.
Terminal rule: An optional catch-all permit or deny row added after the source rules.
Shadowing: A condition where an earlier row can match a later row before the later row gets a chance to decide the route.

References:

RFC 4632: Classless Inter-domain Routing (CIDR), IETF.
Cisco IOS XE IP Routing Commands: ip prefix-list, Cisco.
Filtering: IP Prefix List, FRRouting.
route-filter-list, Juniper Networks.
Understanding Route Filters for Use in Routing Policy Match Conditions, Juniper Networks.
EOS ACLs and Route Maps, Arista.