Short answer: Cisco ACI uses BGP in two distinct ways: external BGP sessions on border leaf switches exchange routes with routers through an L3Out, while internal MP-BGP and spine route reflectors distribute eligible external routes to tenant leaves. This is not simply a conventional BGP fabric where every leaf peers with every other leaf; policy and tenant scope determine which routes are imported and advertised.[1][2]
What BGP does in an ACI fabric
In a conventional routed fabric, operators often configure BGP sessions between leaf and spine switches for the underlay, overlay, or both. ACI is policy-driven and abstracts much of this configuration. Its MP-BGP control plane distributes external reachability inside the fabric, while an L3Out provides the tenant's routed connection to an external network. A border leaf is simply a leaf participating in that external connection.[1]
The useful mental model is two route-exchange stages: (1) a border leaf learns routes from an external peer using the protocol configured on the L3Out, such as eBGP; (2) eligible routes are redistributed into the fabric's MP-BGP control plane, where spine route reflectors help distribute them to leaves where the tenant is deployed.[1][2]
Route flow, step by step
- An external router advertises a prefix to a border leaf over an L3Out BGP session.
- ACI applies the L3Out's inbound route-control policy and tenant/VRF context.
- The accepted route must be eligible for installation and distribution; a route present only in a protocol's received-route view is not necessarily usable or redistributed.
- MP-BGP carries eligible external reachability through the fabric using configured spine route reflectors.
- A leaf with the relevant tenant configuration can use the route for forwarding, subject to policy, endpoint and contract behavior.
- For outbound advertisements, export route-control rules decide which tenant routes are sent to the external peer.
Configuration example: conceptual external BGP on an L3Out
ACI configuration is normally expressed through APIC objects and policies rather than pasted as a complete NX-OS BGP stanza. The following is an illustrative Cisco IOS-style external-router configuration; adapt interface, ASN, authentication, address family, prefix policy and next-hop design to the actual deployment.
ip prefix-list ACI-EXPORT seq 10 permit 10.20.0.0/16 le 24
ip prefix-list ACI-IMPORT seq 10 permit 0.0.0.0/0
!
route-map TO-ACI permit 10
match ip address prefix-list ACI-EXPORT
!
route-map FROM-ACI permit 10
match ip address prefix-list ACI-IMPORT
!
router bgp 65010
neighbor 192.0.2.2 remote-as 65020
address-family ipv4
neighbor 192.0.2.2 activate
neighbor 192.0.2.2 route-map FROM-ACI in
neighbor 192.0.2.2 route-map TO-ACI out
maximum-prefix 100 80 restart 5
This sketch is not an APIC configuration recipe. In APIC, configure the external routed domain and L3Out, attach the BGP peer and route-control policy, and separately verify that the required spine nodes are enabled as fabric route reflectors. Exact menus and supported options vary by APIC release.[1][2]
Traffic engineering: what you control
Outbound from the fabric
ACI selects among available routes according to its tenant routing and policy behavior. You influence which destinations and paths are available by controlling import filters, route redistribution, and which L3Outs advertise usable routes. Validate path choice on the relevant leaf and check the external peer's advertised/received routes. A policy change that only changes an advertisement does not guarantee the remote network will select it.
Inbound toward the fabric
You can influence remote path selection by selectively advertising prefixes, using supported BGP attributes or provider communities at the external edge, and coordinating with the upstream. The remote AS makes the final decision. ACI policy determines what the fabric exports; it cannot compel an upstream to choose one circuit or guarantee symmetric return traffic.
What BGP does not decide
BGP route reachability does not by itself grant application access. ACI tenant VRFs, bridge domains, endpoint learning, contracts, route-control policy, and forwarding programming all matter. A route in a BGP table is not proof that a particular endpoint can communicate successfully.
Verification: follow the route across layers
- On the external router, check BGP neighbor state, received routes, accepted routes, advertised routes, and the installed routing-table entry (for example,
show ip bgp summary,show ip bgp,show ip route; syntax varies by platform). - In APIC, confirm the L3Out peer is operational, the correct tenant/VRF and address family are used, and inbound/outbound route-control policies are attached as intended.
- On the border leaf, confirm the route is accepted and installed in the relevant tenant VRF—not merely received from the neighbor.
- Check that the route is distributed through the fabric MP-BGP process and visible on a non-border leaf that hosts the tenant.
- Verify the destination route, next hop, and hardware forwarding entry on the leaf; then test the return path and ACI contract/policy separately.
Expected logic: neighbor Established → prefix accepted by policy → route selected/installed → fabric distribution visible → forwarding programmed on the consuming leaf → policy permits the actual flow.
Troubleshooting checklist
- Session down: check addressing, reachability, remote/local ASN, timers, authentication, interface/VLAN and address-family activation.
- Prefix received but absent from tenant routing: inspect inbound filters, route-control scope, VRF association, route validity and whether a better route wins.
- Route on border leaf but not other leaves: verify fabric MP-BGP route-reflector configuration, tenant deployment, route eligibility and route-distribution policy.
- Route visible but traffic fails: inspect next-hop resolution, forwarding programming, contracts, endpoint state, external return route, firewall/NAT and asymmetric-path handling.
- Unexpected advertisement: inspect export route-control policy and the exact peer's advertised-routes view; do not infer export from the tenant routing table alone.
- Scale or convergence issue: compare installed route counts and platform/release limits, then check control-plane health and relevant APIC faults.
How this differs from a classic BGP leaf-spine fabric
In a classic BGP EVPN/VXLAN design, engineers commonly define underlay BGP and overlay EVPN peerings, route types, and VTEP behavior explicitly. In ACI, MP-BGP is chiefly an internal mechanism for distributing external routes, and tenant networking policy is central. Do not assume that configuring an external BGP L3Out automatically creates a general-purpose EVPN overlay or that every fabric route is exported to every tenant. Cisco documents MP-BGP between leaf and spine for external-route propagation and spine route-reflector roles.[1]
Interview answer
“In ACI, external BGP normally terminates on a border leaf through an L3Out. Accepted external routes are distributed inside the fabric using MP-BGP, with spine switches acting as route reflectors. I verify the neighbor, route policy, installed tenant route, distribution to a non-border leaf, forwarding entry, and return path. BGP reachability alone does not bypass tenant contracts or guarantee remote inbound path selection.”
Related reading
- BGP EVPN Explained: VXLAN Routes, Route Types and Troubleshooting
- BGP Filtering Explained: Prefix Lists, AS-Path Filters and Maximum-Prefix
- BGP Best-Path Selection Explained
Sources
- Cisco APIC Layer 3 Networking Configuration Guide 6.2(x): Route distribution within the ACI fabric
- Cisco APIC Basic Configuration Guide 6.2(x): BGP route reflector policy
- RFC 4271: A Border Gateway Protocol 4 (BGP-4)
Related standards background: BGP's path-vector operation and attributes are specified in RFC 4271.[3]
Post a Comment