Forum Discussion
Ed_Summers
Nimbostratus
NimbostratusListener order-of-precedence and SOL9038
I find myself confused on the wording of SOL9038 and appreciate any information that can clarify acutal LTM operation with respect to traffic that matches both a source and destination listener.
The last line of SOL9038 states: "For example, a virtual server with a destination address and a netmask of 0.0.0.0/0:0 takes precedence over a source listener object." I understood this to mean that should traffic match both a source and destination listener, the destination listener would assume full control over the traffic and that the source listener would not take effect. My local SE seemed to be in agreement that, given a wildcard virtual of 0.0.0.0/0:*, traffic would never trigger a SNAT on the device.
However I noted different operation in one of our production units. Home testing on LTM VE appears to show that the SNAT will take effect if the destination listener is not configured to SNAT traffic.
So now I am reforming my understanding of SOL9038 to match what I've seen but want to confirm this is correct operation. The OOP allows both source and destination listeners to operate on the same traffic, but should a conflict arise the destination listener settings will take effect. More simply - source and destination listeners are NOT mutually exclusive?
I can post information on testing conducted and results, but after reviewing the results and thinking it through the answer to my question my be as simple as the above.
Thanks for any assistance! -Ed
nitassEmployee
Home testing on LTM VE appears to show that the SNAT will take effect if the destination listener is not configured to SNAT traffic.
yes, that is correct.
Ed_SummersThank you nitass. I also confirmed separately with user 'What Lies Beneath'. I guess my original understanding was formed based on first reading the OOP for destination listeners, which would be mutually-exclusive; i.e. The system can only match and execute one destination listener.
Progressing from this I assumed the same for source vs. destination listeners, but after testing and multiple outside confirmations I now see where my understanding was incorrect. I would offer that the SOL language should state "When a connection matches both a source and a destination listener object, the BIG-IP LTM system places a higher precedence on the destination listener parameters" or something similar, rather than the term "object". To me that implies an all-or-nothing config.
Again - appreciate your support!
dragonflymrCirrostratus
Hi, To be honest I am still a bit confused what exactly is going on with precedence here. Let's take your example: 1. Destination listener 0.0.0.0/0:* created by PerformanceL4 VS with SNAT Pool set to None, pool member 10.10.20.1 2. Source listener created by SNAT object let's say origin 192.168.1.1, translation 10.10.20.10 Packets received (assuming Address Translation enabled in VS): 1. S: 192.168.1.2 D:10.10.10.1 - on egress S: 192.168.1.2 D:10.10.20.1 2. S: 192.168.1.1 D:10.10.10.1 - on egress S: 10.10.20.10 D:10.10.20.1 - SNAT source listener working Can't see any precedence to be evaluated in above Now let's have another scenario: 1. Destination listener 0.0.0.0/0:* created by PerformanceL4 VS with SNAT Pool set to Auto Map (selfIP 10.10.20.100), pool member 10.10.20.1 2. Source listener created by SNAT object let's say origin 192.168.1.1, translation 10.10.20.10 3. Source listener created for 0.0.0.0/0 by VS? Packets received (assuming Address Translation enabled in VS): 1. S: 192.168.1.2 D:10.10.10.1 - on egress S: 10.10.20.100 D:10.10.20.1 - Auto Map enganged 2. S: 192.168.1.1 D:10.10.10.1 - on egress S: 10.10.20.100 D:10.10.20.1 - SNAT source listener for SNAT object ignored, used Auto Map listener from VS Here I can see precedence - so even if source IP matches SNAT object origin still Auto Map is used. Or Maybe I am completely lost here? By the way, what is a point for disabling Address Translation for VS that is using pool? I assume that VS will only work if VIP and pool member IPs are in the same network. In other case when dest IP will not be translated packet will not reach pool member. What could be a real life scenario to use VS with disabled Address Translation? Piotr- dragonflymrI was thinking about this after writing above reply. Seems that it is more or less babble :-(. I think SOL is right using term "source listener object". SNAT is object. It can process packets on it's own. Mentioned sentence can be translated to such situation: 1. There is SNAT defined with some origin IP 2. There is VS defined with whatever broad VIP definition - like any network/any port If there is packet with destination IP matching VIP and source IP matching SNAT origin it will be always processed by VS object not by SNAT object. Separate issue is how it will be processed by VS object when VS has not SNAT enabled. In case of D_IP and S_IP match and no SNAT defined in VS object SNAT will work for VS no on its own. I mean packet will be processed by VS in regards to D_IP translation but SNAT object will perform S_IP translation for VS. Other level of precedence here is SNAT definition in VS and SNAT object. When VS has no SNAT config SNAT object will provide SIP translation. If VS object has SNAT configured, VS setting will always override SNAT object. I mean that S_IP will be translated according to SNAT config in VS not according to SNAT object config. Example: VS defined without any SNAT, SNAT defined with IP A When packet matching both VIP and IP A will be received S_IP will be change to translate IP defined in SNAT object. However for the same packet with for example Auto Map set in VS, S_IP will be translated to selfIP of the network where pool members are located. So we have precedence related to SNAT object and SNAT config in VS here - quite other story than precedence for VS object and SNAT object. Hope it makes sense, especially that I am not native English speaker and novice in are of LTM. Piotr
kash_49328great answer
- Brandon