Hi Markus,


I like the idea of discussing this at NLNOG to review: intended goals
(ie. why src_as_path is important at all) and how the current feature
works and if/how it can help. Entirely agree with your point "but if
quality could be here improved upfront, it's always good".

Look forward! 


On Wed, Aug 22, 2018 at 12:18:06PM +0200, Markus Weber wrote:
> Hi Paolo,
> guess you remember who introduced here pmacct and with it the use
> of the peer maps, don't you? If not - do I have to get concerned?
> What you outlined sounds great but I must admit my understanding
> of the code is (not yet) sufficient to even start to work on this
> (neither on my own nor guided). I know you love contributions ...
> Further I would suggest to first outline the "function" of such a
> feature in more detail, the side effects, corner cases and alike
> and maybe evaluate if such a feature is of much use at all to have
> it in the code base.
> It certainly may improve the src_as_path quality, but everything
> beyond the adjacent AS remains still pure guessing.
> So while bgp_peer_src_as_map is great for private interconnects to
> ensure correct adjacent peer AS and to some extend for IXes (works
> often better than expected), src_as_path comes with a significant
> higher uncertainty.
> OTOH, what we observe now is often mismatches of src_as_path's first
> AS and forced set bgp_peer_src_as via peer.maps (with asymmetric
> traffic). Something which could be marked during post-processing
> step, but if quality could be here improved upfront, it's always
> good ...
> I'll try to find some time in the next weeks and maybe we can
> talk about it at NLNOG - if not earlier, but I doubt I'll be much
> further then.
> Best regards,
> Markus
> On 21.08.2018 around 19:21 Paolo Lucente wrote:
> >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

pmacct-discussion mailing list

Reply via email to