Subject: Re: [44net] Iperf server - kk7kx From: Assi Friedman assi@kiloxray.com Date: 07/26/2015 12:23 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
Based off the output of the munge script, those two addresses take different paths: /sbin/ip route add 44.137.41.96/28 via 89.18.172.156 dev tunl0 onlink /sbin/ip route add 44.137.0.0/16 via 213.222.29.194 dev tunl0 onlink
Ok... THAT explains something!
This is *old* data. That 44.137.41.96/28 entry was removed on April 25th this year, and you still have it in your table. The 44.137.41.96/28 network should now be routed via the 44.137.0.0/16 entry, as I have moved this network from a tunnel route to a radio link to our Dutch HAMNET which connects to internet via a national gateway for 44.137.0.0/16.
It looks like your method of managing routes only adds and modifies entries, but never deletes them. I'm interested in what method you are using, and if you maybe have copied it from someone else who also still uses this. It would explain some of the broken routing we are facing.
Of course when some route no longer appears in the encap table, you should make sure you also delete it from your local routing table. Else you will have more and more incorrect routes as a result.
Maybe it is better to switch to using ampr-ripd, which would not have this problem.
Rob
I use the encap file and the munge script to update the routes nightly. I think I know what the problem is. Just realized that the script attempts to grab the encap file from ftp.ampr-gateways.org which is not available. Where are we supposed to grab the encap file from nowadays? Thanks, Assi
On Sun, Jul 26, 2015 at 12:15 PM, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
Subject: Re: [44net] Iperf server - kk7kx From: Assi Friedman assi@kiloxray.com Date: 07/26/2015 12:23 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
Based off the output of the munge script, those two addresses take different paths: /sbin/ip route add 44.137.41.96/28 via 89.18.172.156 dev tunl0 onlink /sbin/ip route add 44.137.0.0/16 via 213.222.29.194 dev tunl0 onlink
Ok... THAT explains something!
This is *old* data. That 44.137.41.96/28 entry was removed on April 25th this year, and you still have it in your table. The 44.137.41.96/28 network should now be routed via the 44.137.0.0/16 entry, as I have moved this network from a tunnel route to a radio link to our Dutch HAMNET which connects to internet via a national gateway for 44.137.0.0/16.
It looks like your method of managing routes only adds and modifies entries, but never deletes them. I'm interested in what method you are using, and if you maybe have copied it from someone else who also still uses this. It would explain some of the broken routing we are facing.
Of course when some route no longer appears in the encap table, you should make sure you also delete it from your local routing table. Else you will have more and more incorrect routes as a result.
Maybe it is better to switch to using ampr-ripd, which would not have this problem.
Rob
Found it. Is there a way to wget or ftp the file automatically? Assi
On Sun, Jul 26, 2015 at 6:36 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jul 26, 2015 at 05:27:42PM -0700, Assi Friedman wrote:
Where are we supposed to grab the encap file from nowadays?
portal.ampr.org - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Sun, Jul 26, 2015 at 07:07:45PM -0700, Assi Friedman wrote:
Found it. Is there a way to wget or ftp the file automatically?
Of course there is; you can call 'wget' from a cron job. Typically you'd do so in a script that handles the error condition in some way if the get fails. - Brian
eg
/usr/bin/wget -N -nd -q \ --ftp-user=username \ --ftp-password=password \ ftp://portal.ampr.org/encap.txt
(substitute in the proper values for 'username' and 'password')
Just downloaded and updated the encap file from portal.ampr.org. My node is now updated with the recent file. Is there a way to automate download of the encap file via ftp or wget? Thanks, Assi
On Sun, Jul 26, 2015 at 12:15 PM, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
Subject: Re: [44net] Iperf server - kk7kx From: Assi Friedman assi@kiloxray.com Date: 07/26/2015 12:23 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
Based off the output of the munge script, those two addresses take different paths: /sbin/ip route add 44.137.41.96/28 via 89.18.172.156 dev tunl0 onlink /sbin/ip route add 44.137.0.0/16 via 213.222.29.194 dev tunl0 onlink
Ok... THAT explains something!
This is *old* data. That 44.137.41.96/28 entry was removed on April 25th this year, and you still have it in your table. The 44.137.41.96/28 network should now be routed via the 44.137.0.0/16 entry, as I have moved this network from a tunnel route to a radio link to our Dutch HAMNET which connects to internet via a national gateway for 44.137.0.0/16.
It looks like your method of managing routes only adds and modifies entries, but never deletes them. I'm interested in what method you are using, and if you maybe have copied it from someone else who also still uses this. It would explain some of the broken routing we are facing.
Of course when some route no longer appears in the encap table, you should make sure you also delete it from your local routing table. Else you will have more and more incorrect routes as a result.
Maybe it is better to switch to using ampr-ripd, which would not have this problem.
Rob
On 27 Jul 2015, at 03:30, Assi Friedman assi@kiloxray.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Just downloaded and updated the encap file from portal.ampr.org. My node is now updated with the recent file. Is there a way to automate download of the encap file via ftp or wget? Thanks, Assi
The preferred solution is to use the API, you can then run a cronjob at whatever frequency you prefer to check for changes and update your routes.
Chris
-
Assi Friedman -
Brian Kantor -
Chris -
Rob Janssen