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
