Hi Paolo, On Jun 20, 2013, at 7:23 PM, Paolo Lucente wrote:
> 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. You are right. The #90 is not exported by our equipment (Cisco). It was merely a _wish_ rather than a limitation. > > 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. We already export #234 and #235 capturing the ingress and egress VRF ID respectively (Cisco). You are right, they are 32 bit integers. I did link the results with SNMP (Cisco) OID 1.3.6.1.4.1.9.9.711.1.1.1.1.2 to get their names. Works well. I can provide you with some pcap dumps if you want to have a look. Do you think it is generic enough of a use-case to be incorporated in pmacct? > > 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
