Hi Rihard,
Regarding the usage of RIPv2, here are some details...
To be able to set up our mesh network, we need to know, for each mesh partner, the subnet with its mask and the gateway, to which we need to send the encapsulated traffic. That means, e.g. traffic to 44.182.20.0/24 needs to be encapsulated via ipencap (IP protocol 4) and sent to 89.122.215.236. On the reverse side, all encapsulated traffic from 44.182.20.0/24 comes in and needs to be decapsulated.
Decapsulation works for all incoming traffic, but to be able to encapsulate traffic, we need to tell the IPIP driver, which is point to multipoint capable, to which destination to encapsulate to. This is done by setting up special routes in the system. Assuming the tunnel interface is tunl0, this goes something like: ip route add 44.182.20.0/24 via 89.122.215.236 dev tunl0 onlink
Now, to gather the needed info for setting up these tunnels, there was the traditional way, by getting the encap.txt file manually, and parsing it via a script (called munge script).
To automate this and to adapt to fact changing gateway IPs, there was a need to get this data automatically to the GW's. And it would have been nice to get some authentication, to be sure the data is genuine. Here comes RIPv2 into play. The data carried by RIPv2 is exactly what we need: A list of subnet IPs, netmasks and a gateway IPs. And there is simple password authentication available, too.
In a standard way, RIP packages give you subnet routing infos but the gateway to which data has to be sent is the IP of tha machine which sent that data. In RIPv2, the gateway information is used only to optimize routing. So, in a standard RIP way, the info would translate to: ip route add 44.182.20.0/24 via 44.0.0.1 Which is obviously wrong, since it does not define the proper gateway device and encapsulation endpoint. Freely translated, this will get all of your outgoing 44net traffic being encapsulated and sent to 44.0.0.1, where it will be dropped.
Here come tools like ampr-ripd into play: They listen to the RIP information sent every 5 minutes by ampr-gw (44.0.0.1), check its authenticity by password and dynamically generate the proper routes for the P2MP tunnel interface, which is not possible by standard RIPv2 handling.
I hope this clarified the issue.
Marius, YO2LOJ