ISE - where do portals reside?

[Kevin-H]

Where do the ISE portals reside? PAN or PSN?

For BYOD & guest flows, I know the portal is on the PSN that the user gets redirected to.

But what about the portals that users go to directly, such as My Devices, or Sponsor portal?

I need to know exactly where they are, so that I can create the appropriate DNS A records pointing to the correct node(s).

If the portals can be on multiple nodes, how would you handle fault detection & mitigation, w/o using a load balancer?

TIA

[Rob Ingram]

Hi, The portals are hosted on the PSNs. I guess without a load balancer you could use DNS round robin (never personally tried it). You need to ensure you use a wildcard or universal certificate (a SAN entry for each PSN) so you don't get any certificate errors.
HTH

[Arne Bier]

This is indeed a tricky subject.  As a technical reference I would look at BRK-SEC3699 from CiscoLive (Craig Hyps) - this is the bible of information for this stuff.  Craig has also done a lot of great work with F5 in putting together a guide of how to integrate their load balancers. 

It gets tricky.

Bottom line is that the PSN's run all the portals to do with Guest and BYO on TCP/443 with automatic redirects to 8443, etc. depending on whether you have configured custom ports in the portal config section.  The admin GUI runs on all nodes (including PAN and MnT on TCP/443).

In my customer case we use F5 load balancers.  We have several F5 LTM 'Virtual Servers' depending on what we want to load balance:  e.g.

VS_1 for handling radius and webauth traffic.  The pool members are the PSN's that have Policy services enabled.

VS_2 for handling TACACS traffic. Pool members are the PSN's that have the TACACS services enabled

VS_3 for handling Admin GUI traffic (to handle PAN failover)

The hardest part in all of this is to ensure that your load balancer handles session persistence. In other words, the first time the LB sees some new traffic and makes a load balancing decision, all subsequent traffic from that client MUST go to the same PSN.  If this is not done, nothing will work.  e.g. if LB sends Guest MAB traffic to PSN-1, and then web session comes along and LB incorrectly load balances this to PSN-2, then portal will not work. Session persistence must be based on common attributes that you see in all traffic - e.g Framed IP address, or Calling-Station-Id - see the BRKSEC-3699 - if you are doing multi vendor like Aruba, then you cannot use Cisco's Session Accounting ID as a persistence attribute (as tempting as it may seem).  Things will break.  Make it as generic as possible.

If you don't have a fancy load balancer in place, then there are folks you have built ISE policies that mimic the behaviour.  One such case is over in the ISE Communities Forum https://communities.cisco.com/thread/84157 - see the comments made by Paul Berbee about implementing load balancing without a load balancer.