I opened a TAC case on this issue and the came back with the following...
"We have the restriction where in if we already have a queuing policy applied to an interface, and if we try to attach another queuing policy to another interface, this new queuing policy should have the same order of class.
So all downlink ports (gi1/0/1 - 48) should have queuing policy in which the order of class should be same . Similarly all uplink ports (gi1/1/1-4) "
I had used autoqos to provision other ports so already had a policy applied on interface gig 1/0/1. After opening the TAC case I made a new policy -map that had same classes in it as the one created by auto-qos but changed the parameters to meet my needs. Was then able to apply it to different interfaces.
I'm facing the same issue. Auto QoS has been uplied on 2 of the trunk interfaces. For various reasons I can't remove this policy-map, but I need to apply different policy-map to stop high output drops on another trunk interface.
Could you please help me how you set up the class-map order so it matches with the AutoQos but it has different parameters.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...