Re: Restrict mcc netbox interfaces

On Mon, 1 Jul 2013 08:27:23 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:

Hi!

Unfortunately my network devices are very slow to anwser snmp get-bulk

requests, causing cricket process run indefinitely.

Hi Bruno,

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.

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.

Doing that would cause traffic collection for router ports to cease as well, and I would think those are at least as important as your VLAN trunks.

 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]

• interfaces = netbox.interface_set.select_related('netbox').filter(*

•    **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).

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)...

I've listed a few options above. I cannot guarantee that we will make 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/