For which reason do you deploy BGP confederations within a BGP transit backbone?

Question

Options

• Ato support a larger number of eBGP peer sessions
• Bto increase the number of routes that can be redistributed between the running IGP and BGP
• Cto reduce the number of eBGP routes that must be shared between autonomous systems
• Dto reduce the number of iBGP peering sessions

• A
  5% (2)
• B
  3% (1)
• D
  92% (36)

Explanation

In a standard iBGP deployment, every iBGP speaker must peer with every other iBGP speaker in the AS (full mesh), which results in n*(n-1)/2 sessions - a number that grows quadratically. BGP confederations address this by splitting the AS into smaller sub-ASes. Routers within each sub-AS maintain a full iBGP mesh only among themselves, while sub-ASes peer with each other using eBGP-like sessions (but preserve iBGP attributes). This dramatically reduces the total number of required peering sessions. Route Reflectors are the alternative approach to the same problem. Options A and C are wrong because confederations do not increase eBGP capacity or reduce eBGP route volume. Option B is wrong because confederations have no effect on redistribution between IGP and BGP.

No community discussion yet for this question.