Full-mesh BGP is not scalable. Which options loosen the full-mesh requirements? (Select two.)

Question

Options

• ARoute reflectors
• BIBGP
• CEBGP
• DSplit horizon
• EConfederations

• A
  87% (40)
• B
  9% (4)
• C
  2% (1)
• D
  2% (1)

Explanation

The IBGP full-mesh requirement exists because the BGP split-horizon rule prevents an IBGP router from re-advertising routes learned from one IBGP peer to another IBGP peer. With N routers, this requires N*(N-1)/2 sessions, which becomes unmanageable at scale. A is correct: Route reflectors (RRs) relax the split-horizon rule for designated RR clients. Clients only need to peer with the RR(s), not every other IBGP router. The RR reflects routes between clients, eliminating the need for full mesh among clients. E is correct: Confederations divide the AS into smaller sub-ASes. Within each sub-AS, IBGP rules still apply (requiring mesh or RRs within the sub-AS), but between sub-ASes, EBGP-like rules are used, allowing route advertisement without the full-mesh constraint across the entire original AS. B is false because IBGP IS the protocol creating the full-mesh problem. C is false because EBGP is used between autonomous systems and does not address internal IBGP scaling. D is false because split horizon is the BGP rule that CAUSES the full-mesh requirement - it is not a solution to it.

No community discussion yet for this question.