Hi Craig,
the used syntax of
[TCP::collect]
followed by
[TCP::payload]
and
[TCP::release]
looks fine for me. The iRule should successfully collect the first TCP packet send by your client, inspect the received payload and then select a
[pool]
based on the result and then just relase the collected packet and send it to the selected pool.
So far so good, but unfortunately you will not find the FQDN of the accessed erver within the payload. The problem is that SSH does not reveal the used FQDN like the TLS protocol would do using its SNI extension. The only information that is send in the initial TCP packet exchange is the SSH-Agent / Version string of your SSH client and server:
Client -> Server : SSH-2.0-PuTTY_Release_0.67
Server -> Client : SSH-2.0-OpenSSH_5.3
So in the end your intended iRule logic may work for you, if you're going to use different SSH clients for the individual SSH servers, or if you find a SSH client which would allow to overwrite the initial SSH-Agent / Version strings using additional command line options... 😞
Cheers, Kai