Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Related Documentation

    Detailed Procedures

    For traffic collection to work properly and reconcile data to the correct router, several fields should be verified using the router profile connectivity check described in Test Profile Connectivity. Use the Profile Fix button to correct any mistakes in the hostname, community string, etc.

    Starting the Data Collector(s)

    1. If your data collection has not been started, then at the command prompt on the machine on which you installed the data collector (for example, /u/wandl/dcollect/dc.sh), type the following command shown after the “$” prompt:
      $ ./dc.sh start 1

      You should see start up messages indicating the process ID for the new data collector.

      Trying to start using pid=8608
      Data Collector (pid=8608) Started.

      The last input parameter of the dc.sh command specifies the instance number of the collector that is being started. In the above example, the instance number is zero (1). There can be more than one instance of the data collector running at once on the same server, so you may start another instance by selecting a different number.

    2. Multiple data collector instances can be started in sequence by using comma. The example below starts instance 2, 3, 5, and 7.
      $ ./dc.sh start 2,3,5,7
      Multiple data collector instances can be started as a range. The example below starts instance 0, 1, 2, 3, 4, and 5 inclusive.
      $ ./dc.sh start 0-5
    3. Execute the following command to see the status of the collectors running. In the following case, two data collectors have been started.
      $ ./dc.sh status
      Found collector instance wandl_0 with pid=8608 (running)
      Found collector instance wandl_1 with pid=8628 (running)
    4. If SNMP data collectors are to be connected to a different JMS host, then run:
      $ ./dc.sh start <instance#> -h <host_ip_address>

    Note that SNMP data collectors can be started with users other than “wandl” or the owner of the software installed.

    To check that a distributed data collector has been correctly registered on the Application server, check the /u/wandl/log/dgs.log.0 file on the application server for the line, “INFO: Collector registered”. Alternatively, check /u/wandl/dcollect/log/dcollect_wandl_<pid>.msg on the data collector machine.

    1. In the IP/MPLSView client, open the live network. Select Performance > Traffic Collection Manager. If this is the first time, you will be prompted to enter in the client-server communication IP addresses and ports for traffic collection as shown in the figure below. Enter the IP address of your JMS server and Task Manager and the port numbers if you are not using the default ports. The JMS server and Task Manager is typically started on the Unix machine on which IP/MPLSView was installed.

      Note: The Use HTTP Tunneling checkbox is used for JMS communications and normally should not be selected, except for scenarios with firewalls/NAT.

      Java Messaging Service (JMS) is a message middleware layer used to pass collected traffic statistics from the data collector(s) to the IP/MPLSView server.

      Figure 116: Client-Server Communication Parameters

      Client-Server Communication Parameters
    2. Click OKand the Traffic Collection Manager window will appear as shown in Figure Figure 117.
    3. If the Traffic Collection Manager does not appear and you have installed the IP/MPLSView client before, it could be due to incompatibility with previous installation. Try renaming the previous TrafficCollection.<server-IP-address>.xml file in your local user application data’s wandl directory. For example, “C:\Documents and Settings\<username>\Application Data\wandl” for Windows XP or “C:\Users\<username>\AppData\Roaming\wandl” for Windows Vista. Then reopen the Traffic Collection Manager. (Note that clearing out the old client side XML files was necessary in older versions, but may not be necessary anymore.)

    Distributed Data Collection

    For larger networks, distributing the data collectors across a few machines can result in greater efficiency. Otherwise, the performance of the IP/MPLSView server may be slowed down. A general practice is to use a different traffic data collector for every 100 to 150 routers. (Note that this is a general guideline. The load imposed on the traffic collector is really dependent on the number of interfaces and tunnels.)

    To run a data collector on another server, you need to install the data collector on that server. Simply run the install.dcollect script that is located within the dcollect folder from the installation CD or directory.

    Note: You should install using the same user ID that will be executing the dc.sh (for example, wandl).

    During the installation process, you will be prompted for the “JMS server”. Here you should specify the server on which the main IP/MPLSView program was installed. In the following example, the user is installing a distributed data collector on 192.10.20.109. The JMS server is 192.10.20.213. After this data collector is started on the 192.10.20.109 machine, it should appear automatically after a minute or so within the IP/MPLSView Traffic Collection Manager graphical interface. The following is an example of the dcollect installation procedure. Press <ENTER> to accept the defaults:

    Please enter the root directory where this software will be installed
    (default=/u/wandl) /u/wandl/213_dcollect
    Checking for necessary disk space
    Extracting files, This may take a few seconds
    PLEASE WAIT...................
    Copying Files ...
    For this part of the installation, you need to supply the name of the server to which you are connecting (default is the local machine) and the port number for communication (default is 7000).
    If you don't know this information, ask the person who installed the server portion of the software, or just take the defaults. You will always have the chance to change them by editing the file /u/wandl/213_dcollect/dcollect/dc.sh.
    Please supply the name or IP address of the JMS server [ 192.10.20.109 ] 192.10.20.213
    Please supply the JNDI Port [ 1856 ]
    ********** INSTALLATION COMPLETE **********
    You may run the Data Collector by executing
    /u/wandl/213_dcollect/dcollect/dc.sh start 0

    Data collectors running on a different machine than the main server should obtain a separate npatpw license for placement into the /u/wandl/dcollect/db/sys directory.

    For users with multiple concurrent user license:If after you have started a data collector (for example, data collector 0), you wish to change the IP address of the JMS server, you may also manually edit the file(s) in the dcollect directory with a name similar to “dcconfig_wandl_0.xml”, where “wandl” is the userID of the installer/executor, and 0 is the instance number. First, stop the corresponding data collector using “./dc.sh stop n”, where n is the data collector number. Then, in the “dcconfig_wandl_0.xml file, simply look for the line similar to the following, and replace the IP address with that of the IP/MPLSView server you wish to use: <JMSURL>jnp://192.10.20.213</JMSURL>

    Finally, restart the data collector using “./dc.sh start n”, where n is the data collector number.

    Setting the Collection Elements

    Figure 117: Traffic Collection Manager

    Traffic Collection
Manager
    1. On the first tab called Collection Elements, double-click on the “Collectors” sub-item on the left pane of the window to see the data collectors that are running. Click on the “Free Routers” sub-item on the same pane to see the routers that exist on the network.
    2. Using this Traffic Collection Manager, you may create groups of routers and then assign a different data collector to each group for load distribution. Create a router group by right-clicking on the item “Global Network” and selecting Add New RouterGroup.
    3. Select the created router group and edit its name on the “Properties” pane of the window. To do that, go to the “Router group description” entry of the table and double-click on the value box. Modify the name when you see the blinking cursor in the textbox. Hit <Enter> to finish the edit.
    4. Assign a data collector to this new router group by right-clicking on the router group name on the left pane. Click on Set Collector from the pop-up menu and select a data collector from the list. Alternatively, you may also click on the collector from the “Collectors” list, then drag and drop it into the router group.
    5. You can add a router to the router group by adding a new router, or selecting a router from the profiles list in the Task Manager. To add a new router, right-click on the router group and select Add New Router. A new router entry will appear inside the router group. To edit its properties, click on the name of the new router on the left pane and modify its properties on the right pane by double-clicking on the value fields.
    6. To add a logical router, right-click on the router group and select Add New Router. For the Router IP, enter the loopback IP of the logical router. For the Secondary IP, enter the management IP of the physical router. For the SNMP GET port, use 161. For the SNMP GET community string, use the logical-router-name/default@community-string statement , where the variables logical-router-name and community-string are the actual names defined in the configuration file.
    7. To add a router from the profile list generated by the Task Manager, select Add From Profile when right-clicking on the router group. Select the router profile from which you wish to add from, and all the routers in that profile will automatically be added onto this router group.

      Note: If the Free Router list already has the routers in the profile list, it will not be added to the router group. You must drag and drop that router from the “Free Routers” list to the router group manually.

    8. To remove a network element (a router or a data collector) from the router group, select the element and right-click to select Remove.This will not actually delete the element entirely, but will move the router to the “Free Routers” list. To delete the network element from the database entirely, right-click and select Delete, or select the delete button on the toolbar at the top of the window (the trash can icon). When changes are saved later, the settings on the server will also be deleted permanently.

      Figure 118: Toolbar Start, Stop, Refresh, Delete, Save, and Undo Items

      Toolbar Start, Stop, Refresh, Delete, Save, and Undo
Items
    9. Sometimes the client view of a collection element needs updating when changes are made. To update the element, select the element(s) and click on the refresh button at the toolbar (the two arrows). Alternatively, you may select Refresh from the right-click popup menu.

      Note: When the Refresh button is selected for Free Routers or Collectors, it will update only the number of sub-elements. It will not, however, refresh each individual collector.

    10. To edit more than one network element simultaneously, highlight the group of elements in the tree view and edit them as normal in the property table. Note that if the elements all have the same value for a given property, that property will have a value in the property table during a group edit. However, if any one of the elements has a disparate value, the value will not appear. Any property that is set for the group edit is set for every element in the selection.

      Figure 119: Traffic Collection Manager with Router Groups and Collectors

      Traffic Collection Manager with Router Groups and Collectors
    11. Once changes are completed in the Collection Elements tab, click on the save button on the toolbar to save any changes to the server (the disk icon).

      Note: As a precautionary measure, save any series of extensive changes. When any changes are made to the client, only the last three buttons are enabled (delete, save, reset) while the changes are pending.

    12. Click the reset button if necessary to undo all the changes since the last save (the last button on the toolbar with the back arrow icon). The client will return to the “saved” state, which allows for starting/stopping the collection and refreshing an element.
    13. To search for a router within the list, right-click on Global Network and select “Find Router in Group”. This will highlight the corresponding network element. Note that if “Find Router in Group” is selected for a particular router group, rather than the Global Network, then the search will be restricted to that group.

    Modifying Collection Parameters

    Traffic collection settings include (a) global properties like the collection interval, (b) device-specific properties like the collection method, (c) device group properties to specify what to do with the devices in a group if the collector for that group fails, and (d) collector properties.

    Global Properties

    Click on the Global Network item from the left-pane and set the Traffic collection interval (seconds). (It is best to set it at multiples of 300(sec) – 5 minute interval.). If no value is set for the interval (the interval is set to zero seconds), then “Global Network” will be shown in red, indicating there is still some incomplete information.

    Device Properties

    Make sure that the Router Type is not GENERIC. It should match the correct hardware vendor family of the router. For certain families within the same vendor, it is necessary to explicitly specify that family. For example, for CISCO ASA devices, the router type CISCO_ASA should be specified rather than CISCO. For Cisco IOS-XR, the router type CISCO_IOX should be specified rather than CISCO.

    Figure 120: Router Fields

    Router Fields

    To specify the Collection Method (SNMP, CLI, Bulkstats), select one or more routers from the left hand side. Then, on the right hand side, double click on the row in the Value column corresponding to Collection Method and choose the method from the drop-down menu. Normally, SNMP is used for the traffic collection method. However, CLI can also be used for Juniper, Cisco, Redback, and ERX as a means of reducing SNMP processing at the routers. Bulkstats is supported for Redback, Juniper, and ERX, and requires a license as well as special advanced configuration. Please refer to Configuring Bulkstats Traffic Collection (Advanced) on page 181 or contact Juniper support for more details on bulkstats.

    Make sure that all the SNMP attributes are present in the router profile when SNMP method is chosen and CLI attributes when CLI method is chosen. Specify the exact router type, as the information will be used to send appropriate vendor-specific commands to the router and parse the data collected from them. (Note that for the CLI method, the current supported vendors include Cisco, Juniper, Juniper-ERX and Redback devices.)

    By default, the traffic collection will collect both iftable and ifxtable for interface traffic. Select the cell to the right of List of Collection tables to bring up the following window. Here you can additionally specify if you want to collect COS (class of service) and MCAST (multicast) traffic. Options may vary depending upon the hardware vendor. Additionally, if you want to collect only iftable and not ifxtable, you can uncheck IFX.

    Figure 121: Choose Collection Tables

    Choose Collection Tables

    Some of the dependency relationships are described at the bottom of this window. Note also that certain categories are only available for SNMP collection method.

    The Max Collection Time (seconds) is used to set the max collection timeout. For a router with a lot of interfaces, tunnels, and VPNs, it is better to set this number to high value.

    Router Group Properties

    Click on each Router Group to configure settings related to the router groups, as shown in the following image.

    • Enable Router Group Failure:If this checkbox is selected, it means that if the data collector for this group fails, this group can be reassigned to be collected by another collector. This option should be unselected for a group of routers which is collected using Bulkstats. It should also be unselected if you want to avoid collecting for this group of routers and have stopped the data collector on purpose.
    • Is this Group for Bulkstats Collection?:Select yes, if this group is being used for Bulkstats collection. Routers that are to be collected using the bulkstats method should be added to groups with this checkbox selected.
    • Do not split Group on Failover:This option is only effective when you check the above Enable Router Group Failover option. Checking this option, all the routers in a group will be switched together as a group into the same active group during collector failures. Otherwise, the routers will be distributed to several active groups when you leave the option unchecked.

      Figure 122: Router Group Settings

      Router Group Settings

    Traffic Collector Properties

    • Maximum # of collection threads: The max number of parallel threads can be executed at the same time. The default value is 20.
    • Maximum collection wait queue size:The queue used to store collection jobs (in general, one router element collection is one job) to be processed by data collector threads. The default value is 200.

    Save all changes before starting data collection, by pressing the Save button (the diskette icon).

    Starting the Traffic Collection

    A complete network, ready for traffic collection, requires a Global Network with at least one router group for collection, with every router group having a data collector and at least one router, a valid collection interval (best to set at multiples of 300(sec) – 5 minute interval) and MIB data set from the Collection Data panel. Best practice would suggest creating a router group for every data collector and limit the number of routers to about 100 to 150 per collector, though it can probably handle more.

    To start collection, press the Start button, which is the first button on the toolbar. The server will then initiate a collection session on each collector associated with a router group. Currently, there are no means to start collection for just one router group, as the network is collected as a whole.

    To stop collection, press the collection stop button (second button on toolbar).

    Note: Collection will continue even if the client is shut down, as long as the collectors and the DGS are running. Even the DGS can be shut down for brief periods ( < 10 minutes) while still ensuring a continuous data stream because the data messages sent by the collectors are stored in message queues. As long as the messaging server is running, these messages will be available to the DGS for processing.

    Be advised that any changes made to the collection elements in the client will affect the running collection upon saving, that is, removing a router from a router group will remove that router from collection, deleting a router group will terminate the corresponding collection session on its associated data collector.

    Collection Status

    After collection has started, click on the Collection Status tab to monitor collection events. Any errors, warnings, and updates, including “traffic collected” events will appear there. There is a limit to the number of events displayed in the event table. To clear the events in the table, press the reset button. Note that this only resets the events table and not any element changes made in the client.

    To check the collection status, go to the Collection Status tab. Clicking on an entry will also show expand the Short Description column in the Status Detail panel at the bottom of the window

    Figure 123: Collection Status Panel

    Collection Status Panel
    • An Event Type of “warning” (severity MINOR) will be highlighted in green by default, such as the “Task already queued or running, skipping:10.30.0.1” This message may be an indication that the router is still busy servicing the prior request.
    • An Event Type of “error” (severity MAJOR) will be highlighted in red by default. For example, an error’s description might be “[108.5.5.5] Timeout: No Response from 108.5.5.5” This indicates that the 108.5.5.5 router is not reachable.
    • An Event Type of “normal” (severity INFO) will not be highlighted by default. A typical Status Type is “CollectionUpdate” indicating that the rest of the collection is running smoothly. Another one is “CollectorRegister” and “CollectorStart” , that appears once the user has started up a new data collector.

    Collection Settings

    The last tab, Collection Settings, allows the user to set different settings for the Traffic Collection Manager, such as the color settings from (Master Collection Panel > Panel - Collection Status).

    Figure 124: Settings for Status Window

    Settings for Status Window

    Troubleshooting

    Test Connectivity

    Verify the data collector can reach and gather data from the routers with the Test Connectivity tool. Right-click on any router(s) in a Router Group and select Test Connectivity.Test Connectivity will run Ping, SNMP, and CLI tests on the router(s) for reachability, SNMP configuration, and CLI login access. If any of the tests fails, review the settings in the Properties panel or the Router Profile. Note that the Test Connectivity tool only works for a complete Router Group with an assigned data collector.

    Figure 125: Test Connectivity

    Test Connectivity

    Problems in the Traffic Collection Manager

    Figure 126: Red Lettering: A Warning Sign

    Red Lettering: A Warning Sign

    In order for the traffic collector to return live updates, you must have first run a “Scheduling Live Network Collection” task from the Task Manager as described in Chapter 7,Live Network Collection before performing the traffic data collection. Without this step, many SNMP Errors may arise in the Collection Status window. If within a couple minutes, you do not see any Status “Normal” Traffic Collecting messages in the Collection Status window, please restart the application, check in the Task Manager that the Live Network Collection has been performed and try the data collection once again.

    Once the Collection Elements and Collection Data have been set, either the Start button (the triangle icon on the toolbar) or the Stop button (the square button on the toolbar) should be enabled. If the Stop button is enabled, this means that the collection is already in progress. If neither button is enabled, check the following:

    Red Lettering

    Make sure that there is no red lettering in the Collection Elements panel. Red lettering indicates that some part of the user-supplied information is incomplete. For example, in Figure 126, the “Global Network” is in red lettering, indicating that at least one of the router groups has an incomplete setting. The router group named “WestGroup” is also in red lettering, indicating it has an incomplete setting. Traversing down the tree, notice that there is a router element in WestGroup also in red lettering “<unknown> - 129.1.1.1”.

    • Incomplete/Incorrect Router Entry- By clicking on a collection element in the left panel, you can see if there are any required properties that need to be set by examining the Properties panel on the right. An asterisk will precede the incomplete property name in the right-hand property table. In Figure 126, there is an asterisk besides “Router name”, corresponding to the “<unknown> - 129.1.1.1” entry. Clicking in the Value column and assigning a router name will cause the “<unknown>” entry to refresh and the red lettering disappears. However, “WestGroup” remains in red lettering, indicating there is still an incomplete setting. If there is still a red mark, check that the SNMP community string is correct, the router vendor is correct, and that the router is reachable via ping.
    • No Data Collector Assigned- The other reason that data collection is not ready to start is because no data collector has yet been assigned to this router group, as is the case in Figure 126. Right click on the router group and set the appropriate collector. If Set Collector is grayed out, this means that no collectors have been started and you must start one, as described in Starting the Data Collector(s) on page 155.
    • No Traffic Collection Interval Specified.- If the traffic collection interval is not set (or set to zero seconds), this will also cause “Global Network” to be displayed in red lettering. In the Collection Elements tab, left-click the mouse on the words “Global Network”. In the Properties panel on the right, an asterisk will precede the Property, “Traffic collection interval (s)” to indicate that a value is required before the collection can begin. It is recommended to specify a collection interval of some multiple of 300 seconds (5 minutes).

    Collector with a Red “X”

    A collector with a red “X” may indicate that the collector is not running. Click on the collector and the Properties pane at right will indicate whether it is running or not. If not, run the data collector dc.sh as described in Starting the Data Collector(s) on page 155.

    Data and Elements Not Saved

    Settings must be saved in order for the collection to begin. Make sure that in both the Collection Elements and Collection Data tab, the Save button (diskette icon on the toolbar) has been pressed. Make sure that at least one MIB collection variable has been selected into the right panel of the Collection Data tab.

    Specifying Traffic Aggregation Options

    By default, hourly and daily aggregation of traffic is performed and is viewable through the web reports.

    1. To set up regular traffic aggregation by a different interval, select Admin > Task Managerand then select the New Task button. Select the Aggregated Traffic Report task and click Next.

      The Aggregate Type options include:

      • Yesterday (for daily aggregation)
      • Last week (Mon~Sun) for weekly aggregation, using Monday as the beginning of each week
      • Last week (Sun~Sat) for weekly aggregation, using Sunday as the beginning of each week
      • Last n days: Select the number of days
      • Last Month: Monthly aggregation, that is, represent each month by one set of statistical values instead of 30.
      • Range: Select the range of days.

        To select which types of statistical values to calculate select it from the Fields section. For example, the Linkname, # of Samples, Average, Max, and 95% are selected by default.

        Figure 127: Aggregated Traffic Report

        Aggregated Traffic Report
    2. Under Misc, you can select to Remove Data older than ___ days to reduce the disk storage requirements.
    3. Select “Use Egress Only”to report on only egress traffic rather than ingress traffic.
    4. ClickNext. In the Schedule Task pane, make sure to select an interval as frequent or more frequent than the aggregate type chosen.
    5. To view the results from the IP/MPLSView Web Interface, go to Live Network > Performance Management > Aggregated Traffic Reports.

    Viewing Collected Data

    1. Close the Traffic Collection Manager by clicking on the X symbol at the upper-right corner of the window.
    2. On the Live Network topology window, click on Live Util legend to see the fraction of the link that is actually being utilized in Layer 3. You can scroll the bars in between colors on the Live Util tab to change the legend.
    3. Right-click on a link and select Live Interface Loadto view the traffic data. Note that two charts will be displayed, one for each node/interface on the link. Each chart has an A->Z and Z->A tab. In this way, you can compare the A->Z results on one end of the link with the Z->A results on the other end of the link. Options are also available from this window to view the CoS and multicast traffic, in case CoS or multicast traffic collection was configured in the Traffic Collection Manager.
    4. If there are MPLS-TE tunnels in the network, right-click on a link and select Interface vs Tunnelto compare the traffic on the interface to the traffic on the tunnel, which should be similar.
    5. You can press the Tunnel layer button on the main menu bar to see the tunnel traffic live utilization. Press Layer 3 to see the interface traffic live utilization.

      Figure 128: Switching Between Tunnel Layer and Layer 3

      Switching Between Tunnel Layer and Layer 3
    6. Select Network > Elements >Links.Right-click the table header and select Table Optionsto add live network utilization and bandwidth information items (for example, Live_L2_Util_AZ, Live_L3_Util_AZ, Live_L2_BW_AZ, Live_L3_Util_AZ, and likewise for the opposite direction).
    7. Right-click on a link to see a Traffic Charts menu with a number of options for traffic charts.
    8. Select Network > Elements >Tunnels.Right-click the table header and select Table Options to add the column Traf to view traffic bandwidth.
    9. To see a traffic record, go to Performance > Traffic Charts.
      • Select Total Network Tunnel Trafficto get the total tunnel traffic data.
      • Select Total Router to Router Tunnel Traffic to get the total tunnel traffic between two routers. Then click the source and destination router on the map.
      • Select Total Router Tunnel Trafficto get the total ingress and egress tunnel traffic for a router. Then click the router on the map.
      • See Figure 129 for a sample chart of Total Network Tunnel Traffic
      • To zoom in, click and drag across the data. Once zoomed in, the bottom scrollbar will become active and you can scroll the data. The Reset Zoom icon will also be activated, which you can use to reset to the original zoom level.

        Figure 129: Daily Tunnel Traffic Data for 6/17/2002

        Daily Tunnel Traffic Data for 6/17/2002

        Note that the starting date can be changed using the first calendar icon (“Settings” icon), and the range (daily, weekly, monthly, or yearly) can be changed using the second calendar icon.

        Figure 130: Choose a Date Window

        Choose a Date Window

        Figure 131: Choose a Date Range (Daily, Weekly, Monthly, or Yearly)

        Choose a Date Range (Daily, Weekly, Monthly, or Yearly)

    Viewing Through the Web Browser


    You can also view traffic data via the IP/MPLSView Web interface. To access the IP/MPLSView Web interface from the IP/MPLSView application, select File > Launch Web.

    Alternatively, to directly access the web, open your web browser and type in the address http://server_host:8091, replacing server_host by the IP/MPLSView server’s IP address or hostname. You should log in with the user account and password provided to you by your administrator. Once logged in, you can view charts for router to router traffic, network tunnel traffic, interface traffic, and individual tunnel traffic. These can be accessed under the menu for Performance Management.


    Viewing the Traffic Replay


    The traffic data collected using the live Traffic Collection manager can also be replayed.

    1. Select the Utilization Legends > Interface CoS Util.

      Figure 132: Interface CoS Util Legend

      Interface CoS Util Legend
    2. Alternatively, if you wish to query a different time range, click the Offline button. Next, select Traffic > Traffic Load. This will bring up the Load/Util window displayed in Figure 133.

      Figure 133: Traffic Replay in Offline Mode (Options May Vary)

      Traffic Replay in Offline Mode (Options May Vary)
    3. In Layer 3 mode, you will see an Interface radio button. In Tunnel layer mode, you will see a Tunnel radio button instead. Click on the Interface/Tunnel radio buttons. The bottom panel will become enabled, allowing you to select the period of time to begin the replay of traffic data. In this panel, you must specify the Start From date as well as an Interval time period. Then, click the Fetch button. This will fetch the results from the Traffic Collection database and load the traffic data into the topology map for display. Note that the aggregation statistic performed on the data is based on computation of the Average.
    4. Clicking on the Run button now allows you to view the traffic utilization on the topology map over 24 consecutive intervals, starting from the starting date and time, and spaced out by 24 Interval time intervals. If the online traffic data collection was performed with 5-minute samples, and in the offline Load/Util replay window in Figure 133 you specify an interval of 30 Minutes, then the results displayed for each 30 minute interval will be the strict average of the corresponding six 5-minute intervals. Note that the raw data at the specified interval (for example, 5 minute interval) is only stored for a given period of time, which can be configured in the agg.xml file as explained in Traffic Data Archival and Cleanup. After that period of time, the data is aggregated into one data point per day, which can be viewed through the historical web charts.
    5. You can also view per-link traffic statistics by right clicking on a particular link on the topology map. In the popup menu in Layer 3, select Traffic Load > Measured Interface Traffic.In the popup menu in the Tunnel Layer, select Traffic Load > Tunnel Traffic on Link. This will bring up a 24-period barchart displaying the interface/tunnel traffic utilization, respectively, on either direction of that link over the 24 intervals.
    6. To view the trafficload file, save the network to a different directory from File > Save Network... Then navigate to that directory from the File Manager and view the interfaceTraffic.in.x and interfaceTraffic.out.x files for interface traffic or the T_trafficload.x for tunnel traffic.

      For more information about the other options available in the Load/Util window, please consult “The Traffic Menu” chapter of the General Reference Guide.


    Create a 24-Hour Trafficload File


    To create a 24-hour traffic load file for offline analysis, use the Traffic > Traffic Aggregation window. For more information, see Traffic Aggregation.


    Data Collector Logs


    Logs for the Data Collector can be viewed under /u/wandl/log/.

    • dgs.log.n for logging output
    • dgs.msg for exceptions
    • dgsMSG.log.n for a full trace
    • dgsTASK.log.n for data flush info
    • dgsDB.log.n for database logs

    Log levels can be configured in /u/wandl/db/confis/dgs.xml

    Traffic Data Archival and Cleanup

    By default, raw traffic will be accessible at the scheduled interval (for example, 5 minutes) for the last 35 days. Beyond the 35 days, there will be only one data point per day. Accumulated traffic data is stored and gzipped under /u/wandl/data/traffic.archivefor a certain number of days (35 by default).

    If this setting uses up too much disk space, the parameter archiveCapacity (35 by default) can be edited in /u/wandl/db/config/agg.xml to a smaller number. For proper display of historical traffic charts from the web, any changes to this value in the agg.xml file should also be made to the parameter archiveCapacity in /u/wandl/web/wandl/WEB-INF/web.xml.

    If disk space is running low, a cron task can be setup to remove or backup old archive files. To set up a cron job, switch to root user. Run the command “crontab -e”. An example entry for removing old archive files at 1:00 AM every day (before aggregation, which is usually set to run at 2am) is as follows:

    0 1 * * * rm /u/wandl/data/traffic.archive/*

    Archive files will contain the raw data at the scheduled interval (for example, 5 minute default). After being archived, this data can be accessed via mysql commands.

    By default traffic data older than 100 days is purged.

    Traffic aggregation logs are stored in /u/wandl/log:

    • agg.log.n:Logging output from the Aggregator. Edit log levels in /u/wandl/db/config/agg.log.properties file. This rotating log is 500KB max.
    • agg.msg:Includes stdout and stderr output. All exceptions will appear here.
    • aggTASK.log.n:Data flush capture
    • aggDB.log.n:Database access log with full trace of all SQL queries

    To change log levels, edit /u/wandl/db/config/agg.xml

    Delete Interfaces from Traffic Database

    When interfaces or tunnels are no longer active and collecting traffic data, you may want to delete them from the traffic database to save disk space and remove them from appearing on the web reports. The following steps describes the procedure to delete interfaces and tunnels from the traffic database.

    Identify the routers and interfaces or tunnels you want to delete.

    This next step for running the Check Traffic Data script using command “/u/wandl/bin/check_trafficdata.sh <parameter> <filename>” is optional.


    Check Traffic Data Script


    The Check Traffic Data script will display interfaces or tunnels with no traffic or unknown traffic data collected by the data collector and not in the router configurations. The purpose is to help identify interfaces not in the Live Network that has no useful traffic data. The script requires the intfmap.x file or the tunnel.x file. The following descriptions are parameters of the script:

    • -i pathname of the Live Network intfmap.x file. Normally located at /u/wandl/data/.network/intfmap.x
    • -t pathname of the Live Network tunnel.x file. Normally located at /u/wandl/data/.network/tunnel.x
    • -n the last n days. Default value is 30.
    • -r -1 or 0. -1 searches for -1 values only which indicates unknown traffic data. 0 searches for 0 and -1 which indicates no traffic and unknown traffic data respectively. Default value is -1.
    • -w is the default wandl home path /u/wandl
    • -d is the default path of the interface or tunnel files

      Example execution of the check traffic data script:

      Example execution of the check traffic data script:
      # /u/wandl/bin/check_trafficdata.sh -i /u/wandl/data/.network/intfmap.x -n 10
      # intfmap: /u/wandl/data/.network/intfmap.x
      # wandl home: /u/wandl/
      # Checking: last: 10 day(s)
      # Report intfmap with all: -1 only
      # Data directory: /u/wandl/data/traffic_history/dbinterface
      EX1,pime.32769
      BEK3640,ATM0/0-atm
      BEK3640,ATM0/0.0
      BEK3640,ATM0/0.0-atm

      The script output displays the router name, interface name meeting the parameter conditions. The results require finding the -r value on every traffic entry during the last -n value days. In the above example, this means for the last 10 days router BEK3640 at interface ATM0/0.0 had value -1 or unknown traffic data.

      1. Stop Application Monitor using command “/u/wandl/bin/.appmonitor stop”
      2. Stop DGS using command “/u/wandl/bin/.dgs stop”
      3. Verify DGS has been stopped using command “/u/wandl/bin/status_mplsview”.It should return a warning message that DGS is not detected.
      4. Stop all the data collectors using command “/u/wandl/dcollect/dc.sh stop all”
      5. Run the Interface Cleanup script using the /u/wandl/bin/intf_cleanup_util.sh <filename> command.

    Interface Cleanup Script


    The Interface Cleanup script will parse the input file and then generate a SQL command to delete the interfaceID from the traffic database. The input file format has 3 parameters for search condition, router name, and interface name.

    Example input file:
    #e/r,router name,interface name
    e,ATL,ge-0/0/0.1
    r,ATL,ge-0/0/[0-9]\\.1
    r,ATL,lsi\\.[0-9]*
    First column parameter is e or r. e searches for an exact match and r searches
    using mySQL regular expression. The regular expression search only applies to
    the interface name.
    Second column is the router name. It requires an exact match.
    Third column is the interface name. It accepts mySQL regular expressions.
    Example execution of interface cleanup script:
    # /u/wandl/bin/intf_cleanup_util.sh deleteintf.test
    ** 2 interfaces are matched, do you wish to see the result? [y/n] (default=yes)y
    EX3 vme 232
    EX1 bme0.32768 545
    *** Do you wish to delete these interfaces from database? [y/n] (default=no)y
    *** Are you sure to delete these interfaces from database?, it is not
    reversible! [y/n] (default=no)y
    Preparing SQL statement to delete the interfaces...Done.
    Command generated:
    delete from WInterface where interfaceID in (232,545)
    About to execute the delete command, procceed?[y/n] (default=no)y
    Successfully deleted interfaces from the database!

    This next step for applying a Data Collector Exclusion Pattern is optional.

    Data Collector Exclusion Pattern

    This will apply a rule to the data collector to drop the interface data after collection. This prevents the interface from getting an interfaceID in the traffic database. Go to directory /u/wandl/dcollect and edit the data collector configuration file using any text editor. Search for the <EXCLUSION_PATTERN> tag and enter the interfaces to exclude. It accepts Java regular expressions.

    Example data collector exclusion pattern configuration edit:

    Example data collector exclusion pattern configuration edit:
    # vi dcconfig_wandl_21.xml
    <EXCLUSION_PATTERN>vme||bme.*</EXCLUSION_PATTERN> 
    1. Start DGS using the /u/wandl/bin/.dgs start command.
    2. Start Application Monitor using the/u/wandl/bin/.appmonitor start command.
    3. Start the data collectors using the /u/wandl/dcollect/dc.sh start all command.
    4. Confirm the interfaces or tunnels are properly deleted by checking the web traffic reports.

    Selective Interface Traffic Collection

    The default traffic collection method collects all interfaces on the router. This method may result in collecting unwanted or junk interfaces from the router which gets added into the traffic database and performance management web reports. These extra interfaces may have no significance or use to network operators. The Selective Interface Traffic Collection method allows you to specify exactly which interfaces to collect or not to collect.

    Input Files

    To use the selective interface traffic collection method, you need to define the interfaces to collect or not to collect. The interfaces to collect traffic data are defined in three text files interface.attributes, interface.rules, and interface.user in /u/wandl/db/config directory. By default these three text files are initially empty. Example format and syntax for each file is found in files interface.attributes.template, interface.rules.template, and interface.user.template respectively.

    You may use any combination of these three file. When more than one file is used, the priority of the interfaces definitions from highest to lowest goes user > rules > attributes. Example, you have attribute definition collecting all physical interfaces which returns fe-0/1, ge-0/2, and you have user definition not collecting any fe interface, then the interface collected will only be ge-0/2 because user definition has highest priority.

    Some of the fields in the input files support regular expression, see each file description. The links below are references for using regular expression syntax.

    • http://www.regular-expressions.info/reference.html
    • http://msdn.microsoft.com/en-us/library/1400241x%28v=vs.85%29.aspx

    Interface.attributes


    The file interface.attributes is a list of attributes in the network model. The file format is attribute property, collection option. The attribute property is determined by the simulation engine and should not be edited. The collection option takes parameters Y, N, or ACTIVE. Y means collect, N means do not collect, and ACTIVE means collect if both operational status and admin status are up when the selective interface process queries the routers.

    Default settings in the interface.attributes.template file:

    FIXLINK,Y
    PHYSICAL,Y
    LOGICAL,N
    PhysicalWithSubInterface,N
    BACKBONE,Y
    BGP,N
    VLAN,N
    VPN,N
    CISCOTUNNEL,Y
    • FIXLINK is a special IP/MPLSView file that allows you to specify nodes, links, and interfaces that cannot be auto discovered from the Task Manager. All interfaces in fixlink.x file.
    • PHYSICAL are physical interfaces. All interfaces in intfmap.x file without dot or colon extension in the name.
    • LOGICAL are logical interfaces. All interfaces in intfmap.x file with dot or colon extension in the name.
    • PhysicalWithSubInterface will include the physical interface if any of it's logical interface is collected. Example, if logical interface ge-0/1.1 is collected, then also collect physical interface ge-0/1.
    • BACKBONE are interfaces used in the backbone. All interfaces in bblink.x file that are not type ASLINK.
    • BGP are interfaces configured for BGP. All interfaces in bblink.x file that are type ASLINK.
    • VLAN are interfaces configured for VLAN. All interfaces in intfmap.x file with intf_type vlan.
    • VPN are interfaces configured for VPN. All interfaces in intfmap.x file with VPN-List entry.
    • CISCOTUNNEL are cisco interfaces configured with tunnels. All cisco interfaces in intfmap.x file beginning with keyword Tunnel.

    Interface.rules


    The file interface.rules allows you to define interfaces by hardware vendor to collect or not to collect traffic data. The file format is collection option, vendor, OS, hardware type, interface name, comment. All the fields except the collection option supports regular expression.

    • collection option takes parameter add, remove, or active. add means collect, remove means do not collect, and active means collect if both operational status and admin status are up when the selective interface process queries the routers.
    • vendor is the hardware vendor such as Cisco and Juniper.
    • OS is the operating system name such as IOS and JunOS. This field is optional.
    • hardware type is the hardware type such as Cisco 3640 and Juniper J320. This field is optional.
    • interface name is the interface name used in the ifDesc field from the ifTable.
    • comment is the comment field from the intfmap.x file. This field is optional.

      Sample interface.rules definition below will not collect any interface name starting with lsi from Juniper J2320 routers.

      remove,Juniper,JunOS,J2320,^lsi.*

    Interface.user


    The file interface.user allows you to define interfaces by node to collect or not to collect traffic data. The file format is collection option, node name, interface name. All the fields except the collection option supports regular expression.

    • collection option takes parameter add, remove, or active. add means collect, remove means do not collect, and active means collect if both operational status and admin status are up when the selective interface process queries the routers.
    • node name is the node name listed in the .diag profile in /u/wandl/data/.TaskManager/tmpdirectory. The .diag profile differs from the Router profile in that the routers listed in .diag are confirmed routers that are reachable by SNMP.
    • interface name is the interface name used in the ifDesc field from the ifTable.

      Sample interface.user definition below will collect any interface name starting with Ethernet on any router containing name 3640, and will not collect any interface name starting with lsi from router J1.

      add,^.*3640.*,^Ethernet.*
      remove,J1,^lsi.*

    Output Files


    After setting the interface definitions by editing the input files, the selective interface manager will generate files for interface index monitoring, and files for the data collector to identify which interfaces to collect traffic data. These files are under /u/wandl/data/selectiveInterface/fromAPPand should not be edited. These files will also automatically be copied to the data collector server under DCINSTALLROOT/selectiveInterface/fromApp,where DCINSTALLROOT is the install directory of the data collector.


    Ifindexfile


    The file ifindexfile contains a list of nodes and interface indexes for the data collector to collect traffic data. This file will intelligently update when there are changes to the network model, changes to the interface definition files, or interface index changes on the router potentially caused by the router rebooting. To manually rebuild this file, use command /u/wandl/bin/selectiveIntfList.sh


    Ifindexfile.withIfDesc


    The file ifindexfile.withIfDesc contains a list of nodes, interface indexes, and the interface description.


    Ifindexfile.withIfDescAllIntfsLR.csv


    The file ifindexfile.withIfDescAllIntfsLR.csv provides a mapping of logical routers to physical device and is used by the event server and event browser.


    Node.ifinfo


    The file node.ifinfo contains a list of interface indexes and interface name per node. This file is used for interface index monitoring.


    Distributed Data Collector Server


    If the data collector package is installed in a distributed environment, then automatic ssh login and Rsync packages are required to be configured and installed on both the application server and data collector server. The ssh login between the application and data collector server should be configured for wandl user (not root user). See the Getting Started Guide, Installing Replication and Rsync chapter.

    1. During installation of the data collector package, you will be prompted to configure data collectors for selective interface. Enter Y to configure or you can configure at a later time by using /u/wandl/dcollect/bin/configureSelectiveIntf.shcommand.
    2. The installation will prompt for the location of the data directory on the application server which by default is /u/wandl/data
    3. The installation will prompt for the IP address of the application server. Be sure to change the IP address when installing in a distributed environment.

    Configuration


    Configuration of the data collector to use the selective interface traffic collection method can be done during the data collect package installation or by using /u/wandl/dcollect/bin/configureSelectiveIntf.shcommand. The configuration will prompt for the location of the data directory on the application server which by default is /u/wandl/data.

    The default polling interval for the selective interface manager to detect changes in the network model, interface definition files, and router interface indexes is set to 900 seconds (15 minutes). This setting can be changed in /u/wandl/db/config/selectiveintf.xml by editing the value in <POLLAPPTASK_FREQUENCY_SECS>. Typically this value should not be changed.


    Start Selective Interface Method


    The following steps describes the process to start using the selective interface traffic collection method. All steps should be done as wandl user:

    1. Create interface definitions by editing the input files.
    2. Optional step to manually build ifindexfile using command. Otherwise the ifindexfile will automatically build within 15 minutes on default settings.

      /u/wandl/bin/selectiveIntfList.sh

    3. Configure the data collector to use selective interface using command

      /u/wandl/dcollect/bin/configureSelectiveIntf.sh

    4. Startup the selective interface manager using command

      /u/wandl/bin/.selectiveintf start

    5. Verify the ifindexfile is generated by using command

      cat /u/wandl/data/selectiveInterface/fromAPP/ifindexfile

    6. Start data collector instance using command where # is an integer

      /u/wandl/dcollect/dc.sh start #

    7. Open the client and go to Performance > Traffic Collection Manager.
    8. Add New RouterGroup, assign routers, assign a data collector instance, and press Play button to start collection.
    9. After a few collection cycles, open Web > Performance Management > Router Total Traffic Report to verify the selected interfaces and traffic data are collected.

    Stop Selective Interface Method


    The following steps describes the process to stop using the selective interface traffic collection method:

    1. Stop all data collectors using command

      /u/wandl/dcollect/dc.sh stop all

    2. Configure the data collector to not use selective interface using command

      /u/wandl/dcollect/bin/configureSelectiveIntf.sh off

    3. Stop the selective interface manager using command

      /u/wandl/bin/.selectiveintf stop

    4. Delete the output files on data collector server using command

      rm -r /u/wandl/dcollect/selectiveInterface/fromAPP/


    Commands and Paths


    Selective Interface Server

    • Directory: /u/wandl/bin
    • Program: .selectiveintf
    • Start server command: /u/wandl/bin/.selectiveintf start
    • Stop server command: /u/wandl/bin/.selectiveintf stop
    • Configuration file: /u/wandl/db/config/selectiveintf.xml

    Note: Check the status of the server using command /u/wandl/bin/status_mplsview.


    Input Files


    • Directory: /u/wandl/db/config
    • Files: interface.attributes, interface.rules, interface.user
    • Syntax examples: interface.attributes.template, interface.rules.template, interface.user.template

    Note: Input files are actually a symbolic link to the data directory /u/wandl/data/db/config.


    Output Files


    • Directory: /u/wandl/data/selectiveInterface/fromAPP
    • Files: ifindexfile
    • Automatic index build: default 15 minute interval polling for monitoring changes to network, input files, or router interface index
    • Manual index build command: /u/wandl/bin/selectiveIntfList.sh

    Note: The ifindexfile will be copied automatically to the data collector server /u/wandl/dcollect/selectiveInterface/fromAPP/.


    Data Collector


    • directory: /u/wandl/dcollect
    • program: dc.sh
    • start instance command: /u/wandl/dcollect/dc.sh start #
    • stop instance command: /u/wandl/dcollect/dc.sh stop all
    • check status command: /u/wandl/dcollect/dc.sh status
    • configuration file: /u/wandl/dcollect/dccconfig_wandl_#.xml

    Note: In a distributed environment, automatic ssh login must be setup for wandl user between the application and data collector server.


    Data Collector Configuration


    • directory: /u/wandl/dcollect/bin
    • program: configureSelectiveIntf.sh
    • enable selective interface command: /u/wandl/dcollect/bin/configureSelectiveIntf.sh
    • disable selective interface command: /u/wandl/dcollect/bin/configureSelectiveIntf.sh off
    • test connectivity to application server command: /u/wandl/dcollect/bin/configureSelectiveIntf.sh check

    Note: The data collector instance must be restarted for configuration changes to take effect.

    Configuring Bulkstats Traffic Collection (Advanced)

    Note: This is an advanced traffic collection feature which requires a license. Please contact your Juniper representative for more information.

    1. Configure the appropriate Bulkstats statements on routers to ftp Bulkstats data to /u/wandl/data/bulkstats/current on the IP/MPLSView server. Provisioning templates for ERX and Junos can be found in /u/wandl/data/templates/configlet/BulkStats. The recommended interval for bulkstats collection 15 minutes, and 15 minutes interval for FTP data transfer.
    2. When setting up the router profiles, note that the name in router profile must be exactly the same as the real router name. The vendor type must also be correct for Bulkstats to work. For ERX, only the physical router is needed, not virtual routers. Traffic data for virtual routers will come in one file with the physical router and will be separated automatically. Use the routerName, instead of routerName(default).
    3. Start up a data collector from command line:

      /u/wandl/dcollector/dc.sh start <instance #>

    4. Open the Traffic Collection Manager GUI.
    5. Create a new router group. Uncheck the box Enable Router Group Failover so the data collector will not change when it goes down. Check the box Is this group for Bulkstats Collection? to designate that the router group is for Bulkstats.
    6. Assign a data collector and Bulkstats enabled routers into this router group. Change the collection method to Bulkstats.
    7. Start traffic collection. Wait for incoming data. You will be able to see traffic on the map after receiving two data sets from a router. Bulkstats should FTP into /u/wandl/data/bulkstats/currentfrom routers. Example of raw data output for ERX is listed below. After the data is processed, /u/wandl/data/.network/interface.traffic.bulk file and object files in /u/wandl/data/bulkstats/wandlobjformat will be created. Raw data will be moved into /u/wandl/data/bulkstats/archive
    8. By default, interface.traffic.bulk file has 15min interval, but is updated every 5 min. The reason for this is the passive nature of bulkstats collection in comparison to SNMP/CLI collection. Instead of going into the router to retrieve data, we are waiting for bulkstats data to come in, which could be anytime. So if the data comes in right before the file updates, then we do not want to wait for another 15 minutes to process the data from 30 minutes ago. Therefore, it is better to update interface.traffic.bulk more frequently, 5min by default. So the file updates every 5 minutes, but the data points represent 15 minutes traffic. There will be 8 data points to represent15*8 = 2hours.
    9. Historical traffic can be seen from the web: Live Network > View Historical Traffic Reports.

    Notes


    The Server’s and Routers’ clocks should be configured the same for the collection data to be in sync with the real traffic data. This prerequisite is not required for CLI/SNMP collection, since the CLI/SNMP collection time is decided by the time that collection manager starts talking to the routers and starts collection. Bulkstats, on the other hand, waits for data that could come in anytime. Every 5 seconds Bulkstats checks for new incoming files, whose ftp transfer times are uncertain and are depending on the file size and the connection transfer rate. Therefore the traffic collection manager cannot determine the exact time when the file is generated. It will depend on the time stamps of the files generated by the routers, which means that it will depend on the accurate clock time of the routers and the server.

    If the Traffic Collector is running on a separate machine different from the Application Server, then (a) the automatic SSH connection from the traffic collector to the Application Server needs to be setup, and (b) the rsync package needs to be available on the traffic collector.

    • To install rsync on the traffic collector, switch to the root user and run the ./inst_rsync.sh package under the installation directory’s replication folder. This directory is not a default package in the installation. Contact Juniper support for assistance if this directory is missing.
    • To set up the automatic SSH connection, please refer to Getting Started Guide, Replication chapter, I. Prerequisites for Rsync, “Automatic Login”, for the detailed procedure of creating a private and public key on the traffic collector, but do it for the wandl user (not root user). Copy over the public key to the remote server’s .ssh/authorized_keys file to enable automatic login. Only one-way SSH from the traffic collector to the IP/MPLSView server is needed in this case.

    The processed Bulkstats data is immediately available at the application server for data collectors running on the application server, whereas with remote data collectors the data is rsync'd every 15 minutes.

    Note that BulkStats is designed to work with one IP/MPLSView server. For one Bulkstats file in the router, the router can only FTP the data to one remote machine. If you need a second IP/MPLSView server to monitor the traffic, a second copy of the Bulkstats file should be configured in the router to collect the same traffic statistics. This should be done with caution as it may use up more router CPU/memory resources.

    Troubleshooting

    • “Could not initialize JMS communications. Please check the JMS server” - This is often due to a firewall blocking traffic to the JMS server. Check that the appropriate ports are open between the client and the server as described in the Getting Started Guide’s Port Requirements. In some cases, the port value needs to be changed from the default. The user is prompted for the port value the first time the Traffic Collection Manager is opened. Once the settings are saved, the user is not prompted for them anymore. To get the prompt for these options again, delete the file: C:\Documents and Settings\<user_name>\Application Data\wandl\TrafficCollection.<server_ip>.xml (Windows XP) or C:\Users\<user_name>\AppData\Roaming\wandl\TrafficCollection.<server_ip>.xml and then run Traffic Collection again.
    • If the data collector does not appear in the Traffic Collection Manager check the status using the “./dc.sh status” command. In some cases, you may need to check the /u/wandl/tmp/.pids file to check that a non-existent process (labelled as DGS) is cleared from the .pids file. If the data collector is on a different machine than the application server, check /u/wandl/log/dgs.log.0on the application server to see if the collector has been registered or not (“INFO: Collector registered”). Check /u/wandl/dcollect/log/dcollect_wandl_<pid>.msg on the data collector machine.
    • If the Traffic Collection Manager cannot be started, try renaming the TrafficCollection.<server-ip-address>.xml file as described in step 3 on page 156 and reopening the Traffic Collection Manager. Select the option for HTTP tunneling. If that does not work, check if there is a firewall between the IP/MPLSView client and server machines, and make sure the port 4458 is open. Refer to the Getting Started Guide for a list of ports used between the server and client.
    • If there is still a problem with the Traffic Collection Manager, check the file /u/wandl/bin/mplsenvsetup.sh and look for the MPLS_JBOSS_MEMORY setting. The Task Manager Memory setting is specified during the installation of the IP/MPLSView server and is defaulted to 256 MB. To change this setting to a higher number (512 or higher is recommended), stop the IP/MPLSView server (/u/wandl/bin/stop_mplsview), run the following commands, and then startup the IP/MPLSView server (/u/wandl/bin/startup_mplsview):

      cd /u/wandl/bin; ./changeconfig.sh

      Select 7.) Task Manager Memory, and change it to a large number ,for example, 768

      Select 24.) JBoss Web Memory, and change it to a larger number, for example, 512

    • If the Traffic Collection Manager’s status tab shows the error that data was collected before scheduling a traffic collection (“the network is not currently collecting, yet data has arrived”, or if traffic is being collected at an interval different than the saved setting in the Traffic Collection Manager, then there may be a data collector still running from a previous installation. In that case, go to the directory of the previous installation and run “dc.sh stop all”.
    • If the Traffic Collection Manager’s status tab indicates a warning or error that traffic collection is being queued “Task already queued or running, skipping <ip address>”, this means that the task was not completed by the time of the next collection interval, and the interval may be skipped. In that case, it may be helpful to increase the collection interval. Click on the Global Network in the Collection Elements tab, and then edit the Traffic collection interval in the right pane to increase its value
    • If there is a major error that says,Cannot find module xxxxx messages, this can be fixed by copying over some updated mibs to /u/wandl/dcollect/snmp/mibs and then deleting .index so that the index can be rebuilt. For example, the routers may be using a newer version of SNMP Mibs
    • If not all the traffic data can be collected within the current timeout value (default 3s), open the Traffic Collection Manager, use <Ctrl> or <Shift> to select the routers whose SNMP timeout value needs to be increased and then increase the value in the right pane. When doing so, it may be desirable to also increase the collection interval.
    • For some routers, there may be errors of severity MAJOR indicating no response within the timeout. In this case, check first for connectivity from the IP/MPLSView server to the router. Basic reachability can be checked from Tools > Diagnostics > Diagnostics Manager. If the reachability fails, check that the necessary routes are added on the IP/MPLSView server to the router network. If the problem is still not solved, SNMP connectivity can also be checked from either the MIB Browser* (Tools > MIB Browser) or the Host Discovery task in the Task Manager. If the SNMP connection fails, check the router configuration and the router profile settings (for example, community string).
    • If the Traffic Collection Manager still has problems, stop the IP/MPLSView server (/u/wandl/bin/stop_mplsview), run the following commands to clear out temporary files that may be in a bad state, and then startup the IP/MPLSView server (/u/wandl/bin/startup_mplsview).
      rm /u/wandl/data/mysql/data/jms/*
      rm /u/wandl/data/mysql/ib*
      cd /u/wandl/app/jboss/server/wandl
      rm -rf data tmp work
      cd /u/wandl/app/jboss/server/web
      rm -rf data tmp work

    Modified: 2015-12-29