configuration bgp role

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

BGP Role (RFC 9234) prevents route leaks by declaring the business relationship between peers. When both peers advertise the Role capability, the Only To Customer (OTC) path attribute is stamped on eligible egress updates, and routes carrying OTC that arrive from a non-customer direction are rejected. Ze's implementation is the role plugin, and it enforces the RFC 9234 rules as a mandatory filter when the peer has a role configured.

A minimal working config

bgp {
    peer upstream {
        connection {
            remote { ip 10.0.0.1; }
            local  { ip 10.0.0.2; }
        }
        session {
            asn { local 65000; remote 65001; }
            family { ipv4/unicast { prefix { maximum 1000000; } } }
        }
        role {
            import customer;
            strict true;
        }
    }
}

role { import customer } declares the local role for this peer: "I am a customer of the peer on the other side". strict true requires the peer to advertise the Role capability too; if it does not, Ze rejects the session with a Role Mismatch NOTIFICATION.

Configuration reference

Path	Type	Default	Description
role/import	enum	none	The local role. One of provider, customer, rs, rs-client, peer.
role/export	list	none	Destination roles that may receive routes. Typically not needed.
role/strict	bool	false	Reject peers that do not advertise the Role capability.

Role can be set at the group level and overridden per peer, like any other inheritable setting.

The five roles

RFC 9234 defines five roles. Each one describes a business relationship from the local side's point of view.

Role	Code	Meaning
provider	0	This side sells transit to the peer (the peer is a customer).
rs	1	Route server at an IXP (the peer is a route-server-client).
rs-client	2	Client of a route server (the peer is a route server).
customer	3	This side buys transit from the peer (the peer is a provider).
peer	4	Settlement-free peering.

Valid peer pairs

The local and remote roles must form one of the five valid pairs.

Local	Remote
provider	customer
customer	provider
rs	rs-client
rs-client	rs
peer	peer

A mismatch (for example, local customer with remote peer) triggers a Role Mismatch NOTIFICATION, code 2 subcode 11, and the session is rejected.

OTC filtering

The OTC attribute (type 35) is the wire-level mechanism that RFC 9234 uses to prevent leaks. The Role plugin applies OTC rules on both the receive and the send path.

On receipt

Received from role	Action
provider, peer, rs	If OTC is not present, add OTC with the remote ASN.
customer, rs-client	If OTC is present, the route is a leak; mark it ineligible and do not install.

The first rule tags routes that come in from a non-customer direction so that downstream rules can tell whether a route has "already been leaked once" on its way to this AS. The second rule enforces the actual leak prevention: a customer sending us a route with OTC means the route has been upstreamed somewhere it should not have been, and we drop it.

On send

Sending to role	Action
customer, rs-client, peer	If OTC is not present, add OTC with the local ASN.
provider, peer, rs	Do not send routes that already have OTC.

The first rule adds OTC for routes going to a non-provider direction so that downstream can recognise leaks. The second rule prevents us from being the source of a leak: we do not propagate routes with OTC further up the hierarchy.

Strict mode

strict true is the right default for new deployments. When set, Ze requires the peer to advertise the Role capability in its OPEN message. If the peer does not advertise it, Ze sends a Role Mismatch NOTIFICATION and rejects the session.

When strict is off (the default), Ze proceeds even if the peer does not advertise Role. OTC filtering is still applied based on the local role, but the peer may not be doing its side of the work. This is useful during deployment while your peers catch up, and dangerous in the long run.

Without role

When role is not configured for a peer, no OTC processing happens for that peer. Routes flow in and out without role-based filtering. The engine does not invent a default role: you either declare one or you do not.

Verification

ze cli -c "peer upstream capabilities"

The capabilities block shows whether Role was negotiated, which role each side declared, and which side is strict. A session where Role did not negotiate shows role: no in the output.

ze show warnings            # Look for role-mismatch if the session bounces
ze show errors              # notification-sent / notification-received for Role Mismatch events

The operational report bus surfaces role-related NOTIFICATIONs through ze show errors.

See also

• BGP peers for the surrounding peer configuration.
• Policies for the filter chain context.
• Plugins: policy for the role plugin.
• In-tree BGP Role guide for the full reference.

Adapted from main/docs/guide/bgp-role.md.