Ah - seems obvious now. Thanks! On 1 October 2018 at 19:37 BST, Brian Kantor wrote: -- Aaron Jackson, Research Associate Computer Vision Lab, University of Nottingham http://aaronsplace.co.uk

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 > >

I can edit pages on the wiki. Give me the info, and I’ll add it in. On Mon, Oct 1, 2018 at 6:29 PM pete M <petem001(a)hotmail.com> 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 > >> > >>

44.0.0.1 can not be pinged via the tunnel, only via internet. You need to try other tunnel endpoints, but really need to find a live one :-) You could try 44.182.21.1... On 02.10.2018 02:07, Aaron Jackson wrote:

On 02/10/18 18:31, Brian Kantor wrote: 44.136.76.1,  44.136.76.2, 44.136.76.3 and 44.136.76.4 should all respond to pings, if you want to test. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

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 &lt;aaron(a)aaronsplace.co.uk&gt; 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 &lt;aaron(a)aaronsplace.co.uk&gt; 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 >>>>> >>>>>

I thought that bug was fixed some time back... [kb9mwr@kb9mwr ~]$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. 64 bytes from 44.0.0.1: icmp_seq=2 ttl=61 time=62.3 ms And even from outside 44net: C:\Users\user>ping 44.0.0.1 Pinging 44.0.0.1 with 32 bytes of data: Reply from 44.0.0.1: bytes=32 time=72ms TTL=48 Reply from 44.0.0.1: bytes=32 time=71ms TTL=48 On Wed, Oct 3, 2018 at 10:00 AM Brian Kantor &lt;Brian(a)bkantor.net&gt; wrote:

On 04/10/18 05:41, Brian Kantor wrote: Brian, just checked now, and I am getting a ping back from 44.0.0.1. Traceroute confirms it's going via the tunnel. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

On 04/10/18 07:52, Brian Kantor wrote: I can't see how the packet can get back without the tunnel.  This site is not BGP connected, only on the IPIP mesh.  -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

To: 22:21:35.179766 IP tenty.ca > amprgw.ucsd.edu: IP ve3tok. > gw.ampr.org: ICMP echo request, id 24603, seq 97, length 64 (ipip-proto-4) Return: 22:21:35.258376 IP amprgw.ucsd.edu > tenty.ca: IP gw.ampr.org > ve3tok.: ICMP echo reply, id 24603, seq 97, length 64 (ipip-proto-4) Bob VE3TOK On 2018-10-03 06:14 PM, Brian Kantor wrote:

Yes, that is what I see too.. Bob VE3TOK On 2018-10-03 05:45 PM, Tony Langdon wrote: