Forum Discussion
In-Line or One-Arm LTM Placement
I do not approve ingress SNAT or SNAT pools in any circumstance :p
True L3 IP visibility on a lower level is the cornerstone of smooth troubleshooting. These days, such networks are a minority, but I always advocate for the use of 2 Default Gateways (IP rules) in end-servers, if F5 cannot be the only default gateway.
BigIP with explicit use of SNAT (one-arm/one-VLAN deployment) may work, but there are CAUTIONS:
- Loss of availability to run tcpdump against true client-src-IP in end-servers, and any other device in line after BigIP. This alone, without considering any other facts or variables, makes the deployment unclean/dirty.
- Risk breaching TCP src-port limits on Server-Side. You can have ~64k concurrent server-side connections from your SNAT-IP to a pool member (dest-ip/port-no combo). It makes it far easier to breach those limits if more clients are stacked up on the same src-IP.
- Once the limit above is breached, you are likely to opt for 'SNAT Pools' - this will convert your infrastructure into a clusterfuck.
- Now, as a dedicated administrator of a clusterfuck infrastructure, what kind of evidence can you provide to an external party, to convincingly prove that incident is not linked to a "possible network issue on your side"? What will you say if they ask for a tcpdump against their source IP-address from the end-servers?
- JRahmJan 09, 2017
Admin
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.
- Harry1Jan 12, 2017
Nimbostratus
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?
- Hannes_Rapp_162Jan 12, 2017
Nacreous
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.
- Harry1Jan 13, 2017
Nimbostratus
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?
- Austin_Geraci_3Jan 13, 2017
Cirrus
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.
- Hannes_Rapp_162Jan 13, 2017
Nacreous
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.
- Jan 13, 2017
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..
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com