In a multi-AS underlay design

Question

Options

• AYou must use eBGP for underlay routing within a leaf and spine topology
• BEither eBGP or iBGP for underlay routing within a leaf and spine topology will work
• CThis is a wrong design for routing protocol for the underlay
• DYou must use iBGP for underlay routing within a leaf and spine topology

• A
  90% (26)
• B
  3% (1)
• C
  7% (2)

Explanation

In a multi-AS underlay, each device (or tier) is assigned a distinct Autonomous System number. By BGP's fundamental definition, sessions between devices in different ASes must be eBGP - iBGP is exclusively for peers sharing the same AS. Therefore, eBGP is not just preferred but required when the design intentionally spans multiple ASes across leaf and spine layers.

Why the distractors fail:

• B is wrong because iBGP is categorically incompatible across different AS numbers - it's not interchangeable with eBGP in this context.
• C is wrong because multi-AS eBGP underlay is actually a well-established, industry-standard data center fabric design (used heavily in Clos/leaf-spine architectures).
• D is wrong because iBGP would require all peers to share one AS - the moment you introduce multiple ASes, iBGP cannot handle inter-AS routing.

Memory tip: Let the prefix remind you - eBGP = external = crossing AS boundaries. A multi-AS design is literally defined by external boundaries, so eBGP is the only logical fit. If you ever see "multi-AS," immediately think "must be eBGP."

No community discussion yet for this question.