Guide

BGP Policy

Ze applies ordered import and export filter chains to BGP updates. Define named policy objects once, attach them globally, to a group, or to one peer, then verify both accepted routes and the routes sent onward.

Policy model

Policy has two parts:

Named filter instances under bgp { policy { ... } }.
Ordered references under filter { import [...] export [...] }.

bgp {
    policy {
        loop-detection no-self-as {
            allow-own-as 0
        }
    }

    filter {
        import [ no-self-as rpki:validate ]
    }

    group customers {
        filter {
            import [ community:scrub ]
            export [ prefix:customer-export ]
        }
    }
}

The effective chain is cumulative: automatic safety filters run first, followed by global, group, and peer references. Use insert in the editor when order matters.

Filter outcomes

A filter can:

accept the update unchanged;
reject it and stop the chain;
modify selected attributes and pass the changed update onward.

Each plugin declares whether an internal error fails open or closed. Security filters should normally reject on failure. Operational policy should make that choice explicit rather than depending on an unavailable external service.

Common policy building blocks

Ze ships filters for:

AS path matching and length;
prefix lists;
standard, large, and extended communities;
route attribute modification;
private AS removal;
address-family filtering;
RPKI and IRR validation;
RFC 4271 AS loop and RFC 4456 cluster-list loop detection.

The plugin guide documents the registered filter types and their current configuration. The generated plugin catalogue shows which plugin owns each filter.

IRR and RPKI

IRR filters build allowed prefix sets from routing registry data. RPKI validates route origin against ROAs. They answer different questions and can be used together:

IRR: is this prefix documented for this network or AS-SET?
RPKI: is the origin AS authorised by a cryptographically validated ROA?

Use the IRR filtering and RPKI guides for cache configuration, refresh, failure behaviour, and operator commands.

Attribute changes

Attribute modification belongs in an explicit export or import chain. Keep each named modifier narrow, then compose it with other filters. Typical operations include setting local preference or MED, changing next hop, and adding or removing communities.

Inspect the live plugin documentation before using increment or decrement operations. Attribute ranges and missing-attribute behaviour are validated by the owning plugin.

Redistribution

The top-level redistribute block moves selected routes between protocol RIBs. Redistribution is separate from ordinary per-peer BGP filtering, but the resulting routes still pass through the destination protocol's policy and loop-prevention rules.

Use named destinations and specify the source protocols deliberately. Avoid broad two-way redistribution unless the topology and loop controls have been proven. Connected, static, kernel, OSPF, IS-IS, and BGP route sources have different ownership and withdrawal behaviour.

See Route filters and redistribution for the current chain rules and configuration syntax.

Verify policy

Use the same route at each boundary:

ze cli -c "show bgp rib peer transit-a"
ze cli -c "show bgp rib best"
ze cli -c "show bgp irr check peer transit-a prefix 192.0.2.0/24"
ze cli -c "show bgp peer transit-b rib"

Confirm:

The route is present or absent at the expected import boundary.
The best-path result carries the intended local attributes.
Exported attributes match the destination peer's policy.
A rejected route does not reappear through redistribution.
A policy reload completes without warnings or partial application.