Yes this is possible and should be working assuming you are on the correct platform with the configuration for it. TrustSec is of course vlan/subnet independent, all that matters is the SGT to IP binding and the SGACL that would apply between the tag/tags. So your policy should be working if everything else is up to it. When you are being enforced across VLANs, is that also on the same switch, just different vlans, or different switches? If we cover the basics when you are trying same vlan enforcement, does it meet some basic criteria, 1. Is the switch model capable of SGACL enforcement 2. Is the vlan included in the "cts role-based enforcement vlan-list" of the switch(s) 3. Do the SGACL's show up in "sh cts role-based permissions" 4. Do both endpoints display their "local" mappings in "sh cts role-based sgt-map all" ... View more

Yes, that is exactly what the command does. Keep in mind that if you are using a load balancer then you also want your persistence value set slightly higher than the interim accounting interval. Cisco has started recommending 2880 minutes in most configuration examples but other values are still valid. ... View more

I tested and encountered the issue with both 16.6.6 and 16.9.3, the bug notes indicate less reach than I found. I believe this is not platform dependent but an issue with the software. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvq78911 Switching "automate-tester username test ignore-acct-port probe-on" to "automate-tester username test probe-on" fixed my device sensor issue. I used the following. Hit me up on teams and I can send you over the full config if you need. I intentionally avoided snmp query probe, otherwise I think it would have masked the issue, I suspect this is an issue a lot of deployments have since Hari's guide suggests the "ignore-acct-port" option. accounting/device sensor specific config. aaa accounting update newinfo periodic 2880 ! device-sensor filter-list cdp list cdp-list tlv name device-name tlv name address-type tlv name capabilities-type tlv name version-type tlv name platform-type ! device-sensor filter-list lldp list lldp-list tlv name system-name tlv name system-description tlv name system-capabilities ! device-sensor filter-list dhcp list dhcp-list option name host-name option name requested-address option name parameter-request-list option name class-identifier option name client-identifier ! device-sensor filter-spec lldp include list lldp-list device-sensor filter-spec cdp include list cdp-list device-sensor filter-spec dhcp include list dhcp-list ! access-session attributes filter-list list DS_LIST vlan-id cdp lldp dhcp http ! access-session authentication attributes filter-spec include list DS_LIST access-session accounting attributes filter-spec include list DS_LIST device-sensor notify all-changes ! radius-server attribute 6 on-for-login-auth radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius-server dead-criteria time 30 tries 3 radius-server vsa send ... View more

Are you using the automated tester with ignore accounting option? I just logged a new bug where the switch doesn't send device sensor cache. ... View more

Are you using TACACS on this deployment? I have an issue we identified on 2.4 that causes this under load. I haven't used 2.3 with any customers deployments but possible the same issues exist. All of the ISE nodes send health status syslogs to the MNT's. The typical cause for this issues exists not because the nodes stop sending the syslogs (as indicated by Craigs old post), but the MNT collector cannot ingest them quickly enough. Log ingestion lags behind to the point where the nodes appear to be down because the syslogs are still stuck in buffer files. There are a number of reasons why the logs don't get ingested quickly enough, most of them have been fixed. Is there a reason you are on patch 6 and not patch 7? The following two issues are related to causing these messages and are fixed in 2.3 patch 7. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn12442 https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvq73457 If you move to patch 7 and this is still and issue, you will need to work with TAC. ... View more

Have you tried installing the patch from the CLI? It would be my preferred method since you are in control. very simple command, patch install <patch_bundle> <repository_that_stores_patch_file> ... View more

There are a few issues that can cause this but you will have to work with TAC to diagnose. Your thought process is correct here, the most common cause is if the syslog buffers do not get ingested by the collector process quickly enough, then the health status alarm will be triggered since ISE think's the node is missing. I am working through this on 2.4 p8/9 right now, and it was also a frequent issue for a number of my customers on earlier patches. I was not expecting to face this issue again since most of those were corrected in earlier patches. If by chance you are leveraging TACACS on this deployment, then we may be facing the same issue and I could share the case number for TAC to check on. ... View more