Syslog practice questions

The interface received a superior BPDU and became the root port.

Why wrong: STP role changes like becoming a root port occur when a superior BPDU is received, but that event would be reflected in spanning-tree state transitions and forwarding behavior, not in a security intrusion log. A hub does not originate BPDUs, and the error message clearly identifies a port-security violation rather than an STP topology change. Therefore, the interface's down state is due to security enforcement, not a spanning-tree decision.

The hub forced the interface to become a routed port.

Why wrong: A hub is a Layer 1 device that simply forwards electrical signals, so it cannot change the logical mode of a switch interface. A routed port is created only by explicitly removing Layer 2 switching with the "no switchport" command, which is not shown here. The log message references a port-security violation, not a change in interface mode.

DHCP snooping always shuts a port when a hub is attached.

Why wrong: DHCP snooping filters DHCP messages based on whether a port is trusted or untrusted; it does not count MAC addresses or react to the simple attachment of a hub. A hub only extends the collision domain, and it does not generate DHCP traffic or cause a DHCP snooping violation by itself. The exhibit shows a port-security restriction on secure MAC addresses, not any DHCP-related action.

logging trap debugging

Why wrong: Debugging is severity level 7, the lowest on the syslog scale, so 'logging trap debugging' causes every syslog message generated by the device to be sent, from level 0 emergencies through level 7 debugging. This is maximally inclusive and obviously exceeds the engineer's goal of only warning messages, because it forwards all debug output and every other severity class.

logging trap notifications

Why wrong: Notifications sit at severity level 5, which is one step less severe than warnings. When you configure 'logging trap notifications', the device sends levels 0 through 5—so it includes all warning and more severe messages plus the lower-severity notification messages. That adds an extra level of messages beyond the engineer's stated requirement, making the filter too broad rather than limiting the output to warnings only.

logging trap informational

Why wrong: The 'logging trap informational' command sets the trap filter to severity 6, which means the device will transmit all messages from level 0 through 6—including informational and all less severe messages. Because informational is two steps below warnings, this would forward far more messages than requested, including notifications and routine informational notices that the engineer does not want.

ntp server 198.51.100.10 source Loopback0 logging trap 4

Why wrong: This is incorrect because 'logging trap 5' uses the numeric severity level, but the question expects the keyword 'notifications' for severity 5. While both are technically valid, the question specifies 'severity 5 (notifications)', and the correct answer uses the keyword.

ntp server 198.51.100.10 logging trap notifications

Why wrong: This is incorrect because it omits the 'source Loopback0' parameter. Without specifying the source interface, the NTP client will use the outgoing interface IP, which may not be Loopback0, potentially causing reachability or authentication issues.

ntp server 203.0.113.5 source Loopback0 logging trap 7

Why wrong: This is incorrect because it uses the wrong NTP server address (203.0.113.5 instead of 198.51.100.10) and sets the logging trap level to debugging (7), which sends all messages instead of only notifications (5) and above.

Syslog is used to assign IP addresses dynamically to endpoints

Why wrong: Dynamic IP address assignment is performed by DHCP, which leases addresses from a configured pool and delivers client options like subnet mask and gateway, not by syslog. Syslog is purely an observability protocol used to forward log messages, and it has no mechanism or role in network address allocation, so this option incorrectly conflates a logging service with DHCP.

Syslog entries replace SNMP counters for interface statistics

Why wrong: Syslog is event-driven and reports discrete occurrences such as interface errors or configuration changes, while SNMP continuously tracks cumulative counters like bytes transmitted, packets dropped, and CRC errors from the MIB. These serve different purposes: SNMP provides quantitative traffic statistics for capacity planning and performance monitoring, whereas syslog delivers qualitative event notifications, so syslog cannot substitute for SNMP counters.

The logging trap level is set to informational, so only high-severity messages are sent with correct timestamps.

Why wrong: Setting the logging trap level to informational actually allows all messages of severity informational and higher (levels 0–6) to be sent. Even if only emergencies were sent, their timestamps would still be accurate if the router’s clock is correct.

The SNMP v3 user’s privacy password is incorrect, causing the NMS to reject syslog traps.

Why wrong: SNMP v3 authentication and privacy settings control SNMP traps, which are separate from syslog messages. Syslog uses UDP port 514 and does not depend on SNMP v3 credentials. An SNMP v3 misconfiguration would affect trap delivery, not syslog timestamps or NetFlow exports.

The IP flow cache timeout is set too low, causing NetFlow timestamps to appear skewed.

Why wrong: The flow cache timeout determines how long an active flow is kept in the cache before it is exported. A lower timeout exports flows more frequently but does not alter the actual start or end times recorded in the flow records. The timestamps in NetFlow records come from the system clock, not the cache timer.

NetFlow - Device management; SNMP - Flow analysis; Syslog - Performance measurement; IP SLA - Logging; SPAN - Remote traffic mirroring; RSPAN - Local traffic mirroring

Why wrong: It swaps the purposes of several technologies: NetFlow is not for device management, SNMP is not for flow analysis, Syslog is not for performance measurement, IP SLA is not for logging, SPAN is local not remote, and RSPAN is remote not local.

NetFlow - Logging; SNMP - Performance measurement; Syslog - Flow analysis; IP SLA - Device management; SPAN - Remote traffic mirroring; RSPAN - Local traffic mirroring

Why wrong: It misassigns each technology: NetFlow is not for logging, SNMP is not for performance measurement, Syslog is not for flow analysis, IP SLA is not for device management, SPAN is local not remote, and RSPAN is remote not local.

NetFlow - Performance measurement; SNMP - Logging; Syslog - Device management; IP SLA - Flow analysis; SPAN - Local traffic mirroring; RSPAN - Remote traffic mirroring

Why wrong: It misassigns several technologies: NetFlow is not for performance measurement, SNMP is not for logging, Syslog is not for device management, and IP SLA is not for flow analysis. However, SPAN and RSPAN are correctly matched.

SNMP

Why wrong: SNMP is a UDP-based protocol that manages network devices by reading and writing MIB objects, but it is fundamentally oriented toward monitoring and simple metric collection. Its SET operations lack transactional safety, configuration rollback, or standardized YANG data models, so it cannot reliably support the validation and rollback needed for automated closed-loop remediation. Thus, while SNMP can alert an AI agent to a fault, it is not the tool for applying structured configuration changes.

CLI scripting

Why wrong: CLI scripting, such as Expect or pexpect, automates network devices by sending text commands and parsing screen output, but it is brittle and platform-specific because it depends on exact command syntax and output formatting. It lacks machine-readable data models, structured RPC semantics, and transactional rollback, so any network change can fail silently or leave the device in an inconsistent state. Consequently, CLI scripting is not a robust or scalable mechanism for an AI-driven closed-loop remediation system.

Syslog

Why wrong: Syslog is a one-way logging protocol that transmits event messages from network devices to a collector; it cannot accept or execute configuration commands from a management system. It is useful for detecting faults and providing audit trails, but it does not provide any RPC mechanism for changing device state. Therefore, while syslog may feed data into a closed-loop detector, it is entirely incapable of carrying out automated remediation actions.

Syslog

Why wrong: Syslog is a logging protocol that transmits event messages and error notifications generated by network devices, such as configuration changes or interface flaps. Because it is push-based and asynchronous, it lacks the polling mechanism needed for routine metric collection and therefore does not suit a periodic monitoring platform.

NetFlow

Why wrong: NetFlow is designed to capture and export metadata about IP traffic flows, including source/destination addresses, ports, and protocol, to analyze network usage patterns. It does not provide general device health counters or periodic status polling, so it would be inappropriate for a monitoring platform focused on routine operational metrics.

Port security

Why wrong: Port security is a Layer 2 switch feature that restricts which MAC addresses can access a port to prevent unauthorized LAN access. It is a security enforcement mechanism, not a monitoring protocol or framework, and provides no facility for periodic collection of device statistics or health data.

The NTP server is using TCP instead of UDP for NTP communication.

Why wrong: NTP is a protocol that exclusively uses UDP port 123 for both client requests and server replies; it does not have a TCP implementation for standard time synchronization. If the server were somehow configured to use TCP, the router's NTP client would still send its requests via UDP and would simply receive no response, but this scenario does not occur in practice because TCP is only used for NTP-over-TCP tunneling or diagnostic utilities, not for production NTP. Therefore, a TCP/UDP mismatch is not a plausible explanation for the reachability failure shown by the reach counter.

The NTP server has a higher stratum level than the router's local clock, so the router ignores it.

Why wrong: A server with a higher stratum number (e.g., stratum 4) is considered less authoritative than the router's own local clock if the router is running as stratum 3, so the NTP selection algorithm would choose not to synchronize to that server. However, this stratum-based preference only affects which of multiple reachable servers is selected as the synchronization source; it does not affect the router's ability to exchange NTP packets with the server. The reach counter would still reflect successful NTP packet exchanges even if the server's stratum caused it to be rejected for sync, so a reach of 0 cannot be explained by stratum alone. In fact, the router would still receive and process NTP messages, just not use them for clock synchronization.

NTP authentication is misconfigured on the router.

Why wrong: NTP authentication is a security feature that uses MD5 or SHA1 keys to verify the authenticity of NTP messages, but the running-configuration on the router does not display an 'ntp authentication-key' or 'ntp trusted-key' statement, so authentication is not enabled on this device. Even if authentication were enabled, a mismatch of keys would cause the router to drop the NTP response immediately after receiving it, which would typically update the reach counter to a nonzero value or generate an authentication failure log, rather than keeping reach at zero. The absence of any authentication configuration and the complete lack of received packets point to a connectivity issue, not a key mismatch.

Syslog severity 7

Why wrong: Syslog severity 7 is a logging level used to indicate debug-level messages that are typically generated for troubleshooting and are not a notification mechanism. Syslog is a separate protocol from SNMP, used for system logging, and severity 7 messages are often verbose and not necessarily event-driven alerts. Even if a device sends syslog messages, this is not the SNMP trap mechanism, and the question specifically refers to the SNMP-based notification behavior.

DHCP relay

Why wrong: DHCP relay (ip helper-address) is a Layer 3 feature that forwards DHCP client broadcast requests to a DHCP server on another subnet, allowing clients to obtain IP configuration across network boundaries. It is entirely unrelated to SNMP and does not provide any event notification or alerting capability. A DHCP relay agent does not monitor device status or send unsolicited messages to a management station, so it cannot satisfy the requirement for an immediate device-triggered notification.

NetFlow exporters

Why wrong: NetFlow exporters are network devices configured to send flow records — metadata about traffic flows, such as source/destination IPs and port numbers — to a NetFlow collector for traffic analysis, capacity planning, or security forensics. These exports are periodic or based on flow expiration, not unsolicited event alerts from the device. Therefore, NetFlow is designed for visibility into traffic patterns rather than the immediate, event-driven notification that SNMP traps provide.

Another SSID

Why wrong: Another SSID is wrong because an SSID is simply the name of a wireless LAN and is used by clients to identify and connect to a particular wireless network. Creating a second SSID might segment wireless clients onto different VLANs or policies, but it does not produce flow-level data about traffic utilization. Since the monitoring gap is about traffic visibility, adding a network name does not address the need for flow analytics.

PortFast

Why wrong: PortFast is wrong because it is a Spanning Tree Protocol (STP) feature that allows a switch port to transition immediately from blocking to forwarding, bypassing the listening and learning states. Its purpose is to speed up convergence on ports connected to end devices, not to monitor or measure network traffic. PortFast has no ability to record flow information, so enabling it would not provide the traffic-usage details the monitoring system lacks.

A larger wildcard mask

Why wrong: A larger wildcard mask is wrong because wildcard masks are used by ACLs to define which packet headers match a permit or deny statement. Changing the wildcard mask only alters the range of IP addresses to which the ACL is applied; it does not generate traffic analytics or flow records. ACLs themselves are stateless filters, not monitoring tools, so expanding a wildcard mask has no effect on visibility into traffic usage.

Because NTP converts Syslog into a routing protocol

Why wrong: NTP is a time-synchronization protocol that exchanges timestamped timing packets over UDP 123; it carries no Syslog payload or routing information. Syslog remains a separate application-layer protocol over UDP 514, and routing protocols such as OSPF or EIGRP have their own update and neighbor mechanisms. Aligning device clocks cannot rewrite or convert one protocol into another, so this option fundamentally misstates NTP's function.

Because NTP automatically creates DHCP pools

Why wrong: DHCP pool creation is a manual configuration task performed on a DHCP server or a router running the DHCP service, involving address ranges, lease times, and options such as default gateway and DNS. NTP has no mechanism for, or interaction with, DHCP address allocation; it operates over UDP 123 and simply adjusts time on clients. Confusing NTP with DHCP pool generation confuses time synchronization with dynamic host configuration.

Because NTP eliminates the need for a Syslog server

Why wrong: A Syslog server is still required as the central collector, storage, and alerting engine for log messages, regardless of how accurate device clocks are. NTP only synchronizes clock time so every device agrees on Coordinated Universal Time; it does not gather, index, or store event messages. Removing the Syslog server would eliminate the central logging plane, leaving time-synchronized logs stranded on individual devices.

The device must run Syslog before NTP can sync

Why wrong: Syslog and NTP are entirely separate services: syslog forwards log messages to a collector, while NTP synchronizes wall-clock time. The switch will happily update its clock from an NTP server even if no syslog server is defined, and the absence of syslog configuration cannot stop the NTP process. Mixing these protocols to explain clock drift is a category error.

NTP requires a trunk port on the management VLAN

Why wrong: NTP is an application-layer protocol that rides on IP and UDP port 123; a trunk port is an Ethernet feature for multiplexing multiple VLANs onto a single link. The switch only needs an IP address in any VLAN that provides a route to the NTP server, whether that VLAN is untagged or trunked. If the clock is off, trunking is completely irrelevant to the failure.

The clock can sync only if DNS is configured

Why wrong: A switch can synchronize its clock to an NTP server using the server's numeric IP address, which requires no name resolution. DNS is only a convenience when the configuration references a hostname like 'time.example.com' instead of an IP. If the clock is off, the root cause must be reachability or synchronization of the NTP server, not a missing DNS record.

Because NTP assigns the Syslog server its IP address.

Why wrong: This is wrong because NTP does not provide IP addressing.

Because Syslog replaces authentication when NTP is present.

Why wrong: This is wrong because logging and time sync do not replace access control.

Because centralized logging blocks unauthorized traffic automatically.

Why wrong: This is wrong because logging improves visibility, not traffic enforcement.

Configure 'ntp server 203.0.113.10 source Loopback0' and 'logging trap warnings'.

Why wrong: This is incorrect because the 'ntp server' command does not support the 'source' keyword; the source interface is configured globally with 'ntp source'. Also, 'logging trap warnings' sets severity to 4, which filters out informational (severity 6) messages.

Configure 'ntp source Loopback0' and 'logging trap debugging'.

Why wrong: This is incorrect because 'logging trap debugging' sets severity to 7, which includes all messages (0-7). While this would include informational messages, it is overly broad and not the standard recommended level for informational and above; 'informational' (severity 6) is the correct trap level.

Configure 'ntp source Loopback0' and 'logging host 198.51.100.20' without changing the trap level.

Why wrong: This is incorrect because while the NTP source is correctly set, the syslog trap level is not changed. By default, the trap level is 'informational' (severity 6) on some IOS versions, but often it is 'warnings' (severity 4) or lower. The question implies the current configuration filters out informational messages, so the trap level must be explicitly set to 'informational'.

Configure 'ntp server 192.0.2.10' and 'logging trap 7'.

Why wrong: This is incorrect because 'ntp server 192.0.2.10' is already configured (implied by the scenario). The issue is the missing source interface, not the server command. 'logging trap 7' is not a valid command; the correct syntax is 'logging trap debugging' or 'logging trap 7' is not standard (though severity 7 is debugging, the keyword is preferred).

Configure 'ntp source Vlan100' and 'logging trap warnings'.

Why wrong: This is incorrect because 'logging trap warnings' sets the syslog trap level to warnings (severity 4), which filters out messages with severity lower than warnings (like notifications, informational, and debug). The NOC requires all messages up to debug level, so the trap level must be set to debugging.

Configure 'ntp update-calendar' and 'logging trap informational'.

Why wrong: This is incorrect because 'ntp update-calendar' updates the hardware calendar from NTP, but does not fix the source interface issue. 'logging trap informational' sets the trap level to informational (severity 6), which still excludes debug messages (severity 7).

It advertises Layer 3 reachability between routers

Why wrong: NTP is transported over IP, but it does not exchange routing information or build neighbor adjacency for Layer 3 reachability. Routing protocols — such as OSPF, EIGRP, and BGP — are responsible for discovering paths and populating the routing table, while NTP merely carries time-sync packets. Therefore, NTP cannot serve as a substitute for a routing protocol.

It encrypts data traffic between endpoints by default

Why wrong: NTP is strictly a time synchronization protocol, so it does not encrypt or protect data-plane traffic by default. Its messages carry time information, not user payloads, and any confidentiality on the wire is an optional enhancement such as NTP authentication, which only verifies packet integrity, not encrypt traffic. Encryption of endpoints is handled by separate protocols like IPsec, TLS, or SSH, not by NTP itself.

Syslog

Why wrong: This is wrong because Syslog focuses on event and message reporting.

DHCP

Why wrong: This is wrong because DHCP assigns host configuration and does not provide traffic-flow analysis.

PortFast

Why wrong: This is wrong because PortFast is an STP edge-port feature.