ISE and Load Balancers

[NETAD]

Hello, I’m working on a project where we’re deploying a distributed ISE deployment that consists of 7 nodes. 2 admin/mnt and 5 PSNs used solely for TACACS. The customer wants to do the following: 

on the network devices, point to the LBs for tacacs and have the LB do the load balancing across the ISE. Nodes? Is this ok? I feel like this adds complexity.

Second, for the Admin nodes, he would like to put both of them behind an LB again and have to LB do a health check for the other secondary node. The reason behind this is to not have to instruct the administrator to start using the secondary admin node when the primary fails. Is this feasible at all? I don’t think so. 

[yalbikaw · Accepted solution]

Hello :)

check this link for tacacs and load balancing configuration

https://community.cisco.com/t5/security-blogs/how-to-tacacs-failover-with-f5-big-ip-virtual-servers/ba-p/3796384

the second option i don't see there is a need for this, like it will not be a constrain  to make this issue transparent for the administrator they can easily detect it and open the secondary pan.

[Arne Bier · Accepted solution]

Hi @NETAD 

I will answer your second question.  Yes it's very possible and I have done it with a large customer using F5 load balancers.  It's not a case of load balancing traffic to the PAN's, but rather, it's a DNS discussion (i.e. F5 GTM).  The LTM in each data centre polls its local PAN using REST API.  The F5 can interpret the XML that comes back to figure out whether that PAN is the master or not.  If it is, then it tells the GTM to be authoritative for the DNS resolution of the PAN URL.  This has the great benefit that you only need a single FQDN for your ISE PAN !! e.g.   iseadmin.mycompany.com - you don't care which PAN is the active one - you will always get the right answer via DNS (which is informed by the F5 GTM/LTM combination).  The REST call is a simple one about the node info (check the docos).

As for 5 PSN nodes doing TACACS.  If you want to keep them all equally busy then using a load balancer is the only (smart) way to do this.  If you had 1000 switches, then you could theoretically manually load balance by configuring the first 200 switches to point to PSN1, then next 200 switches to PSN 2, etc. - same story for the Secondary TACACS server (maybe chose the PSN5, 4, 3, 2, 1 in that order - whatever - you get the idea) - poor man's load balancing :-)  But the chances are that this will not have the desired effect of keeping each PSN 20%  busy all the time.  Only a load balancer will quasi guarantee that.

[NETAD]

Thank you so much. Very theral like usual. Can I get the doc link for the REST API?

[Arne Bier]

Hi

The API is documented somewhere on CCO, but I tend to get it from the PAN itself - you need to enable ERS and then assign an ISE admin user account to allow ERS access - by default I think the factory supplied admin can be (ab)used for that purpose ;-)

e.g. in my lab I called up the API documentation with

https://192.168.0.221:9060/ers/sdk#_ 

The API call is 

/ers/config/node/name/<PAN_node_name>

Below is the API call - the result you're looking for is

"primaryPapNode" : true

I only have one lab node, but if you ran this against a secondary PAN then it would return

"primaryPapNode" : false

[admin-biera@iptel-centos-01 ~]$ curl -k -v -X GET https://restapi:Encryption123@192.168.0.221:9060/ers/config/node/name/ise01 -H 'ACCEPT: application/json'
* About to connect() to 192.168.0.221 port 9060 (#0)
*   Trying 192.168.0.221...
* Connected to 192.168.0.221 (192.168.0.221) port 9060 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* Server auth using Basic with user 'restapi'
> GET /ers/config/node/name/ise01 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.0.221:9060
> ACCEPT: application/json
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, must-revalidate
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: JSESSIONIDSSO=8F19AF45AB203E4939229E6457A9ABAD; Path=/; Secure; HttpOnly
< Set-Cookie: APPSESSIONID=A7AB57EC45A99161F2F6DBEC3D7E6A35; Path=/ers; Secure; HttpOnly
< Pragma: no-cache
< ETag: "2D5E1AAE6110C382B56B6C8981E18E60"
< Date: Wed, 05 Jun 2019 02:26:20 GMT
< Content-Type: application/json;charset=utf-8
< Content-Length: 563
< Server:
<
{
  "Node" : {
    "id" : "aee5cb10-42d6-11e8-9914-0050568a2395",
    "name" : "ise01",
    "gateWay" : "192.168.0.1",
    "displayName" : "ise01",
    "inDeployment" : true,
    "otherPapFqdn" : "",
    "ipAddresses" : [ "192.168.0.221" ],
    "ipAddress" : "192.168.0.221",
    "nodeServiceTypes" : "SESSION,PROFILER,DEVICE ADMIN",
    "primaryPapNode" : true,
    "pxGridNode" : true,
    "papNode" : true,
    "link" : {
      "rel" : "self",
      "href" : "https://192.168.0.221:9060/ers/config/node/name/ise01",
      "type" : "application/xml"
    }
  }
* Connection #0 to host 192.168.0.221 left intact

[Timothy Riegert]

Hi, Arne - that's very helpful. Would you happen to have a screenshot / example of what the F5 health monitor setup would like for that setup that you could share by any chance? Is it just a standard HTTPS monitor where you look in the "receive string" for that or does it require an external monitor? Appreciate any insight you can provide. Thanks again -tim

[Arne Bier]

Hi Tim

I don’t have a screenshot unfortunately but from memory (customer showed me briefly) it was a health probe that did a http GET to a URL (same as I mentioned in my previous post) and they filled in the authentication stuff as required. The results were parsed by a regex to pull out the desired data. It was in the GUI. F5 is amazing and it does this natively. 

[Jason Kunst · Accepted solution]

Some things for help
http://cs.co/ise-api
https://community.cisco.com/t5/security-documents/ise-guest-sponsor-api-tips-amp-tricks/ta-p/3636773

[scott.stapleton]

From memory, IOS can also load balance to TACACS / RADIUS.

[Damien Miller]

As a more general note on this conversation and more of a just in case tidbit. I wouldn't put all five psns behind the same VIP or even the same load balancer. You want to account for failures in all aspects of the design.

I would also account for an AD failure behind ISE, I reccomend using an AD service account to perform a radius authentication health check. This way you test back to the directory service and can pull a bad node from the VIP.

Cool idea putting the PANs behind a VIP. I've recently had quite a few headaches with non PSN ISE nodes using F5's for default gateways and it makes me hesitant.