2

I would have a question regarding physical problem detection in a link with ping.

The assumption is as follows: I have a fiber or cable with much of noise due to bad hardware (bad cable or bad transceiver for example), so this cable or fiber will statistically generate CRC Errors for X% of ethernet frames, is it true?

So, could you confirm me this point or tell me if I'm wrong: With large ping (65k packet for example), one ping will generate approximately 65000 / 1500(mtu) = 43 frames, as ip fragments, so normally the probability to get ICMP packets loss (because normally if one IP fragment is lost the entire IP packet is lost) with large ping is higher than with small ping?

So, the global question is, whereas ping and ICMP are for layer 3 problems detection, with large ping, could we easier detect a physical problem on a link?

  • 1
    To diagnose layer 1 problems, the error counters in your equipment do a lot better job than guesswork using ping. Statistically, yes, a larger packet (or bunch of linked packets) will get damaged and dropped more easily than smaller ones. – Zac67 Jul 11 '17 at 17:19
1

Sending a good ten minutes of 0-interval MTU-sized DF pings with contents 0x0000 and a second test with contents 0xffff is an excellent way to apply some stress to simple transmission technologies. Lost packets -- or overly delayed packets after the first few packets -- are a clear indication that further investigation is required. It's also a good moment to check that the reported round-trip time is within reasonableness (it's very easy for a transmission provider to provision a circuit which crosses the country and back rather than crossing the city).

Ping is great for finding faults. However, ping alone isn't a great acceptance test for being sure there are no faults. The rest of this answer explains why.

As part of the ping test you should connect with each of your network elements on the path (hosts, switches, routers) and record the transmission traffic and errors counters before the start and after the end. Rising error counters of any type require further investigation. Don't ignore small rises in error counters: even a low rate of loss will devastate TCP performance.

This still isn't to say that the link is acceptable. Let's take 1000Base-LX, ethernet over single-mode fiber. It's possible that the light levels at the receiver are under the specification for that transceiver's model. But we have an above-average sample of that transceiver so all is well. But then that transceiver has a fault and we replace it with a below-average-but-within-specification sample. The link cannot restore to service even though we have fixed the fault. So as part of the acceptance testing we need to check that light levels are within specification at both ends; and we need to check that there is a viable power budget at the extremes of both transmitting and receiving transceiver's performance (to make this easy, manufacturers will give their SFPs nominal ranges where they have done the power budget calculations, such as 10Km for 1000Base-LX/LH. But for any link longer than 10Km you should do your own power budget: five minutes arithmetic can save you hundreds of dollars in allowing you to safely purchase a lower-power SFP). SFPs often have a feature "DOM" which allows you to check the receive light level from the device's command line.

More complex transmission technologies have forward error correction. So the link appears to work under high transmission error rates, but if error rates are higher or more sustained then the FEC is overwhelmed and the transmission passes rubbish. So for these links we are very interested in the counts of error corrections. Interpreting those FEC counters requires understanding the physical transmission, as we're now low enough in the "stack" that we can no longer pretend that media isn't naturally free of errors. But even in these systems a simple ping test is enough stress to give initial results.

Finally, you should be aware that PCs are a cheap but not perfect test platform. So sometimes packet drops are because of the end-systems rather than the transmission. This can be simple IP-layer issues (such as a MTU inconsistent with the subnet, always a possibility when backbone links should be running with a MTU > 9000) or host performance issues (particularly >10Gbps). The cost of "real" ethernet test platforms is extraordinarily high, because you're paying for those issues to have been fully sorted via hardware or clever software (eg, running within the NIC).

2

It depends on the type of the noise. If it is an ideal random noise, then yes, you will get much higher packet loss with bigger packets. It suggests a layer1 problem. In this case, setting a smaller packet size can be a workaround for TCP.

However, in the daily practice, often not this is the case. Particularly transceiver problems tend to forget whole packets, or to send crap to the optical line.

  • Ethernet defines the medium and signaling methods. What exactly do you define as “below Ethernet”? The physics behind the characteristics of electricity/light? – YLearn Jan 23 '18 at 14:09
  • @YLearn Exactly. Layer2: Ethernet, Layer1: bit stream on the wire, Layer0: analogue stream (= signal) on the wire. Although ISO/OSI defines only layer1-7, I've heard this terminology on many places. I would also mention, ISO/OSI is not really a full-implemented standard, it serves more like a reference. – peterh Jan 23 '18 at 14:15
  • 1
    Signal on the wire is part of L1 in the model (after all, the signaling is how the the bits are determined) and part of the Ethernet standard. Yes, the models are just that but to go below L1 in the OSI model would be getting down to the flow of electrons through a conductor. L0 makes no sense and the only times I have heard it used were by people who don’t actually understand the conceptual models. – YLearn Jan 23 '18 at 14:52
  • @YLearn The ISO/OSI "standard" is not a "standard" in the sense that we can have any application and compare its workings to the literal meaning of its definitions. Practically there are no applications of this standard. It is not like if you point to a C source code and I can say (or can't) deterministically say, if it is valid ISO/IEC 9899:2011 or not. ISO/OSI works as a reference model, i.e. it simplifies our communication. On this reason, I can't admit that this minor detail would be a really important thing. On the same reason, I changed "layer0" to "layer1" in the post. – peterh Jan 23 '18 at 15:38
  • Where did I refer to it as a standard? The only standard that I refer to is the Ethernet standard, which is a standard (specifically IEEE 802.3). When referring to the OSI model, I always refer to it as a model. And that model includes the signaling on the wire as part of L1, which is why The Ethernet standard is often referred to as a L1/L2 standard since it includes both layers of the conceptual model in the standard (which also means you L1 and below Ethernet do not make sense). – YLearn Jan 23 '18 at 16:01
0

Ping with large packet is only to check the mtu size passing through this segment CRC errors mostly incremented while there is issue with physical layer even with small mtu value.

  • Whereas ping is layer 3 diagnostic tool, and crc are layer 1 and 2 problem detection, I think there is a correlation to do. It's like to speak about packet loss incidence regard tcp bandwidth. Two differents layer but a correlation is possible. Many packet loss result of a big tcp bandwidth reduction. We could quantified this. I think doing the same correlation with ip packet loss and crc errors is possible. But I don't get the confirmation. – bdes31 Jun 12 '17 at 8:00
  • Ping only works for path MTU verification if you're taking care that it doesn't fragment. – Zac67 Jul 11 '17 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.