Cisco Nexus 7010 Flow setup

[hoffswell]

Hi -

This is a repeat of an older issue, but I thought I'd start a new thread. It's been a while. I'm a new Scrutinizer user.

Installation of a netflow export to scrutinizer yields the following when trying to add the 7010 to the source list for Top Subnet Traffic:

Code: Select all

Some devices do not export the correct information for this algorithm
Name   TemplateID   Template Missing Columns
1lan<snip>   10000   sourceIPPrefixLength, destinationIPPrefixLength

I found that the solution was to export flow data from the nexus as version 5, as opposed to version 9.

Here's my precise config, in case anyone can use it:

Code: Select all


feature netflow

flow exporter scrutinizer
  description exportV5 to scrutinizer
  destination 1.1.1.1 <ip of scrutinizer box>
  transport udp 2055
  source Vlan1
  version 5

flow monitor to-scrutinizer
  description flows to scrutinizer
  record netflow-original
  exporter scrutinizer


interface Vlan10
  ip flow monitor to-scrutinizer input 

interface Vlan11
  ip flow monitor to-scrutinizer input 

interface Vlan12
  ip flow monitor to-scrutinizer input 




Note that I'm using the pre-installed netflow record "netflow-original" so I do not need to define the record further. For the record, that record looks like this:

Code: Select all


# show flow record netflow-original

Flow record netflow-original:
    Description: Traditional IPv4 input NetFlow with origin ASs
    No. of users: 2
    Template ID: 258
    Fields:
        match ipv4 source address
        match ipv4 destination address
        match ip protocol
        match ip tos
        match transport source-port
        match transport destination-port
        match interface input
        match interface output
        match flow direction
        collect routing source as
        collect routing destination as
        collect routing next-hop address ipv4
        collect transport tcp flags
        collect counter bytes
        collect counter packets
        collect timestamp sys-uptime first
        collect timestamp sys-uptime last



I hope this helps!

[scottr]

Thank you for the information.

It does seem a little strange that a netflow version 9 record would not have the source and destination IPPrefixlength fields and v5 does.

If you look at the template view of the v9 record do you see these header fields?

Scott

[hoffswell]

I'm afraid I'm not a grand-master of netflow packet layout, but I do see this:

http://www.cisco.com/en/US/technologies ... a3db9.html

NetFlow Version 9 Flow-Record Format

I do not see a specific reference to sourceIPPrefixLength, destinationIPPrefixLength.

I wonder if the template refers to them as SRC_MASK and DST_MASK.

As per your:

http://www.plixer.com/support/netflow_v9.html

While the nexus would show up when I pointed the v9 flows at the scrutinizer, this missing data made it so I could not add the device to some of the analytics.

[scottr]

I know that it is probably to late now, since you have v5 templates working OK, but could you do a source or destination subnet report from the status screen when you were sending v9?

Scott

[hoffswell]

Good morning -

I changed it to v9, and see a new "unknown: custom flows (10000)" entry on the report selector, under the v5 option.

When I run a source subnet report under this, I get this:

Code: Select all

The current report requires the following columns:
egressInterface, ingressInterface, sourceIPAddress, sourceIPPrefixLength, octetDeltaCount
Device(s) exports the following templates:
NetFlow v5 (5) is missing columns:
Click here to view a list of report types and their required columns

Maybe there is some customization on the Nexus end that will alleviate this issue?

Happy to help, if I can.

[scottr]

Hi,

So with a version 5 template you were able to add the device to the gadget in Flow Analytics, but not able to open the subnet report?

Here is what I think is occuring. The Nexus is sending down the fields in the template as src_mask and dst_mask, instead of sourceIPPrefix and DestIPPprefix. I have been looking at some documentation to see if there is any collect statement that you can add to the flow record.

Can you email me a screenshot of the flowview of the template. scottr@plixer.com

Also, if you are evaluating, you do get full support from the pre-sales tech. She maybe able to work via a gotomeeting to check this out. 207-324-8805 x3

Scott

[hoffswell]

Hi Scott -

Yes, we are in the evaluation period. It is possible that my issue is a noob issue.

We are going to do a reinstall, as our current server is low on disk. A new virtual is being created, and I will set up a new exporter with v9. If it works, it does, otherwise, I'll get on support.

[hoffswell]

Reporting back -

Cisco has told me that the sourceIPPrefixLength, destinationIPPrefixLength fields are not supported by NX/OS.

Cisco said, specifically:

"I heard back from the dev team and it looks like the hardware does not support source/dest prefix length, therefore that why 0 is returned. It doesn’t matter if version 5 or 9 is used, the hardware does not store the prefix in the cache."

The work-around for Scrutinizer is to use a network range filter, and not look at the subnets reports or search filters.

So, for our remote site, with networks -

10.3.0.0/16, 192.168.12.0/24, 192.168.13.0/24

the search filters can be, for example -

10.3.0.0 - 10.3.255.255
192.168.12.0 - 192.198.13.255


The only problem with this is that you loose the "top subnets" reports.

[scottr]

Hello,

Can you send me a screenshot of the template view from this device?
It may take a couple of shots as you scroll to the right.

Scott
scottr@plixer.com