Packet-Delay and Reordering with a SG200-18-Switch

[jger00001]

Sometimes we see an issue that the switch delays a fragment up to one millisecond. And the delay may cause reordering...

We are using a "SG200-18 18-Port Gigabit Smart Switch" with the following Version:

Software Information
Firmware Version (Active Image):    1.3.2.02
Firmware MD5 Checksum (Active Image):    4e5ee4d4fcc4f6ee86f4cf39e015e362
Boot Version:    1.1.0.6
Boot MD5 Checksum:    01eac6cfe0267f6c28a302c0082b7086

Here is an extract from capture-files showing the issue. You see that the red-marked fragment is in order when it enters the switch. When it leaves the switch the red-marked fragment is delayed and reordered:

Capture on the Interface "before" the switch:

10:18:52.348867 IP (tos 0x0, ttl  15, id 49508, offset 2960, flags [none], proto: UDP (17), length: 306) 192.168.20.13 > 229.2.1.3: udp
10:18:52.348868 IP (tos 0x0, ttl  15, id 49509, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.20.13.35917 > 229.2.1.3.5503: UDP, length 3238
10:18:52.348871 IP (tos 0x0, ttl  15, id 49509, offset 1480, flags [+], proto: UDP (17), length: 1500) 192.168.20.13 > 229.2.1.3: udp
10:18:52.348873 IP (tos 0x0, ttl  15, id 49509, offset 2960, flags [none], proto: UDP (17), length: 306) 192.168.20.13 > 229.2.1.3: udp
10:18:52.348875 IP (tos 0x0, ttl  15, id 49510, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.20.13.35917 > 229.2.1.3.5503: UDP, length 3238

Capture on the Interface "after" the switch:

09:37:42.438678 IP (tos 0x0, ttl  15, id 49508, offset 2960, flags [none], proto: UDP (17), length: 306) 192.168.20.13 > 229.2.1.3: udp
09:37:42.438680 IP (tos 0x0, ttl  15, id 49509, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.20.13.35917 > 229.2.1.3.5503: UDP, length 3238
09:37:42.438681 IP (tos 0x0, ttl  15, id 49509, offset 2960, flags [none], proto: UDP (17), length: 306) 192.168.20.13 > 229.2.1.3: udp
09:37:42.438727 IP (tos 0x0, ttl  15, id 49510, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.20.13.35917 > 229.2.1.3.5503: UDP, length 3238
...

09:37:42.439077 IP (tos 0x0, ttl  15, id 49522, offset 2960, flags [none], proto: UDP (17), length: 306) 192.168.20.13 > 229.2.1.3: udp
09:37:42.439313 IP (tos 0x0, ttl  15, id 49509, offset 1480, flags [+], proto: UDP (17), length: 1500) 192.168.20.13 > 229.2.1.3: udp
09:37:42.458090 IP (tos 0x0, ttl  15, id 49523, offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.20.13.35917 > 229.2.1.3.5503: UDP, length 3238

We looked in the configuration of the switch but we can't find something, so we assume that it might be a bug in the switch...

It is also remarkable that sometimes the same fragment is delayed by two  different Cisco switches in the setup; so it may be be something about  the content of the packet...

Any suggestions, what it can be? Thanks in advance!

[Tom Watts]

Hi Jger, is this for something like a message of the day? What are you using UDP 17 for?  UDP is still best effort which the switch may not necessarily be faulted for. You may try something such as turning off spanning tree on the ports to see if that can help somehow.

-Tom
Please mark answered for helpful posts

[jger00001]

Hi Tom,

thanks for the answer.

No, it is no "message of the day". It is "normal" internet-traffic that is encapsulated within another protocol, that are basebandframes that are send over IP/UDP...

Spanning tree is allready turned off, so that unfortunately does not solve the issue...