Networking

What makes a network feel fast or slow comes down to queues filling at bottleneck links. This page builds the queueing models that explain latency, then turns to defending the network (firewalls, VPNs, ACLs), prioritizing traffic with quality of service, and the tools and metrics for troubleshooting and monitoring.

How this page is organized. It covers two intertwined but distinct concerns:

These are the network-layer primitives. Higher-level defense — threat models, zero trust, detection engineering, and incident response — lives in Cybersecurity. Observability data feeds directly into those workflows, and the Network Observability section below shows the hand-off into Security Operations.

Understanding Network Performance

When network engineers talk about performance, they’re often dealing with queues—just like lines at a coffee shop.

Why Networks Need Queues

Imagine a router as a busy intersection. Packets arrive from multiple sources, but the router can only forward them one at a time. When packets arrive faster than they can be processed, they must wait in a queue. This waiting time directly impacts your experience—it’s why video calls sometimes freeze or web pages load slowly.

This real-world problem motivates queueing theory. By modeling network devices as queuing systems, we can predict and optimize performance.

Modeling Network Queues

The Python models below are illustrative — small M/M/1 and queueing-network models that make the formulas concrete.

import numpy as np
import matplotlib.pyplot as plt
from scipy import stats

class NetworkQueue:
    """Model a network device (like a router) as a queue to predict performance.
    
    This M/M/1 model helps us understand:
    - How long packets wait in router buffers
    - When a network link becomes congested
    - How to size buffers appropriately
    """
    def __init__(self, arrival_rate, service_rate):
        self.lambda_ = arrival_rate  # λ
        self.mu = service_rate       # μ
        self.rho = arrival_rate / service_rate  # ρ = λ/μ
        
        if self.rho >= 1:
            raise ValueError("System is unstable (ρ >= 1)")
    
    def average_customers(self):
        """L = ρ / (1 - ρ)"""
        return self.rho / (1 - self.rho)
    
    def average_queue_length(self):
        """Lq = ρ² / (1 - ρ)"""
        return self.rho**2 / (1 - self.rho)
    
    def average_waiting_time(self):
        """W = 1 / (μ - λ)"""
        return 1 / (self.mu - self.lambda_)
    
    def average_queue_time(self):
        """Wq = ρ / (μ - λ)"""
        return self.rho / (self.mu - self.lambda_)
    
    def response_time_distribution(self, t):
        """P(T ≤ t) = 1 - e^(-(μ-λ)t)"""
        return 1 - np.exp(-(self.mu - self.lambda_) * t)
    
    def simulate(self, duration=1000):
        """Discrete event simulation"""
        events = []
        current_time = 0
        customers_in_system = 0
        
        while current_time < duration:
            # Next arrival
            inter_arrival = np.random.exponential(1/self.lambda_)
            arrival_time = current_time + inter_arrival
            
            # Service time
            service_time = np.random.exponential(1/self.mu)
            
            events.append({
                'time': arrival_time,
                'type': 'arrival',
                'service_time': service_time
            })
            
            current_time = arrival_time
            
        return events

# Example: Analyzing a home router handling video streaming
# Your router receives 800 packets/second during Netflix streaming
# It can forward 1000 packets/second to your device
router = NetworkQueue(arrival_rate=800, service_rate=1000)
print(f"Average packets waiting: {router.average_queue_length():.2f}")
print(f"Average delay added: {router.average_queue_time()*1000:.2f} ms")

# This 4ms delay might not seem like much, but it adds up across multiple hops!

When Single Queues Aren’t Enough

Real networks have multiple devices, each adding its own delays. To understand end-to-end performance, we need to model networks of queues. This is particularly important for cloud applications where data might traverse dozens of devices.

class MultiHopNetwork:
    """Model traffic flow through multiple network devices.
    
    Use this to analyze:
    - Cloud application latency (web server → load balancer → app server → database)
    - Content delivery networks
    - Multi-datacenter architectures
    """
    def __init__(self, num_nodes):
        self.num_nodes = num_nodes
        self.routing_matrix = np.zeros((num_nodes, num_nodes))
        self.external_arrivals = np.zeros(num_nodes)
        self.service_rates = np.zeros(num_nodes)
        
    def set_routing(self, from_node, to_node, probability):
        """Set routing probability between nodes"""
        self.routing_matrix[from_node, to_node] = probability
        
    def solve_traffic_equations(self):
        """Solve λᵢ = γᵢ + Σⱼ λⱼ * Pⱼᵢ"""
        # Form system: (I - P^T)λ = γ
        I = np.eye(self.num_nodes)
        A = I - self.routing_matrix.T
        
        # Solve for arrival rates at each node
        arrival_rates = np.linalg.solve(A, self.external_arrivals)
        
        return arrival_rates
    
    def analyze_performance(self):
        """Analyze performance metrics for each node"""
        arrival_rates = self.solve_traffic_equations()
        metrics = []
        
        for i in range(self.num_nodes):
            if arrival_rates[i] < self.service_rates[i]:
                queue = NetworkQueue(arrival_rates[i], self.service_rates[i])
                metrics.append({
                    'node': i,
                    'utilization': queue.rho,
                    'avg_delay': queue.average_waiting_time(),
                    'avg_queue': queue.average_customers()
                })
            else:
                metrics.append({
                    'node': i,
                    'utilization': float('inf'),
                    'avg_delay': float('inf'),
                    'avg_queue': float('inf')
                })
                
        return metrics

Congestion control (TCP Reno and BBR, in Transport & Application Protocols) exists precisely to keep these queues from filling up and overflowing.

Securing Networks: Defense in Depth

This section and Network Observability cover the network-defense primitives; the performance/QoS material is in the other sections.

Every network connection is a potential security risk. Let’s explore how networks are protected at multiple layers. These primitives — firewalls, VPNs, and ACLs — operate on the data plane itself; they are the enforcement points that the policies in Cybersecurity ultimately push down to.

Firewalls: The Network’s Bouncer

Firewalls examine traffic and block anything suspicious, like a bouncer checking IDs at a club.

Types:

  • Packet filtering
  • Stateful inspection
  • Application layer
  • Next-generation (NGFW)

VPN (Virtual Private Network)

Creates encrypted tunnels.

Types:

  • Site-to-site
  • Remote access
  • SSL/TLS VPN
  • IPSec

Access Control Lists (ACLs)

Define permitted/denied traffic.

# Cisco ACL example
access-list 100 permit tcp any host 192.168.1.10 eq 80
access-list 100 deny ip any any

For threat models, zero-trust, and attack techniques, see Cybersecurity.

Quality of Service: Managing Network Traffic

Not all traffic is equal. Would you rather have your video call drop or your background download slow down? QoS lets networks make these decisions intelligently.

How QoS Works

  • Classification and marking
  • Queuing
  • Policing and shaping
  • Congestion avoidance

Common QoS Models:

  • Best Effort
  • IntServ (Integrated Services)
  • DiffServ (Differentiated Services)

Troubleshooting Networks: Tools and Techniques

When networks fail, you need to diagnose problems quickly. Here are the essential tools every network engineer uses.

Essential Diagnostic Tools

ping: Test connectivity

ping -c 4 google.com

traceroute: Show path to destination

traceroute google.com

netstat: Display connections

netstat -tulpn

tcpdump: Capture packets

tcpdump -i eth0 -w capture.pcap

nmap: Network discovery

nmap -sS -p 1-1000 192.168.1.0/24

dig: DNS lookup

dig @8.8.8.8 example.com

Systematic Troubleshooting

When things don’t work, follow the OSI model from bottom to top:

Layer 1 - Physical: Is it plugged in?

  • Check cable connections
  • Look for damaged cables
  • Verify link lights on switches

Layer 2 - Data Link: Can you reach local devices?

  • Ping your default gateway
  • Check ARP cache (arp -a)
  • Verify VLAN configuration

Layer 3 - Network: Can you reach remote networks?

  • Ping external IPs (8.8.8.8)
  • Traceroute to see where packets stop
  • Check routing table (ip route)

Layer 4+ - Transport/Application: Are services working?

  • Test specific ports with telnet/nc
  • Check firewall rules
  • Verify DNS resolution
  • Look at application logs

Slow Performance:

  1. Check bandwidth utilization
  2. Look for packet loss
  3. Measure latency
  4. Check for duplex mismatch
  5. Verify MTU settings

Network Observability

Observability is the difference between knowing a link is slow and knowing why. A well-instrumented network produces three complementary streams of data — packets (the raw ground truth), flows (who talked to whom, and how much), and metrics/telemetry (counters and gauges sampled over time) — plus the logs devices emit about their own state. Each operates at a different granularity and cost, and mature operations correlate all of them. This data serves performance work (capacity planning, latency hunting) and network defense (anomaly detection, forensics), which is why observability sits on the boundary between the two halves of this page.

Data source Granularity Typical volume Primary uses
Packet capture (pcap) Every byte on the wire Very high Deep troubleshooting, forensics, intrusion analysis
Flow records (NetFlow/IPFIX/sFlow) Per-conversation summaries Moderate Traffic analysis, anomaly detection, capacity planning, billing
Metrics/telemetry (SNMP, gNMI) Per-interface counters/gauges Low Dashboards, alerting, trend analysis
Logs (syslog, flow logs, audit) Per-event records Moderate–high Audit trails, security investigation, change correlation

Packet Capture Workflows

Packet capture is the ground truth — it records the actual bytes, so it answers questions that aggregated data cannot (which TLS handshake failed, why a retransmission storm started, what an attacker exfiltrated). Because the volume is enormous, the practical workflow is capture narrowly, store briefly, analyze offline.

Capture with a BPF filter so you keep only what matters:

# Capture only HTTP/HTTPS to one host, rotate files at 100 MB, keep 10 files
tcpdump -i eth0 -G 0 -C 100 -W 10 -w cap_%Y%m%d_%H%M%S.pcap \
  'host 192.168.1.10 and (tcp port 80 or tcp port 443)'

# Snap length 96 bytes: capture headers only, not payloads (privacy + size)
tcpdump -i eth0 -s 96 -w headers.pcap

Analyze the capture offline (so the capture host stays light):

# Top talkers by bytes
tshark -r cap.pcap -q -z conv,ip

# Just the TCP retransmissions — a fast pointer at loss/congestion
tshark -r cap.pcap -Y 'tcp.analysis.retransmission' \
  -T fields -e frame.time -e ip.src -e ip.dst

# Reconstruct the bytes of TCP stream 0
tshark -r cap.pcap -q -z follow,tcp,raw,0

Operational notes:

  • Tap vs. SPAN. A passive optical/network TAP copies every frame without loss; a switch SPAN/mirror port is cheaper but drops frames under load and can reorder them. Use a TAP when the capture must be authoritative (security forensics, compliance).
  • Privacy and scope. Full payload capture often contains credentials and personal data. Use snap-length limits, capture only header fields where possible, and treat pcap as sensitive. See Privacy Engineering.
  • Continuous capture appliances (e.g. ring-buffer “network recorders”) keep a rolling N hours of full packets so that when an alert fires you can retrieve the packets around the event — packet capture is most valuable retrospectively.

Flow Telemetry: NetFlow, IPFIX & sFlow

Capturing every packet everywhere is infeasible, so routers and switches export flow records — one summary row per conversation (5-tuple of src/dst IP, src/dst port, protocol) with byte/packet counts and timestamps. Flow data is the workhorse of network visibility: small enough to keep for months, detailed enough to spot a scan, a DDoS ramp, or a top talker.

  • NetFlow / IPFIX (Cisco’s NetFlow v9 was standardized as IPFIX, RFC 7011) export every flow the device sees. Records are aggregated in the device’s flow cache and exported when the flow ends or a timer expires.
  • sFlow instead samples 1-in-N packets and streams interface counters. Sampling makes it cheap and constant-cost at line rate, at the price of statistical (rather than exact) byte counts — fine for trends and anomaly detection, less so for billing.
                 +-------------------+
   packets  -->  |  Router / Switch  |  flow cache (5-tuple + counters)
                 +---------+---------+
                           | export (UDP) NetFlow v9 / IPFIX / sFlow
                           v
                 +-------------------+      +---------------------+
                 |  Flow Collector   | ---> |  Analysis / SIEM /  |
                 | (nfcapd, etc.)    |      |  capacity dashboards|
                 +-------------------+      +---------------------+

# Collect NetFlow v5/v9/IPFIX with nfdump's collector on UDP/2055
nfcapd -w -D -p 2055 -l /var/flows

# Top 10 talkers by bytes from collected flows
nfdump -R /var/flows -s ip/bytes -n 10

# Flows to an unusual port — a quick exfiltration/scan check
nfdump -R /var/flows 'dst port 4444 or dst port 6667'

Use cases (the same data, two audiences):

  • Performance: capacity planning, identifying top talkers, validating QoS classification, peering/transit cost analysis (billing on 95th-percentile).
  • Security: detecting port scans (many dst ports, few bytes each), beaconing (regular small flows to one host), DDoS (sudden fan-in), and data exfiltration (large egress to an unfamiliar destination).

Metrics & Streaming Telemetry

Metrics are sampled numeric counters and gauges — interface octets, errors, discards, CPU, queue depth — that drive dashboards and alerts.

  • SNMP (Simple Network Management Protocol) is the long-standing pull model: a Manager polls Agents on each device, walking a MIB (Management Information Base) tree of OIDs. It is universally supported but poll-based (typically 60–300 s intervals), so it misses microbursts, and SNMP v3 (authenticated + encrypted) should be used in place of the community-string-only v1/v2c.

    SNMP components:

    • Manager: the monitoring/polling system
    • Agent: software on the managed device that answers queries
    • MIB: the schema of OIDs the agent exposes
    # Poll an interface's inbound octet counter (SNMPv3, authPriv)
snmpget -v3 -l authPriv -u monitor -a SHA -A "$AUTHPASS" \
  -x AES -X "$PRIVPASS" 192.168.1.1 IF-MIB::ifInOctets.2

  • Streaming telemetry (gNMI/gRPC, NETCONF/YANG) is the modern push model: the device streams state changes and high-frequency samples (sub-second) to a collector, instead of waiting to be polled. This catches microbursts and scales to large fabrics far better than SNMP polling. Collectors such as Telegraf normalize SNMP, gNMI, and flow data into a time-series database (Prometheus, InfluxDB) visualized in Grafana.

   Devices  --(SNMP poll / gNMI stream)-->  Telegraf  -->  TSDB (Prometheus/Influx)  -->  Grafana

Core Network Performance Metrics

These are the headline numbers every dashboard tracks and every alert thresholds on:

  • Bandwidth: maximum data rate a link can carry
  • Throughput: actual achieved data rate
  • Utilization: throughput as a fraction of bandwidth (the input to the queueing models above — recall delay explodes as utilization ρ approaches 1)
  • Latency: one-way or round-trip delay
  • Jitter: variation in latency (critical for voice/video)
  • Packet loss: fraction of packets dropped
  • Interface errors/discards: CRC errors, drops, and discards that point at physical or buffer problems

Logs, Retention & Cost

Devices also emit logs — syslog from routers/firewalls, flow logs from cloud VPCs, audit logs from management planes. Logs answer “what changed and when”, which is essential for correlating a performance regression or a security event with a config push.

Every observability stream forces a retention vs. cost decision, because volume and value diverge over time:

Stream Typical hot retention Typical cold/archive Rationale
Full packet capture Hours to a few days Rarely archived (huge) Only needed around an active incident
Flow records Weeks to months Months–years (compressed) Cheap enough to keep for trend + forensic lookback
Metrics Days at full resolution Months–years, downsampled Old data only needs trend resolution, not per-second
Logs Days–weeks hot/searchable Months–years (compliance) Audit/forensics + regulatory mandates

Practical patterns:

  • Tiered storage: keep recent data hot and searchable; roll older data to cheap object storage (e.g. S3) with lifecycle rules.
  • Downsampling/roll-ups: store metrics at 10 s for a week, 1 min for a month, 1 h for a year — preserving trends without the volume.
  • Compliance-driven minimums: many frameworks mandate retaining security-relevant logs for a fixed period (commonly 90 days hot, one year archived); see Compliance & Governance.
  • Sampling and aggregation at the source (sFlow sampling, flow-cache timeouts) is the cheapest way to control volume before it ever reaches storage.

Integration with Security Operations

Network observability is not just for performance engineers — it is a primary sensor for the security operations center (SOC). The hand-off looks like this:

   pcap / flows / metrics / logs
              |
              v
   +----------------------+        +-------------------------+
   |  Collectors / TSDB   |  --->  |  SIEM (correlation,     |
   |  + flow analyzers    |        |  alerting, retention)   |
   +----------------------+        +-----------+-------------+
                                               |
                            detections, threat hunting, IR
                                               v
                                   Security Operations workflows
  • Flow records feed network-detection-and-response: a SIEM correlates a beaconing pattern in flows with a suspicious DNS log and a firewall deny to raise one high-fidelity alert instead of three weak ones.
  • Packet capture is the forensic backstop — when an alert fires, analysts pull the packets around the event to confirm scope and extract indicators.
  • Metrics and logs provide the timeline: a CPU spike, a config change, and an unusual egress flow line up to tell the story.

This is exactly the data pipeline that detection engineering and incident response consume. For how this telemetry is turned into detections, triaged, and acted on, see Security Operations, Operations & Response, and Incident Response. For the threat models that decide what to look for, see Attacks & Defense.

Best Practices

Network Design

  • Follow hierarchical model (core, distribution, access)
  • Implement redundancy
  • Use standard protocols
  • Document everything
  • Plan for growth

Security

  • Implement defense in depth
  • Use strong encryption
  • Regular security audits
  • Keep firmware updated
  • Monitor for anomalies

Performance

  • Optimize routing paths
  • Implement QoS appropriately
  • Monitor utilization
  • Use caching where possible
  • Regular capacity planning

Continue

Previous: Routing & Switching — the paths whose performance we measure here.  Next: Modern & Future Networking — programmable, cloud, and research-frontier networks.

See Also