vserver ALWAYS replies to ping

Hi Alfonso,

Take a look at this related post (Click here). The gist is that you cannot disable ICMP for an IP address because you could have multiple virtual servers defined on the same virtual address. For a TCP virtual server, you cannot even prevent a three way handshake based on the virtual server's pool state. You can configure LTM to reset an existing TCP handshake if the pool is down using an iRule like this:

 
 when CLIENT_ACCEPTED { 
  
     Send a reset if the default pool doesn't have any active members 
    if { [active_members [LB::server pool]] == 0 } { 
       log local0. "No nodes available for [LB::server pool].\ 
          Resetting client connection: [IP::client_addr][TCP::client_port] -> [IP::local_addr]:[TCP::local_port]" 
       reject 
    } 
 } 
 

Aaron

Thank you! This clears it up pretty well.

 

 

One follow up though. How does the GTM monitor the active or inactive state of a VS in order to resolve one VIP or another? Given the facts mentioned on the other thread. I assume that it would not make sense if it relied on simple icmp or a TCP connection to the VIP, right?

 

 

Alfonso

Each LTM should monitor its pool members using an application-specific monitor, then the status of the virtual servers is communicated to GTM via iQuery.

 

A non-LTM virtual server would need to be monitored by an application-specific monitor on the GTM.

can anyone verify the iRule resets/drops the connection?

 

 

I've set this up, but with a tcpdump, I still see the SYN,SYN-ACK,ACK handshake and the connection does not get cleared?

 

 

if I then enter anything the connection is dropped.

 

 

Is this iRule different then configuring the pool to drop/reset the connection via the drop-down box?

 

 

tks,

 

Ken

On 9.3.1 it works fine. I used netcat to open a TCP connection without sending any data.

 

 

client.4704 > vip.http: S 2054786817:2054786817(0) win 64240

 

vip.http > client.4704: S 666623169:666623169(0) ack 2054786818 win 3711 (DF)

 

client.4704 > vip.http: . ack 1 win 64240

 

vip.http > client.4704: R 1:1(0) ack 1 win 3711 (DF)

 

 

Aaron

Deb says iQuery should be used to monitor an LTM's VS from a GTM, and I've read that in a few other places too. Unfortunately we set up our GTM's to use application specific health monitors, the generic HTTPS and ICMP monitors that come with GTM. I'm having trouble understanding whether its "required", "highly recommended", or just "optional" to use iQuery from GTM to LTM. Our LTM's have hundreds of VS's, but I only need to monitor one of them from GTM, so I thought it was overkill to import the status of the many for the needs of the one. Is there a short list of the bad things that can happen if I'm not using iQuery from GTM to LTM?

I think it's more efficient to use iQuery if you're using GTM to load balance many VIPs so you don't have LTM polling the pool members and GTM polling the VIP. If you only have one LTM VIP you want to check status for, a single GTM monitor should be fine.

 

 

Anyone else have thoughts on this?

 

 

Aaron

I also prefer to use iQuery to monitor from GTM->LTM, but you should take into consideration your architecture. Something like iquery probably wouldn't get messed with in firewall rules, but 80/443 rules do quite often...having a poll on the real service provides an additional feel good that firewall rules aren't getting mangled, or other potential problems. If GTM/LTM sit in the same DMZ layer and would traverse nothing, additional polls wouldn't make much sense.

The problem we have with the HTTPS and ICMP monitors today is that a couple times a day they fail even though the VIP hasn't gone down. Would iQuery be more "reliable" in the sense of producing fewer false positives?

Hi,

 

 

Any of you know if there is any other way to implement that VS don't repond to TCP / ICMP connection when the pool don't have active memebers ?

 

 

For me the tcping / telnet all works , even if the pools is marked down

 

 

Highly appreciate your help

 

 

thanks

 

Sojan