Forum Discussion

  • Inline and one arm don't really change LTM behavior as we are full proxying TCP connections.

     

    What is needed times to times is to be able to preserve source IP address to backend server. in such case you may need to deactivate SNAT (source NAT), then two architecture modes are available :

     

    • keep a proxy behavior with a VIP and make sure the come back traffic is routed to big-ip
    • implement a bridged mode with two arms.

    Otherwise if you don't need that, and you can SNAT all you applicative traffic, the LTM will behave the same with one or two arms.

     

    Some people like two arms for traffic segmentation at the firewall level, you can pretty much identify easily traffic going to the big-ip, from traffic going to the backend as you will be in different subnets. But even in this case, you could be physically on one arm, but logically on two with vlan tagging.

     

  • The basic difference between the two is routing and data flow. In an inline configuration, a request passes through one interface/VLAN on the client side, and out another interface/VLAN on the server side to get to the server. In a one-arm configuration, a request passes through a single interface/VLAN and back out that same interface/VLAN to get to the server. There should be no significant difference between the two modes from a performance perspective, but the one-arm mode does add one layer of complexity in that it generally requires a SNAT. Given that the BIG-IP VIP address and server IP are likely on the same subnet, there's a better chance that the server will have a direct route back to the client's source through the same external router. This is typically called "Direct Server Return" and can work, but requires additional configuration. In most cases though, you definitely want the response from the server to route back through the VIP, so a SNAT profile will change the client's source to force return routing. The down side of that is that you don't get the client's true source in the request for logging. You can still insert an X-Forwarded-For header with the client's true source, but that only applies to HTTP traffic. Otherwise you have to configure all of your servers to use the BIG-IP self-IP address as their default gateway.