#Reflection rules update#
#Reflection rules full#

#Reflection rules update#

Update messages formatted 4, replicated 4, current 0, refresh 0, limit 1000ġ0.0.40.2 Two Clusters, Intra-site and Inter-site Route Reflectionįollowing configuration has been done on router RR acting as route reflector. Topology: global, highest version: 7, tail marker: 7 Paths: (1 available, best #1, table default, RIB-failure(17)) RR#show ip bgp cluster-idsĪll (inter-cluster and intra-cluster): DISABLEDīGP routing table entry for 172.16.1.1/32, version 5 In this case RR has client-to-client reflection disabled and it reflects 172.16.1.1/32 coming from S1PE1 only to the non-client S2PE1. Let's assume AS1 is partially meshed: S1PE1 and S1PE2 form iBGP neighbourship (for instance, they are located on the same site and we want to optimize the way network processes updates). Single Cluster with Client-to-client Reflection Disabled In this particular case, update is also sent back to S1PE1, but it happens becuse S1PE1 and S1PE2 have the same routing policy and, therefore, form the same update group. These outputs show that RR receives the 172.16.1.1/32 prefix from S1PE1 and reflects it to the client S1PE2 and non-client S2PE1. Update messages formatted 3, replicated 6, current 0, refresh 0, limit 1000 Minimum time between advertisement runs is 0 secondsīGP version 4 update-group 2, internal, Address Family: IPv4 Unicast Number of NLRIs in the update sent: max 1, min 0 Update messages formatted 2, replicated 2, current 0, refresh 0, limit 1000

Refresh blocked (not in list, last not in list) Topology: global, highest version: 4, tail marker: 4įormat state: Current working (OK, last not in list) Origin IGP, metric 0, localpref 100, valid, internal, bestīGP version 4 update-group 1, internal, Address Family: IPv4 Unicast

Paths: (1 available, best #1, table default)

Global cluster-id: 172.16.3.3 (configured: 0.0.0.0)īGP client-to-client reflection: Configured UsedĪll (inter-cluster and intra-cluster): ENABLEDĬluster-id #-neighbors C2C-rfl-CFG C2C-rfl-USEīGP routing table entry for 172.16.1.1/32, version 2 In conventional designs, non-client router will be route reflector for routers in the next hierarchy level but in this example just another PE is used for simplicity. In this case, S1PE1 and S1PE2 are clients of RR while S2PE1 is non-client. Neighbor 10.0.20.2 route-reflector-client Neighbor 10.0.10.2 route-reflector-client Single Cluster with Default Settingsįollowing configuration has been done on router RR acting as route reflector.

Between clients in different clusters (inter-cluster)įolllowing are some router reflection scenarios and respective configuration examples.

Between clients in the same cluster (intra-cluster).

Thus, there are 3 types of route reflection scenarios. Multiple cluster IDs (MCID) feature allows to assign per-neighbor cluster IDs. This attribute is used for loop prevention: when router receives update which CLUSTER_LIST contains router's own cluster ID, this update is discarded.īy default cluster ID is set to the BGP router id value, but can be set to an arbitrary 32-bit value. When route reflector reflects a prefix, it creates/modifies an optional non-transitive attribute called CLUSTER_LIST by adding its own cluster ID to it.

#Reflection rules full#

RFC4456 introduces the route reflection feature which removes the need of full mesh between iBGP speakers. By default BGP speakers does not advertise iBGP-learned prefixes to iBGP peers - this is done to maintain loop prevention. Description of BGP Route ReflectionĪ BGP speaker is a BGP enabled router. Prior knowledge of BGP concepts especially clusters and route reflection is assumed. This article describes different scenarios of Border Gateway Protocol (BGP) route reflection and usage of multiple cluster IDs.