During last months i was involved into ACI deep learning that gave me the opportunity to achieve the DCACI specialist certification and, of course, the CCNP Data center certification. One of the main step to achieve the ACI certification is practice! Practice gives you the ability to surf the system GUI with agility and enforces your knowledge and the understanding of how the different object joins together.
One of the most satisfying lab i made during the training is the shared L3Out. As the majority of you knows, L3Out is an object that allows the fabric to establish a routing adjacency with an external router in order to exchange routes inbound and outbound the fabric. L3Out is generally configured under the user tenant but you can use a predefined tenant called “common” which can hosts all the shared services in a datacenter like DHCP servers, DNS servers and…external connections.
The intent of the lab is to create a shared external connection into the common tenant and leak the routes between the common and the user tenants.
The physical layout is very simple, the external router called R1 is directly attached to a leaf switch called LEA-1-102:

The logical layout is quite simple, as you can see from the picture the common tenant “peers” R1 via an eBGP connection where it will learns the default route from R1 and avertise to it the bridge domain subnets configured under the user tenant “lw-lab_TN”. Spoiler…..since the external routes (default route 0/0) is mapped into an external EPG (shared_ExtEPG) you need a contract called “shared_internet” to permit the route leaking between the tenants:

The first configuration i need is on the router R1 where i configure the routed interface and the BGP session:
interface GigabitEthernet0/0/1
description L3Out_to_LEA-1-102
ip address 172.24.1.162 255.255.255.252
negotiation auto
end
router bgp 65500
bgp log-neighbor-changes
neighbor 172.24.1.161 remote-as 65535
neighbor 172.24.1.161 description LEA-1-102
!
address-family ipv4
neighbor 172.24.1.161 activate
neighbor 172.24.1.161 send-community both
neighbor 172.24.1.161 default-originate
neighbor 172.24.1.161 soft-reconfiguration inbound
exit-address-family
Then i move to the common tenant where i configure the VRF, with default parameters, on which i’ll configure the L3Out:

After that i need to configure the L3Out and the external EPG. To configure the L3Out i can navigate the proper menĂ¹ under Tenant>Networking>L3Outs and create a new ones. The wizard mask appear and i can proceed further selecting the proper attributes for my L3Outs:




When i’ll click on the finish button the L3Out object will be created and configured on the selected leaf. Since i need to configure a shared L3Out, at this point i need to edit my external EPG and activate the shared attributes:

At this point the BGP session between R1 and the leaf is in place:

From the leaf perspective, on BGP table we are able to receive the default route from R1 but we are not advertise anything to it:

So, we need to start advertising the user subnets configured on the bridge domains. To do that we need to edit the subnet configuration on every BD and mark them as “Advertised Externally” and “Shared between VRFs”:

Our job is not over because we miss the last but fundamental configuration to leak the user subnet with the external routes, the contract. Our contract is very simple because it will permit all the IP traffic in both directions, we need to pay attention to the contract scope since it needs to works between tenants!
Under the common tenant we need to create the filter to categorize the ip traffic, then we’ll apply the filter to the subject and the subject to the contract. So let’s create the filter:

Then create the contract called “shared internet” with a subject that recalls the newly created filter. Take note that the contract scope is global!


Last but not least we need to apply the contract to ours EPG in order to achieve the route leaking so we will apply the contract to the external EPG as a provider and to user tenant vzAny as a consumer:


After that, the BGP table on R1 is populated with the user tenants routes which now are able to reach external destinations:

