CTS & SGT behavior in C9K environment

[andy!doesnt!like!uucp]

Hi

i want to share my experience of deployment of CTS/SGT in campus built with C9Ks & ASA 5516X as WAN-edge router.

C9Ks run 17.3.3 , ASA runs 9.12 . Simplified topology:

To clarify on notes: on the ISE all C9Ks & ASA are configured for TrustSec, pac-provisioned & get pushed with SGTs & IP-SGT maps (though ASA doesnt seem receiving IP-SGT maps). No SGT-assignment from ISE to endpoint's ingress during AuthZ, Some VLANs get terminated on Core switch, some VLANs get terminated on FW. there is default route to ASA from Core & route from ASA to Core pointing to Core's client's aggregated subnet. 

It's about what i can see with capture now:

1) Unless endpoint in FW-terminated VLAN gets 1st time applied SGT (by configuring SGT in AuthZ-profile & reauthing endpoint) its source frame gets added with SGT 0 by access switch;

2) all endpoints in Core terminated VLANs have their source frames assigned with SGTs corresponding to their subnets of belongness;

Can anyone explain this behavior?

[jeaves@cisco.com]

Have read this a few times and don't quite understand the setup enough in order to be useful. If you email me we can perhaps organise to have a chat.

[jeaves@cisco.com · Accepted solution]

Have had a chat now. One issue was related to static classifying with longest match.

Looking at the FW-terminated VLAN issue, the traffic path traverses a port-channel between access and core. The inline tagging configuration is good i.e. is enabled on the members, yet Andy shared a capture on the core showing SGT 0 being propagated even after I set a /32 classification on the access. Core and Access Cat9k's running 17.3.3 so need to check possible bugs on port-channel propagation.

[andy!doesnt!like!uucp]

Tons of thanks , Jonothan for clarifications (books must be read entirely :0)

[jeaves@cisco.com]

Have tested in the lab now, you'll see I've sent you an email Andy with the full details.

For others, the summary is that I setup a port-channel between a Cat9300 (access) and Cat9500 (core) and monitored if the SGT was propagated. It was (in both directions).

The versions in my lab:

Cat9300 was 17.06.01prd14

Cat9500 was 17.3.4

As Andy has seen the problem on 17.3.3 the best action is to try 17.3.4.

[andy!doesnt!like!uucp]

i appreciate your efforts Jonny, but i have the same with SGT==2 which is SGT_CTS_DEVICE in yours & my cases.

all traffic generated by IPs belonging CTS DEVICEs gets assigned SGT 2 unconditionally.