Networking Fundamentals practice questions

Source address

Why it fails: A specific source address is not a required match criterion in a Junos security policy. The policy can use 'source-address any' to match traffic from any host, so omitting a specific source address does not prevent the policy from permitting traffic. What actually defines the traffic's origin is the ingress zone, not the IP address, and without a source zone the policy cannot be evaluated.

Application

Why it fails: Application is a security policy match criterion that identifies the service (e.g., HTTP, DNS) the traffic uses, but it is entirely optional. Junos allows you to set 'application any' to match all protocols and ports, so an administrator does not have to specify an application to permit traffic. The mandatory element for a policy to permit traffic is the source zone, which determines which incoming interface's traffic the policy applies to.

Static routes always have a metric of 1.

Why it fails: Static routes do not inherently carry a metric; metrics are used by dynamic routing protocols for cost calculations. In Junos, static route selection relies on preference, not metric, and a metric is only relevant if you explicitly assign one for redistribution purposes, such as setting a metric for routes injected into OSPF or RIP. Therefore, saying static routes always have a metric of 1 is incorrect because they have no default metric at all.

Static routes are automatically redistributed into OSPF.

Why it fails: Static routes are never automatically redistributed into any dynamic protocol in Junos; redistribution must be explicitly configured using policy statements and an 'export' statement under the protocol hierarchy. For OSPF, you must define a policy that matches static routes and apply it as an export policy, otherwise OSPF only advertises its own internal and external routes. Automatic redistribution would violate routing policy principles and is not a default behavior.

The default preference for static routes is 170.

Why it fails: The value 170 is the default preference for OSPF external routes in Junos, not for static routes. Static routes have a default preference of 5, while OSPF internal routes use 10, and direct interfaces use 0. Confusing these values is a common mistake, but the 'show route' output clearly displays the preference as part of the route entry, making it easy to verify.

Check the interface error counters for CRC errors or drops.

Why it fails: Interface errors would likely cause persistent failures, not intermittent.

Verify the BGP session state and check for route flapping.

Why it fails: The BGP session is established and routes are present, so route flapping may not be the cause.

Check the MPLS label switching table to ensure labels are correctly assigned.

Why it fails: The LSP is up and labels are assigned, so this is likely not the issue.

Ethernet

Why it fails: Ethernet is a local-area network (LAN) technology designed for broadcast media and shared media access, not a WAN encapsulation for serial links. When engineers connect two routers over a serial interface, Ethernet does not apply because it lacks the framing for synchronous serial connections. While Ethernet can support subinterfaces in the form of 802.1Q VLAN subinterfaces on routed interfaces, those are for breaking up a LAN broadcast domain, not for defining multiple logical WAN circuits over a single physical serial link.

PPP

Why it fails: PPP is a widely used point-to-point WAN protocol, but it does not support subinterfaces because it is inherently a single point-to-point link with no concept of virtual circuits or multiple logical channels. A physical PPP link can only carry one network-layer session, so there is no need or mechanism for subinterface configuration. Even though PPP supports Multilink PPP (MLPPP) to bundle multiple physical links, that aggregates links outward rather than splitting a single link into multiple logical subinterfaces, which is fundamentally different from Frame Relay's NBMA virtual circuits.

HDLC

Why it fails: HDLC here refers to Cisco HDLC, which is a Cisco-proprietary point-to-point WAN encapsulation derived from the ISO HDLC standard but with an added type field for multiprotocol support. Like PPP, it operates strictly point-to-point and has no facility for virtual circuits or logical subchannels on a single serial physical interface. Because each physical HDLC link carries exactly one network path, subinterfaces are neither supported nor necessary, so it is not an option for designs requiring multiple logical circuits over one connection.

Warning: Normal but significant conditions

Why it fails: This definition is incorrect for Warning severity. Warning (level 4) indicates warning conditions—situations that are not necessarily errors but could lead to errors if not monitored. In Junos, warnings might include high memory usage or a link that is flapping, which are not 'normal' at all and are significant enough to alert an operator. 'Normal but significant conditions' is actually the definition of Notice severity, not Warning.

Notice: Warning conditions

Why it fails: This definition is incorrect for Notice severity. Notice (level 5) indicates normal but significant conditions, such as a configuration change being committed or a process starting successfully. In Junos, notice-level messages are informational and confirm that an expected event has occurred, but they do not represent warnings or impending problems. 'Warning conditions' is the definition of Warning severity, so this option is a mismatch.

The VLANs are not configured with the same VLAN ID

Why it fails: VLAN IDs are unique and define separate Layer 2 broadcast domains; inter-VLAN routing requires different VLAN IDs so that each IRB fronts a distinct subnet. If the two VLANs shared a VLAN ID, they would actually be a single broadcast domain, and the switch would have no reason to route between them—it would simply forward frames locally. Thus, mismatched VLAN IDs are not the cause of the failure; in fact, having distinct VLAN IDs is a prerequisite for inter-VLAN routing.

IP routing is not enabled globally: set routing-options router-id 10.0.0.1; set routing-options rib inet.0 static route 0.0.0.0/0 next-hop 203.0.113.1

Why it fails: Junos EX switches operate in Layer 2 mode by default, and simply creating two IRB interfaces and assigning IP addresses does not activate IP forwarding between them. To enable inter-VLAN routing, you must turn on the IP routing engine, typically by configuring a router ID under 'set routing-options router-id 10.0.0.1' or by ensuring a loopback interface exists so the RIB (inet.0) can build routes and perform next-hop resolution. Without this, packets arriving on one IRB cannot be routed to the other because the switch never performs the Layer 3 lookup required for forwarding between VLANs. The command in the correct answer also adds a default static route, which further confirms that routing is being deliberately enabled.

The switch needs an external router configured for VLAN routing

Why it fails: Junos EX series switches are Layer 3 capable and can route between VLANs internally using Integrated Routing and Bridging (IRB) interfaces. An external router is only necessary if the switch is operating in pure Layer 2 mode or if you choose to move the Layer 3 boundary outside the device—but the EX hardware already contains the routing engine and forwarding ASICs needed for inter-VLAN routing. Adding an external router would simply relocate the Layer 3 gateway without addressing the real problem: the switch's own IP routing is not globally enabled. The correct fix is to configure routing-options on the EX switch itself.

10.0.0.1

Why it fails: 10.0.0.1 is the next-hop for the default route (0.0.0.0/0), but that route is only used when no more specific prefix matches the destination. Since the packet to 192.168.1.100 matches 192.168.1.0/25 (prefix length /25), which is longer than /0, the forwarding decision ignores the default route's next-hop. Thus, 10.0.0.1 is not selected even though it would be the next-hop for any traffic without a longer match.

10.0.0.0

Why it fails: 10.0.0.0 is the network address of the subnet that likely contains the next-hop interfaces, not a unicast IP address that can be used as a next-hop. A router cannot forward packets to a network address because it is not assigned to any interface as a usable host address. Furthermore, no route entry lists 10.0.0.0 as the next-hop; it only appears as the subnet identifier. Therefore, it is nonsensical as an output of the route lookup.

Directly connected (the packet is sent directly to 192.168.1.100)

Why it fails: The destination 192.168.1.100 is not in any subnet directly attached to the router, so it cannot be reached by sending the packet directly to that IP address. A directly connected route would require an interface on the router to belong to 192.168.1.0/24 or a matching subnet, but the exhibit shows the next-hop for 192.168.1.0/25 is 10.0.0.2, indicating a remote next-hop. Even if the router had an interface in the 192.168.1.0/24 range, the longer /25 route would still take precedence for this destination. Thus, the 'directly connected' option is factually incorrect for this destination.

An IRB interface for the VLAN

Why it fails: An IRB interface provides Layer 3 functionality for a VLAN on MX or EX series.

A Layer 3 switchport

Why it fails: Layer 3 switchports are for routed ports, not VLAN interfaces.

A default gateway for the VLAN

Why it fails: Default gateway is for inter-VLAN communication, not intra-VLAN.

If no router ID is configured, the system uses the lowest IP address on an active interface.

Why it fails: Junos OSPF router-ID election takes the highest IPv4 address on a loopback interface, and only if no loopback exists does it take the highest IPv4 address on any active physical interface. Using the lowest is incorrect because the selection algorithm is explicitly highest-based: the router ID is not chosen by preferring a low numeric interface value. This distinction matters during initial bring-up and when relying on auto-derived IDs instead of configuring an explicit router ID.

The router ID must be an IP address from a directly connected interface.

Why it fails: The router ID is a 32-bit routing-options identifier that does not have to correspond to any interface on the box. You can set it to an arbitrary address, such as a management network that is not directly connected, and OSPF will still use it for adjacencies and LSA origination as long as it is unique. The idea that it must be a directly connected IP unduly ties the OSPF instance to interface reachability, which the OSPF Hello and LSA processes do not require. In Junos, 'routing-options router-id' explicitly decouples the ID from interface configuration.

The router ID is automatically derived from the MAC address.

Why it fails: OSPF router ID is an IP-derived identifier, not a hardware-derived one, so it has no relationship to MAC addresses. In Junos, the router ID is either explicitly configured as an IPv4 address or selected as the highest IPv4 address on the loopback or an active interface, which is an IP-based election. The OSPF protocol expects a 32-bit router ID value in the Router LSA, and a MAC address is 48 bits and belongs to Layer 2, so a MAC-derived approach would be non-compliant and impossible to fit the LSA field.

The router ID is not in the same subnet as the interface.

Why it fails: In OSPF, the router ID is a 32-bit identifier, typically the highest loopback or active interface IP, but it does not have to reside in the same subnet as any OSPF interface. It serves solely for router identification and protocol processes like DR/BDR election and LSA origination. OSPF neighbor adjacency depends on matching interface parameters such as area ID, timers, authentication, and MTU, not on the router ID's network. Therefore, an unrelated router ID will not prevent two routers from forming an adjacency.

The VLAN tag is missing on the interface.

Why it fails: On a Juniper MX, a missing or incorrect VLAN tag on an interface typically results in frames being untagged or tagged incorrectly, which prevents Layer 2 forwarding across the VLAN. Since OSPF sends Hello packets as IP unicast/multicast over Ethernet, the absence of the proper VLAN tag will cause Hellos to never reach the neighbor, so no adjacency can form. However, this is not an OSPF-specific issue; any IP traffic would fail, and the root cause is in the Layer 2 configuration. OSPF itself is functioning normally; it simply has no underlying connectivity to work with.

The max-lsa limit has been reached.

Why it fails: The `max-lsa` feature in OSPF is a safety mechanism that limits the number of LSAs in the database to protect against memory exhaustion or flapping neighbors. It is checked continuously, but it applies to the number of LSAs accepted for the routing table, not to the initial Hello or DBD packets that establish the neighbor relationship. Adjacency formation happens through a completely separate state machine; once a router passes the ExStart and Exchange states, it already has a full database synchronisation. If the max-lsa limit is reached, it causes the neighbor to go Down or log an error, but it does not stop the initial two-way handshake or DBD exchange. Therefore, reaching the limit is not a reason why two routers would fail to become neighbors in the first place.

Router ID

Why it fails: Incorrect: Router ID must be unique per router, but it does not need to match between neighbors.

Authentication settings

Why it fails: Incorrect: While authentication settings must match if configured, they are optional and not a required factor for all OSPF adjacencies.

Increasing the forward-delay timer

Why it fails: The forward-delay timer controls how long a port spends in listening and learning states before transitioning to forwarding. Increasing this timer makes the transition slower, not faster, thereby lengthening the convergence process whenever a topology change occurs. This is the opposite of a valid convergence-reduction technique, as it delays the time before a port can forward traffic and exacerbates the impact of any spanning-tree recalculation.

Enabling MAC address notification

Why it fails: MAC address notification is a port security or administrative feature that sends SNMP traps when new MAC addresses are learned, and is used for monitoring and auditing network access. It does not influence the spanning-tree algorithm, port state transitions, or BPDU processing, and therefore has no effect on convergence time. Since convergence is determined by STP timers and state machines, enabling MAC notification cannot reduce or accelerate spanning-tree reconfiguration.

The OSPF network type is not consistent between the two switches.

Why it fails: Mismatched OSPF network types (broadcast versus point-to-point) prevent hellos being accepted, leaving the interface DOWN with no neighbour, which matches leaf-03 while other leaves work. It is tempting because network-type mismatch is a classic adjacency fault, and it would be the cause if the interface were up and hellos were being sent but discarded.

The interface MTU is misconfigured on one side.

Why it fails: The stem states MTU is 1500 on both sides, so an MTU mismatch cannot be the cause. MTU matters because mismatched values block DBD exchange, leaving neighbours stuck in EXSTART or EXCHANGE, not the interface in DOWN with no neighbour entries at all.

Duplicate router ID on leaf-03 and spine-01.

Why it fails: A duplicate router ID would not leave the interface in DOWN; OSPF would still form adjacency on the link. Router IDs matter for identifying the device within the domain, and duplicates cause instability elsewhere, not a local interface stuck in DOWN with no neighbours.

The interface has a speed mismatch.

Why it fails: A speed mismatch on a point-to-point serial link would manifest as physical-layer problems, such as the interface failing to establish carrier or excessive CRC/alignment errors, not as a link that is up but cannot pass traffic. Because the exhibit shows the interface is enabled and the physical link is up, a speed mismatch is ruled out as the cause of the data transmission failure.

The interface is using the wrong IP address.

Why it fails: An incorrect IP address would prevent successful routing and end-to-end reachability at Layer 3, but it would not stop Layer 2 frames from being exchanged over the serial link. The interface would still come up and could pass keepalives if the encapsulation matches; the failure described is at the data-link layer. Therefore, a wrong IP address is not the reason.

The interface is administratively down.

Why it fails: The exhibit shows the interface is Enabled, meaning it has not been shut down. An administratively down interface would display Administratively down or Disabled in the output and would not allow any traffic, but that is clearly not the case here. The physical and operational states are up, so the administrative state is not the issue.

Enable MAC learning globally on the switch.

Why it fails: MAC learning is enabled by default on Juniper EX switches and does not require global activation. Disabling it is possible but uncommon. The issue is more likely a missing or inactive VLAN, not a global MAC learning setting.

Configure the interface as a trunk port.

Why it fails: A trunk port is used to carry multiple VLANs and may not be appropriate for a host that sends untagged frames. Changing to trunk mode would not necessarily fix MAC learning and could cause the host's untagged traffic to be placed in the native VLAN instead of VLAN 10.

Verify that the interface is not administratively disabled.

Why it fails: The scenario states that the interface is up and configured as an access port. If it were administratively disabled, it would be down, so this is not the issue. Checking administrative status is a basic step, but it does not address the specific problem of MAC learning in the correct VLAN.

The IRB interface does not have an IP address configured.

Why it fails: The scenario explicitly states that the IRB interface has an IP address assigned, so this cannot be the root cause. For inter-VLAN routing on Junos, each IRB unit needs an IP address in the corresponding VLAN's subnet to act as the gateway for that VLAN. If the IRB lacked an IP, hosts would have no valid gateway and traffic would never leave the VLAN, which is not the reported symptom. Since the stem confirms an address is present, this option is incorrect.

The VLANs are on different switches.

Why it fails: Inter-VLAN routing does not require the VLANs to reside on separate switches; a single switch with IRB interfaces can route between VLANs locally. Even if the VLANs extend across multiple switches, you would typically configure trunk ports and ensure the IRB exists on one switch or use an external router, but this topology alone does not break inter-VLAN routing. The symptom described—traffic failing between two VLANs—would occur regardless of the underlying switch placement if the VLAN definitions are missing. Thus, this option is not the cause.

The switch ports are not configured for VLAN tagging.

Why it fails: VLAN tagging is only necessary on trunk ports that carry multiple VLANs over a single link, not on access ports that belong to a specific VLAN. In a single-switch inter-VLAN routing scenario, the IRB interface terminates each VLAN's subnet, and the access ports forward untagged frames into their assigned VLAN. Even if you had trunk ports, the lack of tagging alone would not prevent the IRB from routing between VLANs; it would just affect how frames arrive at the switch. Therefore, this is not the cause of the reported traffic failure.

The router IDs are not the same.

Why it fails: Router IDs are 32-bit identifiers that must be unique within the OSPF routing domain. If two routers have different router IDs, that is the normal and expected condition; adjacency formation does not require router IDs to match. In fact, matching router IDs would create an error, because each router would see the other's packets as coming from itself and reject them. Therefore, the router IDs not being the same is not a fault; it is a prerequisite for a valid OSPF neighbor relationship to exist.

The area ID is not configured.

Why it fails: If the area ID were not configured, the interface would not be enabled for OSPF at all, and you would not see any neighbor entry or adjacency state. In this scenario, the adjacency reaching EXSTART means OSPF is operationally up on both ends and the routers have already exchanged Hello packets. A mismatch in area IDs would prevent the routers from even becoming neighbors, typically leaving the state at DOWN or INIT, not EXSTART. The stem indicates the configurations match in this regard, so an unconfigured or mismatched area ID is not the cause.

The hello and dead intervals are mismatched.

Why it fails: Mismatched hello and dead intervals produce failures much earlier in the OSPF neighbor discovery process. Routers only accept Hello packets that carry matching values for these timers; if they differ, the Hello packets are ignored, and the neighbor state never progresses past DOWN or INIT. EXSTART represents a far later stage, after the routers have already exchanged Hello packets and reached the 2-Way state, which proves that the hello/dead intervals were successfully matched and accepted. Thus, this option cannot explain an adjacency stuck specifically in EXSTART.

It sets the interval for VRRP advertisements.

Why it fails: VRRP priority is a numeric value used exclusively for electing the master router, not for controlling timing. Advertisement intervals are configured independently via the 'advertise-interval' parameter, which dictates how often a master sends VRRP advertisements to notify other group members of its presence. Changing the priority has no effect on the frequency or timing of these packets, so this option is incorrect.

It determines the virtual MAC address.

Why it fails: VRRP's virtual MAC address is generated algorithmically from the Virtual Router ID (VRID), not from any priority value. For IPv4, the virtual MAC is 00:00:5e:00:01:xx, where xx is the VRID in hexadecimal, so priority does not appear anywhere in the address. Reconfiguring priority will never alter the MAC address that hosts use as their gateway's Layer 2 address, making this option incorrect.

It changes the virtual IP address.

Why it fails: The virtual IP address is an administratively configured address that represents the default gateway for clients, and it remains unchanged regardless of which physical router is active. Priority only determines which participating router assumes the master role to forward packets; it does not modify or reassign the virtual IP itself. Therefore, even if one router has a much higher priority, the virtual IP address stays the same, ensuring seamless failover without impacting client configurations.

show interfaces terse

Why it fails: The 'show interfaces terse' command outputs only a one-line summary per interface, showing administrative status, link status, and IPv4/IPv6 addresses. It deliberately omits data-link encapsulation details such as PPP or HDLC, making it unsuitable for verifying that both routers use the same encapsulation. This command is intended for a quick health check of interface state and IP addressing, not for diagnosing layer-2 framing mismatches. Relying on it here would miss the specific information needed to confirm encapsulation compatibility.

show configuration interfaces

Why it fails: The 'show configuration interfaces' command displays the configured settings for the interface from the candidate or active configuration, which might include an explicit encapsulation statement. However, it shows only the intended configuration, not the operational state or whether the encapsulation negotiation has succeeded. If the encapsulation is left at the default (e.g., HDLC on serial links), the command may not display it at all, lulling the engineer into thinking it is correct. A true verification requires the operational state shown by 'show interfaces extensive', which also exposes any mismatch between the local and remote encapsulation.

monitor traffic interface

Why it fails: The 'monitor traffic interface' command captures and displays packet data in real time, showing headers like Ethernet type or PPP protocol field, but it does not reveal the router's configured encapsulation parameter. You might see what encapsulation appears to be on the wire, but you cannot determine if the router is intentionally configured for that encapsulation or if it is a mismatch. Additionally, it is a troubleshooting tool for observing traffic flow, not a configuration inspection tool. It would not show whether the local interface's encapsulation setting matches the peer's configured setting.

Host route for the gateway

Why it fails: A host route for the gateway is a /32 entry that applies only to that single IP address. Because the server already has a connected route for its local subnet, the gateway is already reachable; this host route adds nothing for off-subnet traffic. Every other destination would still have no route, so the server cannot reach anything beyond its local network.

Dynamic route via OSPF

Why it fails: Running OSPF on a server is almost never appropriate because OSPF is a dynamic routing protocol designed for routers managing multiple interfaces and complex topologies. A server would need to form adjacencies with neighboring routers, and if misconfigured it could advertise unintended routes or cause routing instability. Furthermore, the question's scenario of 'configuring a new subnet' for servers does not call for the overhead of a routing protocol; a simple default route is the correct, minimal solution.

Static route to each other server

Why it fails: Creating a static route for each other server on the network is unnecessary for two reasons: if the servers are on the same LAN, the connected interface route already provides reachability; if they are on different subnets, the default route through the gateway can deliver the packets. Manually enumerating every destination is not only redundant but also unscalable—any new server added would require another route. This approach also violates the principle of using the least specific route that works.