Summary
Error
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:-
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.