Re: [pmacct-discussion] effort to relicense pmacct from GPL to a BSD-style license

2020-01-08 Thread Markus Weber
I consent to relicensing any and all the contributions I have made to 
the pmacct project - no matter how small these had been ;-)


Markus

Am 08.01.2020 um 14:52 schrieb Job Snijders:

Dear all,

Summary: The pmacct project is looking to relicense its code from the
current GPL license to a more liberal BSD-style license.

A few weeks ago I had the pleasure to spend some face time with Paolo,
which allowed for in-depth discussion about pmacct's current trajectory
and bright future. We concluded it would be in the best interest of the
pmacct project to attempt to relicense all code under a more permissive
BSD-style license, for mainly two reasons:

1) Faced with our own mortality, it became clear that succession
planning is of paramount importance for this project's continued
success. We contemplated what happens in context of intellectual
property rights should one of pmacct's contributors pass away, and
realized potential heirs won't necessarily desire involvement in this
open source project, potentially hampering changes to intellectual
property policies in the project's future.

2) We suspect there are entities who violate the terms of pmacct's
current GPL license, but at the same time we don't wish to litigate.
Instead of getting infringers to change their behavior, relicensing
the project could be another way to resolve the potential for
conflict: we see benefits to removing rules we don't plan on
enforcing anyway.

Going forward, the preferred license under which we encourge people to
contribute new work is a variant of the ISC license (also used by the
OpenBSD project). The license template (to be used in file headers) can
be found here:

 https://github.com/pmacct/pmacct/blob/master/LICENSE.template

We need explicit approval from all contributors, and carefully keep
track of those agreements. If a contributor doesn't agree or answer,
we'll have to re-implement the contributed functionality or remove the
contribution from the code base.

REQUEST TO THE PMACCT CONTRIBUTOR COMMUNITY
---

If you have contributed to the pmacct project (your name may be listed
below), please consider a reply-all to this email expressing your
explicit consent (or disapproval) to change the license governing your
contributions to the pmacct project, to the following license:

 """
 Permission to use, copy, modify, and distribute this software for
 any purpose with or without fee is hereby granted, provided that the
 above copyright notice and this permission notice appear in all
 copies.

 THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
 WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
 WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
 AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
 DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA
 OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
 TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 PERFORMANCE OF THIS SOFTWARE.
 """

---

The next action in this process will be to individually follow up with
all contributors who didn't respond to the above request.

Once the relicensing effort has been completed, we'll tag the resulting
code base as pmacct version 2.0.0 and celebrate! Pmacct has many great
years ahead of itself; Paolo's enthusiasm to do so is evident in this
interview video :-) https://www.youtube.com/watch?v=QqmOcMAtGDM

Please feel free to raise any questions you may have on the
pmacct-discussion@pmacct.net list, or privately with me and/or Paolo.

Kind regards,

Job Snijders


DRAFT LIST OF KNOWN PMACCT AUTHORS (based on 'git shortlog -sen')
=
  
Commits  Author 

2921  Paolo Lucente 
  52  Marc Sune 
  20  Corentin Néau 
  17  Vincent Bernat 
  14  Job Snijders 
  12  Matthias Arnold 
   9  Raphaël P. Barazzutti 
   9  Claudio Ortega 
   8  Jonas Jensen 
   8  Matthias Arnold 
   8  Tim LaBerge 
   7  Jared Mauch 
   7  vittoriofoschi 
   7  Camilo Cardona 
   5  Aaron Finney 
   5  Vittorio Foschi 
   4  vphatarp 
   3  Alexander Brusilov 
   3  Emil Palm 
   3  Dusan Migra 
   3  Dan Berger 
   3  Markus Weber 
   2  Tim LaBerge 
   2  Guy Lowe 
   2  Hidde van der Heide 
   2  Jim Westfall 
   2  Lee Yongjae 
   2  Lennert Buytenhek 
   2  Matthieu Texier 
   2  Miki Takata 
   2  Pierre Dubouilh 
   2  Tiago Gomes 
   2  Vadim Tk 
   3  Thomas Graf 
   1  Junpei YOSHINO 
   1  root 
   1  Mehul Prajapati 
   1  Mike Jager 
   1  rouba002 
   1  Nimrod 
   1  Jeroen Roovers 
   1  Paweł Małachowsk

Re: [pmacct-discussion] src_as_path finding

2018-08-22 Thread Markus Weber

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

[pmacct-discussion] src_as_path finding

2018-08-20 Thread Markus Weber

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

Re: [pmacct-discussion] Only packets from router to netflow server

2016-08-19 Thread Markus Weber

Hi Matthias,

could it be that your hosts does NOT accept/process the packets as those 
are targeted to another MAC address? If you run wireshark/tcpdump the 
interface to put into promiscuous mode to get them ...


If all have the same dst mac just change your interface facing the SPAN 
port to it.



Other than that: any host "firewall" rules active?

Markus

On 19.08.2016 11:21, Jentsch, Mario wrote:


Hi Mattias,

do you have a drawing of your setup? I have to admit that it is 
unclear to me…


Thanks,

Mario

*From:*pmacct-discussion [mailto:pmacct-discussion-boun...@pmacct.net] 
*On Behalf Of *Mattias Larsson

*Sent:* Thursday, August 18, 2016 1:36 PM
*To:* pmacct-discussion@pmacct.net
*Subject:* [pmacct-discussion] Only packets from router to netflow server

I use a SPAN port on my switch to capture all netflow (udp 2055) 
packets and send it to a interface where my pmacct server has one 
extra interface connected to.


But when I look on the traffic/packets that pmacctd genereates it 
seems only be the IP packets between my router and netflow server. It 
seems it not decodes the cisco netflow payload/data.


When I do a tcpdump on the interface and look at it with wireshark I 
can see see the flows.


Any suggestion what I'm doing wrong?

Thanks in advance!


Mattias



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



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

Re: [pmacct-discussion] iBGP and networks_file

2016-02-24 Thread Markus Weber

Hi Steve,

you are using nfacctd_as_new fallback? That is said to work like "When 
'fallback' is specified, lookup is done against the winning longest 
match lookup method (sFlow/NetFlow <= BGP), which can be different for 
source and destination IP prefix.".


If I understand you correctly, you want to have the networks file take 
precedence over BGP, ignoring normal longest match lookups. I remember 
Paolo stating a while ago, that this is/was not possible ... and 
fallback would have been renamed to "longest" make this clear.


... Oh, OTOH, check out networks_file_no_lpm - which "Makes a matching 
IP prefix defined in a networks_file win always" (1.5.2) ... guess this 
is what you are looking for (and what I've been looking for as well ;-).


Markus



On 24.02.2016 16:57, Steve Dodd wrote:

Hi all,

I’m trying to address the case of iBGP learned routes showing AS0 for 
src_as/dst_as. I have defined a list of our internal network space 
with a mapping to our AS. However, it appears that an explicit match 
is required IE:


[networks.lst]
65001, 10.0.0.0/8

This would result in an appropriate src_as/dst_as mapping of 65001 for 
10.0.0.0/8, but not for 10.1.0.0/24.


Is this the expected behavior?

Thanks,
Steve


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



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


Re: [pmacct-discussion] Question about teeing and sampling

2016-02-10 Thread Markus Weber
No problem with tee here - but wasn't Pau expecting tee to do further 
sampling (which it doesn't)?


==nfacctd_tee.conf:
pidfile: /pmacct/var/nfacctd_tee.pid
logfile: /pmacct/log/nfacctd_tee.log
daemonize: true
files_umask: 2
nfacctd_disable_checks: true
nfacctd_pipe_size: 8388608
plugin_buffer_size: 204800
plugin_pipe_size: 2048
nfacctd_ip: 
nfacctd_port: 

plugins: tee
tee_receivers: /pmacct/etc/tee_rec.lst
tee_transparent: true


==tee_rec.lst:
id=1ip=:,:

Run nfacctd with nfacctd_tee.conf to duplicate NF data received on 
: to : and :. Then run on 
: your NFsen and on : another nfacctd with 
another config to use pmacct's great features (what ever you want to 
aggregate on or do with the data).


Eventually you might need tee_transparent to be true (or -S with 
samplicator) to keep original source address.



Markus

On 10.02.2016 10:35, Jordan Grigorov (Neterra NMT) wrote:

Hello Pau,

You can try /samplicate/ tool (https://github.com/sleinen/samplicator) 
to forward netflow data to multiple IPs/ports.


Just install it and issue:

/samplicate -s 88.22.33.99 -p 9996 127.0.0.1/9995 ///127.0.0.1// -f/

Best Regards,



---


Jordan




On 8.02.2016 16:27, KA PDE wrote:

Hi all,

I've recently discovered pmacct and I'm evaluating it to forward 
netflow data for security purposes to a set of collectors, some of 
them requiring less amount of data sent.


I have a simple configuration using the tee plugin. I've managed to 
send flow information to NFsen but I'm unable to find a way of 
sampling to the other destination.Is this achievable with pmacct?


! nfacctd configuration
!
!
!
daemonize: true
pidfile: /var/run/nfacctd.pid
syslog: daemon

nfacctd_port: 9996
nfacctd_ip: 88.22.33.99
plugin_pipe_size: 1024
plugin_buffer_size: 10240

plugins: tee[nfsen], tee[pmacct]
tee_receiver[nfsen]: 127.0.0.1:9995 
tee_receiver[pmacct]: 127.0.0.1: 
! sampling_rate[pmacct]: 4096
tee_transparent: true

Thanks in advance and best regards,

Pau


___
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] nfacct total bytes inconsistencies

2015-11-29 Thread Markus Weber

On 28.11.2015 21:22, Vaggelis Koutroumpas wrote:

Now, checking the udp drop counters on the old server, indeed I see some
25000+ drops. That counter seem to increase during the refresh time of
the sql plugin. Not always though. Is there a connection between the
drops and the mysql insert/update process? If so, would running the
mysql server on a different server eliminate any future possibility of
that happening again?


Get those fixed (if they increase while nfacct is running and if you can't
ensure, that the drops are caused by any other UDP packets hitting the
box). Increase max UDP receive buffers on the box and set nfacctd_pipe_size.
Make sure nfacct is really using the new buffer size ... you may consider
offloading mysql to a different server, but if usually increasing buffers
to be prepared for peaky incoming flow data should be sufficient (sure,
depending on how much data you receive).

For dropped flow data you'll never get stats.

Cheers,
Markus

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


[pmacct-discussion] Starving BGP sessions

2015-07-23 Thread Markus Weber


In heavy loaded environments [Paolo knows our probably better
than me ;-] BGP sessions might run into timeouts during heavy
routing updates (on startup it takes here -thanks to the fast
box it's running on - 30 mins to load all tables).

Reasons seems to be/is the processing loop in bgp.c, which
handles incoming updates of peers first, which connected first,
'till there are no more updates available from them, and then -
only then - get to handle the later connected peers.

Attached is a small quick-and-dirty hack (against 1.5.0), which
should fix this (still not a real round-robin fashion, unless
you have as many peers as configured as max; so it still gives
a preference to the first ones, but does not forget the later
ones; more rr like would be to set peers_idx_rr to peers_idx+1
before the break ...).

Please let me know if you think this break anything ... if not,
maybe worth merging it into the official release.

Cheers,
Markus

Pricing Housing
*** /home/ertools/source/pmacct-1.5.0/src/bgp/bgp.c-origThu Jul 23 
10:17:34 2015
--- /home/ertools/source/pmacct-1.5.0/src/bgp/bgp.c Thu Jul 23 10:24:18 2015
***
*** 57,62 
--- 57,63 
  void skinny_bgp_daemon()
  {
int slen, ret, rc, peers_idx, allowed;
+   int peers_idx_rr = 0;
struct host_addr addr;
struct bgp_header bhdr;
struct bgp_peer *peer;
***
*** 507,514 
  /* We have something coming in: let's lookup which peer is thatl
 XXX: to be optimized */
  for (peer = NULL, peers_idx = 0; peers_idx  
config.nfacctd_bgp_max_peers; peers_idx++) {
!   if (peers[peers_idx].fd  FD_ISSET(peers[peers_idx].fd, read_descs)) {
!   peer = peers[peers_idx];
break;
}
  }
--- 508,516 
  /* We have something coming in: let's lookup which peer is thatl
 XXX: to be optimized */
  for (peer = NULL, peers_idx = 0; peers_idx  
config.nfacctd_bgp_max_peers; peers_idx++) {
!   if (peers[(peers_idx+peers_idx_rr)%config.nfacctd_bgp_max_peers].fd  
FD_ISSET(peers[(peers_idx+peers_idx_rr)%config.nfacctd_bgp_max_peers].fd, 
read_descs)) {
!   peer = peers[(peers_idx+peers_idx_rr)%config.nfacctd_bgp_max_peers];
!   peers_idx_rr = (peers_idx_rr+1)%config.nfacctd_bgp_max_peers;
break;
}
  }
___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists