Hi Yann,

For applications, you can rely on the built-in correlation mechanism.
You may run in the same issue, yes; your feedback would be valuable in
seeing how wide-spreaded is the issue. This used to work.

For interfaces, confirm such correlation is not currently supported; if
possible, could you send me a sample of your flow and options data via
unicast email? In principle it looks something good to do as part of the
post processing, like you are doing right now but i'd like to confirm.

Paolo

On Wed, Jun 07, 2017 at 10:23:58AM +0200, Yann Belin wrote:
> Hi Paolo,
> 
> Thanks for the reply. I'm not doing anything too fancy, only
> correlating two types of fields: Interfaces and Applications.
> 
>   - For applications, I'm using the same fields than Gilad in the
> GitHub issue, except that I'm doing the correlation in post
> processing. Since we are both using Cisco routers, I expect the same
> issues if I try a direct correlation, but I'd be happy to test it /
> send you a pcap in unicast.
>   - For interfaces, I'm receiving fields #10 (input interface snmp id)
> and #14 (output interface snmp id) in data flows, and I'm correlating
> it to option field #82 (interface name short). Option table is indexed
> on field #10.
> 
> I'm pasting below the template layouts for reference.
> 
>   
> _____________________________________________________________________________
>   |                 Field                   |    ID | Ent.ID | Offset |  Size 
> |
>   
> -----------------------------------------------------------------------------
>   | INTERFACE INPUT SNMP                    |    10 |        |      0 |     4 
> |
>   | interface name short                    |    82 |        |      4 |    32 
> |
>   | interface name long                     |    83 |        |     36 |    64 
> |
>   
> -----------------------------------------------------------------------------
> 
>   
> _____________________________________________________________________________
>   |                 Field                   |    ID | Ent.ID | Offset |  Size 
> |
>   
> -----------------------------------------------------------------------------
>   | APPLICATION ID                          |    95 |        |      0 |     4 
> |
>   | application name                        |    96 |        |      4 |    24 
> |
>   | application description                 |    94 |        |     28 |    55 
> |
>   
> -----------------------------------------------------------------------------
> 
>   
> _____________________________________________________________________________
>   |                 Field                   |    ID | Ent.ID | Offset |  Size 
> |
>   
> -----------------------------------------------------------------------------
>  (...)
>   | application id                          |    95 |        |      8 |     4 
> |
>   | interface input snmp                    |    10 |        |     12 |     4 
> |
>   | interface output snmp                   |    14 |        |     16 |     4 
> |
>  (...)
>   
> -----------------------------------------------------------------------------
> 
> Yann
> 
> On Tue, Jun 6, 2017 at 9:05 PM, Paolo Lucente <pa...@pmacct.net> wrote:
> >
> > Hi Yann,
> >
> > Great point. There are a very few cases where pmacct does the magics of
> > correlating actual data to options on your behalf, ie. sampling rate and
> > application ID. So, given the current functionality, it sounds you are
> > doing the right thing saving both and correlating it afterwards as part
> > of your post-processing. It would be great to know - here or via unicast
> > email - what kind of correlation you are doing.
> >
> > Paolo
> >
> >
> > On Tue, Jun 06, 2017 at 03:28:30PM +0200, Yann Belin wrote:
> >> Hi,
> >>
> >> I was reading trough recent issues on GitHub, and #137 [see link
> >> below] got my attention. The last comment from Paolo leads me to think
> >> that nfacctd can be configured to (try to) automatically match flow
> >> data to option table(s).
> >>
> >> Is it the case, or am I misreading something? Until now, I have been
> >> collecting data and options separately (using nfacctd_account_options)
> >> and had to match it afterwards via a script; such feature could make
> >> my life quite easier.
> >>
> >> Ref. https://github.com/pmacct/pmacct/issues/137
> >>
> >> Thanks,
> >>
> >> Yann
> >>
> >> _______________________________________________
> >> pmacct-discussion mailing list
> >> http://www.pmacct.net/#mailinglists
> >
> > _______________________________________________
> > pmacct-discussion mailing list
> > http://www.pmacct.net/#mailinglists

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Reply via email to