6.2.2 Intra-Domain Routing Protocols
1. Routing Information Protocol (RIP)
One of the most widely used interior gateway protocols is the Routing Information Protocol
(RIP). RIP is an implementation of a distance-vector, or Bellman-Ford routing protocol for local
networks. It classifies routers as active and passive (silent). Active routers advertise their routes
(reachability information) to others; passive routers listen and update their routes based on
advertisements, but do not advertise. Typically, routers run RIP in active mode, while hosts use
passive mode.
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) adds 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:
- Next hop
- RIP II can advertise a next hop other than the router supplying the routing update. This
is quite useful when advertising a static route to a dumb router that does not run RIP,
as it avoids having packets destined through the dumb router from having to cross a
network twice.
- 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.
- Network Mask
- RIP I assumes that all subnetworks of a given network have the same network mask. It
uses this assumption to calculate the network masks for all routes received. This
assumption prevents subnets with different netmasks from being included in RIP
packets. RIP II adds the ability to specify the network mask with each network in a
packet.
- 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
networks must only be provided in native RIP II packets that are multicast.
- Authentication
- RIP II packets may also contain one of two types of authentication strings that may be
used to verify the validity of the supplied routing data. Authentication may be used in
RIP-I-compatible RIP II packets, but be aware that RIP I routers will ignore it.
- 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 separate authentication key is
used for non-router queries.
RIP-I and network masks
RIP-I derives the network mask of received networks and hosts from the network mask of the
interface via which the packet was received. If a received network or host is on the same natural
network as the interface over which it was received and that network is subnetted (the specified
mask is more specific than the natural netmask), the subnet mask is applied to the destination. If
bits outside the mask are set it is assumed to be a host, otherwise it is assumed to be a subnet.
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.
The RIP Statement
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_file_option 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
- Specifies that RIP packets will be broadcast regardless of the number of interfaces
present. This is useful when propagating static routes or routes learned from anther
protocol into RIP. In some cases, the use of broadcast when only one network
interface is present can cause data packets to traverse a single network twice.
- nobroadcast
- Specifies that RIP packets will not be broadcast on attached interfaces, even if there
are more than one. If a sourcegateways clause is present, routes will still be
unicast directly to that gateway.
- nocheckzero
- Specifies that RIP should not make sure that reserved fields in incoming version 1 RIP
packets are zero. Normally RIP will reject packets where the reserved fields are
non-zero.
- preference preference
- Sets the preference for routes learned from RIP. The default preference is 100. This
preference may be overridden by a preference specified in import policy.
- defaultmetric metric
- Defines the metric used when advertising routes via RIP that were learned from other
protocols. If not specified, the default value is 16 (unreachable). This choice of values
requires you to explicitly specify a metric in order to export routes from other
protocols into RIP. This metric may be overridden by a metric specified in export
policy.
- query authentication [none| ([simple|md5] password)] ;
- Specifies the authentication required of query packets that do not originate from
routers. The default is none.
- interfaceinterface_list
- Controls various attributes of sending RIP on specific interfaces. See the section on
interface list specification for the description of the interface_list.
- Note that if there are multiple interfaces configured on the same subnet, RIP updates
will only be sent from first one for 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
- Specifies that RIP packets received via the specified interface will be ignored.
The default is to listen to RIP packets on all non-loopback interfaces.
- ripin
- This is the default. This argument may be necessary when noripinis used on a
wildcard interface descriptor.
- noripout
- Specifies that no RIP packets will be sent on the specified interfaces. The default
is to send RIP on all broadcast and non-broadcast interfaces when in
broadcast mode. The sending of RIP on point-to-point interfaces must be
manually configured.
- ripout
- This is the default. This argument is necessary when it is desired to send RIP on
point-to-point interfaces and may be necessary when noripin is used on a
wildcard interface descriptor.
- metricin metric
- Specifies the RIP metric to add to incoming routes before they are installed in the
routing table. The default is the kernel interface metric plus 1 (which is the
default RIP hop count). If this value is specified it will be used as the absolute
value, the kernel metric will not be added. This option is used to make this router
prefer RIP routes learned via the specified interface(s) less than RIP routes from
other interfaces.
- metricout metric
- Specifies the RIP metric to be added to routes that are send via the specified
interface(s). The default is zero. This option is used to make other routers prefer
other sources of RIP routes over this router.
- version 1
- Specifies that the RIP packets sent on the specified interface(s) will be version 1
packets. This is the default.
- version 2
- Specifies that RIP version 2 packets will be sent on the specified interfaces(s). If
IP multicast support is available on the specified interface(s), the default is to
send full version 2 packets. If multicast support is not available, version 1
compatible version 2 packets will be sent.
- multicast
- Specifies that RIP version 2 packets should be multicast on this interface. This is
the default.
- broadcast
- Specifies that RIP-1-compatible RIP version 2 packets should be broadcast on
this interface, even if IP multicast is available.
- [secondary] authentication[none | ([simple|md5] password)]
- This defines the authentication type to use. It applies only to RIP version 2 and is
ignored for RIP-1 packets. The default authentication type is 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 gateway_list
- Defines the list of gateways from which RIP will accept updates. The gateway_list is
simply a list of host names or IP addresses. By default, all routers on the shared
network are trusted to supply routing information. But, if the
trustedgatewaysclause is specified, only updates from the gateways in the list
are accepted.
- sourcegateways gateway_list
- Defines a list of routers to which RIP sends packets directly, not through multicast or
broadcast. This can be used to send different routing information to specific gateways.
Updates to gateways in this list are not affected by noripout on the interface.
- traceoptions trace_file_option trace_options
- Specifies the tracing options for RIP. (See Trace Statements and the RIP-specific
tracing options below.)
The policy option logs information whenever a new route is announced, or the metric being
announced changes, or a route goes or leaves holddown.
Packet tracing options (which may be modified with detail, send or recv):
- packets
- All RIP packets.
- request
- RIP information request packets, such as REQUEST, POLL and POLLENTRY
- response
- RIP RESPONSE packets, which are the type of packet that actually contains routing
information.
- other
- Any other type of packet. The only valid ones are TRACE_ON and
TRACE_OFF,both of which are ignored.
Examples of RIP tracing option:
traceoptions none;
traceoptions /var/tmp/rip_peer1 detail packets;
traceoptions receive request; traceoptions send response;
Last updated April 25, 1997
gated@gated.merit.edu