ACI fabric supports transit routing. This feature enables a border leaf to perform bidirectional redistribution between routing domains. A transit traffic can pass from one layer 3 domain to another layer 3 domain through ACI (the ACI acting as a transit between the two layer 3 domains). A transit route is defined to import traffic through a Layer 3 outside network of an L3out where it is to be imported. A different transit route is defined to export traffic through another L3out to the destination routing domain.
The route-maps for import and export route controls are made up of prefix-list matches. Each prefix-list consists of bridge domain (BD), external subnet prefixes in the VRF and the export prefixes that need to be advertised outside. Route control policies are defined in an l3out and controlled by properties and relations associated with the l3Out. APIC uses the enforce route control property of the l3Out to enforce route control directions. The default is to enforce control on export and allow all on import. The default scope for every route is import. These are the routes and prefixes which form a prefix-based EPG.
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
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.
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.
