Sd Wan Architecture practice questions

A network administrator is comparing configuration management tools and wants to use one that is agentless, uses YAML for playbooks, and communicates with Cisco IOS XE devices over SSH. Which tool best meets these requirements?

Trap 1: Puppet

Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode with SSH for some modules. However, its manifests are written in a Ruby-based DSL, not YAML, and its primary model is agent-based. For Cisco network devices, Puppet support often relies on dedicated modules and may not be as straightforward for pure SSH-based configuration as the tool described.

Trap 2: Chef

Chef uses Ruby-based recipes and cookbooks, not YAML, and traditionally requires a Chef client agent on managed nodes. While Chef can manage network devices through specific resources, it does not natively use YAML for its configuration definitions. The requirement for agentless operation over SSH with YAML playbooks does not align with Chef's standard architecture.

Trap 3: SaltStack

SaltStack can operate in an agentless mode using SSH, but its default communication model uses a master-minion architecture with agents. Its configuration files are written in YAML, but the typical deployment for network devices often relies on proxy minions rather than direct SSH. The scenario emphasizes agentless SSH and YAML playbooks, which is more characteristic of Ansible's standard workflow.

A
Puppet
Why it fails: Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode with SSH for some modules. However, its manifests are written in a Ruby-based DSL, not YAML, and its primary model is agent-based. For Cisco network devices, Puppet support often relies on dedicated modules and may not be as straightforward for pure SSH-based configuration as the tool described.
B
Chef
Why it fails: Chef uses Ruby-based recipes and cookbooks, not YAML, and traditionally requires a Chef client agent on managed nodes. While Chef can manage network devices through specific resources, it does not natively use YAML for its configuration definitions. The requirement for agentless operation over SSH with YAML playbooks does not align with Chef's standard architecture.
C
SaltStack
Why it fails: SaltStack can operate in an agentless mode using SSH, but its default communication model uses a master-minion architecture with agents. Its configuration files are written in YAML, but the typical deployment for network devices often relies on proxy minions rather than direct SSH. The scenario emphasizes agentless SSH and YAML playbooks, which is more characteristic of Ansible's standard workflow.
D
Ansible
Ansible is agentless, connecting to devices over SSH, and uses YAML-formatted playbooks to define automation tasks. It includes modules such as ios_config and ios_command that specifically target Cisco IOS XE devices. This matches all stated requirements: no agent, YAML syntax, and SSH communication, making it the correct choice for this scenario.

Question 2easymultiple choice

A company is deploying a virtualized network function (VNF) for a Cisco CSR1000v router on a VMware vSphere hypervisor. The architect must choose the hypervisor type to ensure the best performance for the VNF. Which hypervisor type is VMware vSphere classified as, and why is it suitable for VNF deployment?

Trap 1: Type 2 hypervisor; it runs on top of an operating system, providing…

A Type 2 hypervisor relies on a host operating system for device drivers and resource scheduling, which adds significant CPU and I/O overhead. While it offers flexibility to run on commodity OSes, the extra layer makes it unsuitable for VNFs that need deterministic, multi-Gigabit throughput. In Cisco SD-WAN deployments, virtual edge routers are almost exclusively hosted on bare-metal hypervisors like ESXi or KVM, not on Type 2 environments.

Trap 2: Type 1 hypervisor; it requires a host OS for management, adding…

This option falsely claims that a Type 1 hypervisor requires a host OS for management. In reality, Type 1 hypervisors include a built-in management interface or run management tools as virtual appliances (e.g., VMware ESXi's vCenter, Xen's dom0) without a general-purpose host OS. Because there is no underlying OS, the hypervisor itself consumes fewer resources and avoids the overhead that this option incorrectly associates with the correct architecture.

Trap 3: Type 2 hypervisor; it is embedded in the hardware firmware.

Type 2 hypervisors are software packages that execute inside an existing OS, so they cannot be embedded in hardware firmware. Hardware firmware, such as UEFI, may provide virtualization extensions, but the hypervisor itself exists at the software layer of an installed OS. This choice confuses an embedded hypervisor (typically Type 1, like Xen or a system management firmware) with a hosted Type 2 hypervisor, and it is fundamentally wrong for the virtualized SD-WAN control plane.

A
Type 2 hypervisor; it runs on top of an operating system, providing flexibility for VNF management.
Why it fails: A Type 2 hypervisor relies on a host operating system for device drivers and resource scheduling, which adds significant CPU and I/O overhead. While it offers flexibility to run on commodity OSes, the extra layer makes it unsuitable for VNFs that need deterministic, multi-Gigabit throughput. In Cisco SD-WAN deployments, virtual edge routers are almost exclusively hosted on bare-metal hypervisors like ESXi or KVM, not on Type 2 environments.
B
Type 1 hypervisor; it runs directly on the hardware, offering near-native performance for VNFs.
The correct answer is a Type 1 hypervisor because it runs directly on the physical hardware, giving VNFs direct access to CPU, memory, and NIC queues. This architecture minimizes latency and enables high-performance features like SR-IOV and DPDK, which are critical for SD-WAN edge devices handling real-time traffic. Cisco SD-WAN virtual appliances (vEdge, vSmart) are validated on ESXi and KVM, both Type 1 hypervisors, to guarantee near-native packet forwarding.
C
Type 1 hypervisor; it requires a host OS for management, adding overhead.
Why it fails: This option falsely claims that a Type 1 hypervisor requires a host OS for management. In reality, Type 1 hypervisors include a built-in management interface or run management tools as virtual appliances (e.g., VMware ESXi's vCenter, Xen's dom0) without a general-purpose host OS. Because there is no underlying OS, the hypervisor itself consumes fewer resources and avoids the overhead that this option incorrectly associates with the correct architecture.
D
Type 2 hypervisor; it is embedded in the hardware firmware.
Why it fails: Type 2 hypervisors are software packages that execute inside an existing OS, so they cannot be embedded in hardware firmware. Hardware firmware, such as UEFI, may provide virtualization extensions, but the hypervisor itself exists at the software layer of an installed OS. This choice confuses an embedded hypervisor (typically Type 1, like Xen or a system management firmware) with a hosted Type 2 hypervisor, and it is fundamentally wrong for the virtualized SD-WAN control plane.

Question 3easymultiple choice

A company is deploying Cisco DNA Center and wants to use streaming telemetry from its network devices to provide real-time visibility. The network consists of Cisco Catalyst 9000 switches running IOS-XE. The engineer needs to configure the devices to stream telemetry data to DNA Center. Which protocol should the engineer use for the telemetry transport?

Trap 1: NetFlow v9.

NetFlow v9 is incorrect because it is a flow-export protocol designed specifically for recording and exporting IP traffic statistics, such as source/destination addresses, ports, and byte counts. It does not carry device health information like interface counters, CPU load, or memory usage, which are central to system telemetry. DNA Center's streaming telemetry is based on YANG-modeled data over gRPC, not NetFlow's UDP-based flow records.

Trap 2: SNMPv3.

SNMPv3 is incorrect because it operates on a pull-based model where a management station must poll device OIDs to retrieve data, making it inefficient for high-frequency, real-time telemetry. While SNMP supports traps/informs for notifications, these are limited in structure and frequency compared to the continuous, subscription-based streaming that DNA Center requires. Modern telemetry pushes data proactively via gRPC, whereas SNMP always relies on a request-response exchange or sparse trap events.

Trap 3: Syslog.

Syslog is incorrect because it is designed for unstructured or semi-structured event messages, primarily for logging and troubleshooting, not for structured, high-frequency numerical telemetry. Syslog messages are typically sent via UDP without guaranteed delivery, and there is no subscription mechanism to receive continuous updates of interface counters or system health. DNA Center's telemetry solution depends on YANG-defined data models and gRPC's reliable, ordered streaming, which syslog cannot provide.

A
gRPC (Google Remote Procedure Call).
gRPC (Google Remote Procedure Call) is the correct answer because Cisco DNA Center leverages model-driven telemetry, and gRPC is the standard transport for that telemetry. It uses protocol buffers to encode structured YANG data and supports high-frequency, push-based subscriptions over HTTP/2. This allows DNA Center to stream interface counters, CPU/memory utilization, and other operational state from devices in near real-time, eliminating the need for repeated polling.
B
NetFlow v9.
Why it fails: NetFlow v9 is incorrect because it is a flow-export protocol designed specifically for recording and exporting IP traffic statistics, such as source/destination addresses, ports, and byte counts. It does not carry device health information like interface counters, CPU load, or memory usage, which are central to system telemetry. DNA Center's streaming telemetry is based on YANG-modeled data over gRPC, not NetFlow's UDP-based flow records.
C
SNMPv3.
Why it fails: SNMPv3 is incorrect because it operates on a pull-based model where a management station must poll device OIDs to retrieve data, making it inefficient for high-frequency, real-time telemetry. While SNMP supports traps/informs for notifications, these are limited in structure and frequency compared to the continuous, subscription-based streaming that DNA Center requires. Modern telemetry pushes data proactively via gRPC, whereas SNMP always relies on a request-response exchange or sparse trap events.
D
Syslog.
Why it fails: Syslog is incorrect because it is designed for unstructured or semi-structured event messages, primarily for logging and troubleshooting, not for structured, high-frequency numerical telemetry. Syslog messages are typically sent via UDP without guaranteed delivery, and there is no subscription mechanism to receive continuous updates of interface counters or system health. DNA Center's telemetry solution depends on YANG-defined data models and gRPC's reliable, ordered streaming, which syslog cannot provide.

Read the full wireless explanation →

Question 4hardmultiple choice

A network engineer is designing a Cisco SD-Access fabric for a campus network. The fabric must support both wired and wireless clients, and the engineer wants to ensure that traffic from wired endpoints is encapsulated and forwarded through the fabric without requiring the endpoints to change their IP addresses. Which component of the SD-Access architecture is responsible for encapsulating traffic from wired endpoints and forwarding it to the fabric edge?

Trap 1: Control plane node

The control plane node maintains the mapping of endpoint identities to fabric edge nodes using LISP. It does not encapsulate or forward data traffic from wired endpoints. Its role is to provide the control plane database for endpoint location, not to perform VXLAN encapsulation of user traffic.

Trap 2: Fabric intermediate node

The fabric intermediate node is a Layer 3 underlay device that forwards VXLAN-encapsulated traffic between fabric edge and border nodes. It does not encapsulate traffic from wired endpoints; it only transports the encapsulated packets based on the outer IP header. It has no knowledge of endpoint identities or fabric encapsulation functions.

Trap 3: Fabric border node

The fabric border node connects the SD-Access fabric to external networks such as the data center or WAN. It does not encapsulate traffic from wired endpoints; instead, it handles traffic entering or leaving the fabric. While it may de-encapsulate VXLAN traffic for external destinations, it is not the first point of encapsulation for wired endpoints.

A
Control plane node
Why it fails: The control plane node maintains the mapping of endpoint identities to fabric edge nodes using LISP. It does not encapsulate or forward data traffic from wired endpoints. Its role is to provide the control plane database for endpoint location, not to perform VXLAN encapsulation of user traffic.
B
Fabric edge node
The fabric edge node is responsible for encapsulating traffic from wired endpoints using VXLAN and forwarding it to the fabric. It acts as the first-hop router for endpoints and registers them with the control plane node. This component is essential for wired client integration in SD-Access, as it provides the anycast gateway and encapsulation functions.
C
Fabric intermediate node
Why it fails: The fabric intermediate node is a Layer 3 underlay device that forwards VXLAN-encapsulated traffic between fabric edge and border nodes. It does not encapsulate traffic from wired endpoints; it only transports the encapsulated packets based on the outer IP header. It has no knowledge of endpoint identities or fabric encapsulation functions.
D
Fabric border node
Why it fails: The fabric border node connects the SD-Access fabric to external networks such as the data center or WAN. It does not encapsulate traffic from wired endpoints; instead, it handles traffic entering or leaving the fabric. While it may de-encapsulate VXLAN traffic for external destinations, it is not the first point of encapsulation for wired endpoints.

Question 5hardmultiple choice

A network engineer is designing a high-availability solution for a data center using Cisco Application Centric Infrastructure (ACI). The engineer wants to ensure that the fabric can continue to operate if a spine switch fails, and that traffic is load-balanced across all available paths. Which statement accurately describes the ACI fabric architecture?

Trap 1: ACI uses a single spine switch for all traffic, and redundancy is…

ACI does not use a single active spine with a standby. All spine switches are active and forward traffic simultaneously. The fabric is designed for active-active operation, and there is no standby spine. This option misrepresents the ACI architecture and its high-availability model.

Trap 2: ACI uses a traditional Spanning Tree Protocol (STP) to prevent…

ACI does not use STP; it uses a spine-leaf architecture with an overlay protocol (VXLAN) and a distributed control plane (IS-IS). The fabric is designed for high availability, and a failed spine switch does not cause a full outage. STP is not part of the ACI fabric forwarding model.

Trap 3: ACI uses a ring topology for the fabric, and a failed spine switch…

ACI does not use a ring topology; it uses a spine-leaf topology. A ring would be used in some other architectures, but not in ACI. In ACI, the spine layer is a full mesh with the leaf layer, and a spine failure does not break connectivity because other spines are available.

A
ACI uses a spine-leaf topology where every leaf connects to every spine, and a failed spine switch reduces capacity but does not cause an outage.
In ACI, leaf switches connect to all spine switches, forming a full-mesh at the spine level. If a spine fails, the remaining spines continue to forward traffic, so the fabric remains operational. This provides high availability and load balancing across all available paths, meeting the design requirements.
B
ACI uses a single spine switch for all traffic, and redundancy is achieved through a standby spine that takes over on failure.
Why it fails: ACI does not use a single active spine with a standby. All spine switches are active and forward traffic simultaneously. The fabric is designed for active-active operation, and there is no standby spine. This option misrepresents the ACI architecture and its high-availability model.
C
ACI uses a traditional Spanning Tree Protocol (STP) to prevent loops, and a failed spine switch causes a full fabric outage.
Why it fails: ACI does not use STP; it uses a spine-leaf architecture with an overlay protocol (VXLAN) and a distributed control plane (IS-IS). The fabric is designed for high availability, and a failed spine switch does not cause a full outage. STP is not part of the ACI fabric forwarding model.
D
ACI uses a ring topology for the fabric, and a failed spine switch breaks the ring, causing a partial outage.
Why it fails: ACI does not use a ring topology; it uses a spine-leaf topology. A ring would be used in some other architectures, but not in ACI. In ACI, the spine layer is a full mesh with the leaf layer, and a spine failure does not break connectivity because other spines are available.

Question 6easymultiple choice

A network engineer is new to automation and wants to use a simple, agentless tool to push configuration changes to a group of Cisco IOS XE switches. The engineer prefers to write the automation tasks in YAML and does not want to install any software on the switches. Which tool should be used?

Trap 1: Puppet

Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode using SSH for some modules. However, its configuration is written in a domain-specific language (DSL) rather than YAML, and it is more complex for simple configuration pushes. The scenario specifies agentless and YAML, which aligns better with Ansible.

Trap 2: SaltStack

SaltStack can operate in an agentless mode using SSH, but its primary configuration is written in YAML for states, yet it often requires a master and minion architecture. For network devices, it may need additional setup. Ansible is more commonly used for agentless network automation with YAML and has extensive Cisco module support.

Trap 3: Chef

Chef uses a Ruby-based DSL for defining configurations and generally requires a Chef client (agent) on managed nodes. While it can use SSH for some tasks, it is not primarily agentless and does not use YAML for playbooks. The engineer's preference for YAML and no agent installation points away from Chef.

A
Puppet
Why it fails: Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode using SSH for some modules. However, its configuration is written in a domain-specific language (DSL) rather than YAML, and it is more complex for simple configuration pushes. The scenario specifies agentless and YAML, which aligns better with Ansible.
B
Ansible
Ansible is an agentless automation tool that uses YAML-based playbooks to define tasks. It connects to network devices via SSH or other protocols without requiring any software installation on the managed devices. This matches the engineer's requirements: simple, agentless, and YAML-based configuration management for Cisco IOS XE switches.
C
SaltStack
Why it fails: SaltStack can operate in an agentless mode using SSH, but its primary configuration is written in YAML for states, yet it often requires a master and minion architecture. For network devices, it may need additional setup. Ansible is more commonly used for agentless network automation with YAML and has extensive Cisco module support.
D
Chef
Why it fails: Chef uses a Ruby-based DSL for defining configurations and generally requires a Chef client (agent) on managed nodes. While it can use SSH for some tasks, it is not primarily agentless and does not use YAML for playbooks. The engineer's preference for YAML and no agent installation points away from Chef.

Read the full MPLS explanation →

Question 7mediummultiple choice

A network architect is designing the QoS architecture for a Cisco SD-WAN deployment that carries voice, video, and data traffic across MPLS and Internet transports. The design must use a consistent DiffServ marking strategy across all transports and ensure that voice traffic is prioritized over video. Which QoS policy type and marking approach should the architect use?

Trap 1: Use localized QoS policies on each WAN edge router with CoS…

Per-device localized QoS policies configured directly on each WAN edge router create a management and operational split from the SD-WAN controller. Because the markings are based on the transport type, the same application could receive different CoS (802.1p) values on MPLS versus Internet links, breaking any consistent end-to-end quality strategy. Moreover, Layer 2 CoS bits are not preserved through IPsec tunnels or across the provider network, so they are a poor choice for an IP-based SD-WAN fabric. Centralized policy is required to ensure uniform classification and queue treatment across all sites and transports.

Trap 2: Use MPLS EXP markings for MPLS transport and IP Precedence for…

Using MPLS EXP bits on the MPLS transport and IP Precedence on the Internet transport forces the SD-WAN policy to depend on the transport medium rather than the application, which defeats the purpose of a unified QoS strategy. MPLS EXP is a Layer 2.5 shim header that is typically overwritten or re-marked by the provider's ingress router, while IP Precedence has only 8 values, far less granular than the 64 DSCP classes available for application classification. Since the same traffic would be marked differently on each transport, forwarding decisions and per-hop behaviors would be inconsistent, causing voice or video to be treated differently depending on the selected circuit. This fragmentation makes troubleshooting and SLA enforcement extremely difficult and does not align with centralized SD-WAN policy design.

Trap 3: Use NBAR2 to automatically classify traffic and apply markings…

NBAR2 is a local classification mechanism that inspects application signatures on the device itself, but it does not provide a centralized, fabric-wide QoS policy in the SD-WAN architecture. Running NBAR2 per router would require independent configuration and tuning on every edge device, and the classification outcome (the assigned markings) would still need to be tied to a local policy, which can drift between devices and lacks vManage’s centralized enforcement and monitoring. Additionally, NBAR2 performance impact and the difficulty of guaranteeing identical application signatures across different software versions make it unsuitable as the primary QoS policy mechanism. In SD-WAN, centralized policy is applied from the controller; NBAR2 could be used as an optional local classification tool, but not as the sole source of QoS marking.

A
Use localized QoS policies on each WAN edge router with CoS markings based on the transport type.
Why it fails: Per-device localized QoS policies configured directly on each WAN edge router create a management and operational split from the SD-WAN controller. Because the markings are based on the transport type, the same application could receive different CoS (802.1p) values on MPLS versus Internet links, breaking any consistent end-to-end quality strategy. Moreover, Layer 2 CoS bits are not preserved through IPsec tunnels or across the provider network, so they are a poor choice for an IP-based SD-WAN fabric. Centralized policy is required to ensure uniform classification and queue treatment across all sites and transports.
B
Use a centralized QoS policy that marks traffic with DSCP and applies per-queue shaping on the WAN edge.
A centralized QoS policy, defined in vManage and pushed to all WAN edge routers, is the correct SD-WAN approach because it applies identical DSCP marking rules regardless of the underlying transport. DSCP operates at the IP layer, so it can be preserved across IPsec tunnels by instructing the tunnel to copy the outer TOS field, allowing service providers and remote routers to honor priority markings. The per-queue shaping component uses scheduling constructs such as strict priority for voice and a separate bandwidth pool for video, ensuring that real-time traffic receives predictable latency and jitter even when a transport link is congested. This transport-independent, centrally managed model is the foundation of Cisco SD-WAN QoS.
C
Use MPLS EXP markings for MPLS transport and IP Precedence for Internet transport.
Why it fails: Using MPLS EXP bits on the MPLS transport and IP Precedence on the Internet transport forces the SD-WAN policy to depend on the transport medium rather than the application, which defeats the purpose of a unified QoS strategy. MPLS EXP is a Layer 2.5 shim header that is typically overwritten or re-marked by the provider's ingress router, while IP Precedence has only 8 values, far less granular than the 64 DSCP classes available for application classification. Since the same traffic would be marked differently on each transport, forwarding decisions and per-hop behaviors would be inconsistent, causing voice or video to be treated differently depending on the selected circuit. This fragmentation makes troubleshooting and SLA enforcement extremely difficult and does not align with centralized SD-WAN policy design.
D
Use NBAR2 to automatically classify traffic and apply markings based on application signatures.
Why it fails: NBAR2 is a local classification mechanism that inspects application signatures on the device itself, but it does not provide a centralized, fabric-wide QoS policy in the SD-WAN architecture. Running NBAR2 per router would require independent configuration and tuning on every edge device, and the classification outcome (the assigned markings) would still need to be tied to a local policy, which can drift between devices and lacks vManage’s centralized enforcement and monitoring. Additionally, NBAR2 performance impact and the difficulty of guaranteeing identical application signatures across different software versions make it unsuitable as the primary QoS policy mechanism. In SD-WAN, centralized policy is applied from the controller; NBAR2 could be used as an optional local classification tool, but not as the sole source of QoS marking.

Study the full QoS explanation →

Question 8mediummultiple choice

An enterprise is designing a QoS architecture for its WAN edge routers connecting to multiple service providers. The design must support traffic shaping to avoid packet drops due to provider policers, while also prioritizing real-time traffic. Which approach should the architect use to shape traffic to the contracted CIR while still allowing bursts?

Trap 1: Use a policer on the ingress interface to drop traffic exceeding…

Ingress policing (e.g., `police` in Cisco IOS) measures traffic and either drops or re-marks packets that exceed the configured rate, but it does not queue excess traffic. Since the goal is to keep traffic within the provider's CIR without causing drops, a policer on the ingress interface is inappropriate—it would discard legitimate bursts instead of buffering them. Policing on ingress might protect the router itself, but it does not address outbound shaping to the provider, so it fails to meet the requirement.

Trap 2: Configure a shaper on the provider's device instead of the customer…

Managing the provider's device is not possible because it lies outside the customer's administrative control; service-provider equipment is configured by the provider, and the customer cannot install or tune a shaper on it. Even if the provider offers shaping as a managed service, the customer cannot rely on such an implementation here—the correct practice is to shape on the customer edge router, specifically on the egress interface facing the provider. This is the only location where the customer can guarantee the shaping policy matches the contract, since it is under their direct control.

Trap 3: Set the interface bandwidth to the CIR and rely on FIFO queuing.

The `bandwidth` command simply sets a metric value for routing protocols and influences queueing calculations—it does not rate-limit, buffer, or pace actual traffic. FIFO queueing without a shaper means bursts are transmitted as fast as the physical interface allows, so traffic can exceed the CIR and be dropped by the provider's policer. Even if the interface's `bandwidth` equals the CIR, the router does not use that value to enforce a rate, which is why shaping is necessary for contract compliance.

A
Apply a shape average policy on the egress interface of the WAN edge router, setting the CIR and burst parameters to match the provider contract.
Shape average on the egress interface uses a token bucket to constrain the long-term average traffic rate to the CIR while permitting short bursts up to the configured Bc (and optionally Be). Unlike a policer, the shaper queues excess packets so they are transmitted later, which smooths traffic sent toward the provider and prevents the provider's ingress policer from seeing micro-bursts that trigger tail drops. Matching the CIR and burst parameters to the provider contract ensures the shaped output stays within the contracted traffic profile, making this the only option that actively enforces the committed rate while preserving burst absorption.
B
Use a policer on the ingress interface to drop traffic exceeding the CIR.
Why it fails: Ingress policing (e.g., `police` in Cisco IOS) measures traffic and either drops or re-marks packets that exceed the configured rate, but it does not queue excess traffic. Since the goal is to keep traffic within the provider's CIR without causing drops, a policer on the ingress interface is inappropriate—it would discard legitimate bursts instead of buffering them. Policing on ingress might protect the router itself, but it does not address outbound shaping to the provider, so it fails to meet the requirement.
C
Configure a shaper on the provider's device instead of the customer router.
Why it fails: Managing the provider's device is not possible because it lies outside the customer's administrative control; service-provider equipment is configured by the provider, and the customer cannot install or tune a shaper on it. Even if the provider offers shaping as a managed service, the customer cannot rely on such an implementation here—the correct practice is to shape on the customer edge router, specifically on the egress interface facing the provider. This is the only location where the customer can guarantee the shaping policy matches the contract, since it is under their direct control.
D
Set the interface bandwidth to the CIR and rely on FIFO queuing.
Why it fails: The `bandwidth` command simply sets a metric value for routing protocols and influences queueing calculations—it does not rate-limit, buffer, or pace actual traffic. FIFO queueing without a shaper means bursts are transmitted as fast as the physical interface allows, so traffic can exceed the CIR and be dropped by the provider's policer. Even if the interface's `bandwidth` equals the CIR, the router does not use that value to enforce a rate, which is why shaping is necessary for contract compliance.