Hi Adam, Sure, send me a backtrace. A low-touch option is to leave everything as is in the main-stream code, make you work with some value of 512 bytes, and document it back on the wiki so that it can be useful resource for future.
Actually, I'm curious about your use-case for this. I ask because by far i reckon the most interest is in the opposite direction, ie. get accounted only relevant subset of information (hence bgp_aspath_radius as value of the AS-PATH decreases as one gets far away from the own AS and bgp_stdcomm_pattern knobs). Cheers, Paolo On Thu, Jan 30, 2014 at 07:22:11PM -0500, Adam Jacob Muller wrote: > Hi, > Has anyone successfully raised the limits on these values (from > src/network.h). > > In particular, MAX_BGP_EXT_COMMS seems quite easily overrun at 96, > about 20% of the prefixes I see have communities that are longer > than that. (compared to well under 1% of as paths). > > I did attempt to recompile with larger values here, but bad > things(tm) happened. > (values = 512 for all 3). > * nfacctd started and worked fine > * pmacct immediately segfaults when you try to query (I can send a > backtrace on request -- preferably offlist to you Paolo) > > If you use a vanilla (96/96/128) pmacct (with a 512/512/512 > nfacctd), things are actually better oddly. > pmacct talks to nfacctd fine, and for the ext_comms anyway it works > fine (and you get the long community list!), however this appears to > break -everything- else. With most other things returning entirely > nonsensical data (things like as_path is always ^$, but I had the > expected number of entries in that table!). > > -Adam > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
