22 Jul
2019
22 Jul
'19
2:25 p.m.
Rob;
I'm taking this off list as I think we've pretty much beaten a dead
horse beyond it's glue stage :)
On Mon, 2019-07-22 at 19:42 +0200, Rob Janssen via 44Net wrote:
The problem is that the new proposal will not work as
smoothly and will be much
more difficult to implement when the old system is to be left in place.
What we would need to have happen then is for those looking to migrate
to the new system to continue (as you do) to run an IPIP gateway if they
wish to have connectivity to those who are on IPIP until such a
migration is complete. You don't want to cut off those who are on an
existing link for the sake of just new topologies. It'd be like your ISP
cutting off your PPP link for an ATM link because everyone else said
they wanted an ATM link. It'd make no sense for them to just cut you off
like that. I would think the same logic would apply here.
That is because the new system is to be using
automatic routing (with BGP or
maybe OSPF when others can convince my that would work better), while the old
system uses manual static routing managed by the portal.
When I helped set up one ISP, we used BGP to our peers and OSPF
internally. We found OSPF to be a tad faster in route updating than BGP.
Not much but enough where it was noticable.
On our legacy packet system we use pc/FlexNet as our "backbone" as it
handles ax.25 (even with IP encapsulated underneath) as BGP does on
global internet. Works very slick even at slow speeds.
*you* are not supposed to be spending that money. It
is to be spent by those that
deploy the VPN servers. Hopefully ARDC.
I don't think it's the duty or function of ARDC to do this. Sure, this
is a personal opinion of mine but I think funding can be better spent
elsewhere such as new ham recruitment for example. We're leased a static
block from the goodness of their heart, it should be our own
responsibility in connecting to the network. Again we're fortunate that
ARDC/BK has an IPIP server available. Years ago this was not the case if
you recall.
But NONE of those volunteers were from the
Netherlands!! (they did not need to
be, because I already host such a proxy farm in the Netherlands and the call for
volunteers was to get more of them running across the world)
The spread of volunteers was not as good as it could have been, but there were
several from California, from Canada, from Australia, etc.
Probably there are not so affected by backward internet connectivity (or lack
of money) as you are. I don't know if they end up spending the $5/month for
the benefit of amateur radio or if they got their hosting for free as part of
some other deal. But they do offer the service! Voluntarily, without complaining.
There's a small handful of users who's ISP filters them from even having
more than 1 ipip socket open which I host for them on my system, free of
charge. Initially I was going to use OpenVPN but it was more headache
than it was worth and I didn't want to bother managing it. There's
another I'm dealing with who's ISP is using watchdog timers to in a
sense kill any type of network socket he's trying to maintain including
SSH. He has an old router he's supposed to be putting OpenWRT on which
should help so he can put his CPE into bridge mode and disable the
watchdog timers.
Here, the ISPs deploy CPEs with watchdog timers fully enabled and the
menu to disable them deleted from the firmwares for a couple of reasons,
one of which is that they use the cheapest of gear with the least amount
of ram in them and the watchdogs are supposed to help keep old NAT
sessions flushed from ram. Another of course is to try and discourage
you from running any sort of server services or additional networking
through them. As I mentioned before, this is spreading like a cancer
here... like SAFe did a couple of decades ago and we had to jump over
that hurdle!
Because I think it is a waste of money (or a waste of
time) to do a lot of research
do potentially get a new product or another innovation started, for a community
that is not interested in innovation and will make up any motivation to resist it.
I've seen your website and some of the projects you've done - very
impressive! I don't think it'd be a waste of time at all! I think once a
good draft is made, some sort of script to help those less
network-inclinded to help migrate.. and it'd be all good. The portal
(for now) could contain a tick box under "direct" perhaps for VPN, and
that could push a newly requested block to a hub you propose via BGP -
I'm assuming you propose internal usage BGP of sorts for this?
Then we set up a time table as to when a cut off of IPIP may take place
but until then we'd have to leave an IPIP gateway up either at the hubs
or somehow push those on IPIP to UCSD for routing. It wouldn't happen
overnight by all means!.. but it could be done over time.
You very well know that a system like the proposed one
is operating in many other
places, and the only proposed change is to interconnect those systems and make
more of them, to replace the old and static system with something more flexible
and more usable.
Correct, I'm very well aware of this... and a bit envious I can't do
that here!
Maybe you are mostly stuck in the usage scenario where
AMPRnet is mostly used to
emulate the old packet radio system, e.g. for BBS forwarding, DX cluster, telnet
chat, etc.
That's basically what we're limited to for various reasons which I won't
get too deep into the specifics of but the reality is hams are losing
sites because nobody wants us there. We did try to set up 2.5 and 5Ghz
systems but our terrain is not favorable - way too many shadows and we
can't get the real estate we need to fill the holes. Also there's a
negative stigma with most clubs about 44-net in general. If it can be
done on 44-net then it can be done more efficiently with a direct IP
from the ISP is the attitude most take. I can't say I disagree with such
logic. One thing 44-net does help give is some low level sense of
security that one sourced with a 44-net IP most likely (although now not
true) a ham.
However, most new users who already know the internet
want to do
other things, like WebSDR, audio and video streaming (e.g. to YouTube), running
amateur-oriented web services like a Mattermost server, etc.
Internet connectivity is a must for most of these.
That could actually open a can of worms here. A ham using ham
frequencies to YouTube for example may constitute a violation of 3rd
party communications regulations, or a ham with an asterisk server on
ham freqs to phone a non ham may also fall under that same scope. While
no rulings have been made or even presented I don't think anyone wishes
to chance a black eye on their license in case it is looked at by our
governing body. It's easier to keep such things off ham freqs and feel
safer that you're not causing any harm to your status.
But you can at least try!
As I've mentioned, via VPN I have. Prior to getting IPIP working I had a
VPN link with WA7V in Walla Walla Washington, which route wise about 12
hops further from me then UCSD. While the MTU was 1500 vs 1480 the IPIP
tunnel was much faster for me.
I remember seeing the questions here about having an
IPIP gateway with more than one external address (e.g. using two different ISP
links) to have redundancy at that level. Not possible, Sir! An IPIP tunnel
endpoint has no way of seeing that the other side is down.
Correct! There's no multi-home solution using IPIP, but now I'm
wondering if BGP or OSPF through IPIP may help fix that?
With the newly proposed system this function would be
no problem. BGP sees
that a link is down and switches over to the alternate. Even within a second,
when you configure BFD with it.
But as long as the IPIP advocates get it their way, this will not happen.
Again, with a proper plan (ref: rule of 7 P's) it could happen it just
has to be quite simplified for the networking challenged, and IPIP has
to be given a cut off date of I would say at least 4-5 years for
everyone to get on board with something new. This also gives plenty of
time to configure a test-bed and let people at various levels of
networking skills (or lack there of) to try it out before full
deployment. In the interim however we can't just bump people off because
some wish to change the method of connectivity.
I could deploy it to my home, but I have no need to do
that. I already have a
5GHz WiFi link to our nearby (5 miles) access point so I get my AMPRnet over
radio, thank you very much.
As do I from gw.ct.ampr.org which is a 2.5Ghz hotspot for amprnet. Only
my main system connects to it for now.
And I have a VPN as a backup in case it somehow
fails. In fact I have backup in 2 directions: when my VDSL connection fails,
I can still surf the web via my amateur radio connection. If only to check the
ISP website to see if there are any known interruptions.
While I don't have a VPN link anywhere at the moment, I probably could
set one up somewhere... and I use Autostatus to constantly check not
only my links but links to others I either support, or our RF legacy
packet nodes. I modified it especially in it's fping routines to allow
the slower speeds but it works and works well.
And there are several other stations here with the
same setup. Not only do they
have the above advantages, their systems also provide backup to the links between
the access points. When the interlink to my accesspoint fails (another radio link),
it would be automatically backed up via my own VPN and radio link. BGP does
all that. The IPIP system can't.
Over there in Europe you do have a lot more leniency to do what you want
to do, with the real estate resources to do it with. Here we
unfortunately don't. Some areas of the country are doing Hamwan with
some success - here hams are viewed more as a nuisance and our
towers/antennas depreciate property value. In the state I live in, a few
years back it was even declared that use of our mobile rigs constituted
what they call "distracted driving" and is subject to criminal fines. I
find this offensive not just for the fact that it's too strict a law,
but the ARRL HQ is almost in my back yard and they did nothing to lobby
against it.
If you want me to try a VPN/BGP link to you somehow I'd be willing to
try it out and perhaps document the process in making it work.
--
Rain is caused by big, high-pressure areas; cold fronts; warm, moist air;
And the first day of your vacation.
-----
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org