08-23-2021 01:23 AM
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?
Solved! Go to Solution.
08-24-2021 07:16 AM
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.
08-24-2021 03:39 AM
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.
08-24-2021 07:16 AM
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.
08-24-2021 07:20 AM
Tons of thanks , Jonothan for clarifications (books must be read entirely :0)
08-24-2021 10:07 AM
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.
08-24-2021 10:29 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide