Well, I have a VPS in Melbourne, which runs IRLP
reflector 9550, among
other things. I currently have a /28 of public (non AMPR) IPs, which
are fully utilisied by Echolink. I could ask about getting a /24 BGP
announced, so I could participate.
That would be great!
You can start getting a /24 (from your country network or from that 44.190
network, that does not really matter when you are not close to another network
like Germany) and setup your system to be on the tunnel mesh.
Then you can experiment with the software.
In parallel you can get your BGP announcement fixed.
One thing I am not seeing addressed by this proposal
is what happens
with the nodes themselves, which are the the most problematic part of
Echolink (and IRLP) due to their incompatibility with NAT (requiring
port forwarding to work at all).
That is what the whole proxy/relay thing is about.
A proxy lives on a system with unlimited UDP access from/to internet (port 5198/5199)
and it also listens on port 8100 (default) for TCP connections from a repeater, link
or user who is behind NAT. When a user connects it relays the UDP traffic from those
ports to the TCP connection, and vice-versa. So it solves the NAT problem for that
specific user, while preserving full functionality (the user behind the proxy can
connect to several other stations and accept connections from other stations all at
the same time). But a proxy can be used only by one user at the same time, that is
why you want like 200 proxies. Proxies register themselves at
Echolink.org, and a
user wanting to use one can retrieve a list from the server and select one, some clients
can automatically pick a non-busy proxy from that list. The Echolinks server sorts
the list by geolocation distance to the requester, so your own proxies will appear
at the top of the list.
At least, when you have setup geolocation properly for your subnet. When you carve
your subnet out of a country network this will work automatically when your coordinator
has properly registered the country network. When he/she hasn't, your subnet will
likely
appear as located in San Diego, California. But you can fix that by sending a couple of
registration requests to the most important geolocation providers, easlily found by
googling for IP geolocation. This is another disaddvantage of the 44.190 space: you
will certainly have to solve this problem yourself.
A relay is a bit different. It allows only limited functionality: only outgoing
connections, only a single destination at a time. It is used by default by the phone
apps.
A relay can serve multiple users at the same time, but the group of users can only
connect to different destinations. When a user of a relay wants to connect to a
destination (e.g. a popular repeater) that has already been connected by another user,
the relay will refuse the connection and the app will have to hop over to another relay
to try it there. That is why it is suggested to run 10 relays at each site.
Relays are not automatically registered. They need to be manually registered at
Echolink,
who will put them in a geo DNS so users will get their address when querying
relay.echolink.org
and being closest to your relay. Try a dig -t a
relay.echolink.org to see what it
returns
for you (most likely it will return our relays at 44.137.75.x in Amsterdam, not really
close
for you :-)
That is what we are trying to solve by getting some more relays deployed. But first
you can experiment with proxies, you can turn them on or off at your own will. Once you
have started to run relays you need to take care that they remain running or when you
want to quit, to tell that to the Echolink people so they can take them out of the pool,
so users will not have to try to reach them in vain (until they try one that still
works).
Rob