Forum Discussion

Vikky_193911's avatar
Vikky_193911
Icon for Altostratus rankAltostratus
Mar 20, 2019

SNAT vs Inline in high performance scenario

We are thinking about moving from SNAT to Inline Source Address Translation (we can control default gateway of the pool nodes either way) due port exhaustion and "general" feeling that this is much faster way to terminate HTTP/HTTPS VPS.

 

Port exhaustion was addressed with adding more IPs to the SNAT Pool list, but expanding it with more and more IPs is just not a elegant solution.

 

Peak traffic is around 200K/s of small http/https requests. Thus we are wondering about should we go with inline or not? Removing one iRule (x-forward) would be enough for small speed improvements, but what are others?

 

TIA!

 

application delivery
BIG-IP
inline
ip address exhaustion
LTM
snat

2 Replies

Sort By
  • Vijay_E's avatar
    Vijay_E
    Icon for Cirrus rankCirrus
    Mar 21, 2019

    I think there are profile values that can insert XFF header instead of iRule. Depending on your network design, you can have selective SNAT, where SNAT can be enabled for specific client IP addresses and not for all.

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Mar 22, 2019

    Hi Vikky,

     

    I'm supporting LTMs for an Affiliate Ressource provider with pretty much comparable RPS.

     

    It makes absolutely sense for me to inline those rather agressive workloads. In generall the prefered choice should be allways to inline LTM if possible, and only use SNAT if inline is (for whatever silly reason) not possible. By doing so you will remove the max-connection hard limits of an SNAT pool completely...

     

    Note: I'm even wondering how large your SNAT pool must currently be to support 200k/s connections? Did you reserved an entire Class-B subnet for SNAT? ;-)

     

    Removing one iRule (x-forward) would be enough for small speed improvements, but what are others?

     

    Try to avoid iRules if possible for those heavy workloads. LTM policies are executed much faster.

     

    If SSL-offloading is involved you may check your Cipher-Strings and prefer those stuff which is supported by your Cavium SSL-Offload Cards. Switching to Eliptic-Curve may also save lots of cycles...

     

    Also optimize your TCP profiles, to get rid of idle connections much faster. We have noticed, that lots of long living connection hurts the system more than having frequent new connections setups.

     

    Cheers, Kai