Route reflectors are a key part of managing the scalability of an MPLS network and are used simply to optimise BGP signalling and the management of multiple address families that are carried within the MP-BGP rib-in tables.
Normally if a PE wishes to join a VPN it will receive routes from a remote PE that’s announcing NLRI into the core network. In a scenario where route reflectors are in operation the announcement of address space is sent exclusively from a client (a PE) to a route reflector (often a P router). The route reflector then announces (or reflects) the client routes to all other clients that are peering with the route reflector; the BGP split horizon rule dictates that routes will not be announced back to the originator, thus preventing loops forming.
The function of a route reflector in an MPLS network is generally different to operation in a traditional BGP-4 environment. Route reflectors generally do not forward traffic in MPLS networks and are used exclusively on P routers. P routers are not concerned with VRFs or the MPLS VPN topology and thus do not set themselves as the next hop when receiving routes from clients. Due to this behaviour the route reflector must be able to resolve a next hop within the inet.3 routing table for the BGP routes it receives from its clients, otherwise the routes would be hidden and not propagated to other clients. The standard approach to dealing with this is to install egress LSPs from the route reflector to all of its clients. Other approaches can also use static routes to the client PEs or a default static route in inet.3; ultimately all of these solutions allow the route reflector to resolve the BGP next hop of the originator of the MP-BGP routes and thus propagate the routes to other clients.
In order to configure route reflection on a P route a cluster i.d is used to identify a specific cluster of route reflectors that can exchange routes with each other
The client routers are configured