Re: [pmacct-discussion] src_as_path finding
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= id= in= > >> > >>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
Re: [pmacct-discussion] src_as_path finding
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= id= in= 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
Re: [pmacct-discussion] src_as_path finding
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= id= in= > > 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] src_as_path finding
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= id= in= 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
