Hi Markus,
You are indeed right about the status quo of src_as_path. If you see, there is a bgp_peer_src_as_type that can be set to 'map' and a bgp_peer_src_as_map that allows to provide a map very similar to what you described: https://github.com/pmacct/pmacct/blob/1.7.1/examples/peers.map.example See the input interface, the bgp_nexthop (RPF), potentially src_mac and vlan (if vendors would dare one day to support these in NetFlow/IPFIX for kits they sell to SPs - or if using sFlow) knobs. What this will return is a peer source ASN instead of the full AS-PATH: would you like to experiment / PoC and, if happy enough, we can build an equivalent feature - with all the obvious disclaimers possible to inform about otential inaccuracy - for AS-PATH? How does it sound? Paolo On Mon, Aug 20, 2018 at 02:26:27PM +0200, Markus Weber wrote: > Hi Paolo (and others), > > nfacctd: am I correct that src_as_path is filled in by looking > up best path for src_ip in the agent's associated RIB and then > use that one? > > If so then src_as_path would be wrong for asymmetric traffic > (as stated in the documents) e.g. if traffic on PE comes in > from peer A, but reverse path is preferred for peer B (or via > iBGP). > > However, with ADD-PATH the "more likely" correct src_as_path > might be in the RIB. > > Naive as I am I would think that a map like (similar to other > src maps e.g MED, local pref, peer) > > ip_src_bgpnexthop=<NH or list of NHs> id=<PE> in=<IngressIf> > > could hint the src_as_path lookup by using ip_src_bgpnexthop for > NF packets received from PE ingressing on IngressIf to find a > RIB entry with a matching NH. > > True, there would be only a benefit for ADD-PATH, mostly only > for the first AS (as everything behind remains pure guessing), > the ip_src_bgpnexthop would have to be multiple IPs (e.g. v4 & v6), > multi-point links (like IX) without src_mac (another possible > match field) are still "pure luck to get it right" and the case > "what to do" and "how to mark" if no match is found (or multiple > matches) is another question (*). > > How hard do you think would it be (and I fear this goes beyond > my *current* understanding of the code ...) to implement this? > > Or is that just a stupid useless idea? > > Cheers, > Markus > > > (*) It would be nice also to have some kind of optional flag if > lookup was successful and src_as_path lookup is most likely > "symmetric" or not; and fallback to current behavior ... > > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
