monitor connectivity from Windows powershell host
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
I've attached a ps1 script that I use. I added txt to the .ps1 extension so hopefully the mail server delivers it. Let me know if you don't know what to do with it.
Thank You, Kris Springer Systems Admin I/O Network Administration
On 9/16/25 09:24, hopbyhop.net wrote:
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com
Hi I know from experience that the kernel may respond to ping requests though it could be flat dead for any other purposes. While thinking about it it stroked me that on some cases ping won't even hit the kernel but will be handled by the NIC. And indeed this is the case according to deepseek (below). I guess that a ping to VMs running on hardware equipped with smart NIC the availability test is useless:
The Network Interface (NIC/SmartNIC): Limited Offloading
This is where your question gets interesting. Modern high-performance network interface cards (NICs), especially "smart NICs" or "DPUs" (Data Processing Units), can implement parts of the ICMP logic directly on their own hardware or firmware. This is done for performance reasons, to reduce load on the main CPU.
This is not a full implementation but rather offloading specific, simple tasks:
· ICMP Echo Reply Offload (Ping Offload): This is the most common example. The NIC is configured to listen for incoming ICMP Echo Request packets destined for its IP address. Instead of passing these requests up to the host kernel, the NIC's firmware immediately generates and sends the corresponding ICMP Echo Reply itself. The host CPU is never interrupted, which is a significant performance benefit on servers under heavy load. · ICMP Rate Limiting: A smart NIC might be programmed to rate-limit certain types of ICMP messages (e.g., Destination Unreachable) directly on the card before they ever hit the kernel, helping to mitigate flood attacks.
On Tue, 16 Sept 2025, 16:51 IO Support, <support@ionetworkadmin.com> wrote:
I've attached a ps1 script that I use. I added txt to the .ps1 extension so hopefully the mail server delivers it. Let me know if you don't know what to do with it.
Thank You, Kris Springer Systems Admin I/O Network Administration
On 9/16/25 09:24, hopbyhop.net wrote:
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Another point against ping: it may be blocked, depending on company policy. Where I work, there's about 2,000 machines I can't ping, but I can ssh to them just fine. A bunch of others I can both ping and ssh. I think the idea is, if someone breaks into the network, blocking ping stops them from mapping the network. But then ping isn't always blocked, so who the hell knows what they're thinking.....
Ralph Mitchell
On Sun, Sep 21, 2025 at 3:45 AM Ron Cohen <rcohen55@gmail.com> wrote:
Hi I know from experience that the kernel may respond to ping requests though it could be flat dead for any other purposes. While thinking about it it stroked me that on some cases ping won't even hit the kernel but will be handled by the NIC. And indeed this is the case according to deepseek (below). I guess that a ping to VMs running on hardware equipped with smart NIC the availability test is useless:
The Network Interface (NIC/SmartNIC): Limited Offloading
This is where your question gets interesting. Modern high-performance network interface cards (NICs), especially "smart NICs" or "DPUs" (Data Processing Units), can implement parts of the ICMP logic directly on their own hardware or firmware. This is done for performance reasons, to reduce load on the main CPU.
This is not a full implementation but rather offloading specific, simple tasks:
· ICMP Echo Reply Offload (Ping Offload): This is the most common example. The NIC is configured to listen for incoming ICMP Echo Request packets destined for its IP address. Instead of passing these requests up to the host kernel, the NIC's firmware immediately generates and sends the corresponding ICMP Echo Reply itself. The host CPU is never interrupted, which is a significant performance benefit on servers under heavy load. · ICMP Rate Limiting: A smart NIC might be programmed to rate-limit certain types of ICMP messages (e.g., Destination Unreachable) directly on the card before they ever hit the kernel, helping to mitigate flood attacks.
On Tue, 16 Sept 2025, 16:51 IO Support, <support@ionetworkadmin.com> wrote:
I've attached a ps1 script that I use. I added txt to the .ps1 extension so hopefully the mail server delivers it. Let me know if you don't know what to do with it.
Thank You, Kris Springer Systems Admin I/O Network Administration
On 9/16/25 09:24, hopbyhop.net wrote:
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Ralph
I feel for you. Blocking ICMP is a common strategy for "security" but it has three problems (and probably others):
- It's trivial for an attacker to use something like traceroute to send TCP/SYN packets on a few standard ports (eg 22, 443, 445) and you've not only mapped out the accessible hosts, but you also know what services they run.
- Blocking all ICMP means that some core TCP/IP functionality stops working, and this can have a detrimental effect on the resiliency of the network. For example Path MTU Discovery (PMTUD) is now (for about 20+ years) standard in all modern operating systems, and it allows for much more efficient and reliable comms. Disabling the "icmp-fragment-needed" response prevents the two endpoints from negotiating the optimal MTU for the session. Similarly, blocking "icmp-host-unreachable" or "icmp-network-unreachable" packets may prevent the client's ability to quickly failover, unnecessarily causing significant impact in some cases.
- During an outage, the lack of ping prevents various common forms of troubleshooting, potentially making fault resolution take far longer than it could. For high-severity faults this can be catastrophic.
Security measures such as blocking ICMP are very handy to mitigate various risks in some situations. But unless the situation is being considered from a threat and risk perspective, implementing a mitigation without a clear risk to be addressed is putting the cart before the horse, and is not how to do security.
</rant context="I've had this argument many times">
Cheers Jeremy
On Mon, 22 Sept 2025 at 11:15, Ralph M <ralphmitchell@gmail.com> wrote:
Another point against ping: it may be blocked, depending on company policy. Where I work, there's about 2,000 machines I can't ping, but I can ssh to them just fine. A bunch of others I can both ping and ssh. I think the idea is, if someone breaks into the network, blocking ping stops them from mapping the network. But then ping isn't always blocked, so who the hell knows what they're thinking.....
Ralph Mitchell
On Sun, Sep 21, 2025 at 3:45 AM Ron Cohen <rcohen55@gmail.com> wrote:
Hi I know from experience that the kernel may respond to ping requests though it could be flat dead for any other purposes. While thinking about it it stroked me that on some cases ping won't even hit the kernel but will be handled by the NIC. And indeed this is the case according to deepseek (below). I guess that a ping to VMs running on hardware equipped with smart NIC the availability test is useless:
The Network Interface (NIC/SmartNIC): Limited Offloading
This is where your question gets interesting. Modern high-performance network interface cards (NICs), especially "smart NICs" or "DPUs" (Data Processing Units), can implement parts of the ICMP logic directly on their own hardware or firmware. This is done for performance reasons, to reduce load on the main CPU.
This is not a full implementation but rather offloading specific, simple tasks:
· ICMP Echo Reply Offload (Ping Offload): This is the most common example. The NIC is configured to listen for incoming ICMP Echo Request packets destined for its IP address. Instead of passing these requests up to the host kernel, the NIC's firmware immediately generates and sends the corresponding ICMP Echo Reply itself. The host CPU is never interrupted, which is a significant performance benefit on servers under heavy load. · ICMP Rate Limiting: A smart NIC might be programmed to rate-limit certain types of ICMP messages (e.g., Destination Unreachable) directly on the card before they ever hit the kernel, helping to mitigate flood attacks.
On Tue, 16 Sept 2025, 16:51 IO Support, <support@ionetworkadmin.com> wrote:
I've attached a ps1 script that I use. I added txt to the .ps1 extension so hopefully the mail server delivers it. Let me know if you don't know what to do with it.
Thank You, Kris Springer Systems Admin I/O Network Administration
On 9/16/25 09:24, hopbyhop.net wrote:
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
"unless the situation is being considered from a threat and risk perspective,"
That is exactly where we're at. Dept of Defense hands out the rules we have to follow, even though we're not directly connected to any classified networks.
Ralph Mitchell
On Sun, Sep 21, 2025 at 10:26 PM Jeremy Laidman <jeremy@laidman.org> wrote:
Ralph
I feel for you. Blocking ICMP is a common strategy for "security" but it has three problems (and probably others):
- It's trivial for an attacker to use something like traceroute to send TCP/SYN packets on a few standard ports (eg 22, 443, 445) and you've not only mapped out the accessible hosts, but you also know what services they run.
- Blocking all ICMP means that some core TCP/IP functionality stops working, and this can have a detrimental effect on the resiliency of the network. For example Path MTU Discovery (PMTUD) is now (for about 20+ years) standard in all modern operating systems, and it allows for much more efficient and reliable comms. Disabling the "icmp-fragment-needed" response prevents the two endpoints from negotiating the optimal MTU for the session. Similarly, blocking "icmp-host-unreachable" or "icmp-network-unreachable" packets may prevent the client's ability to quickly failover, unnecessarily causing significant impact in some cases.
- During an outage, the lack of ping prevents various common forms of troubleshooting, potentially making fault resolution take far longer than it could. For high-severity faults this can be catastrophic.
Security measures such as blocking ICMP are very handy to mitigate various risks in some situations. But unless the situation is being considered from a threat and risk perspective, implementing a mitigation without a clear risk to be addressed is putting the cart before the horse, and is not how to do security.
</rant context="I've had this argument many times">
Cheers Jeremy
On Mon, 22 Sept 2025 at 11:15, Ralph M <ralphmitchell@gmail.com> wrote:
Another point against ping: it may be blocked, depending on company policy. Where I work, there's about 2,000 machines I can't ping, but I can ssh to them just fine. A bunch of others I can both ping and ssh. I think the idea is, if someone breaks into the network, blocking ping stops them from mapping the network. But then ping isn't always blocked, so who the hell knows what they're thinking.....
Ralph Mitchell
On Sun, Sep 21, 2025 at 3:45 AM Ron Cohen <rcohen55@gmail.com> wrote:
Hi I know from experience that the kernel may respond to ping requests though it could be flat dead for any other purposes. While thinking about it it stroked me that on some cases ping won't even hit the kernel but will be handled by the NIC. And indeed this is the case according to deepseek (below). I guess that a ping to VMs running on hardware equipped with smart NIC the availability test is useless:
The Network Interface (NIC/SmartNIC): Limited Offloading
This is where your question gets interesting. Modern high-performance network interface cards (NICs), especially "smart NICs" or "DPUs" (Data Processing Units), can implement parts of the ICMP logic directly on their own hardware or firmware. This is done for performance reasons, to reduce load on the main CPU.
This is not a full implementation but rather offloading specific, simple tasks:
· ICMP Echo Reply Offload (Ping Offload): This is the most common example. The NIC is configured to listen for incoming ICMP Echo Request packets destined for its IP address. Instead of passing these requests up to the host kernel, the NIC's firmware immediately generates and sends the corresponding ICMP Echo Reply itself. The host CPU is never interrupted, which is a significant performance benefit on servers under heavy load. · ICMP Rate Limiting: A smart NIC might be programmed to rate-limit certain types of ICMP messages (e.g., Destination Unreachable) directly on the card before they ever hit the kernel, helping to mitigate flood attacks.
On Tue, 16 Sept 2025, 16:51 IO Support, <support@ionetworkadmin.com> wrote:
I've attached a ps1 script that I use. I added txt to the .ps1 extension so hopefully the mail server delivers it. Let me know if you don't know what to do with it.
Thank You, Kris Springer Systems Admin I/O Network Administration
On 9/16/25 09:24, hopbyhop.net wrote:
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Well, I had one, but I retired 5 months ago and have no access to the collection of my powershell scripts. I was using the powershell's TNC ( test network connectivity) to the remote RDP ports, because ping is not a good indication to the availability of the server. ICMP is a low-level protocol and the kernel may respond though the server will not be available to any users' activities. Good luck with it Ron
On Tue, 16 Sept 2025, 16:24 hopbyhop.net, <ict@hopbyhop.net> wrote:
Hi all. I would check connectivity from a Windows machine (with XymonPSClient installed) do one or a few external host. Just a ping response time would be enough. Anyone has a quick and dirty solution already implemented? Thanks Mario
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
participants (5)
-
hopbyhop.net
-
IO Support
-
Jeremy Laidman
-
Ralph M
-
Ron Cohen