tracert running multiple times a second to the same private IP address and some other systems

BamaDog27

New Member
Joined
Sep 17, 2024
Messages
3
we are finding that we have multiple Windows systems that are running tracert for the same private IP address, and one to a different private IP address. We don't see anything in Task Scheduler to determine what is doing it, but I was hoping someone here might know if there is a tool or some other way to determine what is causing tracert to run all the time?
 
Solution
Persistent traceroutes running multiple times a second to the same private IP address in a Windows Server environment can be attributed to several factors. Here are some potential causes to consider:
  1. Network Configuration: Check if there's a routing issue or misconfigured network settings that could be causing repeated traceroute attempts. A misconfigured router or a device incorrectly processing routing requests may trigger multiple traceroute attempts.
  2. Monitoring or Logging Tools: If there are any network monitoring or logging tools installed on the server or other devices in the network, they might be generating frequent traceroutes as part of their operation. Verify the settings of such tools to see if they are...
It looks like you're dealing with an interesting situation where multiple Windows systems are executing the tracert command for the same private IP and another distinct private IP. This could point to a few underlying issues or configurations that might not be immediately visible in Task Scheduler. Here are some steps and tools you can use to diagnose the problem:

Process Monitoring: - Use tools like Process Explorer or Process Monitor from Sysinternals to see which processes are running the tracert command. Look for any clues or patterns indicating what might be triggering them. - In Process Monitor, set filters to look for processes involving tracert.exe.
2. Event Logs: - Check the Windows Event Viewer for any logs that might correspond to the execution of tracert. Specifically, examine the Application and System logs around the time the commands are triggered.

Startup Configurations: - Review startup items using msconfig or the Task Manager's Startup tab to see if any applications have been set to launch that might be initiating network diagnostic commands.

Scheduled Tasks: - While you mentioned not seeing anything in Task Scheduler, make sure to check the history of scheduled tasks to see if there might be transient or hidden tasks that could be scheduling these commands.

Network Activity: - Use network monitoring tools like Wireshark or NetWitness to observe the traffic patterns and see if any device is consistently querying the destination IP address. This might provide an indirect hint as to what's triggering tracert.

Group Policies: - Examine any Group Policies that might be affecting network diagnostics or automated scripts across your systems.

Antivirus/Firewall Logs: - Check any security software you have running, as some may run diagnostic commands as part of their operations or protection mechanisms. If you find anything significant using these methods, please share more details, and we can look into it further!
 
Last edited by a moderator:
The first option ChatGPT gives is what I would do. Use procmon from the sysinternals tools with a filter for the process where the operation is 'Process Start'. Double clicking that row should give you a parent PID, that PID should match a process on the system which should identify the culprit.
 
I am running Process Monitor and filtered tracert, but it didn't find anything, yet our firewall is still seeing tracert traffic coming from the server.
 
It could be happening programmatically which would be much harder to track down. Powershell has the built-in Test-NetConnection that can do traceroutes or even could be manually programed in any dotNet or other languages
 
We are running Process Explorer on the server and it doesn't show any tracert's running, yet our firewall says that there are a ton of tracert's coming from it.
 
@ChatGPT What would cause persistent traceroutes on Windows Server that don't necessarily appear in procmon and the origin is unknown.
 
Persistent traceroutes running multiple times a second to the same private IP address in a Windows Server environment can be attributed to several factors. Here are some potential causes to consider:
  1. Network Configuration: Check if there's a routing issue or misconfigured network settings that could be causing repeated traceroute attempts. A misconfigured router or a device incorrectly processing routing requests may trigger multiple traceroute attempts.
  2. Monitoring or Logging Tools: If there are any network monitoring or logging tools installed on the server or other devices in the network, they might be generating frequent traceroutes as part of their operation. Verify the settings of such tools to see if they are misconfigured or working as intended.
  3. Automated Scripts or Applications: Sometimes, automated scripts or applications running on the server might initiate frequent traceroutes for diagnostics or monitoring purposes. Check for any scripts or applications that may have been scheduled or are running in the background.
  4. Malware or Intrusion: In rare cases, persistent traceroutes could indicate malicious activity, such as a network scan by malware. Check the server for signs of malware or unauthorized access to ensure that the network isn't being compromised.
  5. ARP Requests: If the traceroutes are being triggered by ARP requests to resolve MAC addresses for IPs within the same subnet, it can lead to repeated traceroute attempts as the system tries to identify the path to the device.
  6. Network Load Balancers: If your architecture includes load balancers, they may be generating traceroute requests as they distribute traffic to ensure connectivity to various nodes.
To troubleshoot, go through these steps:
  • Monitor network traffic using tools like Wireshark to capture the traceroute packets.
  • Check for running services or scheduled tasks on the server that might cause these traceroutes.
  • Investigate event logs in the Windows Event Viewer for any anomalies or related activities.
By combining insights from network analysis and server monitoring, you should be able to pinpoint the origin of these persistent traceroutes. If you have any specific configurations or logs, sharing them might help in narrowing down the cause further.
 
Solution