cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
686
Views
6
Helpful
14
Replies

Cisco 3850 Output Errors

mspdog22
Level 1
Level 1

Hello 

 

We are running Cisco 3850-48P-L in our network and facing issues with output errors. We are using these switches in a Service provider network for a large MDU install and offering the MDU a 1 gig plan. When we run a speed test on the switch we can only see about 540 mbps download and 940 mbps upload. I am not worried about the upload speed as 940 is a good number witch you have to take in that ethernet has overhead factored in. When we look at the interface we are seeing tons of output errors on the switch ports. 

Our software ver is 16.09.08 

We have also ran the command 

qos queue-softmax-multiplier 1200

 

From what i have been reading up on is this command should take care of the issue but it is not working. 

you

Thanks for any help you can provide. 

14 Replies 14

qos queue-softmax-multiplier 400 <<- this value need to 400 not 1200 for SW C3k series 

MHM

I remember I read this value in cisco doc. I will search for this doc. Share it here. 

MHM

Thank you.  It would be interesting to read if you find it.

If 400 not help you share the qos you apply let me check it 

MHM

marce1000
VIP
VIP

   

   - Check cable and or cabling for the involved interfaces ; also have a look at 
      https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/200594-Catalyst-3850-Troubleshooting-Output-dr.html

   M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

@marce1000 raises a good point about checking cabling as OP didn't describe the actual "output errors".  If they are just due to drops, generally that's due to interface egress congestion, not hardware issues (well beyond, perhaps, insufficient hardware resources).

Joseph W. Doherty
Hall of Fame
Hall of Fame

The 1200 setting often reduces drops but does not guarantee zero drops.

Most network designs (for practical reasons) do not preclude the possibility of there being drops.  If fact, "good" protocols will try to determine maximum available bandwidth possibly using drops.

Might drops be reduced further?  Maybe, but it can take much QoS tuning effort for possibly little improvement.

Actually a 3850 is probably not the ideal platform in a SP environment.  Cisco used to (?) have a Metro Ethernet switches for that purpose.  Unsure what, if any, switches Cisco would recommend currently.

The Cisco document @marce1000 recommends looking at is a really, really good place to start!

BTW, if you read the document @marce1000 provided, a (very) important note is:

From 3.6.3 or 3.7.2, the maximum value for Softmax can be modified with the CLI command qos queue-softmax-multiplier 1200 with 100 as the default value. If configured as 1200, the Softmax for non-priority queues and non-primary priority queue (!=level 1) are multiplied by 12 from their default values. This command would take effect only on the ports where a policy-map is attached. It is also not applicable for priority queue level 1.

I.e. just using qos queue-softmax-multiplier 1200 globally may not adjust the interface buffers.

The other thing to keep in mind, buffers are both reserved and a shared resource.  I.e. to increase the amount of possible shared buffers, you need to, if possible, reduce reserved buffers, this is one of the aspects of "QoS tuning" I referred to earlier, but so is using the qos queue-softmax-multiplier 1200 command.  Any QoS tuning chances making things worse, rather than better.  That said, qos queue-softmax-multiplier 1200 is so often recommended, one can wonder why it's not the default (actually someone did post that as a questions on these forums).  The answer is, rarely does it cause things to worsen, but that's not the same as never, and often it does help.

One of the big differences, between basic LAN switches, and higher end switches and/or Metro Ethernet switches, the latter often have more more hardware support, like more RAM for buffers (also why they tend to cost more).

Leo Laohoo
Hall of Fame
Hall of Fame

@mspdog22 wrote:
540 mbps download

This is an ISP issue.  

Configure traffic-shaping until the output drop stops incrementing and then report the (traffic-shaping) rate to the ISP so they make corrections.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @mspdog22 ,

I agree with @Leo Laohoo . The results of the tests for downstream 540 Mbps lead likely to an ISP issue.

Hope to help

Giuseppe

 

Joseph W. Doherty
Hall of Fame
Hall of Fame

Reading both @Leo Laohoo and @Giuseppe Larosa replies, they both appear to believe the "540 mbps download" is strictly an ISP issue, which it might be, but since you've identified yourself as a MDU service provider, it's unclear to me whether the upload/download stats you describe are between you and your clients or are between you and your upstream provider.  I.e. is the 540 Mbps what you see as your ingress stat on your uplink or as your egress stat on your downlink?  What interfaces are showing the high drop rates, you uplink or downlinks or both?

As a side note, if you're unable to pull more than 540 down from your upstream ISP, definitely there could be a problem with them, but there are possible reasons it's not them too.  For example, if a download speed test is using something like TCP ACKs, to regulate its send flow rate, such ACKs being dropped, going upstream, can cause the download rate to slow.

Or, for something like TCP speedtests, a too small RWIN, on the receiving host, will limit transmission rate to that host.  (Also a too large RWIN can cause a slowdown too, or some corner cases of just a few packet drops.)

Hello @Joseph W. Doherty ,

I agree with you that the OP has not specified where he has performed the speed test.

However , he says:

>> When we run a speed test on the switch we can only see about 540 mbps download and 940 mbps upload

This is what makes me think of a possible ISP sub rate circuit at least in one direction

Hope to help

Giuseppe

 


@Giuseppe Larosa wrote:

Hello @Joseph W. Doherty ,

I agree with you that the OP has not specified where he has performed the speed test.

However , he says:

>> When we run a speed test on the switch we can only see about 540 mbps download and 940 mbps upload

This is what makes me think of a possible ISP sub rate circuit at least in one direction


Certainly possible.  Also we don't know the interfaces being used for that test, which may be especially relevant in light of "When we look at the interface we are seeing tons of output errors on the switch ports.", ports, plural.

More over, OP, at least, appears to believe the lower than expected download performance is due to output drops, but if they are only getting about half of a gig interface's utilization upon ingress (download), why/where drops?

Again, certainly a provider might have provisioned less than full link bandwidth, but also again, you don't get drops until you oversubscribe bandwidth.  Believe we need more clarity on what the situation actually is.

Review Cisco Networking for a $25 gift card