According to Cisco documentation, a crc on a serial interface is conducting a crc check at the packet level. I have also seen documentation that says that crc's are performed on frames, a crc check is used to decide if an fcs should be incremented.
My question is: would the crc's given in a show interface for an ether interface be a the packet level, or are the frame level? Would a failure require the re-transmission of a frame or a packet?
CRCs in "show interface" belong to frame CRC failures. The frame is dropped, if this occures, so data is lost. If retransmission takes place is basically a question of Layer4 protocol. With TCP the answer is yes, with UDP the answer is no.
From the command reference for "show interfaces":
"Cyclic redundancy check generated by the originating LAN station or far-end device does not match the checksum calculated from the data received. On a LAN, this usually indicates noise or transmission problems on the LAN interface or the LAN bus itself. A high number of CRCs is usually the result of collisions or a station transmitting bad data."
"On an ATM interface, CRC errors also occur when the ATM network provider drops some cells of a total packet in the switch "cloud". This can be done to police the number of cells and bits per second you are transmitting. You can obtain more information on policing by clicking here. The ATM interface detects these lost cells when the segmentation and reassembly (SAR) function reassembles the cells to create a complete packet again. Thus, CRC errors on ATM interfaces may point to a mismatch in traffic shaping and traffic policing parameters."
This quote is directly from cisco's site. Even though this quote is in the context of the ATM, it still refers to the crc in relation to re-assembly of the packet via segmentation, not to a cell. If a re-transmission of cells is needed to complete a packet due to lost cells through the cloud, as part of the SAR process a crc would increment. While we generally expect that a crc would increment when a malformed frame or cell arrives, a crc is also clocked, at least in case of ATM, when a segment fails the segment and re-assembly process (sar). I cant find anything definitive, but I would assume the same thing would be true using other types of L2 transport.
Many thanks for your response, and please feel free to correct me where I am confused.
sure, for ATM this is true, but it is still OSI Layer2. In other Layer2 protocols there might be no fragmentation. The exceptions are ATM, MLPPP, FR fragmentation.
And in ATM there is no packet reassemled but a frame, f.e. the AAL5 frame. The usage of the word "packet" in the above citation is misleading (to say the least).
So CRC checking in ATM is also done in Layer2 with the help of the AAL5 frame CRC. There is no check performed on IP, TCP or other protocols containing CRC fields.
In a strict sense, OSI layer 2 data units are called frames and Layer 3 data units are called packets, Layer 4 are segments.
CRC refers to frames and thus to Layer2 Errors. I admit, that a frame CRC error would most likely also mean a packet CRC error, though especially in ATM AAL5 one could imagine a bit error occuring in the padding bytes not affecting the transported IP packet.
In any case a detected CRC error results in a discard of the complete frame.
One more thing: "If a re-transmission of cells is needed to complete a packet due to lost cells through the cloud..."
There will be NO cell retransmission in ATM. The frame is discarded if cells are missing (or CRC fails), counters are increased ... and the rest is up to Layer4 in the end devices.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.