Last time, we settled on the fact that the advent of fast Internet led to the rapid growth of our local area network (LAN). It so happened that the network was divided into two IP ranges, which provided access to different resources, but were in the same L2 broadcast domain. Relatively speaking, we used the network 192.168.0.0-192.168.0.255 and 192.168.1.0-192.168.1.255. Computers with an address from one network did not have access to the second, but shared cables. By the way, one of the ranges worked with the DHCP server, and the second only with static addresses. Both network was routed to the one shared Internet gateway. As the hardware base, we used various switches working only with twisted pair, and separate devices for converting electrical signals from twisted pair into optical signals for optical fiber - Optical Converters. At first, everything even worked...

Pay attention to how much space this design takes.
With the increasing number of computers in the network, the flow of broadcast traffic between them is growing. As a result, the transmission of "useful information" remains less and less network bandwidth. Gradually, the network simply began to work very slowly. Moreover, it happened like an avalanche. Let's figure out the reasons.
The first reason. A large network with a large number of intermediate switches between hosts. According to the map, this is about 3 km and up to 9 switches per line. Switches very well help direct traffic only to those parts of the network to which it is addressed, but for this they have to analyze the beginning of each network packet, and this takes time. That is, each switch transmits information further with a delay. The more switches, the greater the delay.
The second reason is the broadcast traffic that every computer generates. I ran a test on virtual machines. About 200 virtual machines, most of which are idle (just running), generate 980 packets of broadcast and multicast traffic in 3 minutes (with a working DNS server for local names). Let's take a closer look at what gets into broadcast traffic.
Every time you turn it on, the computer wants to start using the LAN. To do this, it needs an address. It has one address - MAC. But it does not allow you to take advantage of all the charms of Facebook and YouTube. It need an IP address. If the computer does not manually configure a static IP address, then when it is turned on, it will start sending requests to the network for its issuance by a special DHCP server. Since the computer does not know where the DHCP server is located, it sends requests using broadcast packets. This means that they will reach every computer in the network. And only the DHCP server should answer them. You can imagine it as follows. When a person wakes up, he picks up the loudspeaker and shouts out the window: "I, John Smith, wake up, what is my IP address?" And some specialist calls him later and says his IP address. However, before this, the same specialist himself uncovers the loudspeaker and yells at him: "Is there anyone with an IP address like that?" The cries of each such John Smith are heard by everyone. It is good that they get up, as a rule, only once a day.
But that is not all. After the computer has received its IP address and the ability to communicate with other computers in the network, it begins to get to know everyone. It takes out his loudspeaker and yells out the window again: “Hello! My name is John Smith! My IP address is 192.168.0.145! ” This is necessary so that we do not later ask everyone what his address is, but immediately write to this address. Still, the computer can decide that its kung fu is better than everyone else and arrange the election of the Chief of the network. Then a few more messages are added. The main computer on the network is needed so that everyone asks for the addresses of other computers.
And that is not all. Smart programs send messages by computer name or IP address. And for the stupid transmission of messages by wire, you need to know their MAC addresses. First, you need to find out the IP address of the recipient. If we know only his name, then we need to ask someone who knows what his IP is. In a good case, this is done by the DNS server. If it is exists in the LAN, then a request is sent to it personally. Not to everybody at once, namely one server. In a bad case, you have to shout again at the loudspeaker: "Who is SmithPC?" And wait for an answer. Well, at least the answer comes personal. And then, when we find out the IP address and find out where the message packet will go (to the router or directly to the addressee), we need to find out its MAC address. Because without it we can’t send anything. And we look - do we know the MAC address of the IP address of interest to us. If not, we shout to everyone and ask for it. And so does every computer on the network. A packet from one switch reaches all the others.
In our case, this overlapped with a not-so-fast network - 100 Mbps. This speed has been used everywhere. Most likely, between the switches because of this, "congestion" formed. You can compare this with a small highway - one lane in each direction. And on this highway there are villages in which 24 roads join the highway. While there are few cars, everything works fine. But the more cars, the more the highway between the villages is loaded. At some point, all the village roads will get stuck in traffic jams. Has someone started downloading a file from the server? The rest will experience network problems at this time.
And finally, another problem is the network loops. When the network is not divided into segments, and the switches are not very smart, then it is likely that the network will be completely “put down” by connecting one of the switches to itself. In this case, it will begin to multiply the number of broadcast packets exponentially. That is, very soon the entire network will be occupied by copies of the same packets made by the loop in the network. And the network will not be able to transmit anything else.
How scary! We will wait for the third part to find out what we have done with it.






