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

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?


(*) 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

Reply via email to