Selective SNAT rule

Okay, here's what I've got:

virtual test_snat {
   destination 192.0.2.10:smtp
   ip protocol tcp
   profile fastL4
   pool test_snat
   rule disable_snat
}
pool test_snat {
   monitor all tcp
   member 172.19.10.11:smtp
   member 192.0.2.25:smtp
}

1. snat is enabled on the VIP and on the pool.

2. I'm using no persistence.

3. What's the difference between a backend server and a backend node?

4. I'll try this.

5. The reselect is necessary if it is required to disable snat for only certain nodes in a pool.

Just to reiterate, I have a remote 'dummy' VIP set up on a remote BIGIP which is load balanced among three servers that are local to that remote BIGIP. I only need snat to occur on the 192.0.2.25 node, as it's in a remote location, on a different IP subnet.

Two things I notice...

 

 

1) I would suggest defining the default SNAT for the VIP. (We'll disable snat in the rule - The overhead is minimal).

 

Add one of the following to your virtual definition:

 

- snatpool snat_pool (Let me know if you want to be implicit)

 

- snat automap (I use this all the time, works like a charm. You need to make sure you have configured an automap IP. Let me know if you need help with this.)

 

2) I've had difficulty using the fastL4 profile with iRules... Are you sure this is supported? I would suggest getting rid of this profile.

 

 

As for your questions:

 

3) No difference

 

5) Why is the reselect neccesary? I am confused...

 

 

Thanks,

 

Brian

Oh yeah one more question... What do you mean by "dummy" VIP?

OK, I suppose I wasn't clear in my previous posts...sorry!

 

 

I have two sites:

 

 

SiteA Network: 192.0.2.0/28

 

SiteA VIP: 192.0.2.10

 

SiteA "Dummy" VIP: 192.0.2.11

 

SiteA Internal Nodes: 172.16.10.0/24

 

 

SiteB Network: 192.0.2.16/28

 

SiteB VIP: 192.0.2.24

 

SiteB "Dummy" VIP: 192.0.2.25

 

SiteB Internal Nodes: 172.19.10.0/24

 

 

We're load balancing SMTP between 6 physical servers at two geographically dispersed locations (3 at each site). Primary MX is 192.0.2.10 and secondary MX is 192.0.2.24. Because little traffic should actually go to the backup during normal operation, we want to use these servers in the primary MX pool so we don't have these boxes sitting around twiddling their thumbs, so to speak. These are obviously just example IPs and networks, BTW...

 

 

SiteA has two VIPs configured, as does SiteB. SiteA is the primary MX and SiteB is the backup MX. SiteA is load-balanced to a pool configured with three local servers (172.16.10.11, .12, and .13) and one remote server (192.0.2.25). The second VIP, what I call a "dummy" VIP, is configured with only the three local servers. SiteB is configured similarly.

 

 

The dummy VIP exists as an loop-prevention mechanism. It exists because if I use the secondary MX as a node in my primary MX VIP, the possibility exists that the backup MX will choose the primary MX node upon receipt of a TCP session. To avoid this, we made a fourth node (the dummy VIP) which consists solely of the three remote servers at each location.

 

 

We cannot use SNAT on the sessions which are load-balanced to the servers local to each BIGIP - the sessions appear to come from the BIGIP and the servers start denying connections because there's too many from a single address. This could be changed in the server configs, but there's side-effects to that which I won't go into.

 

 

We need to use SNAT for the sessions which are load-balanced to the *remote* nodes, because if we don't, the original IP is sent in the packet, so the remote dummy VIP attempts to send the ACKs to the original IP - which obviously doesn't work because no pre-existing TCP session exists with the remote dummy VIP.

 

 

I'm sorry for the long explanation - I hope this clears things up at least a little.

5) He needs to do a reselect because at the time LB_SELECTED is evaluated, the LB parameters have been locked down. Just doing "snat none" will have no effect because it's already been chosen based on the settings before LB_SELECTED was triggered. Doing an LB::reselect indicates that LB needs to be redone with new parameters. One of the things that happens in LB, is that the pool parameters is replaced with a pool member parameter. So, as long as the pool or pool member are not LB::reselected, the existing pool member chosen in the first place will still be used.

 

 

At some point, I'll try to verify that all this is in fact working as advertised. It's probably the first time someone has tried to tweak the snat based on which pool member was selected.

 

This has probably been asked before, but is there a flowchart available for the different events and at what point in the traffic flow they occur at? I attempted to search for this, but didn't find anything, probably because I was using the wrong terminology.

 

 

Also - if I log in an iRule, where does that information go? I don't see it logged anywhere in the /var/log directory or in the logs that the WebUI shows. The documentation states it logs it to the Syslog facility, but which one and which file?

it will go to /var/log/tmm unless otherwise specified.

Posted By citizen_elah on 10/13/2005 10:08 AM

 

 

it will go to /var/log/tmm unless otherwise specified.

 

Hmm...then something isn't right. With the log settings above, I don't see anything pop up in the tmm file. I'm not specifying another facility, so I would assume that would just dump into that tmm log.

sorry, I meant /var/log/ltm

Why don't you just set your two MX records that point to the two VIPs to equal weight?

 

 

Event order post:

 

Click here http://devcentral.f5.com/Default.aspx?tabid=28&forumid=5&postid=3020&view=topic

 

 

Thanks,

 

-Brian