Respond to server depending on TCP::client_port

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.