SdNOG Meeting Network Setup

From SdNOG wiki
Revision as of 12:31, 26 February 2019 by Admin (talk | contribs) (Text replacement - "sdnog" to "SdNOG")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Template:TOCRight

Introduction

As the SdNOG event grows each year, so must the meeting network grow, to scale, and provide essential network services to the workshop participants, and plenary attendees. Starting with SdNOG-2, a more holisitic approach has been taken to the network design and layout for the multi-day event.

In the spirit of co-operatation, and transparency, the details, layout, and thinking behind the design are all explained here, in the hopes that others would find this design useful, and, used as a base to improve on, for the next event (and to others). The design is made without bias to equipment; it is expected that where there are equipment shortfalls, adjustments can be made as necessary to compensate for this.


General design philosophy

SdNOG Network Layout
  • The network should be entirely dual-stacked where possible.
  • There should be no Network Address Translation (NAT) used. Address space for the event can be obtained free of charge from AfriNIC, and should be done so 30days before the event.
  • The different networks should be separated at Layer-2 level to limit broadcasts, and to aid in troubleshooting.
  • Services in use at the event, are encouraged to be run onsite, so that services may continue operating in the event of a link outage.

A schematic for what the network is expected to look like is provided on the right.

Wired Network

NOC network

  • A wired network should be available for all critical NOC services, such as onsite:
    • DHCP
    • DNS
    • NMS
    • streaming
    • etc.
  • The wired network should NOT provide DHCP services for the NOC subnet, except for authenticated hosts, for example, for known MAC addresses (like the wireless APs)

Wired User Network

It's anticipated that there will be very few users that do not have a wireless capable device. For these users, we will have a separate wired network (ie. not the same as the NOC network) that they may use to connect to the event network. It is anticipated that we will use the legacy network for this (see below). It's desirable to keep records of the ports used, since this will be helpful in planning future events, and assessing the continued need for this.

Note: we do this now (before the event) since it's easier to setup and run and manage, than have to do this during the meeting, when it is expected that the NOC staff will be otherwise occupied.

Wireless Networks

Secure wireless

  • The general networks will be protected by a WPA2-PSK key.
  • It is desirable that both 2.4Ghz and 5Ghz network services are made available, and where possible, users encouraged to use the 5Ghz radio.
  • The SSIDs in use will be:
    • SdNOG (for the 5Ghz network)
    • SdNOG-gn (for 2.4Ghz network). It is desirable that the naming of the SSIDs encourage use of the "5Ghz" radio. These names may change closer to the event.
  • DHCP4 and DHCP6 will be in use on the subnet.


Unprotected wireless

(aka legacy network)
Not all users may have devices that can support WPA2-PSK, through a mix of either hardware, and/or software issues. (Windows XP, SP2, for example). For these users, we plan to have a hidden (ie. non-beaconed SSID) that they would be able to use. Codenamed legacy, this should be known only to the NOC staff, and made available only to users that request it. A key goal would be to determine what the actual usage pattern for this network is, to be able to make an educated guess as to whether, or not, to provision for this future years.

Naming Standards

  • All domain suffixes should end in mtg.SdNOG.sd
  • It is expected that devices will be named in the format: ap0x, where x denotes a number relating to however many devices there may be. Even when it is expected that there is just one (1) device, we expect the standard to be followed to allow for easier insertion of future devices.
  • All names should be written in lower-case.
  • All system specific names should have appropriate DNS entires (A, AAAA, and PTR)