Re: [44net] RIP44 vs RIP v2

Tom, a little deeper insight on this, because some may be curious :-) The RIPv2 actually transfers just a list of destination network/netmask, gateway and distance data from one host to another. e.g. from 44.0.0.1 (ampr-gw) to 224.0.0.2 (multicast) network: 44.182.21.0/255.255.255.0 gateway: 89.122.215.236 distance: 1 The difference appears in how the routes are interpreted. From a point of view of a regular RIPv2 processing, the router will know that the specific network is reachable via THE SENDER'S IP AND RECEIVE INTERFACE that sent the announcement. So in a regular RIPv2 system this will translate this to: route 44.182.21.0/255.255.255.0 via 44.0.0.1 dev ampr-gw metric 2 which is obviously wrong in our case, and would send all traffic via the ampr gateway. The gateway information is used only to mitigate between routing decisions in some implementations, if there are multiple routes with the same distance. Our routing daemons interpret this in a different way, using the gateway information to get the remote tunneling endpoint and relies on some specific behavior of the linux kernel tunnel driver: route 44.182.21.0/255.255.255.0 via 89.122.215.236 dev tunl0 metric 2 This tells the kernel to encapsulate traffic to 44.182.21.0/24 via the IPIP tunnel tunl0 using 89.122.215.236 as the encap endpoint, which is exactly what we want. This technique is available ONLY for the linux tunnel driver. E.g. for the mikrotik implementation, the scripts create an individual tunnel to the gateway for each link partner based on the RIP data. The user space implementation done in amprd offers a virtual network interface for all 44.0.0.0/8 traffic and solves all routing issues inside its code, without using the kernel routing tables or the tunnel driver, using the same RIPv2 information. (Maybe this shoul actually land in the Wiki) Marius, YO2LOJ On 21.12.2017 21:53, Tom Cardinal wrote: