bgp

Pre-Alpha. This page describes behavior that may change.

The core BGP plugin implementing RFC 4271. It provides the BGP finite state machine (Idle, Connect, Active, OpenSent, OpenConfirm, Established), OPEN/UPDATE/KEEPALIVE/NOTIFICATION message handling, the peer reactor, and the plugin event bus bridge.

Category

Core.

Configuration

The plugin is loaded automatically when a bgp configuration block is present.

bgp {
    router-id 10.0.0.1;
    session { asn { local 65000; } }

    peer upstream {
        connection {
            remote { ip 10.0.0.2; }
            local  { ip 10.0.0.1; }
        }
        session {
            asn { remote 65001; }
            family { ipv4/unicast { prefix { maximum 1000000; } } }
        }
    }
}

The bgp config root triggers loading. FatalOnConfigError is set, so the daemon exits if the BGP configuration is invalid. For the full peer surface (session policy, capabilities, filters, address families, authentication) see Peers.

Multipath

bgp/multipath/ configures equal-cost multipath (ECMP) across BGP paths.

bgp {
    multipath {
        maximum-paths  4;
        relax-as-path  false;
    }
}

Leaf	Type	Default	Description
maximum-paths	uint16 (1–256)	1	Maximum number of equal-cost paths installed in the FIB for the same prefix. 1 disables multipath.
relax-as-path	boolean	false	When true, AS-path length must match but the content does not have to. Equivalent to bgp bestpath as-path multipath-relax on other vendors. When false, multipath requires identical AS-path length and content.

Multipath operates on the post-best-path selection output: after best-path picks one winner, any additional paths that tie on the usual comparison attributes (up to maximum-paths) are also installed for forwarding.

Behaviour

The reactor is the central orchestrator. On startup it parses the config tree, opens TCP listeners, and creates a peer session for each configured neighbor. Peer sessions run the RFC 4271 FSM: the connection advances through Idle, Connect, Active, OpenSent, OpenConfirm, and Established. OPEN messages negotiate capabilities. Once Established, UPDATE messages carry NLRI and path attributes, KEEPALIVE messages maintain the session, and NOTIFICATION messages signal errors.

Peer startup is deferred until all higher-tier plugins have completed their handshake. A post-startup callback on the coordinator starts peer sessions only after the plugin infrastructure is ready, preventing validate-open callbacks from arriving before dependent plugins are initialised.

Configuration changes use a three-phase transaction protocol (verify, apply, rollback). The apply phase reconciles the running peer set against the new config tree through a journaled operation that can be rolled back on failure.

Interactions

• Every other BGP plugin depends on this one. It is always the first BGP component loaded.
• Publishes peer lifecycle events and UPDATE messages to the event bus for consumption by bgp-rib, bgp-gr, bgp-watchdog, and other subscribers.
• Registers the reactor with the coordinator, which manages plugin startup ordering and the post-startup peer launch.
• The interface plugin provides link-state events that the reactor uses to react to interface changes.

Source

main/internal/component/bgp/plugin/ main/internal/component/bgp/reactor/

See also

• Plugin index
• bgp-healthcheck
• bgp-rib
• bgp-gr