Listener 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
VS and NAT precedence
Hi, I was under impression that when there is NAT and VS defined (both matching incoming packet) then VS always wins. That is the case for SNAT - except when Source Address Translation is set to None on VS and matching SNAT object exists. But still for SNAT there is full control if SNAT should be used or not (even if SNAT is None on VS, we can set Allow SNAT No on Pool). Problem is that there seems to be no such control for NAT. Scenario: Network VS Forwarding (IP) type Source Address: 10.1.20.252/32 Destination Address/Mask: 192.168.104.0/24 Service Port: All Source Address Translation: None Enabled On: VLAN int NAT object Origin Address: 10.1.20.252 NAT Address: 10.128.11.51 Host sending traffic to 192.168.104.0/24 subnet Host IP: 10.1.20.252 - matching both NAT Origin Address and VS Source Address Def GW: BIG-IP Self IP on VLAN int Result: All traffic leaving BIG-IP on VLAN ext has src IP NATed to 10.128.11.51 (NAT Address). What's more, looking and NAT and VS stats it's obvious that traffic is processed by both VS and NAT (same packet count reported on both). Wonder if it is expected behavior? If so it seems that there is no way to prevent NATing src IP for such configuration - only way is to set NAT object to disabled - seems to be a little drastic solution. Piotr
VS and NAT precedence
Hi, I was under impression that when there is NAT and VS defined (both matching incoming packet) then VS always wins. That is the case for SNAT - except when Source Address Translation is set to None on VS and matching SNAT object exists. But still for SNAT there is full control if SNAT should be used or not (even if SNAT is None on VS, we can set Allow SNAT No on Pool). Problem is that there seems to be no such control for NAT. Scenario: Network VS Forwarding (IP) type Source Address: 10.1.20.252/32 Destination Address/Mask: 192.168.104.0/24 Service Port: All Source Address Translation: None Enabled On: VLAN int NAT object Origin Address: 10.1.20.252 NAT Address: 10.128.11.51 Host sending traffic to 192.168.104.0/24 subnet Host IP: 10.1.20.252 - matching both NAT Origin Address and VS Source Address Def GW: BIG-IP Self IP on VLAN int Result: All traffic leaving BIG-IP on VLAN ext has src IP NATed to 10.128.11.51 (NAT Address). What's more, looking and NAT and VS stats it's obvious that traffic is processed by both VS and NAT (same packet count reported on both). Wonder if it is expected behavior? If so it seems that there is no way to prevent NATing src IP for such configuration - only way is to set NAT object to disabled - seems to be a little drastic solution. Piotr
multiple valid persistence records?
Hi, Does anybody have any information on what basis for example for a single HTTP request, a matching source address persistence record and a matching universal persistence record get precedence over one another? Where is this decided or what factors influence this? Kind regards, Thomas