Hi Joel,
You are correct. It appears sampling information is not passed over
by the NetFlow exporter. I will let anybody else on this list using
Juniper & IPFIX recently reply more broadly but: my experience on
this up to 2011 is captured here:
https://puck.nether.net/pipermail/juniper-nsp/2011-January/018838.html
and back then there was no option to explicitely enable sending
sampling info (i was wondering the same since on IOS you have such
knob).
That said, pmacct supports counters renormalization basing upon
sampling information passed in IEs #34-35. The first that sees a
working IPFIX implementation based on IEs #304-311 please drop me
a brief trace so that i can align pmacct accordingly.
Cheers,
Paolo
On Sat, Dec 07, 2013 at 08:55:10AM -0800, Joel Krauska wrote:
> Maybe answering my own question...
>
> It looks like IPFIX fields 304-311 are used to identify sampling
> information.
> http://www.iana.org/assignments/ipfix/ipfix.xhtml
>
> I am not seeing these field types with debug turned on. (-d)
>
> DEBUG ( default/core ): NfV10 agent : :::
> DEBUG ( default/core ): NfV10 template type : flow
> DEBUG ( default/core ): NfV10 template ID : 256
> DEBUG ( default/core ):
> -
> DEBUG ( default/core ): |pen | field type | offset | size
> |
> DEBUG ( default/core ): | 0 | IPv4 src addr | 0 | 4
> |
> DEBUG ( default/core ): | 0 | IPv4 dst addr | 4 | 4
> |
> DEBUG ( default/core ): | 0 | tos| 8 | 1
> |
> DEBUG ( default/core ): | 0 | L4 protocol| 9 | 1
> |
> DEBUG ( default/core ): | 0 | L4 src port| 10 | 2
> |
> DEBUG ( default/core ): | 0 | L4 dst port| 12 | 2
> |
> DEBUG ( default/core ): | 0 | icmp type | 14 | 2
> |
> DEBUG ( default/core ): | 0 | input snmp | 16 | 4
> |
> DEBUG ( default/core ): | 0 | IPv4 src mask | 20 | 1
> |
> DEBUG ( default/core ): | 0 | IPv4 dst mask | 21 | 1
> |
> DEBUG ( default/core ): | 0 | src as | 22 | 4
> |
> DEBUG ( default/core ): | 0 | dst as | 26 | 4
> |
> DEBUG ( default/core ): | 0 | IPv4 next hop | 30 | 4
> |
> DEBUG ( default/core ): | 0 | tcp flags | 34 | 1
> |
> DEBUG ( default/core ): | 0 | output snmp| 35 | 4
> |
> DEBUG ( default/core ): | 0 | in bytes | 39 | 8
> |
> DEBUG ( default/core ): | 0 | in packets | 47 | 8
> |
> DEBUG ( default/core ): | 0 | 152| 55 | 8
> |
> DEBUG ( default/core ): | 0 | 153| 63 | 8
> |
> DEBUG ( default/core ): | 0 | 136| 71 | 1
> |
> DEBUG ( default/core ):
> -
> DEBUG ( default/core ): Netflow V9/IPFIX record size : 72
> DEBUG ( default/core ):
> DEBUG ( default/core ): NfV10 agent : :::
> DEBUG ( default/core ): NfV10 template type : options
> DEBUG ( default/core ): NfV10 template ID : 512
> DEBUG ( default/core ):
> DEBUG ( default/core ): | field type | offset | size |
> DEBUG ( default/core ): | 144| 0 | 4 |
> DEBUG ( default/core ): | 160| 4 | 8 |
> DEBUG ( default/core ): | 130| 12 | 4 |
> DEBUG ( default/core ): | 214| 16 | 1 |
> DEBUG ( default/core ): | 215| 17 | 1 |
> DEBUG ( default/core ):
> -
> DEBUG ( default/core ): Netflow V9/IPFIX record size : 18
>
> So it looks like my router (MX80) isn't sending this data...
>
> Maybe it's a JunOS config option?
>
> --Joel
>
>
> On Sat, Dec 7, 2013 at 8:46 AM, Joel Krauska wrote:
>
> > Should I expect sampling 'correction' scaling to work with IPFIX?
> >
> > I have this configuration, but my byte counts appear to be off by our
> > scaling factor.
> > nfacctd_renormalize: true
> >
> > Is there a debug/log message that would identify the netflow sampling rate
> > detected?
> >
> > It looks like I can hardcode with nfacctd_ext_sampling_rate or a sampling
> > map, but I was hoping IPFIX would be transmitting the rate.
> >
> > Cheers,
> >
> > Joel
> >
> >
> >
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists
___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
