The following table lists all the attributes and tags that may be set within a configuration file.

[enterprise]

The enterprise section contains all the sites in the enterprise. Most configuration files should only contain one enterprise section. Global default settings can be specified at the enterprise level and overridden within the more specific site and subnet sections.

[site]

A site is the administrative domain of a single Traffic Server. Typically a site will be a single geographical site or campus. Multiple sites are grouped into an enterprise. A site is broken up into zones which define the scope of the site.

[zone]

A site is composed of a number of zones. Zones can be allocated as needed to define administratively significant partitions of the network. A zone is specified by the subnets it contains. Typically a zone might represent a building, business unit, floor, or any other useful subdivision of the site network.

[subnet]

Each subnet, specified by the subnet attribute, defines a range of addresses. All manually specified agents must be contained in the appropriate subnet section (i.e. the subnet that contains their address). Otherwise, if auto-discovery is enabled, agents will be automatically discovered and added to their subnets.

[agent]

Specifies an agent within a subnet. An agent may have individual ports specified. Typically agent sections do not need to be specified unless specific settings are required that override those for the subnet.

Note: If auto-discovery is not enabled, each port must be individually entered for the agent, if those ports are to be monitored.

[port]

A port is a single interface on an agent, specified by its ifIndex. Typically a configuration will not be specified down to the port level, but port sections can be useful if a specific port is to be excluded from monitoring or requires specific settings.

name

An administrative name for the section. Names do not need to be globally unique, but should distinguish subsections within a single section (e.g. If a site has a number of zones, each zone should have a unique name within the site, but zone names can be reused within other sites).

server

The fully qualified host name of the Traffic Server responsible for the site (e.g. traffic.corp.inmon.com).

softwareKey

The software key for this site. The key is required to enable monitoring. Evaluation keys expire at the end of the evaluation period and a new key is required before monitoring can resume. Depending on the license, a key may only permit a limited number of interfaces to be monitored.

Note: The server may discover more interfaces than it is permitted to monitor. While these additional interfaces can be queried, there will be no data associated with them.

A key is specific to the site server. If the domain name is changed then a new key will have to be issued.

subnet

Specifies the address range associated with a [subnet] section. An address range is specified using an address and a mask, or an address and the number of mask bits. Valid subnets are of the following forms:

Note: Overlapping subnets are permitted within the configuration file. Addresses will be associated with [subnet] sections using the deepest "deepest match". The deepest match is the subnet with the narrowest range of addresses, for example, the address 10.10.24.13 would be matched to 10.10.14.0/24 rather than 10.0.0.0/8.

address

The fully qualified domain name, or IP address, of the sampling agent being specified in an [agent] section.

ifIndex

The value of ifIndex (from MIB-2) that identifies a port on the agent.

managerName

Provide the network manager's name.

managerTelephone

Provide the network manager's telephone number.

managerLocation

Provide a textual description of the network manager's location (e.g. "Room 152").

AutoDiscoveryHour

Specify the hour of the day when the daily auto-discovery sweep should be run. The time is specified by an integer in the range 0 - 23 indicating an hour in the local time zone of the server.

Note: By default discovery will occur at 4am each day (i.e. AutoDiscoveryHour = 4).

KeepActiveMinutes

An integer specifies the number minutes for which minute granularity interface statistics and connection data should be kept.

KeepHistoryDays

The maximum number of days to store hourly traffic data. Data older than the specified maximum will be automatically deleted.

Note: There is no guarantee that the specified number of days can be kept. If disk space is limited old data will be deleted to make space for new data. Data may also deleted in order to satisfy the free disk requirement specified by KeepFreeMBytes.

KeepFreeMBytes

An integer specifying the amount of free disk space (in Mbytes) that should be maintained in the disk partition containing the history data (i.e. /usr/local/inmon/server/data/historyData). 

Note: This setting will take precedence over the value set for KeepHistoryDays.

DNS_Scope

A comma separated list of subnets specifies the range of IP addresses for which DNS lookups will be performed. DNS lookups will not be attempted for addresses outside the specified address range.

DNS lookup can be very time consuming for addresses outside the local site or the enterprise. Limiting the range of addresses for which lookups will be performed speeds up queries.

For example:

DNS_Scope = 10.0.0.0/8     ; limit DNS requests to 10.* addresses.

ConsolidatePorts

Certain services are characterized by large numbers of short requests to a well known port (e.g. http requests or DNS requests). Keeping port numbers for both ends of the connections to these services provides very little information, but can consume large amounts of disk space. The ConsolidatePorts option allows these well known ports to be specified causing only the well known port information to be saved. Currently only TCP and UDP ports can be consolidated.

For example:

ConsolidatePorts.TCP = 80,8080     ; consolidate http, and http proxy traffic.
ConsolidatePorts.UDP = 53,161,2049 ; consolidate DNS, SNMP and NFS traffic.

Note: The order of ports specified in the list establishes a priority. In the above example, port 53 is listed before port 2049. If a UDP packet contained a source port of 53 and a destination port of 2049 then it would be port 2049 that would be discarded in favor of the higher priority port 53.

WARNING: This option causes potentially useful port information to be lost and should only be used for popular protocols where large numbers of short flows occur, and for which the service port is always the same.

TraceEnabled

Automated tracing performs traceroute tests to based on network traffic. To enable automatic tracing set TraceEnabled to YES and to disable set to NO. Tracing can only be performed for flow measurements that include subnet information (i.e. NetFlow and sFlow).

Note: Many of the Routing functions depend on tracing being switched on.

Note: Tracing is disabled by default.

PeriodicReportHour

The hour of the day when scheduled reports will be updated.

e.g. PeriodicReportHour = 2    runs reports at 2am.

community

The SNMP community string to use when communicating with agents in this section of the configuration.

Subsections may override this setting.

Note: In addition to a primary community name, two alternative community names can be specified. These alternative community names will be tried in the event that the primary community name fails. To specify alternative community names use the following attribute names: alternativeCommunity1 and alternativeCommunity2. The use of alternative community strings is discouraged, since it slows down discovery (additional queries are required as each alternative is tried). Primary community strings can be overridden by zone, subnet and device and it is preferable if primary community strings are uniquely specified at each level.

discoveryEnabled

Determines whether the Traffic Server should find and automatically configure sampling agents within this section of the configuration. Valid settings are YES and NO.

Note: By default only multi-port devices will be discovered. hubDiscoveryEnabled must be set if single port devices (hubs or instruments) are to be included.

Note: Unless discovery is enabled, every port that is to be monitored by the Traffic Server will need to be specified explicitly (using [port] sections).

Subsections may override this setting.

hubDiscoveryEnabled

Determines whether the Traffic Server should include single port devices (such as instruments or hubs) when it discovers agents. Valid setting are YES or NO.

Note: The hubDiscoveryEnabled flag has not effect if discoveryEnabled is set to NO.

samplingEnabled

Specify whether a particular section should be monitored or not. Valid settings for samplingEnabled are YES or NO.

Subsections may override this setting.

samplingRate

The sampling rate to use when monitoring ports within this section. The sampling rate is a number greater than one that specifies the number of packets to skip between samples (e.g. a setting of 400 mean that on average one in every 400 packets is sampled).

Specific sampling rates can be given for different interface speeds. The speed specific tags are as follows:

• samplingRate.1000 The value to use for interface speeds >= 1Gb/s
• samplingRate.100 The value to use for interface speeds >= 100Mb/s
• samplingRate.10 The value to use for interface speeds >= 10Mb/s
• samplingRate The default value to use if a speed specific setting is not provided.

Note: When Netflow records are received they are sampled using the default samplingRate setting.

forceSamplerAcquisition

Extended RMON Agents can only be used by a single application at a time. By default the InMon Traffic Server will respect prior claims made on Extended RMON Agents even if doing so means that it cannot acquire all the ports specified by its configuration file. The forceSamplerAcquisition flag can be used to override this behavior ensuring that the specified domains are fully monitored. Valid settings are YES and NO.

threshold

Thresholds are used to detect abnormal traffic conditions on an interface. When thresholds are exceeded, notifications can be sent via email (as specified by emailDestination) or as SNMP traps (as specified by trapDestination).

The following threshold options are available:

• threshold.hours specifies the hours of the day during which thresholds should be monitored (see Traffic Query for a description of valid hour values).
  e.g. threshold.hours = 9-16 monitors from 9am to 5pm.
• threshold.days specifies the days of the week during which thresholds should be monitored (see Traffic Query for a description of valid day values).
  e.g. threshold.days = 2-6 monitors from Monday to Friday.
• threshold.<counter>.<type>.<speed>
  threshold.<counter>.<speed>
  threshold.<counter>
  where:
  <counter> is the name of the interface counter to which the threshold applies. (i.e. frames, utilization, broadcasts, multicasts or errors).
  <type> is the type of the interface (e.g. ethernet-csmacd).
  <speed> is the speed of the interface in Mbps (e.g. 10 for a 10Mbps link). Speed specific thresholds are selected so that the smallest threshold >= ifSpeed is selected. For example, a 45 Mb link will use threshold.utilization.100 and not threshold.utilization.10. Speeds can also be specified using the K, M, or G multipliers (the default is M). Thus a threshold for a 10G link can be specified as threshold.utilization.10G. Fractional speeds are not allowed.
  e.g. threshold.utilization.10 = 80%/2/5 specifies that utilization on 10Mbps links should not exceed 80% for more than 2 out of any 5 consecutive minutes. A value for the threshold of 80%/2 would specify that the link should not exceed 80% utilization for 2 consecutive minutes. A value of 80% would specify that the link should not exceed 80% for any minute. For counters such as errors, a value of 12 would indicate a threshold of 12 errors per second. 12% would indicate that number of error frames should not exceed 12% of the total number of frames.
  Setting threshold.utilization = none disables the threshold. This is typically used to exclude a specific area in the network from being monitored.

Note Threshold patterns are matched using the most specific pattern. For example a threshold of threshold.utilization.10 will match instead of the more general threshold threshold.utilization.

event

Events can be sent via email (as specified by emailDestination), SNMP Traps (as specified by trapDestination) and logged using using syslog. Events may come from different sources, including: threshold violations (e.g. link congested), status events (e.g. switch unreachable) and system events (e.g. disk space low). The event flag is used to control the filtering and dispatching of events. For example to send all system events to the syslog, place the following entry in the configuration file:

event.system.syslog = YES

The following threshold options are available:

• event.<action> = YES/NO
• event.<type>.<action> = YES/NO
• event.<type>.<severity>.<action> = YES/NO

Where:
<action> the action to be taken. (i.e. syslog, trap, email).
<severity> is the minimum severity of the event (i.e. inform, warn, severe).
<type> is the type of event (i.e. system, threshold, status...).

e.g. event.threshold.warn.trap = YES specifies that threshold events of warning severity and above should be sent as SNMP traps.

Note: An asterisk (*) may be used as a wildcard when specifying event handling.  For example, event.* = NO disables forwarding of all events and event.*.*.syslog = YES sends all events to the syslog.

Note: The format of SNMP traps is given by the INMON-TRAP-MIB.

trapDestination

Provide the IP address or domain name of a machine to receive SNMP traps. To send notifications to multiple destinations, add a new trapDestination line for each recipient. 

By placing additional trapDestinations at different level in the site hierarchy, notifications for specific zones, subnets or devices, or even ports can be sent to specific recipients.

Traps are generated in response to events. Trap formats are defined by the INMON-TRAP-MIB.

emailDestination

The email address(es) to which event notifications should be sent. To send notifications to multiple destinations, use a comma separated list of addresses (e.g. emailDestination = peter@inmon.com, neil@inmon.com). 

By placing additional emailDestinations at different level in the site hierarchy, notifications for specific zones, subnets or devices, or even ports can be sent to specific recipients.

Note: The smtpHost must be set before email notifications can be sent.

emailFrom

The from address to use when sending event notifications.

Note: The smtpHost must be set before email notifications can be sent.

smtpHost

The smtp server to which email should be forwarded.

congestionMonitor

The congestion monitor function automatically identifies the busiest segments on the network. Information from the congestion monitor appears in Congestion reports.

The following congestionMonitor options are available:

• congestionMonitor.enabled enables or disables congestion monitoring. Valid settings are YES and NO.

Note: By default congestion monitoring is enabled on all ports throughout the network. Typically congestionMonitor.enabled=NO will be inserted to disable congestion monitoring of backup networks, test network, or other parts of the network where high utilizations are expected and don't effect quality of service.

SLA

Service Level Agreements (SLA's) are expressed as the number of minutes per day that utilization is permitted to exceed a specified threshold. The SLA thresholds are used to generate SLA reports.

The following SLA options are available:

• SLA.hours specifies the hours of the day during which SLAs should be monitored (see  Traffic Query for a description of valid hour values).
  e.g. SLA.hours = 9-16 monitors from 9am to 5pm.
• SLA.days specifies the days of the week during which SLAs should be monitored (see Traffic Query for a description of valid day values).
  e.g. SLA.days = 2-6 monitors from Monday to Friday.
• SLA.utilization specifies acceptable utilization as a utilization threshold, and a number of minutes per day during which the threshold may be exceeded.
  e.g. SLA.utilization = 80%/2 specifies that utilization should not exceed 80% for more than 2 minutes per day. Setting SLA.utilization = none disables SLA monitoring. This is typically used to exclude a specific area in the network from being monitored.

portNames

Specify the SNMP MIB value to by used to assign names to ports. Port names (in combination with [agent] names) are used to uniquely identify ports within Traffic Server (i.e. they act as a key in queries and are displayed when summarizing port level information). By default ifIndex will be used to name ports.

Choices are:

• ifIndex
• ifName
• ifAlias
• ifDescr
• ciscoPortName

Note: If you explicitly name a port then the setting for portNames will have no effect.

portDescription

Determines what appears in the port description field when you drill down to the port level in the Monitor>Traffic application. Port descriptions are simply a way of displaying additional information about a port. The default is ifName.ifAlias.ifDescr

Value is of the form:

portDescription = var[.var]

Where var can be one of:

• ifName
• ifAlias
• ifDescr
• ciscoPortName

Note: The portNames setting is used when single short names for ports are required.

agentNamePolicy

Specify how agents are to be named.

Choices include:

• DNS Use the reverse DNS name for the agents IP address.
• SNMP Use the sysName value from SNMP MIB-2
• IP Use the agent's IP address.

Note: The default is to use SNMP

hideInactivePorts

Set to YES if you wish to hide inactive ports and NO if you want to show inactive ports when drilling down in the Monitor->Traffic application.

Note: Default is NO

pollCounters

Automatic counter polling uses SNMP to poll the interfaces on a switch. An [agent] section must be created for the switch.

To enable automatic counter polling, set pollCounters to YES and to disable set to NO.

WARNING Do not enable counter polling for switches that are being monitored by an sFlow Probe, or which have embedded sFlow. sFlow already incorporates counter polling so any additional polling activity will be wasted overhead. Merging the two sets of counter values can also yield unpredictable results.

Note: Counter polling is disabled by default.

protocol

Specify how ports should be used to identify protocols and create named groups of protocols.

• protocol.priority.<layer> Each packet flow is associated with two ports. Port priority is used to determine which of the two ports to use to identify the protocol. For example, traffic between TCP port 2312 and port 6000 is likely to represent the X11 protocol. To indicate that 6000 has a higher priority than 2312 when determining the TCP protocols, use the following declaration:
  protocol.priority.TCP=6000,2312
  Port priority lists can also include ranges, for example:
  protocol.priority.UDP=1-512,2049,513-1024,6343,9985-9995,19981-19991
• protocol.group.<layer>.<name> Group multiple, related protocols together and assign a group name. For example, web traffic may occur on ports 80, 8080 and 8088:
  protocol.group.TCP.web = 80,8080,8088

wan

Identify a link as being a "WAN" link. Detailed flow data is maintained for WAN links and long term counter histories are maintained using rrdtool. In addition, threshold, status and traffic information for WAN links can be viewed in the Routing screens.

• wan.enabled Control RRD logging of interface statistics. Set to YES for enabled and NO for disabled. Must be set on within individual [port] sections.
• wan.name Give a name to the wan link.
• wan.services Specify a set of protocol.group names to trend for each enabled interface. The RRD history data will cleared whenever you change the value of wan.services. The following example shows the use of the rrd.services setting to trend link utilization broken down by a number of well known services.
  wan.services = TCP.web,TCP.login,TCP.file-transfer,TCP.X11,UDP.DNS,UDP.snmp
  Note: wan.services must be set at the [enterprise] or [site] level.

WARNING WAN logging is a relatively expensive operation and shouldn't be activated for more than a few hundred interfaces. The use of the wan.services function further increases the overhead associated with WAN logging, further limiting the number of interfaces that can be monitored. Typically WAN monitoring will only be activated for selected important links such as backbone or WAN links.

Note: Traffic Server does not automatically delete RRD files when logging is disabled. This means that if you accidentally disable logging for a port, you can re-enable it without loosing any data. However, this means that RRD charts that are no longer being updated will appear in the Routing>Traffic page. To delete the RRD data you must log into the Traffic Server and delete the corresponding files:

/usr/local/inmon/server/data/RRD/<agent>/<ifIndex>-*.rrd

rrd

The rrd settings control the default sizes of RRD charts displayed for wan links.

• rrd.index.height Default height of charts when displayed on index pages.
• rrd.index.width Default width of charts when displayed on index pages.
• rrd.detail.height Default height of charts when displayed on a detailed single link view.
• rrd.detail.width Default width of charts when displayed on a detailed single link view.

preSampled

This option only applies when receiving Netflow data. If an agent is exporting sampled Netflow then set preSampled=YES. This will cause data to be scaled by the samplingRate configured for this agent.  If the Netflow records specify a sampling rate, then that rate will be used instead.

WARNING Setting preSampled=YES for non-sampled Netflow will cause traffic to be overestimated. Also you must ensure that the samplingRate setting for the agent matches the sampling rate used to configure sampled Netflow in the router.

flowTimesInSeconds

This option only applies when receiving Netflow (cflowd) data from Juniper routers. Set flowTimesInSeconds=YES to indicate that timestamps are in seconds rather than hundredths of a second.

netflowInputASInfo

Indicate whether Netflow records contain origin or peer AS information. Valid settings are:

• origin If origin AS information is contained in the Netflow records.
• peer If peer AS information is contained in the Netflow records.

Note: Make sure that the configuration file settings match the settings used to configure AS information in the router.

ifSpeed

Set the ifSpeed associated with a port. Normally ifSpeeds will be correctly identified using SNMP or sFlow data, however, if the device does not provide ifSpeed information, or reports incorrect ifSpeed information, then this parameter allows the speed to be manually set.

Values are of the form <integer><K|M|G> where: K = Kilobits/sec, M = Megabits/sec and G = Gigabits/sec. For example:

• ifSpeed = 1200 sets the speed to 1200 bits/sec.
• ifSpeed = 10M sets the speed to 10 Megabits/sec.
• ifSpeed = 1G sets the speed to 1 Gigabit/sec.

Correct ifSpeed information is important when calculating link utilizations and when applying thresholds.