cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

813
Views
0
Helpful
4
Replies
Cisco Employee

F5 loadbalance on RADIUS + T+

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

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Advocate

Re: F5 RADIUS Device Admin using ISE RADIUS

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

View solution in original post

4 REPLIES 4
Cisco Employee

Re: F5 RADIUS Device Admin using ISE RADIUS

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.

Cisco Employee

Re: F5 RADIUS Device Admin using ISE RADIUS

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?

Cisco Employee

Re: F5 RADIUS Device Admin using ISE RADIUS

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+?

Advocate

Re: F5 RADIUS Device Admin using ISE RADIUS

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

View solution in original post