Day 61 — IRR, RPSL, Route Objects and AS-SET Based Filtering

1. Opening

Internet Routing Registries exist so operators can publish routing-policy information in a structured form. That information can be used to build filters, validate customer onboarding data and automate configuration generation. The danger is treating a useful operational registry as if it were a universally authenticated source of truth.

Internet-edge security works best when each source of routing truth has a clearly defined job. The local configuration expresses business policy. IRR data documents routing intent. RPKI validates origin authorization. BGP exposes what is actually being announced. None of those sources alone replaces the others.

The objective is therefore not merely to create a filter. It is to create a repeatable authorization workflow with enough evidence to explain why a prefix is accepted, rejected, blackholed or escalated.

2. Concept and standards behavior

RFC 2622 defines RPSL. Route/route6 objects associate a prefix with an origin AS; aut-num expresses AS policy; as-set groups ASNs; route-set and filter-set can group route-policy information. RFC 7682 discusses how IRR information can support eBGP filtering but also highlights registry-quality and authorization considerations. RIPE's current database documentation remains an authoritative implementation reference for its object model.

The series continues to separate four layers:

1. Standards behavior — what an RFC defines.
2. Registry or authorization data — what IRR/RPKI/IANA sources say.
3. Cisco implementation — how IOS XE expresses the mechanism.
4. Operator policy — what this network chooses to accept, advertise or discard.

A safe production design must state which layer is making each decision. For example, a route can be RPKI NotFound yet explicitly authorized by a customer contract and IRR object; conversely, an IRR object does not cryptographically prove resource control.

3. Scenario

Customer-A AS65030 is approved to advertise 203.0.113.0/24. A local IRR fixture contains a matching route object and an AS-SET AS65030:CUSTOMERS containing AS65030. Generate a prefix list from the approved fixture, review it, then attach it inbound.

Common lab topology

                    Transit-A / AS65020
                           |
                     192.0.2.0/30
                           |
                    EDGE1 / AS65010
                      /           \
             Customer-A           Scrubber/RTBH
              AS65030               control
                 |
          203.0.113.0/24
                           |
                    Transit-B / AS65040

All addresses and ASNs are documentation/private lab values. External registry examples are conceptual; no real organization is impersonated and no real ROA is created.

Success criteria

1. Only explicitly authorized customer prefixes are accepted.
2. Export policy cannot accidentally create transit.
3. RPKI validation state is visible but policy action remains explicit.
4. Special-purpose/bogon controls are registry-aware.
5. Blackhole signaling can be invoked only by approved sources and prefixes.
6. Incident containment is reversible and evidence-preserving.

4. Topology diagram

A matching editable SVG and PNG are stored under media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable eBGP sessions.
• A documented customer prefix inventory.
• Time-synchronized logging.
• Independent management access.
• For IRR/RPKI exercises: local snapshots or lab fixtures, not live production credentials.
• For blackhole exercises: a dedicated discard next hop/community policy and strict trigger authorization.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

ip prefix-list CUST-A-IN seq 10 permit 203.0.113.0/24
route-map CUST-A-IN permit 10
 match ip address prefix-list CUST-A-IN

router bgp 65010
 address-family ipv4
  neighbor 192.0.2.2 route-map CUST-A-IN in
 exit-address-family

Generated policy must be reviewed before deployment. Registry automation must never push directly to production without validation, diff, canary and rollback controls.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors
show bgp ipv4 unicast neighbors 192.0.2.2 received-routes
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes
show ip prefix-list
show route-map
show logging
show bgp ipv4 unicast regexp _65030$
show ip prefix-list CUST-A-IN detail

The verification question is not “does the prefix exist somewhere?” but “which evidence source authorized it, which policy matched it, and what did the router actually do?”

8. Controlled modification

Add a second approved prefix to the lab IRR fixture. Regenerate policy into a staging file, diff it against production, approve the new line, then apply only the reviewed change.

Before the change, predict whether the affected object is Adj-RIB-In, Loc-RIB, Adj-RIB-Out, FIB forwarding or an external authorization state. Re-check the same evidence after the change.

9. Fault injection

Illustrative lab — not a real incident.

Add a stale/mistyped IRR route object for 198.51.100.0/24 with origin AS65030 but do not add it to the contractual prefix inventory. The workflow should flag the disagreement instead of auto-permitting the route.

The lab changes one authorization or policy variable at a time. Do not combine an RPKI fault, IRR fault and BGP policy fault in the same experiment unless the post explicitly reaches the capstone stage.

10. Step-by-step troubleshooting

1. Identify the exact prefix, origin AS and neighbor relationship.
2. Confirm the BGP session remains Established unless session loss is part of the event.
3. Capture the received AS_PATH, origin and communities.
4. Compare the prefix against the approved customer inventory.
5. Check current IRR/RPSL data or the lab fixture.
6. Check RPKI validation state where available.
7. Check special-purpose/IANA classification when relevant.
8. Inspect import policy and prefix-list/AS-path/community matches.
9. Inspect export policy before changing inbound controls.
10. Determine whether the issue is unauthorized origin, route leak, stale registry data, bad automation or a legitimate operational change.
11. Apply the narrowest proven containment.
12. Verify forwarding, negative containment and rollback readiness.

11. Root cause and correction

The failure is automation that trusted one registry object without cross-checking the approved customer inventory. Correct the workflow so IRR-derived policy is constrained by customer authorization and, where available, RPKI state.

The correction must repair the relevant trust source or policy boundary rather than broadening filters simply to make the route appear.

12. Post-fix verification

Confirm:

• intended BGP sessions remain Established;
• approved prefixes are accepted;
• unauthorized prefixes are absent or explicitly contained;
• RPKI state/policy matches the design;
• per-neighbor export remains default-deny;
• forwarding and discard behavior match the service objective;
• logs identify the triggering event.

13. Rollback

Restore the last approved filter/policy snapshot. If the change was incident containment, preserve the evidence before removal. Never roll back by replacing a default-deny policy with permit any. A temporary exception must be prefix-, peer- and time-bounded with an owner.

14. Deep-dive engineering notes

IRR is an operational registry, not RPKI

IRR objects can be extremely useful for filter generation and relationship documentation. Their authentication/authorization quality varies by registry and object history. Treat source registry and maintenance status as part of the data.

AS-SET recursion

An AS-SET can contain other sets. Recursive expansion can become large, stale or circular. Automation should enforce recursion depth, size limits and source allowlists before generating filters.

Filter generation

The safest pipeline is registry query → normalized candidate set → customer-contract comparison → RPKI comparison → generated candidate config → diff/review → canary → deployment. Direct registry-to-router push removes the checks that make automation safe.

Route objects and observed BGP

A route object says what is registered, not what is actually announced right now. Compare registry data with live route observations and customer change notices.

Multiple IRRs

The same AS may maintain objects across several IRRs. Define an authoritative source policy for each customer rather than merging every public object indiscriminately.

14A. Production workflow — IRR-derived filter lifecycle

A production IRR workflow should start with an explicit inventory of who is allowed to authorize routing changes. The registry query is not the first step; the customer/peer record is. For each external relationship, record the contracted AS, approved maintainer or registry sources, expected AS-SET name, maximum recursive expansion size, and prefix-length boundaries.

Next, query only the approved IRR sources. Normalize the returned route/route6 objects into canonical prefix/origin tuples. Expand AS-SETs recursively with hard controls: maximum depth, maximum object count, cycle detection and a time limit. If expansion exceeds the approved boundary, fail the build rather than silently producing a huge permit list.

The candidate prefix set should then be reconciled with the customer authorization inventory. New prefixes are not automatically trusted because they appeared in IRR. Removed prefixes are not automatically deleted if a scheduled migration or registry outage is in progress. Generate a three-way diff: new in registry, removed from registry, and unchanged. Require an owner for each unexpected delta.

Where RPKI data is available, annotate every candidate prefix with validation state for the expected origin. This does not turn IRR into RPKI, but it gives reviewers useful risk context. An IRR route object matching a RPKI Valid authorization is stronger operational evidence than a lone object in an unknown-quality registry.

Generate router configuration into a staging artifact, not directly to the device. Run syntax checks, line-count bounds and a “blast-radius” report showing which neighbors inherit the filter. Compare the generated config with the currently deployed revision. A change from 20 prefixes to 2,000 prefixes should stop the pipeline even if every line is syntactically valid.

Deployment should be staged. Apply to a lab or canary edge first, re-evaluate routes using a non-disruptive mechanism where supported, inspect accepted prefixes and verify customer traffic. Then deploy to the remaining edges. Preserve the previous filter revision so rollback is deterministic.

Finally, schedule reconciliation. IRR objects age, customers migrate prefixes, AS-SETs change and registries can contain stale data. The production control is not “we generated a filter once”; it is a maintained process with freshness monitoring, exception expiry and an auditable history of why each prefix entered the allowlist.

15. Production lessons

• Record the IRR source used for every generated filter.
• Treat AS-SET expansion as untrusted input requiring limits.
• Never use IRR alone as cryptographic ownership proof.
• Diff generated policy before deployment.
• Maintain an exception register for customers whose operational state temporarily disagrees with registry data.

16. Knowledge check

1. Which source in this post documents intent, and which source can cryptographically validate origin authorization?
2. What evidence proves the router actually enforced the expected policy?
3. Why should a temporary incident exception be narrower than the permanent policy?

Answers

1. IRR/RPSL documents routing intent; RPKI ROAs support cryptographic origin authorization.
2. Received/accepted/advertised route evidence plus policy counters/logs and forwarding tests.
3. Broad exceptions can outlive the incident and silently create a new leak or hijack acceptance path.

17. Sources

• RFC 2622 — Routing Policy Specification Language (RPSL)
• RFC 2650 — Using RPSL in Practice
• RFC 7682 — Considerations for Internet Routing Registries and Routing Policy
• RIPE Database documentation — route/route6, aut-num, as-set and filter-set objects
• Cisco IOS XE 17.18.x — BGP prefix-list and route-map filtering guidance