Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
It's possible your device has a very bad config, that drops packets prematurely, but more likely is some source, or sources, of traffic that's just more than the gig interface can handle.
Leo's example of a SAN device is good, but it could also be the combination of traffic from multiple devices, whose aggregate is too much for the gig interface.
What are the usual solutions?
Well, if the congestion is from transient bursts, and queuing delay isn't another issue, increasing interface queuing capacity might be one solution. This might require another "better" device, or sometimes, reconfiguration of the device.
If the congestion is sustained, either you need to provide more bandwidth (e.g. Etherchannel or 10g to the router) or, if device supports, you need to better manage traffic flow rates. The latter can be done in various ways, all not mutually exclusive, but all usually very dependent on device capabilities and protocols being used by traffic. For example, TCP will slow its transmission rate when it detects packet drops, so QoS might manage when and what packets to drop to minimize overall packet drops, yet maximizes transmission rate.
