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.
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.
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.
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…
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...