I see - thanks for that. It makes much more sense. It would be great if
this was described on the Wiki. I'm also interested in updating the
Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting
this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
> Hi,
>
> There is a big difference in how the packets are processed.
>
> The regular RIPv2 sets a route to a specific subnet via the sender and
> interface where the RIP broadcast was received on. The gateway
> information is used only as an optimization element, in case a route
> with to that gateway already exists so that the one with the lower
> metric gets chosen.
>
> In our case, we use the RIP announcements to transport the subnet AND
> gateway information.
>
> So, assuming a point to multipoint interface, if there is let's say an
> announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0
> interface, regular RIPv2 would translate this to:
>
> 44.128.0.0/24 via 44.0.0.1 if ipip0
>
> while ampr rip would translate this to:
>
> 44.128.0.0/24 via 1.2.3.4 if ipip0
>
> In the first case, traffic to 44.128.0.0/24 is sent directly to the
> gateway (the RIP sender), while in the second case it is encapsulated to
> 1.2.3.4.
>
> On a mikrotik router it even goes a step further:
> it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates
> a route
>
> 44.128.0.0/24 via ampr-1.2.3.4
>
> This is the processing in the usual case, for 44 subnets having a 44net
> gateway we assume that the gateway is published by BGP and is directly
> reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there
> are 2 route set:
>
> 44.128.0.1 via default-gw (which is autodetected), and
> 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
>
> So, while the information structure in both cases conforms to the RIPv2
> specifications, its usage is completely different.
>
> Marius, YO2LOJ
>
>