Forum Discussion

uni's avatar
uni
Icon for Altostratus rankAltostratus
Feb 09, 2012

Source IP decision in Performance HTTP virtual

Can I make a load-balancing decision based on the source IP address with a Performance HTTP or Performance Layer 4 virtual? As I see it, the decision is made as soon as the client SYN is received, which is before the CLIENT_ACCEPTED fires.

 

6 Replies

  • 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
  • uni's avatar
    uni
    Icon for Altostratus rankAltostratus
    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
    
  • uni's avatar
    uni
    Icon for Altostratus rankAltostratus
    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.
  • uni's avatar
    uni
    Icon for Altostratus rankAltostratus
    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.