Select Two (Multi-Select) Questions

The requesting router uses the IA_NA option to request a prefix.

Why wrong: Incorrect. The requesting router uses the IA_PD (Identity Association for Prefix Delegation) option, not IA_NA (non-temporary address).

The delegating router must be configured with 'ipv6 dhcp server' under the downstream interface facing the requesting router.

Why wrong: Incorrect. The 'ipv6 dhcp server' command is used on the delegating router's interface facing the requesting router, but the statement is misleading because the delegating router enables DHCPv6 server functionality on the interface connected to the requesting router, not 'downstream' in the sense of LAN clients.

The requesting router can only use the delegated prefix on the interface that received it.

Why wrong: Incorrect. The requesting router can sub-delegate the prefix to downstream interfaces, typically using the 'ipv6 address prefix-from-provider' or similar command to assign /64 subnets from the delegated prefix.

CoPP is applied directly to physical interfaces to protect the control plane.

Why wrong: CoPP is applied globally to the control plane using the 'service-policy input' command under 'control-plane', not to individual interfaces.

CoPP operates at Layer 2 to filter Ethernet frames before they reach the CPU.

Why wrong: CoPP operates at Layer 3 and above, classifying packets based on IP headers and upper-layer information, not Ethernet frames.

CoPP replaces the need for access control lists (ACLs) on the device.

Why wrong: CoPP complements ACLs but does not replace them; ACLs are often used within class maps for CoPP classification.

Create a class-map that matches routing protocol packets (e.g., OSPF, EIGRP, BGP) and assign a police rate with conform-action transmit and exceed-action drop.

Why wrong: Incorrect. Using exceed-action drop will drop legitimate routing packets during spikes, which can cause routing instability.

Place routing protocol traffic into a class with a 'drop' action to prevent it from overwhelming the control plane.

Why wrong: Incorrect. Dropping routing protocol traffic would cause loss of routing adjacencies and network instability.

Apply the CoPP policy only to the 'control-plane host' subinterface, which processes all routing protocol packets.

Why wrong: Incorrect. The 'control-plane host' subinterface handles packets destined to the router itself, including routing protocols, but applying CoPP only there does not prevent drops; the policy actions still apply.

The output shows the routing table entries that are affected by the CoPP policy.

Why wrong: Incorrect. The command does not display routing table information; it only shows CoPP policy statistics.

The output displays the CoPP policy applied to each physical interface.

Why wrong: Incorrect. CoPP is applied to the control plane, not physical interfaces. 'show policy-map interface' shows per-interface policies.

The output includes the ARP cache entries that are protected by CoPP.

Why wrong: Incorrect. ARP cache is not displayed by this command; it shows only CoPP policy statistics.

It filters both incoming and outgoing IPv6 traffic on a port.

Why wrong: IPv6 Source Guard filters only incoming traffic (ingress) to prevent spoofing; it does not filter outgoing traffic.

It requires DHCPv6 snooping to be enabled on the VLAN to function.

Why wrong: While DHCPv6 snooping can populate the binding table, ND Inspection can also be used; DHCPv6 snooping is not strictly required.

RA Guard validates the source MAC address of Router Advertisements against the IPv6 source address.

Why wrong: Incorrect. RA Guard does not perform source MAC validation; it checks router preference and hop limit fields.

The default RA Guard policy action is to log Router Advertisements from unauthorized ports.

Why wrong: Incorrect. The default action is 'block', not 'log'. Logging can be configured separately.

RA Guard is typically enabled on trunk ports to protect against rogue RAs from other VLANs.

Why wrong: Incorrect. RA Guard is usually applied on access ports; trunk ports often need to forward legitimate RAs.

IPv6 Source Guard dynamically creates binding entries for all IPv6 addresses learned via ND.

Why wrong: Incorrect. Source Guard does not create bindings; it relies on DHCPv6 snooping or ND snooping to populate the binding table.

IPv6 Source Guard filters traffic based on the destination IPv6 address in the packet.

Why wrong: Incorrect. Source Guard filters based on source address, not destination.

IPv6 Source Guard only works with addresses learned via DHCPv6.

Why wrong: Incorrect. It can also work with addresses learned via ND snooping, not just DHCPv6.

Disable DHCPv6 snooping on the VLAN to allow RAs to be forwarded.

Why wrong: Incorrect. DHCPv6 snooping does not affect RA forwarding; it only monitors DHCPv6 messages.

Enable IPv6 Source Guard on the client-facing interfaces.

Why wrong: Incorrect. Source Guard filters source addresses, not RAs, and would not help with RA delivery.

Configure a DHCPv6 pool on the switch to provide addresses to clients.

Why wrong: Incorrect. SLAAC does not use DHCPv6; a DHCPv6 pool is for stateful DHCPv6, not SLAAC.

show ipv6 route

Why wrong: Incorrect. This command shows the IPv6 routing table, not FHS bindings.

show ipv6 traffic

Why wrong: Incorrect. This command shows IPv6 traffic statistics, not FHS-specific binding information.

Apply the ip nat outside command on the interface facing the internal network.

Why wrong: The outside command should be applied to the interface facing the external network, not the internal one.

Configure an access list to match the inside local addresses for translation.

Why wrong: Access lists are used for dynamic NAT or PAT, not for static NAT, which uses an explicit mapping.

Enable the ip nat service command globally to activate NAT.

Why wrong: There is no such global command; NAT is enabled by configuring translations and interface markings.

The source session can use an IPv6 address for the destination without any additional configuration.

Why wrong: Incorrect. ERSPAN source sessions support IPv4 destinations; IPv6 is not supported for ERSPAN source in most IOS-XE versions.

The source session can be configured to use a VRF for the destination IP reachability.

Why wrong: Incorrect. ERSPAN source sessions do not support VRF-lite for the destination; the destination IP must be reachable via the global routing table.

The source session automatically creates a GRE tunnel interface that can be verified with 'show ip interface brief'.

Why wrong: Incorrect. ERSPAN does not create a visible tunnel interface; the GRE encapsulation is handled internally by the monitor session.

The command 'ip ssh version 1' is required to enable SSH.

Why wrong: SSH version 2 is default; version 1 is deprecated and not recommended.

The command 'transport input ssh' must be configured globally.

Why wrong: This command is applied under the VTY line configuration, not globally.

RSA key modulus size must be at least 2048 bits for SSH version 2.

Why wrong: While 2048 bits is recommended, SSH version 2 works with smaller modulus sizes as well.

'show ip nat statistics'

Why wrong: Incorrect. This shows hit counts and configuration summary, not per-translation details needed for application failure analysis.

'show ip access-lists'

Why wrong: Incorrect. This shows ACL entries and matches, not NAT translations.

'show running-config | include nat'

Why wrong: Incorrect. This shows the NAT configuration, not the operational translations or debug output.

The 'ip nat inside source static' command automatically enables PAT when multiple inside hosts are configured.

Why wrong: Incorrect. Static NAT creates a one-to-one mapping and does not use PAT; each inside host requires a separate public IP.

The 'ip nat pool' command is required for all PAT configurations.

Why wrong: Incorrect. PAT can use a single interface IP without a pool; a pool is only needed when using a range of addresses.

The 'snmp-server group' command creates a group and assigns a username to it.

Why wrong: Incorrect. The 'snmp-server group' command creates an SNMP group and associates it with a security model and level, but it does not assign a username. Usernames are assigned to groups via the 'snmp-server user' command.

The engine ID is automatically generated and cannot be manually configured.

Why wrong: Incorrect. While the engine ID is automatically generated, it can be manually configured using the 'snmp-server engine-id local' command.

SNMPv3 supports only the authPriv security level.

Why wrong: Incorrect. SNMPv3 supports three security levels: noAuthNoPriv, authNoPriv, and authPriv.

show ntp packets

Why wrong: Incorrect. There is no 'show ntp packets' command in Cisco IOS. The correct command for packet statistics is 'show ntp statistics'.

show clock detail

Why wrong: Incorrect. 'show clock detail' shows the calendar time and time source (e.g., user, NTP), but it does not provide the detailed NTP synchronization status or associations like the other commands.

The 'ip domain-lookup' command is disabled by default on Cisco IOS routers.

Why wrong: Incorrect. The 'ip domain-lookup' command is enabled by default. It must be explicitly disabled with 'no ip domain-lookup' if DNS resolution is not desired.

The 'ip host' command creates a dynamic DNS entry that can be overwritten by a DNS server.

Why wrong: Incorrect. The 'ip host' command creates a static host entry in the local host table. Static entries are not overwritten by DNS responses; they take precedence over dynamic resolution.

The 'show hosts' command displays only statically configured host entries.

Why wrong: Incorrect. The 'show hosts' command displays both static and dynamically learned (via DNS) host entries, including their addresses and flags indicating how they were learned.

snmp-server community PUBLIC ro

Why wrong: This is for SNMPv1/v2c community strings, not SNMPv3.

snmp-server host 10.1.1.1 version 3 priv USER

Why wrong: This configures a trap receiver, not the user/group authentication.

snmp-server enable traps

Why wrong: Enables trap generation, but is not required for SNMPv3 authentication/encryption.

The 'show ip eigrp topology' command shows routes in active state.

Why wrong: Active state in topology indicates a query process, not directly an MTU problem.

The 'show ip eigrp interfaces' command shows a hold time of zero.

Why wrong: Hold time is a configured timer, not a dynamic value that drops to zero due to MTU issues.

When a router is configured as an EIGRP stub with the 'connected' keyword, it automatically advertises all connected interfaces, including passive interfaces, to its neighbors.

Why wrong: The 'connected' keyword only advertises connected routes that are part of the EIGRP process; passive interfaces are still advertised if they are in the EIGRP network statement, but the stub does not automatically include all connected interfaces unless they are explicitly in the EIGRP configuration.

The command 'show ip eigrp topology all-links' on a stub router displays only the routes that are in the routing table, as stub routers do not store feasible successors.

Why wrong: The 'all-links' option displays all EIGRP-learned routes, including feasible successors, regardless of stub status. Stub routers can still store feasible successors if they have multiple paths.

An EIGRP stub router configured with the 'static' keyword will automatically redistribute all static routes into EIGRP, even if the 'redistribute static' command is not present.

Why wrong: The 'static' keyword only allows the stub router to advertise static routes that are explicitly redistributed using the 'redistribute static' command under the EIGRP process; it does not enable automatic redistribution.