Hello!
Today I released an update to ampr-ripd (1.16) and amprd (1.5) to support ipip encapsulation on subnets which have their endpoints BGP announced in the 44net space. Just compile and replace your current daemon executable file (stop the old one first). No changes in configuration should be necessary.
Get them as usual from my ham project page:
Internet:
http://www.yo2loj.ro/hamprojects/ampr-ripd-1.16.tgz
http://www.yo2loj.ro/hamprojects/amprd-1.5.tgz
44net:
http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.tgz
http://yo2tm.ampr.org/hamprojects/amprd-1.5.tgz
73 de Marius, YO2LOJ
Hello Marius.
While ago compiled and started ampr-ripd-1.16 on my server. Will keep you posted in case of any issues.
Best regards. Tom - SP2L
Hi again,
Thanks to Jann, DG8NGN, we have some test setups on virtual machines on his server. To test the new feature you can ping/traceroute the following hosts to check the function:
Direct BGP endpoint 44.130.121.2 running amprd, host via tunnel: 44.130.121.3 Direct BGP endpoint 44.130.122.2 running ampr-ripd, host via tunnel: 44.130.122.3
Marius, YO2LOJ
For completeness, this is what you should expect in a trace (44.182.21.254 is my router running the Mikrotik script):
C:\Users\Marius>tracert 44.130.121.2
Tracing route to 44.130.121.2 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms router.yo2loj.ampr.org [44.182.21.254] 2 14 ms 14 ms 14 ms 89.122.214.254 3 15 ms 14 ms 14 ms 10.0.225.153 4 37 ms 37 ms 37 ms 10.0.200.30 5 37 ms 37 ms 37 ms atuin.rzone.de [80.81.192.110] 6 37 ms 37 ms 42 ms ae0.0.morla.as6724.net [81.169.144.33] 7 51 ms 52 ms 52 ms xe-0-0-1.core-b30.as6724.net [85.214.0.64] 8 52 ms 51 ms 51 ms 192.68.17.1 9 49 ms 50 ms 49 ms 44.130.121.2
Trace complete.
C:\Users\Marius>tracert 44.130.121.3
Tracing route to 44.130.121.3 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms router.yo2loj.ampr.org [44.182.21.254] 2 50 ms 50 ms 50 ms 44.130.121.3
Trace complete.
C:\Users\Marius>
On 4/04/2017 5:29 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi again,
Thanks to Jann, DG8NGN, we have some test setups on virtual machines on his server. To test the new feature you can ping/traceroute the following hosts to check the function:
Direct BGP endpoint 44.130.121.2 running amprd, host via tunnel: 44.130.121.3 Direct BGP endpoint 44.130.122.2 running ampr-ripd, host via tunnel: 44.130.122.3
I upgraded my ampr-ripd, but the only one of these I could get to work was 44.130.121.3. The other 3 were unreachable from 44.136.76/24. :( This result was identical to those obtained with the previous version, and I got a bit suspicious. I had been testing from my Windows machine, which routes everything for 44/8 to the AMPRnet router (confirmed with tracert -d)
I repeated the test from the Pi running ampr-ripd and all 4 addresses are reachable from that machine. Traceroutes look good too from there. With further thought, that is expected behaviour. Directly reachable BGP advertised endpoints are going to break here, because of routing/addressing issues. I'm not sure how I'm going to fix this for machines other than the AMPR router itself.
Tony,
If you have your gateway running on the Pi, for your windows machine you need to use the Pi as a gateway for 44.0.0.0/8.
This could be achieved in 2 ways:
a - If you use 44net addresses in your LAN add a permanent route 44.0.0.0/8 via PI
b - If you use private addresses, it gets a little more complicated:
- use the above method and do NAT on the Pi
- add a second network adapter with a 44net address and the above route via Pi
- set up a vlan on your computer and on the Pi and use that one for 44 access (this is quite tricky on windows)
Marius, YO2LOJ
On 2017-04-05 2:01, Tony Langdon wrote:
I upgraded my ampr-ripd, but the only one of these I could get to work was 44.130.121.3. The other 3 were unreachable from 44.136.76/24. :( This result was identical to those obtained with the previous version, and I got a bit suspicious. I had been testing from my Windows machine, which routes everything for 44/8 to the AMPRnet router (confirmed with tracert -d)
I repeated the test from the Pi running ampr-ripd and all 4 addresses are reachable from that machine. Traceroutes look good too from there. With further thought, that is expected behaviour. Directly reachable BGP advertised endpoints are going to break here, because of routing/addressing issues. I'm not sure how I'm going to fix this for machines other than the AMPR router itself.
On 5/04/2017 4:08 PM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Tony,
If you have your gateway running on the Pi, for your windows machine you need to use the Pi as a gateway for 44.0.0.0/8.
It is, and the Windows box can see 44 net addresses via the tunnels.
This could be achieved in 2 ways:
a - If you use 44net addresses in your LAN add a permanent route 44.0.0.0/8 via PI
I have a 44net alias on the windows box. It works for tunneled hosts. I've been on XMPP via the tunnel for ages. And I have the 44/8 route configured.
But the issue I'm seeing looks a bit different.
From the Pi, if I traceroute to a tunneled host, I get:
root@vkhub1332:~# traceroute -n 44.130.122.3 traceroute to 44.130.122.3 (44.130.122.3), 30 hops max, 60 byte packets 1 44.130.122.3 503.028 ms 522.513 ms 523.122 ms
But if I traceroute to a directly connected host, I get:
root@vkhub1332:~# traceroute -n 44.130.122.2 traceroute to 44.130.122.2 (44.130.122.2), 30 hops max, 60 byte packets 1 10.69.181.1 1.442 ms 1.816 ms 1.890 ms 2 150.101.32.54 75.362 ms 75.271 ms 83.859 ms 3 150.101.34.159 84.356 ms 84.258 ms 84.166 ms 4 150.101.33.28 137.165 ms * 137.301 ms 5 150.101.33.14 129.474 ms 129.694 ms 130.061 ms 6 * 150.101.40.131 129.893 ms 130.717 ms 7 202.7.162.249 132.171 ms 184.537 ms 184.993 ms 8 203.29.134.68 176.233 ms 178.579 ms 178.344 ms 9 213.248.86.188 390.892 ms 364.606 ms 364.375 ms 10 62.115.138.50 402.851 ms 80.91.253.69 402.927 ms 62.115.138.46 401.288 ms 11 213.155.135.56 466.577 ms 213.155.135.58 462.136 ms 62.115.139.42 462.462 ms 12 62.115.141.239 460.566 ms 62.115.121.11 460.441 ms 62.115.137.169 460.298 ms 13 213.248.94.78 462.012 ms 525.652 ms 399.758 ms 14 85.214.0.64 411.515 ms 411.695 ms 480.802 ms 15 192.68.17.1 479.886 ms 480.223 ms 539.187 ms 16 44.130.122.2 539.240 ms 547.934 ms 544.131 ms
Now, ampr-ripd does identify this host as directly connected, which appears to be the expected behaviour with the new version. All well and good from the Pi, but there is one significant implication - the source IP is no longer my 44 net IP, but it's the public IP of my router, and the internal IP is the 10.x IP of the Pi (my regular IP range. I think that's where things are breaking.
I could renumber to 44net addresses, but that would mean taking up a /27 at least, to accommodate all the devices here. That is an option to consider, if all else fails.
b - If you use private addresses, it gets a little more complicated:
- use the above method and do NAT on the Pi
NAT would mean I'm running double NAT, something I would prefer to avoid, if possible. but an option for when the route goes direct, but I might be stuck with that option. I'd only want to
- add a second network adapter with a 44net address and theabove route via Pi
I'm not sure how this one is going to help, would need to see a diagram, same for the VLAN option.
On 3 April 2017 at 20:29, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi again,
Thanks to Jann, DG8NGN, we have some test setups on virtual machines on his server. To test the new feature you can ping/traceroute the following hosts to check the function:
Direct BGP endpoint 44.130.121.2 running amprd, host via tunnel: 44.130.121.3 Direct BGP endpoint 44.130.122.2 running ampr-ripd, host via tunnel: 44.130.122.3
Hi,
I have 44.131.14.0/24 advertised via BGP. This prefix is actually being anycasted from multiple locations, which wasn't really supported by the existing system and I hadn't gotten around to finding a solution yet.
The prefix is split over multiple networks, and I am using IPIP encapsulation internally, so it was trivial to add the new gateway mechanism to my existing setup. The prefix was not previously "on-net", so I don't think I risk breaking anything with this experimental configuration.
I have added a gateway at 44.131.14.255 and pointed the prefix to it on the portal. I am pulling the encap list for outbound routes every 2 hours, using a manual script which does the same thing of adding a route when it comes across a 44/8 gateway address.
root@vpn:~# traceroute 44.130.122.3 traceroute to 44.130.122.3 (44.130.122.3), 30 hops max, 60 byte packets 1 London.AS206671 (45.63.97.98) 1.913 ms 1.880 ms 1.834 ms 2 44.130.122.3 (44.130.122.3) 30.611 ms 30.575 ms 30.515 ms
The first hop is the nearest instance of my anycasted router that handles both BGP and the IPIP tunnels, it has 44.131.14.255 on a loopback interface.
Wireshark confirms I am going out encapsulated from 45.63.97.98 to 44.130.122.2 and the replies are coming back encapsulated from 44.130.122.2 to 44.131.14.255.
If you want to test it, 44.131.14.254 is a second loopback on the gateway that is used for status monitoring. 44.131.14.192 is a unicast node "inside" my network to check end to end connectivity.
- Mike, M6XCV
(PS. If you need anyone else to help with testing BGP stuff, I can advertise any prefix from my personal AS with minimal effort.)
Hi Mike,
Both 44.131.14.255 via direct and 44.131.14.254 via tunnel are working ok from my side. It seems you got it right :-)
Marius, YO2LOJ
On 2017-04-06 17:42, M6XCV (Mike) wrote:
Hi, I have 44.131.14.0/24 advertised via BGP. This prefix is actually being anycasted from multiple locations, which wasn't really supported by the existing system and I hadn't gotten around to finding a solution yet.
The prefix is split over multiple networks, and I am using IPIP encapsulation internally, so it was trivial to add the new gateway mechanism to my existing setup. The prefix was not previously "on-net", so I don't think I risk breaking anything with this experimental configuration.
Hi,
Here a complete picture of our test network (Tnx. Jann).