Self-Solve Knowledge Search

Minimize Maximize
Network Node Manager i (NNMi)/Smart Plug In (SPI) - Performance for Traffic: Dat...
Title :
Network Node Manager i (NNMi)/Smart Plug In (SPI) - Performance for Traffic: Data flushes from Traffic-Leaf to Traffic-Master component fail when a Cisco Nexus device is sending Netflow v9 packets.
Document ID :
KM00416110
Product - Version:
network node manager ispi performance for traffic 9.10 ;
OS :
Windows,Linux
Updated :
Fri Mar 13 12:52:33 GMT 2015
Summary :
This document describes what measures need to be taken when a Traffic Leaf Collector Instance refuses to flush data to the Traffic Master Component, when a Cisco Nexus device, running on the Nexus-network-Operating-System (NX-OS), is the flow forwarder, and Netflow v9 is the protocol in use.
Problem

The Cisco Nexus Node, as well as its interfaces, are viewable in the NNMi Inventory.
On the iSPI Traffic Leaf Server, execution of the "nmstrafficleafstatus.ovpl" command shows that the Leaf Service is running.
On the "iSPI Performance for Traffic Configuration" page, under the "Leaf Collectors" tab, the Traffic Leaf Collector's status also shows up as "RUNNING".
 

Yet, when the Leaf Collector is opened (and if (all) the flow forwarding nodes are Cisco Nexus devices forwarding Netflow v9), the following information is seen in the "Start-Stop Times" section:-   

  • The "Last Stop Time" shows "Never Stopped".
  • The "Last Flush Time" shows "Never Flushed".
  • The "Number of Flows" value is 0.
  • The "Number of Flushed" value is 0.
  • The "Number of Packets" value is 0.

The following messages are seen on the Traffic SPI Leaf's "traffic_spi_leaf_0.log.0" log file:-
(the log file is located at %TrafficDataDir%log\traffic-leaf\ on Windows, and $trafficdatadir/log/traffic-leaf/ on Unix)
.
.
com.hp.ov.nms.spi.traffic.netflow.NetflowAttributeMap [getRequiredTypes]INFO [15] : A required parse attribute - 5 IPToS for this flow is not present in: [SrcIP, DstIP, IPProtocol, NFSNMPInputIndex, NFSNMPOutputIndex, SrcPort, DstPort, TCPFlags, IPToS, NumPackets, NumBytes64, StartTime, EndTime, SrcAS, DstAS, SrcVlanId, DstVlanId]
...com.hp.ov.nms.spi.traffic.netflow.NetflowAttributeMap [getRequiredTypes]INFO [15] :
Present attributes : [8, 12, 4, 7, 11, 10, 14, 61, 6, 1, 2, 22, 21, 48, 60]
Required Attributes [8, 12, 4, 10, 14, 7, 11, 6, 5, 2, 1, 22, 21, 16, 17, 58, 59].

Cause

On a Cisco Nexus Device, running the Nexus-network-Operating-System (NX-OS), a Netflow v9/Flexible-Netflow packet contains certain predefined Field Types. Associated with each Field Type is a Field Identifier (ID).
When these packets are decoded on Wireshark (a free packet sniffing utility), they show up like this:-
 
  
NetflowPacket
 
 
 
Notice the Field Type in the screenshot, in all uppercase, and the corresponding Field ID denoted by numbers within parentheses, e.g. "IP_TOS (5)", "IP_SRC_ADDR (8)" etc.
 
The Traffic Leaf Component contains a parser built into its processing engine, which reads flow data (Netflow, Sflow, or any other supported flow), and converts it into its own software-processable/software-understandable format.
 
In the case of Netflow, the parser requires certain Field Types, which it calls "parse attributes", to be present in the incoming packets. When it does not find these parse attributes, it drops the packets.
 
From the log message we saw earlier, the parser was looking for the following parse attributes to be present:-
[SrcIP, DstIP, IPProtocol, NFSNMPInputIndex, NFSNMPOutputIndex, SrcPort, DstPort, TCPFlags, IPToS, NumPackets, NumBytes64, StartTime, EndTime, SrcAS, DstAS, SrcVlanId, DstVlanId]
...which are respectively associated with the following
Field IDs:-
[8, 12, 4, 10, 14, 7, 11, 6, 5, 2, 1, 22, 21, 16, 17, 58, 59].

While processing the incoming flow, when the parser encoutered the first instance of a missing "required-parse attribute" (Field Type IPToS, with Field ID 5), it wrote the message "...required parse attribute - <FieldID> <Field Type> for this flow is not present..." in the "traffic_spi_leaf_0.log.0" file.

Fix

The Netflow v9/Flexible Netflow Protocols from Cisco are defined in such a way that a flow record requires at least one key field before it can be used in a flow monitor. The key fields differentiate flows, with each flow having a unique set of values for the key fields. The key fields are defined using the match command.
 
On the Cisco Nexus device, make sure that the following key fields are set to be matched in the flow exporter that is configured:-
 
 
 match ipv4 source address
  match ipv4 destination address
  match ipv4 protocol
  match ipv4 tos
  match transport source-port
  match transport destination-port
  match interface input
  match  interface output
  match flow direction
  match ipv4 source mask
  match ipv4 destination mask
 
The NX-OS also allows for the collection of several non-key (non-unique) fields.
Make sure the following non-key fields are to collected in the flow exporter that is configured:-
 
 
  collect transport tcp flags
  collect counter bytes
  collect counter packets
  collect timestamp sys-uptime first
  collect timestamp sys-uptime last
 
This ensures that the Traffic SPI Leaf's parser gets all the required parse attributes to process incoming flows.
 
Note: The steps described are valid even for non-Cisco-Nexus flow forwarders, if they have not been sufficiently configured to meet the required attributes parameters.