Forum Discussion
Altostratusno outbound traffic pool
Employeeit's hard to say for sure, but since the .18 (presumably) monitor traffic is doing well, it would seem as if the server never completes the TCP 3WH for the .16 request. I also see two different ports (32255 and 32270). Are you certain the server can respond on that port, or isn't in any way configured to block .16? If this is a web app, can you curl to it from the BIG-IP?
curl -vk http://172.17.31.254:32255
Altostratus32270 is another service deployed on the same pool member; it has the same issue as 32255.
Yes the service works perfectly if we bypass the BIG-IP by directly accessing the pool member ip address.
It's a web app, kindly find in attachment the snapshot of the curl fom big-ip to pool member.
- Kevin_Stewart
When you access directly are you using http or https?
Are you using a server SSL profile on the BIG-IP?
- sbroulaye
We're accessing directly using http://172.17.31.254:32255/#/sessions
No server SSL profile configured in this specific VS, only client SSL profile.
- Kevin_Stewart
You indicated earlier that you were testing curl with https. So then if you do this from the BIG-IP shell, you see a good HTTP response?
curl http://172.17.31.254:32255/#/sessionsIf you do, this request would be coming from the self-IP (.18). Is the monitor showing good for the 32255 pool member? I'm assuming here that you're only using a tcp half-open monitor, which just checks to see if the server returns an ACK. So then if you switch to a full tcp monitor, does that still show green? And you have no rules on the server to block traffic from floating .16?
If you tcpdump on both on both BIG-IPs, do you see TCP handshake ACK traffic going to the other box?
