Qatar University CMPE456 Computer Network

College of Engineering Fall 2022

Computer Science and Engineering Chapter 10
1. 10.2.1.8 Packet Tracer - Web and Email Instructions
2. 10.2.2.8 Packet Tracer - DNS and DHCP Instructions
3. 10.2.3.2 Packet Tracer - FTP Instructions

10.2.1.8 Packet Tracer - Web and Email Servers

Topology

Objectives
Part 1: Configure and Verify Web Services
Part 2: Configure and Verify Email Services
Background
In this activity, you will configure HTTP and email services using the simulated server in Packet Tracer. You
will then configure clients to access the HTTP and email services.
Note: Packet Tracer only simulates the process for configuring these services. HTTP and email software
packages each have their own unique installation and configuration instructions.

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 1 of 16
Packet Tracer - Web and Email Servers

Part 1: Configure and Verify Web Services

Step 1: Configure web services on CentralServer and BranchServer.
a. Click CentralServer and click the Services tab > HTTP.
b. Click On to enable HTTP and HTTP Secure (HTTPS).
c. Optional. Personalize the HTML code.
d. Repeat Step1a – 1c on BranchServer.
Step 2: Verify the web servers by accessing the web pages.
There are many endpoint devices in this network, but for the purposes of this step, use PC3.
a. Click PC3 and click the Desktop tab > Web Browser.
b. In the URL box, enter 10.10.10.2 as the IP address and click Go. The CentralServer website displays.
c. In the URL box, enter 64.100.200.1 as the IP address and click Go. The BranchServer website displays.
d. In the URL box, enter centralserver.pt.pka and click Go. The CentralServer website displays.
e. In the URL box, enter branchserver.pt.pka and click Go. The BranchServer website displays.
f. What protocol is translating the centralserver.pt.pka and branchserver.pt.pka names to IP addresses?

Part 2: Configure and Verify Email Services on Servers

Step 1: Configure CentralServer to send (SMTP) and receive (POP3) Email.
a. Click CentralServer, and then select the Services tab followed by the EMAIL button.
b. Click On to enable the SMTP and POP3.
c. Set the domain name to centralserver.pt.pka and click Set.
d. Create a user named central-user with password cisco. Click + to add the user.
Step 2: Configure BranchServer to send (SMTP) and receive (POP3) Email.
a. Click BranchServer and click the Services tab > EMAIL.
b. Click On to enable SMTP and POP3.
c. Set the domain name to branchserver.pt.pka and click Set.
d. Create a user named branch-user with password cisco. Click + to add the user.
Step 3: Configure PC3 to use the CentralServer email service.
a. Click PC3 and click the Desktop tab > E Mail.
b. Enter the following values into their respective fields:
1) Your Name: Central User
2) Email Address: [email protected]
3) Incoming Mail Server: 10.10.10.2
4) Outgoing Mail Server: 10.10.10.2
5) User Name: central-user
6) Password: cisco
c. Click Save. The Mail Browser window displays.
d. Click Receive. If everything has been set up correctly on both the client and server, the Mail Browser
window displays the Receive Mail Success message confirmation.
Step 4: Configure Sales to use the Email service of BranchServer.
a. Click Sales and click the Desktop tab > E Mail.
b. Enter the following values into their respective fields:
1) Your Name: Branch User
2) Email Address: [email protected]
3) Incoming Mail Server: 172.16.0.3
4) Outgoing Mail Server: 172.16.0.3
5) User Name: branch-user
6) Password: cisco
c. Click Save. The Mail Browser window displays.
d. Click Receive. If everything has been set up correctly on both the client and server, the Mail Browser
window displays the Receive Mail Success message confirmation.
e. The activity should be 100% complete. Do not close the Sales configuration window or the Mail Browser
window.
Step 5: Send an Email from the Sales client and the PC3 client.
a. From the Sales Mail Browser window, click Compose.
b. Enter the following values into their respective fields:
1) To: [email protected]
2) Subject: Personalize the subject line.

Page 2 of 16
Packet Tracer - Web and Email Servers
3) Email Body: Personalize the email.
c. Click Send.
d. Verify that PC3 received the email. Click PC3. If the Mail Browser window is closed, click E Mail.
e. Click Receive. An email from Sales displays. Double-click the email.
f. Click Reply, personalize a response, and click Send.
g. Verify that Sales received the reply.

10.2.2.8 Packet Tracer - DNS and DHCP Instructions

Lab - Using Wireshark to Examine a UDP DNS Capture
Topology

Objectives
Part 3: Record a PC’s IP Configuration Information
Part 4: Use Wireshark to Capture DNS Queries and Responses
Part 5: Analyze Captured DNS or UDP Packets
Background / Scenario
If you have ever used the Internet, you have used the Domain Name System (DNS). DNS is a
distributed network of servers that translates user-friendly domain names like www.google.com to an
IP address. When you type a website URL into your browser, your PC performs a DNS query to the
DNS server’s IP address. Your PC’s DNS server query and the DNS server’s response make use of
the User Datagram Protocol (UDP) as the transport layer protocol. UDP is connectionless and does
not require a session setup, as does TCP. DNS queries and responses are very small and do not
require the overhead of TCP.
In this lab, you will communicate with a DNS server by sending a DNS query using the UDP transport
protocol. You will use Wireshark to examine the DNS query and response exchanges with the name
server.
Required Resources
1 PC (Windows 7, Vista, or XP with a command prompt access, Internet access, and Wireshark installed)
Part 3: Record a PC’s IP Configuration Information
In Part 3, you will use the ipconfig /all command on your local PC to find and record the MAC and
IP addresses of your PC’s network interface card (NIC), the IP address of the specified default
gateway, and the DNS server IP address specified for the PC. Record this information in the table
provided. The information will be used in the following parts of this lab with packet analysis.
IP address
MAC address
Default gateway IP address
DNS server IP address
Part 4: Use Wireshark to Capture DNS Queries and Responses
In Part 4, you will set up Wireshark to capture DNS query and response packets to demonstrate the
use of UDP transport protocol while communicating with a DNS server.
a. Click the Windows Start button and navigate to the Wireshark program.
Note: If Wireshark is not yet installed, it can be downloaded at
http://www.wireshark.org/download.html.
b. Select an interface for Wireshark for capturing packets. Use the Interface List to choose the
interface that is associated with the recorded PC’s IP and MAC addresses in Part 3.
c. After selecting the desired interface, click Start to capture the packets.
Page 3 of 16
Packet Tracer - Web and Email Servers
d. Open a web browser and type www.google.com. Press Enter to continue.
e. Click Stop to stop the Wireshark capture when you see Google’s home page.
Part 5: Analyze Captured DNS or UDP Packets
In Part 3, you will examine the UDP packets that were generated when communicating with a DNS
server for the IP addresses for www.google.com.
Step 1: Filter DNS packets.
a. In the Wireshark main window, type dns in the entry area of the Filter toolbar. Click Apply or press Enter.
Note: If you do not see any results after the DNS filter was applied, close the web browser and in the
command prompt window, type ipconfig /flushdns to remove all previous DNS results. Restart the
Wireshark capture and repeat the instructions in Part 2b –2e. If this does not resolve the issue, in the
command prompt window, you can type nslookup www.google.com as an alternative to the web browser.

b. In the packet list pane (top section) of the main window, locate the packet that includes “standard query” and
“A www.google.com”. See frame 4 as an example.
Step 2: Examine UDP segment using DNS query.
Examine UDP by using a DNS query for www.google.com as captured by Wireshark. In this example,
Wireshark capture frame 4 in the packet list pane is selected for analysis. The protocols in this query are
displayed in the packet details pane (middle section) of the main window. The protocol entries are highlighted
in gray.

a. In the packet details pane, frame 4 had 74 bytes of data on the wire as displayed on the first line. This is the
number of bytes to send a DNS query to a name server requesting the IP addresses of www.google.com.
b. The Ethernet II line displays the source and destination MAC addresses. The source MAC address is from
your local PC because your local PC originated the DNS query. The destination MAC address is from the
default gateway, because this is the last stop before this query exits the local network.
Is the source MAC address the same as recorded from Part 1 for the local PC?
c. In the Internet Protocol Version 4 line, the IP packet Wireshark capture indicates that the source IP address
of this DNS query is 192.168.1.11, and the destination IP address is 192.168.1.1. In this example, the
destination address is the default gateway. The router is the default gateway in this network.
Can you pair up the IP and MAC addresses for the source and destination devices?

Page 4 of 16
Packet Tracer - Web and Email Servers
Device IP Address MAC Address
Local PC
Default Gateway
The IP packet and header encapsulates the UDP segment. The UDP segment contains the DNS query as
the data.
d. A UDP header only has four fields: source port, destination port, length, and checksum. Each field in UDP
header is only 16 bits as depicted below.

Expand the User Datagram Protocol in the packet details pane by clicking the plus (+) sign. Notice that there
are only four fields. The source port number in this example is 52110. The source port was randomly
generated by the local PC using port numbers that are not reserved. The destination port is 53. Port 53 is a
well-known port reserved for use with DNS. DNS servers listen on port 53 for DNS queries from clients.

In this example, the length of this UDP segment is 40 bytes. Out of 40 bytes, 8 bytes are used as header.
The other 32 bytes are used by DNS query data. The 32 bytes of DNS query data is highlighted in the
following illustration in the packet bytes pane (lower section) of the Wireshark main window.

The checksum is used to determine the integrity of the packet after it has traversed the Internet.
The UDP header has low overhead because UDP does not have fields that are associated with three-way
handshake in TCP. Any data transfer reliability issues that occur must be handled by the application layer.
Record your Wireshark results in the table below:
Frame Size
Source MAC address
Destination MAC address
Source IP address
Destination IP address
Source Port
Destination Port
Is the source IP address the same as the local PC’s IP address recorded in Part 1? _
Is the destination IP address the same as the default gateway noted in Part 1?
Step 3: Examine UDP using DNS response.
In this step, you will examine the DNS response packet and verify that DNS response packet also uses UDP.
a. In this example, frame 5 is the corresponding DNS response packet. Notice the number of bytes on the
wire is 290 bytes. It is a larger packet as compared to the DNS query packet.
Page 5 of 16
Packet Tracer - Web and Email Servers

b. In the Ethernet II frame for the DNS response, from what device is the source MAC address and what
device is the destination MAC address?

c. Notice the source and destination IP addresses in the IP packet. What is the destination IP address?
What is the source IP address?
Destination IP address: Source IP address: _
What happened to the roles of source and destination for the local host and default gateway?

d. In the UDP segment, the role of the port numbers has also reversed. The destination port number is
52110. Port number 52110 is the same port that was generated by the local PC when the DNS query was
sent to the DNS server. Your local PC listens for a DNS response on this port.
The source port number is 53. The DNS server listens for a DNS query on port 53 and then sends a DNS
response with a source port number of 53 back to originator of the DNS query.
When the DNS response is expanded, notice the resolved IP addresses for www.google.com in the
Answers section.

Page 6 of 16
Packet Tracer - Web and Email Servers

10.2.3.2 Packet Tracer - FTP Instructions

Topology – Part 1 (FTP)
Part 1 will highlight a TCP capture of an FTP session. This topology consists of a PC with Internet access.

Topology – Part 2 (TFTP)

Part 2 will highlight a UDP capture of a TFTP session. The PC must have both an Ethernet connection and a
console connection to Switch S1.

Addressing Table (Part 2)

Device Interface IP Address Subnet Mask Default Gateway
S1 VLAN 1 192.168.1.1 255.255.255.0 N/A
PC-A NIC 192.168.1.3 255.255.255.0 192.168.1.1
Objectives
Part 1: Identify TCP Header Fields and Operation Using a Wireshark FTP Session Capture
Part 2: Identify UDP Header Fields and Operation Using a Wireshark TFTP Session Capture
Background / Scenario
The two protocols in the TCP/IP transport layer are the TCP, defined in RFC 761, and UDP, defined
in RFC 768. Both protocols support upper-layer protocol communication. For example, TCP is used
to provide transport layer support for the HyperText Transfer Protocol (HTTP) and FTP protocols,
among others. UDP provides transport layer support for the Domain Name System (DNS) and TFTP
among others.
Note: Understanding the parts of the TCP and UDP headers and operation are a critical skill for
network engineers.
In Part 1 of this lab, you will use Wireshark open source tool to capture and analyze TCP protocol header
fields for FTP file transfers between the host computer and an anonymous FTP server. The Windows
command line utility is used to connect to an anonymous FTP server and download a file.
In Part 2 of this lab, you will use Wireshark to capture and analyze UDP protocol header fields for TFTP file
transfers between the host computer and Switch S1.
Note: The switch used is a Cisco Catalyst 2960s with Cisco IOS Release 15.0(2) (lanbasek9 image) and no
configuration. Other switches and Cisco IOS versions can be used. Depending on the model and Cisco IOS
version, the available commands and output produced might vary from what displays in the labs.
Part 6: Required Resources – Part 1 (FTP)
1 PC (Windows 7, Vista, or XP with command prompt access, Internet access, and Wireshark installed)
Required Resources – Part 2 (TFTP)
 1 Switch (Cisco 2960 with Cisco IOS Release 15.0(2) lanbasek9 image or comparable)
 1 PC (Windows 7, Vista, or XP with Wireshark and a TFTP server, such as tftpd32 installed)
 Console cable to configure the Cisco IOS devices via the console port
 Ethernet cable as shown in the topology

Page 7 of 16
Packet Tracer - Web and Email Servers

Part 7: Identify TCP Header Fields and Operation Using a Wireshark FTP
Session Capture
In Part 1, you use Wireshark to capture an FTP session and inspect TCP header fields.
Step 1: Start a Wireshark capture.
a. Close all unnecessary network traffic, such as the web browser, to limit the amount traffic during the
Wireshark capture.
b. Start the Wireshark capture.
Step 2: Download the Readme file.
a. From the command prompt, enter ftp ftp.cdc.gov.
b. Log into the FTP site for Centers for Disease Control and Prevention (CDC) with user anonymous and no
password.
c. Locate and download the Readme file.

Step 3: Stop the Wireshark capture.

Step 4: View the Wireshark Main Window.
Wireshark captured many packets during the FTP session to ftp.cdc.gov. To limit the amount of data for
analysis, type tcp and ip.addr == 198.246.112.54 in the Filter: entry area and click Apply. The IP address,
198.246.112.54, is the address for ftp.cdc.gov.

Page 8 of 16
Packet Tracer - Web and Email Servers
Step 5: Analyze the TCP fields.
After the TCP filter has been applied, the first three frames in the packet list pane (top section) displays the
transport layer protocol TCP creating a reliable session. The sequence of [SYN], [SYN, ACK], and [ACK]
illustrates the three-way handshake.

TCP is routinely used during a session to control datagram delivery, verify datagram arrival, and manage
window size. For each data exchange between the FTP client and FTP server, a new TCP session is started.
At the conclusion of the data transfer, the TCP session is closed. Finally, when the FTP session is finished,
TCP performs an orderly shutdown and termination.
In Wireshark, detailed TCP information is available in the packet details pane (middle section). Highlight the
first TCP datagram from the host computer, and expand the TCP record. The expanded TCP datagram
appears similar to the packet detail pane shown below.

The image above is a TCP datagram diagram. An explanation of each field is provided for reference:
 The TCP source port number belongs to the TCP session host that opened a connection. The value is
normally a random value above 1,023.
 The TCP destination port number is used to identify the upper layer protocol or application on the remote
site. The values in the range 0–1,023 represent the “well-known ports” and are associated with popular
services and applications (as described in RFC 1700, such as Telnet, FTP, HTTP, and so on). The
combination of the source IP address, source port, destination IP address, and destination port uniquely
identifies the session to both sender and receiver.
Note: In the Wireshark capture below, the destination port is 21, which is FTP. FTP servers listen on port 21
for FTP client connections.
 The Sequence number specifies the number of the last octet in a segment.
 The Acknowledgment number specifies the next octet expected by the receiver.

Page 9 of 16
Packet Tracer - Web and Email Servers
 The Code bits have a special meaning in session management and in the treatment of segments. Among
interesting values are:
- ACK — Acknowledgement of a segment receipt.
- SYN — Synchronize, only set when a new TCP session is negotiated during the TCP three-way
handshake.
- FIN — Finish, request to close the TCP session.
 The Window size is the value of the sliding window; determines how many octets can be sent before
waiting for an acknowledgement.
 The Urgent pointer is only used with an Urgent (URG) flag when the sender needs to send urgent data
to the receiver.
 The Options has only one option currently, and it is defined as the maximum TCP segment size (optional
value).
Using the Wireshark capture of the first TCP session startup (SYN bit set to 1), fill in information about the
TCP header:
From the PC to CDC server (only the SYN bit is set to 1):
Source IP Address:
Destination IP Address:
Source port number:
Destination port number:
Sequence number:
Acknowledgement number:
Header length:
Window size:
In the second Wireshark filtered capture, the CDC FTP server acknowledges the request from the PC. Note
the values of the SYN and ACK bits.

Fill in the following information regarding the SYN-ACK message.

Source IP address:
Destination IP address:
Source port number:
Destination port number:
Sequence number:
Acknowledgement number:
Header length:
Window size:
In the final stage of the negotiation to establish communications, the PC sends an acknowledgement message
to the server. Notice only the ACK bit is set to 1, and the Sequence number has been incremented to 1.

Page 10 of 16
Packet Tracer - Web and Email Servers

Fill in the following information regarding the ACK message.

Source IP address:
Destination IP address:
Source port number:
Destination port number:
Sequence number:
Acknowledgement number:
Header length:
Window size:
How many other TCP datagrams contained a SYN bit?
After a TCP session is established, FTP traffic can occur between the PC and FTP server. The FTP client and
server communicate between each other, unaware that TCP has control and management over the session.
When the FTP server sends a Response: 220 to the FTP client, the TCP session on the FTP client sends an
acknowledgment to the TCP session on the server. This sequence is visible in the Wireshark capture below.

When the FTP session has finished, the FTP client sends a command to “quit”. The FTP server acknowledges
the FTP termination with a Response: 221 Goodbye. At this time, the FTP server TCP session sends a TCP
datagram to the FTP client, announcing the termination of the TCP session. The FTP client TCP session
acknowledges receipt of the termination datagram, then sends its own TCP session termination. When the
originator of the TCP termination, FTP server, receives a duplicate termination, an ACK datagram is sent to
acknowledge the termination and the TCP session is closed. This sequence is visible in the diagram and
capture below.

Page 11 of 16
Packet Tracer - Web and Email Servers

By applying an ftp filter, the entire sequence of the FTP traffic can be examined in Wireshark. Notice the
sequence of the events during this FTP session. The username anonymous was used to retrieve the Readme
file. After the file transfer completed, the user ended the FTP session.

Apply the TCP filter again in Wireshark to examine the termination of the TCP session. Four packets are
transmitted for the termination of the TCP session. Because TCP connection is full-duplex, each direction must
terminate independently. Examine the source and destination addresses.
In this example, the FTP server has no more data to send in the stream; it sends a segment with the FIN flag
set in frame 63. The PC sends an ACK to acknowledge the receipt of the FIN to terminate the session from the
server to the client in frame 64.
In frame 65, the PC sends a FIN to the FTP server to terminate the TCP session. The FTP server responds
with an ACK to acknowledge the FIN from the PC in frame 67. Now the TCP session terminated between the
FTP server and PC.

Page 12 of 16
Packet Tracer - Web and Email Servers

Part 8: Identify UDP Header Fields and Operation Using a Wireshark TFTP
Session Capture
In Part 2, you use Wireshark to capture a TFTP session and inspect UDP header fields.
Step 1: Set up this physical topology and prepare for TFTP capture.

a. Establish a console and Ethernet connection between PC-A and Switch S1.
b. If not already done, manually configure the IP address on the PC to 192.168.1.3. It is not required to set the
default gateway.

c. Configure the switch. Assign an IP address of 192.168.1.1 to VLAN 1. Verify connectivity with the PC by
pinging 192.168.1.3. Troubleshoot as necessary.
Switch> enable
Switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# host S1
S1(config)# interface vlan 1
S1(config-if)# ip address 192.168.1.1 255.255.255.0
S1(config-if)# no shut
*Mar 1 00:37:50.166: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
*Mar 1 00:37:50.175: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1,
changed state to up
S1(config-if)# end
S1# ping 192.168.1.3

Page 13 of 16
Packet Tracer - Web and Email Servers
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1007 ms

d. Save the running configuration to NVRAM:

S1# copy run start

Step 2: Prepare the TFTP server on the PC.

a. If it does not already exist, create a folder on the PC desktop called TFTP. The files from the switch will be
copied to this location.
b. Start tftpd32 on the PC.
c. Click Browse and change the current directory to C:\Users\user1\Desktop\TFTP by replacing user1 with
your username.
The TFTP server should look like this:

Notice that in Current Directory, it lists the user and the Server (PC-A) interface as the IP address of
192.168.1.3.
d. Test the ability to copy a file using TFTP from the switch to the PC. Troubleshoot as necessary.
S1# copy start tftp
Address or name of remote host []? 192.168.1.3
Destination filename [s1-confg]?
!!
1638 bytes copied in 0.026 secs (63000 bytes/sec)
If you see that the file has copied (as in the above output), then you are ready to go on to the next step. If
not, then troubleshoot. If you get the %Error opening tftp (Permission denied) error, first
check to make sure your firewall is not blocking TFTP, and that you are copying to a location where your
username has adequate permission, such as the desktop.
Step 3: Capture a TFTP session in Wireshark
a. Open Wireshark. From the Edit menu, choose Preferences and click the (+) sign to expand Protocols.
Scroll down and select UDP. Click the Validate the UDP checksum if possible check box and click
Apply. Then click OK.

Page 14 of 16
Packet Tracer - Web and Email Servers
b. Start a Wireshark capture.
c. Run the copy start tftp command on the switch.
d. Stop the Wireshark capture.

e. Set the filter to tftp. Your output should look similar to the output shown above. This TFTP transfer is used
to analyze transport layer UDP operations.
In Wireshark, detailed UDP information is available in the Wireshark packet details pane. Highlight the first
UDP datagram from the host computer, and move the mouse pointer to the packet details pane. It may be
necessary to adjust the packet details pane and expand the UDP record by clicking the protocol expand box.
The expanded UDP datagram should look similar to the diagram below.

The figure below is a UDP datagram diagram. Header information is sparse, compared to the TCP datagram.
Similar to TCP, each UDP datagram is identified by the UDP source port and UDP destination port.

Using the Wireshark capture of the first UDP datagram, fill in information about the UDP header. The
checksum value is a hexadecimal (base 16) value, denoted by the preceding 0x code:
Source IP Address:
Destination IP Address:
Source Port Number:
Destination Port Number:
UDP Message Length:
UDP Checksum:
How does UDP verify datagram integrity? _
Examine the first frame returned from tftpd server. Fill in the information about the UDP header:

Page 15 of 16
Packet Tracer - Web and Email Servers
Source IP Address:
Destination IP Address:
Source Port Number:
Destination Port Number:
UDP Message Length:
UDP Checksum:

Notice that the return UDP datagram has a different UDP source port, but this source port is used for the
remainder of the TFTP transfer. Because there is no reliable connection, only the original source port used to
begin the TFTP session is used to maintain the TFTP transfer.
Also notice that the UDP Checksum is incorrect. This is most likely caused by UDP checksum offload. You can
learn more about why this happens by searching for “UDP checksum offload”.

Challenge
Because neither FTP nor TFTP are secure protocols, all transferred data is sent in clear text. This includes any
user IDs, passwords, or clear-text file contents. Analyzing the upper-layer FTP session will quickly identify the
user ID, password, and configuration file passwords. Upper-layer TFTP data examination is a bit more
complicated, but the data field can be examined and the configuration user ID and password information
extracted.

Cleanup
Unless directed otherwise by your instructor:
1) Remove the files that were copied to your PC.
2) Erase the configurations on switch S1.
3) Remove the manual IP address from the PC and restore Internet connectivity.

Page 16 of 16