Lab Objective
Configure SXP between a switch with SGT-capable hardware and a second switch lacking that capability, verify SGT-to-IP bindings propagate over the SXP session, and confirm the receiving switch can still enforce SGACL policy despite never seeing an inline SGT tag on the wire.
Lab Purpose
The SGT lab covered earlier in this series relied on inline tagging, where the SGT travels embedded directly within each frame — a capability requiring specific hardware support. SXP solves the problem of extending SGT-based policy to switches, routers, or firewalls that lack this inline tagging hardware, by propagating the SGT-to-IP binding information out-of-band instead.
Lab Topology
Switch1 (SGT-capable, inline tagging,
configured with SGT assignments
from the earlier SGT lab)
---- SXP session ---- Switch2 (legacy
hardware, cannot
carry inline SGT
tags on its uplinks)
Employee-PC (SGT 10) connects to Switch1
Enforcement point exists on Switch2 for
traffic destined to a server thereTask 1: Configure Switch1 as an SXP Speaker
Configure Switch1 to speak SXP, advertising its locally learned SGT-to-IP bindings to Switch2.
Task 2: Configure Switch2 as an SXP Listener
Configure Switch2 to listen for SXP updates from Switch1.
Task 3: Verify the SXP Session Establishes
Confirm the SXP connection between the two switches reaches an established state.
Task 4: Verify SGT-to-IP Bindings Propagate
Confirm Switch2 learns Employee-PC's SGT-to-IP binding via SXP, despite never seeing an inline SGT tag.
Task 5: Verify SGACL Enforcement Works on Switch2
Apply the same SGACL policy from the earlier lab on Switch2 and confirm it enforces correctly using the SXP-learned binding.
Solution and Verification
Switch1(config)# cts sxp enable
Switch1(config)# cts sxp default password SxpKey2026
Switch1(config)# cts sxp connection peer [Switch2-address] password default mode local speaker
-- "speaker" means Switch1 will advertise
-- its bindings TO the peer -- it does not
-- expect to receive bindings back over
-- this sessionSwitch2(config)# cts sxp enable
Switch2(config)# cts sxp default password SxpKey2026
Switch2(config)# cts sxp connection peer [Switch1-address] password default mode local listener
-- "listener" means Switch2 only receives
-- bindings, matching the speaker role
-- Switch1 was configured withSwitch1# show cts sxp connections
SXP Peer IP Source IP Conn Status
[Switch2-addr] [Switch1-addr] On
-- Connection established, confirmed by
-- "On" statusSwitch2# show cts sxp sgt-map
SGT IP Address
10 192.168.100.10
-- Switch2 learned Employee-PC's SGT (10)
-- mapped to its IP address purely through
-- the SXP session -- no inline tagging
-- hardware was involved anywhere in this
-- propagation pathSwitch2(config)# cts role-based sgt-map [SharedServer-address] sgt 30
Switch2(config)# ip access-list role-based DENY-GUESTS
Switch2(config-rb-acl)# deny ip
Switch2(config-rb-acl)# exit
Switch2(config)# cts role-based permissions from 20 to 30 DENY-GUESTS
-- Identical policy structure to the
-- earlier SGT lab, applied on a switch
-- that never handles an inline SGT tag
-- for this traffic at allGuest-PC> ping SharedServer
-- (Guest-PC's SGT 20 binding also
-- propagated via SXP from Switch1)
Request timed out.
Success rate is 0 percent (0/5)
-- Enforcement on Switch2 works correctly,
-- using only the SXP-learned binding
-- information rather than any inline tag
-- carried in the packet itselfKey Takeaway
SXP separates the propagation of SGT-to-IP binding information from the inline tagging mechanism itself — a switch running SXP as a listener can enforce SGACL policy using IP-based lookups against learned bindings, entirely independent of whether it has the hardware capability to read or write an inline SGT tag, making SXP the standard mechanism for extending SGT-based segmentation across a mixed environment of SGT-capable and legacy infrastructure.