1 Oct
2018
1 Oct
'18
7:07 p.m.
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
>>>
>>>