[pmacct-discussion] sfacctd and nfacctd using the same db tables

[Jordan Grigorov (Neterra NMT)]

Hello,

We're using a mixed network environment with equipment that supports 
either sflow or netflow.


Currently we're using sfacctd only and mysql plugin which stores data 
into MariaDB CS database.


Is there any option to use both sfacctd and nfacctd that are using the 
same DB and tables?



Thank you in advance.

Kind Regards,


--
---


   Jordan Grigorov


   Network Engineer IP Services



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

Re: [pmacct-discussion] IPv6 BGP lookup

[Jordan]

Hello Paolo, Derrick

Would you share us your findings here? We're having the same problem 
using a bit different setup.


We're running a couple of sessions(IPv4 and IPv6) both using the same 
router id (IPv4 address).
In the agent_to_peer we're having pure configuration using only the IPv4 
address for bgp_id(without any filters and etc.).


We're getting either IPv4 or IPv6 BGP attributes in the database 
depending on the sequence the BGP sessions are established.


Please note that we're injecting full IPv4/IPv6 BGP tables into the 
daemon(if it's some kind of a memory limitation).



Also I tried to perform some BGP debug using the /bgp_daemon_msglog /but 
it seems there's no such valid key in the last version?!


Thanks in advance.

Best Regards,






On 4.03.2016 21:52, Derrick Sawyer wrote:

Hi Paolo,
Yes very perplexing.  If you can ping me privately, I can give you 
more detail and show you what I am seeing.


Thanks,
-/-Derrick

On Fri, Mar 4, 2016 at 6:40 AM, Paolo Lucente > wrote:


Hi Derrick,

You mean you get only v4 or v6 in the /tmp/pmacct.json? When records
are purged from the cache to the print_output_file, there is no
distinction as v4 vs v6 (ie. separate loops or so) so i'm a bit
puzzled - i can confirm you i've never been reported anything like
that plus you have no filtering whatsoever in your config that can
lead to such behaviour.

I'd be more than happy to support you verifying whether this is
actually somehow originated by the sFlow exporter.

Cheers,
Paolo

On Fri, Mar 04, 2016 at 01:17:32AM -0800, Derrick Sawyer wrote:
> Hi Paolo,
> Seeing something weird with this setup.  When I restart the
sflow process,
> I will get either all IPv4 or all IPv6 for each refresh.  Have
you seen
> this before?  Below is my config.
>
> ==
> !e Defaults
> debug: false
> daemonize: true
> plugins: print
> print_refresh_time: 60
> print_history_roundoff: m
> print_history: 15m
> print_output: json
> print_output_file: /tmp/pmacct.json
> print_cache_entries: 37
> networks_cache_entries: 37
> sfacctd_port: 7000
> !sfacctd_time_new: true
> interface: eth0
> sfacctd_as: bgp
> sfacctd_net: bgp
> sfacctd_peer_as: true
> sfacctd_renormalize: true
> sfacctd_ip: 10.10.10.22
> plugin_buffer_size: 102400
> plugin_pipe_size: 10240
> !pkt_len_distrib_bins:
> 0-199,200-399,400-599,600-799,800-999,1000-1499,1500-9000
> pkt_len_distrib_bins:
>

0-49,50-99,100-149,150-199,200-249,250-299,300-349,350-399,400-449,450-499,500-699,700-899,900-109
> 9,1100-1299,1300-1499,1500-9000
>
> !BGP
> bgp_daemon: true
> bgp_daemon_max_peers: 10
> bgp_aspath_radius: 15
> bgp_table_per_peer_buckets: 4
> bgp_peer_src_as_type: bgp
> bgp_src_as_path_type: bgp
> bgp_src_local_pref_type: bgp
> bgp_src_med_type: bgp
> bgp_neighbors_file: /tmp/bgp.peers
> bgp_peer_src_as_map: /opt/knifefish/etc/pmacct/peers.map
> bgp_agent_map: /opt/knifefish/etc/pmacct/agent_to_peer.map
> bgp_daemon_msglog_file: /tmp/bgp-peer.log
> ==
>
> Thanks,
> -/-Derrick
>
> On Thu, Mar 3, 2016 at 4:47 PM, Derrick Sawyer
mailto:sawye...@gmail.com>> wrote:
>
> > Hi Paolo,
> > Opps ;)  I forgot about that.  That did the trick!  The bgp
agent mapping
> > config with dual v4/v6 sessions seems to be the key for me.
> >
> > Again appreciate the help and quick responses!
> >
> > -/-Derrick
> >
> > On Thu, Mar 3, 2016 at 4:36 PM, Paolo Lucente
mailto:pa...@pmacct.net>> wrote:
> >
> >> Hi Derrick,
> >>
> >> This should be because, according to the config you sent in
the first
> >> email, you have 'bgp_daemon_ip: X.X.X.X' - which effectively
binds the
> >> BGP daemon to only X.X.X.X. Please comment it out and if
necessary do
> >> any filtering via iptables or such. All working well, we can
refine it
> >> afterwards.
> >>
> >> Cheers,
> >> Paolo
> >>
> >> PS: should this still not put us on the right path and should
your box
> >> be accessible remotely, vi'd be more than happy to have a
look myself.
> >>
> >>
> >> On Thu, Mar 03, 2016 at 04:12:41PM -0800, Derrick Sawyer wrote:
> >> > Hi Paolo,
> >> > It looks like I am not receiving IPv6 prefixes and the
MP-BGP is not
> >> > working.  I will have to configured dual sessions but the
IPv6 session
> >> is
> >> > not working.  Below is my agent mapping file and router config.
> >> >
> >> > I am also running the latest pull from the git repo.
> >> >
> >> > ---
> >> > bgp_ip=10.10.10.0  ip=10.10.10.0 filter=ip
> >> > bgp_ip=2000:3000:404c:::::
ip=10.10.10.0 filter=ip6
> >> > 
> >> >
> >> > router bg

Re: [pmacct-discussion] sfacct feature suggestion - traffic in/out direction

[Jordan]

Hello,

I mean that when you enable sflow on an interface you cannot configure 
ingress/egress option.

It captures both directions while we need only data for ingress traffic.

There are two major problems with your solution. I think /direction /is 
not a valid sfacct key and we already use pretagging(both tag,tag2) for 
other purposes.


Regards,


On 07/27/2016 06:27 PM, Jentsch, Mario wrote:


Hi Jordan,

not sure what you mean with “equipment that cannot separate 
inbound/outbound traffic” but as long as you have /direction/ in your 
flow data you can add a pre-tag map like


/!/

/! tag=1  - inbound IPv4 traffic/

/! tag=2  - outbound IPv4 traffic/

/! tag=3  - inbound IPv6 traffic/

/! tag=4  - outbound IPv6 traffic/

/!/

/set_tag=1 ip=0.0.0.0/0 direction=0 filter='ip'/

/set_tag=2 ip=0.0.0.0/0 direction=1 filter='ip'/

/set_tag=3 ip=0.0.0.0/0 direction=0 filter='ip6'/

/set_tag=4 ip=0.0.0.0/0 direction=1 filter='ip6'/

/set_tag=0 ip=0.0.0.0/0/

/!/

and filter e.g. the ingress flows with

/!/

/pre_tag_filter[ingress]: 1,3/

/aggregate[ingress]: …/

/!/

Regards,

Mario

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

*Sent:* Wednesday, July 27, 2016 5:06 PM
*To:* pmacct-discussion@pmacct.net
*Subject:* [pmacct-discussion] sfacct feature suggestion - traffic 
in/out direction


Hello,

We're having issues with equipment that cannot separate 
inbound/outbound traffic using sflow V5.


Looking at the sflow V5 protocol it's having the following fields. 
Usually they match the snmp interface indexes.

/source_id/
/interface input/
/interface output/


What I suggest as a new feature are the following cases:

*Match_all_traffic*(by default) - matches all packets (as it currently 
works)
*Match_input_only *- (if /source_id==interface input /permit, else 
drop the rest of the samples)
*Match_output_only* - (if/source_id==interface output/permit, 
else drop the rest of the samples)



Please let me know if such feature would be possible?
If there is any other already implemented solution I would be glad to 
know.


Thank you in advance.

Best Regards,


--
---


Jordan



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


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

[pmacct-discussion] sfacct feature suggestion - traffic in/out direction

[Jordan]

Hello,

We're having issues with equipment that cannot separate inbound/outbound 
traffic using sflow V5.


Looking at the sflow V5 protocol it's having the following fields. 
Usually they match the snmp interface indexes.

/source_id/
/interface input/
/interface output/


What I suggest as a new feature are the following cases:

*Match_all_traffic*(by default) - matches all packets (as it currently 
works)
*Match_input_onl**y *- (if /source_id==//interface input /permit, else 
drop the rest of the samples)
*Match_output_only* - (if///source_id==//interface//output/permit, 
else drop the rest of the samples)



Please let me know if such feature would be possible?
If there is any other already implemented solution I would be glad to know.

Thank you in advance.

Best Regards,



--
---


   Jordan


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

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

[Jordan Grigorov (Neterra NMT)]

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

<https://www.linkedin.com/company/neterra>


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 <http://127.0.0.1:9995>
tee_receiver[pmacct]: 127.0.0.1: <http://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

Re: [pmacct-discussion] sfacctd - Multiple RIB - incorrect BGP data

[Jordan Grigorov (Neterra NMT)]

Hello Paolo,

Using this pre_tag_map structure returns the following error. Pmacct 
version is 1.5.1.


/Jan 28 10:06:20 ERROR ( default/core ): required key missing at line 1 
in map '/etc/pmacct/pretag/peer1.map'. Required key is: 'ip'.//
//Jan 28 10:06:20 ERROR ( default/core ): required key missing at line 2 
in map '/etc/pmacct/pretag/peer1.map'. Required key is: 'ip'./

...

I tryed adding  the 'ip' key but all the bgp and 'tag' data is null.
By the way so far the agent_id value is always 0 or NULL(we're having 
about 20 multi vendor agents).

Am I doing something wrong?

Kind Regards,


---


   Jordan

www.neterra.net <http://www.neterra.net/> 
<https://www.linkedin.com/company/neterra>



On 20.01.2016 08:46, Paolo Lucente wrote:

Hi Jordan,

A feature to map MACs to ASNs, ie. equivalent to the networks_file
that does IP (prefixes) to ASNs, is not currently available - just
to confirm. Adding it needs a bit of work but it's not a big deal,
definitely achievable.

The workaround i can propose is to pass through the pre_tag_map
infrastructure; use tag as peer_src_as and tag2 as peer_dst_as;
the map would be composed as follows (please excuse typos):

set_tag=   src_mac= jeq=dst
set_tag= src_mac= jeq=dst
set_tag= src_mac= jeq=dst
...
set_tag2= dst_mas= label=dst
set_tag2= dst_mas=
set_tag2= dst_mas=

With further reference on the syntax of a pre_tag_map file available
here:

https://github.com/pmacct/pmacct/blob/master/examples/pretag.map.example

Then your 'aggregate' configuration directive you would look like
'tag, tag2, < .. >'. Please let me know if the work around can work
for you for a proof of concept and/or a short-term solution.

Cheers,
Paolo

On Tue, Jan 19, 2016 at 11:28:58AM +0200, Jordan Grigorov (Neterra NMT) wrote:

Hello,

We are using sfacctd, mysql and BGP daemon capturing IXP traffic.

We're facing a problem with incorrect BGP data caused by the
multiple RIB of our RS.

In details there is wrong information in the DB for the primitives
/peer_src_as /and/peer_dst_as/ for some flows as there is only a
single iBGP session between the RS and the sflow collector(in a
single RIB).
As we're unable to bring up iBGP sessions for each RIB is there any
solution for this case?


What we intend to do is to create a dynamic file that maps each IXP
member MAC address to his ASN(/peer_dst_as)/ value.
Then for each flow this /peer_dst_as/ value should be obtained from
the file and injected into the DB rather than from the sfacct BGP
daemon.
Is there any option to do this without heavy src code modifications?

Thank you in advance.

Kind Regards,


--
---


Jordan Grigorov

<https://www.linkedin.com/company/neterra>


___
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] sfacctd - Multiple RIB - incorrect BGP data

[Jordan Grigorov (Neterra NMT)]

Hello,

We are using sfacctd, mysql and BGP daemon capturing IXP traffic.

We're facing a problem with incorrect BGP data caused by the multiple 
RIB of our RS.


In details there is wrong information in the DB for the primitives 
/peer_src_as /and/peer_dst_as/ for some flows as there is only a single 
iBGP session between the RS and the sflow collector(in a single RIB).
As we're unable to bring up iBGP sessions for each RIB is there any 
solution for this case?



What we intend to do is to create a dynamic file that maps each IXP 
member MAC address to his ASN(/peer_dst_as)/ value.
Then for each flow this /peer_dst_as/ value should be obtained from the 
file and injected into the DB rather than from the sfacct BGP daemon.

Is there any option to do this without heavy src code modifications?

Thank you in advance.

Kind Regards,


--
---


   Jordan Grigorov

<https://www.linkedin.com/company/neterra>


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

[pmacct-discussion] sfacctd - mysql multiple tables

[Jordan Grigorov (Neterra NMT)]

Hello,

We are using sfacctd, mysql and BGP daemon.

Is there an easy way to configure sfacctd to write into multiple mysql 
tables?


What we would like to achieve is to insert different primitives into 
different mysql tables.

Is it possible with a single instance of sfacct?

Thanks in advance.

Kind Regards,


--
---
*Jordan Grigorov*
Network Management Team

Neterra Ltd.
Telephone: +359 2 974 33 11
Fax: +359 2 975 34 36
Mobile: +359 886 280 046
www.neterra.net <http://www.neterra.net>


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