Snapshot
Snapshot
A point-in-time storage or VM state used for short-term rollback depending on the platform.
In everyday business: It can quickly undo a bad change, but it is not automatically an independent backup.
BASELINING
Network Baselines and Interface Counter Playbook
Learn what normal looks like before a fault occurs, then use counter deltas instead of one unexplained snapshot.
Book 1 | Chapter 9
Chapter opening
Chapter 9 moves from the course overview into network baselines and interface counter. The aim is not to memorise product menus or commands. The reader should understand what problem the technology solves, how it fits into the wider networking technical textbook, what normal operation looks like, and how to prove the result in the field.
The previous chapter introduced snmp, syslog, ntp and network monitoring playbook. This chapter continues the sequence by focusing on network baselines and interface counter playbook, so the reader can connect the architecture to a more specific operational problem.
Learning objectives
- Explain the main purpose of Network Baselines and Interface Counter in plain language.
- Identify the components that must work together for the service to operate.
- Use evidence to separate a design problem from a configuration or physical fault.
- Describe the business impact of a failure and the evidence required for handover.
Why this matters in a real company
Monitoring gives IT evidence before and during a fault. Instead of waiting for staff to report that the network is slow, counters and logs can show when the problem started and where it is developing.
Course: Networking Technical Textbook
PLAIN ENGLISH
Technical terms used in this chapter
You do not need to memorise the jargon first. Understand what each term does and why somebody running a company would care about it.
Latency
Latency
The delay before an operation or packet completes.
In everyday business: Users experience high latency as slowness even when headline bandwidth looks good.
PoE
Power over Ethernet
Technology that sends DC power and Ethernet data over the same twisted-pair cable.
In everyday business: A camera or access point can be installed with one network cable instead of a separate power outlet.
BUSINESS TRANSLATION
What this means outside the server room
This topic affects how reliably staff and systems can communicate. Good network design reduces downtime, makes faults easier to find and keeps departments or services separated where required.
Backup
What it means: A backup is an independent recoverable copy of data or system state.
In normal business language: Think of it as having a duplicate of important company records stored safely away from the live filing cabinet.
Why the decision matters: A backup only counts if it can be restored. Test recovery, not just backup completion.
Snapshot
What it means: A snapshot is a point-in-time state of a storage volume or VM on the same platform.
In normal business language: It is like a quick undo point inside the same office. Very useful for rolling back a mistake, but not enough if the whole storage system is lost.
Why the decision matters: Use snapshots for fast rollback, but keep independent backups for real disaster recovery.
PoE
What it means: Power over Ethernet sends both data and electrical power over the same Ethernet cable.
In normal business language: A camera or access point can use one cable instead of separate network and power wiring.
Why the decision matters: PoE can simplify installation and UPS protection, but the switch power budget and cable quality still need to be designed.
Latency
What it means: Latency is the delay before a network or storage operation completes.
In normal business language: It is the difference between a cashier serving you immediately and making you wait even though the shop is not full.
Why the decision matters: Low latency often matters more to user experience than headline bandwidth.
WiFi
What it means: WiFi is shared radio networking, so all clients in the same radio environment compete for airtime.
In normal business language: It is more like a meeting room where people take turns speaking than a dedicated cable for every person.
Why the decision matters: Good WiFi design focuses on capacity, interference and client behaviour, not only whether a signal bar appears.
9.1 A counter is meaningful only in context
Ten CRC errors accumulated over three years is different from ten new CRC errors every minute. Record the value, wait during normal or failing traffic, then measure the change.
Useful baseline data
- Interface utilisation.
- CRC/FCS and input errors.
- Discards/drops.
- Link flaps.
- Negotiated speed/duplex.
- PoE draw.
- CPU and memory.
- WAN latency/loss.
- WiFi channel utilisation and retries.
Cisco-style checks
show interfaces counters
show interfaces counters errors
show interfaces <port>
show logging
Before and after
Capture counters before a cable swap or configuration change, then again after the same test traffic. That makes the change measurable.
Busy-hour baseline
A 02:00 graph is not a useful baseline for a problem that occurs every weekday at 10:00. Record the network under the load that actually matters.
Client benefit
Baselines shorten troubleshooting because the technician can compare current behaviour with known healthy operation rather than generic guesses.
9.2 Error categories
CRC/FCS, runts, giants, alignment errors and discards point to different fault classes depending on platform. Read the vendor definition of each counter before drawing a conclusion.
Utilisation percent can hide microbursts
A five-minute average may show a link at 20 percent even when short bursts fill buffers and cause drops. Where applications experience brief latency spikes, look for queue/drop telemetry and shorter-interval data.
Baseline after every major change
After a WAN upgrade, switch replacement, WiFi redesign or storage migration, establish a new healthy baseline. Old thresholds may no longer describe normal operation.
9.3 Link speed baseline
Record expected negotiated speed for critical ports. A server or AP that silently drops from 1 Gb/s or higher to a lower speed may still be reachable but create a capacity problem.
Duplex
Modern Ethernet normally uses autonegotiation, but legacy/manual settings can create mismatches. On platforms that expose duplex and collision/error counters, verify both ends when performance is unexpectedly poor.
Optical baseline
For critical fibre links with supported DOM, record transmit and receive power per optic at commissioning. Compare later readings only against the exact optic specification and historical baseline.
PoE baseline
Record normal power draw for critical APs, cameras and phones where the switch exposes it. A device that suddenly requests or consumes different power can indicate a configuration, accessory or hardware change.
Counter reset caution
Clearing counters can make troubleshooting easier, but first save the existing values. Otherwise you destroy historical evidence that may show whether errors started before the current incident.
WORKED BUSINESS SCENARIO
Scenario: users complain about five-minute outages
The network looks healthy whenever IT checks it, but staff report short dropouts several times a week.
What the chapter teaches us: Live status is not enough. Historical counters, logs, timestamps and baselines are what let the technician reconstruct a short incident after it has ended.
Think it through
- Which events should be sent off-device?
- Why must device clocks agree?
- What does a counter delta tell you that a single counter value cannot?
PRACTICAL WORK
Hands-on lab
Collect one hour of interface utilisation, errors and device logs from a lab switch. Mark a controlled cable disconnect and confirm the timestamp appears in both monitoring and syslog.
Troubleshooting exercise
Users report brief outages but the interface is currently up. Compare link-flap logs, error-counter deltas and monitoring history around the reported times.
Chapter field checklist
- I can explain the subject without relying only on acronyms.
- I can draw or describe the main traffic, storage, power or service path.
- I know what normal operation should look like.
- I know which logs, counters or test results prove the result.
- I can explain the business impact if this component fails.
- I would document the final configuration and evidence at handover.
Chapter summary
Network Baselines and Interface Counter Playbook should now be understood as a business service with a technical implementation, not simply a collection of commands or product names. The important habit is to know the purpose, understand the dependencies, measure the result and document what was proven.
END OF CHAPTER
Review questions
- Explain the subject in plain language to a business owner.
- List the main dependencies that must be healthy before this service can work.
- Describe one realistic failure and the first three pieces of evidence you would collect.
- Explain what should be documented at handover.
A good answer should explain the reason, not only repeat a product name or command.
Technical references
Use the current project specification and the exact product documentation for the installed equipment. These references support the technical principles used in this guide.