In-Line or One-Arm LTM Placement

I try to be less dogmatic in my advice. As much as we would all love the ideal greenfield deployment, the reality is far from that, so knowing all the options and how to best deal with them is important.

so can we convert the one arm mode deployment in two arm mode just pointing app servers gateway to bigip or i need two interfaces like inside and outside?

Hello prak,

The basic pre-requisite for In-line SNATless BigIP deployment is that Client-Side and Server-side traffic do not use identical VLAN tag information. If you already have servers in a given VLAN, it's best to take that existing VLAN number, and configure it in BigIP for use on the Server-Side (Internal). For the Client-Side (External) traffic you should allocate a different VLAN.

If you decide to go ahead with the design changes and need more help, I would gladly help you out if you post a separate question.

thanks Hannes. appreciate your reply. but how can you receive my question thread? should i mention here or any other way to get in touch?

In-Line implementations are most definitely advantageous in some situations. For example, legacy apps dependent on a true client address, "troubleshoot heavy" environments, non HTTP apps, etc.

To say one is better than the other is discounting real world variables and different environments. I work in 100s of different environments, and I can tell you no two are exactly the same. Different networks, different server placements, different cultures / people / politics. The correct methodology all depends - it's never static.

When designing new environments I always try to make SNAT and In-Line support available if possible.

The people and technology are always evolving in environments - The flexibility of delivering applications for anything you can route to is too great to discount.

Hi Austin,

"I work in 100s of different environments" - so you run around a lot, delivering large quantity of minimum viable setups?

I respect your experience in industry but there are too many environments built by those who bear no burden of having to maintain the systems on-goingly. There must be "that someone" behind those dreadful designs. But as long as clients are happy, it can even be a win-win.

In the context we're discussing, SNAT is a mitigation feature to address shortcomings in routing topology. It's a strong medicine with side-effects, should not be taken unless the issues are severe.

Hannes,

It would be nice if everyone had the luxury of re-configuring every network we work in, providing in-line support wouldn't be all I changed. More often than not, network segmentation has run it's course by the time BIG-IPs make it in a network. Which equates to quite the effort for complete in-line support.

If we were only concerned with being profitable we would limit customers into our ideology that some features are never good in any scenario. Doing things like locking companies into one network design and never supporting features like SNAT creates more work, not less.

Fact of the matter is it doesn't matter if you're a consultant or Joe Network engineer, 9 times out of 10 times you're not going to get company buy in to jack around servers and/or make a bunch of network changes to support in-line communication - unless it's absolutely necessary and can demonstrate so. I can't tell you how many times a company battled me for adding another subnet for "future" in-line support, only to be thankful sooner than later down the line when they run into an issue and need it.

SNAT provides flexibility in environments that are reliant on their routing topologies and are reluctant / unable to make changes to their servers & network configurations to support in-line communication.

I'm the first person to push in-line support, I prefer seeing the real address in my logs too. I especially prefer in-line communication in Internet facing DMZs - for obvious reasons.

SNAT isn't at all "bad", it's not akin to an illness, it's just a feature that allows you to be flexible. If we went along that premise, you would say the whole BIG-IP platform is bad, overcoming shortcoming of TCP/IP and many other protocols. Is it bad to use oneconnect to improve performance of backend connecttions? Oneconnect makes it harder to troublehsoot designs too. One could make the argument the backend connections were't "sick" before oneconnect was implemented.. See where I'm going? Have an open mind, all we can do is make our decisions based on the technical data and real work environment details. In our line of work the answer is rarely static..