Security practice questions

The switch has IP Source Guard enabled, blocking valid DHCP traffic.

Why it fails: IP Source Guard enforces source IP addresses against the DHCP snooping binding table, but binding entries are created only after a client successfully completes DHCP. A DHCPDISCOVER or DHCPREQUEST is sent from 0.0.0.0 before any binding exists, and IP Source Guard does not filter the DHCP handshake itself. Therefore, enabling IP Source Guard would not cause DHCP snooping to block valid DHCP traffic on the server-facing interface.

The DHCP server is on a different subnet and the switch lacks an IP helper address.

Why it fails: A DHCP server on a different subnet would require an IPv4 helper address on the Layer 3 interface to relay broadcast DHCPDISCOVER messages, but this is a separate routing issue rather than a DHCP snooping trust problem. In the described scenario, the server is reachable in the same VLAN, so no ip helper-address is needed; DHCP snooping is operating in the Layer 2 domain. Missing helper addresses cause offer/ack timeouts at the client, but they do not cause DHCP snooping to drop server messages at the switch.

The DHCP server is sending offers too quickly, exceeding the rate-limit on the switch.

Why it fails: The DHCP snooping rate limiter, configured with 'ip dhcp snooping limit rate', applies only to packets from untrusted clients, not to server-to-client responses like DHCPOFFER and DHCPACK. It is designed to prevent DHCP starvation attacks where a malicious host floods the switch with fake DISCOVER messages, exhausting the address pool. A server sending offers quickly would not trip this limiter, and if it did, the impact would be rate-based throttling, not the complete absence of DHCP replies caused by untrusted server ports.

Manually shut down the access ports that have unknown MAC addresses in the binding table.

Why it fails: This does not address the DHCP server response being dropped.

Disable Dynamic ARP Inspection on VLAN 10.

Why it fails: Disabling DAI on VLAN 10 leaves the rogue DHCPACK drops unaddressed, since the trunk port's trusted-state configuration governs snooping, not DAI. DAI validates ARP packets against the snooping binding table; it is the right control when spoofed ARP replies, not dropped DHCPACKs, cause the fault.

Disable IP Source Guard on all access ports in VLAN 10.

Why it fails: IP Source Guard filters traffic by matching source IP and MAC against the DHCP snooping binding table; disabling it removes that enforcement but leaves the dropped DHCPACK on the trunk untouched, so duplicate addresses persist. It is tempting because IPSG does police spoofed bindings, but it is the correct control for untrusted access ports, not trunk-side DHCP relay trust.

STP (802.1D): Per-VLAN spanning tree

Why it fails: Incorrect — STP is a single spanning tree for all VLANs; per-VLAN is PVST+.

RSTP (802.1w): Multiple spanning tree instances

Why it fails: Incorrect — RSTP runs a single instance; multiple instances are provided by MSTP.

The 'switchport port-security violation shutdown' command does not generate syslog messages; the administrator must configure 'switchport port-security violation restrict' instead.

Why it fails: The shutdown violation mode does generate a syslog message when a violation occurs. The restrict mode also generates a syslog message, but it does not shut down the port. The issue is not the violation mode but the lack of logging configuration.

The switchport port-security violation shutdown command requires the 'logging synchronous' command on the console line to display messages.

Why it fails: The 'logging synchronous' command affects console output by preventing log messages from interrupting command input; it does not control whether syslog messages are generated or sent to a syslog server. The absence of messages is due to logging level, not console synchronization.

The port security violation mode must be set to 'protect' to generate syslog messages.

Why it fails: The protect violation mode drops packets but does not generate syslog messages. The shutdown mode does generate syslog messages, but only if the logging level permits it. The issue is not the violation mode but the logging configuration.

Change the switch port to `authentication host-mode multi-domain`.

Why it fails: Multi-domain mode is used when a single port must support both a voice device and a data device, such as an IP phone with a PC attached. It does not force the supplicant to start on the laptop. The symptom described is a supplicant initialization problem, not a host-mode limitation, so changing host-mode will not resolve it.

Enable MAC Authentication Bypass (MAB) on the switch port.

Why it fails: MAB is a fallback for devices that do not support 802.1X supplicants, such as printers or cameras. It uses the device MAC address as the username and password. The laptops in this scenario are corporate Windows devices that should have a native 802.1X supplicant. Enabling MAB would not fix the initial authentication failure and could weaken security by allowing MAC-based access.

Configure the switch port as a trunk instead of an access port.

Why it fails: The port mode (access or trunk) does not affect whether the supplicant starts authentication. Changing to a trunk could actually break connectivity for the laptops and does not address the supplicant behavior. The issue is that the supplicant is not initiating EAPOL, not the VLAN tagging on the port.

switchport port-security violation restrict

Why it fails: The restrict mode drops packets from violating MAC addresses and generates SNMP traps and syslog messages, but it does not place the interface into the err-disabled state. Because the policy explicitly requires err-disable, restrict does not satisfy the requirement even though it does send traps.

switchport port-security maximum 1

Why it fails: Setting the maximum number of allowed MAC addresses to one limits how many devices can connect but does not define the action taken when a violation occurs. Without a violation mode configured, the default is shutdown, but the question requires explicit configuration to guarantee the behavior; the maximum command alone does not generate SNMP traps by itself.

switchport port-security violation protect

Why it fails: Protect mode silently drops frames from unauthorized MAC addresses without generating any SNMP trap, syslog message, or err-disable action. This mode is the least intrusive and therefore fails the policy requirement for both err-disable and SNMP trap generation on violation.

Apply an ACL directly to the control plane interface with 'ip access-group' to permit only ARP at 100 pps.

Why it fails: ACLs do not have rate-limiting capabilities; they only permit or deny traffic based on match criteria. Applying an ACL to the control plane interface is not a valid configuration; CoPP requires a policy-map with policing actions. This option fails because it cannot enforce a packet rate limit and misuses ACL functionality.

Configure a class-map matching ARP, create a policy-map with a police rate of 100 pps, and apply it to all physical interfaces with 'service-policy input CoPP'.

Why it fails: Applying the policy to physical interfaces would police all ingress traffic on those interfaces, not just traffic destined to the control plane. This could impact transit traffic and does not specifically protect the CPU. CoPP must be applied to the control plane, not to data plane interfaces, to rate-limit only control-plane-bound packets.

Use MQC to create a policy-map with a police rate of 100 pps for ARP and apply it to the control plane using 'service-policy output CoPP'.

Why it fails: The 'service-policy output' command applies to egress traffic from the control plane, not ingress. CoPP is designed to police traffic entering the control plane from the data plane, so 'input' is required. Using 'output' would not rate-limit ARP packets destined to the CPU, leaving the control plane unprotected against ARP floods.

The police action of 100000 bps is applied to all traffic because the policy map lacks a class-default configuration.

Why it fails: The absence of a class-default does not cause all traffic to be policed; only traffic matching configured class maps is policed. The issue is that the SSH class map is matching all traffic, likely due to an incorrect match statement.

The policy map 'COPP-POLICY' has an implicit default class that matches all traffic and applies the same police action.

Why it fails: CoPP policy maps do not have an implicit default class; unmatched traffic is not policed unless explicitly configured. The issue is likely due to the class map matching more traffic than intended, such as using 'match any' instead of specific criteria.

The control plane service policy requires an explicit permit statement for other traffic; otherwise, all traffic is policed by default.

Why it fails: CoPP does not require explicit permit statements for other traffic; unmatched traffic is not policed unless a class map matches it. The problem is that the class map is matching all traffic, not the absence of a permit statement.

A crypto map with the peer address set to 0.0.0.0

Why it fails: The crypto map set peer command requires a specific IP address or hostname of the remote peer. Setting it to 0.0.0.0 is not valid for a site-to-site crypto map. For dynamic peers, the local router typically acts as the responder and uses a dynamic crypto map, not a peer address of 0.0.0.0.

A dynamic crypto map with no set peer and a match address ACL

Why it fails: A dynamic crypto map is used on the hub when the spoke has a dynamic address, but the question asks for the element required to accept IKE from any peer with pre-shared keys. A dynamic crypto map alone does not authenticate the peer; the pre-shared key with wildcard address is required. The dynamic crypto map is part of the solution but not the specific required element for IKE authentication.

A crypto isakmp key with the peer's hostname and no address

Why it fails: Cisco IOS requires an address or wildcard for the pre-shared key entry. Specifying only a hostname is not a valid syntax for crypto isakmp key. The router needs to know which peer addresses the key applies to, and with a dynamic peer the wildcard 0.0.0.0 0.0.0.0 is used.

Guest VLAN

Why it fails: Guest VLAN is used when a device does not support 802.1X or fails authentication, not when the RADIUS server is unreachable. Guest VLAN typically provides limited internet access. The requirement here is specifically for RADIUS server unavailability, which maps to critical VLAN or a similar fallback, but the restricted remediation access points to a different feature.

Critical VLAN

Why it fails: Critical VLAN is used when the RADIUS server is unreachable, but it typically provides full network access or a pre-configured VLAN for critical services. It is not specifically for restricted remediation access. The scenario requires restricted access to remediation servers, which is the purpose of a guest or restricted VLAN, not critical VLAN.

Auth Fail VLAN

Why it fails: Auth Fail VLAN is used when authentication fails (e.g., wrong credentials), not when the RADIUS server is unreachable. It places the port in a VLAN for failed authentication. The scenario specifies server unreachability, so this is not the correct trigger.

macsec mka

Why it fails: There is no combined 'macsec mka' command in Cisco IOS XE. MACsec and MKA are configured separately. The correct approach is to enable MACsec with 'macsec' and then enable MKA with 'mka'. Using an invalid command would result in a syntax error and MACsec would not operate properly, leaving the link unsecured.

mka key-server priority 1

Why it fails: The 'mka key-server priority' command sets the priority for the key server election but does not enable MKA itself. MKA must be enabled before key server parameters can be configured. Without enabling MKA, this command would have no effect, and MACsec would not function. This command is used after MKA is enabled to influence which switch becomes the key server.

macsec

Why it fails: The 'macsec' command enables MACsec on the interface but does not enable MKA. MACsec and MKA are separate; MKA is the key agreement protocol. By default, enabling MACsec may also enable MKA, but the question specifically asks for the command to enable MKA. In some configurations, you must explicitly enable MKA with 'mka' under the interface. However, on many platforms, 'macsec' implicitly enables MKA, but the explicit command is 'mka'.

Configure a security group ACL (SGACL) on the switch to filter traffic based on SGT.

Why it fails: SGACLs are used for enforcement, not for propagation. They define which traffic is allowed between security groups. While SGACLs are part of a complete TrustSec deployment, they are not required to support SGT propagation. The question specifically asks for actions required to support SGT propagation and enforcement, and SGACLs are enforcement-only.

Configure 802.1X with MAB on all access ports to assign SGTs dynamically.

Why it fails: 802.1X and MAB are used for identity-based authentication and can be used to assign SGTs via Cisco ISE, but they are not required for SGT propagation and enforcement. SGTs can also be assigned statically or via SXP. The question asks for actions required to support SGT propagation, not for the authentication method.

Configure the switch to use SXP (SGT Exchange Protocol) to share SGTs with non-TrustSec devices.

Why it fails: SXP is used to propagate SGTs to devices that do not support hardware-based CTS, such as older switches or routers. It is not required on a Catalyst 9000 switch that supports native SGT tagging. SXP is an optional component for mixed environments, not a mandatory step for SGT propagation on TrustSec-capable hardware.

Apply a class-map matching 'match access-group name BGP_PEERS' with a police rate of 8000 pps, conform-action transmit, exceed-action transmit, and remove the default CoPP policy.

Why it fails: Removing the default CoPP policy eliminates policing for all other control-plane protocols, leaving ARP, ICMP, and routing protocols unprotected. Excess transmissions for BGP alone do not protect the CPU from non-BGP floods, so the requirement to protect the CPU during BGP flaps without disrupting BGP is only partially met.

Apply a class-map matching 'match protocol bgp' with a police rate of 8000 pps and a conform-action transmit, exceed-action drop.

Why it fails: Matching 'protocol bgp' via NBAR identifies BGP traffic correctly, but a rigid 8 Mbps-style policer still drops legitimate UPDATE bursts during session re-establishment. CoPP should rate-limit abnormal control-plane floods, not normal reconvergence traffic, so this configuration risks blackholing valid routes.

Apply a class-map matching 'match access-group name BGP_PEERS' with a police rate of 8000 pps and a conform-action transmit, exceed-action drop.

Why it fails: While policing BGP is part of the solution, an 8000 pps hard drop limit can discard legitimate BGP UPDATE bursts after session re-establishment, when the full routing table is exchanged. This disrupts convergence more than it protects the CPU, so it does not satisfy the requirement to protect the CPU without disrupting legitimate BGP updates.

Create a zone-pair for inside-to-outside with an inspect policy, and apply an ACL to the outside interface to deny all inbound traffic.

Why it fails: Using an interface ACL to deny inbound does not replace the need for a zone-pair for outside-to-inside. ZPF enforces policy based on zone-pairs, and traffic from outside to inside would be implicitly dropped only if a zone-pair exists with a drop action. An interface ACL alone does not satisfy the ZPF requirement and may conflict with ZPF processing.

Create a zone-pair for inside-to-outside with an inspect policy, and configure the router to use the outside interface as the source for SSH.

Why it fails: Configuring the source interface for SSH does not create the necessary zone-pair for self-to-outside traffic. ZPF treats router-originated traffic as coming from the self zone, so a zone-pair from self to outside with a policy that permits SSH is required. Changing the source interface alone does not satisfy ZPF policy.

Create a zone-pair for inside-to-outside with an inspect policy, and a zone-pair for self-to-outside with an inspect policy, and rely on the implicit drop for outside-to-inside.

Why it fails: While an implicit drop exists for traffic that does not match any zone-pair, relying on it for outside-to-inside is not sufficient because the requirement is to explicitly deny that traffic. More importantly, the self-to-outside zone-pair with an inspect policy would allow return traffic, but the outside-to-inside direction still needs an explicit policy to ensure denial. The correct answer includes an explicit drop policy for outside-to-inside.

ip dhcp snooping trust on the access port and ip dhcp snooping limit rate 10 on the uplink

Why it fails: Trusting the access port would allow DHCP server messages from an untrusted source and defeats DHCP snooping protections. Applying the rate limit on the uplink rather than the access port does not limit client DHCP requests where the starvation attack originates, so this configuration is incorrect.

ip dhcp snooping information option allow-untrusted combined with a DHCP snooping rate limit of 10

Why it fails: The information option allow-untrusted command relates to handling DHCP option 82 from untrusted ports and does not impose a rate limit. It does not address DHCP starvation, and combining it with a rate limit does not satisfy the requirement to limit requests per second on the access port.

ip dhcp snooping limit rate 10 configured globally under ip dhcp snooping configuration mode

Why it fails: The DHCP snooping rate limit is an interface-level command, not a global one. Configuring it in global DHCP snooping mode is not valid syntax for this purpose and would not apply the per-port rate limit required to mitigate DHCP starvation on the untrusted access port.

The 'authentication event server dead action authorize vlan 100' command only applies to unauthenticated devices; authenticated devices require 'authentication event server dead action reinitialize'.

Why it fails: The 'authorize vlan' action applies to both authenticated and unauthenticated devices, placing them in the specified VLAN. The issue is likely that the command is not applied correctly or the interface is not configured with the correct authentication settings.

The interface is missing the 'authentication event server dead action authorize' command for authenticated devices, or the command is not supported on the platform.

Why it fails: The command 'authentication event server dead action authorize vlan 100' is supported on many Cisco Catalyst platforms. If it is missing, authenticated devices would be disconnected. However, the more common cause is that the command is configured but the RADIUS server is not properly monitored.

The 'authentication event server dead action authorize vlan 100' command requires the 'authentication event fail action authorize vlan 100' command to be configured as well.

Why it fails: The server dead and fail actions are independent. The fail action handles authentication failures, while the dead action handles server unavailability. The absence of a fail action does not affect the dead action. The issue is server dead detection.

police 8000 conform-action transmit exceed-action drop

Why it fails: This statement rate-limits OSPF to 8000 kbps and drops excess packets. Although 8000 kbps exceeds typical OSPF hello rates, the policy still drops traffic once the threshold is exceeded, which does not guarantee that OSPF hellos are never dropped. The requirement is to exempt OSPF from policing entirely, so applying any policer to the OSPF class fails to meet the stated condition.

police 8000 conform-action transmit exceed-action transmit

Why it fails: This police statement permits traffic up to 8000 kbps and also transmits traffic that exceeds that rate, effectively disabling rate limiting. While OSPF hellos would pass, the class would no longer enforce any policing, which is inconsistent with using CoPP to protect the control plane. It does not represent an explicit exemption from policing and could allow a flood of OSPF packets to impact the RP.

police 8000 conform-action transmit exceed-action set-dscp-transmit af31

Why it fails: This action remarks excess OSPF traffic to AF31 and transmits it, which still applies a policer to the OSPF class. Remarking does not exempt the protocol from rate limiting, and it alters the DSCP of control-plane traffic, which can cause unintended QoS behaviour. It does not satisfy the requirement that OSPF hellos be unconditionally permitted.

Configure the WLC to use LEAP as the EAP type and enable CCKM for fast roaming.

Why it fails: LEAP is a Cisco-proprietary EAP method that uses username and password credentials, not certificates. It does not support the mutual certificate authentication required by EAP-TLS. CCKM is used for fast roaming with LEAP or other EAP methods but does not enable EAP-TLS.

Enable MAC filtering on the WLC and add all corporate client MAC addresses to the local database.

Why it fails: MAC filtering is a separate access control mechanism and does not replace or enable EAP-TLS. While MAC filtering can be used as an additional layer, it does not provide the certificate-based mutual authentication that EAP-TLS requires. The WLAN security policy must still be configured for 802.1X with EAP-TLS.

Configure a preshared key on the WLC and distribute it to all corporate clients through Group Policy.

Why it fails: Preshared keys are used with WPA2-Personal, not with 802.1X/EAP-TLS. EAP-TLS relies on digital certificates for mutual authentication and does not use preshared keys. Distributing a PSK would not provide the certificate-based authentication required by the policy.

Cisco TrustSec SGACLs enforced at the distribution layer

Why it fails: Security Group ACLs (SGACLs) enforce role-based access control using SGTs, but they do not provide encryption of the traffic. They filter packets based on group tags, not cryptographic protection. The requirement explicitly calls for encryption and authentication at Layer 2, which SGACLs alone cannot deliver.

Dynamic ARP Inspection (DAI) with DHCP snooping binding table

Why it fails: DAI validates ARP packets against the DHCP snooping binding table to prevent ARP spoofing, but it offers no encryption or authentication of user data. It is a Layer 2 security feature for mitigating man-in-the-middle attacks, not a TrustSec encryption component. It does not meet the stated encryption requirement.

Security Group Tag Exchange Protocol (SXP) with IPsec transport mode

Why it fails: SXP propagates Security Group Tags (SGTs) between network devices that cannot natively read SGTs, but it does not encrypt user traffic. Adding IPsec transport mode would encrypt at Layer 3, violating the requirement to avoid IPsec. SXP is a control-plane tagging mechanism, not a data-plane encryption solution.

permit tcp host 203.0.113.1 eq bgp host 198.51.100.1 and a second entry for the other provider, both with the established keyword.

Why it fails: The established keyword matches TCP segments with the ACK or RST flag set, which applies to return traffic or established sessions, not the initial inbound SYN from the peer. Placing established on the inbound WAN ACL would block the BGP peer's initial connection attempt. The established keyword is used on outbound ACLs to permit return traffic.

permit tcp any eq bgp host <local address> with a log keyword to record unexpected peers.

Why it fails: Permitting any source on port 179 keeps the overly broad exposure the team is trying to remove. Adding logging only records the events; it does not restrict access. The requirement is to allow only the two known provider addresses, so an any-source permit fails the policy objective.

permit tcp 203.0.113.0 0.0.0.255 eq bgp any and a second entry for the other provider's subnet.

Why it fails: Permitting an entire subnet and any destination is broader than necessary and does not pin the traffic to the local peering address. It also allows the provider subnet to reach any port on the router if additional entries exist. The precise peering tuple is required to satisfy the least-privilege requirement.