Back
Lesson 3 of 7

SGACLs — Micro-Segmentation Policies

Objective

In this lesson you will create SGACL (Security Group Access Control List) contracts that implement micro-segmentation between Security Groups (SGTs). You will define permit, deny, and log actions for SGT-to-SGT traffic, bind SGACLs to enforcement points, and verify traffic enforcement and logging. In production, SGACLs let you express fine-grained intent (for example "cameras cannot talk to lighting controllers") independent of IP addressing — this is essential when devices move or when overlays (VXLAN) carry SGTs across fabric boundaries.

Real-world scenario: a campus with IP cameras (SGT 5) must be prevented from reaching lighting controllers (SGT 20) but allowed to reach HVAC controllers (SGT 30). The network enforces this policy at the fabric edge and propagates SGT information over VXLAN or site-to-site tunnels so datacenter firewalls can also apply the same policy.

Quick Recap

Refer to the topology introduced in Lesson 1. This lesson does not add new devices; we reuse endpoints and IP addresses from the reference material:

  • Camera (classified as SGT 5): 10.1.200.100
  • Lighting controller (classified as SGT 20): 10.1.100.52
  • Source endpoint used in examples (could be other device): 10.1.10.220
  • Example employee host (SGT 4): 10.0.0.5

Topology (logical, showing exact IPs on endpoints):

Router/Switch representing Fabric Edge | Gi0/1 ---- 10.1.200.100 (Camera, SGT 5) | Gi0/2 ---- 10.1.100.52 (Lighting, SGT 20) | Gi0/3 ---- 10.1.10.220 (Other client) | Gi0/4 ---- 10.0.0.5 (Employee host, SGT 4)

Note: Interface names (Gi0/1 etc.) are shown here as the local switch/router-facing port identifiers for clarity in the lab. IP addresses are exact as provided in the reference material.

Key Concepts

  • Security Group Tags (SGTs): Think of SGTs like labels attached to packets that indicate a device role (Camera = SGT 5, Lighting = SGT 20). These labels travel inside the fabric (for example inside VXLAN payloads) or are carried/translated over tunnels (SXP, VTI) so policy is consistent across sites. In production, this lets you express policy by role, not IP address.

  • SGACL (Security Group ACL): A named policy that declares allowed/denied traffic between SGTs. SGACLs are the enforcement “contract” — they map SGT-pair intent to concrete actions (permit/deny/log). In production, SGACLs provide micro-segmentation without manually maintaining hundreds of IP ACLs as devices move.

  • Enforcement point: SGACLs must be bound to interfaces or to the fabric egress/ingress so the device can apply the ACL in hardware at the moment packets leave or enter a domain. In a VXLAN-based fabric, enforcement typically occurs at the fabric edge (egress fabric edge).

  • Logging and visibility: An SGACL entry can include a log action. When a deny + log executes, the network device forwards metadata to a logging/monitoring system (syslog/SEIM), giving visibility into policy hits. This is critical for incident response and tuning.

  • Propagation & tunnels: When SGTs traverse tunnels or non-SGT-aware hops, they can be carried in the data plane (VXLAN), exchanged via SXP to legacy peers, or stripped for non-capable peers. In production, confirm both ends of a tunnel are SGT-capable when you need end-to-end enforcement.

Step-by-step configuration

For each step below you will see: What we are doing, exact commands, explanation of what changed, a short real-world note, and verification commands with expected output.

Step 1: Define SGACLs to represent micro-segmentation contracts

What we are doing: Create two SGACLs: one that denies Camera (SGT 5) -> Lighting (SGT 20) and logs the hit, and another that permits Camera (SGT 5) -> HVAC (SGT 30). These named SGACLs express intent in the fabric and will later be bound for enforcement.

configure terminal
! Define SGACL that denies camera -> lighting and logs
sgacl name SGACL_CAMERA_TO_LIGHTING
 rule 10 deny ip host 10.1.200.100 host 10.1.100.52 log

! Define SGACL that permits camera -> HVAC
sgacl name SGACL_CAMERA_TO_HVAC
 rule 10 permit ip host 10.1.200.100 host 10.1.10.220
exit

What just happened: Each sgacl name block creates a named SGACL and adds rules. Rule entries are ordered; rule 10 is evaluated first. The "deny ... log" action will cause the device to drop matching packets and produce a log/event so administrators can see policy hits. The permit rule explicitly allows traffic for the specified SGT pair.

Real-world note: Naming SGACLs clearly (e.g., SGACL_CAMERA_TO_LIGHTING) makes policy audits and automation far easier in large environments.

Verify:

show sgacl name SGACL_CAMERA_TO_LIGHTING
sgacl name SGACL_CAMERA_TO_LIGHTING
 rule 10 deny ip host 10.1.200.100 host 10.1.100.52 log
show sgacl name SGACL_CAMERA_TO_HVAC
sgacl name SGACL_CAMERA_TO_HVAC
 rule 10 permit ip host 10.1.200.100 host 10.1.10.220

Expected output shows the named SGACLs and their rules in full (not abbreviated). The device reports the configured actions (deny/permit) and the log keyword.

Step 2: Map SGTs to endpoints (SGT assignment)

What we are doing: Assign SGT values to the IPs of interest (Camera: SGT 5; Lighting: SGT 20; HVAC/other: SGT 30) so enforcement can match based on security group rather than IP only. This step is crucial because SGACLs act on SGTs and/or endpoint IPs.

configure terminal
! Map SGT to endpoints - explicit identity mapping for lab verification
cts role-based sgt-map 10.1.200.100 5
cts role-based sgt-map 10.1.100.52 20
cts role-based sgt-map 10.1.10.220 30
exit

What just happened: Each cts role-based sgt-map command associates an IP address with an SGT. This creates an IP-to-SGT mapping that the enforcement logic uses when evaluating SGACLs. When a packet arrives from 10.1.200.100, the switch/router treats it as carrying SGT 5.

Real-world note: In production, SGTs typically come from authentication sources (ISE) or are learned from inline tagging — static IP-to-SGT mappings are used for lab validation or legacy devices.

Verify:

show cts role-based sgt-map
IP                SGT
10.1.200.100      5
10.1.100.52       20
10.1.10.220       30

Expected output lists each IP and its mapped SGT. This confirms the enforcement engine can correlate IP address to SGT.

Step 3: Bind SGACLs to enforcement (apply contract to the interface/egress)

What we are doing: Attach the SGACLs to the appropriate enforcement point (interface representing the fabric edge). This is how the device performs action (permit/deny/log) on matching traffic as it traverses the interface.

configure terminal
! Apply SGACLs to the interface that connects the Camera (Gi0/1)
interface GigabitEthernet0/1
 description Camera port - SGT 5
 switchport mode access
 switchport access vlan 200
 cts enforcement sgt 5 sgacl SGACL_CAMERA_TO_LIGHTING direction in
 cts enforcement sgt 5 sgacl SGACL_CAMERA_TO_HVAC direction in
exit

What just happened: The interface configuration tells the device to enforce the named SGACLs for traffic that arrives on Gi0/1 and is associated with SGT 5. The enforcement checks packets' SGTs (or IP-to-SGT mappings) and applies the SGACL rules in order. The "direction in" ensures checks occur on ingress traffic before it traverses the device.

Real-world note: Applying SGACLs at the ingress prevents unwanted traffic from consuming network resources; enforcement at egress can be used for specific deployment models. In VXLAN fabrics, enforcement typically happens at fabric edge egress.

Verify:

show running-config interface GigabitEthernet0/1
interface GigabitEthernet0/1
 description Camera port - SGT 5
 switchport mode access
 switchport access vlan 200
 cts enforcement sgt 5 sgacl SGACL_CAMERA_TO_LIGHTING direction in
 cts enforcement sgt 5 sgacl SGACL_CAMERA_TO_HVAC direction in

Expected output shows the interface config and the bound SGACLs. This confirms the device will evaluate the configured SGACLs for traffic arriving on Gi0/1.

Step 4: Test policy behavior and observe logging

What we are doing: Generate traffic from the Camera IP (10.1.200.100) to the Lighting controller IP (10.1.100.52) — this should be denied and logged. Then test Camera -> HVAC (10.1.10.220) — this should be permitted. In a real lab, use ping or a TCP session tool to create traffic.

! Simulated verification commands you would run on the enforcement device
show sgacl counters name SGACL_CAMERA_TO_LIGHTING
SGACL: SGACL_CAMERA_TO_LIGHTING
 rule 10 deny ip host 10.1.200.100 host 10.1.100.52 log
  hits: 5
 show sgacl counters name SGACL_CAMERA_TO_HVAC
SGACL: SGACL_CAMERA_TO_HVAC
 rule 10 permit ip host 10.1.200.100 host 10.1.10.220
  hits: 12

! Logging output (syslog) - sample events showing deny + log
show logging | begin "SGT"
Apr  1 12:34:56 DeviceID %SGT-4-ACL_LOG: Deny packet src=10.1.200.100 dst=10.1.100.52 proto=icmp sgc_src=5 sgc_dst=20 reason=SGACL_RULE_10

What just happened: The show sgacl counters output shows hit counters for SGACL rules — rule 10 for the deny has registered hits. The syslog entry demonstrates that deny + log produced a log event with source/destination IP and source/destination SGTs, giving administrators the context needed to investigate.

Real-world note: Regularly monitor SGACL counters and logs to tune policies and detect misclassifications or attacking devices. High deny counts could indicate compromised endpoints or misapplied policy.

Verify:

show sgacl counters name SGACL_CAMERA_TO_LIGHTING
SGACL: SGACL_CAMERA_TO_LIGHTING
 Rule 10 deny ip host 10.1.200.100 host 10.1.100.52 log
  Packet Matches: 5
  Byte Matches: 820

show logging | include Deny packet src=10.1.200.100
Apr  1 12:34:56 DeviceID %SGT-4-ACL_LOG: Deny packet src=10.1.200.100 dst=10.1.100.52 proto=icmp sgc_src=5 sgc_dst=20 reason=SGACL_RULE_10

Expected output confirms SGACL counters increment and matches syslog entries for denied packets.

Verification Checklist

  • Check 1: SGACL definitions exist — verify with show sgacl name <name> and confirm rules and actions show correctly.
  • Check 2: IP-to-SGT mappings are present — verify with show cts role-based sgt-map and ensure each endpoint IP maps to the intended SGT.
  • Check 3: Enforcement is active on the interface — verify via show running-config interface <iface> and show sgacl counters name <sgacl> to see policy hits and logging.

Common Mistakes

SymptomCauseFix
No SGACL matches appear in countersIP-to-SGT mappings not configured or SGTs not present in the packetVerify show cts role-based sgt-map and authentication/inline tagging. Ensure SGT is present on packets entering the enforcement point.
Expected denies but traffic flowsSGACL not bound to the correct interface or wrong direction (in/out)Check show running-config interface <iface> and ensure cts enforcement entries reference the correct SGACL and direction.
Log entries missing for denied flowsThe rule lacks the "log" action or logging destination not configuredEnsure SGACL rule uses log. Confirm device logging/syslog is configured and reachable.
High false-positive deniesIP-to-SGT mapping incorrect or overly specific SGACL rules using host IPsUse broader match or map correct IPs to SGTs. Consider basing SGACLs on SGT pairs rather than exact IP hosts in dynamic environments.
Policy not enforced across tunnelRemote peer not SGT-capable or SGT is stripped on tunnelVerify tunnel SGT propagation method (VXLAN, SXP, VTI). If remote peer is not SGT-capable, use SXP or strip as an intentional behavior and adjust policy accordingly.

Key Takeaways

  • SGACLs express intent between Security Groups (SGTs) and are fundamental for scalable micro-segmentation — they let you manage policy by role instead of IP.
  • You must ensure endpoints are properly classified (SGT assigned) and that SGACLs are bound at the enforcement point (interface/fabric edge) for the policy to take effect.
  • Logging on deny rules provides crucial visibility; use SGACL counters and syslog to monitor hits and tune policies.
  • In production, verify that SGT propagation (VXLAN, SXP, tunnels) is working end-to-end so policies remain consistent across sites and across overlay/underlay transitions.

Tip: Think of SGACLs like “role-based firewall rules” inside the network fabric — they are the language for intent-based micro-segmentation, and they only work when SGTs reliably tag or map endpoints across the domain.

Next lesson preview: we will expand trust propagation across tunnels (SGT over VTI/SXP) and show how SGACL enforcement works when endpoints are separated across sites.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security