Using NTA with DragonFly FlowMeter nprobe NetFlow collection appliance

Hi,

Does anyone have any experience using NTA with Dragonfly nprobe appliances? We're using the Dragonfly Flowmeter. Like a lot of nprobe implementations, we've spanned a port off of a Cisco switch, and the Dragonfly's collector interface connects to the span port. Then we've got a network uplink over which the processed Netflow data is sent to our NTA server.

NTA shows Netflows as being received, but at the same time it keeps showing error messages about "receiving a NetFlow data stream from an unmanaged interface", and the NTA output just shows a single conversation between a multicast address and a VLAN interface on a switch. There's no information on client endpoints or Internet traffic, even though I've used Wireshark to confirm that Netflows are being received by the NTA server, and I can even drill down into the Wireshark trace and see the individual client endpoints in the Netflows.

So it appears the Dragonfly appliance is sending the appropriate Netflow data, but NTA isn't interpreting it correctly. Any ideas? I read some posts about adjusting interface indexes on nprobe implementations, but I'm not sure how I'd do that with this Dragonfly appliance.

FYI - I'm currently monitoring all available interfaces on the Dragonfly appliance - these consist of Lo, eth0, eth1 and pcapx0. Also, I've set the Dragonfly to send Netflow v9.

Thanks.

Find more posts tagged with

Accepted answers

FormerMember

The resolution, apparently, was that the Dragonfly engineers added a patch to their appliance that set the ifIndex for the different Netflows to a static value. When I checked the latest Wireshark traces, I saw that the ifIndex for each flow was indeed remaining constant (in this case 4), rather than changing with each flow. However, I'd been instructed by the Dragonfly engineers to have SolarWinds discover and monitor the eth0 interface on their appliance. But SolarWinds showed that the ifIndex for eth0 was 2, not 4. I ran another SNMP discovery of the Dragonfly box and found that ifIndex 4 belonged to a pcap interface called "pcapx0". Once I added that interface as a Netflow source, I started seeing the expected Netflow data.

So if anyone ever tries to use a Dragonfly nflow appliance with SolarWinds, that was our solution (at least the solution that's currently working for us).

All comments

mcbridea

What are you seeing as the export interface index number on the PCAP?

FormerMember

The pcap "interface" displays like this: "pcapx0". So I guess its index number is 0? But it doesn't show up as an interface on the Dragonfly appliance, it only shows up when I discover the device with SolarWinds via SNMP.

FormerMember

Correction - the pcap index is actually 4. However, I was working with SolarWinds support on this and we confirmed that the Netflow is actually coming from eth0, which has an index of 2. When we examined some Wireshark captures of the Netflow data being sent to the Orion server, we didn't see this index number reflected anywhere. Instead, in the Wireshark trace, when we drilled down into the individual flows, we found the following (note the last two lines, in bold):

Cisco NetFlow/IPFIX
    Version: 9
    Count: 3
    SysUptime: 360075
    Timestamp: Aug 17, 2010 15:42:00.000000000
        CurrentSecs: 1282074120
    FlowSequence: 122
    SourceId: 0
    FlowSet 1
        Data FlowSet (Template Id): 257
        FlowSet Length: 948
        Flow 1
            SrcAddr: x.x.x.x
            SrcPort: 61320
            DstAddr: x.x.x.x
            DstPort: 53
            NextHop: 0.0.0.0 (0.0.0.0)
            InputInt: 41250
               OutputInt: 64195

The SolarWinds tech thought that one of these should represent the If index, which according to our SNMP discovery should be "2".

So that's where we're stuck now. I'm going to send SolarWinds some traces and some info about our Dragonfly nprobe collector and see if they can determine the problem.

FormerMember

So if anyone ever tries to use a Dragonfly nflow appliance with SolarWinds, that was our solution (at least the solution that's currently working for us).