6 Dynamic Routing Protocols

6.1 Introduction

When a networking utility needs routing information, it searches the system's routing table. You can set up and manage this table manually (from the command line). However, if the network environment is constantly in flux, the information in a static routing table could quickly become obsolete. To update the routing table dynamically, VxWorks supports RIP (Routing Information Protocol).

RIP comes bundled with VxWorks and is intended for small to medium-sized networks. RIP is a distance-vector protocol, which means that it contains a vector of distances (a hop count). Each router uses these distance-vectors to update its routing tables.

6.2 RIP, Routing Information Protocol

RIP maintains routing information within small internetworks. You can use RIP only in networks where the largest number of hops is 15. Although 15 hops can encompass a very large network, many networks already 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 backward 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 also 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.

6.2.1 VxWorks Debugging Routines for RIP

The RIP server provides 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 large amounts 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 time out 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 not propagate to other routers.

RTS_INTERNAL

Route is internal, used to implement border gateway filtering.

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).

RTS_OTHER

Route belongs to some other (non-RIP) protocol.

RTS_PRIMARY

Route is a primary route. If this flag is set, the RTS_OTHER flag must also be set.

RIP periodically pushes routing information into the VxWorks routing table. Between updates, the two tables can diverge, but updating only periodically avoids route thrashing (pushing transient routes into the system route table but then removing them immediately).

6.2.2 Configuring RIP

To include the RIP server, reconfigure the image. The relevant configuration parameter is INCLUDE_RIP.

NOTE: If you exclude RIP, but include SNMP, a separately purchasable option, you might want to edit snmpMib2.mib to exclude RIP MIB objects. Including these objects does no harm, but it makes the image larger unnecessarily.

Compile-Time Configuration

The RIP server starts up when the network initialization code calls ripLibInit( ). This routine takes several parameters. You set the value of these parameters by adjusting the following configuration parameters:

BSD 4.3 Compatible Sockets -- BSD43_COMPATIBLE

Although BSD43_COMPATIBLE is not a RIP-specific configuration parameter, you must turn it off if you want to use VxWorks RIP. By default, this parameter is already set. BSD43_COMPATIBLE is also automatically defined if VxWorks is configured to use sockets, INCLUDE_BSD_SOCKET.

RIP Supplier Flag -- RIP_SUPPLIER, default: 0

Set to 1, RIP_SUPPLIER 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.

RIP Gateway Flag -- RIP_GATEWAY, default: 0

Set to 1, RIP_GATEWAY tells the server that the router is a default gateway to all hosts external to the routing domain. If this is not the case, set this constant to 0.

WARNING: Do not set RIP_GATEWAY to 1 unless this really is the general gateway. Setting this to 1 configures the RIP server to ignore any advertisements for default routers received from other RIP peers.

RIP Multicast Flag -- RIP_MULTICAST, default: 0

Set to 1, RIP_MULTICAST 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.

RIP Version Number -- RIP_VERSION, default: 1

Set to 1, RIP_VERSION 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, RIP_MULTICAST, to 1, you put the server in full version-2 mode.

RIP Timer Rate -- RIP_TIMER_RATE, default: 1 second

RIP_TIMER_RATE tells RIP how often it should examine the routing table for changes and expired routes.

RIP Supply Interval -- RIP_SUPPLY_INTERVAL, default: 30 seconds

RIP_SUPPLY_INTERVAL tells RIP how frequently it should transmit route updates over every known interface. This value must be set to a multiple of the RIP Timer Rate.

RIP Expire Time -- RIP_EXPIRE_TIME, default: 180 seconds

RIP_EXPIRE_TIME tells RIP the maximum time between updates before a route is invalidated and removed from the kernel table.

RIP Garbage Time -- RIP_GARBAGE_TIME, default: 120 seconds

RIP_GARBAGE_TIME tells RIP specifies the amount of time to wait before a route removed from the kernel table is also deleted from the internal routing table. This wait time does not apply until after the RIP_EXPIRE_TIME expires. Thus, when a RIP_GARBAGE_TIME applies, the total wait time is RIP_GARBAGE_TIME plus RIP_EXPIRE_TIME. By default, that delay would be 300 seconds (120 plus 180).

RIP Authentication Type -- RIP_AUTH_TYPE, default: 1 (no authentication)

RIP_AUTH_TYPE tells RIP which authentication method (if any) that it should use. Valid values for RIP_AUTH_TYPE are:

1 -- no authentication
2 -- simple password authentication
3 -- MDS authentication

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

Run-Time Configuration

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.

RIP Task Priority and User Protection Domains

RIP tasks run at a priority of 100 and 101. If you are using your own protection domain, make sure that the task priority range for the protection domain spans the above two values.

6.2.3 Creating an Interface Exclusion List for RIP

By default, RIP runs on all interfaces active when RIP is initialized. If you do not want to run RIP on a particular interface, you can name the interface on a RIP exclusion list. However, you must put the interface on the exclusion list before RIP is initialized. If that is not possible, you can add the interface to the list and then call ripIfReset( ).

NOTE: Calling ripIfReset( ) clears the RIP interface settings for the interface. This means you lose the interface hooks, the interface MIB2 settings, and all other such information associated with the interface.

If RIP is already running on an interface, simply putting an interface on the exclusion list does not automatically shut down RIP on that interface.

To manage an interface exclusion list, ripLib provides the following functions:

ripIfExcludeListAdd( ) -- add an interface to the RIP exclusion list

ripIfExcludeListDelete( ) -- remove an interface from the RIP exclusion list

ripIfExcludeListShow( ) -- show the interfaces on the RIP exclusion list

For more information on these functions, see the relevant ripLib reference entries.

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 time out is the length of time for which the route remains current. If a route is not updated within 3 minutes, it is flushed from the routing table.