Nigel, Brian,
IMHO this is actually a non-issue.
I will take Nigel's setup as an example.
In my setup there is no route pointing to 44.24.221.1. So traffic to it will
be NAT-ed by my router to my public IP, and then sent via internet to
44.24.221.1.
The route to it is completly traceable to 44.24.221.1.
Now the route created by the RIP daemon states:
44.24.240.0/20 via 44.24.221.1 dev ampr0
This means that traffic will be IPIP encapsulated and sent to 44.24.221.1,
apparently originating from 89.122.215.236 (because of NAT).
Nevertheless, it will reach its intended target, and back because its
originating address is my public IP for which IPIP is forwarded to the
gateway.
And this is what I get on gateway itself:
root@server:~# traceroute -I 44.24.221.1
traceroute to 44.24.221.1 (44.24.221.1), 30 hops max, 60 byte packets
1 mikrotik-v4.ext (192.168.74.2) 0.173 ms 0.145 ms 0.165 ms <--
here is where NAT happens
2 89.122.214.254 (89.122.214.254) 14.956 ms 16.982 ms 19.035 ms
...
16 44.24.221.1 (44.24.221.1) 195.174 ms 209.189.202.213 (209.189.202.213)
203.172 ms 204.115 ms
And a trace to a host inside 44.24.240.0/20:
root@server:~# traceroute -I 44.24.241.97
traceroute to 44.24.241.97 (44.24.241.97), 30 hops max, 60 byte packets
1
switch.seattle-er1.hamwan.net (44.24.241.97) 202.845 ms 204.839 ms
206.865 ms
And this is what I get from my desktop computer via LAN (my local IP being
44.182.21.36 for 44net connections):
Tracing route to
switch.seattle-er1.hamwan.net [44.24.241.97]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 44.182.21.254 <- router IP
2 <1 ms <1 ms <1 ms 192.168.74.1 <- internal gateway
IP
3 214 ms 219 ms 223 ms
switch.seattle-er1.hamwan.net [44.24.241.97]
So it is actually working without any issues.
73s de Marius
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Nigel
Vander Houwen
Sent: Wednesday, November 12, 2014 18:07
To: AMPRNet working group
Subject: Re: [44net] Gateways with external address in net-44
(Please trim inclusions from previous messages)
_______________________________________________
Brian,
I believe the issue stands (and this is hearsay) that the 44/net router at
UCSD assumes that ALL 44/8 traffic goes to them, so they can't route to
externally announced 44/8 addresses. So until that got fixed, I don't
believe your idea would be workable. However, that's not too different (if
I understand you correctly) from what I proposed, that UCSD handles the
routing (if the issue were to be resolved) for entries that aren't in the
encap, and end points/users can still route to specific tunnel entries,
and the rest of 44/8 to UCSD.
If the described issue doesn't exist, or can be resolved, I think that
would be the easiest way for everyone.
Nigel