7 Mar
2012
7 Mar
'12
7:20 a.m.
I agree, this is in good practice and should be adhered to.
We are utilizing Cisco 7200 series as the actual net facing edge routers although some
will be 2800 series.
These could be substituted with FreeBSD to save cost.
Sent from my iPhone
On Mar 6, 2012, at 6:04 PM, 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:
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:
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 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