Re: [pmacct-discussion] route distinguisher (RD) looks wired when dump the BGP table.

2016-12-02 Thread Paolo Lucente

Hi Alberto,

You may, sure. Although, if the issue is it dumps 32k routes out of 42k,
it may be something else than a performance issue. It smells it will need
more info in order to reproduce it.

Cheers,
Paolo
 
On Fri, Dec 02, 2016 at 09:55:54PM +0100, Alberto Santos wrote:
> Thx a lot
> I also notice performance issues when dumping the table.  Today i have 42 k
> mpls vpn v4 routes but it only dumps 32k
> Do u want me to create another issue?
> BR
> Al
> 
> On Dec 2, 2016 18:50, "Paolo Lucente"  wrote:
> 
> >
> > Hi Alberto,
> >
> > I see you opened an issue on GitHub too about this. To avoid duplications,
> > let me handle this there. I will try to replicate the problem in lab and
> > come back to you. It smells like a bug.
> >
> > Cheers,
> > Paolo
> >
> > On Wed, Nov 30, 2016 at 07:29:14PM +0100, Alberto Santos wrote:
> > > Hi,
> > >
> > > I started playing with pmacct and I noticed that the route distinguisher
> > RD
> > > looks wired when dumping the BGP table in a file. Is there any reason
> > why?
> > >
> > > here it is an example:
> > >
> > > "rd": "1:40.0.17.10:256
> > >
> > > The IP address is inverted, it should be 10.17.0.40 and the 2nd part
> > should
> > > be 1806 instead.
> > > Is this a bug? pls find below the complete output from the file.
> > >
> > > [root@hostname]# cat bgp-10_197_1_114-2016_11_29T20_05_00.txt | grep
> > > 10.12.95.16
> > > {"timestamp": "2016-11-29 20:05:00", "peer_ip_src": "10.17.1.14",
> > > "event_type": "dump", "ip_prefix": "10.12.95.16/28", "bgp_nexthop":
> > > "10.17.1.14", "as_path": "65346", "comms": "65346:39", "ecomms":
> > > "RT:65432:2", "origin": 0, "local_pref": 100, "rd": "1:40.0.17.10:256"}
> > >
> > > BR
> > >
> > > Alberto
> >
> > > ___
> > > 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] IPv4 and IPv6 sFlow BGP AS

2016-12-02 Thread Paolo Lucente

Hi Sergey,

I guess what you need is to refine your bgp_agent_map as follows:

bgp_ip=176.**.**.252 ip=0.0.0.0/0   filter='ip'
bgp_ip=2001:**:**:1::11  ip=0.0.0.0/0   filter='ip6'

Let me know if this works for you.

Cheers,
Paolo

On Fri, Dec 02, 2016 at 08:09:07PM +0200, Сергей Горшков wrote:
> Hi all.
> 
> I need your help because I am in a deadlock
> 
> My config
> 
> #cat sfacctd.conf
> ! sfacctd configuration
> !
> !
> !
> daemonize:  true
> interface:  any
> pidfile:/var/run/sfacctd.pid
> syslog: daemon
> logfile:/var/log/sfacct.log
> !
> sfacctd_as_new: bgp
> bgp_daemon: true
> bgp_agent_map:  /etc/pmacct/bgp_agent.map
> !
> aggregate: tag,vlan,src_as,dst_as,src_host,dst_host,src_port,dst_port,proto
> !
> plugins:mysql
> sql_db: pmacct
> sql_table_version:  6
> sql_table:  acct_v6
> sql_host:   localhost
> sql_user:   *
> sql_passwd: *
> sql_refresh_time:   60
> sql_optimize_clauses:   true
> sql_history:1h
> sql_history_roundoff:   h
> sql_locking_style:  row
> --
> 
> # cat bgp_agent.map
> bgp_ip=176.**.**.252  ip=0.0.0.0/0
> bgp_ip=2001:**:**:1::11  ip=0.0.0.0/0
> --
> In this configuration, all IP6 addresses obtained AS 0
> 
> select * from acct_v6 where ip_src like '%2001:4860%';
> +--+--+++-+---+--+--+--+-+---+---+-+-+
> | agent_id | vlan | as_src | as_dst | ip_src  |
> ip_dst| src_port | dst_port | ip_proto | packets | bytes |
> flows | stamp_inserted  | stamp_updated   |
> +--+--+++-+---+--+--+--+-+---+---+-+-+
> |0 | 3855 |  0 |  0 | 2001:4860::8:0:8f90 |
> 2001:67c:2d40::47 |0 |0 | ipv6-i   |   2 | 428 |
> 0 | 2016-12-01 11:00:00 | 2016-12-01 11:35:01 |
> 
> IP4 everything is fine
> 
> |0 | 3905 |  15169 |  50581 | 173.194.21.80   | 31.43.60.150
> |  443 |21668 | tcp  |   2 |  3044 | 0 | 2016-12-01
> 11:00:00 | 2016-12-01 11:16:01 |
> 
> If BGP neighbors to change their place
> 
> # cat bgp_agent.map
> bgp_ip=2001:**:**:1::11  ip=0.0.0.0/0
> bgp_ip=176.**.**.252  ip=0.0.0.0/0
> 
> Then get IP6 AS number and get IP4 AS0
> How to make sFacct collated both IP4 and IP6 addresses with an
> autonomous system number??
> 
> 
> 
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

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

Re: [pmacct-discussion] stamp_inserted

2016-12-02 Thread Paolo Lucente

Hi Jaroslav,

Unfortunately not as they are integral part of the sql_history feature
(which you need to populate the time-related variables of the tables).
As an alternative, only for the 'all' tables where you have the other
timestamps, you may disable sql_history and write to a fixed, say,
'router1_in' 'router1_out' tables and, ie. via a sql_trigger script,
you can take care yourself of the logics of renaming the tables so to
include some time-related variable.

Cheers,
Paolo

On Wed, Nov 30, 2016 at 01:00:02PM +0100, Jaroslav Jirásek wrote:
> Hi, I use this scerario:
> 
> sql_refresh_time: 120
> sql_history: 2m
> sql_history_roundoff: m
> sql_dont_try_update: true
> nfacctd_pro_rating: true
> 
> aggregate[router1.all.in]: 
> src_host,dst_host,proto,src_port,dst_port,timestamp_start,timestamp_end
> aggregate[router1.all.out]: 
> src_host,dst_host,proto,src_port,dst_port,timestamp_start,timestamp_end
> aggregate[router1.sums.in]: dst_host
> aggregate[router1.sums.out]: src_host
> 
> plugins: 
> mysql[router1.all.in],mysql[router1.all.out],mysql[router1.sums.in],mysql[router1.sums.out]
> 
> sql_table[router1.all.in]: %Y%m%d_router1_in
> sql_table[router1.all.out]: %Y%m%d_router1_out
> sql_table[router1.sums.in]: %Y_router1_sums_in
> sql_table[router1.sums.out]: %Y_router1_sums_out
> 
> sql_startup_delay[router1.all.in]: 240
> sql_startup_delay[router1.all.out]: 240
> sql_startup_delay[router1.sums.in]: 240
> sql_startup_delay[router1.sums.out]: 240
> 
> in tables %Y%m%d_router1_in and %Y%m%d_router1_out I have columns
> stamp_inserted and stamp_updated,
> but I don´t need them, because I aggregate nothing. timestamp_start
> and timestamp_end is enough.
> In these tables I need to store everything for best accuracy when
> finding problems.
> 
> In sums tables I don´t need column stamp_updated.
> 
> Is there any way to not store these columns?
> 
> Thank you, Jaroslav
> 
> 
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

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