I got a situation i really don't comprehend - maybe there are wiser people around here which could enlighten me.

I got an IPIP tunnel which allows access to the ampr domain (44.0.0.0/8). This tunnel forwards a subdomain to its endpoint (44.182.21.0/24 in my case) and also distributes its routing paths for the whole 44 domain via RIPv2 multicasts. The routing elements contain a IP/mask pair and a gateway, the later being outside the 44 domain, but accessible via the tunnel. RIP multicasts are from 44.0.0.1 to 224.0.0.9 (RIPv2 multicast).
Now there are 2 problems...

First, the RIP listener needs to have an interface set with a netmask of /8 (e.g. 44.182.21.1/8) or else it won't process the routes. That means i will always have a direct connected route with smaller metric than the ones provided by RIP which show up with metric 120. Do the RIP routes take precedence anyway?

And the second issue is related to how routes are taken over by the router.
Now RIP routes have each a gateway set: But these translate wrong into the routing table: and do not respect the gateway provided by RIP.

Could anyone suggest a workaround on this or do i have to live with it?

Thank you.
Marius

Now i just for info, and to show what 'read the *** manual' means...

This is an non-issue. The tunnel IPIP i wanted to set up is a IPIP-NOS tunnel which is not supported by Mikrotik routers.
And the RIP messages non-standard.
IPIP-NOS tunnels need to build up a separate tunnel for each destination, using the gateway IP as endpoint.
Since Mikrotik's implementation is PtP only, this is not supported.
AFAIK, only Linux and some Cisco routers support this. And NOS derivates of course.

Have a nice day.
Marius

I stumbled on the same issue and it is disappointing that it is actually not possible to use Mikrotik for AMPRNet.

Have you managed to do this other way? How can I contact you for help?

There is no "easy" solution for this.

As I stated earlier, the ipip encapsulation in RouterOS assumes a PtP IPIP link with one source and one destination IP, while the Linux IPIP implementation accepts a point to multipoint setup also.
In Linux, these multiple destinations are set by adding routes with different gateways via that interface, these routes being provided dynamically by the rip44d which "digest" the RIPv2 messages received from 44.0.0.1 and injects them into the routing table.
Standard RIP implementations (as in Mikrotik) will add those routes using the RIP sender as the gateway, resulting in the described behavior. So this is a no-go for our purposes.

A viable approach would be to get the routes via encap.txt and use some kind of script to add them to RouterOS while creating a PtP IPIP interface for each entry in the encap file, resulting in 389 interfaces (the current number as I write) - Tom Hayward KD7LXL provided such a script on the 44net group.

The second approach, the one I use in my setup, would be to use an encapsulation server on Linux (a Raspberry Pi would do) which would take care of the encap providing the local IPIP tunnel endpoint and also would provide forwarded RIPv2 packets via a modified rip44d script which will be properly used by RouterOS (with this encapsulation server as gateway).

I personally favor the second solution, since it will provide a dynamic setup.

I agree with you both. There has to be a better way. I want to use AMPR for connectivity, but I'm being reduced to having to run a Linux server. Not what I want as a HE router on my network.
I posted on the 44net forum tonight that I want a Simple connection. Something that doesn't use a service specific load or daemon. I find that rather obsurd that they do it.

Anyway.. let me know if you want to do some testing or experimenting. For now, I'll park my 44/8 reservations, until that entire network comes around.

What I could understand so far, you have to create IPIP tunnel to EACH living subnet in 44/8 and then set route to that subnet using it's IPIP tunnel.

I could not get example of routing settings so I can try to replicate on Mikrotik.

There is another option. You may contact admin of some 44&8 subnet, he could provide pptp or other VPN for you and then you can route through his network using just one route.

There is a hope that they might decide to start using iBGP or something for routing in 44/8.

Neticted, i agree on your later solution. One or two tunnels to someone else, and let them do all the routing. If they do decide to use BGP, I fear it will take a few years to get it going. Unless a few ham's that may also be (W)ISP's step up and offer colo's, then it may move along some faster.

I have heard there are going to be some changes in the next year or so, but have not heard what they are. Hopefully it would help those of us who choose not tu use the Linux solution.

I for one, and planning my HamNet with my own doings. I will use my ISP for some external links outbound from the rest of the network, but not general port 80 type (web traffic for a lack of better term). Mostly BBS, Ham related FTP, some enhanced service hopefully like mumble chat, sms... Things that you couldn't do over normal "Packet" because it was too slow. I do plan on offering connections to Telnet Nodes and RF Packet Nodes through this as well. Kinda a one stop shop concept.
HamWan.org out of the Seattle area is doing this, but they are integrating it into 44/8 too, and offering more of WISP services I believe. I haven't really gotten a handle on what they are offering / providing. There may be a few more of these types of systems out there too, just haven't heard of them yet.

Catch with routing through someone else is that all traffic has to go through his links this spending his resources. I guess that is the main reason why such routing is not in widespread use for 44/8 network - people cannot afford resources to share.

Check out Italian and German hamnets. They use BGP to advertize their subnets publicly.

Trouble is that Law forbids non licenced people to use radio amateur resources, thus, most hamnets choose sipmle soluiton - they do not go public, and when they are not public, it is hard to route without direct VPNs.