Brazos / v1.2 Features – Shared L3Out

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:

blog3.1_lg

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.

blog3.2_lg

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.

blog3.3_lg

We should wind up with individual Coke and Pepsi contracts, both having a Global scope.

blog3.4_lg

Next, I’ll create the External EPG object under the already-created L3Out.

blog3.5_lg

Once a name is assigned, click the [+] to add a Subnet entry.

blog3.6_lg

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.

blog3.7_lg

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.

blog3.8_lg

Moving to the tenant portion of the configuration, the Pepsi contract is added to the Pepsi EPG as a consumed contract…

blog3.9_lg

…and the Coke contract to its respective EPG as well.

blog3.10_lg

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.

blog3.11_lg

And 10.1.2.0/24 constitutes Pepsi’s subnet.

blog3.12_lg

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.

blog3.13_lg

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.

blog3.14_lg

As you can see, now VRF Pepsi:default is learning everything that falls within 0.0.0.0/0 which is, well, everything.

blog3.15_lg

Three of the routes selected above are being learned through OSPF, the 102.102.102.0/24 and 202.202.202.0/24 networks are reachable via static routes.

blog3.16_lg

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *