Forum Discussion

sandy16's avatar
sandy16
Icon for Altostratus rankAltostratus
Jan 23, 2013

F5 multi-arm mode design.

Hi, we plan to deploy a pair of LTMs in multi-arm/vlan mode. In other words the F5 sits in that vlan where it needs to load balance by having 3 ips in that vlan - floating ip and 2 self ips. The main reason to do this is as the customer has several vlans,vrfs and then deploying it in two-arm mode was making it to complex on the upstream firewalls to allow traffic. Hence we decided to go with the multi-arm mode.

 

Is this design valid or there are any issues in it?

 

10 Replies

  • Sorry, can you clarify your requirements please. It's probably just the terminology getting in the way.

     

     

    Are you wishing to have the clients, the VIP and the real servers in the same VLAN? If not, please elaborate a bit.

     

     

    I'm not sure why VRFs and VLANs are an issue, the F5 tags VLANs and has Route Domains if required.

     

     

  • Hi Steve, the VIP and the servers are in the same vlan. The clients can be anywhere in the internal network, as long as they can reach the VIP. We don`t want to use route-domains due to their complexity and moreover we are not doing a multi-tenancy setup and neither the ip-space/subnets overlap.
  • The servers have their default-gw to some switch, not the F5. We use auto-snat in our environment.
  • OK, so what I'd call one-armed mode =]

     

     

    This is a valid design. I'll always prefer having the F5 'in-line' and thus removing any need for SNAT (the route to clients is always through the F5 even if it isn't the first hop). An alternative of course is to have a flat VLAN server-side where the F5 is the only IP gateway (a stub if you will) - this provides the most flexibility and the easiest troubleshooting.

     

     

    If you ever need to do 'double bounce' - use the same LB to LB to web servers and then from the web servers to app servers one-armed mode will involve two SNATs, one per VIP. This can make tracking a single connection/flow very hard. In-line mode reduces this to one SNAT on the second VIP. Stub mode (if I can call it that) avoids SNAT altogether.
  • Steve -- with 'stub mode', with client traffic unSNAT'ed and with server gateway set to F5, do you have a suggestion for server backups? We've avoided this configuration because server-initated traffic would otherwise swamp the F5 interfaces. My apologies if this is hijacking the thread!
  • No worries. You can do a few things here;

     

     

    1) Use a dedicated server backup interface on a different subnet/VLAN that doesn't pass through the F5 (same or different local switch, doesn't really matter)

     

    2) Use the same server interface but VLAN tagging to a different subnet/VLAN that doesn't pass through the F5 (same or different local switch, doesn't really matter)

     

    3) Use a Performance (Layer4) VS to handle the traffic with minimal overhead (assuming bandwidth completely swamped)

     

    4) If bandwidth is a real issue, do 3) but apply a suitable Rate Class to manage it (assuming this won't delay the backup too much)

     

     

    Personally in environments I work in 1) is the common approach whatever the infrastructure and regardless of the F5. That or direct SAN attachment. Hope this helps.
  • Thank you, Steve. Thankfully the F5 platform is plenty flexible, allowing one to shoot both feet at the same time :-}.