in which case I will need to configure " no-client-reflect " ,, As far as I know it's used if the clients are in full mesh and your using it so u will not reflect the same route to it , but if I have full mesh client at the first place why I am using route reflector and if the RR configured with this knob then what is the use of it ( RR )
If u r using full-mesh so no need to use RR. I will give u one scenario to use no-client-reflect when u have more than one client in the group and u don't want to reflect routes to specific neighbor from RR side, you could use this command at neighbor level
JNCIE-M/T # 1059, CCNP & CCIP
----------------------------------------------------------------------------------------------------------------------------------------If this post was helpful, please mark this post as an "Accepted Solution".Kudos are always appreciated!
Thanks for your reply , this is what I understand but in the Description in the below link it say we use it in case if we have full mesh and RR to prevent sending redundant copy of the updates
Yes that's right (Include this statement when the client cluster is fully meshed) when the client is fully meshed so no need to send route advertisement from RR
Your totally right , that is make me confuse what is the need if already there is RR to configure full mesh and then configure this knob
Good point. This knob would be useful when you are migrating from conventional full mesh BGP peering to RR peering.
Can you please illustrate an example / scenario where we use this command ? Any practical example? Why on earth would some body have both the fully meshed routers in a cluster and a network with Route reflector operational concurrently? If at all there is migration from fully meshed network to a network with RR, what is the strategy of using this command No-client-reflect?
And by the way this is also a JNCIP question. I came across this command while studying JNCIP.
Actually you might use this knob in case if you need to reflect between BGP peers reside in different groups without reflecting within the group itself, for example your router has four IBGP sessions in two different groups (2 sessions peer group), two sessions with two IGW routers in group1 and remaining two with internal PE in group2 and you need to reflect internet routes received from IGW routers to the PEs without reflecting routes between the IGW routers in group1.
This is not doable with the default configuration due to the IBGP loop prevention mechanism, and in order to circumvent this you have to configure one of the groups (group1) with the cluster knob to act as RR, however you still need to use the no-client-reflect knob to disable reflection between the IGW routers.
Recently i used no-client-reflect for my migration project.
The scenarios is as follows:
1. I have existing network A with 2 RR & 21 RR-Clients routers where most of my customer connected to RR-Client.
2. I need to migrate all the customers from network A to network B.
3. Network B router running on full-mesh & in order to get the routes from network A i would need a peering session with RR in network A.
4. i configured no-client-reflector on RR to prevent the routing loop & sending of redundant route advertisements.
This make sense..
Because during integration of new network in your example B. you dont have to flood routes of network A to network B and hence, no need to advertise network A's routes back to all client which are in network A.
I am not sure if someone is still looking for help on this topic. I was reading through it and was unable to make sense out of the use of this command, so I tested the same into the lab.
What I found is -
If you enable RR in a BGP topology and have configured no-client-reflect then RR will not advertise any routes it is receiving from a client to other Clients.
What I can think of a use for this command is for example- I don't want to reflect my routes to a particular family then I can explicitly enable no-client-reflect for that family so that routes won't be reflected to the clients for the specific family whereas everything else will be reflected.
I do see there are a lot of options available after no-client-reflect and we can have a specific use scenario for that.
shinam@R2# set protocols bgp group RR no-client-reflect family ?Possible completions:> evpn EVPN NLRI parameters> inet IPv4 NLRI parameters> inet-mdt IPv4 Multicast Distribution Tree (MDT) NLRI parameters> inet-mvpn IPv4 MVPN NLRI parameters> inet-vpn IPv4 Layer 3 VPN NLRI parameters> inet6 IPv6 NLRI parameters> inet6-mvpn IPv6 MVPN NLRI parameters> inet6-vpn IPv6 Layer 3 VPN NLRI parameters> iso-vpn ISO Layer 3 VPN NLRI parameters> l2vpn MPLS-based Layer 2 VPN and VPLS NLRI parameters> route-target Route target NLRI used for VPN route filtering> traffic-engineering Traffic Engineering (BGP-TE) NLRI parameters
If it helps great or please feel free to ask questions.
The no-client-reflect command Disable 'intracluster route redistribution' by the system acting as the route reflector.
But we need the route reflector configuration as we still need the routes from non-clients into the cluster and from cluster to non-clients. This comes into play in hierarchical RR design/ connecting to other clusters. The non-client configuration prevents the reflection within the cluster and the cluster config will still allow us to break the usual IBGP rule enabling full connectivity.
Quick summary of RR operation:
If the RR receives a route from a nonclient peer, it reflects the route to all clients.
If the RR receives a route from a client peer, it reflects the route to all nonclients and all client
peers except the client who originated the route. (Note: If you configure the parameter no- client-reflect, the RR does not reflect routes to other clients. Include this statement only when all the clients are fully meshed.)
If the RR receives a route from an EBGP peer, it reflects the route to all client and nonclient peers. In addition to these re-advertisement rules, the RR sets two BGP attributes:
Originator ID indicates the router ID of the router that originated the route into BGP.
Cluster list records the sequence of clusters that the route has traversed.
The RR uses the following rules when setting these attributes:
A RR never adds the cluster ID, cluster list, and originator ID to a route that it received from an EBGP peer or to a route learned from another protocol other than IBGP (such as static route) while reflecting.
If the reflection is client to client or client to nonclient, the cluster ID, cluster list, and originator ID are added to the route. An originator ID is created only if one is not set. The current cluster ID is added to the existing cluster list or a new cluster list is created if one is not present.
Once set, the originator ID and cluster list attributes are checked to prevent routing loops. The following routing loop checks are implemented in the JUNOS software:
If a route is received from a client in a cluster that has our own cluster ID (for the same cluster), the route is discarded and not installed in the routing table.
If a route is received from a nonclient that has our own cluster ID, the route is accepted because it might have to be reflected to another cluster if the router is supporting multiple clusters.
Do not reflect a path back to the originator of the route.
Do not reflect a path to a client if the cluster ID of the cluster to which the client belongs is
included in the cluster list.
• Discard any route received if the originator ID is the same as our router ID.