Something I can't wrap my head around is happening with a DC on our network. I am a programmer by trade not a network engineer, but I am 99% sure this is not normal behavior.
Anyway when I rebooted the DC I had a cmd prompt open on my machine pinging the machine so I could see when it went down/came back up. However the pings never stopped, so I logged into the machine to look and see if it rebooted, which it did based on the system uptime being reported.
So I did the same thing with Linux running the ping command, which shows duplicate packets being returned on every request, except when the machine was down for the reboot.
So on windows the packets didn't change much when I rebooted it, just the TTL changed.
Reply from 10.0.0.254: bytes=32 time<1ms TTL=128
[... Machine rebooted]
Reply from 10.0.0.254: bytes=32 time<1ms TTL=255
[... Machine came back up]
Reply from 10.0.0.254: bytes=32 time<1ms TTL=128
On the Linux machine the duplicates stopped while the machine was down rebooting. Also every duplicate on the Linux ping has a TTL of 255 and the non-duplicates were all 128.
The machine in question is used for DC, DNS, and a file Server. It is listed as the second DNS server on both the machines tested.
If I ping another DC from both those machines there are no duplicates in Linux, and I suspect that it would not respond to pings while rebooting like the other machine.
Does anyone have any explanation what the heck is going on? The network has 2 AD DC/DNS servers with no load-balancing, clustering, or any other type of failover.
Best Answer
The default TTL for Windows (at least for all current versions) is 128, so those ping replies are from your DC. The ping replies with a TTL of 255 are from another device (probably Linux based) that has an A record in DNS that is the same as the A record for the DC. Take a look at the relevant DNS zone to find the offending A record and delete it. Check the system that corresponds to the offending A record to make sure it isn't configured with the same ip address as the DC.