Shared services such as DNS, Active Directory (AD), or other authentication services deployed in a tenant in an on-premises ACI site can be securely consumed by endpoints in other tenants spread across other Cisco ACI and AWS sites. This enabled services to connect from on-premises to the cloud site while each site has it’s own VRF within a tenant. Currently, the Shared Services provider needs to be on the onPremise side.
This makes it easier to deploy new applications in the cloud, and consume shared services from the brownfield network on premises, without having to redeploy them for applications hosted in the cloud.
Please see: Use-case scenarios on CCO
In this short blog, I’ll point out the details of how to configure Shared services between OnPrem and AWS Site using MSO.
As always, before we proceed let’s make sure we know the guidelines and limitations for shared services between OnPrem and AWS site.
Guidelines and Limitations
- Inter-Tenant shared services are not supported in the current release.
- Inter-VRF services are supported within the same Tenant only.
- For shared services across different VRFs, each on-premises site can have no more than one VRF stretched to one or more cloud sites.
- Multiple VRFs can be stretched between cloud sites only.
- When creating the shared services contract between the cloud EPG and on-premises EPG across different VRFs within same tenant, the Contract’s scope must be set to tenant.
- There is a one to one mapping of AWS Account to a Cloud ACI tenant. Hence, one MUST use only one AWS Account to deploy a Cloud ACI tenant.
Going back to our discussion…
I’ll keep this blog short and only point out the details to make the shared services / route leaking configuration work. I’m not going to go through every detail of other configuration step by step because I show that in the previous ACI/AWS posts.
To start off with, let’s follow the advise from the previous post on Templates
- Draw out a logical diagram
- Make a list of what objects to put in what template
The Logical diagram is shown below:
In the diagram above you will notice the following:
- We stretch the Tenant across both OnPrem and AWS sites
- each site has it’s own VRF
- OnPrem Site has it’s own BD with default gateway of 11.5.1.1/24
- AWS Site has 10.1.1.0/24 defined in the AZ
- OnPrem site has “epg-shared-svc”.
- AWS Site has epg-web
- OnPrem site has a VM with IP 11.5.1.11/24
- AWS Site has an EC2 with IP of 10.1.1.100/24
- AWS site has an IGW (Internet Gateway — external EPG in ACI talk)
- AWS site has a contract between it’s epg (epg-web) to the IGW (Aws-extEPG1)
- A contract “web-2-sharedSvc-contract” exists between AWS EPG “epg-web” and OnSite EPg “epg-shared-svc”
Let’s now make a list of what object goes in what Template:
If you think about it we will have to make 3 templates in our schema:
- OnPrem+AWS template — for shared objects going to both sites
- AWS-Only template — for AWS site only
- OnPrem-Only template — for OnPrem site Only
Now let’s list out what goes in each of these templates:
OnPrem+AWS Shared Template:
- web-2-sharedSvc contract — since this contract needs to be applied between the epgs and need to be on both sites
- Contract Filter associated with the above contract
AWS-Only Template:
- app1 — this App Profile belongs to AWS site only
- epg-web — this epg goes on only the AWS site
- aws-vrf1 — this VRF goes only on AWS site
- AWS-ExtEPG-Contract and it’s associated filter
- AWS-ExtEPG1 — this external EPG goes on AWS site only
OnPrem-Only Template:
- app-sharedSvc – this App Profile belongs to onPerm site only
- epg-shared-svc — this epg goes only on onPrem site
- bd-sharedSvc – since this bd goes only on onPrem site
- VRF onPrem-sharedSvc — this VRF goes only on onPrem site
If you follow the above list, and refer to the diagram you could easily build this tenant. From the knowledge gained from the previous posts on how to configure, this should be a breeze.
The only thing thats new here is the route leaking configuration needed between the VRFs of the OnPrem site and AWS Site.
Route Leaking configuation:
If you are used to operating ACI you will probably already have guessed what needs to be done for route leaking between the VRFs.
The only item that you need to know is that for this to work, when you attach the contract, the cloud EPG side needs to be the consumer. The OnPrem site needs to be the provider.
Below are the steps to enable route Leaking:
- Make the Contract (in the shared template) that needs to go between the epgs from the AWS site and the OnPrem site. Ensure that the scope of the Contract is Tenant.
- apply the contract between the AWS EPG and OnPrem EPG. Make sure that the AWS side is the consumer and OnPrem epg is the provider
- when defining the BD Default Gateway on the OnPrem site, make sure to have “Advertise Extenally” checked as shown below
- On the site local for OnPrem-Only template, click on the EPG and make sure to put a IP from the BD subnet on the EPG. Make sure that this IP is not the same as the BD default gateway IP. In this case the BD default gateway is 11.5.1.1/24. So, we ware using 11.5.1.254/24 on the EPG.
- Make sure that the following boxes are checked on the IP that you define:
- Advertise Externally
- Shared Between VRF’s
- No Default SVI Gateway
That’s all !
Let’s quickly test this out in the lab setup
Test Results
ssh into the EC2 instance and try to ping the VM on the shared services side. In our case the contract had filter as “unspecified” so ping should work. “ping 11.5.1.11”
References:
- Cisco Cloud ACI on AWS White Paper
- Cisco Cloud ACI on Microsoft Azure White Paper
- Internet Service for Cisco Cloud APIC Workloads: (how to create untrusted user)
- Cisco Cloud APIC for AWS Installation Guide, Release 4.2(x)
- Shared On-Premises L3Out for Cisco Cloud APIC Workloads
- Cloud APIC Install Guide-Azure
- Cisco Cloud on Azure White Paper
- Cloud APIC Insall / Upgrade & Configure Guide