Hi Osama, Very good to know, great stuff. About the extra fields your colleagues would be seeking for: it would make a lot of sense to include support for field type #90, do you have it populated in your NetFlow export? If yes, i would highly appreciate to receive privately a brief trace which includes the field (even if you kindly have some room to implement this yourself). Thing is, in IPFIX (*) this field is defined as octetArray which, in turn, smells variable-legth (which in turn means it requires IPFIX rather than NetFlow v9 to be implemented properly). Let me know, i'm very curious. I did not manage to see it populated in any of the egress NetFlow traces i've been looking through.
Curious also about the other set of fields you were speaking about: i saw them only included as part of some NSEL exports but always empty: their size, unsigned32, does not coincide with the size of a MPLS RD so i wonder what is being actually encapsulated in there. Cheers, Paolo (*) http://www.iana.org/assignments/ipfix/ipfix.xml On Thu, Jun 20, 2013 at 03:09:09PM +0200, Osama Abuelsorour wrote: > Hi Paolo, > > I've just tested the new CVS version. Indeed the three primitives > mpls_label_bottom and mpls_label_top show in our aggregations. The > combination of this and *_iface primitives would help us classify traffic > from the core side. > > I'll work a bit more on it to come up with a process that combines with it > SNMP (for interface indices and labels resolution). If it is generic enough, > I will contribute it. > > p.s. Some guys in my team are getting a bit more greedy: They were wondering > about the mplsVpnRouteDistinguisher (#90) and VRF stuff (#234, #235, #236). > If I have time next week, I might just add them myself (unless you are > already working on that). > > Thanks again for the great work! > > On Jun 9, 2013, at 12:49 AM, Paolo Lucente wrote: > > > Briefly to follow-up on this, to say: > > > > * support has now been introduced for MPLS_TOP_LABEL_ADDR (NetFlow v9/ > > IPFIX field type #47) which is mapped to peer_dst_ip field, ie. where > > typically BGP next-hop is written to. It would be nice if you could > > confirm presence of this field in your export (maybe along vendor and > > model information). > > > > * support has also been introduced for top and bottom MPLS labels (top > > is intuitively MPLS_LABEL_1 whereas bottom is determined dinamically > > by checking the BoS bit): mpls_label_top and mpls_label_bottom. If a > > flow has only a single label the value of twos will coincide. Having > > visibility of the top label value is especially useful to resolve > > the BGP next-hop in cases in which MPLS_TOP_LABEL_ADDR field is not > > available; the mpls_label_bottom is key in resolving which L2/L3 > > MPLS VPN, if any, traffic belongs to. > > > > * To further help in distinguishing VPN traffic, a derived primitive > > has also been made available: mpls_stack_depth. > > > > This is all available pulling the code from the CVS. Hope this helps, > > looking forward at receiving feedback. > > > > Cheers, > > Paolo > > > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
