Hard Difficulty Questions

The ingress interface is configured as a trunk port.

Why it fails: Trunk versus access mode governs VLAN tagging on Layer 2 interfaces and does not prevent a firewall filter from applying routing-instance actions. Filter-based forwarding works on routed ingress traffic regardless of trunk configuration. Trunk ports are the right choice when carrying multiple tagged VLANs between switches.

The firewall filter term lacks a 'count' action statement.

Why it fails: A count action only increments a counter for monitoring; it neither routes nor discards traffic. The term needs a routing-instance action to redirect matching packets into the alternate instance. Counting is genuinely useful for verifying which terms match during troubleshooting, but it cannot perform the forwarding itself.

The routing instance type is set to virtual-router instead of forwarding.

Why it fails: A virtual-router instance maintains a separate routing table but still requires the filter's routing-instance action to steer traffic into it; the instance type alone does not cause drops. Forwarding instances suit filter-based forwarding because they share the main table's routes. Virtual-router instances are correct when full routing isolation is required.

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.

MED and NEXT_HOP

Why it fails: MED influences path selection between autonomous systems and NEXT_HOP is the next-hop IP; neither prevents route reflection loops. The reflector adds ORIGINATOR_ID and CLUSTER_LIST so clients discard routes they originated. MED and NEXT_HOP manipulation applies when tuning inbound traffic or resolving next-hop reachability, not loop prevention.

AS_PATH and LOCAL_PREF

Why it fails: A route reflector adds ORIGINATOR_ID and CLUSTER_LIST to reflected routes; AS_PATH and LOCAL_PREF are unchanged by reflection. AS_PATH and LOCAL_PREF are tempting because both influence BGP best-path selection, but loop prevention across the reflector cluster relies on the cluster list, not path attributes.

COMMUNITY and ATOMIC_AGGREGATE

Why it fails: COMMUNITY and ATOMIC_AGGREGATE are optional transitive attributes used for policy tagging and aggregation suppression, not loop prevention. A route reflector instead adds ORIGINATOR_ID and CLUSTER_LIST. These attributes would be relevant when tagging routes for community-based filtering or marking aggregated prefixes, not for reflecting routes between clients and non-clients.

To define how often the DIS sends Hellos.

Why it fails: DIS Hello frequency is configured with the hello-interval on the interface, not lsp-lifetime, which sets the ageing timer for a router's own LSPs in the link-state database. The option tempts because DIS Hellos are IS-IS timers, yet lsp-lifetime governs LSP validity, not Hello transmission.

To limit the number of LSPs in the database.

Why it fails: lsp-lifetime sets how long a router's own LSPs remain valid before ageing out; it does not cap database size. The option tempts because LSP counts relate to the link-state database, but database limits come from memory and throttling, not this timer.

To set how long the adjacency stays up.

Why it fails: The adjacency hold time is governed by the hello and hold-time settings, not lsp-lifetime, which controls how long a router's own LSPs remain valid in the link-state database before being purged. It is tempting because both are timers, but lsp-lifetime concerns LSP ageing, not neighbour adjacency state.

100 Gbps default; reference bandwidth must be decreased for legacy interfaces.

Why it fails: Junos defaults to a 100 Mbps reference bandwidth, not 100 Gbps, so this premise is wrong. Raising the reference bandwidth is what differentiates 10G and 40G links; decreasing it would collapse high-speed interfaces to identical costs. A 100 Gbps reference would be chosen only if links exceeded 100 Gbps.

10 Gbps default; no adjustment is needed for modern networks.

Why it fails: Junos defaults to 100 Mbps, not 10 Gbps. With a 10 Gbps reference, 10G and 40G interfaces both compute cost 1, so no differentiation occurs — exactly the problem the stem describes. A 10 Gbps reference would suit networks whose fastest links are 10 Gbps.

1 Gbps default; interfaces above 1 Gbps are automatically assigned fractional costs.

Why it fails: Junos defaults to 100 Mbps, not 1 Gbps, and OSPF cost is an integer (reference bandwidth divided by interface bandwidth), never fractional. Interfaces above the reference bandwidth all yield cost 1, so 10G and 40G links become indistinguishable. A 1 Gbps reference suits networks topping out at 1 Gbps.

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.

The static route preference must be set lower than 1.

Why it fails: Preference controls route selection among competing routes, not whether a recursive next-hop resolves. Lowering it below 1 does not create resolution. Preference tuning is tempting when a static route loses to a dynamic route, and that would be correct for influencing best-path selection, but resolution depends on the next-hop address being reachable.

The next-hop IP must be directly connected to a physical interface on the local router.

Why it fails: A recursive next-hop is by definition not directly connected, so requiring direct attachment contradicts the scenario. Directly connected next-hops are tempting because they activate immediately without resolution, and that would be correct for a simple non-recursive static route, but recursion instead requires the indirect address to resolve via another route.

BGP multipath must be enabled under routing-options.

Why it fails: BGP multipath affects load balancing across equal BGP paths and has no bearing on resolving a static route's recursive next-hop. It is tempting when adding alternate paths for redundancy, and that would be correct for multipath forwarding between BGP peers, but static route activation depends on the next-hop resolving through the routing table.

AS_PATH

Why it fails: AS_PATH is attribute type code 2 and contains a sequence of autonomous system numbers, not an IP address. It is tempting because AS_PATH is well-known mandatory and appears in every update, but the stem's type code 3 with an IP address value identifies NEXT_HOP.

ORIGIN

Why it fails: ORIGIN is attribute type code 1, carrying a one-octet value (IGP, EGP or INCOMPLETE) that describes route provenance, not an IP address. It is tempting because ORIGIN is well-known mandatory, but type code 3 with an IP address value identifies NEXT_HOP instead.

LOCAL_PREF

Why it fails: LOCAL_PREF is attribute type code 5, is discretionary rather than well-known mandatory, and carries a preference metric, not an IP address. It is tempting because it influences outbound path selection, but the stem specifies type code 3 with an IP address value, which is NEXT_HOP.

The OSPF Designated Router (DR) on the NSSA segment

Why it fails: The DR manages adjacency and LSA flooding on the segment, not external route translation; Type 7-to-Type 5 conversion is an NSSA ABR function. Confusing DR with ABR is tempting because both are elected roles, but the DR has no backbone interface and cannot generate Type 5 LSAs.

The ASBR that originated the external route

Why it fails: The originating ASBR floods Type 7 LSAs within the NSSA but never converts them; translation happens at the NSSA ABR bordering the backbone. This is tempting because the ASBR sources the external route, yet without a backbone adjacency it cannot inject Type 5 LSAs into area 0.

Any internal NSSA router running Junos OS

Why it fails: Only the NSSA's elected NSSA ABR performs Type 7-to-Type 5 translation; internal NSSA routers hold Type 7 LSAs but never translate them. Any internal router is tempting because all NSSA routers carry Type 7 LSAs, yet translation requires an ABR with a backbone adjacency.

Execute request system reboot immediately to restart tunnel daemon processing.

Why it fails: Rebooting the system is disruptive and unnecessary for diagnosing tunnel configuration or path issues.

Use clear ip-ip statistics to reset tunnel counters.

Why it fails: There is no clear ip-ip statistics command in Junos OS.

Run show chassis routing-engine to check control plane memory utilization of tunnel encapsulation modules.

Why it fails: Routing engine chassis health does not directly diagnose specific tunnel encapsulation path failures.

An explicit static route matching the aggregate prefix must be configured.

Why it fails: A static route for the same prefix is unnecessary and would itself activate the aggregate, masking the real requirement. Static routes are the right tool when you need a fixed, manually maintained path to a destination that no dynamic protocol advertises.

A discard policy must be explicitly defined under the aggregate route definition.

Why it fails: Junos activates an aggregate only when a contributing more-specific route exists in inet.0, so a discard policy changes forwarding behaviour, not activation. It is tempting because discard is the default next hop for aggregates, and defining one is valid when you want the aggregate to blackhole traffic once it becomes active.

The aggregate route must be redistributed using BGP or OSPF.

Why it fails: Redistribution exports the aggregate into BGP or OSPF; it does not create the contributing more-specific route that Junos requires before the aggregate becomes active. Redistribution is correct when you want an already-active aggregate advertised to peers.

IP Source Guard requires static ARP inspection to be enabled simultaneously.

Why it fails: Dynamic ARP inspection is a separate anti-spoofing feature and is not a prerequisite for IP Source Guard. It is tempting because DAI and IP Source Guard are often deployed together on access ports, but the missing DHCP snooping binding is the actual cause of the drops.

The client's MAC address is in the port security violation log.

Why it fails: Port security violations concern MAC address limits, not IP-to-MAC binding validation. It is tempting because port security also drops traffic on access ports, but the log explicitly shows no DHCP snooping binding, which is what IP Source Guard checks.

IP Source Guard only supports static IP bindings, not DHCP-derived bindings.

Why it fails: IP Source Guard supports both static and DHCP snooping-derived bindings; it is not limited to static entries. It is tempting because static bindings are configured manually for hosts without DHCP, but the real fault is that DHCP snooping is not enabled for the VLAN.

family inet

Why it fails: Family inet configures IPv4 addressing on the interface, but the payload inside this GRE tunnel is IPv6, so family inet6 must be set on the gr- unit. It tempts because the outer transport is IPv4, yet that outer header belongs to the tunnel source, not the gr- unit.

family iso

Why it fails: Family iso enables OSI connectionless routing (IS-IS), which carries no IPv6 packets; the gr- unit requires family inet6 for the encapsulated traffic. It tempts when IS-IS runs over GRE for adjacency formation, a separate design from tunnelling IPv6 payloads.

family mpls

Why it fails: Family MPLS carries label-switched packets and cannot hold the IPv6 payload; the tunnel's inner protocol is IPv6, so family inet6 is required. It tempts when the GRE tunnel itself rides an MPLS core, where label handling occurs on the transport interfaces, not the gr- unit.

The cipher suite defaults to GCM-AES-128 on one end and AES-CBC-128 on the other.

Why it fails: MACsec requires both peers to negotiate the same cipher suite; mismatched GCM-AES-128 and AES-CBC-128 causes the secure association to fail, so frames decrypt incorrectly. It is tempting because cipher mismatch is a common cause, but here the defaults must match on both ends for the MKA session to succeed.

The MTU on the physical interface is set too small to accommodate MACsec ICV overhead.

Why it fails: MACsec adds a 16-byte ICV plus header, but an undersized MTU causes fragmentation or drops of oversized frames, not decryption failure of frames that arrive. MTU tuning is the right fix when large frames are silently discarded on a jumbo-capable path, not when the ciphertext itself fails authentication.

DHCP snooping is blocking the MACsec control frames on the transit link.

Why it fails: DHCP snooping filters rogue DHCP server messages on untrusted access ports; it does not inspect or drop MACsec control frames such as MKA or EAPOL on a transit link. It would be relevant on access ports where rogue DHCP servers must be blocked, not on a point-to-point trunk carrying encrypted traffic.

set routing-instances aggregate-property

Why it fails: This command structure does not exist.

set protocols bgp aggregate-attribute 10.10.0.0/16

Why it fails: This is not valid BGP syntax.

set routing-options aggregate route 10.10.0.0/16 policy

Why it fails: Policies are not applied directly via the aggregate route statement in this manner for route attribute injection.

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.

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.

Stub areas filtering out external LSA advertisements

Why it fails: Stub areas filter summary/external LSAs and do not dictate the creation of Type 2 LSAs.

Virtual links traversing a non-backbone transit area

Why it fails: Virtual links are modeled as point-to-point links using Type 1 LSAs.

Point-to-point links between two directly connected routers

Why it fails: Point-to-point links use Type 1 Router LSAs only and do not require a DR or Type 2 LSAs.

Configure 'set protocols isis reference-bandwidth <value>' globally.

Why it fails: Reference bandwidth affects calculated metric values for wide metrics, not DIS election.

Configure 'set protocols isis lsp-interval <value>' to speed up PDU transmission.

Why it fails: LSP transmission interval controls LSP pacing, not the DIS election.

Configure 'set protocols isis level <1|2> metric <value>' to lower the interface cost.

Why it fails: IS-IS metric values affect path selection, but have no impact on the DIS election process.