10-05-2017 07:31 PM
Hi
The F5/Cisco interworking has been well documented and we have applied all the concepts from BRK-3699 and the famous Cisco/F5 document.
I am faced with integrating an Aruba 7210 Controller into my ISE deployment, that needs to provide access to the same Sponsored Guest access solution that we have built around the Cisco WLC and F5. I am having a hard time wrapping my head around how Aruba do things with its static URL redirection etc. But before I even get to that point, our F5 guys have to change the iRules to allow the Aruba radius traffic through the Virtual Server, since the current virtual server expects to see the Cisco AuditSessionID
The F5 is currently configured to create persistence based on the AuditSessionID because we want to persist across re-authentications - this is a great identifier that the F5 can leverage in Accounting Records, and also URL redirects - all with the aim of ensuring a reliable session persistence experience, including re-authentications.
Aruba doesn't support that Cisco VSA. So I am wondering whether to
Has anyone out there deployed Aruba Controllers across more than one PSN behind an F5 firewall for load balancing?
I would like to see the Aruba configuration for that situation, since, from what I have read/seen, the static External Captive Portal URL is hard coded with an IP address - and this surely cannot scale beyond one PSN???!!!
Any guidance appreciated.
Solved! Go to Solution.
10-06-2017 03:25 AM
In general I discourage the use of the session ID since NADs, particularly wireless, often change the session ID or new sessions get triggered from roaming. This will cause a thrash on the backend as PSNs must address the potential replication requirements and change of ownerships. In other words, a given client can trigger many different session IDs over time and will consequently be load balanced across many different PSNs. For this reason I typically advocate Calling Station ID for persistence since same client will hit same PSN regardless of the session ID triggered (or not) by the Cisco or 3rd-party NAD.
One option that would work across different NADs is to persist RADIUS on Calling Station ID and to add the Framed-IP to the persistence/sticky table, then load balance HTTP based on source IP. Example config provided here: F5 LTM loadbalancing Radius and HTTP traffic for ISE - Cisco
This will allow HTTP traffic to be sent to same PSN as used for RADIUS.
/Craig
10-06-2017 03:25 AM
In general I discourage the use of the session ID since NADs, particularly wireless, often change the session ID or new sessions get triggered from roaming. This will cause a thrash on the backend as PSNs must address the potential replication requirements and change of ownerships. In other words, a given client can trigger many different session IDs over time and will consequently be load balanced across many different PSNs. For this reason I typically advocate Calling Station ID for persistence since same client will hit same PSN regardless of the session ID triggered (or not) by the Cisco or 3rd-party NAD.
One option that would work across different NADs is to persist RADIUS on Calling Station ID and to add the Framed-IP to the persistence/sticky table, then load balance HTTP based on source IP. Example config provided here: F5 LTM loadbalancing Radius and HTTP traffic for ISE - Cisco
This will allow HTTP traffic to be sent to same PSN as used for RADIUS.
/Craig
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide