Information Systems:Wired Network (LAN) Infrastructure Redesign - Revision history

Norwinu at 20:19, 19 April 2017

2017-04-19T20:19:44Z

Norwinu at 17:32, 24 February 2017

2017-02-24T17:32:36Z

Norwinu at 17:27, 24 February 2017

2017-02-24T17:27:04Z

Norwinu: /* IP address changes */

2016-11-28T20:31:32Z

IP address changes

Norwinu: /* Stacking */

2016-11-28T20:27:44Z

Stacking

Norwinu: /* Switch features */

2016-11-28T20:26:28Z

Switch features

Norwinu: /* Configuration changes */

2016-11-28T19:40:45Z

Configuration changes

Norwinu: /* Configuration changes */

2016-11-28T19:32:04Z

Configuration changes

Norwinu: /* Hardware */

2016-11-28T19:17:53Z

Hardware

Norwinu at 19:16, 28 November 2016

2016-11-28T19:16:19Z

← Older revision		Revision as of 20:19, 19 April 2017
Line 72:		Line 72:
	Should we keep the DMZ - 172.30.25.0/24?		Should we keep the DMZ - 172.30.25.0/24?

−	[[Category: ~~Networking~~]]	+	[[Category: Archived Pages]]
−	[[Category: I.T. Projects and Ideas]]

← Older revision		Revision as of 17:32, 24 February 2017
Line 1:		Line 1:
−	{{quote \|Network ~~implementation~~ re-design (switch swap) will occur March 3, 2017. Discussion for that project can be found [[Information Systems: ~~March 2017~~ Network redesign \| here]].}}	+	{{quote \|Network re-design (switch swap) will occur March 3, 2017. Discussion for that project can be found [[Information Systems: Network redesign implementation \| here]]. This page represents initial discussion prior to actual planning of the project.}}

	=Overview=		=Overview=

← Older revision		Revision as of 17:27, 24 February 2017
Line 1:		Line 1:
		+	{{quote \|Network implementation re-design (switch swap) will occur March 3, 2017. Discussion for that project can be found [[Information Systems: March 2017 Network redesign \| here]].}}
		+
	=Overview=		=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.		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.

@@ Line 62: / Line 62: @@
 ===IP address changes===
-With the incorporation of VLANs, IP addresses will need to be reconsidered. /21 likely won't be necessary.
+With the incorporation of VLANs, IP addresses will need to be reconsidered. /21 likely won't be necessary. New DHCP pools will also need to be setup, and it should be decided whether this is served by the AD domain controllers, by the Sophos, or by the
 [[Category: Networking]]

@@ Line 37: / Line 37: @@
 ===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 multiple switches as one, especially since there is a high port density in the server room.
 ===Spanning Tree===

@@ Line 51: / Line 51: @@
 ===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.
 [[Category: Networking]]

@@ Line 13: / Line 13: @@
 =Configuration changes=
-==VLANs==
+==Switch features==
 The entire uniPHARM network is currently a single, very large broadcast domain. Here are the proposed VLANs:
@@ Line 34: / Line 35: @@
 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==
+===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==
+===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==
+===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==
+===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/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.

@@ Line 5: / Line 5: @@
 Currently, we have the following '''3Com''' switches to work with:
-* 4 x 3870 SuperStack - Gigabit, stackable. Access-layer switch.
+* 4 x 3870 SuperStack - Gigabit, managed, stackable. Access-layer switch.
-* 6 x 4200G - 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 switches. This is a Distribution or Core 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.

← Older revision		Revision as of 19:16, 28 November 2016
Line 11:		Line 11:
	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.		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=
⚫	=VLANs=
		+
		⚫	==VLANs==
	The entire uniPHARM network is currently a single, very large broadcast domain. Here are the proposed VLANs:		The entire uniPHARM network is currently a single, very large broadcast domain. Here are the proposed VLANs: