Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Sensors Overview

Paragon Insights accepts data from Juniper, third-party devices, and from various types of telemetry sensors including traditional network management protocols like system log and SNMP. Paragon Insights supports push and pull models of data collection. In the push model, your devices push telemetry data to Paragon Insights through trap notifications, for instance. In the pull mode, Paragon Insights periodically polls your devices for data. This guide describes each of the supported ingest methods, with examples, sorted by whether they fall into the push or pull model. Along with each description, we provide the required Junos OS version and device configurations needed to enable the specific ingest type.

As the number of objects in the network, and the metrics they generate, have grown, gathering operational statistics for monitoring the health of a network has become an ever-increasing challenge. Traditional ’pull’ data-gathering models, like SNMP and the CLI, require additional processing to periodically poll the network element, and can directly limit scaling.

The ’push’ model overcomes these limits by delivering data asynchronously, which eliminates polling. With this model, the Paragon Insights server can make a single request to a network device to stream periodic updates. As a result, the ’push’ model is highly scalable and can support the monitoring of thousands of objects in a network. Junos devices support this model in the form of the Junos Telemetry Interface (JTI).

Paragon Insights currently supports five push-model sensors:

While the ’push’ model is the preferred approach for its efficiency and scalability, there are still cases where the ’pull’ data collection model is appropriate. Two examples might be when a device doesn’t support the Junos Telemetry Interface (JTI), or when managing third party devices. With the pull model, Paragon Insights requests data from network devices at periodic, user-defined intervals.

Paragon Insights currently supports the following pull-model sensors:

Native GPB

Native sensors use a Juniper-proprietary data model using Google Protocol Buffers (GPB). The device pushes telemetry data (when configured) over UDP.

The device pushes data from the Packet Forwarding Engine, that is, directly from a line card. This means telemetry data is sent over the forwarding plane, so the collector must have in-band connectivity to the device.

To use native format, you configure the device with settings that include where to send the telemetry data. When you configure Paragon Insights to start collecting the data, the stream is already flowing towards the server.

For more information on native sensors, see Understanding the Junos Telemetry Interface Export Format of Collected Data.

NetFlow

Paragon Insights supports NetFlow v9 and NetFlow v10 (IPFIX) natively as NetFlow ingest method, using a data model that aligns with other Paragon Insights ingest mechanisms. NetFlow is a network protocol for collecting IP traffic statistics, which can then be exported to a tool for analysis. The NetFlow v9 data export format is described in RFC 3954; NetFlow v10 is officially known as IPFIX and standardized in RFC 7011.

Junos devices support flow monitoring and aggregation using these protocols; the Junos OS samples the traffic, builds a flow table, and sends the details of the flow table over a configured UDP port to a collector, in this case Paragon Insights. Paragon Insights receives the incoming Netflow data, auto-detects it as v9 or v10, and process it further.

As shown above, the network device pushes data from the Packet Forwarding Engine, that is, directly from a line card. This means flow data is sent over the forwarding plane, so the collector must have in-band connectivity to the device. To use the flow sensor option, you configure the device with settings that include where to send the flow data. When you configure Paragon Insights to start collecting the data, the flow data is already flowing towards the server.

Paragon Insights uses flow templates as a mechanism to identify and decode incoming flow data before sending it for further processing. Paragon Insights provides predefined flow templates for NetFlow v9 and v10 (IPFIX), or you can define your own. The predefined templates match those which the Junos OS currently supports. For example, the Junos OS template, ipv4-template, aligns with the Paragon Insights template hb-ipfix-ipv4-template. To view the fields used in the Junos OS templates, see Understanding Inline Active Flow Monitoring.

Note:

In the current ingest implementation for NetFlow, the following field types are not supported:

  • Fields for enterprise specific elements

  • Variable length fields
Warning:

For NetFlow ingest, ensure that there is no source NAT in the network path(s) between the device and Paragon Insights. If the network path contains source NAT, then the received device information is not accurate.

A typical workflow includes adding a NetFlow configured device in Paragon Insights, configuring NetFlow templates, configuring a rule with Flow sensor, and deploying a playbook with the rule to a device group.

With the playbook applied, you can begin to monitor the devices.

  1. Click Monitoring > Network Health in the left navigation bar and click on the Device Group tab.

  2. Select the device group to which you applied the playbook from the Device Group pull-down menu.

  3. Select one of more of the devices to monitor.

  4. In the Tile View, the external tile contains the parameters from the rule you configured earlier.

sFlow

Paragon Insights supports sFlow (v5) natively as another flow-based ingest method.

sFlow is a statistical sampling-based technology for high-speed switched or routed networks. You can configure sFlow to continuously monitor traffic at wire speed on all interfaces simultaneously if you want.

sFlow provides or helps with:

  • Detailed and quantitative traffic measurements at gigabit speeds

  • Insight into forwarding decisions

  • Troubleshooting for network issues

  • Congestion control

  • Security and audit trail analysis

  • Route profiling

Everything that sFlow does above, it does without impact to forwarding or network performance. For more information on sFlow, see: RFC 3176, InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks.

As a statistical sampling protocol, Juniper’s sFlow agent samples the traffic and counters on network interfaces, creates sFlow datagrams, and forwards them to external sFlow collectors. Paragon Insights is one such collector.

To know how to configure sFlow packets in Paragon Insights, go to Configure sFlow Settings.

OpenConfig

To use OpenConfig format, you configure the device as a gRPC server. With Paragon Insights acting as the client, you define which sensors you want it to subscribe to, and it makes subscription requests towards the device.

Data streamed through gRPC is formatted in OpenConfig key/value pairs in protocol buffer (GPB) encoded messages. Keys are strings that correspond to the path of the system resources in the OpenConfig schema for the device being monitored; values correspond to integers or strings that identify the operational state of the system resource, such as interface counters. OpenConfig RPC messages can be transferred in bulk, such as providing multiple interface counters in one message, thereby increasing efficiency of the message transfer.

For more information on OpenConfig sensors, see Understanding OpenConfig and gRPC on Junos Telemetry Interface.

gNMI-Encoded OpenConfig RPC

gNMI-encoded OpenConfig works much like OpenConfig RPC in that you must set the network device up as an OpenConfig server to which Paragon Insights makes subscription requests. However, gNMI supports more subscription types than Paragon Insights currently supports. Currently, Paragon Insights only supports gNMI STREAM subscriptions in the SAMPLE mode. STREAM subscriptions are long-lived subscriptions that continue, indefinitely, to transmit updates relating to the set of paths configured within the subscription. SAMPLE mode STREAM subscriptions must include a sample_interval.

The messages returned to the client through gNMI are encoded by the device in protobuf, JSON, or JSON-IETF format and cannot be sent in bulk. This, in part, makes gNMI-encoded messaging less efficient than gRPC-encoded messaging.

Warning:

  • For JSON or JSON-IETF, it is assumed that the device returns gNMI updates as only leaf values encoded in JSON, rather than returning an entire hierarchy or sub-hierarchy as a JSON object.

  • Numbers encoded in JSON or JSON-IETF are decoded by Paragon Insights as either float64, int64, or string, according to RFC 7159 and RFC 7951. If your OpenConfig rules contain fields that are of a different type, we recommend that you change the field types accordingly.

Junos OS and Cisco devices can be managed by Paragon Automation using gNMI-encoded OpenConfig. If a device does not support gNMI in general, or the STREAM subscription in SAMPLE mode, or does not support an OpenConfig request, it returns one of the following errors:

  • Unimplemented

  • Unavailable

  • InvalidArgument

In the case of a Junos OS or Cisco device, the error causes the connection to fall back to OpenConfig RPC. In the case of a third-party device, the connection simply fails due to the error.

gNMI-encoded OpenConfig can be enabled at the device or device-group level. If enabled at the device-group level, then all devices added to the group use gNMI by default. If enabled (or not enabled) at the device level, then the device level setting takes precedence over the device-group level setting.

Note:

During the initial connection gNMI devices attempt to perform an initial sync with the client. The device sends a continuous stream of data until the device and the collector (Paragon Insights) are in sync. After initial sync, the device begins normal streaming operations based on the configured reporting rate. Because of the processing load this creates, Paragon Insights has this feature disabled by default. It can be enabled at the device-group or device level if needed.

For more information about gNMI, see: gRPC Network Management Interface (gNMI).

Device Configuration for OpenConfig

OpenConfig requires:

  • Junos OS Version: 16.1 or later

    • The OpenConfig sensor requires that the Junos device have the OpenConfig and network agent packages installed. These packages are built into Junos OS Releases 18.2X75, 18.3, and later. For releases between 16.1 and 18.2X75 or 18.2, you must install the OpenConfig and Network Agent packages.

      Before you install the Network Agent package:

      • Install Junos OS Release 16.1R3 or later.

      • Install the OpenConfig for Junos OS module. Using a Web browser, navigate to the All Junos Platforms software download URL on the Juniper Networks webpage: https://www.juniper.net/support/downloads/. From the Network Management tab, scroll down to select OpenConfig. Select the Software tab. Select the OpenConfig Package (Junos with upgraded FreeBSD). For more information, see Installing the OpenConfig Package.

      • Install Secure Sockets Layer (SSL) certificates of authentication on your Juniper Networks device.

        Note:

        Only server-based SSL authentication is supported. Client-based authentication is not supported.

      An example of a valid Network Agent package name is:

      network-agent-x86-32-16.1R4.12-C1.1.tgz

      Note:

      Each version of the Network Agent package is supported on a single release of Junos OS only. The Junos OS version supported is identified by the Junos OS release number included in the Network Agent package name.

      Use the 32-bit Network Agent package for both 32-bit and 64-bit versions of Junos OS or Junos OS Evolved.

      To download and install the Network Agent package:

      1. Navigate to the All Junos Platforms software download URL on the Juniper Networks webpage: https://www.juniper.net/support/downloads/.

      2. Select the name of the Junos OS platform for the software that you want to download.

      3. Select the release number (the number of the software version that you want to download) from the Release drop-down list to the right of the Download Software page.

      4. Select the Software tab.

      5. Navigate to the Tools section of the Software tab and select the Junos Network Agent package for the release.

      6. Log in to the Juniper Networks authentication system using the username (generally your e-mail address) and password supplied by a Juniper Networks representative.

      7. Download the software to a local host.

      8. Copy the software to Juniper Networks device or to your internal software distribution site.

      9. Install the new network-agent package on the device by issuing the request system software add package-name from the operational mode:

        For example:

        Note:

        The command uses the validate option by default. This option validates the software package against the current configuration as a prerequisite to adding the software package to ensure that the device reboots successfully. This is the default behavior when the software package being added is a different release.

      To verify whether you have the OpenConfig and the Network Agent packages installed, enter the following command:

      See Understanding OpenConfig and gRPC on Junos Telemetry Interface for more information.

    • Network agent is not supported on PPC platforms (MX104, MX80, and so on).

Device Configuration

Configure a device by entering the following command:

To configure OpenConfig port under device configuration in Paragon Automation GUI, see Editable Fields on the Edit Devices Page table in Edit Devices.

Syslog

In addition to the JTI-related options above, Paragon Insights also supports system logs as a data collection method, using a data model that aligns with other ingest mechanisms.

A device can push syslog messages (when configured) over UDP to the Paragon Insights server either out-of-band through the Routing Engine (RE) using the router’s management interface, or in-band through the Packet Forwarding Engine, that is, directly from a line card.

To use syslog format, you configure the device with settings that include where to send the syslog messages. When you configure Paragon Insights to start collecting the data, messages are already flowing towards the server.

For more information on syslog as used by Juniper devices, see Junos OS System Log Overview.

A syslog message consists of a header, structured data in key-value format within square brackets, and the log message. The header consists of the following information:

  • Log priority

  • Version number of Syslog protocol specification on header format.

    Currently, this number is 1.

  • Timestamp of when the message was generated in the format of "Mmm dd hh:mm:ss".

  • Hostname identifies the device that sent the syslog message.

  • Application name

  • Application process ID

  • Message ID

Requirements to configure Syslog in Paragon Insights

Syslog ingest requires some setup before you can use it as a sensor in a rule:

  • Pattern - A pattern identifies some syslog event; you create a pattern for each event you want to monitor. You can configure patterns for both structured and unstructured events.

  • Pattern set - With the patterns configured, you then group them into a pattern set, which you then reference when defining the syslog sensor settings within a rule.

Before you configure Patterns and Pattern Set for Syslog ingest, note that the following fields are common in syslog messages. Paragon Insights extracts these fields and includes them automatically in the raw table, enabling you to make use of them directly when creating a rule, and avoiding the need to configure patterns.

To illustrate use of these values, consider the following example syslog messages:

Structured - <30>1 2019-11-22T03:17:53.605-08:00 R1 mib2d 28633 SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

Equivalent unstructured - <30>Nov 22 03:17:53 R1 mib2d[28633]: SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

System-generated fields:

  • "__log_priority__" - Priority of syslog message

    • In the examples, <30> denotes the priority

  • “__log_timestamp__" - Timestamp in epcoh in the syslog message

    • In the structured example, 2019-11-22T03:17:53.605-08:00 is converted to epoch with -08:00 indicating the time zone

    • In the unstructured example, the time zone from the configuration will be used to calculate epoch

  • "__log_host__" - Host name in the syslog message

    • In the examples, R1 denotes the host name

  • "__log_application_name__” - Application name in the syslog message

    • In the examples, mib2d is the application name

  • "__log_application_process_id__” - Application process ID in the syslog message

    • In the examples, 28633 is the ID

  • "__log_message_payload__" - Payload in the message

    • Structured example - “SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

    • Unstructured example - “SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

  • "Event-id" - Denotes the event ID configured in the pattern

    • In the examples, SNMP_TRAP_LINK_DOWN is the event ID

Note:

Be sure not to define any new fields using a name already defined above.

To know how to configure Syslog ingest, see Configure System Log Ingest.

Server Monitoring Sensor

In Paragon Automation, the Server Monitoring sensor collects data from servers and virtual machines on which you host the Paragon application. The sensor uses the third-party plug-in, Node Exporter. The Node Exporter plug-in is pre-installed in all server clusters of Paragon Automation. In the GUI, the default servers and virtual machines deployed in the Paragon Automation cluster are represented as devices that are automatically added to the Paragon-Cluster device group. The sensor collects data from servers and virtual machines to track CPU, memory, network, traffic, disk, and filesystem metrics. It writes the output to a time series database.

Note:

Users must not delete the default Paragon-Cluster device group.

Paragon Automation has the following pre-configured playbooks to monitor server data.

  • CPU utilization
  • Disk reads and writes
  • Errors, available bytes, and utilized bytes in filesystem
  • Utilized bytes and available bytes in memory
  • Received and transmitted total packet size, errors in received and transmitted packets, total received and transmitted multicast packets in network

When you configure a rule using Server Monitoring ingest, you can use the some of the sensor paths listed in Table 1.

Table 1: Server Metrics
Sensor Path Description
/node/boot/time/seconds Boot time in each server node.
/node/cpu/seconds/total The total time (in seconds) the CPU stays in idle, system, user, and nice modes.
/node/disk/read/bytes/total The total number of bytes read successfully.
/node/disk/read/errors/total The total number of read errors in a node.
/node/disk/read/retries/total The number of times the ingest tries to read from the disk if there is a failure.
/node/disk/read/sectors/total The total number of sectors read successfully.
/node/disk/read/time/seconds/total The total time taken to complete reads successfully per node.
/node/disk/reads/completed/total The total number of reads completed successfully.
/node/disk/write/errors/total The total number of errors in writes
/node/disk/write/retries/total The number of times the ingest tries to write on the disk if there is a failure.
/node/disk/write/time/seconds/total The total time taken to complete all writes.
/node/disk/writes/completed/total The total number of writes completed per node.
/node/disk/written/bytes/total The total number of bytes written successfully.
/node/disk/written/sectors/total The total number of sectors written successfully.
/node/exporter/build/info A metric that has the value '1' and has version, revision, go version, and branch from which node exporter is built.
/node/filesystem/avail/bytes The filesystem size available to non-root users.
/node/filesystem/device/error The number of I/O errors that occur when collecting data from a filesystem.
/node/filesystem/files The total number of index nodes permitted in a node.
/node/filesystem/files/free The number of index nodes that are free for use in a node.
/node/filesystem/free/bytes The free space (in bytes) available for the user, excluding reserved blocks.
/node/filesystem/readonly Data that shows if the filesystem in a node is mounted as read-only.
/node/filesystem/size/bytes The size of all files in bytes.
/node/load1 Load on each server/host node captured every 1 minute.
/node/load15 Load on each server/host node captured every 15 minutes.
/node/load5 Load on each server/host node captured every 5 minutes.
/node/memory/active/bytes Memory bytes that are actively used by processes.
/node/memory/compressed/bytes Total size of compressed memory.
/node/memory/free/bytes Total memory in bytes that is free for use in a node.
/node/memory/inactive/bytes Memory bytes that are not actively used by processes.
/node/memory/swap/total/bytes Total memory swapped in a node.
/node/memory/swap/used/bytes The amount of swapped memory used in a node.
/node/memory/swapped/in/bytes/total Total swapped in memory in a node.
/node/memory/swapped/out/bytes/total Total swapped out memory in a node.
/node/memory/total/bytes Total bytes of memory in a node.
/node/memory/wired/bytes Memory that cannot be swapped out.
/node/network/receive/bytes/total Total size of packets received by a device.
/node/network/receive/errs/total Total number of errors encountered by a device when receiving packets.
/node/network/receive/multicast/total Total number of multicast packets received by a device.
/node/network/receive/packets/total Total number of packets received by a device.
/node/network/transmit/bytes/total Total size of packets sent from a device.
/node/network/transmit/errs/total Total number of errors encountered a device when transmitting packets.
/node/network/transmit/multicast/total Total number of multicast packets transmitted by a device.
/node/network/transmit/packets/total Total number of packets transmitted by a device.
/node/scrape/collector/duration/seconds Time taken by each collector to scrape metrics.
/node/scrape/collector/success Number of times Node Exporter collector successfully scraped targets.
/node/textfile/scrape/error Errors encountered by Node Exporter when scraping targets using textfile scripts.
/node/time/seconds Displays system time in seconds in the node since epoch (1970).
/node/uname/info Name of the node from which Node Exporter collects metrics.

The following tags such as mode, device etc. can be used as key fields applicable to all metrics listed under main metrics (/node/cpu or /node/network).

When you configure a key field in a rule, you can mention only the key field name in the Path field.

  • /node/cpu/
    • cpu: The number of cores available in CPU.
    • mode: The type of CPU usage in a node such as idle, system, user, and nice.
  • /node/disk/
    • device: Name of disks such as disk0, disk1, sda, sdb, or sdc.
  • /node/filesystem/
    • device: Disk paths such as /dev/sda1, /dev/sda2, and /dev/sdb1
    • fstype: Type of partition formatting such as ext4, NTFS (New Technology File System), and APFS (Apple File System).
    • mountpoint: Mount paths in the device.
  • /node/network/
    • device: Interface names of the device such as wlan0, en0, or docker0.

To configure an example rule using Server Monitoring ingest, see Configure a Rule Using Server Monitoring Sensor

iAgent (CLI/NETCONF)

For all the benefits of the ’push’ data collection methods, some operational and state information is available only through CLI/VTY commands. iAgent fills this gap by taking advantage of NETCONF/SSH functionality to provide Paragon Automation with the ability to connect to a device, run commands, and capture the output.

iAgent sensors use NETCONF/SSH and YAML-based PyEZ tables and views to fetch the necessary data. Both structured (XML) and unstructured (VTY commands and CLI output) data is supported.

With iAgent, the Paragon Automation server initiates inbound SSH requests over any available network interface, whether in-band or out-of band; and the device responds (when properly configured) with the requested data.

In Paragon Automation Platform, the iAgent ingest is extended to other vendor devices from Arista Networks, Palo Alto Networks, and Cisco.

You must configure a Junos device to send telemetry data using iAgent sensor or a NETCONF connection.

At minimum, iAgent (NETCONF) requires:

  • Junos OS Version: 11.4 or later

  • Minimum required device configuration:

To configure iAgent or NETCONF port for inbound connection in Paragon Automation GUI, see Table 1.

Paragon Automation uses Netmiko to make inbound SSH connections over the selected port to a third-party device. To gather device information, Paragon Automation sends CLI commands over SSH and receives string blobs back as output. The string blobs are then parsed through TextFSM, using NTC templates into JSON format and then stored in the database. Default templates are located at /srv/salt/_textfsm. You can visit the GitHub repository of NTC Templates for network devices.

For advanced users who need a template which does not exist, you can create your own templates and upload them to Paragon Insights using the Upload Rule Files button on the Configuration > Rules page. User defined templates are stored at /jfit/_textfsm. The files must end with the .textfsm suffix. To know how to upload pre-defined rules in Paragon Automation Platform, see Add a Predefined Rule.

TextFSM is integrated into PyEZ’s table/view feature which is an integral part of iAgent.

Example: PaloAlto Panos– Show Running Security Policy

To see the running security policy on a Panos device, we need to:

Define PyEZ Table/View

We need to define a PyEZ table that is used by the iAgent rule assigned to the Panos device. The following table definition lacks a view definition. Because of this, the entire output from the show running security-policy ends up getting stored in the database after processing.

(Optional) To store only a portion of the received data in Paragon Automation, you can define a view in the same file. The view tells Paragon Automation which fields to pay attention to.

Gather Output from Device

Using an iAgent rule that references the PyEZ table (or table/view) defined above, Paragon Automation sends the command show running security-policy to the device which produces the following output:

Generate JSON for Use in Paragon Automation Database

Since the device configuration specifies Palo Alto Networks as the vendor and Panos OS as the operating system, the TextFSM template used for this example would look like this:

When the template above is used by Paragon Automation to parse the output shown previously, the resulting JSON looks like:

Outbound SSH (Device-Initiated)

Paragon Automation also supports iAgent (NETCONF) connections that are device-initiated using outbound SSH. This configuration makes Paragon Automation act as the client to the device making the connection. This type of connection is useful in environments in which the remote devices cannot accept incoming connections. All existing iAgent rules can be used when outbound SSH is configured in Junos devices.

Note:

NETCONF over SSH connections are supported only in Junos devices.

Outbound SSH is disabled by default. You can configure an outbound SSH connection:

  • In the ingest by configuring a single port. This port is used by all device groups.

  • In device-groups by configuring its ports. This configuration takes precedence over the ingest configuration.

When you configure outbound SSH in device-groups, you must enter a TCP port number over which all the member devices initiate their NETCONF connections to Paragon Automation. You can disable outbound SSH in a device through management CLI. To configure outbound SSH ports in device groups, see ports section of the device group configuration in Add a Device Group.

Paragon Automation supports a single TCP port for iAgent (NETCONF) outbound SSH connections from all device groups. This port can be configured at the ingest level. You can avoid opening multiple TCP ports in different device groups and simplify network management with a single port. To configure iAgent port at the ingest, see Configure Outbound SSH Port for iAgent.

You can connect a device that is managed in different device groups through outbound SSH by configuring multiple clients, where each client has the same port. In this case, you must create as many copies of the device as there are device groups. Each device must have the same port number.

As an example, consider device r0 (10.1.1.1) configured for device groups dg1 and dg2. To connect 10.1.1.1 to both device groups via the same outbound SSH port, you can create one more device r1 (10.1.1.1) with the same IP and deploy it in dg2.

You must also configure Paragon Automation for these ports in the respective device-groups. Figure 1 is an example device group configuration.

Figure 1: Edit Device Group Configuration Edit Device Group Configuration

Using the following sample client configurations, device 10.1.1.1 can connect to two device groups using two outbound SSH clients with the same port.

Note:

The 10.1.1.1 in the example denotes Paragon Automation (host) IP address.

SNMP

SNMP is a widely known and accepted network management protocol that many network device manufacturers, including Juniper Networks, provide for use with their devices. It is a polling type protocol where network devices that are configured to use SNMP make configuration, diagnostic, and event information available to collectors, which must also be properly configured and authenticated. The collectors poll devices by sending specifically structured requests, called get requests, to retrieve data.

Paragon Automation supports SNMP as a sensor type, using standard get requests to gather statistics from the device. Paragon Automation makes requests over any available interface, whether in-band or out-of-band, and the device responds (when configured) with the requested data.

For information about SNMP as used on Junos OS devices, see Understanding SNMP Implementation in Junos OS.

Paragon Insights also supports scalar object instances along with tabular objects in SNMP.

  • The SNMP object can be scalar, tabular, or a combination of both in rules. When you create a rule using SNMP ingest, you can add:

    • Only scalar fields.

    • A combination of tabular and scalar fields.

    • A tabular column along with the index queried as a scalar object.

      A tabular column queried as a scalar comes with the limitation that the index number does not refer to the same Object across all the devices when you configure the tabular field in rule. For example, IF-MIB::ifAdminStatus.16. The ifAdminStatus is a column in IF MIB table. The IF-MIB::ifAdminStatus.16 refers to the table column with index 16.

    • Only tabular fields.

  • A scalar object is identified by its MIB name (for example, JUNIPER-MIB::scalarObjectName) or as an OID.

  • Paragon Insights validates a given scalar by checking the MAX-ACCESS property in the MIB definition.

    If you find MAX-ACCESS in the MIB definition set to read-only, read-create, or read-write, then that object can be queried as a scalar.

The complete path to query a scalar object is MIB-Name::table column name:index number.

For example, IF-MIB::ifInOctets:16 .

What's Next