1 Network Services Foundations and Lab Setup

How network services work together

A client needs network configuration to communicate: an IP address, a subnet mask or prefix, a default gateway, and often DNS resolver addresses. DHCP can provide these settings automatically. For IPv4, DHCP uses UDP ports 67 and 68. Clients on the same subnet can discover a DHCP server by broadcast; a router or relay is needed to pass DHCP requests between subnets.

The subnet mask helps a client decide whether a destination is local. For a local destination, the client uses ARP to find the next-hop Ethernet address. For a remote destination, it sends the packet to its configured default gateway. The router consults its routing table to choose a path.

NAT may translate addresses at the network boundary, and many-to-one NAT may translate ports as well. NAT is distinct from both routing and a firewall.

DNS clients query a resolver to translate names into resource records, commonly an IP address. DNS does not choose the route to that address. DNS commonly uses UDP and also supports TCP on port 53. NTP synchronizes device clocks, typically using UDP port 123; accurate time makes logs and event sequences easier to compare.

Design an isolated virtual lab

A virtual lab lets you practice network services in a small network you control rather than changing settings on a home or workplace network. Use a hypervisor such as VirtualBox or another platform that supports private virtual networks.

A basic arrangement has a client VM and a service VM on an isolated LAN, with a router/firewall VM connecting that LAN to an optional WAN. The WAN can connect to hypervisor NAT when internet access is wanted; the service VM can provide DHCP, DNS, and NTP.

Choose an internal or host-only virtual network. Internal networking keeps VM traffic within that virtual network. Host-only networking can also let the host communicate with the VMs. Avoid bridged networking for initial service experiments because it connects a VM to the physical LAN.

Configure the lab network

Choose a private IPv4 subnet that does not overlap with existing networks. One example is 192.168.50.0/24; private IPv4 ranges are defined in RFC 1918.

Give the router VM two interfaces: a WAN interface connected to hypervisor NAT, if internet access is needed, and a LAN interface on the isolated lab network. Configure routing and, if needed, outbound NAT on the router. Do not assume that the hypervisor's NAT adapter routes between your lab subnets.

Assign stable addresses to the router's LAN interface and the service VM. Configure one DHCP server for the lab subnet and use an address pool that does not overlap with stable or reserved addresses. If testing your own DHCP server, disable any hypervisor DHCP service on that same network to avoid competing offers.

Configure the DHCP scope to offer the correct subnet, default gateway, and DNS resolver. Then configure DNS and NTP on the service VM, or use explicitly selected upstream services if the lab has internet access. Keep the lab isolated, use test systems, and avoid exposing experimental services to the public internet. A second subnet can be added later to test routing, DHCP relay, or policies between networks.

Test and troubleshoot in order

Start on a client VM by checking its assigned address, subnet, gateway, and DNS resolver with the operating system's network-configuration tools. Test each part in sequence:

• Addressing: Check that the client has an address in the intended subnet and that it is outside reserved or static addresses.

• Local reachability: Test whether the client can reach the router's LAN address. If not, check interface state, subnet mask, duplicate addresses, and local filtering. On IPv4 Ethernet, ARP resolves a local next-hop address.

• Routing and NAT: If internet access is intended, test whether the client can reach a known remote IP address. If local traffic works but remote traffic does not, check the client's default route, router forwarding, NAT, and firewall rules.

• DNS: Test whether the client can resolve a name, and compare a name lookup with a connection to a known IP. If IP connectivity works but names fail, investigate the configured resolver and DNS service.

• Time: Check whether the client is synchronized and whether it can reach its configured NTP server.

• QoS: Generate competing traffic between lab systems and observe queueing, delay, loss, or throughput with and without a policy. Without congestion or competing traffic, a QoS policy may have no visible effect.

Change one setting at a time and record the result. This makes it easier to identify which service or network layer caused a failure.

Understand traffic policies

QoS policies classify and handle traffic through measures such as marking, shaping, policing, or assigning forwarding priority. They can manage delay, jitter, loss, or bandwidth when resources are constrained. Simply marking packets does not guarantee better service end to end, and a policy may have no visible effect without congestion or competing traffic.