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 }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

BGP prefix lists describe which route prefixes should be accepted, rejected, or passed into a later route-policy decision. They are common at customer edges, transit edges, route servers, and redistribution boundaries because a single broad route can cover many more-specific routes unless the prefix-length window is written carefully.

The important question is not only the base CIDR block. A row such as 198.51.100.0/23 le 24 matches the aggregate and the allowed /24 specifics, while an exact 198.51.100.0/23 row does not. That distinction matters when accepting customer aggregates, blocking leaked deaggregates, or writing an explicit catch-all rule for a peer-facing policy.

BGP prefix-list range showing a base aggregate, accepted prefix lengths, terminal rule, and review warnings.

Prefix-list review is a route-control task, not a reachability test. A generated list can express the intended route filter, but it does not prove that the prefix is owned, authorized, visible from another network, or safe to deploy. The useful review happens when the generated statements, length ranges, row order, and terminal behavior all match the policy you meant to write.

The safest habit is to read each statement as a match rule for routes, not as a packet ACL. Prefix length is part of the route being matched, so ge 24 le 28 means the route's mask length must be from /24 through /28 within the base prefix.

Technical Details:

BGP carries route reachability as IP prefixes. A less-specific prefix covers a larger address set, while a more-specific prefix covers a smaller address set inside that larger block. Prefix-list statements use that relationship to match route advertisements by base prefix and mask length.

Cisco IOS, IOS-XE, and FRRouting syntax express the rule as ip prefix-list or ipv6 prefix-list entries. Junos route-filter-list syntax expresses the same planning idea with match types such as exact, upto, orlonger, and prefix-length-range. The words differ, but the core question remains the same: which mask lengths should match inside this CIDR block?

Rule Core:

Each row becomes one normalized route-filter rule after comments, spacing, CSV cells, action words, CIDR notation, and length bounds are parsed. Rows without explicit bounds become exact matches. Missing minimum or maximum bounds are filled from the base prefix and the address-family limit.

BGP prefix-list range mapping rules
Source intent	Length window	Cisco and FRR form	Junos form
Exact base prefix only	Minimum equals maximum equals base prefix length	No `ge` or `le` suffix	`exact`
Base prefix through a maximum length	Minimum equals base prefix length, maximum is user supplied	`le MAX`	`upto /MAX`
Longer specifics through address-family limit	Minimum is base prefix length plus one, maximum is `/32` or `/128`	`ge MIN`	`longer` when the minimum is one bit longer
Base prefix or any longer specific	Minimum equals base prefix length, maximum is `/32` or `/128`	`le 32` for IPv4 or `le 128` for IPv6	`orlonger`
Specific bounded window	Minimum and maximum are both supplied and within the family limit	`ge MIN le MAX`	`prefix-length-range /MIN-/MAX`

Validation is intentionally conservative. A minimum length shorter than the base prefix is rejected because it would describe a broader match than the CIDR row. A maximum shorter than the minimum is rejected because the window cannot exist. IPv4 bounds cannot exceed /32, and IPv6 bounds cannot exceed /128.

Generated prefix-list review checks
Review check	What triggers it	Why it matters
Valid source rows	A row has no usable IPv4 or IPv6 CIDR prefix, or length bounds are invalid.	Invalid rows still appear in the ledger so the missing statement is visible before deployment.
Address families	The source contains both IPv4 and IPv6 rows.	Some policy contexts keep address families separate even when the text list accepts both.
Terminal behavior	An explicit deny/reject all or permit/accept all row is requested.	A catch-all row can make the final policy intent clear, but the action must be deliberate.
Network normalization	Host bits are present, such as `203.0.113.9/24`.	The generated rule uses the network boundary, so the operator should confirm the normalized prefix.
Duplicate matches	The same family, normalized prefix, bounds, and action repeat.	Duplicate statements usually add clutter and may hide a copy-paste mistake.
Earlier-match shadowing	A broader earlier rule can match a later row before the later row is reached.	Order can change the effective action for Cisco and FRR style lists.

Junos review has one extra wrinkle. Route-filter-list entries are reusable match objects used inside policy statements, and Junos route filters use longest-match behavior. Repeated destination prefixes with different match types need a review of the surrounding policy term, not just the generated list text.

Everyday Use & Decision Guide:

Start with the platform you plan to configure. Choose Cisco IOS / IOS-XE or FRRouting / SONiC when you need numbered ip prefix-list or ipv6 prefix-list statements. Choose Junos route-filter-list when the output will be referenced from a Junos policy statement term.

Use a list name that can be pasted into the target device. Spaces and unsupported characters are converted to underscores in the generated syntax, so compare the Platform syntax review row with the name you expected before copying the configuration.

Use one row per prefix in Prefix rows. CSV rows can contain prefix, minimum length, maximum length, action, and an optional note.
Use row text such as permit 203.0.113.0/24 ge 24 le 28 when the source material already looks like router syntax.
Use Junos-style row text such as 198.51.100.0/23 upto /24 or 2001:db8:40::/48 orlonger when converting existing route-filter notes.
Leave Output order on Keep input order when the sequence is part of the policy review.
Use Start sequence and Sequence step to leave gaps for future Cisco or FRR insertions.
Use Terminal rule only when the catch-all action should be visible in the generated list.

The fastest trust check is the warning area plus Policy Review. Red invalid-row messages must be fixed before the list is useful. Yellow warnings deserve attention when a prefix was normalized, an entry is duplicated, a later deny can be shadowed by an earlier permit, or a mixed IPv4 and IPv6 list needs to be split.

A clean generated list still belongs in a change review. Compare the Prefix Ledger statement, length range, match type, and row status against the intended route policy before pasting the final configuration into a router or route-policy repository.

Step-by-Step Guide:

Build the list from known route prefixes first, then review the generated statements and policy warnings before using the text anywhere else.

Choose Platform syntax. The summary badges should identify Cisco IOS / IOS-XE, FRRouting / SONiC, or Junos route-filter-list output.
Enter List name. If the review output shows the name was normalized, use the sanitized name consistently in the surrounding route policy.
Choose Default row action. A row with no explicit action uses that setting, while rows beginning with permit, deny, accept, reject, allow, or block override it.
Paste or load rows in Prefix rows. If the warning area says no valid CIDR prefix was found, reduce the row to a plain CIDR value and optional length bounds.
Set Terminal rule to no extra row, deny all, or permit all. The Terminal behavior review row should match the intended final action.
Open Advanced when sequence spacing or ordering matters. Keep input order for policy review, or sort only when normalized ordering is the documented goal.
Read Prefix-List Config, then compare Prefix Ledger and Policy Review. Fix invalid, normalized, duplicate, or shadowed rows before copying the config text.

A useful handoff includes the generated statement, the source row, the length range, and the review state that explains why the row is ready or needs correction.

Interpreting Results:

The headline statement count tells you how many configuration lines were generated, not whether the policy is correct. Treat ready to paste as a syntax-readiness signal for the current inputs. Treat review warnings as a stop point for normalized addresses, duplicate rows, mixed families, shadowing, or explicit terminal behavior. Treat fix source rows as a hard block.

Prefix Ledger is the row-by-row audit. The Length range and Match type columns explain what each statement really matches. Policy Review is the operational checklist because it names the condition, evidence, and operator action for the current list.

ready means the row produced syntactically usable statement text for the selected platform.
normalized means the entered address had host bits and was rewritten to the CIDR network boundary.
duplicate means an earlier row already used the same prefix, bounds, and action.
shadowed means an earlier generated row can match before the later row reaches its intended action.
terminal means the row came from the catch-all setting rather than the pasted source list.
invalid means the row did not produce a statement and should not be ignored during review.

Worked Examples:

Customer aggregates with one bounded specific range:

The sample rows 203.0.113.0/24,24,24,permit, 198.51.100.0/23,23,24,permit, and 10.44.0.0/16,24,28,deny with Cisco syntax produce three statements. The middle row becomes ip prefix-list PL-CUSTOMER-IN seq 20 permit 198.51.100.0/23 le 24, and the third row becomes ip prefix-list PL-CUSTOMER-IN seq 30 deny 10.44.0.0/16 ge 24 le 28. Policy Review should report valid rows, one IPv4 family, and no duplicate or shadowing warning.

The same policy as a Junos route-filter-list:

Switching the platform to Junos route-filter-list changes the output words, not the source rows. The 198.51.100.0/23 row with a /23 to /24 window becomes upto /24 accept. The 10.44.0.0/16 deny row becomes prefix-length-range /24-/28 reject. If Terminal rule is set to deny all, an additional 0.0.0.0/0 orlonger reject row appears and Terminal behavior should say the catch-all row was appended.

Host bits and a bad paste:

A row such as 203.0.113.9/24,24,28,permit is normalized to 203.0.113.0/24 and can still generate a statement. A second row such as not-a-prefix cannot generate a statement, so the summary becomes fix source rows. The useful correction is to fix the invalid line and confirm that the normalized network address is the intended advertised prefix.

A later deny hidden by an earlier permit:

With Cisco or FRR syntax, permit 10.0.0.0/8 le 24 before deny 10.1.2.0/24 creates a shadowing warning. The deny row is syntactically valid, but the earlier permit can match the same /24 first. Reorder the entries or tighten the broader row if the specific deny is supposed to take effect.

FAQ:

Which row formats can I paste?

Use one prefix per line. CSV rows can provide prefix, minimum length, maximum length, action, and note. Text rows can include a CIDR prefix with permit or deny words, ge, le, exact, longer, orlonger, upto, or prefix-length-range.

What does le 24 mean in a prefix list?

le 24 means the route's prefix length must be less than or equal to /24 while still falling within the base CIDR prefix. It is a mask-length test, not an address-number comparison.

Why did the generated prefix differ from what I pasted?

The entered address had host bits. For example, 203.0.113.9/24 is rewritten as 203.0.113.0/24 because prefix-list statements match route networks. Check the normalized value before using the statement.

Does a ready row prove the route should be accepted?

No. A ready row means the statement text was generated for the selected syntax. Verify route ownership, ROA or IRR evidence when relevant, neighbor policy, address-family context, and device behavior before deploying the list.

Does this connect to my router?

No. It parses pasted text and selected text files in the page, then generates configuration text. It does not open a BGP session, query devices, or collect live route tables.

Why does Junos output use accept and reject?

The source action is mapped to Junos policy wording. Permit becomes accept, and deny becomes reject. Review the surrounding policy statement because a route-filter-list entry is a reusable match object rather than a complete neighbor filter by itself.

Glossary:

BGP: Border Gateway Protocol, the inter-domain routing protocol that advertises route prefixes between autonomous systems.
CIDR: Classless Inter-domain Routing notation, such as 198.51.100.0/23, where the suffix gives the prefix length.
Prefix length: The number after the slash in CIDR notation; a longer prefix length describes a smaller address set.
Exact match: A route match where the advertised prefix length must equal the configured prefix length.
Terminal rule: An explicit catch-all permit or deny row added after the source rows to make the final action visible.
Shadowing: A condition where an earlier broader row can match a later row before the later row has a chance to apply.

References:

RFC 4271: A Border Gateway Protocol 4 (BGP-4), RFC Editor, January 2006.
RFC 4632: Classless Inter-domain Routing (CIDR), RFC Editor, August 2006.
IP Routing Commands, Cisco.
Filtering, FRRouting.
route-filter-list, Juniper Networks.