Interface counters: CRC, runts, giants and drops on Network+

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. A switch port's CRC and runt counters climb steadily while its collision counter stays at zero, and a cable tester passes the run. Which of the following is the most likely cause?

   Right. In the game that’s Renown for your Network Troubleshooting building.

   Not that one: C is right. In the game your Network Troubleshooting building would lose a little Renown, and this question would come back later.

   Your answerA.InterferenceElectrical noise flips bits inside frames and the frame check fails, so CRC errors alone could be interference. Runts are frames cut short, and noise does not cut frames short; the far end stopping mid-frame because it believes it collided does.Your answerB.AttenuationAttenuation is signal loss over distance. A cable tester checks exactly that and passed, and a weak signal would corrupt bits rather than produce a stream of undersized frames.The answerC.Duplex mismatchThe switch port troubleshooting guide states that when a link runs full duplex 'the collision counter is not active.Your answerD.CrosstalkCrosstalk is bleed between pairs inside the cable and is one of the parameters a cable tester measures. A passing test rules it out, and it would not account for the runts in any case.

   Show the full explanation and doc quotes

   If the FCS, CRC, alignment, or runt counters increment, check for a duplex mismatch.' A zero collision count with rising CRC and runt counters is that signature: the half-duplex side detects 'collisions' and truncates frames, which the full-duplex side records as runts and CRC errors.

   Written from www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html

2. A switch port's giants counter climbs steadily while its CRC, runt and collision counters stay flat, shortly after the attached server was reconfigured. Which of the following is the most likely cause?

   Right. In the game that’s Renown for your Network Troubleshooting building.

   Not that one: A is right. In the game your Network Troubleshooting building would lose a little Renown, and this question would come back later.

   The answerA.MTU mismatchThe Ethernet-like interfaces MIB counts, in dot3StatsFrameTooLongs, 'frames received on a particular interface that exceed the maximum permitted frame size'.Your answerB.Duplex mismatchWhen the two ends disagree on duplex, the half-duplex side aborts frames it thinks collided and the other side records runts and CRC errors. A giants count with clean CRC and runt counters is not that pattern.Your answerC.Transceiver mismatchA transceiver that does not match the far end's type or wavelength tends to give no link or a stream of bit errors. It does not lengthen frames, and nothing about the transceiver changed when the server was reconfigured.Your answerD.CrosstalkCrosstalk is signal bleeding between cable pairs. It corrupts bits inside frames, which shows as CRC errors; a well-formed frame that is simply larger than the port allows is a configuration difference, not a cabling fault.

   Show the full explanation and doc quotes

   That is the giants counter. Frames that are too long but otherwise intact mean the sender is using a larger maximum transmission unit (MTU) than the port is configured to accept, which fits a server reconfigured for jumbo frames.

   Written from www.rfc-editor.org/rfc/rfc3635.html

3. An uplink port's drops counter climbs every night during the backup window, while its CRC, runt and giant counters stay at zero. Which of the following is the most likely cause?

   Right. In the game that’s Renown for your Network Troubleshooting building.

   Not that one: B is right. In the game your Network Troubleshooting building would lose a little Renown, and this question would come back later.

   Your answerA.Duplex mismatchIf one side ran half duplex and the other full, the port would record damaged frames: CRC errors, runts, late collisions. Here every error counter is zero and only packets the switch chose to discard are counted, which is a capacity problem, not a link-setting problem.The answerB.CongestionThe Interfaces MIB defines ifOutDiscards as outbound packets 'chosen to be discarded even though no errors had been detected', and names freeing up buffer space as one reason.Your answerC.CrosstalkCrosstalk is signal bleed between pairs; it flips bits and the result is a bad frame check. Frames that arrive intact and are then thrown away because the port cannot send them fast enough are a different symptom entirely.Your answerD.Improper terminationAn improperly terminated cable shows as errors and intermittent link, at any time of day. Discards with no errors that appear only when the backup job floods the uplink point at the link being oversubscribed.

   Show the full explanation and doc quotes

   Error-free discards that track the heaviest traffic period are the port running out of buffer: congestion. A physical-layer fault would raise the error counters, which here are flat.

   Written from www.rfc-editor.org/rfc/rfc2863.html