Network Operations practice questions

Change the management IP address

Why it fails: Changing the management IP address before a firmware upgrade is an unnecessary action that introduces additional risk and complexity without any benefit to the upgrade process. The upgrade itself does not require a modification of network addressing. Altering the IP could lead to temporary loss of access to the device, making it difficult to monitor the upgrade progress or recover if issues arise, thereby complicating an already critical procedure.

Disable all physical interfaces

Why it fails: Manually disabling all physical interfaces on a critical core router prior to a firmware upgrade is counterproductive and would cause an immediate, unnecessary network outage. While a firmware upgrade often involves a reboot and temporary traffic interruption, the device itself manages this process. Disabling interfaces beforehand would only prolong the downtime and disrupt services prematurely, without offering any technical advantage to the upgrade procedure.

Remove the old firmware image

Why it fails: Deleting the old firmware image prior to a successful upgrade and thorough validation of the new firmware is a significant operational risk. The old firmware serves as a crucial fallback option; if the new firmware proves unstable, incompatible, or introduces critical bugs, the administrator can quickly revert to the previous, known-good version. Retaining the old image provides a rapid recovery path, preventing extended network disruption and ensuring business continuity.

Notify all users of a scheduled outage

Why it fails: Notifying all users of a scheduled outage is a vital communication step, but it must follow the confirmation of a validated change plan and a precise schedule. Communicating an outage before the firmware update has been thoroughly tested and approved could lead to unnecessary alarm, erode user trust if the plan changes, or result in false alarms. Effective notification relies on having a firm understanding of the change's impact and timeline, which is informed by prior testing and planning.

Create a detailed rollback plan

Why it fails: Creating a detailed rollback plan is an essential risk mitigation strategy, outlining the steps to revert to a previous stable state if the update fails. However, the most effective rollback plans are informed by the potential failure modes and issues discovered during lab testing. Developing a comprehensive rollback strategy without understanding the specific challenges or potential complications revealed through testing makes the plan less precise, less effective, and potentially slower to execute when needed most.

Schedule the update during a maintenance window

Why it fails: Scheduling the update during a maintenance window is a logistical step that occurs much later in the change management process, after the technical feasibility and impact of the change have been thoroughly validated. Without prior testing in a controlled lab environment, scheduling an update for a critical core switch is premature and irresponsible, as the potential for unknown issues could lead to extended, unscheduled downtime, far exceeding any planned maintenance window and severely disrupting network operations.

Virtual IP (VRRP/HSRP)

Why it fails: Incorrect. VRRP/HSRP provide first-hop gateway redundancy for routers, not for server NIC failover. They operate at Layer 3 and would require the server to act as a router, which is not the intended use.

Spanning Tree Protocol (STP)

Why it fails: Incorrect. STP prevents loops in a switched network but does not provide load balancing or server failover.

Port mirroring

Why it fails: Incorrect. Port mirroring duplicates traffic for monitoring purposes and does not offer any failover or load balancing capability.

Save the running configuration to the startup configuration.

Why it fails: Saving the running configuration to the startup configuration (e.g., `copy running-config startup-config`) overwrites the persistent configuration that loads upon reboot. This action does not create a separate, independent backup for rollback purposes; rather, it commits the *current* state, which might already include unintended changes or be the state *just before* the new policy is applied. If the new policy fails and the router reboots, it would load the potentially problematic configuration, making recovery more difficult than with an external backup.

Test the QoS policy in a lab environment.

Why it fails: While testing a new QoS policy in a dedicated lab environment is a highly recommended best practice for validating its functionality and impact without affecting production, it is not the *absolute first* step before touching a live core router. The question asks what should be done *first* before implementing, implying immediate preparation for the production change. A lab test, while valuable, might not always be feasible or available, and even after successful lab testing, a production backup remains paramount for unforeseen real-world variables.

Schedule a maintenance window and notify the help desk.

Why it fails: Scheduling a maintenance window and notifying the help desk and affected stakeholders are crucial administrative and communication steps for any significant network change. These actions ensure proper coordination and minimize user impact by setting expectations. However, from a technical preparedness standpoint, these steps should follow the creation of a robust configuration backup. Without a reliable backup, even a well-communicated maintenance window lacks the fundamental technical safety net required for a swift recovery if the implementation encounters critical issues.

90

Why it fails: An Administrative Distance of 90 is the default for internal Enhanced Interior Gateway Routing Protocol (EIGRP) routes. EIGRP is a Cisco proprietary advanced distance-vector protocol known for its rapid convergence and efficient use of bandwidth. Its low AD of 90 reflects its high trustworthiness and preference within a Cisco-centric network, indicating that routes learned via EIGRP are generally considered superior to those from OSPF or RIP.

100

Why it fails: The value 100 represents the default Administrative Distance for Interior Gateway Routing Protocol (IGRP), a legacy Cisco proprietary distance-vector routing protocol. IGRP was an older protocol designed to overcome some limitations of RIP in larger networks but has since been superseded by EIGRP. This AD is not associated with OSPF, which is an open-standard link-state protocol, and IGRP is rarely encountered in modern network deployments.

120

Why it fails: A default Administrative Distance of 120 is assigned to routes learned via the Routing Information Protocol (RIP). RIP is an older, simpler distance-vector protocol that uses hop count as its primary metric. Its relatively high AD of 120 reflects its slower convergence times, potential for routing loops, and limited scalability compared to more advanced protocols like OSPF or EIGRP, making it less preferred in complex network environments.

3 (error)

Why it fails: Choosing a trap level of 3, corresponding to "error," would be insufficient for the administrator's requirement to include warning messages. This setting only captures log messages with severity levels from 0 (emergency) through 3 (error). Consequently, any events classified as "warning" (severity level 4) would be filtered out and not recorded, potentially causing the administrator to miss important pre-failure indicators or non-critical but noteworthy operational issues.

5 (notice)

Why it fails: Selecting a trap level of 5, which represents "notice," would result in capturing more log messages than strictly necessary. While it includes warning messages, it also encompasses less severe informational messages like "notice" (severity 5) and potentially "informational" (severity 6), depending on the specific implementation. This increased verbosity can lead to larger log files, make it harder to identify critical events, and consume more storage and processing resources than required for the stated objective.

7 (debug)

Why it fails: A trap level of 7, corresponding to "debug," is an excessively verbose setting that captures all possible log messages, including the least critical debug-level events. While it certainly includes warning messages, it also floods the log system with highly detailed, often transient, and typically irrelevant information for day-to-day operational monitoring. This extreme verbosity makes it very difficult to parse meaningful warnings or errors, consuming significant resources and obscuring important events amidst a deluge of data.

FTP

Why it fails: File Transfer Protocol (FTP) is a robust protocol designed for interactive file transfers, requiring a full control connection and a separate data connection for each transfer. Its reliance on explicit user authentication, session management, and directory navigation introduces significant overhead, making it less efficient for automated, bulk firmware updates to numerous network devices. This complexity is often unnecessary for a simple, script-driven file push in a controlled environment.

HTTP

Why it fails: Hypertext Transfer Protocol (HTTP) is primarily used for serving web content and user interfaces, and while it can technically transfer files, it is not as commonly implemented for firmware updates in network devices as TFTP. Implementing a full HTTP client and server stack on resource-constrained embedded devices for a single task like firmware updates introduces unnecessary complexity and overhead compared to the purpose-built simplicity of TFTP. Device manufacturers often prioritize the minimal resource footprint and directness of TFTP for this specific maintenance function.

SNMP

Why it fails: Simple Network Management Protocol (SNMP) is fundamentally designed for monitoring and managing network devices, allowing administrators to query device status, receive alerts, and modify configuration parameters via Management Information Bases (MIBs). However, SNMP does not include a native mechanism for transferring large binary files, such as firmware images, directly. While SNMP can be used to trigger a firmware update process or report its status, it cannot perform the actual file transfer itself.

Running configuration

Why it fails: The "show running-config" command displays the current active configuration settings loaded into the switch's volatile memory, encompassing interface parameters, VLAN assignments, and various protocol configurations. While essential for understanding how the switch is configured to operate, this command does not provide real-time operational data such as the dynamically learned MAC addresses present in the forwarding database. Therefore, it cannot fulfill the request to report learned MAC addresses, as it shows static configuration rather than dynamic operational state.

IP interface configuration

Why it fails: The "show ip interface" command provides detailed information about the Layer 3 (IP) configuration and operational status of interfaces on a switch or router. This includes parameters such as assigned IP addresses, subnet masks, interface status (up/down), and protocol status, focusing exclusively on network layer addressing and connectivity. This command offers no insight into the Layer 2 MAC addresses that have been learned by the switching fabric, making it irrelevant for reporting MAC address learning.

VLAN configuration

Why it fails: The "show vlan" command displays a summary of all configured Virtual Local Area Networks (VLANs) on the switch, including their names, status, and the specific ports assigned to each VLAN. While crucial for understanding the Layer 2 segmentation and port membership within the switch, this command does not list the individual MAC addresses that have been dynamically learned by the switch within those VLANs or on those ports. It describes the VLAN structure and port assignments, not the dynamic host presence or MAC address learning details.

Configure a load balancer in front of multiple servers

Why it fails: A load balancer distributes traffic across multiple back-end servers, so it cannot keep one server's IP reachable when that server has only a single NIC and no second host to fail over to. It is tempting because load balancers do provide high availability, but they require multiple servers behind a virtual IP.

Use VRRP to create a virtual IP address

Why it fails: VRRP is used for router redundancy, not server NIC redundancy. It allows a backup router to take over a virtual IP if the primary router fails, but does not protect against a server NIC failure.

Use DNS round robin

Why it fails: DNS round robin distributes traffic across multiple IPs, but it does not provide automatic failover; if the server's NIC fails, clients may still attempt to reach the unresponsive IP.

Implement QoS policies to prioritize traffic.

Why it fails: Implementing Quality of Service (QoS) policies aims to prioritize specific types of network traffic, such as voice or video, over less critical data to ensure performance. However, configuring QoS without first understanding the current bandwidth utilization and traffic patterns is inefficient and could misallocate resources. A baseline analysis is crucial to identify which applications genuinely require prioritization and to design effective QoS rules that optimize network performance rather than arbitrarily shaping traffic.

Upgrade the switch to a higher capacity model.

Why it fails: Upgrading a core switch to a higher capacity model without first assessing current utilization and traffic patterns is a premature and potentially wasteful action. Without understanding existing bandwidth demands, peak loads, and specific bottlenecks, an upgrade might not address the actual problem or could result in an unnecessary expenditure. Proper network management dictates that hardware changes should be data-driven, ensuring that investments align with actual performance needs and justify the cost.

Enable SNMP traps for link down events.

Why it fails: Enabling SNMP traps for link down events is a valuable proactive measure for network fault management, immediately alerting administrators to critical connectivity issues. However, this action focuses solely on detecting failures and does not provide any insight into the historical or current bandwidth utilization levels. SNMP traps are reactive to specific events, whereas evaluating bandwidth utilization requires continuous data collection and analysis of performance metrics over time for effective capacity planning.

Strip the cable jacket, Trim wires to length, Untwist and arrange wires in T568B order, Insert wires into RJ45 connector, Crimp the connector, Test the cable

Why it fails: Trimming the wires to length before untwisting and arranging them in the T568B standard is fundamentally incorrect. This premature trimming makes it exceedingly difficult to properly untwist the twisted pairs and align them precisely in the correct color code sequence. The result is often uneven wire lengths within the connector, leading to unreliable contact with the RJ45 pins and potential signal transmission errors.

Strip the cable jacket, Untwist and arrange wires in T568B order, Insert wires into RJ45 connector, Trim wires to length, Crimp the connector, Test the cable

Why it fails: Inserting the wires into the RJ45 connector before trimming them to the appropriate length is an impractical and ineffective step. The individual conductors must be trimmed to a uniform length, typically around 0.5 inches (12.7 mm), to ensure they reach the end of the connector and make proper contact with the internal pins. Attempting to trim wires after insertion would be impossible to do evenly and accurately, resulting in poor electrical connections and a failed termination.

Untwist and arrange wires in T568B order, Strip the cable jacket, Trim wires to length, Insert wires into RJ45 connector, Crimp the connector, Test the cable

Why it fails: Attempting to untwist and arrange the wires in T568B order before stripping the cable jacket is physically impossible and an incorrect initial step. The protective outer jacket encases all the twisted pairs, preventing access to the individual conductors required for proper untwisting and color-coding. The cable jacket must be removed first to expose the internal wires, making this sequence illogical and unachievable.

ping: Resolves domain names to IP addresses.

Why it fails: This statement is incorrect because the `ping` command's primary function is to test network connectivity using ICMP echo requests, not to perform domain name resolution. While `ping` can accept a domain name as an argument, it relies on the operating system's configured DNS client to resolve that name to an IP address *before* sending any ICMP packets. The actual resolution process is handled by services like DNS, which tools such as `nslookup` directly query.

traceroute: Tests connectivity by sending ICMP echo requests.

Why it fails: This statement is incorrect because, while `traceroute` does utilize ICMP messages (specifically Time Exceeded messages) to map network paths, its core mechanism is distinct from simply testing connectivity. The primary function of sending ICMP echo requests to verify host reachability is performed by the `ping` command. `Traceroute` focuses on revealing the sequence of intermediate routers, not just the end-to-end reachability.

SET

Why it fails: The SET operation is used by an SNMP manager to modify the value of a managed object on an SNMP agent, effectively configuring or controlling the device remotely. This command allows for changes to device parameters, such as enabling or disabling an interface, or adjusting a routing metric. It is a write operation, distinctly different from reading data for monitoring purposes, and requires appropriate write permissions.

TRAP

Why it fails: An SNMP TRAP is an unsolicited notification sent by an SNMP agent to the manager when a significant event occurs on the device, such as a link going down or an authentication failure. Unlike a GET request, a TRAP is not initiated by the manager seeking information; instead, it's an asynchronous alert from the agent. Its purpose is to inform the manager of critical, often urgent, situations without the manager having to constantly poll the device.

INFORM

Why it fails: An SNMP INFORM is a manager-to-manager or agent-to-manager notification that, unlike a TRAP, requires an explicit acknowledgment from the receiving manager. This acknowledgment mechanism makes INFORM messages more reliable for critical event notifications where delivery assurance is paramount. While still an agent-initiated notification of an event, rather than a manager-initiated data retrieval, its guaranteed delivery makes it suitable for high-priority alerts that cannot be missed.

TFTP

Why it fails: TFTP, or Trivial File Transfer Protocol, is a lightweight protocol known for its simplicity and lack of security features, including authentication and encryption. It operates over UDP and is primarily used for transferring small files in scenarios where security is not a concern, such as booting diskless workstations or initial firmware updates. Consequently, using TFTP for automated network device configuration backups would expose critical device settings to significant security risks, as data could be easily intercepted or altered.

FTP

Why it fails: FTP, or File Transfer Protocol, transmits both control commands and data in cleartext, meaning all information, including usernames, passwords, and the configuration files themselves, is sent unencrypted over the network. This inherent lack of encryption makes FTP highly susceptible to eavesdropping and man-in-the-middle attacks, compromising the confidentiality and integrity of network device configurations. Therefore, relying on FTP for automated backups of sensitive network settings is a significant security vulnerability that should be avoided.

HTTP

Why it fails: HTTP is fundamentally an unencrypted application layer protocol designed for retrieving web pages and resources, not for secure, programmatic file transfers like configuration backups. It transmits data in cleartext, making any sensitive information, including device configurations, vulnerable to interception and exposure. While HTTP/S (secure HTTP) adds encryption, the protocol itself lacks the robust file transfer capabilities and authentication mechanisms typically required for automated network device management.

SNMP GET

Why it fails: SNMP GET is a polling mechanism where the Network Management System (NMS) actively requests the current value of a specific Management Information Base (MIB) object, identified by its Object Identifier (OID), from an SNMP agent. For continuous monitoring of a dynamic metric like CPU usage, the NMS would need to issue frequent GET requests. This constant polling generates significant network overhead and increases the processing load on both the NMS and the monitored device, making it inefficient for real-time event notification.

SNMP GETNEXT

Why it fails: SNMP GETNEXT is designed to retrieve the next lexicographical MIB object after a specified OID, enabling sequential traversal of MIB tables or lists. While it can retrieve multiple related values, it remains a polling operation initiated by the NMS. Using GETNEXT repeatedly to monitor a single, specific event like a CPU threshold being exceeded is inefficient, as it's not optimized for event-driven alerts and would still contribute to unnecessary network traffic and agent processing overhead.

SNMP WALK

Why it fails: SNMP WALK is an extended series of GETNEXT requests that systematically retrieves all MIB objects within an entire subtree. This operation is typically used for initial device discovery, inventory collection, or comprehensive configuration backups, as it pulls a large volume of data. Repeatedly performing an SNMP WALK for continuous monitoring of a single metric, such as CPU usage, would be extremely resource-intensive, generating excessive network traffic and placing an undue burden on the network and the device's SNMP agent.

SLA

Why it fails: A Service Level Agreement (SLA) is a contractual document that defines the guaranteed level of service a provider commits to, including metrics like uptime, response times, and resolution times. While crucial for establishing operational expectations and potential penalties for non-compliance, an SLA does not detail the technical procedures, risk assessments, or step-by-step instructions required to execute a firmware upgrade on a network device. Its purpose is performance assurance, not operational methodology.

Network diagram

Why it fails: A network diagram visually represents the physical and logical topology of a network, illustrating device placements, interconnections, IP addressing schemes, and sometimes VLANs or routing protocols. While essential for understanding the scope of devices affected by an upgrade and identifying potential dependencies or impact areas, a network diagram does not contain the procedural steps, risk assessments, or rollback plans necessary to guide the actual firmware upgrade process. It describes "what" is there, not "how" to change it.

Baseline performance report

Why it fails: A baseline performance report establishes a snapshot of a network device's normal operational metrics, such as CPU utilization, memory usage, interface bandwidth, and error rates, under typical load. This report is invaluable for post-upgrade validation, allowing administrators to compare current performance against the known good state to identify any negative impacts or improvements. However, it provides no instructions or methodology for the actual process of upgrading firmware.

Use SNMP traps to alert on each latency spike

Why it fails: SNMP traps are asynchronous notifications sent by a network device to a management station when a specific event or threshold is met, such as a critical interface going down or a high CPU utilization. While useful for immediate alerts on latency *spikes* (if configured), traps are event-driven and do not provide the continuous, granular data collection necessary for building a historical record of latency trends. They signal an occurrence, rather than systematically logging ongoing performance metrics.

Run a continuous ping test and manually log timestamps

Why it fails: A continuous ping test measures the round-trip time to a single destination, providing real-time latency data. However, manually logging timestamps and results is highly inefficient, prone to human error, and not scalable for monitoring critical network infrastructure. This method lacks the automation, data storage, and reporting capabilities required for effective historical trend analysis and proactive management of network performance.

Use traceroute to identify each hop and measure latency per hop

Why it fails: Traceroute (or `tracert`) is a diagnostic tool that maps the path a packet takes to a destination, showing each router (hop) and the round-trip time to each hop. While useful for identifying specific points of high latency or path changes at a given moment, it provides only a snapshot. It is not designed for continuous, automated, historical data collection across an entire network for trend analysis, nor does it typically integrate into network monitoring systems for long-term storage and reporting.

B) Perform an SNMP walk of the interface OIDs

Why it fails: Performing an SNMP walk of interface OIDs is incorrect because an SNMP walk is a polling operation initiated by the NMS to retrieve a sequence of variables within a specified branch of the Management Information Base (MIB) tree. While it can gather comprehensive interface status data, it is a pull-based method that only discovers an interface down event during its next scheduled execution. This does not provide the immediate, real-time alerts required for critical infrastructure monitoring.

C) Use SNMP get to retrieve interface status periodically

Why it fails: Using SNMP get to retrieve interface status periodically is incorrect because SNMP get is a polling operation where the NMS explicitly requests the value of a specific managed object from a device. While repeated 'get' requests could eventually detect an interface failure, this method is inefficient for immediate alerts. It generates continuous network traffic and places a significant processing burden on both the NMS and the monitored device, without guaranteeing instant notification of critical events.

D) Configure SNMP set to change interface parameters

Why it fails: Configuring SNMP set is incorrect because this operation is used by the Network Management System (NMS) to actively modify or write configuration parameters on a managed network device. For instance, an SNMP set command could be used to administratively shut down an interface or change its IP address. It is a command for configuration changes, not a mechanism for the device to autonomously send alerts about its operational status to the NMS.

B) Network diagram

Why it fails: A network diagram documents topology and addressing; it is not an approval artefact for a change. A change request records the proposed modification, risk, rollback and authorisation. The diagram would be the right reference where the task is understanding device interconnections before designing the change.

C) Incident report

Why it fails: An incident report documents a past outage and its resolution, so it cannot authorise a planned change. The required document is a change request submitted for approval. An incident report would be correct where the task is recording root cause and remediation after an unplanned event.

D) Backup configuration

Why it fails: A backup configuration preserves the switch's prior state for rollback; it is not a change-control artefact requiring approval. The stem asks for the document prepared and approved before the change, which is a change request or method-of-procedure record. Backup configuration is tempting because it is genuinely part of change preparation, but it documents recovery, not intent.

SNMP

Why it fails: Simple Network Management Protocol (SNMP) is primarily used for monitoring and managing network devices by polling for operational statistics and receiving event notifications (traps). While it can report on interface utilization, CPU load, and memory status, SNMP does not capture or export the granular, session-level details of individual traffic flows between endpoints. It focuses on device health and performance metrics rather than the specifics of network conversations.

ICMP

Why it fails: Internet Control Message Protocol (ICMP) operates at the network layer and is fundamental for reporting errors and performing diagnostic functions within an IP network. Common uses include ping for host reachability testing and traceroute for path discovery, where it conveys messages about network conditions or unreachable destinations. ICMP does not collect, aggregate, or export detailed information about ongoing traffic flows or conversations between endpoints.

LLDP

Why it fails: Link Layer Discovery Protocol (LLDP) is a vendor-neutral Layer 2 protocol used by network devices to advertise their identity, capabilities, and port information to directly connected neighbors. Its primary function is to facilitate network topology discovery and management, allowing devices to learn about their immediate connections and their configuration. LLDP is not designed to monitor or export IP traffic flow data, focusing instead on physical and logical link characteristics.