Trying to load Balance several Cisco ISE servers.

[mohanakrishna]

Trying to load Balance several Cisco ISE servers.  For persistence, Cisco recommends using Calling-Station-ID and Framed-IP-address...Session-ID is recommended if load balancer is capable of it.  I have documentation for the Cisco ACE, but using F5 LTM's.  Assuming this has to be done with an I-Rule as none of these are available as a default.  Not sue where to begin.  I tried attaching the Cisco PDF, but not able for whatever reason.

[Ravi Singh]

Please also keep in mind that When using a Load-Balancer (anyone's) you must ensure a few things.

• Each PSN must be reachable by the      PAN /  MNT directly, without having to go through NAT (Routed mode LB,       not NAT). No Source-NAT. This includes the Accounting      messages, not  just the Authentication ones.
  
  • This means the       Load-Balancer must be in the direct path between the clients and the ISE PSNs.
  • Some       organizations have used Policy  Based Routing (PBR) to accomplish the       path, without physically  locating the Load-Balancer between the clients       and the PSNs.
• Endpoints (clients) must be able      to  reach each Policy Services Node Directly (not going through the VIP) for       redirections/Centralized Web Authentication/Posture  Assessments/Native      Supplicant Provisioning, and more.
• You may want to "hack"      the certs to include the VIP FQDN in the SAN field (my next blog post      should cover this trick).
• Perform sticky (aka: persistence)      based on Calling-Station-ID and Framed-IP-address.
• VIP gets listed as the RADIUS      server of each NAD for all 802.1X related AAA.
• Dynamic-Authorization (CoA):
  
  • If you use       Server NAT to replace the  PSN IP address with the VIP Address for Change       of Authorization,  then you would use the VIP address as the       Dynamic-Authorization  (CoA) client.
  • Otherwise, use       the real IP Address of the PSN, not the VIP.
• The LoadBalancers get listed as      NADs in ISE so their test authentications may be answered, to keep the      probes alive.
• ISE uses the Layer-3 Address      to  identify the NAD, not the NAS-IP-Address in the RADIUS packet. This       is a big reason to avoid SNAT.

Failure Scenarios:

• The VIP is the RADIUS Server, so      if the  entire VIP is down, then the NAD should fail over to the Secondary       DataCenter VIP (listed as the secondary RADIUS server on the NAD).
• Use probes on the Load-Balancers      to ensure that RADIUS is responding, as well as HTTPS (at minimum).
  
  • LB Probes       should send test RADIUS  messages to each PSE periodically, to ensure that       RADIUS is  responding, not just look for open UDP ports.
  • LB Probe should       also examine the response for HTTPS, not just look for the open port(s).
• Use node-groups with the L2-adjacent      PSN's behind the VIP.
  
  • If the       session was in process and one  of the PSN's in a node-group fails,       then another member of the  node-group will issue a CoA-reauth; forcing       the session to begin  again. 
  • At this point,       the LB should have  failed the dead PSN due to the probes configured       in the LB; and so  this new authentication request will reach the LB &       be  directed to a different PSN…

[Tarik Admani]

Mohana,

The link that Ravi is referencing is from a blog which is posted below -

https://supportforums.cisco.com/community/netpro/security/aaa/blog/2012/09/19/ise-and-load-balancing

You will need to set persistence or stickiness for the called-station-id since the ISE PSN generate radius state attributes for each client. If the session transitions from one psn to the next then this can cause a mess by dropped request and the load balancer marking psns dead.

I agree with you the loadbalancing scenario isnt well documented lets see if we can some help from Cisco and not links to general guides.

Tarik Admani
*Please rate helpful posts*