F5 loadbalance on RADIUS + T+

[dvan]

Hi,

Are there any published best practices documents or guides for performing Cisco Device Administration against ISE via RADIUS in an F5 LB setup? Have searched around with no luck so far...  The current F5 & ISE deployment guide covers network access only.

Thanks,

Denis

[hslai]

Nothing from our product team. Each vendor and products have varied implementations to accept AAA authentications for device administration purposes so please refer to vendor docs.

These two F5 links might help.

F5 Radius Authentication for admins

SOL14324 - Using F5 vendor-specific attributes with RADIUS authentication (11.x -12.x)

You may use dictionary.f5 to import the F5 VSAs to ISE.

[dvan]

Thanks Hsing-Tsu.

What I'm specifically after is an F5 persistence setup when using ISE for both network access and device administration purposes (RADIUS only).

According to the F5 & ISE Deployment guide which covers network access (not device admin), Calling Station ID is a recommended persistence method with a fall back in place (Eg. Source IP).

What I've found is that with Cisco WLCs, device admin RADIUS requests don't contain the Calling Station ID, causing the fall back method to be hit, which then causes all new requests from the WLC (including network access requests) to stick to one ISE PSN.  With enough load from the WLC, this has the potential to overload the PSN rather than spread the load amongst the PSN pool.

Is there any Cisco recommended and/or tested persistence method for device admin in a Load Balanced setup?

[hslai]

That is correct that T+ not relying calling-station-Id. I believe it would work to load balance based on the field "remote address". chyps may comment on this further.

BTW, are you not separating PSNs for RADIUS and T+?

[Craig Hyps · Accepted solution]

If I understand the issue correctly, no TACACS+ involved, just user and device admin--both using RADIUS.

The F5 should be matching on more specific record, so LTM should not be reverting all sessions based on source IP only.  If seeing issue for any new connections then we may need to work with F5 to see best way to prevent this from occurring, and only leverage existing IP-based persist entry when Calling-Station-ID is not present.   For some NADs it is possible to populate the Calling-Station-Id with the client IP so that should allow persist on client IP.

Another option may be to fallback to RADIUS username, NAS Port ID, NAS Port Type, etc, such that you are able to distinguish and persist device admin auth requests from network access requests.  For example, on my switch, a RADIUS auth via SSH to switch yields:

     Calling-Station-ID: Admin client IP address

     Nas-Port-Id: tty2

     Nas-Port-Type: Virtual

/Craig