Network Design Exercise
Design Project
Objective
The task is to develop a network for a multi site company.
This exercise attempts to give experience of a real world design that you may be asked to do in your future employment. As a result, only minimal guidance is given. You will need to fall back on all the experience that you have gained from the previous exercises. You will be assessed based on the decisions you made in each stage of the project.
Overview
The network to be designed connects computers across three sites. The main site, called "Base" has four floors connected via a fast backbone network. One external site is connected using FDDI, and the other uses a T3 link through the Internet (protected with a firewall).
The network should be analyzed and improvements recommended. An option to re- locate some of the servers can be considered. The backbone network upgrade from serial to partially meshed should also be evaluated.
Design Description
The servers and workstations have predefined physical locations.
- "Base" site:
- "HQ Floor" (HQ subnet)
∗ one switch
∗ one database server to hold product documentation (dbDOC)
∗ one database server to hold finances associated with product manufacturing and sales (dbFIN)
∗ one database server to hold administrative tasks, salaries, staffing schedules (dbHR)
∗ two "manager" workstations
∗ three "marketing" workstations
- "Development Floor" (DEV subnet)
∗ one switch
∗ one database server to hold product manufacturing inventory (dbINV)
∗ one remote shell server to handle design and development of products (srvDEV)
∗ one "manager" workstation
∗ five "developer" workstations
- "Manufacturing Floor" (MFG subnet)
∗ one switch
∗ one database server to interface with the manufacturing process (dbMFG)
∗ one "supervisor" workstation
- "Sales Floor" (SAL subnet)
∗ one switch
∗ one "front desk" workstation
∗ one "manager" workstation
∗ two "support" workstations
∗ two "sales" workstations
∗ two "marketing" workstations
∗ three "admin" workstations
- Serial Backbone network
∗ each floor subnet connects to a "floor backbone router" (BBHQ, BBDEV, BBMFG and BBSAL)
∗ one backbone router (BBFDDI) connects to an FDDI gateway
∗ one backbone router (BBFW) connects to the Internet via a gateway
• "External Near" site:
- one ethernet to FDDI gateway
- one switch
- one "front desk" workstation
- one "manager" workstation
- one "marketing" workstation
- total of "C" "support" workstations
- total of "D" "sales" workstations
- total of "E" "admin" workstations
• "External Far" site:
- one gateway connects to the Internet via a firewall
- one switch
- one "front desk" workstation
- one "manager" workstation
- three "marketing" workstations
- total of "F" "support" workstations
- total of "G" "sales" workstations
- total of "H" "admin" workstations
Where the number of workstations C, D, . . . , H are extracted from your student ID using the following rule:
- your student number is an eight digit number represented as ABCDEFGH (example 12345678)
- the values for C, D, E, F, G and H are the respective digits from your student ID (in the above example: C=3, D=4, . . . , and H=8)
- the network domain is defined by you student ID as: ABC.DE.FG.00 (example 123.45.67.00)
- All workstation are connected using 100baseT cables.
- The backbone network uses using 100baseT cables.
- The FDDI link is 100Mbps duplex.
- The Internet connection is a serial PPP-T3.
- The backbone servers, firewall and gateway within the "Base" site should use a static IP address. You have to allocate these addresses from the valid available address range.
Note:
The available version of the Riverbed Modeler is limited to simulate only the first 50,000,000 events. This limitation should be taken into account in planing the modeling and scenario generation.
During an eight hour working day, the staff access the following services:
• user "front desk":
- dbHR data base every hour for 5 minutes
• user "admin":
- dbHR data base once a day for 5 minutes
- inventory data base twice a day for 10 minutes
- documentation data base twice a day for 5 minutes
• user "developer":
- dbHR data base once a day for 5 minutes
- documentation data base once a day for 5 minutes in query mode
- documentation data base once a day for 10 minutes in entry mode
- remote shell development four times a day for 90 minutes
• user "support":
- dbHR data base once a day for 5 minutes
- documentation data every two hours for 2 minutes
• user "supervisor":
- dbHR data base once a day for 5 minutes
- inventory data base once a day for 10 minutes
- documentation data base once a day for 5 minutes
- manufacturing database every 30 minutes for 3 minutes
• user "sales":
- dbHR data base once a day for 5 minutes
- inventory data base once per hour for 5 minutes
- documentation data base once a day for 2 minutes
- dbFIN data base every hour for 2 minutes
• user "marketing":
- dbHR data base once a day for 5 minutes
- documentation data base three times a day for 15 minutes
• user "manager":
- dbHR data base once a day for 5 minutes
- inventory data base once a day for 10 minutes
- dbFIN data base twice a day for 10 minutes
The typical data packet sizes per transaction for the servers is:
• product documentation (dbDOC) average 350kB, with a standard deviation of 80kB
• finances associated with product manufacturing and sales (dbFIN) fixed 10kB
• administrative tasks, salaries, staffing schedules (dbHR) any size between 2kB and 20kB
• product manufacturing inventory (dbINV) average 100kB, with a standard deviation of 10kB
• interface with the manufacturing process (dbMFG) fixed size 100kB
• remote shell server to handle design and development of products (srvDEV) exponentially distributed short commands at 1kB at a mean 30 seconds followed by a fixed 200kB reply from the server
Tasks
• requirements analysis
create a detailed design requirement specification
• project planning evaluate required tasks
plan task execution sequence estimate individual task duration
• applications and profiles modeling
identify scenarios needed to complete the project
• create a hierarchical network in Riverbed Modeler
• simulate scenarios
• modify the network to validate potential improvements
• create a project report
Assessment
This is an individual project. You will be assessed as follows:
• Initial network planning (show your work)
• network topology
• network address spaces planning
• applications modeling methods (show your work)
• profiles modeling
• simulation and results
• report
For a successful assessment:
• ensure all included screen clips are readable
• every image has a reason to be included, and a description (not just a name)
• include screen clips showing each application and profile configuration detail
• include the DES Log, and a description of warnings and errors listed
• include traffic plots for individual applications/profiles that show how accurate the model is
Assessment Detail
• Analysis
- Map the project description into a design specification
- Estimate traffic between each backbone and associated section
- Estimate each backbone to associated section minimum link throughput
This is a sanity check to indicate if the link rate is too low. It is done manually. Traffic form all users and servers using the link (crossing the floor boundary) is considered.
One possibility is to calculate the worst case total traffic on a link then divide by the total transaction time.
∗ Example: BBMFG to MFG floor
traffic from user "SUPER" to dbHR, dbDOC, dbFIN and dbINV
(traffic to dbMFG is local)
throughput = (20K + (350K + 80K)+ 10K) x 8 / (20min) = 3.1kbps << 100Mbps
- Estimate each backbone to associated section maximum link response time
This is done manually. One possibility is to calculate the sum of the largest worst case event transaction size for each independent user on a link then divide by the link rate.
∗ Example: BBMFG to MFG floor
traffic from user "SUPER" to dbHR, dbDOC, dbFIN and dbINV (traffic to dbMFG is local)
servers on MFG floor:
dbMFG : only local traffic : 0 contribution
users on MFG floor: "SUPER"
service usage mode transaction size minimum response time
dbHR: (1 x 5min)/day (20kB)max 20kBx8/100Mbps=1.6msec
dbINV: (1 x 10min)/day (100kB + 10kB)max 110kBx8/100Mbps=8.8msec
dbDOC: (1 x 5min)/day (350kB + 80kB)max 430kBx8/100Mbps=34msec
dbMFG: only local traffic - 0 contribution -
Example table describing the users on the HQ floor service access per day:
|
user
|
count
|
dbHR
|
dbDOC
|
dbFIN
|
dbINV
|
srvDEV
|
dbMFG
|
|
MGR
|
2
|
2x(5/d)
|
|
2x(2x10/d)
|
2x(10/d)
|
|
|
|
MKT
|
2
|
2x(5/d)
|
2x(3x15/d)
|
|
|
|
|
Example table describing the users on the HQ floor transaction maximum size per day:
|
user
|
count
|
dbHR
|
dbDOC
|
dbFIN
|
dbINV
|
srvDEV
|
dbMFG
|
|
MGR
|
2
|
40kB
|
|
40kB
|
220kB
|
|
|
|
MKT
|
2
|
40kB
|
2580kB
|
|
|
|
|
Note: the above table does not include traffic from other floors to the servers located on the HQ floor. To estimate the minimum link throughput or maximum link response time, the complete tables are needed, including all users and servers in all locations.
• Model generation and verification
- for each application
∗ inter-command interval: which distribution ? why this distribution ?
distribution parameters ?
∗ duration:
which distribution ?
why this distribution ? distribution parameters ?
∗ implement (show readable screen shot of attributes setup)
∗ verify correct operation (graph screen shot showing correct start and duration)
• Address space planning
- for each router port in the HQ site allocate a valid IPv4 address and mask
• Scenario creation
- for each scenario:
∗ purpose ?
∗ key features - what is changed ?
∗ what is measured ?
∗ how to qualify results: targets, conditions ?
• Simulation
- for each scenario:
∗ results
∗ result interpretation
∗ are the targets met ?
∗ is the simulation matching estimates ?
• Modifications and improvements
- Modify and re-simulate the design
- Does the simulation show expected improvements
- is any link rate changed
(increased to meet requirements, decreased to decrease costs) ?
- should the backbone network be modified ?
Project Report Structure Suggestion
• Project Overview
- What is this project about ?
- What is the project goal ?
- Why this project ?
- What is achieved ?
• Design Decisions
- Design specification
- Functional block diagram
- Design architecture
- Verification plan
• Design Decisions
- Design specification
∗ what models are needed
∗ what is the functionality
- Functional block diagram
∗ identify blocks and data flow
∗ explain each block functionality
- Design architecture
∗ explain each block implementation plan
- Verification plan
∗ how to prove the unit is operating correctly
• Design Implementation
- Explain each block implementation specifics
- Include schematics
- May include simulation data or diagrams
• Design Issues
- Highlight core issues
- What was easy to implement ?
- What was difficult to implement ?
- What works as planed ?
- What does not work as planed ?
- What is not implemented ?
• Test Report
- Explain each test:
∗ what functionality is addressed ?
∗ what is the pass/fail criteria ?
∗ what is the test result (pass or fail) ?
∗ include relevant diagrams
• Conclusion
- Summary:
∗ what was the project goal ?
∗ what is achieved ?
∗ what worked or did not work ?
∗ what could be done to improve the design functionality ?
∗ what could be done to improve the design implementation ?