cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1343
Views
0
Helpful
4
Replies

UT causing DFM authentication alarms?

Hello,

DFM is showing lot's of authentication failure minor alarms which match the User Tracking major acquisition schedule.

The message description says the non-authenticated source is the IP address of the LMS server itself.

EVENT DESCRIPTION       = MinorAlarm::Component=<managedDeviceName>: Authentication Failure;Description=Non-authenticated source :<LMS IP address>;

I have done a Device Credential Verification and it was successful for both snmp and cli

What would be causing this alarm? 

Thanks, Graeme

2 Accepted Solutions

Accepted Solutions

Joe Clarke
Cisco Employee
Cisco Employee

If your community strings contain '@' that could cause this.  Depending on the configuration or UT or the version, this could also be a bug where UT is querying VLANs which do not exist on the switch.

View solution in original post

The inactive name doesn't mean anything.  Campus will label a VLAN as inactive if it's unable to obtain some VTP information from the switch.  The problem is that a port is assigned to a VLAN that is not present on the switch.  What will happen is that Campus will record all port access and auxiliary VLANs.  UT will query all of these VLANs.  However, if a port is configured in a VLAN that is not present on the switch, then the switch will throw an authFail unless the "no snmp-server trap authentication unknown-context" command is configured.

Unfortuantely, there is no other way to know (via SNMP) that a VLAN is not present on a switch.  Therefore, to fix this, you'll need to either disable the unknown-context traps or correct the switch's config.

View solution in original post

4 Replies 4

Joe Clarke
Cisco Employee
Cisco Employee

If your community strings contain '@' that could cause this.  Depending on the configuration or UT or the version, this could also be a bug where UT is querying VLANs which do not exist on the switch.

Thanks Joe,   I have tracked down what's happenning.

The VLAN doesn't exist in the VLAN database of the switch. But, there is at least one port assigned to this non-existent VLAN.

Looking in CM it seems to know that this VLAN doesn't exist as the "VLAN Port Assignment" displays the VLAN Name as "inactivexx" where xx is the vlanID.

So my question is, should UT not attempt to walk devices using community@xx since it will/should always return an error.

Of course the root of the problem is on the switch in that the VLAN has been deleted with ports still assigned to it which needs to be fixed.

This situation sounds like a good candidate for CM Discrepancies - if it isn't already?

thks, Graeme.

:Update:

Looking a bit wider in CM I can see a switch that has VLAN1 only defined (ahem) with operational ports on it yet the VLAN Name in CM is showing as inactive1. AFAIK switches alway name vlan1 as "default", not sure why CM doesn't match.

So maybe my theory about vlans named "inactive*" is not quite correct. Under what circumstances does CM name a VLAN "inactive*" ?

The inactive name doesn't mean anything.  Campus will label a VLAN as inactive if it's unable to obtain some VTP information from the switch.  The problem is that a port is assigned to a VLAN that is not present on the switch.  What will happen is that Campus will record all port access and auxiliary VLANs.  UT will query all of these VLANs.  However, if a port is configured in a VLAN that is not present on the switch, then the switch will throw an authFail unless the "no snmp-server trap authentication unknown-context" command is configured.

Unfortuantely, there is no other way to know (via SNMP) that a VLAN is not present on a switch.  Therefore, to fix this, you'll need to either disable the unknown-context traps or correct the switch's config.

OK, understand. Thanks

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco