F5 load balancing for PSN's

[hpretori]

Hi there,

We have two PSN groups, each consisting of 5 PSN’s. Each group needs to be load balanced by a F5.

The customer has this F5 deployed “on a stick” in layer 3 mode.

I have read Craig Hyps doc on this “HowTo-95-Cisco_and_F5_Deployment_Guide-ISE_Load_Balancing_Using_BIG-IP.pdf” and it does not cover this particular scenario (and I’m guessing for good reason)

The scenario his doc does cover with “on a stick” mode is to trunk the outside and inside vlan down the stick. i.e. the LB becomes logically inline in front of the PSN’s

With the customers setup the LB has no inside or outside. It’s one L3 interface used for in and out. They also use SNAT. I advised them that this will break RADIUS for ISE we cannot do SNAT. However if they remove SNAT and therefore just do a vanilla LB to the PSN’s (with sticky IP and or MAC) then traffic from client-A will hit PSN-A, return traffic from PSN-A will bypass the LB. Asymmetric routing will take place which is never a good idea, but the customer is hesitant to spin up a new virtual guest and make it logically inline (as I suggested it to them). 

Questions:

1. Is the customers “on a stick” L3 mode with no inside and outside supported for a PSN LB scenario?
2. If not, why not.

Regards

Henk

[hslai]

Have you not asked Craig directly on this?

It seems to me that the reason for the trunk is to be able to bridge the requests and responses without SNAT.

[hpretori]

I have now asked Craig directly - sent an email to him couple of minutes ago.

RE your comment, if you wanted to make sure the connections come back to the F5 you would need the SNAT. So not being F5 expert, maybe F5 wouldn't like it with this scenario if SNAT is turned off and return traffic is bypassing the F5 completely.

Not sure.

By having F5 logically inline without SNAT the path in and out stays the same.

simply put it would break IP as the source wouldnt get a reply in sequence from the destination it sent to.

Ive sent an email to the customer that F5 must go inline logically or physically.

[Craig Hyps · Accepted solution]

Hendrick,

It is technically possible to deploy F5 "on a stick".  The primary issue with models that do not have ISE physically or logically inline is the likelihood of asymmetric traffic and misunderstanding of the individual flow paths.  The most common issue with these deployments is traffic drop by one of the devices in the multiple traffic paths (load balancer, access device, PSN, or some other security device like a firewall that doesn't like the one-way flows).

After helping troubleshoot a number of these deployments including "on a stick" and other asymmetric implementations, the typical root cause was lack of understanding of flows. Even after discovering where traffic drop was occurring, often the solution was to simplify flow and place LB inline rather than redesign to compensate for asymmetry. While writing the guide I reviewed the scenarios with F5 subject matter experts and we mutually agreed that only the inline scenario should initially be covered in the guide.  I wanted to provide best practices and recommendations that would ensure the highest chance for success.  That is why guide does not cover non-inline models. Most successful and trouble-free deployments deploy inline. 

To handle asymmetry, often require LB configured for asymmetric traffic. PSNs should use LB as its default gateway (or use PBR for L3 setup). If bypass LB on return, the NAD will see the response coming from PSN IP address rather than VIP address. The PSN address is not the IP used to send packet!  Unless NAD has option to accept these IP changes, it will drop the packet.  Cisco switches and routers have alias option to accept packets from trusted IPs that do not match RADIUS target; Cisco wireless controllers currently do not support this option.

Hope that helps clarify options and why inline is generally recommended.  For more info, please refer to BRKSEC-3699 session on CiscoLive Online.

Craig

[hpretori]

Thanks for your response Craig,

that's valuable info.

regards

Henk