3 Oct
2018
3 Oct
'18
9 a.m.
No worries - I had another look last night but for some reason cannot
figure out why I can't get a response back from the gateway. The Pings
go out of the right tun interface and I can receive the routes from RIP
- so bidirectional communication should be possible. Not sure!
I think I'll leave it for the weekend
Aaron
On 3 October 2018 at 00:15 BST, pete M wrote:
> 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
>>>>>
>>>>>