Hi Markus,
:-D 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! Paolo 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 http://www.pmacct.net/#mailinglists
