7 Mar
2012
7 Mar
'12
7:30 a.m.
I think its important to remember all of the amateur radio restrictions on
content are at the point when the traffic moves onto RF under amateur radio
rules, e.g. in the US, you can operate Part 97 (Amateur) or Part 15 on many
of our microwave bands. Responsibility for filtering content should be
delegated to the party responsible for gating to amateur radio RF.
If we try to control, consistently, at the border gateways, we may be
filtering content that would be otherwise permitted. I think a lot of
amateur networks living on the Internet loose a lot of utility because of
the "one size fits all" or "*one ring to rule them all*" approach.
The
operator of the border router can "throttle" or "filter" traffic
depending
on available bandwidth and local needs.
The network manager / coordinator has a responsibility to insure that the
address space is not being misused and using authenticated access by
subnets, via tunnels or other mechanisms, allows the network manager to
revoke access to a subnet under his/her tier one router for abuse.
If we really want to grow the network, with useful applications, we need to
strike a balance between security and ease of setup / access. Many
applications will have users that are not familiar with the subtleties of
the network and some of our LAN operators will not be strong
administrators. Our greatest need for expertise is at the bridge/gateway to
amateur radio RF and this may be the exact place that we find the least
expertise, this is where the network manager needs to have a toolbox at
his/her disposal to assist. Intervening layers of infrastructure should be
largely "plug and play" -- even to the point where the network manager
says, if you want to connect to the border router, here is a configuration
and credentials for "X" router, install this and you will have
connectivity. Then provide pointers to applications, tools, and
configurations to handle the interconnection of RF.
When AMPRNET was created, we didn't have a lot of the tools we do now, nor
inexpensive off the shelf systems for infrastructure. For example, today we
could have an AX.25 daemon that listens to a TNC or other bridge to RF and
at least in the US, lookup the callsign in the AX.25 header in a copy of
the FCC license database and do a DHCP address assignment to the device on
the other end of the AX.25 connection, add a dynamic DNS entry, and start
routing traffic. With all but the AX.25 daemon being "off the
shelf", pre-configured, hardware.
We have a habit of making things more complex than they need to be and
promoting some "roll your own" solution that could easily be accomplished
using off the shelf technology. Certainly, we should encourage and support
experimentation and innovation, but that is only a segment of the user base
a successful network can and should support.
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
On Tue, Mar 6, 2012 at 16:04, Tim Pozar <pozar(a)lns.com> wrote:
Great ideas.
May I suggest that the router facing the net (ie running BGP4) does not
have to have all of these features on it. In our deployment, the two
OpenBSD (PF) boxes we are running are border only. They only run BGP4 and
have GigE ports trunked going to a switch that breaks things out and
connects to access routers that are downstream that do all the "customer"
facing "features". This could be GRE, IPinIP, etc. Access routers could
be anything from KA9Q to Mikrotik to Soekris boxes running Linux, etc.
Normally you are going to make changes on the access routers and you want
to keep the border routers as stable as possible so you keep changes to a
minimum there.
Having this separation really has saved our bacon a number of times in the
City of San Francisco Community Broadband Network we are running.
Tim
On Mar 6, 2012, at 3:53 PM, Elias Basse wrote:
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
To expand further on a multi-homed system and
with some solid network
experience running a global company network via VSAT and
other Global Mixed
Links:
1) Regarding Routers - A FreeBSD Router running a package such as
PFSENSE fits the
bill http://www.pfsense.org and is well in the price
range of any amateur operator (Free) except it needs to run on a very
robust hardware platform.
2) Regarding the requirements for security - I agree that a form of
security is
needed to ensure that someone is not abusing the system. A
content filter such as Squid/SquidGuard or DansGuardian could be used to
ensure that no nasty things come about across amateur radio bands or the 44
Net.
3) Regarding scalability and IP addressing issues, we should have the
capabilities
for a regional sub-router that has all tie ins to the MPLS via
a tunnel, direct connection, or ip-ip tunnel. This can easily doll out
SECURE VPN (OpenVPN) tunnels to any node or sub-node that is connected to a
public network with little to no overhead. This also opens up another
aspect of bridging the network together and that is MULTICAST voip using an
open source low bandwidth codec as an alternative to the DSTAR AMBE Codec.
4) Regarding DNS, this can be performed rather easily as if you are
utilizing a
*nix based OS you can run a DNS Mirror of the entire network
locally as this is a smaller portion of the internet as a whole.
I am also going to add that caching can also be utilized by sub-nodes to
serve out
pages that have been served out before thus cutting bandwidth
requirements by 40% or more, this also allows something else - A COMPLETELY
OFFLINE COPY! so if the internet ever goes down, there is a copy of the
pages in question on a regional node, that may have a chance to propagate
the page to a user that needs it should we have global network backbone
outages.
In our network for Louisiana that is in the design phases now, we have
incorporated all of these things, as well as given an ipip tunnel option
for each regional router that can populate edge and border gateways behind
it with BGP routes and information. This is all incorporated using RF
links and if not in range of an RF link, a tunnel to one of 9 regional
routers.
We have also carved portions of the address space to allow this as well.
In order to obtain internet access, a user must authenticate their call
sign so
that all web traffic can be logged, in the event of an abuse of the
system.
The entire system is set to utilize HSMM (High Speed Multi Media) Mesh
Radio Links
in the 900MHz, 430MHz (Testing New Cards now), 5.8GHz, and
2.4GHz bands.
I also have drawings, diagrams, and explanations of the entire network
design if
anyone is interested.
Best Regards,
Elias Basse
KD5JFE
Louisiana AMPRNET Coordinator
On Mar 6, 2012, at 4:48 PM, K7VE - John wrote:
> Tim,
>
> I wouldn't suggest we demand a certain make/model. My intent is
"reference" configurations. Certainly a professional can come up with
something that is competent and architecturally compatible.
>
> I also know that an "amateur" / volunteer built and managed
infrastructure often needs recipes for those who are technically competent
enough to learn how to perform routine maintenance, but may not know where
to start.
>
> I've been involved in helping a whole bunch of D-STAR gateways come
online
and while someone familiar with systems and network administration
can work their way through the "rough" spots, often when it comes to that
little extra to track down a problem, there is just not the knowledge
and/or experience to do so -- so they reach out to others. If we have some
reference implementations, and a new border router uses that recipe, then
it is much more possible to advise on troubleshooting.
>
> If a widely deployed system is used, then there is a larger community
that has
discovered and documented special cases, which are often available
on the net.
>
> John D. Hays
> K7VEPO Box 1223, Edmonds, WA 98020-1223
>
>
>
>
> On Tue, Mar 6, 2012 at 14:19, Tim Pozar <pozar(a)lns.com> wrote:
> Great start on the details.
>
> BTW... I wouldn't nail down the hardware to a specific make/model too
much. I run a 1+ Gig community network on a pair of OpenBSD routers (in
failover via VRRP/HSRP/CARP). I run trunks to it and break it out on
common managed switches (ie cisco 2960G). The boxes themselves are two
Rackable servers with the hard drives replaced with SSDs.
>
> I think the requirements for the border router could include:
>
> Must:
> * Can support at least one full route table.
> * Supports 200% of expected bandwidth needs.
> Ie. Up and Downstream feeds, PPS, etc.
> * Be supported by conditioned and emergency power
> * HVAC is also on emergency power
> * Physically secure and accessible by the regional coordinator and
"Amateur Radio Digital Communications" authorized representatives only.
> * (More?)
>
> Should:
> * router(s) are multi-homed
> * routers have fail-over (hot-spare)
>
> Couldl:
> * Enough memory to support large NAT tables (if needed)
> * MPLS
> * VLANs,
> * (More?)
>
> You may have two routers speaking BGP and core and access routers
downstream
of this. It may all be L3 or it could be L2. Up to the needs
of the installation (ie downstream links) and the needs of the community.
Tim
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net