Thanks Aaron! Will definitly test that this week.
Le 1 oct. 2018 à 19:09, Aaron Jackson aaron@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@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