Configuring Traffic Sentinel - step by step guide

Traffic Sentinel is a powerful tool for monitoring and managing network activity in large multi-layer switched and routed networks. In order to operate correctly, some initial configuration is required.

The following steps are needed to fully configure Traffic Sentinel:

  1. Initial configuration
  2. Configure switches
  3. Discover switches
  4. Confirm traffic measurements
  5. Define administrative groupings
  6. List addresses space
  7. Assigning agents to groups
  8. Set thresholds
  9. Forward events
  10. Schedule reports
  11. Create user accounts
  12. Customize dashboard

It is recommended that you work through all the steps. This will familiarize you with the major components of the product and ensure that all the product features operate correctly. It is worth reading through all the steps before starting. While the steps are presented in a linear fashion, in practice configuration is more of an iterative process as you find the best way to organize information and settings.

Each of the steps is described in detail in the rest of this document.

1. Initial configuration

Once you have installed Traffic Sentinel, connect to its web interface.

Scroll down to the bottom of the End User License Agreement and click on the Accept License button.

The next step is to enter an initial configuration, click on the File>Configure link to go to the configuration screen.

You will need to log in as an administrator in order to make configuration changes. Use the default username and password for the initial login (i.e. User: administrator, Password: administrator).

Note: Don't forget to change the default passwords when you configure user accounts (see 11. Create user accounts).

Once you have logged in you should see the Site Settings form.

The settings in the Site Settings form are:

  • Enterprise Name Enter the name of your organization. Short names or abreviations are recommended.
  • Site Name Enter a name for the campus, data center or city containing the devices being monitored. Again short names are recommended.
  • Server This non-editable field displays the hostname of the server running the Traffic Sentinel software.
  • Serial Number Enter the serial number (provided by InMon) that corresponds to your software license. The serial number will start with the letters ITS and should be 12 digits long.
  • Contact Name Enter the name of the person responsible for administering this Traffic Sentinel.
  • Contact Location Enter a location for the contact person.
  • Contact Phone Enter telephone number for the contact person.
  • Days of Historical Data The number of days to keep the traffic history.
  • Mbytes of Free Disk Space Historical data will automatically be deleted (oldest first) if the disk partition fills up.

Make sure that you enter the Software Key and Serial Number that were issued with your license. Also check to make sure that the reported Server name matches the host name you gave when you requested the software key (if the server name doesn't match then check the FAQ entry: How can I change the hostname to match the software key?).

Note: Online help is available for each screen, just click on the Help link at the top right of the screen.

If the software key has been accepted, the following configuration screen will appear giving access to all the configuration options:

By default, Traffic Sentinel will use SNMP version 2c with the community string "public". If you need to change these settings, click on the Edit SNMP Settings link on the configuration screen to configure the SNMP settings.

The table lists SNMP settings that have been defined for different parts of the network. In this case there is only one "site-level" setting.

Click on the Edit button to edit the entry.

Fill in the new SNMP settings and click on the Submit button to make the changes. In this example we are changing the community string to "secret". If you want detailed information on the SNMP settings, just click on the Help link at the top right of the screen.

Note: In this example, the changed SNMP settings will be used to talk with all devices on the site (i.e. it was a "site-level" change). Later in this tutorial, you will see that it is possible to group switches and apply different settings to each group.

2. Configure switches

Depending on your network equipment and the protocols you are going to use to monitor each network device, there may be some switch configuration changes required. Typically these tasks will involve logging into each switch and using using the switch CLI (Command Line Interface) to make the changes.

  • SNMP It is important that Traffic Sentinel by able to use SNMP to collect information from all the switches you want to monitor. You should make sure that SNMP is enabled on the switches and that any security policies in place on the switches permit Traffic Sentinel to make SNMP requests. You will need information on the SNMP settings on the switches (SNMP community string, SNMP version, passwords etc.) in order to configure Traffic Sentinel.
  • sFlow® sFlow can be configured using SNMP or through the switch CLI. However, the mechanisms that are available will depend on the switch vendor. If your vendor supports the sFlow MIB, you will need to make sure that Traffic Sentinel is allowed SNMP read/write access. If you are configuring sFlow through the switch CLI then you will need to consult your switch vendors documentation for the settings. The following FAQ entries describe typical configuration settings:
  • NetFlow© NetFlow is configured through the switch CLI, see: How do I configure NetFlow on my Cisco router? NetFlow does not provide interface counter information, so Traffic Sentinel will need to use SNMP to regularly poll the switch for interface counters (see SNMP configuration section above).
  • JFlow© JFlow is configured through the switch CLI, see: How do I configure JFlow on my Juniper router? JFlow does not provide interface counter information, so Traffic Sentinel will need to use SNMP to regularly poll the switch for interface counters (see SNMP configuration section above).
  • IPFIX IPFIX is configured through the switch CLI. IPFIX does not provide interface counter information, so Traffic Sentinel will need to use SNMP to regularly poll the switch for interface counters (see SNMP configuration section above).

When configuring sFlow devices through the CLI you will have to specify a "sflow counter polling interval". This setting determines how often interface counters are sent to Traffic Sentinel. The interface counters are used to calculate link utilizations and error rates and to trigger threshold events. An interval of 20 seconds is recommended.

When configuring traffic flow monitoring (i.e. sFlow, NetFlow, JFlow or IPFIX), it is recommended that you enable monitoring on all switch interfaces and that you configure the switch to use packet sampling (where possible). Packet sampling will reduce the monitoring overhead on the switches, reduce the amount of monitoring traffic on the network and will increase the number of switches and interfaces that you can monitor. The following default sampling rates are recommended:

Link SpeedSampling Rate
10Mb/s1 in 200
100Mb/s1 in 500
1Gb/s1 in 1000
10Gb/s1 in 2000

Note: For most applications and most networks the default sampling rates will work well. If you have unusually high traffic levels you may want to increase the sampling rate (e.g. use 1 in 5000 instead of 1 in 2000 for your 10Gb/s links).

When configuring switches to send sFlow, NetFlow, JFlow or IPFIX data to Traffic Sentinel, it is important to make sure that you send each protocol to the correct port. The File>Status page lists the ports used to receive each type of data:

Note: It is important to make sure that any firewalls between Traffic Sentinel and the switches it is monitoring allow passage of packets to these ports. In addition the firewall should allow ICMP echo (ping) packets and SNMP packets (UDP:161).

The following tutorials have more details:

3. Discover switches

Traffic Sentinel will automatically "discover" devices when it receives sFlow, NetFlow, JFlow or IPFIX data (Note: you would have had to configure the switches to send data to Traffic Sentinel - see 4. Configure switches). If all your devices fall into this category you can skip to section 3.2 Agents.

If you have devices that can only be monitored using SNMP or devices that are going to be configured using SNMP (e.g. sFlow devices supporting the sFlow MIB), then you will need configure Traffic Sentinel's discovery settings before these devices will be discovered. See 3.1 Agent Range below.

3.1 Agent Range

Traffic Sentinel provides a mechanism for scanning ranges of addresses to automatically discover network devices. You will need to edit the network configuration and create an "agent range". First go to the File>Configure>Edit page.

Click on the Edit Agent Ranges link access table of agent ranges.

Click on the New button to create a new agent range.

The Agent Range Settings form has the following settings:

  • Group The administrative group (see 5. Define administrative groupings). You can leave this setting at its default since you will be defining groups in step 5 and will be able to change the setting then.
  • First Address The first address in the range.
  • Last Address The last address in the range.
  • Scan Addresses Set to Scan to allow Traffic Sentinel to test all the addresses in the range and discover switches.
  • Override Control The sFlow MIB has a reservation mechanism that allows a network management application identify settings that it is using and to protect them from changes by other network management applications. Normally the settings Don't Override is appropriate since this respects the settings made by other applications. If Traffic Sentinel is the only application being used to collect sFlow data then you might want to set this value to Override, ensuring that Traffic Sentinel will be able to take over whatever resources it need to monitor the network.
  • Enable/Disable Set this value to Enable to allow the address range to be scanned and to allow monitoring of Agents that fall into this range. Set to Disable if you want to block monitoring of Agents in this range.

In this example, switches are allocated addresses in the range to The form shows the settings needed to scan this range for agents.

3.2 Agents

Traffic Sentinel identifies each switch or router by a unique IP address or "Agent" address. The term "Agent" commonly refers to the software entity on a managed switch or router that is responsible for handling SNMP requests. Traffic Sentinel uses the term to refer to any device that it is monitoring.

A device may have many IP addresses associated with it. For example, a router will typically have an IP address associated with each routed interface. The following rules determine which IP address will be used as the unique Agent address:

  • SNMP Traffic Sentinel uses SNMP to obtain information about agents. Unlike sFlow, NetFlow and IPFIX which stream information from the switch to Traffic Sentinel; SNMP information must be explicitly requested by Traffic Sentinel. The agent address will either be defined in the Traffic Sentinel configuration file, or determined by sFlow, NetFlow or IPFIX.
  • sFlow The sFlow protocol explicitly assigns a unique agent address to each device. The "sFlow Agent Address" can usually be displayed using command line "show" commands and is accessible as part of the sFlow SNMP MIB. The agent address is typically the IP loopback address for the device.
  • NetFlow The NetFlow protocol does not provide an explicit agent address. Traffic Sentinel will simply use the source IP address from the NetFlow datagrams it recieves as the agent address.
  • JFlow The JFlow protocol does not provide an explicit agent address. Traffic Sentinel will simply use the source IP address from the JFlow datagrams it recieves as the the agent address.
  • IPFIX Like NetFlow, the IPFIX protocol does not have an explicit agent address. Traffic Sentinel will simply use the source IP address from the IPFIX datagrams it receives as the agent address.

The File>Configure>Status page shows all the agents that have been discovered and their place in the configuration tree. Section 5. Define administrative groupings describes the rules for locating an agent in the configuration tree.

In this example, there are 6 switches located with Zone and Group "Other", indicating that we haven't yet organized the network into Zones and Groups (see 5. Define administrative groupings).

To see the addresses instead of names, change the Show setting to Addresses.

This view shows addresses that have been discovered. If the address is in bold then it is the Agent address, otherwise it is another of the addresses associated with the Agent.

Click on links in Discovered Agents or Discovered Addresses to see details about the Agent. The following screen shows information relating to the address.

In this case the IP Address (Agent address) is and Traffic Sentinel is applying configuration settings from the Path for the site (i.e. InMon>HQ). Clicking on the Edit button at the top of the screen will open the configuration editor to the correct path for the agent so that its settings can be changed.

The Flows and Counters values are sFlow CLI, indicating that Traffic Sentinel is receiving interface counters and traffic flow information through CLI configured sFlow.

The Settings sections on this page show all the settings that are being applied to this agent. You can see that the SNMP community string "public" is being used for SNMP requests.

If want to find an agent you can use the Search>Agent/Interface page to find the agent using any of its addresses, its name or its description. The following example shows the result of searching for an agent using the address

This page shows that the IP Address (Agent address) is (Note: this is the same agent we looked at before. If you go back to the previous screen you will notice that appears in the Other Addresses list for agent

The Contact Address is the address that is used to communicate with the agent. In this case the Contact Address and the IP Address are the same, but this is not always the case. If the IP Address is unreachable from Traffic Sentinel, another of the agent's addresses may be used as the Contact Address.

The address that we searched for is associated with the loopback interface, lo0 on the switch.

Finally, when new agents are discovered and informational event is generated in the event log:

The Events>List page shows recent events. Setting the Severity to All and the Type to Configuration will show recent configuration changes and new or removed agents. In this example, two new agents have been found in the last 24 hours, agents and

4. Confirm traffic measurements

The Traffic>Status page is the best place to confirm that traffic data is being received and to identify problems.

The top level view shows the Zones that contain Groups of switches (see 5. Define administrative groupings). In this case click on the default zone name "Zone 1".

There is only one group defined, the default group "Group 1". Click on the group name to see the switches it contains.

The table shows the 7 switches in the selected group. The grid of colored boxes indicates the status of each switch. Shade is used to indicate whether flow information is being collected for the device (flow information is used to determine which connections are generating traffic).

Unknown There is no status value, either because no counter data is available, or because there are no thresholds set.
Good Counter value does not exceed threshold value.
Warn Counter has exceeded threshold value in at least once, but not enough times to cause an alert.
Critical Counter has exceeded threshold value often enough to generate an alert.

The circled "marginal" boxes in the Agent status column should be investigated further.

The first agent,, has the message No SNMP information available indicating that there is a problem with obtaining SNMP information. Clicking on the circled status box gives the following information:

This table indicates that the agent exists (since it responds to ICMP Test, "ping" test messages), but fails to respond to SNMP tests messages. SNMP communication problems can be caused because the Traffic Sentinel SNMP configuration settings are incorrect for this switch, or because the switch is not permitting SNMP requests from Traffic Sentinel.

Clicking on the second circled status box, corresponding to the agent gives the following information:

In this case the Flows and Counters columns indicate that Traffic Sentinel is attempting to use the sFlow MIB to configure sFlow monitoring for the agent. The ICMP and SNMP tests are successful, but Interfaces Not Aquired indicates that All switch interfaces were already being monitored by other network applications and were not available to Traffic Sentinel. Clicking on the All link gives the following information:

The Manger value of;SF;;; indicates that the sFlow agent is already in use by software running on The monitor on should be configured to release this agent so that it can be acquired by Traffic Sentinel.

Clicking on the third circled status box, corresponding to agent, gives the following information:

In this case the Flows and Counters columns indicate that Traffic Sentinel is attempting to use the sFlow MIB to configure sFlow monitoring for the agent. The ICMP and SNMP tests were successful, but the SNMP SET test failed. Configuring sFlow via the sFlow MIB requires that Traffic Sentinel have SNMP read/write access (i.e. it must be able to perform SNMP SET operations). The failed SNMP SET test indicates that either the switch hasn't been configured to allow SET operations, or Traffic Sentinel hasn't been given the correct SNMP configuration to perform SET operations. Traffic Sentinel does have SNMP read access (shown by the successful SNMP test).

Once the communication issues have been resolved, the availability of counter and flow information can be verified using the Traffic>Trend page.

The agent fgs had a status color indicating that flow and counter information is available. Selecting an interface, ethernet0/1/2, on this switch and selecting the Utilization shows that counter information is indeed being collected for this switch.

Selecting the Top Sources chart confirms that flow information is being collected for this switch.

5. Define administrative groupings

Dividing the network into administrative groups makes it easier to organize large number of network devices. In addition, grouping devices allows different settings to be applied selectively to groups of devices.

Traffic Sentinel provides a two level hierarchy. At the top level are zones. Each zone can contain groups and each group can contain network agents. The hierarchy provides a single location or path for each agent (i.e. an agent can only appear in one group and a group can only appear in one zone).

In addition to grouping agents, the zone and group hierarchy is also used to organize IP address space. Grouping addresses makes it easier to report on traffic within or between zones and to apply different policies to different groups of hosts (e.g. the traffic patterns and policies associated with servers in the data center are likely to be different from the traffic patterns and policies associated with students in dorms).

There are many ways in which you might choose to group your network; you should choose a scheme that works best for your organization.

5.1 Examples

The following examples give some typical organizational schemes.

5.1.1 University

A university might choose to organize its network by logical group and then by building. For example:

Data Center

5.1.2 Company

A company may choose to organize the campus network by building and floor. For example:

Building A1st Floor
2nd Floor
Building B1st Floor
2nd Floor
3rd Floor

5.1.3 Hotel

A hotel might organize its network by area and by room or floor. For example:

AdminData Center
Conference CenterBallroom A
Ballroom B
Guests2nd Floor
3rd Floor

5.2 Creating zones and groups

The File>Configure>Edit page is used to define zones and groups. In the following example we will be building the zones and groups for the network described in the 5.1.1 University example.

The first step is to define the zones. Click on the Zone link at the top of the page or the Edit Zones link in the Groupings section of the page.

The Edit Zones form allows zones to be added, removed or modified. Note that there are three zones defined already that were created when Traffic Sentinel was first started. The first, Multicast is used to capture IP multicast addresses (see 6. List address space to see how IP addresses can be grouped). The second, Unassigned is used to capture IP addresses that don't belong to any other groups. The third, Zone 1, includes the subnet containing Traffic Sentinel.

Note: Don't delete the Zone 1 zone. When you delete a zone you delete all the configuration elements it contains. You can delete it later, once the configuration is complete and any settings in Zone 1 have been moved.

Click on the New button to define a new zone.

Simply enter the name of a zone, in this case "Core" and click on the Submit button to create the zone. These steps can be repeated to add all the zones, in this example the zones are "Core", "Departments" and "Accommodation".

Once a zone has been defined, it is time to add groups to the zone.

In this example, we will start with the "Core" zone. Click on the Edit button next to the zone.

The Zone Settings form allows different settings to be applied to the zone. In this case we want to add groups to the zone, so click on the Edit button next to Edit Groups.

The Edit Groups form allows groups to be added in the same way that zones were added earlier.

Note: The Index > InMon > HQ > Core path at the top of the page shows that we are editing groups within the Core zone.

Click on the New button to add a group.

In this example we are adding a group called "Admin" to the "Core" zone. Click on the Submit button to add the group. Continue adding all the groups to the zone, in this example "Admin", "Data Center" and "DMZ".

Repeat this process until all the zones and groups have been defined.

6. List address space

Grouping host addresses allows traffic patterns to be better understood. Listing all the locally assigned addresses allows local vs. non-local traffic to be identified. Assigning addresses to different groups allows analysis of traffic within and between groups and zones. For example, in this tutorial we divided a university network into different groups and zones. Identifying the addresses associated with student housing, university departments and core administrative function makes it is easy to to construct and enforce network usage policies for these different groups. For example, you might want to limit the amount of bandwidth used by students running peer-to-peer application, or provide tighter control over access to the university administration computers.

Traffic Sentinel uses Classless Inter-Domain Routing (CIDR) a method of defining groups of IP addresses. In CIDR notation a group of IP addresses is defined using a network (IP) address and a number of mask bits indicating the number of significant bits from the address that will be shared by members of the group. For example, the CIDR will group all the addresses that share the 10.1.4 prefix; i.e. all the addresses that exist on the subnet. To illustrate CIDR priorities, consider the an IP address, Suppose that two CIDRs are defined, and The IP address is contained in both of these CIDRs, but the CIDR is a more specific group of addresses and so will have priority over the CIDR.

CIDRs provide a very efficient means of specifying address groups. The goal is not to reflect every detailed subnet in the network, but to use CIDRs to describe the overall subnetting policy for the site. For example, suppose that the university network in 5.1.1 University uses the private address space. The following table shows a possible address allocation policy for the site:

Data Center10.0.16.0/20,

In this example, there are one or more /20 CIDRs assigned to each group. It is useful to define a "catch all" group to ensure the proper identification of local addresses. In this case we can create a "Unassigned" zone and group to contain the CIDR. Remember that an address will be assigned to the most specific CIDR, so the only addresses that will appear in the Unassigned group will be local addresses that don't belong in any of the other groups. As well as ensuring that all local addresses are correctly identified, the Unassigned group is helpful in other ways. If Traffic Sentinel detects network traffic from addresses in the Unsassigned group, this indicates that an undocumented block of addresses is in use. If network traffic to the Unassigned group is detected, it can indicate that someone is scanning your address space, providing a useful security alert.

The "Multicast" zone and group are created automatically in the intial Traffic Sentinel configuration file. The CIDR identifies IP multicast traffic. The Multicast group makes it easier to report on multicast traffic and ensures that multicast traffic is treated as local traffic.

The File>Configure>Edit page is used to assign CIDRs to groups. In the following example we will add a CIDR from the University example above (see 5. Define administrative groupings for instructions on creating the "Unassigned" zone and group).

Click on the CIDR link at the top of the page or the Edit CIDRs link in the Groupings section of the page.

Click on the New button to add a new CIDR.

Note: The CIDR in the Zone 1 zone and Group 1 group was added by default in the initial Traffic Sentinel configuration file. This is simply the subnet that Traffic Sentinel resides on and it can be removed by clicking on the Remove button in the table.

Select a Group, and specify the Address and Mask Bits components of the CIDR. In this case the group is Core>Admin (i.e. the Admin group in the Core zone) and we want to add the CIDR, so the address is and the mask is 20 bits, mask = Click on the Submit button to create the CIDR.

Repeat these steps until you have added all the CIDRs for your site.

A useful way to see which will contain an address is to use the Search>Host page.

In this case a search for the address shows that the address has been placed in the Core zone and the Admin group. The Location value, InMon>HQ>Zone 1>Group 1>ProCurve Switch 5406zl>A15, shows the switch and switch port connecting this host to the network and the zone and group that the switch has been assigned to.

Note: In this case the switch appears in the Group 1 group while a host connected to it appears in the Admin group. The switch location is determined using the rules in 7. Assigning agents to groups while traffic associated with host addresses is grouped by CIDR. While it often makes sense to group hosts and switches together, you may have situations where this isn't possible or doesn't make sense. It can be useful to organize switches geographically (e.g. Building A, 2nd Floor) while classifying network traffic by corporate function (e.g. Manufacturing, Sales, Support).

7. Assigning agents to groups

Once the site has been divided into zones and groups, it is time to assign network devices to their correct groups.

Groups can contain Agent, Agent Range and CIDR definitions. When an agent discovered, it is assigned to a Group based on its agent IP address. The following priority rules determine the Group that the agent will be assigned to:

  1. Agent If an explicit agent section has has been defined for the agent address, then the agent section will have highest priority.
  2. Agent Range The smallest agent range that contains the agent address will have priority over other agent ranges. The size of an agent range is the number of addresses in the range. Any agent range containing the agent address will have priority over a CIDR.
  3. CIDR The most specific CIDR that contains the agent will have priority over other CIDRs. Classless Inter-Domain Routing (CIDR) is a method of defining groups of IP addresses. In CIDR notation a group of IP addresses is defined using a network (IP) address and a number of mask bits indicating the number of significant bits from the address that will be shared by members of the group. For example, the CIDR will group all the addresses that share the 10.1.4 prefix; i.e. all the addresses that exist on the subnet. To illustrate CIDR priorities, consider the an agent address, Suppose that two CIDRs are defined, and The agent address is contained in both of these CIDRs, but the CIDR is a more specific group of addresses and so will have priority over the CIDR.
  4. Site If no other location is found for the agent, it will pick up site level settings and will be assigned a Zone and Group of "Other".

In section 3.1 Agent Range you may have defined Agent Range settings in order to discover the switches. In this case you will be using Agent Range and Agent settings to assign agents to groups. Alternatively, if you haven't been using Agent Ranges, you may want to use CIDRs to group agents. In either this case, it is worth reading 8. List address space before proceeding because CIDRs are used for classifying traffic flows (allocating source and destination IP addresses to groups) as well as for assigned agents to groups. Often the overlap between the two functions is desirable (you want to put the switch in the same group as hosts), but there may be situations where you would like assign the switch to a different group without disturbing the address space groupings. Since Agent Range and Agent settings have a higher priority than CIDR settings, they can be used to move an agent while leaving the address groups undisturbed.

In section 3.2 Agents we used the File>Configure>Status page to show where "agents" have been placed in the configuration tree.

8. Set thresholds

An interface counter threshold consists of a Limit, a Minutes Over Limit and a Total Minutes value. Every minute Traffic Sentinel will check thresholds against every monitored interface and determine its status based on the threshold settings. The following illustration demonstrates the calculation of interface status:

The Interface Statistics chart shows the minute by minute changes in an interface statistic. The horizontal line shows the threshold Limit value. The second Threshold Crossings chart shows the intervals when the Limit has been exceeded. The final Status Chart shows the status as marginal as soon as the threshold value starts to be exceeded. The status changes to critical and an event is generated after 4 consecutive intervals (i.e. Minutes Over Threshold is set to 4) in which the Limit value has been exceeded. Finally, it takes 4 intervals of values below the threshold value before the status returns to good (assuming that Total Minutes is also set to 4).

Total Minutes can be larger than Minutes Over Threshold. In this case a notification occurs if the Limit value is exceeded at least Minute Over Threshold times in Total Minutes consecutive intervals. For example, suppose Total Minutes is set to 10 and Minutes Over Threshold is set to 4. A notification will occur if 4 intervals in any 10 interval period exceed the Limit. In addition, the status will only return to good after 10 consecutive periods with the value under the Limit.

The product ships with default settings defined at the Site level, which can be edited or overridden.

The following example of entering an new threshold setting:

The new threshold overrides the Utilization threshold in the Data Center for interfaces with speeds >= 1Gb/s (10/100 Mb/s interfaces will still pick up the site level settings).

Note: In general, thresholds should be set so that only severe traffic problems that impact quality of service will generate events. Critical events are intended to provide actionable notification of problems to network operators. When setting thresholds, try to identify a traffic level that will have a noticeable effect on network service levels. Set a duration that corresponds to an unacceptable period of poor service. The goal is to generate very few, significant events indicating severe problems that require immediate attention. Thresholds are not intended as a reporting tool to generate statistical information about network traffic. Traffic Sentinel provides detailed query and reporting capabilities that can be used to trend traffic and identify busy links before severe congestion problems occur (see Querying and Reporting).

9. Forward events

Events are listed on the Events>List page. Events can be forwarded via:

  • RSS feed
  • email
  • syslog
  • SNMP Trap

To obtain an RSS feed, simply select the event list that you want to follow, then click on the button.

Forwarding events via email, syslog and SNMP Trap is configured on the File>Forwarding>Events page.

10. Schedule reports

Traffic Sentinel has a highly customizable query and reporting capability. The tutorial, Querying and Reporting, describes the steps needed to configure reporting.

11. Create user accounts

Each Traffic Sentinel user should have an individual account and password. Traffic Sentinel maintains individual user preferences and settings and enforces access controls for each user.

The File>Users page is used to manage users.

Note: Make sure that at least one user has an Administrator access level. Don't forget to remove the default operator and administrator users, or to change their passwords from the default settings.

12. Customize dashboard

Each user can create their own customized home page showing all the critical information needed to manage the network.

The tutorial, Customizing the Dashboard, describes how to configure the dashboard.

Related Topics