An assessor's office deploys a single BGP route reflector in the civic core so many edge routers no longer need a full iBGP mesh. What primary purpose does that route reflector serve?
Select an answer to reveal the explanation.
Short Explanation
Think of a route reflector like the county clerk who relays messages so every department does not need a private line to every other department. Clients peer with the reflector; it reflects iBGP routes so you skip the full-mesh spaghetti.
Full Explanation
In the assessor's civic BGP core, a route reflector (RR) solves the classic iBGP full-mesh scaling problem. iBGP speakers normally will not advertise iBGP-learned routes to other iBGP peers, which forces an N*(N-1)/2 mesh as the number of edge routers grows. An RR breaks that rule for its clients: clients peer with the reflector (and often with redundancy peers), and the RR reflects eligible iBGP routes among those clients so every assessor edge does not need a private session to every other edge. That reflection role is the primary purpose called out in the stem—scaling iBGP without a full mesh—not changing how eBGP works toward ISPs.
The option that claims the RR replaces eBGP with OSPF on every ISP handoff fails by concept. Route reflection is an iBGP topology and advertisement rule inside an AS; it does not redefine the exterior peering protocol, does not make private ASNs optional, and does not convert ISP handoffs into OSPF adjacencies.
The option that says the RR encrypts civic prefixes with IPsec before they leave the ASN confuses control-plane route distribution with data-plane confidentiality. An RR forwards BGP UPDATE messages according to reflection rules; it does not establish IPsec SAs or encrypt payloads as its BGP purpose.
The option that claims the RR converts overlapping RFC1918 prefixes into unique MPLS labels without MP-BGP mixes route reflection with MPLS L3VPN constructs. Uniqueness of overlapping customer prefixes in VPNv4 is the job of route distinguishers carried in MP-BGP, not of an iBGP RR alone.
Exam caveat: ENARSI expects you to know RR client/non-client advertisement rules, cluster-id loop prevention, and that a single RR is a control-plane concentration point—redundancy usually means multiple RRs—not that an RR replaces eBGP, IPsec, or RD/RT design.
Operational check: on the RR and clients, confirm sessions are Established, that clients are configured as route-reflector clients, and that show bgp ipv4 unicast neighbors / advertised-routes shows client-learned prefixes reflected to other clients. Verify IGP reachability to next hops and watch for missing reflection when a peer is mistakenly treated as a non-client.