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.
Ah yes, it would be better when ampr-ripd added a "src" option with the IP of the tunnel interface to the /32 routes it adds to the table...
Rob
On 6/04/2017 2:18 AM, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
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.
Ah yes, it would be better when ampr-ripd added a "src" option with the IP of the tunnel interface to the /32 routes it adds to the table...
Now another question about directly connected 44net addresses - is there a way for them to reach tunneled addresses? I would prefer to have my services accessible from all 44net addresses when I start offering something serious later this year. ATM, it appears my /24 would be unreachable from these addresses, because even if there is a host route to an endpoint, the 44net address is not exposed to directly connected endpoints (they see the public IP of my router). And those direct connected addresses not running tunnels wouldn't reach me for obvious reasons.
-
Rob Janssen -
Tony Langdon