FlexView Request Groups

NetSight Console uses SNMP requests to retrieve the MIB data that appears in FlexViews. In the interest of performance, Console supports multiple SNMP requests, bundling multiple GET or GETNEXT requests into each SNMP PDU (protocol data unit) when retrieving data for FlexViews. But, the success or failure for a particular SNMP operation is determined at the PDU level. So, when an individual request contained in a PDU fails, the entire PDU is marked as having failed and the data for the requested MIB objects cannot be displayed in the FlexView. This same condition exists when any one of the devices queried supports some, but not all, of the requested MIB objects. The query fails and results in an empty FlexView row being displayed for that device. You could remove the columns for the unsupported MIB objects, but then that data will not be available from devices where those objects are supported.

A better solution would be to assign MIB objects that may not be supported to a separate request. With Console, you can assign MIB objects to one of four request groups (default, 2, 3, or 4) corresponding to a grouping of SNMP requests sent to devices. This feature gives you control over which SNMP requests are bundled into each SNMP PDU. MIB objects that are supported by all devices should be left in one (default) request group and MIB objects that are supported on some, but not all, devices can be put in a separate request group. If the PDU for the first request group succeeds, but the PDU for the second request group fails, a FlexView row will still be added that contains the data returned in the first PDU. The columns that cannot be populated due to the failure of the second PDU are left blank. Both PDUs will succeed for devices that support all of the objects and the FlexView rows created for those devices will contain valid data in all columns.

When columns are mapped to more than one request group, requests are done according to group order: Default, group 2, group 3, then group 4. Scalar (not contained in a table) and instanced (tabular) MIB data is retrieved by one or more separate SNMP PDUs for each request group. The tabular data usually produces several rows of information for a particular device, one row for each instance in the requested MIB table. When a FlexView is defined to show both scalar and tabular objects, the specific scalar information is repeated for each instance (row) of tabular data returned from a device.

As a general rule, you should:

  • assign columns with MIB objects that are supported by all devices to the Default request group.
  • assign columns with MIB objects that are not supported by all devices to the 2 or 3 request group.

The use of multiple request groups is shown in this example of a network with devices that support three sets of MIB objects.

  • Group I supports objects A, B, C, and D,
  • Group II supports objects A, B, and C,
  • Group III supports objects A, B, and D,

In this example, you would use three request groups to get the FlexView to populate correctly. Since objects A and B are supported by all devices, you can assign columns for A and B to the Default request group. Objects C and D are supported by some, but not all devices, so column C should be assigned to request group 2, and Column D should be assigned to request group 3.

  NOTE: Utilizing multiple request groups increases the number of SNMP PDUs that must be sent to populate a FlexView.

Related Information

For information on related windows:

For information on related concepts:

For information on related tasks: