1 Introduction
A Local Area Network (LAN) provides a confined environment in which multiple devices com-
municate and share resources through switched Ethernet connections. This laboratory exercise
models a small office LAN comprising a managed switch, dedicated service hosts (DNS and
HTTP servers), and client devices (desktop PCs and a laptop). The experiment demonstrates
fundamental concepts of Layer 2 switching, static IPv4 addressing, basic service deployment,
and client–server interactions. Emphasis is placed on configuring device interfaces, verifying
connectivity with ICMP and application-layer requests, and applying systematic troubleshoot-
ing techniques to resolve common connectivity and service-access issues. The scope of the
report includes device configuration steps, verification procedures, observed results, and rec-
ommendations for improving network reliability and service availability.
2 Objectives
• Understand LAN architecture: Examine switched Ethernet topology and Layer 2
forwarding behavior.
• Configure IP addressing: Assign static IPv4 addresses, verify subnetting, and confirm
end-to-end connectivity.
• Deploy and validate services: Configure DNS and HTTP services on dedicated servers
and test client access.
• Perform diagnostics and troubleshooting: Use ICMP and application-layer tests to
identify and resolve common connectivity and service issues.
3 Tools and Apparatus
The following tools and apparatus were used to design, configure, and test the local area network
in this laboratory exercise.
• Simulation software: Cisco Packet Tracer — used to model the network topology,
configure devices, and simulate traffic and services.
• Network switch: Cisco Catalyst 2960 (simulated) — central Layer 2 switching device
for connecting servers and client hosts.
• End devices (simulated): Desktop PCs (PC0, PC1) and Laptop (Laptop0) — used as
clients to generate traffic and test service access.
• Server hosts (simulated): DNS server and HTTP servers — provide name resolution
and web services for client testing.
• Cabling: Ethernet straight-through cables — connect end devices and servers to the
switch for standard host-to-switch links.
• Configuration interface: CLI/GUI within Packet Tracer — used to assign static IPv4
addresses, configure services, and run diagnostic commands.
• Diagnostic tools: ping, nslookup, and web browser (HTTP requests) — used to verify
connectivity, name resolution, and service availability.
1
• Documentation tools: Text editor and LaTeX environment — used to record configu-
ration steps, capture results, and prepare the laboratory report.
4 Theory
A switched Ethernet LAN connects hosts through a Layer 2 device that forwards frames based
on MAC addresses. When a frame arrives on a switch port, the switch records the source
MAC and associated port in its MAC address table and forwards frames destined for a known
MAC only to the corresponding port; unknown destinations are flooded to all ports in the same
broadcast domain. This learning and forwarding behavior minimizes unnecessary traffic and
enables efficient local communication between hosts.
Address Resolution Protocol (ARP) provides the mapping between IPv4 addresses and MAC
addresses within a subnet. When a host needs to send an IP packet to a local destination, it
issues an ARP request to discover the target’s MAC address; the resolved MAC is cached for
subsequent transmissions. Static IPv4 addressing assigns fixed addresses to devices, simplifying
service discovery and access in small networks but requiring careful management to avoid
address conflicts.
DNS (Domain Name System) translates human-readable hostnames into IP addresses, en-
abling clients to locate services without memorizing numeric addresses. In a small LAN, a local
DNS server can resolve internal names and forward external queries, improving usability and
reducing manual configuration on clients. Proper DNS configuration is essential for reliable
application-layer access when services are referenced by name.
HTTP is an application-layer protocol used for retrieving web resources from HTTP servers.
Clients initiate TCP connections to the server’s IP and port (typically port 80 for HTTP) and
exchange request and response messages; successful HTTP transactions confirm both transport-
layer connectivity and correct server configuration. Hosting multiple HTTP services on distinct
servers in the same LAN demonstrates basic client–server interactions and service isolation.
ICMP-based tools such as ping and name-resolution utilities like nslookup are fundamental
for network diagnostics. ping verifies basic IP-level reachability and round-trip latency, while
nslookup checks DNS resolution paths and server responses. Systematic use of these tools, com-
bined with inspection of switch MAC tables and ARP caches, supports efficient troubleshooting
of connectivity and service-access issues in a switched LAN environment.
5 Figures Flowchart and Diagrams
5.1 Network Topology and Connections
The network is organized as a single switched LAN where all end devices connect to a central
switching fabric. Service hosts (DNS and HTTP servers) and client devices (desktop PCs and
a laptop) are attached to the switch using Ethernet links. Each device is assigned a static IPv4
address within the same subnet to allow direct Layer 2 forwarding and simple client–server
communication. The topology emphasizes a star-like physical layout (devices radiating to the
switch) while illustrating logical broadcast behavior within the single broadcast domain.
Place the full network diagram here to give readers a clear visual of device placement,
cabling, and IP assignments.
2
Figure 1: Overall network topology showing switch, servers, client devices, and cable types.
5.2 Device Addressing and Port Mapping
The table below summarizes the logical IP addressing and the physical switch port assign-
ments corresponding to the network topology diagram. Place the exported topology image
immediately above this table so readers can cross-reference device labels and cabling.
Table 1: Device IP Addresses and Switch Port Mapping
Device Type Device Name IP Address Switch Port Cable Type
Server (DNS) DNS Server 0 [Link] Fa0/1 Straight-Through
Server (HTTP) HTTP Server 1 (Google) [Link] Fa0/2 Straight-Through
Server (HTTP) HTTP Server 2 (Facebook) [Link] Fa0/3 Straight-Through
PC PC0 [Link] Fa0/4 Straight-Through
Laptop Laptop0 [Link] Fa0/5 Straight-Through
PC PC1 [Link] Fa0/6 Straight-Through
Switch 2960-24TT Switch0 (management – –
IP optional)
5.3 Connection Methodology Flowchart
The flowchart below summarizes the step-by-step procedure used to connect devices, select
cabling, assign IP addresses, and verify connectivity and services. Export the diagram from
[Link] as an image (e.g., [Link]) and insert it here so readers can view the
procedural steps alongside the topology and tables.
3
Figure 2: Procedural flowchart for device connectivity, cabling selection, and verification.
6 Program Code and Commands
This subsection documents the exact sequence you followed: assign IP addresses to all devices,
then run verification commands from PC0 (client). Include the actual command lines and
representative command outputs (screenshots) in the Results or Appendix.
6.1 Step 1 — IP address placement
Assign static IPv4 addresses on each device before testing. Example entries for the devices
used in this lab:
DNS Server: [Link] /24
HTTP Server 1: [Link] /24
HTTP Server 2: [Link] /24
PC0: [Link] /24
Laptop0: [Link] /24
4
PC1: [Link] /24
Default Gateway: [Link] (optional)
DNS Server: [Link]
6.2 Step 2 — Commands executed on PC0
Open PC0 Desktop → Command Prompt and run the following commands in order. Capture
each command output as a screenshot.
# Verify local IP configuration
ipconfig /all
# Test reachability to DNS server
ping [Link]
# Test reachability to HTTP servers
ping [Link]
ping [Link]
# Test DNS resolution (if using names)
nslookup [Link] [Link]
# Test HTTP service (from Packet Tracer client browser or use telnet)
telnet [Link] 80
6.3 Representative ping output
Include the exact ping output you observed. For example, from PC0 pinging the DNS server:
C:\>ping [Link]
Pinging [Link] with 32 bytes of data:
Reply from [Link]: bytes=32 time=2ms TTL=128
Reply from [Link]: bytes=32 time=1ms TTL=128
Reply from [Link]: bytes=32 time=1ms TTL=128
Reply from [Link]: bytes=32 time=2ms TTL=128
Ping statistics for [Link]:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms
5
Figure 3: Command Prompt output confirming 0% packet loss across 3 hubs.
7 Input and Output
This section presents the visual verification of the network configuration. It confirms that
the switch has successfully learned the physical addresses of connected devices and that the
Application Layer services (DNS and HTTP) are functioning correctly for the end-user.
7.1 Switch MAC Address Table
To verify Layer 2 connectivity and switching logic, the ‘show mac-address-table‘ command was
executed on the Cisco 2960 Switch.
Observation: The output below confirms that the switch has dynamically learned the
MAC addresses of the connected PCs and Servers. It maps each MAC address to a specific
physical port (FastEthernet), validating that the switch allows directed communication rather
than broadcasting every frame.
Figure 4: Switch MAC Address Table showing dynamic learning of device physical addresses.
6
7.2 DNS and HTTP Service Verification
The final verification involves testing the ”User Experience” to ensure that the Client PC can
access websites using domain names rather than IP addresses.
7.2.1 Name Resolution (nslookup)
Before opening the web browser, the ‘nslookup‘ command was used on PC0 to verify that the
DNS server ([Link]) correctly resolves the domain name [Link] to the IP
address [Link].
Figure 5: Successful DNS resolution of the domain name to its corresponding IP address.
7.2.2 Web Browser Output
Finally, the Web Browser on PC0 was utilized to access the HTTP Servers. As shown in the
figures below, the browser successfully displayed the distinct webpages for both ”Google” and
”Facebook” servers, confirming that the network distinguishes between the two services based
on the resolved IP addresses.
(a) Accessing HTTP Server 1 (Google) (b) Accessing HTTP Server 2 (Facebook)
Figure 6: Successful retrieval of HTML content from both Web Servers.
7.3 Discussion
The results demonstrate successful implementation of a switched LAN with dedicated services.
1. Layer 2 Forwarding: The MAC address table proves the switch is actively filtering
traffic based on learned hardware addresses.
2. Address Resolution: The nslookup output validates that the DNS server is reachable
and correctly configured with A-Records.
7
3. Service Availability: The browser screenshots confirm that TCP port 80 connections
are being accepted by the servers and that the HTML content is being delivered to the
client.
8 Remarks
Upon completion of this laboratory experiment, several key observations were made regarding
the behavior of switched networks and application-layer services:
• Dynamic Learning: It was observed that the Switch MAC address table remains empty
until traffic is generated. This highlights the ”self-learning” nature of Layer 2 devices,
which only map ports to hardware addresses upon receiving active frames.
• DNS Dependency: The experiment clearly demonstrated that HTTP service access
via domain names ([Link]) is entirely dependent on the correct configuration
of the DNS IP on the client side. Without the DNS entry, the browser fails to resolve the
host, even if the web server is physically reachable.
• Service Isolation: By hosting ”Google” and ”Facebook” on two different server IPs
([Link] and [Link]), it was shown how a single LAN can manage multiple
distinct services differentiated by their logical addresses.
• Troubleshooting Efficiency: Using ping before attempting to use the Web Browser
proved to be an essential troubleshooting step. It ensured that Layer 3 connectivity was
stable before testing Application Layer (Layer 7) protocols.
9 Conclusion
This lab successfully simulated a functional Local Area Network utilizing Cisco Packet Tracer.
By configuring HTTP and DNS services, we demonstrated the end-to-end process of how a user
interacts with the web: from name resolution to content retrieval. The integration of a 2960
Switch provided a practical look at how frames are forwarded within a broadcast domain. All
objectives, including static IP assignment, service deployment, and connectivity verification,
were met. This exercise reinforces the theoretical understanding of the TCP/IP stack and
provides the foundational skills necessary for configuring real-world network environments.