Netonix Forums

We have a WS-12-DC taking multilple WAN connections and a Metro ethernet connection and trunking them back to our server room via LACP. The performance has been fine as far as we can tell.

We have been troubleshooting an issue with one upstream provider since December, most of that time this switch was NOT in place, but they continue to want to troubleshoot with Cisco. Yesterday on a 2 hour conference call with Cisco the only problem we could find anywhere was RX drops on the ports of our Netonix.

This switch typically sees between 200-700 Mbps TOTAL throughput, so we should be well within the performance capabilities of the Netonix. We are not seeing RX errors, only drops and, to a lesser degree, filtered packets. We have tried different ports, different (tested) cables, and a copper SFP. All show the same issue, steadily incrementing RX drops. MTU is the same on the Netonix and Cisco ends.

What could be causing these RX drops?

Rx Drops is a common issue many people in the IT world battle to find the cause:
https://www.google.com/search?q=what+ca ... e&ie=UTF-8


There is no clean cut answer to this question, the only real way to find the exact answer is to experiment or use port mirroring and software like wireshark.

We appear to have resolved the issue with an upgrade from 1.4.5 to 1.4.7 firmware.

brock wrote:We appear to have resolved the issue with an upgrade from 1.4.5 to 1.4.7 firmware.

Well not sure how that would have any bearing on it unless it was an SFP port (maybe).

We use a switch core. We do not write the switch core code it is hard coded in the chip.

All we write is the UI/CLI/Daemons.

What we do is turn features on and off in the switch core, that's it. This is not a SOFTWARE switch where we write the code that touches every single packet.

Simply there is a switch core with a default config when it boots up. WHen our Linux system boots and loads the UI/CLI we then configure options such as FLow Control or VLANs in the switch core we do NOT write or change the core switch software at all, this is not how a switch core works.

Now it is possible that the soft reboot that occurs at the completion of the reboot which drops all Ethernet connections and renegotiates did something?

Or as I said if an SFP port we have changed some of the config options on versions for the SFP slots to make them more compatible with more modules?

In past versions we increased the default MTU size but that was many versions ago.

Sometimes breaking Ethernet connections and resetting the connection fixes something which could be on either side of the link.

Was not SFP. I agree it could be the reboot.

brock wrote:Was not SFP. I agree it could be the reboot.

Well glad it is resolved.