Re: [pmacct-discussion] pmacctd and src_std_comm aggregation
Ciao Simone, You see, that is the thing with the example you proposed: it is very likely that one of the two paths is not in the RIB (like you said) so you can't really make 'suggestions', you have to force it through a static mapping; i do see people being fine with that for the Peer Source ASN because in majority of cases (not all, ie. some remote peerings may escape this scheme depending how they are built) you may map it 1:1 to an interface, a VLAN or a MAC address. But being the communities bound to a NLRI, anything static does not really scale (and that is the main reason the knob is not there today). So your alternate idea, let's make the path visible via ADD-PATH:, sure, that would be actually a nice test to use your lab for. A possible logics could be (again as you suggested): 1) a bgp_peer_src_as_map compiled as you do today + bgp_nexthop (key already supported so zero work there), to associate ASNs, the expected next-hop and interface / VLAN / MAC address; 2) have a BGP session with ADD-PATH so that the multiple paths remain visible (also here zero work to do) and 3) use the BGP next-hop info in the bgp_peer_src_as_map as selector in the ADD-PATH vector (also this is logics already existing BUT NOT in conjunction with a BGP next-hop fed by a bgp_peer_src_as_map or, let me re-phrase, at least this is untested / uncharted territory). Sounds like fun. Shall we move to unicast email for lab access and arranging all the different pieces? Since it's not urgent, doing some spare-time work on it, i guess we can converge on this in a week or a couple. Paolo On Mon, May 25, 2020 at 06:21:56PM +0200, Simone Ricci wrote: > Ciao Paolo, > > > Il giorno 25 mag 2020, alle ore 16:03, Paolo Lucente ha > > scritto: > > > > Ciao Simone, > > > > If i got it correct you are after static mapping of communities to input > > traffic - given an input interface / vlan or an ingress router or a > > source MAC address. > > Yes, just to be clear imagine this scenario: > > route 192.0.2.0/24, originated by AS1000, coming in from two upstreams > (AS100, AS200) announced as follows: > > 192.0.2.0/24 100 500 1000 (100:100) > 192.0.2.0/24 200 1000 (200:100) > > Obviously the path via AS200 will be the best one, so pmacctd always attaches > community 200:100 to inbound traffic…even if enters via AS100 (it can > discriminate the peer src AS thanks to the relevant map) > > > It seems doable, like you said, adding a machinery > > like it exists for the source peer ASN. > > If I understand correctly, in nfacctd/sfacctd the association is done looking > at the BGP next-hop attribute; maybe it’s possible to sort it out just by > “extending” the existing map to let the user “suggest” that traffic matching > a relevant filter has a specific bgp next-hop as well as a peer src AS…but > I’m just thinking out loud here. > > > I'd have one question for you: > > > > How would the 'output' look like: one single community or a list of > > communities (ths may make less sense but still i'd like to double-check > > with you)? > > Regarding the format, the actual output will be OK (single string, > communities separated by _), as I push everything via AMQP and parsing gets > done upper in the stack; it’s not a bad thing, when considering that not all > databases are going to accept arrays of objects and that trasformation is > easily supported by a lot of tooling (be it logstash, telegraph, fluentd…) > > > I guess you may be interested in either standard or large > > communities but not extended, true? And, if true, would you have any > > preferences among the two? Perhaps the standard ones since you mention > > 'src_std_comm’? > > At the moment the support for the standard ones will suffice, for me > > > It's not a biggie and i guess i can converge on this relatively soon; > > can you confrm your priority / urgency? > > Oh it’s not urgent at all, but it would be a very nice-to-have feature which > helps getting a lot of interesting insights. > Just one thing: as you may remember I’ve got a nice testing environment that > you’re welcome to use if it helps. > > Thank you! > Simone. > ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] pmacctd and src_std_comm aggregation
Ciao Paolo, > Il giorno 25 mag 2020, alle ore 16:03, Paolo Lucente ha > scritto: > > Ciao Simone, > > If i got it correct you are after static mapping of communities to input > traffic - given an input interface / vlan or an ingress router or a > source MAC address. Yes, just to be clear imagine this scenario: route 192.0.2.0/24, originated by AS1000, coming in from two upstreams (AS100, AS200) announced as follows: 192.0.2.0/24 100 500 1000 (100:100) 192.0.2.0/24 200 1000 (200:100) Obviously the path via AS200 will be the best one, so pmacctd always attaches community 200:100 to inbound traffic…even if enters via AS100 (it can discriminate the peer src AS thanks to the relevant map) > It seems doable, like you said, adding a machinery > like it exists for the source peer ASN. If I understand correctly, in nfacctd/sfacctd the association is done looking at the BGP next-hop attribute; maybe it’s possible to sort it out just by “extending” the existing map to let the user “suggest” that traffic matching a relevant filter has a specific bgp next-hop as well as a peer src AS…but I’m just thinking out loud here. > I'd have one question for you: > > How would the 'output' look like: one single community or a list of > communities (ths may make less sense but still i'd like to double-check > with you)? Regarding the format, the actual output will be OK (single string, communities separated by _), as I push everything via AMQP and parsing gets done upper in the stack; it’s not a bad thing, when considering that not all databases are going to accept arrays of objects and that trasformation is easily supported by a lot of tooling (be it logstash, telegraph, fluentd…) > I guess you may be interested in either standard or large > communities but not extended, true? And, if true, would you have any > preferences among the two? Perhaps the standard ones since you mention > 'src_std_comm’? At the moment the support for the standard ones will suffice, for me > It's not a biggie and i guess i can converge on this relatively soon; > can you confrm your priority / urgency? Oh it’s not urgent at all, but it would be a very nice-to-have feature which helps getting a lot of interesting insights. Just one thing: as you may remember I’ve got a nice testing environment that you’re welcome to use if it helps. Thank you! Simone. ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] pmacctd and src_std_comm aggregation
Ciao Simone, If i got it correct you are after static mapping of communities to input traffic - given an input interface / vlan or an ingress router or a source MAC address. It seems doable, like you said, adding a machinery like it exists for the source peer ASN. I'd have one question for you: How would the 'output' look like: one single community or a list of communities (ths may make less sense but still i'd like to double-check with you)? I guess you may be interested in either standard or large communities but not extended, true? And, if true, would you have any preferences among the two? Perhaps the standard ones since you mention 'src_std_comm'? It's not a biggie and i guess i can converge on this relatively soon; can you confrm your priority / urgency? Paolo On Sun, May 24, 2020 at 02:09:24PM +0200, Simone Ricci wrote: > Good Evening, > > I’m trying to configure pmacctd to aggregate inbound traffic by these > primitives: > > peer_src_as, src_as, src_std_comm > > The goal is to see if traffic from certain networks announced by carrier X > with specific communities comes in from X or another hypothetical path (in > that case the communities are not relevant, but that’s another story). > > My configuration is the following: machine running pmacctd sees the traffic > thru 2 NICs, connected to SPAN port on core switches (where the carriers are > linked); only inbound traffic is presented. I also setup a bgp peering with > the border router, and enabled ADD-PATH capability on the session. > > The setup seems to work, the problem being that the community list always > refers to the bgp best path; digging thru the documentation I see that in the > ADD-PATH case, the method to select the relevant entry is looking at the > bgp_next_hop of the flow…but I think that's actually applicable only to > netflow/sflow collectors, right? I were wondering if it’s possible to extend > bgp_peer_src_as_map to set the relevant information, so that every flow will > have the community field populated by leveraging the same mechanics actually > used to populate the peer_src_as field. > > Thank you > Simone > > > ___ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
