Lab Files For Opnet Modeler PDF
Lab Files For Opnet Modeler PDF
To do the labs in the Opnet Modeler Introductory Lab Manual requires some
additional files which can be downloaded from the following location, or can be
issued to you by your lab instructor during a lab session.
At present the lab files can be downloaded from the following location:
Extract the contents of this folder and you will find two folders:
Hotel_Net
project_environment
To get started with the labs in the Introductory Lab Manual proceed with the
following steps.
1. Start Opnet Modeler via VMware player in the usual way (see the Handout entitled:
Working with Opnet and VMware Player at GCU for instructions on how to do
this).
2. Once you have initialized Opnet Modeler you will see that the following three
folders will be added to the Desktop of the virtual machine:
op_models
op_admin
op_reports
Typically these folders are not found on the desktop for the application so we must
associate these folders with Opnet Modeler so that the application knows to look in
these folders. Before we can associate the folders with the application we first follow
these steps.
i) Copy the folders Hotel_net and project_environment you extracted from the .zip
file and put them into the newly created op_models folder on the virtual desktop. Note
that files must be dragged and dropped to and from VMware player to action a copy
and paste operation, cutting and pasting alone will not work.
Once you click Add Model Diretory the following screen will appear, locate the
op_models folder on your VMware desktop and select it.
File -> Manage Model Files -> Refresh Model Directories, to update the
applications environment variables.
When doing the introductory labs you may be required to open an existing project at
some point, i.e. from the files you downloaded.
The default view you will see on doing a File->Open may look like this:
(Please note that the below screenshot will be visible only when you will select the
op_models from desktop by clicking on the Look in)
Please note that this is the default view for opening files and projects in Opnet
Modeler 16.1, however the traditional File->Open view for Opnet Modeler can be
switched to by clicking on the Switch to file chooser organized by model directories
button:
To change to the traditional view which is what we will be using and referring to in
the lab material for this course click this button and the view will change to the
following screen view below.
When you change to this view you can now see that the Model directories now
associates the folder C:\Documents and Settings\Student\Desktop\op_models
with the application.
To change back to the previous view click on the Switch to general file chooser
button:
Important: When you create a new Project in Opnet Modeler it will automatically
create a folder with the name you give your project, make sure you select this folder
when saving your project try and keep all your projects organised in your
op_models directory. This will make things easier if you wish to save your work
between labs.
Remember: It is up to you to save your work between lab sessions. Save your lab
files to either a portable storage device, such as a USB memory stick or you can
save your lab files (i.e. the folders op_admin, op_models, op_reports) each week to
your student H: drive on the GCU network. You must drag and drop these folders
to/from the VMware player to copy them across from/to your chosen storage
location. If you do save your work each week in this way then any preferences you
alter in Opnet Modeler can be maintained and the above procedure can be reduced to
simply refreshing the model directories.
Opnet Modeler projects can become quite large and so each student should have an
increased quota for their H: drive disk space this should be around 500MB. If you
have any problems storing projects to your student H: drive/personal storage device
ask your lab instructor for assistance.
Lab Objectives:
In this lab you will implement switched local area networks and examine the
performance of different scenarios connecting LANs with switches and hubs.
Here you will set up LANs using two different switching devices: hubs and
switches. Remember that a hub forwards packets which arrive on any of its inputs to
all of its outputs. A switch on the other hand will forward incoming packets to one or
more outputs depending on the destination of packets. In the lab below you are going
to study how the throughput and collision of packets in a switched network are
affected by the configuration of the network and the type of switching devices used.
Overview:
One key issue with a switch is that it must cope with the finite bandwidth of its
outputs. If packets for a certain output arrive at the switch and their arrival rate is
greater than the capacity of the switch output then we have a problem of contention.
The switch will be forced to queue, or buffer, packets until the contention lessens. If
the contention lasts for too long, then the switch will run out of buffer space and will
have to discard packets. If packets are discarded too frequently, we end up with a
congested switch and this makes for an inefficient network.
1. Start Opnet Modeler Choose File, New, Project, then click OK.
3. In the Startup Wizard: Initial Topology dialogue box, ensure that Create
Empty Scenario is selected. Click Next, then choose Office from the Network
Scale list, -> Click Next, three times and then finally click Finish.
1. From the Project Editor choose Topology -> Rapid Configuration. Then from
the drop down menu select Star and click Next.
2. Click the Select Models button in the Rapid Configuration dialogue box. From
the Model List drop down menu choose ethernet and click OK.
d. Number = 16
e. X = 50, Y = 50
f. Radius = 42
Click OK once you have entered the values (note: the 10BaseT link represents
an Ethernet connection operating at 10Mbps).
4. Right-click on node_16, which is the hub -> Edit Attributes and change the
name attribute to Hub1 and click OK.
5. Save your project. From the Project Editor, File -> Save then you should already
have a folder listed <your_initials>_SwitchedLAN.project in the left hand pane (in
file chooser mode) of the Save As dialogue box, click on this folder and then keeping
the File name as <your_initials_SwitchedLAN> click Save.
Check the Apply Changes to Selected Objects check box - this an important feature
to use to prevent you configuring each node individually.
4. Click OK to close the attribute editing window(s) then Save your project changes.
Note that the parameters that have just been set are only available to a limited number of
models in Opnets standard model library referred to as the packet generating nodes.
These models usually have names that end in station or uni_source and contain the
Keith Sharp Glasgow Caledonian University - edited 2012
compound attribute called Traffic Generation Parameters which lets the modeller
generate streams of generic packets (i.e. not linked to any specific network
Now that we have configured the nodes to generate traffic within the LAN we now
need to choose the traffic-related statistics we wish to collect during the simulation.
1) Right click anywhere in the project workspace and select from the menu Choose
1
Collisions occur on the network when the Ethernet system resolves simultaneous attempts to
access the shared channel. On a busy Ethernet with fast machines you can expect to see many
c) Click Apply to keep this setting and then close the window. (Note we are NOT
running the simulation at this point merely configuring the parameters for simulation).
The network we just created utilizes only one hub to connect the 16 workstations.
We need to create another network that utilizes a switch and see how this will affect
the performance of the network. To do that we will create a duplicate of the current
network:
1) Select from the Scenarios menu select Duplicate Scenario and set the name of
it to HubAndSwitch then Click OK.
Note: It is important to note that when you are comparing network scenarios, to try and
change as few elements as possible between the scenarios. In general any simulation
study experiments should be controlled so that any change in the simulation output,
which is invoked by a change in the simulation model, should be easily accounted for. If
too many parameters are altered between each simulation, or each instance of a
simulation model, then it becomes more difficult to build confidence in what has caused
the change in the resultant output of the model.
2) Open the Object Palette by clicking on the icon in the tool bar on the Project
Editor or select from the Project Editor menu Topology->Open Object Palette
and locate the Ethernet in Shared Object Palettes.
Note: you can switch between icon view (below left) and tree view (below right)
by clicking the view toggle button in the top left hand corner of the object palette
4) Right click on the new hub, select Set Name, rename to Hub2.
5) Right click on the new switch, select Set Name, rename to Switch.
To remove a link,
select it and choose
Cut, from the Edit
menu (or simply hit the
Delete key). You can
select multiple links by
Shift+left clicking
successive links
and then you can
delete them all at
once.
The new HubandSwitch scenario only comprises of two new objects, an additional
hub and a switch. The network has the switch interconnecting two ethernet hubs
Keith Sharp Glasgow Caledonian University - edited 2012
each with 8 ethernet workstations attached.
To run the simulations for both scenarios together follow these steps:
2. Change the values under the Results column to <collect> (or <recollect>)
for both scenarios. Compare with the following screenshot:
3. Click OK to run the two simulations. Note that depending on the speed
of your processor, this may take a few minutes to complete.
[If you get error messages then check your model is configured correctly, as above,
or ask your lab instructor for assistance.]
To view the results (i.e. the statistics you selected for gathering during the
simulation earlier in PART 4)
1. From the DES menu in the Project Editor select Results->Compare Results.
Now Change the drop down menu in the lower-right part of the Compare
Results window from As Is to time_average.
Keeping the statistics Overlaid, select the Traffic Sent (packets/sec) statistic
from each Scenario (HubOnly and HubAndSwitch):
In the reference diagram below you will see that the traffic in both scenarios is
Keith Sharp Glasgow Caledonian University - edited 2012
almost identical on average in the preview panel.
2. To display the results as a graph you must click the Show button at the
bottom right of the Compare Results window.
6. Again deselect the previously selected statistics from the Compare Results
window and now select under the Object Statistics:
Question: Why does the Switch in the HubAndSwitch scenario not have
a Collision Count statistic associated with it?
[END OF LAB]
Lab Objectives:
In this lab you will build a larger network model in which you will learn more about
how Opnet Modeler represents computer networks. In addition you will revise some
basic networking concepts including IP addressing, subnetting, and the OSI model.
The lab demonstrates how Opnet Modeller performs subnetting. You will be configuring a
fairly complex LAN topology using different networking devices (including, workstations,
hubs, bridges, switches, routers, and network cloud models).
Reminder:
IP addresses (specifically IPv4) are traditionally given classes. There are five standard
classes named simply A,B,C,D and E which essentially are used to determine the
host part and network part of an IP address.
IP address representations:
For e.g. the above network address is a Class C address and so has a subnet mask of
24 bits and would be written as: 192.168.10.1/24, subnet mask /24 = 255.255.255.0
(The leading 24 binary digits in the mask = 1 for representing the network, the last
eight = 0 determining the host portion).
Class Leading Start End address Default Subnet Mask Total #of host
bits address addresses
24
A 0 0.0.0.0 127.255.255.255 255.0.0.0 (/8) 2 -2
16
B 10 128.0.0.0 191.255.255.255 255.255.0.0 (/16) 2 -2
8
C 110 192.0.0.0 223.255.255.255 255.255.255.0(/24) 2 -2
28
D 1110 224.0.0.0 239.255.255.255 224.0.0.0 (/4) 2 -2
28
E 1111 240.0.0.0 255.255.255.255 240.0.0.0 (/4) 2 -2
5. Start Opnet Modeler Choose File, New, Project, and then click OK.
View->Background->Set Properties
2. Now you will collect the components from the Object palette you will require to
build the LAN topology.
In the ComponentsOnly scenario workspace you will place and organise the
following objects in the project workspace by following these steps.
(Note: If you can not find any object then just type the name of that object in the
text box next to Search by name in object palette and press enter.)
1 x Sm_Application_Config object
1 x Sm_Profile_Config object
1 x Sm_Int_wkstn model (we will copy and paste more of these later)
6. Again in the Object Palette open the Cisco palette and pick up the
following items and place them into your project workspace:
4 x ethernet16_bridge bridges 8 x
ethernet16_hub hubs
1 x IP Attribute Config object
ether
4. From the 3Com palette take:
2 x ppp_server servers
1 x ip32_cloud Internet cloud model
3. Now rename the nodes you have collected to the names in figure 2.1. We need 23
workstation nodes using simply the names 1,2,3,,23 however we do not want to
rename these all individually 23 times. The simplest way to create consistently named
objects in Opnet is to name one first and then copy that instance multiple times. The
copy operation is smart enough to know to increment the number portion of the name.
Rename the Sm_Int_wkstn to simply the number 1, then copy this object by
selecting it and hit Ctrl+C to copy the node, and then press Ctrl+V, your pointer
should now change its appearance to a box shape by left clicking in the workspace
you will have dropped a copy of the Sm_Int_ wkstn model with the name 2 .
Repeat the Ctrl+V then Left-click operation another 21 times to obtain 23 copies of
the model. (Similarly if you named the model instance PC1, it would be pasted as
PC2, PC3, PC4 etc on subsequent paste operations.)
Figure 2.1
Your initial scenario should have the above components, named and numbered as
shown in figure 2.1
Duplicate the ComponentsOnly Scenario and call the new scenario NetworkModel
via the Project Editor Menu: Scenarios->Duplicate Scenario
Using the example in figure 2.2 as a guide place , connect and rename the
network nodes in the topology shown, the links to use are discussed below:
b) Use PPP_DS1 links for any links to the servers and the Internet cloud.
To change the colour of a link edit the color attribute note the colours are
stated in Hex format (if you are have used web design packages you will be
familiar with this) the colour of the text in this attribute is the same as the link.
Edit the color by clicking on the Value field and select your chosen colour.
To change the width of your link edit the thickness attribute by entering a
decimal value into the Value field for this attribute (measured in number of
pixels).
Your workstations may just be currently represented by a generic node icon or blue
circle. To make this more representative of a network object change the icon of all
the workstations by doing the following:
iii) Click in the Value field of the icon_name attribute, then making sure that
the symbolic icon palette is selected in the drop down box of the Icon Palette
find the wkstn_windows icon, click on it, and then click OK to apply the change
Keith Sharp Glasgow Caledonian University - edited 2012
to all the workstations. Use View->Layout->Scale Nodes Interactively to scale
the workstations to a smaller size (50%).
Now that you have built the basic topology and altered the appearance of your nodes
you are now ready to configure the network.
The first task we are going to do is configure IP addressing for our network objects,
namely:
b) Now all the workstations are selected, click on one and from the right-click
menu select Edit Attributes, make sure and check Apply Changes to Selected
Objects to change the parameters for all workstations at once:
IP->
IP Routing Parameters->
Loopback Interfaces->
Click on the Rows box in the bottom left corner and change the number 0 to 1,
by clicking inside the Rows box.
The loop back interface LB0 will be created for the router set the following
parameters for this interface by clicking on its associated fields in the Table:
Address: AutoAssigned
Subnet Mask: Class C (natural)
Click OK twice making sure you have checked the Apply to selected objects
check box.
Scenarios->Duplicate Scenario
Now assign IP addresses to all the (Layer 3) interfaces in the network of this
duplicate scenario, in the Project Editor select:
Now IP addresses (IPv4 addresses) will be assigned to all the connected (and
loop back) interfaces in the network model scenario.
When the Table view appears change the value of the Row box from 0 to 1.
You should now see a similar view:
Click on the Name field of Row 1 and the following choices will appear:
For the FTP and Telnet Server add the following services to the server:
File Transfer (Heavy), Telnet Session (Heavy)
Once you have set the services for the servers click OK to apply the changes.
You will come to learn later about the different mechanisms which can be used to
represent traffic in Opnet, but for now just follow the steps given here to define a ping
traffic demand, this will allow us to then analyse ping traffic behaviour through our
network model we have created.
Note: A traffic demand is used to represent traffic flows between two specific nodes.
We are now going to create the ping traffic demand for the AutoAssignIPv4 scenario:
a) From the Object Palette select from the internet_toolbox palette the
ip_ping_traffic object and then click on workstation 23 as the starting point, and then
select the FTP and Telnet Server as the traffic end.
The ping traffic of course has to traverse the entire network and
cross the Internet cloud to reach the FTP and Telnet Server. We
are going to analyse the path of the ping traffic demand in Part
10.
Set Ping Pattern: Record Route and press OK. Now we will be
able to see all the layer-3 devices the ECHO/ECHO REPLY packets
have passed
through when we come to run our simulation.
Alternatively use the keyboard shortcut Ctrl+R, to set the simulation parameters.
2. Set the Duration to 1 hour(s), leaving the other parameters as their defaults and
Click on Run.
In this section you will write down all the IP addresses assigned to each node and
interfaces in the AutoAssignIPv4 scenario - to obtain the IP addresses for your
network objects use the following steps:
Note: Fill in the table provided in this lab document, it has been prepared for this task
Where each row represents an interface, since routers can have multiple interfaces
there will be multiple rows for the maximum number of interfaces the device can
support, some of these interfaces may support different link technologies. Note that
only the connected interfaces will be assigned IP addresses by the Auto- Assign
operation performed earlier. Clicking the Value field () to the right of the Interface
Information Attribute will bring up these row values in a tabular form.
1) To make the collection of IP addresses a bit simpler we will use the Network
Browser to obtain a listing of the objects in the AutoAssignIPv4 scenario.
2) Collect the IP addresses for the workstations, servers and routers using the method as
stated in i) and ii) above but right click on the objects via the Network Browser and not the
workspace to make things simpler. That way you just work your way down the listed
objects instead of trying to locate them individually within your network model.
In Opnet Modeler the only IP addresses which appear on router interfaces are those
which are connected to some network. When a link starts/terminates at a router, Opnet
gets an unused interface from the router model and assigns it to the links
automatically. However it will only be possible if the router actually has free interfaces
which support the link technology you are trying to make connections with.
The way interfaces are assigned IP addresses depends on the router model. In the
picture below we take the Cisco 7505 router as an example specifically the model,
taken from Router 2 in our AutoAssignIPv4 scenario:
CS_7505_5s_e6_fe2_fr4__sl4_tr4
Remember that this naming convention is interpreted as Cisco Systems (CS), 5 slot
chassis, 6 Ethernet ports, 2 Fast Ethernet Ports, 4 Frame Relay ports, 4 Serial IP
connectors (SLIP) and 4 Token Ring ports.
However finding out how interfaces are assigned their interface numbers is not obvious,
but you can find this out by doing the following steps:
This is consistent with how the interfaces have been assigned with the 10BaseT links we
have used for Router2 in our network model. Specifically the first 5 Ethernet interfaces
IF0 IF4 are connected and assigned IP addresses i.e. Opnet selects which interfaces
are used when link connections are made between devices for convenience. Note that IP
addresses for the interfaces shown above may differ from your own model, as it is
dependent on which order you make your connections. Specifically which ever
connection of a specific type (e.g. Ethernet) was made first gets assigned to the lowest
interface number, IF0 then IF1,IF2 etc until all the interfaces of that type are used up.
After all the interfaces of a certain link technology have been used in a device, then no
more connections of that type can be made.
As you saw in your introductory labs, you can derive modified versions of device
models (Derived Models) from the standard library to increase or alter the number or
types of interfaces supported by a default model in the Object Palette.
Question 9.1: Why do we not look for IP addresses on hub, switch or bridge
interfaces?
To analyse the results of the ping traffic demand that you configured earlier in Part
7, follow these steps:
From the Project Editor menu select DES->Results->View Results then in the
DES Run (1) Tables tab expand the following hierarchy:
Note: Your results may differ from the sample ping results given above.
Question 10.1: Why is the IP address of Router 3 of the ICMP ECHO-Request and
ECHO-Reply paths not the same?
Question 10.2: Why do some devices appear on the ping trace and some do not and
is the forward path the same as the return path to and from the server, respectively.
In this part we are going to take a closer look at the network by capturing traffic using
a packet analyser node model. As an analogy you can think of this as a specially
configured type of workstation running protocol analysis software such as Wireshark
1
(formerly known as Ethereal).
PacketAnalyzer.
4. Obtain an ethernet_pkt_analyzer node from the Object Palette, type this into
the Search by name: field and press Find Next to locate it. Place an instance of the
node near to Hub 8 in the new scenario, rename the node Packet Analyzer.
6. Re-assign IP addresses to all devices in the new scenario via the Project
Editor menu: Protocols->IP->Addressing->Auto-Assign IPv4 Addresses
5.
5. From the Object Palette get a Profile Config object (you can either search
for this or locate it quickly under the internet_toolbox Shared Object Palette.) and
place it somewhere in the PacketAnalyzer scenario.
6. Rename the Profile Config object to TelnetProfile (via Right-click and Set
Name).
Profile Configuration, and expand the attribute and left-click in the rows Value field
and select 1 to add a new row, (i.e. row 0).
The reason we are creating this traffic profile is that we are simply going to apply it to
one of the hosts attached to the hub which we are going to monitor with the Packet
Analyzer node we created earlier.
Applications and Traffic profiles in Opnet Modeler will be covered in detail in later
labs, just now we quickly configure a profile so we can apply it to one of our
workstations to generate traffic which our Packet Analyzer node can sniff.
Remembering our Hub operational logic, we know that the traffic entering the hubs
inputs will be transmitted out each of its other interfaces (i.e. excluding the source
interface of the incoming traffic). By connecting the Packet Analyzer to a hub we
automatically can see any traffic leaving the connected hosts (you have to
configure a node to generate traffic, device models often by default do not generate
traffic you must alter their parameters and often use other objects from the library to
assist in doing this.)
d) Right-click on host 13 and select Edit Attributes and under the following
hierarchy:
Applications->
Application: Supported Profiles->
Keith Sharp Glasgow Caledonian University - edited 2012
Left-Click in the Value field and select Edit
Click on the Profile Name column and select the Telnet Profile which you created
previously. Leave the other fields as their default values.
Click OK and then click OK on the Attributes panel for host 13.
6. The next step we need to configure the filtering rules for the
packet analyzer/sniffer:
a) Right Click on your Packet Analyzer node and Edit Attributes, and then find
the attribute called Packet Analyzer Configuration.
b) Then once you have added the new row, you then must expand the Filtering
Information Attribute then adjust the following settings as follows:
Once you have updated the Source IP Address and Capture Filename fields as
above then click OK to confirm the changes to Packet Analyzer node.
These settings will filter only the traffic coming into the hub from workstation 13,
and this traffic will be exported into an external file.
7. Run the Simulation keeping the simulation parameters as they are go to the menu
on the Project Editor select DES->Configure/Run Discrete Event Simulation.
8.
5. Locate the Packet Analyzer capture file via the File->Open on the main Menu
once Excel has opened.
Step 1: Select the option: Original Data Type: Delimited, and then Click Next.
e) You can now analyze the data from the formatted text file:
Question 11.1: How could the server responses be collected using the procedures you
have learnt in this lab?
Draw the layer-3 networks as a solid line, labelling it with the correct network
address and subnet mask.
Question 4: How many different networks do all the hosts belong to?
Question 5: From the Building Network Models lab duplicate the PacketAnalyzer
scenario and call it PacketAnalyzer2.
Run the simulation for the PacketAnalyzer2 scenario via the Project Editor:
DES->Configure/Run Discrete Event Simulation and then click the Run button.
Import the capture files from the op_models folder into Excel and take a look at the
data. Why do you think there are less packets in the communication from the Telnet
Server to host 13 than from host 13 to the server? (only a general answer is expected
here)
Lab Objectives:
In this lab you will begin to interact with routing protocols which are provided as part of the
Standard Model library with Opnet Modeler. Specifically in this lab you will configure and
analyze the behaviour of the RIP (Routing Information Protocol) routing protocol model.
Overview:
So far you have configured IP addresses for some network devices but not looked closely at
how Opnet Modeler allows for network communications when you build a network model.
There are different issues when establishing connectivity at different network layers, the
focus of this lab is on layer 3 connectivity, here we shall begin to look at routing protocols
and the IP model built into Opnet Modeler (and other Opnet solutions). The IP model is
available as part of the in-built functionality of the Standard Model Library and it an integral
component to many network objects which you should be aware of.
In terms of routing protocols we begin with RIP, not just because it is a simple routing
protocol, but because unless you manually alter parameters within you network
models/simulation it is automatically used as a default. Essentially all interfaces have their
routing protocol set to RIP unless you configure them otherwise. Therefore it is important to
know how this model works and whether by using it in your simulation it is cause for any
potential problems within the scenario you are investigating.
Routing algorithms are required to generate routing tables to get a unified picture of a
network between routing devices. The essential task of a router is to discover the lowest-cost
path between any two nodes (where the cost of a path is equivalent to the sum of all the
individual costs of all the edges making up the path). Routing protocols are what routers and
some other network devices use to achieve this task in a distributed manner (i.e. all the
routers work together to solve the problem). Routing protocols must be able to dynamically
find the lowest-cost path in the presence of link and node failures and also changing edge
costs.
N.B. Please read the RIP handouts to get a better understanding of the contents of this
lab and answer the lab questions.
9. Start Opnet Modeler in the usual way (Remember to add the op_models directory to
associate it with the software before beginning the lab that way the models you
then make and save can be saved here and later copied from the VMware desktop to
place in your H: drive or USB storage device).
10. Choose: File -> New from the main menu, select Project and click OK.
11. Name the project: <your initials>_RIP, and name the scenario: NO_failure
then click OK
12. In the Startup Wizard, select create emtpy scenario click Next, then
select Campus click Next three times and then click Finish.
Note that the Object palette opens when you create a new project. At present it should be
visible, if not open it via the Project Editor menu via Topology->Open Object Palette or
click the Palette icon on the tool bar.
Using the internet_toolbox palette follows these steps:
1
a) 1 x ethernet4_slip8_gtwy
2
router b) 2 x 100BaseT_LAN
objects.
8. Use bidirectional 100BaseT links to connect the object you added to your
project scenario. Rename and position the objects as shown below.
1
In the recent past routers were often referred to as gateways. This router model supports
connections for Ethernet and Serial Line Internet Protocol (SLIP) links. SLIP is a networking
standard, commonly used for point-to-point serial connections running TCP/IP. It is not an
Internet standard but is defined in RFC 1055.
Rename the LAN objects Net10 and Net1, and the rename the gateway to Router1.
The ethernet4_slip8_gtwy node model represents an IP-based router which supports four Ethernet
hub interfaces an eight serial line interfaces. IP packets arriving on any interface are routed to the
appropriate output interface based on their destination IP address. For this specific model the
Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) protocol may be used to
dynamically and automatically create the routers routing tables and select routes appropriately and
adaptively.
4. Click OK and then save your project (make sure you save it into your op_models
folder on the desktop of your VMware virtual machine).
We wish to analyze the routing protocol so we must first explicitly set parameters within our
models to allow us to collect and then view information from our network scenario.
1. Right-click on Router1 -> Edit Attributes: then expand the following Attribute:
a) Status: Enabled
Here we are telling Opnet Modeler essentially to save a copy of the routing table for us at the
end of the simulation specific to the RIP routing process.
a) Select all the components in the workspace at once by left clicking and drag your
mouse pointer over all the network nodes and links. Or you can individually select
Keith Sharp Glasgow Caledonian University - edited 2012
multiple objects by clicking on them one-by-one and holding down the Shift key.
b) Once you have selected all 5 objects (two LAN objects, one router, and two links),
Press Ctrl+C, to copy the selected objects and then press Ctrl+V to paste a copy of
the network segment you just created.
c. Repeat Step 2 three times to make three new copies of the objects and arrange them
as depicted in the following diagram note how the names of the objects remain the
same and the numbers increment.
d. So now you should have 4 routers named Router1, Router2, Router3, Router4, and
connected to each of these you have Net1 + Net10, Net2 + Net11, Net3+Net12, Net4
3
+ Net13, respectively. Connect them together as below using PPP_DS3 links (also
found in the internet_toolbox palette). Change the colour of the links between the
routers to green to distinguish them from the 100BaseT links.
To analyze the performance of the RIP protocol, we will collect the following statistics:
7) Right click anywhere in the project workspace (i.e. not on top of an object) and select
5
b) Global Statistics->RIP->Traffic Received (bits/sec)
6
c) Node Statistics -> Route Table -> Total Number of Updates
You may have noticed that there is a difference between setting parameters with respect to
your network model, and setting parameters for the simulation you are running with that
network model. There are often parameters which cross over from either being part of the
model or part of the simulation. The effect of setting a simulation parameter which influences
model behaviour is similar to globally setting parameters for your model. Experience using
Modeler will allow you to better judge whether you should set certain parameters manually
for network model objects or whether you can do it more efficiently via Simulation settings.
1. Usually to configure simulation parameters you would follow the menu to the
Note that you can also press Ctrl+R to bring up this window or you can click its
8.
Total number of RIP update traffic (in bits) sent per second by all the IP interfaces using
RIP as their protocol in this network.
9.
Total number of times the routing table at this node gets updated (e.g., due to
new route addition, existing route deletion, and/or next hop update).
Here Auto Addressed/Export means that all the IP interfaces are assigned IP addresses
automatically during the simulation. The class of address (e.g. A, B or C), is determined
based on the number of hosts in the designed network, i.e. Opnet calculates this based on
the number of nodes in your network. However in addition to assigning IP addresses the
simulation process will also export each address assigned into a file: by default this file is
called <network_name>ip_addresses.gdf and is saved in the primary model directory (
typically op_models).
In the network model we have made so far the routes which we have in our scenario will
build their routing tables, and then they will not need to update them further because the
state of the network is not going to change over the course of the simulation. In this
duplicate scenario we alter our existing network model to include simulated link failures so
we can compare the behaviour of the routers in both cases.
- Select Duplicate Scenario from the Scenarios menu and name it Failure and click
OK.
- Open the Object Palette by clicking on the painters palette icon on the
Project Editors toolbar. Find the utilities Shared Object Palette.
- Right-click on the newly added Failure object and select Edit Attributes:
Essentially these settings will cause the link between Router1 and Router2 to fail
200 seconds into the simulation. (Tip: Colour the link between Router1 and
Question 7.1 - What is displayed in the Value field of the Name attribute
when you click on it?
Now we wish to run the simulation for both scenarios, to do this follows these steps:
1) Go to the Scenarios menu on the Project Editor, and select Manage Scenarios.
2) Change the values under the Results column to <collect> (or <re_collect>) for both
scenarios.
3) Click OK to run the two scenarios. Depending on the speed of your PCs processor
and memory specification, this may take several seconds to complete.
4) After each of the simulation runs completes (they are run in the scenario order
indicated by the numbers on the left hand side in the Manage Scenarios Dialogue box
you can change the order by clicking in the # field) - click Close and then save your
project, by saving you eliminate the need to re-run the simulation to view the
simulation results/output.
1) From the Project Editor menu select DES->Results->Compare Results from the
Results menu.
2) Change the drop down menu in the Results Browser to Stacked Statistics as shown in
the following figure:
4) You should get two graphs, one for each scenario. Right-click on each graph
and select Draw Style -> Bar Chart.
5) The resultant graphs should look like the following note that you can manipulate
the way you view these graphs in many ways, for e.g. you can zoom in on a specific
area by clicking and dragging over a region of interest.
6) Right click on the graph for the Failure scenario and select the following from
the pop up menu which appears: Export Graph Data to Spread Sheet
This will open a spreadsheet consisting of the data points which make up the graphed
representation (created via the Results Browser) in Microsoft Excel 2007 which is
installed in the VMware image. The spreadsheet will be named <your initials>_RIP-
Failure-DES-1.txt
Question 9.1.3 Look at the left most column of the data, at what frequency
is data collected? How many times within the simulation is data collected?
Before checking the contents of the routing tables we will need to know which IP addresses
have been assigned to all the interfaces in the current network. Remember that we set these
IP addresses to be assigned automatically during simulation (it saves us having to do it
manually
however there will be occasions where you would have to model exact IP addresses if
you are modelling (aspects of) a real-world network). We set the Global simulation
attribute IP Interface Addressing Mode previously in Step 6.3b) to export this
information to a file.
1. From the File menu choose Manage Model Files->Refresh Model Directories. This
makes Opnet Modeler to search the model directories and update its list of files
(depending on what version of Modeler you are using this step may not be necessary).
2. From the Files of type: menu choose Open, and from the drop down menu select
This data is fairly straight forward to interpret, for e.g. Interface 0 = IF0 and it
connects to the LAN called Net1 and has IP address 192.0.0.1/24 therefore the
network representing the LAN Net1 is 192.0.0.0/24.
4. Print out the layout of the network you implemented in this lab. On this layout, use
the information you obtained from the .gdf file and write down the IP addresses
associated with the topology. Include the network addresses and the router interface
addresses. [Note: To associate your VMware PC with a lab printer you will have to
run the VMWARE-Print V3.exe script on the virtual machines desktop and then
choose the correct printer from the printer menus; you will need to also enter your
GCU network user id and password during the script.] NB- If you are unable to do
1) To check the content of the routing tables in Router1 for both scenarios:
You need to go into the NO_Failure and Failure scenarios separately. You can do
this via the Project Editors Scenario menu and select Switch to Scenario.
Then right click on the Router of interest, in this case Router 1 in each scenario
and choose View Results from the pop up menu:
From the Result Browser select the DES Run (1) Tables tab.
Click on the Show button to bring up the routing table in its own window.
The following figures show the two routing tables for each of the scenarios; note that
there may be differences to your own depending on how you constructed your model.
1. From the Project Editor select DES->Results->Compare Results and for the No_Failure
and Failure scenarios compare the results by selecting the Statistics as Stacked in the
Results Browser and select the Global statistic RIP - Traffic Sent (bits/sec) for each
scenario.
2. Click Show and remember to change the Draw Style of each graph by right
clicking on each graph and selecting Bar Chart.
Question 9.4.1 Why does the RIP traffic appear regulated overall? (Hint: Think about
how routing protocols operate).
Question 9.4.2 From these graphs and the graph you generated in Part 9.1 what can
you deduce about how Opnet classifies RIP traffic vs RIP updates?
1. Duplicate the Failure scenario and name the new scenario Recovery.
2. In this new scenario have the link between Router1 and Router2 recover after 400
seconds. To do this alter the parameters of the existing Failure-Recovery object as
depicted below:
4. Also check the contents of Router1s routing table at the end of the simulation, and
compare this table with the corresponding routing tables generated in the NO_Failure
and Failure scenarios. What has happened to the routing table?
[END OF LAB]
Lab Objectives:
In this lab you will take a look at how distributions and measurements are important with
respect to accurately portraying network behaviour. We will analyse some simple
measurements taken from a real networking scenario and see how they can be adopted into
modelling objects in Opnet Modeler. Later in Lab 4.2 we will also look at how traffic can
be characterised using distribution functions built into Opnet Modeler.
Overview:
When you use a tool such as Opnet Modeler and interact with a large library of modelling
objects, often these object have pre-defined or suggested default parameters associated with
them. In the real-world every network is configured and behaves differently, and to
accurately replicate them via simulation models often requires altering default simulation
parameters to something closer to the real-world networks behaviour.
Ulitmately to discover how a real network behaves will involve some kind of network
measurement to generate statistical data of network performance. Network measurement and
analysis tools are often used by network simulation analysts to better construct more
accurate representations of real networks. Parameters used in network models are often
altered after analyzing aspects of network behaviour rather than leaving them to their default
values (In Opnet Modeler default values can also be Not used meaning turned off).
Network simulation software tools often use distributions to generate inter-arrival times for
application packets, determine packet sizes, specify application repetition patterns, and
generate protocol parameters and delays/latencies on devices. There are predefined
distribution models available within Opnet Modeler however it is possible for users to
define custom distributions to suit their modelling/simulation requirements.
For this lab we begin with a real scenario -a real network where some analysis has already
taken place. We use the context of part of Glasgow Caledonian Universitys network to
provide a familiar framework. In this lab you will use previously collected data and
manipulate it to derive values for parameters of a simple network model of the real scenario
in Opnet Modeler
In this experiment we are trying to obtain parameters to make an Opnet Model more accurate
with respect to the real network we are basing our model upon.
In our scenario depicted in figure 1.0 we are attempting to find a suitable value to
describe the delay across the GCU Network from PCs on Level 4 of the Saltire Centre to
th
the opnetserver which is located on the 6 floor of the George Moore Building (GMB).
Often when measuring values from any system we require more information than simply
the direct measurements we are interested in, it all depends on what methods we are using
to obtain our desired measurement data.
In networking there exists a simple method which can be used to calculate one way packet
delay across a network by analyzing ICMP ping traffic. This is discussed in the next
section in 2.2
Later we are going to represent the scenario depicted in figure 1.0 as an Opnet Model and to
emulate the GCU Network portion of the topology (which essentially is unknown) we are
going to use a network cloud object specifically an IP cloud model:
Opnet Modeler provides network cloud models to allow the user to abstract parts of a
network topology where details are unknown or not relevant to their studies.
IP cloud models are used in Opnet Modeler when you do not know the details of a
network backbone at the WAN level, or if you are more interested in modelling LAN
infrastructures and you do not need to model the backbone network in precise detail.
Basically because you do not know the details of the backbone, a cloud node gives you
a simpler model without losing any detail. Using cloud models to represent backbones is
sufficient for many types of network simulation study.
IP cloud models have two main parameters which can be set to better emulate
a backbone network with more accuracy:
13. Packet (or Cell) Latency specifies the one-way delay that each packet
experiences while traversing the network. You can set this parameter by right-clicking on
an IP cloud model object in Opnet Modeler and under Edit Attributes locate the Packet
Latency (secs) attribute.
14. Packet (or Cell) Discard Ratio - specifies the ratio of packets dropped to
packets submitted to the network backbone. You can set this value based on your
network service providers statistics or its traffic-contract guarantees (when considering
WAN infrastructures).
In this lab we are going to concentrate on Packet Latency as there is a simple test you can
run on a network to determine this setting (which we will then use for our cloud model). In
First, you need to use a simply trace route utility such as Microsofts tracert to report the
number of hops that a packet traverses from one end of the cloud to the other. Then measure
the response time for a typical ping packet sent across the network. (Keep in mind that the
ping response time includes transmission delays at each hop that is each hop must retransmit
the ICMP messages) After you have these two values, you can use the following equation to
compute the actual network latency:
Latency = (Ping Response Time (Hop Count * (Ping Packet Size/Data Rate))) / 2
Note the division of two is not strictly accurate for representing the one way delay. If we
ignore the division by two the formula represents the there and back again time of the ICMP
echo request and echo reply packets respectively. It is suitable for this experiment but in
general we know that routes between two network nodes are not necessarily symmetric, in
time or in terms of the actual path packets taken across IP networks.
Looking at the scenario it is clear that there are two LANs (the subnet on the fourth floor of
th
the Saltire Centre and a subnet on the 6 floor of the George Moore Building) which we know
about the network in between we have little information about at this point. The first step is
th
to calculate the number of hops between these two LANs this is done from the PC on the 4
floor of the Saltire Centre library.
th 1
a) Using a Windows XP PC on the 4 floor of the Saltire Centre, a tracert command was
issued from a DOS command prompt thus:
C:\>tracert 10.15.1.11
1
tracert is a path discovery utility which is part of the Windows TCP/IP protocol suite.
From the tracert results we know that the PC and the server are two hops away (i.e.
separated by two networks). We can use this information later in the formula which
we introduced in section 2.2.
9. From your current lab workstation issue a tracert to 10.15.1.11 does the
tracert encounter any hops? If so how many?
Whenever you measure something you need to use a suitable scale to obtain an accurate
measurement. The use and derivation of accurate parameters is necessary in simulation
to build models which can replicate real world behaviour with suitable precision.
4 From the Start Menu of your Windows lab PC (i.e. the physical PC not a
VMware PC), Select Run and type in the command cmd and click OK.
C:\>
Note that with respect to the timing information we have the response time for each of the four
echo-request packets sent and responded to. However the information is given in a crude
estimate of milliseconds, which is not sufficiently fine a scale to use to measure the packet
delay across the GCU network cloud.
This limitation in this instance means that we must try and find either: another method of
measurement, or a similar utility which measures at a higher resolution/finer scale.
2.4.2 hrping
Since the timing information with repect to Microsofts implementation of ping is in just
multiples of milliseconds - providing little detail for accurate measurement we must use
another tool or approach.
For this experiment we have used a more accurate version of the ping utility called hrping,
which is available via the following URL for download:
http://www.cfos.de/ping/ping.htm
The resolution of the hrping timing information associated with the ICMP packets is at a finer
level of precision, specifically fractions of milliseconds.
Note: You will be able to download, install and run this utility inside a Virtual Machine in
the labs but you will not be able to do it from the physical machine as you do not have
administrative rights to do this on student lab PCs which is why some of the tasks have
been completed for you.
When using this version of ping we have more flexibility in terms of the options available in
the hrping utility in relation to the ping utility see the listings below.
C:\>ping -?
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]] [-w
timeout] target_name
Options:
-t Ping the specified host until stopped.
To see statistics and continue - type Control-Break;
To stop - type Control-C.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don't Fragment flag in packet.
-i TTL Time To Live.
-v TOS Type Of Service.
-r count Record route for count hops.
-s count Timestamp for count hops.
-j host-list Loose source route along host-list.
-k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.
hrping options:
C:\Program Files\hrping-v235>hrping -?
This is hrPING v2.35 by cFos Software GmbH -- http://www.cfos.de
options:
-lic Show public license and warranty
-t Ping the specified host until stopped
-n count Number of echo requests to send (default 4)
-E file Stop pinging when <file> exists
-l size Send buffer size (ICMP payload size, default 64)
-L size Total IP datagram size (ICMP payload size + 28)
-f Set Don't Fragment bit in IP header
-i TTL Time To Live (default 255 for ping, 30 for traceroute)
-v TOS Type Of Service (default 0)
-w timeout Timeout in millisecs to wait for each reply (default 2000)
-s time Interval in millisecs between packets (default 500 ms)
-r [count] Be a traceroute (do <count> pings each hop, default 3)
-a [hop] Resolve addresses to names for traceroute (start at <hop>)
-o Don't do overlapped send/receive
-tsc Force RDTSC usage
-W "warm up" with one uncounted echo request at beginning
-F file Log output into <file> as well
-T Print timestamp in front of each line
-I id Set ICMP id field to <id>
-q Don't print a line per ping
-A Abort after the first echo reply (-AA => or error)
-H use IP_HDR_INCL socket option (experimental)
-S print a summary on each receive
5. Compare the results of the ping you issued via your lab PC with hrping. Download
and install the hrping utility in your VMware virtual machine to do this (where you
typically carry out your Opnet based labs).
Question 2.4.2a) what do you notice about the response times, to what degree of
accuracy are they measured?
Question 2.4.2b) what option do you use in hrping to generate a specific number of ping
packets?
You may have noticed that the default number of ICMP messages sent by both the ping and
hrping utilities is only four packets. We are trying to gauge what the response time is for the
th
round trip journey from a PC on Level 4 of the Saltire building to the opnetserver on the 6
floor of GMB and so we will need to use a suitable number of samples to determine a
suitably accurate value for this.
Warning! It should be noted that depending at what time of day you decide to take your
measurements, behaviour across a network such as the one in our scenario may be
affected. If measurements are taken at a particularly busy time for example during lunch
time when many students access email and use the web - then delays/response times
across the network will obviously be affected by this. It is important to be aware of these
factors, but for our experiment we can safely ignore it, as this detail is not strictly
important to the purpose of this lab. However in a simulation study factors such as this
should be considered.
To keep things simple we shall consider 100 samples or a 100 ICMP echo
request/reply packets.
100 pings were issued from the PC to the opnetserver using the hrping utility: Below
is the output generated by the hrping utility for 100 pings:
[end of output]
We now have enough data to let us begin to derive a suitable parameter for use with
our cloud model in our Opnet model (which we will construct later on).
The data we collected is not currently in a usable form, we are interested in the response time
data only. The response times have been extracted for you and are available to download
from Blackboard via a text file which can be located under: Course Documents -> Opnet
Modeler Labs -> Week 6 -> Labs -> hrping-output.txt
1) Download the file from Blackboard and place it inside your VMware virtual machine.
Strictly speaking the set of values in hrping-output.txt file are not response times, they
represent the round trip time (RTT) of the ICMP ping packets as was discussed previously
in section 2.2
To begin with you are going to import the data from the hrping-output.txt file into Microsoft
Excel to further analyse the data:
2) Open the hrping-output.txt file from inside your Opnet VMware environment.
3) Select all the numerical data from the text file and copy it (select the column
of figures in the text file and press Ctrl + C).
4) Go into the Blank workbook which opened automatically when your started Excel and
click on the upper leftmost cell i.e. Cell A1, and then paste the numbers you have
just copied into the workbook i.e. press Ctrl + V or select Edit->Paste from the
main application menu.
5) Check that you have successfully pasted all the numbers you should have figures
present in cell A1 to cell A100 in the spreadsheet.
6) Save the workbook as icmp_response_times via File->Save the resultant file should
have the extension .xls
a) Select all cells, A1 to A100, do this by left clicking on cell A1 and then hold down the
Shift key and click on cell A100.
d) Your resultant graph by default should look something like the following:
2
1.8
1.6
1.4
1.2
1 Series1
0.8
0.6
0.4
0.2
0
1 13 25 37 49 61 73 85 97
Along the x-axis the sample numbers 1-100 are stated and on the y-axis we have the
ping response times in milliseconds. Note you can manipulate the graphs appearance
after you have made it using the wizard to suit your visual requirements.
8) To determine the average response time from the data, select cell 101 and type the
word Average into it, then select cell 102 directly below it and then click on the
insert function button at the top of the workbook under the main Excel tool bar:
11) Now when you click on cell 102 you will see its associated formula in the insert
function toolbar it should read =AVERAGE(A1:A100) and the average
value will appear in cell 102 it should read exactly 0.59054
It is important to note that despite the data having a few anomalous spikes within the
sample of measurements the average response time overall corresponds with the majority
of all the sample points in the graph. (Exercise: Rechart the graph data using the Excel
Chart Wizard plotting all the data points to verify this yourself.)
The reason that these spikes do not impact greatly our average value is because we took
a sufficiently large sample of measurements (i.e. 100 in total). If we only took a few
sample measurements we could have derived a different and perhaps less accurate value
for the average response time.
An example of this potential problem is demonstrated with a smaller data series in the
spreadsheet entitled anomaly.xls which is available on Blackboard alongside the lab
content for Week 6.
Looking at this example it is evident that using a suitable sample size is also an
important aspect when determining measurements/parameters for network simulation
models.
Now that we have a representative value for the Ping Response Time and we know the
Hop Count to be equal to two, we can revisit our formula.
Latency = (Ping Response Time (Hop Count * (Ping Packet Size/Data Rate))) / 2
So we just need to plug in the numbers to determine the Packet Latency parameter for
our cloud model.
(Average) Ping Response Time = 0.59054 ms (from above procedure)
Ping Packet Size = 64+28 = 92 bytes or 92*8 = 736 bits (default for hrping)
Note that we have yet to decide on a value for the data rate of the network backbone. Data
rate can be a difficult thing to measure without access to the network infrastructure. For
the purposes of this experiment we are going to assume that we have FastEthernet speeds
of
Keith Sharp Glasgow Caledonian University - edited 2012
100Mbps. However the likelihood is that the backbone of the GCU campus network is much
faster.
1) Start up Opnet Modeler in the usual way. Make a new project and call it
GCUnetwork, name the scenario PacketLatency.
2) Create an empty scenario selecting a Campus scale network with a 1km square size.
3) Using the following objects from the internet_toolbox palette and create the
topology in the following diagram.
2 x ethernet16_switch
2 x ethernet4_slip8_gtwy routers
1 x ethernet_wkstn and 1 x ethernet_server
1 x Application Config object and 1 x Profile Config object
Use PPP_DS1 links between the cloud and the routers, and use 100BaseT for the
1) Update the IP clouds Packet Latency parameter using the value we calculated
earlier. Right click on the IP cloud and select Edit Attributes, alter the Packet Latency
(secs) parameter and enter the value 0.3ms. Specifically set the following values.
Distribution Name: constant
Click OK
First we specify to our model which applications we wish to be available for use within our
network model. To make the network model do something we must simulate some traffic across
it. We are going to simulate http traffic crossing the network from the PC to the server.
Secondly we specify the behaviour of any applications we have chosen by giving them
an associated profile of behaviour.
2) Right click on the Profile Config/Definition Object. Expand the Attribute Profile
Configuration and add 1 row.
Expand the newly created row 0 under the Application hierarchy and click on the
Value of the Name attribute and select Web Traffic from the drop down menu.
Keith Sharp Glasgow Caledonian University - edited 2012
Leave the other parameters to default and click OK.
1) Right-click on the Server in the scenario and select Edit Attributes, expand the
Applications Attribute and click on the Value field of the Application: Supported Services
Attribute field, which should currently read None.
2) Select Edit and Click in the Rows box in the bottom left hand corner and add 1 row.
3) Click in the Name field of the row, and select Web Traffic from the drop down
note: this only appears since we defined it earlier in our scenario in 4.2.1 then click OK
twice.
4.4 Configure the PC to generate web traffic across the link to the server
1) Right-click on the PC in the scenario and select Edit Attributes, expand the
Applications attribute hierarchy and then expand the Application: Supported Profiles attribute.
4) Click on the Value field of the Profile Name attribute and select Web Profile from
the drop down - note: this only appears since we defined it earlier in our scenario in 4.2.2
then click OK twice.
1) Right click on the PacketLatency scenario work space and select Choose Individual
DES Statistics.
2) Expand the Global Statistics hierarchy and select under the HTTP statistics Page
Response Time (seconds), Click OK after you have ticked the associated checkbox.
2) Set the duration of the simulation to be 1 hour, leave the other parameters to their
defaults.
In the next part we are going to duplicate the scenario we have just made but remove the
delay which we explicitly set in the IP cloud from our measurements.
1) Duplicate the PacketLatency scenario and call the new scenario NoPacketLatency.
2) Remove the Packet Latency setting from the IP cloud in the new
NoPacketLatency scenario Right click on the IP cloud and reset the attribute Packet
Latency (secs) to the predefined value of None.
2) Under the Results column fields select collect or recollect for each scenario and
click OK to run the simulation for each scenario one after the other:
To compare the results between scenarios you do this using the Project Editor via the
DES->Results-> Compare Results menu item.
Making sure you select the Results for both scenarios, view the Global HTTP statistics for
Page Response Times (seconds) over the simulated hour of Heavy Browsing from the PC to
the server. Change the Presentation from As Is to time_average then click Show to display
the graph independently from the Results Browser.
Notice the response time is greater in the PacketLatency scenario. Bearing in mind
this is for a single PC. This difference is noticeable, but it might not be significant to
the simulation study. Whenever you do a simulation study you need to know whether
certain aspects of network behaviour are relevant or could have an impact on your
investigation.
Exercise:
As an exercise try duplicating the PacketLatency and NoPacketLatency
scenarios and increasing the number of hosts accessing the web server. You can
either do this by adding workstations to the switch or by using LAN objects if you
want to use larger numbers of workstations at any one time.
Does the delay setting we applied to our cloud object become more significant as the
number of workstations increase?
[END OF LAB]