This chapter provides details of how to work with cOS Stream's management interfaces.

Management Access Methods

	Note: InCenter and InControl Can Not Be Used at the Same Time
	It is not possible to configure and use both Centralized Management systems simultaneously. A choice must be made regarding which management system to use.

By default, cOS Stream provides a default LocalUserDatabase object which can be used to authenticate management access if this method is selected (by default, it is selected). This database contains, at a minimum, one predefined user with the following default credentials:

Username: admin
Password: admin

This account has full administrative read/write privileges to all configuration data and is always the account used for initial SSH login (console access does not require any credentials in the default configuration).

	Important: Change the default administrator password
	For security, it is strongly recommended to change the password for the predefined admin account as soon as possible following the initial configuration of cOS Stream.

Displaying the Local User Database

System:/> show LocalUserDatabase

  Name
  ----------
  AdminUsers

System:/> cc LocalUserDatabase AdminUsers

System:/LocalUserDatabase/AdminUsers> show
			
User
			
   Name   Groups          Comments
   -----  --------------  --------
   admin  Administrators  <empty>

System:/LocalUserDatabase/AdminUsers> cc
System:/> 

Creating an Auditor Account

If, however, the group is specified as the text string Auditors, the user will only have read-only privileges and will not be able to make configuration alterations. The following commands create an auditor account with a username of audit and a password of audit:

System:/> cc LocalUserDatabase AdminUsers
System:/LocalUserDatabase/AdminUsers> add User audit
			Password=audit
			Groups=Auditors

Linking Logins to the Database

For example, SSH logins are controlled by a RemoteMgmtSSH object. This object refers to an AuthenticationProfile object that then refers to the database to be used for authentication.

AuthenticationProfile objects are discussed further in Section 17.1, Authentication Profiles. The diagram below illustrates the relationship between the various components.

Figure 2.1. Local User Database Usage with SSH

The CLI provides a comprehensive set of commands that allow the display and modification of a configuration.

This section only provides a summary for using the CLI. For a complete reference for all CLI commands, see the separate Clavister cOS Stream CLI Reference Guide.

String Delimiters, the Escape Character and Special Characters

add User my-user Password="pass word"

set User my-user Password="pass\"word"

Other special characters that might be needed are the following:

For example:

set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH Banner="Welcome!\r\n - Type \"help\""

Note that the only other case that requires a backslash escape character is when using the dollar sign ($) in a CLI script when it is not part of a variable such as $1. When used in another context within a CLI script, it must be written as \$. This is discussed further in Section 2.1.4, CLI Scripting.

Case Sensitivity

CLI Access Methods

Enabling SSH Access

SSH is a protocol primarily used for secure communication over insecure networks, providing strong authentication and data integrity. SSH clients are freely available for almost all platforms. cOS Stream supports version 2 of the SSH protocol.

A RemoteMgmtSSH rule controls SSH access on the default management interface. A predefined RemoteMgmtSSH rule exists in the default configuration but it is disabled. It can be displayed with the CLI command:

System:/> show RemoteManagement RemoteMgmtSSH
	
  # Name
  - -------------
o 1 RemoteMgmtSSH

To enable this rule, use the command:

System:/> set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH -enable

All such rules also require their SourceInterface and SourceNetwork properties to be set for any traffic to be accepted:

System:/> set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH
			SourceInterface=if1
			SourceNetwork=if1_net

The following output from a show command now confirms that the rule has all the required properties set and is enabled:

System:/> show RemoteManagement RemoteMgmtSSH
	
# Name          SourceInterface Source Network
- ------------- --------------- --------------
1 RemoteMgmtSSH if1             if1_net

Authentication for SSH access is controlled by the AuthProfile property of the RemoteMgmtSSH rule. By default this is set to a predefined AuthenticationProfile object called MgmtAuthProfile. This profile points to the predefined local user database which contains a predefined administrator account with the credentials:

The AgentType property of the authentication profile for SSH access should always be set to Basic. All authentication profile properties are explained in Section 17.1, Authentication Profiles.

Processing Multiple RemoteMgmtSSH rules

Authentication Methods for SSH Management Access

SSH and SCP with Public Key Authentication

Public key authentication is set up with the following steps:

The following should be noted about the behavior of SSH authentication using public keys:

Troubleshooting SSH Access Problems

Controlling Direct Console Access to the CLI

show COMPortAccess 

Port Bps    Data bits Parity Stop bits Flow control Rows Cols
---- ------ --------- ------ --------- ------------ ---- ----
COM1 115200 8         None   1         None         40   80
		

An AuthenticationProfile is associated with the ComPortAccess object to specify authentication. In the default configuration, no profile is specified so there is no username/password pair required for console login. The same profile used by default for SSH could be associated with console access by using the command:

System:/> set COMPortAccess COM1 AuthProfile=MgmtAuthProfile

Basic Object Management Commands

CLI Command Structure

	<command> <object_category> <object_type> <object_name>

System:/> show Address IPAddress my_address

When typing commands, the object category can be left out where the command's meaning is unambiguous. For example, the show command above could have been entered as:

System:/> show IPAddress my_address

However, tab completion will always assume that the category is included. For example, tab completion would not be able to help complete the above command if the tab is pressed during or after the IPAddress object type.

The same object name could be used within two different categories or types although this is best avoided in order to avoid ambiguity when reading configurations.

	Note: The terms Category and Context
	When describing the CLI, the term object category is also sometimes referred to as the object context.

A command such as add can also include object properties. To add a new IPAddress object with an IPv4 address of 10.49.02.01, the command would be:

System:/> add Address IPAddress my_address Address=10.49.02.01

Setting the System Name and CLI Prompt

System:/> 

set System Name=my-system1

my-system1:/>

CLI Help

System:/> help time
COMMAND
        time (t). Display and set current system time.
		"
		"

Typing the CLI command:

System:/> help help

will give information about the help command itself.

Configuration Object Help

System:/> helpconfig EthernetInterface

Applying a Single Command to Multiple Objects

An example of an object that has an index number is the IPRule object which must be a member of the rule list in an IPRuleSet. Suppose that there are 100 IPRule objects in the main IP rule set. To change the rules with an index number between 65 and 80 (inclusive) so that their LogEnabled property is disabled, the command would be the following:

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> set IPRule -Range=65-80 LogEnabled=No

Instead a more complex range could be specified:

System:/IPRuleSet/main> set IPRule -Range=10,11-15,60-65 LogEnabled=No

Deletion can be specified in the same way:

System:/IPRuleSet/main> delete IPRule -Range=90-100

The CLI Command History

Tab Completion

For example, consider the following, incomplete command to add a LogReceiver object called my_server to the configuration:

System:/> add LogReceiver LogReceiverSyslog my_receiver
			IPAddress=my_log_server_ip
			LogSeverity=

If the tab character is now entered, a list of available options is displayed for the LogSeverity property:

System:/> add LogReceiver LogReceiverSyslog my_receiver
			IPAddress=my_log_server_ip
			LogSeverity=(tab)
       Type:  String
Description:  Specifies with what severity log events
will be sent to the specified log receivers
    Default:  Emergency,Alert,Critical,Error,Warning,Notice,Information

List of all valid choices:

Name
-----------
<empty>
Debug
Information
Notice
Warning
Error
Critical
Alert
Emergency

Tab Completion Only Displays Allowed Properties

Special Characters Used with Tab Completion

Object Categories and Tab Completion

If a command such as add is entered and then the tab key is pressed, cOS Stream displays all the available categories. By choosing a category and then pressing tab again all the available object types for that category are displayed. Using categories means that there is a simple way to specify what kind of object is being sought and a manageable number of options are displayed after pressing the tab key.

Tab completion and its options are discussed further in the introduction to the separate Clavister NetShield Firewall CLI Reference Guide.

Selecting Object Categories

Suppose a route is to be added to the routing table main. The first command would be:

System:/> cc RoutingTable main
		
System:/RoutingTable/main> 

Notice that the command prompt changes to indicate the current category/context. We can now add the route:

System:/RoutingTable/main> add Route
			Interface=if1
			Network=if1_net
			Name=new_route1

To return to the default CLI context, the command is cc on its own:

System:/RoutingTable/main> cc
		
System:/> 

The categories that require an initial cc command before object manipulation have a "/" character following their names when displayed by a show command. For example: RoutingTable/.

Specifying Multiple Property Values

		AccountingServers=server1,server2,server3

Resetting to the Default Value

System:/> add OSPFProcess Name=my_process1 RouterID=ip_ospf1
Added OSPFProcess OSPF
System:/> set OSPFProcess OSPF1 RouterID=<empty>
Updated OSPFProcess OSPF

Inserting into Rule Lists

Referencing by Name

The cOS Stream CLI Reference Guide lists the options available for each object, including Name= and Index=.

To make reading configurations easier, it is strongly advised to always add unique a unique name to important objects in a configuration. For example, IP rules should always have an appropriate name specified so that their purpose can be immediately understood.

Where the Name property is optional, it can also have duplicates but this is never recommended and can be confusing.

Logging On to the CLI

After SSH communication is established, cOS Stream will respond with a login prompt to pressing the Enter key. Type in the username the login prompt followed by the Enter key. Type the password followed by the Enter key again. After the first startup, cOS Stream will allow administrator login with the username admin and the password admin. This default password should be changed as soon as possible.

If accessing the CLI through a local console connection to the firewall, authentication will only be required if an AuthenticationProfile is explicitly associated with the console's COMPortAccess object.

After a successful logon, the CLI command prompt will appear:

System:/> 

The default welcome message will also be displayed directly after the logon. This SSH welcome message can be removed with the CLI command:

System:/> set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH Banner=

Where ssh is the name of the RemoteMgmtSSH object. To reset the message:

System:/> set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH Banner="Welcome!"

SSH Connection Timeout

System:/> set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH
			SessionIdleTime=1000000

Changing the admin User Password

To change the password, for example to my-password, the following CLI commands are used. First, change the current CLI context to be the relevant LocalUserDatabase object:

System:/> cc LocalUserDatabase AdminUsers

The password of the admin user can now be changed:

System:/LocalUserDatabase/AdminUsers> set User admin Password="my-password"

Finally, return to the default CLI context:

System:/LocalUserDatabase/AdminUsers> cc

Activating and Committing Changes

System:/> activate

System:/> commit

If the commit command is not issued within 30 seconds (the default time period) then the activated changes are automatically undone and the old configuration restored.

Symbols Indicating Object Status

- means the object has been deleted.
o means the object has been disabled.
! means the object has errors.
+ means the object has been newly created.
* means the object has been modified.

Checking Configuration Integrity

System:/> show -errors

All the changes made to a configuration can be shown before activation with the command:

System:/> show -changes

Examining the Configuration Log

System:/> cfglog -all
		
Notice  vsinit/Configure:1805  2025-11-22 13:53:40
  - Beginning system reconfigure. System starting.
		
Notice  vsinit/Configure:1805  2025-11-22 15:59:30
  - Beginning system reconfigure. Activating new configuration.

Notice  vsinit/Configure:2033  2025-11-22 15:59:31
  - Reconfigure completed successfully.

The output from this command also shows if cOS Stream is running in demonstration mode, without a valid license.

System Performance Commands

Using the CLI, the statistics command provides a means to examine individual or groups of values. To see all values for system cpu usage, a wild card can be used as in this example with some typical output:

System:/> statistics -add /system/cpu/*
		
Name | 2025-11-22 13:36:11              Value  Unit
--------------------------------------  -----  ----
/system/cpu/control_plane_usage         1      %
/system/cpu/cpus/ControlPlane_01/usage  1      %
/system/cpu/cpus/FastPath_01/usage      3      %
/system/cpu/cpus/FastPath_02/usage      11     %
/system/cpu/cpus/FastPath_03/usage      5      %
/system/cpu/cpus/FastPath_04/usage      31     %
/system/cpu/cpus/SlowPath_01/usage      7      %
/system/cpu/cpus/SlowPath_02/usage      3      %
/system/cpu/cpus/SlowPath_03/usage      23     %
/system/cpu/cpus/SlowPath_04/usage      14     %
/system/cpu/fast_path_usage             50     %
/system/cpu/slow_path_usage             47     %

The above output comes from a hypothetical processor with four cores. For each core, the fast path and slow path usage is shown with the total for each path at the bottom. The Control Plane handles configuration management and logging functions. The Slow Path deals with the setup of new flows. The Fast Path deals with packet forwarding functions.

The memory command provides a snapshot of memory utilization.

System:/> memory
			
	"
	"
  Free:                                   121306 KB
  Total (In listing + free):              135892 KB

The bulk of the above memory usage output has been omitted except for the final two lines. These give a summary of overall memory utilization.

The top command provides details of CPU utilization by control processes only. An example with truncated output is shown below.

System:/> top

Load avg: 0.94, 0.51, 0.35
CPU usage: 24.8%  CPUs: 1
Name          Time   CPU(%)
------------  -----  ------
statd         14:04  6.3
mdpd          12:52  5.1
vsinit        07:17  2.7
		"
		"

The format of this CPU usage summary follows the convention of the same command in UNIX. The Load avg figures are for the last 1, 5 and 15 minutes respectively. This list is ordered by CPU usage, with the most active processes placed at the top.

Multiple Administration Logins

For example, if one user deletes a configuration object then another user who tries to change it will receive a message to say that the operation is invalid.

Logging Out from the CLI

System:/> exit

Changing the Command View

The currently enabled views can be listed by using the cmdview command with no parameters. For example:

System:/> cmdview
Command view(s) enabled: default

In normal operation the Default view is sufficient. However, some situations may require the use of commands that should be used cautiously and for that reason they are hidden in alternate command "views".

For example, to turn on the Advanced view, enter the command:

System:/> cmdview advanced

Entering the Help command will now show that an additional set of commands are available to the administrator in addition to the default set. These additional commands include, for example, ruledb which provides a technically detailed listing of the current IP rules.

Similarly, an extra set of diagnostic commands becomes available with the command:

System:/> cmdview debug

The Debug, Default and Advanced command views all become available if the parameter all is used:

System:/> cmdview all

The original, default command view is returned by using the following command:

System:/> cmdview default

The service Command View

For this reason, the service view is protected by an additional one time password (OTP) which must be requested from Clavister support.

To allow the administrator to easily store and execute sets of CLI commands, the Clavister NetShield Firewall provides a feature called CLI scripting. A CLI script is a predefined sequence of CLI commands which can be executed after they are saved to a file and the file is then uploaded to the Clavister NetShield Firewall.

The steps for creating a CLI script are as follows:

The CLI script command is the tool used for script management and execution. The complete syntax of the command is described in the cOS Stream CLI Reference Guide and specific examples of usage are detailed in the following sections. See also Section 2.1.3, The CLI in this manual.

	Note
	Uploaded CLI script files are not held in permanent memory and will disappear after system restarts.

All CLI Commands are Allowed in Scripts

Executing Scripts

System:/> script -run my_script.sgs

Script Variables

$1, $2, $3, $4......$n

The values substituted for these variable names are specified as a list at the end of the script -run command line. The number n in the variable name indicates the variable value's position in this list. $1 comes first, $2 comes second and so on.

	Note: The symbol $0 is reserved
	Notice that the name of the first variable is $1. The variable $0 is reserved and is always replaced before execution by the name of the script file itself.

For example, a script called my_script.sgs is to be executed. The IPv4 address 126.12.11.01 is to replace all occurrences of $1 in the script file and the string if1 address is to replace all occurrences of $2.

The file my_script.sgs contains the single CLI command line:

add Address IPAddress if1_ip Address=$1 Comments=$2

To run this script file after uploading to cOS Stream with the given substitutions, the CLI command would be:

> script -run my_script.sgs 126.12.11.01 "if1 address"

Notice how the "if1 address" parameter is enclosed in quotes so any spaces can be included.

When the script file runs, the replacement of the variables means that the command becomes:

add Address IPAddress if1_ip Address=126.12.11.01 Comments="if1 address"

Escaping Characters

Script Validation and Command Ordering

Error Handling

System:/> script -run my_script2.sgs -force

Script Output

System:/> script -run my_script2.sgs -verbose

Scripts Are Lost After Restart

Listing Scripts

System:/> script
		
Name            Size
--------------  ----
my_script.sgs   8
my_script2.sgs  10

System:/> script -show my_script.sgs

Creating Scripts Automatically

If an installation already has the objects configured that need to be copied, then running the script -create command on that installation provides a way to automatically create the required script file. This script file can then be downloaded to the local management workstation and then uploaded to and executed on other Clavister NetShield Firewalls to duplicate the objects.

For example, suppose the requirement is to create the same set of IPAddress objects on several Clavister NetShield Firewalls that already exist on a single firewall. The administrator would connect to the single firewall with the CLI and issue the command:

System:/> script -create Address IPAddress -filename=new_script.sgs

This creates a script file called new_script_sgs which contains all the CLI commands necessary to create all IPAddress objects in that firewall's configuration. The created file's contents might, for example, be:

add Address IPAddress if1_ip Address=10.6.60.10
add IPAddress if1_net Address=10.6.60.0/24
add IPAddress if1_br Address=10.6.60.255
add IPAddress if1_dns1 Address=141.1.1.1
		"
		"
		"

Note that with the -create option, the output file must be specified with the -filename= parameter. This is the only time that -filename= is used.

The file new_script_sgs can then be downloaded with SCP to the local management workstation computer and then uploaded and executed on other Clavister NetShield Firewalls. The end result is that all units will have the same IPAddress objects in their address book.

In order to preserve any script files created in this way between system restarts, they must downloaded to the local storage of the management workstation using SCP and then uploaded again later.

Note: Automatically created scripts omit the object category

In the created script example above, adding an IP address is done with the command: add IPAddress... This is instead of the usual way of qualifying the object with its group name: add Address IPAddress... Both are valid forms of the command. If an object type can be uniquely identified with its name, its object category need not be specified. With automatically generated scripts, this is always the case. This shortened form can also be used when typing the entire command in a CLI console although tab completion will always include the object category.

Objects Excluded from Script Files

These node types are skipped when the script file is created and cOS Stream gives the message No objects of selected category or type.

	Tip: Listing commands at the console
	To list the created CLI commands on the console instead of saving them to a file, leave out the -filename= parameter in the script -create command.

Commenting Script Files

# The following line defines the if1 IPv4 address
add Address IPAddress if1_ip Address=10.6.60.10

Scripts Running Other Scripts

		script -run my_script2.sgs

In order to allow InControl to connect to cOS Stream for management using the NetCon communication protocol, a Remote Management rule needs to be used.

Example 2.1. Configuring cOS Stream for Centralized Management Using InControl

In this example, there is an InControl server located behind the DMZ interface. To allow the InControl server to connect to cOS Stream, a Pre-shared Key (PSK) and a Remote Management rule is needed.

In the default configuration, a NetCon remote management rule exists but is disabled. This rule must either be enabled and modified or deleted, and a new remote management rule created for NetCon, as only one rule of this type can exist at any given time. For the below example, the method of making modification to the existing rule is used.

Command-Line Interface

First, Generate a new PSK object, note that the size must be 512 bits:

System:/> pskgen NetconPSK -size=512

Alternatively, if an existing PSK is already available:

System:/> add PSK NetconPSK Type=HEX PSKHex=568633cd5399c365fc8...

Enable the pre-created Remote Management rule.

System:/> set RemoteManagement RemoteMgmtNetcon -enable

As the last step, modify the enabled Remote Management rule to allow NetCon communication from the InControl server located in the DMZ using the chosen PSK.

System:/> set RemoteManagement RemoteMgmtNetcon
				AuthProfile=MgmtAuthProfileNetCon
				Key=NetconPSK
				SourceInterface=DMZ
				SourceNetwork=DMZ_net
				AccessLevel=Admin

This uses the default authentication profile MgmtAuthProfileNetCon. A new profile with custom values can also be used:

System:/> add AuthenticationProfile NetconAuth AgentType=PSK

Once deployed, the InControl server located in the DMZ is now allowed to connect to the firewall using the NetCon protocol for centralized management.

For more in-depth information about InControl see the the separate InControl Administration Guide.

To upload and download files to or from the Clavister NetShield Firewall, the Secure Copy (SCP) protocol can be used. SCP is based on the SSH protocol and many freely available SCP clients exist for almost all platforms. The command line examples given below are based on the most common command format found with SCP client software. Some SCP clients might use different syntax.

	Note: SFTP is not supported
	Currently, cOS Stream does not support SFTP which means that transfers with later versions of the OpenSSH client may fail. This is solved by including the OpenSSH -O legacy option.

SCP Command Format

Upload is performed with the command:

> scp <local_filename> <destination_firewall>

Download is done with the command:

> scp <source_firewall> <local_filename>

The source or destination Clavister NetShield Firewall is specified using the format:

		<user_name>@<firewall_ip_address>:<filepath>

For example:

		admin@10.62.11.10:config.bkp

The <user_name> must be a defined user belonging to the administrator user group.

	Note: SCP examples do not show the password prompt
	SCP will normally prompt for the user password after the command line but that prompt is not shown in the examples given in this document.

Examples of SCP Uploading and Downloading

Using Wildcards with SCP

 > scp admin@192.168.3.1:*.mib .

 > scp admin@192.168.3.1:* .

 > scp *.bkp admin@192.168.3.1:.

For system management tasks in the default configuration, the administrator logs in to the CLI via SSH using a username and password that are checked against the credentials stored in a local database.

An alternative to using a local database is to have cOS Stream perform authentication of the entered credentials against an external RADIUS server. This is done by changing the properties of the AuthenticationProfile object assigned to the RemoteManagementSSH object used for CLI access via SSH. The option exists to use either a local database or a RADIUS server as the authentication source, or a combination of both. If a combination is selected, the administrator can then select which source to try first.

	Caution: RADIUS is ignored with public key authentication
	If cOS Stream is able to use public key authentication when an SSH client connects then RADIUS authentication will not also be attempted even though it might be configured in an associated AuthenticationProfile object.

Configuration Steps

RADIUS Servers Must Be Correctly Configured

The Login Message Changes for a Group Mismatch

However, there is one exception. When the user credentials are correct but the group name returned by the RADIUS server does not match a valid group (it is not Administrators or Auditors) the CLI will display the following message:

	Access denied.

Generated Log Event Messages

The types of log event messages that cOS Stream might generate are as follows:

 AUTHSYS: prio=notice id=00000 event=user_logged_in
 userid=33 user=jdoe ip=192.168.1.1 profile=MgmtAuthProfile agent=Basic
 userdb=RadiusServer1 usergroups="Administrators" action=none

AUTHSYS: prio=notice id=00000 event=user_logged_in
 userid=32 user=admin ip=192.168.1.1 profile=MgmtAuthProfile agent=Basic
 userdb=AdminUsers usergroups="Administrators" action=none

 AUTHSYS: prio=warning id=00000 event=received_radius_access-reject_message
 userid=33 user=jdoe ip=192.168.1.1 profile=MgmtAuthProfile
 agent=Basic userdb=RadiusServer1 action=none

 AUTHSYS: prio=warning id=00000 event=authentication_source_did_not_respond
 userid=33 user=jdoe ip=192.168.1.1 profile=MgmtAuthProfile
 agent=Basic userdb=RadiusServer1 action=none

Use the Local Console as a Fallback Option

System:/> add AuthenticationProfile my_mgmt_auth_profile
			LocalUserDB=""
			RemoteServer=my_radius_auth1,my_radius_auth2
			RemoteLoadBalance=RoundRobin
			AuthOrder=LocalLast
			MultipleLogins=AllowOne

System:/> set RemoteManagement RemoteMgmtSSH RemoteMgmtSSH
			AuthProfile=my_mgmt_auth_profile

Overview

Supported SNMP Versions

This section discussed overall MIB file support and setting up version 1 or 2c access. SNMPv3 access is described in Section 2.1.9, SNMPv3 Polling.

Supported Request Operations

MIB Files

An SNMP client connecting to cOS Stream can use two different types of MIB files:

Downloading MIB Files

> scp admin@192.168.1.17:/*.mib .

The selected MIB file should be transferred to the hard disk of the workstation that will run the SNMP client so it can be imported by the client software. When the SNMP client runs, the MIB files are read and they tell the client which values can be queried.

MIB Entries

IfPktsTotCnt OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION 
        "Total number of packets transmitted by the interface"
    ::= { clvIfStatsEntry 10 }

All statistical values that can be accessed by SNMP are listed in the separate Statistics Reference Guide which provides all available information for each. This includes the description of the values together with the MIB OID, MIB name and MIB type.

Setting Up Version 1 or 2c SNMP Access

To ensure that the correct RemoteMgmtSNMP object triggers, different objects should not use overlapping filters. Instead, each object should specify a unique source interface and network combination. In addition, the source interface and network filters of RemoteMgmtSNMP and RemoteMgmtSNMP3 objects should also not overlap.

In addition to the filter parameters above, each RemoteMgmtSNMP rule also needs to have these two properties configured:

Other optional properties for the RemoteMgmtSNMP rule can be found in the separate CLI Reference Guide.

The Community String

System:/> add RemoteManagement RemoteMgmtSNMP my_snmp
			SourceInterface=lan
			SourceNetwork=mgmt-net
			GetCommunity=my-community-string

IP Rules are not Required with SNMP

Security Concerns with Version 1 and 2c

However, SNMPv3 polling can provide both encryption and authentication and this is described in the next section.

cOS Stream supports SNMPv3 polling by an external SNMPv3 client with an IPv4 or IPv6 address. SNMPv3 differs from the earlier SNMP versions in that it can provide both encryption and/or authentication.

Setting Up SNMPv3 Polling

All the available properties are listed under the RemoteMgmtSNMP3 object entry in the separate CLI Reference Guide.

To ensure that the correct RemoteMgmtSNMP3 object triggers, different objects should not use overlapping filters. Instead, each object should specify a unique source interface and network combination. In addition, the source interface and network filters of RemoteMgmtSNMP and RemoteMgmtSNMP3 objects should also not overlap.

SecurityLevel Property Options

SNMPv3 Encryption

SNMPv3 Authentication

By default, the algorithm used for creating the hash of the password is HMAC-SHA1-96. This can be changed by setting the property AuthenticationMethod to the alternative value of HMAC-MD5-96. However, HMAC-SHA1-96 is the recommended setting for strong security.

Note that SNMPv3 polling with authentication enabled will cease to function if the reboot counter has reached its maximum value. The reboot counter and how it is reset is explained further in Section 20.5, SNMP Traps.

Multiple Clients Are Allowed

However, it is important that the SourceNetwork property for multiple RemoteMgmtSNMP3 objects do not have IP addresses assigned to them which overlap. If overlapping occurs, the behavior will be unpredictable.

System:/> add RemoteManagement RemoteMgmtSNMP3 my-snmp3-rule
			SourceInterface=if1
			SourceNetwork=if1_net
			LocalUserDB=AdminUsers
			PrivacyPassword=mysecretpassword
			RequestLimit=20