[Contents] [Prev] [Next] [Index] [Report an Error]

Route Reflection and Looping

BGP prevents looping between ASs by evaluating the AS-path attribute to determine a route’s origin. Border routers reject routes they receive from external neighbors if the AS path indicates that the route originated within the border router’s AS.

Route reflection creates the possibility of looping within an AS. Routes that originate within a cluster might be forwarded back to the cluster. Because this happens within a given AS, the AS-path attribute is of no use in detecting a loop.

Route reflectors add an originator ID to each route that identifies the originator of the route within the local AS by its router ID. If a router receives a route having the originator ID set to its own router ID, it rejects the route.

You can also use a cluster list to prevent looping. Each cluster has an identifying number, the cluster ID. For clusters with a single route reflector, the cluster ID is the router ID of the route reflector; otherwise you configure the cluster ID. The cluster list records the cluster ID of each cluster traversed by a route. When a route reflector passes a route from a client to a nonclient router outside the cluster, the reflector appends the cluster ID to the list. When a route reflector receives a route from a nonclient, it rejects the route if the list contains the local cluster ID.

What about routes that a client forwards out of the cluster? No cluster ID is needed, because clients can forward routes only to EBGP peers, that is, to peers outside the AS. Looping between ASs is prevented by the AS-path list.

The following commands configure the route reflectors for the network topology shown in Figure 46. You configure the other routers, whether nonclients or route reflector clients, as usual for IBGP and EBGP peers.

To configure router Salem as a route reflector:



host1(config)#router bgp 29 

host1(config-router)#neighbor 10.2.5.5 remote-as
29 

host1(config-router)#neighbor 10.2.5.5 route-reflector-client 

host1(config-router)#neighbor 10.2.5.6 remote-as
29 

host1(config-router)#neighbor 10.2.5.6 route-reflector-client 

host1(config-router)#neighbor 10.2.5.7 remote-as
29 

host1(config-router)#neighbor 10.2.5.8 remote-as
29 

host1(config-router)#neighbor 10.2.25.5 remote-as
325

You do not configure a cluster ID, because router Salem is the only route reflector in this cluster.

Figure 46: BGP Route Reflection

Image g013143.gif

To configure router Concord as a route reflector:



host2(config)#router bgp 29 

host2(config-router)#neighbor 10.7.1.3 remote-as
29 

host2(config-router)#neighbor 10.7.1.3 route-reflector-client 

host2(config-router)#neighbor 10.7.1.4 remote-as
29 

host2(config-router)#neighbor 10.7.1.4 route-reflector-client 

host2(config-router)#neighbor 10.7.6.2 remote-as
29

You do not configure a cluster ID, because router Concord is the only route reflector in this cluster.

To configure router Acton as a route reflector:



host3(config)#router bgp 29 

host3(config)#bgp cluster-id 23 

host3(config-router)#neighbor 10.3.1.1 remote-as
29 

host3(config-router)#neighbor 10.3.1.1 route-reflector-client 

host3(config-router)#neighbor 10.1.2.3 remote-as
29 

host3(config-router)#neighbor 10.1.2.3 route-reflector-client 

host3(config-router)#neighbor 10.3.3.4 remote-as
29 

host3(config-router)#neighbor 10.2.5.1 remote-as
29

You must configure a cluster ID, because router Acton and router Harvard are both route reflectors in this cluster.

To configure router Harvard as a route reflector:



host4(config)#router bgp 29 

host4(config)#bgp cluster-id 23 

host4(config-router)#neighbor 10.3.1.2 remote-as
29 

host4(config-router)#neighbor 10.3.1.2 route-reflector-client 

host4(config-router)#neighbor 10.1.2.1 remote-as
29 

host4(config-router)#neighbor 10.1.2.1 route-reflector-client 

host4(config-router)#neighbor 10.3.3.2 remote-as
29 

host4(config-router)#neighbor 10.2.5.2 remote-as
29

You must configure a cluster ID, because router Harvard and router Acton are both route reflectors in this cluster.

bgp client-to-client reflection

Use to reenable the reflector to reflect routes among all clients.
Client-to-client reflection is enabled by default. If the route reflector’s clients are fully meshed, you can disable reflection because it is not necessary.
If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group.
Examplehost1(config-router)#no bgp client-to-client reflection
Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP routing table, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear.
Use the no version to disable route reflection; use only if the route reflector’s clients are fully meshed.
See bgp client-to-client reflection.

bgp cluster-id

Use to configure a cluster ID on the route reflectors if the BGP cluster has more than one route reflector. For clusters with a single reflector, the cluster ID is the reflector’s router ID and does not have to be configured.
You specify a cluster ID number or an IP address of a router acting as a route reflector.
The new cluster ID is used in update messages sent after you issue the command. To force BGP to resend all routes with the new cluster ID, you must use the clear ip bgp command to perform a hard clear or a soft clear.
Use the no version to cause BGP to use the router ID as the cluster ID.
See bgp cluster-id.

neighbor route-reflector-client

Use to configure the local router as the route reflector and the specified neighbor as one of its clients. The reflector and its clients constitute a cluster. BGP neighbors that are not specified as clients are nonclients.
Route reflectors pass routes among the client routers.
Route reflection eliminates the need for all IBPG peers to be fully meshed. The members of a cluster do not have to be fully meshed, but BGP speakers outside the cluster must be fully meshed.
If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group.
If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member.
Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP routing table, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear.
Use the no version to indicate that the neighbor is no longer a client. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
See neighbor route-reflector-client.

[Contents] [Prev] [Next] [Index] [Report an Error]