Network Basics: Follow a Packet and Diagnose a Connection

Network basics are the skills needed to explain how devices exchange data and to find where a connection fails. Start with links, switches, IP addresses, subnets, routers and DNS. Then follow a request from a client to a service, checking the evidence at each stage instead of changing settings at random.

This guide is for beginners, IT support learners and anyone preparing for networking study. You do not need to buy equipment to understand the example. A simulator or two isolated lab devices is enough to practise the addressing and troubleshooting steps.

What is a computer network?

A computer network connects devices so they can exchange information using agreed protocols. A laptop loading a website, a phone joining Wi-Fi and an application querying a database all depend on networking. A working connection requires more than a cable: both endpoints need compatible addressing, an available path, permitted traffic and a responding application.

A LAN connects devices within a local environment, such as an office. A WAN joins networks across larger distances. MAN describes metropolitan coverage; WLAN describes a wireless LAN. These terms describe scope or access method rather than a guarantee about speed or security. Wi-Fi and the internet are different things: a device can join Wi-Fi while its upstream internet connection is unavailable.

What do switches, routers and firewalls do?

Start with the job a component performs

Component	Main job	First useful check
Network interface	Connect the host to an Ethernet or wireless link.	Is it enabled and connected?
Switch	Forward Ethernet frames within a Layer 2 network; VLANs separate broadcast domains.	Is the port in the intended VLAN?
Router	Forward IP packets between networks using its routing information.	Is there a route to the destination?
Firewall	Apply rules and, depending on the product, inspect sessions or application traffic.	Which rule or session explains the result?
Wireless access point	Connect wireless clients to the network.	Is the client associated to the expected network?
Modem or access terminal	Adapt the connection to the provider access technology.	Does the provider-facing link have service?

The OSI model is a useful vocabulary for isolating a problem: physical links, frames, IP delivery, transport and application behavior. Real protocols do not always fit perfectly into one teaching diagram. Say what evidence you have: “the link is up” is more useful than “Layer 1 seems fine,” and neither proves that the web application is healthy.

IP address, subnet mask, gateway and MAC address

Consider a fictional lab client at 192.168.10.20/24, a gateway at 192.168.10.1, and a web server at 192.168.20.10. The /24 prefix places addresses 192.168.10.0–192.168.10.255 in the client's subnet; in this ordinary LAN example, the first is the network address and the last is the broadcast address. The server is in a different subnet, so the client sends its packet toward a router.

An IP address identifies an interface at the network layer. A MAC address is used for local Ethernet delivery. For this IPv4 example, ARP lets the client discover the local next hop's Ethernet address. The client looks for its gateway's MAC, not the remote server's MAC across the routed path. Routers build new link-layer frames for each outgoing link.

The private IPv4 ranges include 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Private addresses are not globally routed on the public internet. NAT often translates private IPv4 traffic at an edge, but NAT does not replace firewall policy. IPv6 uses 128-bit addresses and neighbor discovery rather than ARP; learning IPv4 is a starting point, not the whole addressing topic.

Follow a request from the client to the server

1. Resolve the name. The client asks its configured DNS service for the server name. A cached answer may avoid a new query. Record the returned address; a wrong DNS result can send traffic to the wrong place.
2. Choose the next hop. The host checks its routing information. Our example's remote subnet uses the gateway, while an on-subnet destination would normally be reached directly.
3. Deliver the frame. The host uses its local link and the switch forwards the frame toward the gateway. A VLAN mismatch can stop the journey before routing begins.
4. Route and filter. Routers forward toward the server network. Firewalls may permit or deny the requested protocol and destination port. The reply also needs a valid path.
5. Reach the service. For an HTTPS service using TCP, a transport connection and TLS exchange precede the application response. An open network path still cannot make a stopped or misconfigured application answer correctly.

DNS translates names; DHCP can provide host configuration; TCP provides a reliable byte stream; UDP carries datagrams without TCP's connection mechanism. Applications choose protocols for their needs. A port identifies a transport endpoint, not a physical switch socket. HTTP errors and certificate errors belong to different stages from a disconnected link.

A practical connection troubleshooting sequence

Begin with an explicit symptom: “this client cannot reach this URL at this time.” Note whether other clients or services work. Capture the expected address, protocol and port. On Windows, inspect ipconfig /all, route print and nslookup. On a Linux lab host, inspect ip address, ip route and an available DNS lookup tool. These commands inspect different parts of the problem; none is a complete health test.

Interpret observations before choosing a change

Observation	Investigate next	Avoid this assumption
No link or association	Cable, interface status, switch port or Wi-Fi association.	A DNS change can repair a missing physical link.
Wrong prefix or gateway	DHCP lease and the intended subnet plan.	Any address starting with 192.168 is compatible.
DNS gives an unexpected address	Resolver, record, cache and split DNS.	The application moved because one lookup differed.
Gateway responds; service times out	Destination route, filters, reply path and listener.	A successful gateway ping proves the full path.
HTTP 403 or 500 response	Application authorization or server logs.	Every failed web request is a network outage.

Ping uses ICMP and can be filtered independently of the application you are testing. Traceroute results can also omit routers or replies. Treat them as evidence, not a verdict. If the actual problem is HTTPS, test the intended service with an approved client and correlate timestamps with server or firewall logs.

Build one small lab and introduce one fault

Create two simulated LANs using the address plan above. First verify the client's address and gateway, then reach the router's local interface, then the server. Record a baseline containing the client settings, route, DNS answer and application result. Now give the client an unused, incorrect gateway in the same local subnet. Re-run the exact checks and explain why same-subnet communication can still work while remote communication fails.

Restore the gateway and repeat the original test. Next, change only a lab DNS record or client DNS setting. Observe how a name-based test can fail even when a permitted direct-address test still reaches the service. Do not bypass TLS verification to make an HTTPS test look successful: a certificate-name mismatch is meaningful evidence.

Questions beginners often ask

Should I learn network basics before CCNA?

Yes. Being comfortable with addresses, prefixes, devices and packet flow makes CCNA study easier to apply. You can develop those foundations while studying; an earlier certification is not the same as having the required understanding.

Can I practise without physical routers?

A simulator can support many foundational exercises. Confirm that it implements the protocol or feature being studied. Physical links, wireless behavior and hardware-specific troubleshooting eventually need suitable equipment or a realistic lab.

Your practical checklist

Use these checks here or download the matching checklist.

• Explain the difference between local networking, Wi-Fi and internet access.
• Record the client address, prefix, gateway and DNS server.
• Decide whether a destination is local or requires a router.
• Explain why the next-hop MAC differs from the remote server address.
• Follow DNS, routing, filtering and service response as separate checks.
• Record a working baseline before introducing one lab fault.
• Restore the setting and repeat the same test.
• Write the symptom, evidence, cause, change and verified result.

Choose your next learning step

Continue with the CCNA syllabus and lab checklist, practise basic OSPF, or explore the Network Engineer Master Program and networking labs.

Book a career guidance callback to discuss your starting skills, or compare current learning plans and fees. Confirm the syllabus, lab access and enrolment details on the chosen program page.

Sources and editorial note

• IETF: ARP for Ethernet address resolution
• IETF: private IPv4 address allocation
• Cisco: CCNA certification and foundational scope

Technical references checked on 18 October 2026. By Network Kings. Prepared with AI assistance; no independent technical review recorded. Worked scenarios are illustrative learning exercises, not a claim of completed target-platform testing or learner outcomes.