In Cisco ACI, transit routing is the powerful capability that allows the fabric to act as a seamless intermediary, forwarding traffic between two or more external Layer 3 networks. This comprehensive guide breaks down the complex process of configuring ACI transit routing, walking you through the essential steps from setting up your route policies and match rules to applying the route control profile to the L3out external EPG. By the end of this article, you’ll have a clear, actionable understanding of how to enable efficient, policy-driven connectivity between your isolated networks.
What is ACI Transit Routing?
The ACI fabric acts as a central hub for transit routing, enabling the seamless flow of traffic between different Layer 3 networks / domains. This powerful feature allows a border leaf to redistribute routes in both directions, connecting separate routing domains through the ACI fabric. Think of it like a highway interchange: an L3out is configured to import traffic coming from an external network, an L3 network / domain, into the ACI fabric. A separate L3out is then defined to export that same traffic out of the fabric to a different L3 network / domain and to its final destination network. This bidirectional process ensures a smooth and efficient transit of data between the two domains.
Creating route maps in ACI for transit routing is all about controlling the flow of traffic using prefix lists. Each prefix list specifies which subnets from the bridge domains, external networks and other VRFs should be either imported or exported. The route control policies are configured within an L3Out, and the ACI fabric uses the “enforce route control” property to determine how the traffic is managed. By default, ACI allows all routes to be imported but is more restrictive on what it exports. These carefully defined policies, prefixes and routes are what form a prefix-based route control.
ACI Transit Routing Use cases
The use case for the ACI transit routing is to provide full connectivity between two or multiple isolated L3 domains. It also can act as a backup path between L3 domains. The layer 3 domains such as external pods, NSX-T data center, mainframes, service nodes, or WAN routers can peer with the ACI fabric to use its transit functionality between them.
Since multiple L3out policies can be deployed on a single node or multiple nodes in the fabric, a variety of protocol combinations are supported. Every protocol combination can be deployed on a single node using multiple l3out policies or multiple nodes using multiple l3out policies. Deployments of more than two protocols in different l3out policies in the fabric are supported.
Supported Transit Combination Matrix for ACI 5.2(X) – https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/5x/l3-configuration/cisco-apic-layer-3-networking-configuration-guide-52x/m_transit_routing_v2.html
ACI Transit Routing between two L3 Domains Connected with eBGP
In this section, transit routing between two L3 domains connected using eBGP to the ACI fabric (no direct connectivity between the two domains) will be demonstrated.
The Setup uses an ACI fabric running 4.2(6h) and CSR 1000V (Cloud Services Router) 15.5(3)S3.
Assumptions –
- The two L3 domains are Data Center Core and NSX virtual environment.
- eBGP between Core – ACI and NSX – ACI is already configured.
- The IP addressing and the logical setup is as shown below.
- Each L3 domains peer with two border leaf switches.
- L3 domains in the lab utilize only one CSR 1000V, in production environment redundant router should be used for resiliency.
- Contract between EPGs is not part of this demonstration. This solely focuses on control plane (routing).
- Uses BGP community string to control the redistribution of routes. There are other ways like IP prefix-list to identify and control routes for redistribution, community string is only one way.
- Uses Route map at the L3Out level. It’s also possible to apply the route-map at the neighbor level for BGP peering.
Lab Topology
Expected result –
- Only subnets (10.10.1.0/24 & 10.10.2.0/24) tagged with 64525:10 from the core domain will be advertised to the NSX domain through the ACI fabric.
- Only subnets (10.20.3.0/24 & 10.20.4.0/24) tagged with 65525:20 from the NSX domain will be advertised to the core domain through the ACI fabric.
Step 1: Verify the eBGP Neighbor-ship and BGP Routes
ACI
The ‘show ip bgp summary vrf BASH_B:BASH’ show established neighborship with both Core and NSX domains.
L3 Domain – Core
The ‘show ip bgp summary’ show an established neighborship with the ACI fabric but the ‘show ip route bgp’ shows no route learned from the BGP peering.
L3 Domain – NSX
The ‘show ip bgp summary’ show an established neighborship with the ACI fabric but the ‘show ip route bgp’ shows no route learned from the BGP peering.
Step 2: Verify the eBGP Learned Subnet has the Community as Expected on the ACI Boarder Leaf Switches
AS expected, 10.10.1.0/24 & 10.10.2.0/24 from Core, and 10.20.3.0/24 & 10.20.4.0/24 have the community string attached.
Step 3: Configure the Transit Route Profile so that the Routes with the Right Community will be Advertised to the Opposite L3 Domain
Step 3.1: Configure the Match Rule for the Community Strings
- Match 64525:10 for routes from L3 domain Core
- Match 65525:20 for routes from L3 domain NSX
This is configured under Tenant > Policies > Protocol > Match Rules
Step 3.2: Configure the Route-map for Import and Export Route Control
This is configured under Tenant > Networking > L3Outs > [L3Outs name] > Route map for import and export route control
Step 4: Apply the Route Control Profile to the L3out External EPG (InstP)
The route control profile is applied to the external EPG to have the policy at the L3Out level. The above created profile is applied on the export direction for both respected L3Outs.
This is configured under Tenant > Networking > L3Outs > [L3Outs name] > External EPGs > [External EPGs name]
Step 5: Verify the Routes Tagged with the Right Community are Routed between the two Isolated L3 Domains Through the ACI Fabric
L3 Domain – Core
The tagged routes from the NSX domain are seen on the Core domain as expected for proper functioning of the VMs on the NSX environment.
L3 Domain – NSX
The tagged routes from the core domain are seen on the NSX domain as expected for proper functioning of the VMs on the NSX environment.
