Submit a ticketCall us

Looking to compare latest NPM features with previous versions of NPM?
The NPM new feature summary offers a comparison of new features and improvements offered with this release.

 

Home > Success Center > User Device Tracker (UDT) > Troubleshooting the capture of voice vlans in UDT

Troubleshooting the capture of voice vlans in UDT

Table of contents
Created by Eric Bryant, last modified by Matthew Lamb on Jul 06, 2016

Views: 37 Votes: 3 Revisions: 9

Overview

This article explains what to troubleshoot when you are unable to see IP/Mac endpoint information for suspected voice vlans on a layer 2.

Environment

UDT version 3.2.2 -3.2.4

Detail

By default, voice vlans are not provided a port association via the standard Cisco OID vmMembershipSummaryTable (1.3.6.1.4.1.9.9.68.1.2.1) by design. This OID is what Cisco generally reports the vlan information through SNMP when such is requested. You can find more on this documented here.

 

If in the event though that you have applied either UDT 3.2.3 HotFix1 or UDT 3.2.4 and the voice vlans are still not showing up, run through the following:

 

1. Find what the vlan #.

 

2  Run the UDT compatibility checker against the layer 3 device.

 

Note: There must  be no access denied errors for the base port tables or the VMmembership table, if access denied errors are present see the following articles:

 

3. Run an SNMP walk for the context voice vlans, change the community string

For example:

 

If no OIDs are returned, check if the vlan contexts were setup correctly.

 

**If UDT is at 3.2.4 version and vlans are present in a walk then enable UDTPollAllActiveVLANs setting in the database via the following in Database Manager:

 Update [dbo].[UDT_Setting] Set SettingValue ='1' where SettingName = 'UDT.PollAllActiveVLANs'

 

Query to revert changes if needed. Setting should not effect performance however:

Update [dbo].[UDT_Setting] Set SettingValue ='0' where SettingName = 'UDT.PollAllActiveVLANs'

 

Important note regarding this feature: The alternative method for polling vlan information as documented above can cause the polling intervals to run longer than normal. This is in part because if a vlan is on the device but nothing is assigned to it, UDT will still attempt to poll for that vlan information and will have to await the timeout when nothing is provided. This can cause the layer 2 scan jobs to run longer than they were before, meaning some slight changes to the intervals must be made.

 

It's recommended to push the layer 2 polling interval out an additional 5 to 15 minutes to account for this alteration. You can also adjust the Layer 2 Job Timeout further as well within the UDT Settings > Advanced Settings portion to avoid the job timing out as well due to this change.

 

 

 

Last modified
09:52, 6 Jul 2016

Tags

Classifications

Public