CCNA Layer 3 Technologies Questions

The set ip next-hop verify-availability command allows PBR to verify the reachability of the next-hop using a tracking object. The syntax includes the next-hop IP, a sequence number, and the track keyword followed by the tracking object number. If the tracked object is up, the next-hop is used; if down, the route map is not applied, and normal routing takes over. This meets the requirement of forwarding only if the next-hop is reachable.

In OSPFv3, the EXSTART state is reached after the neighbor is seen in the Hello packet, but before database description packets are exchanged. A mismatch in interface MTU prevents the routers from agreeing on the initial database description sequence, causing the adjacency to remain in EXSTART. This is a common issue when IPv6 MTU is not consistent across the link, especially with tunneling or different link types.

For DMVPN Phase 3 shortcuts to work, spokes must have a route to the destination spoke network pointing to the tunnel interface, and NHRP must resolve the destination NBMA address. The hub uses redirect messages to inform spokes of a better path, and spokes use shortcut to install a direct NHRP entry. Without proper routing and NHRP, shortcuts fail.

BGP network statements only advertise a prefix if there is an exact matching route in the IP routing table. Here, only 10.10.1.0/24 and 10.10.2.0/24 exist, not 10.10.0.0/16, so BGP will not originate the aggregate. To advertise the /16, the engineer must either create a summary route (e.g., a static route to Null0) or use the aggregate-address command.

AS_PATH is a well-known mandatory attribute that can influence inbound traffic by making the path appear longer. By prepending additional AS numbers to the AS_PATH for a specific prefix, the engineer can make that path less preferred by the ISP. This is a common method to influence inbound traffic when MED is not honored, as MED is optional and often not considered across different autonomous systems.

Static routes for a VRF must be configured with the `ip route vrf <vrf-name>` syntax in global configuration mode. Without the `vrf` keyword, the route is installed in the global routing table, not the VRF. This command correctly places the route into the VRF CUSTA routing table.

This command, issued in interface configuration mode, enables OSPFv3 for IPv6 on the interface and assigns it to area 0. It is the standard method to activate OSPFv3 on an interface in Cisco IOS. Without this command, the interface will not participate in OSPFv3 and no adjacency will form.

The track keyword associates the static route with a tracked object (in this case, object 1). If the tracked object goes down, the route is removed from the routing table. This provides next-hop reachability tracking. The engineer must also configure a track object to monitor the next-hop, typically using ICMP echo or a route reachability check. This is the correct way to conditionally install a static route based on next-hop availability.

In OSPFv3, if a router receives a hello packet with its own router ID, it transitions the interface to the LOOPBACK state to prevent adjacency formation. This typically happens when two routers are misconfigured with the same router ID. The LOOPBACK state is a clear indicator of a duplicate router ID conflict on the link, and the adjacency will not form until the conflict is resolved.

Even if the tunnel interface is up, traffic will not pass unless there is a route directing traffic destined for the remote network out the tunnel interface. Without such a route, packets will follow the default route or be dropped. This is a common oversight: the tunnel is operational, but the routing table lacks an entry pointing to the tunnel for the remote subnets. Thus, no traffic passes.

The VPNv4 address family is specifically designed for MPLS Layer 3 VPNs. Configuring 'address-family vpnv4' under BGP enables the PE router to exchange VPNv4 routes with other PE routers. These routes include the route distinguisher and route target extended communities, allowing the receiving PE to import the route into the correct VRF.

PBR requires that the route-map be applied to the inbound interface where traffic enters, and the match conditions (e.g., ACL) must correctly identify the traffic. If the ACL is misconfigured or the policy is applied in the wrong direction, PBR will not take effect. Checking these ensures the policy is properly triggered for the specified traffic.

The 'Dead timer expired' message means hellos are not being received within the dead interval. Since authentication and timers are correct, the most likely cause is that hellos are lost in one direction due to a Layer 2 loop, unidirectional link, or a faulty cable/port. Verifying the Layer 2 path and interface counters will reveal dropped or missing hellos and resolve the flapping.

The show ip eigrp interfaces detail command displays detailed EIGRP information for each interface, including the hello interval and hold time. This is the correct command to verify the timers, as mismatched timers are a common cause of adjacency failures. It also shows other parameters like split horizon and authentication, making it a comprehensive troubleshooting tool for EIGRP interface settings.

In NSSA, the P-bit in the Type-7 LSA options field indicates whether the LSA should be translated into a Type-5 LSA by the ABR. If the P-bit is cleared, the ABR will not translate the LSA. The P-bit is typically set by the ASBR when the LSA is originated, but it can be cleared under certain conditions, such as when the ASBR is also an ABR or when the LSA is redistributed without the proper configuration. This directly prevents translation.

A router becomes an ABR automatically when it has at least two interfaces in different OSPF areas. No specific command enables ABR functionality. The engineer only needs to ensure that the interfaces are correctly assigned to different areas, which is already stated. Thus, no additional command under router configuration mode is needed to make the router an ABR.

The 'area 1 range' command is used on an ABR to summarize inter-area routes from the specified area into other areas. It must be configured on the ABR, and the area specified is the source area (Area 1). This command aggregates routes from Area 1 into a single summary LSA that is advertised into Area 0. It is the correct method for inter-area route summarization in OSPF, reducing the size of the link-state database and routing tables in the backbone.

OSPF network types must match on both sides of a link for an adjacency to form. R1 is configured as point-to-point, while R2 is broadcast. This mismatch causes hello packets to be interpreted differently, and the adjacency will not form. Both routers must use the same network type, either point-to-point or broadcast.

In DMVPN Phase 3, NHRP redirect is configured on the hub to inform spokes of a better path, and NHRP shortcut is configured on the spokes to allow them to dynamically build direct tunnels to other spokes. This combination enables spoke-to-spoke traffic to bypass the hub, reducing latency and hub load. This is the correct solution for the scenario.

OSPF area summarization is performed by an ABR on routes entering the backbone. If the tunnel interface belongs to the same area as the corporate domain, the hub is not an ABR and cannot generate summary LSAs. Placing the tunnel in a separate area makes the hub an ABR, allowing `area X range` to summarize spoke routes before advertising them.

A floating static route is configured with a higher administrative distance than the primary route, so it is only installed in the routing table if the primary route fails. This makes it ideal as a backup path. The technician can specify an administrative distance greater than that of the dynamic routing protocol or the primary static route.

To configure a totally stubby area in OSPFv3, the ABR must have the `area 1 stub no-summary` command. This setting prevents the ABR from flooding type 3 summary LSAs into the area and automatically generates a default route (inter-area-prefix LSA) into the stub area. If this command is missing, the ABR will not inject a default route, and routers in Area 1 will lack a path to external destinations.

This command, entered in interface configuration mode, enables MD5 authentication for EIGRP AS 10 on that interface. It specifies that EIGRP packets must be authenticated using MD5. After enabling this, you must also configure a key chain and apply it with ip authentication key-chain eigrp 10. This is the correct first step to enable MD5 authentication for EIGRP on an interface.

OSPF DR election is not preemptive. Once a DR is elected, it remains DR until it fails or the OSPF process is restarted. If another router was elected DR first, the router with the highest priority will not take over even if it comes online later. To force a new election, you must restart the OSPF process or shut down the interfaces. Thus, this is the most likely reason.

This command sets the OSPF network type to point-to-point, which eliminates DR/BDR election and allows immediate adjacency formation. It is appropriate for a WAN link where the provider expects point-to-point behavior. By default, point-to-point networks send Hellos every 10 seconds and have no DR/BDR, reducing overhead and speeding convergence.

This is correct because PBR requires a route map to define match criteria (source subnet) and set actions (next-hop). Applying it inbound on the ingress interface GigabitEthernet0/0 ensures packets from 10.1.1.0/24 are policy-routed before the routing table is consulted. The next-hop 10.2.2.2 must be reachable via the interface the packet is forwarded out, which is GigabitEthernet0/1.

In DMVPN Phase 3, the hub must have ip nhrp redirect configured to inform spokes when a better path exists. When the hub receives a packet from a spoke and forwards it to another spoke, it sends an NHRP redirect message to the originating spoke, prompting it to initiate a direct tunnel. Without this command, spokes will not receive the redirect and will continue to route through the hub, preventing direct spoke-to-spoke tunnels.

This command displays OSPFv3 interface parameters such as network type, hello interval, dead interval, and MTU, which are critical for adjacency formation. In this scenario, a mismatch in MTU or network type can cause the neighbor to stall in EXSTART. Therefore, this command is the correct choice to verify those parameters.

For PBR to work, the route map must be applied to the ingress interface using the ip policy route-map command. If this command is missing, the route map will not be evaluated, and traffic will be forwarded based on the routing table. This is a common oversight. The engineer must enter interface configuration mode and apply the route map to the interface where traffic enters the router. Without this step, PBR will not function.

In DMVPN Phase 3, the hub must be configured with ip nhrp redirect to send NHRP redirect messages to spokes when it receives traffic that could be sent directly between spokes. This allows the hub to inform the originating spoke of a better path, enabling direct spoke-to-spoke tunnels. Without this, spokes continue to route through the hub.

NHRP redirect allows the hub to inform spokes about a more optimal path to another spoke. When Spoke1 sends traffic to Spoke2 via the hub, the hub sends an NHRP redirect message, prompting Spoke1 to initiate a direct tunnel. This is essential for Phase 3 DMVPN, especially with NAT, as it enables dynamic spoke-to-spoke tunnels without preconfiguration.

Entering OSPF configuration mode with 'router ospf 1' and then issuing 'router-id 10.1.1.1' explicitly sets the router ID. This method is preferred because it does not depend on interface IP addresses, ensuring the router ID remains 10.1.1.1 even if interfaces change or go down.

Route targets are extended BGP communities used to control the import and export of routes between VRFs. By assigning unique route targets to each VRF, you ensure that routes from one VRF are not imported into another. This provides the necessary isolation. Without proper route target configuration, routes could leak. Therefore, route targets are the correct mechanism.

This command correctly configures a static route for the 192.168.1.0/24 network with a next-hop of 10.1.1.1. The subnet mask 255.255.255.0 corresponds to /24, and the next-hop is specified as an IP address. This is the standard syntax for a static route on Cisco IOS.

GRE tunnels can carry multicast traffic if multicast routing is enabled. You must enable ip multicast-routing globally and configure PIM (e.g., PIM sparse-mode) on both the tunnel interface and the underlying physical interface. This allows multicast packets to be encapsulated and forwarded through the tunnel. Without PIM on the tunnel, multicast traffic will not be routed.

The `ip helper-address` command configures the router to forward UDP broadcasts, including DHCP requests (UDP port 67), to the specified server. This allows the DHCP server to receive the request and assign an address from the appropriate pool based on the gateway address (giaddr) set by the router. This is the correct and standard way to configure a DHCP relay agent on Cisco IOS.