Hi Osama, Very good to hear from you. About the UDP ports: field types #180 and #181 are supported but the fact the template contains both these two and their traditional counterparts, field types #7 and #11, kills the heuristics currently in place to decide which one to pick. What is the reason behind putting all together in a single template? If it makes sense to you to remove such redundancy and have pmacct working, good; otherwise please send me privately a brief capture so to improve the current heuristics.
About the MPLS label fields: these are not supported (well, there is an indirect way to aggregate on them via pre-tagging, but i will not propose it to you as a viable solution). I more wonder what is the use-case behind your interest into them - it would be great if you can elaborate on it. Cheers, Paolo On Sun, May 05, 2013 at 11:38:06AM +0200, Osama Abuelsorour wrote: > Hello, > > I've started using pmacct as a collector for few Cisco routers. We are very > interested in mpls labels and other field types. pmacct did pick up most of > them but not all. In addition, it didn't pick up any L4 information because > they were received on the more specific types such as udpSourcePort instead > of l4 src port, etc. > Here is the NFv9 template: > > DEBUG ( default/core ): NfV9 template type : flow > DEBUG ( default/core ): NfV9 template ID : 258 > DEBUG ( default/core ): ----------------------------------------------------- > DEBUG ( default/core ): | pen | field type | offset | size | > DEBUG ( default/core ): | 0 | mpls label 1 | 0 | 3 | > DEBUG ( default/core ): | 0 | mpls label 2 | 3 | 3 | > DEBUG ( default/core ): | 0 | IPv4 src addr | 6 | 4 | > DEBUG ( default/core ): | 0 | IPv4 dst addr | 10 | 4 | > DEBUG ( default/core ): | 0 | L4 src port | 14 | 2 | > DEBUG ( default/core ): | 0 | L4 dst port | 16 | 2 | > DEBUG ( default/core ): | 0 | 186 | 18 | 2 | > DEBUG ( default/core ): | 0 | 180 | 20 | 2 | > DEBUG ( default/core ): | 0 | 181 | 22 | 2 | > DEBUG ( default/core ): | 0 | 234 | 24 | 4 | > DEBUG ( default/core ): | 0 | 44 | 28 | 4 | > DEBUG ( default/core ): | 0 | input snmp | 32 | 4 | > DEBUG ( default/core ): | 0 | 89 | 36 | 1 | > DEBUG ( default/core ): | 0 | BGP IPv4 next hop | 37 | 4 | > DEBUG ( default/core ): | 0 | 45 | 41 | 4 | > DEBUG ( default/core ): | 0 | output snmp | 45 | 4 | > DEBUG ( default/core ): | 0 | direction | 49 | 1 | > DEBUG ( default/core ): | 0 | 235 | 50 | 4 | > DEBUG ( default/core ): | 0 | 95 | 54 | 4 | > DEBUG ( default/core ): | 0 | in bytes | 58 | 8 | > DEBUG ( default/core ): | 0 | first switched | 66 | 4 | > DEBUG ( default/core ): | 0 | last switched | 70 | 4 | > DEBUG ( default/core ): ----------------------------------------------------- > DEBUG ( default/core ): Netflow V9/IPFIX record size : 74 > > Here is a sample output of nfacctd: > TAG TAG2 CLASS VLAN ETYPE SRC_IP > DST_IP SRC_PORT DST_PORT PROTOCOL TOS PACKETS FLOWS > BYTES > 0 0 unknown 0 800 X.X.X.X Y.Y.Y.Y > 0 0 ip 0 0 1 58 > 0 0 unknown 0 800 X.X.X.X Y.Y.Y.Y > 0 0 ip 0 0 1 58 > > The above flows are mpls double tagged. I did a binary dump on the NF packets > and I made sure that the data is actually sent by the router. > > The question is this: is there a simple way to make it recognize the fields > that I want? Then, when it does, can it apply aggregation and accounting on > them as well? > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
