RIP maintains routing information within small internetworks. You can use RIP only in networks where the largest number of hops is 15. While this might seem like a large number, there are already many existing corporate networks that exceed this limit.¹

RIP is based on work done in the Internet community, and its algorithmic base goes back to the ARPANET circa 1969. It is based on the distance-vector algorithm, also called Bellman-Ford, which is described in "Dynamic Programming," from Princeton University by R. E. Bellman. This paper was published in 1957.

The RIP server provided with VxWorks is based on the BSD 4.4 routed program. There are several relevant RFCs; the two most important are RFC 1058, in which RIP version 1 was first documented, and RFC 1388, in which the version 2 extensions are documented.

The VxWorks RIP server supports three modes of operation:

• Version 1 RIP

This mode of operation follows RFC 1058. It uses subnet broadcasting to communicate with other routers and sends out only a gateway and metric for each subnet.

• Version 2 RIP with Broadcasting

This mode is the same as Version 2 RIP with multicasting (see below), except that it uses broadcasting instead of multicasting. This mode is backwards compatible with RIP Version 1 and is the mode recommended in RFC 1388.

• Version 2 RIP with Multicasting

In this mode, the server not only knows about routers but can describe routes based on their subnet mask and can designate a gateway that is not the router that sends the updates. Thus, the machine that hosts the RIP server does not necessarily have to be the gateway. Because this mode uses multicasting to communicate, only interested nodes in the network see routing information and updates.

Provided with the RIP server are several routines that make debugging easier. The most often used is ripLogLevelBump( ), which enables tracing of packets and routing changes. Keep in mind that bumping the log level several times prints a lot of data to the console. Another routine is ripRouteShow( ), which prints the router's internal tables to the console. The printed message provides the following information:

• the route being advertised

• the router that routes the packets

• a subnet mask

• the timeout on the route (in seconds)²

• the flags value (see Table 6-1)

  Table 6-1:  Flag Constants for ripRouteShow( )

  Constant		Meaning
  RTS_CHANGED		Route has changed recently (within the last 30 seconds).
  RTS_EXTERNAL		Route should propagate to other routers.
  RTS_INTERNAL		Route is internal, do not propagate.
  RTS_PASSIVE		Route is on a passive interface (loopback).
  RTS_INTERFACE		Route is on a directly connected interface.
  RTS_REMOTE		Route is on a point to point link.
  RTS_SUBNET		Route is to a subnet (not a host).

Routing information is pushed down into VxWorks's routing table periodically, but there can be periods when the two are out of sync. This periodic updating (as opposed to continuous updating) avoids route thrashing, where transient routes are pushed into the system but then need to be removed immediately.

To include the RIP server, reconfigure the VxWorks image. The relevant configuration macro is INCLUDE_RIP. The RIP server starts up when usrNetwork.c calls ripLibInit( ). This routine takes four parameters. You set the value of these parameters by editing the configuration and adjusting the following configuration items:

RIP Supplier Flag

Set to 1 tells the RIP server to send out routing information and updates no matter how many physical interfaces are attached to it. Setting this constant to 0 turns off this feature. (Configuration macro: RIP_SUPPLIER)

RIP Gateway Flag

Set to 1 tells the server that it is a router to the greater Internet. If this is not the case, set this constant to 0 (the default). (Configuration macro: RIP_GATEWAY)

	WARNING: Do not set RIP_GATEWAY to 1 unless this really is the general gateway. Setting this to 1 makes the RIP server send a default route (0.0.0.0) out with every routing update. This tells all the other listening servers that this server is the default route for its subnet. This causes all packets to go to this router if they do not have a route that matches an existing entry in their routing table.

RIP Multicast Flag

Set to 1 tells the server to use the RIP multicast address (224.0.0.9) instead of using broadcasts. This mode lowers the load on the network generated by the routing updates. Unfortunately, not all RIP server implementations (for example, BSD and SunOS routed) can handle multicasting. (Configuration macro: RIP_MULTICAST)

RIP Version Number

Set to 1 tells the server to run just as a version 1 RIP router (as described in RFC 1058). Such a server ignores all version 2 packets as well as malformed version 1 packets. Set this constant to 2 to tell the server that it should send out version 2 packets and that it should listen for and process both version 1 and version 2 packets. If you set this constant to 2 and set the RIP Multicast Flag to 1, you put the server in full version 2 mode. (Configuration macro: RIP_VERSION)

BSD 4.3 Compatible Sockets

Undefine this constant if you want to use RIP with VxWorks. By default, this constant is already defined. (Configuration macro: BSD43_COMPATIBLE). It is also automatically defined if VxWorks is configured to use sockets. The relevant configuration macro is INCLUDE_BSD_SOCKET.

	CAUTION: The RIP server does not support separate routing domains. Only routing domain 0, the default, is supported.

In addition to setting the defines shown above, there are two alternate methods you can use to configure RIP:

• Use the m2Rip routines to configure RIP. These routines are documented in the reference entries. The parameters to these routines are also described in RFC-1389.

• Use an SNMP agent to configure RIP.

1:  A packet takes a hop every time it crosses a subnet. If a packet leaves machine Q and must pass through two subnet routers before it reaches its destination on machine N, the number of hops is two.

2:  The timeout is the length of time for which the route remains current. If a route is not updated after 3 minutes, it is flushed from the routing table.