Forum Discussion

Ken_Meade_51669's avatar
Ken_Meade_51669
Icon for Nimbostratus rankNimbostratus
Mar 16, 2009

Virtual Server responds to TCP request

Hi there,

 

Hopefully a simple issue with a simple explanation.

 

I have configured a VS using a Pool with two members.

 

 

I have turned down the two members, thus marking the pool down and the Virtual Server down.

 

 

However when I telnet to the IP/port combination of the virtual server I am getting a connection (not to any pool-member) but to the VS, so from a monitoring perspective I see this as active (without getting into application checks etc).

 

 

Any ideas what this might be?

 

 

so e.g.

 

 

Pool 192.168.1.254:7255

 

member1 10.10.10.1:7255

 

member2 10.10.10.2:7255

 

 

turn down the service on both 10.10.10.1 and 10.10.10.2 the Pool is correctly marked down and so is the virtual server.

 

 

When i telnet to 192.168.1.254:7255, in a DOS prompt I get the blank screen light it has connected rather then the connection refused or timing out...?

 

 

Thanks for your repsonses.

 

Ken
management
monitoring
  • Ken_Meade_51669's avatar
    Ken_Meade_51669
    Icon for Nimbostratus rankNimbostratus
    Mar 16, 2009
    well i've applied this iRule and the Virtual Server still performs the 3-way handshake (but obviously does not forward me to any pool members).

     

    This is causing a problem as one of our customers base their own failover on a simple tcp connect to the Virtual server...any ideas?

     

    tks

     

    Ken
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Mar 16, 2009
    They'll need to perform an application layer check to see if a virtual server is up or down. Here is a recent post with details (Click here).

     

     

    Aaron
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Mar 23, 2009
    There's a little bit more to add to this discussion - what you're dealing with here is a standard virtual server type. Because of this you're seeing the LTM full proxy in its full glory. On a standard VS, BigIP will always respond with a handshake on the client side. Only when you push data will you get a reset - that's because the LTM is now trying to send data to the server side of the proxy and there's nothing listening behind it.

     

     

    One way to accomplish what you're after iis to take advantage of what we know of the BigIP profiles: the fastl4 profile is 'packet based', and it'll attempt to send packets on to the backend immediately; therefore it'll throw your reset immediately. In other words, a performance l4 profile essentially disables the LTM's full proxy for that specific virtual server.

     

     

    Now, you may not find this desirable - after all, when you go with a packet-based VS you're sacrificing a ton of functionality. If this is the case, you could always stand up a parallel VS on a different port and have your customer hit that VS as their failover test.

     

     

    I hope this makes sense, and more importantly I hope it helps.

     

    -Matt