I have been following the conversation on what can we use the modern version
of the 44net for other than a futile attempt to compete with cable modems,
4G/LTE or fiber-optic links. The purpose of the 44net/JNOS project that we
are putting together for NYC-ARECS is for providing email/telnet services
for a served client in case their connection goes down or does not exist
in an ad-hoc location. I am wondering if we can expand on the usual email
and telnet sessions at 1k2 or even 9k6 to include things like routing our
own VoIP/Echolink-type connections? The Echolink manual states that it needs
24K+ data speeds to connect to it's servers and maintain a voice connection.
I know that there are other codecs that can work at lower speeds as well as
ongoing work with FreeDV operating in 1.5 Khz on 20 meters! Ideas anyone?
On 7/25/13 9:27 AM, Brian Rogers wrote:
> That's why I completed the work started by Hessu and Marius in regards
> to axMail-Fax... however there's already a system out there called
> Winlink 2000 that uses HF, FM, and Internet to handle email. When I
> query those who run it I get almost always these 3 identical comments:
>
> 1) It's windows, there's no learning curve of nos or linux involved.
> 2) I can use the resources I have already without any _additional
> expenses_.
> 3) I don't have time to learn amprnet.
>
> ... then there was the issue raised about 3-party relaying, so now we
> have governmental restrictions shying us away from certain applications.
>
> How we route is all well and good, but if you're not:
> - providing useful services, some of which may be unique
> - have a user base to use this network
> - cost effectiveness (especially to the seniors who may be on fixed
> incomes)
I have no interest in limiting myself to what some old ignorant hams can
understand. This is one of the reasons I got out of radio for a number of
years, as it was not new or challenging due to these guys. I want to sit down
an study if I don't understand it, not gripe about it (and my angina) on FM.
We really have two discussions here. One is global BGP peering and a 44-net
back bone, the other is the end user connecting over tunnels or dedicated
links to the backbone.
The backbone should be based on standard routing protocols and be vendor
agnostic (ie ALU/CSCO/JNPR), as I could see having a router and peering link
donated, but if we need to rack a linux box, we'll have an issue.
The individual backbone POP's can interconnect with the end users over any
method they want. (I'd say we need to support IPIP or GRE tunnels as standard
at any POP)
For an end user wanting a /29 or /31 they would pick a "local" AMPR POP, and
link in with them.
Thoughts?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 7/25/13 11:59 AM, Marc, LX1DUC wrote:
> What is your experience with that setup? Does it always (99.999% :-D)
> work? If so, count me in an let's go with it.
I've been running Cisco 1811's and 2800's in my local lan at home connecting
me to my datacenter in tampa. (don't tell my day job, lol).
I am running the MSS adjust and have no issues with it. Even without it, all
major sites on the internet work, only smaller sites have an issue.
We should not be limiting ourselves due to other peoples broken network
designs. On the internet between peering points, where clue is found, I've
never had an issue with icmp blocked. Now on the GRX, yes....
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 7/24/13 6:33 PM, Eric Fort wrote:
> Where are you. I'm trying to get people together in Southern California to
> do pretty much exactly the same thing.
I'm about as far from San Diego as you can get and still be in the US :)
I'm in St Petersburg, FL. Not many local hams here who want to mess with this
stuff, I have a few who I know from work and we're playing with some
re-purposed Alvarion radios.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 7/24/13 6:28 PM, Neil Johnson wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> I like drawings.
>
> Is this what I gather the concept is ?
>
> https://dl.dropboxusercontent.com/u/11681146/AMPRnet_Concept_V01.pdf
>
can you post the visio file? I'd like to revise a couple things.
be aware, there is a little man that pops out of a router and punches you in
the jaw if you type "router rip" ;)
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
I guess it will kind of boil down to applications. And a way to
advertise them to everyone else who has access to the network.
Here are some random ideas
Make a mirror of mods.dk or something like it, are their any unlimited
mod sites? As far as I know you can only lookup one per day.
How about a part-number datasheet lookup service? Or periodical lookup.
Or hosting services for ham software development projects.
For a good place to start how about someone setup a listserver on the
amprnet, perhaps "ampr-services"?
It would probably be a good idea if there was a way for the HSMM nodes
to have a way to tunnel to other remote nodes. Maybe touch base with
the firmware developers?
My thoughts.
The IPIP / JNOS network is an anachronism that is quant but doesn't
take advantage of how technology has evolved. I'm a pretty skilled
network guy but the current IPIP tunnel system has eluded me. I have
gotten close, but finally thrown my hands up each time. (I never get
the rip44d to run and find the proper password.)
However, I can get a VPN tunnel running in short order which can bring
an address range to whatever location is on the full Internet. I have
a personal class-C at home that has functioned over a VPN for over a
year and I have VPN'ed to another Net-44 gateway with success. (In
both cases on inexpensive MikroTik routers.)
I think we need to work on connectivity of the gateways to unify
Net-44 and treat the "on air" connectivity as a separate task.
Whether the on air connectivity is for IP over AX.25 at 1200 bps,
WiFi/HSMM, D-STAR Digital Data, or some new transport over RF. It
doesn't do a lot of good to have islands of on air activity without
interconnectivity of Net-44. Otherwise just use RFC 1918 address
space and NAT it to the Internet.
My vision is that we have multiple BGP gateways on the Internet. Some
may advertise the whole of 44/8 and others may have smaller networks,
clear down to 44.x.x.x/24 Some will be multi-homed, some will not, but
all would be advertised to the Internet for routing. Any router
advertising all of 44/8 would need to know about all routes for
anything with a CIDR of less than /8. I don't think we really want
all traffic to go to 1 or 2 routers advertising 44/8 or we're back to
the everything must go through UCSD scenario of the last couple of
decades.
My recommendation is to find ISPs who are willing to 'donate'
bandwidth and routing for some number of BGP'ed networks, then place
routers at those ISPs which will support authenticated VPN service to
local networks.
Say we had an ISP (or University, etc.) that would donate bandwidth
for 44.24.0.0/16 and 44.12.0.0/16,44.26.0.0/16, and 44.40.0.0/16 and
BGP advertise those ranges. Let's another data center wanted to BGP
44.24.100.0/24. Traffic would flow to the best gateway for each. If
44.24.10.0/24 didn't have the ability to BGP its own address space, it
could VPN to the router at the major gateway (ISP) and that router
would tunnel traffic for that network to the gateway for
44.24.10.0/24. Then there might be a small on the air network at
44.24.128.0/28 and its gateway would VPN to the 44.24.10.0/24 router
who would route traffic for the small network.
This would mean that no special tables need to be passed around. Each
router would know the addresses it was responsible for and would route
all other 44 traffic to its "upstream" and non-44 network traffic to
the Internet through their service provider.
This means the "heavy lifting" of BGP and network routing would be
handled by those ISPs where the expertise exists and a new member of
Net-44 could simply setup a simple router that VPN'ed to an upstream
router to get its traffic and to send Net-44 traffic, all other
traffic would simply pass over local service provider's network.
This is all readily available, off the shelf, technology. For the end
user it is very inexpensive to setup a router with VPN. Then the
local distribution over RF can happen over whatever technology is
available, whether a TNC and FM radio, WiFi dongle, UDR56k-4, Bullet,
etc.
________________________________
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
On 7/24/13 1:02 PM, Neil Johnson wrote:
> I'm a network engineer at another University in the midwest US and I
> *might* be able to convince our routing guru to let us be a BGP peer and I
> could setup another tunnel end point box.
>
> I would need explicit details on how this would work and a the potential
> risks and plans for their mitigation before I approach him.
>
> We don't have earthquakes, just tornados and floods :-)
>
> No promises however.
We have really two networks here. The internal 44-net and the external
internet facing net.
I'd propose to have a few points around the globe where we can peer the whole
44 internet facing net. Each of these locations would announce 44/8 and more
specific routes for what's close to them.
Behind this in the 44-net internal the gateway routers would be meshed over
GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP
sessions between all the BGP speakers, but this would allow end user networks
to tunnel to a given 44/net router, and not need to keep a full route table of
the 44-net internal space. (I hate end stations needing to do routing, that's
why we have routers!)
This would provide full access to the 44/net from outside, easy access from
the AMPR users, and full visibility between directly routed netblocks and the
rest of 44-net with out having to maintain a full mesh.
I'd imagine the more specific announcements from the peering points would be
statically configured, but there is a way to do a limited redistribution from
the IGP into the BGP. I think it would be easier to do it manually (and more
stable), but given some time in the lab at work I could get this going.
Thoughts?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
On 7/24/13 6:15 PM, Marc, LX1DUC wrote:
> (BTW IS-IS probably wouldn't work that well over Layer3 tunnels AFAIK,
> as it is itself a Layer3 protocol and would need to be transported
> over a Layer2 link (please correct me if I'm wrong))
IS-IS will work fine over GRE. GRE forms an interface over which IP/CLNS can
function. Multicast and broadcast traffic works over this as well.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
