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 <pa...@pmacct.net> 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
