Hands-On Lab: Configuring TrustSec Environment Data Download (EDD)

This hands-on lab configures a switch to dynamically download its SGT name-to-number mappings from the ISE-equivalent policy server via Environment Data Download, verifying the switch stays synchronized with centrally managed SGT definitions without requiring local per-device configuration of every group name.

TrustSec Environment Data DownloadDynamic SGT Name ResolutionCentralized Policy Server Synchronization

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure a switch to download SGT environment data (name-to-number mappings) from a centralized policy server, verify the switch resolves SGT names correctly without any local static definition, and confirm the switch automatically picks up a newly added SGT definition without manual reconfiguration.

Lab Purpose

The SGT labs covered earlier in this series manually configured SGT numbers and their meanings on each switch individually — practical for a lab, but unsustainable across dozens of switches in a real deployment where SGT definitions change over time. Environment Data Download lets every switch pull this information dynamically from a single authoritative source, keeping definitions consistent fabric-wide.

Lab Topology

Switch1 ---- PolicyServer (ISE-equivalent,
             authoritative source for SGT
             name-to-number mappings)

PolicyServer currently defines:
  SGT 10 = Employees
  SGT 20 = Guests
  SGT 30 = Servers

Task 1: Configure Switch1 to Point to the Policy Server

Configure the CTS AAA server pointing to the policy server for authorization and environment data.

Task 2: Trigger an Environment Data Download

Manually trigger a refresh of environment data from the policy server.

Task 3: Verify SGT Names Resolve Correctly

Confirm Switch1 displays human-readable SGT names rather than only numbers, sourced entirely from the policy server rather than local configuration.

Task 4: Add a New SGT Definition on the Policy Server

Add a new SGT (SGT 40 = Contractors) on the policy server, without touching Switch1's configuration at all.

Task 5: Verify Switch1 Automatically Learns the New Definition

Confirm Switch1 eventually resolves SGT 40 to "Contractors" without any local configuration change.

Solution and Verification

Switch1(config)# aaa new-model
Switch1(config)# radius server POLICY-SERVER
Switch1(config-radius-server)# address ipv4 [PolicyServer-address] auth-port 1812 acct-port 1813
Switch1(config-radius-server)# key TrustSecKey2026

Switch1(config)# aaa group server radius CTS-SERVERS
Switch1(config-sg-radius)# server name POLICY-SERVER

Switch1(config)# cts authorization list CTS-SERVERS

Switch1# cts refresh environment-data

-- This explicitly requests updated
-- environment data (SGT name-to-number
-- mappings, among other TrustSec
-- environment settings) from the policy
-- server, rather than waiting for the
-- automatic periodic refresh interval

Switch1# show cts environment-data

CTS Environment Data
====================
Security Group Table:
  0-00:Unknown
  2-00:TrustSec_Devices
  10-00:Employees
  20-00:Guests
  30-00:Servers
-- Switch1 resolved all current SGT names
-- entirely from the policy server -- no
-- name-to-number mapping was ever manually
-- typed into Switch1's own configuration

PolicyServer> [administrator adds a new
               SGT definition: SGT 40 =
               Contractors]

-- No configuration change made on Switch1
-- at this point

-- After the periodic refresh interval
-- elapses (or another manual refresh):

Switch1# cts refresh environment-data

Switch1# show cts environment-data

CTS Environment Data
====================
Security Group Table:
  0-00:Unknown
  2-00:TrustSec_Devices
  10-00:Employees
  20-00:Guests
  30-00:Servers
  40-00:Contractors
-- The new SGT definition appeared
-- automatically, sourced entirely from the
-- policy server -- Switch1 never required
-- any local awareness of this new group
-- being added

Key Takeaway

Environment Data Download decouples SGT naming and definition management from individual switch configuration entirely — every device in the TrustSec domain resolves the same names from the same authoritative source, meaning a single change on the policy server (adding, renaming, or removing an SGT definition) automatically propagates to every switch without requiring a single command to be typed on any of them, a critical scalability improvement over the fully manual per-switch SGT configuration used in the earlier standalone SGT lab.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue