Show IP Route practice questions

The OSPFv3 process ID must match on both routers.

Why wrong: OSPFv3 process IDs are locally significant and do not need to match for adjacency to form.

The link-local addresses are not in the same subnet.

Why wrong: Link-local addresses are only used for neighbor discovery and do not require subnet matching; they are always on the same link.

The router ID 1.1.1.1 is duplicated on R2.

Why wrong: Duplicate router IDs can cause issues, but the 'show ospfv3 neighbor' output would typically show the neighbor in EXSTART or EXCHANGE state, not missing entirely.

The static route will be preferred because static routes always beat dynamic routes.

Why wrong: Only if the static route has a lower AD than the competing routes.

RIP wins because its metric is lower than OSPF cost.

Why wrong: Different routing protocols are compared by AD first, not by their internal metrics.

All three routes should load-balance because the prefix length is the same.

Why wrong: Equal prefix length alone is not enough; the route source and attributes do not match for ECMP here.

The static route for 10.10.20.0/24 is missing from the routing table.

Why wrong: The exhibit shows that a static route to 10.10.20.0/24 via 10.10.10.2 is present in the routing table.

The GigabitEthernet0/0 interface is administratively down.

Why wrong: The interface is shown as directly connected with a local address, indicating it is up and operational.

The default route is not configured; the gateway of last resort is missing.

Why wrong: The output shows 'Gateway of last resort is 10.10.10.2 to network 0.0.0.0', meaning the default route is present.

show vlan brief

Why wrong: This is wrong because VLAN output does not verify OSPF neighbor state.

show spanning-tree

Why wrong: This is wrong because STP output is not the primary verification tool for OSPF adjacency.

show mac address-table

Why wrong: This is wrong because MAC table output does not verify OSPF neighbor relationships.

Change the native VLAN on R1's trunk interface to 99, correct the encapsulation on G0/0.20 to dot1Q 20, but do not enable IP routing because it is enabled by default.

Why wrong: This is incorrect because IP routing is not enabled by default on Cisco routers; it must be explicitly configured with the 'ip routing' command. Without it, the router cannot forward packets between subinterfaces.

Change the native VLAN on R1's trunk interface to 1, correct the encapsulation on G0/0.20 to dot1Q 20, and enable IP routing globally.

Why wrong: This is incorrect because the native VLAN mismatch is not resolved; the switch expects native VLAN 99, not 1. The native VLAN must match on both ends of the trunk.

Change the native VLAN on R1's trunk interface to 99, correct the encapsulation on G0/0.10 to dot1Q 10, and enable IP routing globally.

Why wrong: This is incorrect because the encapsulation on G0/0.20 is still wrong; it should be dot1Q 20, not dot1Q 10. The subinterface for VLAN 20 must use VLAN ID 20.

The OSPF router-id is automatically derived from the MAC address of the first Ethernet interface.

Why wrong: The router-id is not derived from the MAC address.

If the router-id is changed using the 'router-id' command, the change takes effect immediately without any additional action.

Why wrong: Changing the router-id requires a reload or a 'clear ip ospf process' command to take effect.

The router-id must be the same on all routers in a single OSPF area.

Why wrong: The router-id must be unique within the OSPF domain.

Authentication mismatch between R2 and 3.3.3.3

Why wrong: A mismatch would stop the neighbor relationship from reaching 2WAY in the first place.

R2 must be configured as a point-to-point network type

Why wrong: That is not required here and would change behavior rather than explain the current normal state.

R2 has a duplicate router ID

Why wrong: A duplicate router ID causes other issues and is not what this output indicates.

The OSPF route to 10.60.4.0/24

Why wrong: This is wrong because the /24 is less specific than the /28.

The EIGRP route to 10.60.0.0/16

Why wrong: This is wrong because the /16 is broader than both other matches.

No route at all

Why wrong: This is wrong because the destination clearly matches all three shown prefixes.

Change the AD of the static route via 192.0.2.2 to 200 and the AD of the route via 198.51.100.2 to 1.

Why wrong: This is incorrect because it suggests modifying both routes, but the primary route already has AD 1 (default) and the backup has AD 1 as well; the fix is to increase the backup's AD, not change the primary's.

Add a static route to 192.168.10.0/24 via 192.0.2.2 with AD 1 and remove the existing route via 198.51.100.2.

Why wrong: This removes the backup route entirely, which eliminates redundancy. The requirement is for automatic failover, not removal of the backup.

Configure a policy-based route to prefer the next-hop 192.0.2.2 for traffic to 192.168.10.0/24.

Why wrong: Policy-based routing (PBR) is not the standard solution for simple primary/backup path selection; static route AD manipulation is the correct method.

The native VLAN is always tagged on an 802.1Q trunk link.

Why wrong: This is incorrect because the native VLAN is specifically the VLAN that is not tagged on an 802.1Q trunk; all other VLANs are tagged.

The command switchport trunk native vlan 10 is used to restrict which VLANs are allowed on a trunk.

Why wrong: This is incorrect because switchport trunk native vlan 10 sets the native VLAN to 10, not restricts allowed VLANs.

The command show interfaces trunk displays the IP addresses configured on router subinterfaces.

Why wrong: This is incorrect because show interfaces trunk is a switch command that shows trunk status and allowed VLANs, not router IP addresses.

Apply ip nat enable on both interfaces.

Why wrong: `ip nat enable` is not the normal Cisco IOS syntax used for classic inside/outside NAT in this scenario. The directional role assignment is what needs correction.

Replace overload with pool.

Why wrong: Using a pool is another NAT design option, but it is not required for PAT to work. The current command already uses interface overload, which is valid. The failure is caused by reversed inside and outside roles.

Change access-list 1 to a standard ACL numbered 100.

Why wrong: Standard ACL 1 is already valid for identifying inside local addresses. There is no requirement to use ACL 100 for this kind of NAT rule. The bigger issue is that the interfaces are assigned the wrong NAT roles.

snmp-server community NetOpsRO ro snmp-server user AdminUser v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow export EXPORTER

Why wrong: This is incorrect because the SNMPv3 user is created without a group, which is required for authentication and privacy privileges. Also, 'ip flow export' is not a valid interface command; the correct command is 'ip flow monitor' referencing a flow monitor that uses the exporter.

snmp-server community NetOpsRO ro snmp-server group AdminGroup v3 priv snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 version 2c TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input

Why wrong: This is incorrect because the 'snmp-server host' command includes 'version 2c', which forces traps to be sent using SNMPv2c with the community string. However, the trap community 'TrapComm' is specified, but the command syntax is correct; the error is that the trap destination should not specify version 2c if the community is intended for v2c traps, but the question does not specify version, so it's acceptable. Actually, the main error is missing the flow exporter reference in the flow monitor; the flow monitor must be configured with the exporter. The given config does not show the flow monitor configuration.

snmp-server community NetOpsRO ro snmp-server group AdminGroup v3 priv snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input flow monitor FLOW-MONITOR exporter EXPORTER

Why wrong: This is incorrect because the flow monitor configuration is placed after the interface command, which is out of order. The flow monitor must be configured before it is applied to the interface. Additionally, the 'flow monitor' command should be in global configuration mode, not after the interface command.

The routers are in different OSPF areas.

Why wrong: This would be a valid reason if one router were in area 0 and the other were in another area. In the exhibit, both routers place the same subnet into area 0, so the area setting is not the issue. The failure occurs at the interface parameter level instead.

The subnet mask prevents multicast OSPF packets from being exchanged.

Why wrong: The subnet mask shown is a normal /24 LAN mask and does not stop OSPF multicast traffic. OSPF commonly uses multicast on broadcast segments without any problem in that mask size. The real incompatibility is the timer mismatch, not the mask.

The OSPF process IDs do not match on the two routers.

Why wrong: This sounds believable because many learners assume OSPF process IDs must match between neighbors. In reality, the process ID is locally significant and is not exchanged as a neighbor-forming parameter. Two routers can still become neighbors with different local process numbers if the real link parameters match.

Because static routes cannot reference exit interfaces.

Why wrong: This is wrong because static routes can be configured with outgoing interfaces.

Because the destination must be a /24, not a /16.

Why wrong: This is wrong because the issue shown is interface state, not the destination mask.

Because static routes require NTP before installation.

Why wrong: This is wrong because time synchronization is unrelated to static-route installation.