I'm experimenting with AMPR, and I have been allocated a 44.x.x.x IP address block which I'd like to use via an IPIP tunnel. There are some tutorials out there but none of them explain what happens behind the scenes. Can anyone explain?

In particular, When the IPIP tunnel is created, no endpoint is specified (see script https://github.com/NotMikeDEV/RIP44/blob/master/rip44.lua). When I send packets through the tunnels, how does Linux know where its endpoint is, i.e. where to send the packet?

My understanding is that this not just a mere tunnel but a mesh network. How does it work?

  • $\begingroup$ By AMPR, do you mean AMPRNet™, ampr.org ? $\endgroup$ Commented Aug 17, 2021 at 13:03
  • $\begingroup$ Correct, AMPRNet. $\endgroup$
    – divB
    Commented Aug 18, 2021 at 6:43

2 Answers 2


FYI, I'm writing this as someone experienced with Linux IP routing, but only superficially familiar with AMPRNet.

All of the routing appears to happen through ordinary Linux facilities which can be inspected and modified with ip. AMPRNet appears to broadcast route advertisements to a multicast address, and this RIP44 daemon receives them and then runs ip to configure the kernel with the routes it discovers.

The lua script begins by configuring a rule to route traffic to LOCAL_SUBNET to the main routing table:

os.execute("ip rule add to " .. LOCAL_SUBNET .. " table main priority 20")

The main table is the route table Linux uses ordinarily, but it does so by a default rule which has a low priority. The script just adds a higher priority rule which does the same thing only for your local subnet.

Then, it adds a slightly lower priority rule to send everything else to a routing table called ROUTING_TABLE:

os.execute("ip rule add from " .. LOCAL_SUBNET .. " table " .. ROUTING_TABLE .. " priority 25")

The lua script adds routes to this other routing table (ROUTING_TABLE) according to the RIP44 multicasts it receives in the process_route() function. The most relevant line is 78:

os.execute("ip route replace " .. prefix .. " via " .. gateway .. " onlink dev tunl0 table " .. ROUTING_TABLE)

prefix and gateway are values the daemon received from a RIP44 multicast. onlink dev tunl0 is the part that makes the AMPRNet traffic use the ipip tunnel. The option is described by ip-route(7) as:

onlink pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix.

The table option tells ip route to add this rule to this table containing only AMPRNet routes rather than the default main table.

Because these routes are not in the main table you will not see them with ip route show unless you ask to see the table specifically with ip route show table ROUTING_TABLE (replacing ROUTING_TABLE with the value configured in rip44.conf) or all the route tables with ip route show table all.


I just started fooling with this myself and I'm coming at this from a Mikrotik-style configuration. But you have to create an initial IPIP tunnel to UCSD ( in order to receive the RIP44 announcements. RIP44 is a little different from RIP in that it does not direct you to the announcer for the routes advertised; it advertises the next hops of the tunnel endpoints for each route. This is why a lot of systems need a bodge written, because most systems do not have native support for RIP44. Once you have the announcements, you can populate a routing table and use it as a template for how to get to what endpoints for what routes. This is very high level and not in the weeds. It is also not entirely complete. I hope that it helps.

  • $\begingroup$ It's always nice to hear from someone with direct relevant experience! Nice first answer! We'll look forward to more from you. $\endgroup$
    – rclocher3
    Commented Jan 3, 2022 at 23:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .