[netsa-tools-discuss] Reflecting ipfix flow to another collector

[Mark Thomas]

Ruth-

I am glad you have found a work-around for receiving multiple
versions of NetFlow on a single port, but I am sorry it is not
working for the IPFIX records.

There is nothing in flowcap (libfixbuf) itself that performs a
checksum on the data it receives.  Flowcap relies on the network
stack in the operating system to verify the checksums in the IP and
UDP headers.  Since the checksums are being accepted for the NetFlow
v5 and NetFlow v9 streams, I would also expect them to be accepted
for the IPFIX stream.

For the probe that is listening for IPFIX data, are you seeing any
messages similar to the following?

  Aug  4 15:46:34 myhost flowcap[98836]: 'S10': accepted connection from 127.0.0.1:55036, domain 0x0000

My IPFIX-receiving probe is defined as:

  probe S10 ipfix
    protocol udp
    listen-on-port 9991
    listen-as-host 127.0.0.1
  end probe

If you are seeing that message but you are getting no data and you
are not getting any error messages, I am not certain what may be
happening.  libfixbuf is typically good at telling you why it is
rejecting packets.

If you are not seeing the "accepted connection" message, that
probably means the data is not reaching flowcap.  To fix this,
verify that the firewall is not blocking packets and double check
port, protocol, and host settings.

Another problem that sometimes occurs is when a port that flowcap
wants to use is already in use by a host listening on an IPv4
address.  flowcap may bind to the only the IPv6 address, so it is
listening, but not where you think it is.  This issue can be
difficult to debug.

The following bit of Perl code can be used to test an IPFIX UDP
connection.  Change "127.0.0.1:9991" to the host and port where data
is being received.

  #! /usr/bin/perl
  use IO::Socket::INET;
  $s = IO::Socket::INET->new(PeerAddr=>"127.0.0.1:9991", Proto=>"udp")
      or die "socket: $!";
  for (0..10) {
      $data = pack("nnNNN", 10, 16, time, $_, 0xaeaeaeae);
      send($s, $data, 0)
          or die "send: $!";
  }

Running that code causes the flowcap log to show the above "accepted
connection" message followed by a series of messages

  Aug  4 15:46:34 myhost flowcap[98836]: IPFIX Message out of sequence (in domain aeaeaeae, expected 00000001, got 00000002)
  Aug  4 15:46:34 myhost flowcap[98836]: IPFIX Message out of sequence (in domain aeaeaeae, expected 00000002, got 00000003)


Having your reflector maintain the source IP of the incoming packets
is one way to work around the problem of

> the packets all looked like they were coming from the same source,
> but were actually from different routers, so the templates got
> mixed up between the different sources.

An alternate approach is to modify each stream to have a unique
observation domain in the IPFIX/NetFlow v9 header.  It is easiest if
you can do this at the router generating the flow records.

-Mark


On Tue, 4 Aug 2015 13:07:12 +0000, Ruth J. Poole wrote:

> Hello all,
>
> In our setup, we have a udp packet reflector which receives feeds from
> multiple sources.  Our feed consists of netflow v5, v9, and IPFIX, so
> we split the feed by netflow version, so that we can run separate
> instances of flowcap for each version.  We were having issues with the
> v9 and IPFIX not getting read correctly because by going through the
> reflector, the packets all looked like they were coming from the same
> source, but were actually from different routers, so the templates got
> mixed up between the different sources.  We modified the reflector so
> that now it retains the original source address in the ip and udp
> headers.  The v5 and v9 flowcop collectors now process the incoming
> packets correctly.  The IPFIX collector, however, appears to be
> rejecting the incoming packets from the reflector.  The reflector sets
> the ip checksum to zero and it gets recalculated.  It calculates and
> sets the udp header.  I have checked the packets in Wireshark, and the
> ip and udp checksums are correct.  I'm wondering is flowcap doing
> validation on the md5 checksum in the IPFIX records and rejecting them
> because it no longer matches after modifying the destination address
> in the original packet? I don't get any error messages even with
> log-level=debug Is there a way to turn off this validation in flowcap?
> Or do I have to also calculate a new md5 checksum in the reflector?
>
> Ruth Poole
> Phone: 507-284-0456
> Email: poole.ruth at mayo.edu<mailto:poole.ruth at mayo.edu>