NOSintro – TCP/IP over Packet Radio

An Introduction to the KA9Q Network Operating System

by Ian Wade, G3NRW

Chapter 28: IP ROUTING


AX.25 routing, as described in the Chapter 26, is a form of source routing; that is, the entire route to the target is pre-defined at the sending end (the source). At the IP and NET/ROM layers, however, the sending end doesn’t need to know the entire route. Instead, each station along the route forwards packets in roughly the right direction towards the target, on the assumption that the next station down the line does likewise.

This method of routing gives us much more flexibility in getting packets to their destination. The packet radio network is an ever-changing and unpredictable environment — nodes appear and disappear overnight — and so it’s unrealistic to try to plan every hop along the route. Instead, we let individual stations along the way decide how to forward our packets, hoping that those stations can handle local circumstances which we may be blissfully unaware of!

Thus the only likely situation where we need to use AX.25 routing is for local links via digipeaters to neighbouring NOS (IP) stations. Once our packets reach a NOS neighbour, routing will then take place at the IP layer.

This chapter is concerned with how packets are routed at the IP layer. This means setting up the IP routing table to make sure that when NOS receives a packet addressed to another station, it knows where to forward it to.


IP Forwarding

It’s important to recognise which packets NOS will forward. By default, when not actually transmitting, NOS listens on the channel, and will hear packets from all and sundry, addressed to all and sundry. For forwarding purposes, NOS will ignore all of these packets unless they happen to be broadcasts packets, or they are addressed to itself at the AX.25 level.


Fig 28-1: The route add default entry in the IP routing table handles all direct connections; i.e. all connections to stations within radio range and not passing through intervening IP gateways (routers).

For example, in Fig 28-1, the AX.25 destination address is NS9KEN-5, so only Ken’s station will act on the packet — any other stations which hear the packet will ignore it. When the packet passes up to the IP layer at Ken’s station, NOS discovers that the IP destination address is ns9ken, so the packet has reached the end of the line. NOS then passes the packet up to the higher protocol layers for further processing in Ken’s system.

The generic command to add an entry into the IP routing table is route add, and the entry for this particular scenario is very simple:

route add default tnc0

That is, by default all IP packets are transmitted via the tnc0 interface and are intended for local stations within radio range. If you only want to talk to local NOS stations within radio range, and forwarding by other stations is not required, this is the only entry you’ll need in the IP routing table.


Forwarding packets via an IP Gateway

When the target system is not within local radio range, it will be necessary for an intermediate station, called an IP Gateway (or router) to forward your traffic in the right direction. Fig 28-2 shows this situation.


Fig 28-2: Forwarding via an IP gateway. The routing tables at ns9bob and ns9liz contain an entry to route traffic for each other via the gateway (ns9ken).

Bob wants to contact Liz, but as she is out of direct range, Bob uses Ken’s station as a gateway. To launch packets on their way to Liz, Bob needs this line in autoexec.nos:

route add ns9liz tnc0 ns9ken

This tells NOS that the eventual target is ns9liz, but that the packets must initially be addressed to ns9ken. That is, the last parameter on the line (ns9ken) is the IP hostname of the gateway, which must be within radio range. Using ARP, NOS will discover that the AX.25 address of ns9ken is NS9KEN-5, and will use this address in the AX.25 "to" field.

When a packet for Liz arrive at Ken’s station, it passes as usual up to the IP layer. Here, NOS discovers that the IP destination address is ns9liz. As Liz is within radio range of Ken, the existing default IP routing table entry is all that’s required, so NOS just inserts Liz’s callsign (NS9LIZ-5) into the AX.25 "to" field and sends the packet to her.

Liz also needs the following entry in her autoexec.nos:

route add ns9bob tnc0 ns9ken

so that if she wants to talk to Bob, her packets will go via ns9ken.

To summarise then, if a target station is out of direct radio range, you need to set up an IP routing table entry which incorporates the hostname of the next-door NOS station designated to forward your packets towards the target.


Multiple Hops

Taking this a stage further, it should now be clear how to forward packets through a chain of gateways. For example, in Fig 28-3, Bob is sending a packet to Jim via Ken and Liz. To do this, Bob needs another entry in his IP routing table:

route add ns9jim tnc0 ns9ken

This causes the packet to be addressed to NS9KEN-5. When the packet arrives at Ken’s system, it has to be forwarded on towards Jim, but (unlike Liz), Jim is not within range.

Fig 28-3: Multi-hop Forwarding. Each station needs IP routing table entries to forward to the next gateway.

So Ken needs this entry in autoexec.nos:

route add ns9jim tnc0 ns9liz

to forward the packet to Liz.

When the packet arrives at ns9liz, her default IP routing table entry is sufficient for the final leg of the journey to ns9jim.

In other words, as each station along the route forwards a packet, the AX.25 destination address in the packet is the address of the next station down the line, and this changes as it passes through each station. On the other hand, the IP destination address is the ultimate destination of the packet, and this remains the same all the way down the line.


Locally Generated Packets

Not only do all of the above forwarding rules apply when a station receives packets addressed to it at the AX.25 layer, they also apply when packets originate from within the station itself (for example, during an FTP transfer started at the keyboard). Thus when Ken gives the command ftp ns9jim, for example, NOS will forward his packets to Liz, on the assumption that Liz will then send them on to Jim.


Other IP Routing Table Commands

To see the current state of the IP routing table, use the route command:

net> route

Dest Len Interface Gateway Metric P Timer Use
ns9liz 32 tnc0 ns9ken 1 man 3
ns9jim 32 tnc0 ns9ken 1 man 4
default 0 tnc0 1 man 5

The route add commands described earlier place entries in the IP routing table which NOS will include in routing table broadcasts if you have enabled broadcasting (e.g. with the RIP protocol). If you want to add some private entries that you don’t want broadcast to the outside world, you can use the route addprivate command instead. For example, to add an entry for a LAN station via interface en0:

route addprivate lanbox en0

In this case, the route command will display the entry with a capital P to show that it is private:

net> route

Dest Len Interface Gateway Metric P Timer Use
lanbox 32 en0 1
P man 3

To remove an entry from the IP routing table, use the route drop command. For example:

route drop ns9ken


Routing to a group of Stations

In practice you’ll probably find that many of the remote stations you want to contact have similar IP addresses, and that most of them are contactable via just one or two gateways. See Fig 28-4.

NOS provides a convenient shorthand method of setting up the IP routing table for this situation. For example, the IP addresses for Liz and Jim are and respectively. The first 24 bits of their addresses are the same, and Bob forwards traffic for both Liz and Jim through ns9ken. So instead of having separate entries for Liz and Jim, Bob could set up an address mask for all addresses whose first 24 bits correspond to 44.199.45. The mask is given a meaningful name such as region45, and is defined in domain.txt: IN A

Then Bob can use this mask in IP routing table entries in autoexec.nos. For example:

route add region45/24 tnc0 ns9ken

The /24 part of the target address indicates that only the first 24 bits of this address are significant. Liz’s address and Jim’s address both match this mask, so packets for them will be routed to ns9ken.


Fig 28-4: The route add region45/24 command in autoexec.nos handles routing of packets to Liz and Jim via Ken. A separate entry is required for Sue, to force her traffic to be routed via Pam (otherwise it would also pass through Ken).

The route command shows this IP routing table entry as follows:

net> route

Dest Len Interface Gateway Metric P Timer Use
region45 24 tnc0 ns9ken 1 man 3

Note that the Len (mask length) column now contains 24, instead of the usual 32.

Overriding General Routes

Another complication: what happens if Bob also wants to forward to ns9sue, whose IP address is, via ns9pam? (See Fig 28-4 again). If Bob only has the region45/24 entry as above, Sue’s traffic will also go via ns9ken, not via ns9pam as intended.

The workaround here is to put a specific entry for Sue in autoexec.nos:

route add ns9sue tnc0 ns9pam

The routing table now looks like this:

net> route

Dest Len Interface Gateway Metric P Timer Use
ns9sue 32 tnc0 ns9pam 1 man 1
region45 24 tnc0 ns9ken 1 man 3
default 0 tnc0 1 man 5

Because Sue’s entry refers specifically to her full 32-bit IP address, this takes precedence over the region45/24 entry.

In general, then, when NOS refers to the IP routing table to see how to route to a particular station, it attempts first to match the destination address against full 32-bit addresses in the table. If no match is found, NOS then takes the next lowest bit mask size in the table (24 bits in this example) and attempts the match again. This process continues with progressively shorter mask sizes until either a match is found, or until no match is found.

This latter case (i.e. no match at all) corresponds to the default entry in the routing table; i.e. this entry has a bit mask size of zero. Thus if there is no match, the packet will not be forwarded to another gateway, and will only be heard by local stations within radio range.


TheNet X1G

Until recently, the only practical way of forwarding IP packets has been to use NOS in the way just described. This relies on there being an IP route from end to end.

If there are any gaps in the route (i.e. no IP gateways to forward the traffic), it then becomes necessary to use NET/ROM links to bridge the gaps — in this case, IP packets are encapsulated inside NET/ROM packets whilst traversing the NET/ROM network, then decapsulated when they reach another IP gateway.

The way to use NET/ROM to do this is described in the next chapter.

A new development which has removed the need to descend to the NET/ROM level is the emergence of version X1G of TheNet, the NET/ROM "work-alike". See Fig 28-5 opposite.

This version of TheNet contains an IP router as well as a NET/ROM router, making it possible for NOS stations to use the NET/ROM network without encapsulating IP packets inside NET/ROM packets first. Version X1G of TheNet is now popping up all over the place, so it’s likely that NET/ROM encapsulation of IP packets will virtually disappear in the fairly near future.

Fig 28-5: Version X1G of TheNet supports both IP and NET/ROM forwarding. This allows NOS stations to communicate with each other via the NET/ROM network, without having to encapsulate IP packets inside NET/ROM packets.


Back to Contents Page

Back to NOSintro Main Page.

[Copyright 1992-2009 Dowermain Ltd. All Rights Reserved. This page last modified: 21 May 2009]