City guest Wi-Fi bulk transfers share an uplink with ticket-window VoIP. Interpreting a CBWFQ-style policy, what outcome should staff expect under congestion?
Select an answer to reveal the explanation.
Short Explanation
CBWFQ is like labeled bins at a busy ticket window—voice gets a reserved lane, and guest bulk downloads get a smaller bin so they cannot shove the clerk aside when the line explodes.
Full Explanation
Class-Based Weighted Fair Queuing style policies allocate congestion behavior by class rather than treating every flow as equal FIFO noise. On a city guest Wi-Fi uplink that also carries ticket-window VoIP, staff should expect configured queues to receive bandwidth shares or priority treatment so voice can be protected while bulk guest transfers are constrained to their assigned class. That outcome is the practical reading of CBWFQ-style policy under congestion: markings and class maps matter because the scheduler honors them when the link is busy.
Flattening all classes into a single FIFO so marking no longer matters abandons CBWFQ's purpose and would let guest bulk starve voice. Asserting guest traffic always preempts EF voice because CBWFQ ignores DSCP reverses both priority intent and classifier behavior; CBWFQ policies are built around classes that typically key off DSCP or ACLs. Claiming CBWFQ converts the uplink into a pure Layer 2 flood domain without queues confuses bridging floods with queuing architecture and is not a CBWFQ outcome.
Exam caveat: under-congestion items test whether you expect class isolation versus FIFO collapse. Prefer the option that preserves voice protection and constrains bulk classes.
Operational check: under a controlled guest bulk transfer, confirm VoIP class drop/latency counters stay within policy while the guest class shows queueing delay or drops limited to its share, and verify the policy-map still matches DSCP/ACL classes on the congested uplink.