Layer 3 Technologies practice questions

The authentication keys are mismatched.

Why it fails: While mismatched authentication can prevent adjacency, the scenario does not mention authentication being configured. It is a possible cause, but less likely than K-value mismatch because authentication is not always used. The administrator would typically check authentication after verifying basic parameters. Without evidence of authentication configuration, K-values are a more probable cause.

The hello timer intervals are mismatched.

Why it fails: EIGRP hello timers do not need to match for an adjacency to form. The hello interval is used to determine how often hello packets are sent, but mismatched timers can lead to neighbor relationships flapping or dropping, not a failure to form. The hold time is what must be compatible, but even that is not a strict requirement for initial adjacency formation.

The autonomous system numbers are different.

Why it fails: The scenario explicitly states that the autonomous system numbers match. Therefore, this cannot be the cause. EIGRP requires matching AS numbers for adjacency, but since they are already verified as matching, this option is incorrect. The administrator has already ruled this out, so it is not the most likely cause.

The EIGRP hello timer is mismatched.

Why it fails: EIGRP hello timers do not need to match for adjacency formation. Unlike OSPF, EIGRP does not require matching hello intervals. The routers will form an adjacency even if hello timers differ, as long as other parameters match. Therefore, a hello timer mismatch would not prevent adjacency formation and is not the cause.

EIGRP authentication is configured with different passwords.

Why it fails: Authentication mismatches do cause adjacency failures, but the administrator stated that no ACLs are blocking traffic and did not mention authentication. Authentication is an additional configuration that must be explicitly set; if it were the cause, the administrator would likely have seen authentication error messages. Thus, it is less likely than an AS number mismatch.

The EIGRP K-values are mismatched.

Why it fails: While mismatched K-values will prevent adjacency formation, this is less common than an AS number mismatch. K-values are typically left at default, and changing them requires explicit configuration. Since the administrator has not mentioned changing K-values, it is less likely. The AS number mismatch is a more frequent oversight in multi-router configurations.

The router IDs are not unique.

Why it fails: Duplicate router IDs in OSPFv3 can cause instability and prevent adjacency, but the symptom is usually a stuck in INIT or 2-WAY state, or frequent flapping. EXSTART is specifically related to the master/slave negotiation and DBD exchange, which is more commonly affected by MTU mismatches than duplicate router IDs.

The router interfaces have different OSPFv3 network types.

Why it fails: Different OSPFv3 network types can cause adjacency issues, but typically result in a mismatch in DR/BDR election or hello timers, leading to a stuck in INIT or 2-WAY state, not EXSTART. EXSTART indicates a problem with the master/slave negotiation, often due to MTU mismatch or duplicate router IDs.

The OSPFv3 process ID is different on each router.

Why it fails: The OSPFv3 process ID is locally significant and does not need to match between neighbors. Different process IDs do not affect adjacency formation; the routers will still form an adjacency as long as other parameters like area ID, hello timers, and MTU match. Therefore, this is not the cause of the EXSTART issue.

Ensure that the interface IP addresses are on the same subnet.

Why it fails: If the interface IP addresses were not on the same subnet, the routers would not form a neighbor relationship at all, and the neighbor would not appear in the output of show ip eigrp neighbors. Since the neighbor is present but stuck in EXSTART, IP addressing is not the issue. Verifying subnet correctness is a basic step, but it does not address the EXSTART problem.

Configure the same autonomous system number on both routers.

Why it fails: A mismatched autonomous system number would prevent the routers from forming an adjacency entirely, and the neighbor would not appear in the neighbor table. Since the neighbor is stuck in EXSTART, the AS numbers must already match. Changing the AS number would not resolve the stuck EXSTART state and could cause further disruption.

Set the maximum transmission unit (MTU) to match on both interfaces.

Why it fails: MTU mismatches can cause EIGRP to fail during the exchange of initial topology information, but they typically result in the neighbor being stuck in EXCHANGE state, not EXSTART. The EXSTART state is specifically related to the master/slave negotiation, which is influenced by interface MTU? Actually, EIGRP uses the interface MTU in the initial hello packet to determine the master/slave relationship during EXSTART. If MTUs differ, the router with the higher MTU becomes master, but if the MTU is mismatched, it can cause issues? Actually, the master/slave election is based on the router ID, not MTU. Wait, I need to correct this. In EIGRP, the master/slave negotiation during EXSTART uses the router ID: the router with the higher router ID becomes the master. MTU mismatches can cause problems in the exchange of routing information, but not typically in EXSTART. So this option is incorrect.

router ospfv3 1

Why it fails: This command is used in Cisco IOS to enable OSPFv3 for IPv6 and IPv4 address families in a multi-address-family configuration. However, in classic OSPFv3 configuration, the command is 'ipv6 router ospf'. The 'router ospfv3' command is used in newer IOS versions with address family support, but for basic OSPFv3 on IPv6, it is not required. It may be correct in some contexts, but not in the traditional dual-stack scenario.

ipv6 ospf area 0

Why it fails: This command is incomplete and missing the process ID. OSPFv3 requires a process ID to be specified. Without it, the command is invalid. The correct syntax is 'ipv6 ospf process-id area area-id'. Therefore, this option is incorrect and would not enable OSPFv3 properly.

ospfv3 1 ipv6 area 0

Why it fails: This command is used in interface configuration mode to enable OSPFv3 for IPv6 when using the address-family model. It is not the standard command for classic OSPFv3 configuration. The traditional command is 'ipv6 ospf 1 area 0'. This command might be used in IOS-XE with the 'router ospfv3' process, but it is not required in the basic dual-stack scenario described.

The route via 192.168.1.2, because it has a lower administrative distance.

Why it fails: This is incorrect because both routes are static routes and have the same administrative distance (1). The route via 192.168.1.2 does not have a lower administrative distance; the difference is in the configured metric, not administrative distance. The router will prefer the route with the lower metric when administrative distances are equal.

Both routes will be installed and load balancing will occur.

Why it fails: This is incorrect because static routes with different metrics to the same destination are not installed simultaneously for load balancing. Load balancing occurs only when routes have the same administrative distance and metric. Here, the metrics differ, so only the best route is installed. The router does not perform unequal-cost load balancing for static routes by default.

The route via 192.168.2.2, because it has a higher administrative distance.

Why it fails: This is incorrect because a higher administrative distance makes a route less preferred. The router selects the route with the lowest administrative distance. In this case, both routes are static and have the same administrative distance (1), so administrative distance is not the tiebreaker. The metric determines the best path.

Configure a key chain and apply it with 'ip ospf authentication key-chain NAME'.

Why it fails: Key chains are used for OSPF authentication in newer IOS versions, but the scenario already uses MD5 key configuration. The missing piece is area authentication, not a key chain. Key chains are an alternative method, but they do not resolve the mismatch when the area is not configured for authentication.

Set the OSPF priority to 0 on the interface.

Why it fails: OSPF priority determines DR/BDR election and has no impact on authentication. Setting priority to 0 prevents the router from becoming DR/BDR, but it does not enable authentication. The adjacency failure is due to authentication mismatch, not DR election.

Change the OSPF network type to point-to-point on the interface.

Why it fails: Changing the network type to point-to-point affects adjacency formation and DR/BDR election, but it does not address authentication. The problem is that authentication is not enabled at the area level, so OSPF hellos lack authentication information. Network type change is irrelevant to authentication mismatch.

The OSPF network type is set to point-to-point, which prevents DR/BDR election.

Why it fails: On a point-to-point network type, OSPF does not elect a DR or BDR. However, in this scenario, the segment is described as broadcast multi-access, so the network type should be broadcast by default. If it were point-to-point, no DR would be elected, but the issue is likely due to the priority change not taking effect immediately.

The router's OSPF router ID is lower than the current DR, so it cannot become DR even with a higher priority.

Why it fails: The DR election first considers priority; if priorities are equal, the highest router ID wins. Since the router has the highest priority, it should become DR after a new election. The router ID is not the deciding factor when priorities differ. Thus, this is not the reason.

The interface is configured with a priority of 0, which excludes it from DR/BDR election.

Why it fails: A priority of 0 indeed prevents a router from becoming DR or BDR. However, the scenario states the router has the highest OSPF priority, implying it is not 0. Therefore, this is not the cause. The real issue is the lack of a new election after the priority change.

redistribute ospf 1 metric 10000 100 255 1 1500

Why it fails: This command redistributes all OSPF routes into EIGRP with the specified metric, but it lacks a route map to filter which routes are redistributed. Without a route map, all OSPF routes are redistributed, which does not meet the requirement of redistributing only specific routes.

redistribute ospf 1 metric 10000 100 255 1 1500 subnets route-map OSPF_TO_EIGRP

Why it fails: The 'subnets' keyword is used when redistributing into OSPF, not EIGRP. EIGRP does not use the 'subnets' keyword; it automatically includes subnetted routes. Including 'subnets' here would cause a syntax error or be ignored, making this command incorrect for EIGRP redistribution.

redistribute ospf 1 route-map OSPF_TO_EIGRP

Why it fails: This command attempts to redistribute OSPF into EIGRP with a route map but omits the required EIGRP metric parameters. When redistributing into EIGRP, you must specify the metric (bandwidth, delay, reliability, load, MTU) either in the redistribute command or via a default-metric command. Without it, redistribution will fail.

Configure the static route with the default administrative distance and enable OSPF route filtering to remove the OSPF route when the static route is active.

Why it fails: Using the default AD (1) makes the static route preferred over OSPF. Filtering OSPF routes does not change the preference; the static route would always be used. This approach is overly complex and does not achieve the goal of using the static route only when OSPF is unavailable. It also introduces unnecessary configuration and potential for routing loops.

Configure the static route with a lower administrative distance than OSPF, for example: ip route 10.20.0.0 255.255.0.0 192.168.1.1 100

Why it fails: A lower administrative distance (100) makes the static route more preferred than OSPF (AD 110). This would cause the static route to always be installed in the routing table, even when OSPF is available, which is the opposite of the desired behavior. The engineer wants the static route to be a backup, not the primary path. Therefore, this configuration fails the scenario.

Configure the static route with a higher administrative distance than OSPF, for example: ip route 10.20.0.0 255.255.0.0 192.168.1.1 110

Why it fails: Setting the administrative distance to 110 makes the static route less preferred than OSPF (default AD 110), so OSPF would always be chosen even if the static path is the only working one. This does not achieve the goal of using the static route only when OSPF is unavailable; it makes the static route effectively a backup only if OSPF is removed, but the question asks for the static route to be used when OSPF is not available, which requires a floating static route with a higher AD than OSPF but still usable when OSPF fails. However, the AD value of 110 is equal to OSPF's default, so the static route would not be preferred over OSPF, and if OSPF fails, the static route would still be in the routing table only if OSPF is removed. Actually, a floating static route uses an AD higher than the dynamic protocol, but if OSPF is down, the static route with AD 110 would be used only if no other OSPF route exists. But the question says 'without changing the administrative distance globally' and wants static used only when OSPF is not available. The correct approach is to set a higher AD than OSPF, such as 111 or 250. So this option is incorrect because 110 is not higher than OSPF's default AD.

OSPFv3 uses the same multicast addresses as OSPFv2: 224.0.0.5 and 224.0.0.6.

Why it fails: OSPFv3 uses IPv6 multicast addresses FF02::5 (AllSPFRouters) and FF02::6 (AllDRouters). OSPFv2 uses IPv4 multicast addresses 224.0.0.5 and 224.0.0.6. Since OSPFv3 operates over IPv6, it uses IPv6 multicast addresses. The addresses 224.0.0.5 and 224.0.0.6 are not used by OSPFv3.

OSPFv3 can run over an IPv4 network using a unicast address for neighbor communication.

Why it fails: OSPFv3 is designed to run over IPv6. While there is an extension for OSPFv3 to support IPv4 address families, it still uses IPv6 link-local addresses for neighbor communication and requires IPv6 to be enabled. OSPFv3 does not run directly over an IPv4 network using IPv4 unicast addresses; that is the domain of OSPFv2. Therefore, this statement is false.

OSPFv3 uses the same link-state database (LSDB) for both IPv4 and IPv6.

Why it fails: OSPFv3 maintains separate link-state databases for each address family. While OSPFv3 supports multiple address families (IPv4 and IPv6) through the use of address family identifiers, it does not use a single shared LSDB for both. Each address family has its own LSDB and runs independently. This separation allows for different topologies and policies for each protocol.

ip route 192.168.1.0 255.255.255.0 GigabitEthernet0/0

Why it fails: This command creates a fully specified static route with only an exit interface. While it ties the route to the interface, it does not specify a next-hop address. On broadcast interfaces like Ethernet, this can cause the router to ARP for every destination, leading to inefficiency. It also does not ensure the next-hop is reachable; it only uses the interface. This is not the best practice for the requirement.

ip route 192.168.1.0 255.255.255.0 10.1.1.1

Why it fails: This command creates a standard static route with a next-hop IP address. However, it does not specify an exit interface. The router will recursively look up the next-hop address to determine the exit interface. This can lead to the route being used even if the intended interface is down, as long as the next-hop is reachable via another path. It does not meet the requirement of tying the route to a specific interface.

ip route 192.168.1.0 255.255.255.0 10.1.1.1 GigabitEthernet0/0

Why it fails: This command has the correct syntax but the order of parameters is reversed. In Cisco IOS, the exit interface must come before the next-hop address. The correct syntax is 'ip route prefix mask interface next-hop'. This command would be rejected or misinterpreted, making it invalid. Therefore, it does not achieve the goal.

The autonomous system number is different.

Why it fails: The scenario states that the administrator verified that the autonomous system numbers match. Therefore, this cannot be the cause. EIGRP requires matching AS numbers for adjacency, but since they match, it is not the issue. The problem must be another factor.

The hello timer is set to 10 seconds on one router and 30 seconds on the other.

Why it fails: EIGRP hello timers do not need to match for adjacency formation. The hold timer, which is typically three times the hello timer, is what matters. If hold timers are compatible, adjacencies can form even with different hello intervals. Therefore, mismatched hello timers alone would not prevent adjacency.

The K-values are mismatched.

Why it fails: The scenario states that K-values are default on both routers, meaning they match. Mismatched K-values would prevent adjacency, but since they are default and match, this is not the cause. The issue lies elsewhere, such as a passive interface.

The spokes are not configured with 'ip nhrp network-id' matching the hub.

Why it fails: The NHRP network ID must match on all DMVPN routers for NHRP to function. If mismatched, NHRP resolution would fail entirely, and even hub-to-spoke communication would be broken. The scenario states that spoke-to-spoke traffic initially goes through the hub, indicating that NHRP is working and the network ID is likely correct.

The spoke routers do not have a route to the destination spoke's tunnel IP.

Why it fails: In DMVPN Phase 3, spokes initially have a default route or a summary route pointing to the hub. When traffic is sent to a destination spoke, the hub sends an NHRP redirect, and the spoke initiates an NHRP resolution to find the destination's NBMA address. If the spoke lacks a route, it would not even send traffic to the hub. The issue is not routing but the NHRP shortcut mechanism.

The hub does not have 'ip nhrp map multicast dynamic' configured.

Why it fails: The 'ip nhrp map multicast dynamic' command is used on the hub to allow it to replicate multicast traffic to all spokes, which is essential for routing protocols like OSPF. However, the issue described is about spoke-to-spoke traffic not switching to a direct path, which is related to NHRP redirect and shortcut, not multicast replication.

Verify that the EIGRP autonomous system number matches on both routers.

Why it fails: The autonomous system number must match for EIGRP neighbors to form an adjacency. However, if the AS numbers were mismatched, the adjacency would not form at all, and the error message would differ. The retry limit exceeded message specifically points to a failure in receiving acknowledgments, which is not directly related to AS number mismatch.

Adjust the EIGRP K-values to match on both routers.

Why it fails: Mismatched K-values would prevent the formation of an EIGRP adjacency because the metric computation would differ. However, the error message indicates that the adjacency initially formed and then dropped, which is not typical for K-value mismatch. K-value mismatch usually results in an immediate failure to form an adjacency, not a retry limit exceeded after formation.

Increase the EIGRP hello interval on both routers.

Why it fails: Increasing the hello interval would delay hello packet transmission, potentially worsening the adjacency issue. The retry limit exceeded message indicates that EIGRP did not receive acknowledgments for its hello packets within the retry limit. Adjusting the hello interval does not address the underlying problem of missing acknowledgments, which is typically caused by mismatched K-values or authentication failures.

ip route 192.168.2.0 255.255.255.0 10.0.0.2 90

Why it fails: This command sets the administrative distance to 90, which is lower than OSPF's 110. Therefore, the static route will always be preferred over the OSPF route, making it a primary route rather than a backup. To act as a backup, the static route's administrative distance must be higher than OSPF's.

ip route 192.168.2.0 255.255.255.0 10.0.0.2 110

Why it fails: This command sets the administrative distance to 110, which is the same as OSPF's default administrative distance. If both routes have the same distance, the router may load-balance or prefer one based on other factors. It does not guarantee the static route is used only when OSPF fails, as equal distance can cause unpredictable behavior.

ip route 192.168.2.0 255.255.255.0 10.0.0.2

Why it fails: This command creates a static route with the default administrative distance of 1. Since 1 is lower than OSPF's 110, this static route will always be preferred over the OSPF route, even when the OSPF route is available. It does not provide backup behavior; it overrides OSPF permanently.

Enable recursive routing for the next-hop.

Why it fails: Recursive routing is not a feature that can be enabled; it is a behavior where the router looks up the next-hop in the routing table. PBR does not support recursive next-hop lookup by default. The next-hop must be directly reachable or resolved via a route. Simply enabling recursive routing is not a valid command or concept in this context.

Set the next-hop to the default gateway.

Why it fails: Setting the next-hop to the default gateway would not achieve the goal of routing to a specific next-hop that is not in the routing table. The default gateway is used when no specific route exists. PBR allows overriding the default routing behavior, but the next-hop must still be reachable. Using the default gateway would not ensure that the specific next-hop is used, and it may not be the intended path.

Configure the next-hop as a directly connected interface.

Why it fails: While using an interface as the next-hop in PBR is possible, it is not recommended on broadcast networks because it can cause the router to ARP for every destination. The scenario states the next-hop is not in the routing table, so it may not be directly connected. Using an interface does not guarantee reachability of the next-hop. The requirement is to ensure the next-hop is reachable, which is typically done with a static route.

Origin

Why it fails: Origin is a well-known mandatory attribute that indicates how the route was introduced into BGP (IGP, EGP, or incomplete). It is evaluated after MED in the best path selection process. It is not typically manipulated to prefer routes from a specific eBGP peer because it is less granular and not designed for that purpose.

AS_PATH

Why it fails: AS_PATH is a well-known mandatory attribute that lists the autonomous systems a route has traversed. A shorter AS_PATH is preferred. However, manipulating AS_PATH is typically done to influence inbound traffic from other ASes, not to prefer routes from a specific eBGP peer over another. It is evaluated after weight and local preference, so it is less direct for this purpose.

MED

Why it fails: Multi-Exit Discriminator (MED) is an optional non-transitive attribute that is used to influence inbound traffic from an external AS. It is evaluated later in the best path selection process, after AS_PATH. While MED can influence which route is preferred, it is not the primary attribute for comparing routes from different eBGP peers because it is only compared between routes from the same neighboring AS. It is not the best choice for this scenario.

The OSPFv3 area ID is configured as a decimal value instead of dotted decimal.

Why it fails: OSPFv3 area IDs can be configured in decimal or dotted-decimal format; both are accepted. Moreover, the scenario states that the area ID is the same on both routers. An area ID format difference would not prevent adjacency if the numerical value is identical. This is not a valid cause for adjacency failure.

The OSPFv3 network type is mismatched between the two routers.

Why it fails: While a network type mismatch can cause adjacency issues, it is less likely than a missing router ID in a pure IPv6 setup. The scenario states that IPv6 unicast routing is enabled but does not mention any IPv4 addresses, which is the key clue. Network type defaults are usually consistent on Ethernet segments.

A router ID conflict exists because OSPFv3 does not automatically select a router ID.

Why it fails: OSPFv3 automatically selects a router ID from the highest loopback IPv4 address or highest interface IPv4 address. If no IPv4 address exists, the router ID must be manually configured. However, a conflict would not prevent adjacency if the router IDs are unique. Since the scenario does not mention duplicate IDs, this is not the most likely cause.

ospfv3 1 ipv6 area 0

Why it fails: The command 'ospfv3 1 ipv6 area 0' is used in interface configuration mode to enable OSPFv3 for IPv6 on the interface. However, it is an alternative syntax that is used when configuring OSPFv3 for multiple address families. The more common and direct command is 'ipv6 ospf 1 area 0'. In this scenario, the engineer is specifically enabling OSPFv3 for IPv6, so the simpler command is preferred, but the other is also valid. However, the question asks for the required command, and both are valid, but the most direct answer is 'ipv6 ospf 1 area 0'.

ipv6 router ospf 1

Why it fails: The command 'ipv6 router ospf 1' is used in global configuration mode to enable the OSPFv3 routing process. It does not enable OSPFv3 on an interface. Interface participation requires the interface-level command. This command alone does not activate OSPFv3 on any interface.

network 2001:db8::/32 area 0

Why it fails: The 'network' command is used in OSPFv2 to advertise networks into OSPF. In OSPFv3, network advertisement is done per interface, not with the network command. Therefore, this command is not used in OSPFv3 configuration. It would be incorrect for this scenario.