On Wed, Dec 21, 2022 at 11:03 PM Saku Ytti <saku@ytti.fi> wrote:
On Thu, 22 Dec 2022 at 08:41, William Herrin <bill@herrin.us> wrote:
Suppose you have a loose network cable between your Linux server and a switch. Layer 1. That RJ45 just isn't quite solid. It's mostly working but not quite right. What does it look like at layer 2? One thing it can look like is a periodic carrier flash where the NIC thinks it has no carrier, then immediately thinks it has enough of a carrier to negotiate speed and duplex. How does layer 3 respond to that?
Agreed. But then once the resolve happens, and linux floods the queued pings out, the responses would come ~immediately. So the delta between the RTT would remain at the send interval, in this case 1s. In this case, we see the RTT decreasing as if the buffer is being purged, until it seems to be filled again, up-until 5s or so.
Howdy, Not quite. The ping origination time isn't set when layer 3 decides the packet can be delivered to layer 2, it's set when layer 7 drops the packet on the stack. In other words: when the ping app "sends" the packet, not when the NIC actually puts the packet on the wire or even when the OS sends the packet over to the NIC. The time the packet spends queued waiting for ARP to supply a next-hop MAC address counts against the round trip time. When you see this pattern of descending ping times exactly one second apart where the responses all arrived at once, it's usually because something in the path didn't have the next-hop MAC address for a while, and then it did. And it's usually not something deep in the network because something deep would exhaust it's transmission queue long before it could queue several seconds worth of pings. If you want to prove this to yourself, set up a Linux box, install a filter to drop arp replies (arptables or nftables), delete the arp entry for your default router (arp -d) and then start pinging something. When you -remove- the arp filter, you'll see the pattern in the ping responses that Jason posted. You may get different results in other OSes. For example, Windows will lose its DHCP address with the carrier flash, so when ping tries to send the packet the network is unreachable. Because the stack considers the network unreachable, the ping packet isn't queued and the error is reported immediately to the application. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/