Transit Routing Use case - EIGRP with routed interfaces -

Beginning with APIC code 1.1, Cisco introduced the ability to allow routes to “Transit” the fabric. Prior to this release, the ACI Fabric was only seen as a collection of “stub” networks, meaning that the ACI Fabric would only advertise Bridge Domain subnets; it would not advertise routes received from an external routing peer to another external routing peer. This created problems with several designs, as we weren’t allowed to advertise routes learned from an external peer (i.e., a mainframe running OSPF), and then send those routes to another external router (i.e., such as a Nexus 7000).

NOTE – There are several ways of enabling transit routing. A good number of those involve configuring multiple L3outs in your Tenant (i.e., L3out #1 for a FW, L3out #2 for OSPF routing to an external router). We’ll likely cover that scenario in more depth in a future blogpost. For now, this post aims to show you how to enable Transit routing with one L3out.

Assumptions:

You have read the L3out using EIGRP blogpost and are familiar with it.
Routed Interfaces will be used from External Devices to ACI Border LEAFs
VRF is operating in Enforced Mode (meaning, we are enforcing Contracts between EPGs, which is the default operation).
Preferred Group Membership will not be used
- Note – There is a caveat of using Preferred Group Membership with L3outs; Your L3EPG Subnet will have to be defined as 0.0.0.0/1 and 128.0.0.0/1. See the link here for more details.
External Routers will be configured with an MTU of 9000
Your design includes only one L3out

Prerequisites for this design:

Configure ACI Fabric BGP route reflectors
Configure Fabric Access Policies (ACI Leaf Interfaces that connect your External Routers will need to be configured)
Tenant Configuration is complete (Application Profile, EPG, BD, Contracts / Filters, and VRF already exist)
Review the Transit Routing docs from CCO, and understand them!

Caveats for this design:

Border Leaf switches will connect to only (1) External device each (i.e., we did not connect Leaf201 to both N7K1 and N7K2). Reference DDTS CSCuy16355.
If you have a requirement to connect a border leaf to more than one external device (i.e., classic-V L3 topology), please make note of the considerations for this design which can be found in the Transit Routing section of the “Cisco APIC and Transit Routing Document” on CCO.

HW/SW requirements:

Minimum Software of APIC 1.1 is required for EIGRP and for Transit Routing
No hardware requirements

What are we trying to do?

We want traffic to successfully flow from N7K1 to ACI to N7K2. We will setup a design whereby routes from N7K1 (i.e., 111.111.111.111/32) can be advertised to ACI, and ACI will advertise it to N7K2.

Screen Shot 2017-10-24 at 1.27.31 PM.png

Configuration

This configuration builds off of the configuration we have already discussed in the L3out- Routed Interfaces with EIGRP blogpost. We will discuss the modifications to that configuration below.

Before Transit routing is enabled

Below is the routing table from our external routers, N7K1, and N7K2.

LabCore01# show ip route
IP Route Table for VRF “default”
‘*’ denotes best ucast next-hop
‘**’ denotes best mcast next-hop
‘[x/y]’ denotes [preference/metric]
‘%<string>’ in via output denotes VRF <string>

<NOTE – There is no route to the 222.222.222.222/32 from N7K2>

Enabling Transit Routing

When using EIGRP and Transit routing, there will be two additional configuration options under your L3EPG Subnet, that will allow externally learned routes to be advertised to another router.

Export Route Control Subnet – Used when you need to advertise transit routes
Aggegate Export – Export all routes, when 0.0.0.0/0 is used under your Subnet and Export Route Control is enabled

Tenant > Networking > External Routed Networks > L3out > Networks > L3EPG

Screen Shot 2017-10-24 at 2.44.54 PM.png — Enabling Export Route Control and Aggregate Export

After Transit routing is enabled

LabCore01# show ip route
IP Route Table for VRF “default”
‘*’ denotes best ucast next-hop
‘**’ denotes best mcast next-hop
‘[x/y]’ denotes [preference/metric]
‘%<string>’ in via output denotes VRF <string>

100.1.1.0/24, ubest/mbest: 1/0
*via 192.168.201.1, Eth1/9, [170/51456], 2d16h, eigrp-50, external
111.111.111.111/32, ubest/mbest: 2/0, attached
*via 111.111.111.111, Lo1, [0/0], 4w3d, local
*via 111.111.111.111, Lo1, [0/0], 4w3d, direct
192.168.1.1/32, ubest/mbest: 2/0, attached
*via 192.168.1.1, Lo0, [0/0], 4w3d, local
*via 192.168.1.1, Lo0, [0/0], 4w3d, direct
192.168.1.2/32, ubest/mbest: 1/0
*via 192.168.201.1, Eth1/9, [170/51456], 0.000000, eigrp-50, external, tag 4
294967295
192.168.50.0/24, ubest/mbest: 1/0, attached
*via 192.168.50.251, Vlan50, [0/0], 4w0d, direct
192.168.50.251/32, ubest/mbest: 1/0, attached
*via 192.168.50.251, Vlan50, [0/0], 4w0d, local
192.168.201.0/30, ubest/mbest: 1/0, attached
*via 192.168.201.2, Eth1/9, [0/0], 2d16h, direct
192.168.201.2/32, ubest/mbest: 1/0, attached
*via 192.168.201.2, Eth1/9, [0/0], 2d16h, local
192.168.202.0/30, ubest/mbest: 1/0
*via 192.168.201.1, Eth1/9, [170/51456], 0.000000, eigrp-50, external, tag 4
294967295
201.1.1.1/32, ubest/mbest: 1/0
*via 192.168.201.1, Eth1/9, [90/128576], 2d16h, eigrp-50, internal
202.1.1.1/32, ubest/mbest: 1/0
*via 192.168.201.1, Eth1/9, [170/51456], 0.000000, eigrp-50, external, tag 4
294967295
222.222.222.222/32, ubest/mbest: 1/0
*via 192.168.201.1, Eth1/9, [170/51456], 0.000000, eigrp-50, external, tag 4
294967295 . << Route from N7K2 loopback222

So whats up with the tag of “4294967295” – this is a tag added by ACI to ensure we don’t run into routing loops. See the excerpt from CCO below.

“When L3Outs are configured for transit routing with IGPs (OSPF or EIGRP), mutual route redistribution occurs between BGP and the IGP. Mutual redistribution of routes between different protocols can result in routing loops under certain scenarios. Cisco ACI adds protection for routing loops when redistributing transit routes into EIGRP or OSPF. When a transit route is redistributed into OSPF or EIGRP, the route is tagged with the tag value specified in the route tag policy. If a route is received on an OSPF or EIGRP L3Out with this tag value, the route is dropped. The default route tag policy tag value is 4294967295. The following output shows the tagged route received by the external router, and the table-map and route-map are configured to drop packets with this tag to prevent them from being advertised back into the fabric”

LabCore01# ping 222.222.222.222
PING 222.222.222.222 (222.222.222.222): 56 data bytes
64 bytes from 222.222.222.222: icmp_seq=0 ttl=252 time=1.206 ms
64 bytes from 222.222.222.222: icmp_seq=1 ttl=252 time=0.969 ms
64 bytes from 222.222.222.222: icmp_seq=2 ttl=252 time=0.953 ms
64 bytes from 222.222.222.222: icmp_seq=3 ttl=252 time=0.905 ms
64 bytes from 222.222.222.222: icmp_seq=4 ttl=252 time=0.931 ms

— 222.222.222.222 ping statistics —
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.905/0.992/1.206 ms