It looks like we have the correct routes, but maybe the situation already rectified itself.
44.182.21.0/24 via 89.122.215.236 dev tunl0 proto ampr-ripd metric 4 onlink 44.182.21.1 via 89.33.44.100 dev tunl0 proto ampr-ripd metric 4 onlink
This weekend we had another issue. I use a script to download the ampr.org zone from ftp://gw.ampr.org/pub/ampr.tar.gz to have it available locally in case there is a DNS problem on internet or we get isolated (lost connectivity on our gateway). Our local DNS servers 44.137.0.1 and 44.137.0.2 operate from this downloaded zone rather than from internet, and a regular check of the version number is made and the new file downloaded when it changes.
As I experienced before that download of this file sometimes is not complete due to DDoS or other issues that make the download very slow, I added a sanity check: verify that the PTR entry for 44.255.255.255 is present in the 44.rev file before replacing our copies with the downloaded one. That entry was the last line in 44.rev, however someone has removed it so my script permanently rejected the download.
Well... maybe a line can be added at the end of the files like there is at the end of encap.txt saved by ampr-ripd, so scripts can check for that to see if the file is complete: # --EOF--
Of course it is always better to have a documented check criterium than to rely on something like the 44.255.255.255 -> broadcast.ampr.org entry...
Rob
Rob, The FTP protocol supports STAT that can tell you the file size prior to downloading it. Also most FTP clients give an exit status > 0 when the transfer (partially) failed. Why do you need magic markers? It is very error prone and the transport itself already caters fot most cases. 73s Wijnand
Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Rob Janssen pe1chl@amsat.org Date: 15/10/2018 10:11 (GMT+01:00) To: 44net@mailman.ampr.org Subject: Re: [44net] Routing update issue It looks like we have the correct routes, but maybe the situation already rectified itself.
44.182.21.0/24 via 89.122.215.236 dev tunl0 proto ampr-ripd metric 4 onlink 44.182.21.1 via 89.33.44.100 dev tunl0 proto ampr-ripd metric 4 onlink
This weekend we had another issue. I use a script to download the ampr.org zone from ftp://gw.ampr.org/pub/ampr.tar.gz to have it available locally in case there is a DNS problem on internet or we get isolated (lost connectivity on our gateway). Our local DNS servers 44.137.0.1 and 44.137.0.2 operate from this downloaded zone rather than from internet, and a regular check of the version number is made and the new file downloaded when it changes.
As I experienced before that download of this file sometimes is not complete due to DDoS or other issues that make the download very slow, I added a sanity check: verify that the PTR entry for 44.255.255.255 is present in the 44.rev file before replacing our copies with the downloaded one. That entry was the last line in 44.rev, however someone has removed it so my script permanently rejected the download.
Well... maybe a line can be added at the end of the files like there is at the end of encap.txt saved by ampr-ripd, so scripts can check for that to see if the file is complete: # --EOF--
Of course it is always better to have a documented check criterium than to rely on something like the 44.255.255.255 -> broadcast.ampr.org entry...
Rob
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Done. - Brian
On Mon, Oct 15, 2018 at 10:11:17AM +0200, Rob Janssen wrote:
Well... maybe a line can be added at the end of the files like there is at the end of encap.txt saved by ampr-ripd, so scripts can check for that to see if the file is complete: # --EOF--
Of course it is always better to have a documented check criterium than to rely on something like the 44.255.255.255 -> broadcast.ampr.org entry...
Rob
-
Brian Kantor -
pd0mz -
Rob Janssen