Quakecon: Network Operations Center tour

[elfkin at gmail.com (Harald F. Karlsen)]

On 02.08.2015 23:36, Josh Hoppes wrote:
> We haven't tackled IPv6 yet since it adds complexity that our primary
> focus doesn't significantly benefit from yet since most games just
> don't support it. Our current table switches don't have an RA guard,
> and will probably require replacement to get ones that are capable.

The lack of RA-guard/DHCPv6-guard can still bite you. A client can still 
send rogue RAs and set up a rogue DNS-server and start hijacking traffic 
as AAAA is preferred over A records by most operating systems these 
days. IPv6 first-hop security is really underrated these days and not 
providing the clients with IPv6 does not exclude IPv6 as a potential 
attack vector.

> We also re-designed the LAN back in 2011 to break up the giant single
> broadcast domain down to a subnet per table switch. This has
> definitely gotten us some flack from the BYOC since it breaks their
> LAN browsers, but we thought a stable network was more important with
> how much games have become dependent on stable Internet connectivity.
> Still trying to find a good way to provide a middle ground for
> attendees on that one, but I'm sure everyone here would understand how
> insane a single broadcast domain with 2000+ hosts that aren't under
> your control is. We have tried to focus on latency on the LAN, however
> when so many games are no longer LAN oriented Internet connectivity
> became a dominant issue.

At The Gathering we solved this by using ip helper-address for specific 
game ports and a broadcast forwarder daemon (which has been made 
publicly available). It sounds really ugly, but it works pretty good, 
just make sure to rate-limit the broadcast as it can be pretty ugly in 
the case of a potential loop/broadcast-storm.

> Some traffic is routed out a separate lower capacity connection to
> keep saturation issues from impacting it during the event.
>
> Squid and nginx do help with caching, and thankfully Steam migrated to
> a http distribution method and allows for easy caching. Some other
> services make it more difficult, but we try our best. Before Steam
> changed to http distribution there were a few years they helped in
> providing a local mirror but that seems to have been discontinued with
> the migration to http. The cache pushed a little over 4Gbps of traffic
> at peak at the event.
>
> The core IT team which handles the network (L2 and above) is about 9
> volunteers. The physical infrastructure is our IP & D team, which gets
> a huge team of volunteers put together in order to get that 13 miles
> of cable ready between Monday and Wednesday. The event is very
> volunteer driven, like many LAN parties across the planet. We try to
> reuse cable from year to year, including loading up the table runs
> onto a pallet to be used in making new cables out of in future years.
>

Thanks for the write-up, it's always cool to read how others in the 
"LAN-party scene" does things! :)

-- 
Harald