23 May
2017
23 May
'17
12:19 p.m.
As Marius and I both noted, that's a limitation of
Microtik and the > use of RIPv2 instead of RIP44. rip44d and ampr-ripd don't care
about
the subnet mask of the source and destination IP addresses.
That's actually a limitation on how multicast works. In usual
circumstances, a router does not listen to multicasts not originating
from the subnet its interface is connected to.
Ad it applies to broadcasts, too, with some exceptions like DHCP servers.
And this is a IMHO normal behavior. In this way, one can share a
physical connection for multiple subnets without interference between
them, and avoid reception of unwanted data that could interfere with
proper network functionalities.
Regarding the mandatory use of 44net clients: Any RIPv2 client can
receive the ampr multicasts which do conform to the RIPv2 standard
(except IGMP subscription for 224.0.0.9, which is no problem). The issue
is that a standard RIPv2 client will interpret those routes as all
needing to go via 44.0.0.1 (the originator of the RIP packet).
So the RIP multicasts are standard RIPv2, we just want to use the data
in a different way, and here the daemons and the router scripts come
into play.
So, for ANY RIPv2 capable router the following apply: If you can receive
RIPv2 and put them in a separate VRF/routing table out of the way of the
main routing table, you can use those routes to construct by scripting a
list of tunnel interfaces and correct routes via thos interfaces and
place them into the main routing table, thus having a working full mesh
on your router. So this should be the starting point for possible Cisco
IOS/ Juniper JunOs/Ubiquiti EdgeOS implementations.
Marius, YO2LOJ