Source IP decision in Performance HTTP virtual

As I see it, the decision is made as soon as the client SYN is received, which is before the CLIENT_ACCEPTED fires.i do not think so. i understand CLIENT_ACCEPTED event is still fired event using fastL4 profile.

 

 

In effect, when an entry is inserted in the BIG-IP connection table, this event fires.CLIENT_ACCEPTED wiki

 

http://devcentral.f5.com/wiki/iRules.CLIENT_ACCEPTED.ashx

Possibly, but http://support.f5.com/kb/en-us/solutions/public/8000/000/sol8082.html?sr=19200790l4 states that

 

the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM makes the load balancing decision and passes the SYN request to the pool member.

 

So, at the point the load-balancing decision is made, there is no established connection so I guess it comes down to when an entry is inserted in the connection table - after the first SYN, after the SYN/ACK, or after the full handshake.

i do not have pva platform. this is my virtual edition.

[root@ve1023:Active] config  b virtual bar list
virtual bar {
   snat automap
   destination 172.28.19.79:80
   ip protocol 6
   rules myrule
   profiles fastL4 {}
}
[root@ve1023:Active] config  b pool foo1 list
pool foo1 {
   members 200.200.200.101:80 {}
}
[root@ve1023:Active] config  b pool foo2 list
pool foo2 {
   members 200.200.200.102:80 {}
}
[root@ve1023:Active] config  b rule myrule list
rule myrule {
   when CLIENT_ACCEPTED {
        set vs "[IP::local_addr]:[TCP::local_port]"

        if {[IP::addr [IP::client_addr] equals 192.168.206.0/24]}{
                pool foo1
        } else {
                pool foo2
        }
}

when SERVER_CONNECTED {
        log local0. "[IP::client_addr]:[TCP::client_port] -> $vs -> [IP::remote_addr]:[TCP::remote_port]"
}
}

[root@ve1023:Active] config  tcpdump -nni 0.0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes
21:27:09.259100 IP 192.168.206.154.62935 > 172.28.19.79.80: S 2531232491:2531232491(0) win 8192 
21:27:09.261195 IP 200.200.200.10.62935 > 200.200.200.101.80: S 2531232491:2531232491(0) win 8192 
21:27:09.262185 IP 200.200.200.101.80 > 200.200.200.10.62935: S 1534523877:1534523877(0) ack 2531232492 win 5840 
21:27:09.262191 IP 172.28.19.79.80 > 192.168.206.154.62935: S 1534523877:1534523877(0) ack 2531232492 win 5840 
21:27:09.263231 IP 192.168.206.154.62935 > 172.28.19.79.80: . ack 1 win 16695
21:27:09.263243 IP 200.200.200.10.62935 > 200.200.200.101.80: . ack 1 win 16695

[root@ve1023:Active] config  cat /var/log/ltm
Feb  8 21:27:01 local/tmm notice tmm[4369]: 013e0001:5: Tcpdump starting bcast on :::0 from 127.1.1.1:35578
Feb  8 21:27:09 local/tmm info tmm[4369]: Rule myrule : 192.168.206.154:62935 -> 172.28.19.79:80 -> 200.200.200.101:80
Feb  8 21:27:11 local/tmm notice tmm[4369]: 013e0002:5: Tcpdump stopping on 127.1.1.2:3933 from 127.1.1.1:35578

[root@ve1023:Active] config  tcpdump -nni 0.0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes
21:28:16.841317 IP 172.28.19.253.48900 > 172.28.19.79.80: S 3025425990:3025425990(0) win 5840 
21:28:16.841447 IP 200.200.200.10.48900 > 200.200.200.102.80: S 3025425990:3025425990(0) win 5840 
21:28:16.844314 IP 200.200.200.102.80 > 200.200.200.10.48900: S 2189717286:2189717286(0) ack 3025425991 win 5792 
21:28:16.844324 IP 172.28.19.79.80 > 172.28.19.253.48900: S 2189717286:2189717286(0) ack 3025425991 win 5792 
21:28:16.847261 IP 172.28.19.253.48900 > 172.28.19.79.80: . ack 1 win 46 
21:28:16.847271 IP 200.200.200.10.48900 > 200.200.200.102.80: . ack 1 win 46 

[root@ve1023:Active] config  cat /var/log/ltm
Feb  8 21:28:13 local/tmm notice tmm[4369]: 013e0001:5: Tcpdump starting bcast on :::0 from 127.1.1.1:52391
Feb  8 21:28:16 local/tmm info tmm[4369]: Rule myrule : 172.28.19.253:48900 -> 172.28.19.79:80 -> 200.200.200.102:80
Feb  8 21:28:19 local/tmm notice tmm[4369]: 013e0002:5: Tcpdump stopping on 127.1.1.2:3935 from 127.1.1.1:52391

Thanks for that. Obviously the connection table entry is added after the first SYN, which makes sense (in hindsight). The CLIENT_ACCEPTED event then fires. I had incorrectly assumed that CLIENT_ACCEPTED was triggered after the client-side connection was fully established.

 

you are welcome.

 

 

actually, what you thought is interesting. CLIENT_ACCEPTED event definition might not be fully complete anyway.

 

 

hope someone here gives us sight.

Good point. If you look at http://devcentral.f5.com/wiki/iRules.CLIENT_ACCEPTED.ashx, it says:

 

when an entry is inserted in the BIG-IP connection table, this event fires. For TCP connections, this happens when the three-way handshake successfully completes

 

This obviously contradicts your finding, nitass. I assume that explanation applies to standard profiles, not to FastL4.