If you followed the previous 2 articles on ACI/AWS Usage configurations, ( stretched Tenant/EPG use case and AWS use case only ) you will notice that we used Shared Templates at times and Site Only Templates at other times.
In my opinion, it’s best to make a logical diagram before starting to configure using MSO. This will make it very clear on when to use what, so, you don’t have to think too much during the actual configuration.
Take for example, you wanted to do a similar configuration as the stretched Tenant/EPG use case that we went through earlier, but you did not want to do a stretched EPG. Instead you wanted to have the EPGs reside in individual sites. The configuration will only have to be slightly modified, but the basic idea is the same. Let’s look at the diagram below for such a use case.
In the above diagram, you will notice that the topology is very similar to the stretched EPG use case, except that we don’t stretch the EPG this time. Instead we have a separate EPg on the OnPrem side and a separate EPg on the AWS only side. We then have to make appropriate contracts between the 2 EPgs as needed.
So, it’s best to make a list of the templates and which Template to put what object on. Note the same idea can be extended to more than 2 sites where you would build the required templates.
From the above diagram, we can make a list like this:
- VRF: AWS+OnPrem shared Template (since VRF goes on both fabrics)
- APP Profile AP1: AWS+OnPrem shared Template (since we have the same app profile on both sites)
- epg-App: OnPrem Template only
- epg-Web: AWS Template only
- App2Web contract: AWS+OnPrem shared Template (since the contract goes on both sites)
- Web2OnPrem ext contract: AWS+OnPrem shared Template (since the contract goes on both sites)
- AWS IGW contract: AWS Template only (since this is for AWS external connectivity only)
- OnSite ExtEPg: OnPrem Template only
- AWS-2OnPremExtEPg: OnPrem Template only
- AWS only extEPg: AWS Template Only
Let’s look at another use case. In this use case we will extend the stretched EPG use case of the previous article.
We will extend that topology to:
- add another EPG on the AWS side.
- that EPG should have direct Internet connectivity from the AWS side
- that EPG should also be able to reach the corporate network
- that EPG should be able to reach the other EPGs In EPG-1 only on tcp port 1234
Before we start, let’s draw out the logical diagram first as shown below.
Now, it’s easy to make out list for our incremental configuration (the green objects)
The list would look like this:
- EPG-2: AWS Site Only
- epg1-2-epg2 contract: OnPrem+AWS site (since the contract will go to both sites
- Also, note that we are going to reuse some of the other contracts. (the IGW contract and the EPG-1 to AWS-2-OnPremExtEPg contract) Making the logical diagram makes this evident.
- However, keep in mind that the external EPG Selector will now have to be tied down. 0.0.0.0/0 will break your intent, because it will allow the 2 EC2s to communicate through the local IGW. In my case, I”ve changed the external Cloud EPG Selector to only allow my local subnet (from my MAC as shown below.)
I’m not going to go through the step by step configuration any more. If you followed in your lab the previous 2 articles the configuration will be really easy to do. I highly suggest you try this out in your own lab. Since I set this up in my lab, let’s do a quick test to verify it’s working.
From EC2-2 let’s ping the Corporate Net. 100.65.0.1
From EC2-2 let’s ping 18.104.22.168 (direct out of AWS external connection)
From EC2-2 let’s ping EC2-1 (remember our contract only allowed tcp port 1234), so this should not work.
From EC2-2 on EPG-2 let’s test to see if tcp port 1234 is working.
A quick way of testing this is by using the netcat utility. (Note before doing this make sure to add an additional cloud EPg selector for your IGW External EPg and add 0.0.0.0/0 in there, otherwise the centos Repositories will not be reachable so your yum install will not work. Once done, delete that additional selector with 0.0.0.0/0)
- first install netcat on EC2-1. To do this, ssh to EC2-1 and use the command: sudo yum -y install nmap-ncat
- Next, on EC2-1 start the netcat listen mode on port 1234 by using the command: nc -l 1234
- Now, go to EC2-2 and install telnet by using the command sudo yum -y install telnet
- Next, from EC2-2 do a telnet EC2-1_ip 1234, in my case telnet 10.0.1.100 1234
- on EC2-2 type something in. This should echo back on EC2-1
- 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