ICMP/TCP Deny on Pool Down

My VIPs send RSTs when pool members are down...is that not the behavior you have?

Hey Chris,

 

 

This isn't necessarily the default behavior depending on the virtual server configuration. to my knowledge, the VS will *always* respond to ICMP - though there have been RFEs for this in the past. A vanilla virtual server should send a RST if no pool is available but a virtual server has an HTTP profile (or perhaps it depends on iRules attached to it - I can't recall for certain) it will establish the 3-way handshake before tearing down the connection.

 

 

As to the original question - I don't know if there has ever been any movement on the RFEs to change this behavior. It is probably worth reaching out to F5 Support and asking for the status and/or to have your request appended to the list.

 

 

// Ben

 

And that is part of the problem, we dont want it to make the 3-way or respond to icmp as this is what the site selector polls to see the availability of the service. Thanks anyway guys, i'll see what support have to say.

Hi Steve,

 

There might be a way. You can disable ICMP by issueing the following command "b virtual address arp disable." It should stop ICMP. The method you could use is an external script that would check health check the pool members for status. If DOWN it not only stops traffic to the DOWN members, but also issues a shell "B" command to disable the arp. Also re-enables the arp with the status is UP.

 

 

I hope this helps

 

Bhattman

 

I encountered this as well when I worked with the GSS. My solution was to make the health monitor on GSS TCP only and use an irule to check for active members in the pool, if none, discard requests from ONLY the GSS source IPs. This worked just fine in my environment.

 

 

BTW, for the GSS the discard is important, because ANY TCP response, even a RST, is considered "good".

We are in the same boat, migrated from Cisco the F5. We have GTM's but are still using the GSS's currently with local services on LTM's. I tried both of these irules and the 3 way handshake seems to complete still, so my GSS doesnt mark them down. The connection is dropped right away after the handshake, but its too little too late for the GSS. Any ideas? My pool members are down (failed) not suspended. no persistence profile on this test vip. 10.2 code.

 

 

when CLIENT_ACCEPTED {

 

if { [active_members POOL-PURISMA_UAT2] == 0} {

 

discard }

 

}

 

 

also tried

 

 

when CLIENT_ACCEPTED {

 

if { [active_members [LB::server pool]] == 0 } {

 

discard }

 

}

 

 

any ideas?

Hi Steve,

 

 

Have you set up TCP only monitor on the GSS as Jason described?

 

 

I encountered this as well when I worked with the GSS. My solution was to make the health monitor on GSS TCP only and use an irule to check for active members in the pool, if none, discard requests from ONLY the GSS source IPs. This worked just fine in my environment.

 

 

Aaron

 

yep I have done that on my GSS, tcp probing answers configured as VIPs on the ports the VIP is listening on at the F5, in this case port 80. The thing I don't understand is the event here is CLIENT_ACCEPTED, doesn't that imply the F5 has to complete the 3 way handshake before the irule is evaluated? I do see when I telnet to the vip with the irules I mentioned above the connection is dropped right away, but that is after the initial handshake completes thus it's too late for the GSS to know better, it has already considered the keepalive passing. I have also tried reset and graceful on the GSS termination method, no dice.

I'm not familiar enough with GSS to help much. From what Jason said you should be able to use discard to avoid ACKing any packets after the three way handshake. If the GSS is configured to expect a packet after the three way handshake then the iRule seems like it should do the job.

 

 

Aaron