Submit a ticketCall us

AnnouncementsWeb Help Desk Integrations eCourse

Looking to reduce response times? Sign up for our eCourse to learn how integrating Web Help Desk with Dameware Remote Support, Network Configuration Manager, Network Performance Monitor, and Server & Application Monitor can improve communication efficiencies.

Register for your free eCourse.

Home > Success Center > Netflow Traffic Analyzer (NTA) > NTA - Knowledgebase Articles > NetFlow Interface resource(s) show utilization peaks higher than NPM utilization or higher than the interface bandwidth

NetFlow Interface resource(s) show utilization peaks higher than NPM utilization or higher than the interface bandwidth

Created by Melanie Boyd, last modified by MindTouch on Jun 23, 2016

Views: 1,521 Votes: 0 Revisions: 3

Overview

If the active flow cache timer on each flow exporter is not set correctly, NetFlow Interface resource(s) can show utilization peaks higher than NPM utilization or higher than the interface bandwidth.

Environment

  • NTA, all versions

Cause 

Flow exporters may store active flows for longer than the default NTA reporting period of 1 minute. When long duration flows are exported the data is reported as occurring in same minute the export is sent to NTA. The result may cause reporting of data rates larger than the actual rate for that minute.

Resolution

The active flow cache timer on each flow exporter should be set to 1 minute to match the NTA reporting period.

  • For Cisco devices running IOS 12.2 (14)S and above, include ip flow-cache active 1 in the device global configuration.
  • For Adtran devices running 16.1 and above, include ip flow cache timeout active 1 in the device configuration.
  • For sFlow: set polling interval 60 Exact syntax may vary by vendor implementation. See your vendor’s configuration guide for details.
  • For NetFlow (Catalyst switches), include mls aging long 64 in the device global configuration. 64 seconds is the minimum allowed value.
  • For J-Flow, include ip flow-cache timeout active 1 in the device configuration.

 

Note:

There is a known issue in Orion NTA 3.6 (resolved in 3.7) that can rarely cause similar behavior. You can determine if this issue is causing this behavior by running the following query using MS SQL Management Studio when connected to your Orion database:

SELECT

      n1.caption,

      n2.caption,

      i.InterfaceName,

      a.InterfaceName

FROM

      interfaces i

      INNER JOIN

            (

            SELECT (nodeId * 4096) | interfaceIndex as hash, InterfaceIndex, InterfaceName, NodeId, interfaceid

            FROM interfaces

            ) A

            ON A.hash = ((i.nodeId * 4096) | i.interfaceIndex)

                  AND NOT(a.interfaceindex = i.interfaceindex AND a.nodeid = i.nodeid)

      INNER JOIN Nodes n1 on i.NodeID = n1.NodeID

      INNER JOIN Nodes n2 on a.NodeID = n2.NodeID

WHERE

      n1.NodeID < n2.NodeID

If the query returns results, then the results indicate nodes (and their interfaces) where you will see incorrect traffic results. In this case, please upgrade to 3.7.

 

 

 

Last modified

Tags

Classifications

Public