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
