Class OF Service practice questions

forwarding-class

Why it fails: Forwarding-class assigns a new class to the packet.

transmit

Why it fails: Transmit allows the packet to pass.

mark-action

Why it fails: Mark-action is used to remark the packet header.

Layer 4 classification requires an explicit forwarding-class map under system services

Why it fails: Forwarding classes are mapped directly in the firewall action.

Multi-field classifiers do not support TCP ports in Junos

Why it fails: Multi-field classifiers fully support TCP/UDP ports via firewall filters.

Layer 4 matching is only supported on ingress CoS rewrite rules

Why it fails: Rewrite rules are for egress remarking, not classification.

ieee-802.1

Why it fails: ieee-802.1 is used for Layer 2 CoS bits in the VLAN header.

exp

Why it fails: exp is used for MPLS experimental bits.

dscp

Why it fails: dscp is used for the full 6-bit Differentiated Services Code Point.

It separates policing actions strictly for Layer 2 control frames

Why it fails: Control frames are handled by separate routing-protocol filters.

It disables hardware-based policing and falls back to RE software rate-limiting

Why it fails: Logical interface policers execute in hardware on supported ASICs.

It applies the policer globally across all physical interfaces on the Routing Engine

Why it fails: That describes a system-level or global policer.

Traffic exceeding 100% is dropped by the Routing Engine

Why it fails: Commit validation catches this before operational traffic handling.

Junos normalizes the percentages proportionally during commit time

Why it fails: Junos does not auto-normalize; it rejects oversubscribed percent allocations.

The excess 10% is automatically assigned to the best-effort queue

Why it fails: Automatic reassignment does not occur for invalid sums.

show firewall log

Why it fails: Firewall logs show security and filter logging events.

show interfaces drop-rate

Why it fails: Interface drop rates are viewed via interface extensive commands.

show system drop-stats

Why it fails: This command does not exist in Junos.

4

Why it fails: 4 was common on older M-series platforms.

8

Why it fails: 8 is the default configuration set, but hardware supports more.

16

Why it fails: Modern MPCs support up to 64 forwarding classes.

peak-rate

Why it fails: peak-rate is not a standalone Junos policer keyword.

rate-limit

Why it fails: rate-limit is not the correct Junos syntax keyword.

transmit-rate

Why it fails: transmit-rate is used in scheduler configurations.

drop-profile-map

Why it fails: drop-profile-map links drop profiles to loss priorities.

transmit-rate

Why it fails: transmit-rate allocates bandwidth.

priority

Why it fails: priority sets scheduling precedence.

set routing-options forwarding-table l2-accounting

Why it fails: This command does not exist.

set firewall family inet filter <filter> overhead-accounting

Why it fails: Firewall filters do not handle shaping overhead.

set class-of-service interfaces <interface> encapsulation-overhead

Why it fails: encapsulation-overhead is not the correct command syntax.

Behavior aggregate classifiers must be disabled on all egress interfaces

Why it fails: BA classifiers are on ingress and unrelated to priority scheduling.

Buffer sizes must be set to zero for all priority queues

Why it fails: Buffers are still required for bursts.

The scheduler must have a transmit-rate percentage of exactly 100%

Why it fails: transmit-rate is not required to be 100% for priority queues.

dynamic-profiles

Why it fails: Dynamic profiles are used for subscriber management.

bgp-routes

Why it fails: BGP routes handle network reachability, not CoS.

H-QoS eliminates the need for physical interface drop profiles

Why it fails: H-QoS operates alongside physical interface drop profiles, which still govern tail-drop and buffer behaviour on the underlying port; it does not replace them. It is tempting because hierarchical scheduling adds per-level shaping, and it would be correct where a single-level scheduler alone handles all queue and drop decisions.

H-QoS is configured exclusively under the system routing-options hierarchy

Why it fails: H-QoS is configured under class-of-service on the interface and its scheduler hierarchy, not under system routing-options, which holds routing protocol and system-wide parameters. It is tempting because routing-options is a familiar top-level stanza, and it would be correct when setting autonomous system numbers or router-id values.

H-QoS requires disabling all hardware-based forwarding ASICs

Why it fails: H-QoS relies on the MX Series hardware forwarding ASICs and Packet Forwarding Engine to enforce hierarchical shaping and scheduling; disabling them removes the capability entirely. It is tempting because software-based scheduling appears flexible, and it would be correct on platforms lacking dedicated hardware queuing support.

Current BGP peer states

Why it fails: Class-of-service output reports per-interface queue counters, scheduler maps and rewrite rules, not routing-protocol adjacencies; BGP peer states live in 'show bgp summary'. It tempts because interface commands do list logical units, yet peer state is a control-plane, not CoS, attribute.

Routing table packet forwarding counts

Why it fails: The command displays class-of-service configuration and statistics per interface, such as schedulers, queues and rewrite rules, not routing table forwarding counters. It is tempting because forwarding counts appear in other show outputs, but CoS interface output concerns queuing and classification, not routing.

The multi-field classifier is applied after the behavior aggregate classifier, and its results are ignored if a BA classifier is present.

Why it fails: This statement is incorrect because multi-field and behavior aggregate classifiers cannot coexist on the same interface. The multi-field classifier is not applied after a BA classifier; instead, it replaces the BA classifier entirely. If a BA classifier is configured, a multi-field classifier cannot be applied to the same interface.

The multi-field classifier uses a fixed table that maps DSCP values to forwarding classes and cannot match on source IP.

Why it fails: This describes a behavior aggregate classifier, which uses a fixed mapping table for DSCP or other CoS bits. Multi-field classifiers, on the other hand, use firewall filters and can match on source IP addresses and many other fields. The statement incorrectly attributes BA classifier characteristics to multi-field classifiers.

The multi-field classifier is applied before the behavior aggregate classifier, and its results override the BA classifier.

Why it fails: Multi-field classifiers and behavior aggregate classifiers are mutually exclusive on an interface. You cannot apply both to the same interface, so there is no order of operations where one overrides the other. The multi-field classifier is a separate classification method that uses firewall filters to assign forwarding classes and loss priorities based on multiple fields.

Assign a shaping-rate to the data queue equal to the interface bandwidth.

Why it fails: Shaping the data queue to the full interface bandwidth does not create strict priority for voice nor weighted sharing between video and data. In fact, allowing data to transmit at line rate could let it consume bandwidth the design intends to reserve, undermining the intended CoS behavior on this egress interface.

Assign a large buffer-size percentage to the best-effort data queue.

Why it fails: Increasing buffer-size on the data queue only affects how much burst traffic can be buffered; it does not establish strict priority for voice or define weighted sharing for video and data. Buffer tuning is a complementary optimization, not a required element to satisfy the strict-priority and weighted-sharing design described.

Assign priority strict-high to both the video and voice queues.

Why it fails: Making both video and voice strict-high priority would cause them to compete as strict-priority queues, which defeats the design goal of video sharing bandwidth with data under weighted scheduling. It also risks video starving data and can cause unpredictable behavior when multiple strict-high queues exist on the same interface.

A queue configured with low priority is serviced before a queue configured with high priority when the low-priority queue is backlogged.

Why it fails: Priority order in Junos runs from strict-high down to low, so a high-priority queue is always serviced before a low-priority queue when both are backlogged. The low-priority queue only receives service when higher-priority queues have no packets waiting, which protects latency-sensitive traffic.

A queue configured with a transmit-rate of remainder receives all bandwidth not allocated to other queues.

Why it fails: The remainder keyword assigns the queue the bandwidth left after other queues with explicit rates are satisfied. It does not mean the queue receives all unallocated bandwidth exclusively; multiple remainder queues share the leftover proportionally, and excess bandwidth can also be distributed by the scheduler.

A scheduler map applied to an interface replaces the default scheduler map for all queues on that interface.

Why it fails: A scheduler map associates forwarding classes with schedulers, but it does not automatically replace the default map for queues not referenced. Each forwarding class that must use a non-default scheduler has to be explicitly listed, otherwise the default scheduler applies to that class.

To dynamically assign forwarding classes based on IP headers

Why it fails: Forwarding-class assignment happens through behaviour aggregate classifiers or multifield classifiers, not aggregate shaping, which only limits combined bandwidth of child queues. It is tempting because classifiers and schedulers are both configured under the class-of-service hierarchy, so their distinct roles are easily confused.

To ensure absolute priority for best-effort traffic

Why it fails: Aggregate level shaping caps the combined bandwidth of all child queues sharing a scheduler node; it cannot grant absolute priority, which strict-high priority scheduling provides instead. It is tempting because shaping and prioritisation are both configured in the same hierarchical scheduler map, so the two functions are easily conflated.

To rewrite CoS bits on egress frames

Why it fails: CoS bit rewriting is performed by rewrite rules attached to a firewall filter or interface, not by aggregate level shaping, which enforces a bandwidth ceiling on a scheduler node's children. It is tempting because both features appear in CoS configuration, yet they operate at entirely different processing stages.

expedited-forwarding

Why it fails: Expedited-forwarding carries low-loss, low-latency data such as VoIP, not control plane traffic; Junos reserves network-control for routing protocols and management. It is tempting because EF is the highest-priority standard class, so it appears to suit critical traffic, but that priority serves latency-sensitive payloads.

assured-forwarding

Why it fails: Assured-forwarding provides four drop-precedence subclasses for bandwidth-guaranteed subscriber traffic, not routing protocols or management. It is tempting because AF sounds like guaranteed delivery for important traffic, but its purpose is differentiated handling of data classes, whereas control plane traffic uses the dedicated network-control class.

best-effort

Why it fails: Best-effort is the default class for unclassified traffic with no priority guarantee, so it cannot be reserved for control plane traffic. It is tempting because it is the catch-all class, but Junos assigns routing protocols and management to network-control, leaving best-effort for ordinary data.

buffer-size

Why it fails: Buffer-size sets queue memory depth, controlling burst absorption rather than scheduling order, so it cannot make voice serviced first. It is tempting because voice needs low jitter, and buffer tuning is correct when sizing queues for bursty traffic, not for strict priority.

transmit-rate

Why it fails: Transmit-rate caps or guarantees a queue's bandwidth share; it does not determine service order, so voice packets still wait behind other queues. It is tempting because rate limiting protects voice from starvation, and it would be correct where the requirement is guaranteed bandwidth rather than strict priority.

drop-profile

Why it fails: Drop-profile defines which packets are discarded during congestion, governing loss behaviour rather than queue servicing order, so voice would not be scheduled first. It is tempting because voice requires low loss, and drop profiles are correct when shaping TCP or managing congestion.