Cisco SDA and Security Part I - macro segmentation in SDA

Two big things standout with SD-Access - the segmentation story and native wireless integration. This post (and the next) is going to look at segmentation and how that is achieved within the SD-Access solution.


What is segmentation? In simple terms, you're creating boundaries between systems (or groups of systems). Using certain constructs, you control whether system A can talk to system B. This is a fairly common requirement in today's enterprise networks - you want to be able to separate out departments and control who can talk to whom. The constructs that we use in SD-Access have existed far before this solution was brought to life - VRFs (or, in SD-Access terms, Virtual Networks commonly abbreviated to VNs) and SGTs (Scalable Group Tags or as it was previously know, Security Group Tags).


In SD-Access, VNs are a form of macro-segmentation and SGTs are a form of micro-segmentation. The general idea is a create a major boundary between groups using VNs and then further control communication between different endpoints in the same group (VN) using SGTs. Hence, the terms 'macro' and 'micro'.




This post will cover macro segmentation while the next will tackle micro segmentation. We're going to continue using the same topology as some of the previous posts. Some minor differences - an AD has been added into the mix and now Host4 sits behind Edge1 (instead of Host1). Additionally, Host5 is connected to Edge2 via the same port as Host2 - gig1/0/6. Think of this as VDI environment - we're spinning up multiple VMs, all of which physically connect to the same port on the Edge. All these VMs must also be authenticated and authorized before accessing the network.




Each of the hosts have been marked with the expected VN they should belong to:


  • Host5 should be a part of Guest_VN

  • Host4 should be a part of ODC_Users (which belongs to Corp_VN)

  • Host2 should be a part of Corp_Users (which also belongs to Corp_VN)


By the end of this, we should understand two major things:


  • How VNs are created

  • How VNs provide a form of segmentation

  • Why SDA requires a 'Fusion' device


So, as I stated earlier, VNs are nothing but VRFs. Let's quickly revisit how to create a VN. In your DNAC GUI, traverse to the "Policy" page and click on "Virtual Network". You should get a page that lists all your VNs (including the pre-existing VNs that are created by default).



The blue "plus" sign allows you to create a new VN. Some basic parameters are needed here such as the VN name. You can also drag and drop existing SGTs to this new VN.



Once you've created your VN, you can go to the"Provision" page and from here click on "Fabric", then your fabric name and eventually your site name. Your fabric should now be visible to you:




From here, go to "Host Onboarding".



Multiple drop downs are available here - one of them is "Virtual Networks". Here, you should see your new VN. This is also where you associate IP pools to your VNs. For example, within the VN named "Corp_VN", I have the following IP pools associated:



Quick tip - hovering over the name of the pool will display the actual IP subnet associated with the pool.

You can add an IP pool to your VN by clicking on the "Add" option. This gets you to the following page where you can choose your IP pool, give a name for the Authentication Policy and specify whether the traffic in this pool is data or voice. There are some other options available as well which we're not going to get into since it is irrelevant to this post.




The "Authentication Policy" name is very important - this is what you use in your ISE authorization policies. We'll get to this in part II of this series.


Once a VN is created and saved, DNAC pushes the relevant network components that are needed to make this work in the SD-Access architecture - this includes creating a L2 VLAN for this pool across all Edges, a corresponding SVI with an anycast IP address across all Edges, creating an instance-ID in LISP and other relevant LISP configuration and so on. In this setup, let's quickly take the IP pool called "Corp_Users" to demonstrate some of this configuration.



Notice how the LISP instance-ID is also mapped to the VRF. This is VRF aware LISP, something I cover in this post, which forms the basis of macro segmentation.


Naturally, this subnet needs to be advertised out to the external world - for this, an aggregate is created on the Borders.



Now that we have an understanding of what happens when a VN is created, let's look at why or rather how these VNs provide segmentation. For this use case, let's assume that all hosts (Host2, Host4 and Host5) have already been authenticated and assigned their respective VLANs and thus, their respective VNs (we will look at the authentication piece of this, along with SGTs in the next post).


The following topology now shows the updated IPs of these hosts:



Say, Host4 (in Corp_VN) wants to reach Host5 (in Guest_VN). Since they are in two different subnets, Host4 ARPs for its default gateway (which is Edge1) and once successfully resolved, it sends the ICMP packet to Edge1.




Edge1 will look at its LISP map-cache and hit the 0.0.0.0/0 entry, which says send map-request.



It sends a LISP map-request to the map-resolver (Border1, in this case).



Remember, all of these packets are VRF specific. How are the VRFs identified? Using LISP instance-IDs. Each instance-ID uniquely maps to a VRF. A packet capture clearly confirms that the instance-ID is carried in map-requests as well:



This implies that the map-resolver will look for this prefix in the corresponding instance-ID only. Does Border1 know of this subnet or this prefix in instance-ID 4100?



Nope! Border1 will now send a negative map-reply with the shortest possible subnet mask that doesn't overlap with any other EID it knows.




This is confirmed by the following packet:



Notice the EID prefix and the EID mask - it is 192.2.16.0/21. This should now be installed in the LISP map-cache and eventually FIB on Edge1:



Edge1 encapsulates this and sends it to Border1 (or Border2) but where would they send the packet to? It will simply get blackholed on the borders.


This is why you need a fusion device - to facilitate conversation between VNs (the cleanest way of doing this would be LISP Extranet but that feature is still not available in SD-Access). You form a VRF-lite style BGP peering per VN (or VRF) towards your fusion device - this can be automated via the L3 handoff feature of DNAC.


However, since the packet is decapsulated at the border, you end up losing the VXLAN header and thus the VNI and the SGT as well.


This implies that with the addition of a fusion, you now have no restrictions in conversation between VNs which was the whole point of macro-segmentation. Sounds counter-intuitive, doesn't it? This is why a lot of customers will use a firewall as a fusion so that firewall rules can control inter-VN communication. Alternatively, we can use static IP-SGT mappings on the borders to control this as well using SXP tunnels. This is something we'll cover in the micro-segmentation post.


So, there we have it - macro-segmentation in all its glorious beauty. I hope this was informative, see y'all in the next one!

For any queries, concerns or conversations, please email contact@theasciiconstruct.com