Lab Files for Opnet Modeler (1).pdf

OPNET Modeller lab booklet

Keith Sharp Sharp Glasgow Caledonian University - edited 2012 2012

M ode eler – Introductory Lab Files for Opnet Mod Introductory Lab Manual

To do the labs in the Opnet Modeler 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 Blackboard->Course Documents->Opnet Labs-> Week 1->Labs From here download the zip file – 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 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.


M ode eler – Introductory Lab Files for Opnet Mod Introductory Lab Manual

To do the labs in the Opnet Modeler 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 Blackboard->Course Documents->Opnet Labs-> Week 1->Labs From here download the zip file – 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 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 Diretory the following screen will appear, locate the VMware desktop and select it. op_models folder on your VMware desktop


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 application‟s environment variables.

Keith Sharp Glasgow Caledonian University - edited 2012

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 _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 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 Opnet‟s 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 t raffic 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.

1

Collisions occur on the network when the Ethernet system resolves simultaneous attempts to access the shared channel. On a busy Ethernet with fast machines you can expect to see many


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: 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.

a)

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 easil y 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 – Switch – ethernet16_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 E dit menu (or simply hit the D elete elete key). You can select multiple links by

Shift Shif t+le +left clicki clicking ng successive links and then you can delete them all at once.

To add a new link, use the 10Base link 10B aseT T link available in the Object Palette Object Palette. Use the View->Layout-

>Scale >Scale N ode ode I con I nter nter acti active vely ly 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 Keith Sharp Sharp Glasgow Caledonian University - edited 2012 2012

each with 8 ethernet workstations attached. 7) Save your project. PART 7 – 7 – Run 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 (or ) for both scenarios. Compare with the following screenshot:

to run the two simulations. Note that depending on the speed 3. Click OK to 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 If you get error messages then check your model is configured correctly, correctl y, as above, or ask or ask your lab instructor for assistance.] assistance. ]

PART 8 – 8 – View 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 Results window from As Is to time_average . Keeping the statistics Overlaid, select the Traffic Sent (packets/sec) statistic ubA ndSwitch) ndSwitch): from each Scenario ( HubOnly and and H ubA In the reference diagram below you will see that the traffic in both scenarios is Keith Sharp Sharp Glasgow Caledonian University - edited 2012 2012

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. Results window. 3. Deselect the previously selected statistics to clear the preview panel.

4. Select the Traffic Received

statistic (under (packet/sec) Global Statistics -> Traffic Sink > Traffic Received packets/sec) packets/sec) and click Show (for both scenarios HubOnly and HubAndSwitch). HubAndSwitch). The resulting graph should resemble the one shown here. As you can see the traffic received in Keith Sharp Sharp Glasgow Caledonian University - edited 2012 2012

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 H ubAndSwitch 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]


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 A B C D E

Leading bits 0 10 110 1110 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

Default Subnet Mask

127.255.255.255 191.255.255.255 223.255.255.255 239.255.255.255 255.255.255.255

255.0.0.0 (/8) 255.255.0.0 (/16) 255.255.255.0(/24) 224.0.0.0 (/4) 240.0.0.0 (/4)


Total #of host addresses 2 -2 2 -2 2 -2 2 -2 2 -2

PART 1 - Creating the Project 5. Start Opnet Modeler – Choose File, New, Project , and then click OK. 6. Name the project _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.

In the Object Palette take the following components from the 5. 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) Again in the Object Palette open the Cisco palette and pick up the 6. following items and place them into your project workspace: Keith Sharp Glasgow Caledonian University - edited 2012

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 ethernet16_hub hubs 1 x IP Attribute Config object

8

x

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 PC 1, 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



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 Keith Sharp Glasgow Caledonian University - edited 2012

to all the workstations. Use View->Layout->Scale Nodes Interactively to scale the workstations to a smaller size (50%).


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 Cisc o 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: Keith Sharp Glasgow Caledonian University - edited 2012

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. Keith Sharp Glasgow Caledonian University - edited 2012


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 scenario‟s 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

Interface Name

Subnet Mask

(e.g. IF0, LB0)

1 2 3 4 5 6 7 8 9


Node Interface

IP Address

Network and

Interface Name

Subnet Mask

(e.g. IF0, LB0)

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


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.

Connect the Packet Analyzer, to Hub 8 using a single 10BaseT connection. 5. Essentially this object is a workstation with its NIC set in promiscuous mode and can sniff traffic using filtering rules.

Re-assign IP addresses to all devices in the new scenario via the Project 6. Editor menu: Protocols->IP->Addressing->Auto-Assign IPv4 Addresses

5.

From the Object Palette get a Profile Config object (you can either search 5. 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:


1

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: _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 _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:

DE S->Configur e/Run Discrete E vent Si mulation… and then click the R un 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 i ntegral 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.


PART 1 - Creating the Project 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: F ile -> New from the main menu, select Project and click OK . 11. Name the project: _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.

1

In the recent past routers were often referred to as gateways. This router model supports connections for Ethernet and Serial Line Internet Protocol (SLIP) links. SLIP is a networking standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard but is defined in RFC 1055.


2

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 gatewa y 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‟ r outing 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: E nabled b) Export Time(s) Specification: E nd 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 Keith Sharp Glasgow Caledonian University - edited 2012

multiple objects by clicking on them one-by-one and holding down the Shift key. b) Once you have selected all 5 objects (two LAN objects, one router, and two links), Press Ctrl+C, to copy the selected objects and then press Ctrl+V to paste a copy of the network segment you just created. c.

Repeat Step 2 three times to make three new copies of the objects and arrange them as depicted in the following diagram – note how the names of the objects remain the same and the numbers increment.

d. So now you should have 4 routers named Router1, Router2, Router3, Router4, and connected to each of these you have Net1 + Net10, Net2 + Net11, Net3+Net12, Net4

+ Net13, respectively. Connect them together as below using PPP_DS3 link s

3

(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:

3

The PPP_DS3 link has a speed/data rate of 44.736Mbps.


4

a) Global Statistics ->RIP->Traffic Sent (bits/sec)

5

b) Global Statistics->RIP->Traffic Received (bits/sec)

c) Node Statistics -> Route Table -> Total Number of Updates

6

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 ef ficiently 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 Editor‟s 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 = RI P b) IP->IP Interface Addressing Mode = Auto Addressed/E xport 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 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 painter‟s palette icon on the Project Editor’s 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 (or ) 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 _RIP-

Failure-DES-1.txt Question 9.1.3 – Look at the left most column of the data, at what frequency is data collected? How many times within the simulation is data collected?

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 _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 machine‟s 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 P roject Editor’s 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.R outer1-

>Performance Click on - Routing Table – RI P 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 DE S->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 RI P - Tr affic 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 Router1 ‟s 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 network‟s 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 University‟s 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 the opnetserver which is located on the 6

th

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 provider‟s 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

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 Microsoft‟s 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 Latency = (Ping Response Time

Retransmission Delay per Hop) / 2

–

(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

th

floor of the Saltire Centre library. th

a) Using a Windows XP PC on the 4 floor of the Saltire Centre, a tracert

1

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

<1 ms

<1 ms

<1 ms

10.28.11.1

2

<1 ms

<1 ms

<1 ms

172.16.28.1

3

2

ms

2

ms

2

ms 172.16.15.2

4

<1

ms

<1

ms

<1

ms opnetserver.enterprise.gcal.ac.uk [10.15.1.11]

1

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 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 Microsoft‟s 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

Ping the specified host until stopped.

-a -n -l -f -i -v -r -s -j -k

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.

To see statistics and continue - type Control-Break;

count size TTL TOS count count host-list host-list

-w timeout

Timeout in milliseconds to wait for each reply.

hrping options: C:\Program Files\hrping-v235>hrping 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

Don't do overlapped send/receive Force RDTSC usage "warm up" with one uncounted echo request at beginning Log output into as well Print timestamp in front of each line Set ICMP id field to 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

Show public license and warranty Ping the specified host until stopped Number of echo requests to send (default 4) Stop pinging when 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 r eply (default 2000)

Interval in millisecs between packets (default 500 ms) Be a traceroute (do pings each hop, default 3) Resolve addresses to names for traceroute (start at )

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 t o do this (where you typically carry out your Opnet based based labs).

Keith Sharp Sharp Glasgow Glasgow Caledonian University University - edited 2012 2012


Note: Your results should be of a similar format to that included below: C:\Program Files\hrping-v235>hrping 10.15.1.11 This is hrPING v2.35 by cFos Software GmbH -- http://www.cfos.de 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 – time – for 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 100 pings were 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 This is hrPING v2.35 by cFos Software GmbH -- http://www.cfos.de 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

from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from

to

send

10.15.1.11: seq=0000 time=1.314ms TTL=128 ID=ff3b 10.15.1.11: seq=0001 time=0.570ms TTL=128 ID=ff3c 10.15.1.11: seq=0002 time=0.558ms TTL=128 ID=ff3d 10.15.1.11: seq=0003 time=0.530ms TTL=128 ID=ff3e 10.15.1.11: seq=0004 time=0.568ms TTL=128 ID=ff3f 10.15.1.11: seq=0005 time=0.567ms TTL=128 ID=ff40 10.15.1.11: seq=0006 time=0.576ms TTL=128 ID=ff41 10.15.1.11: seq=0007 time=0.584ms TTL=128 ID=ff42 10.15.1.11: seq=0008 time=0.578ms TTL=128 ID=ff43 10.15.1.11: seq=0009 time=0.560ms TTL=128 ID=ff44 10.15.1.11: seq=000a time=0.585ms TTL=128 ID=ff45 10.15.1.11: seq=000b time=0.532ms TTL=128 ID=ff46 10.15.1.11: seq=000c time=0.546ms TTL=128 ID=ff47 10.15.1.11: seq=000d time=0.699ms TTL=128 ID=ff48 10.15.1.11: seq=000e time=0.581ms TTL=128 ID=ff49 10.15.1.11: seq=000f time=0.557ms TTL=128 ID=ff4a 10.15.1.11: seq=0010 time=0.582ms TTL=128 ID=ff4b 10.15.1.11: seq=0011 time=0.575ms TTL=128 ID=ff4c 10.15.1.11: seq=0012 time=0.559ms TTL=128 ID=ff4d 10.15.1.11: seq=0013 time=0.565ms TTL=128 ID=ff4e 10.15.1.11: seq=0014 time=0.591ms TTL=128 ID=ff4f 10.15.1.11: seq=0015 time=0.566ms TTL=128 ID=ff50 10.15.1.11: seq=0016 time=0.585ms TTL=128 ID=ff51 10.15.1.11: seq=0017 time=0.560ms TTL=128 ID=ff52 10.15.1.11: seq=0018 time=0.584ms TTL=128 ID=ff53 10.15.1.11: seq=0019 time=0.555ms TTL=128 ID=ff54 10.15.1.11: seq=001a time=0.546ms TTL=128 ID=ff55 10.15.1.11: seq=001b time=0.553ms TTL=128 ID=ff56 10.15.1.11: seq=001c time=0.552ms TTL=128 ID=ff57 10.15.1.11: seq=001d time=0.546ms TTL=128 ID=ff58 10.15.1.11: seq=001e time=0.574ms TTL=128 ID=ff59 10.15.1.11: seq=001f time=0.559ms TTL=128 ID=ff5a 10.15.1.11: seq=0020 time=0.576ms TTL=128 ID=ff5b 10.15.1.11: seq=0021 time=0.574ms TTL=128 ID=ff5c 10.15.1.11: seq=0022 time=0.541ms TTL=128 ID=ff5d 10.15.1.11: seq=0023 time=0.560ms TTL=128 ID=ff5e 10.15.1.11: seq=0024 time=0.573ms TTL=128 ID=ff5f 10.15.1.11: seq=0025 time=0.575ms TTL=128 ID=ff60 10.15.1.11: seq=0026 time=0.565ms TTL=128 ID=ff61 10.15.1.11: seq=0027 time=0.566ms TTL=128 ID=ff62 10.15.1.11: seq=0028 time=0.553ms TTL=128 ID=ff63 10.15.1.11: seq=0029 time=0.538ms TTL=128 ID=ff64 10.15.1.11: seq=002a time=0.601ms TTL=128 ID=ff65 10.15.1.11: seq=002b time=0.581ms TTL=128 ID=ff66 10.15.1.11: seq=002c time=0.567ms TTL=128 ID=ff67 10.15.1.11: seq=002d time=0.540ms TTL=128 ID=ff68 10.15.1.11: seq=002e time=0.545ms TTL=128 ID=ff69 10.15.1.11: seq=002f time=0.578ms TTL=128 ID=ff6a 10.15.1.11: seq=0030 time=0.753ms TTL=128 ID=ff6b 10.15.1.11: seq=0031 time=0.561ms TTL=128 ID=ff6c 10.15.1.11: seq=0032 time=0.563ms TTL=128 ID=ff6d 10.15.1.11: seq=0033 time=0.805ms TTL=128 ID=ff6e 10.15.1.11: seq=0034 time=0.700ms TTL=128 ID=ff6f 10.15.1.11: seq=0035 time=0.531ms TTL=128 ID=ff70 10.15.1.11: seq=0036 time=0.577ms TTL=128 ID=ff71 10.15.1.11: seq=0037 time=0.613ms TTL=128 ID=ff72 10.15.1.11: seq=0038 time=0.559ms TTL=128 ID=ff73


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

from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from from

10.15.1.11: seq=0039 time=0.544ms TTL=128 ID=ff74 10.15.1.11: seq=003a time=0.565ms TTL=128 ID=ff75 10.15.1.11: seq=003b time=0.523ms TTL=128 ID=ff76 10.15.1.11: seq=003c time=0.584ms TTL=128 ID=ff77 10.15.1.11: seq=003d time=0.627ms TTL=128 ID=ff78 10.15.1.11: seq=003e time=0.574ms TTL=128 ID=ff79 10.15.1.11: seq=003f time=0.560ms TTL=128 ID=ff7a 10.15.1.11: seq=0040 time=0.799ms TTL=128 ID=ff7b 10.15.1.11: seq=0041 time=0.549ms TTL=128 ID=ff7c 10.15.1.11: seq=0042 time=0.568ms TTL=128 ID=ff7d 10.15.1.11: seq=0043 time=0.529ms TTL=128 ID=ff7e 10.15.1.11: seq=0044 time=0.668ms TTL=128 ID=ff7f 10.15.1.11: seq=0045 time=0.563ms TTL=128 ID=ff80 10.15.1.11: seq=0046 time=0.546ms TTL=128 ID=ff81 10.15.1.11: seq=0047 time=1.748ms TTL=128 ID=ff82 10.15.1.11: seq=0048 time=0.550ms TTL=128 ID=ff83 10.15.1.11: seq=0049 time=0.532ms TTL=128 ID=ff84 10.15.1.11: seq=004a time=0.558ms TTL=128 ID=ff85 10.15.1.11: seq=004b time=0.544ms TTL=128 ID=ff86 10.15.1.11: seq=004c time=0.633ms TTL=128 ID=ff87 10.15.1.11: seq=004d time=0.531ms TTL=128 ID=ff88 10.15.1.11: seq=004e time=0.701ms TTL=128 ID=ff89 10.15.1.11: seq=004f time=0.544ms TTL=128 ID=ff8a 10.15.1.11: seq=0050 time=0.562ms TTL=128 ID=ff8b 10.15.1.11: seq=0051 time=0.505ms TTL=128 ID=ff8c 10.15.1.11: seq=0052 time=0.548ms TTL=128 ID=ff8d 10.15.1.11: seq=0053 time=0.525ms TTL=128 ID=ff8e 10.15.1.11: seq=0054 time=0.537ms TTL=128 ID=ff8f 10.15.1.11: seq=0055 time=0.538ms TTL=128 ID=ff90 10.15.1.11: seq=0056 time=0.547ms TTL=128 ID=ff91 10.15.1.11: seq=0057 time=0.526ms TTL=128 ID=ff92 10.15.1.11: seq=0058 time=0.565ms TTL=128 ID=ff93 10.15.1.11: seq=0059 time=0.531ms TTL=128 ID=ff94 10.15.1.11: seq=005a time=0.510ms TTL=128 ID=ff95 10.15.1.11: seq=005b time=0.526ms TTL=128 ID=ff96 10.15.1.11: seq=005c time=0.536ms TTL=128 ID=ff97 10.15.1.11: seq=005d time=0.683ms TTL=128 ID=ff98 10.15.1.11: seq=005e time=0.561ms TTL=128 ID=ff99 10.15.1.11: seq=005f time=0.533ms TTL=128 ID=ff9a 10.15.1.11: seq=0060 time=0.536ms TTL=128 ID=ff9b 10.15.1.11: seq=0061 time=0.530ms TTL=128 ID=ff9c 10.15.1.11: seq=0062 time=0.543ms TTL=128 ID=ff9d 10.15.1.11: seq=0063 time=0.520ms TTL=128 ID=ff9e

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 graph‟s appearance after you have made it using the wizard to suit your visual requirements. To determine the average response time from the data, select cell 101 and type the

8)

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:

9)

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 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.

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 Keith Sharp Glasgow Caledonian University - edited 2012

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 cloud‟s 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 – H eavy

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 ma de 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

DE S->Results-> C ompare 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 .


Lab Files for Opnet Modeler (1).pdf

Recommend Documents