Re: [pmacct-discussion] bgp_peer_src_as_map and pmacctd

2019-06-19 Thread Simone Ricci
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

Re: [pmacct-discussion] bgp_peer_src_as_map and pmacctd

2019-06-18 Thread Paolo Lucente

Ciao Simone,

The config and maps all look good and, to be frank, it should all work.
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. 

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. If
that is not possible, i can simulate a setup in my own testbed (it will
take longer). Let me know what is possible (here or by unicast email).

Paolo

On Tue, Jun 18, 2019 at 10:58:50AM +0200, Simone Ricci wrote:
> Good Morning,
> 
> I’m facing a problem with pmacctd trying to use bgp_peer_src_as_map directive 
> to populate accordingly the peer_src_as field. Our setup is quite simple:
> 
> - The collector (running pmacctd) sees traffic subject to analysis on two 
> interfaces
> - Every link lives in its own vlan
> - One link has multiple peers in it (it’s an IXP)
> 
> This is the current configuration:
> 
> ## pmacct.conf ##
> daemonize: false
> pcap_interfaces_map: /opt/pmacct/etc/pcap_interfaces.map
> pcap_ifindex: map
> plugins: memory[in]
> aggregate[in]: src_as, peer_src_as
> imt_buckets: 65537
> imt_mem_pools_size: 65535
> imt_mem_pools_number: 1048576
> plugin_buffer_size: 1048576
> plugin_pipe_size: 134217728
> bgp_daemon: true
> pmacctd_as: bgp
> bgp_agent_map: /opt/pmacct/etc/bgp_agent.map
> bgp_peer_src_as_map: /opt/pmacct/etc/bgp_peers.map
> bgp_peer_src_as_type: map
> 
> 
> ## pcap_interfaces.map ##
> ifname=enp1s0f0 ifindex=100
> ifname=enp1s0f1 ifindex=200
> 
> ## bgp_agent.map ##
> bgp_ip=W.X.Y.Z ip=0.0.0.0/0 ! W.X.Y.Z is peer’s router id
> 
> ## bgp_peers.map ##
> id=X ip=0.0.0.0/0 src_mac=xx:xx:xx:xx:xx:xx
> id=Y ip=0.0.0.0/0 src_mac=yy:yy:yy:yy:yy:yy
> id=Z ip=0.0.0.0/0 src_mac=zz:zz:zz:zz:zz:zz
> 
> Obviously macs and asns are hidden to protect the innocents (!)
> 
> When I start the daemon, it comes up correctly without giving any 
> warning/error, but peer_src_as gets always populated with the first entry on 
> the relevant map (in this case, X).
> Now I’m wondering, is this configuration supported ? Or maybe src_mac is 
> supposed to be used only with nfacctd and sfacctd ?
> 
> To overcome the problem I can easily span multiple pmacctd daemons, each one 
> with the relevant pcap_filter directive, then collect data separately (which 
> is not an issue since the memory plugin is just for debugging purposes, the 
> plan is of course is to send everything to influx and/or elasticsearch for 
> further analysis)…but this seems rather hackish to me.
> 
> Thanks!
> 
> 
> -- 
> Simone Ricci
> 
> 
> 
> 
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists