ROUTING INFORMATION

PROTOCOL (RIP)
“DATA NETWORK” FOR JTOs PH-II : RIP

INTRODUCTION
The DARPA Internet Architecture.

Internet Protocols

The Internet system consists of a number of interconnected packet networks

supporting communication among host computers using the Internet
protocols. These protocols include the Internet Protocol (IP), the Internet
Control Message Protocol (ICMP), the Transmission Control Protocol (TCP),
and application protocols depending upon them .

All Internet protocols use IP as the basic data transport mechanism. IP is a

datagram, or connectionless, internetwork service and includes provision for
addressing, type-of-service specification, fragmentation and reassembly, and
security information. ICMP is considered an integral part of IP, although it is
architecturally layered upon IP. ICMP provides error reporting, flow control
and first-hop gateway redirection.

Reliable data delivery is provided in the Internet protocol suite by transport-

level protocols such as the Transmission Control Protocol (TCP), which
provides end-end retransmission, resequencing and connection control.
Transport-level connectionless service is provided by the User datagram
Protocol (UDP).

Networks and gateways

Constituent networks may generally be divided into two classes.

1. Local-Area Networks (LANs)

2. Wide-Area Networks (WANs)

In the Internet model, constituent networks are connected together by IP

datagram forwarders which are called "gateways" or "IP routers".

A gateway is connected to two or more networks, appearing to each of these

networks as a connected host. Thus, it has a physical interface and an IP
address on each of the connected networks. Forwarding an IP datagram
generally requires the gateway to choose the address of the next-hop
gateway or (for the final hop) the destination host. This choice, called
"routing", depends upon a routing data-base within the gateway. This routing
data-base should be maintained dynamically to reflect the current topology of
the Internet system; a gateway normally accomplishes this by participating in
distributed routing and reachability algorithms with other gateways. gateways
provide datagram transport only, and they seek to minimize the state
information necessary to sustain this service in the interest of routing flexibility
and robustness.

BRBRAITT March-2007 2
“DATA NETWORK” FOR JTOs PH-II : RIP

Autonomous Systems

For technical, managerial, and sometimes political reasons, the gateways of

the Internet system are grouped into collections called "autonomous systems"
. The gateways included in a single autonomous system (AS) are expected to

• Be under the control of a single operations and maintenance (O&M)

organization;
• Employ common routing protocols among themselves, to maintain their
routing data-bases dynamically.

A number of different dynamic routing protocols have been developed; the

particular choice of routing protocol within a single autonomous system is
generically called an interior gateway protocol or IGP.

An IP datagram may have to traverse the gateways of two or more

autonomous systems to reach its destination, and the autonomous systems
must provide each other with topology information to allow such forwarding.
The Border Gateway Protocol (BGP) is used for this purpose, between
gateways of different autonomous systems.

Routing Information Protocol (RIP)

RIP is one protocol in a series of routing protocols based on the Bellman-Ford

(or distance vector) algorithm. This algorithm has been used for routing
computations in computer networks since the early days of the ARPANET.
The particular packet formats and protocol described here are based on the
program "routed", which is included with the Berkeley distribution of Unix. It
has become a de facto standard for exchange of routing information among
gateways and hosts. It is implemented for this purpose by most commercial
vendors of IP gateways. Note, however, that many of these vendors have
their own protocols which are used among their own gateways.

This protocol is most useful as an "interior gateway protocol". In a nationwide

network such as the current Internet, it is very unlikely that a single routing
protocol will used for the whole network. Rather, the network will be organized
as a collection of "autonomous systems". An autonomous system will in
general be administered by a single entity, or at least will have some
reasonable degree of technical and administrative control. Each autonomous
system will have its own routing technology. This may well be different for
different autonomous systems. The routing protocol used within an
autonomous system is referred to as an interior gateway protocol, or "IGP". A
separate protocol is used to interface among the autonomous systems. The
earliest such protocol, still used in the Internet, is "EGP" (exterior gateway
protocol). Such protocols are now usually referred to as inter-AS routing
protocols. RIP was designed to work with moderate-size networks using
reasonably homogeneous technology. Thus it is suitable as an IGP for many
campuses and for regional networks using serial lines whose speeds do not
vary widely.

BRBRAITT March-2007 3
“DATA NETWORK” FOR JTOs PH-II : RIP

RIP is intended for use within the IP-based Internet. The Internet is organized
into a number of networks connected by gateways. The networks may be
either point-to-point links or more complex networks such as Ethernet or the
ARPANET. hosts and gateways are presented with IP datagrams addressed
to some host. Routing is the method by which the host or gateway decides
where to send the datagram. It may be able to send the datagram directly to
the destination, if that destination is on one of the networks that are directly
connected to the host or gateway. However, the interesting case is when the
destination is not directly reachable. In this case, the host or gateway
attempts to send the datagram to a gateway that is nearer the destination.
The goal of a routing protocol is very simple. It is to supply the information that
is needed to do routing.

This protocol does not solve every possible routing problem. As mentioned
above, it is primary intended for use as an IGP, in reasonably homogeneous
networks of moderate size. In addition, the following specific limitations should
be mentioned

• The protocol is limited to networks whose longest path involves 15

hops. Note that this statement of the limit assumes that a cost of 1 is
used for each network.
• The protocol depends upon "counting to infinity" to resolve certain
unusual situations.
• This protocol uses fixed "metrics" to compare alternative routes.

RIP Algorithm

Let's look at what happens when a datagram is sent from one source to a
destination. If the source and the destination are in the same autonomous
system it is delivered by the system's technology. But, if the destination is in
another autonomous system the datagram should be transferred to that
autonomous system. There it will be delivered by that system technology.
routers are the ones that should do the transferring. Therefore, they should
know all the autonomous systems in the supernet. When they receive a
datagram addressed to autonomous system `A' they should transfer it to
`A'. A trivial way to implement a router is having one router that is connected
to all autonomous systems. However this is not practical.

A more practical way is having many routers. Each connected to few

autonomous systems. Let a datagram be sent from one autonomous system
to another. The router of the first autonomous system would transfer the
datagram to that autonomous system (if it can), or transfer it to another router,
that knows how to reach the destination. Eventually the datagram will reach a
router that has a connection to that autonomous system and the datagram will
be transferred correctly.

This way requires each router to hold a database of all the possible
destinations. Each entry in the database should hold the next router that
datagrams should be sent to. This way could have worked very well. Alas, the
network cannot be kept still. New routers can be installed Old routers can

BRBRAITT March-2007 4
“DATA NETWORK” FOR JTOs PH-II : RIP

crash. Crashed router can come up. Therefore, our connection through a
router is not guaranteed. Even if the router doesn't crash, a new router may
be installed, providing better service.

Before we continue this discussion, we have to make few things clearer. We

have to define what we mean by saying that one line is better than the other.
There are many ways to measure a connections. You can measure it by the
Dollar cost, number of hops in the way, error rate, latency, etc. We will
assume that connection are measured by the number of hops in its path. This
assumption is no way, obligatory and any system administrator can define a
measure of his own. We will treat measure as costs. That means that the
lower the number associated with the connection, the better. RIP treats any
number higher than fifteen as infinity (sixteen). So, sixteen means 'no
connection'. This method of calculating the cost is called metric.

Let d( i , j ) be the cost of the direct link from i to j .

d( i , i ) = 0 for any i .

Let D( i , j ) be the cost of the best route from i to j . It is defined for any two
entities i , j .

D( i , i ) = 0 for any i .

D( i , j ) = min [d( i , k ) + D( k , j )] for i <> j

The last equation can be proven using induction over the number of steps in
the routes. The metrics can be calculated using a simple algorithm. Entity i
gets its neighbor k to send their estimates of their distance from j . When i
gets the estimates from k , it adds d( i , k ) to each of the numbers. Then i
picks the smallest value. A proof that this algorithm converges to the correct
values of D( i , j ) in finite time, when the network topology does not change.
Very few assumption were made about the order in which the entities send
each other their information. No assumption were made on the initial values of
D( i , j ), except that they have to be non-negative. That means that it is safe
to run the algorithm asynchronously. Entities can send updates by their own
clock. Updates may be dropped, as long as they don't get all dropped.
Because there are no assumptions on the initials values, the algorithm
handles changes. when the topology changes, the system will move to a new
equilibrium using the old one as its starting point.

Once a router is installed, or started, it should send messages to all of its

neighbors. This is necessary in order to update their tables. Consider this
case:

A was connected to D through B and C . Once E has been installed, A can

connect to D through E . This line costs less. That's why E has to announce
its existence to A . If E should ever crash, A must know about it. Otherwise it
will continue to send datagram s through E . Unfortunately, a router can't

BRBRAITT March-2007 5
“DATA NETWORK” FOR JTOs PH-II : RIP

always inform others, that it is about to crash. A router can't depend on such
message to warn it.

Therefore a router crash, must be learned in other ways. RIP forces a router
to send update messages every thirty seconds. These messages contain
routes, that that router knows; and their metrics. If a router does not receive
an update message for 180 seconds. from another router. It assumes that
router to be unreachable. This timeout of 180 seconds allow a router to miss
five update messages, without being marked unreachable. This is necessary,
because the media might be unreliable and loose datagrams.

The algorithm so far, sends update messages every thirty seconds. Every
update message contains a list of the autonomous system the routers knows
to reach and their metrics. If the metric in an update message is lower than
the metric in the router 's table, the router would update the metric and the
next hop fields in its table. If for some destination, an update had come from
the next hop, indicating a different metric, then the metric in the table should
be changed. This is necessary because if the metric changes in the next hop,
we must change the metric in our router, as well. This guarantees correct
performance, but not good enough. Consider this case:

BRBRAITT March-2007 6
“DATA NETWORK” FOR JTOs PH-II : RIP

All links have cost of 1, except for the direct link from C to B which has cost
10. Each router will have a table showing the next hop and the metric for each
destination. We're interested only in the connection to the target network.

D : directly connected, metric 1.

B : connected via D , metric 2.

C : connected via B , metric 3.

A : connected via B , metric 3.

Now suppose that the link from B to D fails. The routes should adjust to use
the link from C to D . Unfortunately it will take quite a while for this to happen.
The routing changes start when B notices that the route to D is no longer
usable. The chart below assumes that all router s send updates at the same
time. the chart shows the metrics for the target.

time --->

B : unreachable | C , 4 | C , 5 ....

C: B, 3 | A,4| A,5

A: B, 3 | C,4| C,5

The problem is that A and C both believe they can connect to the target
through each other. It happened because they sent messages indicating they
can connect to the target at cost of 3. When they received the message from
B saying that the target is unreachable, they received another message. The
second message said they can connect to the target in cost of 3. This cost is
of course not true, because the link from B to D is unusable. Since A and C
don't know that the route from each other uses another link that is no longer
usable, they would both update their tables to point at each other. Since, they
increase the metric by one, they will both report that the cost is now four.
Since A uses C as next connection, and C signals that the cost had change, A
would change the cost of the link. Same thing would happen to C . This way
the cost of the connection will slowly rise. The worst case is when the target is
really unusable, and then the cost will rise up to infinity. This effect is called
'counting to infinity'. This is why infinity was chosen to be such a small
number. If some autonomous system becomes completely unreachable, we
would like the counting to be over as soon as possible.

There are several ways to prevent this from happening. The ones that RIP
uses are called 'split horizon with poison reverse' and 'triggered update'.

BRBRAITT March-2007 7
“DATA NETWORK” FOR JTOs PH-II : RIP

Split horizon.

Notice that the problem above is caused because both A and C deceive each
other. They both claim they have a connection. Since they both think they can
connect through each other, a real link is not established. This could have
been prevented if A hadn't told C that it can connect to the target. Generally, it
is not useful to claim reachability for a destination to the neighbor from which
the route was learned. The "simple split horizon" omits routes learned from
one neighbor in updates to that neighbor. "split horizon with poisoned reverse"
include those routes but with cost of infinity.

If A thinks it can get to D through C its message to C should indicate that D is

unreachable. If C still claim reachability to D , then either it is connected
directly to D , or it knows another router that claim reachability. C 's route to
the destination cannot go back to any route that points to C .

In general, split horizon with poisoned reverse, is safer than simple split
horizon. If two routers point at each other, advertising reverse routes with
metric of 16 will brake the loop immediately. If the reverse routes are simply
omitted, those routes will have to be eliminated by waiting for a timeout. Alas,
poisoned reverse increases the size of the messages. Consider the case of a
campus backbone connecting many buildings. Each building has a router. In
simple split horizon only the network that is connected to the router is included
in the updates messages. In split horizon with poisoned reverse, ALL
networks learned must be published as well.

Implementors may use simple split horizon if they like. Or they can offer a
configuration option, to allow the system manager to choose which way to
use. It is also possible to advertise some reverse routes with metric of sixteen,
and omit others.

Triggered updates

Split horizon with poisoned reverse will break any loop of two router s.
However, it is still possible for loops of three or more router s, to occur. A may
think it can reach the target through B . B may think it can reach the target
through C . C may think it can reach the target through A . This loop will break
only when infinity will be reached. Triggered updates are an attempt to speed
up this convergence. To imply triggered updates, we simply add a rule that
whenever a router changes the metric of a route, it is required to send update
messages almost immediately. The triggered update messages will be sent
even if it is not time to the regular update message. Consider a case were G
can connect to a target network, and then its link becomes unusable. G will
send its neighbor updates about the change. Its neighbors will update their
tables if necessary. The ones that updated their tables will send their own
update messages. Some of the neighbors' neighbors will update their tables,
and send their own update messages. The update messages will propagate
back, until they reach a portion of the network that uses another route to
connect to the target.

BRBRAITT March-2007 8
“DATA NETWORK” FOR JTOs PH-II : RIP

If the system could be made to stay still while the update messages
propagate back, it had been possible to prove that counting to infinity would
never happen. A bad router will be removed from the tables, using update
messages. Alas, this is not the case. While the triggered updates are being
sent, regular updates can be sent, from router who hasn't got the update yet.
Their update will indicate that the target is still reachable. It is possible that a
router will receive a false regular update saying the target is reachable, after it
received a triggered update saying the target is unreachable. This could
reestablish a connection incorrectly. Triggered updates reduce the chance to
get counting to infinity, however this can still happen.

Format of RIP Datagram:

The format of the RIP header is shown here:

8B + 4B + 25x20B = 512 B

UDP Header RIP Header RIP Data

Octet +0 Octet +1 Octet +2 Octet +3

COMMAND VERSION UNUSED (SET TO ZERO’S)

ADDRESS FAMILY IDENTIFIER UNUSED (SET TO ZERO’S)

IP ADDRESS
UNUSED (SET TO ZERO’S)
UNUSED (SET TO ZERO’S)
METRIC

Each word (line) is 32 bits

The fields size (e.g, (1) ) are in octets

The portion of the datagram from address family field through metric may
appear up to 25 times. IP address is the usual 4-octet Internet address, in
network order. The special address 0.0.0.0 is used to describe a default route.
The address family identifier for IP is 2. The metric field must contain a value
between 1 and 15 inclusive, specifying the current metric for the destination,
or the value 16, which indicates that the destination is not reachable. The
maximum datagram size is 512 octets. (IP or UDP headers not counted)
Every datagram contains a command, a version number, and possible
arguments.
Here is a summary of the commands implemented in version 1 of RIP:

BRBRAITT March-2007 9
“DATA NETWORK” FOR JTOs PH-II : RIP

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 poll, or it may
be an update message generated by the sender.
3. traceon Obsolete. Messages containing this command are to be
ignored.
4. traceoff Obsolete. Messages containing this command are to be
ignored.
5. reserved This value is used by Sun Microsystems for its own purposes.
If new commands are added in any succeeding version, they should
begin with 6. Messages containing this command may safely be
ignored by implementations that do not choose to respond to it.

Addressing considerations

The RIP packet formats do not distinguish among various types of address.
Fields that are labeled "address" can contain any of the following:

• host address
• subnet number
• network number
• 0, indicating a default route

When routing a datagram , its destination address must first be checked

against the list of host addresses. Then it must be checked to see whether it
matches any known subnet or network number. Finally, if none of these
match, the default route is used.

"Border" gateway s send only a single entry for the network as a whole to host
s in other networks. This means that a border gateway will send different
information to different neighbors. For neighbors connected to the subnetted
network, it generates a list of all subnets to which it is directly connected,
using the subnet number. For neighbors connected to other networks, it
makes a single entry for the network as a whole, showing the metric
associated with that network. (This metric would normally be the smallest
metric for the subnets to which the gateway is attached.)

Timers

Every 30 seconds, the output process is instructed to generate a complete

response to every neighboring gateway .

There are two timers associated with each route, a "timeout" and a "garbage-
collection time". Upon expiration of the timeout, the route is no longer valid.
However, it is retained in the table for a short time, so that neighbors can be
notified that the route has been dropped. Upon expiration of the garbage-
collection timer, the route is finally removed from the tables.

BRBRAITT March-2007 10
“DATA NETWORK” FOR JTOs PH-II : RIP

The timeout is initialized when a route is established, and any time an update
message is received for the route. If 180 seconds elapse from the last time
the timeout was initialized, the route is considered to have expired, and the
deletion process which we are about to describe is started for it.

Deletions can occur for one of two reasons: (1) the timeout expires, or (2) the
metric is set to 16 because of an update received from the current gateway .
(See response command for a discussion processing updates from other
gateway s.) In either case, the following events happen:

- 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 signalled to trigger a response.

Until the garbage-collection timer expires, the route is included in all updates
sent by this host , with a metric of 16 (infinity). When the garbage-collection
timer expires, the route is deleted from the tables.

Should a new route to this network be established while the garbage-

collection timer is running, the new route will replace the one that is about to
be deleted. In this case the garbage-collection timer must be cleared.

Input processing

Before processing the recived datagram s, certain general format checks

must be made. These depend upon the version number field in the datagram ,
as follows:

• 0 datagram s 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 datagram s whose version number is one are to be processed as
described in this document. 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 datagram s 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. Version 1
implementations are to ignore this extra data and process only the
fields specified in this document.

After checking the version number and doing any other preliminary checks,
processing will depend upon the value in the command field.

BRBRAITT March-2007 11
“DATA NETWORK” FOR JTOs PH-II : RIP

Output processing

Let describe the processing used to create response messages that contain
all or part of the routing table. This processing may be triggered in any of the
following ways

- 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 update may be delayed.)

Triggered updates require special handling for two reasons. First, experience
shows that triggered updates can cause excessive loads on networks with
limited capacity or with many gateway s on them. Thus the protocol requires
that implementors include provisions to limit the frequency of triggered
updates. After a triggered update is sent, a timer should be set for a random
time between 1 and 5 seconds. If other changes that would trigger updates
occur before the timer expires, a single update is triggered when the timer
expires, and the timer is then set to another random value between 1 and 5
seconds. Triggered updates may be suppressed if a regular update is due by
the time the triggered update would be sent.

Second, triggered updates do not need to include the entire routing table. In
principle, only those routes that have changed need to be included. Thus
messages generated as part of a triggered update must include at least those
routes that have their route change flag set. They may include additional
routes, or all routes, at the discretion of the implementor; however, when full
routing updates require multiple packet s, sending all routes is strongly
discouraged. When a triggered update is processed, messages should be
generated for every directly-connected network. Split horizon processing is
done when generating triggered updates as well as normal updates.

If, after split horizon processing, a changed route will appear identical on a
network as it did previously, the route need not be sent; if, as a result, no
routes need be sent, the update may be omitted on that network. (If a route
had only a metric change, or uses a new gateway that is on the same network
as the old gateway , the route will be sent to the network of the old gateway
with a metric of infinity both before and after the change.) Once all of the
triggered updates have been generated, the route change flags should be
cleared.

BRBRAITT March-2007 12
“DATA NETWORK” FOR JTOs PH-II : RIP

If input processing is allowed while output is being generated, appropriate

interlocking must be done. The route change flags should not be changed as
a result of processing input while a triggered update message is being
generated.

The only difference between a triggered update and other update messages
is the possible omission of routes that have not changed. The rest of the
mechanisms about to be described must all apply to triggered updates.

Here is how a response datagram is generated for a particular directly-

connected network:

The IP source address must be the sending host 's address on that network.
This is important because the source address is put into routing tables in
other host s. If an incorrect source address is used, other host s may be
unable to route datagram s. Sometimes gateway s are set up with multiple IP
addresses on a single physical interface. Normally, this means that several
logical IP networks are being carried over one physical medium. In such
cases, a separate update message must be sent for each address, with that
address as the IP source address.

Set the version number to the current version of RIP.

Set the command to response. Set the bytes labeled "must be zero" to zero.
Now start filling in entries. To fill in the entries, go down all the routes in the
internal routing table. Recall that the maximum datagram size is 512 bytes.
When there is no more space in the datagram , send the current message
and start a new one. If a triggered update is being generated, only entries
whose route change flags are set need be included.

Routes to subnets will be meaningless outside the network, and must be

omitted if the destination is not on the same subnetted network. they should
be replaced with a single route to the network of which the subnets are a part.
Similarly, routes to host s must be eliminated if they are subsumed by a
network route.

If the route passes these tests, then the destination and metric are put into the
entry in the output datagram . Routes must be included in the datagram even
if their metrics are infinite. If the gateway for the route is on the network for
which the datagram is being prepared, the metric in the entry is set to 16, or
the entire entry is omitted. Omitting the entry is simple split horizon. Including
an entry with metric 16 is split horizon with poisoned reverse.

RIP Version 2

Rip 2 is an extension of the Routing Information Protocol (RIP), as defined in

the previous sections. Its purpose is to expand the amount of useful
information in the RIP packets and to add security elements.

The justifications of maintaining old RIP in a world of newer and stronger

routing protocols are mainly its vast distribution and its small overhead

BRBRAITT March-2007 13
“DATA NETWORK” FOR JTOs PH-II : RIP

requirements both in bandwidth and in configuration and management time. In

addition, RIP is very easy to implement, especially in relation to the newer
IGPs. Under the assumption that RIP will remain in service for some more
years, there were people who thought it was reasonable to increase RIP's
usefulness, especially since the gain looked far greater than the expense of
the change.

Recently, RIP version 2 became the standard version of RIP, and the original
RIP is now historic.

The main disadvantages of RIP version 1 are the minimal amount of

information included in every packet, the large amount of unused space in the
header of each packet and the ignorance from implementations and topics
which postdated RIP 1. Namely, autonomous systems and basically EGP
interactions, sub-netting, and authentication.

The RIP 2 datagram format is:

8B + 4B + 25x20B = 512 B

UDP Header RIP Header RIP Data

Octet +0 Octet +1 Octet +2 Octet +3

COMMAND VERSION ROUTING DOMAIN

ADDRESS FAMILY IDENTIFIER ROUTE TAG

IP ADDRESS
SUBNET MASK
NEXT HOP
METRIC

The Command, Address Family Identifier (AFI), IP Address, and Metric all
have the same meanings as in RIP 1. The Version field specifies version
number 2 for RIP datagrams which use authentication or carry information in
any of the newly defined fields.

In RIP 2 there is an optional authentication mechanism. When in use, this

option abuses an entire RIP entry, and leaves space to at most 24 RIP entries
in the remainder of the packet. The most widespread authentication Type is
simple password and it is type 2.

BRBRAITT March-2007 14
“DATA NETWORK” FOR JTOs PH-II : RIP

The Routing domain field enables some routing domains inter-work upon the
same physical infrastructure, while logically ignoring each other. This gives
the ability to simply implement various kinds of policies. There is a default
routing domain which is assigned the value '0'.

The Route Tag (RT) field exists as a support for EGP's. This field is expected
to carry Autonomous System numbers for EGP and BGP. RIP systems which
receive RIP entry which contains a non-zero RT value must re-advertise that
value.

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 is included for this entry.

Next Hop is the immediate next hop IP address to which packets to the
destination specified by this route entry should be forwarded. The purpose of
the Next Hop field is to eliminate packets being routed through extra hops in
the system. It is particularly useful when RIP is not being run on all of the
routers on a network.

Multi-casting is an optional feature in RIP 2 using IP address 224.0.0.9. This

feature reduces unnecessary load on those hosts which are not listening to
RIP 2. The IP multi-cast address is used for periodic broadcasts. In order to
maintain backwards compatibility, the use of the multi-cast address is
configurable.

RIP 2 is totally backwards compatible with RIP 1. Its applications support fine
tuning to be RIP 1 emulation, RIP 1 compatible, or fully RIP 2.

BRBRAITT March-2007 15