Why still QOS marking when voice is marked EF by default?

[Maivoko]

1.except auto qos, Why still QOS marking when voice is marked EF by default?

which are not marked? where can find default marking which things it can mark by default? 

for example port 445 file copy traffic , is there default marking for this traffic?

2. if apply pre cos classify in GRE and IPSec , will it have service interruption when apply the commands?

3. if apply auto qos discovery for 7 days, what will be influenced and impacted within these 7 days?

4. As I know , auto qos discovery applied at CE routers, CE router usually managed by ISP, is this command to apply in CE router or ASR router ?, is there need to make firewall allow this discovery traffic to access switch auto qos? what are the policy rules in firewall to allow this traffic? is it only need to allow NBar application traffic?

5. COS to DSCP matched well with CS to DSCP value, does it mean no need to change this table?

if need to change , what reason for this change? is this table exist by default or need to type default commands to make it apply ?

[balaji.bandi]

what model of the device and IOS code running ?

can you post sample QOS config ?

[M02@rt37]

Hello @Maivoko,

1-While voice traffic is marked as EF by default, not all devices and applications honor these markings. Some devices and applications might not prioritize or treat EF-marked traffic as expected. Additionally, there are other types of traffic that need proper marking for effective QoS, such as video, signaling, and network control traffic. 

Auto QoS and other QoS mechanisms help ensure consistent and effective QoS across the network.

The default markings depend on the device and platform. Cisco devices often use the DSCP values to classify and mark traffic. For specific protocols like file copy traffic (e.g., port 445 for SMB), the default markings might vary depending on the platform and configuration.

2-Applying a pre-classify configuration in GRE and IPSec tunnels should not cause service interruption. Pre-classification involves marking packets before encryption, allowing the remote device to interpret the markings.

3-Applying "auto qos discovery" for 7 days enables the router to analyze traffic patterns and apply appropriate QoS settings based on the observed traffic behavior. During this period, there might be a slight impact on router performance as it collects and analyzes traffic data.

4-"auto qos discovery" is typically applied on the CE routers. This command helps the router identify the applications and their QoS requirements on the network. Firewalls and security policies should allow the necessary traffic for discovery, which might include NBAR-related traffic and other protocol-specific traffic that helps identify applications and their QoS needs.

5-While COS to DSCP mapping is important for end-to-end QoS, the default mappings might not always align perfectly with your network's needs. Depending on the application requirements and QoS policy, you might need to adjust the COS to DSCP mappings to achieve the desired QoS behavior. Default mappings exist, but you can modify them using QoS configuration commands to meet your network's specific QoS goals.

[Maivoko]

some people use AF 41 for voice traffic and AF 42 for video traffic, is it correct?

should video traffic have priority over voice?

some people configured COS 6,7 at queue 3 and COS 4,5 at queue 4 at the same time,

voice and video have priority over routing and networking traffic , is it correct improvement or wrong because impact routing and networking traffic?

[M02@rt37]

Hello @Maivoko,

Using AF 41 for voice traffic and AF 42 for video traffic is a valid approach, but whether it's correct depends on your network's requirements and the applications you're prioritizing. Voice and video traffic are both latency-sensitive, so giving them higher priority with appropriate DSCP values is a common practice. However, whether video traffic should have priority over voice traffic depends on your organization's communication patterns and QoS goals.

Configuring COS 6 and 7 (or DSCP values corresponding to those COS values) at queue 3 and COS 4 and 5 at queue 4 indicates that you're prioritizing voice and video traffic over routing and networking traffic. This approach is in line with the idea of prioritizing real-time traffic to ensure a better user experience. However, you have to consider the overall impact on your network and the resources allocated to each queue.

Consider a balance between prioritizing important traffic and maintaining overall network health.

[Maivoko]

1.ACI spine and leaf case with 10 thousands users using Microsoft Teams in whole office hours non-stop

can Configuring COS 6 and 7 (or DSCP values corresponding to those COS values) at queue 3 and COS 4 and 5 at queue 4 and Using AF 41 for voice traffic and AF 42 for video traffic  be better ?

2.Campus network case with 10 thousands users using Microsoft Teams in whole office hours non-stop

can Configuring COS 6 and 7 (or DSCP values corresponding to those COS values) at queue 3 and COS 4 and 5 at queue 4 and Using AF 41 for voice traffic and AF 42 for video traffic  be better ?

3.OSPF network case with 10 thousands users using Microsoft Teams in whole office hours non-stop

can Configuring COS 6 and 7 (or DSCP values corresponding to those COS values) at queue 3 and COS 4 and 5 at queue 4 and Using AF 41 for voice traffic and AF 42 for video traffic  be better ?

[Joseph W. Doherty]

#1 Other than manual or auto-QoS policies, that mark packets, I'm only aware of "older" Cisco switches, when QoS was enabled, would reset ToS (and Cos?) to zero unless the ingress was trusted or ingress policy was being used.

I.e. could provide a specific example, of where you see this unexpected marking?

#2 there might be some impact to "in-flight" packets.  In my experience, generally it's "unnoticed" but to be absolutely safe, such configuration changes should be limited to maintenance periods.

BTW, what's "pre cos classify"?  If you meant just "pre-classify", you believe you need this because?

3. Additional device resources, such as CPU and memory, will be used.  Possibly, over time, the most impacted would be memory, but much would depend on how the over time statistics are managed.

4.  Auto QoS Discovery applies to same device, specific interface.  Only if the device was running FW or ACL features, that might drop egress traffic, such might impact whether Auto QoS Discovery would still obtain data for that traffic, because even it it does, if traffic is blocked, it likely wouldn't impact effect of the Auto QoS policy generated.

5. Cannot say, as don't know how your environment uses CoS AND ToS.

Personally, I generally recommend don't bother with L2 CoS, at all, unless you cannot use L3 ToS and your really believe you need QoS at just L2.

Also, personally, I don't advocate using Auto QoS except if you're incapable or unwilling to learn QoS and you're only worried about QoS for apps like VoIP.  Auto Discovery QoS, for some reason, brings to mind the saying "putting lipstick on a pig".