Information Systems:Wired Network (LAN) Infrastructure Redesign

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, managed, stackable. Access-layer switch.
• 6 x 4200G - Gigabit, managed, stackable, decent web interface. Access-layer switch.
• 1 x 4500 - 10/100, managed, most features amongst all the switch models. This is a Distribution or Core class of 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.

Configuration changes

Switch features

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 the risk of compromised access to the switches (and potential threats to our network) is very low, so leaving this as is should be fine. This way, you won't need a VLAN-capable device to quickly access and troubleshoot the switches.

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. Rapid spanning tree will be employed; I don't really see anything better.

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

Switches should be connected to each other by multiple ports trunked together. Some servers links should also be aggregated for increased bandwidth. Note that port-bonding will not necessarily speed up BackupExec backups or lead to a noticeable speed increase for users. This is because disk bandwidth is far more limiting. What port trunking helps with is accommodating max bandwidth utilization by many users (e.g. the transferring large files from Superserver to multiple desktops).

QoS/traffic prioritization

QoS will be absolutely essential if and when we get IP phones. For now, it will be used to rate-limit certain kinds of traffic and reserve bandwidth for other types.