Respond to server depending on TCP::client_port

Oh, and I forgot to mention, this is all within the SERVER_DATA area that I'm thinking this needs to happen, so my concern is that TCP::client_port wouldn't be a valid check.

 

 

-eaw

If the client just disappears without closing the client side connection, then the connection table entry would still exist and TCP::client_port would still return the client's source port.

 

 

Could you send the watchdog request through to the client to see if it's still there? If there isn't a response from the client then the server would know the client is gone.

 

 

Aaron

True, but here's the f-ed up part of that. Which watchdog gets passed through? Because of how this is being built from a Diameter perspective, we need to separate the client and server sides to a degree.

 

 

Here's the background info you weren't privy to before, but I should have included for full disclosure on what I'm doing:

 

 

When the client hits the VIP, it will send a CER (AVP 257). The iRule will send this same CER to all members of the pool. Each of them that can will respond with a CEA (AVP 257 again). Upon receipt of the first CEA, the LTM will send it's own CEA back to the client, making a couple modifications to things like the destination host. This allows the client to believe it is talking to the LTM as it's destination host, and the servers will be talking to the origin host via the TCP connection that was originally established. Since the Diameter RFC says that either side can send watchdog, the iRule is set up to intercept and respond to either side of the flow. Else, client-side watchdog would have to be sent to all pool members, or server-side would have to somehow be accounted for and sent through. In the case of no watchdog, TCP idle timeout takes effect. This is what is triggering the removal of the client-side connection, but the server-side remains. Thus, the state we're trying to account for now.

 

 

I suppose it would be possible to tweak this a bit so the watchdog packets are handled in the same manner as the CER/CEA. May end up being the best solution all around.

Wow... that's a novel concept for serially broadcasting a request to all pool members. So for a single client connection, you send the request to each pool member. Periodically, servers will send a watchdog packet to the client and you need to know how to handle that based on whether the client has "silently disappeared" or not. It sounds like in order to test the client status, you'd need to either generate your own packet to the client or pass the server's request through. I'd guess the latter would be simpler.

 

 

So is the issue that you need to track which server generated the watchdog request when you get the client response to that watchdog request? If I am following you...

 

 

Does the Diameter protocol have a way to insert an arbitrary field in a request which the client will return in the response? If so you could insert a session ID there. Or can you use the Origin-State-Id in the message to track which server generated the original watchdog request with a sesison table entry which maps the Origin-State-ID to a specific server?

 

 

Also, out of curiosity, what are you using TCP::notify response for? I've only seen references to it for triggering the USER_REQUEST/RESPONSE events, but I don't see either event in your rule.

 

 

Aaron