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.

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.

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.