SNMP

Every other discovery source looks at endpoints. SNMP looks at the network devices you manage: the switches, routers and access points under Infrastructure → Network → Devices. Taranac asks each device what it is and keeps its vendor, model, serial number, software version and uptime, its ports, its LLDP/CDP neighbours and its forwarding table. The last two are what endpoints gain from it: a switch’s neighbour table carries what phones and access points say about themselves, and its forwarding table says which port a MAC address is behind.

Profiles and templates are under NAC → Discovery Sources → SNMP. Whether a device is polled, and what it answered, is on the device itself.

For v3, the Signing algorithm is one of MD5, SHA1, SHA224, SHA256, SHA384, SHA512, and the Encryption algorithm one of DES, 3DES, AES128, AES192, AES256. The form offers only what this build can actually perform, and says so if something is missing.

The recommended pair is SHA1 / AES128, and the form pre-selects it. It is what the estate answers on. In our lab, three devices out of five could not do SHA-2 at all (Cisco IOS 15.2 and RouterOS 7.5 accept only MD5 and SHA-1), and that depends on the software version, not the vendor. Choose SHA-2 where you know the device supports it. AES192 and AES256 are not described by any SNMP standard, and vendors implement them with incompatible key schemes. The form warns that such a profile may work on one vendor and fail on the next, with an error that looks exactly like a wrong passphrase.

A new installation has four example profiles: Example: v2c read-only (the default), Example: v3 authPriv (SHA-1 / AES-128) with user taranac-sha1, Example: v3 authPriv (SHA-256 / AES-128) with user taranac-sha256, and Example: v1 read-only. Their communities and passphrases were generated when the installation was created. Nothing is shipped, and no two installations share a credential. To use one, reveal the secret (this needs the Reveal secret permission and is audited) and configure the same values on your devices. Until you do, a device polled with an example profile usually reports Silence on v1/v2c and Unknown user on v3: the profile is complete, and what is missing is on the device.

A device either names a profile or is set to Inherit, which takes the Default profile from the Defaults card on the SNMP page. The device form shows the result as Applied: … with where it came from, for example set on this device or inherited from the defaults. It also shows who will do the asking (Asks from: …).

Who polls is a property of the profile (Poll from): the core, or one named site collector. A profile that names a collector is polled by that collector or not at all. There is no silent fallback to the core. A poll that succeeded from the wrong place would describe a network path nobody uses, and a failure is named by where it happened:

A collector runs exactly the same collection code with the same template as the core, so answers from the two are comparable.

A poll asks four things, independently:

The vendor comes from the IANA enterprise number inside sysObjectID (1.3.6.1.4.1.14988.… is MikroTik). It answered correctly on every device measured, including the ones that name no model. The forwarding table is a snapshot: each poll replaces the previous one, and a MAC that left the table is removed.

Vendors put the same facts in different places and keep inventing new ones. A template is the map, and it is data you can copy and correct yourself, without waiting for a release.

• What to read about the device. Four fields (Model, Serial number, Software version, Platform / software image), each with a list of sources tried top to bottom, where the first non-empty answer wins. A source is An OID I type, A standard ENTITY-MIB column, Read out of sysDescr (a pattern), or This platform does not report it.
• One pattern over sysDescr can fill several fields at once. *EOS version {os_version} running on an Arista {platform} is the whole reading of Arista’s sysDescr. Patterns use * and {field} placeholders, the same language as profiling rules. They are not regular expressions, because a regular expression run on text a device chose, on every poll, is a fault waiting to happen. A pattern needs literal text before the first field.
• “Not reported” is an answer. This platform does not report it ends the list: the field stays empty because the vendor reports nothing, and the device card says not reported instead of looking incomplete. A MikroTik CHR is a virtual machine with no serial number anywhere, and its template says so.
• Ports, neighbours and the MAC table are choices rather than addresses, because reading a forwarding table is index arithmetic, which is code. You can drop port rows by name pattern (up to 10 patterns, for example InLoopback*). Neighbours are read by LLDP, CDP or both in order, with the local port read as an interface index (the usual) or a bridge port number (Extreme). The MAC table is read by one of five modes:

The two per-VLAN modes cost one walk per active VLAN on every poll, and walk the VLAN list from Where the VLAN list comes from (the standard dot1qVlanStaticName table, or an OID you type). If no source there answers, the poll falls back to one plain walk.

A shipped template is never changed. Editing one saves a copy and leaves the original alone, so there is no reset button: the original is always there. A template can declare its vendor (Declared vendor (IANA enterprise number)). That is used only to warn in the connection test when the template is pointed at another make of device. It never stops a poll, because the standard part of any template works on any device.

Every shipped template was measured on real devices in our lab, and its description says what was measured.

There is no automatic choice of template. Two Cisco devices of one IOS family needed opposite MAC-table settings in our lab, and both identify as Cisco, so a guess based on the vendor would be wrong half the time. Point each profile at the template its devices need.

Polling is off on every device until you switch it on, with Poll this device on the device form. It is not inherited. A switched-on device is polled once per poll interval, which the Defaults card shows read-only, with who sets it (every 60 min · Stated by: Core). The interval is set on the core by SNMP_POLL_INTERVAL_SECONDS in .env (default 3600, clamped to 60 to 604800). The scheduler checks every minute which devices are due, and only the cluster leader polls.

A device has to be entered as a single host address. SNMP asks one specific address, so a device whose network object is a subnet is reported as No single address. A device entered by name is refused too: a name resolves through DNS, and a trace could not say which address it talked to.

A device that has no SNMP agent at all can be marked This device does not support SNMP, with a required reason. It is then not polled, and not counted as failing, until someone clicks Put it back in the poll.

When a scheduled poll fails, an alert for that device says why. One alert per device, however long it stays silent, and it is closed once the device is no longer polled.

The device form (Infrastructure → Network → Devices, open a device) has an SNMP section:

• Poll this device: the switch. Off until you turn it on.
• SNMP profile: Inherit, or a named profile, with Applied: … and Asks from: … below it. Create a profile and use it here is offered when there is none.
• Test the connection…: the Test drawer for this device and profile.

Each identity field is badged with who wrote it. A poll fills Vendor, Platform, Model, Serial number and OS version only where the field is empty or was last written by SNMP. It never overwrites a value a person typed. When the device answers differently from what was typed, the field shows take from SNMP with the device’s value. Take the device’s answer writes that one field at once, records it in the audit log, and from then on the field follows the device. The rest of the form still waits for Save. Every change a poll makes to these fields is also audited, with the previous value and who had written it.

The SNMP Info tab shows What the device says about itself (the five facts, uptime, sysName, sysObjectID, sysLocation, sysContact, sysDescr and the raw answer), with Collect now. It also shows Ports, forwarding table, neighbours, each with its own collect button. Each table separates not asked from asked, and empty. An empty neighbour table usually means LLDP is switched off on the device. An empty forwarding table on a Cisco usually means it needs per-VLAN reading. The device list has an SNMP column and filter: Answering, No answer, Never polled, Polling off, No SNMP.

Test on a device… (from a profile, even an unsaved one) and Test the connection… (from a device) hold one conversation with one device and report it in full. A test changes nothing on the device.

The drawer leads with Will it collect?. Each area (Device facts, Ports, Neighbours, MAC addresses) is tried under a ceiling and shown with its count, and with a note when something is missing: which fields this agent does not report, an agent whose SNMP view excludes the interface table, or neighbours answering on the other protocol than the template reads. For the forwarding table it asks twice, once plainly and once for one VLAN, and says whether to switch the per-VLAN mode on, whether it would not help, or whether it is not needed.

Show the whole conversation opens the trace. For v3 it shows the Engine-id exchange first: a v3 request is three round trips, and nearly every v3 failure happens in the first two. Then every request with its attempt number and timing, and What the device said, object by object with its OID. No such object is a definite answer and is shown as different from a value that could not be read. Copy the trace puts it on the clipboard for a ticket.

The drawer names the failure in terms of what to check:

A test with a saved profile against a device is filed as that device’s last answer: a test is a smaller poll. With an unsaved profile or a bare address, the answer is shown and not filed, and a failed test does not count as a failed poll. With Save the profile and file this answer, one step saves the draft and keeps the result.

For a device whose poll comes back empty or not at all, run on the core host:

./taranac diagnose --protocol snmp --device "core-sw-01"

--device is the device’s name in Taranac (or its id), not an address. The address polled is one of the things the report works out and explains. The tool runs one real poll through the same collection code the scheduled poll uses, writes nothing to the database, and produces one text report in ./diagnostics/ (use --out DIR to put it elsewhere), layer by layer, cheapest first:

1. Resolution, before any packet: whether polling is on, which profile applied and where it came from, version and algorithms, port, timeout and retries, who would ask, which address and why.
2. Crypto state: which USM algorithms this image can perform, and whether the profile’s are among them.
3. The v3 engine-id exchange on its own.
4. The poll: every request, numbered and timed.
5. What was learned and what was not: which objects the device declined to have, CDP checked when LLDP is empty, which forwarding MIB answered, and when the table carries no VLANs, one VLAN-indexed request with both counts side by side. This is the answer to “why is the MAC table empty”.

The report never contains a community or passphrase, not even its length. If the profile polls from a collector, the report says so at the top: the conversation it records is the core’s own and serves as a comparison, not the collector’s poll.

Switch-port location. An endpoint’s page has a Where it is plugged in card. It lists every switch port whose forwarding table holds the endpoint’s MAC, with the likely access port first and a reason for each: the switch authenticated the device on that port, the device announces itself there over LLDP or CDP, it is the only edge port reporting it, it has the fewest MACs, or the port leads to another device you manage. It needs the forwarding tables of your access switches, so poll them. See Endpoints.

Neighbour descriptions for profiling. LLDP and CDP are how a desk phone, access point or camera tells the switch what it is (Cisco IP Phone 8845, AP 3802I). When a neighbour’s chassis or port id is an endpoint’s MAC, including the SEP + MAC id Cisco phones use in CDP, its description becomes that endpoint’s LLDP / CDP self-description signal. A neighbour that is merely on the same port (a PC behind a phone) does not describe that PC. The scanner hearing the same frame counts as the same witness, not a second one. A switch sees every access port in the estate, whereas a scanner sees only the wires it is attached to.

sysObjectID. A polled device that is also an endpoint (an access point or switch that authenticates to a port), recognised by an interface MAC equal to the endpoint’s, gives its sysObjectID to profiling as the SNMP sysObjectID signal. It is the vendor’s IANA arc, assigned rather than claimed. See Profiling rules.

Allow only Taranac’s address (or the collector’s, for a profile that polls from a site) to query, and give read-only access. Examples for the shipped Example: v3 authPriv (SHA-1 / AES-128) profile. Reveal its passphrases first.

Cisco IOS / IOS-XE:

ip access-list standard TARANAC-SNMP
 permit 10.0.0.10
!
snmp-server view TARANAC-RO iso included
snmp-server group TARANAC v3 priv read TARANAC-RO access TARANAC-SNMP
snmp-server user taranac-sha1 TARANAC v3 auth sha <signing passphrase> priv aes 128 <encryption passphrase>
!
! neighbours: CDP is on by default; LLDP is not
lldp run

snmp-server user lines do not appear in the running configuration. Check with show snmp user. For a Cisco whose forwarding table needs per-VLAN reading over v3 (Per VLAN, context vlan-10), the group must also serve the VLAN contexts: snmp-server group TARANAC v3 priv context vlan- match prefix read TARANAC-RO access TARANAC-SNMP. With v2c, Per VLAN, community@10 needs nothing more than the community.

MikroTik RouterOS 7:

/snmp community add name=taranac-sha1 addresses=10.0.0.10/32 security=private \
    authentication-protocol=SHA1 authentication-password=<signing passphrase> \
    encryption-protocol=AES encryption-password=<encryption passphrase> \
    read-access=yes write-access=no
/snmp set enabled=yes

On RouterOS, v2c communities and v3 users share one list of names, and a second entry with an existing name is refused. That is why the two v3 examples use different user names. Neighbours are read over LLDP, which RouterOS supports.

After configuring, use Test the connection… on the device before switching Poll this device on.

Start polling the access layer. Configure the default profile’s credential on the switches, pick the template that fits (for mixed Cisco access switches, start with Cisco IOS / IOS-XE and run the Test drawer on one of each model), switch Poll this device on, and check Will it collect?. Within one interval, endpoints show Where it is plugged in.

A Cisco switch with an empty MAC table. Run Test the connection…. If it says to switch on the per-VLAN table, give that switch’s profile the Cisco IOS — forwarding table per VLAN template (or a copy of your own with Per VLAN, community@10).

A vendor with no shipped template. Copy Standard (RFC), add the vendor’s OIDs or a sysDescr pattern for the fields it keeps elsewhere, and use This platform does not report it for what the platform lacks. Test it against one device before pointing a profile at it.

A site the core cannot reach. Create a profile with Poll from set to that site’s collector, and use it on the site’s devices.

• Discovery & profiling: where SNMP fits among the sources.
• Endpoints: the switch-port card, and classification.
• Profiling rules: the LLDP/CDP and sysObjectID signals.
• Scanner: the other way to hear LLDP and CDP.
• Collectors: polling from a site.