3 Oct
2018
3 Oct
'18
12:15 a.m.
Thanks Aaron! Will definitly test that this week.
> Le 1 oct. 2018 à 19:09, Aaron Jackson <aaron(a)aaronsplace.co.uk> a écrit :
>
> I'm happy to post here now. Although, I'm not sure everything is working
> correctly yet. The routes are definitely setup via rip44d:
>
> # ip route | grep ^44 | head
> 44.0.0.1 via 169.228.34.84 dev tun0 onlink window 840
> 44.2.0.1 via 191.183.136.1 dev tun0 onlink window 840
> 44.2.2.0/24 via 216.218.207.198 dev tun0 onlink window 840
> 44.2.7.0/30 via 98.208.73.100 dev tun0 onlink window 840
> ...
>
> Here's what you need to do to get rip44d running:
>
> curl -O https://raw.github.com/hessu/rip44d/master/rip44d
> chmod u+x rip44d
> configure
> set system package repository wheezy components 'main contrib non-free'
> set system package repository wheezy distribution wheezy
> set system package repository wheezy url http://http.us.debian.org/debian
> commit
> save
> sudo apt-get install libio-socket-multicast-perl
> sudo ./rip44d -i tun0 -p <the password>
>
> ** Definitely do not run apt-get upgrade - warned on the Ubiquti Wiki **
>
> I still do not have my routing working properly though. I am unable to
> ping any anything in 44/8. Still trying to figure this out, but having
> fun in the process. It is probably something obvious, although they are
> definitely going out the right interface.
>
> $ ping 44.0.0.1
> PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data.
> ^C
> --- 44.0.0.1 ping statistics ---
> 206 packets transmitted, 0 received, 100% packet loss, time 205183ms
>
> $ sudo tcpdump -i tun0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
> 23:59:13.362459 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq
200, length 64
> 23:59:14.362442 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq
201, length 64
> 23:59:15.362404 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq
202, length 64
> 23:59:16.362477 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq
203, length 64
>
> $ ip route get 44.0.0.1
> 44.0.0.1 via 169.228.34.84 dev tun0 src 44.139.48.22
> cache expires 509sec mtu 1472 window 840
>
> Hopefully the above to get rip44d will be of some use to someone anyway.
>
> Thanks,
> Aaron, M6PIU
>
>
>
>> On 1 October 2018 at 23:28 BST, pete M wrote:
>>
>> It would be nice if you would make a post in here how you managed to install
ripd44 on the edgerouter. Then the manager of the wiki could also post it on the wiki.
>>
>>
>>
>>> Le 1 oct. 2018 à 18:09, Aaron Jackson <aaron(a)aaronsplace.co.uk> a écrit
:
>>>
>>> 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
>>>>
>>>>