Regarding IPFIX from inline-jflow, I did a Wireshark capture and it looks
like the MX80 is sending erroneous srcAS, dstAS information within the
IPFIX records. I've taken this up with Juniper. Nfdump seems to be doing
the right thing with IPFIX.

Thanks for your replies on this.

Regards

Bruce
--
street address:  AARNet, POD 3, 20 Dick Perry Ave, Kensington, WA 6151,
Australia
m. 0408 882 390     t. +61 8 9289 2212      e.  [email protected]
w. www.aarnet.edu.au





On 18/07/12 12:03 PM, "Dave hartzell" <[email protected]> wrote:

>I'm also having problems with IPFIX from inline-jflow (MX-480)...
>
>My records are recorded as such (manually randomized):
>
>Date flow start          Duration Proto      Src IP Addr:Port
>Dst IP Addr:Port   Packets    Bytes Flows
>1970-01-01 00:00:00.000     0.000 TCP     1y0.xx.206.200:59812 ->
>1zz.172.21.198:38159        0        0     1
>1970-01-01 00:00:00.000     0.000 TCP     1y0.xx.206.203:36276 ->
>1zz.172.21.196:38001        0        0     1
>1970-01-01 00:00:00.000     0.000 TCP     1y0.xx.206.194:1217  ->
>1zz.172.21.197:53452        0        0     1
>1970-01-01 00:00:00.000     0.000 TCP       172.16.20.23:50104 ->
>192.168.133.215:19764        0        0
>
>Lots of zero values in the fields, and basically a zero date.
>
>From what I can tell, this might be Junos version related, as I don't
>see this on a Junos 10.3 (to a different 1.6.6 collector).  Here is
>the problematic 10.4 config:
>
>family inet {
>            output {
>                flow-server 192.xx.mm.nn {
>                    port 4739;
>                    autonomous-system-type origin;
>                    no-local-dump;
>                    version-ipfix {
>                        template {
>                            ipv4;
>                        }
>                    }
>                }
>                inline-jflow {
>                    source-address 192.168.xx.yy;
>                }
>            }
>        }
>    }
>
>The Wireshark decodes of the IPFIX packets look fine....
>
>Dave
>
>
>
>On Tue, Jul 17, 2012 at 8:45 PM, Bruce Morgan
><[email protected]> wrote:
>> I'm using inline jflow on an MX80 configured for IPFIX export and the
>> records get generated and exported except all the srcas, dstas fields
>>are
>> sort of scrambled but rather uniformly.
>>
>> The following is a list of some transpositions:
>> Real AS -> NFDump reported AS
>> 786  -> 786
>> 65511 -> 20454
>> 38083 -> 21474
>> 15169 -> 57369
>> 4134 -> 4134
>>
>> Anyone seen this before? Is there an issue with the nfdump beta code for
>> IPFIX? As far as I can tell nfdump seems to be reporting fine with the
>>other
>> fields.
>>
>> Regards
>>
>> Bruce
>>
>> --
>> street address:  AARNet, POD 3, 20 Dick Perry Ave, Kensington, WA 6151,
>> Australia
>> m. 0408 882 390     t. +61 8 9289 2212      e.
>>[email protected]
>> w. www.aarnet.edu.au
>>
>> 
>>-------------------------------------------------------------------------
>>-----
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>>Discussions
>> will include endpoint security, mobile security and the latest in
>>malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Nfdump-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
>>


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Nfdump-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss

Reply via email to