ferrix/docs/content/docs/guides/roles.md

+++ title = "BGP Roles" description = "Describes BGP roles and the Only to Customer attribute (RFC 9234), which Ferrix uses to detect and prevent route leaks." weight = 3 +++

A BGP role describes the relationship between two neighbors, such as provider and customer. Ferrix uses BGP roles, as specified in RFC 9234, to detect and prevent route leaks.

Understanding Route Leaks

A route leak is the advertisement of a route beyond its intended scope. A typical example is a network that receives a route from one transit provider and advertises it to another transit provider. The leaking network then carries traffic between the two providers, which neither provider intended.

Most route leaks are configuration errors. A common cause is a mismatch in the relationship that the two neighbors have configured: one neighbor treats the session as a customer session, and the other treats it as a peer session.

Supported Roles

The role statement specifies the role of the neighbor in relation to the local router. Table 1 lists the roles.

Role	The neighbor
PROVIDER	Provides transit to the local AS.
CUSTOMER	Receives transit from the local AS.
PEER	Exchanges its own routes and its customers' routes with the local AS.
ROUTE_SERVER	Is an Internet exchange route server.
ROUTE_SERVER_CLIENT	Is a client of a route server operated by the local AS.

Roles apply only to EBGP neighbors. Ferrix rejects a configuration that assigns a role to an IBGP neighbor.

Configuring BGP Roles

The following example configures a transit provider and requires the provider to confirm its role:

peers {
  name: "transit-a"
  endpoint { address: "203.0.113.1" }
  remote_asn: 64496
  role: PROVIDER
  require_role: true
}

Tip

Configure a role for every EBGP neighbor. The role enables route leak detection and ASPA verification, and a role mismatch is detected when the session is established.

Role Negotiation

Ferrix advertises its own role in the BGP Role capability of the OPEN message. For example, if the neighbor's role is CUSTOMER, Ferrix advertises the role PROVIDER.

If the neighbor advertises a role that does not correspond to the configured role, Ferrix rejects the session with the NOTIFICATION message OPEN Message Error / Role Mismatch.

If the neighbor does not advertise a role, for example because it does not implement RFC 9234, Ferrix accepts the session and uses the configured role. To reject such neighbors, configure require_role: true.

The status page displays the role of each neighbor, and indicates whether the neighbor confirmed it.

Only to Customer Attribute

The Only to Customer (OTC) attribute marks a route that can be advertised only to customers. The attribute contains the AS number that added it.

Ferrix adds the OTC attribute in the following cases:

• On import, to routes received from a provider, a peer, or a route server.
• On export, to routes advertised to a customer, a peer, or a route server client.

The attribute is retained when the route is advertised further.

Ferrix rejects a route with the OTC attribute in the following cases, with the rejection reason route leak (Only to Customer):

• The route is received from a customer or a route server client.
• The route is received from a peer, and the OTC attribute contains an AS number other than the peer's.

These checks cannot be disabled, as required by RFC 9234. They detect a route leak even if no AS on the path has published an ASPA, provided that the neighbors of the leaking AS add the OTC attribute.

Roles and Route Advertisement

If learned_routes is enabled, a route with the OTC attribute is advertised only to customers. Because Ferrix adds the attribute to routes from providers, peers, and route servers, the local router provides transit only to its customers when all neighbors have a role.

A neighbor without a role is not subject to this restriction and receives all routes. Ferrix logs a warning at startup for each such neighbor that has learned_routes enabled. See Route Advertisement.

Roles and ASPA Verification

ASPA verification depends on the direction from which a route is received. Ferrix determines the direction from the neighbor's role, and does not verify the AS paths of routes from a neighbor without a role. See AS Path Verification.