Select Two (Multi-Select) Questions

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

Why it fails: The ip nat outside command belongs on the external-facing interface, not the internal one; applying it there inverts the NAT domain mapping and breaks translation. It is tempting because outside designation is genuinely required for static NAT, but on the interface connected to the internet, where the global address is reachable.

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

Why it fails: Static NAT maps a fixed inside local address to a fixed inside global address using ip nat inside source static; no access list is referenced, so this step belongs to dynamic NAT with a pool or PAT. It is tempting because ACLs commonly accompany NAT configuration, but static entries match addresses directly.

Enable the ip nat service command globally to activate NAT.

Why it fails: NAT activates automatically once ip nat inside and ip nat outside are applied to the relevant interfaces; no global ip nat service command exists on Cisco IOS. It is tempting because other IOS features require global enablement, but static NAT needs only the inside source static mapping plus interface designations.

The authNoPriv security level uses encryption but no authentication.

Why it fails: authNoPriv uses authentication but no encryption; encryption is only in authPriv.

SNMPv3 always requires encryption for all security levels.

Why it fails: Encryption is optional; noAuthNoPriv and authNoPriv do not use encryption.

The 'priv' keyword in the snmp-server group command disables authentication.

Why it fails: The 'priv' keyword enables encryption, but authentication is still required.

It prevents rogue DHCPv6 servers from assigning malicious addresses.

Why it fails: ND Inspection validates ICMPv6 Neighbor Solicitation and Advertisement messages against the binding table; it does not police DHCPv6 server traffic. It is tempting because rogue DHCPv6 servers are a real threat, but that is handled by DHCPv6 Guard, which filters server advertisements on untrusted ports.

It uses a prefix list to determine which source addresses are allowed.

Why it fails: ND Inspection builds its binding table from snooped Neighbor Discovery messages and uses a policy (trusted/untrusted) plus optional static bindings, not a prefix list of permitted source addresses. A prefix list is tempting because IPv6 access lists and RA Guard policies do filter by prefix, but that is a different feature.

It is enabled globally and cannot be applied on a per-interface basis.

Why it fails: ND Inspection is configured per interface (or per VLAN) with ipv6 nd inspection, marking ports trusted or untrusted, so it is not a global-only feature. It is tempting because some IPv6 first-hop security features are enabled globally, but interface-level policy is precisely how ND Inspection scopes its enforcement.

Spokes must be configured with the ip nhrp network-id command matching the hub.

Why it fails: The ip nhrp network-id command is used to identify the NHRP network. It must match on all routers in the same DMVPN cloud for NHRP to function. However, if the network-id mismatched, NHRP resolution would fail entirely, preventing even spoke-to-hub communication. Since the scenario states that spokes are unable to establish direct spoke-to-spoke tunnels but presumably can reach the hub, a network-id mismatch is not the likely cause. Thus, it is not a correct explanation for the specific issue.

The hub must be configured with the ip nhrp map multicast dynamic command.

Why it fails: The ip nhrp map multicast dynamic command is used on the hub to automatically add multicast mappings for spokes. It is commonly used for routing protocol multicast traffic, but it is not specific to Phase 3 operation. While it may be present in a DMVPN configuration, it does not enable or disable spoke-to-spoke shortcut tunnels. Therefore, its absence would not directly cause the failure of direct spoke-to-spoke tunnels in Phase 3.

The hub must be configured with the ip nhrp authentication command.

Why it fails: The ip nhrp authentication command is used to authenticate NHRP messages between peers. If authentication is misconfigured, NHRP resolution would fail, affecting all NHRP operations, not just spoke-to-spoke tunnels. While authentication is important for security, it is not a Phase 3-specific requirement for shortcut tunnels. The question asks for statements that describe correct Phase 3 operation that could explain the issue; authentication is not specific to Phase 3. Hence, it is not a correct choice.

The hub must have 'ip nhrp shortcut' configured on its tunnel interface.

Why it fails: 'ip nhrp shortcut' is configured on the spokes, not the hub. It allows the spoke to intercept packets that are being sent to the hub for a destination that is reachable directly, and instead send an NHRP resolution request for the destination. On the hub, this command is not used. Therefore, configuring it on the hub would not achieve the desired Phase 3 behavior.

The hub must have 'ip nhrp network-id' configured with the same value as the spokes.

Why it fails: The 'ip nhrp network-id' is a mandatory configuration on all DMVPN routers, including the hub and spokes, to identify the NHRP network. While it is required for NHRP to function, it is not specific to enabling spoke-to-spoke communication in Phase 3. The question asks for two statements that are true regarding the hub configuration to support spoke-to-spoke communication, and this is a general requirement, not a specific Phase 3 feature.

The hub must have 'ip nhrp map multicast dynamic' configured to support multicast traffic.

Why it fails: 'ip nhrp map multicast dynamic' is typically configured on the hub in DMVPN to allow it to replicate multicast and broadcast traffic to all registered spokes. While it is a common command for multicast support, it is not specifically required for spoke-to-spoke unicast communication in Phase 3. The question focuses on spoke-to-spoke communication, which relies on NHRP redirect and shortcut. Thus, this command is not one of the two required statements.

Group members must have a static VRF configured to isolate the GET VPN traffic from the global routing table.

Why it fails: VRF isolation is not a requirement for GET VPN group membership. GET VPN typically runs over the global routing table, and while VRFs can be used for other design reasons, they are not part of the GDOI registration or key distribution process. Adding a VRF does not help a member join the group or decrypt traffic.

Group members must be configured with the same ACL as the key server to define interesting traffic for the encryption policy.

Why it fails: Interesting traffic ACLs in GET VPN are defined within the group policy that the key server distributes, not manually on each member. The member receives the encryption policy and TEK parameters from the key server. Manually configuring a matching ACL is unnecessary and can conflict with the downloaded policy.

Group members must have IKEv2 configured with a certificate authority to authenticate to the key server.

Why it fails: GET VPN GDOI uses IKE Phase 1 (ISAKMP) to establish the registration and rekey channel with the key server, not IKEv2 with a CA. While certificates can be used for IKE authentication, IKEv2 with a CA is not a requirement; preshared keys or IKEv1 with RSA signatures commonly suffice in GDOI deployments.

The OSPFv3 router ID is a 128-bit value derived from the highest loopback IPv6 address.

Why it fails: The OSPFv3 router ID is a 32-bit value formatted like an IPv4 address, not 128-bit, and it is not derived from an IPv6 loopback address. It must be manually configured or inherited from an IPv4 address. A 128-bit identifier describes the IPv6 address, not the router ID.

The 'ipv6 router ospf' command is used to enable OSPFv3 on an interface.

Why it fails: The 'ipv6 router ospf' command creates the OSPFv3 routing process in global configuration mode; interface participation requires 'ipv6 ospf <process-id> area <area-id>' under the interface. It is tempting because process creation is a genuine prerequisite, but that step alone leaves the interface without an OSPFv3 adjacency.

OSPFv3 uses the network type configured under the OSPFv3 process globally, not per interface.

Why it fails: OSPFv3 network type is configured per interface with 'ipv6 ospf network', not globally under the process; the stem's global claim contradicts IOS-XE behaviour. It is tempting because several OSPFv3 parameters, such as router-id and reference bandwidth, are indeed set process-wide, but network type is not among them.

The severity level in a syslog message ranges from 0 (debugging) to 7 (emergency).

Why it fails: Incorrect: Severity 0 is Emergency, 7 is Debugging.

By default, Cisco IOS includes a sequence number in every syslog message when logging is enabled.

Why it fails: Incorrect: Sequence numbers are optional and not present by default.

The timestamp in a syslog message from a Cisco device is formatted as DD/MM/YYYY HH:MM:SS by default.

Why it fails: Correct: By default, Cisco IOS logs timestamps in DD/MM/YYYY HH:MM:SS format.

The hostname field in a syslog message is derived from the IP address of the interface that sends the message.

Why it fails: Incorrect: The hostname is the device's configured hostname, not derived from IP.

The egress LSR performs label imposition (push) before forwarding the IP packet to the destination.

Why it fails: Label imposition occurs at the ingress LSR, which pushes the label onto the unlabelled IP packet entering the MPLS domain. The egress LSR instead performs disposition, removing the label before delivering the packet. Imposition is tempting because it is the first label operation in the forwarding path, but it belongs to ingress, not egress.

PHP is enabled only when the egress LSR is not directly connected to the penultimate LSR.

Why it fails: PHP operates regardless of whether the egress LSR is directly connected to the penultimate LSR; adjacency is not the trigger. The penultimate LSR pops the label whenever it has an implicit-null label for the destination. Direct connectivity is tempting because it affects label distribution method, not PHP activation.

By default, PHP is disabled on Cisco IOS routers and must be explicitly configured.

Why it fails: PHP is enabled by default on Cisco IOS routers; the penultimate LSR pops the outer label so the egress LSR receives an unlabelled packet. Disabling it requires explicit configuration, not enabling. The statement inverts the default, which is tempting because PHP behaviour is configurable and often discussed alongside explicit-null settings.

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

Why it fails: 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 it fails: Cisco IOS XE generates a default engine ID from the chassis and enterprise number, but the snmp-server engineID command overrides it manually. The option's absolute claim of immutability fails; manual configuration is required when matching an existing SNMPv3 engine across devices.

SNMPv3 supports only the authPriv security level.

Why it fails: SNMPv3 defines noAuthNoPriv, authNoPriv and authPriv; authPriv is merely the strongest, not the only level. The option overstates the restriction. authNoPriv is valid where authentication is needed without payload encryption, and noAuthNoPriv remains available for legacy-style polling.

Apply the policy map to a physical interface using the 'service-policy input' command.

Why it fails: CoPP is applied to the control plane, not to physical interfaces.

Configure a 'shape average' command in the policy map to limit traffic rate.

Why it fails: CoPP uses 'police' for rate-limiting, not 'shape'; shaping is for interface queues.

Apply the policy map to the control plane using the 'service-policy input' command under the interface configuration mode.

Why it fails: The 'service-policy input' command is used under 'control-plane' configuration mode, not interface mode.

Enable IPv6 routing globally with 'ipv6 unicast-routing'.

Why it fails: Global IPv6 unicast routing is not required for RA Guard; the feature operates at Layer 2 on the interface and is enabled per-port with 'ipv6 nd raguard policy' and attachment. It tempts because routing is needed for IPv6 forwarding generally. RA Guard is correct when blocking rogue RAs on access ports.

Configure 'ipv6 nd raguard' directly on the interface without a policy.

Why it fails: RA Guard requires a policy defined in global configuration and then attached to the interface; the interface-level command alone is not the supported syntax. It is tempting because many interface features are enabled with a single command, and a policy would be the correct approach when applying differentiated blocking or monitoring behaviour across multiple ports.

Enable DHCPv6 Guard on the same interface to complement RA Guard.

Why it fails: DHCPv6 Guard filters rogue DHCPv6 servers and is unrelated to RA Guard's function of blocking unauthorised router advertisements; enabling it is not a required step. It is tempting because both are IPv6 first-hop security features often deployed together, and DHCPv6 Guard would be correct when the requirement is preventing rogue DHCPv6 servers.

The route is received with a higher local preference than the best path.

Why it fails: Incorrect. Higher local preference makes the route more preferred; it would be installed as best if it wins the path selection.

The neighbor is configured with 'soft-reconfiguration inbound'.

Why it fails: Incorrect. Soft-reconfiguration stores received updates but does not affect route installation; the route is still installed if it is the best path.

The interface is flapping up and down.

Why it fails: Interface flapping is usually due to physical or Layer 2 issues, not ACLs.

Routing protocol neighbors are dropping.

Why it fails: Neighbor drops are usually due to protocol timers, authentication, or MTU issues, not ACLs.

snmp-server community PUBLIC ro

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

snmp-server host 10.1.1.1 version 3 priv USER

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

snmp-server enable traps

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

Use the 'show authentication sessions interface' command to view the session status and method.

Why it fails: The 'show authentication sessions interface' command shows the authentication session details, such as the method used (dot1x, mab, webauth) and the status. While it can confirm if a session exists, it does not directly indicate whether EAPOL packets are being received or processed. It is less specific for EAPOL troubleshooting.

Check the 'show mac address-table interface' command to see if the supplicant's MAC address is learned.

Why it fails: The MAC address table shows learned MAC addresses, which can indicate if the supplicant is sending traffic. However, it does not confirm that EAPOL packets are being received or processed by the 802.1X authentication process. EAPOL frames are not learned in the MAC address table in the same way as regular data frames.

Use the 'show radius statistics' command to verify RADIUS server reachability.

Why it fails: The 'show radius statistics' command displays RADIUS packet statistics, such as access-requests and access-challenges. While it can help diagnose RADIUS communication issues, it does not show whether the switch is receiving EAPOL packets from the supplicant. The issue is between the supplicant and the switch, not the switch and the RADIUS server.

The 'network' command is used to create a summary route in BGP.

Why it fails: The 'network' command injects a prefix into the BGP table only when a matching route already exists in the RIB; it does not aggregate component routes into a summary. It is tempting because it originates prefixes, which suits advertising a static or connected subnet, but summarisation requires the 'aggregate-address' command instead.

BGP summarization requires a route-map to suppress more specific routes.

Why it fails: BGP summarisation is achieved with the aggregate-address command, which can suppress more specifics via the summary-only keyword; a route-map is not required. It is tempting because route-maps commonly filter and manipulate BGP attributes, and would be correct when selectively setting communities or metrics on advertised routes.

Route summarization in BGP can only be configured on route reflectors.

Why it fails: Summarisation is configured per BGP process or per neighbour with 'aggregate-address', on any router, not solely on route reflectors. Route reflectors are tempting because they centralise iBGP prefix propagation and reduce peer meshes, but that is a separate scaling mechanism from summarisation itself.

CoPP automatically drops all traffic that exceeds the configured rate, regardless of the exceed-action specified in the policy.

Why it fails: CoPP does not automatically drop all excess traffic; the action taken on packets that exceed the rate is defined by the exceed-action in the police command. Common actions include drop, transmit, or mark. The default exceed-action is drop, but it can be changed. Therefore, it is incorrect to say it always drops all excess traffic.

The class-default class in a CoPP policy-map must always have a police action configured to drop all unmatched traffic.

Why it fails: The class-default class does not require a police action. By default, unmatched traffic is transmitted without policing. Configuring a police action on class-default would restrict all other traffic, which may not be desired. It is a common practice to leave class-default unpoliced to allow legitimate traffic, or to configure a high policing rate if needed.

CoPP can be applied to a specific interface to police traffic entering that interface before it reaches the control plane.

Why it fails: CoPP is not applied to interfaces; it is applied to the control plane. Interface-level policing would affect all traffic, not just control plane traffic. CoPP specifically targets traffic destined to the router itself, and it is applied under the control-plane configuration. Applying a policy-map to an interface would police transit traffic as well, which is not the purpose of CoPP.

Configure an access-list to match the traffic.

Why it fails: An access-list is used inside the route-map's match statements, not as a standalone required step. PBR requires defining a route-map with match and set clauses and applying it to the interface, so the ACL alone is insufficient.

Enable CEF globally.

Why it fails: CEF is enabled by default on modern Cisco IOS and is not a PBR configuration step. PBR needs a route-map defining match criteria and set next-hop, plus interface application via 'ip policy route-map'; enabling CEF configures nothing for policy routing.

Use the 'ip local policy route-map' command.

Why it fails: 'ip local policy route-map' applies PBR to router-generated traffic only, not to transit traffic being routed through interfaces. Interface-level 'ip policy route-map' is required for forwarded packets, so this command addresses the wrong traffic class.

OSPF as the PE-CE routing protocol

Why it fails: OSPF can be used as a PE-CE routing protocol, but it is not required for exchanging customer routes between PEs. The core exchange relies on MP-BGP. Using OSPF on the PE-CE link is a design choice; other protocols like BGP or EIGRP are equally valid. Thus, OSPF is not a mandatory component for the inter-PE route exchange.

RSVP-TE for traffic engineering

Why it fails: RSVP-TE is used for traffic engineering in MPLS networks, providing explicit paths and bandwidth reservation. It is not required for basic MPLS Layer 3 VPN route exchange. While it can be deployed in the core, it is an optional feature for optimizing traffic, not a prerequisite for VPNv4 route distribution between PEs.

LDP for label distribution

Why it fails: LDP distributes labels for the core IGP routes, enabling label switching within the MPLS domain. However, LDP is not used to exchange customer VPN routes between PEs. While LDP is often used in the core, it is not a requirement for VPN route exchange; MP-BGP is responsible for that. Therefore, LDP alone does not fulfill the requirement.