3 Apr
2017
3 Apr
'17
3:10 p.m.
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
3 Apr
3 Apr
2:41 p.m.
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
3:29 p.m.
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
3:47 p.m.
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>
4 Apr
4 Apr
7:01 p.m.
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.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
5 Apr
5 Apr
2:08 a.m.
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.
8:41 a.m.
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 the
above 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.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
6 Apr
6 Apr
10:42 a.m.
On 3 April 2017 at 20:29, Marius Petrescu <marius(a)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.)
2:08 p.m.
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.
5 Apr
5 Apr
2:13 a.m.
Hi,
Here a complete picture of our test network (Tnx. Jann).
http://www.yo2loj.ro/files/Ampr-TestNet.png
2599
days inactive
2602
days old
9 comments
4 participants
participants (4)
-
M6XCV (Mike) -
Marius Petrescu -
SP2L -
Tony Langdon