• Supported Platforms
• M Series
• T Series

Configuring BGP Route Reflection

In standard IBGP implementations, all BGP systems within the AS are fully meshed so that any external routing information is redistributed among all routing devices within the AS. This type of implementation can present scaling issues when an AS has a large number of internal BGP systems because of the amount of identical information that BGP systems must share with each other. Route reflection provides one means of decreasing BGP control traffic and minimizing the number of update messages sent within the AS.

In route reflection, BGP systems are arranged in clusters. Each cluster consists of at least one system that acts as a route reflector, along with any number of client peers. BGP peers outside the cluster are called nonclient peers. The route reflector reflects (redistributes) routing information to each client peer (intracluster reflection) and to all nonclient peers (intercluster reflection). Because the route reflector redistributes routes within the cluster, the BGP systems within the cluster do not have to be fully meshed.

When the route reflector receives a route, it selects the best path. Then, if the route came from a nonclient peer, the route reflector sends the route to all client peers within the cluster. If the route came from a client peer, the route reflector sends it to all nonclient peers and to all client peers except the originator. In this process, none of the client peers send routes to other client peers.

To configure route reflection, you specify a cluster identifier only on the BGP systems that are to be the route reflectors. These systems then determine, from the network reachability information they receive, which BGP systems are part of its cluster and are client peers, and which BGP systems are outside the cluster and are nonclient peers.

Note: When you configure route reflection on a Juniper Networks routing device, you can apply policy changes to the following attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Other vendors might not support policy changes to these attributes and so care must be taken with policy when migrating route reflection configurations from routing devices other than Juniper Networks devices to Juniper Networks devices.

To configure a routing device to be a route reflector, you must do the following:

• Configure multiple IBGP groups.
• Configure a cluster identifier (using the cluster statement) for groups that are members of the cluster.
• Configure all the groups with the same IBGP AS number.

To configure the route reflector, include the following statements in the configuration:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

By default, the BGP route reflector performs intracluster reflection because it assumes that all the client peers are not fully meshed. However, if the client peers are fully meshed, intracluster reflection results in the sending of redundant route advertisements. In this case, you can disable intracluster reflection by including the no-client-reflect statement within the group statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Examples: Configuring BGP Route Reflection

This example shows how to configure a simple route reflector. The configuration shown in Figure 1 contains three routers: Router 1, which is the route reflector; Router 2, which is a client; and Router 3, which is a nonclient.

The routers have the following loopback addresses:

• Router 1—10.1.2.3
• Router 2—10.1.2.4
• Router 3—10.1.2.5

You must configure all routers to run a common IGP or to have static configuration, so that they learn each other’s loopback addresses.

inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
16.0.0.0/8 (1 entry, 1 announced)
*BGP   Preference: 170/-101
Source: 10.1.2.4
Nexthop: 172.16.1.2 via fxp0.0, selected
State: <Active Int Ext>
Local AS: 65534        Peer AS: 65534
Age: 11:55        Metric2: 0
Task: BGP_65534.10.1.2.4+4327
Announcement bits (3): 2-KRT 3-BGP.0.0.0.0+179 4-BGP_Sync_Any
AS path: I
BGP next hop: 172.16.1.2
Localpref: 100
Router ID: 10.1.2.4

inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
16.0.0.0/8 (1 entry, 1 announced)
*BGP   Preference: 170/-101
Source: 10.1.2.3
Nexthop: 172.16.1.2 via fxp0.0, selected
State: <Active Int Ext>
Local AS: 65534        Peer AS: 65534
Age: 11:57      Metric2: 0
Task: BGP_65534.10.1.2.3+4619
Announcement bits (2): 2-KRT 4-BGP_Sync_Any
AS path: I <Originator>
Cluster list: 1.2.3.4
Originator ID: 10.1.2.4
BGP next hop: 172.16.1.2
Localpref: 100
Router ID: 10.1.2.3

inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
15.0.0.0/8 (1 entry, 1 announced)
*BGP   Preference: 170/-101
Source: 10.1.2.5
Nexthop: 172.16.1.2 via fxp0.0, selected
State: <Active Int Ext>
Local AS: 65534        Peer AS: 65534
Age: 11:14        Metric2: 0
Task: BGP_65534.10.1.2.5+179
Announcement bits (3): 2-KRT 3-BGP.0.0.0.0+179 4-BGP_Sync_Any
AS path: I
BGP next hop: 172.16.1.2
Localpref: 100
Router ID: 10.1.2.5

inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
15.0.0.0/8 (1 entry, 1 announced)
*BGP   Preference: 170/-101
Source: 10.1.2.3
Nexthop: 172.16.1.2 via fxp0.0, selected
State: <Active Int Ext>
Local AS: 65534        Peer AS: 65534
Age: 11:23        Metric2: 0
Task: BGP_65534.10.1.2.3+179
Announcement bits (2): 2-KRT 4-BGP_Sync_Any
AS path: I <Originator>
Cluster list: 1.2.3.4
Originator ID: 10.1.2.5
BGP next hop: 172.16.1.2
Localpref: 100
Router ID: 10.1.2.3