Cisco SDA and Security Part IV - micro-segmentation in SDA continued (some more)

Using SGTs, we were able to control communication between endpoints in the same VN. But what happens when traffic from these endpoints leaves the fabric? At the borders, the packet is decapsulated and since the outer header is stripped, along with the VXLAN header, we lose all SGT information.

So, to understand how we can control such kind of traffic, let’s introduce a corporate server in the shared segment with an IP address of – our goal is to ensure that ODC users should not be able to talk to this corporate server.

There are several ways to do this, however, the most flexible way is via SXP tunnels. The idea is this – we need to allow the borders to do CTS role-based enforcement as well (which is not enabled by default in SDA) and pass IP to SGT mappings to the borders via an SXP tunnel between ISE and the borders.

So, let’s take this step by step. The first goal is to bring up an SXP tunnel between Border1 and ISE.

To begin with, ensure SXP is enabled in ISE:

Make sure the appropriate interface is selected here – I’ve chosen gig1 since that is my fabric facing interface on ISE:

Once the SXP service is enabled, create a domain. Typically, this is not needed and you can use the default domain as well. But with a custom SXP domain, it is much easier to control which devices you are pushing IP to SGT mappings to.

Here, as you can see, I have created a domain called “sda borders”.

The next thing is to build the actual SXP tunnel itself. An important aspect of this to remember – for every VRF that you have, a separate SXP tunnel must be built since the IP to SGT mappings will be specific to VNs (VRFs). So, before we build the tunnel, let’s ensure that there are no problems in reachability. I want to build an SXP tunnel from VLAN 3014 on Border1 (which is in VRF Corp_VN) to the ISE IP address

Let’s first create the SXP tunnel on ISE. This is where you input the SXP domain as well and using this domain, you can control which devices can get what update:

Once this is saved, configure matching parameters on Border1 as well:

Confirm that the SXP tunnel is up on both sides:

Confirm the status on ISE as well:

The “Status” says ON, so we’re good on this front. Perfect, the tunnel is up on both sides!

Remember, we still haven’t created any SGTs or SGACLs for this new corporate server. Let’s do that quickly from DNAC:

As you can see, we’ve created an SGT called “Corp_Servers” with a decimal value of 23 and assigned it to the VN “Corp_VN”.

Let’s create an SGACL now that denies communication between ODC_Users and Corp_Servers:

Once this is saved, make sure it syncs to ISE and you can see it in the ISE policy matrix as well:

Finally, it’s time to create a static IP to SGT mapping on ISE – this is what is referenced to push the SGACL to the Border. The IP address you put here is a /32 entry. Along with the IP address, select the SGT and the SXP domain as well. There is no need to select a device to deploy – the deployment happens on its own and we’ll understand how soon enough.

Prior to saving this, quickly look at the SGTs and SGACLs present on Border1

As you can see, there are no SGTs or SGACLs present currently. Let’s save the IP to SGT mapping now. After this, look at the same commands on Border1 again:

So, how did this really work behind the scenes? The SXP tunnel is used for the simple purpose of PUSHING an SGT to the device (Border1, in this case). When you save the IP to SGT mapping on ISE, the following debugs prove that the SXP tunnel is used to push this mapping to Border1:

Once Border1 learns of a new SGT, it follows the same logic as our Edges did – it sends out an Access-Request to ISE, with an AV pair that lists this new SGT it learned. ISE looks at its SGACLs and if there is any SGACL with this SGT as the destination SGT, it responds back to Border1.

ISE Live Logs confirm this Access-Request with a username of CTSREQUEST:

A packet capture confirms the same process again:

The reply shows the SGACL that ISE returned:

This entire flow can be summarized as below:

As a final confirmation of what we wanted to achieve here, let’s ping from Host2 to the Corporate Server. The pings will and are accounted for as hardware denied packets:

This confirms the packets were dropped on the border. This also concludes our little micro-segmentation journey! I hope this was informative.

For any queries, concerns or conversations, please email