Difference between revisions of "Information Systems:Wired Network (LAN) Infrastructure Redesign"
m |
|||
| Line 1: | Line 1: | ||
| + | =Overview= |
||
| + | The redesign of the wired network (layout, configuration etc.) was supposed to happen with new switches, but it was decided that a significant investment was already made in our current hardware, and thus a redesign will be attempted with our current switches. This article details the major areas involved in this redesign. |
||
| + | |||
| + | =Hardware= |
||
| + | Currently, we have the following '''3Com''' switches to work with: |
||
| + | |||
| + | * 4 x 3870 SuperStack - Gigabit, stackable. Access-layer switch. |
||
| + | * 6 x 4200G - Gigabit, managed, stackable. Access-layer switch. |
||
| + | * 1 x 4500 - 10/100, managed, most features amongst all the switches. This is a Distribution or Core switch. |
||
| + | |||
| + | The 4500 is packed with features and its CLI resembles the one on the 4200G. Because we only have 1 of this model, it might be appropriate as a "play" switch. |
||
| + | |||
=VLANs= |
=VLANs= |
||
| − | The entire uniPHARM network is currently a single, very large broadcast domain |
+ | The entire uniPHARM network is currently a single, very large broadcast domain. Here are the proposed VLANs: |
: VLAN 1 - Management VLAN, no devices |
: VLAN 1 - Management VLAN, no devices |
||
| + | |||
: VLAN 10 - Corporate LAN - desktops, printers/print servers, RF guns, outbound NAT through Telus, Terago |
: VLAN 10 - Corporate LAN - desktops, printers/print servers, RF guns, outbound NAT through Telus, Terago |
||
| − | : VLAN 20 - |
+ | : VLAN 20 - Backup traffic, separate L3 domain, no default gateway, no outbound internet access |
| ⚫ | |||
: VLAN 30 - Guest VLAN, outbound NAT through Telus, Terago, no access to corporate intranet |
: VLAN 30 - Guest VLAN, outbound NAT through Telus, Terago, no access to corporate intranet |
||
| + | : VLAN 40 - Storage traffic (SAN iSCSI), separate L3 domain, no default gateway, no outbound internet access |
||
| − | : VLAN 50 - Telus Corporate WAN, /27 (Superman WAN, Bart (public), Mail (public), Infoblox) |
||
| + | |||
| − | : VLAN 51 - Terago Corporate WAN, /29 (Superman WAN, Bart (public), Mail (public), Infoblox) |
||
| ⚫ | |||
: VLAN 60 - DHL/Loomis LAN |
: VLAN 60 - DHL/Loomis LAN |
||
| − | It is important to note that routing will be needed to route traffic between some of our VLANs. |
+ | It is important to note that routing will be needed to route traffic between some of our VLANs. The Sophos should be able to handle inter-VLAN routing, so VLAN interfaces should be setup as part of the configuration. Since the UTM220 has limited ports, router-on-a-stick can be used to route between some of the VLANs. The WAN ports to the Telus and Terago router/modems should remain dedicated for ease of administration. |
| + | The management VLAN should ideally be changed from its default setting of VLAN 1, but our network is pretty small and network secur |
||
| ⚫ | |||
| + | |||
| + | ==Stacking== |
||
| + | Since we have 4 of the 3870s, stacking should be explored to see if it's feasible and ideal for our environment. It does make sense to administer everything as one, especially since there is a high port density in the server room. |
||
| + | |||
| ⚫ | |||
A spanning tree topology should be implemented to provide redundancy during a switch failure and to prevent broadcast storms from mis-plugging of ports. |
A spanning tree topology should be implemented to provide redundancy during a switch failure and to prevent broadcast storms from mis-plugging of ports. |
||
Root bridges will be the server room switches. |
Root bridges will be the server room switches. |
||
| + | |||
| + | ==RMON and sFlow== |
||
| + | Port analysis is useful for troubleshooting, and for general insight into what's going on in our network. sFlow should be enabled for traffic sampling, and one port in each switch should be set as an analyzer port (for Wireshark). |
||
| + | |||
| + | ==LACP/port aggregation== |
||
[[Category: Networking]] |
[[Category: Networking]] |
||
Revision as of 11:59, 28 November 2016
Overview
The redesign of the wired network (layout, configuration etc.) was supposed to happen with new switches, but it was decided that a significant investment was already made in our current hardware, and thus a redesign will be attempted with our current switches. This article details the major areas involved in this redesign.
Hardware
Currently, we have the following 3Com switches to work with:
- 4 x 3870 SuperStack - Gigabit, stackable. Access-layer switch.
- 6 x 4200G - Gigabit, managed, stackable. Access-layer switch.
- 1 x 4500 - 10/100, managed, most features amongst all the switches. This is a Distribution or Core switch.
The 4500 is packed with features and its CLI resembles the one on the 4200G. Because we only have 1 of this model, it might be appropriate as a "play" switch.
VLANs
The entire uniPHARM network is currently a single, very large broadcast domain. Here are the proposed VLANs:
- VLAN 1 - Management VLAN, no devices
- VLAN 10 - Corporate LAN - desktops, printers/print servers, RF guns, outbound NAT through Telus, Terago
- VLAN 20 - Backup traffic, separate L3 domain, no default gateway, no outbound internet access
- VLAN 30 - Guest VLAN, outbound NAT through Telus, Terago, no access to corporate intranet
- VLAN 40 - Storage traffic (SAN iSCSI), separate L3 domain, no default gateway, no outbound internet access
- VLAN 50 - WAN traffic (Telus, Terago)
- VLAN 60 - DHL/Loomis LAN
It is important to note that routing will be needed to route traffic between some of our VLANs. The Sophos should be able to handle inter-VLAN routing, so VLAN interfaces should be setup as part of the configuration. Since the UTM220 has limited ports, router-on-a-stick can be used to route between some of the VLANs. The WAN ports to the Telus and Terago router/modems should remain dedicated for ease of administration.
The management VLAN should ideally be changed from its default setting of VLAN 1, but our network is pretty small and network secur
Stacking
Since we have 4 of the 3870s, stacking should be explored to see if it's feasible and ideal for our environment. It does make sense to administer everything as one, especially since there is a high port density in the server room.
Spanning Tree
A spanning tree topology should be implemented to provide redundancy during a switch failure and to prevent broadcast storms from mis-plugging of ports.
Root bridges will be the server room switches.
RMON and sFlow
Port analysis is useful for troubleshooting, and for general insight into what's going on in our network. sFlow should be enabled for traffic sampling, and one port in each switch should be set as an analyzer port (for Wireshark).