Lab Files For Opnet Modeler
Lab Files For Opnet Modeler
Lab Files For Opnet Modeler
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.
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
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:
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
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.
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:
compound attribute called Traffic Generation Parameters which lets the modeller
generate streams of generic packets (i.e. not linked to any specific network
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.
b)
c)
To remove a link,
select it and choose
Cut, from the Edit
menu (or simply hit the
Delete key). You can
select multiple links by
Shift+left clicking
successive
links
and then you can
delete them all at
once.
The new HubandSwitch scenario only comprises of two new objects, an additional
hub and a switch. The network has the switch interconnecting two ethernet hubs
Keith Sharp Glasgow Caledonian University - edited 2012
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.]
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.
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?
[END OF LAB]
LAB 4
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
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:
Keith Sharp Glasgow Caledonian University - edited 2012
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.
4 x ethernet16_bridge bridges 8 x
ethernet16_hub hubs
1 x IP Attribute Config object
ether
4.
From the 3Com palette take:
2 x ppp_server servers
1 x ip32_cloud Internet cloud model
3. Now rename the nodes you have collected to the names in figure 2.1. We need 23
workstation nodes using simply the names 1,2,3,,23 however we do not want to
rename these all individually 23 times. The simplest way to create consistently named
objects in Opnet is to name one first and then copy that instance multiple times. The
copy operation is smart enough to know to increment the number portion of the name.
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:
b)
Use PPP_DS1 links for any links to the servers and the Internet cloud.
2.
3.
4.
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:
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.
Keith Sharp Glasgow Caledonian University - edited 2012
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.
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.
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
Keith Sharp Glasgow Caledonian University - edited 2012
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.
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?
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.
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.
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:
Keith Sharp Glasgow Caledonian University - edited 2012
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->
Keith Sharp Glasgow Caledonian University - edited 2012
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
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.
Keith Sharp Glasgow Caledonian University - edited 2012
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.
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?
Lab 5
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.
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.
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.
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).
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.
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
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.
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.
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?
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.
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-
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)
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?
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
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.
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
Keith Sharp 2
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
Keith Sharp Glasgow Caledonian University - edited 2012
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?
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
Reply from 10.15.1.11: bytes=32 time<1ms TTL=125
Reply from 10.15.1.11: bytes=32 time<1ms TTL=125
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
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
-S
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).
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
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:
to
send
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
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
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:
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.
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
Keith Sharp Glasgow Caledonian University - edited 2012
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.
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
Keith Sharp Glasgow Caledonian University - edited 2012
other connections.
This model now represents our scenario as depicted in figures 1.0 and 2.0.
Secondly we specify the behaviour of any applications we have chosen by giving them
an associated profile of behaviour.
2) Right click on the Profile Config/Definition Object. Expand the Attribute Profile
Configuration and add 1 row.
Expand the newly created row 0 under the Application hierarchy and click on the
Value of the Name attribute and select Web Traffic from the drop down menu.
Keith Sharp Glasgow Caledonian University - edited 2012
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)
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.
Simulation
2)
Set the duration of the simulation to be 1 hour, leave the other parameters to their
defaults.
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)
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