Timeline for What can cause a Layer 2 Switch to drop frames that aren't malformed?
Current License: CC BY-SA 3.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2016 at 11:32 | vote | accept | davidb | ||
| Oct 18, 2016 at 11:32 | answer | added | davidb | timeline score: 1 | |
| Oct 18, 2016 at 11:30 | comment | added | davidb | The problem was solved by a firmware update! | |
| Oct 18, 2016 at 11:29 | history | edited | davidb | CC BY-SA 3.0 | added 56 characters in body |
| Oct 15, 2016 at 15:59 | comment | added | davidb | I start to belive that this is actually a bug in the firmware. Im doing a firmware update and will report back if that worked out,... | |
| Oct 15, 2016 at 15:57 | history | edited | davidb | CC BY-SA 3.0 | added 308 characters in body |
| Oct 14, 2016 at 12:34 | comment | added | marctxk | @RonTrunk, I agree about devices getting checksums wrong but a switch should only drop on bad FCS, not on IP or TCP/UDP checksums, that's for routers/endpoints to worry about. If it does drop for a bad FCS then the drop should be counted. Bad FCS frames are not captured by Wireshark on a normal PC unless the NIC driver is specifically capable and set, if it's a dedicated analyser then they will be. Anyway David tells us that the packet is not malformed. This is a wierd one that's for sure. | |
| Oct 14, 2016 at 12:13 | comment | added | Ron Trunk | @marctxk Another thing to check is to turn on checksum validation on Wireshark -- it's rare, but I've seen devices miscalculate checksums. | |
| Oct 14, 2016 at 12:11 | comment | added | marctxk | @RonTrunk, David's done that and he knows that the frame didn't come out of the switchport that the printer's on. The options now are: it was dropped; it was forwarded out through another port. If it was dropped there should be a counter or there's a bug, if it was forwarded through another port then there was a MAC table change or a bug or the PC has suddenly used the wrong MAC address (still with a Ricoh OUI and existing in the table otherwise it'd be flooded, easy to check). Hard to believe in a MAC change just after the SNMP got through, especially if it's repeatable. | |
| Oct 14, 2016 at 11:25 | comment | added | Ron Trunk | I find it hard to believe that the switch - a layer 2 device - is dropping packets based on layer 4 information. Some possible explanations: 1. The Syn packet has a bad checksum (you don't have checksum validation turned on), 2. The SYN is getting through but the SYN-ACK isn't. Can you capture packets on the other side of the switch? | |
| Oct 14, 2016 at 10:06 | comment | added | davidb | this has been captured from a tap between the switch and the pc. I also put a tap between the switch and the scanner. The frame did not reach the scanner! | |
| Oct 14, 2016 at 10:04 | comment | added | marctxk | I'm assuming this is a capture on the PC that's trying to use the scanner. Nothing jumps out of the trace, you already have two-way packet flow between the two devices. If it were me I'd want to put taps on the two cables to make sure that: it is the SYN that's being dropped (not the SYNACK); it is the switch that's dropping it. However I wouldn't buy two taps for the privilege, it's just too costly compared to the problem when you already have a work-around. | |
| Oct 14, 2016 at 7:52 | comment | added | davidb | See edit for further information | |
| Oct 14, 2016 at 7:52 | history | edited | davidb | CC BY-SA 3.0 | added 321 characters in body |
| Oct 13, 2016 at 9:27 | comment | added | marctxk | When using the SG-200, do the flows fail completely or are they just slow? I'd like to see the network capture. | |
| Oct 12, 2016 at 18:37 | comment | added | Ron Trunk | Any switch, managed or unmanaged, will drop bad frames. | |
| Oct 12, 2016 at 16:08 | comment | added | Ron Maupin♦ | If you can't use CLI, then what does the Etherlike Statistics page say about interface errors? | |
| Oct 12, 2016 at 15:59 | comment | added | davidb | @marctxk it only uses unicast. | |
| Oct 12, 2016 at 15:58 | comment | added | davidb | @RonMaupin That is only valid for the 220 and above. The 200 does not have a CLI and I can't telnet in. (supportforums.cisco.com/discussion/12389791/…) | |
| Oct 12, 2016 at 15:34 | comment | added | marctxk | Does your TWAIN driver use only unicast communication or is there some multicast discovery process involved? | |
| Oct 12, 2016 at 13:58 | comment | added | Ron Maupin♦ | You can telnet to the switch. It has CLI. The command I gave you was directly from the SG200 CLI manual. | |
| Oct 12, 2016 at 13:52 | comment | added | davidb | in the SG-200 series there is no console in the SG-200 series... | |
| Oct 12, 2016 at 13:48 | comment | added | Ron Maupin♦ | This is the command: show interface ethernet {interface | switchport}. Do this for the interface to which the scanner is connected. | |
| Oct 12, 2016 at 13:46 | comment | added | hertitu | Also, "employees have trouble" is rather broad, can you clarify in more detail? And, where/how did you take the capture? If you capture on your PC then of course it will not show any frames that got sent by the scanner but dropped by the switch. | |
| Oct 12, 2016 at 13:42 | comment | added | Ron Maupin♦ | No. In the switch, you can show the interface. It will give you all the statistics, including errors it sees. | |
| Oct 12, 2016 at 13:40 | comment | added | davidb | You mean the packet capture? Or the logged information? | |
| Oct 12, 2016 at 13:35 | comment | added | Ron Maupin♦ | Edit your question to include the output on the switch interface. | |
| Oct 12, 2016 at 13:34 | comment | added | davidb | Sadly the don't say anything | |
| Oct 12, 2016 at 13:33 | comment | added | Ron Maupin♦ | What do the switch interfaces say about errors? | |
| Oct 12, 2016 at 13:28 | history | asked | davidb | CC BY-SA 3.0 |