Micro-Segmentation: The Matrix Is Correct and Nothing Is Enforced

Micro-segmentation is the part of SD-Access that delivers most of the security value and depends on a component outside the fabric entirely. The switches carry group tags and enforce policies; they do not decide what tag an endpoint gets or what the policy between two groups is. Both of those come from the identity services platform, which means the fabric's security behaviour is only as correct as an integration that runs over RADIUS and a publish-subscribe channel.

The consequence is that micro-segmentation failures divide cleanly into two kinds and the division is not obvious from the symptom. Either the endpoint got the wrong tag, which is an authentication and authorisation problem, or the policy between two tags is not what was intended, which is an authoring and distribution problem. Both present as traffic being permitted or denied incorrectly, and they are investigated in different places with different commands.

This article covers what the identity platform contributes, how an endpoint acquires a group tag and what happens when it cannot, how policies get from the authoring interface to the switch that enforces them, how to design a matrix that remains manageable, and the failures that silently permit or deny — the ones where enforcement looks configured and is not doing what the matrix says.

 

What Does ISE Actually Contribute to a Fabric?

What is the division of labour?

The switches carry tags and enforce policies. The identity platform decides which tag each endpoint gets, holds the policy matrix, and distributes both. The controller is where policy is authored and is not in the enforcement path at all. That means a fabric with a healthy controller and a broken identity integration continues forwarding traffic and stops applying any of the segmentation it was built for — silently, because permitting traffic produces no error.

A Deeper Dive into the Integration

What the switch downloads and when

Two distinct downloads. Environment data is the list of group names and numbers plus the server list, fetched once and refreshed periodically, and it is what lets the switch translate a tag number into something meaningful. Policy is fetched per group pair, on demand, when the switch first needs to evaluate traffic between those two groups. A switch that has never seen traffic between two groups has never downloaded the policy for them, which is correct and occasionally confusing.

! Has the switch reached the policy server at all?
EDGE1# show cts environment-data
CTS Environment Data
==================================
Current state = COMPLETE
Last status = Successful
Local Device SGT:
  SGT tag = 2-00:TrustSec_Devices
Server List Info:
Installed list: CTSServerList1-0001, 1 server(s):
  *Server: 10.5.5.10, port 1812, A-ID ...
          Status = ALIVE
Environment Data Lifetime = 86400 secs
! ^ State COMPLETE and server ALIVE is the baseline.
!   Anything else and nothing below will work.

The device credential, which is easy to miss

Before a switch can download anything it has to authenticate itself to the policy server, using a credential configured on the switch and matching a device entry on the server. A mismatch here produces a switch that assigns no tags, downloads no policy, and reports an incomplete environment state — which is a clear signal if you look at it and completely invisible if you do not.

! The switch's own credential
cts credentials id EDGE1 password <shared>
!
! The RADIUS relationship it uses
aaa new-model
aaa authentication dot1x default group ISE-GROUP
aaa authorization network default group ISE-GROUP
cts authorization list default
!
radius server ISE-1
 address ipv4 10.5.5.10 auth-port 1812 acct-port 1813
 pac key <shared>
!
! Verify the credential took
EDGE1# show cts credentials
CTS password is defined in keystore, device-id = EDGE1

Profiling, which is what makes MAB tolerable

MAC-based authentication on its own is weak: it accepts whatever MAC address is presented, which anyone can copy. Profiling closes some of that gap by building a picture of what a device actually is from its behaviour — the DHCP options it sends, the fields in its HTTP user agent, the services it advertises, the vendor prefix of its MAC. A device claiming to be a printer that behaves like a laptop is flagged rather than admitted.

The practical value in a fabric is that profiling is what allows the large population of devices with no supplicant to receive meaningful groups instead of all landing in one undifferentiated pool. A camera, a badge reader and a printer are three distinct groups with three distinct policies, and none of them can authenticate. Without profiling they are one group and the segmentation between them does not exist.

What lives where

Refreshing without waiting

Both downloads have lifetimes measured in hours, so a policy change made centrally does not reach every switch instantly. During a change or an investigation, forcing a refresh removes the ambiguity about whether the switch is acting on current information — which is otherwise a genuine possibility and a frustrating one to discover late.

! Force both downloads rather than waiting for the lifetime
EDGE1# cts refresh environment-data
EDGE1# cts refresh policy
!
! Then confirm what actually arrived
EDGE1# show cts environment-data | include state|Status
EDGE1# show cts role-based permissions
!
! And when the switch last refreshed on its own
EDGE1# show cts environment-data | include Lifetime|Last

How Does an Endpoint Get Its Group Tag?

What are the mechanisms?

Five, in descending order of preference. An endpoint that authenticates with 802.1X receives its tag in the authorisation response, which is the ideal case because the tag follows the identity rather than the address. An endpoint that cannot authenticate is identified by its MAC and profiled, which achieves the same outcome with weaker assurance. Below those are static bindings by address, by subnet, and by port — all of which tie the tag to a location rather than to an identity.

A Deeper Dive into Tag Assignment

The authenticated path

The endpoint authenticates, the policy server evaluates its rules, and the acceptance carries the group as a vendor attribute alongside anything else being assigned. The switch installs a binding from the endpoint's address to that group, and from then on every packet the endpoint sends is encapsulated with that tag. The binding's source is recorded, which is how you tell an assigned tag from a configured one.

! The session, which shows what was assigned
EDGE1# show access-session interface GigabitEthernet1/0/12 details
Interface:  GigabitEthernet1/0/12
MAC Address:  a0b4.0101.5555
IPv4 Address:  10.10.10.55
User-Name:  jsmith
Status:  Authorized
Domain:  DATA
Oper host mode:  multi-auth
Method status list:
  Method    State
  dot1x     Authc Success
Server Policies:
      SGT: 0010-00
      Vlan Group:  Vlan: 1021
!
! And the resulting binding
EDGE1# show cts role-based sgt-map vrf CAMPUS 10.10.10.55
IP Address    SGT   Source
10.10.10.55   10    LOCAL

Devices that cannot authenticate

Printers, cameras, badge readers, building systems — a large population that has no supplicant and never will. These fall back to MAC-based authentication, where the switch presents the endpoint's MAC address and the policy server matches it against a profiled identity to decide a group. The assurance is weaker, because a MAC address can be copied, and it is considerably better than putting all of them in one untagged pool.

! Port configuration supporting both, in order
interface GigabitEthernet1/0/20
 description Printer or camera
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication host-mode multi-auth
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 7
!
! Confirm which method actually succeeded
EDGE1# show access-session interface GigabitEthernet1/0/20 details | include Method|SGT
  Method    State
  mab       Authc Success
      SGT: 0032-00

Static bindings and their cost

A static binding ties a group to an address rather than to an identity, which means it does not follow the endpoint and has to be maintained by hand. It is the right answer for a server with fixed addressing and the wrong answer for anything that moves. The tell is the source field on the binding — a binding whose source is a configuration line rather than an authentication is one somebody has to remember to update.

! Static, by address - for fixed-address servers
cts role-based sgt-map vrf CAMPUS 10.99.1.10 sgt 60
!
! Static, by subnet - a coarse fallback
cts role-based sgt-map vrf CAMPUS 10.10.40.0/24 sgt 50
!
! Read the Source column to tell them apart
EDGE1# show cts role-based sgt-map vrf CAMPUS all
IP Address      SGT   Source
10.10.10.55     10    LOCAL     ! authenticated
10.10.40.50     50    CLI       ! typed by a human
10.99.1.10      60    CLI

What happens with no binding

An endpoint with no binding is tagged with the unknown group rather than with nothing, and the policy matrix has an entry for that group like any other. This is the mechanism that makes a deployment safe during rollout — unknown traffic can be permitted while tagging is being established — and it is also the mechanism that quietly permits everything if the tagging never gets established.

! What the switch does with untagged traffic
EDGE1# show cts role-based permissions default
IPv4 Role-based permissions default: Permit IP-00
! ^ Anything without a matching policy is permitted.
!   Safe during rollout. Dangerous if it stays that way.
!
! How many endpoints actually have a binding?
EDGE1# show cts role-based sgt-map vrf CAMPUS all | count LOCAL
EDGE1# show device-tracking database | count REACHABLE
! ^ A large gap between these two is the real measure of
!   how much of the network is actually being segmented.

Changing a tag without disconnecting the endpoint

An endpoint whose group needs to change — a device that has been re-profiled, a user whose role changed, a machine moved to quarantine — does not need to be disconnected. A dynamic authorisation message from the policy server updates the active session in place, the switch installs the new binding, and subsequent traffic carries the new tag. The endpoint observes nothing.

This is the mechanism behind automated quarantine: a device flagged by a security tool is moved into a restricted group within seconds, without anyone touching a switch and without the device being aware. It is also worth knowing during troubleshooting, because a binding that changed without any port event is not an anomaly — it is this mechanism working.

! An active session, before and after a policy change
EDGE1# show access-session interface GigabitEthernet1/0/12 details | include SGT|Status
Status: Authorized
      SGT: 0010-00
!
! ... dynamic authorisation arrives from the policy server ...
!
EDGE1# show access-session interface GigabitEthernet1/0/12 details | include SGT|Status
Status: Authorized
      SGT: 0099-00
! ^ Quarantine group, applied without the port flapping.
!
! Force a reauthentication manually if needed
EDGE1# clear access-session interface GigabitEthernet1/0/12

The rollout sequence that works

How Do Policies Get From Authoring to the Switch?

What is the path?

The matrix is authored centrally, stored by the identity platform, and downloaded by switches per group pair as they need it. Enforcement then has to be explicitly enabled on the switch, and this is separate from everything else — a switch can hold a complete, current, correct policy and enforce none of it because one global command is absent. That separation is the single most consequential thing to know about the distribution path.

A Deeper Dive into Distribution

Enabling enforcement, which is not implied

! Enforcement is separate from having the policy
cts role-based enforcement
cts role-based enforcement vlan-list 1021-1099
! ^ Both. Global alone does not cover SVI-attached traffic
!   on every platform.
!
! Confirm it is actually on
EDGE1# show cts role-based permissions | include Enforcement|enforcement
EDGE1# show run | include role-based enforcement
!
! The definitive test - are the counters moving at all?
EDGE1# show cts role-based counters
! ^ All zeros on a busy switch means enforcement is off.

Reading the downloaded policy

The permissions output shows what the switch holds for each group pair it has needed. A pair that is absent has simply never been exercised. A pair that is present shows the named policy and, importantly, whether it ends in a permit or a deny — which is where the difference between "this policy restricts three protocols" and "this policy permits three protocols and denies everything else" becomes visible.

! What this switch is currently holding
EDGE1# show cts role-based permissions
IPv4 Role-based permissions default: Permit IP-00
IPv4 Role-based permissions from group 10:Employees to group 60:Servers:
        Employee_Server_Access-20
IPv4 Role-based permissions from group 30:Contractors to group 60:Servers:
        Deny IP-00
!
! The contents of a named policy
EDGE1# show cts rbacl Employee_Server_Access-20
CTS RBACL Policy
  name   = Employee_Server_Access-20
  IP protocol version = IPV4
  refcnt = 2
  flag   = 0x41000000
  aclinfo:
    permit tcp dst eq 443
    permit tcp dst eq 22
    deny ip
! ^ The trailing deny is what makes this restrictive.

Why on-demand download is the right design

Downloading the entire matrix to every switch would mean every device holding policies for group pairs it will never see, consuming hardware table space that is finite and valuable. On-demand download means a switch holds only what it is actually using, which is typically a small fraction of the matrix and scales with the conversations that switch carries rather than with the size of the organisation's policy.

The operational consequence is the one noted earlier: an absent policy in the permissions output is not evidence of a problem. It is evidence that this switch has not yet needed that pair. Confirming a policy exists means generating the traffic that requires it, or forcing a refresh, rather than expecting it to appear because it was authored.

Confirming a change actually landed

A policy edited centrally reaches switches on the download lifetime, so verifying a change means either waiting or forcing a refresh and then reading the switch rather than the authoring interface. The authoring interface shows intent; the switch shows what is being enforced, and those are different things during the window between them.

! After a central policy change, on an affected switch
EDGE1# cts refresh policy
EDGE1# show cts role-based permissions from 30 to 60
EDGE1# show cts rbacl | include name|refcnt
!
! And confirm behaviour, not just configuration
EDGE1# show cts role-based counters | include 30 *60
! ^ The denied counter rising after the change is the
!   only real evidence it is in effect.

Where enforcement happens matters for troubleshooting

The policy is evaluated at the destination switch, using the source group carried in the packet header and the destination's local binding. That means a denial is visible only on the destination switch, and every command run on the source will report a healthy, correctly tagged, successfully transmitted flow. Starting an investigation at the source is the most common wasted step in this area.

! The counters live at the DESTINATION
EDGE2# show cts role-based counters
Role-based IPv4 counters
From  To    SW-Denied  HW-Denied  SW-Permit  HW-Permit
30    60    0          18442      0          0
! ^ 18442 packets denied from group 30 to group 60.
!
! Clear and watch, to confirm a live flow is the one being hit
EDGE2# clear cts role-based counters
EDGE2# show cts role-based counters | include 30 *60

How Do I Design a Policy Matrix That Stays Manageable?

What makes a matrix unmanageable?

Group count, because the matrix grows with its square. Ten groups is ninety possible pairs; twenty groups is three hundred and eighty. Most of those cells are left at the default and only the exceptions are authored, so the real burden is the number of exceptions rather than the number of cells — but the number of exceptions tends to grow with the group count too, because more groups means more distinctions somebody wants to express.

A Deeper Dive into Matrix Design

Fewer groups than you first want

The instinct is to create a group per department, per device type, and per trust level, which produces thirty groups and a matrix nobody can reason about. The groups worth having are the ones between which a policy genuinely differs. If Finance and Marketing have identical permissions everywhere, they are one group for segmentation purposes regardless of how differently the organisation thinks about them.

! A starting set that covers most requirements
!   Employees        - general corporate access
!   Contractors      - restricted subset
!   Guests           - internet only
!   Servers          - destinations, not sources
!   IoT              - narrow, device-initiated only
!   Printers         - accept jobs, initiate nothing
!   Quarantine       - remediation only
!
! Seven groups = 42 ordered pairs, of which perhaps
! eight need an explicit policy. That is manageable.
!
EDGE1# show cts environment-data | begin Security Group Name

Design the exceptions, not the permissions

A matrix where every cell is authored is a matrix nobody maintains. A matrix with a permissive default and eight explicit denials is one that can be read in a minute and reasoned about correctly. The exceptions are where the security value is; the rest is noise that obscures it. This also makes the eventual move to a restrictive default a smaller change, because the exceptions that matter are already written.

Direction matters and is easy to get wrong

Policy is evaluated from a source group to a destination group, and the two directions are separate cells. A printer that should accept print jobs and never initiate connections needs permission from Employees to Printers and a denial from Printers to everything — two different cells expressing one intent. Writing only one of them produces a policy that appears to work and does not do half of what was intended.

! One intent, two cells
!
! Employees -> Printers : allow printing
EDGE1# show cts role-based permissions from 10 to 20
IPv4 Role-based permissions from group 10:Employees to group 20:Printers:
        Print_Access-10
!
! Printers -> anything : deny, because printers initiate nothing
EDGE1# show cts role-based permissions from 20 to 10
IPv4 Role-based permissions from group 20:Printers to group 10:Employees:
        Deny IP-00
! ^ Both cells needed. Only the first is usually written.

Servers are destinations, not sources

A useful discipline when defining groups is to notice that some of them only ever appear on one side of the matrix. Servers are almost always destinations: workstations connect to them and they rarely initiate anything back. Printers are the same. Recognising that halves the number of cells worth thinking about for those groups, and it makes the ones that do matter — a server group that unexpectedly needs to initiate outbound connections — stand out as something to ask about.

The corollary is that a group appearing on both sides of many exceptions is probably two groups. If a population sometimes behaves as a client and sometimes as a server, splitting it lets each half have a policy that reads clearly, and that is one of the few cases where increasing the group count genuinely simplifies the matrix.

Naming that survives a handover

A policy called Policy_1 tells the next person nothing. A policy called Contractor_Deny_Finance tells them the source group, the action and the destination, which is everything they need to decide whether it is the one causing the problem. This costs nothing at authoring time and saves an investigation every time somebody unfamiliar has to read the matrix under pressure.

Testing a policy before relying on it

A policy is verified by producing traffic that should hit it and confirming the counter moves, not by reading the matrix. That takes two minutes per policy and it catches direction errors, group assignment errors and enforcement being off — three of the most common problems — in a single test. Doing it for the eight exceptions that matter is a short exercise; doing it for none of them is how a matrix reaches production untested.

! Test one policy properly
!
! 1. Confirm both endpoints have the groups you expect
EDGE1# show cts role-based sgt-map vrf CAMPUS 10.10.10.71
EDGE2# show cts role-based sgt-map vrf CAMPUS 10.99.1.10
!
! 2. Clear the counters on the DESTINATION switch
EDGE2# clear cts role-based counters
!
! 3. Generate traffic that should be denied
!    (from the source endpoint, not from a switch)
!
! 4. Confirm the right counter moved
EDGE2# show cts role-based counters | include 30 *60
! ^ A denied count that matches your attempts is a pass.
!   Anything else means the policy is not doing what you think.

Which Micro-Segmentation Failures Silently Permit or Deny?

What are the failures worth memorising?

Four. Enforcement never enabled, which permits everything while looking correct. An endpoint with no binding carrying the unknown group, which is permitted under a permissive default and denied under a restrictive one. A policy authored in one direction only. And a stale download, where the switch is enforcing a matrix that was replaced hours ago.

A Deeper Dive into the Failure Catalogue

Enforcement that was never switched on

The unknown group

One direction authored

A five-command investigation

! In this order. Most cases end in the first two.
!
! 1. Is enforcement even on? (destination switch)
EDGE2# show cts role-based counters
! ^ all zeros on a busy switch = enforcement off. Stop.
!
! 2. Do both endpoints have the groups you expect?
EDGE1# show cts role-based sgt-map vrf CAMPUS <source-ip>
EDGE2# show cts role-based sgt-map vrf CAMPUS <dest-ip>
!
! 3. What policy does the destination hold for that pair?
EDGE2# show cts role-based permissions from <src-sgt> to <dst-sgt>
!
! 4. Is it current?
EDGE2# cts refresh policy
EDGE2# show cts role-based permissions from <src-sgt> to <dst-sgt>
!
! 5. Is the integration healthy at all?
EDGE2# show cts environment-data | include state|Status

What to monitor

Four items. Environment data state per switch, alerting on anything other than complete. The gap between tracking database entries and bindings, alerting on growth. Denial counters per group pair, compared against a baseline of intended denials. And an all-zero counter on any switch carrying traffic, which is the enforcement-off signal and is otherwise found only by audit.

The stale download

The fourth failure is the least dramatic and the most likely to waste an afternoon. A policy edited centrally reaches switches on the download lifetime, which is measured in hours, so during that window different switches are enforcing different versions of the matrix. A test that passes on one switch and fails on another, with identical configuration, is usually this — and it resolves itself, which makes it particularly annoying to characterise.

The habit that removes it is to force a refresh on the specific switch before drawing any conclusion from it. That takes one command and converts an ambiguous result into a definite one. It is also worth doing on both switches involved in a test, because the source switch's group list and the destination switch's policy are two separate downloads with two separate lifetimes.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers policy and segmentation within the software-defined infrastructure domain, and the questions concentrate on the model rather than the product: how a tag is assigned, where enforcement happens, what the difference between macro and micro segmentation is, and which show command reveals what. Being able to say that enforcement is at the destination and name the counter command covers a good proportion of it.

Conclusion

Micro-segmentation in a fabric depends on two things that originate outside it: the tag an endpoint receives at authentication, and the policy between two tags. The switches carry and enforce; they decide neither. That division explains why segmentation failures divide into a tagging family and a policy family, why they are investigated in different places, and why an integration failure fails open and is therefore invisible from a connectivity perspective.

The rollout sequence matters more than the technology. Authenticate without enforcing, verify every endpoint receives the tag you expect, enforce with a permissive default and specific denials, and only then consider a restrictive default. The gap between the endpoint tracking count and the binding count is the measure of how far through that sequence a deployment actually is, and it is the exact blast radius of tightening the default before the sequence is complete.

The failures are all quiet. Enforcement never enabled permits everything while every command reports success. An untagged population is invisible until the default changes. A policy authored in one direction works for the traffic it was tested with and nothing else. And in every one of those cases the configuration reads correctly — which is why the counters, on the destination switch, are the only output that says what is actually being enforced.

External Links

• Cisco TrustSec Configuration Guide
• RFC 3748 — Extensible Authentication Protocol (EAP)
• RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
• RFC 5176 — Dynamic Authorization Extensions to RADIUS
• RFC 7348 — Virtual eXtensible Local Area Network (VXLAN)
• Cisco — Software-Defined Access Configuration Guide, Catalyst 9300
• Cisco Learning Network — CCIE Enterprise Infrastructure

Reference Notes

1. Cisco TrustSec documentation describes the Scalable Group Tag and its assignment to endpoints through dynamic authorisation or static configuration.
2. Cisco TrustSec documentation describes SGACL enforcement at the destination device, using the source group carried with the traffic and the destination's local group binding.
3. Cisco TrustSec documentation describes environment data, which a device downloads to obtain the group name list and server information, and which is refreshed on a configurable lifetime.
4. Cisco TrustSec documentation describes on-demand SGACL download, in which a device requests the policy for a source and destination group pair when it first needs to evaluate that pair.
5. Cisco TrustSec documentation describes cts role-based enforcement as the command enabling SGACL enforcement, separate from policy acquisition.
6. Cisco TrustSec documentation describes the cts credentials device identity used to authenticate a network device to the policy server.
7. RFC 2865 defines RADIUS, the protocol carrying the authorisation response in which a group assignment is returned to the switch.
8. RFC 3748 defines the Extensible Authentication Protocol used by 802.1X supplicants during authentication.
9. RFC 5176 defines RADIUS dynamic authorisation, used to change an active session's authorisation without requiring the endpoint to reauthenticate from scratch.
10. Cisco documentation describes MAC Authentication Bypass for endpoints that cannot present an 802.1X supplicant, using the endpoint's MAC address as its identity.
11. Cisco documentation describes the unknown group, applied to traffic from endpoints for which no binding exists, and the default policy that governs it.
12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include policy and segmentation within the software-defined infrastructure domain.