BGP Prefix-List and Policy Generator

← Back to Tools

Build a BGP import or export policy once and get it as Junos, Cisco IOS / IOS-XE or Cisco IOS-XR configuration: prefix sets (with ge/le ranges), AS-path and community matches, and local-preference, MED, community and AS-path-prepend actions. Then test it: paste a list of routes and see, term by term, what the policy would accept, reject or change — before it goes anywhere near a router. Everything runs in your browser; nothing is sent anywhere.

Start From

Policy

Output for

Address family

Policy name

Applied as

Your ASN (used for prepends)

IOS AS-path access-list numbers start at

Prefix Sets

One entry per line: prefix/len followed by an optional range — exact (default), orlonger, longer, le N / upto N, ge N, ge N le M or prefix-length-range A-B. A route matches a set if it matches any entry. Anything after # is a comment. To match by prefix length alone use 0.0.0.0/0 ge 25 (or ::/0 ge 49).

Policy Terms — evaluated top to bottom

The first term whose conditions all match decides the route when its action is Accept or Reject. Continue applies the term’s changes and keeps evaluating the terms below. A term with no conditions matches every route. Anything no term decides gets the default action.

Default action (nothing above decided)

Configuration

Test The Policy

One route per line, fields separated by |: prefix | AS path | communities | local-pref | MED | expect. Everything after the prefix is optional. The AS path is as the route arrives (neighbor AS first, origin AS last; empty means locally originated). Local-pref defaults to 100. Add accept or reject as the last field to turn a line into a pass/fail check.

Routes to test

Reference

Prefix sets are match-only lists — they never accept or reject by themselves. A term uses a set as a condition, and its action decides what happens. To exclude something, put a Reject term for it above the terms that accept.
Conditions inside a term are ANDed (prefix set, AS-path, community). Values inside one condition are ORed: several ASNs or several communities match if the route has any of them.
Length checks use ranges. “Too specific” is 0.0.0.0/0 ge 25; “too short” is 0.0.0.0/0 le 7 (which also catches the default route). The IPv6 equivalents are ::/0 ge 49 and ::/0 le 18.
Accept / Reject / Continue. Continue applies the term’s set actions and falls through to the next term — on Junos it is next term, on IOS it is the route-map continue command, on IOS-XR it is simply no done/drop.
AS-path matches are structured rather than free regex: originated by (last AS), learned from neighbor AS (first AS), passes through, locally originated (empty path), or contains a private ASN (64512–65534, 4200000000–4294967294). The tool writes the right regex for each platform, so the tester and the config always mean the same thing.

Junos writes each prefix set as a route-filter-list and the policy as policy-statement terms. A community with several members matches only when the route carries all of them, so the tool creates one community per value for OR-style matching. AS-path regexes are matched against the whole path, which is why they start or end with .*.
IOS / IOS-XE writes ip prefix-list / ipv6 prefix-list, ip as-path access-list (numbered, so check the start number is free), ip community-list standard and a route-map with one sequence per term (10, 20, 30…). Anything the route-map does not match is denied by the implicit deny at the end; the tool still writes the final sequence explicitly. Arista EOS and NX-OS use very similar commands, but this output has not been checked on them.
IOS-XR writes prefix-set, as-path-set, community-set and a route-policy. A route-policy that runs off the end without done drops the route, and eBGP sessions without a policy accept and send nothing, so the tool always ends with an explicit done or drop.
What “Continue” lets the next term see. On Junos, a later term matches the route as earlier terms changed it — a community added above is visible below. On IOS and IOS-XE it is the opposite: every route-map sequence matches the route as it arrived, and only the final result carries the accumulated changes. The tester follows the platform you pick, and the tool warns when a term depends on a change made above it on IOS. IOS-XR is expected to behave like Junos but that has not been lab-checked.
Long AS-path regexes. IOS-XE refuses a single AS-path regex of roughly 250 characters or more, so the private-ASN match is written as three permit lines in one ACL (lines in one ACL are ORed) instead of one long expression.
Sequence versus set semantics. The tester evaluates terms strictly in order and uses the first decision, exactly as a route-map, a Junos policy-statement and an XR route-policy do. A prefix set has no order of its own.

Communities are not sent by default on IOS and IOS-XR. If a policy adds or sets communities for a neighbor to see, that neighbor needs neighbor X send-community (IOS; both for extended too) or send-community-ebgp (IOS-XR). Junos sends them.
Applying an inbound policy does not re-evaluate routes already received unless you refresh: clear ip bgp X soft in (IOS), clear bgp X soft in (XR), clear bgp neighbor X soft-inbound (Junos). Outbound changes need a soft-out.
Local-preference is not carried over eBGP. Setting it on an export policy to an external neighbor does nothing; set it on import.
Export policies and well-known communities. A route that arrived carrying no-advertise (or no-export, toward an eBGP neighbor) is not advertised, whatever your export policy accepts. Deleting the community in the policy does not rescue it, and a community the policy adds does not block that advertisement. The tester shows this.
What an eBGP neighbor receives from an export. Your AS is added to the path, local-preference is not sent, and a MED is sent only if the policy sets one — a MED you received from someone else is not passed on.
Prepending belongs on eBGP policies. In testing, IOS-XE 17.18 did not apply a route-map set as-path prepend to routes received from an iBGP neighbor; it worked as expected on eBGP.
Check the unconditional terms. A term with no conditions and an Accept or Reject action ends evaluation; the tool warns when it makes later terms unreachable.
Do not paste into production blind. Look at what the router already has: an existing policy with the same name, AS-path ACL numbers already in use (IOS), or an existing policy on the neighbor.
AS-path prepending is a blunt tool — every extra copy is another AS-path hop in everyone’s table; 2–3 is usually plenty.
The example prefixes and ASNs in the starting points are made up. The bogon lists follow the common Team Cymru-style martian set; check them against your own policy before relying on them.

Junos and Cisco IOS-XE were run for real. Every starting point, plus stress scenarios covering prefix ranges, every AS-path match, community add / replace / delete / clear, MED, prepend, Continue chains and default-accept — IPv4 and IPv6, import and export, well over 100 routes per platform — was loaded into Juniper cRPD (Junos 26.2) and a Cisco IOL router (IOS-XE 17.18). FRRouting announced each test route with the exact AS path, communities, MED and local-preference from its test line, and the router’s own accept/reject decision and resulting attributes were compared with the tester’s prediction. They agree. Exports were checked as an eBGP neighbor receives them.
Testing changed the tool. It found that IOS-XE rejects very long AS-path regexes, that IOS and Junos differ on what a later term can see after Continue, that well-known communities block advertisement before an export policy runs, and what an eBGP neighbor really receives (no local-preference, no passed-on MED). All of that is now built in.
IOS-XR was not run. Its output was checked line by line against Cisco’s published Routing Policy Language syntax (prefix-set ranges, ios-regex AS-path sets, community-sets, set community … additive, delete community, prepend as-path, done / drop) but not on a router. Arista EOS and NX-OS have not been tested either.
What it does not model: BGP best-path selection, next-hop handling, large and extended communities, free-form AS-path regexes, prefix limits and AS-sets. The tester reports what one policy does to one route, not what a router will finally choose.
Still a convenience tool: read the generated configuration, test it in a lab, and compare it with what is already on your router before applying it.

Provided as-is, with no warranty of any kind. This runs entirely in your browser as a convenience tool, not a certified reference — always double-check results before relying on them for anything important, especially production changes. See the full disclaimer.