ARP inverse process-RARP Protocol process

The RARP protocol is opposite to the ARP protocol. We will also present the specific rules here. We hope to make a comparison with the ARP Protocol process, which will certainly help you. The ARP protocol we just introduced is to find the physical address by querying the network. The RARP protocol we will discuss next is the opposite: it gets its IP address by querying other hosts on the network..

Usually, when we use the ethernet card, a manufacturer will burn the physical address of the NIC in the ROM at the factory time. This address cannot be changed (some models of the network card, or through other technical means allow you to modify the object address ). Regardless of whether the system is up or not, this address will exist and it is easy for the system to obtain it. However, in some diskless) on the workstation, the system files are stored on the remote server. When it is started, it cannot communicate with the server because it does not have an IP address, and cannot load the system files. Then, we must have a way for such a non-disk workstation to obtain its IP Protocol address before communicating with the server. The RAPR Protocol was designed to solve this problem.

Like the ARP protocol, RARP also queries the IP Protocol address in the form of broadcast, but the IP Protocol address is not someone else. We can see that the operation of RARP is actually very similar to ARP:

RARP Query

RARP Query Process

First, the query host sends an RARPRequest broadcast packet to the network, and queries its own IP address from other hosts. At this time, The RARP server on the network will send the IP address of the sender to the queryer in a RARPReply packet. In this way, you can obtain the IP address of the host.

However, unlike ARP, the query host may get more than one RARPReply after dropping the RARPRequest package (In ARP query, we can be sure that only one response will be obtained ). Because there may be more than one RARP server on the Network (designed based on backup and sharing considerations), all servers that receive RARP requests will attempt to respond to the query host RARPReply. In this case, the network will be flooded with this RARP response, making it an additional load. At this time, we have two ways to solve the RARP response problem.

The first method is to allocate a master server to each host that initiates the RARP request. Normally, only the master server responds to the RARP request. Other hosts only record the time when the RARP request was received.. If the master server cannot respond smoothly, the query host sends the RARP protocol request again in broadcast mode while waiting for the Failover. If other non-master servers receive the same request within a short time after receiving the first request then, the response will be made.

The second method is similar: Normally, when the primary server receives an RARP request, it will directly respond to the primary server to prevent all non-primary servers from returning the RARP response at the same time. Each non-primary server will wait for a period of time to respond. If the master server fails to respond, the query host will be delayed for a period of time before the second request is made to ensure that the response from the non-master server is received during this period of time. Of course, designers can carefully design the delay time to a reasonable interval.

PROXY ARP

Proxy ARP is usually used to answer questions on a vro.