- A few questions about APIC-EM EasyQoS deployment: If APIC-EM EasyQoS was using NBAR for identifying application packets on a router, how would it do the same on a non-NBAR device like 3750-X.
- If customer decided to trust the DSCP marking from a connected end point, how could this be configured on APIC-EM allowing the device trust DSCP for the particular port instead of service-policy input
On the first question (what would EasyQoS do for a non-NBAR supported platform), please see
For the second question:
- >If customer decided to trust the DSCP marking from a connected end point, how could this be configured on APIC-EM allowing the device trust DSCP for the particular port instead of service-policy input?
A principal that EasyQoS (as part of DNA Automation) is built on is policy-abstraction. In other words, we're not looking to present ever QoS lever and **** and option to the operator to configure; but rather we are soliciting business-level intent (i.e. "tell us what applications are important to you") and then we configure the corresponding Cisco Validated Design (CVD) best-practice configurations on a device-by-device basis to achieve that intent.
As such, we don't expose when/where to trust, mark/remark, queue, drop, etc. These policy-actions are all abstracted.
That being said, if the operator wants a specific app from a specific port to be treated with end-to-end QoS, they can configure a Custom Application that specifies the source and/or destination address (and/or source + destination ports, etc.). The operator would also designate what kind of application it is (either by specifying "voice", "bulk-data" etc. or by selecting an application that it is "SIMILAR TO"). At this point EasyQoS would properly classify, mark and queue the app based on standards-based CVD best-practices.