Subject: [44net] 44.151.29.29/32 F4LTS From: "Marc, LX1DUC" lx1duc@laru.lu Date: 02/14/2015 12:21 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Good evening,
is Eric F4LTS on this list or does anybody have his contact data?
Eric has added network 44.151.29.29/32 with Gateway 44.151.29.29, once the IPIP interface on my router comes up, the route for 44.151.29.29/32 via 44.151.29.29 comes up, which in turn takes down the interface which disabled the route, which allows the interface to come up... a fine loop.
I had to filter his network 44.151.29.29/32 from the results I fetch via the API in order to keep my log size down.
I'm not sure if the portal should allow the gateway for a network to between inside that same network. I think it makes no sense but please correct me if I'm wrong.
73 de Marc, LX1DUC
It is certainly not correct... fortunately ampr-ripd ignores such routes after it was found that other people (like SA0BXI) had created them and they caused encapsulation loops.
But of course you are right, the portal should simply refuse to store such incorrect information in the first place. It should issue an error message that makes the user think again about what they have requested.
I am a bit disappointed about the progress in the portal development. Sure it can happen that people are temporarily busy and have to postpone things a bit until more time is available, but the portal as it is now has halted the development of amprnet and left everything in a stalemate situation. The DNS part needs to be finished, the allocation of subnets has to be much more flexible, overrides have to be made available to coordinators, and some address management tools have to be added. When it is decided that this cannot be done in the time available to the developer, it may be better to switch to another management system like the hamnet-db.
73, Rob