A housing authority must scale iBGP so closet PE routers do not require a full mesh to every other iBGP speaker. What is the primary purpose of deploying route reflectors?
Select an answer to reveal the explanation.
Short Explanation
Full-mesh iBGP is every closet calling every other closet—n squared phone lines. A route reflector is the switchboard: clients peer with the reflector, and it passes the routes along. Same iBGP rules, way fewer sessions.
Full Explanation
BGP route reflectors allow a hierarchy in which clients peer with reflectors that advertise learned iBGP routes to other clients and non-client peers, avoiding an n-squared full mesh. A housing authority that must scale iBGP so closet PE routers do not require a full mesh to every other iBGP speaker should deploy route reflectors primarily to relax that full-mesh requirement by reflecting routes from clients to other clients and non-clients. Use reflectors for iBGP scalability inside the civic ASN while keeping an IGP for session and next-hop reachability.
Route reflectors do not convert every iBGP client session into eBGP with a private ASN per closet. They do not eliminate the need for an IGP underneath iBGP loopback peering. They do not replace BGP entirely with OSPF stub areas for Internet table scale—OSPF cannot substitute for Internet-scale BGP tables on civic edges.
Exam caveat: follow reflector client and non-client rules carefully, and deploy redundant reflectors so a single control-plane node is not a chokepoint for the housing authority. Operational check: peer closet PEs only to reflectors, confirm they learn iBGP routes they would have missed without a mesh, verify next-hop reachability via IGP, and test redundancy by withdrawing one route reflector.