Forum Discussion
NimbostratusIneffective alias service port in HTTP or TCP Monitors
Hello!
I'm running into a scenario where setting the alias service port for TCPMon and HTTPMon was ineffective. If i look under the instance tab, the active port is different from the alias service port. Instead, it is the port number associated with the nodes/pool.
Can anyone think of a case where this is true? or able to recreate this issue?
For example:
Monitor: HTTPMonitor, alias service port set to 80
Pool: Pool1
Members: 192.168.1.3:1333, 192.168.1.4:1333
Result: service port under "instances" tab in the gui is displaying 1333 instead of 80.
However, according to f5 support, the alias service port should override the port associated with the node. http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_monitors.html
3 Replies
natheCirrocumulus
Hankliu,
Alias port should override port associated with pool member.
My test lab, admittedly v11.4.1 (and I see you might be running v10) the instance reports the alias port correctly. what specific tmos version are you running? possibly a bug?
Anyway, what happens when you tcpdump on the serverside, do you see monitor traffic on port 80 or 1333? If 80 only it might be a GUI issue rather than anything in practice.
N
HankLiu_159320Hey nathan, thanks a lot for getting back to me. I left out a detail in my post. Currently, our f5 configuration is automated and that includes the monitor creation and assocation with pool. However, if I create a second monitor (exact replica) and manually associate it with the pools, the alias service port will function properly and override the default ports from the pool members. So this could be an issue in automation/iControl. Can you suggest some examples on monitor creation or port assocations with pools? Thanks again!
- natheSorry, can't admit to bring an iControl guru. You got me there!
