On 7/7/13 12:13 PM, Bill Vodall wrote:
> It should only cost about $1K each node and some hundreds of hours.
> Then, when it's working - if you do find the paths, there will be
> endless discussions of what can and can't flow on the system and what
> keys can or can't be used.
>
> Compare that to Facebook today with a broadband account that just works.
>
> It'll be hard enough getting a path with an ID-1 (price reduced - $710
> at HRO) or UDR56K... Then you still have the content and use case
> issues...
First, most linking repeater systems cost 5-10k for a basic setup, so 1k a
node is not out of line.
Perhaps it's un-amateur of me, but I'm not so much concerned with potential
minor part 97 violations if it means I'm on the air with others and providing
a service to hams at large. Much like the legalities of dancing on ATV, I
don't care to arm-chair lawyer mp3's over a data link, or logging every frame
I send over the air.
If something needs to change in part 97, I'll sign whatever petition, or
comment on it if need be.
I'm an engineer, and building networks is fun for me, not arguing about why we
can't do it.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
>I remember hearing about these though I'd consider these to be somewhat of
>an oddity. again why 70cm, only 30MHZ wide & already filled with other
>users? Why is everyone so damn scared and afraid of moving to the amateur
>microwave bands where we have 1555MHZ of mostly unused spectrum from
>1.2-47.2GHz? Why must we recreate the wheel so much of the time when it
>may be better, faster, easier, & cheaper to use directly or adapt a
>solution already in use in another service.
>Eric
>AF6EP
Well, partly because the availability of solutions in other services puts
our band in danger.
For example, the presence of WiFi in the 13cm band (we have 2320-2450)
already resulted in a ban to use 2400-2450 because of WiFi interference.
The same will probably happen on the 5.7 GHz band now that it is becoming
more popular for WiFi.
70cm is only 10 MHz here and part of that is already allocated to other
services and we are only secondary to them.
1240-1300 we are going to lose when Galileo (the European GPS) is becoming
deployed. Only a small segment for DX will probably be left (1296)
The more a band is attractive for other services, the more likely we are
going to lose it soon. The much higher bands will remain availble for now,
but they are not as attractive.
Rob
It would seem Linux and Ethernet whatever architecture it's running on
would seem to be the best solution available for routing Net44 at the
moment and it works well. a standardized plug and play package of hardware
sold by your local candy store would be nice but we're only partially
there. Being that 44NET/Amprnet is supposed to be a RADIO BASED IP NETWORK
(or at least interconnected islands of RADIO BASED IP NETWORK) we seem to
only have half of a standardized solution to offer. It seems that we have
forgotten the RADIO part. Given a live piece of cat5 with bits on it that
I wish to have show up elsewhere what can we offer to the average ham that
can go on the tower with Ethernet in one side and an antenna on the other,
especially something standard enough that a local group can set up a
network with? The only thing I can think of that even comes close is the
professional grade 802.11 hardware that's out there. (much of the consumer
stuff lacks the configurablity we could really use such as power control
and timeouts). I might propose that we standardize the RF interface for
AMPRNET on an agreed physical layer (of 802.11 unless something else is
proposed and made quickly and cheaply available) and a relatively standard
stack of hardware and software be put forth as a package that could be
turnkey deployed by interested parties. What would others think of
embarking upon such a project as a group? who might be interested? and
what might we offer? (PS. I know of at least one manufacture of gear that
would be quite happy to mod a standard product or products so as to have
them better fit the amateur radio band plan and channels on a couple of our
microwave bands as well as make provision for the ability to get
significant QRO above the 25-30dbm out that seems standard. This in
production batches maybe as low as lots of 100 units)
Eric
On Fri, Jun 28, 2013 at 1:32 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org>wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Actually, Linux on x86 hardware is just as much of a "hardware-based"
> solution as any proprietary OS on proprietary hardware is. In fact, Linux
> on x86 easily outperforms most proprietary hardware solutions up to and
> beyond the Cisco 7x00 range, especially with the current Intel architecture
> systems. Vyatta (now part of Brocade) and others have proven that over and
> over for the last several years.
>
> I hope we can establish something that's vendor neutral, rather than any
> type of single vendor lock-in.
>
> Michael
> N6MEF
>
>
> ----
>
> In the performance class we are operating in, "hardware based" is not
> really
> required.
> A suitable box (processor and ethernet interfaces) and software (e.g. Linux
> plus some usermode
> tools) can do the same thing.
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
> http://www.ampr.org/donate.html
>
Hessu;
Can you please email me off list? Thanks in advance.
--
Brian Rogers
Phone: 860-673-4537
Email: n1uro(a)gmx.com
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org/
Platform: Linux
URONode/axMail-Fax created here!
Coordinator for:
1-land, DE, and N.J AmprNet
On 6/27/13 2:26 PM, K7VE - John wrote:
> Great idea - wrong platform. Cisco specific solutions aren't reachable for
> many.
>
> Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like
> MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc.
I take issue with that. MikroTik is just as much of a closed platform as
Cisco/JNPR/ALU/Fond-cade/etc.
Cisco is ubiquitous, to a lesser extent Juniper (though I have to favor ALU
for MPLS/core!).
I'd say what we need is an open standards based solution that works across
linux/cisco/jnpr (maybe an o-series? :)
Something custom protocol wise to tie the 44net together is not ideal either
as we cannot expect the big router vendors to support amprnet protocols. I
know I'm able to slap a 1ru router (ie c2[6-9]00) in lots of places with good
connectivity I could never put a server.
I belive there is a way to do this via NHRP with BGP. I know I have a
customer doing something like this. Since we don't need crypto for 44net I
suspect it would work for us.
just my .02
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
I am working on a lab design to add some flexibility and test other
connection methods to the 44.0.0.0/8 network. I currently have a Linux
gateway running rip44d for my main connectivity to the other 44/8 subnets.
I have setup a Cisco based DMVPN where I can route other subnets to and
route back to the Linux gateway for access to other subnets. This
configuration also allows access from the public Internet to the allocated
subnets via a Linux gateway.
I have a diagram with a working layout and is in testing now. I am looking
to see if anyone might be interested in connecting up to my cloud and see
what and if any problems we may encounter. I use a very similar setup with
my customers and there are some distinct advantages:
- The end user would only need an internet connection and a Cisco
DMVPN capable router. I have used 800, 1800, 2800, 3700 series Cisco
routers.
- The DMVPN works when you plug the Cisco router into a direct
Internet or NAT connection. You can plug it in at home behind your Netgear
home router, use DHCP and a private address on the router "public"
interface.
- Many subnets can be routed through a single Linux gateway and
distributed easily.
- No issues with dynamic IP address from your provider.
If you are interested or have any comments or suggestions, take a look at
the network diagram I made at
http://www.hindmarsh.cc/images/wc3xs-ampr44.png
73 de WC3XS - Jesse
Jesse Hindmarsh <jesse(a)hindmarsh.cc> wrote:
>
>
>
>
>
> Rob,
>
> I like your thinking. Are you a Cisco guy too? I have been for too long :-)
>
> I am still partial to hardware based solutions.
>
> Jesse - WC3XS, CCNP Voice, CCNP RS, CCDA
I learned networking with the KA9Q software and later when I got a job as a sysadmin I worked
with existing Cisco routers and found many things very familiar. I learned the Cisco stuff myself from
the manuals, have no CC certifications. I converted our existing network at work from leased
lines to VPN some 10 years ago over Internet using DMVPN and it worked very well.
(now we have dedicated lines again, but that wasn't affordable at megabit speeds 10 years ago)
I suggested DMVPN before on this list, and I still think it could be a good option at least when
an open implementation is available. I don't know if it is today, it has been in the works for
some time. (the specs are open)
In the performance class we are operating in, "hardware based" is not really required.
A suitable box (processor and ethernet interfaces) and software (e.g. Linux plus some usermode
tools) can do the same thing. I run IPsec tunnels between Ciscos, between Linux boxes,
and between Cisco and Linux, and it is all inter-operating well.
Of course we don't want to tie outselves to "only Cisco". But a solution where Cisco and open
implementations (on systems like Linux and BSD) inter-operate is a very good thing.
IMHO we don't need to consider compatibility with DOS (e.g. JNOS on DOS) as critical anymore.
Rob
K7VE - John <k7ve(a)k7ve.org> wrote:
> Great idea - wrong platform. Cisco specific solutions aren't reachable for many.
>
> Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc.
The big advantage of Cisco DMVPN is that it can create a fully meshed tunnel network with endpoints
on dynamic addresses, with only one (or a few) central hubs on static addresses, fully automatically.
It is like what you have with a JNOS or Linux route importing encap.txt all the time, but without the hassle.
Other VPN solutions are usually hub-and-spoke, where all internode traffic goes through the central hub.
It is like connecting to net-44 by tunneling everything to 169.228.66.251 instead of loading a routing table.
Rob
Jesse,
Take a look at my startup script at
http://44.60.44.13/startampr
It seems you have a similar setup, although one line of your
configuration seems incorrect:
ip route add 44/8 via 169.228.66.251 dev tunl0 onlink src 44.64.192.253
You should remove this route, it's invalid inside AMPR. You should not
reach 44.0.0.0/8 via AMPRGW (169.228.66.251), you should reach each
subnet via its gateway WAN IP address, as populated by rip44d. The
return packet would come in the same manner, via their 44GW that has a
route configured for you.
My router:
@kb3vwg-001:~# ip route get 44.64.192.253
44.64.192.253 via 24.229.88.252 dev tunl0 src 172.31.255.254
My route table shows:
44.64.192.0/24 via 24.229.88.252 dev tunl0 onlink window 840
73,
Lynwood
KB3VWG