I appreciate the help, I'm seeing extremely slow file transfer rates and file access when the AutoQoS feature is configured on a 3850 stack, as soon as I remove the auto generated QoS service policy from an interface where the PC is plugged in then all file access/transfers return to normal. Has anyone experienced this and/or has any recommendations? I've seen this also on a 3750 stack. Thanks again.
I'm seeing the exact same on a 3850 but only on ports that have 10/100 Cisco phone connected. Computers directly connected or thought a 1G Cisco phone are not affected.
Have a look at bug CSCug85580
When "auto qos voip cisco-phone" is applied to a 3850 port, data traffic over 10 (or 20) Mb/s is dropped at ingress.
Issue seen in IOS-XE 3.2.0/3.2.1(SE) on a Catalyst 3850
The policy below is the generated Service-policy input: AutoQos-4.0-CiscoPhone-Input-Policy Class AutoQos-4.0-Default-Class set dscp default police cir 10000000 bc 8000 be 8000 conform-action transmit exceed-action set-dscp-transmit dscp table policed-dscp violate-action drop Remove the policer from the above class-map policy.
----How to upgrade to fixed release ---------
step 1. record all auto qos config by "show auto qos":
GigabitEthernet2/0/3 auto qos voip cisco-phone
GigabitEthernet2/0/27 auto qos voip cisco-softphone
step 2. under the interface, do "no auto qos ..." for each of the above interfaces
step 3. sh run | i AutoQos, do the following
a. no policy-map xxx
b. no class-map xxx
c. no ip access-list extended AutoQos-xxx
d. no table-map xxx e. no table-map policed-dscp
step 4. sh run | i AutoQos, make sure that nothing exists
step 5. show auto qos make sure that nothing exists
step 6. wr mem
step 7. reload with rebuild/fixed image
step 8. re-configure auto qos for the interfaces recorded in step 1. .
Ive seen this a number of times, luckily we have it fixed in newer releases.
If you need assistance with upgrading the 3850, i wrote this document that might help: https://supportforums.cisco.com/docs/DOC-36615
hope that helps
Upgrading to IOS-XE 3.3 without taking the extra step of deleting the autoQoS and regenerating it seems to have fixed this.