Thanks Paolo....looks like our dst_mask is showing up now in the
memory tables! (sql way too slow and IO constrained)
I wanted to ask about these messages we're getting in the logs now
that we're using mem tables:
WARN ( prefixes/memory ): Unable to allocate more memory pools, clear
stats manually!
WARN ( as_path/memory ): Unable to allocate more memory pools, clear
stats manually!
What does it mean? It seems like data is still getting into the mem
tables.
Here's the basic config we're using now:
plugins: memory[as_path], memory[prefixes]
aggregate[prefixes]: as_path, dst_net, peer_dst_as, dst_as, dst_mask,
tag
aggregate[as_path]: as_path, peer_dst_as, dst_as, tag
imt_path[as_path]: /tmp/sfacctd_as_path.pipe
imt_path[prefixes]: /tmp/sfacctd_prefixes.pipe
sfacctd_net: bgp
imt_mem_pools_number: 64
bgp_daemon: true
sfacctd_as_new: bgp
We've tried messing with the imt_mem_pools number but don't really see
it making a difference...maybe one of the other IMT options is needed?
Thanks,
-Brent
On Mar 11, 2010, at 9:36 AM, Paolo Lucente wrote:
Hi Brent,
Thanks very much for the feedback. I've just corrected the issue
and will commit it to the CVS shortly later today.
Cheers,
Paolo
On Thu, Mar 11, 2010 at 09:26:57AM -0800, Brent Van Dussen wrote:
Paolo -
Just tried to build the latest CVS version and am getting compile
errors
when configure option "--disable-l2" is used. When I re-configured
without it everything builds fine.
Here's the error I get:
-bash-3.2$ make
Making all in src
gmake[1]: Entering directory `/home/bvd/pmacct-cvs/pmacct/src'
Making all in nfprobe_plugin
gmake[2]: Entering directory `/home/bvd/pmacct-cvs/pmacct/src/
nfprobe_plugin'
gcc -DPACKAGE=\"pmacctd\" -DVERSION=\"0.12.1-cvs\" -DPROGNAME=1 -
DIM_LITTLE_ENDIAN=1 -DHAVE_PCAP_H=1 -DHAVE_LIBPCAP=1 -DPCAP_7=1 -
DPCAP_TYPE_linux=1 -DHAVE_DLOPEN=1 -DSTDC_HEADERS=1 -
DHAVE_SYS_WAIT_H=1
-DHAVE_GETOPT_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_TIME_H=1
-DHAVE_U_INT64_T=1 -DHAVE_U_INT32_T=1 -DHAVE_U_INT16_T=1
-DHAVE_U_INT8_T=1 -DENABLE_THREADS=1 -DRETSIGTYPE=void -
DHAVE_VSNPRINTF=1
-I. -I.. -O2 -DFLOW_SPLAY -DEXPIRY_RB -c -o
nfprobe_plugin.o
nfprobe_plugin.c
nfprobe_plugin.c: In function ???l2_to_flowrec???:
nfprobe_plugin.c:312: error: ???p??? undeclared (first use in this
function)
nfprobe_plugin.c:312: error: (Each undeclared identifier is reported
only once
nfprobe_plugin.c:312: error: for each function it appears in.)
gmake[2]: *** [nfprobe_plugin.o] Error 1
gmake[2]: Leaving directory `/home/bvd/pmacct-cvs/pmacct/src/
nfprobe_plugin'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/bvd/pmacct-cvs/pmacct/src'
make: *** [all-recursive] Error 1
Should be able to let you know shortly how the prefix length feature
works.
Thanks,
-Brent
On Mar 9, 2010, at 8:28 AM, Brent Van Dussen wrote:
Thanks for getting this set up Paolo!
We'll get the latest CVS version loaded and tested this week to
provide feedback.
Cheers,
-Brent
On Mar 7, 2010, at 1:34 AM, Paolo Lucente wrote:
Hi Brent, All,
On Sat, Feb 20, 2010 at 01:05:20AM +0000, Paolo Lucente wrote:
Would it also be possible to have the dst_net appended with mask
length
and a slightly larger DB field to accomodate it?
255.255.255.255/25
would be a CHAR(18) instead of CHAR(15) but it would be really
nice to
have this information from BGP or the sflow prefix field added in
so a
network map isn't needed.
Netmasks. They are not there but i've recently received two more
requests in a row for such a feature. All coming from people
making
use of the BGP feature. Hence, this is on my todo list and will
appear very soon - would say roughly 3-4 weeks. Would such approx
timeline match your expectations?
To say at this propo that network masks have now been implemented
as aggregation primitives. It's all published in the CVS. Network
masks lie in a different field from the IP prefix - so that this
implementation can get handy for other, ie. statistical, purposes.
Indeed, SQL language manipulation can be used to merge masks and
IP prefixes together on output.
Also, good property of this way of proceeding is that by keeping
masks in a separate field, they can be defined as INT(1) which is
space-savy compared to a string representation within the IP prefix
field. I already see this argument will not particularly impress
the PosgreSQL friends but it's done for the sake of selecting a
generic approach (not all RDBMS packages have the luxury of 'inet'
types ...).
Cheers,
Paolo
_______________________________________________
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
