Hi Adam, What version of pmacct are you using? Is it possible to get remote access to the box running pmacct so to troubleshoot/debug? If yes, please follow-up privately, then we can summarize the issue on the list. Otherwise i will try to reproduce your issue in lab. Let me know.
Cheers, Paolo On Fri, Aug 24, 2012 at 02:35:22PM -0400, Adam Jacob Muller wrote: > Interestingly, the MySQL thread for dst_as is pegging one cpu core: > > root 6513 98.8 0.2 98344 65580 pts/3 R+ 01:25 780:31 > sfacctd: MySQL Plugin [dst_as] > > Updating to a 300 second interval also did nothing unfortunately. > > > -Adam > > > On 08/24/12 01:29, Adam Jacob Muller wrote: >> Hi Brent, >> >> They are in fact the same, my final design won't be (I'll have devices >> without a full feed sending sflow), but they are right now. >> >> >> sfacctd_as_new: false >> does not produce data in the dst_as table. >> >> sfacctd_net: bgp >> does produce data in the in the dst_net table. >> >> Odd one. >> >> -Adam >> >> >> On 8/24/12 1:06 AM, Brent Van Dussen wrote: >>> I see you have 'sfacctd_net: bgp' commented out. Was something not >>> working with dst_net until you did? >>> >>> Actually now that I look at your bgp_agent_map again, I think this may >>> be where you're missing your BGP related data. >>> >>> Try this instead for your bgp_agent_map: >>> >>> id=ip.address.of.BGP.neighbor ip=ip.address.of.sflow.agent >>> >>> If the box you're getting your sflow feed from is really the same box >>> you're sending your full BGP feed from then why not just use the sflow >>> reported dst_as field and set 'sfacctd_as_new: false'? >>> >>> -Brent >>> >>> >>> On Aug 23, 2012, at 9:45 PM, Adam Jacob Muller wrote: >>> >>>> Hi Brent, >>>> I have around 300pps of sflow data coming in. >>>> >>>> https://gist.github.com/9cf741bb3c1af8432886 >>>> >>>> Everything works EXCEPT dst_as >>>> >>>> mysql> select table_name,table_rows from information_schema.tables >>>> where table_schema='pmacct' and table_name in >>>> ('peer_dst_as','dst_as','dst_net','dst_ip','src_ip','dst_iface_mac')\G >>>> *************************** 1. row *************************** >>>> table_name: dst_as >>>> table_rows: 0 >>>> *************************** 2. row *************************** >>>> table_name: dst_iface_mac >>>> table_rows: 111 >>>> *************************** 3. row *************************** >>>> table_name: dst_ip >>>> table_rows: 1112796 >>>> *************************** 4. row *************************** >>>> table_name: dst_net >>>> table_rows: 64358 >>>> *************************** 5. row *************************** >>>> table_name: peer_dst_as >>>> table_rows: 68 >>>> *************************** 6. row *************************** >>>> table_name: src_ip >>>> table_rows: 857878 >>>> 6 rows in set (0.00 sec) >>>> >>>> >>>> # sed -i -e 's/: 10/: 300/' /etc/pmacctd/sfaccd.conf >>>> >>>> Running that now, will see in 5 minutes I guess :) >>>> >>>> -Adam >>>> >>>> On 8/24/12 12:32 AM, Brent Van Dussen wrote: >>>>> Hi Adam, >>>>> >>>>> I've seen some interesting behavior with sfacctd when the >>>>> sql_refresh_time is really low, especially when there isn't a very >>>>> significant volume of sflow samples coming in. >>>>> >>>>> What happens if you increase the sql_refresh_time to, say, 300 >>>>> seconds instead of 10? >>>>> >>>>> Can you also post your full sfacctd config? >>>>> >>>>> Thanks! >>>>> -Brent >>>>> >>>>> On Aug 23, 2012, at 8:02 PM, Adam Jacob Muller wrote: >>>>> >>>>>> Hi, >>>>>> I've been investigating pmacctd (specifically sfacctd) recently, >>>>>> its a very nice tool and fits some of what I need very well I think. >>>>>> >>>>>> >>>>>> I've gotten pmacctd doing a number of the things i'm looking for it >>>>>> to do, but for some reason the dst_as aggregate doesn't seem to >>>>>> work for me. >>>>>> >>>>>> >>>>>> I have: >>>>>> sfacctd_as_new:bgp >>>>>> >>>>>> aggregate[dst_as]: dst_as >>>>>> sql_refresh_time[dst_as]: 10 >>>>>> sql_table_type[dst_as]: bgp >>>>>> sql_table[dst_as]: dst_as >>>>>> >>>>>> >>>>>> I also have a BGP peer configured (with a full table incoming): >>>>>> bgp_daemon: true >>>>>> bgp_daemon_ip: a.b.c.d >>>>>> bgp_agent_map: /etc/pmacctd/bgp_agent_map >>>>>> >>>>>> >>>>>> /etc/pmacctd/bgp_agent_map has: >>>>>> id=loopback.ip.of.peer ip=loopback.ip.of.peer >>>>>> >>>>>> (bgp is configured to [and does] connect from loopback) >>>>>> >>>>>> >>>>>> Looking at the sflow data with sflowtool, I see: >>>>>> agentSubId 1 >>>>>> agent loopback.ip.of.peer >>>>>> >>>>>> I also see (less frequently), agentSubId 2 and 3 >>>>>> >>>>>> This SEEMS all correct to me, but for an unknown reason its >>>>>> doing... nothing, no errors (yes I got LOTS of errors at points, >>>>>> but i've resolved them all). >>>>>> >>>>>> >>>>>> Any ideas what else I might be missing? >>>>>> >>>>>> >>>>>> -Adam >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
