SNAT vs Auto-map

 

A little more control... (e.g. seggregation of traffic by srcip).

 

More connections... (Important for lots of short lived connections where you may run out due to the 2xMSL TIME_WAIT status, or just for really busy LTM's)

 

 

H

Makes logging easier as well. If you have a different SNAT Pool per VS, you'll know where requests came from.

With 10.x tcpdump, you can also see the virtual server name in the packets. This line shows a SNAT to pool member SYN which was via the http_10.1.0.15_vs virtual server:

 

 

14:05:19.472966 IP 10.1.0.11.50954 > 10.1.0.100.http: S 3232923316:3232923316(0) win 4380 out slot1/tmm0 lis=http_10.1.0.15_v

 

 

A VS specific SNAT pool is still useful, but figured I'd throw this out there too.

 

 

Aaron

Posted By hoolio on 02/11/2011 02:11 PM

 

With 10.x tcpdump, you can also see the virtual server name in the packets. This line shows a SNAT to pool member SYN which was via the http_10.1.0.15_vs virtual server:

 

 

14:05:19.472966 IP 10.1.0.11.50954 > 10.1.0.100.http: S 3232923316:3232923316(0) win 4380 out slot1/tmm0 lis=http_10.1.0.15_v

 

 

A VS specific SNAT pool is still useful, but figured I'd throw this out there too.

 

 

Aaron

 

Was referring more to firewalls, Netflow, etc...boxes that only care about IP/Port. Still, very cool reminder. I noticed that once and didn't think anything of it. Didn't even consider the application at the time.

To me, the biggies are (in favor of specific SNAT vs. Automap):

 

 

1) You can be much more flexible regarding ephemeral port exhaustion.

 

2) It helps reduce confusion when you're troubleshooting.

 

3) You can tune the timeout values on a snat pool, unlike automap.

 

 

Also, CMP can complicate the ephemeral port exhaustion issues, and some folks out there consider it to be best practice to setup a 1:1 mapping between the Virtual Server and a dedicated SNAT pool.

 

 

-Matt