Training Cisco 200-125 CCNA v3.0. Day 6. Fill in the blanks (DHCP, TCP, "handshake", common port numbers)

Original author: Imran Rafai
  • Transfer
  • Tutorial
Before we begin today's video tutorial, I want to thank everyone who contributed to the popularity of my course on YouTube. When I started it about 8 months ago, I did not expect such success - for today 312724 people have looked at my lessons, I have 11208 subscribers. I never dreamed that this modest undertaking would reach such heights. But we will not lose time and immediately move on to today's lesson. Today we fill in the gaps that have occurred in the last 7 video tutorials. Although today is only 6 days, day 3 has been split into 3 video lessons, so in fact today you are watching the eighth video lesson.

Today we will deal with 3 important topics: DHCP, TCP transmission, and the most common port numbers. We have already talked about IP addresses, and one of the most important factors in configuring an IP address is DHCP.



DHCP stands for “Dynamic Host Configuration Protocol,” a protocol that helps dynamically configure IP addresses for hosts. So we all saw this window. When you click on the “get IP address automatically” option, the computer searches for a DHCP server configured on the same subnet and sends various packets and requests for the IP address. DHCP has 6 messages, of which 4 are critical for assigning an IP address.

The first message is a DHCP DISCOVERY discovery message. The DHCP discovery message is like a greeting. When a new device enters the network, it asks if a DHCP server is present on the network.

What you see on the slide looks like a broadcast request, the device code is accessing all devices on the network in search of a DHCP server. As I said, this is a broadcast request, so all network devices hear it.



If there is a DHCP server on the network, it sends a packet - a DHCP OFFER sentence. The proposal means that the DHCP server, in response to the discovery request, sends the configuration to the client, prompting the client to accept a specific IP address.



The DHCP server reserves the IP address, in this case 192.168.1.2, does not provide, namely it reserves this address for the device. At the same time, the offer package contains its own IP address of the DHCP server.

If this network has more than one DHCP server, another DHCP server, having received a broadcast request from the client, would also offer it its IP address, for example, 192.168.1.50. Usually two different DHCP servers are not configured on the same network, but sometimes this still happens. Thus, when a DHCP proposal is sent to the client, it receives 2 DHCP proposals and now must decide which DHCP proposal it wants to accept.

Let's assume that the client accepts the first application. This means that the client sends out a DHCP REQUEST request that literally says: “I accept the IP address 192.168.1.2 offered by the DHCP server 192.168.1.1.”



Upon receipt of the request, the DHCP server 192.168.1.1 replies: “OK, I admit it,” that is, it confirms the request and sends this DHCP ACK confirmation to the client. But we remember that another DHCP DHCP server reserved an IP address of 1.50 for the client. Upon receiving the client’s broadcast request, he learns about the failure and puts this IP address back into the pool so that he can assign it to another client if he receives another request.



These are the 4 critical messages that DHCP exchanges at the beginning of the IP address assignment. Further, DHCP has 2 more information messages. An informational message is issued by the client if he needs more information than he received in the DHCP OFFER sentence in the second step. If the DHCP server did not provide enough information in the DHCP proposal, or if the client needs more information than the one contained in the proposal packet, it requests additional DHCP information. There is another message that the client sends to the server - this is the release of DHCP RELEASE. It states that the client wants to free his existing IP address.

However, most often it happens that the user disconnects from the network before the client manages to send DHCP RELEASE to the server. This happens when you turn off the computer, which we carry out. At the same time, the network client, or computer, simply does not have time to inform the server about the release of the used address, so DHCP RELEASE is not an obligatory step. The required steps to obtain an IP address are: DHCP discovery, DHCP offer, DHCP request, and DHCP confirmation.

In one of the following lessons I will tell you how we configure a DHCP server when creating a DNCP pool. By pool is meant that you are informing the server of the assignment of IP addresses in the range from 192.168.1.1 to 192.168.1.254. Thus, the DHCP server will create a pool, place 254 IP addresses in it, and will be able to assign network clients addresses from this pool only. So this is something like an administrative setting that a user can do.

Now consider the transmission of TCP. I don’t know if you are familiar with the “telephone” shown in the picture, but as a child, we used such cans connected by a cord to talk to each other.



Unfortunately, the current generation cannot afford such "luxury." I mean, today children are in front of the TV from the age of one, they play PSP, and maybe this is a moot point, but I think we had a better childhood, we really went outside and played games, and you cannot tear today's children off the couch.

My son is only one year old, and I already see that he is addicted to the iPad, I mean that he is still very small, but it seems to me that today's children are already born with knowledge of how to handle electronic gadgets. So, I wanted to say that in childhood, when we played, we were tearing cans, and when they tied them with a string and said something in one can, on the other end a person could hear what they were saying, just putting a can in his ear . So this is very similar to a network connection.

Today, even for TCP transmission, there must be a connection that must be established before the actual data transfer begins. As we discussed in previous lessons, TCP is a transmission focused on pre-establishing a connection to the network, while UDP is a transmission without the need to establish a connection. You can say that UDP is when I throw the ball, and it depends on you whether you can catch it. Are you ready to do it or not, this is not my problem, I'm just going to give it up.

TCP is more like talking to a guy and warning him in advance that you are going to throw the ball, that is, a connection is made between you, and only then you throw the ball, so it is very likely that your partner will be ready to catch him. Thus, TCP actually builds a connection, and then begins to carry out a real transfer.

Consider how it creates such a connection. To create a connection, this protocol uses a 3-step handshake. This is not a very technical term, but it has long been used to describe a TCP connection. A 3-step handshake is initiated by the sending device, and the client sends a packet with the SYN flag to the server.

Suppose that the girl in the foreground whose face we can see is device A, and the girl in the background whose face is not visible is device B. Girl A sends a SYN packet to girl B, and she says: “great, someone he wants to talk to me. So I need to answer that I'm ready for communication! ” How to do it? One could simply send back another SYN packet and then an ACK acknowledgment indicating receipt of the original SYN packet. But instead of sending the ACK separately, the server forms a common packet that contains the SYN and ACK and transmits it over the network.



So, at the moment, device A sent a SYN packet and received back a SYN / ACK packet. Now device A should send ACK to device B, that is, confirm that it has received the consent of device B to establish communication. Thus, both devices received SYN and ACK packets, and now we can say that the connection is established, that is, a 3-stage handshake via TCP is implemented.



Next, we will look at TCP Windowing technology. Simply put, this is the method used by TCP / IP to negotiate the capabilities of the sender and receiver.



Suppose that on Windows we are trying to transfer a large file, say, 2 GB in size, from one drive to another. At the very beginning of the transfer, the system will tell us that the file transfer will take about 1 year. But a few seconds later, the system will recover and say: "Oh, wait a minute, I think it will take not 6 months, but about 6 months." A little more time will pass, and Windows will say: “I think that maybe I can transfer the file in 1 month.” Then the message “1 day”, “6 hours”, “3 hours”, “1 hour”, “20 minutes” "," 10 minutes "," 3 minutes. "In fact, the whole process of transferring a file will take only 3 minutes. How did it happen? Initially, when your device tried to contact another device, it sends one packet and waits for confirmation. If the device is waiting confirmation for a long time, it thinks: "If I have to transfer 2 GB of data at that speed, then it will take about 2 years." After some time, your device receives the ACK and thinks: “OK, I sent one packet and received the ACK, therefore, the recipient can receive 1 packet. Now I will try to send him 10 packets instead of one. " The sender sends 10 packets and after some time receives an ACK confirmation from the receiving device, which means that the recipient is waiting for the next 11th packet. The sender thinks: “excellent, since the recipient immediately coped with 10 packets, now I will try to send him 100 packets instead of ten.” He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases. After some time, your device receives the ACK and thinks: “OK, I sent one packet and received the ACK, therefore, the recipient can receive 1 packet. Now I will try to send him 10 packets instead of one. " The sender sends 10 packets and after some time receives an ACK confirmation from the receiving device, which means that the recipient is waiting for the next 11th packet. The sender thinks: “excellent, since the recipient immediately coped with 10 packets, now I will try to send him 100 packets instead of ten.” He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases. After some time, your device receives the ACK and thinks: “OK, I sent one packet and received the ACK, therefore, the recipient can receive 1 packet. Now I will try to send him 10 packets instead of one. " The sender sends 10 packets and after some time receives an ACK confirmation from the receiving device, which means that the recipient is waiting for the next 11th packet. The sender thinks: “excellent, since the recipient immediately coped with 10 packets, now I will try to send him 100 packets instead of ten.” He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases. Now I will try to send him 10 packets instead of one. " The sender sends 10 packets and after some time receives an ACK confirmation from the receiving device, which means that the recipient is waiting for the next 11th packet. The sender thinks: “excellent, since the recipient immediately coped with 10 packets, now I will try to send him 100 packets instead of ten.” He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases. Now I will try to send him 10 packets instead of one. " The sender sends 10 packets and after some time receives an ACK confirmation from the receiving device, which means that the recipient is waiting for the next 11th packet. The sender thinks: “excellent, since the recipient immediately coped with 10 packets, now I will try to send him 100 packets instead of ten.” He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases. now I’ll try to send him 100 packets instead of ten. " He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases. now I’ll try to send him 100 packets instead of ten. " He sends 100 packets, and the recipient replies that he has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases.

That is why you see a rapid decrease in file copy time compared to the originally stated - this is due to an increase in the ability to transfer a large amount of data. However, there comes a point when a further increase in transmission volume becomes impossible. Suppose you have sent 10,000 packets, but the receiver’s device buffer is capable of receiving only 9,000. In this case, the recipient sends an ACK with the message: “I have received 9000 packets and am now ready to receive 9001”. From this, the sender concludes that the buffer of the receiving device has a capacity of only 9000, which means that from now on I will send no more than 9000 packets at a time. In this case, the sender quickly calculates the time it will take him to transfer the remaining amount of data in portions of 9000 packets, and gives out 3 minutes. These three minutes are the actual transmission time. This is what TCP Windowing does.

This is one of those traffic control mechanisms where the transmitting device over time understands what the actual network bandwidth is. You may wonder why they cannot agree in advance on what is the capacity of the receiving device? The fact is that this is technically impossible, because there are various types of devices on the network. Suppose you have an iPad, and its data transfer / reception speed is different from the iPhone, you may have different types of phones, or maybe you have a very old computer. Therefore, everyone has different network bandwidth.

Therefore, TCP Windowing technology was developed when data transfer begins at a low speed or with a minimum number of packets, gradually increasing the traffic window. You send one packet, 5 packets, 10 packets, 1000 packets, 10000 packets and slowly open this window more and more until the “expansion” reaches the maximum possible value of sending the volume of traffic in a specific period of time. Thus, the concept of Windowing is part of the TCP protocol.

Next, we will look at the most common port numbers. The classic situation is when you have 1 main server, perhaps this is a data center. It includes a file server, a web server, a mail server, and a DHCP server. Now, if one of the client computers contacts the data center, which is located in the middle of the picture, it will start sending file server traffic to client devices. This traffic is shown in red, and a specific port for a specific application from a specific server will be used to transmit it.



How did the server know where certain traffic should go? He will find out from the destination port number. If you look at the frame, you will see that in each data transfer there is a mention of the destination port number and the source port. You see that blue and red traffic, and blue traffic is web server traffic, both arrive on the same physical server, in which different servers are installed. If it is a data center, then it uses virtual servers. So how did they know that the red traffic was supposed to return to this left laptop with this IP address? They know this thanks to the port numbers. If you refer to the Wikipedia article “TCP and UDP Port List”, you will see that it lists all the standard port numbers.



If you scroll this page, then you can see how big this list is. It contains approximately 61,000 rooms. Port numbers from 1 to 1024 are known as the most common port numbers. For example, port 21 / TCP is for transmitting ftp commands, port 22 for ssh, port 23 for Telnet, that is, for transmitting unencrypted messages. The very popular port 80 is used to transmit data via HTTP, and port 443 is used to transmit encrypted data via HTTPS, which is similar to the secure version of HTTP.
Some ports are designed for TCP and UDP at the same time, and some perform different tasks depending on which connection is used - TCP or UDP. So, officially port 80 TCP is used for HTTP, and unofficially port 80 UDP is used for HTTP, but using a different HTTP protocol - QUIC.



Therefore, port numbers in TCP are not always designed for the same as in UDP. You do not need to learn this list by heart, it is impossible to remember it, but you need to know some popular and most common port numbers. As I said, some of these ports have an official purpose, which is described in the standards, and some have an unofficial purpose, as is the case with Chromium.

So, this table lists all common port numbers, and these numbers are used to send and receive traffic when using specific applications.

Now let's look at how data moves on the network based on the little information we know. Suppose that the computer 10.1.1.10 wants to contact this computer, or this server, which has the address 30.1.1.10. Under the IP address of each device is its MAC address. I give as an example a MAC address with only the last 4 characters, but in practice it is a 48-bit hexadecimal number with 12 characters. Since each of these numbers consists of 4 bits, 12 hexadecimal digits represent a 48-bit number.



As we know, if this device wants to contact this server, the first step of the 3-stage handshake must be done first, that is, a SYN packet is sent. When creating this request, the computer 10.1.1.10 will indicate the source port number, which Windows creates dynamically. Windows randomly selects a port number between 1 and 65,000. But since the starting numbers in the range from 1 to 1024 are widely known, in this case the system will consider the numbers greater than 25000 and create a random source port, for example, under the number 25113.

Then the system will add the destination port to the packet, in this case port 21, because the application that is trying to connect to this FTP server knows that it must send FTP traffic.

Further, our computer says: “OK, my IP address is 10.1.1.10, and I need to contact the IP address 30.1.1.10.” Both of these addresses are also included in the packet, forming a SYN request, and this packet will not be changed until the end of the connection.

I want you to understand from this video how data moves across the network. When our computer sending the request sees the source IP address and the destination IP address, it understands that the destination address is not in this local network. I forgot to say that these are all / 24 IP addresses. So if you look at the IP addresses / 24, you will understand that computers 10.1.1.10 and 30.1.1.10 are not on the same network. Thus, the sending computer understands that in order to exit this network, it must turn to the gateway 10.1.1.1, which is configured on one of the router interfaces. He knows that he must go to 10.1.1.1, and knows his MAC address 1111, but does not know the MAC address of the gateway 10.1.1.1. What is he doing? It sends a broadcast ARP request that all devices on the network will receive, but only a router with an IP address of 10.1 will respond to it.



The router will reply with its AAAA MAC address, and both the source and destination MAC addresses will also be placed in this frame. Once the frame is ready, before leaving the network, a CRC data integrity check will be performed, which is an algorithm for finding the checksum in order to detect errors.
The cyclic redundant CRC code means that this entire frame, from SYN to the last MAC address, is run through a hash algorithm, say MD5, resulting in a hash value. Then the hash value, or MD5 checksum, is placed at the beginning of the frame.



I designated it FCS / CRC because FCS is a frame check sequence, a four-byte CRC value. Some people use the designation FCS, and some use the CRC, so I just indicated both designations. But basically this is just a hash value. It is necessary in order to make sure that all the data coming through the network does not contain errors. Therefore, when this frame reaches the router, the first thing the router will do is calculate the checksum on its own and compare it with the FCS or CRC value that the received frame contains. Thus, he will be able to verify that the data received over the network does not contain errors, after which he will remove the checksum from the frame.

Next, the router will look at the MAC address and say: “OK, the AAAA MAC address means that the frame is addressed to me”, and will delete the part of the frame containing the MAC addresses.



Looking at the destination IP address 30.1.1.10, he will understand that this packet is not addressed to him and must go further through the router.

Now the router is “thinking” about whether it needs to see where the network is located with the address 30.1.1.10. We have not yet considered the full concept of routing, but we know that routers have a routing table. This table has an entry for the network with the address 30.1.1.0. As you recall, this is not a host IP address, but a network identifier. The router will “think” that it is possible to reach the address 30.1.1.0/24 by going through the router 20.1.1.2.

You may ask, how does he know this? Just keep in mind that he will learn about this either from the routing protocols, or from your settings if you, as an administrator, have configured a static route. But in any case, the routing table of this router contains the desired entry, so he knows that he must send this packet to 20.1.1.2. Assuming that the router already knows the destination MAC address, we just continue forwarding the packet. If he does not know this address, he will start ARP again, get the MAC address of the router 20.1.1.2, and the process of sending the frame will continue again.

So, we assume that he already knows the MAC address, then we will have the source MAC address of BBB and the destination MAC address of CCC. The router again calculates FCS / CRC and places it at the beginning of the frame.



Then it sends this frame over the network, the frame reaches the router on 20.1.12, it checks the checksum, makes sure that the data is not corrupted, and removes FCS / CRC. Then he "cuts off" the MAC address, looks at the destination and sees that it is the address 30.1.1.10. He knows that this address is connected to his interface. The same process of frame formation is repeated, the router adds the MAC addresses of the source and destination, hashes, attaches the hash to the frame and sends it over the network.



Our server, having finally received a SYN request addressed to it, checks the hash checksum, and if the packet does not contain errors, it removes the hash. Then he removes the MAC addresses, looks at the IP address and realizes that this packet is addressed to him.
After that, it trims the IP addresses related to the third level of the OSI model and looks at the port numbers.



He sees port 21, which means FTP traffic, sees SYN and therefore realizes that someone is trying to establish a connection with him.

Now, in accordance with what we learned about the handshake, server 30.1.1.10 creates a SYN / ACK packet and sends it back to computer 10.1.1.10. Upon receiving this packet, device 10.1.1.10 will create an ACK, pass it through the network in the same way as the SYN packet, and after receiving the ACK by the server, the connection will be established.

One thing you need to know is that it all happens in less than a second. This is a very, very fast process, which I tried to slow down so that you could understand everything.
I hope what you learned from this tutorial comes in handy. If you have questions, write to me at imran.rafai@nwking.org or post questions under this video.

Starting from the next lesson, I will select 3 of the most interesting questions from YouTube, which I will consider at the end of each video. From now on, I will have the “Best Questions” section, so I will post the question with your name and answer it live. I think it will benefit.


Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending it to your friends, a 30% discount for Habr users on a unique analogue of entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until the summer for free when paying for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only we have 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $ 99! Read about How to Build Infrastructure Bldg. class using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

Also popular now: