On Mon, 1 Jul 2013 08:27:23 -0300 Bruno Galindro da Costa <bruno.galindro@gmail.com> wrote:Hi Bruno,
> Hi!
>
> Unfortunately my network devices are very slow to anwser snmp get-bulk
> requests, causing cricket process run indefinitely.
AFAIK, Cricket does not use get-bulk requests at all; I would venture to
guess that your devices are slow to respond to SNMP requests, period.
Doing that would cause traffic collection for router ports to cease as
> Is it possible to implemment a new feature to restrict the number of
> interfaces generated by mcc.py? So, I can tell to mcc.py to only
> generate trunk interfaces config.
well, and I would think those are at least as important as your VLAN
trunks.
> * interfaces = netbox.interface_set.select_related('netbox').filter(*
> Searching in source code, i've found this piece of code. I think the
> bold line that must be upgraded to provide this feature:
>
>
> def create_interface_config(netbox, targetdir, module):
> """Create config for this netbox and store it in targetdir
>
> returns: a list of containers
> """
> LOGGER.info("Creating config for %s" % targetdir)
>
> config = CONFIG[module]
> * **config['filter']).distinct().order_by('ifindex')*
I wouldn't change that line, but rather the CONFIG dictionary of that
module. If you want to exclude switch ports that are non-trunk ports,
you can make a modification like this diff:
========================================================================
diff --git a/python/nav/mcc/interfaces.py b/python/nav/mcc/interfaces.py
--- a/python/nav/mcc/interfaces.py
+++ b/python/nav/mcc/interfaces.py
@@ -26,7 +26,7 @@
'dirname': 'ports',
'boxfilter': ~Q(category='EDGE'),
'filter': (Q(gwportprefix__isnull=False) |
- Q(baseport__isnull=False) |
+ (Q(baseport__isnull=False) & Q(trunk=True)) |
Q(ifconnectorpresent=True)),
},
}
========================================================================
This would ensure that any switch port (baseport number is not null)
selected for traffic data collection must also be a trunk. The filter
will still include router ports and physical ports. You may also wish to
exclude physical ports by removing the `Q(ifconnectorpresent=True)`
criterion.
NAV includes the main IP device category "EDGE" for one reason only:
Cricket would not scale to the massive amounts of switch ports installed
at NTNU, so they decided to exclude all access/edge switches from
traffic stats collection and created the EDGE category to mean "a switch
we don't collect interface traffic counters from". This might also be an
interesting option for you.
Another Cricket issue is that it works in a purely serial manner. Any
delay in collecting a single value will delay the entire Cricket
collection run, which must complete within 5 minutes to be on
time. Cricket can be made to run partially in parallel by modifying the
`subtree-sets` file and splitting the configuration trees into two or
more subsets (the latest NAV version ships with a subtree-sets that
defines a single "nav" set with all of Cricket's directories).
NAV's `cron.d/cricket` file can then be modified, duplicating the
cricket-collector line, once for each configured subtree set, and
replacing the subtree set name on each instance with one from the
`subtree-sets` file. These sets will then be collected in parallel (as
soon as you run `nav restart cricket` to update the actual crontab).
I've listed a few options above. I cannot guarantee that we will make
> Until this feature can be applyed, is there any workarround that I can
> do to acomplish that? All of my switches trunk ports is standardized to be
> in the last ports (22 to 26 and 44-48)...
this into a configurable feature of mcc.py, as we are currently in the
process of throwing out Cricket and rrdtool from NAV and replacing it
with the more scalable Graphite [1] and new plugins for ipdevpoll. When
these changes are released, the above issues may become moot. Collection
will always run in parallel, so a delay in one device should not affect
the others.
[1] http://graphite.wikidot.com/
--
Morten Brekkevold
UNINETT