# SNMP polling and traps Discover network devices and poll them over SNMP with a Tracix Collector, match them to device profiles, and receive their traps and informs. A Tracix Collector on your network finds SNMP devices in the address ranges you give it, polls them for interface, CPU, memory and hardware metrics, and receives the traps and informs they send. You set all of it up in one integration, **SNMP**, on a collector policy. ## Before you begin * A [Tracix Collector](https://tracix.io/docs/collect/collector/install) that can reach your devices on UDP 161, and that they can reach on the trap port, UDP 162 by default. * Read-only credentials your devices accept: an SNMP v2c community, or an SNMPv3 user with its authentication and privacy settings. ## Set up SNMP **1. Open the connect steps** In your workspace, open **Collectors › Integrations** and select the **SNMP** tile, under **Network & Discovery**. **2. Choose where it runs** SNMP runs on your own collectors. Under **Where to add this integration**, pick the policy of the collectors that can reach the devices, or create one. **3. Say what to scan** In **CIDRs**, list the ranges to sweep, such as `10.0.0.0/24`. A `/32` polls one specific device. Set the **Site** the devices belong to: it fills the **Site** column on Devices and groups them on the topology map. Leave **Port** at 161 unless your devices listen elsewhere. **4. Enter the credentials** For SNMP v2c, leave **SNMP version** at **v2c** and enter the **Community (v2c)**. For SNMPv3, choose **v3**, then open **Advanced** and enter the **User (v3)**, with its **Auth protocol (v3)** and **Auth password (v3)**, and its **Priv protocol (v3)** and **Priv password (v3)**. **5. Review and connect** Check the **Collection interval** (default 5 minutes) and the trap settings, then **Review** and **Connect**. Collectors on the policy pick up the new revision of their policy. ### SNMPv3 security levels The user's security level follows the passwords you enter: | You enter | Security level | | ---------------------- | ------------------------------------------ | | Both passwords | `authPriv`: authenticated and encrypted | | The auth password only | `authNoPriv`: authenticated, not encrypted | | Neither password | `noAuthNoPriv`: neither | Use `authPriv` where your devices support it. The protocols default to SHA-256 and AES-256; MD5, SHA-1 and DES are there for older devices and are weak. A privacy password without an auth password is not a valid user: the collector doesn't poll with it, and policy validation flags the field. With **SNMP version** at **v2c**, a v3 user is used only to accept the devices' traps and informs, not to poll. ### Discovery settings | Setting | Default | What it does | | ---------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------ | | **Collection interval** | 5m | How often each discovered device is polled | | **Device profiles** | Auto | Leave empty to match each device to a profile automatically, or pick profiles to limit a mixed network | | **Rescan interval** | 15m | How often the ranges are swept for new devices | | **Probe timeout**, **Retries**, **Concurrency** | 5s, 1, 50 | How the sweep probes each address | | **Auto-accept discovered devices** | Off | Adds discovered devices to Devices without the confirm step | | **Generate profiles for unknown devices with Brain** | On | Builds a profile for devices no built-in profile matches. Needs a model credential in AI settings. | ## Confirm discovered devices The collector sweeps every address in the ranges and fingerprints each device that answers by its `sysObjectID`, `sysName` and `sysDescr`. New devices wait in **Network › Discovery Candidates**, where you **confirm** or **reject** each one, unless the integration auto-accepts them. Confirmed devices appear in **Network › Devices & Inventory**. When several collectors on a policy can reach the same devices, only one of them polls at a time, and another takes over if it stops reporting. Every collector on the policy receives traps. ## Device profiles A profile says which OIDs to poll for a kind of device and what to call the results. Tracix ships 174 device profiles, plus 21 building blocks they share, derived from Kentik's SNMP profiles under the Apache 2.0 license. Each device is matched in this order: 1. An exact `sysObjectID` match. 2. The longest matching `sysObjectID` prefix. 3. A pattern on `sysDescr`. A device that matches nothing is never given a profile silently: it is flagged on Discovery Candidates, where Brain can propose one for you to confirm. Every device, matched or not, gets the base interface and system metrics. ## What is collected Metrics follow OpenTelemetry semantic conventions where they exist, with Tracix names only where OpenTelemetry has none. Counters are stored raw, and rates are computed when you query them. | Area | Examples | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Interfaces | `hw.network.io`, `hw.network.packets`, `hw.errors`, `hw.network.up`, `network.interface.discards`, with `network.interface.name`, `network.interface.index` and `network.interface.speed` | | System | `device.uptime`, CPU and memory, from the device's profile | | Identity | `device.hostname`, `device.manufacturer`, `device.model.name`, `device.serial` | | Neighbors | LLDP neighbors, which draw the links on the topology map | Devices appear in **Network › Devices & Inventory**, with tabs for interfaces, hardware, routing and more where the device reports them. Their metrics are also in **Insights › Metrics Explorer**. See [Devices](https://tracix.io/docs/network/devices) and [Discovery and topology](https://tracix.io/docs/network/discovery-topology). ## Receive traps and informs Traps are part of the same integration and are on by default. Point each device's trap destination at a collector on the policy: | Setting | Default | What it does | | ----------------------------------- | ------------- | -------------------------------------------------------------------------------- | | **Receive traps and informs** | On | Turns the trap listener on | | **Listen address** | `0.0.0.0:162` | The UDP address and port the collector listens on | | **Additional accepted communities** | None | Communities accepted besides the integration's own | | **Accept SNMPv1 traps** | On | Translates v1 traps to their v2 form, so a v1 and a v2c `linkDown` read the same | | **Keep uncurated traps** | On | Keeps traps without curated meaning as info events, named from the MIBs | The collector accepts SNMP v1 and v2c traps whose community the integration accepts, v2c informs with that community, and v3 traps and informs from the integration's v3 user, and drops the rest. You enter the credentials once: the integration's community and v3 user serve both polling and traps. It acknowledges an inform only after it has accepted the record. Most devices learn the collector's SNMP engine ID when they first send it a v3 inform. Some, such as Cisco IOS and IOS-XE, need it configured: the list of collectors that listen shows each one's **Engine ID** beside its address. Configure it on the device as the remote engine for that address and port before you create the v3 user, because the device derives the user's keys from it. **1. Check where to send traps** After you connect, the last step lists the collectors that listen, with their addresses, under **Point your devices at the collector**. The same list is on **Devices** under **Traps**. **2. Configure your devices** Set each device's trap destination to one of those addresses on the listen port, with the integration's community or its v3 user. **3. Keep the source address** The collector identifies a device by the address its traps come from. Don't send traps through anything that rewrites the source address, such as a NAT or a load balancer that changes it. ### Ports below 1024 UDP 162 needs permission to bind a low port, and not every collector has it: * **Linux** collectors get it from the installer. Hosts installed before the installer granted it need the current installer run once; until then they get no listener on 162. * **Kubernetes** collectors on the chart's default profile can't bind it. Set **Listen address** to `0.0.0.0:1162` and send traps to the node on 1162, or redirect 162 to 1162 on every node. * **Docker** collectors installed with the console's command receive traps on host UDP 1162 by default. Set `TRACIX_TRAP_HOST_PORT` before you run the command to use another host port. * **macOS** and **Windows** collectors can bind 162. The Windows installer adds a firewall rule for the collector. All SNMP integrations on a policy share one listener per collector, at the listen address of the first integration by name. ### How traps are stored Each trap or inform becomes one log record, in the `snmp.traps` dataset, named `MODULE::name` from a MIB dictionary built into the collector. Curated traps carry a severity and open or clear conditions, such as a link going down and coming back. The collector drops repeats of the same trap within 10 seconds and limits each source to 50 traps a second, with a burst of 200; while it limits a source, it records a storm event. Traps appear on **Network › Devices & Inventory** under **Traps**, on each device's **Traps** tab, and in **Insights › Log Explorer**. When you connect, **Enable trap alerts** installs Tracix's monitors for common traps. See [Monitors](https://tracix.io/docs/alerting/monitors). There is no custom MIB upload: trap names come only from the built-in dictionary. ## Next steps - [Devices](https://tracix.io/docs/network/devices): Work with your device inventory - [NetFlow, IPFIX and sFlow](https://tracix.io/docs/collect/network-data/flows): Add traffic data from the same devices - [Syslog](https://tracix.io/docs/collect/network-data/syslog): Receive the devices' logs