Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

BGP Route Server Overview

Internet Exchange Points (IXPs) present a unique BGP session scaling challenge. Unlike BGP route reflectors, which are used to scale internal BGP (IBGP) sessions within a single autonomous system, IXPs interconnect multiple independent service providers, each operating its own autonomous system.

Participants at an exchange often want to exchange reachability information with many other participants. Establishing individual external BGP (EBGP) sessions between every pair of participants does not scale well, because each new participant requires configuration changes on all existing participants.

BGP route servers, defined in RFC 7947, address this scalability problem. A route server allows IXP participants to establish a single EBGP session to the route server instead of maintaining multiple bilateral EBGP sessions. The route server receives routes from participants, applies policy, and selectively advertises routes to other participants without acting as a transit router in the forwarding path.

Although BGP route servers provide a function similar to BGP route reflectors, they are designed specifically to scale EBGP peering at exchange points rather than IBGP sessions within an autonomous system.

A BGP route server is the EBGP equivalent of an IBGP route reflector that simplifies the number of direct point-to-point EBGP sessions required in a network. EBGP route servers are transparent in terms of BGP attribute propagation so that a route received from a route server carries the set of BGP attributes (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, and Communities) if the route is from a directly connected EBGP peer.

As with an IBGP route reflector, an EBGP route server is attached to a network outside of the direct forwarding path between the EBGP peers using the route server functionality. This connectivity can be through a direct physical link, or through Layer 2 networks such as VPLS LAN or EVPN, or through an IP fabric of point-to-point EBGP links providing reachability of loopback addresses of peers (typical in data center networks).

The BGP protocol is enhanced to provide route-server capability with the following functionalities described in RFC 7947:

  • Attribute transparency for NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, and Communities.

  • Per-client policy control and multiple route-server RIBs for mitigation of path-hiding.

BGP Route Server Programmability

BGP programmability in Junos OS leverages route server functionality to enable external control of route injection and advertisement behavior. The Junos BGP JET bgp_route_service.proto API has been enhanced to support route server functionality, including the ability to:

  • Program EBGP route servers

  • Inject routes into route server–specific routing information bases (RIBs)

  • Selectively advertise routes to specific client groups through client-specific RIBs

The API includes a peer-type attribute that identifies routes as originating from EBGP or IBGP peers, allowing applications to control how routes are processed and distributed within the route server framework.

Route server functionality is generally address-family independent, although certain specific BGP attribute support may be address-family-specific (for example, AIGP is only supported for labeled-unicast address-families). Route server functionality is supported for all EBGP address families.

BGP Attribute Transparency

EBGP attribute transparency [RFC7947] for the route server is supported by modifying the normal BGP route propagation such that neither transitive nor non-transitive attributes are stripped or modified while propagating routes.

Changes to normal EBGP behavior are controlled by the route-server-client CLI configuration. The route-server-client CLI configuration at the [edit protocols bgp group group-name] hierarchy level implements route server BGP attribute transparency behavior.

  • The route server provides attribute transparency for both single-hop EBGP and multi-hop configurations. Therefore, the route-server-client configuration implicitly includes the functionality of no-nexthop-change for single-hop and multi-hop sessions. For multi-hop BGP sessions you must configure the multihop keyword.

  • The route-server-client can be configured at the protocol, group, or neighbor levels of the [edit protocol bgp] hierarchy.

  • The route-server-client configuration is applicable only when the group type is external. When the route-server-client is configured for internal groups, a configuration error is issued when attempting to commit.

  • The route-server-client configuration has no parameters.

  • Normal BGP privilege applies to the route-server-client configuration.

Note:

Attributes are handled independently with respect to attribute transparency. Even if next-hops cannot be sent unmodified by the route-server, other attributes are sent transparently as applicable for those attributes.

The following is a sample route-server-client configuration:

Next-Hop

The next-hop attribute must not be modified by imposing next-hop self or otherwise modifying the next-hop, unless explicitly configured through a policy. The route server must propagate BGP next-hops according to the third-party next-hop rules of RFC 4271.

Next-hop behavior is specified for the following route-server scenarios:

  • In the case of LAN and WAN interconnect, when the route server is connected to client peers through a shared LAN and WAN subnet, the received third-party next-hops are advertised by the route server without modification as defined in RFC 4271.

  • In the case of data center multihop interconnect, when the route server is connected to client peers through a multihop interconnect, EBGP multihop must be configured and the behavior of the no-nexthop-change CLI configuration is implicitly imposed by the route-server-client configuration. The received third-party next-hops are advertised by the route server without modification, as per the optional third-party behavior defined in RFC 4271.

  • In other cases, such as point-to-point single-hop connections between the route server and client peers, normal next-hop advertisement procedures are used to prevent advertising next-hops that could be rejected by BGP peers (for example, most BGP implementations, by default, rejects next-hops addresses that are not covered by the subnet address on non-multipoint sessions.

AS-Path

AS-Path must not be modified by prepending the route server’s local AS number. Configuring route-server-client CLI for a peer suppresses the prepending of the local AS number in the advertisements. In addition, the show route advertising-protocol bgp peer CLI command is changed for peers that are route server clients such that the local AS is not shown in the advertised metrics.

Other Attributes

  • MULTI_EXIT_DISC attribute (optional, non-transitive) must be propagated as received.

  • All community attributes, including no-advertise, no-export, and non-transitive extended communities, must be propagated as received.

  • Accumulated IGP (AIGP) attribute (optional, non-transitive) must be propagated as received.

    Note:

    Junos OS supports AIGP only for BGP-LU address families (IPv4 and IPv6).

BGP Route Server Client RIB

A route server client-specific RIB is a distinct view of a BGP Loc-RIB which can contain different routes for the same destination than other views. Route server clients, through their peer groups, may associate with one individual client-specific view or a shared common RIB.

In order to provide the ability to advertise different routes to different clients for the same destination, it is conceptually necessary to allow for multiple instances of the BGP path selection to occur for the same destination but in different client/group contexts.

To implement the high-level requirement of flexible policy control with per-client/group path selection, BGP route server takes the approach of using non-forwarding routing instances (NFIs) to multi-instance the BGP pipeline, including BGP path selection, Loc-RIB, and policy. The route server is configured to group route server clients within BGP groups configured within separate non-forwarding routing instances. This approach leverages the fact that BGP running within a routing instance does path selection and has a RIB that is separate from BGP running in other routing instances.

Example

Consider an IXP route server with three participants:

  • Client A prefers the shortest AS path

  • Client B prefers routes learned from a specific peer

    Client C accepts only customer routes

To support these requirements:

  • The route server creates separate non-forwarding routing instances

  • Each routing instance contains a BGP group for one or more clients

  • Each instance applies its own import and export policies

  • BGP path selection runs independently in each instance

As a result, the route server can advertise different best paths for the same prefix to different clients, without installing any routes in the forwarding table.

Policy Requirements and Considerations

To propagate routes between route server clients, routes are leaked between the RIBs of the routing instances based on configured policies.

Configuration of the route server for policy control includes the following considerations:

  • Route server clients should be configured within the same primary instance or routing-instance to receive the same Loc-RIB view.

  • Route server clients should be configured within their own routing-instance to receive totally unique Loc-RIB views.

  • Route server clients should be configured in different BGP peer groups in the same routing-instance to have different export policy on the same Loc-RIB view.

  • For the route server client-specific RIB views to receive all routes from other tables by default, a full-mesh of instance-import policies is configured with instance-any. When configuring instance-import with policy containing instance-any:

    • instance-any can be used in:

      • policy-statement ... term ... from

      • policy-statement ... from

      • policy-statement ... term ... to

      • policy-statement ... to

    • instance-any has no parameters.

    • Using instance-any in policies other than instance-import does not have any effect.

  • Configuring many distinct routing-instances and peer-groups impacts scale and performance.

  • The BGP forwarding-context CLI configuration at the [edit protocols bgp group neighbor] hierarchy level splits the routing instance for a BGP neighbor into a configuration instance and a forwarding instance. The BGP forwarding-context CLI configuration also supports non-forwarding instance with BGP peers configured as route-server-client where the specified instance is any instance capable of forwarding a primary or a routing-instance that is not of type no-forwarding.

Related Documentation