Guide

BGP Resilience

BGP resilience is a set of separate mechanisms. Route Refresh reapplies policy without dropping the session. Graceful Restart retains forwarding during a restart. RIB persistence retains outbound state. Route reflection distributes iBGP routes without a full mesh. Use only the mechanisms the topology requires.

Route Refresh

When both peers negotiate Route Refresh, request a new advertisement without tearing down TCP:

ze cli -c "request peer transit-a refresh ipv4/unicast"
ze cli -c "request peer transit-a clear soft"

Enhanced Route Refresh adds Begin-of-RR and End-of-RR markers so stale routes can be removed after the replacement stream completes. Verify the negotiated capability with show bgp peer transit-a capabilities before relying on it.

Graceful Restart

Graceful Restart requires the bgp-gr and bgp-rib plugins. The restarting speaker advertises the capability, while the receiving speaker retains stale routes until End-of-RIB or timer expiry.

plugin {
    internal rib { use bgp-rib }
    internal gr { use bgp-gr }
}

bgp {
    peer upstream1 {
        capability {
            graceful-restart {
                restart-time 120
                long-lived-stale-time 3600
            }
        }
        process gr { receive [ state eor ] }
        process rib { receive [ state ]; send [ update ] }
    }
}

Long-Lived Graceful Restart extends the stale period and deprioritises stale routes. It is active only when both peers negotiate it. Routes carrying NO_LLGR are removed rather than retained.

See Graceful Restart for timers, stale levels, communities, and failure handling.

Restarting Ze

Use the restart path when peers should see a planned Graceful Restart:

ze signal restart

A normal stop does not claim that forwarding state will survive:

ze signal stop

After restart, confirm that peers negotiated GR, stale routes were retained only for the intended families, fresh routes replaced them, and no stale entries remain after End-of-RIB.

RIB persistence

The bgp-persist plugin tracks outbound routes and can replay them after reconnect. It complements Graceful Restart but does not replace policy or best-path calculation. Persisted state must still be reconciled with the live configuration and destination peer.

Use show bgp rib status, the peer RIB commands, and warning reports to confirm that replay completed. A reconnect should not trigger repeated full-table floods to unrelated peers.

Route reflection

Route reflection replaces an iBGP full mesh with client and non-client relationships. Ze applies ORIGINATOR_ID and CLUSTER_LIST loop protection and retains ordinary import and export policy per destination.

Design points:

Give each reflector a stable router ID and cluster identity.
Mark clients explicitly.
Use at least two reflectors for a production cluster.
Keep client export policy separate from eBGP policy.
Verify that a route learned from one client reaches other clients and eligible non-clients, but does not return to its originator.

For a task-oriented example, see the FlowSpec route-reflector guide. The same reflection topology applies to other negotiated families, subject to their plugin support.

ADD-PATH and multipath

ADD-PATH advertises more than one path for a prefix. Multipath installs equal-cost next hops in the local RIB and FIB. These are independent:

ADD-PATH changes what paths cross a BGP session.
Multipath changes what equal candidates are installed locally.

Verify send and receive modes, path identifiers, best-path state, and installed ECMP next hops separately. See ADD-PATH and the BGP protocol page for current support.

Failure checklist

During a maintenance test:

Record peer state and RIB counts.
Trigger the intended refresh, session restart, or process restart.
Watch peer state and recent events.
Confirm forwarding remains valid where GR or LLGR promises it.
Confirm stale routes disappear after refresh completion or timer expiry.
Confirm every peer receives one coherent replacement stream.
Check show warnings, show errors, and show health.