Checkmk
to checkmk.com

1. What is SNMP?

1.1. Using SNMP instead of a Checkmk agent

Routers, switches, firewalls, printers, appliances, UPSs, hardware sensors, and many other devices do not allow the installation of a Checkmk agent. They do however already have a built-in interface for monitoring provided by their manufacturer — an SNMP agent. This agent can be accessed via the Simple Network Management Protocol (SNMP). Checkmk uses SNMP to monitor such devices. The benefit for you is that setting up the monitoring is very easy.

There are also SNMP agents for Windows and Linux, however using these instead of the Checkmk agent is not recommended. SNMP is not very performant, so using this for monitoring generally means that the Checkmk server needs more CPU and memory per host than when working with its own agent. In addition the data provided via SNMP are incomplete. In some cases, however, monitoring via SNMP in addition to the Checkmk agent can be useful. See the chapter on SNMP and Checkmk agent for more on this topic.

However, if there is no Checkmk agent plug-in for monitoring a particular hardware or software component (e.g. a RAID controller), but the component has an SNMP interface, you can of course collect additional monitoring data via SNMP. In such a case, make sure that the query intervals are long enough.

Monitoring SNMP devices with Checkmk is very easy. If you just want to get started quickly with SNMP, you will probably need to read the short section on SNMP in the Beginner’s guide. This article goes into much more depth, and shows you all of the details and specific scenarios when SNMP monitoring with Checkmk.

1.2. SNMP versions

The SNMP protocol is available in different versions. These protocols are all incompatible with each other, and so the monitoring system and the monitored device must always consistently use the same protocol version. Checkmk supports versions v1, v2c, and v3. In practice, an estimated 99 % of installations use v2c. Here is an overview of all of the relevant versions of SNMP:

Version Features Checkmk Description and application in practice

v1

yes

Use only on very old (say, 15 years and older) devices that do not support v2c, or their support for v2c is defective.

v2c

Bulk queries,
64-Bit-Counter

yes

This is the standard in practice. v2c is a ‘light’ variant of v2 and the ‘c’ here stands for Community, which performs the role of a password in SNMP. The 64-bit counters are essential in monitoring switch ports with 1 Gbit/s and more. The bulk queries accelerate monitoring by up to a factor of 10.

v2

Security

no

Version 2 offers even better security options in addition to the features of v2c. Version 2 of SNMP is not found in practice, therefore CMK does not support this protocol version. If you need security use version 3 instead.
Attention: Since the ‘real’ version 2 has no relevance, many masks in Checkmk refer simply to v2, but always really mean v2c.

v3

Security,
Context

yes

Version 3 is used when encrypting SNMP traffic. With v2c and v1 this runs in plain text – including in the community. In practice, version 3 is rather less common, because this version requires significantly more computing power, and also the cost of the configuration is significantly higher than with v2c. The Contexts are a concept in which different information is visible in the same area of the SNMP data structure (OID), depending on the context ID. This would be used for partitioning of Fibre Channel switches for example.

1.3. SNMP traps

Checkmk uses active requests for SNMP monitoring – a pull method. Checkmk sends a UDP packet (port 161) containing an SNMP request to the device requesting the provision of specific data. The device then responds with a UDP packet containing the response data (or an error message).

SNMP has a second process: SNMP traps. These are spontaneous push messages sent by devices at configured addresses via UDP (Port 162) in push mode. Traps have many disadvantages over active requests, which is the reason they are not very important for monitoring. Some of the disadvantages are:

  • Traps are not reliable. UDP packets can be lost. There is no confirmation of receipt.

  • Mostly only Error messages are sent, but no Recovery messages. Thus the current status in the monitoring is unclear.

  • If thousands of switches simultaneously send traps (for example, if an important upstream service is not available for them), the trap receiver will not be able to handle it and will break under the load. Monitoring will then be overloaded when you need it most.

  • When changing the trap receiver’s IP address, all devices must be reconfigured.

  • Traps are hard to test. Few devices even have a function to send a generic test trap -– let alone test real error messages. Therefore it is difficult to predict whether an important trap will be processed correctly when its first invocation occurs after a few months or years.

However if you want or need to work with traps, the Event Console provides a solution. This can receive traps and generate events from them.

2. Setting-up SNMP in Checkmk

2.1. Preparing a device

The first step is to prepare the device. Each device that supports SNMP has its own configuration mask somewhere in its configuration. Make the following settings in this configuration mask:

  1. Go to configuration for active queries (SNMP GET). (Do not confuse this with the traps — the terminology in the configuration dialogs can be very confusing).

  2. Enable SNMP for reading requests.

  3. Enter the addresses of your Checkmk servers as the permitted IP addresses. It may also be useful to provide a Checkmk test site here. Important: If you have multiple redundant Checkmk servers, do not forget to also specify the IP address(es) used after a failover. In the case of the Checkmk appliance in particular, this uses the IP address of the active node as the source IP address for outgoing connections — and not the service IP address. In a distributed environment the IP address of the remote site from which the device is monitored is critical.

  4. Assign a Community if protocol versions v1 and v2c are to be used.

The Community is a kind of password, except that there is no user name for SNMP. There is a convention that the community is public. This is the default for many devices — and also for Checkmk. Of course you can argue that this is insecure and that you should specify another community. This certainly makes sense, but you should know that SNMP transmits the community in plain text (except for SNMP Version 3).Anyone who can listen to packets can therefore very easily identify the community. On the other hand you have limited access to read-only access, and most of the information that can be retrieved via SNMP is not very critical.

Furthermore, the use of different communities per device is very cumbersome to handle. After all, these must not only be maintained in the devices, but also in the monitoring system. That is why in practice users usually use the same community everywhere — or at least everywhere within a region, department, computer center, etc.

Tip: If you want to increase the security even without SNMP version 3, it makes sense to extend the network concept so that you put the traffic with the management services, and thus also SNMP, in a separate management VLAN and secure that access with the firewall.

2.2. Adding a device into Checkmk

Add the monitored devices as hosts in Checkmk in the usual way. If you have chosen your folder structure so that only one folder contains SNMP devices, you can make the other settings directly in that folder. This makes it easier to add additional hosts later, and also avoids errors.

Adding a host to monitoring via SNMP.

Now in the properties of the host (or folder), in the Monitoring agents box set Checkmk agent / API integrations to No API integrations, no Checkmk agent.

In the same box, also activate SNMP and as the SNMP protocol select SNMP v2 or v3. The selection of protocol version 1 is an makeshift solution only for very old devices. You should use this only if you know that v2 is really not supported, or when the implementation for the device is defective (in practice, only in isolated cases). Above all, SNMP version 1 is very slow because it does not support bulk accesses. This difference is very significant.

The third and final setting is called SNMP credentials. Here again a choice of the protocol version is necessary, since v2c and v3 differ here. We will discuss version 3 below. If you do not have very high security requirements, you will be well-served by v2c — or you can place the SNMP communication in a management VLAN and thus secure it. SNMP v2c requires the entry of the Community as discussed above.

There is an alternative way to configure the SNMP credentials, if you can not easily pass it through your folder structure: the Setup > Agents > SNMP rules > SNMP credentials of monitored hosts rule set. This will allow you to assign the credentials based on host tags, labels and similar properties. The principle is that a community that is set directly at the host or folder always takes precedence over the rules.

Monitoring via SNMP and Checkmk agent

Occasionally the question comes up whether it would not be possible or even useful to monitor Linux or Windows using SNMP instead of the Checkmk agent. The answer is very simple: possible yes, useful no. Why?

  • The monitoring data of the SNMP agent is very limited. Therefore you need the Checkmk agent for halfway useful monitoring anyway.

  • The SNMP agent does not provide any meaningful data that the Checkmk agent would not provide.

  • The SNMP agent is more cumbersome to set up.

  • Last but not least, the SNMP protocol requires significantly more CPU and network resources than normal monitoring with Checkmk.

However, there are a few situations where monitoring via SNMP in addition to the Checkmk agent can be useful. This can then involve both the Checkmk agent for Linux and for Windows. A typical example is that for a software or hardware component (for example, a RAID controller) a tool from the server manufacturer is installed and provides monitoring data only via SNMP, as is the case with Fujitsu ServerView, for example. Then you can of course collect additional monitoring data via SNMP. In this case, make sure that the query intervals are sufficiently long. With Windows it can also happen that a query via PowerShell is not possible — due to the Windows version used or because there are no cmdlets for the application.

In such a case, if you want to monitor the Linux or Windows host via Checkmk agent and SNMP, do the following: In the host’s properties, in the Setup menu, in the Monitoring agents box, set the Checkmk agent / API integrations option to a value with Checkmk agent (API integrations if configured, else Checkmk agent or Configured API integrations and Checkmk agent). In the same box, enable the SNMP option and set the value to SNMP v2 or v3 or SNMP v1, as described above:

Include a host in monitoring via Checkmk agent and SNMP.

Services that are available via both SNMP and Checkmk agent (e.g. CPU usage, file systems, network cards) are then automatically fetched from the Checkmk agent and not via SNMP.

2.3. Diagnostics

When you have finished with the settings, you can make a short detour via the diagnostics page. To do this save with the Save & go to connection test action bar button. Here is an example of the diagnostics for a switch. Various protocol versions of SNMP are tried simultaneously, namely:

  • SNMP v1

  • SNMP v2c

  • SNMP v2c without Bulk Queries

  • SNMP v3

A normal, modern device should respond to all four variants with the same data — however this may be limited depending on the configuration. The result will look like this:

Output of SNMP v2c diagnostics.

The four information outputs are described here:

sysDescr

The description of the device as it is hard-coded in the device firmware by the manufacturer. This text is very important to Checkmk for automatic service discovery.

sysContact

This field is for specifying a contact person and is defined by you in the device configuration.

sysName

Here is the host name of the device. This field is also configured on the device. For the actual monitoring the name plays no further role and is only displayed for information. However, it makes sense and is helpful if the host name here matches the host name in Checkmk.

sysLocation

This is a field for a free text entry — purely for information — in which you can enter the location of the device.

2.4. The service configuration

Special features of SNMP devices

After saving the host properties (and optionally the diagnostics), the next step is usually the configuration of services. There are some peculiarities with this, because internally the service discovery is done very differently in SNMP devices compared to hosts, which are monitored with the Checkmk agent. Checkmk can simply look at the agent’s output and find the items of interest using the individual check plug-ins. With SNMP a little more work is necessary. Although Checkmk could perform a detection and generate a full output of all SNMP data (SNMP walk), and in this look for interesting information, but there are devices for which a single detection would take several hours!

However Checkmk has a smarter approach. Initially, it only retrieves the very first two records (OIDs) from the device — the sysDescr and sysObjectID. Thereafter, as needed, further queries are invoked. Based on the results, each of the nearly 1 000 supplied SNMP check plug-ins decides whether the device actually supports this plug-in. Checkmk calls this phase the SNMP scan, and as a result the software produces a list of check plug-ins that serve as candidates for the actual service discovery.

In a second step the actual detection runs. The plug-ins found retrieve the exact data they need using local SNMP queries, and use this data to determine the services to be monitored. The data retrieved are precisely those which will later be fetched regularly for monitoring.

For devices in a LAN the whole process usually does not take very long — more than several seconds would be an exception. If you monitor devices over high-latency WAN links however, the entire scan may take several minutes. A scan also takes longer for switches with hundreds of ports of course. Now it would be very impractical if you had to wait so long every time you open the services’ page.

Therefore the Setup normally skips the scan, and does the detection only with the check plug-ins already in use at the host. The SNMP walks are then already available as cache files through the normal monitoring, and detection does not take long. With this you will be able to find new items from existing plug-ins (for example, new switch ports, hard disks, sensors, VPNs, etc.), but not find brand new plug-ins.

The Full service scan button forces an SNMP scan and fetches fresh data via SNMP. As a result services from completely new plug-ins are also found. It may be necessary to wait for slow-responding devices.

Standard services

No matter which device you monitor via SNMP — as a minimum the following three services should appear in the configuration:

Display of the three standard services that every SNMP device should have.

The first service is a check that monitors the network ports. At least one must have the device and be active — otherwise SNMP would not function. In general Checkmk is preset so that it includes all ports that are active at the time of a service discovery (operational status ‘up’) in the monitoring. You can influence this with the Setup > Services > Service discovery rules > Network interface and switch port discovery rule set.

By the way, in the Beginner’s guide you will find a chapter on best practices when configuring switch ports.

The second is the SNMP Info service which displays the same four pieces of information that you saw in the diagnosis. This has a purely informal function and is always OK.

Finally there is the Uptime service, which shows you when the device was last restarted. This service is always OK by default, but you can set upper and lower thresholds for the uptime.

3. When devices create problems

3.1. A defective SNMP implementation

It actually seems as if any conceivable mistake that can theoretically be made when implementing SNMP has already been made by some manufacturer at some point. And so there are devices with which SNMP works reasonably well, but certain parts of the protocol do not, or have been incorrectly implemented.

If the problems occur with the commercial editions, one reason may be that the more performant inline SNMP implementation, which is activated there by default, relies more heavily on compliance with standards than snmpget. If devices do not respond at all or not reliably, it sometimes helps to switch off inline SNMP for affected devices and thus activate the somewhat more robust and significantly slower snmpget.

For tests on the command line, the command cmk has for some options the additional --snmp-backend option, which accepts inline (use of inline SNMP), classic (use of snmpget) or stored-walk (use of a stored SNMP walk) as parameters. If the test on the command line was successful, you can use the Hosts not using Inline-SNMP rule set to specify the hosts that should not use inline SNMP permanently.

No response for a request to 'sysDescr'

One possible error is when SNMP agents fail to respond to the request for standard information — no reply to the sysDescr for example. These devices are as good as dead in a diagnosis, and they will not deliver any results to a service discovery if you don’t help them with a special configuration. To do this, for affected hosts create a rule under Setup > Agents > SNMP rules > Hosts without system description OID with the Positive match (Add matching hosts to the set) option. Checkmk then simply assumes that everything is fine and skip the test with the sysDescr. Although no check plug-ins will be detected that expect specific parts in this text, in practice this does not matter as the affected plug-ins are designed to accommodate such a condition.

SNMP v2c works, but bulk requests fail

Some devices support version v2c — and will provide an answer to this in the diagnostics — however, the implementation of the GetBulk command is missing in the protocol. This is used by Checkmk to get as much information as possible with a single request and is very important for the performance.

With such a host, some simple SNMP checks will work — such as SNMP Info or SNMP Uptime, but other services will be missing — especially the network interfaces that must be present on each device.

If you actually have a host where this is the case, you can run it with v2c, but without bulk requests. Configure such a host as follows:

  1. Set the SNMP version for the host properties to SNMP v1.

  2. In the Setup > Agents > SNMP rules > Legacy SNMP devices using SNMP v2c rule set, create a rule for the host, and set the value typically to Positive match (Add matching hosts to the set).

This forces the host to use the SNMP v2c protocol — although version 1 has been set — however without bulkwalk. Incidentally, we do not recommend the use of SNMP v1 — even if that is supported — because it does not support 64-bit counters. This can lead to missing or erroneous measurement data for network ports which are subject to heavy traffic.

Devices which respond very slowly

There are some devices with which some SNMP queries take a very long time. This is partly due to incorrect implementations. Here it can sometimes help to go back to SNMP v1 — which is usually much slower, but can still sometimes be faster than a broken SNMP v2c. Before you try this however, you should check whether the manufacturer provides a firmware upgrade that solves the problem.

A second cause may be that the device has very many switch ports, and also a slow SNMP implementation. If you only want to monitor very few of the ports (only the first two ports, for example), you can manually limit Checkmk to polling only specified ports. Details on this can be found below in Performance.

3.2. Only the standard services are found

You have included an SNMP device in the monitoring but Checkmk recognizes only the SNMP Info and SNMP Uptime services and the interfaces. This can be due to a number of causes:

a) There are no plug-ins

Checkmk provides nearly 1 000 check plug-ins for SNMP devices, but even this list is naturally never complete. Over and over again it is found that for certain devices Checkmk does not provide any specific plug-in, meaning you can only monitor the standard services as mentioned. Here you have the following options:

  • You might find a suitable plug-in on the Checkmk Exchange, where users can upload their own plug-ins.

  • You develop plug-ins yourself. You will find articles in this User guide.

  • You contact our support team or one of our partners and request that they develop suitable plug-ins.

b) The plug-ins cannot be recognized

It sometimes occurs that a new firmware version for a device results in Checkmk plug-ins no longer recognizing the device — e.g. because a text has changed in the system description for the device. In such a case the existing plug-ins must be adapted. Contact our support team for this.

c) The device does not deliver the required data

Some (few) devices have the ability to individually-configure access to specific information areas in their SNMP configuration. Your device may be set to deliver the default information, but not that for the device-specific services.

On a few devices you must use SNMP v3 and Contexts to get the data you want.

3.3. Devices that do not respond at all to SNMP

If the ping works, but none of the SNMP protocol versions work, there can be several possible causes:

  • The device is not reachable via IP at all. You can check this with the Ping Test (first box).

  • The device does not support SNMP at all.

  • The SNMP share is not configured correctly (activation, allowed addresses, Community).

  • A firewall blocks SNMP. You need to open UDP port 161 for both outgoing and incoming traffic.

4. SNMP v3

4.1. Security

By default SNMP is unencrypted and is therefore very poorly-authenticated by a Community transmitted as plain-text over the network. This level may still be sufficient for a local, isolated network, as here monitoring is limited to accessing read-only operations.

If you still want a higher level of security you will need SNMP version 3. This provides the option of encryption and genuine authentication. For this however a corresponding configuration is also necessary.

SNMP v3 recognizes various levels of security:

noAuthNoPriv

No real, user-based authentication, no encryption. Nonetheless, the advantage over v2c is that the password is no longer transmitted in plain text, instead it is hashed.

authNoPriv

User-based authentication with a name (Security name) and a password, but no encryption.

authPriv

User-based authentication as with authNoPriv, and additionally all data is encrypted. Here you have to manually exchange a Key — that is, deposit the Key both in the device and in Checkmk.

The required setting in Checkmk is made in the same place where you also defined the Community — either under the host properties or the SNMP credentials of monitored hosts rule. There, instead of SNMP Community, select one of the three levels of v3 and configure the necessary values:

Configuring SNMP v3 security settings.

4.2. Contexts

SNMP v3 introduces the concept of Contexts. A device can show different information at one and the same point in the SNMP tree — depending on which Context ID is given in the query.

If you have a device that works with such contexts, you will need two settings in Checkmk:

  • First, the device must be queried using SNMP v3 (as described in the previous section).

  • Then you need another rule in the SNMPv3 contexts to use in requests rule set. Here you select the check plug-in for which contexts are to be activated, and then the list of contexts that should be queried in the monitoring.

Luckily there are very few situations in which you have to work with contexts, because unfortunately it is not possible for the monitoring to recognize them automatically. A manual configuration of the contexts is always necessary.

5. Performance and timing

5.1. Inline-SNMP

Performance always plays a role — especially in environments with many hosts — and monitoring with SNMP consumes more CPU and memory than with Checkmk agents.

CEE While Checkmk Raw makes SNMP requests in the classic way via the snmpget or snmpbulkwalk commands, the commercial editions have a built-in SNMP engine that performs SNMP requests very efficiently without generating any extra processes. With this, CPU load for SNMP processing is approximately halved. The shorter polling times also reduce the number of Checkmk processes needed concurrently, and thus the memory usage.

5.2. Check intervals for SNMP checks

If your resources reach their limits, or if it takes more than 60 seconds to poll a single device, you can reduce the interval at which Checkmk queries the host(s). With the Normal check interval for service checks rule set, which you apply specifically to the Checkmk-Services of hosts, you can extend the general interval of one minute to, for example, 2 or 5 minutes.

Especially for SNMP checks, there is also the Check intervals for SNMP checks rule set. This allows you to lower the interval for individual check plug-ins. It is important to know that you can never set the interval to faster than the interval for general monitoring by the Checkmk service.

Overall, however, we recommend that the monitoring be designed so that the standard interval of one minute can be maintained, and only increased in exceptional cases for individual hosts or checks.

5.3. Timing settings for SNMP access

By default Checkmk expects a response in less than one-second for an SNMP request. It also tries a total of three times before giving up. For devices that respond very slowly, or that can only be reached over a very slow network, it may be necessary to change these parameters. You do this through the Timing settings for SNMP access rule set:

Increasing the response timeout.

Please note that these settings apply to an individual SNMP request. The complete process of monitoring a host consists of many separate requests. The total timeout is therefore a multiple of the settings specified here.

5.4. Bulkwalk: Number of OIDs per bulk

By default SNMP transmits 10 responses in one packet per GetBulk request. Try the Bulk walk: Number of OIDs per bulk experimental rule set to see if a higher value performs better. However this will only be the case when large tables are transferred to the host — e.g., if it is a switch with many ports.

SNMP always fills the packets up to the specified number, including any records following the actual required ones. And if only a few of these records are really needed, extra data is transferred uselessly and the overhead increases.

On the other hand, in practice it may occasionally occur that devices with the default value of 10 OIDs per bulk packet can have problems. In such a case it can be useful to reduce the number.

5.5. Limiting SNMP OID ranges

Checkmk normally works by always getting the information on all switch ports, even though not all are actually being monitored. This is a good thing anyway, since this is normally faster because single queries cannot be done with the efficient bulk queries. In addition, from our point of view, it is always advisable to monitor all ports in order to find faulty ports or cables with high error rates. If ports are not reliably UP, you can also flag the link status DOWN as being OK.

However, there are isolated cases where switches have very many ports, and which for some reason respond very slowly, or process SNMP very inefficiently, so that it is no longer possible to monitor with complete retrieval of all port information.

For such cases, there is the Bulk walk: Limit SNMP OID Ranges rule set. This allows you to statically limit the list of queried data (e.g., ports). In the rule’s value, for each particular check plug-in you specify which indexes of the respective table are to be fetched.

The usual check type for switch ports is called SNMP interface check with 64 bit counters (using v2c). The following example shows a setting in which only the first two ports are fetched via SNMP:

Bulkwalk: limit SNMP OID ranges.

Note: This filtering is then in effect before the service discovery and monitoring. Depending on the Network interface and switch port discovery setting, this does not automatically mean that these two ports will actually be monitored.

6. Simulation through SNMP walks

6.1. Principle

The Checkmk SNMP engine has a very handy feature — you can have a monitored device write a complete snapshot of all its SNMP data to a file, an SNMP walk. You can use this file later to simulate monitoring the device on another Checkmk server, even if this other server has no actual network connection to the device.

We use this feature very intensively, for example, when our support team is developing new check plug-ins for our customers. Our developers therefore do not need access to your devices — just an SNMP walk.

6.2. Creating a walk via the GUI

You can create an SNMP walk directly from the GUI. The function can be found in the context menu of the Checkmk service of the hosts and also in the menu of the hosts (entry icon agent output Download SNMP walk):

Download SNMP walk in the context menu for the host in the monitoring overview.

The creation of the walk takes a few seconds in the best case, but a few minutes are not uncommon. When the build is done you can download the created file via the Result line.

6.3. Creating a walk from the command line

Alternatively, you can also create walks from the command line. Log on to the site from which the device is being monitored. The creation of the walk is simply done with the cmk --snmpwalk command and the specified host (which must be configured in monitoring):

OMD[mysite]:~$ cmk --snmpwalk switch23

Also use the -v switch to see more detailed output on the progress:

OMD[mysite]:~$ cmk -v --snmpwalk switch23
switch23:
Walk on ".1.3.6.1.2.1"...3664 variables.
Walk on ".1.3.6.1.4.1"...5791 variables.
Wrote fetched data to /omd/sites/mysite/var/check_mk/snmpwalks/switch23.

The file will be placed in the var/check_mk/snmpwalks directory, where it simply carries the name of the host. It is a text file. If you are curious you can view this — e.g., with less — and quit the program with the Q key:

OMD[mysite]:~$ less var/check_mk/snmpwalks/switch23
.1.3.6.1.2.1.1.1.0 Yoyodyne Frobolator 23 port L2 Managed Switch
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.11863.1.1.3
.1.3.6.1.2.1.1.3.0 560840147
.1.3.6.1.2.1.1.4.0 Zoe Zhang 
.1.3.6.1.2.1.1.5.0 cmkswitch23
.1.3.6.1.2.1.1.6.0 Data Center 42
.1.3.6.1.2.1.1.7.0 3
.1.3.6.1.2.1.2.1.0 27

The command cmk --snmpwalk has some more useful options:

Option Effect

--extraoid <OID>

When Checkmk performs a walk on a host, it generally retrieves two subtrees from the SNMP data area. These are specified in the SNMP tree using so-called OIDs (object identifiers). These are MIB-2 and enterprises — that is, on the one hand a standard area that is normalized and the same for all SNMP devices, and on the other hand a manufacturer-specific area. If SNMP is implemented correctly, this should cause the device to send all data that it provides. If this is not the case and you are looking for a specific range, you can add its OID to the walk with this option, e.g. cmk --snmpwalk --extraoid .1.2.3.4 switch23. Don’t forget the ‘period’ at the beginning of the OID.

--oid

This option is similar to --extraoid, but only retrieves the specified OID. This is of interest for testing purposes. Note, however, that the walk will be incomplete.

-v

The v stands for verbose and will output some interesting information during the walk.

-vv

The vv stands for very verbose and outputs much more information.

6.4. Using saved walks for simulations

If you want to use this walk on a different (or the same) Checkmk site for a simulation, then save the walk file with the name of the host on this site under var/check_mk/snmpwalks. Make sure that the site user is owner of the file and permissions are set to 0600 (only the owner is allowed to read and write).

Now create a rule in the Simulating SNMP by using a stored SNMP walk rule set that accesses the affected host(s).

From now on, only the saved file will be used to monitor the host. There is now no network access to the host — except the ping for the host check, and possibly any configured active checks. You can simply redirect these to the Checkmk server by giving the IP address 127.0.0.1 to the hosts.

7. Files and directories

File path Description

var/check_mk/snmpwalks

Here SNMP walk files are generated or also expected if you want to use them to simulate SNMP data.

On this page