Hackerspace Network Planning
| This article is a Draft. Information within may be incomplete; use at your own risk. |
Contents
Hackerspace Network Planning
This page serves as a place for ideas for the Hackerspace computer network; and how it plans to be grown out as we gain resources or members.
Minimal Network Layout
In a very, very minimal network layout, we can simply use whatever off-the-shelf router (very possibly the one supplied by our ISP, or someone's WRT54GL) to get internet access into the hackerspace.
This is plenty for an initial buildout, cheap to set up, quick to deploy; but a little limiting, as well as full of single points of failure. Definitely enough to get us access during our initial buildout.
Actual Network Layout
As we grow, we will want some actual segregation of traffic, the ability to put firewalls in place, some redundancy, and the ability to issue subnets to hackerspace projects as needed. As well, I'd like to get a colocation network in place for permanent or semi-permanent projects that may be hosted on the hackerspace network and/or exposed to the internet.
In addition, being able to sublet our traffic out to other sub-tennants, if necessary, would be a useful addition. For that, we'd also want some form of rate-limiting on both networks (to offer some reliable level of service to both the Hackerspace's network clients, and our sublet clients).
Visual overview
Each differently colored background block represents a separate VLAN and subnet.
Proposed network layout
Network Edge
All traffic should be routed through an edge router; and, ideally, a pair of routers in a VRRP or CARP failover configuration. These are named "sshc-cgx-edge-01/02" in the above diagram.
Currently, the plans are to run an open-source router-focused OS distribution, very likely Vyatta or pfSense, on sshc-cgx-edge-01/02.
The "Sublet Network" is not necessarily going to be required, but is in place if we are sharing a space with another organization and would like to share internet connectivity and costs.
Distribution Layer
From there, an distribution switch (named "sshc-cgx-dist-01") will be broken out into three further physical switches (and more from that level, if necessary).
Ideally, sshc-cgx-dist-01 should be an OSI Level 3 aware switch; though that may be cost-prohibitive. If so, sshc-cgx-edge-01/02 can be used for routing (or another router (pair) added in).
Internal Network Layer
Currently, there are three VLANs planned to operate in the Internal Network Layer.
Internal Support Network
(Switch: sshc-cgx-util-01)
The Internal Support Network is a network for internal SSH:C administrative IT services - LDAP, VoIP, key server, access control server, internal database, and so on.
This network will be secured more closely than other networks, simply due to the fact that the information stored within may be sensitive, and a compromise in this area could be rather disruptive.
Colocated/Production Network
(Switch: sshc-cgx-colo-01)
The Colocated/Production Network is a network that is used for storing permanent or semi-permanent member systems. This is the network that will have the ability to be placed directly on the Internet, and also where the sshchicago.org website will live (if it is moved on-site).
General Office Network
(Switch: sshc-cgx-org-01)
This is called the "Office" network for lack of a better name. All Member personal computers, workstations/dashboards out in the Hackerspace, and wireless devices will be in this network. Demand for downstream bandwidth (from the Internet) is expected to be highest here, so tracking of consumption may be a concern.
Proposed/Necessary Network Applications and Services
- LDAP
- DNS
- DHCP
- Shared file server/homepage store
- Squid proxy (if we aren't likely to have a wide pipe, this is probably a good idea)
- Backup server?
- Mirror of popular linux distribution repositories?
- IDS/other security features?
- VoIP server?
Physical network considerations
Moved to Network Drops and Cabling
Hardware Wishlist
Network Equipment and Servers
- One (or ideally, a pair) 1U rack-mount server with space for two ethernet ports (either onboard or a free expansion slot); running some form of a reasonably recent x86_64 CPU. (This will be for use as the edge router). Power consumption is a concern as well, if we can get something that's less power hungry than a P4, that would be ideal.
- A few more x86_64 servers of some sort to start running some of our internal administration services on
- Rackmountable Patch panels
- Ladder or Basket rack (this will depend heavily on how we are able to run cables - even if we have the option to run them through the walls, we may not want to for flexibility's sake).
- 0U PDU
- Cabinet (we have this)
- Rack mountable, managed switches. For the network layer switches, we can probably get away with just gigabit uplinks on the network-layer switches.
- Rack mountable, managed switch for distribution layer. Ideally, this should be gigabit all the way across (or, even better, a layer-3 aware switch), but that gets expensive! :)
- Rack-mounted cable management (one for each switch)
Tools
- Network crimper(s)
- Punchdown tool
- Brother P-Touch (for labeling things)
- Fish tape
- Ladder
- Cable tester
- Cable tracer
Consumables
- Velcro ties
- P-Touch Cartridges
- Keystone jacks
- RJ45 jacks
- Wall plates?
Estimated Cost
I've drawn up a really, really rough estimate of costs; simply off of Newegg pricing. Some of this hardware may want to be revisited; and we're definitely open to donations! :)
Services
A table of stuff to get running on the network. FQDNs for these will be hostname.sshchicago.org, but resolve to RFC1918 addresses.
| Hostname | Software | Purpose | Operating System | Hardware recommendation |
|---|---|---|---|---|
| auth | FreeIPA | Authentication server (including LDAP and RADIUS) | CentOS | Virtualized |
| spacewalk | Spacewalk | OS Deployment Server/Linux Distribution Local Mirror | CentOS | Virtualized |
| monitor | Zenoss | Monitoring server | CentOS | Virtualized (hopefully) |
| rancid | Rancid | Network hardware configuration tracking | CentOS | Virtualized |
| sshc-cgx-edge-01 | pfSense | Router and Firewall | pfSense | Physical, Atom server or equivalent |
| log | Syslog/Logstash (or even put with Zenoss) | Syslog server | CentOS | Virtualized |
| monkey | Assorted (TFTP, PXELINUX, attached to serial port on hypervisor) | Utility box | CentOS | Virtualized |
Current state
We have our pfSense router in place, at https://192.168.1.1. Username is "admin."
pfSense info
All settings are still at their default, excepting a Squid cache (which can be turned off under Services), and the DHCP server is configured for network booting (which currently doesn't work).
