1 Sep
2015
1 Sep
'15
3:32 a.m.
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