
                   RIP - Routing Information Protocol

This is a doc that explains how I feel RIP should be used in the UK for
the amateur service. Please pass comments on this doc as necessary.

RIP is Routing Information Protocol and is used on TCP/IP networks to
spread routing information. It however is not readily adaptable to the
radio network without some careful planning. It is NOT a flooding system
like NET/ROM uses and thus it is more complex. The damage that can be done
by speading false or incorrect information is more serious.

I don't intend to bore you with the details, only to explain the advantages
and disadvantages of using RIP, and how to get going.

To use a real-life situation I've reproduced part of the local network as
it runs at present. On top of this I'll then explain how RIP could make it
easier. 

We currently have a BIG problem in dropping NET/ROM routing in favour of 
RIP and that is that a lot of people are not yet using a version of NET with
RIP available.


g1emm ----- g4bio
 \           / \           g1sls
  \         /    \           /
   \       /       \        /
    \     /          \     /
     \   /             \  /
     g1wkk             g1bys 
                        |  \
                        |    \
                        |      \
                        |        \
                      g6jha     g8zhr

Assuming that everyone is running RIP, then the following information ONLY
is added to the routing table ( using route add host )

g1emm          g4bio          g1bys         g1sls          g8zhr        
-----          -----          -----         -----          -----         
rou add g1wkk  rou add g1bys  rou add g1sls rou add g1bys  rou add g1bys
rou add g4bio  rou add g1emm  rou add g7gbq
               rou add g1wkk  rou add g6jha
                              rou add g8zhr

g1wkk          g7gbq          g6jha
-----          -----          -----
rou add g1emm  rou add g1bys  rou add g1bys
rou add g4bio

Then you will need to set-up who you will send RIP to and who to accept it
from. This is quite easy. If you are a stub in the network then accept
information from your gateway, but don't broadcast it. If you are used as
a gateway then accept from other gateways, and broadcast to all hosts 
including stubs. See below using our example network.

Each route times out after 4800 seconds ( I haven't worked out if this bit
is configureable ( Kelvin?? )), unless updated. A route cost of one is added
by default but you can change this by adding a metric value to your route add
commands.

So in our example network the following commands are entered.

g1emm               g4bio                g1bys               g8zhr
-----               -----                -----               -----
rip accept g4bio    rip accept g1emm     rip accept g4bio    rip accept g1bys
rip add g4bio 1200  rip add g1emm 1200   rip add g4bio 1200
rip accept g1wkk    rip accept g1wk      rip add g1sls 1200
rip add g1wkk 1200  rip add g1wkk 1200   rip add g8zhr 1200
                                         rip add g6jha 1200
                                         rip add g7gbq 1200

g1wkk               g6jha              g1sls              g7gbq
------              -----              -----              -----
rip accept g1emm    rip accept g1bys   rip accept g1bys   rip accept g1bys
rip add g1emm 1200
rip accept g4bio
rip add g4bio 1200

As you can see the routing not that difficult but requires thought. DO NOT
add cluster routes unless you really mean it. You can break the routing if
you do. Only add to your routing table hosts that are directly accessable
to you.

To start RIP running you must have a line 

start rip 

in your autoexec.net. It is also necessary to have the line RIP merge if
you take routing information from more than 1 host. If a particular host
is sending bogus routes, you can use

rip refuse <host>

to ignore their routing information.


To start the ball rolling, right at the end of your autoexec.net add lines
like 

rip request <host>

for all your gateways. This will request the lastest information from your
gateways and add it to your routing table.

Thats it, not too painful I hope.

Advantages
----------

1, With this system is that we are no longer NET/ROM dependant
except where necessary, and thus our packet overhead is reduced. 

2, Also a simpler set of route add's is all that is required to read in 
upon boot.

3, More reliable IP routing to distant hosts.

4, Dynamic IP routing as opposed to fixed routing with NET/ROM bodge.


Disadvantages
-------------

1, Easily broken routing if cluster routing is used.

2, Difficult to use in a mixed NET/ROM / RIP routing environment.


As far as I'm concerned the quicker we get RIP going the better.

Your comments and suggestions on this are welcome, plus results of any
over the radio tests.

Keith Brazington
27/3/90

To start accepting the RIP broadcasts, merely say:

start rip

If you're not acting as a gateway to anyone,  this is all you need do --
your system will begin to passively monitor its interfaces for broadcast
routing  packets  and  it will automatically add routes to  the  routing
table.   It may take up to 30 seconds on an Ethernet for the table to be
built (this assumes a broadcast rate of 30 seconds, which is standard on
Ethernet).   If you want to get started faster, you can give an optional
IP address to the command:

start rip [128.96.160.0]

This  broadcasts  a  RIP "request"  packet on the local  subnet,   which
triggers  each  gateway within earshot to send you its  routing  tables.
(This requires knowledge of the local IP broadcast address,  plus an ARP
entry for same.  Read on to find out about both of these things.)

If  you  are also acting as a gateway,  then you'll want to  enable  the
transmit  routines.   First add ARP entries that map the local broadcast
address for each of your networks to the correct hardware address.   For
example,  the IP broadcast address on my shack ethernet is 128.96.160.0,
so I include the line

arp add [128.96.160.0] ethernet ff:ff:ff:ff:ff:ff

in  my  /autoexec.net file.   Then i enable the broadcasting of  routing
info with the line

rip add [128.96.160.0] ethernet 30 6

This  means  "broadcast"   your routing tables every 30 seconds  on  the
interface  named 'ethernet',  using IP destination address 128.96.160.0.
Generate triggered updates as necessary, and use spit horizon method."

On a packet radio channel, i might use the following lines:

arp add [44.64.0.0.] com1 qst-0

rip add [44.64.0.0.] com1 600 7

The last parameter in the "rip add"  command is the flag parameter.   It
is the sum of the following possible values:

1 - Include  a  host-specific route to yourself in each  update.    (Not
    needed  if you're already advertising a route to the network  you're
    on.)

2 - Use  spit horizon updating;  that is,  omit all routing entries that
    point  to the interface being used on the broadcast.   (This reduces
    the chances of routing loops forming).

3 - Generate  triggered  updates as necessary on this interface,   i.e.,
    whenever a metric changes in the routing table, immediately generate
    a  broadcast on this interface with the changed entries.   If  split
    horizon (bit2) is also set,  use "poisoned reverse",  i.e.,  for any
    routing  table  entries that point to this interface,  include  them
    with  an infinite metric (RIP defines 16 to be infinity)  instead of
    leaving  them out as happens during a normal routing broadcast  when
    split horizon is set.  Triggered updates helps spead the word faster
    when links fail, reducing the chances of a temporary loop forming.

For Ethernet, I recommend a flag value of 6 (triggered updates and split
horizon).   On SLIP links,  use 6 or 7, depending on whether you need to
emit a host-specific route to yourself.  On a packet radio channel where
everyone  is  not  fully connected (the usual case),  use  7  and  DON'T
advertise  any  routes to the subnet unless you can reach every  one  on
that subnet.

(A  packet  radio  channel is best modeled as a collection of  point  to
point   links  links  since  it  rarely  fits  the  model  of  a   fully
interconnected  subnet  like  Ethernet.)   Note that you  dont  have  to
broadcast your routes; you can direct them to a specific set of stations
by  using their names or addresses in the "rip add"  command.   You  can
have  any  number of such commands per interface,  with the  only  limit
being channel traffic overhead.

An experimental parameter is available to control somthing i call "route
merging".    If you say "rip merge on",  then an incoming route that  is
more  specific than the one you already have in your table is ignored if
they both point to the same gateway.  For example, if you already have a
default  route  that  points to gatway "foobar",  then  any  route  that
arrives  from  gateway foobar will be ignored because ot put it  in  the
table  would  not cause any change in the routing of packets  --  they'd
still  go  to foobar anyway.   Properly used,this should save a  lot  of
routing table space.

You  can  trace the automatic routing messages and controls by the  "rip
trace"  command;  it takes a numeric parameter.   "rip trace 0" disables
tracing,  "rip trace 1" generates messages only when routes change,  and
"rip trace 2" shows you everything, even when things are stable.

If  you want to ignore routing broadcasts from a certain gateway  (e.g.,
because it can't hear you), say

rip refuse hostname

where  'hostname'   is a domain name or [ip address]  of  the  offending
gateway.  To reverse this, just say

rip accept hostname

This  manual  filtering will probably do until I'm able to  devise  some
sort  of  link connectivity algorithm and protocol than can analyze  the
quality  of the path between your station and each of your neighbours so
routing packets can be filtered automatically.  I have an idea how to do
this  -- by broadcasting periodic status packets containing received and
transmitted  packet count statistics and using such packets to determine
how well you're being heard.

Thanks  to N6TTO for contributing the original version of this code that
was the starting point for my hacking over the past week or so.


*** EOF
