- Identify common TCP and UDP default port numbers
- Explain the function of common networking protocols
- Summarize DNS concepts and its components
We will analyze some of the most common Application Layer services that a network engineer will encounter on a daily basis, as well as learn the well-known default port numbers assigned to those application services. The objectives are to identify common TCP and UDP protocols, analyze their functionality, and learn the most common port numbers. The information presented in this chapter is very useful in various fields of computer networking and will assist in troubleshooting networks.
You configure and troubleshoot port numbers and services in our Cisco CCNA lab and video course.
The most common protocols, organized by the TCP/IP layer they operate at, are presented in Table 5.1 below:
Table 5.1 – TCP/IP Layers and Their Protocols
We will analyze each of these protocols, starting with application protocols and continuing with management and networking protocols.
Port numbers are assigned to different protocols and services so that a user will know how and what to access at the other end and to identify specific applications. They are also used to track the session associated with that protocol. As explained in Chapter 1, the TCP and UDP headers include a 16-bit source and destination port, so port numbers can be represented in the range of 0 to 65535 (the maximum decimal number that can be represented on 16 bits).
Port numbers fall into two categories:
- Well-known port numbers
- Temporary port numbers
Well-known port numbers are non-ephemeral ports, meaning they are permanently assigned to a protocol or a service. They can be used as a destination port by any network-enabled machine in order to reach specific protocols. A well-known port number helps to uniquely identify a Web server, for example. Even though the Web server might use a random port number, it usually uses port number 80 as a convention so other devices can know how to reach it. If the service used a non-standard port number, a client device could reach it only if it was specifically informed about the port number used. Well-known port numbers are usually those below 1024.
Temporary port numbers are ephemeral ports and are usually used as source ports in a two-way communication process. They are determined in real-time by the client workstation and are usually numbers above 1024. When the session is closed, the generated source port number disappears and a new session destined to the same service will usually use a different source port. The process of generating ephemeral port numbers is done automatically by the TCP/IP stack on the devices and it uses sequential or random port numbers. The allocation process of the unique source ports is accomplished at the Application Layer.
|Note: The TCP header contains port numbers but they are really being used by the Session Layer of the OSI reference model (i.e., bundled in the Application Layer in the TCP/IP protocol suite).|
Even though the same port number can be used in both TCP and UDP, the services they identify can be completely different. For example, TCP port 80 identifies a different service/protocol than UDP port 80 does.
Do not confuse port numbers with protocol numbers. Port numbers uniquely identify network protocols, while protocol numbers identify Layer 3 protocols, for example:
- TCP is protocol number 6
- UDP is protocol number 17
- ICMP is protocol number 1
- IGMP is protocol number 2
The most common application protocols are as follows:
- E-mail protocols (SMTP, POP3, IMAP)
Hypertext Transfer Protocol (HTTP) is the primary protocol used across the Internet between a browser and a Web server, which is a process known as Web browsing.
When a client PC (Web browser) makes a request, the type of request will determine the destination port number used. Websites are often listening on TCP port 80, a well-known port identifying the HTTP protocol, and they respond to request packets using TCP 80 as the source port, as depicted in Figure 5.1 below. This makes life easier for Web clients because if there were no standards regarding this approach, the communication between users and servers would be random.
Figure 5.1 – HTTP Flow Diagram
Anytime a Web browser wants to contact a Web server, it knows that the default port at the Application Layer that is used by the server to listen for traffic is TCP port 80.
|Note: A traffic flow (stream) is uniquely identified by the combination of source IP and port + destination IP and port.|
Considering the traffic flow described above and moving down the protocol stack, you have the following information presented at each layer:
- Application Layer: HTTP (port 80)
- Transport Layer: TCP (HTTP uses TCP as the underlying protocol)
- Internet Layer: IP (the HTTP request is destined to the IP address of the Web server)
- Layer 2: whatever frame types are appropriate for the network type used (often Ethernet)
- Layer 1: the actual bits being sent to the directly connected switch by the client machine
As a practical example, if you type the address www.cisco.com into a browser and make a packet capture of that particular interface, you will see the following:
Figure 5.2 – HTTP Packet Capture
If you analyze the captured packet, you can see some interesting information that confirms the traffic flow information above:
- TCP is used as the protocol for Layer 4, because this is the protocol HTTP is based on at that particular layer.
- The destination port in the TCP header is port 80, identifying HTTP. So at Layer 4, you will find specific information regarding Application Layer data.
- The source port in the TCP header is a unique random high port number that was unused at that time. A unique port number is used for each connection opened by the client toward the server so that the server can individually respond to each request by sending a reply back to the specific port number (identifying each request).
While HTTP is one of the most commonly used protocols on the Internet today, it is not secure, as it sends traffic without encryption on the network. Without any protection, an intruder might capture the packets and easily read the conversation. The HTTP Secure (HTTPS) protocol was developed to overcome these security issues by ensuring a secure encrypted connection between the Web client and the Web server, as shown in Figure 5.3 below:
Figure 5.3 – HTTPS Flow Diagram
HTTPS uses a different port than HTTP by default: TCP port 443 instead of TCP port 80. This can be examined in the packet capture presented in Figure 5.4 below:
Figure 5.4 – HTTPS Packet Capture
The encryption used by the HTTPS protocol is accomplished using the Transport Layer Security/Secure Sockets Layer (TLS/SSL) mechanism. SSL was created by Netscape and this evolved into TLS, which is the updated IETF (Internet Engineering Task Force) version of SSL. HTTPS encryption is still called generic SSL, even though TLS is used as the underlying mechanism.
|Note: When a user wants to access a website, he doesn’t always have to enter “http://” or “https://” in front of the website name, as most browsers automatically complete this by detecting the protocol it can use to access the website.|
The most common protocols used for sending and receiving e-mail traffic are as follows:
- SMTP (Simple Mail Transfer Protocol): TCP port 25
- POP3 (Post Office Protocol): TCP port 110
- IMAP (Internet Message Access Protocol): TCP port 143
POP3 and IMAP (currently at version 4) are used for receiving e-mail. POP3 was designed for intermittent connectivity, and is used for retrieving e-mails only on request or automatically at a pre-configured interval.
IMAP is a more evolved protocol that was developed in the last few years, as it offers more functionality and flexibility. It can manage all e-mail messages directly on the mail server, unlike POP3 which must download the messages in order to manage them locally. IMAP offers access to e-mails from everywhere, not just on the local workstation, and it can also transparently synchronize the local e-mail client with the e-mail server. Although IMAP offers extra functionality, all of these features make IMAP use more resources on the server.
|Note: IMAP is still less popular than POP3 because it was developed at a later stage and requires more resources.|
Unlike POP3 and IMAP, SMTP is used to push (send) e-mails to a server, as well as for transferring e-mails between servers. SMTP offers advanced security features, including encryption.
Being familiar with the protocols used by e-mail applications can help a network engineer in many situations, including with tasks that involve filtering e-mail traffic. This can be accomplished by blocking the well-known e-mail ports using access control lists or other filters, but it doesn’t prevent situations in which the applications use non-standard ports.
File Transfer Protocol (FTP) is, just as the name says, a protocol that allows users to transfer files between the file systems of multiple devices, offering many functionalities in this regard. FTP is an advanced file transfer protocol and it works based on a client-server architecture, as illustrated in Figure 5.5 below:
Figure 5.5 – FTP Flow Diagram
A user who wants to access an FTP server usually uses a dedicated FTP client application that initiates a connection to the server. The FTP client sends a session request on port 21, and after the session to the server is initialized data is transferred using port 20. A unique particularity of FTP is that it uses two port numbers:
- TCP port 20: FTP data
- TCP port 21: FTP control (sends commands to the server)
The image in Figure 5.6 below depicts an FTP control packet capture. Notice that it uses TCP port 21 at the Application Layer.
Figure 5.6 – FTP Packet Capture
Other features offered by FTP include authentication based on username and password and advanced file management functionality on remote devices (e.g., list, delete, and other commands).
|Note: Instead of using a dedicated FTP client application, you can access an FTP server by simply typing ftp:// into a Web browser. For example, ftp://ftp.example.com would access the shared file system on the example.com domain (also known as FQDN – Fully Qualified Domain Name).|
Trivial File Transfer Protocol (TFTP) is similar to FTP but it lacks its complexity and security enhancements. TFTP is an unreliable file transfer protocol that functions over UDP port 69. Unlike FTP, which uses TCP to ensure a connection-oriented session with packet tracking, sequence numbers, and acknowledgements, TFTP does not ensure the proper delivery of packets.
Because it does not use packet tracking or have the complexity of FTP, TFTP is an Application Layer service that provides less overhead but also less reliability. Some other important differences from FTP include the following:
- TFTP provides only read and write functionality
- TFTP does not provide authentication so it is not suitable for production environments
|Note: One of TFTP’s most common uses is transferring firmware and other files to network devices like routers and switches.|
Voice over IP (VoIP) involves moving telephone traffic over an IP infrastructure. Voice packets are digitized and then sent on the IP network. VoIP communications have some particularities that require specific protocols to handle different aspects of the process. In this regard, two protocols are of interest:
- SIP (Session Initiation Protocol)
- RTP (Real-time Transport Protocol)
SIP and RTP are used for completely different aspects of VoIP transmission. SIP is a VoIP signaling protocol that is used to build and terminate media calls, while RTP is used to digitize voice packets and carry the media stream to the other side.
SIP can be used by a phone so that when the user initiates a call, it can logically connect to the other phone to open the conversation. This Application Layer protocol has been designed to run independent of the underlying Transport Layer, meaning it can run on either TCP or UDP.
After the call setup process is over, conversation streaming happens over UDP because of the low overhead, which is suitable for delay-sensitive traffic such as VoIP. The protocol that makes this happen is RTP, as it was designed for the actual delivery of the voice packets over the network.
The most common management protocols are as follows:
Domain Name System (DNS) is a protocol that translates names into IP addresses. Whenever a client wants to interact with a Web server on the Internet, it will identify it by using a name (e.g., cisco.com) because names are easy to remember when compared to complex and random IP addresses. However, in order to communicate with the Web server, the client must have its IP address, and this is where the DNS service comes into play by translating the name into a Layer 3 address.
Figure 5.7 – DNS Basic Functionality
As depicted in Figure 5.7 above, when a DNS server receives a query from a client containing a name, it returns an IP address. The client computer knows where to send the DNS request because it is configured with a DNS server address, which is either entered manually or received via DHCP. After the client receives the IP address associated with the website it wants to communicate with, the connection is initialized and the Web server can be accessed. The DNS server listens for requests on port 53 (both TCP and UDP). UDP port 53 is used for normal DNS lookups and queries and TCP port 53 is used for zone transfers between DNS servers.
A standard DNS query is depicted in the packet capture below, in which you can see both the UDP port number at the Transport Layer and the actual query details at the Application Layer:
Figure 5.8 – DNS Query
Such a query is respond to by the server using a DNS reply similar to the one presented in the packet capture below, in which you can see the actual list of IP addresses returned for the specific website name:
Figure 5.9 – DNS Reply
DNS functions over UDP, so if no response is received in a timely manner, another DNS query will be sent. A TCP request is eventually sent out if no response is forthcoming.
|Note: When trying to access a website from a Windows PC, the operating system first searches for a name-to-IP binding in the internal host file (e.g., location for Windows 7: C:\Windows\System32\drivers\etc), and if no match is found there, it sends a DNS query to the configured server. The reason for this is mostly historical, as there were not that many name-to-IP associations in the past, so it was not a problem to store them in a local file.|
To test DNS functionality on a Windows machine, you can use one of the two methods exemplified below:
- Issue a ping command to the specific website from the command prompt. The website name will automatically be translated into the associated IP address, as depicted in the screenshot below:
Figure 5.10 – Windows DNS Query Test (ping Command)
- Issue an nslookup command from the command prompt. This will return comprehensive details about the DNS records associated with the specific website, which can be seen in the screenshot below:
Figure 5.11 – Windows DNS Query Test (nslookup Command)
The DNS service doesn’t work using a single server because it would not be capable of managing all the name-to-IP mappings on the Internet. Instead, DNS uses a collection of servers that work together to provide name-to-IP resolution. This collection of servers is organized hierarchically using a distributed database composed of multiple DNS servers, which include the following:
- Root servers
- Top-level domain (TLD) servers
- Authoritative servers
- Resolving servers
Usually, a client sends a query to a resolving DNS server first. As DNS servers do not have all the name-to-IP bindings, they use a hierarchical structure to communicate between each other and find the information they need. For example, when a client sends a DNS query for www.cisco.com, the following process occurs:
- The client PC sends the request to the resolving DNS server (the IP address of this server is configured on the PC).
- The resolving DNS server does not have the required information, so it forwards the request to the root server (superior in hierarchy).
- The root server redirects the request to the servers responsible for the .com domains (top-level domain DNS servers).
- The DNS request arrives at the top-level domain DNS server, which forwards it to the authoritative DNS server that specifically handles the cisco.com domain.
- The authoritative DNS server for the cisco.com domain provides the resolving server with the final answer.
- The resolving server caches the information to provide a direct response to future queries.
A simplified DNS hierarchy diagram is depicted in Figure 5.12 below:
Figure 5.12 – DNS Hierarchy
A generic DNS query flows over the path as follows: root name server à TLD server à authoritative server. The authoritative servers contain manually configured IP addresses that represent internal server or services names.
|Note: Resolving DNS servers are the most commonly used DNS server type, as they receive the initial DNS query and initialize the entire hierarchical DNS query flow in order to receive a response for the client.|
From a dimension standpoint, the Internet currently has around 13 root server clusters, 200 generic top-level domains (gTLDs), and 248 country code TLDs (ccTLDs). The most important reasons for using such a hierarchical distributed DNS server structure are redundancy and fault tolerance.
Combining every element presented by each level in the hierarchical DNS structure results in a Fully Qualified Domain Name (FQND), for example, www.cisco.com or mail.yahoo.com. The FQDN identifies a unique service or server.
DNS servers contain entries called resource records, also known as DNS records. All this information forms a database that contains naming, IP addresses, and other details. There are more than 30 DNS record types, but the most commonly used are the following:
- A record: This type represents a standard IPv4 address and is the most commonly used DNS record on the Internet.
- AAAA record: This type represents an IPv6 address (four As because the IPv6 address is four times larger than an IPv4 address: 128 bits vs. 32 bits). AAAA records allow for the use of the same DNS server for storing both IPv4 and IPv6 information, which is simpler than having dedicated DNS servers for IPv4 and IPv6 translations.
- CNAME record: CNAME stands for canonical name and this type of record represents an alias of an existing record (i.e., additional names associated to a host). This is used when you have a single physical server but multiple associated services. For example, a single device might be a mail, a Web, and an ftp server for a small company. Instead of having multiple entries for these services, you can just refer them to a single server. This is useful if you have to change the record in the future because you can do this in a single place instead of affecting multiple entries.
- MX record: MX stands for mail exchange and this type of record determines the host name for an e-mail server (not the IP address). It is often used by e-mail servers looking for other e-mail servers in order to communicate and send messages.
- NS record: The name server (NS) record is used when you have multiple internal DNS servers in an organization and you want to designate where they are located.
- PTR record: PTR stands for pointer record and, unlike a normal DNS lookup, it is useful if you want to perform a reverse lookup from an IP address in order to find the domain name. PTR records are the reverse of A or AAAA records.
|Note: An important thing to note regarding PTR records is that the name used to obtain an IP address might not be the same as the name you get when you reverse from that IP address, because there are often multiple names associated with multiple IP addresses.|
Dynamic DNS (DDNS) is a technique used in situations in which the IP addresses associated with specific names are often modified to prevent a denial of service to those services. If an IP address of a Web server changes, the server will not respond when identified by name because the name-to-IP binding is broken. In order to fix such situations, DDNS updates the DNS server records using a secure, automated process.
Dynamic DNS can be used by both large enterprises and home users. Enterprises might require DDNS because they use DHCP, which prevents servers of interest from having the same IP address over a long period of time. Dynamic DNS functionality is built into the Windows Active Directory and allows the domain’s controllers to register with the DNS and other computers in the domain to find AD services by issuing queries.
From a home-user perspective, DDNS functionality might be needed if the ISP allocates dynamic IP addresses, thus preventing the user from accessing home resources from other locations. An internal device cannot be identified if the public IP address keeps changing, so DDNS solves this issue by having a software application on the device automatically report the new IP to a central DDNS server on the Internet. The public third-party DDNS server creates an entry for each new IP address and this can be accessed at any point in time to access the home network.
|Note: Dynamic DNS functionality is often embedded into home-user routers and it can be easily configured.|
The Dynamic Host Configuration Protocol (DHCP) is a network protocol used by hosts to automatically obtain an IP address and other parameters (e.g., gateway, DNS server, etc.). DHCP is an evolution from the old BOOTP protocol, which was also used for allocating IP addresses but had very limited functionality.
DHCP uses UDP as its Transport Layer protocol and it has a couple of well-known ports associated with it:
- UDP port 67 (on which the server is listening)
- UDP port 68 (used by clients)
DHCP allows a computer to make a request for an IP address when it boots up (or at a later moment). A DHCP server that listens on the well-known port responds with a specific IP address (i.e., a DHCP Offer). The client accepts this and the server sends back an acknowledgement to confirm the allocation. The entire DHCP conversation contains two packets coming from the client side and two packets coming from the server side, as depicted in Figure 5.13 below:
Figure 5.13 – DHCP Process
Going into more detail on the conversation between the client and the server, the following sequence of events is involved in the DHCP allocation process:
- The client sends a DHCP Discover packet using the following parameters:
- Layer 2 Broadcast destination address of FF:FF:FF:FF:FF:FF; the local switch forwards this frame to all other ports so any device on the network will receive it
- Layer 3 destination port: UDP 67 (bootps, DHCP servers are listening on this port)
- Layer 3 source port: UDP 68 (bootpc)
- The DHCP server responds with a DHCP Offer packet, which includes the proposed IP address, using 67 as the source port and 68 as the destination port.
- The client accepts the offer with a DHCP Request packet.
- The server confirms the allocation by issuing a DHCP Acknowledgement packet. It also sends other details like the default gateway address and the DNS server address. All of these parameters are called options and the client receives them from the server as part of the DHCP conversation.
If a Windows client cannot find a DHCP server, it uses an Automatic Private IP Addressing (APIPA) address (e.g., 169.x.y.z), and it cannot communicate with any other device on the network.
|Note: DHCP servers can be configured not only on dedicated machines/servers but also on network devices that support this functionality, e.g. routers and switches.|
Remote Access Protocols
Remote access protocols allow the remote management of network devices, meaning they can obtain console (command line interface) access. This can be done via either an unsecure communication channel, using the Telnet protocol, or a secure communication channel, using the SSH (Secure Shell) protocol. Using either of these two protocols can generate a session at the Application Layer toward a network device, which uses a software client on the management workstation to control the network device that is acting as a Telnet or SSH server.
One of the most commonly used Telnet and SSH software client is a free software utility called PuTTY, which allows a user to initiate a Telnet or SSH session with a network device and obtain control of the command line interface (CLI). The packet capture screenshots presented below illustrate a Telnet and a SSH session initiated by a client, respectively:
Figure 5.14 – Telnet Session (Client to Server)
Figure 5.15 – SSH Session (Client to Server)
From the packet captures presented above, you can see that both Telnet and SSH are considered Application Layer services that require TCP at the Transport Layer and they use the following ports:
- Telnet: TCP port 23
- SSH: TCP port 22
The source port in both cases is a random unallocated port on the client machine. When the session is over, the source port number disappears and the next session will probably use a different one. Analyzing the SSH packet capture, you can also see details regarding the applications used (PuTTY) in the Application Layer information field.
The reverse packet, coming from the server (the managed device) toward the client, will use the high port number as the destination and TCP port 23 or 22 as the source port. This is exemplified only for Telnet in the packet capture screenshot presented In Figure 5.16 below (SSH follows an identical logic):
Figure 5.16 – Telnet Session (Server to Client)
The problem with using Telnet is that all traffic is sent in clear text (unencrypted) over the wire, so it represents a major security risk as a possible attacker could capture the configuration sent/received from the network device. For this reason, SSH should be used instead of Telnet in production environments. SSH provides the same functionality, with the additional feature of encrypting the data.
|Note: SSH is to Telnet what HTTPS is to HTTP.|
Network Time Protocol (NTP) is a protocol used by network devices to synchronize time across the network infrastructure. With NTP, hosts and network devices can make periodic requests to an NTP server (destination port UDP 123) in order to synchronize their internal clocks. Even though the hosts use an unreliable protocol at the Transport Layer, they are still expecting time-related information from the server over UDP.
Most computers have information about NTP servers by default from the factory. Many free public NTP servers are available on the Internet at the moment, but the most exact servers from a time accuracy perspective are GPS-based machines.
|Note: One of the most important functionalities of running NTP across multiple network devices is log synchronization.|
Remote Desktop Protocol (RDP) is a well-known application that runs on TCP port 3389 and allows users to remotely connect and manage a computer. If the RDP service is running on a remotely managed machine, you can run a remote desktop application on the client PC, which makes a request to the RDP server (managed machine) to establish a connection.
Simple Network Management Protocol (SNMP) is an Application Layer protocol that runs over UDP port 161 and is used by network administrators to gather statistics and control network devices. SNMP is used to share management information between network devices, usually between a management workstation and routers, switches, or other devices. SNMP has two components:
- The SNMP server (manager), which is usually a dedicated workstation
- The SNMP agent, which is usually a service on the managed network device
SNMP has evolved during the years and has now reached version 3 (SNMPv3). Network designers and engineers should demand that every environment use SNMPv3, not the older, unsecure SNMP versions (1 and 2), because of the advanced security features it presents. SNMP is used by network administrators and engineers to:
- Control network performance
- Plan scalable enterprise solutions and intelligent services
SNMP accesses detailed information in Management Information Bases (MIBs) and it uses SNMP agents. The MIB is an object-oriented hierarchical database system stored locally on the network device. An MIB entry example is 126.96.36.199.188.8.131.52.1.20.0, with 1 being the root of the MIB tree and 0 being the final leaf.
The SNMP agent is used to send and receive information from the device to the Network Management Station (NMS), and vice versa. In order to do that, different types of SNMP messages are used. The NMS will run some kind of network management software that retrieves and displays the SNMP information in a graphical user interface (GUI) format. The information displayed is used for control, troubleshooting, and planning.
Another SNMP concept is represented by community strings, which are the access control method. A community is basically a password that controls which group of people has access to certain information on the device.
Using SNMP, the administrator can gather reports from the network device regarding parameters like CPU utilization, memory utilization, and interface bandwidth utilization. The managed device contains the SNMP agent and the MIB that stores all the information. Different types of messages are used to relay information from the NMS to/from the managed device (i.e., the monitored device). This is illustrated in Figure 5.17 below:
Figure 5.17 – SNMP Messages
The first message is called Get Request. This is sent to the managed device when the NMS wants to get a specific MIB variable from the SNMP agent that runs on that device. The Get Next Request is used to return the next object in the list after the Get Request message returns a value. The Get Bulk message works only in SNMPv3 environments and it can be used to retrieve a big chunk of data (e.g., an entire table); it also reduces the need to use many Get Request and Get Next Request messages. This reduces overhead on bandwidth utilization on the link.
The Set Request message is also sent by the NMS and is used to set an MIB variable on the agent. The Get Response message is the response from the SNMP agent to the NMS Get Request, Get Next Request, or Get Bulk messages.
A Trap is used by the SNMP agent to transmit unsolicited alarms to the NMS when certain conditions occur (e.g., device failure, state change, or parameter modifications). Different thresholds can be configured on the managed device for different parameters (like disk space, CPU utilization, memory utilization, and bandwidth utilization) and Traps are sent when the defined thresholds are reached. SNMPv3 introduced another message called Inform Request. This is similar to a Trap message and is what a managed device will send to the NMS as an acknowledgement to other messages.
Multiple SNMP versions were developed since SNMP was created, as follows:
- SNMPv1: the initial implementation of the SNMP protocol, which offer limited security via community strings
- SNMPv2c: the revised SNMP version, which includes multiple enhancements but still has limited security functionality via community strings
- SNMPv3: the latest SNMP version, which offers advanced security features, including authentication and encryption; this is the recommended version to be used in production environments
|Note: SNMPv3 is defined by the following RFCs: RFC 2571, RFC 2572, RFC 2573, RFC 2574, and RFC 2575.|
SNMPv3 provides three security levels:
- NoAuthNoPriv: no authentication and no privacy mechanisms
- AuthNoPriv: authentication (MD5, SHA) but no privacy mechanisms
- AuthPriv: the highest level of security; uses authentication (MD5, SHA) and privacy (e.g., DES).
Internet Control Message Protocol (ICMP) is a maintenance protocol that operates at Layer 3 and sends control messages over the network. ICMP is identified as protocol number 1 in the Layer 3 header and it can transmit multiple message types to accomplish different maintenance tasks.
While ICMP has many different functions, the main one is sending Echo Requests to a machine to verify that it is up and running. If the specific machine is operating, it will send an ICMP Echo Reply message back to the source, confirming its availability. This process, also known as a ping, is shown below in Figure 5.18:
Figure 5.18 – ICMP Echo Request and Echo Reply
Figure 5.19 below illustrates an Echo Request packet capture:
Figure 5.19 – ICMP Echo Request
Figure 5.20 below illustrates a reply to the Echo Request:
Figure 5.20 – ICMP Echo Reply
Another ICMP function is determining whether you are trying to access a destination that is not reachable using Destination Unreachable messages. The most commonly used ICMP message types include the following:
- Type 0: Echo Reply
- Type 3: Destination Unreachable
- Type 5: Redirect
- Type 8: Echo Request
- Type 11: Time Exceeded
- Type 30: Traceroute
The Internet Group Management Protocol (IGMP) is used in environments that run Multicast traffic, like video streaming or audio content. IGMP allows Multicast users to subscribe or disconnect from a Multicast stream. In order to understand Multicast protocols, network devices like switches and routers must be Multicast-enabled and properly configured.
The most common networking protocols are as follows:
TCP and UDP functionality has already been analyzed, so we will focus on the ARP protocol in this section.
Address Resolution Protocol (ARP) is a network protocol that allows hosts to learn the Layer 2 address of a device it wants to communicate with by sending a query based on the Layer 3 address of the specific device.
When a host wants to communicate on the network, it does this by having Layer 3 information about the destination device (this may have been learned from a DNS query). In order to send the packet over the communication channel, the host/PC must first use the local Layer 2 address of the destination device and it does this by sending an ARP Request, as follows:
- The PC determines it needs to know the Layer 2 address of a network device (usually the default gateway, which is often a router).
- The PC broadcasts an ARP Request on the wire.
- The switch receives the Broadcast ARP packet and forwards it to all other ports.
- The destination device (router) receives the message, identifies itself in the Destination field, and sends an ARP Reply with its Layer 2 address.
- The PC now knows the router MAC address so it can properly encapsulate Unicast frames toward that device.
Figure 5.21 below exemplifies the ARP Request/Reply behavior:
Figure 5.21 – ARP Process
As depicted in Figure 5.21 above, the process starts with the source device sending a Broadcast ARP Request packet, which contains the IP address of the destination device. The destination device sends a Unicast response back to the source, which contains its own source MAC address, thus offering the missing information.
|Note: On a Windows PC, you can see all known Layer 2 addresses using the arp -a command in a command prompt terminal. This command lists the ARP cache of the machine, which hosts all Layer 3-to-Layer 2 associations for a determined period in order to quickly reuse them without sending further ARP Requests.|
The most common protocols, organized by the TCP/IP layer they operate at, are presented in Table 5.2 below:
Table 5.2 – TCP/IP Layers and Their Protocols
Port numbers are assigned to different protocols and services so that a user will know how and what to access at the other end and to identify specific applications. They are also used to track the session associated with that protocol.
Well-known port numbers are non-ephemeral ports, meaning they are permanently assigned to a protocol or a service. They can be used as a destination port by any network-enabled machine to reach specific protocols. Temporary port numbers are ephemeral ports that are usually used as source ports in a two-way communication process. They are determined in real-time by the client workstation and are usually numbers above 1024.
Configure port numbers and protocols in our 101 Labs – CompTIA Network+ book.