To get you started with some baseline information, the scale of a hybrid deployment on 2.4, where the PAN and MNT functionality is shared on the same nodes, is only 20k active endpoints. Even if you were to leverage 2.6 and 3695 VM's (256GB), total active endpoint count for a hybrid deployment is only 50k. If 60k is a reliable number, then you need 4 dedicated nodes to handle PAN/MNT functions, using additional dedicated PSNs for authentication. Each dedicated 2.4 3595 VM will support 40k active endpoints. You also want to consider failure and patching scenarios, where you put the PSN's depends on authentication load. It's also entirely possible to use 3515 nodes for PSNs, just more of them since they only support 7500 active endpoints. ... View more

Yes, you can follow the process in this link to have them converted to 2.4+ medium licenses. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-24/213171-ise-2-4-upgrade-alarms-fewer-vm-license.html If you are planning to upgrade to Release 2.4, contact ise-vm-license@cisco.com with sales order numbers that include VM purchase to procure one medium VM license for each VM previously purchased. You should also include your CCOID along with the sales order number. Alias is only for previously purchased customers who wish to upgrade to 2.4 and need PAKs. This is only the case if you bought traditional licenses, these are end of sale so all new licenses purchased are ready to install when you receive the pak. ... View more

Your authentication policy plan sounds like you have a good grasp on what you want to do. If I had the choice though I wouldn't do dvlans or dacls, I would build out TrustSec leveraging SGT's and SGACL that are vlan agnostic. It doesn't matter what IP or VLAN an endpoint is on, it depends what policy you write for your SGACLs. Now the caveat here is that you have to "build out" the TrustSec framework, carrying SGT's inline end to end is ideal, but in smaller environments you can inline tag in the LAN then use SXP to bridge the WAN. I say smaller environments because SXP doesn't scale great. There are lots of WAN overlays that support inline tagging today, a big miss right now is that Cisco SDWAN (Viptela) does not yet support inline tagging. A second caveat is the hardware support and I typically only suggest deploying TrustSec on the hardware that has full support. By full support I mean inline tagging and SGACL capabilities. There are some use cases where you do not need SGT's at the LAN or across the WAN, typically north south enforcement where you send SGT's to a central enforcement point, this is usually a warm up for a full deployment. Just an option. What ever you do, design to your requirements and make sure it's scalable and supportable, ... View more

I have changed the IP on a standalone ISE 2.4 lab server a few times. Leave the application running when you do it. int gigabitethernet 0 ip add x.x.x.x 255.255.255.0 If the node is part of a deployment, deregister it first. The process is covered in the 2.4 admin guide. https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/install_guide/b_ise_InstallationGuide24/b_ise_InstallationGuide24_chapter_0101.html#ID-1412-00000138 ... View more

No official support for ISE in the cloud. They could leverage the VMware Cloud offering in AWS and it would run.  VMware Cloud in AWS provides you the same functionality of on premise esxi, they use bare metal EC2 hosts.    Azure is out, you can't run ISE within a nested hyperv instance.   ... View more

The only reason I suggested leveraging WAN edge was because it would fewer SXP connections than going to each access switch which can be a scaling issue. Total mappings support on the Cat 9k's is also quite limited, they can only handle 10,000 IP-SGT mappings where as an ISR can support 125,000+. It sounds like you have a fairly large environment, so 10k mappings could easily be a scale issue. I would want to inline tag everything in the LAN to enable east west enforcement anyways. You would be dealing with fewer connections and no inline tagging work to add in for the future state. When (if) SDWAN ever supports native SGT inline tagging, then you would still need inline tagging in the LAN up to the router, you would just be dropping the SXP connections on the router when moving to SDWAN inline tagging. I have not spun up the SDWAN code on an ISR, but I know the commands are there for inline tagging, not sure if SXP is still in there, I would want to go this route if possible. I haven't tested it on SDWAN code, but after this discussion I think I will when I get time in the next couple of weeks. Your understanding of the mapping flow sounds correct, ISE will speak all static mappings you manually create as well as dynamic mappings created during authorization. It is a single point of truth for all IP-SGT mappings regardless of how they are generated, unless manually tagged on NADs. ... View more

You could simplify this by having ISE be the central speaker of all IP-SGT mappings and no return SXP connections. ISE will already be the source of truth for IP-SGT mappings since it knows them/learns them during authentication, you do not need to communicate them back to ISE. Building SXP connections from reflectors to the access layer isn't a requirement if you are willing to utilize inline tagging in the LAN. Take this as an example of what may help it scale better. You send these IP-SGT mappings to an ASR 1k with a speaker connection from ISE, then use the ASR 1k to speak them down to the WAN edge at sites. To scale this out a bit better, you could create a three tier topology, ISE speaker > ASR speaker > ISR 4k listener. Then within the LAN you leverage cts manual to perform inline tagging throughout the site. The ISR 4k utilizing the SXP IP-SGT mappings it learns, will retag any traffic egressing it's LAN interfaces. The core/distribution/access would be configured for inline tagging and sgacl enforcement. It doesn't have to be an ISR 4k either, they are just a reasonably scalable platform when it comes to mappings, this would work with legacy ISR G2 platforms. This assumes you have inline tagging capable hardware from the remote site WAN edge down to the access layer.   ... View more

How many sites and SGT mappings are you looking at? It could be beneficial to leverage ISE as the SXP reflector (or simply the speaker), rather than dedicating some expensive hardware to it. We managed ~130 bidirectional connections on dedicated ASR's with approximately 40k IP-SGT mappings. The CPU's on both ASR's were 90%+ at this point. This was the point where we stopped adding SXP connections, enforcement across the WAN from that point forward required an overlay and inline tagging. SXP across the WAN was a temporary measure here. I would try to stay away from designing anything at scale with bidirectional SXP connections as they are extremely resource intensive. I would actually avoid SXP in any form at scale since it just isn't a great protocol. It works great in limited deployment, point to point such as WLC to core, or access to access spanning a wireless bridge. When you start adding connections and mappings together to cross the WAN it just isn't efficient. I would strongly urge an overlay and inline tagging across the WAN. That's not to say SXP won't work for you, but it adds a scaling component. I would start that discussion with endpoint counts and and number sites/connections required. ... View more