Whether you’re just getting your start in Application Delivery and SNAT, or you’re a veteran who never took the time to understand what automap is and how address translation works with the F5® BIG-IP®, I’m confident you will find this information indispensable.
Address Translation and the F5 BIG-IP
We’ll dive into detail explanations on the 3 ways the BIG-IP can perform address translation:
- SNAT
- NAT
- Virtual Servers
Aside from address translation, we’ll also cover traffic the BIG-IP LTMs handle and doesn’t do any address translation for, which we refer to as In-Line or inline communication. Grab some coffee, tea, or whatever your drink of choice is and let’s snuggle up to some address-translation in the awesome world of F5…
What is SNAT?
I’ve seen SNAT referenced two ways in F5s documentation, Source Network Address Translation, and Secure Network Address Translation, both of which are correct. “Source” makes it’s easier to understand, because you are translating the “source” addresses of the client initiating traffic or as the devices references it the “origin”. It’s “Secure” because you can’t initiate traffic to a SNAT, the “translation” addresses are never known by the host initiating the traffic. In short a SNAT is made of up three components:
- Translation – Options: an IP address (single address), a SNAT Pool (multiple addresses), or an Automap(self IP(s) of the Local Traffic Manager™). This is what the Source address of the client is translated to.
- Origin – Options: All addresses (everything coming in on the VLAN you specify, or an Address list (specific addresses you provide). These are indeed the source addresses of the client.
- VLAN Traffic – Options: All VLANs (every VLAN), Enabled on (only on the VLANs specified), or Disabled on (on all VLANs except the ones you specify)
The most common misunderstanding is how SNAT can be used. Unlike a traditional NAT, you can’t send traffic to a SNAT address. SNATs are either global (i.e. traffic coming through a LTM®), or they can be associated with a Virtual Server.
The first option is the hardest to get your head around, the second option, associating with a Virtual Server, is a lot easier to grasp and is usually everyone’s first exposure to SNAT, using “SNAT automap” applied to a virtual server. In both examples SNAT is generally used to solve routing issues and can be used with a variety of mappings but not limited to, one to one, many to one, all to one, etc etc. Let’s dive into the first option and see if we can get a better understanding of SNAT not applied to a Virtual Server, but affecting the LTM globally.
Global traffic and SNAT
Outbound Traffic – Translating the source address of many hosts on an internal non Internet routable subnet to one external Internet routable address is a common problem solved with SNAT. Think about how your home router works, it’s not the same but is a similar concept. When traffic hits the BIG-IP, the ”origin” would equate to an “address list” you specify with all the hosts in it or “all addresses” for that specific VLAN, the “Translation” would be one single address.(in this example). The destination addresses now sees the “Translation” address as your new source. When traffic returns to the BIG-IP from the destination it is then translated back to the original origin address. It’s important to note, by default SNATs are allowed on all VLANs, but you can get more granular and split them out between multiple VLANs.
Virtual Servers and SNAT
Inbound Traffic – Virtual Servers can have SNATs applied to them effectively changing the source of the Client initiating traffic to the VS. Here’s the really cool part about SNATing: with SNAT anything you can route to you can load balance to! That, my F5ers, is a beautiful thing! You see, in most cases, the servers you want to load balance are NOT going to have the BIG-IP as their gateway, so unless you translate the source address to something that belongs to the BIG-IP, you’re going to end up routing “around” the BIG-IP and not “through” the BIG-IP. Resulting in your VS not working and what we call asymmetrical routing, a fancy term for traffic taking different routing paths in one direction or the other. Asymmetrical routing is not always going to break traffic, but when dealing with a stateful device, something that maintains a connection like the Full Proxy BIG-IP, asymmetrical routing can break your communication.
What is SNAT automap, a simple explanation
Everyone’s first exposure to SNAT is usually SNAT automap. A lot of organizations, at some point, just turn this on without a good understanding of SNAT. Hopefully after reading this article you have a better understanding of the inner workings of SNAT.
The SNAT automap feature is going change the source address of the communication to the self-ip of the exit interface in a specific order of preference. Again, this is so the communication comes back to the load balancer. Otherwise the destination host would route around the load balancer when communicating back to the client, resulting in asymmetric traffic. Unless of course the servers have the Local Traffic Manager (LTM) as their gateway, which I discuss in the “inline” section below.
SNAT automap order of preference
AJ asked a good question in the comments below that merits an update to this article, and it pertains to “order of preference”. Automap is going to select the source address from available Self-IPs in a specific order of preference as follows:
- Floating Self-IP addresses on the egress VLAN
- Floating self IP addresses on different VLANs
- Non-floating self IP addresses on the egress VLAN
- Non-floating self IP addresses on different VLANs
One of the main reason it prefers the float is, you got it AJ, in scenarios where there is a HA configuration and a failover event occurs we want to make sure the return traffic follows the newly activated device / traffic group.
Alternative to SNAT: Inline
An alternative to SNAT would be an Inline design. Having the servers in your pool Inline means they will need the load balancer as their Gateway address. As inconvenient as this might sound vs. the “anything you can route to you can load balance” approach, there are definitely reasons why one might choose to go inline vs SNAT. The one major thing you lose with SNAT, or gain depending on your perspective, is the client’s source address. With an inline approach, you preserve the source address. Some applications and logging systems want to see the “real” source IP of a connection. When you use SNAT, that is replaced by one of the options you specify. One could also make the argument an Inline approach is slightly faster than a SNAT approach, but again.. that might start an argument 😉
How do I capture my source address with SNAT?
So now you’re SNATing, you feel cool, you look cool, and well… you are cool!
You’re load balancing anything you can route to, life is good and server admins are happy they didn’t have to jack around their servers and change their gateway. Until they look in their logs and are confused what happened to all the source address information! Fortunately, if you’re dealing with web-based traffic we can still provide this information to them, it’s just going to require a little bit of reconfiguration on their side as well as yours. Enter the XFF header option! The X-Forwarded-For header option when enabled will capture the source address of the client and append it in the header. The logging server would then need to be configured to grab this value instead of looking at the actual source address. I’d like to note a few gotchas / limitations here:
- Encrypted Web Traffic – If your web traffic is encrypted you’re going to need to terminate SSL at the BIG-IP. In other words you’re going to need to host the certificate / key and associate them in a client-side SSL profile with the virtual server(s) in question. This might seem like a pain at first, but trust me, it’s a GOOD thing. Managing your SSL certs/keys on the F5 will save you time, money, and a lot of headaches. You’ll even save precious CPU cycles on your servers if you choose not to re-encrypt on the server-side.
- Non-Web Traffic – If you’re not dealing with web traffic, your options are limited. The only way you will be able to log the client source address is to capture it from an iRule and log it locally at the BIG-IP device. Script away and you could even ship that info off automatically to the people or systems who need it.
What is a NAT?
NATs are a one-to-one mapping between addresses. Unlike SNATs and Virtual servers, NATs can be used for traffic initiated in both directions. You can Send Traffic to the NAT address or the Origin address can send traffic to any address, as long as that origin address passes through the BIG-IP of course 😉
NATs are not connection based like SNATs (i.e. they are not tracked by the BIG-IP). A NAT is made up of two major components:
- NAT address – The NATs address is the routable address on the external network of the BIG-IP system. It should not be the same address of the mgmt IP as well as the originating or translated IP address defined for a SNAT.
- Origin Address – You can think of this as the internal address. I know, I know.. confusing, because “origin” when talking SNAT is an external address or address list, but in this case you need to think of it differently. It’s important to note a Virtual Server can’t use this IP address.
Why Do I Need SNAT?
To put it simply, you need SNAT when using the BIG-IP because the F5 is a stateful Full Proxy. Traffic passing through it needs to return through it, otherwise the connection will break. I’ve put together this picture to depict a common inbound SNAT scenario, where the servers do NOT point to the BIG-IP as their GW, rather they point to a layer 3 device – router. Step 5a depicts the scenario where SNAT IS turned on at the VIP, and traffic is sent back to the F5 BIG-IP that is part of the directly connected subnet of the pool members.
Another common situation you should be mindful of when deciding if SNAT is needed or not is to consider if servers will ever need to source traffic to VIPs that have pool members on the same subnet as the servers originating communication.
If they do, then you definitely want to consider using SNAT, or using an iRule to SNAT traffic sourced by the servers. If you don’t use SNAT in that situation the return traffic from the servers will go directly back to the source host on the same subnet bypassing the F5 BIG-IP and breaking communication. Thank you Iyad for bringing up that situation in the comments – it’s an important one to consider!
Here’s a detailed description of the traffic path with NO SNAT enabled.
- The client with the source address of 10.10.100.75 makes a request to 10.10.10.50, a VIP that lives on the BIG-IP. Since it’s not directly connected to the client, it sends the traffic to its’ gateway – 10.10.100.1
- The router receives the traffic and forwards it out of the directly connected VIP 10.10.10.50
- The VIP receives the traffic, since NO SNAT is enabled, it does not change the source address of the communication, and forwards it to the respective pool member, lets pick 172.16.1.19. At this point the source of the communication is still the client, 10.10.100.75, destined for 172.16.1.19.
- This is the point where the communication starts to go bad, and breaky breaky begins. The pool member 172.16.1.19 receives the traffic, and since 10.10.100.75 isn’t directly connected, it sends the traffic out of its’ default gateway – 172.16.1.1.
- The router receives the traffic sourced from the pool member destined back to the client. The router sends the traffic out of its’ directly connected subnet and back to the client. The client is expecting the VIP of 10.10.10.50 to respond back, not the pool member. The client doesn’t recognize the connection and the communication breaks – this is known as asymmetric routing around a stateful device.
Do you see how this could have be fixed? You have two options:
- Change the gateways of the servers to the BIG-IP inside trusted subnet floating IP of 172.16.1.5, this will not only fix the asymmetric routing, but it preserves the real source IP of the communication. You can imagine this communication coming back down step 3 since they’re on the same subnet and directly connected.
- Turn SNAT on at the 10.10.10.50 VIP. If you used SNAT Automap, it would use the Floating IP to source communication to the pool members. You can see this alternative directly connected traffic path depicted in (5a) – this is known as symmetric routing through a stateful device.
ThePacketMan says
Thank you for the images and explanations! This has helped me quite a bit explain snat vs inline to co-workers. “What is snat? here read this” lol
Johan says
Great post – do I have to use snat with f5? It seems it’s not a requirement, but how does a VIP work without snat?
Maisha says
Hi Austin,
My setup is the same as you pictured here. My VIP is on VLAN 10 (10.10.10.10) and my Nodes are on VLAN 20 (10.10.20.3, 10.10.20.4). My issue is I have to intact/preserve my Client’s source IP (10.10.30.75) address while returning the traffic. I used SNAT (selfIP of VLAN20 or Automap) it worked but it is changing the source IP of the Client. Is it possible to do Half-NAT to achieve it? if yes, then what would be the solution?
Hurdy H. says
Very well explained – ty
Rudy says
Thank you, this answered all the questions I had after trying to sort through the F5 docs.
Casey Wallace says
Hi Akshay. Thanks for your question as it brings up an interesting scenario. A lot of it depends on the virtual server config. A Standard virtual server WITHOUT an HTTP profile will immediately respond with a RST if the pool members are down. However, if an HTTP profile is applied to the VS (which you likely had set), you will be able to establish a client side connection and a telnet test will establish a 3-way-handshake (3WHS). Standard virtual servers process connections using the full proxy architecture. The TCP 3WHS occurs on the client side of the connection before the F5 LTM system initiates the 3-way-handshake on the server side of the connection. More on this from F5 article: https://support.f5.com/csp/article/K8082. So telnet in this case is not an adequate full proxy test and the only way to test this would be to to send at least one HTTP request after the 3WHS and use tools like curl.
Zachery says
I constantly refer back to this article – thank you so much!
Akshay says
Hi,
I had a scenario where I created a Virtual Server and didn’t set SNAT to automap.
To test the Virtual Server I tried to telnet to port 80 on VIP and that was successful but when I tried reaching that IP from browser, it was unsuccessful.
Can you explain this behavior as why telnet to port 80 was working?
Jose Anda says
Thanks for sharing this great explanation!
iyad koussa says
Hi Austin,
this is a great clear and near perfect document about SNAT, i read alot about this subject but your document stands out with its sofisticated ans simple way of saying things.
One thing i would like to add may be ( i am not sure if anybody already mentioned it in the commnets as i didn’t read them all), it is a bout the case when a server belonging to the same LAN/VLAN of the load balanced servers, let’s say a 172.16.1.22/24 server which needs to talk to those load balanced in the 172.16.1.0/24 but via the assigned VIP (10.10.10.50), in this case the packets will go from this server to the vip then get loadbalanced to one of the servers (172.16.1.19. 20 or 21), let’s say the 172.16.1.19, now, whithout SNAT (automap) when this server wants to respond it will send the answer back directly to the source (172.16.1.22) turning around the bigip, and that will happen even if the .19 has the selfip 172.16.1.5 as its gateway (I would prefer to see a switch in your drwaing above connecting all the 172.16.1.0/24 machines, that will clear out what i am trying to say), the .22 server will then recive an answer packets from a source he never talked to (remeber that its ditanation was the 10.10.10.50) and it will not know what to do with these packets but ignoring them.
So as a conclusion: in cases (like artifactory and Remedy BMC applications) where servers in the same VLAN need to talk via the VIP, in these cases, evene if you have the loadbalanced servers in an in-line mode (their gateway is the selfip facing their VLAN/LAN) communication will break down if SNAT (automap) is not applied.
I hope that i could put my point as clear as your document, and again thanks for the good job you have made.
My best regards.
Austin Geraci says
Hi Iyad – thanks for your feedback, what you’re describing is definitely true! In short – Iyad is saying if a server on the same subnet as the pool members and communicates with a VIP that does not have snat enabled, communication will break because the server will see the true source and communicate directly back to the source host on the same subnet – instead of going back to the F5.
I depicted the example purposely with a unique host on a 10. subnet to avoid this, but the situation is important and worth an addition to the article – ty much!
Vineet says
Hello Austin,
Any suggestions on how to differentiate between application traffic and monitoring traffic when SNAT automap is being used ?
Austin Geraci says
Hi Vineet! Yes, Monitoring traffic will be sourced from the “Non floating”, ie “Local IP” addresses, and the auto SNATs will sourced from the floating IP addresses.
That’s because all Devices in a HA group need to know the status of nodes/pool members, in case of a failover – hence monitor traffic from all devices in a HA pair/group.
The SNAT traffic will source from the float in case of a fail over as well, so traffic continues through the active unit – as the floats “float” to the active unit.
Now if you don’t have any Floating IPs and just a local self IP you can see how you may run into an issue here. I recommend specifying a SNAT pool or a floating self IP to help you differentiate between monitor and application traffic. Good Luck!
Oguz says
Hi Austin,
Thank you for your clear and precise explanation.I have a question about the last part of article:
“2.Turn SNAT on at the 10.10.10.50 VIP. If you used SNAT Automap, it would use the Floating IP to source communication to the pool members. You can see this alternative traffic path depicted in (5a) – this is known as symmetric routing through a stateful device.”
I think that the alternative traffic path should be return path in (3), because ip’s of pool nodes and f5 floating self ip are in the same network (172.16.1.0/24 – layer2 routing -) that’s why the next hop should be directly f5 self ip, not default gw of pool nodes, right?
Austin Geraci says
Hi Oguz,
Good catch brother! It was written correctly but botched the pic! It’s updated now and I included some txt to make it a lil less ambiguous – thanks!
pradeep says
You save my life tonight! 🙂
proxy site says
Thanks for writing this awesome article. I’m a long time reader but I’ve never been compelled to leave a comment. I subscribed to your blog and shared this on my Twitter. Thanks again for a great post!
Piotr says
HI,
First of well great explanation! One think that bother me a bit is SNAT Self IP order of precedence. Easy part is choosing first floating then local Self IP on Egress VLAN – I assume Egress VLAN means VLAN to which either target host (node) is directly attached (same subnet as Self IP) or where router IP is located via which destination IP can be reached (for example based on static route configured on BIG-IP).
In what case other option will be used “IP addresses on different VLAN” – or what can cause usage of Self IP on different VLAN than Egress VLAN? I assume that even if this Self IP will be used traffic anyway will be send via Egress VLAN (one via which destination IP can be reached) but instead of having this VLAN IP some other IP will be used for source IP.
That seems to be quite problematic scenario.
Piotr
Beth says
Is there anyway to force the F5 to use one of the SNAT pool members? This way all traffic that to the member has the same parameters?
We are experiencing an issue where a software token generated through the F5 which uses SNAT is not being recognized by the software after being generated. It’s causing the software to through a redirect to login.
I think some the cause has something to do with the SNAT pool. If one IP from the pool is being used when the token is generated, and then another IP is used to connect with the token then the software would see a difference in the IP used to generate the token and then IP used to access with the token.
Austin Geraci says
Hi Beth! It sounds like you have a persistence issue. If it’s web traffic you could use cookie persistence, if not source address persistence might do the trick, but I would need to know more to be 100% sure. If your’e going to use something like cookie persistence that depends on seeing the actual traffic, don’t forget to terminate SSL on the virtual server – doesn’t matter for source address persistence. Please feel free to contact us for more help!
Jaques says
Hi Austin,
Thanks for the SNAT explanation!!!
Do you have more links where you describe features and functionality of F5 (LTM/GTM/ASM)
Jaques says
Hi Austin,
Great SNAT explanation, do you have some other links in which you described features and functions of LTM/GTM/ASM etc?
Thanks
Vincent says
Hi, Austin,
Great article — found it from Google. But I have a burning question that I can’t find on Google…
I can see the purpose of SNAT for proxying/load balancing protocols like FTP, telnet, etc., which needs to maintain a single TCP connection from client to server (passing through Big-IP).
Now, I am only concerned with proxying HTTP traffic for my web servers, so do I need SNAT at all for HTTP? I have used Apache, etc., as HTTP proxies, which acts like this: the browser makes an HTTP connection to (and the underlying TCP connection terminates at) Apache. The URL’s hostname is Apache’s hostname. Then Apache makes a new HTTP/TCP connection to the backend web server. That’s how the HTTP content is ultimately delivered from browser to the web server. So, we are talking about two separate TCP connections where Apache is in the middle. Apache doesn’t, and doesn’t need to, operate at the IP layer or manipulate IP headers (where SNAT is for.) Because two TCP connections are chained via Apache, SNAT is unnecessary and irrelevant.
If I want to use Big-IP to replace Apache as my HTTP proxy/load balancer, doesn’t Big-IP work in the same principle as Apache in this regard? If so, why care about SNAT? Or, am I misunderstanding the mechanism of how Big-IP achieves HTTP proxying?
JoeLB says
great explanation, Austin !
thanks a lot
Here are 2 extra comments/questions if this can help :
1) when creating a SNAT (which is used globally in the LTM as you explained) that refers to a SNAT Pool, you can define several Hosts IPs or even subnets to represent the original Source IP address and in the same way, you can define several IP in the referred SNAT Pool ;
let’s suppose you define 10 IP addresses in hte SNAT and 10 IP addresses in the associated SNAT Pool :
Will the SNAT be a 1-to-1 NAT, supposing those IPs are not referred in any other BigIP object ?
if not, is there a way to create a 1-to-1 SNAT configuration, i.e. what we generally call a static NAT as opposed to a dynamic NAT where we have a Many-to-1 NAT for example ?
2) Just to complete those NATs aspects on BigIP, it may be useful to mention that there is another form of NAT that takes place on the destination IP of the initial request received by the BigIP : i.e the Destination IP which is a VIP defined in a Virtual Server is translated to 1 of the Pool members real addresses associated to this VS ;
well, this is not described as a NAT function in standard F5 documentation,
but, in order to distinguish the SNAT described above from this other kind of address translation, it looks good to mention it, I think, even if, for most people, it is obvious 😉
David O says
If anyone likes, I have come up with a way to kill of SNAT Automap for linux nodes…and not by making the BigIP the default gateway…. Assuming your pool members are linux-based (BSD too? I dunno), using iproute2, iptables and layer2 you can set the bigip as a conditional gateway for your traffic and voila! Remote client-ip right down to your application. Of course http can always be handled via XFF, but even things like postfix, etc now log remote ips right there. I posted this write-up on DevCentral ::
devcentral.f5.com/codeshare/kill-snat-automap
and the link to the startup script is here:
github.com/dfosborne2/F5-BigIP/blob/master/bigip-gw
Austin Geraci says
Nice contribution David! This is crafty, and the script is nicely documented.
There are definitely ways to overcome some of the drawbacks, some rework of the script and you could add support for more than one address on each interface – but there’s some work there 😉
Like you faced, I can see pushback for existing server builds. Once a host is in production, a change is a change – and a default gateway change will definitely seem less risky to management vs adding a script for conditional routing & making interface changes etc.
I can see the requirement for the node to be on the same subnet as a selfip being a show stopper. One of the biggest advantages of SNAT is being able to load balancing anything you can route to. I can’t think of a good way to use this script and avoid the same subnet deal – maybe some type of chaining logic between some hosts, but that could get hairy!
I can make cases for why to use this and why not to use this, but it definitely has it’s use cases! Good Job!
AJ says
Hey Austin, great explaination here. Wayyy better than the F5 docs and dev centrall articles. One thing to query, if the LTM is deployed in HA, then automap will use the floating IP of the exit interface right? In the event for example the primary LTM failed and the secondary came online, then the self IP of the primary unit would be inaccessible and the secondary would not be configured but with a floating IP, there wouldn’t be an impact to live traffic, I think?
Austin Geraci says
Great question AJ! It merits an update to the article, see the “SNAT automap order of preference” section above for your answer in detail. You have the idea, we want the return traffic to follow the active unit / traffic group to not disturb traffic.
AJ says
No worries Austin! It was one that puzzled me. I do have a query regarding the source IP of health checks? I’m unsure of whether it is the IP of the VIP the nodes will see?
AJ says
Just in case someone else is/was wondering about the health check, I’ve figured it out and is like so:
In a HA solution, the health checks will be sourced from the self IP of the interface that the VLAN is in on both LTMs.
So say for example, the F5 topology is set up like below and I’ve set up a monitor for nodes within the 192.168.100/24 network:
Networks:
192.168.100.0/24
192.168.99.0/24
LTM 1 self IP’s:
192.168.100.1
192.168.99.1
LTM 2 self IP’s:
192.168.100.2
192.168.99.2
Pool Members
member1: 192.168.100.5
member 2: 192.168.99.10
So, the monitor request that will be sent to member 1 will have the source address of both 192.168.100.1 from ltm1 & 192.168.100.2 from ltm 2. The requests will be identical but from different sources, though the f5 is in HA each ltm will do determine the status of the node in the health check.
Austin Geraci says
You got it AJ! – The reason this works this way is because each LTM needs to know the status of the pool members independently, specifically in a case of a failover. To be even more clear, monitor traffic is sourced from LOCAL only self IPs, not floating IPs.
Albert says
Hi Austin,
You hit the nail on the spot ….. great explanation about SNAT. Yeah, I was too confused about SNAT in the beginning when I turned it in auto map using VS and later I understand. But your explanation here it makes more solid as a rock!
Tnx
Sam says
SNAT Pool is the other option to be discussed… Means assigning an IP or pool of IPs to deal with high number of requests. You really need to know the actual traffic flow…it might be the case the Auto Map doesn’t enough to deal with current sessions.
Larry says
This was a great explanation of SNAT. The F5 docs are terrible at simplified layman’s terms. Thank you.
Sudiro says
Thanks for your clear expkanation. By the way, in my company we implemented inline and SNAT together. Why? Because the gateway is not in LTM, but in Cisco Aggregate switch. Do you think this kind of configuration is okay? Should wr change gateway from aggregate switch to LTM? Kindly you csn give me suggestions,..thanks
Austin Geraci says
If the BIG-IP is not the GW of the pool members you’re referencing, then it is not in-line. You only create an inline configuration when the BIG-IP is the GW of the pool members. This works because SNAT is turned on. If this is right or wrong all depends on the requirements, does the application(s) in question have any of the in-line requirements I mentioned in the article?
Shikha says
You made life easy with SNAT..thank you..
Robert says
Thanks for the explanation.
However some drawings next to the explanations would make things even more clear.
Although I am not a native English speaker, Stateful is with 1 x f
Keep up the good work.
Austin Geraci says
Hi Robert, I appreciate your suggestion – I’ll take some time to add some drawings in the very near future, and “stateful” has been corrected! Please feel free to ask any questions for clarification on the topic.
Austin Geraci says
Hi Robert – We added a drawing with some traffic flow explanations – hope it helps!
ATX-Guy says
Hola! I’ve been following your site for a long time now and finally got the bravery to go ahead and give you a shout out from Austin Texas!
Just wanted to say keep up the good work!
Malcolm says
Austin,
Very good post, SNAT is really flexible and works well, making it source IP transparent can be done IF the load balancer is the default gateway, but then if the load balancer was the default gateway you could just use simple layer 4 NAT mode which is obviously faster. I notice you mention starting an argument about that… which you would have done 5 years ago… but I would have thought any modern processor could saturate a 1Gb pipe at either layer 7 (SNAT) or layer 4 (DNAT) easily….
I still love DR mode myself, but I probably need to update my blog to show that on modern hardware SNAT layer 7 is almost definitely the way to go for a flexible load balanced cluster.
Austin Geraci says
Thanks Malcolm – What I’m saying in reference to inline vs SNAT is with modern hardware the gains from an inline approach are marginal in terms of performance vs SNATing traffic to pool members that may be a few hops or switches away.
DR aka DSR aka N-PATH definitely had it’s day, but again, hardware performance has caught up.. These days you lose so much forgoing the full proxy architecture.
We’re not just load balancing anymore – we’re delivering applications securely, providing resilient communication, and context aware access. The true evolution of load balancing to application delivery 😉
helpmenat says
I finally can understand SNAT.. Thank you greatly, your SNAT-automap explanation was exactly the plain English I needed to finally get it.. Many thanks
Austin Geraci says
YW, stay tuned for more articles, and let me know if there are any subjects you guys would like me to cover next.
MikeS says
Thanx, makes sense
SammyJ says
Are you interested in doing any training sessions for our group on this subject?
JohnnyontheMax says
great post, I’ve been interested in NAT ever since we turned it on to get our first Virtual Server to get it to work lol, now I can see how we powerful it really is..
Oby H says
Thanks, this so much more clear now. I was not aware SNAT’s could effect traffic globally, this explains a lot lol..
Austin Geraci says
Oby, glad I could help.
help my LB says
Very good information, really helped me understand SNAT.
Sirel W says
This post is so help to me! Thanks for sharing, they way you explain is much clear than f5 website.