350-401 Implementing QoS on its campus network Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The router does not trust the CoS marking and re-marks it to 0.

  Why it's wrong here

  The idea that the router 'does not trust' the CoS marking is a misconception. Trust refers to whether an interface accepts and forwards an inbound Layer 2 CoS value without modification, but even if the router fully trusts the CoS, that value exists only in the 802.1Q tag. Once the router performs a Layer 3 lookup and rewrites the Layer 2 header, the 802.1Q tag is stripped, so the CoS field is gone regardless of trust. Re-marking to 0 is not the root cause; the fundamental issue is that CoS cannot survive a Layer 3 hop.

• ✓

  CoS is a Layer 2 marking and is not carried across a Layer 3 hop; the router must map CoS to DSCP.

  Why this is correct

  CoS is a Layer 2 class-of-service field carried exclusively in the 802.1Q VLAN tag, so it is only meaningful on a single Layer 2 segment. When a router receives a frame, it de-encapsulates the Layer 2 header, including the 802.1Q tag, and then forwards the packet as a Layer 3 IP packet. The CoS value is therefore lost and cannot be preserved across a routed hop; the router must explicitly map the incoming CoS value to the IP DSCP field before routing. This mapping must occur at the ingress or before the Layer 3 forwarding decision to maintain end-to-end QoS priority.

• ✗

  The switch must be configured to set DSCP instead of CoS.

  Why it's wrong here

  Telling the switch to set DSCP instead of CoS does not address the core problem, because the issue is specifically that CoS is a Layer 2 marking that disappears at Layer 3. Even if the switch were configured to set DSCP, that DSCP value is carried in the IP header and would survive the Layer 3 hop, but the switch's configuration does not fix the router's inability to map CoS to DSCP. Furthermore, the switch may already be setting DSCP independently, and the real requirement is for the router to preserve or translate the existing CoS priority. The problem statement is about CoS loss, not about changing the marking source on the switch.

• ✗

  The router must have 'mls qos trust cos' configured on the interface.

  Why it's wrong here

  The command 'mls qos trust cos' is used on Cisco switches to make an ingress port trust the CoS value already present on received frames, which merely prevents the port from re-marking CoS to a default value on ingress. It does not solve the issue at hand because the router still strips the Layer 2 header when routing, and the CoS is not automatically mapped to DSCP. Even if the router trusts CoS, the trust operation only applies to the incoming interface's QoS processing; it does not carry the CoS across the Layer 3 boundary. The correct configuration is to explicitly map CoS to DSCP (for example, using a QoS policy or 'mls qos map cos-dscp') to preserve priority across the routed hop.

Go deeper

Related to this question