Networking Fundamentals practice questions

Source address

Why wrong: 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 wrong: 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.

It sets the interval for VRRP advertisements.

Why wrong: 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 wrong: 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 wrong: 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.

Static routes always have a metric of 1.

Why wrong: 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 wrong: 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 wrong: 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.

Ethernet

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 VLAN is not allowed on the trunk between the switches

Why wrong: When hosts are in the same VLAN but the trunk port connecting the switches does not have that VLAN in its allowed list, the switches will not forward frames for that VLAN across the trunk. Even though each switch learns MAC addresses from its own access ports, the frames sent between hosts never traverse the trunk because the VLAN is pruned or not permitted. This causes Layer 2 connectivity failure despite both MAC entries being present in the respective switches' forwarding tables.

The ARP cache on the hosts is stale

Why wrong: A stale ARP cache would cause a host to send unicast frames to an incorrect MAC address, so the frames would reach the wrong port. In that case, the switch would still have learned the correct MAC addresses for both hosts on their access ports, but the frames would not be delivered to the intended destination. The presence of both MAC entries in the switch table indicates that frames have been successfully sent and received at Layer 2, which would not happen if a stale ARP cache prevented proper frame delivery.

Spanning Tree Protocol is blocking a port

Why wrong: If STP were blocking a port on the trunk between the switches, that port would not forward frames, and the switches would not learn MAC addresses on that port. However, the troubleshooting output shows that both switches have MAC table entries for the hosts on their access ports, which means the access ports are forwarding normally. STP blocking would not explain why both MAC entries are present while connectivity fails; it would instead prevent MAC learning on the blocked port.

The VLANs are not configured with the same VLAN ID

Why wrong: 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 wrong: 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 wrong: 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.

The routers are in different OSPF areas

Why wrong: OSPF requires all routers on a shared link to belong to the same area. If one router is configured with area 0 and the other with area 1, the Area ID field in the hello packet does not match, so the receiving router discards the packet before any neighbor state is formed. This definitely prevents adjacency, but it is less common on a simple two-router point-to-point Ethernet link than a hello/dead interval mismatch, which is the more typical configuration error.

OSPF authentication is configured on one router but not the other

Why wrong: When OSPF authentication is enabled on an interface, every hello packet carries an authentication type and key in the OSPF header. If one router is configured with MD5 authentication (type 2) or a plain-text password (type 1), and the other router expects no authentication (type 0), each side rejects the received hello because the authentication fields do not match local expectations. This mismatch produces explicit error messages such as 'OSPF packet authentication failed,' so it is not a silent failure like the interval mismatch—making it a distinct and less likely cause in this scenario.

The routers have the same router ID

Why wrong: A router ID is a unique 32-bit identifier, typically derived from the highest loopback address. If two directly connected routers are configured with the same router ID, each sees the other's hello advertising its own RID, causing the routing process to regard the neighbor as invalid and refuse to establish an adjacency. Duplicate RIDs can also lead to routing instability and blackholes, but in a straightforward two-router setup, this is an uncommon misconfiguration; a hello/dead interval mismatch is far more frequent and is the correct answer here.

ARP request is sent to a multicast MAC address

Why wrong: ARP does not use multicast for its requests. Layer 2 multicast MAC addresses (e.g., 01:00:5E:...) are utilized by protocols such as IGMP or IPv6 Neighbor Discovery, but IPv4 ARP specifically uses the broadcast address. Furthermore, multicast would require a defined group membership, which does not exist for the purpose of address resolution in IPv4.

ARP reply is sent to the broadcast MAC address

Why wrong: If ARP replies were sent to the broadcast address, every host on the subnet would be forced to process and discard the frame, wasting bandwidth and CPU cycles. The replying host already knows the requester's MAC address from the source address field of the ARP request, so it can send a unicast reply directly. Broadcasting replies would violate the efficiency design of ARP and introduce unnecessary network overhead.

ARP is used for both IPv4 and IPv6

Why wrong: ARP is strictly an IPv4 protocol; IPv6 uses Neighbor Discovery Protocol (NDP) instead. NDP relies on ICMPv6 messages and solicited-node multicast addresses to perform address resolution and also handles tasks like duplicate address detection and router discovery, which ARP does not. Thus saying ARP is used for both IPv4 and IPv6 is incorrect.

VLAN tag (802.1Q)

Why wrong: The VLAN tag (802.1Q) is an optional 4-byte field inserted between the Source MAC address and the EtherType field only when a frame traverses a VLAN-trunking interface. It contains a Tag Protocol Identifier (TPID) of 0x8100 and a Tag Control Information (TCI) that carries the VLAN ID and priority bits. Standard untagged or access-port frames do not include this field, so it is not a mandatory header component.

Frame Check Sequence (FCS)

Why wrong: The Frame Check Sequence (FCS) is a 4-byte CRC value placed at the very end of the Ethernet frame, after the payload, and thus belongs to the frame trailer rather than the header. It is calculated over the entire frame contents on transmission and verified upon reception, enabling the network adapter to discard frames corrupted by bit errors. Because it does not contain addressing or protocol information and is not located at the beginning of the frame, it cannot be considered a header field.

Hosts in different VLANs can communicate without any additional configuration

Why wrong: VLANs segment into separate broadcast domains; without routing, hosts on different VLANs cannot exchange frames at Layer 2. A Layer 3 device such as a router or an EX Series switch with an IRB interface must be configured to forward traffic between VLANs. Thus, this statement is false as it ignores the necessity of Layer 3 routing.

VLANs are automatically created when you assign an interface to an untagged VLAN

Why wrong: On Junos, you cannot assign an interface to a nonexistent VLAN; the VLAN (or bridge domain) must first be defined in configuration, then the interface can be bound to it. Even if you assign an interface to an access (untagged) port, the VLAN entry must exist as a configuration element. Unlike some platforms that auto-create VLANs, Junos requires explicit configuration of the VLAN so that its ID, name, and associated routing or filtering options are clear.

10.0.0.1

Why wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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.

Manually specify the root bridge and root port.

Why wrong: Manually specifying the root bridge and root port determines the logical STP topology by electing the root switch and designating the forwarding paths toward it, but it does not alter the mandatory port state progression. Every non-edge port must still pass through blocking, listening, and learning states for the Forward Delay timer (default 15 seconds each in classic STP, or the equivalent synchronization process in RSTP) before reaching forwarding. Manual configuration just guarantees which ports become root and designated ports; it cannot skip the 30-second (or configured) convergence delay.

Use link aggregation to bundle multiple links.

Why wrong: Link aggregation (e.g., LACP or static EtherChannel) bundles multiple physical links into one logical link, which STP treats as a single port. This reduces the total number of logical ports STP must evaluate and can simplify the topology, but it does not change STP timer behavior or the state transition process for the bundle's logical port. The aggregated port itself still must complete the listening and learning stages unless it is configured as an edge port, so link aggregation alone does not speed up convergence.

Increase the hello timer to speed up BPDU exchange.

Why wrong: Increasing the hello timer (default 2 seconds) makes BPDUs less frequent, which actually slows down the detection of topology changes and makes the STP algorithm respond more slowly. The hello interval is also the base for the Max Age and Forward Delay calculations (typically 2 seconds, 20 seconds, and 15 seconds respectively in classic STP), so changing it without adjusting those timers can lead to inconsistent and unstable topology convergence. Configuring a shorter hello timer could fail to give remote switches enough time to receive BPDUs, increasing the risk of temporary loops, while longer hello delays convergence further.

show log messages

Why wrong: show log messages is for examining the system logging facility, which records events such as interface transitions or error alerts. However, it does not provide a consolidated, cumulative view of interface error counters; it only shows individual log entries at the time they occurred. Even if an error is logged, you cannot use that output to see current counts of CRC errors, drops, or framing errors, so it's not the right tool for this task.

show configuration interfaces ge-0/0/0

Why wrong: show configuration interfaces ge-0/0/0 displays only the configuration hierarchy from the configuration database, such as family settings, unit numbers, and interface properties. It conveys nothing about live operational state or real-time error counters, since those values exist only in the operational datastore and are not stored as configuration statements. Configuration output cannot reveal CRC or framing errors, so this command is wrong for an operational troubleshooting task.

show interfaces ge-0/0/0 terse

Why wrong: show interfaces ge-0/0/0 terse provides a condensed, one-line-per-unit summary showing only administrative and operational status, such as link up/down and protocol state. It does not include error counters, packet statistics, or queue information, so it cannot reveal issues like CRC errors or drops. Terse format is meant for a quick high-level overview, not for detailed per-interface fault analysis, which is why it is not the correct choice.

The native VLAN cannot be changed after initial configuration.

Why wrong: In Junos, the native VLAN is not a permanent, immutable value: it is a per-interface setting in the ethernet-switching family configuration, and you can change it at any time with the `native-vlan` statement (e.g., `set interfaces ge-0/0/1 unit 0 family ethernet-switching native-vlan sales`). The running configuration is updated immediately and no reboot or complete trunk rebuild is required. Thus, claiming it cannot be changed after initial configuration misrepresents a simple, live-updatable parameter.

Frames in the native VLAN are always tagged with the VLAN ID on the trunk.

Why wrong: IEEE 802.1Q trunk links carry frames from multiple VLANs by adding a 4-byte tag, but each trunk is also allowed to designate one native VLAN whose frames are transmitted without any tag — and on arrival, those untagged frames are placed into that same native VLAN. Therefore, the statement that native VLAN frames are 'always tagged' directly contradicts how a native VLAN works; the entire point is to leave those frames untagged, often to interoperate with legacy devices or to support mixed-format traffic. On Junos, you explicitly configure the native VLAN to control which untagged packets are associated with which VLAN.

The native VLAN must be the same as the management VLAN.

Why wrong: The native VLAN and the management VLAN are conceptually separate: the native VLAN is a layer-2 trunk-port property that handles untagged frames, while the management VLAN is a layer-3 construct used for out-of-band or in-band management access (SSH/SNMP/CLI). On a Junos device, the management interface could be a separate routing (RE) port (like `me0`) or a VLAN with an IRB interface, and that VLAN is wholly independent of the trunk's native VLAN setting. There is no Junos requirement that the management VLAN equal the native VLAN; they are different configuration namespaces, and you can set them to any values you need.

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

Why wrong: 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 wrong: 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 wrong: 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.

MAC addresses are shared across VLANs.

Why wrong: MAC addresses are tied to individual network interfaces, and a switch maintains a separate MAC forwarding table (or forwarding database) per VLAN. A host's MAC address is not globally 'shared' across VLANs; the switch learns it in the context of a specific VLAN and uses it only when forwarding frames within that VLAN. Even if a device is multi-homed into multiple VLANs, it uses distinct MAC addresses for each interface or virtual interface, so the original statement is incorrect.

Each VLAN must be assigned a unique IP subnet.

Why wrong: VLANs operate at Layer 2 and do not inherently require an IP subnet; IP addressing is a Layer 3 concern. While it is a common best practice to map one VLAN to one IP subnet to simplify routing, you could have multiple VLANs sharing the same subnet or a single VLAN with multiple subnets, though this often creates routing complexities. The word 'must' makes the statement false because it is a recommendation, not a protocol requirement.

A single switch port can belong to only one VLAN.

Why wrong: While an access port is indeed assigned to a single untagged VLAN, a trunk port can be a member of many VLANs simultaneously by carrying tagged traffic for each of those VLANs. Trunk ports use VLAN tagging (802.1Q) to identify which VLAN a frame belongs to, so a single switch port can belong to multiple VLANs. The statement is therefore an overgeneralization that ignores trunk links, which are common in enterprise networks.

Router ID

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

Authentication settings

Why wrong: 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 wrong: 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 wrong: 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.