Discovery and identity matching

What discovery does

Find devices gathers evidence from addresses on the management networks recorded in Cenovel. Found devices is the review queue for what answered, what needs access, and what could not be identified. Finding an address does not, by itself, add a new inventory asset or approve its physical location.

Use the site view when you know where the equipment belongs. Use the district view when reviewing networks and discoveries across sites. A result may identify a switch, access point, server management controller, or another device. Identification and successful collection of every hardware detail are separate outcomes. An Administrator EX can also turn on a nightly find, which is off by default; it only fills Found devices, and nothing is added until someone adds it.

Prepare the network and access

Only private management networks are accepted. Each network can be at most a /22, with up to 256 listed networks and 4,096 addresses in one find. Divide larger ranges into appropriate approved networks. These limits keep the selected scope explicit; a public address is not a supported discovery target.

1. Confirm the site exists and, for switches, that its closet has been recorded. A switch must be assigned to a closet at the selected site before it can be added from the queue.
2. Add or enable the intended private management network under Networks. Use its network address, such as 10.20.30.0/24, rather than a host address with a network suffix. A single address can be entered as a /32.
3. Configure an active credential in Governance › Monitoring › Configuration › Access. Only Administrator EX can create or change credentials; ask one if the site has none that applies. Device CLI credentials support SSH; SNMPv3 credentials support SNMP discovery. A site credential must cover the selected site. A district credential can be used across sites.
4. For SSH, verify the device fingerprint through a trusted source before approving a new key. A new-key result means identification stopped at the trust check; it is not an invitation to repeatedly change passwords.
5. Check your permissions. Site discovery changes require equipment-page edit access and Operator or above. District discovery follows Monitoring permissions. Adding a server also requires Monitoring edit permission.

Run a find and review the result

The current finder can use SSH, SNMPv3, or server management evidence according to the available credentials and responses. It does not promise to collect both SSH and SNMP evidence for every found device. A successful SSH identification can finish that address before SNMP is attempted.

Ignore records a review decision for a waiting item. The same device remains ignored when found again. Use Ignore for a deliberate decision, not as a substitute for correcting missing access or an unresolved serial conflict. The queue can be filtered to Waiting for review, In Cenovel, Ignored, or All.

1. Open Find devices for the intended scope and start a find, or choose a single address within the approved scope. Watch the run status rather than starting repeated copies of the same search.
2. Open Found devices and inspect the reported name, vendor, model, serial, address, method, credential label, and last-seen time. When a site collector performed the read, the result identifies that collector.
3. Read the explanation beside a result that needs attention. Correct the credential or trust problem, then find the address again. Stop a run when its scope is wrong or further attempts are no longer useful.
4. For an identified device awaiting review, open Add. Confirm the site, closet where required, device name, and catalog model. Review the model diagram and the available interface evidence before confirming the model.
5. Choose Add to Cenovel only after the identity and placement are settled. If the item or selected model changed while the form was open, reload and review the current information before trying again.

Understand access and partial results

A timeout, closed service, or credential that Cenovel cannot open is not proof that hardware was removed. Read the run explanation and the observation time. Repeated credential refusals are remembered for a limited window, and remaining attempts can be held; immediately repeating the find may therefore try fewer credentials.

Partial component reads must not turn an omitted power supply or fan into a removal. A missing serial at an already identified attachment also does not establish a replacement. A positively reported changed serial is different evidence and can identify a replacement. Complete empty inventory can establish absence, while the former inventory asset remains available as a record.

A successful SSH command is not enough to prove a complete hardware inventory. If a supported Junos, EXOS, or IOS/IOS-XE chassis inventory command returns text with no recognizable chassis or member identity, Cenovel records a parse failure and treats the read as partial. The same protection applies when the output contains more recognizable member-row headings than the parser can recover as members. The successful connection still counts as reachable; the unreadable inventory does not prove component removal.

Cenovel also treats malformed numbered Junos member, PIC, transceiver, power-supply and fan-tray rows as incomplete evidence. An unreadable member or PIC heading cannot give its children the previous heading’s location: those children are skipped until a valid sibling or ancestor is found. Existing components remain recorded when the inventory is incomplete. This protection has passed automated checks but has not been verified against physical equipment, and it may not be in your installed version.

Scroll the table sideways to read all columns.

How existing identities are treated

When adoption checks existing inventory, a unique live serial match takes precedence over the device name. If more than one live record carries that serial, Cenovel requires review instead of choosing an arbitrary record. Without a usable serial match, a name match is limited to the selected site and its locations; duplicate names also require review.

A result already recognized as an existing asset directs you to that asset to review its whereabouts. It is not another Add opportunity. A serial found only in deleted inventory is surfaced as a reappeared asset. Discovery neither restores it automatically nor creates a replacement copy; if it is back in service, restore the deleted record from the found item's Restore button or from Recently deleted; otherwise ignore the found item.

For example, a switch may answer at a new address under a new hostname while retaining its unique serial. Review the existing record and location rather than creating another asset for the new address. Conversely, the same hostname with a different serial may represent replacement hardware. Resolve the replacement from the existing device page instead of merging the two identities.

Finish the review

When SSH discovery supplies component evidence, adoption preserves the time that evidence was actually collected. Adding the device does not make an old observation fresh. A subsequent scheduled read updates the evidence and reconciles the same chassis and component identities when their reported identity remains unchanged.

• Confirm the asset opens under the intended site and closet, and distinguish reported whereabouts from an approved inventory move.
• For a stack, check each reported member and serial. Incomplete or contradictory member evidence is not permission to assign all components to the stack head.
• Review component findings separately from the chassis result. A readable switch can still contain a part whose catalog identity needs a decision.
• Keep unresolved results visible until the access, model, or identity issue is understood. A successful find is evidence for a decision, not a guarantee that every device feature was read.