Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

BGP Route Reflectors

 

Understanding BGP Route Reflectors

This topic discusses using route reflectors to simplify configuration and aid in scaling. A further way to reduce the workload on a route reflector that is not in the traffic-forwarding path is to use the no-install statement at the [edit protocols bgp family family-name] hierarchy level. Starting in Junos OS Release 15.1, the no-install statement eliminates interaction between the routing protocols daemon (rpd) and other components in the Junos system such as the kernel or the distributed firewall daemon (dfwd). This interaction is eliminated by prohibiting any routes in the associated rpd routing information bases (RIBs), also known as routing tables, from being published to those components.

Note

In releases previous to Junos OS Release 15.1, you can reduce the workload on a route reflector that is not in the traffic-forwarding path by using a forwarding-table export policy that rejects routes learned from BGP.

Because of the internal BGP (IBGP) full-mesh requirement, most networks use route reflectors to simplify configuration. The formula to compute the number of sessions required for a full mesh is v * (v - 1)/2, where v is the number of BGP-enabled devices. The full-mesh model does not scale well. Using a route reflector, you group routers into clusters, which are identified by numeric identifiers unique to the autonomous system (AS). Within the cluster, you must configure a BGP session from a single router (the route reflector) to each internal peer. With this configuration, the IBGP full-mesh requirement is met.

To use route reflection in an AS, you designate one or more routers as a route reflector—typically, one per point of presence (POP). Route reflectors have the special BGP ability to readvertise routes learned from an internal peer to other internal peers. So rather than requiring all internal peers to be fully meshed with each other, route reflection requires only that the route reflector be fully meshed with all internal peers. The route reflector and all of its internal peers form a cluster, as shown in Figure 1.

Note

For some Juniper Networks devices, you must have an Advanced BGP Feature license installed on each device that uses a route reflector. For license details, see the Software Installation and Upgrade Guide.

Figure 1: Simple Route Reflector Topology (One Cluster)
Simple Route
Reflector Topology (One Cluster)

Figure 1 shows Router RR configured as the route reflector for Cluster 127. The other routers are designated internal peers within the cluster. BGP routes are advertised to Router RR by any of the internal peers. RR then readvertises those routes to all other peers within the cluster.

You can configure multiple clusters and link them by configuring a full mesh of route reflectors (see Figure 2).

Figure 2: Basic Route Reflection (Multiple Clusters)
Basic Route Reflection
(Multiple Clusters)

Figure 2 shows Route Reflectors RR 1, RR 2, RR 3, and RR 4 as fully meshed internal peers. When a router advertises a route to RR 1, RR 1 readvertises the route to the other route reflectors, which, in turn, readvertise the route to the remaining routers within the AS. Route reflection allows the route to be propagated throughout the AS without the scaling problems created by the full mesh requirement.

Note

A route reflector that supports multiple clusters does not accept a route with the same cluster ID from a non-client router. Therefore, you must configure a different cluster ID for a redundant RR to reflect the route to other clusters.

However, as clusters become large, a full mesh with a route reflector becomes difficult to scale, as does a full mesh between route reflectors. To help offset this problem, you can group clusters of routers together into clusters of clusters for hierarchical route reflection (see Figure 3).

Figure 3: Hierarchical Route Reflection (Clusters of Clusters)
Hierarchical Route
Reflection (Clusters of Clusters)

Figure 3 shows RR 2, RR 3, and RR 4 as the route reflectors for Clusters 127, 19, and 45, respectively. Rather than fully mesh those route reflectors, the network administrator has configured them as part of another cluster (Cluster 6) for which RR 1 is the route reflector. When a router advertises a route to RR 2, RR 2 readvertises the route to all the routers within its own cluster, and then readvertises the route to RR 1. RR 1 readvertises the route to the routers in its cluster, and those routers propagate the route down through their clusters.

Example: Configuring a Route Reflector

This example shows how to configure a route reflector.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

Generally, internal BGP (IBGP)-enabled devices need to be fully meshed, because IBGP does not readvertise updates to other IBGP-enabled devices. The full mesh is a logical mesh achieved through configuration of multiple neighbor statements on each IBGP-enabled device. The full mesh is not necessarily a physical full mesh. Maintaining a full mesh (logical or physical) does not scale well in large deployments.

Figure 4 shows an IBGP network with Device A acting as a route reflector. Device B and Device C are clients of the route reflector. Device D and Device E are outside the cluster, so they are nonclients of the route reflector.

On Device A (the route reflector), you must form peer relationships with all of the IBGP-enabled devices by including the neighbor statement for the clients (Device B and Device C) and the nonclients (Device D and Device E). You must also include the cluster statement and a cluster identifier. The cluster identifier can be any 32-bit value. This example uses the loopback interface IP address of the route reflector.

On Device B and Device C, the route reflector clients, you only need one neighbor statement that forms a peer relationship with the route reflector, Device A.

On Device D and Device E, the nonclients, you need a neighbor statement for each nonclient device (D-to-E and E-to-D). You also need a neighbor statement for the route reflector (D-to-A and E-to-A). Device D and Device E do not need neighbor statements for the client devices (Device B and Device C).

Tip

Device D and Device E are considered to be nonclients because they have explicitly configured peer relationships with each other. To make them RRroute reflector clients, remove the neighbor 192.168.5.5 statement from the configuration on Device D, and remove the neighbor 192.168.0.1 statement from the configuration on Device E.

Figure 4: IBGP Network Using a Route Reflector
IBGP Network Using
a Route Reflector

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device A

Device B

Device C

Device D

Device E

Step-by-Step Procedure

Configuring the Route Reflector

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IBGP in the network using Juniper Networks Device A as a route reflector:

  1. Configure the interfaces.
  2. Configure BGP, including the cluster identifier and neighbor relationships with all IBGP-enabled devices in the autonomous system (AS).

    Also apply the policy that redistributes OSPF routes into BGP.

  3. Configure static routing or an interior gateway protocol (IGP).

    This example uses OSPF.

  4. Configure the policy that redistributes OSPF routes into BGP.
  5. Configure the router ID and the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Note

Repeat these steps for each nonclient BGP peer within the cluster that you are configuring, if the other nonclient devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.

Configuring Client Peers

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure client peers:

  1. Configure the interfaces.
  2. Configure the BGP neighbor relationship with the route reflector.

    Also apply the policy that redistributes OSPF routes into BGP.

  3. Configure OSPF.
  4. Configure the policy that redistributes OSPF routes into BGP.
  5. Configure the router ID and the AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Note

Repeat these steps for each client BGP peer within the cluster that you are configuring if the other client devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.

Configuring Nonclient Peers

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure nonclient peers:

  1. Configure the interfaces.
  2. Configure the BGP neighbor relationships with the RRroute reflector and with the other nonclient peers.

    Also apply the policy that redistributes OSPF routes into BGP.

  3. Configure OSPF.
  4. Configure the policy that redistributes OSPF routes into BGP.
  5. Configure the router ID and the AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Note

Repeat these steps for each nonclient BGP peer within the cluster that you are configuring if the other nonclient devices are from Juniper Networks. Otherwise, consult the device’s documentation for instructions.

Verification

Confirm that the configuration is working properly.

Verifying BGP Neighbors

Purpose

Verify that BGP is running on configured interfaces and that the BGP session is established for each neighbor address.

Action

From operational mode, enter the show bgp neighbor command.

user@A> show bgp neighbor

Verifying BGP Groups

Purpose

Verify that the BGP groups are configured correctly.

Action

From operational mode, enter the show bgp group command.

user@A> show bgp group

Verifying BGP Summary Information

Purpose

Verify that the BGP configuration is correct.

Action

From operational mode, enter the show bgp summary command.

user@A> show bgp summary

Verifying Routing Table Information

Purpose

Verify that the routing table contains the IBGP routes.

Action

From operational mode, enter the show route command.

user@A> show route

Understanding a Route Reflector That Belongs to Two Different Clusters

The purpose of route reflection is loop prevention when the internal BGP (IBGP) routing devices are not fully meshed. To accomplish this, RRs break one of the rules of normal BGP operation: They readvertise routes learned from an internal BGP peer to other internal BGP peers.

Normally, a single RR is a member of only one cluster. Consider, for example, that in a hierarchical RR design, a tier-two RR can be the client of a tier-1 RR, but they can not be clients of each other.

However, when two RRs are clients of each other and the routes are being reflected from one cluster to another, only one of the cluster IDs is included in the cluster list. This is because having one cluster ID in the cluster list is adequate for loop prevention in this case.

Table 1 summarizes the rules that route reflectors use when filling in a reflected route's cluster list with cluster IDs.

Table 1: Rules for Route Reflectors

Route Reflection Scenario

Configuration

When reflecting a route from one of the clients to a non-client router

client -> RR -> non-client

The RR fills the cluster ID associated with that client in the cluster list of the reflected route.

When reflecting a route from a non-client router to a client router

non-client -> RR -> client

The RR fills the cluster ID associated with that client in the cluster list of the reflected route.

When reflecting a route from a client router to another client router that is in a different cluster

client1 -> RR -> client2 (different cluster)

The RR fills the cluster ID associated with client1 in the cluster list before reflecting the cluster ID to client2. The cluster ID associated with client 2 is not added.

When reflecting a route from a client router to a non-client router that is in a different autonomous system.

For example, when you have configured a tier 2 RR and 2 BGP groups one for the RR clients and the other for tier 1 RR and you are reflecting a route from one autonomous system to another autonomous system.

client -> RR -> non-client (different AS)

The RR does not fill the cluster list with the cluster-ID before reflecting the route to the non-client device because the cluster-ID is specific to one autonomous system.

Example: Configuring a Route Reflector That Belongs to Two Different Clusters

This example shows how to configure a route reflector (RRs) that belongs to two different clusters. This is not a common scenario, but it might be useful in some situations.

Requirements

Configure the device interfaces and an internal gateway protocol (IGP). For an example of an RR setup that includes the interface and IGP configuration, see Example: Configuring a Route Reflector.

Overview

In this example, Device RR1 is a route reflector for both Device R2 and Device RR2.

Device RR2 is a route reflector for Device R4.

Consider figure Figure 5.

Figure 5: Route Reflector in Two Different Clusters
Route Reflector
in Two Different Clusters

This example shows the BGP configuration on Device RR1 and Device RR2.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device RR1

Device RR2

Configuring Device RR1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device RR1:

  1. Configure the peering relationship with Device R2.
  2. Configure the peering relationship with Device R0.
  3. Configure the peering relationship with Device RR2.

Results

From configuration mode, confirm your configuration by entering the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Configuring Device RR2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device RR2:

  1. Configure the peering relationship with Device R4.
  2. Configure the peering relationship with Device RR1.

Results

From configuration mode, confirm your configuration by entering the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the Cluster ID Advertised for Route 2.2.2.2

Purpose

Verify that BGP is running on configured interfaces and that the BGP session is established for each neighbor address.

Action

From operational mode, enter the show bgp neighbor command.

user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 2.2.2.2 extensive

Meaning

The 2.2.2.2/32 route originates from the Device RR1’s client peer, Device R2. When this route is sent to RR1’s client, Device RR2, the route has the 5.5.5.5 cluster ID attached, which is the cluster ID for RR1-R2.

Checking the Cluster ID Advertised for Route 1.1.1.1

Purpose

Check the route advertisement from Device RR1 to Device RR2.

Action

From operational mode, enter the show bgp group command.

user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 1.1.1.1/32 extensive

Meaning

The 1.1.1.1/32 route originates from the Device RR1’s non-client peer, Device R0. When this route is sent to RR1’s client, Device RR2, the route has the 6.6.6.6 cluster ID attached, which is the cluster ID for RR1-RR2.

Device RR1 preserves the inbound cluster ID from Device R2 when advertising to another client in a different cluster (Device R4).

Understanding BGP Optimal Route Reflection

You can configure BGP Optimal Route Reflection (BGP-ORR) with IS-IS and OSPF as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups. This is done by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.

Client groups sharing the same or similar IGP topology can be grouped as one BGP peer group. You can configure optimal-route-reflection to enable BGP-ORR in that BGP peer group. You can also configure one of the client nodes as the primary node (igp-primary) in a BGP peer group so that the IGP metric from that primary node is used to select the best path and advertise it to the clients in the same BGP peer group. Optionally, you can also select another client node as the backup node (igp-backup), which is used when the primary node (igp-primary) goes down or is unreachable.

To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.

Note

BGP-ORR only works when IGP is used for BGP route resolution. BGP-ORR does not work when MPLSLDP/RSVP is used for route resolution.

Use the following CLI hierarchy to configure BGP-ORR:

Configuring BGP Optimal Route Reflection on a Route Reflector to Advertise the Best Path

You can configure BGP Optimal Route Reflection (BGP-ORR) with IS-IS and OSPF as the interior gateway protocol (IGP) on a route reflector to advertise the best path to the BGP-ORR client groups. This is done by using the shortest IGP metric from a client's perspective, instead of the route reflector's view.

To enable BGP-ORR, include the optimal-route-reflection statement at the [edit protocols bgp group group-name] hierarchy level.

Client groups sharing the same or similar IGP topology can be grouped as one BGP peer group. You can configure optimal-route-reflection to enable BGP-ORR in that BGP peer group.

To configure BGP-ORR:

  1. Configure optimal route reflection.
  2. Configure one of the client nodes as the primary node (igp-primary) in a BGP peer group so that the IGP metric from that primary node is used to select the best path and advertise it to the clients in the same BGP peer group.
  3. (Optional) Configure another client node as the backup node (igp-backup), which is used when the primary node (igp-primary) goes down or is unreachable.

Use the following CLI commands to monitor and troubleshoot the configuration for BGP-ORR:

  • show bgp group—View the primary and backup configurations of BGP-ORR.

  • show isis bgp-orr—View the IS-IS BGP-ORR metric (RIB).

  • show ospf bgp-orr—View the OSPF BGP-ORR metric (RIB).

  • show ospf route—View the entries in the OSPF routing table

  • show route—View the active entries in the routing tables.

  • show route advertising protocol bgp peer—Verify whether the routes are being advertised according to the BGP-ORR rules.

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.

Release History Table
Release
Description
Starting in Junos OS Release 15.1, the no-install statement eliminates interaction between the routing protocols daemon (rpd) and other components in the Junos system such as the kernel or the distributed firewall daemon (dfwd).
In releases previous to Junos OS Release 15.1, you can reduce the workload on a route reflector that is not in the traffic-forwarding path by using a forwarding-table export policy that rejects routes learned from BGP.