It took me a bit to figure out your first two screenshots of are your datalog of time stamps, the EntryStatus attrirbute of the Module class (highest 4 bits), in descending order of time.
It's normal for a connection to go through a sequence of logical status states when it breaks and re-makes. Unfortunately they're not in numerical order of their normal operation.
The sequence you see for node "100" when its connection fails and then restarts is 5, 0, 1, 2, 7, 3, 4.
Under nominal operating conditions, all connection Status values are 4. That's how most folks write trap/detection logic to tell if they're broken. So the state was probably "4" prior to 2021-05/31 03:12:04.
[a timeout or other failure occurs]
5 Shutting Down
[...] six seconds elapse
0 Standby
[...] three seconds elapse
1 Faulted
2 Validating
7 Waiting
3 Connecting
4 Running
[and it runs for a while]
Your screenshot Capture-Comm3.png shows that the problem isn't a physical problem with the cables from the CompactLogix ethernet ports to a switch, because all the media error counters are zero on both ports.
The screenshot Capture-Comm4.png does show that there have been some missed packets in the connection to 10.10.57.86.
But those 24 "Missed Rx Packets" aren't much in the scheme of things, with a connection that's been producing data every 100 ms for 7 hours. 10 packets/second x 60 seconds x 60 minutes x 7 hours = 252,000 packets with just 24 missed Rx packets.
It might indicate a short burst, or an occasional loss. You can't tell from that diagnostic screen because it doesn't timestamp each lost Rx Packet. But because the connection is still up, it wasn't enough to cause it to fail (generally 4x in a row).
