RIP Protocol Processing

The operation process of the RIP Protocol is the process in which the router software processes the message input and output. The input and output processes are roughly described as follows:

(1) Input Processing: mainly refers to the processing of the data packets received by the router protocol software on UDP port 520. For input processing, you must first perform a certain format check, and then perform corresponding processing on several input messages after the check is passed.

Request Message: When a vro starts running, a request is usually sent to obtain the initial value of the route table from a neighboring machine. The Command field of the message is (request ). Requests to all or some route tables are generally sent from UDP port 520 as a broadcast. In reality, such a request has two formats: request to get the entire route table and request to get some specific route entries in the route table.

The routing software processes requests one by one. If there is no route entry, no response is returned. If there is only one route entry in the request, and the address family identifier is 0, the metric is 16, the receiver needs to send requests from all route tables. In addition, some routes are required. The processing is simple. You can view the route entries one by one in the request route entry table. For each route entry, search in the host route database. If yes, enter the metric value of the route into the metric field of the datagram. If no, enter 16 in the field. Once all route entries have been processed, set the command field to response and send the datagram back to the source port.

Note that the request processing varies depending on whether the request is about a specified batch of destinations or the entire route table. For the entire route table, the output can be processed normally, including horizontal segmentation and subnet hiding. Therefore, some route entries from the route table are hidden. For a specified route entry, returns the search result without horizontal segmentation. If necessary, returns the subnet information.
2. Response Message: the response is received because of specified query, route modification, and other reasons.

Whatever the response is received, the RIP handler starts to update its route table. Each entry of a route table must at least include the following:
· Target site address;
· Metric value to the target site;
· "Next vro" address;
· "Updated recently" logo;
· Several timers.

Because the processing response may modify the host route table, strict validity checks must be performed. For the RIP Veon1 datagram, the must be zero domain must be checked for zero processing, and the RIP Version2 datagram can be ignored. After the datagram verification is valid, verify the route entries one by one. After all the data passes, we set metric = MIN (metric + cost, 16). 16 represents an infinite length, and then checks whether an existing route has arrived at this address. If not, add it to the route table, however, if metric is infinitely long, do not add it to the route table. If the existing route is no worse than the new route, we will not add it to the route table. To do this, perform the following actions:
· Set the destination and metric based on the received Datagram
· Set A Router Based on the source host of the datagram
· Set a timeout value for the route. If the garbage collection timer is running, stop it.
· Set the route change flag to send a signal to the output process and trigger a modification.

If there is an existing route, first compare the router. If it comes from the same router, reinitialize the timeout value and then compare metric. If the datagram comes from the same vro as the existing route and the new metric value is different from the old one, or the new one is lower than the old one, perform the following actions:
· Fill in the new metric and set the vro as the source of the datagram
· Timeout value for Route Initialization
· Set the route change flag to send a signal to the output process and trigger a modification.
· If the new metric is 16, start the deletion process (only when metric is set to 16)
· If the new metric value is equal to the old one, nothing except the reinitialization timeout value

(2) Output Processing: This process is used to generate response information that contains all or part of the route table. It may be triggered when the input process discovers a request or modifies the route.

First, let's look at how to select the destination address in the last two cases. If a response is sent to all destinations, the response is sent to the peer end of the network connected to each point-to-point, and the response is broadcast on the network that supports broadcast. However, if the network does not support broadcast or is in a silent vro, it is necessary to specify an actual near host and vro table to explicitly send a datagram to each. The modification triggered must be handled in two ways:

First, modifications triggered may cause extra loads on networks with limited capacity or many routers. Therefore, the Protocol requires the implementer to take certain measures to limit the frequency of triggering changes, after sending a trigger modification, You need to randomly set a timer to 1 to 5 seconds. If other modifications occur before the timer times out, one of them must be triggered only when the timer times out, the timer is then randomly set to 1 to 5 seconds, and the triggered modification may be forbidden by the general modification;

Second, the entire route table does not need to be included in the trigger modification. In principle, only the changed routes need to be included. The information as part of the trigger modification includes at least the routes with the route modification flag set, it can also include additional routes and all routes. If the complete modification requires more than one datagram, it is very likely that all the routes will be interrupted. In the triggered modification process, each directly connected network information needs to be generated. Horizontal splitting is required for trigger modifications or general modifications.

If both output and input processing are allowed, a mutex mechanism must be established to generate a triggered modification. when the information is changed, the route change Mark cannot be changed because of the input. The only difference between the trigger modification and other modifications is that some changed routes may be ignored, and other mechanisms introduced in the future may need to adapt to the trigger modification.

Related Articles]

• Changes in the RIP Protocol topology-convergence

• RIP Distance Vector Algorithm

• The RIP Protocol calculates the value to infinity.