New Tool - BGP Prefix-List and Policy Generator (with a Policy Tester)

New on the Network Tools page: a BGP Prefix-List and Policy Generator. You describe a BGP import or export policy once, get the configuration for Junos, Cisco IOS / IOS-XE or Cisco IOS-XR, and then test it against a list of routes before it goes anywhere near a router.

What it builds

• Prefix sets with ranges: exact, orlonger, longer, le, ge, ge N le M, prefix-length-range. Length checks are just 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). IPv6 works the same way.
• Ordered terms. Each term matches on a prefix set, an AS-path condition (originated by, learned from neighbor AS, passes through, locally originated, contains a private ASN) and communities. Then it can set local-preference and MED, add, replace, delete or clear communities, prepend your AS, and accept, reject or continue to the next term.
• Real platform output. Junos gets route-filter-list and policy-statement terms. IOS gets prefix-lists, AS-path ACLs, community lists and a route-map with one sequence per term. IOS-XR gets prefix-sets, as-path-sets, community-sets and a route-policy that ends in an explicit done or drop.
• Starting points for the common jobs: a strict customer import, IPv4 and IPv6 transit and peer sanity filters (bogons, too short, too long, your own prefixes, private ASNs), and an export that advertises only your prefixes and your customers.

The tester

Paste routes, one per line:

23.150.2.0/24 | 64501 64600 | 64501:555 | | | accept
10.1.0.0/16   | 64501       |           | | | reject

The fields are prefix, AS path, communities, local-preference, MED and an optional expected result. For every route you get accept or reject, which term decided it, the attributes before and after the policy, and a step-by-step trace of every term it did and didn’t match. Add accept or reject as the last field and the line becomes a pass/fail check, so a policy can be tested the way code is.

The tester follows the platform you pick. That matters, as the next section shows.

We tested it against real routers

A generator that has only ever been checked against its own idea of the syntax is a liability, so every starting point plus a set of stress scenarios (ranges, every AS-path match, community add / replace / delete / clear, MED, prepends, continue chains, IPv4 and IPv6, import and export) was loaded into a real Junos 26.2 (Juniper cRPD) and a real Cisco IOS-XE 17.18 router. 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 or reject decision and resulting attributes were compared with the tester’s prediction. They agree on every route.

Doing that turned up things the documentation doesn’t make obvious, and the tool now handles all of them:

• IOS-XE rejects very long AS-path regexes. A single private-ASN expression of roughly 250+ characters fails with % unmatched [], so the tool writes it as three permit lines (several lines in one ACL are ORed).
• continue doesn’t mean the same thing. On Junos a later term sees what earlier terms changed: add a community above and a term below can match it. On IOS every route-map sequence matches the route as it arrived, so that same policy silently stops working. The tester models the platform you pick, and the tool warns when a term depends on a change made above it on IOS.
• Well-known communities beat your export policy. A route that arrived carrying no-advertise (or no-export, toward an eBGP neighbor) is not advertised no matter what the policy accepts. Deleting the community in the policy doesn’t rescue it, and a community the policy adds doesn’t block the advertisement. Both Junos and IOS behave this way.
• What an eBGP neighbor actually receives. Your AS is added to the path, local-preference isn’t sent, and a MED goes out only if the policy sets one. A MED you received from someone else is not passed on. The export view shows exactly that.

What it doesn’t do

IOS-XR output was checked line by line against Cisco’s published Routing Policy Language syntax but not run on a router, because there is no image to run it on. Arista EOS and NX-OS haven’t been tested. Large and extended communities, free-form AS-path regexes, AS-sets and prefix limits aren’t modeled, and neither is best-path selection. The tester tells you what one policy does to one route, not which path a router will finally choose.

As with the other tools here, everything runs in your browser and nothing is sent anywhere. Treat the output as a starting point: read it, test it in a lab, and compare it with what’s already on the router (an existing policy with the same name, AS-path ACL numbers already in use on IOS) before you apply it.

The Junos Protect-RE Filter Generator was updated at the same time. It now covers RADIUS CoA (UDP/3799) and 802.1X servers, NETCONF with your own port, IKE and IPsec, LDP, RSVP, PIM, IGMP/MLD, MSDP and RIP, with IPv6 versions of each. Testing it on a real Junos 26.2 router also turned up a bug in the BGP neighbor list: a second apply-path on the same prefix-list replaces the first rather than adding to it, so the generator now uses separate lists. Thanks to J. Coke for the RADIUS CoA catch that started the update.

The Network Tools page also changed: every category is now visible with a filter box, category chips and a Cards / List toggle, and the Tools menu lists the categories.

fryguy.net/tools-bgp-policy