A router running RIP in active mode broadcasts updates at set intervals. Each update contains paired values where each pair consists of an IP network address and an integer distance to that network. RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a router advertises directly connected networks at a metric of 1. Networks which are reachable through one other gateway are two hops etc. Thus, the number of hops or hop count along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path. Using hop counts to calculate shortest paths does not always produce optimal results. For example, a path with hop count 3 that crosses three Ethernets may be substantially faster that a path with a hop count 2 that crosses two slow-speed serial lines. To compensate for differences in technology many routers advertise artificially high hop counts for slow links.
As delivered with most UNIX systems, RIP is run by the routing
daemon, routed (pronounced route-"d"). A RIP routing
daemon dynamically builds on information received through RIP updates.
When started up, it issues a REQUEST for routing information
and then listens for responses to the request. If a system configured
to supply RIP hears the request, it responds with a RESPONSE packet
based on information in its routing database. The RESPONSE packet
contains destination network addresses and the routing metric for each
destination.
When a RIP RESPONSE packet is received, the routing daemon takes the information and rebuilds the routing database adding new routes and "better" (lower metric) routes to destinations already listed in the database. RIP also deletes routes from the database if the next router to that destination says the route contains more than 15 hops, or if the route is deleted. All routes through a gateway are deleted if no updates are received from that gateway for a specified time period. In general, routing updates are issued every 30 seconds. In many implementations, if a gateway is not heard from for 180 seconds, all routes from that gateway are deleted from the routing database. This 180 second interval also applies to deletion of specific routes.
RIP version 2 (more commonly known as RIP II) add additional capabilities to RIP. Some of these capabilities are compatible with RIP I and some are not. To avoid supplying information to RIP I routes that could be mis-interpreted, RIP II can only use non-compatible features when it's packets are multicast. On interfaces that are not capable of IP multicast, RIP I compatible packets are used that do not contain potentially confusing information.
Some of the most notable RIP II enhancements are:
RIP I routers will ignore next hop information in RIP II packets. This may result in packets crossing a network twice, which is exactly what happens with RIP I. So this information is provided in RIP I compatible RIP II packets.
While RIP I routers will ignore the network mask in RIP II packets, their calculation of the network mask will quite possibly be wrong. For this reason, RIP I compatible RIP II packets must not contain networks that would be mis-interpreted. These network must only be provided in natve RIP II packets that are multicast.
The first method is a simple password in which an authentication key of up to 16 characters is included in the packet. If this does not match what is expected, the packet will be discarded. This method provides very little security as it is possible to learn the authentication key by watching RIP packets.
The second method is still experimental and may change in incompatible ways in future releases. This method uses the MD5 algorithm to create a crypto-checksum of a RIP packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself, instead it contains a crypto-checksum, called the digest. The receiving router will perform a calculation using the correct authentication key and discard the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides a much stronger assurance that routing data originated from a router with a valid authentication key.
Two authentication methods can be specified per interface. Packets are always sent using the primary method, but received packets are checked with both the primary and secondary methods before being discarded. In addition, a seperate authentication key is used for non-router queries.
On point-to-point interfaces, the netmask is applied to the remote address. The netmask on these interfaces is ignored if it matches the natural network of the remote address or is all ones.
Unlike in previous releases, the zero subnet mask (a network that matches the natural network of the interface, but has a more specific, or longer, network mask) is ignored. If this is not desirable, a route filter may be used to reject it.
rip yes | no | on | off [ {
broadcast ;
nobroadcast ;
nocheckzero ;
preference preference ;
defaultmetric metric ;
query authentication [none | [[simple|md5] password]] ;
interface interface_list
[noripin] | [ripin]
[noripout] | [ripout]
[metricin metric]
[metricout metric]
[version 1]|[version 2 [multicast|broadcast]]
[[secondary] authentication [none | [[simple|md5] password]] ;
trustedgateways gateway_list ;
sourcegateways gateway_list ;
traceoptions trace_options ;
} ] ;
The rip statement enables or disables RIP. If the
rip statement is not specified the default is rip
on ;. If enabled, RIP will assume nobroadcast when
there is only one interface and broadcast when there is
more than one.
The options are as follows:
broadcast when only one network
interface is present can cause data packets to traverse a single
network twice.
sourcegateways clause is present, routes will still
be unicast directly to that gateway.
Note that if there are multiple interfaces configured on the same subnet, RIP updates will only be sent from first one one which RIP output is configured. This limitation is required because of the way the Unix kernel operates. It will hopefully be removed in a future release.
The possible parameters are:
noripin is used on a wildcard interface
descriptor.
broadcast mode. The sending of RIP on
point-to-point interfaces must be manually configured.
noripin is used on a
wildcard interface descriptor.
none. If a
password is specified, the authentication type
defaults to simple. The password
should be a quoted string with between 0 and 16
characters.
If secondary is specified, this defines the
secondary authentication. If omitted, the primary
authentication is specified. The default is primary
authentication of none and no secondary
authentication.
trustedgateways clause is specified only updates
from the gateways in the list are accepted.
noripout on the interface.
policy option logs info whenever a new route is
announce, the metric being announced changes or a route goes or leaves
holddown.
Packet tracing options (which may be modified with
detail, send or recv):
REQUEST, POLL and
POLLENTRY
RESPONSE packets, which is the type of
packet that actually contains routing
information.
TRACE_ON and TRACE_OFF both of
which are ignored.