Hi Adam,
Nice to meet you again!
Question a) If it gets discarded i will not see it in a network analyzer like Wireshark. How can I check on a Switch for FCS errors / how many frames it dropped because of CRC mismatch ?
There are show commands to reveal these kinds of issues.
Switch# show interfaces fa0/1
FastEthernet0/1 is down, line protocol is down (notconnect)
Hardware is Fast Ethernet, address is 0023.34ed.9683 (bia 0023.34ed.9683)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Switch# show interfaces fa0/1 counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Fa0/1 0 0 0 0 0 0
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa0/1 0 0 0 0 0 0 0
Switch# show controllers ethernet-controller fa0/1
Transmit FastEthernet0/1 Receive
0 Bytes 0 Bytes
0 Unicast frames 0 Unicast frames
0 Multicast frames 0 Multicast frames
0 Broadcast frames 0 Broadcast frames
0 Too old frames 0 Unicast bytes
0 Deferred frames 0 Multicast bytes
0 MTU exceeded frames 0 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 0 Minimum size frames
0 8 collision frames 0 65 to 127 byte frames
0 9 collision frames 0 128 to 255 byte frames
0 10 collision frames 0 256 to 511 byte frames
0 11 collision frames 0 512 to 1023 byte frames
0 12 collision frames 0 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 0 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
0 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames 0 Too old frames
0 511 byte frames 0 Valid oversize frames
0 1023 byte frames 0 System FCS error frames
0 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames
These outputs were captured on a Catalyst 3560. These commands would also apply to 2960 and 3750 series switches. Other platforms may have slightly different commands and their outputs but there should always be a way of getting these values.
Question b) Will the Switch notify Laptop1 that it dropped the Frame, or will it be completely up to the Layerk 4 protocol on Laptop1 side to handle this issue ?
No, the switch will silently discard the frame without notifying anyone. Ethernet has no signalling that would allow one device to tell the other that the frame has been damaged or discarded. The frame will be lost without a trace, and it is up to higher protocols (in TCP/IP, up to TCP or SCTP) to correct the resulting information loss.
What i mean prior to exchanging data, Laptop1 and PC2 established a connection (3 way handshake). So Laptop1 will send data with the sequence number let's say 0123 and since it didn't get any ACK for that SEQ number from PC2 because the frame was dropped by the switch , it will be the Laptop 1 that will re-send the frame ?
You are talking about a TCP session between Laptop1 and PC2 here. In this case, yes, you are correct: Because Laptop1 will get no acknowledgement for the data it sent to PC2, it will - after a certain period of time - re-send the unacknowledged TCP segment that will get encapsulated into an IP packet and ultimately into an Ethernet frame as it is sent out from Laptop1's NIC.
Case 2. The Frame reaches PC2 and because of CRC mismatch it being dropped by the PC2 NIC. How can i check if this was caused by CRC issues ?
This depends on whether the operating system on PC2 maintains any statistics regarding its NIC operation. When a NIC drops a frame because of some error condition, it will signal this in some of its internal registers that the NIC driver can access and collect information from. The question is, though, whether the operating system collects this information. Being a Linux guy, I cannot really speak for Windows, but in Linux, these data are to be seen in various places. For example, if my WiFi adapter is called wlan0 under Linux, the statistics can be seen as individual files in the /sys/class/net/wlan0/statistics directory. Another file holding these data for all network cards in system is the /proc/net/dev file.
Perhaps someone more acquainted with Windows can tell us if there is a way of accessing these counters under that OS.
Best regards,
Peter
