The objective of this case study is to produce a portion of the design for an Enterprise Wide network to be implemented across several educational sites in the South East of England. This enterprise network is known as the Virtual Education Action Zone or VEAZ. Each VEAZ site will contain a Local Area Network (LAN) or networks. These will be interconnected as a Wide Area Network (WAN) to form the Action Zone!
This case study focuses on the Greensward College site within VEAZ chosen by the authors to act as the Primary Site.
The design brief requires the case study to be presented as web pages. The URL is: http://www.nikmakris.com/cisco_tcs/
Within VEAZ the routed protocols to be supported are TCP/IP and Novell IPX. The routing protocols will be RIP and IGRP.
A single Class B IP address, 22.214.171.124, has been as allocated to the VEAZ project. A suitable addressing scheme is to be devised accommodating the subnetting and host requirements of the Enterprise. Initially three workgroups per site are required - Administration, Curriculum (student) and Server. Restricted access across workgroups is required.
As VEAZ is a collection of networks under a common administration sharing a common routing strategy the assumption has been made that the Internet Assigned Number Authority (IANA) has allocated an Autonomous System (AS) number. 10 will be used as the AS number used in this case study.
The Virtual Education Action Zone is an Enterprise Network consisting of a primary site and a number of secondary sites. This design is for the primary site, but also takes account of factors affecting the whole of the Enterprise Network. The emphasis of this design is on the hardware used, the protocols to be employed and how the network will be secured. Above all the design must be scaleable with a projected network life-span of seven to ten years. Taking into account 100% growth during that time.
The Action Zone office is located at the Primary Site. It contains the master management host, which has full access to all devices on the network. All router configuration will be carried out from the master host allowing central storage and back-up.
Initially three workgroups per site will be provided - Administration, Curriculum (student) and Server. Access across workgroups is to be restricted.
Controlled access to the internet will be allowed.
The following will be provided as enterprise servers:
The following workgroup servers are to be provided on the Primary Site. These will be linked across sites to provide redundancy in the event of failure:
General Design Considerations
Estimation of present and projected traffic load. This depends on the applications to be used. Includes remote applications and databases and backups across the network. Ideally the Enterprise network should provide video conferencing between sites and voice over IP telephony.
Analysis of the current network at Greensward resulted in the design as shown in the site diagram. One MDF, which incorporates the Point of Presence, will support six IDFs connected in Star topology. The MDF and IDF placement ensures cable runs of less than 100 metres for UTP and 2000 metres for fibre. Each IDF can support growth in the host population.
The MDF and IDF placement present no Health and Safety or environmental issues.
All cabling will be EIA/568 standards. Cat 5 UTP cable will be used for LAN connections which supports speeds up to 100Mbps. 1 Gbps fibre will be used for backbone connections. Use of these cabling types will allow the network to support the estimated growth demands. All cabling runs will be doubled for redundancy in the event of a cable break.
The WAN connection will be made using Frame Relay on an E1 line. An ISDN line will be provided for backup. An E1 should provide for reasonable growth.
Microsegmentation using switches will be used to reduce collision domains.
Administration, Curriculum and Server LANs will be provided separated by a router. This will enable data to be filtered between segments, ARP broadcasts to be isolated, collisions to be isolated within segments and Layer 4 services filtered between segments.
IP and IPX protocols will be supported.
A separate border Firewall/Gateway router is shown on the layout diagrams to control external ingress and access, including internet access. This function may be incorporated into the site router.
Access will be prohibited from Curriculum LANs to Admin LAN, but allowed from Admin to Curriculum. Exceptions are that DNS (port 53) and mail (port 25) access will be allowed from Curriculum to Admin.
Hosts on Admin networks will have static IP addresses. Those on Curriculum will be assigned by DHCP.
Access Control Lists (ACLs) will be placed on the router ports to provide security. A UserID and password administration policy will be devised and adhered to.
Recognising that a school is a hostile environment the MDF and IDFs will be in locked rooms. Servers will be located in these rooms any equipment that needs to be provisioned away from the MDF or IDF will be contained in a locked cabinet.
IPX is to run on the Curriculum LAN segments. This will require a dedicated Novell Netware Servers. A single IPX encapsulation type will be used noting the defaults for Cisco and Novell are different. Two router interfaces cannot belong to the same logical network, be it IP or IPX.
Subinterfaces will be configured to accommodate different frame types, different IP subnets.
IP and IPX will be the only protocols allowed to traverse the WAN between the Action Zone sites.
See links to:
Network Physical Diagram IP Addressing Scheme IPX Addressing Scheme? Hardware Listing Cut Sheets Hoizontal/Vertical Router Configuration Security Policy including User ID and Password Policy Access Control Lists and Their Placement
The principle objective of this initial design was to produce a working network design that was future-proof in terms of network growth and requirements. This has been achieved but compromises have been made to keep costs down. For example it was felt that initial provision of an E3 connection for the WAN link would cater for extended growth. This was not done due to the cost involved, however it could be implemented at a later date.
If more IP addresses are required than can be provided under the current addressing scheme then an option is to use local NAT addressing schemes.
Subnets could be redefined using VLANs if growth demands. The switches are already in place to do this. There is a design overhead to define the user groups within each VLAN. They then require administration.
Wireless technology has not been used in this initial design as it was decided to hardwire the areas to be networked. This remains an option however for expanding the network into areas that are difficult to flood wire, or to areas where demand for network connectivity is only occasional.