Media And Qos practice questions

show dial-peer voice

Why it fails: This shows dial-peer status, not media resource registration.

show media resources

Why it fails: This is not a valid IOS command for media resource status.

show voice gateway status

Why it fails: This is not a standard IOS command.

To limit the bandwidth consumed by a call.

Why it fails: Bandwidth management is controlled by Regions and Locations, not MTPs.

To provide codec transcoding services.

Why it fails: Transcoders provide transcoding; MTPs primarily handle signaling/DTMF compatibility.

To cache video streams for faster playback.

Why it fails: MTPs do not perform video caching.

Set the Region codec to 'G.711 to G.729' explicitly.

Why it fails: Regions define codec preferences, they do not trigger transcoding functionality.

Enable 'Allow Transcoding' in the Service Parameters.

Why it fails: Transcoding is managed via MRGL/MRG/MRHP structures, not global service parameters.

Configure the IOS gateway as a Media Termination Point (MTP) only.

Why it fails: An MTP is not sufficient if transcoding is required; a dedicated Transcoder resource is needed.

set ip dscp ef

Why it fails: The 'ip' keyword is not required and is syntactically incorrect for 'set dscp'.

mark dscp 46

Why it fails: 'mark' is not a valid command within a policy-map class.

set dscp voice

Why it fails: 'voice' is not a valid keyword for the set dscp command.

The voice traffic is taking up all bandwidth

Why it fails: Voice typically uses a small, defined bandwidth percentage in LLQ.

The router's CPU is overloaded

Why it fails: CPU load affects control plane performance, not media flow prioritization.

The interface is configured for full-duplex

Why it fails: Full-duplex is standard for modern networks and does not cause drops.

priority trust dscp

Why it fails: This command does not exist.

trust dscp

Why it fails: The correct syntax is 'qos trust dscp'.

mls qos trust dscp

Why it fails: This is an older syntax primarily used on legacy Catalyst switches.

Audio Bandwidth Parameter

Why it fails: This is not a specific service parameter.

Maximum Audio Bitrate

Why it fails: Not a service parameter setting.

System-wide QoS policy

Why it fails: QoS is configured on routers, not via a service parameter for bandwidth.

rate-limit [kbps]

Why it fails: 'rate-limit' is for policing, not bandwidth reservation.

guarantee [kbps]

Why it fails: 'guarantee' is not a valid command.

priority bandwidth

Why it fails: 'priority' is a separate command from 'bandwidth'.

Best effort queuing

Why it fails: Voice cannot rely on best effort.

Strict Priority Queuing (PQ) without bandwidth limits

Why it fails: PQ must always have a bandwidth limit to prevent starvation.

Weighted Random Early Detection (WRED)

Why it fails: WRED is not suitable for voice traffic (it drops packets).

They are optional for all deployments

Why it fails: Locations are required for effective call admission control.

They are used to define codec preferences

Why it fails: Regions define codec preferences, not locations.

They define the gatekeeper address

Why it fails: Gatekeepers are configured separately from locations.

RTCP

Why it fails: RTCP is for control/stats, not call signaling.

RTP

Why it fails: RTP is media, not signaling.

SCCP

Why it fails: While SCCP is a signaling protocol, SIP and H.323 are the most common in modern environments; however, SCCP is technically valid, but SIP and H.323 are the primary ones tested.

Use the set ip dscp ef command in a route-map and apply it to the WAN interface outbound to mark voice traffic.

Why it fails: Route-maps are used for routing policy, not for QoS marking. While route-maps can set IP precedence or DSCP in some contexts, they are not the correct tool for marking voice traffic at the edge. Marking should be done with a policy-map and class-map. Additionally, applying marking outbound would be too late, as the service provider expects markings to be set before the packet leaves the customer network.

Configure a policy-map that sets DSCP to af41 for video traffic and cs3 for call signaling, and attach it to the ingress interface with service-policy input.

Why it fails: While this configuration correctly marks video and call signaling, the question requires marking voice bearer, call signaling, and video. This option only addresses video and call signaling, omitting voice bearer marking. Therefore, it does not fulfill all the marking requirements. The correct answers must include marking voice bearer as EF, which is not covered here.

Configure the mls qos trust dscp command on the ingress interface to trust incoming DSCP markings from the IP phone.

Why it fails: The mls qos trust dscp command is used on Cisco Catalyst switches to trust incoming DSCP markings, but it does not perform marking itself. On a Cisco IOS XE router, the equivalent command is not mls qos; instead, you use a policy-map to set DSCP values. Trusting incoming markings is unnecessary if the router is responsible for marking, and it would not ensure proper marking if the phone does not mark correctly.

AF31 (26)

Why it fails: AF31 is sometimes used for call signaling in some QoS designs, but Cisco recommends CS3 for call signaling. AF31 is typically used for streaming video or transactional data. Using AF31 for signaling may not align with Cisco's best practices and could lead to inconsistent treatment across the network.

EF (46)

Why it fails: EF is used for voice media, not call signaling. Marking signaling as EF would give it the same priority as voice, potentially causing unnecessary prioritization and congestion issues. Call signaling should use a lower priority than voice media to ensure that voice packets are always treated with the highest priority.

AF41 (34)

Why it fails: AF41 is used for interactive video, not call signaling. Marking signaling as AF41 would give it a higher priority than necessary and could interfere with video traffic. Call signaling requires a moderate priority, which CS3 provides.

match protocol rtp audio

Why it fails: NBAR protocol matching can recognize RTP audio, but it depends on deep packet inspection and payload signatures rather than the DSCP value the phones already set. In this scenario the engineer explicitly wants to classify by marking, and NBAR adds CPU overhead and may not recognize encrypted or new codec flows, so it does not meet the stated requirement.

match cos 5

Why it fails: The Class of Service field exists only in 802.1Q trunk tags at Layer 2, so a Layer 3 class-map on a routed WAN interface cannot evaluate it. Voice bearer is normally tagged CoS 5 on the access switch trunk, but by the time the packet is routed toward the service provider that tag is stripped, making this statement ineffective for selecting RTP on the routed WAN edge.

match access-group name VOICE-ACL

Why it fails: An access-group match classifies traffic by Layer 3 or Layer 4 header fields defined in an ACL, not by the DSCP marking. It would require enumerating every voice subnet and RTP port range, which is exactly the ACL-based approach the engineer wants to avoid, and it would not honor the markings the endpoints already apply.

show interfaces

Why it fails: The show interfaces command provides general interface statistics like packets input/output, errors, and drops, but it does not display QoS markings such as DSCP. It is not useful for verifying the DSCP value of voice packets.

show policy-map interface

Why it fails: The show policy-map interface command displays statistics for policies applied to interfaces, such as match counts and queue drops, but it does not show the DSCP value of individual packets. It is useful for verifying that classification is occurring, but not for directly seeing the DSCP marking of voice packets.

show mls qos interface

Why it fails: The show mls qos interface command displays QoS configuration and statistics for an interface, such as trust state and default CoS, but it does not show the DSCP value of specific packets. It can indicate whether the interface is trusting DSCP, but not the actual DSCP of received voice packets.

Configure Weighted Random Early Detection (WRED) on the voice class.

Why it fails: WRED is a congestion avoidance mechanism that drops packets based on queue depth and DSCP, but it is not typically applied to the voice class itself. Applying WRED to voice would be counterproductive because voice packets are all treated with the same priority and should not be randomly dropped. WRED is more suitable for data classes to prevent global synchronization.

Configure Low Latency Queueing (LLQ) with a strict priority and no policer.

Why it fails: Configuring LLQ with strict priority and no policer is exactly what the engineer already did, and it is causing poor voice quality. Without a policer, the priority queue can consume all available bandwidth during congestion, starving other queues and potentially causing voice packets to be dropped if the interface is oversubscribed. The solution is not to remove the policer but to ensure proper bandwidth allocation and policing.

Configure a priority queue with a policer to limit voice bandwidth.

Why it fails: A policer on the voice class would limit the amount of voice traffic that can enter the priority queue. While this can prevent voice from consuming too much bandwidth, it does not address the issue of data traffic starving the voice queue. In fact, if voice is already prioritized, the problem is likely that the priority queue is not getting enough service, not that it is consuming too much.

TCP 443 for signaling and UDP 8443 for media traversal

Why it fails: TCP 443 is the HTTPS port used for provisioning and administrative access, and UDP 8443 is not a standard Expressway media traversal port. Using these would not establish the required media path between the two servers and would break the expected traversal zone behavior.

UDP 5060 for signaling and a wide UDP port range for media

Why it fails: UDP 5060 is the unencrypted SIP signaling port and does not describe the traversal zone media transport. Opening a wide UDP range for media is exactly what the engineer wants to avoid, and it does not provide the single predictable transport required for a narrow firewall rule set between the two Expressway servers.

TCP 5061 for signaling and UDP 3478 for media traversal

Why it fails: TCP 5061 is used for SIP TLS signaling, and UDP 3478 is the STUN port used for NAT discovery, not for carrying the media between the internal and external Expressway. Neither port describes the single multiplexed media transport that the traversal zone should use for consistent firewall configuration.

Low Latency Queueing (LLQ) with a priority level of 10000 kbps for video

Why it fails: LLQ provides a strict priority queue, which would give video traffic absolute priority over all other classes. This could starve other critical traffic, such as voice signaling, and does not guarantee a minimum bandwidth percentage; it enforces a maximum rate. The requirement asks for a guaranteed 20% and burst up to 15 Mbps, which LLQ does not satisfy.

Class-Based Weighted Fair Queueing (CBWFQ) with a bandwidth guarantee of 10000 kbps and a burst size of 15000 bytes

Why it fails: CBWFQ allows specifying a burst size in bytes, but this only affects the token bucket for policing, not the actual bandwidth allocation. The bandwidth guarantee is a minimum rate, and burst size does not enable the class to exceed the guaranteed rate. The requirement is to burst up to 15 Mbps, which is a rate, not a byte size, so this option is incorrect.

Class-Based Weighted Fair Queueing (CBWFQ) with a bandwidth guarantee of 10000 kbps and a shape average of 15000 kbps

Why it fails: CBWFQ with a bandwidth guarantee provides a minimum bandwidth but does not allow bursting above the guaranteed rate. The shape average command would limit traffic to 15 Mbps, but it would not permit bursts above the guaranteed 10 Mbps. This configuration would either restrict video to 10 Mbps or incorrectly shape it to 15 Mbps, failing to meet the burst requirement.

A policy-map that matches on DSCP 0 and sets all traffic to EF, applied outbound on the WAN interface

Why it fails: This policy would mark all traffic as EF, which is incorrect because only voice media should be EF. Voice signaling should be CS3. Additionally, applying it outbound on the WAN would affect traffic leaving the router, not inbound traffic from the provider. The provider would likely ignore these markings anyway.

A policy-map that matches on IP precedence and sets DSCP CS3 for signaling and EF for media, applied inbound on the LAN interface

Why it fails: Applying the policy inbound on the LAN interface would mark traffic as it enters the router from the LAN, but the requirement is to re-mark traffic received from the WAN provider. Since the provider does not honor markings, the router must re-mark on the WAN interface inbound. This option would not affect traffic coming from the WAN.

A policy-map that matches on NBAR for SCCP and RTP, sets DSCP CS3 and EF respectively, and is applied outbound on the LAN interface

Why it fails: While NBAR can identify SCCP and RTP, applying the policy outbound on the LAN interface would mark traffic leaving the router toward the LAN. However, the requirement is to re-mark traffic arriving from the WAN provider before it enters the LAN. This would not re-mark inbound WAN traffic, so it is incorrect.

EF (46)

Why it fails: EF (DSCP 46) is used for voice media (RTP), not signaling. Marking signaling as EF would give it the same priority as voice payload, potentially causing congestion issues and delaying actual voice packets. Voice signaling requires less strict latency than media, so CS3 is more appropriate. Using EF for signaling is a common mistake that can degrade voice quality.

CS4 (32)

Why it fails: CS4 (DSCP 32) is sometimes used for streaming video or other applications but is not standard for voice signaling. Cisco recommends CS3 for signaling. CS4 would place signaling in a different queue, possibly with lower priority than needed for timely call setup. This misclassification can cause delays in call establishment during congestion.

AF41 (34)

Why it fails: AF41 (DSCP 34) is typically used for interactive video, not voice signaling. While both are real-time, video has different characteristics. Voice signaling is control traffic and should be marked CS3. Using AF41 for signaling would misclassify it and could lead to incorrect queuing treatment, potentially affecting call setup times.