{"id":3008,"date":"2026-10-08T12:08:49","date_gmt":"2026-10-08T12:08:49","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/cisco-300-415-qos-adaptive-shaping-cisco-sd-wan\/"},"modified":"2026-10-21T11:43:29","modified_gmt":"2026-10-21T11:43:29","slug":"cisco-300-415-qos-adaptive-shaping-cisco-sd-wan","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/cisco-300-415-qos-adaptive-shaping-cisco-sd-wan\/","title":{"rendered":"Cisco 300-415: QoS and Adaptive Shaping in Cisco SD-WAN"},"content":{"rendered":"

Quality of Service in Catalyst SD-WAN<\/a> is not one feature.<\/p>\n

It is a set of mechanisms that classify traffic, mark it, place it into queues, schedule transmission, shape the rate, police excess traffic, and\u2014in some designs\u2014adapt the shaper to changing WAN capacity.<\/p>\n

The current 300-415 ENSDWI<\/a> v1.2 blueprint explicitly includes QoS as part of Catalyst SD-WAN implementation.<\/p>\n

Start with classification and marking<\/h2>\n

QoS needs a way to distinguish traffic.<\/p>\n

Classification can use information such as protocol, application, source, destination, or existing packet markings.<\/p>\n

The policy can then preserve or change markings such as DSCP.<\/p>\n

A strong understanding of DSCP<\/a> is useful because DSCP values are a common way to communicate forwarding treatment across Layer 3 networks.<\/p>\n

Marking alone does not guarantee better performance.<\/p>\n

It tells QoS mechanisms how traffic should be treated when there is competition for bandwidth.<\/p>\n

Classification should be checked at the point where the policy actually runs. If the design depends on DSCP, verify whether upstream devices mark traffic correctly and whether any intermediate policy rewrites the value. If the design depends on application recognition, confirm the application is being identified consistently.<\/p>\n

A marking strategy also needs a trust boundary. Blindly trusting every endpoint-provided DSCP value lets an ordinary application claim premium treatment. Many enterprise designs classify or remark traffic at a controlled ingress point so downstream queues can trust the resulting code point.<\/p>\n

Queues separate classes during congestion<\/h2>\n

A router can place different traffic classes into separate queues.<\/p>\n

That gives the scheduler a way to treat delay-sensitive traffic differently from bulk traffic when the outgoing interface cannot transmit everything immediately.<\/p>\n

Without congestion, queueing policy may have little visible effect because the interface can forward all offered traffic.<\/p>\n

QoS becomes most important at the point where demand exceeds available capacity.<\/p>\n

QoS<\/a> provides the underlying classification, queueing, and congestion-management model; Catalyst SD-WAN applies those principles inside a centrally managed WAN policy framework.<\/p>\n

Queue depth and drop counters provide evidence about congestion. A class that never drops may not be the bottleneck even if users complain about the application. A class that persistently drops while another queue is empty may indicate a bandwidth allocation or classification problem.<\/p>\n

Priority service should be bounded. Real-time traffic benefits from low delay, but an oversized priority class can starve other queues and turn \u201cprotect voice\u201d into \u201clet anything marked voice dominate the link.\u201d Correct classification and realistic bandwidth allocation are inseparable.<\/p>\n

Scheduling decides which queue transmits next<\/h2>\n

Queuing separates traffic.<\/p>\n

Scheduling decides how the queues share the physical interface.<\/p>\n

A policy may provide strict priority to a limited class and weighted service to other queues.<\/p>\n

The design goal is not to make one application infinitely fast. It is to protect important traffic from being starved by other traffic during congestion.<\/p>\n

Too much priority traffic can defeat the purpose. If most packets are classified into the priority class, the network no longer has meaningful differentiation.<\/p>\n

QoS therefore depends as much on correct classification as on scheduler configuration.<\/p>\n

Schedulers express a service relationship among queues, not a guarantee that the WAN itself has infinite capacity. If a provider circuit or internet path can deliver less than the local interface speed, queueing only at line rate may move the real congestion point downstream where the enterprise cannot control which packets are dropped.<\/p>\n

That is why shaping and queuing are often designed together. The shaper creates an intentional egress rate, and the child queues decide which traffic gets protected when demand exceeds that rate.<\/p>\n

Shaping limits the sending rate smoothly<\/h2>\n

A shaper controls the rate at which traffic leaves an interface or tunnel.<\/p>\n

When offered load exceeds the configured rate, shaping typically buffers packets and releases them according to the allowed rate.<\/p>\n

That can reduce downstream drops when the physical or provider path has less usable capacity than the local interface can transmit.<\/p>\n

For example, a router may have a 1-Gbps Ethernet interface connected to a service that only permits 200 Mbps. Without appropriate shaping, the local interface can burst traffic faster than the provider path can sustain.<\/p>\n

The important point is that shaping creates an intentional bottleneck at a place where the enterprise can control queue behavior.<\/p>\n

Shaping introduces delay because excess traffic is buffered. That makes the configured rate and burst behavior important: a shaper set far below the usable circuit capacity can create unnecessary queueing, while a shaper set above the real bottleneck may fail to prevent provider-side drops.<\/p>\n

During troubleshooting, compare the configured shape rate with both the contracted service and observed path capacity. The Ethernet port speed is often the least useful number when the handoff is faster than the subscribed WAN service.<\/p>\n

Policing drops or remarks excess traffic<\/h2>\n

Policing enforces a traffic rate differently.<\/p>\n

When traffic exceeds the configured limit, a policer can drop or remark the excess rather than buffering it until later.<\/p>\n

That makes policing useful for enforcing a hard contract or limiting a class, but it can be harsher on bursty applications.<\/p>\n

Shaping and policing are therefore not interchangeable.<\/p>\n

A shaper delays excess traffic.<\/p>\n

A policer enforces the limit immediately.<\/p>\n

The appropriate mechanism depends on whether buffering is acceptable and where congestion should be controlled.<\/p>\n

A policer is appropriate when exceeding the rate should be treated as nonconforming behavior rather than temporarily buffered demand. Depending on configuration, excess traffic can be dropped or remarked to a lower service class.<\/p>\n

Because policing acts quickly, bursty TCP applications may experience loss and retransmission even when their long-term average rate seems acceptable. If the symptom is periodic loss at a precise rate threshold, inspect policer counters before assuming the WAN transport itself is congested.<\/p>\n

Per-tunnel QoS separates traffic by remote path<\/h2>\n

Catalyst SD-WAN can apply QoS at the tunnel level.<\/p>\n

That matters in hub-and-spoke designs where many remote sites share one physical WAN interface at the hub.<\/p>\n

A single parent interface queue does not automatically provide fair or predictable behavior for every overlay tunnel.<\/p>\n

Per-tunnel QoS can create more granular shaping and queueing for traffic associated with individual remote sites.<\/p>\n

This is a specifically SD-WAN concern because the physical interface can carry many logical overlay tunnels simultaneously.<\/p>\n

At a hub, many logical tunnels may share one physical interface. Without per-tunnel controls, one busy branch can consume a disproportionate share of the interface queue and affect other spokes. Per-tunnel QoS provides a way to shape or schedule traffic with the remote tunnel as part of the resource model.<\/p>\n

That does not remove the need for an aggregate parent policy. The physical interface still has a finite rate. A complete design considers the hierarchy: overall interface capacity, tunnel-level allocation, and application queues inside the traffic sent toward each remote site.<\/p>\n

Adaptive QoS handles changing WAN bandwidth<\/h2>\n

Cisco’s current documentation describes Adaptive QoS as a mechanism that adjusts WAN-interface and per-tunnel shaper rates based on measured available bandwidth.<\/p>\n

This is especially useful for transports whose usable capacity changes, such as internet or cellular connections.<\/p>\n

Cisco documents the feature as examining WAN loss and local shaper loss and adjusting the shaper rate upward or downward.<\/p>\n

The high-level logic is:<\/p>\n