RIP ( Routing Information Protocol )

• The IP address of the destination.



• Metric represents the total cost of getting a datagram from the host to that destination. This metric is the sum of the costs associated with the networks that would be traversed in getting to the destination.



• The IP address of the next gateway along the path to the destination. If the destination is on one of the directly-connected networks, this item is not needed.



• A flag to indicate that information about the route has changed recently. This will be referred to as the "route change flag."



• Various timers associated with the route.

• When RIP is started it sends a message to each of its neighbors (on well-known UDP port 520) asking for a copy of the neighbor's routing table. This message is a query (command set to 1) with an address family of 0 and a metric of 16. The neighboring routers return a copy of their routing tables.



• When RIP is in active mode it sends all or part of its routing table to all of its neighbor routers (by broadcasting and/or by sending it on any point-to-point links to its neighbors). This is done every 30 seconds. The routing table is sent as a reply (command is 2, even though it is unsolicited).



• When RIP discovers a metric has changed, it broadcasts the change to other routers.



• When RIP receives a reply, the message is validated and the local routing table is updated if necessary.



• To improve performance and reliability, RIP specifies that once a router (or host) learns a route from another router, it must keep that route until it learns of a better one (with a strictly lower cost). This prevents routes from oscillating between two or more equal cost paths.



• When RIP receives a request, other than one for the entire table, it is returned as the response with the metric for each entry set to the value from the local routing table. If no route exists in the local table, the metric is set to 16.



• RIP routes learned from other routers time out unless they are re-advertised within 180 seconds (6 broadcast cycles). When a route times out, its metric is set to infinity, the invalidation of the route is broadcast to the router's neighbors, and 60 seconds later, the route is deleted from the local routing table.

• The protocol is limited to networks whose longest path (the network's diameter) is 15 hops. The designers believe that the basic protocol design is inappropriate for larger networks.



• Solving the counting to infinity problem is done by using the split horizon, poisoned reverse and triggered updates techniques.



• The protocol depends upon "counting to infinity" to resolve certain unusual situations. (This will be explained in the next section.) If the system of networks has several hundred networks, and a routing loop was formed involving all of them, the resolution of the loop would require either much time (if the frequency of routing updates were limited) or bandwidth (if updates were sent whenever changes were detected).



• This protocol uses fixed "metrics" to compare alternative routes. It is not appropriate for situations where routes need to be chosen based on real-time parameters such a measured delay, reliability, or load.

• Command



Value	Command	Description
1	Request	A request for the responding system to send all or part of its routing table.
2	Response	A message containing all or part of the sender's routing table. This message may be sent in response to a request, or it may be an unsolicited routing update generated by the sender.
3	Trace on. Obsolete
4	Trace off. Obsolete.
5	SUN reserved.
6	Triggered request	A triggered request is retransmitted at periodic intervals until a triggered response is received.
7	Triggered response	A triggered response is retransmitted at periodic intervals until a triggered acknowledgement is received.
8	Triggered acknowledgement	A message sent in response to every triggered response packet received.
9	Update Request	It is a request to the peer system to send ALL appropriate elements in its routing database.
10	Update Response	It is a message containing zero or more routes in an update.
11	Update Acknowledge	It is a message sent in response to every Update Response packet received.



• Version

8 bits. The RIP protocol version.


• Routing Domain

The Routing Domain (RD) number is the number of the routing process to which this update belongs. This field is used to associate the routing update to a specific routing process on the receiving router.


• Address family Identifier 16 bits.



• Route tag

16 bits. Cleared to 0 for RIPv1. For RIPv2, this is an attribute assigned to a route which must be preserved and readvertised with a route. The intended use of this tag is to provide a method of separating routes for networks within the RIP routing domain from routes which may have been imported from an EGP or another IGP.


• IPv4 address
  32 bits.



• Subnet mask.

32 bits. The Subnet Mask field contains the subnet mask which is applied to the IP address to yield the non-host portion of the address. If this field is zero, then no subnet mask has been included for this entry.On an interface where a RIP-1 router may hear and operate on the information in a RIP-2 routing entry the following two rules apply:

• Information internal to one network must never be advertised into another network.


• Information about a more specific subnet may not be advertised where RIP-1 routers would consider it a host route.



• Next hop

32 bits. The immediate next hop IP address to which packets to the destination specified by this route entry should be forwarded.


• Metric

32 bits. Contains a value from 1 to 15 which specifies the current metric for the destination. A value of 16 indicates that the destination is not reachable.

• Host address


• Subnet number


• Network number


• 0, indicating a default route

• The 30-second updates are triggered by a clock whose rate is not affected by system load or the time required to service the previous update timer.



• The 30-second timer is offset by addition of a small random time each time it is set.

• The garbage-collection timer is set for 120 seconds.



• The metric for the route is set to 16 (infinity). This causes the route to be removed from service.



• A flag is set noting that this entry has been changed, and the output process is signaled to trigger a response.

• 0 Datagrams whose version number is zero are to be ignored. These are from a previous version of the protocol, whose packet format was machine-specific.



• 1 Datagrams whose version number is one are to be processed as described in the rest of this specification. All fields that are described above as "must be zero" are to be checked. If any such field contains a non-zero value, the entire message is to be ignored.



• >1 Datagrams whose version number are greater than one are to be processed as described in the rest of this specification. All fields that are described above as "must be zero" are to be ignored. Future versions of the protocol may put data into these fields.

• Request

Request is used to ask for a response containing all or part of the host's routing table. Note that the term host is used for either host or gateway, in most cases it would be unusual for a non-gateway host to send RIP messages.The request is processed entry by entry. If there are no entries, no response is given.

Note that there is a difference in handling depending upon whether the request is for a specified set of destinations, or for a complete routing table. If the request is for a complete host table, normal output processing is done. If the request is for specific entries, they are looked up in the host table and the information is returned.


• Response

Responses can be received for several different reasons:

• Response to a specific query


• Regular updates


• Triggered updates triggered by a metric change

Because processing of a response may update the host's routing table, the response must be checked carefully for validity. The response must be ignored if it is not from port 520. The IP source address should be checked to see whether the datagram is from a valid neighbor.

Now that the datagram as a whole has been validated, process the entries in it one by one. Again, start by doing validation. If the metric is greater than infinity, ignore the entry.
Now look up the address to see whether this is already a route for it. In general, if not, we want to add one.
We want to avoid adding routes to hosts if the host is part of a net or subnet for which we have at least as good a route. If neither of these exceptions applies, add a new entry to the routing database. This includes the following actions:

• Set the destination and metric to those from the datagram.


• Set the gateway to be the host from which the datagram came.


• Initialize the timeout for the route. If the garbage- collection timer is running for this route, stop it.


• Set the route change flag, and signal the output process to trigger an update.

If the datagram is from the same gateway as the existing route and the new metric is different than the old one, or if the new metric is lower than the old one, do the following actions:

• Adopt the route from the datagram. That is, put the new metric in, and set the gateway to be the host from which the datagram came.


• Initialize the timeout for the route.


• Set the route change flag, and signal the output process to trigger an update.


• If the new metric is 16 (infinity), the deletion process is started.

• By input processing when a request is seen. In this case, the resulting message is sent to only one destination.


• By the regular routing update. Every 30 seconds, a response containing the whole routing table is sent to every neighboring gateway.


• By triggered updates. Whenever the metric for a route is changed, an update is triggered.

• The IP source address must be the sending host's address on that network.


• Set the version number to the current version of RIP.


• To fill in the entries, go down all the routes in the internal routing table.

Example 1: Plain Text Authentication



One of the two ways in which RIP updates can be authenticated is using plain text 

authentication. This can be configured as shown in the tables below.



          RB#debug ip rip

           RIP protocol debugging is on

          *Mar  3 02:11:39.207: RIP: received packet with text authentication 234

          *Mar  3 02:11:39.211: RIP: received v2 update from 141.108.0.10 on Serial0

          *Mar  3 02:11:39.211: RIP: 70.0.0.0/8 via 0.0.0.0 in 1 hops

          RB#show ip route  

          R    70.0.0.0/8 [120/1] via 141.108.0.10, 00:00:25, Serial0

               80.0.0.0/24 is subnetted, 1 subnets

          C       80.80.80.0 is directly connected, Loopback0

               141.108.0.0/30 is subnetted, 1 subnets

          C       141.108.0.8 is directly connected, Serial0



Using plain text authentication improves the network design by preventing the 

addition of routing updates originated by routers not meant to take part in the 

local routing exchange process. However, this type of authentication is not secure. 

The password (234 in this example) is exchanged in plain text. It can be captured 

easily and thus exploited.

Example 2: Troubleshooting Commands



Certain show commands are supported by the Output Interpreter Tool (registered 

customers only), which allows you to view an analysis of show command output.



          RA#debug ip rip

             RIP protocol debugging is on



             *Mar 1 06:47:42.422: RIP: received packet with text authentication 234

             *Mar 1 06:47:42.426: RIP: ignored v2 packet from 141.108.0.9 (invalid 

             authentication)



             RB#debug ip rip

             RIP protocol debugging is on



             *Mar 1 06:48:58.478: RIP: received packet with text authentication 235

             *Mar 1 06:48:58.482: RIP: ignored v2 packet from 141.108.0.10 (invalid 

             authentication)



The following output from the show ip route command shows that the router is not 

learning any routes via RIP:



          RB#show ip route

         Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP 

                 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 

                 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

                 E1 - OSPF external type 1, E2 - OSPF external type 2

                 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

                 ia - IS-IS inter area, * - candidate default, U - per-user static route

                 o - ODR, P - periodic downloaded static route



Gateway of last resort is not set



          80.0.0.0/24 is subnetted, 1 subnets

             C 80.80.80.0 is directly connected, Loopback0

                  141.108.0.0/30 is subnetted, 1 subnets

             C 141.108.0.8 is directly connected, Serial0

             RB#

■ Parent layer
■ Child layer

UDP XNSs

RIP

RIPv1 RIPv2 RIPv3 RIPv4