In the OSI and TCP/IP models, the application layer is the interface between the user and the network services, and therefore it has a lot of protocols which a CCNA candidate should know about. Packet Tracer contains some of the most important protocols and, although they’re much more complex in reality, the basics can be understood with a lab. We’ll see a common scenario when a user wants to put a webpage on an ISP’s web server with FTP, and we’ll use some email-related protocols, as well.

We will use the following topology:

Our user connects to the Internet through DSL. The ISP has a server farm consisting of mail, Web, FTP, and DNS servers. The administrator has a laptop. In the base topology attached to this article, the IP addressing and the DNS are configured, as along with an email account for the administrator (

Let’s start by creating an email account for the user. This should be done on an SMTP server: SMTP means simple mail transport protocol and it is used to send emails between hosts on the Internet. SMTP is a TCP-based service and uses port 25 by default. On this port, a daemon program called mail transfer agent (MTA) is listening and accepting connections from clients, which can be a single user’s mail user agent (MUA) software, or another SMTP server. When the connection has been established, the peers exchange the information about the mail message by SMTP commands, as this is a clear text protocol. The following is an example of such a conversation copied from real server (some data is sensitive so I made it unrecognizable):

It can be seen that we can send email without a MUA: just telnet to the mail server on port 25 and issue the necessary SMTP commands. (Note: ISPs usually block this type of connection because of spammers.) First the client sends a HELO command saying its domain name, then the address of the sender, followed by the address of the recipient (RCPT). The next phase specifies the data of the message; we can also specify other email message header fields such us Subject, then we add the body of the message. The end of the message is indicated by a dot in separate line. If everything is OK, the server accepts this and puts the message in a queue to process it further. It can run a spam analyzer or virus scanner, and then puts it into the user’s mailbox: this is the most common scenario. When the recipient user wants to read the message, he or she must use another protocols, namely POP3 or IMAP. POP3 is the acronym for post office protocol, while IMAP stands for internet message access protocol. Both of them are for accessing our emails remotely, but POP3 is simpler. It usually downloads the full message from the server, while IMAP doesn’t; moreover it can store them in separate folders (there are lot more differences, of course).

With this information in mind, let’s get back to our lab and be the administrator of Go to the mail server and locate the Services/EMAIL section. The domain name is already set, so our job is just to enter a username and a password for our customer. Let it be “user1” and “password1,” and add it to the database by clicking the plus sign. Later we can see the data by clicking on the username, and can even change the password.

Now go to the admin laptop and launch the Desktop/Email application. First we have to create a profile here, so fill in the necessary information:

By clicking Save, we are ready to send and receive emails through the server. Let’s write a letter to the customer about how he can access to the website and how to upload his webpage. Click on Compose button and enter the following:

Clicking on Send, the mail should be sent to the server and a message on the bottom states that the process finished successfully. Now go to the user’s PC and repeat the steps necessary to create the user profile for email. When it is ready, click on Receive and the message should appear. The client uses POP3 this time, which is also TCP-based and uses port 110 by default. Nowadays using POP3 is not recommended, because it’s a clear text protocol, so a hacker can easily capture the passwords. Use POP3S instead, which is POP3 complemented by SSL (secure socket layer). With this, the username and password are encrypted.

As I mentioned, SMTP uses TCP. By entering Simulation Mode, we can see the TCP three-way handshaking process: Every TCP connection starts with this. First the client sends the SYN segment, indicating that it wants a connection on the given port, and provides its starting sequence number. It’s important for the sequencing of segments, which is a method used by TCP to maintain reliable transmission. The server answers with a SYN+ACK segment, which acknowledges the first segment and provides its own sequence number. Finally, the client also sends an ACK. Now the data transport of the mail message starts and, when it finishes, the peers close the connection by sending FIN – FIN+ACK – ACK segments.

Now our customer knows the information about the upload possibilities, so the first step is to make the new web page. In our example, it’ll be just a single HTML page, but Packet Tracer gives the opportunity to make complete sites, even using JavaScript. First try to reach the web server in order to test the reachability: Enter the address into the address field of the Web Browser application. It should work. Anyway, if we can’t reach a website by domain name, but just by IP address, then we need to check the DNS settings and the connection state with the DNS server.

In order to make the user’s web page, open the Desktop/Text Editor application on the PC. Make a very basic HTML page with just the following content:

This is the web page of User1

Save it under the name of user1.html, then close the editor and open Command Prompt. First see if the saved file is there by issuing the dir command. Unfortunately we cannot test our HTML pages on the local machine before we upload them, but in this case it’s not a problem. If you want to use a more complicated web page in Packet Tracer, you can make it in a real HTML editor, save it to the local machine and then import it to the HTTP server.

Next we need to upload the file to the web server. Normally, the individual users have separate directories on the server where they can put their pages, but PT doesn’t support this. Moreover, the websites of the users can appear under different domain names: This is called virtual hosting. A web server treats virtual hosts just like physical hosts: It has separate domain name, separate web pages, separate log files, and so on, but all of them exist on one physical server, under one physical IP address. When the HTTP server gets a request for a particular domain name, it will know what pages to serve, based on that name. This way the ISP needs many fewer IP addresses and servers.

In our lab we’ll use FTP (file transfer protocol) to upload files, which is an obvious way for this, although not the most secure one, as FTP uses authentication, but the data (username and password) will traverse in clear text through the network. We can overcome this by using SFTP (secure FTP) or FTPS (FTP over SSL), but in this lab we’ll use the good old basic protocol. First we have to create the user account on the server for User1. So go to the web+ftp server, and locate Services/FTP. Here we need to check whether the service is on, and then add the user’s name and password (same as for email). Moreover, we have to specify which rights the user will have: There’re read, write, delete, rename, and list. We can create a user who can list the files and directories and read them, but cannot delete, rename, or write into them. This is common in the so-called anonymous FTP servers, where anybody can connect to the server even without a user account, but can only download some files. In this case the username is “anonymous” or “ftp,” and the password is usually our email address. A s we can see, PT has some files to download: they are OS image files just as for the TFTP service.

Now that our server is ready, go to the client PC. The necessary client program is built into every operating system, in our case the name is ftp. We need to specify the destination server’s name or address, and then authenticate ourselves:

FTP servers usually print a welcome message before the connection; this is especially common in the case of anonymous FTP. After successful login, there can be another message, and finally we’ll get the prompt where we can issue control commands. For example, we can discover the directories by dir command, download files with get, upload files with the put command, and so on. Enter help to know the commands supported by PT. You need to know that FTP uses two TCP ports: 21 is for the control channel and 20 for the data transfer in active mode. But what is active mode? In this case, the server starts the data transfer initiated from its 20/TCP port toward the client. This is OK if we don’t have a firewall, but most of them block that type of traffic, because it’s initiated from the untrusted network side. The solution is to use passive mode: In this case, the server tells the client the port that can be used to connect to under the data transfer, and the client starts the process. As this is a permitted traffic (from inside to outside) the firewall won’t block, and the answer can come in from the server also. We can set our client into passive mode under Windows with the quote pasv command, but in the simulator there’s the passive command. Notice that when the client starts, it automatically enters passive mode, so we don’t really need to specify it, but when using real clients, take note of this. A quick test if everything works is issuing the dir command: If we can see the file list, then FTP works as expected.

Now upload the HTML file created before, but we have to know what destination directory we need to use, because the default directory doesn’t contain the web pages, but the image files. So we need to enter the following:

cd /http

This way we enter the root directory of the HTTP server. Next do the actual upload and check if it’s successful:

It looks good, but the final test is to see the page in the web browser. Logout from FTP with the quit command and open the browser. Enter the address we got in the email and see the result. Well done, our first HTML page is published on the web!

There’s a device that can be used in this lab to get to know the protocols even better: the sniffer device. This is under the End Devices category. Put it into the topology between the user PC and the WLAN router: Connect Port0 to the PC and Port1 to the router. Then go to the GUI tab and refresh the web browser with the Go button. You should see some protocols listed one by one in the sniffer: They are protocols of the incoming packets on Port0, the traffic coming from the PC. Possibly they are starts with ARP, as the PC must know the MAC address of the default gateway to send a DNS request about the address of the web server. Then comes the three-way handshake of TCP, followed by the HTTP packets and finally the teardown packets of the connection. We can examine each packet by clicking on it. Unfortunately the sniffer doesn’t support bidirectional data gathering, but we can see the incoming packets from Port1 also. I recommend using Wireshark or similar software in real labs to get better understanding of how these protocols work, but we can do some experiments and more difficult labs in Packet Tracer also.