[nsp] In-Depth experience with Netflow Prefix Aggregation?

From: Gert Doering (gert@greenie.muc.de)
Date: Thu Oct 11 2001 - 09:08:16 EDT

Hi,

does one of you have "in-depth experience" with bouter-based netflow
aggregation, to be specific, prefix aggregation?

I did some testing with it today, using the packet documentation in
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/\
        nfc_3_0/nfc_ug/nfcform.htm
(wrapped by hand), and it seems that the "src_mask" and "dst_mask"
fields for the "RouterPrefix Flow Record Format" are sent in the
wrong order.

By this, I mean:

 * I send packets from 131.159.72.4 which is part of 131.159.0.0/16,
   to 195.30.33.252/32, which is a NAT router behind a leased line.

 * The reply packets trigger a netflow export entry, which is then
   aggregated on the router to "195.30.33.252/<src_mask> ->
   131.159.0.0/<dst_mask>".

 * The entry is correctly displayed in "show ip cache flow agg pref"
   (10 pings, load-shared over 2 interfaces):

Src If Src Prefix Msk Dst If Dst Prefix Msk Flows Pkts
Se1/0/7:1 195.30.33.252 /32 Fa6/0/0 131.159.0.0 /16 1 5
Se1/0/7:2 195.30.33.252 /32 Fa6/0/0 131.159.0.0 /16 1 5

 * The problem is: when this entry is exported, the "src_mask" (byte 28)
   is set to 16, and the "dst_mask" (byte 29) is set to 32, which is just
   the wrong way round

The box in question is a 7500 with 12.0(17)S1.

I checked the data structures and their usage in my test program a number
of times now, and they *seem* to be correct.

Further investigation using tcpdump led me to this:

14:59:27.690552 Cisco-F-V-Lo0.Space.Net.53372 > turing2.Space.Net.2055: udp 108
                         4500 0088 0010 0000 fd11 0c79 c195 2c0e
                         c31e 001a d07c 0807 0074 548c 0008 0002
                         44d8 39cc 3bc5 97a4 2648 bb60 0000 0023
                         0000 0502 0000 0000 0000 0001 0000 0005
                         0000 01a4 44d7 a4c0 44d7 c448 c31e 21fc
                         839f 0000 1020 0000 0000 02a8 0031 0018
                         0000 0001 0000 0005 0000 01a4 44d7 a8a8
                         44d7 c838 c31e 21fc 839f 0000 1020 0000
                         0000 02a8 0032 0018

which, decoded, gives:

v8e/p: 195.30.33.252/16 -> 131.159.0.0/32, 5, 420, src_as=0, dst_as=680
v8e/p: 195.30.33.252/16 -> 131.159.0.0/32, 5, 420, src_as=0, dst_as=680

and if you check the hex numbers vs. the URL listed above, the "0x1020"
values are the mask lengths in question, decode to /16 -> /32.

So, I think my question boils down to:

 - is this a documentation or IOS bug?

 - does anybody care (that is: does anybody use prefix aggregation with
   a smaller "mask source/destination minimum" than 32 - in which cases
   both ends are a /32 and thus don't matter)?

regards,

gert 

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert.doering@physik.tu-muenchen.de

This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:19 EDT