Lab Files For Opnet Modeler

OPNET Modeller lab booklet
Keith Sharp Glasgow Caledonian University - edited 2012
Lab Files for Opnet Modeler Introductory Lab Manual
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:
Blackboard->Course Documents->Opnet Labs-> Week 1->Labs
From here download the zip file intro_modeler_labs.zip
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.
ii) Go to the main console screen for Opnet Modeler

Select File->Manage Model Files->Add Model Directory
Once you click Add Model Diretory the following screen will appear, locate the
op_models folder on your VMware desktop and select it.
Click OK to add the directory, the following Confirm Model Directory screen will
appear, select the check box named Include all sub-directories only and Click OK
And, finally, from the main menu select:

File -> Manage Model Files -> Refresh Model Directories, to update the
applications environment variables.
3. BEFORE STARTING THE LABS PLEASE NOTE:

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:
which is located in the bottom left of the default File-Open view.

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.
When you expand this directory you will see that the Hotel_net and
project_environment sub-directories, which are the project folders you extracted from
the downloaded zip files, are also listed under the model directories.
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 3
Simulation of Computer Networks
Lab 3: LAN Switching
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:
Computer networking involves understanding limitations of equipment and
technology, be they physical (number of interfaces on a device) or logical (number of
usable IP addresses within a subnet). There is a limit to how many hosts can be
attached to a single network and to the size of the geographical area that a network
can serve (e.g. the physical limitations of transmission media -cabling, wireless signal
etc). The most common form of network infrastructure in terms of Local Area
Networks (LANs) is a switched Ethernet environment. A switch is a device with
several inputs and outputs leading to and from the hosts that the switch interconnects.
Switches allow for the intercommunication between one host and another. The central
role of the switch in the LAN is to take packets that arrive on an input and forward (or
switch) them to the correct output so that they will reach their required destination.
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.
PART 1 - Creating the Project
1. Start Opnet Modeler Choose File, New, Project, then click OK.
2. Name the project <you_initials>_SwitchedLAN, and the scenario HubOnly
and 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.
4. Close the Object Palette when your empty project opens.
PART 2 - Building the Network Model

To create the switched LAN:
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.
3. In the Rapid Configuration dialogue box set the following values:
a. Center Node Model = ethernet16_hub

b. Periphery Node Model = ethernet_station
c. Link Model = 10BaseT
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.
6. Now that you have created the network it
should look similar to the one pictured here:
PART 3 - Configuring the Workstations

Here you will configure the workstations to generate traffic.
1. Right click on any of the 16 workstations (node_0 to node_15) and from
the menu Select Similar Nodes. All the workstations in the workspace will
be selected when you do this.
2. Right click on any of the 16 stations, Edit Attributes:
Check the Apply Changes to Selected Objects check box - this an important feature
to use to prevent you configuring each node individually.
3. Expand the Traffic Generation Parameters attribute, and the Packet
Generation Arguments in the hierarchy. Set the following 4 values by clicking in
the Value field and selecting Edit:
ON State Time: (exponential) 100
OFF State Time: (constant) 0.0
Interarrival Time (seconds): (exponential) 0.02
Packet Size (bytes): (constant) 1500
Note: Packet Size in a switched Ethernet LAN will differ depending on

what the networks Maximum Transmission Unit MTU needs to be. This is
the maximum size of the Ethernet Frame traversing the network at Layer 2.
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
compound attribute called Traffic Generation Parameters which lets the modeller
generate streams of generic packets (i.e. not linked to any specific network
application layer or layer 3 protocol). Consequently this method of traffic generation

is often used to study Layer 2 technologies such as Ethernet, Frame Relay, and ATM,
but there are traffic generating workstation nodes for IP also (however here we are
investigating Ethernet traffic).
PART 4 Choosing Statistics for Collection
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.
To choose statistics to be collected during the simulation:
1) Right click anywhere in the project workspace and select from the menu Choose
Individual DES Statistics.
2) In the Choose Results dialogue box, choose the following 4 statistics:
Ethernet Delay: Global Statistics->Ethernet->Delay (sec)
The Ethernet Delay represents the end to end delay of all packets received by all the
stations.
Traffic Received: Global Statistics->Traffic Sink->Traffic Received (packets/sec)
Represents the amount of traffic received by all the sinks across all the nodes in the
network, a sink is where a packet terminates, on termination any associated statistics
are updated for example the Traffic Received global statistic would be incremented
(Double-click on a workstation node, how many sinks does a workstation have?).
Traffic Sent: Global Statistics->Traffic Source->Traffic Sent (packets/sec)
Represents the amount of traffic sent by the traffic sources (in this case all the packet
generating nodes we set in the scenario, i.e. all the ethernet workstation nodes).
Collision Count: Node Statistics->Ethernet->Collision Count
1
This is the total number of collisions encountered by the hub (or hubs) during
packet transmissions within the scenario.
3) Click OK to apply these statistics collection
settings to your scenario.
Next step now is to configure the simulation
parameters.
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
collisions, the event of a collision causes the Ethernet to undergo a recovery procedure.
PART 5 Configure the Simulation

Here we configure the duration of the simulation:
a)
Click on the Configure/Run Simulation button

in the Toolbar on the
Project Editor or alternatively click on DES->Configure/Run Discrete Event
Simulation in the Project Editor Menu bar.
b)
c)
Set the duration to be 2.0 minutes.

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).
PART 6 Duplicate the Scenario

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
3) We need to place an additional hub and a switch in the new scenario:

a. To add the Hub double-click on its icon in the object palette
ethernet16_hub if in tree view, or single click if in icon view, then move
your mouse pointer over the project workspace and click to drop at the
location you select. Right click to stop deploying hub objects.
b. Repeat the same procedure to add the Switch ethernet16_switch
(Question: what is the significance of the number 16 in the model name?)
c. Close 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.
6) Reconfigure the network of the HubandSwitch scenario so that is looks
like the following one:
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.
To add a new link,

use the 10BaseT link
available in the
Object Palette.
Use the View->Layout>Scale Node Icon
Interactively feature
in the project Editor
to scale individual or
groups of icons to
better utilise your
workspace.
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
each with 8 ethernet workstations attached.

7) Save your project.
PART 7 Run the Simulation
To run the simulations for both scenarios together follow these steps:
1. Select from the Scenarios menu Manage Scenarios.
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.
4. Click on View Details in bottom left corner of DES Execution Manager
Dialogue Box. After the two simulations run complete (they will run in
succession), one for each scenario, click the Close button.
[If you get error messages then check your model is configured correctly, as above,
or ask your lab instructor for assistance.]
PART 8 View the Results

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
almost identical on average in the preview panel.
Note: To view statistics collected during

simulation across different scenarios select
them from here. The select results are then
previewed in the panel to the right.
2. To display the results as a graph you must click the Show button at the
bottom right of the Compare Results window.
3. Deselect the previously selected statistics to clear the preview panel.
4. Select the Traffic Received

(packet/sec)
statistic
(under
Global Statistics -> Traffic Sink > Traffic Received packets/sec)
and click
Show (for both scenarios
HubOnly and HubAndSwitch).
The resulting graph should
resemble the one shown here. As
you can see the traffic received in
the
second
scenario,
HubAndSwitch, is higher than
that of the HubOnly scenario:
Question: Why do think this
is the case?
5.
Again
deselect
the
previously selected statistics
and select the Delay (sec)
statistic for both scenarios and
click Show. The resulting
graph should resemble the one
here. ( Note: Your results may
differ slightly to this due to
different node placement
since Delay takes physical
distance into consideration).
6. Again deselect the previously selected statistics from the Compare Results
window and now select under the Object Statistics:
Office Network -> Hub 1-> Ethernet -> Collision Count
- From both scenarios, HubOnly and HubAndSwitch.
Office Network -> Hub 2-> Ethernet -> Collision Count
- From the HubAndSwitch scenario only.
- When you have selected the above then click Show to display the graph.
Question: Why does the Switch in the HubAndSwitch scenario not have
a Collision Count statistic associated with it?
7. The resultant graph should resemble the one below:
8. Save your project.
[END OF LAB]
Keith Sharp Glasgow Caledonian University - edited

2012
Glasgow Caledonian University Keith Sharp 2012
Keith Sharp Glasgow Caledonian University edited 2012
LAB 4
Simulation of Computer Networks Lab 4: Building Network Models

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.
An IP, is simply a number, whose basic representation is a binary number, typically
written in dotted decimal notation for e.g.
IP address representations:
Binary (base2): 11000000101010000000101000000001
Decimal (base10): 3232238081
Dotted Decimal: 192.168.10.1
An IP address is always accompanied by a subnet mask, which again is a binary
number but with a specific format. The subnet mask determines the network part of
the IP address and the host part. Classfull IP addressing has fixed subnet masks for
each class.
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).
The network address is the first 24 bits of the IP address = 192.168.10.0
The host address is represented in the last 8 bits = .1 = 00000001 (binary), 1 (decimal)
Below is a summary of the IPv4 address Classes:
(you should be familiar with the first 3 classes)
Class Leading
bits
A
0
B
10
C
110
D
1110
E
1111
Start
address
0.0.0.0
128.0.0.0
192.0.0.0
224.0.0.0
240.0.0.0
End address
127.255.255.255
191.255.255.255
223.255.255.255
239.255.255.255
255.255.255.255
Default Subnet Mask Total #of host

addresses
24
255.0.0.0 (/8)
2 -2
16
255.255.0.0 (/16)
2 -2
8
255.255.255.0(/24)
2 -2
28
224.0.0.0 (/4)
2 -2
28
240.0.0.0 (/4)
2 -2

5. Start Opnet Modeler Choose File, New, Project, and then click OK.
6. Name the project <your_initials>_Subnetting, and the scenario
ComponentsOnly and then click OK.
7. In the Startup Wizard: Initial Topology dialogue box, ensure that Create
Empty Scenario is selected. Click Next, then choose Campus from the
Network Scale list (leaving the defaults), -> Click Next, three times and then
finally click Finish.
8. Close the Object Palette when your empty project opens.
PART 2 Preparing the workspace

1. Change the background properties in the Project Editor as follows
View->Background->Set Properties
The following properties should be set to:
Units: Kilometres
Drawing: Dashed
Division: 1
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.
4.
Open the Object Palette if it is not already open.
5.
In the Object Palette take the following components from the
Sm_Int_Model_List palette and drop them into the project work space.
(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:
3 x CS_7505_5s_e6_fe2_fr4_sl4_tr4 routers (under Cisco 7505)
Note: that the Cisco 7505 series routers have the wrong icon associated with them, this is
a bug in Modeler 16.1, but the model is right one which you can confirm by right clicking
the router icon and choosing edit attribute. In front of make you can confirm the router
model.
n.b. the graphical icon of a model does not affect its behaviour in any way.
3.
From the object ethernet palette take:
4 x ethernet16_bridge bridges 8 x
ethernet16_hub hubs
1 x IP Attribute Config object
ether
4.
From the 3Com palette take:
1 x 3C_SSII_3900_4s_ae36_ge3 switch (in the 3Com SSII 3900-36 folder)

5.
From the internet_toolbox 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.
Try this out for yourself:
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.)
The following figure is what you should have in your ComponentsOnly scenario:
Figure 2.1
Your initial scenario should have the above components, named and numbered as
shown in figure 2.1
PART 3 Duplicate the scenario
Duplicate the ComponentsOnly Scenario and call the new scenario NetworkModel
via the Project Editor Menu: Scenarios->Duplicate Scenario
PART 4 Building the Network Model
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:
Figure 2.2 Network Model Topology
Keith Sharp Glasgow Caledonian

University - edited 2012
Building the Network Model (continued):

a)
Use 10BaseT for all the links except servers.
b)
Use PPP_DS1 links for any links to the servers and the Internet cloud.
Note: these links are available together in the internet_toolbox palette.

Changing Link Appearance
Sometimes network models can be made clearer by assigning different colours
and widths to the links in the network (this has been done in Figure 2.2). To do
this with your links, select the links you wish to change and right click on one of
them and select Edit Attributes (Advanced) -making sure if you have selected
more than one link to check the Apply changes to selected objects check box:
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).
Additionally links do not need to be restricted to straight line connections between
nodes. By clicking at intermediate points between nodes when drawing a link, you
can influence the path of the link between network objects. In the real world
network cables are rarely laid in straight lines between network nodes. We simply
deploy them here without this consideration for convenience.
c) Change the appearance of all the workstation nodes:
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:
i)
Right-click on any of the workstations in the NetworkModel scenario and

click on
Select Similar Nodes to highlight all the Sm_Int_wkstn nodes.

ii)
Now Right-click on one of the selected nodes then select Edit
Attributes (Advanced) and check the Apply changes to selected objects
checkbox.
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
to all the workstations. Use View->Layout->Scale Nodes Interactively to scale

the workstations to a smaller size (50%).
Part 5 Configuring the Network Model

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:
1.
Configuring network address parameters for the workstations.
2.
Configuring network addresses parameters for the Cisco 7505 routers.
3.
Configuring network addresses parameters for the Cisco 7000 routers.
4.
Configuring IP addresses for all network interfaces.
1. Configuring network addresses for the workstations:

a)
Click on any workstation in the NetworkModel scenario, and use Select
Similar Nodes from the right-click menu to select all the workstations.
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:
Change the following values for the workstations:

IP->IP Host Parameters->Interface Information->Address: Auto Assigned
IP->IP Host Parameters->Interface Information->Subnet Mask: Class C
(natural)
2. Configuring network addresses for the Cisco 7505 routers:
a) For the Cisco 7505 routers (Router1,2,3)
Use the following values:
IP->
IP Routing Parameters->
Loopback Interfaces->
Click in the Value field to the right and
Select Edit:
When you select Edit the following screen will appear:
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.
3. Configuring network addresses for the Cisco 7000 routers
Repeat the same steps as in 2 above for the Cisco 7000 routers (i.e. Router 4 and 5).
4. Configuring IP addresses for all network interfaces
Before configuring IP addresses on all the interfaces duplicate the NetworkModel
scenario (it is always a good idea to save larger projects in stages, scenarios give a
natural facility to enable this). From the Project Editor:
Scenarios->Duplicate Scenario
Call the duplicated Scenario AutoAssignIPv4
Now assign IP addresses to all the (Layer 3) interfaces in the network of this
duplicate scenario, in the Project Editor select:
Protocols->IP->Addressing->Auto-Assign IPv4 Addresses
Now IP addresses (IPv4 addresses) will be assigned to all the connected (and
loop back) interfaces in the network model scenario.
Part 6 Assigning Services to Servers

To assign services to the servers in the topology follow these steps:
a) Right-click on a server and then click on Edit Attributes->Applications->
Application: Supported Services and click in the Value field and select Edit
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:
These choices will appear as long as the
Description field is Supported.
To add a service just select one of the predefined
values in the drop down menu (listed here ->)
To add more than one service to the server you
must click the Insert button to add additional
rows. If you know the number of additional
services you want you can also add more
rows/services via the Rows box.
Set the servers in the network model as follows:
For the Print and DB Server add the following services to the server:
File Print (Heavy), Database Access (Light)
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.
Part 7 Create a ping traffic demand

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.
b) The ip_ping _traffic demand will appear as an arrow from the
starting point object to the end point object of the traffic flow.
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.
To set the parameters of the demand, Right click on the arrow
representing the ping traffic and click on
Edit Attributes:
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.
c) Save your project
Part 8 Running the Simulation

1. Remaining in the AutoAssignIPv4 scenario click on the Configure/Run
Simulation icon, or select from the Project Editor,
DES->Configure/Run Discrete Event 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.
Part 9 IP address assignment analysis
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
i) To obtain the IP addresses of workstations and servers:
-Perform a Right-click on the node
-Select Edit Attributes
-Expand Attribute IP->IP Host Parameters->Interface Information->Address
ii) To obtain the IP addresses of routers:
-Perform a Right-click on the node
-Select Edit Attributes
-Expand Attribute IP->IP Routing Parameters->Interface Information->rows
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.
In the project Editor:

Select View->Show Network Browser, your Project Editor window will change its
appearance with a listing of all the scenarios network objects on the left hand side:
The Network Browser view can also be filtered to list individual object types you have in
the current scenario you are viewing in the Project Editor. You can use the top drop down
box to list the nodes of a certain type in your network (i.e. you can use this feature for
collecting the IP addresses of the workstations, servers, and routers).
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.
NB - Use the table below to write down the listed IP addresses.
Node Interface
IP Address
Network and
Subnet Mask
1
2
3
4
5
6
7
8
9
Interface Name
(e.g. IF0, LB0)
Node Interface
IP Address
Network and
Subnet Mask
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Router 1 Loopback
Router 1 to Switch 1
Router 1 to Hub 2
Router 1 to Hub 6
Router 2 Loopback
Router 2 to Bridge 3
Router 2 to Hub 7
Router 2 to Hub 8
Router 2 to host 15
Router 2 to host 16
Router 3 Loopback
Router 3 to Hub 3
Router 3 to Hub 5
Router 4 Loopback
Router 4 to Hub 8
Router 4 to IP cloud
Router 4 to Print & DB
Server
Router 5 Loopback
Router 5 to IP Cloud
Router 5 to FTP and
Telnet Server
Print and DB Server
FTP and Telnet Server
IP Cloud to Router 4
IP Cloud to Router 5
Interface Name
(e.g. IF0, LB0)
Router Interfaces
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:
i) From the Project Editor
Right-click on the router you want to investigate and select View Node
Description, this will bring up useful information about the router model, including
what interface numbers correspond to which ports/link technologies.
OR
ii) From the Object Palette
Right-click on the network device you are interested in and select View Model Details
and the same information is listed as in i) under the Comments panel of the window.
Router interfaces cont

For the CS_7505_5s_e6_fe2_fr4__sl4_tr4, model we are using as an example the
interface details are given like this:
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?
Part 10 Analyse the ICMP Ping Results

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:
Object Tables->Campus Network->23->Performance->
Ping Report for Campus Network FTP and Telnet Server at 100 seconds
Click Show to bring up the table of results in a separate window:
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.
Part 11 Further Analysis

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).
3.
Duplicate the current scenario (i.e. the AutoAssignIPv4) and call it
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.
5.
Connect the Packet Analyzer, to Hub 8 using a single 10BaseT connection.
Essentially this object is a workstation with its NIC set in promiscuous mode and
can sniff traffic using filtering rules.
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).
7.
Then right click on it again and select via Edit Attributes:
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).
Expand row 0 and change the following attribute values:
Profile Name: Telnet Profile
Applications: Change the rows value from 0 to 1, this will create a row 0, then
simply click in the Value field of the Name Attribute then from the applications that
appear select Telnet Session (Heavy) you can safely leave the rest of the parameters
as their defaults your Attributes for this Profile Config object should look similar to
the following:
www.wireshark.org
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->
Left-Click in the Value field and select Edit
The following screen appears:
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.
Change the value in the rows field from 0 to 1.
b) Then once you have added the new row, you then must expand the Filtering
Information Attribute then adjust the following settings as follows:
Source IP address: node 13 IP address
Capture Filename: <your_name>_capture.txt
(Remember: to get the IP address of the workstation, Right Click on it ->

Edit Attributes->IP->IP Host Parameters->Interface Information)
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.
a) Open Microsoft Excel in the Virtual Machine
Start->Programs->Microsoft Office->Microsoft Office Excel 2003
5.
Locate the Packet Analyzer capture file via the File->Open on the main Menu
once Excel has opened.
6.
Open the <your_name>_capture.txt file via the opnet_models folder where
it will have been saved by default change the File of type: drop down on the Open
dialogue to Text Files (*.prn, *.txt, *.csv) so that you can select the newly created
capture file.
d) When you open the file the following Text Import Wizard screens will appear,
complete the steps given here to format your data from the capture file:
Step 1: Select the option: Original Data Type: Delimited, and then Click Next.
Step 2: Select the option: Delimeters: Comma and Click Finish.

e) You can now analyze the data from the formatted text file:
Note that the capture file shows packets being sent from host 13 to the FTP and the
Telnet Server (do not worry about the packet internals at present). However we only
have half of the Telnet session data, to obtain the complete sessions we must collect
the responses from the FTP and Telnet server to host 13.
Question 11.1: How could the server responses be collected using the procedures you
have learnt in this lab?
Tutorial Questions Week 5 Simulation of Computer Networks

Question 1: According to the table of IP addresses you have collected in Lab 2,
which devices/models divide networks.
Question 2: On the network model diagram handout provided,
Draw the layer-3 networks as a solid line, labelling it with the correct network
address and subnet mask.
Draw the layer-2 collision domains as a dashed line
Question 3: In reference to Lab 2, why do hosts 15 and 16 belong to two different
class C networks?
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.
Rename the existing ethernet_pkt_analyzer object to 13toTelnetServer Edit the
name of the capture file for this node to 13toTelnet_capture.txt Add a second
ethernet_pkt_analyzer object to the scenario and call it
TelnetServerto13 and set its parameters to collect traffic from the Telnet Server
to host 13 and attach this to hub 8 (using a 10BaseT link).
Set the capture file for the TelnetServerto13 analyzer to Telnetto13_capture.txt
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 5
Lab 5: Topology Diagram
Fundamentals of Simulation of Computer Networks
Lab 5: Routing (RIP)

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:
In relation to Opnet software it is important to recognise the integration of certain features
common to network device models, be they end hosts or gateway devices such as routers.
Networks are often described in terms of their operational layers for e.g. using reference
models such as the OSI or the TCP/IP reference models. Therefore there exist common
functions which occur at certain network layers which must be adopted for modelling and
simulation purposes to accurate replicate network behaviour.
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.
PART 2 Create and Configure the Network Model
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:
7. Add the following objects to the project workspace:
a) 1 x ethernet4_slip8_gtwy
router b) 2 x 100BaseT_LAN
1
2
objects.
8. Use bidirectional 100BaseT links to connect the object you added to your
project scenario. Rename and position the objects as shown below.
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.
LAN objects are a way to simulate a local area network without explicitly using individual host,
connections and devices. The LAN object models many users on the same LAN and also allows
for a server within the LAN also. Because fewer objects are present in your network when you
use LAN objects they help reduce the memory required to run simulations. (see Appendix A of
your introductory manual).
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.
3. Close the Object Palette dialogue box.

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).
PART 3 Configure the Router

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:
Reports->RIP Routing Table
Then make sure the following parameters values are set
a) Status: Enabled
b) Export Time(s) Specification: End of Simulation
c) Click OK and save your project.
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.
PART 4 Adding more LANs

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
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.
PART 5 Choose the Statistics for Collection

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
Choose Individual DES Statistics from the pop-up menu.

8) In the Choose Results window, check the following statistics:
The PPP_DS3 link has a speed/data rate of 44.736Mbps.
a) Global Statistics ->RIP->Traffic Sent (bits/sec)
b) Global Statistics->RIP->Traffic Received (bits/sec)
c) Node Statistics -> Route Table -> Total Number of Updates
Click OK and then save your project.
PART 6 Configure the Simulation Parameters

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
Configure Simulation window via DES->Configure/Run Discrete Event
Simulation
Note that you can also press Ctrl+R to bring up this window or you can click its
associated icon on the Project Editors toolbar:
2. Set the duration to 10.0 minutes.
3. In the leftmost panel of the Configure/Run DES interface expand the
Common->Inputs->Global Attributes hierarchy (see below for screenshot)
Under Global Attributes change the following attribute values:
a) IP->IP Dynamic Routing Protocol = RIP
b) IP->IP Interface Addressing Mode = Auto Addressed/Export
c) Simulation Efficiency -> RIP Sim Efficiency = Disabled
d) Simulation Efficiency -> RIP Stop Time (seconds) = 600
7.
Total number of RIP update traffic (in bits) received per second by all the nodes using RIP
as the routing protocol in the IP interfaces in the node.
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).
e) Click Apply and then save the project.
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).
PART 7 Duplicate the Scenario
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.
Add a Failure Recovery object to your workspace and name it Failure as
illustrated in the following diagram.
Right-click on the newly added Failure object and select Edit Attributes:
Expand the Link Failure/Recovery Specification hierarchy and set rows to 1
Set the attributes of the newly added row, row 0 as below:
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
Router2 red to highlight the link failure for that scenario).

Click OK to confirm the changes and save the project.
Question 7.1 - What is displayed in the Value field of the Name attribute
when you click on it?
PART 8 Run the Simulation

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.
PART 9 View simulation results
9. 1 Comparing the number of routing updates

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:
3) Select the Total Number of Updates statistic for Router1 and Click Show.
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.
The graph on the top sections shows

the total number of router updates
for the Failure scenario and the
bottom graph shows this also but for
the
NO_Failure scenario.
Question 9.1.1 What happens if
you hold your mouse cursor over
a bar on the simulation output
graphs?
Question 9.1.2 Maximise the
results window what happens
to the x and y scales?
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>_RIPFailure-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?
9. 2 Obtain the IP addresses of the Interface

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
Generic Data File, making sure you have selected the correct folder in the
Model directories: panel.
Select the <your_initials>_RIP-NO_failure-ip_addresses file (nb the other file

exported for the other scenario should contain the same information). Once you have
selected the file click Open.
3. The following figure show part of the gdf file contents. It shows the IP
addresses assigned to the interfaces of Router1 in our network:
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
this then you can use the topology diagram available on page 4.
9. 3 Compare the Routing Tables
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.
Expand
the
hierarchy:
Campus
Network.Router1-
>Performance Click on - Routing Table RIP at 600 seconds

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.
Routing Table of Router 1 at the end of the NO_Failure scenario simulation:
Routing Table of Router 1 at the end of the Failure scenario simulation:
Question 9.2.1 With regards to the operation of the RIP routing protocol can
you explain the difference between the Routing Tables for each of the scenarios?
Question 9.2.2 What metric is used by the RIP routing protocol, and what
is the maximum possible value this metric can be?
(Hint for the above two questions see the RIP handouts)
9.4 Compare the sent RIP traffic for both scenarios

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.
Your results should be similar to those illustrated here:
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?
PART 10 Link Recovery

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:
Note: You will have to add a row to the Link Failure/Recovery Specification to allow
you to recover from the pre-existing failure already configured.
3. Generate and analyse the graphs which show the effect of this recovery on the Total
Number of Updates in the routing table of Router1.
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?
5. Save your work.
[END OF LAB]
Lab 6
Fundamentals of Simulation of Computer Networks
Lab 6: Distributions, Measurement and Traffic
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.
Essentially distributions are an arrangement of values of a variable showing their observed
or theoretical frequency of occurrence. To obtain parameters for a distribution function,
typically requires either some kind of analysis of sample data or analytically predicting the
behaviour of some system variable. Using distributions and altering default parameters in
Opnet models are closely related as most network based phenomena is time-based. Events in
simulation systems are often characterised using distributions, however actual event data can
usually be imported also, but the overhead of processing real data is often greater than using
an efficient and accurate distribution function.
Part 1 The Real-world scenario

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.
Figure 1.0: GCU network scenario
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
Glasgow Caledonian University 2012
Keith Sharp 2
Part 2 Determining Packet Latency with ICMP ping

2.1 IP Cloud Models
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
the next section we go over the specifics of this test.
PLEASE NOTE SOME OF THE STEPS BELOW HAVE BEEN DONE FOR YOU
DUE TO RESTRICTIONS WITHIN THE UNIVERSITY NETWORK.
2.2 Calculating Packet Latency with ICMP
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:
To calculate Packet Latency there is a simple formula:
Latency = (Ping Response Time Retransmission Delay per Hop) / 2
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.
2.3 Determining the Hop Count
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
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
th
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
Tracing route to opnetserver.enterprise.gcal.ac.uk
[10.15.1.11] over a maximum of 30 hops:
<1 ms
<1 ms
<1 ms
2
3
<1 ms
2
ms
<1 ms
2
ms
<1 ms
172.16.28.1
2
ms 172.16.15.2
<1
<1
<1
ms
ms
10.28.11.1
ms opnetserver.enterprise.gcal.ac.uk [10.15.1.11]
tracert is a path discovery utility which is part of the Windows TCP/IP protocol suite.
From the data presented via the Windows tracert utility we can add value to our abstract
diagram. Figure 2.0 shows an abstract representation of the path our traffic takes from the PC
to the server. Note that the router icons are used to represent network hops they are not
literally used to represent the physical infrastructure between the PC and the opnetserver.
Figure 2.0: Abstraction of the tracert results
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?
10. What protocol does the tracert utility operate over?
2.4 Determining the Ping Response Time

2.4.1 Problem with Microsoft ping
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.
5 Issue a ping command to the opnetserver at 10.15.1.11.
Note that you should get a set of results similar to those illustrated below:
C:\>ping 10.15.1.11
Pinging 10.15.1.11 with 32 bytes of data:
Reply from 10.15.1.11: bytes=32 time<1ms TTL=125
Ping statistics for 10.15.1.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
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.
ping options:
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
-a
-n
-l
-f
-i
-v
-r
-s
-j
-k
count
size
TTL
TOS
count
count
host-list
host-list
-w timeout
Ping the specified host until stopped.

To see statistics and continue - type Control-Break;
To stop - type Control-C.
Resolve addresses to hostnames.
Number of echo requests to send.
Send buffer size.
Set Don't Fragment flag in packet.
Time To Live.
Type Of Service.
Record route for count hops.
Timestamp for count hops.
Loose source route along host-list.
Strict source route along host-list.
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
usage: hrPING [options] host
options:
-lic
-t
-n count
-E file
-l size
-L size
-f
-i TTL
-v TOS
-w timeout
-s time
-r [count]
-a [hop]
-o
-tsc
-W
-F file
-T
-I id
-q
-A
-H
Show public license and warranty

Ping the specified host until stopped
Number of echo requests to send (default 4)
Stop pinging when <file> exists
Send buffer size (ICMP payload size, default 64)
Total IP datagram size (ICMP payload size + 28)
Set Don't Fragment bit in IP header
Time To Live (default 255 for ping, 30 for traceroute)
Type Of Service (default 0)
Timeout in millisecs to wait for each reply (default 2000)
Interval in millisecs between packets (default 500 ms)
Be a traceroute (do <count> pings each hop, default 3)
Resolve addresses to names for traceroute (start at <hop>)
Don't do overlapped send/receive
Force RDTSC usage
"warm up" with one uncounted echo request at beginning
Log output into <file> as well
Print timestamp in front of each line
Set ICMP id field to <id>
Don't print a line per ping
Abort after the first echo reply (-AA => or error)
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).
Note: Your results should be of a similar format to that included below:

C:\Program Files\hrping-v235>hrping 10.15.1.11
Using source IP address 10.28.11.154
packets Pinging 10.15.1.11
with 64 bytes data (92 bytes IP):
Reply
Reply
Reply
Reply
from
from
from
from
10.15.1.11:
10.15.1.11:
10.15.1.11:
10.15.1.11:
seq=0000
seq=0001
seq=0002
seq=0003
time=0.962ms
time=0.390ms
time=0.392ms
time=0.375ms
to
send
TTL=127
TTL=127
TTL=127
TTL=127
ID=1ebe
ID=1ebf
ID=1ec0
ID=1ec1
Statistics for 10.15.1.11:

Packets: sent=4, rcvd=4, error=0, lost=0 (0% loss) in 1.500374 sec
RTTs of replies in ms: min/avg/max: 0.375 / 0.529 / 0.962
C:\Program Files\hrping-v235>
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?
2.5 Measuring the Ping response time
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:
C:\Program Files\hrping-v235>hrping -n 100 10.15.1.11

Using source IP address 10.28.11.154
packets Pinging 10.15.1.11
with 64 bytes data (92 bytes IP):
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
send
from 10.15.1.11: seq=0000 time=1.314ms TTL=128 ID=ff3b

from 10.15.1.11: seq=0001 time=0.570ms TTL=128 ID=ff3c
from 10.15.1.11: seq=0002 time=0.558ms TTL=128 ID=ff3d
from 10.15.1.11: seq=0003 time=0.530ms TTL=128 ID=ff3e
from 10.15.1.11: seq=0004 time=0.568ms TTL=128 ID=ff3f
from 10.15.1.11: seq=0005 time=0.567ms TTL=128 ID=ff40
from 10.15.1.11: seq=000a time=0.585ms TTL=128 ID=ff45
from 10.15.1.11: seq=000b time=0.532ms TTL=128 ID=ff46
from 10.15.1.11: seq=000c time=0.546ms TTL=128 ID=ff47
from 10.15.1.11: seq=000d time=0.699ms TTL=128 ID=ff48
from 10.15.1.11: seq=000e time=0.581ms TTL=128 ID=ff49
from 10.15.1.11: seq=000f time=0.557ms TTL=128 ID=ff4a
Glasgow Caledonian University 2012
Keith Sharp 9
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply

Statistics for 10.15.1.11:

Packets: sent=100, rcvd=100, error=0, lost=0 (0% loss) in 49.500460 sec
RTTs of replies in ms: min/avg/max: 0.505 / 0.590 / 1.748
C:\Program Files\hrping-v235>
[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).
2.6 Extracting the response time data
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
This timing information was extracted simply by using pattern matching/extracting

mechanisms which are built into most Word/Text processing software (including MS Word).
1) Download the file from Blackboard and place it inside your VMware virtual machine.
2.7 Determining the average response time value

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:
1) Open Microsoft Excel inside your Opnet VMware environment.
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
7) Next generate a graph of the data by following these steps:
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.
b) Click on the Chart Wizard button on the Excel toolbar:
c) Select the following:
Chart Type = Line
Char sub-type = Line
Feel free to annotate your graph as you wish using the wizard but do not alter the
default display settings for the data:
Click Next> three times and then click Finish
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)
9)
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:
The insert function wizard will appear:
Select AVERAGE from the Select a function:

panel.
Click OK.
10) The function arguments dialogue box will then show up, when it does select all
the numeric data again as you did in step 7 a). then click OK
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
12) Save your spreadsheet.
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.
2.8 Revisiting the Packet Latency formula

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)
Hop Count = 2 (from tracert)
Ping Packet Size = 64+28 = 92 bytes or 92*8 = 736 bits (default for hrping)
Data Rate = ? (not calculated)
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
100Mbps. However the likelihood is that the backbone of the GCU campus network is much
faster.
Looking at the equation the numbers give us the following calculation:
Latency = (0.59054 (2 * (736/100 000 000))) / 2
Latency = (0.59054 (2 * 0.00000736)) / 2 Latency
= (0.59054 0.00001472) / 2
Latency = (0.59052528) / 2
Latency = 0.29526264 ms (remember our calculations were in milliseconds)
Latency = 0.29526264/1000 = 0.00029526264 or roughly 0.0003 seconds.
Part 3 Building the network model

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
other connections.
This model now represents our scenario as depicted in figures 1.0 and 2.0.
Part 4 Configuring the network model

4.1 Configure the IP Cloud
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
Mean outcome: 0.0003 secs
Click OK
4.2 Configure Application Traffic

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.
1) Right click on the Application Config/Definition Object. Expand the Attribute

Application Definitions and add 1 row.
Expand the newly created row 0:
Under the Name attribute enter the name Web Traffic.
Expand the Description hierarchy and select under Http Heavy

Browsing
Leave the other parameters to default and click OK.
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.
Under the Profile Name enter the name Web Profile.
Expand the Application hierarchy and add a row under it.
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.
Leave the other parameters to default and click OK.
4.3 Configure the server to support the previously defined web services
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.
2)
Click in the rows Value field and add a row.
3)
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.
4.5 Configure simulation parameters

Specify Global Statistics to collect:
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.
Specify Simulation Parameters

1)
From the project editor menu select DES->Configure/Run Discrete Event
Simulation
2)
Set the duration of the simulation to be 1 hour, leave the other parameters to their
defaults.
Save your project

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.
Part 5 - Duplicate the Scenario

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.
3)
Click OK and save your changes.
Part 6 Run the simulation

1)
To run the simulation for both scenarios at once. Go to the Scenarios->
Manage Scenarios menu via the Project Editor.
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:
Part 7 Compare the results
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.
Your results should reflect those depicted in the following diagram:
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]
Glasgow Caledonian University
101
Keith Sharp 2012

Lab Files For Opnet Modeler

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Lab Files For Opnet Modeler

Enviado por

Direitos autorais:

Formatos disponíveis

OPNET Modeller lab booklet

Keith Sharp Glasgow Caledonian University - edited 2012