Difference between revisions of "SdNOG Meeting Network Setup"
Sara.alamin (talk | contribs) (Created page with "Category: Best Practices Category: Meeting Setup {{TOCRight}} ==Introduction== As the SdNOG event grows each year, so must the meeting network grow, to scale, and pro...") |
m (Text replacement - "sdnog" to "SdNOG") |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[Category: Best Practices]] | [[Category: Best Practices]] | ||
− | [[Category: | + | [[Category: Events]] |
+ | [[Category: Plans]] | ||
{{TOCRight}} | {{TOCRight}} | ||
Line 7: | Line 8: | ||
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. | 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== | ==General design philosophy== | ||
Line 15: | Line 17: | ||
* 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. | * 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. | A schematic for what the network is expected to look like is provided on the right. | ||
+ | |||
==Wired Network== | ==Wired Network== | ||
===NOC network=== | ===NOC network=== | ||
Line 45: | Line 48: | ||
==Naming Standards== | ==Naming Standards== | ||
− | * All domain suffixes should end in mtg. | + | * 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. | * 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 names should be written in lower-case. | ||
* All system specific names should have appropriate DNS entires (A, AAAA, and PTR) | * All system specific names should have appropriate DNS entires (A, AAAA, and PTR) |
Latest revision as of 12:31, 26 February 2019
Contents
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
- 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)