How GLPI SNMP network discovery fills gaps that agents leave
Network teams usually need switches, routers, firewalls and printers in GLPI, and most of these devices cannot run a GLPI Agent. A GLPI Agent can collect hardware and software inventory from the computers and servers it is installed on, and the GLPI Agent documentation describes its role in network discovery and inventory as well. For devices with no agent option, the GLPI Inventory plugin offers SNMP discovery as another route to find them and collect their data. In practice, teams tend to run agent inventory for endpoints and servers, then use SNMP discovery to cover network gear and printers that sit outside that reach.
Plan the two methods as complements. Agent data tells you what is installed on a host. SNMP discovery tells you that a device answers on the network and what it reports about itself, which is often limited to identity, interfaces and basic status. Decide early which device classes must appear in GLPI, which ones already arrive through agents, and where the two sources could create duplicate asset records. Duplicates are easier to prevent in the design than to clean up later.
Confirm the exact discovery and inventory capabilities against the GLPI Inventory plugin version you plan to run, since behavior differs between plugin releases. Check which device types and SNMP versions it supports, what data it returns for each one, and which settings control the scope. Test the plan on a small set of switches and printers from each vendor in your estate before committing to a rollout. The results will show whether SNMP alone gives enough detail for the records you need, or whether some devices need a different source.
Discovery and inventory settings and when each fits
This table compares the main configuration choices for SNMP discovery in the GLPI Inventory plugin, with the situations where each fits and the trade-off it carries. Read each row as a decision: the left column names the setting, the right columns say when it suits your network and what it costs in load, coverage or maintenance. Confirm exact limits and defaults in the plugin documentation for your installed version before you commit to a design.
| Setting | When it fits | Trade-off |
|---|---|---|
| Scan ranges and scope | Flat printer subnets with a known address plan, where one range per floor or site keeps results easy to review | Narrow ranges reduce load but miss devices that move or sit outside the plan; wide ranges catch more but add scan time and noise |
| Scan ranges by network segment | Segmented core networks, where each VLAN or management subnet needs its own reachable scanner or agent | Each segment adds a task to maintain; reachability from the scanning host must be confirmed per segment |
| SNMP credentials by protocol version | SNMPv2c where devices are older and read-only community strings are already managed under a change process | Community strings travel with weaker protection than SNMPv3; confirm which versions each device model supports |
| SNMPv3 credential sets | Core switches, routers and managed printers that support authenticated and encrypted access and where security teams require it | More setup per device class and more credential records to rotate; mismatched security levels cause silent misses |
| Discovery tasks | Initial mapping of an unknown network, or when you need to find new devices before deciding what to inventory | Discovery identifies devices but gathers less detail, so it does not replace a full inventory pass |
| Inventory tasks | Known devices where you need model, serial, firmware, interfaces or printer counters on a schedule | Requires credentials and reachability for each target; depends on discovery results being in place first |
| Thread or concurrency limits | Large ranges or slow SNMP devices, where lower concurrency protects the scanning host and the network | Lower limits extend total run time; higher limits finish sooner but can overload older devices or links |
| Scheduling | Daily or weekly inventory for stable switches and printers, with discovery run less often on a wider range | Frequent runs keep records current but add load and log volume; infrequent runs leave new or replaced devices unrecorded for longer |
| Entity and import rule assignment | Multi-site organizations where discovered devices must land in the correct entity by location, subnet or device type | Rules must be ordered and tested; a broad rule can assign printers or network gear to the wrong entity |
Set up SNMP discovery in GLPI, step by step
This sequence takes a GLPI instance from version check to verified switch, router and printer records in the right entity. Each step ends with a check so the team can confirm the result before moving on to the next range or device class.
Confirm GLPI and plugin versions
The GLPI administrator records the GLPI core version and the GLPI Inventory plugin version, then checks both against the installation documentation for supported PHP and database versions. Confirm that the plugin version matches the GLPI core version, since a mismatch is a common reason discovery tasks fail to start. Done when the versions are written down in the change record and the GLPI Agent that will act as the discovery host is confirmed to be on a supported release, according to the GLPI Agent documentation.
Agree in-scope address ranges with network owners
The network team and the GLPI administrator agree in writing which subnets, VLANs and device classes discovery may scan, and which addresses are excluded such as firewalls, guest networks and industrial equipment. Record the owner of each range and the agent or server that will scan it. Done when every range has a named owner and an approved change record, so no device is probed without a responsible party.
Create read-only SNMP credentials on devices
The network team creates SNMP read-only credentials on switches, routers and printers, using SNMPv3 where the device supports it and limiting access to the discovery host's address. Store the community strings or SNMPv3 users in GLPI's SNMP authentication configuration rather than in notes or spreadsheets. Done when one test device answers an SNMP query from the discovery host with the new credential, and the credential is recorded in the password store with an owner.
Run discovery against a pilot range
The GLPI administrator creates a discovery task limited to one small pilot range that includes a known switch and a known printer, then runs it from the GLPI Inventory plugin. Keep the pilot range small so that any unexpected load or noisy device can be identified quickly. Done when the task completes and reports the number of addresses scanned and devices found, with no error from the agent for the pilot range.
Review discovered devices before inventory
The administrator opens the list of discovered devices and checks each entry against the network owner's records, confirming that IP addresses, serial numbers and device types are correct. Mark devices that should not be managed as ignored or unmanaged, and leave unknown devices for the network team to classify. Done when every pilot device is either accepted for inventory or deliberately excluded, with the decision noted against the device.
Run inventory tasks on approved devices
The administrator creates an inventory task for the accepted devices only, and sets the task to run once before any recurring schedule is enabled. Watch the task log for SNMP timeouts and authentication failures, which usually point to a wrong credential or an access list on the device. Done when the task finishes with the expected number of devices inventoried and the logs show no unresolved credential errors.
Verify entity placement and asset type
Open a known printer and a known switch in GLPI and confirm that the model, serial number, IP address and asset type are correct, and that each record sits in the entity that the network owner expects. Check that the printer appears as a printer and not as a generic network device, and that the switch appears with its ports. Done when a named person from the network team signs off on the spot checks, and any mismatch has a corresponding rule adjustment or ticket.
Widen scope in stages
Once the pilot passes, the administrator adds the next approved range, repeats the discovery and review steps, and keeps a record of each expansion. Watch the thread limits and scan timing for the discovery host, and stop expanding if the task log shows timeouts or the network team reports device load. Done when every approved range has been scanned, reviewed and checked, and the recurring schedule is enabled with an owner for each range.
Choosing SNMP credentials by device and environment
Many network printers and older switches only speak earlier SNMP versions, and their firmware is often the last thing a vendor updates. For these devices, the practical question is not whether to use SNMP but how to limit what the credential can do. A community string is a shared secret sent with each request, so anyone who can observe the traffic can reuse it. Keep these devices on their own credential set, and scope it to read-only access so it cannot change device configuration.
- Segment the discovery path: Limit which GLPI Inventory discovery tasks can reach printer subnets, and avoid reusing a community that also works on core switches.
- Use a unique community per site or device class: A leaked string should expose one area, not the whole estate.
- Plan for replacement: Record these devices in GLPI so they are visible for refresh, replacement or firmware review.
- Confirm version support per model: Check each model's documentation or vendor SNMP notes, since support differs between printer families.
Before relying on a legacy credential, confirm the exact SNMP version and community the device model accepts and that the read-only scope holds on that firmware.
Managed switches and routers from recent generations can usually be configured for SNMPv3, which adds named users with authentication and privacy settings. Authenticated SNMPv3 users are stronger than community strings because each request is validated and can be encrypted, and the user can be restricted to read-only views. This is the preferred option wherever the device supports it, and it should be the default for new network segments.
- Create a dedicated read-only user: Do not reuse an administrative account for discovery.
- Choose authentication and privacy settings the device supports: Confirm which algorithms the firmware offers before standardizing on them.
- Restrict the view: Limit the user to the MIB objects discovery needs, where the device allows it.
- Document the user per device group: Record the user name and its scope in your configuration standard so audits can trace it.
- Rotate on a schedule you can run: Plan credential changes so discovery tasks are updated in the same window.
Confirm with each vendor which SNMPv3 security levels and algorithms your exact models and firmware versions support before you build the credential set.
Most organizations run both generations side by side, often on the same subnet. The risk in a mixed estate is that a single broad credential list gets tried against every device, which spreads weak secrets across the network and produces noisy failures. The better pattern is to group devices by what they support and give each group its own discovery task and credential set, so the plugin only offers each device the credentials it was designed for.
- Group by capability, not by location alone: Put SNMPv3-capable switches in one group and printers in another, even if they share a building.
- Keep the credential lists short: Fewer entries per task means fewer failed attempts and less exposure.
- Track which group each device lands in: Review unmatched devices after each run and move them into the right group.
- Plan the migration path: Move devices to SNMPv3 when firmware allows, and retire the community credential once no device uses it.
Confirm how the GLPI Inventory plugin orders credential attempts in your version and whether a failed SNMPv3 attempt is followed by the community attempt, since that order determines what each device is exposed to.
Thread limits and scan timing on large networks
Discovery and inventory on a large network need controlled concurrency because every parallel SNMP query adds load on both the target devices and the links between the GLPI server and the network. Switches and printers often have modest management CPUs, and a burst of polling can slow the devices themselves or saturate a WAN link to a remote site. The thread setting in the GLPI Inventory plugin controls how many devices are queried at once. Set it too low and a run stretches out, so a scan may not finish before the next window opens and the same devices are queried again while the previous job is still running. Set it too high and you risk timeouts, missed responses and devices that appear to have disappeared. Confirm the exact configuration point, its name and its allowed values in the plugin documentation for your version, and do not carry a number over from a forum post or another environment.
Size the work before you choose a value. Split the address space into ranges that match sites, VLANs or management subnets, and record how many devices each range is expected to hold. Stagger the discovery and inventory tasks by site so that remote locations with narrow links do not all run at the same hour as the head office, and keep tasks for the same range from overlapping. Use the first full pass as a baseline: record the start and end time of each task, the number of devices that responded, and the number that timed out or were skipped. Ask your GLPI Inventory plugin provider or implementation partner to confirm how the task log reports these figures in your version, so that the baseline is comparable from one run to the next.
After the baseline, watch run durations as a trend rather than as a single result. A run that grows week over week usually means new devices, a slower link, or a thread setting that no longer matches the size of the range. A run that finishes far earlier than before can mean that devices stopped answering, which is a discovery gap rather than good news. Plan a review after each change to the network, such as a new site, a switch replacement or a large printer rollout, and adjust the range or schedule before the next window. Keep the schedule, the ranges and the thread setting in your change records so that a future engineer can explain why a run took the time it did.
Why switch ports and printers go missing after a discovery run
Why do switch ports not appear after a GLPI SNMP discovery run?
Most missing ports come from SNMP access that works for the device but not for the interface tables. Check that the credential on the discovered switch matches the SNMP version configured in GLPI, and that the community or user has read access to the interface branches, not only to the system information. Some switch models expose port data under different OIDs or restrict bridge and interface tables by default, so confirm the model's SNMP support with the vendor. Next, test a single switch from the GLPI server with a read-only SNMP query before changing any GLPI settings, so you can separate a credential problem from a model limitation.
Why is my printer found but shows no toner or page count data?
A printer that is discovered but returns no supply or counter data usually means the device answers on the basic system OIDs but not on the printer MIB branches that report toner levels and page counts. Printer support varies widely by manufacturer and firmware, and some models only expose these values through a vendor-specific MIB or a web interface. Check whether the printer's SNMP agent is enabled, whether its community string or SNMPv3 user has access to the printer MIB, and whether the firmware is current. If the device still reports nothing, treat the gap as a model limitation and confirm supported data points with the vendor before you plan any custom work.
Why do discovered devices end up as unmanaged or ignored in GLPI?
Discovered devices land as unmanaged or ignored when the import rules or the discovery settings do not match them to an existing record or a known device type, or when a rule explicitly refuses them. Typical triggers are a missing serial number or MAC address, a duplicate match with an existing asset, or a device class that no rule accepts. Start by reading the device's entry in the discovery results and noting which identifiers it reports. The sibling topic on handling ignored and unmanaged devices covers how to decide which records to keep, quarantine or promote, so use it once you have confirmed the identifiers are present.
Why does a GLPI network discovery run stop partway through?
A run that stops partway usually hits a limit rather than a failure in one device. The common causes are the thread count being set too high for the server or the network, SNMP timeouts and retry values that are too short for slow switches, and firewall rules that drop UDP traffic after a burst of queries. Check the task logs for the last device processed, then compare its response time with the timeout configured in the discovery task. Reduce the thread count and increase timeouts before rerunning, and confirm that the GLPI server can reach the target subnets on UDP port 161 for SNMP queries.
Why does the same switch or printer appear twice in the asset list?
Duplicates appear when the discovered device and an existing record do not share a matching identifier, so the import rules create a second asset instead of updating the first. This often happens when a device was first added by hand or by an agent, then discovered by SNMP with a different name, IP address or serial format. Compare the two records for serial number, MAC address and management IP, and check which matching rule applied to each. Fix the matching rules so that identifiers from SNMP and from agents map to the same asset, then merge the existing duplicates under a documented procedure rather than deleting either record.
Why does SNMP work from one network segment but not another?
Reachability differences between segments usually come from firewall rules, access control lists on the switches, or SNMP agents restricted to specific management addresses. The GLPI server or discovery agent must be allowed to send UDP requests to port 161 on each target, and the device must accept requests from that source address. Test each segment separately with the same read-only query, and check whether the device's SNMP configuration limits access by source IP. If the segment is managed by another team, ask them to confirm the rules in writing before you change anything on the GLPI side.
Can our own team fix these discovery gaps, or do we need a partner?
Your team can diagnose most of these gaps if it has access to the network devices, the GLPI server and its logs, and the vendor documentation for each model. The work that usually takes longer is the inventory of which models are in scope, the credential rollout across switches and printers, and the matching rules that prevent duplicates. A partner is often used when the estate is large, when several network teams must coordinate changes, or when the discovery design needs to be written down before rollout. Any engagement is scoped in writing before work starts, and the quote follows from that scope, so ask for the device list, credential approach and log review to be listed as deliverables.
What should we ask a vendor or partner about SNMP support before a rollout?
Ask which SNMP versions each switch and printer model supports, which MIB branches it exposes for interfaces, bridge tables and supplies, and whether those branches are enabled by default. Ask for the read-only credential requirements, any known limitations in firmware versions you run, and whether the vendor documents the source address restrictions. Your answers determine which GLPI discovery settings are needed and which devices will need manual handling. Keep the answers in a device support matrix so that later troubleshooting starts from documented facts rather than guesses.
Security and operational risks in SNMP discovery
SNMP discovery reads detailed information from network devices, and the credentials and scan settings you choose determine both how much an attacker could learn and how much load your older equipment absorbs. The cards below cover the controls to set before the first scan and the records to keep afterward.
Read-only credential scope
Create SNMP credentials that can only read the objects GLPI needs for device identity, interfaces and printer counters, and never write. A read-write community string on a switch can change configuration, so a read-only account limits the damage if the credential leaks. Confirm with your network team which community strings or SNMPv3 users already exist, and remove any that are no longer needed.
Preferring SNMPv3
Use SNMPv3 with authentication and privacy wherever the device supports it, because SNMPv1 and v2c send community strings in cleartext. Check each device model's documentation for supported security levels before you add it to the discovery configuration. Plan a fallback for legacy printers that only offer v2c, and keep those devices on a separate, tightly scoped task.
Limiting scan ranges to approved subnets
Define discovery ranges from your IP address management records and approved subnets, not from a broad network sweep. Scanning unmanaged segments can pick up guest networks, industrial controllers or third-party equipment you do not own. Review each range with the network owner before the task runs, and record who approved it.
Protecting stored credentials in GLPI
SNMP credentials are stored in the GLPI database through the plugin configuration, so anyone with database or administrative access may be able to read them. Restrict the profiles that can open discovery configuration, and check how the installed plugin version stores and encrypts these values. Confirm this with the plugin documentation for your version, and include the GLPI encryption key files in your backup and key management plan.
Load on legacy devices
Aggressive polling and high thread counts can slow older switches, routers and printers, and some embedded devices stop responding under sustained SNMP queries. Start with a small range, a low thread limit and an off-hours window, then measure device response before widening the scope. Ask your network team which devices have known SNMP stability issues, and exclude them or schedule them separately.
Discovery logs and change records
Keep discovery task logs, the credential change history and the approved scope documents together so an auditor can trace which device was found, when, and under which authority. Review the log retention settings in your GLPI version and confirm they meet your records policy. Record every change to a discovery range or credential as a change request, so the inventory evidence has a clear chain of custody.
What does a GLPI SNMP discovery project cost and take?
What drives the cost of a GLPI SNMP discovery project?
The main drivers are the number of device types, the number of sites, the mix of SNMP versions in use, how credentials are stored and rotated, how segmented the network is, and how much import rule design the data needs before it is trusted. A flat network with one SNMP version and a few printer models is far simpler than several sites with separate VLANs, SNMPv3 users per segment and a long list of vendor models. Each of these adds discovery scopes to define, tests to run and mappings to review. Ask any partner to break its quote down by these factors so you can see which assumptions carry the cost.
How long does a pilot take compared with a full SNMP rollout?
A pilot usually covers one site or one network segment, a small set of device types and a short list of rules, so it is much shorter than a full rollout. The full rollout depends on how many sites and segments need discovery scopes, how many device models must be classified, and how long change windows and firewall approvals take in your environment. Neither duration can be known from a general description, so ask for a timeline built from your site list, your segment map and your approval process, and agree the pilot exit criteria in writing before work starts.
Can our own team run a GLPI SNMP discovery project without a partner?
Yes, a team that already runs GLPI and manages its network can do this in-house, provided it has someone who understands SNMP versions, MIB behavior, SNMPv3 user design and GLPI's discovery and inventory task model. The usual gap is not GLPI configuration but testing across real device models, tuning thread limits and reviewing why ports or devices go missing. Be honest about the time that testing and rule tuning will take from staff who also have other duties. A partner is most useful when the scope is wide, the timeline is fixed or the team lacks SNMP experience.
What do network and security teams need to provide?
Network staff need to supply the switch, router and printer inventory, management IP ranges, VLAN and segment layout, SNMP read access on devices, and approval for the discovery traffic and firewall rules that let the GLPI server or agents reach devices. Security staff need to approve how SNMP credentials are created, stored and rotated, and whether SNMPv3 with per-segment users is required. Both teams should agree on who owns credential changes after go-live, because a rotated community string or user will otherwise stop discovery silently.
Which SNMP credential handling choices affect cost and risk?
Credential design affects both effort and exposure. SNMPv1 and SNMPv2c use community strings that are sent in clear text, while SNMPv3 adds authentication and encryption but needs a user, passphrase and privacy settings for each device group. Storing many credentials in GLPI means more configuration, more testing and more rotation work, but fewer shared secrets. Ask how the project will document each credential set, who can read it in the GLPI interface, and how a rotation is rolled out without losing devices during the change.
Does import rule design add to the effort of a discovery project?
Yes, import rule design is often the largest hidden effort. Discovered printers and switches arrive with vendor model names, serial numbers and sysDescr strings that do not match your asset types, so each device family needs rules that assign the right type, entity and status, and that refuse or quarantine devices that should not enter the inventory. The effort grows with the number of device families and with the number of exceptions your network holds. Plan review time with the people who own your asset records, because rules that look correct in a test can still misfile real devices.
What does the GLPI Network subscription page tell us about cost?
The official GLPI subscription page at glpi-project.org is where published GLPI Network plan prices appear, so check there for current subscription figures before comparing options. Those prices cover the GLPI Network service, not the work of designing and testing discovery in your environment. DeployOpen quotes follow a written scope agreed before work starts, so the quote will list the sites, device types, credential sets, rule families and deliverables included, and what your team must supply.
Limits to confirm in your environment before rollout
Discovery results depend on the SNMP support of your own hardware, the GLPI and plugin versions you run, and the size of the scan ranges you plan to use. Confirm each item below with the vendor, the plugin documentation or a pilot before you set a rollout date.
SNMP versions and OIDs per model
Ask each switch, router and printer vendor which SNMP versions (v1, v2c or v3) and which OIDs the model answers for system, interface and printer supply data. SNMPv3 settings such as the security level and authentication protocol must match the device exactly, or the device appears silent. Test one unit per model in a pilot subnet and record which fields came back, since a missing field is often a model or firmware limit rather than a GLPI fault.
GLPI and plugin version compatibility
Record the GLPI core version and the GLPI Inventory plugin version you run now, then check the plugin's compatibility notes against your planned move to GLPI 11 or 12. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so plan that step into the upgrade window. Confirm with the plugin documentation whether discovery and task behavior change between versions.
PHP and database requirements
Check the server against the installation docs before you size the discovery host. For GLPI 11.0 the docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and they state that only MySQL and MariaDB are supported. The GLPI README lists newer requirements for the main branch, so confirm which set applies to the release you will deploy and whether your database version is inside it.
Large address range handling
Ask how the plugin schedules discovery across very large address ranges, including how it splits work, how many threads it uses per task and what happens when a scan overruns its window. Thread limits and range size together decide whether a /16 finishes, stalls or silently skips hosts. Run a pilot on your largest real segment, count the devices found against the number you expect, and tune the thread limit and task split before scaling out.
Asset data against your inventory process
Compare the fields discovery writes, such as serial number, model, firmware, IP address and location, against the attributes your asset inventory process and any control evidence require. Ask who owns the mapping of discovered devices into asset types, and whether printers and network gear will be reviewed before they count as managed assets. If a field is not captured, decide whether it will be entered manually or collected another way.
How DeployOpen scopes and delivers GLPI network discovery
DeployOpen plans and builds GLPI SNMP network discovery and printer inventory inside your own infrastructure, starting from a written scope that names the network segments, device types and SNMP credential model in play. The work moves from discovery runs through inventory tasks and import rules to documented handover, so your team can run the discovery schedule after the engagement ends.
How we scope
- Inventory the subnets, VLANs and sites where switches, routers and printers sit, and record which are in discovery scope.
- Agree which SNMP versions, community or user credentials and vendor models the written scope covers before work starts.
- Define entity assignment, ignored device rules and the systems that must be checked against discovery results.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. Quotes follow from that written scope.
How we build
- Configure the GLPI Inventory plugin and GLPI Agent discovery tasks, with the SNMP credentials stored under access controls you approve.
- Run discovery first, review what is found, then schedule inventory tasks against the devices your scope confirms.
- Tune thread limits and task batching per network segment, then test that switches, routers and printers return complete data.
- Check missing ports and unmanaged devices against the device list, and document the cause of each gap found.
How we hand over
- Deliver written runbooks covering discovery schedules, credential rotation, import rules and how to add a new network segment.
- Document the test results for each device class, including which models returned full port and printer supply data.
- Walk your operations and service desk staff through reviewing discovery reports and promoting real devices into the asset inventory.
- Hand over configuration exports and version notes so the GLPI and plugin upgrade path can be planned by your own team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped to your GLPI and plugin versions.
- Review discovery coverage after network changes, new printer fleets or GLPI and plugin upgrades under the agreed scope.
- Confirm with your network team which SNMP settings, firewall rules and device firmware your environment requires before each change.
- Ask any support proposal to state the response expectations, covered versions and the work that falls outside the retainer.
