Solved: DFM and NAM utilisation threshold

jedellerby · ‎02-24-2009

I'm trying to adjust the threshold for utilisation on DATA-PORT-1 on a NAM and I'm unable to get it working. I've gone through the following steps:

1) DFM > Configuration > Other Configurations > Group Administration: Customised a group to match on various parameters which I thought should be specific to my NAM. I don't have the list of parameters I tried but it included matching against "DATA-PORT-1" and "NAM", at least one of which found all the NAMs in my database. I tried the group under all three interface types (interface, trunk, access).

2) DFM > Configuration > Polling and Thresholds > Setting Priorities, and made sure the customized group was at the top of the group list.

3) DFM > Configuration > Polling and Threshold > Apply Changes

4) DFM > Configuration > Polling and Thresholds > Managing Thresholds, selected group, and clicked View.

I have found for all but ne of the group matches I tried to create, it failed to match against the NAMs and hence had no interfaces under view. On the one occasion it matched and listed all of the NAM interfaces except for the DATA-PORT-1 and -2, which is the one interface I need to change the threshold for!

My queries are:

1) What is the best process to determine which variable to match against in the group rules?

2) Does the fact that I getting high utilisation events against NAM DATA-PORT-1 automatically mean it's a managed entity? I assume so.

3) What type of port is a DATA-PORT-1, interface, access or trunk, I assume trunk?

Note there's a chance I didn't move the group to the top of the priority list on every rule/group combination I created so I'll go through that process once more.

Thanks

Jed

Joe Clarke · ‎03-05-2009

You may see that devices slip into Questioned state, or that events are no longer generated. This will happen if the Cisco Sybase databases become out of sync with the backend EMC repositories.

If you haven't done much configuration, and reinit at this point is safe, and not too costly.

The OID matching approach is fine if you want to match all interfaces on all NAMs.

View solution in original post

Joe Clarke · ‎02-24-2009

1. Go to DFM > Device Management > Device Details. Launch the DDV for your device, and look at the Interface Name and Description fields. These are the values you can specify when grouping. It's probably easier to match on Name than Description.

2. Yes, it sounds like it is managed as an interface correctly.

3. This is an interface, not a port. That is probably why you were unable to match.

jedellerby · ‎02-27-2009

jc,

The DDV check shows all of the interfaces including MGMT, DATA-PORT-1 and DATA-PORT-2.

I've setup the Interface/Customisable Group 1 group again and managed to match all the NAMs under the OID. The group is top of thr priority list. When I go to View under Managing Thresholds I do not see the MGMT, DATA-PORT-1 and DATA-PORT-2 interfaces. I do see all the other monitored interfaces such as ALLSPAN, NETFLOW and the VLAN interfaces I've setup to monitor. However, i's the DATA-PORT-1 and 2 that I get threshold alerts for so need to tune the threshold for.

The one difference I can see for the MGMT and DATA-PORT-n attributes is that they are ETHERNET CSMACD ports and not PROP VIRTUAL. The matching list of interfaces are all PROP VIRTUAL, so this seems to be the difference.

I tried searching for these interfaces under AccessPort and TrunkPort but they didn't show up either, probably what you expected.

Is this more likely a bug?

Jed

Joe Clarke · ‎02-27-2009

What is your grouping ruleset?

jedellerby · ‎02-28-2009

The ruleset is set to match on the system SNMP OID. It's under the interface group set.

I also made match on name work fine as you suggested but at the time the name of the NAMs varied, some were IP addresses and some were names so I mover over to the OID. I've since fixed the naming issue so all are in the database as names rather than IP addresses. That was a separate issue.

Jed

jedellerby · ‎02-28-2009

Oh, and I used group 1 rather than group A. Not quite sure if that should make a difference.

Joe Clarke · ‎02-28-2009

Please post the EXACT ruleset used so I can try and recreate this.

jedellerby · ‎03-04-2009

jc,

The group us Custonmizable Group 1 with parent rules of /DFM@/User Defined Groups/Customizable Interface Groups Interfaces OID equals "ANY".

The actual rule for the group is:

Interfaces.SystemObjectID equals ".1.3.6.1.4.1.9.5.1.3.1.1.2.291"

When I view the devices it normally finds all the NAM devices as I mentioned earlier.

However, I've just been through a seperate process of reimporting all the devices in DFM and rediscovering. I had issues with rediscover getting stuck at 10%/40% but a combination of restarting LMS twice and deleting the rps files appears to have fixed that issue.

Now that I've checked the NAM interface list again I am seeing the CSMACD interfaces that I wasn't seeing last week for all of the NAMs. So, I think the problem is fixed as it shows up in the 'view'.

I assume I had some kind of corruption/confusion in the database that led to this issue?

Jed

Joe Clarke · ‎03-04-2009

Possibly. However, deleting the rps files by themselves is not a good idea. This can lead to other problems. If you come to the point where you want to reinitialize the DFM databases, you should remove the DFM*.rps files AND do the following:

NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=dfmInv dmprefix=INV

NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=dfmEpm dmprefix=EPM

NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=dfmFh dmprefix=FH

jedellerby · ‎03-05-2009

What type of issues should I keep an eye out for now I've deleted the rps files without the database reinit?

There is only the one threshold group setup and some interfaces EXPLICITLY_UMANAGED so any reset of the database at this point in time wouldn't be too big a deal. Is it worth completing the steps you recommend above now to avoid possible future issues?

We'll be upgrading to LMS 3.2 shortly so I don't want this to lead to upgrade issues or confusion when I see a new issue.

BTW, was the OID matching approach a sensible way forward, now it's working I assume the answer is yes!

Jed

Joe Clarke · ‎03-05-2009

You may see that devices slip into Questioned state, or that events are no longer generated. This will happen if the Cisco Sybase databases become out of sync with the backend EMC repositories.

If you haven't done much configuration, and reinit at this point is safe, and not too costly.

The OID matching approach is fine if you want to match all interfaces on all NAMs.