Forum Discussion
ICMP packets on a TCP monitor
We observed an issue where the pool members are on cloud had ICMP disabled. F5 had route and able to telnet to member but the tcp monitor still marked down. Once the ICMP was enabled on the server end, node status came up while it still had TCP monitor.
============================
Tested this in lab...
We have a pool with two members(x.x.x.x:443) in it. Pool ONLY has a default TCP monitor associated to it and the members inherit the same.
As i understand, tcp monitor will try a 3-way handshake and mark the status of the members up/down accordingly.
When i do a tcpdump for this pool member, i see there's a TCP handshake between self-ip and pool member and then FIN from self-ip which is expected.
BUT also see ICMP packets as well and would like to understand why are we seeing ICMP packets here while we are NOT monitoring using ICMP
Also on the monitor logs, there are PING events being mentioned. Hence would like to understand further in-detail on this.
Appreciate your assistance to understand the role of ICMP while a TCP monitor is being used.
[0][15333] 2024-01-17 15:55:04.319941: ID 75 😞_do_ping😞 time to ping, now=[1705487104.319820][2024-01-17 15:55:04], status=UP [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 mon=/Common/tcp fd=-1 pend=0 #conn=0 up_intvl=5 dn_intvl=5 timeout=16 time_until_up=0 immed=0 next_ping=[1705487104.249856][2024-01-17 15:55:04] last_ping=[1705487099.294125][2024-01-17 15:54:59] deadline=[1705487120.249856][2024-01-17 15:55:20] on_service_list=True snd_cnt=1224 rcv_cnt=1222 ]
[0][15333] 2024-01-17 15:55:04.320112: ID 75 😞_do_inactive_service_ping😞 ping [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 srcaddr=none ]
[0][15333] 2024-01-17 15:55:04.320128: ID 75 :(_connect_to_service): creating new socket (rd0) [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 ]
[0][15333] 2024-01-17 15:55:04.320213: ID 75 :(_connect_to_service): connect: Operation now in progress [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 srcaddr=::ffff:172.16.200.202%0:34624 ]
[0][15333] 2024-01-17 15:55:04.320237: ID 75 :(_do_inactive_service_ping): connection pending [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 ]
[0][15333] 2024-01-17 15:55:04.320249: ID 75 :(_do_inactive_service_ping): post ping, status=UP [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 mon=/Common/tcp fd=17 pend=1 #conn=1 up_intvl=5 dn_intvl=5 timeout=16 time_until_up=0 immed=0 next_ping=[1705487104.249856][2024-01-17 15:55:04] last_ping=[1705487099.294125][2024-01-17 15:54:59] deadline=[1705487120.249856][2024-01-17 15:55:20] on_service_list=True snd_cnt=1224 rcv_cnt=1222 ]
[0][15333] 2024-01-17 15:55:04.320271: ID 75 😞_do_ping😞 post ping, status=UP [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 mon=/Common/tcp fd=17 pend=1 #conn=1 up_intvl=5 dn_intvl=5 timeout=16 time_until_up=0 immed=0 next_ping=[1705487109.249856][2024-01-17 15:55:09] last_ping=[1705487104.319820][2024-01-17 15:55:04] deadline=[1705487120.249856][2024-01-17 15:55:20] on_service_list=True snd_cnt=1225 rcv_cnt=1222 ]
[0][15333] 2024-01-17 15:55:04.320764: ID 75 :(_main_loop): Activity on pending service, now=[1705487104.320754][2024-01-17 15:55:04] [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 srcaddr=::ffff:172.16.200.202%0:34624 fd=17 pend=1 #conn=1 ]
[0][15333] 2024-01-17 15:55:04.320786: ID 75 :(_do_inactive_service_ping): ping [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 srcaddr=::ffff:172.16.200.202%0:34624 ]
[0][15333] 2024-01-17 15:55:04.320828: ID 75 :(shutdown_service) Closing logging file /var/log/monitors/Common_tcp-Common_172.16.20.2-443.log
[0][15333] 2024-01-17 15:55:04.320957: ID 75 :(addPingEvent): probe latency 0.072ms; mean latency 0.059ms; standard deviation 0.019ms; confidence interval 0.055ms; divergence limit 0.073ms (mean + 25%); confidence interval limit 0.114ms; status UP. (history buffer contains 11 events (11 timing events) over 49.9832 seconds) [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 srcaddr=none ]
[0][15333] 2024-01-17 15:55:04.320999: ID 75 :(_do_inactive_service_ping): connected [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 ]
[0][15333] 2024-01-17 15:55:04.321031: ID 75 :(adjust_deadline): from [1705487120.249856][2024-01-17 15:55:20] to [1705487125.249856][2024-01-17 15:55:25] [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 mon=/Common/tcp fd=-1 pend=0 #conn=0 up_intvl=5 dn_intvl=5 timeout=16 time_until_up=0 immed=0 next_ping=[1705487109.249856][2024-01-17 15:55:09] last_ping=[1705487104.319820][2024-01-17 15:55:04] deadline=[1705487125.249856][2024-01-17 15:55:25] on_service_list=True snd_cnt=1225 rcv_cnt=1222 ]
[0][15333] 2024-01-17 15:55:04.321062: ID 75 :(_response_success): node was up and is still up [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 srcaddr=none mon=/Common/tcp snd_cnt=1225 rcv_cnt=1222 ]
[0][15333] 2024-01-17 15:55:04.321077: ID 75 :(_do_inactive_service_ping): post ping, status=UP [ tmm?=false td=true tr=false addr=::ffff:172.16.20.2:443 mon=/Common/tcp fd=-1 pend=0 #conn=0 up_intvl=5 dn_intvl=5 timeout=16 time_until_up=0 immed=0 next_ping=[1705487109.249856][2024-01-17 15:55:09] last_ping=[1705487104.319820][2024-01-17 15:55:04] deadline=[1705487125.249856][2024-01-17 15:55:25] on_service_list=True snd_cnt=1225 rcv_cnt=1223 ]
[0][15333] 2024-01-17 15:55:09.329772: ID 75 :(main_loop [next_ping]) Closing logging file /var/log/monitors/Common_tcp-Common_172.16.20.2-443.log
You probably have the default node monitor (set to ICMP) enabled (which sends ICMP health monitor traffic to all nodes, in addition to existing monitors you have already applied)
You can verify this by using the following command:
list ltm default-node-monitor
Sample Output:
ltm default-node-monitor { rule icmp }
If you want to disable this default-node monitor, you can use the following command:
modify ltm default-node-monitor rule none
- F5TeamCirrus
I removed the ICMP and all monitors under the default-node-monitor.
Now the pool only has the default TCP monitor but i still see the ICMP packets on the tcpdump
can you check if this node is added in any other pool that contains ICMP monitor? since you are taking packet capture on the node IP, and the node might be existing as a pool member in multiple pools.
- F5TeamCirrus
The Node doesn't have any other monitor
yes, you mentioned that before, I'm asking if the node is a member of any other pool?
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com