Importing Network Traffic - Suraj @ LUMSsuraj.lums.edu.pk/~te/simandmod/Opnet/11 importing...

687-Trf

Importing Network Traffic

Chapter 11

688-Trf

Modeling Concepts

689-Trf

Modeling Concepts

OverviewIm

po

rting

Netw

ork

Traffic

Trf.1 Overview

There are several types of traffic that can be used to load a network, includingexplicitly generated traffic, conversation pair (background routed) traffic, anddevice/link load (background utilization) traffic. While explicitly generated trafficmust be defined in OPNET, conversation pair traffic and link load traffic can beimported from outside sources.

When performing a traffic import, there are several steps which can varydepending on the type of traffic you are importing, but in general these steps are:

1) Preparing for traffic import

2) Importing using archive aliases (ESP module only)

3) Importing conversation pair traffic or device/link loads

4) Converting loads to conversation pairs (if necessary)

5) Importing distributions from packet traces (optional)

6) Specifying edge/core devices (optional)

7) Importing Node Aliases (optional)

Trf.2 Preparing for Traffic Import

There are several steps to complete in preparation for importing traffic, the firstof which is capturing or creating the network traffic file. If you are importing trafficfrom traffic collection software such as Agilent’s NetMetrix, Concord’sNetworkHealth, Cisco’s NetFlow, etc, you should refer to the product-specificdocumentation for detailed instructions on capturing traffic. If you are importingtraffic from an ASCII text file or a spreadsheet, refer to sections

Trf.3.5 ImportingConversation Pair Traffic from a Spreadsheet

,

Trf.3.6 Importing Conversation PairTraffic from a Text File

, and

Trf.5.3 Importing Device/Link Load Traffic from a textfile

for more information.

Once you have collected or created your traffic files, you must locate themwhere Modeler can see them, as discussed in the following section.

Specifying Traffic File Locations

The location of traffic files, whether they reside on a UNIX or Windowsmachine, is specified by Modeler’s

traffic_archive_dir

environmentattribute. If the traffic files reside on the same machine as Modeler,

traffic_archive_dir

can be specified from the Preferences selection underthe Edit menu. If the traffic files are on a machine other than the one runningModeler, you must install the Remote Traffic Import programs on the remote

690-Trf

Preparing for Traffic Import

Modeling Concepts

machine, then specify

traffic_archive_dir

in the

op_rtid.ef

environment file, located on the remote machine.

To specify the traffic directory for a local machine...

1) If Modeler is not running, start it.

2) From the Edit menu, choose Preferences.

3) Set the

traffic_archive_dir

attribute to the directory where your trafficfiles are located.

➡

When you perform traffic imports, Modeler will look in the directoryspecified by

traffic_archive_dir

for the traffic files.

To specify the traffic directory on a remote machine...

1) Install

op_servd

,

op_rtid

, and

op_rtid.ef

in a user-specified directory on theremote machine if you have not already done so. Then set

traffic_archive_dir

in the

op_rtid.ef

file

to specify the pathname of the directory where the traffic files reside.

2) On the machine running Modeler, go to the Edit menu and choose Preferences.

3) Edit the

traffic_servers

environment attribute to include the names ofany machines on which the Remote Traffic Import program has been installed.

Note: If a server uses a port number other than 0 (the default value of

servd_port

) to listen for command-line arguments from Modeler, youshould append a colon and the port number to the server name–i.e.“

server:5101

”.

4) Close the

Preferences

dialog box.

➡

When you perform traffic imports, Modeler will look on any machinesspecified by the

traffic_servers

attribute for additional traffic files.

5) Start

op_servd

from the command line. You should start the program from thedirectory where you installed it, and include the “

./

” prefix in the programname (as in “

./op_servd -servd_port

<port_number>

”).

691-Trf

Modeling Concepts

Preparing for Traffic ImportIm

po

rting

Netw

ork

Traffic

Importing Traffic Files

Once the traffic files have been placed in the proper directory, they can beimported into Modeler and applied to the network in the current scenario. Refer tothe following sections,

Importing Conversation Pair Traffic

and

Importing Device/Link Load Traffic

, for import procedures on each specific type of traffic.

Trf.2.1 Creating Archive Aliases

Archive aliases can only be created with the ESP module. If you continuouslymonitor your network traffic using NetMetrix or other traffic collecting software,you may wish to set up imports that take place automatically whenever new trafficfiles are generated. These imports can be set up using

archive aliases

inconjunction with the Schedule Automated Simulations feature. Creating and usingarchive aliases is discussed here. For information on using the ScheduleAutomated Simulations feature, refer to section

Schedule Automated Simulations

in the Project Editor chapter of the Editor Reference manual.

Creating an archive alias

An

archive alias

is a placeholder that represents a traffic archive file that willexist at some time in the future. Specifying an alias causes OPNET to look for atraffic archive file with a particular name when the next import occurs (this name isshown in angle brackets when the alias is displayed in the

Traffic Import

dialog box).The name of the traffic archive file is computed whenever an import takes place.Therefore, one archive alias refers to different archive files created over a period oftime.

For example, suppose you schedule your network for weekly traffic collectionfrom 1:00 PM to 3:00 PM on the first day of each week. At 3:00 PM on January 11,1999, a new traffic archive file called "D_1999_01_11" will be created by yourtraffic collection program (presumably it is configured to create files with thisnaming convention). You create an alias file with a matching naming conventionthat refers to the previous day's results, and schedule a traffic import for 12:01 AMon the second day of each week. At 12:01 AM on January 12, 1999, OPNETperforms the traffic import as scheduled, using the archive alias to look for thenewly created traffic file. If you were to view the traffic import dialog box at thattime, you would see that the alias was displayed with the name“<D_1999_01_11>”, which matches the archive file. On the following week, at12:01 AM on January 19, 1999, the alias will compute the name “D_1999_01_18”for the archive file, and so on.

To create an archive alias…

1) Create a directory for the new traffic files if one does not already exist (thisdirectory should be accessible from your

traffic_archive_dir

prefer-ence).

692-Trf

Preparing for Traffic Import

Modeling Concepts

2) In OPNET, open the project and scenario you wish to set up for automatedtraffic import.

3) Choose Import Conversation Pairs (Network menu

➧

Import Traffic submenu).

4) In the

Import Traffic

dialog box, right-click on the directory which will hold thenew traffic files, then choose Add Archive Alias from the pop-up menu.

➡

The

Archive Alias

dialog box opens.

There are several options that can be specified in this dialog box:

•

Use archives created N days prior to import

—Specifies the numberof days the archive is created prior to its import. For example, if a trafficfile is captured every Friday from 12am to 12am (a 24-hour period) andyou wanted to import the file each Sunday night to run a simulation,you would set N to 2.

•

In format

—Specifies a default pattern for a naming convention, in-cluding: HP NetMetrix, HP NetMetrix ASCII, ExpertSniffer, FlexibleCSV, and others.

•

Filename Patterns

—Specifies the file name format of the traffic file tobe created. Default file name patterns are provided with each traffic fileformat, or you can specify your own using the “Year”, “Month” and“Day” buttons.

Note that when you specify the format and file name pattern, a sample filename appears in the dialog box.

5) Specify the settings in the

Archive Alias

dialog box appropriately, then click

OK

.

➡

The new archive alias appears in the

Traffic Import

dialog box in theappropriate directory. Note that the icon in front of the alias name is whiteinstead of green, and also that the alias is labeled with the computed name inangle brackets.

693-Trf

Modeling Concepts

Importing Conversation Pair TrafficIm

po

rting

Netw

ork

Traffic

Archive aliases are automatically added to the list of archives to import.

Note: Archive aliases are not actual traffic files and therefore do not containany traffic. If an actual archive file corresponding to the archive alias does notexist at the time of the next import, no traffic will be imported for that file.

6) Click the

Save

button to save the selected archives and aliases. These files willbe imported the next time an import is performed. If you wish to scheduleautomatic imports before a simulation, refer to section

Schedule AutomatedSimulations

of the

Project Editor

chapter in the

Editor Reference

manual.

Trf.3 Importing Conversation Pair Traffic

Conversation pair traffic can be imported in several formats:

• From Agilent NetMetrix (formerly HP NetMetrix)

• From Cisco NetFlow

• From NetScout Manager

• From Network Associates’ ExpertSniffer

• From a spreadsheet

Archive alias

694-Trf

Importing Conversation Pair Traffic

Modeling Concepts

• From a text file

Trf.3.1 Importing Conversation Pair Traffic from Agilent NetMetrix

If a NetMetrix traffic file resides on a Windows machine and will be importedinto Modeler from that Windows machine, the file must first be converted to ASCIIformat. However, if the traffic file resides on a UNIX machine and will be importedinto Modeler on a Windows machine using Remote Traffic Import, the file does notneed to be converted to ASCII.

Importing from Agilent NetMetrix

1) If you are importing traffic from a remote machine, make sure you have the

op_servd

daemon running on that machine. If it is not running, start the pro-gram from the directory where it resides, and include the “

./

” prefix in the pro-gram name (as in “

./op_servd -servd_port

<port number>

”).

2) In Modeler, open the project and scenario containing the network to which youwish to import traffic.

3) Choose From Agilent NetMetrix (Traffic menu

➧

Import Conversation Pairssubmenu).

4) In the

Traffic Import

dialog box, left-click on the archives you wish to import.

➡

Selected archives appear in the Selected Archives section of the dialog box.Also note that as you select each traffic file, the information about that fileappears in the Probe Information section on the right-hand side of the dialogbox.

5) Set the options under Traffic Selection appropriately for the traffic you areimporting.

Note: For more information about using the Traffic Import dialog box, refer toImporting Traffic Files on page 691.

6) Click

OK

to begin traffic import.

➡

The progress bar shows the progress as the traffic files are imported.

Once traffic import has completed, you may need to use the Unassigned TrafficAssistant and the Node Aliases feature to assure that all imported traffic has beenassigned to the proper objects. For more information on these features, refer to

Toassign unrecognized traffic sources…

on page 701and

Trf.8 Working with NodeAliases

695-Trf

Modeling Concepts

Importing Conversation Pair TrafficIm

po

rting

Netw

ork

Traffic

Trf.3.2 Importing Conversation Pair traffic from Cisco NetFlow Collector

This import method requires the Multi-Vendor Import (MVI) module. Refer toTrf.2.1 Importing Traffic from Network Associates’ Expert Sniffer Files in theMulti-Vendor Import User Guide for more information.

Trf.3.3 Importing Conversation Pair traffic from NetScout Manager

This import method requires the Multi-Vendor Import (MVI) module. Refer toTrf.2.3 Importing Traffic from a NetScout Manager Database in the Multi-VendorImport User Guide for more information.

Trf.3.4 Importing Conversation Pair Traffic from ExpertSniffer

This import method requires the Multi-Vendor Import (MVI) module. Refer toTrf.2.1 Importing Traffic from Network Associates’ Expert Sniffer Files in theMulti-Vendor Import User Guide for more information.

Trf.3.5 Importing Conversation Pair Traffic from a Spreadsheet

This import method, coupled with the Export Conversation Pairs toSpreadsheet feature (Exporting Conversation Pair Traffic to a Spreadsheet on page713) provides you with a powerful tool for viewing and editing conversation pairtraffic in spreadsheet format. Typically, this import feature will be used after traffichas first been exported to a spreadsheet and edited. In this way conversation pairtraffic can be edited quickly and easily.

To import conversation pair traffic from a spreadsheet…

1) In Modeler, open the project and scenario containing the network to which youwish to import traffic if it is not already open.

2) Choose From Spreadsheet (Traffic menu ➧ Import Conversation Pairssubmenu).

3) In the Select traffic file to import dialog box, navigate to the appropriate directory,then select the traffic file (.txt file) to import.

➡ The selected file appears in the Open section of the dialog box.

4) Click OK.

➡ The Import Traffic Flows dialog box appears.

5) In the Import Traffic Flows dialog box, choose one of the following options:

Replace all existing traffic - replaces all existing conversation pair traffic in the entire net-work with the traffic defined in the imported .txt file.

696-Trf

Importing Conversation Pair Traffic Modeling Concepts

Replace only pairs defined in spreadsheet - if the imported .txt file only defines traffic forcertain objects in the network, and you select this option, only these objects’ traffic to bereplaced. All other conversation pair traffic in the network will remain the same.

6) Click OK to begin traffic import.

Trf.3.6 Importing Conversation Pair Traffic from a Text File

ASCII-format text files that contain conversation pair traffic must be convertedto CSV (comma separated value) format before they can be imported. You canconvert the files manually, or you can automate the process by using externalpreprocessing script files.

Converting Traffic Files Manually

Once you have created an ASCII file, you must convert it to a comma separatedvalue file (CSV) and edit the header to the appropriate format.

To convert to a CSV file and edit the archive header…

1) Open the ASCII traffic file in an editor or spreadsheet that supports CSV files,such as Microsoft Excel.

Note: Traffic archives are typically very large, so some text editors may not beable to open them.

2) There are two formats of CSVs supported by Modeler—NetMetrix ASCII(.tr1) and Flexible CSV (.tr2). You must edit the headerinformation of your file to include header information in the format of yourchoice, as shown on the following pages.

3) Save the traffic archive file in CSV format.

Now that you have converted the traffic archive to ASCII format, you are readyto move the file to the appropriate directory and import it. Refer to SpecifyingTraffic File Locations on page 689 for detailed instructions on moving andimporting traffic files.

Using Preprocessing Scripts to Convert Traffic files

You may want to import traffic from files that use ASCII formats unsupportedby Modeler. If you have (or can create) executable scripts to convert particulartypes of files to Flexible CSV (.tr2) format, you can assign these scripts to specificfiles during a traffic-import operation. Modeler runs these scripts before importingthe data; this allows you to import traffic from many different file types at once.

Note: You cannot use this feature to import traffic data from a remote machineor a NetScout Manager database.

697-Trf

Modeling Concepts Importing Conversation Pair TrafficIm

po

rting

Netw

ork

Traffic

A preprocessing script must be either a shell script or an executable file thattakes two command-line arguments. The program should read in the traffic file(specified by argument 1), convert its contents to .tr2 format, and write the resultsto the output file (specified by argument 2).

To use this feature, you must register each script using thetraffic_preprocessor_progs environment attribute. You must enter fullpath names for any scripts located outside your user path.

Once you have registered your scripts, you can use the Traffic Preprocessor pull-down menu (on the Traffic Import dialog box) to assign conversion scripts to specificarchives. All scripts listed in traffic_preprocessor_args appear on this menu. SeeImporting Traffic Files on page 691 for specific information on assigning scripts totraffic files.

Trf.3.7 Completing a Conversation Pair Import

The Traffic Import dialog box

The Probe information that appears with each traffic archive file providesidentifying information about the file:

• Host—Specifies the IP address of the probe.

Traffic Import Dialog Box

698-Trf


• Media—The type of NetMetrix probe (Ethernet, FDDI, etc.) used tocollect network traffic.

• Device—The name of the NetMetrix probe.

• Start—The start time of the traffic capture period.

• End—The end time of the traffic capture period.

• Interval—The amount of time between traffic collection.

Under the Selection section, you can set several options that control the trafficimport:

• From—Indicates the start time of the period of traffic to import. Theimport period can be a subset of the collection period, but the From timecannot be earlier than the Start time. The default From time is the sameas the Start time.

• To—Indicates the end time of the period of traffic to import. The im-port period can be a subset of the collection period, but the To time can-not extend past the end of the collection period. The default To time isthe same as the End time.

• Edit Selection—Allows you to graphically set the From and To times.Traffic is shown as a bar graph in which the graph divisions are the traf-fic capture intervals. ASCII traffic files always show 32 intervals,whereas NetMetrix traffic intervals are determined by the number oftraffic capture periods.

Note: Only NetMetrix can be shown in graph form. Because of performanceissues, ASCII traffic files cannot be shown in graphical format at this point.

699-Trf


po

rting

Netw

ork

Traffic

• Archive Merging Mode—Indicates what merging mode to use when1) you are importing from multiple traffic files, or 2) you choose to re-tain (not overwrite) the current traffic data in your scenario. In boththese cases the merge mode resolves any conflicting data in multipletraffic sources. Merging is useful when you have nodes on differentsegments, and probes on each segment as well. When nodes send trafficto one another, the traffic will be recorded by the probe on each seg-ment, so that multiple values for the same traffic will be stored in thearchive file. During import, you can set the Archive Merging Mode op-tion to either Maximum, Addition, or Minimum. Setting the mergemode to Maximum selects the maximum of the two traffic values dur-ing import (this setting is most commonly used), while setting Mini-mum selects the smaller of the two traffic values. Choosing Additionadds the two traffic values.

• Traffic Preprocessor pull-down menu—Allows you to import trafficarchives that use ASCII formats unsupported by OPNET. By selectingan archive and then choosing a preprocessing script in this menu, youcan automatically convert the archive to Flexible CSV (.tr2) format pri-or to the import. Note that you cannot assign a script to multiple ar-chives—you must assign a script to each archive individually. Theinitial setting for all archives is None. This tells OPNET to import thefiles “as is,” and is the correct setting for CSV, NetMetrix, and Snifferfiles. See section Importing Conversation Pair Traffic from a Text Fileon page 696 for more information on using preprocessing scripts.

Note: You cannot use this feature when importing traffic data fromremote machines or NetScout Manager databases.

Traffic Graph Example

700-Trf


• Concatenate Traffic Data check box—Indicates whether OPNETconcatenates multiple archives from a single traffic server. Normallywhen you import multiple archives, OPNET overlays them so that traf-fic runs concurrently: the start time for each archive’s traffic corre-sponds to the simulation start time. With this feature enabled, OPNETorders the archives by start time so that traffic runs consecutively: thetraffic for each subsequent archive follows the traffic in the precedingarchive.

This feature is useful when you have successive runs from a single net-work traffic probe (as opposed to multiple probes running concurrent-ly). Suppose you have two traffic archives: the first represents trafficcollected from 9:00 to 9:30, and the second represents traffic collectedfrom 10:00 to 10:30. Enabling this feature results in concatenated traf-fic over one hour of simulation time. (The half-hour interval from 9:30to 10:00 is ignored.) Disabling this feature results in the two archives’traffic running concurrently over 30 minutes of simulation time;OPNET calculates aggregate traffic loads based on the Archive Merg-ing Mode setting.

Note: This feature does not concatenate traffic from multiple serv-ers; OPNET concatenates the archives from each server but over-lays the results from all servers.

4) Set the options under Traffic Selection appropriately for the traffic you areimporting.

5) Click OK to begin traffic import.

➡ The progress bar shows the progress as the traffic files are imported.

Completing the Import

During import, OPNET matches imported traffic with source nodes in thenetwork model using the node’s network alias. A network alias can consist ofeither an IP address or a MAC address, and nodes may have multiple aliases.Aliases are persistent OPNET-wide by default, but can be project-wide if theapply_all_aliases environment attribute is FALSE. When this attribute isFALSE, you can share aliases across scenarios with the Export Change Set andImport Change Sets operations (Scenarios menu ➧ Node Aliases submenu). TheNode Aliases submenu also includes the Export to Text File and Import from TextFile operations, which allow you to edit your aliases in a spreadsheet program andthen reimport them into OPNET.

If OPNET is unable to match traffic to a network object, the traffic will appearin the Unrecognized Traffic Assistant dialog box after import. Unrecognizedsources may appear during import for one of two reasons: either the source nodewas accidentally omitted from the network (if, for example, Node Manager was

701-Trf


po

rting

Netw

ork

Traffic

unable to properly discover the node), or the traffic source is not actually part ofthe network. The first case might occur if a network machine is running AppleTalk.Because Node Manager does not recognize machines connected to the network viaAppleTalk, it would not be able to correctly discover the node. An imported trafficfile would probably have traffic from that node, but since the node does not appearin the network model, the import process would be unable to match the traffic withthe correct source node. The second case might occur if a node inside the networkcommunicates to a machine outside the modeled network. Traffic from the outsidemachine would appear in the traffic file, but there would not be a correspondingsource node in the network model.

In either case, any unrecognized traffic can be associated with a network objectafter import. In order to associate a traffic source to an network object, the source’sIP or MAC address must be added to the object’s list of aliases. For example, in thecase where there is traffic from many sources outside the network, you mightassociate all the outside sources with the object (for example, a router) thatconnects the modeled network to the outside world. This way, the aggregate trafficfrom all outside sources is modeled by a single object, called an edge device. Anedge device has a special identifying tag (which can be set in the Selecting EdgeDevices dialog box) that makes assigning unrecognized traffic easier. Once thetraffic has been associated with the proper nodes, the traffic file must be re-imported so that any changes can be applied to the network model.

To assign unrecognized traffic sources…

1) When the traffic import is complete, if there are any unrecognized trafficsources, a dialog box labeled Unrecognized Traffic Assistant will appear. Withinthe Traffic Assistant, there are two divisions of unrecognized sources: thosesources that have IP and MAC address information (these are listed under theicons with an IP address), and sources that do not have IP address information(these are listed under the icons with the traffic archive name). You can use theUnrecognized Traffic Assistant to quickly associate unrecognized sources withnetwork objects.

702-Trf


Note: If you close the Unrecognized Traffic Assistant dialog box, you must re-import the traffic to view the unrecognized sources again.

2) For each object, you must decide if the traffic is necessary for your simulationand, if so, what object to apply the traffic to. There are two cases to consider:

• Traffic with IP or MAC address information—Unrecognized trafficsources with IP and MAC address information (that is, traffic listed un-der the icons with an IP address) usually appear when an object withinthe modeled network attempts to communicate with an object outsidethe network. If the traffic is important to the scenario, it must be asso-ciated with an appropriate node. For example, if the modeled networkhas a dedicated router for connections with the outside world, anysource addresses from outside machines should be associated with thatrouter (which would be tagged as an edge node), as we are concernedwith the aggregate traffic being sent into the network from the outside.If the source’s traffic is not important to the model scenario, it can beignored.

• Traffic without IP address information—Unrecognized traffic thatdoes not have any IP address information can be found in the Unrecog-nized Traffic Assistant under the icon with the traffic archive file name.Typically this type of unrecognized traffic is to and from sources withinthe network. You can either ignore the source if it is not important tothe model scenario, or you can add a new node to the network modeland add the unrecognized source to the node’s alias list. In the casewhere you have many unrecognized sources from inside the network,

703-Trf


po

rting

Netw

ork

Traffic

you may choose to add an object and tag it as an edge device, then as-sociate certain traffic from unrecognized sources with that object.

There are two features in the Unrecognized Traffic Assistant that can helpassign unidentified traffic. Clicking the Suggestions button may provide additionalinformation to help you decide the network object to which traffic should beassigned. The Auto-Assign button takes all remaining traffic sources and distributesthem according to available suggestions and, if there are no suggestions, distributesthe sources to the edge devices.

To add a single source to a network object…

1) In the Unrecognized Traffic Assistant dialog box, under the Unrecognized Sourcessection, click on the sources for which you wish to obtain a suggestion.

Note: If an appropriate object does not already exist, add it in the Project Edi-tor, connect it to the network, then click the Refresh button in the UnrecognizedTraffic Assistant dialog box. The new object will appear and sources can thenbe assigned to it.

2) In the Network Objects section, click on the node object with which you wishto associate the traffic.

Note: You can also click on the Suggestions button if you are not sure whichobject to associate the traffic with.

3) Click on the Assign button.

➡ The traffic is assigned to the selected node, and is removed from theUnassigned Sources section. You can view the sources associated with aparticular node by right-clicking on a node object in the workspace andchoosing Edit Aliases from the object pop-up menu.

To view OPNET’s suggestions for a particular traffic source…

1) In the Unrecognized Traffic Assistant dialog box, under the Unrecognized Sourcessection, click on the sources you wish to associate with a particular nodeobject.

2) Click on the Suggestions button.

➡ If a suggestion is available, the node that is a suggested source will betagged with an arrow and the accompanying suggestion will appear in theSuggestions box.

704-Trf

The Conversation Pair Browser Modeling Concepts

To automatically assign traffic…

1) In the Unrecognized Traffic Assistant dialog box, click on the Auto-Assign button.

➡ All unassigned traffic will be associated with a network object according tothe following rules:

• If there is a single suggestion for the particular traffic source, the trafficwill be assigned according to the suggestion. If there is more than onesuggestion, OPNET will randomly choose a suggestion and assign traf-fic accordingly.

• Traffic that does not have a suggestion associated with it is distributedrandomly to any objects that are specified as edge nodes. (Edge nodescan be weighted, however, to give them more or less priority when traf-fic is assigned.)

• If there are no objects tagged as edge nodes, OPNET will ask if youwould like to specify edge devices. If so, tag the appropriate devicesand run Auto-Assign again. Otherwise, the remaining unassigned traf-fic sources will be ignored during simulation.

Once you have decided what to do with each unrecognized source, you mustre-import the traffic files for the changes to take place.

Trf.4 The Conversation Pair Browser

Once you have imported conversation pair traffic and applied it to theappropriate nodes, you can view and edit the traffic graphically on a per-nodebasis.

Using the Conversation Pair Browser…

1) From the Traffic menu, choose Conversation Pair Browser.

➡ The Conversation Pair Browser opens showing only the network objectsthat are traffic sources. To view all network objects, deselect the Only Sourcescheck box at the lower left of the dialog box.

2) Select a node that is a traffic source. Sources are indicated by a left-pointingarrow.

➡ The destination(s) of that node’s traffic will appear on the Destination sideof the Traffic dialog box.

705-Trf

Modeling Concepts Importing Device/Link Load TrafficIm

po

rting

Netw

ork

Traffic

3) Right-click on one of the source’s destination nodes, then select View Trafficfrom the pop-up menu.

➡ The Traffic dialog box appears, showing the node’s conversation pair trafficin graphical format.

At this point, you can edit, copy, cut, paste, and clear the traffic on any givennode. For step-by-step guidelines on performing these tasks, refer to Bld.6Modeling Network Traffic.

Trf.5 Importing Device/Link Load Traffic

Device/link load traffic can be imported in several formats:

• From Concord NetWorkHealth

• From MRTG

• From a text file

Trf.5.1 Importing Device/Link Load Traffic from Concord NetWorkHealth

This import method requires the Multi-Vendor Import (MVI) module. Refer toTrf.3.6 Importing from NetworkHealth for more information.

Trf.5.2 Importing Device/Link Load Traffic from MRTG

This import method requires the Multi-Vendor Import (MVI) module. Refer toTrf.3.7 Importing from MRTG for more information.

Trf.5.3 Importing Device/Link Load Traffic from a text file

The process of importing device/link loads can be divided into four main steps:

1) Create the ASCII file from which to import data. See Creating a Device/LinkLoad Text File on page 706.

2) Configure OPNET for import by specifying the location of the ASCII files. SeeConfiguring OPNET to Import a Device/Link Load Text File on page 707.

3) Specify aliases. You can skip this step if you have imported your networktopology and you used the IP or MAC addresses as aliases in the ASCII file.Otherwise, see Specifying Aliases on page 707.

When you import a network from HP Network Node Manager or TivoliNetView, OPNET assigns the identifiers it receives (IP addresses andinterface numbers) to the appropriate nodes and links in your network.Later, OPNET receives the alias names you specified in the ASCII file,

706-Trf

Importing Device/Link Load Traffic Modeling Concepts

which include these identifiers. Using the identifier, OPNET matches thealias name to the OPNET network object.

4) Import the device/link load data. See section Trf.8.1 Performing theBackground Utilization Import.

Creating a Device/Link Load Text File

To import device/link load data, a text file in .gbu (General BackgroundUtilization) format must be created. Any standard text editor can be used to createthis file, which should use the following format:

This text file (saved as a .gbu file) is composed of two main sections: a nodesection and a link section. The node section should always appear before the linksection.

Observe the following guidelines when creating these files:

• Entries in each field should be separated by a single tab character.

• The Alias can be any name. Aliases are then associated with actual ob-jects in your network; this process is described in section SpecifyingAliases on page 707.

• The value of the Attribute field should be the actual attribute name:CPU Background Utilization on workstations, ServerBackground Utilization on servers, LAN Background

General Background Utilization (.gbu) File Format

Nodes#Alias Attribute Time (sec) Value %CA Server Background Utilization 300 20DE Server Background Utilization 3800 80MN Server Background Utilization 7600 100MN Server Background Utilization 11500 40

Links#Alias Attribute Time (sec) Value % Directionlink-CA Background Utilization 100 40 Alink-DE Background Utilization 200 50 Blink-DE Background Utilization 400 60 Blink-CA Background Utilization 600 20 Alink-MN Background Utilization 900 99 Blink-NY Background Utilization 300 30 A

707-Trf

Modeling Concepts Importing Device/Link Load TrafficIm

po

rting

Netw

ork

Traffic

Utilization on LAN objects, and background utilizationon links.

• The value for the Time field should be specified in seconds.

• The Value field specifies the percent utilization of the object.

• The Direction field appears only in the Links section. Valid values forthe Direction are “A” and “B”. Since this field is not in use at this time,however, there is no difference between specifying a value of “A” or“B” for this field.

Configuring OPNET to Import a Device/Link Load Text File

Before you can import device/link loads, you must first specify where your text.gbu files are located. Edit the static_bk_util.archive_dir environmentattribute to include the path name to every file to import.

Specifying Aliases

During a device/link load data import, OPNET matches traffic data in the textfile to the corresponding objects in the OPNET network model. To make thesematches, OPNET needs to know the alias, as specified in the text file, for eachnode or link in the network that has imported traffic.

Refer to Trf.8 Working with Node Aliases for more information on how tospecify aliases.

Importing the .gbu text file

To import device/link load text files…

1) From the Traffic menu ➧ Import Device/Link Loads... submenu, choose Importfrom Text Files....

➡ The Import from ASCII dialog box appears.

2) Choose the ASCII text files you wish to import. If you do not see the files,verify that you have configured OPNET with the correct paths as described insection Configuring OPNET to Import a Device/Link Load Text File.

3) Verify the setting of the Sample Size pull-down menu. The default is As Is.Changing the setting makes OPNET recalculate the imported utilization databased on the specified sample rate. For example, suppose that the ASCII filespecifies utilization data values in five-minute increments. If you set thisparameter to By Hour, OPNET calculates the average utilization for each hourrather than importing the data directly.

708-Trf

Converting Link Loads to Conversation Pairs Modeling Concepts

4) Verify the setting of the Overwrite Existing Data check box. When this box ischecked, OPNET overwrites the background utilization attributesettings with the imported values. Otherwise, OPNET sets the backgroundutilization attribute values to be the average of the imported utilizationvalue and the original utilization setting.

5) Click OK to perform the data import.

➡ Progress bars show which files are being imported and parsed.

To verify that the background utilization attributes have beenupdated, examine the background utilization attribute for a link. Thevalue shown in this attribute should match the value shown in the text file.

Trf.6 Converting Link Loads to Conversation Pairs

Because link load traffic only affects the link to which it is applied, you maywant to convert it to conversation pair traffic. As conversation pair traffic, it can bererouted via the routing protocol(s) in use. Therefore, if a link becomesoverloaded, or if a link or node fails in simulation, the conversation pair traffic isrerouted, while the link load traffic will only remain on the link and not bererouted.

To convert link loads to conversation pair traffic…

1) From the Traffic menu, select Convert Loads to Conversation Pairs...

2) In the Convert Loads to Conversation Pairs dialog box, set the conversionoptions appropriately. Explanations of the conversion options follow:

• Average Packet Size - the average size of the packets that are created dur-ing conversion.

• Traffic Data Merge Mode - how converted link load traffic is merged withexisting conversation pair traffic. The options are:

Overwrite - overwrites all existing conversation pair traffic with con-verted link load traffic.

Add - adds the converted link load traffic to the existing conversationpair traffic.

Keep Minimum - for each time period, OPNET Modeler compares theamount of converted traffic to the amount of existing traffic and useswhichever one is smaller.

709-Trf

Modeling Concepts Specifying Core and Edge DevicesIm

po

rting

Netw

ork

Traffic

Keep Maximum - for each time period, OPNET Modeler compares theamount of converted traffic to the amount of existing traffic and useswhichever one is smaller.

• Reset Utilization to Zero - resets all link load traffic to zero after conver-sion.

• Select Core Devices button - allows you to choose which devices shouldbe marked as core. This helps the traffic conversion engine assign con-verted traffic appropriately, as devices marked as core are not used astraffic sources or sinks. Refer to Specifying Core and Edge Devices onpage 709 for more information.

• Show Core Devices button - shows all devices in the network that havebeen marked as core devices.

Trf.7 Specifying Core and Edge Devices

Core and edge devices may need to be assigned for traffic import or conversionoperations.

Core Devices

Core devices must be specified when converting from link loads toconversation pairs so that the conversion is accurate. A core device is neither atraffic sink nor a traffic source, but simply has traffic flowing through it. Typicalcore devices include routers, hubs, and switches.

To add a core device…

1) Choose Specify Core/Edge Devices from the Traffic menu.

2) In the Specify Core / Edge Devices dialog box, click on the device you wish totag as an edge device, then click the Set as Core Device button.

➡ The device appears with an “C” over it, to denote a core device.

3) Click on any additional devices you wish to tag as core devices.

4) When you are finished specifying core devices, click OK.

Edge Devices

Edge devices sometimes must be specified when assigning unrecognizedimported traffic. An edge device is a traffic entry or exit point into the network.

710-Trf

Working with Node Aliases Modeling Concepts

To add an edge device…

1) Choose Specify Core/Edge Devices from the Traffic menu.

2) In the Specify Core / Edge Devices dialog box, click on the device you wish totag as an edge device, then click the Set as Edge Device button.

➡ The device appears with an “E” over it, to denote an edge device.

3) Click on any additional devices you wish to tag as edge devices. If you selectmultiple edge devices, traffic will be divided between them according to theirweight. You can select the default weight, which associates traffic evenlyamong edge devices, or set the weight manually by right-clicking on a nodeand choosing Set Weight.

4) When you are finished specifying edge devices and their weights, click OK.

Trf.8 Working with Node Aliases

OPNET uses node aliases to identify nodes in the OPNET model. Thesealiases operate on a one-to-one basis: a particular IP address in an imported trafficfile is mapped to a particular node on the OPNET model.

OPNET uses interface aliases to identify links in the OPNET model, but themethod is different: a link in the OPNET model is uniquely identified because ithas two particular interfaces. You must enter two interface aliases to acquire all ofthe data for a link; if you enter just one, you receive only the data related to thatinterface.

To assign node aliases to a node...

Note: You must assign an alias to every node for which you will import traffic.

1) Right-click on the node and choose Edit Aliases from the pop-up menu.

➡ The Edit Aliases dialog box appears.

711-Trf

Modeling Concepts Working with Node AliasesIm

po

rting

Netw

ork

Traffic

2) Click the Add button and enter the Alias used in the general backgroundutilization file, then click OK to close the dialog box.

To assign interface aliases to a link...

Note: You must assign an alias to every link interface for which you willimport traffic. We recommend that you work methodically, beginning with thelink in the top left corner of the window and progressing to the lower right cor-ner. Repeat the procedure in this section for every link of interest.

1) Right-click on the link and choose Advanced Edit Attributes from the pop-upmenu.

➡ The Advanced Edit Attributes dialog box appears.

2) Identify which node is node A and which is node B. The name of a link is in theform node_a <--> node_b. In the example above, Bridge is node A andRouter is node B.

712-Trf

Working with Node Aliases Modeling Concepts

3) Click on the Node A Interface Aliases button.

➡ An Interface Aliases edit pad appears.

4) Enter the link alias, as specified in the general background utilization file, forthe node A interface.

5) Click on the Node B Interface Aliases button.

➡ An Interface Aliases edit pad appears.

6) Enter the appropriate alias for the node B interface.

Trf.8.1 Performing the Background Utilization Import

1) Choose Import from Text Files (Traffic menu ➧ Import Device/Link Loads... sub-menu).

➡ The Import from ASCII dialog box appears.

2) Choose the general background utilization files you wish to import. If you donot see the files that you wish to import, verify that you have configuredOPNET with the correct paths as described in section Configuring OPNET toImport a Device/Link Load Text File.

3) Verify the setting of the Sample Size pull-down menu. The default is As Is.Changing the setting makes OPNET recalculate the imported utilization databased on the specified sample rate. For example, suppose that the generalbackground utilization file specifies utilization data values in five-minute

713-Trf

Modeling Concepts Exporting TrafficIm

po

rting

Netw

ork

Traffic

increments. If you set this parameter to By Hour, OPNET calculates the averageutilization for each hour rather than importing the data directly.

4) Verify the setting of the Overwrite Existing Data check box. When this box ischecked, OPNET overwrites the background utilization settings with theimported values. Otherwise, OPNET sets background utilization to be theaverage of the imported utilization value and the original utilization setting.

5) Click OK to perform the data import.

➡ Progress bars show which files are being imported and parsed.

To verify that background utilization has been applied, examine theBackground Utilization attribute for a link. The value shown in this attributeshould match the value shown in the general background utilization file.

Trf.9 Exporting Traffic

In addition to importing traffic in several formats, OPNET Modeler allows youto export traffic for viewing and editing.

Exporting Conversation Pair Traffic to a Spreadsheet

OPNET Modeler allows you to export conversation pair (routed background)traffic from a scenario to a tab-separated ASCII file, which can be viewed as aspreadsheet in an application such as Microsoft Excel.

To export conversation pair traffic to a spreadsheet...

1) From the Traffic menu, choose Export Conversation Pairs ➧ To Spreadsheet.

714-Trf

ASCII Traffic File Formats Modeling Concepts

2) In the Export Traffic Flows dialog box, set each option as appropriate. Thetraffic duration and time step should already be set, as they are calculated andset dynamically by OPNET Modeler. Each option is discussed below:

Traffic Duration - the total amount of time the traffic file should span.This is determined by the length of the conversation pair traffic in thescenario.

Time Step - the bucket size of the exported traffic.

Traffic Units - the units the exported traffic should be in. This can bespecified in bits/sec, Kbits/sec, Mbits/sec, or Gbits/sec.

Export traffic only for selected nodes - if you have selected nodes in thescenario and then check this option, only the traffic for these selected nodeswill be taken into consideration when the traffic is exported. This option isespecially useful if you want to view and edit traffic for a few objects.

Display file in spreadsheet program - if this option is selected, theexported traffic file will automatically be displayed in the programspecified by the spreadsheet_prog preference (environmentattribute).

Trf.10 ASCII Traffic File Formats

host: dummyhost

device: router

media: ethernet

time_origin: 08/13/1997 01:00:00

time_end: 08/13/1997 03:00:00

traffic:

WORKSTATION/128,ROUTER,[08/13/1997 01:00:00-08/13/1997 01:30:00],5,100




ROUTER,GTWY,[08/13/1997 01:00:00-08/13/1997 01:30:00],50,500

ROUTER,GTWY,[08/13/1997 01:30:00-08/13/1997 02:00:00],100,700

ROUTER,GTWY,[08/13/1997 02:00:00-08/13/1997 02:30:00],80,1323

ROUTER,GTWY,[08/13/1997 02:30:00-08/13/1997 03:00:00],30,752

NetMetrix (.tr1) File Format

715-Trf

Modeling Concepts ASCII Traffic File FormatsIm

po

rting

Netw

ork

Traffic

NetMetrix ASCII Traffic Format

Field Name Format

Source IP address

Destination IP address

Time duration <start date> <start time>-<end date> <end time>

Number of packets

Number of bytes

time_origin:0.0

time_end:3600.0

traffic:

source,destination,start_sec,end_sec,bits_sec,packets_sec

Glasgow LAN,London CPE,0,600,300000,200

Dublin LAN,London CPE,0,600,900000,800

Manchester LAN,London CPE,0,600,100000,70

London CPE,Glasgow LAN,0,600,450000,300

London CPE,Dublin LAN,0,600,600000,500

London CPE,Manchester LAN,0,600,90000,80

Edge 1,Edge 2,0,600,8000000,7000

Edge 1,Edge 3,0,600,8000000,7000

Edge 1,Edge 4,0,600,8000000,7000

.tr2 File Formats

716-Trf

ASCII Traffic File Formats Modeling Concepts

.tr2 File Formats (Cont.)

host: dummyhost

device: router

media: ethernet

time_origin: 08/13/1997 03:00:00

time_end: 08/13/1997 05:00:00

traffic:

source,destination,start,end,bits_sec,packets_sec

WORKSTATION,ROUTER,08/13/1997 03:00:00,08/13/1997 03:30:00,200,10




ROUTER,GTWY,08/13/1997 03:00:00,08/13/1997 03:30:00,1000,100

ROUTER,GTWY,08/13/1997 03:30:00,08/13/1997 04:00:00,1400,200

ROUTER,GTWY,08/13/1997 04:00:00,08/13/1997 04:30:00,2646,160

ROUTER,GTWY,08/13/1997 04:30:00,08/13/1997 05:00:00,1504,60

Importing Network Traffic - Suraj @ LUMSsuraj.lums.edu.pk/~te/simandmod/Opnet/11 importing...

Documents

Transcript of Importing Network Traffic - Suraj @ LUMSsuraj.lums.edu.pk/~te/simandmod/Opnet/11 importing...