In standard internal BGP implementations, all BGP systems within the AS are fully meshed so that any external routing information is redistributed among all routers 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.
To configure a router to be a route reflector, you must do the following:
- Configure multiple IBGP groups.
- Configure a cluster identifier (using the
clusterstatement) 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:
group group-name {
type internal;
peer-as autonomous-system;
neighbor address1;
neighbor address2;
}
group group-name {
type internal;
peer-as autonomous-system;
cluster cluster-identifier;
neighbor address3;
neighbor address4;
}
For a list of hierarchy levels at which you can configure 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:
group group-name {
type internal;
peer-as autonomous-system;
cluster cluster-identifier;
no-client-reflect;
neighbor address3;
neighbor address4;
}
For a list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement
 |
NOTE: BGP route reflection is not supported for VPN routing and forwarding (VRF) routing instances. |
Examples: Configuring Route Reflection
This example shows how to configure a simple route reflector. The configuration shown in Figure 9 contains three routes: 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:
You must configure all routers to run a common IGP or to have static configuration, so that they learn each other's loopback addresses.
Configure Router 1 to be a route reflector for Router 2 and a regular IBGP neighbor for Router 3:
[edit]
routing-options {
autonomous-system 65534;
}
protocols {
bgp {
group 13 {
type internal;
local-address 10.1.2.3;
neighbor 10.1.2.5;
}
group 12 {
type internal;
local-address 10.1.2.3;
cluster 1.2.3.4;
neighbor 10.1.2.4;
}
}
}
Configure Router 2 to be an IBGP neighbor to Router 1 and announce 16.0.0.0/8 to Router 1. Configure route 16.0.0.0/8 as a static route on Router 2.
[edit]
routing-options {
static {
route 16.0.0.0/8 nexthop 172.16.1.2;
}
autonomous-system 65534;
}
protocols {
bgp {
group 21 {
type internal;
local-address 10.1.2.4;
export dist-static;
neighbor 10.1.2.3;
}
}
}
policy-options {
policy-statement dist-static {
from protocol static;
then accept;
}
}
Configure Router 3 to be an IBGP neighbor to Router 1 and announce 15.0.0.0/8 to Router 1. Configure route 15.0.0.0/8 as a static route on Router 3.
[edit]
routing-options {
static {
route 15.0.0.0/8 nexthop 172.16.1.2;
}
autonomous-system 65534;
}
protocols {
bgp {
group 31 {
type internal;
local-address 10.1.2.5;
export dist-static;
neighbor 10.1.2.3;
}
}
}
policy-options {
policy-statement dist-static {
from protocol static;
then accept;
}
}
The following is the output of the show route detail command for route 16.0.0.0/8 on Router 1 and Router 3. Note that router 1 learns 16.0.0.0/8 from its client, Router 2, and reflects it to Router 3. On Router 3, the output of the show route commands include the cluster list and originator ID attributes, which are added by Router 1 when the route is reflected.
Router 1:
user@router1> show route 16.0.0.0/8 detail
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
Router 3:
user@router3> show route 16.0.0.0/8 detail
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
The following is the output of the show route detail command for route 15.0.0.0/8 on router 1 and router 2. Similar to when routes are reflected from client peers to nonclient peers, router 1 reflects a route it learns from a regular IBGP neighbor to its client. Cluster list and Originator ID attributes are added during the reflection process.
Router 1:
user@router1> show route 15.0.0.0/8 detail
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
Router 2:
user@router2> show route 15.0.0.0/8 detail
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