The InfrastructureHolocronReturn to index ←

Archive 02 · Layers 2–4

Network
Paths

Connectivity is not a yes-or-no condition. A working service depends on a complete forward path, a complete return path, and every policy and dependency between them.

SwitchingRoutingDNSQoSPackets
01EndpointAddress · Route · DNS
02AccessPort · VLAN · PoE
03NetworkRoute · ACL · QoS
04ServiceTransport · TLS · App
RETURN PATH MUST ALSO BE PROVEN ←
Engineering perspectiveFrom cable to packet

Full-path troubleshooting

The network is not the space
between two systems.

It is the system connecting them. Christian’s networking work spans IP planning, VLAN and network-region changes, port and firewall analysis, packet capture, secure signaling, QoS, and real-time voice troubleshooting across complex enterprise environments.

That work begins with a simple discipline: identify every hop, state what should happen there, and collect evidence that it did.

Diagnostic sequence

Prove the path in layers

“The network is up” is not a test result. Each layer has a different question, a different source of evidence, and a different owner.

  1. 01

    Identity

    IP address, prefix, gateway, DNS, lease, and network region.

  2. 02

    Local path

    NIC state, ARP, access port, VLAN membership, trunking, and switch counters.

  3. 03

    Routed path

    Next hop, route selection, NAT, ACLs, firewalls, and asymmetric return paths.

  4. 04

    Transport

    TCP handshake, UDP reachability, resets, retransmissions, fragmentation, and MTU.

  5. 05

    Trust

    Name resolution, time, certificates, TLS negotiation, and cipher compatibility.

  6. 06

    Application

    Protocol behavior, server response, dependencies, media flow, and recovery.

Packet evidence

Ask a narrow question.
Build a narrow filter.

A capture is useful only when tied to a timeline, endpoints, expected behavior, and a testable question. Start broad enough to preserve context; filter copies during analysis instead of destroying the original evidence.

arp or icmp

Prove local resolution and basic reachability.

dns

Confirm the question, response, address, delay, and failure code.

tcp.flags.syn == 1

Find connection attempts and determine whether the peer answers.

tcp.analysis.retransmission

Expose loss, delay, or an unacknowledged path.

tls.handshake

Inspect certificate exchange and negotiation failures.

sip or rtp

Separate call signaling from the media streams users actually hear.

Real-time traffic

Voice exposes the network

File transfers can recover quietly. A conversation cannot. Delay, variation, loss, policy, and path selection become immediately human.

How long a packet takes to travel

Latency

Delay becomes conversational friction even when every packet arrives.

Variation in arrival time

Jitter

Real-time media needs a predictable flow; buffers can absorb only so much variation.

Packets that never arrive

Loss

Small bursts can damage audio long before ordinary data applications appear broken.

Traffic classification

DSCP

Marking identifies intent. Queuing, trust boundaries, and congestion determine whether it helps.

Control plane

Signaling

SIP, H.323, TLS, registration, call setup, feature negotiation, and teardown.

Media plane

RTP

Separate UDP streams with their own addresses, ports, codecs, direction, and quality.

Sanitized field patterns

Symptoms become test plans

The goal is not to collect commands. It is to turn an imprecise complaint into a sequence of questions that can be proven or eliminated.

Pattern 01

Endpoint will not register

Prove addressing, DHCP options, file retrieval, signaling reachability, and the server response before changing the endpoint.

Pattern 02

TLS connection fails

Verify DNS and time first, then inspect the certificate chain, names, validity, trust, and negotiated protocol.

Pattern 03

One-way or no audio

Map both RTP directions, advertised media addresses, NAT, firewall policy, codec agreement, and network-region selection.

Network doctrine

Observe both directions

Document the source, destination, time, protocol, expected response, and actual response. If the forward path works, prove the return path. If the transport works, prove the application.

Return to all archives →