Network Operations

What this unit covers

The topics below follow the published Networking course framework for Unit 4. Networking publishes no per-unit weighting, so there is no percentage to chase here.

Lessons in this unit

• Monitoring, Baselines, and Documentation18 min · 3 objectivesExplain observable and supportable network operations · Apply the idea to evidence from a realistic technology scenario · Justify a decision using security, reliability, cost, and user impact
• A Structured Troubleshooting Method18 min · 3 objectivesExplain hypothesis-driven fault isolation · Apply the idea to evidence from a realistic technology scenario · Justify a decision using security, reliability, cost, and user impact
• Change, Capacity, and Continuity18 min · 3 objectivesExplain safe network change and operational resilience · Apply the idea to evidence from a realistic technology scenario · Justify a decision using security, reliability, cost, and user impact

Every term in Unit 4

All 40 terms we publish for Network Operations, with definitions. Reading them through is the fastest way to find the ones you cannot define — then drill those in cram mode until you can produce them without the prompt.

Network baseline

A record of normal utilization, latency and error rates. "Slow" is not measurable until a baseline exists, and neither is "back to normal".

Network monitoring

Continuously collecting availability and performance data so problems are noticed before users report them.

SNMP polling vs traps

Polling asks devices for status on a schedule; a trap is the device volunteering that something happened. Polling has predictable load, traps have lower latency.

NetFlow and flow data

Records of who talked to whom, how much and for how long — without the packet contents. Enough to find the top talker and the unexpected destination.

Packet capture

Recording actual traffic for analysis. The most detailed tool and the most expensive to store, so it is targeted rather than continuous.

Alert threshold

The level at which monitoring raises an alarm. Too tight and alert fatigue sets in; too loose and outages are discovered by users.

Structured troubleshooting method

Identify the problem, establish a theory, test it, plan and implement a fix, verify, then document. The steps exist so that guessing does not replace testing.

Identify the problem

Gather symptoms, ask what changed, and determine scope — one user, one segment, or everyone. Scope alone eliminates most theories.

Establish and test a theory

Form one explanation, test it, and if it fails form the next rather than changing several things at once. Changing several things means learning nothing from the result.

Verify and document

Confirm full functionality with the user, and record cause and fix. Undocumented fixes get rediscovered from scratch by the next person.

Top-down vs bottom-up troubleshooting

Start at the application and work down, or start at the cable and work up. Bottom-up suits physical symptoms; top-down suits "this one site does not load".

Divide and conquer

Test at a middle layer to eliminate half the stack at once. Pinging the gateway settles layers 1 to 3 in a single step.

ping

Sends ICMP echo requests to test reachability and round-trip time. A failed ping is not proof of failure — many hosts and firewalls drop ICMP by policy.

traceroute / tracert

Shows the path to a destination hop by hop, revealing where latency appears or the path stops. Middle hops that do not reply are common and not necessarily a fault.

ipconfig / ifconfig / ip

Displays and refreshes local addressing. First command when a client cannot reach anything — a 169.254 address diagnoses the problem immediately.

nslookup / dig

Queries DNS directly, separating a name-resolution failure from a connectivity failure. If the address resolves but does not answer, DNS is not the problem.

netstat / ss

Lists active connections and listening ports on the local host. Reveals what a machine is actually talking to.

arp

Shows the local address-to-MAC table. Two IP addresses sharing one MAC is a sign worth investigating.

Cable tester and toner probe

A tester verifies continuity and wiring order; a toner traces which cable in a bundle is which. The physical-layer tools that stop the guessing.

Loopback plug

Loops a port's transmit back to its receive to test the port itself independently of the cable and the far end.

Common physical faults

Damaged cables, wrong cable category, exceeded distance limits, bad connectors and dirty fiber. All produce errors and retransmission rather than a clean failure.

Duplex mismatch

One end at full duplex, the other at half. The link works and performs terribly with rising error counters — a slow-network complaint, not an outage.

IP address conflict

Two hosts assigned the same address, usually a static address inside a DHCP pool. Intermittent connectivity for both.

Rogue DHCP server

An unauthorized server handing out incorrect addressing. Clients get wrong gateways or DNS and appear randomly broken.

Network documentation

Diagrams, address plans, VLAN assignments, device inventory and configuration backups. The difference between a two-hour outage and a two-day one.

Physical vs logical diagram

A physical diagram shows cabling and rack locations; a logical diagram shows addressing, VLANs and traffic flow. Both are needed and they answer different questions.

IP address management (IPAM)

Tracking which addresses and subnets are allocated to what. Prevents conflicts and makes an unknown device on the network noticeable.

Configuration backup

Saved device configurations, so a failed switch is replaced by restoring a file rather than reconstructing it from memory.

Change control

A process for proposing, approving, scheduling and documenting changes. Most unplanned outages follow a planned change nobody recorded.

Maintenance window

A scheduled period for disruptive work, agreed in advance. Turns an outage into an appointment.

Rollback plan

The documented way to undo a change if it fails, prepared before the change starts. Deciding how to reverse it during the outage is too late.

Service level agreement (SLA)

A commitment about availability or response time, usually with consequences. Defines what "working" contractually means.

Uptime and the nines

Availability stated as a percentage: 99.9% allows about 8.8 hours of downtime a year, 99.99% about 53 minutes. Each nine costs considerably more than the last.

Mean time between failures and mean time to repair

How long a component typically lasts, and how long restoring it takes. Availability improves by raising the first or lowering the second.

Capacity planning

Using trend data to add capacity before saturation rather than after complaints. What baselines and monitoring are ultimately for.

Asset and lifecycle management

Tracking what hardware exists, its warranty and its end of support. Unsupported infrastructure is both an availability and a security problem.

Remote access for administration

SSH and VPN rather than exposing management interfaces to the internet. Management planes are the highest-value target on any network.

Out-of-band management

A separate path to manage devices that works when the production network does not. The reason a misconfigured firewall does not require a site visit.

Escalation

Handing an issue to a higher tier with the evidence already gathered. Escalating without the symptoms, scope and steps already tried simply restarts the work.

Post-incident review

Examining what happened and why after service is restored. The step that turns one outage into prevention rather than into a repeat.

What examiners penalize here

• For a scenario about **observable and supportable network operations**, identify the decisive evidence before naming a response. A defensible conclusion here is: Convert the vague symptom into measured scope, then compare evidence across the path.
• For a scenario about **hypothesis-driven fault isolation**, identify the decisive evidence before naming a response. A defensible conclusion here is: The narrow scope makes a building-wide router failure unlikely; test the local path first.
• For a scenario about **safe network change and operational resilience**, identify the decisive evidence before naming a response. A defensible conclusion here is: A technically valid update is still a poor operational change when timing, validation, and recovery are missing.

Practice Networking

Our practice bank is drawn from across the whole course rather than filtered to one unit, which is closer to how the exam asks anyway — it will not tell you which unit a question is testing.

Questions about this unit

All 5 units of AP Networking

1. Unit 1 · Network Foundations
2. Unit 2 · Network Infrastructure
3. Unit 3 · Network Services
4. Unit 4 · Network Operations
5. Unit 5 · Network Security