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:


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?


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

Reply via email to