disable arp not working

Hi Kirit,

I believe that it is by function that the VIP will respond even though the backend is not available - Performance L4 simply changes that due the nature of the setting. We had the same issue for an app that was simply checking the port of the VIP rather then checking the content so I put the following in place while we fixed the app to do content checking

  
  when HTTP_REQUEST {  
    if { [active_members pool_http_servers] == 0 } {  
      reject  
    }  
  }  
  

or

  
  when CLIENT_ACCEPTED {  
    if { [active_members pool_http_servers] == 0 } {  
      reject  
    }  
  }  
  

The reject statement sends out a TCP reset

I hope this helps

Bhattman

Yep, you are exactly right. With a standard virtual server, the LTM is in 'full proxy' mode, so you'll get a successful 3-way handshake. The full proxy allows BigIP to do all of its magic, and this particular scenario is an artifact of the architecture. After all, there are perfectly valid reasons to have a virtual server with nothing behind it but you still want it to handle traffic - e.g. a port 80->443 redirection.

 

 

One thing to note when you're doing this type of telnet testing is that as soon as you try and PSH data to the LTM it'll send a RST just like Bhattman's rule does above. His version catches this scenario earlier, and the LTM will RST on the first SYN from the client (I believe - haven't tested with tcpdump to verify this).

 

 

All this being said, it would definitely be nice to have a check-box way to fully disable (at L2) a virtual server when all of the members are down...

 

 

-Matt

I applied the rule to my virtual server and it did not work. meaning I am still able to telnet to the vip

 

 

 

I also have to mention http profile in virtual server otherwise I get the following message

 

 

01070394:3: HTTP_REQUEST event in rule (mhe_check_members) requires an associated HTTP or FASTHTTP profile on the virtual server (test_pool-4.2.4.4-80).

 

 

 

my irule is as follows

 

 

 

when HTTP_REQUEST {

 

if { [active_members test_pool-4.2.4.4-80] == 0 } {

 

reject

 

}

 

}

CLIENT_ACCEPTED did not work either

Hi Kirit,

 

 

See this post for details:

 

 

vserver ALWAYS replies to ping

 

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=32&tpage=1&view=topic&postid=5593055932

 

 

As long as you have a TCP profile added to a VIP, LTM will still answer a TCP handshake before the CLIENT_ACCEPT event is triggered and the connection is reset. So telnet or any other type of request will show a connection which is immediately closed by LTM with a reset:

 

 

07:03:32.263791 802.1Q vlan4094 P0 client.4235 > vip.http: S 1533083566:1533083566(0) win 64240

 

07:03:32.263808 802.1Q vlan4094 P0 vip.http > client.4235: S 4202135950:4202135950(0) ack 1533083567 win 3711 (DF)

 

07:03:32.292668 802.1Q vlan4094 P0 client.4235 > vip.http: . ack 1 win 64240

 

07:03:32.292718 802.1Q vlan4094 P0 vip.http > client.4235: R 1:1(0) ack 1 win 3711 (DF)

 

 

Aaron