CCNA Layer 3 Technologies Questions

The class map is used to classify traffic by matching specific criteria, such as protocol type, source/destination IP, or port numbers. In this scenario, to rate-limit ICMP echo requests, the engineer would create a class map that matches ICMP echo-request packets. Therefore, the class map is the component that defines the traffic classification for CoPP.

OSPFv3 does not automatically enable on interfaces when the process is created; each interface must be explicitly enabled with `ipv6 ospf <process-id> area <area-id>` or by using `ipv6 ospf area` under the interface. Without this command, the router will not send or process OSPFv3 hellos, so no adjacency forms even though IPv6 addressing and unicast routing are configured correctly.

This configuration creates a route map that matches traffic from the 10.1.1.0/24 subnet (via access list 10) and sets the next-hop to 192.168.1.1. The route map is applied to the interface with the ip policy route-map command. This correctly implements policy-based routing for the specified subnet, while other traffic will follow the normal routing table.

The passive-interface command under router ospf suppresses OSPF hello packets on the specified interface, preventing adjacency formation, but the network connected to that interface is still advertised as a stub network into OSPF. This meets the requirement of no adjacencies while still advertising 10.3.3.0/24. It is the standard method for this scenario and does not affect other interfaces.

The ipv6 unicast-routing command enables IPv6 unicast routing globally on the router. Without it, the router will not forward IPv6 packets, even if interfaces have IPv6 addresses. This command is essential for any IPv6 routing configuration. It allows the router to participate in IPv6 routing protocols and forward IPv6 traffic between interfaces.

When using PBR with 'set ip next-hop', the next-hop IP address must be reachable via a route in the routing table. If the next-hop is not directly connected, you need a static route to that next-hop. This ensures that the router can forward the packet to the next-hop. Without the static route, the PBR action would fail because the next-hop is not resolvable.

The 'set ip next-hop recursive' command requires that the specified next-hop IP address be resolvable through a route in the routing table (RIB). If there is no route to that next-hop, the recursive lookup fails, and the PBR policy is not applied. The router will then fall back to normal destination-based routing. Thus, the most likely reason is that the next-hop address is not present in the RIB.

With NHRP redirect on the hub, the hub sends an NHRP redirect message to the originating spoke when it forwards traffic out the same tunnel interface. The spoke then sends an NHRP resolution request for the destination NBMA address, receives a resolution reply, installs a shortcut entry in the NHRP cache, and the routing protocol (or NHRP) installs a /32 route, enabling direct spoke-to-spoke forwarding.

In DMVPN Phase 3, the hub must be configured with `ip nhrp redirect` to inform spokes when a better path exists. When the hub receives a packet from a spoke destined to another spoke, it sends an NHRP redirect message to the originating spoke, prompting it to resolve the destination spoke's NBMA address directly. This enables spoke-to-spoke tunnels without traversing the hub for subsequent packets. Without this command, Phase 3 shortcut switching does not occur.

The 'passive-interface' command under EIGRP configuration suppresses EIGRP hello packets and updates on the specified interface, preventing adjacency formation. However, the connected network is still advertised into EIGRP as long as it is covered by a network statement. This meets the requirement of not sending updates out of the interface while still advertising the subnet.

For DMVPN Phase 3 shortcut tunnels to work, the spoke must have a route to the destination network pointing to the hub initially. When traffic is sent to the hub, the hub sends an NHRP redirect, and the spoke can then establish a direct tunnel. Without a route via the hub, the spoke cannot trigger the shortcut process.

Local preference is the second BGP attribute in the best-path selection process, after weight, and it is used to influence outbound traffic within an autonomous system. By setting a higher local preference for routes learned from ISP-A, the router will prefer those routes over routes from ISP-B for the same prefix. This is the standard method to control outbound path selection when multiple eBGP peers exist.

Policy-based routing requires that the ACL correctly identifies the traffic to be policy-routed. The ACL must permit TCP port 80 from 10.1.1.0/24 to any destination. Additionally, the route map must be applied to the ingress interface (GigabitEthernet0/0) in the inbound direction, which is the default when using the `ip policy route-map` command. Verifying these elements will resolve the issue.

AS path is a well-known mandatory attribute that lists the autonomous systems a route has traversed. By prepending additional AS numbers to the AS path, the engineer makes the route appear longer, which is less preferred by BGP. This influences inbound traffic because the ISP will choose a shorter AS path if available. It is a common method to manipulate inbound traffic.

The 'ip nhrp redirect' command on the hub enables NHRP redirect messages, which inform spokes of a better direct path to another spoke. This allows spoke-to-spoke communication without traversing the hub after initial resolution. It is essential for DMVPN Phase 3 and works with 'ip nhrp shortcut' on spokes.

This sequence enables OSPF MD5 authentication on the interface and configures the key ID and password. The 'ip ospf authentication message-digest' command activates MD5 authentication for OSPF on that interface, and 'ip ospf message-digest-key 1 md5 Cisco123' defines the key. This is the correct method to enable MD5 authentication per interface. Both commands are required; without the first, the key is configured but authentication is not enabled.

This address family is specifically designed to carry VPNv4 routes with MPLS labels between PE routers. It enables the exchange of customer VPN routes along with their associated route targets and MPLS labels. Configuring this address family under BGP is essential for MPLS L3VPN operation.

Setting OSPF priority to 0 on an interface makes the router ineligible to become DR or BDR on that interface. This is the correct method to prevent a router from being elected as DR. The priority value is carried in Hello packets and used in the DR election process; a priority of 0 means the router will not participate in the election.

Setting the OSPF priority to 0 on the interface prevents the router from being elected as DR or BDR on that segment. It will still form adjacencies and participate in OSPF as a DROTHER. This is the standard method to ensure a router does not take on the DR/BDR role while remaining an active OSPF participant.

A GRE tunnel interface remains down if the tunnel source address is not up or if there is no route to the tunnel destination. The administrator must ensure the physical interface with the source address is operational and that a route exists to 10.2.2.2. Without reachability, the tunnel cannot come up.

When the interface for the primary static route fails, the route is removed from the routing table. The router then evaluates the floating static route, which has a higher administrative distance (200) but becomes the best available path. It is installed in the routing table, allowing traffic to use the backup path. This is the intended design of a floating static route for redundancy.

AS_PATH is a well-known mandatory attribute that lists the autonomous systems a route has traversed. By prepending additional AS numbers to the AS_PATH, the path length increases, making the route less preferred by BGP's best path selection process. This is a common method to influence inbound traffic, as the ISP will prefer shorter AS paths.

Multiprotocol BGP (MP-BGP) is used to distribute VPNv4 routes across the MPLS core. It carries the VPNv4 address family and associated MPLS labels (route targets and route distinguishers). Provider edge routers establish iBGP sessions to exchange VPNv4 reachability information, enabling MPLS L3 VPNs.

OSPF MD5 authentication requires that both routers use the same key ID and identical key string on the interface. If the neighbor has a different key ID or key string, the MD5 digest will not match, and OSPF hellos will be rejected, preventing adjacency formation. The most common cause of failure after enabling MD5 is a mismatch in these parameters.

Using route tags is a standard method to prevent feedback loops in mutual redistribution. By tagging routes when redistributing from OSPF into EIGRP, and then denying those tags when redistributing from EIGRP back into OSPF, you prevent the same routes from being reintroduced. This breaks the loop and is a scalable, deterministic solution.

The VPNv4 unicast address family is specifically designed to carry MPLS L3VPN routes with route distinguishers and extended communities. Activating it under the BGP configuration enables the exchange of VPNv4 prefixes with the route reflector. This is the correct address family for MPLS L3VPN route distribution.

For a static route to be installed in the routing table, the next-hop address must be reachable via a directly connected interface or another route. If 10.1.1.2 is not reachable, the static route remains inactive and does not appear in the routing table. This is a common issue when the next-hop is not on a directly connected subnet or lacks a route.

To exchange VPNv4 routes between PE routers, BGP must be configured with the VPNv4 address family. This allows the PE routers to carry customer routes with route distinguishers and route targets. Without enabling the VPNv4 address family, the PE routers cannot exchange VPN routing information, and MPLS L3VPN would not function.

A floating static route is a static route with an administrative distance higher than that of the primary route. It is used as a backup and only installed in the routing table when the primary route fails. This matches the requirement of using the static route only when the primary route is unavailable. Configuring a floating static route involves specifying a higher administrative distance than the dynamic routing protocol or the primary static route.

The ip helper-address command is used on an interface to forward UDP broadcasts, including DHCP requests, to a specified server. Configuring it with the DHCP server's IP address enables the router to relay DHCP requests from clients on that interface to the server. This is the correct command to enable DHCP relay functionality on the LAN interface.

PBR is applied to the interface where traffic enters the router. In this scenario, traffic from the 192.168.1.0/24 subnet arrives on GigabitEthernet0/0 (LAN). Therefore, you must apply the route map to that interface using the ip policy route-map command in interface configuration mode. This activates PBR for incoming packets on that interface, allowing the route map to be evaluated.

This command uses a wildcard mask of 255.255.255.255, which matches any IP address. It enables OSPF on all interfaces of the router, including both the 10.1.1.1/24 and 192.168.1.1/24 interfaces, achieving the goal with a single network statement.

A floating static route is configured with an administrative distance higher than that of the primary route. The command `ip route 0.0.0.0 0.0.0.0 192.168.1.1 200` sets the administrative distance to 200, which is higher than the default administrative distance of most dynamic routing protocols (e.g., OSPF is 110, EIGRP is 90). This ensures the static route is only used if the primary route is not in the routing table.

On spoke routers in DMVPN Phase 3, 'ip nhrp shortcut' allows them to install shortcut routes to other spokes based on NHRP redirect messages from the hub. Without this, spokes will not create direct tunnels and will continue to send traffic through the hub. This command is necessary for the spokes to dynamically learn the NBMA addresses of other spokes and establish direct connections. It is a key component of Phase 3 operation.

When you assign an interface to a VRF using `vrf forwarding`, Cisco IOS removes any existing IP address configuration. This is expected behavior because the interface's IP address must be unique within the VRF's routing table. The engineer must re-enter the IP address after assigning the VRF. This is a common operational step that often surprises engineers.

The ACTIVE state in EIGRP indicates that a route has been lost and the router is actively querying its neighbors for an alternative path. If replies are not received within the active timer (default 3 minutes), the route becomes stuck-in-active. Common causes include unidirectional links, packet loss, or a neighbor that is too busy to respond. In this scenario, R1 is sending queries but not receiving replies, which aligns with a unidirectional link or a neighbor issue.

On spoke routers in DMVPN Phase 3, 'ip nhrp shortcut' must be enabled to allow the spoke to install a shortcut route to the destination spoke when it receives an NHRP redirect from the hub. This command enables the spoke to override its default routing and send traffic directly to the destination spoke's NBMA address. Without it, the spoke ignores the redirect and continues to forward traffic through the hub.

This command uses the correct syntax for a static route: 'ip route' followed by the destination network, subnet mask, and next-hop address. The subnet mask 255.255.0.0 corresponds to a /16 prefix length, matching the 172.16.0.0/16 network. This is the standard way to configure an IPv4 static route on Cisco IOS.

When redistributing routes into OSPF, the subnets keyword is required to include subnetted routes. Without it, only classful networks are redistributed, so routes with subnet masks are not advertised. Since the scenario involves redistributing EIGRP routes, which are often subnetted, the subnets keyword ensures they are included in OSPF LSAs.

In DMVPN Phase 3, the hub must have ip nhrp redirect to inform spokes of a better path, and spokes must have ip nhrp shortcut to install shortcut routes. Without these, spoke-to-spoke tunnels will not be established. This is a common misconfiguration that prevents direct spoke communication.

The 'variance' command under the EIGRP routing process enables unequal-cost load balancing. The value (multiplier) determines which feasible successor routes can be used. A variance of 2 means that any feasible successor with a metric up to twice the successor's metric will be used for load balancing. This allows the higher-cost path to be utilized.

The address-family vpnv4 command is used to enter the VPNv4 address family configuration mode. Within this mode, you can activate BGP neighbors to exchange VPNv4 routes. This is required for PE routers to exchange VPNv4 prefixes, which include the route distinguisher and VPN label. Without this address family, PE routers cannot exchange VPN routing information.

For the hub to send NHRP redirect messages, it must have a route to the destination spoke network and be able to perform NHRP resolution. If the hub lacks a route or NHRP resolution fails, it cannot generate redirects. The engineer should verify that the hub has routes to all spoke networks, that NHRP entries are correct, and that the hub can resolve spoke NBMA addresses. This is a common cause of missing redirects in DMVPN Phase 3.

OSPFv3 is enabled per interface, unlike OSPFv2 which can be enabled under router configuration. Without the ipv6 ospf 1 area 0 interface command, the interfaces do not participate in OSPFv3, so no hellos are sent or received. This command activates OSPFv3 on the interface and associates it with Area 0. Thus, neighbors will form once the interfaces are enabled.

This sequence correctly identifies HTTP traffic using an extended ACL, matches it in a route-map, sets the next-hop, and applies the route-map to the incoming interface. PBR uses route-maps with match statements based on ACLs to classify traffic, and the ip policy route-map command enables PBR on the interface. This meets the requirement precisely.

To enable PBR, the route map must be applied to the interface using the 'ip policy route-map' command. Without this command, the route map is not used, and traffic follows the normal routing table. The engineer configured the route map but may have forgotten to apply it to the interface, which is a common oversight.

For MPLS L3 VPN, the PE router must have a BGP address-family for each VRF to exchange routes with other PEs. Without address-family ipv4 vrf CUSTOMER, the PE will not advertise or receive VPN routes for that customer, preventing connectivity. The VRF configuration alone is insufficient.

For a static route to be installed in the routing table, the next-hop address must be reachable via a valid route. If 10.0.0.1 is not reachable, the static route remains in the configuration but is not installed. This is a common issue when the next-hop is not directly connected or no route to it exists.

When redistributing routes into EIGRP, a seed metric is required because EIGRP uses a composite metric (bandwidth, delay, load, reliability, MTU). If no seed metric is provided, the routes will not be redistributed. You can specify the metric in the `redistribute` command using the `metric` keyword or set a default metric with the `default-metric` command under the EIGRP process.

This configuration defines an AS-path access list to match routes originating from AS 65001 (using the regular expression ^65001$) and a community list to match the community 100:200. The route map then matches both conditions and sets the local preference to 200. This fully satisfies the requirement.

The command 'show ipv6 ospf interface' displays OSPFv3 interface status, including whether OSPFv3 is enabled on the interface, the area ID, and the state. If OSPFv3 is not enabled, the interface will not appear or will show as passive. This directly answers the question of whether OSPFv3 is enabled on the interfaces.

A distribute-list can filter incoming or outgoing EIGRP routes. If applied inbound on the local router, it can prevent specific routes from being installed in the topology table. This matches the symptom of missing routes despite an established neighbor relationship. The distribute-list can reference an ACL or prefix-list to selectively filter routes based on network numbers or masks.

This correctly matches the source subnet and HTTP destination port using an extended ACL, then sets the next-hop for matching packets. Applying the route-map inbound on GigabitEthernet0/1 ensures only traffic arriving on that interface is policy-routed. This meets all conditions: specific source, specific destination port, and interface restriction.

The neighbor route-map command applies the route map to routes learned from the specified neighbor. For local preference to be set on inbound routes, the route map must be applied in the inbound direction using the in keyword. Without this command, the route map is not applied to incoming updates, so local preference remains at its default value of 100. This is the most likely missing configuration.

The `debug ip policy` command provides real-time detailed output about PBR processing, including which route map sequence is matched, the packet's source and destination, and the resulting action such as setting the next-hop or interface. It is the most detailed troubleshooting tool for PBR, showing exactly how packets are handled. However, it can be CPU-intensive and should be used with caution in production.

The router-id command under router ospf explicitly sets the OSPF router ID to 192.168.1.1. This value is used regardless of interface status, so the router ID remains stable even if Loopback0 flaps. Without this command, the router ID is dynamically selected based on highest loopback or active interface IP, which could change if the loopback fails.

The 'ipv6 ospf 1 area 0' command is used under an interface to enable OSPFv3 on that interface and assign it to area 0. This is required for the interface to participate in OSPFv3 and form adjacencies. Without it, the interface will not send or receive OSPFv3 hello packets. Thus, it is a necessary command.

A route map with a prefix list provides granular control over which EIGRP routes are redistributed into OSPF. Setting a tag on those routes allows EIGRP to deny routes with that tag when redistributing back, preventing loops. This is a standard best practice for mutual redistribution, ensuring only intended routes are advertised and loop prevention is enforced.

The 'set ip next-hop recursive' command allows the router to recursively resolve the next-hop IP address through the routing table, even if it is not directly connected. This enables PBR to forward traffic to a next-hop that is multiple hops away. This is the correct command to use when the next-hop is not directly connected.

Pinging the remote tunnel endpoint IP address tests reachability to the physical interface or loopback used as the tunnel destination. If the ping fails, the tunnel cannot pass traffic, and OSPF neighbors will not form. This command directly verifies Layer 3 connectivity to the endpoint, which is essential for a GRE tunnel to operate. It helps isolate whether the problem is in the underlay network or in the tunnel configuration itself.

This command sends an ICMP echo request to the tunnel destination (203.0.113.2) using the tunnel source address (203.0.113.1) as the source. If the ping succeeds, the tunnel endpoint is reachable, and the underlying transport network is working. If it fails, there is a routing or connectivity issue between the endpoints, which would prevent the tunnel from passing traffic. This is the correct way to test reachability to the tunnel destination.

For a GRE tunnel to be operational, the tunnel source and destination IPv4 addresses must be reachable. If the underlying IPv4 network cannot route between 10.1.1.1 and 10.2.2.2, the tunnel interface will remain down, and OSPFv3 will not form an adjacency. Additionally, the tunnel interface must be in an up/up state for OSPFv3 to run over it.

In DMVPN Phase 3, spokes initially use the hub for communication. When traffic to another spoke is detected, the spoke sends an NHRP resolution request. If the spoke lacks a route to the other spoke's tunnel endpoint (NBMA address) or NHRP resolution fails, the shortcut cannot be established. Ensuring NHRP resolution and routing to the NBMA address is critical.

EIGRP uses the network command with a wildcard mask to specify which interfaces participate in EIGRP. To advertise both 10.1.1.0/24 and 10.2.2.0/24, you need two network statements: one for each subnet. The wildcard mask 0.0.0.255 matches the /24 subnet. This configuration enables EIGRP on both interfaces and advertises the connected networks. This is the correct and specific way to achieve the goal.

A floating static route is configured with a higher administrative distance than the primary route, so it is only installed in the routing table when the primary route fails. This makes it a backup path. It is commonly used for redundancy in WAN links, where a secondary link should only be used if the primary goes down.

OSPFv3 requires that the interface be explicitly enabled for OSPFv3 using the 'ipv6 ospf <process-id> area <area-id>' interface configuration command. Without this, the router will not send Hello packets on that interface even if the OSPFv3 process is running. Other options are incorrect because they either do not prevent Hello generation or are not applicable.

Route targets control which routes are imported into and exported from a VRF. By assigning distinct RTs for import and export on each VRF, you ensure that routes from one VRF are not imported into another. This maintains VRF separation. Without proper RT configuration, routes could be leaked between VRFs if RTs are shared.

Removing passive-interface allows EIGRP to send and receive Hellos on the interface, forming adjacencies. An outbound distribute-list filters which routes are advertised, permitting only the desired subnet. This combination ensures only 10.1.1.0/24 is advertised out of GigabitEthernet0/0 while other subnets are suppressed.

EIGRP for IPv6 requires IPv6 unicast routing to be enabled globally. The routing process is created with ipv6 router eigrp AS number, and then EIGRP must be enabled on each interface using ipv6 eigrp AS number. This allows the interfaces to participate in EIGRP for IPv6 and form adjacencies with neighbors.

The address-family vpnv4 unicast is used on PE routers to exchange VPNv4 routes with other PE routers. It carries the RD and RT extended communities along with the customer prefixes. This address family must be activated on the PE-PE BGP session to propagate MPLS VPN routing information. Without it, VPNv4 routes are not exchanged, and MPLS VPN connectivity fails.

The address-family vpnv4 command enters the VPNv4 address family configuration mode. Within this mode, the engineer can activate neighbors and configure other VPNv4-specific parameters. Without this, the router cannot exchange VPNv4 prefixes with other PE routers. This is the correct command to enable the address family for MPLS L3VPN.

On a PE router, an MPLS L3VPN requires a VRF instance per VPN. The VRF must have a route distinguisher (RD) to make the VPN routes unique, and one or more route targets (RT) to control import and export of routes into and out of the VRF. This allows the PE to forward traffic to the correct CE based on the RT. Without these, VPN routing and forwarding would not work.

PBR requires a route map with at least one match statement (e.g., `match ip address` referencing an ACL for 10.1.1.0/24) and a set statement (e.g., `set ip next-hop 192.168.2.1`). The route map must be applied to the ingress interface with `ip policy route-map PBR`. If the match or set is missing, or if applied to the wrong interface, PBR will not take effect. This option correctly identifies the necessary configuration elements.

The `show bgp vpnv4 unicast all` command displays the BGP VPNv4 table, which contains routes from all VRFs. It shows the VPNv4 prefixes, their attributes, and the associated route distinguishers and route targets. This is critical to verify that the PE is receiving and advertising VPNv4 routes correctly. If routes are missing here, the issue may be with BGP configuration or route targets.

This sequence correctly implements PBR for HTTP traffic. The extended ACL matches source subnet and destination TCP port 80. The route-map uses match ip address to reference the ACL and set ip next-hop to specify the next-hop. Applying the route-map to the ingress interface with ip policy route-map activates PBR. This ensures only HTTP traffic from the subnet is policy-routed, while other traffic follows normal routing.