Subject: Re: [44net] New Linux Boot Scripts for Testing From: Gustavo Ponza g.ponza@tin.it Date: 08/04/2015 02:10 PM
To: 44net@hamradio.ucsd.edu
As per the 44.88.0.9:
As per my tests since this morning (local time) for the first time I can ping and connect the http and ftp facilities at 44.88.0.9 and downloaded some files... never happened since years to now!!! Hope that Brian will share his actual GW setup, TNX.
As per the 44.137.0.1 and subnets:
Report is that the 44.137.0.1 GW is promptly pingable, but regarding their subnet only the following are *correctly* pingable, namely:
44.137.24.5 44.137.40.1 44.137.40.10 44.137.40.2 44.137.40.20
all the other not.
Those addresses are not on the 44.137.0.1 gateway but on two different private gateway systems that advertise only those addresses.
I hope everyone correctly implements a "most specific route first" policy that means that traffic to such addresses goes to the indicated tunnel endpoint (89.18.172.155 and 89.18.172.156) while other addresses in the 44.137.0.0/16 network are routed to tunnel endpoint 213.222.29.194. That should be no problem on e.g. a Linux system.
For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute, you should see a couple more hops after the tunnel that are radio hops.
As per the 44.60.44.10:
Remain not pingable
Same for me!
The hamwan.org remain unreachable
That one is reachable for me: traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 gw.pe1chl.ampr.org (44.137.41.110) 0.248 ms 0.337 ms 0.428 ms 2 cisco1.pi1utr.ampr.org (44.137.41.254) 2.254 ms 20.621 ms 21.124 ms 3 pi1utr.pi9noz.ampr.org (44.137.60.1) 22.615 ms 34.658 ms 34.694 ms 4 213.222.29.193 (213.222.29.193) 68.524 ms 68.560 ms 68.582 ms 5 0.xe-7-0-1.xr4.1d12.xs4all.net (194.109.12.5) 68.636 ms 70.600 ms 71.415 ms 6 0.ge-0-2-0.xr1.sara.xs4all.net (194.109.5.2) 73.308 ms 77.651 ms 77.645 ms 7 er1.ams1.nl.above.net (80.249.208.122) 79.347 ms 64.952 ms 11.503 ms 8 ae14.cr1.ams10.nl.zip.zayo.com (64.125.21.77) 13.982 ms 14.622 ms 15.123 ms 9 v142.ae29.cr2.ord2.us.zip.zayo.com (64.125.30.170) 112.583 ms 112.614 ms 113.365 ms 10 ae11.cr1.ord2.us.zip.zayo.com (64.125.20.245) 118.816 ms 119.403 ms 120.093 ms 11 v11.ae29.mpr1.sea1.us.zip.zayo.com (64.125.31.50) 158.630 ms 159.681 ms 160.046 ms 12 216.200.88.129.z00003.above.net (216.200.88.129) 159.559 ms 159.593 ms 159.922 ms 13 ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 150.858 ms ge0-0-0-0-sea3.threshinc.net (209.189.201.213) 151.354 ms ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 151.977 ms 14 seattle-er1.hamwan.net (209.189.196.68) 152.033 ms 150.810 ms 151.959 ms 15 eth0.seattle-srv1.hamwan.net (44.24.241.98) 149.933 ms 150.508 ms 151.199 ms
It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed). You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint.
Rob
On Tue, Aug 4, 2015 at 12:19 PM, Rob Janssen pe1chl@amsat.org wrote:
The hamwan.org remain unreachable
It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed). You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint.
Indeed, this is what you should be seeing for hamwan.org at the moment. Since our gateway was deleted from the portal we have not gone in and rebuilt things.
We are properly BGP routed, so any machine on the internet (and not behind amprgw) should be able to access it.
Tom KD7LXL
On Tue, Aug 04, 2015 at 12:34:32PM -0700, Tom Hayward wrote:
We are properly BGP routed, so any machine on the internet (and not behind amprgw) should be able to access it.
amprgw# ping hamwan.org PING hamwan.org (44.24.241.98): 56 data bytes 64 bytes from 44.24.241.98: icmp_seq=0 ttl=51 time=39.177 ms 64 bytes from 44.24.241.98: icmp_seq=1 ttl=51 time=39.212 ms 64 bytes from 44.24.241.98: icmp_seq=2 ttl=51 time=39.318 ms ^C --- hamwan.org ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 39.177/39.236/39.318/0.060 ms
On Tue, Aug 4, 2015 at 12:48 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Aug 04, 2015 at 12:34:32PM -0700, Tom Hayward wrote:
We are properly BGP routed, so any machine on the internet (and not behind amprgw) should be able to access it.
amprgw# ping hamwan.org PING hamwan.org (44.24.241.98): 56 data bytes 64 bytes from 44.24.241.98: icmp_seq=0 ttl=51 time=39.177 ms 64 bytes from 44.24.241.98: icmp_seq=1 ttl=51 time=39.212 ms 64 bytes from 44.24.241.98: icmp_seq=2 ttl=51 time=39.318 ms ^C --- hamwan.org ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 39.177/39.236/39.318/0.060 ms
Does this mean the longstanding UCSD 44/8 static route has been removed??
Tom KD7LXL
On Tue, Aug 04, 2015 at 12:49:46PM -0700, Tom Hayward wrote:
Does this mean the longstanding UCSD 44/8 static route has been removed??
Yes, we've been in testing mode for a few days and all seems to be working properly.
I guess that makes this the official announcement. - Brian
This is incredible news! WOOOOOOOOOO!
Thank you much for the work in that regard. This simplifies so much of the interconnectivity between BGP routed subnets, and IPIP users.
Nigel K7NVH
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Aug 04, 2015 at 12:49:46PM -0700, Tom Hayward wrote:
Does this mean the longstanding UCSD 44/8 static route has been removed??
Yes, we've been in testing mode for a few days and all seems to be working properly.
I guess that makes this the official announcement.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
TNX Tom for your positive explanation.
gus
The hamwan.org remain unreachable
It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed). You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint.
Indeed, this is what you should be seeing for hamwan.org at the moment. Since our gateway was deleted from the portal we have not gone in and rebuilt things.
We are properly BGP routed, so any machine on the internet (and not behind amprgw) should be able to access it.
Tom KD7LXL
As per the 44.137.0.1 and subnets:
Report is that the 44.137.0.1 GW is promptly pingable, but regarding their subnet only the following are *correctly* pingable, namely:
44.137.24.5 44.137.40.1 44.137.40.10 44.137.40.2 44.137.40.20
all the other not.
Those addresses are not on the 44.137.0.1 gateway but on two different private gateway systems that advertise only those addresses.
I hope everyone correctly implements a "most specific route first" policy that means that traffic to such addresses goes to the indicated tunnel endpoint (89.18.172.155 and 89.18.172.156) while other addresses in the 44.137.0.0/16 network are routed to tunnel endpoint 213.222.29.194. That should be no problem on e.g. a Linux system.
The following is the routing situation seen from here; the 44.137 IPIP routes result correctly addressed toward the commercial GW IP addresses according to the above statements. The routes are collected from the gw.ampr.org and so only that setup there. Now, as per my understanding, all the whole 44.137 GWs should be setup on the same way of that (above) pingable GWs to be reached via tunl0.
root@ir0rm-7:/# route -n|grep 44.137 44.137.2.138 84.106.127.22 255.255.255.255 UGH 0 0 0 tunl0 44.137.24.1 88.159.160.228 255.255.255.255 UGH 0 0 0 tunl0 44.137.24.5 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 44.137.25.62 88.159.83.58 255.255.255.255 UGH 0 0 0 tunl0 44.137.32.50 84.83.147.249 255.255.255.255 UGH 0 0 0 tunl0 44.137.0.49 77.175.246.216 255.255.255.255 UGH 0 0 0 tunl0 44.137.40.2 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 44.137.40.1 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 44.137.40.10 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0 44.137.40.20 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0 44.137.1.160 46.21.164.170 255.255.255.240 UG 0 0 0 tunl0 44.137.1.208 195.240.133.194 255.255.255.240 UG 0 0 0 tunl0 44.137.33.16 84.83.147.249 255.255.255.240 UG 0 0 0 tunl0 44.137.33.32 62.45.244.128 255.255.255.240 UG 0 0 0 tunl0 44.137.51.64 130.255.72.61 255.255.255.240 UG 0 0 0 tunl0 44.137.37.160 82.161.55.187 255.255.255.240 UG 0 0 0 tunl0 44.137.37.176 82.139.110.195 255.255.255.240 UG 0 0 0 tunl0 44.137.37.192 31.151.69.80 255.255.255.240 UG 0 0 0 tunl0 44.137.41.128 83.160.55.17 255.255.255.240 UG 0 0 0 tunl0 44.137.27.112 88.159.160.228 255.255.255.240 UG 0 0 0 tunl0 44.137.31.32 82.176.45.37 255.255.255.240 UG 0 0 0 tunl0 44.137.0.0 213.222.29.194 255.255.0.0 UG 0 0 0 tunl0
For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute, you should see a couple more hops after the tunnel that are radio hops.
That IP address doesn't appear on the above list but it is positively pingable:
root@ir0rm-7:/# ping 44.137.41.97 -c 4 PING 44.137.41.97 (44.137.41.97) 56(84) bytes of data. 64 bytes from 44.137.41.97: icmp_req=1 ttl=61 time=93.1 ms 64 bytes from 44.137.41.97: icmp_req=2 ttl=61 time=87.6 ms 64 bytes from 44.137.41.97: icmp_req=3 ttl=61 time=86.8 ms 64 bytes from 44.137.41.97: icmp_req=4 ttl=61 time=97.4 ms
--- 44.137.41.97 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 86.863/91.271/97.413/4.307 ms
... and its traceroute is:
root@ir0rm-7:/# traceroute 44.137.41.97 traceroute to 44.137.41.97 (44.137.41.97), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 linux.pe1chl.ampr.org (44.137.41.97) 101.326 ms 104.222 ms 104.455 ms
The hamwan.org remain unreachable
That one is reachable for me:
It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed). You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint.
Yes, it is clear now, TNX.
gus
-
Brian Kantor -
Gustavo Ponza -
Nigel Vander Houwen -
Rob Janssen -
Tom Hayward