Refer to the Exhibit Practice Questions

Flood the frame to all ports except ge-0/0/0

Why wrong: The Ethernet switching table in Junos contains a learned MAC address entry for the destination, so the frame is a known unicast. Flooding is only performed for unknown unicast, broadcast, or multicast frames, where the destination is not in the table. Since the entry exists and points to ge-0/0/2, flooding to all ports except the ingress would be unnecessary and incorrect.

Drop the frame because the VLAN does not match

Why wrong: The frame is received on ge-0/0/0 and is tagged with VLAN 10. The destination MAC's forwarding entry is also in VLAN 10, so the frame's VLAN membership is consistent. There is no VLAN mismatch here; a drop would occur only if the ingress VLAN did not match the egress port's VLAN configuration, which is not the case.

Forward the frame out of both ge-0/0/1 and ge-0/0/2

Why wrong: The destination MAC address is a unicast address, not a multicast or broadcast address. Forwarding the frame to multiple ports would be appropriate only for BUM (broadcast, unknown unicast, multicast) traffic, where the frame is replicated. Since the MAC table contains a specific entry for this destination on ge-0/0/2, the frame must be sent to that single port only, not to ge-0/0/1 as well.

ge-0/0/2

Why wrong: ge-0/0/2 is administratively down, meaning the interface has been intentionally disabled in configuration. Even if a cable is connected and a transceiver is present, the link will remain down because the interface is disabled. This is a configuration state, not a physical layer failure; the link would come up only after removing the 'disable' statement.

ge-0/0/0

Why wrong: ge-0/0/0 is administratively up and the link is up, indicating that the physical layer is healthy. The interface has successfully negotiated with the peer, and the carrier is detected on the wire. Since both administrative and operational states are up, there is no indication of a physical layer problem on this port.

ge-0/0/3

Why wrong: ge-0/0/3 is administratively up and shows link up, so the physical medium is functioning correctly. In Junos, 'show interfaces ge-0/0/3' would display 'Physical link is Up', confirming that light or electrical signal is present. A physical layer issue would manifest as a down condition despite an up administrative state, which is not the case here.

VLAN10 is not defined in the global VLAN configuration.

Why wrong: The exhibit shows VLAN10 listed with its member interfaces and an active status, which proves VLAN10 is defined at the [edit vlans] hierarchy. A VLAN only appears in the output of operational commands like 'show vlans' when it is configured. Since VLAN10 is active, a missing global VLAN definition cannot be the cause of the connectivity failure.

An IRB interface for VLAN10 is not configured.

Why wrong: An IRB (integrated routing and bridging) interface provides a Layer 3 gateway for a VLAN, enabling routing between VLANs or to other subnets. For two hosts on the same VLAN and the same IP subnet, communication is purely a Layer 2 broadcast and MAC-learning process, so an IRB is unnecessary. Even if the hosts were on different subnets, an IRB alone would not help unless the hosts are configured with that IRB as their default gateway.

The interface ge-0/0/2 is configured as a trunk port.

Why wrong: On Junos, a trunk port can explicitly include VLAN10 in its 'vlan members' list, so the port would still forward VLAN10 frames. The exhibit shows ge-0/0/2 as a member of VLAN10, which is consistent with either an access port or a trunk whose allowed list contains VLAN10. A trunk port is not inherently incompatible with Layer 2 connectivity in VLAN10; the port's membership matters more than its mode, so this is not the root cause.

The IP address 1.1.1.1/32 is already in use.

Why wrong: The error is about the policy-statement, not the IP address being in use.

The candidate configuration has no errors and this is a warning.

Why wrong: It is an error, not a warning, and the commit check failed.

The commit check command requires user confirmation.

Why wrong: Commit check runs and reports errors without requiring confirmation.

The new switch is running a different version of Junos that is not compatible with the fabric

Why wrong: While Junos version compatibility is essential for VCF formation, the scenario does not indicate any version discrepancy. The QFX5110 supports the same major Junos releases as other VCF-capable switches, and a version mismatch would typically cause an explicit error or prevent the member identification, but the question does not state this as the cause. Therefore, this is an incorrect diagnosis.

The new switch is only connected to one spine node, and VCF requires full mesh connections to all spines

Why wrong: A VCF leaf node only needs at least one connection to a spine node to be discovered and participate in fabric operations. The VCF topology recommends full mesh for redundancy and performance, but it is not a hard requirement for membership. The device will still join and exchange fabric membership information over the single link, so this option incorrectly states a requirement.

The new switch has 'set virtual-chassis no-split-detection' enabled, preventing it from joining

Why wrong: The 'no-split-detection' configuration is designed to control the behavior when a virtual chassis splits (i.e., when member links are lost), ensuring that certain members remain active. It does not influence the process of a new device joining the fabric. A leaf with this setting enabled can still join a VCF as long as its VC-ID and version are compatible; therefore, this is not the cause.

Configure SSH to accept only public key authentication for user1.

Why wrong: Disabling password authentication for user1 forces all SSH sessions for that account to use a public key, eliminating brute-force password guessing for that username. However, this change is user-specific and does nothing to block or throttle the source IP address that is generating the repeated login attempts; the attacker can still attempt other usernames or attack another service. A management-plane filter, not an authentication policy, is required to stop the network-level attack.

Disable the user1 account.

Why wrong: Disabling the user1 account removes that single user as a target, but it is a reactive measure that does not identify or stop the attacker. The offending IP remains active and can simply run the same brute-force attack against other valid accounts, and the login logs would still show repeated failures. This action also potentially breaks legitimate operations if user1 is a functional account, whereas the immediate concern is the source address.

Set the 'session-limit' for user1 to prevent multiple login attempts.

Why wrong: The 'session-limit' parameter in Junos limits the number of concurrent authenticated sessions that user1 may have open, not the number of failed login attempts or authentication failures. Repeated login failures occur serially and never establish a session, so this knob has no effect on the brute-force activity. It also does not address the IP address, so a single attacker can keep retrying regardless of the session limit.

The route has a higher metric

Why wrong: The route's metric is 0, identical to other static routes for the same prefix. In Junos, a higher metric would affect route preference among equal-preference routes but would not hide a route; even a manually raised metric still leaves the route eligible for use if the next-hop is reachable. Since all static routes share the same metric, this assertion is incorrect.

The route has a lower preference

Why wrong: Preference determines which route is selected when multiple protocols offer the same prefix, with lower values being more preferred. All static routes have a default preference of 10, and a lower preference would actually make the route more attractive, not hidden. Hidden status is governed by next-hop reachability, not by preference, so this explanation is invalid.

The route is not committed

Why wrong: The route already appears in the output as a hidden route, which proves it exists in the routing table and was loaded from committed configuration. In Junos, any active route must have been committed; if the configuration were uncommitted, the route would not be present at all. Therefore claiming it is uncommitted contradicts the evidence shown.

The CPU will be overloaded due to the kernel messages.

Why wrong: The kernel messages generated when rpd is killed are a symptom of the process crash, not a cause of CPU overload. Logging a fatal error and generating a core dump consume negligible CPU cycles compared to normal router operations. Actual CPU overload would occur only from repeated crash/restart loops or massive route recalculation, but the message output itself has no significant resource impact. Thus, kernel messages do not overload the CPU.

The router will stop forwarding packets immediately.

Why wrong: Packet forwarding on Junos is performed by the Packet Forwarding Engine (PFE) using dedicated hardware ASICs, independently of the Routing Engine's rpd process. When rpd is killed, the existing forwarding table in the PFE remains intact, so traffic already being forwarded continues without interruption. Only after dynamic adjacencies are lost and routes are withdrawn will the forwarding entries for those routes be removed; static and directly connected routes stay valid. Therefore, the router will not stop forwarding packets immediately.

The router will reboot automatically.

Why wrong: Junos does not reboot the router when a user-space software process like rpd fails. The process monitoring framework automatically attempts to restart the failed daemon while the Routing Engine, chassis, and all other services continue to operate normally. A full system reboot is reserved for severe circumstances such as a kernel panic or hardware failure, not for a daemon termination. Hence, the router will not reboot automatically as a result of rpd being killed.

Displays help for syslog messages that include 'error'.

Why wrong: This option confuses a system log query with the CLI's help facility. The command does not invoke help or return usage hints about syslog messages; it directly reads the existing log output and applies a filter. The filter selects lines containing the literal string "error", displaying actual event entries rather than documentation. Therefore, it is incorrect because the output is operational log data, not help text.

Displays all syslog messages.

Why wrong: This option misunderstands the purpose of the pipe filter. Piping the log output to a match filter such as `match error` restricts the display to only those lines whose content satisfies the regular expression `error`. Without that filter, the command would show the entire log file, but the pipe consumes the full output and discards non-matching lines. Thus, the command does not report all messages; it reports a filtered subset of the log.

Displays the error log file.

Why wrong: This option incorrectly assumes the command targets a separate file. Junos does not maintain a dedicated "error log" file; all syslog messages, including errors, warnings, notices, and informational messages, are written to the configured log file, commonly `/var/log/messages`. The pipe filter is applied to the output of that standard file, so the command shows matching lines from that file rather than opening a different error-specific log. Hence, the phrase "error log file" is a misnomer.

The candidate configuration matches the committed configuration.

Why wrong: The `show | compare` command outputs a diff between the candidate configuration and the active committed configuration (rollback 0). When the candidate exactly matches the committed configuration, the command produces no output at all, not a listing of differences. Here, the presence of `+` and `-` lines proves the two configurations differ, so the statement is false.

The rollback 0 configuration is being displayed.

Why wrong: The `show | compare` command with no argument compares the candidate configuration against rollback 0, but it does not display the rollback 0 configuration itself. Instead, it displays only the differences between the candidate and rollback 0, using `-` and `+` markers. To view the actual rollback 0 configuration, you would need to use `show configuration | display rollback 0` or `rollback 0` in configuration mode. The diff here clearly shows changes, not a static rollback snapshot.

The interface ge-0/0/0 has been deleted.

Why wrong: The diff shows lines under the `interfaces ge-0/0/0` hierarchy, specifically within `family inet` and its `address` sub-statement. Both a `-` line (old address) and `+` line (new address) are present, indicating the interface definition still exists and only the address is being modified. If the interface were deleted, the entire block for ge-0/0/0 would appear with `-` prefixes, and there would be no corresponding `+` lines for that interface.

Reverse path forwarding (RPF) check is dropping the echo request.

Why wrong: RPF checks apply only to transit traffic being forwarded through the router, not to packets that the router itself originates, such as ICMP echo requests generated by a ping command. Even if RPF had been enabled, it would evaluate the source address of incoming packets on an interface against the unicast route table; a locally sourced ping never undergoes that input-interface check. Moreover, nothing in the exhibit suggests RPF is configured, so this cannot be the cause of the failure.

The interface is administratively down.

Why wrong: The exhibit explicitly shows 'Admin: up' in the interface status, meaning the interface has not been administratively disabled with the 'disable' configuration statement. An administratively down interface would display 'Admin: down' and would also remove the connected route from the routing table, causing the ping to fail immediately with a network unreachable or no route error. Because the interface shows both admin and operational up state, this option is not applicable.

Proxy ARP is not configured on the interface.

Why wrong: Proxy ARP is a feature where a router replies to ARP requests on behalf of a host that is on a different subnet or network segment, allowing the requesting host to think the router is the owner of the target IP. In this scenario, both the operator and the target 192.168.1.2 reside on the same subnet, so direct ARP (without proxy) is the correct and expected behavior. The absence of proxy ARP would only matter if the target were behind a router on a different L2 domain, which is not the case here.

The physical link is flapping

Why wrong: Link flapping would cause the physical interface to transition between up and down, generating syslog messages such as "Physical link down" and "Physical link up," and the OSPF adjacency would drop and immediately restart based on interface state changes. The exhibit shows the neighbor adjacency repeatedly cycling through non-full states without any interface state change, which is inconsistent with a flapping physical link. Additionally, link flapping affects all routed protocols, whereas an MTU mismatch selectively impacts adjacency formation while keeping the interface operational.

OSPF authentication is misconfigured

Why wrong: Authentication misconfiguration would cause OSPF hello packets to be discarded or rejected, producing "authentication failed" log messages at each hello interval. The neighbor would remain in the Down or Attempt state and never progress to ExStart, because no hello packets would successfully pass the authentication check. In the exhibit, the adjacency is repeatedly being attempted and reaching the database exchange phase, which would be impossible if authentication were failing on every hello packet.

The routers are in different OSPF areas

Why wrong: If the routers were in different OSPF areas, the area ID is carried in the OSPF header, and a mismatch causes incoming Hello packets to be silently dropped. As a result, the neighbor would never leave the Down state, and no adjacency would be attempted. Because the exhibit explicitly shows the neighbor adjacency repeatedly forming and then resetting across multiple states, an area mismatch cannot explain the behavior—it would prevent any progression beyond Down.

The route has a lower local preference

Why wrong: Local preference is a BGP path attribute used during best-path selection to choose the preferred egress route, but it does not affect a route's validity or eligibility for installation. Even if this route had a lower local preference than an alternative path, BGP would still consider it a valid candidate; it would simply lose the best-path decision. A lower local preference does not cause a route to be hidden—hidden status is reserved for routes that fail structural requirements such as next-hop resolution or import policy rejection, not for routes that score lower in an attribute comparison.

The route has a longer AS path

Why wrong: AS path length is a criterion in the BGP best-path algorithm that prefers shorter paths, but it is irrelevant to whether a route can be accepted into the routing table. A longer AS path makes this route less preferred, meaning it will not be selected as active if a shorter-path route exists; however, the route is still a full-fledged BGP route and remains visible in the BGP RIB. In fact, if this were the only route for the prefix, it would be installed and active. Hidden routes are caused by fundamental acceptance failures, such as an unreachable next-hop, not by being outscored in path selection.

The route has a higher MED value

Why wrong: MED (Multi-Exit Discriminator) is a metric exchanged between autonomous systems to influence inbound traffic when multiple entry points exist into the same AS, but it does not determine route eligibility. In this exhibit, the MED is 0, identical to other candidate routes, so MED provides no differentiation at all. Even a higher MED would merely cause the route to lose a best-path comparison among routes from the same neighboring AS; the route would still be present and usable. A route is only hidden if it cannot be resolved or otherwise fails acceptance criteria—never solely because of a high MED value.

The route is from the kernel.

Why wrong: In Junos, the route type 'user' does not refer to kernel-originated routes. Kernel routes are displayed with the 'kern' type in the forwarding table, representing routes installed by the operating system itself, such as directly connected interfaces. A route listed as 'user' indicates that an administrator explicitly created it through configuration, typically as a static route, rather than it being derived from the kernel.

The route is a default route generated by the router.

Why wrong: Default routes that are generated by the router itself, such as those learned via DHCP or automatically created for internal purposes, are not assigned the 'user' type. These routes typically appear with types like 'dhcp' or 'local' and are not the result of manual configuration. The 'user' type is exclusively reserved for routes that an administrator statically defines, so a router-generated default route would show a different type.

The route was learned from a routing protocol.

Why wrong: Routes learned from dynamic routing protocols such as OSPF, BGP, or IS-IS are not labeled 'user' in Junos. Instead, they are identified by protocol-specific types like 'ospf' or 'bgp', or sometimes aggregated under 'other' for less common protocols. The 'user' type is specifically reserved for manually configured static routes, not for routes that are dynamically learned from routing updates.

Emergency messages are logged to the console only.

Why wrong: The console is configured to receive messages at severity 'warning' or higher, and since 'emerg' is the most severe severity (level 0), it is included in that threshold. Therefore, emergency messages are logged to the console, but they are not restricted to the console: the file 'messages' uses 'any any' to capture all severities, and the remote host uses 'any critical' which also includes 'emerg'. Thus, saying 'console only' is false because all three destinations receive emergency messages.

Emergency messages are logged only to the file 'messages'.

Why wrong: While it is true that the file 'messages' logs emergency messages because its severity is 'any' (all levels), the file is not the sole destination. The console's 'warning' severity threshold also captures emerg, and the remote host's 'critical' threshold does as well. Therefore, stating that emergency messages are logged 'only' to the file is incorrect, as they are also sent to the console and the remote host.

Emergency messages are logged only to the remote host.

Why wrong: The remote host does receive emergency messages because its severity level 'critical' includes more severe levels (emerg and alert), so emerg is within that range. However, the remote host is not an exclusive destination; the console with 'warning' threshold and the file with 'any' threshold both also log emergency messages. Consequently, the claim that emergency messages are logged only to the remote host is false, as they are also logged locally to the console and to the 'messages' file.