ACI

ACI Route Leaking Host Addresses

Simon Birtles

When we route leak networks between VRFs in ACI prior to version 3.x we needed to ensure that we moved the subnet configuration from the bridge domain to the EPG which meant we could have the EPG acting as a provider of a shared service to a different Tenant/VRF. The downside of this was that now we had to allocate a subnet to the EPG which kind of puts us back in the network centric world – we are trying to get away from this! What we want to do is to have the ability to span a bridge domain and subnet across a number of EPGs. One common approach is to assign a subnet to an application which may consist of many EPGs.

This limitation has been lifted with the 3.x subnet option ‘No Default SVI Gateway’ [fvSubnet \ ctrl=”no-default-gateway”]. We now leave the subnet gateway configured in the bridge domain and can even leave the scope set to “Private to VRF” in this configuration. We now configure the subnet gateway address again in the EPG Subnet configuration but we apply the subnet options “Shared between VRFs” and optionally “Advertised Externally”. We dont want to tell ACI to use this address again as the default gateway, this is already being done via the bridge domain subnet so in the EPG Subnet configuration we select the “No Default SVI Gateway” option. This tells ACI not to use this for the default gateway configuration. We now have the EPG working as a shared services provider with subnet configured in the EPG subnet leaked to the consumer EPG/VRF providing you have the correct contracts setup in the usual way in the EPG.

So this is good news, but its gets slightly better. The EPG subnet address configured does not have to be the same as the bridge domain subnet address. It must be in the network range of course or you are configuring an entirely new network which is not the point here. Lets use an example from an experience in a production network to talk about this next point.

We have an application profile with five EPGs all using the same bridge domain and IP subnet, one of these EPGs has three SQL servers, we want two (SQL-1, SQL-2) of these to be accessible from another tenant EPG (and therefore a different VRF), SQL-3 is not to be accessible from outside the VRF currently (it will in the near future). We can move hosts around EPGs and define contracts or even with VM attributes use uSeg EPGs but for ease in this situation we just want to prevent access to SQL-3 from outside the VRF. Instead of defining the entire subnet using the gateway IP and the network prefix length in the EPG subnet we create a EPG subnet and define the host address for SQL-1 i.e (10.243.176.194/32), and create another one for SQL-2 (10.243.176.195/32) and ensure these subnets have the options selected as described earlier. As long as the correct contract is in place – in this case a contract with Global scope being provided by the EPG and consumed by the other tenant EPG then only the /32 hosts you have defined will be route leaked and therefore only SQL-1 and SQL-2 will be accessible to the consumer in the other VRF. Within the local VRF access is available to all the SQL servers.

A few screenshots of the configuration;

Overview:

Bridge Domain Subnet:

EPG Subnet:

Simon Birtles

I have been in the IT sector for over 20 years with a primary focus on solutions around networking architecture & design in Data Center and WAN. I have held two CCIEs (#20221) for over 12 years with many retired certifications with Cisco and Microsoft. I have worked in demanding and critical sectors such as finance, insurance, health care and government providing solutions for architecture, design and problem analysis. I have been coding for as long as I can remember in C/C++ and Python (for most things nowadays). Locations that I work without additional paperwork (incl. post Brexit) are the UK and the EU including Germany, Netherlands, Spain and Belgium.