Here's a question I haven't bothered to ask until now. Can someone please
help me understand why I receive a ping reply after almost 5 seconds? As I
understand it, buffers in SP gear are generally 100ms. According to my math
this round trip should have been discarded around the 1 second mark, even
Sometimes this is usually due to high CPU time on the target device. If the
device is under heavy load, the ICMP Echo process gets lowest priority. With a
well-known name server like 4.2.2.2, this seems unlikely. It could be an
intermediate hop or a routing loop, Do a traceroute to get more deta
Keep in mind that ping reports round trip time, so there could be a device
delaying the ping reply on the return trip. In these cases, it helps to have a
traceroute from both ends, to detect asymmetrical routing and possibly return
path congestion invisible in a traceroute from you end.
On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone wrote:
> Here's a question I haven't bothered to ask until now. Can someone please
> help me understand why I receive a ping reply after almost 5 seconds?
>
> 64 bytes from 4.2.2.2: icmp_seq=398 ttl=54 time=4915.096 ms
> 64 bytes from 4.2.2.2: icmp_se
There's this thing called bufferbloat...
On Wed, Dec 21, 2022 at 11:58 AM William Herrin wrote:
>
> On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone wrote:
> > Here's a question I haven't bothered to ask until now. Can someone please
> > help me understand why I receive a ping reply after almost 5
As well if this persists you may consider disabling hardware rx/tx checksumming
to see if it clears up your results. Some net cards can get glitchy causing
this exact behavior.
GL
--
J. Hellenthal
The fact that there's a highway to Hell but only a stairway to Heaven says a
lot about anticip
On Wed, Dec 21, 2022 at 1:20 PM Dave Taht wrote:
> On Wed, Dec 21, 2022 at 11:58 AM William Herrin wrote:
> > On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone
> > wrote:
> > > Here's a question I haven't bothered to ask until now. Can someone please
> > > help me understand why I receive a ping r
You didn't tell us anything about your path or your endpoint, or if you see
this just with Lumen's DNS servers or with other devices. So it is hard to
guess what is going on here.
That said, I know I've seen this kind of behavior both with buffer bloat on
consumer devices (particularly the uplink
Because there is no standard for discarding "old" traffic, only discard is for
packets that hop too many times. There is, however, a standard for decrementing
TTL by 1 if a packet sits on a device for more than 1000ms, and of course we
all know what happens when TTL hits zero. Based on that, you
There certainly aren't any temporal buffers in SP gear limiting the
buffer to 100ms, nor are there any mechanisms to temporally decrease
TTL or hop-limit. Some devices may expose temporal configuration to
UX, but that is just a multiplier for max_buffer_bytes, and what is
programmed is a fixed amou
On Wed, Dec 21, 2022 at 10:07 PM Saku Ytti wrote:
> I don't really think
> ARP/ND is good candidate like Herring suggested, because it's
> cyclical, instead of exactly single event, but not impossible.
Suppose you have a loose network cable between your Linux server and a
switch. Layer 1. That RJ
On Thu, 22 Dec 2022 at 08:41, William Herrin 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 periodi
On Wed, Dec 21, 2022 at 11:03 PM Saku Ytti wrote:
> On Thu, 22 Dec 2022 at 08:41, William Herrin 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
13 matches
Mail list logo
