With the December release of Cisco ACI v1.2 (codename Brazos), a plethora of a new capabilities were added. The first on my list to cover is the ‘Shared L3Out’; the ability to use one L3Out to provide external network connectivity across numerous private networks/VRFs. Sharing a single L3Out helps resolve some of the border leaf scale limitations in prior versions, as well as sidestep the complexity involved in configuring numerous, individual VRF-lite adjacencies as was previously required.
Given a few prerequisites, configuring the Shared L3Out feature involves a only a few steps. In a lab environment, I’ve already configured a L3Out in the common tenant with external networks learned via both OSPF peerings and static routes. I’m also feeding ACI a default route through OSPF to boot. Coke and Pepsi are serving as our customer tenants, with VMs in each for testing. Here’s a view of the routing table as seen from the border leafs:
To configure a Shared L3Out, we’ll need to perform the following:
- Create a contract in the common tenant for each customer that has a global scope.
- Create an External EPG subnet with the appropriate settings.
- Publish the contracts from step 1 under the L3Out’s External EPG.
- Consume the aforementioned contracts from each customer EPG.
- Modify each customer EPG subnet to be advertised externally and shared between VRFs.
First, we’ll create contracts to tie the L3Out in common to the EPGs in each respective customer. Because these contracts span VRFs and Tenants (and certainly Application Profiles, for that matter), Global scope is the appropriate selection.
I’m not worried about testing a specific application with this configuration, so I’ll just use the default filter which will allow all traffic.
We should wind up with individual Coke and Pepsi contracts, both having a Global scope.
Next, I’ll create the External EPG object under the already-created L3Out.
Once a name is assigned, click the [+] to add a Subnet entry.
The next set of options deserves a bit of explanation:
- Export Route Control Subnet – For use when advertising transit routes, i.e. routes learned from other L3Outs.
- Import Route Control Subnet – Only applicable when using BGP.
- External Subnets for the External EPG (formerly known as Security Import Subnet) – Use this subnet for inbound security contract purposes.
- Shared Route Control Subnet – Share this route to another VRF.
- Shared Security Import Subnet – Allow the application of security contracts across VRF instances.
- Aggegate Export – When 0.0.0.0/0 and Export Route Control are specified, export all routes.
- Aggregate Import – Applies only to BGP and 0.0.0.0/0 in the inbound direction.
- Aggregate Shared Routes – Leak all routes matching the aggregation from one VRF into another. This option doesn’t share the same 0.0.0.0/0 restriction as Export/Import Route Control.
As I am receiving the routes inbound to the fabric, sharing across VRFs through the use of contracts, the three settings shown below need to be enabled. I’ll test the Aggregate Shared Routes setting later.
Speaking of contracts, with the newly created External EPG selected, under the Policy > Contracts tab, the Coke and Pepsi contracts created in the first step need to be added as provided contracts.
Moving to the tenant portion of the configuration, the Pepsi contract is added to the Pepsi EPG as a consumed contract…
…and the Coke contract to its respective EPG as well.
Finally, the subnets associated with each EPG’s bridge domain need to be Advertised Externally (formerly known as ‘Public’), and Shared between VRFs. 10.1.1.0/24 represents the Coke subnet.
And 10.1.2.0/24 constitutes Pepsi’s subnet.
With the configuration in place, let’s check our customer routing tables on the border leafs. From both Coke and Pepsi, we see the local subnets assigned to the bridge domain, and the default 0.0.0.0/0 route being learned from the L3Out in common.
For a moment, let’s revisit the Aggregate Shared Routes setting under the External EPG Network object and compare the difference in border leaf routes with that setting enabled.
As you can see, now VRF Pepsi:default is learning everything that falls within 0.0.0.0/0 which is, well, everything.
Three of the routes selected above are being learned through OSPF, the 188.8.131.52/24 and 184.108.40.206/24 networks are reachable via static routes.