14 Feb
2015
14 Feb
'15
2:18 p.m.
Subject:
[44net] 44.151.29.29/32 F4LTS
From:
"Marc, LX1DUC" <lx1duc(a)laru.lu>
Date:
02/14/2015 12:21 AM
To:
AMPRNet working group <44net(a)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