08-03-2024 09:43 PM
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.
08-03-2024 11:38 PM
qos queue-softmax-multiplier 400 <<- this value need to 400 not 1200 for SW C3k series
MHM
08-04-2024 05:49 AM
Your recommendation is based on?
I ask because shows 1200 being used in https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/200594-Catalyst-3850-Troubleshooting-Output-dr.html#toc-hId--444667651
08-04-2024 06:16 AM
I remember I read this value in cisco doc. I will search for this doc. Share it here.
MHM
08-04-2024 06:29 AM
Thank you. It would be interesting to read if you find it.
08-04-2024 06:17 AM
If 400 not help you share the qos you apply let me check it
MHM
08-03-2024 11:50 PM
- 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.
08-04-2024 09:14 AM
@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).
08-04-2024 06:11 AM
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!
08-04-2024 09:34 AM
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).
08-10-2024 11:12 PM
@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.
08-12-2024 01:29 AM
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
08-12-2024 09:47 AM
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.)
08-12-2024 12:40 PM
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
08-12-2024 01:11 PM
@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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide