Select Two (Multi-Select) Questions

Hello ACK PDU

Why it fails: IS-IS Hello PDUs are not acknowledged; there is no Hello ACK PDU type. It is tempting because acknowledgement mechanisms exist in other protocols, and it would be correct where a protocol defines explicit ACK PDUs, which IS-IS does not.

Routing Update PDU

Why it fails: IS-IS defines Hello, LSP, CSNP, PSNP and IIH PDUs; no Routing Update PDU exists. It is tempting because routing protocols such as RIP and BGP carry update messages, and it would be correct terminology for those protocols, not IS-IS.

Maximum Transmission Unit (MTU) size set to exactly 1500 bytes

Why it fails: MACsec operates at layer 2 and does not negotiate MTU; peers can establish a secure session across links with differing MTU values, so 1500 bytes is not a required match. It is tempting because MTU mismatches do break some tunnelled protocols, but that concerns fragmentation, not MACsec session parameters.

IP address subnet allocation on the physical transit ports

Why it fails: MACsec secures the Ethernet frame and never inspects layer 3, so IP subnet allocation on the physical ports is irrelevant to session establishment. It is tempting because IP reachability matters for IPsec peers, but MACsec uses the Connectivity Association Key and cipher suite instead.

The route is immediately accepted and installed in the routing table.

Why it fails: 'Next policy' halts evaluation of the current policy and passes the route to the next policy in the chain; it neither accepts nor installs anything. Acceptance is what a terminating 'accept' action does, which is why this reads as plausible when a route is ultimately permitted later.

The route is rejected and dropped.

Why it fails: 'Next policy' does not reject or drop the route; it defers the decision to the following policy in the chain, where it may still be accepted. Rejection is the terminating 'reject' action, which discards the route and returns it to BGP.

Evaluation jumps to the next term within the same policy block.

Why it fails: 'Next policy' exits the entire current policy and moves to the next policy in the chain, not the next term within the same policy. Jumping to the next term is what the 'next term' action does, so this confuses the two closely named Junos policy actions.

Synchronization of BGP routing daemon state between separate routers.

Why it fails: LAG operates at Layer 2, aggregating Ethernet member links; it does not synchronise BGP routing daemon state, which is handled by routing protocol adjacencies. It is correct when the question asks about combining physical links for bandwidth or redundancy.

Automatic upgrade of Junos OS across peer devices.

Why it fails: LAG bundles physical links into one logical interface for increased bandwidth and redundancy; it has no relationship to Junos OS software upgrades. It would be correct if the question asked about aggregating member links between switches.

Elimination of the need for Spanning Tree Protocol across all VLANs.

Why it fails: LAG bundles parallel links into one logical interface, but Spanning Tree still runs on other switch ports and VLANs to prevent loops. It is correct when the question asks about increasing bandwidth or link redundancy between two devices.

The VRRP router ID configured on VLAN 1.

Why it fails: Virtual Chassis primary Routing Engine election uses member ID, priority and hardware/software capability, not VRRP configuration. VRRP router ID is a Layer 3 gateway redundancy parameter unrelated to RE mastership. It would be relevant when tuning VRRP master election on an EX Series switch, not Virtual Chassis RE election.

The number of active LACP links connected to member 0.

Why it fails: LACP link counts are not among the Virtual Chassis primary Routing Engine election criteria, which are member ID, priority and the preprovisioned or non-provisioned role. LACP determines aggregated link membership and hashing. It would be the right consideration when troubleshooting a port-channel's active member links, not RE mastership.

It operates independently without any interaction with external RSTP switches.

Why it fails: The CIST interoperates directly with external RSTP switches, treating their spanning tree as part of instance 0. Claiming independence fails because MSTP is explicitly designed for RSTP compatibility. It is tempting because MSTP regions appear self-contained internally, yet boundary ports still exchange and translate RSTP BPDUs.

It is limited strictly to a maximum hop count of 1.

Why it fails: CIST uses the standard MSTP hop count, configurable up to 255 via max-hops, not a fixed limit of 1. The claim fails because no such restriction exists. It is tempting because MSTP does bound topology diameter through hop counts, but the actual default is 20, not 1.

It prohibits the use of root protection on instance 0 ports.

Why it fails: Root protection is configurable on CIST (instance 0) ports; MSTP applies it to the common spanning tree to guard the regional root. The statement inverts this, so it fails. It is tempting because root guard is often associated with per-instance MSTP configuration, yet instance 0 supports it normally.

Enable Layer 3 routing directly on the physical trunk interface unit 0.

Why it fails: Unit 0 on a physical trunk interface carries no VLAN tagging configuration, so untagged and priority-tagged frames cannot be mapped to a native VLAN. Layer 3 routing is configured on a VLAN interface (unit with vlan-id), which is the correct approach when inter-VLAN routing is required, not for trunk frame handling.

Configure the interface encapsulation as CCC or VPLS.

Why it fails: CCC and VPLS encapsulation are for circuit cross-connect and VPLS Layer 2 VPN services, not for standard trunk ports carrying multiple VLANs. It tempts because both are Junos interface encapsulation settings, but a trunk needs family ethernet-switching with vlan members and a native VLAN to handle untagged and priority-tagged frames.

Disable MAC learning on the trunk interface to prevent native VLAN loops.

Why it fails: Disabling MAC learning does not address untagged or priority-tagged frame handling and would break forwarding on the trunk. It tempts as a loop-prevention measure, but native VLAN traffic is handled by configuring a native VLAN on the trunk, not by suppressing the MAC learning that ethernet-switching relies on.

Enable spanning-tree protocol globally for the access VLAN to become active.

Why it fails: Spanning tree does not gate VLAN membership; an access interface becomes active once it references an existing VLAN. Enabling STP globally is done to prevent Layer 2 loops in redundant topologies, not to activate a VLAN on a port.

Configure the interface family as inet and assign an IP address.

Why it fails: Layer 3 addressing on the interface does not assign it to a VLAN; access membership requires the interface to reference the VLAN under unit 0. An inet family with an IP address is configured for routed ports or IRB interfaces, not switched access ports.

Configure the interface as a trunk port with native-vlan-id enabled.

Why it fails: An access port carries untagged traffic in a single VLAN, so trunk encapsulation with native-vlan-id contradicts the requirement. Trunks are configured when a link must carry multiple VLANs between switches, where tagging and a native VLAN genuinely apply.

IGMP snooping on static interfaces

Why it fails: IGMP snooping manages multicast group membership at Layer 2; it neither forwards packets between subnets nor provides alternate paths. Static routes achieve redundancy through qualified-next-hop or backup routes with preference values. Snooping is tempting in multicast designs, but it cannot restore reachability when a primary link fails.

OSPF area stubbing

Why it fails: OSPF area stubbing reduces link-state advertisements entering an area; it is an OSPF design technique, not a static-route redundancy mechanism. Static-route high availability uses qualified-next-hop or backup static routes with differing preferences. Stubbing is tempting in large OSPF topologies, but it does not provide an alternate forwarding path.

BGP AS-path prepending on static routes

Why it fails: AS-path prepending manipulates BGP path selection between autonomous systems; it cannot be applied to a static route, which has no AS path attribute. Static-route redundancy relies on qualified-next-hop or backup routes with preference values. Prepending is tempting for influencing inbound BGP traffic, but it is irrelevant here.

Unicast traffic destined for known active MAC addresses exceeding average utilization

Why it fails: Storm control monitors broadcast, multicast and unknown unicast; frames to known active MAC addresses are normal switched traffic and are never counted. It tempts because unicast flooding resembles unknown unicast, but the distinction is destination MAC presence in the forwarding table, not average utilisation.

CPU control plane queue utilization exceeding 90%

Why it fails: Storm control meters physical interface bandwidth per traffic type, not internal CPU control-plane queue depth; those queues are policed by CoPP. It is tempting because CPU protection also drops excess traffic, but that mechanism targets punted control traffic, not the Layer 2 flooded frames storm control counts.

BPDU control frames exceeding Spanning Tree hello timers

Why it fails: Storm control counts BPDUs only if they are configured as the monitored traffic type and exceed the configured threshold; exceeding STP hello timers is not a storm-control condition, it signals topology or timer problems. It tempts because BPDUs are Layer 2 control frames, but storm control reacts to rate, not timer intervals.

OSPFv3 authentication

Why it fails: OSPFv3 authentication secures routing protocol adjacencies on Layer 3 interfaces, not end-host access at the switch port. It is tempting because it is authentication, but secure access ports govern supplicant identity, dynamic VLAN assignment and MAC limits on edge ports.

MACsec point-to-point encryption

Why it fails: MACsec encrypts hop-by-hop traffic on point-to-point links between switches or routers, which is a campus uplink or WAN concern rather than a secure access port edge feature. It is tempting because it is port-based security, but secure access ports cover supplicant authentication, dynamic VLANs and MAC limiting.

MED

Why it fails: MED is an optional non-transitive attribute, so it is never propagated between autonomous systems and cannot qualify as transitive. It is tempting because MED does influence inbound path selection between multiple entry points into the same AS, which is exactly the scenario where it is the correct attribute to set.

LOCAL_PREF

Why it fails: LOCAL_PREF is a well-known discretionary attribute confined to a single autonomous system; it is never advertised to external BGP peers, so it cannot be transitive. It is tempting because LOCAL_PREF is the correct attribute for steering outbound traffic within one organisation across multiple exit points.

Local Preference is a well-known discretionary attribute that is exchanged across eBGP peers.

Why it fails: Local Preference is well-known discretionary, but it is exchanged only across iBGP peers within an AS and is stripped at eBGP boundaries. It is tempting because it does steer outbound path selection, yet that selection stays internal to the autonomous system.

MED is a well-known mandatory attribute used for inter-AS route selection.

Why it fails: MED is an optional non-transitive attribute, not well-known mandatory, and it influences selection between paths from the same neighbouring AS, not inter-AS selection. It is tempting because MED does compare routes, but only within one AS's inbound path choice.

Optional transitive attributes are ignored by BGP speakers that do not recognize them and are never passed along to other peers.

Why it fails: Optional transitive attributes unrecognised by a speaker are still propagated to other peers, with the partial bit set. It is tempting because unrecognised optional non-transitive attributes are indeed dropped; transitivity is the axis that separates the two.

Static routes are created automatically when an interface comes up.

Why it fails: Direct routes, not static routes, are created automatically when an interface comes up with an address. Static routes require explicit configuration. The reversal is tempting because automatic installation is a genuine Junos behaviour — it just belongs to connected routes, which is the attribute being tested.

Direct routes require manual IP address configuration under routing-options.

Why it fails: Direct routes are installed automatically when an interface has an IP address and is up; no routing-options configuration is involved. Manual configuration under routing-options is exactly what defines static routes. The option inverts the two, which is tempting because both route types do appear in the routing table.

Static routes cannot be used with recursive next-hops.

Why it fails: Static routes absolutely can use recursive next-hops — pointing at a next-hop resolved via another route is standard Junos behaviour. The tempting pull is that recursion is a real routing concept, but it distinguishes nothing here: direct routes simply resolve to the connected interface, while static routes are manually configured.

Disabling all Layer 2 learning on the translation interface.

Why it fails: VLAN translation rewrites tag values while retaining normal Layer 2 forwarding and MAC learning; disabling learning would break forwarding on the translation interface. It is tempting because translation alters tags, but the required components are push, pop and translation-profile statements, not suppression of the learning plane.

Enabling OSPFv3 routing directly on the customer edge interface unit 0.

Why it fails: Selective QinQ with VLAN translation requires push/pop actions and translation profiles mapping inner to outer tags on the interface; OSPFv3 is a routing protocol unrelated to tag rewriting. It is tempting because unit 0 configuration appears in interface setups, but Layer 3 routing does not manipulate 802.1Q tag stacks.

Storm Control rate-limiting

Why it fails: Storm Control rate-limits broadcast, multicast and unknown unicast traffic by policing configured thresholds on a port; it never consults the DHCP snooping binding table. It is tempting because both features are configured on access switches, but Storm Control would be the correct choice for suppressing broadcast storms, not for validating DHCP assignments.

Port Security MAC-Limit

Why it fails: Port security MAC-limit counts learned source MAC addresses per interface; it consults the MAC address table, not the DHCP snooping binding database. It is tempting because both features restrict which hosts may send traffic, but the binding database specifically underpins IP Source Guard and Dynamic ARP Inspection.

MACsec Key Agreement (MKA)

Why it fails: MACsec Key Agreement negotiates secure link keys and authenticates peers at layer 2 using EAP exchanges and connectivity association keys; it never reads DHCP snooping bindings. It is tempting because both concern layer-2 access control, but the binding database feeds IP Source Guard and Dynamic ARP Inspection instead.

Bridge priority adjustment

Why it fails: Bridge priority adjustment sets which switch becomes root, shaping the topology rather than defending access ports. BPDU guard and root guard are the protective features; they act on superior BPDUs arriving at edge ports, which priority tuning never inspects.

Hello timer scaling

Why it fails: Hello timer scaling changes how quickly BPDUs are sent and neighbours age out; it tunes convergence, not port admission. BPDU guard and root guard are the protective features, since they block or err-disable access ports receiving superior BPDUs from rogue switches.

Forward delay timer optimization

Why it fails: Forward delay optimisation shortens listening and learning states to speed convergence; it does not police port admission. BPDU guard and root guard are the protective features, since they detect and block superior BPDUs from unauthorised switches on access ports.

show virtual-chassis

Why it fails: show virtual-chassis displays member IDs, roles and fabric link status for a Virtual Chassis, not LACP bundle membership. It is tempting because it verifies multi-switch topology, and it would be correct when validating Virtual Chassis formation and inter-member links.

show vrrp detail

Why it fails: show vrrp detail reports Virtual Router Redundancy Protocol group states and priorities, not LACP aggregation. It is tempting because it verifies gateway redundancy, and it would be the correct command when confirming VRRP mastership and failover behaviour.

show chassis routing-engine

Why it fails: This command reports Routing Engine CPU, memory and uptime, not LAG membership or LACP state. It is tempting because it verifies chassis health, and it would be the right choice when diagnosing RE failover or resource exhaustion rather than aggregate link status.

Configure the interface as a trusted port for Dynamic ARP Inspection.

Why it fails: Dynamic ARP Inspection validates ARP packets against the DHCP snooping binding table; it has no role in MACsec key agreement. It is tempting because both are port-level Layer 2 security features, and DAI would be configured on access ports in a DHCP-snooping deployment, not on the MACsec link.

Enable DHCP snooping on the transit VLAN.

Why it fails: DHCP snooping builds a binding table for untrusted access ports; MACsec encrypts the transit link using MKA-derived keys and does not consult that table. It is tempting because snooping is commonly enabled alongside DAI on access switches, but it neither establishes nor secures a MACsec channel.

BGP multipath enabled across all core interfaces.

Why it fails: BGP multipath is unrelated to FBF operation; FBF requires a firewall filter matching traffic, a routing-instance (or forwarding instance) type, and an interface or RIB group binding. Multipath affects load balancing across equal-cost routes, so it would be relevant when tuning BGP path selection, not for policy-based forwarding.

An RSVP-TE LSP tunnel configured between the routers.

Why it fails: FBF operates on stateless firewall filter matching plus a routing-instance lookup; it needs no MPLS traffic engineering tunnel. RSVP-TE LSPs provide explicit path and bandwidth reservation for MPLS traffic, which would be the correct choice when the requirement is deterministic traffic-engineered paths, not filter-based forwarding.