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

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

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 a success - for today, my lessons were watched by 312724 people, I have 11208 subscribers. I never dreamed that this humble undertaking would reach such heights. But let's not waste time and immediately move on to today's lesson. Today we fill in the gaps that occurred in the last 7 video tutorials. Although today is only 6 days, day 3 was divided into 3 video tutorials, so in fact today you watch the eighth video tutorial.

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

DHCP stands for “Dynamic Host Configuration Protocol,” a protocol that helps you 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 sending various packets and requests for the IP address. DHCP has 6 messages, of which 4 are crucial for assigning an IP address.

The first message is a DHCP DISCOVERY discovery message. A DHCP discovery message is similar to a greeting. When a new device enters the network, it asks if there is a DHCP server on the network.

What you see on the slide looks like a broadcast request, the device code accesses all devices on the network looking for a DHCP server. As I said, this is a broadcast request, so all devices on the network can hear it.

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

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

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

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

Upon receiving the request, the DHCP server responds: “OK, I admit it,” that is, confirms the request and sends this DHCP ACK acknowledgment to the client. But we remember that another DHCP server DHCP reserved a client IP address 1.50 for the client. After receiving a broadcast client request, he will find out about the failure and put 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 assignment of IP addresses. Next, DHCP has 2 more informational messages.An informational message is issued by the client if he needs more information than he received in the DHCP OFFER clause in the second step. If the DHCP server does not provide enough information in the offer, or if the client needs more information than the one contained in the offer package, 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 release his IP address.

However, it most often happens that the user is disconnected from the network before the client has time to send a DHCP RELEASE to the server. This happens when you turn off the computer, which we carry with you. At the same time, the network client, or computer, simply does not have the 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 acknowledgment.

In one of the following lessons, I will tell you how we set up a DHCP server when creating a DNCP pool. A pool means that you tell the server about the assignment of IP addresses in the range from to Thus, the DHCP server will create a pool, place 254 IP addresses in it and will be able to assign addresses to the network clients only from this pool. So this is something like an administrative setting that a user can make.

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

Unfortunately, today's generation cannot afford such “luxury”. I mean, today children are in front of the television from the age of one year old, they play PSP, and this may be a controversial issue, but I think we had a better childhood, we really went outside and played games, and You can't tear today's kids off the couch.

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

Today, even for TCP transmissions, 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 that is focused on pre-establishing a connection to a network, while UDP is a transmission without the need to establish a connection. We can say that UDP is when I throw the ball, and it depends on you if you can catch it. Are you ready to do it or not, this is not my problem, I'm just going to quit it.

TSP 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 being made between you, and only then you throw the ball, so that your partner is likely to be ready to catch it. Thus, TCP actually builds the connection and then starts the actual transfer.

Consider how he 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 TCP connections. A 3-step handshake is initiated by the sending device, and the client sends a packet with a 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, who- he wants to talk to me. So, I need to answer that I am ready to communicate! ”How to do this? One could simply send back another SYN packet and then an ACK acknowledgment indicating that the original SYN packet has been received. But instead of sending ACK separately, the server generates a common packet, which contains the SYN and ACK, and sends it over the network.

So, for now, device A has sent a SYN packet and received a SYN/ACK packet back. Now device A should send an ACK packet to device B, that is, confirm that it received device B's consent to establish a connection. Thus, both devices received the SYN and ACK packets, and now it can be said that the connection is established, that is, a 3-stage handshake is made using the TCP protocol.

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

Suppose that on Windows we are trying to transfer a large file, say 2 GB, from one disk to another. At the very beginning of the transfer, the system will inform us that the transfer of the file will take approximately 1 year. But a few seconds later, the system will correct itself and say: “oh, wait a minute, I think it will take not a year, but about 6 months”. It will take a little more time, and Windows will report: "I think I may be able to 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 takes only 3 minutes. How did that 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 complete the transfer of 2 GB of data at that speed, then this It has been around for about 2 years. ”After some time, your device receives an ACK and thinks:“ OK, I sent one packet and received an 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 a confirmation from the receiving device ACK, which means that the recipient expects the next, 11th packet. The sender thinks: “fine, since the recipient coped immediately with the 10th packet, now I will try to send him 100 packages instead of ten. He sends 100 packets, and the recipient replies that he 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 the file copying time compared to what was initially stated - this is due to the increased possibility of transferring large amounts of data. However, there comes a time when a further increase in the volume of transmission 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 9,000 packets and is 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 takes him to transfer the remaining amount of data in batches of 9000 packets, and gives 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 eventually understands what the actual network capacity is. You may ask why they cannot agree in advance on what is the capacity of the receiving device? The fact is that it is technically impossible, because there are various types of devices on the network. Suppose you have an iPad, and its data transfer/receive speed is different from the iPhone, you may have different types of phones, or maybe you have a very old computer. Therefore, everyone has a different network bandwidth.

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

Next we 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 send it.

How did the server know where certain traffic should go? He will know about it from the destination port number. If you look at the frame, you will see that in each data transfer there is a reference to the destination port number and the source port. You can see that blue and red traffic, and blue traffic is the traffic of the web server, both coming to the same physical server, where different servers are installed. If it is a data center, then it uses virtual servers. So how did they know that the red traffic should have returned to this left laptop with this IP address? They know this thanks to the port numbers. If you refer to the Wikipedia article "List of TCP and UDP ports", you will see that it lists all the standard port numbers.

If you scroll through 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 sending ftp commands, port 22 is for ssh, port 23 is for Telnet, that is, for sending unencrypted messages. Very popular port 80 is used to transmit data over HTTP, and port 443 is used to transmit encrypted data over HTTPS, which is similar to the secure version of HTTP.
Some ports are designed for both TCP and UDP, 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 another HTTP protocol - QUIC.

Therefore, port numbers in TCP are not always intended to be the same as in UDP. You do not need to learn this list by heart, it is impossible to remember it, but you should know some popular and most common port numbers. As I said, some of these ports have a formal purpose, which is described in the standards, and some - an informal purpose, as in the case of 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 take a look at how data travels online, based on the little information we know. Suppose that computer wants to connect to this computer, or this server, which has an address of Under the IP address of each device is its MAC address. I give an example of 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, the 12 hexadecimal digits are a 48-bit number.

As we know, if this device wants to connect with 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, computer will indicate the source port number that Windows creates dynamically. Windows randomly selects a port number in the range from 1 to 65,000. But since the initial numbers in the range from 1 to 1024 are widely known, in this case the system will consider numbers greater than 25000 and will create a random source port, for example, with the number 25113.

Next, 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.

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

I want you to understand from this video how data travels over a network. When our sending computer sees the source IP address and destination IP address, it understands that the destination address is not on 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 and are not on the same network. Thus, the sending computer of the request understands that in order to leave this network, it must contact the gateway, which is configured on one of the interfaces of the router. He knows that he should go to, and knows his MAC address 1111, but does not know the MAC address of the gateway What does he do? It sends a broadcast ARP request that all devices on the network will receive, but only the router with the IP address will respond to it.

The router will respond with its AAAA MAC address, and both MAC addresses — the source and destination — will also be placed in this frame. As soon as the frame is ready, before you leave the network, a CRC data integrity check will be performed, which is an algorithm for finding the checksum to detect errors.
The cyclic redundancy code CRC means that the entire frame, from the SYN to the last MAC address, is run through a hashing algorithm, say, MD5, which results in a hash value. Then the hash value, or MD5 checksum, is placed at the beginning of the frame.

I labeled 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 in principle, this is just the hash value. It is necessary in order to make sure that all data coming over 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 contains the received frame. This way, 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: “Well, 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, he will understand that this packet is not addressed to him and must go through the router further.

Now the router "thinks" about how he needs to see where the network is located with the address We have not yet considered the complete concept of routing, but we know that routers have a routing table. In this table there is an entry for the network with the address As you remember, this is not the IP address of the host, but a network identifier. The router “thinks” that it is possible to reach the address, passing through the router

You may ask, how does he know this? Just keep in mind that he will find out about this either from the routing protocols or from your settings if, as an administrator, you 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 Assuming the router already knows the destination MAC address, we simply continue to forward the packet. If he does not know this address, then he will launch ARP again, get the MAC address of the router, and the frame sending process will continue again.

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

Then it sends this frame over the network, the frame reaches the router 20.1.12, it checks the checksum, makes sure that the data is not damaged, and deletes the FCS/CRC. Then he "cuts off" the MAC address, looks at the destination and sees that it is the address He knows that this address is connected to his interface. The same framing process is repeated, the router adds the source and destination MAC address values, does the hashing, attaches a hash to the frame and sends it over the network.

Our server, having finally received a SYN request addressed to it, checks the checksum of the hash, and if the packet contains no errors, deletes the hash. Then he removes the MAC address, looks at the IP address and realizes that this packet is addressed to him.
After that, it truncates the third-level OSI IP addresses and looks at the port numbers.

He sees port 21, which means FTP traffic, sees SYN and therefore understands that someone is trying to communicate with him.

Now, according to what we learned about the handshake, server creates a SYN/ACK packet and sends it back to the computer Upon receiving this packet, the device 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 - 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 you find what you have learned from this lesson useful. If you have questions, email me at imran.rafai@nwking.org or leave questions under this video.

Starting with the next lesson, I will select the 3 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 be beneficial.

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 to friends, 30% discount for Habr users on a unique analogue of the 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 share the server? (options with RAID1 and RAID10 are available , up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps before the summer is free if you pay for half a year, you can order here .

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

Source text: [Translation] Training Cisco 200-125 CCNA v3.0. Day 6. Fill in the blanks (DHCP, TCP, “handshake”, common port numbers)