Routing Fundamentals practice questions

show log messages

Why wrong: The 'show log messages' command is used to inspect system event and error logs, such as daemon failures or interface flapping events. While these logs can give clues about why a connectivity issue occurred, they do not display the routing table or the current forwarding state. This makes it a diagnostic tool for historical context, not for verifying whether a route to a destination exists.

show configuration

Why wrong: The 'show configuration' command outputs the applied configuration in either set or hierarchy format, detailing static routes, protocols, and interfaces as they are configured. However, it shows only the intended or configured state, not the dynamically learned routes or active routing table entries. A route may be configured but still not be active in the routing table due to an error, so this command cannot confirm the actual routing state.

show interface

Why wrong: The 'show interface' command provides information about physical and logical interface properties, including link status, input/output errors, and protocol state (e.g., up/down). This is useful for verifying Layer 1 and Layer 2 connectivity, but it does not provide Layer 3 route information. Even if all interfaces show 'up', a route may still be missing or the next hop may be unreachable, so this command cannot be used to troubleshoot routing-table-level issues.

Both routes, if they are equal-cost.

Why wrong: Equal-cost multipath (ECMP) only applies when two routes to the same prefix share the same preference and the same metric. Because a static route defaults to preference 5 and OSPF internal routes default to preference 10, these routes are not equal-cost regardless of their metric values. The router will select the static route as the active route, and no load balancing across both will occur.

The route with the higher preference value.

Why wrong: In Junos, preference is an administrative distance that signifies how much the router trusts the source that supplied the route; lower numeric values denote higher priority. Selecting a route with a higher preference value would mean trusting a less reliable protocol over a more reliable one, which is the opposite of Junos behavior. The route with the higher preference (e.g., OSPF at 10) is only used if the lower-preference route disappears.

The OSPF route, because OSPF is a dynamic routing protocol.

Why wrong: Protocol type alone does not determine route selection; Junos assigns a default preference to each protocol based on its trustworthiness and administrative control. OSPF is dynamic, but its internal routes carry a preference of 10, which is higher than the static route's 5. Being dynamic does not auto-prioritize a route; in fact, static routes are often deliberately given a lower preference so operators can precisely control routing decisions.

All routes in the routing table are active.

Why wrong: This is false because Junos keeps routes from multiple sources (e.g., OSPF, IS-IS, static, BGP) in the routing table, and each routing instance's table can contain several routes for the same prefix while only the route with the best route preference is marked active. The remaining routes are retained as inactive, so the routing table always contains a mix of active and inactive routes. Only the active route is considered for forwarding, which is why this statement is incorrect.

Multiple active routes can exist for the same prefix.

Why wrong: By default, Junos installs only one active route per prefix in a routing table, chosen by the lowest route preference and then, if necessary, by tie-breakers such as the origin protocol's internal metrics. Even when equal-cost multipath (ECMP) is configured, the active route is a single route object that carries multiple equal-cost next hops, rather than multiple separate active routes. Therefore, the statement is false as a general rule, and the ECMP exception still does not create multiple active routes for the same prefix.

An active route is always preferred over a passive route.

Why wrong: Junos does not define 'passive routes' as a routing-table state, so the claim is not meaningful in the context of Junos. The routing table categories are active (selected as the best) and inactive (non-best routes held from other protocols), and route preference is a numeric value assigned to protocols, not a comparison between an active and a 'passive' candidate. An inactive route with a higher preference value can become active if the current active route is withdrawn, but there is never a case where both an active and a passive route compete for the same prefix because 'passive' refers to a different feature, such as passive OSPF interfaces.

The preference of a static route cannot be changed.

Why wrong: The preference of a static route is not fixed—it can be adjusted using the 'preference' statement at the [edit routing-options static route] hierarchy level. You can set a custom preference value for a route or for a specific qualified next hop. This is commonly done to make a static route less preferred than a dynamic route, or to create a backup static route that only becomes active when no better route exists.

Static routes automatically update if the next hop becomes unreachable.

Why wrong: Static routes do not dynamically react to network changes; they remain in the routing table even if the next hop becomes unreachable. There is no built-in mechanism that automatically withdraws or updates a static route. To provide failover behavior, you must rely on additional features such as qualified next hops, routing protocols that detect failures, or external monitoring, because the static route itself will keep pointing to the dead next hop until manually removed or overridden.

BGP routes

Why wrong: BGP is an exterior gateway protocol that establishes TCP sessions with peers and exchanges prefixes as it learns them. Because these routes depend on the BGP process, its neighbors, and the network state, they are dynamically learned and cannot be considered protocol-independent. Their presence in the routing table is entirely contingent on BGP's operation.

OSPF routes

Why wrong: OSPF is a link-state interior gateway protocol that builds adjacencies, floods link-state advertisements, and runs Dijkstra's algorithm to compute routes. All OSPF routes are dynamically discovered and derived from the state of the OSPF domain. Because they result from a running dynamic protocol, they are not protocol-independent.

1

Why wrong: The exhibit actually contains two separate static route entries for 0.0.0.0/0, each with its own next-hop and preference. A candidate might count only the active instance in the forwarding table, but the configuration shows both routes. Therefore, answering 1 undercounts the static default routes that are explicitly configured.

0

Why wrong: The two routes shown in the exhibit are clearly static default routes because they have a protocol/code of 'S' and a destination prefix of 0.0.0.0/0. Even though there are two routes with different preferences, both are configured static entries. Selecting 0 incorrectly assumes that default routes are always dynamically learned, but these are statically defined.

3

Why wrong: Only two routes for 0.0.0.0/0 appear in the exhibit, not three. A third route might be imagined if you mistakenly include a default route from an interior gateway protocol like OSPF or BGP, but the exhibit shows exactly two static entries. Therefore, choosing 3 introduces a non-existent route.

Both routes are active.

Why wrong: Only one route can be active for a prefix.

The static route because it has a lower preference.

Why wrong: The static route (preference 5) is not active; the OSPF route (preference 10) is active.

Neither route is active.

Why wrong: The OSPF route is active.

show route protocol

Why wrong: `show route protocol` is incomplete because it requires a protocol name, such as `show route protocol ospf`, to function correctly. Even when a protocol is supplied, it lists every route learned via that protocol, not a route to a specific IP address. This command serves protocol-level troubleshooting, but it cannot directly answer a question about a particular host or subnet.

show route active

Why wrong: `show route active` displays only the active routes, meaning those currently installed in the forwarding table, but it does not accept a destination address as part of the command. Instead, it lists all active prefixes in the routing table, which can be extensive, and provides no way to isolate a single IP. The `active` keyword is a state filter, not a destination filter, so it cannot show the route to 192.168.1.1.

show route table

Why wrong: `show route table` is meant to display the contents of a specified routing table, like `show route table inet.0`, and without a prefix argument it dumps every route in that table. The command accepts a table name, not a destination IP, so it will not narrow down to a specific address. To view the route for 192.168.1.1, you must use the `show route` command followed directly by that IP address.

Community list

Why wrong: A community list is a match condition used within a routing policy to identify routes carrying specific BGP community values. However, simply configuring a community list has no direct effect on the routing table; it must be embedded in a policy statement with an action such as accept or reject, and that policy must be applied in the import direction. Therefore, a community list is not a standalone route-filtering mechanism—it is a matching tool that only works in combination with a routing policy.

Prefix list

Why wrong: A prefix list is a building block that defines a set of IP prefixes for matching purposes, but it cannot filter routes by itself. It must be referenced inside a routing policy statement as a match condition, and that policy must then be applied in the import direction to actually prevent a route from entering the routing table. Without being tied to a policy action, a prefix list is simply an inert object with no filtering capability.

Firewall filter

Why wrong: Firewall filters operate in the data plane, inspecting packet headers and determining whether each packet should be forwarded or dropped. They do not evaluate route advertisements or interact with the routing table's control plane, so they have no ability to prevent a route from being installed. Even if a firewall filter drops all traffic matching a route, the route can still exist in the routing table and be advertised to peers; therefore, it is not a valid tool for route filtering.

Protocol type

Why wrong: Protocol type is not a direct selection attribute in Junos route selection because it is already factored into the route preference. Each protocol (e.g., Direct, Static, OSPF, IS-IS) has a default preference value that encodes its desirability, such as Direct=0, Static=5, and OSPF=10. Since these protocol-derived preferences are compared, the protocol type itself is not separately evaluated. Thus, saying protocol type is a selection attribute is misleading; only the resulting preference matters.

Next hop address

Why wrong: The next-hop address describes the immediate next router or interface used to forward packets, but it plays no role in determining which route becomes active in the routing table. Route selection in Junos is based solely on preference and metric; next-hop information is not evaluated as a criterion. Only after a route is selected does the next hop matter, as it defines the forwarding path. If two routes have equal preference and metric, Junos may load-balance across both next hops rather than choosing one based on the address.

AS path length

Why wrong: AS path length is a BGP-specific attribute used in the BGP path selection algorithm, not in Junos's general active-route selection process. The general Junos route selection compares preference and metric across all routing protocols, and AS path length does not exist for non-BGP routes. Even for BGP routes, AS path length is considered only after BGP-specific attributes like local preference and origin, and it is not the generic criterion the question asks about. Therefore, it is incorrect to list AS path length as a Junos route selection attribute.

10

Why wrong: A default route preference of 10 is assigned to OSPF internal routes, not direct routes. In Junos, OSPF intra-area and inter-area routes inherently have a higher preference (lower preference value) than many other protocols, but they still cannot compete with direct routes. Direct routes always take precedence because preference 0 is lower than 10. Mistaking OSPF's value for direct routes is a common confusion.

5

Why wrong: Static routes have a default preference of 5 in Junos, which is why some might guess this value. However, direct routes are even more preferred because they use preference 0. Static routes are administratively configured, while direct routes are automatically derived from interface addresses, so Junos gives the automatic local routes the absolute highest preference. This distinction prevents accidentally overriding a directly connected network with a static route.

15

Why wrong: There is no standard Junos routing protocol or route type that uses a default preference of 15. Actually, you might see preference values like 15 for certain internal or vendor-specific cases, but in standard Junos defaults, direct routes are 0, static 5, OSPF 10, and other protocols have various values (e.g., RIP 100, BGP 170). Since 15 is not assigned to any common protocol, it cannot be the default preference for direct routes. It would be an arbitrary value.

show interfaces terse

Why wrong: Incorrect. 'show interfaces terse' shows interface status and IP addresses but not routing table entries.

show configuration interfaces

Why wrong: Incorrect. 'show configuration interfaces' displays the interface configuration, not the routing table.

show arp

Why wrong: Incorrect. 'show arp' shows ARP cache entries (IP-to-MAC mappings) and does not display routing table information.

Static routes require OSPF to be enabled on the router.

Why wrong: Static routes are manually configured entries in the routing table and are completely independent of any dynamic routing protocol such as OSPF. OSPF is only relevant if you want to advertise or redistribute the static route into the OSPF domain, but the static route itself functions without any routing protocol running. Therefore, the statement that OSPF must be enabled is false.

Static routes automatically generate ICMP redirect messages.

Why wrong: ICMP redirect messages are generated by the forwarding engine when a packet is forwarded out the same interface it arrived on and a better next-hop is known, typically as a result of dynamic routing or forwarding decisions. A static route does not automatically trigger ICMP redirects; redirect generation is controlled by the forwarding behavior and platform settings, and is often disabled for security reasons. Hence, this statement is incorrect.

The default route (0.0.0.0/0)

Why wrong: The default route (0.0.0.0/0) has a prefix length of 0, making it the least specific match. For destination 172.16.1.100, the static route to 172.16.0.0/16 has a longer prefix length and is therefore preferred by Junos's longest-prefix-match logic. The default route is only consulted when no other route with a more specific prefix exists.

The router will drop the packet.

Why wrong: A router drops a packet only when no matching route is found or the selected next hop is unreachable. Here, the destination 172.16.1.100 matches the static route to 172.16.0.0/16, which has a valid next hop, so the packet is forwarded rather than discarded. The existence of a valid matching route invalidates the drop scenario.

The static route to 10.0.0.0/8

Why wrong: The static route to 10.0.0.0/8 is not a candidate because 172.16.1.100 is not within that prefix range — it begins with 172, not 10. The address belongs to the 172.16.0.0/12 block, and more specifically to the configured 172.16.0.0/16 route. A route can only be selected if the destination address is mathematically contained within the route's prefix.

DNS resolution is failing on the host.

Why wrong: DNS resolution is not relevant because the test uses a ping to an IP address, not a hostname.

The default route is not active on the router.

Why wrong: The default route is active on the router, as verified by 'show route 0.0.0.0/0'.

Proxy ARP is not enabled on the router's internal interface.

Why wrong: Proxy ARP is not required for a directly connected host. The router can deliver return traffic to the host using standard ARP for the host's IP on the internal subnet.

Static routes have a default preference value of 10.

Why wrong: The default preference for static routes in Junos is 5, not 10; a preference of 10 is typically associated with OSPF internal routes. Route preference is a metric for comparing routes from different protocols, where a lower value is more preferred. Since static routes are more trusted than most dynamic protocol routes, Junos assigns them a low default preference of 5.

Static routes require a routing protocol to be activated.

Why wrong: Static routes are manually configured using the "set routing-options static" hierarchy and require no underlying routing protocol to function; they are installed directly by the routing engine. Routing protocols are only needed for dynamic route discovery, neighbor adjacency, or route exchange, none of which apply to static routes. Even on a device running no routing protocol at all, static routes work normally.

Static routes are automatically updated if the network topology changes.

Why wrong: Static routes never change on their own; if the network topology changes, an administrator must manually edit or remove the static route configuration. They do not react to interface down events, metric changes, or path failures like dynamic routing protocols do. This is why static routes are best suited for small, stable networks or for stub/edge connections with predictable paths.

show route 192.168.1.2

Why wrong: The `show route 192.168.1.2` command performs a longest-prefix-match lookup for that specific destination in the inet.0 routing table. Even with a default static route configured, the output will display the most specific route covering 192.168.1.2—such as a directly connected subnet or a more specific learned route—not the 0.0.0.0/0 default entry. This command is useful for troubleshooting a particular prefix, but it does not directly verify the existence or next-hop of the default route. To explicitly check the default route, you must query the 0.0.0.0/0 prefix.

ping 192.168.1.2

Why wrong: The `ping 192.168.1.2` command tests end-to-end IP connectivity by sending ICMP echo requests and observing replies; it does not display any routing table information. A successful ping may depend on the default route for forwarding, but it also relies on ARP resolution, firewall filters, and the return path, so it cannot confirm that the static default route is present or correctly configured. Additionally, ping will succeed even if the default route is absent but a more specific route exists for that destination, making it completely unreliable for verifying the default route. The output only shows packet loss and round-trip times, never the next-hop or route preference.

show route protocol static

Why wrong: The `show route protocol static` command filters the routing table to display all routes learned from the static protocol, which can include numerous unrelated static entries. While the 0.0.0.0/0 default route will appear in this output, you must scan through every static route to find it, and if any static routes are hidden (e.g., rejected by route resolution), they may not appear in the default view. This command is broader and less direct than a targeted `show route 0.0.0.0/0`, but it can be useful for auditing all static routes at once. For quickly confirming the default route's next-hop, however, it introduces unnecessary noise.

IS-IS: Uses a distance-vector algorithm with split horizon

Why wrong: IS-IS is actually a link-state protocol, not a distance-vector protocol. It uses its own hello PDUs and link-state PDUs to build a topology database, similar to OSPF, and runs the Dijkstra SPF algorithm to compute routes. The notion of split horizon applies to distance-vector protocols like RIP, so this pairing is incorrect.

Static route: Learned dynamically through routing protocols

Why wrong: Static routes are explicitly configured by an administrator, rather than being learned dynamically through routing protocols. Because they never change automatically when network conditions shift, an incorrectly configured or outdated static route can cause black holes until manually updated. This distinguishes static routing from dynamic protocols such as OSPF or BGP, which adapt to topology changes on their own.

BGP: Uses distance-vector algorithm with link-state updates

Why wrong: BGP is a path-vector protocol, so describing it as a distance-vector algorithm with link-state updates is a contradiction. BGP does not use periodic full-table distance-vector updates, nor does it flood link-state advertisements; instead it sends incremental path updates containing AS-path and attributes. This classification error conflates three distinct protocol mechanisms into a single incorrect description.

system: Configures routing protocols like OSPF and BGP.

Why wrong: Assigning routing protocols like OSPF and BGP to the 'system' hierarchy is incorrect because Junos reserves a separate top-level hierarchy named 'protocols' for all routing protocol configuration. While the 'system' hierarchy can indirectly affect protocol operation through global parameters like time source, it never contains protocol-specific statements such as 'ospf' or 'bgp'. Proper Junos configuration requires strict separation of concerns: system-level device settings under 'system', protocol instances under 'protocols'.

interfaces: Configures security policies and zones.

Why wrong: Security policies and zones belong under the 'security' hierarchy, specifically within 'security zones' and 'security policies', not under 'interfaces'. Interfaces are bound to zones through the 'security zones' section, but the interfaces hierarchy itself is limited to physical and logical properties like addressing and encapsulation. Attempting to configure zone-based policy under 'interfaces' would be rejected by the Junos schema and demonstrates a misunderstanding of where security abstractions reside in the configuration model.

Configure a static route for 203.0.113.0/24 with a lower preference.

Why wrong: Configuring a static route with a lower preference (administrative distance) for 203.0.113.0/24 would install it in the routing table ahead of the OSPF route, because lower preference values are preferred. This overrides OSPF's dynamic path selection entirely, meaning the router no longer follows OSPF's cost-based decisions or reacts to OSPF topology changes. A static route does not monitor OSPF neighbor state or link health, so if the designated interface fails, the statically routed traffic will be blackholed or fail to failover, eliminating the redundancy that OSPF is supposed to provide.

Use policy-options to set a higher preference for one of the paths.

Why wrong: Junos route preference is a protocol-level value, not a per-path attribute; OSPF routes share one preference, so a policy that raises preference for one OSPF route would apply to all OSPF routes or require complex matching that still doesn't reflect OSPF's cost. Altering preference via policy-options changes how the routing table compares OSPF with other protocols, not how OSPF selects among its own paths. OSPF already has a built-in mechanism, the metric, to differentiate paths, so trying to manipulate preference per interface is both the wrong tool and ineffective for creating a primary/backup relationship.

Modify the load-balance configuration under forwarding-options.

Why wrong: Load balancing under forwarding-options controls how traffic is spread across multiple equal-cost next hops, such as per-flow or per-packet distribution. It only activates when the routing table has two or more routes with identical preference and metric; a backup interface with a higher OSPF metric is not equal-cost, so load balancing would never split traffic to it. Configuring load balancing does nothing to change the OSPF metric or preference, so it cannot designate one path as primary and the other as backup. This option would at best cause the router to alternate traffic across both paths if they were equal-cost, which is the opposite of the desired active/backup behavior.