Museomix is a short event where coders, designers, hackers, cultural and museum experts brainstorm on collections and museum installations. This document gives hints on network deployments and IT infrastructure for such event.
The figures given in this document are based on a 100 people event.
It is of utmost importance to anticipate network distribution to museum exhibits and attendees. When possible, Cat-5 cabling should be used, especially for exhibits : this will make life easier to teams since they won't have to deploy WiFi on the exhibits, which is often an additionnal burden. However, it should be possible to place WiFi access points to feed wireless network to the exhibits if needed.
Deployed Ethernet switches should be manageable and support 802.1q VLAN tagging/trunking. Without this, segmenting network won't be possible, and LANs won't span among several switches.
This also applies to attendees : whenever possible, copper cabling should be used. It's more predictible and reliable than wireless links.
However, WiFi is a must have and carefull planning WiFi gear is the key of a successful event network. People typically expect a wifi network to be as reliable as what they have at home. While this is quite easy to achieve at home, the problem is much different in such events where many more devices are involved and generate much more traffic.
Thus, specific hardware is often required to address these issues. Unless budget is very tight, using low-end access points is not an option and specialized gear for high density environments (Meraki, Aruba, ...) should be considered.
With 100 attendees, DHCP subnets must be big enough to avoid IP address exhaustion. Since people typically carry a laptop, a smartphone and sometimes a tablet, a reasonable rule of thumb is to count 3 IP address per attendee. So, using a single LAN network topology, a class C won't provide enough addresses. Active network hardware, shared ressources and museum exhibits will also eat up addressing space and should be counted.
Thus, it is strongly advised to use aggregated class C networks (or a class B can be used if CIDR aggregation is not desirable). However, having large LAN segments will involve a lot of broadcasting and might brind down WiFi to it's knees. In this case, segmenting the network might be considered. However, this has non-trivial implication on layer-3 routing.
Networks fail, needs vary... Having multiple oubound links to different providers is to be considered closely. At #museomix2012, we had 3 uplinks. All three had been used during the event. Several reasons for multiple links can be though of.
Having multiple uplinks to different providers increases reliability. If one link fail, traffic can be quickly redirected to another working uplink. Of course, the network topology must be flexible enough to allow automatic or manual uplink swapping.
All users are not equal... The event management team typically want a dedicated high performance network, unaffected by attendees usage. This uplink doesn't need to be a big pipe. It just has to be dedicated to few people so bandwiths availability is guaranteed and traffic stays manageable. This could also be accomplished using QoS on a the main fat pipe. But since multiple pipes are highly recommended, using the spare link might be easier.
Of course, this has some implication on network topology and it's probably easier to use a dedicated (V)LAN for the management team with a dedicated gateway (with, in turn, has implication on shared network ressources like file servers and printers).
Using multiple uplinks can be used to distribute load over several links. This will help providing enough bandwith to users if available pipes are not big enough. Of coure, combining load sharing, QoS and automatic fail over (fault tolerance) is really what's should be achieved, but adds significant complexity to the network topology.
Such events typically involves a lot of outbound communication : the local teams will publish a lot of multimedia material on social networks. Moreover, users among these technical profiles often use cloud synchronized data (Dropbox, Facebook, ...).
This kind of usage will eat up a significant amount of upstream bandwith, which is often much more expensive than downstream bandwith. While emphasis should be placed on upstream bandwith, cloud storage has usually a bounce effect : people share their data uploading to cloud storage, an team members automatically download the document. While some cloud sharing software can handling this cleverly (Dropbox can use LAN for synchronization), not all do.
While it's not easy to scale properly, it seems from past experience that a 10Mbps upload pipe for a 100 attendees event is a minimum.
You need to distribute IP addresses, thus a DHCP server is required. Be carefull not to have multiple DHCP servers on the LAN (AP often provide DHCP addressing). You'll need to define/exclude ranges, or add static entries too (your maangement station or printers for instance).
Provide a local caching DNS server to your attendees. It will improve response times and you'll be able to server specific DNS records if needed (for shared ressources for instance).
To tackle down bandwith usage, it's recommended to set up a shared file server. This server should :
- be open to everyone on the local network
- use a protocol supported by all attendeeds operating systems (this ususally boils down to CIFS with Samba)
- have per team shares
Since this is a collaborative and open effort, authentication is not required. However, the fileserver must be accessible to attendees only.
Another option is to use a local, cloud-like sharing platform like Owncloud. However, this implies much more upfront configuration (adding users, creating groups).
Being able to synchronize data on the local file server to a remote server could be a desirable feature. However, active/active setups (where data can be written locally and online) are hard to setup and might lead to unexpected results. It is probably better to be able to write locally, and read only online.
Having a fast, network enabled color printer is a must for such event. However, just like the network links, a second printer should be made available for the management team and as a fallback for the attendees. This should not be understated. Being caught in an attendees swarm grumping about the printer not working is not something you want to experience, so having working printers is really a must.
Staying away from working printers is also a must : staying close to the printer will make you the de-factor printerman. Even if the printer works, attendees will often have hard time configuring them properly. Plan ahead and have detailled, per-OS setup instructions displayed next to the printers.
This can comes handy if you provide hardware for the exhibits. Many people in numeric arts use linux a their OS of choice. If you envison a lot of linux deployments over the course of the event, having a TFTP/PXE server to boostap linux installations on workstations will save everyone a lot of time and bandwith.
Installation may vary, but having a local package repository (using apt-mirror for instance) will save a lot of bandwith and make things much quicker.
If you hand some hardware (read: workstations) to attendees, make sure they are delivered blank (and you provide PXE/TFTP bootstrapping services) of with a bare OS. A frequent mistake is to take computers from the shelf without considering how they are currently configured. While this can lead to internal data to leak, it will also add a lot of confusion on the field.
- carefull planing, well ahead of event date since gear might have to be acquired
- use specialized wifi gear
- use manageable switches
- hard to test before the event
- be confident with the deployed hardware
- choose a topology and stick to it
- as a network admin, stay away from the printers