Troubleshooting Guide: Wireless Access Points Not Discovered!!

[Selva Arun]

🔧 Troubleshooting Guide: Wireless Access Points Not Discovered

A Comprehensive Step-by-Step Guide for ServiceNow Administrators

Based on Real Production Troubleshooting Experience

✨ Community Contributed

👨‍💻 From Real-World Experience

This guide is based on my actual troubleshooting experience when our Network team reached out about missing Wireless Access Points in ServiceNow. After investigating hundreds of unreported WAPs during a major deployment, I discovered the root causes and created this comprehensive troubleshooting methodology. What started as a production issue became a learning opportunity that I'm now sharing with the ServiceNow community to help others resolve similar problems quickly.

— Selva Arun (Meena)

📋 Overview

This comprehensive guide provides step-by-step troubleshooting when your Network team reports that Wireless Access Points (WAPs) are missing from ServiceNow CMDB. This article is designed for ServiceNow administrators and ITOM teams supporting network discovery.

💡 Critical Concept: Understanding WAP Discovery

WAPs are NOT discovered directly!

Wireless Access Points are discovered through their Wireless LAN Controller (WLC), not by targeting the AP's IP address directly.

Wireless Controller Discovery (via SNMP)

↓

Controller classified as cmdb_ci_ip_switch

↓

Network Switch Pattern triggers

↓

Pattern queries controller for connected APs

↓

WAPs discovered as cmdb_ci_wap_network

✅ Key Takeaway

If the controller is misclassified or missing, no WAPs will be discovered.

1

Verify the Wireless Controller is Discovered

🎯 First Question to Ask

"Is the Wireless LAN Controller discovered in ServiceNow?"

How to Check:

1. Navigate to: Configuration > Servers > IP Switches
2. Search for the controller by:
   • Hostname (e.g., "wlc", "controller", "9800")
   • IP address (obtain from Network team)
   • Serial number
3. If controller is NOT found: Verify the controller's IP is in your discovery range and proceed to Step 2
4. If controller IS found: Note the CI Class field and proceed to Step 3

2

Verify Controller is in Discovery Range

Check Discovery Schedule:

1. Navigate to: Discovery > Discovery Schedules
2. Find schedules covering the network range
3. Verify the controller's IP is included

Run Quick Discovery:

1. Navigate to: Discovery > Quick Discovery
2. Enter controller IP address
3. Select appropriate MID Server
4. Click Discover
5. Monitor the discovery run

🚨 CRITICAL ISSUE: SSH Takes Priority Over SNMP!

Problem: If the wireless controller responds to both SSH (port 22) and SNMP (port 161), ServiceNow will prioritize SSH discovery over SNMP by default. This causes the device to be discovered as an "SSH device" rather than using SNMP classification, which prevents proper controller classification and WAP discovery.

How to Identify This Issue:

• Check the Discovery Status - if you see SSH probes triggered instead of SNMP - Classify
• Device discovered but not classified as IP Switch
• SNMP - Classify probe never runs

✅ SOLUTION: Use SNMP-Only Discovery Behavior

Force discovery to use SNMP instead of SSH by creating a Discovery Behavior:

Steps to Create SNMP-Only Behavior:

1. Navigate to: Discovery > Behaviors
2. Click New
3. Fill in the fields:
   • Name: "SNMP Only - Wireless Controllers" (or similar)
   • Type: SNMP
   • Applies to: IP Range or Specific IPs
   • IP Range/Device: Enter your controller's IP or subnet
4. In the Behavior section:
   • Check "Use SNMP"
   • Uncheck all other protocols (SSH, WMI, etc.)
5. Click Submit
6. Associate the behavior with your Discovery Schedule:
   • Open your Discovery Schedule
   • In the Behaviors related list, add the behavior you just created
7. Re-run discovery

Result: Discovery will now use SNMP to classify the device, triggering the SNMP - Classify probe and properly classifying the controller as an IP Switch.

⚠️ Other Common Issues

• IP not in range: Add the subnet to discovery schedule
• Credentials missing: Verify SNMPv3 credentials exist for the device
• Device not responding: Check firewall rules (UDP 161)
• MID Server connectivity: Verify MID can reach the management network

3

Check Controller Classification (CRITICAL)

🚨 Most Common Root Cause!

This step identifies 90% of WAP discovery issues.

Classification	CI Class	Status
✅ Correct	cmdb_ci_ip_switch	WAPs will be discovered
❌ Incorrect	cmdb_ci_ip_router	WAPs will NOT be discovered

💡 Why This Matters

The WAP discovery pattern is part of the Network Switch Pattern. If the controller is classified as a router, this pattern doesn't trigger, and WAPs remain undiscovered.

How to Verify:

1. Open the controller CI record
2. Check Class field at the top
3. If it shows "IP Router" instead of "IP Switch", proceed to Step 4

4

Identify the Root Cause - Missing SNMP OID

If the controller is classified as IP Router, the likely cause is a missing SNMP OID Classification record.

How to Find the Device's SNMP OID:

1. Navigate to: Discovery > ECC Queue > Output
2. Filter:
   • Name: "SNMP - Classify"
   • Source: [controller IP]
   • Queue: output
   • State: ready or processed
3. Open the most recent record
4. Click View XML or examine the Payload field
5. Search for: type="SnmpObjectId"

<!-- You'll find something like this: --> <sysObjectID oid="1.3.6.1.2.1.1.2" type="SnmpObjectId">.1.3.6.1.4.1.9.1.XXXX</sysObjectID>

Copy the OID value (e.g., 1.3.6.1.4.1.9.1.3323) - Remove the leading dot if present

📊 Example OIDs for Common Cisco WLCs:

Model	SNMP OID
Cisco C9800-40-K9	1.3.6.1.4.1.9.1.2530
Cisco CW9800M	1.3.6.1.4.1.9.1.3323
Cisco WLC 5520	1.3.6.1.4.1.9.1.1631

5

Check if OID Exists in Classification Table

1. Navigate to: Discovery > Classification > SNMP OID Classification
2. Search for the OID you found (e.g., 1.3.6.1.4.1.9.1.3323)
3. If no record exists: This is your root cause - proceed to Step 6
4. If record exists but incorrect:
   • Check Classifier field - should be "Standard Network Switch"
   • Check Table field - should be "cmdb_ci_ip_switch"
   • If incorrect, update and re-run discovery

6

Create Missing SNMP OID Classification

📝 Required Information

Before creating the record, gather:

• OID: From Step 4
• Model Name: From Network team or device documentation
• Manufacturer: Usually "Cisco Systems, Inc." for Cisco devices

Create the Record:

1. Navigate to: Discovery > Classification > SNMP OID Classification
2. Click New
3. Fill in the fields:

Field	Value	Example
Active	true (checked)	✓
OID	[OID from Step 4]	1.3.6.1.4.1.9.1.3323
Classifier	Standard Network Switch	Standard Network Switch
Manufacturer	Cisco Systems, Inc.	Cisco Systems, Inc.
Model	[Model name]	CW9800M
Table	cmdb_ci_ip_switch	cmdb_ci_ip_switch

4. Click Submit

7

Verify Model Record Exists

The SNMP OID Classification may reference a model that doesn't exist in the Product Model table.

1. Navigate to: Configuration > Product Model
2. Search for the model name (e.g., "CW9800M")
3. If not found, create new record:
   • Name: [Model name]
   • Display Name: [Full product name]
   • Manufacturer: [Lookup Cisco Systems, Inc.]
   • Model categories: Network Gear (optional)

8

Re-run Discovery and Verify

Run Discovery:

1. Navigate to: Discovery > Discovery Schedules
2. Find the schedule containing the controller
3. Click Discover Now
4. Wait for completion

Verify Controller Classification:

1. Navigate to: Configuration > Servers > IP Switches
2. Search for controller
3. Verify:
   • Class: cmdb_ci_ip_switch ✓
   • Model: Correct model ✓
   • Manufacturer: Cisco Systems, Inc. ✓

Verify WAP Discovery:

1. Navigate to: Configuration > Servers > Access Points
2. Filter by: Wireless LAN Controller: [controller hostname]
3. Verify WAPs are now present

🎉 Success!

If you see WAPs in the Access Points table with the correct controller relationship, you've successfully resolved the issue!

🔍 Common Scenarios and Solutions

📖 Real-World Context

During a major wireless infrastructure deployment at our organization, the Network Operations Center reported receiving 397 alert tickets overnight for staging Access Points. Investigation revealed that hundreds of WAPs weren't being discovered in ServiceNow because their wireless controllers were misclassified. The scenarios below represent the actual issues encountered and resolved during this production troubleshooting effort.

Scenario 1: SSH Takes Priority Over SNMP (VERY COMMON!)

Symptom

Controller discovered but classified incorrectly; SSH probes run instead of SNMP - Classify

Root Cause

Device responds to both SSH (port 22) and SNMP (port 161). ServiceNow defaults to SSH with higher priority, preventing SNMP classification

Solution

Create Discovery Behavior with "SNMP Only" for the controller's IP/subnet and associate it with your Discovery Schedule

Prevention

For all wireless controllers, create SNMP-only behaviors proactively to force SNMP discovery

Scenario 2: New Controller Model

Symptom

Brand new wireless controller model deployed

Solution

Create SNMP OID Classification record (Steps 4-7)

Prevention

When deploying new hardware models, proactively create OID classification records

Scenario 3: Controller Classified as Router

Symptom

Controller discovered but classified as cmdb_ci_ip_router

Root Cause

Missing or incorrect SNMP OID Classification

Solution

Follow Steps 4-8

Scenario 4: Some WAPs Missing

Symptom

Controller discovered correctly, but not all WAPs appear

Possible Causes

• WAPs not yet associated with controller
• Discovery timing (AP was offline during scan)
• Missing MIB files for specific AP models

Solution

• Verify all APs are associated in controller management interface
• Re-run discovery
• Check if additional MIB files are required

Scenario 5: WAPs Discovered but Missing IP Addresses

Symptom

WAP CIs created but IP address field is empty

Known Issue

Related to Visibility Content app versions 6.19.0+

Reference

KB1647806 (ServiceNow Known Error)

✅ Quick Reference: Troubleshooting Checklist

Use this checklist when Network team reports missing WAPs:

Is the wireless controller discovered in ServiceNow?
→ If NO: Check discovery range and credentials
→ If YES: Continue

Is SSH taking priority over SNMP?
→ Check Discovery Status - are SSH probes running instead of SNMP - Classify?
→ If YES: Create Discovery Behavior for "SNMP Only" (see Step 2)

What CI Class is the controller?
→ If cmdb_ci_ip_router: Missing/incorrect OID classification
→ If cmdb_ci_ip_switch: Continue

Find controller's SNMP OID from ECC Queue Output
→ Search for type="SnmpObjectId" in XML

Does OID exist in SNMP OID Classification table?
→ If NO: Create classification record
→ If YES: Verify classifier is "Standard Network Switch"

Does Product Model exist?
→ If NO: Create model record

Re-run discovery and verify:
→ Controller class = cmdb_ci_ip_switch
→ WAPs appear in Access Points table
→ Relationship: WAP → Controller exists

🛡️ Prevention and Best Practices

👥 For Network Teams:

1. Notify ServiceNow team before deploying new controller models
2. Provide model name, IP address, and SNMP credentials
3. Allow ServiceNow team to create classification records before go-live

💻 For ServiceNow Teams:

1. Maintain a library of SNMP OID Classification records for common network devices
2. When new models are reported, immediately check for OID classification
3. Document model-to-OID mappings for your organization
4. Subscribe to ServiceNow Knowledge Base for pattern updates

📊 Proactive Monitoring:

1. Create report: "Controllers without Associated WAPs"
2. Monitor discovery logs for classification failures
3. Regular CMDB health checks for wireless infrastructure

📌 Summary

When WAPs are not discovered, the issue is almost always with the Wireless LAN Controller classification, not the WAPs themselves. By following this systematic troubleshooting approach, you can quickly identify and resolve the root cause.

Key Takeaway: Ensure wireless controllers are classified as cmdb_ci_ip_switch by creating proper SNMP OID Classification records for new models, and use Discovery Behaviors to force SNMP discovery when devices respond to both SSH and SNMP.

This troubleshooting methodology was developed from real production experience and has been successfully used to resolve WAP discovery issues across multiple wireless controller models. I hope it helps you solve similar challenges in your ServiceNow environment!

Was this article helpful? 🙏

Please mark it as 'Helpful' to help other community members find this solution more easily!

Have questions or suggestions? Feel free to comment below or reach out to your ServiceNow administrator.

Article by Selva Arun (Meena)

📚 Additional Resources

SNMP Discovery Explained (KB0752582) Discovery of WAPs (KB1511615) Cisco WAPs Discovery Documentation Understanding WAP and WLC Discovery

Tags: #SNMP #Discovery #WirelessAccessPoints #WAP #WLC #NetworkDiscovery #Troubleshooting #CiscoWLC #Classification #ITOM

Shared with the ServiceNow Community | Based on Real Production Experience