BGP Route Server Overview

 

A BGP route server is the external BGP (EBGP) equivalent of an internal IBGP (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 programmability leverages the route-server functionality. The BGP JET bgp_route_service.proto API has been enhanced to support route server functionality as follows:

  • Program the EBGP route server.

  • Inject routes to the specific route server RIB for selectively advertising it to the client groups in client-specific RIBs.

The BGP JET bgp_route_service.proto API includes a peer-type object that identifies individual routes as either EBGP or IBGP (default).

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 multihop no-nexthop-change for single-hop and multi-hop sessions.

  • 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.

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 master 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 master or a routing-instance that is not of type no-forwarding.