Port of G8BPQ's RIP 98 to TNOS ------------------------------ 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: Only six bytes are used per entry. Variable length subnets are supported. No underlying broadcast capable protocol is required. A bare minimum of information is supplied per 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, looked after by Jonathan and Terry Dawson. This can currently be found at: http://www.cs.nott.ac.uk/~jsn/ 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. 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 (default is on) When off, incoming RIP 98 frames are ignored. The presence of this rip98rx command within the 'rip' submenu indicates that your TNOS should be capable of RIP 98 operation. Reception of incoming RIP 98 frames: ------------------------------------ To enable the reception and 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). Decide whether you will act upon incoming RIP frames from anyone who can be bothered to send them to you, or from the outset, stay restricted to a few trusted friends. In the case of the former. Ensure that 'rip filter' is off. If there is a known local 'bad egg' you can lock their rip frames out with: rip refuse e.g. rip reject 44.128.0.254 If it's just your friends you'd like to receive frames from, use: rip filter on and add their ip addresses using: rip accept e.g. rip accept 44.128.0.253 You can use 'rip accept' and 'rip refuse' a number of times to add multiple hosts. If you get in a twist, a summary of accepted / rejected hosts appears when the 'rip status' command is used. The value of 'rip ttl' sets the 'timeout' value of a rip added route in receive, except when you are also sending rip frames to that host. See the later caveat. Outbound RIP 98 frames: ----------------------- 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, it tends to get chucked out by RIP. 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. Format of RIP 98 entry: rip add [] [] [AUTH ] [RD ] For rip 98, we only make use of the first four fields after 'rip add' The destination address of your mate who's going to receive your RIP 98 frames. 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) [] 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. 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. 01 Split Horizon Processing - Omit all routes which 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 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). [] 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. 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 an 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