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
[pmacct-discussion] pmacctd and src_std_comm aggregation
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
Re: [pmacct-discussion] bgp_peer_src_as_map and pmacctd
Buongiorno Paolo, > Il giorno 19 giu 2019, alle ore 03:07, Paolo Lucente ha > scritto: > > Ciao Simone, > > The config and maps all look good and, to be frank, it should all work. Phew! At least the config was ok :-) > I admit it may be a better tested config with nfacctd/sfacctd (where it > should just work) than pmacctd/uacctd. If you have interest in trying to > make it work, i'd be more than happy to support you and investigate the > issue. Yes of course! Even if I found a viable workaround (aggregate also by vlan and src_mac, then “resolve” peer_src_as later in the pipeline) it would be a pleasure to help. > Shall i find you positive: the setup is a bit involved and by far the > easiest would be if i could troubleshoot on your own setup/testbed No problem, I’ll send you access details in a separate - unicast :-) - email…just the time to reconfigure the things a bit. Thank you for the support ! -- Simone Ricci ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
