cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1366
Views
0
Helpful
5
Replies

VLAN SVI bound traffic and TrustSec policy enforcement

andrewswanson
Level 7
Level 7

 

Hi

I'm working on a TrustSec dev environment using ISE for SGT assignemnt and Policy enforcement.

 

I started looking at a policy that would restrict authenticated clients on a vlan to only ping their default gateway (vlan svi)

 

  • The Distribution switch (WS-C3650-48FQM 16.8.1a) hosting the vlan SVI shows the vlan SVI as having SGT 2 (source INTERNAL)
  • The Access switch (WS-C3650-48PD 16.9.2) connecting the PC shows the PC as having SGT 3100 (source LOCAL)

 

ISE is configured with a policy permitting icmp only from SGT 3100 to SGT 2 - the switches download the cts environment data successfully and can be viewed from the switch cli


IPv4 Role-based permissions from group 3100:TEST to group 2:TrustSec_Devices:
SGACL_ICMP-01
Deny IP-00


These permissions aren't being enforced - I can still SSH to the SVI. If I set permissions to just Deny IP-00 I can still ping/ssh to the SVI.

 

From cisco documentation:

"SGACL enforcement can be applied to packets switched within a VLAN or forwarded to an SVI associated with a VLAN, but enforcement must be enabled explicitly for each VLAN"

 

I have the command "cts role-based enforcement vlan-list <vlan>" on both access/distribution switch but policy is still not enforced. All other ISE policies work as configured but not this one - I've checked that SGT propagation (manual inline) between access/distribution is working ok.

 

Does anyone have any idea why I can't enforce policy for SVI bound traffic? I don't think I had this issue in the past (with same/similar config) when the distribution switch was a VSS 6880.

 

Thanks
Andy

1 Accepted Solution

Accepted Solutions

I believe I was mistaken on the first being useful, unless you have cts caching enabled you wouldn't see the ip sgt mappings from packets carried inline. I also think Cisco deprecated this feature on the switching platforms which was helpful for confirming inline tagging. You could try issuing "cts sgt caching" but I think I last saw it in 16.3, it was gone in 16.6.

Since you are referring to SGT 2, I'm assuming this is the management SVI of the distribution switch? If so the enforcement would have to be performed on the access 3650, does that have cts enforcement enabled and sgacl's?

"The following restriction apply to the Cisco Catalyst 3650 Series Switches and Cisco Catalyst 3850 Series Switches:
CTS SGACLs cannot be enforced for punt (CPU bound) traffic due to hardware limitations."

I would definitely test this with two proper endpoints but I would expect this traffic flow to at least be enforced on the access layer.

View solution in original post

5 Replies 5

Damien Miller
VIP Alumni
VIP Alumni
Do you see the ip sgt mappings for both svi and pc in "sh cts role-based sgt-map all" on a single switch?
Within ISE, is the trustsec egress policy in "monitor mode"?
Is anything showing denied in "sh cts role-based counters"?

I would agree, it should work and sounds like you have the correct components in place.

Hi Damien - thanks for the reply:

Do you see the ip sgt mappings for both svi and pc in "sh cts role-based sgt-map all" on a single switch? No - I see ip-sgt binding for the pc only on the access layer switch and the ip-sgt binding for the vlan svi only on the distribution layer switch
Within ISE, is the trustsec egress policy in "monitor mode"? No
Is anything showing denied in "sh cts role-based counters"? No - I'm seeing zero hits for SGT tag 3100 (PC) to SGT 2 (SVI)

I'll double check the configs and try different ios to see if that makes a difference.
Thanks
Andy





 

I believe I was mistaken on the first being useful, unless you have cts caching enabled you wouldn't see the ip sgt mappings from packets carried inline. I also think Cisco deprecated this feature on the switching platforms which was helpful for confirming inline tagging. You could try issuing "cts sgt caching" but I think I last saw it in 16.3, it was gone in 16.6.

Since you are referring to SGT 2, I'm assuming this is the management SVI of the distribution switch? If so the enforcement would have to be performed on the access 3650, does that have cts enforcement enabled and sgacl's?

"The following restriction apply to the Cisco Catalyst 3650 Series Switches and Cisco Catalyst 3850 Series Switches:
CTS SGACLs cannot be enforced for punt (CPU bound) traffic due to hardware limitations."

I would definitely test this with two proper endpoints but I would expect this traffic flow to at least be enforced on the access layer.

Thanks for that - I wasn't aware of that 3k hardware limitation.

 

I was testing the trustsec policy with Distribution switch SVI and loopback ip addresses (all with the SGT tag of 2). I can confirm that I'm running into this hardware limitation by testing the policy with a Distribution switch IP Address on a physical interface (which also has an SGT tag of 2).

 

I'll check that next week and update the thread.

 

Cheers
Andy

After a bit more testing I found that I couldn't enforce Trustsec policy for traffic destined to any Distribution switch owned IP Address (virtual or physical) when the source endpoint is in a Distribution switch VLAN.

 

This was the case whether the endpoint was connected to the Access switch or the Distribution switch (distribution switch had both SRC and DST SGTs in its table).

 

I resolved this by creating an SXP connection between Access (listener) and Distribution (speaker) so that the Access switch learned all distribution switch owned IP addresses (SGT of 2) - see below. With this in place, the Trustsec policy worked as expected with policy enforced on egress from the access switch.

 

Not sure if this is related to the 3k hardware limitation or a bug but I'll mark thread as resolved. It'll be interesting to see if I have the same problem when the Distribution switch is a Catlayst 6880

Cheers
Andy

 

DISTRIBUTION SWITCH

cts sxp filter-enable
!
cts sxp filter-list SGT2
permit sgt 2
!
cts sxp filter-group speaker SGT2
peer ipv4 <ACCESS-SWITCH-MGMT-IP>
!
cts sxp connection peer <ACCESS-SWITCH-MGMT-IP> source <DISTRIBUTION-SWITCH-MGMT-IP> password default mode local speaker

 

ACCESS

cts sxp connection peer <DISTRIBUTION-SWITCH-MGMT-IP> password default mode peer speaker

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: