PSN load balancing (Located in Different DCs)

[GRANT3779]

Hi All,

Please see attached for high level overview of the placement of PSNs. We have an F5 LB at each DC. There will eventually be more PSNs located at each DC.

I read through the F5 / ISE guide here - 

https://communities.cisco.com/docs/DOC-68198

This all makes sense but seems more aimed at when PSNs are located in same location. I am looking at what is best practise load balancing with the current topology and PSN placement.

My thinking was the following.

DC1 F5 would load balance between PSNs in DC1 and DC2. (call this F5 active)

DC2 F5 would load balance between PSNs in DC2 and DC1. (call this F5 standby)

In my radius groups on my NADs I would list the two F5 addresses, essentially acting as an active/standby radius config.

I was also hoping to use a common FQDN for the whole CWA url-redirect setup, e.g "guest.company.com" but concerned about redirects and the breaking of session-id.
I could create a DNS entry for guest.company.com and point the record to the "active" DC F5 LB addresses which I think would work (to an extent). However if that "active" F5 address goes down and my NADs send radius traffic to the "standby" F5 address, I would then need to manually amend DNS entry to point to the "standby" F5 address, meaning manual intervention.

Hopefully the above is clear...ish, and apologies for the long winded text.

Anyone else with similar setups, and what are you doing for LB and also CWA URL?

Thanks in advance.

[Marvin Rhoads · Accepted solution]

I did a somewhat similar installation but the client had L2 VLANs extended between the DCs so we were able to use a single address for the F5 VIP.

A lot depends on whether you are using (and/or have the code that's able to use) RADIUS load balancing on your NADs. If you aren't and the primary DC will always get the RADIUS requests (except when it times out and for whatever reason you fail over to the secondary DC) then you are OK. If you are doing round-robin RADIUS then you may have the issues you wrote about.

A given F5 (or F5 cluster) will use stickiness to keep a given calling-station-ID (MAC address) on the correct PSN as long as it gets the RADIUS traffic.

Regarding DNS, I would think if you had the F5 GTM feature setup that could swing resolution to the alternate DC when it is active.

[GRANT3779]

Thanks for the Input Marvin,

On my PSNs is there a way for me to say within my authorisation rules -

"If the Radius Request has been sent from the DC1 F5 address then use a certain Auth Profile"

e.g..

If I have two DNS entries pointing to each of my DC F5s. e.g

guest1.company.com points to DC1 F5 address (Say 1.1.1.1)
guest2.company.com points to DC2 F5 address (Say 2.2.2.2)

I need to be sure to return the correct URL in my CWA redirect. If a NAD sends Radius traffic to DC2 F5 (2.2..2.2), I need to ensure my auth profile then returns guest2.company.com otherwise the whole session ID may break. Is there a way I can ensure the CWA redirect always returns the FQDN associated with the F5 that took the initial request? Only way i can think of is to have a rule somewhere that identifies this request came was sent from a certain load balancer address.

Thanks

[Marvin Rhoads]

GRANT3779  

The problem with that is that the RADIUS requests are coming from the network access device (NAD - i.e. the switch, WLC or ASA that is the authenticator on behalf of the endpoint supplicant).

[GRANT3779]

Yes you are right. My misunderstanding of F5 maybe. In this instance then does it make more sense for my DNS records to map to the real internal IP of the PSNs.

Example of a high level flow for a specific PSN–

Guest client connects to “Guest” SSID
WLC sends Radius request to say "DC1" F5 IP
F5 will load balance to one of the PSNs
Auth Profile says if Network Access ISE Hostname equals PSN1.. send url-redirect guest1.company.com

Guest client looks up the DNS for the url which would resolve to PSN1, routing directly to it (bypassing F5).

Would this work or does return traffic need to go via F5?

This would not scale well though once I have more PSNs at each DC I guess.

Any suggestions to other options? Doesn't seem to be a typical design from all the docs I am reading.

[Marvin Rhoads]

You have the option of load balancing the CWA and other PSN-hosted web pages in addition to the RADIUS sessions. It all depends on your scalability and availability goals.

In addition to the F5 - ISE guide, also have a look at Craig Hyps' excellent Cisco Live presentations on "Designing ISE for Scale and High Availability" (BRKSEC-3699).

[Amadou TOURE]

Grant, Marvin,

If I'm not mistaken, the URL for the CWA redirection will be push automatically to the NAD by the PSN which authenticated the endpoint so it will have the PSN hostname not the common hostname.

Even if you created a common hostname, I'm wondering how it would be published to the endpoint after the authentication as the URL redirection is grayed-out in ISE configuration.

Thanks 

[Config T]

Instead of forcing your load balancer to load balance between PSN's at separate DC's, I would configure the load balancer to only load balance it's local PSN's. I would configure both load balancers with the same virtual-server IP address. Configure the load balancer to only advertise the virtual-server IP when at least one of the PSN's is passing health monitors ... if all local PSN's are offline then disable the virtual-server IP. Then use anycast and route metrics to manipulate which branch locations prefer which DC locations. If any DC goes down, the ISE virtual-server IP is automatically withdrawn and the NADs at all branches will automatically find the remaining ISE virtual-server. With this design you only have to configure one radius server IP address on all of your NADs and you could scale the design to include unlimited redundant DCs/ISE virtual-servers without ever touching the NAD again.