Dynamic routing protocols are not in widespread use in the amateur radio TCP/IP environment. This is mostly due to the effects of 'anomolous propagation', and that most routing protocols transmit their information in 'broadcasts' to be acted on by all stations who can hear them. A slight 'lift' in conditions can cause havoc lasting a few hours when they subside, as it takes time for the anomalous entries to be purged from routing tables.
RIP 98 was originally devised by G8BPQ, probably for use in the "bolt-on goodie" IP router for the G8BPQ netrom node, and has quite a few outstanding features to recommend it in a the typical amateur radio TCP/IP environment:
A bare minimum of information is transmitted per route entry. Four address bytes, one subnet width (mask) byte, and the metric, making six bytes in total.
Routing information is sent to specific hosts, and not 'broadcast' This saves disruption to a radio based network when say a lift occurs, or a broadcast is received as a plane flies over, leading to short-lived and unreliable routes being propagated through the system.
A RIP 98 daemon written by Jonathan Naylor is also available for the Linux operating system, and is included in the 'ax25-utils' package. It is documented in its 'man' pages - man rip98d man rip98.conf
Since no broadcast capable protocol is required, routing information can be exchanged between a RIP 98 capable Linux kernel, and a TNOS equipped with RIP 98 over the internal 'slip' link commonly found in setups where TNOS runs under Linux. Some other routing protocols such as RSPF rely on 'broadcasts' and the frames have to be identified as such by the protocol bearing the IP frame (e.g. AX25 frames to QST-0), clearly, this is not possible over SLIP links. The benefits of using RIP 98 in this situation is that an update to a routing table in one entity is automatically propagated to the other, and there is no need to manually update both routing tables.
Within TNOS, the capability exists to refuse versions of RIP lower than a certain number. RIP 1 does not support variable length subnets on the same port, and a 'rip reject' command is provided to ensure that incoming rip frames can be discarded if they are below the desired version. Since a TNOS may wish to act on say, RIP 2 frames, but not RIP 98, an additional command has been provided for the paranoid.
rip rip98rx <off|on> (default is on)
When off, incoming RIP 98 frames are ignored.
The presence of this rip98rx command within the 'rip' submenu indicates that your NOS should be capable of RIP 98 operation. RIP 98 was added to TNOS in version 2.22.
Reception of incoming RIP 98 frames:
To enable the reception and the acting upon of received RIP 98 frames.
In your autoexec.nos, don't forget to 'start rip'. Make sure that you do not set 'rip rip98rx' to 0 (off).
The bad news is that once activated with start rip your RIP server will act on any frames sent to you. If there is a known local 'bad egg' you can lock their rip frames out with:
rip refuse <ip address> e.g. rip refuse 44.128.0.254
and to reinstate them into your 'good books' use:
rip accept <ip address> e.g. rip accept 44.128.0.254
The rip filter <on|off> command when enabled just stops 'default' routes entering your table from any host.
You can use 'rip refuse' a number of times to add multiple hosts. If you get in a tizz, a summary of refused hosts appears when the 'rip status' command is used.
The value of 'rip ttl' sets the 'timeout' value of a received rip added route in seconds, except when you are also sending rip frames to that host. See the later caveat.
Pick your victims. More than likely as not, they'll be your neighbours RF wise (or your Linux kernel), unless you're going to try experimenting with some really natty stuff like 'encap' and 'mobile IP' (now there's an idea, watch out for RIP 99 !!)
It's a good idea to have a static route already entered for them, because if you try to do a 'rip add' to host which is not already in your routing table, how is the RIP transmission going to know how to get to them ? (in any case RIP will chuck your 'rip add' entry out !)
Please note that the TNOS implementation of RIP 98 does not 'loop back' any routing table entry where the receiver of the RIP frame is shown as the 'gateway' for that entry. At the time of writing, the Linux RIP98 daemon is quite happy about echoing a route learned from an adjacent host back to it - this can cause routing loops !
Format of RIP 98 entry:
rip add <dest> <interval> [<flags>] [<ripver>] [AUTH <password>] [RD <routing domain>]
For rip 98, we only need to make use of the first four fields after 'rip add'
<dest> The destination address of your mate who's going to receive your RIP 98 frames.
<interval> Time in seconds between RIP updates to this station.
A caveat applies here. Normally we'd expect the 'timeout time' of a route sent to us by anyone to be the value of 'rip ttl'. If we have a route set up to this host, the timeout value becomes the *outgoing* time interval multiplied by four, so you can see that it's good practice to have the same value of 'interval' used between two hosts. If your friend sends you their table once an hour, and you decide to send once every five minutes, your partner's routes will start to vanish from your table after 20 minutes ! (RIP first applies a metric of '16' to the route, before banishing it completely. If an update is received during this 'hold-down' period, it is ignored)
[<flags>] The (lucky) flag value I've been using is 13. It is actually the 'hex' value of the flags you input, straight, without any '0x' business. It might actually be better to use a value of 11, since the route to any neighbour making use of non-broadcast RIP should be a static one !
As KA9Q is an "engineer's" stack, here are the values that make up the flag for those who 'must play' - particularly with split horizon.
| Flag value (Hex) | Description |
|---|---|
| 01 | Split Horizon Processing - Omit sending all routes who, or whose gateways, are on the same interface as the 'victim host' of your RIP frames. (but see poison reverse). |
| 02 | Include our own host as a destination in the RIP transmissions. |
| 04 | Broadcast (We don't want to broadcast with RIP 98 - so 0). |
| 08 | Multicast (and 0 again !). |
| 10 | Poison Reverse - If split horizon is in use, rather than omit entries referring to hosts on the same port as the RIP transmission, send them marked with a metric of 16 in response to a 'triggered update' - like where something has changed in our routing table. |
| 20 | Authentication in use (0 with RIP 98). |
[<ripver>] The version of RIP to be used when sending RIP frames to that host. Try using 98 to get the best results with RIP 98 !
To send RIP 98 frames every half an hour to a host using a test address, I might use:
rip add 44.128.131.252 1800 13 98
The best place for 'rip add' lines is probably near the end of your autoexec.nos after the routes have been added, and the rip server started.
Beginners may wish to start by making sure that 'rip merge' is off. This can help you decipher exactly what is going on in your routing table should 'Murphy' intervene.
Rip Command Reference:
The following has mostly been filched from the 'README.NOW' document supplied with the JNOS source. In its entirety, it is perhaps the most useful document ever written about a NOS !
Resumes the acceptance of RIP broadcasts from a specific node previously banned with rip refuse given in the <gateway> field. e.g. rip accept 192.55.248.1 or rip accept skeggi.tcman.ampr.org
rip add <dest> <interval> [<flags>] [<ripver>] [AUTH <password>] [RD <routing domain>]
Adds a node to the list of stations that are to be broadcast to with the local nodes routing table. <dest> is the destination node, usually a broadcast address except in RIP 98. < interval> is the number of seconds between broadcasts. <flags> are the RIP flags used (see below for the flags), it is a hexadecimal number. <ripver> is the version of the RIP broadcasts. This may be a 1, 2 or 98 in capable servers. The AUTH identifier preceeds the authentication password to be included with the RIP broadcasts to this destination. The RD identifier preceeds the routing domain number. This number must range from 0 to 65535. The authentication fields and routing domain fields are only valid with RIP-2 broadcasts. The password must be 16 characters or less. Printable ASCII characters are recommended, but not required.
0x01 Do split horizon processing
0x02 Include ourselves in the routing broadcast
0x04 Broadcast RIP packets (default type)
0x08 Multicast RIP packets (not implemented) (RIP-2)
0x10 Poisoned Reverse on
0x20 Authentication data to be included in broadcast (RIP-2)
Recommend flags are Split Horizon with Poison Reverse or 0x11.
If setting the 'Include ourselves in the routing broadcast' (02) flag, keep an eye on the proceedings over the air. It's sometimes possible for two (or more !) routers to generate a continuous stream of RIP response frames which contain only information referring to themself. TNOS 2.30 users who 'roll their own' source code can download a patch to overcome this.
Authentication and routing domain data entered here only applies to the outgoing RIP broadcasts. See rip authadd and rip authdrop for entering acceptable passwords and routing domains.
Examples:
rip add skeggi.tcman.ampr.org 30 0x31 2 AUTH frodo RD 2
rip add biggus.tcman.ampr.org 300 0x11 1
rip proxy <src> <dest> <interval> [<flags>] [AUTH <password>] [RD <ROUTING DOMAIN>]
This command adds a node to the list of stations that are to be broadcast to with the local nodes routing table. <src> is the node that the broadcast will "point" to. <dest> is the destination node, usually a broadcast address except in RIP 98. <interval> is the number of seconds between broadcasts. <flags> are the RIP flags used (see rip add for the flags), it is a hexadecimal number. The AUTH identifier preceeds the authentication password to be included with the RIP broadcasts to this destination. The RD identifier preceeds the routing domain number. This number must range from 0 to 65535. The authentication fields and routing domain fields are only valid with RIP-2 broadcasts. The password must be 16 characters or less. Printable ASCII characters are recommended, but not required.
Proxy RIP is tricky, complex and not needed for normal use. Do NOT use proxy rip unless you understand what you are doing. Proxy RIP's primary use would be to advertise routes to another machine that is aquiring routing information via another routing protocol. See RFC 1388 for further details.
rip drop <dest> [<domain>]
Removes a routing broadcast entry. If a RIP-2 broadcast was entered, the correct routing domain needs to be entered, since it is possible to broadcast multiple routing domains to the same address.
Example: rip drop skeggi.tcman.ampr.org 2
rip authadd <interface> <routing domain> [<password>]
Adds an acceptable routing domain and optionally a password to a specific interface.
Examples:
rip authadd ax0 2 frodo
rip authadd en0 3
rip authdrop <interface> <routing domain>
Removes an acceptable routing domain (and password if any) from a specific interface.
Example: rip authdrop ax0 2
rip filter <ON|OFF>
Will cause advertisements to the default route (0.0.0.0) to be tossed and ignored. By default this is off. This can serve as a LID filter. Default routes should NOT be advertised, unless there is a specific reason (ie this machine is a gateway to the rest of the Internet).
rip merge <ON|OFF>
Will cause overlapping routing entries to be merged into one routing entry. For example n0bel.tcman.ampr.org is a route to 192.133.30.0/28, and 192.133.30.16/28, with merging on this would become a single entry of 192.133.30.0/27. It's best for new RIP users to leave 'rip merge' off, so the routing table can be more easily inspected for 'nasties' !
Will reject all RIP broadcasts from the gateway station. rip accept is the opposite. By default all stations are accepted.
rip reject <version>
Used to ignore older RIP broadcasts, as they may cause undesirable routing table alterations. The version number is the version number and below that are ignored. RIP version 0 (XNS RIP) is always ignored. The default is 0. To ignore RIP-1 broadcasts: rip reject 1 would do the job.
rip request <gateway> <version>
Asks the gateway station to send a routing table now, rather than waiting for periodic updates. It's also possible to specify the version of RIP used. If you're the originator of the request, and your host is listed in the victim's table of RIP servers, then omitting the version will allow RIP to use the version normally used between you, otherwise the default version is RIP-2. NOS's responding to RIP Request frames usually omit any routes pointing to the same port that the request was received on.
rip rip98rx <off|on> (default is on)
Enables you to decide whether capable servers should act on received RIP 98 frames.
rip status
Displays various statistics for RIP-1, RIP-2 and RIP98 (if fitted) RIP broadcasts, RIP refusals, and acceptable Interface, Domain and Password combinations. It also displays the refusing version level. The default interface is for every interface. Thus unless removed, any RIP-2 broadcast with a domain of 0 does not require a password and will be accepted.
rip trace <level> [<file>]
Begins tracing RIP operations. The higher the level, the more detailed the logging. Level 9 is the useful maximum, with level 0 (the default) being no logging. If a file is specified, logging will go to that file, else logging appears on the console.
rip ttl <time-To-LIVE>
Sets the time-to-live in seconds before RIP entries expire from the routing tables. The default should work for almost all cases.
Finale.
If you're using the Linux RIP 98 daemon to play with, just a little observation on a feature observed within it. I've noticed that a 'more specific' route can get gobbled up by a less specific one when the latter's metric is smaller, or the same. It's a good idea to give "catch most" routes like 44.0.0.0/8 a higher metric than the highest of those locally seen in use.
I would just like to thank John Wiseman, G8BPQ; Jonathan Naylor, G4KLX and David Mackay, G4HJG for providing a good reason to waste the 1997 Easter weekend. The devil does indeed find work for idle hands.
73, Gareth Rowlands, G4HIP
| internet: | gareth@lightfox.demon.co.uk |
| amprnet : | g4hip@gb7bbc.ampr.org |
| AX25 BBS: | G4HIP@GB7BBC.GB7HSN.#32.GBR.EU |
Updated: 5 June 1999