Cisco MLS and MQC QoS – trust cos/dscp

ciscoqosroutingswitchswitching

A question about Cisco MLS and MQC QoS.

I read two things on a Cisco guide: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/118629-technote-qos-00.html

On the 3750, by default the QoS is disabled whereas on the 3850, it is
enabled. Also in order to preserve Layer 2 (L2)/Layer 3 (L3) QoS
marking on the 3750 platform, a trust configuration must be applied.

In the case of the 3850, all packets by default are trusted (the L2/L3
QoS marking is preserved), unless you change it with an application of
a specific policy map on the ingress or egress interface.

And, to perform a trust cos in a MQC model in Ingress:

Ingress: apply policy-map trust-cos Ingress policy:

3850#show run policy-map trust-cos 
class class-default
   set cos cos table default

3850#show table-map default
 Table Map default
    default copy

So the question, the guide explain that the trust cos/dscp is enabled by default on the MQC QoS model, but the guide explain how to apply a trust cos/dscp in ingress interface in MQC, so, what's true ?

Best Answer

I agree, that looks contradictory. For the DSCP case it says "Ingress: default trust dscp, no policy needed" but for the CoS case it says "Ingress: apply policy-map trust-cos".

You can ask Cisco to clarify their documentation, but rather than wait for a clarification, you can go ahead and implement an explicit input policy anyway. Configuring an explicitly defined policy is probably better than depending on some poorly documented implicit behaviour, and is also more portable across multiple devices/software releases.

If you want to trust the incoming CoS, use a table-map that maps 1 to 1, 2 to 2 and so on. This is what the example in the documentation ("trust-cos" policy map) does.

If you do not want to trust the incoming CoS, use a policy-map that sets the cos to 0 unconditionally.

policy-map no-trust-cos
 class class-default
  set cos default

(or set cos 0)

Similarly for trusting/not trusting DSCP.

Related Solutions

Cisco – Enabling MLS QoS on a production 7600

You definitely should enable MLS QoS. It is also prerequisite for CoPP, which you should add in your TODO list to implement.

Enabling 'mls qos' without other config is extremely bad idea in low-end cats, like 3560/3750, due to unexpected default scheduling and due to heavily reduced buffers causing more microbursting.

On 7600/6500 it's comparatively safe to enable, but of course you can crash your router with 'show run'. I would feel comfortable enough to enable it during production hours.

You should monitor 'show queueing interface X' after enabling to see that you're not dropping anything. Long term, you should design QoS policy and implement it, I recommend using as few queues as possible (and assign 100% of buffer to those few queues). Example of possible QoS policy in WS-X6704-10GE:

interface TenGigabitEthernet4/1
 wrr-queue bandwidth percent 30 40 30 0 0 0 0  ## allocate 3 queues (+implied strictpriority) share buffer 30% 40% 30% on thos three queues
 wrr-queue cos-map 1 1 0 7 # map cos values to queues
 wrr-queue cos-map 2 2 3 
 wrr-queue cos-map 3 1 4 
 wrr-queue cos-map 3 2 6

For advanced config, you may want to supplement that with 'wrr-queue random-detect' with RED curve per queue+threshold. Be sure to mark your traffic correctly when it enters your network.

DSCP trust over IPSec GRE

I just stumbled across this old one showing up as related, and wanted to answer, for having been in that situation more than once.

No need for trust configuration on cisco routers like ISR G1 (18xx/28xx/38xx), G2 (19xx/29xx/39xx) or ISR 4000 series - and probably older ones, too.

As long as there is no inbound QoS policies that would classifiy and (re)mark the packets, they will leave the ToS byte alone.

Usually, the to-be-encapsulated packet's ToS Byte (including DSCP) is copied out to the encapsulating headers.

Also see https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/IPSecQoS.pdf

Chapter "ToS Byte preservation" (Page 6-12):

To overcome this predicament, the IPSec protocol standards inherently have provisioned the capability to preserve the ToS byte information of the original IP header by copying it to the IP headers added by the tunneling and encryption process.

QoS Preclassification is also explained right there. In a nutshell: with QoS preclassify, every to-be-encrypted data packet gets a companion data structure in router memory that holds information from the original packet. Egress QoS policies then queue/schedule the encrypted packet properly, based on the data from the companion data instead of the encapsulated/encrypted (and therefore inaccessible) original packet.

If I understand your case correctly, default-active ToS byte preservation and an egress policy on the tunnel interface should work pretty nicely, making sure that the packets leave the router in the order you intend them to.

However, it may be that the metro ethernet or the WAN service provider might not trust the dscp markings in the outermost IP headers and might nullify them. That may be of minor concern for two reasons:

the packets left the router after queuing/scheduling, in the order you wanted them to. If your egress policy includes proper shaping to just-under-the-SP's thresholds, the SP's devices won't need to queue/reschedule.
the remote tunnel endpoint will start do decapsulate the incoming packet. First step will be to discard the outermost IP header with the possibly nullified ToS byte. No harm done, the next IP Header will still have the original ToS byte with the DSCP field.

Best Answer

Related Solutions

Cisco – Enabling MLS QoS on a production 7600

DSCP trust over IPSec GRE

Related Topic