Managing SD-Access Segmentation

Peter Welcher
Architect, Operations Technical Advisor

This blog is about the concepts underlying SD-Access segmentation. It covers the forms of segmentation, where enforcement can occur, and some practical advice.

Previous blogs in this series:

Forms of Segmentation

SD-Access provides a two-tier hierarchy for segmentation.

The “top” tier is virtual networks or VN’s. These are actually VRF’s in terms of implementation: separate routing domains. The SD-Access switches provide no direct way for traffic to move between VN’s. Instead, an external device is used. A “fusion router” connects to the various VN’s (VRF’s in its configuration), either leaking routes or exchanging routes selectively with global routing. A “fusion firewall” does the same thing, generally treating the VRF’s as different zones and applying stateful enforcement.

The second tier is Scalable Groups, sometimes also called security groups, SG’s.

Every VN must have at least one SG in it. There may be more than one SG in the VN.

SG’s as assigned statically as VLANs on ports or dynamically via ISE assignment of SGT (SG tag) and associated VLAN.

By default, SG’s within the same VN can route traffic to each other.

The following diagram illustrates this.

On the left, the dotted line indicates segmentation into two different SG’s in one VN, the black and the orange SG’s. The curved green lines with arrows indicate traffic between the two SG’s, as allowed or denied by SGACL’s applied to the site fabric switches via DNAC.

On the right, the black and red workstations are in two different VN’s. The heavier double line on the switches indicates this stronger segmentation. The red curved line with arrows indicates how traffic would flow between a black and a red workstation. Traffic would be denied unless an SGACL on the firewall permits the flow(s).

As we will see below, DNAC can be used to create SG policies as to what traffic is allowed between any pair of SG’s. Each policy rule can be applied uni- or bi-directionally.

One mild surprise in DNAC is that IP pools are per-VN, meaning all SG’s in a VN will normally be addressed out of the same pool. For those of us used to thinking SG = VLAN = subnet, that seems a bit odd. The key point here is that with SGACL’s and SDA, the whole point is to leverage SG’s and stay out of the IP address business as far as security. So this default addressing scheme in DNAC emphasizes that and saves us from having to specify which IP pool or subnet goes with each VLAN = SG.

Put briefly, VN = subnet with SDA. Because segmentation no longer revolves around addresses!

Practical Advice

SG’s and VN’s are used as a method of grouping devices for segmentation.   Segmentation provides places in the network for policy enforcement. In general, it appears best to view them as being global to the network, even if some are not present in all switches or sites.

One common practice is to have certain SG’s that repeat for some or most VN’s. This approach might tie VN’s to business units so that each VN having an Employee and a Contractor SG would make sense.

Some of Cisco’s documentation takes such an approach. What I have heard and believe is that having many VN’s can be a bit painful to work with, in the sense that adding a VN creates work. At the borders, each VN will require a matching VRF that has to be manually configured on a fusion device, plus policy ACL rules if the fusion is in a firewall.

Another perspective is that VN’s are strong boundaries, which should be used where a firewall is advisable to enforce traffic controls between VN’s or between a VN and the datacenter or rest of the network. In particular, if local compliance policy for something like PCI or HIPAA requires a firewall, that’s a good indication that it should probably be a separate VN. If compliance requires an audit of what’s within the boundary, having a separate VN with a firewall as a boundary might be a very good idea.

Despite this, there is a Verizon-Cisco case study on the web to the effect that VLANs may be good enough segmentation. If so, SG’s might be good enough. (“YMMV”).

Another way to think of this is “the matrix” for configuring policies, both in ISE and DNAC. If you have N VN’s, there are, in principle, N x (N-1) policies needed. The matrix is a N x N grid with each box representing a policy pair. The N-1 comes in because the diagonal isn’t needed: there’s no policy from a VN to itself.

Concerning SG’s, if there are M of them (M > N), then M x (M-1) is likely a bigger number. Not great, but it comes with the territory. This does suggest we do not want to get carried away with SG’s either.

The prevailing wisdom is to start small and add VN’s and SG’s where you need to, slowly.

You can re-assign users and devices to a new SG (and possibly thereby to a new VN) via ISE. Deploying new SG’s or VN’s is automated in DNAC, so not that onerous.

Thus, adding segments over time is quite a reasonable thing to do. Doing things this way also means you do not set yourself up for failure when migrating to SDA or first deploying SDA. Do stop adding before managing all you’ve created becomes too complicated. (Job security of the wrong kind?)

As an example, you could have a VOIP SG in each VN, but why? That would mean either firewall rules to get to voice gateways in the datacenters or per-VN interfaces on the voice gateways. Worse, it would mean that calls from a phone in VN1 to someone in VN2 would have to traverse the fusion firewall. So physical VOIP handsets, conference room systems, etc. might belong in an SG within a single large VN, or perhaps a dedicated Voice VN.

On the other hand, softphones on workstations are going to be in the workstation’s SG and VN. So you would still need to permit phones to talk to such softphones through the fusion firewall.

Yes, that’s a bit clumsy. I haven’t seen a good clean way to deal with that.

There seems to be a knee-jerk reaction of putting guests into a separate VN. I’ve seen this at several sites. That could be done, or they could just be in a Company VN with SG rules applied?

The point of bringing this up is that another consideration when planning is, “what happens if I mess up on the SG policy ACL’s?”

If two endpoints are in different VN’s, there will be no traffic between the groups. That’s good for security: what is not explicitly permitted is forbidden. If you mess up, there is no security breach. The endpoints just cannot talk to each other.

If two endpoints are in the same VN and you mess up an SGACL between SG’s, then traffic can flow. So, guest workstations might be able to send traffic to employee workstations. How strongly do you feel about that risk and its consequences?

By way of contrast, suppose you deploy multiple SG’s for employee groups to minimize lateral malware spread. If you get the SGACL’s wrong, their workstations might be able to communicate with each other. That does not have immediate consequences unless malware is already present and probing. Of course, if you don’t notice the lapse for months, then you’ve got exposure.

Networks come with trade-offs (as Russ White is fond of pointing out). Here, the trade-off is added security or risk with policy error versus support effort.

Where Does Enforcement Occur?

Traffic is classified, and tags are applied inbound (“ingress”). Enforcement is on egress, exit from an SDA switch.

The switches themselves do enforcement of SG to SG and other rules on egress. So, traffic from A to B is discarded at the SDA switch B is attached to.

We noted above that VN to VN traffic is enforced on the fusion device. If the fusion devices is a router, and if you set up routing between all the assigned subnets, then VN to VN traffic will be applied until you set up ACL’s. If you’re using a Cisco fusion firewall, then no traffic will flow between VN’s unless you create ACL’s. For simplicity, I am dodging discussing the per-interface security levels and rules in Cisco firewalls – they would work the way they normally do.

What Do I Enforce Where?

We have seen that the fabric switches do SG to SG enforcement, controlling user traffic near the users (and end devices, including IoT devices).

Exiting from a VN to another VN, or perhaps to global routing (WAN, data center, or Internet) typically occurs in a fusion firewall.  This can also be viewed as near the users. While the fabric might be used to control a user to data center traffic, it makes more sense to me to do so in the fusion firewalls. An added advantage would be generating flow records for security monitoring purposes.

The fusion firewalls would see all users to the datacenter and cross-VN traffic. They would not see user to user traffic within or between fabric sites (assuming SD-Transit).

We will revisit fusion firewalls in the next blog, where we cover fusion firewalls in more detail.


Cisco Press book, Software-Defined Access

Cisco SDA Design Guide

Cisco SDA Segmentation Design Guide (a bit dated but useful)


Disclosure Statement


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.