IRR-Driven BGP Policy Automation for a Tier 2 Nationwide ISP
Automated BGP POLICY UPDATE
The customer and the problem
BGP route filtering is the layer that actually keeps bad routes out of most networks, and at a lot of ISPs it is still updated by hand. This is the story of automating it end to end.
A Tier 2 nationwide ISP operating multiple POPs, present at several internet exchanges, running private peerings and IP transit customers on an all-Juniper network. Every new BGP session followed the same manual path: an engineer configured the interface, wrote the policies, brought up the session, and built the prefix filters by hand from whatever the peer’s IRR objects said that day. Filter updates after turn-up depended on someone remembering to run them.
The risk is well documented across the industry. RPKI adoption is real but partial: measurement work cited by RIPE Labs puts full route origin validation at 12.3 percent of ASes, with 36.2 percent validating nothing at all. What actually blocks most bad announcements today is the same thing it was 20 years ago: strict BGP route filtering built from IRR data. Filters that are only as good as their last update.
Engineering
Client: Non Disclosure
Industry: Service Provider
Services: Professional Network Services, 24/7 NOC
Technologies: BGP, IRR, RADB, IRRPT, Python
What we built
A provisioning and filter automation system with a database at its center and a web UI the engineering and operations teams use daily. The core is IRRPT, extended and integrated rather than reinvented, with bgpq3 underneath for IRR resolution and NETCONF for everything that touches a router.
Architecture overview
In the UI, a dedicated BGP sessions view holds the full lifecycle. For a new session the engineer enters the peer ASN, selects the router and interface, attaches the AS-SET where one exists, and sets the session type: IX, private peering, transit, or customer. The record lands in the SQL database, which is the single source of truth for every session the network runs.
Provisioning flow
A config-generation worker renders the session from a Jinja2 template. The session type drives everything: interface configuration, policy skeleton, BGP stanza, and assignment to the correct peer group. Deployment is one action in the UI:
- The rendered config is uploaded to the Juniper router.
- Before BGP is enabled, the system runs a reachability preflight: 1000 ICMP packets toward the peer address.
- Only on a clean test does it configure the session, then waits for Established.
- Import and export policies start as REJECT in both directions. The session comes up carrying nothing.
- The UI marks the session green: provisioned, established, filtered shut until the IRR data arrives.
The nightly IRR loop
Filter updates run on demand from the UI or automatically every 24 hours overnight. Each run, per peer:
- Reads the current prefix-list from the router config and stores it in the database.
- Runs bgpq3 against the IRR for the peer’s ASN or AS-SET, as selected in the UI.
- Writes the freshly fetched prefixes to the database with a timestamp.
- Diffs new against current, and pushes only the delta to the router over NETCONF.
- Emails the responsible department a full change report: which RIR objects changed, and which prefix-list changes they triggered.
That last step is the quiet hero. Every filter change on the network is traceable to the IRR object that caused it, with a timestamp and a diff, and nobody logged into a router to make it happen.
That last step is the quiet hero. Every filter change on the network is traceable to the IRR object that caused it, with a timestamp and a diff, and nobody logged into a router to make it happen.
Beyond filters
The same database holds contact details for every peer. What began as a CLI convenience grew into a maintenance-notification workflow in the same UI: select peers by router, by IX, by POP, or by hand, and send a custom notification to all of them. Maintenance communication went from a mailbox archaeology exercise to a 2-minute task.
Results
- In production for more than 5 years, still running.
- Every BGP session on the network is provisioned from one template set, one database, one workflow.
- Prefix filters refresh nightly from the IRR without human involvement, with a full audit trail.
- New sessions go from UI entry to established, filtered state without an engineer touching a router.
What we would do differently today
At build time the honest debate was IRRPT versus Peering Manager, and IRRPT won because its logic was easier to bend to the customer’s exact workflow. It also runs on PHP, which we mention with apologies to developers of nicer languages, and precisely that simplicity made it easy to adapt.
Today the answer would likely be different. IRRPT has gone quiet as a project, while Peering Manager has grown into a genuinely complete platform: PeeringDB synchronization that surfaces potential peers with contacts already attached, IX session discovery, routing-policy and community modeling, prefix-list generation with bgpq3 or bgpq4 underneath, config rendering with the same Jinja2 approach, and NAPALM-based deployment. Much of what we built by hand around IRRPT now exists in the tool. The architecture lesson holds either way: a database as source of truth, templates for everything, REJECT until the filters exist, and an audit trail nobody has to remember to write.
faq
What is BGP route filtering, and why automate it?
BGP route filtering is the practice of accepting only the prefixes a peer is actually authorized to announce, using prefix-lists built from their IRR objects. It is the main thing that stops route leaks and many hijacks before they spread. The problem is that IRR data changes constantly, so a filter is only correct until the next time the peer updates their objects. Automating BGP route filtering means those prefix-lists refresh on their own, every night, instead of depending on an engineer remembering to run an update.
How does IRR data drive the prefix filters?
Every peer registers the prefixes and AS-SETs they intend to announce in an Internet Routing Registry such as RIPE or RADB. Our automation runs bgpq3 against those objects for each peer, generates the resulting prefix-list, compares it to what is currently on the router, and pushes only the difference over NETCONF. The result is a filter that always reflects the peer’s latest registered policy, with a full record of what changed and why.
Does BGP route filtering replace RPKI?
No. They protect against different problems and work best together. RPKI, through route origin validation, cryptographically checks that the originating AS is authorized for a prefix, but adoption is still partial and it does not stop route leaks. IRR-based BGP route filtering restricts a session to a specific set of prefixes regardless of origin signing. Most well-run networks run both: RPKI for origin validation, and prefix filtering built from IRR data as the layer that actually bounds what each session can announce.
be our next success story!
Drop us a line! We care for your Business and are here to answer your questions 24/7